# AI コーディング 使い方：レビュー時間で測る実践ワークフロー URL: https://codebasechat.com/ja/journal/ai-coding-tsukaikata Type: blog Locale: ja Published: 2026-11-10 Updated: 2026-11-11 --- > AI コーディングの使い方を、新人エンジニアに渡しているワークフローで解説します。計画の立て方、プロンプト例、ツールの選び方、AI が書いたコードのレビュー方法、チームのルールまで。 AI コーディング 使い方で最初につまずくのは、たいてい生成そのものではなく、その前後です。チケットの説明をチャットに貼ると、もっともらしい200行のコードが返ってきます。コンパイルも通ります。ところが2日後にレビュアーから「既存のリトライ処理を無視しているのはなぜ？」と聞かれ、チームの誰も答えられません。この記事では、新しく入ったエンジニアに最初に渡しているワークフローを紹介します。モデルを「リポジトリを知らない、速くて自信満々な若手」として扱い、タイピングの時間ではなくレビューの時間を基準に組み立てます。 ## AI コーディングで本当に速くなるのか？ 場合によります。[Stack Overflow 2025 年開発者調査](https://survey.stackoverflow.co/2025/ai)では、回答者の84%がAIツールを使っている、または使う予定があると答えました。一方で、出力をある程度信頼しているのは33%にとどまります。最も多い不満は66%が挙げた「惜しいけれど、正しくない」コードです。さらに45.2%は、AIが書いたコードのデバッグに想定より時間がかかると答えています。 統制された調査の結果は、もう少し厳しいものです。2025年の[METR の研究](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)では、経験豊富なOSS開発者16人が、自分がよく知るリポジトリの実際の issue 246件に取り組みました。AI の利用を許可したところ、作業は約19%遅くなりました。本人たちは約20%速くなったと感じていました。METR はその後、より新しいデータを公開しているので、この数字は2025年初頭のツールのスナップショットとして読んでください。 言いたいのは「AI は遅い」ということではありません。速さの体感は当てにならない計器だということです。最初の下書きが出てきた速さではなく、チケットを開いてから PR がマージされるまでの分数で測ってください。 ![ノートに手書きの機能計画があり、横にキーボードと付箋が置かれている](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/216434-inline1.webp) ## プロンプトを送る前に書くこと プロンプトを送る前に、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、誰かに聞く流れと同じですが、より速く進みます。 ![2つの色でハイライトされたコードの差分を表示するノートパソコンの画面](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/567383-inline2.webp) ## AI が書いたコードはどうレビューするか 同僚のコードより時間をかけてレビューしてください。同僚にはそのリポジトリでの実績がありますが、モデルにはありません。 私のチェックリストは次の順番です。 - **読む前に実行する。** 自分で書いた、通るテストは、自信ありげな説明に勝ります。 - **import を読む。** 存在しないパッケージや見慣れないヘルパーは、まずそこに現れます。 - **欠けているものを探す。** エラー処理、null の扱い、後始末。モデルは正常系を上手く書きます。 - **差分の大きさを確認する。** 10行の修正を頼んで120行返ってきたら、頼んでいない部分まで書き換えられています。 - **説明できない行は削除する。** レビューで擁護できない行は、マージしません。 コミットは小さく、メッセージは正直に書いてください。「webhook 送信に再試行を追加（AI 支援、テスト追加）」で十分です。隠しても誰の得にもならず、後のデバッグが難しくなるだけです。 ## 任せてはいけないものは何か 間違えたときに、静かに、しかし高くつくものです。認証ロジック、決済フロー、データマイグレーション、権限チェックがそうです。「ほぼ正しい」コードはテストを通り、本番で壊れます。 それでも使えますが、モードを変えてください。コードを書かせるのではなく、リスクを挙げさせてレビューするのです。想定される問題を5つ並べた一覧を読むのは3分で済みます。生成されたマイグレーションを読めば、その後の半日を、その正しさを疑って過ごすことになります。 学習中の人には、もう一つ除外があります。最初の版は自分で書き、そのあとでモデルに批評させてください。生成されたものを常に受け入れる若手は、プログラミングではなくプロンプトを覚えます。そのギャップは、最初の障害対応で表面化します。 ## チームではどう変わるか 個人とチームの差は、レビューの負荷です。エージェントを使う一人の開発者は、レビュアーが読める量より多くの PR を一日に開けてしまいます。最初に3つを決めておきましょう。 - **サイズの上限。** 変更行数が数百行を超える PR は、誰が、あるいは何が書いたかに関係なく分割する。 - **開示のルール。** 変更が AI 支援であることを明記し、レビュアーが注意を配分できるようにする。 - **共有のルールファイル。** 個人ごとのプロンプトを五つ持つより、規約の情報源を一つにする。 オンボーディングで最も良い使い方は、質問駆動の読解だと考えています。新しく入った人がアシスタントに「この機能はどこにあるか」と聞き、コードで確認する。それだけで「これは誰の担当？」を探す最初の一週間が短くなります。保守できないコードを渡す必要はありません。 ![会議テーブルで印刷されたページを一緒に確認する2人のエンジニア](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/e7c330-inline3.webp) **最初の1週間の計画**（そのままコピーして使えます） - 1日目：テストとボイラープレートにだけインライン補完を使う。 - 2日目：エディタ内チャットで、コードベースへの質問を1日3つ投げ、答えをコードで確かめる。 - 3日目：タスクごとに小さな編集を1つだけ提案させ、すべての差分を読む。 - 4日目：低リスクな作業（例：複数ファイルにまたがる設定キーの改名）を、ブランチ上でエージェントに任せてみる。 - 5日目：レビューでいらついた点から、ルールファイルを書く。 一週間を通して、一つの数字を追ってください。チケットを開始してから、レビュー修正を含めて PR がマージされるまでの分数です。その数字が下がらなければ、そのツールが自分の仕事に合わない場所が分かったということで、それも立派な成果です。 最後に言っておきたいのは、最も確かな効果はコード生成ではなく理解だということです。見慣れないモジュールを1時間ではなく10分で把握できること。コードを書くことは、仕事の中で一度も遅い部分ではありませんでした。遅いのは、読むこと、判断すること、検証することでした。ツールはそこに向け、マージボタンを押す判断は自分が持つ。そうすれば、残りは自然とついてきます。 ## FAQ ### AI コーディングは本当に生産性を上げますか？ 作業によります。METR の2025年の調査では、経験豊富な開発者の作業が約19%遅くなりました。速さの体感ではなく、チケットからマージまでの時間で測るべきです。 ### AI にプロンプトを送る前に何を書くべきですか？ 振る舞いの変更、触るファイル、再利用すべき既存のパターン、禁止事項、動作確認の方法を、10行以内の計画として書きます。 ### どのツールから始めればよいですか？ 画面上にパターンがあるテストやボイラープレートならインライン補完から始めます。複数ファイルに触れる作業は、差分をレビューできる範囲でエージェントを試します。 ### AI が書いたコードは何を重点的にレビューすべきですか？ import、エラー処理、null の扱い、差分の大きさを確認します。まず実行してから読み、説明できない行は削除します。 ### 認証や決済のコードにも AI を使ってよいですか？ 生成を任せるのは避け、リスクの洗い出しやレビューに使うことをおすすめします。 ### チームでは何を決めておくべきですか？ PR のサイズ上限、AI 支援の開示ルール、共有のルールファイルの三つです。