手元の作業を続けながら、OpenCodeに別の場所でバグを直してもらう

変更を書きかけのところに、日付の解析が失敗するという報告が届いた。手元のファイルは編集し続けながら、コーディングエージェントには別の仕事を頼みたい。二者が同じディレクトリで編集を始めると、小さな修正案でも自分の作業と切り分けにくくなる。

11月6日、OpenCode 2.2.6はスクリプトからのコマンドライン実行にワークツリーのオプションを加えた。OpenCodeはオープンソースのコーディングエージェントで、対話型端末と、スクリプトからプロンプトを実行するコマンドを備える。新しいオプションでは、別のGitワークツリーで始めるよう指定でき、必要なら名前を付け、元の作業ディレクトリもそのまま使える。同じリリースでは、条件が一致するModel Context Protocol（MCP）接続を、明示的に有効にしたとき共有する機能も追加された。実行前に確認したいのは、エージェントがどのファイルを変更でき、どのサービスを使えるかだ。OpenCode v2.2.6リリース · OpenCode CLI文書

扱いやすい構成は、範囲を絞った一つの仕事に、明確な開始状態、変更を調べる場所、プロジェクトの外へ出る操作ごとの明示的な権限を組み合わせたものだ。

OpenCodeプロジェクトの端末画面。パッチとセッションの表示が見える。リリースタグ付きの公式画像で、MITライセンス表記を添えている。Telli.shがサイズを調整し、余白を追加した。

ディレクトリが別なら、確認する差分がはっきりする

Gitワークツリーは作業ごとにファイルとインデックスを持つ。Telli.shオリジナル図解。

Gitワークツリーは、一つのリポジトリに複数の作業ディレクトリを結びつける。各ワークツリーには個別の作業ファイル、インデックス、チェックアウト位置があり、リポジトリのデータの大半は共有する。自分の変更を手元に置いたまま、エージェントのパッチだけを確認できる。一方、エージェントが見るソースも変わる。同じリポジトリに属していても、最初のディレクトリの未コミット変更が別のチェックアウトに自動で現れることはない。Gitワークツリー文書

OpenCodeの11月6日のリリースには三つの指定方法がある。新しいワークツリーには opencode run -w または opencode run --worktree を使い、名前を付けるときは --worktree=<name> を使う。ワークツリーのオプションは --continue や --session と併用できない。新しい実行には新しい開始時の文脈が要る。長いやりとりがあるバグ報告なら、必要な再現手順と期待結果を新しいプロンプトに移す。OpenCode v2.2.6リリース · ワークツリーの実装と例

別ディレクトリは、レビューのための場所と考えるとよい。開始前に想定するブランチとコミットを記録する。開始後は、新しいワークツリーのコミットと状態を見る。未追跡のテスト用ファイルや開発者のエディターにしかない変更にテストが依存していれば、二つの実行で結果が違う理由になる。古いコードに対して正しいパッチでも、これから出荷するブランチには適さないことがある。

大きな仕事を渡す前に、一つの小さな変更を試す

自分が管理するリポジトリで、範囲の明確な仕事から始める。失敗するうるう日のテストは、大規模なアップグレードより最初の実験に向いている。期待する結果が明確だからだ。古くなったナビゲーションのリンクを一つのルートテストで直す例も同じくらい扱いやすい。どちらも、何が変わるべきか、どう確かめるかを明示する。

1. 開始時の状態を記録する。 現在のディレクトリで git status --short と git rev-parse HEAD を実行し、出力をバグ報告と一緒に保管する。すでに通る基準テストがあれば再現方法も残す。opencode --version で新しいオプションに対応するリリースか確認する。OpenCode v2.2.6リリース

2. 名前付きワークツリーで一つの仕事を渡す。 再現手順と対象テストをプロンプトに含める。以下は架空の日付パーサーを使った例で、対象のテストがリポジトリにある前提だ。変更をコミットせずに残すよう依頼すると確認しやすい。さらに強い境界が必要なら、使う権限と実行環境で制限する。

   Shellターミナルで実行

   opencode run --worktree=date-parser "Reproduce the leap-day parsing bug in the date parser tests. Fix the narrow cause, run the targeted tests, and leave the changes uncommitted for review."
   

3. 結果を見る前に新しいディレクトリを特定する。 元のリポジトリで git worktree list を実行し、表示されたパスを使う。新しいディレクトリで git status --short、git diff、git diff --cached を確認する。最後のコマンドはエージェントが何かをステージした場合に必要だ。未追跡のファイルも別途確認する。エージェント側のディレクトリから対象テストを自分で再実行し、うるう年の2月29日と、その日付が無効になる年の両方を扱っているかを見る。Gitワークツリー文書

4. 確認した変更だけを取り込む。 レビュー済みのコミットやパッチを対象ブランチに適用できるまで、変更案を別に置いておく。元のディレクトリの状態をもう一度見る。必要な記録を残し、保存したい保留中の変更がないと確認するまでは、エージェントのワークツリーを保持する。Gitのワークツリー一覧があれば、各ディレクトリと仕事を対応付けやすい。Gitワークツリー文書

関係のない問題が二つ同時に来たときも、この方法が役立つ。一件ずつ範囲を区切り、統合前に二つの差分を比較する。ワークツリーを分ければ、一方の未ステージのテスト変更がもう一方のディレクトリに現れることはない。それでも同じブランチに取り込むときには、共通のヘルパーを変えた場合などに衝突し得る。ブランチの統合と最後の回帰テストは通常のレビュー工程に残る。

リポジトリの外で何を許可するか決める

二つのワークツリーが、同じOSアカウントで動くことがある。同じ環境変数、認証情報ヘルパー、ネットワークにアクセスできる可能性もある。ワークツリーのオプションは、実行の開始場所を決め、通常の作業変更を分離する。より強い境界が必要なら、実行環境やアカウントを個別に制限する。権限の確認はそれに従うツールを制御し、プロセスが最終的にアクセスできる範囲はOSや実行環境が決める。

変更の置き場所、ツールの承認、実行時のアクセスは別々に確認する。Telli.shオリジナル図解。

OpenCodeのV2権限文書では、操作ごとに順序付きのルールを使う。指定できるのは allow、ask、deny で、最後に一致したルールが優先される。公式の例ではシェルの実行に確認を求めたうえで、一般的な調査コマンドを許可し、プッシュは拒否する。承認する人がいない状態で動かすなら、定期ジョブに入れる前に、そのフローで ask がどう動くか試す。禁止事項は設定に明記し、ジョブに実際に必要なサービスには、権限を絞った短命の認証情報を使う。OpenCode権限文書

文書だけを変える課題なら、これらの層を簡単に試せる。サンプルプロジェクトの一節だけ変更を許可する。利用を認めたプロバイダーを使わせ、本番用の認証情報は渡さない。スクリプトを実行し、差分が想定したファイルだけか確認する。後でリポジトリのリモートやチケットツールが要るなら、機能ごとに用途を定め、権限を個別に検証する。

もともと同じ境界を共有する場合に接続をまとめる

MCPを使うと、ドキュメント検索や課題管理など、別のプログラムが提供するツールをエージェントから呼べる。11月6日のリリースでは、pool: true により、一つのOpenCodeサーバーが扱う複数のディレクトリで関連設定が一致した場合、接続を再利用できる。公式のV2文書では、プールが適用されるのは2026-07-28版のプロトコルだ。サーバーが古い版で接続した場合は個別の接続を維持する。二つのプロジェクトを同じアドレスに向けるだけでは一致しない。リモート設定と認証済みアカウントが一致する必要があり、ローカルサーバーではコマンド、環境、作業ディレクトリも照合される。OpenCode v2.2.6リリース · OpenCode MCP接続共有文書

例として、二つのワークツリーが同じアカウントで社内文書を検索するとする。サービスが該当する版に対応していれば、共有で重複する接続設定を減らせる。まず、両方のディレクトリが同じ情報を参照してよいことと、連携機能が必要な権限だけを持つことを確かめる。一方が公開文書だけを使い、もう一方が社内チケットを開けるなら、接続を分けたほうが境界を確認しやすい。

ローカルサーバーが現在の作業ディレクトリに依存することもある。同じコマンドで起動しても、各プロジェクトのディレクトリで立ち上がるプロセスは異なる文脈を持つ。OpenCode文書によると、プロジェクトをまたいでローカル接続をプールするには固定の作業ディレクトリが必要で、共有接続にはルート情報がない。まずは対象リソースの範囲が明確な読み取り専用サービスから試すとよい。呼び出し元のリポジトリによって挙動が変わるツールなら、接続を共有する前に何が変わるか測る。OpenCode MCP接続共有文書

スクリプト実行には終了条件も要る

OpenCode 2.2.6は --archived も加えた。スクリプトやCIのセッションをアーカイブ済みの状態で開始し、通常のセッション一覧に出さない。変わるのはセッションの見せ方だ。ジョブの結果、ワークツリーのパス、テスト結果はレビュー担当者が見つけられる場所に保存する。普段の一覧が空でも、パッチを確実に探せるようにしてからこのオプションを使う。11月6日のリリースノートでは、アーカイブ済みのセッションは --continue の対象から外れる。OpenCode v2.2.6リリース

同じリリースで、スクリプト実行が終わるタイミングも変わった。プロンプトから起動したバックグラウンドのコマンド、サブエージェント、画像ジョブが終わるのを待ってから終了する。リリースノートによると待機自体に時間制限はなく、開発サーバーやファイル監視によって実行が続くことがある。自動テストでは、検査が済めば終了するコマンドを選び、外側のCIステップには時間上限を設ける。実行のキャンセル、テストの失敗、エージェントによる成功報告は別々に扱う。時間切れになったら、再実行や統合の前に変更案の実態を確認する。OpenCode v2.2.6リリース

予備試験が動いたら、エージェントの完了報告だけでなく、全体の手間を見て効果を判断できる。新規実行の準備に何分かかったか。レビュー担当者が差分を理解して確かめるまでに何分かかったか。無関係な編集の修復や、停止したツールの調査がどれくらい発生したか。規模が似た仕事をいくつか比べ、準備とレビューも時間に含める。別のワークツリーは、一人が責任を持てる小さな差分を保つときに最も役立つ。

きれいなチェックアウトなら責任の所在が見える

ワークツリーのオプションが役立つのは、レビューを始める場所が明確になるからだ。片方が作業を続けている間に、もう片方は基準の状態を見て、変更を調べ、テストを再実行できる。接続の共有と実行権限も同じように明確にしたい。引き継ぎやすいのは、どこから始まったか、何を変えたか、どんな証拠で統合できるかを、それ自体で説明できる小さなパッチだ。

出典

• OpenCode公式端末画像とリポジトリのライセンス

• OpenCode v2.2.6リリース、2026年11月6日

• OpenCode CLI文書

• OpenCode V2の権限

• OpenCodeのMCP接続共有

• Gitワークツリーのマニュアル

---

作業の背景にある判断や試験を検索できる記録に残すなら、Telli.shのアカウントを作成できます。