「AIコーディング」は、エディタでコードの続きを提案する機能から、コードを見ずにアプリを作るやり方までを、1つの語でまとめて指しています。範囲が書き手ごとに違うまま流通しているので、「AIで開発が速くなる」と聞いても、どの工程がどう速くなるのかが分からないまま話が進みます。
この語の中身は、補完型、エージェント型、バイブコーディングの3つに分けると見通しがつきます。機能が違うだけでなく、世に出た時期が4年ほど離れているからです。
AIコーディングは何を指す言葉か
自然言語の指示をもとに、AIがソースコードを生成したり補完したりする技術と開発スタイルの全般を指します。狭く使えばエディタ上の補完機能のこと、広く使えば自然言語だけで開発を進めることまでを含み、どちらの意味なのかは文脈でしか判別できません。
商用ツールとして早い事例は GitHub Copilot です。GitHub は2021年6月29日に技術プレビューとして公開し、Copilot を「AI pair programmer」、つまりペアプログラミングの相手として位置づけました。コードの文脈を読んで、行全体や関数全体を提案する機能として説明されています。
3つの言葉は、出てきた時期が違う
同じ「AIコーディング」の下に並ぶので横並びに見えますが、後から出たものほど人がコードに触る量が減っていきます。日付はいずれも、2026年8月時点で発表元の資料に当たったものです。
- 補完型（2021年）書いている途中のコードに、続きを提案します。人がコードを書く前提は変わりません。
- エージェント型（2024年）指示を受け取ったAIが、複数ファイルの編集を自律的に進めます。
- バイブコーディング（2025年）コードそのものを読まずに、生成と実行と修正を繰り返して形にします。
補完型は既存のフローに乗る
既存の開発フローにそのまま組み込める点が特徴として説明され、GitHub Copilot が代表例として挙げられます。打鍵の量が減ります。
エージェント型の起点
対外的な起点として扱われることが多いのは、Cognition が2024年3月12日に「初のAIソフトウェアエンジニア」として発表した Devin です。公式ブログは SWE-bench で13.86%を解決したと報告しています。従来の最高成績は、無支援の条件で1.96%、編集対象のファイルを与えた条件でも4.80%でした。
学術側では2024年5月6日、Princeton大学の John Yang、Carlos E. Jimenez らが SWE-agent を arXiv で発表しています。言語モデル向けに設計したインターフェース、Agent-Computer Interface を介して、コード編集、リポジトリ探索、テスト実行を行わせる手法で、NeurIPS 2024 に採択されました。エージェント型は宣伝の言葉として出てきただけではなく、査読を通った定式化を持っています。
2025年2月24日には、Anthropic が Claude Code を限定的な研究プレビューとして公開しました。公式は、コードの検索と読解、ファイルの編集、テストの作成と実行、GitHub へのコミットとプッシュまでを行う協働者として説明しています。公式リポジトリでの定義は「ターミナルの中で動き、コードベースを理解し、自然言語の指示で定型作業を実行する agentic coding tool」です。
バイブコーディングは誰が言い始めたか
語の起点は、Andrej Karpathy（元OpenAI共同創業者）が2025年2月2日にXへ投稿した文だとされています。コードが存在することすら忘れて雰囲気に身を任せる新しいコーディングだ、という趣旨の文でした。Nue は元の投稿を直接確認できていないため、日付と文面は複数の二次情報が一致している範囲として書いています。
2025年11月6日、Collins Dictionary が vibe coding を2025年の「今年の言葉」に選び、Karpathy による造語だと明記しました。辞書側の定義は、自然言語で指示するAIを使ってコンピュータのコードを書くこと、です。造語から辞書の選出まで9か月しかかかっていません。
説明が割れているのはどこか
解説記事は、補完型とエージェント型の2分類で止まるものが多くなっています。バイブコーディングは別枠の話として扱われ、3つを出どころごと時系列で並べた日本語記事は見当たりません。分類が機能軸だけだと「どれを使うか」の話にはなりますが、「どこまで人が見るか」の話になりません。
語源の扱いも分かれます。提唱者名と2025年2月という時期まで書く記事がある一方、vibe と coding を組み合わせた語感だけを説明し、誰がいつ言い始めたかに触れない記事もあります。大手通信事業者の解説記事（2025年11月公開）は後者で、AIと人がリアルタイムで並走しながら開発を進める手法、生成と実行と修正のサイクルを短時間で繰り返すもの、と説明しています。
語源を押さえておくと、その記事が指している範囲を判定できます。2025年2月より前に書かれた「AIコーディング」の説明に、バイブコーディングは入っていません。
「速くなる」の根拠は、誰が測ったかで逆を向く
生産性の主張は、出典の種別で結果が割れています。ツールの提供元が関わった調査は速くなったと報告し、独立系の研究機関の調査は遅くなったと報告しました。どちらかが誤っていると決める材料はありません。測っている対象が違います。
提供元が関わった調査
2023年2月13日に arXiv へ提出された研究は、プロフェッショナル開発者95名を対象に、JavaScript で HTTP サーバーを実装するタスクのランダム化比較試験を行いました。GitHub Copilot を使える群は、使えない群より55.8%速く完了しています。平均で1時間11分と2時間41分、95%信頼区間は21%から89%で、統計的に有意でした。
著者4名のうち3名が Microsoft Research と GitHub の所属で、残る1名が MIT Sloan の研究者です。提供元が関わっていることは結果を否定する理由になりませんが、種別として記録しておく価値があります。
同じ研究には、あまり引用されない結果も入っています。タスクの完了率自体には有意差がなく、恩恵は経験の浅い開発者、負荷の高い開発者、年齢の高い開発者に偏っていました。全員が速くなったわけではありません。
独立系研究機関の調査
独立系の非営利研究機関 METR は2025年7月10日、経験豊富なオープンソース開発者16名、実際の作業246件を対象にした試験の結果を公表しました。AIツールの使用を許可された条件では、実測でタスク完了に19%長い時間がかかっています。参加者は事前に24%速くなると予想し、実験後も20%速くなったと自己申告していました。体感と実測が逆を向いています。
この話には続きがあります。METR は2026年2月24日、追跡実験の設計変更を発表しました。招待した開発者の30%から50%が「AIなしでは参加したくない」として辞退したため選択バイアスが生じ、当初設計の追跡調査は完了できていません。新規参加者47名の集団での加速度の推定値はマイナス4%、95%信頼区間はマイナス15%からプラス9%。旧研究の参加者のうち10名の部分集合ではマイナス18%、信頼区間はマイナス38%からプラス9%でした。METR は2025年7月の結果を古いものとし、現在のAIツールの実態を代表しないとしています。
「19%遅くなる」という数字だけを持ち出すのは、測った本人が取り下げている使い方です。信頼区間がゼロをまたいでいる以上、2026年8月時点で言えるのは、熟練者が実際の作業で使う場面については速くなるとも遅くなるとも確定していない、というところまでです。
個人の速度と、チームの出荷は別に測られている
Google Cloud の DORA 2024年版レポートは、AI導入が個人の生産性、フロー、満足度を高める一方で、ソフトウェア配信の安定性とスループットには悪影響を与えると報告しています。書く速度が上がることと、出荷が安定することは、別々の指標として測られています。「AIで速くなるか」を1つの数字で聞くと、この差が消えます。
速くなるのは書くところ、決めるところではない
Nue は受託開発でAIコーディングを前提に体制を組んでいます。設計とレビューは人がやります。AIが速いのは書くところで、何をどう作るかを決めるところではありません。速くなったぶんは、試す回数を増やすことに使っています。
実装が安くなると、工程の順序が変わります。文書で固めてから実装に入る進め方は、手戻りのコストが高かった時代の最適解でした。書き直しが軽いなら、動かしてから決める方が安くなります。AI受託開発 が要件書を開始条件に置かず、解決したいことが1つ決まっていることだけを条件にしているのは、この判断によるものです。PdM とプロダクトデザイナーが AIコーディングと組み、2週間で動いて人に触ってもらえるものを出します。動いて人に触ってもらえるものが、そのまま育てられるとは限りません。プロトタイプとMVPで確かめる対象が違う理由は別の記事に書きました。
順序が変わると、増える仕事があります。何を確かめるために作るのかを決める工程です。作る前に文書を厚くする代わりに、確かめたい一点を絞る必要が出てきます。1回あたりの実装が安くなっても、この一点が定まっていなければ、動くものが増えるだけで判断材料は増えません。
どれだけ速くなったかを、Nue は測っていません。だから数字は書きません。
レビューで見る対象の移り方
コードが速く出てくるようになると、レビューの負荷は減りません。移ります。
Nue の受託開発では、生成AIを使う機能があるかどうかを見積もりの前に確認します。使う場合は、精度が出なかったときの逃げ道の設計が必要です。ここを省くと、動くけれど信用できないものになります。テストが通ることと、出力を信用してよいことは別です。生成AIを組み込んだ機能のレビューは、動くかどうかの確認では終わりません。
役割分担の型は、コード以外の領域から借りられます。Nue の週次のプロダクトレビューでは、コントラスト比、代替テキストの有無、デザイントークンからの逸脱のように機械的に判定できる項目は自動化し、「この導線は分かりにくい」といったUXの妥当性判断は人が担う体制を取っています。コーディングの文脈ではないので類推になりますが、線の引き方は同じです。形式的に判定できるものは機械に寄せ、人の時間は判断が要るところに残す。デザイン側でこの考え方を制約・検証・フィードバックの層に分けて説明したのがデザインハーネスです。
コードを読まずに進めるやり方は、この線を引きません。コードが存在することを忘れるという前提をそのまま運用に持ち込むと、レビューの手がかりが人の側に残りません。試作として速いことと、運用に載せられることは別の話になります。
向いていない場面
出力の正しさを誰も判定できない領域では使えません。精度が出なかったときの逃げ道が設計できないなら、動くものができても運用には乗りません。受託開発の見積もりでこの項目を先に聞くのは、後から効いてくるからです。
誰がやっても一律に速くなるわけでもありません。提供元が関わった調査でさえ、恩恵は経験の浅い開発者に偏り、タスクの完了率には差が出ていません。熟練者が慣れた領域で実際の作業を進める場面については、2026年8月時点で結論が出ていません。
何を作るかが決まっていない状態で始めても、決まっていないものが速くできるだけです。検証が本番に届かない理由は生成AIのPoCが本番に行かない理由に書きました。速く書けることは、そこで詰まっている項目を埋めません。