連載⑦（データレディネス篇）でデータという「上流」を整えました。第8回は、もう一つの上流——「人材」と「体制」に移ります。
「うちにはAI担当者が1人しかいない。その人が辞めたら終わり」「気がつけば部署ごとに別のAIツールを契約していて、全部で月いくらかかっているか誰も把握していない」——この2つは、規模を問わず最も頻繁に耳にする定着・拡大フェーズ特有のつまずきです。
連載④（現場とIT対立篇）が扱ったのは導入時の摩擦でした。本記事が扱うのはその先——導入はできたのにAIが組織に「面」として根付かず、担当者への一点集中とツールの無秩序拡大が同時進行する状況です。
解決の核は2つです。スキルの組織内移転（知識を人に閉じ込めない設計）とAIポートフォリオ管理（ツールを組織として把握・制御する仕組み）。技術ではなく人・体制・ガバナンスの話であり、どちらも「やり方を知れば即日着手できる」レベルの問題です。
（1）2つの問題の本質——「点」で運用しているAIが組織に「面」として定着しない
AI担当者への一点集中と、ツール乱立は別々の問題のように見えますが、根は同じです。AIの導入と運用が「個人」や「部署」という点単位で起きていて、組織全体という面に広がっていないという構造的な問題です。
点で動いている状態では何が起きるか。担当者一人がツール選定・プロンプト設計・社内展開・トラブル対応をすべて抱え込みます。その人が異動や退職をすると、ノウハウごと消えます。一方、各部署が自分の判断でツールを導入し続けると、全社では何十ものAIサービスが走り、コストも把握できなければ、重複機能のムダも見えません。
この状態は、NOC/TACの現場でいう「構成管理台帳（CMDB）がない状態でのネットワーク運用」に似ています。どの機器が動いていて、誰が担当していて、どんな設定になっているか——それが見えないまま運用を続けると、障害発生時に手も足も出ない。AIツールも同じで、「何を誰が使っているか」が見えなければガバナンスは成立しません。
| 問題 | 表面症状 | 根本原因 | 本記事での処方 |
|---|---|---|---|
| AI担当者1人依存 | 「あの人しか分からない」「退職したらAI活用が止まる」 | 知識・スキルが個人に集中し、組織に移転されていない | スキルの組織内移転設計 |
| ツール乱立・無秩序拡大 | 「何のツールに月いくらかかっているか分からない」「同じ機能のツールが3つある」 | 部署単位の点導入が積み重なり、全社視点の管理がない | AIポートフォリオ管理 |
（2）AI担当者1人依存の解剖——なぜ”一点集中”が起きるのか
AI担当者への一点集中は、悪意ではなく構造的必然で起きます。典型的な経緯はこうです。
社内でAIに興味を持ったエンジニアや情シス担当が、自発的に試して成果を出す。「あいつに聞けばAIのことは解決する」という評判が広まる。相談が集中し、その人が全案件を抱える。他の人はAIに関わる機会がないまま学習の場を失い、一点集中がさらに深まる——この正のフィードバックループが固まると、担当者が異動・退職した瞬間に全社のAI活用が止まります。
一点集中の何が問題か、整理します。
| リスク | 具体的なシナリオ | 影響度 |
|---|---|---|
| バス係数1のリスク | 担当者が退職・長期休暇・異動で、AI活用が組織ごと止まる | 高 |
| スケールの限界 | 全社からの相談が1人に集中し、対応が追いつかず活用が停滞する | 中〜高 |
| 暗黙知の非共有 | 有効なプロンプト・ワークフロー・ノウハウが個人の頭の中にあり、引き継ぎ不能になる | 高 |
| 担当者の燃え尽き | 集中した負荷と期待で担当者が疲弊し、自らがボトルネックになる | 中 |
| 業務継続性の脆弱化 | その担当者が関与しているすべてのAI活用案件が、同時にリスクを抱える | 高 |
「バス係数（Bus Factor）」とは、何人が同時にいなくなるとプロジェクトが止まるかを示す指標です。バス係数が1ということは、たった1人の欠如で組織全体のAI活用が機能停止するという、極めて脆弱な状態を意味します。
（3）スキルの組織内移転——知識を「人」に閉じ込めない4つの設計
解決策は「AI担当者を増員する」ではありません。増員はコストがかかり、時間もかかります。より現実的なアプローチは、既存の担当者が持つ知識・スキル・ノウハウを、組織の資産として移転・蓄積する仕組みを作ることです。
スキルの組織内移転には4つの設計柱があります。
柱①：プロンプト・ワークフローのライブラリ化
担当者の頭の中にある「効くプロンプト」「業務ワークフロー」を、誰でも参照・使用・改善できる形で外部化します。ポイントは、単なる「プロンプト集」ではなく「なぜこの設計か」の解説を付けることです。コピペ集では次の人が応用できません。
最低限記録すべき項目は以下の5つです。
| 項目 | 内容 | 例 |
|---|---|---|
| 用途・業務文脈 | どの業務でいつ使うか | 「月次レポートの要約文生成」 |
| プロンプト本文 | 実際のプロンプト（変数部分を明示） | {{文書}} を以下の条件で… |
| 設計意図 | なぜこの指示にしたか | 「出力長を制限しているのは…」 |
| 出力例 | 良い例・NG例のサンプル | 期待出力と失敗例を並記 |
| 改善履歴 | どう変えてきたか | 「v1→v2でロール指定を追加」 |
柱②：AI活用の「型」を研修化する
担当者に相談するのではなく、社員が自分で使えるようにするには、「型」の言語化と研修化が必要です。ここで重要なのは、汎用的なAI操作研修ではなく、「自社の業務でAIをどう使うか」という文脈に絞った実践的な内容にすることです。
効果的な研修設計の3原則：
1. 実際の業務タスクを材料にする — 「メール文を書くプロンプト」より「◯◯部署の月次報告書の初稿生成プロンプト」の方が定着率が高い。自社の具体業務で試せるものに絞る。
2. 「失敗から学ぶ」セクションを入れる — うまくいかなかったプロンプトと、改善した経緯を共有する。成功例だけでは応用力がつかない。
3. 小さく繰り返す — 1回の全日研修より、30分×隔月の「AI活用事例共有会」の方が知識が定着する。継続的な場の設計が重要。
柱③：「AI活用ギルド」の組成
AIに関心・スキルのある人材を部門横断で集めたインフォーマルな実践コミュニティ（ギルド）を作ることで、担当者1人への依存を分散させます。ギルドは組織図上の正式な部署ではなく、「各部門のAI活用を推進する人たちのゆるやかな横断組織」です。
ギルドの役割は3つです。①各部門のAI活用事例を横展開する、②課題を持ち寄って相互に解決する、③AI活用のナレッジをライブラリに追加・更新する。週次の全体会議ではなく、月1回の事例共有＋Slackチャンネルなどの非同期チャンネルで運営するのが現実的です。
柱④：「AI活用度」の可視化と評価への組み込み
スキル移転が進まない理由の一つは、AIを使いこなすことが「評価される行動」になっていないことです。「AIを使うかどうかは個人の自由」という状態では、学習インセンティブが働きません。
具体的な対策として、業務目標（OKR・MBO等）に「AIを活用した業務改善提案」を組み込む、AI活用事例を共有した社員を称える仕組みを作る（表彰・社内ブログ等）、部門ごとのAI活用指標（使用頻度・効率化成果）を経営報告に含める——といった施策が効果的です。
（4）ツール乱立の解剖——部署ごとのサイロ導入がどう積み重なるか
AIツールの乱立は、一夜にして起きません。典型的なパターンはこうです。営業部門がCRM連携のAIツールを個人カードで契約する。マーケティングがコンテンツ生成ツールを試用で入れて、そのまま本契約になる。情シスが全社向けにChatGPT Enterpriseを導入する。開発部門がCopilotを入れる——それぞれに理由があり、それぞれが有用です。しかし全体を把握している人間がいない状態になります。
ツール乱立が生む問題を整理します。
| 問題カテゴリ | 具体的な問題 | 見えにくい理由 |
|---|---|---|
| コストの不可視化 | 全社で月に何十万かかっているか把握できない。個人・部署のカード決済に埋もれている | クレジットカード明細に散在 |
| 機能の重複 | 「文書要約ができるツール」が3つ契約されている。それぞれ異なる部署が使い、比較すらされていない | 部署間でツールの情報共有がない |
| セキュリティリスクの分散 | どのツールに何のデータを入力しているか、情シスが把握できない。GDPR・個人情報保護法の観点でリスクのある使い方が見えない | 現場の自由導入に監視がない |
| 契約管理の欠如 | 誰が契約したか分からないツールが残り、使われていないのに課金が続く。担当者退職後も契約が生き続ける | 契約台帳がない |
| 学習効果の分散 | ノウハウが各ツールのユーザーに分散し、「このツールの使い方はAさんしか知らない」が複数発生する | 組織横断のナレッジ共有がない |
特に見落とされがちなのがセキュリティリスクです。「とりあえず便利なので使い始めた」ツールに、顧客データや社内機密情報を入力しているケースは珍しくありません。データの取り扱いポリシーを確認せずに使い続けることは、情報漏洩リスクに直結します。
（5）AIポートフォリオ管理の設計——「何を使っているか」を組織として把握する
ツール乱立への解決策は「一元管理ツールを導入する」ことではありません。まず必要なのは、現状の棚卸し（インベントリ）です。ネットワーク管理でCMDBを作る前に、まずすべての機器を発見するプロセスが必要なように、AIツールも「今何が動いているか」を把握することが出発点です。
ステップ①：AIツール・インベントリの作成
情シスまたはDX推進が主導し、全部署に対して「現在使用中のAI関連ツール・サービス」を申告させます。個人カード決済のものも含めて申告対象にすることが重要です。収集する情報は以下の項目です。
| 収集項目 | 目的 |
|---|---|
| ツール名・サービス名 | 重複・類似機能の発見 |
| 契約形態（個人/部署/法人） | 契約の把握・一本化判断 |
| 月次コスト | 全社コストの可視化 |
| 利用人数・利用頻度 | ROI評価・統廃合判断 |
| 主な用途 | 機能重複の発見 |
| 入力しているデータの種類 | セキュリティリスクの評価 |
| 契約更新日・解約可否 | 整理のタイミング設計 |
| 担当者名 | 管理責任の明確化 |
この棚卸しで、多くの組織が「把握していなかった契約」の存在に驚くことになります。初回は作業コストがかかりますが、半期に1回の定期棚卸しとして定着させることで、乱立の再発を防ぎます。
ステップ②：ツールの4分類マトリクスへの配置
インベントリができたら、各ツールを「活用度」×「戦略的価値」の2軸でマトリクスに配置します。
| 象限 | 特徴 | 推奨アクション |
|---|---|---|
| 高活用・高戦略価値（コアツール） | 多くの人が使い、業務インパクトが大きい | 重点投資・全社展開・サポート充実 |
| 低活用・高戦略価値（育成ツール） | 戦略的には重要だが普及していない | 活用推進施策・研修・担当者支援 |
| 高活用・低戦略価値（慣性ツール） | 使われてはいるが業務への貢献が不明確 | ROI再評価・代替可否の検討 |
| 低活用・低戦略価値（整理候補） | 使われておらず、戦略的価値も低い | 解約・統廃合・機能統合の検討 |
このマトリクスを使うことで、「何を手厚くするか」「何を整理するか」の経営判断が、感情論や担当者の好みではなく客観的な基準でできるようになります。
（6）ポートフォリオ整理の優先フレーム——統廃合の判断軸
ツールを整理する際、「廃止」に対して現場から抵抗が起きることは避けられません。「今のツールで慣れているのに変えたくない」「自分が選んだツールを否定されたくない」という反応は自然です。だからこそ、感情ではなく判断軸を先に合意しておくことが重要です。
統廃合の判断軸（優先順）
①セキュリティ・コンプライアンスリスク：まず最初に確認すべきは、そのツールが「使い続けていいか」という観点です。個人情報や機密データを入力しているにも関わらず、データ取り扱いポリシーが不明なツールは、活用度に関わらず即時対処が必要です。
②機能重複の整理：同じ機能を持つツールが複数ある場合、最も活用度・ユーザー満足度・コストパフォーマンスが高いものに一本化します。「2つあってもいい」という判断をする場合は、明確な使い分け基準を文書化します。
③コスト対効果：月次コストと利用人数・頻度から「1人あたり月額コスト」を計算し、業務インパクトと比較します。使われていないツールの解約は、組織として意思決定しやすい最もシンプルな整理です。
④戦略整合性：会社の事業戦略・DX方針と整合しているかを確認します。長期的に重要なツールには重点投資し、非整合なものは段階的に縮小します。
「影響を受ける現場」への説明設計
ツールを統廃合する際、現場への説明は「廃止する理由」だけでなく「移行後に何が使えるようになるか（または変わらないか）」をセットで伝えることが定着の鍵です。また、移行期間の設定と、代替手段のサポートを明確にすることで、現場の不安を軽減できます。
（7）人材・ツール二層のガバナンス設計
スキル移転とポートフォリオ管理は、それぞれ独立した施策ではなく、組織のAIガバナンスという一つの体制として設計する必要があります。特に規模が大きくなるほど、「誰が何を決めるか」のルールがないと、再び一点集中と乱立が始まります。
AIガバナンスの3層構造
| 層 | 担い手 | 役割 | 主な意思決定 |
|---|---|---|---|
| 経営層 | CIO/CDO・経営会議 | 方針・投資・リスク管理 | 全社AI戦略、予算配分、セキュリティポリシー |
| 推進層 | 情シス・DX推進・AIギルド | 標準化・評価・横展開 | ツール承認基準、研修設計、ポートフォリオ管理 |
| 現場層 | 各部門担当者・ギルドメンバー | 活用・改善・ナレッジ共有 | 業務での活用方法、課題の吸い上げ、事例共有 |
特に「推進層」が機能しない組織では、経営が方針を出しても現場に届かず、現場が成果を出しても経営に見えません。DX推進部門や情シスが「警察（禁止する役）」ではなく「触媒（広める役）」として機能する設計にすることが、AIガバナンスが形式的にならない条件です。
新規AIツール導入の承認フロー
ツール乱立の再発を防ぐには、新規ツールを導入する際の承認フローを整備することが必要です。ただし、これを複雑にしすぎると現場が申請を避けてサイレントな導入が増えます。シンプルに保つことが重要です。
推奨する最小フローは次の通りです。
① 現場が「AIツール導入申請」をフォームで提出（ツール名・用途・入力データの種類・月次コスト・利用人数）
② 情シスがセキュリティチェック（データ取り扱いポリシー確認・既存ツールとの重複確認）を実施。1週間以内に判断
③ 承認の場合、ポートフォリオ台帳に登録して管理開始
④ 非承認の場合、理由と代替案を提示
承認フローを設けることで、「知らないうちに入っていたツール」がなくなります。また、申請の際にセキュリティを確認する習慣が現場に根付くことも副次効果として期待できます。
（8）セルフ診断チェックリスト
DX推進・情シス・経営の方が、自組織の現状を診断するためのチェックリストです。「✗」が多い項目が、優先的に手をつけるべき課題です。
A. AI人材・スキル分散
| チェック項目 | 確認できたか |
|---|---|
| AI活用ノウハウが特定の1〜2人に依存しておらず、複数の社員が自律的に使いこなせている | ○ / ✗ |
| 有効なプロンプト・ワークフローが文書化・共有されており、担当者が変わっても引き継げる | ○ / ✗ |
| 部門横断でAI活用事例を共有する場・仕組みが定期的に機能している | ○ / ✗ |
| AI活用スキルの習得・向上が、人事評価や業務目標に何らかの形で組み込まれている | ○ / ✗ |
B. AIツール・ポートフォリオ管理
| チェック項目 | 確認できたか |
|---|---|
| 全社で利用中のAIツール・サービスの一覧（契約形態・コスト・用途・利用人数含む）が把握できている | ○ / ✗ |
| 同一・類似機能のツールの重複が特定されており、統廃合の方針が検討されている | ○ / ✗ |
| 新規AIツールを導入する際の申請・承認フローが整備されており、サイレント導入が起きにくい | ○ / ✗ |
| 各ツールへの入力データの種類が把握されており、セキュリティ・コンプライアンスリスクが評価されている | ○ / ✗ |
C. ガバナンス体制
| チェック項目 | 確認できたか |
|---|---|
| AIの活用方針・禁止事項・セキュリティポリシーが文書化されており、全社員に周知されている | ○ / ✗ |
| AIポートフォリオと人材育成の状況が経営レベルで定期的にレビューされている | ○ / ✗ |
| AI活用の推進と管理（標準化・リスク管理）を担う推進層（情シス・DX推進等）が機能している | ○ / ✗ |
判定の目安：「○」が9個以上——人材・ツール両面のガバナンスが整っており、活用の深化フェーズに進める。「○」が5〜8個——部分的な整備が必要。最もリスクの高い「✗」から着手する。「○」が4個以下——人材依存とツール乱立が複合的に組み合わさっている可能性が高い。まずインベントリ作成と担当者依存の可視化から着手することを推奨する。
（9）よくある質問（Q&A）
Q1. AI担当者を増やす予算がありません。スキル移転から始めるべきですか？
その通りです。増員より先にスキル移転に取り組む方が、コストも低く即効性があります。まず担当者のノウハウをプロンプト・ライブラリに落とし込む作業から始めてください。これは追加コストがほぼゼロで着手でき、担当者への集中を即座に緩和します。増員はその後の議論です。
Q2. AIツールのインベントリ作成を呼びかけても、現場が申告しません。どうすればよいですか？
申告しない理由は多くの場合、「申告すると禁止されるのではないか」という不安です。まず「申告イコール取り締まり」ではなく「状況を把握してサポートするため」というメッセージを経営・情シスから明確に発信することが重要です。また、申告フォームをシンプルにし、回答の所要時間を5分以内に抑えることも申告率を上げる実践的な工夫です。
Q3. AIギルドを作っても、業務が忙しい社員が参加してくれません。
ギルドを「追加業務」として設計しているのが原因です。参加インセンティブを設計し直してください。有効なアプローチは、①ギルドでのノウハウ共有が自分の業務を楽にする体験を作る（自分の課題が解決される場にする）、②参加に業務時間を使うことを上司が認める、③活動実績が評価・称賛につながるルートを作る、の3つです。「参加してほしい」よりも「参加すると自分が得をする」設計にすることが鉄則です。
Q4. 現場が使い慣れたツールを廃止しようとすると激しく反発されます。
感情的な反発は、「廃止の理由」より「移行後の世界」が見えていないことから来ることが多いです。廃止の通知と同時に、①移行先ツールの何が優れているか、②現在のツールで行っている作業が移行先でできること（または別の方法で対応できること）、③移行支援のサポート体制を明示することで、反発は大きく和らぎます。また、ツール廃止の「猶予期間」（例：3ヶ月）を設けることも有効です。
Q5. 中小企業でも「AIポートフォリオ管理」が必要ですか？社員10人規模の会社でも？
規模を問わず、「どのツールを誰が使い、月いくらかかっているか」が把握できていない状態はリスクです。10人規模であればスプレッドシート1枚で十分です。ツール名・用途・コスト・担当者・更新日を並べた「AIツール台帳」を一度作れば、それがポートフォリオ管理のスタートです。大企業向けの複雑な仕組みは不要ですが、「把握する習慣」は組織規模に関わらず必要です。
まとめ——「人とツールの両方を面で管理する」
AI活用が定着・拡大フェーズに入った組織が直面する「人材依存」と「ツール乱立」は、どちらも点単位の運用が積み重なった結果です。解決は技術ではなく、組織設計とガバナンスの問題です。
1. スキルは組織の資産にする。担当者のノウハウをプロンプト・ライブラリに外部化し、研修と横断コミュニティ（ギルド）を通じて組織全体に広げる。AI活用スキルを評価に組み込むことで、学習インセンティブを設計する。
2. ツールは棚卸しから始める。まず「何が動いているか」のインベントリを作る。次に活用度×戦略価値の2軸でマトリクスに配置し、統廃合・重点投資の判断軸を合意する。新規導入の承認フローで再発を防ぐ。
3. ガバナンスを「禁止」ではなく「触媒」として設計する。経営・推進・現場の3層で役割を分け、推進層が現場の活用を支援し、経営に成果を見せるサイクルを回す。管理の目的はAI活用の抑制ではなく、安全で持続可能な拡大を実現することにある。
次回・連載⑨では、「AIの活用効果が見えない／成果を経営に説明できない」という問題を扱う予定です。AI活用のROIをどう定義し、どう計測し、経営に対してどう報告するか——「やっているのに認められない」状況への処方箋をお届けします。
免責事項：本記事は2026年7月時点の情報および一般的な実践知に基づく情報提供であり、特定の製品・サービス・組織構成における効果を保証するものではありません。また、法的・技術的助言ではありません。実際の組織設計・ガバナンス設計・ツール選定は、自社環境・適用法令・コンプライアンス要件に照らして検討し、必要に応じて専門家にご相談ください。
コメント