Perl を作った Larry Wall が挙げたプログラマの三大美徳、そして書籍『Team Geek』のHRT。どちらも古典で、今さら解説する記事でもありません。
- 怠惰 (Laziness) / 短気 (Impatience) / 傲慢 (Hubris)
- 謙虚 (Humility) / 尊敬 (Respect) / 信頼 (Trust)
前者は「プログラムに対する姿勢」・後者は「人に対する姿勢」…と整理されるのが定番です。
…で、最近ふと思ったのです。あれ？ この2つって、AI駆動開発になってからのほうが効いてるのでは？…と。
AIのためのフレームワークを作った話を何度か書きましたが、あれを作っている間ずっとやっていた事は、後から名前を知った Harness Engineering や Loop Engineering と呼ばれる手法でした。
そしてその中身は、三大美徳とHRTでほぼ説明が付いてしまう…そんなお話です。
Harness Engineering ＝ 怠惰・短気・傲慢
まずは、Harness Engineering（ハーネスエンジニアリング）から。
HashiCorp 創業者の Mitchell Hashimoto 氏が、2026年2月5日のブログ記事 My AI Adoption Journey の「Step 5: Engineer the Harness」で挙げた言葉です。
the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again
雑に訳すと、「エージェントが間違えたら、二度とその間違いができないように『仕組み』を作る」こと。
これは、Sessionクラスの記事で「老舗鰻屋の秘伝のタレ」と書いていたやつです。AIがバグを出す度に原因を討論し、Coreの設計が悪いならCoreを直し、◯◯.md 等に反映させ…を延々と繰り返す。名前が付いてるとは知らずにやってました。
面白いのは、この手法の動機が、三大美徳そのままだという事です。
怠惰 ＝ 同じ指摘を二度したくない
Hashimoto 氏が挙げている実装形態の1つが、AGENTS.md のようなファイルに1行ずつルールを足していく方式です。エージェントが同じミスを踏む度に1行増える。
これに対し、勤勉な人は、AIが間違える度に律儀に指摘して直させます。それで動くので。
一方で怠惰な人は、「またこれ言うのかよ…」で耐えられなくなり、指摘そのものを消しにいく。◯◯.md が育つのは、勤勉だからではなく、同じ説明を3回するのが面倒くさいからですし、面倒くさいからこそAI自身に ◯◯.md を書かせます。
短気 ＝ 人間の目視レビューが我慢ならない
AIの生成物「全て」を、毎回人間が読んでレビューする…というのは、短気な人間には無理です。開発速度が出なくてイライラするので(笑)
ですので、例えば Lattice では、フレームワークの規約違反を自動チェックする静的テストを入れてあり、違反があれば修正方法を提示しつつ人間が読む前に落とします。
Hashimoto 氏の言う harness のもう1つの形態が、「スクリプト等のツールを用意して、その存在をドキュメントでエージェントに教える」…ですが、まさにこれです。
傲慢 ＝ AIが書いたコードでも、出す以上は自分の名前
私はここ2,3ヶ月ほど、コードをほぼ書いていません。
しかし、納品物の品質責任は、当然ながら100%自分にあります。
「AIが書いたので」は、言い訳になりません。傲慢な人間は、AI製だろうが自分の名前で出るものが批判されるのが我慢ならないので、結果としてハーネスの品質が上がります。
三大美徳が「プログラムに対する姿勢」だとすると、AI駆動開発においてプログラムの位置にあるのはハーネスのほうです。アプリのコードはAIが書きますので。
Loop Engineering ＝ 検証を人間の気分から外す
もう1つの新語が、Loop Engineering（ループエンジニアリング）です。
2026年6月7日に、OpenClaw の作者 Peter Steinberger 氏が、「もはやスキルはコーディングエージェントにプロンプトを書く事ではなく、エージェントにプロンプトを書くループを設計する事だ」…という趣旨のポストをして広まりました。
ほぼ同時期に、Claude Code を率いる Anthropic の Boris Cherny 氏も、「もう Claude にプロンプトを書いていない。Claude にプロンプトを出して次に何をするか判断させるループを走らせている。私の仕事はループを書く事だ」…と語っており、この流れに Google の Addy Osmani 氏が Loop Engineering という名前と型を与えた…という経緯です。
要するに、「目標 → コード調査 → 変更 → 検証実行 → 結果を読む → 次を決める」を回し切らせるという話です。元をたどれば ReAct（Reason + Act）で、目新しい発明ではありません。
ハーネスとの関係は、私はこう捉えています。
- ハーネス ＝ AIが迷わず、間違えようがないレールを敷く（事前）
- ループ ＝ それでも出た間違いを、人間を経由せずとも検出して戻す（事後）
私の場合なら、例えばClaude Code を司令塔・Antigravity CLI を実装役にした協業環境がまさにこれです。Claude が設計と検証、Gemini が生成、そして先述の静的検査テストが規約違反を落とし、実機テストまでAIが行う。これらが繋がっていれば、私が画面を見ていなくてもループは回り続けます。
この2つが揃うと何が起きるか？ 「AIを信用する」が、精神論ではなく設計の話になります。
HRTの宛先は、もはや人間の同僚ではない
ここからが本題です。
『Team Geek』のHRTは、「人に対する姿勢」として紹介されたものです。
ところが今、私のチームメイトはAIで、1人＋AIという体制については人月の神話の記事でも書いたとおりです。
つまり、**HRTを向ける相手そのものが、人間ではなくなっています。**三大美徳の対象がアプリのコードからハーネスへ移ったのと同じ事が、HRT側でも起きているわけです。
謙虚 (Humility) ＝ AIが間違えたら、まずは自分の設計を疑う
これが一番効きます。
例えば、Sessionクラスの記事に載せた、実際のやり取りがこれです。
- ぼく：
Latticeが、あなた（AI）にとって使いやすいか？あなたがバグを出さないか？という「AIフレンドリーさ」を徹底的に追求して作ったものなのは、あなたも分かってるよね？ あなたを責める気はないので、今回のバグが出た原因を正直に教えて。 - Claude様：大変申し訳ございません！
SKILL.mdには◯◯と書いてあるのに、見落としてました！(意訳) - ぼく：大変申し訳ございません！それは私の設計が悪いんでございます！どうすれば改善されるか案をお出しくだされ！！(懇願)
茶化して書いていますが、やっている事は真面目です。AIのミスを「AIが馬鹿だから」で片付けた瞬間、ハーネスは1ミリも育ちません。
「自分が常に正しいと思わないこと」というHRTの謙虚は、AI相手でこそ実利があります。原因をAIのせいにする道を自分で塞ぐと、改善が必ず環境側に落ちるからです。
Validatorクラスの記事でも同じ結論に着地しました。私が「違う！美しくない！」と叫んでいた原因は、Claudeが間違えたからではなく、当時の私の設計が「柔軟性という名の曖昧さ」を許容していたからでした。
尊敬 (Respect) ＝ 提案を、検討に値するものとして扱う
『Team Geek』の尊敬は「一緒に働く人の能力や功績を高く評価すること」ですが、AI相手だとこれは**「AIが出した案を、却下する時も理由を添えて返す」**という形になります。
「却下」とだけ返すのと、「却下。その案だと◯◯のケースで破綻するから」と返すのとでは、次に返ってくる案の質が露骨に変わります。理由を返す ＝ 判断基準をコンテキストに足しているのと同じですので、これはある意味当たり前です。
そして、同じ理由を3回返したら、それはもう ◯◯.md に書くべきルールです。尊敬を払った回数だけ、ハーネスの材料が貯まっていく。
ここは、三大美徳の「傲慢」とちょうど裏表になっています。自分の設計が批判されるのは我慢ならない（傲慢）、しかしAIの提案は検討に値するものとして扱う（尊敬）。矛盾しているようですが、両方あるとハーネスの改善速度が上がります。
信頼 (Trust) ＝ 仕組みの上で任せる
『Team Geek』の定義はこうです。
自分以外の人は有能であり、正しいことをすると信じること
これをAIに適用すると、途端に反発が来ます。「AIを信頼するなんて危険だ」と。
でもね。そもそも「信頼」を無条件の意味で使っていた人が、どれだけいますか？
信頼している同僚が相手でも、我々はコードレビューを通しますし、CIも回します。それで「お前を信頼していない」とは誰も言いません。信頼とは、検証の仕組みが乗った上で成立するものであって、検証を省く事とイコールではありません。
AI相手でも、話は変わりません。
ハーネスとループを用意した上でAIを信頼するのは、CIを回した上で同僚を信頼するのと、同じ構造です。
逆に、ハーネスも検証も無い状態で出力をそのまま通すのは、信頼ではなく盲信です。これはバイブコーディングの記事で書いた「(笑) は品質ではなく詐称に対して付く」という話と、同じ一線の話です。
「信頼」と「盲信」とを明確に分けるものは何か？ それは、AIへの態度ではなく、その手前に「仕組み」があるかどうかだけだと思います。
「AIはまともなコードを書けない」と言う人へ
AIの生成物にダメ出しをする人の指摘内容は、大抵の場合そのとおりです。
規約は守らないし、既存の実装を無視して車輪を再発明するし、テストは通るのに要件を満たしていない。私も散々見てきましたので、それが嘘だとは思っていません。
その上で言いますが、それは、AIの問題ではなく、仕組みが育ってないだけです。
- 規約を守らない → 規約が
◯◯.mdに書かれておらず、破っても自動テストが落とさないから - 車輪の再発明 → SSOTや既存実装の場所をAIが知る手段が無いから
- 要件を満たさない → 要件がドキュメントや自動テストとして表現されていないから
どれも、指示の出し方ではなく仕組みの設計の問題です。Hashimoto 氏の定義「二度とその間違いができないように『仕組み』を作る」そのままの話。
私は以前これを、F1マシンを一般道で走らせているようなものだと表現しました。走れはしますが、信号で止まり、速度制限を守り、合流で迷う。その度にバグが生まれる。遅いのはマシンのせいではありません。
そして、道を敷かずに文句だけ言い続ける状態というのは、HRTで言えば謙虚の欠如、三大美徳で言えば怠惰の欠如です。同じ不満を100回言えるのは、勤勉だからこそだと思います。
結論
- 三大美徳（怠惰・短気・傲慢）は、
Harness Engineeringの動機そのもの。対象がアプリのコードから、AIが走る環境に移っただけ。 - HRT（謙虚・尊敬・信頼）の宛先は、同僚からAIへ移った。謙虚が無いとハーネスは育たず、尊敬を払った回数だけ材料が貯まる。
- **信頼は盲信ではない。**人間相手のCIと同じで、検証の仕組みが乗って初めて信頼になる。ハーネスとループがその仕組み。
40年近く前の美徳と、10年以上前のHRTが、2026年に生まれた新語をきれいに説明してしまう。
結局のところ、道具が変わっただけで、プロの条件は昔から1つも変わっていないという事なのだと思います。