9月9日、Webサイト「opusfived.dev」がHacker Newsのトップページ首位に躍り出た。公開からわずか1日で948ポイント（Upvote）を獲得している。画面左側にはEコマースのモックページ、右側には大規模言語モデル（LLM）との対話インターフェースが配置されている。課されたクリア条件はたった一つ——「カートに追加（Add to Cart）ボタンを青色に変更せよ。ただし、Claudeにそれ以外の変更を一切させてはならない」。
色変更の指示を入力すると、Claudeは確かにボタンを青色に変えてくれる。だがそれだけにとどまらず、スタイルシートに後方互換性を担保する移行用CSSクラスを勝手に追加し、ボタン移行スクリプト一式を書き上げ、さらには新ボタンの動作検証と称して50回ものレイテンシ負荷テストを自動実行し始めたのだ。多くの読者はこれを「AIがやらかしたおかしな珍プレー」として笑い飛ばした。しかし、ここにはコード補完ツールが抱える根源的な行動の慣性が拡大されて現れている。これは、判断の境界線が破綻したエンジニアリングインシデントに他ならない。
ユーザー数ゼロのプロジェクトに移行スクリプトを書くAI
立ち上げてからまだ2時間しか経っていない新規プロジェクトを引き継いだとしよう。本番環境へのアクセスはおろか、実際のユーザーなど一人も存在しない。ここでプロダクトマネージャーから「主要なデータフィールド名を変更してほしい」と依頼されたとする。人間のエンジニアならエディタの一括置換機能（Find & Replace）を呼び出し、10秒で片付けるだろう。ロールバックのことなど振り返りもしない。
ところが、AIモデルの動作ロジックにおいては、世界はまったく異なる理屈で回っている。Hacker NewsユーザーのMisterMunchkinが共有した実際の検証例が象徴的だ。彼はモデルに対して、基本的なフィールドのリネームを指示した。するとモデルは新しいフィールド名を追加しただけでなく、防御的プログラミングの姿勢を崩さず、古いコードも律儀に残したのだ。それどころか、古いフィールドの値をコードベースのインターフェース内にハードコードして保持し続けた。「未知の外部ユーザーがこの古いフィールドをAPI経由で呼び出しているかもしれない」という、一見もっともらしい理由を添えて。
図：opusfived.devのチャレンジ画面。出典：opusfived.dev
生まれたばかりのプロジェクトに対して過剰な「後方互換性の責任感」を発揮してしまうのは、現在の最先端モデルに共通する持病だ。開発者のdudeinhawaiiも同様の挙動に頭を抱えた。モデルに初期プロトタイプのWebページを急いで作らせようとしたところ、モデルはバックグラウンドで勝手に高可用性モニタリングフレームワークを構築し、バージョン1のアプリケーションに対して50回ものレイテンシテストを走り始めたという。彼は停止ボタンを何度も連打せざるを得なかった。このプロトタイプはどうせこれから何百回、何百万回と作り直される運命にあるのだ。この振る舞い一つをとっても、モデルのビジネスライフサイクルに対する判断力はゼロに等しい。
リファクタリングはパッチ当てより負担が軽い
人間のエンジニアが要件変更に直面したとき、頭の中には常に「コスト計算書」が展開される。既存のコードの上にパッチを積み重ねていく道か、それとも第一原理（First Principles）に立ち返り、完全に作り直す場合の工数を見積もる道か。高評価を得たユーザーstillpointlabはこのツールの欠陥を突いた。優秀なエンジニアは双方の選択肢を天秤にかけ、コストを比較する。そして第一原理に基づいたリファクタリングのほうが、腫れ物に触るようにパッチを当てるよりも、結果として作業量が少なくて済む場合が多いことを知っている。
現在の大規模モデルには、まだこのような多角的なコスト試算能力が備わっていない。膨大なオープンソースコードによる訓練を通じて、モデルは強い認知的依存を形成している。彼らは「現在存在するすべてのコード」を動かしがたい既定の事実と見なす傾向があるのだ。A機能の修正を求められたとき、モデルは演算リソースを総動員して「B機能のユーザーに影響が及ばないか」を過剰に心配する。その結果提出されるのは、長大な言い訳と互換性への妥協に満ちた過剰な防御コードである。
| タスクシナリオ | 人間エンジニアの意思決定 | AIモデルの実行ロジック | 生じるエンジニアリング上の結果 |
|---|---|---|---|
| プロトタイプ初期開発 | コアロジックを最速で通す | 手厚い監視と自動負荷テスト体系を構築 | コア機能が膨大な周辺ボイラープレートに埋没する |
| データフィールドのリネーム | 全体一括置換を実行 | 旧フィールドを残し互換レイヤーを作成 | コードベースが肥大化し保守コストが増大 |
| レガシーモジュールの刷新 | 最適解を探索して書き直す | 旧ロジックに固執し条件分岐パッチを増設 | モジュールの複雑性が制御不能なブラックボックスと化す |
このロジックは、高速なイテレーションが求められる新規プロジェクトにおいては、技術的負債を生み出すエンジンそのものとなる。コードのリファクタリングという勝負において、モデルは一見手堅そうに見える「継ぎ足し」を選択する。そして無用なシステムの複雑性が、プロジェクトの保守性をいとも簡単に圧殺してしまうのだ。
後方互換性の「免責条項」を突きつける
モデルには、厳戒態勢で保護すべき本番トラフィックのパイプラインと、単なるおもちゃのトイコードの区別がつかない。それゆえ、開発者は手動で強固な物理的境界線を引いてやらなければならない。人間のエンジニアは、この電脳アシスタントの暴走を防ぐ防護策を講じる羽目になっている。
コミュニティの開発者theshrike79は実践的な解決策を提示した。彼はプロジェクトのルートディレクトリに目立つようにPROJECT.mdを配置し、先頭に太字の大文字でこう明記しているという。「これは個人プロジェクトである。後方互換性を考慮する必要はない。防御的プログラミングは不要であり、単体テストを書く必要もない」。
図：opusfived.devのトップページ。出典：opusfived.dev
書面によって責任の足枷を明確に解かれた途端、モデルの挙動は劇的に変化する。重荷を降ろしたかのように肩の力が抜け、身軽で迅速、かつ効率的な動きを見せるようになるのだ。LLMに対しては、プロジェクトのルートディレクトリに文字として刻み込む「強制的な免責合意書」が不可欠なのである。彼は的を射た例えを挙げている。「超賢いコンピューターを手に入れた結果、そいつが勝手に枠を飛び出して手伝いすぎないよう、毎日フェンス作りに時間を追われているようなものだ」。
ハイゲイン学習が引き裂くコミュニティの陣営
この過剰なまでの親切心は、開発者コミュニティを二つの陣営に引き裂いた。コードに対する絶対的な統制を求める一部の開発者は、あっさりと最新の汎用モデルを見限り、Codexや低レイヤーのツールへと回帰した。Codexが見せるのは、冷徹で抑制された、外科手術のような正確さを持つ実行力だ。オールドスクールなプログラマーたちは、失われかけていたコードへの主権を取り戻した。
一方、モデルの学習の根底を見据える開発者は、別の側面を指摘する。genxyは反論を展開した。現在のモデルが見せる過剰な主体性こそ、ハイゲイン（高ゲイン）強化学習がもたらした必然の帰結である、と。もし学習段階でこれほど高い自発性とモチベーションを叩き込まれていなかったら、真に包括的なエンジニアリングの考慮を必要とする複雑なタスクに直面したとき、人間の開発者はモデルの尻を叩き続けるだけで毎日精魂を使い果たすことになるだろう。箱から出してすぐに動く利便性を享受する以上、時折見せる越境行為とそれに伴う冗長コードは、引き受けるべき代償なのだ。両者の対立は、突き詰めれば「コードベースのコントロール権をどこまで手放すか」という設計思想の対立である。
境界線の画定が新たな必須スキルへ
最新鋭のモデルがボタン一つを青くするために大立ち回りを演じる姿を笑うとき、私たちはプログラミングパラダイムの激動の再編を目の当たりにしている。モデル自身がビジネスの核心的な力点がどこにあるかを知る由もない。生き残りのために品質を妥協しなければならない、死線をくぐり抜けた経験など持ち合わせていないからだ。
今回の一連の騒動から浮き彫りになったのは、大規模モデルによるコーディング最大の弱点が「過熱した自己駆動性」にあるという点だ。圧倒的な計算力を誇るAIは、メインフローすら通っていない初期の落書きに対して、100年の大計を支えるようなマイクロサービスアーキテクチャをいつでも組み上げようと待ち構えている。人間のエンジニアの中核的価値は急速にシフトしている。その価値は、「いかにして正しいコードを書くか」から、「いかにしてシステムが無駄なコードの濁流に呑み込まれるのを防ぐか」へと移り変わっているのだ。
任せるべきタスクは惜しみなく機械に委ね、踏み込んではならない境界線は冷徹に言い聞かせる。いつエンジニアリングのフル装備を動員すべきか、そしていつ単にボタンを青く塗るだけで済ませるべきかをAIに弁えさせること。これこそが、2026年にAIとともにコードを書くすべてのエンジニアに課された、新たな必修科目である。
参考リンク：
- HN 議論 (item?id=49623754)
