導入：Claude Codeに「速くして」だけでは遅いまま
「この画面が遅いので、Claude Codeで何とかなりませんか」。こんな相談を受けると、AIなら短い指示でもコードを出してくれそうに見えます。でも、パフォーマンス改善で一番危ないのが、この「何となく重い」のまま変更を始めることです。画面の描画なのか、APIの応答なのか、データベースの照会なのかによって、見る場所も対策もまったく違います。
僕も最初のころは、表示速度の改善を頼まれてから、怪しい箇所を片っ端から書き換えていました。フロントエンドの描画、SQL、キャッシュと幅広く手を付けた結果、差分は巨大なのに、体感速度はほとんど変わらないという失敗をしています。変更点多く、原因の切り分けもできず、レビューする側にも負担がかかりました。
そこで今は、Claude Codeに作業を投げる前に目的と制約を整理します。例えば、次のように伝えると会話が始めやすいです。
目的: 管理画面の初回表示を3秒以内にする
現状: 実データでは平均4.8秒、主にAPI応答で待っている
制約: 表示項目と権限制御は変えない。DB構成の大規模変更は避ける
依頼: まずボトルネックの仮説を3つ挙げ、必要な計測方法を提案する
重要なのは、いきなり「修正して」と頼まないことです。Claude Codeには、少し先で一緒に考えてくれる仲間として、仮説の整理や見落としの確認を任せます。その代わり、機密情報や本番環境の生データをそのまま渡さないこと、判断に必要な情報には何があるかを最初に確認することは忘れません。
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
最新ツール・トレンド情報をずんだもん×めたんが解説するYouTubeチャンネルを運営しています！
いいね、チャンネル登録してもらえると嬉しいです🙇♂️
ハジメル.dev: https://hajimeru-dev.vercel.app/
「ひとりで続けるのは難しい」「何から学べばいいか分からない」という方向けに、
プログラミングのマンツーマンレッスンサービス「ハジメル.dev」も運営しています。
未経験OK・オンライン完結・月額制/違約金なしなので、気軽に無料相談してみてください🙇♂️
海外テックニュースを追いたいけど、英語や情報量の多さで大変…という方向けに、
Hacker News の話題を日本語でサクッと追える「HackerNews 日本語まとめ & AI要約」
を個人開発しました！
技術トレンド収集に使ってもらえると嬉しいです🔥🙇♂️
→ HackerNews 日本語まとめ & AI要約: https://hn-matome-2ht.pages.dev/
「ニャンパイアサバイバー」というヴァンパイアサバイバーリスペクトのゲームを作成しました！
もしよろしければ遊んで頂けると嬉しいです😭
習い事教室の先生向けに、SNS 投稿・生徒募集・保護者通知の文章を AI で生成する Web サービス「おしらせAI」を個人開発しました。Next.js + Supabase + LLM で構成しており、無料で月 10 回まで試用できます。よければ触ってみてください。
→ おしらせAI: https://oshirase-ai.vercel.app/
言いたいことがうまく伝わらない…という方向けに、会話の言い方を添削する「伝え方ラボ」を開発中です。
場面を選んで自分の言葉で返すと、何が伝わっていないかの指摘と、そのまま使える言い換えが返ってきます。
ChatGPT に相談すると褒めから入って直すべきところが残りがちなので、指摘側に振り切りました。
現在は公開時にお知らせするメール登録のみ受付中です🙇♂️
→ 伝え方ラボ: https://tsutaekata-lab.pages.dev/
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
まずは計測し、Claude Codeに共有する範囲を絞る
パフォーマンス改善では、「速くなった気がする」ではなく、同じ条件で測った数字を基準にします。僕が最初に確認するのは、対象のURLや操作、データ件数、キャッシュの状態、ブラウザや端末、そして何回の平均を使うかです。これらが揃っていないと、前回はキャッシュ済みで今回は照会済みだった、という違いだけで結果が揺れてしまいます。
APIなら、次のように複数回測って中央値やばらつきを見ます。hyperfineが使えない環境では、curlを繰り返すだけでも構いません。
hyperfine --warmup 3 --runs 10 \
'curl -sS -o /dev/null -w "%{time_total}\n" \
"http://localhost:3000/api/reports"'
ブラウザの動作なら、開発者ツールのネットワーク一覧でAPI待ちを確認し、必要に応じてプロファイラも使います。ここで分かった「API応答が全体の8割を占める」「特定の照会で遅い」といった事実を、Claude Codeに渡します。僕自身、管理画面の表示改善でJavaScriptの処理を疑っていましたが、計測すると大半は1件ずつ実行されるSQL待ちでした。最初から計測できていれば、何日もフロントエンド側の最適化に費やさずに済みました。
プロジェクトにCLAUDE.mdを置き、目標や測定方法を共有しておくのも有効です。
# Performance
- 対象API: GET /api/reports
- 目標: p95 1.5秒以下
- 測定: 固定10万件のシードデータ、ウォームアップ3回
- 注意: 本番ログや個人情報をプロンプトへ貼らない
Claude Codeには、この情報から追加で必要な計測や、再現手順の抜けを質問できます。「どこから調べればいいか分からない」ときは、まず計測計画だけを作ってもらうのがおすすめです。
仮説を小さく切り、実装前にレビューさせる
計測結果を持ったら、次は原因の仮説を小さい単位に分解します。僕がよく使う指示は、「まだコードを変更せず、根拠順に仮説を並べ、それぞれを否定・確認する方法を示して」というものです。こうすると、Claude Codeがいきなり大規模な変更を提案するリスクを減らせます。
例えば、次のような照会はN+1問題、つまりデータ件数に比例して照会が増える状態かもしれません。
for (const user of users) {
user.orders = await orderRepository.findByUserId(user.id);
}
ユーザーが100件あれば照会が101回になる可能性があります。この場合、IDを一度に渡すよう変えるだけで大きく改善するかもしれません。
const userIds = users.map(({ id }) => id);
const orders = await orderRepository.findByUserIds(userIds);
ただし、修正コードを受け取った時点で完了とは考えません。実際に発行されるSQL、必要なインデックス、データがない場合の挙動、メモリ使用量、権限制御が維持されているかを確認します。Claude Codeに「この変更で壊れる可能性があるケースを挙げて」と頼むと、自分一人では見落としがちな条件を洗い出しやすくなります。
僕は今、まず小さなブランチを作り、1つの仮説に対する変更だけに留めます。効果が出なければ戻して次の仮説を試せるため、心理的にも作業的にも負担が軽くなります。仮説ごとの測定値と変更点を記録しておけば、「なぜこの修正を入れたか」も後から説明できます。性能改善は、たくさんのコードを書くことではなく、根拠のある変更を積み重ねることだと学びました。
失敗から学んだこと：キャッシュと非同期処理を同時にいじらない
性能改善で痛い目を受けたのは、キャッシュ導入と非同期処理の変更を同時に進めたときです。ローカルでは応答時間が大きく短縮でき、一気に成功したと思いました。ところが本番に近い環境で負荷をかけると、同じデータでも古い値が返ったり、一定時間だけ照会が集中したりしました。
当時の処理は、大まかには次のような構造でした。
const cached = await redis.get(key);
if (cached) return JSON.parse(cached);
const fresh = await loadReport();
await redis.set(key, JSON.stringify(fresh), "EX", 60);
return fresh;
キャッシュに値がなければ読み込み、保存して返します。一見問題ありませんが、値がない瞬間に同じ照会が複数入ると、複数の処理が同時に元データを読み込みます。さらに非同期の完了順やエラー時の挙動も変えていたため、遅さの原因と不具合の原因を区別できませんでした。
この経験から、まずキャッシュの有無だけを変えて測る、次に更新タイミングを変える、最後に並列処理へ変える、という順序を守るようにしています。各段階で速度だけでなく、値の新鮮さ、エラー率、データベース負荷も確認します。Claude Codeには実装前に「高負荷時に同じキーが同時に読まれた場合どうなるか」「障害時には何が起きるか」を確認してもらい、提案されたコードをそのまま信じず、境界条件を自分で追います。
戻しやすい小さな変更、機能フラグ、失敗時の旧処理への切替えを用意しておくことも大切です。「速くなった」だけでマージすると、別の不具合を生まないとは限りません。性能と信頼性を同時に守る方が、結果的に近道でした。
まとめ：Claude Codeを「一緒に考える相手」にする
Claude Codeをパフォーマンス改善で使うとき、僕が最も重視しているのは次の5点です。
- 「重い」を具体的な指標に置き換える
- 同じ条件で比較し、中央値だけでなくばらつきも見る
- 実装前に仮説を小さく分け、根拠を確認する
- 一度に変更する要素を一つにする
- 速度だけでなく、正確性、負荷、保守性を確認する
Claude Codeは、計測していない状態のボトルネックを当ててくれる魔法の道具ではありません。一方で、情報を与えれば、調査方針の整理、盲点の確認、比較用のスクリプト作成、変更後の確認項目の洗い出しを一緒に進めてくれます。自分が判断を放棄せず、数字と挙動を確認しながら使えば、かなり心強い仲間になります。
もし今、性能改善で何から始めればよいか迷っているなら、まずは対象操作を一つ選び、3回から10回測ってみるところから始めましょう。その結果をClaude Codeに渡し、「仮説を立てるだけで、まだコードは変えないで」と頼んでみるのもよい方法です。最初から完璧な改善をする必要はありません。測り、小さく試し、必要なら戻りながら進めれば、確実に前へ進めます。性能改善は一朝一夕では終わりませんが、一つずつ数字で確認できることは、駆け出しの自分にも十分できる開発の楽しみです。