AIで業務マニュアルを更新する手順：差分と責任者を残す

この記事で分かること

更新対象となる業務マニュアルの正本を固定する方法
変更要求票からAIへ差分案を作らせる手順
現行文、変更案、変更根拠を並べた差分表の作り方
業務責任者の承認、施行、旧版保管までの運用

注意： AIにマニュアル全文を書き直させると、変更対象外の手順まで変わる可能性があります。本記事では、承認された変更要求と現行文の差分だけを作成・確認します。

先に結論

マニュアル更新で最初に決めるのは、どの文書が正本かです。次に、変更理由、対象範囲、根拠、施行希望日、確認責任者を変更要求票へ記録します。

AIには正本と変更要求を渡し、差分案を作らせます。業務担当者が実際の画面・手順と照合し、責任者が承認した版だけを公開します。AIは差分整理を担当し、手順の正しさと施行判断は業務責任者が持つ運用にします。

マニュアルの変更根拠から公開までを管理する流れ 正本の固定、差分抽出、担当者確認、版の公開を順に行い、変更の根拠と責任者を残す流れを示している。

手順1：正本を1つに固定する

共有フォルダー、チャット、個人PCに同名の手順書がある状態では、AIへ渡す前に正本を決めます。

正本には次の情報を付けます。

文書ID：OPS-ORDER-001
文書名：受注登録マニュアル
現行版：v3.2
施行日：2026-05-01
所有部門：業務管理部
業務責任者：[氏名または役割]
保管場所：[承認済み文書のURLまたは管理場所]
次回レビュー日：2026-11-01
ステータス：施行中

ファイル名だけで版を判断せず、文書内にも版、施行日、所有者を記載します。「最新版」「最終」「最終2」といった名前は避けます。

正本を特定できない場合は、複数版をAIに統合させてはいけません。各版の所有者と更新履歴を調べ、業務責任者が正本を決めます。

手順2：変更要求票を作る

口頭の依頼やチャットの一文だけで更新すると、変更範囲が広がります。次のテンプレートで要求を記録します。

## 変更要求票
- 変更要求ID：CR-2026-014
- 対象文書ID：OPS-ORDER-001
- 対象版：v3.2
- 依頼者：
- 依頼日：
- 変更理由：
- 根拠資料：制度通知、承認済み仕様書、画面確認記録など
- 対象箇所：章、見出し、手順番号
- 変更内容：追加／修正／削除
- 対象外：今回変更しない章や業務
- 想定利用者：
- 施行希望日：
- 業務確認者：
- システム確認者：
- 承認責任者：
- 旧手順との互換性：あり／なし／要確認
- 教育・周知の要否：
- ロールバック条件：

「画面が変わったので修正」のような依頼では不十分です。どの環境で、どの項目名が、何に変わったかを確認します。検証環境と本番環境で表示が違う場合は、施行条件として記録します。

手順3：根拠資料を限定してAIへ渡す

AIが参照してよい資料を明示します。

現行の承認済みマニュアル
承認済みの変更要求票
正式な仕様書、通知、画面確認記録
用語集や文体ルール

メールの推測、未承認の画面案、出所不明のメモは、根拠資料へ混ぜません。AIサービスへ入力可能な機密区分か、アクセス権が適切かも確認します。

Microsoft 365 Copilot Notebooksのように、追加した参照資料へ範囲を絞って回答する製品もあります。ただし、参照範囲が限定されることは、資料の内容が正しいことを意味しません。古い資料を追加すれば、古い手順に基づく回答になります。

手順4：差分だけを作らせる

次のプロンプトでは、全文改稿を禁止し、変更要求IDと根拠を残します。

あなたは業務マニュアルの差分整理担当です。
現行版v3.2と、承認済み変更要求CR-2026-014を比較してください。

作業範囲：
- 変更要求で指定された章・手順だけ
- 表記統一が必要な場合も、対象外箇所は変更せず指摘のみ

出力：
1. 差分表（箇所ID、現行文、変更案、変更理由、根拠資料、確認者）
2. 影響を受ける前後の手順
3. 追加確認が必要な点
4. 変更要求に含まれないが矛盾する可能性がある箇所

ルール：
- 現行文を省略しない
- 根拠資料にない画面名、ボタン名、権限、例外処理を作らない
- 不明点は[要確認]とする
- 対象外の文章を読みやすさのために書き換えない
- 削除案も、削除する原文と理由を表示する
- 完成版ではなくレビュー用の差分案として出力する

成功の目安は、変更要求にない段落が勝手に書き換えられていないことと、各変更案に根拠が付いていることです。

手順5：差分表をレビューする

差分表は次の形に統一します。

箇所ID	現行文	変更案	種別	根拠	業務確認	承認
3.2-04	「申請」ボタンを選択	「申請内容を確認」後、「申請」ボタンを選択	修正	SPEC-221 §4	未	未

レビューでは、文章の自然さより先に次を確認します。

変更要求の対象箇所と一致するか
変更案が根拠資料の内容を超えていないか
前後の手順番号、画像、参照リンクに影響がないか
権限、例外、エラー時の処理が残っているか
現行利用者が新手順へ切り替えられるか
対象外の手順が変わっていないか

削除にも承認が必要です。「不要そうだから」というAIの判断だけで、注意事項や例外処理を削除しません。

手順6：実際の手順で確認する

業務担当者が、更新案だけを見て対象業務を再現します。可能であれば、一般利用者と同じ権限・画面で確認します。

記録する項目は次のとおりです。

確認記録ID：TEST-CR-2026-014-01
対象版：v3.3候補
確認環境：本番／検証
確認者：
確認日時：
開始条件：
実施した手順番号：
期待結果：
実際の結果：
差異：
証跡：画面記録、ログ、申請番号など
判定：合格／要修正／実施不可

成功とは、AIが「問題ありません」と回答することではありません。許可された環境で担当者が手順を実行し、期待した結果を確認できることです。

本番で試すと取り消せない処理、課金、顧客通知、データ削除が発生する場合は、検証方法と承認者を別途定めます。

手順7：責任者が承認する

確認者と承認者を分けます。小規模なチームで同一人物になる場合も、確認した日時と根拠を残します。

承認時には次を確定します。

公開版番号
施行日
対象者
旧手順を使える猶予期間
周知・研修の方法
問い合わせ先
問題発生時のロールバック先

AIの生成日時や作業者名だけでは、業務承認の証跡になりません。責任者が差分と確認記録を見たことを残します。

手順8：新しい版を公開し、旧版を保管する

公開時は、正本の保管場所を新しい版へ切り替えます。利用者が古いリンクから開いた場合に、旧版であることが分かる表示を付けます。

文書ID：OPS-ORDER-001
公開版：v3.3
施行日：2026-08-15
変更要求：CR-2026-014
承認者：
承認日：
主な変更：手順3.2-04の申請前確認を追加
旧版：v3.2（廃止、監査用に保管）
正本URL：

旧版は削除せず、通常利用者が誤って使わない保管場所へ移します。保管期間は社内規程や法令に従います。旧版の画面上部には「廃止版」「施行終了日」「現行版へのリンク」を表示します。

手順9：施行後に監視する

公開で終わりではありません。施行直後は次を確認します。

問い合わせ件数と内容
手順途中の離脱やエラー
旧版へのアクセス
現場で発生した例外
想定外の権限差や画面差

重大な誤りが見つかった場合は、責任者が公開停止、旧版へのロールバック、暫定手順の周知を判断します。AIへ自動修正・自動公開させません。

期待結果と確認方法

更新完了時に、次の関係をたどれることが成功条件です。

公開版の変更箇所 → 差分表 → 変更要求票 → 根拠資料 → 確認記録 → 承認者

任意の変更行を1つ選び、「なぜ変えたか」「誰が確認したか」「いつ施行されたか」を説明できるか確認します。説明できない行は、公開前に差分表へ戻します。

さらに、変更要求の対象外章を現行版と比較します。意図しない差分があれば、AIによる全面改稿や書式変換が混ざった可能性があります。

失敗しやすい点と対処

正本が複数ある

AIで統合する前に、所有者と履歴を確認します。正本を決められない状態では更新を停止します。

全文を「最新化」させる

AIが画面名や一般的な手順を補う可能性があります。変更要求ID、対象章、参照可能資料を限定し、差分表だけを出させます。

スクリーンショットだけを差し替える

画像内の番号、本文の操作名、代替テキスト、前後の説明も確認します。画像から読み取った文字列は実画面と照合します。

公開日と施行日が混ざる

先に公開して研修期間を設ける場合があります。いつから新手順が正式になるかを別項目で明示します。

旧版を同じ場所に残す

検索結果やブックマークから古い版が使われます。廃止表示、現行版への誘導、閲覧権限を整えます。

AIの参照範囲を信頼しすぎる

限定された資料に基づく回答でも、読み違い、抜け、矛盾は起こり得ます。参照資料の正しさと生成差分の正しさを別々に確認します。

採用しない条件

業務責任者が不在、正本が不明、変更根拠が未承認、実際の手順を確認できない、誤操作時に重大な損失がありロールバックできない場合は、AIを使った更新を採用しません。先に文書管理と承認経路を整えます。

AI活用ナビの判断

AI活用ナビの判断： マニュアル更新でAIが最も役立つのは、全文の代筆ではなく、現行文と変更要求の対応付け、矛盾候補の抽出、差分表の整形です。変更要求、確認者、承認者、施行日を残せない組織では、生成速度を上げる前に版管理を整えるべきだと判断します。

確認日と公式情報

2026年7月29日に確認しました。

NIST「Artificial Intelligence Risk Management Framework」：AI RMF 1.0のGovern、Map、Measure、Manageという枠組みと、役割・責任、文書化、継続的な確認を重視する考え方を確認しました。NISTはAI RMF 1.0の改訂作業中であることも案内しています。
Microsoft「How Microsoft 365 Copilot Notebooks works」：追加した参照資料に基づく回答、参照範囲、対応形式、現時点の制限に関する説明を確認しました。利用条件、上限、画面はプランや更新により変わる可能性があるため、導入時に公式ページを再確認してください。

NIST AI RMFは任意利用のリスク管理枠組みであり、この手順そのものを規定したマニュアル更新規格ではありません。本記事では、責任、文書化、確認、継続管理の考え方を編集部の実務手順へ応用しています。

PRIMARY SOURCES