第7章：安定性OS ― エージェントが壊れない構造

— エージェントは"壊れるのが普通"ではない。壊れる理由はすべて構造にある。

AIエージェントが壊れるとき、原因はモデルの能力不足ではない。

99%は 設計思想の欠陥 である。

• 文脈が汚染される
• 時間軸が混ざる
• 実行と判断が同じ場所にある
• "創発"に自律と実行を背負わせる
• 推論プロセスがループを生む
• 同じ質問でも回答が揺れる

これらはすべて 構造欠陥 だ。

逆に言えば、構造さえ整えれば、エージェントは 簡単に安定 する。

---

7.1 エージェントが壊れる典型的な経路

あなたが何度も観測してきた"事故"は、すべてこの一本線に収束する：

文脈の混乱
   ↓
判断の混乱
   ↓
タスク選択の混乱
   ↓
実行の混乱
   ↓
エラーを誤解
   ↓
誤解をもとに再計画
   ↓
ループ／暴走／破綻

つまり：

"壊れる"のではない。"壊れる構造で作った"だけである。

---

7.2 安定性OSの3本柱

エージェントの安定性は、次の3つだけで決まる。

① 文脈の分離（Context Isolation）

エージェントは役割（ロール）が混ざった瞬間に迷い始める。

• いまは設計者？
• いまは実装者？
• いまは調査員？
• いまは実行者？

これらが混ざると、AIは人間では絶対に起こらない誤解を起こし始める。

文脈汚染が起きる理由

LLMは「最後に読んだ文」で世界を決めるので、

• 役割
• 判断基準
• 目的
• タスクの可否

が混ざると 一瞬で「別の人格」になる。

対策：Role Memoryによる"人格の固定"

• 役割を一つだけアクティブにする
• 別の役割を使うときは明示的に切り替える
• 役割ごとに"判断基準"を固定

---

② 実行の外部化（Execution Offloading）

AI内部で実行させると破綻する。

• ファイルの生成
• コード実行
• API呼び出し
• DB更新
• プロセス制御
• スケジューラ操作

これらをAIが"自分でやる"と、誤解 → 実行 → 事故 が必ず起きる。

なぜか？

LLMは「世界の状態」を理解できないから。

• ファイルが本当に存在するか？
• APIが成功したか？
• DBに反映されたか？

記号と自然言語しか扱えないので、現実世界の状態は"想像"になる。

→ 事故の温床

対策：Task Interface を外に置く

実行はすべて：

• MCP
• サブエージェント（ワーカー）
• 外部API
• Cloud Functions
• AgentEngineのタスクリクエスト
• LangGraphのNode Execution

など、外部エンジンに担当させる。

AIがやることは "どのタスクを呼ぶか"だけ。

---

③ 時間の固定化（Temporal Stabilization）

第6章で述べた「レポート化」は、この"時間の安定化"の中心になる。

エージェントが壊れる最大原因は：

毎回ゼロから考え直すこと。

• コストが揺れる
• レイテンシが揺れる
• 回答が揺れる
• 推論量が積み上がり、文脈が吹っ飛ぶ

対策：推論を過去に押し込める

• 分析はバッチ
• 状態はメモリ
• 設計判断はRole Memory
• フォーマットはReports
• ルールはCore Memory

「未来」を安定させる唯一の方法は、過去にすべてを押し込めることだ。

---

7.3 3層を揃えるとAIは壊れなくなる

3層を並べてみると、すべての事故は説明がつく。

事故の種類	原因	対策
ループ	文脈汚染＋実行が内部	Role Memory＋外部化
暴走	役割混在	文脈の固定
間違い続ける	推論が毎回ゼロ	レポート化
状態を誤解する	内部実行	タスク外部化
実行できない	判断と実行の混在	Task Interfaceの分離
再現性なし	推論が揺れる	時間軸の固定
バグ修正できない	状態不可視	外部実行ログ化

この表を見ると分かる通り：

エージェント事故は100%構造で防げる。

---

7.4 安定性OSの実装ガイド（具体編）

実務でやるべきことをまとめる。

1. Role Memory を定義する

エージェントごとに

role:
  - architect
    rules: [...]
  - analyst
    rules: [...]

のように定義する。

2. タスクは必ず外部化する

LLMには「API仕様」を渡すだけ。

task:
  generate_video(...)
  send_email(...)
  run_sql(...)

実行はすべてMCPなどの外部。

3. 状態は"自然言語"で扱わない

• ファイルの存在
• ステータス
• DB値

は自然言語ではなく 構造化データ で返す。

{
  "status": "success",
  "path": "/tmp/video.mp4"
}

4. 推論を過去に移す（レポート化）

• 分析
• 線形計算
• 分類
• 重要語抽出

はすべてバッチで先にやる。

5. LLMは「読む→判断→タスク選択」だけを行う

これだけで、安定は9割決まる。

---

7.5 この章のまとめ

• ✔ エージェントが壊れる原因は"構造"にある
• ✔ 文脈・実行・時間の混在がすべての事故の源
• ✔ 文脈は Role Memory で固定する
• ✔ 実行は外部に出す（AIは考えるだけ）
• ✔ 推論は未来ではなく過去に押し込め
• ✔ 3層を揃えれば、エージェントは壊れない

---

次章：エージェントOSの統合

Role / Memory / Task / Reportsを一つの「OS」として設計する

---

Last Updated: 2025-12-07