手的コーディングを止めてニューラルネットワークのハーネスを設計し始める方法

最近、自分でも妙だなと思うようになりました。エディタに座り、Claude CodeやCursorのようなエージェントを起動してタスクを与え、10分後には作り上げた関数や壊れた型の嵐を整理しているなんてことがありませんか。5ページ分のシステムプロンプトを口述しようとすると状況はさらに悪化します：モデルは3ステップ目で指示の最初の内容を忘れてしまうのです。

実は、OpenAI、Anthropic、Cursorを取り巻くエンジニアリングコミュニティでは、この問題はすでに独立した分野としてformalizedされています。それはハーネスエンジニアリングと呼ばれ、エージェントのためのハーネスやbrakeを設計することとして理解できます。

リポジトリ deusyu/harness-engineering は、このトピックに関する広範な知識ベースを一箇所に集めています：Martin Fowler、LangChain、Bunのクリエイターらによる英語の概念分析、翻訳記事の数々、そして自分のプロジェクトにこのアプローチを実装するための готовые テンプレート。

このアイデアはどこから来たのか

従来の開発では人がコードを作成し、機械がそれを実行しますが、自律型エージェントの登場によりこのチェーンは変化します。人がゲームの制約とルールを定義し、ニューラルネットワークがコードを作成し、環境がチェックを実行してエージェントにフィードバックを返します。

重要なのは、エンジニアがすべての行の作者であることを止めるということです。エンジニアの主な成果物は制約のシステムになります：設定ファイル AGENTS.md、カスタムリンター、構造的テスト、CIにおける厳格なゲート。

リポジトリでは、あるチームの実際の実験データを引用しています：5ヶ月以上かけて3〜7人のチームで約15,000件のプルリクエストをマージし、合計ほぼ100万行のコードに達しました。1人あたり1日平均3.5件のPRをクローズしています。生成の大部分は6時間セッションで夜間に行われました。

ハーネスエンジニアリングの主要原則

リポジトリの著者は、このアプローチをいくつかの応用概念に分解しています。

リポジトリを唯一の真実の情報源として

gitリポジトリ内に存在しないものはすべて、エージェントにとっては存在しないものになります。Zoomでの通話、Slackでのアーキテクチャの議論、Google Docsの下書きは、モデルのコンテキストには入りません。

APIのシグネチャを変更したり、フォルダ構造について合意した場合は、バージョン管理されたファイルとしてリポジトリに保存する必要があります。すべての仕様書やタスク計画はすぐにブランチにコミットされます。

百科事典の代わりにマップを

エージェント開発の設定における一般的なミスは、すべてのプロジェクト指示を含む巨大なシステムファイルを作成することです。モデルは長いプロンプトに圧倒されてしまいます。

代わりに、約100行の AGENTS.md ファイルが使用されます。これは目次や地形図のように機能し、タスクに応じてエージェントをどのサブディレクトリを参照すべきかを示します。各サブディレクトリには独自のローカル AGENTS.md が含まれています。この原則は段階的コンテキスト開示と呼ばれます。

言葉による説得の代わりに機械的な制御を

ドキュメント内のテキストルールはすぐに時代遅れになり、エージェントはそれらを無視したり誤解釈したりしがちです。リンターやユニットテストは時代遅れになりません。

長いアーキテクチャスタイルの説明の代わりに、カスタムリンターが作成されます。最も興味深い点は、このようなリンターのエラーメッセージには問題の修正に関する明確な指示がすぐに含まれていることです。エージェントはチェックを実行し、リンターエラーをキャッチし、ヒントテキストを読み、問題のあるコードセクションを自ら書き換えます。

エージェントのためのコード可読性とエントロピー管理

ライブラリを選択する際は、安定した、よく文書化された、予測可能な動作を持つ技術が優先されます。ライブラリが複雑すぎたり、ダークメタプログラミングのマジックを使用していたりすると、エージェントは常につまずきます。複雑な外部パッケージの動作をニューラルネットワークに推測させるよりも、シンプルな内部モジュールをゼロから実装する方が簡単な場合があります。

さらに、エージェントは既存のコードベースで悪いパターンを見つけると、それをコピーするのが好きです。リポジトリが腐るのを防ぐために、特別なリファクタリングエージェントがバックグラウンドで実行されます。そのタスクは、標準からの逸脱を見つけて修正用のPRを作成することだけです。

自己参照型リポジトリ

プロジェクト deusyu/harness-engineering を興味深いものにしているのは、まさに説明する原則に基づいて構築されていることです。

リポジトリ内では、pre-commit hooksとGitHub Actions経由でトリガーされる厳格な scripts/check-consistency.sh スクリプトが実行されます。このスクリプトは13段階の整合性をチェックします：

• バッジやドキュメントに記載されている記事の正確な数を検証する
• ディレクトリ構造が宣言されたファイルツリーと一致することを監視する
• すべてのリンクとテーブルを検証する
• 記事の翻訳における画像監査を制御し、元の図表が失われないようにする

新しい資料の追加プロセスは、特殊なClaudeスキルを通じて自動化されており、エージェントが記事の初期解析とフォーマットを行い人間は最終的な検閲者としてのみ機能します。

このプロジェクトの対象者

一人でペットプロジェクトを作成していたり、チームでCursor、Claude Code、Aider、ローカルモデルと効率的な作業を設定したい場合は、このリポジトリをブックマークする価値があります。

ここには魔法のボタンや готовые バイナリはありません。これはハンドブックとエンジニアリング経験のコレクションであり、プロンプトが距離とともに機能しなくなる理由と、ニューラルネットワークがコードベースをダンプに変えるのではなく利益をもたらすようにリポジトリを設定する方法を説明しています。

学習を開始する最も簡単な方法は、 concepts/ ディレクトリ内のファイルから始めて、プロジェクトルートの AGENTS.md の実装を確認し、自分の作業リポジトリに同様の構造を適用してみることです。