「動いているけど遅い」という状態のコードは、バグほど緊急性がないため、後回しになりやすい。エラーが出ているわけではないから、ユーザーからのクレームが来るまで放置してしまうこともある。でも、処理に10秒かかっているAPIが1秒になれば、ユーザー体験は根本的に変わる。
私がCodexをパフォーマンス改善に使い始めたのは、バッチ処理の実行時間が問題になったときだ。毎日夜間に動く処理が、データ量の増加とともに3時間かかるようになっていた。どこがボトルネックなのかは何となく分かっていたが、「どう直すか」が分からなかった。
試しにコードをCodexに渡して「このコードのパフォーマンスの問題点を指摘してください」と頼んでみた。返ってきた内容には、自分が気づいていた箇所もあったが、全く意識していなかった部分への指摘もあった。
この記事では、Codexをパフォーマンス改善に使った実際の体験と、具体的な使い方、そして「ここには注意が必要」と学んだことを書く。
結論から言うと、Codexはパフォーマンス改善の「何を直すか」を見つける段階で力を発揮するが、「どれを優先して直すか」はプロファイリングの結果と自分の判断が必要だ。この順番を守ることが、効果的な最適化の鍵になる。
「動いているけど遅い」という問題の難しさ
パフォーマンス改善がバグ修正と違うのは、「どこを直せばよいか」が見えにくいことだ。
ボトルネックを見つけることが最初の壁
コードが遅い原因は、一箇所に集中していることが多い。「ボトルネック」と呼ばれるこの箇所を特定できれば、そこを改善するだけで全体の速度が大幅に改善されることがある。逆に、ボトルネックではない部分をいくら最適化しても、全体の速度はほとんど変わらない。
問題は、「どこがボトルネックか」が見た目だけでは分からないことだ。コードを読んで「ここが重そう」と感じる箇所は、実際にはボトルネックではないことがよくある。逆に、一見シンプルな処理がデータ量の増加で急激に遅くなることもある。直感に頼ったパフォーマンス改善は、的外れな最適化につながりやすい。
最適化は「正しさ」より「バランス」が難しい
バグ修正は「直れば正解」という明確な基準がある。一方、パフォーマンス改善は「どこまでやれば十分か」の判断が必要だ。
速さを追求すると、コードが読みにくくなることが多い。シンプルで読みやすいコードより、ビット演算や複雑なアルゴリズムを使ったコードの方が速いことがある。しかし読みにくいコードは保守コストが上がり、将来のバグの原因になることもある。
この「速さと読みやすさのトレードオフ」を判断するのは人間の仕事だ。Codexは「速くなる方法」を提案してくれるが、「そのトレードオフを受け入れるかどうか」は自分で決める必要がある。
Codexにパフォーマンス改善を頼む方法
コードとボトルネックの情報を渡す
Codexにパフォーマンス改善を依頼するとき、コードだけでなく「どういう状況で遅くなっているか」を一緒に渡すことで精度が上がる。
効果的に渡す情報：
- 対象のコード（問題のある箇所とその周辺）
- データ量・規模の情報（「現在10万件のレコードで実行している」）
- 実行時間の計測結果があれば（「この処理に約30秒かかっている」）
- プロファイリングツールの結果があれば（どの関数に時間がかかっているか）
- 使っている言語・フレームワーク・DBのバージョン
これらを揃えて依頼することで、Codexが「この規模のデータでこの処理をするならN+1問題が発生しやすい」「この部分はバッチ処理ではなく非同期処理に変えると改善できる」のような、具体的な提案を返してくれやすくなる。
どんな改善提案が返ってくるか
Codexが返してくれる改善提案は、大きく以下のカテゴリに分かれる。
- アルゴリズムの改善：O(n²)からO(n log n)への変更など、計算量の削減
- データ構造の最適化：リストの代わりにセットを使う、辞書の活用など
- データベースクエリの改善：N+1問題の解消、インデックスの追加提案、クエリの書き直し
- キャッシュの導入：同じ計算を繰り返している箇所へのキャッシュ適用
- 並列・非同期処理の導入：独立した処理を並列で実行する提案
- 不要な処理の削除：ループ内で毎回計算しているが、ループ外に出せる処理
これらの提案は、「なぜそれが遅さの原因か」の説明と一緒に返ってくることが多い。提案の理由を理解することで、同じ種類の問題を次に自分で見つける力が身についていく。
実際にCodexとパフォーマンス改善を進めた
SQLクエリの最適化
最初に効果を実感した場面は、SQLクエリの最適化だった。夜間バッチで大量のレコードを取得して処理するコードがあり、データ量の増加とともに実行時間が伸びていた。
コードをCodexに渡したところ、「このコードはループの中でDBへのクエリを発行しているため、N+1問題が発生しています」という指摘が返ってきた。N+1問題とは、1回のメイン処理に対してN回の追加クエリが発生する問題で、データ量が増えるにつれて実行時間が線形以上に増加する。
Codexはこの問題の修正案として、「ループ内のクエリをJOINを使った1回のクエリにまとめる」コードを提示してくれた。修正を適用したところ、10万件のデータに対して3時間かかっていた処理が20分に短縮された。
N+1問題は「分かっていれば避けられる」問題だが、コードを書いているときは気づきにくい。特に、ORMを使っているときにこの問題が生まれやすい。Codexがコードを「外からの目」で見てくれることで、自分では見えていなかった問題が浮かび上がった。
Pythonコードのボトルネック特定
別の場面では、Pythonのデータ処理コードが遅いという問題をCodexに持ち込んだ。処理対象のリストを逐一操作しているコードで、件数が増えるにつれて実行時間が急増していた。
Codexに渡したところ、「リスト内でのin検索はO(n)の計算量がかかるため、件数が増えると急激に遅くなります。setを使うとO(1)に改善できます」という指摘が返ってきた。さらに、「このループ内で毎回同じ計算をしているため、ループの外に出せます」という別の指摘もあった。
Codexはデータ構造の選択ミスによるパフォーマンス問題を見つけることが得意で、「リストをセットに変える」という比較的シンプルな修正で大きな改善が得られることをCodexを通じて何度も学んだ。
Codexの提案で気づいたこと
「読みやすさ」と「速さ」のトレードオフ
Codexが提案する最適化の中には、「速くなるが読みにくくなる」ものが含まれることがある。ビット演算を使った整数の高速化、複雑なリスト内包表記、キャッシュを使った状態管理の追加——これらは速度向上には有効だが、コードの複雑さを上げる。
Codexは「速くなる方法」を提案するが、「そのコードを6ヶ月後に読んだとき、チームの誰かが理解できるか」は提案の中に含まれない。この判断は自分がしなければならない。
実際に私が選んだのは、「速くなるが読みやすさを保てる改善」を優先し、「速くなるが複雑になる改善」はコメントを添えた上で採用するか見送るか判断する、というアプローチだった。
最適化の前に測定が必要という気づき
Codexを使ったパフォーマンス改善を通じて最も大きな気づきだったのは、「最適化の前に測定をしていなかった」という反省だ。
Codexの提案を適用して速くなったとき、「どれだけ速くなったか」を正確に測定していなければ、改善の効果が分からない。また、複数の改善を同時に適用すると、どの改善が効いたかも分からなくなる。
パフォーマンス改善は「測定→特定→改善→再測定」のサイクルで進めることが原則で、Codexはその「特定」フェーズを助けてくれるツールだ。最初に「改善前の実行時間を測定する」という一手間を入れることで、Codexの提案の効果を客観的に評価できるようになった。
Codexに任せすぎないために
プロファイリングの結果を先に取得する
Codexにコードを渡す前に、プロファイリングツールを使ってどこに時間がかかっているかを測定することを強く推奨する。Pythonならcprofileやline_profiler、Node.jsならV8プロファイラ、データベースならEXPLAIN文が使える。
プロファイリングの結果とコードをセットでCodexに渡すことで、「実際にボトルネックになっている箇所」への具体的な改善提案が返ってくる。プロファイリングなしで渡した場合、Codexは「ボトルネックに見える箇所」を指摘するが、それが実際のボトルネックではない可能性がある。
プロファイリングをせずにCodexの提案を採用すると、実際のボトルネックではない部分を最適化して「気持ちは改善されたが実行時間はほぼ変わらなかった」という結果になることがある。
最適化後のテストの重要性
パフォーマンス改善は、動作を変えない変更のはずだが、最適化によって意図せず動作が変わることがある。特にアルゴリズムの変更やデータ構造の変更は、エッジケースで異なる結果を返す可能性がある。
Codexが提案した最適化を適用した後は、必ず既存のテストを実行し、動作が変わっていないことを確認する。テストがない場合は、「改善前のコードで期待される出力」を記録しておき、改善後のコードと比較する形でもよい。
私が実際に経験したのは、リスト処理をset処理に変えたときに、元のコードでは保証されていた順序がsetでは保証されなくなり、後続の処理に影響が出たケースだ。テストを実行していなければ気づかなかった変化だった。
よくある質問（FAQ）
Q1. Codexはどんな言語のパフォーマンス改善に対応していますか？
Python・JavaScript・TypeScript・Go・Java・Rubyなど主要言語のパフォーマンス改善に対応しています。各言語固有の最適化パターン（PythonならNumPy活用・リスト内包表記、JavaScriptなら非同期処理の適切な使い方）を理解した上で提案してくれます。言語を明示して渡すことで、より適切な提案が返ってきやすくなります。SQLのクエリ最適化にも対応しており、N+1問題・インデックスの活用・JOINの書き方改善なども相談できます。
Q2. プロファイリングをしたことがない場合、何から始めればよいですか？
言語ごとに使いやすいプロファイリングツールがあります。Pythonなら「cProfile」（標準ライブラリに含まれ、追加インストール不要）が最初の一歩として使いやすいです。Node.jsなら「console.time()/console.timeEnd()」でコードブロックの実行時間を計測できます。SQLならデータベースのEXPLAIN文（MySQLではEXPLAIN SELECT〜、PostgreSQLでも同様）でクエリの実行計画を確認できます。Codexに「このコードのプロファイリング方法を教えてください」と聞くと、使い方の説明もしてくれます。
Q3. Codexが提案したキャッシュの導入は安全ですか？
キャッシュは効果的ですが、導入前に「キャッシュが古くなったときの更新戦略」を決める必要があります。Codexはキャッシュの実装コードを生成してくれますが、「いつキャッシュを無効化するか」というロジックは、アプリケーションのビジネスルールに依存するため、自分で設計する必要があります。キャッシュの不整合（古いデータが返り続ける）はデバッグが難しいバグになるため、導入後のテストと監視の仕組みをセットで考えることを推奨します。
Q4. N+1問題とは何ですか？Codexはどう対処しますか？
N+1問題とは、1回のメイン処理に対してN回の追加クエリが発生するデータベースアクセスのパターンです。例えば、10件の注文を取得して（1回目のクエリ）、各注文に紐づく顧客情報を取得する（10回のクエリ＝N回）という場合、合計11回のクエリが発生します。Codexはこのパターンを検出し、「JOINを使った1回のクエリにまとめる」または「事前に必要なデータをまとめて取得しておく（プリロード/eager loading）」という改善案を提示してくれます。ORMを使っているコードでは特に頻出する問題です。
Q5. Codexの最適化提案が効かなかった場合はどうすればよいですか？
まずプロファイリング結果と改善後の測定結果を比較して、本当に改善されていないかを確認します。改善されていない場合、ボトルネックが別の箇所にある可能性があります。プロファイリング結果をCodexに渡して「この結果を見てボトルネックを特定してください」と依頼することで、より正確な指摘が得られます。また、問題がコードではなくインフラ（DBのスペック・ネットワーク遅延・ディスクI/Oなど）にある場合は、コードの最適化では解決できません。
Q6. フロントエンドのパフォーマンス改善にもCodexは使えますか？
はい、使えます。JavaScriptのレンダリング最適化・不要な再レンダリングの防止・バンドルサイズの削減・遅延ロードの実装など、フロントエンド特有のパフォーマンス問題にも対応できます。Reactなら「このコンポーネントが不必要に再レンダリングされている原因を指摘してください」、Vue.jsなら「このウォッチャーの処理が重いです。改善案を教えてください」のように、フレームワークを指定して依頼すると精度が上がります。Lighthouseのスコアや計測ツールの結果をあわせて渡すとさらに具体的な提案が返ってきます。
Q7. パフォーマンス改善とリファクタリングを同時に行うことはおすすめですか？
推奨しません。パフォーマンス改善とリファクタリングは目的が異なる変更で、同時に行うと「速くなったのはどの変更のせいか」「動作が変わったのはリファクタリングのせいか最適化のせいか」が追いにくくなります。まず動作を変えないリファクタリングを行ってテストが通ることを確認し、その後にパフォーマンス改善を行う順番が安全です。Codexに依頼する際も「リファクタリングしてください」と「パフォーマンスを改善してください」を別の依頼として分けることを推奨します。
まとめ：Codexはパフォーマンス改善の「気づき」を与えてくれた
Codexをパフォーマンス改善に使い始めて変わったことは、「自分では見えていなかった問題に気づける」という体験の積み重ねだった。
N+1問題・データ構造の選択ミス・ループ内の無駄な計算——これらはどれも「言われれば分かる」が「コードを書きながら気づく」のが難しい問題だ。Codexに「外からの目」でコードを見てもらうことで、自分が書いた直後には見えなかった問題が浮かび上がった。
ただし、Codexの提案を活かすためには、「測定→特定→改善→再測定」というサイクルを守ることが大切だ。プロファイリングなしにCodexの提案を採用しても、的外れな最適化になる可能性がある。Codexは「何が問題か」を見つける力を貸してくれるが、「何を優先して直すか」は測定結果と自分の判断が必要だ。
「動いているけど遅い」コードへの向き合い方が、Codexを使うことで変わった。問題を一人で抱えてにらみ続けるより、まずCodexに渡して「外からの指摘」を受け取ることから始める方が、解決への道が短くなる。
今、遅いと感じているコードがあるなら、まずCodexに「このコードのパフォーマンス上の問題点を指摘してください」と渡してみてほしい。自分では気づいていなかった何かが見えてくるかもしれない。
