昨日の続きをAIに任せたつもりが、実は違うモデル、違う推論の深さで動いていた。出力は返ってくるので気づきにくいのですが、長い開発作業では厄介なズレです。
OpenCode v1.18.31は、ACP経由でセッションを読み込み、再開、分岐したときに、モデル、推論の強度、動作モードなどの選択を正しく復元する修正を含みます。派手な新機能ではありません。ただ、AIへ仕事を翌日まで預けるなら、この種の「再開後も同じ条件か」を確認する仕組みが必要です。
v1.18.31で直ったこと
OpenCodeの公式リリースによると、ACPセッションを読み込み、再開、分岐した際に、保存されていたモデル、effort、mode、reasoning chunkの境界を復元するようになりました。
この修正が入ったPull Request #48225には、問題がもう少し具体的に書かれています。修正前は、GPT-5.6 Solのようなモデルが返す複数のthinking chunkが区切りなしで連結される場合がありました。また、セッション再開時にモデルは選び直されても、reasoning effortが復元されないことがありました。
Pull Requestでは、Zed上のACPモードでGPT-5.6 Solとhigh effortを選び、終了後に再起動して同じ強度が選ばれることを確認しています。これは開発者による検証内容です。すべてのモデルやACPクライアントで同じ結果を保証するものではありません。
ACPはAIツール同士をつなぐ入口
OpenCodeの公式文書は、ACP（Agent Client Protocol）をAIコーディングエージェントとエディター間の標準プロトコルとして説明しています。OpenCodeはACPサーバーとして動作し、ZedやJetBrains IDEなどの対応クライアントから利用できます。
この構成では、画面を閉じてもセッションを再開したり、既存セッションから別案を分岐したりできます。便利な反面、エディター、ACP、OpenCode、モデル提供元の間で状態を引き継ぐ箇所が増えます。会話履歴が残っていても、モデルや推論強度が変われば、同じ仕事の続きとは言い切れません。
推論強度は、AIのギアに近い設定です。OpenCodeのモデル文書では、多くのモデルで推論量やverbosityなどを変えるvariantを用意し、variantキーで独自設定も定義できると説明しています。設計判断や原因調査では深く考えさせ、定型修正では軽く回す。この使い分け自体は合理的です。問題は、再開したときにギアが勝手に変わっても利用者が気づけないことです。
現場で起きるのは品質の静かなばらつき
たとえば、初日は高い推論強度で権限設計をレビューし、翌日に同じセッションを再開して修正を続けるとします。再開時に標準強度へ戻れば、会話の流れは残っていても検討の深さが変わる可能性があります。逆に、軽い定型作業が高い推論強度のままなら、時間や利用量が増えます。
セッションを分岐して比較するときも同じです。A案とB案でモデルや強度が違えば、案の良し悪しだけを比べたことになりません。比較条件を残さず、「B案のほうが良かった」と結論づけるのは危険です。
thinking chunkの境界も、単なる表示上の問題とは限りません。思考過程そのものを正解の根拠として扱うべきではありませんが、運用ログで応答の中断箇所や処理単位を調べる際、区切りが潰れていると障害の切り分けが難しくなります。監査では、最終出力、使ったモデル、設定、実行結果を中心に残すほうが扱いやすいでしょう。
更新後は三つの再開テストをする
僕なら、v1.18.31へ更新した後に次の三つだけ確認します。検査用リポジトリを使えば、本番コードを触る必要はありません。
- 特定のモデルと推論強度を選んで短い作業を実行し、クライアントを終了する。再起動後、同じセッションでモデル、強度、動作モードが復元されるかを見る。
- 元のセッションから分岐し、分岐先でも同じ設定が引き継がれるか確認する。意図的にvariantを変えた場合は、その変更だけが反映されることも確かめる。
- 短い応答と複数段階の応答を実行し、記録が途中で連結されたり欠けたりしていないかを見る。エディター上の表示だけでなく、保存後の再読込まで確認する。
記録するのは、OpenCodeのバージョン、ACPクライアント名とバージョン、モデル、variantまたはeffort、agent/mode、再開か分岐か、期待値、実際の結果です。プロンプト全文や顧客コードを検査記録へ貼る必要はありません。再現条件と機密情報は分けます。
再開時の設定が戻っても、そのモデルが現在の利用候補に残っているとは限りません。AIモデル一覧の変化を検知する更新管理も合わせると、復元テストとモデル廃止への備えを同じ手順で管理できます。
チーム運用では設定名まで引き継ぐ
一人で使うなら、画面を見て違和感に気づけるかもしれません。複数人や定期処理では、担当者が変わるだけで前提が消えます。「昨日のセッションを続けてください」という申し送りでは足りません。
作業チケットには、セッションIDだけでなく、利用するモデル、variant、agent/mode、再開時に確認するテストを短く残します。推論強度をhighにした理由も一文あれば十分です。難しい原因調査のためなのか、重要なレビューのためなのか。理由が分かれば、後任は高い設定を維持すべきか、通常設定へ戻すべきか判断できます。
自動処理では、開始時に期待する設定をログへ出し、終了時に実際の設定と結果を残す方法が現実的です。ただし、ログにAPIキー、顧客名、ソースコード本文を混ぜません。設定証跡を増やして機密の保存先まで増やすのは逆効果です。
また、再開テストは毎回の作業に入れる必要はありません。OpenCode、ACPクライアント、モデル設定のどれかを更新した時点で実施し、組み合わせごとに結果を一度保存します。日々の担当者は、その合格済みの組み合わせを使います。変更が入ったら再検査。このくらいなら、確認作業が本業を圧迫しません。
GOとHOLDの境目
v1.18.31は、ACP経由でセッションを再開・分岐する利用者には更新候補です。三つのテストが通り、通常作業にも不具合がなければ限定GOでよいでしょう。
モデル、推論強度、動作モードのどれかが戻らない、分岐元と分岐先の条件を判別できない、再読込後の記録が欠ける場合はHOLDです。まず利用中のACPクライアントとOpenCodeの組み合わせを固定し、再現条件を添えて問題を切り分けます。
この修正は、セッション状態の復元を直すものです。モデル更新による出力差、プロバイダー側の仕様変更、誤った権限設定、保存先の破損まで防ぐわけではありません。重要な作業では、Gitの差分、テスト結果、承認記録を正本にします。AIの会話履歴だけを作業証跡にしないことです。
長時間動くAIでは、開始時の設定より「再開後も同じ条件か」のほうが抜けやすい。毎回すべてを監査する必要はありません。更新後の短い再開テストを受け入れ手順に入れるだけで、品質のばらつきを早く見つけられます。
一次情報
- OpenCode v1.18.31 release notes
- OpenCode Pull Request #48225: restore session options and reasoning boundaries
- OpenCode Docs: ACP Support
- OpenCode Docs: Models and variants
公式事実は上記リリース、Pull Request、公式文書に基づきます。三つの再開テスト、限定GO/HOLD、記録項目はmonobloによる実務提案です。