第5章：タスクOS ― MCPで"実行"を思考から追放する

— LLMは「判断する存在」であり、「実行する存在」ではない。

エージェントが破綻するパターンの8割はこうだ：

AIが自分で考え、自分で実行し、自分で修正しようとする

つまり "思考" と "実行" を分離していない。

これを構造から禁止するのが、タスクOS（Layer4）の役割である。

---

5.1 なぜ"実行"をAIにやらせてはいけないのか？

理由は3つある。

① AIは「実行の前提条件」を評価できないから

LLMは世界の状態を観測できない。

• APIレスポンス
• ファイルの存在
• 入力の欠損
• 状態遷移の未完了

こうした"現実の状態"を推測で補完しようとして暴走する。

---

② AIは「自分の誤解」に気づけないから

LLMの最大の弱点：

自分の誤解を誤解だと判断する"メタ認知"がない

だから一度間違うと：

誤解 → 間違った次のステップ → 誤解の補正 → さらに悪化 → ループ

Predict → Error → Self-fix のループが暴走。

---

③ 実行は例外処理だらけで、AIが扱えないから

実行は "予期しない入力"が常に発生する世界。

• APIが落ちた
• 引数が足りない
• レイテンシが異常
• ファイルが壊れている
• 一つ前のタスクが未完了
• ネットワーク障害発生

例外処理はパターン化できない。

これをLLMに任せるのは 構造的に不可能。

---

5.2 タスクは「LLMではなくOSが扱う」もの

エージェントOSの中心思想は：

AIは考えるだけ。実行はOSがやる。

これは"AIを弱くする思想"ではない。

実行を外に押し出すことで：

• AIの文脈が純度を保つ
• 判断の再現性が高まる
• 破綻確率が激減する
• 例外処理をコードで書ける
• デバッグしやすくなる

つまり AIが強くなるために、実行を奪う。

---

5.3 MCP / Tools / タスクAPI の正しい設計思想

タスクOSは以下の構成で成立する：

LLM（判断専用）
   ↓ "どのタスクを使うべきか" を選ぶ
TaskRouter（OS）
   ↓ 実行
Task Worker / MCP / API（実行専用）

この3層に分離すると、エージェントは一気に安定する。

---

5.4 タスクテンプレートの構造（標準化）

タスクは「関数」ではない。 状態機械（State Machine）の1ステップ である。

テンプレートの正しい構造はこれ：

{
  "task_name": "search_flights",
  "description": "航空便の空きを検索する",
  "input_schema": {
    "departure": "string",
    "arrival": "string",
    "date": "YYYY-MM-DD"
  },
  "output_schema": {
    "status": "success | error",
    "flights": "Flight[]?",
    "error_reason": "string?"
  }
}

ポイント：

• 入力・出力が固定
• 成功 / 失敗を必ず返す
• 例外処理はワーカー側
• LLMは「選ぶだけ」で良い

---

5.5 LLMをタスクに"触らせない"ことが安定の源

AIがやることは TaskRouterへの指示。

例：

- 現在地Aから目的地Bへの最短ルート検索が必要
 → use(search_route)

- ホテル候補を絞る必要がある
 → use(fetch_hotels)

- 予算を超過した
 → use(update_budget)

そして重要なのは：

タスクの内部ロジックはLLMに見せない。伝えるのはタスクの存在と目的だけ。

これにより文脈が混ざらない。

---

5.6 タスクOSが防ぐ「よくある破綻パターン」

破綻1：AIが独自の手順を発明する

例：「まずAをやって、そのあとBして……」

タスクOS： → 禁止 → LLMは"どのタスクを呼ぶか"だけ判断

---

破綻2：エラーが返ってきたら"勝手に修正"しようとする

タスクOS： → 修正は全てワーカー → LLMには "エラーの意味" だけ伝える

---

破綻3：中間生成物が混ざり文脈崩壊

タスクOS： → 状態管理はOS → LLMは"状態を読むだけ"

---

破綻4：ループしてコスト爆増

タスクOS： → OSがループ回数や再試行を管理 → LLMは1ターンの判断しかしない

---

5.7 タスクは「人間の筋力をLLMに渡す」行為である

タスクとは、以下のような "人間の筋力" をAIに提供することだ。

• DB操作
• ファイル生成
• 検索
• APIコール
• 予約・決済
• 監視・通知

AIは判断だけ。 筋力（実行）はマシン。

この分離こそが エージェントの安全性・再現性・信頼性の源泉。

---

5.8 タスクOSの実装手順（実務用）

① タスク一覧を棚卸しする

目的達成に必要な機能を全部出す。

② タスクにIDを振り、input/outputを固定する

LLM用に整形。

③ 例外処理をすべてワーカーに移す

AIに例外処理をさせない。

④ 状態管理はOS（メタレイヤ）に出す

LLMはただ読むだけ。

⑤ LLMには「タスクを選ぶ権限だけ」を渡す

この構造が AIを最も強くする"人間的OS"。

---

5.9 この章のまとめ

• ✔ 実行は危険。AIにやらせてはいけない
• ✔ タスクはワーカー、LLMは判断専用
• ✔ MCPは "思考と実行の分離" を実現する道具
• ✔ タスクは状態機械の1ステップ
• ✔ LLMは「どのタスクを使うか」だけ判断
• ✔ 実行を奪うほど、エージェントは強くなる

---

次章：レポートOS ― 推論を「未来」から「過去」へ移す

第6章では、非創発タスクをレポート化し、推論コストとレイテンシをゼロにする構造を解説する。

---

Last Updated: 2025-12-07