Amazon Web Services ブログ

REST API を Amazon Bedrock AgentCore Gateway で MCP サーバー化する ― オリックス「PATPOST」での取り組み

本記事は、オリックス株式会社 法人営業本部 デジタル戦略推進室様と AWS が共同で執筆しました。

AI エージェントが実務で使われ始め、「既存の API を、エージェントから使えるようにできないか？」と考えたことがある方も多いのではないでしょうか。

本記事は、オリックス株式会社が提供する SaaS「PATPOST」の既存 REST API を、
Amazon Bedrock AgentCore Gateway で MCP サーバー化した事例です。

既存資産に手を入れずに MCP サーバー化するところまでは短時間で到達できた一方、「ユーザーごとにレスポンスが変わる API で、認証認可情報をどう引き回すか」「エージェントにとって本当に効果的なツールとは何か」という議論に発展しました。
本記事がオリックス様と同じように既存 API 資産を AI エージェントへ提供しようとしている方の参考になれば幸いです。

なお、本記事で紹介する MCP サーバーは検証（PoC）として実装したものであり、本稿執筆時点では一般提供しておらず、提供に向けた準備を進めている段階です。

背景：なぜ PATPOST を MCP サーバー化しようと考えたのか

はじめに、PATPOST がどのようなサービスかをご紹介します。

PATPOST

PATPOST は、オリックスが 2023 年 5 月から提供している、生成 AI を活用したビジネス文書管理サービスです。
スキャンした紙文書や PDF を AI-OCR と生成 AI でデータ化し、抽出した情報をセキュアな環境で一元管理できます。
お客様の社内システムと連携するための REST API を公開しており、蓄積した文書データを業務システムから直接活用できることも特徴です。

MCP サーバー化に取り組んだ動機について、PATPOST のテックリードである牧野様に伺いました。

PATPOST が MCP サーバー化に取り組んだのは、SaaS の使われ方が変わりつつあるという実感があったからです。
国内の SaaS 事業者からも MCP サーバーの公開が相次いでおり、AI エージェントから呼び出せることは、
この先の SaaS に求められる要件になっていくと考えました。だとすれば、自分たちの機能をエージェントから使えるようにするには何が必要になるのか、机上で整理するのではなく、実際に動かして確かめておきたい。それが出発点でした。そうした検討を進める中で、AWS の担当者から Amazon Bedrock AgentCore Gateway を使えば既存の API 資産を活かしたまま MCP サーバー化できるというご提案をいただき、検証を開始しました。

既存 API を改修せずに MCP サーバー化

今回は PoC という位置づけのため、既存資産に大きな改変を加えずに試したいというご要望がありました。
そこで、すでに外部公開している REST API を活かす方法を採りました。

AgentCore Gateway の「OpenAPI Target」に OpenAPI 定義を登録すると、既存 API の各エンドポイントがそのまま MCP ツールとして公開されます。つまり、既存の REST API と、その OpenAPI 定義があれば MCP サーバー化することができます。今回はこの方法を採用しました。

AI エージェントが MCP で AgentCore Gateway を経由して同じ API を呼ぶ

認証認可に関する考慮

PATPOST の API は、ログインしている利用者ごとに、その人が見てよいデータだけを返します。
利用者は API キーで識別されます。

今回は PoC のため既存資産に大きな改変は加えない方向で検討し、PATPOST がすでに利用している Amazon Cognito と、利用者ごとの API キーを活かして、認証認可情報をバックエンドまで届けることとしました。
全体像は次の図のとおりです。

認証フロー図

リクエストは次の流れで処理されます。

  1. MCP クライアントが認証なしで呼び出すと、AgentCore Gateway はリクエストを受け付けず 401 レスポンスを返します。
  2. MCP クライアントは、401 レスポンスの WWW-Authenticate ヘッダーに示されたエンドポイント
    （.well-known/oauth-protected-resource）からメタデータを取得し、
    認可サーバー（Amazon Cognito）の URL を得ます。（RFC 9728）
  3. これを受けて MCP クライアントは Amazon Cognito の認可フローを開始します。
    利用者がブラウザでログイン・同意すると、MCP クライアントはアクセストークンを取得します（OAuth 3LO）。
  4. クライアントは取得したアクセストークンを付けて呼び出し直します。
  5. AgentCore Gateway は Cognito が発行したトークンを検証します。
  6. 検証済みトークン（JWT）から利用者 ID を取り出します。
  7. その利用者に対応する API キーを Amazon RDS から取得します。
  8. 取得した API キーを、バックエンドへ送るリクエストのヘッダに付与します。

このうち 6 から 8 で用いているのが、2025 年 11 月に提供が始まった AgentCore Gateway の Interceptor です。Interceptor は、AgentCore Gateway に届いたリクエストをバックエンドへプロパゲーション（伝搬）する前に、
独自の処理を差し込める仕組みです。

なお、Interceptor がリクエストの内容（Authorization ヘッダ＝JWT）を読み取れるようにするには、
AgentCore Gateway 側で受信ヘッダを Interceptor へ渡す設定（passRequestHeaders）を有効にしておく必要があります。

この結果、PATPOST 側は「利用者本人から呼ばれた」のと同じ形でリクエストを受け取れます。
既存資産には手を入れず、利用者ごとのデータの出し分けを保ったまま MCP サーバー化することができました。

残る論点

この構成には、既存資産を活かせること以外にも利点があります。バックエンドへ渡す認証情報（API キー）を
Interceptor の中で組み立てているため、認証情報がエージェントの実行環境やモデルのコンテキストに乗りません。
プロンプトインジェクションなどでモデル側から認証情報が漏れる経路を作らずに済みます。

また、この構成では、インバウンド認証で受け取った JWT をそのまま下流へ渡していません。
インバウンドの JWT は AgentCore Gateway を宛先として発行されたトークンであり、
これをそのまま下流 API に渡す（token passthrough）と、必要以上の権限を持つトークンの流用や権限昇格を招く、
いわゆる confused deputy 問題につながります。MCP の認可仕様でも、MCP サーバーがクライアントから受け取ったトークンをそのまま背後の API に渡してはならない（MUST NOT）とされています。今回は JWT を下流に流さず、AgentCore Gateway の内側で利用者ごとの API キーに置き換えているため、この問題を避けられています。

一方で AgentCore Gateway には、アウトバウンド認証の仕組みとして IAM・API キー・OAuth といった方式が用意されており、OAuth のグラントタイプの 1 つとして OBO（On-Behalf-Of トークン交換）も選択できます。ただし、アウトバウンド認証の API キーはターゲットに 1 つのキーを紐付ける方式のため、PATPOST のように利用者ごとに異なる API キーを使い分けることはできません。利用者ごとの最小権限のクレデンシャルを下流に渡すなら OBO が候補になりますが、その場合はバックエンド側が交換後のトークンを受け取って検証する対応が必要になります。今回は本体に手を入れない方針だったため、先述の構成を採用しました。

オリックス様コメント

最後に、今回の取り組みについて牧野様よりコメントをいただきました。

PATPOST では約 2,300 社（※）のお客様の文書をお預かりしているため、「誰がどのデータを見てよいか」という境界を保つことを最優先にしています。

人が画面から使う場合、ログインしている本人が誰かは分かります。しかしエージェントがユーザーの代わりに API を呼ぶようになると、この情報が途中で失われてしまいます。

今回の検証では、PATPOST 本体に手を入れないという方針のもとで、すでに利用している Cognito と利用者ごとの API キーを活かし、この課題を解決できました。

今後もこの前提を守りながら、MCP を活用したプロダクトの展開を進めていきたいと考えています。

※ 2026 年 8 月 31 日時点

エージェントにとって「効果的なツール」

ここまでで、既存の REST API に手を入れることなく、そのまま MCP ツールとして公開できました。ただ、API をそのまま 1 対 1 でツールにすることが、エージェントにとって最適とは限りません。REST API は、リソース単位の細粒度な操作を提供し、それらをクライアント側で組み合わせて目的を達成する設計が一般的です。例えば「一覧を取る → ID を指定する → 詳細を取る」といった呼び出しの連鎖です。この粒度のまま MCP ツールとして公開すると、エージェントによる呼び出しの往復が増え、その分だけ消費するトークンやコンテキストも膨らみます。

AgentCore Gateway の Target にできるのは OpenAPI 定義だけではありません。独自の処理を実装した AWS Lambda 関数も Target にすることができます。Lambda Target を使うとバックエンドの API にもエージェント側にも手を入れずに、ツールを設計し直すことができます。たとえば、複数回に分かれた呼び出しを 1 つのツールにまとめる、返ってくるデータをエージェントが読みやすい形に整える、よく使う操作を「1 つの意図 ＝ 1 つのツール」として提供する、といった形です。

OpenAPI Target と Lambda Target の対比。左は API と 1 対 1 のツールが並ぶ素通し、右は Lambda で集約・整形して 1 つの意図を 1 つのツールとして返す

PATPOST の API の形を模したモックバックエンドを用意し、「対象期間の請求書の合計金額を算出する」というタスクで、OpenAPI Target と Lambda Target の 2 つの構成を比較したところ、
Lambda Target では消費トークンと呼び出しの往復回数は大幅に削減され、処理時間も短縮されました。

PATPOST でも公開に向けて、適切なツール設計を意識して取り組むこととなりました。

まとめ

今回は、オリックス株式会社が提供する SaaS「PATPOST」の既存 REST API を、Amazon Bedrock AgentCore Gateway で MCP サーバー化する取り組みを振り返ってきました。分かったことを、あらためて 3 つに整理します。

まず、「MCP サーバー化する」ことは、既存の資産に手を加えずにマネージドに実現できました。既存の REST API とその OpenAPI 定義さえあれば、OpenAPI Target に登録するだけで各エンドポイントがそのままエージェントのツールになります。

次に、認証認可の観点です。PATPOST は利用者ごとにデータを出し分ける設計のため、既存の Amazon Cognito と利用者ごとの API キーを活かし、Interceptor の中で認証認可情報を API まで届けています。
この手作りの部分を、OBO のような標準的な仕組みにどこまで寄せられるかは、引き続き検討していきたいテーマです。

そして、API をそのまま 1 対 1 でツールにするのが、エージェントにとって最適とは限りません。
Lambda Target や Interceptor を使えば、バックエンドの API にもエージェントにも手を入れずに「ツールの呼び出し方」を設計し直せます。

本記事が、皆様のエージェント利活用の参考になれば幸いです。

参考リンク

著者について

牧野 友

牧野 友 / Yu Makino

オリックス株式会社 法人営業本部 デジタル戦略推進室。ビジネス文書管理サービス「PATPOST」のテックリード。社内の開発チームとパートナー企業と協働しながら、
AWS 上でのアーキテクチャ設計・開発・運用を担当している。
生成 AI の実務適用に関心がある。

鯨田 連也

鯨田 連也

アマゾン ウェブ サービス ジャパン合同会社の AI Specialist Solutions Architect として、
日本における Amazon Bedrock AgentCore の技術支援をリードしており、業界を問わず様々なお客様とともに、Agent の開発、Agent 基盤の設計、LLM のファインチューニングに
取り組んでいます。AWS 入社前は、データサイエンティストとして深層学習モデルの開発や Agent を活用したソリューションの構築に従事していました。
2025年度に Japan AWS Top Engineer および AWS Community Builder に選出。

池田 優

池田 優 / Yu Ikeda

アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。
金融領域のお客様を中心にご支援しています。