GitHubで148スターを集めた「HERO-Anti-OverDefense」は、Hashing・Edge cases・Rubrics・Overbuildという4つの過剰防衛パターンをコーディングAIに禁じる貼り付け型の契約書だ。開発者の共感を集めた一方で、私はこの流れを手放しで称賛する気にはなれない。むしろ、AIコード品質論の底の浅さを露呈した事件だと見ている。
何が起きたか
Hugging Face出身の開発者wanshuiyin氏が公開した「HERO-Anti-OverDefense」が、GitHubトレンドで148スターを獲得した。HEROはHashing、Edge cases、Rubrics、Overbuildの頭文字で、コーディングAIがやりがちな4種類の「過剰防衛」を封じるための貼り付け型プロンプト契約書だ。Claude CodeやCursorといった主要コーディングエージェントに貼るだけで、無意味なハッシュ検証、想定しすぎたedge cases処理、勝手に増えるルーブリック評価、過剰な抽象化を抑制できるという触れ込みである。背景には「AIに任せると生成コードが数倍に膨らむ」という現場の疲弊がある。ナレーションは経営者向けに、保守コスト増加、社内品質の統一、コード標準化という3点を要点として整理していた。数字としては148スターに過ぎないが、話題性は明らかに数字以上に走っている。
なぜこのニュースが重要か
重要なのは、これが「AIが書いたコードは信用できない」という不信の可視化だからだ。2024年以降、コーディングエージェント市場は「書ける量」「速度」ばかりを競ってきた。しかし現場のエンジニアは、AIが吐き出す守りすぎのコード、つまり起こりもしないedge caseに対する例外処理や、二重三重のnullチェックによって、レビュー工数と保守コストが逆に増えていることに気づき始めている。HERO-Anti-OverDefenseの148スターは、その不満の温度計だ。経営視点で言えば、AI導入で人月が減ったと思っていた案件が、実は「AI防衛コードの掃除工数」に置き換わっていた可能性がある。人月削減のROIを再計算しなければならない企業は少なくないはずだ。特にレガシー統合案件では、AIの過剰防衛によって既存コードとの整合性チェックが増え、結果として工数が膨張する構造的リスクが潜んでいる。この警告を無視する経営者は、来期のエンジニアリング予算で痛い目を見る。
過剰評価への反論
とはいえ、私は「HERO契約書を貼れば解決」という空気に強く釘を刺したい。第一に、これは根本的にはプロンプトエンジニアリングの延長線上の応急処置にすぎない。モデル側の学習傾向を変えない限り、貼り付け契約書はモデル更新のたびに効果が揺らぐ。第二に、「過剰防衛」を悪と断じる思想そのものが危険だ。edge cases処理を削れば確かにコードは短くなるが、本番障害の多くは「想定外のedge」から起きる。開発者コミュニティが「冗長=悪」の空気に染まりすぎると、金融や医療のような高信頼領域では逆にセキュリティ事故を招く。148スターの熱狂は、Web系スタートアップの視点に偏った局所最適の可能性が高い。第三に、そもそもGitHub148スターは、経営判断の根拠として弱すぎる数字だ。同種の「AIに指示書を貼るだけ系」リポジトリは過去にも複数バズっては消えている。ナレーションが「爆発的に拡散」と煽るのは印象操作に近い。冷静に見れば、これは症状に貼る絆創膏であって、AIコード品質問題の本質治療ではない。「貼るだけで解決」という物語こそ、AI時代最大の思考停止装置である。
経営者として次に取るべき動き
第一に、自社のAI生成コードに含まれる「過剰防衛率」を計測せよ。行数比、例外処理比、テストカバレッジの内訳を可視化しない限り、HEROを導入すべきかどうかも判断できない。感覚論で導入を決めるのは最悪だ。第二に、貼り付け契約書は「試験導入」に留め、モデルベンダーとの直接交渉に切り替える準備をせよ。ClaudeやCursorが法人向けにシステムプロンプト層のカスタマイズを提供している以上、プロジェクト単位でSLA化するのが本筋である。第三に、「削るべき防衛」と「残すべき防衛」の社内ルーブリックを人間側で明文化せよ。edge cases処理を一律に削ると、監査対応時に説明不能な障害を抱え込む。AI品質の標準化とは、AIに任せることではなく、人間が判断基準を持つことだ。148スターに踊らされる経営者は、来年、その掃除工数を経営会議で説明する羽目になる。