AIコーディングエージェントに「この機能を作って」と頼むと、コードを調べ、編集し、コマンドを実行し、テストまで進めてくれるようになりました。
この体験は便利です。しかし本番の開発では、動くコードが出たことだけで完了にはできません。
- 仕様にない振る舞いをAIが補っていないか
- テストされていない境界条件はないか
- AIが触れてよいデータ・環境だけを触っているか
- 失敗したときに、どこで止まり、誰へ引き継がれるか
- 後から、なぜその変更を承認したのか説明できるか
これらを扱う考え方が Agentic Engineering です。これは「プロンプトをうまく書く技術」ではなく、AIエージェントが安全に仕事を続けられる開発システムを設計する仕事です。
本記事は、2026年8月に開催された坂本一憲氏の講演「AIエージェントによるソフトウェア開発の最前線 ― Vibe CodingからAgentic Engineeringへ」で紹介された実験と論点を、実務でAIエージェントを導入する技術者向けに整理したものです。
「答えるAI」から「作業するAI」へ、何が変わったのか
初期の生成AIは、エラー文を貼り付けて原因や修正案を尋ねる相談相手でした。その後、IDEの補完や選択範囲の書き換えをするコーディング支援へ進みました。
現在のコーディングエージェントは、目的と作業環境を渡すと、次の流れをある程度自力で回せます。
リポジトリを読む
↓
関連コードと仕様を探す
↓
実装・修正する
↓
テスト、型検査、ビルドを実行する
↓
失敗ログを読んで直す
↓
証拠とともに結果を報告する
人間の仕事が消えるわけではありません。むしろ重心が変わります。
| 従来、人間が主に担ったこと | エージェント時代に人間がより強く担うこと |
|---|---|
| 実装を一行ずつ進める | 目的、制約、完了条件を決める |
| 手元でコマンドを実行する | AIが使えるツールと権限を設計する |
| 目視で動作を確認する | 評価器、承認、停止、復旧を設計する |
| 個別の修正を指示する | 証拠を確認し、責任を持って判断する |
講演の主題も、モデルがどれだけ賢いかではなく、「何を頼むか、何を見せるか、どの環境で働かせるか、どう反復させるか」にありました。イベント告知でも、Context / Harness / Loop Engineering、複数エージェントのオーケストレーション、レビュー・検証・責任が扱われると明示されています。
Vibe Codingは速い。ただし「正しい」を保証しない
Vibe Codingは、自然言語で「こんなものを作りたい」と伝え、動いた画面を見ながら直していく開発スタイルです。
文化祭の電子チケット管理アプリを作ってください。
高校生がスマートフォンで使います。
残高を大きく表示し、使用履歴も見せてください。
試作、要求探索、個人用の小さな自動化には非常に強力です。利用者が画面を見てから「履歴も必要だ」「このボタンは要らない」と気づけるからです。
一方で、動いたことと正しいことは別です。
- ある入力だけで処理が壊れる
- 権限チェックが漏れる
- 複数人の同時操作でデータが壊れる
- 修正により別の機能が壊れる
- 本番データや秘密情報に触れてしまう
失敗の損失が小さい場面では、Vibe Codingで早く学ぶ価値があります。本番システムへ進めるなら、そこで得た要求を、検証可能な仕様・テスト・権限設計に変換する必要があります。この後半を担うのがAgentic Engineeringです。
Agentic Engineeringを4層に分けると、失敗原因を切り分けやすい
講演では、AIエージェントの開発環境を次の4層として説明していました。
| 層 | 問い | 主な成果物 | 典型的な失敗 |
|---|---|---|---|
| Prompt | 何を頼むか | 目的、入出力、制約、完了条件 | AIが不足仕様を推測する |
| Context | 何を見せるか | 現行仕様、設計書、規約、Decision Log | 古い・足りない情報で判断する |
| Harness | どの道具と制約で働くか | CLI、テスト、CI、権限、ログ、承認点 | 自己申告だけで終わる |
| Loop | どう反復し、どこで止めるか | トリガー、再試行、引き継ぎ、停止条件 | 同じ誤解を繰り返す、終わらない |
4層は流行語の置き換えではありません。障害を「プロンプトが悪い」で片付けず、どの設計が欠けているかを探すための地図です。
Prompt: 書かれていない仕様は、モデルの性能では埋まらない
講演で紹介された小規模実験では、「おやつ注文アプリの合計金額を返す関数」を、曖昧な依頼と詳細な依頼で比較しました。
曖昧な依頼は次の程度です。
おやつ注文アプリの合計金額を返す関数を実装して。
これでは、税率、クーポン形式、端数処理、空注文、最終金額の下限が分かりません。AIは止まるとは限らず、もっともらしい仕様を選んで実装します。その「親切な補完」が、業務仕様との不一致になります。
講演での外部テスト8件の比較では、曖昧な条件は2モデルとも1件しか通らず、入力・税・クーポン・丸め・例外・完了条件を明示した条件では両モデルが8件通過したと報告されました。これはモデルの一般的な性能順位を示す実験ではありません。同じ課題・同じ評価器の範囲では、仕様の明示が大きく効いたという結果です。
依頼は長文化するより、判断に必要な情報を構造化します。
## 目的
管理者が在庫不足の商品を確認できるようにする。
## 対象範囲
- `src/inventory/` と管理画面のみを変更する
- 認証基盤、決済、DBの既存テーブルは変更しない
## 入出力と業務規則
- 在庫数が `threshold` 以下なら「要補充」と表示する
- `threshold` 未設定時は 5 を使う
- 在庫数が負の値の場合は表示せず、エラーを記録する
## 完了条件
- 管理者以外は画面・APIともアクセスできない
- 境界値を含む受け入れテストが通る
- `npm run lint && npm run typecheck && npm test` が成功する
## 不明点
推測で実装せず、質問をIssueに記録して停止する。
ポイントは「AIに考えさせない」ことではなく、推測してよい余白と、必ず人間へ返す不明点を分けることです。
Context: AIに渡す情報は、量ではなく鮮度と導線で決まる
Contextは、その時点でAIが参照できる情報環境です。README、現行仕様、ADR、コーディング規約、DB定義、過去の意思決定、既存コードが含まれます。
講演では、仕様がない条件では作業が進まず、現行仕様が大量の会議メモ・旧仕様に混在する条件でも小規模課題では正答できた一方、整理された現行情報が最も望ましいという教訓が示されました。
「たくさん渡せば安心」ではありません。古い仕様や無関係な資料は、誤参照、コンテキスト消費、料金、遅延、調査時間を増やします。AIが読めることと、読ませるべきことは別です。
リポジトリには、少なくとも次の入口を作ると効果があります。
README.md # 起動・検証・全体像
AGENTS.md # AI向けの作業規則、禁止領域、実行手順
docs/current/ # 現行仕様だけを置く
docs/adr/ # 変更してはならない判断の背景
docs/archive/ # 旧仕様を現行資料から分離する
AGENTS.md に「どの検証を実行するか」「本番設定には触れない」「仕様不足ならどこに質問を残すか」を書くと、毎回プロンプトで繰り返さずに済みます。
Harness: AIの「確認しました」を、実行可能な証拠に置き換える
Harnessは、AIモデルの周囲にある実行環境です。ファイル操作、CLI、テスト、型検査、Lint、ビルド、スクリーンショット、ログ、ネットワーク制御、権限、承認ゲートを含みます。
AIに「自分で確認してください」とだけ頼んでも、コードを読み直して「問題ありません」と答えるだけかもしれません。同じ前提で作り、同じ前提で自己評価すれば、見落としは残ります。
必要なのは、AIの外側から返る信号です。
| 目的 | 外部から返す信号の例 |
|---|---|
| 構文・型の不整合を止める | formatter、lint、typecheck |
| 振る舞いを確認する | unit / integration / E2E テスト |
| 画面品質を確認する | ブラウザ操作、スクリーンショット、アクセシビリティ検査 |
| 依存関係を確認する | SCA、SBOM、脆弱性スキャン |
| 変更を追跡する | Git差分、CIログ、実行ログ、成果物URL |
講演の実験でも、要件だけの条件ではモデルごとの推測の偶然に成否が左右されましたが、受け入れテストを実行して通るまで修正するHarnessを渡すと、両モデルが全テストを通過したと紹介されました。
ただし、テストは真実そのものではありません。テストが間違っていれば、AIは間違った評価器に合わせてしまいます。Harnessの品質は、テストケースのレビュー、境界値、回帰テスト、評価対象外の明示まで含めて管理します。
Loop: 回数を増やすのではなく、独立した評価で反復させる
Loop Engineeringが扱うのは、1セッション内部の「観察→実行→観察」だけではありません。
Issueを受け取る
↓
実装エージェントが変更する
↓
テスト・静的解析を実行する
↓
独立したレビューエージェントが差分と仕様を照合する
↓
不合格なら修正へ戻す／不明点なら人間へ引き継ぐ
↓
証拠を残して、条件を満たした場合だけ完了する
講演の欠陥修正実験では、同じAIだけにレビューと修正を繰り返させると、最初の誤解を維持して結果が悪化する場合がありました。テストと、記憶を引き継がない独立レビューを組み合わせた条件では、見落としの回収が最も良かったとされます。
実装者とレビュー者を分ける目的は、AIを増やすこと自体ではありません。同じ仮説に引きずられない評価経路を作ることです。レビュー担当には、修正者の「できました」という説明より、仕様、差分、テスト結果を渡します。
ループには必ず停止条件も必要です。
停止条件の例
- 全必須CIが成功し、レビュー指摘が0件
- 同じ失敗が3回続いたら、人間へエスカレーション
- 変更ファイル数または実行時間が予算を超えたら停止
- 本番・秘密情報・データ削除が関わる操作は承認待ち
「テストが通れば完了」は、そのテストが見ている範囲でしか正しさを保証しません。停止条件には、評価器の届く範囲と届かない範囲を明記しましょう。
権限は「読める・書ける・公開できる」を分ける
エージェントの自動化効果は権限に依存します。しかし、ファイル編集の権限と、本番デプロイや顧客データ削除の権限を同じものとして扱ってはいけません。
最初は、次のように段階化するのが現実的です。
| 操作 | 初期の扱い | 拡大する場合の条件 |
|---|---|---|
| リポジトリと文書の閲覧 | 原則許可 | 秘密情報をマスクする |
| ブランチ上のコード編集 | 許可 | 変更対象パスを限定する |
| テスト環境での実行 | 許可 | ダミーデータ、ネットワーク送信先制限 |
| コミット・PR作成 | 条件付き許可 | CI結果と差分を添付する |
| 本番反映、DB変更、外部送信 | 人間承認 | 最小権限、ロールバック、監査ログ |
特に重要なのは、AIに権限を渡す前に、独立した停止手段を持つことです。予算上限、ネットワークの送信先制限、短命な認証情報、実行時間上限、ロールバック手順、監査ログをHarnessとLoopに組み込みます。
AIが速く書くほど増える「理解の負債」
検証が通っても、人間がシステムを理解しているとは限りません。
AIの生成速度が上がると、コード量と「人間が設計理由・依存関係・変更影響を説明できる範囲」の差が開きます。講演で触れられた理解の負債は、単なるドキュメント不足より深刻です。障害時に原因を絞れず、AIの説明を検証できず、誰も重要な判断を引き受けられなくなるからです。
完全な解決策はありませんが、負債を増やしにくくする実践はあります。
- 重要な変更には、目的・設計理由・代替案・ロールバックを残す
- 重要な不変条件をテストに落とす
- AIの変更には、参照した仕様と検証結果を紐づける
- 大きな変更を小さなPRに分ける
- 説明できない重要変更はマージしない
- 定期的に、生成コードではなく境界・依存・運用をレビューする
人間が「承認ボタンを押す人」だけになると、AIの出力品質を評価する能力自体が弱くなります。レビューの目的は、AIの文章を読み切ることではなく、組織が責任を持てる理解を維持することです。
明日から始める導入順序
最初から自律的な開発工場を作る必要はありません。失敗の影響が小さい変更で、次の順に整えると安全です。
- 対象を選ぶ: テスト環境で完結する小さなバグ修正や文書・テスト整備から始める。
- 完了条件を書く: 目的、対象外、例外、禁止事項、受け入れ条件をIssueに置く。
-
現行情報の入口を作る: README、
AGENTS.md、現行仕様、ADRを整理する。 - 評価器を先に用意する: lint、typecheck、テスト、ビルド、必要なら画面検証をCIで実行可能にする。
- 証拠を必須にする: AIの完了報告には、差分、実行コマンド、結果、未検証事項を含める。
- 権限を小さく始める: 読み取り→ブランチ編集→テスト環境→PR作成の順に広げる。
- 停止と引き継ぎを決める: 再試行上限、予算上限、承認地点、エスカレーション先を先に決める。
導入の成否を「生成行数」や「AIが何回動いたか」で測るのは危険です。手戻り、レビュー待ち、障害、未解決の仕様質問、証拠の欠落まで観測して初めて、工程全体が良くなったかを判断できます。
まとめ: 最も重要な成果物はコードだけではない
Vibe Codingは、アイデアを素早く形にし、要求を発見するための強力な方法です。ただし、本番品質を作るのは会話の巧さだけではありません。
- Promptで、AIが推測してはいけない条件を明文化する
- Contextで、現行かつ必要な情報へ確実に到達させる
- Harnessで、自己申告ではない検証信号と権限境界を与える
- Loopで、独立した評価、継続、停止、人間への引き継ぎを設計する
AIに実装を委任しても、仕様、評価器、権限、完了宣言、責任は委任できません。
これからの技術者が作るべきものは、コードそのものに加え、AIが間違いに気づき、危険な操作を止め、根拠を残して人間へ引き渡せる開発システムです。そこまでを設計して初めて、AIエージェントは速さだけでなく、再現性のある成果につながります。
作成日: 2026年8月10日