マルチエージェントシステムのためのグラフエンジニアリング：アーキテクチャ、ガバナンス、オブザーバビリティ

2026年7月18日、 explainx.aiの記事 は、「グラフエンジニアリング」をめぐる急速な議論を統合しました。これは、マルチエージェント組織（役割、依存関係、委任パス、ランタイムのタスク構造）を、設計されたグラフとして扱うという考え方です。この名称の由来は定かではなく、既存のナレッジグラフの用法と混同されることもありますが、その根底にある「グラフベースのオーケストレーション」という手法には、確立された系譜があります。

作業定義：グラフエンジニアリングは、 トポロジー を設計するものです。マルチエージェントシステムにおいて、どのノード（エージェント、決定論的関数、ルーター、人間のチェックポイント）が存在し、どの遷移が許可され、ランタイムのワークグラフがどのように形成・変化するかを定義します。一方、ループエンジニアリングは、各エージェントノードが実際にどのように実行されるかを設計します。

本稿のエンタープライズ向けテーゼ：オーケストレーターがグラフを所有し、TrueFoundryがゲートウェイを通じてルーティングされるモデルおよびMCPツールの運用を統制し、Agent Harnessエージェントのためのマネージドランタイムを提供します。製品の境界については後述します。

‍

グラフエンジニアリングとは何か？その定義

グラフエンジニアリングとは、マルチエージェントシステムを、異種混合ノード（エージェント、決定論的関数、ルーター、結合、ツール、人間のチェックポイント）からなる明示的なグラフとして設計・運用することです。通信や委任をエッジとし、トポロジーそのもの（誰が存在し、何を所有し、誰と誰が対話でき、作業がどうルーティングされるか）を、偶発的な結果ではなく、プログラム可能でバージョン管理可能な成果物として扱います。前述の記事の所有権の例がこれを具体的に示しています。認証・権限・監査ログを所有するセキュリティエージェント、スキーマと移行を所有するデータエージェント、エンドポイントと契約を所有するAPIエージェント、コンポーネントと状態を所有するフロントエンドエージェント。それぞれが使命を持つノードであり、その構造自体が設計対象である組織に組み込まれています（explainx.ai）。読者や検索エンジン経由で訪れた方のために、一つ明確にしておくべきことがあります。これは ナレッジグラフエンジニアリングではありません 。ナレッジグラフエンジニアリングは、検索や推論のためにグラフ構造化データ（エンティティ、関係、トリプルストア）を構築する確立された学問です。ナレッジグラフはシステムが 何を知っているかを構造化するのに対し、2026年におけるグラフエンジニアリングは、システムが 何者であるか 、つまりそのメンバー、使命、メッセージパスを構造化するものです。これら二つは一つのアーキテクチャ内で共存可能であり、それぞれ異なる問いに答えるものです。

グラフエンジニアリングの歴史：データフローとDAGからマルチエージェント組織まで

新しい用語には、その背景となる歴史が存在します。この用語には非常に豊かな系譜があり、それを辿ることは、この実践が今後どのように定着していくかを予測する上で有益です。その最も深い根源にあるのは、次のような直感です。 計算とはグラフである初期のデータフローアーキテクチャはハードウェアのレベルでこの概念を探求し、その後、作業の分解とスケジューリングが必要とされるあらゆる場面で再浮上しました。コンパイラの依存関係グラフ、MapReduceの暗黙的なDAG、そしてエンジニアの世代が慣れ親しんだツールへと引き継がれました。AirflowのようなワークフローオーケストレーターはDAGをデータエンジニアリングの単位とし、ディープラーニングのフレームワークは計算グラフをモデル実行の単位としました。第二の根源はさらに古く、本質に近いものです。それは数十年にわたるマルチエージェントシステムの研究です。アクターモデルによる計算は、独立したアクターがメッセージを交換する様子をモデル化しました。コントラクトネットプロトコルでは、エージェントが入札を行い、タスクを委譲していました。これは「ワークグラフ」という言葉が生まれるずっと前の話です。分散AIコミュニティは、エージェントの通信と組織化のための語彙を構築しましたが、それは今日、現在構築されているシステムの設計ドキュメントのように読めます。第三の根源は組織的なものです。組織図、RACIマトリックス、ビジネスプロセス表記法はすべて、誰が何を所有し、どのように業務が流れるかを示すグラフであり、7月18日の記事にある「組織グラフ」は、意図的かどうかにかかわらず、その伝統をソフトウェアに取り入れたものです。現代の収束は急速に進みました。エージェントフレームワークはグラフをコード内の第一級オブジェクトにしました（LangGraphという名前がそれを物語っています。AutoGenやCrewAIはマルチエージェントの会話やチームを構造化しました）。GoogleのA2Aプロトコル（2025年）は、エージェントの発見、タスク管理、メッセージ、アーティファクト、エージェント間の調整のための標準化されたプロトコルを提案しました。これは私たちが以下の記事で検討したレイヤーです。 マルチエージェントガバナンスに関する投稿 2026年半ばまでには、実務者のステップは「プロンプト → コンテキスト → ループ」となり、ループエンジニアリングの6月の統合的な動きが、グラフエンジニアリングの7月の動きに再利用されるテンプレートを提供しました。新しい用語には謙虚さが求められますが、私たちの見解を述べれば、グラフエンジニアリングとは発明ではなく、次のようなものです。 命名イベント 数十年にわたって蓄積されてきた実践が、一つのものとして議論可能になった瞬間です。命名イベントは重要です。なぜなら、そこからツール開発、採用、そして私たちの専門領域である運用に関する議論が始まるからです。

グラフエンジニアリングの立ち位置：プロンプト、コンテキスト、ループエンジニアリング

統合的な記事の進捗テーブルは、この用語を位置づける最も明確な方法であり、そこに一つ加える価値があります。プロンプトエンジニアリングは以下を制御します。 単一のモデル応答そのプリミティブは指示テキストであり、静的で単発のタスクには十分です。コンテキストエンジニアリングは以下を制御します。 モデルが見るものそのプリミティブは検索、メモリ、ウィンドウバジェットです。ループエンジニアリングは以下を制御します。 単一エージェントの行動サイクル 観察・推論・行動・検証のループ、停止条件、ツールの規律などです。これこそが、私たちが二部構成で扱ったテーマの核心です。 第一部 では、ラップトップで動作するループとエンタープライズ環境で実行されるループの違いは、ループそのものではなく、それを取り巻く環境（アイデンティティ、予算、ガードレール、トレース）にあると論じました。そして、 第二部 では、ガバナンスの効いた多数のループが「フリート（艦隊）」を構成すると論じました。これは単なる大きなループではなく、独自の規律を必要とする運用上の課題です。グラフエンジニアリングは、エージェントループ、決定論的な運用、ルーター、結合、ツール、人間のチェックポイントといった異種混合のノード間におけるトポロジーを制御します。つまり、どのノードが存在し、それぞれが何を所有し、どの遷移が許可され、それらの間でどのように業務が流れるかを定義するのです。ここで明確にしておくべき追加点は、これらのレイヤーが 構成する 置き換えるのではなく、補完するものです。ノードのループが適切に設計されていないグラフは、信頼できない従業員で構成された組織図のようなものです。逆に、ループは優れていてもトポロジーが偶然の産物であるグラフは、当社のフリートに関する投稿で警告した「大規模な調整の失敗」を体現するものとなります。グラフエンジニアリングがループエンジニアリングに取って代わるのかという問いに対する答えは「ノー」です。グラフエンジニアリングはループエンジニアリングの上位レイヤーであり、ノード数だけでなく、ファンアウト、リトライ、並行処理、ツール利用、コンテキストサイズ、キャッシュといったトポロジーやランタイムの挙動によって増幅された要件を継承するのです。

エンタープライズにおけるグラフエンジニアリング：ガバナンス、コスト管理、およびオブザーバビリティ

次に、定義の進化にほとんど依存しない部分について説明します。本番環境のマルチエージェントグラフは、エージェント的なコンポーネントと決定論的なコンポーネントを組み合わせたものです。エージェント的な呼び出し元はIDを持ち、モデルやツールを呼び出し、動的なタスクを生成します。その結果生じる運用負荷は、トポロジー、ファンアウト、リトライ、並行処理、およびランタイムの変更に依存します。 ガバナンス： 独立して管理される各呼び出し元やサービスエージェントには、解決可能なIDが必要です。プロセス内の決定論的ノードは、アーキテクチャ上で個別のポリシーや帰属情報の明示が必要でない限り、そのノードを含むサービスのIDで動作させることができます。これには、当社の エージェントIDの調査 で詳述した仮想アカウント、RBAC、ユーザーごとの委任などが該当します。「グラフが勝手にやった」という言い訳は監査の回答として通用しないためです。ゲートウェイを介したモデルリクエストや、グラフから発行されるMCPツール呼び出しにはポリシーが必要です（どのノードがどのツールにアクセスできるかはレジストリ設定で管理します。ツールレベルの制限や、各ノードの権限を制限する仮想MCPサーバーなどがこれにあたります）。また、ゲートウェイを介したモデルリクエストやMCPツール呼び出しには、文書化された4つのガードレールフックを適用してください。出力ガードレールには非ストリーミングのレスポンスが必要であり、システムプロンプトはデフォルトで除外されます。llm_input、llm_output、およびツール呼び出し前後のペアに対してこれらのフックを適用することで、リスクのあるコンテンツがノード間で伝播する前に、設定されたクラスを検知、ブロック、または編集できます。ただし、これはエージェント間のプロンプトインジェクションのリスクを完全になくすものではありません。これは、当社の シングル・トークン・シーケンスに関する投稿 （ガードレールのドキュメント； MCPゲートウェイのドキュメント）。 コスト管理： ワークグラフは、ファンアウト、リトライ、動的に生成されるサブタスクを通じてモデルやツールの呼び出しを増加させる可能性があるため、コスト管理を明示的に行う必要があります。予算ルールはテナントまたはチーム単位で作成し、仮想アカウントやメタデータの値ごとに個別の制限を割り当てることができます。レート制限ルールは、サポートされているメタデータの次元に合わせて照合やパーティション分割が可能です。 graph_id または node_id によってそのマッピングが作成されます。ゲートウェイはグラフの所属関係を推論しません（予算管理ドキュメント; レート制限ドキュメント）。

Authorization: Bearer <node-specific-virtual-account-token>
X-TFY-METADATA: {
  "graph_id": "release-review",
  "run_id": "run-8f31",
  "node_id": "security-reviewer"
}

相関パターンの例：固有の仮想アカウントトークンに加え、伝播されたグラフ、実行、およびノードの識別子。

可観測性： ここで、意図された役割と実際に実行された作業との乖離が把握可能になります。安定したグラフ、実行、ノードの識別子を伴うゲートウェイ経由のリクエストにおいて、ゲートウェイのメトリクスとリクエスト記録は、ノードに関連付けられたコスト、レイテンシ、モデル、ツールの分析をサポートします。これに加え、呼び出し元のIDやポリシーの適用結果を含むリクエストレベルの記録は、オーケストレーターが安定したgraph_id、run_id、node_idを出力する場合、オーケストレーター自身の実行トレースと相関させることが可能です。オーケストレーターはトポロジーの信頼できる唯一の情報源であり続け、ゲートウェイは観測した操作に関するモデル、ツール、ポリシー、レイテンシ、コストの証拠を提供します（メトリクスダッシュボードドキュメント）。 マネージドエージェントランタイム： エージェントノードはループを実行しますが、決定論的関数、ルーター、結合、人間によるチェックポイントといった他のノードタイプはループを実行しません。そして TrueFoundry Agent Harness は、ループが管理下で実行される場所としてドキュメント化されています。オーケストレーション、メモリ、MCPツールへのアクセス、ステップごとのコストを含むステップレベルのトレース、および設定された機密アクションに対する人間による承認ゲートが含まれており、グラフ内では真に新しい概念となります。 構造的チェックポイント、つまり結果が集中するまさにそのエッジにおいて、設定された機密ツール呼び出しの前に行われる人間による承認チェックポイントです。 最適化： ノードに関連付けられた属性（安定した識別子を伴うゲートウェイ経由のリクエストで利用可能）により、グラフは調整可能なシステムへと変わります。高コストなノードにはルーティングを通じて安価なモデルを割り当て、繰り返されるサブタスクにはセマンティックキャッシュを適用し、不安定なモデルターゲットにはゲートウェイのフォールバックチェーンを設定できます。オーケストレーションエッジの再試行および復旧動作はグラフランタイムの責任となります。これらは当社のゲートウェイの投稿で解説しているものと同じ手段ですが、今回はトポロジーを対象として適用できます。

エンタープライズ向けグラフエンジニアリング・チェックリスト：本番環境のマルチエージェントグラフに必要なもの

今四半期、マルチエージェントグラフを本番環境へ移行するチームにとって、要件は7つの問いに集約されます。これらはオーケストレーション層とガバナンスの効いた実行プレーンの両方にまたがるものです。独立して管理されるすべての呼び出し元に、解決済みのIDが割り当てられているか？ゲートウェイを介したモデル呼び出しやMCP呼び出しに、安定したグラフ、実行、ノードの識別子が保持されているか？オーケストレーターは実際のランタイム作業グラフを記録しているか？オーケストレーションのトレースを、ゲートウェイのコスト、ポリシー、レイテンシ、ツール記録と関連付けられるか？グラフやノードに関連付けられた予算ルールは、仮想アカウントやメタデータを通じてマッピングされているか？機密性の高いツール操作は、明示的な承認チェックポイントによって保護されているか？モデルの変更は、リクエスト契約が許す範囲で、仮想モデルルーティングの背後に分離されているか？回答できない項目があれば、そこがインシデント発生の潜在的なリスク箇所となります。

グラフエンジニアリングの未来：注目すべきポイント

予測はあくまで予測であり、現時点での見解に過ぎません。用語は今後入れ替わるでしょう。「組織グラフ（org graph）」や「作業グラフ（work graph）」という言葉が定着するとは限らず、ループエンジニアリングの時と同様に、数週間以内には競合する概念が登場するはずです。各フレームワークが用語の主導権を争うでしょう。そして、真に興味深いエンジニアリングは、7月18日の記事で示されたプリミティブが交差する地点、すなわち「安定した組織グラフのポリシー下におけるランタイム作業グラフの変異」に集中するはずです。誰がノードを生成できるのか、生成されたノードは何を継承するのか、キャンセルされたタスクの副作用をどう解消するのか。標準化の議論（A2Aとその継承規格）はエッジ層で続いていくでしょう。これらのシステムが孤立した実験から共有の本番環境へと移行するにつれ、エンタープライズの要件が可視化されます。その時、上記のチェックリストはブログの枠組みを超え、調達基準へと変わります。状況の変化に合わせてこのガイドを更新していきます。命名に関する議論はまだ新しく、新しい用語を扱うことは継続的な改訂を約束するものです。おそらく今後も変わらず重要なのは、結びの主張です。これは、このブログのアーカイブの中で最も古い教訓を、最新の語彙で表現したものに過ぎません。パラダイムはX（旧Twitter）やフレームワークから生まれますが、成長するのは本番環境においてです。どのような用語が生き残るにせよ、持続可能な運用には、オーケストレーション、ID、ポリシー、予算、承認、証跡にわたる明確なオーナーシップが不可欠です。

TrueFoundryの視点：パラダイムは移り変わるが、本番環境への備えは変わらない

「プロンプトエンジニアリング、コンテキストエンジニアリング、ハーネスエンジニアリング、ループエンジニアリング、そして今回のグラフエンジニアリング。ラベルは今後も次々と現れ、毎週のように新しいものが登場するかもしれません。しかし、それらを顧客に提供するために必要なもの――ガバナンスの効いたアクセス、予算、ガードレール、ID、トレース――は、これまで一度も変わっていません。新しいパラダイムを学び続けましょう。そして、それらすべてをデプロイ可能にするインフラストラクチャを強化してください。」

これが、本書を読むエンタープライズ担当者にとっての実際的な教訓です。グラフエンジニアリングはまだ初期段階にあり、用語の由来さえ定まっていないほどです。しかし、オーケストレーション層がどのように進化しようとも、グラフノードの一部はモデルやMCPツールを呼び出し、残りは決定論的または人間が制御する形になるでしょう。ゲートウェイを介したトラフィック（モデル呼び出しやMCPツールの呼び出し）には、現在と同様のガバナンスが必要であり、オーケストレーター自身のグラフ記録と関連付けられなければなりません。

そして、各 エージェント型 ノード内部の実行層――つまりループ――には、すでに管理された拠点が存在します。それが エージェントハーネスです。これは、承認、サンドボックス化、ステップ単位のトレースの下で、エージェントが計画、実行、観察を行うためのランタイムです。私たちの ループエンジニアリング に関する投稿と、その フリートスケール版の続編 で、その層を詳しく解説しています。グラフエンジニアリングは成熟するにつれ、それらの管理されたループを組織化するための規律となるでしょう。

グラフエンジニアリングに関するFAQ

グラフエンジニアリングとナレッジグラフエンジニアリングは同じものですか？

いいえ。ナレッジグラフエンジニアリングは、検索や推論のためにエンティティ（実体）と関係性を構造化するものです。一方、2026年のマルチエージェントという文脈におけるグラフエンジニアリングは、以下のものを構造化します。 システム：異種混合ノード、許可された遷移、責務、そして実行時のワークグラフです。一つのアーキテクチャで両方を使用することも可能です。

エンタープライズ環境において、グラフエンジニアリングには何が必要ですか？

本番環境のグラフエンジニアリングは、オーケストレーター、アプリケーションのインストルメンテーション、そしてガバナンスの効いた実行プレーンにまたがります。オーケストレーターはトポロジーと実行時のグラフ状態を記録し、参加する呼び出し元はグラフ、実行、ノードの識別子を伝播させます。TrueFoundryは、ゲートウェイを介したモデルやMCPの操作に対して、ID管理、アクセス権限ポリシー、予算、レート制限、ガードレール、承認プロセス、記録、メトリクスを適用できます。

現在、グラフエンジニアリングをサポートしているツールは何ですか？

グラフフレームワークはトポロジーとオーケストレーションを提供し、A2Aのようなプロトコルはエージェント間の通信をサポートします。TrueFoundryは、Agent Harnessエージェントの管理実行環境を提供し、ゲートウェイを経由するモデルやMCPの操作に対してガバナンス、予算、ガードレール、リクエスト記録、メトリクスを提供します。ノードレベルの相関関係を把握するには、アプリケーションによって伝播される、解決済みの明確なIDや識別子が必要です。

参考文献

• 7月18日の統合 — Yash Thakker, “Graph Engineering: After Loops, This Is How You Wire Multi-Agent Orgs,” explainx.ai, 2026年7月18日。提案されたフレームワーク、オーナーシップの例、および同記事で言及されている組織グラフとワークグラフの区別について参照。 Shubham Saboo。
• 本ブログのループエンジニアリングに関する一連の記事 — Loop Engineering at Enterprise Grade: From Laptop Loops to Governed Runtimes; Loop Engineering, Continued: From One Governed Loop to an Operable Fleet。関連情報： マルチエージェントA2Aガバナンス; エージェントIDセンサス; 非推奨化のトレッドミル; Agent Harnessとは何か。
• TrueFoundryドキュメント — Agent Harness（マネージドエージェントランタイム：オーケストレーション、トレース、承認ゲート）; MCPゲートウェイの認証とセキュリティ; ガードレール; 予算管理; メトリクスダッシュボード（公式イメージ）。
• 基礎およびフレームワークの参照 — アクターモデル： Hewitt, Bishop & Steiger, “A Universal Modular ACTOR Formalism for Artificial Intelligence” (IJCAI 1973); Contract Net Protocol: Smith, IEEE Trans. Computers (1980); Apache Airflow DAG ドキュメント; LangGraph ドキュメント; AutoGen ドキュメント; CrewAI ドキュメント; Google A2A 発表資料。
• Agent Harness — サブエージェントのドキュメント; AI Gateway — レート制限のドキュメント。

7月18日付の記事から引用した用語については文中で明記し、それ以外の実質的な議論についてはリンクを添えて要約しています。エンタープライズマッピングはTrueFoundryによる編集上の構成であり、7月18日付の記事ではエンタープライズ運用や特定のベンダーについては言及されていません。また、各機能は2026年7月19日時点のTrueFoundryの公開ドキュメントに基づき要約したものです。「グラフエンジニアリング」は台頭しつつある概念であり、その名称の由来は定まっていません。本ガイドはパラダイムの進化に合わせて改訂される予定であり、最終更新日はページメタデータに記載されています。

‍