夜航ワークフローには、回避できない納品条件がある。selftestが全件通過しない限り、そのタスクは納品できない。
この制約によって、AIによるコーディング支援を、無人状態でも実行可能な開発工程へ拡張している。夜間に実行し、翌日に検収するこの循環を「夜航」と呼ぶ。
夜航ワークフローの構成
夜航は自律開発の循環である。実行前に、作業目標と優先順位を記載したタスク指示書を渡す。AIは、作業が完了するか、人の判断を必要とする問題が生じるか、停止指示を受けるまで、次の手順を継続する。
- タスクの読み取り：指示書を読み、具体的なタスクを一つ引き受ける;
- 実装：コードを記述するか、システムを変更する;
- L1テストゲート：数百件のアサーションを実行し、一件でも失敗すれば自動的に差し戻して修正する;
- L2対抗レビュー：テスト通過後、別のAIが反証を目的として変更を検査する;
- 統合と報告：変更を統合し、新規内容をプレイ可能なビルドから直接検証できる状態にして、納品報告を送る;
- 次の循環：指示書にある次の作業へ進む。
テストゲートの中心的な役割
無人開発の主なリスクは、新しい変更が既存の規則を気づかれないまま損なうことである。
テストゲートは継続的な監視を担う。数百件のアサーションが、体勢崩しの受付時間、篝火のセーブ、強化式など、ゲーム内の重要な動作を固定する。いずれかが失敗すれば、そのタスクは自動的に差し戻され、納品段階へ進めない。テストゲートはモデル自体の判断能力を高めるものではなく、未検証の成果が主要工程へ入ることを制限する。
自動テストの後に行う対抗レビュー
テストだけでは、実際の現象が正しいことを保証できない。アサーションの通過は、問題の消失と同義ではない。 実際に、画面上の不具合が残っているにもかかわらず、テストが通過した事例があった。調査すると、そのアサーションは「何も発生しなかった」ことだけを検証しており、その状態自体が誤りであっても通過できる設計だった。
そのため、テストの後に対抗レビューを置いている。統合前に、別のAIが提案を誤りと仮定し、それを覆す反例を積極的に探す。低リスクのタスクには一人、高リスクのタスクには独立した二人のレビュー担当を配置する。問題を再現できず、提案を合理的に反証できなくなった段階で、変更を次へ進める。
夜間タスクの納品内容
翌日の夜航レポートには、夜間に完了したタスク、実行したテスト数、統合済みの変更、人の判断を待つ問題が記載される。私の作業は、結果の確認、未決事項の判断、次の指示書の作成に集中する。
結論
「自動で実行できること」と「無人状態での実行に適していること」は、異なる基準である。後者は抽象的な信頼ではなく、明確なタスク境界、テストゲート、対抗レビューに依存する。自動テストが回帰リスクを制御し、対抗レビューが判断上の盲点を補う。両方が成立して初めて、夜間の自律開発を安定して運用できる。