第7章：エージェントの安定性設計
― 暴走・ループ・コスト爆発を"構造で"防ぐ
ここまでの議論を振り返ると、エージェントが破綻する原因は、ほぼすべて 文脈管理の失敗 にある。
- 文脈が混ざる（役割が曖昧）
- タスクが混ざる（実行まで背負わされる）
- 時間が混ざる（毎回一から思考・計算）
言い換えると、
文脈・実行・時間の3つをしっかり分ければ、エージェントはほとんど壊れなくなる。
安定性は「機械学習の難しさ」ではなくアーキテクチャの問題だ。
エージェントが不安定になる典型シナリオ
実務でよく見られる失敗から整理する。
- タスク指示が曖昧
- AIが手探りで計画を立てる
- AIが自分で決めた手順を実行する
- 実行結果を誤解する
- 自分で誤った修正計画を立てる
- 無限ループ
「判断 → 実行 → 評価」がすべてAI内部で完結してしまうと、誤解が閉じたループとして増幅される。
強い制約なしに自律型で回すのは危険だ。
安定性をつくる3つのレイヤー
エージェントの安定性は、以下の3層で支えられる。
1️⃣ 文脈の安定（役割の純度）
- 役割＝文脈を分離する
- 判断基準だけを明記する
- 推論の外へ踏み出さない制約を入れる
迷いは文脈汚染から始まる。
2️⃣ 実行の安定（タスク外部化）
- 実行はすべてMCPや外部ワーカーに任せる
- LLMは"使うべきタスクを選ぶだけ"
- 実行結果は構造化して返す
AIは決断し、MCPが動く。役割の重ね着をさせない。
3️⃣ 時間の安定（レポート化）
- 計算は事前バッチで済ませておく
- LLMは読むだけ
- コストとレイテンシが固定化される
推論コストを過去に押し込む。質問時には推論させない。
"チェックポイント"は万能ではない
多くのフレームワークは、中間で人間や別エージェントに「承認」を入れることで安定性を確保しようとする。
しかし実は、これは応急処置にすぎない。
- 文脈が汚染されていれば → チェックしてもブレる
- タスクをAIが内部に持っていれば → 承認タイミングを逃す
- 創発が無制御なら → 人間が止めるしかない
承認ワークフローは最後の砦。本質は構造で安定させること。
安全弁は品質保証ではない
構造で安定させるとき、安全弁（ループ上限・連鎖上限）を入れることになる。ここで混同が起きる。
安全弁は暴走を止める。品質は保証しない。
- 修正の往復に上限を置けば、無限ループは構造的に消える
- しかし同じ問題を上限回数ぶん繰り返して、すべて失敗することはある
- 止まった時点の成果物は中途半端なままだ
それでよい。安定性とは「壊れない」ことであり、「正しい」ことではない。正しさは別の仕組み（事後チェック・人間レビュー）で担保する。安全弁と品質保証を同じ機構に混ぜると、どちらも果たせなくなる。
そして安全弁には知性を入れない。
安全弁はシンプルであることが最大の価値だ。安全弁に判断を持たせると、安全弁自体が壊れる。
「回数ではなく収束度で止める」ような改良は、止める判断をAIに戻す。最後の砦が推論に依存すれば、砦は推論と一緒に倒れる。回数上限のような、推論に依存しない止め方を選ぶ。
事後チェックは「複数の独立軸」で構成する
判断と検証を分離しても、検証が1つの総合判断なら穴が残る。
- 文脈バイアスは分離で補正できる ― 実行役と検証役に別の役割文脈を与える
- モデルバイアスは分離で補正できない ― 同じモデルは文脈を変えても同じ盲点を持つ
だから検証を「これは問題ないか？」という1問に集約しない。「品質」「セキュリティ」「テストの有無」「スコープ逸脱」のように、独立した軸を構造的に定義して別々に評価する。ある軸が盲点に落ちても、別の軸が拾う。
検証の信頼性は、モデルの賢さではなく軸の独立性から来る。
そして事後チェックには帯域がある。同時に走らせる自律の本数を増やすと、先に飽和するのは実行側ではなく検証側だ。帯域を超えた事後チェックは、落ちるのではなく通ったことになる。エラーを出さずに縮退する。だから同時実行の本数には上限を置く。上限の根拠はAIの能力ではなく、検証側が実際にさばける量である。
止められる範囲でしか止められない
安全弁も事後チェックも「誤りを見つけて止める」機構だ。止めることに意味があるのは、止めた時点でまだ外の世界が変わっていない場合だけである。
コード生成では、プルリクエストという待機場所がこの前提を暗黙に保証している。メール送信・デプロイ・決済のように、実行した瞬間に外部へ効果が出る操作では前提が消える。
自律で実行してよいのは、取り消せる操作だけである。取り消せない操作は、結果ではなく実行そのものを人間の承認に通す。
可逆かどうかは操作そのものが持つ性質であり、推論なしに判定できる。だからこの線引きはAIの判断に委ねず、構造として置く。
ただし、可逆であることは自律に渡してよい理由にはならない。承認モードの切り替え、ロール昇格、許可リストの拡張、認証情報の付与は、設定としては戻せる。戻せるが、戻すまでのあいだに承認を通さない実行ができる。
制約される主体は、その制約を解除する権限を自分で発行できてはならない。
権限を緩める方向の変更だけを承認に通し、厳しくする方向は自律でよい。安全弁の効き目は、安全弁自体を書き換えられないことに依存している。
安定性をチェックする質問（実務用）
エージェントを設計したら、以下のチェックをしてみてほしい。
- ✓ 判断と実行は完全に分離されているか？
- ✓ 役割は文脈として一貫しているか？
- ✓ タスク手順が文脈に紛れ込んでいないか？
- ✓ データ計算がリアルタイムになっていないか？
- ✓ 文脈外の判断をしない制約があるか？
- ✓ 誤解がループにならない構造か？
- ✓ 全ユーザーが同じ知識にアクセスできるか？
- ✓ 創発性の高いタスクに、実行前のリスク判定があるか？
- ✓ 自律実行の結果に事後チェックがあり、それが複数の独立軸で構成されているか？
- ✓ 同時に走る自律の本数が、検証側のさばける量を超えていないか？
- ✓ 取り消せない操作が、実行そのものを人間の承認に通す形になっているか？
- ✓ AI自身の権限を引き上げる操作（承認モードの緩和・ロール昇格・許可リストの拡張・認証情報の付与）が、可逆であっても承認を通す形になっているか？
- ✓ 自己修正ループと自律の連鎖に上限があり、その上限が推論に依存しない形で置かれているか？
1つでも「No」なら、不安定化リスクが高い。
安定性は"設計思想"で決まる
AIを賢くするのではなく、賢さが「壊れないようにする」。
その鍵はシンプルだ。
- 文脈を分ける
- 実行を外に出す
- 計算を事前に済ませる
- 過信しない
- 主語を間違えない
エージェントは人間の代わりではない。人間の判断を増幅する役割だ。
この章のまとめ
- 不安定化の原因は「文脈・実行・時間」が混ざること
- 3つを分けることでエージェントはほぼ壊れない
- チェックポイントは対症療法であり、本質は構造にある
- 安定性は"知能"ではなく"設計思想"で決まる
- 安全弁は暴走を止めるだけで品質は保証しない。安全弁と品質保証を混ぜない
- 安全弁はシンプルであること自体が価値。判断を持たせると安全弁が壊れる
- 事後チェックの信頼性は検証軸の独立性から来る。帯域を超えた事後チェックは落ちずに「通ったことになる」
- 止められるのは、まだ外の世界が変わっていないうちだけ。取り消せない操作は実行そのものを承認に通す
- 可逆であることは自律に渡してよい理由にならない。制約される主体が、その制約を解除する権限を自分で発行できてはならない
次章は、これらを統合した「エージェントOS構想」を提示する。
Last Updated: 2026-09-20