生成AIプラットフォームエンジニアリングの一例:AOAI×Bing Search MCPのAPI公開

生成AIプラットフォームエ ンジニアリングの一例 AOAI×Bing Search MCPのAPI公開

◼ ◼ ◼ 自己紹介 生成AI×プラットフォームエンジニアリン グ(PFE) 生成AI PFEの一例 ：AOAI×Bing Search MCP のAPI公開

自己紹介 ◼ 名前：折田菜津子 ◼ 会社：株式会社 エーピーコミュニケーションズ ◼ 主な業務 ⚫ プラットフォームエンジニアリング • 開発者向けのガードレール策定(自動化含む) ◼ 趣味 タロット(ほぼ毎日1枚引きしています)

テーマのきっかけ(イントロダクション) プラットフォームエンジニアリングの業務に携わる中で、 開発チーム（SAチーム）向けに単なるインフラテンプ レートの提供にとどまらず、AI駆動開発の基盤づくりの重 要性を実感しました。そこで、個人的な趣味としてAzure openn AI Service及びBing Search MCPの API公開に関する 検証を行いました。 今回は、その検証過程で得た気づきや工夫した点について、 ご紹介したいと思います。

生成AI×プラット フォームエンジニアリ ング(PFE)

プラットフォームエンジ ニアリング(PFE)とは

プラットフォームエンジニアリング(PFE)の概要 開発者がセルフサービス型でプラットフォームの構築や運用を行えるよう支援するサービ スや専門分野を指す。内部開発プラットフォーム（IDP）は、APIやクラウドインフラ、 CI/CDツール、モニタリングなどの幅広い機能を備えており、プラットフォームチームと いう専門チームがこれを提供することで、開発プロセスを効率化し、開発者の負担を軽減 する。

PFEが注目されている背景 ◼ システムの複雑化と開発者の認知負荷増大 ◼ DevOpsの課題 ◼ DXの推進によりスピーディーな開発が求められている

PFEが注目されている背景 ◼ システムの複雑化と開発者の認知負荷増大 ◼ DevOpsの課題 ◼ DXの推進によりスピーディーな開発が求められている 近年、コンテナ、マイクロサービス、サーバーレスなどの技術が急速に普 及し、開発の柔軟性は向上した。しかし、その一方で、開発者が扱うべき ツールや知識の範囲が拡大し、システム構成の複雑化が進んでいる。これ により、開発者はアプリケーション開発に加え、インフラの管理や運用、 セキュリティ対策、ツールの連携など、多岐にわたる業務を担う必要が生 じ、「認知負荷」が増大した。

PFEが注目されている背景 ◼ システムの複雑化と開発者の認知負荷増大 ◼ DevOpsの課題 ◼ DXの推進によりスピーディーな開発が求められている DevOpsの導入により、開発と運用の協力体制が強化され、ソフトウェア開 発のスピードと品質は向上した。開発者がDevOps基盤の構築や運用まで担 うことが求められるケースが増え、結果として業務負担が過度に増加する 問題も指摘されている。

PFEが注目されている背景 ◼ システムの複雑化と開発者の認知負荷増大 ◼ DevOpsの課題 ◼ DXの推進によりスピーディーな開発が求められている DXの推進に伴い、企業は市場の変化に迅速に対応できるソフトウェア開発 を求められている。スピーディーかつ高品質な開発を実現するためには、 開発者が負担を感じることなく、効率的に作業できる環境が必要。

PFEが注目されている背景 ◼ 構成の複雑化と開発者の認知負荷増大 ◼ DevOpsの課題 ◼ DXの推進によりスピーディーな開発が求められている 解 決 開発者の負担を軽減し、コーディングに集中できる環境を整えるプラット フォームエンジニアリングが、今注目を集めています。

PFEのメリット 1.開発者の生産性向上 • インフラ管理の負担軽減で、開発に集中できる環境を整備 • 作業の自動化により、開発の効率を向上 2.ソフトウェアデリバリーの迅速化 • 標準化されたツールで、アイデアからリリースまでの時間を短縮 • CI/CDの活用で、スムーズな継続的デリバリーを実現 3.ガバナンスとセキュリティの強化 • セキュリティ対策やコンプライアンスをプラットフォームに組み込み、安全性を確保 4.運用効率の向上 • インフラ管理を集約し、開発者が運用作業の負担から解放 5.コスト削減 • 共通基盤の活用と自動化で、開発・運用コストを最適化 6.開発者の満足度向上 • 環境整備により、開発者のエンゲージメントと定着率を向上 7.スケーラビリティと柔軟性の向上 • クラウド技術を活用し、ビジネスの成長に柔軟に対応可能

DevOpsやSREとの相違点 ⚫ DevOpsより開発者の負担を軽減できる DevOpsでは、開発者が開発効率を向上させるために、CI/CD基盤や運用基盤 （Ops）を自ら整備するケースがある。一方、プラットフォームエンジニア リング（PFE）では、これらの基盤をプラットフォームチームが用意してく れるため、開発者は自身のコーディングやアプリケーション開発に専念でき る。

DevOpsやSREとの相違点 ⚫ SREの要素が一部として包含されている SREはシステムの信頼性と品質を向上させることを目的としているが、プ ラットフォームエンジニアリング（PFE）では、それだけに留まらず、 開発効率の向上やセキュリティ強化を含む、自動化されたプロセスを実現す ることを目指す。 プラットフォームエンジニアリング セキュリティ 強化 信頼性と品 質の確保 開発効率の向上

生成AI×プラットフォー ムエンジニアリング(PFE)

生成AI×PFE Gartnerは、2025年以降のソフトウェアエンジニアリングにおける主要な戦略的ト レンドの一つとして、「生成AIプラットフォームエンジニアリング」の概念を提 唱しました※1。 同社は、2027年までにプラットフォームチームを有する組織の約70％が、社内開 発者向けプラットフォームに生成AI機能を組み込むようになると予測しています。 ※1主要なソフトウェアエンジニアリングのトレンド、AIネイティブなソフトウェアエンジニアリング、生成AIプラットフォームエ ンジニアリングなど、ガートナーが発表 － Publickey

• https://www.publickey1.jp/blog/25/aiai.html

生成AI×PFEのメリット ◼ プラットフォームチーム ⚫ 単純作業や反復的なプロセスを生成AIに任せることで、複雑な課題への対応に専念 できる時間を創出 ⚫ 開発チームに提供するドキュメントや仕様書の生成・整理を効率化し、情報共有の 精度とスピードを向上 ⚫ SRE Agentなどの活用により、インシデント対応の負担を軽減し、運用の安定性を 強化 ◼ 開発チーム ⚫ コードの補完や修正提案をAIが支援することで、開発効率および品質を向上 ⚫ ベストプラクティスのリアルタイム提示による学習支援により、スキル向上とナ レッジの定着を促進 近年、生成AIによる開発や運用効率の向上に関心が高まる中、 プラットフォームエンジニアリング（PFE）への生成AIの導入は、必要不 可欠である ※1主要なソフトウェアエンジニアリングのトレンド、AIネイティブなソフトウェアエンジニアリング、生成AIプラットフォームエ ンジニアリングなど、ガートナーが発表 － Publickey

• https://www.publickey1.jp/blog/25/aiai.html

PFE×生成AI PFEに生成AIを導入するとはいっても、開発効率のほかセキュリティ面なども考慮して検討しなけれ ばなりません。 例えば、 生成AI基盤をどう提供したらいいか。。。。。 MCPはどのベンダー及び種類() (リモートMCP？ローカルMCP?)を選定するべきか。。。。 カスタムMCPをどう提供したらいいか。。。。。 次章では、PFEへの生成AI導入の一例として、Azure Open AI Service(AOAI)×Bing Search MCPのAPI公開 について、説明します！ 生成AI導入の参考になれば幸いです！

生成AI PFEの一例 AOAI×Bing Search MCPのAPI公開

API構成

API構成例 SAチーム向けに公開する場合、監視面や集約のメリットからAPI Managementを介した公開を実装します。 AI Foundary(Project) 構成イメージ AOAI Hub VNET Grounding with Bing Search(GwBS) pl-subnet 開発端末VNET(spoke) apim-subnet Web検索 Roo code コード支援 Dev box functions-subnet APIM vnet統 合 AOAI Functions(MCP) GwBS AI Foundary

APIM×AOAI実装の工夫点 ① AOAIのモデルバージョンごとに、APIのオペレーショ ンを分ける ② AOAIのモデルバージョンの自動アップデートを無効に する ③ AOAIの負荷分散とサーキットブレーカーの構成 ④ トークン制限の構成 ⑤ 余計なAPIをブロック

APIM×AOAI実装の工夫点 ①AOAIのモデルバージョンごとに、APIのオペレーションを分ける API openration 1 openration 2 例）GPT-4o-miniの20240718のバージョン(gpt-4o-mini_20240718) GPT-4oの2024-08-06のバージョン(gpt-4o_20240806) GPT-4oの2024-11-20のバージョン(gpt-4o_2024-11-20) モデルバージョンごとにオペレーションを分けることで、 開発者のカスタマイズ性が上がる

APIM×AOAI実装の工夫点 ②AOAIのモデルバージョンの自動アップデートを無効にする AOAIのモデルをデプロイすると、デフォルトでは新バージョンが使用可 能になったら自動アップデートされる。 ・デフォルト更新ポリシー Propenrties.versionUpgradeOption:"OnceCurrentVersionExpired“ バーションが上がると挙動が変わり開発者に影響する可能性があるので、 更新ポリシーを「NoAutoUpgrade」にして、自動アップデートを無効化 するとよい。 前のページで説明したように、バーションごとにAPIのオペレーション を分けて管理するとよい。 • Terraformでの自動アップデートを無効化方法 例） resource "azurerm_cognitive_deployment" "example" { name = "example-cd" cognitive_account_id = azurerm_cognitive_account.example.id version_upgrade_option = “NoAutoUpgrade” ….

APIM×AOAI実装の工夫点 ③AOAIの負荷分散とサーキットブレーカーの構成 ⚫ 負荷分散 AOAIをAPIMのバックエンドに登録す る。ロードバランサーで負荷分散を 構成し、アクティブ・スタンバイ構 成においては、primaryバックエンド をpriorityを高く設定する ⚫ サーキットブレーカー アクティブ・スタンバイ構成においては、Primary側 にサーキットブレイカーを設けることで、429エラー などのレスポンスが発生した際に、スタンバイへ自動 的に切り替える運用が可能。 ※複数の AOAI バックエンドに対してラウンドロビン 方式でリクエストを分散する構成の場合は、サーキッ トブレイカーは不要。 これは、サーキットブレイ カーがあくまで「priorityの高いすべてのバックエン ドが利用不可」と判断された場合に、 priorityの低い へフェイルオーバーするための仕組みであるため。

APIM×AOAI実装の工夫点 ④トークン制限の構成 azure-openai-token-limit 使ってトークン制限を構成(従来では、 rate-limitやリクエストボディサイズを制限していた) サブスクリプションやIPアドレスごとにトークン制限が可能。 また、このポリシーの中にTPM(tokens-per-minute)の設定があるが、 どれぐらいトークン数に制限すればいいか迷う場合は、一旦はAOAIの TPM数に合わせて設定しておいて、ダッシュボードで数か月間TPMを観 察し、調整するとよい。 <azure-openai-token-limit tokens-per-minute="30000" counterkey="@(context.Subscription.Id)" estimate-prompt-tokens="true" tokens-consumed-header-name="consumed-tokens" remainingtokens-header-name="remaining-tokens" />

APIM×AOAI実装の工夫点
⑤余計なAPIをブロック
使用しないAPIは、400エラーを返すようにAll operationsスコープ
でポリシーを設定
使用するAPIは各オペレーションごとにポリシーを設定
使用しないAPIはAll operationsスコー
プで400エラーを返すように設定

使用するapiはオペレーションごとのポ
リシーで設定

<inbound>
<!-- 既定ではエラーで折り返す -->
<return-response>
<set-status code="400" reason="Bad Request" />
<set-body>{
"error": {
"code": "openrationNotSupported",
"message": "Your request openration is not
supported"
}
}</set-body>
</return-response>
</inbound>

<policies>
<!-- Throttle, authorize, validate, cache, or transform the requests -->
<inbound>
<authentication-managed-identity resource="https://cognitiveservices.azure.com" />
<include-fragment fragment-id="backend-aoai" />
<azure-openai-emit-token-metric namespace="Azureopenai">
<dimension name="API ID" />
<dimension name="Subscription ID" />
</azure-openai-emit-token-metric>
<azure-openai-token-limit tokens-per-minute="30000" counter-key="@(context.Subscription.Id)" estimate-prompttokens="true" tokens-consumed-header-name="consumed-tokens" remaining-tokens-header-name="remaining-tokens" />
...

APIM×Bing Search MCP実装の工夫点 レートリミットの構成 APIMのrate-limit-by-key ポリシーを使って、 IPアドレスごとにリクエスト数を制限し ています。 <rate-limit-by-key calls="20" renewalperiod="60" counterkey="@(context.Request.IpAddress)" />

その他の工夫点 ①監視用Managed Grafanaダッシュボードを作成 監視用に便利なManaged Grafanaダッシュボードを作成してみました！ (抜粋) • AOAIのモデルごとの1時間あたりの平均応答時間(秒) • MCPごとの1時間あたりの平均応答時間（秒） • openai APIのオペレーションごとの1時間あたりのResponse 429の回 数 • Bing MCP APIのエラーコードごとの1時間あたりの回数 • • サブスクリプションごとの1日あたりの平均プロンプトトークン/完了トーク ン/合計トークン数 サブスクリプションごとの1日あたりの最大プロンプトトークン/完了トーク ン/合計トークン数 • AIモデルごとの1時間あたりのリクエスト数

その他の工夫点 ②APIMサブスクリプションキーの払いだし APIMサブスクリプションキーを払い出す場合、SAチームごとに払い出すか/ユーザーご とに払い出すかのどちらかになる。 どちらを採用するか状況によって決めるとよい。 監視の注意点として、 SAチームごとに払い出すケースで、ユーザーごとのリクエスト数やトークン数を監視し たい場合はIPアドレスごとに集計するとよい。 トークン数について、azure-openai-emit-token-metric ポリシーでカスタムメトリック(IPア ドレスなど)ごとのトークン数をapplication insightsに送信可能。 しかし、カスタムメトリックに設定されたディメンションの数に応じて、12時間以内に 出力可能なログ数に上限がある

• https://learn.microsoft.com/ja-jp/azure/api-management/azure-openai-emit-token-metric-policy#limits-for-custom-metrics

APIの活用例

APIの活用例①コードレビュー AOAIのAPIを使ってコードレビューができる。 コードレビューに使えるツールについて、紹介します。 • PR-agant：CICDでコードレビューが可能。レビュー結果をPRコメントとして出力できる • Roo-code(Roo-cline)： Clineをフォークして、機能追加されたAI agentツール branch main branch feat/xxx PR コードプッシュ 開発支援 コード分析 Roo code API Management AOAI

APIの活用例②Web検索 Bing Search MCPのAPIを使ってWeb検索ができる。 最新情報を必要とする場合に便利。 Web検索による最新情報取得 Roo code Functions(MCP) API Management GwBS

補足

Grounding with Bing Search(GwBS)

Grounding with Bing Search(GwBS)とは GwBS は、AI Foundry エージェントがリアルタイムで公開されているウェブ データを活用し、より正確かつ最新の応答を生成するための機能です。 従来だと Bing Search API を利用して構成されていましたが、同APIは2025年8月 に完全廃止が予定されているため、今後は GwBS への移行が必須となります。 GwBS を利用するには、Azure 上で専用の GwBS リソースを作成し、AI Foundry エージェントと接続することで連携を実現します。

AIエージェントとの接続の注意点 AI Foundaryには、AIリソースをまとめる媒体がAI Hub と AI Foundry 2つあります。 GwBSは、後者のAI Foundryに紐づけましょう。※ AI Hub Project) AI Foundary(Project) Grounding with Bing Search(GwBS) ※ AI Hub と AI Foundryの違いについて、 AI Foundry Hub vs AI Foundry Project参照

• https://note.com/daka1/n/n7d4c80ec44ff

GwBSと従来のBing Search APIの実装比較 Web検索を活用した生成AIによる応答構成において、従来の Bing Search API を利用する場合 は、以下の手順をそれぞれ個別にコードで実装する必要がありました。 ① 検索クエリの生成 ② Bing による検索の実行 ③ 検索結果をもとに回答を生成 一方、GwBS（Grounding with Bing Search）では、例えば Python の場合、`azure.ai.agents` モジュールの `AgentsClient` クラスでツールとして GwBS を指定することで、これら一連の 流れを統合的に扱うことができ、従来よりもコードが簡潔かつ効率的になります。

APIMによるMCP OAuthフローの構成

APIMによるMCP の OAuth 認証フローの構成 APIM を AI 認証ゲートウェイとして活用することで、MCP の OAuth 認証フローを構成可 能。 これにより、PKCE の検証やアクセストークンの取得を、APIM を介して安全にスケラブ ルに実施できる。 1. 2. 3. 4. 5. MCP クライアントは APIM にアクセスし、認証要求を開始 APIM は Entra ID にリダイレクトし、ユーザー認証を実施 認証後、APIM のコールバック URL にリダイレクトされ、 APIM は Entra ID との間で認証コードを Entra ID のアクセス トークンに交換 その後、APIM は MCP クライアント向けに暗号化された セッションキー（MCP サーバトークン）を生成し、トー クンエンドポイント経由で MCP クライアントに返却 MCP API 呼び出し時には、クライアントから送信される MCP サーバトークンを検証し、有効であれば MCP サーバ へ安全にプロキシする処理が行われる 公式にサンプルレポジトリ(remote-mcp-apim-functions-python)が公開されている

• https://github.com/Azure-Samples/remote-mcp-apim-functions-python

自作のMCPでOAuth認証試してみました！ Entra ID OAuth AI Foundary(Project) MCP認証 MCP inspecctor Web検索 Grounding with Bing Search(GwBS) APIM GwBS MCP 現在（2025年7月時点）、MCP の認証は MCP inspector 経由でのみ可能。 VS Code では初回認証後、約1時間間は MCP への接続が維持されるが、アクセストーク ンの有効期限切れ後に「404 client not found」エラーが発生し、再認証ができない不具 合が発生している。 この問題は公式 GitHub の issue にも報告されており、現時点では解決時期は未定。

• https://github.com/Azure-Samples/remote-mcp-apim-functions-python/issues/8

APIM×MCPの認証方法の使い分け APIMへのアクセスに対する送信元制限の可否で分かれる。 送信元制限不可の場合、 OAuth認証を実装 制限可もしくは内部アクセスのみの場合、 サブスクリプションキーによる認証 pl-subnet 開発端末VNET(spoke) apim-subnet Web検索 Roo code コード支援 Dev box AOAI functions-subnet APIM vnet統 合 GwBS AI Foundary

近日中にgithubで公開予定です！ テスト用の AOAI×MCPのAPI 構成について、 近日中に公開予定です！ Entra ID OAuth AI Foundary(Project) MCP inspecctor MCP認証 Managed Grafana GwBS Roo code APIM GwBS MCP AOAI