ガバナンスはAIに何を許可するかを決定する。ゲートウェイはそれを強制するだけだ。

あらゆる技術の移行は同じパターンをたどる。新たなプラットフォームが登場し、アーリーアダプターが実験に殺到し、ベンダーが機能の提供を競い、やがてどのカンファレンスの講演もベンチマークチャートになる。

エンタープライズAIも例外ではなく、現在、エンタープライズインフラで最も急成長しているカテゴリのひとつがAIゲートウェイだ。組織は、複数の基盤モデルへの接続、認証情報の管理、利用状況の監視、予算の強制を一元的に行いたいと考えている。AIが孤立したパイロットから本番環境へ移行するにつれ、ゲートウェイは利便性から要件へと変わる。

しかし、アーキテクト、プラットフォームエンジニア、技術リーダーとの1年にわたる対話の後、筆者が繰り返し気づくのは、同じことだ。最初に直面する本当の障害は、ほとんど常に技術的なものではない。

会議は通常、次のように進む。セキュリティ担当者は顧客データを外部モデルに送信できるかどうかを尋ねる。財務担当者は、AI支出を事業部門間でどのように配分するか、数十のアプリケーションが毎分トークンを消費し始めた場合、予算の責任者は誰かを知りたがる。法務担当者はAIの意思決定をどのように監査するかを尋ねる。コンプライアンス担当者はどの規制が適用されるかを尋ねる。

そして、誰も準備していなかった質問が出る。

「実際にこれを許可したのは誰だ？」

部屋が静かになる。答えが難しいからではなく、答えが必要だと誰も気づいていなかったからだ。

これらはどれもゲートウェイの問題ではない。ガバナンスの問題だ。

AIガバナンスとは何か、そしてなぜ先に必要なのか

AIガバナンスとは、企業がAIをどのように利用することを許可するかを決定する一連の組織的決定である。誰がどのモデルを使用することを承認されるか、どのデータが組織外に持ち出される可能性があるか、支出をどのように配分・上限設定するか、何をログに記録・保持しなければならないか、例外を承認できるのは誰か。これらはリーダーシップの機能であり、ソフトウェア機能ではない。

Bifrostのようなプラットフォームがこの点をよく示している。AIゲートウェイは、これらの決定を強制するレイヤーである。

だからこそ順序が重要だ。ガバナンスのないゲートウェイは矛盾を解消しない。矛盾を産業化する。

AIゲートウェイは玄関ドア。ガバナンスは誰が鍵を持つかを決める。

玄関ドアを設置するのは簡単だ。誰が鍵を受け取り、どの部屋を開けられるか、鍵の有効期間はどれくらいか、誰かが通り抜けたときに何を記録するかを決めるのは、はるかに難しい。これらは組織的決定であり、ドアはそれを強制する。

ガバナンスがなければ、各アプリケーションチームがプロバイダー、認証情報、予算、ロギング、データ処理について独自に判断する。ほぼ同じ作業を行う2つのチームが、全く異なるポリシーを持つことになる。2人の異なる開発者が、2つの異なる火曜日に、2つの異なる判断を下したからだ。一貫性は失われ、リスクは複合し、運用上の複雑さは人員に比例して増大する。

ゲートウェイが存在するだけでは、この問題は解決しない。組織が一貫して解決できる単一の場所を提供する。

ビジネスポリシーを技術ポリシーに変換するには

ここで、Bifrost AIゲートウェイが単なる配管以上のものになる。成熟したゲートウェイは、アプリケーションとプロバイダーの間でリクエストをルーティングするだけではない。ビジネス上の決定をランタイムの動作に翻訳する。

具体的に考えてみよう。財務部門が、Marketingに対して最先端モデルの実験に月額2,000ドルを割り当て、80%でアラート、100%でハードストップをかけ、Engineeringに対しては顧客向け本番ワークロードがAIに依存するため40,000ドルを割り当てると決定したとする。これは予算策定の演習ではなく、相対的なリスクとビジネス価値に関するガバナンス決定だ。どのシステムも強制できない予算は、単なる予測に過ぎない。

モデルアクセスの場合も同様だ。Customer Support、Legal、Engineeringはそれぞれ異なる規制上のリスクと、特定のモデルにアクセスする異なる理由を持っており、これらの区別は技術的な仕組みがなければアドバイザリーのままになる。

各リンクはBifrostがその制御を実装する方法を示しているが、マッピングはどのゲートウェイを選択しても成立する。

この表で起こっていないことに注目してほしい。ゲートウェイはガバナンスを決定していない。ガバナンスを運用化している。そして、この区別がこの議論の核心だ。Bifrostがこれらの機能を実装する方法を探りたい場合は、ドキュメントとオープンソースコンポーネントがGitHubのBifostリポジトリで入手可能だ。

AIゲートウェイを導入する前に下すべき6つの決定

これらは、インフラが強制する対象が存在する前に必要となる決定だ。

  1. 所有者を指名する。 単一の責任者または常設委員会。セキュリティ、法務、エンジニアリングの間で所有権を共有すると、確実に所有者が不在になる。
  2. データを分類する。 どのカテゴリが外部モデルに到達可能で、どのカテゴリが決して到達できず、どのカテゴリがセルフホスト展開を必要とするか。ほとんどの組織はすでにこの分類を持っており、AIにマッピングしていないだけだ。
  3. 機能別に承認されたモデル階層を定義する（好みによるものではない）。 顧客向け本番、内部生産性、実験的研究は3つの異なるリスクプロファイルであり、1つの許可リストを共有すべきではない。
  4. 最初の本番ワークロードの前に予算所有権と上限を設定する。 採用後にコストコントロールを後付けするのは、政治的問題であり、技術的問題ではない。そして、はるかに悪化する。
  5. 何をログに記録し、どのくらいの期間保持するかを決定する。 NISTのAIリスクマネジメントフレームワーク、ISO/IEC 42001、EU AI Act、既存のSOC 2コントロールはいずれも証拠を求めている。証拠が必要になる前に、証拠がどのようなものかを決めておく。
  6. 例外パスを文書化する。 文書化された例外パスがないポリシーは、例外を防がない。記録なしで例外が発生することを保証する。

それは1週間の会議で済むことであり、四半期にわたるものではない。

これらの決定が構成としてどのように見えるか

決定3と4は最も見えやすい。なぜなら、同じオブジェクトが両方を運ぶからだ。Bifrostでは、そのオブジェクトは仮想鍵であり、プロバイダーとモデルの許可リスト、所有チーム、独自の予算を保持する。先ほどのMarketingの決定（財務部門が会議で下したもの）は、次のようになる。

{
  "name": "Marketing Experimentation",
  "team_id": "team-marketing",
  "provider_configs": [
    { "provider": "openai", "allowed_models": ["gpt-4o-mini"] }
  ],
  "budget": {
    "max_limit": 2000.00, "reset_duration": "1M"
  },
  "expires_at": "2026-12-31T00:00:00Z",
  "is_active": true
}

全画面モードに入る 全画面モードを終了

以前はスライドにあったポリシー。許可リストは決定3、予算は決定4、expires_atは決定6だ。例外を時間制限することは、デフォルトで永続化することを防ぐ方法だからだ。ポリシーのレビューは、20のチームにインタビューするのではなく、ファイルを読み込むことになり、「先四半期にどのモデルが誰に承認されたか」という質問の答えが差分になると、監査は考古学プロジェクトではなくなる。

これがより深いポイントだ。リクエストの瞬間に作成された記録は証拠だ。請求書と記憶から後で再構築された記録は証言だ。筆者はこれをwrite-side custodyとして他で書いたことがある。出所は、書き込みが行われた場所で捕捉されなければならず、後で組み立てられるべきではないという原則だ。ゲートウェイは組織が行うすべてのAIリクエストの書き込み側であり、したがって、custodyが利用可能になる最も安価な場所となる。

しかし、ガバナンスファーストは単に待つことを意味するだけではないか

これは公正な異論であり、失敗モードは現実のものだ。多くの組織が18ヶ月間AIガバナンスについて議論し、何も出荷していない一方で、エンジニアは個人的にAPIキーを経費計上して仕事を進めている。ガバナンスが決定に費やす月は、組織がガバナンスなしで決定する月でもある。

したがって、この議論の正直なバージョンは、「ガバナンスを完了してからインフラを購入する」ではない。6つの決定は安価であり、本番トラフィックは3つ（データ分類、予算所有権、ロギング）に先行してはならない。ゲートウェイは並行して導入する。ただし、最初の顧客向けワークロードが、機密とみなされるものを決めたことがないことを発見させるようなことはしない。

ガバナンスが変わったらどうなるか

6ヶ月後、同じ会社が競合他社を買収する。Marketingは一夜にして2倍になる。財務部門は買収したチームを別予算にしたいと言う。法務部門は欧州の顧客データがEUから出ることを絶対に認めないと言う。Engineeringには本番環境に20のアプリケーションがあり、それらを書き換える意欲はない。

そのとき、組織はゲートウェイが実際に何のためのものかを発見する。リクエストのルーティングではない。アプリケーションの変更を強制することなくポリシーの変更を吸収することだ。

機能リストを超えてAIゲートウェイを評価する方法

プロバイダーの数を数えたり、レイテンシを測定したり、価格を並べたりしてゲートウェイを比較するのは簡単だ。これらは重要だ。しかし、すべてのゲートウェイデモは、1秒あたり10リクエストでは同一に見える。予算上限、監査要求、再編時に乖離する。正式な評価を行う場合は、LLMゲートウェイ購入者ガイドを参考にするのが合理的だ。

インフラより先にガバナンスを

技術は戦略の代わりになったことはない。組織は市場で最も有能なゲートウェイを購入しても、AIをどのようにガバナンスするかを決めていなければ苦戦する。逆もまた真実であり、より興味深い。ガバナンスを最初に決着させる組織は、新しいモデルをより速く（より遅くではなく）採用する傾向がある。難しい質問は、統合のたびに再議論されるのではなく、一度だけ答えられるからだ。

ここで静かな部屋に戻る。

目標は、「これを許可したのは誰か」と誰も尋ねないことではない。目標は、誰かが尋ねたときに、その部屋にいる誰かが名前を挙げて、それを強制するシステムを指し示せることだ。

すべての玄関ドアと同様に、ゲートウェイの価値は、どれだけうまく開くかで測られるものではない。誰が通り抜けているかをどれだけ自信を持って知っているかで測られる。

この記事はBifrostチームとの協力で執筆された。ここに示されたアーキテクチャ的視点と結論は筆者自身のものです。