AI推進チームの作り方｜情シス・法務・DXの役割分担を「RACI」で見える化する90日ステップ

コアチームは推進・技術・意思決定の小さな母体にする

コアチームは、AI活用推進の中心になる少人数のチームです。組織規模にもよりますが、初期段階では想定例として3〜5名程度から始めると運用しやすいでしょう。

推進責任者

DX部門、経営企画部門、または全社改革を担う部署が担当することが多く、AI活用の目的、対象領域、優先順位、経営報告を担います。

技術・セキュリティ担当

情シス部門や情報セキュリティ部門が該当します。ツール選定、アカウント管理、権限設定、ログ管理、既存システムとの連携可否を確認します。

意思決定や合意形成の担当

経営層や部門長との接続を担い、予算、対象範囲、リスク許容度、全社展開のタイミングを確認します。

この3つの役割をコアチームに置くことで、「何を実現したいのか」「安全に使うための条件は何か」「組織としてどこまで進めるのか」を同じ場で扱えるようになります。

拡張チームは専門観点を必要なタイミングで入れる

拡張チームは、常時すべての会議に参加する必要はありません。論点に応じて相談・レビューする関係者です。

法務部門

契約、個人情報、著作権、規程との整合性を確認します。特に、社外に出す文書、契約に関わる文書、個人情報や機密情報を含む業務では、早い段階で関与してもらう必要があります。

人事部門

研修、社内周知、職種別のスキル育成を担当します。AI活用は一部の詳しい人だけが使っても、組織全体の成果にはつながりにくいため、教育設計が重要です。

現場代表

実際の業務で使えるユースケースを見極める役割です。AI推進チームが考えた施策が、現場で本当に使えるか、現場負荷が大きすぎないかを確認します。

必要に応じて、広報、ブランド、監査、カスタマーサクセス、営業企画なども拡張チームに含めます。

小さく決める場と広く確認する場を分ける

AI推進体制でよくある失敗は、すべての関係者を同じ会議に呼んでしまうことです。これでは、議論は広がりますが、決定が進みにくくなります。

コアチームでは、週次または隔週で進捗確認と意思決定を行う。拡張チームでは、月次または論点別にレビューする。このように分けると、推進スピードとリスク確認のバランスを取りやすくなります。

たとえば、初期運用の想定例は次のとおりです。

• コアチーム会議：隔週30分
• 拡張レビュー会議：月1回60分
• 経営報告：四半期に1回
• 現場ヒアリング：PoC対象部門ごとに月1回

これは実績値ではなく、体制設計のたたき台です。組織規模、対象部門数、扱う情報の機密度に応じて調整してください。

DX部門・経営企画部門の役割

DX部門や経営企画部門は、AI活用の目的と優先順位を定義する役割を担います。

AIを導入すること自体が目的になると、現場では「何のために使うのか」が曖昧になります。まずは、どの業務課題を解決したいのかを明確にする必要があります。

たとえば、次のような論点です。

• 会議後の議事録作成時間を減らしたい
• 社内問い合わせ対応を効率化したい
• 提案書作成の初稿づくりを早くしたい
• 研修コンテンツの作成負荷を下げたい
• 社内ナレッジの検索性を高めたい

DX部門は、こうした活用テーマを整理し、PoC（概念実証。小さな範囲で実用性や課題を検証する取り組み）の対象範囲を決めます。さらに、利用状況や成果を集計し、次の展開判断につなげます。

情シス部門・情報セキュリティ部門の役割

情シス部門は、AI活用の土台を支える役割です。

主な担当領域は、ツール選定、アカウント管理、権限設定、セキュリティ、ログ管理、既存システムとの連携です。AI活用を現場に広げるほど、誰がどの情報にアクセスできるかが重要になります。

確認すべき項目は、次のようなものです。

• 利用者の追加・削除フロー
• 退職者・異動者の権限変更
• 管理者権限の付与基準
• 外部連携の可否
• ログ取得・監査の要件
• 機密性の高い業務での利用制限
• 利用中のAIサービスやモデルの変更状況
• ベンダーの利用規約・データ取扱方針の変更

AI活用をスムーズに進めるには、現場が安心して使える環境を先に整えることが大切です。また、導入時の確認だけで終わらせず、利用中のAIサービスやモデル、利用規約、データ取扱方針などの変更を継続的に確認し、必要に応じて権限や利用条件を見直す運用も必要です。

ツール選定では、Microsoft 365、Google Workspace、各種生成AIサービス、社内ナレッジ検索ツールなど、複数の選択肢があります。Kanataを利用する場合は、スペース、プロジェクト、アプリ、ライブラリという単位で利用者・データ・機能を整理でき、プロジェクトごとにメンバーや権限を管理できる点が特徴です。部門や用途ごとに情報を分けたい場合は、この構造を権限設計とあわせて検討できます。

法務部門の役割

法務部門は、AI活用の「してよいこと」と「してはいけないこと」を整理する役割です。

特に重要なのは、入力情報の扱いです。公開情報、社内一般情報、顧客情報、個人情報、未公開財務情報、契約情報などは、同じように扱うことはできません。

日本の個人情報保護委員会は、生成AIサービスの利用に関して、個人情報を適正に取り扱う必要があることを注意喚起しています。また、法律・規制・契約に関わるAI出力は、社内の法務部門や専門家が確認する運用にしておくのが現実的です。EU域内でAIを提供・利用する事業がある場合は、EU AI Actの適用状況も確認する必要があります。AIリテラシーに関する規定などはすでに適用されており、2026年8月2日からは透明性に関する義務なども適用されています。一方、高リスクAIに関する一部の規定には、2027年以降の適用時期が設定されています。

法務部門が関与すべき論点は、次のとおりです。

• 入力禁止情報の定義
• 個人情報や機微情報の扱い
• 契約書や顧客資料を扱う場合の条件
• AI出力の著作権・引用・二次利用
• 社外提出物にAIを使う場合のレビュー基準
• 利用規程や社内ガイドラインとの整合
• 利用中のAIサービスやモデル、利用規約の変更時の再確認

法務部門の関与が遅れると、PoC後にルールを作り直すことになりかねません。AI推進の初期段階から、最低限の禁止事項と相談基準を決めておくことが重要です。

人事部門の役割

人事部門は、AI活用を一部の人だけの取り組みにしないための役割を担います。

AIツールを導入しても、社員が使い方を知らなければ定着しません。また、使う人によって理解度に差があると、出力品質やリスク認識にもばらつきが出ます。

人事部門が担うべき領域は、次のようなものです。

• 全社員向けの基礎研修
• 管理職向けの活用研修
• 職種別ユースケース研修
• 利用ガイドラインの周知
• 新入社員・異動者向けオンボーディング
• AI活用スキルの評価・育成方針

研修コンテンツは、動画、eラーニング、社内勉強会、オンデマンド教材など、複数の形式が考えられます。Kanataを利用する場合は、AIチャット、AI要約、eラーニングなどを組み合わせ、動画を起点に教材を作成・配信する運用も検討できます。ただし、研修コンテンツを作るだけでは十分ではありません。受講後に実務で試し、疑問を拾い、ルールを更新する流れが必要です。

現場代表の役割

現場代表は、AI活用を実務に接続する役割です。

推進チームや情シス部門だけで考えた施策は、どうしても管理側の視点に寄りやすくなります。しかし、実際にAIを使うのは現場の社員です。

現場代表が確認すべきなのは、次のような点です。

• そのユースケースは本当に頻度が高いか
• AIを使うことで作業が増えないか
• 出力を確認する負担は現実的か
• 現場で使う言葉や形式に合っているか
• 例外ケースが多すぎないか
• 成果が出た場合、横展開できそうか

現場代表は、単なる利用者ではなく、AI推進チームにとっての検証者です。早い段階で巻き込むことで、机上の体制設計にとどまりにくくなります。

AI推進のRACI想定例

以下は、AI推進体制を設計する際の想定例です。実績値ではなく、社内提案のたたき台として調整してください。

この表を作ると、たとえば「利用ガイドラインはDXが原案を作り、法務が最終責任を持つ」「研修は人事が責任を持つが、内容はDXや現場代表と相談する」といった関係が見えるようになります。

RACIで決めすぎないほうがよいこと

一方で、RACIは細かく決めすぎると運用が重くなります。

日々のプロンプト改善、個人の業務メモ整理、部門内の小さな活用アイデアまでRACIに落とす必要はありません。すべてを承認制にすると、現場の試行錯誤が止まってしまいます。

RACIで明確にすべきなのは、リスクや影響範囲が大きい領域です。

• 機密情報を扱う業務
• 社外に出す文書
• 契約・法務に関わる出力
• 全社展開するガイドライン
• 研修や評価に関わる方針
• ツールや権限の設計

日常的な小さな改善は現場に任せ、影響の大きい判断はRACIで責任を明確にする。このバランスが重要です。

目的とコアチームを決める

最初に決めるべきなのは、AI活用の目的です。

「全社でAIを使う」だけでは広すぎます。まずは、どの業務課題を対象にするのかを絞ります。

想定例としては、次のようなテーマです。

• 会議後の議事録作成を効率化する
• 社内問い合わせ対応を減らす
• 営業資料の初稿作成を早くする
• 研修コンテンツの作成負荷を下げる
• 社内ナレッジを検索しやすくする

目的を決めたら、推進責任者、情シス担当、意思決定や合意形成の担当を置きます。この段階では、全社の関係者をすべて集める必要はありません。まずは小さなコアチームを作り、論点を整理します。すでに部門や個人で生成AIが利用されている場合は、誰が、どのAIサービスを、どの業務で利用しているかを棚卸しし、AIインベントリとして把握しておくと、その後のルール設計やリスク確認につなげやすくなります。

利用ガイドラインと禁止事項を決める

次に、最低限の利用ガイドラインを作ります。

ここで重要なのは、最初から完璧な規程を作ろうとしないことです。まずは、社員が迷いやすいポイントを明文化します。

• 入力してよい情報
• 入力してはいけない情報
• 個人情報のマスキング方法
• 社外提出前のレビュー基準
• AI出力をそのまま使ってはいけない領域
• 判断に迷った場合の相談先

この段階で法務と情シスを巻き込み、「禁止」と「要相談」を明確にしておくと、後の展開が進めやすくなります。

ユースケースを3つに絞って試す

AI活用の初期段階では、ユースケースを広げすぎないことが重要です。まずは、頻度が高く、効果を実感しやすく、リスクを管理しやすい業務を選びます。

想定例としては、次の3つです。

1. 議事録要約です。会議録音やメモをもとに、決定事項、TODO、議論の要点を整理します。
2. 社内FAQです。人事・総務・情シスへの定型問い合わせを、規程やマニュアルに基づいて回答できるようにします。
3. 提案書や報告書の初稿作成です。白紙から書く負担を減らし、人が内容確認と編集に集中できるようにします。

ツールは、既存のグループウェア、汎用生成AI、ナレッジ管理システム、AI活用支援プラットフォームなどから選べます。Kanataを使う場合は、プロジェクト単位でAIチャット、AI要約、eラーニングを分け、プロンプトや学習データをライブラリで管理する運用が検討できます。

効果測定と次フェーズ判断を行う

PoCが終わったら、利用実績と現場の反応を確認します。

見るべき指標は、単に利用回数だけではありません。次のような観点で確認します。

• 利用者数
• 継続利用率
• 対象業務の作業時間
• 出力のレビュー負荷
• 問い合わせ件数
• 現場の満足度
• リスク・ヒヤリハットの発生有無
• 横展開できそうな部門
• 利用中のAIサービス・モデルの変更状況
• ベンダーの利用規約・データ取扱方針の変更
• 誤回答・不適切出力・情報漏えいなどのインシデント
• AI利用による業務品質への影響
• 利用停止・モデル切替が必要になった場合の代替手段

たとえば、3か月間・5部門・50名で試行した場合、月次で「利用回数」「対象業務の作業時間」「レビューで修正が必要だった割合」を確認する、といった設計が考えられます。

ここでも、実績がない数値を成果として書かないことが大切です。社内提案資料では、「想定例」「目標値」「実績値」を分けて記載しましょう。また、PoC後も定期的に利用状況とリスクを確認し、AIサービスやモデル、利用規約などの変更に応じてガイドラインや運用を見直すことが重要です。

情シスだけに任せてしまう

AIツールの導入は情シスが主導しやすい領域です。しかし、情シスだけで進めると、セキュリティやアカウント設計は整っても、現場の業務課題に合わないことがあります。

回避策は、ツール選定の段階からDX部門と現場代表を入れることです。何を実現したいのかを明確にしたうえで、必要な機能や制約を整理します。

DX部門だけで進めてしまう

逆に、DX部門だけで進めると、活用テーマは出てきても、情報管理や法務確認が後追いになることがあります。

とくに、顧客情報、契約情報、個人情報を扱う可能性がある場合、法務や情シスの確認が遅れると、PoC後に運用を止めざるを得ないこともあります。

回避策は、初期段階で「禁止情報」「要相談情報」「社外提出前レビュー」の3つだけでも決めておくことです。

法務確認を最後に回してしまう

法務確認を最後に回すと、「現場ではもう使い始めているが、ルール上は問題がある」という状態になりやすくなります。

法務部門は、AI活用を止めるために入るのではありません。安全に広げるための前提を整える役割です。

早い段階で相談し、最初からすべてを禁止するのではなく、「どの条件なら使えるか」を一緒に整理しましょう。

人事・研修を巻き込まない

AI活用は、詳しい人だけが使う状態では広がりません。特に、現場社員のスキル差が大きい場合、利用ルールやプロンプトの書き方が人によってばらつきます。

回避策は、人事部門と一緒に、基礎研修、職種別研修、管理職向け研修を分けて設計することです。最初から高度な使い方を教える必要はありません。まずは、入力してはいけない情報、出力の確認方法、よく使う業務テンプレートから始めるのが現実的です。

現場代表がいない

推進チームに現場代表がいないと、体制図は整っていても、実務に合わない施策になりがちです。

たとえば、議事録要約のテンプレートを作っても、実際の会議体に合っていなければ使われません。社内FAQを作っても、現場が使う言葉で検索できなければ定着しません。

回避策は、PoC対象部門から1〜2名の現場代表を入れ、テンプレートや運用ルールを一緒に検証することです。