Claude Code Skills を使いこなすためのプロンプト 40 選:プロフェッショナルガイド

@ClaudeCode_UT
日本語2 か月前 · 2026年4月27日
242K
261
26
0
711

TL;DR

本ガイドでは、6 つのビジネスカテゴリーにわたる Claude Code Skills 用の高性能プロンプト 40 選を解説します。AI ワークフローを最適化するための「役割」「コンテキスト」「制約」というアーキテクチャの原則を学びましょう。

『"いい感じにしてください"って打って、全然いい感じじゃないのが返ってきた...💢』

これ、AIのせいじゃなくてあなたの"指示の出し方"のせいなんです。

AIを使っていて、こんな経験はありませんか?

  • 「もっとちゃんとして」としか言えない自分に気づいた
  • 毎回ゼロからプロンプトを考えて、結局ありきたりな返事しか返ってこない
  • Skillsを作ってみたけど、SKILL.mdに全部書いたら精度がガタ落ちした
  • AIツールに課金してるのに、投資に見合う使い方ができてる自信がない

この記事を最後まで読めば、500個テストして残った40本のプロ仕様プロンプトと、Claude Code Skillsの参照文書をどう構造化すれば精度が上がるかの設計原則が手に入ります。

エンジェル投資家のKhairallah氏が公開した記事が、300万ビューの大バズ中なんです。

始める前に2つだけお願いがあります。

  1. この記事を保存して、今週20分だけ時間を確保してください
  2. AIを使ってる同僚や友人にシェアしてください

今回はその内容をわかりやすく日本語で噛み砕いて、さらに「なぜこの構造で指示すると品質が上がるのか」と、その構造を「Claude Code Skillsの参照文書設計にどう活かすか」まで解説します。

元ポストはこちら:

https://x.com/eng_khairallah1/status/2048334883198738761

1行プロンプトと構造化プロンプトでは出力が全く違う

東大ClaudeCode研究所 - inline image

Khairallah氏はこう言っています。

「ほとんどのプロンプト集はありきたりだ。"ブログ記事を書いて" "このテキストを要約して" "この概念を説明して"。これはプロンプトではない。願望だ」

実際にやってみると、差は一目瞭然です。

たとえば「ブログ記事を書いて」とだけ入力すると、AIは当たり障りのない一般論を返してきます。構造も曖昧で、手直しに30分かかることも珍しくありません。

一方で、この記事で紹介するP01のプロンプトを使うと、読者層・角度・構造・ルールまで指定されているので、AIは具体的で実用的な記事を一発で出力します。手直しなしでそのまま使えるレベルです。

同じAI。同じテーマ。違うのはプロンプトの構造だけ。

では、プロ品質のプロンプトには何が入っているのか。40本すべてに共通する6つの要素から見ていきましょう。

40本に共通するプロンプト設計の6要素

東大ClaudeCode研究所 - inline image

Khairallah氏が500個以上テストして残した40本。この40本には共通する6つの構成要素があります。

プロンプトがうまくいかない原因のほとんどは、この6つのどれかが抜けているからです。

■ 1. 役割

AIに「あなたは○○の専門家です」と伝える要素です。

P01を見てみましょう。冒頭で「あなたはトップクラスのメディアで執筆経験のあるシニアコンテンツストラテジストです」と指定しています。役割がないと、AIは「何でも屋」として答えます。役割があると、その専門家の視点で答えます。

■ 2. 文脈

状況・背景・制約条件を渡す要素です。

P12の意思決定マトリクスでは「予算、タイムライン、チーム体制、目標」を入力として求めています。文脈が薄いと、AIは一般論を返すしかありません。あなたの状況を知れば知るほど、AIの回答はあなた専用のものになります。

■ 3. 制約

やってはいけないことを明確にする要素です。

P01では「フィラー表現禁止」「ヘッジワード禁止」「1段落3文以内」と具体的に禁止事項を並べています。AIは制約がないと、安全側に倒して冗長になりがちです。「やるな」と言われて初めて、切れ味のある出力が出てきます。

■ 4. 形式

出力の構造を指定する要素です。

P11のSWOT分析では「各象限5項目→影響度評価→戦略優先順位→今週のアクション」と出力の構造を細かく指定しています。形式を指定しないと、AIは自分の判断で構造を決めます。それが毎回あなたの求めるフォーマットになるとは限りません。

■ 5. 品質基準

「ここまで達していなければやり直し」のラインを示す要素です。

P01の末尾にある「この記事は編集なしでそのまま公開できるレベルであること」がまさにこれです。品質基準を伝えると、AIは自分の出力を基準に照らして調整してから返してきます。

■ 6. 具体例

求める出力のサンプルやバリエーションを示す要素です。

P03のメール作成では「バージョンA: ストレートで断定的 / バージョンB: 温かく協調的」と2パターンの出力を要求しています。具体例を示すと、AIはあなたが何を「良い出力」と考えているか理解できます。

この6要素はSkillsの参照文書にそのまま使える

東大ClaudeCode研究所 - inline image

ここまで見てきた6要素を、もう一つの角度から見てみます。

Claude Codeには「Skills」という仕組みがあります。よく使う仕事のパターンに名前をつけて、コマンド1つで呼び出せるようにしたものです。

たとえば「/write-article」と打てば記事を書いてくれる。「/weekly-plan」と打てば週間計画を作ってくれる。毎回プロンプトを1から書き直す必要がなくなります。

Claude Code Skillsを勉強したい方は下記もチェックしておきましょう⇩

東大ClaudeCode研究所 avatar

東大ClaudeCode研究所

@ClaudeCode_UT

·

Apr 26

東大ClaudeCode研究所 - inline image

Article

【9割が知らない】2万人が保存した「AIに得意分野を持たせる20Skills」

「AIに同じこと何回説明すればいいんだよ...

東大ClaudeCode研究所 - inline image

「昨日あれだけ教えたのに、なんでまたゼロからなの...」

これ、AIのせいではなくて、あなた自身の「AIへの教え方」のせいなんです。...

4

109

1.1K

1.5M

このSkillsの出力品質を決めるのが「参照文書」の構造です。

よくある失敗パターンがあります。SKILL.mdという1つのファイルに、ルールも例も背景情報も全部詰め込むことです。気持ちは分かりますが、これをやるとAIが処理すべき情報が多すぎて精度が落ちます。

正解は、情報を用途別のファイルに分けて、必要な時に必要なファイルだけを読み込む構造にすることです。

Anthropic公式のSkillsテンプレートでも、この分離構造が推奨されています。

markdown
1skill-name/
2 SKILL.md → 常に読み込む。役割と基本ルールだけ (500行以下推奨)
3 references/ → タスクに応じて読み込む。知識・制約・品質基準
4 scripts/ → 実行可能コード。繰り返し処理やデータ変換
5 assets/ → 出力用テンプレートやアイコン

SKILL.md のname と descriptionだけが最初にロードされます。SKILL.md本体は薄く保ち、詳細な情報はreferences/ に分離してリンクする。これが公式が推奨する設計です。

そして、参照ファイルの中身をどう構造化するか。ここでさっきの6要素がそのまま使えます。

■ 役割 → SKILL.mdに「あなたは○○です」と定義

■ 文脈 → audience.mdやcompany-context.mdに自社・読者の情報を配置

■ 制約 → writing-rules.mdやrisk-criteria.mdに「やってはいけないこと」を集約

■ 形式 → format-templates.mdに出力構造を定義

■ 品質基準 → quality-checklist.mdに合否の判定基準を明記

■ 具体例 → good-examples.mdに過去の成功事例を蓄積

ここから先のカテゴリ別プロンプトは、2つの視点で読んでみてください。

1つ目は「コピペしてそのまま使えるプロンプト」。2つ目は「Skillsの参照文書を設計する時のパターン」。

各カテゴリの最後に、そのカテゴリのプロンプトをSkillsの参照文書に落とし込むとどうなるかの具体例を載せています。

ではここから、6カテゴリ40本のプロンプトを全て日本語でお届けします。

※ P21-28のテクニカル系はエンジニア向けのためタイトルのみ紹介しています。

ライティング・コンテンツ作成 10本

東大ClaudeCode研究所 - inline image

このカテゴリ10本すべてに「役割」と「品質基準」が組み込まれています。AIに専門家として振る舞わせ、かつ「ここまで達してなければダメ」という基準を伝える。この2つがあるだけで、AIの出力は「下書き」から「そのまま使える完成品」に変わります。

ライティングのプロンプトは、記事やメールだけでなく、日常の業務報告やプレゼン資料にもそのまま応用できます。

■ 01. エキスパート記事ライター

ブログやnote記事を書く時に。角度と構造を先に決めるのがポイント。

markdown
1あなたはトップクラスのメディアで執筆経験のあるシニアコンテンツストラテジストです。
2
3[トピック]について[文字数]文字の記事を書いてください。
4
5読者: [読者の属性と知識レベル]
6角度: [あなた独自の視点。他の同テーマの記事との差別化ポイント]
7
8構造:
9- フック: 大胆な主張か意外な事実で始める。ありきたりな導入はNG
10- 問題提起: このトピックに対する一般的な考え方がなぜ間違っているか、不完全か
11- フレームワーク: 主張を3〜5のセクションに分けて展開。それぞれに明確な見出し
12- 根拠: 各セクションに具体的な事例、ケーススタディ、データポイントを1つ以上
13- アクション: 読者が「今週中に」できる具体的なアクション3つで締める
14
15ルール:
16- 1段落3文以内
17- フィラー表現禁止(「重要なのは」「今日の世界では」等)
18- ヘッジワード禁止(「かもしれない」「おそらく」「〜のようだ」等)
19- 主張は全て具体的に。曖昧なものは不可
20- 各セクションで最も重要な1文を太字にする
21
22この記事は編集なしでそのまま公開できるレベルであること。

■ 02. スレッド設計

Xで連投スレッドを書く時に。フックから締めまで設計済みの構成

markdown
1[トピック]についてのXスレッドを書いてください。
2
3スレッド構成:
4- ツイート1: フック。大胆な主張、意外な統計、逆張りの視点。2秒でスクロールを止めさせる
5- ツイート2-3: 問題提起。なぜ多くの人がこれを間違えているか
6- ツイート4-10: フレームワーク。番号付きのステップ、テクニック、洞察。1ツイートに1つ。各ツイートが単独でも成立し、かつ全体として流れるように
7- ツイート11-12: フレームワークが機能する実例やケーススタディ
8- 最終ツイート: 1つの具体的なアクション + 行動喚起
9
10ルール:
11- 各ツイート280文字以内
12- 意味のない絵文字は使わない
13- 「ちょっと説明すると」「ここがポイントで」等の前置き禁止。各ツイートは中身から始める
14- 教科書ではなく、切れ味のいい友人から学んでいる感覚で
15
16合計: 12〜15ツイート。

■ 03. メール作成

markdown
1この状況でメールを書いてください: [状況、相手、目的を詳しく記述]
2
3トーン: [プロフェッショナル/カジュアル/ストレート/外交的]
4
5ルール:
6- 件名: 具体的かつ行動を促すもの(「ちょっと質問」「フォローアップ」はNG)
7- 冒頭: 最初の1文で本題に入る。社交辞令は不要
8- 本文: 短い段落3つまで。各段落の役割は1つだけ
9- 締め: 明確な次のアクションか依頼。相手が何をすればいいか迷わないこと
10- 全体: 150語以内
11
122バージョン作成:
13バージョンA: [トーン1。例: ストレートで断定的]
14バージョンB: [トーン2。例: 温かく協調的]
東大ClaudeCode研究所 - inline image

■ 04. コンテンツ展開

1つの記事からSNS・メルマガ・動画まで5展開したい時に

markdown
1このコンテンツを5つのフォーマットに展開してください。
2
3<元コンテンツ>
4[記事、投稿、文字起こし等を貼り付け]
5</元コンテンツ>
6
7作成するもの:
81. Xスレッド(12ツイート、各280文字以内)
92. LinkedIn投稿(200〜300語、プロフェッショナルだが堅すぎない)
103. ニュースレター導入文(100語、全文へのティーザー)
114. SNS投稿3本(それぞれ独立、それぞれ異なるインサイトをハイライト)
125. ショート動画台本(60秒、会話調、カメラに向かって話す想定)
13
14ルール:
15- 各フォーマットがそのプラットフォームに自然に馴染むこと。コピペ感は出さない
16- 核となる主張と重要なインサイトは全フォーマットで維持する
17- トーンはプラットフォーム別に調整: X=パンチがあってストレート、LinkedIn=プロフェッショナルで思慮深い、ニュースレター=パーソナルで限定感

■ 05. コピーライティング変換

自分が書いた文章をプロのコピーに変えたい時に。変更理由の解説付き

markdown
1このテキストをもっと説得力のある文章に書き換えてください。
2
3<元テキスト>
4[テキストを貼り付け]
5</元テキスト>
6
7以下のコピーライティング原則を適用:
8- 機能ではなくベネフィットを先に出す
9- 曖昧な表現の代わりに具体的な数字を使う
10- 反論が生まれる前に先回りして対処する
11- 操作的にならずに緊急性を生み出す
12- 明確でハードルの低い行動喚起で締める
13
14書き換え版を見せた後、最もインパクトのあった変更点3つと、それが心理学的になぜ効くかを説明してください。

■ 06. ブログ記事のアウトライン設計

構成を先に固めてから書きたい時に。

markdown
1[トピック]についてのブログ記事の詳細なアウトラインを作成してください。
2
3ターゲット読者: [誰]
4ゴール: [記事を読んだ後に読者がどうなっていたいか]
5目標文字数: [文字数]
6
7各セクションについて:
8- 見出し(魅力的で具体的。ありきたりにしない)
9- 2〜3文の要約
10- このセクションに必要なデータポイント、事例、または論拠
11- 次のセクションへのつなぎ
12
13併せて含めること:
14- 代替見出し案3つ(予測クリック率順にランク付け)
15- メタディスクリプション(160文字以内)
16- 内部/外部リンクの候補5件
東大ClaudeCode研究所 - inline image

■ 07. ストーリーテリング変換

データや事実をナラティブに変えたい時に。プレゼンや報告書の導入にも

markdown
1この味気ない事実情報を、引き込まれるナラティブに変換してください。
2
3<事実>
4[事実、データ、専門的な内容を貼り付け]
5</事実>
6
7ルール:
8- 定義からではなく、具体的なシーン・人物・瞬間から始める
9- 事実をストーリーアークに織り込む: 設定→緊張→解決
10- 複雑な概念を直感的に理解させるアナロジーを使う
11- 読者の理解が変わる「なるほど」の瞬間を1つ含める
12- 読者の人生に結びつくテイクアウェイで締める
13
14事実は正確なまま。変えるのは伝え方であって、内容ではない。

■ 08. 見出しジェネレーター

タイトルや見出しで悩む時に。

markdown
1このコンテンツに対する見出し案を20個作成してください: [コンテンツの概要]
2
3カテゴリ:
4- 好奇心型 5本(クリックせずにいられないもの)
5- ベネフィット型 5本(価値が一目で分かるもの)
6- 逆張り型 5本(読者の常識を揺さぶるもの)
7- 数字型 5本(具体的な数量や期間を使ったもの)
8
9各見出しについて:
10- 予測クリック率を1〜10で評価し、理由を説明
11
12総合TOP3を理由付きでランク付けしてください。
東大ClaudeCode研究所 - inline image

■ 09. ケーススタディ作成

導入事例や成功事例を作る時に。

markdown
1以下の事実をケーススタディにまとめてください。
2
3クライアント: [名前/業種]
4課題: [何に苦しんでいたか]
5解決策: [何を導入したか]
6結果: [測定可能な成果]
7
8構成:
91. 課題(2段落。読者がその痛みを感じられるように)
102. アプローチ(3〜4段落。具体的な手順。一般論ではなく)
113. 結果(1〜2段落。具体的な数字、Before/After比較)
124. 教訓(1段落。読者にも当てはまる学び)
135. プルクォート(結果に基づいて、クライアントが実際に言いそうな1文)
14
15ルール:
16- 臨場感のために現在形を使う
17- 具体的な数字を3つ以上含める
18- プルクォートはマーケティングコピーではなくリアルな言葉に

■ 10. 文体の再現

特定の文体を真似して書きたい時に。3サンプルからパターンを抽出する

markdown
1同じ著者による3つのライティングサンプルを分析してください。
2
3<サンプル1>[貼り付け]</サンプル1>
4<サンプル2>[貼り付け]</サンプル2>
5<サンプル3>[貼り付け]</サンプル3>
6
7以下を特定:
8- 文の長さのパターン(短い/ミックス/長い)
9- 語彙レベル(シンプル/専門的/ミックス)
10- トーン(フォーマル/カジュアル/権威的/会話的)
11- 構造的な癖(段落の長さ、見出しの使い方、箇条書きのパターン)
12- 繰り返し使うフレーズやパターン
13- 一貫して避けているもの
14
15分析後、[新しいトピック]について300語の文章を、この著者の文体を完全に再現して書いてください。元の著者が書いたと信じられるレベルで。

★ このカテゴリをSkillsの参照文書にすると...

東大ClaudeCode研究所 - inline image

P01〜P10のライティング系プロンプトには「制約」と「品質基準」が特に充実しています。これをそのままSkillsの参照文書に転用できます。

markdown
1.claude/skills/content-writer/
2 SKILL.md ← 役割の定義だけ
3 references/
4 writing-rules.md ← 制約。フィラー禁止、1段落3文以内
5 audience.md ← 文脈。読者の属性と知識レベル
6 format-templates.md ← 形式。記事・メール・スレッドの構造
7 quality-checklist.md ← 品質基準。公開レベルの判定条件

writing-rules.mdの中身はこうなります。

markdown
1## 制約
2- 1段落3文以内
3- フィラー表現禁止(「重要なのは」「今日の世界では」等)
4- ヘッジワード禁止(「かもしれない」「おそらく」等)
5- 主張は具体的に。曖昧なものは不可
6
7## 品質基準
8- 編集なしでそのまま公開できるレベルであること
9- 各セクションで最も重要な1文を太字にする

P01のプロンプトにある「ルール」と「品質基準」がそのまま参照ファイルの内容になっています。

SKILL.mdには役割だけ書き、細かいルールは参照ファイルに分離する。この構造にすると、記事を書く時もメールを書く時も同じ品質が維持されます。

分析・戦略立案 10本

東大ClaudeCode研究所 - inline image

なぜ同じAIに分析を頼んでも、使える回答とそうでない回答が出てくるのか。

答えはシンプルです。このカテゴリのプロンプトを見ると、「文脈」と「形式」が徹底的に指定されています。P12の意思決定マトリクスでは予算・タイムライン・チーム体制・目標を入力として求め、出力を「5基準×重み付け×スコアのテーブル」という形式で返させています。文脈の解像度が高いほど、AIは一般論を避けてあなたの状況に合った回答を出せるようになります。

■ 11. SWOT分析

新規事業やプロジェクトの戦略を整理したい時に。影響度付きで優先順位まで出る

markdown
1[会社/プロダクト/戦略]の包括的なSWOT分析を行ってください。
2
3各象限(強み・弱み・機会・脅威)について:
4- 5つの具体的な項目をリストアップ(一般論ではなく、この状況に特有のもの)
5- 各項目: なぜこの象限に入るかを1文で説明
6- 各項目の影響度: 高/中/低
7
8さらに:
9- この分析に基づく戦略的優先事項の第1位(1文)
10- この優先事項を無視した場合の最大リスク(1文)
11- 今週取るべき最初のアクション(1つ、具体的で実行可能なステップ)

■ 12. 意思決定マトリクス

markdown
1以下の選択肢から決断する必要があります: [2〜4つの選択肢をリストアップ]
2
3背景: [予算、タイムライン、チーム体制、目標]
4
5意思決定マトリクスを作成してください:
61. この決断で最も重要な5つの基準を特定(不明な場合は確認してください)
72. 各基準に重要度の重みを付ける(合計100%)
83. 各選択肢を各基準に対して1〜10でスコアリング
94. 加重スコアを計算
105. フォーマットされた表で提示
11
12その上で2段落の推薦文を:
13- どの選択肢を選ぶべきか、なぜか明確に述べる
14- 次点の最も強い論拠を認める
15- 推薦が変わる条件を1つ特定する

■ 13. 根本原因分析

問題の本当の原因を突き止めたい時に。「5 Whys」で表面から根本まで掘る

markdown
1直面している問題: [問題とその症状を説明]
2
3根本原因分析を行ってください:
41. 「なぜ?」を5回連続で掘り下げる(5 Whys)。毎回より深い層へ
52. 各レベルで、それが症状なのか根本原因なのかを特定
63. 最深部で、真の根本原因を特定
74. 3つの解決策を提案。表面的な症状への対処、中間的な原因への対処、根本原因への対処を1つずつ
85. どの解決策を実行すべきか、なぜかを推薦
9
10私が最初に述べた問題の定義を額面通りに受け取らないでください。本当の問題は、私が説明したものとは違うことが多いです。
東大ClaudeCode研究所 - inline image

■ 14. 市場機会の分析

新しいアイデアの可能性を見極めたい時に。

markdown
1[プロダクト/サービスのアイデア]の市場機会を分析してください。
2
3評価項目:
41. 需要: 誰が欲しがっているか。何人いるか。欲しがっている根拠は
52. 競合: 他に誰が提供しているか。いくらか。どこが弱いか
63. タイミング: なぜ今なのか。以前は実現できなかったのに、今なら可能な理由は
74. 参入障壁: 6ヶ月以内に競合がコピーするのを防ぐものは何か
85. ユニットエコノミクス: 顧客1人あたりの提供コスト vs 請求可能額
9
10各セクション: 可能な限り数字で具体的に。不確実な点は明示すること。
11
12最後にGO / 慎重にGO / NO GO の判定と、確信度(高/中/低)を提示してください。

■ 15. ミーティング戦略

重要な商談やクライアントMTGの前に。想定問答まで準備できる

markdown
1[トピック]について[相手。役割、関係性、相手が重視すること]とのミーティングがあります。
2
3このミーティングでの目標: [達成したいこと]
4
5準備:
61. 冒頭の発言(2文。会話の適切なフレームを設定する)
72. 必ず伝えるべき3つのキーポイント(優先順位順)
83. 聞くべき3つの質問(重要度順)
94. 想定される3つの反論と、それぞれへの対応
105. 理想的なクロージング(合意内容と次のアクションをまとめる)
116. 撤退ライン: 最低限許容できる結果は何か

■ 16. 価格設計

プロダクトやサービスの価格を決める時に。3ティア構成と心理学的根拠付き

markdown
1[プロダクト/サービス]の価格設定を手伝ってください。
2
3背景:
4- 何をするか: [説明]
5- 誰向けか: [ターゲット顧客]
6- 提供コスト: [コスト]
7- 競合の価格: [分かれば]
8- 提供する価値: [顧客が得るもの。時間の節約、売上増加、問題の解決]
9
10価格体系を設計:
111. 3ティア(入門/本命/プレミアム)。サイズではなく価値を反映する名前で
122. 各ティアに含まれるものと、その境界が存在する理由
133. 各価格帯の心理学的な根拠
144. 大半の顧客がどのティアに着地すべきか、そこに誘導する方法
155. 一括払い vs サブスクリプションの分析。どちらが適切でなぜか
16
17フォーマットされた比較表で提示してください。

■ 17. 競合分析

競合の弱点を見つけたい時に。5軸で丸裸にして差別化ポイントまで出す

markdown
1[競合名/URL]の競合分析を行ってください。
2
3分析:
41. ポジショニング: コアメッセージは何か。誰をターゲットにしているか。どんな感情を売っているか
52. プロダクト: 実際に何を提供しているか。コア機能と付加価値の区別は
63. 価格設定: どう課金しているか。各ティアの内容は。利益率はどこか
74. コンテンツ: どんなトピックを発信しているか。頻度は。最も反応の良いフォーマットは
85. 弱点: どこが脆弱か。顧客は何に不満を持っているか。何をやっていないか
9
10最後に:「もし[競合名]と直接競合するなら、私が違うことをする3つのこと」で締めてください。

■ 18. OKR設計

チームや個人の目標を構造的に設定したい時に。

markdown
1[チーム/個人/会社]の[期間]のOKRを作成してください。
2
3背景: [現状。今いる場所、目指す場所、使えるリソース]
4
5各Objective(3つ提案)について:
6- Objective: 野心的だが達成可能。定性的。インスパイアするもの
7- 3〜4のKey Result: 具体的、測定可能、期限付き
8- 各Key Resultについて: 現在のベースライン、ターゲット、測定方法
9- 達成可能性の確信度(1〜10)
10
11Key Result同士が矛盾していないかフラグを立ててください。

■ 19. リスク評価

新しい施策やプロジェクトのリスクを事前に洗い出したい時に。

markdown
1[施策/決断/プロジェクトを説明]を実行しようとしています。
2
3リスク評価を行ってください:
41. 最も起こりやすいリスク7つをリストアップ
52. 各リスクについて:
6 - 発生確率: 高/中/低
7 - 発生した場合の影響: 高/中/低
8 - 早期警告サイン(このリスクが現実化していると気づく方法)
9 - 予防策(発生を防ぐためにできること)
10 - 緊急対応策(発生してしまった場合にどうするか)
113. 全リスクを2×2マトリクスにプロット(発生確率 vs 影響度)
124. 積極的に監視すべきTOP3リスクを特定
13
14楽観的にならないでください。私が考えていないリスクを聞きたいのであって、「大丈夫ですよ」という安心感ではありません。
東大ClaudeCode研究所 - inline image

■ 20. 振り返りファシリテーター

プロジェクトの振り返りを構造的にやりたい時に。

markdown
1このプロジェクト/期間の振り返りを進行してください: [何が起きたかを説明]
2
3構成:
41. うまくいったこと(具体的に5つ。根拠付き)
52. うまくいかなかったこと(具体的に5つ。根本原因付き)
63. 学んだこと(今後の仕事の仕方を変える3つの教訓)
74. 次に変えること(具体的で実行可能な3つの変更。曖昧な意気込みではなく)
85. やめること(意図的にやめる2つのこと)
9
10ルール:
11- 具体的に。「コミュニケーションが悪かった」は無意味。「プロダクトチームが価格変更をローンチ2日前まで知らされず、マーケ資料の更新に追われた」が有意味
12- 特定されたすべての問題に、具体的な予防アクションを含めること

★ このカテゴリをSkillsの参照文書にすると...

東大ClaudeCode研究所 - inline image

分析・戦略系のプロンプトは「形式」の指定が特に精密です。この形式をそのまま参照ファイルに保存すると、何度でも同じ分析フレームワークを呼び出せます。

markdown
1.claude/skills/decision-support/
2 SKILL.md ← 役割。「ビジネスアナリスト」
3 references/
4 frameworks.md ← 形式。SWOT/意思決定マトリクス/5 Whysのテンプレート
5 company-context.md ← 文脈。自社の予算/目標/チーム体制
6 risk-criteria.md ← 制約。「楽観禁止」「不確実な点は明示」

frameworks.mdの中身はこうなります。

markdown
1## 意思決定マトリクス
21. 5つの基準を特定
32. 各基準に重みを付ける(合計100%)
43. 各選択肢を1〜10でスコアリング
54. 加重スコアを計算
65. 推薦が変わる条件を1つ特定する
7
8## 根本原因分析
91. 「なぜ?」を5回連続で掘り下げる
102. 表面/中間/根本の3レベルで解決策を提案
113. 問題の定義を額面通り受け取らない

P12とP13のプロンプトの「出力構造」が、そのまま参照ファイルのテンプレートになっています。company-context.mdに自社の情報を1回書いておけば、SWOT分析でもリスク評価でも毎回入力し直す必要がなくなります。

テクニカル 8本 (タイトルのみ)

P21〜P28はコードレビューやAPI設計などエンジニア向けの内容です。全文は元記事を参照してください。技術チームがいれば、この記事ごと共有するのがおすすめです。

**■ 21. アーキテクチャアドバイザー

■ 22. コードレビュー

■ 23. デバッグ診断

■ 24. API設計

■ 25. データベーススキーマ設計

■ 26. テストケース作成

■ 27. ドキュメント作成

■ 28. リファクタリング計画**

仕事の生産性 4本

東大ClaudeCode研究所 - inline image

P29の週間計画プロンプトには「意図的にスキップするもの」というセクションがあります。やることリストではなく、「やらないことリスト」を要求している。

ここにこのカテゴリの設計思想が凝縮されています。「文脈」として自分の四半期目標や先週の実績を渡し、「制約」として現実的な時間の限界を伝える。AIは「全部やりましょう」ではなく「これを捨てましょう」と言ってくれるようになります。

■ 29. 週間プランナー

月曜の朝に。四半期目標から逆算して「やらないこと」まで決められる

markdown
1今四半期の目標: [リストアップ]
2先週の実績: [簡潔なサマリー]
3今週のコミットメント: [ミーティング、締切、義務]
4
5週間計画を作成してください:
61. TOP3優先事項(四半期目標にとって最も重要なもの)
72. スケジュール(曜日別のミーティングと締切)
83. バッファタスク(重要だが柔軟なもの)
94. 意図的にスキップするもの(今週あえてやらないこととその理由)
東大ClaudeCode研究所 - inline image

■ 30. 学習アクセラレーター

markdown
1[トピック/スキル]を学びたいです。
2
3現在のレベル: [初心者/中級者/上級者]
4使える時間: [週あたりの時間数]
5学習スタイル: [実践型/理論型/ミックス]
6ゴール: [学習後に何ができるようになりたいか]
7
8学習プランを作成してください:
91. 前提条件: 先に知っておくべきことは何か(基礎が足りなければ正直に)
102. 核となる概念: 理解すべき5〜7の重要な考え方。学ぶべき順番で
113. プロジェクト: 各概念につき、作ることで学べるハンズオンプロジェクトを1つ
124. リソース: 各概念につき、最も優れたリソースを1つだけ(10個の選択肢ではなく、1つ)
135. マイルストーン: 各概念を本当に理解したかどうかの判定方法(「慣れた気がする」ではなく、具体的なテスト)
146. タイムライン: 使える時間を前提にした、現実的な週単位のプラン
15
16プランを水増ししないでください。3週間で学べるなら8週間に引き延ばさない。

■ 31. 交渉準備

給与交渉や取引先との交渉の前に。譲歩の順序から撤退ラインまで設計できる

markdown
1[何を]について[誰と]交渉します。
2
3背景: [関係性、経緯、力関係]
4理想的な結果: [ベストケース]
5許容できる結果: [最低限受け入れられるもの]
6相手の立場の予測: [相手がおそらく求めていること]
7
8準備:
91. 最初のポジションとその根拠
102. 提示できる譲歩3つ(小さいものから大きいものの順)
113. 各譲歩の見返りに求めるもの3つ
124. 相手が出す可能性の高い反論3つと、それぞれへの対応
135. 双方にとって価値が増える創造的な選択肢2つ(パイを広げる)
146. 撤退ラインと、品よく退出するための具体的な言葉

■ 32. 習慣デザイナー

新しい習慣を始めたい時に。

markdown
1この習慣を身につけたいです: [習慣を説明]
2
3現在のルーティン: [普段の1日がどんな感じか]
4過去の挑戦: [以前試したことと、なぜ失敗したか]
5
6習慣の実装プランを設計してください:
71. 最も小さなバージョン(2分で終わるスターター版)
82. トリガー: 既存のどの習慣やイベントにくっつけるか
93. 環境のデザイン: 習慣を簡単にするための物理的な変更
104. 報酬: 習慣を強化する即座のポジティブフィードバック
115. 記録方法: 継続性をどう測定するか
126. 失敗プロトコル: 1日サボった時にどうするか(必ずサボる日は来るから)
137. 段階的拡大: 2分版が4週間でどう成長するか
14
15現実的にしてください。1週間で捨てる完璧なルーティンより、続く小さな習慣のほうがいい。

★ このカテゴリをSkillsの参照文書にすると...

週次計画は毎週やることです。だからこそSkills化の効果が大きい。

markdown
1.claude/skills/weekly-planner/
2 SKILL.md ← 役割。「生産性コーチ」
3 references/
4 quarterly-goals.md ← 文脈。今四半期の目標(四半期ごとに更新)
5 skip-criteria.md ← 制約。「意図的にスキップ」の判定基準
6 schedule-format.md ← 形式。出力フォーマット

quarterly-goals.mdを四半期の初めに1回書いておけば、毎週月曜の朝に「/weekly-plan」と打つだけで、目標に整合した計画が出てきます。先週の実績だけ入力すれば済む状態です。

データ分析・リサーチ 3本

東大ClaudeCode研究所 - inline image

AIにデータを「まとめて」と言うと、表面的なサマリーが返ってきます。

このカテゴリのプロンプトはそうなりません。P33のデータ分析では「まず分かりやすい言葉で結論を述べ、その後に裏付けとなる数字を付けて」と形式を指定しています。

P35のリサーチ統合では「個別に要約するだけではダメです。ソースを横断するつながりとパターンを」と品質基準を設定しています。形式の指定がAIの思考順序を変え、品質基準の設定が「まとめ」を「洞察」に変えます。

■ 33. データ分析

売上データやアンケート結果を分析したい時に。「ミスリードの可能性」まで教えてくれる

markdown
1このデータを分析してください。
2
3<データ>
4[CSV、テーブル、数値、アンケート結果等を貼り付け]
5</データ>
6
7提供してほしいもの:
81. サマリー統計(一目で分かるキーナンバー)
92. 最も重要なパターンやトレンド3つ
103. すぐには見えない意外な発見2つ
114. このデータのミスリードになりうる側面1つ(誤解されやすい点は)
125. このデータが提起する、追加データが必要な質問3つ
13
14読者: [この分析を読む人と、その技術レベル]
15まず分かりやすい言葉で結論を述べ、その後に裏付けとなる数字を付けてください。

■ 34. アンケート分析

アンケートの回答データを構造的に分析したい時に。

markdown
1このアンケート結果を分析してください。
2
3<アンケートデータ>
4[回答データを貼り付け]
5</アンケートデータ>
6
7提供してほしいもの:
81. 回答者のデモグラフィック/セグメントの特徴
92. 重要度順にランク付けしたTOP5の発見
103. 強い合意がある領域(回答者の意見が一致している点)
114. 意見が分かれている領域
125. 一般的な想定に反する意外な発見
136. データに基づく実行可能な推薦3つ(具体的にやるべきこと)
147. このデータの限界(サンプルサイズ、バイアス、結論を出せないこと)

■ 35. リサーチ統合

複数の情報源から1つの結論を出したい時に。個別要約ではなくソース横断の統合

markdown
1[トピック]について複数のソースからリサーチを集めました。
2
3<ソース1>[貼り付けまたは要約]</ソース1>
4<ソース2>[貼り付けまたは要約]</ソース2>
5<ソース3>[貼り付けまたは要約]</ソース3>
6
7統合してください:
81. 全ソース共通のテーマ(何について合意しているか)
92. 矛盾点(どこで意見が割れているか。どちらが信頼できるか、なぜか)
103. ギャップ(まだ答えが出ていない問いは何か)
114. 自信を持って出せる重要な結論3つ
125. 理解を強化するために次にリサーチすべきこと
13
14各ソースを個別に要約するだけではダメです。本物の統合を求めています。個別に読んだだけでは見えない、ソースを横断するつながりとパターンを。

★ このカテゴリをSkillsの参照文書にすると...

markdown
1.claude/skills/research-synthesizer/
2 SKILL.md ← 役割。「リサーチアナリスト」
3 references/
4 source-evaluation.md ← 品質基準。ソースの信頼度判定ルール
5 synthesis-rules.md ← 制約。「個別要約禁止。統合のみ」
6 output-template.md ← 形式。合意/矛盾/ギャップの出力構造

synthesis-rules.mdに「個別に要約するだけではダメ。ソースを横断するつながりを見つけること」とP35の品質基準をそのまま書いておけば、毎回の分析で同じ品質が出ます。AIが「まとめ」ではなく「洞察」を出す構造が参照ファイルに定義されている状態です。

コミュニケーション 5本

東大ClaudeCode研究所 - inline image

上司との1on1、部下へのフィードバック、取引先への謝罪。こういう場面で「何を言うか」だけでなく「相手がどう反応したらどう返すか」まで準備できたら、どれだけ楽でしょうか。

このカテゴリでは「役割」の使い方がユニークです。自分に役割を与えるのではなく、相手の立場をAIに想定させます。P36では「相手の反応予測」を入力に含め、P40では「相手の言葉で問題を描写」と指定しています。さらに「具体例」の要素で複数バリエーションを生成させます。P39の謝罪では書面版と口頭版、P40のピッチでは3つのエネルギーレベルを出し分ける設計です。

■ 36. 難しい会話の準備

上司との会話などより、カスタマーサクセスなどの文脈の方が効果があると個人的には思います。

markdown
1[トピック]について[相手。役割、関係性]と難しい会話をする必要があります。
2
3状況: [何が起きて、なぜこの会話が必要か]
4目標: [達成したいこと。言いたいことだけではなく]
5相手の反応予測: [どう反応すると予想するか]
6
7準備:
81. 冒頭の発言(ストレートだが共感的。問題を避けないが人を攻撃しない)
92. コアメッセージを1文で(会話がどう転んでも、これだけは伝えなければならないこと)
103. 防御的な反応への対応(「そんなの不公平だ」「あなたが間違ってる」等への具体的な返し方)
114. 積極的に聴く方法(相手の視点を理解するために聞くべき質問)
125. 着地点(最良→許容できるの3つの結果をランク付け)
136. クロージング(合意をまとめ、関係性を維持し、次のステップを定義する)

■ 37. フィードバック設計

部下やチームメンバーに成長を促すフィードバックをしたい時に。会話形式で出力される

markdown
1[相手。役割、関係性]に[何について。具体的な行動や成果物]のフィードバックを伝える必要があります。
2
3背景: [良好な関係? 繰り返しの問題? 初めて?]
4
5以下のフレームワークでフィードバックを下書きしてください:
61. 観察(具体的に何を観察したか。性格ではなく行動)
72. 影響(チーム、プロジェクト、成果にどう影響したか。具体的に)
83. 期待(今後どうしてほしいか。具体的かつ達成可能)
94. サポート(成功するために自分が何をするか。変化を要求するだけではなく)
10
11トーン: [支援的/ストレート/真剣]
12
13メモではなく、話し言葉として書いてください。これはメールではなく会話です。
東大ClaudeCode研究所 - inline image

■ 38. プレゼンテーション設計

社内プレゼンや提案の構成を組みたい時に。

markdown
1[トピック]のプレゼンテーションのアウトラインを作成してください。
2
3聴衆: [誰で、何を重視しているか]
4持ち時間: [長さ]
5ゴール: [プレゼン後に聴衆がどうしてほしいか]
6
7構成:
81. オープニング(30秒。スマホを置かせるフック)
92. 問題提起(1〜2分。現状の課題を感じさせる)
103. 解決策(3〜5分。フレームワーク/提案/インサイトを3つの明確なポイントに分けて)
114. 根拠(2〜3分。各ポイントの具体的な事例、データ、ケーススタディ)
125. 反論対応(1〜2分。最大の懸念を相手が口にする前に対処)
136. 行動喚起(30秒。次に何をしてほしいか正確に)
14
15各セクションについて: スライドの主要コンテンツ、スピーカーノート、次のセクションへのつなぎの一文を。

■ 39. 謝罪の設計

仕事上のミスを謝罪する必要がある時に。こちらもCS文脈などが利用可能性が高いと考えています。

markdown
1[相手]に[何が起きたか]について謝罪する必要があります。
2
3背景: [状況。自分がしたこと、その影響、相手との関係]
4
5以下の要件を満たす謝罪文を作成してください:
61. 自分が何を間違えたか具体的に認める(曖昧にせず、具体的な行動を)
72. 相手への影響を理解していることを示す(自分の視点ではなく、相手の視点から)
83. 全責任を取る(「でも」「もし」「言い訳」一切なし)
94. 今後何を変えるか説明する(具体的、実行可能、検証可能)
105. 許しを求めない(許すかどうかは相手の選択であって、自分の要求ではない)
11
12トーン: 誠実かつストレート。200語以内。過剰な説明なし。自分の感情に焦点を当てない。
13
142バージョン作成:
15バージョンA: 書面(メール/メッセージ)
16バージョンB: 口頭(対面で話す場合)

■ 40. エレベーターピッチ

投資家ピッチや自己紹介で。

markdown
1[プロダクト/サービス/アイデア]のエレベーターピッチを作成してください。
2
3聴衆: [誰にピッチするか]
4場面: [投資家ミーティング、ネットワーキングイベント、コールドアウトリーチ等]
5持ち時間: [30秒 / 60秒 / 2分]
6
7構成:
81. フック(もっと聞きたいと思わせる1文)
92. 問題(痛みを1文で描写。自分の言葉ではなく相手の言葉で)
103. 解決策(自分が何をするか1文で。仕組みではなく、相手にとって何をしてくれるか)
114. 証明(信頼性を示す1文。実績、成果、注目クライアント)
125. お願い(次に何をしてほしいか1文)
13
143つのエネルギーレベルで作成:
15バージョンA: 自信に満ちて大胆
16バージョンB: 会話的で温かい
17バージョンC: データ駆動で精密
18
19各バージョンは声に出して話した時に自然に聞こえること。書き言葉ではなく。

★ このカテゴリをSkillsの参照文書にすると...

東大ClaudeCode研究所 - inline image

コミュニケーション系は「相手の情報」が鍵です。この情報を参照ファイルに蓄積しておくと、毎回の会議準備で威力を発揮します。

markdown
1.claude/skills/meeting-prep/
2 SKILL.md ← 役割。「コミュニケーション戦略アドバイザー」
3 references/
4 stakeholder-profiles.md ← 文脈。主要な関係者のプロフィールと重視すること
5 meeting-types.md ← 形式。会議タイプ別の準備テンプレート
6 response-patterns.md ← 具体例。過去の反応パターンと対応策

stakeholder-profiles.mdに上司や取引先の「重視すること」「過去の反応パターン」を書いておけば、会議のたびに「相手はどんな人か」を入力し直す手間がなくなります。AIは蓄積された文脈をもとに、相手に合わせた準備を出力してくれます。

プロンプト集は終着点ではなく入口

東大ClaudeCode研究所 - inline image

40本のプロンプトが手に入りました。ここからどう使いこなすかで、結果が大きく変わります。

Khairallah氏は元記事で4つのステップを提案しています。

■ まずはこの4つから

**1. 保存する

**40本を暗記する必要はありません。必要な時にこの記事に戻ってくればいい。だから最初にこの記事を保存してもらったんです。もっというと、このプロンプトや記事本文をClaude Codeに解析してもらってもいいんです。

**2. 今週5本を使う

**自分の仕事に最も近い5本を選んでください。[トピック]や[読者]の部分を自分の状況に書き換えて、そのまま貼り付けて使います。

**3. うまくいったプロンプトを保存する

**カスタマイズして良い結果が出たプロンプトは、テキストファイルに保存してください。「提案書レビュー用」「週次計画用」のようにフォルダ分けすると、自分専用のプロンプトライブラリが育っていきます。

**4. 毎週2-3本ずつ拡張する

**使ったことのないカテゴリから2-3本試して、対応できる仕事の幅を広げていく。最初はライティングだけだったのが、分析→コミュニケーション→データと広がっていくイメージです。

Khairallah氏はこう言っています。

「1ヶ月間一貫して使い続ければ、あなたのAIワークフローは、ほとんどの人が何年もかけて到達するレベルに達する」

■ さらにその先へ

ここからは、プロンプト集を起点にした発展パスです。

保存したプロンプトが増えてきたら、次のステップが見えてきます。何度も使うプロンプトに名前をつけて管理する。「提案書レビュー」「週次計画」のようにフォルダに分けると、自分専用のプロンプトライブラリができあがります。

Claude Codeには、このライブラリを「Skills」として登録し、コマンド1つで呼び出せる仕組みがあります。Skillsとは、再利用可能な業務パターンの定義です。自分の仕事を構造化して説明できる人なら誰でも作れます。

▼ Claude Code Skillsの入門をしたい人は下記も読みましょう ▼

東大ClaudeCode研究所 avatar

東大ClaudeCode研究所

@ClaudeCode_UT

·

Apr 25

東大ClaudeCode研究所 on X — cover

Article

【完全保存版】Claude Code SkillsでAIに仕事のやり方を覚えさせる徹底ガイド

「プログラミング知識ゼロだからAI活用できるか不安...」

「ターミナルの黒い画面を見るのが怖いし気が進まない」

「でも、AIの流れに置いていかれるのは不安

東大ClaudeCode研究所 - inline image

そんな状態でも、Claude Code...

1

87

825

584K

この記事で紹介した各カテゴリの「Skillsの参照文書にすると」の例を見てもらえば分かる通り、プロンプトの6要素がそのまま参照ファイルの設計パターンになります。

大事なのは、1つのファイルに全部詰め込まないこと。情報を用途別に分離して、必要な時に必要なファイルだけをAIに読み込ませる。

Skillsが増えていくと、AI環境全体が自分仕様に育っていきます。プロンプトの質がAI環境設計の入口です。今日の40本は終着点ではなく、その入口に立ったということです。

まとめ

  • 500個テストして残った40本は「願望」ではなく「設計された指示」。構造の有無で出力品質が根本的に変わる
  • プロ品質のプロンプトには6つの要素がある: 役割・文脈・制約・形式・品質基準・具体例
  • この6要素はそのままClaude Code Skillsの参照文書の構造化に使える
  • SKILL.mdに全部詰め込まず、references/ に用途別に分離すると精度が安定する
  • ビジネス系5カテゴリ32本で「書く・考える・計画する・調べる・話す」の全領域をカバー
  • プロンプト集は終着点ではなく「Skills設計 → AI環境全体の設計」の入口

この記事では32本のプロンプトとSkillsの参照文書設計パターンを紹介しました。まずは自分の仕事に近いカテゴリから1本コピペして試してみてください。

最後まで読んでいただいた方へ。

東大ClaudeCode研究所 - inline image

東大Claude Code研究所は、現役東大生チームで運営しているアカウントです。Claude Codeガチ勢がビジネス業務で使える情報を実践して発信します。

大手企業とのAIエージェント共同開発も進行中。実務で培った知見を毎日発信しています。

フォローするとこんな情報を受け取れます 👇

■ 東大生が開発したClaude Codeスキルやツールの無料配布

■ Skillsの設計パターンや参照文書の構造化ノウハウ

■ 海外で192万回読まれたAI活用術の日本語完全解説

ご興味を持っていただけた方は、ぜひフォローしてチェックしてみてください。

スキルの受け取りや限定情報は公式LINEで配信中です。 https://lin.ee/quYxNMc

Save to YouMind

Use YouMind to read viral articles deeply

Save the source, ask focused questions, summarize the argument, and turn a viral article into reusable notes in one AI workspace.

Explore YouMind
クリエイターのために

あなたの Markdown をきれいな 𝕏 記事に

自分の長文を投稿するとき、画像・表・コードブロックを 𝕏 向けに整形するのは手間がかかります。YouMind は Markdown 全体を、そのまま投稿できるきれいな 𝕏 記事に変換します。

Markdown → 𝕏 を試す

解読すべきパターンをもっと

最近のバイラル記事

バイラル記事をもっと見る