【この記事について】

AIに毎日コンテンツを作らせる運用を、3ヶ月ぶん実際に回しました。

その運用の中身と、壊れた箇所の全部を、記録のまま置いた記事です。

まず、現在地を先に書きます。

・実行ファイル総数：380（うち設計・分析ドキュメント100本、定期実行タスク39本）

・稼働期間：3ヶ月

・この運用から発生した売上：0円

売上0円です。隠しません。むしろ、それが書ける唯一の理由になっています。

世に出ている「AIでこう作れます」は、作り方の話です。

この記事にあるのは、毎日回した結果どうなったか、です。

うまくいった話ではありません。動かなかった仕組み、壊れた工程、

気づくのに6日かかった停止、集計を見ないまま3日ずれた日付。そういう記録です。

━━━━━━━━━━━━━━━━━━━━━━

この記事に書いてあること

━━━━━━━━━━━━━━━━━━━━━━

第1章｜何を毎日回しているか（定期実行タスクの実物）

39本のタスクをどう分けたか。cronの時刻をどう決めたか。

同じブラウザで複数アカウントを触るタスクを同時刻に置いて壊した話と、その直し方。

「組んだのに一度も動いていなかった」を検知する手順。

第2章｜画像つき動画台本を量産する型

1本の台本から、画像生成用プロンプトを機械的に量産する共通テンプレの全文。

カット数を尺から逆算する計算式（5枚固定にすると何が起きるか）。

色トーンの並べ方。テロップの文字数上限。崩れたときの逃げ方。

第3章｜毎日3本の記事を回すワークフロー

トレンドを推測ではなく実測で取る手順（APIのエンドポイントとレスポンスの読み方）。

その日の勝ち型を判定して当日分に反映するまでの流れ。

アカウントを取り違えないための確認手順（実際に取り違えかけた話つき）。

第4章｜品質を落とさない仕組み（自己修正ループ）

作る役と検査する役を分ける構成。検査役に渡す判定基準。

全文を作り直さずに、落ちた箇所だけ直す手順。

「未確認」を「未確認」のまま残すための書き方。

第5章｜壊れた記録（全数）

3ヶ月で壊れたものを、日付つきで全部並べます。

配信が止まった話、6日間動いていなかった仕組み、

同じ失敗を対象を変えて繰り返した話、書いた記事に日付の誤りを出して訂正した話。

━━━━━━━━━━━━━━━━━━━━━━

この記事に書いていないこと

━━━━━━━━━━━━━━━━━━━━━━

・稼ぐ方法は書いていません。売上が0円なので、書けません。

・再現性の保証はしません。これは1つの運用の記録であって、手法の推奨ではありません。

・「これをやれば伸びます」という主張はしません。伸びていないからです。

━━━━━━━━━━━━━━━━━━━━━━

向いている人／向いていない人

━━━━━━━━━━━━━━━━━━━━━━

向いている：

・AIに作業を任せる仕組みを、実際に組もうとしている

・他人がどこで壊したかを先に知って、同じ穴を避けたい

・成功談より、失敗の具体と日付が欲しい

向いていない：

・すぐに収益が出る方法を探している

・きれいにまとまった教科書を求めている

━━━━━━━━━━━━━━━━━━━━━━

価格について

━━━━━━━━━━━━━━━━━━━━━━

発売時点：2,980円

以下の部数に達した時点で、記載のとおり値上げします。

・累計10部　→ 4,980円

・累計30部　→ 9,800円

・累計50部　→ 19,800円

記録は毎日増えます。増えた分は追記します。

追記のたびに内容が増えるため、上の部数で価格を上げます。

早く買った人のほうが安く、以後の追記も同じ価格で読めます。

━━━━━━━━━━━━━━━━━━━━━━

免責事項

━━━━━━━━━━━━━━━━━━━━━━

・本記事は、筆者が実際に行った運用の記録であり、成果を保証するものではありません。

・記載の数値は、記載時点の実測値です。取得できていないものは「未計測」と明記しています。

・本記事の内容を実行した結果生じたいかなる損害についても、筆者は責任を負いません。

・各サービスの仕様・規約は変更される場合があります。実行前に必ず最新の情報をご確認ください。

・本記事の無断転載・再配布を禁止します。

第1章｜何を毎日回しているか

■ 1-1. タスクの分け方

定期実行タスクは39本あります。役割で4つに分けています。

(1) 作る　：台本を書く／記事を書く／ログを書く

(2) 出す　：決まった時刻に公開する

(3) 触る　：他人の投稿に反応して露出を作る

(4) 測る　：数字を取って記録する／週次でまとめる

この分け方には理由があります。(1)(2)は失敗しても静かに失敗します。

(3)(4)は失敗すると数字が動かないので、あとで気づけます。

つまり(4)を持っていないと、(1)〜(3)が全部止まっていても分かりません。

実際に、その状態を6日間続けました（第5章）。

■ 1-2. 時刻の決め方

cronの時刻は「効果的な時間帯」で決めていません。衝突しない順で決めています。

同じブラウザで複数のアカウントを触るタスクを同時刻に置くと壊れます。

ログイン状態が1つしかないので、後から動いたタスクが前のタスクのセッションを奪います。

これで実際にエラーが多発しました。直し方は単純で、30分ずつずらすだけです。

現在の並べ方（同一ブラウザを使うものは必ず30分以上あける）：

07:00　週次の数字計測（月曜のみ）

08:30　週次の入金レビュー（月曜のみ）

09:00　台本作成（月・木のみ）

10:00　記事のトレンド分析＋作成＋公開

12:00　コメント回り（アカウントA）

13:30　スキ回り（アカウントA）

15:00　リサーチ（読むだけ・書き込みなし）

16:30　運用ログ作成（アカウントB）

17:00　スキ回り（アカウントB）

19:00　外部トレース（ログアウト状態で取得）

22:00　日報

15:00のタスクを「読むだけ」にしているのは、書き込みが無ければ

セッションを奪っても被害が出ないからです。衝突しても壊れない工程を、

衝突しやすい時間帯に置く。これが一番効きました。

■ 1-3. 「組んだのに一度も動いていない」を検知する

これが一番高くついた失敗です。手順を書きます。

タスクの実行履歴には「最終実行日時」があります。

組んだ直後は、この欄が空です。動けば日時が入ります。

問題は、空欄が2種類あることです。

(a) まだ実行時刻が来ていない

(b) 実行時刻は来たが、動かなかった

画面上は同じ「空」です。区別する方法は1つだけで、

「次の実行予定時刻」が現在時刻より過去になっているのに、最終実行が空なら(b)です。

これを毎週チェックする手順に入れてください。私は入れていなかったので、

6本のタスクが作成以来1度も動いていないことに、数週間気づきませんでした。

もう1つ。スケジューラの多くはアプリが起動している時しか発火しません。

「組んだから動く」ではなく「起動していた時間に重なった分だけ動く」です。

夜間や休日に組んだタスクは、そもそも実行機会がありません。

対策は、仕組みを作る日に「動いた証拠が残る形」を一緒に決めることです。

動いたら記録が増える。増えていなければ止まっている。

そう判定できる形にしていないものは、動いているかどうか永久に分かりません。