SOC 2 AI API ゲートウェイのスコープのレビューは、バッジから始めるべきではありません。まず尋ねるべきなのは単純な質問です。レポートは、どのシステム、期間、管理策、依存関係、そして購入者側が負う責任を実際に対象としていたのか、ということです。
この違いはモデルルーティングにおいて重要です。AI API ゲートウェイは、アプリケーションと複数のモデルプロバイダー、エンドポイント群、ログ、サポートワークフロー、請求記録、フォールバック経路の間に位置することがあります。SOC 2 Type 2 レポートは、ゲートウェイベンダーが記述したシステムと、対象となった信頼サービス基準について有用な証拠になり得ます。しかし、すべての上流モデルプロバイダー、すべてのルート、すべてのプロンプト保持設定、すべての購入者アカウント設定、または将来のすべてのモデル変更が承認済みであることの証明として扱うべきではありません。
調達、セキュリティ、法務、プラットフォームエンジニアリングが、レポートで何を証明すべきか、何を証明すべきでないか、そしてどのフォローアップ証拠を承認パケットに含めるべきかを判断する際には、この SOC 2 AI API ゲートウェイのスコープ チェックリストを使用してください。
Flatkey がこのレビューに関連するのは、現行の公開サイトが flatkey.ai を、1 つのキーで公式 GPT、Claude、Gemini、その他のモデル トラフィックをルーティングするための AI API ゲートウェイおよびモデル運用プラットフォームとして位置づけ、ダッシュボード、請求、ルーティング、利用状況、運用証跡の画面を備えているためです。Flatkey の公開ページと証明書検索ページは、日付付きのスクリーニング証拠にすぎません。本番承認では、非公開の SOC 2 レポート、該当する場合は署名済み契約/DPA、アカウント設定、ルート構成、そして実行予定のワークロードに関するサポート確認を求めてください。
より広い調達コンテキストについては、この記事に SOC 2 AI API ゲートウェイ証拠チェックリスト、AI ゲートウェイ調達証拠パケット、および AI API ベンダーリスク評価 を組み合わせてください。
SOC 2 AI API ゲートウェイのスコープ:クイック判定表
レビューの最初のページでは、レポート証拠と購入者側のフォローアップ証拠を分けるべきです。
| レビュー領域 | SOC 2 レポートが証明に役立つこと | それだけでは証明できないこと |
|---|---|---|
| 法主体 | どのサービス組織が審査されたか | すべての関連会社、再販業者、または上流モデルプロバイダーが対象であること |
| システム境界 | 記述されたシステムにどのプラットフォーム、サービス、所在地、インフラ、人員、プロセスが含まれるか | すべてのダッシュボード機能、エンドポイント群、顧客ルート、または将来の統合が対象であること |
| レポート期間 | Type 2 監査の対象期間 | 期間終了後も現在の管理策が変更されていないこと |
| 信頼サービスカテゴリ | セキュリティ、可用性、機密性、処理の完全性、プライバシーなど、どの基準が含まれていたか | 選択されなかったカテゴリも審査されたこと |
| テストされた管理策 | 監査人がどの管理策をテストし、その期間の結果がどうだったか | 購入者側の設定、ルートポリシー、またはワークロードのデータ分類がテストされたこと |
| 例外 | 管理策の例外が記録されていたか、また経営陣がどのように対応したか | 例外があなたの特定ワークロードにとって重要でないこと |
| サブサービス組織 | 主要な依存関係が含まれているか、除外されているか、または他のレポートで扱われているか | 上流のモデルプロバイダーの保持、学習、ログ記録、またはリージョン動作がカバーされていること |
| CUEC | 購入者が運用しなければならない補完的ユーザー実体管理策はどれか | ベンダーが購入者の鍵保管、マスキング、プロバイダー許可リスト、またはアプリ層のデータ分類に責任を負うこと |
これが SOC 2 AI API ゲートウェイのスコープ に関する核心ルールです。レポートは、定義された期間における記述済みサービス組織システムに関する証拠です。チームが作成し得るすべての AI ルートへの一律承認ではありません。
管理策を読む前に 5 つのスコープ項目を固定する
まず、クリーンな意見を探して読み進めるべきではありません。5 つの項目から始めてください。
| 項目 | 購入者への質問 | 保存すべき証拠 |
|---|---|---|
| 実体 | 監査対象のサービス組織は誰か? | レポート表紙、法主体、契約相手方、公開されていれば証明書検索 |
| システム | どのサービス、インフラ、チーム、プロセス、データフローが含まれるか? | システム記述、製品/サービス一覧、システム境界図 |
| 期間 | レポートはどの Type 2 期間を対象としていたか? | 開始日、終了日、必要に応じてブリッジレター |
| 基準 | どの信頼サービスカテゴリが含まれていたか? | セキュリティ、可用性、処理の完全性、機密性、プライバシーの範囲 |
| 依存関係 | どのサブサービス組織と CUEC が意見に影響するか? | インクルーシブ/カーブアウト方式、サブサービス一覧、購入者管理策一覧 |
AI ゲートウェイでは、システム項目が最も重要です。「API ゲートウェイ」はベース URL のルーティングだけを意味することもあれば、ダッシュボードアクセス、モデルカタログ、アカウント残高、利用量計測、リクエストログ、アラート、サポートワークフロー、インシデント対応、鍵管理まで含むこともあります。非公開レポートは、システム記述に何が含まれていたかを示すべきです。もし示していないなら、利用予定の正確なルートにレポートのスコープを対応付けるようベンダーに求めてください。
AI ゲートウェイに対して SOC 2 レポートが証明すべきこと
スコープが定められた SOC 2 Type 2 レポートは、購入者が以下の質問に答えるのを助けるべきです。
| 証明領域 | SOC 2で有用な証拠 | AIゲートウェイにおける解釈 |
|---|---|---|
| 統制の設計と運用 | 報告対象期間中にテストされた統制 | 記載されたゲートウェイシステムにおいて、アクセス、変更管理、監視、インシデント対応、ベンダー管理、および関連統制が運用されていたかどうか |
| 可用性の範囲 | 可用性基準、SLAに近接した監視、含まれる場合のインシデントプロセス | 対象サービスに定義済みの監視および対応統制があったかどうかであり、各モデルプロバイダーが引き続き利用可能であるかどうかではない |
| 機密性およびプライバシーの範囲 | これらのカテゴリが含まれる場合の基準と統制 | 記載されたシステムについて顧客データの取り扱い統制が検証されたかどうかであり、すべてのプロバイダー機能が同じ保持設定を持つかどうかではない |
| 変更管理 | テストされたリリース、承認、変更統制 | ゲートウェイのコード/設定変更が管理されていたかどうかであり、購入者が承認したルートを後から購入者が変更できないかどうかではない |
| アクセス統制 | 従業員アクセス、特権アクセス、管理者レビュー、アカウント管理統制 | ベンダー側のアクセスが管理されていたかどうかであり、購入者がAPIキーを安全に保管していたかどうかではない |
| 論理セキュリティ | 認証、認可、ログ記録、脆弱性、監視の各統制 | ゲートウェイで説明されているセキュリティ統制が存在していたかどうかであり、購入者アプリがプロンプト送信前にシークレットをマスクしているかどうかではない |
| ベンダー管理 | サブサービス組織およびベンダー監視統制 | ベンダー依存関係が管理されていたかどうかであり、上流の各プロバイダーのSOC 2、DPA、または保持設定があなたのルートをカバーしているかどうかではない |
ここでSOC 2 AI APIゲートウェイのスコープが実務的になります。レポートはベンダーリスクのスクリーニングを支援するかもしれません。それでも、エンドポイントファミリー、データ区分、プロバイダーの許可リスト、フォールバックポリシー、プロンプト/出力のログ記録、メタデータ保持、サポートアクセス、削除経路といったルートの事実に翻訳する必要があります。
レポートで証明すべきでないこと
最も一般的な調達上の誤りは、SOC 2レポートに、本来そのために設計されていない判断の代わりをさせることです。
レポート単独で、以下を証明するために使わないでください。
| 主張 | なぜ追加確認が必要か |
|---|---|
| 「すべてのモデルプロバイダーがカバーされている。」 | 上流プロバイダーはサブサービス組織であったり、カーブアウトされていたり、ゲートウェイのレポート範囲外であったりします。プロバイダーマップと該当するプロバイダーの証拠を求めてください。 |
| 「プロンプトや出力はどこにも保存されない。」 | ゲートウェイのログ、プロバイダーの不正利用監視ログ、アプリケーション状態、サポートチケット、バックアップには異なる保持動作があり得ます。 |
| 「すべてのルートに対して学習は適用されない。」 | 学習および保持の約束は、プロバイダー、アカウント、エンドポイント、機能ごとに異なることがよくあります。アカウントレベルの証跡を保存してください。 |
| 「フォールバックは承認済みである。」 | フォールバックルートは、別のプロバイダーまたはリージョンにデータを送信する可能性があります。承認記録には、許可されたフォールバックプロバイダーを明記すべきです。 |
| 「購入者のアプリは準拠している。」 | SOC 2はサービス組織の統制に関するものです。購入者側のマスキング、キー保管、データ分類、アプリのアクセス統制は購入者の責任です。 |
| 「プライバシーまたはDPAのレビューが完了している。」 | SOC 2は、署名済みDPA、データ移転評価、プライバシー通知、BAA、または地域別処理の約束ではありません。 |
| 「現在の状態は報告期間と同一である。」 | 報告期間は数か月前に終了している可能性があります。ブリッジレター、現在のポリシー、現在のルート設定、最近の証拠を求めてください。 |
| 「価格、モデルの可用性、SLAの結果が保証されている。」 | モデルカタログ、価格、プロバイダーのレート制限、第三者の可用性は、SOC 2レポートの外で変更されることがあります。 |
ベンダーが「SOC 2がそれをカバーしている」と言う場合は、正確なセクション、システム境界の文言、対象基準、統制、テスト結果、そしてCUECまたはサブサービス組織に関する注記を示すよう求めてください。
プロバイダーを承認する前にサブサービス組織を確認する
AIゲートウェイは、クラウドホスティング、決済システム、分析、サポートツール、可観測性ベンダー、セキュリティツール、上流のモデルプロバイダーに依存する場合があります。SOC 2レポートでは、サブサービス組織がどのように扱われているかを説明しているはずです。購入者が通常目にするのは、次の2つのアプローチのいずれかです。
| 方法 | 購入者にとっての意味 |
|---|---|
| インクルーシブ方式 | サブサービス組織の関連統制がレポートの範囲に含まれます。どの統制が含まれているかを確認してください。 |
| カーブアウト方式 | サブサービス組織はレポート範囲から除外されます。別個の証拠と、補完的なサブサービス組織の統制を確認してください。 |
モデルルーティングでは、カーブアウトが重要です。ゲートウェイのSOC 2レポートは、ゲートウェイのベンダー管理統制をカバーしていても、OpenAI、Anthropic、Google、または他の上流プロバイダーを監査対象システムの外に置いている場合があります。それでもレポートが無意味になるわけではありません。つまり、SOC 2 AI APIゲートウェイのスコープのレビューには、承認済みの各ルートについてプロバイダー証跡の行を含める必要があるということです。
ベンダーのドキュメントを見ると、なぜこれを推測できないのかが分かります。OpenAI の API データ管理では、乱用監視ログ、アプリケーション状態、Zero Data Retention、Modified Abuse Monitoring、エンドポイント固有の動作が分けて扱われています。Anthropic の API データ保持に関するドキュメントでは、API や機能ごとに必要な保存要件が異なり、ZDR は対象ユースケースに対して顧客が求める取り決めであることが説明されています。Cloudflare の AI Gateway ログに関するドキュメントでは、ゲートウェイがプロンプト、レスポンス、プロバイダー、タイムスタンプ、トークン使用量、コスト、継続時間、DLP アクション、ペイロードレベルのロギング制御を公開できることが示されています。これらは、Flatkey の非公開レポートについての主張ではなく、購入者があらゆるゲートウェイルートで確認すべきコントロール面の例です。
CUEC は定型文ではなく、購入者側の作業として扱う
補完的ユーザー実体コントロールは埋め草ではありません。サービス組織のコントロールに意味を持たせるために、購入者が運用しなければならないコントロールです。
AI ゲートウェイでは、購入者側の一般的な CUEC 作業には次のようなものがあります。
| 購入者が保有するコントロール | 保存すべき証跡 |
|---|---|
| キーの保管とローテーション | シークレットマネージャーのパス、担当者、ローテーション日、緊急ローテーション手順書 |
| ルート承認 | 承認済みエンドポイントファミリー、プロバイダーの許可リスト、フォールバック方針、データ分類 |
| プロンプトの秘匿化 | アプリケーションレベルの秘匿化ルール、テスト記録、ブロックされたフィールドの例 |
| アクセスレビュー | 管理者一覧、キー所有者、退職時対応記録、ダッシュボードアクセスレビュー |
| ログ方針 | プロンプトと出力を保存するかどうか、メタデータのみのルール、保持スケジュール |
| 利用監視 | 予算責任者、クォータ設定、アラート閾値、財務レビューの頻度 |
| インシデント対応フロー | リクエスト ID、サポートへのエスカレーション経路、証跡バンドル、通知責任者 |
| 更新トリガー | 新しいプロバイダー、エンドポイントファミリー、データ分類、ロギング変更のレビュー日とトリガー |
優れた SOC 2 AI API ゲートウェイのスコープ メモは、CUEC の一覧をエンジニアリング作業に紐づけるべきです。購入者がプロンプト送信前にシークレットを秘匿化しなければならないなら、承認にはその秘匿化テストへの参照を含めるべきです。購入者がモデルプロバイダーを承認しなければならないなら、ルート設定に許可リストを示すべきです。
Flatkey 固有の確認証跡として要求し、保存すべきもの
2026 年 7 月 11 日時点で確認した現在の Flatkey 公開ページは、この調達ワークフローで Flatkey を使うことを支持していますが、アカウント固有の証跡の代わりにはなりません。
| 証跡 | 公開確認で示された内容 | 使い方 |
|---|---|---|
| ホームページ | Flatkey は、1 つのキー、モデルルーティング、ダッシュボードでの確認、利用状況、コスト、ルーティング、エラーの可視化を通じて、公式の GPT、Claude、Gemini API を中心にサービスを公開しています。 | 日付付きの製品確認証跡として使用します。非公開の SOC 2 レポートのスコープとして扱わないでください。 |
| 料金ページと料金 API | 公開された料金/カタログの画面では、ライブの料金ページと、openai、openai-response、anthropic、image-generation、openai-video を含む 158 のモデル行とエンドポイントファミリーを持つ料金 API 応答が返されました。 |
日付付きのカタログスナップショットとしてのみ使用します。モデルとエンドポイントの利用可能性は変更される可能性があります。 |
| SLA ページ | SLA では、Flatkey が運用するホスト型ダッシュボード、API ゲートウェイ、ルーティング、計測、アカウントサービスに適用され、第三者の AI モデルプロバイダーやその他の外部システムは対象外であると記載されています。 | Flatkey が直接運用するものと、第三者依存関係を区別するために使用します。 |
| プライバシーおよび利用規約ページ | 公開ポリシーページでは、API アクセス、モデルルーティング、利用記録、請求、サポート、第三者モデルプロバイダー、モデル/プロバイダールールの変更について説明しています。 | 確認証跡として使用します。最終承認には、署名済み契約条件とルート固有のデータ処理証跡が依然として必要です。 |
| 証明書検索 | 公開 CAI 検索では、VOC AI Inc. の証明書 USA-SOC2-220513、SOC 2 Type II、有効、期間は 2025 年 7 月 15 日から 2026 年 7 月 14 日までと表示されました。 |
公開検索としてのみ使用します。実際の SOC 2 レポートを要求し、対象システム、基準、期間、例外、CUEC、サブサービスの扱いを確認してください。 |
Flatkey であれ、他の AI API ゲートウェイであれ、承認には次のように記載すべきです。「公開ページ確認済み。非公開レポート要求済み。ルート証跡添付済み。未サポートの前提条件を列挙済み。」
スコープからルートへの証跡パケットを作成する
このレビューの成果物は、あいまいな承認ではなく、小さな証跡パケットであるべきです。
| パケット項目 | 保存するファイル | 担当者 |
|---|---|---|
| SOC 2 レポート | 非公開レポート、レポート期間、基準、意見、例外、必要に応じてブリッジレター | 調達/セキュリティ |
| スコープマップ | レポートのシステム境界をダッシュボード、ゲートウェイ、API、メータリング、ログ、サポート、ルート設定にマッピングしたもの | プラットフォームエンジニアリング |
| プロバイダーマップ | 承認済みプロバイダー、フォールバック順序、サブサービスの扱い、個別のプロバイダー証跡 | セキュリティ/プラットフォーム |
| データマップ | プロンプト、出力、ファイル、メタデータ、請求記録、ログ、サポートチケット、バックアップ | セキュリティ/法務 |
| 保持マトリクス | エンドポイントファミリー別のゲートウェイ、プロバイダー、アプリケーション、サポート、バックアップの保持期間 | セキュリティ/法務 |
| CUEC記録 | 購入者側の統制と、それぞれが実装されている証拠 | プラットフォーム/セキュリティ |
| テスト証跡 | 低リスクのリクエストが1件成功した記録と、想定どおり失敗した1件の記録。リクエストIDとマスキング済みログを含む | プラットフォームエンジニアリング |
| 承認メモ | スコープ、制約、未解決リスク、レビュアー名、更新トリガー | 事業責任者/調達 |
このパケットは、SOC 2 レビューとエンジニアリング運用をつなぐ橋渡しにもなります。新しいプロバイダー、モデルクラス、ロギングモード、データクラスが追加された場合、どのファイルを更新すべきかをチームが把握できるようにしておくべきです。
承認を一時停止すべき赤信号
以下のいずれかが未解決なら、承認を一時停止してください。
- SOC 2 レポートが入手できず、バッジまたは証明書検索しか提供されていない。
- レポート期間が終了しており、ブリッジレターまたは最新の証跡がない。
- システム記述に、利用予定のゲートウェイ経路が明確に含まれていない。
- レポートが関連するサブサービス組織を除外しており、個別のプロバイダー証跡が添付されていない。
- 選択された信頼サービスカテゴリが、購入者が示したリスク、たとえばプライバシーや機密性と一致していない。
- CUEC が、未実装の購入者側統制を要求している。
- プロンプト/出力のログは無効化されている前提だが、それを証明するアカウントまたはルートの証跡がない。
- フォールバックが未承認のプロバイダーへデータを送信しうる。
- サポートがリクエスト内容を確認できるのに、サポートアクセス、チケット保持、マスキングの文書がない。
- 承認に担当者、有効期限、またはルート変更トリガーがない。
これらの赤信号は、必ずしもベンダー不合格を意味するわけではありません。SOC 2 AI API ゲートウェイのスコープレビューがまだ完了していないことを意味します。
実用的な承認文の例
役に立つ承認文は、短く、具体的で、検証可能です。
| 項目 | 文言例 |
|---|---|
| レポート証跡 | "Vendor X の SOC 2 Type 2 レポートを、期間 A〜B、セキュリティおよび可用性の基準について確認。対象ルートについて未受諾の例外なし。" |
| 承認済みスコープ | "承認済みのゲートウェイ基底 URL とチャットエンドポイントを通じた、本番のテキストのみのサポートワークフロー。" |
| プロバイダー | "Provider A を主、Provider B をフォールバックとする。画像、動画、ファイル、Web検索、バッチの各エンドポイントは使用しない。" |
| データクラス | "アプリケーションレベルのマスキング後の顧客サポートテキスト。支払いデータ、秘密情報、PHI、規制対象記録は含まない。" |
| ロギング | "ゲートウェイのメタデータログは許可。生のプロンプト/出力ログは無効、または別途承認済み。プロバイダーの保持証跡を添付。" |
| 購入者側統制 | "キーはシークレットマネージャーに保存、四半期ごとのアクセスレビュー、ルートの許可リスト、月次利用レビュー、インシデント責任者を割り当て済み。" |
| 更新トリガー | "プロバイダー追加、新しいエンドポイントファミリーの有効化、ロギング変更、規制データのルーティング、または SOC 2 期間終了前に更新する。" |
これが「承認済み」の意味であるべきです。開発者はどのルートを使えるかを把握できます。調達は、どの証跡が確認されたかを把握できます。セキュリティは何を監視すべきかを把握できます。法務は、どの前提に契約文言がまだ必要かを把握できます。
要点
SOC 2 AI API ゲートウェイのスコープレビューは、正確さを保つ限り有用です。レポートは、監査対象サービス組織の記述されたシステム、対象基準、統制の運用、レポート期間、例外、サブサービスの扱い、購入者責任を証明する助けとなるべきです。すべてのルート、プロバイダー、保持設定、フォールバック動作、DPA 条項、データ所在地の主張、購入者設定まで証明するものに拡張すべきではありません。
Flatkey では、まず現在の公開証跡から始め、そのうえで非公開の SOC 2 レポートを取得し、チームが実際に運用するルートにマッピングしてください。1 つの API キーと 1 つのダッシュボードで複数モデルにアクセスしたい場合は、キーを取得し、SOC 2 AI API ゲートウェイのスコープチェックリストを調達パケットに添付し、各本番ルートを、明示的なプロバイダー、ロギング、保持、CUEC の証跡とともに承認してください。
よくある質問
SOC 2 AI API gateway scope とは何ですか?
SOC 2 AI API gateway scope とは、AI API ゲートウェイに適用される SOC 2 レポートの境界です。監査対象エンティティ、記述されたシステム、レポート期間、信頼サービスカテゴリ、テスト済み統制、サブサービス組織、対象外範囲、購入者が所有する CUEC が含まれます。
SOC 2 は、すべての AI モデルプロバイダーが対象であることを証明しますか?
いいえ。SOC 2 は、ゲートウェイベンダーが記載されたシステムとその依存関係をどのように管理しているかを示すことはできますが、上流のモデルプロバイダーは、含まれる場合もあれば、除外される場合もあり、または別個の証拠でカバーされる場合もあります。購入者は、承認済みの各ルートについてプロバイダーマップを保存すべきです。
SOC 2 Type 2 レポートは、プロンプトが保持されないことを証明しますか?
それだけでは証明できません。プロンプトと出力の保持は、ゲートウェイ、上流プロバイダー、アプリケーション状態、サポートチケット、ログ、バックアップの間で異なる場合があります。購入者は、エンドポイント、アカウント、およびルート固有の保持証跡を確認すべきです。
SOC 2 バッジを見た後、調達担当は何を求めるべきですか?
非公開の SOC 2 レポート、レポート期間、対象基準、システム記述、例外、サブサービス組織の取り扱い、CUEC、必要に応じてブリッジレター、プロバイダーマップ、ルート構成、ログ設定、保持マトリクス、そして該当する場合は署名済みの契約/DPA の証拠を求めてください。
スコープレビューはどのくらいの頻度で更新すべきですか?
SOC 2 AI API ゲートウェイのスコープレビューは、レポート期間の満了時、ベンダーが新しいレポートを提供したとき、プロバイダーまたはエンドポイントファミリーを追加する前、新しいデータ分類をルーティングする前、ログや保持が変更されたとき、そして重大なインシデントの後に更新してください。



