Claude を「便利だけど安定しない」と感じる人と、「自分の生産性を 5 倍にする道具」として使い倒している人の差は、プロンプトと Skills の “正しい作り方” を公式から学んでいるかどうかにあります。Anthropic は 2026 年版の 公式プロンプティングベストプラクティス と Agent Skills の Authoring ガイド を最新モデル（Opus 4.8 / 4.7 / 4.6、Sonnet 4.6、Haiku 4.5）向けに整備し、「ここまでやれば中級者」というラインを明文化しました。本稿では、両ドキュメントを横断的に読み解き、脱初心者のために今日から実装できるパターン を整理します。
まず押さえる：プロンプトと Skill は「使い分け」る別物
混同しやすいのですが、プロンプトとSkillは役割が違います。
| 項目 | プロンプト | Skill |
|---|---|---|
| 役割 | 単発の指示 | 再利用可能な手順書 |
| 配置 | 会話の中 / system prompt | .claude/skills/ ディレクトリ |
| トリガー | 都度入力 | Claude が description を読んで自動選択 |
| 拡張 | XML タグ・例 | scripts/ / references/ / assets/ をバンドル |
「繰り返し同じ指示を書いている」と気づいた瞬間が、Skill 化のサイン です。逆に、その場限りの一回きりのタスクをわざわざ Skill にする必要はありません。
プロンプト編：公式が推す 5 つの王道
Anthropic 公式の Prompting Best Practices は、Claude 4.x 系全体に通底する 5 つのテクニックを提示しています。
1. Clear and direct（端的に頼む）
Claude 4 系は「察してくれる AI」ではなく、ストレートに頼まれた通りに動く相棒 です。「AI が勝手に過剰サービスする時代は終わった」と公式が明言しているので、欲しい結果は直接的に書くのが正解です。
2. Few-shot examples（2〜5 個の入出力例）
特に構造化された出力（JSON、テーブル、コミットメッセージ等）で精度を爆上げするのが 2〜5 個の良質な入出力例 を見せること。3 個前後が体感上のスイートスポットです。
3. XML タグで構造化
複雑な指示は <context>, <task>, <format> のような XML タグで区切ると、Claude が「どこからどこまでが何の指示か」を正確に解釈します。Markdown と混ぜても問題なく、長文プロンプトの可読性も上がります。
4. Chain-of-thought（思考の段階化）
複雑な推論には 3 段階のテクニックがあります。
- Basic: 「Think step-by-step」と書く
- Guided: 思考すべきステップを箇条書きで列挙
- Structured:
<thinking>タグで思考領域を切る
ロジックが必要なタスクでは、これだけで正答率が大きく上がるという報告が公式に出ています。
5. Role prompting（役割指定）
System message で「あなたは○○のシニアエンジニアです」と役割を与えるのは、ドメイン特化タスクの精度を大幅に押し上げる最強テクニック の 1 つ。「面倒だから書いていない」人ほど、ここを入れるだけで劇的に効きます。
Skill 編：「いつ Skill にすべきか」を見極める
Skill は モジュラーな能力 です。会話履歴を圧迫せず、必要なときだけ読み込まれる仕組みなので、何度も書く指示は積極的に Skill 化したほうが得です。
Skill 化の判断軸:
- 同じ手順書を 週 2 回以上 参照しているか？
- スクリプトや参照ドキュメントを毎回貼っていないか？
- ワークフローに 検証ステップ が必要か？
公式が推奨するネーミング規則は 動名詞形（gerund form）——processing-pdfs、analyzing-spreadsheets、writing-documentation のように、何の能力を提供するかが一目で分かる形にします。utils、helper、tools のような曖昧な名前は禁忌。
SKILL.md の正しい書き方
SKILL.md の構造は frontmatter + 本文 の 2 部構成です。frontmatter には name（64 文字以内、英数字とハイフン）と description（1024 文字以内、三人称で書く）が必須。
description が「Skill 選択の生命線」
Claude は 100 以上の Skill から最適なものを description だけを見て 選びます。なので「何をして、いつ使うか」を具体的に書く必要があります。
# 良い例
description: Extract text and tables from PDF files, fill forms, merge documents.
Use when working with PDF files or when the user mentions PDFs, forms, or document extraction.
# 悪い例
description: Helps with documents
本文は 500 行以下、参照は 1 段階のみ
公式の推奨は SKILL.md 本文を 500 行以下 に抑えること。それ以上の詳細は別ファイルに分け、SKILL.md から 1 段階のリンク だけで辿れる構造にします。SKILL.md → advanced.md → details.md のように 2 段以上ネストさせない のは、Claude が深い参照を head -100 のような部分読みで済ませてしまう挙動を避けるためです。
Progressive disclosure——「読み込みを段階的に解放する」
Skills の核心思想が progressive disclosure（段階的開示）です。仕組みとしては:
- 起動時に 全 Skill の frontmatter（name + description）だけ がシステムプロンプトにプリロードされる
- ユーザーの依頼が来たら、Claude が description から最適な Skill を選び、
SKILL.mdを読みに行く - SKILL.md 内で参照されている
references/finance.mdなどは、必要になったときだけ Bash + Read で読み込む
つまり「大量のリファレンスファイルをバンドルしてもコンテキストを消費しない」という設計です。公式が強調する「context window は public good（みんなの共有財）」という思想がここに直結します。
“Claude A が書いて、Claude B が試す” 反復開発
公式が提唱する Skill 開発の最強パターンが、Claude A と Claude B を分ける こと。
- Claude A（設計役）に Skill を書かせる
- Claude B（実行役・別セッション）に書いた Skill をロードして実タスクを試させる
- Claude B のつまずきを観察し、その学びを Claude A に戻す
- これを 3〜5 周回す
「Claude は Skill 設計の専門家でもあり、エージェント挙動を一番分かっている」という事実を逆手にとった、強力な開発ループです。
やってはいけないアンチパターン 7 選
公式チェックリストから、特に踏みがちなものを抜粋。
- vague な description（「Helps with files」など）→ Skill が選ばれない
- Windows パス（バックスラッシュ） → Unix で壊れる
- Voodoo constants（
TIMEOUT = 47の根拠なし）→ Claude が値を変えられない - 多すぎる選択肢提示（「pypdf でも pdfplumber でも PyMuPDF でも…」）→ 迷う。デフォルトを 1 つ示す
- SKILL.md が冗長（「PDF とは…」のような Claude が既知の解説）→ トークン無駄
- 時限的情報を埋め込む（「2025 年 8 月までは…」）→ 必ず腐る
- 用語の揺らぎ（”field” と “box” の混在）→ 解釈ブレ
個人開発・副業視点：「Skill 1 個から始める」
副業の文脈では、まず 自分が週 2〜3 回繰り返している作業 を 1 つだけ Skill にしてみるのが正解。たとえば、
- 記事の構成テンプレート生成（タイトル → セクション → 字数配分）
- コミットメッセージのスタイル統一（type(scope): description 形式）
- クライアント向けレポートの整形（固定フォーマットへの変換）
これらを Skill 化するだけで、普段のコンテキストスイッチコストが大きく減ります。1 個作ってみて、運用しながら 2 個目を作る、というペースで「自分専用の AI 道具箱」が積み上がっていきます。
まとめ：「公式に従う」が最短
Claude は十分賢く、プロンプトの細かいテクニックよりも 明確な指示・適切な例・必要なら Skill という王道のほうが効きます。Anthropic 公式の Best Practices は読み物として 1 時間で全部読める分量なので、今夜のうちに 1 周して、明日朝 SKILL.md を 1 個書く という流れが、脱初心者の最短ルートです。
