Eili Library

PromptからGraphへ――AIエージェント設計を5つのレイヤーで捉える

17 min read

PromptからGraphへ――AIエージェント設計を5つのレイヤーで捉える

動画で見る：AIエージェント設計の現在地 — Prompt → Context → Harness → Loop → Graph Engineering

AIエージェントを使い始めると、最初は「良いプロンプトを書けばよい」と考えがちだ。しかし、長時間動き、ファイルやAPIを扱い、複数の役割が協力するエージェントでは、それだけでは足りない。

本稿では、AIエージェントの設計対象が広がる流れを、次の5つのレイヤーとして整理する。

Prompt → Context → Harness → Loop → Graph

これは公式に標準化された工程表ではない。とりわけ Graph Engineering は、単一の確立された学術分野や製品名ではなく、本稿で「複数のエージェント・ツール・検証・権限を、関係の構造として設計すること」を指す便宜的な呼び名である。ただし、グラフによるワークフロー実行、状態・ノード・エッジ、承認ゲートといった実装要素自体は、現在の主要なエージェント基盤に明確に見られる。

flowchart TB
    P["Prompt<br/>何を指示するか"] --> C["Context<br/>何を見せて考えさせるか"]
    C --> H["Harness<br/>何を許可し、どう安全に実行するか"]
    H --> L["Loop<br/>どう観測・検証・再試行するか"]
    L --> G["Graph<br/>役割・状態・経路をどう接続するか"]
    P -. "下位レイヤーとして残る" .-> G
    C -.-> G
    H -.-> G
    L -.-> G

重要なのは、後のレイヤーが前のレイヤーを捨てるわけではないことだ。グラフ型のシステムにもプロンプトがあり、コンテキストがあり、安全な実行環境と検証ループが要る。これは流行語の交代ではなく、設計の射程が広がる話である。

まず全体像

レイヤー主な設計対象中心となる問い
Prompt Engineering指示AIに何をしてほしいか？
Context Engineering情報AIは何を知った状態で判断するか？
Harness Engineering実行環境何を許可し、何で守るか？
Loop Engineering反復観測・検証・修正をどう回すか？
Graph Engineering*関係と経路誰／何を、どの条件で接続するか？

* 本稿での整理上の呼称。

1. Prompt Engineering：指示を設計する

Prompt Engineeringは、モデルに渡す命令、制約、例、出力形式を設計する営みである。一回の呼び出しであっても、役割、成功条件、禁止事項、出力スキーマを明確にすれば、出力の安定性は大きく変わる。

役割：技術編集者
目的：一次情報に基づく要約を作る
制約：推測は推測と明記する。出典URLを残す
出力：見出し、要点、根拠、未確認事項

ここでの主役は、基本的には一回のモデル呼び出しだ。プロンプトは今も基礎であり、エージェント化しても「何を成功と見なすか」「何をしてはいけないか」を伝える役割は失わない。

2. Context Engineering：見せる世界を設計する

エージェントの品質は、命令文だけで決まらない。参照する文書、ソースコード、会話履歴、検索結果、ツールの返り値、メモリも判断を左右する。これらを、必要な時に、必要な量だけ渡す設計がContext Engineeringである。

Anthropicは、Context Engineeringを「望ましい振る舞いを生むため、推論時に含めるトークンの構成を最適化すること」と説明している。また、コンテキストは有限の資源であり、長くすれば常に良くなるわけではない、と指摘する。Anthropicの解説

flowchart LR
    U["ユーザーの依頼"] --> S["必要な情報を選ぶ"]
    D["文書・コード"] --> S
    M["要約・メモリ"] --> S
    T["検索・ツール結果"] --> S
    S --> X["最小限で高信号なContext"] --> LLM["LLM"]

実務では、すべてを一度に入れるより、次のような段階的な取得が有効になることが多い。

  • 最初に方針、目次、ファイル一覧などの小さな地図を渡す
  • エージェントが必要と判断した詳細だけをツールで読む
  • 長い作業では、重要な決定・未解決事項を要約して次の反復へ渡す

RAG、メモリ、Skills、AGENTS.mdのようなリポジトリ指示、MCP経由のツール結果は、用途こそ異なるが、いずれも「モデルが今見えている世界」を整える部品として捉えられる。

3. Harness Engineering：実行環境を設計する

エージェントが文章を返すだけなら、誤答は主に会話の問題で済む。だが、Shellでコマンドを実行し、ファイルを書き換え、GitHubやデータベースに触れるなら、能力だけでなく実行環境の設計が安全性を決める。

ここでいうHarnessは、モデルの周囲に置く作業場・制御装置の総称である。代表的な構成要素は次の通りだ。

  • ツールの許可リストと引数の制約
  • 読み取り専用／書き込み可能な領域の分離
  • 認証情報と権限の最小化
  • 実行ログ、トレース、コスト・時間の上限
  • テスト、静的解析、承認ゲート、ロールバック
  • 作業状態と引き継ぎ情報の保持

OpenAIのAgents SDKはガードレールとトレーシングを、Microsoft Agent Frameworkは長い複数ステップの作業向けHarnessを明示的な構成要素として扱っている。OpenAIのエージェント構築ガイド Microsoft Agent Frameworkの概要

flowchart TB
    subgraph H["Harness：エージェントの実行環境"]
      I["指示・Context"] --> A["Agent / LLM"]
      A --> TO["Tools"]
      TO --> V["決定論的な検証<br/>テスト・Lint・ポリシー"]
      V --> A
      P["権限・予算・停止条件"] -. "制約" .-> A
      O["ログ・トレース"] <-. "記録" .-> A
    end

Harnessは「賢いモデルを閉じ込める檻」ではなく、モデルが安全に能力を発揮するための足場である。特に外部への書き込みを伴う処理では、モデルの自己申告ではなく、テスト結果・権限判定・人間の承認といった外部から確認できる条件を成功基準にする。

4. Loop Engineering：反復を設計する

エージェントの作業は、一回の生成で終わらない。観測し、実行し、結果を検証し、失敗なら情報を更新してやり直す。この時間的な構造を設計するのがLoop Engineeringである。

ReActは、言語モデルの推論と行動を交互に行わせ、外部情報を取得しながら計画を更新する代表的な研究である。ReAct論文

flowchart TD
    GOAL["Goal"] --> PLAN["Plan"] --> ACT["Act"] --> OBS["Observe"] --> CHECK{"Verify"}
    CHECK -- "未達・失敗" --> PLAN
    CHECK -- "達成" --> END["End"]
    LIMIT["時間・費用・反復回数の上限"] -. "停止" .-> CHECK

ループを本番運用する際は、少なくとも次を設計する。

  1. 開始条件：いつ、何をきっかけに走るか
  2. 観測：何を読んで次の判断をするか
  3. 検証：何をもって成功・失敗とするか
  4. 停止：反復回数、時間、予算、副作用の上限をどこに置くか
  5. 復旧：失敗時に再試行するか、人に渡すか、ロールバックするか

単一エージェントと検証器の往復だけでも、十分に強力な構成になる。複数エージェント化は、並列化や専門分化による利益が、調整コストを上回る場合に初めて検討すべきだ。

5. Graph Engineering：関係と経路を設計する

ループが「一連の反復」を扱うのに対し、グラフは分岐、並列、合流、再試行、承認を含む関係全体を扱う。現在のフレームワークでは、一般に次の三要素で表現される。

  • Node：エージェント、ツール、評価器、人間の承認、通常のプログラム処理
  • Edge：順序、条件分岐、委譲、再試行、依存関係、データの受け渡し
  • State：各ノードが読んだり更新したりする共有状態

LangGraphはまさにState・Node・Edgeでエージェントの振る舞いをモデル化し、固定遷移と条件付き遷移、並列実行を提供している。LangGraph Graph API MicrosoftのAgent Frameworkも、executorとedgeを有向グラフとして接続するワークフローを提供する。Microsoft Learn: Workflows

flowchart LR
    U["依頼"] --> P["Planner"]
    P --> R["Research"]
    P --> D["Developer"]
    R --> J["統合・検証"]
    D --> J
    J --> Q{"品質・権限チェック"}
    Q -- "修正が必要" --> D
    Q -- "高リスク" --> H["Human approval"]
    Q -- "承認済み" --> S["成果物"]
    H -- "承認" --> S
    H -- "差し戻し" --> P

このとき、Nodeは必ずしもAIではない。たとえば「単体テスト」「本番リリースの承認」「予算超過時の停止」は、LLMではなく決定論的なソフトウェアや人間に担わせた方がよい。グラフの価値は、AIを増やすことではなく、責任と失敗境界を明確にすることにある。

3種類のグラフを混同しない

「グラフ」という言葉は対象が異なるため、少なくとも次の三つを分けて考えると議論が整理しやすい。

種類表すもの例
Knowledge Graph世界・データの関係ユーザー→所有→プロジェクト、文書→参照→規約
Task Graph作業の依存関係要件→設計→実装→テスト→リリース
Agent Graph役割・権限・通信の関係Planner→Researcher／Reviewer、人間の承認ゲート

Knowledge Graphは「何と何が関係しているか」、Task Graphは「どの順番で終えるか」、Agent Graphは「誰が判断・実行・検証するか」を中心にする。実際のシステムでは重なり合うが、まず区別すると、必要なデータモデルと安全策が見えやすくなる。

Dynamic Graph：自由な提案と決定論的な制約を分ける

複雑な依頼では、毎回同じ経路が最適とは限らない。エージェントに「このタスクには調査・設計・セキュリティ確認・実装・テストが必要だ」と経路を提案させる設計は可能である。

ただし、提案されたグラフをそのまま実行してはならない。モデルが提案するのは候補であり、実行可否は通常のプログラムで検証する。

flowchart TD
    A["Agent proposes a graph"] --> V["Graph validator"]
    V --> B{"構造・権限・予算・型は有効か"}
    B -- "No" --> R["理由を添えて再計画"] --> A
    B -- "Yes" --> E["実行"] --> O["ログ・評価"]

検証器に持たせたい代表的な規則は、次のようなものだ。

  • 許可されないNodeタイプやツールを含まない
  • 外部書き込みの前に承認Nodeが置かれている
  • 循環には反復上限と停止条件がある
  • 並列Nodeが同じ状態を書き換える場合、競合解決の規則がある
  • 予算・実行時間・外部API呼び出し回数の上限を超えない

この分離によって、LLMの柔軟な分解・提案能力と、ソフトウェアの再現可能な安全制御を組み合わせられる。

いつグラフに進むべきか

グラフは強力だが、何でもグラフ化すればよいわけではない。構造を増やすほど、状態管理、デバッグ、監視、コスト見積もりは難しくなる。まずは単一エージェントと短い検証ループで始めるのが現実的だ。

次の条件が重なるとき、グラフ設計の価値が上がる。

  • 独立した調査・実装・テストを並列に進められる
  • 役割ごとに必要な権限やコンテキストが明確に異なる
  • 人間の承認や監査可能な責任分界が必要である
  • 失敗時に一部だけ再実行・再計画したい
  • 長時間の処理で状態の保存と復旧が必要である

反対に、単純な質問回答、短い編集、手順が固定された小さな自動化では、単一のエージェントと明快な停止条件の方が、安く、理解しやすく、保守しやすい。

まとめ：AIに答えさせることから、AIが働く構造を設計することへ

PromptからGraphへの流れは、AI設計の問いが次のように拡張していく見取り図である。

言葉（Prompt）
  → 知識（Context）
  → 環境（Harness）
  → 時間（Loop）
  → 関係（Graph）

最終目標は、複雑なマルチエージェント組織を作ることではない。依頼に対して必要十分な構造を選び、権限・状態・検証・停止を説明可能にすることだ。

AIエージェントの重要な扱い方は、モデルを信頼するか不信するかの二択ではない。モデルが得意な探索・提案・言語理解を活かしながら、重要な制約と検証を、観測可能で決定論的な仕組みに置く。その境界を丁寧に設計することが、これからのAIエンジニアリングの核になる。

参考資料

グラフビュー

バックリンク