この記事でわかること
結論から言うと、AIに開発を任せるほど「エラーで落ちない、静かなバグ」が増えていく。プログラムは平然と動いているのに、出してくる数字だけが間違っている。これが一番たちの悪いバグだ。
対策はシンプルで、バグを直す前に「走らせると合否を一発で返す小さなチェック」を先に作る。赤なら発生中、緑なら直った、とすぐ分かる仕組みのことだ。コードを読んで犯人を推理するのは、その仕組みができてから。
この考え方を自作スキルに落として、自分の株分析ツールに回してみたら、本当にバグが1個出てきた。今日はその実話を書いていく。
記事概要図
自作ツールをAIと作っていて、ふと不安になった
週末調査用に最近作った副業の株スクリーニングツールを、Claudeと一緒にPythonで育てている。米国株のトレンドを点数化して、毎週末に候補を出すものなのだが、前から精度が気になっていた。
「これ、ちゃんと動いてはいるけど……出してる数字、本当に合ってるのか？」
エラーは一切出ていない。グラフもきれいに出る。でも、それが逆にこわい。バグがないか検証したいけれど、どこからどう手をつければいいのか、ずっと考えあぐねていた。
「静かなバグ」が一番こわい
バグには2種類ある。エラーで盛大に落ちてくれるバグは、実は親切なほうだ。どこで何が起きたか、ちゃんと教えてくれるから。
問題は、落ちないバグのほうだ。プログラムは何事もなかったように動き続けて、間違った答えだけを静かに返してくる。株ツールでこれをやられると最悪で、間違った数字を信じたまま投資判断をしかねない。
しかもAIに書かせたコードは、見た目がそれっぽく仕上がるぶん、この手のバグに余計に気づきにくい。ちゃんと動いているように見えるから、つい信じてしまうわけだ。
AIに開発させると壊れる、4つのパターン
ちょうどその頃、TypeScript界隈で有名な Matt Pocock が、自分が日々使っているスキル集（mattpocock/skills）を公開していた。これがよくできていて、「AIに開発を任せると壊れる典型的なパターン」を4つに整理し、それぞれに処方箋となるスキルを当てている。
| 壊れ方 | 何が起きるか | 処方の中身 |
|---|---|---|
| ズレ | 意図と違うものを作られる | 着手前に質問攻めして要件を固める |
| 用語のブレ | 毎回同じ説明をAIにやり直す | 共有用語を文書にしてトークンを節約 |
| 品質の崩壊 | 検証なしで暴走・静かなバグ | 検証ループ（テスト・デバッグ）を強制 |
| 設計の腐敗 | 速さに比例して複雑になる | 小さな入口・深い中身で設計する |
今回自分がハマった「静かなバグ」は、ちょうど3番目の「品質の崩壊」に当たる。そして、その処方箋にあたるのが、検証ループを強制する diagnosing-bugs というデバッグ手順だった。
ちなみに導入は npx skills@latest add mattpocock/skills の一行で済んで、必要なスキルだけ選んで入れられる。最初から全部入れる必要はないのもありがたい。
デバッグの「型」を自作した（diagnosing-bugsを翻訳）
核になっているのは、たった一行のルールだ。
バグを直す前に、走らせると合否を一発で返す小さなチェック（赤緑判定コマンド）を先に作れ。
赤はバグ発生中、緑は直った状態。この「合否が一瞬で分かる仕組み」さえ先に作ってしまえば、あとは赤を緑に変えるだけの単純作業になる。コードを眺めて推理を始めるのは、その仕組みができてからだ。順番を逆にすると、たいてい沼にハマる。
このルールが良かったので、そのまま自分のClaude Code用スキルに翻訳した。名前は /bug-hunt。英語圏の開発者向けの言い回しを、週末しか動けない個人開発の自分向けに噛み砕いただけのものだ。「テスト基盤がなくても、使い捨てのチェックスクリプトで十分」といった具合に、自分の環境に合わせて手を入れている。
実際に回したら、一発でバグが出た
さっそく、この型を自分の株ツールに当ててみた。
まずは推理したい気持ちをぐっと我慢して、赤緑判定だけを作る。ネットにも繋がず、何度走らせても同じ答えが出る、合成データのチェックだ。中身はこんな感じになる。
- 「ずっと株価が横ばい（実質フラット）」な架空の銘柄を用意する
- ただし途中で10対1の株式分割が起きたことにする
- これをツールのスコア計算に流して、点数がフラット相応（ほぼ0）になるか見る
走らせた瞬間、赤になった。
調整後（フラット）のスコア = 0.0000 ← 期待どおり
分割を含む生データのスコア = -0.5400 ← バグ
❌ FAIL（赤）ただの横ばい銘柄なのに、スコアが大きくマイナスに振れている。完全な誤判定だ。
原因は、株価データを取るときの設定一行だった。auto_adjust=False という指定で、株式分割を調整していない生の株価をそのまま使っていたのだ。株は分割すると見かけ上の株価がガクッと下がる（10分割なら10分の1になる）。その「見かけの暴落」を、ツールが本物の下落だと勘違いしていた。直近1年で分割した銘柄は、移動平均も52週高値もまとめて巻き込まれて誤判定される。それでいてエラーは一切出ない。まさに静かなバグだった。
しかも調べてみると、この生データを使う設定は、週次で実際に回している本番スクリプトにも残っていた。これにはさすがにゾッとした。
修正自体は拍子抜けするほど簡単で、auto_adjust=False を True に変えるだけ。分割と配当を調整したきれいな株価が返ってくる。本番に関わる3ファイルを直して、さっきの赤緑チェックがちゃんと緑になることを確認した。最後に、「今後うっかりまた生データを使っていないか」を見張る小さなチェックも置いておいた。
ここで大事なのは、コードを一行も推理しないうちに、合成データ一発で「分割が犯人だ」と確定できたことだ。もし実際の銘柄をネット越しに何度も叩いて当てずっぽうをしていたら、たぶん半日は溶けていたと思う。
やってみて分かったこと（3つ）
ひとつ目。判定コマンドが作れた時点で、もう9割は終わっている。残りは赤を緑に変える作業でしかない。一番頭を使ったのは「どうやって合否を一瞬で出すか」を設計するところだった。
ふたつ目。AIは「動くもの」は作ってくれるが、「正しいかどうか」はまったく別の話だということ。ここは人間が検証の仕組みを持っていないと、静かなバグを永遠に検知できない。AIに任せる範囲が広がるほど、この検証の型がじわじわ効いてくる。
みっつ目。型にしておくと、毎回ブレないこと。スキルにまとめておけば、次に別のツールで「数字が変だな」となっても、同じ手順を呼び出すだけで済む。その日の気分や集中力に結果が左右されなくなる。
まとめ：AIに開発させるなら、検証の型を持とう！
AIにコードを書かせるのは、もう特別なことではなくなった。ただ、書かせれば書かせるほど「動くのに間違っている」コードのリスクは上がっていく。
だから本当に効く対策は、賢いプロンプトよりも、地味な検証の型のほうだ。「直す前に赤緑判定を作る」。これを自分のスキルとして持っておくだけで、バグ退治が運任せから手順に変わる。
ちなみに今回のような「自分専用のツールをAIと一緒に育てる」やり方は、過去に書いたObsidian × Claudeで外部脳を作った話やNotebookLM × Claudeでゼロトークン調査とも地続きだ。AIを単なる作業者ではなく相棒として使う感覚は、一度つかむともう元には戻れない。
Pythonやデータ分析の土台をきちんと固めたい人は、手を動かせる講座を一本持っておくといい。こういう「静かなバグ」に気づける目も、その過程で少しずつ育っていく。
