AIで業務マニュアルを作る方法｜手順書に落とす流れ

AIで業務マニュアルを作るときは、文書を書かせる前に現場で実行されている手順を確かめます。担当者のメモや既存資料をそのまま整理させると、古い操作、暗黙の判断、抜けた例外をAIが自然な文章で補う可能性があります。AIに任せるのは、確認した手順の構造化と文章化です。手順の正確さ、例外判断、承認権限は現場の担当者が確認します。

対象業務と完了条件を絞る

「業務マニュアルを作る」では範囲が広すぎます。まず、誰が、どの状況で、何を完了するために読む文書か決めます。一つのマニュアルで複数業務を扱う場合は、開始条件や使う権限が違う作業を無理にまとめません。対象業務の境界を先に切ると、必要な入力、判断、例外を見落としにくくなります。

最初の整理では、次を記録します。

• 利用者：経験、担当範囲、必要な権限。

• 開始条件：いつ、何をきっかけに手順を始めるか。

• 入力：必要な資料、システム、依頼内容。

• 完了状態：何ができたら作業終了か。

• 影響：間違えた場合の顧客・金銭・安全・記録への影響。

• 承認：担当者だけで進めてよい範囲と、確認が要る条件。

• 更新責任：手順や画面が変わったときに知らせる人。

業務責任者に、通常ケースだけでなく最近の例外や失敗も聞きます。担当者の経験だけに依存している判断があれば、「慣れている人なら分かる」と済ませず、判断の手掛かりと相談先を明確にします。AIが埋めた空欄を標準手順だと誤認しないよう、未確認事項の欄を独立させます。

現場の行動を観察して手順素材を集める

作業者に思い出してもらうだけでは、無意識に飛ばしている確認が抜けることがあります。可能な範囲で、現場担当者に通常ケースを実演してもらい、開始条件、操作、判断、記録、終了条件を順に記録します。画面を撮影する場合は、顧客データや認証情報を含めない方法を選び、社内規程や利用者の同意が必要な場合は先に確認します。

業務手順を記録する表の例：

表は横にスクロールできます

工程	担当の操作	確認する表示・入力	判断条件	次の状態
開始	対象案件を開く	案件ID、受付状態	IDが一致する	内容確認へ
確認	必須項目を見る	承認状況、金額欄	条件不足なら中断	更新または相談
実行	承認済み操作だけ行う	操作結果の表示	完了表示を確認	記録へ
終了	対応履歴を残す	日付、担当、結果	記録が保存済み	完了

これはマニュアルの内容を示す架空例であり、どの製品の画面や実際の操作とも無関係です。実案件では使用システムの表示名、操作権限、承認者を現場で確かめてから入力します。

AIには素材の整理を頼み、穴を埋めさせない

手順素材をAIに渡す前に、社外サービスへ入力してよい情報かを確認します。顧客名、認証情報、内部URL、セキュリティ手順、未公開の障害対応は、許可されたAI環境か確認なしに入力しません。個人情報や機密情報が不要なら外し、残す必要がある場合は組織の利用ルールと契約条件に従います。

依頼文は、手順生成よりも素材の再構成に限定します。

あなたは承認済みの業務メモをマニュアルの下書きへ整理する編集者です。業務内容や操作を追加で推測してはいけません。

入力に記録された手順を、開始条件、事前準備、操作、判断条件、例外、記録、完了条件へ分類してください。

各手順に元メモの行番号を付け、根拠がない画面名・権限・判断基準は［現場確認］としてください。

操作と判断を一つの曖昧な文にまとめず、1ステップで一つの主要行動が分かる形にしてください。

入力：［社内承認済みの匿名化素材］

AIが説明を滑らかにした後、元資料にない承認ルールやシステム項目が追加されていないかを比較します。画面名の推測や、現在のUIを知っているかのような記述も確認が必要です。操作を再現できない箇所は、手順書へ確定文として入れず、担当者へ質問を返します。

1ステップを実行・検証できる形にする

「対象データを確認して更新する」のように、複数の操作と判断が一文に入っていると、どこで間違えたか分かりません。可能なら、一つの主要な操作とその確認を一つのステップにします。スクリーンショットは、どの画面・どの状態を示すか説明し、文章と同じ版のシステムで撮影します。画像だけに頼らず、画面上の名前や結果も文章に残します。

重要な操作では、実行前後を明確にします。たとえば削除や一括更新の手順なら、対象を確認する画面と、実行後に完了を確かめる方法を分けます。取り消せない操作、金額に影響する処理、顧客へ通知する操作などは、権限・承認・中断条件を明示し、確認者なしで進めないようにします。具体的な安全策は実業務の責任者が決めます。

マニュアルは、初めて読む人が作業を始める入口と、経験者が該当箇所を探す索引の両方を持つと使いやすくなります。冒頭に対象読者、目的、必要な権限、作業時間ではなく完了状態、困ったときの連絡先を置き、詳細は実際の手順順に並べます。警告は一般的な注意ではなく、「どんな条件で止まり、誰へ連絡するか」を具体的にします。

例外・停止・再開のルールを残す

マニュアルが役立つのは通常手順だけではありません。入力が見つからない、申請内容が一致しない、承認状態が違う、画面が案内と異なる、権限が不足するといった場面で、作業をどこで止めるか示します。AIに例外を創作させず、現場で確認できた例外と責任者が承認した判断だけを載せます。

例外表には、条件、すべきこと、してはいけないこと、相談先、再開条件を記載します。単に「上長へ相談」と書くのではなく、どの情報を伝え、どの承認が得られるまで処理を保留するのかを決めます。担当者が不在なら誰へ引き継ぐかも、実運用に基づきます。判断基準が未確定なら公開前の未解決事項として残し、マニュアルを確定版にしません。

手順を現場で試し、版を管理する

下書きのレビューは、著者だけでなく実際にその業務を担当する人が行います。可能なら、手順を知らない担当者にマニュアルを見ながら通常ケースを実施してもらい、確認なしで進められたか、どこで迷ったか、誤操作の危険があったかを記録します。テストケースは現場の承認がある環境で行い、本番データを使うときは組織の安全ルールに従います。試していない手順を「実際に検証済み」と表現しません。

更新管理には、文書所有者、承認者、対象システムの版、公開日、改訂理由、次の確認契機を記します。組織変更や画面更新のほか、手順事故や監査指摘も見直しのきっかけになります。古い版を現場の共有場所から除き、関連するFAQや研修資料にも差がないか確認します。AIへ古い版を再入力しないよう、素材の版番号を依頼時にも記録します。

使える状態かを公開前に見る

• 対象読者と開始条件が明確か。

• 各操作を実際の権限で実行できるか。

• 判断条件が「適切に」「問題なければ」だけになっていないか。

• 例外と停止条件、相談先が確認済みか。

• 元資料にないシステム名や承認手順が追加されていないか。

• 重要な操作の実行前後を確認できるか。

• 画面画像、機密情報、顧客データの扱いが承認済みか。

• 現場担当者が読みながら作業し、迷った点を直したか。

• 所有者、承認者、更新トリガー、版が分かるか。

一つでも重大な不明点がある場合は、文面を整えるより現場の責任者へ戻します。

1ステップを「読んで動ける」形にする

「管理画面で処理する」「内容を確認する」だけでは、初めて担当する人は何を見て次へ進むか分かりません。操作、期待する結果、違った場合の止め方を一組で書きます。画面操作であれば「どのメニューを開くか」「対象をどう特定するか」「保存後に何を見れば完了か」。判断を含む業務なら「判断材料」「承認者」「記録先」を分けます。

表は横にスクロールできます

手順の部品	マニュアルに書く内容	未確認なら
開始	依頼・期限・必要権限	現場責任者へ確認
操作	画面や書類で行う1つの行動	実画面を見てから記載
完了確認	保存状態、番号、通知などの証拠	完了条件を業務ownerが決定
例外	起きる条件、停止点、相談先	通常手順へ混ぜない
記録	残す情報、保存先、保持条件	情報管理担当へ確認

たとえば、架空の「申請を承認する手順」を作る場合でも、承認権限や金額条件をAIに想像させてはいけません。実際の規程と担当者の確認から条件を埋め、未確定欄を「要確認」として残します。見た目の整った手順書より、未確認箇所が見える下書きの方が、業務へ安全に近づけます。

初めての人に読んでもらうテスト

文章の正しさを作成担当者だけで確認すると、暗黙知に気づきにくくなります。対象業務に慣れていない人に、マニュアルだけを見て実行してもらい、どこで止まったかを記録します。テスト環境がない操作や、顧客・金銭・安全へ影響する操作は、実データで試さず、承認された訓練環境や画面例を使います。

チェックするのは、説明の分かりやすさだけではありません。手順の順序で戻り作業が発生しないか、必要な権限を事前に示しているか、画面名が現行と一致するか、完了後に二重処理を防げるかも確認します。迷った人の質問をマニュアルへ反映した後、別の担当者でも同じ結果へ到達できるか再確認します。作成者自身による読み返しを「現場テスト」の代わりにしないことが大切です。

例外を分けるときの判断

すべての例外を本文に入れると、通常手順が読みにくくなります。一方、例外を省くと、失敗時に担当者が独自判断をすることになります。例外は頻度ではなく、間違えた場合の影響と、通常手順へ戻れるかで扱いを決めます。低リスクで安全に戻せる分岐は短い補足にし、権限逸脱、個人情報、金銭、顧客影響、取り消せない変更などは目立つ停止条件として本文から参照できるようにします。

例外項目には「発生条件／してはいけない操作／停止後の相談先／再開に必要な承認／記録する内容」を揃えます。現場で起きた例外がマニュアルにない場合、担当者にその場で手順を追加させるのではなく、暫定対応と正式な変更を分けます。暫定対応の期限と承認者を記録し、正式手順は業務ownerの確認後に更新します。

更新責任を実務に結び付ける

「定期的に見直す」だけでは、更新漏れを防げません。システム画面、規程、帳票、権限、担当部署の変更を受け取る窓口を決め、その変更がどのマニュアルへ影響するか追えるようにします。マニュアルにはowner、承認者、版、確認日、次回確認のtriggerを置き、旧版を配布場所からどう外すかも決めます。

更新時は、差分だけ直して完了にせず、関連するスクリーンショット、FAQ、研修資料、リンク先の版も確認します。重大な手順変更なら、既に作業中の人へ周知する方法も必要です。変更履歴に「何が変わったか」「誰が確認したか」「どの利用者へ影響するか」を残すと、後から古い説明が見つかったときに範囲を追いやすくなります。

AIものさしの判断

AIでmanualを作る価値は、文章をゼロから生成することより、現場の断片的な知識を整理することにあります。

実際の手順→AIで構造化→担当者reviewの順にすると、使えるmanualになりやすくなります。