AIに仕様を考えてもらう。
Codexに実装してもらう。
別のCodexにPlaywrightのE2Eテストを書いてもらう。
ここまで分業できると、人間はAIの出力を次のAIへ渡すだけでも開発が進むように見えます。
ただ、実際に業務管理アプリを開発してみると、このやり方には危険があります。
間違った前提まで、そのまま次のAIへ流れてしまうからです。
現在は、
- ChatGPT Work：設計・仕様・指示整理
- 開発Codex：実装・修正
- テストCodex：Playwright E2Eテスト
- 画像AI：アイコン・画像作成
- 人間：採用・却下・質問・原因切り分け
という形で役割を分けています。
この記事では、実際の業務アプリ開発で使っているAI開発ワークフローと、AI同士を直接つながず人間を判断点として残している理由をまとめます。
現在のAI開発ワークフロー
大まかな構成は次のとおりです。
Work
設計・仕様・指示案
│
▼
人間
理解・質問・採用・却下・修正
│
┌────────────┼────────────┐
▼ ▼ ▼
開発Codex テストCodex 画像AI
実装 E2Eテスト アイコン・画像
│ │ │
└────────────┼────────────┘
▼
人間
実画面・ログ・DB・結果を確認
│
▼
必要ならWorkへ戻す
ポイントは、AIを分けていることよりも、
AIとAIの間で人間が判断していること
です。
Workの指示をそのままCodexへ渡すだけではありません。
Codexの完了報告をそのままテストCodexへ渡すわけでもありません。
人間が一度内容を理解してから次へ進めています。
Workで作った指示も、そのまま実行しない
Workでは、次のようなことを整理します。
- 何を変更するのか
- なぜ必要なのか
- 現在の仕様と矛盾しないか
- どこまで変更してよいか
- どこを変更してはいけないか
- 何を確認すれば完了なのか
ただし、Workが作った指示もそのまま実行しません。
まず読みます。
分からない部分があれば質問します。
変更範囲が広すぎれば絞ります。
必要性が分からない変更があれば理由を聞きます。
納得できなければ、指示そのものを作り直させます。
つまり、
Work
↓
指示生成
↓
そのまま実行
ではなく、
Work
↓
指示案
↓
人間が確認
├─ 採用
├─ 質問
├─ 修正
└─ 却下
↓
Codexへ実行指示
という流れです。
実装指示では「変更可能範囲」をかなり限定する
最近行ったPWA対応では、単に、
PWA化してください
とは指示していません。
実際には、次のような条件を先に固定しました。
- DEV環境だけを対象にする
- 本番側変更禁止
- 使用するPWAアイコンの実寸を実装前に確認
- サイズ不一致ならコードを変更せず停止
- 変更可能ファイルを限定
- 認証処理を変更しない
- PHPセッションを変更しない
- DBを変更しない
- Nginxを変更しない
- 業務画面を変更しない
- Service Workerで業務データをキャッシュしない
- POST、PHP、JSON、PDF、CSVをキャッシュしない
-
git add、commit、push、本番反映は禁止 - 最後に変更内容と検証結果を報告する
実装するAIに自由を与えないという意味ではありません。
今回の作業で自由に判断してよい範囲を先に決めています。
アプリ側では「ついでの修正」をさせない
AIは調査中に別の改善案を見つけることがあります。
たとえば、
共通処理へまとめましょう
ファイルを分割しましょう
将来使うためのカラムを追加しましょう
といった提案です。
必要なら採用します。
ただし、
「将来使うかもしれない」だけでは採用しません。
ファイルを増やせば管理対象が増えます。
DBカラムを増やせば、スキーマとテスト対象も増えます。
共通処理を変更すれば、今回修正する必要のなかった画面まで影響する可能性があります。
そのため、
見つけた改善点
≠
今回変更するもの
として分けています。
アプリ側では、変更範囲をできるだけ狭くします。
AIの提案は止めるだけではない
AIの提案を制限しているだけではありません。
良い案はかなり採用しています。
操作履歴
操作履歴自体を残す考えはありました。
しかし、
- 誰が操作したか
- いつ操作したか
- 何が変更されたか
- 取り消したか
- 再確定したか
- 後から操作の証拠としてどう表示するか
まで細かく設計するところは、AIの提案をかなり採用しました。
請求管理
請求書についても、
作る
だけではなく、
確認
↓
確定
↓
取消
↓
再確定
↓
送付
↓
送付履歴
という業務ステップの考え方には、AIからの提案を取り入れています。
つまり、人間の役割はAIの提案を止めることではありません。
AIに自分では思いつかなかったところまで考えてもらい、使うものを選ぶこと
です。
開発CodexとテストCodexを分ける
現在は、実装とE2Eテストを別のCodexで行っています。
Work
↓
開発Codex
↓
実装結果
↓
Work / 人間
↓
テスト指示
↓
テストCodex
↓
Playwright
同じAIへ、
これを実装してください
と依頼した直後に、
正しく動くかテストしてください
と任せる方法もあります。
ただ、実装したAIが自分の実装を前提にテストを組み立てる可能性があります。
テストでは、
実装内容ではなく仕様を確認したい
ので、役割を分離しています。
E2Eテストも場合によって分割する
テストも一つへ詰め込みすぎないようにしています。
たとえば案件・契約業務の場合、
- 案件を登録できる
- 権限制御が正しい
- 利用上限が正しい
- 作業明細で使用中の案件を削除できない
では、確認したい責務が異なります。
一つの長いE2Eシナリオにすると、
取引先登録
↓
案件登録
↓
作業明細登録
↓
削除制御テスト
↓
FAIL
となった場合、最後の削除制御だけを確認したいのに、その前段から毎回実行することになります。
cleanup対象も増えます。
一方で細かく分けすぎると、同じ前提データをテストごとに準備・後処理する必要が増え、実行時間やcleanupの負担も大きくなります。
もちろん、テストごとに独立したデータを作る方が適しているケースもあります。ここは対象とするシステムやテストの目的によって分けて考えています。
そのため現在は、
アプリは変更範囲を狭くする。
テストは確認範囲を明確にする。
という基準で考えています。
FAILをそのまま開発AIへ渡さない
ここは特に重要です。
PlaywrightがFAILしたからといって、
FAIL
↓
開発Codexへエラーを貼る
↓
修正
とはしません。
なぜなら、原因がアプリとは限らないからです。
可能性としては、
- アプリの不具合
- テストコードの不具合
- locatorの誤り
- テストデータの残留
- DB状態の想定違い
- 仕様理解の誤り
などがあります。
テスト結果だけを次のAIへ渡すと、原因が違うのにアプリを修正し始める可能性があります。
エラーログもAIが読み間違える
VS Codeのターミナルやブラウザに出たエラーを丸ごとAIへ渡すこともできます。
しかし、AIがログの重要箇所を取り違えることがあります。
たとえば、
大量のログ
↓
AIが一部分を原因だと判断
↓
修正
↓
別のFAIL
↓
またログ全部を渡す
を続けると、根本原因から離れていく場合があります。
そこで、人間側でも一定程度確認します。
画面上では登録済み
保存までは成功している
削除だけ失敗している
前回データが残っている可能性がある
といった事実を確認してからAIへ渡します。
完全に原因を特定する必要はありません。
どこが怪しいかという仮説を持って渡すだけでも、AIの調査開始地点が変わります。
SQLを直接確認した方が速い場合もある
DB状態が怪しい場合、AIとの会話を続けるよりSQLを確認する方が圧倒的に速いことがあります。
たとえば、
案件が削除できない
という問題なら、
その案件を参照しているデータが存在するか
をDBで確認できます。
その結果、
作業明細から参照されている
と分かれば、その事実をAIへ渡せます。
AIには、
削除できません。原因を考えてください
ではなく、
DBを確認したところ、この作業明細から参照されています。
アプリ側とテスト側のどちらを確認すべきか調査してください。
と渡せます。
AIを使うこと自体が目的ではありません。
その場で一番速く、正確で、安全な確認方法を使います。
情報を大量に渡せば精度が上がるとは限らない
AIへログ、コード、画面情報を大量に渡せば正確になるように思えます。
実際には、重要でない情報へ引っ張られることもあります。
そのため、
画面を見る
↓
ターミナルを見る
↓
必要ならコードを見る
↓
DBを見る
↓
確認できた事実だけを整理
↓
AIへ渡す
という方法を取ることがあります。
情報量より、確認済みの事実を渡すことを優先しています。
Gitの扱いもアプリ側とテスト側で違う
今回の開発環境では、本番とDEVが同じサーバー上にあります。
ディレクトリは分離していますが、本番とDEVには同名ファイルがあります。
そのため、変更ファイル名だけを見ると、
正しいファイルを修正した
ように見えても、実際には本番側だったという危険があります。
変更先は人間側でも確認します。
アプリ側
アプリを変更した場合、そのコードを開発サーバーへ反映しなければ実画面でテストできません。
そのためアプリ側では、
変更
↓
確認
↓
commit
↓
DEVへ反映
↓
テスト
になります。
ここでのcommitは、
完成した
という意味ではなく、
検証するための状態を作る工程
です。
テスト側
テストコードは異なります。
作成・修正途中ではその都度commitしません。
その区切りまでに必要なテストがPASSして初めてcommitします。
つまり、
アプリ側
テストするためにcommit
テスト側
PASSした区切りでcommit
という違いがあります。
AIの「修正しました」は完了条件ではない
開発Codexが、
修正しました
と返しても、それだけでは完了にしません。
変更ファイルを確認します。
変更箇所もざっと確認します。
そして最終的には実画面を見ます。
今回の業務管理アプリでは、
- 有償版・管理者
- 有償版・一般ユーザー
- 無償版・管理者
- 無償版・一般ユーザー
で表示や操作が異なります。
管理者では正常でも一般ユーザーでは壊れている可能性があります。
有償版では正常でも無償版の制限を壊している可能性があります。
AIの完了報告ではなく、実際の動作を確認します。
実機確認も残る
現在はPCだけでなく、iPhoneとiPadでも確認しています。
PWAとして公開することを考えると、今後はAndroid実機も必要だと考えています。
AIがコードを書けても、
実際の端末でどう表示され、どう操作できるか
を確認する作業は残ります。
AIを使うほど、人間が暇になるとは限らない
コードを書く作業はかなりAIへ任せられるようになりました。
その一方で、人間側では、
- Work
- 開発Codex
- テストCodex
- VS Code
- ブラウザ
- 実画面
- ログ
- DB
- 画像AI
などを見ることになります。
さらに複数ユーザー・複数契約状態の画面も確認します。
結果として、
書く仕事が減り、判断する仕事が増えました。
見る。
比較する。
疑う。
質問する。
採用する。
止める。
次にどこへ進むか決める。
今のところ、人間側はこちらの比重が大きくなっています。
AI同士はまだ直接つないでいない
AIエージェント同士を直接連携させ、実装からテスト、修正まで自動化する方向もあります。
現在の私は、そこまではしていません。
理由は単純です。
AIも間違うからです。
Workが間違った前提を作る。
開発Codexが指示を広く解釈する。
テストCodexが仕様を取り違える。
ログの原因を誤認する。
一つの誤りをそのまま次のAIへ流すと、誤った前提のまま処理が続きます。
そのため現在は、
AI
↓
人間が理解・判断
↓
AI
という区切りを残しています。
人間は情報を運ぶためにいるのではありません。
間違った前提を次へ流さないための判断点として入っています。
AIに任せる範囲は狭くしていない
ここまで書くと、AIを信用せず作業を制限しているように見えるかもしれません。
実際には逆です。
以前よりAIへ任せる範囲は広がっています。
- 仕様案
- コード調査
- 実装
- 修正案
- テストコード作成
- E2Eテスト実行
- ログ調査
- 差分確認
- 画像作成
かなり任せています。
ただし、
- 何を作るのか
- 何を正しい状態とするのか
- どこまで変更してよいのか
- AIの提案を採用するのか
- FAIL時にどこを調べるのか
- 次にどのAIへ渡すのか
は人間側で決めます。
AIに任せることと、AIに自由に変更させることは別です。
まとめ
現在のAI開発ワークフローでは、AI同士を直接つないでいません。
Workで設計する。
人間が確認する。
開発Codexへ実装を任せる。
結果を確認する。
テストCodexへE2Eテストを任せる。
FAILしたら、人間も実画面・ログ・DBを確認する。
必要ならSQLで事実を確認する。
そのうえで、次にどこを直すのかを決める。
人間がすべてのコードを書く必要はなくなっています。
しかし、人間が何もしなくてよくなったわけでもありません。
人間はAI同士の間でコピペする係ではなく、何を採用し、何を止め、どこへ進むかを判断する役割です。
そして今のところ、
AIに任せる範囲を広げるために、人間が判断する場所を明確にする。
この形が一番扱いやすいと感じています。
今回のように、人間が変更範囲や確認方法を判断するようになった背景には、AIによる修正で、すでに正常だった機能が別の修正によって失われる経験がありました。
この状態を、前回のnoteでは**「破壊的修正ループ」**と呼び、なぜ起きるのか、どうすれば以前の正解を守りながら修正を進められるのかをまとめています。
関連記事（note）
設計しても、AIは前の正解を守ってくれない。