実験マインドセット

問題：毎セッション同じプロンプトパターンを使い続けている。それが最善かどうかわからないし、何時間もサイレントにロスしているかもしれない。

クイックウィン：今すぐこの実験を1つ実行して、プロンプトスタイルがClaudeの出力をどう変えるか確認してみよう：

Prompt A: "Fix the bug in auth.ts"
Prompt B: "Let's work through auth.ts together. What might be wrong?"
Prompt C: "Review auth.ts like a senior engineer. List every issue you find."

3つの結果を比較してみる。協調型バージョンはたいていより深い分析を生み出し、直接型バージョンが見逃すエッジケースも捕捉する。それが実験ループの威力だ。

実験1：プロンプトスタイルの影響

同じタスクでも、フレーミングの仕方によって出力が変わる。どんなデバッグタスクでも、次の3つのスタイルを試してみよう：

Style 1 (Command): "Fix the bug in login.ts"
Style 2 (Teaching): "Walk me through login.ts and help me find what's wrong"
Style 3 (Review): "Act as a code reviewer. Analyze login.ts for bugs, security issues, and edge cases."

わかること：スタイル3（レビューモード）は、作業を素早い修正実行ではなく分析としてフレーミングするため、より多くの問題を表面化させる傾向がある。

これが実際のパターンだ。明確なnullチェックのバグとレートリミッターの微妙なタイミング欠陥を持つログインハンドラーに3つのスタイルをすべて実行してみる。スタイル1（コマンド）はnullチェックにパッチを当てて終わる。スタイル2（ティーチング）はnullチェックにパッチを当てて理由を説明するが、タイミング問題は見逃す。スタイル3（レビュー）はnullチェック、タイミングの脆弱性を捕捉し、内部状態をクライアントに漏らすエラーメッセージまでフラグを立てる。

このパターンはタスクの種類全体にわたって成立するが、ギャップの大きさは異なる。セキュリティに敏感なコードでは、レビューモードが明らかにより多くを捕捉する。シンプルなUIバグでは、ギャップは縮まりコマンドスタイルで十分だ。リファクタリングでは、ティーチングモードがClaudeに変更のたびに説明を強制するため、最もクリーンな結果を生み出すことが多い。

プロジェクト内でどのタスクタイプにどのスタイルが勝つかをログに記録しよう。数セッション後には独自のルックアップテーブルができあがる：セキュリティ作業はレビューモード、シンプルな修正はコマンドモード、リファクタリングはティーチングモード。

実験2：ファイルコンテキストの影響

Claudeのコード品質は、コンテキストとして提供するファイルによって変わる。自分で試してみよう：

Experiment A: "Refactor errors.ts to use a cleaner pattern"
Experiment B: "Refactor errors.ts. Reference utils/errors.ts and AuthController.ts for the existing pattern."

2番目のバージョンは既存のパターンにフィットしたリファクタリングを生み出す。コンテキストがなければ、Claudeはコードベースと競合するかもしれないパターンを発明してしまう。

カスタムエラー階層を持つ実際のプロジェクトで試してみよう。実験Aでは、Claudeはジェネリックなtryブロックと new Error() 呼び出しを書く。クリーンなコードだが、すでにリポジトリにある AppError、ValidationError、NotFoundError クラスを無視する。リファクタリングされたファイルは型の不一致でコードの残りの部分とコンパイルさえできない。

実験Bでは、Claudeは utils/errors.ts でエラークラスを見つけ、AuthController.ts がすでにそれらをどう使っているかを読み、既存のパターンに合ったリファクタリングを生み出す。同じタスク、同じモデル、同じセッション。違いはファイル参照が3つ増えただけだ。

本当の教訓は「Claudeにファイルをたくさん渡す」よりも深い。スイートスポットがある。2〜4つの密接に関連するファイルを含めると出力品質が一貫して向上する。6〜7ファイルを超えると、Claudeが多くのパターンに注意を分散させるため効果が薄れる。型定義ファイルと欲しいパターンをすでに実装している1ファイルから始めよう。

実験3：プランニングモード対直接実行

プランニングモード（Shift+Tabを2回）はClaudeの問題へのアプローチを変える。この比較を実行しよう：

Direct: "Add user permissions to the admin dashboard"
Planning: [Shift+Tab twice] "Add user permissions to the admin dashboard"

プランニングモードでは、Claudeはコードベースを読んでから、1つのファイルにも触れる前にオプションを提示する。アプローチをレビューし、早期に問題を捕捉し、進む道を選べる。

マルチファイル機能でギャップがすぐに現れる。認証ミドルウェア、ダッシュボードルート、フロントエンドコンポーネントにまたがるパーミッションシステムでこの実験を実行してみよう。直接実行はすぐにミドルウェアに飛び込みコーディングを始める。既存のユーザーモデルと競合するロール構造について仮定を立て、変更の半分を元に戻さなければならない。

プランニングモードは、対照的に、コードを書く前に3つのアーキテクチャオプションを提示する。1つのオプションは既存のロール列挙型を使う。別のオプションはより細かい粒度のためにパーミッションテーブルを提案する。3番目はハイブリッドを提案する。オプション1を選ぶと、実装は最初のファイルからコードベースに揃う。

閾値の位置：3ファイル以上に触れる複雑な機能はほぼ常にプランニングモードから恩恵を受ける。シンプルな修正（単一ファイル、明白な変更）は不要だ。損益分岐点は2ファイル程度にある。2ファイルでは、プランニングモードは約30秒のオーバーヘッドを追加するが、バックトラックを防ぐ。それ以下では、形式のための形式になる。

実験4：CLAUDE.mdの設定

CLAUDE.mdファイルはClaudeの動作を直接形成する。異なる設定でテストしよう：

Configuration A: (empty CLAUDE.md)
Configuration B:
  - Always ask before making changes outside the current feature directory
  - Use conventional commits
  - Prefer small, focused changes over large refactors

それぞれで同じタスクを実行して比較する：

• Claudeはいくつの確認質問をするか？
• プロジェクトのパターンに従うか？
• コミットは適切にスコープされているか？

設定Aでは、Claudeはすべてのディレクトリをオープンな場所として扱う。ダッシュボード機能を追加するよう依頼すると、データベーススキーマを修正し、APIルートを更新し、デプロイ設定を一発で変更する。質問なし。1つの巨大なコミット。

設定Bでは、同じリクエストが確認質問を引き起こす：「ダッシュボード機能には新しいAPIエンドポイントが必要です。src/api/ に作成しますか、それとも既存の routes.ts を修正しますか？」結果の作業は、各レイヤーのファイルだけに触れる3つの焦点を絞ったコミットとして届く。

CLAUDE.mdはドキュメントではない。オペレーティングシステムだ。そこに書いた指示がClaudeのすべての判断を形成する。同じタスクに異なる指示を実行して出力の変化を観察しよう。CLAUDE.mdの小さな変更が行動に驚くほど大きな変化をもたらす。ファイルタイプごとのClaudeの動作に対するより細かい制御については、ルールディレクトリガイドを参照しよう。

実験5：コンテキストウィンドウのプレッシャー

これは静かに重要だ。Claudeの出力品質はコンテキストプレッシャー下で、告知なしに低下する。このテストを実行しよう：

新鮮なセッションを開始して、適度に複雑な機能を構築するようClaudeに依頼する（3〜4ファイルに触れるもの）。品質に注目する。次に、しばらく実行していて蓄積されたコンテキストがある既存のセッションで、全く同じ機能を依頼する。

新鮮なセッションは通常、より良いエラーハンドリングでクリーンなコードを生み出す。ロードされたセッションは近道を切る：短い変数名、少ないエッジケースチェック、時にはテストをスキップする。Claudeが良いコードの書き方を忘れたのではない。モデルが蓄積されたコンテキスト全体に注意を分散させ、現在のタスクのための余地を少なくするのだ。

実践的な教訓：複雑なタスクの前に /compact を積極的に使おう。2ファイル以上に触れる機能の前に /compact を実行すると、品質の違いが明確にわかる。一部の開発者は完全に新鮮なスタートのために /clear を好むが、会話履歴を失う。/compact コマンドは以前のコンテキストを捨てずに要約することで、その中間を取る。

自分の実験ログを作る

学んだことを記録するシンプルなトラッキングファイルを作ろう：

# Claude Code Experiments

## Prompt Style
- Review mode: best for security and auth code
- Command mode: best for quick UI fixes
- Teaching mode: best for refactors

## Planning Mode
- Use for 3+ files
- Skip for single-file changes

このログが個人最適化ガイドになる。1ヶ月後には、コードベースで自分のパターンで実際に機能するもののデータセットができあがる。正しいアプローチはプロジェクト、言語、作業の種類によって変わるので、それはどんな一般的なアドバイスよりも価値がある。

具体性が大切だ。「レビューモードの方が良い」は役立たない。「レビューモードは認証コードのセキュリティ問題を2〜3倍多く捕捉する」は毎セッション行動できる何かだ。

次に試す実験

もっとテストする準備ができたら、次を試してみよう：

1. コンテキスト管理：60%対90%のコンテキスト使用量では何が起きるか？
2. オートプランニング：自動化されたプランニングは手動モード切り替えを上回るか？
3. モデル選択：異なるモデルは同じ複雑なタスクをどう扱うか？
4. ディープシンキング：拡張思考はより良いアーキテクチャの判断を生み出すか？

推測をやめよう。実験を実行しよう。結果を記録しよう。反復しよう。

毎セッションが自分を速くする何かを見つけるチャンスだ。体系的に実験する開発者は最初の直感に固執する人を追い越す。すべての回避策は名付けられるのを待っているパターンだ。すべての名付けられたパターンはClaudeが再利用できるスキルだ。

これが実際の「システム進化マインドセット」の意味だ。トップ開発者とその他を分ける5つのClaude Codeベストプラクティスの1つだ。