結論から書く。AIコーディングエージェントは「速くなる」が前提で語られがちだが、実際には特定の条件が揃うと明確に遅くなる。私が本業のFDE（企業のAI導入支援）と複業側の開発の両方でClaude Codeを日常的に使っていて体感しているのは、①要件があいまいなまま投げたとき、②レビューコストがエージェントの生成速度に追いつかないとき、③直したいバグの原因がコードの外（環境・設定・外部サービス）にあるとき、の3パターンで確実に速度が落ちるということだ。今回はこの3パターンを具体的に書く。
「速そう」という感覚が判断を狂わせる
AIコーディングエージェントを使い始めた頃、私は「エージェントに投げている時間=速い」と錯覚していた。手を動かさずにコードが生成されていく様子を見ていると、体感として「進んでいる」感じがする。
だが実際に計測してみると、生成されたコードを読んで意図とズレている箇所を見つけ、修正指示を出し、また生成を待つ——このループが3〜4周すると、自分で最初から書いた方が早かったケースが普通にあった。問題は「エージェントが遅い」のではなく、「自分の投げ方と検証の仕方が、エージェントの速さを活かす構造になっていない」ことにある。以下、具体的に速度が落ちる条件を整理する。
パターン1: 要件があいまいなまま投げる
一番遅くなるのはこのパターンだ。「このバグを直して」「ここにこの機能を足して」とだけ伝えて、期待する仕様や制約を言語化せずに投げると、エージェントはもっともらしいが的外れな実装を高速に生成してくる。
問題は、生成物の見た目が整っているせいで、レビューする側が「一見動きそうだからこれでいいか」と判断を誤りやすいことだ。的外れな実装をベースに修正を重ねると、最終的に全部書き直す羽目になり、最初から自分で仕様を詰めてから書いた場合より遅くなる。
私がクライアントワークで徹底しているのは、エージェントに投げる前に「入力」「期待する出力」「守るべき制約（既存のインターフェースを変えない、特定のライブラリを使わない等）」の3点を短くてもいいので文章にしてから渡すことだ。この一手間を省いた案件ほど、後のレビューで手戻りが発生している。
パターン2: レビューが生成速度に追いつかない
エージェントはコードを書く速度が人間より圧倒的に速い。この速度差自体が罠になる。
レビューを雑にして「動いたからOK」で進めると、後になって型の不整合、想定外のエッジケース、既存コードとの重複実装が積み重なっていることに気づく。この「後になって気づく」タイミングが遅いほど、修正コストは指数関数的に増える。1ファイル分の変更ならその場で直せるが、複数コミットにまたがった後に気づくと、どこから崩れたかを遡る作業自体が重い。
私の場合、生成量が多い変更ほど「小さく生成させて、その都度レビューする」というサイクルを崩さないようにしている。1回のプロンプトで大きな変更をまとめて依頼すると、レビューの負荷が一気に跳ね上がり、結局「読むのが面倒だからざっと流す」という手抜きレビューに流れやすい。エージェントの生成速度に自分のレビュー速度を合わせようとするのではなく、レビューできる単位までタスクを分割してから投げる方が、トータルでは速い。
パターン3: 原因がコードの外にあるバグ
これは意外と見落とされがちなパターンだ。バグの原因が環境変数の設定ミス、外部APIの仕様変更、インフラ側の権限設定など、コードそのものではない場所にあるとき、エージェントに「このエラーを直して」と投げ続けると、コード側の修正を延々と繰り返す空回りが起きる。
エージェントはエラーメッセージとコードから推測して直そうとするので、コードを変え続けることはできる。だが原因がコードの外にある場合、どれだけコードを書き直しても直らない。この空回りに気づくまでに何往復もエージェントとやり取りしてしまい、最初から自分でログや設定を確認していれば5分で終わった話に30分以上かかった、という経験が複数案件であった。
エラーが出た瞬間にエージェントへ丸投げするのではなく、「これはコードの問題か、環境・外部要因の問題か」を自分で一度切り分けてから、コードの問題だと判断できた範囲だけをエージェントに渡す。この切り分けを飛ばすかどうかで、体感の作業時間が大きく変わる。
判断材料: 投げる前のチェックリスト
実務では、エージェントに作業を渡す前に以下を自分に確認するようにしている。これを満たさないまま投げたタスクは、高確率で手戻りが発生している。
- 入力・期待する出力・守るべき制約を、投げる前に1行ずつでも言語化したか
- 依頼する変更は、レビューし切れるサイズに分割されているか（目安として1回の依頼で1機能・1修正まで）
- バグ修正の場合、原因がコード側にあると自分で切り分けた上で依頼しているか
- 生成結果を「動いたから良い」ではなく、既存コードとの重複や型の整合性まで見て判断しているか
まとめ
- AIコーディングエージェントは「投げている時間=速い」という体感に頼ると、実際の作業時間を見誤る
- 要件をあいまいなまま投げると、もっともらしい的外れな実装がハイスピードで積み上がり、結局書き直しになる
- レビュー速度が生成速度に追いつかないと手戻りが後から一気に噴出するので、レビューできる単位まで依頼を分割する
- バグの原因がコードの外にある場合はエージェントに丸投げせず、自分で切り分けてから渡す
次回は、この切り分けを踏まえて実際にどうタスクを分割してエージェントに渡しているか、具体的なプロンプト設計を書く。
関連記事
- クライアントワークでClaude Codeを使う際の運用設計
- Claude Codeで複数事業のコードベースを横断運用する方法
- マルチプロジェクトでのAI活用、Claude Codeのメモリ機能をどう使うか
この実践記録はX（@amazenpapa）でも発信しています。
