DeepSeek Harness: 本当にすべてがプラグインになるとき

AIエージェントについて話すとき、私たちはほとんどの場合、まずモデルに注目する。どのモデルがより良いコードを書くのか。どれがより長いコンテキストを理解するのか。ベンチマークでより多くの課題を解くのはどれか。それは理解できるが、今では視野が狭すぎる。エージェントは言語モデルだけでできているわけではない。ツール、メモリ、セッション、権限、実行環境、計画、ログ、そして人間が介入するための何らかのインターフェースが必要だ。

だからこそ、DeepSeek HarnessのDeveloper Previewがとても興味深い。DeepSeekは、その考えを驚くほど明快な一文にまとめている。Everything is a plugin. 交換可能なのは追加ツールだけではない。モデル、スキル、セッション、サンドボックス、ストレージ、エージェントループ、スケジューリング、さらにはユーザーインターフェースまでプラグインとして扱われる。

一見すると、これは開発者向けの技術的な設計判断に思える。しかし実際には、AIの次の段階について、より大きな主張が含まれている。知性がモデルから来る一方で、実務能力がHarnessから生まれるのなら、その後半部分を単一ベンダーの不透明な塊にしてはならない。

エージェントはモデル以上のものだ

DeepSeek自身は、この関係を非常に簡潔に表現している。エージェントはモデルとHarnessの組み合わせだ。モデルは言語を処理し、判断を生成する。Harnessはモデルを現実の環境につなぐ。ファイルを用意し、ツールを登録し、状態を管理し、サブエージェントを起動し、コマンドを実行し、次のモデル呼び出しでどの情報を再びコンテキストに入れるかを決める。

したがってHarnessは、単なるモデルの包装ではない。モデルの応答が実際に何になれるかを決める。エージェントはテキストを出すだけなのか、それともファイルを変更できるのか。リポジトリ全体が見えるのか、作業フォルダだけなのか。コマンドはホスト上で直接動くのか、コンテナ内か、遠隔のサンドボックスか。人間の承認が必要なのか。状態は複数のセッションにわたって残るのか。これらはすべてモデルの性質ではなく、その周囲のランタイムが下す決定だ。

回答から行動へ

単純なチャットでは、この違いはほとんど目立たない。質問が入り、回答が返る。しかしエージェントがリポジトリで作業し、チケットを処理し、社内システムへアクセスし、長時間のタスクを引き受けるようになると、Harnessは少なくともモデルと同じくらい重要になる。言葉で示された意図を現実の一連の手順に変換し、その結果を新たなコンテキストとしてモデルへ戻すからだ。

まさにそこで、印象的なデモ技術が信頼できる道具になるかどうかが決まる。優れたモデルでも、コンテキストが悪く、権限が広すぎ、セッション管理が不安定なら、エージェントとしては悪い。見事に論じながら、間違ったファイルを編集したり、古い状態を使ったり、エラー後に適切に続行できなかったりする。逆に、少し弱いモデルでも、よく設計されたランタイムの中では驚くほど役立つことがある。適切なツールが見え、境界が明確で、作業を追跡できるからだ。

アーキテクチャも成果の一部になる

DeepSeek Harnessは、この層を見えるものにする。Cordisカーネルはプラグインをマウントし、依存関係を解決し、コンポーネントを再び取り外せる。機能はサービスとして提供される。例えば、あるプラグインがShellを実装し、別のプラグインがそのShellをモデル用ツールとして公開し、さらに別のプラグインがワークフロー内でそのツールを利用できる。具体的な実装は、Harness全体を作り直さなくても設定によって切り替えられる。

DeepSeekは、追加ツールをいくつか拡張として許すだけの多くのプラットフォームより先まで進んでいる。モデル接続、ツールレジストリ、セッションログ、そしてエージェントループそのものまでプラグインだ。アーキテクチャによれば、拡張のたびにパッチを当てる必要がある特権的なコアは存在しない。新しい振る舞いは既存コンポーネントの横にマウントされ、削除時には登録内容もきれいに解除できる。

これはまったく新しい考えではない。OS、ブラウザ、エディタ、プラットフォームは何十年もモジュール式コンポーネントによって発展してきた。新しいのは、DeepSeekがこの原則を完全なAIエージェントへ徹底的に適用している点だ。エージェントのアーキテクチャは固定された製品ではなく、運用者が変更できる判断の組み合わせになる。

「すべてがプラグイン」が魅力的な理由

プラグインという考え方は、完成品が持つ力を、組み立て可能なランタイムへ移す。作業方法をすべて作り直さずにモデル提供者を交換できる。ローカルShellを、より強く隔離された実装へ置き換えられる。別のストレージ、異なるセッションロジック、独自のインターフェースも使える。DeepSeekは自社のモデル接続に加え、他のプロバイダーと、ユーザー定義のOpenAI互換エンドポイントも文書化している。

すべてをやり直さずにモデルを交換する

これにより、エージェントは環境に合わせて構成するインフラに近づく。小さな開発チームには、ファイルアクセス、Git、テストだけで十分かもしれない。Securityチームなら、ネットワーク照会、隔離されたサンドボックス、より厳しい承認、改ざんできないログも求める。企業は独自のモデルゲートウェイを利用でき、個人ラボはローカルのOpen-Weightモデルへ接続できる。

モデルが急速に入れ替わる今、これは戦略的に重要だ。今日はあるベンダーがCodingで優れ、明日は別のベンダーが長いコンテキストやツール利用で上回るかもしれない。閉じた製品では、モデルの変更がプラットフォームの変更にもなりやすい。セッション、ルール、権限、統合、作業方法を再構築しなければならない。モジュール式ランタイムなら、モデルは別のプロバイダーや自社運用のエンドポイントへ交換できる一つのコンポーネントであり続ける。

もちろん、完全に摩擦がないわけではない。モデルによってロール形式、Reasoning、ツール呼び出し、画像対応、エラー時の振る舞いが異なる。その違いは各アダプターで適切に処理する必要がある。しかし、明確な継ぎ目の価値もそこにある。特定ベンダーの特殊性が、製品全体へ無秩序に広がらない。

交換可能なボタンではなく、交換可能なインフラ

特に興味深いのは、機能の定義、提供者、利用者を分けていることだ。Bashインターフェースは何ができるかを記述する。Providerはコマンドをどこで、どのように実行するかを決める。さらに別のプラグインが、モデルから呼び出せるToolにする。このような継ぎ目は重要だ。各エージェントループを作り直さなくても、そこにタイムアウト、隔離、承認、ログを組み込める。

複数の機能が同じ実行環境を共有すると、その可能性が明確になる。ファイルシステムとプロセスがローカル環境から遠隔サンドボックスへ移されれば、Shell、Terminal、コードナビゲーションも一緒に移せる。利用者から見える機能は似たままでも、その下のセキュリティと運用の枠組みは根本から変わる。この種の交換可能性は、画面にスイッチを一つ追加するより価値が高い。

複数のランタイムモードからもDeepSeekの狙いが見える。標準モードは完全なCoding Agentを提供する。Codeモードでは、モデルが生成したTypeScriptコードを通じて複数のツール呼び出しを調整できる。Minimalモードは、ベンチマーク向けにShellとEditorだけへ環境を縮小する。Creatorモードでは、プラグインや独自Presetを調べられる。すべての用途で同じ巨大なツール箱を読み込む必要はない。

ProfileとBundleは、これを単なる拡張機能の寄せ集め以上のものにする。Profileは、特定用途向けに定義されたエージェントランタイムを形作れる。ローカル開発向けの軽量Profile、本番システム向けの制限を強めたProfile、特に多くのログを残すフォレンジックProfileなどが考えられる。機能は同じ部品から構成されながら、その組み合わせと境界をリスクに合わせられる。

実用上の可能性はどこから生まれるのか

アーキテクチャは魅力的だが、価値が現れるのは具体的な場面だ。プラグインシステムはそれ自体が目的ではない。用途ごとに新しいプラットフォームを作らず、エージェントを現実の要件へ素早く適応させられなければならない。

個人の道具から企業プラットフォームへ

一人の開発者なら、ローカルShell、ファイルEditor、モデルから始められる。それがチーム用ツールになると、別の要件が加わる。中央管理されたID、分離されたWorkspace、重要操作の承認、モデルゲートウェイ、コスト管理、永続セッション、エクスポート可能なAudit Trailだ。モノリシックなアプリでは、これらがいつ提供されるかをメーカーが決める。

モジュール式ランタイムなら、企業は不足部分を自ら補い、既存Providerを置き換えられる。エージェントを一から発明し直す必要はない。同じインターフェースとエージェントロジックのまま、企業ゲートウェイの背後で別のモデルを使い、社内サンドボックスでコマンドを実行し、自社Storageにセッションを保存できる。便利なToolと、制御可能なPlatformの違いはここにある。

同じ部品から異なる信頼ゾーンを作る

すべての作業に同じ権限が必要なわけではない。文書を要約するエージェントに本番アクセスは不要だ。Incident Response用エージェントにはログデータやネットワーク照会が必要かもしれないが、設定変更は許すべきではない。Deployment用エージェントは変更を実行できても、より厳しい承認、短いToken、特に明確なログが必要だ。

適切に分離されたServiceとProfileがあれば、この違いをランタイムで表現できる。モデルがすべてのセキュリティ詳細を理解し、自発的に守る必要はない。環境が、そもそもどの機能を提供するかを技術的に決める。Securityにとってこれは中心的な点だ。マウントされていない機能は、モデルが直接使えるToolとして存在しない。

専門家のためのエコシステム

一社だけで、最高のサンドボックス、最高のSession Store、すべての企業システム、すべてのモデルアダプターを同時に作ることはできない。開かれたプラグインモデルなら、専門家が一つの層だけを優れたものにできる。Securityベンダーは堅牢な実行環境を提供できる。Storageプロジェクトは監査可能なセッションを届けられる。社内プラットフォームチームは、承認とIDを自社組織へ接続できる。

安定したインターフェースでこれらが組み合わされば、膨張し続ける単一アプリではなく、エコシステムが生まれる。おそらくこれがDeepSeek Harnessの最大の可能性だ。DeepSeekがすべての用途を制する必要はない。他者が自分たちの機能を提供し、組み合わせる場所として、このアーキテクチャが選ばれれば十分だ。

追跡可能性は脇役ではない

プラグインに並ぶもう一つの強い考えは、append-onlyのSession Logだ。DeepSeekによれば、モデルが見るものはすべてEventとして記録される。System Instruction、Tool呼び出しと結果、コンテキスト注入、サブエージェントの計画も含まれる。再開、分岐、検索、再実行は同じEvent Streamを基礎にする。

開発者にとっては、失敗した実行を再構成できるため実用的だ。Securityと運用にはさらに重要になる。エージェントがファイルを変更し、コマンドを起動し、データをサービスへ送ったとき、最後のチャットメッセージだけでは足りない。どのコンテキストが存在し、どのToolが関わり、判断がどの時点で行動へ変わったかを追跡できなければならない。

従来のアプリでは、障害を入力と決定論的なコード経路へ遡れることが多い。エージェントでは難しい。同じ大まかな依頼でも、モデルは異なる中間手順を導き、別の順序でツールを使い、予想外の結果へ反応できる。完全な履歴がなければ、最後にはエージェントがそう決めたという主張しか残らない。それではDebugにもSecurity Incidentにも足りない。

Event StreamをSource of Truthにする判断は、もう一つの可能性を開く。より比較しやすい実験だ。セッションを特定地点で分岐し、別のモデル、変更したPrompt、異なる機能で続けられる。どのモデルがきれいな回答を書くかだけでなく、一つの具体的な変更が同じ現実の作業状態へどう作用するかを調べられる。

企業では、長期的にエージェント向けのChange LogやIncident Logに発展するかもしれない。誰が依頼したのか。どのPolicyが有効だったか。モデルはどのデータを受け取ったか。どの操作が承認されたか。何が結果として返ったか。エージェントが助言だけでなく実システムを変更するようになれば、これらの問いは重要になる。

ただし、ログがあるだけで完成したAudit Trailになるわけではない。保持期間、アクセス保護、完全性、機密情報、Exportを適切に解決する必要がある。完全なログは、Prompt、ソースコード、Toolの結果、認証情報を含むなら、それ自体がリスクにもなる。それでも基本判断には共感する。モデルに見える情報は隠れた脇道から来るのではなく、再構成可能なEvent Streamから来るべきだ。

オープンソースが戦略的な武器になる

このプロジェクトが中国から生まれたことは、さらに興味深い。DeepSeekはモデルWeightsだけを公開するのではなく、Stackの複数層を目に見える形で作り始めている。DeepSeek V4はWeightsとCodeをMIT Licenseで提供している。そこへ、同じくMIT LicenseのHarnessが加わり、エージェント作業のための開かれたランタイムになる。その下にはCordisという独自のプラグインと構成モデルさえある。

これは、私がAI、セキュリティ、完全なStackをめぐる競争で書いた動きと一致する。中国はAIアプリを消費するだけではない。中国企業はモデル、推論ソフトウェア、ハードウェア経路、そして今ではその上のエージェントインフラまで構築している。DeepSeekの速度は、中国を単なる模倣産業とみなす西側の古いイメージではもはや説明できない。

この競争におけるオープンソースは、理想主義だけではない。配布手段であり、検証可能性による信頼であり、エコシステムを加速する装置だ。Weights、Code、Interfaceを公開すれば、世界中の開発者がバグを見つけ、連携を作り、その設計をDe Facto Standardへ押し上げる。開かれたHarnessは、他社モデルが内部で動いても関係性を保てるため、DeepSeekにとって閉じたチャット画面をもう一つ作るより戦略的価値が高いかもしれない。

これは注目すべき点だ。DeepSeekは、自社のDeepSeekさえ交換可能なプラットフォームを作っている。短期的には矛盾して見える。なぜモデル提供者が競合への乗り換えを容易にするのか。長期では、それこそがより強い立場になり得る。開発者がエージェント、プラグイン、セキュリティルール、セッションをこのランタイム上に構築すれば、Harnessが共通インフラになる。DeepSeekはモデル呼び出しをいくつか失っても、エコシステム全体のアーキテクチャへ影響力を得られる。

開放性は学習も速める。閉じた製品では、中核アーキテクチャの進化は主にメーカーの手に残る。開かれたプロジェクトは、元のチームが完全には予測できなかった環境で使われる。そこからBug Report、新しいAdapter、代替Backend、運用知識が生まれる。エージェントソフトウェアのような若い分野では、このFeedback Loopが完璧な最初のReleaseより重要かもしれない。

プラグイン方式の賢さも、まさにそこにある。DeepSeekはすべてのStorage、Sandbox、企業システムを自ら作る必要がない。他者がそれらの機能を差し込めるアーキテクチャを提供する。エコシステムが育てば、新しい統合の一つ一つがコアにも利益をもたらす。

中国はモデルだけでなく、その周囲の道筋も作っている

地政学的な意味はBenchmark値だけにはない。強力なモデルがどこかで訓練されたというだけでは、国や経済圏は技術的に自立できない。ハードウェア、推論ソフトウェア、開発ツール、Interface、運用経験、そしてその上で製品を作る開発者が必要だ。DeepSeek Harnessは、まさにその連鎖を構成するもう一つの部品だ。

中国技術についての西側の物語は、この発展に遅れがちだ。中国を主に安価な模倣者と見続ければ、独自アーキテクチャが公開され、世界の開発者へ働きかける速度を見落とす。DeepSeekがあらゆる分野で永久に首位である必要はない。差を小さく保ち、高速で反復し、他者がその上に構築できる形で成果を開けば十分だ。

閉じた最先端モデルとの差は縮まっている

Open-Weightモデルは長い間、ラボや特殊用途向けの興味深い選択肢と見なされ、本当に強い能力は少数の閉じたベンダー側にあると思われてきた。この図式は崩れつつある。すべての分野で差が消えたわけではないが、多くの予想より速く詰まっている。

DeepSeekは自社評価でV4モデルを最新の閉じた最先端モデルと直接並べている。BenchmarkによってV4 Proは近い位置に達し、同等の値を示すこともあれば、明確に遅れることもある。Software Engineering、Tool利用、事実知識、非常に難しいReasoningで結果は一様ではない。だからこそ、一つの表から「勝者」を決めるべきではない。

より重要なのは時間的な距離だ。つい最近まで最大手の米国Labだけの優位と考えられていた能力が、数か月後にはWeightsをダウンロードし、自社運用し、調査できるモデルに現れている。「最先端モデルから数か月遅れているだけ」は自然科学的に測れる定数ではない。それでも、閉じたシステムの優位が今どれほど短命に見えるかをよく表している。

その結果、優位性の経済的な意味も変わる。閉じたモデルが特定課題で10パーセント優れていれば、決定的になることはある。しかし開かれたモデルが十分に良く、自社インフラで動き、自社のセキュリティゾーンへ統合できるなら、総合判断で開かれたモデルが勝つ場合もある。制御、データ所在地、予測可能なコスト、独自調整の余地も性能の一部であり、Benchmarkには現れない。

ただしハードウェアを忘れてはならない。Weightsが公開されていても、1.6兆Parameterのモデルが簡単にサーバールームで動くわけではない。DeepSeek V4 Proは巨大なMixture-of-Expertsモデルだ。Tokenごとに有効になるParameterが一部だけでも、メモリ、推論コスト、運用は依然として重い。つまり開放性はCodeとWeightsへのアクセス障壁を取り除くが、大規模モデルの物理的現実までは消さない。

それでも、Weightsの存在だけで市場は変わる。研究者はモデルを調べられる。Providerは自社インフラで提供できる。Communityは量子化やランタイム最適化を開発できる。企業は少なくとも、一つのAPIへ完全に依存する以外の選択肢を得る。

競争の軸も移る。モデルの生の知識は重要であり続けるが、持続的な価値はData Pipeline、Evaluation、Runtime、Security、Distribution、実際のProcessへの組み込みにも生まれる。開かれたHarnessはこの変化に正確に合う。モデルの交換が容易になるほど、信頼性のあるコンテキスト、ツール、境界を提供するプラットフォームが強くなる。

オープンであることは、信頼できることと同じではない

どれほど期待していても、「中国発のオープンソース」を自動的に主権性と同一視するのは無邪気すぎる。ホストされたDeepSeekサービスを使えば、データは依然として外部事業者へ送られる。データ主権が本当に変わるのは、自社運用のモデルエンドポイントと管理されたHarnessを使うときだ。それでも出所、Build Process、依存関係、UpdateはSupply Chainの一部として残る。

プラグインはこの責任をさらに重くする。プラグインは無害なThemeではない。Toolを登録し、Serviceへアクセスし、システム上でCodeを実行できる。DeepSeekの文書はGit Repositoryからのインストールについて、許可されたBuild ScriptがエージェントのSandbox外でHost上に実行され得ると明確に警告している。信頼できるSourceだけを許可し、依存関係を特定Commitへ固定するよう勧めている。

これはまさに必要な警告だ。開かれたプラグインプラットフォームは交換可能性を生む一方、新しいSupply Chainも作る。追加のProviderはPrompt、File、Credential、実行可能なToolへアクセスできる可能性がある。侵害されたプラグインは、すでにランタイムの正規部分なら、派手なモデルJailbreakを必要としない。

ソースコードを閲覧できることは利点だが、それだけではSecurity Reviewにならない。誰かが実際にCodeを読み、Buildを再現し、Versionを固定し、Updateを管理しなければならない。プラグインエコシステムが成長するほど、出所は機能とほぼ同じくらい重要になる。出所不明の便利なプラグインは、機能が欠けていることより大きなリスクになり得る。

本格運用なら、私は少数の検証済みプラグインだけを使う。Versionを固定し、権限を分離し、Secretは設定の外で管理し、外向き通信を制御する。Sandboxは名前だけでなく、本当に隔離しなければならない。Session Logは保護し、機密データを点検する必要がある。何より「すべてがプラグイン」という主張を、「すべてのプラグインが何でもできる」にしてはならない。

したがって長期的な可能性はGovernanceにもかかっている。優れたプラットフォームには、理解しやすいProvenance、署名済みArtifact、再現可能なBuild、明確な依存関係、Profileごとに機能を制限する方法が必要だ。DeepSeekとCommunityがこうした地味な基盤を真剣に扱えば、開放性は本当の制御につながる。そうでなければ、プラグインという約束は非常に大きな攻撃対象領域になるだけだ。

DeepSeek Harnessに今後求めたいもの

DeepSeekはこのプロジェクトを意図的にDeveloper Previewと呼び、非互換な変更を予告している。今は読み、試し、重要でないデータでテストするには良い時期だ。ただし、中心的な本番ワークフローを依存させる理由にはまだならない。

整理されたアーキテクチャから堅牢なエコシステムが生まれるかが重要になる。署名済みRelease、追跡可能なプラグインの出所、明確な権限モデル、再現可能なBuild、変更のたびに信頼を求めないUpdate Processが必要だ。プロジェクトが急速に進化するとき、異なるProviderのプラグインが実際にどれほど組み合わせられるかも同じくらい重要になる。

約束された交換可能性が日常で通用するかも見たい。モデルアダプターは紙の上では簡単に交換できる。現実には、モデルごとにTool呼び出し、Reasoning、Context形式、画像対応、Failure Modeが異なる。開いたインターフェースはその差を小さくするが、消し去るわけではない。

こうした留保はあるものの、DeepSeek Harnessは今年もっとも興味深いAIプロジェクトの一つだと思う。すでに最高のCoding Agentでなければならないからではない。中国のAI企業がモデルより上の層を開き、組み立て式のシステムにしている点が面白い。他社がエージェントを閉じたプラットフォームへ深く統合する一方で、DeepSeekは自社モデルさえ交換可能なプラグインにすぎないアーキテクチャを選んでいる。

私の印象と、信じられないほどの速度

Developer Previewだけでも、大きな可能性を感じる。画面はプラグインという原則を具体的にし、Trajectory表示は追跡可能性を後付けにするつもりがないことを示している。プロジェクトはまだ若く、多くが動いている。それでも、この開かれたアーキテクチャは、非常に速く大きなものが生まれ得る土台に見える。

いまAIの世界では、数週間の差さえ古く感じるほど多くのことが起きている。Alphabetだけで2026年に1,750億から1,850億ドルの設備投資を見込み、Metaも1,150億から1,350億ドルを投じ、いずれもAIインフラの影響を強く受けている。そう考えれば驚く必要はない。何千億ドルもの資金が突然、同じ考え、同じ競争、同じ未来へ流れ込んでいる。

資金が良い製品を保証するわけではない。しかしモデル、データセンター、エージェントプラットフォームが、数年前には考えられなかった速度で進む理由は説明できる。モデルは交換しやすくなり、公開Weightsは急速に追いつき、決定的な差別化はHarnessへ移っている。DeepSeekは三つすべてで明らかにアクセルを踏んでいる。AIインフラを作る者は、これを単なる中国との競争物語としてではなく、閉じたStackへの自分たちの依存を見直す招待として読むべきだ。

それでは、また。
Joe