DeepInfer から DeepSeek Harness へ：監査できるエージェントの範囲を決める

前回のゲスト記事ではスタックを整理した。モデル、DeepInfer のような推論エンジン、DeepSeek Harness のようなエージェントハーネス、そしてエージェントが呼べるツールだ。今回はその地図を、実際の1つのデプロイのためのスコープ表に変える。

多くのチームは最初に間違った問いを立てる。どのモデルが最も賢いか、どの API が最も多くのコネクタを持つか、金曜日までにどう動かすか。それらは後でよい。最初の問いはもっと狭い。このエージェントに許す1つのタスクは何で、正しく終わったことを何が示すのか。

そこは最も安く失敗できる場所でもある。目的が曖昧でツール権限が広いエージェントは、生産性の勝利ではなく、承認者が実際の操作を見ないまま起きる事故の待機状態だ。以下は、動かす前に境界を引くための方法である。

1つのタスク、1つの終点

「競合を調査する」はタスクではない。停止条件も、受け入れ可能な成果物も、有用なブリーフと説得力のある段落の山を区別する手段もない。狭くすると地味だが、動く。

入力、成果物、根拠、停止条件が明示され、承認ポイントも明確になる。マーケティング責任者がブリーフを確認してからポジショニング文案に使う。調査タスクの中では外部操作は起きない。

コーディングエージェントなら、リポジトリのパス、テストコマンド、完了定義が相当する。サポートエージェントなら、1つのチケット区分、許可された返信群、人間への引き継ぎ規則だ。形は変わるが、規律は変わらない。

ツール契約

タスクが狭まったら、本当に必要なツールを列挙する。ベンダーが持つツール全部でも、来四半期に使うかもしれないものでもない。入力から「レビュー可能な成果物」まで運ぶ2〜3の接続だけだ。

リストは製品名ではなく、結果の重さで分類するとよい。

最初のデプロイは読み取りと準備で止めるべきだ。臆病ではなく、検索の品質を確かめてから行動権限を与える順序である。SpringBrand のエージェントが接続すべきツールを整理するガイドも、別の方向から同じことを言っている。1つの業務上の問いから始め、アカウントや情報源を解決し、タスクが必要とするときだけ接続を増やす。

契約には失敗時の挙動も書く。タイムアウトは「レコードなし」ではない。期限切れの資格情報は空の結果ではない。この2つを区別できないと、レビュー担当者は「確認済みの空白」と「切れた接続」を区別できない。

読み取りと書き込みは資格情報の設計

権限をプロンプトの指示として書くのは魅力的だ。「何も削除しないで」と言う。それは制御ではない。制御は資格情報、ツールスキーマ、実行層にある。

まず読み取り専用の資格情報を与える。書き込みが必要なら、別の ID と狭いスコープを与え、承認なしでは呼べないツールの後ろに置く。便利だからといって管理者のトークンを再利用しない。エージェントが管理者と同じレコードに届くなら、プロンプトインジェクションも同じ範囲に届く。

SpringBrand のAI エージェントのセキュリティガイドはここで役立つ。データ、ツール、ID、操作の境界を描き、読み取り権限と書き込み権限を分け、取得した内容を信頼しない入力として扱い、認可をモデルの外に置く。最後の点が最も飛ばされる。Web ページは指示を含められるが、権限を付与することはできない。

DeepSeek Harness は実行時にも同じ継ぎ目を提供する。スコープ付きツールレジストリ、承認ポリシー、サンドボックスモード、追記専用のセッションログだ。これらはあなたのアクセスモデルを置き換えないが、それを強制する場所を与える。

不可逆な操作の直前に人を置く

承認ポイントは「ワークフローのどこか」ではない。元に戻せない操作の直前であり、レビュー担当者にこれから起きる具体物を見せる。宛先、件名、本文、送信先、金額、レコード変更だ。

メール送信後の承認は通知にすぎない。送信の3ステップ前の承認は、途中で変わった下書きを承認しているかもしれない。レビュー担当者が必要とするのは最終的な提案であり、計画の要約ではない。

これは SpringBrand のhuman-in-the-loop ツール比較の中心でもある。結果の直前に止め、レビューした値を保持し、判断を実際に実行される操作へ結び、拒否やタイムアウト後の挙動を決める。Gumloop、n8n、Zapier、自作の承認キューでもパターンは同じだ。

dsh では承認ポリシーとツール呼び出しの境界に対応する。操作が「送信」ならレビュー担当者はそのメールを見るべきだ。「公開」ならページと URL を見るべきだ。「タスクを承認」は粗すぎる。

ボットチームを使うなら、限界を先に読む

DeepSeek Harness のコミュニティプラグインは増えている。一例が DeepSeek Bot だ。名前付きボット、ボット間メッセージ、グループチャットをハーネスに追加する。DeepSeek 公式製品ではなく、dsh を使うのに必須でもない。

それでも有用なケースだ。SpringBrand のDeepSeek Bot の役割と限界は、調査ブリーフを収集、比較、起草の3ボットに分け、本当に重要な問いを立てる。共有メモリはどこにあり、アンインストール後はデータがどうなり、ブリーフを使う前に誰が情報源を確認するのか。

問いはボットの数だけ増える。ボットチームは調整とモデル利用を増やすが、カバレッジを自動で増やさない。3つのアシスタントが同じページを言い換えるなら、テキストは増えても証拠は増えない。独立した仕事——たとえば引用の独立確認——があるときだけ役割を足す。

人が読める監査証跡を残す

再構成できないエージェントに、結果のある操作を任せるべきではない。最低限、次を記録する。

• タスクと承認済みのスコープ。
• 呼び出したツール、入力、出力。
• モデルまたはプロバイダーのバージョン、ハーネスのバージョン。
• 不可逆操作を承認した人と、その人が見た内容。
• 外部結果。失敗とタイムアウトを含む。

dsh の追記専用セッションログは、最初の3つの自然な背骨になる。承認キューと対象システムが残り2つを持つ。重要な設計は、安定した task ID または proposal ID で結び、レビューの判断を実際に実行された操作へ対応させることだ。

「デモは成功した」が監査で落ちるのもここだ。チャットに「done」と書いてあっても、CRM 更新が起きたこと、メールが送られたこと、レビュー担当者が承認した版が実際に届いたことは証明できない。

1ページのスコープ表

最初のツールをつなぐ前に、これを埋める。空欄があれば、そのタスクを任せる準備はできていない。

方法は地味だ。モデルは交換でき、推論エンジンも交換でき、ハーネスも交換できる。スコープ、権限、監査証跡だけが、このデプロイを説明可能にする。

エージェントのスコープ、ツール契約、レビュー設計については、SpringBrand のエージェントワークフローのブログに長いガイドがある。設計の参考として読み、自分のワークフローのテスト代わりにはしないこと。

FAQ

出典

• DeepSeek Harness リポジトリ — README、ライセンス、developer preview の注意、起動コマンド。
• DeepSeek Harness アーキテクチャ — プロファイル、バンドル、ツールレジストリ、セッションログ。
• DeepSeek Harness 安全ガイド — サンドボックスと承認の方針。
• 推論の上の層 — 本サイトの前回のゲスト記事。4層のスタック。
• DeepInfer の制約 — 推論エンジンが完全なサービングスタックではない理由。

次に読む：比較ハブ、またはDeepInfer のアーキテクチャ。