フォームのエラー表示をAIに直してもらうと、正常系の画面は案外すぐ整う。一方で、送信に失敗した直後の表示や再送信ボタンは、差分を見ないと抜け落ちたことに気づきにくい。そこで完成を待たず、途中で一度止めて画面の状態と変更ファイルを確かめたい。
最近のコーディングエージェントには、実行中の追加入力や割り込みを扱うものもある。ただし、止め方はクライアントや実行モード次第。「中断したから作業前の状態に戻った」とは考えないほうがいい。ここではReact/TypeScriptのフォーム変更を例に、停止、差分点検、再開を一つの作業手順にする。以下は説明用の例で、特定のリポジトリやエージェントで検証済みの結果ではない。
まず、AIに渡す仕事を小さくする
たとえばお問い合わせフォームの送信失敗時に、エラーメッセージが狭い画面でも読めて、入力内容を残したまま再送信できるようにする。対象のパスや検査コマンドは、実際のリポジトリを確認してから埋める。
対象: お問い合わせフォームと対応するテスト（実際のパスを記入）
確認する状態: 初期表示、入力エラー、送信失敗後の再送信
画面: 狭い幅でもエラー文が読めること。キーボードだけで再送信できること
変更しない: 認証API、デプロイ設定、新規依存
事前承認: 外部通信、依存追加、ロックファイル変更
渡さない: 本番トークン、実顧客データ
停止条件: 対象外ファイルの変更、想定外の通信・依存追加、状態の取りこぼし
完了条件: 差分レビュー、既存の型・テスト、手動の画面確認
このカードはプロンプトとして使える。ただし「変更しない」と書くだけではアクセス制御にはならない。実行環境で制限できる操作は別途制限し、承認が必要な操作は止めて人が判断する。最初から画面全体の作り直しを頼むより、直す状態を限定したほうが停止時の差分も読みやすい。
想定外の変更が見えたら、先に差分を見る
エラー文を直している途中で新しいパッケージが入った、あるいは失敗状態の表示が消えた。そういう時は、利用中のツールで追加入力を送るか、進行中の操作を止める。割り込みがどこまで効くかは製品・モードごとに確かめる必要がある。すでに完了した書き込みやコマンドの結果は、そのまま残りうる。
停止後は、まず作業ツリーを確認する。コミット済みの変更も含めて比較できるよう、作業ツリーを隔離し、開始コミットを控えておくと追いやすい。以下は同じシェルで作業を続ける例。別のシェルで点検するなら、控えたコミットIDをBASEに設定し直す。
# 作業開始前。変更が残っているなら、先に所有者と扱いを決める
git status --short
BASE=$(git rev-parse HEAD)
printf '%s\n' "$BASE" # このIDを控える
# エージェントを止めた後。同じシェルで点検する
git status --short
git diff --check "$BASE" # 空白などの差分エラーを確認
git diff --stat "$BASE" # 変更範囲をつかむ
git diff "$BASE" # 追跡対象の差分本文を読む
git diffに未追跡ファイルの中身は出ない。git status --shortで??が見えたら、そのファイルも別に開いて確認する。停止前に作られたファイルを、確認せず一括で削除・採用しない。git diff --checkも型検査や画面確認の代わりにはならない。
再開メモは「次の一手」が読めればいい
長い会話ログをそのまま再投入するより、停止時点の判断を短く残すほうが迷いにくい。既存の設計メモがある場合も、今回の仕様やレビュー結果と食い違えば、人が決め直す。
開始: BASE（コミットID）
現在: フォームのエラー表示を変更。未追跡ファイルの有無は別途確認
判断: 送信失敗後も入力値を保持し、再送信を許す
保留: 狭い幅での表示、キーボード操作、既存テストは未確認
次の操作: 失敗状態の画面だけを確認し、必要ならそこだけ直す
ここでいう「生成UI」が、AIにReactの画面コードを書かせる意味なのか、実行時にAIがコンポーネントを選んで描画する意味なのかも分けておきたい。後者なら、モデルに任せるコンポーネントの範囲とレンダリングの境界が追加の設計対象になる。使えるSDKや実装パターンを調べる際は、Generative UIのライブラリ・SDKと実装例のようなリソース集も入口になる。ただし、そのページはエージェントの停止やロールバックを保証するものではない。自分の画面で使う部品と権限は、リポジトリ側で決める。
完了判定はコード、画面、記録を混ぜない
再開後に「テストが通った」で終わらせると、エラー文の折り返しやフォーカス移動が残る。実際のpackage.jsonのscriptsを先に見て、存在する型チェック・テスト・lintを選ぶ。存在しないnpm run typecheckを記事の手順として固定しない。
# Node.jsプロジェクトのルートで、使える検査名を確認する例
node -p 'JSON.stringify(require("./package.json").scripts, null, 2)'
# 表示されたscriptsから該当する検査だけを実行し、結果を記録する
画面側では、初期表示、入力エラー、送信失敗、再送信の順に確認する。狭い幅でエラー文が欠けないか。Tabで操作できるか。再送信中の二重送信を防げているか。APIを叩くテストなら本番ではなくテスト用の失敗応答で再現する。見ていない状態には「未確認」と書く。
利用量のダッシュボードも品質判定とは分ける。GitHubは2026年10月、一部のCopilot SDK移行後のIDEでagent activityが正しく帰属されない問題を案内している。これはその計測経路の話であって、すべてのエージェントの利用量が欠けるという話ではない。PRの記録には使ったIDE・版と実行モードを添え、画面の合否は別に残す。
僕ならレビューの最後に、変更ファイルの一覧、止めた理由、まだ見ていない画面、再開時の次の操作を一度だけ読み返す。止めても続きを他の人に説明できるなら、そのPRはだいぶ扱いやすい。
参考
- Codex CLI releases：0.163.0の実行中追加入力・割り込みに関するリリース記述。全クライアントの動作を保証するものではない。
- GitHub Changelog: Update your IDE to restore agent activity in Copilot usage metrics：一部IDEの計測帰属問題。
- Qiita: プログラミング雑記 2026年10月5日：設計判断や継続性を考えるための補助的な参照。個別の動作仕様の根拠には用いていない。