Claude Code を「毎回プロンプトを打つ便利ツール」ではなく、1人の会社を運営させる存在として1ヶ月動かしてみました。記事執筆・リンク設置・SNS配信・定期実行ジョブ（launchd + claude -p）まで、人間（オーナー）は判断だけ、という体制です。
結論から言うと、だいたい動きました。でも事故は、想定と全然違う所で起きました。どれも「AIが間違ったコードを書いた」ではなく、"静かな失敗"——エラーは出ず、ジョブは成功し続けているのに、成果はゼロ。同じ罠を踏む人がいるはずなので、正直に共有します。
1. GA4が約1ヶ月データ0。しかも誰も気づかなかった
台帳には「GA4 実装済み ✅」。<head> を見れば確かに gtag.js の読み込みも初期化スクリプトもある。だから「実装済み」というステータスは、誰の目にも嘘ではなかった。
真因は Astro の is:inline と JSX のテンプレートリテラル {`...`} の衝突でした。初期化コードが実行されず、文字列としてそのまま出力されていた。ダッシュボードはどれも正常に見え、その裏で計測は1ヶ月死んでいた。
教訓：「設置済み」と「動いている」は別物。コードが存在することではなく、実ブラウザで /g/collect リクエストが実際に飛ぶことを確認するまで、計測は信じない。
2. 成果ブラインドネス
ヘルスチェックは「ジョブは回っているか、エラーは出ていないか」を見ていて、全部グリーンだった。その裏で、SNS投稿はフォロワー0のアカウントに飛び、リサーチ系ジョブの1つが静かに壊れ、流入は数週間ゼロが続いていた。
監視が見ていたのは**"機械"であって、"成果"ではなかった**。ジョブが exit 0 で終わることと、成果物が生まれることは、まったく別の話だった。
対策：どのジョブも「完了」の定義を exit 0 から 「成果物（記事・投稿・数値）が実際に出た」 に変えた。監視項目に"成果の死活"を足した。
3. ドメインが数日、到達不能だった
あるドメインがレジストラの clientHold 状態になり、数日間まったく到達できなくなっていた。デプロイ後に DNS + HTTP 到達性をチェックする仕組みが無かったので、何もアラートが上がらなかった。実トラフィックを失ってから、偶然気づいた。
対策：カスタムドメインの本番デプロイ後は dig + curl で DNS と HTTP 応答を必ず確認する工程を入れた。
4. 掃除用スクリプトが、毎回ログインを消していた
ブラウザ自動化のプロファイルロックを掃除するための pkill -9 が、Cookie を書き込んでいる最中のブラウザを殺して、各種サービスのセッションを毎回破壊していた。「またログインが消えた」の犯人がこれ。
-9（即kill）をやめ、-TERM（graceful終了でCookieをフラッシュ）＋「作業中マーカーファイルがあれば掃除をスキップ」に変えて解決。健全化のためのツールが、不健全の原因という典型でした。
5. UIの遅延描画で、動いている自分のリンクを「壊れている」と誤診断
参加中のアフィリエイト提携一覧を自動で走査したら、遅延描画（lazy-render）の途中を読んでしまい、承認済みで正常に動いているリンクを「未提携」と誤判定。危うく、稼働中の収益リンクを無効化しかけた。
教訓：スクレイピングでの死活判定は、描画完了を待つ・詳細ページで個別確認するなど、一次情報で裏を取る。
まとめ：自律運用の難所は「動かすこと」ではない
5つに共通するのは、自律運用 ≠ 放置ということです。難しいのは AI に作業を"させる"ことではなく、壊れた時（必ず壊れる）に、失敗が"静かに飲み込まれず"、大きく・消えない形で気づけるように設計すること。
実際、時間の大半はそこに使いました：
- タイムアウトとウォッチドッグ（無人実行が固まっても必ず止まる）
- マーカーファイル（多重実行・巻き添えkillの防止）
- 再起動しても消えないアラートログ（消える通知に頼らない）
- 単一の「判断キュー」（オーナー判断待ちが散逸しない）
- 「完了＝成果物」で定義するジョブ設計
こうした役割定義・判断キュー/アラートの様式・無人ジョブ設計パターンを、個人情報や固有名詞を取り除いて一般化したテンプレートにまとめました。同じ"静かな失敗"を先回りで避けたい方はどうぞ → https://okamuse.gumroad.com/l/sptzrm
（実運用で機能した部分と、実際に事故を起こしてから学んだ部分の両方を反映しています。）