公式スキル · AI 活用

AI アシスタントへのコンテキスト指示書

v1.0.0・2026年11月4日更新

AI アシスタントやエージェントへの指示を書く。役割、読み手、できること・できないこと、正とする情報源、ツール、形式、例、例外ケース、人への引き継ぎ。

Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。

使う場面

• カスタム GPT、Claude のプロジェクト、問い合わせ対応ボットを設定するとき
• アシスタントが同じ間違いを繰り返し、指示が長くなっているとき

AI に渡すもの

• アシスタントの目的と、だれが使うか
• 決してやってはいけないこと
• 事実がどこにあるか
• よい回答の例

できあがるもの

重要な順に並べた短い指示書。例、例外ケース、人に引き継ぐ条件つき。

手順

1. 役割と目的を2文で書く だれのためのもので、うまくいった会話で何が達成されるか。「あなたはカスタマーサクセスチームが顧客からの請求に関する質問に答えるのを手伝う。よい回答は正確で、規程の該当箇所を示し、そのまま貼りつけられる」。
2. 読み手とトーンを決める 出力を読むのはだれか、どのくらい詳しいか。トーンのルールを2〜3個、例のフレーズつきで。AI がもともと守る一般的なルール（「親切に」）は書かない。
3. できること・できないことを並べる できること: 範囲内の作業。できないこと: 範囲外のこと、断るべきこと、決してしてはいけない約束（返金、法的な助言、納期）。「できないこと」には、それぞれ代わりに何をするかを書く。
4. 正とする情報源を示す どのテーマはどの文書やツールが正か。情報源同士が食い違うとき、どこにも答えがないときにどうするか（「わからないと答え、[連絡先]を案内する」）。情報源は場所を示し、文書を丸ごと指示に貼りつけない。
5. ツールがあれば説明する 1つにつき1行。何をするか、いつ使うか。2つのツールが重なっていて、人が見てもどちらを使うか言えないなら、1つにまとめるか削る。
6. 出力形式を決める テンプレートか、形そのものを示す短い例。長さ、見出し、何を入れるか。多様な入力と理想の出力の例を2〜3個足す。例はルールより多くを教える。
7. 例外ケースとエスカレーションを押さえる いちばんうまくいかなそうな状況を3〜5個（怒っている利用者、範囲外の依頼、情報の不足、個人情報の要求）、それぞれ期待する動きとともに。いつ、どうやって人に引き継ぐかを書く。
8. 重要な順に並べ、削る いちばん大事なルールを、わかりやすい見出しで上のほうに置く。実際の失敗か起こりそうな失敗に結びつけられない行は消す。最小限から始め、テストで必要だとわかったときだけルールを足す。

SKILL.md の全文

AI が読むファイルそのものです。 ダウンロード

---
name: context-engineering-brief
description: AI アシスタントやエージェントに渡すコンテキストの指示書（システムプロンプト、カスタム指示）を書く。役割、目的、読み手、できること・できないこと、正とする情報源、ツール、出力形式、少数の例、例外ケース、人に引き継ぐ条件を、短く重要な順に並べる。カスタム GPT、Claude のプロジェクト、Gemini の Gem、Copilot のエージェント、問い合わせ対応ボットを設定するとき、システムプロンプトを書きたい、AI への指示を改善したい、同じ間違いを繰り返すアシスタントを直したいときに使う。
---

# コンテキスト指示書

アシスタントは、渡されたコンテキストからいちばんありそうな動きをする。Anthropic のコンテキストエンジニアリングのガイダンスは、「望む結果が出る可能性をいちばん高める、情報量の多いトークンの最小の集まり」を探すよう勧めている。導けるくらい具体的に、ただし壊れやすい if-then のロジックを書き込まない。例外ケースを並べた長いリストより、多様で典型的な例を少し入れることも勧めている。だからこの指示書（このスキルの既定値）は、いちばん大事な指示を先頭に置き、長いルールの一覧の代わりに具体的な例を少し使い、事実を全部貼りつけずに、事実がどこにあるかを示す。

## 使う場面

- カスタム GPT、Claude のプロジェクト、Gemini の Gem、Copilot のエージェント、問い合わせ対応ボットを設定するとき。
- アシスタントが同じ間違いを繰り返し、指示が長くなってきたとき。
- アシスタントをチームに渡し、何のためのものか、何をしないかを全員にわかるようにしたいとき。
- アシスタントが検索する文書の準備（rag-source-prep を使う）やテスト（eval-set-builder を使う）には使わない。

## 用意するもの

- アシスタントの目的と、だれが使うか。
- 決してやってはいけないこと（社内ルール、データ、トーン、約束）。
- 事実がどこにあるか。文書、ナレッジベース、ツール。
- よい回答の例を2〜3個、あれば。なければ手順6で書き、「[下書き]」と印をつける。
- 既存のアシスタントなら、わかっている失敗。いちばん価値のある材料になる。

## 手順

1. **役割と目的を2文で書く。** だれのためのもので、うまくいった会話で何が達成されるか。「あなたはカスタマーサクセスチームが顧客からの請求に関する質問に答えるのを手伝う。よい回答は正確で、規程の該当箇所を示し、そのまま貼りつけられる」。
2. **読み手とトーンを決める。** 出力を読むのはだれか、どのくらい詳しいか。トーンのルールを2〜3個、例のフレーズつきで。AI がもともと守る一般的なルール（「親切に」）は書かない。
3. **できること・できないことを並べる。** できること: 範囲内の作業。できないこと: 範囲外のこと、断るべきこと、決してしてはいけない約束（返金、法的な助言、納期）。「できないこと」には、それぞれ代わりに何をするかを書く。
4. **正とする情報源を示す。** どのテーマはどの文書やツールが正か。情報源同士が食い違うとき、どこにも答えがないときにどうするか（「わからないと答え、[連絡先]を案内する」）。情報源は場所を示し、文書を丸ごと指示に貼りつけない。
5. **ツールがあれば説明する。** 1つにつき1行。何をするか、いつ使うか。2つのツールが重なっていて、人が見てもどちらを使うか言えないなら、1つにまとめるか削る。
6. **出力形式を決める。** テンプレートか、形そのものを示す短い例。長さ、見出し、何を入れるか。多様な入力と理想の出力の例を2〜3個足す。例はルールより多くを教える。
7. **例外ケースとエスカレーションを押さえる。** いちばんうまくいかなそうな状況を3〜5個（怒っている利用者、範囲外の依頼、情報の不足、個人情報の要求）、それぞれ期待する動きとともに。いつ、どうやって人に引き継ぐかを書く。
8. **重要な順に並べ、削る。** いちばん大事なルールを、わかりやすい見出しで上のほうに置く。実際の失敗か起こりそうな失敗に結びつけられない行は消す。最小限から始め、テストで必要だとわかったときだけルールを足す。

## 出力の形式

```markdown
# [アシスタント名] — 指示書

## 役割と目的
[2文]

## 読み手とトーン
- 読み手: [だれか、どのくらい詳しいか]
- トーン: [ルール] — 例:「[例のフレーズ]」

## できること
- [範囲内の作業]

## できないこと（と、代わりにすること）
- [X は決してしない] → [Y をする]

## 正とする情報源
| テーマ | 情報源 | ない・食い違うとき |
|---|---|---|

## ツール
- [ツール]: [何をするか] — [条件]のときに使う

## 出力の形式
[テンプレートか説明]

## 例
**利用者:** [入力]
**あなた:** [理想の出力]

## 例外ケース
- [状況] → [動き]

## 人に引き継ぐとき
- [条件] → [方法: だれに、どの経路で]
```

## 例

**入力:** 「フィールドノート（現場作業の訪問スケジュール管理 SaaS）の営業チーム向けカスタム GPT。見込み客からの機能と料金の質問への返信を下書きさせたい。料金は『料金表2025』、機能は『製品 FAQ』にある。カスタム連携を約束したり、値引き額を伝えたりしてしまう。値引きは営業マネージャー（山本さん）の承認が必要」

**出力:**

```markdown
# フィールドノート 営業返信アシスタント — 指示書

## 役割と目的
あなたは、見込み客からの機能と料金の質問への返信を、フィールドノートの営業担当のために下書きする。よい下書きは料金表2025と製品 FAQ に照らして正確で、営業担当がそのまま貼りつけられ、2つの文書に書いていないことを会社に約束させない。

## 読み手とトーン
- 読み手: 現場作業の会社の業務管理の担当者。技術に詳しくない。
- トーン: わかりやすく率直に、400字以内 — 例:「はい、作業員はオフラインでも予定を確認できます。」

## できること
- 2つの文書をもとに、機能と料金の質問に答える。
- 次の一歩（デモ、トライアル）を提案する。

## できないこと（と、代わりにすること）
- 値引きを提示する、ほのめかす → 下書きに「[営業担当へ: 値引きは山本さんの承認が必要]」と書く。
- カスタム連携やロードマップの項目を約束する → 今あるものを伝え、要望を社内に伝えると申し出る。
- セキュリティや法務の質問に答える → 「[営業担当へ: セキュリティチェックシートの手続きに回す]」と書く。

## 正とする情報源
| テーマ | 情報源 | ない・食い違うとき |
|---|---|---|
| 価格、プラン | 料金表2025 | 「確認します」と答え、営業担当に知らせる |
| 機能 | 製品 FAQ | 推測しない。営業担当に知らせる |

## 出力の形式
400字以内の返信。そのあとに「営業担当へのメモ:」として、確かめることを並べる。

## 例
**利用者:** freee 会計と連携できますか？ SAP 用のコネクターも作ってもらえますか？
**あなた:** はい、フィールドノートは追加の設定なしで、請求書を freee 会計と同期できます。SAP のコネクターは現時点ではありませんが、ご要望は製品チームに伝えます。freee 会計との同期を20分のデモでご覧になりますか？
営業担当へのメモ: SAP の要望 — CRM に記録する。

**利用者:** 作業員25人だといくらですか？ 今月中に契約したら20%引きにできますか？
**あなた:** 作業員25人の場合の料金はプランによって変わります。料金表のプラン一覧にそれぞれの選択肢があり、どれが合うかご案内します。20%引きについては、上長に確認してご連絡します。
営業担当へのメモ: [営業担当へ: 値引きは山本さんの承認が必要]。送る前に、料金表2025からプランの価格を書き入れる。

## 例外ケース
- 見込み客が値引きを求める → 数字を入れずに下書きし、「[営業担当へ: 値引きは山本さんの承認が必要]」を足す。
- どちらの文書にもない質問 → 「確認して本日中にご連絡します」と答え、営業担当へのメモを添える。

## 人に引き継ぐとき
- 見込み客が契約、法的な条件、競合の価格に合わせた値引きに触れる → 営業担当が対応する。CRM で山本さんをタグづけする。
```

## 送る前のチェック

- [ ] 役割と目的が、先頭の2文に収まっている。
- [ ] すべての「できないこと」に、代わりにすることが書いてある。
- [ ] テーマごとに正とする情報源が1つあり、ないときのルールがある。
- [ ] 出力の形そのものを示す具体的な例が2つ以上ある。
- [ ] すべてのルールが、わかっている失敗か起こりそうな失敗にたどれる。一般的な助言は削ってある。
- [ ] エスカレーション先として、人か経路の名前がある。

## よくある失敗

- 文書を丸ごと指示に貼りつける。情報源として場所を示す。
- 例外ケースのために if-then のルールを40個書く。例と原則を示し、ルールは実際に見た失敗の分だけ足す。
- 代わりを書かずに「決して〜しない」と書く。アシスタントは断るか、即興で動く。何をすればよいかを伝える。

チームで使う

AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む

チームのPodに追加

変更履歴

• v1.0.0 · 2026年11月4日 · First release.