Claudeで業務マニュアルを作る手順：旧資料を読ませて作り直す

結論

Claudeで業務マニュアルを作る強みは、すでに社内にある長い文書をそのまま材料にできる点にあります。入社手続きの規程、数年前の手順書、過去の問い合わせ記録をまとめて読ませ、書かれている内容と実際にやっていることの差を先に出します。そこから抜けている操作を指摘させ、読む人の習熟度に合わせて粒度を指定すれば、初稿は目安として1時間ほどで整います。配れる状態になるのは、その作業をしたことがない担当者に通しで実行してもらい、止まった箇所を直した後です。

「このくらいは分かるだろう」が手順書を壊す

手順書の穴は、書き手の善意から生まれます。細かく書くと読みにくいと考えて、慣れた人なら飛ばせる操作を省く。その省略が、新しく入った人にとっては行き止まりになります。

入社者のアカウントを作る作業でいえば、「管理コンソールでユーザーを作成する」の1行の裏に、どの管理者アカウントで入るのか、所属部署をどの単位で設定するのか、既定のグループに入れる操作をいつやるのか、という判断が隠れています。書き手は毎月やっているので、それを判断だと思っていません。自分で読み返しても穴は見えません。読んだ瞬間に記憶が空白を埋めるからです。Claudeに読ませる意味は、社内の事情を一切知らない読み手を用意し、つながらない箇所を指摘させられる点にあります。

この記事では、社員300名の企業の情報システム部門で、月に3名から5名の入社者に対してアカウントを発行し、貸与端末を初期設定するまでの作業を例にします。今は担当者1名が把握していて、その人が繁忙期に休めない、という状態からの出発です。

下準備：作業をしながら、操作ログのように書き出す

思い出して書くと、うまくいった回の手順だけが残ります。実際に次の入社者の準備をするとき、やった操作をその場で1行ずつ書き留めてください。文章にする必要はありません。「管理コンソール、ユーザー追加、姓名とメール、部署はコードで入れる、ここで一度保存しないとグループ設定が出ない」という走り書きで十分です。

つまずいた瞬間こそ書き残します。保存しないと次の項目が出ないといった順序の制約は、書き手が体で覚えていて言葉にしていない情報の代表です。新任者が最初に止まるのもここです。

あわせて社内の関連文書を集めます。入社手続きの規程、前任者が作った設定手順書、情報セキュリティの取り扱い基準、過去の問い合わせ記録。古い文書も捨てません。何が変わったのかを知る材料になります。

具体例1：長い規程と旧手順書を読ませ、実態との差を出す

Claudeには案件ごとに資料を登録しておくプロジェクトという入れ物があり、そこに置いた文書は会話をまたいで参照されます。マニュアル作りは1回で終わらず、退職時の権限削除、端末の返却と続くため、最初に資料と前提を置いておくと2本目以降が軽くなります。プランや時期によって使える機能が異なるため、最新の仕様は公式情報で確認してください。

プロジェクトに置く前提は、この程度で足ります。

このプロジェクトは、当社の情報システム部門の作業手順書を整備するためのものです。
登録した資料は、入社手続き規程、前任者の設定手順書、情報の取り扱い基準です。

【前提】
・社員300名。月に3名から5名の入社がある
・アカウント発行と端末の初期設定は、情報システム部門の担当者1名が行っている
・社内の言葉では「貸与端末」「初期設定」と呼んでいる

【守ってほしいこと】
・私が伝えていない設定値、権限、日数を事実として書かない。「要確認」と書いて空欄にする
・資料に書かれていない手順を勝手に足さない。足したい場合は本文と分けて提案する
・手順を書くときは、どの資料の何章から読み取ったかを併記する
・カッコを使った補足や英語の併記をしない。用語は文中で言い直す

資料を登録したら、実態との差を出させます。

登録した資料と、私が貼り付けた作業メモを読んでください。
作業メモは、直近の入社者1名分の準備をしながらその場で書いたものです。

【やってほしいこと】
1. 資料に書かれている手順と、作業メモの実際の操作を突き合わせる
2. 資料にはあるが、実際には行われていない作業を挙げる
3. 実際には行われているが、資料のどこにも書かれていない作業を挙げる
4. 資料の中で、記述が互いに食い違っている箇所を挙げる
5. 資料に書かれた設定値のうち、現在も有効かを確認すべきものを挙げる

【条件】
・それぞれ、どの資料の何章と、メモのどの行を根拠にしたかを書く
・どちらが正しいかは判断せず、差があるという事実だけを示す
・この段階では手順書の本文を書かない

3番に並ぶ項目が、いちばんの収穫です。毎回やっているのに文書化されていない操作は、担当者の頭の中だけにあります。「部署コードを人事から受け取ってから作業を始める」といった手順が、ここで表に出ます。

4番の食い違いも見つかります。規程では入社日の3営業日前までに準備すると書かれているのに、旧手順書は前日でも間に合う前提になっている。片方だけが改定されて放置された跡です。気づいた時点で、どちらを正とするかを責任者に確認します。

抜けている操作を指摘させる

差分が出たら、読み手を入れ替えて手順を読ませます。

ここまでに整理した手順一覧を、次の人になったつもりで読んでください。

・今月この部門に異動してきた社員
・管理コンソールを触った経験がない
・当社の部署構成も権限の考え方も知らない
・担当者が不在で、聞ける相手がいない

この人がこの手順だけで作業したとき、手が止まる箇所を挙げてください。

【条件】
・「どこで止まるか」と「何が書かれていないから止まるか」を分けて書く
・止まる可能性の高い順に並べ、10点以内に絞る
・必要な情報を誰から受け取るか、設定が正しくできたと判断する方法、
　自分の権限でやってよい範囲、失敗したときの戻し方の4つは、
　書かれているかを必ず確認する
・書かれていない内容を推測で補わず、質問の形で返す

返ってくるのは、「ユーザーを作成するとありますが、どの管理者アカウントで入るのかが書かれていません」「グループに追加するとありますが、どのグループが標準なのかが分かりません」といった指摘です。4つの観点を名指しするのは、これらが経験者の頭から抜けやすいからです。とりわけ失敗したときの戻し方を書いた手順書は少なく、新任者が誤った設定をそのまま残す原因になります。

答えられる指摘はその場で埋め、答えが決まっていないものは責任者と決めます。「新任者がどこまで自分の判断で設定してよいか」が定まっていないと分かった時点で、この作業は権限設計の見直しに変わります。

読む人に合わせて、説明の粒度を変える

渡す相手によって必要な情報量が違います。粒度を指定しないと、どの相手にも中途半端な長さで返ってきます。

読む人	指示に入れる条件	1手順あたりの目安
異動してきたばかりの担当者	1操作ごとに1文。画面名と設定値を毎回書く	3文から5文
繁忙期だけ手伝う他部門の社員	触ってよい範囲を先に示し、それ以外は引き継ぎにする	2文と注意1行
作業を委託する外部の事業者	判断を挟まず、手順と合否の基準だけを書く	条件と手順の表
担当を引き継ぐ後任者	手順より、設計の意図と過去の経緯を厚くする	事例つきの解説

指定するときは、相手の肩書きではなく、その人が何を知らないかを書くほうが正確に伝わります。

整理した手順に本文をつけてください。

【読む人】
・今月この部門に異動してきた社員
・管理コンソールの画面を見たことがない
・「権限グループ」「初期化」といった社内の言い方を知らない

【書き方の条件】
・1つの操作につき1文。2つの操作を1文に入れない
・設定値を入力する箇所は、何を入れるかと、その値をどこから得るかを書く
・正しく設定できたかを確かめる操作を、手順の中に組み込む
・社内の言い方を使うときは、その場で普通の言葉に直す。カッコを使った補足はしない
・私が伝えていない値は「要確認」と書いて空欄にする
・1手順は5文以内に収める

【出力形式】
・手順は番号つきで並べる
・例外や条件つきの作業は本文から外し、末尾に一覧としてまとめる

確認の操作を手順に組み込ませる指示が、この種の作業では効きます。設定した直後に「一覧画面に戻り、作成したユーザーが所属部署つきで表示されていることを確かめる」という1文があるだけで、翌日の問い合わせが減ります。見出しや章立てをそろえる指定は、Claudeで文章の書式を整える手順で使った条件がそのまま流用できます。

画面の操作を文章でどう書くか

管理画面は更新が頻繁で、画像を貼った手順書はすぐ古くなります。文章側の型を決めておくと、画像が古くなっても手順が読めます。

アカウントを作成する操作を文章にしてください。私の説明は以下です。

【操作の内容】
管理コンソールにログインし、左の一覧からユーザーを選ぶ。
新規追加を押すと、姓名とメールアドレスを入れる欄が出る。
部署は自由入力ではなく、人事から受け取ったコードを選ぶ。
ここで一度保存しないと、権限グループを選ぶ欄が出てこない。
保存後に権限グループの欄が出るので、標準の入社者用を選んで確定する。

【書き方の型】
・1文を「どこを見て」「何をして」「どうなったら次へ進むか」の順に組み立てる
・画面名や欄の名前は、実際に表示されている文字をそのまま書く。
　私が伝えていない名称は「要確認」と書いて空欄にする
・ボタンや項目は、位置ではなく表示名で指し示す。
　「右上のボタン」のような書き方はしない
・操作の順序に制約がある箇所は、なぜその順番なのかを1文で添える
・画像を差し込む箇所には、何を写した画像が必要かを1行で指定する

順序の理由を書かせる指示が、この作業では効きます。「保存しないと権限グループの欄が出ない」と理由が添えてあれば、新任者は欄が見つからないときに手を止めません。位置ではなく表示名で指す書き方は、画面の配置が変わっても生き残ります。

具体例2：成果物を別画面に出し、章ごとに育てる

手順書は修正の回数が多く、会話の中に全文を出させると、直すたびに長い出力が流れて前の版が埋もれます。Claudeには成果物を別画面に出す機能があり、手順書の本体を横に置いたまま会話を続けられます。「手順7だけ、権限グループの確認操作を足して書き直してください」と頼めば、その章だけが差し替わります。

別画面に出すときは、章の並びを先に決めておきます。

ここまでの内容を、作業手順書としてまとめてください。
編集しやすいように、別画面の文書として出力してください。

【構成】
1. この手順書が扱う範囲と、扱わない範囲
2. 作業を始める前にそろえるもの … 誰から何を受け取るかを表にする
3. アカウント発行の手順
4. 貸与端末の初期設定の手順
5. 設定が正しく終わったことを確かめる項目 … 一覧で並べる
6. うまくいかないときの対処と、戻し方
7. 引き継ぎと連絡先 … 部署名と、渡すときに伝える情報
8. 未確定の事項 … 私が確認して埋める箇所と、確認先を併記する

【条件】
・私が伝えていない設定値、日数、権限は書かず「要確認」と記す
・3章と4章は同じ並びにする
・各章の冒頭に、その章を読むべき場面を1行で書く

8章の未確定事項の一覧が、そのまま次の数日のやることになります。本体が別画面に残っていると、責任者に画面を見せながらその場で埋めていけます。

通しで実行してもらい、止まる箇所を記録する

初稿はまだ手順書ではありません。検証は、その作業をしたことがない人に実際にやってもらう以外に方法がありません。

1. アカウント発行をしたことがない人を1人選びます。他部門の社員でも構いません。
2. 印刷した手順書だけを渡し、口頭で補足しないと先に伝えます。
3. 本番ではなく、検証用に作った架空の入社者1名分で通します。
4. 書き手は横で黙って見て、止まった時刻と箇所だけを記録します。
5. 終わったら、迷わなかったが不安だった箇所を本人の言葉で聞き取ります。

記録をそのままClaudeに渡して直します。

作成した手順書を、この作業の未経験者に通しで実行してもらいました。
止まった箇所と本人の発言を貼ります。該当手順を書き直してください。

【止まった箇所と本人の発言】
・手順1「管理コンソールにログインする」→「どのアカウントで入るのか分からない」
・手順4「部署コードを選ぶ」→「一覧に似たコードが並んでいて、どれか判断できない」
・手順6「権限グループを選ぶ」→「欄が表示されず、先に進めなかった」
・手順10「初期設定を終える」→止まらなかったが「終わった判断が合っているか不安だった」

【条件】
・該当する手順だけを書き直し、他は変更しない
・私がまだ答えを伝えていない箇所は「要確認」で空欄のまま残す
・「不安だった」と言われた箇所は、確認できる操作を1つ足す形で直す
・直した理由を各手順の後ろに1行つける

止まらなかったが不安だった箇所を分けて扱うのが狙いです。不安は、次の人が止まる場所の予告になります。職種の単位で同じ進め方を組み立てた例は、情報システムの業務マニュアルをAIで作る手順にあります。

更新を止めないための決めごと

手順書が使われなくなるのは、内容が現状と合わなくなるからです。決めるのは、誰が直すか、いつ見直すか、変更をどこで知るかの3つだけです。担当を個人名ではなく役職で決め、見直しを四半期の予定に入れ、システムの設定や規程を変えた人が手順書の担当に連絡する経路を作ります。

Claudeは、変更の反映そのものより、変更が他の章に及ぼす影響を洗い出すのに向いています。

プロジェクトに登録した運用中の手順書を読んでください。次の変更が入りました。

【変更】
・入社者用の権限グループが、部署ごとの3種類に分かれた
・貸与端末の初期設定が、配布前に一括で済ませる方式に変わった
・入社日の前日までに準備を終える運用になった

【やってほしいこと】
1. 変更に直接かかわる手順を書き直す
2. 変更の影響で意味が通らなくなる他の章を挙げる
3. 不要になった手順を挙げる。削除するかは私が決める
4. 新しく必要になる手順があれば、提案として本文と分けて出す
5. 改訂履歴に書く1行を作る。日付は空欄にする

3番と4番を分けるのは、削除と追加の判断を人が持つためです。使われていないように見える手順が、監査で求められる記録の裏づけだったという事態は起こります。

うまくいかないときの対処

長い資料を読ませると、後半の内容が薄くなる。 章ごとに分けて読ませ、章単位で要点を出させてから統合するほうが安定します。

設定値がもっともらしく埋まってしまう。 前提に書いた「伝えていない値を書かない」という条件は、会話が長くなると効きが落ちます。文書を作らせる直前に同じ条件を書き添え、出力後に数字と設定値だけを拾って自分の記録と突き合わせてください。

手順の粒度が途中で変わる。 書き直しのたびに「1つの操作につき1文」という条件を添えます。全文を出し直させるより速く終わります。

一般的なIT運用の作法が混ざる。 社内で採用していない考え方が入ることがあります。「資料に書かれていない手順を足さない」と前提に書き、それでも混ざるなら、出力の直後に「この手順のうち、資料に根拠がないものを挙げてください」と聞き返すと自分で申告します。

責任者の確認を経てから公開する

Claudeが出した手順書は、まだ誰の承認も得ていない下書きです。公開の前に、現在の担当者が全文を読んで画面名と設定値を確かめ、権限に関わる章は部門の責任者が範囲を確認します。取り扱い基準に触れる記述は、情報セキュリティの担当にも目を通してもらいます。実在の社員名や検証に使ったアカウント名が残っていないかも、この段階で外します。

他のツールで同じ作業を進める手順は、ChatGPTで業務マニュアルを作る手順とGeminiで業務マニュアルを作る手順にまとめています。

まとめ

次の入社者の準備をするとき、操作を1行ずつその場で書き留めるところから始めてください。社内にある規程と旧手順書をClaudeのプロジェクトに登録し、書かれている内容と実際の操作の差を出させます。異動してきたばかりの人になったつもりで抜けを指摘させ、答えられない指摘は責任者と決めます。成果物を別画面に出して章ごとに育て、この作業をしたことがない人に架空の入社者1名分で通してもらいます。プロジェクトに置いた前提と資料は、退職時の権限削除や端末の返却の手順書を作るときにそのまま使えます。