第3章：タスク外部化とテンプレート設計
― "AIに全部やらせようとする" ほどエージェントは壊れやすくなる
エージェント設計の話をすると、よく次のようなフレーズを耳にする。
- 「計画 → 実行 → 検証 のループをAIに任せるべき」
- 「タスク分解をAI自体にやらせる」
- 「AI同士で役割分担して進める」
理想的に聞こえるが、実務ではほとんどうまくいかない。 理由は単純で、LLMは"判断"と"手順"が混ざると性能が急激に落ちるからだ。
判断（文脈）と、実行（タスク）は別物である。 それを区別しない限り、エージェントは必ず揺らぐ。
AIが苦手なのは「手順」そのもの
LLMは"思考の文脈"を扱うことは得意だが、 "実行の文脈"は苦手だ。
実行とは、例えば次のようなものだ：
- APIを呼び出す
- データを取得する
- 値を計算する
- ファイルを作る
- 外部へ書き込む
これらには
- 正確な手順
- 厳密なパラメータ
- 決まった順番の操作
- 例外処理
といった「手続き的複雑性」が含まれる。
LLMの内部構造は、これとまったく相性が良くない。
するとどうなるか？
- 判断基準がタスクで汚染される。
- タスク実行が判断で揺れる。
"どっちの文脈か分からない状態"になり、 エージェントは不安定な挙動を示し始める。
では、どうすれば安定するか？
答えはシンプルで、
タスクはすべて外に出す。AIエージェントには判断だけを残す。
具体的には：
- API呼び出し → MCP（ツール）側で定義
- 分析 → テンプレート化した関数群で定義
- ファイル生成 → 外部サービスに切り出す
- 実行シーケンス → システム側で制御する
AIエージェントは「それを使うべきかどうか」を判断するだけでいい。
タスクのテンプレート化 ― "外に出す"ための構造
タスクを外部化するといっても、ただバラバラにツールを並べると扱いにくい。 そこで有効なのが タスクテンプレート である。
テンプレートとは、
- 何ができるか
- どんな入力を受け取るか
- どんな出力を返すか
- 何を保証するか（制約）
- エラー時はどう振る舞うか
といった「実行のインターフェース」を決めたもの。
AIが行うのは、
"どのテンプレートを使うべきか" の判断だけ。
実務で最も安定する構造は、 AIが 「実行の選択」 を行い、 具体的な 「実行の中身」 はすべてテンプレート（MCP）に任せる構造だ。
タスクを外部化すると何が起きるか
メリットは驚くほど大きい。
1. エージェントが揺れなくなる
判断の文脈が濁らないため、一貫した出力が出る。
2. コストが読める
外部タスクは料金と性能が固定される。暴走の心配がない。
3. デバッグができる
タスク実行がMCP側に切り出されているので、再現性が高い。
4. マイクロサービス的に組める
エージェントの中身を変えずに、外側のテンプレートを差し替えられる。
5. 組織のナレッジとして再利用できる
タスクテンプレートはコードとして資産化し、全チームで使える。
6. 運用者が安心する
LLMが勝手に外部サービスを叩かないため、監査・ガバナンスが通る。
これは実務での大きな武器になる。
判断が純度を保つと、エージェントは強くなる
判断（文脈）は濁らせてはいけない。
- 価値基準
- 役割
- 制約
- 優先順位
これだけがエージェントに残る。
タスク（実行）は
- MCP
- API
- パイプライン
- 外部ワーカー
- テンプレート
に追い出す。
この分離こそが、AIシステムを安定させる"原則"だ。
この章のまとめ
- LLMは"手順"が混ざると性能が落ちる
- 判断と実行は混ぜてはいけない
- タスクは外部化し、テンプレートに落とし込む
- AIは"使うべきタスクを選ぶ"だけでよい
- 文脈の純度が高まり、エージェントが安定する
次章（第4章）は、さらに具体的に
エージェントに何を書き、何を書かないか（プロンプト設計）
を扱う。
Last Updated: 2025-12-04