DeepSeek Harnessが登場、エージェントのランタイムをモデルの上位に置く
DeepSeekは2026年8月13日、モデル性能だけではない新たな領域を切り開くDeepSeek Harness v0.1を公開した。この開発者プレビューは、交換可能なモデル、ツール、スキル、セッション、サンドボックス、インターフェースからエージェントを組み立てるためのオープンソースランタイムをプログラマーに提供する。この動きによりDeepSeekは、言語モデルを実用製品へ変えるソフトウェア層で直接競争することになる。
これは新たなモデルチェックポイントではない。dshとも呼ばれるDeepSeek Harnessは、モデルがどのようにコンテキストを受け取り、ツールを呼び出し、ファイルを管理し、セッションを維持し、複数ステップの作業を完了するかを決定する。実際のタスクでは、こうした判断が基盤モデルそのものと同じほど重要になり得る。
このリリースは、開発者市場におけるDeepSeekの立ち位置も変える。これまで多くのチームは、他社ベンダーや独立プロジェクトが管理するエージェント製品の中でDeepSeekモデルを利用してきた。DeepSeekはいまや、推論エンジンとそれを取り巻くランタイムの両方に影響を及ぼせる。
したがって中心となる競争は、単にDeepSeekと別のモデル提供者との対決ではない。Claude CodeやOpenAI Codexのような垂直統合型エージェントに対する、オープンで組み合わせ可能なランタイムの競争である。DeepSeekはより多くの交換可能なコンポーネントを約束する一方、プレビュー段階であることは、統合とセキュリティに関する責任をより大きく開発者側へ移すことを意味する。
DeepSeek Harnessはランタイムであり、新たなモデルリリースではない
重要な変化は、DeepSeekが各モデル呼び出しの前・最中・後に何が起きるかを制御するソフトウェアを提供するようになった点にある。
エージェントハーネスは、モデルをツール、メモリ、ファイル、権限、インターフェース、実行ループへ接続するランタイム層だ。モデルが何を観測できるか、どのアクションを要求できるか、そしてシステムがその要求をどう処理するかを決める。
DeepSeekは新プロジェクトを、「すべてがプラグイン」という原則を中心に構築されたオープンソースのエージェントハーネスと説明している。公式のプロジェクトリポジトリでは、モデル、ツール、スキル、セッション、サンドボックス、ファイルシステム、ループ、オーケストレーション、ユーザーインターフェースを交換可能なコンポーネントとして挙げている。
この一覧は、リリースの範囲を示している。DeepSeekが提供しているのは、固定されたワークフローを持つコーディングチャット画面だけではない。開発者が異なるエージェント製品を構築できる組み立て層を公開している。
最初の開発者プレビューには、ローカルで実行されるWebインターフェースが含まれる。Node.jsを利用できる開発者は、@deepseek-ai/dshパッケージを通じて起動でき、デフォルトではローカルアドレスでインターフェースが提供される。
リポジトリには、グラフィカルインターフェースを必要としないタスク向けのヘッドレスプロファイルも含まれている。文書化された例の一つでは、コマンドラインからエージェントにワークスペースの要約を求める。別の例では、標準入力・出力を介したJSON-RPCを使う自動化プロトコルを通じてエージェントセッションを公開する。
こうした入口により、DeepSeek Harnessはいくつかの役割を担える。個人開発者はローカルエージェントインターフェースとして実行できる。チームは社内エージェントの基盤としてパッケージを使える。製品企業は完全なインターフェースを採用せずに、選択したサービスを統合できる。
DeepSeekはこのプロジェクトをMITライセンスで公開した。このライセンスは、必要な著作権表示とライセンス通知を保持することを条件に、幅広い利用、改変、再配布を認める。
ハーネスは組織の運用環境に特に近い位置にあるため、ライセンスの選択は重要だ。リポジトリ、コマンドライン、社内文書、認証情報、外部サービスに触れる可能性がある。企業はこの層を承認する前に、しばしば検査や改変を必要とする。
リポジトリはv0.1を完成したエンタープライズ製品ではなく、開発者プレビューとして位置づけている。DeepSeekは、互換性を破る変更が発生すると明示的に警告している。開発者はこのリリースを、安定したインターフェースの約束ではなく、実験と貢献への招待として受け取るべきだ。
この警告は、リリースの重要性を損なうものではない。8月13日に何が変わったのかを明確にする。DeepSeekは、モデルとAPIを通じて知能を提供する段階から、知能を行動へ変える運用構造を提供する段階へと移った。
DeepSeekがエージェントスタックの上位へ進む理由
モデルへのアクセスは交換可能になりつつあり、その一方でハーネスはエージェントの有用性、制御可能性、代替しにくさを左右する存在になっている。
生のモデルはコードを生成し、要求を分析し、コマンドを提案できる。しかし、別のシステムがその機能を提供しない限り、リポジトリを自律的に調査したりファイルを変更したりはできない。ハーネスがそのシステムを供給する。
この違いは、長時間にわたるタスクで明確になる。コーディングエージェントは、どのファイルを調べるか、どの情報を保持するか、いつツールを呼び出すかを決めなければならない。失敗したコマンドを検出し、計画を修正し、一貫したセッションを維持する必要もある。
同じモデルを使う二つの製品でも、ハーネスの選択が異なれば性能は変わり得る。一方はより明確なツール説明を提供するかもしれない。別の製品はコンテキストをより効果的に要約するかもしれない。さらに別の製品は、より強力なサンドボックスでコマンドを隔離するかもしれない。
この現実はモデルベンダーに圧力をかける。外部のエージェントがインターフェース、ワークフロー、ツール統合、ユーザー履歴を所有するなら、基盤モデルは交換可能な入力になり得る。ハーネス提供者は顧客との関係を保持し、どのモデルにトラフィックを送るかを決める。
DeepSeek Harnessはこのリスクに直接対処する。モデルコンポーネントを交換可能なままにしながら、DeepSeekモデルをデフォルトにできるソフトウェア層をDeepSeekに与える。同社はオープンなアーキテクチャを捨てずに、ランタイムへの影響力を得ようとしている。
このタイミングは、会話型アシスタントから複数ステップの作業を完了するエージェントへの業界の移行にも沿っている。開発者はいまや応答品質以上のものを評価する。ツールの信頼性、コンテキスト管理、実行の安全性、可観測性、失敗からの回復を重視している。
DeepSeek自身のドキュメントにも、こうした運用上の懸念が反映されている。開発ガイドではホストとクライアントのシステムを分け、自動チェックを文書化し、シミュレーションと実APIの両方によるテストを説明している。また、Web、ヘッドレス、自動化で利用するためのインターフェースも提供する。
これはAPIエンドポイントとは異なる製品表面だ。APIは安定したままでも、外部開発者が周辺のワークフローを生み出せる。ハーネスは、プラグインが実行中のセッションに出入りするなかで振る舞いが変わる多数のサービスを協調させなければならない。
DeepSeekは開発者から学ぶ経路も得る。公開プラグインシステムは、どのツール、ワークフロー、エージェントパターンが採用を集めるかを明らかにし得る。そのフィードバックは、将来のモデル学習、ツール利用の振る舞い、API設計に影響を与えられる。
この戦略は、よく知られたプラットフォームのパターンに似ている。まず企業が中核となる技術コンポーネントを提供する。次に、開発者がそのコンポーネントをデータ、ツール、ユーザー体験と組み合わせるオーケストレーション層へ進出する。
ただしDeepSeekは、自社サービスだけでスタックを閉じようとしているわけではない。モデルプラグインの設計により、他社提供者やローカルモデルも同じ位置を占められる。この開放性こそが、今回のリリースにおける最も興味深い緊張関係を生み出している。
アーキテクチャが機能すれば、開発者が複数のモデルを組み合わせる場合でも、DeepSeekは影響力のあるエージェントプラットフォームになれる。そうならなければ、このプロジェクトは主にDeepSeekのAPI向けの別インターフェースとして機能することになるかもしれない。
この違いは、DeepSeekの既存ユーザー層以外での採用に左右される。開発者はプラグイン契約を競合フレームワークより拡張しやすいと感じなければならない。チームは、機密性の高いツールやファイルを扱うランタイムを信頼する必要もある。
DeepSeek Harnessの賭けは、すべてを交換可能にすべきだというものだ
DeepSeekは、エージェント開発者が一つの厳格に管理された製品の利便性よりも、組み合わせ可能性を重視すると賭けている。
このプロジェクトのアーキテクチャは、DeepSeekが時空間的な組み合わせ可能性のためのメタフレームワークと呼ぶCordisを基盤としている。実用面では、Cordisは時間や実行コンテキストに応じて利用可能性と関係性が変化するサービスを管理する。
従来のアプリケーションは、多くの場合、依存関係を一度初期化し、それらを固定されたものとして扱う。エージェント環境は異なる。セッションはあるタスクのためにツールを有効化し、スコープを限定した実行コンテキストを作成し、タスク終了時にはその両方を破棄する場合がある。
DeepSeekのCordis基盤は、このように変化する環境のために設計されている。プラグインはサービスを提供し、他のサービスを利用し、周囲のコンテキストが変わるのに応じて反応できる。フレームワーク自体は活発に開発中であり、APIは安定していない。
DeepSeek Harnessはこのアプローチをエージェントスタック全体に適用している。モデルアダプターはプラグインになる。ツールコレクション、ファイルシステム、サンドボックス、セッションマネージャー、ユーザーインターフェース、オーケストレーションループも同様だ。
この構造は、開発者に複数の形の制御を与える。インターフェースを作り直さずにモデルを置き換えられる。エージェントループを書き直さずにサンドボックスを変更できる。ランタイムの残りを維持したまま、企業固有のツールを導入できる。
同じ設計は異なる運用モードも支援できる。Webクライアントにはブラウザ向けコンポーネントとホストプロセスが必要だ。ヘッドレスデプロイメントには、同じ視覚層なしで自動化用の接点が必要になる。スコープ付きプラグインにより、両方の構成は同一のアプリケーションになることなくサービスを共有できる。
これが「すべてがプラグイン」というメッセージの仕組みである。単なるマーケットプレイスのスローガンではない。リポジトリは、ホストパッケージ、クライアントパッケージ、アプリケーション、例、ドキュメント、ベンダー提供の依存関係を含む大規模なTypeScriptワークスペースとして構成されている。
DeepSeekのアーキテクチャは、特権サービスが動作するホストと、インターフェースコンポーネントが動作するクライアントも区別する。この境界は重要だ。エージェントは、ブラウザコンポーネントにシステム機能への無制限なアクセスを与えるべきではないからだ。
プロジェクトは両者の間のリモートインターフェースを生成する。ホストサービスは呼び出し可能なメソッドを宣言でき、クライアントコンポーネントは生成された契約を利用する。この手法は、インターフェースを基盤となるサービス定義と同期させることを目指している。
開発者にとっての魅力は、完全なフォークを維持せずにカスタマイズできることだ。企業は、読み取り専用のリポジトリツール、制限付きの文書ストア、あるいは特化したレビュー用ループを作成できる。そうした振る舞いをプラグインとしてパッケージ化することも可能だ。
実際のユースケースとしては、見慣れないリポジトリをレビューするエンジニアリングチームが考えられる。エージェントはコード検索プラグイン、読み取り専用のファイルシステム、分析用に選定されたモデルを読み込める。デプロイ用の認証情報や書き込みコマンドへのアクセスは必要ない。
別のチームは社内リサーチエージェントを構築するかもしれない。承認済みのWebソース、ローカル文書、セッションストレージ、最終統合用の別モデルを組み合わせられる。ユーザーインターフェースは、これらの基盤サービスを置き換えずに変更できる。
このモジュール性は実験も容易にする。チームは同じツールとセッションロジックのもとで二つのモデルを比較できる。モデルを変えずに異なるオーケストレーションループを試せる。この分離により、実際にタスクを改善したコンポーネントがどれなのかを明らかにできる。
モデル非依存の立場は、DeepSeekに戦略的な利点とリスクの両方をもたらす。他のモデルを支援すれば、プロジェクトの対象者を広げられる。一方で、開発者がDeepSeek自身のランタイム内で別のモデルの方が優れていると見いだす助けにもなり得る。
DeepSeekは、そのトレードオフを受け入れる意向のようだ。同社が競っているのはエージェントアーキテクチャにおける立ち位置であり、すべてのコンポーネントを独占的に支配することではない。
オープンアーキテクチャが統合型コーディングエージェントに圧力をかける
DeepSeek Harnessは、モデル、インターフェース、ツール、オーケストレーションループが不可分な単一製品として提供されなければならないという考えに異議を唱える。
Claude CodeとOpenAI Codexは、プロジェクトを調査し、コマンドを実行し、ファイルを編集し、結果を報告できるエージェントを開発者が期待するようにしてきた。統合された設計はセットアップを簡素化し、各ベンダーに完全な体験へのより強い統制を与える。
この統合には実際の利点がある。ベンダーは自社モデル向けにツールの説明を調整し、コンテキスト処理を最適化し、製品アップデートを連携させられる。問題が発生した際、ユーザーにとってもサポートの責任範囲が明確になる。
DeepSeekのアプローチは別の優先順位から始まる。開発者に代わってすべてを決めるのではなく、各判断を置き換え可能なコンポーネントとして公開する。チームは、デプロイメントにどのモデル、ファイルシステム、サンドボックス、ループを組み込むかを選択できる。
この対比は、機能一覧の違いというより所有権の問題だ。統合型エージェントでは、ベンダーがランタイムを所有し、ユーザーは選択された部分を設定する。DeepSeek Harnessでは、開発者がランタイムを所有し、パッケージから組み立てられる。
この違いは、特殊なセキュリティ要件やインフラ要件を持つ組織にとって重要だ。企業によっては、特定のコンテナシステム内でコマンドを実行する必要があるかもしれない。ログを社内ネットワーク内に留める必要がある場合もある。データ分類ごとに異なるモデルプロバイダーを使いたいこともある。
プラグインアーキテクチャは、そうした制約により直接的に対応できる。一方で、カスタマイズを加えるたびに、レビュー、テスト、更新、サポートすべきコンポーネントも増える。
統合製品は、チームが単一の明確な経路を最適化するため、一般的なワークフローではより速く進化できる。オープンなハーネスは、外部の開発者が新しい統合を作るために許可を得る必要がないため、周辺領域でより速く進化できる。
したがって、競争の焦点は開発者の負担になる。カスタマイズによる省力化がフレームワークによる作業増を上回れば、DeepSeek Harnessは成功する。チームがプラグイン互換性の解消や不安定な契約の追跡に時間を費やすなら、苦戦するだろう。
DeepSeekの現行ドキュメントは、大きなエンジニアリング上の意欲を示している。リポジトリは継続的インテグレーションで複数世代のNode.jsをサポートし、ブラウザ向けビルドとホスト向けビルドを分離し、広範な自動ゲートを備える。こうした詳細は、DeepSeekがこのプロジェクトを再利用可能なプラットフォームとして機能させる意図を持つことを示している。
ユーザーガイドでも、Webインターフェースは製品全体ではなく、ひとつの入口として扱われている。これは、dshが単なるブランド付きチャットアプリケーションではなく、エージェントのためのインフラであるという見方を裏付ける。
ただし、ドキュメントとアーキテクチャだけでは、本番環境での信頼性は証明されない。独立した比較では、同一タスクの下でハーネスとモデルの完全な組み合わせを検証しなければならない。モデル単体のベンチマークスコアでは、ランタイムが失敗したツールから復旧できるか、あるいはファイルを適切に保護できるかには答えられない。
この比較では、誤った二者択一も避けるべきだ。開発者が使えるエージェントはひとつだけではない。チームは日常的なコーディングには統合製品を採用しつつ、専門的な社内ワークフロー向けにDeepSeek Harnessを試験できる。
今回のリリースは、モデルベンダーの公式エージェントはクローズドな一括製品でなければならないという前提を弱めるものだ。DeepSeekは、公式ランタイムでも検査可能かつ拡張可能であり得ることを示している。
この決定は、競合各社にオーケストレーション層のより多くを公開するよう圧力をかける可能性がある。また、独立プロジェクトが互換性のあるプラグイン規約を採用する契機にもなり得る。もっとも、初期プレビューだけでどちらの結果も保証されるわけではない。
最初の試金石は、外部開発者が表面的なラッパーではなく、意味のあるプラグインを構築するかどうかだ。次は、DeepSeekがフレームワークを変更しても、それらのプラグインが互換性を維持できるかどうかである。3つ目は、チームが継続的な業務でそれらをデプロイするかどうかだ。
互換性とセキュリティは依然として未検証の部分
このプレビューは開発者に制御を与える一方で、不安定なインターフェース、プラグインの信頼性、ツール権限に関する責任も移転する。
DeepSeekは、互換性を損なう変更が発生すると明言している。この警告は、初期段階のすべてのデプロイ判断に反映されるべきだ。チームは現在このソフトウェアを評価できるが、現在のプラグイン契約が次のリリースまで存続するとは想定すべきではない。
破壊的変更は、初期プレビューでは珍しくない。より大きなエコシステムが依存する前に、メンテナーが弱い抽象化を修正できるからだ。しかし頻繁な変更は、統合を繰り返し更新しなければならないプラグイン開発者を遠ざける可能性がある。
Cordisは、さらに別の不安定な層を導入する。同プロジェクトのリポジトリ自体が、APIは予告なく変更される可能性があるとしている。したがってDeepSeek Harnessは、公開契約がなお発展途上にあるメタフレームワークに依存している。
セキュリティ上の問題は、より重大だ。エージェントハーネスは、確率的なモデル出力を決定論的なシステム操作につなげられる。ランタイムがコマンド実行、ファイル変更、外部へのデータ送信を行える場合、モデルの誤った応答はより深刻な問題になる。
プラグインのモジュール性が自動的に安全な分離を生むわけではない。プラグインはエージェントの能力を拡張できるが、攻撃対象領域も広げ得る。チームは、すべてのコンポーネントについて権限、ネットワークアクセス、認証情報の取り扱い、データ保持を調査する必要がある。
プロンプトの指示は十分なセキュリティ境界ではない。読み取り専用を維持するよう求められたモデルにも、読み取り専用の挙動を強制するツールが必要だ。モデルが要求したとしても、ランタイムは許可されていない操作を防がなければならない。
ホストとクライアントの分離は有用なアーキテクチャ上の境界を提供するが、実装品質が重要になる。開発者には、特権サービスがリクエストを検証し、スコープを正しく制限している証拠が必要だ。プラグインがクラッシュした場合や利用不能になった場合の明確な挙動も必要となる。
サードパーティ製プラグインはサプライチェーン上の懸念を生む。パッケージがソースコード、ローカルファイル、API認証情報へのアクセスを得る可能性がある。悪意のあるアップデートは、ユーザーインターフェースに見える部分を変えずに、そのアクセスを悪用できる。
したがって組織は、プラグインのインストールを見た目を整える拡張機能の追加ではなく、依存関係の承認と同様に扱うべきだ。バージョンを固定し、ソースコードをレビューし、認証情報を制限し、制約された環境内でツールを実行すべきである。
可観測性も同様に重要だ。チームには、どのモデルがリクエストを生成し、どのプラグインが動作し、どの引数を受け取り、その後何が変更されたかを示す記録が必要となる。その追跡情報がなければ、デバッグやインシデントレビューは推測に頼ることになる。
DeepSeekの公開資料は、開発時のチェックとテスト基盤を説明している。ただし、サポート対象のすべての構成が敵対的入力に対して安全に振る舞うことを示す独立した証拠は、まだ提供していない。
プロジェクトにはベンチマーク文書が含まれるが、ベンチマーク結果は慎重に解釈する必要がある。エージェントのスコアは、モデル、プロンプト、ツール、環境、オーケストレーション方針、評価ルールを合わせて反映する。
この依存関係により、比較は難しくなる。別のシステムが同じモデルと環境を使用しない限り、DeepSeek Harnessの高スコアはハーネス自身の寄与を切り分けられない。別のハーネスによるモデルスコアにも、同じ問題がある。
開発者は、リポジトリの活動を採用実績とみなすことにも抵抗すべきだ。スター、フォーク、オンライン上の注目は関心を示す。しかし、継続利用、本番利用、運用コストの低下を示すものではない。
最も信頼できる初期の証拠は、再現可能なタスクから得られる。同じプラグインセットを異なるチームがインストールし、比較可能な挙動を得られるか。統合を作り直さずにアップグレードできるか。管理者はプロンプトに頼らず、エージェントのツールを制約できるか。
DeepSeekは、開発者がこれらの問いを調査するのに十分なコードを提供している。しかし、それらを決着させるには、まだ十分な実地での履歴を提供していない。
DeepSeek Harnessが重要かどうかを示す3つの兆候
次の段階は、プラグインの採用、インターフェースの安定性、完全なエージェントデプロイメントから得られる信頼できる証拠にかかっている。
最初の兆候は、有用なサードパーティ製プラグインのコミュニティだ。DeepSeekは、互換性のあるリポジトリにdsh-pluginトピックを付与するよう開発者に呼びかけ、メインコードベースの外部に発見の経路を作っている。
重要なのは、プラグインの数より品質だ。薄いアダプターは、このアーキテクチャが要求の厳しい業務を支えることを証明せずに、初期の勢いを生み出せる。安全なサンドボックス、エンタープライズ認証、可観測性、制限付きファイルシステムのためのプラグインは、より強い証拠となる。
健全なコミュニティには、DeepSeek以外のメンテナーも必要だ。独立開発者は互換性を文書化し、不具合に対応し、フレームワーク変更後に統合を更新しなければならない。そうでなければ、オープンライセンスであってもエコシステムはコアチームに依存したままとなる。
開発者が異なるユースケースにまたがる本格的なプラグインを構築すれば、オープンランタイムの論拠は強まる。活動の大半がDeepSeekのリポジトリ内に留まるなら、このプロジェクトは設定可能な公式クライアントに近いものに見える。
2つ目の兆候は、v0.1から安定した契約へ至る道筋だ。プレビュー段階での破壊的変更は許容されるが、開発者はどのインターフェースが信頼できるものになりつつあるかを確認する必要がある。
DeepSeekは、バージョン管理されたプラグインAPI、移行ガイド、非推奨化の猶予期間、互換性テストを通じて信頼を強められる。明確なセキュリティモデルは、安定したプログラミングインターフェースと同じくらい重要になる。
安定性は、すべての機能を固定することを意味しない。外部メンテナーが計画を立てられるほど、変更を予測可能にすることを意味する。プロジェクトの既存のテスト規律は基盤を提供するが、真の試金石は公開された互換性の約束になる。
アップグレードが日常的な作業になれば、DeepSeek Harnessは長期運用の製品を支えられる。すべてのリリースで大規模な書き換えを強いられるなら、開発者はこれを実験用途に限定するだろう。
3つ目の兆候は、完全なワークフローに対する独立評価だ。テストでは、モデル、タスク環境、ツール、許可された操作を統制しながら、ハーネスを比較すべきである。
有用な評価は、タスク完了だけにとどまらない。不正な操作、失敗したツールからの復旧、人間の介入、実行時間、提供された成果物の正確性を記録すべきだ。
セキュリティテストには別のトラックがふさわしい。研究者は、プロンプトインジェクション、悪意あるリポジトリ、侵害されたプラグイン、認証情報の露出、サンドボックスからの脱出の試みを調べるべきである。
本番環境のケーススタディも、別の形の証拠となる。反復業務にDeepSeek Harnessを使用するチームは、エージェントがどの程度の頻度で正しく完了するか、どの程度の監督が必要かを報告できる。こうした観察は、一回限りのデモでは見落とされる弱点を明らかにする。
独立した結果が、そのモジュール性が信頼性を維持することを示せば、DeepSeekは統合型エージェントに対する説得力のある答えを持つことになる。カスタマイズが一貫性のない挙動を生むなら、厳格に統制された製品が優位性を維持するだろう。
今回のリリースは、すでにひとつの事実を示している。DeepSeekはもはやモデルエンドポイントだけで競争しようとしていない。同社は、DeepSeekが管理する基盤の上で、開発者にエージェントを取り巻く運用層を構築してほしいと考えている。
開発者にとって、賢明な対応は焦点を絞った実験だ。範囲を限定したワークフローをひとつ選び、利用可能なツールを制限し、すべての操作を記録する。同じタスクとレビュー工程の下で、そのデプロイメントを既存のエージェントと比較する。
こうした試行を文書化するチームは、判断と発見をエンジニアリングナレッジベースに蓄積できる。その記録は、プラグイン、モデルバージョン、セキュリティポリシーが変化する際に不可欠になる。
DeepSeek Harnessは、エージェントのランタイムを明確な競争領域として位置づけている点で注目に値する。オープンなアーキテクチャにより、開発者には異例のほど大きな制御権が与えられる一方、プレビュー段階であるため、信頼性とガバナンスには未解決の課題が残る。
今後数か月の論点は明確だ。開発者は置き換え可能なプラグインを信頼できるシステムへと発展させられるのか、それとも統合コストによって再び統合型エージェントへ回帰するのか。DeepSeekは自らの主張を示した。あとは実際の導入事例がそれを検証する必要がある。
