「社員にAIを覚えてもらいたい」というご相談は増えています。一方で、外部研修を受けさせたものの、終わったあとに何も残らなかったという話も同じくらい聞きます。

本記事は、当社が続けている伴走レクチャーの実例です。少人数で運営している会社で、プログラミング経験のない担当の方に、定例の場でAI活用を指導してきました。

結論から書くと、この案件で本当に難しかったのは「作れるようになること」ではありませんでした。作れるようになった先に、3つの壁がありました。研修の設計を考えている方には、そこが一番参考になるはずです。

なお、お客様が特定されないよう、企業名・業種・具体的な数値は伏せ、状況の説明にとどめています。

前提：教える相手が、すでに走り出していた

対象の方は少人数の運営体制のなかで実務を回している担当で、プログラミングの経験はありません。現職に参画した直後から、AIツールを独学で触り始めていた方です。

最初の定例の時点で、すでに次の状態にありました。

  • AI開発ツールを自分でインストール済み
  • 外部サービスと連携するアプリの開発に着手済み
  • 社内向けのツールをいくつか自作し、実際に使っている

当初は「これからAIを使い始める方向けの入門レクチャー」を想定していましたが、初回の冒頭で方針を変えました。基礎から順に教える形は、この方には遅すぎます。

そこで、教科書的なカリキュラムをやめ、本人が今まさに詰まっている箇所を毎回その場で外していく形に切り替えました。題材は常に、本人の実務です。

この切り替えは正解でした。研修が終わった時点で「学んだ気がする」ではなく、動くツールが手元に残るからです。

何を教えたか：非エンジニアが最初に覚えるべき5つ

初期に扱った内容のうち、コードの書き方は1つもありません。実際に効いたのは以下でした。

1. まず設計を相談する（プランモード）

いきなり作らせず、最初に「どう作るか」をAIと相談する。方針・技術選定はAIに任せてよい、という感覚をつかむのが第一歩です。

2. 設計図をテキストで置いておく

プロジェクトのルールや前提を書いたテキストファイルを、作業フォルダの直下に置いておく。AIが毎回それを読むため、新しいセッションを開いても前提を説明し直さずに済みます。増やしすぎると人間側が管理できなくなるので、短く保つのがコツです。

3. 会話が長くなったら、リセットする

AIが覚えていられる量には上限があります。上限に近づくと自動で圧縮がかかりますが、その際に「忘れてはいけないことまで忘れる」ことがあります。圧縮を待たず、区切りのいいところで新しいセッションを開く方が安定します。

4. AIに外部サービスを操作させる3つの方法と、その違い

APIキーを渡す・ブラウザを直接操作させる・認証連携を使う、の3通りがあり、安全性と使える場面が違います。特にAPIキーは漏れると誰でもアクセスできてしまうため、画面共有時に映さないといった基本の注意が要ります。

5. 最初のうちは、必ず人が1回チェックを挟む

メール送信のように外部に影響が出る処理は、自動で最後まで走らせない。この習慣が、後述する3つ目の壁に直結します。

成果：自動化が実務に組み込まれて動いている

数ヶ月の伴走で、業務のなかで実際に回っているものが出てきました。

毎日届く定型のメールから必要な情報を抜き出し、複数名で共有しているファイルへ転記する作業がありました。これが決まった時刻に自動で実行されるようになっています。

ほかにも、画像から表データへ起こすツール、社内のタスク管理ツールが本人の手で作られ、使われています。

プログラミング経験のない方が、実務のかたわらでここまで到達しているのは十分な成果です。しかし、ここからが本題でした。

壁①：作ったのに、本番で使えない

途中で稼働状況を棚卸ししたところ、はっきりした傾向が出ました。

ツール 状態
定型メールからの転記 稼働中
画像から表データへの変換 稼働中
タスク管理ツール 稼働中
顧客への一斉送信ツール 完成・本番未使用
外部サイトへの投稿自動化 作った・ほぼ使っていない
文章の書き分け 失敗して放置
SNS連携 凍結中

作ったものの半分以上が、本番で回りきっていません。しかも止まっている理由が、精度や技術的な不具合ではありませんでした。

一斉送信ツールは完成しています。それでも使われていない理由は「誤作動したらどうしよう」「そもそも本当に実行されるのか分からない」という不安でした。顧客全員に誤った内容を送る事故は、取り返しがつきません。だから怖くて押せない。

これは技術の問題ではなく、信頼の問題です。そして信頼は、動くところを見せるだけでは生まれません。

壁②：自動化したのに、速くならない

もう1つ、示唆的な失敗がありました。

外部サイトへの投稿作業を、AIにブラウザを操作させる形で自動化しました。実装は完了し、繰り返し使える形にもなっています。

ところが、実際に走らせると手作業とほとんど変わらない時間がかかりました。加えて、ブラウザを立ち上げて操作させるため、PCのメモリを使い切ってしまい、他の作業ができなくなります。

結果、ほぼ手動に戻っています。

原因ははっきりしていて、この方のPCがメモリの少ない機種だったことです。AIにブラウザを操作させる方式は、画面を読み取りながら判断するため、環境の制約をまともに受けます。

ここから得た教訓は明快です。自動化の可否は、業務の内容だけでなく、その人のPC環境で決まる。研修の初回に環境を確認しておかないと、実現できない提案をしてしまいます。

壁③：失敗したときに、誰も気づかない

3つの壁のうち、最も本質的だったのがこれです。

稼働している転記の処理には、実は問題がありました。正常に動いたときも、失敗したときも、何も通知が来ないのです。過去に実行が飛んでいたことがありましたが、気づいたのは後日でした。

この処理が取りこぼすと、顧客への対応が漏れます。実害が外に出ます。

同じ構図が、別の箇所にもありました。自動返信の控えが担当者側で迷惑メールフォルダに振り分けられており、問い合わせに気づけないケースがあったのです。

つまり、この方が抱えていた課題は「AIツールを作れないこと」ではなく、作ったものが黙って止まることに耐えられないことでした。壁①の「怖くて使えない」も、根は同じです。

対策として取り組んでいるのは、派手な機能ではありません。

  • 処理が終わったら、成功でも失敗でも必ず通知を飛ばす
  • 通知は担当者全員に届くようにする
  • 外部に影響が出る処理は、実行前に人の承認を挟む
  • 通知経路そのものを二重化する（1つが詰まっても気づける）

自動化の価値は、作業を減らすことよりも「見なくてよくなること」にあります。見ていないと不安なままなら、作業時間は減っていません。

この事例から、研修を設計する方へ

数ヶ月の伴走から、再現性のある形にまとめると次のようになります。

1. 相手の現在地を、初回に必ず測る

すでに走り出している人に入門講座をやると、時間を無駄にします。逆に、環境や前提を確認せずに進めると、実現できない提案をします。測るべきは、経験の有無・PCのスペック・すでに作ったもの・今まさに困っていることの4点です。

2. 題材は、必ず本人の実務から取る

汎用的な演習課題は、終わった瞬間に消えます。本人の業務を題材にすれば、研修の成果物がそのまま業務資産になります。

3. ゴールを「作れるようになること」に置かない

作ることは、以前よりはるかに簡単になりました。研修の合否は「しばらく経っても、その自動化が回り続けているか」で見るべきです。この基準にすると、教える内容が変わります。通知・エラー処理・人の承認といった地味な部分に、時間を割くようになります。

4. 単発の講座ではなく、間隔を空けた定例にする

1日集中型の研修では、壁①〜③に到達しません。壁は、実際に本番で使おうとした瞬間に初めて現れるからです。作る→使ってみる→詰まる→次回持ち込む、というサイクルを回せる形が必要です。

まとめ

  • プログラミング経験がなくても、伴走があれば実務の自動化を自作できる段階に到達する
  • ただし本当の壁は「作れない」ではなく、「怖くて本番に載せられない」「速くならない」「止まっても気づけない」の3つ
  • 研修の合否は、作れるようになったかではなく、しばらく経っても回り続けているかで測る
  • そのために教えるべきは高度な技術ではなく、通知・承認・環境の見極めといった運用の設計

当社の導入研修は、この形を標準にしています。1人あたり60分×4回で、御社の実際の業務を題材に進めます。研修後の定着まで見る伴走支援もご用意しています。

他の2つの導入パターンについては、中小企業のAI導入は、実際には3つの形しかないをご覧ください。