AIでマニュアルを作るなら、業務メモを渡して、手順・担当者・完了条件を整理させるところから始められます。
ただし、メモにない社内ルールまでAIに決めさせないことが重要です。
「備品を返却する」と書けても、故障していたときに誰へ連絡するかは、会社側で決める必要があります。
この記事では、架空の備品貸出メモを使い、AIの初回出力から修正まで実際に試しました。
そのまま使える指示文と入力サンプルを公開します。
ChatGPTなどで下書きを作りたい総務担当者や、引継ぎ資料を整えたい業務責任者向けの内容です。
検証日：2026年9月10日。文章生成はCodexで実行しました。実行モデルの名称・版は確認できていません。ChatGPTの画面で同じ結果を確認した検証ではありません。入力・回答はすべて編集部が作成した架空の設定で、顧客資料や実際の社内運用は使用していません。現場での操作テストと業務責任者の承認は未実施です。
この記事で分かること
- 文章で説明する業務は対話型AI、クリック位置を伝える業務は操作記録、動きを伝える業務は実写の写真や動画を起点にします
- 誤字の確認だけで終わらず、通常時と例外時を一つずつ試します
- 実資料へ移る前に、入力する内容・閲覧できる人・保存先・削除方法を責任者と確認してください
AIで作れるマニュアルと、
ツールの選び方
文章で説明する業務は対話型AI、クリック位置を伝える業務は操作記録、動きを伝える業務は実写の写真や動画を起点にします。
「AIなら何でも文章にすればよい」と考えると、現場で必要な情報が抜けます。
| 作りたいもの | 用意する素材と方法 | 確認するポイント |
|---|
| 申請・受付・引継ぎの手順書 | 業務メモをChatGPTなどへ渡し、手順と不明点を整理する | 担当者・期限・例外時の連絡先が決まっているか |
| システムの操作マニュアル | 実際の画面操作を記録し、説明文を補う | 利用者と同じ権限で、ボタンや画面が表示されるか |
| 設備・作業のマニュアル | 正しい作業を撮影し、工程ごとに説明を付ける | 手の位置・動作・危険箇所を実際の作業者が確認できるか |
PC操作が中心なら、例えばManualForceは、操作の記録からスクリーンショットと手順を作成し、後から説明を修正できると案内しています。
文章だけで架空の画面名を生成するより、実画面を起点にする選択肢です。
対応範囲や利用条件はプランごとに確認してください。
一方、社内で判断が分かれている業務は、記録するだけでは手順が決まりません。
まず責任者へ確認する質問を整理する方が先です。
以下では、画面操作を含まない備品の貸出・返却を例に、その進め方を紹介します。
業務メモから手順書を
作る4ステップ
素材を集める、下書きを作る、不明点に答える、初めての担当者が試す、の順に進めます。
見栄えを整える前に「この説明だけで次の作業を判断できるか」を確かめます。
1. 一つの業務に絞り、
現在のやり方を書き出す
最初から「総務業務すべて」を渡す必要はありません。
「貸出依頼を受けてから、返却を記録するまで」のように開始と終了を決めます。
既存のメモが粗くても、誰が何を確認しているか、どこで迷うかを残してください。
未確定のルールは「未決定」と書きます。
今回使ったメモには、必要な依頼項目、予約の確認方法、受取場所、返却時に確認する3点を記載しました。
一方、故障・延滞・キャンセルの対応と承認者は、意図的に未整理のままにしました。
検証用の業務メモをダウンロードする
2. 下書きと、公開前の
確認質問を同時に出す
「マニュアルを作って」だけでなく、根拠に使える情報と、推測を避けたい項目を指定します。
担当者・確認するもの・作業・完了条件をそろえると、単なる説明文と実務の手順を区別しやすくなります。
次の章に、実際に使った指示文を載せています。
3. 回答を反映し、変更点を見る
AIの質問に対して、現行規程や責任者の判断に基づいて回答します。
ルールがまだない場合は、記事のサンプルを流用して決定済みにせず、業務側で決めます。
修正後は全文を眺めるだけでなく、期限・連絡先・例外時の処理がどう変わったかを比較します。
4. 初めての担当者に
試してもらい、承認する
作成者以外の人が、テスト用の予約やダミーデータで手順をたどります。
「台帳はどこ？」「この状態で完了にしてよい？」と止まった場所を直し、責任者の承認後に公開します。
安全に関わる業務は、AIの文章だけを根拠に実作業を始めず、既存の安全手順に従って検証します。
AIが埋められないルールは、人に確認して反映します。
画像を押すと拡大できます。
手順の説明図で、実測結果ではありません。
マニュアル作成用のプロンプト
「不明点は要確認とし、判断が必要な手順の中にも表示する」のが、この指示文の要点です。
最後の注意書きだけにまとめると、作業中の担当者が見落とすおそれがあります。
以下の業務メモだけを根拠に、初めて担当する人向けの業務マニュアルの下書きを作成してください。
ルール：
1. メモにない締切、権限、連絡先、画面名、対応方法を推測で追加しないでください。
2. 情報が足りない箇所には「要確認」と書き、手順の最後にまとめて隠さず、判断が必要になる位置にも示してください。
3. 通常の流れと例外時の扱いを分けてください。例外時の方法が不明なら、解決済みのように書かないでください。
4. 各手順に「担当者」「確認するもの」「作業」「完了条件」を入れてください。
5. 最後に、公開前に業務責任者へ確認すべき質問を一覧にしてください。
6. 手順が未確定の下書きであることを冒頭に明記してください。
出力：目的・対象／開始前に必要な情報／通常手順／例外と要確認事項／公開前の確認質問。
業務メモ：
（ここに業務メモを貼り付けてください）
ChatGPTで試す場合は、新しいチャットへこの指示文を貼り、末尾の括弧内を業務メモに置き換えて送信します。
最初は上の架空メモを使えば、実データを入力せずに出力の形を確認できます。
これは文章の整理を依頼するプロンプトで、特定のモデルや同じ回答を保証するものではありません。
回答が長すぎる場合も、例外処理を丸ごと消さないようにします。
「通常手順は短くし、例外時の連絡先と停止条件は残してください」と追加で頼むと、削ってよい説明と残すべき判断条件を分けられます。
実際の出力では、
確認質問が15項目出た
架空メモと上の指示文を渡すと、通常手順は6段階に整理され、公開前の確認質問が15項目出ました。
初回の出力は完成品ではありません。むしろ、手順にする前に決めるべきことが見える結果でした。
例えば、出力には次の記述がありました。表現は初回出力からの抜粋です。
作業：3点がそろっていれば、台帳を「返却済み」にします。
具体的な更新方法は要確認です。
3点がそろっていても故障がある場合に「返却済み」にしてよいかは、メモでは決まっていません。
元メモには「3点がそろっていれば返却済みにする」とありますが、故障時の対応は未整理です。
AIの初稿も、処理する指示と、判断が未確定という注意を同じ作業欄に残していました。
不明点の指摘はできても、故障時に処理を止める手順にはなっていません。
このまま配布すると、壊れた備品を通常の返却として閉じてしまう可能性があります。
| 初回に残った疑問 | 記事用に設定した回答 | 修正で明確にすること |
|---|
| 故障していても返却済みにするか | 不具合があれば「要確認」にし、総務責任者へ相談する | 3点の有無だけで処理を終えない |
| 返却遅れをいつ判断するか | 予約の終了時刻を期限にする | 期限後は総務担当が返却予定を確認する |
| キャンセル時に台帳をどう直すか | 状態を「キャンセル」にし、行は削除しない | 予約を取り消しても記録を残す |
これらは記事の検証用に設定した回答であり、すべての会社に適したルールではありません。
同じやり取りに回答を追加し、初回の下書きを修正させました。
検証に使った回答と修正指示をダウンロードする
修正版の手順を一つ見る
付属品がそろっていても、不具合があれば確認を求めます。架空の設計例です。
修正版の「通常手順6」を、以下にそのまま抜粋します。
未承認の下書きですが、何を確認してから処理を終えるかが具体化しています。
6. 返却された備品を確認し、台帳を更新する
- 担当者：総務担当。
- 確認するもの：本体・電源ケーブル・接続ケーブルの3点の有無、外観の異常、利用中の不具合の申告。
- 作業：総務カウンターで返却確認を行い、問題がなければ台帳の状態を「返却済み」にします。不足・破損・不具合の申告があれば、3点そろっていても「返却時に問題がある場合」へ進みます。
- 完了条件：返却確認で問題がないと確認でき、該当する記録が「返却済み」になっています。
別の「返却時に問題がある場合」の手順では、状態を「要確認」にして総務責任者へ相談します。
改善したのは文章の滑らかさではなく、担当者が処理を終えてよい条件です。
ただし、修正版にも、遅延中の記録方法、受渡し後のキャンセル、「要確認」を解決した後の更新方法、最終承認について4項目の確認質問が残りました。
回答を一度追加しても完成とは限りません。
未決事項を業務側で確認し、実際に使えるかを試す必要があります。
この検証は、一つの架空業務を使った初回生成と追加回答による修正です。
作業時間の削減率や現場での使いやすさは測定していません。
出力を自動的に正しいと判定するためのテストでもありません。
入力と出力の全文を確認する
公開前に、
手順どおり作業できるか確認する
誤字の確認だけで終わらず、通常時と例外時を一つずつ試します。
今回の備品貸出なら、次のような確認ができます。
これはこれから実施するための確認表で、本記事で操作テストを完了したという意味ではありません。
- 通常の貸出：初めての担当者が台帳を開き、必要事項を登録し、受取場所を案内できるか。
- 情報不足：終了時刻がない依頼を受けたとき、予約を確定せず利用者へ質問できるか。
- 故障した備品の返却：付属品がそろっていても「返却済み」にせず、確認を依頼できるか。
- キャンセル：別の予約を消さず、該当する記録を更新できるか。
操作に詰まったら、担当者が悪いと判断する前に、台帳の場所、対象の見分け方、完了条件が書かれているか確認します。
画面の操作説明が必要なら、実際の台帳で撮った画像を補います。
AI生成の架空画面を操作の証拠には使いません。
公開する文書には、対象業務・適用部署・版・更新日・承認者を付けます。
申請先やシステムが変わったときに、どの説明を見直すか分かる状態にしてください。
旧版を残す場合も、通常の検索では最新版へたどり着くようにします。
社内資料をAIに
入力する前の注意点
AIの学習をオフにしても、その資料を入力してよいことにはなりません。
会社で認められたサービス・契約・設定と、資料の利用権限を先に確認します。
顧客名だけでなく、取引条件、個人情報、画面に映る通知やファイル名にも注意が必要です。
OpenAIのデータコントロールの説明では、個人向けChatGPTの設定で「すべての人のためにモデルを改善する」をオフにすると、その後の会話が学習に使われなくなるとしています。
また、データ利用方針では、BusinessやEnterpriseなどの業務向け製品は、入力と出力を既定で学習に使わないと案内しています。
ただし、それだけで社内規程や契約上の条件を満たすとは限りません。
最初の検証では、この記事のような架空メモで出力を確認できます。
実資料へ移る前に、入力する内容・閲覧できる人・保存先・削除方法を責任者と確認してください。
判断できない資料は、そのまま外部AIへ貼り付けないようにします。
マニュアルの更新も
仕組みに含める
承認した手順書に合わせて、FAQや引き継ぎ資料の参照先も更新します。
手順が変わったら、対象の手順書番号、元の業務メモ、承認した版を結び付けます。
AIが修正案を作り、実際に作業する担当者が確認してから最新版を公開します。
古い手順書を参照しているFAQや引き継ぎ資料も、更新対象として確認します。
文書を直しただけで全員へ伝わったとは扱わず、必要な担当者への通知と、初回の作業確認まで残します。
一本の手順書を作るだけなら、既存のAIと文書ツールで始められます。
更新する部署が多い、承認待ちが滞る、どれが最新版か分からない、といった問題が出てから、管理の仕組みを検討します。
最初から専用システムを開発する必要はありません。
例えば、業務メモから下書きを作成し、担当者へ不明点を送り、回答と承認を受けて公開する流れをつなぐ方法があります。
自動化する場合も、未承認の文章を公開しないこと、誰が何を変更したか残すこと、失敗した処理を担当者が確認できることを設計に含めます。
手順書を整えた後、探す手間や同じ質問への対応を減らしたい場合は、社内問い合わせをAI化する際の確認点が次の検討になります。
対象業務の選び方から整理する場合は、AI導入の進め方も参考にしてください。
手順書ではなく毎日の報告を短いメモから整えたい場合は、日報の書き方と例文を参照してください。
手順書を後任へ渡す場合は、引き継ぎ書の書き方とExcelテンプレートで次回予定と初回実施の確認も残せます。
まるっとAIでは、業務のヒアリングから専用ツールの設計・開発・改善まで支援しています。
マニュアル作成を含む業務を相談する際は、機密資料を送る前に「何の手順を整えたいか」「どこで担当者が止まるか」をお聞かせください。
既存ツールで対応する範囲と、仕組みを追加する範囲を整理します。
無料で
