AIに手順書を作らせる方法｜作業メモから他の人が迷わないマニュアルへ

こんにちは。バナナデスクです。

いつもの作業を誰かに頼もうとして、「受付を確認して、問題がなければ次へ進めてください」とメモを書いた。自分には分かるのに、相手からは「何を見れば問題がないと分かりますか」と聞かれる。引継ぎで抜けやすいのは、この判断の部分です。

AIは短いメモを読みやすい手順へ整えてくれます。ただし、書いていない判断まで正しく知っているわけではありません。「適切に処理する」を丁寧な文章へ替えても、任された人が迷う場所は残ります。

今回は、架空の無料説明会の受付メモから、照合・分岐・中断・完了までを含む手順書を作ります。実在するシステムの操作説明や、スタッフによる実証結果ではありません。自分の作業を引き継ぐために、AIへ何を渡し、何を確認するかが分かる完成見本です。

執筆：バナナデスク｜WEBビジネスの設計・集客・改善

最初に、手順書が終わる場所を決める

「受付業務のマニュアル」では、申込の確認、日程変更、案内の送信、当日の参加確認まで広がります。初めて作るなら、始まりと終わりを一つずつ決めてください。

今回の範囲は「新しい申込の通知を受け取った担当者が、元の受付記録を照合し、案内作成へ進めるか、確認待ちにするかを記録するまで」です。案内メールの送信、予約の確定、返金、元の申込内容の修正は含めません。

「閲覧できること」も前提です。共有先の権限がなくて画面を開けないのに、本文だけ立派な手順書を渡しても仕事は始まりません。権限の申請先は本文へパスワードを書くのではなく、運営側で決めた窓口を案内します。

作業メモを、事実と未決定事項へ分ける

次のようなメモをAIへ渡す場合を考えます。

通知が来たら受付を見る。重複に注意。足りない内容は確認。大丈夫なら案内へ。記録を忘れない。

この段階では、AIに完成手順を想像させるより、何が足りないかを出してもらいます。見たいのは一般的な注意事項の数ではなく、その作業が止まる具体的な疑問です。

この例の元受付の状態は「有効」「取消」「未確認」とし、次へ進めるのは「有効」だけです。「取消」「未確認」や定義のない状態は、理由を付けて確認待ちにします。元受付の状態と、確認担当が残す「案内作成待ち」などの作業状態は、別の欄で扱います。

これは架空の運用ルールです。実際には、同じ人が複数回へ申し込めるか、対象回の変更をどう扱うかなどを、業務の責任者が決めます。AIが一般論から選んだルールを、そのまま自社の正解にしないでください。

AIには「手順」と「未決定」を分けて出してもらう

資料へ個人情報や取引先情報が含まれる場合は、利用が認められた範囲を先に確認します。今回のような設計練習は、氏名やメールアドレスを含まない架空の記録で進められます。

目的：受付確認を初めて担当する人が、照合して状態を記録できる手順書を作る。
入力：作業メモ、開始・終了条件、使う資料、決定済みルール。
出力：
1. 前提と使う資料
2. 番号付きの手順
3. 条件別の分岐
4. 中断する条件と、確認先へ渡す情報
5. 完了を確かめる方法
6. 未決定事項（本文と分ける）
制約：
・入力にない画面名、ボタン名、運用ルールを作らない。
・判断条件がない箇所を「適切に対応する」で埋めない。
・担当者の権限を超える送信、予約確定、内容修正を加えない。
・同じ受付IDと同じ人物を混同しない。
・実行・テストをしていない内容を確認済みと書かない。

Microsoftの手順記述ガイドは、番号付きの説明、操作する場所の明示、保存など完了に必要な操作を含めることを挙げています。以下ではその考え方を使い、実際の画面を指定しなくても確認できる業務の順序を作ります。参照：Procedures and instructions checklist。

完成見本：無料説明会の受付を照合する

以下は、架空の運用ルールを記入した手順書です。「対象説明会一覧」「対応記録」は資料の役割を示す名称で、特定のアプリにあるメニュー名ではありません。

1. 通知の受付IDを確認する。通知を作業の入口に使い、申込内容の正本としては使いません。IDがない場合は通知時刻と通知元を控え、確認待ちへ進みます。
2. 元の受付記録を、受付IDで開く。見つからない、閲覧できない、複数の異なる記録が出る場合は処理を止めます。似た名前の申込を代わりに採用しません。
3. 元の記録で連絡先・対象説明会・受付状態を確認する。連絡先に値があり、対象回が一覧に存在し、受付状態が「有効」であることを確かめます。空欄、矛盾、取消、未確認、定義のない状態は確認待ちにし、案内作成へ進めません。
4. 対応記録で、同じ受付IDの履歴を調べる。同じID・同じ内容で案内作成待ち以降へ進んでいる場合、二重に次の処理を作らず、参照した履歴と「既存履歴参照」を追記します。内容が違えば確認待ちです。同じ連絡先に別IDの履歴がある場合も、対象回と申込意図を確認待ちにし、勝手に統合しません。
5. 未対応で条件が揃っていれば「案内作成待ち」と記録する。受付ID、確認時刻、理由、担当を付けます。この段階では案内を送信せず、次の担当へ渡す記録を整えます。
6. 保存した対応記録を開き直す。対象IDと状態が残っているか確認します。保存に失敗した場合は完了扱いにせず、失敗した操作と表示を記録して確認先へ渡します。

最後を「記録する」で終えず、記録が残ったことまで確かめます。一方、画面を開き直したことだけで案内メールが届いたとは判断しません。今回の終点は、次の担当へ渡せる状態の保存です。

迷いやすい分岐を、対応表にする

分岐を増やしすぎると読むのが大変ですが、実際に判断が変わる条件は省けません。まれな例外は本文から外して別の対応表にし、基本手順のどこから参照するかを示す方法もあります。

「確認先へ連絡」とだけ書くのも不足です。引き継ぐ前に、誰が判断するか、どこへ記録するか、返答までどの状態で保持するかを決めます。架空の担当名や連絡先を実運用の手順書へ残さないようにしてください。

正常な1件だけでなく、止まる4件も通す

以下は、手順の論理を確かめるための架空の試験ケースです。実際のスタッフが操作した結果ではなく、先ほど決めた条件から期待する処理を導いたものです。

記入済みの引継ぎ記録なら、「R104／対象回不一致／元記録は第2回、対応記録は第1回／案内作成を止めた／運営担当へ確認依頼」のようになります。解決したときは、誰の確認でどちらを採用したかを追記します。止まった理由を消して上書きするより、判断の経緯が残ります。

引継ぎ相手が迷った場所を、文章へ戻す

論理上の確認ができたら、許可されたテスト環境と架空データで、実際に使う人へ一件ずつ進めてもらいます。作成者が横で正解を全部教えると、手順書だけで進めたか分からなくなるので、最初は止まった場所を記録してください。

見るのは速さだけではありません。どの資料を開くか、条件をどちらへ分岐させたか、止めるべき所で止まったか、保存後の確認まで行えたかです。「分かりやすかった」という感想だけで完成判定をしません。

たとえば相手が「対応済みは送信済みですか」と尋ねたら、その状態名が広すぎる可能性があります。今回のように「案内作成待ち」と工程を限定すれば、次に何をするかも明確になります。AIにはその質問と修正した定義を渡し、影響する手順だけを直してもらいます。

更新日だけでなく、変えた条件を残す

公開する手順書の冒頭に、対象業務、版、更新日、責任者を置きます。運用中は「必須項目を変更した」「対象回の照合元が変わった」「保存方法が変わった」など、実際の変更点を残してください。

資料のスクリーンショットを付ける場合は、実画面と同じか、個人情報が写っていないか、権限の違う人にも同じ表示かを確認します。架空の画面を、実際の操作を確かめた証拠として使わないことも大切です。

最初から全業務をまとめる必要はありません。自分がよく頼まれる一つの作業を選び、始まり、終わり、迷う条件を先に書く。AIにはそれを読みやすい形へ整えてもらい、最後は実際の利用者が条件に沿って進めるか確かめる。この順で、作業者の頭の中にある判断を手順書へ移していけます。