Skip to main content

​
グラフエンジニアリング（2026年）とFIM One

業界の議論では、しばしばループエンジニアリング（単一のエージェントが繰り返し思考と行動を行う）からグラフエンジニアリング（マルチノードトポロジーを明示的なエンジニアリングオブジェクトにする）への転換が取り上げられます。このラベルは新しいものですが、実践は新しくありません。LangGraphスタイルのシステムとマルチエージェント組織は、数年前からグラフを使用しています。FIM Oneにとって重要なのは、人々が意図するグラフの種類と、それが3つの実行レイヤーにどのようにマッピングされるかです。

​
グラフエンジニアリングが通常意味すること

そのフレーミング全体でのコンセンサス：グラフはループを置き換えない。グラフ設計はプロセス間の関係を設計します。各エージェントノードは依然として完全なループを実行する可能性があります。 「グラフ」は実際には過負荷です。3つの用法が混在しています： このページは最初の2つ（オーケストレーション）についてです。

​
「Difyワークフローの新しい名前」ではない

Difyスタイルのビジュアルワークフローとグラフエンジニアリングは共通の起源（明示的なトポロジー）を持ちますが、同じ製品ではありません。 短縮形：クラシックワークフローは決定論的（または半決定論的）パイプで時々LLMステップが入ります。グラフエンジニアリングはマルチノードシステムトポロジーで、重要なポストは依然として自律的な智能体となります。

​
FIM Oneでの業界マップの位置付け

FIM Oneはすでに制御スペクトラム全体にまたがっており、チャット「Planner mode」はそのうちの一部に過ぎません。

​
グラフエンジニアリング vs FIM One DAG (チャットプランナー)

同じファミリー(明示的なマルチステップトポロジー)。異なる種族。 含意: グラフエンジニアリング周辺の業界の関心はグラフ/スケジューリングエンジンの維持を検証します。これはユーザーがすべてのターンで「プランナー」を選ぶことを強制するチャットデフォルトを必要としません。ほとんどのタスクは依然として強力なループを望みます。グラフは並列ブランチ、固定コンプライアンスパス、マルチロールオーケストレーションで価値を発揮します。

​
FIM One が学べること（ReAct、DAG、Workflow を強化）

具体的な成果。スローガンではなく。レバレッジ順に整理。 「グラフをやる」ときに避けるべきアンチパターン：
  • 人間の状態機械 をシミュレートするために 依存グラフ を使用（待機プリミティブなしの複数ステップ「回答待ち」）。
  • ReAct の update_plan（チェックリストメモリ）をグラフエンジニアリング（スケジューリングトポロジー）と同一視。
  • グラフ機能を エンジン構成 ではなく、第二のチャット人格として出荷（ループは外側、必要に応じてスケジュールは内側）。
  • FIM One DAG ステップを「浅い LLM 呼び出し」と説明：エンジンを過小評価し、プロダクト判断を誤解させる。

​
AIツーリングランドスケープにおける5つの「計画」

「計画」という言葉は多義的です。今日、少なくとも5つの異なるアプローチが存在し、それぞれが異なる問題を解決しています： 最初の2つは設計時計画です——作業開始前に計画を生成し、人間（またはモデル自体）がそれをステップバイステップで実行します。最後の3つはランタイム計画を導入します——実行グラフはプログラム的に生成・スケジュールされ、独立したブランチが並列で実行されます。違いは誰が実行するかです：Claude Code Teamsは自律エージェントを生成し、FIM One DAGは単一オーケストレータ内のステップをディスパッチします。 これらのアプローチは競合ではなく、補完的なレイヤーです。Kiro形式の仕様は何を構築するかを定義でき、FIM One DAGはサブタスクを並行してどのように実行するかをスケジュールできます。Claude Codeの計画モードは人間がアプローチに同意することを保証し、FIM Oneの PlanAnalyzerは結果を自動的に検証します。

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

Claude Code TeamsとFIM One DAGは、フル容量で動作する場合、三層ネスティングアーキテクチャを示します：
  • レイヤー1 — ヒューマンゲート：ユーザーが計画をレビューし、実行開始前に承認します。
  • レイヤー2 — DAGオーケストレーション：承認された計画は依存関係エッジを持つタスクに分解されます。独立したタスクは並列実行され、ダウンストリームタスクはブロッカーの解決を待ちます。
  • レイヤー3 — ReAct内部ループ：各タスクは完全なReAct サイクル（認識 → 推論 → 行動 → 観察）を実行するエージェントによって実行され、マルチステップ推論、ツール使用、自律的な再試行が可能です。
重要な洞察：Claude Code TeamsとFIM One DAGは同じ三層を実装していますが、レイヤー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 ステップはすでに完全な ReAct エージェント — レイヤー3 は理想ではなく現実です。各ステップは agent.run() をツールと複数反復ループで実行します。トップレベルの ReAct チャットターンとの違いは意図的です（ステップごとのプランボードなし、チャットレベルの ask_user_question 待機なし、model_hint / 一般的なデフォルトで選択されたモデル）。
要点： 同じエージェント本質、収束する並列哲学。Claude Code は チームコラボレーション モデルに従います — リーダーがワーカーにタスクを委譲し、ワーカーはメッセージで通信します。FIM One は パイプラインスケジューリング モデルに従います — DAG エグゼキューターが依存関係解決に基づいて ReAct ステップ をディスパッチします。実際には、両者とも依存関係駆動の並列実行を実装しています。違いは調整オーバーヘッド（メッセージ対エッジ）、分離（ピアエージェント対タスク＋依存関係結果）、トークン経済学です。製品ギャップは「ノードをエージェントにする」というより、グラフをスケジュールするか 1 つのチャットループに留まるか、および グラフが一時停止できない場所での人間待機エッジ です。

​
構造化出力の段階的低下

DAGパイプライン内のすべての構造化LLM呼び出しサイト（Planner、Analyzer、Tool Selection）は、3段階の低下チェーンを実装する統一されたstructured_llm_call()ユーティリティを使用します： 各テキストベースのレベルは、次のレベルに低下する前に、再フォーマットプロンプトで1回再試行します。結果は、解析された値、抽出が成功したレベル、および累積トークン使用量を含むStructuredCallResultです。 この設計により、同じプロンプトがGPT-4（Native FC）、Claude（JSONモード）、ローカルモデル（プレーンテキスト）全体で確実に機能し、4つの呼び出しサイト全体に分散するのではなく、1つの場所で一貫したエラーハンドリングと再試行ロジックが実現されます。

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

上記の5つの計画アプローチはランドスケープを説明しています。FIM One自体では、3つの実行レイヤーが完全な人間制御から完全なAI自律性までの制御スペクトラムを提供します。グラフエンジニアリングに関連して：Workflowはデザイン時のグラフプロダクト、DAGPlannerはランタイムタスクグラフ、ReActはループエンジニアリング（オプションのプラン・ボード・メモリ付き、スケジュールグラフではない）です。 設計原則：ユーザーが望む正確な量の制御を提供する。
  • すべてのローン承認が5つの特定のステップを通過することを証明する必要がある？ → Workflow。
  • 3つのトピックを並列で調査してから統合する必要がある？ → DAG。
  • 実行中にドラフト、改善、または構造化された質問をする必要がある？ → ReAct。
  • 不確かな場合？ → execution_mode: "auto"がクエリを分類し、ランタイムでDAGまたはReActにルーティングします（目標が主に明確化または短い探索の場合はReActを優先）。
このレイヤリングがFIM Oneを単一パラダイムツールから区別するものです：
  • DifyはWorkflowレイヤーを強調しています（静的または半静的なビジュアルグラフ）。
  • LangGraphはコードレベルの制御フローグラフDSLを強調しています（開発者定義のトポロジー、動的ルーティング、チェックポイント）。構造的にはビジュアルワークフローに関連していますが、ソフトウェアとして表現されています。
  • Manus級エージェントはエージェント/ループレイヤーを強調しています（自律実行、ユーザー定義構造が少ない）。
FIM Oneは3つのレイヤーすべてをカバーしており、さらにチャットエンジン間の自動ルーティングも行います。ユーザー定義グラフ → LLM生成タスクグラフ → スケジュールグラフなしの進行は、より広い業界の誠実さと一致しています：モデルが改善するにつれて、明示的なトポロジーはほとんどのターンでは必須UIではなく、オプションになります。グラフエンジニアリングの熱は、すべてのチャットをプランナーを通して強制することではなく、エンジンと構成への投資の理由です。

​
関連ドキュメント

  • ReAct Engine — ループ、ツール、プランボード、明確化質問
  • DAG Engine — プランナー、エグゼキューター、アナライザー、リプラン
  • Competitive Landscape — Dify / Manus / Coze ポジショニング