業務マニュアルをAIで作るなら、正常手順と例外を分ける

「確認して登録」だけの手順書では、何を比べ、どこで止まるかが分かりません。この記事では、通常手順と例外を分けた短いマニュアルを作ります。成果物は、開始条件・完了した証拠・止める条件・相談先がそろった初稿です。

担当者の説明を具体的な判断にする

架空の請求書受付を例にします。ここで扱うのは受付記録の下書きで、支払いや会計処理の手順ではありません。実業務では社内の承認済み手順を優先してください。

現場メモ（架空例）
開始：社内で受領した請求書と発注記録を担当者が用意する。
必要な確認：取引先コード、請求書番号、対象月、金額。
通常：請求書と発注記録を照合し、既存受付記録で重複候補を確認。
不一致・項目欠損・重複候補がなければ、受付記録の下書きを作る。
完了：リーダー確認後、受付IDと原本の場所が記録されている。
例外：金額不一致、必要項目欠損、重複候補は登録を進めずリーダーへ相談。
不明：重複候補を探す具体的なキー、相談時の連絡手段。

「適切に確認する」を、比較対象・確認項目・不一致時の動きへ分けます。未確定の重複判定キーをAIが勝手に決めたり、金額を帳尻合わせで修正したりしないようにします。

コピーして使う：手順と不足条件を整理する

目的：現場メモから業務マニュアルの初稿を作る。
情報源：下記の現場メモだけ。未記載の操作や判断を補完しない。
形式：目的・対象範囲、開始条件、必要資料、
通常手順（番号｜作業｜比較対象｜結果の確認）、
例外（条件｜止める作業｜相談先）、完了条件、不足している質問。
未確定の条件は「要確認」とする。質問への回答まで作らない。
「確認する」は、何と何を比べるかまで具体化する。
支払いや原本の修正を追加しない。実システム操作は行わない。
現場メモ：［承認済みメモまたは上の架空例を貼る］

初稿の到達例

1. 受領した請求書と発注記録を用意し、必要項目があるか確認する。欠けていれば進めず相談する。
2. 取引先コード・番号・対象月・金額を照合する。不一致なら停止する。
3. 既存受付記録で重複候補を確認する。判定キーが未確定なら、担当者に確認するまでこの手順は実行可能と扱わない。
4. 問題がない場合だけ受付記録の下書きを作り、リーダーの確認を受ける。
5. 確認後の受付IDと原本の場所を記録する。どちらかがなければ完了としない。

これは編集上の到達例です。画面名やボタンは未確認なので追加していません。「同じ番号が見つかったら削除」ではなく、重複候補として停止・相談する設計です。必要な判定条件が未確定のまま、本番で試さないでください。

別の担当者が追えるかを確認する

Microsoftの公式プロンプトガイドは、回答の確認と信頼できる情報源との照合を案内しています。ここでは、現場メモとの照合に加え、架空の正常・欠損・不一致・重複候補の4ケースを机上で追う確認方法を提案します。机上確認と、本番に近い環境での実操作検証は別です。

手順の確認記録
手順書ID・版／元の現場メモの版：
ケース：正常／欠損／不一致／重複候補
期待する動き・停止位置：
追ってみた結果と迷った箇所：
不足資料・不足条件：
修正内容：
確認者・確認日：
判定：机上確認済み／要修正
実操作検証を行った場合のみ追加：環境・日時・操作・結果・証跡

結果の確認ポイント

• 開始に必要な資料と権限、比較対象、完了した証拠が書かれているか。
• 例外で止まる位置と相談先が分かるか。未確認の答えが手順に混ざっていないか。
• 再開の条件と判断者が決まっているか。未定なら確認事項に残す。
• 更新担当・版・適用日があり、古い手順を取り下げられるか。

今日試すこと

架空例から初稿を作り、金額不一致のケースを追ってください。登録前に止まり、相談先が分かるかを見ます。判定キーや連絡手段への質問が残っていれば、現場に確認してから手順を確定します。

参考資料

Microsoft：Copilotのプロンプトの書き方（公式資料、2026年10月2日確認）。業務例・手順・確認記録はTOMONIの編集上の提案で、実行確認は未実施です。

記事一覧へ戻る