生成AIで社内マニュアル・手順書を作り、更新し続ける運用。元の手順の集め方、画面の変更への追従、版の管理、古い手順の廃止

この記事の結論：生成AIで社内マニュアル・手順書を作るときは、AIに一から考えさせず、画面の録画と作業する人の口頭の説明のような「元の手順の記録」を集めてから、決まった形の下書きに直させます。AIには記録にない操作を足させず、分からない所は「不明」と書かせ、実際に作業する人が操作しながら確かめてから公開します。公開した手順書には、対象の画面・版・持ち主・次に見直す日を持たせ、手順書に書いたボタンや入力欄の名前が画面に残っているかを自動テストで見張って、変わったときだけ直します。版の履歴には変えた理由を残し、古い手順は消さずに「廃止」の状態にして新しい手順書へ案内します。

想定している読み手は、社内の業務システムやクラウドサービスの手順書を抱えていて、生成AIで作る・直す手間を減らしたい会社の担当者と、その仕組みを組むエンジニアです。社内の文書から探した内容をAIが答える仕組みや、プロンプトのテンプレートの作り方は扱わず、手順書そのものを作り、保ち、終わらせる運用に絞ります。

生成AIで手順書を作る前に、元の手順を「記録」として集める

生成AIで社内マニュアル・手順書を作るとき、最初にやるのはAIへの指示ではなく、元の手順の記録集めです。AIは、渡された材料にない操作を、もっともらしく補って書いてしまうことがあるためです。

集める記録は、次の3種類です。

録画は、作業に慣れた人が手を止めずに操作すると、何をしているのかが映像から読み取れないことがあります。「いま締め日を確かめています」のように、目で確かめている所も口に出してもらうと、AIが手順に起こしやすくなります。

録画や文字起こしを外部のAIサービスに渡すときは、入力したデータが学習に使われない設定かを確かめてから使います。

手順書は、決まった形と管理の項目を持たせて書かせる

手順書は1本ごとに、目的・前提・手順・確かめ方の決まった形と、版や持ち主のような管理の項目を持たせます。形がそろっていれば、AIに書かせるときの指示も、人が確かめるときの見方も一つで済みます。

手順書の頭に置く管理の項目は、次のようにします。

id: keihi-shinsei-01
title: 経費の申請を出す
system: 経費精算システム
screens:            # この手順書が操作する画面（自動テストと結び付ける）
  - expense-new
  - expense-confirm
version: 3
status: published   # draft / published / deprecated
owner: 経理担当
reviewed: 2026-10-03
next_review: 2027-01-31
replaced_by: null   # 廃止したときに、案内する先の手順書の id
sources:            # 下書きの元にした記録
  - 録画 2026-09-30 経理担当
generated_by_ai: true
approved_by: 経理の責任者

本文は、次の4つの見出しで書かせます。

1. 目的。 この作業で何が終わるのか
2. 前提。 必要な権限、始める前にそろえる書類、作業できる期間
3. 手順。 1つの番号に1つの操作。ボタンや入力欄は、画面に出ている名前のとおりに書く
4. 確かめ方。 作業が終わったことを、どの画面のどの表示で確かめるか

手順の中で、ボタンや入力欄を画面の表示どおりの名前で書いておくことが、後で画面の変更を見張るときの手がかりになります。

AIへの指示は、記録にない操作を足させず、分からない所を書かせる

手順書の下書きを作らせる指示では、記録にない操作を足さないこと、分からない所は「不明」と書くこと、手順ごとにどの記録のどこを元にしたかを示すことを求めます。

指示の例は、次のとおりです。

あなたは社内の手順書を下書きする担当です。
以下の <記録> だけを材料にして、決まった形の手順書を書いてください。

守ること:
- <記録> に出てこない操作、画面、ボタンの名前を書かない
- 記録から判断できない所は「【不明】」と書き、推測で埋めない
- 手順の番号ごとに、元にした記録と時刻（例: 録画 03:15）を括弧で付ける
- ボタンや入力欄の名前は、記録の中で読み上げられた表示のとおりに書く
- 個人の名前、顧客の情報、パスワードは書かない

形:
## 目的 / ## 前提 / ## 手順 / ## 確かめ方

<記録>
（録画の文字起こし、既存のメモ、例外の聞き取りを貼る）
</記録>

下書きができたら、公開の前に人が2つのことを確かめます。

• 操作しながら読む。 その作業を普段しない人が、手順書だけを見て練習用のデータで最後まで操作できるか
• 不明の所を埋める。 「【不明】」の箇所を作業者に聞いて直し、元にした記録の欄に聞き取りを足す

手順ごとに元の記録の時刻が付いていれば、確かめる人は録画のその場面だけを見直せば済みます。元の記録が示されていない手順は、AIが補った可能性があるものとして扱います。

画面の変更は、手順書に書いた名前が画面に残っているかを自動で見張る

手順書が古くなる一番の原因は、システムの画面の変更です。手順書に書いたボタンや入力欄の名前が、いまの画面にも残っているかを自動テストで見張ると、変更に気づくのを人の記憶に頼らずに済みます。

自社で動かしている業務システムなら、PlaywrightのARIAスナップショットで、画面にある見出し・入力欄・ボタンの役割と名前を確かめられます。手順書の screens に書いた画面ごとにテストを1本置き、手順書の中で使っている名前だけを書きます。

// tests/manual-screens/expense-new.spec.ts
// この画面を参照している手順書: keihi-shinsei-01
import { test, expect } from '@playwright/test';

test('expense-new: 手順書に書いた名前が残っている', async ({ page }) => {
  await page.goto('/expenses/new');
  await expect(page.getByRole('main')).toMatchAriaSnapshot(`
    - heading "経費の申請"
    - textbox "支払日"
    - combobox "勘定科目"
    - button "申請する"
  `);
});

ARIAスナップショットでは、名前を省いたり正規表現で書いたりして、一部だけを一致させることができます。日付や件数のように毎回変わる表示は、手順書の確かめ方に関係しなければ書かずにおきます。見た目の画像で比べる toHaveScreenshot もありますが、Playwrightの文書にあるとおり、画像はOSやブラウザなどの環境で変わるため、手順書の言葉の追従には、名前を比べる方を先に使うのが扱いやすいと考えています。

テストが落ちたら、その画面を参照している手順書を一覧にして、持ち主に直してもらいます。

// scripts/manuals-for-screen.ts
// 使い方: npx tsx scripts/manuals-for-screen.ts expense-new
import { readFileSync, readdirSync } from 'node:fs';
import { parse } from 'yaml';

const screen = process.argv[2];
const dir = 'manuals';

for (const file of readdirSync(dir).filter((f) => f.endsWith('.md'))) {
  const text = readFileSync(`${dir}/${file}`, 'utf8');
  const head = text.match(/^---\n([\s\S]*?)\n---/);
  if (!head) continue;
  const meta = parse(head[1]);
  if (meta.status === 'published' && meta.screens?.includes(screen)) {
    console.log(`${meta.id}\t${meta.title}\t持ち主: ${meta.owner}`);
  }
}

外部のクラウドサービスのように、自社でテストを流しにくい画面は、提供元の更新のお知らせを担当者が受け取るようにし、お知らせが来たらその製品を system に持つ手順書を同じ方法で一覧にします。

版は履歴の残る場所で持ち、変えた理由とAIの関与を残す

手順書の版は、Gitや文書管理のサービスのように変更の履歴が残る場所で持ち、版を上げるたびに変えた理由を書きます。誰がいつ何を変えたかを後から追えないと、作業の間違いがあったときに、手順書のせいか作業のせいかを切り分けられません。

版の上げ方は、変更の大きさで分けておきます。

AIに下書きや直しをさせた版は、generated_by_ai と approved_by の欄で、AIが関わったことと、公開を認めた人を残します。総務省・経済産業省のまとめた「AI事業者ガイドライン」は、AIを使う事業者を含めた共通の指針に透明性とアカウンタビリティを挙げています。手順書の場合、AIが書いた部分を誰が確かめて公開したかを記録に残すことが、その手がかりになります。

古い手順は消さずに「廃止」にして、新しい手順へ案内する

使わなくなった手順書は、すぐに消さず、状態を「廃止」にして、代わりの手順書への案内を付けます。古い手順への社内のリンクやブックマークが、行き止まりにならないようにするためです。

廃止の流れは、次のとおりです。

1. 代わりを決める。 新しい手順書があれば replaced_by にその id を書く。業務そのものがなくなったなら、その旨を本文の先頭に書く
2. 状態を変える。 status を deprecated にし、本文の先頭に「この手順は使いません」と、廃止した日と理由を書く
3. 検索の対象から外す。 社内のポータルの一覧や、社内の文書を探して答えるAIの、検索の対象からも外す
4. 保存の期間を決める。 過去の作業を確かめるために残す期間を決め、過ぎたら消す

3つ目の、AIの検索の対象から外す作業は忘れられやすい所です。原本を廃止にしても、検索の索引に古い断片が残っていると、AIが古い手順で答えてしまいます。原本の変更を索引に反映し、消した文書が外れたことまで確かめる流れは、RAGを小さく作るときの構成をまとめた記事で扱っています。

定期の見直しは、次の見直し日と使われ方から順番を決める

画面の変更を見張っていても、業務の決まりの変更のように画面に出ない変更は見つかりません。手順書ごとに次に見直す日を持たせ、その日が来たものから持ち主に確認を頼みます。

見直しの順番は、次の情報から決めます。

• 次の見直し日を過ぎたもの。 持ち主に、内容がいまの業務と合っているかを確かめてもらう
• よく読まれているもの。 読まれる回数が多い手順書ほど、間違いの影響が大きい
• 問い合わせが来たもの。 「手順書のとおりにやったができない」という声があった手順書
• 持ち主がいなくなったもの。 異動や退職で持ち主が空いた手順書は、新しい持ち主を決めるまで見直しの対象にする

見直しで内容が変わらなかったときも、reviewed と next_review の日付を更新します。日付が更新されていれば、少なくともその日には誰かが確かめた、ということが読む人にも伝わります。

社内で回し始める順番

一度にすべての手順書をAIで作り直そうとすると、確かめる人の手が足りなくなります。次の順で、小さく始めて広げます。

1. 対象を絞る。 よく使われ、画面の操作が中心の業務を3本ほど選ぶ
2. 形を決める。 管理の項目と本文の4つの見出しを決め、置き場所を1か所にする
3. 記録を集めて下書きする。 録画と聞き取りから、AIで下書きを作る
4. 操作しながら確かめて公開する。 作業者以外の人が手順書だけで操作できるかを確かめる
5. 画面の見張りを付ける。 公開した手順書の画面ごとに、自動テストを1本置く
6. 見直しの日を回す。 次の見直し日が来たものを、毎月まとめて持ち主に知らせる

株式会社bundlyzeでは手順書が対象にする業務システムそのものについて、要件定義に始まり保守運用までを請け負っており、手順書の置き場所や画面の見張りを、システムの改修と同じ流れに組み込む形でもご相談いただけます。生成AIを業務の流れに組み込む進め方は、AIを使った業務の仕組みづくりのページにまとめています。

出典

参照した文書は、どれも2026-10-03に開いて確かめました。ツールの機能も指針も版が進むので、導入の前には最新版に当たってください。

• Playwright「Aria snapshots」：toMatchAriaSnapshot、一部の一致と正規表現、–update-snapshots での更新
• Playwright「Visual comparisons」：toHaveScreenshot と、環境による描画の違い
• 総務省の公表ページ（AI事業者ガイドライン）：第1.2版（2026年3月31日）、共通の指針