「重い」と言われた画面を前に、どこから手をつけるか考えている開発者
AIコーディング約15分

AIにパフォーマンス改善の候補を出させる｜推測で直さない手順

「あの画面、最近ちょっと重いんだよね」。朝会でそう言われて、その日の午後に手が空いた——という流れは、たぶん今日もどこかで起きています。

とりあえずAIに聞いてみる。コードを貼って「速くしてほしい」と伝えると、改善案が十いくつ、きれいに箇条書きで返ってきます。N+1クエリ、インデックス、キャッシュ、非同期化、アルゴリズムの計算量。どれも、もっともらしい。

そして手が止まります。全部やる時間はないし、どれが効くのかも書いていないからです。

これは、聞き方が下手だったから起きることではありません。AIは「一般によく遅くなる場所」なら答えられますが、「あなたのシステムでいま時間を食っている場所」は知らない——ただそれだけです。知らないことを聞かれたから、一般論が並んだ。この記事では、そこをどう埋めるかを整理します。

結論：AIにパフォーマンス改善を手伝わせるときの要点は3つです。①コードを貼る前に、遅さを3つの数字にする——どの操作が／何秒かかっていて／どのくらいの件数・時間帯のときか。②「速くして」ではなく「この計測結果から、遅い原因の候補を、可能性が高い順に、確かめ方つきで挙げて」と頼む。AIは原因の仮説を並べるのが得意で、どれが効くかの判断は苦手です。③1つ直すごとに、同じ条件で測り直す。まとめて直すと、何が効いたのか永遠に分かりません。

AIに足りないのは腕ではなく、あなたのデータ量とアクセスのされ方です。そこだけ数字で渡せば、候補出しはかなり頼れます。

全部を今日やる必要はありません。まずは①の3つの数字からで大丈夫です。

何が起きているのか——AIは「よくある遅さ」を答えている

推測で見当をつける場面、ストップウォッチで計測する場面、いちばん大きいものだけを1つ直す場面を並べた図
測らずに推測で選ぶと、たいてい小さいほうを直してしまう。計測してから、いちばん大きい1つに手を入れます

まず、なぜここだけ勝手が違うのかを共有させてください。理由は3つあります。

1つ目は、AIが見ているのがコードだけだということ。同じ「一覧を組み立てるコード」でも、対象が10行なのか10万行なのかで、直すべき場所はまるで変わります。AIはその件数を知りません。だから、件数がいくつでも言える一般論——N+1、インデックス、キャッシュ——を並べることになります。間違ってはいないけれど、あなたの環境で効くかどうかは別の話です。

2つ目は、遅さがたいてい1〜2か所に偏っていること。図の中央です。処理時間の内訳を測ってみると、ほとんどの場合、ひとつ飛び抜けて大きい箱があります。残りは合計しても誤差の範囲、ということが珍しくありません。だから、返ってきた十いくつの候補を全部やる必要はそもそもないのです。やるべきは、いちばん大きい箱を見つけることで、その情報はコードの中ではなく計測結果の中にあります。

3つ目は、推測で直すと「複雑になっただけ」で終わりやすいこと。図の左です。測らずに手を入れると、たまたま目についた小さいほうを直してしまいます。速度は体感で変わらず、コードだけ読みにくくなる。しかもキャッシュや並列化のように、新しい不具合を持ち込む種類の変更だと、遅いままリスクだけが増えることもあります。

この3つが重なると、「AIに聞いて何日か直したのに、ユーザーからはまた重いと言われる」という、いちばん報われない状態になります。逆に言えば、測るのを先にするだけで、AIの候補は急に使えるものに変わるということでもあります。

具体例——AIの改善案が、こう外れる

現場で見かけやすいのは、次のような形です。どれも「AIが嘘をついた」わけではなく、判断材料がなかったというだけの話です。

並べてみると、外れ方のほとんどが「件数」「更新頻度」「どこで時間を使っているか」を渡していないことに由来します。裏を返せば、渡せる情報です。

影響——一番の損失は、時間より「次の手が無くなること」

推測で直すことのしんどさは、直った・直らない以外のところにも出ます。

ただ、ここは強調しておきたいのですが、計測は一度やれば資産になります。今日測った数字は、次に「重い」と言われた日の比較対象になります。いま測っておくことは、未来の自分の調査時間を減らす作業でもあります。

明日からやること（3ステップ）

大がかりな監視基盤は要りません。この順番で、今日から小さく始められます。

1. コードを貼る前に、遅さを3つの数字にする

まず、次の3つを1行ずつ書きます。これがAIへ渡す最初の材料です。

①どの操作が遅いのか（画面名・API名・バッチ名まで具体的に）
②何秒かかっているのか（よくあるときと、いちばん遅いときの両方）
③どんな条件のときか（データ件数・同時アクセス・時間帯）

例：

測り方は、大がかりでなくて構いません。ブラウザの開発者ツールで、どのリクエストに何秒かかっているかを見るだけでも、サーバ側かフロント側かの切り分けはできます。サーバ側なら、監視ツール（APM）があればその画面を、なければ処理の前後で時刻を記録してログに出すだけでも十分な出発点になります。プロファイラが使える環境なら、それがいちばん早いです。

ひとつだけ注意点を。平均だけを見ないでください。平均1.5秒でも、20回に1回が8秒かかっているなら、ユーザーが覚えているのは8秒のほうです。「ふだん」と「いちばん遅いとき」の2つを持つ、と決めておくと迷いません。

そして、ここで内訳まで分かったら、AIに聞く必要すらないことがあります。「3秒のうち2.8秒が1本のクエリだった」と見えてしまえば、もう直す場所は決まっています。

2. 「候補を、確かめ方つきで、可能性が高い順に」頼む

数字が出たら、修正コードではなく仮説を頼みます。ここはAIがかなり得意な仕事です。

そのまま使える頼み方の例：

以下の前提と計測結果について、修正コードはまだ出さなくて結構です。 この処理が遅い原因の候補を、可能性が高い順に5つまで挙げてください。それぞれについて、次の3点をセットで書いてください。

1. なぜそれが原因だと考えられるか（計測結果のどの数字を根拠にしているか）
2. それが本当に原因かを確かめる方法（何をどう測れば、白黒つくか）
3. 直した場合、どの数字がどれくらい変わるはずか（見込みで構いません）

あわせて、判断するために足りない情報があれば、先に質問してください。

前提：（言語・フレームワーク・DB／データ件数／同時アクセス）
計測結果：（①②③の3行と、分かっていれば内訳）
コード：（対象のコード）

ポイントは3つあります。

「修正コードはまだ出さなくて結構です」と先に言うこと。これを言わないと、AIは親切に直したコードを並べてくれて、原因の話が置き去りのまま差分レビューが始まります。いま欲しいのは、どこを疑うべきかの順番です。

「確かめる方法」を必ず添えさせること。これが入ると、候補が検証できる形になります。「たぶんN+1です」ではなく「発行されているクエリ本数を数えれば分かります」まで書かせる。すると、AIが当てずっぽうで言っている候補は、確かめ方が書けずに曖昧になるので、そこでも見分けがつきます。

「足りない情報があれば質問して」と足すこと。地味ですが効きます。件数や更新頻度を聞き返してくれれば、こちらが渡し忘れていたことに気づけます。前提の渡し方そのものはAIにコードを書かせる前に渡す前提と制約｜伝え方の型と同じ考え方です。

返ってきた候補は、上から順に「確かめる方法」だけ実行します。直すのはまだです。ここで多くの候補は消えます。全部に対応する必要はまったくありません——選り分け方はAIレビューの指摘を取捨選択する｜直す・直さないの判断軸と同じ要領です。

3. 1つ直して、同じ条件で測り直す

残った候補のうち、いちばん大きい箱ひとつに手を入れます。図の右です。

そして、どこかで止める判断も必要です。1.1秒を0.9秒にするために2日かけるより、その2日を別の仕事に使ったほうがいい場面はよくあります。「どこまで速ければ十分か」を先に決めておくと、止めどきで迷いません。期待値のすり合わせはAIへの過度な期待を現実に着地させる｜できる・できないの説明術の考え方が役に立ちます。

3つとも今日やる必要はありません。ステップ1の3つの数字を書くだけでも、AIから返ってくる候補は変わります。

パフォーマンス改善のチェックリスト

全部に○が要るわけではありません。気になった行だけで十分です。

① AIに聞く前に

② AIに聞くとき

③ 直したあと

この記事のまとめ

AIは、遅くなりやすい場所のカタログを驚くほど速く出してくれます。得意なのは候補を並べることと、確かめ方を書くこと。苦手なのは、あなたのシステムでいちばん時間を食っているのがどこかを知ることです。それは、渡していない情報だからです。

やることは3つだけです。①遅さを3つの数字にする／②「修正コードはまだいいので、原因の候補を確かめ方つきで、可能性が高い順に」と頼む／③1つ直して、同じ条件で測り直す。この3つがあると、性能改善は「勘で当てにいく作業」から、「順番に確かめる作業」に近づきます。

計測結果を確かめて、速くなったことを自分の目で確認できた開発者

「重い」と言われたときに、いきなりコードを開かず「まずどこが重いのか測ろう」と思えたなら、それはもう、遠回りをひとつ減らしています。全部の候補を潰さなくて大丈夫です。いちばん大きい箱をひとつ見つけて、ひとつ直す。それだけで、明日の画面は今日より軽くなります。

よければ、こちらも

関連用語