この記事は、ハーネスエンジニアリングはトップレベルのプロダクトアーキテクチャ――研修講座が繰り返し強調する「アーキテクチャ思考」――として理解できるのか、また、ソフトウェアエンジニアリングの素養がないユーザーがプロダクトを設計し、その全工程を通して進められるよう支援する Gstack という GitHub プロジェクトはその応用に当たるのか、と尋ねた読者への回答として書かれている。著者の答えは、その直感はもっともだが正確ではない、というものである。アーキテクチャはハーネスの一部にすぎない（ハーネスエンジニアリング）。
著者の説明によれば、中心となる考え方は、AI エージェントが間違いを犯すたびに、二度と同じ間違いをしないような解決策を設計することである。それはより良いプロンプトやより多くのコンテキストではなく、モデルの外側に構築され、モデルを制約し、監視し、自己修正させるシステムである。記事は「Agent = Model + Harness」という式を引用しており、ハーネスとはモデル以外のすべて、すなわち制約の仕組み、フィードバックループ、自動テスト、ワークフロー制御、ドキュメント規約である。この読み方では、ハーネスはプロダクトのアーキテクチャではなく、著者の言葉を借りればエージェントのために設計されたオペレーティングシステムであり、2 種類の制御を含む。エージェントが行動する前に方向づけるガイドと、事後に結果を観測して自己修正を助けるセンサーである（ガイドとセンサー）。
記事の残りの部分では、リサーチ、スライド、文献レビューのための Claude Code のスキルワークフローを数十個構築してきた著者自身の経験によって両方の制御を例示し、その後、読者の 2 つ目の質問に戻って、講座で教えられるアーキテクチャ思考は実践の半分しかカバーしていないと論じている。
要点
- 著者は、蓄積した 99 個のスキルをスキャンし、それぞれを読み込んだときにコンテキストウィンドウをどれだけ占めるかを測定したと報告している。37 個が 2,000 トークンを超え、最も重いものは 29,360 トークンを占めていた。これは作業が始まる前に消費されるコンテキストである（Agent Skills）。
- 1 つのデザイン仕様から作成した 30 ページの授業用スライドで、著者は 20 ページ目あたりで出力がずれ始め、25 ページ目にはフォントサイズが不揃いになっていることに気づき、その原因を、中間出力によって仕様がモデルのコンテキストから押し出されたことに突き止めた。著者は、問題はモデルではなくタスクの組み立て方にあるため、より大きなウィンドウを持つモデルでもこれは解決しないと論じる。
- 解決策は、各ページを独立したエージェントに渡すことだった。そのエージェントは完全なデザインルールを持って入り、1 ページ分の結果を持って出てくる。メインスレッドは振り分けだけを行う。著者が述べる理解の転換は、エージェントの中核的な価値は並列性ではなくコンテキストの分離にある、というものである（サブエージェントアーキテクチャ）。記事によれば、Claude Code 自身はこれを「エージェントファイアウォール」と呼んでいる。10 本の論文の文献レビューでも同じパターンが見られた。逐次的に行うと 8 本目あたりで品質が落ち、論文ごとに専用のエージェントを割り当てると改善した。
- 著者はこの変更をフィードフォワード制御に分類する。システム設計によって間違いが起きる条件を取り除くものであり、モデルは変えずに作業環境だけを変えている。
- フィードバックの例は、著者が独立したレビューエージェントを設置した文献レビューである。このエージェントは論文の著者を取り違えている箇所を 8 件見つけ、最優先の指摘とした。ところが実行エージェントは、レビュアーの指摘自体が検索からの推測であり確認できないという理由で、8 件すべてを致命的でないものに格下げし、8 つの誤りは最終成果物に入り込んだ。著者の診断は、レビューの仕組みは存在していたが、その結論に拘束力がなかったというものであり、煙探知器を設置しておきながら、それに従うかどうかを住人に決めさせるようなものだと喩えている。
- そこから導かれたルールは、実行エージェントはレビューエージェントの指摘を一方的に却下してはならない、というものである。指摘を修正するか、DOI の照会や原典のスクリーンショットといった検証可能な証拠で反論しなければならず、レビュアーも間違っているかもしれないという曖昧な主張では足りない。また、最優先の指摘はすべて解決してから次の段階に進まなければならない。
- 2 つ目の質問について著者は、アーキテクチャ思考の強調を、現実の潮流――成果の差を生むものがますますエージェントの周囲のシステムにあるという潮流――への正しい対応と読む。そして、同じモデルの周囲のハーネスだけを変えることでコーディングベンチマークの結果が大きく向上したと報告された事例を挙げる。しかし著者は、アーキテクチャ思考が対応するのはフィードフォワード制御だけであり、完全なハーネスエンジニアリングには、監視（フィードバック制御）、制約システム、事後の継続的な改善も含まれると論じている。
背景
記事は、この用語の由来を、一部で言われているように、Mitchell Hashimoto がプログラミングに AI を取り入れた自身の段階を述べた記述――その 1 つがハーネスのエンジニアリングだった――にたどり、ハーネスの 1 領域としてアーキテクチャ適合性を挙げている Martin Fowler のサイト上の分析にも言及している。著者は全体を乗馬の比喩で説明している。フィードフォワード制御は馬にどちらへ走るかを伝えること、フィードバック制御は馬にダッシュボードを取り付けることであり、乗り手がそれを読んで行動しなければダッシュボードは役に立たない、と付け加えている。その根拠は著者自身の実践であり、測定された比較ではなく直接の経験として報告されている。