メインコンテンツにスキップ

AIエージェントを予測可能にするグラフエンジニアリング

技術
解説
AIエージェント
イベントレポート
グラフエンジニアリングは、エージェントの実行・記憶・手順を明示的なグラフにし、LLMが推論する範囲を判断の必要な箇所に絞る設計手法である。Neo4jの論文では、散文のスキルを型付きグラフへコンパイルすると、27タスクの合格率が53.3%…
作者

obelos

公開

2026年11月4日

更新日

2026年11月4日

グラフエンジニアリングは、エージェントの実行・記憶・手順を明示的なグラフにし、LLMが推論する範囲を判断の必要な箇所に絞る設計手法である。Neo4jの論文では、散文のスキルを型付きグラフへコンパイルすると、27タスクの合格率が53.3%から67.4%に上がった（AIP論文）。ただし論文の検証モデルはClaude Sonnetのみで、グラフが効く範囲にはまだ未検証の部分が残る。

本記事は、AI Engineerが2026年11月に公開した20分のトーク「Make Your AI Agents Predictable With Graph Engineering」（Zachary Blumenfeld, Neo4j）を起点に、論文と公式ドキュメントで補完したものである。

3つのグラフは、別々の問いに答える

グラフエンジニアリングという言葉の定義は、まだ定まっていない。実行グラフだけを指す立場もあれば、知識側のグラフも必須とする立場もある。Blumenfeldのトークは、実行・コンテキスト・手続きの3種類に整理する。

実行グラフはLLMの経路を制約する。LangGraphはチェックポインタで各ステップの状態を保存し、人による承認、障害からの再開、過去時点への巻き戻しを可能にする。

コンテキストグラフは、事実に加えて判断の履歴を保持する。Neo4jは短期記憶、長期記憶、推論記憶の3層で構成し、決定とその理由、使用したツールを決定トレースとして残す。

手続きグラフは、スキルの順序、入出力、依存関係を明示する。知識グラフが「何であるか」に答えるのに対し、手続きグラフは「何をすべきか」に答える。トークは、コンテキストグラフと手続きグラフの2つに焦点を当てる。

AIPは、散文のスキルを型付きの実行グラフにする

Agent Skillsの本体は、LLMが実行のたびに読み直す自由形式のMarkdownである。AIP論文は、この形式の限界を4点挙げる。

散文スキルの問題 起きること AIPの対処
構造を強制できない コードやコマンドを毎回導出し、実行ごとに経路がぶれる 確定処理をスクリプトのノードにする
調整が難しい 意味を変えない言い換えでも精度が大きく変わる スキーマ検証で曖昧さを作成時に解消する
改善の範囲が定まらない エージェントによる修正は追記に偏り、スキルが肥大化する 編集対象をノード、スクリプト、エッジに限定する
原因を特定できない 失敗を特定の手順に帰属できず、監査もできない 全ステップに名前と型を付け、クエリ可能にする

AIPはAgent Skills仕様の拡張である。ステップは、確定処理を担うスクリプトノードと、判断を担う説明文ノードの2種類に分かれる。ステップ間は型付きの入出力でつなぎ、全体をスキーマ検証済みのYAMLで管理する。次の例は、仕様の主要項目を説明するために作成したものである。

purpose: 融資申請を審査し、承認、否決、上申を判定する
steps:
  - name: load-application
    script: scripts/load_application.py
    outputs: [{name: application, type: object}]
  - name: score-risk
    script: scripts/score_risk.py
    inputs: [application]
    outputs: [{name: risk, type: object}]
  - name: judge-exception        # 判断ノード
    description: ポリシーの例外に当たるか、過去の決定を参照して判断する
    inputs: [risk]
    outputs: [{name: decision, type: string}]

既存スキルの変換には、コンパイラのメタスキルを使う。人が書いた原文を残したまま、スクリプト、参照文書、スキーマへ展開する。専門家がスキルを書く工程は置き換えない。

注意点として、論文時点のAIPはランタイムではなく仕様である。エージェントはYAML全体をコンテキストに読み込み、自身の推論で手順をたどり、順序を強制する仕組みは今後の課題とされている。後述するトークのデモでは、小さなCLIでスキルを包み、ルーティングをプログラムで実行している。

効果は有意だが、速度とコストの改善は確定していない

AIPへの変換で平均報酬は0.106上がり、統計的に有意だった（p=0.011）。一方、実行時間の短縮は有意ではない。検証はSkillsBenchの27タスク、Claude Sonnet 4.6、各5試行で行われた。

指標 人が書いたスキル AIP変換後 差
平均報酬 0.599 0.705 +0.106
合格率 53.3% 67.4% +14.1pt
平均実行時間 585秒 510秒 -75秒（p≈0.28で有意差なし）
平均ツール呼び出し 27.7回 25.6回 -2.1回（有意差なし）
タスク別の勝敗 - - 12勝13分2敗

改善は一部のタスクに偏り、単一の構造的な軸では有意にならなかった。たとえばスクリプトを持たない散文スキルのmars-clouds-clusteringは2/5から5/5へ上がった。逆にenergy-market-pricingでは精度が上がった代わりに、実行時間とツール呼び出しが約2倍に増えた。

ノード単位の修復も確認された。offer-letter-generatorは誤ったキー参照が原因で全試行が失敗していたが、修正後は0/5から5/5へ回復し、他のタスクの劣化はなかった。

結果の解釈には、次の制約がある。

  • 形式と作成者の交絡：改善の要因がグラフ形式なのか、変換時に生成されたスクリプトの質なのかは分離されていない。
  • モデルが1種類：弱いモデルほど効果が大きいという仮説は未検証で、Haikuや他社モデルでの再現は今後の課題である。トークでは、Haikuでの検証を進めていると述べている。
  • 専門家の原文が前提：タスク指示だけからAIPスキルを作ると、初期試行で0/15と人手のスキル（11/15）を大きく下回った。

Googleなどの研究者によるProcedural Graphs論文は、別の手法で同じ方向の結果を示す。24の条件のうち19で最良のベースラインを上回り、2条件が同等、3条件が下回った。ただし、この手法は推論時に毎回ガイダンスを生成するため、GDPvalとALFWorldではステップ数が減っても総トークンが33.4%と55.4%増えた。手作りのグラフが不適切だと、成功率が87.50%から58.93%へ下がる例も報告されている。グラフは自動的にコストを下げるものではなく、グラフの質と利用方式に依存する。

決定トレースからスキルを蒸留し、LLMの役割を1工程に絞る

既存のスキルを変換するだけでなく、エージェントの実行記録からスキルを生成する経路もある。Neo4j Agent Memory Service（NAMS）は、この処理を次の7工程で行う。Neo4j Labsのプロジェクトで、LLMを使うのは5番目の工程だけである。

  1. Scope：蒸留の対象とする会話の範囲を決める。
  2. Snapshot：ワークスペースをロックし、抽出途中の記憶を使わないようにする。
  3. Consolidate：繰り返す行動をまとめ、ツール実行の結果で有効なパターンとアンチパターンに分ける。
  4. Graph：記録されたトレースから、手順のトポロジーを決定的に導出する。
  5. Synthesize：LLMがステップの説明と主張を書き、すべてに参照元を付ける。
  6. Gates：根拠性（0.9以上）、網羅率（0.6以上）、PIIなどを検査し、不合格なら公開しない。
  7. Persist：スキルをサブグラフとして保存し、人のレビュー待ちにする。

スクリプトノードになるのは、記録されたツール呼び出しで裏付けられるステップだけである。判断のステップは説明文のまま残し、記録された推論に紐付ける。記録が3ステップ未満の範囲は、無理にグラフ化せず散文に戻す。

成果物は標準のSKILL.mdパッケージなので、Claude Code、MCPクライアント、REST経由の各種フレームワークで読み込める。トークが挙げる可搬性は、この形式に支えられている。

公開後の鮮度も、グラフで管理する。スキルと根拠の記憶が同じグラフにあるため、ツールの結果が記録時と食い違うステップをクエリで検出できる。修復は該当ステップのみを対象とし、他のステップは変更しない。根拠が失われた場合は修復せず、蒸留のやり直しを求める。

融資審査は、決定論的な処理と判断の分離が効く領域である

トークのデモは、融資審査エージェントである。事業計画のPDF、Databricksの取引データ、融資ポリシー、過去の決定をコンテキストグラフに統合する。エージェントはこのグラフをたどって審査できるが、実行ごとに手順の長さが変わる。そこで、成功した実行をグラフ状のスキルへコンパイルし、小さなCLIで包む。

処理は次の順に進む。

  1. 実行スクリプトがハードルールを判定する。
  2. 自動で承認、否決できない案件を、型安全な決定モデルへ渡す。
  3. 人への上申が必要かを分岐する。
  4. 不要ならエージェントがレポートを書き、lintで確認する。

実行時間は、Fable単体の2.7分が、AIPでほぼ半分になり、Haikuへの切り替えでさらに短くなったと報告された。ただし登壇者自身が、正式な研究ではなくデモだと断っている。

実行履歴はグラフに保存するので、通った分岐と通らなかった分岐をクエリで確認できる。

同じ領域のLoanGuard AIの開発記録は、この分離が必要な理由を具体的に示す。閾値評価ツールがBREACHを返したのに、Claudeが独自に計算し直してCOMPLIANTと結論する不具合が起きた。修正では、ツールの結果を判定の正とし、再計算を禁じる指示を明記した。計算はツール、解釈はLLMが担う。

このシステムは、モデルも役割で分けている。ルーティングと統合にはHaiku、専門エージェントにはSonnetを割り当てる。判断の結果は、評価、所見、推論ステップをノードとするサブグラフに保存し、判定から根拠の条文までたどれるようにした。

手順がグラフになると、ガバナンスの問いもクエリで答えられる。Skill Graphの作者は、自身の18個のスラッシュコマンドをグラフに変換し、人の承認なしで外部を変更するステップを検索した。結果は6件で、モデルの判定だけでPull Requestを閉じる手順も含まれていた。この手法はトーク登壇者のウェビナーに着想を得たものだが、書かれた指示を検査するだけで、実際の実行は検証していない。ステップの分類もClaudeの判定で、公開例は人による全件レビューが済んでいないため、件数は分類次第で変わる。

MATCH (s:Command)-[:HAS_STEP]->(w:Step {effect: "remote"})
WHERE NOT EXISTS {
  MATCH (a:Step {kind: "approval"})-[:INPUTS_TO|THEN*]->(w)
}
RETURN s.name, w.id

上のクエリは考え方を示すために簡略化したものである。経路の有無で答えが決まる問いなので、全文検索では代替できない。

グラフ化は、境界が実在する箇所だけに適用する

1つのループで済む処理をグラフにしても、調整の負荷が増えるだけである。分割の基準は、役割、権限、失敗時の扱いに実際の違いがあるかで判断する。

判断軸 単一ループを維持する グラフに分割する
作業の性質 完了条件が1つの作業 異なる専門性に分かれる作業
権限 同じツールと文脈で安全に進められる ノードごとに権限やツールが異なる
経路 LLMに任せても安全 承認や条件分岐を決定論的に強制する
失敗時 同じループの再試行で足りる 個別の再試行、補償、エスカレーションが要る
手順の既知性 事前に経路を決められない 既知の手順でLLMの裁量を制限できる

導入時の未解決の課題は、次の3点である。

  • どのトレースを経験として残すか：Blumenfeldは別のトークで、決定の質を評価して記憶に残す仕組みはまだ検討段階だと述べている。悪い決定を前例として学習しない設計が要る。
  • ランタイムでの強制：論文時点のAIPは、手順の遵守をエージェントの規律に委ねている。順序を厳密に守らせる箇所は、デモのCLIのように実行側で強制する必要がある。
  • 語彙の断片化：SurrealDBが1件の会話で行った自社測定では、自動抽出した属性キーの85%が1回しか使われなかった。同じ実行で既存の語彙を提示した関係カテゴリでは、ラベルあたりの使用回数が1.4回に対して4.3回だった。オントロジーを先に定義しないと、構築したグラフをクエリで活用できない。

なお、本記事の定量結果の多くは、グラフ技術を提供する企業やその研究者によるものである。自社のタスクへ適用する前に、代表的な業務で散文スキルと比較評価する必要がある。

関連記事

モデル・ハーネス・コンテキストの3層で改善する方法は、次の記事で解説しています。

使うほど賢くなるエージェントのつくり方――モデル・ハーネス・コンテキスト

ハーネスを自動で改良する研究は、次の記事で紹介しています。

AIエージェントは「自分の仕組み」をどう鍛えるか──Harmony Harness論文を読む

知識をモデルの重みに定着させる方法は、次の記事で解説しています。

企業が自社モデルを訓練する時代の実装ロードマップ：Will Brown講演の解説

参考資料