AI コーディング 使い方：レビュー時間で測る実践ワークフロー
要約
AI コーディングの使い方は、生成よりもレビューで決まります。計画を10行以内で書き、既存のヘルパーを名指しし、差分を小さく保つ。Stack Overflow 2025 年調査では84%が AI ツールを使う、または使う予定と回答した一方、出力を信頼するのは33%でした。METR の研究では、経験豊富な開発者の作業は約19%遅くなりました。速さの体感ではなく、チケットからマージまでの分数で測ってください。
AI コーディング 使い方で最初につまずくのは、たいてい生成そのものではなく、その前後です。チケットの説明をチャットに貼ると、もっともらしい200行のコードが返ってきます。コンパイルも通ります。ところが2日後にレビュアーから「既存のリトライ処理を無視しているのはなぜ？」と聞かれ、チームの誰も答えられません。この記事では、新しく入ったエンジニアに最初に渡しているワークフローを紹介します。モデルを「リポジトリを知らない、速くて自信満々な若手」として扱い、タイピングの時間ではなくレビューの時間を基準に組み立てます。
AI コーディングで本当に速くなるのか？
場合によります。Stack Overflow 2025 年開発者調査では、回答者の84%がAIツールを使っている、または使う予定があると答えました。一方で、出力をある程度信頼しているのは33%にとどまります。最も多い不満は66%が挙げた「惜しいけれど、正しくない」コードです。さらに45.2%は、AIが書いたコードのデバッグに想定より時間がかかると答えています。
統制された調査の結果は、もう少し厳しいものです。2025年のMETR の研究では、経験豊富なOSS開発者16人が、自分がよく知るリポジトリの実際の issue 246件に取り組みました。AI の利用を許可したところ、作業は約19%遅くなりました。本人たちは約20%速くなったと感じていました。METR はその後、より新しいデータを公開しているので、この数字は2025年初頭のツールのスナップショットとして読んでください。
言いたいのは「AI は遅い」ということではありません。速さの体感は当てにならない計器だということです。最初の下書きが出てきた速さではなく、チケットを開いてから PR がマージされるまでの分数で測ってください。
プロンプトを送る前に書くこと
プロンプトを送る前に、10行以内の計画を自分の言葉で書いてください。これを飛ばすと、モデルは隙間を自分の推測で埋めます。その推測は定義上ありふれたものになります。
私のテンプレートは短いものです。
振る舞いの変更を一文で書く。
触る可能性のあるファイルを挙げる。自信がなくても構いません。
新しいコードが再利用すべき既存の関数やパターンを書く。
やってはいけないことを一つ書く（新しい依存を入れない、スキーマを変えないなど）。
動作確認の方法を書く（テスト、curl、スクリーンショットなど）。
3番目は最も飛ばされがちで、「ほぼ正しい」コードの多くがここから生まれます。withRetry というヘルパーが存在することを名前で伝えるか、モデルがそれを読める状態にしない限り、モデルは知りようがありません。
「アプリ全体を作って」というプロンプトは避けてください。初心者でもシニアでも、同じ結果になります。誰も理解できない巨大な差分と、未完成のプロジェクトです。
実務で通用するプロンプトの例
実際の作業で考えます。Webhook の送信側が、受信側のタイムアウト時にイベントを落としてしまう問題です。弱いプロンプトは「webhook の信頼性を直して」です。使えるプロンプトは、チケットのように読めます。
src/webhooks/sender.ts の sendWebhook() に、指数バックオフ付きのリトライを追加してください。
lib/http.ts の withRetry() を再利用すること。最大4回、ジッターあり。
公開シグネチャは変えない。依存関係も追加しない。
受信側が2回失敗してから成功するケースの vitest テストを追加する。このプロンプトは、ファイル、再利用するヘルパー、上限、確認方法を名指ししています。結果は、一度に読み切れる30行程度の差分になるはずです。差分が150行に膨らんだら、モデルは脱線しています。その場合は手直しせず、差分ごと却下してください。
小さなコツが2つあります。まず計画を先に出させ、ファイルを変更する前に読むこと。間違った計画は30秒の損失ですが、間違った差分は10分の損失です。次に、回答が的外れなときは議論せず、破られた制約を言い直すこと。「新しい依存を追加していますが、ルールでは禁止です」の方が、長い説明より効きます。
どのツールがどの作業に合うか
ツールには3つの形があり、それを混同することが二番目に多い失敗です。
インライン補完は、入力中に次の行を予測します。画面上にパターンがあるボイラープレートやテストに向いています。エディタ内のチャットは、選択したコードについて質問に答え、差分を一つずつ承認できる編集を提案します。エージェントはタスクを受け取り、ファイルを読み、コマンドを実行して、ブランチを持ち帰ります。
選び方は、安く検証できる量で決まります。2秒で読める補完はリスクが低いです。14ファイルに触れるエージェントの実行は、報酬は大きい一方でレビューの負担も大きくなります。
Cursor はエディタ中心の選択肢です。Tab 補完が強力で、エージェントのセッションを並列に動かせる VS Code のフォークです。一日中エディタで作業するなら価値があります。チームが JetBrains に標準化していて切り替えないなら、見送ってください。
GitHub Copilot は、すでに GitHub を使っているチームにとって導入の負担が少ない選択肢です。PR、Issue、レビューが一か所にまとまります。ただし課金には注意してください。2026年6月に使用量ベースの AI Credits に移行したため、エージェントを多用すると、座席料金から想像するより高くつきます。
Claude Code はターミナル中心のエージェント型ツールです。リファクタリングやバグ調査を任せ、結果をレビューする使い方になります。インライン補完はなく、対応するのは Claude のモデルだけです。タスク単位で任せたい人にとっては妥当なトレードオフです。
Aider はスクリプトから扱え、git を中心に動くツールです。変更ごとにメッセージ付きで自動コミットするため、巻き戻しは git revert で済みます。支払うのはモデルのトークン代だけなので、コストを自分で管理したい人に向いています。
リポジトリを無視させない方法
文脈を意図して与えることです。悪い出力の多くは、関連するファイルをモデルが一度も見ていないことに由来します。
習慣は3つです。第一に、ディレクトリ全体ではなく、パターンを決めている2〜3ファイルだけを添付すること。第二に、失敗したテストやエラーは説明せず、そのまま貼ること。第三に、リポジトリに短いルールファイルを置き、ツールが毎回読めるようにすること（命名、エラー処理、禁止ライブラリなど）。多くのエージェントツールが対応しています。
# AI-RULES.md
- エラー：services/ では throw せず Result を返す
- HTTP 呼び出しは lib/http.ts 経由（リトライとトレースあり）
- 新しい依存は PR の説明に理由を書く
- テスト：vitest、*.test.ts を同じディレクトリに置くこの4行のような短いルールだけで、レビューコメントの驚くほど多くを減らせます。人間にとっても助けになります。
まだ知らないリポジトリでは、編集を頼む前に質問してください。「セッションの期限はどこで強制され、何がそれを呼び出していますか？」は、「リフレッシュトークンを追加して」より良い最初のプロンプトです。回答を読み、そこで挙げられた2つのファイルを開いてから、変更内容を決めます。これは普段の grep、blame、誰かに聞く流れと同じですが、より速く進みます。
AI が書いたコードはどうレビューするか
同僚のコードより時間をかけてレビューしてください。同僚にはそのリポジトリでの実績がありますが、モデルにはありません。
私のチェックリストは次の順番です。
読む前に実行する。 自分で書いた、通るテストは、自信ありげな説明に勝ります。
import を読む。 存在しないパッケージや見慣れないヘルパーは、まずそこに現れます。
欠けているものを探す。 エラー処理、null の扱い、後始末。モデルは正常系を上手く書きます。
差分の大きさを確認する。 10行の修正を頼んで120行返ってきたら、頼んでいない部分まで書き換えられています。
説明できない行は削除する。 レビューで擁護できない行は、マージしません。
コミットは小さく、メッセージは正直に書いてください。「webhook 送信に再試行を追加（AI 支援、テスト追加）」で十分です。隠しても誰の得にもならず、後のデバッグが難しくなるだけです。
任せてはいけないものは何か
間違えたときに、静かに、しかし高くつくものです。認証ロジック、決済フロー、データマイグレーション、権限チェックがそうです。「ほぼ正しい」コードはテストを通り、本番で壊れます。
それでも使えますが、モードを変えてください。コードを書かせるのではなく、リスクを挙げさせてレビューするのです。想定される問題を5つ並べた一覧を読むのは3分で済みます。生成されたマイグレーションを読めば、その後の半日を、その正しさを疑って過ごすことになります。
学習中の人には、もう一つ除外があります。最初の版は自分で書き、そのあとでモデルに批評させてください。生成されたものを常に受け入れる若手は、プログラミングではなくプロンプトを覚えます。そのギャップは、最初の障害対応で表面化します。
チームではどう変わるか
個人とチームの差は、レビューの負荷です。エージェントを使う一人の開発者は、レビュアーが読める量より多くの PR を一日に開けてしまいます。最初に3つを決めておきましょう。
サイズの上限。 変更行数が数百行を超える PR は、誰が、あるいは何が書いたかに関係なく分割する。
開示のルール。 変更が AI 支援であることを明記し、レビュアーが注意を配分できるようにする。
共有のルールファイル。 個人ごとのプロンプトを五つ持つより、規約の情報源を一つにする。
オンボーディングで最も良い使い方は、質問駆動の読解だと考えています。新しく入った人がアシスタントに「この機能はどこにあるか」と聞き、コードで確認する。それだけで「これは誰の担当？」を探す最初の一週間が短くなります。保守できないコードを渡す必要はありません。
最初の1週間の計画（そのままコピーして使えます）
1日目：テストとボイラープレートにだけインライン補完を使う。
2日目：エディタ内チャットで、コードベースへの質問を1日3つ投げ、答えをコードで確かめる。
3日目：タスクごとに小さな編集を1つだけ提案させ、すべての差分を読む。
4日目：低リスクな作業（例：複数ファイルにまたがる設定キーの改名）を、ブランチ上でエージェントに任せてみる。
5日目：レビューでいらついた点から、ルールファイルを書く。
一週間を通して、一つの数字を追ってください。チケットを開始してから、レビュー修正を含めて PR がマージされるまでの分数です。その数字が下がらなければ、そのツールが自分の仕事に合わない場所が分かったということで、それも立派な成果です。
最後に言っておきたいのは、最も確かな効果はコード生成ではなく理解だということです。見慣れないモジュールを1時間ではなく10分で把握できること。コードを書くことは、仕事の中で一度も遅い部分ではありませんでした。遅いのは、読むこと、判断すること、検証することでした。ツールはそこに向け、マージボタンを押す判断は自分が持つ。そうすれば、残りは自然とついてきます。