非エンジニア部門(管理部)にAIを定着させる伴走設計の話

▼背景：エンジニアだらけの会社なのに、管理部だけAIが進まない

ある受託開発企業（社員150名規模）で、AI導入の伴走支援に入った。社員のほとんどがエンジニアで、開発部門はClaudeやCursorを日常的に使いこなしている。ところが管理部——人事・労務・経理・採用・営業事務を5人で兼務して回している少数精鋭の部門——だけは、AIがほとんど業務に入り込んでいなかった。

経営層の課題感はシンプルだった。「開発は勝手にAIを使いこなすのに、管理部は取り残されている。ここを何とかしたい」。

これ、実はかなり典型的な構図だ。同じ会社の中でもAIとの距離感は部門ごとに大きく違う。そして距離が遠い部門ほど、「じゃあ研修やろう」で片付けられて、結局定着しない。

▼「研修」をやっても、現場では使われない

今回まず決めたのは、これを「研修」と呼ばないことだった。最初から「伴走支援」というフレーミングを徹底した。

理由はこうだ。研修は「知識を渡して終わり」になりがちで、渡した知識が現場の業務に接続されないまま風化する。生成AIの使い方を1時間説明されても、翌週の請求書処理や求人票作成は何も変わらない——これが「AI研修あるある」だ。

渡すべきは知識じゃなくて、「自分の業務が実際に変わった」という体験のほうだ。両者を整理するとこうなる。

	研修	伴走
ゴール	知識を渡す	業務が変わる
進め方	一方向の説明	各自が自分の業務課題を持ち寄る
成果物	受講完了	自分の業務で動くエージェント
期間	単発で完結	継続してサイクルを回す

今回は月1回・各2時間・全4回のワークショップ形式で組んだ。単発ではなく、回を重ねながら各自の業務にAIを食い込ませていく設計だ。

▼伴走設計の5つのポイント

1. リテラシーのばらつきを「前提」に設計する

同じ会社でも、開発部門はほぼ毎日AIを触り、管理部は週2〜3回。このレベル差を無視して一律の内容をやると、片方が退屈し、片方が置いていかれる。両方から「時間の無駄だった」と思われる、最悪のパターンだ。

だから基礎（大規模言語モデルの仕組み、ハルシネーション、プロンプトの書き方）は丁寧にやりつつ、事例は各メンバーの実業務に紐づけて出した。「全員に同じことを教えない」のが伴走の入り口だ。

2. 初回のゴールは、欲張らない

初回に設定したゴールは、たった一つ。「エージェントを使えば業務が楽になりそうだ」というイメージを持ってもらうことだけだ。

実際、初回はメール作成AIを題材に、プロンプトを書く→エージェントとして登録する→動作確認する、までを目の前で実演した。抽象的な説明より、自分の業務に近いものが動く様子を1回見せるほうが、100倍伝わる。

3. 「宿題→フィードバック」のサイクルを回す

伴走の本体は、各自が自分の業務課題でエージェントを1つ作ってきて、それに対して具体的なフィードバックを返すサイクルだ。

たとえば「人事連絡を自動化するエージェント」「領収書を作成するエージェント」——各自が持ち寄った“作りかけ”に対して、プロンプトの分割の仕方、ステップの切り方、どこまでをAIに任せてどこからは既存の仕組み（VBA等）に寄せるか、を一緒に詰めていく。この「自分の業務での具体」に踏み込めるかどうかが、研修と伴走を分ける。

4. プロンプトビルダーで「自分で作れる」に持っていく

伴走のゴールは、こちらが毎回プロンプトを渡すことじゃない。参加者が自力でエージェントを作れるようになることだ。

そのために使ったのが、Microsoft 365 Copilotのエージェント作成機能（Agent Builder）と、いわゆる「プロンプトを作るプロンプト」だ。議事録作成エージェントを例に、「どういう業務を、どんな手順で任せたいか」を書けば、それを整ったプロンプトに起こしてくれる流れをデモした。

5. デモは、相手の“実データ”でやる

汎用的なサンプルでデモしても、正直あまり刺さらない。効いたのは、参加者が実際に関わっている固有名詞をその場で入れてライブで動かしたときだった。

ある回では、大学リサーチ用のエージェントを、参加者本人が実際に採用で関わっている大学名を入れてその場で走らせた。抽象的なサンプルでは「ふーん」だった反応が、自分の業務そのものが動いた瞬間に「これは使えそう」に変わる。デモは相手の現実に寄せるほど強い。

▼正直、ここで詰まった

ここまで書くと綺麗に進んだように見えるけど、実際はそんなことない。詰まった話も書いておく。ここが一番、これからやる人の役に立つはずだ。

宿題、7人中2人しか埋まってなかった

「次回までにエージェントを1つ作ってくる」という宿題を出したものの、事前シートに記入があったのは7人中2人だけ。全員分の宿題発表を前提に組んだ進行が、開始直前に崩れた。

その場でやったのは、進行の組み替え。「作ってこなかった人には、プロンプトビルダーの説明を先にして、その場で一緒に作る時間にしよう」と方針を切り替えた。宿題をやってこなかったこと自体を責めるのではなく、「じゃあ今ここで一緒に作ろう」に持っていく。伴走は、崩れる前提で組んでおくくらいがちょうどいい。

事前アンケートのネタは、意外とすぐ尽きる

初回前に全員へヒアリングシートを配り、業務課題を吸い上げてから臨んだ。この事前準備は効いたが、2回目あたりで気づいた。事前に集めた課題は、2回も回すとほぼ出し切ってしまう。

3回目以降は、事前アンケート頼みをやめて、ワークショップの中でその場の会話から新しい課題を掘っていく方式に切り替える必要があった。伴走が進むほど、「事前に用意した設計」より「その場で拾う瞬発力」の比重が上がる。

「何に使いたいか」がふわっとしている人がいる

全員が「これをAIにやらせたい」と明確に持っているわけではない。「便利そうだけど、具体的に何を任せればいいかは分からない」という状態の人も普通にいる。

このタイプには、本人から要件が出てくるのを待っていても進まない。こちらから業務フローの設計案を先にぶつけて、「たとえばこう組めますけど、どうですか」と叩き台を出すほうが早い。要件定義ごと伴走する、くらいの姿勢が要る。

▼まとめ：非エンジニア部門のAI定着は「設計」できる

「開発は勝手に使うのに、管理部は進まない」——これはメンバーのやる気の問題じゃない。業務に接続する設計が無いまま「研修」で終わらせているだけのことが多い。

• ▶ 「研修」ではなく「伴走」——渡すのは知識ではなく「業務が変わった体験」
• ▶ リテラシーのばらつきは前提——全員に同じことを教えない
• ▶ 初回は欲張らない——「楽になりそう」という手応えだけでいい
• ▶ 宿題は全員やってこない前提で組む——崩れたらその場で作る時間に切り替える
• ▶ デモは相手の実データで——固有名詞が入った瞬間に反応が変わる
• ▶ ふわっとした人にはこちらから叩き台を——要件定義ごと伴走する

非エンジニア部門のAI活用は、根性論でも属人でもなく、設計の問題だ。設計さえあれば、AIとの距離が遠い部門でも十分に根付かせられる。