HopBase結論から言うと、LLM API ベンダーに対する企業のセキュリティ審査は 4 つのレイヤーに集約されます。キーガバナンス（最小権限と即時失効：漏えいしたキーはそのキーだけで被害が完結し、他チームのトラフィックに一切触れずに数秒で失効できること）、データ経路（リクエストとレスポンスの内容が保存されるか、ログはどの項目をどれだけの期間保持するか、学習に使われる可能性はあるか）、監査と照合（すべての呼び出しをキー・モデル・トークン数まで追跡でき、失敗したリクエストは課金されず、途中まで生成された出力にはその旨が明記されること）、そしてベンダーの検証可能性（口頭の約束は数に入らず、再現できる挙動だけが根拠になる）です。以下は 10 項目のチェックリストで、各行に合格基準だけでなく自分で検証する方法も記載しています。キーを 2 本作って 1 本を失効させる、意図的に失敗させて請求を確認する、といった方法です。私たちを含め、どのベンダーにも使えます。
レイヤー 1：キーガバナンス
ほぼすべてのインシデントは認証情報の漏えいから始まります。正しい原則はただ 1 つ、どのキーも被害範囲を最小にすることです。
- アプリごと・チームごとにキーを 1 本——漏えいしても失うのはその 1 本だけで、失効させても他には影響しません。
- モデル許可リスト——キーは含まれるグループが提供するモデルしか呼び出せないため、漏えいしたキーでもその範囲外には届きません。
- 独立したクォータ——キーごと・メンバーごと・部門ごとに設定でき、暴走した連携が全体の予算を食い潰すことはありません。
- ハッシュのみで保存——HopBase は API キーを一方向ハッシュで保存し、平文のキーがデータベースに書き込まれることはありません。データベースが盗まれてもキーは復元できません。
レイヤー 2：データ経路
どのベンダーにも、次の 3 つの質問を書面で投げかけてください。
- リクエストとレスポンスの内容は保存されますか？
- ログはどの項目を、どれだけの期間保持しますか？
- データが学習やその他の二次利用に使われる可能性はありますか？
私たちの公開方針はコンテンツを長期保持しないことです。プロンプトと出力はリクエストの処理にのみ使い、業務データとして長期保存せず、モデルの学習にも使いません。課金メタデータ（モデル、トークン数、レイテンシ、ステータス）は請求と監査のために保持します。失敗したリクエストはトラブル対応のため短期間保存することがあり、期限後に自動削除されます。通信はすべて TLS で暗号化されています。各プランのチャネル属性は料金ページに明記しているので、プランごとに評価できます。
レイヤー 3：監査と照合
- すべてのリクエストにモデル・使用量・レイテンシ・ステータスの記録が残るため、異常をキー・時刻・モデル・量まで追跡できます。
- 使用明細はエクスポートでき、請求額は実際の消費量と一致します。
- 失敗したリクエストは課金されません。出力を生成する前に失敗したリクエストは無料です。唯一の例外は、出力がすでに生成された後に中断されたリクエスト（たとえばストリーミング中にクライアントが切断した場合）で、生成済みの使用量分が課金され、エクスポートには「Request interrupted, charged for the usage already generated」と明記されるため、すべての行を確認できます。
レイヤー 4：ベンダーの検証可能性
モデルのすり替えなし、密かな性能劣化なし、データ保持なし——どのベンダーもそう主張します。主張は検証できませんが、挙動は検証できます。ベンダーには次のことを求めてください。
- チャネル属性の公開——各プランが何の上で動いているかをオープンにしていること。
- エラーのパススルー——モデル提供元のエラーコードをそのまま返し、握りつぶしたり書き換えたりしないこと。
- テストの歓迎——再現可能な忠実度テストに難色を示すベンダーは、それ自体がすでに答えになっています。
1 ページのチェックリスト
| 項目 | 合格基準 | 検証方法 |
|---|---|---|
| キーの粒度 | アプリごとに 1 本、即時失効が可能 | キーを 2 本作って 1 本を失効させ、もう 1 本に影響がないことを確認する |
| モデル許可リスト | キーは許可されたモデルにしか届かない | 許可されていないモデルを呼び出し、きちんと拒否されることを確認する |
| クォータの分離 | キー／メンバー／部門ごとに独立 | テスト用キーのクォータを使い切り、他のキーに影響がないことを確認する |
| コンテンツ保持 | プロンプト／出力を長期保持せず学習にも使わない。保持範囲と期間を書面で示せる | 保持ポリシーと項目一覧を書面で要求する |
| 通信経路 | 全経路で TLS | 証明書チェーンを確認する。平文 HTTP は失格 |
| キーの保存 | サーバーはハッシュのみを保持 | 「データベースが漏えいしたら平文のキーが分かるか」を質問する |
| 監査の粒度 | リクエストごとのモデル／使用量／レイテンシ／ステータス | 使用明細をエクスポートして抜き取り確認する |
| 失敗時の課金 | 失敗したリクエストは無料、出力後に中断したリクエストには明記がある | 意図的に失敗させ、請求とエクスポートの備考を確認する |
| エラーのパススルー | 提供元のエラーコードをそのまま返す | レート制限を発生させ、公式の挙動と比較する |
| 忠実度 | ベンダーがテストを歓迎する | 5 つの忠実度チェックを実行し、反応を見る |
よくある質問
HopBase は私のデータを保存したり、学習に使ったりしますか？
学習には使わず、業務データとして長期保存することもありません。プロンプトと出力はリクエストの処理にのみ使います。課金メタデータ（モデル、トークン数、レイテンシ、ステータス）は請求と監査のために保持し、失敗したリクエストはトラブル対応のため短期間保存することがありますが、期限後に自動削除されます。
ゲートウェイは経由点が 1 つ増える分、リスクも増えるのでは？
その 1 つの経由点で、ガバナンスを一元化できます。キーの階層、クォータ、許可リスト、監査、失効を統一的に管理できるのです。代わりに N 個のチームがそれぞれ提供元の生キーを持つ形にすると、漏えい面は広がり、ガバナンスのコストも上がります。経路そのものはエンドツーエンドで TLS です。
このチェックリストはどう使えばよいですか？
複数のベンダーを並行してこのリストにかけ、項目ごとにデモか書面での確認を求めてください。モデル側は忠実度テストで検証します。価格の話はそのあとです。
企業での導入とセキュリティ審査についてはお問い合わせください。接続方法の詳細はドキュメントをご覧ください。