2026年8月17日公開の v0.1.0-rc.7 で公式に確認できる変更は、各プラグインが設定カードを登録できるようになったことです。公式リリース一覧 と公式リポジトリの開発プレビュー説明を基準に判断すると、今週は既存プラグインの全面改修ではなく、最小設定の試験と保存状態の確認に進むべきです。設定入口が増えたことは、設定契約が安定したことを意味しません。

最初の判断： 既存の dsh-plugin が読み込みと設定保存を維持できているなら、カード対応だけを理由に大規模な再設計は待ちます。新規プラグインは小さな設定面を試し、検証処理と旧来の回退経路を残してください。

対象になる開発者と判断ポイント

この内容は、rc.7向けに既存プラグインの適応要否を見極めたい作者向けです。複数のプラグインで設定入口をそろえたいチーム管理者や、「すべてがプラグイン」という設計を運用可能な製品体験へ進めたい開発者にも関係します。

一方、単に画面の見た目を確認したいだけなら、今すぐ実装へ入る必要はありません。公式リポジトリ自身が開発プレビューであり、互換性を壊す変更があり得ると明記しているためです。リポジトリのREADMEでは、この段階の性質が明確に示されています。

公開直後に確定したことと、まだ決まっていないこと

rc.7の新機能を「プラグインが設定カードを登録できる」と読むのは妥当です。これは、利用者がプラグイン設定へ到達する入口を、宿主側の共通画面にまとめやすくする変更です。Cordisを基盤とするプラグイン構成との相性もよく、設定管理をプラグイン単位で整理する方向性は読み取れます。公式リポジトリの構成説明も、各機能をプラグインとして扱う設計を説明しています。

ただし、次の内容はリリース説明だけでは確定しません。

  • 設定カードAPIが今後も同じ形で維持されるか。
  • 設定値をプラグイン、宿主、配布ファイルのどこが所有するか。
  • 旧設定から新カードへ自動移行できるか。
  • 設定変更に必要な権限や、ユーザー単位の分離がどう扱われるか。
  • カードの保存処理とプラグインのライフサイクルが、どの契約で結ばれるか。

したがって、設定カードは「操作画面の追加」と「設定モデルの再定義」を分けて扱う必要があります。後者まで変更されたと決めつけると、不要な互換性リスクを抱えます。

初日の確認：既存プラグインは本当に影響を受けるか

公開初日は、コードを直す前に設定経路を棚卸しします。確認対象は画面だけではありません。設定の読み込み元、保存先、初期値の決め方、環境変数との優先順位まで追跡してください。

次の3パターンで判断すると、作業範囲を絞れます。

  • 影響が小さいケース
    プラグインが通常の設定ファイルや環境変数を読み、画面構造を直接参照していない場合です。読み込みと保存が継続して動くなら、rc.7対応は監視対象にとどめます。

  • 確認が必要なケース
    旧設定入口の固定パス、画面要素の識別子、特定の表示順に依存している場合です。カード登録とは別に、設定の取得と表示が分離されているかを確認します。

  • 改修候補になるケース
    設定値を画面の一時状態だけに保持している、保存処理を独自イベントへ強く依存している、または同じ項目を複数の設定ファイルへ書き込んでいる場合です。ここではカード対応より、設定所有権の整理を先に行います。

プラグイン開発では、最初に最小構造と設定の読み込み経路を切り分けてください。実装の入口を整理したい場合は、VMSPINの日本語技術記事一覧から関連するプラグイン運用情報を確認し、画面対応を先に進めるより、どの層が設定値を保持しているかを確認した方が不要な改修を避けやすくなります。

注意： 設定カードが表示されたことだけで、保存完了とは判断しないでください。画面の再読み込み、プロセス再起動、別アカウントでの確認まで終えて、初めて永続化を評価できます。

第一週の最小試験：設定の一往復を通す

新規プラグインや改修候補は、最初から複雑な設定画面を作らない方が安全です。秘密情報を含まない文字列、数値、真偽値など、失敗時に再発行や漏えい対応が不要な項目を1つ選びます。

試験は次の順番で進めてください。

  1. rc.7のバージョンを固定し、試験用ブランチを作成します。
  2. プラグインが通常どおり読み込まれ、初期値が表示されることを確認します。
  3. 設定カードへの登録状態を確認し、項目名と説明が利用者に理解できるか見ます。
  4. 値を変更し、保存操作後にプラグイン側の読み取り結果が変わるか確認します。
  5. 画面を再読み込みし、変更値が再表示されるかを確認します。
  6. プロセスを再起動し、同じ値が残るか確認します。
  7. 不正値や未入力を送った場合に、拒否、警告、既定値への回退のいずれが起きるか記録します。
  8. 失敗後にプラグインが再読み込みできるか確認し、ログと利用者向け表示を分けて評価します。

ここで大切なのは、存在しないAPI名やコンポーネント名を推測して実装しないことです。登録関数、設定の読み取り方法、保存イベント、ライフサイクル名は、公式のプラグイン関連ソースまたは実際の再現結果で確認できたものだけを採用してください。

チーム導入：設定所有者を一つに絞る

複数プラグインを管理する段階では、設定カードの見栄えより書き込み責任が問題になります。プラグインが管理する値、宿主が管理する値、デプロイ時に固定する値を文書化しないと、同じ項目が複数の入口から変更されます。

最低限、各設定項目について次を記録します。

  • 所有者はプラグイン、宿主、デプロイファイルのどれか。
  • 初期値と、値が未設定だった場合の動作。
  • 利用者が変更できる範囲と、管理者だけが変更できる範囲。
  • 変更後に再起動が必要か。
  • 将来のキー変更時に、旧値へ戻す方法。
  • 秘密情報を扱う場合の保管先とログへの出力禁止事項。

カードを導入しても、配布時の設定ファイルを即座に廃止する必要はありません。環境ごとの差分を管理する用途では、デプロイ側の設定を正とし、カードは許可された範囲の上書きだけに限定する設計が扱いやすい場合があります。

公式の安定信号を待つ間の運用

rc.7の段階で投資を広げるかは、次の信号で判断します。正式ドキュメントに登録方法と保存契約が明記される、公式のサンプルプラグインが追加される、互換性に関する説明が更新される、後続リリースノートで移行方針が示される、といった変化です。公式ドキュメント領域も継続して確認してください。

反対に、画面だけが先に増え、API名や保存仕様が短期間で変わっている間は、チーム全体の標準パネルへ拡張しない方が安全です。1つか2つの非機密設定で試験し、リリースごとに読み込み、保存、再起動の結果を比較します。

公開後7日間の判断基準

  • 1日目： 既存 dsh-plugin の設定入口と画面依存を確認します。
  • 2〜3日目： 最小設定で登録、変更、保存、再読み込みを試します。
  • 4〜5日目： 再起動、アップグレード、別ユーザーで状態を確認します。
  • 6日目： 設定所有者、権限、回退方法をチーム記録へ追加します。
  • 7日目： 公式ドキュメントと後続リリースを確認し、継続、保留、撤回を決めます。

FAQ：rc.7で迷いやすい実装判断

DeepSeek Harnessのプラグイン設定カードは何をする機能ですか？

v0.1.0-rc.7で公式に確認できるのは、各プラグインが設定カードを登録できるようになった点です。利用者がプラグインごとの設定項目を見つけやすくなるため、管理画面の入口は整理されます。ただし、保存先、権限、移行方式、将来のAPI互換性まで発表されたわけではありません。

今使っているdsh-pluginはrc.7向けに作り直す必要がありますか？

すぐに全面改修する必要はありません。まずプラグインの読み込み、既存設定の表示、変更後の保存が従来どおり動くかを確認してください。旧設定入口の固定参照や画面構造への依存がなければ、設定カード対応は小さな試験ブランチに分け、安定契約が示されるまで本番切り替えを急がない判断が妥当です。

プラグイン設定カードはcordis.ymlの代わりになりますか？

現時点では代替と判断できません。設定カードは利用者向けの管理入口であり、cordis.ymlやデプロイ用ファイルが担う初期値、環境差分、配布管理を自動的に置き換えるとは確認されていません。同じ項目を複数の場所から変更できる設計にすると、どの値が有効か分からなくなるため、所有者を先に決める必要があります。

DeepSeek Harnessのプラグインに設定画面を追加するとき、何から始めますか？

最初はAPI名を推測せず、rc.7の公式コード、開発ドキュメント、実際に動くサンプルを確認します。そのうえで秘密情報を含まない文字列や真偽値を1つだけ使い、登録、読み取り、変更、保存、再読み込み、失敗時の表示を順番に検証します。未確定のライフサイクル名を前提に、既存機能全体を組み替えるのは避けてください。

公開後の確認用チェックリスト

  • [ ] rc.7のバージョンを固定し、試験結果を記録できる状態にした。
  • [ ] 既存プラグインが旧設定入口や画面構造へ直接依存していないか確認した。
  • [ ] 非機密の設定項目を1つ選び、最小の設定カード試験を作った。
  • [ ] 登録、読み取り、変更、保存、再読み込み、失敗表示を確認した。
  • [ ] プロセス再起動後も設定が残るか確認した。
  • [ ] 設定の所有者と、変更可能な権限を決めた。
  • [ ] 秘密情報を画面やログへ出さない保管方針を決めた。
  • [ ] cordis.yml、宿主設定、カードの役割が重複していない。
  • [ ] 後続リリース、公式ドキュメント、サンプルの更新を確認した。
  • [ ] 安定契約がない場合は、チーム全体への展開を保留した。

現行構成とMac環境の使い分け

既存のローカル構成だけで試す場合、端末ごとのNode.jsやパッケージ状態がそろわない、再起動試験の記録が個人環境に閉じる、複数ユーザーの設定差分を再現しにくいという問題があります。特にrc.7のような開発プレビューでは、設定保存の確認と環境差分の切り分けを同じ端末で行うと、原因判定が遅れます。

一方、Mac環境をレンタルすれば、試験用の実行環境を分け、プラグインの読み込み失敗や再起動後の状態を同じ手順で確認しやすくなります。長期の常時稼働や物理インターフェースが必要なら自前環境が向きますが、rc.7の第一週検証や一時的なチーム試験なら、Mac環境の利用条件を確認し、必要な期間だけ環境を確保する方法も選択肢になります。

最後に、設定カードへ進む前にプラグインの最小構造と読み込み復旧手順を確認し、カード試験を単独で通してください。安定した公式契約が示されるまでは、遠隔のMac環境でチーム向け設定パネルへ一気に拡張せず、まずは小規模な検証環境で結果を記録するのが安全です。試験環境を分離して再起動や設定保存を確認する場合は、VMSPINの日本語案内で利用方法の概要を確認できます。

最終更新：2026年8月18日。 rc.7の公式リリース情報、公式リポジトリのREADME、masterブランチのドキュメントとプラグイン関連コードを確認しています。後続候補版または正式版、設定カード開発文書が公開された場合は、API、永続化、互換性の判断を個別に再確認してください。