今日の収穫、3行で。

HNの反応は割れた。歓迎派は「価格据え置きでキャッシュ読み取りが1/4、長時間エージェントほど効く」「クォータのリセットも同時に来た」と実利を評価する。懐疑派は「Fable 5はOpusにベンチでもコストでも見劣りし、5.1で本当に差が出るのか」「無料で試させてくれない限り触らない」と慎重だ。文章面では「以前よりストック表現は減ったが密度が上がって読みづらい」「succinctさとは違う」との批判が目立ち、3つの破壊的変更が『think_deeplyツールで生の思考を吐かせる』『他モデルの思考ブロックを復元させる』といった露出手口への対策だと分析するコメントもあった。

「Content provenance（来歴情報）」がこのモデルで有効化されたとコメントで指摘されている。各思考ブロックにはどのモデルが生成したかが記録され、Fable 5.1は過去モデルの思考を読めるが過去モデルはFable 5.1の思考を読めない、という一方向の可視性になっている。

「たしかにCodexの推論ログにLibreOffice参照が出る。docx/xlsxをLLMの作業結果と相互変換するための手っ取り早い手段だろう」と用途を推測する声がある一方、「2GBは狂気。ハッシュ固定でオンデマンド取得すればいい」「ユーザーが既に持つバイナリを探して使わないのはなぜか」とサイズと実装への批判が集まった。Anthropic側もclaude-codeが無断で10GBのVMを入れた前例があると持ち出され、フロンティア各社アプリの肥大化そのものへの不満に発展している。

同種の指摘として、OpenAIアプリには `@oai/walnut` なる別バンドルの存在もコメントで言及された。オフィス文書の生成・編集をAIに任せる流れが進むと、Officeは『ビューア』に後退しかねないという観測も出ている。

指示を増やすほど従うという前提が崩れつつある、というのが通底する論点だ。文章として書いた規範の大半は人間もモデルも守れず、Hookやdenyルールのように機械が検査・強制できる形に落とし込んだ分だけが実効を持つ——「93行しか検査できず13行しか止められない」という数値がそれを可視化する。一方で全部をHook化はできないため、CLAUDE.mdは常時読み込む最小限の指示に絞り、詳細はskillや外部ドキュメントへ逃がす『痩せさせる』設計へ収束しつつある。

共通するのは「人間がターミナルに張り付く前提」を外す方向だ。PCを閉じても継続させる、開発の大半をクラウド環境へ移す、外部イベント（Webhookやメッセージ）で起動する——いずれも、エージェントを対話相手ではなくバックグラウンドのワーカーとして扱う。副作用として、実行環境の権限管理や成果の受け取り方（後続のs09の委任・安全設計）が新たな設計課題として浮上する。

採点記事へのHNの反応は辛辣で、「D004（引数に説明がない）を一律減点するのは粗い。urlのように説明不要な引数もある」「基準がAI生成っぽく、Anthropic発の作法で純度テストしているだけ」との批判が並んだ。一方で建設的な合意もあり、「システムAPIをそのままツール化するのが最大の失敗。100個のツールではなく10〜12の領域＋領域内アクションの階層にまとめよ（例：ファイル操作は単一の『file』ツールにlist/copy/rename等のアクション）」という設計原則が支持を集めた。

Q. MCPサーバーのツールは多いほど良い？
A. 逆で、フラットに多数のツールを並べると文脈を汚す。少数の『領域』ツールにアクションを束ねる階層化が、モデルが必要時だけ潜って使える設計とされる。

Q. LLMに書き込み権限を渡すツールで気をつける点は？
A. 書き込み系MCPは誤操作・悪用の影響が大きいため、操作の境界を明示し、危険な操作を安全な調査から分離する設計が推奨される。

Q. oRPCはHonoやtRPCと何が違う？
A. oRPCはOpenAPI互換の型安全RPCで、Honoをサーバーに据えつつクライアントまで型を通せる。TanStack Startのサーバー関数と組み合わせる構成が本記事の主眼。

Q. 業務システムをCloudflare Workersに載せる利点は？
A. エッジでの低レイテンシ配信とD1/KV等との一体運用。一方でランタイム制約（実行時間・Node API非互換）が設計判断を縛る、という学びが共有されている。

クラウドAPIの従量課金と対照的に、手元の統合メモリ機（128GB級）でそれなりのモデルが実用速度で動くようになってきた点が肝だ。H3-metalのようなネイティブ実装やmacOS VMでのGPUパススルーは、Apple Siliconの帯域を引き出す最適化の方向を示す。ただし大規模モデルや長文脈ではメモリと速度が依然ボトルネックで、用途を選ぶという温度感も同居する。

『指示文（プロンプト）で権限を縛る』のは実効性が低い、という認識が共通する。調査は自由にさせつつ副作用のある実行だけを別スコープ・別権限に隔離する、あるいはツールやサンドボックスの側で機械的に制限する——非同期・遠隔実行（s04）が広がるほど、この分離設計の重要度が増す。承認ダイアログの内部挙動を可視化する記事は、ユーザーが『はい』を押す前に何が起きるかを理解するための土台を与える。

「人間化」記事は誤読も招いたが、主旨は『生成後に文体を整えるより、モデル内部の簡潔な自己対話をそのまま活かせ』という提案だ。HNでは「花のような装飾過多の出力は読み返しても頭に入らない。むしろ deictic な言い回しを削れと指示している」「終始フレンドリーで冗長なのはいらない、簡潔で事実ベースの工学的応答が欲しい」と、簡潔さを求める声が強い。Fableがドキュメントで筆者の名を三人称で使う癖への違和感など、出力トーンの実務的な不満も具体的に挙がった。

Claudeのテキスト透かしは出力後に付ける印ではなく、サンプリング（次トークン選択）の段階で統計的な偏りを埋め込むことで実現される。s01のFable 5.1で有効化された『来歴情報』とあわせ、AI生成物の識別・追跡は生成プロセスそのものに組み込まれつつある。

「偽トークンを注入し、プロキシ側で本物に差し替える」パターンは有効だが目新しくはなく、コメント欄はInfisical・varlock・Vault連携など自作の類似実装の宣伝で埋まった。批判的な声としては「結局は信頼するプロキシへ鍵を移し替えているだけで、どこかでLLMに資格情報が渡る」「静的な資格情報には効くが、SSO（OAuth/OIDC/SAML）を使えるならそちらの方が成熟している」との指摘があり、OAuthクライアント資格情報のフローをゲートウェイ側で代行する拡張が実用的だという提案も出た。