DeepSeek、すべてのコンポーネントを置き換え可能にするAgent Harnessを公開

DeepSeekは初のHarness開発者プレビューを公開した。Google Newsの見出しの背景にある対立は、驚くほど具体的だ。同社は単に別のコーディングエージェントにプラグインを追加したのではない。モデルアダプター、ツールレジストリ、セッションログ、サンドボックス、エージェントループ、ユーザーインターフェースを、すべて置き換え可能なコンポーネントにした。

この設計により、DeepSeek HarnessはClaude Code、Codex、その他の完成済みコーディングエージェント製品よりも下位のレイヤーに位置づけられる。これらの製品は、定義済みの拡張ポイントを備えた組み立て済みエージェントを開発者に提供する。DeepSeekが提供するのは、コーディングアシスタントに似たものを含む多様なエージェントを生み出せる、設定可能な基盤だ。

この違いは、プロジェクト最大の不確実性も浮き彫りにする。DeepSeekはすべての要素を組み合わせ、置き換え、拡張できるとしているが、ソフトウェアは依然として開発者プレビューの段階にある。ドキュメントでは、互換性を破る変更が発生すると明示的に警告している。したがって今回の公開は、アーキテクチャの提案であると同時に、極端なモジュール性が本番利用に耐えられるかを問う未完の試験でもある。

Google Newsの見出しが実際に発表したもの

DeepSeekが公開したのはAIモデル周辺の仕組みであり、新しいチャットインターフェースを備えた別のモデルではない。

dshとも呼ばれるDeepSeek Harnessは、MITライセンスで公開されたオープンソースのエージェントハーネスだ。エージェントハーネスとは、プロンプト、ツール、ファイル、状態、権限、繰り返されるモデル呼び出しを管理する、モデルを取り巻くソフトウェアを指す。

プロジェクトの公式リポジトリは、「Everything is a Plugin」という一つの基本理念を掲げる。これにはモデル、スキル、ツール、セッション、サンドボックス、ファイルシステム、ループ、オーケストレーション、そしてユーザーに提示されるインターフェースまで含まれる。

DeepSeekによれば、現行リリースは開発者プレビューだ。ユーザーはnpmコマンドを通じてブラウザーインターフェースを起動でき、アプリケーションはデフォルトでローカルに提供される。開発者はリポジトリをソースからビルドすることもできる。

今回の公開に先立ち、DeepSeekが専任のHarnessチームを構築している兆候があった。しかし、以前の採用動向よりもコードの方が重要だ。これにより開発者は、製品デモに依存せず、具体的なシステムを検証、改変、実行できるようになる。

これが、この話題がGoogle Newsで単なるリポジトリ公開以上のものとして扱われた理由だ。DeepSeekは競争力のあるモデルで広く知られるようになったが、Harnessは、モデルが実作業をどう遂行するかを決めるソフトウェアへと注目を移す。

生の言語モデルは入力を受け取り、出力を生成する。一方、実用的なエージェントは、いつツールを呼び出すか、どの履歴を保持するか、どこでコマンドを実行できるか、いつ人間の承認を必要とするかも判断しなければならない。

こうした判断が、似たモデルを使う二つの製品の挙動が異なる理由を説明することは少なくない。周辺システムは、失敗したコマンドから復旧し、計画を維持し、コンテキストを圧縮し、安全でないファイル操作を防止できる。同時に、これらの責務のいずれも誤って扱う可能性がある。

DeepSeekは、その周辺システム自体を製品にしようとしている。同社が提供するWebアプリケーションは、基盤コンポーネントの可能な構成の一つであり、すべてのユーザーが受け入れなければならない特権的な実装ではない。

このフレームワークは、動的に構成されるソフトウェアのためのメタフレームワークとしてDeepSeekが説明するCordis上に構築されている。Cordisでは、プラグインが共有コンテキストにサービス、型付きイベント、可逆的なエフェクトを提供できる。

可逆的なエフェクトとは、提供元コンポーネントがアンロードされた際に元に戻せる、追跡対象の変更を指す。これによりランタイムは、未知の状態を残さずに機能を追加・削除するための構造化された手段を得る。

この基盤が、DeepSeekのより大きな約束を支える。開発者は設定を通じて、ローカルファイルシステムプロバイダーをリモート実装に置き換えたり、モデルアダプターを変更したり、別のエージェントループを導入したりできるはずだ。

今回のリリースは、すべての組み合わせが信頼性高く動作することを証明するものではない。ただし、他のエージェント製品が固定的に扱うことの多いコンポーネントの周囲に、DeepSeekがプラグイン境界を設けたことは示している。

この違いが中心的な緊張を生む。置き換え可能な仕組みが増えるほど開発者の制御は強まるが、同時に管理すべきインターフェース、依存関係、障害モードも増える。

DeepSeek Harnessが完成済みコーディングエージェントに与える圧力

DeepSeekは、開発者がエージェントを周辺部分でのみカスタマイズすべきだという前提に異議を唱えている。

多くのコーディングアシスタントは、明確な方針を持つ中心部を維持しながら拡張機構を公開している。開発者はツールの追加、外部サービスとの接続、スキルのインストール、指示の変更を行える。それでも製品は、主要ループ、セッションモデル、インターフェースを管理し続ける。

DeepSeek Harnessは、置き換え可能な境界をより内側へ移す。アーキテクチャドキュメントによれば、開発者がパッチを当てる必要のある特権的なコアは存在しない。

デフォルトのエージェントループでさえ、他の機能と同じ共有コンテキストを通じて登録される。このループは、ユーザー入力がどのようにモデルリクエスト、ツール呼び出し、結果、そして後続ステップへ変わるかを制御する。

これはClaude Code、Codex、または類似製品を時代遅れにするものではない。成熟したコーディングエージェントは、インストール、更新、認証、モデルアクセス、安全ルール、インターフェース上の判断を一貫した体験へとまとめている。

このパッケージ化には実際の価値がある。今日中にテストを修正する必要がある開発者は、アーキテクチャ上の選択を求めるフレームワークより、妥当なデフォルトを備えたツールを好むかもしれない。

DeepSeekが代わりに圧力をかけているのは、異なるデフォルトを求める研究チーム、プラットフォームエンジニア、組織だ。これらのユーザーは、カスタムサンドボックス、社内モデルゲートウェイ、管理されたストレージ、監査可能な実行経路を必要とする場合がある。

置き換え可能なモデルアダプターは、特に重要だ。これにより、エージェントの挙動を単一のモデルプロバイダーへの排他的な依存から切り離せる。

DeepSeek自身のAPIドキュメントではすでに、拡張可能なPiコーディングエージェントを含むサードパーティ製ハーネスを取り上げている。Pi統合ガイドにも、DeepSeekはサードパーティの有効性や安全性を保証しないという免責事項が含まれる。

Harnessは別の回答を提供する。DeepSeekモデルを外部エージェントに適応させるよう開発者に求めるのではなく、DeepSeekは周辺アーキテクチャを提供しつつ、他のモデルプロバイダーも利用可能にできる。

これにより主な競争は、DeepSeek対特定の一社という構図ではなくなる。高度に設定可能な基盤と、完成された明確な方針を持つエージェント製品の競争である。

基盤を選ぶ道では、組織がシステムの動作を定義できる。チームは計画に一つのモデル、コード生成に別のモデル、機密性の高い分類にローカルモデルを使える。プロバイダーは共通のアダプター境界の背後に置ける。

同じチームは、異なるエージェントに異なるツールを割り当てることもできる。データベース専門エージェントには読み取り専用アクセスを与え、デプロイメントエージェントには限定的なリリース制御を与える、といった形だ。

こうした制限は、登録済みの機能と実行ポリシーに組み込める。システムプロンプト内の一文だけに依存する必要はない。

明確な方針を持つ製品を選ぶ道では、異なるトレードオフが生じる。ユーザーが理解すべき選択肢の数を抑え、サポート対象の経路にテストを集中させ、一貫したサポート対象を作り出す。

したがってDeepSeek Harnessは、必ずしも日常ユーザーのレイヤーではなく、アーキテクチャのレイヤーで既存製品に圧力をかける。競合他社は、自社の内部機構のどこまでを開発者が置き換えられるようにすべきかを判断しなければならない。

競合他社は中心部を管理下に置いたまま、サポート対象の拡張機能を増やすことができる。より低レベルのSDKやサービスを公開することもできる。また、全面的な置き換えは十分な実用的利益をもたらさずに運用上の複雑さを生む、と主張することもできる。

直ちに求められる対応は、同等のフレームワークとは限らない。より強いシグナルとなるのは、エージェントベンダーが自らのアーキテクチャ境界を明確にし、より多くの挙動を検査可能にするかどうかだ。

エンタープライズの購入担当者にとって、これは抽象的な違いではない。固定されたセッションシステムは保持要件と衝突する可能性がある。固定されたサンドボックスは組織のインフラをサポートできないかもしれない。固定されたツールパイプラインには必要な承認ゲートが欠ける場合がある。

Google News経由で今回の公開を追う開発者は、したがって所有権に注目すべきだ。DeepSeekは、追加の作業を伴う場合でも、チームがエージェントスタックのより多くを所有すべきだと提案している。

エージェントループを含め、すべてがプラグイン

注目すべき仕組みはプラグインの数ではなく、プラグインが置き換えられない保護された中心部が存在しないことだ。

実行中のDeepSeek Harnessインスタンスは、プラグインツリーとして組み立てられる。プロファイルは名前付きの構成を定義し、バンドルは設定行と、それらの行がマウントするコードをパッケージ化する。

DeepSeekはWeb用とヘッドレス用のテンプレートを提供している。ベースバンドルは、モデルアダプター、ツール、永続化、サンドボックス制御、承認ポリシー、認証情報、設定、テレメトリーを提供する。

追加のバンドルは、ブラウザーアプリケーションや単発ランナーを加えることができる。設定レイヤーは順番に適用され、後から加えるパッチによって行を置き換えたり、新しい行を導入したりできる。

この構成により、二つのエージェントは同じコードの多くを共有しつつ、異なる機能を公開できる。一つのプロファイルにはブラウザーインターフェースとローカルシェルを含め、別のプロファイルは自動化ワークフロー内でサーバーなしに実行できる。

プロジェクトは中核的な挙動をパッケージに分割している。セッションは追記専用のイベントログを所有し、記録されたイベントは黙って上書きされず追加される。ツールにはスコープ付きレジストリと、保護された実行パイプラインがある。

システムプロンプトパッケージは、プロンプトセクションとツールスキーマを組み立てる。言語モデルパッケージは、メッセージの語彙とプロバイダーアダプター境界を提供する。エージェントパッケージは、実行中のエージェントと関連イベントを公開する。

一つのターンには複数のステップを含められる。各ステップは一つのモデルリクエストと、そのリクエストから呼び出されるツールで構成される。

実行前には、プラグインが定義済みイベントを通じて作業を検査または拒否できる。モデル出力はセッションへストリーミングされ、ツール呼び出しは実行前と実行後の段階を通過し、その結果が次のモデルリクエストを引き起こすことがある。

このイベント構造は重要だ。なぜなら、拡張性だけでは一貫した挙動を保証できないからである。プラグインには、プロセスを観察、変更、停止できる合意済みのポイントが必要だ。

DeepSeekは、再読み込み後も残るべき事実には永続的なセッションイベントを使用する。現在進行中の作業にはライブエージェントイベントを使う。機能イベントにより、ポリシーとアダプターはループ全体をインポートせずにサブシステムへ接続できる。

セッションログは、モデルから見えるコンテキストの信頼できる唯一の情報源として機能する。DeepSeekによれば、モデルリクエストに到達するあらゆる情報は、そのログから再構築可能でなければならない。

この選択は、しばしば独立して実装される複数の機能を結びつける。再開、フォーク、トランスクリプト、永続化、リプレイ、テレメトリーは、同じイベントストリームから導出できる。

代替案は、インターフェース、モデルコンテキスト、保存済み履歴、可観測性システムのために別々の表現を維持することだ。これらのコピーは、エラー、キャンセル、コンテキスト圧縮の後に乖離する可能性がある。

DeepSeekの設計が乖離を自動的に排除できるわけではない。プラグイン実装には依然としてバグが含まれうる。ただし、共通のイベントソースがあれば、何が起きたかを検査するための明確な場所が開発者に与えられる。

機能の接続点は、さらに別のレイヤーを加える。DeepSeekは、サービスインターフェース、そのインターフェースを実装するプロバイダー、そしてサービスを利用するコンシューマーによって接続点を定義している。

ファイルシステムへのアクセスを考慮してください。モデル向けツールはファイル操作を要求する場合がありますが、ファイルシステムプロバイダーが、その操作をどこでどのように実行するかを決定します。

プロバイダーを置き換えることで、機能の実行先をローカルワークスペースからリモートサンドボックスへ移せます。関連するシェル、ターミナル、言語サーバーの操作も、その実行環境を共有できます。

これは既存アシスタントにコマンドを追加するよりも深い形のモジュール性です。すべての利用側を書き直すことなく、アシスタントの作業場所とポリシーを変えられます。

サブエージェントにも同様の境界があります。あるプロバイダーは Harness 内で子エージェントを作成し、別のプロバイダーは親インターフェースを維持したまま、タスクを別製品へ委任できます。

Cordis はその基盤となる合成モデルを提供します。付随するフレームワーク論文では、時間的合成可能性を、コンポーネントを取り除き、その影響を完全に元に戻すこととして説明しています。

同論文は、空間的合成可能性を、依存関係を宣言し、共有コンテキストの変化に反応することと定義しています。Cordis は、追跡可能なエフェクト、依存関係の解決、設定の調整、ホットモジュールリプレースメントを通じて、これらの概念を組み合わせます。

この論文は2026年8月13日付のドラフトとして公開されました。著者らは、現在も改訂中のプレプリントであり、内容が大幅に変わる可能性があると注意を促しています。

この注意書きは重要です。形式的な語彙はアーキテクチャの議論を容易にしますが、それ自体が性能、信頼性、セキュリティを検証するものではありません。

DeepSeek の仕組みがなお魅力的なのは、理論を観察可能なリポジトリ構造と整合させているためです。アーキテクチャ文書には、サービス、パッケージ、イベント、設定レイヤー、置き換えポイントが明記されています。

その結果は、単一のアシスタントというより、エージェントのための実行環境に近いものです。モデルとツールはこの環境上のアプリケーションであり、コンテキストとイベントシステムがそれらを調整します。

開発者にとっての利点は、制御された再構成です。DeepSeek にとっての利点は、戦略的な到達範囲にあります。同社のモデルは参加できますが、Harness はエコシステム全体が単一のモデル群に依存することを要求しません。

Developer Preview の注意書きこそが本当のリスク

DeepSeek の柔軟性に関する主張はコード上で確認できますが、本番運用への準備が整っているかは未証明であり、明確に免責されています。

リポジトリは、互換性を破る変更が発生すると大文字で警告しています。これは些細なリリースノートではありません。組織がこのプロジェクトを評価する方法を変えるものです。

チームは今日から DeepSeek Harness を試せます。しかし、プロファイル、プラグイン契約、設定ファイル、内部サービスが更新をまたいで安定し続けるとは考えるべきではありません。

この不確実性は、置き換え可能なインターフェースを中心に設計されたフレームワークにとって特に重要です。アーキテクチャが直接結合を最小化していても、各カスタムコンポーネントは何らかの契約に依存しています。

その契約が変われば、プラグイン開発者は実装を更新しなければなりません。深いモジュール性は変更を封じ込められますが、境界を維持するコストをなくすことはできません。

設定にも微妙なリスクがあります。文書化されたレイヤリングシステムは、対象行の設定全体を置き換えるため、ネストされた値をすべて自動的に組み合わせるわけではありません。

このルールは、経験豊富な運用者にとって予測可能です。一方で、部分的なパッチが未指定のフィールドを保持するとユーザーが想定した場合、設定漏れを招く可能性があります。

より大きな課題は、組み合わせテストです。完成した製品なら、モデル、ツール、サンドボックス、インターフェースの組み合わせを限定して検証できます。

各レイヤーの変更を許容するフレームワークは、はるかに大きな互換性の範囲に直面します。DeepSeek が、すべてのサードパーティ製モデルアダプターを、あらゆるツールパイプラインおよびストレージプロバイダーとの組み合わせで現実的にテストすることはできません。

したがって、責任はプロファイル作成者とデプロイチームへ移ります。彼らは、実際に運用する予定の正確な構成をテストしなければなりません。

セキュリティにも同様の注意が必要です。置き換え可能なサンドボックスとツールポリシーは、より強力な隔離の機会を生みますが、置き換え可能であることが安全な設定を保証するわけではありません。

寛容なサブプロセスプロバイダーは、慎重に制限されたツールリストを損なう可能性があります。カスタムプラグインは、認証情報を不適切に扱ったり、機密コンテキストを露出させたり、想定された承認動作を回避したりするおそれがあります。

オープンソースであれば、レビュアーはそうした経路を調査できます。しかし、dsh-plugin トピックを付けたすべてのプラグインがセキュリティ監査を受けていることを意味するわけではありません。

プラグインの発見自体も、信頼の問題になります。開発者には、来歴、バージョン互換性、保守状況のシグナル、そしてどのコードがセッションや認証情報にアクセスするのかを理解する手段が必要です。

従来のパッケージエコシステムでも、悪意ある依存関係や放棄されたモジュールにはすでに苦慮しています。エージェントプラグインは、プロンプト、ソースコード、ツール結果、実行状態を観察し得るため、さらに機密性の高い役割を持つ可能性があります。

追記専用ログには別のトレードオフがあります。詳細なイベント履歴は再生と監査を支えますが、保存されたモデルコンテキストには、独自コード、社内文書、機密性の高いユーザー入力が含まれる可能性があります。

組織は、そのログの保存先、検索できる人物、利用可能な期間、削除要件の適用方法を決めなければなりません。

このフレームワークでは、ストレージも置き換え可能な関心事として扱われます。エンタープライズ対応は、実運用で再生保証を弱めずに保持期間とアクセス制御を設定できるかどうかに左右されます。

Google News の注目は、アーキテクチャへの熱意を裏付けのない性能主張へ変えてしまうリスクもあります。DeepSeek は今回の発表を通じて、Harness が競合製品よりも同社のモデルを高精度にすることを示してはいません。

このリリースは、プラグイン合成がタスク完了率を改善することを示す中立的なベンチマークを提供していません。また、Cordis のリカバリーが長時間実行される作業でより良い結果を生むことも証明していません。

有能なハーネスは、適切なツールとコンテキストを提供することで、モデルをより有用にできます。しかし、基盤となるモデルのあらゆる限界を修復できるわけではありません。

弱い計画立案は、依然として弱い計画立案です。不適切なツール選択はなお失敗を招きます。エージェントは、失敗したアプローチの完璧なログを残すこともあります。

リリース直後に公開されたユーザー報告は有用な手掛かりを示す可能性がありますが、統制されたテストの代わりにはなりません。初期導入者には自己選択の偏りがあり、設定は異なり、新奇性が判断に影響することもあります。

開発者は、代表的なリポジトリと再現可能なタスクを使ってフレームワークを評価すべきです。テストには、中断された操作、拒否された権限、失敗したツール、コンテキスト圧縮、プラグインのアップグレードを含める必要があります。

また、同等のモデルとツール構成を比較すべきです。そうしなければ、好ましい結果はハーネスではなく、より優れたモデル、より広い権限セット、あるいはより単純なタスクを反映している可能性があります。

DeepSeek は、リリースを正確にラベル付けした点で評価に値します。Developer Preview の注意書きは、このプロジェクトが急速に進化しているという率直な期待を示しています。

次の問いは、採用が拡大しても DeepSeek がその明確さを維持できるかどうかです。安定したバージョニング、移行ガイダンス、セキュリティ報告、互換性テストは、当初のローンチスローガンよりも重要になります。

Google News の注目後に見るべきこと

DeepSeek Harness が持続的なインフラになるのか、それとも称賛される実験にとどまるのかを示すシグナルは3つあります。

最初のシグナルは、契約の安定化です。開発者は、プラグイン、プロファイル、セッションイベント、機能インターフェースに関する明確な互換性ポリシーがリリースノートに示されるかを注視すべきです。

初期プレビューにおいて破壊的変更は普通のことです。重要なのは、それらの変更が文書化された安定的な境界へ収束するかどうかです。

移行ツールがあれば、その根拠は強まります。明確な非推奨期間と機械検証可能な設定スキーマは、カスタムプロファイルの維持コストを下げるでしょう。

DeepSeek がアーキテクチャの進歩を止めずに主要な継ぎ目を安定化できれば、そのフレームワークに関する主張はより強くなります。プラグイン統合の度重なる書き換えは、それを弱めるでしょう。

2つ目のシグナルは、独立した運用上の証拠です。チームには、実際のリポジトリ、長時間のセッション、ツール障害、制約されたサンドボックスを含む再現可能なテストが必要です。

タスク成功は指標の一つにすぎません。評価者は、リカバリー動作、重複作業、コンテキストの正確性、権限の強制、障害診断に必要な労力も測定すべきです。

ベンチマークは、モデル能力とハーネスの挙動を分離する必要があります。可能な限り、同じモデルを異なるハーネス構成で実行すべきです。

信頼できるテストは、権限と利用可能なツールも公開すべきです。無制限のシェルアクセスを持つエージェントを、狭いサンドボックス内で動作するエージェントと安易に比較すべきではありません。

独立した評価が信頼できるリカバリーと検査可能な実行を示せば、DeepSeek の仕組みを裏付けることになります。結果が広範な手動チューニングに依存するなら、フレームワークは専門家にとってより有用なものにとどまるでしょう。

3つ目のシグナルは、プラグインエコシステムの品質です。リポジトリ数やソーシャル上の注目は、好奇心を測るものであって、信頼できる供給を測るものではありません。

有用なプラグインには、継続的に保守される文書、テストカバレッジ、セキュリティ対策、明確な互換性情報が必要です。信頼されるエコシステムには、悪意あるパッケージや放棄されたパッケージを報告するプロセスも必要です。

DeepSeek は、発見のためにプラグインリポジトリへタグを付けるよう開発者に促しています。次の段階は、どの拡張機能にツール、セッション、認証情報へのアクセスを認めるべきかを評価する、信頼できる方法を整えることです。

このシグナルが、誰がフレームワークを採用するかを決めます。研究チームは実験的なモジュールを自ら監査できます。大半のエンタープライズチームには、より小規模で、サポートされ、レビュー可能なコンポーネント群が必要です。

競合他社の反応も、この3つのシグナルの範囲で注目に値します。競合が DeepSeek の方向性を検証するために Cordis を複製する必要はありません。

より置き換え可能なサンドボックス、エクスポート可能なイベント履歴、文書化されたエージェントループ、あるいはより低レベルのオーケストレーション SDK はいずれも、開発者がインターフェースの下にある制御を求めていることを示すでしょう。

沈黙が自動的に失敗を意味するわけではありません。確立された製品は、使いやすさ、サポート、統合されたモデル性能によって勝ち続けることができます。

DeepSeek にとって最も強い成果は、市場が分かれることです。完成されたエージェントは一貫したツールを望むユーザーに対応し、Harness は交換可能な部品から専門的なエージェントを構築するチームに対応します。

この分化は、より広いソフトウェアの歴史を映しています。フレームワークと完成されたアプリケーションは、異なる所有権の問題を解決するため、しばしば共存します。

ナレッジワーカーは DeepSeek Harness を直接操作しないかもしれませんが、そのアーキテクチャはなお彼らに影響します。エージェントシステムは、プロジェクトファイル、社内調査、メッセージ、組織の知識にますます触れるようになっています。

こうしたシステムが失敗したとき、ユーザーはモデルが受け取ったコンテキストと、どのツールが動作したのかを知る必要があります。再構築可能なイベント履歴は、その調査をより具体的にできます。

関連する AI ワークフローを構築するチームは、情報源にも同じ規律を適用すべきです。保守されたAI ナレッジベースは、エージェントの出力を取り巻く文書と意思決定を保存できます。

この実践は、ランタイムの安全性を解決するものではありません。人々が、生成された結論と、それに至るために使われた証拠および組織的コンテキストを区別する助けになります。

最終的な評価は、狭く保つべきです。DeepSeek は、動作するコード、詳細な文書、そして異例に広いプラグイン定義を備えた、本格的なアーキテクチャ提案を公開しました。

しかし、一般的な開発者がその柔軟性を安全に管理できることは、まだ示されていません。サードパーティ製コンポーネントが互換性を維持することも、この設計がより良いタスク成果を生むことも証明されていません。

Google News の見出しは記憶に残るアイデアを捉えていますが、今後3か月は、安定した契約、独立した運用テスト、信頼できるプラグインによって評価されるべきです。

DeepSeek Harnessを評価するなら、まずは範囲を限定したワークフローから始める。モデル、ツール、権限、プロファイル、期待される結果を記録する。その後、実行を中断し、ツールを拒否し、プロバイダーを1つ置き換えたうえで、イベントログが依然として結果を説明できるかを確認する。この演習は、機能チェックリストよりも効果的にDeepSeekの実際の論点を検証できる。問われるのは、すべてをプラグインにできるかどうかではない。そうしたプラグインを置き換えても、信頼性、セキュリティ、そしてエージェントが何をしたのかを理解する能力を失わずに済むのか、という点だ。