アーキテクチャ、役割、コンテキストの管理：トークン消費を抑え、より信頼性の高い結果を得る方法

ここ数ヶ月、多くのフロントエンドチーム（およびそれ以外のチーム）が身をもって学んでいることが明らかになってきました：「より強力なモデル」だけでは、弱いアーキテクチャを救えない。最上位クラスのLLMを使っていても、制御不能に膨らむコンテキスト、混在した役割、頻繁なマージ、ずさんなテスト管理といった混乱したワークフローに組み込んでしまえば、トークン、時間、品質をすべて浪費してしまいます。

その逆もまた興味深い事実です：よく設計されたハーネスは、より安価なモデルからも驚くべき結果を引き出せる。特に、明確な役割を与えて運用する場合に顕著です。

ハーネスとは何か（そしてなぜモデルより重要なのか）

ここで言う「ハーネス」とは、単に長いプロンプトや追加のルールのことではありません。ハーネスとは以下の総体です：

  • 役割のオーケストレーション（計画担当、実行担当、検証担当の分担）;
  • コンテキスト構造（各エージェントが何を見、どれくらいの頻度で更新されるか）;
  • 統合ワークフロー（ブランチング、マージ、競合管理）;
  • テストサイクル（迅速かつ自動的なフィードバック、変更のゲーティング）;
  • ドリフト防止戦略（エージェントが目的から逸脱するのを制限）。

要するに、「コードを書くモデル」とソフトウェアを生産するエンジニアリングされたシステムの違いです。

シングルエージェントの問題：ドリフトとコンテキスト飽和

大規模なプロジェクトを単一エージェントに任せると、非常に具体的な理由で失敗しがちです：

  • 全体像と局所的な詳細の両方を記憶し続けなければならない。
  • コンテキストウィンドウが巨大であっても、「すべてを抱え続ける」認知コストは増大します。
  • 時間が経つにつれ、エージェントは次の状態に陥る可能性があります：
    • 全体像を見失い、間違ったものを最適化する；
    • 抽象度が高すぎて、脆弱な実装を生む；
    • 矛盾、レグレッション、追跡困難なバグを導入する。

これが「ドリフト」の根本原因です。これは（単に）モデルの限界ではなく、プロセスの限界です。

ツリー構造のスウォーム：コンテキストと責任の分離

効果的なマルチエージェントアプローチは、非常にシンプルなメタファーを使います：木と葉。

  • 最上位にはプランナーがいます：全体像を維持し、ステップに分解し、受入基準を定義します。
  • 下位にはワーカーがいます：小さなタスクを受け取り、実装します。

すべてを変えるルールは、厳格な分担です：

  • プランナーは実装しない → 低レベルの詳細で「埋もれ」ず、設計に集中し続けられる；
  • ワーカーは計画しない → アーキテクチャに迷わず、明確に定義されたタスクに集中する。

この分離により、単一エージェントが「木全体を歩き」、すべての祖先、決定、制約を持ち歩く必要が劇的に減ります。

モデルの経済性：高価なプランナー、安価なワーカー

このスキームの最も実践的な帰結のひとつは、以下の使い分けができることです：

  • フロンティアモデル（高価）を計画に使う；
  • 1つ以上のより安価なモデルを実行に使う。

「常に最高のモデルを買ってスケールする」ことに慣れた人にとっては直感に反する結果ですが：総コストは大幅に低下し、品質は損なわれません。なぜなら実行部分が最もトークン集約的だからです。

さまざまな組み合わせを比較した結果、「フロンティアをプランナー＋安価モデルをワーカー」という構成は、同じ機能的成果を、フロンティアを両方に使った場合と比べてトークン消費が1桁低い支出で達成できました。

運用品質：競合の減少、コード量の削減、より高い制御性

成熟したハーネスは、最終スコアだけでなく、エンジニアリングに携わる誰もが認識する運用メトリクスによっても評価されます：

1) マージ競合は混沌の症状

スウォームが大量の競合を生成する場合、それは「Gitの問題」ではなく、エージェントを境界なく過度に重複させて動作させているサインです。

より良いハーネスは次のことを行います：

  • 共通ファイル／領域での同時作業を減らす；
  • 統合の順序を強制する；
  • 非互換性を早期に表面化させる。

2) コード行数 ＝ 進捗 ではない

もう一つのパターン：生成されるコードが少ないことは、よりクリーンなプロセスを意味する可能性があります。

同じタスクを大幅に少ない行数で解決する場合、多くの場合、次のことを示します：

  • 重複の減少；
  • 不要な「創造的再実装」の減少；
  • 既存のライブラリ／プリミティブのより良い再利用と遵守；
  • churn の減少（書き、書き直し、ループでの再構築）。

これは絶対的なルールではありません—時にはより多くのコードが「より正しい」こともあります—が、エージェントシナリオでは、膨大なコード生成はしばしば警鐘となります。

「仕様が新しいプロンプト」：作業単位の変化

チームで働く人（および製品を構築する人）にとって価値ある考え方があります：作業単位が移行しつつある。

  • オートコンプリート → 単位：単一行。
  • 「古典的」モデル → 単位：ブロックまたは関数。
  • エージェント → 単位：ファイル／機能。
  • スウォーム → 単位：仕様。

スウォームの場合、上流で行うことが決定的になります：よく書かれた仕様は品質の乗数です。無限である必要はなく、検証可能であることが重要です：

  • 明確な機能要件；
  • 制約（API、パフォーマンス、互換性）；
  • 受入基準（テスト、エッジケース）；
  • 曖昧さのない「完了」の定義。

フロントエンド担当者への実践的示唆（例が「バックエンド寄り」でも）

データベースの再構築はフロントエンドから遠く感じるかもしれませんが、教訓は以下にそのまま当てはまります：

  • デザインシステムのリファクタリング；
  • ReduxからZustandへ／VueからReactへ／CSRからSSRへの移行；
  • ルーティング、認証、キャッシュ、i18nを含むアプリの書き換え；
  • E2EテストとUIリグレッションの自動化。

今日、コード生成にエージェントを試しているなら、優先すべきは常に最新のモデルを追いかけることではなく、混沌を防ぐハーネスを構築することです。

堅牢なハーネスを実現するための具体的なチェックリスト

このアプローチを再現可能にするために、以下のポイントは確かな基盤となります：

  1. 役割の分離：プランナー ≠ 実装者 ≠ レビュアー。
  2. 小さく検証可能なタスクをワーカーに（狭いスコープ、限定されたファイル／領域）。
  3. テストをゲートに：対象を絞ったテストが失敗→成功するまでマージしない。
  4. ブランチ戦略：同一ファイル上での並行作業を最小化。
  5. 制御されたメモリ：コンテキストは有用な成果物（決定、API、契約）のみで更新し、ログやノイズは含めない。
  6. 運用メトリクス：競合、churn、LOC、グリーンビルドまでの時間、リグレッション率。

まとめ：モデルだけでなくハーネスに時間を投資する

最終メッセージはシンプルで非常に「エンジニアリング的」です：プロセスのアーキテクチャは生の性能を上回る。

フロンティアモデルは特に計画や意思決定に適した選択肢かもしれませんが、高コストの実験と生産システムの違いは、ハーネスの規律にあります：役割の分離、制御されたコンテキスト、秩序ある統合、そして各ステップを導くテストです。

コード生成能力がすでにコモディティ化した世界では、競争優位性は多くの人が過小評価する点に移っています：エージェントの作業をどう組織するか、そして予算を浪費せずプロジェクトの制御を失うことなく、仕様を検証可能なソフトウェアに変換する方法です。

Articolo originale: https://frontendfacile.it/blog/perche-l-harness-batte-il-modello-lezioni-pratiche-dai-sistemi-multi-agente