Skip to main content

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

「計画」という言葉は過負荷状態にあります。今日、少なくとも5つの異なるアプローチが存在し、それぞれが異なる問題を解決しています: 最初の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層ネストされたアーキテクチャを示します：
  • レイヤー1 — ヒューマンゲート：ユーザーが計画をレビューし、実行開始前に承認します。
  • レイヤー2 — DAGオーケストレーション：承認された計画は依存関係エッジを持つタスクに分解されます。独立したタスクは並列実行され、ダウンストリームタスクはブロッカーの解決を待ちます。
  • レイヤー3 — ReAct内部ループ：各タスクは完全なReAcycleを実行するエージェント（Perceive → Reason → Act → Observe）によって実行され、マルチステップ推論、ツール使用、自律的な再試行が可能です。
重要な洞察：Claude Code TeamsとFIM One DAGは同じ3つのレイヤーを実装していますが、レイヤー2のメカニクスが異なります — メッセージパッシング対依存関係エッジ解決。

​
フルパワーランタイム: FIM One vs Claude Code Teams

どちらも本物のエージェント — コアループは同じです: 認識 → 推論 → 行動 → フィードバック。違いは、フル容量で並列作業をどのようにオーケストレーションするかにあります。

​
実世界ベンチマーク: 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() ユーティリティを使用します： 各テキストベースのレベルは、次のレベルに低下する前に、リフォーマットプロンプトで 1 回再試行します。結果は、解析された値、抽出が成功したレベル、および累積トークン使用量を含む StructuredCallResult です。 この設計により、同じプロンプトが GPT-4（ネイティブ FC）、Claude（JSON モード）、ローカルモデル（プレーンテキスト）全体で確実に機能し、4 つの呼び出しサイト全体に散在するのではなく、1 か所で一貫したエラーハンドリングと再試行ロジックが実現されます。

​
3つの実行レイヤー：制御スペクトラム

上記の5つの計画アプローチはランドスケープを説明しています。FIM One自体では、3つの実行レイヤーが制御スペクトラムを提供します — 完全な人間制御から完全なAI自律性まで： 設計原則：ユーザーが望む正確な量の制御を提供する。
  • すべてのローン承認が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生成グラフ → グラフなし — はより広い業界トレンドを反映しています：モデルがより高度になるにつれて、明示的なオーケストレーション構造は必須ではなくオプションになります。