AI ツーリング環境における5つの「計画」
「計画」という言葉は過負荷状態にあります。今日、少なくとも5つの異なるアプローチが存在し、それぞれが異なる問題を解決しています:| アプローチ | 計画形式 | 実行 | 承認 | コア価値 |
|---|---|---|---|---|
| 暗黙的モデル計画 | 内部思考の連鎖 | 単一推論パス | なし | モデルが独自にステップを考える |
| Claude Code計画モード | Markdownドキュメント | 順序実行 | 実行前に人間がレビュー | 実行前にアプローチを合意 |
| Claude Code Teams | 依存関係エッジ付きタスクリスト | 並行実行（マルチエージェント） | 人間が計画を承認、その後自律実行 | 動的エージェントプール + 並列実行 |
| Kiro仕様駆動開発 | 構造化仕様（要件 + 設計 + タスク） | 順序実行 | 人間が仕様をレビュー | トレーサブルな要件、受け入れ基準 |
| FIM One DAG | JSON依存グラフ | 並行実行（単一オーケストレーター） | 自動（PlanAnalyzer） | 並列実行 + ランタイムスケジューリング |
3層ネスティング：フルパワーアーキテクチャ
Claude Code TeamsとFIM One DAGは、フル容量で、3層ネストされたアーキテクチャを示します：- レイヤー1 — ヒューマンゲート：ユーザーが計画をレビューし、実行開始前に承認します。
- レイヤー2 — DAGオーケストレーション：承認された計画は依存関係エッジを持つタスクに分解されます。独立したタスクは並列実行され、ダウンストリームタスクはブロッカーの解決を待ちます。
- レイヤー3 — ReAct内部ループ：各タスクは完全なReAcycleを実行するエージェント（Perceive → Reason → Act → Observe）によって実行され、マルチステップ推論、ツール使用、自律的な再試行が可能です。
フルパワーランタイム: FIM One vs Claude Code Teams
どちらも本物のエージェント — コアループは同じです: 認識 → 推論 → 行動 → フィードバック。違いは、フル容量で並列作業をどのようにオーケストレーションするかにあります。| 次元 | Claude Code Teams | FIM One DAG |
|---|---|---|
| 並列モデル | リーダーがサブエージェントを生成し、メッセージ経由でタスクを割り当てる | トポロジカルソートが独立したステップを自動並列化 |
| タスクグラフ | blockedBy / blocks エッジを持つTaskList（動的DAG） | depends_on エッジを持つ静的JSON DAG |
| 調整 | 明示的なメッセージパッシング（SendMessage / Broadcast） | 暗黙的な依存関係エッジ — メッセージなし、データフローのみ |
| エージェントライフサイクル | 動的プール — エージェントはオンデマンドで生成、完了時にシャットダウン | 固定ステップエグゼキューター — ステップごとに1つのLLM呼び出し |
| フィードバックと修正 | 各サブエージェントが自律的に再試行; リーダーが失敗時に再割り当て | PlanAnalyzerが結果を評価 → 再計画ループ（最大3ラウンド） |
| 人間の関与 | プランモード承認、その後自律実行 | 完全自動 — PlanAnalyzerが合格/再計画を決定 |
| コンテキスト管理 | 各サブエージェントが分離されたコンテキストウィンドウを取得（相互汚染なし） | すべてのステップ間で共有DbMemory + LLM Compact |
| トークン経済 | N エージェント × エージェントあたりトークン — 時間↓ トークン↑（乗法的コスト） | 順序実行または浅い並列化 — 低い総トークン |
| スケーリングパターン | より多くのサブエージェントを追加（水平、メッセージ結合） | より多くのDAGブランチを追加（水平、依存関係結合） |
| 最適な用途 | 多様で疎結合なタスク（リサーチ + コード + テスト） | 明確なデータ依存関係を持つ構造化ワークフロー |
実世界ベンチマーク: v0.5 RAG システム
Claude Code Teams は FIM One の v0.5 RAG サブシステム全体を単一セッションで構築しました:- 8 フェーズ: Embedding → Reranker → Loaders → Chunking → VectorStore → Retrieval → KB Backend → Frontend + Docs
- 46 テスト合格、フロントエンドビルドクリーン
- 実行時間: 約 5 分
- トークンコスト: エージェントタスクあたり約 100k トークン × 8+ タスク ≈ 800k+ 総トークン
- 依存関係エッジ: フェーズ 5 はフェーズ 4 + 1b に依存; フェーズ 6 はフェーズ 5 + 2 + 3 に依存 — 本物の DAG
収束、競争ではなく
「チーム協働」と「パイプラインスケジューリング」の境界がぼやけています：- Claude Code Teamsの
blockedBy/blocksはDAGです — タスクは明示的な依存関係エッジを持ち、リーダーは先行タスクが完了すると新たにブロック解除されたタスクをディスパッチします。これはトポロジカルスケジューリングに追加のステップ（メッセージ）を加えたものです。 - FIM OneのDAGはエージェント自律性から恩恵を受ける可能性があります — ステップごとの単一LLM呼び出しの代わりに、各ステップで完全なReACtループを実行させることで、複雑なサブタスクをより適切に処理できます。
構造化出力の劣化
DAG パイプライン内のすべての構造化 LLM 呼び出しサイト (Planner、Analyzer、Tool Selection) は、3 レベルの劣化チェーンを実装する統一されたstructured_llm_call() ユーティリティを使用します:
| レベル | 条件 | 動作方法 |
|---|---|---|
| Native FC | llm.abilities["tool_call"] | 仮想ツール呼び出しを強制; tool_calls[0].arguments から抽出 |
| JSON Mode | llm.abilities["json_mode"] | response_format={"type":"json_object"} を設定; extract_json() で解析 |
| Plain text | 常に利用可能 | extract_json() で自由形式コンテンツを解析、その後オプションで regex_fallback() |
StructuredCallResult です。
この設計により、同じプロンプトが GPT-4 (ネイティブ FC)、Claude (JSON モード)、ローカルモデル (プレーンテキスト) 全体で確実に機能し、4 つの呼び出しサイト全体に分散するのではなく、1 つの場所に一貫したエラーハンドリングと再試行ロジックが集約されます。