公式スキル · カスタマーサクセス
ヘルプ記事の作成
1つの作業についてヘルプ記事を書く。作業名のタイトル、先に答え、画面どおりのラベルの番号つき手順、スクリーンショットのメモ、トラブルシューティング、関連記事。
Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。
使う場面
- 同じ質問がくり返し届き、回答が担当者の返信の中にしかないとき
- 新しい機能を出し、お客さまに使い方を伝える必要があるとき
AI に渡すもの
- 作業と、それができる人
- 実際の手順と画面のラベル
- 問い合わせでわかっている問題
できあがるもの
スクリーンショットの差し込み位置とトラブルシューティングつきの、そのまま公開できるヘルプ記事。
手順
- タイトルを作業名にする お客さまが検索する形で、作業そのものを書く:「連絡先を CSV で書き出す」「ワークスペースにメンバーを追加する」。「エクスポート機能」や「エクスポートについて」にはしない。1記事に1つの作業。メモが2つの作業にまたがるなら、2記事に分ける。
- 最初の2文で答える その作業で何ができるかと、いちばん短い道筋を書く:「連絡先は **連絡先** > **書き出し** から書き出せます。数分以内にファイルがメールで届きます。」続けて、だれが行えるか、先に何が必要か(役割、プラン、権限)。
- 番号つきの手順を、1手順1操作で書く 各手順は操作から書き始める。画面のラベルは、表示どおりの表記で太字にする。メニューの道筋は **設定** > **チーム** のように書き、「>」は太字にしない。操作の前に場所を書く:「右上の **設定** をクリックします。」手順は3〜10個。それより長ければ、見出しつきの節に分ける。
- うまくいったときの状態を書く 最後の手順のあとに、成功したらお客さまに何が見えるかを1行で:メッセージ、ファイル、一覧に増えた項目。
- 役に立つ場所にだけスクリーンショットを置く 押す場所が見つけにくい手順や、画面が込み入っている手順のあとに差し込み位置を入れる。すべての手順のあとには入れない。何が写っているかを書いておけば、あとで撮影でき、代替テキストにもなる。
- 実際の問題からトラブルシューティングを書く 各項目は、お客さまの言葉で症状を見出しにし、原因と対処を1〜3文で書く。問い合わせかプロダクトチームから聞いた問題だけを使い、エラーをつくらない。
- 関連記事を2〜4本リンクする 次にやりそうな作業と、前提となる作業。記事の実際のタイトルが渡されていればそれを使い、なければ「[関連: トピック]」と書く。
SKILL.md の全文
AI が読むファイルそのものです。 ダウンロード
---
name: help-article-writer
description: お客さまの1つの作業について、ヘルプセンターやナレッジベースの記事を書く。タイトルは作業名にし、答えを先に書き、画面の表示どおりのラベルで番号つきの手順を並べ、スクリーンショットの差し込み位置、トラブルシューティング、関連記事をつける。ヘルプ記事、サポート資料、操作ガイド、ナレッジベースのページを頼まれたとき、問い合わせへの回答やリリースノート、走り書きのメモを、お客さまが一人で進められる記事にしたいときに使う。
---
# ヘルプ記事の作成
ヘルプ記事は、お客さまがサポートに連絡せずに1つの作業を終えるためのもの。お客さまは検索から来て、自分の作業を探して流し読みし、プロダクトを横に開いたまま手順をたどる。タイトルは作業名にし、答えを先に書き、どの手順も1つの操作だけにして、ラベルは画面の表示どおりに書く。
## 使う場面
- 同じ質問が問い合わせにくり返し届き、回答が担当者の返信の中にしかない。
- 新しい機能を出し、お客さまに使い方を伝える必要がある。
- 既存の記事が長い、古い、社内の言葉で書かれている。
- 多数の質問をまとめた FAQ には使わない(faq-from-tickets を使う)。リリースノートにも使わない(release-notes を使う)。
## 用意するもの
- 記事で扱う作業と、だれが行うか(すべてのユーザー、管理者だけ、特定のプラン)。
- 実際の手順:プロダクトに表示されるとおりの画面、ボタン、メニューの名前。説明しかなければ手順を書き、自信のないラベルにはそれぞれ「[ラベルを確認]」と付ける。
- わかっている問題:問い合わせやプロダクトチームから聞いた、お客さまがつまずくエラー。
- 任意:関連記事としてリンクする既存の記事。
## 手順
1. **タイトルを作業名にする。** お客さまが検索する形で、作業そのものを書く:「連絡先を CSV で書き出す」「ワークスペースにメンバーを追加する」。「エクスポート機能」や「エクスポートについて」にはしない。1記事に1つの作業。メモが2つの作業にまたがるなら、2記事に分ける。
2. **最初の2文で答える。** その作業で何ができるかと、いちばん短い道筋を書く:「連絡先は **連絡先** > **書き出し** から書き出せます。数分以内にファイルがメールで届きます。」続けて、だれが行えるか、先に何が必要か(役割、プラン、権限)。
3. **番号つきの手順を、1手順1操作で書く。** 各手順は操作から書き始める。画面のラベルは、表示どおりの表記で太字にする。メニューの道筋は **設定** > **チーム** のように書き、「>」は太字にしない。操作の前に場所を書く:「右上の **設定** をクリックします。」手順は3〜10個。それより長ければ、見出しつきの節に分ける。
4. **うまくいったときの状態を書く。** 最後の手順のあとに、成功したらお客さまに何が見えるかを1行で:メッセージ、ファイル、一覧に増えた項目。
5. **役に立つ場所にだけスクリーンショットを置く。** 押す場所が見つけにくい手順や、画面が込み入っている手順のあとに差し込み位置を入れる。すべての手順のあとには入れない。何が写っているかを書いておけば、あとで撮影でき、代替テキストにもなる。
6. **実際の問題からトラブルシューティングを書く。** 各項目は、お客さまの言葉で症状を見出しにし、原因と対処を1〜3文で書く。問い合わせかプロダクトチームから聞いた問題だけを使い、エラーをつくらない。
7. **関連記事を2〜4本リンクする。** 次にやりそうな作業と、前提となる作業。記事の実際のタイトルが渡されていればそれを使い、なければ「[関連: トピック]」と書く。
## 出力の形式
```markdown
# [作業名のタイトル]
[何ができるかと、いちばん短い道筋。1〜2文。]
**できる人:** [役割/プラン] · **始める前に:** [前提。なければ消す]
## [作業、または作業の最初の部分]
1. [場所]の **[ラベル]** をクリックします。
2. [...]
![スクリーンショット:写っているもの]
うまくいくと、[お客さまに見えるもの]。
## うまくいかないとき
### [お客さまの言葉での症状]
[原因と対処、1〜3文。]
## 関連記事
- [記事のタイトル]
```
## 例
**入力:**
> プロダクトからのメモ:管理者は「設定」→「チーム」→「メンバーを招待」ボタンからメンバーを招待できる。メールアドレスを入力(カンマ区切り)、役割を「メンバー」か「閲覧者」から選び、「招待を送信」。招待の有効期限は7日。問い合わせ:招待メールが届かないという声(たいてい迷惑メールフォルダか、アドレスの誤り)。管理者以外は「メンバーを招待」がグレーになっている。
**出力:**
```markdown
# ワークスペースにメンバーを招待する
メンバーは **設定** > **チーム** > **メンバーを招待** から招待できます。招待された人には参加用のリンクつきのメールが届き、リンクは7日間有効です。
**できる人:** ワークスペースの管理者
## 招待を送る
1. 左のメニューの **設定** をクリックします。
2. 開いた画面で **チーム** をクリックします。
3. 続けて **メンバーを招待** をクリックします。
4. メールアドレスを1つ以上、カンマで区切って入力します。
5. 役割を **メンバー** か **閲覧者** から選びます。
6. 最後に **招待を送信** をクリックします。
![スクリーンショット:メールアドレスを2つ入力し、役割のメニューを開いた「メンバーを招待」の画面]
うまくいくと、招待した人はチームの一覧に「招待中」と表示され、参加するまでそのままになります。
## うまくいかないとき
### 招待メールが届かない
招待した人に、迷惑メールのフォルダを確認してもらってください。見つからなければ、チームの一覧でアドレスを確かめ、もう一度招待を送ってください。
### 「メンバーを招待」がグレーになっている
招待できるのは管理者だけです。ワークスペースの管理者に招待してもらうか、自分を管理者にしてもらってください。
## 関連記事
- [関連: メンバーの役割を変える]
- [関連: メンバーを外す]
```
## 送る前のチェック
- [ ] タイトルが作業名で、1つの作業だけを示している。
- [ ] 最初の2文が、手順を読まなくても質問に答えている。
- [ ] どの手順も操作は1つで、画面のラベルはすべて太字でプロダクトの表示と一致しているか、「[ラベルを確認]」の印がある。
- [ ] だれができるか、うまくいったときにどうなるかが書いてある。
- [ ] トラブルシューティングの項目は、すべて問い合わせかプロダクトチームから来ている。
- [ ] 社内の言葉(チケット、SKU、フィーチャーフラグ、バックエンド)が出ていない。
## よくある失敗
- 背景から書き始める(「チームは〜の重要な要素です」)。読み手は手順を読みに来ている。
- 「設定ページに移動してチームを構成します」と書く。クリックを1つずつ書く。
- すべての手順のあとにスクリーンショットを入れる。ページが長くなり、画面が変わるたびに古くなる。
チームで使う
AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む
変更履歴
- v1.0.0 · · First release.
出典
出典は英語のページです。
- Procedures | Google developer documentation style guide (2026-11-04に確認)
- UI elements and interaction | Google developer documentation style guide (2026-11-04に確認)
- Writing step-by-step instructions - Microsoft Style Guide (2026-11-04に確認)
- Tips & Templates for Writing Great Knowledge Base Articles (2026-11-04に確認)
- Create different types of articles in your Help Center (2026-11-04に確認)