2026 DeepSeek Harness OpenTelemetry どう有効化すればセッションを漏らさないか？

DeepSeek Harness OpenTelemetry 設定は、まず DISABLED のまま開始し、フィードバック収集が必要な場合だけ FEEDBACK_ONLY をテストしてください。FULL へ進むのは、送信対象の分類、OTLP端点の認証、TLS、保存期間、削除責任、停止時の未送信データ処理まで確認した後です。

今週の推奨アクションは、月曜日にデータ所有者と禁止項目を確定し、水曜日に隔離したテスト端点へ最小セッションを送信し、金曜日に断線・正常終了・遠隔Macの引き渡しを検収することです。どれか1つでも確認できなければ、設定は DISABLED に戻してください。

この記事は、遠隔Mac上のAgent障害を集中監視したいプラットフォームエンジニア、セッション内容を実行環境の外へ出してよいか判断するセキュリティ・コンプライアンス担当者、観測可能なDeepSeek Harness環境をチームへ引き渡す運用責任者向けです。

SECTION 01 開始前に、会話データを「ログ」と分けて分類する

OpenTelemetryは転送規格とSDKの仕組みであり、送信内容を自動的に安全なものへ変換する機能ではありません。Agentの会話では、通常のプロセスログに見えないユーザー入力、ツールの実行結果、ローカルパス、リポジトリ名、エラーメッセージ、フィードバック本文まで同じ記録に含まれる可能性があります。

最初に、次の3列を持つ台帳を作成してください。

所有者が決まらない会話、利用目的が曖昧なフィードバック、削除期限を説明できないデータは、送信対象に含めないでください。OpenTelemetryのログ設定で OTLPログ を有効にしても、機密性の判断が済むわけではありません。

DeepSeek Harnessは会話の遠隔測定を初期状態で送信しますか？

公式設定で確認されている共有モードは DISABLED、FEEDBACK_ONLY、FULL です。ただし、実際の既定値、各バージョンでの収集フィールド、プラグインが生成する属性は、利用中のバージョンの設定とソースで確認してください。未確認の環境では、送信されないと決めつけず DISABLED を維持するのが安全です。

SECTION 02 第一段階：共有モードを先に固定する

この3モードは、ログの詳細度を変えるスイッチではなく、どの目的のデータを共有するかというポリシーです。したがって、OTLP端点を先に作ってからモードを決めると、試験中の会話が意図せず外部へ出る危険があります。

• DISABLED：会話遠隔測定を使わない。データ分類が終わっていない環境、顧客情報を扱う環境、引き渡し直前の環境では第一候補です。
• FEEDBACK_ONLY：障害や品質改善のために許可されたフィードバックだけを扱う前提です。会話本文やツール結果が含まれないとは限らないため、実際の受信記録を確認する必要があります。
• FULL：対象範囲が最も広くなり得る共有方針です。観測項目を増やす前に、入力、出力、ツール結果、ファイル情報をそれぞれ許可・禁止に分けてください。

設定を変更できる人物も台帳へ記録します。開発者全員が環境変数を変更できる状態なら、承認済みの共有モードが運用中に上書きされるため、CI設定、起動スクリプト、管理者権限を分けてください。

SECTION 03 第二段階：隔離したOTLP端点へ最小セッションを送る

まず本番収集基盤ではなく、専用のテスト端点を用意します。OTLP/HTTPでは端点にスキーム、ホスト、ポート、シグナル別パスを設定でき、ログ専用端点には OTEL_EXPORTER_OTLP_LOGS_ENDPOINT を使えます。標準的なOTLP/HTTPの既定ポートは4318、OTLP/gRPCは4317ですが、DeepSeek Harnessの実装が同じ既定値を採用するとは限らないため、設定ファイルと実際の接続先を照合してください。(opentelemetry.io)

設定例は、実在しない端点と認証情報だけを使います。

DEEPSEEK_HARNESS_TELEMETRY_MODE=FEEDBACK_ONLY
OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=https://telemetry.example.invalid/v1/logs
OTEL_EXPORTER_OTLP_LOGS_HEADERS=authorization=REDACTED
OTEL_EXPORTER_OTLP_LOGS_PROTOCOL=http/protobuf
OTEL_EXPORTER_OTLP_LOGS_TIMEOUT=10000

実際の認証値をシェル履歴、チャット、構成管理リポジトリへ貼り付けないでください。OpenTelemetryではログ専用ヘッダー、TLS証明書、クライアント証明書、タイムアウトを個別に設定できます。端点は原則として https を使い、証明書検証を無効化する設定や平文HTTPへの切り替えを常用しないでください。(opentelemetry.io)

最小セッションは、秘密情報を含まない固定文字列、ツールを使わない短い応答、既知のテスト用識別子だけで作ります。送信側で記録したイベント数と、受信側で確認できる属性・本文・タイムスタンプが一致するかを照合してください。

注意：OTLP端点へ届いたことは、内容が適切だったことを意味しません。受信側の保存期間、検索画面の権限、バックアップ、再送キューまで含めてデータの行き先を確認してください。

SECTION 04 表に出る項目と、送信失敗時の境界を検証する

OpenTelemetryの公式仕様では、OTLPエクスポーターに端点、TLS、ヘッダー、圧縮、プロトコル、タイムアウトなどを設定できます。ヘッダーは共通設定とログ専用設定があり、ログだけに資格情報を渡したい場合は専用変数を優先してください。(opentelemetry.io)

一方で、DeepSeek Harnessがどの会話フィールドをどの属性へ変換するかは、OpenTelemetryの仕様だけでは判定できません。次の項目を、テスト端点の受信記録で個別に確認します。

1. ユーザー入力とAgentの出力が本文として入るか。
2. ツール名、引数、実行結果、標準エラーが記録されるか。
3. ローカルパス、リポジトリ名、ブランチ名、ホスト名が属性に入るか。
4. フィードバック本文と評価理由が別イベントで送られるか。
5. セッション識別子だけで過去の会話を再構成できるか。

OTLPログ端点の資格情報はどう保護しますか？

端点URLと認証ヘッダーを同じ設定ファイルへ固定保存せず、実行時の秘密情報注入、短い有効期限、端点ごとの限定権限を使ってください。ログ専用の認証情報を発行し、読み取り権限や管理権限と共有しない構成が適切です。認証情報を更新した後は、旧トークンが受信側と遠隔Macの双方で無効になったことも確認します。

OpenTelemetryのログバッチ処理には、実装によって待機時間、送信タイムアウト、キュー容量、バッチサイズが存在します。一般的な仕様上の既定値として、ログ送信タイムアウトは30秒、最大キューは2048件、最大バッチは512件とされていますが、これはDeepSeek Harness固有の保証ではありません。利用バージョンが採用するSDKと設定値を必ず確認してください。(opentelemetry.io)

遥測の送信に失敗するとAgentタスクも失敗しますか？

OpenTelemetryの一般仕様では、エクスポーターの失敗やタイムアウト、再試行、キュー廃棄の扱いはSDKと実装に依存します。標準仕様だけから、DeepSeek HarnessのAgent処理が必ず継続する、あるいは必ず停止するとは判断できません。端点を到達不能にし、Agentの終了コード、タスク状態、標準エラー、処理時間、再送の有無を確認してください。(opentelemetry.io)

確認できていない再試行回数や破棄件数を運用資料へ書くのは禁止です。少なくとも、正常送信、認証失敗、TLS証明書不一致、DNS失敗、端点応答遅延の5条件を別々に検証し、Agent本体と遥測送信の失敗を分けて記録します。

SECTION 05 第三段階：遠隔Macへ展開する前の実施順序

テスト端点での確認が終わったら、次の順番で遠隔Macへ展開します。端末ごとに同じ設定を配布するのではなく、環境ラベル、所有者、許可モード、端点、停止手順をひも付けてください。

1. 設定を固定する：許可された共有モードと変更者を構成管理へ登録します。
2. 出口を限定する：遠隔Macから許可されたOTLP端点への通信だけを通し、不要な外向き通信を残しません。
3. 秘密情報を注入する：認証情報を環境変数や秘密情報管理から起動時に渡し、ファイルや履歴へ残しません。
4. 無害なセッションで確認する：テスト用入力、ツールなしの応答、許可済みフィードバックを順番に送ります。
5. 禁止データを投入して確認する：実在の秘密ではなく、検出用のダミー文字列と架空パスを使い、受信記録へ入らないことを確認します。
6. 端点を遮断する：Agent処理、終了コード、タスク状態、標準エラー、未送信記録を保存します。
7. 正常停止する：プロセス停止後にエクスポーターの終了処理が走るか、設定されたタイムアウト内に戻るかを確認します。
8. 交付資料を作る：最終モード、許可端点、認証情報の撤回者、保存期間、削除担当、再有効化条件を記載します。

OpenTelemetryのSDKには、未送信データを可能な範囲で送る ForceFlush と、エクスポーターを終了させる Shutdown の概念があります。ただし、終了時にすべての記録が必ず届くという意味ではなく、タイムアウトや端点障害があれば完了しない記録が残り得ます。(opentelemetry.io)

遠隔Macの停止・交接チェック

• [ ] DeepSeek Harnessの共有モードを DISABLED に変更した
• [ ] 実行中のAgentプロセスとバックグラウンド処理を停止した
• [ ] 正常終了後にOTLP端点への新規接続がないことを確認した
• [ ] 送信待ちキュー、ローカル一時ファイル、標準出力を確認した
• [ ] OTLP端点の認証情報を撤回またはローテーションした
• [ ] 受信側の保存データとバックアップの削除担当を確定した
• [ ] 次の利用者へ、遥測を再有効化できる条件を明記した

遠隔Macの引き渡し前には、どの順番で会話遠隔測定を止めますか？

先にモードを DISABLED へ変更し、その後にAgentと関連プロセスを停止し、最後に端点資格情報を撤回してください。資格情報だけを先に無効化すると、停止時のエクスポーターが認証エラーを出し、未送信記録や終了処理の確認を難しくする場合があります。

ただし、停止処理の具体的な待機時間や未送信データの保持場所は、DeepSeek Harnessのバージョンと採用SDKの実装を確認してください。公式資料や再現試験で確認できない場合は、「削除済み」ではなく「削除確認待ち」として環境を引き渡します。

SECTION 06 最後に、現在の構成からMac運用へ切り替える判断

既存のWindows、Linux、共有クラウド環境で同じ観測を行う場合、端末ごとの出口制御が揃わない、秘密情報の注入経路が複数になる、利用終了後も一時ファイルや送信キューが残る、といった運用上の欠点が出やすくなります。特にチームで遠隔実行環境を共有すると、誰が遥測を有効化したか、どの端点へ送ったか、交付時に何を削除したかを追いにくくなります。

Mac上で実行環境を統一すれば、起動設定、外向き通信、停止手順を同じ検収項目で管理しやすくなります。ただし、長期の固定負荷、物理インターフェースが必要な作業、常時占有が前提のワークロードでは、購入や専有環境の方が適する場合もあります。短期の検証、障害再現、チームへの一時的な可観測環境の交付であれば、VPSNIXの遠隔Mac運用案内を確認し、まず DISABLED から始める構成が現実的です。

接続前に、VPSNIXのプライバシーポリシーとヘルプセンターの運用情報も確認してください。重要なのは、OpenTelemetryを有効にすることではなく、どの会話を、誰の許可で、どの端点へ送り、いつ消すかを遠隔Macの利用期間全体で説明できる状態にすることです。

関連記事

• DeepSeek Harnessのバックグラウンドタスクを検収する方法
• DeepSeek Harness API Keyの安全な保存先を選ぶ