はじめに：なぜ、あるライブラリ作者の個人エッセイが注目されているのか
ChatGPTやClaude、GitHub Copilotといった生成AIをコーディングに使うことは、もはやエンジニアだけの話ではなくなりつつあります。管理職や個人事業主の方でも、「AIにコードを書かせれば開発が速くなる」という言葉を耳にする機会は増えているのではないでしょうか。
その一方で、「AIに任せきりにして大丈夫なのか」という不安の声も根強くあります。この問いに、実務に基づいた形で答えているのが、軽量JavaScriptライブラリ「htmx」の作者であるCarson Gross氏です。同氏は2026年に入ってから、AIコーディングエージェントとの向き合い方について複数のエッセイを自身のサイトで公開し、開発者コミュニティで大きな反響を呼んでいます。
本記事では、Gross氏の一連の主張と、実際に彼が体験した具体的なバグ修正のエピソードを紹介しながら、AIエージェントを業務に取り入れる際に押さえておきたい考え方を整理します。専門的なコードの話も出てきますが、エンジニアでない方にも「AI活用の勘所」として読んでいただける内容です。
htmxとCarson Gross氏について
htmxは、JavaScriptをほとんど書かずにHTMLの属性だけでAjax通信や画面の部分更新を実現できるライブラリです。「JavaScript疲れ」と呼ばれる、フロントエンド開発の複雑化に対するアンチテーゼとして支持を集め、GitHub上のスター数は約4万9000に達しています。作者のCarson Gross氏はモンタナ州立大学でコンピューターサイエンスを教える教育者でもあり、技術的な主張だけでなく、AIが与える教育・キャリアへの影響についても積極的に発信しています。
「コードは安くなった、理解することが高くついている」
Gross氏は2026年6月4日に公開したエッセイ「Code is Cheap(er)」の中で、AIによってコードを大量かつ高速に生成できるようになったことを認めた上で、次のように主張しています。
「わかる」ことの価値が急上昇している
コードが人間の手から一行ずつ生まれていた時代は、コードを書く過程そのものが「理解」を伴っていました。しかしAIが一気に大量のコードを生成すると、そこには最初から「理解」が存在しません。理解が必要ならば、コードが書かれた後で改めて読み解く作業が発生します。Gross氏は、「コンパイラの出力を人間が逐一理解してないとが同じだ」という楽観論に対して、コンパイラは決定論的であり生成物の範囲も機械語に限定されるのに対し、LLM（大規模言語モデル）は非決定論的で汎用的なソフトウェアを出力する点が本質的に異なると反論しています。
「引き算のエンジニア」という発想
この状況への処方箋として提案されているのが、「Subtractive, Constraining Engineer（引き算をする、抑制的なエンジニア）」という考え方です。これは、AIが出したコードを鵜呑みにせず、内容を精査、」要な複雑さを削ぎ落とし、時には「ノー」を言う役割を担うエンジニア像を指します。作る量ではなく、取り除いた量、あるいは「入れさせなかった」量に誇りを持つという発想であり、Gross氏はこれを「建築家というより彫刻家」に近いと表現しています。複雑さは放置すればシステムの規模に応じて幾何級数的、時には指数関数的に増大していくというのが同氏の持論であり、AIは複雑さを恐れずに大量のコードを生み出せてしまう分、この抑制役の重要性は増していると指摘しています。
「魔法使いの弟子」の罠
Gross氏はディズニー映画「ファンタジア」に登場する「魔法使いの弟子」のエピソードをたびたび引き合いに出します。ほうきに掃除を任せた弟子が、やがて制御不能な事態を招くように、AIに任せきりで内容を理解しないまま開発を進めると、いずれ手に負えない複雑さを抱え込むことになるという警鐘です。魔法使いになるべきであって、弟子になってはいけない、というのが同氏の一貫したメッセージです。
実例で見る、AIエージェントとの協働作業
理論だけでなく、Gross氏は2026年6月29日公開のエッセイで、自身が保守する別のプロジェクト「hyperscript」で実際に起きたバグ修正のやり取りを詳細に公開しています。抽象論ではなく具体的な事例である点が、この記事群の説得力を高めています。
バグの発生と原因調査
あるバージョンアップで、特定の構文（fetchコマンドにas JSONを組み合わせる書き方）が正しく解釈されなくなるという不具合が報告されました。Gross氏はまず、AIコーディングツールのClaudeに原因調査を依頼します。Claudeは数分で、直近のリファクタリングによって文法の範囲が意図せず拡大してしまったことを突き止めました。Gross氏自身も「一人で調べるより大幅に速かった」と、この調査フェーズでのAI活用を高く評価しています。
3つの修正案と、それぞれへの評価
一方、修正案の提示ではAIの弱点が浮き彫りになりました。最初の提案は目の前のバグだけを場当たり的に直す「ハック」で、汎用性に欠けるとして却下されました。2つ目の提案は動作こそしますが、パーサーに新しい状態管理用のフラグを追加する必要があり、不要な複雑さを持ち込むものでした。Gross氏はここで、既存のコードベースに「follows」という仕組みがす��存在することに気づき、それを使えば新しいフラグを足さずに解決できると指摘します。Claudeはこの指摘に従って3つ目の修正案を提示しましたが、これは対象範囲が広すぎ、本来影響を受けるべきでない別のコマンドにまで副作用が及ぶものでした。
最終的には人間が手を動かした
結局、Gross氏は自分の手で、影響範囲をfetchコマンドに限定した最終的な修正コードを書き上げました。その上で、テストコードの生成は改めてClaudeに依頼し、既存のテストスイートに沿った的確なテストが得られたと評価しています。この一連の流れからGross氏が導き出した教訓は、「AIは調査とテスト生成では強いが、既存の設計思想に沿った“きれいな”解決策を出すのは苦手」というものです。そして、その弱点を補えるかどうかは、コードベースを理解している人間がループの中にいるかどうかにかかっていると結論づけています。
htmx 4.0にも表れる「シンプルさへのこだわり」
Gross氏のこうした思想は、htmx自体の開発方針にも反映されています。2025年11月に発表され、2026年に入ってからアルファ版・ベータ版の開発が進んでいる「htmx 4.0」では、通信処理の基盤を古いXMLHttpRequestから現代的なfetch() APIへと全面的に置き換える作業が進められています。
主な変更点
具体的には、属性の継承をこれまでの暗黙的な挙動から明示的な指定に変更すること、画面遷移の履歴をローカルにキャッシュせずサーバーへ再度リクエストする方式に切り替えること、ストリーミング応答やDOMのモーフィング（差分更新）をコア機能として取り込むことなどが予定されています。これらはいずれも、機能を増やすというよりも、内部の複雑さと利用者が直面する「クセ」を減らす方向の変更であり、Gross氏がエッセイで語る「引き算」の哲学と一致しています。なお、htmx 2.0系は今後も無期限にサポートされる予定で、4.0への移行を急ぐ必要はないとされています。
ビジネスパーソン・管理職にとっての示唆
エンジニアではない読者にとっても、この一連の議論には実務上のヒントがあります。第一に、AIエージェントの導入を検討する際は「AIに何を任せ、何を任せないか」の線引きを意識することが重要です。Gross氏自身、原因調査やテスト生成にはAIを積極的に使う一方、システムの設計思想に閝わる判断は自分で下すと明言しています。これは、業務でAIエージェントを導入するチームにおいても応用できる考え方です。
第二に、若手・新人の育成方針への示唆です。Gross氏は大学教員としての立場から、「AIにコードを書かせず、まず自分で書かせるべきだ」と学生に伝えていると述べています。スピード重視でAIに丸投げする文化が広がれば短期的な生産性は上がるように見えても、複雑さの制御に失敗するリスクが高まるというのが同氏の見立てです。管理職の立場では、目先の速度だけでなく、チームが生成物を「理解」できているかどうかを評価軸に加える発想が参考になります。
AIを「TA（助手）」として使うという発想
Gross氏はもう一つ興味深い提案をしています。それは、AIをコードの生成係としてではなく、優れた「TA（ティーチングアシスタント）」として使うという発想です。同氏は自身の授業で、コーディングエージェントが生徒の代わりにコードを書いてしまうのではなく、概念の理解や技術選定の相談相手として振る舞うよう設定した指示ファイル（AGENTS.md）を公開し、学生に配布しています。この考え方は教育現場に限らず、企業研修やOJTの場でも応用が可能です。新人にいきなり完成したコードを渡すのではなく、AIとの対話を通じて「なぜそう実装するのか」を理解させる運用ルールを設けることで、育成とスピードを両立できる可能性があります。
年齢を重ねた開発者にとってのAI
Gross氏は50歳を迎えた自身の経験にも触れ、記憶力や長時間労働への耐性が落ちてきた開発者にとって、AIが「知識を素早く思い出す助け」と「粘り強くテストを書き続ける体力の代替」という二つの役割を果たしてくれると述べています。一方で、AI依存が思考力の衰えを加速させる懸念も率直に認めており、恩恵とリスクの両方を冷静に見いめる姿勢は、年齢やキャリアを問わず参考になる視点です。
まとめ
htmxの作者Carson Gross氏が2026年を通じて発信してきた一連のエッセイは、生成AI・AIエージェントの活用が「使うか使わないか」の二択ではなく、「どこまで、どう任せるか」という設計の問題であることを、具体的な開発事例を通じて示しています。原因調査やテスト生成といった得意領域ではAIを積極的に活用しつつ、設計判断という要の部分では人間が責任を持って理解し、必要なら「ノー」と言う。この「引き算のエンジニア」という姿勢は、コードを書かないビジネスパーソンや管理職がAIエージェントを業務に取り入れる際にも、そのまま応用できる普遍的な考え方だと言えるでしょう。
