生成AIの浸透状況を診断してほしい、と依頼を受けるとき、まず何を見るかで診断の質が決まります。ログを見るだけでは足りず、ヒアリングだけでも足りず、業務プロセスの棚卸しがなければ根本原因は見えません。DX 推進担当として社内で自ら診断を進める場合、あるいは外部支援を選ぶ判断材料が欲しい場合、最低限見るべき10項目を整理します。
項目は、ログ観察・ヒアリング・業務プロセスの3方向に分かれます。10項目すべてを2週間で見きるのが標準的な診断のスコープです。
10項目の全体像
| # | 項目 | 方法 |
|---|---|---|
| 1 | 利用ログの全体像 | ログ観察 |
| 2 | 部門別・役職別の利用率分布 | ログ観察 |
| 3 | 用途別のプロンプト分類 | ログ観察 |
| 4 | 権限設計の実態 | 情シスヒアリング |
| 5 | 現場担当者の使用状況と諦めた理由 | 現場ヒアリング |
| 6 | 推進担当・情シスの負荷状況 | 推進側ヒアリング |
| 7 | 対象業務プロセスの棚卸し | 業務プロセス観察 |
| 8 | 業務側で連携が必要なマスタ・データの状態 | 情シス+業務ヒアリング |
| 9 | 経営層の期待値と現実のギャップ | 経営ヒアリング |
| 10 | 既存KPI との整合 | 資料レビュー |
10項目を順に見ていきます。ログ観察系（1〜3）から始めて全体像を掴み、ヒアリング系（4〜6, 9）で理由を掘り、業務プロセス系（7〜8）で根本原因に迫る、というのが実務的な進め方です。
項目1〜3: ログ観察系
項目1: 利用ログの全体像
直近60〜90日分の利用ログを、管理コンソール（M365、ChatGPT Enterprise の管理画面、社内 ChatGPT 環境のAPIログ）から取り出します。総ユーザー数、アクティブユーザー数、週次・月次のアクティブ率の推移。まずここで「そもそも使われているか」の輪郭が見えます。
項目2: 部門別・役職別の利用率分布
組織全体のアクティブ率が20%でも、内訳を見ると営業部門は40%、経理部門は5%、といった偏りがあります。この分布を可視化することで、「どの部門から浸透が止まっているか」の優先順位づけができます。役職別も見ると、管理職と実務担当のどちらが使っているか、が分かります。
項目3: 用途別のプロンプト分類
プロンプトの内容を、6〜8カテゴリ（情報検索、文書作成、業務判断支援、顧客対応、コード処理、学習）に分類します。ログ全件は非現実的なので、月次200〜500件のサンプリングを別のLLMで分類するのが実務的です。ここで「経営価値の高い用途にどれだけ使われているか」が見えます。
項目4〜6, 9: ヒアリング系
項目4: 権限設計の実態
情シスへのヒアリングで、AIから業務データがどこまで見えるかを確認します。Copilot なら Graph API 経由の Dynamics/Salesforce 接続の可否、社内 ChatGPT なら RAG に載せているデータソースと権限設計。「使えない」の裏には、権限設計の不整合が潜んでいることが多いです。
項目5: 現場担当者の使用状況と諦めた理由
対象部門の担当者5〜10名に30分ずつヒアリングします。「実際にどう使っているか」「試したが期待した回答にならなかったケース」「今は使っていない理由」の3点。ここで「1度誤答を経験して離脱」「プロンプトの書き方が分からず諦め」といった離脱の理由が具体的に見えます。
項目6: 推進担当・情シスの負荷状況
推進担当と情シスに、AI関連の相談件数、平均対応時間、返信までのリードタイム、を聞きます。相談の集中と滞留の実態が数字で見えると、「兼任1名で回っていない」の構造的な状況が明らかになります。
項目9: 経営層の期待値と現実のギャップ
経営スポンサーへの30分ヒアリングで、AI導入時に期待した成果、現時点で見えている成果、四半期で報告してほしい指標、を確認します。ここが空欄だと、いくら浸透が進んでも「経営が納得する報告」ができません。
項目7〜8: 業務プロセス系
項目7: 対象業務プロセスの棚卸し
AI を埋め込みたい業務プロセスを1〜3件選び、SOPに沿って手順を全部書き出します。営業なら商談準備〜提案書作成〜商談後の議事録、経理なら月次締めの仕訳判断〜レビュー〜報告書作成。この棚卸しがあると、「業務のどの瞬間にAIを呼ぶべきか」のトリガー設計ができます。
項目8: 業務側で連携が必要なマスタ・データの状態
項目7の業務プロセスで参照するデータ（顧客マスタ、勘定科目マスタ、商品マスタ、業務履歴）が、最新か、AIから見えるか、を確認します。「マスタが2年前のダンプ」「顧客情報が3つのシステムに分散」といった状態は、AI活用のボトルネックとして頻繁に見つかります。
項目10: 既存KPI との整合
既存の業績KPI（営業なら受注率、経理なら締め所要日数）と、AI浸透KPIをどう整合させるか、を資料レビューで確認します。切り離されたKPIだと、AI活用の成果が既存業務評価に反映されず、現場のインセンティブが働きません。既存KPI との紐付けが、浸透の持続性を左右します。
診断の出力粒度
10項目を2週間で見きった診断の出力は、次の粒度で仕上げます。
| セクション | 内容 | 分量 |
|---|---|---|
| 観察サマリ | 10項目それぞれで見えた数字と実態 | 20〜30ページ |
| 見立て | 浸透しない主要原因（5つの構造的原因のうちどれが該当か） | 3〜5ページ |
| 優先順位 | 手をつけるべき順に整理 | 1〜2ページ |
| 次の一手の候補 | 打ち手のオプション、コストと期待効果の見立て | 3〜5ページ |
診断はあくまで「見立て」までで、打ち手の設計と実行は別工程です。診断だけで社内の投資判断が進められる粒度を意識するのが、良い診断の条件です。
社内で進める場合と、外部支援を使う場合
10項目を社内リソースで進めることは可能です。ただ、ヒアリングの中立性と、既存の失敗パターンの参照、という点で外部支援には合理性があります。
| 軸 | 社内で進める | 外部支援を使う |
|---|---|---|
| 時間 | 推進担当が2〜3週間集中できるなら可能 | 2週間で仕上がる |
| ヒアリングの中立性 | 上下関係が絡み、本音が出にくい | 初対面なので本音が出やすい |
| パターン参照 | 自社のケースしか知らない | 類似案件を10社以上見ている前提で類推できる |
| コスト | 内部人件費のみ | 25万円前後（DE-STK のAI浸透スコア診断の場合） |
まとめ
AI浸透スコア診断は、ログ観察・ヒアリング・業務プロセスの3方向10項目で構成します。ログだけでも、ヒアリングだけでも、業務プロセスだけでも足りず、3方向を合わせて初めて構造的な原因が見えます。診断の出力は「見立て」までで、打ち手の設計は別工程として分けるのが健全です。
「うちの場合はどこから手をつけるべきか」の見立てを掴みたい場合は、AI浸透支援 by DE-STKのAI浸透スコア診断（2週間・25万円）が入口として使えます。現状の利用実態、構造的な原因、次に打つべき手の候補まで、社内の投資判断に耐える粒度でお出しします。
あわせて読みたい
- 生成AI導入後の「使われない」を解消する：現場浸透の設計と実装
- Forward-Deployed Engineer（FDE）が去った後、AIプロジェクトを引き取る組織設計
- 生成AI浸透KPIの設計：アクティブ率・用途分布・成果指標の3層モデル
- Microsoft Copilotが営業部門で使われない典型3パターンと構造的原因
よくある質問
Q. 診断を2週間で見きるのは無理では？
A. 10項目を精密に見ようとすると2ヶ月以上かかりますが、それは診断ではなくコンサルティングです。2週間の診断は「見立てを出すための最小十分な観察」で、精密調査ではありません。ログ観察はまとめて数日、ヒアリングは15〜20名で1週間、業務プロセスは1〜2件で数日、が現実的な配分です。
Q. 診断だけで浸透しない主要原因が本当に分かりますか？
A. 主要原因の8割は10項目で切り分けられます。残り2割は、実際に打ち手を試して分かる「見えなかった要因」で、これは診断の範囲外です。診断は「次に何を試すか」の優先順位を出すもので、100%の因果特定は目的にしません。
Q. 外部支援の診断は、社内の反発を招きませんか？
A. 情シスや推進担当が「外部に評価される」と身構えるケースはあります。診断の目的が「批判ではなく、次の一手の材料集め」だと最初に共有し、成果物のドラフトを社内レビューにかけてから納品する運用にすると、反発は最小化できます。