AISI（日本のAIセーフティ・インスティテュート）事務局が2026年2月に公開した「CAIO設置・AIガバナンス実務マニュアル（案）」は、高リスクのAIの用途を承認するときの割り当て例として、事業責任者をResponsible、CAIO（最高AI責任者）をAccountable、CISO（最高情報セキュリティ責任者）と法務部門とDPO（データ保護責任者）をConsulted、IT部門をInformedとする形を示しています^[1]。この4つの役割の頭文字を取った表がRACIです。同じマニュアル案は、すべての判断がCAIOに集中すると承認が滞り、責任が1人に偏るおそれがあると書き、その対策の1つにRACIで責任分担と決定権限を文書にすることを挙げています^[1]。

AIの案件を誰が進め、誰が止められるかは、社内規程の条文と会議の慣行と、役員それぞれの了解に分かれていることがあります。RACIは、それを案件ごとに1枚の表へ書き出し、承認を待つ人も承認する人も同じ表を見て動けるようにする手順です。では、RACIはどの単位で作り、最終責任の欄に誰を書けば、承認が止まらず、責任もあいまいにならないのでしょうか。

RACIの4文字は何を割り当てるか

RACIは、AIに限らずプロジェクト管理で使われてきた表の形式です。表の行に作業や決定事項を、列に人や部門を並べ、交わるところにR、A、C、Iのどれかを書きます。マニュアル案の例を当てはめると、高リスクのAIの用途を承認する作業では次のようになります^[1]。

「この作業での意味」の列は当社が付けた説明です。この例では、案件を進める事業責任者（R）と、承認の可否に責任を負うCAIO（A）が別の人になっています。

CとIの違いは、承認の前に意見を聞くか、承認の後に結果を伝えるかです。事業責任者が社内会議の要約のAIの利用を申請した場面で考えます。

CISOをCに置くと、CISOがセキュリティの観点から意見を返すまで、CAIOは承認できません。CISOの返事に3日かかれば、承認も3日遅れます。その代わり、CISOは承認の前に、その使い方を止めるよう求めることができます。

CISOをIに置くと、CAIOはCISOを待たずに承認し、CISOには承認の後で連絡が届きます。承認は早く済みますが、CISOが問題に気づけるのは承認の後です。ある部門をCとIのどちらに置くかは、承認の前に止められることと、承認までの日数のどちらを取るかを、案件ごとに決めることでもあります。

米国国立標準技術研究所（NIST）のAIリスク管理フレームワーク（AI RMF）も、組織の統治を扱うGOVERN機能で、AIのリスクを把握し、測り、管理することに関わる役割と責任と連絡経路を文書にし、組織全体の個人とチームに分かるようにすることを求めています^[3]。RACIは、この要求を表の形で満たす方法の1つです。

なぜ組織図ではなく、AIの用途ごとに作るのか

CAIOとCISOと法務部門の関係を組織図の上で1度決めれば済む、と考えたくなります。マニュアル案はそう書いていません。各部門との連携は固定的ではなく、ユースケース別に連携責任表（RACI）を作り、四半期ごとに更新して、必要に応じて責任と承認フローの強さを見直すのが実務的だとしています^[1]。

同じ生成AIのサービスでも、社内会議の要約と採用選考では、相談を受けるべき部門が違います。マニュアル案は、採用選考のAIについて、影響評価に人事部門、ダイバーシティ＆インクルージョン担当部門、法務部門を参加させるよう求めています^[1]。社内会議の要約の行には、この3部門をCに置く理由がありません。組織図で1度決めた分担を全案件に当てはめると、社内会議の要約にまで法務部門の意見を待つ手順が入り、承認が遅れることがあります。

マニュアル案は、初年度の計画の例でも、RACIを2段階で書いています。最初の90日では、CAIOの任命と合わせて権限と責務のRACIを定義し、91日目から120日目では、パイロット案件ごとの責任者をRACIで確定します^[1]。前者は全社でのCAIOの権限を決める表で、後者は案件ごとの表です。

ここで、「ユースケースごとにRACIを作るなら、最初に整備するために全部のユースケースをヒアリングしなければならず、膨大な時間がかかる」という疑問が出ます。マニュアル案は、すべてのユースケースの表を最初にそろえるよう求めてはいません。案件ごとの表を確定する対象はパイロット案件で、低リスクで範囲の限られた案件には簡易フローや事後報告を認めています^[1]。RACIのために、ユースケースを1件ずつ聞き取り直す必要はありません。使い道と高、中、低の区分は、AIインベントリを作るときに、部門長に書いてもらって集めています。当社は、その区分と、権利・安全影響AIに当たるかどうかに応じてRACIの型を作り、インベントリの各行に型の名前を書く進め方をとります。たとえばAIインベントリに20件の使い道があっても、RACIの表を20枚作る必要はなく、低リスク、中リスク、高リスク、権利・安全影響AIの4つの型を作れば済みます。

Aの欄に、CAIOと合議体のどちらを書くか

マニュアル案を読み進めると、承認の最終責任をめぐって2つの記述が並んでいます。RACIの例ではCAIOがAです。一方で、推奨体制の節は、CAIOを議長とする全社AIステアリングコミッティという合議体が、ユースケースの採否について最終決定権を持つか、経営会議に答申する役割を持つことを想定しています。どちらにするかは各社が選び、社内規程などで明確にしておくことが望ましいとしています^[1]。

Aの欄を埋めるには、先に社内規程で合議体の位置付けを決める必要があります。以下は、マニュアル案の記載から当社が考える整理です。

• 合議体が最終決定権を持つなら、合議体の審査を受ける行のAは合議体になり、議長のCAIOがその決定を説明する立場になる。
• 合議体が答申だけを行うなら、Aは経営会議や担当役員になり、合議体はCに入る。
• どちらの場合も、当社は1つの行にAを1つだけ書くことを勧める。マニュアル案の例でもAはCAIOの1人で、Aが2つあると、承認を求める事業責任者がどちらの判断を待てばよいか分からなくなるからだ。ただし、Aを何人にするかも組織が決めることである。

合議体をAにしたときは、開催の頻度が承認の待ち時間になります。マニュアル案は、全社AIステアリングコミッティの開催を少なくとも月1回を標準としています^[1]。すべての用途の承認を合議体のAに集めると、月1回の開催では、提出の時期によって承認まで1か月近く待つ案件が出ることがあります。

マニュアル案は、この待ち時間への対策も書いています。承認や例外承認に目標リードタイムを設けてダッシュボードで見張ること、低リスクで範囲の限られた案件には簡易フローや事後報告を認めることです^[1]。RACIでは、低リスクの行のAを事業責任者に下ろし、CAIOをIに置く形にできます。

最初のRACIをどう作るか

リスク区分ごとの型を作れば、最初に作る表は5行で済みます。以下は、マニュアル案の記載をもとにした作り方の一例で、当社の見方です。

1. 社内規程で、全社AIステアリングコミッティが最終決定権を持つのか、答申だけを行うのかを決める。
2. 表の行に、高、中、低それぞれの用途の承認、権利・安全影響AIの用途の承認、重大インシデントの対応方針の決定を置く。各行にAを1つ書いてから（当社が勧める書き方）、R、C、Iを割り当てる。承認の4行が型になる。
3. Cに置いた部門ごとに、意見を返す期限を書く。
4. 型を選ぶためのリスク区分は、新しく作らない。マニュアル案には、高、中、低の区分を付ける場面が2つある。1つ目は、最初の90日でAIインベントリという一覧表を作るときで、社内のユースケースを棚卸しして、1件ずつ高、中、低のどれかを簡易に付ける。2つ目は、案件ごとにAIIA（AI影響評価）という評価書を書くときで、AIIAに書く項目の1つに高、中、低の社内リスク区分がある^[1]。
5. 新しい案件は、事業責任者が申請のときに型を写して出す。型は、1つ目のAIインベントリの区分で仮に選び、2つ目のAIIAの区分で確定させる。一覧表の1行だけを見て付けた区分より、1件を詳しく調べて付けた区分のほうが確かだからである。AIIAで詳しく見た結果、区分が上がったら、承認の前に型を選び直す。案件ごとに個別に詰めるのはパイロット案件と高リスクの案件だけにし、四半期ごとに型を見直す。

この表は当社が作った例です。高リスクの行はマニュアル案の7.3の割り当て例をそのまま使い^[1]、権利・安全影響AIの行は、5.8がCAIOと全社AIステアリングコミッティの承認を必須にしていることに合わせ、議長をCAIOとする合議体をAにしました^[1]。低リスクの行は15.1の簡易フローと事後報告の考え方に合わせて、Aを事業責任者に下ろし、CAIOには事後に報告する形にしました。重大インシデントの行は、7.1が全社AIステアリングコミッティの決定事項に重大インシデントの対応方針を挙げているので^[1]、合議体が最終決定権を持つと規程で決めた場合の書き方にしています。中リスクと低リスクの行は、マニュアル案に例がなく、当社が作った割り当ての一例です。どの部門をCに置き、どの部門をIに置くかは組織の体制や事業によって変わるので、決まった正解はありません。

区分を、情報資産のリスク分類（機密性、完全性、可用性の点数）だけで決めると、型を取り違えることがあります。情報資産の点数は、情報が漏れたり壊れたりしたときの損害を測るもので、AIの判断で人が受ける影響は測らないからです。マニュアル案は採用選考のAIを、候補者の雇用機会やキャリアに重大な影響を与えるという理由で、高リスクとして管理するとしています^[1]。この理由は、情報資産の点数には現れません（情報資産のリスク分類）。

たとえば、営業部門が「社内会議の要約にAIを使いたい」と申請し、AIインベントリの簡易な区分が低リスクだったとします。営業部門は、低リスクの行を写し、Rに担当者の名前、Aに営業部長の名前を入れて申請します。AIIAでも低リスクと確かめられれば、営業部長が承認し、CAIOは承認の後に報告を受けます。AIIAで、会議に顧客の個人情報が多く含まれると分かり中リスクに上がったなら、中リスクの行に写し直し、CISOの意見を聞いてからCAIOが承認します。

RACIの表は、社内規程の代わりにはなりません。表のAに書いた人が承認できる根拠は、職務権限規程などの社内規程で別に定めておく必要があります。マニュアル案自身も、すべての企業にそのまま当てはまる唯一の正解ではなく、特定の法域での法的助言でもないと断っています^[1]。文書はドラフト版として意見を募集している段階です^[2]。

冒頭の例に戻ると、マニュアル案がRとAを別の人にしているのは、案件を進める人と止められる人を分けるためだと読めます。では、AIIAで区分が上がったとき、事業責任者が型を選び直して申請し直したことを、誰が確かめるのでしょうか。

参考・一次ソース

■お問い合わせ

全社AIステアリングコミッティの位置付けを決めてRACIのAの欄を埋めたいときや、リスク区分ごとに承認の流れを分けて待ち時間を減らしたいときは、アハクラフトにご相談ください。

お問い合わせ