階層型AIインテークとは、各AI申請について、そのリスクに比例した深度の審査（通常はセルフサービスから制限付きまでの4つの階層）を適用してルーティングする体系的な運用管理手法です。ガバナンス処理能力が導入の加速スピードを支えきれなくなった時点で破綻してしまう、従来の単一ルートの審査プロセスに代わるものであり、エンタープライズ規模で運用されるあらゆるAIガバナンスプログラムを支える重要な基盤要素となります。

主な要点

比例性の原則： EU AI法、ISO/IEC 42001、NIST AI RMFなど、主要なAI規制フレームワークはすべて同じ運用要件に収束しています。すなわち、AIシステムに適用される精査は、それがもたらすリスクに比例しなければならないということです。階層型インテークは、この要件をエンタープライズ規模で実運用へと落とし込むための方法です。

4階層モデル： 「セルフサービス」、「簡易審査」、「詳細審査」、「制限付き」の4つに分類されます。各階層には定義されたリスクプロファイル、審査プロセス、および承認者が存在します。この構造は、EU AI法の4段階のリスク分類や、ISO 42001のリスクベースの管理手段に極めて明確に対応しています。

継続的な管理手法としてのインテーク： 階層1を超えるシステムにおいては、インテークが一度のプロセスで「完了」することはありません。重大な変更に伴うトリガー、ベンダーによるモデルのアップデート、ユースケースの適用範囲の変更が発生するたびに、再評価を強制的に行う必要があります。インテークを単発のイベントとして扱うプログラムは、規模が拡大した段階で破綻します。

インテーク：あらゆるガバナンスプログラムを支える重要基盤

AIガバナンスプログラムのすべての構成要素（AIインベントリ、アセスメントライブラリ、モニタリングの実施、規制関連ドキュメント、監査トレール）は、インテークの上に成り立っています。これがなければ、プログラムは実態を把握しているシステムしか管理できず、その把握している内容は四半期もしないうちに実環境（本番環境）の動向と乖離することになります。これは、第一波のAI導入を乗り越えた企業間で共通して見られるパターンです。その失敗の兆候は、多くの場合、目に見える形では現れません。ガバナンスプロセスの遅延が、回避（シャドー化）を招く原因となります。

この回避を招く遅延パターンは、2つの明確な形となって現れます。1つ目は「ボトルネック」の発生です。これは、すべてのAI申請に対して単一の審査プロセスが適用され、滞留が発生する場合に生じます。例えば、AI文章生成ツールの導入を申請する消費財メーカーのマーケティングチームが、数週間に及ぶ適合性評価を正当に必要とする採用候補者選別システムの審査の後ろで待たされることになります。ビジネスの現場責任者がこのような遅延を3、4回経験すると、次第に正規のプロセスを迂回するようになります。個人アカウントが使用され、無料の公開AIサービスに業務が流れ、開示のないままSaaSの組み込みAI機能が有効化されます。インテークの処理能力に反比例するようにしてシャドーAIの領域が拡大し、インベントリは本番環境の実態ではなく、単に「承認されたシステム一覧」を反映するものへと形骸化していきます。

シャドーAIの領域は、インテークの処理能力に反比例して拡大します。

2つ目は「ギャップ」による破綻です。ハイリスクなシステムが真に必要とする深度に合わせた単一の審査プロセスは、低リスクなツールにとっては過剰な負荷となります。この場合、選択肢は極めて好ましくない2つの結末へと狭まります。すなわち、審査の深度を妥協して規制要件を満たせない形骸化したものにするか、あるいは与信審査モデルと同じ200問のアセスメントへの回答をマーケティングチームにも要求することでプログラムの社内的な信頼性を失うか、のどちらかです。いずれにしても、そのガバナンスプログラムは書面上の見栄えほど機能しなくなります。

階層型インテークは、これら両方の課題を解決します。この原則は、EU AI法の第6条、同規格の細則「6.1.2」および「8.2」とあわせて読まれるべきISO 42001の「6.1.4」、さらにはNIST AI RMFの「Govern（統治）」機能など、主要なAI規制体制のすべてにおいて支持されています。また、これはエンタープライズ規模において実運用可能な手法です。

4階層モデル：リスクに応じた精査の適用

図1：4階層のAIガバナンス・インテークモデル。リスクに応じて精査の規模が拡大します。成熟したプログラムにおける各階層の割合目安は、概ね階層1が60〜70%、階層2が20〜25%、階層3が5〜15%、そして階層4は極めてわずか（ただしゼロではない）となります。

具体的な申請事例に沿って考えると、このモデルの仕組みが明確になります。人事チームが外部ベンダーからAI搭載の採用候補者スクリーニングツールを導入しようとするケースを想定します。このユースケースは、EU AI法の附属書III（雇用）に該当するため、最低でも階層3（詳細審査）に分類されます。さらに、このシステムは個人に関する重大な意思決定（雇用）を行うため、これによっても階層3であることが裏付けられます。また、扱うデータは機微情報（履歴書には個人データ、場合によっては特別カテゴリデータが含まれます）に該当し、これも決定的な要因となります。各評価軸が統合的に評価され、この申請は階層3にルーティングされます。ここでは、詳細なリスク評価、複数関係者による審査、附属書IVに基づく技術文書の作成、そしてベンダー側のモデルアップデートをトリガーとする再評価設定が必要となります。

これを、公開済みのマーケティング用コピーの校正にのみ使用される社内向けの文章校正ツールと比較してみます。個人データは扱わず、重大な意思決定も伴わず、外部への影響も一切ありません。すべての評価軸が階層1（セルフサービス）を指し示します。インテークは2分で完了する登録フォームのみで完結し、お昼時にはインベントリに登録されます。例外としてフラグが立てられない限り、レビュー担当者（人間）が申請に介入することはありません。

「階層4」という断固として拒否・制限する仕組みがあるからこそ、全体のモデルに対する信頼性が担保されます。

明確な却下ルートが存在しない場合、インテークはすべての申請を「いずれはガバナンス対応可能である」と暗黙的に受け入れることになり、結果として適用される法的規制における禁止事項に関する規定がプログラムから形骸化してしまいます。監査トレールには、明確な却下理由が文書化された階層4の記録が不可欠であり、その記録自体が規制当局に対して、企業のガバナンスプログラムが機能し、成熟していることを示す強力な証拠となります。

考慮すべき境界線のケース： 一部のシステムは、複数の階層をまたぐような判定が難しい状況にあります。例えば、利用目的が実質的に拡大した階層2のシステム（顧客からの問い合わせに対応するチャットボットから、返金の可否を自律的に決定する権限を持つまでに稼働範囲が拡大した場合など）は再評価が必要となり、階層3へ移行すべきです。逆に、十分な人間の監視のもとで2年間安定して運用され、リスクプロファイルが明らかに低い水準で安定している階層3のシステムは、継続的な監視を条件に階層2への移行（プロモーション）を検討することができます。こうした階層の変更は、自動的な判定ではなく、変更理由を文書化した決定でなければなりません。ここで問いかけるべきは、「提示可能な証拠に基づき、新しい分類が規制当局に認められるかどうか」です。

エージェント型AIシステムこそ、このモデルが対応しなければならない転換点です

4階層モデルという枠組み自体は新しいものではありません。極めて革新的なのは、階層3に該当するシステムが急速に増加している点です。その主な要因は、人間による審査を経ずに自律的に処理を実行する権利が与えられたシステム群、すなわちエージェント型AIの台頭にあります。エージェント型システムに対するインテークは、4階層モデルにおいて対応すべき、構造的な3つの相違点があります。

1つ目は、ユースケースの内容にかかわらず、その「自律性」自体の影響で初期値が階層3（詳細審査）に引き上げられる点です。社内の経費申請に関する問い合わせに対応するだけであれば、ユースケースとしては階層2に分類されます。しかし、そのエージェントに経費の実際の申請や払い戻しの決済を実行する権限が与えられた瞬間、それは階層3の領域に突入します。ここでは「どのような判断を下すか」ではなく、「どのような権限に基づき自律的にアクションを実行するか」が最大のリスクプロファイルとなります。

2つ目は、エージェント型システムのインテークにおいては、その「権限の範囲」を明示的に規定しなければならない点です。階層3エージェントの申請では、エージェントが呼び出し可能なツール、人間の確認なしに実行可能な自律アクション、人間へのエスカレーション判定基準、および実行間の挙動を監視するモニタリング手段が設定されている必要があります。これらは、従来の静的なAIシステムを前提としたアンケート構造には落とし込めません。そのため、エージェント型AIの申請フォームでは、データの取り扱いではなく、その「行動および権限の範囲」に特化した設問が通常30〜40%ほど多く必要となります。

3つ目は、「重大な変更」の基準が異なる点です。従来の静的なAIシステムにおいては、ベンダーから提供されるモデルのアップデートが主な再評価トリガーとなります。しかし、エージェント型システムにおいては、実行を許可されたアクション（ホワイトリスト）の拡大（例：新しいAPIの呼び出しを許可する、新たな記録システムへの書き込み権限を与える、特定の経費決済を承認する権限を与えるなど）が重大な変更イベントに該当します。これは当初の評価範囲を大幅に超える可能性があり、なおかつ「AIモデル自体の変更」としては把握できません。階層3のエージェント型システムのインテークにおいては、本番稼働時に許可リスト（アクションのホワイトリスト）の明示的な登録を義務付け、変更が発生した際にはインテークを再起動するプロセスが必要不可欠です。

エージェント型システムにおいて、極めて重要な問いは「どのような判断を下すか」ではなく「どのようなアクションを実行させるか」です。

ブレのない一貫したシステム分類：7つの評価軸

階層への振り分けは、どの審査担当者が申請を処理したとしても、同じリスクプロファイルに対しては常に同一の判定となる必要があります。不適切に設計された分類プロセスは、判断にブレ（ドリフト）を生じさせます。適切に設計されたプロセスでは、すべての申請に対して一貫した一連の「評価軸」を適用し、機械的に判定を導きます。適切に設計されたインテークフォームは、以下に示すいくつかの評価軸に基づき、5〜8個の設問を提示して機械的にルーティングを行います。例外なケースにのみ手動での上書きルールが存在すべきであり、分類判定の初期設定を手動にすると、判断に大きなブレが生じる原因となります。

特に規制対象となる金融サービス企業において、このモデルリスク管理（MRM）という評価軸は、単なる階層の判定材料にとどまりません。これはモデルのバリデーション、継続的な監視、および定期的な再認定といったパラレルで稼働するライフサイクル全体を起動させます。インテーク機能は、これを既存のMRM側へ円滑に受け渡し・引き継ぐべきであり、インテーク側でMRMのワークフローを重複して実行してはなりません。MRMの対象となるAIシステムに関しては、インテーク記録はMRMのワークフローそのものを重複して追うのではなく、対応する既存のMRM管理IDを参照する形に留めるのが適切な設計です。

評価軸が衝突した場合： 各評価軸は通常同様の方向性を指し示しますが、時には判断が分かれることもあります。例えば、ある製造工場に導入する設備メンテナンス予測AIシステムについて考えます。個人データは扱わず、個人に関する重大な意思決定もしないため、一見すると影響は小さく取り消しも容易に思えます。しかし、本システムがEU AI法第6条(1)に基づきハイリスクと見なされる「安全性が損なわれると重大な危険を招く機械製品（附属書I対象）」に統合されている場合、ユースケースのカテゴリによってこれだけで強制的に階層3に規定されます。他の評価軸がどのような数値を指し示していても、このカテゴリの影響を受けます。この場合の鉄則は、複数の評価軸の中で最も高い階層を示した判定を適用し、その理由を文書化することです。

第6条(3)における例外規定： EU AI法では、システムが単に手作業の事務処理や限定的な準備タスクのみを実行する場合、あるいは人間によって完結された業務の質を向上させるだけであり、最終的な意思決定に直接的な影響を及ぼさない場合に限り、附属書IIIのシステムであっても規制対象の「ハイリスク」に該当しないと供給者自身で判断（自己決定）することを認めています。しかし、この例外規定の窓口は非常に狭く設定されています。例えば、履歴書を人間が読みやすいように標準フォーマットに変換するだけのAIは例外に該当する可能性があります。一方で、予測される適性度に基づいて履歴書に優先順位（ランキング）をつけるAIは、最終的な合否を人間が下す場合であっても例外には該当しません。このソーティングは、規制当局が「重大な影響を及ぼす行為」と見なす方法でプロセスに介入しているためです。この例外規定（6条3項）を拡大解釈して悪用することは、それ自体が重大な規制リスク（法令違反のリスク）を内包しています。そのため、インテークの設計にあたっては、この例外規定の適用（当てはめ）を単なるルーティング上の逃げ道にするのではなく、実態に即した証拠に基づく適正な事実認定が必要なものとして処理しなければなりません。

第50条の透明性およびその重要性： EU AI法の第50条は、ユースケースや属する業界部門にかかわらず、人間と対話するAI、人工的な合成コンテンツの生成、またはディープフェイク等を作成・処理するAIシステムに対して開示義務を課しています。階層2に分類される一般的なカスタマーサポート向けチャットボットであっても、ユーザーに対して適切な事前開示（AIであることを示す明示等）が不足し、顧客がそれを人間のサポート対応と区別できなくなった瞬間、第50条の不適合に該当します。製品インテークフォームには、第50条の要件のトリガー判定項目を必ず直接組み込んでおく必要があります。附属書IIIベースの一般的な適合評価プロセスを稼働させた先の極めて遅い段階になってこの要件に気がついた場合、プロセスにおいて必要な証拠資料の抜け漏れが生じる致命的な事態を招きます。2026年8月2日以降、これは対象システムを運用するユーザー（導入企業）と開発ベンダー（供給者）の双方にとって法的義務化となるため、製品のインテーク承認時にその判定が明確に記録されている状態にしておく必要があります。

とある銀行が、カスタマーサポートを自動化するためにサードパーティ製の対話AIチャットボットを調達する事例をもとに、各評価軸がどのように作用し合うのかを見てみましょう。その外部ベンダーは、「このシステムは会話形式の処理のみを行い、エスカレーションはオペレーター（人間）が担当するため、リスクは極めて限定的である」とアピールして製品を販売しています。しかし、銀行が自社の規定に基づいてインテーク評価軸を適用したところ、以下のような状況となります。まず、ユースケースカテゴリ（これは附属書IIIの対象外ですが顧客対応チャットとして登録）、データの機微度（会話ログに口座番号などの顧客情報が含まれる可能性があるため、これによってリスク評価および階層が引き上げられます）、意思決定等の影響度（情報提供のみのため影響度は引き上げなし）、不可逆性（返答の取り消し・訂正ができるため引き上げなし）、自律性レベル（人間を介さず個々のメッセージに対してリアルタイムで返信するため、エージェント型システムに近いリスク評価として階層を引き上げ）、透明性要件（第50条が適用されるためAIを使用していることの開示が必要）、業界規制（金融機関としての規制環境により、さらに階層が引き上げられます）、MRMのトリガー（ベンダーのチャットボットに対してSR 11-7等の規定が直接適用されるモデルではないため該当なし）、製品の提供経路（自社開発ではなくサードパーティ調達のため新規のインテーク適用が必要）。以上の結果、この製品は階層2の最上レンジ、あるいはデータの取り扱いやコンテキストに関するアセスメントの内容によっては階層3に分類されます。

ベンダーが製品説明等で多用する「限定的なリスク」といった主観的な表現は評価において考慮されません。あくまで、製品を導入する組織自身が自社の評価軸に基づいて行う客観的な分類プロセスの結果が優先されます。

この種のインテークに関連するベンダー管理手法の詳細については、弊社作成の「サードパーティ製AIベンダーのリスクアセスメントガイド」をご参照ください。

5つのステップで構成される、階層に応じたワークフロー

各AIの申請・審査プロセスは、どの階層に分類されたとしても、共通する以下の5つの定義に沿って進行します。選択された階層に応じて、各ステップで処理すべき事項の範囲（タスクの規模および審査の深度）が決定されます。

AIガバナンスにおける5つのインテーク・ワークフローのステップを示す図：「ステップ1：ユースケースの特定」、「ステップ2：既存インベントリとの整合確認」、「ステップ3：アセスメントの実行」、「ステップ4：審査レビュー」、「ステップ5：最終決定」。この5段階の基本構成はすべての階層で共通ですが、各段階で行われるプロセスの審査深度は決定された階層分類に応じて自動的にスケール（増減）します。

この5つの基本構成自体はどの階層でも変わりませんが、各ステップで実行すべきタスクの深度が階層に応じて適切にスケーリングされます。たとえば、階層1のシステム申請であれば、これらすべての項目が数十分以内で完了します。一方で、階層3に該当する申請では、アセスメント（評価ドキュメントの整備）だけで通常4〜6週間を要し、その後の関係者による審査および承認までに、さらに2週間が必要となります。また、関係者のロール（役割定義）も階層に応じて変化します。階層1では、申請者が対象製品の「オーナー」となり、社内インベントリへの追加が自動化されます。階層2では、法務やリスク担当の指定された承認者が最終承認の判断を下し、申請者は日々の責任者として稼働します。階層3では、部門を横断した審査委員会が正式な承認決定を下し、割り当てられた専門の審査担当者が技術要件の確認報告書を作成し、ビジネスオーナーは継続的な運用の監査責任を負います。

一度承認されたシステムをアセスメントの第3のステップに差し戻すきっかけとなるのが、システムに変更が加えられる「重大な変更」の発生です。EU AI法の第3条(23)では、市場に流通した製品、あるいは本番で稼働しているAIシステムに施される改修のうち、規制への準拠性や当初アセスメントされた対象システム自体の「開発目的・意図されていた用途」に影響を与えるシステム仕様への変更を「重大な変更」と定義しています。この種の変更が発生した場合、ISO 42001（マネジメントプロセスにおける再評価トリガーとして規定される仕様変更）や、NIST AI RMF（リスクの再定義・再マッピングが必要とされる重要な仕様変更）にも同様の規定が組み込まれています。具体的な例を挙げると、ベンダーから提供されるモデルコアプログラムの更新（バージョンアップ）、エージェント型システムに対する新たな接続APIの追加（ホワイトリストの変更）、チャットボットに対して決済や返金処理の自律権限を与えるなどの挙動の大幅な拡張、ファインチューニングされた学習データに対する新規コーパスの追加などがあります。これらはいずれも再評価を必要とする変更イベントに該当し、再審査のためのインテークプロセスを適正な審査深度で再起動させ、過去に記録したリスクアセスメントの適用評価を適格に上書きする必要があります。

たとえば、とある医療サービスプロバイダーが、特定のAI学習バージョンに基づく病名推測用の医療支援AIを、詳細な審査（階層3）を経たうえで2025年に本番インフラへ導入したケースを考えます。その後、2026年4月に、開発元ベンダーから「推論精度が洗練された新たなモデルバージョンとなり、これに合わせて学習データの性質がアップデートされたプログラムバリアントを提供する」との通知を受けました。この状況下では、「重大な変更」に関する規定に基づいてインテーク機能が速やかに再評価プロセスをトリガーしなければなりません。なぜなら、1年以上前の過去の審査履歴では、新しい学習データが反映された最新モデル製品のアウトプットの安全性や、新たなバイアス特性等を的確に担保できない可能性があるためです。この再評価の結果、これまでの評価に実質的な変更の必要なしと結論づけられることもありますが、これは沈黙のうちに自動的にバージョン更新されるのではなく、正式な意志決定プロセスとしてその評価理由が文書化されていなければなりません。

手動から自動へ：プラットフォームの移行を促す運用の限界値

AIシステム一件あたりに生じる審査時間：4時間超から1時間に短縮。法規制における適合水準も担保したまま、半年間で達成。

これは、それまでメールやGoogleフォームに頼った手工業的な運用を続けていたとある大手グローバル消費財企業が、インテーク全体の自動化システムおよび階層型ワークフローを導入したことによって実現した驚異的な成果です。審査にかかる対応時間の劇的な短縮は、目に見えるわかりやすい改善成果（メトリクス）の一つですが、本当に変革をもたらす本質的なメリットは「ガバナンスプロセスの構造自体の大きな変化」にあります。自動化プラットフォーム導入前は、リスクチームは申請されるすべてのAI申請の処理にあたりボトルネックになっていました。導入後は、リスクが明らかに少ないセルフサービスツールが専門チームの確認リソースを圧迫することは一切なくなり、部門を横断した審査委員会、法務、およびセキュリティ担当といった専門家集団は、真に精密な精査と判断を必要とする一部の高度な高リスクシステムのみに時間を集中して割くことができるようになりました。これにより、監査トレール全体の整合性が担保された高品質なログがシステム上で常時担保され、当局からの規制要求等に対しても事後的な追跡をせずに対応を完了できるようになります。

この階層型インテーク手法を、メール配信やスプレッドシート（手動）等だけで運用し始めることは、ガバナンスプロセスが始動した極めて初期の段階、たとえば対象のAIシステムが1〜2ダース（約20件）程度の少量である状況であれば実運用可能です。

しかし、管理対象のアプリケーション数が一定の限界点（トリガーボリューム）を超えた瞬間から、手動でのプログラム運用を組織上で破綻なく継続することは不徳となり、自動化されたプラットフォーム専用ソリューションへの投資は避けられなくなります。ガバナンス崩壊の兆候は、多くの場合以下のように予測可能です。まず、審査担当者ごとの判断基準にブレが発生します。 同じシステムであるにもかかわらず、審査にあたる個別の担当者の知見等に起因して、適用される階層評価の結果が毎回異なってしまいます。また、メールスレッドなどの監査証跡がチーム全体で断片化します。 プロジェクトの個別チャット履歴や個人ファイル置き場などにログが散逸し、規制当局の調査が入った際に「これまでの意思決定プロセスの正当性を客観的に示せる唯一の真実（シングルソースオブトゥルース）」を迅速に構築できなくなります。さらに、変更管理の再評価トリガーが見落とされます。 数百から数千にスケールする本番稼働中のサービス状態を追跡できなくなり、ベンダー側の更新を機に知らないまま評価内容に乖離が生じます。そして、本来判定が自動化されているべきはずの階層1の単純な申請が、階層3と同じ待ち行列に滞留します。 ルーティングの自動化システムが存在しないため、判定が特定ガバナンス担当者の属人的知識（脳内）のみに依存して維持され、その担当者が一週間休暇を取得しただけで、日常の調達ワークフロー全体が硬直することになります。

これからの企業のAIガバナンスの運用において極めて重要な役割を果たす製品の要件は、それほど奇抜なものではありません。すなわち、複数関係者が同一のインベントリに対して不適切なデータ更新を起こさせずに、安全に履歴の参照・更新ができる一元化された管理コンソール、インテークフォームの入力内容から一貫した判断ロジックで動作するルーティングの仕組み、適切なステップを踏むタスク自動引き渡し（チケットフロー）、監査要件に対応する書類や必要データの自動生成、そして組織や担当者が変わっても破綻しない一連の監査トレール一元管理システムです。

システムを手動で運用するか、あるいは初期の段階から自動化プラットフォームに投資するかという選択は、実質的に「組織全体のAIを活用したイノベーションの成長過程において、どれだけ過酷なオーバーヘッド（プロセス遅延）を許容できるか」を決める選択に他なりません。階層化を導入すれば運用プロセスの崩壊という限界点の到来を一時的に遅らせることはできますが、最終的な解決にはなりません。先進的なガバナンスを展開する組織は、運用の限界点が発生してプロセスが停止し社内の信頼性が破綻する前の極めて早期の段階で自動化インフラ（エチケット管理など）への投資を完了することで、イノベーション推進と適正な規制適合のバランスを高度に両立しています。

企業の既存GRCスタックにおける、インテークの適切な位置づけ

インテーク機能は、既存の調達管理、セキュリティ監査、プライバシー評価（DPIAなど）、ベンダー調達などのGRC関連の既存システムに対して、「競合する新たな独立の並行管理トラックとして存在するのではなく、常にそれらすべての総合的な玄関口（エントランス）」として機能している必要があります。既存の部門審査システム等と別個の階層で、重複したデータを別に入力させる形で新しい管理ツールやタスクを追加した場合、企業の業務プロセス（タスク重複、データの多重管理、判定結果のズレ、リソース制限の圧迫）はすぐに限界に達し、その結果その運用自体が現場の反対にあって廃止に追い込まれます。

理想的なインテーク製品は、インテークに1度入力・作成したデータレコード自体が、調達管理部門、法務評価部門、セキュリティ監査部門、およびその他のガバナンスシステムにおいて、それぞれの立場から必要な情報として常時一元的かつ整合性を持って参照可能なデータハブとなる必要があります。

• ベンダーの評価・統制評価： インテーク登録された変更要件に基づき、ベンダーのAIシステム選定時に設定すべき適切な契約義務事項（システムアップデート時の事前開示期間の合意、透明性提供義務、モデル定義データの開示要求等の監査条件指定）を適用・確認するために利用します。

• 調達・購買プロセス： AIシステムとして設定されているリスク分類や使用目的に合致した適切な契約構成になっているか確認することができます。調達における引き継ぎ設計は最も難所のひとつであり、従来の契約管理（OneTrust、ServiceNow、ProcessUnity等）との間において、契約条項データベースの同期などの統合的ワークフローを構築する必要があります。

• セキュリティ評価： インテーク登録されたシステムから生じるアクセス権限、要求データ経路、システム保護要件を考慮し、適正なセキュリティモデルや防御方式の要件策定に利用します。

• プライバシー評価： インベントリに定義された扱われるデータの性質に応じて、必要なプライバシー影響評価（DPIA）や、データ主体の権利保護施策、GDPR等の国外におけるデータ保管要件、暗号化基準を策定するために利用します。

複数の独立した重複したガバナンス手法を社内に強制するコストは、非常に大きなプロセス効率の損失として跳ね返ってきます。

システムを並行で二本走らせ、情報の同期処理などを欠いた運用を行った場合、月日が経つにつれてスプレッドシートや記録間で情報の不一致が発生し、全体像を見失う重大な破綻（サイロ化）が生じます。

とある銀行が、ベンダー調達プロセスにおいてこれらを適切に行っている運用のイメージは、次のようなものです。まず、プロダクトのインテークに製品情報が入力されると、これが自動的に下流に同期されます。ベンダーリスク部門はこの情報をもとに、既存の調達プロセス上で必要最小限の追加ヒアリング項目だけ、AI用の補足項目として審査を進めます。同時に法務は、モデル開示や技術文書提供の条件が整っているか一元の入力データからチェックし、セキュリティはデータハブを通じて暗号化・通信方式等を確認、プライバシー部門はデータ特性に基づいてプライバシー評価を処理します。いずれの部門も申請者に対して重複して同一の要件データを再度回答させることなく、インテークされたデータをシームレスに利活用することができます。これによりベンダー側からも、重複した質問のない、整合性の取れた手続きとして処理が評価されます。

階層型インテークが失敗するパターン（およびその克服法）

階層型インテークは、主に7つの典型的なパターンによって失敗に陥ります。最初の5つのパターンは通常、プログラム稼働開始から最初の18ヶ月以内に発生します。残りの2つのパターンは、ガバナンス稼働開始から2、3年目の成熟期になってから静かにプログラムを蝕み、最初のいくつかの危機を乗り越えてきた運用の仕組み自体を台無しにしてしまいます。それぞれのパターンには、定期的なガバナンスモニタリングを通じて観測可能な特有の兆候（シクナル）と、本質的な原因を取り除くための具体的な対応アプローチが存在します。

特に初期の段階で最も頻発する失敗のメカニズム： 多くのエンタープライズが最初に陥るのが「システム評価を初期構築の一度きりのタスクイベントとして完了とする」誤った認識に起因するものです。本稼働開始から約1年が経過する際、監査で、承認当時と比較してプログラム製品に「ベンダー側のモデルのサイレントアップデート」、「一部の新データ利用に伴う機能領域拡張」などが知らぬ間に実行されたシステムが複数検知されます。インテークを起動した当初のリスク分類や監査トレールとしての状態は形骸化し、規制当局の立ち入り適合審査等に耐え難い実態が発生します。これを克服するには、階層1以外のすべての稼働システムに対して、規定に基づく定期評価サイクル（階層2は毎年、階層3は半年等の頻度等）を定義させ、かつ変更があった際は強制的に審査画面へ誘導する自動の警告トリガーを設定することが仕組みとして必要です。これらはプログラム稼働当初にインテークの一部として組み込まれている必要があります。

活動後半の2年目の課題こそ、本当にプログラムの根幹を崩壊させる要因です。 「形骸化してしまいすべて承認を投げるだけの審査委員会」や「経営幹部のAI統制に対する熱意の終息」は、それ単発の評価結果だけを見ていてもその活動の不適合を検知できないことが多く、本当に重大なセキュリティインシデントや法令違反等が発生した瞬間に初めてそれが不稼働状態にあったことが浮き彫りになります。独立の専門家にレビュー対象の役割を持たせる制度設計、意思決定段階においてあえて代替解を提示する批判的な意見の記載を提出書類としてルール化することなどは、ルール定義として当初から実装されなければなりません。監査体制に問題が発生した後の対処では遅く、「形骸化したガバナンス、形だけ書類を揃えていた」状況であるとして、法的処分において著しく不利になる要因です。

上記に定義される各失敗シグナルからシステムデータを保護しインベントリを活用するために、弊社作成の「AI製品インベントリの適正な実務構築ガイド」をあわせてご参照ください。

適合プロジェクト導入1年目のベンチマーク数値目標

以下に提示するメトリクスは、Enzaiを利用する世界的な各企業のこれまでのAI管理プログラムが、活動開始後、最初の1年（12〜18ヶ月以内）、および開始から3年が経過して一連の最適化システムが実地運用として定着する成熟期に達した際の各種パラメータをまとめたものです。これらは弊社の各実務ユーザー環境から得られた観測実績値より構築されていますが、各社におけるプログラム導入初期の習熟度合い、利用業界における規制内容、および導入しているシステムの自動化連携水準等に応じて差異が生じる可能性があるため、目標到達の成果を完全に保証するものではなく、ひとつの優れた基準として参照してください。もし、導入から12ヶ月が経過してもなお、最初の導入マイルストーンを大きく下回る数値となっている企業の場合、前述した問題に対応する仕組みが適切に設計・駆動していない可能性があります。

たとえば、監査を数年間推進した結果、階層4（拒否・除外判定）の実績レコードが1件も存在しないガバナンスプログラムがあった場合、それは実力として機能的に破綻しています。なぜなら、その間本来制限を受けるべき不適合であったはずの何らかのツールの持ち込み・利用に対して適切に対処できていないためです。逆に、ほぼ全てのツールの申請において毎回階層3の多重アセスメントが必要と判定されている企業の場合、リスクレベルに応じた意思決定（階層化）の機能が役割を果たしておらず、不要なコストによって事業部門の開拓スピードをむやみに阻害している事態を招きます。いずれの過多による影響も、インテーク設計に再調整が必要とされるアラート指標です。

実践に見る、リスク最適における比例性の原則の実装

実務における階層型インテークの設計は、諸外国の大手AI規制枠組みが推奨している「リスク比例措置（プロポーショナリティ・プリンシパル）」を本番環境で担保するための、最も効率的な解法を提示します。4段階で構成されるカテゴリは、それ自体を企業のガバナンスプロセスとして形にし、7からなる多角的な製品評価軸はルーティングの基準を与え、5つのフェーズから推進する引き継ぎは実際の適合スピードを維持させ、運用ベンチマークはそれらの適格性を常時監視・追跡する機能を提供します。

階層型プロセスには、かつての紙ベースや書類だけのプログラムでは達成できなかった「運用の透明性」が企業の事業推進にもたらされます。確実な仕組みが社内で駆動していれば、会社が保有するAIシステムの数が膨大に発展した状況でも、本当に警戒する必要がある高リスクシステムから目を逸らされることがありません。必要なシステム判定は迅速に進み、かつ万が一の規制当局による確認要請時には、追加の整理作業などを全く必要としない品質のログがあらかじめ用意されています。

規制遵守にあたり、最も避けなければならない誤認識は、行政機関などもよく指摘する「実体のないアセスメント書類の数合わせで、実地の対応推進をごまかす（コンプライアンス・シアター）」状態となることです。提出文書と実際に開発環境で許可・拒否されている決定が完全に同期し、実態として製品導入前に厳しい安全基準による「階層4の制限処理」が確実に稼働し、それに則した調達が機能しているプログラムこそが、本当に信頼に値するガバナンスプログラムと言えます。

さらに高度なエージェント型アプリケーションの制御、およびインテークより先進的な段階での適格保護の仕組みについては、弊社が提供する「エージェント型AIカバナンスの適正な統制ガイド」をあわせてご参照ください。

よくある質問（FAQ）

AIガバナンスにおける「階層型インテーク（Tiered Intake）」とはどのような概念ですか？

階層型インテークは、新しく導入または活用を希望するAIツールの利用要請（申請）に対して、システムが抱えている固有のリスク量に正確に比例させたアセスメント審査（セキュリティ審査等）を実施・ルーティングする手法を指します。企業の多くでは主に「セルフサービス」、「簡易審査」、「詳細審査」、「制限付き」等に分けた4階層のアプローチが採用されており、カテゴリによって適正なセキュリティレベルの確保、関連文書の精読基準、承認者の割り振りなどが連動します。これにより、従来のすべて等しく複雑なプロセスを適用してAI導入の推進スピードと安全確認の双方を阻害していた構造問題を克服します。

AIカバナンスを推進する際、社内で分けるべきアセスメントの階層はいくつに設計するのが適切ですか？

一般のエンタープライズを前提とした場合、4段階が最大のバランシングを示します。現在開発または保持するガバナンス対象システム数が総数で数百以下といった比較的小さな運用においては、プロセスの簡素化を優先して「簡易審査」と「詳細審査」の内容を共通アンケート構造にマージ（集約）し、3階層での運用から立ち上げる場合でも十分な性能を発揮できます。階層を5個や6個といった過度に複雑な設定にした場合、隣接する基準のボーダーラインにおいて各社が毎回割り振りの迷いや判定の曖昧さに振り回される結果を招き、不要に時間を要する非効率を生みます。

どのような条件を備えているAIシステムが、自動的に「階層3（詳細審査）」に規定されますか？

雇用審査、クレジットカードなどの与信判断、保険価格査定や医療画像選定、重要システムインフラなどを構成する、EU AI法の附属書IIIに関連するハイリスク用途に当てはまるもの、またそれに関する法定義に該当する特定業界要件に該当するシステムである場合です。また、人の手を完全に介さずに独自のビジネスアカウント等から自律的に実行権限を持つエージェント型AIシステムである場合もこれに属します。判定においては、複数の評価軸が異なる結果を示した際には「最もリスクが高いカテゴリを適用する」ルールを導入・ドキュメント設計するのが最適です。

エージェント型AIが申請された場合、インテークプロセスはどのような仕様特性に対応しますか？

一般的にエージェント型システムは、そのシステムとしての自律的行動のリスクを踏まえ、用途自体の機微性の有無にかかわらず、インテークへの入力時点でその判定を「階層3」として分類・審査します。エージェント向けの申請構成では、システムが関与できるコマンドリスト、人間への判断移管と決定のタイミング、自律的な処理の間におけるエラー発生防止手段があるかなどの評価項目がフォームに追加されます。このリストに変更が生じる場合は、これを重大な仕様変化として捉え、確認プロセスを再び起動します。

一度承認され運用中のAIシステムが、再び再アセスメントを必要とされるトリガー（トリガー事案）は何ですか？

EU AI法第3条(23)などが示す「重大な変更（Substantial Modification）」の定義に類する修正が本番アプリケーションに加えられる際です。具体的には、プロバイダーが提供したベースAIモデルコアが最新コアへと置き換わったタイミング、自律エージェントのアクセス接続先（ホワイトリスト）の拡大、または利用対象としている顧客個人情報の種別や利用地域の適用拡大などがあげられます。中リスクに定められたシステム（階層2等）であっても1年に1回程度定期的な監査をベースに進め、これに変更があった際は即時にチェックがトリガーされる形でのシステム構築が義務づけられます。

適正な階層カバナンスとしての申請プロセス環境を、実際に全くの初期設定から実装を完了させるまでどれくらいの時間を要しますか？

メール送受信などの暫定的な手動運用（パイロット展開）を推進するまでの初期環境の設計で、大体3〜6ヶ月ほどの時間を必要とします。前述した「1年目のベンチマーク水準」に照らした本番環境全体の運用立ち上げでは大体9〜15ヶ月、そして3年目に移行して組織的なライフサイクルが全自動で定着するレベルの成熟推進フェーズに到達するためには、おおよそ18〜24ヶ月ほどの運用経過を伴います。なお、社内での取扱システム数が一定の閾値（例えば審査中のAIアセット総数が50〜200個に差し掛かる時期）を超えた場合、これ以降スプレッドシートやチャット通知ベースの上記手動対応だけで適法性や正確さをキープすることは完全に物理的限界を迎え、自動化ツールを活用しなければ破綻します。

階層型インテークアプローチは、一般に存在する既存のIT統制や、TPRMなどのベンダー審査を完全に置き換えることができますか？

いいえ、それらを置き換える目的ではなく、むしろ既存システムの役割を引き継ぐための「フロントドア（一元の玄関口）」として機能します。インテークを単独の独立した並行審査システムとして構築した結果、現場は既存の調達確認とあわせて二つのシステムに二回同じ回答を求められるようになり、その運用が立ち消えてしまう失敗例が多数存在します。優れた構成では、インテークに1回集約されたインプットデータが、後続となる調達判定用のServiceNowやOneTrust、およびセキュリティアセスメントデータベースなどに対して必要なマスタとして自動流通・参照されます。

Enzaiは、ServiceNowなどのITツールや、OneTrustをはじめとした一般のGRCプラットフォームとどう異なりますか？

Enzaiは、それら既存の総合GRCスタックの上段でAIに特化したガバナンス評価を推進し、かつ既存スタックとシームレスに機能・データを接続統合させる「AIスペシャリストレイヤー」としてのプラットフォーム価値を提供します。例えば既存調達や契約といった一連の流れは使い慣れたServiceNow等のシステムに任せ、そこではチェックが困難なEU AI法への適応、およびISO 42001評価の作成や変更管理といった専門性の高い領域はEnzaiで行います。これにより、企業がこれまで多額の研究投資をしてきたGRCのインフラ環境を再構築・廃止することなく、最先端のAIカバナンスインフラを追加・結合して導入完了できるよう設計されています。

Enzaiの役割

本ガイドでは、AI管理における効率的な運用管理の手法をご紹介しました。Enzaiは、これを具体的に企業の現場にシステムとして組み込むためのプラットフォームパッケージを提供しています。モデル評価、自動的な7つの次元分類、5ステージフロー、および法的措置に耐えうる一元的な内部監査データの確保など、すべてがプログラム内のインフラとして全自動で駆動します。もし現在、管理数が急増してプロセスの崩壊や遅延を懸念されているのであれば、ぜひお気軽にEnzaiへご連絡ください。お客様が展開予定のリアルなAIユースケースをひとつサンプルとして、どのような承認・管理の形が最善となるか、私たちのシステム上で適合モデル例を示すサポートを実行いたします。

全編資料ダウンロードのご案内： 階層的な審査プロセスの適用だけでなく、具体的なガバナンスポリシーの設定や対象システムの把握、アセスメントの検証評価や日々のモニタリング管理まで網羅した、包括的解説ガイド 『AIガバナンス入門：ポリシー策定から実運用へ（The Essential Guide to AI Governance）』 を配布しております。公式Webサイト等から資料をダウンロードしてください。

Enzaiは、企業のAIカバナンスを一歩前進させ、抽象的なポリシーから実体のある確固たる組織運用への移行（イネーブルメント）を加速させるグローバル屈指のAIガバナンス特化型エンタープライズプラットフォームです。自律性を持つエージェント型製品のコントロールを確実に掌握するための特化型インフラ、変化するAIインベントリ全体の維持、およびEU AI法などの最新レギュレーションへの追従要件を提供します。高度にスケーリングされた各種自動化機能を通じて、企業はISO 42001やNIST要件との乖離を起こさず、最大限の信頼性とともに最新のAI技術開発による成長を推進できるよう支援します。

参考文献

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

2. ISO/IEC 42001:2023, 情報技術 - 人工知能 - マネジメントシステム。国際標準化機構、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. 米国連邦準備制度理事会（FRB）、SRレター 11-7、「モデルリスク管理における管理指針（Supervisory Guidance on Model Risk Management）」、2011年4月。 federalreserve.gov

11. ニューヨーク市 Local Law 144 of 2021, 自動化評価雇用ツールに関する規則。 nyc.gov/site/dca/about/automated-employment-decision-tools.page

12. カリフォルニア州プライバシー保護局（CPPA）、自動意思決定技術（ADMT）に関する修正・追加案草案。 cppa.ca.gov/regulations/

13. 規則（EU）2024/1689、第6条(3) - 著しい実質的危険をもたらさない特定附属書III用途への免除規定。

14. 規則（EU）2024/1689、第3条(23) - 「重大な変更（Substantial Modification）」における法定義。

15. 規則（EU）2024/1689、第50条 - 特定構成のAIにおけるユーザー等への各種透明性・開示義務。

16. 本セクションに提示される初年度（Year-1）における各種捕捉数、システム分布割合、および判定にかかる処理日数レンジは、 Enzaiを活用してAI統制を始動させてから12ヶ月以上が経過した実稼働中のお客様企業における、運用実績データ値を元にした基準値モデルです。実際の個々の企業動向は初期段階の組織構造や市場、採用している自動化学習状況に応じて変動するため、上記成果は結果を固定して保証する種類のものではありません。