AI Gateway「Bifrost」の本番導入で、Technical Project Manager が担ったこと
本文の状態
日本語全文を表示中
詳細モードで約20分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
LayerX Tech Blog
LayerX の TPM が AI Gateway「Bifrost」の本番導入プロジェクトを通じて、課題の構造化や技術選定、役割分担、リリース推進における具体的な実践方法を解説している。
AI深層分析を開く2026年8月28日 18:51
AI深層分析
キーポイント
AI Gateway の定義と機能
AI Gateway はアプリケーションと複数の LLM プロバイダーの間に入り、接続制御を一元化する仕組みであり、モデルルーティングや障害時のフェイルオーバーなどの共通機能を担う。
TPM の役割と実践内容
LayerX の TPM は本番導入プロジェクトにおいて、課題の構造化、技術選定、各ロールとの役割分担、リリースまでの推進を具体的に実行した。
マルチモデル環境への対応
生成 AI 業務の拡大に伴い、複数のモデルやプロバイダーを使い分ける環境では、可用性、コスト、セキュリティを一元的に管理する必要性が高まっている。
TPMの役割と責任範囲
Ai Workforce事業部のTPMは技術理解を生かし、プロジェクト全体の技術的側面を支えながら前進させる。AEやSREなど多様な職種と連携し、インフラやセキュリティを含む横断的な活動を通じてプロジェクトを推進する。
解決すべき課題の構造化
LLM API利用の複雑化に伴い、モデル制御や障害対応などの要件を3つの具体的な課題に整理し、関係者の議論を明確にした。これにより技術的な不確実性を検証し、開発計画への落とし込みを容易にした。
重要な引用
AI Gateway は、アプリケーションと複数の LLM プロバイダーの間に入り、接続や制御を一元化する仕組みです。
この発表の重要性は、各社で少しずつ異なる AI Gateway の課題解決方針と、Kubernetes や CNCF の OSS コミュニティでの標準化議論にある。
技術的な不確実性を検証し、「具体的な開発計画」へ落とし込む
事業側、開発チーム、SRE、セキュリティの間で情報の中心となり、各担当者が自分の役割に集中できる状態を作る
編集コメントを表示
編集コメント
本記事は、AI Gateway の導入において TPM が果たす具体的な役割と実践的なアプローチを詳細に示しており、現場のプロジェクト推進担当者にとって有益な事例となっている。技術選定やリスク管理の観点から、実務への応用可能性が高い内容である。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
はじめに
LayerX の Ai Workforce 事業部で、TPM（Technical Project Manager）をしている urapico です。
本記事では、OSS の AI Gateway である Bifrost を本番環境へ導入したプロジェクトを例に、課題の構造化や技術選定、各ロールとの役割分担、リリースまでの推進など TPM が実際にどのように前に進めていくのかを紹介します。
AI Gateway で何を解決したかったのか、なぜ Bifrost を選んだのかという技術面の検討内容もあわせてお伝えします。AI サービスへの AI Gateway 導入を検討している方にも、参考になれば幸いです。
その前に、AI Gateway と TPM について補足させていただきます。
AI Gateway とは
AI Gateway は、アプリケーションと複数の LLM プロバイダーの間に入り、接続や制御を一元化する仕組みです。
現在、生成 AI が担える業務が広がり、サービスでは用途に応じて複数のモデルや LLM プロバイダーを使い分けるようになっています。こうしたマルチモデル環境では、プロバイダーごとに異なる API や認証情報に加え、可用性、コスト、セキュリティ、利用状況を一元的に管理する必要があります。
そのため AI Gateway には、単一の LLM プロバイダーへの接続を中継するだけでなく、リクエスト内容やコスト、レイテンシーに応じたモデルルーティング、障害時のフェイルオーバー、予算管理、アクセス制御、機密情報のマスキング、監査ログやトレーシングなどを共通機能として提供する役割が求められています。
この考え方は、Cloudflare や AWS、Microsoft、Kong などの主要ベンダーに広がっています。AI Gateway でどの課題を解決しようとしているかは、各社で少しずつ異なります。また、Kubernetes や CNCF の OSS コミュニティでも標準化に向けて議論が進められています。
参照
TPM（Technical Project Manager）とは
TPM の役割や責任範囲は、組織によって異なります。Ai Workforce 事業部では、プロジェクト全体の技術的な側面を支え、技術理解を生かしてプロジェクトを前に進める役割を担っています。
*以前のTPMの記事もご覧ください。
執筆時点で、Ai Workforce 事業部には3名の TPM が所属しています。バックグラウンドはそれぞれ異なりますが、複数の技術領域で経験を積んできた点は共通しています。
AE（Account Executive）、DS（Deployment Strategist）、FDE（Forward Deployed Engineer）、SWE（Software Engineer）、SRE（Site Reliability Engineer）、PdM（Product Manager）などと連携しながら、インフラやセキュリティを含む技術領域を横断し、プロジェクトの前進に必要な活動を担うのが特徴です。
具体的には、次のような活動をします。
- 技術的な不確実性を検証し、「具体的な開発計画」へ落とし込む
- 選択肢を比較して技術的な意思決定をする
- 事業側、開発チーム、SRE、セキュリティの間で情報の中心となり、各担当者が自分の役割に集中できる状態を作る
- 品質やセキュリティの要件を満たしたデリバリーを推進する
今回の AI Gateway 導入は、こういった役割を TPM として担いながら進めることができたプロジェクトでした。以降、プロジェクトの流れに沿って紹介します。
出発点：解決したい課題を構造化する
LayerX が開発・提供する Ai Workforce は、Azure 上で稼働しています。
AI を利用したサービスを開発・運用していると、LLM API の呼び出しは徐々に複雑になっていきます。
最初はアプリケーションから Azure OpenAI を直接呼び出すだけで十分でも、サービスが成長するにつれて、モデルやリージョンの制御、障害時の切り替え、利用状況の把握といった要件が出てくるのではないでしょうか。
プロジェクトの出発点として、私はこうした要件を、関係者が迷わないように議論できる3つの課題に整理しました。
テナント単位のデータレジデンシー制御
私たちのサービスでは、テナント（サービス内の論理的な利用単位）ごとにデータレジデンシー要件（データを保存・処理する地理的な場所に関する要件）が異なります。
たとえば、あるテナントはグローバル推論（リージョンを限定せず処理を振り分けるデプロイ方式）の Azure OpenAI を利用できても、別のテナントは特定のリージョン内で処理を完結させなければならない、といったケースです。それは、どういったケースでしょうか？ 以下にいくつか考えられる一般的なケースをあげてみます。
- お客様との契約で処理地域が指定されている業務処理
- 製造業の未公開設計情報の処理（企業の輸出管理ポリシーなどに依存）
- M&A・法務文書を扱う処理（守秘義務や契約条件に依存）
これらの処理が常にリージョン指定の推論を必要とするとは限りません。各企業の契約やポリシーに応じて、処理地域を適切に制御する必要があります。
そして、このテナントごとの推論処理の呼び分けをアプリケーション側で実現しようとすると、テナントの設定取得、許可されたモデルエンドポイントの判定、API キーやクライアントの選択を、アプリケーション内のすべての LLM 呼び出し箇所で行うことになります。LLM の呼び出し箇所が増えるほど、制御の抜け漏れが起こりやすくなります。
LLM プロバイダー障害への対応
LLM プロバイダー側で障害やレート制限が発生すると、その影響はアプリケーションに 429 Too Many Requests や 5xx エラー、タイムアウトとして現れます。このとき、同じモデルへ一定時間後に再試行するのか、別のリージョンや別のモデルへ切り替えるのか、それとも処理全体を中止するのかの判断が求められます。
こうしたリトライやフェイルオーバーを各アプリケーションに実装すると、再試行回数や待機時間、切り替え先の選定ルールがサービスごとに分散します。そしてそれらの複数サービスが同時にリトライすることで、レート制限中のプロバイダーへさらに負荷をかける可能性もあります。また、モデルを切り替える場合は、API の互換性だけでなく、コンテキスト長、ツール呼び出し、コンテンツフィルター、生成品質などの差異も考慮しなければなりません。
さらに、フェイルオーバー先がデータレジデンシー要件を満たしているかを、呼び出し元ごとに管理する必要もあります。
LLM 利用状況の可視化
LLM の利用量、モデルごとのレイテンシー、エラー率、プロバイダーごとの偏りを把握するには、呼び出し元のアプリケーションだけでなく、LLM 通信全体を横断した観測が求められます。
アプリケーションごとにログやメトリクスを実装すると、フォーマットや粒度が揃わず、運用時の調査も難しくなります。
こうして課題を文書にすると、「今回どこまでを解決するのか」というスコープの議論が関係者とできるようになります。
技術選定：ADR と4つの選択肢
意思決定を ADR として残す
課題を整理したら、次は解決手段の選定です。解決手段には常に複数の選択肢があるため、比較検討の結果を ADR（Architecture Decision Record）として文書化し、チームの合意を取りました。
採用した理由だけでなく、選ばなかった選択肢とその理由も残すことで、後からプロジェクトに加わるメンバーも意思決定の背景を追えます。
また、AI Gateway はすべての LLM 通信を中継するため、ゲートウェイ自体の障害がサービス全体に影響する重要コンポーネントになります。ADR の時点でこのリスクを明記し、死活監視とアラートの整備を導入の前提条件に含めました。
技術的な意思決定を口頭ではなく文書で積み上げ、合意を作っていくのは TPM の中心的な仕事のひとつと考えています。
この時、私が検討・比較した以下の4つの選択肢についてお話しします。
- アプリケーションレイヤーで制御する
- Azure API Management の AI Gateway を利用する
- LiteLLM を自前運用する
- Bifrost を自前運用する
1. アプリケーションレイヤーでの制御
追加インフラが不要というメリットはありますが、テナント単位の制御、フェイルオーバー、レート制限、監査をアプリケーション側で実装する必要があります。
LLM の利用箇所が増えるほど、実装の重複と運用コストが増えるため、採用しませんでした。
2. Azure API Management
Ai Workforce は Azure 上で稼働しているため、Azure のマネージドサービスである API Management は、運用負荷を抑えやすく親和性も高い選択肢です。
一方、将来的なマルチクラウド対応や、ゲートウェイの挙動を細かく制御する必要性を考えると、Azure への依存が大きくなります。可能な限りベンダーロックインを抑えたいという方針に加え、利用料が追加で発生し想定コストが増える点も懸念でした。
なお、自前運用にもコンテナとデータベースの費用は発生します。想定リクエスト量をもとに両方を試算したうえで、今回の規模では自前運用のほうがコストを抑えられる見込みだと判断しました。
3. LiteLLM
対応プロバイダーが多く、機能も豊富です。
ただし、今回検討した本番構成では Redis や PostgreSQL などの外部コンポーネントも必要となり、ゲートウェイに加えて周辺ミドルウェアの運用も求められました。
また、AI Gateway は各プロバイダーの認証情報を扱うため、ソフトウェアサプライチェーンのリスクも重視しました。検討時点で LiteLLM では、パッケージ公開経路の侵害によって悪意あるバージョンが公開されるインシデントが報告されていました。その経緯と対応は下記の Issue で公開されており、特定プロダクトの問題というより、認証情報を集約する AI Gateway 全般に共通するリスクとして評価軸に加えました。
4. Bifrost
Bifrost は Go 製の OSS で、AI Gateway に必要な機能を比較的シンプルな構成で導入できます。
最大の決め手は、コアのゲートウェイ機能だけであれば外部ミドルウェアなしで動作することです。本番構成では監査ログと設定値、Virtual Key の永続化のため PostgreSQL を利用していますが、キャッシュ用の Redis が不要で、依存コンポーネントを1つに抑えられる点が他の選択肢との違いでした。
また、Go 製の単一バイナリであることも、デプロイや依存コンポーネントの管理をシンプルに保つうえで評価した点です。
そのほかの決め手は次の通りです。
- OSS であり、クラウドへのロックインを抑えられる
- OpenAI 互換 API として既存アプリケーションから利用できる
- Virtual Key によるルーティング制御ができる
- OpenTelemetry によるメトリクス・トレース連携が可能
- MCP（Model Context Protocol）Gateway など、今後必要になりうる機能を持っている
- 公式ベンチマークでは、モック化した OpenAI への呼び出しを毎秒 5,000 リクエスト処理した結果が公開されており、性能面の参考にできる
一方、検討時点では LiteLLM や大手クラウドのマネージドサービスに比べると新しいプロダクトであり、事例やドキュメントはこれから充実していく段階です。その点は理解したうえで採用しました。
設計のポイント
採用を決めてからは、本番で運用できる形にするための設計を SRE や SWE と一緒に詰めていきました。
概略構成は次の通りです。Bifrost は Azure Container Apps 上に配置し、設定値や Virtual Key の保存先として専用の PostgreSQL を利用しています。
設計のうち、代表的なものを4つ紹介します。
データレジデンシーを Virtual Key で制御する
アプリケーションは、テナントに設定されたデータレジデンシー要件に応じてグローバル用またはリージョン限定用の Virtual Key を選択します。
以下は、リージョン限定の例として US を使用し、Virtual Key の選択方法を簡略化したコード例です。
def get_bifrost_virtual_key(
llm_data_residency: LLMDataResidency,
) -> str:
if llm_data_residency == LLMDataResidency.US:
return settings.BIFROST_VIRTUAL_KEY_US
return settings.BIFROST_VIRTUAL_KEY_GLOBAL
以下は、関連する設定を抜粋・簡略化した Bifrost の config.json の例です。この例では、US 用のキーがグローバル用のプロバイダーへ紐付かない対応関係にしています。
// ...省略...
"virtual_keys": [
{
"id": "global",
"name": "global",
"value": "env.BIFROST_VIRTUAL_KEY_GLOBAL",
"provider_configs": [
{ "provider": "azure", "allowed_keys": ["global-openai"]}
]
},
{
"id": "us",
"name": "us",
"value": "env.BIFROST_VIRTUAL_KEY_US",
"provider_configs": [
{ "provider": "azure", "allowed_keys": ["us-openai"]}
]
}
// ...省略...
"providers": {
"azure": {
"keys": [
{
"name": "global-openai",
"value": "",
"weight": 1,
"models": [
"gpt-5.x"
]
},
{
"name": "us-openai",
"value": "",
"weight": 1,
"models": [
"gpt-5.x-pro"
]
}
// ...省略...
Provider 周りの config.json による制御について、公式ドキュメントでも確認できます。
Bifrost 側では、Virtual Key ごとに利用できるプロバイダーキーを制限します。プロバイダーキーとは、接続できる LLM プロバイダーやモデルを制御するための設定です。US 用のキーがグローバル用のプロバイダーへフェイルオーバーしない対応関係にしているため、今後フェイルオーバー先を複数の LLM プロバイダーへ広げる場合も、データレジデンシー要件を守ったまま可用性を高められます。
アプリケーション側は「US のテナントなので US の Virtual Key を使う」という責務だけを持ち、具体的なモデルエンドポイントや認証情報はゲートウェイ側で管理します。
アプリケーションの変更を最小限にする
Bifrost は OpenAI 互換 API として利用できるため、既存の LLM クライアントの構造を保ちながら導入できました。利用しているライブラリや、受け取ったデータを処理する部分への変更も最小限に抑えられました。
この移行は SWE と協力して進め、既存の直接呼び出しを整理しながら、Bifrost 経由の構成へ段階的に切り替えています。あわせて、今後追加されるコードが意図せずゲートウェイを迂回しにくいよう、開発プロセスにもチェックの仕組みを整えました。
秘密情報をゲートウェイ側に集約する
LLM プロバイダーの認証情報や Virtual Key などの秘密情報は Azure Key Vault に集約しました。また、Azure を基盤として利用しているため、Azure OpenAI には Managed Identity で接続しています。
これにより、アプリケーションコンテナへ認証情報を広く配布せずに済みます。
今後、認証情報が必要な LLM プロバイダーが増えた場合も、ゲートウェイ側へ集約することで、秘密情報を扱う範囲を限定できます。
LLM 通信をまとめて観測する
すべての LLM 通信がゲートウェイを通るため、ゲートウェイに計装を集約すれば、アプリケーションごとに実装しなくても LLM 利用の全体像を観測できます。
Bifrost は OpenTelemetry の GenAI セマンティック規約（gen_ai.* 属性）に沿ったトレースとメトリクスを送信でき、これを OpenTelemetry Collector 経由で Datadog へ転送しています。モデル名、トークン使用量、レイテンシーといった LLM 固有の情報が標準スキーマで揃うため、どのアプリケーション経由のリクエストでも同じ軸で分析できます。
観測で気をつけたのは「何を送らないか」です。プロンプトや応答の本文には、個人情報やセンシティブな内容が含まれているため、Collector でマスクして監視 SaaS へ送らず、メトリクスも値の種類が少ない属性だけに絞っています。
このテレメトリーを土台に、専用ダッシュボードと SLO（Service Level Objective、サービスレベル目標）を整備しました。さらに、SLO に対して許容される失敗の余地（エラーバジェット）の消費速度を検知する、バーンレートアラートの整備も進めています。
TPM としてどう進めたか
ここまでは「何を作ったか」の話でした。この節では、TPM としてプロジェクトをどう前に進めたかを紹介します。
専門性で分担し、間を埋める
このプロジェクトでは、SRE が開発環境の基盤構築を、SWE が Bifrost 関連の実装・検証を担当しました。私が担ったのは、技術検証、ADR の作成、環境ごとの展開、リリース管理、そして関係者間の調整です。
TPM がすべてを抱えるのではなく、専門性を持つメンバーと早めに協働し、私は領域をまたぐ仕事（意思決定、調整、環境差分の確認）を担いました。この分担によって、各担当者が自分の役割に集中できる状態を作りました。
今回はプロジェクトの状況に応じて、TPM 側で一部の実装やリリース作業も担当しました。役割を固定しすぎず、デリバリーに必要な実務を担うこともあります。
本番と同じ条件で先にリハーサルする
展開は、開発環境、ステージング環境、本番相当環境、本番環境と段階を踏みました。
特に効果があったのは、本番と同等のネットワーク制限を持つ環境での事前リハーサルです。閉域に近い構成では、開発環境では見えなかった課題が、本番相当の環境へ展開してはじめて現れることがあります。これらを本番適用の前に検出して解消できたため、本番への展開は落ち着いて進められました。
運用コストを見積もり、早めに共有する
ゲートウェイとデータベースの新設は、月々の運用コストの増加を意味します。
技術的な妥当性だけでなく、コスト影響を見積もってビジネスサイドと共有し、判断材料を揃えるのも TPM の仕事です。
現在は、ADR の作成時にコスト影響もあわせて整理し、早い段階で相談できる体制を整えています。
リリース前にカスタマーサクセスへ共有する
リリース後にサービスをご利用の方と接するのは、開発チームだけではありません。カスタマーサクセスのメンバーが問い合わせに対応できるよう、リリース前に機能の説明を動画とドキュメントで共有しました。また、これらの資料は DS や FDE などお客様とコミュニケーションを取るメンバーにも共有し、機能を理解するための資料として活用してもらっています。
会議だけに頼らず非同期で理解できる形にしたことで、各職種への説明内容のばらつきを抑えながら、関係者それぞれのタイミングでキャッチアップしてもらえました。
導入で得られた効果
AI Gateway の導入によって、次の状態を実現できました。
- 複数のモデル・リージョンを利用しても、テナントごとのデータレジデンシー要件を満たせる
- LLM の接続先、認証情報、制御ロジックがゲートウェイに集約され、アプリケーションは保守しやすい実装を保てる
- 対応済みのプロバイダーやモデルであれば、主にゲートウェイ側の設定変更で追加できる
- サービス全体の LLM 利用状況を、同じメトリクス・同じダッシュボードで観測できる
- フェイルオーバー先を複数の LLM プロバイダーへ広げ、サービスの可用性を高めるための基盤が整った
今後の展望
一方で、事業固有の要件のすべてに対応できているわけではありません。この基盤の上で広げていきたいことは、まだ多くあります。
- 複数の LLM プロバイダーへのフェイルオーバーによる可用性向上
- レート制限によるモデルエンドポイント単位の流量制御
- モデル追加時の設定検証の自動化
- LLM リクエスト内容の監査の高度化
AI Gateway は LLM 通信の中心に位置するため、こうした機能を追加するときも、アプリケーション側のコード変更を抑えられます。保守しやすい実装を保ちながら LLM 利用の要件に応えていける状態を、この基盤で作れたと考えています。
まとめ
AI Gateway の導入は、データレジデンシー制御、秘密情報管理、観測、SLO といった要素を一体として設計し、関係者と合意しながら本番まで届ける必要がありました。
振り返ると、このプロジェクトで私自身が書いたコードはごく一部です。課題の構造化、選択肢の比較と意思決定の文書化、専門性に応じた分担の設計、コストの見積もりとマネージャー陣との合意形成、リリース前の社内共有など、「技術を理解したうえでプロジェクトを前に進める」活動の積み重ねが TPM の仕事だと考えています。
TPM は、組織によって役割や期待される範囲に幅がある職種です。だからこそ、組織に合った役割を自分たちで形作っていける面白さがあります。Ai Workforce 事業部には、AI Gateway のような技術的に深いテーマがたくさんあります。こういった事業の文脈でプロジェクトを前に進めてお客様に価値を届けることに面白さを感じる方には、きっと合う仕事だと思います。
EVENT
AIカンファレンス「Bet AI Day 2026」開催概要
開催日時
2026年9月3日（木）12:00 開演
開催方法
オンライン配信
参加費用
無料（事前申込制）
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み