AIにコードを書かせるだけでは、本番品質のソフトウェアは作れない——Googleが公開した50ページの白書は、そんな実務上の落とし穴を正面から扱っています。

この記事では、GoogleチームがKaggleで無料公開した「The New SDLC With Vibe Coding」の要点を整理します。vibe codingとagentic engineeringの違い、SDLCの変化、失敗の原因と対策まで、開発現場で使える視点を押さえられます。

この記事でわかること

  • Googleが公開した50ページ白書の位置づけと主な論点
  • vibe codingからagentic engineeringへのスペクトラムの考え方
  • 「Agent = Model + Harness」という失敗分析の枠組み
  • 実装は速くなる一方でボトルネックが移る新SDLCの構造
  • 個人・チーム・組織それぞれの着手ポイント

https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding

Googleが公開した白書の概要

2026年5月、Addy Osmani氏、Shubham Saboo氏、Sokratis Kartakis氏の3名が執筆した「The New SDLC With Vibe Coding」を、GoogleはKaggle上で無料公開しました。全50ページで、副題は「From ad-hoc prompting to Agentic Engineering（場当たり的なプロンプトからエージェント工学へ）」です。

この資料は、KaggleとGoogleが共同で開催した5日間のAIエージェント集中講座の教材の一部です。同講座は150万人以上が参加し、白書は200万回以上閲覧されています（参考）。単なる用語解説ではなく、開発ライフサイクル（SDLC）全体をAI前提で組み直すための枠組みがまとめられています。

白書の冒頭では、2026年初頭時点でプロ開発者の85%がAIコーディングエージェントを日常的に使い、51%が毎日利用し、新規コードの約41%がAI生成であると述べられています。問題は「AIを使っているか」ではなく、「どれだけ構造・検証・人間の判断が出力を支えているか」に移った、というのが本書の出発点です。

vibe codingとagentic engineeringは二択ではない

白書が強調するのは、vibe codingとagentic engineeringを対立概念として切り分けないことです。両者はスペクトラムの両端に位置し、同じClaude CodeやCursorを使っていても、周囲の仕組みの厚みで実態は大きく変わります。

観点 vibe coding agentic engineering
意図の伝え方 カジュアルな自然言語 仕様書・アーキテクチャ文書・ルールファイル
検証 「動きそうか」で判断 自動テスト・CI/CD・LMジャッジ
適した用途 プロトタイプ・個人スクリプト 本番システム・チーム開発

2025年2月にAndrej Karpathy氏が提唱したvibe codingは、自然言語で指示し、エラーをプロンプトに貼り戻して直すスタイルを指します。2026年初頭にはKarpathy氏自身が「agentic engineering」という語を導入し、より規律ある側面を示しました。白書はこの流れを踏まえ、用途に応じてスペクトラム上の位置を選ぶべきだと整理しています。

決済処理をvibe codingで組むとCTOが不安になる一方、テストと制約の下でAIが実装を担うagentic engineeringなら別の話になる——白書は、この温度差を意図的に言語化しています。

ボトルネックは「タイピング」から「仕様の質」へ

従来のSDLCは、要件・設計・実装・テスト・デプロイ・保守という段階で進みます。AIはこの流れを一様には速めません。実装は数週間かかっていた作業が数時間に圧縮される一方、要件定義・アーキテクチャ判断・検証は依然として人間のペースに縛られます。

白書はこの非対称性を「実装は解決済み、検証・判断・方向づけが新しい職人技」と表現しています。開発者の役割は、コードを書く実装者から、仕様を定義し出力を評価するシステム設計者へ移ります。

ここで登場するのが「ファクトリーモデル」です。開発者の成果物は個々のコードではなく、コードを生み出す仕組みそのものになります。仕様とコンテキスト、実装エージェント、テストと品質ゲート、失敗をフィードバックするループ、安全制約——これらを設計する側が開発者です。

Agent = Model + Harness

白書の中核概念は「ハーネス（harness）」です。エージェントの挙動の多くは、基盤モデルそのものより、モデルを取り巻く仕組みで決まります。

Agent = Model + Harness

ハーネスに含まれるのは次の要素です。

  • 指示とルールファイル（AGENTS.md、CLAUDE.md、GEMINI.mdなど）
  • ツール定義とMCPサーバー
  • サンドボックスと実行環境
  • オーケストレーションロジック（サブエージェント起動、モデルルーティング）
  • ガードレールとフック（コミット前チェックなど）
  • オブザーバビリティ（ログ、トレース、コスト計測）

エージェントが誤動作したとき、最初に疑うべきはモデルの性能ではなく、ツール不足・曖昧なルール・欠落したガードレール・ノイズだらけのコンテキストだと白書は指摘します。多くの失敗は設定ミスに起因する、という分析です。

Terminal Bench 2.0のベンチマークでは、モデルを変えずハーネスだけを改善したチームが圏外30位以下から5位以内に入った事例が紹介されています。LangChainの別研究でも、システムプロンプト・ツール・ミドルウェアの調整だけでスコアが13.7ポイント上がったと報告されています。

コンテキスト工学が橋渡しになる

プロンプトの巧みさより、エージェントに渡すコンテキストの質が出力を左右します。白書はこれをコンテキスト工学（context engineering）と呼び、6種類の情報を整理しています。

  • Instructions（役割と境界）
  • Knowledge（ドキュメント・図表）
  • Memory（セッション履歴と永続状態）
  • Examples（行動パターンの例示）
  • Tools（呼び出せるAPIやスクリプト）
  • Guardrails（安全制約とフォーマット規則）

さらに静的コンテキスト（常時読み込み）と動的コンテキスト（必要時のみ取得）の切り分けが重要です。Agent Skillsは動的コンテキストの代表例で、タスクに応じて専門知識を段階的に読み込む仕組みです。コンテキスト工学は、vibe codingとagentic engineeringをつなぐ実践領域でもあります。

80%問題と開発者の二つの働き方

AIエージェントは機能の約80%を短時間で生成できます。残り20%——エッジケース、エラーハンドリング、統合ポイント、微妙な正しさ——は文脈理解が必要で、ここが落とし穴になります。コードは正しそうに見え、基本テストも通るのに、ビジネスロジックの前提が誤っている、という失敗が増えています。

開発者の働き方は「指揮者（conductor）」と「オーケストレーター（orchestrator）」の二モードに分かれます。指揮者はIDEでリアルタイムにAIを導き、オーケストレーターは目標を定義してエージェントに委任し、結果をレビューします。前者は理解と制御を保ちやすく、後者はスループットを上げやすい一方、仕様力と評価力が求められます。

METRの調査では、経験豊富な開発者がAIアシスタントを使った特定タスクで、検証と修正にかかる時間の分、実際には19%長くかかったと報告されています（白書内引用）。生産性の数字だけを見ると見落としがちなコストです。

経済性：初期投資と運用コストのトレードオフ

白書は開発手法をCapEx（構築投資）とOpEx（運用コスト）で比較します。

vibe codingは初期投資がほぼゼロですが、非構造なプロンプトの繰り返しでトークンを浪費し、保守時にコードを読み解くコストが膨らみます。agentic engineeringはテストスイートやハーネス設計に upfront の工数をかけますが、出力の初回成功率が上がり、長期の運用コストを抑えられます。

コンテキスト工学は技術論であると同時に財務戦略でもあります。10万トークンのリポジトリ全文を毎回渡すのは非現実的で、AGENTS.mdのような高密度なコンテキストを設計することが、トークン経済の要になります。

本番エージェント構築とAgents CLI

白書の後半では、コーディングエージェントでソフトウェアを作る話から、エージェント自体をプロダクトとして構築する話へ移ります。Google Cloud向けのAgents CLIは、Claude CodeやCodexなど好みのコーディングエージェントと連携し、ADK（Agent Development Kit）のライフサイクル7スキル——プロジェクト生成、コード作成、評価、Agent Runtimeへのデプロイ、オブザーバビリティ設定——を自然言語で回せるCLIです。

プロトタイプから本番エージェントへの移行が、別スタックへの書き直しなしに短縮できる、というのがGoogle側の訴求です。マルチエージェント連携にはMCP（ツール接続）とA2A（エージェント間委譲）の採用も推奨されています。

白書が示す着手順

白書は読者層別に具体的な第一歩を示しています。

個人開発者向け

  • AGENTS.mdを10行程度から始め、エージェントの誤りをルール化する
  • テストとevalをコード生成より先に書く
  • 出荷するコードは1行ずつレビューする

エンジニアリングリーダー向け

  • AGENTS.mdやevalスイートをコードと同様にバージョン管理する
  • デモではなくevalの合格を出荷基準にする
  • プロトタイプ用のvibe codingと本番用のagentic engineeringの境界をチーム規範で明示する

組織向け

  • AI支援開発を生産性機能ではなくエンジニアリング投資として扱う
  • 本番エージェントの前にeval・トレース・権限管理の基盤を整える
  • 採用と育成を実装力から仕様力・評価力・アーキテクチャ判断へシフトする

白書の結論は明快です。「構造はスケールするが、vibeはスケールしない」「AIはエンジニアリング文化を増幅する——強みも弱みも」「人間の役割は縮小ではなく進化する」。生成はほぼ解決済みで、検証・判断・方向づけがこれからの職人技になる、というメッセージで締めくくられています。