プロンプトガイド
Claudeで標準作業手順書を書く方法
良いSOPは、そのタスクを一度もやったことがない人でも最初から正しく実行できるようにする。
Anthropic社のClaudeは、あなたが既にやり方を知っているプロセスを、不慣れな人が実際に従える標準作業手順書に変えることに優れています。番号付きの手順、明確な停止点、そして人々がつまずく例外事項などです。しかし、あなたの頭の中だけに存在するプロセスの部分、書き留めたことのない例外、チームが実際に使用している特定のツールや名前については、あなたがその詳細を伝えない限り、Claudeは知ることができません。解決策は、隣に立つ新入社員に説明するように、Claudeに実際のプロセスを案内することです。誰かに一言で何をしているか聞かれたときに答えるような、整理されたバージョンではありません。
Claudeに標準作業手順書を書くよう依頼するには、実際に行っている通りにプロセスを段階的に説明し、関係するツール、システム、正確な名前を含めて、番号付きの手順として明確な開始点と終了点とともに書式化するよう依頼してください。次の手順が条件に依存する例外、よくある間違い、または決定ポイントを指摘し、あなたが指定しなかったために詳細を推測する必要があった手順にはフラグを立てるようClaudeに依頼してください。最終版として扱う前に、できればタスクを実行しながら、一度ドラフトを実際のプロセスと照らし合わせて確認してください。
公開日
無料レッスン · アカウント不要Claudeと出会うなぜClaudeなのか?6 分無料レッスンを始める要点まとめ
- プロセスを整理された要約バージョンではなく、実際にやっている通りに説明する。自分にとって自動的なためにスキップする手順こそ、新入社員が書面で必要とするものです。
- Claudeに本当の名前を伝える:特定のツール、正確なフィールド、ログインするシステム。「システムを更新する」という手順は、どのシステムかをまだ知らない人には無意味です。
- 決定ポイントを明示的に指摘する。分岐があるプロセス、「依頼が500ドル未満ならXをする。そうでなければYをする」は、その分岐を明確に述べる必要があり、あなただけが持つ文脈から暗示されるだけでは不十分です。
- 明確な開始点と終了点を依頼する。タスクがいつ始まり、いつ本当に完了するかを述べていないSOPは、読者に終わったかどうかを推測させることになります。
- 公開する前に一度タスクを実行しながらドラフトを見直す。画面上では良く見えるが手順を一つ省略しているSOPは、誰かが実際に順番に従おうとしたときにしか明らかになりません。
- 通常のケースを例外から分ける。主要な手順の中に例外ケースを埋め込むと、例外が適用されない時間の九割において、通常のケースが追いにくくなります。
コピーして使える
今日から使えるプロンプト
プロセスのウォークスルーから最初のドラフトを作成する
[タスク]をどのように行うか、関係する正確なツールとシステムを含めて段階的に説明します。[できるだけ詳細にプロセスを説明してください。ツール名、フィールド名、途中で確認することすべてを含めて]。これを、明確な開始点とタスクが完了する明確な点を持つ番号付きSOPに変換してください。私が指定しなかったために詳細を推測する必要があった手順にはフラグを立ててください。
実際にやっている通りにプロセスを説明してください。通常声に出して言わない小さな習慣的な確認を含めて。それらはしばしば新入社員が欠けている手順です。
手順が依存する決定ポイントを追加する
これが私のSOPのドラフトです:[ドラフトを貼り付け]。手順4は実際には条件によって分岐します:[条件]ならば次の手順は[X]です。そうでなければ[Y]です。手順4を書き直して、その分岐を明確に述べ、SOPに従う人が続行する前にどちらの道が自分に当てはまるかを知ることができるようにしてください。
実際のプロセスのすべての分岐でこれを行ってください。決定ポイントを単一の手順内に隠すSOPは、誰かが間違った道を進む最も一般的な理由です。
通常のケースを例外から分離する
これが[タスク]のための私のSOPのドラフトです:[ドラフトを貼り付け]。[例外を説明]のような異常な状況でのみ適用されるものを、最後に別の「例外」セクションに抜き出してください。そうすれば、主要な番号付き手順は通常のケースのみを説明します。現在のケースが通常のパターンに当てはまらない場合にどこを確認すべきかを示す短い指示を主要な手順に残してください。
これにより、ごく一部のケースにのみ当てはまる例外ケースをすべての読者が読み進める必要がなくなり、通常の道筋が追いやすくなります。
ギャップを探すためにSOPをストレステストする
このタスクを今まで一度もやったことがなく、初めて従うものとしてこのSOPのドラフトを読んでください:[ドラフトを貼り付け]。各手順で、述べられていないために知る必要があること、定義されていない用語、または次の手順に移る前に正しくその手順を行ったか不確かになる点を教えてください。
これは、あなたがすでにプロセスを知っているために見えないギャップを浮き上がらせます。新鮮な視点は、慣れが隠すものを捉えます。
プロセスが変わった後にSOPを適応させる
これが[タスク]の既存のSOPです:[現在のSOPを貼り付け]。プロセスが変わりました:[今何が違うかを説明]。新しいプロセスを反映するようにSOPを更新し、チームが既に知っているバージョンと何が違うかを見られるように、どの手順が変わったかを正確に指摘してください。
古い手順を黙って置き換える代わりに、何が変わったかを指摘することは、以前のバージョンを記憶していた人々が実際に何が違うかに気づくのを助けます。
構造
従えるSOPが本当に必要とするもの
これらは、タスクに不慣れな人が最初の試みで正しく完了できるようにする要素です。
明確な開始点と終了点
タスクが正確にいつ始まり、本当に完了したときどう見えるかを述べる。終了点が定義されていないSOPは、読者に終わったか手順を見落としたかを推測させます。
本当のツールに本当の名前
一般的な説明ではなく、チームが使用している実際のシステム、フィールド、ツール名を使う。「依頼を開く」は、読者が依頼がどこにあるかを既に知っている場合にのみ有用です。システムを名指ししてください。
明示的に述べられた決定ポイント
プロセスが条件によって分岐する場合、暗示するのではなく、手順の中で直接それを述べる。隠された分岐は、誰かが間違った道を進む最も一般的な理由です。
主要な手順から分離された例外
通常の道筋を短くきれいに保ち、例外ケースを独自のセクションに移す。主要な手順に例外を埋め込むSOPは、通常のケースを追いにくくします。
あなたがスキップする手順
一言で説明するプロセスがClaudeに与えるべきプロセスではない理由
このタスクについて何をしているか誰かに聞かれたら、おそらく一つか二つの文で要約するでしょう:「依頼を確認し、アカウントを確認し、返金を処理する」。その要約は正確であり、同時に新入社員が実際に必要とするほぼすべてを欠いています。なぜなら、自動的に行う小さな確認、ちらっと見る特定のフィールド、続ける前に常に確認すること、それらは繰り返しによってあなたにとって見えなくなっているからです。それらは、初めてタスクを行う人には見えないものではありません。
これが、技術的に正しいとしても最初のSOPドラフトが薄っぺらに感じられるギャップです。Claudeはあなたが伝えたことだけを書き留めることができ、プロセスの整理された要約バージョンを説明すると、番号付き手順として書式化された整理された要約が返ってきます。仕事に不慣れな人が従えるような実際の手順ではありません。解決策は、隣に立つ新入社員を案内するようにプロセスを語ることです。言及するには明白すぎると感じる部分も含めてです。
それらの見えない手順を浮き上がらせる有用なコツは、後で記憶から要約するのではなく、実際に声に出して語りながら一度タスクを実行すること、またはプロンプトの中でそれに近いことをすることです。習慣的な確認は、生きたプロセスをたどっているときに自然に浮かび上がる傾向があります。後で記憶から思い出すときには消える傾向があります。なぜなら記憶は要約を保持し、その要約を真実にした小さな動きを落としてしまうからです。
よくある間違い
SOPが初めて実際に使われたときに失敗する原因
これらは、合理的に見える文書を、本物の不慣れなユーザーとの接触に耐えられない文書に変えるギャップです。
本当の名前の代わりに曖昧なツール参照
「システムに更新を記録する」は、どのシステム、どの画面、どのフィールドかをまだ知らない人には何の意味もありません。毎回実際のツールを名指ししてください。
1つの手順の中に隠された決定が埋め込まれている
手順が述べられていない条件に密かに依存している場合、読者は自分の状況にどちらの道が当てはまるかを、簡単に方向転換できる手遅れになるまで知ることができません。
タスクに終了点が述べられていない
SOPが「完了」がどう見えるかを述べていない場合、読者は続けるべきか、最後に書かれた手順の後に来る手順を見落としたのかを推測することになります。
例外が主要な手順と混在している
通常の手順の真ん中に置かれた例外ケースは、通常のケースにいる人も含めて、すべての読者に続行する前にそれが当てはまるかどうかを判断させることになります。
関連資料を一緒に保つ
SOPが関連文書と一緒に存在することから利益を得る理由
標準作業手順書が単独で存在することはほとんどありません。通常、準拠しなければならない方針、置き換えた以前のバージョン、または異なるが関連するタスクのための関連手順を参照します。それらの文書を作成中に近くに保つことは、SOPを孤立して書き、他のすべてと一致することを願うよりも、結果をより一貫性のあるものにします。Claudeのプロジェクト機能を使えば、関連ファイルのセットを一つの場所に保つことができ、SOPに関する各会話が、毎回貼り直す必要なく同じ背景資料を参照できます。これはsupport.claude.comのプロジェクトのヘルプページに記載されています。
これは、SOPが手順自体とは独立して変化する方針文書と一致し続ける必要があるときに最も重要です。方針がしきい値を設定する場合、例えばどの承認経路が適用されるかを決定する金額のような場合、方針とSOPを同じプロジェクトに保つことで、一方の将来の更新を他方に対して確認しやすくなります。数ヶ月後に、実装すべき手順と方針が静かにずれていることを発見するのではなく。
これは、チームが同じタスクの変種のために複数の関連SOPを維持している場合にも役立ちます。例えば、標準的な依頼のための手順と、迅速な依頼のための2番目の手順です。両方を同時に見ることができると、共有された手順の表現を一貫して保ち、それらの間の違いを偶発的ではなく意図的なものにしやすくなります。これは、二人がそれぞれ同じ基礎プロセスであるはずのものの異なるバージョンを更新している場合に、聞こえるよりも重要です。
公開する前に
SOPが公式バージョンになる前に確認すべきこと
デスクで読むだけでなく、実際にタスクを実行しながらドラフトを見直してください。画面上で完全に見える手順は、しばしば自動的に行っている小さな行動を省略していることが判明します。そのギャップは、最初から最後まで黙って読むよりも、キーボードに手を置いているときの方がはるかに明白です。
すべてのツール名、フィールド名、システム参照を、今実際に画面上にあるものと照らし合わせて確認してください。インターフェースは変わりますし、名前が変更されたボタンや廃止されたシステムをまだ参照しているSOPは、新入社員にもう存在しないものを探させることになります。これは手順が欠けているよりも悪い失敗です。なぜなら、それは文書のミスではなく彼ら自身のミスのように見えるからです。
可能であれば、タスクを一度もやったことがない人にドラフトを渡し、どこで躓くかを観察してください。プロセスに本当に不慣れな人が止まって「待って、ここで何をするの?」と尋ねる点は、SOPが実際にギャップを持つ場所の最も信頼できる信号です。自分自身の再読よりも信頼できます。なぜなら、あなたはその人が読むようにそれを読むためにプロセスを忘れることができないからです。
Claudeは詳細なウォークスルーを素早くきれいな番号付き手順に変えることができますが、その手順が実際に仕事がどのように行われるかと一致しているか、そして新しい人が質問することなく従うのに十分完全であるかという判断は、実際のタスクに対する本当のテストランでしか確認できないことです。
良いSOPは最初の本当のユーザーを生き延びる
他の人が実際に従えるように十分な詳細でプロセスを説明することは、特定の文章作成スキルです。Nightschool AIの無料レッスンは、Claudeを使った実際の職場での文章作成タスクを扱っています。何を詳しく説明し、何を別の例外セクションに残すかについての判断も含めてです。
よくある質問
ClaudeがSOPを作成する前に伝える最も重要なことは何ですか?
実際に行っている通りにプロセスを案内してください。実際のツールとフィールドの名前、そして通常声に出して言わない小さな習慣的な確認を含めて。それらの見えない手順こそ、新入社員が本当に必要とするものです。
条件に依存する手順をどう扱うべきですか?
手順の中で分岐を明示的に述べてください:条件が真ならば一つのことをし、そうでなければ別のことをする。単一の手順の中に埋め込まれた隠された決定は、誰かが間違った道を進む最も一般的な理由です。
例外は主要な番号付き手順に混ぜるべきですか?
いいえ。通常の道筋を短く保ち、例外ケースを別の例外セクションに移してください。現在のケースが通常のパターンに当てはまらない場合にどこを確認すべきかを示す短い指示を主要な手順に残してください。
自分のSOPドラフトに本当にギャップがあるかどうかをどう知りますか?
物理的にタスクを実行しながら見直すか、プロセスに不慣れな人がするようにClaudeに読んでもらい、定義されていないものにすべてフラグを立ててもらってください。両方とも、プロセスを既に知っている状態では見えないギャップを浮き上がらせます。
ClaudeはSOPを関連する方針文書と一致させるのを助けられますか?
両方を同じClaudeプロジェクトに保つことは、support.claude.comのプロジェクトのヘルプページに記載されているように、作成中に方針を参照しやすくし、後で両者の間のずれを確認しやすくします。
SOPはタスクがいつ完了するかについて何を述べるべきですか?
明確な終了点を述べてください:タスクが本当に完了したときに正確にどう見えるか。それがなければ、読者は終わったか、最後に書かれた手順の後に来るはずの手順を見落としたのかを推測することになります。
実際のプロセスが変わった後、SOPをどう更新すべきですか?
Claudeに既存のSOPを与え、今何が違うかを説明し、どの手順が正確に変わったかを指摘するよう依頼してください。それは、古いバージョンを記憶していた人々が文書全体を再学習する代わりに、実際に何が違うかに気づくのを助けます。
公開前に誰がSOPドラフトを見直すべきですか?
可能であれば、タスクを一度もやったことがない人です。彼らが躓く場所や次に何をすべきか尋ねる場所は、自分自身の再読よりも本当のギャップの信頼できる信号です。プロセスに不慣れな人が読むようにそれを読むことはできないからです。