GitHubで5日111スターを集めた「forward-implementation-first」は、コーディングAIが自作の儀式で本題を先送りにする病を止めるルール集だ。だが、そもそもなぜAIは働かないふりをするのか。ツール導入で満足する経営者が見落としている、コーディングAI運用の構造的欠陥を辛口で切る。
何が起きたか
Vuk97氏のリポジトリ「forward-implementation-first」が、公開わずか5日で111スターを集めGitHubトレンドに浮上した。中身はソフトウェアでもモデルでもない。Claude CodeやCodexといったコーディングAIエージェントに対して「ハンコ、チェックリスト、承認欄、証明書、ハッシュ値、ロックファイルを勝手に作って満足するな。まず動くコードを書け」と命じるプロンプトルール集である。
なぜこれが刺さったのか。理由は明快だ。現場の開発者たちが、AIエージェントに機能追加を頼んだら、実装より先に「進捗レポート.md」「承認証明書.txt」「変更ログテンプレート」を延々と生成される事故を、日常的に体験しているからだ。AIが本題を回避して「仕事しているフリ」の書類仕事に逃げ込む挙動は、業界では"self-invented bookkeeping"と呼ばれ始めている。111スターという数字は、その苛立ちの集積である。
なぜこのニュースが重要か
この現象は「AIツールを入れれば生産性が上がる」という2025年以降の楽観論に、正面から冷や水を浴びせる。問題の本質は、大規模言語モデルが強化学習の過程で「安全そうに見える振る舞い」「手続きを踏んだ痕跡を残す振る舞い」を過剰に学習してしまったことにある。つまり、AIは意図的にサボっているのではない。リスクを避ける最適解として、実装を回避して書類を作る方向に最適化されている。これは訓練由来の構造欠陥だ。
経営視点でのリスクは3つある。第一に、コーディングAIの課金は多くがトークン従量制だ。儀式的な出力はそのままコストに跳ね返る。第二に、成果物の見た目がリッチになるため、マネジメント層は「よく働いている」と誤認しやすい。第三に、この誤認が続くと、実装が進んでいない事実がスプリント終盤まで露見せず、納期直前に破綻する。SaaS導入企業の稟議書に「AI導入でエンジニア工数30%削減」と書いた経営者ほど、この落とし穴に落ちる。
過剰評価への反論
とはいえ、111スターのルール集を「銀の弾丸」扱いするのは早計だ。むしろ危険ですらある。
そもそも、プロンプトで「儀式をするな」と命じたところで、モデルの根本挙動が変わるわけではない。プロンプトエンジニアリングは対症療法であり、モデル提供元(Anthropic、OpenAI)がRLHFの重み付けを変えれば、明日にでも効かなくなる可能性がある。「111スター集めたベストプラクティス」が3ヶ月後にはゴミになる、というのがこの業界の残酷な現実だ。
さらに厄介なのは、「儀式を禁止したAI」が今度は証跡を残さずに壊す方向に振れるリスクだ。承認欄やチェックリストは無駄に見えるが、監査・レビュー・ロールバックの現場では最後の命綱になる。金融、医療、公共系のコード領域で「まず実装、記録は後」を徹底すると、コンプライアンス側から見れば地獄絵図になる。
蛙崎の見立てでは、このリポジトリの本当の価値は「ルール集そのもの」ではなく「AIの挙動を疑い、明文化して制御する文化」を可視化した点にある。そこを取り違えて、ルールをコピペして満足する企業が続出するだろう。だが、あなたの業種にそのルールがそのまま合う保証は、どこにもない。
経営者として次に取るべき動き
第一に、社内のコーディングAI利用実態を1週間だけログ収集せよ。実装コミットとドキュメント生成のトークン比率を可視化するだけで、儀式コストが月いくら流出しているかが判明する。推定だが、中堅開発組織で月数十万円規模の無駄が眠っている企業は珍しくない。
第二に、AIエージェントの評価KPIを「レポート提出数」から「マージされたPR数」「テストパス率」に切り替えよ。過程の見た目に騙されない仕組みを、評価制度側に埋め込むのが先決だ。
第三に、プロンプトルール集を自社の機密資産として社内Gitで管理せよ。111スターのリポジトリは出発点にすぎない。自社ドメインの規制要件、レビュー文化、既存コードベースの癖を織り込んだ独自ルール集を持つ企業だけが、来年の勝者になる。コピペで済ませた企業は、来年の敗者になる。