公式スキル · 業務管理・総務
説明や録画から業務手順書（SOP）を作る
説明や画面録画の文字起こしを、きっかけ、役割、画面のラベルどおりの手順、判断の分かれ目、チェック、管理者のそろった SOP にする。
Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。
使う場面
- 業務を知っている人が説明し、チームがそれを書き残したい
- 定期的な作業を、新しく入った人や業務委託の人に引き継ぐ
AI に渡すもの
- 説明、メモ、または録画の文字起こし
- 使うツール
- だれが、どのくらいの頻度でやるか
できあがるもの
「もし〜なら」の分かれ目、完了の条件、確認事項、管理者、見直し日つきの手順ごとの SOP。
手順
- 完了した状態と、開始のきっかけを書く 目的は、作業が終わったときに何が成り立っているかを1文で（「顧客の受信トレイに請求書が届き、Xero に記録されている」）。きっかけは、作業が始まる出来事（「HubSpot で案件が受注になった」）で、「必要なとき」ではない。
- 名前ではなく役割を書く 「手順1〜8は業務管理担当、手順6は経理責任者が承認」。今の担当者の名前は一度だけ [ ] で添える。担当が替わっても SOP が使えるように。
- 1手順に1つの動作を書く 「何を」の前に「どこで」を書き、続けて動詞で指示し、画面のラベルは表示どおりに太字にする：「**請求書** のページで **新規請求書** を選ぶ」「**支払期日** で今日から30日後を選ぶ」。画面の同じ場所での短い動作は1手順にまとめてもよい。そうでなければ分ける。このスキルの既定値：1つのセクションが12手順を超えたら、見出しで分ける。
- 判断をすべて取り出す 「だいたい」「場合による」「大きい案件なら」といった言葉は判断の分かれ目。それぞれ「もし [条件] なら手順 X へ。そうでなければ次へ。」と書く。あいまいな基準は数字にし、説明した人が数字を言っていなければ「[確認: 基準値]」と書く。
- チェックを足す 完了とする前に作業者が確かめること（レコードがある、合計が合う、メールが送られている）。説明した人が、いちばん多いと言ったミスを1〜3個足す。
- 管理の項目を埋める 管理者（内容を最新に保つ役割）、最終更新日、見直し日。EPA のガイダンスは、1〜2年ごとの定期的な見直しと、業務が変わるたびの更新をすすめている。このスキルの既定値は12か月、ツールがよく変わるなら6か月。下書きは、書いた人とは別の人が試してから確定させることを書いておく。
- 推測せず、足りないところを指摘する 元の説明にないことは、すべて「管理者への確認事項」に入れる。項目名や設定を作らない。
SKILL.md の全文
AI が読むファイルそのものです。 ダウンロード
---
name: sop-writer
description: 担当者が口頭や文章でした説明、または画面録画の文字起こしを、業務手順書（SOP）にする。目的、開始のきっかけ、役割、画面に出るボタンや項目の名前どおりに書いた番号つきの手順、判断の分かれ目、品質チェック、管理者、見直し日を含む。SOP の作成、業務の手順化、チーム向けのマニュアルやチェックリスト、「新しい人がひとりでできるように、やり方を書き残して」と頼まれたときに使う。
---
# 業務手順書（SOP）を書く
良い SOP があれば、その作業の経験が少ない人でも、監督なしで作業をやり遂げられる（米国環境保護庁 EPA の SOP 作成ガイダンスが示す基準）。1手順に1つの動作を、能動の現在形で、画面に出る言葉どおりに書く。判断が必要なところはすべて「もし〜なら」の形で表に出す。
## 使う場面
- 業務を知っている人が、口頭で、Loom で、またはまとまっていない文書で説明し、チームがそれを書き残す必要があるとき。
- 定期的な作業を、新しく入った人、業務委託の人、別のチームに引き継ぐとき。
- 人によってやり方が少しずつ違うせいで、ミスが続いているとき。
- 一度きりのプロジェクトの計画（project-kickoff-brief を使う）や、手順のないルールだけの規程には使わない。
## 用意するもの
- 説明か文字起こし。「ここをクリック」とある画面録画の文字起こしは、どの画面かを特定する必要がある。画面に何が映っていたか一度だけ聞き、わからないところには「[確認: どのボタンか]」と書く。
- 使うツール（アプリの名前、どのアカウントやワークスペースか）。
- だれが作業し、だれのための作業か。なければ「[役割: 要確認]」と書く。
- どのくらいの頻度で発生し、何をきっかけに始まるか。
## 手順
1. **完了した状態と、開始のきっかけを書く。** 目的は、作業が終わったときに何が成り立っているかを1文で（「顧客の受信トレイに請求書が届き、Xero に記録されている」）。きっかけは、作業が始まる出来事（「HubSpot で案件が受注になった」）で、「必要なとき」ではない。
2. **名前ではなく役割を書く。** 「手順1〜8は業務管理担当、手順6は経理責任者が承認」。今の担当者の名前は一度だけ [ ] で添える。担当が替わっても SOP が使えるように。
3. **1手順に1つの動作を書く。** 「何を」の前に「どこで」を書き、続けて動詞で指示し、画面のラベルは表示どおりに太字にする：「**請求書** のページで **新規請求書** を選ぶ」「**支払期日** で今日から30日後を選ぶ」。画面の同じ場所での短い動作は1手順にまとめてもよい。そうでなければ分ける。このスキルの既定値：1つのセクションが12手順を超えたら、見出しで分ける。
4. **判断をすべて取り出す。** 「だいたい」「場合による」「大きい案件なら」といった言葉は判断の分かれ目。それぞれ「もし [条件] なら手順 X へ。そうでなければ次へ。」と書く。あいまいな基準は数字にし、説明した人が数字を言っていなければ「[確認: 基準値]」と書く。
5. **チェックを足す。** 完了とする前に作業者が確かめること（レコードがある、合計が合う、メールが送られている）。説明した人が、いちばん多いと言ったミスを1〜3個足す。
6. **管理の項目を埋める。** 管理者（内容を最新に保つ役割）、最終更新日、見直し日。EPA のガイダンスは、1〜2年ごとの定期的な見直しと、業務が変わるたびの更新をすすめている。このスキルの既定値は12か月、ツールがよく変わるなら6か月。下書きは、書いた人とは別の人が試してから確定させることを書いておく。
7. **推測せず、足りないところを指摘する。** 元の説明にないことは、すべて「管理者への確認事項」に入れる。項目名や設定を作らない。
## 出力の形式
```markdown
# SOP: [作業名]
**目的:** [完了したときに成り立っていること]
**きっかけ:** [作業が始まる出来事] · **頻度:** [どのくらい]
**役割:** [役割] が手順を行い、[役割] が [何を] 承認する。（[今の担当者]）
**ツール:** [アプリとアカウント]
**所要時間:** 約 [分]
## 手順
1. [場所] で **[画面のラベルどおり]** を [動詞] …
2. …
- もし [条件] なら、手順 [n] へ。そうでなければ次へ。
## 完了の条件
- [ ] [確かめられるチェック]
## よくあるミス
- [ミス] — [防ぎ方]
## 管理者への確認事項
- [元の説明で足りないところ]
**管理者:** [役割] · **最終更新:** [日付] · **見直し日:** [日付] · **試した人:** [書いた人以外の人]
```
## 例
**入力（Loom の文字起こしの抜粋）:** 「デモの予約が入ると Calendly に来るので、HubSpot を開いてコンタクトを探して、50人を超える会社なら担当を松田さんに、そうでなければ自分にして、ライフサイクルステージを SQL にして、テンプレートの『demo prep』から準備のメールを送ります。週に10件くらいで、1件4分くらいです。」 依頼者からの補足：青木さんがインサイドセールス（SDR）、HubSpot は営業のワークスペース、業務の管理者は営業企画の責任者。録画に映っていたラベル（HubSpot は英語表示）：Contacts、Search、Company size、Contact owner、Lifecycle stage、Sales Qualified Lead、Email、Templates、Send。
**出力:**
```markdown
# SOP: 新しいデモの予約を担当者に振り分ける
**目的:** 予約されたデモすべてに HubSpot で正しい担当者がつき、見込み客に準備のメールが届いている。
**きっかけ:** Calendly でデモが予約される · **頻度:** 週に約10件
**役割:** SDR がすべての手順を行う。（[青木]）
**ツール:** Calendly、HubSpot（営業のワークスペース）
**所要時間:** 約4分
## 手順
1. Calendly で新しい予約を開き、見込み客のメールアドレスをコピーする。[確認: コンタクトの探し方]
2. HubSpot で **Contacts** を開き、**Search** にアドレスを貼りつける。
3. コンタクトを開き、**Company size** を確かめる。
- もし従業員が50人を超えるなら、**Contact owner** を松田さんにする。そうでなければ自分にする。
4. 同じコンタクトの **Lifecycle stage** を **Sales Qualified Lead** にする。
5. コンタクトの画面で **Email** をクリックし、**Templates** から **demo prep** を選ぶ。
6. 最後に **Send** をクリックする。
## 完了の条件
- [ ] コンタクトの担当者が、会社の規模のルールと合っている。
- [ ] Lifecycle stage が Sales Qualified Lead になっている。
- [ ] 準備のメールが、コンタクトのアクティビティに表示されている。
## 管理者への確認事項
- コンタクトがまだ HubSpot にない場合はどうするか。[確認]
- 「50人を超える」は、HubSpot の Company size の項目で判断するのか、見込み客が書いた人数で判断するのか。[確認]
**管理者:** 営業企画の責任者 · **最終更新:** 11月4日 · **見直し日:** 翌年11月4日（既定の12か月） · **試した人:** [確認: ほかの SDR]
```
## 送る前のチェック
- [ ] どの手順も、1つの動作で、動詞で指示している。
- [ ] 画面のラベルはすべて太字で、元の説明から取っているか、「[確認]」をつけている。
- [ ] 元の説明の「だいたい」「場合による」がすべて、数字か「[確認: 基準値]」つきの「もし〜なら」になっている。
- [ ] きっかけが「必要なとき」ではなく、出来事になっている。
- [ ] 管理者は役割で書き、見直し日があり、書いた人以外に下書きを試す人を決めている。
## よくある失敗
- 「CRM を更新する」と書く。どのレコードの、どの項目を、どの値にするかを書く。
- 詳しい人の省略（「いつものやつをやる」）を残す。新しい人は「いつもの」を知らない。
- SOP を完成させたように見せるために、ボタンの名前を推測で書く。間違ったラベルは「[確認]」より高くつく。
チームで使う
AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む
変更履歴
- v1.0.1 · · Example: the labels visible in the recording now include Sales Qualified Lead, so the bold label in step 4 comes from the source; step 1 no longer assumes a booking email, step 6 drops a greeting check the speaker never mentioned, and the review date uses the 12-month default instead of an unstated "tool changes often".
- v1.0.0 · · First release.
出典
出典は英語のページです。