Copilot研修を作っていたら、プロンプト以前の話になった
対話力・情報整備・レビュー力──AI活用勉強会で気づいた3つの本質
社内のCopilot勉強会の資料を見直す作業をしていた。「プロンプトの書き方を教えれば終わり」という軽い気
持ちで始めたのだが、資料を組み立てているうちに、全然そういう話じゃなかった、という気分になってきた。プロンプトより先に、もっと根っこにある話をしないと、この研修は薄っぺらいままで終わるな、と感じた。
「プロンプト術を教えれば済む」という罠
最初に考えていた構成は、こんな感じだった。
Copilotとは何か、得意なこと・苦手なこと、こう書くと良い回答が返ってきます、このテンプレートを使ってください──という、よくある「プロンプト事例集」型の研修。
作りながら、疑問が積もってきた。
「この研修を受けた人は、本当に変わるだろうか」
品質保証の仕事を長くやっていると、教育の限界みたいなものが見えてくる。知識を渡しただけでは、現場の行動は変わらない。受講後30日以内に実際に使わないと、学んだことは消える。
Copilotも同じだと思った。
慣れていない人がCopilotで詰まる場面を思い浮かべてみると、プロンプトの書き方が悪いというより、もっと別のところでつまずいていた。「何を頼めばいいか整理できていない」「出てきた回答を信じていいのか判断できない」「そもそもTeamsやOutlookの情報が散らかっていてCopilotが文脈をつかめない」、そういう場所だった。
プロンプトの書き方は、氷山の一角だった。
Copilot活用の本質は3要素の掛け算
あれこれ考えていくうちに、こういう等式が見えてきた。
Copilot活用 = 対話力 × 情報整備力 × レビュー力
掛け算で書いたのは意図がある。どれかひとつが0だと、全体が0になるからだ。
どんなにうまいプロンプトを書いても、参照するOutlookのメールが「件名：ご連絡」だらけなら、Copilotは文脈をつかめない。一発で完璧な答えを求めるだけで対話をしなければ、たたき台は育たない。出てきた回答を全部信じて、そのまま出してしまえば、やがて何かが崩れる。
3つを同時に鍛えないと、Copilot活用は絵に描いた餅で終わる。
情報整備力：Copilotは散らかった情報を魔法で整えない
ぼくが研修資料を見直していて、一番「ここが抜けてた」と感じた章がここだった。
Microsoft 365 Copilotは、Outlookのメール、Teamsのチャット、Calendarの会議情報、SharePointのドキュメントを参照して回答を生成する。つまり、Microsoft 365上の情報の状態が、そのままCopilotの出力の質に影響する。
現実の職場の情報を思い浮かべてほしい。
Outlookの件名が「お世話になっております」で始まるもの。「ご確認お願いします」という件名で依頼内容も期限も書かれていないメール。TeamsのDMに重要な決定事項が埋まっていて、チャネルには何も残っていない。Calendarの会議名が「定例」「MTG」で、アジェンダもない。SharePointには「報告書（最終）」と「報告書（最終最終）」と「報告書（確定版）」が並んでいる。
この状態でCopilotに「先週の決定事項をまとめて」と頼んでも、文脈がつかめない。Copilotが悪いというより、情報の残し方が悪い。
品質保証の仕事でいうと、「検査記録がないのに不良率を出してくれ」と言っているようなものだ。記録がなければ、何を集計しても意味がない。
具体的に何を整えればいいかというと、こういう話になった。
Outlookの件名には、目的・依頼内容・期限を入れる。「〇〇の資料確認お願いします（期限：6/15）」と書けば、Copilotが拾える情報として残る。Teamsは重要な決定事項を個人チャットだけで終わらせない。チャネルにスレッドとして残すことで、後から参照できるようになる。Calendarの会議タイトルには目的を入れる。「週次定例」より「週次定例：〇〇案件の進捗確認」の方が、Copilotが会議の文脈を理解しやすい。SharePointは古いファイルを放置しない。最新版がどれかわからない状態は、Copilotにとっても人間にとっても同じくらい困る。
「Copilotが使いやすい情報は、人間にとっても探しやすい情報」だ。整理は、AIのためだけでなく、自分たちのためになる。
対話力：一発で終わらせず、育てる
研修資料の中で、もともとあった強いメッセージがここだった。現行のPPTを見ていて「これは残すべき」と感じた部分だ。
一発プロンプトで完璧な答えを求めない。
返ってきた答えが「なんか違う」なら、そのまま言えばいい。「座学っぽいので実例中心にして」「新人が読んだらどこで迷うか指摘して」「今は機能紹介ではなく対話の話をしている」──こういうことをそのまま言えるのが、AIと話す強みだ。AIは傷つかない。遠慮なく言い直せる。
対話の型を整理すると、4つになった。
１つ目は「状況を教える」。背景・目的・参加者・制約条件を渡す。「参加者は品証と法務です。機密への不安を先に解く必要があります」と言うだけで、返ってくる構成は変わる。
２つ目は「率直に言う」。「これじゃない」「もっとこうしたい」を素直に出す。AIとの対話で一番時間を無駄にするのは、「なんとなく違う」と感じながら使い続けることだ。
３つ目は「視点を変える」。「上司の目線から見たらどう映るか」「現場の作業者が読んだら何が引っかかるか」といった、別の立場を与える。
４つ目は「軌道修正する」。AIは親切に話を広げすぎることがある。「今は機能紹介の話ではなく、対話の話を続けてください」とハンドルを戻すのは、人間の仕事だ。
「AIに文脈を渡すのは、人間にしかできない」というメッセージを研修に入れた。これは本当にそうだと思う。Copilotがどれだけ賢くなっても、自分が何を目的としていて、相手は誰で、この場の空気がどうなのかは、人間が伝えない限り、AIにはわからない。
レビュー力：「作る力」より「受け取る力」
品質保証で20年近くやってきて、これが一番刺さった。
Copilotが出してきたものを、そのまま出さない。これがわかっていても、できていない場面が多い。完成度が高く見えると、人は確認をさぼる。製造業の「検査飛ばし」と同じ構造だ。
ぼくが研修で提案した確認の観点は4つだった。
「事実」──数値・固有名詞・引用は本当に合っているか。「論理」──結論と根拠がつながっているか。「文脈」──今の状況・相手・場面に合っているか。「責任」──そのまま出すことに責任を持てるか。
最後の「責任」が一番重い。
Copilotが書いた文章でも、自分の名前で出した瞬間に、それは自分の発言になる。「AIが書いたので」は免責にならない。これは品質保証で言う「最終判断は人間が持つ」と同じ話だ。
AI活用で本当に大事なのは、「作る力」だけでなく、「受け取ったものを検証する力」だと、ぼくは感じている。
全部、品質保証でやってきたことと同じだった
研修資料を組み立て終わって、気づいたことがある。
GIGOという原則がある。Garbage In, Garbage Out。ゴミを入れたら、ゴミが出てくる。
製造業では、この原則は日常語だ。検査記録の入力が不正確なら、分析結果も信用できない。図面に誤記があれば、製造した部品も正しくならない。入力の品質が、出力の品質を決める。品質保証の人間は、これをイヤというほど知っている。
Copilotも同じだった。
情報が散らかっていれば、出力も散らかる。文脈を渡さなければ、的外れな回答が返る。レビューしなければ、不正確なものが世に出る。
「あ、これ全部、品質保証でずっとやってきたことと同じだ」と気づいたとき、少し不思議な気持ちになった。新しいAIツールの話をしているはずが、20年前から現場でやってきたことの話に戻ってきた。
だから品質保証の視点を持つ人は、AI活用でも同じことを見ている気がする。プロンプトの新しいテクニックより、情報の残し方、対話の仕方、受け取ったものの確認の仕方。そちらが先にある。
締め
Copilot研修の資料は、結局「プロンプト術を教える研修」から「仕事の整え方を見直す研修」に変わった。
それが正しかったかどうかは、受講者が翌日に何を変えるかで決まる。
あなたのTeamsとOutlookは、今日、Copilotが読めますか？