AIエージェントを開発・運用する際、「システム基盤が提示するリマインダーやタスク管理の指示に愚直に従って動作させる」設計を採用していないでしょうか。一見すると自律性と信頼性を高める健全な運用に見えますが、実際の開発現場では、この忠実さが予期せぬAPIコストの暴騰やコンテキストの急速な肥大化を引き起こすケースがあります。

本記事では、同一の執筆パイプラインを完走させた自社の5つのセッションログにおいて、進捗管理ツールの呼び出し回数が 「29回 vs 0回」 という極端な差を生んだ実測ケーススタディを提示します。エージェント制御基盤（Harness）がもたらす構造的オーバーヘッド「Harness Tax」のメカニズムを解明し、スキル側と基盤側の二重管理を防ぐための実用的な現場ルールと設計原則を解説します。

1. はじめに: リマインダーに素直に従うと、なぜコストが跳ね上がるのか

AIエージェントのシステム構成は、タスクの実行手順やドメイン知識を保持する 「スキル」 と、セッションループやツール呼出、コンテキスト履歴を制御する実行基盤 「Harness（ハーネス）」 の2層に分かれます。

開発者がエージェントの指示通りに作業を進めようとする際、Harness側が「未完了タスクの進捗をタスク管理ツールで更新してください」といった定期的なリマインダーや更新チェックリストを発行することがあります。しかし、スキル側が独自に進捗表を保持している場合、このHarness側のリマインダーに応じ続けることで、本来1回で済む状態更新が二重に行われ、大量のツール呼び出しが誘発されるパラドックスが発生します。

このようなエージェント基盤層の維持・制御に伴う構造的なトークン・コスト消費は、AIインフラ大手の Portkey.ai によって Harness Tax （ハーネスタックス）1 と呼ばれています。モデル本来の推論やコンテンツ生成とは直接関係のない「基盤維持のためのやり取り」が、APIコストの大半を占めてしまう現象です。

2. セッション実測ケーススタディ: ツール呼び出し「29回 vs 0回」の差

この「進捗管理の重複」がどれほどツール呼び出し回数に影響を与えるのか、自社で同一のコンテンツ執筆スキルを運用した5つのセッションログから抽出した一次計測データを比較します。

すべてのセッションは同じスキル仕様に基づき、同等品質の成果物を最後まで完成させています。しかし、タスク作成ツール（TaskCreate）およびタスク更新ツール（TaskUpdate）の呼び出し回数には以下の決定的な差が生じました。

セッションIDTaskCreate 呼び出しTaskUpdate 呼び出し成功呼び出し合計成果物の品質
セッション A10回19回29回完了（同等品質）
セッション B0回0回0回完了（同等品質）
セッション C0回0回0回完了（同等品質）
セッション D0回0回0回完了（同等品質）
セッション E1回（※パラメータエラーで即時失敗）0回0回完了（同等品質）

実測データから見えた事実

  • セッション A の突出: セッション A では、進捗ステップを進めるごとにタスク作成と更新が繰り返され、合計 29回 ものツール呼び出しが実行されました。
  • 他セッションのゼロ達成: 一方で、直前のセッション B〜E の4セッションでは、タスク管理ツールの成功呼び出し回数は 0回 でした。セッション E では複数タスクを1括送信しようとするパラメータ指定ミスで1回試行失敗したものの、タスクツールの更新なしで問題なく完了しています。
  • 成果物品質の同一性: タスクツールを29回呼んだセッション A と、0回で完了したセッション B〜E の間で、最終成果物の品質や達成状態に差は見られませんでした。

※ セッション A においてタスクツールが29回呼ばれた直接の引き金について、過去の振り返りメモでは「Harnessのリマインダーに機械的に応じたため」と解釈されていました。しかし生ログを詳細に検索したところ、直接的なシステムメッセージの記録は確認できませんでした。ログから確定できる客観的事実としては、「進捗管理ツールの呼出回数に29回 vs 0回という巨大な差が存在し、ツール呼出なしでも問題なく完走できた」という事実そのものです。

3. 構造分析: Harness Tax と進捗管理の二重化メカニズム

なぜ、同じスキルを実行しているにもかかわらずツール呼び出し数が29回も増加してしまうのでしょうか。その構造的背景には2つのメカニズムが存在します。

1. Harness Tax（基盤オーバーヘッド）の拡大

Portkey.ai の調査によると、エージェント基盤（Harness）の設計、システムプロンプトの冗長性、ツール定義の記述量、および履歴保持方針の違いにより、同一のタスクを実行する場合でも全体の消費トークン量が最大10倍以上変動することが実証されています1。

近年、業界全体が「単純な対話型チャットボット」から「自律型Harnessエージェント」へと移行する中で、基盤層が引き起こす不要なツール呼出やコンテキスト肥大化の制御が最重要課題となっています2。

2. 状態管理の「二重化」とコンテキスト増幅

今回実行したスキルには、フェーズ0からフェーズ7までの進捗状態をテキストドキュメント内の管理表として更新するロジックがあらかじめ組み込まれていました。

この状態で、Harness共通のタスク管理ツール（TaskCreate / TaskUpdate）が有効化されていると、エージェントは「スキル独自のPhase表」と「Harness共通のTaskツール」の両方を更新しようと試みます。1つの作業ステップを進めるたびに、会話履歴へのツール呼び出しリクエストとレスポンスの双方が挿入され、コンテキストウインドウが「進捗管理の通信ログ」で埋め尽くされていきます。

学術研究の ToolLLM (ArXiv:2307.16789)3 でも指摘されている通り、LLMに提示されるツールの選択肢や指示命令が増加するほど、モデルは誤ったツール選択や冗長な呼び出しループに陥りやすくなります。

4. 対策と現場ルール: スキルとHarnessの責務分離

この二重管理によるコスト急増を防ぐため、社内の意思決定ログにおいて、スキルとHarnessの責務を明確に分離する実務ルールが決定されました。

意思決定ルール [D20]: 進捗管理の一本化

「スキル本体に進捗表（例: Phase表）が組み込まれている実行期間中は、Harness側のタスク管理ツール（TaskCreate/TaskUpdate）の利用を明示的にスキップし、進捗管理をスキル側の表に一本化する」

進捗表を持つスキルを実行する際は、Harness標準のタスク管理ツールを呼び出さないよう、スキルの定義ファイル（SKILL.md 等）に明確な制御指示を記述します。

「引き算の設計（The Subtraction Principle）」の適用

ToolLLM 等の研究知見3 を元に本記事で整理する 「引き算の設計（The Subtraction Principle）」 とは、機能を無暗に追加するのではなく、特定の文脈で不要なツール定義や重複指示を意識的に削除・非表示化するアプローチです。

以下は、スキルのルール節に組み込むプロンプト記述の実例です。

## 進捗管理とツール利用のルール

1. 本スキルは内部の「Phase管理表（Phase 0〜7）」を用いて会話テキスト内で進捗を保持します。
2. Harness基盤が提供するタスク管理ツール（`TaskCreate`, `TaskUpdate`）は使用しないでください。
3. 進捗の更新は、ドキュメント内のPhase管理表の書き換えのみで行います。

このようにプロンプト上で責務を明記することで、エージェントがHarnessのリマインダーや共通ツール呼び出しに過剰反応することを防ぎ、セッションあたりのツール呼び出し回数を最小限に抑えられます。

5. まとめ: エージェント基盤設定を見直す4つのチェックリスト

AIエージェントのAPIコスト増大やコンテキスト溢れに悩んでいる場合は、自社の基盤設定とプロンプト構成を以下の4つの観点で点検することをお勧めします。

  1. 二重管理の有無: スキル固有の状態管理表と、Harness共通のタスクツールが重複して動いていないか？
  2. 機械的指示の評価: Harnessが出す自動リマインダーやチェックリストが、無用なツール呼び出しを誘発していないか？
  3. 引き算の設計（The Subtraction Principle）: スキル実行時に、不要な共通ツールの使用をプロンプトで明示的にスキップできているか？
  4. コストとツール呼び出しの可視化: 1セッションあたりのツール呼出回数やトークン消費内訳をリアルタイムにモニタリングできているか？

単一プロンプトの調整にとどまらず、複数のスキルやエージェントが連携する複雑なシステム全体において、Harness構造の最適化やガバナンス設計でお困りの際は、ぜひご相談ください。

コンタクトフォーム

Footnotes

  1. Portkey.ai - The Harness Tax: The Dead Weight Inside Your Coding Agent ↩ ↩2

  2. Portkey.ai - 1 Trillion Tokens and the Death of the Chatbot ↩

  3. ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (ArXiv:2307.16789) ↩ ↩2