結論：利用率が上がらないのは「操作が難しいから」ではなく「自分の業務への翻訳がないから」である

AIシステムが予定どおり完成し、検収も通った。それなのに、日常的に使っているのは元々ITに詳しい一部の社員だけで、大多数は最初に一度触ったきり戻ってこない——投資回収の計算が、利用率の低さで根本から崩れる失敗である。原因を「現場のITリテラシー不足」と片付け、操作研修を追加しても利用率は動かない。利用者が必要としているのは操作方法ではなく、「自分の業務のどの場面で使えば、何がどれだけ楽になるか」という翻訳だからである。

  • 利用率が低い真因は操作スキルではなく、業務別ユースケースへの「翻訳」の欠如であることが多い。
  • 教育＝操作研修ではない。ユースケースの翻訳・最初の成功体験・質問できる場・利用ルールの周知の四つをセットで設計する。
  • 最初の一回で「得をした」体験を作れるかが、その後の継続利用をほぼ決める。
  • 教育・定着支援は納品後に現場へ丸投げされやすい。発注時に要件とスケジュールへ含めておく必要がある。
  • 教育は一斉研修一回で終わらせず、対象者×内容×タイミングの表で段階的に設計する。

この連載は「AI開発発注の失敗図鑑」として、発注側がつまずく論点を一つずつ分解している。第27回となる本稿は、利用者側のスキルと教育の設計に焦点を絞る。似た症状を扱った回との違いを先に示すと、チャットボットが使われない失敗は導線や業務フロー側の設計、つまり「使われる場所に置かれているか」の問題を扱い、運用者不在の失敗はシステムを管理・改善する側の体制を扱った。本稿はその両方が整っていても残る「使う側の人間が、使う理由と使い方を自分の業務の言葉で理解しているか」という教育・リテラシーの設計を扱う。また段階的ロールアウトの失敗で扱った展開設計とは、各段階に教育を組み込むという形で接続する。

なぜ完成したAIが一部の社員にしか使われないのか

「使い方が分からない」は表面の症状にすぎない

利用率の低さをヒアリングすると、現場からは「使い方が分からない」という声が返ってくることが多い。これを字義どおり受け取って操作マニュアルや研修を増やしても、利用率はほとんど変わらない。実際に起きているのは、操作が分からないのではなく、「自分の仕事のどの場面でこれを使うと得をするのか」が分からない、という状態だからである。

汎用的なAIツールほどこの問題は深刻になる。「何でもできます」という説明は、利用者にとって「何に使えばいいか自分で考えろ」と同義である。営業担当には営業の言葉で、経理担当には経理の言葉で、「この業務のこの工程で、こう入力すると、この時間が浮く」という形まで具体化されて初めて、利用者は使う理由を持つ。この具体化を本稿では「翻訳」と呼ぶ。翻訳は開発会社が自動的にやってくれる作業ではない。業務を知っているのは発注側であり、翻訳の主体は発注側にしかなれない。

最初の一回の体験が、その後の利用をほぼ決める

利用者がAIに触れる最初の一回で「思ったような答えが出なかった」「自分の業務には関係なさそうだった」と感じると、二回目は来ない。逆に最初の一回で「いつも30分かかる作業がすぐ終わった」という体験があれば、教えなくても使い続ける。つまり定着の勝負は、リリース後の長期的な啓蒙ではなく、最初の接触をどう設計するかでほぼ決まる。

ところが多くの導入では、最初の接触が「全社向け案内メールとログインURLの配布」だけで終わる。利用者は自由に触って、自由に失望する。最初の一回を成功体験にするには、業務別に「まずこれを試してほしい」という具体的な一手（実際の業務データに近いサンプルと期待される出力）まで用意しておく必要がある。

教育が「開発会社任せ」「納品後回し」になる構造

教育・定着支援が手薄になるのは、発注時の要件に入っていないからである。開発契約の範囲は通常システムの構築までで、操作説明会が一回付く程度のことが多い。開発会社は業務の中身を発注側ほど知らないため、操作説明はできても業務への翻訳はできない。一方の発注側は「納品されてから考える」と先送りし、納品後は現場の管理職へ「使わせておいて」と丸投げされる。誰の仕事でもなくなった教育は実施されず、利用率だけが静かに低迷する。

教育を機能させるには、発注時点で「教育・定着支援に何を含めるか」「開発会社と発注側のどちらが何を担うか」「いつ実施するか」を要件とスケジュールに明記するしかない。後から付け足す予算と工数は、ほとんどの場合確保されない。

教育として設計すべき「4点セット」

操作研修を何度繰り返しても埋まらない部分を、次の四つに分けて設計する。

第一に、業務別ユースケースへの翻訳である。部門・職種ごとに「この業務のこの工程で使う」「入力はこれ、出力はこう使う」「浮く時間はこれくらい」を一覧にする。全社共通の説明資料を一本作るのではなく、対象部門の数だけ翻訳を作るのが原則である。翻訳作業には各部門の業務に詳しい人の関与が不可欠で、ここが発注側の最大の役割になる。

第二に、最初の成功体験の設計である。利用者が最初に試す一手を部門ごとに指定し、実際の業務に近い題材で「確かに楽になった」と感じられる体験を意図的に作る。展開の単位を区切って、先行部門で成功パターンを確かめてから広げる進め方は、段階的ロールアウトの各段階に教育を組み込むことと同じ話である。段階展開は単にリスクを抑える手順ではなく、「前の段階で得た翻訳と成功体験を、次の段階の教育材料にする」仕組みとして使える。

第三に、質問できる場である。研修の場では出ない「こんな使い方をしていいのか」「うまくいかなかったがなぜか」という疑問を、日常的に投げられる場所（チャットの質問チャンネル、部門ごとの世話役、定期の相談会など）を用意する。質問が集まる場所は、そのまま「現場がどこでつまずいているか」の観測点にもなり、ユースケース翻訳の改善材料になる。

第四に、利用ルールの周知である。何を入力してよく、何を入力してはいけないか、出力をどこまで業務に使ってよいかが曖昧なままだと、慎重な社員ほど「怖いから使わない」を選ぶ。利用率の低さの一部は、ルール不明瞭による萎縮である。社内方針として対象範囲・入力禁止情報・レビュー義務・ログ保存・停止条件・更新タイミングの6項目を文書化する考え方は利用率の先にある社内AI方針の設計で整理している。なお、総務省・経済産業省の「AI事業者ガイドライン（第1.2版）」（令和8年3月31日公表）は、AIの利用者側に対してもログの記録・保存や教育・リテラシー向上の重要性を示しており、利用者教育は定着施策であると同時にガバナンス上の備えでもある。

この四つはどれか一つでは機能しない。翻訳がなければ研修は他人事になり、成功体験がなければ翻訳は絵に描いた餅になり、質問できる場がなければ最初のつまずきで脱落し、ルールが曖昧なら使うこと自体が躊躇される。セットで設計して初めて、利用率は「詳しい一部」から「業務で使う大多数」へ広がる。

教育設計の要素表（対象者×内容×タイミング）

教育は「全社員向け研修を一回」ではなく、対象者ごとに内容とタイミングを変えて設計する。発注時にこの表を埋めておくと、要件とスケジュールへの落とし込みがそのまま進む。

対象者教育の内容タイミング
経営層・部門長導入目的と期待効果、利用率と効果の報告の見方、自部門での旗振りの役割発注決定時と展開開始前
先行部門の利用者業務別ユースケースの翻訳、最初に試す一手、利用ルール、質問先リリース直前〜直後（触れる環境とセットで）
部門の世話役（キーユーザー）一段深い使いこなし、つまずきの収集方法、質問への一次対応先行展開の前（一般利用者より先に）
後続部門の利用者先行部門で実証済みのユースケースと成功事例、利用ルール各段階の展開直前（先行の実例を教材に）
情シス・推進担当利用状況の見方、質問・つまずきの集計、ユースケース翻訳の更新方法リリース前と定着期の定期見直し時

この表で重要なのは三点である。第一に、世話役を一般利用者より先に育てること。質問できる場は、答えられる人がいて初めて機能する。第二に、後続部門の教育材料は先行部門の実例で作ること。作り込んだ想定ユースケースより、隣の部門の実話のほうがはるかに説得力がある。第三に、教育をリリース時の一回で終わらせず、定着期に翻訳とルールを更新する役割を決めておくことである。

利用定着を発注要件に入れる場合は、次のように数字で区切ると曖昧になりにくい。

時期見る指標判断
リリース後7日初回ログイン率、最初の利用完了率、質問件数初回体験でつまずく部門を特定し、追加説明を入れる
リリース後30日週1回以上の継続利用者数、部門別利用率翻訳済みユースケースが足りない部門を洗い出す
リリース後60日利用頻度、業務時間削減の自己申告、問い合わせ削減などの初期効果教育内容と利用ルールを更新し、後続部門へ展開する
リリース後90日KPIへの寄与、定着しない部門の理由、追加開発要望継続投資・機能改善・教育継続の判断材料にする

この7日・30日・60日・90日の節目を置くと、利用者教育は「研修をしたか」ではなく「定着したか」で評価できる。第29回で扱う事業KPIの前段として、利用率と初期効果を短い周期で追うことが重要である。

発注前に確認すべきこと（チェックリスト）

  • 利用者の範囲（部門・職種・人数）と、部門ごとの想定ユースケースを発注前に洗い出したか。
  • 教育・定着支援が見積と契約の範囲に含まれるか、含まれる場合は何を指すか（操作説明会一回か、定着伴走か）を確認したか。
  • 業務別ユースケースの翻訳を誰が作るか（発注側の業務有識者の関与）を決めたか。
  • 利用者が最初に試す一手と、成功体験になる題材を部門ごとに用意する計画があるか。
  • 質問できる場（チャンネル・世話役・相談会）と、世話役を先に育てる日程を展開計画に入れたか。
  • 入力禁止情報やレビュー義務などの利用ルールを、リリース前に周知する段取りがあるか。
  • 段階展開の各段階に教育を組み込み、先行部門の実例を後続の教材にする設計になっているか。
  • 定着期にユースケース翻訳と教育内容を見直す担当とタイミングを決めたか。

GXOに相談する前に整理しておくとよい情報

相談前に次を整理しておくと、教育・定着の議論が具体化しやすい。

  • 対象システムと利用者の範囲（部門・職種・人数、ITスキルのばらつき）
  • 現時点で想定している部門別の使いどころ（曖昧なら曖昧なままでよい）
  • 過去に導入したツールで定着しなかった経験と、その際の教育のやり方
  • 社内の利用ルール・AI方針の整備状況（入力禁止情報やレビュー義務が文書化されているか）
  • 教育・定着にかけられる予算・工数と、社内で世話役を担えそうな人の有無

導入の入口で「そもそもどの業務に効くのか」から切り分けたい場合は、AI導入可否アセスメントで対象業務と効果の見込みを整理してから教育設計に入ると、翻訳すべきユースケースが明確になる。開発と定着支援を一体で設計したい場合は、AI導入支援で要件定義の段階から教育・定着を織り込む形が現実的である。

関連記事

よくある質問

Q1. 操作研修をすでに実施したのに利用率が上がらないのはなぜか。

操作研修は「どう動かすか」を教えるが、利用者が知りたいのは「自分の業務のどこで使えば得か」だからである。部門・職種ごとに業務別ユースケースへ翻訳し、最初に試す一手と成功体験を設計しない限り、操作を知っていても使う理由がない状態は変わらない。研修の回数ではなく、翻訳の有無を見直すべきである。

Q2. 教育やユースケースの翻訳は開発会社に任せられないのか。

操作説明や技術的なQ&Aは開発会社が担えるが、業務への翻訳は発注側にしかできない。どの業務のどの工程に効くかを知っているのは業務をしている側だからである。現実的な分担は、開発会社が機能と使い方の素材を提供し、発注側の業務有識者がそれを部門の言葉に翻訳する形であり、この分担と工数を発注時に決めておく必要がある。

Q3. 教育はいつ実施するのが効果的か。

一斉研修を一回行うより、対象者ごとにタイミングを分けるのが効果的である。世話役は一般利用者より先に育て、利用者への教育は実際に触れる環境が整うリリース直前〜直後に行い、後続部門には先行部門の実例を教材として展開直前に届ける。さらに定着期には、集まった質問とつまずきをもとに翻訳と教育内容を更新する。

Q4. 利用ルールを厳しくすると、かえって使われなくなるのではないか。

曖昧なルールのほうが利用を妨げる。何を入力してよいかが不明確だと、慎重な社員ほど「怖いから使わない」を選ぶためである。入力してよい情報と禁止情報を具体例で示し、なぜ禁止かの理由とセットで周知すれば、利用者は安心して使える範囲を把握できる。ルールの明確化は萎縮ではなく、利用の前提条件である。

発注前チェックリスト（全30項目・無料）：本連載の30類型を1枚で点検できるチェックリストを無料ダウンロードできます。発注前の社内確認・稟議の添付資料にご利用ください。

完成したシステムの価値は、使われて初めて発生する。利用者教育とAIリテラシーの設計を「納品後に現場で何とかする」案件から「発注時に要件へ入れる」案件に変えるだけで、投資回収の確度は大きく変わる。教育・定着まで含めた要件の組み立てに不安があれば、無料相談から、利用者の範囲と業務の棚卸しを一緒に始めていただきたい。

出典