「最小のAPIリクエスト1本」でも、DeepSeek APIの認証はBearer方式で、DNS、TLS、資格情報、上流応答を分けて記録できます。(api-docs.deepseek.com)
症状：Webページは開くのに、DeepSeek Harnessの処理が途中で止まる。
最速解決：モデルAPI、Git、依存関係、MCPを別シナリオで実行し、DNS・TLS・プロキシ・実行アカウントの証拠を残してください。
この検査は、クラウドのリモートMacを調達して納品条件へネットワーク要件を書きたい技術責任者向けです。
また、API障害とGit認証障害を分けたい運用担当者、企業プロキシ下で無人実行を確認したい開発者にも使えます。
まず「Webが開く」を合格条件から外します
ブラウザーでコード管理画面を開けても、バックグラウンドのGitが使えるとは限りません。対話シェルだけで設定した認証情報やプロキシ変数が、常駐プロセス、CI、再起動後のタスクへ渡らないこともあります。
見落としやすい制限は主に4つです。
- 経路の違い：HTTPS、SSH、MCPのHTTP接続では、許可ポート、証明書、認証方式が異なります。
- 実行主体の違い：あなたのターミナルでは成功しても、Harnessを起動するアカウントでは失敗します。
- キャッシュの錯覚：依存関係がローカルキャッシュに残っていると、外部レジストリへ接続できなくても初回確認を通過します。
- 障害位置の曖昧さ：上流サービス障害、アカウント権限、Mac側の出口制限を同じ「接続失敗」として扱うと、再現性のない修正になります。
公式APIではモデル一覧取得やチャット完了処理など、HTTP応答を確認できる入口が用意されています。画面上の回答だけでなく、リクエスト記録、HTTPステータス、エラー本文、実行時刻を保存してください。(api-docs.deepseek.com)
4つのシナリオを別々に判定します
| シナリオ | テスト対象 | 成功の証拠 | 拒収条件 |
|---|---|---|---|
| モデルAPI | DNS、TLS、認証、上流応答 | 最小リクエストのID、ステータス、応答時刻、失敗段階 | 画面表示だけ、実キーがログに残る、手動プロキシだけで成功 |
| Git | リポジトリ発見、取得、参照、制御された送信 | リモートURL、取得結果、参照確認、無害な変更の送信結果 | ブラウザーだけ成功、SSH鍵の所在不明、顧客リポジトリ内容を証拠に含める |
| Node.js依存関係 | Harness更新、プラグイン、プロジェクト依存 | キャッシュ削除後の再構築ログ、ロックファイル、終了コード | 個人端末から一時的に環境変数をコピーしないと動かない |
| MCP Server | 発見、ツール呼び出し、結果、取消 | 読み取り専用ツールの結果、区間別ログ、取消後の状態 | ローカル起動だけ成功、外部データ源未確認、権限エラーをネットワーク扱い |
ケース：APIは失敗するが、一般サイトは表示できる
最初に、顧客データを含まない固定文を送る最小リクエストを用意します。確認項目は次の順番です。
- 実行アカウントを確定します。
- APIホスト名のDNS解決結果を保存します。
- TLS接続と証明書検証の結果を保存します。
- APIキーはログへ出さず、認証成否だけ記録します。
- HTTPステータス、応答ID、モデル名、エラー分類を保存します。
401や403系なら、まず資格情報、アカウント、利用権限を確認します。名前解決不能、TLS検証失敗、接続タイムアウトなら、出口、DNS、証明書、プロキシを優先して調べます。上流の5xx系をMac側の拒収と断定せず、同じ時刻のサービス状態や別経路の結果と比較してください。
DeepSeek APIはツール呼び出しにも対応しますが、モデルAPIが通ったことだけで外部ツール経路まで合格とは言えません。(api-docs.deepseek.com)
ケース：コード管理画面は開くがGit操作が失敗する
ブラウザー操作とGit操作は、認証情報も通信経路も別に確認します。GitはSSHやHTTP、HTTPSなど複数の転送方式を扱うため、納品時に「Git対応」とだけ書くのは不十分です。(git-scm.com)
安全な検査用リポジトリで、次の順に実行します。
- リモートURLと使用プロトコルを確認します。
fetch相当でリポジトリを取得します。- 特定の参照やコミットを読み取ります。
- 顧客データを含まない変更を作ります。
- 事前承認したブランチへ、制御された送信を行います。
成功証拠には、リポジトリ名そのものやソース本文を含める必要はありません。実行時刻、使用アカウント、プロトコル、終了コード、参照名を匿名化して残します。秘密鍵、アクセストークン、資格情報ヘルパーの内容は証拠から除外してください。
第二歩：依存関係はキャッシュを消してから再構築します
Harnessの導入や更新、プラグインの取得、プロジェクトのパッケージ復元は、別々の外部接続として確認します。初回だけ成功し、2回目に失敗する環境は継続運用に向きません。
DeepSeekのAIツール連携資料でも、Mac上の開発ツール導入にNode.jsや環境変数が関係する構成が示されています。実際のHarnessの要件は対象バージョンとプロジェクト定義に合わせて固定してください。(api-docs.deepseek.com)
| 確認方法 | 分かること | 判定 |
|---|---|---|
| 既存キャッシュで起動 | ローカルに残った依存関係が使えるか | 予備確認のみ |
| キャッシュを削除して復元 | レジストリ、プロキシ、証明書、ロックファイルの経路 | 本検査 |
| 新しい実行アカウントで復元 | 権限と環境変数の継承 | 本番相当 |
| 再起動後に復元 | 常駐プロセスの設定永続性 | 受入条件 |
個人の端末から一時的にコピーしたHTTP_PROXYやHTTPS_PROXYで成功した場合は、必ず「不可納品」と記録します。正式な設定場所、適用アカウント、変更管理の担当者、再起動後の確認手順が必要です。
第三歩：MCP Serverは3区間に分解します
MCPでは、サーバーがモデルから呼び出せるツールを公開します。公式仕様でも、ツール一覧の取得とツール呼び出しは別のメッセージ処理として扱われます。(modelcontextprotocol.io)
受入検査では、読み取り専用で副作用のないMCP Serverを1つ選びます。
- HarnessからMCPプロセスまたはMCPエンドポイントへ接続します。
- 利用可能なツール一覧を取得します。
- 固定引数で読み取り専用ツールを呼び出します。
- 結果の形式、取得元、エラー状態を確認します。
- 実行中に取消し、または短時間の切断を行います。
失敗したら、次の3区間を個別に記録します。
- Harness → MCP：起動、標準入出力、HTTP接続、プロトコル応答。
- MCP → 上流：DNS、TLS、プロキシ、外部データ源への認証。
- 資格情報 → 認可：トークンの有効性、権限範囲、期限、対象リソース。
MCPのローカルプロセスが「起動済み」と表示されても、外部データ源への到達性は確認できません。取消は協調的に処理されるため、取消要求を送った時点だけでなく、処理が重複実行されていないかも確認します。(csharp.sdk.modelcontextprotocol.io)
注意：企業証明書の検査でTLS検証を無効化したり、証明書エラーを無視したりしないでください。必要な信頼設定は、管理対象のキーチェーンと変更記録で解決します。macOSは証明書の用途ごとに信頼ポリシーを評価します。(support.apple.com)
第四歩：DNS、プロキシ、証明書の継承を確認します
企業プロキシ環境では、対話式ターミナル、ログイン後のGUI、常駐サービスで環境が変わります。検査対象のプロセスを実際の運用起動方法で立ち上げ、次を記録してください。
- 実行アカウントとグループ。
- 親プロセスと起動方式。
- プロキシ設定の取得元。
- 内部DNSと外部DNSの使い分け。
- プロキシを通す接続と、通さないローカルアドレス。
- 証明書を信頼するキーチェーン。
- 接続失敗時の終了コードと再試行方針。
内部名を外部DNSへ漏らさないルール、ローカルMCPへの接続を誤って企業プロキシへ送らないルールも明文化します。証明書の中身や社内プロキシアドレスを納品資料へそのまま書く必要はありません。検査結果には、設定の存在、適用範囲、検証結果だけを残します。
第五歩：短時間の切断と再起動で最終判定します
通信を短時間遮断し、Harnessの処理が停止、再試行、待機、失敗のどれになるか確認します。特にGit送信やMCPの書き込み系ツールでは、切断後に同じ副作用が二重に発生しないことが重要です。
交付パッケージには、少なくとも次を含めます。
- 検査日時。
- 対象MacとHarnessのバージョン。
- 実行アカウント。
- シナリオ別の結果。
- DNS、TLS、プロキシ、認証の失敗段階。
- 再試行、停止、回退の動作。
- 再起動後の再現結果。
- 秘密情報を除外したログの保管場所。
合格条件は3つです。 核心4経路がすべて通ること、機密情報がログへ入らないこと、再起動後も同じ手順で再現できることです。どれか1つでも欠ける場合は、画面が正常でも受入を保留します。
遠隔Macの調達先を比較する場合は、先にMACCOMEのMacレンタル案内で利用形態を確認し、候補ノードを決めた後にMacの注文ページへ進むと、機器選定とネットワーク検査を分けて整理できます。
FAQ：現場で詰まりやすい4つの分岐
リモートMacではWebページが開くのにDeepSeek APIだけ失敗する場合
ブラウザーとHarnessの実行アカウントを分けて比較します。最小APIリクエストでDNS、TLS、認証、HTTP応答を順に記録し、401系は権限、名前解決や証明書の失敗は出口設定として扱います。画面上の回答だけを成功証拠にしないことが重要です。
DeepSeek Harnessの外部接続先を申請する場合
固定のドメイン全集を推測せず、実際のProvider、コードリポジトリ、依存関係源、MCP上流サービスを用途別に洗い出します。接続方向、認証方式、プロキシ経由の有無、代替経路、変更時の申請担当まで記録すると、構成変更後も再検査できます。
企業プロキシ環境でAI Agentを検査する場合
対話シェルでの成功を本番合格としません。常駐タスクと同じアカウント、起動方式、証明書ストアで実行し、再起動後にもプロキシとDNSの設定が継承されるか確認します。個人端末からの一時的な環境変数に依存する構成は、運用へ引き渡さないでください。
MCP Serverの失敗をネットワークと設定に分ける場合
HarnessからMCP、MCPから外部データ源、資格情報と認可の3区間へ分けます。ツール一覧は取れるが呼び出しだけ失敗するなら引数や権限、呼び出し開始前に失敗するなら接続やプロトコルを優先します。ローカルプロセスの起動成功だけでは合格になりません。
現在の構成が手元のMacや一時的なクラウド環境に依存していると、出口設定の担当者が不明、再起動後にプロキシが消える、キャッシュが残っていて障害を見逃す、といった欠点が出やすくなります。長期の固定負荷や物理インターフェースが必要なら自社保有機の方が適する場合もありますが、短期の検証、移行前の受入、複数地域からの再現確認なら、MACCOMEのレンタルMacで先に空のネットワーク証拠マトリクスを埋める方が判断しやすいです。
正式なリポジトリや本番資格情報を移す前に、4種類の最小リンクだけを実行してください。未通過の項目が残る場合は、DeepSeek Harnessの継続実行環境に関するガイドを確認し、出口設定、実行アカウント、再起動後の復旧手順を先に固めます。