どこで何が動いてるのか分からなくなった——自動化を 3 周して見つけた置き場所

AI に勧められるまま、自動化のツールを次々に入れました。動くものは増えたのに、どこで何が動いているのかは分からなくなりました。図を描いても、一箇所に集めても解決しませんでした。3 周してようやく落ち着いた場所の話です。

前回は「読めない」話、今回は「どこにあるか分からない」話

前回の記事では、Claude Code で速く作れるようになった結果、自分が作ったコードの中身を読めなくなっていく話を書きました。今回はその続きで、対象が変わります。コードではなく、動いているものそのものの居場所が分からなくなった話です。

速く作れるほど、中身が分からなくなる前回の記事。作れるのに読めない、という副作用の話。

きっかけは、自分で気づいたのではありませんでした。

不具合らしきものを見つけて Claude Code に直させていたときのことです。修正のたびに、頼んでもいない報告が返ってくるようになりました。「これは陳腐化しています」「これは二重化しています」。最初は 1 つ 2 つでしたが、だんだん頻発するようになりました。

つまり、把握できていないという事実は、自覚症状より先に、他人からの指摘という形で出てきたわけです。この場合の他人は AI でした。

1 周目——とにかく入れた

そこまでに入れていたものと、その後どうなったかを並べます。

入れたもの	何のために	いま
Windows の自動起動	PC を点けたら勝手に動いてほしい	ほぼ退役
タスクスケジューラ	決まった時刻に実行したい	家でしか動かせない処理だけ
n8n	処理を線でつないで組み立てたい	26 個まで育てて退役
Docker	環境を選ばず動かしたい	退役
Healthchecks	合図が来なかったら教えてほしい	今も稼働
Uptime Kuma	生きているか外から叩いて確認したい	退役（過剰だった）
Render	アプリをそのまま置いて動かしたい	置き場所が 3 回変わった

どれも、入れた時点では正しい判断でした。「定期実行したい」と言えばタスクスケジューラを勧められ、「動いているか確認したい」と言えば監視ツールを勧められる。提案には毎回ちゃんと理由がありました。

全部が無駄だったわけでもありません。 Healthchecks は今も動いています。Render も当時は必要でした。株のツールの Python 部分を置くために使っていて、その後、株価データの取得元に利用制限があったので家の PC へ移し、いまはクラウドのサーバーへ移っています。ツールが悪かったのではなく、都合が変わるたびに引っ越しただけです。

一方で、いちばん要らなかったのは Uptime Kuma でした。

壊れたわけではない。時計が 4 重になった

誤解のないように書くと、どれも壊れませんでした。ツールの品質の問題ではありません。

問題は数と配置でした。特に効いたのが「時計」です。決まった時刻に何かを実行する仕組みが、気づけば 4 つ並行していました。

時計	何を動かしていたか
n8n	自作の自動化フロー（最終的に 26 個まで増えた）
タスクスケジューラ	家の PC でしか動かせない処理
データベース側の時計	データを触るだけで完結する処理
Claude Code ルーチン	AI に判断させたい処理

この状態で「あの処理、今どうなってる？」と思ったとき、まず 4 箇所のうちどこを見ればいいかを思い出すところから始まります。しかもそれぞれ画面も用語も違います。

n8n は最終的に 26 個のフローまで育ってから、段階的に畳みました。役に立たなかったからではなく、時計が 4 重になっている状態そのものを解消したかったからです。

2 周目——構成図を描いた（失敗）

最初に思いつく解決策は、たぶん誰でも同じだと思います。図に描けばいい。

私は自分用の管理ツールを作っていたので、その中に構成図を置きました。どこで何が動いていて、何がどこにつながっているのか。作った直後は、たしかに気持ちよかったです。

見ていたのは、最初だけでした。

理由は 2 つあります。ひとつは、構成が大きくなり出してから、全体図を見ても分からなくなってきたこと。図は正しく描かれていても、載っている要素が増えれば、結局その中から必要な 1 つを探す作業になります。これは一覧表を眺めるのと大差ありません。

もうひとつは、しばらく経つとその図が今も正しいのか自分で判断できなくなったことです。更新を忘れた図は、ただ間違っているよりたちが悪いです。合っているかもしれないし、ずれているかもしれない。確かめるには結局、実物を全部見に行くしかありません。

3 周目——全部 Claude Code ルーチンへ集約した（失敗）

そこで次に考えたのが、見に行かなくていい場所に置くという発想でした。

私は毎日 Claude Code を使います。だったら、定期実行するものを全部 Claude Code のルーチンに載せてしまえば、いやでも目に入るはずだ、と。

効率は度外視しました。本来そこで動かす必要のない処理まで、多少無理をして寄せています。「効率よりも、把握できることのほうが大事だ」と判断したからです。この判断自体は、今でも間違っていなかったと思っています。

結果は、こうなりました。

無数のルーチンが起動して、スマホから開くと大量に並んでいて、見られなかった。

図のときと、着地点が同じでした。前回は「見に行かない」、今回は「目には入るが読まない」。手段は正反対なのに、結果は 1 ミリも変わりません。

多すぎたのは事実で、減らす作業も必要でした。ただ、本当の問題は数ではありませんでした。

着地——「動かす場所」と「見る場所」を分けた

行き詰まってから、思考はこう動きました。

1. Claude Code ルーチンに集約できたのなら、そもそも処理そのものもまとめられるのでは？
2. そう考えて、まとめられるだけルーチンの数をまとめていった
3. その作業の途中で、ふと気づいた

気づいたのは、身も蓋もないことでした。どうせ毎回詳しく確認する時間などない。だから、詳しく置いても意味がなくなる。

必要だったのは、処理をまとめることではなく、3 つを同時に満たす報告でした。並べると、なぜ 2 周とも駄目だったかがはっきりします。

条件	構成図	全部を集約	番人
網羅的で、かつ簡易	✗ 網羅的だが重い	✗ 網羅的だが多すぎる	✓
向こうから来る	✗ 見に行く必要がある	✓	✓
毎日使う場所にある	✗	✓	✓

2 周目も 3 周目も、やっていたのは「情報の置き場所」をいじる作業だった。足りなかったのは置き場所ではなく、要約して押し出してくる機能のほうだった。

そう決まると、実行する場所は自由になります。把握のために無理やり寄せる必要がなくなったからです。いまは、それぞれの処理が持っている制約だけで置き場所を決めています。

制約	置き場所
常時動いていてほしい／家の PC が落ちても困る	クラウドのサーバー（OCI）
AI に判断させたい	Claude Code ルーチン
Windows でしか動かない・GPU が要る・常駐が必要	家の PC

そして Claude Code ルーチンには、全体の状況を集めて報告する 1 本だけを残しました。私はこれを「番人」と呼んでいます。1 日 2 回、全部の定期実行について「動くはずだったもの」と「実際に動いたもの」を突き合わせ、日本語で報告してきます。

いま、毎朝どう見えているか

実物を見てもらったほうが早いと思います。今朝届いたものの抜粋です。

## 🌅 朝の株チェック ― 07:31 JST 実行・12/12 成功
- ✅ 材料を集める（ニュース・スクリーニング指標・決算・AI分析）
- ✅ 銘柄を選ぶ（推奨＋成長株/割安株/話題テーマの候補）
- ✅ データの鮮度を点検

## ⚙️ その他の自動処理
- ✅ 場中監視 tick 統合（5 分ごと）稼働中＝無音検知 up・最終 ping 12:55
- ✅ 週次セキュリティ監査 7/20 ／ 自己点検 08:11 ／ 日次パイプライン 07:08
- ⏸ この画面では実績を追えない（オンデマンド／Windows 系）：常駐サンプラ・
     証券会社ツールの再起動・家計 CSV の月次取込

## 🔔 死活監視
- ✅ サービス死活 全 UP（監視対象 17） ／ 無音検知 1 件 正常

## 🧑 あなたの確認待ち
- ✅ 改善提案 0 件 ／ 戦略の改善案 0 件
- … 判定に必要な件数が不足（12/20）

## まとめ：異常なし

見どころは 3 つあります。

1. 見出しが全部日本語で、結果が ✅ に畳まれている。処理名ではなく「何をしたか」が書いてある
2. ⏸ の行で、番人が自分の限界を自己申告している。「ここからは実績を追えません」と言える
3. 末尾が 「まとめ：異常なし」。読まなくていい日は、そこだけ読んで終わり

2 つ目がいちばん効いています。構成図は、自分が古くなったことを教えてくれません。限界を自己申告できるかどうかが、受け身の道具との決定的な差でした。

異常があった日は、番人が原因を調べて、検証できる修正をそのまま入れます。判断が割れるものとリスクが大きいものだけ、私に上がってきます。

副産物——集約した作業自体は、無駄ではなかった

3 周目を失敗と書きましたが、正確ではありません。結論は間違っていたけれど、作業としては効いていました。

一箇所にまとめようとする過程で、無駄が見つかって消え、重複が整理され、動いていなかったものが表に出ました。潜在的なバグもいくつか潰しています。先ほどの「68 本が退役」という数字の、かなりの部分はここで動きました。

さらに番人が回り始めてからは、報告と実態のズレそのものが発見の入口になりました。「動いているはずなのに実績がない」は、たいてい何かが壊れているサインです。

それでも、番人も壊れる

きれいに終わらせたいところですが、現実は違います。番人にも問題は出ました。

つまり監視役を作ると、今度は監視役の言うことが正しいかを疑う仕事が生まれます。当たり前ではあります。番人も自分で作ったシステムである以上、陳腐化もするしバグも出ます。

なので、これは完成した話ではなく、現在地の報告です。

一本化すべきだったのは、実行基盤ではなかった

3 周を振り返ると、こういう流れでした。

1. 1 周目勧められるままツールを入れた。壊れてはいないが、時計が 4 重になった
2. 2 周目構成図を描いた。見に行かなくなった（受け身の道具だった）
3. 3 周目全部 Claude Code ルーチンへ集約した。量に潰れて読まなくなった
4. いま実行は制約ごとに分散させ、報告だけを 1 本に集めた

3 周そのものは 2〜3 週間ほど。ただ構成図を作ったのはかなり最初のほうなので、そこから数えると3 ヶ月くらいの積み重ねの末の話になります。

一本化すべきだったのは、実行基盤ではなく「見る場所」でした。しかもその見る場所とは、見に行く場所ではなく、向こうから来る場所という意味です。

同じことで悩んでいる人へ、ひとつだけ。把握できないのは、ツールを選び間違えたからではありません。 どこで動かすかを何度並べ替えても解決しませんでした。決めるべきなのは「どうやって自分の目に入れるか」で、それは実行基盤とは別に設計していい。これが 3 周してわかったことです。

回り道が無駄だったかというと、全部必要な道だったと思っています。図を描いて失敗しなければ「受け身では駄目だ」とは気づけなかったし、集約して潰れなければ「場所ではなく要約が要る」とは気づけませんでした。