目的を伝えるだけで、AIが自分で段取りを決め、作業を最後まで進める。生成AIの使われ方は、そうした自律的な動きへと軸足を移しつつある。AIエージェントと呼ばれるこの主体が実際に手を動かすとき、その裏側では外部のサービスやデータに絶えずアクセスしている。人に代わって動くものが増えるほど、その動きをどう管理するのかという問いが重みを増していく。
この問いは、AIの活用を社内で本格的に広げようとする企業が、遅かれ早かれ向き合うことになる論点である。今回は、APIのプラットフォームを手がける Postman に、AIエージェントの普及が組織にもたらす課題と、同社が一般提供を始めた新しい基盤について、FINDERS読者にも分かる形で解説してもらった。
AIエージェントは、APIを通じて動いている
いまのソフトウェアは単独では完結しない。あるサービスが別のサービスの機能やデータを借りることで成り立っており、その借り受けの窓口がAPIである。人が使うアプリも、この窓口を通じて地図や決済、在庫といった機能を呼び出している。
AIエージェントが仕事をするときも、やっていることの本質は同じだ。顧客の情報を調べる、見積もりをつくる、社内システムに記録する。どの作業も、対応するAPIを呼び出すことで実現される。人と違うのは、その回数と速さである。人が一日に扱えるAPIの呼び出しには限りがあるが、エージェントは休みなく、しかも何十、何百という単位で並行して動く。一つの目的のために複数のAPIをまたいで連続的に連携することも珍しくない。
いまの仕組みは、人とアプリのために作られている
ここで問題になるのが、既存の仕組みが置かれている前提である。APIへの出入りを受け付け、その可否を管理する役割を担うのが、ゲートウェイと呼ばれる仕組みだ。これまでのゲートウェイは、人間の利用者か、人が操作するアプリケーションを想定して設計されてきた。利用者の数もアクセスの頻度も、ある程度は見通せる範囲に収まっていた。
自律的に動くエージェントは、この前提から外れる。複数のAPIを横断して絶え間なく連携し続ける主体を、従来のゲートウェイは想定していない。米調査会社のガートナーは、AIワークロードの増加によって既存のAPIゲートウェイの能力が通用しなくなり、2029年までに組織の8割が、ゲートウェイの入れ替えか大幅な機能強化を迫られると予測している。あわせて同社は、エージェントが使う新しい通信の方式に確実に対応することが、認められていないAIの動作や、管理の及ばないやり取りを防ぐうえで欠かせないと指摘している。
少し補っておくと、エージェントの世界では、従来のWebのAPIとは異なる新しい通信の約束事が急速に広がっている。代表的なものがMCPとA2Aだ。MCPは、AIが外部のツールやデータに標準化された形でつながるための方式で、ここ一年ほどで業界の共通基盤として定着しつつある。A2Aは、エージェント同士が互いの存在を認識し、直接やり取りするための方式である。いずれもAIエージェントを語るうえで外せないキーワードになりつつあり、裏を返せば、組織が守るべき接続の種類そのものが増えているということでもある。
統制がないまま進むと、何が起きるか
管理が追いつかないまま導入だけが進むと、いくつかのほころびが出てくる。エージェントが、本来は触れるべきでないデータやシステムにアクセスしてしまう。誰のどのエージェントが、いつ何を呼び出したのかを、運用する側が把握できない。問題が起きてから記録をたどろうとしても、全体像が見えない。
一つ一つのエージェントに個別の接続を作り込んでいけば、当面は動く。しかしエージェントの数が増え、つなぐ先が増えるほど、こうした個別対応は積み重なり、全体を見通すことが難しくなっていく。守るべき対象が際限なく広がっていくという点では、FINDERSでも先に紹介したAPIの資格情報の管理と同じ構図である。
Fabric Gatewayが置く、一枚の統制の層
Postmanが一般提供を始めた Fabric Gateway は、この課題に対して、エージェントとAPIのあいだに統制のための層を一枚はさむ、という答えを示す製品である。
仕組みとしては、顧客自身のクラウド環境に単一のゲートウェイを置き、そこを通して、大規模言語モデル、エージェントが使うツール群、社内のAPI、そしてエージェント同士のやり取りを束ねる。エージェントが何を見つけられるか、何にアクセスできるか、どの操作を実行してよいか。その範囲を一箇所で定め、適用する。
イメージとしては、大きなオフィスビルの受付と警備に近い。来訪者が自由に歩き回るのではなく、受付で身元を確かめ、入ってよい階や部屋を決め、出入りの記録を残す。Fabric
Gatewayは、APIという建物に出入りするエージェントに対して、この受付の役割を一手に引き受ける。
Postmanの共同創業者兼CEOであるアビナブ・アスタナは、エージェント型AIの広がりによって、企業がAPIファーストであることは、もはや選択肢ではなく必須条件になったと述べている。エージェントが自社のAPIを把握し、安全にアクセスできなければ事業そのものが立ち行かない以上、何を発見し、何にアクセスし、どの操作を実行できるのかを組織の側で統制できる基盤が要る、という見方である。
Fabric Gatewayの主な機能
機能をいくつかの要点に整理すると、次のようになる。
一つ目は、つなぐ先を一箇所にまとめることだ。社内のAPI、エージェントが使うツール、エージェント自身といった接続対象を、個別に連携させるのではなく、単一の窓口に集約する。管理すべき入り口が一つになる。
二つ目は、通信の方式が何であっても同じ方針で制御できることだ。従来のWebのAPIはもちろん、先に触れたMCPやA2Aといったエージェント向けの新しい方式にも対応し、権限を必要最小限に制限し、状況に応じた制御を一貫して適用する。トレンドとして急速に広がりつつあるこれらの方式に、方式ごとの守り方を個別に作り込むことなく、一つの統制の下で向き合える点がFabric Gatewayの特徴である。
三つ目は、全体を一つの画面で見渡せることだ。どのエージェントが、どのような権限で動作し、互いにどう連携しているか。セキュリティや基盤の担当者が、散らばった情報をかき集めずに一望できる。
四つ目は、接続先に障害や性能低下が生じた際に、別の経路への切り替えなどで処理の継続を図る仕組みだ。ある提供元の応答性能が低下した場合には別の経路へ切り替え、異常が継続する接続は一時的に遮断するといった備えが組み込まれている。
五つ目は、セキュリティ対策と監査を一体的に行えることだ。APIへのアクセスを実行する前に認証や権限の確認を行い、実際のやり取りについては記録を残すことで、安全性と追跡可能性を確保する。
全体を貫いているのは、発見から設計、身元の管理、方針の適用、記録までを、ばらばらの道具ではなく一つの流れとして扱うという考え方である。流れるデータを監視するだけの仕組みとは、ここが異なる。
Postmanがこの基盤を出す背景
Postmanは、APIの開発、テスト、ドキュメント化、管理を一つにまとめたプラットフォームとして知られる。世界で4,000万人を超える開発者と、フォーチュン500企業の98%を含む50万以上の組織が利用している。APIの開発や運用を長年支援してきた企業である。
同社は以前から、あらゆる企業がAPIを前提に動くようになると見てきた。そこにエージェント型AIが加わったことで、その前提は選択肢ではなく必須条件へと変わったというのが、今回の基盤を投入した背景にある。先に一般提供を始めた、資格情報を配らずにAPIへアクセスするための製品Passportとあわせて、Postmanは、AIエージェントが安全にAPIを使うための層を重ねて整えようとしている。
すでにAIエージェントを動かしている、あるいは本格的な導入を控えている。社内のシステム連携やエージェントの数が増え、どのエージェントが何にアクセスしているかを把握しきれていない。こうした状況に心当たりがあるなら、Fabric Gatewayは検討に値する。
もっとも、自社にどう当てはまるかは、システムの構成やAI活用がどの段階にあるかによって変わる。いまの接続と権限の整理から始めるべきか、特定の業務から小さく試すべきか、その入り口も組織ごとに異なる。Postmanの日本チームは、こうした個別の事情に応じた相談を受け付けている。Fabric Gatewayの一般提供は2026年9月に始まった。自社の実情に沿った使い方を具体的に知りたい場合は、日本チームへの問い合わせから始めるとよい。
詳細は Fabric Gateway の製品ページ (https://www.postman.com/jp/fabric-gateway/) で確認できる。
[関連記事]
AIエージェント時代のAPIアクセス
Postmanが資格情報を手元に残さない新製品「Passport」を一般提供
Postman株式会社
https://www.postman.com/jp/