本記事は、オリックス株式会社 法人営業本部 デジタル戦略推進室様と AWS が共同で執筆しました。 AI エージェントが実務で使われ始め、「既存の API を、エージェントから使えるようにできないか？」と考えたことがある方も多いのではないでしょうか。 本記事は、オリックス株式会社が提供する SaaS「 PATPOST 」の既存 REST API を、 Amazon Bedrock AgentCore Gateway で MCP サーバー化した事例です。 既存資産に手を入れずに MCP サーバー化するところまでは短時間で到達できた一方、「ユーザーごとにレスポンスが変わる API で、認証認可情報をどう引き回すか」「エージェントにとって本当に効果的なツールとは何か」という議論に発展しました。 本記事がオリックス様と同じように既存 API 資産を AI エージェントへ提供しようとしている方の参考になれば幸いです。 なお、本記事で紹介する MCP サーバーは検証（PoC）として実装したものであり、本稿執筆時点では一般提供しておらず、提供に向けた準備を進めている段階です。 背景：なぜ PATPOST を MCP サーバー化しようと考えたのか はじめに、 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 サーバー化することができます。今回はこの方法を採用しました。 認証認可に関する考慮 PATPOST の API は、ログインしている利用者ごとに、その人が見てよいデータだけを返します。 利用者は API キーで識別されます。 今回は PoC のため既存資産に大きな改変は加えない方向で検討し、PATPOST がすでに利用している Amazon Cognito と、利用者ごとの API キーを活かして、認証認可情報をバックエンドまで届けることとしました。 全体像は次の図のとおりです。 リクエストは次の流れで処理されます。 MCP クライアントが認証なしで呼び出すと、AgentCore Gateway はリクエストを受け付けず 401 レスポンスを返します。 MCP クライアントは、401 レスポンスの WWW-Authenticate ヘッダーに示されたエンドポイント （.well-known/oauth-protected-resource）からメタデータを取得し、 認可サーバー（Amazon Cognito）の URL を得ます。（RFC 9728） これを受けて MCP クライアントは Amazon Cognito の認可フローを開始します。 利用者がブラウザでログイン・同意すると、MCP クライアントはアクセストークンを取得します（OAuth 3LO）。 クライアントは取得したアクセストークンを付けて呼び出し直します。 AgentCore Gateway は Cognito が発行したトークンを検証します。 検証済みトークン（JWT）から利用者 ID を取り出します。 その利用者に対応する API キーを Amazon RDS から取得します。 取得した 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 つのツール」として提供する、といった形です。 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 にもエージェントにも手を入れずに「ツールの呼び出し方」を設計し直せます。 本記事が、皆様のエージェント利活用の参考になれば幸いです。 参考リンク Model Context Protocol — Authorization: Security Considerations Using interceptors with Gateway Interceptor の設定（passRequestHeaders の挙動） Set up outbound authorization for your gateway On-behalf-of token exchange with AgentCore Identity Apply fine-grained access control with Bedrock AgentCore Gateway interceptors Implement on-behalf-of token exchange for multi-tenant agents with Amazon Bedrock AgentCore Gateway 著者について 牧野 友 / 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 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。 金融領域のお客様を中心にご支援しています。

はじめに Turing では、日々たくさんの自動運転モデルを開発し、これを実車にデプロイして検証する開発サイクルを回しています。実世界でMLモデルによる自動運転システムを成立させるためには、モデル推論のレイテンシが非常にクリティカルな要素になってきます。モデルを高速に推論させるためには、低精度化や量子化、あるいはモデルの構造によってはKV Cacheなど、様々な手法が考えられます。 しかし、色々なアーキテクチャのモデルを大量に開発するTuring において、そのすべてにこうした技術を適用できるソフトウェアスタックを構築することは容易ではありません。今回の記事では、高速化技術を適用する

こんにちは、ソリューションアーキテクトの宇佐美です。 2026年7月15日(水) に開催された「Neuron Community – 2026 Vol.1」の様子をレポートします。このイベントは、2025年3月に立ち上げられた「Neuron Community」の協力のもと開催しました。 今回は、 AWS Summit Japan 2026 開催後ということもあり、AWS Summit Japan の振り返りや、AWS Neuron のアップデート情報が多めの内容となっています。 Neuron Community とは AWS では、機械学習のトレーニングと推論のための高性能で費用対効果の高い機械学習アクセラレータ（ AWS Trainium 、 AWS Inferentia ）、および深層学習と生成 AI ワークロードを実行するために使用される SDK の AWS Neuron を提供しています。「Neuron Community」は、ユーザー間で AWS Trainium / AWS Inferentia / AWS Neuron の知見共有を促進する場として発足しました。 「Neuron Community」は、主に Discord を使用して運営されています。興味を持っていただいた方は、下記の URL から参加してみてください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq オープニング：Neuron Community の成り立ちとカラクリ社での Trainium 取り組み紹介 中山 智文 氏（カラクリ株式会社 取締役 CPO) 資料：後日公開 オープニングセッションでは、カラクリ株式会社の中山氏より発表していただきました。カラクリ株式会社は、2023年より一貫して AWS Trainium を利用し続けており、Neuron Community の立ち上げにも大きな貢献をしていただいています。この発表では、Neuron Community の始まりについて紹介していただきました。また、カラクリ株式会社の AWS Trainium に関する2つの取り組みについても紹介していただきました。1つ目の取り組みは、Amazon EKS 上に構築された 「Neuron 分散学習プラットフォーム」 です。このプラットフォームを構築することで、インフラ関連の知識が十分ではないメンバーでも分散学習を実行できる環境の整備を進めているそうです。2つ目の取り組みは、AWS Trainium の NKI カーネル開発を促進するための 「カーネル開発エージェント」 です。この AI エージェントにより、NKI カーネル開発をエージェントが自律的に進められるようになるということです。最後に、今後の Neuron Community の活動について、よりオープンな場にしていきたいという発信をしていただきました。 AWS Summit Japan 振り返り① セッションダイジェスト「⼤規模学習から AI エージェントの推論まで ~ コスト効率と性能が両⽴する AWS Trainium の全貌 ~」 澤 亮太 (Amazon Web Services Japan G.K.) 資料： “AI エージェントの推論から⼤規模学習まで” コスト効率と性能が両⽴する AI インフラ ̶ AWS Trainium の全貌 Amazon Web Services Japan G.K. の澤からは、 AWS Summit Japan 2026 の振り返りとして、「”AI エージェントの推論から大規模学習まで” コスト効率と性能が両立する AI インフラ ー AWS Trainium の全貌」のセッションを、15 分のダイジェスト版で紹介しました。このダイジェストでは、AWS Trainium の典型的な使い方として、 “A. コードはそのままで学習コストを下げたい” 、 “B. 性能を最適化したい” 、 “C. 推論コストを固定化したい” の3点に注目して説明しました。 A. では、 Native PyTorch support（ベータ版） を使い、GPU向けPyTorchコードのデバイス指定を cuda から neuron に変更して、AWS Trainium 上で学習を実行する方法を紹介しました。デモでは、GPT-2 の学習スクリプトを実行しました。B. では、 NKI (Neuron Kernel Interface) により AWS Trainium のハードウェア命令セットに直接アクセスして AI カーネルの最適化が可能であることを紹介しました。また、性能最適化とデバッグのワークフローを支援する Neuron Explorer、NKI の開発を AI エージェントで加速するためのオープンソースツールキットの “Neuron Agentic Development” についても紹介し、Neuron Agentic Development のデモを見ていただきました。C. では vLLM on Trainium を使うことで、オープンウェイトモデルをAWS Trainium 上でサービングできます。ここでは、openai/gpt-oss-20b モデルを AWS Trainium 上でサービングするデモを見ていただきました。 AWS Summit Japan 振り返り② ブース展示紹介「⽣成 AI を⽀えるインフラ技術」 赤澤 Toshinobu (Amazon Web Services Japan G.K.) Amazon Web Services Japan G.K. の赤澤からは、 AWS Summit Japan 2026 の振り返りとして、ブース展示「生成AIを支えるインフラ技術」について紹介しました。この展示は、複数のマルチモーダルモデルを Amazon EC2 trn2.48xlarge でサービングする様子を見ていただくもので、マルチモーダルモデルで画像の編集を行います。音声で画像編集の指示をすると Whisper Large v3 で音声認識を行い、Qwen3-VL-8B-Instruct で元になる画像を編集するための指示を生成します。指示は Qwen-Image-Edit-2511 に渡され、画像が編集されます。編集された画像は、Qwen3-VL-8B-Instruct を使って指示通りに編集できているかを講評し、XTTSv2 で音声出力します。この発表では、３匹の子猫のイラストを、4匹に増やすという画像編集の様子を見ていただきました。 また、このデモを実現しているアーキテクチャについての説明も行いました。4つのモデルのtrn2.48xlarge の 64 論理コアへのアロケーションや、モデルのデプロイフローなども説明しています。 AWS Trainium / Inferentia / Neuron SDK 最新アップデート 常世 大史 (Amazon Web Services Japan G.K.) 資料： Neuron Communit 2026 Vol.1 AWS Trainium / Neuron 最新アップデート Amazon Web Services Japan G.K. の常世からは、ちょうどイベント前日にテレビ東京の WBS（ワールドビジネスサテライト）で AI 向けアマゾン独自の半導体開発が特集 されたことに触れ、自身が所属するアマゾン内のチップ開発部隊「アンナプルナラボ」について紹介しました。Anthropic との共同プロジェクト Project Rainier では、これまでに 140 万個超の Trainium 2 および Trainium 3 チップが稼働中であること（WBS 内の特集にて紹介）、 OpenAI が 2GW 規模での Trainium 採用を発表 したこと、また従来のチャットボット型 AI からエージェント型 AI へとシフトする中で、AI チップに加え AWS Graviton プロセッサの重要性が増している点を紹介しました。 Meta が数千万の Graviton コアで Agentic AI をスケールしている事例 にも触れました。 次に、澤のセッションでも紹介された AWS Trainium 向けの SDK「AWS Neuron」のアップデートとして、ライブラリのネイティブ化（Native PyTorch、Native vLLM）の最新状況を紹介しました。 また、7 月 7 日にリリースされた最新の Neuron 2.31 では、性能最適化の要である NKI（Neuron Kernel Interface）と NKI Library に大きなアップデートがあった点、さらに NKI カーネル開発用のエージェントコーディング機能 Neuron Agentic Development によるカーネル自動最適化ループへの注力を紹介し、セッションを締めくくりました。 ※ イベント開催後の 2026年7月20日(月) に vLLM Neuron Beta がパブリックリリースしました！ さいごに 通算3回目の Neuron Community は、カラクリ株式会社での AWS Trainium への取り組みの発表や、AWS Summit Japan 2026 の振り返り、AWS Neuron 関連の最新アップデート情報の紹介と、充実した内容となりました。AWS Summit Japan 2026 のセッション動画は、 AWS Summit Japan の Web ページ に登録いただくことでオンデマンド視聴が可能です。ご興味のある方は、ぜひ登録してみてください。 発表後には今後の Neuron Community についてのディスカッションも行われ、約 1 年ぶりの開催となったことを踏まえ、より高い頻度で開催していこうという声が挙がりました。AWS としても積極的に支援していきます。 今後の Neuron Community も、Discord を中心に募集や告知を行っていきます。興味を持っていただいた方は、ぜひ、下記の URL から参加してみてください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq 著者について 宇佐美 雅紀 (Usami Masanori) 製造業のお客様を担当するソリューションアーキテクトです。 製造業のお客様のクラウド活用を支援しています。 常世 大史 (Tokoyo Hiroshi) AWS Annapurna Labs のソリューションアーキテクトです。 Annapurna Labs が提供する AWS Trainium、Inferentia の技術支援に注力しています。