使いこなせるようになった人がぶつかる、3つの壁

入門編の壁は「再現しない・確かめられない・続かない」の3つでした。どれも、1つの作業をAIに頼むときの話です。指示を整え、前提をファイルに置き、確かめる仕組みを作り、定時に動かす。ここまでできると、その壁はかなり低くなります。

ところが、仕組みが10個、20個と増えてくると、別の種類の困りごとが出てきます。1つずつは正しく作ったのに、全体として見ると、どこかがいつも少し壊れている。この講座は、その段階の話をします。

エラーで止まる仕組みは、まだ親切です。困るのは、何もしていないのに「正常に終わった」と記録される壊れ方です。自分の環境では、次の2つが実際に起きました。

• バックアップのジョブが、送り先の設定が空のまま5か月間、毎日「スキップして正常終了」していた。記録はずっと成功で、一度もバックアップしていなかった
• 週の振り返りを作るジョブが、Mac がスリープから戻った月曜の朝に動くと、終わった週ではなく始まったばかりの週を集計していた

どちらもエラーは一度も出ていません。終了コード^※1は0で、ログにも「完了」と出ていました。仕組みが「動いたか」だけを見ていると、この種類の失敗は見えません。

CLAUDE.md やメモリは、足すのは簡単で、減らす人はほとんどいません。半年たつと、もう存在しないファイル名、ぶつかり合うルール、誰も守っていない約束が混ざってきます。

Claude Code のドキュメントには、CLAUDE.md は1ファイル200行以内を目安にすること、長くなると守られにくくなること、矛盾したルールがあると、AIがどちらかを適当に選ぶことがある、と書かれています。AIは書かれたことを全部まじめに読むので、古い前提があると、まじめに迷います。

仕組みを作れるようになると、作ること自体が楽しくなります。その結果、使っていないスキル、誰も読まない通知、止め方のわからない定時実行が増えていきます。

数が増えると何が起きるかは、計算で確かめられます。1つの仕組みが1日に問題なく動く確率を99%とします。互いに関係なく壊れるとすると、全部が無事な確率は掛け算になります。

72個あれば、2日に1日はどこかが壊れている計算です。自分の環境の定時ジョブはちょうど72本でした。1つずつの出来をいくら上げても、数が増えれば「どこかが壊れている」のが普通の状態になります。

作りすぎるから前提が増えて古くなり、古い前提の上で動く仕組みが、気づかないうちに壊れる。3つは別々の問題ではなく、1本の流れです。

だからこの講座では、どの段でも「どう作るか」と同じ重さで、どう確かめるか・どう止めるか・どう減らすかを扱います。

Google のシステム運用の本（SRE本^※2）では、監視は「何が壊れているか（症状）」を見て、「なぜ壊れたか（原因）」はそのあとで調べる、と書かれています。利用する側から見て困っていることを先に見張る、という考え方です。

自分の仕組みに当てはめると、「ジョブが動いたか」ではなく「成果物が届いているか」を見る、ということです。バックアップなら「今日のファイルが送り先にあるか」、週の振り返りなら「先週の分があるか」。こう見ていれば、上の2つの失敗はその日のうちに気づけました。