【ClaudeCodeでAI投資ツールを作る】ClaudeCodeに「監査」を頼んだら、設計から作り直すことになった

ClaudeCodeで金融AIを作った話

前回、Antigravityで作ったシステムのProプランが1時間で溶けた話を書きました。

溶けました。1時間で。マジで溶けた。知らないうちに。

これは相当な方向転換が必要だ、ということだけはわかりました。
でもどうやったらいいか皆目見当がつきません。
なぜならAIにすべてやってもらっているから。

その言葉だけが、ふっと私のもとに降りてきました

それが、真の意味での始まりでした。

「完成した」という幻覚

Antigravityで「動くシステム」ができました。
動いた。確かに動いたんです。
画面に数字が出た。グラフが出た。
なんかそれっぽい「うまくいってます！」みたいなメッセージも出た。

「完成だ」と思いました。人はこうして過ちを犯します。

ただ、1時間でクレジットが溶けたこと、成績がゴミだった。
本当にゴミ。
鉛筆転がして投資したほうがマシってぐらい。

そこで、ClaudeCodeに頼むことにしました。

「このコード、問題ないか全部チェックしてもらえますか？」

当時、ClaudeCodeが何なのか、正直よくわかっていませんでした。 「まあ、AIだし、『いいですね！』くらい言ってくれるだろ」 くらいの期待感です。

Antigravityが出力したコード全体を貼り付けて、 「システム監査を実施してください」と頼んでみました。

返ってきたのは、14個の不合格通知だった

ClaudeCodeの回答を読んで、少し呆然としました。

以下の14個の問題が見つかりました。
REQ-01: ...
REQ-02: ...
...
REQ-14: ...

14個。

「えっ、14個？」

「いいですね！」は一言もありませんでした。 容赦がない。
ご丁寧に番号付きでズバズバ言い放ってくる。

一つ一つ読んでいくと、確かにそれぞれが「問題」だった。 言い訳できない、本物の問題でした。

例えば：

REQ-01：ファイルの構成がバラバラ 
Pythonには「パッケージ」という概念があります。
フォルダの中に __init__.py という空ファイルが必要です。
これがないとPythonがそのフォルダを認識できません。
Antigravityが作ったプログラムには複数フォルダでこれが抜けていました。 正確に言うと「空のファイルが一個だけしかなかった」んですね。
そりゃダメだわ。

REQ-02：ライブラリのバージョンが記録されていない 
requirements.txt に「numpy 1.26」「pandas 2.0」となど、必要な設定を全部書いておかないと、他の環境では動きません。
こちらも不完全でした。

REQ-03：自動テストが走らない設定 
GitHub Actionsという自動テストの仕組みがあるんですが、設定ファイル（pytest.ini）が足りていなかったので、テストが毎回失敗していました。
っていうかテストが失敗し続けているのに、Antigravityでは

としか伝えられていなかったので、失敗さえ気づけていなかった。

REQ-04〜14： 同じような「設計上の問題」が、延々と。

「14個」というのは、「14問不正解」じゃなくて 「そもそも採点できる状態じゃなかった問題が14個」でした。

「動く」と「機能する」の間には、崖があった

ここで、ひとつ重要なことを理解しました。

自分のシステムは「動いていました」。 でも「正しく作られていませんでした」。

具体的には：

「うちのパソコンでは、たまたま動いてた」

という状態。

別のパソコンに移したら動かないかもしれない。
1ヶ月後、自分のパソコンで動かしたら動かないかもしれない。
GitHub Actionsで自動テストを走らせたら、即死するかもしれない。

「動くコード」と「いつでも、どこでも、安定して動くコード」は 全然別物だったんです。

飛行機が「離陸できた」と「安全に飛べる」が違うように。 橋が「立ってる」と「安全に渡れる」が違うように。

自分が作ったのは、崖の上に立ってる橋でした。 しかも自分では気づいていなかった。

絶望と、でもよかったという話

「せっかく動いたと思ったのに…」という落胆。

でも同時に、「これに気づかないまま先に進んでたら、 絶対にもっと大変だったな」という安堵もありました。

ClaudeCodeが指摘してくれなかったら、 バックテストを何十回も繰り返すうちに 「なぜか急に動かなくなった」が何度も出ていたはずです。

原因もわからないまま途方に暮れてたと思う。

そして「自分の力じゃ、このレベルの問題には気づけなかった」 という無力感も、ちゃんとありました。

コードの「構造」を、わかっていなかった。 「ちゃんと作る」がどういうことか、知らなかった。

ClaudeCodeに見てもらうことで初めて、 「自分の設計がダメだった」という事実と正面から向き合えました。

「全部捨てよう」と決めた

14個のリストをもらった後、決意しました。

「Antigravityのコードは、全部捨てよう」

「ClaudeCodeのアドバイスを受けながら、 　設計してから、ちゃんと作り直そう」

と。

後から考えると、Antigravityで作ったものは 「0から出発するためのトレーニング」だったんだと思います。

たまたま動いたコードは、「何が問題かを知るための実験」でした。

まあ、授業料にしては安かったかもしれない。

📌 Tips：「書いてもらう」より「見てもらう」が刺さる

▼ 「動く」と「正しく作られている」は別物

「とりあえず動いた」は「完成」ではありません。 自分で見ただけでは気づけない問題が、必ずあります。

▼ 「AIに監査を頼む」という使い方

「このコード、全部見て問題がないか教えてください」 という頼み方ができます。
これはコードを書けない人間にとって特に強力な使い方です。
自分では「設計の妥当性」が判断できないからこそ、 プロの目でチェックしてもらう感覚です。

▼ ファイル構成は「見えない基礎」

__init__.py の有無、requirements.txt の記録、 こういう「見えない部分」がシステムの土台です。 家で言えば基礎工事。外見がきれいでも、 基礎がゆるければ時間とともに崩れます。

▼ requirements.txt は「動作保証書」

使っているライブラリとそのバージョンを書いておくことで、 「このシステムを動かすには何が必要か」を次の人に伝えられます。 書いておかないと、誰も（未来の自分も含め）再現できません。

▼ CI（自動テスト）は「やらかし検知システム」

GitHub Actionsを設定しておくと、 コードを保存するたびに自動でテストが走ります。 「自分のPCでは動いたけど、上げたら壊れてた」 という事故を防ぐやつです。

▼ 「全体を見て」より「ここを見て」

最初から「ファイル構成だけ見てください」と絞った方が、 返ってくる回答が具体的で実装しやすくなります。 14個を一気にもらうと、どこから手をつければいいかわからなくなります。

次回

ClaudeCodeのアドバイスを受けながら「ちゃんと設計する」作業が始まります。

初日に全パイプラインを一気に作ろうとした無謀さと、 その結果どうなったかを書きます。

次回： #3 「初日に全パイプラインを実装しようとした無謀」

おまけ：私が思うAntigravityちゃん（擬人化）

絶対こんな子にちがいない。
（そして、こういうときだけ賢いな、Gemini。ばっちりじゃねぇか）