速く作れるほど、中身が分からなくなる——Claude Code の副作用と対処
Claude Code で個人開発は驚くほど速くなった。その速さの裏で「作れるのに中身が分からない」問題が育っていた話と、確認できる速さを作るという対処。
前回の記事の最後に「作れるのに、中身が分からないという新しい悩みが生まれた」と書きました。今回はその話です。Claude Code で開発が速くなるほど、自分のシステムが読めなくなっていく——その副作用と、いま試している対処を正直に書きます。
速い。むしろ、やめられない
Claude Code での開発は、とにかく速い。写真加工ツールは 1 日で基本機能ができました。感覚としては、だいたいのツールが「基本だけなら 1 日」です。最初に構想をある程度打ち込んで方針さえ決まれば、あとはスマホから「OK」「ちょっとこうして」「OK」くらいの返信で組み上がっていきます。
もちろん、時間をかけているものもあります。株や FX の自動売買、ワークスペース全体の管理、無料 AI の活用ロジック、このブログのような商業系。こちらはセキュリティやお金のリスクを少しずつ潰しながら積み上げるので、2〜3 ヶ月経ってもずっと「仮完成」のまま改善を続けています。
ただ、速いものも遅いものも共通しているのは、自動でどんどん進むのが楽しくて、やめられないことです。寝かしつけのあとにスマホを開けば、開発が進んでいる。この楽しさ自体は、今も変わっていません。
問題は、この速さに「別の何か」がまったく追いついていなかったことでした。
「使い切らないともったいない」の罠
Claude Code のサブスクには、5 時間ごとの利用枠と週の上限があって、時間が来るとリセットされます。
この「リセットされる」が曲者でした。使い切らないともったいない、という気持ちが湧くのです。それで、特に作りたいものが決まっていないのに、無理やり開発を進めたことが一度や二度ではありません。
その結果どうなったか。ひとつは、いらない機能まで増えました。もうひとつは、あとから仕様書——AI と共有している設計メモ——を見返すと、記憶にないルールが書いてある。どんな機能がどこで動いているのか、自分で分からなくなっていきました。
- 利用枠が時間でリセットされる。「使い切らないともったいない」が湧く
- 作りたいものが決まっていないのに、無理やり開発を進める
- いらない機能まで増える
- 仕様書に記憶にないルールが積もる
- どんな機能がどこで動いているのか、自分で分からなくなる
冷静に考えれば「枠が余ったら休めばいい」だけの話です。でも、開発が自動で進む楽しさと、もったいない心理が重なると、手が止まらない。サブスクの枠は、開発を加速する仕組みであると同時に、中身の分からないものを量産する圧力にもなっていました。
作れるのに、読めない
最初に「これはまずいかもしれない」と思ったのは、トークンの消費がやたら大きくなってきたときでした。自分が把握できていないレベルで、ドキュメントとソースコードが膨らんでいる。AI は毎回それを読んでから作業するので、肥大はそのまま消費量の増加になって返ってきます。
実は、コードを読むこと自体は、もっと前に諦めています。Claude Code の前、GAS——Google のスプレッドシートなどを自動で動かす仕組み——で AI にコードを書かせていた頃、数百行になった時点でもう読んでいませんでした。読む時間もないし、完全に AI が書いたものを理解するのはしんどかったのです。
それでも、全部自分用なので気にせずどんどん作ります。すると出来上がったものを触るのが後回しになり、いざ触ってみると不具合が多発している、ということもありました。
象徴的な出来事があります。自分用の知識ノートを作ろうとしたら、Claude Code に「受動的な画面は作らないルールがあります」と提案を却下されたのです。身に覚えがない。調べてみると、株の完全自動売買ツールを作ろうとしていたときに決めたルールが、なぜか作業場全体のルールに紛れ込んでいました。
自分が作ったはずのルールに、自分の提案が弾かれる。
実害はまだ、でも確実にブレーキ
「それで、何か実害はあったのか」と聞かれると、正直なところ「出ていないといえば出ていない」です。売買で損をしたとか、データが消えたとか、そういう事故は起きていません。
でも、ブレーキは確実にかかっています。
いちばん分かりやすいのが、株の自動売買ツールです。もはや何を作っているのか分からないまま、Claude Code の「次はこうしましょう」という提案に乗って機能を組み込みまくった結果、いまこのツールに何ができるのかが分からない。作った本人が、です。こうなると仕様を変えようにも、何がどこにあるのか分からないので、変えたい一歩目から重くなります。
もうひとつが、トークン消費です。ドキュメントとコードが肥大した結果、週の上限に 3 日で当たるようになりました。5 時間の枠が 1 セッションで吹き飛ぶこともあります。
「分からないまま作る」のツケは、事故ではなく、速さそのものを削る形で返ってきました。速く作れるのが取り柄だったのに、その速さが目減りしていく。いま思えば、これがいちばんの実害です。
だから、確認できる速さを作る
対処として選んだのは、「頑張ってコードを読む」ではありませんでした。読めないことは GAS の頃からはっきりしています。そうではなく、短時間で中身を確認できる道具を作ることにしました。作る速さに、確かめる速さを追いつかせる、という方向です。
具体的には 2 つ作りました。ひとつは、各プロジェクトの進捗や現在地を一覧でき、使っているツールやシステムの全体図も見られる管理ツール。もうひとつは、あちこちで自動で動いている部分——決まった時刻に勝手に走る処理など——の情報を全部収集して、1 日 3 回、状況を報告してくれる仕組みです。
これが、効きました。作りまくった結果いろんな場所で動いているシステムの棚卸しと整理が進んで、ようやく全体を理解できるようになりました。いまは朝、1 分だけ報告を見れば全体が把握できます。
| 確認の道具を作ったら | 導入前 | 導入後 |
|---|---|---|
| あちこちで自動で動いている処理 | 把握できず野放し | 朝 1 分の報告で見える |
| 各プロジェクトの現在地 | 記憶頼み | 一覧と全体図で見える |
| 株ツールの中身 | 分からない | 分からないまま |
そして、正直に書いておきます。表の最後の行のとおり、株ツールの中身は、まったく変わらず分かっていません。確認の道具で見えるようになったのは「何が、どこで、動いているか」までで、「それが、どう書かれているか」ではないからです。この宿題はまだ残っています。
それでも、「全体が見えないまま作り続ける」状態からは抜けられました。Claude Code で作るのが速くなるほど、確かめる仕組みの価値は上がります。もし同じように「作れるけど、分からなくなってきた」と感じ始めた人がいたら、次に作る 1 本は機能ではなく、確認の道具にしてみてください。作る速さが、それだけでまた少し戻ってきます。