AIエージェントに開発を任せる話を聞くと、「完全自動でサービスが完成する」ような印象を受けることがあります。
しかし、実務で最初に目指すべきなのは、そこではありません。
中小企業にとって現実的なのは、寝ている間や移動中に、AIが小さな改善を進め、翌朝にはレビューできるPR候補ができている状態です。
本番反映、顧客送信、契約、決済、重要なDB操作は人間が見る。一方で、調査、修正案、テスト、レポート、PR候補まではAIに進めてもらう。
この分け方にすると、AIエージェントは危ない自動運転ではなく、業務を前に進める夜間スタッフになります。
完全自動開発ではなく、半自律開発ラインにする
完全自動開発という言葉は魅力的ですが、業務では危険です。
なぜなら、開発にはコードを書く以外の判断が多いからです。
- その変更を本当に入れるべきか
- 既存顧客への影響はないか
- サービス説明と矛盾しないか
- 料金、提供範囲、法令、セキュリティに触れていないか
- 本番反映してよいタイミングか
ここまでAIに丸投げすると、速くなる前に怖くなります。
最初は、AIに「完了」まで任せるのではなく、「人間が判断できる差分」まで任せます。
つまりゴールは、こうです。
人間の指示
↓
Codexが1タスクだけ実行
↓
テスト・チェック
↓
REPORT.mdに結果を記録
↓
draft PRまたはレビュー用差分
↓
人間が採用・修正・却下を判断この形なら、AIの速度を使いながら、会社としての判断は人間が持てます。
最小構成は4つでよい
最初から複雑な仕組みにする必要はありません。
半自律開発ラインの最小構成は、次の4つです。
1. TODO.md
これからやることを置くファイルです。
AIには、上から順に未完了タスクを1つだけ進めてもらいます。
大事なのは、1回の実行で複数タスクを詰め込まないことです。対象が広すぎると、差分も検証も読みにくくなります。
2. REPORT.md
実行したこと、変更したファイル、テスト結果、未解決事項を書かせます。
AIがうまく進めたかどうかは、最終成果物だけでは分かりません。どこを見て、何を変更し、どこで迷ったかが残っていると、翌朝のレビューがかなり楽になります。
3. DECISION.md
人間が決めたことを残します。
たとえば、「本番DBは触らない」「無料診断に面談を含めない」「このページのレイアウトは変えない」のような方針です。
AIは過去の判断を忘れます。だから、毎回の会話ではなく、短い決定ログにしておく方が強いです。
4. sandboxブランチまたはworktree
AIの作業場所は、本流から分けます。
小さな修正なら通常のブランチでも構いません。未コミット変更が多い場合や複数作業を並行する場合は、worktreeで分ける方が安全です。
目的は、AIが失敗しても戻せる場所で動かすことです。
Codexで組む場合の基本ループ
Codexを使う場合、最初は次の流れが扱いやすいです。
1. 人間がTODO.mdに小さなタスクを書く
2. Codexに「未完了タスクを1つだけ進める」と指示する
3. Codexが実装、テスト、チェックを行う
4. CodexがREPORT.mdに結果を残す
5. 差分を人間が確認する
6. 問題なければPR化する慣れてきたら、Codexの定期実行や codex exec を使って、決まった時間に同じ確認を走らせることもできます。
ただし、定期実行の最初のゴールは「勝手にmergeすること」ではありません。
良い自動化は、具体的で、繰り返せて、レビューしやすいものです。CodexのAutomationsでも、まずは会話で期待する出力を固めてから定期化するのが自然です。
最初に任せやすいタスク
半自律開発ラインの最初の題材は、失敗しても影響が小さく、レビューしやすいものにします。
向いているのは次のような作業です。
- LPの文言修正
- 管理画面の小さなUI改善
- テスト追加
- 型エラーやlint警告の整理
- READMEや運用手順の更新
- 重複コードの小さな整理
- 既存チェックコマンドの失敗原因調査
逆に、最初から任せない方がよいものもあります。
- 本番DBの更新
- 顧客情報を含む処理
- 認証・決済まわりの変更
- 料金や契約条件の確定
- ファイル削除
- 本番デプロイ
- 外部公開やメール送信
AIに任せる範囲を狭くすると、かえって使える場面は増えます。止めるべき場所がはっきりするからです。
停止条件を先に書く
自律化で一番大事なのは、成功条件より停止条件です。
たとえば、次の条件に当たったら作業を続けず、REPORT.mdに書いて止まるようにします。
停止条件:
- テストまたはビルドが失敗した
- 想定外のファイル変更が出た
- 秘密情報や顧客情報らしき文字列を見つけた
- 本番DB、本番デプロイ、外部公開、pushが必要になった
- 料金、法令、外部サービス仕様など未確認の事実に触れた
- 1つのタスクで複数機能に広がり始めた
- 同じ失敗が3回続いたこの停止条件があると、AIは無理に走り続けず、レビュー待ちに切り替えられます。
指示文は短くても、境界線は具体的にする
Codexに渡す指示は、長い小説のように書く必要はありません。
ただし、やってよいこと、やってはいけないこと、出力形式は具体的にします。
TODO.mdの未完了タスクを上から1つだけ進めてください。
やってよいこと:
- 関連ファイルの確認
- 必要最小限の修正
- 対象チェックコマンドの実行
- REPORT.mdへの追記
やってはいけないこと:
- 本番デプロイ
- push
- ファイル削除
- 顧客情報の外部送信
- TODO.mdにない大きな設計変更
停止条件:
- テスト失敗
- 想定外ファイルの変更
- 外部公開や本番操作が必要
- 判断に迷う仕様変更
完了時:
- 変更ファイル
- 実行したチェック
- 残リスク
- 人間が見るべき点
をREPORT.mdに追記してください。このくらい決めるだけでも、AIの動きはかなりレビューしやすくなります。
PR候補まで自動化する時の注意
次の段階では、AIが作った差分をdraft PRにすることもできます。
ただし、PR化する場合も、権限は分けた方が安全です。
AIが直接広い権限でpushするのではなく、差分を作る処理と、PRを開く処理を分けます。CI上で動かす場合も、AIが動くジョブには読み取り中心の権限を与え、PR作成は別ジョブにする方が扱いやすいです。
大事なのは、AIが「会社として採用された変更」を作るのではなく、「人間が採用判断できる候補」を作ることです。
この一線を越えなければ、自動化の恐怖感はかなり下がります。
小さく始める3週間プラン
導入は、3週間くらいで試せます。
1週目: 手動で3回試す
TODO.md、REPORT.md、DECISION.mdを作り、人間がCodexに1タスクずつ依頼します。
この段階では定期実行しません。AIに任せやすい粒度、止まりやすい条件、レポートの読みやすさを確認します。
2週目: 夜間チェックにする
毎晩または週数回、未完了タスクがあるかを確認し、実行結果をREPORT.mdに残す形にします。
この段階でも、pushや公開はしません。
3週目: draft PR候補にする
テストが通り、差分が小さく、停止条件に当たらないものだけ、draft PR候補にします。
人間は朝、REPORT.mdと差分を見るだけで済みます。
まとめ
AIエージェント開発で最初に目指すべきなのは、完全自動ではありません。
まずは、寝ている間にPR候補まで進める半自律開発ラインを作ることです。
TODO.mdで未来を管理し、REPORT.mdで過去を記録し、DECISION.mdで判断を残す。作業場所はsandboxブランチやworktreeで分ける。失敗3回、本番操作、外部公開、顧客情報、未確認事実に触れたら止める。
この形なら、AIの速度を使いながら、人間の責任あるレビューを残せます。
AI活用をどこから始めるべきか迷っている場合は、まず AI活用診断簡易版（無料） で、既存業務のどこがAIパッケージ化しやすいかをご確認ください。より具体的に整理したい場合は、詳細版AI活用診断（¥5,500税込・MTGなし） で、AIパッケージ適合性、構成案、優先順位、費用前提を整理してお届けします。