AIコーディングを途中で止める条件｜試行の反復と範囲拡大を見逃さない

AIが作業を完遂できるかという予測で停止を決めると、担当者ごとに基準が揺れます。見るべき境界は、次の試行に新しい根拠があるか、依頼時に合意した目的・権限・要件の範囲に収まるかです。根拠を示せない、または合意範囲を越えた時点で自動続行を保留します。現在の成果を捨てる必要はありません。実装を進める役割から、条件を決める役割へ仕事を移します。

停止時には一枚の引継ぎ記録を作ります。依頼の目的と完了条件、該当した停止分類、変更差分、実行した確認、未決事項、試した方針、次の判断者を記載します。感想や自信度より、エラー、変更ファイル、チェック結果、求められた追加権限といった再確認できる事実を優先します。これがなければ、人に渡しても同じ調査が繰り返されます。

NISTのSecure Software Development Framework（SSDF）Version 1.1は、リスク、コスト、実現可能性、適用可能性を考慮し、実践を各組織向けに調整する出発点です。固定チェックリストとしての利用は意図されていません。この考え方に沿えば、全案件へ一律の試行回数や変更ファイル数を課すより、チームが根拠を説明できる状態で判定するほうが適します。以下の4分類はSSDFやGitHubの製品仕様ではなく、research.jsonで検証した一般原則をAI作業へ当てはめた運用例です。

同じエラーが再発しても、直ちに停止とは限りません。最初の結果から仮説が生まれ、次の確認で仮説同士を区別できるなら、試行には新しい情報を得る意味があります。ところが、表面的には別案でも同じ前提の微修正へ戻り、結果を受けても仮説が変わらないことがあります。この段階では、もう一度実行する根拠を説明できません。そこで保留します。

引継ぎ記録には、観測したエラー、試した方針、各方針で変わらなかった結果、推定した根本原因、未確認の仮説を分けて載せます。AIに解決案を追加させるより、技術判断を担う人がログや設計を読み直せる入口を整える場面です。SSDFのPW.7.2は、コードレビューや分析で見つかった問題と推奨修正をワークフローまたは課題管理システムへ記録してトリアージし、根本原因や教訓も文書化する実装例を示しています。

境界は失敗回数では測りません。「次の操作は、どの仮説を確かめるのか」と問います。答えと確認方法を示せれば続行できます。答えが従来案の言い換えにとどまるなら、失敗は検証から反復へ変わっています。記録を技術責任者へ渡し、原因の切り分け、設計変更、作業終了のどれを選ぶか判断してもらいます。

作業中に別の書込み先、シークレット、デプロイ権限が必要になったら、その取得と並行して実装を進めず、一度保留します。依存関係、認証、権限、ワークフロー自体の変更へ広がった場合も対象です。追加権限に合理的な理由があっても、作業を実行するAIが許可範囲まで決めると、実装と承認の責任が混ざります。

残す材料は、求める操作、対象、必要になった経緯、許可された場合の影響、許可しない場合の代替策、すでに生じた差分です。「権限不足」という要約だけでは、恒久的な許可が要るのか、設計変更で回避できるのかを判定できません。権限またはセキュリティの責任者が、限定承認、代替案、作業終了を選べる粒度にします。法人利用時の権限設計はClaude Codeのセキュリティ｜法人導入前に決める権限とデータ管理でも整理しています。

GitHubの公式ガイドは、依存関係、認証、権限、ワークフロー、機密データを扱う変更でセキュリティレビューが特に大切だと案内しています。この事実とSSDFのリスクベースの原則から、当初の許可範囲を越えた時点を別レビューへの切替条件にできます。これは権限を自動的に広げる合図ではありません。承認対象を明らかにして、決定権を持つ人へ渡す合図です。

受入条件が競合している、セキュリティ要件が未決である、要件を満たせない設計しか選べない。この状態でAIが妥当そうな案を採用すると、コードには一つの選択が固定されます。一方で、誰がどのリスクを受け入れたかは残りません。実装技術だけで解けないため、未決事項が差分へ埋め込まれる前に保留します。

記録するのは、競合する条件、確定済みの条件、選べる設計、各案で変わる影響とリスク、決定権を持つ担当です。AIの提案は候補として扱い、確定した受入条件とは区別します。SSDFのPO.1は、セキュリティ要件を把握できる状態にし、要件を特定・文書化・維持することを示しています。PW.2.1には、要件を満たせないときに設計またはリスク対応戦略を変更し、所見を仕様書や課題管理システムなどへ記録する実装例があります。

再開には、仕様責任者が確定した受入条件、またはリスク責任者が選んだ対応戦略を使います。単なる「確認済み」では、停止理由が消えたか分かりません。選ばれた条件と、それにより退けられた選択肢を同じ記録へ追記すれば、AIもレビュー担当者も共通の前提から作業を再開できます。

不具合修正から、無関係なファイル整理、依存関係の更新、認証・権限、ワークフローの変更へ差分が広がった場合は保留します。目的外の変更にも必要性はあり得ます。しかし同じ作業へ含め続けると、受入条件、レビュー担当、戻し方が異なる変更を一度に承認することになります。動作するかだけで続行を決める場面ではありません。

GitHubは、小さく目的を絞ったPull requestのほうがレビューしやすく、安全にマージしやすいと案内しています。変更が大きくなった場合は、単一目的の小さなPull requestへの分割を検討します。また、Draft pull requestは作業途中を正式なレビュー依頼前に共有でき、マージできない状態です。会話、コミット、チェック、変更ファイル、マージを妨げる要因もPull request上で確認できます。

Draft pull requestまたは引継ぎ記録には、元の目的に必要な差分、そこから外れた差分、チェック結果、分割後にも残る依存を示します。レビュー担当者は、元の目的へ戻す、別のPull requestへ分ける、設計から見直す、のいずれかを選びます。停止後の差分を通常のレビュー工程へ戻す方法は、AI駆動開発の開発フロー｜レビュー・テスト・CIで人の判断を残すと組み合わせると整理できます。

引継ぎ後の再開条件は4分類と対になります。失敗の反復には新しい仮説とそれを区別する確認、権限拡張には承認された対象と範囲、仕様未決には確定した受入条件またはリスク対応、変更拡大には分割後の目的と差分が必要です。担当者の了承だけを記すと、同じ迷いが作業中に戻ります。止めた理由を解消した証拠を残します。

運用場所は、チケット、Pull request、課題管理システムなど、チームがレビューできる既存の場所で構いません。プロンプトに停止条件を書くだけでは、検知後の責任者と記録先が曖昧です。テンプレートに停止分類、観測事実、現在の差分、必要な決定、判断者、再開根拠の欄を置けば、AIは検知と材料整理を担当でき、人は権限・仕様・変更範囲を承認できます。

エラーが続いたときは、次の試行が確かめる仮説を説明させます。説明できれば検証を続け、従来案の言い換えなら保留します。そこへ権限越境、未決仕様、単一目的からの逸脱という三つの境界を加えれば、AIコーディングの停止条件は実行可能な形になります。止めた時点の差分と事実を対応する判断者へ渡し、その決定が記録された後にだけ再開します。