新モデルの過剰実装——AI開発で「抑制の圧力」をかけ続ける重要性
きっかけ
今日アップデートされた「Claude Opus 5.5 high」を丸一日使い、LLMの翻訳精度を向上させるためのデータベース構築プロジェクトを進めてみた。
これまでは「ponytailプラグイン」を用いて過剰実装を抑えるアプローチが機能していたが、モデルが更新された影響か、その方針が思うように効かなくなっていた。何度指示しても日本語で回答してくれないなど挙動の変化に振り回され、気づけばAIがコードを書きすぎてプロジェクトが過度に複雑化し、収集がつかなくなった。
学んだこと
- 新モデル登場時は、いきなり大規模な開発に投入せず小さなタスクで挙動を確かめるべき
- 指示の通りやすさやプラグイン・プロンプトの効き目が変わることがあるため、まずはネット上の動向や簡易検証で性質を見極める必要がある。
- AI任せの自動生成（Auto放置）やプロンプト作成支援は、プロジェクト肥大化の温床になる
- 数行のプロンプトで放置して「完了」しても、ブラックボックス化した扱えない遺物が残るだけで、時間とトークンの浪費につながる。
- 個人ツールの開発では「自分が把握できるサイズ」を死守する
- 検証のための検証が増え始めたら危険信号。プロジェクトを意図的に抑制・収束させる圧力を常にかけ続けなければならない。
自分なりの理解
AIは依頼すればいくらでもコードを書いてくれるが、それは成果物の完成ではなく、無秩序な複雑さの塊になり得る。個人開発の目的は、自分の課題を解決することであり、自分が中身を理解・保守できないコードがいくら出来上がっても意味がない。
モデルが変わった直後は、これまでの「手綱」の引き方が通用しなくなるリスクがある。だからこそ、AIにプロンプトを作らせる場合であっても、「スコープを最小限に絞る」、「余計な機能を削ぎ落とす」という収束方向へのブレーキを意識していないと、あっという間に開発は破綻してしまう。
実践へのつなげ方
- モデル移行時のルール化: 新モデル導入直後は本番プロジェクトに即座に適用せず、単機能のスクリプトなど安全なスコープで挙動テストを行う。
- プロンプト設計の意識改革: AIに設計や実装を依頼する際は、「要件を広げる」のではなく「要件を削る」「これ以上コードを増やさない」制約条件をプロンプトに必ず組み込む。
- 引き返し基準の設置: 「テストのためのテストコード」や把握しきれない依存関係が発生した時点で作業を止め、スコープを元の最小単位まで絞る。
次に試すこと
Claude Opus 5.5 highに対して、まずは数十行で完結する最小限の単機能スクリプトを渡し、日本語指示への追従性や過剰実装を抑えるための制約プロンプト（「追加機能の提案は不要」「最小限のコードのみ記述」など）の効き具合を検証する。