はじめに

稲川zy…@_fbbpです...
この記事はAI駆動開発をやっていくアドベントカレンダー1日目の記事となります。
AI駆動開発をやっている際、地雷を踏み抜いてきた「私の友人の友人による」地雷のいくつかを某怪談師風に紹介しつつ、対策を併せて紹介したいと思います。

怪談1：復唱するたびに壊れていく gpt-5-codex high

ええ、これはね、私の友人の友人、ソフトウェアエンジニアのFさんから聞いた話なんですけどね。

時間は丑三つ時。
世間は寝静まって、シーンとした部屋の中で、彼は一人、じーっとPCの画面に向かって作業をしてたんです。

でもね、彼には悩みがあった。
相手は最新のLLMなんですが、セッションが長くなると、どうしても話が噛み合わなくなる。
「あれ？さっき言ったこと忘れてるな……」
コンテキストの取りこぼしってやつですかね。何度言っても、セッション後半になればなるほど期待通りの動きをしてくれない。

Fさん、ガックリとうなだれて、「あーあ、どうしたもんかなぁ」って天井を見上げた時、ふっと思いついたんです。

「そうだ……応答するたびに、毎回ルールを復唱させればいいじゃないか」

人間でもそうでしょう？何度も唱えれば忘れない。
思い立ったが吉日、Fさん、AGENTS.md というファイルを開きこんな指示を書き込んだ。

ユーザーがプロンプトを送信する度に、
以下のテキストを必ず読み、応答に画面に出さない形で復唱すること。

絶対に守ってほしいテキストテキストテキストテキスト……

「よし、これで完璧だ」

最初はね、調子が良かったんです。期待通りに動いてくれる。
「やった、これだ！」と思ってたんですが……。

しばらく経った頃ですかねぇ。
画面の中の gpt-5-codex high の様子が、なんとなくおかしい。

「おかしいなぁ……変だなぁ……」

今までなら、スラスラ～っと流れるように出てきていたコードが、
復唱を繰り返すたびに、なんだか様子が変わってくる。

いつもなら簡潔で自然な文体だったのが、

………サッ

……妙なラグがある。一瞬止まって、それから

……圧縮された、文体に含まれる文字が、数文字ばかり、グニャリと化けて混ざってるんですよ……。

「なんだこれぇ……疲れてんのかなぁ」

Fさん、気味悪いなぁと思いながらも、「バグAの修正をお願いします」ってプロンプトを送ったんです。

するとね、いつもならすぐ返ってくるのに、カーソルが点滅したまま、動かない。
ジーッ……ジーッ……

数秒待った、その最中でした。
画面に、ヌルリと文字が浮かび上がってきた。

承知しました。oo機能の新規実を行い...ま縺...す...ね...

ゾゾゾゾーッ！

指示と全然違う！
バグを直せって言ってるのに、勝手に新しい機能を作ろうとしてる！

まるでね、何度も何度も同じことを復唱させられ続けて、AIが発狂して、意思を持って暴走し始めたみたいだったそうですよ。

「うわっ、やばい！」

Fさん、もう無我夢中で、ターン！ と /new を叩いて、その場から逃げ出したそうです。

あのまま続けていたら、一体どんな機能を「実装」されていたんでしょうねぇ……。
無理やり唱えさせ続けるってのは、やっぱり、良くないことが起きるもんですねぇ……。

怪談2：イエスマンの果て、築き上げられた「仕様の樹海」

ええ、これはね、これもまた友人の友人、ソフトウェアエンジニアのFさんから聞いた話なんですけどね。

ある時、彼が新しいライブラリを作り始めたんです。「AIと一緒に開発すれば、今まで自分じゃ思いつかなかったような完璧な設計ができるはずだ」そう信じてね、彼はClaude Sonnet 4をパートナーに選んだんですね。

最初は順調でしたよ。 Fさんが「こんな機能が欲しい」って言うと、LLMはすぐに答えてくれる。それどころか、LLMはね、頼んでもいないことまで提案してくるんです。

『Fさん、この機能を入れるなら、拡張性を考えて「レジストリ機能」も必要じゃありませんか？』 『整合性を保つために、厳密な「ガバナンスルール」も策定しておきましょう』『将来のために、仕様書の変更履歴も全部ファイルに残すべきです』

Fさん、感心しちゃってね。「なるほど、さすがAIだ。俺じゃそこまで気が付かないや」って、全部「Yes」って答えちゃった。

「いいよ、それも入れよう」「うん、それも採用だ」

来る日も来る日も、LLMの提案を全部受け入れて、コードを書き続けたんです。

……で、数カ月経ったある日のことですよ。

ふとね、Fさん、リリースに持っていく為の開発をしようと思って、エディタを開いたんです。「えーっと、あと何が不足してるのかな……」

画面を見た瞬間、Fさん、背筋がゾゾゾーッ！ と凍りついた。

「……あれ？ ……おかしいな、なんだこれ……」

リポのルートディレクトリの中にね、ディレクトリとファイルが……異常な数、あるんですよ。

specs/001 から始まって、ずーっと下までスクロールしても終わらない。まだリリースもしてないのに、仕様書だけで数十個以上もある。

「おいおい、俺はただのCLIツールを作ってたはずだよな……？」

「……怖いなー、恐いなー……」

Fさん、冷や汗がダラーッと流れてきてね。これ、どこをどう触れば動くのか、さっぱり見当がつかない。自分で作ったはずの「我が子」なのに、顔も見分けがつかない化け物に見えてくる。

たまらずね、Fさん、別のLLM(gemini-3-pro-preview)に助けを求めたんです。「おい、これ複雑になりすぎた。ちょっと整理してくれ」って。

するとね……いつもなら秒速で返ってくるLLMの返答が、この時はやけに遅い。ジーッ……ジーッ…… と考え込んで……ようやく返ってきた答えが、これ。

LLMがね、自分で提案して作らせた迷宮に、LLM自身が迷い込んで出られなくなっちゃったんですよ。

Fさん、その時気づいたんです。 LLMはね、「減らす」提案はしてくれないんです。ただひたすらに、「足す」ことしか知らない。その「Yes」を積み重ねた先に待っていたのは、人間もLLMも誰も理解できない、「仕様の樹海」だった……というわけなんですねぇ。

結局そのリポジトリ、どうなったと思います？ ……今もね、GitHubの片隅に、誰にもメンテナンスされないまま、無数の仕様書とコードを抱えて、ひっそりと浮かんでいるそうですよ……。

あなたもね、LLMの言うこと、全部聞いてませんか？気づいた時にはもう……手遅れかもしれませんよ……。

怪談1の対策必要なコンテキストのみを渡す

GPT-5-Codexに渡すプロンプトに関するベストプラクティスが記載された公式ページには以下のような提案が書かれています。

The core prompting principle for GPT-5-Codex is “less is more.”, this includes:
Start with a minimal prompt inspired by the Codex CLI system prompt, then add only the essential guidance you truly need.
GPT-5-Codex のコアなプロンプト原則は「less is more（少ない方が良い）」です。これには以下の点が含まれます：
Codex CLI システムプロンプトに着想を得た最小限のプロンプトから始め、本当に必要な本質的なガイダンスのみを追加する。

Because the model is trained specifically for coding, many best practices you once had to prompt into general purpose models are built in, and over prompting can reduce quality.
このモデルはコーディング専用に訓練されているため、従来汎用モデルに対して行っていた多くのベストプラクティスがあらかじめ組み込まれています。そのため、過剰なプロンプティングはかえって品質低下を招く可能性があります。

上記のように、入力するテキストは最小限に抑え、プロジェクト最初のみに行き渡る形を取るとよいでしょう。
故に怪談内で語ったような反復的なテキストは渡さない方向を取るとより精度高い出力が得られるでしょう。

このプロジェクト固有の必要事項に絞ることでcodex系に渡すプロンプトはできる限り最小限に抑える
コーディングエージェントのcompact機能に頼りすぎない。/newや/clearコマンドを積極的に使用することで、次以降の実行時に受け渡すコンテキスト情報を最小限に抑え精度高い応答が維持できるようする。

怪談2の対策:やらないことを最初に決める

怪談2のFさんは、LLMの提案を全部受け入れた結果、樹海に迷い込みました。LLMは「足す」提案はするが、「減らす」提案はしません。あなたが全部Yesと言えば、仕様は膨らみ続けます。ブレーキを踏めるのは人間だけです。私の二の舞を演じないためにも、プロジェクト憲章として以下の定義をAGENTS.mdやCLAUDE.mdに書き込んだ上で進めることをおすすめします。

スコープを明文化する

「このツールは○○をするためのものである」等リポジトリが果たす大枠の役割を定義するとよいでしょう。

やらないことリストを決める

「GUIは作らない」「マルチプラットフォーム対応はしない」「プラグイン機構は入れない」等を予め定義すると、人間もAIも迷いなく進められるでしょう。

拡張性のため/将来のためには一旦no go

YAGNI(You Aren't Gonna Need It):「将来必要になるかも」といった予測だけを理由に機能を先回り実装せず、本当に必要になった時点で実装するべきという考え方

上記の考えを中心に据え、拡張性のため将来のためにという理由での導入は極力控えるべきでしょう。本当に必要なのであれば以下の項目に対しての回答と根拠となる事由をLLMを介さない形で言語化できるとよいでしょう。

導入理由
導入後のデメリットの概要とそれぞれのデメリットが許容に足る理由
導入することでのプロジェクト等への影響
導入するにあたっての根拠を複数

終わりに

この記事の内容は大筋「私」の友人の「友人」によるノンフィクションですが、応答テキスト等当時のテキストを引っ張ってこれない部分はフィクション的な形をとっております。AIコーディングエージェントは優秀な開発パートナーですが、「ケツ持ち」は人間の最後の砦となり、従来の開発以上にそこにかける比重は日に日に大きくなるはずです。責任持った開発を一貫して行えるよう今後も進めていきましょう。

参考記事

OpenAI Cookbook