画面のプリセット名だけが「Code Mode」から「PTC Mode」に変わり、既存設定が壊れたように見えています。

2026年8月18日時点の最短結論:確認済みなのは英語名の変更です。今週は表示名、保存済み設定、チーム文書を確認し、名前の変更だけを理由に再デプロイや環境増設はしないでください。

現在のCode Modeを使っていて、アップデート後の設定失敗を心配している開発者向けです。プリセットやプラグイン、社内手順書を管理する担当者、PTC Mode専用の実行環境を用意すべきか判断する技術責任者にも適しています。

注意: PTC Modeという名称から、ツール呼び出し方式、権限モデル、実行エンジンまで変更されたと推測するのは早すぎます。公式の定義、設定キー、移行案内が追加されるまでは、確認済みの事実と推測を分けて扱ってください。

01

まず押さえる変更範囲

公式のv0.1.0-rc.7リリース説明で確認されているのは、英語の内蔵プリセット名が「Code mode」から「PTC mode」へ変更されたことです。現時点で、この変更だけから底層の実行能力、権限、実行プロトコル、必要リソースが変わったとは判断できません。

DeepSeek Harnessの公式リポジトリでは、Harnessをプリセットやプラグインの組み合わせで構成する設計が示されています。したがって、プリセット名はユーザーインターフェース上の識別子であり、名前だけで独立した製品や新しい通信規格になったと解釈するべきではありません。

確認項目 2026年8月18日時点の扱い 今すぐ必要な対応
内蔵プリセット名 Code ModeからPTC Modeへの変更を確認 画面表示を確認
実行エンジン 更名に伴う変更は未確認 再構築しない
ツール呼び出し 変更を示す公式説明は未確認 既存タスクで動作確認
権限モデル 変更を示す公式説明は未確認 allowlistを再設計しない
実行環境の規模 名称変更だけでは判断不能 容量増設を保留

DeepSeek Harness PTC ModeとCode Modeの違いは何ですか。
現段階で公式に確認できる違いは、主に英語のプリセット名称です。旧名称を参照する設定や説明文が残っている場合は、表示や検索で混乱する可能性があります。しかし、それを実行動作の変更と同一視する根拠はまだありません。

02

既存ユーザーの確認ポイント

既存のCode Modeユーザーは、まず3か所を見てください。

1つ目は、起動後のプリセット選択画面です。表示がPTC Modeになっているか、旧名称が別名として残っているかを確認します。2つ目は、設定ファイルや環境変数、起動スクリプトが旧名称を文字列として参照していないかです。3つ目は、チームの操作手順やスクリーンショットです。

設定がプリセットの表示名ではなく内部キーを参照している場合、画面上の変更だけでは動作に影響しない可能性があります。反対に、シェルスクリプトやCI/CDの条件分岐がCode Modeという文字列に依存している場合は、名称変更による失敗が起こり得ます。ここは公式発表ではなく、あなたの実装を確認する作業です。

アップデート後も、以前のCode Mode設定は使えますか。
内部キーや設定形式が変更されていない限り、継続利用できる可能性があります。ただし、公式の移行説明がない時点で互換性を断定するのは避けてください。実際のインストール環境で、既存設定を複製した検証用プロファイルを使い、起動、ツール実行、履歴継続の3点を確認するのが安全です。

今週の確認チェックリスト

  • [ ] v0.1.0-rc.7のリリースノートでプリセット名を確認する
  • [ ] READMEと現在の設定ドキュメントでCode Mode、PTC Modeの表記を照合する
  • [ ] 保存済み設定に旧名称が文字列として残っていないか検索する
  • [ ] 代表的なツール呼び出しを1件実行する
  • [ ] ファイル操作やシェル実行など、権限境界のある処理を1件確認する
  • [ ] 起動ログに読み込まれたプリセット名を記録する
  • [ ] 失敗時に戻せる旧バージョンまたは設定コピーを保管する
  • [ ] チームの手順書に「旧Code Mode=現PTC Mode」と暫定記載する

アップグレード前に検証用のMac環境を用意する場合は、VpsMeshのMac環境案内から接続方法と利用条件を確認してください。候補ページが未公開の環境では、公式リリースノートとリポジトリの履歴を優先します。

03

プラグイン作者の確認範囲

プラグイン作者が確認すべきなのは、能力の推測ではなく名称依存です。設定カード、ヘルプ文、初期プロファイル、登録処理、テスト用スナップショットにCode Modeがハードコードされていないかを検索してください。

Cordisのような構成要素を利用する場合も、まずは現在のプラグイン登録結果と公式コードを確認します。Cordisという名前が出ているからといって、PTC ModeがCordisの新しいプロトコルである、あるいは既存プラグインに自動的な互換別名が用意された、と推測してはいけません。Cordisの公式リポジトリDeepSeek Harnessのリポジトリ履歴を分けて確認することが重要です。

プラグイン側の依存箇所 起こり得る問題 優先確認
表示ラベル 利用者が旧名称を探して迷う 画面文言を修正
プロファイル名 選択肢の表示や検索に失敗する 内部キーと表示名を分離
設定ファイル参照 起動時にプリセットを見つけられない 旧名称の文字列検索
テストスナップショット UIテストだけが失敗する 期待値を更新
権限定義 変更を誤認して過剰修正する 公式設定との差分確認

現時点では、旧名称を受け付ける互換エイリアスが公式に提供されているとは確認できません。したがって、作者側で独自に「Code ModeならPTC Modeへ置換する」と実装する場合は、将来の内部キー変更と混同しないよう、表示層だけに限定してください。

04

チーム運用の暫定整理

チームでは、新旧名称が混在する期間を想定してください。手順書、研修資料、画面キャプチャ、自動化スクリプトは、それぞれ更新速度が異なります。すべてを一度に書き換えるより、「旧Code Modeは現行画面のPTC Modeを指す」という対応表を先に追加するほうが、引き継ぎ時の誤解を抑えやすいです。

担当者が複数いる場合は、次のように分類します。

  • 開発者: 現在の設定で代表タスクが完了するか確認します。
  • プラグイン作者: 旧名称のハードコードと表示文言を検索します。
  • チーム管理者: 手順書とスクリーンショットに暫定マッピングを追加します。
  • 技術責任者: 能力変更を示す公式情報が出るまで環境判断を保留します。

実行モードの選択基準そのものを見直したい場合は、既存の用途、権限、監査要件を先に整理してください。PTC Modeを新しい選択肢として決め打ちするのではなく、現在の運用条件と必要な検証項目から比較することが重要です。

Macを含む遠隔実行環境を候補にする場合は、接続経路だけでなく、認証情報の管理、利用者の権限分離、ログの保管場所も確認してください。利用条件やデータ保護の扱いは、採用予定の環境に関する契約文書と社内のセキュリティ基準を照合してください。外部サービスを利用する場合は、保存データの範囲、削除手順、管理者権限の分離を文書化してから社内審査へ進めます。

05

専用環境を急いで用意しない理由

PTC Modeのために専用の実行環境を準備すべきですか。
名称変更だけを理由に、専用のMac、サーバー、同時実行枠を増やす必要はありません。環境を見直すべきなのは、公式文書で実行方式や権限境界が変わった場合、基準タスクの結果が変わった場合、または常時稼働や並列処理の要件が変わった場合です。

プラットフォーム担当者が先に拡張すると、不要な費用だけでなく、監視対象、認証情報、アクセス経路も増えます。特にリモート環境では、SSHやVNCの接続経路、シークレットの保管場所、プラグインの更新責任まで再整理する必要があります。表示名の変更では、そこまでの変更理由になりません。

Mac上で実際の導入確認を行う場合も、まずは既存の検証環境を使い、プリセット表示、設定読込、ツール実行、ログ保存を順番に確認してください。新しい環境を借りる場合も、先に必要な接続方式と検証期間を決めてから、構成を選ぶべきです。

06

再評価を開始する公式シグナル

次の情報が公式リリース、README、CLIヘルプ、設定文書に追加された場合は、単なる更名ではなく運用変更として再評価してください。

  1. PTC Modeの正式な定義が追加される。
  2. デフォルトで読み込むプラグイン構成が変更される。
  3. ファイル、シェル、ネットワークなどの権限モデルが変わる。
  4. 設定キー、CLI引数、環境変数の名称が変わる。
  5. 旧Code Modeからの移行手順や非互換事項が明記される。
  6. 公式の基準タスクや検証方法が変更される。

DeepSeek Harnessの公式リリース一覧だけでなく、公式README、CLIのヘルプ、設定ファイルを同じタイミングで確認してください。公式側がPTC Modeの仕様を補足した時点で、既存構成をそのまま継続するのか、部分修正するのか、再受け入れ試験を行うのかを決めます。

現時点の判断は3段階です。

  • 継続: 表示名だけが変わり、既存タスクと権限確認が通る場合。
  • 局所修正: プラグイン文言、手順書、スクリプトの名称参照だけが問題の場合。
  • 再受け入れ: 実行方式、権限、設定キー、標準プラグイン構成に公式変更が出た場合。

現在の構成をそのまま再構築するより、まず名称依存を洗い出すほうが安全です。Windowsや一般的なクラウド環境へ急いで移す理由も、PTC Modeの更名だけでは生まれません。既存環境には設定や監視が積み上がっている一方、別環境へ移すと接続経路、権限、ログ保管、運用担当の分担を改めて設計する必要があります。

一時的な検証環境や遠隔のMacが必要になった場合でも、先に現行構成との比較を行い、必要な期間と作業内容を明確にしてください。東京拠点のMac環境を候補にする場合は、接続条件と利用可能な期間を事前に確認し、PTC Modeの公式仕様が確定してから環境変更へ進むのが低リスクです。社内のデータ保護確認では、保存データの範囲、削除手順、管理者権限の分離を文書化しておくと、環境変更後の再確認も進めやすくなります。

最終更新:2026年8月18日。データは同日、DeepSeek Harnessの公式リリース、README、CLI・設定関連文書を確認しています。