Geminiで業務マニュアルを作る手順：現場の口頭説明を手順書に

結論

Geminiで業務マニュアルを作るときの材料は、頭の中の記憶だけではありません。ドライブに散らばった旧手順書と、Gmailに残っている実際のやりとりが、すでに手順の原型を持っています。それらを読ませて骨格を起こし、抜けている操作を指摘させ、読む人の習熟度に合わせて厚みを指定すれば、初稿は目安として1時間ほどで整います。Googleドキュメントに書き出してコメントでレビューを回し、その業務を知らない人に通しで試してもらったところで、ようやく配れる状態になります。

教えた人がいなくなると回らなくなる手順書

経験者が書いた手順書は、経験者だけが読める文書になりがちです。「お客様の注文状況を確認する」と1行書いたとき、書き手は注文番号から検索する方法も、番号が分からないときに電話番号で引く手順も、出てきた画面のどこを見れば発送済みか分かるかも承知しています。読む人はどれも知りません。

厄介なのは、書き手が読み返しても抜けに気づけないことです。文字が足りなくても、記憶が空白を埋めてしまいます。Geminiに読ませる意味は、その業務を知らない読み手を用意できる点にあります。

この記事では、社員120名の通信販売会社で、注文に関する問い合わせの一次対応を例にします。メールと電話で毎日60件ほど届き、今は在籍5年の社員2名が勘で捌いている。この2人が同時に休むと処理が止まる、という状態からの出発です。

下準備：記憶ではなく、直近の実物を集める

手順を思い出して書こうとすると、典型的な対応だけが残り、判断に迷った案件が抜けます。集めるのは実物です。

直近1週間で自分が返した問い合わせのメールを10件ほど選びます。すんなり返せたものと、社内に確認してから返したものを半々にするのが要点です。あわせて、ドライブにある関連資料を1か所のフォルダにまとめます。旧手順書、返信の定型文、商品の仕様表、返品規定。散らばったまま読ませると、Geminiが参照した資料を追えなくなります。

顧客名や注文番号をそのまま渡してよいかは社内ルール次第です。判断がつかなければ、氏名をA様、注文番号を数字なしの記号に置き換えます。手順を起こすのに必要なのは、やりとりの流れと判断の理由だけです。

具体例1：Gmailとドライブの実物から、実際の手順を起こす

Geminiには、Googleドキュメントやドライブ、Gmailと連携して自分の資料を参照させる使い方があります。一次対応のように文書化されていない業務では、この連携が下書きの速さを決めます。プランや時期によって使える機能が異なるため、最新の仕様は公式情報で確認してください。連携が使えない環境なら、やりとりの本文を会話に貼り付けても同じように進みます。

ドライブの「問い合わせ一次対応」フォルダの資料と、
私が貼り付けた過去の対応メール10件を読んでください。
資料には旧手順書、返信の定型文、返品規定が入っています。

【やってほしいこと】
1. 実際のやりとりから、一次対応で繰り返し行われている作業を取り出し、
   時系列の手順として並べる
2. 問い合わせの種類ごとに分岐している箇所を見つけ、分岐の条件を書く
3. 担当者が社内の誰かに確認してから返信している箇所を抜き出し、
   何を、誰に確認しているのかを整理する
4. 旧手順書に書かれているが、実際のやりとりでは行われていない作業を挙げる
5. 逆に、実際は行われているのに旧手順書にない作業を挙げる

【条件】
・この段階では本文を書かず、見出しと手順の一覧だけを出す
・各手順について、どの資料またはどのメールから読み取ったかを併記する
・読み取れなかった箇所は推測で埋めず、質問として返す
・所要時間や件数は、私が伝えていない限り書かない

4番と5番の差分が、この使い方のいちばんの収穫です。旧手順書に残っているのに誰もやっていない作業は、廃止された確認フローの名残であることが多く、消せます。逆に、実際は毎回やっているのに手順書にない作業こそ、新任者が止まる箇所です。「返信前に在庫システムで引当状況を見る」のような操作が、たいていここで出てきます。

出どころを併記させる指示も外せません。どのメールから起こした手順かが分かると、内容を疑ったときに現物へ戻れます。Geminiが資料になかった内容を足した場合は出どころが空欄になるので、見分けがつきます。

抜けている操作を指摘させる

骨格ができたら、読み手を入れ替えて読ませます。

先ほど整理した一次対応の手順一覧を、次の人になったつもりで読んでください。

・先週入ったばかりの派遣スタッフ
・当社の商品を見たことがない
・社内システムの画面を触った経験がない
・隣に聞ける人がいない状態で、電話を1本受けている

この人がこの手順だけで対応したとき、手が止まる箇所を挙げてください。

【条件】
・「どこで止まるか」と「何が書かれていないから止まるか」を分けて書く
・止まる可能性の高い順に並べ、10点以内に絞る
・情報をどこで調べるか、正常と異常の見分け方、自分で答えてよい範囲、
　答えられないときの引き継ぎ先の4つは、書かれているかを必ず確認する
・書かれていない内容を推測で補わず、質問の形で返す

返ってくる指摘は、「注文状況を確認するとありますが、どの画面を開くのかが書かれていません」「返品を受け付けると書かれていますが、受け付けてよい条件が書かれていません」といった形になります。5年やってきた人にとっては考えるまでもない情報です。

最後の4つを名指しするのは、これらが経験者の頭から抜けやすいからです。とくに「自分で答えてよい範囲」を書いていない手順書は多く、新任者が判断できずに保留の山を作ります。

指摘のうち答えられるものはその場で埋め、答えが定まっていないものは現場で決めます。「値引き対応をいくらまで一次対応者が判断してよいか」が誰にも答えられないと分かった時点で、マニュアル作りは運用ルールの整備に変わります。

読む人の習熟度で、説明の厚みを変える

同じ手順でも、渡す相手によって必要な情報量が違います。指定しないと、どの相手にも中途半端な長さで返ってきます。

読む人	指示に入れる条件	1手順あたりの目安
入ったばかりの派遣スタッフ	1操作ごとに1文。画面と調べ方を毎回書く	3文から5文
他部署から異動してきた社員	商品知識は補い、システム操作は簡潔にする	2文と補足1行
繁忙期だけ応援に入る社員	よくある3種類の問い合わせだけを厚く書く	判断の分岐図
対応を引き継ぐ後任者	手順より、例外への判断基準と過去の経緯を厚くする	事例つきの解説

指定するときは、相手の所属ではなく、その人が何を知らないかを書くほうが正確に伝わります。

先ほどの一次対応の手順に本文をつけてください。

【読む人】
・先週入った派遣スタッフ
・社内システムの画面を見たことがない
・「引当」「与信」といった社内の言葉を知らない

【書き方の条件】
・1つの操作につき1文。2つの操作を1文に入れない
・調べる作業が出てきたら、どの画面のどの項目を見るのかをその回に書く
・判断が要る箇所は、何が満たされていれば進めてよいかを条件の形で書く。
　条件を私が伝えていない場合は「要確認」と書いて空欄にする
・社内の言葉を使うときは、その場で普通の言い方に直す。
　カッコを使った補足はしない
・1手順は5文以内に収める

【出力形式】
・手順は番号つきで並べる
・例外や条件つきの作業は本文から外し、末尾に一覧としてまとめる

カッコに頼らせない指示は、そのまま読みやすさに効きます。「引当、つまり在庫をその注文のために取り置く処理」と文中で説明されたほうが、新任者は読み飛ばしません。

画面と電話の操作を、文章でどう表すか

画面操作の記述は、画像を貼れば済むように見えて、更新のたびに壊れます。文章側の型を決めておくと、画像が古くなっても手順が読めます。

注文状況を確認する操作を文章にしてください。私の説明は以下です。

【操作の内容】
受注管理の画面を開いて、上の検索欄に注文番号を入れる。
番号が分からないときは、検索の種類を電話番号に切り替えて引く。
一覧が出るので、日付が新しいものを開く。
状態という欄に「出荷準備中」か「出荷済」のどちらかが出ている。
出荷済なら伝票番号が同じ画面の下に出ているので、それを伝える。

【書き方の型】
・1文を「どこを見て」「何をして」「どうなったら次へ進むか」の順に組み立てる
・画面や欄の名前は、実際に表示されている文字をそのまま書く。
　私が伝えていない名称は「要確認」と書いて空欄にする
・ボタンや項目は、位置ではなく表示名で指し示す。
　「右上のボタン」のような書き方はしない
・操作の結果、画面がどう変わるかを毎回1文で書く
・画像を差し込む箇所には、何を写した画像が必要かを1行で指定する
・電話口で読み上げる言い回しが必要な箇所は、そのまま話せる文にする

位置で指すのをやめると、更新の手間が減ります。「右上の青いボタン」は画面が変われば全部書き直しになりますが、「状態」という表示名で指していれば多くの場合そのまま生き残ります。電話対応の手順書では、最後の条件が効きます。「確認いたしますので、少々お待ちいただけますでしょうか」まで書いてあれば、新任者は言葉に詰まりません。

具体例2：Googleドキュメントに出して、コメントでレビューを回す

一次対応の手順書は、書いた人だけで完成しません。営業部門は「その案内は現場の説明と違う」と言い、経理は返金の手順に口を挟みます。Geminiの回答をGoogleドキュメントに書き出せば、そこから先は普段の共有とコメントの流れに乗ります。

書き出す前に、レビューしやすい形を指定します。

ここまでの内容を、Googleドキュメントに書き出せる形の手順書にまとめてください。

【構成】
1. この手順書が扱う範囲と、扱わない範囲
2. 問い合わせを受けてから返信するまでの基本の流れ
3. 問い合わせの種類別の手順 … 注文状況、返品、請求、商品の仕様の4種類
4. 自分で答えてよい範囲と、引き継ぐ判断の基準
5. 引き継ぎ先の一覧 … 部署名と、渡すときに伝える情報
6. 例外と、過去に判断が分かれた事例

【条件】
・私が伝えていない金額、日数、権限は書かず「要確認」と記す
・3章は種類ごとに同じ並びにする。順序を種類によって変えない
・各章の冒頭に、その章を読むべき場面を1行で書く
・確認が必要な箇所には、誰に確認すべきかを併記する

書き出した後は、章ごとに担当部署を指定してコメントを依頼します。全文を読ませると誰も読みませんが、「3章の返品の部分だけ見てください」と範囲を絞れば返事が来ます。コメントが集まったら、その内容をGeminiに渡して反映案を作らせ、採用するかどうかは自分で決めます。修正履歴が残るので、後から「なぜこの手順になったのか」を追えます。

顧客への回答文そのものを整備する作業は、GeminiでFAQを作る手順と並行して進めると、手順書と回答文の食い違いが起きません。

手順どおり動くかを、別の人に試してもらう

初稿の段階では、まだ手順書ではありません。検証の方法は、その業務を知らない人に実際にやってもらう以外にありません。

1. 一次対応をしたことがない人を1人選びます。他部署の社員でも構いません。
2. 印刷した手順書だけを渡し、口頭では補足しないと先に伝えます。
3. 実際に届いた問い合わせを3件、種類を変えて渡します。返信は下書きまでにします。
4. 書き手は横で黙って見て、止まった時刻と箇所だけを記録します。
5. 終わったら、迷わなかったが不安だった箇所を本人の言葉で聞き取ります。

記録をそのままGeminiに渡して直します。

作成した一次対応の手順書を、未経験者に試してもらいました。
止まった箇所と本人の発言を貼ります。該当手順を書き直してください。

【止まった箇所と本人の発言】
・手順2「受注管理の画面を開く」→「どこから開くのか分からない」
・手順5「出荷済か確認する」→「状態の欄に別の言葉が出ていて判断できなかった」
・手順9「返品を受け付ける」→「受け付けてよい期限が書いていない」
・手順12「引き継ぐ」→止まらなかったが「誰に渡すのが正しいのか自信がなかった」

【条件】
・該当する手順だけを書き直し、他は変更しない
・私がまだ答えを伝えていない箇所は「要確認」で空欄のまま残す
・「自信がなかった」と言われた箇所は、判断の基準を1文足す形で直す
・直した理由を各手順の後ろに1行つける

止まらなかったが不安だった箇所を分けるのが、この指示の狙いです。不安は、次の人が止まる場所の予告になります。同じ検証を職種の単位で組み立てた例は、カスタマーサポートの業務マニュアルをAIで作る手順にあります。

古くならない状態をどう保つか

手順書が使われなくなる原因のほとんどは、内容が現状と合わなくなることです。決めるのは、誰が直すか、いつ見直すか、変更をどこで知るかの3つだけです。担当は個人名ではなく役職で決め、見直しを月次の業務予定に入れ、商品や規定を変えた部署が手順書の担当に連絡する経路を作ります。

Geminiは、変更の反映よりも、変更が他の箇所に及ぼす影響を洗い出すのに向いています。

ドライブにある運用中の一次対応手順書を読んでください。次の変更が入りました。

【変更】
・返品の受付期限が、商品到着から14日以内に統一された
・請求に関する問い合わせは、経理部門ではなく受注課で一次対応することになった
・受注管理の画面に「保留」という状態が追加された

【やってほしいこと】
1. 変更に直接かかわる手順を書き直す
2. 変更の影響で意味が通らなくなる他の手順を挙げる
3. 不要になった手順を挙げる。削除するかは私が決める
4. 新しく必要になる手順があれば、提案として本文と分けて出す
5. 改訂履歴に書く1行を作る。日付は空欄にする

3番と4番を分けるのは、削除と追加の判断を人が持つためです。使われていないように見える手順が、監査で求められている記録の裏づけだったという事態は起こります。

つまずいたときの対処

資料を読ませたのに、一般論の手順が返ってくる。 参照先の指定が届いていない可能性があります。フォルダ名や文書名を回答の中で挙げさせ、実際に読んだものを確認してください。読めていない場合は、対象を1つの文書に絞って試すと切り分けられます。

手順の粒度が途中で変わる。 会話が長くなると条件が薄れます。書き直しを頼むたびに「1つの操作につき1文」という条件を添えるほうが、全文を出し直させるより速く終わります。

社内で使っていない言葉が混ざる。 一般的な通信販売の用語に寄せてくる場合があります。使う言葉の一覧を先に渡し、「この一覧にない言い方をしない」と指示すると大半が消えます。

手順書が長くなりすぎる。 問い合わせの種類を全部1本に詰め込むと誰も読みません。基本の流れと種類別の手順を分け、種類別は1種類1ページに収めます。

人の目を通してから公開する

Geminiが出した手順書は、まだ誰の承認も得ていない下書きです。公開の前に、毎日その対応をしている2名が全文を読んで画面名と順序を確かめます。返金や値引きの判断が関わる章は、権限を持つ責任者が範囲を確認します。顧客名や注文番号が残っていないかも、この段階で外します。

他のツールで同じ作業を進める手順は、ChatGPTで業務マニュアルを作る手順とCopilotで業務マニュアルを作る手順にまとめています。

まとめ

直近1週間に自分が返した問い合わせを10件選び、関連する資料を1つのフォルダに集めるところから始めてください。Geminiに実際のやりとりから手順を起こさせ、旧手順書との差分を出させ、未経験者になったつもりで抜けを指摘させます。Googleドキュメントに書き出して章ごとにコメントを集め、一次対応をしたことがない人に3件だけ通しでやってもらいます。止まった箇所を直した時点で、配れる手順書になります。集めた資料のフォルダは、次の業務の手順書を作るときにそのまま材料として使えます。