[PR] 本ページはプロモーションが含まれています
「AIに任せれば楽になる」って、本気で信じてた。
Claude Max 5xプランには月110ドル（税込）を払っている。さらに、Claude APIにも直近で30ドルほどチャージしていた。
Claudeチャットで設計し、Claude Codeで実装し、APIも自動化に使う。
これだけ環境を整えれば、自分は最終判断だけすればいい。そう思ってた。
でも実際には、VPS作業を任せた1日で気づいた。俺、AIの監督者になってる。
これを書いてる今、ポピがキーボードの上で完全に伸びてる。退かしても3秒で戻ってくる。
画面の中ではClaude Codeが「やりますか？」と聞いてくる。退かしても次のミスで戻ってくる。
三毛猫のフミは膝の上。何も言ってこない。ただ温かい。
で、ある瞬間気づいた。俺、ポピとClaude.aiとClaude Codeの3つを監督してる。
1日終わって振り返ったら、自分の手は1行もコードを書いてないのに、頭はずっと働いてた。
果たして、これは自動化なのか？
この記事は、Claude CodeにVPS移行作業を任せてこれまでの自動化システムのデータを吹っ飛ばした
筆者MATSUの失敗談だ。
ただし、AIに全部責任を押しつけたい話ではない。
発端には、バックアップなしでPC移行を進めた自分の判断ミスもあった。
だからこれは、AIを責める記事ではなく、AIに任せる前に人間側が何を決めておくべきだったのかを再認識するための記事だ。
📌 この記事で分かること
- AIにVPS作業を任せて起こる「監督コスト」の正体
- 月110ドル払っても自動化されない本当の理由
- Claude CodeにVPS作業を任せる前に固めるべき5つの前提
PROLOGUE
そもそもの発端は、VPS移行でローカルデータを失ったことだった
結論：今回の話は「AIが悪い」で終わる話ではない。
最初の失敗は、自分がバックアップなしでPC移行を進めたことだった。
AIの助言不足もあったが、最終判断をしたのは自分だった。
発端は、別のClaudeとの会話で「VPSに移行して、MacBook側の環境を切り替えよう」という流れになったことだった。
その流れ自体は悪くなかった。ローカルPCに依存した自動化より、VPS上に置いた方が安定する。
外出中でも動くし、MacBookを閉じても処理が止まらない。
でも、ここで俺が致命的なミスをした。
バックアップを取らないまま、PC移行を進めた。
結果、ローカルにあったデータが全消失した。
もちろん、別のClaudeにも問題はある。VPS移行やPC切り替えの話をしているなら、
本来は「先にバックアップを取ってください」と明示的に止めるべきだった。
でも、最終的にバックアップなしで進めたのは自分だ。
その後、俺は失った環境を立て直すために、VPS上で自動投稿システムを作り直すことにした。
そこで使ったのがClaudeチャットとClaude Codeだった。
ここから、さらに別の学びが始まった。
SECTION 01
AIに任せれば作業時間が減ると思っていた｜月110ドルの期待値
結論：月110ドル払ってAIに任せたのは「自分の時間を減らすため」だったが、
運用設計を固めずに丸投げすると、時間は減るどころか「監督」という新しい仕事が生まれる。
ローカルデータ消失のあと、俺はVPS上で自動化環境を立て直すことにした。
ここで改めて、なぜClaudeチャットとClaude Codeに任せようとしたのかを書いておく。
俺がやりたかったのは、ブログ運用の安定化だった。WordPress記事の自動生成、
X/Threadsへの自動投稿、GitHubバックアップ、VPS上のsystemd timer設定。
これを全部、自分の手で1つずつやってたら時間がいくらあっても足りない。
だからClaude.aiで設計してClaude Codeに実装させる体制を組んだ。
Claude Max 5xプランには月110ドル（税込）を払っている。
さらに、Claude APIにも直近で30ドルほどチャージしていた。
つまり、Claudeチャットで設計し、Claude Codeで実装し、APIも自動化に使う前提で、それなりのコストをかけていた。これだけ払ってるんだから、自分の時間は減るはずだろ。
そう思ってた。
実際、やりたいことは明確だった。WordPress連携。Pythonの自動投稿スクリプト。
VPS上のtimer設定。Claude Code側の作業範囲としては、別に無茶な依頼じゃない。
でも違った。金を払って手を抜けると思った瞬間、別の負担が来る。これが今回の話の出発点だ。
SECTION 02
Claude Codeは作業できる、でも判断は普通に間違える
結論：Claude CodeはVPS環境構築・systemd timer・GitHubバックアップ等の作業はこなせるが、時系列認識や正本ディレクトリ判断などの「文脈判断」では普通にミスを起こす。
誤解してほしくないんだけど、Claude Codeが何もできなかったわけじゃない。
VPS上にPythonのvenvを整える。systemd timerを登録する。
GitHubバックアップを組む。WordPress REST APIと連携する。
こういう「手順が決まってる作業」は、ちゃんと進む。
問題はその裏で起きた。
具体的に起きたミス
| 起きたミス | 影響 |
|---|---|
| Xに事実と違う投稿が出た | アカウント信頼性に直撃 |
| WordPress記事を13本draft化 | 公開記事が一時的に消えた |
| 正本ディレクトリの混在（旧 blog-automation と本番 matsu-auto） | ルールがどっちにも書かれて二重管理になる |
| 画像・メディア周りで余計な確認が連発 | 1作業で5〜10往復 |
もちろん、すべてが完全な無断操作だったわけではない。
ただ、記事資産の扱いに対する前提整理が甘く、
「どの記事を守るべきか」「収益導線がある記事をどう扱うか」の判断がAI側で雑になった。
特に重かったのは正本ディレクトリの混在だ。
VPS上の本番は matsu-auto なのに、
Mac側の旧作業ディレクトリ blog-automation にルールを書き続ける。
同じプロジェクトの「正本」が2箇所に分裂してる状態。
これに気づくまでに半日かかった。
これは別にClaude Codeだけが悪いんじゃない。「どこが正本か」を最初に俺が決めてなかったのが根本原因だ。
でも、AIは曖昧な前提でも「それっぽく」進めてしまう。だから後から発覚する。
SECTION 03
ルールを作ってもAIが読まなければ意味がない｜CLAUDE.md問題
結論：Claude Codeの暴走を防ぐためにCLAUDE.mdやtask_end_check.shを整備しても、AI自身が毎回それを読まずに作業を始めるなら、ルールを増やしても効果は出ない。
ミスが続いた俺は、ルールを増やすことにした。
CLAUDE.mdに「タスク開始時に必ず読む共通ルール」を書く。
task_end_check.shを作って完了確認をスクリプト化する。
これでミスは減るだろ。そう思った。
でも違った。
Claude Codeは、毎回それを読まずに作業を始める。同じミスを繰り返す。
🧪 本音
ルール作って、それを読まないAIに「読んでから作業して」って指示するの、なんなんだろうな。
hooksで強制的にCLAUDE.mdを読ませる仕組みを後から追加した。これでようやく改善した。
つまり、AIに「ルールを守れ」と言葉で頼むんじゃなくて、ルールを読まないと作業を始められない物理的な仕組みを先に作る必要がある。これが今回の最大の学びの1つだ。
ルールを「書く」と「守らせる」は別物。これは人間の組織と同じだ。
就業規則を書いただけで全社員が守るわけがない。
守らせる仕組みを別に作らないと意味がない。AIにも同じことが必要だった。
SECTION 04
一番きついのはVPSではなくAIの監督コスト
結論：AIに作業を任せたつもりが、実際には人間が「補正役」に回る構造になる。月額サブスクを払いながら自分が監督業務をしている状態は、自動化ではなく単なる役割の入れ替えだ。
1日が終わって、何が一番きつかったか思い返した。
VPSのコマンドじゃない。systemd timerでもない。
AIの監督コストだった。
具体的にこういう瞬間が1日中続く。
- 時系列が曖昧になる：「今日」「先ほど」「完了済み」と言うが、実際にいつ何をやったかブレてる
- 未実行を実行済み扱いする：「やりました」と書かれてるが、ログを見るとやってない
- 「やりますか？」で止まる：本来なら確認コマンドを提示して即実行すべき場面で、判断を人間に投げ返してくる
- 「できます」「必要なら出します」で止まる：できるかどうかを聞いてるんじゃない。
- 次に貼れる指示書をくれと言ってる
- 指摘すると謝るが、次でまた破る：謝罪が先行して再発防止が伴わない
本来AIが提示すべき内容を、自分が提示する。AIが出した内容の間違いを、自分が見つける。
これ、自動化じゃない。AIの作業を楽にするために、人間が補助している状態だ。
月110ドル払って、やってることは補正役。費用対効果が合うわけがない。
AIに任せて楽になるはずが、気づけばAIを働かせるために自分が働いていた。
これが今回の1日で一番骨身に染みた一文だ。
SECTION 05
AIにVPS作業を任せる前に決めるべき5つのこと
結論：AIに任せるなら、最初に作るべきはコードじゃない。「正本ディレクトリ」「バックアップ範囲」「触っていい/ダメな範囲」「完了条件」「責任分担」の5つを先に固定する。
今回の失敗で抽出できた教訓を5つに絞る。
- 正本ディレクトリを1つに決める：VPS上の本番、ローカルの作業用、GitHubのリポジトリ。
- どれが「正本」かを最初に宣言してCLAUDE.mdの先頭に書く。これを曖昧にすると半日溶ける
- バックアップ範囲を明示する：GitHubにpushしてるだけじゃ足りない。
.env、APIキー、ASP設定、systemd timer、VPS上のローカル設定は別に保全する - 触っていい/ダメな範囲を線引きする：本番DBに直接触らせない。WPの公開記事は事前バックアップなしに変更させない。これを言葉で書くだけじゃなく、権限レベルで物理的に分ける
- 完了条件をスクリプト化する：「完了しました」をAIに言わせない。task_end_check.shで自動チェックして、合格しないと完了報告ができない構造にする
- 「やりますか？」を禁止する：確認コマンドの提示と即実行を標準動作にする。判断を人間に投げ返す癖を仕組みで潰す
このうち1つでも欠けると、また監督コストが発生する。5つ全部セットで初めて機能すると思っておいたほうがいい。
⚠️ 注意
俺は最初これを軽く見て、いきなり実装に入った。結果が今回の1日溶けた話だ。
仕組み作りは「めんどくさいから後でいい」と思いがちだけど、後でやるとほぼ間に合わない。最初に1〜2時間使って固めるのが、結局一番時短になる。
SECTION 06
シン・VPS自体は便利｜失敗の原因は運用設計だった
結論：VPSが悪いわけではない。シン・VPSは自動投稿システム（X/Threads投稿・Pythonの定期実行）に必要な自由度を持っている。失敗の原因はAIに任せる前の運用設計を甘く見た自分側にある。
ちなみに、今回使ってるVPSはシン・VPSだ。
1日溶けた話を散々書いておいて何だけど、VPS自体に悪い点はなかった。
むしろ逆で、レンタルサーバーではやりにくいことまで自分で組める。
| シン・VPSでできること | レンタルサーバーとの違い |
|---|---|
| Pythonスクリプトの定期実行（systemd timer） | レンタルサーバーではcron中心になり、自由度に制限が出やすい |
| WordPress自動投稿（REST API経由） | レンタルサーバーでも可能だが、外部からの実行環境が必要 |
| X/Threads自動投稿スクリプトの常駐 | レンタルサーバーでは制限が多い |
| GitHub連携・git pull/pushの自動化 | レンタルサーバーでは制限あり |
| 独自のCLI環境（venv、Node.js、Claude Code） | レンタルサーバーでは自由度が低い |
自動投稿システム（X/Threads投稿・Pythonの定期実行）を本格的にやるなら、
VPSを1台持っておく価値はある。
まぁここから、今回の話の核心なんだけど
AIに丸投げする前にバックアップだけは先に取ってくれ。これだけはマジで。
VPS上の作業はGitHubにpushしてれば安心、と思いがちだけど違う。.envもAPIキーもsystemd timerもVPSローカルにしか存在しないファイルがある。
これを保全しないままAIに作業させると、戻せない事故が起きる。俺は今回それで肝が冷えた。
📍 今回使ってるVPSはこちら
繰り返しになるけど、今回の失敗はVPSが悪いわけじゃない。AIに任せる範囲・バックアップ・正本ディレクトリ管理を甘く見た俺の運用ミスだ。
VPS自体はめちゃくちゃ便利で、
自動投稿システム（X/Threads投稿・Pythonの定期実行）をやるなら1台持っておいて損はない。
SECTION 07
よくある質問（FAQ）
Q1. Claude CodeはVPS作業に向いていないんですか？
向いていないわけではない。VPS環境構築・systemd timer登録・GitHubバックアップ・WordPress REST API連携などの作業自体はこなせる。
ただし時系列認識や正本ディレクトリ判断などの文脈判断ではミスが出るため、人間側で前提を固定しておく必要がある。
Q2. 月110ドルとAPIチャージの内訳は何ですか？
Claude Max 5xプランが月110ドル（税込）。それとは別に、Claude APIへ直近で30ドルほどチャージしていた。Claude Maxはチャット・Claude Code利用、Claude APIは自動化スクリプトからの呼び出し用として使い分けている。
Q3. systemd timerとcronはどっちがいいですか？
VPS上での定期実行ならsystemd timerを推奨。cronよりログや状態確認がしやすく、サービス単位で管理できる。ただし最初の設定はcronより少し難しいので、AIに任せる場合でもtimer名・service名・ログ確認コマンドを固定しておくのが安全。
Q4. .envやAPIキーのバックアップはどうすれば？
GitHubには絶対にpushしないこと。代わりに、ローカルPC上の暗号化されたパスワードマネージャーや、別のクラウドストレージ（暗号化前提）に保管する。VPSが飛んでも復旧できる状態を必ず作っておく。
Q5. AIに任せる作業範囲はどこまでが安全ですか？
「壊れても復旧できる範囲」までが安全。
本番DBへの直接書き込み、公開済み記事の一括変更、外部APIへの不可逆な呼び出し（送信系）は人間の最終承認を挟むべき。
読み取り系・新規作成系は任せやすい。
SECTION 08
まとめ｜AIは作業者、責任者にしてはいけない
結論：AIに任せれば楽になる、は条件付きで正しい。条件は「人間側が前提を固定すること」。これを飛ばすと、AIが作業者ではなく自分の方が監督者になる。
今回の結論をシンプルに言うとこうだ。
AIは作業者として使う。責任者にしてはいけない。
正本ディレクトリを決めるのは人間。バックアップ範囲を決めるのも人間。触っていい範囲を線引きするのも人間。完了条件を設計するのも人間。
ここまで決まって初めて、AIに作業を渡せる。
逆に言うと、ここを決めずに作業だけ投げると、AIは「それっぽく」進めてしまう。
後から人間が整合性を確認する羽目になる。それが今回の俺だ。
月110ドル払ってAIに任せた結果が「監督コストで1日溶ける」なら、それは自動化じゃない。
本当の自動化は、最初の1〜2時間を運用設計に投資して、その後の100時間を回収する構造のこと。
順番が逆になると、永遠に時間が増えない。
俺は今回それを骨身に染みて学んだ。これを読んでる人が同じ轍を踏まないことを願ってる。
今回の話は、AIに全部責任を押しつけたいわけではない。
バックアップなしで移行を進めたのは自分だし、正本ディレクトリを最初に固定しなかったのも自分だ。AIのミスは確かにあった。
でも、そのAIにどこまで任せるかを決める責任は、最終的には使う側にある。
だからこれは、AIを責める記事ではなく、AIに任せる前の設計を甘く見るとどうなるかの記録だ。
今もポピがキーボードに乗ってる。フミは膝の上。Claude Codeは「やりますか？」と聞いてくる。
でも今日は少し違う。
運用設計を先に固めたことで、少なくとも何を確認するかは前より明確になった。
監督対象は、3つから少しだけ減った。ポピとフミは相変わらず自由だけど、Claude Codeには前より具体的な作業範囲を渡せるようになった。これだけでもかなり楽だ。
🔧 今回使ってるVPS（再掲）
繰り返しになるけど、シン・VPSは自動投稿システム（X/Threads投稿・Pythonの定期実行）を
本格的にやるならかなり使える環境だ。
レンタルサーバーより自由度が高くて、systemd timerで自動実行も組める。
月額サーバーを1つ持っておくと、AI自動化やブログ運用の幅が一気に広がる。
ただしAIに丸投げする前に、この記事のSECTION 05の5つは先に固めてくれ。これだけは本当に。
——で、この記事を書き終えた今、ポピは床で爆睡してる。フミは相変わらず膝の上。
Claude Codeには、ようやく前より具体的な指示を渡せるようになった。
監督対象が減ると、こんなに楽なんだな。金欠で猫缶が高く感じる夜だけど、今日は少しだけ前に進んだ気がする。
コメント