Documentation Index
Fetch the complete documentation index at: https://docs.fim.ai/llms.txt
Use this file to discover all available pages before exploring further.
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）によって実行され、マルチステップ推論、ツール使用、自律的な再試行が可能です。
重要な洞察：Claude Code TeamsとFIM One DAGは同じ3つのレイヤーを実装していますが、レイヤー2のメカニクスが異なります — メッセージパッシング対依存関係エッジ解決。
フルパワーランタイム: 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 は計算コストを開発者時間と交換します。
収束、競争ではなく
「チーム協働」と「パイプラインスケジューリング」の境界がぼやけています：
- Claude Code Teamsの
blockedBy/blocksはDAGです — タスクは明示的な依存関係エッジを持ち、リーダーは先行タスクが完了すると新たにブロック解除されたタスクをディスパッチします。これはトポロジカルスケジューリングに追加のステップ（メッセージ）を加えたものです。
- FIM OneのDAGはエージェント自律性から恩恵を受ける可能性があります — ステップごとの単一LLM呼び出しの代わりに、各ステップで完全なReACtループを実行させることで、複雑なサブタスクをより適切に処理できます。
要点： 同じエージェント本質、収束する並列哲学。Claude Codeはチーム協働モデルに従います — リーダーがワーカーに委譲し、ワーカーはメッセージを介して通信します。FIM Oneはパイプラインスケジューリングモデルに従います — DAG実行器が依存関係解決に基づいてステップをディスパッチします。実際には、両者とも依存関係駆動型の並列実行を実装しています。違いはコーディネーションオーバーヘッド（メッセージ対エッジ）とトークン経済学（分離されたコンテキスト対共有メモリ）です。最適なアーキテクチャは両者を組み合わせたものになる可能性があります：構造化されたパイプライン用のDAGスケジューリング、自律的な複数ステップの推論が必要なタスク用のエージェントプール。
構造化出力の段階的低下
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 か所で一貫したエラーハンドリングと再試行ロジックが実現されます。
3つの実行レイヤー：制御スペクトラム
上記の5つの計画アプローチはランドスケープを説明しています。FIM One自体では、3つの実行レイヤーが制御スペクトラムを提供します — 完全な人間制御から完全なAI自律性まで：
| レイヤー | グラフの定義者 | グラフが存在する時期 | 最適な用途 |
|---|
| Workflow Engine | ユーザー（ビジュアルキャンバス / JSONブループリント） | 設計時 | 決定論的プロセス、コンプライアンス/監査証跡、cronスケジュール自動化、非AI オーケストレーション |
| DAGPlanner | LLM（目標を自動分解） | ランタイム | 明確なサブタスク境界を持つ分解可能なマルチステップタスク |
| ReAct Agent | なし（反復ループ） | なし — グラフなし | 探索的、会話的、または反復的改善タスク |
- すべてのローン承認が5つの特定ステップを通過することを証明する必要がある？ → Workflow。
- 3つのトピックを並列で調査してから統合する必要がある？ → DAG。
- 満足するまでドラフトと改善を繰り返す必要がある？ → Agent。
- 不確実な場合？ →
execution_mode: "auto"により、LLMがクエリを分類し、ランタイムでDAGまたはReActにルーティングします。
このレイヤリングがFIM Oneを単一パラダイムツールから区別するものです：
- DifyはWorkflowレイヤーのみを提供します（静的ビジュアルDAG）。
- LangGraphはコードレベルのグラフDSLのみを提供します（開発者定義トポロジー、動的ルーティング — 構造的にはビジュアルワークフローと同等ですがPythonが必要）。
- ManusはAgentレイヤーのみを提供します（自律実行、ユーザー定義構造なし）。
FIM Oneは3つのレイヤーすべてをカバーし、さらにそれらの間の自動ルーティングを提供します。抽象化の進行 — ユーザー定義グラフ → LLM生成グラフ → グラフなし — はより広い業界トレンドを反映しています：モデルがより高度になるにつれて、明示的なオーケストレーション構造は必須ではなくオプションになります。
