2026年DeepSeek Harness推論強度の選び方

コード検索は速く終わるのに、複数ファイルの修正や障害対応だけ手戻りが増えているなら、推論強度の使い分けが必要です。
2026年8月時点の最短解は、結果をすぐ検証できる定型作業をlow、根本原因の特定や高リスク変更をhighに分け、今週は同じ基準タスクで両方を比較することです。

この判断は、low reasoning effortが必ず高速・低コストである、high reasoning effortが必ず高品質である、という意味ではありません。タスクの境界が明確か、失敗を検出できるか、修正に失敗した場合の手戻りが大きいかで決めます。

この解説が必要なのは、単純作業で過剰な推論を避けたい開発者、複数のAgentにリポジトリ作業を割り振るチーム、そして遠隔Mac上で長時間の自動処理を運用する担当者です。
チャットで短い回答だけを得たい場合や、物理デバイスへの接続が主目的の場合は、別の構成が適しています。

※ 最終更新日：2026年8月18日。DeepSeekの最新の思考モード文書、モデル公開情報、Harnessの設定挙動を確認して整理しています。推論強度の実際の受け付け方は、利用するモデルアダプターと接続先で再確認してください。

DeepSeek Harness v0.1.0-rc.7のリリース情報では、low推論強度が追加され、highは既定値として扱われます。ただし、DeepSeekの公式API文書では、思考モードの有効化、reasoning_effort、ツール呼び出し後のreasoning_contentの引き継ぎが別々の設定として説明されています。画面上でlowやhighを切り替えても、モデル、API形式、Harness側の変換処理が一致しなければ、想定した動作にならない場合があります。

DeepSeekの公式文書では、思考モードの既定値や、通常リクエストでのhigh、複雑なAgent処理での自動的な最大強度、互換性のための値の変換が説明されています。利用前に、公式の思考モード設定、公式のツール呼び出しガイド、公式の変更履歴を確認してください。

DeepSeek V3.1以降の公式発表でも、1つのモデルで思考モードと非思考モードを切り替える構成、ツール利用やAgent処理の改善が説明されています。ただし、公式評価結果をそのままDeepSeek Harnessのlowとhighの差に置き換えることはできません。モデル、プロンプト、ツール権限、リポジトリ、実行環境が異なるためです。DeepSeek V3.1の公式リリースは、モデルの機能確認用の資料として使います。

DeepSeek Harnessのlowとhighの違いは、単に回答の速さを比べる機能ですか。
いいえ。実務では、モデルが仮説を増やして検証する余地と、ツールを使った反復をどこまで許容するかを分ける設定として扱うべきです。検索結果の要約なら出力を人間がすぐ確認できますが、ログの矛盾を解く作業では、初期仮説だけで修正すると原因を取り違えます。

ファイル名、関数名、設定値、依存関係など、入力範囲が絞られているコード検索ではlowを初期値にできます。特定のAPI呼び出し箇所を列挙する、設定ファイルの差分を要約する、変更された関数の一覧を作る、といった作業です。

ここで重要なのは、lowを「必ず安い方法」と決めつけないことです。検索結果の漏れを検出するコマンド、要約対象のファイル一覧、出力形式の検査が用意されているからこそ、低強度を選べます。検証手段がないまま、巨大なリポジトリ全体をlowで要約するのは別のリスクを生みます。

単一ファイル内の機械的な置換、型名の統一、明示されたテスト修正なら、lowでパッチを作り、差分とテスト結果を確認する流れが現実的です。一方、認証、キャッシュ、状態管理、データ形式などが複数モジュールにまたがる場合は、最初からhighを選び、変更前に依存関係を列挙させます。

簡単なコーディング作業は低強度でよいのでしょうか。
変更箇所が限定され、期待する差分を機械的に確認でき、失敗時にすぐ戻せるならlowで始めます。次のいずれかに該当する場合はhighへ切り替えます。

• 変更対象が複数ディレクトリにまたがる
• 公開APIやデータ形式が変わる
• テストが不足し、差分だけでは正しさを判断できない
• 失敗時に本番データや権限へ影響する
• 1回の修正で原因と結果を分けて確認できない

切り替え後は、差分ファイル、実行したテスト、ツール呼び出しの順序を記録します。結果だけを保存すると、lowで失敗したのか、ツールの選択を誤ったのか、入力条件が不足していたのかを区別できません。

複雑な障害では、ログ同士が矛盾する、同じ操作でも再現したりしなかったりする、複数サービスの境界で状態が変わる、といった条件が重なります。この場合、high reasoning effortを使う価値は、回答文が長くなることではなく、複数の仮説、反証条件、追加で必要な観測を整理できる点にあります。

ただし、highに切り替えれば原因が確定するわけではありません。ログの時刻、デプロイ履歴、設定差分、再現条件を別々に収集し、Agentには「次に何を確認すれば仮説が否定されるか」まで出力させます。正確率や所要時間が何％向上する、といった数字は、同じモデル、同じリポジトリ、同じツール環境で測定しない限り判断材料にしません。

推論強度を切り替えるとツール呼び出しも変わりますか。
変わる可能性があります。強度そのものがツール仕様を変更するわけではありませんが、必要な調査手順、ファイル参照の順番、テスト実行の回数は変わり得ます。DeepSeek公式文書でも、ツール呼び出しを含む会話では、前の応答に含まれるreasoning_contentを後続リクエストへ引き継ぐ必要があると説明されています。

Harnessのログでは、強度だけでなく、ツール名、引数、失敗、再試行、最終的な差分を一緒に比較します。ツール呼び出しのスキーマや強制的な関数形式を使う場合は、公式のFunction Calling仕様も確認し、モデルの推論結果とツール側の入力検証を分離してください。

数百行の整形変更より、数行の権限設定変更のほうが危険なことがあります。レビューでは、変更量ではなく、誤りが発生した場合の回復難度を基準にします。

• 低リスク：命名統一、重複検出、フォーマット、コメント整理。lowで確認し、静的検査を通します。
• 中リスク：内部ロジック変更、依存パッケージ更新、API呼び出し変更。highまたはlow実行後の人手レビューを必須にします。
• 高リスク：認証、権限、秘密情報、データ移行、公開設定、リリース手順。highを使い、テスト、差分確認、承認者の再確認を組み合わせます。

この分流では、AIの判定を最終承認にしません。高リスク変更は、Agentが「問題なし」と回答しても、保護されたブランチや人間の承認を通過させます。

無人で複数リポジトリを処理する場合、すべてをhighで動かすより、再実行しやすい作業をlowで開始し、検証に失敗したジョブだけhighへ送る設計が管理しやすくなります。対象は、依存関係の一覧化、既知パターンの検索、テスト結果の分類、変更候補の作成です。

切り替え条件は事前に固定します。必須ファイルが見つからない、テストが未実行、JSON形式が壊れている、差分が指定範囲を超えた、同じエラーを繰り返した場合は、lowの処理を成功扱いにせず、highまたは人手確認へ回します。

リトライ、強度変更、ジョブ中止はすべて記録します。実行履歴を残さないと、同じ失敗を何度も再試行して、モデル利用量だけでなくMacのCPU、メモリ、ストレージも消費します。長時間ジョブの受け入れ条件は、DeepSeek Harnessのバックグラウンド処理の設計と合わせて整理すると運用しやすくなります。

チームでは、担当者ごとの感覚で切り替えるのではなく、次の条件分岐をリポジトリ単位の設定と運用手順に落とします。

• 入力範囲が明確で、結果をコマンドや差分で確認できるなら、lowを選びます。
• 変更が複数ファイルに広がり、動作の因果関係を説明する必要があるなら、highを選びます。
• 認証、権限、移行、公開設定に触れるなら、highと人手承認を組み合わせます。
• lowの結果が不完全、テスト失敗、形式不正、差分過多のいずれかなら、highへ切り替えます。
• highでも再現条件や証拠が不足するなら、強度を上げ続けず、人手による調査へ戻します。

DeepSeekモデルの接続先によっては、lowやmediumの扱いが正規化される場合があります。設定値を保存するだけでなく、実際に送信されたリクエストと応答メタデータを確認してください。公式APIのパラメーター説明は、推論強度とツール呼び出しの扱いで確認できます。

比較では、lowとhighを別々の仕事で試してはいけません。同じリポジトリ、同じ指示、同じモデル、同じツール権限で、単純作業、複雑作業、高リスク作業を少なくとも1つずつ用意します。測定項目は、完成した差分、テスト結果、ツール経路、人手による手戻り、実行中のリソース占用、失敗から復旧するまでの記録です。

料金や所要時間を比較する場合は、接続先の料金表と実行ログを必ず併記します。公開情報だけから、lowが必ず安い、highが必ず遅いと推定してはいけません。DeepSeekのモデル仕様や提供条件は更新されるため、DeepSeek公式のモデル情報を基準に、チームの環境で再測定します。

現在のローカル実行や一般的なクラウド環境は、長時間Agentを動かすと開発用Macを占有し、同時実行数、権限分離、ログ保存、再現用の環境固定で不利になりやすいです。特に、単純作業と高リスク作業を同じ強度・同じ権限で走らせる運用は、推論費用だけでなく、失敗時の復旧費用も増やします。

まず隔離したMac環境でlowとhighの同一タスク比較を行い、DeepSeek HarnessのToken運用と、長時間処理に必要なMac容量の計画を分けて見積もるのが安全です。継続的な高負荷処理や物理インターフェースが必要な場合は自前機を選ぶ余地がありますが、期間限定の評価、複数Agentの試験、既存環境を止めずに行う検証なら、JEXCLOUDのMacレンタルで実行環境を分離するほうが、切り替え記録と失敗時の再現を管理しやすくなります。