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

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

　工場の比喩が嫌いだった私が工場を持ち出すのはわれながらおかしいのですが、ここではトヨタの考え方を参考にしてみます。トヨタ生産方式をソフトウェアに持ち込む話は、リーンソフトウェア開発やCIの頃からあります。

　トヨタ生産方式は、トヨタ自動車が作り上げた生産の考え方で、「ジャスト・イン・タイム」と「自働化」の2本の柱からなります。ジャスト・イン・タイムは、必要なものを、必要なときに、必要なだけ作る考え方で、皆さんよくご存じだと思います。それを支える「カンバン」の仕組みは、ソフトウェア開発にもカンバンボードとして取り入れられています。今回取り上げるのは、もう一本の柱の自働化です。

　自働化は、普通の自動化に人間の知恵を付けたもので、上述の通りトヨタは「ニンベンの付いた自働化」と呼んでいます。「異常が分かる」「異常で止まる」「異常で止める」ことで不良品を作らず、後の工程に流さない。異常がはっきり分かるので、再発防止にもつながるとトヨタは説明しています。起源は、豊田佐吉が発明した、糸が切れると止まる織機です。

　ハーネスで言えば、「テスト」「型チェック」「リンター」「フック（エージェントが特定の操作をする前後に自動で走る処理）」がこれに当たります。AIが作ったものに異常があれば、そこで止まり、先に進めない仕組みです。一方、権限の設定は自働化とは別のものです。工場で言えば、人や設備を守る安全柵に近いと思います。工場でも、品質を守る仕組みと安全を守る仕組みは別の系統として扱われています。

　身近なところでは、CLAUDE.mdに「〇〇しないこと」と書き足すのは、ラインに「注意！」の貼り紙を増やすのと同じです。トヨタには、「なぜ」を繰り返して問題の真因を突き止める「なぜなぜ分析」という手法があります。そこでは、「注意する」だけでは対策として不十分だとされます。代わりに、より上位の対策とされるのが「ポカヨケ」です。つまり、間違いを防いだり、間違えてもすぐ気付いて止めたりする仕組みです。ハーネスで言えば、フックや型、権限で、そもそもできなくしたり、すぐ止めたりすることです。ただし、標準書（ここでは指示ファイル）が要らないという意味ではありません。決まりを書くことと、決まりを守らせる仕組みを作ることは、別の仕事です。

　ハシモト氏の「間違えるたびに、二度と同じ間違いをしない仕組みを作る」は、トヨタの「止めて、真因を潰し、標準を直す」とよく似ています。同氏がトヨタを参照しているわけではありません。工場では、止めた後の対応が二段に分かれます。まずラインを動かすための応急処置をし、後で恒久対策をします。「二度と」に当たるのは後者です。

　私は自動車業界の仕事に関わってきましたし、今も関わっています。工場には生産技術という仕事があり、それがソフトウェアでいう開発基盤に当たることはよく知っています。自動車の工場は自動車を設計しませんが、作り方は設計しています。工程の順番、設備や治具、検査をどこに置くか、何を異常とするか。これを考えるのが生産技術です。ハーネスの仕組みを考えることは、AIソフトウェア工場の生産技術に当たると思います。ここまでは、工場の比喩がよく当てはまります。

　ただ、AIがコードを書くソフトウェアの工場では、製品の設計と作り方の設計がはっきり分かれません。工場は設計をしない、という私の違和感は、半分は当たっていたことになります。

アンドンが鳴る場所

　アンドンは、ラインの異常を知らせる表示板です。作業者が異常に気付くと、ひもやボタンでアンドンをつけ、まず班長などの責任者を呼びます。その場で直せればラインは止まらず、直せなければ決まった位置で止まります。アンドンの第1の役目は、人を呼ぶことです。「呼べること」「呼んだら必ず人が来ること」「呼んだ人を責めないこと」が大事だと言われます。

　ハーネスで言えば、「AIが判断に迷ったら人に戻すこと」「人がいつでも止められること」「止まった理由が分かること」に当たります。

　ただし、自動車の工場とAIのソフトウェア工場では、アンドンの鳴る場所が違います。自動車の工場では、何が正常かが先に決まっています。寸法の規格があり、標準作業があります。だから、アンドンは主に不良や作業の遅れで鳴ります。AIのソフトウェア工場では、設計と製造、つまり開発の全体が、同じラインの上で同時に進みます。製品の設計は、作りながら決まっていきます。何が正常かを、先に全部決めておくことができません。そのため、アンドンは不良品よりも、設計が決まっていない場面で鳴ります。そのような場面で、人が呼ばれるべきです。

　私自身の承認の使い方も、これに沿っています。Claude Codeでコードを書かせていると、「シェルでこのコマンドを打っていいか」といった確認がよく来ます。社内で使うだけのもので、やろうとしていることにセキュリティなどの危険がないと分かっている操作は、ほぼオートモードで任せています。そこは何が正常かが決まっているので、止まる必要がありません。一方、どう設計するかという場面では、Claude Codeが具体的な選択肢を示して聞いてくることもあります。AIの側がアンドンを鳴らしている状態だと言えます。そこはしっかり考えますし、それは違うだろうと思えば、いったん止めて自分の考えをきちんと伝えます。ただ、AIはそのままだと、設計が決まっていなくても、自分で前提を置いて先に進んでしまうことがあります。そこで私は、Claude Codeなどのコーディングエージェントで使えるスキル集「Superpowers」の各モードを使い分けて、丁寧に設計するやり方をとっています。

　承認を求められ過ぎて疲れる、という話もよく聞きます。工場では、アンドンが鳴りっぱなしの工程は、作業者ではなく工程が悪いと考えるそうです。承認も同じで、押す人が悪いわけではありません。何が正常かを決められる操作は、テストやフックで自動で判定させるか、権限で最初から許可と禁止を決めておく。そうすれば、アンドンが鳴るのは、本当に人の判断が要る場面に絞られます。

　人の関わり方も、この見方で整理できます。操作の種類ごとに、人がどこにいるかを考えます。人の判断がないと先に進まないのが「ヒューマン・イン・ザ・ループ（in）」、普段は任せ、異常のときに介入するのが「オン・ザ・ループ（on）」、関与しないのが「アウト・オブ・ザ・ループ（out）」です。私の場合、シェル操作はoutに近く、設計の判断はinです。AIが設計の選択肢を聞いてきたら、自分で考えて答えないと先に進みません。

　もう一つ、ラインの責任を誰が持つかも決めておく必要があります。in、on、outにそろえて呼べば、「ヒューマン・オウン・ザ・ループ（own）」です。何を異常とするかを決め、止まった原因を潰して標準を直すのは誰か。トヨタでは改善はラインの全員でするものとされるので、責任者を一人決めれば済むわけでもありません。それでも、誰が責任を持つのかははっきりさせておきたいところです。

作業ごとに決めるRACI

　ハーネスエンジニアリングの解釈は人によってさまざまですが、私は次のように考えています。今のハーネスは、名前は同じでも、テストハーネスとは目的が違います。作ったものの品質を確かめるより、作業の最中にAIが踏み外さないようにするためのものです。トヨタの自働化のように、止まるべきところで止まり、人を呼びます。そして、AIのソフトウェア工場では、そのアンドンは不良品よりも、設計が決まっていない場面で鳴ります。

　何が正常かを決められるところは、仕組みで止めるようにしておきます。私自身、CLAUDE.mdに並んでいた「しないこと」を見直し、フックや権限といった仕組みに移せるものから移しています。

　もう一つ大事なのが、責任の置き方です。役割分担を表す「RACI」という枠組みは、アジャイルなどで知っている人も多いと思います。R（Responsible、実行責任）、A（Accountable、成果責任）、C（Consulted、相談先）、I（Informed、報告先）の4つです。

　AIエージェントについては、「RはAIに任せ、Aは人に残す」と大まかに決めるだけでは足りないと私は考えています。作業の内容ごとに、人とAIエージェントのどちらが「R「「A」「C」「I」を担うのかを、必要なら細かい粒度まで決めておく。チーム開発にAIエージェントを入れているなら、それぞれが具体的に誰なのかまで決めておく。ハーネスを考えるときは、そこまで考えていくことが大事だと思っています。