AI CoEの作り方：推進体制の選び方から設置規程、最初の90日まで

AI CoE（AIセンターオブエクセレンス）の存在意義は、責任の所在を明確にしながら、事業部門が役に立つAIを実装・活用できるようにすることにあります。従業員100〜2,000人の企業なら、まず部門間で調整が必要な意思決定を洗い出しましょう。それを担当者2人で担えるのであれば、部署を新設する前に、小さなAI推進窓口から始める方法があります。

目指す成果は、実務で使える運営上の合意です。どの課題に取り組み、どの基準を適用し、誰が共通ツールを提供し、稼働後も誰が責任を持つのか。組織図に新しい指揮命令系統を加えるだけでは、こうした問いに答えは出ません。

2026年10月26日確認： 以下の組織運営に関する説明は、Microsoft、IBM、NISTの最新の公開資料と照合しています。設置規程、人員配置、90日間の進め方は、運営方法の提案です。業界標準の人員数や、導入に要する期間を保証するものではありません。

AI CoEは何をする組織ですか？

**AIセンターオブエクセレンス（AI CoE）**は、企業全体でAIを活用するための専門知識と共通サービスを取りまとめる機能です。事業の優先課題を、開発・導入、評価、基準づくり、人材育成につなげます。その権限の根拠は、経営層が承認した任務と権限の範囲にあり、「エクセレンス」という名前にはありません。

栽培を学ぶための温室を思い浮かべてください。共通の設備、育て方、専門家の助言は用意されていても、それぞれの花壇の世話をするのは担当の園芸家です。同じように、CoEは検証済みの問い合わせ回答の下書き作成手法を提供できますが、顧客への回答の正確さや確認作業の責任は、サポート部門の責任者が持ち続けます。

MicrosoftのCoEガイダンスでは、案件の受付、パイロット、基準、スキル、再利用可能な資産、成果報告を扱っています。本記事の読者には、これらを次の4つの役割に整理することを勧めます。

業務責任者とともにユースケースを選ぶ

提案された案件を一覧にし、優先順位を付けて管理します。ユースケースとは、特定の業務フローの中で行う具体的な作業です。たとえば、承認済みのヘルプ記事を基に問い合わせへの回答案を作ることです。「カスタマーサービスでAIを使う」では範囲が広すぎて、担当も評価方法も決められません。

責任者、現状の実績を示す基準値、観察できる成果を必須にします。利用可能なデータがあり、人が出力を確認できる案件を優先しましょう。日常業務への導入経路がない華やかなデモよりも、頻繁に発生し、失敗しても回復できる作業のほうが、最初の候補に適しています。

優先順位の根拠はAI戦略です。CoEはその戦略を予算の付いた案件に落とし込み、依存関係を可視化します。独断で別の事業戦略を作る役割ではありません。

現場で使える基準を定める

使用を認めるデータ、アクセスルール、レビュー要件、変更履歴、システムを停止する条件を定義します。そのうえで、実務に合った標準設定や短いチェックリストに落とし込みます。

サポートの回答案作成なら、「承認済みのナレッジを使い、確認者に参照元を示し、送信するすべての回答をサポート担当者が承認する」といったルールが考えられます。「責任を持ってAIを使う」という一般論だけでは、担当者は何をすればよいのか判断できません。

技術面のルールは、従業員が日々行ってよいことを示すAI利用ポリシーと結び付けてください。

共通ツールと評価の仕組みに責任を持つ

承認済みのアクセス手段、再利用可能な連携機能、システム台帳、業務フローの例、評価を実施する仕組みなど、共通機能には責任者を置きます。ここでいう評価とは、代表的なケースを使い、業務フロー全体の性能を繰り返し確認できる検証です。

CoEは共通の評価手法に責任を持ちます。一方、その業務にとって何を合格とするかを決めるのは業務責任者です。同じ基盤モデルを使っていても、サポート回答用のテストセットで採用業務の適切さを保証することはできません。

実際の業務に即して人材を育てる

サポートの確認担当者には根拠のない主張の見抜き方を、エンジニアには権限の境界のテスト方法を、管理職には利用されていることと役に立っていることの違いを教えます。受講者には、作業と失敗時の対応を実演してもらいます。

プロンプトのワークショップは、ツールを知る入り口にはなります。しかし、それだけで重大な影響を伴う業務フローを安全に運用できるとは確認できません。

AI推進組織の3つの運営モデルはどう選びますか？

開発・導入と運用の責任を、どこに確実に置けるかでモデルを選びます。従業員数だけを基準にするのは適切ではありません。大企業でもAIの専門知識が不足していることはあり、規模の小さいソフトウェア企業でも、十分な能力を持つプロダクトチームがある場合があります。

各モデルの呼び方や範囲は重なっています。Microsoftの運営モデルに関するガイダンスは、集中型、ハイブリッド型、分散型という区分を使い、中央のプラットフォームと分散した開発・導入体制の組み合わせをハブ・アンド・スポーク型とも説明しています。IBMのCoEの解説では、区分の仕方がやや異なります。担当を割り当てる際は、以下の定義を使ってください。

集中型が力を発揮するのは、限られた専門知識を意図的に集約するときです。 それでも、成果が業務に役立つかどうかを判断するのは業務責任者です。受付案件の待ち行列を可視化し、少人数の技術チームのもとで案件が見えないまま滞留することを防ぎます。

複数部門が同じ基盤を必要とする段階では、ハブ・アンド・スポーク型が有力な選択肢です。 仮に従業員700人の企業なら、中央チームがアクセスや評価ツールを維持し、サポート部門が回答品質、経理・財務部門が自部門の文書業務に責任を持つ形が考えられます。連携機能が故障したときに誰が直し、各サービスを誰が停止するのかを書き出してください。

分散型に必要なのは、各部門の意欲だけでなく運用能力です。 仮に従業員1,800人の企業なら、日常的なリリース判断を委ねる前に、参加する各部門に責任者、テスト記録、監視、インシデント対応の体制を示してもらいます。その水準に達しない部門には、引き続き手厚い支援を提供します。

業務フローごとに異なるモデルを使ってもかまいません。慎重な管理が必要な共通サービスは中央で運用し、能力のある部門には、範囲を限定した社内アシスタントの管理を任せることができます。権限委譲は、チームと業務に関する証拠に基づいて行います。全社一斉の「卒業式」のように進めるものではありません。

AI CoEとAIガバナンス委員会は何が違いますか？

AI CoEは開発・導入を支える能力を提供し、AIガバナンス委員会は、委ねられた方針策定とリスク判断の権限を行使します。両者は協力し、兼任する人がいてもかまいませんが、どちらが何を決めるのかは区別できるようにします。

たとえば委員会は、企業として許容するリスク、禁止する用途、例外の手続きを承認します。CoEはそれらを、設定、評価要件、研修、運用支援に具体化します。AIガバナンスの枠組みでは、この関係を明文化する必要があります。

権限の分担は、次の例を参考にしてください。

承認済みの社内向け下書き作成フローを、委員会がすべて審査する必要はありません。同時に、CoEも、自分たちが構築したという理由だけで重大なリスクを引き受けるべきではありません。誰が例外を承認できるのか、その適用範囲と有効期限を記録します。

NISTのAI RMF Coreは、GOVERN 2.1で責任の文書化を、GOVERN 2.3でAIリスクに関する意思決定への経営層の責任を求めています。新しい委員会を設けるかどうかよりも、これらが実現していることのほうが重要です。所管が明確なら、既存の経営会議やリスク管理会議がその権限を持つこともできます。

採用の前に、役割と決定権を割り当てる

役職を新設する前に、必要な責任を誰が担うかを決めます。専任で取り組むべき仕事もあれば、既存の専門家に確実に相談できればよい仕事もあります。役割の一覧は、組織図の各枠に1人ずつ採用するよう勧めるものではありません。

経営スポンサー： 合意した優先課題に予算を付け、部門間の対立を解消し、意思決定の権限者を指名します。COOは業務改革を、CTOは共通の技術基盤づくりを支えることができます。両者が関わる場合も、最終責任を持つスポンサーは1人に定めます。

CoE責任者： 任務の範囲、受付プロセス、共通の案件バックログ、報告を担います。設置規程で認められた権限の範囲内で、責任者が決まっていない案件や準備不足の提案を保留できる必要があります。

業務フロー責任者： 現状の基準値を示し、合格とする成果を定義し、確認担当者を割り当て、運用の結果に責任を持ちます。サポート回答の下書き作成であれば、モデルに最も詳しい人ではなく、サポート品質に責任を持つ管理者がこの役割を担います。

技術・評価責任者： 共通の連携機能、アクセス制御、再現可能なテスト、変更履歴を維持します。影響の大きさから独立したレビューが必要な場合は、システムを変更する権限と、業務上の成果を承認する権限を分けます。

データ・リスク分野の協力者： データ責任者は、その情報が目的に適しており、使用を認められるかを判断します。セキュリティ、プライバシー、法務などの専門家は、それぞれの所管事項を評価します。CoEはその意見を取りまとめますが、専門家の権限まで自動的に引き継ぐわけではありません。

活用支援責任者と部門の推進担当者： 承認済みの業務フローを研修に落とし込み、利用者から問題を集め、ガイダンスを更新します。部門の推進担当者に必要なのは名誉職の肩書ではなく、確保された活動時間と技術支援につながる窓口です。

本番稼働するすべての業務フローについて、インシデントの連絡を受け、サービスを停止し、復旧を手配する人も決めてください。AWSのCoEガイダンスには、正式なインシデント対応責任と対応措置が含まれています。パイロットが通常業務になる前に、運営上の合意へ組み込みます。

AI推進体制を2人の窓口で始められる条件

担当を明確にした2人の実務責任者と、既存の専門家による支援で調整業務を担えるなら、AI推進窓口という形を選べます。これは出発点としての提案であり、どの企業にも当てはまる最小人数でも、あらゆるAIシステムを2人で運用できるという約束でもありません。

業務またはプロダクトの責任者に、案件受付、業務フローの設計、研修、効果測定を割り当てます。技術責任者には、承認済みのアクセス手段、連携機能、評価、サポートを任せます。経営スポンサーを置き、既存のデータ、セキュリティ、法務の責任者に相談できるようにします。新たに専任ポストを設けず、既存業務の一部として時間を割り当てる形でも始められますが、上司はその時間を確保しなければなりません。

仮に従業員150人のサービス企業が、人の監督下で下書きを作る業務フローを試すなら、この体制で共通の実務を整え、より大きな組織機能が必要かを見極められる場合があります。2人は業務を調整し、出力の確認は引き続き関係部門が行います。

次の条件を満たしている間は、窓口体制を続けられます。

• 稼働中の案件数が、適切に支援・監視できる範囲に収まっている。
• 大がかりな個別開発をせずに、各部門が共通ツールを使える。
• 既存の責任者が、データやリスクに関する疑問へ速やかに回答できる。
• 通常のサポートと評価が、明示的に確保した稼働時間で対応できる。

部門をまたぐ依存関係、未解決の依頼、運用支援の需要が繰り返し発生し、その対応能力を超えるようになったら拡充します。

影響の大きい業務については、必要な対応能力を別途検討してください。人の権利や安全に影響するシステムを開発する企業では、規模が小さくても、幅広い活用支援プログラムより先に専門家による監督が必要な場合があります。

1ページでまとめるAI CoE設置規程のテンプレート

以下の簡潔な設置規程を出発点にして、角括弧の欄を氏名や具体的な約束に置き換えてください。1ページに収める想定ですが、自社の情報を書き込んだ後でレイアウトを確認しましょう。対象範囲を絞れば、2人の窓口体制にも同じ規程を使えます。

AI CoE設置規程：[会社名]

スポンサーと期間。 スポンサー：[氏名]。CoE責任者：[氏名]。発効日：[日付]。見直し日：[日付、初回は90日目]。割り当てる人員と稼働時間：[確約内容]。

任務。 適切なAI活用を通じて、[事業部門]が[具体的な成果]を改善できるよう支援します。ユースケースの優先順位を付け、共通の基準とツールを維持し、評価を調整し、承認済みの業務フローを運用できるよう各チームを育成します。

対象範囲。 [業務フロー、利用者、環境]を対象とし、[範囲を限定したパイロット]から始めます。[禁止用途および本任務の対象外の業務]は除外します。業務責任者は、引き続き自部門のプロセスと成果に責任を持ちます。

決定権。 スポンサーは優先順位と投入する人員・時間を承認します。CoE責任者は案件受付を管理し、ポリシーの範囲内でサポート対象の技術パターンを承認します。データ責任者は、提案されたデータ利用を個別に許可します。指名されたサービス責任者は、必要な証拠と専門家レビューがそろった後にリリースを承認します。[リスク承認者]は例外とその有効期限を決定します。[運用担当者]は、安全性に問題がある、または正常に機能しないサービスを停止でき、[責任者]がレビュー後に再開を承認します。他の責任者による必須の承認を免除できる役割はありません。

案件受付。 [フォーム／提出先]に、業務フロー、業務責任者、現状の基準値、目指す成果、利用者、データ、実行予定の操作、予見できる害、評価方法、サポート責任者を記載して提出します。毎週レビューし、「進める」「準備する」「上位判断を求める」「中止する」のいずれかを、理由、担当者、次回の日付とともに記録します。未解決の優先順位の対立はスポンサーへ、ポリシーの例外はリスク承認者へ判断を求めます。返答がないことを承認とはみなしません。

共通サービス。 承認済みのアクセス手段、AI台帳、再利用可能なパターン、評価手法、研修、インシデント連絡先を[場所]にまとめ、維持します。各資産に責任者と見直し日を設定します。個々の業務フローの受入基準は、その業務責任者が決めます。

測定指標。 受入基準を満たした作業の成果、品質上の不合格、受付から判断までの時間、保守されている資産の再利用、実演で確認した利用者の能力を追跡します。各パイロットについて、現状の基準値、目標、証拠の入手元、報告責任者、停止条件を記録します。実績の測定には、レビューと手直しも含めます。

運営サイクルと引き継ぎ。 毎週の案件受付レビューと、毎月のスポンサーレビューを実施します。通常利用に移る前に、運用責任、監視、インシデント対応、代替手段を確認します。見直し日には、証拠に基づいて本任務を拡大、修正、または終了します。

詳細な手順は規程の外に置き、リンクで参照できるようにします。ハンドブックを読まなくても、責任の所在をめぐる食い違いを解消できる規程を目指してください。

案件の受付は、必ず判断につなげる

受付から、責任者のいる次の行動までを短くつなぎます。まず次に何をするか決めるための情報を集め、その後、業務フローがもたらす影響に応じて、より詳しい証拠を求めます。

AI導入準備状況の評価で、提案された作業、データ、担当者の状態を確認してください。全社的な意欲をスコアにしても、個々の業務フローの準備が整っているとは判断できません。

サポート部門の管理者が、承認済みヘルプ記事から回答案を作ることを提案したとします。役に立つ受付記録には、その管理者、参照する記事群、確認担当者、現在の対応手順、許容できない誤りを記載します。下書きが自動送信されないことも明記します。

参照する記事群を管理する人がいなければ、**「準備する」に振り分けます。希望するデータ利用がポリシーの範囲外なら、「上位判断を求める」**に振り分けます。責任者、利用を許可されたデータ、レビュープロセス、評価の準備がそろって初めて、パイロットへ進めます。期待する効果が作業量に見合わない場合や、提案が禁止用途に当たる場合は中止します。

見栄えのよい生成例を作る前に、パイロットの受入基準を定義します。サポート回答の下書き作成なら、事実の裏付け、参照元の関連性、不適切な約束、情報開示、合格水準の回答に仕上げるためのレビュー工数を評価します。内容が矛盾する記事や、ナレッジベースでは答えられない質問など、扱いにくいケースも含めてください。

CoEは、こうした確認を繰り返し実施できるようにします。サポート責任者は、実際のサービス要件に照らして結果を判断します。技術的には生成に成功していても、元の作業を行うより確認に時間がかかるなら、業務としては不合格になり得ます。

AI CoEを立ち上げるには？最初の90日で進めること

最初の90日で運営上の合意を整え、範囲を限定した1件のパイロットから証拠を集めます。日付は見直しの節目として扱ってください。カレンダーが最終段階に達したからといって、受入基準に達していない業務フローを本番稼働させることはできません。

1. 1

   1-30日目：業務と権限を定める

   スポンサーと実務責任者を指名します。業務ソフトウェアに組み込まれたAI機能も含め、既存のAI利用を棚卸しします。重複する作業、不明確なデータ利用権限、サポート体制のないサービスを洗い出します。

   設置規程に合意し、最初の業務フローの運営モデルを選びます。現状の基準値を定め、受付記録を完成させます。承認済み用途のガイダンス、案件の提出先、インシデント連絡先を公開します。

   段階を終える際に確認する証拠： 署名済みの任務・権限の規定、実用に足る台帳、指名された業務フロー責任者、合意済みの評価計画です。データへのアクセスが未解決なら、次の段階でも準備に取り組みます。

2. 2

   31-60日目：範囲を限定して業務フローを検証する

   承認済みの範囲内でパイロットを実施します。何がその結果を生んだのか説明できるよう、関係するシステム設定、指示、参照資料を記録します。出力を確認する担当者を訓練します。

   通常のケースと失敗するケースを、合意済みの基準で評価します。出力品質とともに、レビュー時間と手直しも記録します。業務フローを停止し、従来の手順に戻す訓練を行います。

   段階を終える際に確認する証拠： レビュー済みの結果、課題の記録、訓練済みの運用担当者、実行可能な代替手順です。NIST AI RMFガイドの証拠に関する実務を使い、リスク、テスト、意思決定を結び付けます。

3. 3

   61-90日目：継続を判断し、運用責任を割り当てる

   業務フロー責任者と必要なレビュー担当者が、継続、変更、中止のいずれかを決め、理由を記録します。明確な証拠に基づいてパイロットを中止することも、有用な意思決定です。

   継続する場合は、監視、サポート、変更レビュー、運用終了の責任を割り当てます。再利用できる部分だけを、保守担当者を明記して公開します。次の依頼がAI推進窓口の能力で対応できるか、それともCoEの人員や機能を補強すべき具体的な必要性を示しているかを判断します。

   段階を終える際に確認する証拠： 文書化された判断結果、継続する業務の運用責任についての合意、優先順位を付けた次の案件バックログです。対象範囲の拡大は、証拠が裏付ける場合に限ります。

レビューを通過した成果を測る

レビューと修正を終えた後の成果を測ります。生成した下書きの数だけを数えると、使える状態にするための作業が見えなくなります。

サポートのパイロットなら、合格水準の回答に至るまでの時間を、従来の手順と比較します。レビューと手直しの時間も含めてください。回答の質を落として速くなっただけの業務フローが成功に見えないよう、速度と品質を併せて確認します。小規模なパイロットは、その現場に限った証拠として扱い、全社の生産性を推計する材料にはしません。

CoEの指標と、個々の業務フローの指標は分けて管理します。

• 判断までの時間： 必要な情報がそろった受付から、判断を記録するまでの経過時間の中央値です。情報不足による遅れは別に追跡します。
• 品質： パイロット前に合意した基準に対する、不合格の成果と重大な失敗を測ります。平均点だけでなく、重大度も記録します。
• 再利用： バージョンと責任者が明確で、保守されている共通資産を使う業務フローを把握します。
• 実務能力： 利用者が作業を行い、失敗を見抜き、定められた経路で上位判断や支援を求められるかを確認します。

研修の出席者数やアクティブアカウント数は、利用定着の状況を診断する助けにはなります。しかし、業務が改善した証拠にはなりません。生まれた余力を事業でどう使ったのか示せない限り、推定の時間短縮を金銭的な効果に換算することは避けてください。

今すぐ動くべき人と、待つべき人は？

調整上の問題が目に見えているなら、今すぐ取り組みます。既存の責任分担で仕事を回せているなら、新しい部署の設置は待てます。

COOや業務部門のリーダー： チーム間で作業が重複する、提案に業務責任者がいない、どのパイロットを続けるべきか誰も説明できない。こうした状況なら、スポンサーとして任務と権限を定めます。最初に決めるべきことは、どの成果を重視し、誰がそれに責任を持つかです。

CTOや開発担当者： 共通のアクセス手段、評価手法、運用支援を個別に維持することで問題が繰り返されるなら、それらを集約します。開発・導入を任せる相手は、自分たちで作ったものを運用できるチームに限ります。

購買・調達責任者： 契約や投資の範囲を広げる前に、CoEを通じて承認済みの用途、技術要件、運用責任を明確にします。調達権限と契約審査の責任は、正式に変更しない限り、既存の担当者に残ります。

承認済みのプロセスで問題なく業務を行えているチーム： そのまま使い続けてください。CoEの設置が発表されたからといって、すべてのツールを置き換えたり、すべての判断をやり直したり、合意済みの基準をすでに満たす業務フローを移行したりする必要はありません。

AI CoEに期待しすぎてはいけないこと

CoEは、存在するだけで価値を生む組織ではありません。その価値は、可能にした仕事と、防ぐことができた誤った意思決定にあります。

組織図の大きさは、成熟度を示しません。 立派な委員会があっても、止まった業務フローを復旧する責任者がいないことはあります。会議体を増やす前に、運用担当者を決めてください。

ツールの承認は、すべての用途の承認ではありません。 社内メモの下書き作成を認めても、同じシステムが顧客に約束を伝えることまで認めたことにはなりません。承認には、目的、データの範囲、実行できる操作の限界が必要です。

共通の評価手法で、あらゆる業務の適切さを保証できるわけではありません。 再利用できるのは手法と基盤です。業務分野に固有のケース、害、受入基準については、引き続き業務責任者の判断が必要です。

CoEが開発・導入を永続的に独占する必要はありません。 各チームが能力を実証したら、日常的な仕事は部門側へ移し、共通の責任者の下で運営する利点があるサービスを中央に残します。パイロットを評価するのと同じ真剣さで、CoEの任務も見直してください。

よくある質問

AIセンターオブエクセレンスとは何ですか？

AIセンターオブエクセレンスは、企業のAIユースケースの優先順位付け、基準の策定、共通ツールと評価の提供、人材育成を支える調整機能です。中央でシステムを開発・導入する場合もあれば、自ら構築・運用する事業部門を支援する場合もあります。

AIに入力したり、依頼したりしてはいけないことは？

会社のデータルールで禁止された情報を入力したり、承認済みの範囲を超える操作をシステムに求めたりしてはいけません。業務利用では、CoEやAI推進窓口が許可された用途を公開し、判断に迷う案件を関係するデータ責任者やリスク承認者につなぐ必要があります。

AIにはどのようなリスクがありますか？

業務フローによって、誤った出力、機密情報の開示、不公平な取り扱い、権限のない操作などのリスクがあります。対象業務で何が起こり得るかを特定し、管理策、確認担当者、復旧手順を定めてください。一般的なリスク一覧だけで、その評価を代替することはできません。

次の月曜日に、まず取り組むこと

繰り返し発生する業務フローを1つ選び、スポンサー、業務責任者、技術責任者で話し合います。設置規程の「任務」と「決定権」を埋め、成果に責任を持つ人を決め、どのような証拠が出たら中止するのかを書き出します。そのメンバーで合意した範囲を管理できるなら、AI推進窓口として始めましょう。拡充は、実際の業務量によって必要性が裏付けられてから判断します。

AIを実際の業務に組み込むための実践ガイドを受け取りたい方は、ニュースレターにご登録ください。