0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Claude Codeに「応答が遅い」と伝えたら、丸2日間ずっと見当違いの場所を高速化されていた話

0
Posted at

Claude Codeに「応答が遅い」と伝えたら、丸2日間ずっと見当違いの場所を高速化されていた話

「なんか今日、AIの返事が遅いな」——そう感じて、使っているAIコーディングアシスタントに直接「遅い」とだけ伝えたことはないだろうか。そして返ってきた「改善しました」が、自分が本当に困っていた場所とは全然違うところを指していた、ということは。

自分も最近まさにこれをやった。個人開発で動かしている別のプロジェクトの作業をいったん止めてまで、Claude Codeの応答速度の改善に丸2日以上向き合うことになった。

実はこれ、自分の伝え方が下手だったわけじゃなかった。足りなかったのは説明の丁寧さじゃなく、症状そのものの言語化だった。

ここで起きた「フリーズ」は、Claude Code単体の不具合ではない。フックという公式の拡張機能を使って、外部の個人用データベースと連携する自作の仕組みを足していたことが原因だった。フックを使っていない標準のClaude Codeで同じ症状が起きるわけではない。

「遅い」の一言で調査が始まった

伝えた症状は、最初はたった一言だった。「作業を止めてまでこれをやっているんだから、応答が遅い問題をちゃんと直してほしい」。曖昧といえば曖昧な言葉だが、自分の中では症状ははっきりしていた。入力してから最初の反応が返ってくるまでの時間が、体感で長くなっている、というものだ。

AIは、自分が扱いやすい指標にすり替えた

ところが調査を始めたAIは、最初の数時間、頼んでもいない「権限確認のダイアログが出て止まる時間」を主戦場にし始めた。たしかにダイアログが出れば人間の入力待ちになるので、体感の"遅さ"に見えなくもない。でもそれは自分が指摘した症状ではなかった。

指摘すると、AIはいったん認めるものの、また別の測定を追加して似たような検証を続けた。指摘のたびに測定項目が増え、直すはずの時間が調査の時間に食われていく。遅さを直すために頼んだはずのAIが、目の前で新しい"待ち時間"を作っている状態だった。

チェックリストを作れと指示したのに、AIはそれを使わなかった

さすがに同じ指摘を繰り返すのに疲れて、「どうせ大前提を忘れるんだから、対応チェックリストを作ってから実施しろ」と伝えた。AIは実際にチェックリストを作った。作業前に前提を確認する項目、作業後に効果を測り直す項目——ちゃんと書いてある。

ところがその後の報告では、「効果を測り直したか」を確認するはずの項目が、また抜け落ちていた。チェックリストを作ることと、それを実際に使うことは別物だと、身をもって示す結果になった。こちらが指摘して初めて、AIは中身を見直し、測定をやり直した。

結局、「遅い」ではなく「止まっていた」だった

何度かのやり取りの末、症状がようやく正確な言葉になった。「遅い」と言っていたのは入力してからAIが読み込むまでの時間のことで、それとは別に、時々操作を受け付けなくなり、停止ボタンを押しても反応しないことがある——そう言い直して、初めて全体像が見えた。問題は「中央値がやや長い」というなだらかな遅さではなく、操作を一切受け付けなくなる完全な停止だった。数秒〜十数秒の遅さと、停止ボタンすら効かなくなる停止とでは、原因も対処もまるで違う。この一言が出てくるまで、調査は何度も別の方向に逸れていた。

原因は、毎ターン裏で動いている「記憶を思い出す」仕組みだった

Claude Codeには、入力を送るたびに裏で自分のスクリプトを走らせるフック(UserPromptSubmit)という仕組みがある。公式ドキュメントによれば、これは次のタイミングで発火する。

When it fires: When you submit a prompt, before Claude processes it

自分の場合、このフックを使って**個人用の記憶データベース(RAG)**を検索し、関連する過去の判断や教訓を毎回自動で差し込む仕組みを組んでいた。フック側の検索処理がまれに応答不能になり、フックを含むプロセス全体が巻き込まれて固まる——これが「止まる。停止ボタンも効かない」の正体だった。

この記憶を差し込む仕組み自体をどう作ったかは、個人ブログ(AIに毎ターン「今、思い出すべきこと」を差し込む — 個人RAGの活性化層・外部サイトに移動します)に書いている。

直してみた数字

原因が分かれば、あとは早かった。フックの中身を測り直すと、無駄な処理がいくつか積み重なっていた。読み込み処理の見直し、接続先の設定変更、失敗を素早く見切る仕組みの追加——数回に分けて修正を入れた前後で、実際にこう変わった。

応答の中央値(入力してから最初の反応が返るまで)

区間 サンプル数 中央値
修正前(13日間) 680 16.04秒
修正後(3つ入れ終えた後) 19 10.48秒

完全停止(10分以上まったく反応が返らなかった回数)

件数 最長
修正前日 7件 16分
修正当日 0件

修正後のサンプルはまだ19件しかなく、これで「完治した」と言い切るつもりはない。停止の方も1日分の観測なので、これから何日か様子を見る必要がある。ただ、前日に7回も起きていたものが当日ゼロになったのは事実だ。

やってみて分かったこと

一番効いたのは、コードの修正そのものより、症状を自分の言葉で正確に言い直したことだった。「遅い」という一言だけでAIに調査を丸投げすると、AIはその曖昧さを自分が扱いやすい方向へ勝手に埋めてしまう。悪気があるわけじゃなく、むしろ真面目に対処しようとした結果として、見当違いの場所を一生懸命直し続ける。

だから今は、AIに何かを「直して」と頼む前に、自分自身にもう一度聞き直すようにしている。遅いのか、止まるのか。数秒の話なのか、操作が効かなくなる話なのか。 それを最初に言葉にできていれば、丸2日間はもっと短くできたはずだと思う。

関連記事(個人ブログ)

この話をどう測って、どう直したかの詳細は個人ブログに書いています。

参考にした公式ページ


個人ブログ(https://mint041223techblog.netlify.app/)に日々の開発で気づいたことを詳しく書いています(外部サイトに移動します)。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?