Claude Code・Codexに「動作確認」まで任せる開発フロー
Claude CodeやCodexにコード実装を依頼すると、変更やビルドまでは比較的スムーズに進みます。しかし画面を持つアプリの場合、ビルドが通っただけでは「完成」とは言えません。実際にアプリを起動し、操作し、録画し、ログで裏付けを取るところまでやって初めて、動作確認が完了したと言えます。
この記事では、Claude CodeやCodexに実装だけでなく、起動・操作・録画・ログ取得・証跡整理までを一つの開発フローとして任せる方法を紹介します。
デザイナーAIに開発から動作確認まで任せられるって、すごい時代になったね！具体的にどんなメリットがあるんだろう？
エンジニアうん、それにはいくつか重要なポイントがあるんだ。開発の効率と品質を同時に高めるためのアプローチだよ。
ビルド成功は「完了」ではない
多くの現場では「実装が完了しました」「ビルドに成功しました」という報告がそのままタスク完了として扱われがちです。しかし本来は次の3段階に分けて考える必要があります。
- 実装完了：コード変更・restore・Debug build・Release buildが成功している状態
- 検証完了：実装完了に加え、アプリ起動・操作・ログ取得・録画・証跡保存まで済んでいる状態
- タスク完了：検証完了に加え、受入条件を満たし、利用者が最終承認した状態
ビルド成功は、あくまで「動作確認に進める状態になった」だけであり、画面操作や視覚確認が必要なタスクではそれ単体で完了とは扱いません。
デザイナーなるほど、ビルド成功はスタート地点に過ぎないんだね。よくある勘違いかもしれない。
エンジニアそう、特にユーザーに触れる部分は、きちんと動くかどうかの確認が必須だからね。この段階分けが重要なんだ。
実装前に「保護baseline」を作る
画面やアニメーションを変更する場合、変更前の状態が分からないと改善したのか悪化したのか判断できません。そこで実装前に、現在のコミットID・git status・restore結果・Debug/Release buildの結果・変更前のスクリーンショットや録画などを記録しておきます。このbaseline自体のビルドが失敗している場合は、そのまま新しい実装には進みません。
デザイナー保護baselineって、変更前をしっかり記録しておくってこと？デザインでも「ビフォーアフター」は大事だもんね。
エンジニアまさにその通り！現状把握ができていないと、何をもって改善とするかが曖昧になるからね。これは品質管理の基本だよ。
Gateを通過するまで本実装に進まない
工程の境界に「Gate」を設け、次の条件がそろっているかをチェックしてから次の工程に進みます。
- 正本(仕様)が確定している
- 保護対象が明確になっている
- baselineのビルドが成功している
- 受入条件・証跡形式が決まっている
AIはコードを書き始めるのが速いため、準備が不十分でも先に進んでしまいがちです。だからこそ、Gate未通過の状態では実装を禁止するというルールを明記しておくことが重要になります。
デザイナーAIが速いからこそ、人間がしっかりガイドラインを示す必要があるんだね。「Gate」の考え方、プロジェクト管理でも使えそう。
エンジニアその通り。AIを効率的に使うには、人間が適切なプロセスを設計してあげるのが鍵だ。特に上流工程の準備は怠れないね。
Windows上の動作確認はAI自身に実行させる
以前は実装後に自分でアプリを操作・録画していましたが、現在はPowerShell、Python、UI Automation、Win32 APIなどを組み合わせ、AI自身がWindows上でアプリを起動・操作・録画・ログ取得までを行える環境を用意しています。座標だけに依存したマウス操作はウィンドウ位置やDPIの影響を受けるため、可能な限りウィンドウ位置やコントロールを特定してから操作させるのがポイントです。
デザイナーえ、AIが自分でアプリを操作して録画までしてくれるの！？まるでテストエンジニアみたいだね！
エンジニアそうなんだ。この自動化が開発フローのスピードアップと精度向上に大きく貢献している。人間が手動でやるよりもずっと信頼性が高いんだ。
録画・構造化ログ・フレーム抽出で証跡を残す
正式な録画では、録画開始前に対象アプリの状態や不要なウィンドウの有無などを確認する「preflight」を行い、録画開始→操作開始の順序を固定します。処理速度などの性能判定は録画のフレームではなく、アプリ側が出力する構造化ログを正とし、見た目やちらつきなどの視覚的な確認は録画から抽出したフレームで行う、というように役割を分けます。
さらに、失敗した確認結果も含めてattempt単位(attempt-01、attempt-02…)で証跡を保存し、コードを1行でも修正したら新しいattemptとして最初から確認をやり直します。こうすることで、どの問題がどの修正で解決したのかを後から追跡できます。
デザイナー証跡の残し方もすごく緻密なんだね。性能はログ、見た目は動画って役割分担も合理的！
エンジニアうん、多角的な視点で検証することで、より確実な動作確認を実現できるんだ。そして、問題発生時の原因究明も容易になる。
まとめ
Claude CodeやCodexに動作確認まで自走させるには、次のような工程を仕組み化しておく必要があります。
- 正本(仕様)を読む順番を固定する
- 実装前に保護baselineを作る
- Gateを通過するまで実装に進まない
- Windows上の操作・録画・ログ取得までAIに行わせる
- 性能は構造化ログ、見た目は動画とフレームで判定する
- 証跡はattempt単位で保存する
最終的な合否判定や仕様変更、マージやリリースの判断は人間が行うことに変わりありませんが、そこに至るまでの実行結果と証拠をAI自身にそろえさせることで、実装から動作確認までを一つの開発フローとして任せられるようになります。
