導入期を越えて、生成AIは「モデル性能」だけで差がつく時代から、「運用のしやすさ・失敗の仕方・責任の切り分け」で差がつく局面に入っています。今週は、(1) 指示追従が“表層の書式”に引きずられて崩れる問題、(2) エージェントを本番に載せるためのマネージド基盤、(3) エージェントが使うクレジットと権限のガバナンス、の3点が同時に進んだのが印象的でした。
1) 「たった1トークン」で崩れる instruction-tuned モデルの“親切さ”
arXivの論文 One Token Away from Collapse は、instruction tuningで得られる「親切で構造化された回答」が、実は些細な語彙制約で急激に崩れることを示しています（arXiv）。
著者らは、句読点1文字や一般的な単語1つを“使わない”という程度の制約を課すだけで、回答の網羅性（comprehensiveness）が14〜48%落ちたと報告しています（arXiv）。さらに、1,920件のペア比較では、制約なしのベースライン回答が77〜100%で好まれ、閉源モデルのGPT-4o-miniでも31%の低下・99%のベースライン勝率が観測されたとしています（arXiv）。
何が起きているのか（“書式”ではなく“計画”が崩れる）
この現象は「出力フォーマットが崩れる」程度ではなく、回答の計画そのものが立たなくなる planning failure として分析されています（arXiv）。興味深いのは、
- まず自由に書かせてから制約下で書き換える2-pass生成で、応答長が59〜96%回復する
- 生成前のプロンプト表現に線形プローブを当てると、応答長を (R^2=0.51)〜(0.93) で予測でき、ベースモデルでは負の (R^2)
という結果が出ている点です（arXiv）。つまりinstruction tuningが「正しいタスク理解」と「特定の表層テンプレート」を強く結びつけ、そのテンプレートが崩れると“計画を放棄する”ような表現構造が生まれている、という解釈が成り立ちます。
実務への示唆
実運用では、ユーザー要件として「この記号は出さない」「この単語は使わない」「社内用語に合わせる」といった制約が意外に多いです。ここで品質が急落するなら、プロンプト・後処理・評価の設計を変える必要があります。
- 生成を一発勝負にせず、下書き→整形→検証のパイプラインにする（2-pass的発想）
- “独立採点”より、ペア比較やリファレンス比較を中心に据える（論文では独立judgeが劣化を過小検出したと指摘）（arXiv）
- 制約付き生成を前提に、モデル/プロンプトの回帰テストを用意する
こうした対策は、次の「エージェント運用基盤」の話と直結します。
2) マネージド・エージェント基盤の価値は“便利さ”ではなく“失敗管理”
InfoWorldは、Anthropicが Claude Managed Agents を発表したと報じています（InfoWorld）。内容は「Claude上で動くクラウドホスト型エージェント」を作るためのAPI群で、sandboxed code execution、checkpointing、credential management、scoped permissions、end-to-end tracing などを提供するとされています（InfoWorld）。
なぜ今“マネージド”が重要なのか
エージェントは、LLMの出力が不安定でも「再試行」「途中保存」「権限の一時付与」「監査ログ」で壊れ方を制御できれば、プロダクトとして成立します。逆に言えば、モデル単体の性能が上がっても、
- どのツールをいつ呼んだか
- どの資格情報で何にアクセスしたか
- どこで失敗し、どう復旧したか
が追跡できないと、業務に入れた瞬間に事故になります。Managed Agentsが示す方向性は、LLMを“賢い関数”ではなく“長時間動くプロセス”として扱い、失敗と責任を設計するところにあります。
3) エージェントの「クレジット消費」と「権限行使」は、UIではなく契約とデフォルトで守る
Hacker Newsでも議論された Gas Town のGitHub Issueでは、ローカルインストールがユーザーの明示的指示なしにGitHub上の課題レビュー等を走らせ、サブスクのLLMクレジットを消費するのでは、という懸念が提起されています（gastownhall/gastown issue #3649）。Issue本文では、ユーザーのGitHub資格情報でPR提出まで行われ得る点、opt-in/opt-outや警告・可視性が不足している点が争点として述べられています（gastownhall/gastown issue #3649）。
ここが本質：行為主体は誰か
エージェントが外部サービスを呼ぶとき、費用（トークン/クレジット）と権限（API/アカウント操作）が同時に動きます。ここで重要なのは「ユーザーが見たかどうか」ではなく、
- 既定値が安全か（デフォルトoff、最小権限、最小コスト）
- 意思決定のログが残るか（後から説明できるか）
- 逸脱時に止まるか（上限・レート・承認フロー）
です。Managed Agentsのような基盤が提供するべき“credential management / scoped permissions / tracing”は、まさにこの領域の土台になります（InfoWorld）。
まとめ
今週の流れを一言で言うと、「モデルは賢くなるが、運用は“壊れ方”と“責任”を設計しないと成立しない」です。指示追従の脆さは、エージェントに組み込んだ瞬間に“コスト暴走”や“権限事故”として増幅します。逆に、生成をパイプライン化し、評価を比較中心にし、権限とコストをデフォルトで縛れるなら、LLMは業務プロセスの中でようやく安定した部品になります。
参考（動向把握用）: arXiv cs.AI recent, arXiv cs.CL recent, Hacker News