> ## 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 つの計画の種類と FIM One がどこに適合するか。

## AI ツーリング環境における5つの「計画」

「計画」という言葉は過負荷状態にあります。今日、少なくとも5つの異なるアプローチが存在し、それぞれが異なる問題を解決しています:

| アプローチ                 | 計画形式                 | 実行                    | 承認               | コア価値                 |
| --------------------- | -------------------- | --------------------- | ---------------- | -------------------- |
| **暗黙的モデル計画**          | 内部思考の連鎖              | 単一推論パス                | なし               | モデルが独自にステップを考える      |
| **Claude Code計画モード**  | Markdownドキュメント       | 順序実行                  | 実行前に人間がレビュー      | 実行前にアプローチを合意         |
| **Claude Code Teams** | 依存関係エッジ付きタスクリスト      | **並行実行**（マルチエージェント）   | 人間が計画を承認、その後自律実行 | 動的エージェントプール + 並列実行   |
| **Kiro仕様駆動開発**        | 構造化仕様（要件 + 設計 + タスク） | 順序実行                  | 人間が仕様をレビュー       | トレーサブルな要件、受け入れ基準     |
| **FIM One DAG**       | JSON依存グラフ            | **並行実行**（単一オーケストレーター） | 自動（PlanAnalyzer） | 並列実行 + ランタイムスケジューリング |

最初の2つは**設計時**計画です — 作業開始*前*に計画を生成し、人間（またはモデル自体）がそれに従ってステップバイステップで進めます。最後の3つは**ランタイム**計画を導入します — 実行グラフはプログラム的に生成・スケジュールされ、独立したブランチが並列で実行されます。違いは*誰が*実行するかです: Claude Code Teamsは自律エージェントを生成し、FIM One DAGは単一オーケストレーター内のステップをディスパッチします。

これらのアプローチは競合ではなく、相互に補完的なレイヤーです。Kiro形式の仕様は*何を*構築するかを定義でき、FIM One DAGはサブタスクを並行して*どのように*実行するかをスケジュールできます。Claude Codeの計画モードは人間がアプローチに同意することを保証し、FIM OneのPlanAnalyzerは結果を自動的に検証します。

## 3層ネスティング：フルパワーアーキテクチャ

Claude Code TeamsとFIM One DAGは、フル容量で、**3層ネストされたアーキテクチャ**を示します：

```mermaid theme={null}
flowchart TB
    subgraph L1["Layer 1: Human-in-the-Loop"]
        direction TB
        H["User approves plan / confirms direction"]

        subgraph L2["Layer 2: DAG Orchestration"]
            direction TB
            D1["Task graph with dependency edges"]
            D2["Parallel dispatch of independent branches"]
            D1 --> D2

            subgraph L3A["Layer 3: ReAct Loop"]
                R1["Perceive → Reason → Act → Observe"]
            end

            subgraph L3B["Layer 3: ReAct Loop"]
                R2["Perceive → Reason → Act → Observe"]
            end

            subgraph L3C["Layer 3: ReAct Loop"]
                R3["Perceive → Reason → Act → Observe"]
            end

            D2 --> L3A & L3B & L3C
        end

        H --> L2
    end
```

* **レイヤー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()` を実行します       |

各テキストベースのレベルは、次のレベルに低下する前に、リフォーマットプロンプトで 1 回再試行します。結果は、解析された値、抽出が成功したレベル、および累積トークン使用量を含む `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生成グラフ → グラフなし — はより広い業界トレンドを反映しています：モデルがより高度になるにつれて、明示的なオーケストレーション構造は必須ではなくオプションになります。