エンジニア必見!「ハーネス(Harness)」とは一体何か?わかりやすく解説
What Is a Harness?
What Is a Harness?
ソフトウェア開発やテストの文脈で登場する「ハーネス(Test Harness)」とは、プログラムが正しく動作するかを確認するための補助的なコードやツールの枠組みを指します。簡単に言えば、テスト対象のコードを呼び出し、入力を与えて、その結果を検証するための「テスト環境の基盤」です。自動テストを効率化し、信頼性の高いソフトウェアを構築するために欠かせない存在です。
分かりやすくて、要点がまとまっていて最高。記事にしてくれてありがとう!技術に詳しくない友達みんなにシェアするよ。
ハーネス(Harness)こそ次のフロンティアだね。LLMが電気だとしたら、ハーネスは「電子機器」みたいなもの。今はClaudeとChatGPTでAC対DCみたいな争いをしてるけど、それが落ち着けば、実際に価値を提供するのはハーネスになるはず。
Piは拡張システムが素晴らしいから最高のハーネスだよ。Piを株式トレーダーにも、ソフトウェア工場にも、何にだって変えられる拡張機能を作れる。他のハーネスに乗り換えようとしたこともあるけど、Piほど拡張機能が優秀なのはなかった。
新しいハーネスやエージェントプロジェクトが出てきても、Piにコードベースを読み込ませて、その機能をPiに取り込む拡張機能を作らせてるよ。Prime IntellectやDeepseekのハーネスもそうやってPi上で動かしてる。
2025年の「エージェント」に続いて、2026年にはLLMベースのアプリで流行るバズワードだろうね。
まあ、実際そうだろうね。エージェントとして売り出されているものが、中身はただの昔ながらの決定論的なソフトウェアだったとしても驚かないよ。
バックパックの例えもいいね。
ハーネスとは、旅行やタスクに持ち出すもののことだよね。
何を持ち出すにしてもコスト(システムプロンプトやツール、スキルなど)がかかる。
スキルやツール、システムプロンプトをほとんど持たなくても優秀なモデルもあるけどね。
モデルを補完するのがハーネスだよ。
モデルが優秀であればあるほど、ハーネスは最小限で済む。
Pi [0] や smol [1] みたいなハーネスは、その中でもかなりミニマルな部類だね。
[0] https://github.com/earendil-works/pi (https://github.com/earendil-works/pi)
[1] https://github.com/smol-env/smol (https://github.com/smol-env/smol)
最近仕事で会計エージェント向けのハーネスを作ってるんだけど、かなり面白い経験だよ。
最初はLLMがプラットフォームとやり取りしやすくするためにCLIツールを作るところから始めたんだ。社内CLIを作る価値は本当におすすめ。作るのも楽しいし、エージェントにとっても非常に便利だよ。
最初はスキルと組み合わせていたんだけど、スキルを作る人たちがどうしても指示的になりすぎて、社内での自分自身の特定の機能に限定されちゃうことが多かったんだ。2,000行もあるようなスキルは、人間がやるのと同様の欠陥に苦しむことになる。エージェントがただのチェックリストに従うだけだと、自分がしている要求について推論しにくくなるからね。
だから、「エージェントに仕事を推論させて、ツールとガードレールだけ提供してコンテキストを収集し、会計処理をさせたらどうなるか?」を考えてみたんだ。
結局、フロンティアモデルは非常に優秀で、我々が一生懸命作った指示的なスキルよりも高いパフォーマンスを発揮したよ。どうやってタスクをこなすかの指示がなくても、より広範なタスクに対応できたんだ。
10年間CRUD開発をしてきた身としては新鮮で、ハーネスエンジニアリングはとても優れていると思う。
ハンドオフ(引き継ぎ)に優れたハーネスの提案はないかな?
ここで言うハンドオフとはこういうこと:
こういうのって存在するのかな?
以前はPull Requestがこれを集約するのに適した場所だと思ってたんだ。IDEが何であろうと、開発者が誰であろうと、場所がどこであろうと関係ないから。でも今は、エージェントハーネスの方がうまく吸収できる気がする。
なんでハンドオフが必要かって?自分のハーネスがどこで動いているのかコンテキストを見失うことが多すぎるんだ。隔離されたVMの中にいる時もあれば、ノートPCの時もあるし、自宅の強力なGPUを積んだマシンで動かしている時もある。もしTailscaleネットワーク内で自分自身を識別できるハーネスを起動できれば、単一のWeb UIから全てのコンテキストを管理できると思うんだ。
Piを使ってそういう構成を試してみようかと思ってるけど、もしかすると既に自分が考慮していないハーネスのパターンがあるかもしれないね。
著者です。皮肉なことに、この記事は明らかに非ハッカー向けに書いたものなんだけどね。でも、せっかくなので別の例えも考えていたんだ:
ハーネス = シャシー
モデル = エンジン
燃料 = トークン
エージェント = 車
みんなはどう思う?この例えの方が説明としてしっくりくるかな?
企業向けAIエージェントにとって、ハーネスはめちゃくちゃ重要になると思う。
今はどのツールも何らかのAIエージェントを搭載しようとしているけど、大企業におけるAIエージェントは結局、内部のMCP、CLI、APIなどを備えた社内アプリのようなものに落ち着く気がする。
用途ごとに異なるハーネスがあり、人によってアクセス権限が異なるようになるんじゃないかな。
プラットフォームエンジニアやインフラエンジニアがモジュール式のハーネスを構築して、個人やチームがそこにアクセスできるようにする仕組みは理にかなってるよね。
パーソナライゼーションのためにメモリを有効にしたチームメンバー専用のエージェントを持ったり、誰でも社内コンテキストを質問できる(パーソナライズされない)エージェントを持ったり、といった使い分けができるようになるはず。
自分はAgents.md / Claude.md / Project.md しか使っていないから、取り残されてる気分だな。スキルもツールもなし。エージェントにやってほしいことは全部その2つのファイルに書いてある。あと、スクリプトやソースなどのファイル構造を特定のディレクトリにまとめていて、それをmdファイル内でインデックスしてるよ。
ソフトウェアエンジニアたちがツールの意味について合意できない時、それはそのツールが「願望の代用品」に過ぎないということを示しているよ。