コーディングエージェントの選び方
IDE型・CLI型・クラウド型の違いは入口にすぎない。どれを選んでも事故が起きた5つの場面と、編集部が使い続けている運用の型。
「どのコーディングエージェントがいいか」という質問には、正直なところ「どれでも、運用の型がなければ事故が起きる」と答えるしかありません。この記事では、最初にタイプの違いを整理し、そのあと編集部がどのタイプでも実際に踏んだ5つの事故と、その対策を紹介します。
3つのタイプ
| タイプ | 動き方 | 向いている作業 | 注意点 |
|---|---|---|---|
| IDE型 | エディタに組み込まれ、補完から複数ファイルの編集まで | 手元で見ながら速く書く | 差分しか見えないので、全体への影響を見落としやすい |
| CLI型 | ターミナルで動き、コマンド実行やテストまで自走する | 自動化、検証のループ、大きめのリファクタ | シェルの罠を踏む（後述） |
| クラウド型 | リモートのサンドボックスで非同期に作業し、PR を作る | 並列で回す、独立したタスク | 完了報告と実物のずれを確かめる手間が増える |
編集部の現在の使い分けは、ふだんの実装は CLI 型、コードレビューは別系統のモデル、大量の定型処理（分類や翻訳）はいちばん安いモデルです。定型処理はかなり安く、記事299件の翻訳が数分・約0.1ドルで済みました。ただし1回の呼び出しに固定のオーバーヘッドがあるので、少量を何度も呼ぶと割に合いません。
プランごとの月額と API の目安は「Claude Codeの料金の実際」にあります。Claude Code をこれから入れる人は、インストールから最初の変更までを「Claude Codeの始め方」にまとめました。
事故1：完了報告を信じた
「6コミット先行、PR作成済み」という報告が、実際にはツール呼び出し0回だったことがあります。詳しくは「AIの「完了しました」を信じない仕組み」に書きました。対策は、git の実数を毎ターン表示させることと、「完了の断定」と「実数との矛盾」が両方そろったときに止める hook です。
事故2：作業ディレクトリが持ち越された
CLI 型のエージェントでは、シェルの状態が呼び出しをまたいで残ります。cd lp && npm install のあとに並列で出した3つの呼び出しが、全部サブディレクトリで走ってしまいました。その結果、設定の編集が失敗し、lint は空振りし、空のディレクトリを2回デプロイしました。
# 呼び出しをまたいで状態に頼らない
npm --prefix lp install
git -C /abs/path/repo status
( cd lp && npm run build )シェルが zsh の環境では、さらに罠があります。$VAR が単語分割されない、path という変数名が PATH を壊す、glob が一致しないとコマンドがエラーで止まる、などです。
環境変数が「設定したのに効かない」ときの切り分けは、「Claude Codeで環境変数が効かない」にまとめました。
事故3：サブエージェントが親のモデルを継承した
並列で動かすサブエージェントは、モデルを指定しないと親と同じモデルで起動します。高価なモデルで15体が走り出し、慌てて止めました。いまは起動する前に「何体を、どのモデルで」と1行で宣言させています。
逆に、小型のモデルに連鎖するリファクタを任せたら、「テスト1本で足りる」と自分で判断して既存のテストを195行消しました。小型のモデルに任せるのは、1〜2ファイルで、仕様が明確で、削除を含まない作業だけにしています。
並列運用で踏んだほかの失敗は「サブエージェント並列運用の失敗集」にまとめています。
事故4：レビューを「0件になるまで」回した
状態遷移・競合・ライフサイクルを含む変更は、別系統のモデルで指摘が出なくなるまでレビューを繰り返します。ある機能は18周かかり、重大な指摘（P1）が6件、中程度の指摘（P2）が16件出ました。1か所直すたびに、次の競合が見えてきました。
一方で、7周しても件数が 4→3→4→1→3→2→4 と減らず、人間のレビュアーに止められたこともあります。いまの打ち切りの基準は、件数ではなく指摘の中身の変化です。「もっと厳密にできる」という理想論ばかりになったら締めます。P1 は直し、P2 は2周目までに直して、残りは既知の課題として記録します。
打ち切りの判断と CLI の罠は「AIコードレビューは何周で止める？」に書きました。
事故5：権限の分類器を説得しようとした
エージェントの安全分類器は、実行内容ではなくコマンドの文字列を見て止めます。Issue の本文に delete from … と書いただけで「大量削除」として拒否されたことがあります（DB には触らない操作でした）。会話の中でユーザーの同意を取っても、本番への書き込みは通りません。
分類器を回避しようとするのはやめました。いまは段取りの段階で、読み取りはエージェント、書き込みは人と分けています。書き込みが必要なときは「確認の SELECT → 書き込み → 検証の SELECT」を1本のスクリプトにまとめ、人に1回だけ実行してもらいます。マージも人が行います。
読み取りと書き込みの分け方は「AIエージェントの権限設計」で詳しく扱っています。
どれを選ぶか
- 手元で速く書くなら IDE 型。ただし大きな変更は CLI 型で検証のループを回す。
- 無人で回すなら、完了報告を git の実数で確かめる仕組みを先に作る。
- 料金体系は数か月単位で変わります。契約する前に最新の料金を確認してください。
- ローカル LLM と組み合わせるなら、「1ターンに何トークン送るか」で比べます。同じタスクで、2,834トークン・24.6秒と、30,301トークン・4分35秒の差が出ました。API の費用を抑えたいときの選択肢としての測定は「ローカルLLMの遅さの正体」に書きました。
- セッションをまたいで引き継ぐなら、メモに状態を書かない。設計は「エージェントのメモリ設計」に書きました。
- 製品ごとの違いは「3製品を運用で比べた結果」にまとめました。