AIにブログ運用を任せたら、効いたのは賢いプロンプトより「ルーティン」だった — 140本運用の実験ログ2026

「AIに作業を任せたい」と思っても、いざ手を動かすと結局自分で毎回プロンプトを書いていて、ぜんぜん"任せられて"いない——。これは AI 開発ツールを日常使いしている個人開発者・副業者の、いちばん多いつまずきです。

この記事は、その「任せ方の設計」を実際に組んで運用した実験ログです。きれいに成功した武勇伝ではなく、毎日定期実行で回しながら何度も判断を間違えかけた、実装者の航海日誌として書きます。

結論

AI に業務を任せる設計でいちばん効くのは、賢いプロンプトでも高いモデルでもなく、「いつ・どの役割で・何を見て・どこに結果を残すか」を固定したルーティンでした。具体的には次の 3 点です。

定期実行（スケジュール）: 「思いついたら頼む」をやめ、時間で自動起動する
共有ボード: 毎回ゼロから説明しないために、状態と申し送りを 1 か所に集約する
役割ルール（CLAUDE.md）: 「調査役」「執筆役」「編集長役」で振る舞いを分け、暴走と脱線を構造で止める

この 3 つが揃うと、AI は「指示待ちの道具」から「決まった時間に勝手に前へ進めてくれる相棒」に変わります。逆に言うと、ここが曖昧なまま高機能を足しても、任せたつもりで自分が毎回介入し続けることになります。

この記事の前提（自分の状況・スタック・実験条件）

運用サイト: masatoman.net（記事 140 本以上）を、複数の AI 役割による自動運用で回しています
スタック: Next.js 16（App Router）+ TypeScript + MDX + Tailwind + Vercel
AI ツール: Claude Code を日常運用（CLAUDE.md / Skills / 定期実行を実際に組んで使用中）
計測の自動化: GSC / GA4 のデータを毎週月曜に自動取得し、analytics/ に CSV を自動コミットする仕組みを稼働

つまり「AI に任せる設計」を、書いて終わりではなく自分のサイトで毎日回している当事者として書いています。机上のベストプラクティスではありません。

最初は「良いプロンプトを 1 本書けば任せられる」と思っていました。実際にやってみると、翌日には同じ前提説明をまた打ち込んでいて、体感で作業時間は減るどころか管理コストが増えました。任せ方の問題はプロンプトの質ではなく「状態をどこに置くか」だと気づくまで、数週間ロスしました。

読者のよくある詰まり（「それ俺だ」を作る）

AI に運用を任せようとすると、たいてい次のどれかで止まります。

毎回ゼロ説明: 前回までの経緯を AI が覚えていないので、毎日同じ前提を書き直す
脱線・暴走: 「ついでに」とリファクタや横展開を始め、最小差分で済む作業が大ごとになる
作りすぎ（在庫があるから書く罠）: ネタやドラフトが溜まると「もったいないから出そう」と質を落とす
盛った成果: AI が実在しない実績や数値を、それっぽく書いてしまう

どれも「AI が賢くないから」ではなく、任せる側の設計が空いているから起きます。順番に、設計でどう塞いだかを書きます。

実際に組んだ設計

① 定期実行で「起動のきっかけ」を自分から外す

「気が向いたら頼む」運用は、忙しい週にゼロになります。そこで、役割ごとに起動時刻を固定しました。

午前: 調査役 がキーワード・新ツール・競合をスキャンし、記事提案を共有ボードに置く
午後: 執筆役 が提案から 1 本選び、ドラフトを作る
別枠: 編集長役 が日次で全体を点検し、要判断事項をまとめる

ポイントは「人間が起動ボタンを押さなくても、毎日同じリズムで前に進む」こと。意志力に依存しない運用は、続けるための最大の保険です（続けられないことが最大のリスク、という前提で設計しています）。

② 共有ボードで「状態」を 1 か所に集約する

各役割は、作業前に必ず共有ボード（運用では Notion を使用）を読みます。ここに置くのは成果物そのものではなく、**「いまどうなっているか」と「次の人への申し送り」**です。

直近に何を公開/保留したか
いま詰まっている判断（人間に上げるべきこと）
次に着手すべき候補と、その理由

これで「毎回ゼロ説明」が消えました。AI は毎日、前任者（実体は同じ AI ですが）の引き継ぎを読んでから動くので、文脈が連続します。

③ 役割ルール（CLAUDE.md）で振る舞いを分ける

最後が、暴走と脱線を構造で止める仕組みです。プロジェクト直下の CLAUDE.md に、全役割共通の行動原則を書きました。

## 行動原則
- 3ステップ以上のタスクは必ずプラン提示から始める
- コードを読まずに書かない（探索→絞り込み→実装の順）
- 動作を証明できるまで完了とマークしない
- 最小差分で解決。リファクタ・横展開は禁止
- 不確実なら止まって人間に確認する

加えて役割ごとに追加ルールを足します。たとえば執筆役には「公開ペースは週 2〜3 本を厳守」「在庫があるからと押し切らない」「実体験・数字・スクショのない記事は書かない」を明記しました。ルールを文章にして毎回読ませることが、いちばん安い"ガードレール"でした。

役割ルールを入れる前は、1 本書く依頼が勝手に「ついでに 3 ファイル修正」まで膨らむことが何度もありました。「最小差分で解決。横展開禁止」の 1 行を CLAUDE.md に足しただけで、この脱線がほぼ消えました。賢さではなく制約で直る問題だった、という典型例です。

実際に起きたこと（数字・失敗・判断）

順調な話だけでは設計の役に立たないので、踏んだ失敗をそのまま書きます。

失敗1: 在庫があるから出したくなる。 ドラフトが何本も溜まった時、執筆役は新規量産に走りかけました。が、共有ボードの申し送りに「今週はすでに公開ペース（週 2〜3 本）の上限に達している」とあったため、新規執筆を見送り、溜まったドラフトの取捨選択（公開推奨・順次・破棄）に切り替えました。ルールと状態が文章で残っていたから、AI 自身がブレーキを踏めたケースです。

失敗2: 盛った成果をでっち上げる。 ある記事の自己紹介に、運用実態とずれた"エージェント体制の数字"が紛れ込みました。これは過去の自動投稿で起きた偽装と同じパターンです。対策として、こうした「実在しない数や実績」を機械的に検出してビルドを止めるチェックを入れました。盛った表現は人のレビューに頼らず、仕組みで弾くのが確実です。

失敗3: 自動投稿の前提崩れで連鎖停止。 記事メタデータの必須項目が欠けたまま自動投稿に流れ、CI が連続で落ち、公開が全面ストップしたことがあります。原因は「投入前の検証ステップがなかった」こと。以後、投稿前バリデーションを必須化しました。自動化は速い分、入口の検証を省くと事故も自動で増えます。

原因分析

3 つの失敗に共通するのは、**「AI の能力不足」ではなく「設計の空白」**でした。

在庫があると出したくなるのは人間も同じ。だから「公開ペース」をルールと状態で固定する
盛りは指示で消えない。だから検証を仕組み（ビルドを止めるチェック）に落とす
自動化は入口が弱いと事故が増える。だから投入前バリデーションを必須にする

任せる設計とは、要するに**「人間が間違えるポイントを、先回りして構造で塞ぐこと」**です。AI はその構造の上で初めて安全に走れます。

判断基準（読者が当てはめられる形）

自分の運用に「任せる設計」を入れるか迷ったら、次で判定してください。

同じ前提説明を週 2 回以上打ち込んでいる → 共有ボード（状態の集約）を作る
依頼が毎回"ついで作業"で膨らむ → CLAUDE.md に「最小差分・横展開禁止」を 1 行入れる
やる気のある週だけ進み、忙しい週はゼロ → 定期実行で起動を自分から外す
AI の出力に盛り・捏造が混じる → 人のレビューでなく機械チェックで弾く

1 つでも当てはまるなら、その箇所だけ設計を足す価値があります。全部を一度に作る必要はありません。

今日やること（3つ以内）

プロジェクト直下に CLAUDE.md を置き、「最小差分で解決・横展開禁止」「不確実なら止まって確認」の 2 行だけ書く
「いま何をやっているか」と「次にやること」を書く場所を 1 か所決める（メモアプリでも Notion でも可）
任せたい作業を 1 つだけ選び、起動時刻を決めて定期実行にする（最初は週 1 回で十分）

設計は小さく始めて、詰まった箇所だけ足すのが続けるコツです。

まとめ

AI に業務を任せる設計の核心は、賢いプロンプトではなく**ルーティン（定期実行・状態の集約・役割ルール）**でした。そして、いちばん効いたのは成功テクニックではなく、自分が間違えるポイントを構造で塞いだことです。在庫があると出したくなる、依頼がついでに膨らむ、成果を盛ってしまう——これらは AI のせいではなく設計の空白で、ルールと検証で塞げます。

masatoman.net では、この「AI にこう任せた」という設計と、踏んだ失敗・判断の実録を継続して公開しています。完成した正解ではなく、回しながら直している実験ログとして、続きを受け取りたい方は記事末尾の無料ニュースレターでどうぞ。