2026 DeepSeek Harnessで並列ツール呼び出しはいくつ開く？

Node.jsの公式ドキュメントは、CPUコア数を表す os.cpus().length ではなく、実行環境が通常利用すべき並列度の推定値として os.availableParallelism() を使うよう案内しています。つまり、DeepSeek Harnessの並列ツール呼び出しはマシンのコア数から決めず、串行を基準に、隔離・資源・取消・ログの検証を通過したツールだけを限定的に並列化するのが安全です。(Node.js公式ドキュメント)

誰が読むべきか

Agent開発者は、複数のツールを同時に動かして処理時間を短縮しながら、結果の競合を避けたい場合に向いています。プラットフォームエンジニアは共有実行環境の境界を決める材料として、技術調達担当者は1台のMacに詰め込むか、独立したMac環境へ分けるかを判断する材料として利用してください。

まず決めるのは並列数ではなく、ツールの副作用です

maxParallelToolCalls の設定値を先に決めると、読み取り処理と書き込み処理を同じ安全度で扱うことになります。DeepSeek Harnessはプラグインを差し替えられる構成で、公式リポジトリも開発者プレビュー中であり、互換性を壊す変更がありうると明記しています。設定名が存在することと、すべてのツールが安全に同時実行できることは別問題です。(DeepSeek Harness公式リポジトリ)

各ツールについて、次の3点を台帳にしてください。

• 読み取り対象：リポジトリ、設定ファイル、ビルド成果物、外部APIの応答など。
• 書き込み対象：ソースコード、生成ファイル、キャッシュ、ロックファイル、ブランチ、データベースなど。
• 外部へ出す対象：ネットワーク要求、メッセージ送信、クラウド資源の作成、課金対象の操作など。

この台帳で、ツールを次の4種類に分けます。

• 読み取り専用：コード検索、ファイル一覧、設定確認。最初に並列化を試す候補です。
• 独立した書き込み：専用ディレクトリや専用ブランチだけを変更する処理。隔離を確認できた場合に限定並列へ進めます。
• 共有書き込み：同じソース、同じビルドディレクトリ、同じキャッシュやロックを変更する処理。原則として串行です。
• 外部副作用あり：デプロイ、通知、課金、データ更新など。成功しても重複実行が問題になるため、明示的な冪等性が確認できるまで串行にします。

ツール名が違っていても、同じディレクトリへ書き込むなら競合します。読み取りツール同士でも、一方がキャッシュを更新する実装なら完全な読み取り専用とは言えません。

DeepSeek Harnessの並列ツール呼び出しは、ワークスペースを分けて検証します

複数のビルドやテストを同じ作業ディレクトリで走らせる場合、コマンドが異なるだけでは安全性を証明できません。確認すべき対象は、ソースファイルだけでなく、node_modules、生成済みアセット、テスト用データベース、.lock ファイル、テンポラリーディレクトリ、Gitのインデックスです。

並列ビルドでは作業場所を分けるべきか

編集や生成を伴うなら、原則として分けてください。Git公式ドキュメントの git worktree は、同じリポジトリから複数の作業ツリーを作り、各ツリーで別のブランチやコミットを扱える仕組みです。ただし、リポジトリの共通管理領域や参照は共有されるため、作業ツリーを分けただけで外部キャッシュや共有サービスまで分離されるわけではありません。(Git公式ドキュメント)

検証では、実行前後に次を保存します。

• git status --short とブランチ名
• 変更されたファイルの一覧とハッシュ
• ビルドディレクトリ、キャッシュ、ロックの所有タスク
• 成果物の出力先と生成時刻
• 同じファイルを複数タスクが触っていないか

成果物の帰属が分からない場合、処理が成功していても合格にしないでください。速度向上より、再現できる失敗原因のほうが運用コストを大きく左右します。

注意：モデルが1回の応答で複数のtool callを生成しても、実行基盤がすべてを安全に並列化するとは限りません。モデル側の同時要求、実行キュー、子プロセス、ファイルシステムの動作を分けて観察してください。

資源ピークはMacの同時実行上限を決める材料です

Mac同時実行の上限は、CPUの使用率だけでは判断できません。並列ビルド、テストランナー、言語サーバー、パッケージ管理、シェルの子プロセスが重なると、メモリ、ファイルディスクリプター、テンポラリーストレージの空き容量も同時に圧迫されます。

測定は、同じリポジトリ、同じコミット、同じ依存関係、同じテストコマンドで行います。まず串行の基準を取り、その後に限定並列の実行を繰り返し、次の値を1つの記録にまとめてください。

• タスク開始から終了までの経過時間
• CPU使用率の推移と継続的な飽和
• メモリプレッシャー、スワップ、プロセスの常駐量
• ファイルディスクリプター数
• テンポラリーストレージの使用量
• 子プロセス数、終了コード、強制終了の有無

Node.jsには、実行環境が利用すべき並列度を推定する os.availableParallelism() がありますが、これはDeepSeek Harnessの安全なツール呼び出し数を保証する値ではありません。CPUの余力があっても、共有キャッシュ、メモリプレッシャー、ファイルI/Oがボトルネックなら並列数を増やす理由にはなりません。(Node.js公式ドキュメント)

継続的なメモリプレッシャー、頻繁なスワップ、処理中のプロセス終了、テンポラリー領域の枯渇が出たら、設定値を下げるか、ワークスペースまたはMac環境を分けます。性能の数字を別のMacや別バージョンへそのまま移すことはできません。

取消とタイムアウトは、失敗時の被害範囲で判定します

並列実行を広げる前に、1つのツールが失敗したとき、ユーザーが取消したとき、タイムアウトしたときの3パターンを再現してください。フォアグラウンドのツール呼び出しがエラーを返しただけでは不十分で、裏側の子プロセスと作業ディレクトリがどうなったかまで確認します。

実施手順は次の通りです。

第一歩：串行基準を保存する

同一コミットからコード検索、テスト、ビルドを串行で実行し、開始時刻、終了時刻、変更ファイル、成果物、終了コードを保存します。ここで作業前の状態を保存しないと、並列実行後の差分を比較できません。

第二歩：副作用台帳を作る

各ツールが読む対象、書く対象、外部へ送る対象を記録し、読み取り専用と見なしていた処理がキャッシュや一時ファイルを更新していないか確認します。

第三歩：最小単位だけを並列化する

最初は互いに異なるファイルを読む処理、または独立した作業ツリーで完結する処理に限定します。コード検索とテストを同時に動かす場合でも、テストがビルド成果物を生成するなら、単純な読み取り処理とは分けて判定します。

第四歩：取消テストを行う

実行中にユーザー取消を送り、フォアグラウンドの呼び出し、バックグラウンドの子プロセス、生成途中のファイルをそれぞれ確認します。Node.jsの子プロセスは AbortController のシグナルで終了要求を受けられますが、シェルを介した孫プロセスまで同じように終了するとは限らないため、プロセスツリーを確認してください。(Node.js child_process公式ドキュメント)

第五歩：再実行と復旧を確認する

取消後に同じタスクを再実行し、半端な成果物、残ったロック、壊れたキャッシュ、変更されたブランチが結果へ混入しないか調べます。復旧できないなら、速度が改善しても限定並列を採用しません。

第六歩：ログと結果の対応を確認する

各呼び出しにタスク識別子を付け、開始、実行中、成功、失敗、取消、終了の状態を追跡します。結果の到着順と、モデルへ返す順序が異なる場合でも、元の呼び出しを特定できなければなりません。

結果順序とログが追えない構成は不合格です

並列処理では、後から開始したツールが先に終わることがあります。そのため、ログを単純な行番号だけで管理すると、ビルドのエラーを別タスクの結果として誤認しやすくなります。

最低限、次の対応関係を保存してください。

• Agentのターン識別子
• tool callの識別子
• ツール名と引数の要約
• 開始時刻と終了時刻
• 成功、失敗、取消、タイムアウトの状態
• 子プロセスの終了コード
• 変更ファイルと成果物の場所

DeepSeek Harnessの公式リポジトリでは、エージェントループ、ツール実行、セッション管理などが別の構成要素として整理されています。したがって、モデルの応答ログだけでなく、実行環境側のイベントと成果物を結び付けて保存する設計が必要です。(DeepSeek Harnessの構成解説)

判定ツール：5項目を確認して串行・限定並列・環境分離を選びます

以下は、maxParallelToolCalls を設定する前に使える決定条件リストです。チェックが付かない項目を「たぶん問題ない」と扱わず、失格した時点で下の選択肢へ戻してください。

限定並列を選べる条件

• [ ] 各ツールの読み取り、書き込み、外部送信の対象を一覧化できている。
• [ ] 並列するツールが共有ソース、共有ビルド先、共有ロックを変更しない。
• [ ] 作業ツリー、キャッシュ、一時領域、テスト用データをタスク単位で分離できている。
• [ ] CPUだけでなく、メモリプレッシャー、スワップ、ファイルディスクリプター、テンポラリー領域を記録できている。
• [ ] 取消またはタイムアウト後に子プロセスとロックが残らない。
• [ ] すべての結果をtool call識別子、終了状態、成果物と対応付けられる。

6項目すべてにチェックが付く場合は、読み取り専用または独立書き込みのツールから限定並列を試します。最初から最大値へ変更せず、同一基準タスクで串行結果と比較し、失敗時には直前の値へ戻せるようにしてください。

串行へ戻す条件

次のいずれかに該当するなら、DeepSeek Harnessの並列ツール呼び出しを串行へ戻します。

• 同じファイル、キャッシュ、ロック、ビルド出力を複数タスクが使う。
• 取消後にバックグラウンドの子プロセスや半端な成果物が残る。
• メモリプレッシャー、頻繁なスワップ、強制終了が発生する。
• 結果の発生元、エラー、成果物の所有タスクを特定できない。
• 外部操作に重複実行を防ぐ仕組みがない。

実行環境を分ける条件

共有ワークスペースだけでは隔離できない場合、または各タスクに独立した責任と継続的な資源が必要な場合は、作業ツリーではなくMac環境そのものを分けます。特に長時間のビルド、常駐する言語サーバー、大きな依存関係キャッシュ、外部サービスへの書き込みが同時に発生する構成では、1台の環境に並列数を追加するより、独立環境へ分割したほうが復旧範囲を限定できます。

maxParallelToolCallsの設定は条件分岐で運用します

固定の推奨値を配布するより、次の条件分岐を運用ルールにしたほうが安全です。

• 副作用が読み取りだけで、共有ファイル、共有キャッシュ、外部更新がないなら、限定並列を試します。
• 独立した作業ツリー、専用ビルド先、専用一時領域があり、取消後に残留プロセスがないなら、限定並列を継続します。
• 同じファイル、ブランチ、ロック、ビルド先を共有するなら、串行へ戻します。
• 資源ピークが継続し、スワップや強制終了が出るなら、設定値を下げます。
• タスクの責任範囲、成果物、ログを独立させる必要があるなら、ワークスペースまたはMac環境を分けます。
• 結果の順序やエラーの発生元を特定できないなら、速度に関係なく串行を維持します。

この判断なら、「maxParallelToolCallsをいくつにするか」という問いを、環境ごとの検証可能な判断へ変えられます。並列ツール実行後に拡張するか、串行へ戻すか迷った場合は、処理時間ではなく、隔離、取消、資源、追跡のどこが失格したかを確認してください。

現在の共有環境とMac環境の使い分け

1台の共有環境で複数タスクを走らせる方式は、導入が簡単な反面、同じワークスペースやキャッシュを使いやすく、取消後の残留プロセスが別タスクへ影響し、資源ピークの責任範囲も曖昧になります。長期的にコード検索、テスト、ビルドを同時運用するなら、単に maxParallelToolCalls を上げるより、実行環境を分けたほうが原因追跡と復旧を設計しやすくなります。

まずは手元の基準タスクで串行と限定並列を比較し、ワークスペース隔離や資源上限がボトルネックになった段階で、DeepSeek Harness向けのMac環境や複数ノードの構成を検討してください。特定地域の遅延や接続経路も確認したい場合は、シリコンバレーのMacノードのように用途を分けて比較できます。

VPSMACのMacレンタルは、長期にわたり同じ重いビルドを固定運用する用途や、物理インターフェースを直接必要とする用途の代替ではありません。一方、並列ツール実行の検証、独立ワークスペースの試験、短期間の容量確認では、共有環境の競合を避けながら条件を揃えやすい選択肢になります。