SOC 2 AI APIゲートウェイの証跡：調達前に確認すべき点

SOC 2 AI API gatewayのレビューは、購入者がセキュリティ資料を求める前に始めるべきです。調達における問いは「バッジはありますか？」ではありません。ゲートウェイ、モデルルート、ログ、キー、請求記録、サポートプロセス、下流のプロバイダーを、セキュリティレビュー担当者が実際に確認できる証跡に結び付けられるかどうかです。

このガイドは、本番トラフィック前にAI API gatewayを評価する調達、セキュリティ、プラットフォーム、コンプライアンス、ベンダーリスクの各チーム向けです。法務または監査の助言ではありません。実務的な証跡チェックリストとして活用してください。何を要求するか、SOC 2レポートで何を確認するか、ゲートウェイで何をテストするか、そして自社の購入者側ファイルに何を保管するか、です。

Flatkeyが関連するのは、flatkey.aiが公開上、この製品を本番AIチーム向けの1つのAPI gatewayとして位置付けており、モデルアクセス、ルーティング、請求、使用分析、運用制御、ダッシュボード、複数プロバイダー向けの1つのキーを提供しているためです。Flatkeyの公開フッターには、VOC AI Inc. の証明書検索ページへのリンクもあり、SOC 2 Type IIのエントリとISO 27001:2022のエントリが表示されています。また、2026年6月19日に確認された現在のpricing APIスナップショットでは、23ベンダーにわたる638のモデル行が返されました。これらは日付付きの公開証跡として扱い、非公開のSOC 2レポート、署名済み契約、DPA、アカウント設定、または本番ログ検証の代替にはしないでください。

クイックアンサー: SOC 2 AI API Gateway の証拠が示すべきこと

SOC 2 AI API gateway のレビューでは、次の3点が証明されている必要があります。ベンダーの統制報告書が関連するサービスをカバーしていること、ゲートウェイが AI トラフィックに関する運用証跡を出力できること、そしてベンダー報告書が顧客側に委ねている責任について自社チームが統制を持っていることです。

Review Area	Evidence To Request	What To Verify
SOC 2 report scope	Current SOC 2 Type II report, report period, auditor, system description, and bridge letter if the report period is stale.	The AI gateway, API routing, logging, support, billing, and relevant infrastructure are inside the system boundary.
Trust Services Criteria	Categories covered by the report, commonly security plus any availability, confidentiality, processing integrity, or privacy criteria.	The covered categories match the buyer risk. Do not assume privacy or availability are covered unless the report says so.
Complementary user controls	CUECs and buyer responsibilities listed in the SOC 2 report.	Your team can satisfy key management, route approval, data classification, user access, retention, and incident responsibilities.
Subservice organizations	Carve-out or inclusive subservice organization description, provider list, and monitoring controls.	Downstream model providers, cloud services, support tools, observability, and billing vendors are handled consistently with the report model.
AI gateway operations	Sample logs, key ownership fields, route-change history, model-provider route inventory, and incident export process.	The gateway can show who sent traffic, which model/provider received it, what changed, and what evidence is retained.
Data and privacy	Privacy policy, DPA path, data-processing locations, retention policy, payload logging policy, and provider data-use terms.	Prompts, outputs, metadata, support materials, and billing records have clear handling rules.
Buyer-side evidence	Your own rollout record, approved use cases, key taxonomy, route policy, logging mode, and review cadence.	The vendor evidence is tied to how your team will actually use the gateway.

SOC 2 のバッジではなく、スコープから始める

公開バッジは初期スクリーニングには役立ちますが、調達ではベンダーの信頼プロセスに基づいて、実際の SOC 2 レポートの提示を依頼すべきです。AICPA は、SOC 2 レポーティングを、セキュリティ、可用性、処理の完全性、機密性、またはプライバシーに関連するサービス組織の統制に関する検証と説明しています。つまり、調達で本当に重要な質問はスコープです。どのシステム、サービス、期間、基準、統制、例外、そして経営者の表明が含まれているのか、ということです。

SOC 2 AI API ゲートウェイ については、スコープレビューで次の点に答える必要があります。

スコープ項目	購入者の質問	AI API トラフィックにとって重要な理由
法人	レポートと契約書に記載されているのはどの法人ですか？	Flatkey の公開証明書検索は VOC AI Inc. を参照しています。調達ファイルは契約主体およびサービス所有者と一致している必要があります。
システム境界	レポートには AI ゲートウェイ、API ルーティング、ダッシュボード、キー、請求、利用記録、サポートプロセスが含まれていますか？	より広範なデータまたは分析プラットフォームに関するレポートでは、利用予定の特定のゲートウェイワークフローを証明できない場合があります。
報告期間	Type II レポートはどの期間をテストしており、ブリッジレターは必要ですか？	調達では通常、過去の時点の記述だけでなく、最新の運用証拠を求めます。
信頼カテゴリ	どの Trust Services Criteria が含まれていますか？	セキュリティが含まれていても、可用性、機密性、処理の完全性、またはプライバシーが自動的に含まれるわけではありません。
例外	どの統制が限定付き、例外扱い、または是正済みでしたか？	例外は、鍵管理、ログ記録、変更管理、インシデント対応、またはベンダー監視に影響する可能性があります。
サブサービス組織	どのクラウド、プロバイダー、サポート、可観測性、支払いサービスが除外または含有されていますか？	AI ゲートウェイのリスクは、下流のモデルおよびインフラプロバイダーに大きく依存することがよくあります。

実務上のルールはシンプルです。購入者が SOC 2 レポートを、実際のゲートウェイサービスとトラフィック経路に結び付けられない場合、そのレポートはスクリーニングの証拠にすぎず、最終的な調達証拠ではありません。

AI Gateway 制御に SOC 2 基準をマッピングする

AICPA Trust Services Criteria は、セキュリティ、可用性、処理の完全性、機密性、およびプライバシーを対象としています。SOC 2 AI API gateway のエビデンスパケットは、これらの広範なカテゴリを具体的な gateway チェックに落とし込む必要があります。

Control Topic	Evidence To Verify	Related SOC 2 Concern
API key ownership	Keys は所有者、環境、アプリ、ワークフローに紐づけられており、key の作成と失効は監査可能である。	論理的アクセス、説明責任、変更管理、およびインシデント封じ込め。
Route and model approval	承認済み provider、endpoint family、model row、fallback rule、変更記録をレビュー可能である。	変更管理、ベンダー監視、処理の完全性、および機密性。
Audit logs	ログには timestamp、key または project、route、provider、model、endpoint family、status、error class、usage unit、管理上の変更が記録されている。	監視、インシデント対応、アクセスレビュー、および運用証跡。
Payload handling	prompt/output logging mode、redaction、アクセス制限、保持期間、および削除手順が文書化されている。	機密性、プライバシー、およびデータ最小化。
Usage and billing	usage records と billing records は raw payload から分離され、owner、model、route、cost center に紐づけられている。	処理の完全性、説明責任、および財務レビューの支援。
Incident review	セキュリティイベント、provider の障害、不審な利用、key の漏えい、fallback loop、上限超過イベントに対して runbook と export path がある。	セキュリティ監視、対応、および是正。
Vendor and provider changes	provider の追加、削除、地域変更、およびデータ利用ポリシー変更が再レビューをトリガーする。	サブサービス組織の監視とリスク評価。

ここが AI gateway と一般的な API gateway の違いです。route は単なる host/path の判断ではありません。どの model provider が prompts を見るか、どの data policy が適用されるか、どの retention rule が適用されるか、どの fallback path が許可されるか、どの usage unit が課金されるかを決定し得ます。

調達前に確認すべきFlatkeyの証跡

Flatkeyには、初期のSOC 2 AI API gatewayレビューに有用な公開証跡があります。公開サイトには、FlatkeyがAI製品を提供するチーム向けに、モデルアクセス、ルーティング、請求、利用分析、運用管理を統合すると記載されています。フッターには、VOC AI Inc.向けのCert AssureによるSOC 2 Type II検索へのリンクがあり、証明書 `USA-SOC2-220513`、有効期間は2025年7月15日から2026年7月14日まで、確認時点では有効ステータスでした。同じフッターには、VOC AI Inc.向けのISO 27001:2022検索へのリンクもあり、証明書 `USA-I-270513`、有効期間は2024年5月1日から2027年4月30日まで、確認時点では有効ステータスでした。

これらの公開ページを出発点として、調達前にFlatkeyへ直接以下を確認してください:

Flatkey Check	What To Capture	Guardrail
SOC 2 report request	Current report, auditor, period, scope, covered criteria, exceptions, subservice organizations, and bridge letter if needed.	Do not rely on the public badge or certificate lookup alone.
ISO 27001:2022 cross-check	Certificate entity, activity scope, dates, and any statement of applicability or security overview available under trust review.	ISO certification supports an ISMS review, but it does not replace the SOC 2 report or AI-route validation.
Catalog and endpoint support	Current model row, provider, endpoint family, availability status, and pricing unit from Flatkey pricing.	Model counts, vendor counts, and availability can change; verify on the day you approve the route.
Dashboard evidence	Key owner, route, model, provider, status, usage unit, billing record, and any export path in the current Flatkey dashboard.	Do not assume exact dashboard labels from public marketing copy.
Logs and retention	Metadata fields, payload logging behavior, retention period, viewer permissions, support-data handling, and deletion/export process.	Flatkey's public privacy policy mentions request metadata, error records, usage records, necessary logs, and support materials, but a buyer needs account-specific terms.
Provider route policy	Approved providers, fallback constraints, provider data-use terms, and who can change routes.	Reliability fallback can become a vendor-risk change if the downstream provider changes.

セキュリティ承認前にゲートウェイをテストする方法

ライブの顧客トラフィックを待って、SOC 2 AI API gateway の証跡が完全かどうかを確認しないでください。各ルートごとに制御されたスモークテストを実行し、レビュー用パケットを保存します。

1. 秘密情報を含まないルート識別子を作成する: ステージング、本番、バッチ、顧客向け、評価トラフィック用に別々のキーまたはプロジェクトを使用します。
2. 低リスクのモデルルートを1つ選ぶ: プロバイダー、モデル行、エンドポイントファミリー、価格単位、想定データクラスを記録します。
3. 無害なテストリクエストを送信する: 実際の顧客データ、個人データ、秘密情報、または規制対象コンテンツは使用しないでください。
4. ログレコードを確認する: タイムスタンプ、キー/プロジェクト、所有者、ルート、プロバイダー、モデル、ステータス、使用単位、エラークラス、コストの可視性を確認します。
5. 管理証跡を確認する: 誰がキーを作成したか、誰がルートを承認したか、誰がフォールバックを変更できるか、変更がどこに記録されるかを確認します。
6. 拒否パスをテストする: 許可されていないモデル、ブロックされたデータクラス、期限切れのキー、またはクォータの境界を試し、その結果を保存します。
7. 保持を文書化する: メタデータ、ペイロード（ある場合）、サポートチケット、請求記録、セキュリティログがどこに保持されるかを特定します。
8. 調達書類を添付する: SOC 2 レポート、ブリッジレター、ISO 証跡、プライバシーポリシー、利用規約、DPA のパス、プロバイダーレビュー、およびロールアウトノート。
9. 変更時に繰り返す: プロバイダー、モデル、エンドポイントファミリー、フォールバック、データクラス、ログ記録モード、または契約条件が変わったら、パケットを再実行します。
10. 公開証跡と非公開証跡を分ける: 公開ページは事前確認に役立ちます。非公開レポートとアカウント固有の検証が調達を完了させます。

SOC 2 は AI Gateway レビューのあくまで一層にすぎない

SOC 2 AI API gateway のレビューは、ISO 27001、GDPR、アプリケーションセキュリティ、ベンダーリスクチェックと並んで行うべきです。これらのフレームワークは関連していますが、答える問いはそれぞれ異なります。

Framework Or Source	What It Helps Verify	What It Does Not Prove By Itself
SOC 2	記載されたシステムおよび報告対象期間中の Trust Services Criteria に対する統制の独立した検証。	Flatkey のすべての機能、顧客アカウント設定、下流のモデルルート、または購入者のワークフローが対象であることは証明しません。
ISO/IEC 27001:2022	情報セキュリティマネジメントシステムの範囲、リスク管理、認証ステータス。	SOC 2 レポートの代わりにはならず、特定の AI リクエストログスキーマを証明するものでもありません。
GDPR	個人データに関する処理者レビュー、処理のセキュリティ、データ最小化、保持、移転保護、役割マッピング。	ゲートウェイが SOC 2 レビュー済みであるというだけでは、これが満たされたことにはなりません。
OWASP logging guidance	実践的なログ設計、イベント属性、除外すべきデータ、ログの保護、監視上の懸念。	ベンダーの保持ポリシーを定義するものでも、プロンプト/出力の取り扱いが適切であることを証明するものでもありません。
Buyer controls	キーの分類体系、ユーザーアクセス、ルート承認、データ分類、モデルフォールバック、保持、インシデントレビュー。	ベンダー統制の代わりにはなりません。ベンダーの証跡を自社環境で利用可能にするものです。

より広い調達スタックについては Flatkey の関連する enterprise AI API gateway checklist を、セキュリティチームが通常求める証跡項目については audit logs for AI API usage をご利用ください。

調達エビデンスパケットテンプレート

SOC 2 AI API ゲートウェイレビューから得られる最も有用な成果物は、営業技術、セキュリティ、法務、プラットフォームの各チームが読める簡潔なパケットです。

パケット項目	含める項目	担当者
ベンダーの識別情報	法人名、契約主体、サポート連絡先、トラストポータルのパス、証明書検索リンク、現在のステータス。	調達
SOC 2 ファイル	報告書の種類、対象期間、監査人、システム境界、Trust Services Criteria、例外、サブサービス組織、CUEC、ブリッジレター。	セキュリティ
ゲートウェイルートファイル	承認済みプロバイダー、モデル、エンドポイントのファミリー、フォールバックルール、データクラス、ルート所有者、変更承認者。	プラットフォームエンジニアリング
ログと証跡ファイル	リクエストのメタデータ項目、管理ログ、ペイロードポリシー、保持クラス、エクスポート方法、閲覧者アクセスリスト。	セキュリティ運用
データ保護ファイル	DPA のパス、プライバシーポリシー、利用規約、プロバイダーのデータ利用レビュー、処理場所、サブプロセッサー一覧、GDPR における役割の注記。	法務・プライバシー
買い手側の統制	キーの分類体系、アクセスレビューの頻度、ルート変更プロセス、クォータポリシー、インシデント対応手順、再レビューのトリガー。	プラットフォームおよびガバナンス
開始承認	最終承認者、承認済みユースケース、ブロックされたデータクラス、開始日、レビュー日、残余リスク。	セキュリティおよびプロダクト

レビュー時のレッドフラッグ

SOC 2 AI API gateway の証拠に次の未解決のギャップがある場合は、調達を一時停止してください:

• バッジだけの回答: ベンダーはバッジを示すだけで、NDA または信頼アクセスの下で現在の SOC 2 レポートを提供できない。
• スコープの不一致: レポートが、調達対象のゲートウェイとは異なる製品、法人、インフラ境界、または期間を対象としている。
• CUEC プランなし: レポートには顧客の責任が記載されているが、購入側が社内でそれらを割り当てていない。
• 不透明なサブサービス組織: 下流のモデルプロバイダー、サポートツール、ログツール、またはクラウドプロバイダーが明確に扱われていない。
• ルート変更の証拠なし: どの担当者がプロバイダーを追加し、モデルを変更し、またはフォールバックを有効化したのかをチームが示せない。
• ペイロードログの曖昧さ: プロンプトと出力は保存される可能性があるが、保持、アクセス、削除が不明確である。
• ダッシュボードのみの証拠: スクリーンショットはあるが、セキュリティレビュー用のエクスポート可能またはレビュー可能な証拠ファイルがない。
• 再レビューのトリガーなし: 新しいモデル、リージョン、エンドポイントファミリー、プロバイダーのポリシー変更が、調達/セキュリティレビューなしに発生しうる。

よくある質問

SOC 2 AI API ゲートウェイの証拠とは何ですか？

SOC 2 AI API gateway の証拠とは、AI ゲートウェイの統制が調達レビューをどのように支援するかを示す文書、ログ、ルート記録、統制マッピング、そして購入者側のメモの集合です。これには、ベンダーの SOC 2 レポート、スコープレビュー、サブサービス組織の取り扱い、監査ログ、キーの所有権、ルート承認、保持ポリシー、顧客責任が含まれます。

SOC 2 バッジだけで AI API ゲートウェイを承認するのに十分ですか？

いいえ。バッジは初期スクリーニングには役立ちますが、調達では最新の SOC 2 レポート、対象システム、報告期間、基準、例外、サブサービス組織、および補完的利用者事業体統制を確認すべきです。非公開レポートと購入者側のルートテストは、バッジ単独よりも重要です。

SOC 2 はゲートウェイの背後にあるすべてのモデルプロバイダーを対象にすべきですか？

必ずしもそうではありません。SOC 2 レポートは、サービス組織のシステムとサブサービス組織がどのように扱われるかを記述し、多くの場合、カーブアウト方式またはインクルーシブ方式で示されます。購入者は、モデルプロバイダー、クラウドサービス、サポートツール、オブザーバビリティサービスがどのように表現されているかを確認し、そのうえで各プロバイダー独自のデータおよびセキュリティ条件を確認すべきです。

AI API ゲートウェイにおいて SOC 2 と GDPR はどのように関連しますか？

SOC 2 はセキュリティ統制の証拠を支援できますが、GDPR のレビューでは、処理の役割、適法な根拠、データ最小化、処理者条件、移転、保持、データ主体の権利に焦点を当てます。SOC 2 AI API gateway は有用な証拠を一元化できますが、GDPR の義務を自動的に解決するものではありません。

購入前に Flatkey で何を確認すべきですか？

Flatkey の最新の SOC 2 レポート、ISO 27001 証明書の詳細、法的主体、署名済み条件、DPA の経路、モデル/プロバイダールート、エンドポイントファミリー、ダッシュボードの証拠項目、ログ保持、ペイロードの取り扱い、サポートデータの取り扱い、フォールバック動作を確認してください。また、本番利用を承認する当日の最新のモデル行と価格単位も確認してください。

最終調達ステップ

SOC 2 AI API gateway を承認する前に、監査人やエンタープライズ購入者が確認するのと同じ方法で証跡パックを作成してください。つまり、主体、レポートの範囲、基準、期間、例外、サブサービス組織、ログ、アクセス制御、ルート変更、データ処理、顧客責任です。Flatkey はモデルアクセス、ルーティング、利用状況の可視性、運用コントロールを一元化できますが、調達用ファイルでは、現在のレポートと、実際に使用する正確なルートを引き続き確認する必要があります。

モデルアクセス、ルーティング、利用状況の可視性、購入者レビュー用の証跡を 1 つの AI API gateway の背後に一元化する準備ができたら、キーを取得する。