DeepSeek Harness Plan Modeは計画か直接実行か

直接実行へ進める最低条件は、変更対象が限定され、差分を短時間で確認でき、失敗時にコミットやパッチ単位で戻せることです。たとえば、既存のテストがある単一ファイルの条件修正、明確な命名変更、ドキュメントの小規模な更新であれば、計画を別に作る負担が効果を上回る場合があります。

一方、次のいずれかに該当する場合は、先に計画モードへ切り替えます。

• 複数のパッケージ、サービス、設定ファイルを同時に変更する。
• 依存関係やデータの流れを把握できていない。
• 変更後の検証方法が、単一のテストコマンドでは定まらない。
• 失敗するとマイグレーション、認証、ビルド設定などの復旧が難しい。
• 他の担当者が計画を読んでから実行する必要がある。

変更を小さなコミットへ分け、差分を確認してから戻せる状態を作る考え方は、Git公式ドキュメントのブランチ運用でも説明されています。計画モードを使うかどうかに関係なく、変更単位と回退方法を先に決めることが、直接実行の最低条件です。

また、Gitの履歴を使った復旧方法を確認する場合は、Git公式のresetに関する説明を参照します。特に、既存の未コミット変更を残したままエージェントに書き込ませると、生成された差分と作業中の差分が混ざるため、実行前の作業ツリーを記録しておきます。

公式リポジトリはDeepSeek Harnessを開発者向けプレビューとして扱い、互換性を壊す変更が起こり得ると説明しています。そのため、Plan Modeの入口や表示、初期状態を固定的な製品仕様として扱わず、執筆時点の公式コードと設定を確認する運用が必要です。［DeepSeek Harnessの公開リポジトリ情報］(https://github.com/tylerbuilds/deepseek-harness)

DeepSeek Harness Plan Modeはコードを変更するのか。
計画モードを有効にしただけで、計画文が完成したことと、実際のワークスペースへ変更を書き込んだことを同一視してはいけません。公式実装で確認できるモード状態、権限処理、永続化イベントを確認したうえで、計画中に許可される操作と、実行へ移った後の書き込み操作を分けて検収します。

未確認の自動切り替え規則や、すべての書き込みが自動的に遮断されるという説明は、公式資料で確認できない限り前提にしません。開発プレビューの挙動を運用手順へ組み込む場合は、公開リポジトリのREADME、リリース履歴、変更履歴を作業開始時に照合します。

初めて触るリポジトリでは、いきなり実装案を出させるより、まず「どこから起動し、何に依存し、何で検証するか」を確定させます。Plan Modeは安全装置そのものではなく、調査と実行を分離するための作業段階です。読み取り範囲が広すぎれば機密情報を集めるリスクが増え、狭すぎれば誤った計画になります。

実行へ移る前に、次の証拠をそろえます。

• 起動入口、主要なパッケージ、変更対象の呼び出し元が特定されている。
• パッケージマネージャー、ランタイム、ビルド手順が確認されている。
• 既存のテスト、静的解析、型検査など、実行すべき検証が列挙されている。
• 設定ファイルと秘密情報の保管場所が区別されている。
• 変更対象外のディレクトリと、触れてはいけないファイルが明記されている。
• 計画から実行へ移る条件が、担当者の承認とともに記録されている。

ここで重要なのは、生成された計画を「実装済みの設計書」と考えないことです。計画には、読み取れなかった依存関係、環境差分、未実行の検証が残る可能性があります。計画がどのコミットを前提にしたものかを記録し、実行直前に現在のHEADと一致するか確認します。

GitHubをチームの共有基盤として使う場合は、保護ブランチに関する公式ドキュメントのように、レビューや書き込み制限をツール側でも設定します。Plan Modeの計画レビューを人の確認だけに依存せず、対象ブランチ、承認者、必要なチェックをリポジトリ側のルールにも反映させます。

何の作業なら先に計画モードへ入れるべきか。
判断の中心は作業名ではなく、影響範囲と回退コストです。単一の表示文言を直す作業でも、生成コードや多言語リソースを巻き込むなら計画対象です。反対に、複数行に及ぶ変更でも、対象が独立しており、既存テストと小さなコミットで確実に戻せるなら直接実行が合理的です。

チーム作業では、計画を作る人、書き込みを承認する人、テスト結果を確認する人、失敗時に回退を判断する人を区別します。すべてを同じ担当者に任せると、計画レビューが形式化しやすく、逆に承認者を増やしすぎると小さな改修まで待ち時間が発生します。

計画の粒度は、手順の数ではなく、引き継ぎに必要な情報で決めます。各項目に「対象ファイル」「変更理由」「前提条件」「検証方法」「失敗時の戻し方」が含まれていれば、実行担当者は計画者の会話履歴に依存せず作業できます。これらが欠けている場合は、計画を細かくするのではなく、まず不足している証拠を調査し直します。

実行へ切り替える前の確認項目

• [ ] 計画の対象コミットと現在のHEADが一致している。
• [ ] 対象ブランチに未コミットの変更がない、または既存変更が明示されている。
• [ ] 計画に記載された検証コマンドが実行可能である。
• [ ] 書き込みを承認する担当者が決まっている。
• [ ] テスト失敗時の回退担当者と判断基準が決まっている。
• [ ] 計画外の変更を追加する場合の再承認条件が決まっている。

Plan Modeの完了後、どのように実行へ移すべきか。
計画ファイルの存在だけを合図にせず、計画をレビューし、対象コミット、ブランチ、ワークスペースの状態を再確認してから実行段階へ移します。実行中に対象範囲、依存関係、権限のいずれかが変わった場合は、計画を継続せず、いったん停止して差分を更新します。

CIで検証を行うチームでは、GitHub Actionsのワークフロー構文を参考に、計画に記載した検証コマンドと自動チェックの対応関係を明確にします。計画が「テストする」とだけ書かれている場合は、対象ジョブ、成功条件、ログの保存場所まで指定しなければ、引き継ぎ可能な交付物になりません。

認証情報、本番設定、顧客データ、デプロイ鍵を含むリポジトリでは、Plan Modeを有効にしたから安全になるとは考えません。計画段階では必要なソースと設定例だけを読める環境を用意し、実行段階で必要になった権限だけを一時的に追加します。

この分離には、少なくとも3つの意味があります。第一に、計画作成時の不要な秘密情報の取得を防ぎます。第二に、計画と実装の承認責任を分けられます。第三に、セッションが継続・再接続されたとき、以前の権限がそのまま現在の作業へ持ち越されたと誤認することを防ぎます。

SSHでリモートMacへ接続する場合は、OpenSSHの公式マニュアルを確認し、鍵、ユーザー、接続元制限、エージェント転送の扱いを別に定義します。計画モードの有無とは関係なく、接続経路に過剰な権限があれば、読み取り中心の計画環境という設計意図が崩れます。

macOS側の認証情報を扱う作業では、Appleのプラットフォームセキュリティ資料も確認対象に含めます。環境変数、キーチェーン、設定ファイルへ保存された認証情報を、計画作成用のログやセッション履歴へ混入させない運用が必要です。

公式コードの権限処理やセッション永続化イベントは、開発プレビューの更新で変わる可能性があります。したがって、ワークスペース権限の設計では、モード名だけで判断せず、現在のソース、設定、イベント記録を確認します。

注意: 計画モードは、認証情報の隔離、サンドボックス、ブランチ保護、レビュー承認の代わりにはなりません。計画段階で読み取りが許可されていても、秘密情報を含むディレクトリまで広く公開する設計は避けます。

リモートMacで長い調査や改修を行う場合、接続断、セッション再開、Macの再起動、別担当者への引き継ぎが発生します。会話が復元されたとしても、実際のワークスペース、依存関係、ブランチ、バックグラウンド処理まで同じ状態に戻ったとは限りません。

遠隔のMac環境では、次の順番で再開します。

1. 接続先のMac、ユーザー、作業ディレクトリを確認します。
2. 現在のブランチ、HEAD、未コミット差分を確認します。
3. 計画が作成されたコミットと、現在のコミットを比較します。
4. パッケージのインストール状態、環境変数、必要なサービスを確認します。
5. 計画に記載された読み取り結果が、現在のファイル内容と一致するか確認します。
6. 一致しない場合は計画を破棄せず、差分を追記して再承認します。
7. 実行後は、変更差分、テスト結果、ログ、回退方法を交付物として保存します。

リモート実行ではPlan Modeのほうが安全なのか。
計画と実行を分ける点では安全性を高めやすい一方、リモート接続そのもの、Mac側のユーザー権限、SSHや画面共有の設定、保存された認証情報の管理が別のリスクになります。計画モードを使っても、接続断後に古い計画を新しいワークスペースへ適用すれば、誤った変更を生む可能性があります。

リモートMacで作業する場合は、NUKCLOUDのMacレンタル環境を検討する前に、対象リポジトリの持ち出し可否、必要な接続方式、作業終了後のデータ削除条件を確認します。米国東部の作業環境が必要な場合は、米国東部のMac環境の利用条件と、チームのアクセス方針を照合してから割り当てます。

固定ルールとして「常にPlan Mode」または「常に直接実行」とするのではなく、次の条件分岐をチーム標準にします。

• 変更が単一領域で、回退が容易で、既存テストがあり、検証方法も明確なら、直接実行を選びます。
• 複数モジュールにまたがる、依存関係が不明、または初見のリポジトリなら、先にPlan Modeを選びます。
• 本番設定、認証、顧客データ、デプロイ経路が関係するなら、読み取り中心の計画環境と承認後の実行環境を分けます。
• 計画のレビュー担当と実行担当が異なるなら、計画を交付物として保存し、承認後に実行します。
• リモートセッションが中断し、コミットやワークスペースの一致を確認できないなら、直接実行へ戻らず、再調査から始めます。
• 計画が抽象的で、対象・検証・回退のいずれかが欠けているなら、実行へ移さず計画を更新します。

現在の構成やモードの挙動を確認する際は、公開リポジトリのソース、設定、リリース履歴を基準にし、開発者向けプレビューの変更を前提に運用手順を更新します。実行へ進める条件をチームのタスク契約へ書き込み、誰が計画を承認し、誰が検証し、誰が回退を決めるかまで残しておくと、単なる機能設定ではなく責任分界として運用できます。

直接実行だけに固定すると、初見のコードリファクタリングで調査と変更が混ざり、差分の責任範囲が曖昧になります。反対に、すべてをPlan Modeへ送ると、単純な修正でも計画、承認、再接続の待ち時間が増えます。複雑な作業を一時的なMac環境で切り出し、計画、権限、検証を分けて受け渡せる点では、ローカル環境へ無理に変更を集中させるより、NUKCLOUDのMac環境を使うほうが運用を整理しやすい場合があります。

長期にわたり同じ環境で高負荷処理を続ける場合や、物理デバイスへの接続が必要な場合は自前のMacが適しています。一方、短期の調査、検証、チーム交代を伴う作業では、モード切り替えと作業環境の分離を同時に設計することが重要です。