「ハーネス」とは何か 工場の比喩が嫌いだった私がトヨタの自働化とアンドンを持ち出す理由：及川卓也からエージェント時代の開発者たちへ（14）（1/2 ページ）

編集担当者から、「ハーネスエンジニアリングという言葉はふわっとしていて気持ちが悪い」と言われました。実際、ハーネスには決まった定義がなく、どう使うかも会社によってまちまちです。今回は、生成AI以前のテストハーネスとの比較と、トヨタの工場の考え方を手掛かりに、私がハーネスをどう考えているかを紹介します。

[及川卓也，Tably株式会社]

CI/CDのテストハーネス

　「ハーネス」と聞いて思い浮かぶのは、テストにおけるハーネスです。CI/CDで自動化されたテストは、「テストハーネス」と言えます。過去の開発プロジェクトでも、私はこれをさんざん経験してきました。変更を入れるたびにテストが走り、落ちれば先に進めません。日々の開発の一部でした。

　テストハーネスは、テストしたい部品を外から囲って動かすための仕組みです。部品を呼び出す「ドライバー」と、まだできていない部品や外部サービスの代わりをする「スタブ」を用意し、出てきた結果を期待値と照らし合わせます。多くの場合、本物のデータベースやネットワークにはつながず、偽物を用意して、部品だけを確かめます。

AI時代の「ハーネス」

　しかし、AI時代のハーネスは、テストハーネスと同じものではありません。違う形のハーネスです。

　AIを活用する場面では、「ハーネス」という語はまずモデルを評価する道具に使われました。2020年に公開された「lm-evaluation-harness」は、大規模言語モデルの成績を測るためのオープンソースの道具です。新しいモデルが出たときに、各モデルに同じ試験問題を解かせて答えを採点し、成績を比べます。こうした「評価ハーネス」は、オープンソースで公開されたモデル同士を比べるものだけではありません。クローズドAIモデルを作っている企業も、社内で評価ハーネスを使っています。例えば、モデルを更新するときに、前より悪くなったところ（リグレッション）がないかを確かめます。公開されていない社内の仕組みも、評価ハーネスと呼んでよいと思います。

　2025年の後半になると、Claude Codeのような製品そのものが「エージェントハーネス」と呼ばれるようになります。モデルにファイルを読ませ、コマンドを打たせ、その結果をまたモデルに返す。モデルをエージェントとして働かせるための外側の仕組みです。

　「ハーネスエンジニアリング」という語が広まったきっかけの一つは、2026年2月のミッチェル・ハシモト（Mitchell Hashimoto）氏のブログです。ハシモト氏は、開発ツールの会社HashiCorpの共同創業者です。同氏は記事「My AI Adoption Journey」で、エージェントが間違えるたびに、二度と同じ間違いをしないよう時間をかけて仕組みを作ることを「ハーネスエンジニアリング」と呼ぶようになった、と書いています。ただし、業界で決まった呼び名があるのかは分からないし、新しい語を作るつもりはない、とも書いています。

　その後、この語はあちこちで使われるようになりましたが、指している範囲は発信者ごとにばらばらです。広い方では、AIエージェント開発のフレームワークを作るLangChainの発信が、モデル以外の全てをハーネスと呼んでいます。狭い方では、コーディングエージェントの利用者が自分で足す外側の部分だけをハーネスと呼ぶ人もいます。業界で合意された定義はまだありません。「ふわっとしている」と感じるのは当然だと思います。

テストハーネスとの共通点と違い

　「テストハーネス」「評価ハーネス」「エージェントハーネス」を並べると、共通しているところと違うところが見えてきます。

　共通していると私が思うのは4つです。対象を外から囲うこと。対象を呼び出して動かすこと。外の世界との接点を管理すること。結果を確かめること。

　一番大きな違いは目的です。テストハーネスと評価ハーネスは、作ったものの品質を確かめるためのものです。コードやモデルが期待通りに動くかを確かめます。エージェントハーネスは、作業の最中にAIが踏み外さないようにするためのものです。確かめる対象は完成品ではなく、作業の一手一手です。

　囲う対象も違います。テストハーネスが囲うのは、呼ばれたときだけ動くコードでした。エージェントハーネスが囲うのは、次に何をするかを自分で決めて動くAI、つまりエージェントです。そのため、外の世界とのつなぎ方も変わりました。テストハーネスは多くの場合、外の世界を偽物で置き換えますが、エージェントハーネスは本物のファイルやシェル、ネットワークにつなぎます。本物につなぐ以上、何をしてよいかを権限で制限し、止める仕組みや人を呼ぶ仕組みを用意しなければなりません。テストハーネスにはなかったこうした要素が、今のハーネスには欠かせないものになっています。

　名前は同じでも、目的が違います。

　ここでいうハーネスには、Claude Codeのような製品が用意する部分も、私たちがCLAUDE.mdやフックで足す部分も含めています。今のハーネスが囲っているAIは、能力は非常に高いのですが、チームの作法を知りません。何をしてよく、何をしてはいけないか。どのディレクトリに触ってはいけないか、どのコマンドは確認なしに打ってはいけないか。人間のチームなら、新しく入った人に周りが少しずつ教えていくことです。ハーネスとは、作法を知らないAIを受け入れるための仕組みを、コードで書いたものだと思います。

　作法のうち、仕組みに持たせられるのは「何が異常か」の決まりです。この決まりを機械に持たせる知恵を、トヨタは「ニンベンが付いた『自働化』」と呼びました。

工場の比喩が嫌いだった私とトヨタの自働化

　ここで工場の話を持ち出すのは、実は少し気が引けます。私はソフトウェア開発を工場に例えるのが嫌いだったからです。理由は2つあります。

　一つは、工場が設計をしない場所だからです。工場をばかにしているわけではありません。けれども、工場は設計図に書かれたものを大量に作る場所で、設計はしません。一方、ソフトウェア開発は、設計と製造がきれいに分かれていません。作りながら設計が決まっていきますし、生成AIが出てきてからは、その傾向がむしろ強まっています。設計は難しい仕事です。そして生成AIが出るまでは、その後のコーディングも難しい仕事でした。設計をしない工場に、設計と製造が分かれていないソフトウェア開発を例えるのは違う、と思っていたのです。

　もう一つは、日本での工場とソフトウェア開発の関わり方です。1970〜80年代に、大手電機メーカーが工場の生産管理の手法を大規模なソフトウェア開発に持ち込む「ソフトウェア工場」の試みがありました。その後のSIの世界に残った工場のような体質にも、私は違和感を持っていました。

　ところが最近、「ソフトウェアファクトリー」という言葉をよく見かけます。ソースコードの管理からCI/CDまでをまとめた開発プラットフォームのGitLabは、2026年10月6日、組織が決めたポリシーと基準の下で、ソフトウェアをアイデアから本番まで運ぶ仕組みを「Governed Software Factory（統制されたソフトウェア工場）」と呼び、そのための新機能を発表しました。「統制された」と付けているところは、ハーネスの話につながります。日本のエンジニアがエージェントを使った開発の文脈でこの言葉を使うのも、目にするようになりました。海外では、人がコードを書かず、レビューもしない工場を目指す動きもあります。確かに、AIがどんどんコードを書く部分は、ロボットによる自動化が進んだ工場に似ています。