階層型のAI申請受付とは、各AI申請を、そのリスクに見合った深さのレビューへ振り分ける運用上の規律です。通常は、セルフサービスから制限対象までの4つの階層で構成されます。ガバナンスの処理量がAI導入のスピードに追いつかなくなった時点で破綻する一律型のレビュープロセスに代わるものであり、エンタープライズ規模で運用されるあらゆるAIガバナンスプログラムの屋台骨となる要素です。

要点

比例性の原則。主要なAI規制フレームワークであるEU AI Act、ISO/IEC 42001、NIST AI RMFは、いずれも同じ運用上の要件に行き着きます。AIシステムに対する精査は、そのシステムがもたらすリスクに比例していなければならない、という要件です。階層型申請受付は、この要件をエンタープライズ規模で運用に落とし込むための仕組みです。

4階層モデル。セルフサービス／簡易レビュー／フルレビュー／制限対象。各階層には、定義されたリスクプロファイル、レビュープロセス、承認者があります。この構造は、EU AI Actの4段階のリスク分類にも、ISO 42001のリスクベースのコントロールにも、無理なく対応します。

継続的な規律としての申請受付。第1階層より上のシステムでは、申請受付が「完了」することはありません。重大な変更に該当する事象、ベンダーによるモデル更新、ユースケースの適用範囲の変更は、いずれも再評価を必要とします。申請受付を一度きりの手続きとして扱うプログラムは、規模が拡大すると破綻します。

申請受付：あらゆるガバナンスプログラムの屋台骨

AIガバナンスプログラムのあらゆる構成要素、つまりAIインベントリ、評価ライブラリ、モニタリングの頻度、規制対応文書、監査証跡は、すべて申請受付に依存しています。申請受付がなければ、プログラムが管理できるのは把握しているものだけであり、把握している内容は四半期も経たないうちに本番環境の実態と乖離します。AI導入の第一波を越えた企業には、一貫したパターンが見られます。破綻が目立つ形で起きることはめったにありません。ガバナンスが、迂回したくなるほど遅くなるのです。

この「遅さゆえの迂回」は、2つの異なる形で現れます。1つ目はボトルネック型の破綻で、すべてのAI申請に単一のレビュートラックを適用し、待ち行列が生じることで起こります。消費財メーカーのマーケティングチームがAIコピーライティングツールを申請すると、数週間に及ぶ適合性評価が正当に必要な候補者ランキングシステムの後ろで待たされます。こうした待ち時間を3度、4度と経験するうちに、事業部門の責任者はプロセスを避けて通るようになります。個人アカウントが使われ、無料の公開AIサービスが業務を肩代わりし、SaaSに組み込まれた機能が届け出のないまま有効化されます。シャドーAIの領域は申請受付の処理能力に反比例して拡大し、インベントリは本番環境の実態ではなく、承認された内容を映すものになっていきます。

シャドーAIの領域は、申請受付の処理能力に反比例して拡大します。

2つ目はギャップ型の破綻です。高リスクシステムが本当に必要とする深さで運用される単一のレビュートラックは、低リスクのツールにとっては過剰な負担になります。すると選択肢は、同じように悪い2つの結果に絞られます。レビューの深さを薄めて規制要件を満たさないものにするか、信用スコアリングモデルに使うのと同じ200問の評価票をマーケティング部門にも記入させ、社内での信頼を失うかです。いずれにしても、プログラムは書類上で見えるほどには機能しません。

階層型申請受付は、この両方に対処します。この原則は、主要なAI規制のすべてで支持されています。EU AI Actの第6条[4]、ISO 42001の箇条6.1.4（同規格の箇条6.1.2および8.2と併せて読むもの）[2]、そしてNIST AI RMFのGovern機能[3]がそれにあたります。また、エンタープライズ規模での運用も十分に可能です。

4階層モデル：精査の深さをリスクに合わせる

図1：4階層のAIガバナンス申請受付モデル。精査の深さはリスクに応じて変わります。成熟したプログラムにおける各階層の比率は、おおよそ第1階層が60〜70%、第2階層が20〜25%、第3階層が5〜15%で、第4階層は少数ながらゼロではありません。

具体的な申請に当てはめると、このモデルは明快に機能します。人事チームが、サードパーティベンダーのAIによる候補者ランキングシステムを申請する場合を考えます。このユースケースはEU AI Actの附属書III[6]（雇用）に該当し、これだけで第3階層が下限となります。このシステムは個人に関する重大な決定（雇用）を行うため、第3階層であることがさらに裏付けられます。扱うデータも機微です（履歴書には個人データが含まれ、特別な種類の個人データが含まれることもあります）。どの観点も同じ結論を示しており、申請は第3階層に振り分けられます。完全な評価、複数のステークホルダーによるレビュー、附属書IV[7]に基づく技術文書、そしてベンダーのモデル更新に連動した再評価トリガーの設定が求められます。

一方、公開済みのマーケティングコピーにのみ使う社内の文章校正ツールと比べてみましょう。個人データなし、重大な決定なし、外部への影響なし。どの観点も第1階層を示します。申請受付は2分で完了する登録フォームだけで、システムは昼までにインベントリに登録されます。例外のフラグが立たない限り、人間のレビュアーが申請に関与することはありません。

第4階層があるからこそ、構造全体の信頼性が保たれます。

明示的な却下の経路がなければ、申請受付はあらゆる申請をいずれは管理可能なものとして暗黙のうちに受け入れてしまい、適用される規制の禁止用途に関する規定がプログラムから見えなくなります。第4階層の案件は、却下を文書化したうえで監査証跡に残すべきです。その記録自体が、規制当局に対してガバナンスの成熟度を示すエビデンスになります。

押さえておくべき境界事例。複数の階層にまたがるシステムもあります。ユースケースが大きく拡大した第2階層のシステム（たとえば、返金の判断まで担うようになったカスタマーサポート用チャットボット）は再評価を行い、第3階層へ移すこともあり得ます。逆に、2年間にわたり十分な人による監視のもとで運用され、リスクプロファイルの安定が実証されている第3階層のシステムは、継続的なモニタリングを条件に第2階層へ移す候補となり得ます。階層の変更は、既定の流れではなく、文書化された判断であるべきです。問うべきは、入手可能なエビデンスに照らして、規制当局が新しい分類を受け入れるかどうかです。

エージェンティックシステム：このモデルが対応すべき転換点

4階層モデル自体は新しいものではありません。新しいのは、第3階層のシステムが現れるペースです。その主な要因はエージェンティックAI、つまり人間がレビューする出力を生成するだけでなく、自律的に行動する権限を与えられたシステムです。エージェンティックシステムの申請受付は3つの点で構造的に異なり、4階層モデルはそれを吸収しなければなりません。

第一に、自律性という観点があるため、基盤となるユースケースにかかわらず第3階層が既定となります。社内の経費に関する問い合わせに対応するエージェンティックAIは、ユースケースの機微性だけを見れば第2階層に見えます。しかし、実際に経費を申請したり、精算の支払いを予約したりする権限を与えた時点で、第3階層に入ります。リスクプロファイルを決めるのは「どのような判断か」ではなく、「どのような行動か」です。

第二に、エージェンティックシステムの申請受付では、権限の境界を明示的に把握する必要があります。第3階層のエージェンティックシステムの申請受付では、エージェントが呼び出せるツール、人の確認なしに実行できる行動、引き継ぎを発生させるエスカレーション条件、そして確認と確認の間の挙動を対象とするモニタリングを定めるべきです。いずれも、静的なAIシステムで機能していた質問票の構成には当てはまりません。エージェンティックシステムの申請フォームには通常30〜40%多くの項目が必要であり、その焦点はデータの取り扱いではなく、行動の範囲に置かれます。

第三に、重大な変更の捉え方が異なります。静的なAIシステムでは、モデルの更新が主な再評価トリガーです。エージェンティックシステムでは、アクションの許可リストの拡大（新しいAPIの呼び出し、新しい基幹記録システムへの書き込み、新しいカテゴリーでの送金をエージェントに許可すること）が重大な変更にあたり、当初の評価の範囲を完全に超える場合があります。しかも、その変化はモデル自体には現れないことがあります。第3階層のエージェンティックシステムの申請受付プロセスでは、導入時にアクションの許可リストを明示的に登録し、許可リストが変更されるたびに申請受付を再度実施することを求めるべきです。

エージェンティックシステムで問うべきは、「どのような判断か」ではなく「どのような行動か」です。

システムを一貫して分類する：7つの評価軸

階層の割り当ては、どのレビュアーが申請を担当するかにかかわらず、同じリスクプロファイルに対して同じ答えを出さなければなりません。設計の不十分な分類プロセスでは判断にばらつきが生じます。適切に設計されたプロセスは、すべての申請に一貫した評価軸を適用し、ルールに基づいて一意に振り分けます。適切に設計された申請フォームは、以下の評価軸にわたって5〜8問を尋ね、その回答に基づいて一意に振り分けます。手動での上書きは本当の境界事例のために用意しますが、手動での分類を標準にすると判断にばらつきが生じます。

特に規制対象の金融サービス企業にとって、モデルリスク管理の評価軸は、階層の下限を決める入力以上の意味を持ちます。並行するライフサイクル（モデルの検証、継続的なモニタリング、定期的な再認証）を発生させるため、申請受付はそれを再実行するのではなく、既存のMRM部門に引き継ぐべきです。MRMの対象となるAIシステムの申請受付記録は、MRMのワークフローを重複させるのではなく、対応するMRM IDを参照するようにします。

評価軸どうしが矛盾する場合。評価軸はたいてい同じ方向を指しますが、そうでない場合もあります。製造工場の予兆保全システムは、扱う個人データがごくわずかで、個人に関する重大な決定を行わず、完全に可逆であるかもしれません。それでも、附属書Iの製品（機械類）の一部を構成し、そのAIの組み込みがEU AI Act第6条第1項のもとで高リスクとなる場合があります[4]。この場合、他の評価軸が何を示していても、ユースケースの区分だけで第3階層となります。ルールは、いずれか1つの評価軸が示す最も高い階層を採用し、その理由を文書化することです。

EU AI Act第6条第3項の例外。同法は、附属書IIIのシステムが純粋に手続き的もしくは準備的なタスクを実行する場合、または以前に完了した人間の活動の結果を、最終判断に影響を与えることなく改善する場合には、提供者が自ら高リスクではないと判断することを認めています。この例外の範囲は狭く限定されています[13]。人間のレビュアーのために履歴書を標準的なレイアウトに整形するAIツールは、該当する可能性があります。一方、同じ履歴書を予測される適合度で順位付けするAIツールは、最終的な採用判断を人間が行うとしても該当しません。その順位付けは、規制当局が重要とみなす形で判断に影響を与えるからです。第6条第3項の例外の誤用は、それ自体が規制上のリスクとなります。分類プロセスでは、第6条第3項に基づく判断を振り分けの便宜としてではなく、正当化を要する文書化された所見として扱うべきです。

第50条の透明性義務と、独立した評価軸とすべき理由。EU AI Act第50条[15]は、人と対話するAIシステム、合成コンテンツを生成するAIシステム、ディープフェイクを作成するAIシステムに対して、基盤となるユースケースや業種にかかわらず開示義務を課しています。第2階層のカスタマーサポート用チャットボットは、明示的な開示がなければ顧客が人間のオペレーターと区別できない時点で、第50条の対象になります。申請フォームでは、第50条のトリガーを直接確認すべきです。この評価軸の確認が遅れ、それを想定していない附属書IIIの適合性評価の中で初めて検討することになると、監査で表面化するエビデンスの欠落が生じます。2026年8月2日以降、これは対象システムの提供者および導入者にとって厳格な義務となり、申請受付の決定記録に明示されるべきものです。

銀行がサードパーティのカスタマーサポート用チャットボットを調達するケースは、評価軸どうしの相互作用をよく示しています。ベンダーは、出力が会話形式であり、エスカレーションには人間のオペレーターが対応するため、このシステムを「限定的リスク」として販売しています。銀行の申請受付プロセスは、各評価軸を次のように適用します。ユースケースの区分（顧客接点あり、附属書IIIによる下限なし）、データの機微性（会話記録に口座情報が含まれる可能性があり、階層を引き上げる）、決定の影響（情報提供のみで、影響による引き上げなし）、可逆性（回答は撤回可能で、引き上げなし）、自律性のレベル（メッセージごとの人によるレビューなしで応答し、エージェンティックに近い方向で階層を引き上げる）、透明性のトリガー（第50条が適用され、チャットボットであることの開示が必要）、業種別のトリガー（金融サービスの文脈であり、さらに引き上げる）、MRMのトリガー（ベンダーのチャットボットについて、SR 11-7やSS1/23のもとで直接管理される基盤モデルはなく、参考情報のみ）、調達形態（サードパーティからの調達であり、いずれにしても新たな申請受付が必要）。このシステムは第2階層の上位に位置づけられ、データの機微性の評価次第では第3階層となる可能性もあります。

ベンダーによる「限定的リスク」という位置づけは関係ありません。基準となるのは、導入する組織自身の分類です。

この種の申請受付を取り巻く、より広いベンダーリスク管理の考え方については、サードパーティAIベンダーのリスク評価ガイドをご覧ください。

5ステップのワークフローを階層ごとに調整する

申請受付プロセスは、階層にかかわらず、共通する5つのステップで構成されます。各ステップでどれだけのプロセスを行うかは、階層によって決まります。

5ステップのAIガバナンス申請受付ワークフローを示す図：ステップ1 ユースケースの特定、ステップ2 インベントリの確認、ステップ3 リスク評価、ステップ4 レビュー、ステップ5 決定。この流れはどの階層でも共通で、各ステップの深さは階層の分類に応じて変わります。

5つのステップの流れは階層をまたいで共通であり、階層に応じて変わるのは各ステップでのプロセスの深さです。第1階層の申請は5つのステップすべてを20分で終えることもありますが、第3階層の申請では評価だけで通常4〜6週間かかり、さらにレビューと承認のサイクルに2週間を要します。役割は階層ごとに割り当てるべきです。第1階層では申請者が指名された責任者となり、システムは自動的にインベントリに登録されます。第2階層では、法務またはリスク部門の指名された承認者が決定を担い、申請者は継続的な運用について引き続き責任を負います。第3階層では、複数のステークホルダーによるレビュー委員会が決定権限を持ち、任命された独立レビュアーが技術文書のレビューを担当し、事業責任者が実際の利用について引き続き責任を負います。

重大な変更は、ステップ3を再び呼び戻すトリガーです。EU AI Act第3条第23号は、重大な変更を、市場に投入された後のAIシステムに対する変更のうち、その適合性または意図された目的に影響を及ぼすものと定義しています[14]。同様の考え方はISO 42001（AIマネジメントシステムにおいて重大な変更を再評価のトリガーとして扱う）やNIST AI RMF（重要な変更をリスクの再マッピングのトリガーとして扱う）にも見られます。実際の例としては、ベンダーが基盤モデルのバージョンを更新してツールの挙動が変わる、エージェンティックシステムのアクション許可リストに新しいAPIが追加される、カスタマーサポート用チャットボットの役割が返金の判断にまで広がる、ファインチューニングしたモデルの学習データが新しいソースで更新される、といったものがあります。いずれも重大な変更の候補であり、申請受付は適切な階層の深さで再度実施すべきです。それは形式的な手続きのためではなく、以前のリスク評価がもはや妥当でない可能性があるからです。

2025年に第3階層のレビューを経てAI診断支援ツールを導入した医療機関を例に考えます。当初の評価は、特定のデータセットで学習した特定のモデルバージョンを前提としていました。2026年4月、ベンダーが新しい学習データと改良された推論パイプラインを取り入れたモデルバージョンの更新を発表します。重大な変更に関するルールのもとでは、この医療機関の申請受付プロセスを再度実施すべきです。1年前の評価は、更新されたモデルの新しい挙動を網羅していない可能性があるからです。再評価の結果、変更は不要と結論づけられることもありますが、それは沈黙ではなく、文書化された判断でなければなりません。

手作業から自動化へ：プラットフォームの判断を迫る転換点

ユースケース1件あたり4時間から1時間未満へ。チームも規制の水準も同じまま、6か月で。

これは、メールベースのフォームやGoogleフォームで構築した手作業の申請受付プロセスを、自動化された階層型ワークフローに置き換えたある消費財メーカーでの、実際の運用結果です。処理時間の変化は目に見える指標ですが、より重要なのは構造的な変化です。移行前は、リスクプロファイルにかかわらず、リスクチームがすべてのAI申請のボトルネックになっていました。移行後は、低リスクの申請が高リスクの申請と注意を奪い合うことがなくなり、複数のステークホルダーによるレビュー委員会は本当に必要なシステムに時間を使えるようになりました。監査証跡も、事後の調査作業としてではなく、最初から規制当局に提出できる状態になりました。

階層型の申請受付プロセスは、手作業でも運用できます。ほとんどのプログラムは、メールベースのフォーム、共有スプレッドシート、定例のレビュー会議といった形で始まります。このやり方は、最初の十数件から二十数件ほどのAI申請までは通用します。

一定の件数を超えると、自動化への移行は選択肢ではなく必然になります。症状は予測できます。手作業による分類が、レビュアーごとにばらつきます。同じシステムでも、担当者によって異なる階層が割り当てられます。メールのスレッドに残る監査証跡が分散します。チームメンバー、プロジェクトのチャンネル、共有ドライブに散らばり、規制当局に求められた際に提出できる唯一の信頼できる情報源がありません。再評価のトリガーが見落とされます。大規模に追跡する担当者がいないためです。本来は自動化すべき第1階層の申請が、第3階層と同じ待ち行列に並びます。振り分けのロジックが特定の誰かの頭の中にしかなく、その人が休暇中だからです。

必要不可欠になる機能は、特別なものではありません。複数のチームが安全に編集できる一元化されたインベントリ、申請フォームの回答に基づくルールベースの階層分類、適切なレビュアーへの申請の振り分け、規制要件に沿った文書の生成、そして組織変更があっても失われない監査証跡です。

手作業か自動化かの選択は、AI導入の拡大に伴い、組織がどれだけのガバナンス負担を抱えるかの選択です。階層型のプロセスは転換点を先送りしますが、なくすことはできません。早期に自動化へ移行する組織は、転換点を迎える前に、プラットフォームへの投資をAI導入を拡大するための構造的な前提条件と位置づけます。一方、拡大がすでに破綻してから動く組織は、妥協を強いられる状況でプラットフォームの判断を迫られることになります。

申請受付は、より広いGRCスタックのどこに位置づけられるか

申請受付が機能するのは、組織がすでに運用している既存のGRCプロセス（ベンダーリスク、調達、セキュリティレビュー、プライバシー評価）の入口となる場合であり、それらと競合する並行トラックとしてではありません。既存のレビュー機能と並行して動く新しい申請受付プロセスは、作業の重複と、互いに食い違う複数の正式記録を生み出し、そのどちらもプログラムにとって不利に働きます。

申請受付のアウトプットは、調達、法務、セキュリティ、プライバシーの各部門が、それぞれの義務のために参照できる単一の記録であるべきです。

• ベンダーリスク部門は、申請受付の記録を参照して、AI利用に関する契約条項（変更通知の期間、監査権、モデルカードの開示義務）を検討します

• 調達部門は、この記録を参照して、契約の構造がシステムのリスク分類と想定用途に合致していることを確認します。実務で最も難しいのは調達への引き継ぎです。既存のTPRMプラットフォーム（OneTrust、ServiceNow Vendor Risk Management、ProcessUnity）が契約テンプレートの継承を担っているため、AI固有の条項ライブラリは並行して管理するのではなく、そのワークフローに組み込む必要があります。

• セキュリティ部門は、システムのアクセス制御への影響、必要となるデータフロー、適用される脅威モデルを確認するためにこの記録を参照します

• プライバシー部門は、システムに必要なDPIA（データ保護影響評価）またはLIA（正当な利益の評価）、データ主体の権利への影響、国境を越えるデータ移転に関する考慮事項を確認するためにこの記録を参照します

2つのガバナンスシステムを運用するコストは、少しずつ増えるものではなく、構造的なものです。

申請受付の記録は、これらすべての上流に位置する入力です。つまり実務では、すでに導入されているGRCスタックとの明確な連携ポイントを備えた申請受付の仕組みを構築または選定することになります。2つのシステムの正式記録が時間とともに食い違うにつれて、コストは膨らみ続けます。

銀行がサードパーティAIベンダーを受け入れる際の申請受付プロセスを例に、その具体的な姿を見てみましょう。申請受付は、下流のアクションを自動的に発生させます。ベンダーリスク部門は申請受付の記録を受け取り、AI固有の項目を加えた標準的なサードパーティ評価を適用します。法務部門は、変更通知の期間と監査権に関する条項について契約をレビューします。セキュリティ部門はデータフローの仕様を受け取り、脅威モデルを適用します。プライバシー部門は、申請受付時に把握したデータ分類に基づいてDPIAを完了します。どのチームも同じ情報を再度求めることはなく、それぞれが申請受付の記録から情報を取り出します。ベンダーにとっても、重複する質問を投げかける4つの並行プロセスではなく、一貫した1つの要件として見えます。

階層型申請受付が失敗するパターン（とその解決策）

階層型申請受付の失敗には、7つの典型的なパターンがあります。最初の5つは最初の18か月以内に表面化し、残りの2つは2年目から3年目にかけて表面化して、初期の失敗を乗り越えたプログラムを静かに機能不全に追い込みます。いずれにも、定例のガバナンスレビューで現れる診断シグナルと、根本原因に対処する構造的な解決策があります。

初期段階で最も多い失敗の診断の詳細。申請受付を一度きりの手続きとして扱うことは、多くの企業が最初に陥る失敗パターンであり、累積コストが最も大きいものでもあります。そのシグナルは次のとおりです。四半期ごとのインベントリレビューで、前回の評価以降に大きく変化したシステムが3〜4件見つかります。ベンダーがモデルを更新した、ユースケースが拡大した、新しいデータソースが統合された、といった変化があったにもかかわらず、申請受付のプロセスが再度実施されていません。12か月目には、インベントリのリスク分類は実態を伴わないものになり、18か月目には、監査証跡は導入済みシステムの実際の動作を正確に表さなくなります。解決策は構造的なものです。第1階層より上のすべてのシステムに、再評価の頻度（通常、第2階層は年1回、第3階層は半年に1回）と、頻度にかかわらず早期の再評価を求めるトリガー事象のリストを定めます。どちらも後から追加するのではなく、当初の申請受付の決定の一部として記録すべきです。

2年目の2つの失敗が、初期の失敗よりも重要である理由。経営陣の支援の喪失と、追認機関と化したレビュー委員会は、成熟したプログラムを機能不全に陥らせる失敗パターンです。どちらも通常の運用レビューでは見えません。どちらも、重大なインシデントが起き、システムを承認した時点でのガバナンス体制が説明可能だったことをプログラムが示さなければならなくなって、初めて表面化します。構造的な解決策（定量化された取締役会レベルのエクスポージャー指標、独立レビュアーの交代制、反対意見の文書化）は、文化ではなく運用の問題です。必要になる前にプログラムに組み込んでおかなければなりません。失敗の後に後付けで導入することこそ、規制当局が形だけのガバナンスの証拠とみなすものだからです。

上記の失敗パターンのシグナルを支える、より広いインベントリ管理の考え方については、AIシステムインベントリの構築ガイドをご覧ください。

目指すべき姿：1年目のベンチマーク

以下の指標は、階層型申請受付プログラムが最初の12〜18か月で到達する実務上のプロファイルと、多くのプログラムが3年目までに到達する成熟度のプロファイルを示しています。主な目標範囲は、Enzaiの顧客プログラム全体で観察された推移に基づいています[16]。個々のプログラムは、開始時点の成熟度、業種、申請受付の自動化レベルによって異なります。これらのベンチマークは、成果を保証するものではなく、機能しているプログラムのプロファイルを示すものです。12か月目の時点で1年目の数値を大きく下回っているプログラムは、多くの場合、上記の構造的な解決策のいずれかが欠けています。

第4階層の申請が1件もないプログラムは、本来捕捉すべき案件を捕捉できていない可能性が高いでしょう。逆に、すべての申請が第3階層になるプログラムは分類をやめてしまっており、業務のスピードを犠牲にして防御的な過大分類を行っています。どちらの状態も、分類ロジックの見直しが必要であることを示しています。

比例性の原則を実践する

階層型申請受付は、主要なAI規制がいまや例外なく組み込んでいる比例性の原則を、運用の形で表したものです。4階層モデルがその構造を与え、8つの分類評価軸が振り分けのロジックを提供し、5ステップのワークフローが階層ごとに調整される流れとなり、ベンチマークが診断の手段となります。

階層型申請受付は、書類上のガバナンスでは得られない可視性をもたらします。機能する階層型プロセスがあれば、AIフットプリントが拡大しても、プログラムは最も重要な部分を見失いません。捕捉すべき案件は申請受付の段階で捕捉され、迅速に進めるべき案件は不要な摩擦なく進み、副産物として生まれる監査証跡は、規制当局が準備なしにレビューできるものになります。

陥りがちな落とし穴として規制当局が最も頻繁に目にするのは、規律の代わりに文書で済ませることです。詳細な評価があっても第4階層が空のプログラムは、ガバナンスプログラムではなく、書類作成プログラムにすぎません。比例性の原則が機能するのは、比例的なレビューと並んで、比例的な却下が運用上の規律の一部になっているときだけです。

上位の階層で階層型申請受付と隣接する、より広いエージェンティックAIのコントロールについては、「エージェンティックAIガバナンス決定版ガイド」をご覧ください。

よくある質問

AIガバナンスにおける階層型申請受付とは何ですか？

階層型申請受付とは、各AI申請を、そのリスクに見合った深さのレビューへ振り分ける運用上の規律です。多くの企業プログラムは、セルフサービス、簡易レビュー、フルレビュー、制限対象の4つの階層に落ち着きます。各階層には、それぞれ固有の分類プロセス、承認者、文書化の深さ、再評価の頻度があります。このモデルは、ガバナンスの処理量がAI導入のスピードに追いつかなくなった時点で破綻する、一律型のレビュー手法に代わるものです。

エンタープライズのAIガバナンスプログラムには、いくつの階層が必要ですか？

ほとんどの企業にとって、実務上の上限は4つです。管理するAIシステムが数百件未満のプログラムでは、多くの場合3つで運用できます（簡易レビューとフルレビューを統合し、統合後の階層でより詳細な質問票を使います）。5つや6つの階層は過剰設計の兆候です。階層を1つ増やすごとに、隣接する階層の境界で振り分けの曖昧さが生じ、リスクの網羅性に見合う効果がないまま、レビュー主体間の調整コストが増えます。

自動的に第3階層に入るべきAIシステムはどれですか？

EU AI Actの附属書IIIに該当するシステム、個人に関する重大な決定（雇用、信用、保険、住宅、医療、司法、必要不可欠なサービス）を行うシステム、業種固有の高リスク規制のトリガーに該当するシステム、そして基盤となるユースケースにかかわらず自律的な行動が可能なエージェンティックシステムです。ルールは、いずれか1つの分類評価軸が示す最も高い階層を採用し、その理由を文書化することです。

階層型申請受付では、エージェンティックAIをどのように扱いますか？

運用の自律性はユースケースにかかわらずリスクプロファイルを引き上げるため、エージェンティックシステムは第3階層が既定となります。エージェンティックシステムの申請受付では、アクションの許可リスト、人への引き継ぎを発生させるエスカレーション条件、引き継ぎと引き継ぎの間の挙動を対象とするモニタリングを明示的に把握すべきです。許可リストの拡大は重大な変更のトリガーであり、それだけで申請受付が再び必要になります。

承認済みのAIシステムの再評価は、何をきっかけに行いますか？

重大な変更です。EU AI Act第3条第23号では、市場投入後のAIシステムに対する変更のうち、その適合性または意図された目的に影響を及ぼすものと定義されています。実際のトリガーには、ベンダーのモデル更新、エージェンティックシステムのアクション許可リストの拡大、ユースケースの適用範囲の変更、ファインチューニングしたモデルの学習データの更新、利用者数や展開地域の大幅な拡大などがあります。第2階層のシステムは通常、年1回に加えてトリガー発生時に、第3階層のシステムは通常、半年に1回に加えてトリガー発生時に再評価します。

階層型申請受付プロセスを一から構築するには、どのくらいの期間がかかりますか？

最初の申請群を手作業で運用できるようになるまでに3〜6か月、1年目のベンチマーク目標に沿って運用できるようになるまでに9〜15か月、3年目の成熟度プロファイルに到達するまでに18〜24か月かかります。一定の件数を超えると、手作業から自動化への移行は選択肢ではなく必然になります。新しい申請が届くペースにもよりますが、通常は管理対象のAIシステムが50〜200件の間でその時点を迎えます。

階層型申請受付は、ベンダーリスクや調達といった既存のGRCプロセスに取って代わるものですか？

いいえ。既存のプロセスの上流に位置します。申請受付の記録は、ベンダーリスク、調達、セキュリティ、プライバシーの各部門が、それぞれの義務のために参照する唯一の信頼できる情報源であり、どのチームも同じ質問を繰り返す必要はありません。最も多い失敗パターンは、申請受付を既存のGRCと並行するトラックとして運用することです。正しいモデルは、申請受付を入口とし、下流で利用される単一の記録を作成することです。

Enzaiは、ServiceNowやOneTrustのようなプラットフォームとどのような関係にありますか？

Enzaiは、ServiceNow、OneTrust、ProcessUnityなどのエンタープライズGRCスタックの上流に位置し、それらと連携するAI固有のガバナンスレイヤーとして機能します。Enzaiで作成された申請受付の記録は、これらのプラットフォームがすでに運用している下流のワークフローに引き渡されます。AI固有の評価の深さと規制フレームワークの網羅性はEnzaiが担います。ほとんどのお客様は、既存のGRC基盤を置き換えるのではなく、Enzaiを併用しています。

Enzaiの位置づけ

このガイドでは、運用上の規律について説明しました。Enzaiは、それを実現するプラットフォームを提供しています。4階層モデル、評価軸に基づく分類、5ステップのワークフロー、統合された監査証跡のすべてを、プロセスではなくインフラとして運用します。転換点に差しかかっており、自社のプログラムがこのガイドのベンチマークに照らしてどの位置にあるかを検討したい場合は、お問い合わせください。実際のユースケースを1件、このモデルに当てはめて検証します。

ガイド全文を読む：「AIガバナンス必携ガイド：ポリシーから実践へ」では、階層型申請受付に加えて、ポリシー策定、コンプライアンス・フレームワーク、インベントリ管理、評価の設計、継続的なモニタリングを取り上げています。ガイドをダウンロードしてください。

Enzaiは、抽象的なポリシーから運用レベルの監督への移行を支援するために専用設計された、業界をリードするエンタープライズAIガバナンスプラットフォームです。EnzaiのAIリスク管理プラットフォームは、エージェンティックAIのガバナンス、包括的なAIインベントリの維持、EU AI Actへの準拠に必要な専用インフラを提供します。複雑なワークフローを自動化することで、ISO 42001やNISTなどのグローバル標準との整合性を保ちながら、企業が自信を持ってAI導入を拡大できるよう支援します。

参考文献

1. 人工知能に関する調和規則を定める欧州議会および理事会規則（EU）2024/1689（人工知能法）。欧州連合官報、2024年7月。eur-lex.europa.eu/eli/reg/2024/1689/oj

2. ISO/IEC 42001:2023「Information technology - Artificial intelligence - Management system」。国際標準化機構（ISO）、2023年12月。iso.org/standard/81230.html

3. NIST「人工知能リスク管理フレームワーク（AI RMF 1.0）」、NIST AI 100-1。米国国立標準技術研究所、2023年1月。nist.gov/itl/ai-risk-management-framework

4. 規則（EU）2024/1689 第6条：高リスクAIシステムの分類規則。

5. 規則（EU）2024/1689 第5条：禁止されるAI行為。

6. 規則（EU）2024/1689 附属書III：第6条第2項に規定する高リスクAIシステム。

7. 規則（EU）2024/1689 附属書IV：第11条第1項に規定する技術文書。

8. コロラド州SB 24-205「人工知能に関する消費者保護について」、2024年5月署名。leg.colorado.gov/bills/sb24-205

9. イングランド銀行健全性規制機構（PRA）、監督声明SS1/23「銀行のためのモデルリスク管理原則」、2023年5月。bankofengland.co.uk

10. 米国連邦準備制度理事会、SRレター11-7「モデルリスク管理に関する監督指針」、2011年4月。federalreserve.gov

11. ニューヨーク市地方法2021年第144号「自動雇用決定ツール」。nyc.gov/site/dca/about/automated-employment-decision-tools.page

12. カリフォルニア州プライバシー保護庁「自動意思決定技術（ADMT）に関する規則案」。cppa.ca.gov/regulations/

13. 規則（EU）2024/1689 第6条第3項：重大なリスクをもたらさない附属書IIIのシステムに関する例外。

14. 規則（EU）2024/1689 第3条第23号：重大な変更の定義。

15. 規則（EU）2024/1689 第50条：特定のAIシステムの提供者および導入者の透明性義務。

16. 本セクションにおける1年目の捕捉率、階層の分布、決定までの時間の目標値は、階層型申請受付を12か月以上運用してきたエンタープライズのAIガバナンスプログラム全体にわたる、Enzaiの総合的な観察結果を反映したものです。個々のプログラムの推移は、開始時点の成熟度、業種、申請受付の自動化レベルによって異なります。記載の数値は、成果を保証するものではなく、機能しているプログラムのプロファイルを示すものです。