はじめに
Claude Opus のような性能の高いモデルを使っていると、プロンプトの長さはあまり関係ないことに気づきます。効くのは長さではなく、AIに何を判断させるか、です。
最近、海外で紹介されていた Prompt Tier List という整理を見て、これは普段の使い方を見直すのにちょうどいいと思いました。Prompt Tier Listは、プロンプトの効き方をいくつかの段階に分けたものです。
先に言っておくと、この記事を読んだ人はかなりラッキーです。最後に紹介する Tier SS を知っているだけで、他の人を一歩追い越せるからです。そして、Tier SSはストックしておかないともったいないレベルの考え方です。
たとえば、こういうプロンプトは誰でも使います。
短く説明してください
箇条書きで説明してください
初心者向けに説明してください
これはこれで便利です。ただ、Opus のようなモデルだと、もう一段上の頼み方をしたほうが返ってくるものが変わります。
私の前提を疑ってください
見落としている点を教えてください
間違った問題を解こうとしていたら止めてください
ゴールを修正してから作業してください
この違いがわかると、AIを文章生成ツールではなく、相談相手として使えるようになります。この記事では、Prompt Tier Listを下敷きにして、その頼み方を段階ごとに整理します。
Prompt Tier Listの全体像
プロンプトを6段階で整理します。下にいくほど、AIを単なる作業者ではなく判断役として使う頼み方になります。
| Tier | 位置づけ | プロンプトの特徴 |
|---|---|---|
| Tier D | 古い習慣 | 長いだけ、儀式的、過剰な役割指定 |
| Tier C | 形式指定 | 短く、箇条書き、初心者向け |
| Tier B | 判断材料の整理 | 前提、メリット・デメリット、比較 |
| Tier A | 前提の検証 | 見落とし、失敗点、不要な要素の指摘 |
| Tier S | 思考パートナー化 | 重要な質問、勝ち筋、依頼の修正 |
| Tier SS | ゴール補正 | 間違った問題を止め、目的を修正させる |
Tier D：長いプロンプトの罠
プロンプト例
あなたは世界クラスの専門家です
ステップバイステップで考えてください
回答する前に深呼吸してください
とても長く詳細な回答を書いてください
解説
昔からよく見る形です。一見強そうですが、Opus 4.8のような新しいモデルでは効果が薄いことが多いです。問題は、AIに何を判断してほしいのかが書かれていないことにあります。
「あなたは世界クラスの専門家です」と書いても、何を優先すべきかは伝わりません。「とても長く詳細に」と頼むと、長いだけの回答になりがちです。
効くのは長さではなく、どの観点で考えて、どの基準で判断して、どの形で出すか、を指定することです。Tier Dは「AIを使っている感」は出ますが、成果には直結しにくいです。
Tier C：形式を整えるプロンプト
プロンプト例
短くしてください
箇条書きで説明してください
初心者向けに説明してください
英語で回答してください
解説
出力形式を整える指示です。実務でもよく使います。社内共有なら「箇条書きで簡潔に」、初心者向けなら「専門用語を避けて」、といった指示は効きます。
ただし整うのは見た目と読みやすさだけで、AIの考える中身は変わりません。便利ですが、ここで止まると活用としてはまだ浅いです。
Tier B：判断材料を整理するプロンプト
プロンプト例
まず前提条件をリストアップしてください
メリットとデメリットを示してください
足りない点を見せてください
3つの選択肢を比較してください
解説
Tier Bから価値が一段上がります。文章作成ではなく、判断材料の整理をAIにさせているからです。
技術選定なら「この実装方針のメリット・デメリット・リスクを整理して」、企画検討なら「この施策の選択肢を3つ比較して判断材料を整理して」と頼めます。返ってくるのは説明ではなく、意思決定に使える材料です。実務だとこのあたりからかなり使えます。
ただ、Tier Bは「与えられた問いに答える」段階です。その問い自体が正しいかは、まだ問えていません。
Tier A：前提を疑わせるプロンプト
プロンプト例
回答する前に、私の前提を疑ってください
私が見えていない点を教えてください
この中で不要な部分はどこですか？
現実では、これはどこで失敗しますか？
解説
ここからAIをレビュー担当として使えます。実務では、依頼内容そのものがずれていることがよくあります。
「この機能を追加したい」と思っても、本当に必要なのは既存導線の改善かもしれない。「この文章をもっと丁寧にしたい」と思っても、必要なのは丁寧さより論点の整理かもしれない。人間の依頼は最適とは限りません。
だから、こう一文足すだけで役割が変わります。
私の前提で間違っている可能性がある点を指摘してください
AIが「言われたことを処理する存在」から、「依頼そのものをレビューする存在」になります。
Tier S：思考パートナー化するプロンプト
プロンプト例
回答を変える本当に重要な質問だけをしてください
3つの方向性を示し、どれが勝ち筋か教えてください
私の依頼が弱い場合は、修正してください
解説
方向性の選定まで任せる段階です。丸投げではなく、判断の補助線を引かせるイメージです。
この方針について3つの方向性を示し、
最も成果につながる案を1つ選んでください
こう頼むと、案を出すだけでなく比較して選んでくれます。次のような頼み方も効きます。
回答を大きく変える質問だけしてください。
不要な確認質問はしないでください。
質問が多すぎて手が止まることがあるので、質問は許可しつつ重要なものに絞らせる。壁打ち相手として使うときに役立ちます。
Tier SS：ゴールを補正させるプロンプト
プロンプト例
ゴールを修正してから、作業をしてください
私が間違った問題を解こうとしているなら止めてください
主導権を持って、最善の道を選んでください
解説
ここが一番効きます。Tier SSは「作業」ではなく「目的そのものの見直し」をAIに任せるからです。
多くの人は「この作業をしてください」と頼みます。一方で、こう頼むと結果が変わります。
この作業をする前に、そもそもこのゴールが正しいか確認してください
間違ったゴールに向かって高品質なアウトプットを出しても、成果にはつながりません。たとえば「社内向けに長文の説明資料を作りたい」と思っても、本当に要るのは1枚の要約スライドだったりします。「新機能を実装したい」と思っても、必要なのは既存機能の使いづらさの解消だったりします。
つまり作業を頼む前に、解くべき問題が正しいかを一度問う。Tier SSは、その問いをAIに持たせる頼み方です。
作業を依頼する前に、まずゴールを確認させる。この順番が、Tier SSの肝です。
知っている人と知らない人で何が変わるか
Tier SSを使うかどうかで、AIの使い方が変わります。
知らない場合は、思いついた作業をそのまま頼んで、出力の良し悪しを人間が判断する流れになります。これでも効率化はできますが、ゴール設定が間違っていると、AIは間違った方向に全力で進みます。
使っている場合は、まず依頼のゴールをAIに検証させて、必要ならゴールを修正させてから作業に入ります。この使い方だと、AIは作業代行ではなく、目的設定・方針選定・リスク検出まで手伝う相談相手になります。
多くの人はまだAIに作業を頼んでいる段階です。だからこそ、目的まで検証させられるかどうかで差がつきます。Tier SSを知っているだけで、まだ作業しか頼んでいない人たちを一歩追い越せます。ここまで読んだ人はラッキーです。
実務で使える汎用Tier SSプロンプト
ひとまずコピペで使える形にしておきます。
まず、私の依頼のゴールが適切か確認してください。
より良いゴールがある場合は、最初に修正案を提示してください。
そのうえで、最も成果につながる進め方を選んでください。
実行時は以下を必ず行ってください。
1. 私の前提で間違っている可能性がある点を指摘する
2. 見落としている論点を挙げる
3. 現実運用で失敗しそうな点を示す
4. 複数の選択肢がある場合は、最も良い案を1つ選ぶ
5. 不明な点は断言せず、不明と明記する
6. 推測は「推測です」と明記する
必要な質問がある場合は、回答を大きく変える質問だけしてください。
質問が不要な場合は、そのまま作業を進めてください。
実装方針のレビュー、技術選定、不具合調査、設計方針の比較、社内説明の整理、業務改善案の作成など、いきなり作業させたくない場面で使えます。
エンジニア向けの活用例
エンジニアの場合、AIにいきなり手を動かさせるより、最初に「その方針が正しいか」を確認させたほうが効くことが多いです。
例1：実装方針をレビューさせる
「この機能を実装してください」ではなく、こう頼みます。
この機能を実装する前に、
そもそもこの実装方針が適切か確認してください。
より安全・保守しやすい設計がある場合は、
現在の方針をそのまま進めず、改善案を提示してください。
そのうえで、最もリスクの低い実装手順を提案してください。
Claude Codeのように実際にコード変更まで行えるツールでは、特に効きます。変更させる前に方針を疑わせる。これだけでだいぶ安全になります。
例2：技術選定の前提を疑わせる
「このライブラリを導入する前提で実装方法を教えて」と頼む前に、そもそも導入すべきかを確認させます。
このライブラリを導入する前提が本当に適切か確認してください。
既存機能で代替できる可能性、
導入による保守コスト、
将来的なリスクを整理してください。
そのうえで、導入すべきか、導入しない方がよいかを判断してください。
導入後の保守コストは実装時点では見えにくいので、「使えそうだから入れる」ではなく「本当に入れるべきか」を先に問わせる価値があります。
例3：不具合調査で原因仮説を整理させる
「このバグを修正してください」ではなく、先に原因仮説を整理させます。
この不具合について、いきなり修正案を出す前に、
原因として考えられる仮説を整理してください。
そのうえで、
1. 可能性が高い原因
2. 確認すべきログやコード箇所
3. 修正前に検証すべきこと
4. 誤った修正をしてしまうリスク
を整理してください。
原因が不明確なまま修正してしまうのが一番怖いので、「まず原因仮説を整理する」というブレーキをAIに持たせます。
例4：社内説明の目的を整理させる
「この内容を社内向けにまとめて」だと文章はできますが、社内共有で効くのは情報の網羅より目的の明確さです。
この内容を社内向けにまとめる前に、
まず読者に何を理解してもらうべきか整理してください。
目的が曖昧な場合は、より伝わりやすいゴールに修正してください。
そのうえで、
読んだ人が次に取るべき行動が明確になる文章にしてください。
何を伝えるかだけでなく、何のために伝えるかを先に確認させる、という使い方です。
Claude Codeで使うとき
Claude Codeはコードを変更できる分、いきなり実装させる前に方針の妥当性を確認させる意味が大きいです。
この実装方針が本当に適切かを先にレビューしてください。
より安全・保守しやすい設計がある場合は、
現在の依頼をそのまま実装せず、改善案を提示してください。
そのうえで、以下を実行してください。
1. 既存コードへの影響範囲を整理する
2. 実装方針を比較する
3. 最も安全な方針を選ぶ
4. 変更手順を小さなステップに分ける
5. テスト観点を提示する
6. リスクがある場合は実装前に止める
コードを書かせる前に、設計を疑わせる。Opus 4.8時代の安全な進め方として、自分はこれを基本にしています。
まとめ
| Tier | プロンプト例 | 使い方のレベル |
|---|---|---|
| Tier D | あなたは世界クラスの専門家です | 古い定型句に頼る |
| Tier C | 箇条書きで説明してください | 出力形式を整える |
| Tier B | メリット・デメリットを出してください | 判断材料を整理する |
| Tier A | 私の前提を疑ってください | 依頼内容をレビューさせる |
| Tier S | 勝ち筋を選んでください | AIを思考パートナーにする |
| Tier SS | ゴールを修正してから作業してください | 問題設定までAIに補助させる |
長い指示を書くことより、AIに何を判断させるかが効きます。前提を疑わせる、見落としを指摘させる、ゴールを補正させる。この3つを頼みに入れるだけで、AIの立ち位置は作業代行から相談相手に変わります。
最後に、自分が一番使い回している一文を置いておきます。
まず、私の依頼のゴールが適切か確認してください。
より良いゴールがある場合は、修正してから作業してください。
この一文は、必要なときに何度も使い回せます。Tier SSの考え方ごと、ストックしておかないともったいないです。少しでも参考になった方は、ぜひ保存しておいてください。