スピードの最適化

問題：すべてのリクエストが処理待ちの状態になり、応答が戻るまで時間がかかる。数秒で返ってくるべき応答が、のろのろと戻ってくる。

即効策：より軽量なモデルに切り替える。セッション中に /model haiku と入力すれば、次の応答はより早く届く。Haikuは構文に関する質問、簡単な説明、小規模なコード生成に対応している。

「スピード乗数」アプローチ

待ち時間のほとんどは、モデルが遅いせいではない。セッションの設定が間違っているのだ。返信がどれほど早く届くかは、すでに制御している3つの要素で決まる。どのモデルを選んだか、コンテキストの規模はどれくらいか、そしてプロンプトがどれだけ的確か、だ。

素早い応答はフロー状態を維持させる。遅い応答はそこから追い出す。

肥大化したコンテキスト：ターンを重ねるごとに、Claudeが処理しなければならないトークンが積み上がる。長いセッションでは履歴が蓄積され、返信ごとに負荷が増大する。

モデルの不適合：一行の質問にソネットを返すのは、近所の店までトラックで行くようなものだ。エンジンと仕事を合わせることだ。

曖昧なプロンプト：「このコードを手伝って」では推測を強いられる。求めていることを具体的に書き出せば、回答はより早く返ってくる。

セッション中にスラッシュコマンドを使って、タスクの複雑さにモデルを合わせる：

/model haiku    # Quick questions, syntax help, simple edits
/model sonnet   # Complex refactoring, architecture decisions

簡単な作業にはHaikuに切り替える。推論が必要な場合は元に戻す。再起動は不要だ。

応答を高速化するためにコンテキストをスリムに保つ：

/compact        # Compress conversation history when it grows large
/clear          # Start fresh when switching to unrelated tasks

返信が遅れ始めたらすぐに/compactを活用する。重要な情報を保持しつつ履歴を要約にまとめるため、ターンごとのトークン負荷が軽減される。

最も速い最適化には、コマンドは一切不要だ。ただ、より明確なプロンプトが必要だ：

遅い：「この関数を修正して」速い：「handleSubmit内のuserパラメータにnullチェックを追加して」

遅い：「データベースの件を手伝って」　速い：「createdAt順（降順）で、投稿付きのユーザーを取得するPrismaクエリを書いて」

明確なプロンプトは、「え、どういう意味？」というやり取りをなくす。それだけで、やり取り全体の時間が半分になることもよくある。

並列セッション：タスクが干渉しない場合は、2つのターミナルを起動する。一方にフロントエンド、もう一方にバックエンドを割り当てる。

関連タスクのバッチ処理：1つのプロンプトで3つの仕事を同時にこなせる：

"In the UserProfile component:
1. Add loading state
2. Handle the error case
3. Add the avatar upload button"

CLAUDE.mdパターン：繰り返し使うプロジェクトの規約をCLAUDE.mdに記述する。Claudeが自動的にファイルを読み込むため、同じルールを何度も説明する必要がなくなる。

シェルエイリアス：一般的なワークフローのショートカットを作成する：

alias cc="claude"
alias cch="claude --model haiku"

速度を最適化すれば、同時にコストも削減できる。応答が速くなることは通常、以下のことを意味する：

早い段階でこれらの習慣を定着させよ。遅い設定との差はますます広がり続ける。

フィードバックループの短縮：デバッグはレイテンシに左右される。問題に直面した時点で、1秒でも短縮できればその効果は累積する。

探索フェーズ：異なる角度から試しているか？低コストの応答があれば、より大胆になれる。アイデアは2つではなく5つだ。

コードレビュー：差分の確認や説明を求める際、やり取りが読み進めるペースに追いついている時が最も効果的だ。

コンパクションを怠る：コンテキストが肥大化し、応答が遅くなるまで放置する。限界に達する前に /compact を実行せよ。

何でもソネット：Haikuが処理を終えたジョブで、より重いモデルを実行しても結果は同じだ。

直列思考：次のタスクを始める前に一つの回答を待ってしまう。実際には、並行して2つ目のセッションを実行できる。

曖昧な要求：要件を最初から明確に述べず、Claudeに推測させる。

チューニングが成功したかどうかの判断基準：