Claude Code で20以上のプロダクトを実際に作ってきた6ヶ月程が経ちました。
読む前に想像していたことと、”やって初めて分かった” ことは、驚くほどズレていました。
その中でも特に効いた3つを、実例を交えて共有します。
1つ目: 作ってすぐは動くけど、育たない
初日〜3日で “動くもの” が出るのは、多くの人が想像している通りです。
問題はそこからでした。
1週間経つと、追加機能を入れるたびに、以前動いていた部分が壊れる。
2週間で全体が把握不能になる。3週間目には、放置される。
これは私自身に何度も起きた現象で、当初は「AI の限界かな」と誤解していました。
実際の原因は “自分の作業ログ” の欠落
後から言語化すると、原因はシンプルでした。
AI に何を任せて、何を人間が判断したか。
どんな指示で、どんな出力が返ってきたか。
これを残していなかった。
対策として、私は途中から `CLAUDE.md` に近い形式の “作業日誌” を各プロジェクトに置くようにしました。
– プロジェクトの目的
– 現時点で AI に任せている領域
– 人間が判断しているルール
– 起きた事故と、その対処
これがあると、次に AI と作業するとき、”文脈を持った相棒” として振る舞えるようになります。
ないと、毎回 “初対面の他人” になります。
2つ目: リカバリの方が、生成より価値がある
新しく作るのは、AI で速い。ここは想像通りでした。
でも、壊れた時に “どこから戻すか” の判断は、自分の頭がフル回転します。
AI に投げても、”文脈を持たない他人” 相当の答えしか返ってきません。
なぜリカバリ設計が長期的リターンを生むのか
私の場合、20プロダクトを並行して運用しています。
それぞれ、月に1〜2回は “小さな事故” が起きます。
– 昨日まで動いていた機能が、今日は動かない
– データの整合性が崩れている
– クライアント環境でだけ再現するバグ
これらを毎回ゼロから対応していると、20プロダクトの運用は破綻します。
なので、私はリカバリ設計に時間を使います。
– 各プロダクトに “3分で状態を復元できる” ロールバック手順を書き残す
– 事故時に取得すべきログ、確認すべきファイルの一覧
– AI に事故内容を渡す時のテンプレプロンプト
新規生成の効率化より、この設計に投資した方が、長期のリターンが大きい。
これは、実際に運用してみないと絶対に見えない感覚でした。
3つ目: “評論家” になると、その日で伸びが止まる
途中から、他人の使い方を見て「こうすべき」と語りたくなる誘惑があります。
書けば反響もあるし、”分かっている人” として認知されます。
心地よい役割です。
語り始めた瞬間、手が止まる
でも、語り始めた瞬間、自分の手が止まります。
そして、手が止まった瞬間、自分の学びも止まります。
私自身、途中で “評論家役” にハマりかけた時期がありました。
X で、他人のプロンプトを解説する投稿が伸びる。
「あなたはよく分かってますね」と言われる。
でも、その1ヶ月、新しいプロダクトは1つも作っていませんでした。
作り続ける限界を試している時が、一番学べる。
評論家になった瞬間、教える側に見えて、実は成長が止まる。
これは、私自身に起きた変化を、途中で自覚したので、書いておきます。
まとめ: 読んで学ぶより、作って学ぶ
Claude Code の使い方に「正解」はまだありません。
1年やってみて分かったのは、”やって初めて分かる” ことが、驚くほど多いということです。
– 動くものは3日で出るが、育てるには作業ログが要る
– 新規生成より、リカバリ設計への投資の方が長期リターンが大きい
– 評論家になった瞬間、成長が止まる
これらは全て、読んで想像していたこととズレていました。
つまり、この記事も、読んだだけでは学びにはなりません。
今日、1つでも触ってみることでしか、体感は生まれない。
読んで学ぶより、作って学ぶ。
これが、AI 時代の学び方の再定義だと、私は思っています。
コメント