AI駆動開発の実践例
AI駆動開発における開発自動化 ～人を待たせない仕組みのつくり方
［第3回］エージェントの作業をどこで止め、何を人が判断するのか
2026年10月9日 09:00
第1回ではボトルネックが実装から検証・意思決定へ移ったこと、第2回では仕様のマスターがドキュメントから動くソフトウェアへ移ったことを扱いました。
開発自動化の仕組みを設計するとき、避けて通れないのが「エージェントの作業をどこまで進め、どこで止め、何を人に判断させるか」という線引きです。この問いは「どの変更で人の確認を待つべきか」「人が途中から関わるには何が必要か」の2つに分解して考えましょう。
毎回の承認を待つ設計はやめる
安全策として、実装プランの先頭に承認ステップを置きたくなります。しかしこれは高い確率で失敗します。すぐ応答できる人がいなければ、エージェントは最初のステップで止まったままですし、人がいても承認のたびに開発は停滞します。第1回で触れた「人の判断がボトルネックになる」問題を、仕組みの側が助長してしまうわけです。
かわりに、実装役とレビュー役のエージェントが自律的に修正と検証を繰り返す形にします。人は毎回のやり取りを中継せず、少し離れた場所から途中経過を見守り、必要なときだけ関わる。「Human-on-the-loop」と呼ばれるアプローチです。
ただし、承認ステップを外すだけではこの形になりません。「自分のPCを占有させない」「作業を途中で受け渡せる」「人の確認が必要な変更を確実に止める」。この3つが揃って初めて、人は見守る側に回れます。
まず、自分のPCを占有させない
ローカルPCでエージェントを動かすと、動作中はその環境が占有され、人は別の開発ができません。Gitのworktreeでディレクトリを分けても、DBのポートやプロセスの競合までは防げません。
実行はクラウド上の使い捨て環境に移しましょう。タスクごとに独立したコンテナが立ち上がり、終わると破棄される形にすれば、どれだけ並行させても自分のPCは空いたままです。実行環境の置き場所は運用の都合に見えますが、人が本当に手を離せるかを決める境界線です。
作業を途中で受け渡せるようにする
「設計は人間、実装はAI」のように役割を固定せず、書きかけのコードを双方向にいつでも受け渡せる状態にしておきます。
人からエージェントへは、Issueや作成途中のPRへのコメントから作業を渡せるようにします。しかし、ここで1つ落とし穴があります。実行中のコメントを「割り込み指示」として実装役だけに渡すと、実装役は最新指示に従い、レビュー役は「仕様にない」と却下する食い違いが起きます。コメントはすべて仕様そのものに取り込み、実装役とレビュー役が常に同じ要求定義を参照する形にしておきましょう。
逆方向も同様です。検証が終わる前からDraft PRとしてコードを逐次公開し、処理が途中で止まっても、差分はリモートブランチに残す。続きを自分で書くか、コメントを1行足してエージェントに再開させるか。この主導権は人の側に残し、自動再開はさせません。
人の確認が必要な変更だけを止める
人が常に見張る必要があるなら、手を離せたとは言えません。変更の性質に応じて、対応を3つに分けます。
- 固定する：テストの合否基準やエージェントの制御設定（書き換え不可にする）
- 止める：取り消せない変更（人の確認まで進行をブロックする）
- 知らせる：残りすべての変更（通知・共有にとどめる）
「固定する」は、エージェント自身による書き換えの防止です。「テストを通す」だけをゴールにすると、バグを直す代わりにテストコードを書き換える余地が生まれます。CI設定やAGENTS.mdのような指示書は、プロンプトで頼むのではなく、仕組みの側で書き換えを遮断します。
「止める」の対象は取り消せない変更です。DBマイグレーション、認証・決済、インフラ定義などに触れた差分は、テストが通っていても人の目視確認まで進めません。取り消しが容易な変更はまず通し、問題があれば後から直します。
残りはすべて「知らせる」だけにします。危なそうな場所を片っ端から禁止すると、依存ライブラリを1つ足すような正当な修正でも拒否され、エージェントが足踏みします。妥当性は文脈からしか判断できず、パスの拒否ルールでは区別できません。通した上で、変更した事実を人とレビュー役に提示すれば、うまく機能します。
言葉にできた分しか渡せない
最終的には「エージェントにどんな判断基準を渡すのか」という問いに行き着きます。
レビューで何を指摘すべきか、どの振る舞いをテストで固定すべきか、PRの粒度をどうするか。どれもソフトウェアエンジニアリングの作法そのものですが、これまでは暗黙知のままで済んでいました。その共通経験を持たないエージェントには、チームが期待することを言葉にして渡す必要があります。
新しい規律を一から作る必要はなく、感覚でやっていたことを機械が実行できる形に書き出すだけです。ただし書き出してみると、「何を良い変更とみなしていたのか」が曖昧だった部分が次々と浮き彫りになります。一番時間がかかるのは、おそらくそこでしょう。
まとめ
開発自動化とは、その基準を言葉にし、人が毎回の修正に立ち会わなくても進む仕組みを作る作業です。自分のPCを占有させず、必要なときに途中から関わり、確認が必要な変更だけを止める。その条件がそろって、ようやく人は安心して手を離せます。
次回は、これを支える「テスト」を扱います。
著者プロフィール：藤崎 優樹
大阪工業大学大学院で深層強化学習の研究に従事し、2023年にARISE analyticsにデータサイエンティストとして入社。機械学習を用いた大規模レコメンドシステムのシステム開発やデータ分析、社内生成AIアプリ開発やtoC向けWebシステム開発に従事。2025年10月よりAlgomaticにて製造業向けのAIエージェントPoCやシステム開発にAIエンジニアとして参画。
・株式会社Algomatic：https://algomatic.jp/
