Claude CodeやCodexに実装を依頼すると、コードの変更とビルドまでは比較的安定して進められます。

しかし、画面を持つアプリでは、ビルドに成功しただけでは完成とは言えません。

自分のプロジェクトでは、実装後に次の確認が必要でした。

実際にアプリを起動する
対象画面まで操作する
画面遷移や操作結果を録画する
処理時間をログで計測する
動画をフレーム単位で確認する
仕様書の受入条件と照合する
実行したソースと証跡を対応付ける

最初は、自分でアプリを操作して録画し、その動画をAIに渡していました。

ただ、それでは実装をAIに任せても、確認作業は人間側に残ったままです。

そこで現在は、Windows上で実行できる確認については、Claude CodeやCodex側でビルド、起動、操作、録画、ログ取得、フレーム確認まで行わせる形にしています。

この記事は、Windows上で動く画面付きアプリを対象に、自分のプロジェクトで実際に使っている運用を整理したものです。

Claude CodeやCodex単体ですべての画面操作や録画ができるという意味ではありません。PowerShell、Python、UI Automation、Win32 API、録画ソフトなどを組み合わせ、AIが操作できる実行環境を用意しています。

この記事で紹介する方法は、AIへ最終判断を任せるものではありません。

AIには実装、起動、操作、計測、録画、証跡整理までを担当させます。正式採用、仕様変更、マージ、リリースの判断は人間が行います。

結論

Claude CodeやCodexに動作確認まで自走させるには、次の工程を一つの流れとして定義しておく必要があります。

正本確認
↓
保護baseline確認
↓
Gate判定
↓
実装
↓
restore・Debug build・Release build
↓
アプリ起動
↓
録画前確認
↓
自動操作
↓
画面録画
↓
構造化ログ取得
↓
フレーム抽出
↓
受入条件との照合
↓
証跡整理
↓
最終Gate判定
↓
利用者による承認

重要なのは、「動作確認してください」とだけ依頼しないことです。

何を実行するか、何を記録するか、何をもって合格とするか、どの状態なら不合格とするかを、実装前に正本として定義します。

AIが実行結果を見てから、都合のよい合格条件を考える形にはしません。

ビルド成功は完了ではない

自分のプロジェクトでは、完了状態を次のように分けています。

実装完了
= コード変更が完了している
+ restoreが成功している
+ Debug buildが成功している
+ Release buildが成功している

検証完了
= 実装完了
+ アプリを起動している
+ 指定された操作を実行している
+ 構造化ログを取得している
+ 正式録画を取得している
+ 必要なフレームを確認している
+ 証跡が保存されている

タスク完了
= 検証完了
+ SPECとTESTの受入条件を満たしている
+ blocking事項が残っていない
+ 利用者が最終承認している

そのため、次の報告ではタスク完了にはしません。

実装が完了しました。
ビルドに成功しました。

ビルド成功は、実行確認へ進める状態になっただけです。

自動テストに成功していても、画面操作や視覚確認が必要なタスクであれば、それだけでは完了ではありません。

正本を読む順番も決めている

AIに複数の資料を渡すと、古い資料や途中経過を正しい仕様として扱うことがあります。

そこで、自分のプロジェクトでは、資料を読む順番も決めています。

AGENTS.mdまたはCLAUDE.md
↓
.ai-workflow配下の開発ルール
↓
資料地図
↓
SPEC
↓
PLAN
↓
TASK
↓
TEST
↓
REVIEW
↓
保護対象一覧
↓
現在の実装

現在の実装より、承認済みのSPECを上位に置きます。

実装とSPECが異なる場合に、現在のコードへ合わせてSPECを書き換えてはいけません。

現在の実装とSPECが違う
↓
現在の実装を正しいことにする
↓
SPECを実装へ合わせて変更する

この流れになると、不具合が仕様へ変わってしまいます。

既存資料に差異がある場合は、上位の正本に従います。

どちらが正しいか判断できない場合は、勝手に統合せず、BLOCKEDとして止めます。

現在の実装は、必ずしも正しい仕様ではありません。

不具合や未完成の処理が残っている可能性があるため、承認済みの正本より現在のコードを優先しないようにしています。

SPEC・PLAN・TASK・TEST・REVIEWを分ける

実装と動作確認を安定させるため、役割の異なる資料を分けています。

SPEC

何を実現するかを定義します。

画面の状態
操作可能になる条件
遷移の開始条件
遷移完了時の状態
表示してよい要素
表示してはいけない要素
処理時間の上限
対象外

PLAN

どこを変更し、どこへ影響するかを整理します。

変更対象
影響対象
変更しない範囲
確認対象
使用する計測方法
使用する録画方法
変更後に再確認する既存機能

TASK

実装と確認を、実行可能な単位へ分けます。

コード実装
ログ追加
自動操作
録画環境整備
フレーム抽出
受入確認
正本同期

一つのTASKにすべてを詰め込まず、必要に応じて段階を分けます。

例えば、画面遷移を変更する場合は次のように分けます。

TASK-XXX-01
仕様と完成条件の確定

TASK-XXX-02
コード実装とbuild

TASK-XXX-03
Windows上での自動操作と正式録画

TASK-XXX-04
フレーム確認と最終受入

TEST

第三者が見ても同じ操作を再現できる粒度で書きます。

前提条件
操作手順
期待結果
計測項目
必要な証跡
合格条件
不合格条件

REVIEW

実装担当の説明ではなく、正本と証跡を比較した結果を残します。

PASS
CONDITIONAL PASS
FAIL
BLOCKED
未実施
再承認待ち

未実施を合格に含めないことが重要です。

実装前に保護baselineを作る

画面やアニメーションを変更する場合、変更前の状態が分からないと、改善したのか悪化したのか判断できません。

そこで、実装前にbaselineを確定します。

最低限、次を取得します。

現在のブランチ
現在のコミットID
git status
working treeの状態
dotnet restore結果
Debug build結果
Release build結果
変更前スクリーンショット
変更前録画
使用Assetのチェックサム
実行環境

PowerShellで記録する場合は、例えば次のようにします。

$evidenceDirectory = ".ai-workflow\tasks\TASK-XXX\evidence\baseline"

New-Item `
    -ItemType Directory `
    -Path $evidenceDirectory `
    -Force |
    Out-Null

git status --short --branch |
    Out-File "$evidenceDirectory\git-status.txt"

git rev-parse HEAD |
    Out-File "$evidenceDirectory\commit.txt"

dotnet --info |
    Out-File "$evidenceDirectory\dotnet-info.txt"

dotnet restore *>&1 |
    Tee-Object "$evidenceDirectory\restore.log"

dotnet build `
    --configuration Debug `
    --no-restore *>&1 |
    Tee-Object "$evidenceDirectory\build-debug.log"

dotnet build `
    --configuration Release `
    --no-restore *>&1 |
    Tee-Object "$evidenceDirectory\build-release.log"

baselineのbuildが失敗した場合は、そのまま新しい実装へ進めません。

baseline自体が壊れている状態で変更を始めると、元からある問題と今回の変更による問題を分けられないためです。

Gateを通過するまで本実装へ進めない

自分のプロジェクトでは、工程の境界にGateを置いています。

例えば、最初のGateでは次を確認します。

正本が確定している
保護対象が明確になっている
baselineのbuildが成功している
変更前録画が取得できている
受入操作が定義されている
証跡形式が決まっている

これをGate 0としています。

Gate 0を通過していない状態で実装を始めると、後から次の問題が起きます。

どの状態から変更したか分からない
何をもって合格とするか決まっていない
必要な録画を取り直すことになる
実装後に仕様を追加することになる
変更してはいけない範囲まで変更される
現在の不具合を今回の変更で発生したものと誤認する

AIはコードを書き始めるのが速いため、準備が不十分でも先へ進みやすくなります。

そのため、Gate未通過時は実装禁止と明記します。

Gateは大げさな承認会議ではありません。

「次の工程へ進むために必要な条件がそろっているか」を、チェック項目として明確にしたものです。

実装担当とレビュー担当を分ける

実装したAIに、そのまま最終判定まで任せると、自分の変更を肯定する方向で判断することがあります。

自分のプロジェクトでは、実装とレビューの役割を分けています。

実装担当

承認済みSPECを読む
影響範囲を調べる
コードを変更する
restore・buildを実行する
ログを追加する
操作と録画を実行する
証跡を作成する

レビュー担当

原則としてコードを変更しない
SPECとTESTを読む
証跡を確認する
未実施項目を探す
動画を確認する
フレームを確認する
ログと動画を照合する
合否を判定する

レビュー時は、実装時の長い会話をそのまま引き継がない方が、確認が安定する場合があります。

別セッションには、必要な正本と証跡だけを渡します。

SPEC
PLAN
TASK
TEST
REVIEW
変更差分
build結果
構造化ログ
正式録画
抽出フレーム
実装担当の報告

実装担当の説明は参考情報であり、正本ではありません。

Windows上の確認はAI側で実行する

以前は、実装後に自分でアプリを起動し、画面を操作して録画していました。

現在は、Windows上でAI側が確認できる内容については、利用者へ録画を依頼する前に、AI側で実行させています。

実行手段は一つに限定していません。

PowerShell
Python
既存のテストコード
Win32 API
UI Automation
画面録画ソフト
フレーム抽出ツール

例えば、画面上のボタン操作であれば、次の方法を検討します。

キーボード操作で到達できるか
既存のショートカットがあるか
UI Automationで操作できるか
Win32 APIでウィンドウを特定できるか
マウス座標を固定して操作できるか

一つの方法が使えないからといって、すぐに人間へ操作を依頼しません。

ただし、座標操作だけに依存すると、ウィンドウ位置やDPIの影響を受けます。

可能であれば、ウィンドウの位置、サイズ、DPI、対象コントロールを特定してから操作します。

画面座標を固定したマウス操作は、最後の手段として使っています。

ウィンドウ位置、解像度、DPI、表示倍率が変わると、別の場所をクリックする可能性があります。

録画前のpreflightを独立させる

正式録画では、録画開始後の操作だけでなく、録画前の状態が重要です。

自分のプロジェクトでは、録画前確認をpreflightとして独立させています。

確認項目は次のようなものです。

対象アプリが起動している
対象アプリが前面にある
ウィンドウ位置が固定されている
画面解像度が固定されている
DPIが記録されている
不要なウィンドウが閉じている
AIのチャット画面が映り込んでいない
通知が無効になっている
録画ソフトが起動している
録画対象領域が正しい
マウスカーソルの初期位置が正しい
テストデータが初期状態になっている

このpreflight自体も、結果をログへ残します。

PRECHECK-01 PASS 対象アプリ起動済み
PRECHECK-02 PASS 対象アプリ前面表示
PRECHECK-03 PASS 録画領域1920x1080
PRECHECK-04 PASS DPI 100%
PRECHECK-05 PASS 不要ウィンドウなし
PRECHECK-06 PASS カーソル初期位置確認

録画が成功していても、関係のないウィンドウや外部オーバーレイが映り込んでいれば、正式証跡としては不合格にします。

実際に、機能自体は問題なくても、次の理由で正式録画を取り直したことがあります。

AIのチャット画面が映り込んでいた
対象外のオーバーレイが表示されていた
録画前にマウス操作が始まっていた
画面内に不要な文字が一瞬表示された
録画プロセスと操作開始の順番が不明確だった

「動いていること」と「証跡として成立していること」は分けて考えます。

録画開始と操作開始の順番を固定する

正式録画では、次の順番を固定しています。

対象アプリ起動
↓
対象画面へ移動
↓
preflight
↓
録画プロセス起動
↓
録画開始確認
↓
開始前の静止時間
↓
カーソル初期化
↓
自動操作開始
↓
終了状態を一定時間保持
↓
録画停止
↓
ファイル生成確認

録画プロセスを起動した直後に、操作スクリプトが先に進むと、冒頭部分が記録されないことがあります。

そのため、単に録画ソフトを起動するだけでなく、録画開始状態を確認してから操作を始めます。

また、操作終了直後に録画を止めると、最終状態が十分に残りません。

終了状態を数フレーム以上保持してから停止します。

正式動画を取得する

正式動画では、最低でも30fps以上で録画します。

ただし、30fpsで録画したからといって、必ず約33ミリ秒間隔でフレームが記録されるとは限りません。

PC負荷や録画処理の影響で、フレーム間隔が大きく空くことがあります。

そのため、録画後に次を確認します。

動画の開始時刻
動画の終了時刻
総フレーム数
平均フレーム間隔
100ミリ秒以上空いた区間
操作開始フレーム
遷移開始フレーム
遷移完了フレーム
最終状態の保持フレーム数

対象の受入条件で30Hz相当の確認が必要な場合、100ミリ秒以上の欠落が複数ある動画は、正式判定に使えない可能性があります。

動画が再生できることだけでは、録画品質の合格にはしません。

性能判定は構造化ログを正とする

画面遷移の速さを、録画だけで判定すると誤差が大きくなります。

録画ソフト側の遅延やフレーム欠落があるためです。

そこで、性能判定にはアプリ側の構造化ログを使用します。

例えば、画面遷移で次の状態を記録します。

TransitionRequested
FadeOutStarted
FadeOutCompleted
SceneSwitchStarted
SceneSwitchCompleted
FadeInStarted
InteractionEnabled
TransitionCompleted

ログには、最低でも次を含めます。

時刻
経過時間
状態名
フレーム番号
描画対象
操作可能状態
遷移ID

例です。

{
  "transitionId": "TRANSITION-001",
  "state": "FadeOutStarted",
  "elapsedMs": 120.4,
  "frame": 1842,
  "interactionEnabled": false
}

性能については、このログを正とします。

遷移開始から操作可能になるまで何ミリ秒か
各状態が何ミリ秒続いたか
状態の重複がないか
必要な終了状態が記録されているか

一方、次のような内容は動画と抽出フレームで確認します。

ちらつき
一瞬だけ出る不要な表示
前後画面のつながり
オブジェクトの急な出現
位置ずれ
不自然な拡大・縮小
フォーカス状態

役割は次のように分けます。

処理時間・状態遷移
→ 構造化ログ

見た目・操作感
→ 正式動画と抽出フレーム

動画は、見た目や操作順を確認するための証跡です。

ミリ秒単位の性能判定は、録画フレームではなく、アプリ側の構造化ログを基準にしています。

録画後はフレームを抽出する

動画を最初から最後まで人間が見るだけでは、一瞬の表示異常を見落とします。

そこで、録画後にフレームを抽出します。

操作前
操作開始
遷移開始
中間状態
画面切替直前
画面切替直後
遷移完了
操作可能状態
終了状態

画面遷移の品質確認では、必要に応じて全フレームを確認します。

例えば、遷移開始から完了までが1秒なら、30fpsの録画では約30フレームです。

30枚程度であれば、一覧画像を作り、前後のつながりを確認できます。

frame-0001.png
frame-0002.png
frame-0003.png
...
frame-0030.png

確認時は、単に画像を並べるだけでなく、構造化ログの状態と対応させます。

frame-0004
FadeOutStarted

frame-0011
SceneSwitchStarted

frame-0018
FadeInStarted

frame-0026
InteractionEnabled

これにより、「動画では違和感があるが、どの処理で発生したか分からない」という状態を減らせます。

使用したAssetのチェックサムを残す

画面背景や画像Assetが関係する場合、録画だけでは、どのファイルを使ったか特定できません。

そのため、正式証跡では、使用したAssetのチェックサムも残します。

Get-FileHash `
    ".\Assets\TransitionSource.png" `
    -Algorithm SHA256 |
    Format-List |
    Out-File ".\evidence\source-asset-hash.txt"

同じファイル名でも内容が変更されている可能性があります。

コミットID、ソース差分、Assetのチェックサムを残すことで、証跡と実行内容を対応付けられます。

証跡はattempt単位で保存する

動作確認に失敗した場合、修正して同じ録画ファイルを上書きしてはいけません。

自分のプロジェクトでは、確認をattempt単位で保存しています。

evidence/
├─ attempt-01/
│  ├─ environment.txt
│  ├─ commit.txt
│  ├─ git-status.txt
│  ├─ restore.log
│  ├─ build-debug.log
│  ├─ build-release.log
│  ├─ structured-log.jsonl
│  ├─ recording.mp4
│  ├─ source-asset-hash.txt
│  ├─ frame-analysis.csv
│  ├─ frames/
│  └─ execution-report.md
│
├─ attempt-02/
│  └─ ...
│
└─ attempt-03/
   └─ ...

attempt-01が失敗した後に修正した場合、attempt-02として最初から確認します。

コード修正
↓
restore
↓
Debug build
↓
Release build
↓
preflight
↓
録画
↓
操作
↓
ログ取得
↓
フレーム確認
↓
判定

修正後に、修正前のbuild結果や録画を流用しません。

失敗したattemptも残します。

失敗を消して成功した証跡だけを残すと、どの問題をどの修正で解決したのか分からなくなるためです。

コードを1行でも変更した場合は、変更前の録画やbuild結果を正式証跡として流用しません。

新しいattemptを作り、必要な確認を最初から実行します。

動作していても不合格にすることがある

自分のプロジェクトでは、画面上の動作自体は成立していても、次の理由で正式採用を不合格にしたことがあります。

録画開始後に想定外のカーソル移動が行われていた
preflightに対象外のウィンドウが混入していた
動画に外部オーバーレイが映り込んでいた
100ミリ秒以上のフレーム間隔が複数回あった
要求していた終了状態名がログに記録されていなかった
使用した画像のチェックサムが保存されていなかった

この場合、機能確認の一部は成功しています。

しかし、正式証跡として必要な条件を満たしていないため、PASSにはしません。

画面遷移が動いた
≠ 正式受入に合格した

確認結果は、例えば次のように分けます。

機能
PASS

性能
PASS

視覚品質
FAIL

録画品質
FAIL

証跡完全性
FAIL

総合判定
FAIL

これにより、「一部は成功しているが、正式採用はできない」という状態を正確に表せます。

正本は合格後に同期する

実装中や検証中に、SPEC・PLAN・TASK・TEST・REVIEWを都合よく書き換えると、途中経過と正式仕様が混ざります。

そのため、実装と受入が終わるまでは、承認済み正本を基準に確認します。

実装
↓
build
↓
録画
↓
ログ確認
↓
フレーム確認
↓
受入判定
↓
利用者承認
↓
正本同期

正式合格後に、必要な正本へ結果を反映します。

SPEC
PLAN
TASK
TEST
REVIEW
Asset対応表

例えば、TESTには次を記録します。

実測時間
正式動画の保存先
総フレーム数
確認したフレーム範囲
ログの保存先
Assetチェックサム
合否
残存課題

実装担当が、自分の判断だけで既存の承認状態を変更しないようにしています。

Claude Code・Codexへ渡す実行指示

実際の運用に近い形へ簡略化すると、次のような指示になります。

あなたは、Windows上の実リポジトリを調査・実装・検証する担当です。

今回の作業は、コード変更とbuild成功だけでは完了ではありません。

承認済みのSPEC、PLAN、TASK、TEST、REVIEWに従い、
実装後のアプリ起動、自動操作、画面録画、構造化ログ取得、
フレーム確認、証跡作成まで実施してください。

# 正本の読取順

次の順番で確認してください。

1. AGENTS.mdまたはCLAUDE.md
2. .ai-workflow配下のルール
3. 資料地図
4. SPEC
5. PLAN
6. TASK
7. TEST
8. REVIEW
9. 保護対象一覧
10. 現在の実装

下位資料と上位正本が異なる場合は、上位正本を優先してください。

現在の実装に合わせて、承認済みSPECを変更しないでください。

# 実装前確認

次を確認し、証跡へ保存してください。

- 現在のブランチ
- 現在のコミットID
- git status
- working treeがcleanか
- 保護baselineが存在するか
- dotnet restore
- Debug build
- Release build
- 使用するAssetのチェックサム

baselineのbuildに失敗する場合は、本実装へ進まずBLOCKEDとしてください。

# 実装

- 承認済みTASKの範囲だけを変更してください
- 保護対象を変更しないでください
- 対象外のリファクタリングを行わないでください
- TESTの期待値を実装へ合わせて変更しないでください
- 仕様変更が必要な場合は停止してください

# Windows動作確認

Windows上で確認可能な内容は、
利用者へ操作や録画を依頼する前に、あなた自身で実行してください。

PowerShell、Python、既存テスト、Win32 API、UI Automation、
画面録画ソフトなど、利用可能な手段を調査してください。

# preflight

正式録画前に次を確認してください。

- 対象アプリが起動している
- 対象アプリが前面に表示されている
- ウィンドウ位置とサイズが固定されている
- 解像度とDPIが記録されている
- 不要なウィンドウが映っていない
- 通知が無効になっている
- 録画領域が正しい
- 録画プロセスが起動している
- カーソル初期位置が正しい
- テストデータが初期状態である

preflight結果をログへ保存してください。

# 正式録画

次の順番を守ってください。

1. 対象アプリを起動
2. 対象画面へ移動
3. preflight
4. 録画プロセス起動
5. 録画開始確認
6. 開始前状態を保持
7. カーソル初期化
8. 自動操作
9. 終了状態を保持
10. 録画停止
11. 録画ファイル生成確認

録画開始前に対象操作を実行しないでください。

# 性能確認

性能判定は構造化ログを正としてください。

最低限、次を記録してください。

- 遷移ID
- 状態名
- 経過時間
- フレーム番号
- 操作可能状態
- 開始状態
- 終了状態

要求された状態名が不足している場合はPASSにしないでください。

# 視覚確認

正式動画からフレームを抽出し、
TESTで指定された範囲をフレーム単位で確認してください。

次を確認してください。

- ちらつき
- 不要表示
- 外部オーバーレイ
- オブジェクトの急な出現
- 位置ずれ
- 前後画面の不自然な切替
- 最終状態
- フレーム間隔

# 証跡

証跡は次へ保存してください。

.ai-workflow/tasks/TASK-XXX/evidence/attempt-XX/

既存attemptを上書きしないでください。

最低限、次を保存してください。

- environment.txt
- commit.txt
- git-status.txt
- restore.log
- build-debug.log
- build-release.log
- structured-log.jsonl
- recording.mp4
- frame-analysis.csv
- 抽出フレーム
- Assetチェックサム
- execution-report.md

# 判定

次のいずれかで判定してください。

PASS
- 必須項目をすべて実施した
- すべての受入条件を満たした
- 必要な証跡がそろっている
- blocking事項がない

CONDITIONAL PASS
- 必須機能は満たしている
- 残存事項が正式に許容されている
- 利用者の承認待ちである

FAIL
- 受入条件を一つ以上満たしていない
- 動画またはログから不具合が確認できる
- 正式証跡として成立していない

BLOCKED
- baselineが成立していない
- 実行環境が不足している
- 仕様が不明確で判定できない
- 必要な証跡を取得できない

未実施をPASSにしないでください。

build成功だけで完了にしないでください。

録画ファイルが存在するだけでPASSにしないでください。

# 正本同期

実装担当の判断だけで承認状態を変更しないでください。

利用者の最終承認後に、
SPEC、PLAN、TASK、TEST、REVIEWへ結果を同期してください。

# 最終報告

次の順番で報告してください。

1. 結論
2. blocking事項
3. 変更内容
4. build結果
5. TESTごとの結果
6. 構造化ログの実測値
7. 正式動画とフレーム確認結果
8. 証跡保存先
9. 未実施項目
10. 利用者が最終判断する項目

最初から完全自動化はできなかった

ここまで書くと、最初からすべて自動化できたように見えるかもしれません。

実際には、失敗するたびにルールを追加しています。

録画に不要な画面が入った
→ preflightへ対象外ウィンドウ確認を追加

録画開始前に操作された
→ 録画開始確認後に操作する順序を追加

見た目は正常だが時間が分からない
→ 構造化ログを追加

動画のフレームが飛んだ
→ フレーム間隔の検査を追加

どの画像を使ったか分からない
→ Assetチェックサムを追加

修正後に古い録画を使っていた
→ attempt単位の保存を追加

最初から大きな仕組みを作るより、実際に起きた失敗を短いルールへ変える方が運用しやすくなりました。

一度に完全なルールを作るのではなく、再発してほしくない失敗を一つずつ自動化や停止条件へ変えています。

人間の確認はなくならない

Claude CodeやCodexが、ビルド、操作、録画、ログ取得まで実行しても、最後の承認は人間が行います。

AIに任せる範囲は次です。

正本を読む
影響範囲を調べる
実装する
buildする
アプリを起動する
操作する
録画する
ログを取得する
フレームを抽出する
証跡を整理する
受入条件と照合する

人間が判断する範囲は次です。

仕様自体が妥当か
操作感を許容できるか
見た目の違和感を許容できるか
残存リスクを受け入れるか
正式採用してよいか
mainへマージしてよいか

AIが人間の判断まで代行するのではありません。

人間が判断できる状態まで、実行結果と証拠をそろえさせる形です。

まとめ

Claude CodeやCodexに動作確認まで自走させるために、自分のプロジェクトでは次を行っています。

正本の読取順を固定する
SPEC・PLAN・TASK・TEST・REVIEWを分ける
実装前に保護baselineを作る
Gate未通過なら実装へ進めない
Windows上の操作をAI側で実行する
録画前にpreflightを行う
録画開始と操作開始の順番を固定する
性能は構造化ログで判定する
見た目は動画とフレームで確認する
使用Assetのチェックサムを残す
証跡をattempt単位で保存する
実装担当とレビュー担当を分ける
利用者の承認後に正本を同期する

最終的に目指している流れは、次の形です。

仕様を読む
↓
実装する
↓
自分でbuildする
↓
自分でアプリを起動する
↓
自分で操作する
↓
自分で録画する
↓
自分でログを確認する
↓
自分でフレームを確認する
↓
証跡を整理する
↓
人間が判断できる状態で返す

コードを書かせるだけでは、確認作業は減りません。

確認方法、証跡形式、合格条件、停止条件までリポジトリ側に持たせることで、実装から動作確認までを一つの工程として任せられるようになりました。

関連記事

この記事で使用しているSPEC、PLAN、TASKや開発ルールについては、次の記事で整理しています。

今回の記事は、これらの考え方を、実装後のビルド、起動、操作、録画、ログ取得、証跡作成まで広げた内容です。