管理と運用
Context Graph API
APIとサービスの依存関係を認証済みの情報に基づいてエージェントが把握できるようにします。変更がどこまで影響するかをたどり、影響を受けるAPI利用者を特定して、コードをマージする前に破壊的変更を検出できます。
Context Graphの仕組み
468のリポジトリを対象にベンチマーク
8つの質問を3つのモデルで検証し、Context Graphを使う場合と使わない場合で、それぞれ3回ずつ実行しました。モデル、質問、使用するツールはすべて同じ条件です。
29%
プロンプトトークンを削減
Opus 4.7では29%削減。GPT-6 Astraでは23%削減し、Sonnet 4.5では増加しました。
17%
1回の実行あたりのツール呼び出しを削減
Opus 4.7では、69回から57回に減少しました。
27%
1回の実行あたりのコストを削減
Opus 4.7では27%削減。GPT-6 Astraでは20%削減し、Sonnet 4.5では増加しました。
2026年9月に、468のリポジトリと3つのモデルを対象に、計144回のベンチマークを実施しました。コストには、初回のみ必要なグラフの構築と継続的な再取り込みにかかるコストは含まれていません。
システムをまたぐ質問で、プロンプトトークンを削減
モデルがコードを読む前にグラフへ問い合わせた場合の、プロンプトトークンの削減率を示しています。468のリポジトリを対象にOpus 4.7で検証した結果で、8つの質問のうち削減率が最も大きかった3つを掲載しています。質問1つあたりのツール呼び出しが69回から57回に減ったことで、やり取りの回数が減り、トークン数も削減されました。
Chart will load when visible
利用を開始
Postmanで用意済みの質問を実際のAPIに送信し、Context Graphを直接試すことができます。
1. Context Graphでは認証が必要です。クエリを実行する前に、Postmanアカウントにサインインしてください。
2. リクエストの［Authorization］タブにPostman APIキーを追加してください。
アクティブな環境を「Context Graph API」に設定してください。
4. グラフはチームごとに構築されます。現在サインインしているチームのノードが取り込まれ、そのチームのグラフがクエリの対象になります。
5. リクエストボディのクエリを編集して、質問したい内容を指定してください。
取り込まれたグラフは、Postmanのホームボタン ＞［Agent Context］からいつでも確認できます。
複数のリポジトリにまたがる変更で、Context Graphがどう役立つかをご覧ください
リソース
Context Graphをさらに詳しく知る
よくある質問
Postman Context Graphとは何ですか？
API全体の情報を継続的に更新するグラフです。Postmanワークスペース、コードリポジトリ、ランタイムの情報を取り込み、API、エンドポイント、デプロイ、データベース、チームなど、種類ごとに分類されたエンティティと、それらを結ぶ種類ごとの関係としてグラフを構築します。エージェントは、開いているファイルからこうした関係を一から組み立て直すのではなく、このグラフに問い合わせて必要な情報を取得します。
Context Graphではどの情報源からデータを取り込めますか？
主な情報源は、チームがすでに管理している仕様、コレクション、環境を含むPostmanワークスペースです。さらに、OpenAPI、AsyncAPI、サービス定義を検出するためにGitHubリポジトリをスキャンし、コードのスキャンだけでは把握できないデプロイやランタイムの情報をNew Relicから取り込みます。
グラフはどのように最新の状態に保たれますか？
情報源ごとに、更新間隔、Webhook、手動のいずれかで取り込み方法を設定できます。再取り込みは変更分だけを対象とするため、変更のないリポジトリはスキップされます。そのため、コストは管理するシステム全体の規模ではなく、コードの変更量に応じて変わります。ランタイムコネクターからは継続的にデータが取り込まれます。
Context GraphではAPIについてどのような情報を把握できますか？
APIが公開しているもの、ランタイムで何を呼び出し、何に依存しているかを把握できます。また、どのデータベースがAPIを支えているか、どの外部サービスと通信しているか、どのチームが所有しているか、どこにデプロイされているか、何によって監視されているかも確認できます。すべての関係には根拠となる情報が記録されるため、確認済みの関係と推測された関係を区別できます。
Context GraphはMCP経由で利用できますか？
MCPサーバーは現在準備中です。提供開始後は、現在使用しているMCPクライアント（エディター、エージェントフレームワーク、独自の実行環境など）からContext Graphをツールとして利用できるようになります。HTTPリクエストを自分で記述したり、非同期ポーリングを処理したりする必要はありません。現在、早期アクセスの対象組織ではHTTPエンドポイントを利用できます。MCPサーバーの提供開始後も、このHTTPエンドポイント向けに構築したものをそのまま活用できます。
Context Graphを使わないほうがよいのは、どのような場合ですか？
必要な情報が、すでに手元のファイルにある場合です。ベンチマークでは、たとえば「どのモジュールがインポートしているか」のように依存関係が明示されている場合、go.modだけで答えを得られることが分かりました。リポジトリを読むだけで98%のスコアとなり、Context Graphを使っても結果は向上しませんでした。Context Graphが効果を発揮するのは、リポジトリやサービスなどの境界をまたいで情報を確認する場合です。