【ITニュース解説】Gating Access with Bifrost: Nine Calls, Three Refusals, One Trap

裁判所での仕事は、誰がどんな情報にアクセスできるかを決めることだ。例えば、同じ事件を扱う通訳者、速記者、書記官であっても、職務に応じて見られる情報が異なる必要がある。裁判所の記録には公開されるべき情報と、プライバシー保護のために非公開にすべき情報が混在しており、その線引きはファイル全体ではなく、情報の一部分に細かく設定されている。このような複雑なアクセス管理は、システムエンジニアが直面する現実的な課題の一つである。

このような課題に対応するため、AIゲートウェイであるBifrostが注目された。BifrostはMaxim AIが開発したオープンソースのツールで、AIアプリケーションとOpenAIのようなAIプロバイダーの間に位置する。つまり、アプリケーションはBifrostと通信し、Bifrostがプロバイダーと通信することで、複数のAIプロバイダーを一つの窓口で管理できる仕組みである。GitHubで公開されており、自分で構築して利用できる。

Bifrostのようなゲートウェイを導入する最大の目的の一つは、AIプロバイダーへのアクセスを一元的に制御することにある。もし複数の人が共通のAPIキーを使って直接AIプロバイダーにアクセスすると、誰がどれだけの費用を使ったか分からなくなったり、特定の人だけアクセスを停止することが難しくなる。Bifrostは「仮想キー」という概念を導入し、この仮想キーに個別のアクセス権限と利用予算を設定できる。これにより、実際のAPIキーはBifrostの内部に安全に保管され、外部に漏れることなく、きめ細やかなアクセス制御が可能になる。

このアクセス制御において重要な考え方が二つある。一つは「ロールベースアクセス制御（RBAC）」、もう一つは「最小権限の原則」である。RBACとは、個々のユーザーに直接権限を付与するのではなく、「書記官」「通訳者」といった「ロール（役割）」に対して必要な権限を定義し、ユーザーはそのロールに割り当てられることで権限を得る仕組みである。これにより、人事異動などでユーザーの役割が変わった際に、ロールを切り替えるだけでアクセス権限が自動的に変更され、個別の権限を一つずつ修正する手間が省ける。

最小権限の原則とは、職務を遂行するために「必要最小限のアクセス権限」のみを付与し、それ以外のアクセスは一切認めないという考え方である。例えば、書記官は法廷での作業を滞りなく進めるために、通訳者や速記者よりも多くの情報にアクセスする必要があるが、それは職務上必要な範囲に限定される。裁判所の規則でも、機密情報を保護する際には「必要最小限の部分のみ」を非公開にし、他の部分は公開状態を保つよう求められており、これは最小権限の原則と全く同じ考え方である。

筆者はBifrostを実際に構築し、このアクセス制御機能が期待通りに動作するかを検証した。通訳者、速記者、書記官という三つのロールを作成し、それぞれに「routine」「standard」「restricted」という三つの異なるAIモデルへのアクセス権限と日ごとの予算を設定した。例えば、通訳者には「routine」モデルのみ、書記官には全てのモデルへのアクセスを許可した。目標は、合計9回のAPI呼び出し（各ロールが各モデルにアクセス）のうち、事前に計画した6回は成功し、3回はゲートウェイで拒否されることであった。特に、拒否されるべきアクセスが実際に拒否されるかどうかが検証の鍵となる。

検証にあたっては、テスト用のコードをAIに書かせた上で、その信頼性を確保するための工夫を凝らした。スクリプトは、実行前に「何が起こると予想されるか」を明示し、実行後に「実際に何が起こったか」を報告する。そして、両者が一致するか不一致かを明確に表示する。これにより、テスト結果が直感的に理解でき、もし不一致があればすぐに問題を発見できる。また、テストログは一切編集されない生データと、それを平易な言葉で説明するレポートの二種類を用意し、客観的な証拠として利用できるようにした。

この検証プロセスで、システムエンジニアが設定時に陥りやすい重要なポイントが明らかになった。Bifrostには「モデル予算」と「アクセス＆レートリミット」という二つのアクセス制御機能があるが、それぞれ異なる役割を持つ。モデル予算はAIモデルごとの利用費用の上限を設定するもので、どのモデルにアクセスできるかを制御するものではない。一方、「アクセス＆レートリミット」が、仮想キーがどのモデルにアクセスできるかを決定する。デフォルト設定では「全てのモデル」にアクセスが許可されているため、予算だけを設定しても、実際には制限がかからない可能性がある。筆者もこの点を見落としかけ、もし気づかなければ、アクセス制限が機能していないのにテストが成功したと誤解してしまうところだった。この経験は、設定項目の意味を正確に理解し、デフォルト設定に注意することの重要性を示している。

最終的なテスト結果は、期待通り6回のAPI呼び出しが許可され、3回が拒否された。拒否された呼び出しはすべてHTTP 403エラーを返し、その理由も明確に記録された。この結果の信頼性をさらに高めるため、「意図的な破壊テスト」も実施された。これは、あえてシステムの設定を変更して、テストハーネスがその変更を正しく検出し、「予測と異なる結果」を報告するかを確認するテストである。筆者がBifrostのUIで一時的にアクセス許可を広げたところ、テストハーネスは正確にそれを検出し、MISMATCH（不一致）を報告した。これにより、テスト結果が単に「予測通り」だっただけでなく、「正しい動作」であることを確認できた。また、Bifrostを停止して呼び出しを試みるとエラーになることや、エラーメッセージにBifrost固有の用語が含まれていることなどから、すべてのアクセス制御がBifrostゲートウェイで適切に行われていることが証明された。

拒否されたアクセスに関する重要な発見は二つある。一つは、Bifrostゲートウェイでアクセスが拒否された場合、そのリクエストはAIプロバイダーに到達しないため、費用が全くかからないということである。レイテンシ（応答時間）、トークン数、費用がすべてゼロと記録され、予算管理の観点から非常に有用である。もう一つは、拒否されたアクセスについても、Bifrostのログに詳細が記録されることである。「誰が（仮想キー名）、何を（モデル）、なぜ（拒否理由）、いつ（日時）」アクセスしようとして拒否されたかが明確に記録され、JSON形式でエクスポートも可能である。これは、単に「アクセスを禁止する」というポリシーだけでなく、「アクセスが禁止されたことを証明する」というコントロール機能として極めて重要である。特に裁判所のような環境では、「システムがそれを許さなかった」ということを後日、具体的な記録をもって証明する必要があるため、この監査証跡は不可欠である。

今回の検証で、筆者が最も強く感じたのは、アクセス制御、特に最小権限の原則は、規模の大小にかかわらず全てのアプリケーションにとって重要な「衛生管理」であるという点である。三つのロールを設定するのに要した時間は一時間にも満たず、拒否された呼び出しには費用がかからないため、非常に低コストで実現できる。システムエンジニアを目指す人にとっての重要な教訓は、アクセススコープを設定する際は、単に予算だけでなく、どのリソースにアクセスできるかを明確に定義すること。そして何よりも、設定を終えたら必ず「自分で自分のルールを破ろうとする」テストを実行し、設定が期待通りに機能することを確認するべきである。テストされていない境界は、単なる「主張」に過ぎず、実際に機能する「コントロール」ではないことを忘れてはならない。