「REST API→MCP化」で何が問題に？ オリックスが探った“認証・認可とトークン消費”への対処法：既存APIを生かす“2つの工夫”

既存のREST APIをMCPサーバ化する際、利用者ごとのアクセス制御や、ツールの呼び出し回数に伴うトークン消費が課題となる。オリックスはAWSのサービスを使った検証で、既存APIを改修せずにこれらの課題に対処する方法を探った。

[＠IT]

　AIエージェントからAPIを呼び出す際、利用者ごとのアクセス権限をどう維持するのか。複数のAPI呼び出しによって増大するトークン消費をどう抑えるのか――。

　既存の「REST API」を「MCP」（Model Context Protocol）に対応させる上では、単にAPIをMCPツールとして公開するだけでなく、認証・認可の仕組みやAIエージェントに適したツール設計を考慮する必要がある。

　Amazon Web Services（AWS）は2026年10月1日、オリックスが提供するビジネス文書管理サービス「PATPOST」のREST APIを、MCPサーバ化した検証事例を公式ブログで公開した。これを基に、既存のAPIをMCPに対応させる際に生じる課題と、その解決に向けた具体的な実装方法を紹介する。

既存APIを改修せずにMCP化、課題となった認証・認可

　オリックスは2023年5月から、生成AIを活用したビジネス文書管理サービスであるPATPOSTを提供している。スキャンした紙文書やPDFをAI-OCRと生成AIでデータ化し、一元管理できるものだ。

　国内のSaaS事業者からMCPサーバの公開が相次いでいることを踏まえ、オリックスは、AIエージェントから呼び出せることが今後のSaaSに求められる要件になると考えていた。そこで、自社の機能をエージェントから使えるようにするには何が必要かを、実際に動かして確かめることにしたという。

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

　PATPOSTのAPIは、ログインしているユーザーごとに、その人が見てよいデータだけを返す。そのため、AIエージェントがユーザーの代わりにAPIを呼ぶ場合、利用者ごとのデータの出し分けをどう維持するかが課題となった。

　オリックスは、AWSの提案を受けて、既存のAPI資産を生かしたままMCPサーバ化するPoC（概念実証）に取り組んだ。既存の資産に大きな改変を加えないことが前提だった。

　採用したのは、AWSのAIゲートウェイサービス「Amazon Bedrock AgentCore Gateway」だ。Amazon Bedrock AgentCore Gatewayの「OpenAPI Target」にOpenAPI定義を登録すると、既存のAPIの各エンドポイントがそのままMCPのツールとして公開される。

　これにより、既存APIを改修することなく、AIエージェントからPATPOSTの機能を呼び出せるようになった。

ユーザーごとのアクセス権限をどう維持した？

　認証認可には、PATPOSTが利用している認証サービス「Amazon Cognito」と、ユーザーごとのAPIキーを生かした。ユーザーがブラウザでログインしてアクセスを許可すると、MCPクライアントはAmazon Cognitoからアクセストークンを取得する。これは「OAuth 3LO」（3者間認可フロー）と呼ばれる仕組みで、MCPクライアントは取得したトークンを付けてAmazon Bedrock AgentCore Gatewayを呼び出す。

　その後の処理には、2025年11月に提供が始まったAmazon Bedrock AgentCore Gatewayの「Interceptor」を使った。リクエストをバックエンドへ転送する前に独自の処理を差し込める仕組みだ。

　検証済みのJWT（JSON Web Token）からユーザーIDを取り出し、そのユーザーのAPIキーを「Amazon RDS」（Amazon Relational Database Service）から取得して、バックエンドへのリクエストのヘッダに付与する。PATPOSTは、ユーザー本人から呼ばれたのと同じ形でリクエストを受け取れる。

　バックエンド用のAPIキーはInterceptor内で取得・付与するため、AIエージェントの実行環境やLLMのコンテキストに渡す必要がない。これにより、プロンプトインジェクションなどを通じてAPIキーが漏えいするリスクを低減できる。また、アクセストークンを下流のAPIにそのまま渡さないことで、トークンの利用対象や権限の検証が不適切な場合に生じ得る「confused deputy」（権限を持つシステムが第三者に悪用される問題）のリスクにも配慮した。

　Amazon Bedrock AgentCore Gatewayは、アウトバウンド認証の方式としてIAM、APIキー、OAuthを用意しており、OAuthではOBO（On-Behalf-Of：ユーザーに代わって下流向けのトークンに交換する方式）のトークン交換も選べる。ただ、APIキーの方式はターゲットに1つのキーをひも付けるため、ユーザーごとのAPIキーを使い分けられない。OBOはバックエンド側の対応が必要になるため、今回はPATPOST本体を改修しない方針から採用しなかった。

APIをそのままMCP化するとトークン消費が増える？

　APIを1対1でそのままツールにすることが、エージェントにとって最適とは限らない。REST APIは、一覧を取得し、IDを指定して詳細を取得するといった細かい操作を組み合わせる設計が一般的だ。この粒度のままツールにすると、エージェントの呼び出しの往復が増え、消費するトークンやコンテキストも膨らむ。

　Amazon Bedrock AgentCore Gatewayは、独自の処理を実装した「AWS Lambda」の関数もターゲットにできる。このLambda Targetを使えば、バックエンドのAPIにもエージェント側にも手を入れずに、複数回の呼び出しを1つのツールにまとめたり、返すデータをエージェントが読みやすい形に整えたりできる。

　PATPOSTのAPIを模したモックバックエンドで、「対象期間の請求書の合計金額を算出する」タスクを使って比べたところ、Lambda TargetはOpenAPI Targetよりトークン消費量とツール呼び出しの往復回数が大幅に減り、処理時間も短くなったという。

　PATPOSTのMCPサーバは検証として実装したもので、一般提供に向けて準備を進めている段階だ。オリックスは、公開に向けて適切なツール設計に取り組むとともに、Interceptorで作り込んだ認証認可の部分を、OBOのような標準的な仕組みにどこまで寄せられるかを引き続き検討するという。

本稿は、Amazon Web Services（AWS）が2026年10月6日に公開した公式ブログの記事を基に作成しました。