ハーネスがすべてだ。最適化する方法はこちら。

エンジニアたちはかつてIDEについて議論していたが、今はハーネス（harness）について議論している。ハーネスとは、LLMを中心としたループ（while (have next message) do {tool}）であり、スムーズなハーネスはコード生成の速度と品質を大幅に向上させる。

本記事では、ハーネスを最適化するための3つの汎用パターンを紹介する。これらのパターンにはいずれも人間の判断が必要である。

.mdファイルを簡潔に保ち人手で書く

LLMには「指示予算」の制約がある。最先端のモデルでも、数百の指示を超えると「鈍感ゾーン」に入り、関連する指示を見落とし始める。過剰な指示は幻覚を促進する。グローバルシステムプロンプト（CLAUDE.mdやAGENTS.md）は人手で書くべきで、LLM生成のものはパフォーマンスを低下させ、推論コストを約20%増加させる（ETH研究）。プロジェクトの核心とエンドユーザーを記述し、各トークンがその存在価値を争うようにする。代わりにプログレッシブ・ディスクロージャーを採用する：必要なときだけエージェントにコンテキストを取得させ、記述的なファイル名で何が存在するかを知らせる。

CLIの場合、エージェントは--helpを実行してサブコマンドを発見できる。これはモデルが訓練データで見たことのないカスタム内部ツールで特に重要だ。スキル（Skills）については業界のコンセンサスが得られている：起動時には名前と説明だけを読み込み、エージェントが関連性を判断したときにのみ完全なSKILL.mdを読み込む。MCPツールも同様に、プロジェクトごとに接続するサーバーを選択し、ツールの説明は具体的でキーワード豊富に記述する。

R.P.I.を使用して高次の抽象化で作業する

HumanLayerのR.P.I.フレームワークは有用な指針である：各プロンプトはハーネスと対話する際に3つのうちの1つだけを行うべきである。調査（Research）：エージェントに問題文を与え、コードベースを探索させる。行動は取らない。計画（Plan）：エージェントがステップごとの実行計画を書き、人間が積極的にレビューする。実装（Implement）：承認された計画を新しいコンテキストウィンドウ（メインウィンドウ）で実行する。計画が長い場合は、サブエージェントパターンを使う。

サブエージェントを使ってクリーンなコンテキストを維持する

基本ヒューリスティックは単純：メインエージェントが作業の要約で十分な場合にサブエージェントを使う。2つのパターンがうまく機能する：並列ファンアウトとパイプライン。並列ファンアウトは調査に適している。例えばアラートが発報したとき、メインエージェントが3つの仮説を生成し、それぞれにサブエージェントを並列に起動してログやトレースを調査させる。パイプラインは機能を複数の役割（UXデザイナー、アーキテクト、悪魔の代弁者）に順次渡し、多角的な評価を得る。サブエージェントはメインコンテキストをクリーンに保ち、サブエージェント自身も「スマートゾーン」に留まる。

結論：コミットする

ハーネスがタスクに失敗したとき、別のハーネスに切り替えたくなる誘惑がある。しかし、頻繁な切り替えは設定ファイルに蓄積された組織的知識を失わせる。チームのユースケースの大部分をカバーするハーネスを選び（選び方については次回の記事で）、失敗をデータポイントとして扱い、.mdファイルとプロンプト戦略を反復改善することが推奨される。最良のハーネスとは、人間のエンジニアリングによってカスタマイズされ、チームの使用を通じてエッジケースが滑らかになったハーネスである。