AI作業が止まっても再開するために、何を残すべきか

この記事は、2026年8月3–9日の設計文書、Git記録、障害記録をもとに書き直したHaru Spaceの開発回顧だ。非公開の会話、作業・スレッド識別子、ローカルパス、内部の実行構造、認証情報は含めていない。

AI作業が途中で止まったら、「もう一度実行」を押せばよいように思えた。しかし、実際のコード作業はそれほど単純ではなかった。

止まる前にファイルを変更していたのか。外部依存関係の承認を待っていたのか。承認後に戻る会話の文脈は、この作業のものなのか。その間にリポジトリの基準ブランチは変わっていないか。同じ依頼を新しく実行すれば、変更が重複しないか。

初め、私たちは継続性を「会話を長く覚えておく力」だと考えていた。一週間にいくつもの失敗を経験したあと、その定義はほとんど反対になった。

継続性とは、最も長い会話を握り続ける力ではなかった。意図、変更、承認、実行範囲を別々の台帳に残し、役に立たなくなった文脈を安全に切り離す設計だった。

依存関係を承認したら、別の作業に戻ってしまった

最初の問題は、外部パッケージの承認が必要な作業で現れた。

AIが実装を進める途中で、リポジトリにないパッケージが必要になると、作業は一時停止した。人が正確な名前とバージョンを確認して承認すると、制限されたインストーラーが同じ隔離作業領域にパッケージを用意し、元の作業を続けるはずだった。

ところが初期の再開フローは、「この部屋で、このペットが最後に使った会話」を探していた。承認待ちの間に同じ部屋で別の作業が走ると、最後の会話を指すポインターが変わり得た。記事を書いていた作業が別の作業の文脈で再開したり、依存関係を確認しただけの作業のように終わったりする可能性があった。

同じ部屋、同じペットだから、作業の文脈も同じだと見なしたことが問題だった。

そこで、作業単位の継続性へ切り替えた。最初の実行が残した作業専用の文脈を、認証された実行機だけが復元し、同じ隔離作業領域で続けるようにした。過去データのように作業専用文脈がない場合も、別の作業の会話は借りなかった。代わりに、整理された元の依頼を一度だけ含む新しい文脈から復旧した。

再開中は、承認前の暫定結果を最終成果物のように公開しなかった。作業が本当に終了状態になるまで、チャットには元の依頼と現在の進行状態だけを残した。

拒否できてこそ、継続性も安全になった

同じ障害から、最終PRの拒否ボタンが見えない問題も見つかった。予約作業の依頼者とグループ管理者が同じ場合、初期UIは自己承認を防ぐ条件をすべての段階へ同じように適用していた。

コード実行前の自己承認制限と、最終PRの拒否は意味が異なる。結果を見たあとで、「この変更は反映しない」と決められなければならない。サーバーにはその権限があったが、画面が判断を妨げていた。

私たちは承認段階を分けた。最終反映待ちでは、権限を持つグループ管理者が自分の依頼でも理由を残して拒否できるようにした。過去の失敗や閉じられたPRを成功へ書き換えることはしなかった。残っているリモートブランチや成果物を次の作業の根拠にはできるが、新しい判断は新しい履歴として残さなければならなかった。

継続性は、何でも無条件に続ける機能ではなかった。止めること、拒否すること、その理由を保存し、正しい地点から始め直す権利まで含んでいた。

作業ごとの依存関係インストールを、指紋へ変えた

隔離作業領域はコード変更の混在を防いだ一方、依存関係の準備コストも毎回繰り返した。新しい作業フォルダにはパッケージがなく、インストール承認とネットワーク待ちが再び発生した。

運用端末の共用パッケージ保存領域をそのまま接続しようとすると、アカウント権限が混ざって読み取りエラーが起きた。プロジェクト外のキャッシュを直接指すリンクは、ビルドツールのプロジェクトルート検証にも阻まれた。速度を上げるための共有が、隔離と再現性を損なっていた。

そこで、キャッシュの基準を「すでにフォルダがある」から、「検証済みの依存関係入力が同じ」へ変えた。

• パッケージ宣言、ロックファイル、許可された設定からプロジェクト指紋を作る。
• リポジトリが固定したパッケージ管理ツールのバージョンと、承認済みの配布元だけを使う。
• 最初の準備は元のチェックアウトではなく、一時的な入力コピー上で行う。
• インストールスクリプトとユーザー定義フックは実行しない。
• 高リスク脆弱性検査を通過したパッケージデータだけを、読み取り専用で再利用する。
• 各隔離作業領域には、プロジェクト内で完結する依存関係構造を作る。

同じ指紋を持つ次の作業は、ダウンロードと全体インストールを繰り返さなかった。ロックファイルが変われば、既存キャッシュを上書きせず、新しいバージョンを準備した。新しい依存関係は引き続き人の承認フローを通った。

キャッシュは速い抜け道ではなく、検証結果の再利用だった。

最新の基準を取り込みながら、利用者の変更は上書きしなかった

動的プロジェクトが、接続した日の基準ブランチをいつまでも握り続けてはいけない。新しい作業は、可能な限り最新の正規リポジトリから始めるべきだった。ただし、ローカル変更が残る基準チェックアウトを強制的に同期すれば、利用者の作業を失う恐れがある。

そのため、作業を準備する直前にリモートの基準を確認し、基準チェックアウトに予期しない変更があれば、自動整理せず安全に停止した。新しい隔離作業を作る権限と、既存の利用者変更を捨てる権限は同じではなかった。

この原則は、その後の復旧作業でも繰り返し現れた。システムに与えられたのは、どんな代償を払っても原本を最新にする権限ではない。安全な新規作業の基準を選ぶ責任だけだった。

進行状態は、生ログではなかった

AI作業が長くなると、利用者は「作業中」という一行だけを見て待たなければならなかった。本当に進んでいるのか、承認待ちなのか、検証中なのか分かりにくかった。一方で、生ログをそのまま見せれば、ローカルパス、コマンド、内部エラーが露出し、チャットもすぐに膨らむ。

私たちは許可された進行段階だけを構造化し、一つの状態メッセージを更新した。選択した作業の詳細画面には、整理された段階と時刻を順番に残した。リアルタイム通信は軽い状態だけを送り、実際の詳細は既存の認証済みAPIで再確認した。接続が切れたときは、低頻度の照会が代わりを務めた。

その後、ある作業ではブリッジ側に整理済みの失敗診断があったのに、Haru Spaceの変換層が捨ててしまい、共通エラーしか表示されなかった。長さを制限し、秘密情報をマスキングした失敗理由を結果に含め、本文が同じでも診断が違えば別の結果として区別するよう直した。

復旧に必要な説明と、公開してはいけない生の情報を同時に分ける必要があった。

外部認証画面を閉じても、最初には戻らない

開発オンボーディングのリポジトリ接続では、外部認証画面へ移動してから戻ってくる。利用者が認証を取り消したりウェブビューを閉じたりすると、Haru Spaceのダイアログは「接続中」のままロックされていた。サービスを開き直しても、どの段階で止まったのか分からなくなった。

私たちは同じブラウザに、グループと段階の時刻だけを含む小さな再開マーカーを残した。トークン、リポジトリ資格情報、プロンプト、利用者コンテンツは保存しなかった。戻った画面はそのマーカーを案内に使うが、実際のリポジトリ接続と実行機の準備状態は、サーバー記録から計算し直した。

外部認証に一度成功したというクライアント側の表示は、権限の証明ではなかった。戻る地点は覚え、事実は再検証した。

この方法は別の端末までは引き継がなかった。同じブラウザで中断された旅を取り戻す範囲だった。端末間同期は、どの状態をアカウントへ保存するかという、別のプライバシー検討が必要な問題として残した。

空のリポジトリの最初の作業も、「完了」のように終わった

新規プロジェクトの最初の作業では、検証済みの開始テンプレートを配置した。しかしAIがそれを読み、説明しただけで、ファイルを変更せずに終わることがあった。応答は成功のように見えたが、編集作業の目的は達成されていなかった。

初期テンプレートと結果の指紋が同じで、最初の編集という限定された条件に限り、同じ作業領域と文脈で一度だけ修正実行を許可した。実際の変更、構造化された依存関係リクエスト、明確な失敗のいずれかが必要だった。二度目も変更がなければ、成功に見せかけなかった。

修正実行にネットワークやリポジトリ反映の権限は追加しなかった。使用量は最初の実行と合算して記録した。復旧が、記録されない新しい作業を裏で作る手段にならないようにした。

長すぎる文脈は、保存ではなく負債だった

週の終わり、予約された記事作成がファイルを変更しないまま止まった。予約と自動承認は正常に完了し、実行機も作業を始めていたが、長く続いた共用会話の文脈が新しい依頼にも付いてきた。最新の調査、画像、三つの言語原稿を処理する間に、実行予算が先に尽きた。

この出来事は、「会話が続くほど常によい」という考えを覆した。

それ以降、予約実行は毎回、新しい作業文脈から始めた。継続して必要な情報は、リポジトリ文書、現在の依頼、範囲を絞った参照情報から取得した。通常の会話の連続性は維持しつつ、繰り返し自動作業に隠れて積み上がる過去の会話は切り離した。

一方、完了前に応答ストリームが切れた作業もあった。当時確認した原則は、自動で再実行する前に、まず作業領域の変更有無を見ることだった。変更がなければ新しい作業を依頼できるが、ファイルが残っているなら、同じ作業で検証と完了を続けた方が重複編集を避けられる。この限定的な復旧は当時の後続課題であり、完成した機能としては記録しない。

残すと決めたもの、捨てると決めたもの

再開できるAI作業には、次のものが必要だった。

残すべきもの

• 人が確認した元の依頼と実行範囲
• 作業ごとに隔離された変更とGit状態
• 依存関係の要求・判断と、検証済みロックファイルの指紋
• 現在の段階、制限された失敗理由、追加専用の判断履歴
• 基準リポジトリのリビジョンと変更結果の指紋
• 再開が妥当な場合の作業専用文脈への参照

残すべきでないもの

• 別の作業と共有される「最後の会話」ポインター
• プロンプト全文やモデルの生ログを繰り返し複製したもの
• 認証トークン、ローカルパス、内部コマンド
• 予約作業に際限なく積み上がる過去の会話
• 終了前の暫定結果を完成した成果物に見せる状態

再検証すべきもの

• 現在のグループと作業部屋へのアクセス権限
• 基準ブランチとリポジトリの状態
• 承認対象の指紋と依存関係入力
• ファイル変更が実際に存在するか
• 作業が本当に終了状態に達したか

「再開する」という言葉の意味

8月3–9日の失敗はすべて「続きから」という一語の下にあったが、原因は異なっていた。依存関係の承認後に別の会話へ戻った作業、毎回繰り返されたインストール、外部認証画面で途切れたオンボーディング、変更なしで終わった最初の編集、文脈が大きすぎて有用な作業に入れなかった予約実行があった。

一つの再試行ボタンでは解決できない理由だった。

作業の目的は依頼記録に、変更は隔離作業領域に、判断は監査台帳に、再現性はロックファイルの指紋に残す必要があった。会話の文脈は、そのうちの一つにすぎなかった。有効なら継続し、別の作業に属するか、コストを増やすだけなら新しく始めるべきだった。

AIが中断しても再開できるようにしたのは、すべてを覚えさせたことではなかった。失ってはいけないものと、思い切って切り離すべきものを、初めて区別したことだった。