🐴

「ハーネスエンジニアリングやってます」と言いたくない理由

に公開
2

はじめに

トレンドの技術記事を眺めていると「ハーネスエンジニアリング」という言葉が目に飛び込んでくることが多くなってきました。ハーネスエンジニアリング…なんだかカッコいいスタイリッシュな響きで、綺羅星のように輝く新しい専門領域が誕生した感があります。

でも、中身を読んでいくうちに、ちょっと違和感。。。これ、自分が普段やっていることと何が違うんだろう。。

個人的にはハーネスエンジニアリングは、まやかしで実体のない曖昧で危うさを秘めた言葉だと思っています。

正確に言えばハーネスエンジニアリングでやっていること自体は大事なのですが、わざわざ新しい名前をつけて特別すごそうなものに見せる必要があるのか、という違和感がずっとあります。

ハーネスエンジニアリングって何なのか

ハーネスエンジニアリングとは、AIエージェントが自律的に高精度な成果物(コードなど)を生成・実装できるように、人間が周辺環境(ハーネス)を設計・整備する開発手法のことです。
そもそも「ハーネス」とは馬具のことで馬を制御して意図した方向に導くための道具です。
これをAIエージェントに当てはめて、エージェントが暴走せず正しく仕事をするための仕組みやガードレールを作ることを「ハーネスエンジニアリング」と呼んでいます。

https://mitchellh.com/writing/my-ai-adoption-journey#step-5-engineer-the-harness

具体的には、大きく4つの領域があります。

  • 1つ目は、ドキュメント整備。AGENTS.mdやCLAUDE.mdといったAI向けの指示書を書いて、プロジェクトのルールや設計思想をエージェントに伝えます。
  • 2つ目は、テスト・Linterの整備。エージェントが書いたコードが規約に沿っているか、バグがないかを機械的にチェックする仕組みです。
  • 3つ目は、環境構築。git worktreeで隔離された開発環境を用意したり、オブザーバビリティのスタックを整えたりして、エージェントが安全に作業できる場所を作ります。
  • 4つ目は、ツールのスキル化。スクリーンショットの取得やログの確認といった作業をエージェントが自分で実行できるようにツールとして提供します。

さらにOpenAIの事例では、エージェント同士にコードレビューをさせたり、AI生成コードの品質低下を自動検出する仕組みを運用したり、意思決定の記録をすべてリポジトリ内に残すといった手法も紹介されています。

https://openai.com/index/harness-engineering/

OpenAIのチームが5か月で約100万行のコードをエージェントだけで生成した、という事例が話題になりました。そこで実践されていた手法がハーネスエンジニアリングだと紹介されています。

聞くだけだと「すごい、未来のエンジニアリングだ」と感じて、自分も最初はそう思いました。

冷静に考えると、やっていることはシンプル

ところがどっこい、ひとつひとつの中身を見ていくと、かなり地味な作業と枯れた技術の集まりなのです。

たとえばAGENTS.mdの改善。これはつまり「AI用のドキュメントをちゃんと書きましょう」ということです。新しく入ったメンバーに「ここはこうしてね」と引き継ぎ資料を作るのと本質的に同じで、相手が人間からAIに変わっただけです。

テストやリンターの整備も同じで、これも昔からやっていることそのものです。CIでテストを回す、コーディング規約をリンターで強制する、駆け出しエンジニアでも研修で学ぶような基本中の基本。

シェルスクリプトでチェック処理を書くこともあります。自分も実際にやっています。AIエージェントが生成したコードに対して、特定のパターンが含まれていないかgrepで確認したり、ビルドが通るかチェックしたり、でもこれ、やっていることは昔ながらのシェルスクリプトです。たんなるbashです。何も新しくない。

料理で言うなら「レシピを書いて、味見をして、調味料の分量を計る」という作業に「キュリナリーエンジニアリング」と名前をつけているようなものです。やっていること自体は料理の基本なのに、急にカッコいい名前がつくと特別な技術に見えてしまい、なんだかそこに違和感。

名前がつくとすごそうに見える問題

湯婆婆「贅沢な名だね」

これは別にハーネスエンジニアリングに限った話ではありません。IT業界には昔からこの手の現象がありました。

たとえば「DevOps」という言葉が登場したとき、開発と運用の壁を壊すという理念は素晴らしかったのですが、実態としてはインフラを触れるエンジニアが既にやっていたことに名前がついただけ、という側面もあったを記憶しています。あるいは「フルスタックエンジニア」という肩書きも、昔は「何でも屋」と呼ばれていた人たちがカッコいい名前をもらっただけだったりします。

名前がつくこと自体が悪いとは思いません。概念に名前がつけば議論しやすくなりますし、共通言語としての価値はあります。ただ、名前の重力に引っ張られて「自分は最先端の技術をやっている」と錯覚するのは危ういと感じるのです。

自分がやっていることは当たり前のこと

自分は日常的にClaude Codeを使って開発をしています。AIエージェントにコードを書かせて、その出力をレビューして、問題があれば修正する。この流れの中で、確かにハーネスエンジニアリングと呼ばれるようなことはやっています。

CLAUDE.mdにプロジェクトのルールを書いています。テストコードを整備して、エージェントが変なコードを出したら検知できるようにしています。シェルスクリプトでビルドチェックも自動化しています。

でも、これを「ハーネスエンジニアリングやってます」とは言いたくないのです。

なぜかというと、自分がやっているのは当たり前のことを当たり前にやっているだけだからです。ドキュメントを書き、テストを書き、自動化する、エンジニアとして基本的なことをAIという新しい道具に対しても同じようにやっているだけです。

これに特別な名前をつけて「新しい専門領域です」と言ってしまうと、まだAIエージェントを使ったことがない人に対して不必要なハードルを作ってしまうのではないかと心配ですし、実態以上に期待値を高めてしまうことを危惧しています。

自分のことをフルスタックエンジニアですとは、言いにくい問題と似ている

また、私は、普段フロントエンドもバックエンドのコードも触っていますが、自分のことを「フルスタックエンジニアです」と言ったことはこれまでないです。

なんでかというと、「フルスタックエンジニアです」と言った瞬間に、何でもできるスーパーマンみたいに誤解されると困るからです。なんでもはできないわよ、できることだけしかできないのです。

あと「この程度の技術しかないのにフルスタックエンジニア名乗ってる。。。ププ」と自分の中のリトルkaramageが自分で自分の実力を過小評価してる面もあると思います。

「ハーネスエンジニアリングやってます」が生む誤解

試しに想像してみてください。勉強会や懇親会で「最近どんなことやってるんですか?」と聞かれて「ハーネスエンジニアリングやってます」と答えたとします。相手の反応はおそらく「おぉ、なんかすごそうですね」でしょう。そしてそこで会話が止まる。なぜなら、相手は何がすごいのかよくわからないけれど、なんとなく高度なことをやっているんだろうと思い込んでしまうからです。

これが厄介で、実際にやっていることは「CLAUDE.mdにルールを書いて、シェルスクリプトでgrepして、テストを回している」だけなのに、言葉の響きが実態以上の期待値を作ってしまう。 すごそうに聞こえるぶん、聞いた側は「なんか凄そう」「この人は技術力が高い人だ」「自分にはまだ早い」と感じてしまうかもしれません。

本当はその逆。実際にはAIを使っているほとんどのエンジニアの人は何かしらのハーネスエンジニアリングに近いことをすでに行っているんですよ。CLAUDE.mdを書くのは普通のMarkdownファイルを書くのと同じですし、シェルスクリプトでチェックを回すのも数十行のbashで済む話。テストを書くのだって、これまでやってきたことの延長線上にあります。ハーネスエンジニアリングという言葉が持つ「専門家感」が、本来誰でも始められるはずの作業に見えない壁を作ってしまっている。 自分はそこが一番もったいないと感じています。

「すごいことやってますね」と言われたとき、正直に「いや、bashとMarkdown書いてるだけですよ」と返せるかどうか、そこに誠実さがあると思うのです。

大事なのは名前ではなく中身

誤解しないでほしいのですが、ハーネスエンジニアリングで紹介されている個々の手法には価値があります。テストを充実させること、ドキュメントを整備すること、アーキテクチャを強制する仕組みを作ること。これらはAIエージェント時代において今まで以上に重要になるのは間違いありません。

AIは指示が曖昧だと好き勝手にコードを書きます。人間の新人エンジニアなら「ちょっと待って、これでいいんですか」と聞いてくれますが、AIは自信満々にバグを仕込んできます。だからこそガードレールが必要でそこに異論はありません。

ただ、そのガードレールを作る行為に「ハーネスエンジニアリング」という大層な名前をつけて、あたかも新しい高度な専門職が生まれたかのように語るのは、ちょっと大げさではないでしょうか。

まとめ

自分はこれからも、CLAUDE.mdを書いて、テストを整備して、シェルスクリプトでチェック処理を回し続けます。やっていることは変わりません。ただ、それを「ハーネスエンジニアリング」とは呼ぶのはためらいます。なんだかそう言った瞬間むず痒く感じてしまうからです。この感覚、私だけでしょうか?

「AIエージェントにちゃんと仕事をさせるために、当たり前のことを当たり前にやっている」

それでいいしカッコいい名前がなくても、地味な作業の積み重ねがプロダクトの品質を守る。
エンジニアリングって、もともとそういう地味なものだったはずです。

追記

ここまで書いてきてなんですが、もしかすると数カ月後には自分も普通に「ハーネスエンジニアリング」と口にしているかもしれないと思いなおしました。DevOpsもフルスタックも、最初は違和感があったはずなのに、いつの間にか当たり前の言葉になりました。言葉というのはそういうもので、使われ続けるうちに中身が追いついてきてだんだん違和感が消えていき、そのときに「昔あんな記事書いたなぁ」と恥ずかしくなるのかもしれません。
でも、今この瞬間の正直な感覚は残しておきたいので、ここに書き記して起きます。m(_ _)m

Discussion

dukeduke

他人とそのテーマで話をしたいかどうかなんじゃないかと。
1人で作業しようが複数人で作業しようがaiに作業させようが原理原則は変わらないという話題があったとして、aiに上手に作業させるのにどうするかが主題なら一言でコンテキストを明示できる単語は欲しいだろうし、興味がない話題をミュートしたい人にも便利です

karamagekaramage

コメントありがとうございます。おっしゃる通りだと思います。
「ハーネスエンジニアリング」という一言で「ああ、AIエージェントの制御周りの話ね」と伝わるのは、コミュニケーションのコストを下げるという意味で確かに便利ですよね。興味がある人は深掘りできるし、興味がない人はスルーできますし、共通言語としての実用的な価値は自分も否定できません。

自分が引っかかっているのは、その便利さの裏側で「なんかすごそう」という空気感だけが一人歩きしてしまうことへの心配なんだと思います。言葉があること自体は良いことで、ただその言葉に必要以上の重みや広い曖昧なものが混ぜこぜにが乗ってしまうことへの危惧でした。

「名前が要るかどうか」というより「名前の重さや広さが実態と合っているか」が気になっている、というのが正確なところかもしれません。視点の整理になりました、ありがとうございます。