AIモデル承認ワークフローは、モデルルートが本番トラフィックを処理することを許可されるかどうかを決定するリリースゲートです。ルートとは、単なるモデル名ではありません。それは、製品機能の背後で実行されるプロバイダー、エンドポイントファミリー、プロンプトバージョン、ツール権限、フォールバック動作、ロギング設定、コストガードレール、所有者、そしてロールバックパスです。
そのため、新しいルートが本番稼働する前に承認が行われるべきです。モデルはデモでは安全に見えても、間違ったプロンプトバージョンが出荷されたり、フォールバックが未レビューのプロバイダーにトラフィックを送信したり、ツールコールが過大な権限を持ったり、ロギング設定がペイロードを想定より長く保存したり、あるいはロールアウト後に財務部門が支出を照合できなかったりすることで、本番環境で失敗する可能性があります。
このAIモデル承認ワークフローを使用して、モデルの変更を購入者所有のエビデンスファイルに変換します。そのアウトプットは、エンジニアリング、セキュリティ、調達、財務、製品の各部門が後で同じ質問に答えられるほど明確であるべきです。すなわち、何が承認されたのか、なぜ承認されたのか、どのエビデンスがレビューされたのか、そして何が再レビューのトリガーとなるのか、という質問です。
Flatkeyの購入者にとって、このレビューはゲートウェイルートを中心に行われます。Flatkeyの現在の公開サイトでは、製品はモデルアクセス、ルーティング、請求、使用状況分析、運用管理のための単一のAI APIゲートウェイとして位置づけられており、1つのAPIキー、1つのベースURL、1つのダッシュボードで提供されます。これにより、ゲートウェイはルートのエビデンスを一元化するのに便利な場所となります。しかし、本番稼働前にアカウント固有のロギング、プロバイダーの利用規約、モデルの動作、データ処理、承認責任を検証する必要性がなくなるわけではありません。
ワークフローが承認するもの
AIモデル承認ワークフローは、ベンダーのスローガンではなく、ルートを承認すべきです。承認記録には、リリース後に存在する正確な本番環境での動作を特定する必要があります。
| ルートの側面 | 承認に関する質問 | 保持すべきエビデンス | リリースブロッカー |
|---|---|---|---|
| ユースケース | このルートはどのユーザーまたはシステムのタスクを実行しますか？ | 製品概要、データ分類、ユーザーへの影響、不正使用ケース | タスクが曖昧であるか、所有者が不明確である |
| モデルとプロバイダー | どのモデル、プロバイダー、エンドポイント、リージョン、アカウントパスがトラフィックを処理しますか？ | プロバイダーのドキュメント、モデル/バージョンのステータス、ルート設定、フォールバックリスト | フォールバックによって未承認のモデルが選択される可能性がある |
| プロンプトとツールポリシー | どの指示、ツール、スキーマ、権限が許可されていますか？ | プロンプトバージョン、ツールマニフェスト、型付きスキーマ、コードレビュー | ツールが制御なしに不可逆的なアクションを実行できる |
| 評価パック | どのテストが、このルートがこのユースケースに十分であることを証明しますか？ | 評価データセット、メトリクス、しきい値、レビュー担当者のメモ、失敗例 | タスク固有の合否しきい値がない |
| 安全性と不正使用対策 | プロンプトインジェクション、安全でない出力、データ漏洩、ポリシーバイパスはどのように処理されますか？ | レッドチーム演習のケース、フィルター設定、拒否テスト、監視アラート | 既知の障害に緩和策や所有者がいない |
| データとロギング | どのプロンプト、出力、メタデータ、トレース、請求行が保存されますか？ | データフローマップ、ログサンプル、保持クラス、リダクションテスト | 生のペイロードストレージが不明確または無制限である |
| コストとキャパシティ | どの程度の支出、クォータ、レート制限、タイムアウト、フォールバック動作が許可されていますか？ | 予算制限、使用サンプル、ストレステスト、財務担当者 | 障害モードが制御不能な支出を生み出す可能性がある |
| ロールアウトとロールバック | トラフィックはどのように開始、拡大、一時停止、復帰しますか？ | 機能フラグ、カナリア計画、ロールバックコマンド、インシデント連絡先 | ロールバックが手動の推測に依存している |
| 更新トリガー | どのような変更が再承認を必要としますか？ | レビュー日、モデルの非推奨監視、ルート変更ポリシー | ローンチ後のドリフトに誰も責任を負わない |
重要な点：承認は会議ではありません。承認とは、エビデンスパッケージとルート制御のことです。
一度きりのチェックリストではなく、ライフサイクルフレームを使用する
NISTのAIリスク管理フレームワークは、作業を「統治（Govern）」「マッピング（Map）」「測定（Measure）」「管理（Manage）」を中心に構成するため、実用的なフレームです。これはAIモデル承認ワークフローにきれいに対応します。
| AI RMF機能 | ルート承認への置き換え |
|---|---|
| 統治（Govern） | ルート所有者、リスク所有者、財務所有者、セキュリティレビュー担当者、承認ポリシー、および廃止ルールを割り当てる |
| マッピング（Map） | ユースケース、ユーザー、データ、上流プロバイダー、モデルの制限、ルートの依存関係、およびビジネスへの影響を記述する |
| 測定（Measure） | 機能評価、敵対的テスト、安全性チェック、コストテスト、レイテンシーテスト、および可観測性チェックを実行する |
| 管理（Manage） | エビデンスに基づいてルートを承認、ロールアウト、監視、一時停止、更新、または廃止する |
NISTの生成AIプロファイルも重要です。なぜなら、生成システムは、通常のAPI変更レビューでは見逃されがちなリスク（プロンプトインジェクション、ハルシネーション、データ漏洩、安全でない能力拡張、モデルドリフト、下流での誤用など）をもたらすからです。このフレームワークは、意思決定を構造化する方法として扱い、独自のエビデンスの代わりになるものとして扱わないでください。
AIモデル承認ワークフローのチェックリスト
このチェックリストは、すべての新しいモデルルート、重要なプロンプトの変更、ツール権限の変更、プロバイダーのフォールバック、またはエンドポイントの移行に使用してください。
- ルートを定義する。
ルートID、所有者、製品機能、環境、エンドポイントファミリー、プライマリモデル、許可されるフォールバックモデル、プロバイダーアカウント、プロンプトバージョン、ツールマニフェスト、データクラス、および予想されるトラフィックパターンを記録します。
- ユースケースを分類する。
ルートが顧客データ、従業員データ、規制対象のワークフロー、財務上の意思決定、サポートの意思決定、法的レビュー、コード実行、外部アクション、または安全性に配慮が必要なコンテンツに触れるかどうかを判断します。要約ルートと自律的な返金エージェントは、同じ承認の深さを共有すべきではありません。
- モデルとプロバイダーの証拠を収集する。
プロバイダーのモデルドキュメント、利用可能な場合はモデルカードまたはシステムカード、非推奨ステータス、コンテンツフィルタリングのドキュメント、データ処理条件、地域的制約、アカウントレベルの設定を保管します。Googleのモデルバージョンのガイダンスは、モデルが安定版、プレビュー、実験的、非推奨、または廃止のいずれであるかを把握するためのリマインダーです。分かりやすい表示名だけを承認しないでください。
- プロンプトとツールをバージョン管理する。
OpenAIのプロンプトガイダンスでは、コードで管理された本番プロンプト、型指定された入力、コードレビュー、テスト、評価チェック、段階的なロールアウトが推奨されています。これは、購入者所有のAIモデル承認ワークフローにとって正しいパターンです。プロンプトの動作は、コードの動作と同じリリースプロセスに属します。
- タスク固有の評価を構築する。
OpenAIの評価のベストプラクティスでは、評価を可変的なAIシステムにおける正確性、パフォーマンス、信頼性のための構造化されたテストとして位置づけています。承認には、一般的なベンチマークのスクリーンショットだけでなく、タスク固有の評価パックが必要です。典型的なケース、エッジケース、敵対的なケース、多言語のケース、ツールのケース、既知の失敗例を含めてください。
- セキュリティと不正使用のテストを実行する。
OWASPのLLM01プロンプトインジェクションガイダンスでは、直接的および間接的なプロンプトインジェクションを区別しています。両方のテストを追加してください。ルートがツールを呼び出し、ドキュメントを取得し、レコードを書き込み、メッセージを送信し、またはコードを実行できる場合は、過剰な権限、ツール引数の操作、システムプロンプトの競合、取得したコンテンツ内の隠された指示についてテストします。
- データ保持とロギングを検証する。
プロンプト、出力、ツール引数、ファイル、取得されたチャンク、トレース、リクエストメタデータ、監査イベント、請求行が保存されるかどうかを決定します。AI APIデータ保持チェックリストを使用してペイロードコンテンツをメタデータから分離し、AI API使用状況の監査ログを使用して誰がキー、ルート、ロギング、クォータ、モデルポリシーを変更したかを証明します。
- コスト、信頼性、フォールバックの制限を設定する。
トークン予算、リクエスト予算、クォータ制限、タイムアウト戦略、リトライポリシー、フォールバックモデルリスト、サーキットブレーカー、アラートしきい値を記録します。ユーザーエクスペリエンスが良好に見えても、トラフィックをより強力で、より高価で、またはレビューの少ないモデルに静かに移行させるフォールバックは、ガバナンスの失敗です。
- 段階的なロールアウトと更新を承認する。
カナリアリリース、機能フラグ、ルートの重み付け、またはテナントの許可リストを通じてリリースします。最初の1時間のチェック、初日のチェック、最初の1週間のチェック、および更新トリガーを定義します。モデルのバージョン、プロバイダーの規約、プロンプトの動作、ツールの権限、ロギング、コストプロファイル、またはユーザー層が変更された場合に再承認します。
承認パケットを構築する
最も強力なAIモデル承認ワークフローは、コンパクトな承認パケットを残します。これは、レビューできるほど短く、かつ監査できるほど具体的であるべきです。
| パケットフィールド | 必須の回答 | 証明アーティファクト | 更新トリガー |
|---|---|---|---|
| ルートID | この本番ルートの安定したID | ゲートウェイルート設定または変更リクエスト | ルートの名称変更、マージ、または分割 |
| ビジネスオーナー | 誰が製品リスクを受け入れるか？ | 承認記録 | オーナーの変更 |
| テクニカルオーナー | 誰が一時停止またはロールバックできるか？ | オンコールドキュメント、ランブック | チームまたはオンコールの変更 |
| データクラス | プロンプト、ツール、ファイル、検索に入力できるデータは何か？ | データフローマップ、サンプルペイロードクラス | 新しいデータソースまたは顧客セグメント |
| モデルリスト | プライマリモデル、フォールバックモデル、エンドポイントファミリー、プロバイダーアカウント | モデル/バージョンドキュメント、ルートリードバック | 新しいモデル、フォールバック、エンドポイント、またはプロバイダー |
| プロンプトバージョン | 現在のプロンプトビルダー、スキーマ、およびシステム指示ソース | Gitコミットまたはレビュー済み設定 | プロンプト、スキーマ、またはツールの変更 |
| 評価パック | データセット、メトリクス、しきい値、失敗、レビュー担当者の承認 | 評価レポート | モデル、プロンプト、データ、またはユーザー分布の変更 |
| 安全管理 | コンテンツフィルター、拒否ポリシー、プロンプトインジェクションテスト、人間によるエスカレーション | テストレポートとフィルター設定 | フィルター、ポリシー、またはリスク分類の変更 |
| ツール管理 | 許可されたツール、スコープ、引数、承認要件 | ツールマニフェストと権限テスト | ツールの権限または副作用の変更 |
| ログと保持 | メタデータフィールド、ペイロードポリシー、保持クラス、墨塗り動作 | ログサンプルと保持リードバック | エクスポート、可観測性、または保持の変更 |
| コスト管理 | 予算、クォータ、レート制限、アラート、請求書オーナー | 使用サンプルとコストしきい値 | 価格設定、トラフィック、またはモデルミックスの変更 |
| ロールアウト計画 | カナリアサイズ、ロールバック方法、停止条件 | 機能フラグまたはルートウェイト記録 | ロールアウトコホートの拡大 |
| 本番稼働後のモニタリング | メトリクス、アラート、レビュー頻度、インシデントパス | ダッシュボードのスクリーンショットまたはAPIリードバック | アラートの見逃し、インシデント、またはドリフト |
このパケットは調達資産でもあります。これにより、ベンダーのレビューが具体的になります。ベンダーが「エンタープライズ対応」であるかどうかを尋ねる代わりに、購入者はこのルートが準備できていることを証明する証拠は何かを尋ねます。
ルートが本番稼働する前の本番前テスト
テストセットは、承認されたユースケースと一致する必要があります。サポートチケットにラベルを付けるだけのルートは、SQLを記述したり、返金を行ったり、コードを編集したり、医療記録を要約したりするルートとは異なるテストを必要とします。
| テストレーン | テスト対象 | 保持する証拠 | 停止条件 |
|---|---|---|---|
| 機能の正当性 | 通常のタスクでの期待される出力 | 評価スコア、失敗例、レビュー担当者のメモ | 合格率がしきい値を下回る |
| 指示階層 | システムプロンプトと競合するユーザープロンプト | 敵対的なケース | ユーザープロンプトがシステムポリシーを上書きする |
| プロンプトインジェクション | ユーザーテキスト、取得したドキュメント、ファイル、ツール出力への直接的および間接的なインジェクション | レッドチームのトランスクリプト | 隠された指示がタスクを変更する |
| ツールの権限 | ツールの選択、引数の抽出、スコープ、および副作用 | ツール呼び出しログと拒否ケース | ツールが未承認のアクションを実行できる |
| データ漏洩 | シークレット、個人データ、顧客識別子、および取得したコンテキストの漏洩 | フィクスチャテスト | 機密性の高いフィクスチャが出力またはログに表示される |
| コンテンツフィルタリング | 入出力ポリシーのカテゴリと重大度のしきい値 | フィルター設定とブロックされたケース | 必須のカテゴリが監視またはブロックされていない |
| コストとクォータ | トークン予算、レート制限、フォールバック支出、不正利用のバースト | 使用量行とアラートテスト | オーナーのアラートなしで支出が増加する可能性がある |
| 信頼性 | タイムアウト、リトライ、ストリーミング、フォールバック、プロバイダーの停止、サーキットブレーカー | 障害訓練 | ユーザートラフィックが失敗に対してリトライを続ける |
| 監査可能性 | キーの変更、ルートの変更、プロンプトの変更、ログアクセス、クォータの変更 | 監査イベントのサンプル | 変更をアクターと時間に結び付けられない |
| ロールバック | ルートの無効化、プロンプトの差し戻し、フォールバックの削除、以前のモデルの復元 | ロールバック訓練 | ロールバックを迅速に完了できない |
MicrosoftのAzure OpenAIコンテンツフィルタリングのドキュメントは、フィルターにはカテゴリ、重大度、設定の選択肢、およびオプションの動作があることを思い出させてくれるのに役立ちます。承認記録には、スタックのどこかに安全機能が存在することだけでなく、ルートに使用される実際の設定をキャプチャする必要があります。
ルートポリシーの例
承認により、エンジニアが実装でき、レビュー担当者が検査できるルートポリシーが作成されるべきです。正確なスキーマはゲートウェイによって異なりますが、その形状は明示的である必要があります。
route_id: support-summary-prod
owner:
product: support_ops
engineering: ai_platform
security: appsec
finance: finops
use_case:
task: summarize_support_threads
data_class: customer_support_confidential
allowed_environments: [production]
models:
primary: approved_summary_model_2026_07
fallbacks:
- approved_summary_backup_2026_07
denied:
- any_preview_model_without_reapproval
prompt:
source: app/prompts/support_summary.ts
reviewed_commit: 8f3c2d1
schema_required: true
tools:
allowed:
- read_ticket_metadata
denied:
- refund_customer
- send_email
logging:
payload_storage: disabled
metadata_retention_class: ops_metadata_90d
audit_events:
- route_change
- model_change
- prompt_change
- key_rotation
controls:
max_input_tokens: 8000
max_output_tokens: 700
monthly_budget_usd: 500
fallback_requires_same_data_policy: true
evals:
pack: support_summary_eval_2026_07
min_pass_rate: 0.95
required_tests:
- prompt_injection
- sensitive_data_fixture
- tool_scope
rollout:
canary_percent: 5
expand_after_hours: 24
rollback: disable_route_weight
renewal:
review_by: 2026-10-04
triggers:
- model_version_change
- prompt_change
- new_tool
- logging_change
- provider_terms_changeここでAIモデル承認ワークフローが機能します。ルート設定が決定を表現できない場合、承認は抽象的すぎます。
Flatkeyとの連携方法
Flatkeyは、公開されている製品の機能が、統一されたモデルアクセス、ルーティング、請求、使用状況分析、クォータ制限、およびキーとルーティングのための一元化されたダッシュボードを中心に構成されているため、このワークフローの運用基盤として機能します。現在のホームページには、https://router.flatkey.ai/v1/chat/completionsを使用したOpenAI互換のリクエストパターンも表示されており、価格設定とモデルのページでは、前払い残高、使用状況分析、モデルの価格設定、プロバイダーのカバレッジについて説明しています。
Flatkeyをゲートウェイの証拠収集基盤として使用し、承認前にこれらのアカウント固有の詳細を確認します。
- どのモデルとプロバイダーがルートで有効になっているか。
- 各ルートがどのエンドポイントファミリーを使用しているか。
- どのフォールバックモデルが許可され、拒否されているか。
- どのAPIキー、チーム、プロジェクト、環境がルートを呼び出せるか。
- 購入者アカウントで利用できる使用量、コスト、クォータの管理機能は何か。
- どのリクエストメタデータ、監査イベント、請求記録が可視化されているか。
- 生のプロンプト、出力、ツール引数、ファイル、またはトレースが保存されているかどうか。
- ルートの変更、キーの変更、クォータの変更、ロギングの変更がレビュー可能な証拠を生成するかどうか。
これを一般的な信頼性の主張に変えないでください。ゲートウェイはプロバイダーの乱立を減らし、証拠を一元化できますが、AIモデルの承認ワークフローの所有権は依然として購入者にあります。
調達時に尋ねるべき質問
調達およびセキュリティチームは、プラットフォームの概要だけでなく、ルートに合致した証拠を求めるべきです。
| 質問 | 良い証拠 | 不十分な証拠 |
|---|---|---|
| このルートにはどのモデルが使用されますか？ | プライマリモデルとフォールバックモデルを含むルートの読み返し | 「クラス最高のモデルを使用しています」 |
| モデルが失敗した場合はどうなりますか？ | タイムアウト、リトライ、フォールバック、ロールバックのポリシー | 「ゲートウェイが処理します」 |
| どのデータがログに記録されますか？ | サンプルメタデータイベントとペイロードポリシー | 「ログはあります」 |
| 誰がルートを変更できますか？ | ロールリストと監査イベントのサンプル | 「管理者が管理できます」 |
| どの評価に合格しましたか？ | データセット、しきい値、失敗例、レビュー担当者のメモ | 「テストでは機能しました」 |
| どのような安全管理が有効ですか？ | フィルター設定、拒否テスト、プロンプトインジェクションのケース | 「安全性は有効になっています」 |
| 財務部門は何をレビューしますか？ | 使用状況の行、価格設定のスナップショット、予算アラート、請求書パス | 「ダッシュボードがあります」 |
| 何が再承認を必要としますか？ | 文書化されたトリガーリストと所有者 | 「必要に応じてレビューします」 |
このレビューを、ゲートウェイレベルの管理についてはエンタープライズAI APIゲートウェイチェックリスト、上流プロバイダーの境界についてはAI APIベンダーリスク評価、永続的な変更の証拠についてはAI API使用状況の監査ログと関連付けてください。
更新と廃止
承認における最大の失敗は、ドリフト（乖離）です。7月に承認されたルートが、10月に実行されているルートと同じであるとは限りません。
本番稼働前に更新のトリガーを設定します。
- モデルのバージョンが非推奨、廃止、プレビューのみ、または置き換えられた場合。
- プロバイダーがデータ処理、コンテンツフィルタリング、価格設定、リージョン、または機能サポートを変更した場合。
- フォールバックモデル、ルートの重み付け、エンドポイントファミリー、またはプロバイダーアカウントが変更された場合。
- プロンプト、スキーマ、検索ソース、システム指示、またはツール権限が変更された場合。
- 新しいユーザーグループ、顧客層、地域、またはデータクラスがルートの使用を開始した場合。
- 監視アラートが品質、安全性、遅延、コスト、または不正使用のドリフトを示した場合。
- インシデント、サポートエスカレーション、顧客からの苦情、または調達上の指摘がルートに関連した場合。
廃止も同じAIモデル承認ワークフローの一部であるべきです。ルートが廃止される際には、代替ルート、トラフィックの移行完了日、無効化されたキー、削除されたシークレット、保持されるログ、請求の締め処理、および最終的な所有者の承認を記録します。
よくある質問
AIモデル承認ワークフローとは何ですか？
AIモデル承認ワークフローは、モデルルートが本番トラフィックを処理できるかどうかを決定するガバナンスプロセスです。ユースケース、モデル/プロバイダーパス、プロンプトとツールポリシー、評価結果、安全管理、ロギング動作、コストガードレール、ロールアウト計画、更新トリガーを記録します。
新しいAIモデルルートは誰が承認すべきか？
最低でも、承認にはプロダクトオーナー、技術オーナー、セキュリティまたはリスクレビュー担当者、財務または運用オーナーが含まれるべきです。リスクの高いルートでは、法務、調達、プライバシー、サポート、または経営陣によるレビューも必要になる場合があります。
承認にはモデルカードだけで十分か？
いいえ。モデルカードやシステムカードは有用な証拠ですが、プロンプト、ツール、フォールバック、ロギング、データフロー、コスト管理、ロールアウトの動作がユースケースにとって安全であることを証明するものではありません。ルートには依然として独自の承認パッケージが必要です。
モデル承認はどのくらいの頻度で見直すべきか？
レビューの頻度はリスクによって異なりますが、すべてのルートには更新トリガーが必要です。モデルのバージョン、プロバイダー、プロンプト、ツールの権限、ロギング、データクラス、フォールバック、コストプロファイル、またはユーザー集団が変更された場合は、再承認してください。
AIゲートウェイはモデル承認にどのように役立つか？
AIゲートウェイは、モデルアクセス、ルートポリシー、キー、使用状況、コスト、クォータ、監査証跡を一元管理できます。これは購入者のガバナンスを置き換えるものではありません。ゲートウェイを制御と証拠のサーフェスとして使用し、アカウント固有の動作を検証します。
結論
AIモデル承認ワークフローは、本番モデルの変更がインシデントになる前にレビューできるようにすべきです。曖昧なモデル名ではなく、ルートを承認してください。証拠ファイルをゲートウェイの近くに保管し、タスク固有の評価を要求し、プロンプトインジェクションとツールの権限をテストし、ロギングとコスト管理を検証し、最初のリクエストが本番稼働する前に更新トリガーを設定してください。モデルアクセス、ルーティング、使用状況、請求を1つのゲートウェイの背後で一元化する準備ができたら、Flatkeyの現在の価格とモデルカタログを確認し、キーを取得してください。
