AIはコードを書ける。でも「仕事を任せる」は別の話だ——Agentic Engineeringという考え方
AIがコードを書けることと、AIに仕事を任せられることは、同じではない。
この当たり前に聞こえる一文が、実は現場で相当見落とされている。「Copilotで開発速度が上がった」「生成AIでコード補完できるようになった」——それは本当の話だ。でも、それは「モデルが賢くなった」という話であって、「業務として安定して委任できるようになった」とはまだ言えない。
Build With Google Day 1の講演とLab 1 / Lab 2の内容を起点にした技術記事が、この区別を丁寧に解きほぐしている。今回はその内容を軸に、Agentic Engineeringという概念が実務にどう刺さるかを整理したい。
AIはコードが書ける。でも委任できるかは別問題
記事のアナロジーが秀逸なので、まずそのまま紹介する。
ある日、会社に新人が入ってきた。読むのが速い。文章もコードも書ける。こちらが一日かけていた作業を、数分で終わらせることさえある。
それでも、入社初日から基幹システムを自由に操作させる会社はない。
なぜか。新人は「賢さ」を持っているが、以下を知らないからだ。
- 今回の依頼は何をもって完了なのか
- どの設計原則を優先するのか
- どのシステムへ接続してよいのか
- どこから先は承認が必要なのか
- 作業結果を、誰がどの基準で確認するのか
AIエージェントも同じ構造にある。モデルの能力は「地頭や技能」に近く、それだけでは業務にならない。仕様、文脈、道具、権限、検査——これらはモデルの外側にある。ここを設計することが、Agentic Engineeringの中心だ。
賢さは委任の必要条件ではあっても、十分条件ではない。この区別を持っているかどうかで、AI導入プロジェクトの設計がかなり変わってくる。
Vibe Codingを悪者にしない——使い分けの話だ
Agentic Engineeringを語る前に、もう一つ整理しておきたいことがある。Vibe Codingという言葉だ。
Andrej Karpathyが2025年2月にこの言葉を使ったとき、意味は限定的だった。自然言語で修正を頼み、差分をほぼ読まず、エラーをそのままAIへ戻しながら、週末の使い捨てプロジェクトを作る——そういう「意図的に検証を軽くした探索モード」の話だ。
これは合理的な使い方がある。
- アイデアが成立するか、まず画面にして触りたい
- 一度だけ使う小さなスクリプトを作りたい
- 新しいAPIの感触を短時間で確かめたい
問題は、試作品の作り方を、そのまま本番運用へ持ち込むことだ。顧客データを扱う、返金する、在庫を変更する、複数人で保守する——こういった仕事では「動いて見える」以外の品質が必要になる。
元記事が整理している判断軸がわかりやすい。
| 判断軸 | 探索・試作側 | 継続運用側 |
|---|---|---|
| 成果の寿命 | 短い | 長い |
| 失敗時の影響 | 小さく戻しやすい | 顧客・業務・法令へ波及し得る |
| コード理解 | 後回しにできる | チームが説明・保守できる必要がある |
| 検証 | 手で触る程度でも足りる場合がある | 自動テスト、レビュー、監視が必要 |
| 権限 | ローカルで閉じやすい | 外部システムへの操作境界が要る |
Vibe CodingとAgentic Engineeringの違いは「AIを使うかどうか」ではない。成果の周囲にどれだけ構造と検証を置くか、だ。
これは善悪の話ではなく、用途の話だ。探索には探索のやり方がある。本番運用には本番運用の設計がある。混同すると事故が起きる。
AIはSDLC全体を均等に速くはしない
ここが一番重要な指摘かもしれない。
AIは特に「実装」を大きく圧縮する。関数一本の補完だけでなく、複数ファイルにまたがる機能、テスト、設定まで短時間で生成できる。これは本当の話だ。
ただし、以下の問いは同じ割合では短くならない。
- そもそも何を作るべきか
- 二つの要件が衝突したら、どちらを優先するか
- この設計は将来の変更へ耐えられるか
- 生成物が業務ルールとセキュリティ条件を満たすか
実装が一週間から一時間に縮んでも、受入条件が曖昧なら、確認と手戻りが大量に発生する。速く作れるからこそ、間違ったものも速く増やせる。
元記事では、これを「道路の一部だけを高速道路にした状況」に例えている。実装区間だけが高速になれば、入口の料金所に相当する仕様化と、出口の検問に相当する検証へ「車列」が移る。
Build With Google Day 1の講演では、この状態を「Traditional SDLC Under Pressure」として扱い、Agentの出力だけでなくそこへ至る「Trajectory（経路）」も検証することの重要性が示された。
AIによってエンジニアリングが不要になるのではない。エンジニアリングの重心が、実装から仕様・設計・検証へ移る——これが構造として起きていることだ。
Context EngineeringとHarness Engineering
依頼がうまく通らないとき、私たちは「もっと上手な一文を書こう」と考えがちだ。でも、業務の品質は一文の言い回しだけでは決まらない。
新人に「いい感じにレビューして」と頼む代わりに、SLO、過去の障害記録、コーディング規約、アーキテクチャ図、正しいレビュー例、使用可能なツール、してはいけない操作——これらを渡したとする。これは「長いプロンプト」ではなく、仕事に必要な情報環境だ。
これをどう選び、どのタイミングで、どの範囲へ渡すかを設計するのがContext Engineeringだ。全部を常に詰め込むと、重要情報が埋もれ、コストも増え、互いに矛盾する指示が混ざる。常時必要なStatic Contextと、必要時だけ読むDynamic Contextを分ける設計が求められる。
Contextだけでも、まだ仕事は完結しない。そこで出てくるのがHarness Engineeringだ。元記事では、Agentシステムの構成要素としてこう整理されている。
Agent system
├─ Model 意味を読み、候補を作る
├─ Instructions 役割と規則を伝える
├─ Context / Memory 必要な知識と状態を渡す
├─ Tools 外界へ働きかける
├─ Sandbox 実行の影響を閉じ込める
├─ Permissions 操作可能範囲を制限する
├─ Workflow 順序と分岐を管理する
├─ Evaluation 結果と経路を検査する
└─ Observability 後から追える証拠を残す
この見方の利点は、失敗をすべて「モデルが弱い」で片付けなくなることだ。Agentが誤ったファイルを編集したなら、対象範囲の指示が曖昧だったのかもしれない。危険な操作が無確認で走ったなら、PermissionやApprovalフックの設計不足かもしれない。
Agentの品質はモデル単体の点数ではなく、モデルを囲むシステム全体の性質だ。
AIおじさんの見方：これは「曖昧さの高速複製」問題だ
ここからは見方の話になる。
Agentic Engineeringの議論を整理すると、実はひとつの怖い構造が浮かび上がる。
受入条件が明確な組織では、Agentはテストを高速に回し、既存規約に沿った変更を量産できる。逆に、責任範囲が曖昧で、テストが弱く、レビュー基準が人ごとに違う組織では、その曖昧さを高速に複製する。
元記事はこれを数式的に表現している。
Agentの実効品質 ≈ Model能力 × Specificationの明確さ
× Contextの適合度 × Controlの堅牢さ
× Evaluationの検出力
どれか一つが極端に弱いと、モデルだけを強くしても全体は安定しない。これは厳密な測定式ではなく、局所最適を避けるための設計上の見取り図だが、感覚的にはかなり正確だと思う。
多くのAI導入プロジェクトが「モデルを強くする」「プロンプトを改良する」方向に力を入れすぎている。でも本当のボトルネックは、仕様が曖昧なこと、検証基準が存在しないこと、権限の境界が引かれていないことにある場合が多い。これはAIの問題ではなく、元々あった組織・プロセスの問題がAI導入によって可視化されているだけだ。
もう一点。「意図が新しいインターフェースになる」という流れは確かにある。でもそれは仕様が不要になることを意味しない。自然言語の意図を、検証可能な受入条件、型、権限、状態遷移へ翻訳する仕事が新たに必要になる。人間はキーストロークを減らしても、目的・例外・責任の判断からは外れない。
実務的に何を考えるか
「ではどうするか」という話を3点で整理する。
① 仕様化に投資する
実装が速くなるほど、「何を作るか」を明確にする工程の価値が上がる。受入条件、エッジケース、例外処理のルール——これらを曖昧にしたまま「AIに任せる」と、手戻りが増える。仕様書を書く時間が「コストに見えてしまう」感覚を早めに捨てることが必要だ。
② 検証を設計する
OutputだけでなくTrajectory（処理経路）も確認できる仕組みを持つ。「AIが何をしたか」を後から追えるObservabilityの設計は、本番運用では必須になる。「動いていればOK」では、何かが起きたときに何も言えなくなる。
③ Context設計を「プロンプト改善」と混同しない
AIへの指示を磨く作業と、AIが仕事するために必要な情報環境を整える作業は別だ。後者は、ドキュメント整備、アーキテクチャの可視化、ドメイン知識の構造化といった地味な仕事を含む。でもここをサボると、モデルをどれだけ強くしても出力が安定しない。
次の論点としては、組織文化との衝突がある。Agentic Engineeringは、仕様の明確さ、テストの存在、責任範囲の定義といった「もともとできていなかったこと」を突きつけてくる。技術的な問題ではなく、組織設計の問題として扱わないと、ツールを導入するだけで終わる。
まとめ
AIがコードを書けることと、仕事を任せられることは別の話だ。
Vibe Codingは探索・試作に合理的な手法で、Agentic Engineeringはそれを否定せず、継続運用のための構造を足す考え方だ。どちらが優れているという話ではなく、目的に応じた使い分けの問題だ。
実装が速くなるほど、何を作るか・どう確かめるか・人が何を判断するかが重要になる。エンジニアリングの重心が実装から仕様・設計・検証へ移っているのは、AIが賢くなったことの自然な帰結だ。
自分のプロジェクトに置き換えて考えてみると、どこがボトルネックになっているか見えてくるはずだ。モデルの性能か、仕様の明確さか、検証の仕組みか——その答えが、次に何に投資すべきかを教えてくれる。
参考元: 【Build With Google Day 1 2026 #1】AIがコードを書ける、その先へ——Agentic Engineeringとは何か
