AIエージェント統制はAPIから——押さえるべき5つの要素

「エージェントを掌握できなければ、いずれ会社がエージェントに振り回される」——Postmanはこう警鐘を鳴らします。Shadow AIや過剰な権限付与がもたらすリスクに直面する今、これは現実の話です。エージェントはAPI経由で能力を得るため、APIの可視化とアクセス制御が統制の起点になります。前半では、AIエージェントの普及で今なにが起きているのかを調査データを交えてひも解き、企業がコントロールすべき5つの要素を整理。後半でPostmanの新しい製品群Agent Stackを紹介します。AI×Security Conference 2026での発表資料です。

Transcript

1. AI エージェント統制は API から —— 押さえるべき５つの要素 あなたのエージェント、 "何に"アクセスできるか把握していますか？ 草薙 昭彦 テクノロジーエバンジェリスト © All rights reserved by Postman Inc
2. 今起きていること ソフトウェアはもはや、人間が主体として作成・利用・調整するものではな い ソフトウェアが他のソフトウェアを発見し、連携し、動かす時代に その新しいソフトウェアが AI エージェント エージェントは API を通じて能力を得る データ収集・アクション実行・記憶・人やマシン、他エージェントとのやり取り エージェントは絶大な力を持ち、今後さらに大きくなっていく 大きな力にはリスクが伴う
3. 判断を業務の実行に変えるのがツールと API ✦ 例：銀行の問い合わせ対応エージェント ✦ エージェントの判断はツールや API を通じて業務操作になる ✦ その接点で制御できる。そこで API から統制する 依頼 エージェントの判断 ツール／ API 業務システム 「取引を調べて」 履歴を照会し対応を 検討 取引照会・返金・ 回答作成 口座・取引・顧客 対応システム 制御点 誰の権限で／何のデータに／どの操作まで
4. 操作に対するポリシーの設定例 本人の取引履歴を閲覧 自動実行を許可 他人の口座情報を閲覧 禁止 返金・資金移動 人の承認が必要 顧客への回答作成 下書きまで自動 外部モデルへの情報送信 必要な情報に限定し 機微情報は処理 ※企業一般の正解ではなく、説明のために設定したルール
5. 公的機関が相次いで API の点検を求めている （2026年10月） 個人情報保護委員会 （10月7日） JPCERT/CC （10月8日） NICT（10月13日） NCO 情報集約（ 10月14日） WARNING 事例9「API が悪用され る事例」 「API 経由での不正な操作」を攻撃 類型として明記 公開アプリからバックエンド API を 突く「A2B 攻撃」を特定 ✦ 管理対象から漏れた API、パラ メータ変更で他人のデータを取 得（認可不備）、不要な応答、連 番 ID、レート制限欠如 ✦ 各エンドポイントでアクセス制御 ✦ 相次ぐ漏えいを受け、関係省庁 ・専門機関が相次ぎ公表 ✦ 対策: API の棚卸しと、呼び出し の都度の認可確認 ✦ API 利用者・トークンに最小権 限と短い有効期限 ✦ 国家サイバー統括室（ NCO）が 9機関分を集約
6. 連携トークンの悪用 —— ログインを守っても残るリスク Salesloft のチャットボット Drift の事例 （2025年8月8日〜18日） Salesloft への不正アクセス ✦ 窃取された OAuth トークンで Salesforce にアクセス し、大量データ取得と資格情報を探索。トークンは後に 失効措置。影響は顧客により「可能性」と「流出確認済 み」に分かれる OAuth トークンが盗まれる ✦ 正規の資格情報が盗まれ、正規の呼び出しとして使わ れた。ログインの多要素化だけでは防ぎきれない 正規の資格情報として使用 ✦ この事例から、付与済みトークンの管理（最小権限・短い 有効期限・速やかな無効化）と記録・追跡が求められて いる 正規の呼び出しでデータ取得 GitHub アカウント、AWS 環境に侵入 連携サービス用に保管されていた 盗んだトークンで認証を通過 Bulk API 等で大量に照会 ログインの 多要素化 などでは 防げない
7. エージェント特有の失敗の例 問い合わせ文に紛れた指示を 業務指示と取り違え 顧客情報を外部へ送ろうとする 実行できる範囲を 制限できるか？
8. 統制すべき５つの要素 01 Trust（信頼・判断） エージェントの判断と振る舞いを目的に照らして評価 し、信頼できる範囲を定める 02 Access（アクセス・行動） 必要なデータや機能を発見・利用できるようにし、実行 できる範囲を制御する 03 Govern（ガバナンス・リスク） 行動のルールと責任を定め、遵守の確認と問題発生 時の対応を可能にする 04 Scale（拡張・運用） エージェントの数や利用範囲が増えても、統制と安定 運用を維持する 05 ROI（投資対効果・予算） コストと成果を把握し、投資の妥当性を判断する Trust・Access・Governで『安全に任せる条件』を決め、Scale・ROIで『継続運用できるか』を見る
9. ５要素を先ほどのポリシー表に当てはめると Trust Access Govern Scale ROI 判断への信頼 利用・実行範囲 ルールと責任 拡大・運用 投資対効果 増えても 共通ルールを 維持 成果と コストを 評価 本人のデータだけ 本人の取引履歴を閲覧 認可で遮断 他人の口座情報を閲覧 判断が方針に沿うか 人の承認フロー 返金・資金移動 下書きまで自動 顧客への回答作成 送信先の信頼 外部モデルへ送信 送る情報を限定 機微情報を処理
10. エージェントを想定していない既存ツール エージェント 従来のオブザーバビリティツール 誰が何の目的でエージェントを使っているのか見えない 従来型 IAM・シークレット管理 必要最小限の権限ではなく、シークレットそのものと過剰な権限 を渡してしまう GRC・監査プラットフォーム 問題発生時に責任の所在が不明確 クラウドコスト／FinOps ツール エージェントのコストが見えず、 ROI は推測に頼るしかない API ゲートウェイ・運用ツール エージェントが増えるほど、管理の目が届かなくなる API ツールごとにサイロ化 しており、エージェント の動作を横串で制御 できない
11. エージェントライフサイクルと API を通じた統制 API を整備・公開 発見し接続 実行・通信制御 検証・観測・改善 設計・ドキュメント・公開 必要な機能を見つけ繋ぐ 動かし、通信を統制 確かめ、見て、直す Fabric エージェントゲートウェイ AI、MCP、API のための AI ネイティブなゲートウェイ。エンタープライズ のエッジにおいて、ポリシー、ID、スコープを統制 API とコンテキストを供給 Passport アクセス管理 人間およびエージェントのためのアクセス管理。スタック全体を通じて、誰 が（あるいは何が）API にアクセスできるかを制御する Postman AI ネイティブ API プラットフォーム API 設計・テスト・コラボレーションのためのツール群と、 API カタログ ・API ガバナンス機能を提供する統合基盤 API とコンテキストを供給
12. API側：データ単位の認可をテストで確かめる データ単位の認可をテストで確かめる 成功すべきケース 拒否されるべきケース 利用者 Aの資格情報で、A 自身のデータを取得 利用者 A の資格情報で、利用者 B のデータを取 得しようとする → 正常に成功する（期待どおり） → 拒否される。ステータスコードだけでなく、応答 に他人のデータが含まれないことまで確認
13. Insert Slide Title 鍵を持たせず承認された Here API にアクセス FIG. 01 CONTROL MAP 01 The proxy swaps the reference for the real secret, inside your cloud. Discover and request Receive a reference, never the secret. YOUR CLOUD 01 CREDENTIAL REFERENCE 02 Caller orders-api-key VERIFIED 02 Secure Access Proxy Validate and proxy The secret stays inside your cloud. Secret store api key 03 Attribute every call Complete accountability by identity. 03 ATTRIBUTED REQUEST API
14. 通り道で制御する
15. まとめ：エージェントに振り回されないために ✦ エージェントの力は API という接点から ✦ 公的機関も API 認可の点検やトークン管理を求めている ✦ 統制すべきは５要素：Trust、Access、Govern、Scale、ROI ✦ 個々の対策はある。足りないのは、エージェントの行動を通してつなぐこと ✦ 自社の対策を５要素で見直し、統制が途切れている接点の確認を