はじめに
皆さんClaude Code使ってますか？
私はMaxプランを利用し始めて2か月目ですが、すでに手放せない存在になっています。
最近はObsidianとの連携やSkillsの活用が話題に上がる中、そういった知識を使いこなせていますか？
私は無理です。なぜなら、開発を優先したいから。
そもそも、こうした仕組みづくり——いわゆるハーネスエンジニアリング（AIの周りの足場を整える作業）は、やってみると本当に難しいし大変。沼にハマって、肝心の開発が進まないなんて本末転倒ですよね。
というわけで今回は、実体験をもとに「プロンプトに加えるだけ」で手軽にAIの性能を最大限引き出す方法をまとめました。難しいツールセットアップは不要、明日から即実践できるものだけを厳選しています。
テクニック一覧
★は5段階評価。難易度＝導入の手間（少ないほどお手軽）／期待効果＝効き目の大きさ（多いほど絶大）。
※筆者の主観評価のため、内容は悪しからず
掲載順は「①AIの思考のクセを直す → ②専門家ペルソナで武装する → ③開発を支える運用テク」という流れに並べています。上から順に試すのがおすすめです。
| # | テクニック | 難易度 | 期待効果 |
|---|---|---|---|
| 1 | AIに前提を疑わせる | ★☆☆☆☆ | ★★★★☆ |
| 2 | 「多角的・バイアスなし」で視野を広げる | ★☆☆☆☆ | ★★★☆☆ |
| 3 | 専門家ペルソナをサブエージェントに憑依させる | ★★★☆☆ | ★★★★☆ |
| 4 | サブエージェントを桜井政博に洗脳する | ★★☆☆☆ | ★★★☆☆ |
| 5 | Doxygenコメントでコードに記憶を埋め込む | ★★☆☆☆ | ★★★★☆ |
| 6 | CLAUDE.mdに「効くワード」を常駐させる | ★★☆☆☆ | ★★★☆☆ |
| 7 | 「トークン半減」の呪文で使用制限を回避する | ★★☆☆☆ | ★★★★☆ |
| 8 | メインセッションを汚さず長持ちさせる | ★★★★☆ | ★★★★☆ |
1. AIに前提を疑わせる
難易度：★☆☆☆☆ → 期待効果：★★★★☆
実は、最初に紹介するこれがコスパ最強です。
AIは素直すぎます。ユーザーの言葉を「正しい前提」として受け取り、間違った要求を、間違ったまま完璧に実装してしまうことがあります。
一番こわいのは「誤った思い込みのまま爆走される」こと。気づいたときには手戻りの山……トークンも時間も無駄になります。
対策：着手前に前提を吟味させる一言
私の前提や指示が誤っている可能性も考慮して、
まず要件の妥当性を批判的に検討してから着手して。
おかしい点や、より良い代替案があれば、実装前に指摘して。
なぜこれが効くのか
AIはデフォルトで「迎合的（ユーザーに同調しがち）」な傾向があります。
そのまま頼むと、こちらの言い間違いや筋の悪い設計にも「承知しました！」と従ってしまう。
「疑っていい」と明示的に許可を与えることで、AIが批判的検討モードに入ります。
これにより、実装前に前提のミスを潰せます。
使いどころ
- 特に効くのは：要件がふわっとしている設計初期、自分でも自信のない指示を出すとき
- 逆に前提が固まっているときは、余計な確認往復が増えることもあるので使い分けを
2. 「多角的・バイアスなし」で視野を広げる
難易度：★☆☆☆☆ → 期待効果：★★★☆☆
プロンプトに一言加えるだけで、AIの思考の広さと客観性が上がります。
なぜ「多角的に」と「バイアスなし」が効くのか
AIは文脈に引っ張られやすく、最初に提示された情報や直前の会話に影響されます。
「多角的に」という指示を入れると、単一視点でなく複数の角度から検討を促せます。
「バイアスがかからないように」と添えると、先入観を意識させた回答が得られます。
「サブエージェントで客観レビュー」と指示すると、同一会話の流れから切り離した独立評価が可能になります。
使えるフレーズ集
# 意見の幅を広げたいとき
多角的に10個意見を出して
# 先入観を排除したいとき
バイアスがかからないように意識して
# 客観的な評価が欲しいとき
レビューは必ずサブエージェントによる客観レビューを行うこと
# 賛否両論を整理したいとき
良い意見と悪い意見をそれぞれ10個言って
組み合わせ例
この設計案について、多角的に検討してください。
バイアスがかからないように意識して、良い点と悪い点をそれぞれ10個挙げてください。
その後、サブエージェントによる客観レビューを行ってください。
「数」を指定すると視野が広がる
地味に効くのが、「10個」と具体的な数を指定することです。
「意見を出して」とだけ頼むと、AIは無難な2〜3点でまとめてしまいがち。そこに数のノルマを課すと、枠を埋めようとして、普段なら省略する細かい観点や少数派の視点まで絞り出します。 これが「多角的」の正体です。物足りなければ「20個」に増やしてもいい。
💡 ただし「10個出して」は量が増えるだけのこともあります。本当に独立した視点が欲しいなら、視点ごとに別々のサブエージェントにレビューさせるのが本命です（上のフレーズ集にある「サブエージェントによる客観レビュー」がそれ）。
3. 専門家ペルソナをサブエージェントに憑依させる
難易度：★★★☆☆ → 期待効果：★★★★☆
「AIがなんか浅い答えを返してくる」と感じたことはありませんか？
ペルソナ（専門家の人格設定）を与えると、AIをその道のプロとして動かせます。
ただ「チャットでAIに役割を与える」だけなら誰でもやっています。キモは、メインが適切なペルソナを選んでサブエージェントに渡すこと。 これで「独立コンテキストの客観レビュー・メイン汚染なし・並列化」が手に入ります。
ペルソナプロンプトとは？
ペルソナとは、「特定の役割を持った人物の行動・思想・価値観をまとめた情報」のことです。
たとえばシニアプログラマーのペルソナであれば：
- コードを見たとき最初に何を確認するか（保守性？パフォーマンス？セキュリティ？）
- どんなトレードオフを重視するか
- コードレビューで絶対に指摘する観点は何か
……といった情報を文章でまとめたものです。
これをAIに渡すだけで、「その人物として考える」専門家AIが生まれます。
代表的なペルソナ例
| ペルソナ | 使いどころ | 何を見てもらうか |
|---|---|---|
| シニアプログラマー | コードレビュー全般 | 設計・可読性・パフォーマンス |
| テックリード | アーキテクチャ検討 | 技術選定・スケーラビリティ・負債リスク |
| UIUXデザイナー | 画面レビュー | 視認性・操作フロー・ユーザー体験 |
| コードレビュワー | PR前チェック | バグ・セキュリティ・保守性 |
| 桜井政博 | ゲーム品質評価 | 面白さ・リスクとリターン・プレイヤー視点（→ テク4） |
仕組み：メインが選び、サブエージェントが演じる
ここが本丸です。ペルソナをファイル化して、その存在をメインセッションに教えておくだけでOK。
あとはメインが「このタスクならこのペルソナだ」と自律的に選び、サブエージェントへ渡して実行させます。ユーザーが毎回プロンプトを貼り直す必要はありません。
やることはシンプルで、実質3ステップ。しかも一度用意すれば、あとはずっと使い回せます。
Step 1: ペルソナファイルを作る
# personas/senior-programmer.md
あなたはシニアプログラマーです。以下の設計哲学を批評軸に使ってください：
- コードの意図が名前と構造から読み取れるか（命名・責務分離）
- 変更に強い設計か（依存の向き・抽象化の適切さ）
- パフォーマンスのボトルネックになりうる箇所はどこか
- テスタビリティは確保されているか
レビュー形式：
1. 総評（一文）
2. 良い点 5件（具体的に）
3. 改善すべき点 5件（改善案つきで）
4. 最優先で直すべき1点
Step 2: CLAUDE.mdで存在を示す
## 利用可能なペルソナ
- シニアプログラマー: `personas/senior-programmer.md`
- UIUXデザイナー: `personas/uiux-designer.md`
- テックリード: `personas/tech-lead.md`
コードレビューや設計評価の際は、適切なペルソナをサブエージェントに渡してレビューさせること。
Step 3: あとはAIが自動で使う
「このコードをレビューして」と言うだけで、AIが適切なペルソナを選んでサブエージェントに渡してくれます。
ペルソナの作成もAIに丸投げできる
「ペルソナ、自分で書くの面倒じゃない？」と思ったあなた、ご安心を。
ペルソナの作成自体もAIに頼めます。
このプロジェクトのコードをレビューするための「シニアプログラマー」ペルソナを作成してください。
以下を含めること：
- このプロジェクトの技術スタック（Flutter/Dart）に特化した観点
- コードレビュー時に必ずチェックする項目リスト
- 指摘の伝え方（改善案つき）
- レビュー結果の出力フォーマット
personas/senior-programmer.md として保存してください。
一度作れば使い回せるので、最初の投資だけです。
よくみつけたね！でもここには何もないよ！
4. サブエージェントを桜井政博に洗脳する
難易度：★★☆☆☆ → 期待効果：★★★☆☆（ゲーム開発者限定）
ゲーム開発者向けの切り札、通称マサヒロプロンプトです。
ゲームUIやゲームデザインの評価を、任天堂の名ディレクター・桜井政博氏のペルソナで行わせます。
要は、前章のペルソナを「ゲーム評価特化」で作り込んだ一例ですね。
だから運用も前章とまったく同じ。 マサヒロを personas/masahiro-sakurai.md に保存しておき、メインセッションが「今はゲームUIのレビューだ」と判断したときに、サブエージェントとして召喚します。自分で全文を貼り直す必要はありません。
そして「サブエージェントとして走らせる」からこそ、次の飛び道具が成立します。
そのペルソナ本体すら、自分で書く必要はありません。テク3の通り、作成自体をAIに丸投げできます。 ポイントは「中身を指定する」のではなく「桜井氏の思想を調べさせて、詳しく再現させる」こと。下のプロンプトを投げれば、AIが本人の設計哲学をリサーチした上でペルソナを作り、ファイル保存までやってくれます。
マサヒロプロンプトの「作成プロンプト」（AIに調べさせて作らせる）
あなたはプロンプトエンジニアです。ゲームのUI・ゲームデザインを「桜井政博」として
レビューさせるためのペルソナを作成し、personas/masahiro-sakurai.md に保存してください。
# まず徹底的に調べること
桜井政博（『星のカービィ』『大乱闘スマッシュブラザーズ』等のディレクター）の
ゲームデザイン哲学を、できる限り深く調べて理解すること。手がかりの例：
- YouTube「桜井政博のゲーム作るには」で語られた設計論
- 週刊ファミ通の連載コラム、各種インタビュー、講演（GDC等）
- 彼が手がけた作品に共通する設計判断と、その背後にある意図
※Web検索が使えるなら積極的に使い、使えない場合は知識から最大限正確に引き出すこと。
※私（依頼者）の要約を鵜呑みにせず、一次情報に当たって自分で彼の思想を組み立てること。
# ペルソナに落とし込むこと
- 調べた彼の価値観・判断基準・思考の順序・口ぐせ・語り口を、「それっぽい模倣」でなく
本人の思想として詳しく再現すること。表面的な要約で終わらせない。
- 彼が「面白さの核」を何と捉え、何を嫌い（減点要素）、どんな順序でゲームを見るのか——
その批評軸を、調べた内容をもとに自分の言葉で言語化してペルソナに組み込むこと。
- 具体的な作品やUIに対して、鋭く具体的な批評ができるレベルまで作り込むこと。
# レビュー時の姿勢と出力フォーマット（ペルソナに必ず含める）
- 忖度せず、しかし必ず建設的に。一般論で逃げず、徹底的に具体的に。
- 出力は次の形式を厳守：
1. 総評（一言）
2. いいところ 10件（各項目、どの設計判断がなぜ良いか具体的に）
3. 批判 10件（各項目、何が問題か＋「どう直すべきか」の改善案を1つ）
4. 最優先で直すべき1点
- 桜井氏の語り口（理屈っぽくも明快、プレイヤー本位、ときに辛口）で、日本語で。
完成ファイルは、今後ゲームUIレビュー時にサブエージェントへ渡して使う前提で書くこと。
コツ
- 批判と良いところを10個ずつ、と数を指定するのがポイント。数を指定しないとAIは無難な数点でまとめてしまい、多角性が失われます（→ テク2と同じ理屈）
- UI改善・UX評価・ゲームバランス調整など幅広く使える
-
personas/masahiro-sakurai.mdとして保存しておけば、テク3の要領でいつでも呼び出せます
1000人のサブマサヒロを並列召喚する
サブエージェントは並列で何体でも立てられます。
つまり極端な話、1000体の桜井政博を一斉に走らせて、全観点を同時に洗うことすら理論上は可能です。
桜井政博ペルソナのサブエージェントを観点別に並列で立てて、
このゲーム画面を「操作感」「視認性」「テンポ」「達成感」…の軸で同時にレビューさせて。
最後に全レビューを統合し、最優先で直すべき点を1つにまとめて。
もちろんコストは跳ねますが、「1人の桜井に直列で全部聞く」より「観点ごとに分担させて並列で聞く」ほうが、抜け漏れが減り視点も独立します（→ テク2のバイアス排除とも噛み合う）。
全ての開発者に伝われ。
5. Doxygenコメントでコードに記憶を埋め込む
難易度：★★☆☆☆ → 期待効果：★★★★☆
AIにプログラミングを頼む上でいちばん重要と言ってもいいテクです。
巷の「メモリ保持テクニック」より、よっぽど精度の高いコンテキスト維持が実現できます。
Doxygenコメントとは？
Doxygenは、ソースコードに書かれた特定形式のコメントを読み取ってドキュメントを生成するツールです。クラスやメソッドの直前に、/// や /** */ で「何をするものか・引数・戻り値」を構造化して書きます：
/// 素数判定を行う
///
/// ミラー・ラビン法とBPSWテストを組み合わせた確率的素数判定。
/// [n] が素数であれば true、合成数であれば false を返す。
/// [rounds] はミラー・ラビンの試行回数（デフォルト: 20）。
bool isProbablePrime(BigInt n, {int rounds = 20}) {
...
}
ポイントは、ただのメモ書きではなく**「役割・入力・出力・前提」を決まった型で残す**こと。@brief（概要）・@param（引数）・@return（戻り値）といったタグを使い、人間にもツールにも機械的に読める形で意図を明文化します。
普通の // ここでループを回す のような行内コメントが「実装の途中経過の補足」なのに対し、Doxygenコメントは**「このメソッドをどう使うか」という契約（インターフェース仕様）**を書くもの。中身を一行も読まずに、使い方と意図が分かる——この性質がそのまま、AIにとっての強力なメモになります。
たとえば上の例なら、AIは isProbablePrime の実装（ミラー・ラビンのループや剰余計算）を読まなくても、「BigIntを受け取り確率的素数判定の真偽を返す／roundsで精度を調整できる」と即座に把握できます。実装が数百行あっても、読むのは数行のコメントだけ。これが積み重なると、コードベース全体が「AIが高速に読めるインデックス付きの本」になります。
そもそもDoxygenの「本来の使い方」は？
Doxygenはもともと、ソースコードから詳細設計書を自動生成するための専用ツールです。上記の形式でコメントを書いておき、doxygen コマンドを実行すると——
- クラス／メソッドのリファレンス（HTML・PDF など）
- クラス図・継承図
- 関数の呼び出し関係グラフ（コールグラフ）
を自動で吐き出してくれます。「コメントを書く＝設計書が勝手に出来上がる」仕組みで、C++やJavaの大規模プロジェクトで長年使われてきました。
つまりこのテクは、人間向けに確立された"設計書生成フォーマット"を、AI向けの常時参照メモに転用するもの。もともと「読み手に意図を正確に伝える」ために磨かれた形式だからこそ、AIにとっても解釈しやすいわけです。
実は、AIはコードを全部読んでいない（こともある）
ここが核心です。
AIは毎回すべてのコードを精読しているわけではありません。トークン節約のため、関数の中身を開かず、シグネチャやコメントだけ見て判断することがよくあります。
このとき、メソッドにDoxygenコメントが付いていれば——
中身を読まなくても「何をする関数か」が一発で分かるわけです。
memory.mdやCLAUDE.mdはプロジェクトの概要しか書けませんが、Doxygenコメントは**個々のメソッドの「なぜそう実装したか」**をコードに直接刻めます。
- 新しいセッションでもコードを読めばメソッドの意図が分かる
- AIが長い実装を読み直さなくてもコメントで文脈を補完できる
- 人間が読んでも分かりやすく、レビューや引き継ぎが楽
（小声）コメントを英語で書くと、もっとトークンが減る
ここだけの話、Doxygenコメントは英語で書かせるとトークンをさらに節約できます。
AIにとって英語は日本語よりトークン効率が良いので、「AIが何度も読み返すコメント」を英語にしておくと、消費トークンの削減にもつながります（地味ですが、塵も積もれば）。
ただしこれは、生成コードを自分でガッツリ読まない人向けの裏技です。英語コメントは人間（特に日本語話者）には読みづらくなるので、コードはAIに任せきり・自分は設計と検証に専念するスタイルなら丸ごとお得。逆にコメントを自分で読み込みたい人は、無理せず日本語のままでOKです。
CLAUDE.mdへの記載例
## コーディング規則
実装する際は必ずDoxygen形式のコメントを付けること（英語推奨）。
各クラス・メソッドに：
- 何をするものか（@brief）
- パラメータの説明（@param）
- 戻り値の説明（@return）
- 特記事項があれば（@note）
を記載すること。
CLAUDE.mdに一度書いておけば、毎回指示しなくても全実装にコメントが付くようになります。
6. CLAUDE.mdに「効くワード」を常駐させる
難易度：★★☆☆☆ → 期待効果：★★★☆☆
ここまでのテクを凝縮した、コピペで使えるワード集です。
CLAUDE.mdに書いておけば、毎回指示しなくても効きます。
## AIへの行動指針
- 私の前提が誤っている可能性も考慮し、まず要件の妥当性を吟味してから着手する
- 思考は多角的に、バイアスが起きないように意識する
- レビューは必ずサブエージェントによる客観レビューを行うこと
- 計画から検討し、ひとつずつ丁寧に進めること
- 実装には必ずDoxygen形式のコメントを付けること（英語推奨）
⚠️ ただし盛り込みすぎ注意。CLAUDE.mdが肥大化すると一つひとつの指示が薄まり、かえって効かなくなります。本当に効くものだけを厳選しましょう。
そして大前提として、「絶対に守らせたい」ことは、その場で直接指示するのが最強です。CLAUDE.mdは“常に薄く効かせる”ための仕掛けであって、確実性では都度の直接指示にかないません。常駐ワードはあくまで底上げ、ここぞの一手は直接プロンプトで——と使い分けましょう。
7. 「トークン半減」の呪文で使用制限を回避する
難易度：★★☆☆☆ → 期待効果：★★★★☆
AI開発者にとって、最大の敵は何か。バグでも納期でもありません。使用量の上限です。
ノってきたまさにその瞬間に突きつけられる「制限に達しました。しばらくお待ちください」——この強制お預けタイムほど、開発の勢いを根こそぎ奪うものはありません。
ここでトークンを節約すれば、同じ上限内でこなせる仕事量が増え、制限に当たりにくくなります。
その第一歩がこの呪文：
「出力を変えずにトークンを半減させる方法でタスクを進めて」
この一文を添えるだけで、AIが無駄な冗長性を自動的に削ります。
「冗長性を削る」とは具体的に？
- くどい前置きや相づち、同じ説明の繰り返しを減らす
- 思考（考えている途中の出力）をだらだら長くしない
- 不要な確認・再要約の往復を省く
コツは**「出力＝成果物の質は変えずに」と必ず添える**こと。これで、削っていいムダだけを削ってくれます。
あわせ技：思考は英語、出力は日本語
冗長性カットとは別の切り口として、思考する言語を切り替える手もあります。
Claudeは英語で考えるほうがトークン効率が良いので、内部の推論だけ英語に寄せると、それだけで消費が減ります。
サブエージェントも含めて、最終出力以外は英語で思考して、日本語で出力してください。
- 内部の推論ステップ → 英語（短い）
- ユーザーへの最終回答 → 日本語（読みやすい）
成果物は日本語のままなので、読みやすさは犠牲になりません。
サブエージェントのモデル選定が、効果の本体
「一言で半減」はやや盛った表現で、本当に効くのはモデルの使い分けです。
重いタスクをぜんぶ最上位モデルに投げていると、消費が膨らんであっという間に制限に到達します。用途に対して過剰なモデルを使わないだけで、減りの速さが段違いです。
| 用途 | モデル | 狙い |
|---|---|---|
| 単純な検索・探索 | Haiku | 軽い・速い。枠をほとんど食わない |
| 設計・コードレビュー | Sonnet | バランス型の主力 |
| アーキテクチャ判断・難しい正しさの検証 | Opus | ここぞの場面に温存する |
CLAUDE.mdへの記載例
## 使用量の節約
- 思考は英語、ユーザー向け出力は日本語
- 出力を変えずにトークンを半減させる方法でタスクを進めること
- サブエージェントのモデルは目的に応じて選定：
- 探索/検索 → haiku
- 設計/レビュー → sonnet
- 難しい正しさの判断のみ → opus
8. メインセッションを汚さず長持ちさせる
難易度：★★★★☆ → 期待効果：★★★★☆
最難関にして、最大の果実。これを体得するとセッションの寿命が体感2〜3倍になります。
claude-memのような外部メモリも優秀ですが、それより先にやるべきことが2つあります。
① コードそのものにコンテキストを埋め込む（→ テク5）
外部メモリに頼らず、コードを読めば文脈が分かる状態にしておくのが最強です。
新しいセッションでもコードを開けばすぐ作業を再開できます。
② メインセッションのコンテキスト汚染を防ぐ
メインセッションでコーディングをさせないのが肝です。
コーディングやファイル編集などの「雑用」をメインセッションで行うと：
- コンテキストウィンドウが実装の詳細で埋まる
- 重要な設計判断や会話履歴が圧縮・消えやすくなる
解決策：コーディングはサブエージェントに委譲する
# メインセッション（設計・指示・検証・コミット）
「この機能を実装して」→ 指示するだけ
# サブエージェント（コーディング・ファイル編集）
実際のEdit / Write / 探索はすべてここで処理
メインセッションは設計・指示・検証・コミットに専念。
これで重要な文脈が長持ちし、長丁場の開発でもAIの応答品質が落ちにくくなります。
💡 このテクは難易度高めですが、テク3（ペルソナ）・テク5（Doxygen）を先に押さえておくと自然に移行できます。記事のクライマックスにふさわしい、いわばゲームチェンジャーです。
まとめ
| # | テクニック | 難易度 | 期待効果 |
|---|---|---|---|
| 1 | AIに「まず前提を疑え」と言わせる | ★☆☆☆☆ | ★★★★☆ |
| 2 | 「多角的に・バイアスなしで」で視野を広げる | ★☆☆☆☆ | ★★★☆☆ |
| 3 | 専門家ペルソナをサブエージェントに憑依させる | ★★★☆☆ | ★★★★☆ |
| 4 | サブエージェントを桜井政博に洗脳する | ★★☆☆☆ | ★★★☆☆ |
| 5 | Doxygenコメントでコードに記憶を埋め込む | ★★☆☆☆ | ★★★★☆ |
| 6 | CLAUDE.mdに「効くワード」を常駐させる | ★★☆☆☆ | ★★★☆☆ |
| 7 | 「トークン半減」の呪文で使用制限を回避する | ★★☆☆☆ | ★★★★☆ |
| 8 | メインセッションを汚さず長持ちさせる | ★★★★☆ | ★★★★☆ |
どれも「プロンプトに一言追加」「CLAUDE.mdに書いておく」レベルで実践できます。
まずは**テク1（前提を疑わせる）**から試してみてください。コピペ一行で、AIの暴走が目に見えて減ります。
そして特にDoxygenコメントとセッション長持ちは、使い始めてから開発体験が一段変わりました。ぜひ。
宣伝
Xアカウント：@mryocode123
普段はこんなものを作っています：
- コピペを題材にしたインクリメンタルゲーム
- なろう小説をマッチングアプリ式に探索できるアプリ
- 素数ガチャ（超大桁の素数をガチャで引いて、新発見かどうかを判定する謎アプリ）
リリースしたら、ぜひ遊んでください！
開発の進捗はXで発信しているので、よかったらフォローしてもらえると嬉しいです。
Qiitaもフォローお願いします
このQiitaでは、今後も実体験にもとづいた開発者のリアルな情報を発信していく予定です。
今回のような「実際に使って効いたテクニック」を中心に、個人開発での生きた知見をシェアしていきます。
役に立ったら、フォローやこの記事にいいねしてもらえると次の記事の励みになります！