--- title: "Context Graph | Postman API Platform" description: "API、デプロイ、依存関係を継続的に更新し、そのつながりを把握できるグラフです。エージェントはコードを書く前に、変更がどこに影響するかを確認できます。" url: https://www.postman.com/jp/context-graph/ --- # Context Graph | Postman API Platform > API、デプロイ、依存関係を継続的に更新し、そのつながりを把握できるグラフです。エージェントはコードを書く前に、変更がどこに影響するかを確認できます。 ## Context Graph API APIとサービスの依存関係を認証済みの情報に基づいてエージェントが把握できるようにします。変更がどこまで影響するかをたどり、影響を受けるAPI利用者を特定して、コードをマージする前に破壊的変更を検出できます。 --- ## APIが存在するさまざまな環境の情報を、1つのグラフにまとめます ### 今ある環境をそのまま接続 Postmanワークスペース、GitHubリポジトリ、New Relicで稼働しているサービスを、一度接続するだけです。 ### すべての関係を根拠とともに記録 ノードと6種類の関係を分類し、それぞれに根拠を記録します。どのコミットで確認された関係なのか、どこから得た情報なのかまで分かります。 ### 開発に必要な情報をすばやく把握し、エージェントを活用したSDLCを加速 変更の影響範囲や依存関係をたどり、エンドポイントの利用者や所有チームを確認できます。 --- ## Context Graphの仕組み --- *機能* ### 1つのリポジトリや検索ツールだけでは分からないことまで把握 Context Graphは、コーディングエージェントがコードベースだけでは分からない情報を、サービス、リポジトリ、環境をまたいで把握できるようにします。 ### リポジトリをまたいだ変更の影響範囲 「このエンドポイントを変更すると、どのサービスに影響するか？」呼び出し元は別のリポジトリにあることが多く、検索してもたどれない場合があります。Context Graphにはその関係がすでに記録されているため、一から調べ直す必要はありません。 ### 依存関係の連鎖と循環 デプロイ間の依存関係を上流・下流にたどり、サービス間の最短経路を特定します。循環する依存関係も、インシデントにつながる前に検出できます。 ### 所有チームと実際の稼働状況を把握 すべてのAPIに、所有チームとデプロイの情報が記録されます。New Relicを接続すると、実際に何が稼働しているか、最後に確認されたのはいつかという情報も追加されます。こうした実行時の情報は、リポジトリだけでは得られません。 --- *知りたいことをそのまま質問* 自然な言葉で質問するだけです。APIやサービスを横断して、たとえば次のような質問に答えられます。 ### このエンドポイントを変更すると、どこに影響しますか？ ### このAPIに依存しているサービスはどれですか？ ### 実際にこのエンドポイントを呼び出しているのは誰ですか？ ### 最も多く依存されているサービスとスタブはどれですか？ --- ## 468のリポジトリを対象にベンチマーク 8つの質問を3つのモデルで検証し、Context Graphを使う場合と使わない場合で、それぞれ3回ずつ実行しました。モデル、質問、使用するツールはすべて同じ条件です。 _Source: 2026年9月に、468のリポジトリと3つのモデルを対象に、計144回のベンチマークを実施しました。コストには、初回のみ必要なグラフの構築と継続的な再取り込みにかかるコストは含まれていません。_ **29%** プロンプトトークンを削減 **17%** 1回の実行あたりのツール呼び出しを削減 **27%** 1回の実行あたりのコストを削減 --- ### システムをまたぐ質問で、プロンプトトークンを削減 **モデルがコードを読む前にグラフへ問い合わせた場合の、プロンプトトークンの削減率を示しています**。468のリポジトリを対象にOpus 4.7で検証した結果で、8つの質問のうち削減率が最も大きかった3つを掲載しています。質問1つあたりのツール呼び出しが69回から57回に減ったことで、やり取りの回数が減り、トークン数も削減されました。 --- ## 利用を開始 Postmanで用意済みの質問を実際のAPIに送信し、Context Graphを直接試すことができます。 1. Context Graphでは認証が必要です。クエリを実行する前に、Postmanアカウントにサインインしてください。 2. リクエストの［Authorization］タブに[Postman APIキーを追加](https://learning.postman.com/docs/reference/postman-api/authentication)してください。**** アクティブな環境を「Context Graph API」に設定してください。****__ 4. グラフはチームごとに構築されます。現在サインインしているチームのノードが取り込まれ、そのチームのグラフがクエリの対象になります。 5. リクエストボディのクエリを編集して、質問したい内容を指定してください。**** 取り込まれたグラフは、Postmanのホームボタン ＞［Agent Context］からいつでも確認できます。**** [Context Graphに問い合わせる](https://www.postman.com/postman/postman-context-graph-api/http-request/jhcu2uf/submit-a-context-graph-ask?sideView=agentMode) --- ## 複数のリポジトリにまたがる変更で、Context Graphがどう役立つかをご覧ください [複数リポジトリにまたがる変更の例を見る](https://blog.postman.com/multi-repo-api-changes-with-the-postman-ai-engineer/) --- *リソース* ## Context Graphをさらに詳しく知る ### ループエンジニアリング：プロンプトではなく、ループで進める AIエージェントにプロンプトを繰り返し与えるのではなく、実際のAPIコールを正解を判断する基準としてループに組み込みます。生成コードが推測に頼らないようにする、ループエンジニアリングの方法を紹介します。 [記事を読む](https://blog.postman.com/postman-plugin-for-openai-codex/) ### AI EngineerでAPIの3者間の不一致を検出 Postman AI EngineerとContext Graphを使って、OpenAPI仕様、コレクションのリクエスト、実際のサーバーレスポンスを比較し、3者間の不一致を検出します。 [記事を読む](https://blog.postman.com/what-passport-found-in-3-weeks-of-ai-agent-traffic/) ### AIコーディングエージェントにContext Graphが必要な理由 AIコーディングエージェントに足りないのは、より大きなコンテキストウィンドウではありません。コード、API、外部サービスの関係を把握するためのナレッジグラフです。 [記事を読む](https://blog.postman.com/introducing-the-context-graph-api-one-map-of-your-api-ecosystem/) --- ### よくある質問 ### 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が効果を発揮するのは、リポジトリやサービスなどの境界をまたいで情報を確認する場合です。 ### Context Graphは現在利用できますか？ はい、[今すぐお試しいただけます](https://www.postman.com/postman/workspace/postman-context-graph-api)。