エンジニアはかつてIDEについて議論し、今はハーネスについて議論する。
私はオープンソースのハーネス（Roo Code、DeepAgent CLI、HumanLayer）を使い、貢献してきた。初日に知っておきたかったことがある：ハーネスの出力をスラッジと直交させるために今すぐできることが3つある。それでも3つすべてに人間の判断が必要だ。
このガイドは、ハーネスが出力を複利にするか間違いを複利にするかを分ける単純なサーフェスをカバーする：設定ファイルを推論可能なほど軽く保つ方法、R.P.Iフレームワークを使ってモデルがスタッフエンジニアのように問題に向き合うプロンプトを構造化する方法、サブエージェントを使ってメインコンテキストウィンドウをクリーンに保つ方法。
最後には、今日のセットアップにできる具体的な変更のセットと、ハーネス（モデルだけでなく）こそがあなたのエンジニアリングの判断が違いを生む場所だという明確な感覚が得られるはずだ。
モデルが知能の源なら、ハーネスはその知能を有用にするものだ。ハーネスの主な仕事は以下を行う足場として機能することだ：
・セッションと圧縮によって本質的にステートレスなLLMのコンテキストを管理する
・ツール呼び出し、I/O処理、ガードレールをモデル周囲で動作させる
ハーネスを `while (have next message) do {tool}` ループと考えよう。滑らかなハーネス1つが以降に生成されるすべてのコードのスピードと品質を増幅する。
■ .mdファイルを軽く、人間が書いたものにする
今日のエージェントの核心的な欠点は「インストラクションバジェット」の概念だ。HumanLayerのKyleのパラフレーズで言うと、フロンティアの思考LLMはブロート（肥大化）の中で関連する指示に注意を払えなくなる「ダムゾーン」に入る前に数百の指示しか従えない。指示が多すぎると、実質的にモデルに幻覚を起こすよう促している。
グローバルシステムプロンプト——CLAUDE.mdやAGENTS.md——では、人間が書いたものがLLMが生成したものを上回る。ETHの研究はLLM生成のシステムプロンプトがパフォーマンスを低下させ、推論コストが約20%増加することを発見した。最小限の要件を記述する：プロジェクトが何か、エンドユーザーは誰か。すべてのトークンは場所を争うべきだ——毎回のセッションでグローバルに注入されるから。
モデルが必要とするかもしれないすべてをフロントロードし、できる限り詳細なif-elseルールを規定したいという衝動がある。しかしコンテキストを直接解析することはコンテキストウィンドウの貴重なスペースを消費し、推論ウィンドウをドロップさせる。
代わりに、プログレッシブ・ディスクロージャーを適用する：エージェントが必要な時だけコンテキストを引き出すようにし、個々の.mdファイルに説明的な名前を付けることで何が存在するかを知らせる。
【CLIs（コマンドラインインターフェース）】
エンジニアはすでにCLIでプログレッシブ・ディスクロージャーを名前もつけずに使っている。利用可能なサブコマンドを見るために--helpを実行し、特定のサブコマンドの--helpを掘り下げてフラグを確認する。エージェントも同じことができる。これはモデルが見たことのないCLI——あなたのAPIをラップするカスタム内部ツールでトレーニングデータがゼロ——で最も重要だ。プログレッシブ・ディスクロージャーなしでは、全リファレンスをコンテキストに貼り付ける必要があるだろう。これがあれば、エージェントはmycli --helpを実行し、関連サブコマンドを見つけ、次にmycli deploy --helpで特定のフラグを取得する。モデルはあなたがするのと同じ方法でツールのコマンドを発見し、コンテキストはクリーンなままだ。
【Skills（スキル）】
ここで業界が収束している。Claude Code、Codex、OpenCodeはすべて同じ方法でスキルのプログレッシブ・ディスクロージャーを実装している：起動時に、各スキルの名前と説明のみがコンテキストに読み込まれる。完全なSKILL.md指示はエージェントが現在のタスクにスキルが関連すると判断した時のみ読まれる。スキルは必要に応じてのみ読み込まれる参照ファイルやスクリプトを指すことができる。明確で具体的な説明を書けば、エージェントはボディを読まずにそれにマッチできる。エンジニアとして、これは具体的に、エージェントがリクエストに基づいて取得できる明確な命名規則を持つ個別ファイルに特定の指示（スキル）をコードベース全体にわたって維持することが有用だということを意味する。
【MCP tools（MCPツール）】
これはハーネスが大きく分岐する場所だ。
Claude CodeはビルトインのMCPツール検索を搭載している：セッション開始時にツール名の軽量インデックスを読み込み、次にオンデマンドで完全なスキーマを検索・取得する——Anthropicはこれでコンテキスト使用量が85%以上削減されると報告している。CodexとOpenCodeはセッション開始時にすべての設定済みMCPツール定義をコンテキストに読み込む。OpenCodeのドキュメントはコンテキストが速く埋まるため有効にするサーバーを制限するよう明示的にユーザーに警告している。
ハーネスがこれを処理してくれない場合は自分で管理する：プロジェクトごとに接続するMCPサーバーを選択的にし、検索ベースの発見が実際に機能するよう具体的でキーワードリッチなツール説明を書く。一方、コンテキストと推論トークンを節約するために無関係または未使用のMCPを切断することも確認する。
■ R.P.Iでより高い抽象レベルで作業する
軽い設定ファイルと最小限のツールセットが整ったら、次の決断はプロンプトの構造化方法だ。HumanLayerのR.P.Iフレームワークは有用なガイドラインだ：ハーネスとインタラクションする際、すべてのプロンプトは正確に3つのことのうち1つをすべきだ。
【Research（リサーチ）】
コードベースがユニークで複雑なら、エージェントに問題文を与え、構造を探索させる——先行事例、関数定義、ファイルの関連性を含む。このステップでアクションは取ってはならない。
【Plan（プラン）】
エージェントがステップバイステップの実行計画を書く。人間はコードベースに関するコンテキストとドメイン知識を考慮して、生成された計画を積極的にレビューし検証すべきだ。このステップで考えを外注したり怠けたりすると、後で高くつく。
【Implement（実装）】
承認された計画をメインウィンドウと呼べる新しいコンテキストウィンドウで実行する。これはスタックの底だ。計画が長くて不安なら、それぞれのセッションを持つサブエージェントのパターンを使うことをお勧めする——サブタスクの無関係な中間状態と反復的思考がメインコンテキストウィンドウを汚染しない。
ハーネスを操作することは、最高のスタッフエンジニアが問題解決に向き合う方法でそれを動作させることだ：問題をサブ問題に分解し、実装前に計画し、計画の第二の目を得る。抽象化はコード行単位からプロンプトにシフトしたが、根底にある規律は変わっていない。
■ サブエージェントを使ってクリーンなコンテキストを維持する
サブエージェントのコアヒューリスティックはシンプルだ：作業のサマリーがメインエージェントに十分な時に使う。中間コンテキストが必要なら——「これは以前に見たものとどう繋がるか」と尋ねたいなら——プライマリウィンドウに保持する。メインエージェントは推論する必要がない中間ステップの作業のみを委任すべきだ。例えば、サブエージェントに委任できるタスクは、メインコンテキストウィンドウが知る必要なく、最終結果のみが重要な一連のツール実行（取得など）だ。サブエージェントはメインの会話をクリーンに保ちながら、無関係な以前のメッセージなしに「スマートゾーン」にサブエージェントを保つ。
サブエージェントに適した2つのパターン：
【並列ファンアウト】
調査とリサーチに最も効果的だ。アラートが発火した時、エージェントは問題を調査し、根本原因の3つの候補理論を生成し、各理論を同時並行で調査するサブエージェントを起動できる。各サブエージェントは独立してログ、トレース、メトリクスを掘り下げる。メインエージェントは自分のコンテキストに数百のログ行を持つことなく3つのサマリーを受け取り結論を統合する。価値はスピードとコンテキストの分離だ：3つの並列検索は3つの順次検索より速く終わり、ノイズは隔離されたまま。同じパターンは複数のモデルから同時に出力が欲しい時にも適用できる。
【パイプライン】
パイプラインはファンアウトが幅を探索するのに対して深さを強化する。機能を順次的なロールを通して押し進める：ユーザーエクスペリエンスを評価するUXデザイナー、技術的実現可能性を評価するアーキテクト、仮定をストレステストするデビルズアドボケート。各ステージは前のステージの出力を受け取り分析を加える。メインエージェントは3つのレンズをすべてコンテキストに保持せずに層化された多角的な評価を得る。これはLLMのような非決定論的システムに特に有益だ。
■ テイクアウェイ：コミットする
ハーネスがタスクに失敗した時の誘惑はハーネスを切り替えることだ。すべてのセットアップを試すなと言っているのではない（Cursor、Claude Code、OpenCode、Codex、DeepAgent CLI含めて）。単に言いたいのは、1つを自分のワークフローに本当に合わせるために時間を投資する必要があるということだ。異なるハーネスは制約、コンテキストウィンドウ戦略、ツールルーティングロジックが異なる——常に切り替えることは設定ファイルにエンコードされた知識を失い、失敗ケースログをゼロからスタートすることを意味する。
だから推奨は、チームのユースケースの大部分をカバーするハーネスを選び（別の投稿でハーネスの選び方を解説予定）、すべての失敗をデータポイントとして扱う：何が、どのステップで、どんな条件下で壊れたか。それを.mdファイルに追加し、プロンプト戦略を相応に変える。最高のハーネスは自分がカスタマイズしイテレーションしたハーネスだ——チームの使用を通じてスムーズにされたエッジケースを処理できるもの。