Executive Summary
AIがコードを書けることと、AIへ仕事を任せられることは同じではありません。
モデルがどれほど賢くても、目的が曖昧で、必要な資料がなく、使ってよい道具と権限が決まらず、結果を検査できなければ、業務としては不安定です。Agentic Engineeringとは、AIモデルの新しい種類ではなく、AIの能力を、継続して委任できる仕事へ変えるための工学だと捉えると分かりやすくなります。
本稿では、Build With Google Day 1の講演とLab 1 / Lab 2を手掛かりに、次の3点を説明します。
- Vibe CodingとAgentic Engineeringは、善悪ではなく用途の違いである
- AIで実装が速くなるほど、仕様と検証が重要になる
- 仕事を任せるには、Context、Harness、人間の判断が必要になる
シリーズの現在地
全5回で「AIがものすごく賢くなった。では、本当に仕事を任せられるのか？」を追います。
- Agentic Engineeringとは何か（今回）
- Antigravityという職場
- Agent Skillsという業務マニュアル
- Agents CLIとADK Graphによる工程設計
- OutputとTrajectoryによる評価
今回は、後の4回を貫く土台を作ります。
ものすごく優秀な新人が入ってきた
ある日、会社に新人が入ってきたとします。
読むのが速い。文章もコードも書ける。初めて見る技術にもすぐ適応する。こちらが一日かけていた作業を、数分で終わらせることさえあります。
それでも、入社初日から基幹システムを自由に操作させる会社はないでしょう。
新人は、次のことをまだ知りません。
- 今回の依頼は、何をもって完了なのか
- どの設計原則を優先するのか
- どの資料が最新版なのか
- どのシステムへ接続してよいのか
- どこから先は承認が必要なのか
- 作業結果を、誰がどの基準で確認するのか
AIエージェントも同じです。モデルの能力は「社員の地頭や技能」に近く、それだけでは会社の仕事になりません。
つまり、賢さは委任の必要条件にはなっても、十分条件ではありません。
上の図の中央にある仕様、文脈、道具、権限、検査は、モデルの外側にあります。ここを設計することが、本シリーズでいうAgentic Engineeringの中心です。
Vibe Codingを悪者にしない
AIコーディングの議論では、Vibe Codingという言葉がしばしば「雑な開発」の意味で使われます。しかし、原義はもう少し限定的です。
Andrej Karpathyが2025年2月にこの言葉を使ったとき、自然言語で修正を頼み、差分をほぼ読まず、エラーをそのままAIへ戻しながら、週末の使い捨てプロジェクトを作る様子を語っていました。重要なのは、これがコードの理解や厳密な検証を意図的に軽くした探索モードだったことです。
たとえば、次の場面では非常に合理的です。
- アイデアが成立するか、まず画面にして触りたい
- 一度だけ使う小さなスクリプトを作りたい
- 新しいAPIの感触を短時間で確かめたい
- 失敗しても影響が局所的で、すぐ捨てられる
問題は、試作品の作り方を、そのまま本番運用へ持ち込むことです。顧客データを扱う、返金する、在庫を変更する、複数人で保守する、といった仕事では、「動いて見える」以外の品質が必要になります。
ここで左右を勝ち負けにしないことが大切です。
| 判断軸 | 探索・試作側 | 継続運用側 |
|---|---|---|
| 成果の寿命 | 短い | 長い |
| 失敗時の影響 | 小さく戻しやすい | 顧客・業務・法令へ波及し得る |
| コード理解 | 後回しにできる | チームが説明・保守できる必要がある |
| 検証 | 手で触る程度でも足りる場合がある | 自動テスト、レビュー、監視が必要 |
| 権限 | ローカルで閉じやすい | 外部システムへの操作境界が要る |
つまり、Vibe CodingとAgentic Engineeringの違いはAIを使うかどうかではなく、成果の周囲へどれだけ構造と検証を置くかです。
AIはSDLC全体を同じ速さにはしない
従来のソフトウェア開発では、要件を集め、設計し、実装し、テストし、リリースし、保守します。この一連をSoftware Development Life Cycle、SDLCと呼びます。
AIは特に実装を大きく圧縮します。関数を一本補完するだけでなく、複数ファイルにまたがる機能、テスト、設定まで短時間で生成できるからです。
しかし、次の問いは同じ割合では短くなりません。
- そもそも何を作るべきか
- 二つの要件が衝突したら、どちらを優先するか
- この設計は将来の変更へ耐えられるか
- 生成物が業務ルールとセキュリティ条件を満たすか
- 予期しない入力でも安全に止まれるか
実装が一週間から一時間に縮んでも、受入条件が曖昧なら、確認と手戻りが大量に発生します。速く作れるからこそ、間違ったものも速く増やせます。
これは、道路の一部だけを高速道路にした状況に似ています。実装区間だけが高速になれば、入口の料金所に相当する仕様化と、出口の検問に相当する検証へ車列が移ります。
以前
要件 ── 設計 ── 実装 ── テスト ── 運用
AI導入後に起こり得ること
要件 ── 設計 ─ 〔実装〕 ── テスト ── 運用
↑
ここだけ急速に圧縮
結果
「書く時間」より「何を正しいとするか」「本当に正しいか」の比重が増える
Build With Google Day 1の講演では、この状態を「Traditional SDLC Under Pressure」として扱い、仕様がAgent出力を直接評価する基準になること、Outputだけでなくそこへ至るTrajectoryも検証することが示されました。
つまり、AIによってエンジニアリングが不要になるのではなく、エンジニアリングの重心が実装から仕様・設計・検証へ移ります。
Prompt EngineeringからContext Engineeringへ
依頼がうまく通らないとき、私たちは「もっと上手な一文を書こう」と考えがちです。しかし、業務の品質は一文の言い回しだけでは決まりません。
新人に「いい感じにレビューして」と頼む代わりに、次を渡すとします。
- このサービスが守るべきSLO
- 過去の障害と再発防止策
- コーディング規約
- アーキテクチャ図
- 正しいレビュー例
- 使用可能なツール
- してはいけない操作
これらは「長いプロンプト」ではなく、仕事に必要な情報環境です。
技術では、Agentへ与える情報を、たとえば次のように分けられます。
| 文脈 | 役割 |
|---|---|
| Instructions | 役割、目的、動作原則 |
| Knowledge | 仕様書、設計資料、ドメイン知識 |
| Examples | 望ましい入力・出力の具体例 |
| Memory | セッションやプロジェクトの継続状態 |
| Tools | API、コマンド、サービスへの操作手段 |
| Guardrails | 禁止事項、形式、承認条件 |
これをどう選び、どのタイミングで、どの範囲へ渡すかを設計するのがContext Engineeringです。全部を常に詰め込むと、重要情報が埋もれ、費用も増え、互いに矛盾する指示が混ざります。そのため第3回では、常時必要なStatic Contextと、必要時だけ読むDynamic Contextを分けます。
つまり、よいPromptは大切ですが、安定した仕事には「何を知れる状態にするか」というContextの設計が要ります。
Harness Engineering——モデルの周囲を設計する
Contextだけでも、まだ仕事は完結しません。資料を読めても、実行環境が危険だったり、権限が広すぎたり、失敗を観測できなかったりすれば、安心して任せられないからです。
Harnessは、もともと馬具や安全帯を意味します。AIエージェントでは、モデルの能力を安全かつ反復可能な仕事へ結びつける周囲の仕組みとして捉えられます。
Agent system
├─ Model 意味を読み、候補を作る
├─ Instructions 役割と規則を伝える
├─ Context / Memory 必要な知識と状態を渡す
├─ Tools 外界へ働きかける
├─ Sandbox 実行の影響を閉じ込める
├─ Permissions 操作可能範囲を制限する
├─ Workflow 順序と分岐を管理する
├─ Evaluation 結果と経路を検査する
└─ Observability 後から追える証拠を残す
この見方の利点は、失敗をすべて「モデルが弱い」で片付けなくなることです。
Agentが誤ったファイルを編集したなら、対象範囲の指示が曖昧だったのかもしれません。正しいAPIへ到達できなかったなら、Toolの接続が不足していたのかもしれません。危険な操作が無確認で走ったなら、Permissionや承認フックの設計不足です。完了報告は正しかったのに実物が違ったなら、Artifactの独立検査が必要です。
つまり、Agentの品質はモデル単体の点数ではなく、モデルを囲むシステム全体の性質です。
Lab 1とLab 2は、同じ問いの前半と後半だった
Lab 1では、Antigravity上でProjectを作り、Conversationを管理し、Scheduled Task、MCP、Artifacts、Governance、Custom Skillを扱います。
Lab 2では、Agents CLIからプロジェクトをScaffoldし、ADK Graphのコードを読み、Lint、Playground、単発CLIで動作を確かめます。
表面上は別の演習ですが、設計上は一続きです。
| Lab | 主に触るもの | 委任の問い |
|---|---|---|
| Lab 1 | 職場、文脈、権限、Skill、Artifacts | Agentにどの環境と手順を与えるか |
| Lab 2 | Schema、Node、Edge、State、Test | Agentの判断をどの経路へ閉じ込めるか |
Lab 1が「新人の職場と業務マニュアル」を作り、Lab 2が「その仕事の承認経路と試験」を作る、と考えると分かりやすいでしょう。
つまり、Day 1の本質はツールの操作方法ではなく、AIの能力を仕事の構造へ接続することにあります。
もう一段深く：AIが組織文化を増幅する理由
AIは、よい設計文化だけを増幅するわけではありません。
受入条件が明確な組織では、Agentはテストを高速に回し、既存規約に沿った変更を量産できます。逆に、責任範囲が曖昧で、テストが弱く、レビュー基準が人ごとに違う組織では、その曖昧さを高速に複製します。
数式のように単純化すれば、成果は次の積に近いと考えられます。
Agentの実効品質
≈ Model能力
× Specificationの明確さ
× Contextの適合度
× Controlの堅牢さ
× Evaluationの検出力
どれか一つが極端に弱いと、モデルだけを強くしても全体は安定しません。これは厳密な測定式ではなく、局所最適を避けるための設計上の見取り図です。
また、「意図が新しいインターフェースになる」ことは、仕様が不要になることを意味しません。自然言語の意図を、検証可能な受入条件、型、権限、状態遷移へ翻訳する仕事が新たに必要になります。人間はキーストロークを減らしても、目的・例外・責任の判断からは外れません。
今回の持ち帰り
- 賢さと委任可能性は別物。 AIの能力は、仕様・文脈・道具・権限・検査で仕事へ変換する。
- Vibe Codingは探索に強い。 Agentic Engineeringは、それを否定せず、長く運用するための構造を足す。
- ボトルネックは移動する。 実装が速くなるほど、何を作るか、どう確かめるか、人が何を判断するかが重要になる。
次回へ
優秀な新人へ仕事を任せるには、まず職場が要ります。
案件ごとの資料と会話をどこへ置くのか。外部システムへどう接続するのか。どの操作を許し、どんな作業証拠を人が確認するのか。
次回は、Antigravityを単なるAIチャットではなく、「AIの職場」として読み解きます。