Agent Harness 設計：適切なモデルの選び方

Model routing は leaderboard 競争ではなく運用統制です。privacy と data residency が許容モデル群を先に決め、タスク成功と品質が実用経路を選び、その後で token、latency、cost を最適化します。ローカルモデルには、より強い分解、retrieval、決定論的検証が必要です。

Harness が生産単位である

Enterprise Agent は、intake、context、policy gate、モデル、ツール、状態、検証、retry、observability、escalation から成る harness です。モデルは交換可能な部品にすぎません。選ぶのは「最良モデル」ではなく、タスクを検証済み業務状態へ運ぶ許容経路です。thread ベースの AI オペレーション層なら executor が変わっても routing、状態、認可、証拠を維持できます。

Gate 1：Privacy、Residency、契約上の許容性

タスクごとにデータ分類、処理・保存地域、保持、logging、training 利用、subprocessor、越境移転、暗号化、identity、audit、本番権限、retrieval 文書の持ち出し可否を定義します。不適合 endpoint は品質評価前に除外します。

Residency は一時ファイル、index、trace、review queue、backup を含む経路全体に適用されます。氏名だけ消し一意 ID を残す処理は匿名化ではありません。この gate は許容候補を作るだけで、勝者を決めません。

Gate 2：タスク成功、その後に品質

成功とは、解決可能な根拠を持つ回答、source span と結び付いた schema-valid record、または承認済み操作と readback です。美しい文章でも schema 違反、禁止ツール、根拠欠落なら失敗です。

評価には通常ケース、policy 境界、欠損・矛盾データ、ツール障害、prompt injection、必須 escalation、言語・形式差を含めます。schema、認可、証拠、正しい abstention を表現より先に評価します。ドメイン固有の Agent Skillsは手順と確認を安定させます。

Gate 3：Tokens、Latency、Cost

見るべきは token 単価ではなく、検証済みタスク当たりの総コストです。

次元	Harness レベルの指標
成功	許容試行当たりの検証済み完了
品質	first-pass、欠陥重大度、escape rate
Tokens	完了当たり input、cache、output、retry
Latency	trigger から検証状態までの中央値と tail
Cost	inference、retrieval、tool、review、手戻り
安定性	時間、形式、タスク分類をまたぐ変動

現行経路を Baseline = 100 とします。低いコスト指数が有効なのは、成功率、例外負荷、review 時間が悪化しない場合だけです。

ユーザーではなくタスクを Routing する

task_type: extract | classify | synthesize | plan | act | verify
data_class: public | internal | confidential | restricted
residency: approved_regions
authority: read | recommend | dry_run | approved_write
evidence: source_ids and freshness requirements
output_contract: schema or rubric version
risk: consequence and reversibility
latency_budget: interactive | asynchronous | batch

data class、residency、authority は決定論的に扱い、不確実なら安全側へ送ります。policy、model、prompt/skill、source、tool call、verifier、最終状態を routing receipt に残します。

ローカルモデルに別の Harness が必要な理由

ローカル推論はデータ統制、予測可能なコスト、offline 動作を提供しますが、指示追従、ツール選択、長文脈、多言語で不安定な場合があります。

より細かく分解する

文書選択、抽出、分類、執筆、検証を分離し、各工程に狭い契約と checkpoint を設けます。

少なく、より良く取得する

repository 全体を context に入れることは retrieval ではありません。構造化 index、filter、freshness、短い evidence packet を使います。retrieval と Web 検索を備えたローカル AI アシスタントは証拠層の重要性を示します。

決定論的に検証する

schema、parser、allow-list、DB constraint、計算、policy engine、readback で field、ID、合計、権限、最終状態を確認します。同じ call に生成、採点、承認を兼ねさせません。

Cascade、Fallback、Abstention

条件を満たす最小コスト経路から始め、schema 不正、証拠不足、source conflict、tool 障害、policy gate、verifier failure で escalate します。Fallback は residency や authority を迂回せず、未実行の操作を装いません。契約が求める正しい拒否や escalation は成功です。

状態、Version、再現性

task、policy、provider、region、model、prompt、skill、tool schema、retrieval query、source ID、freshness、parameter、verifier、retry、review、action、readback を version 管理します。再現性は入力、設定、外部操作、証拠から生まれ、無制限な思考過程の保存からではありません。プロジェクト固有 Agent の調整でも変更と障害の可観測性が必要です。

実務的な選定プロセス

タスク分類を定義。 2. 許容 gate を適用。 3. 代表・境界・攻撃ケースを作成。 4. 実 harness で検証。 5. hard failure を除外。 6. 成功と品質を採点。 7. 総効率を計測。 8. shadow/dry-run で pilot。 9. 分類ごとに承認。 10. 変更や drift 時に再評価。

意思決定ルール

Privacy、residency、契約が許容性を、検証済み成功と品質が能力を、token、latency、総コストが残る経路の効率を決めます。正しい選択は、品質境界内でタスクを完了し、結果を証明できる最小の許容システムです。