Codex・Claude Code を API Management を中核にして利用する

生成AIの業務活用が進む中で、Codex や Claude Code といったコーディングエージェントを社内で利用したいという要望も増えています。

情報システム部門の立場としては、Enterprise や Business プランのような契約ではライセンスを割り当てたものの利用が進まず、結果としてコストが無駄になってしまうことが懸念されると同時に、新規ベンダーとの契約となると、契約書の締結や支払い口座の開設など、導入前後の運用負荷も無視できません。

だからといって、各部門や個人にサブスクリプション契約を任せてしまうと、利用実態が見えなくなり、結果としてガバナンスが効かなくなるという問題も生じます。

本記事では、Microsoft Foundry にCodex 系モデルや Claude 系モデルをデプロイし、その手前に Azure API Management （以下、API Management）を配置することで、企業向け API Management を中核とした生成AI利用基盤を構築した事例をもとに、全体アーキテクチャと設計の狙いを紹介します。

まず本記事で全体構成と設計の考え方を整理したうえで、次回以降の記事では、Microsoft Foundry におけるモデルによるデータの扱いの違いや、Codex・Claude Code を API Management 経由で利用するための構成、さらに可用性設計や利用制御、可視化といったテーマを順に取り上げる予定です。

本記事で紹介する構成の全体像
- 構成図：API Managementなし／あり
  - API Managementなし
  - API Managementあり
- 前提条件：モデル提供方式と利用可能リージョン
API Management を中核にした利用基盤のメリット
まとめ

本記事で紹介する構成の全体像

構成図：API Managementなし／あり

以下に、構成図と Azure のリソースを示します。

API Managementなし

API Management を経由せず、直接 Microsoft Foundry へリクエストする構成も可能ですが、企業内利用のように複数名が利用する場合にはセキュリティ上、ガバナンス上の問題が生じます。また、可用性という観点でも不安が残ります。

Without API Management — API Managementなし

リソース種別	リージョン
Foundry	East US 2 or Sweden Central
Foundry プロジェクト	East US 2 or Sweden Central

API Managementあり

本記事で紹介する構成です。セキュリティ、ガバナンス、可用性の観点で企業内利用に適した基盤を実現しています。

リソース種別	リージョン
Microsoft Foundry	East US 2
Microsoft Foundry プロジェクト	East US 2
Microsoft Foundry	Sweden Central
Microsoft Foundry プロジェクト	Sweden Central
API Management	Japan East
Application Insights	Japan East
Log Analytics ワークスペース	Japan East

※ Foundry および Foundry プロジェクトは、モデルの提供条件により利用できるリージョンが限定されます。

前提条件：モデル提供方式と利用可能リージョン

本構成は、Microsoft Foundry が提供するモデルに関する制限を踏まえて設計しています。

Microsoft Foundry が提供するモデルのデプロイ方式は、Codex 系モデル、Claude 系モデルともに、現時点ではグローバル標準のみ利用可能です。また、Claude 系モデルについては、利用可能なリージョンが East US 2 および Sweden Central に限定されています。

これらはモデル提供側の前提条件として受け入れた上で、構成を検討する必要があります。

API Management を中核にした利用基盤のメリット

本章では、Codex や Claude Code といったコーディングエージェントからのアクセスを API Management に集約することのメリットを整理します。

ユーザーごとにサブスクリプションキーを払い出すことによるセキュリティの向上

直接 Microsoft Foundry へリクエストしている場合、Codex 系モデルであれ、Claude 系モデルであれ共通のAPIキーを利用することになります。この場合、APIキーを設定する端末や設定ファイルが増えることで、APIキーが漏洩するリスクが高まるとともに、万が一 APIキーが漏洩した場合には、その APIキーを利用しているすべてのユーザー・クライアントに対して設定変更を行う必要があり、影響範囲が大きくなります。

一方、本構成では API Management を用いて、ユーザーごとにサブスクリプションキーを発行し、さらに Codex 系モデル用と Claude 系モデル用でサブスクリプションキーを分けて管理しています。これにより、キー漏洩時にも該当するサブスクリプションキーのみを再生成すればよく、影響範囲を最小限にとどめることができます。

一元管理によるガバナンスの確保

本構成では、Codex や Claude Code といったコーディングエージェントからのリクエストを、直接 Microsoft Foundry に送信するのではなく、API Management を中核として集約しています。

利用者は、用途に応じた API のエンドポイントおよびサブスクリプションキーを設定し、API Management 経由で各モデルを利用します。 API Management は、それらのリクエストを受け取り、バックエンドとして構成した Microsoft Foundry 上の Codex 系モデルやClaude 系モデルへルーティングします。

このように API Management を介在させることで、申請に基づいて利用者を管理し、利用状況を把握しながら、想定外の利用増加によるコストの急増を抑制できます。

また、将来的に OpenAI や Anthropic 以外のモデルを利用したくなった場合でも、バックエンドに新たな API を追加することで、同じ管理体系のまま拡張できる構成としています。

サーキットブレーカーとフェイルオーバーによる可用性の向上

本構成では、Microsoft Foundry を利用するリージョンとして、East US 2 をプライマリー、Sweden Central をセカンダリーとして構成しています。

API Management では、バックエンドとなる Microsoft Foundry の応答状況を監視し、応答が得られない場合にはサーキットブレーカーを発動します。これにより、応答のないバックエンドにリクエストを送り続けてAPI Management のリソースが枯渇することを防ぎます。

また、プライマリーリージョンである East US 2 が利用できなくなった場合には、自動的に Sweden Central 側へフェイルオーバーすることで、利用者はコーディングエージェントを継続して利用できる構成としています。

API Management なし／ありの比較まとめ

API Management を経由しない構成と、API Management を中核とした構成を比較したまとめです。

観点	API Management なし	API Management あり（本構成）
リクエスト経路	各クライアントから直接 Microsoft Foundry にリクエスト	API Management を経由してルーティング
認証・キー管理	Microsoft Foundry の APIキーを、全ユーザー・クライアントで共有	ユーザーごとにサブスクリプションキーを発行・管理
モデルごとの管理	単一の APIキーで複数モデルを利用	Codex 系モデル用／Claude 系モデル用でキーを分離
キー漏洩時の対応	全ユーザー・クライアントで APIキー変更が必要	該当サブスクリプションキーのみ再生成
ガバナンス	申請・承認の仕組みがなく、利用者や利用状況の把握が困難	申請に基づいてユーザー・利用状況を一元管理
可用性	リクエスト先の設定値変更などクライアントに依存	サーキットブレーカー＋フェイルオーバーによる高可用
利用シーン	小規模・個人利用向き	複数名での企業内利用を想定