AIツール比較ガイド
【40記事到達】個人ブログをAIの役割分担で回した運用レポート2026|分業体制・予約公開の仕組み・月額$20の実コスト・失速と立て直しの全記録
本記事の立場と免責: 本記事は当サイト(aikatsulab.com)の運用記録にもとづく実体験型の記事で、アフィリエイトリンクは1本も含みません。断定するのは公開本数・公開日・運用体制・実際に課金しているClaude Proの費用など、当サイト内で検証できる範囲に限ります。1本あたりの作業時間は計測していないため、時間数は公開していません。 運営者はClaudeの上位プランおよびレンタルサーバー各社を未契約で、それらは公式情報の参照に留めます。掲載データは当サイト1件の事例であり、同じ結果になることや収益・検索順位を保証するものではありません。料金・仕様は2026年7月時点のため、各公式ページで最新をご確認ください。
30秒で読める結論
40記事は「頑張って書き続けた」結果ではなく、途中で一度止まってから体制を作り直した結果です。 きれいな右肩上がりではありません。
- 🟢 2026年5月6日から7月25日までの80日間で40本。内訳は5月28本 / 6月5本 / 7月7本で、6月に大きく失速しています
- 🟢 立ち上げ期はAIに1人で全部やらせていました。20本を超えたあたりで限界が出て、役割別のサブエージェントによる分業へ切り替えています
- 🟢 失速から立て直した決定打は書く量ではなく、pubDate(公開日)を先出しする予約公開でした。書く日と出す日を分離しています
- 🟢 実コストはClaude Proの月額20ドル、80日で約2.5か月分。ほかは独自ドメイン代とホスティングの無料枠のみです
- 🟡 サブエージェントの一般的な仕組みは公式ドキュメントの記載にもとづく説明で、当サイトが検証しているのはClaude Pro環境での運用のみです
なお、本記事は続編です。前編にあたる3週間で19記事を書いた立ち上げ記録では、ドメイン取得からサイト構築、最初のつまずき7件までを扱っています。本記事はそこから先、19本が40本になる過程で何が壊れて何を直したかだけを書きます。立ち上げ手順そのものは前編に譲るので、これから始める方は先に前編をお読みください。
1. 40記事到達までの全体タイムライン|2026年5月6日〜7月25日の80日間
先に数字を出します。当サイトの記事はすべて公開日つきのファイルとして残っているので、後から数え直せます。
1-1. 月別の公開本数
| 月 | 公開本数 | 累計 | その月の状態 |
|---|---|---|---|
| 2026年5月 | 28本 | 28本 | 立ち上げ。ほぼ毎日公開 |
| 2026年6月 | 5本 | 33本 | 失速期。週1本前後まで低下 |
| 2026年7月 | 7本(本記事含む) | 40本 | 体制を作り直して再開 |
80日間で40本なので、単純平均は2日に1本です。ただしこの平均値には意味がありません。実態は「28本 → 5本 → 7本」で、真ん中が抜けています。
1-2. 5月に28本出せた理由と、その裏側
5月は新しいものを立ち上げた直後で、書きたいテーマの在庫がありました。しかも工程を分けておらず、思いついたら書いて、書いたらその日にそのまま公開していました。速度だけ見れば、この時期がいちばん出ています。
ただしこの28本は、後から見るとあとで直すことになった記述をいちばん多く含んだ塊でもあります。速く出すことと、直さずに済むことは別でした。この点は第6セクションで詳しく書きます。
1-3. 6月に5本まで落ちた理由(ここを正直に書きます)
6月は5本です。5月の6分の1以下まで落ちました。
理由は、書けなくなったからではありません。書いた日にそのまま公開する運用だったので、書けない週がそのまま更新の空白になったからです。当サイトの運営者は別の仕事と並行して運用しており、まとまった時間が取れる週と取れない週の差がかなり激しい。5月は取れて、6月は取れませんでした。
ここで重要なのは、5月末の時点で在庫がなかったわけではないという点です。書いたものはありました。出す仕組みのほうが手作業に依存していたので、手が空かない=更新が止まる、という構造になっていただけです。
多くの運用ログは、この失速期を書きません。書くと格好がつかないからです。ただ、20〜30本書いた人がいちばん知りたいのは「順調な人がどう順調だったか」ではなく、止まった人がどう再開したかのはずです。当サイトも止まりました。
1-4. 7月に安定した理由
7月は7本です。5月の勢いには戻っていませんが、週2本前後で揺れなくなりました。
変えたのは執筆量ではなく、体制です。具体的には次の2つで、それぞれ第2・第4セクションで扱います。
- 役割別のサブエージェントに工程を分けた(品質のブレと抜けを減らす)
- pubDateを先出しして予約公開に切り替えた(書く日と出す日を分ける)
つまり40記事到達は、「80日間走り続けた記録」ではなく、**「一度止まってから、止まらない形に作り直した記録」**です。以降はその中身を書きます。
1-5. この推移から読み取れること
もう一度3つの数字を並べます。28 → 5 → 7。
このグラフを見て「7月は5月より少ないのだから後退している」と読むこともできます。ただ、当サイトの実感としては逆です。5月の28本は、続けられないペースで出していただけでした。実際、翌月に続きませんでした。7月の7本は、いまの生活と並行して続けられる範囲の数字です。
もし5月と同じやり方を続けていたら、6月の失速のあとに戻ってこられなかった可能性のほうが高いと思っています。ブログ運営でよく言われる「毎日更新」は、更新できる状態が続く前提の話です。続かない前提の人にとって重要なのは、速度ではなく復帰のしやすさでした。
数字の見方をもう1つ。80日で40本というのは、1本あたり2日です。ただしこれは「1本を2日で書いている」という意味ではありません。5段階の工程が複数本ぶん並行して流れた結果を、後から日数で割っただけの数字です。1本を最初から最後まで追いかけた場合の所要日数は計測していないので書けませんが、並行しているぶん、割り算の結果より長くかかります。この2つを混同すると、必要な時間を見誤ります。
なお本記事では、PV・収益・検索順位の数値は一切扱いません。公開本数と体制の記録であって、成果の記録ではないからです。
2. 単独運用から役割分担へ|なぜ1人のAIに全部やらせるのをやめたか
2-1. 立ち上げ期は「1人のAIに全部」でした
前編の時点、つまり19記事目までは、Claude Codeに逐次で全部やらせていました。「このテーマで記事を書いて」と投げて、検索語も構成も本文も同じ流れの中で作らせる。19本まではこれで回りました。
回らなくなったのは20本を超えたあたりです。原因は3つあり、どれも記事数が増えたことで顕在化しています。
2-2. 限界その1|文脈の混線
1つの流れの中で「検索語を調べる」「構成を決める」「本文を書く」を全部やらせると、手前の作業の情報が後ろの作業に混ざります。
具体的には、検索語の調査中に見た他サイトの表現が、そのまま本文の言い回しに引きずられて出てくる。あるいは構成段階で「この記事は初心者向け」と決めたはずなのに、執筆に入る頃には調査時に見た専門的な記述に寄っていく。1本ずつ見れば些細ですが、20本を超えるとサイト全体の粒度がバラバラになっていきました。
2-3. 限界その2|品質基準のブレ
同じ「記事を書いて」という指示でも、出てくるものが日によって違いました。見出しの数、表の使い方、1段落の長さ、結論を先に置くかどうか。
これは指示が悪いのですが、指示を毎回細かく書くほうが破綻します。人間側が毎回思い出して書かなければならないからです。20本目あたりで「前はどう指定したんだっけ」と過去の記事を見返す時間が増え始めました。これは工程を分ける前の典型的な症状だったと思います。
2-4. 限界その3|法令面の観点が抜ける
いちばん深刻だったのがこれです。
執筆に集中している流れの中では、表現の適法性チェックが後回しになります。 「実際に使っていないツールを、使ったかのような書き方にしていないか」「効果を保証する言い方になっていないか」といった観点は、書くことと同時にはやりにくい。人間でも同じですが、AIに一気通貫でやらせると同じことが起きました。
結果として、後から読み返して直すべき記述が出ました。これも第6セクションで扱います。
2-5. 分けた単位|人格ではなく工程で切る
そこで、Claude Codeのサブエージェント機能を使い、工程単位で役割を分けました。 分けたのは次の6つです。
| 役割 | 担当する工程 | 主な成果物 |
|---|---|---|
| 検索語の調査 | 狙う語の選定、検索結果の実査 | 調査メモ |
| 構成の設計 | 見出し構成、記事内の情報配置 | 構成案ファイル |
| 本文の執筆 | 原稿作成 | 記事ファイル |
| 法令面の点検 | 表現リスクの洗い出し | 指摘リスト |
| 技術実装 | サイト側の反映、内部リンク整備 | コード変更 |
| 編集判断 | 出す/出さないの最終判断 | 可否 |
ここで意識したのは、人格を作るのではなく工程で切るということです。「調査担当」「執筆担当」のように、その役割が何をするかだけを定義する。キャラクター性を持たせても出力の質は上がりませんでした。上がったのは、担当ごとに前提と禁止事項を書き分けられるようになったことによる効果です。
たとえば執筆担当には「実際に契約していないサービスを一人称で語らない」と書いておけば、毎回指示しなくてもその制約がかかります。法令点検担当には「本文を書き直すのではなく指摘だけ返す」と書いておけば、勝手に書き換えられずに済みます。
もう1つ、分けてみて初めてわかったことがあります。役割ごとに「やらないこと」を書くほうが、「やること」を書くより効きました。 「良い構成を作ってください」は指示として機能しませんが、「本文は書かないでください」「見出しは9本までにしてください」のような具体的な禁止のほうが、当サイトの範囲では守られやすいという実感があります。工程を切るというのは、実質的に禁止事項を配置する作業でした。
そしてこの分業には、副作用もあります。工程が増えるので、1本あたりの往復回数は増えました。 単独運用のときは1回のやり取りで下書きが出ていたものが、いまは調査・構成・執筆・点検と工程の数だけ段階を踏みます。速度だけを見れば、分業は遅いです。それでも戻さなかったのは、後から直す作業のほうが負担が大きかったからです。5月の28本と7月の7本を比べたとき、後から手を入れた回数は7月のほうが少ないと感じていますが、回数を記録して比較したわけではないので、あくまで実感です。
2-6. 🟡 サブエージェントの一般的な仕組み
Claude Codeの公式ドキュメントによれば、サブエージェントはそれぞれ独立したコンテキストを持ち、専用のシステムプロンプトと使用可能ツールを定義できるとされています。並列に実行させることも可能とされており、本記事で書いている「文脈の混線が減った」という体感は、この独立コンテキストの性質に由来するものと考えています。
ただし、これはあくまで当サイトがClaude Pro環境で運用した範囲の話です。他の環境や他のツールで同じ挙動になるかは検証していません。運用環境そのものの構成はAIで個人ブログを実際に構築・運営した記録にまとめています。
3. 記事1本が公開されるまでのパイプライン|5段階の実フロー
分業体制にした後、記事1本は必ず次の5段階を通ります。飛ばしません。
3-1. 5段階の全体像
| 段階 | やること | 残る成果物 |
|---|---|---|
| ① 検索語の選定と実査 | 狙う語を決め、実際に検索して上位の顔ぶれを見る | 調査メモ |
| ② 構成の設計 | 見出し構成、扱う数値、内部リンクの配置を決める | 構成案ファイル |
| ③ 本文の執筆 | 構成案に沿って原稿を書く | 記事ファイル |
| ④ 法令面の点検 | 表現リスクを洗い出して指摘を返す | 指摘リストと修正 |
| ⑤ 公開 | サイトへ反映し、公開日を設定する | 公開済み記事 |
3-2. 各段階の成果物をファイルとして残している理由
この設計でいちばん効いたのは、①と②の成果物を、頭の中ではなくファイルとして残すことでした。
理由は単純で、AIとの作業はセッションが切れると文脈が消えるからです。今日調べた検索結果の話を、明日の執筆時に相手は覚えていません。ファイルとして残しておけば、翌日の執筆担当に「このファイルを読んでから書いて」と渡せます。
当サイトでは構成案をサイト内のドキュメント用ディレクトリにMarkdownで出力しており、執筆担当は必ずそれを全文読んでから着手します。この一手間で、「構成では初心者向けと決めたのに本文が中級者向けになる」というズレがほぼ消えました。
3-3. 段階①の中身|検索語を決めるだけでは足りない
段階①は、狙う語を決めて終わりではありません。実際に検索して、上位に並んでいるのがどういう性格のページかを見るところまでが1セットです。
上位が企業のサービス紹介ページで埋まっている語は、個人ブログの新規記事が同じ土俵で戦っても届きにくい。逆に、上位が「機能の説明」ばかりで「実際に長く運用した記録」が無い語には、まだ入る余地があります。本記事もその判断で狙う語を決めており、当初の候補は途中で差し替えています。
この段階でテーマそのものを捨てることもあります。テーマを出す工程と、出したテーマを捨てる基準についてはブログのネタ切れをAIで解消する方法に、書くと決まった後の執筆手順の原型はブログ運営者向けAIワークフロー完全ガイドにまとめています。この2本と本記事の関係は、「何を書くか」「どう書くか」「どう回し続けるか」の3層です。
3-4. 段階④を独立させたことがいちばん効いた
5段階のうち、後から追加したのが④の法令面の点検です。
執筆担当とは別の担当が、書き上がった原稿を読んで、リスクのある表現を指摘だけ返す。書き直しはしません。指摘を受けて直すのは執筆担当です。この分離が重要で、点検担当に書き直す権限を持たせると、指摘の粒度が落ちて「なんとなく直っている」状態になります。
点検の観点は、当サイトで独自に定めた品質チェック項目に沿って毎回同じものを見ます。項目を固定しているので、記事ごとに見落としの内容が変わることがありません。
3-5. 人間(運営者)が介入するのは2箇所だけ
正直に線を引いておくと、この5段階のうち人間が必ず入るのは2箇所です。
- 段階②の後: この構成で書く価値があるか、テーマの筋が良いかを判断する
- 段階⑤の前: 出すか出さないかの最終判断
逆に言えば、それ以外は任せています。ただしこの2箇所は、後の第7セクションで書くとおり、任せようとして失敗した箇所でもあります。
3-6. この5段階を「飛ばしたくなる」ときの話
正直に書くと、この5段階は毎回きちんと回せているわけではありません。時間がないとき、いちばん飛ばしたくなるのは**段階①(検索語の実査)**です。テーマはもう決まっているのだから、そのまま構成に入ればいいと思ってしまう。
しかし実際に飛ばした回があり、そのときは構成段階で手戻りしました。上位に並んでいるページの性格を見ないまま構成を組むと、読者がその語で何を求めているかの想定が、書き手の思い込みだけで決まります。 結果、書き上がってから「これは求められているものと違うのでは」となる。手前を省いた分が、後ろで倍になって返ってきました。
もう1つ飛ばしたくなるのが**段階④(法令面の点検)です。こちらは第4セクションで書く予約公開に切り替えたことで、構造的に飛ばせなくなりました。公開日が数日先にあるので、点検を挟んでも間に合うからです。「飛ばしたくなる工程は、意志ではなく仕組みで守る」**というのが、ここでの学びでした。
4. 予約公開の仕組み|pubDateを先出しして公開ペースを一定に保つ
失速からの立て直しで、いちばん効いたのがこれです。
4-1. 何をしているか
当サイトはAstroで構築しており、記事はMarkdownファイルの先頭にpubDate(公開日)を書きます。ここに未来の日付を入れておくと、その記事はサイト上ではまだ公開されず、指定日を過ぎたビルドで初めて表示されます。
つまり、書いた日と、読者に出る日を分離できます。
pubDate: 2026-07-25 ← 書いたのは7月19日でも、表示は7月25日からやっていることはこれだけです。仕組みとしては何も複雑ではありません。
4-2. なぜこれが失速に効いたのか
第1セクションで書いたとおり、6月の失速の原因は「書けない週がそのまま更新の空白になる」構造でした。
pubDateを先出しすると、この構造が変わります。時間が取れる週に3〜4本まとめて書き、公開日を数日おきに振り分けておけば、次に手が空かない週が来ても更新は続きます。 書く量の波と、出る量の波を切り離せるわけです。
実際、7月に週2本前後で安定したのは執筆量が均されたからではありません。執筆量は相変わらず波があります。 出方だけが均されました。ここは実際に運用してみて、はっきり因果があったと言い切れる部分です。
心理面の効果もありました。書いた日にそのまま出す運用だと、更新が止まった週は「今週も出せなかった」がそのまま可視化されます。これが続くと、再開そのものが億劫になる。予約公開に切り替えてからは、書けない週にも記事は出ているので、止まっている感覚がそもそも発生しません。 復帰のコストが下がったのはこの部分が大きいと感じています。
4-3. 運用上の注意点(いいことばかりではありません)
いいことばかりではないので、実際に困った点も書いておきます。
先の日付を埋めすぎると、内容が古くなります。 一度2週間先まで公開日を確保したことがありますが、その間に扱っているツールの仕様が変わり、公開前に書き直す羽目になりました。いまは先1週間程度までにしています。
公開日の重複に気づきにくいという点もあります。同じ日付を2本に振ってしまうと、その日は2本出て、次の日はゼロになる。ファイルを個別に書いているとこれが起きるので、公開予定日は一覧で確認するようにしています。
4-4. 副次的な効果|直す時間ができた
もう1つ、想定していなかった効果がありました。書いてから公開されるまでに数日の猶予ができるので、その間に法令面の点検を通せます。
5月の毎日公開期は、書いたその日に出していたので、点検の時間が構造的に存在しませんでした。予約公開に切り替えたことで、点検工程を挟んでも公開ペースが落ちなくなっています。第6セクションで書く修正の多くは、この猶予があったから見つかったものです。
4-5. 🟡 一般的なCMSの予約投稿との違い
WordPressなどのCMSにも予約投稿機能があり、指定日時に自動で公開される仕組みが標準で用意されているとされています。読者から見た結果は同じですが、当サイトの場合は記事ファイル内の日付という形で、公開日そのものがバージョン管理の対象になります。いつ何を出す予定かが、ファイルを見れば全部わかる状態です。
なお、当サイトは静的サイトをCloudflare Pagesでホスティングしており、レンタルサーバーは使っていません(運営者は各社を未契約です)。したがって本記事の仕組みは、レンタルサーバー+WordPressで始める方にはそのままは移植できません。その構成で始める場合のサーバー選びはConoHa WINGとエックスサーバーの比較で公式情報ベースに整理しています。
5. 月額$20で40記事|2ヶ月半の実コスト構造
5-1. かかった費用の内訳
数字だけ並べます。
| 項目 | 金額 | 備考 |
|---|---|---|
| Claude Pro | $20/月 | 実際に課金しているプラン |
| 上記の80日分 | 約2.5か月 = 約$50 | 2026年5月〜7月 |
| 独自ドメイン | 年額(取得先により変動) | 前編で取得済み |
| Cloudflare Pages | $0 | 無料枠の範囲で運用 |
| 有料テーマ・有料ツール | $0 | 導入していない |
上記はいずれも2026年7月時点で運営者が実際に支払っている、または支払っていない金額です。料金体系は変更され得るため、契約前に各社の公式ページで最新をご確認ください。
5-2. 1記事あたりの固定費換算
40記事に対して、AIツールの費用は約$50です。単純に割ると1記事あたり約$1.25になります。
この数字はそれ以上でも以下でもありません。割り算の結果であって、記事の価値や費用対効果を示すものではないという点は明確にしておきます。同じ$50でも書けた本数が10本なら1記事$5です。ここで比較すべき対象は本来、金額ではなく次項の作業時間のほうです。
上記の換算は当サイト1件の実績にもとづく単純計算です。作業時間や記事の内容は考慮していません。
5-3. 併記すべき前提|かかっているのはお金より時間です
「月$20で40記事」という書き方だけを見ると、費用だけで記事ができるように読めます。実態は違います。
ただし、当サイトは1本あたりの作業時間を計測していません。 ストップウォッチで測った記録がないので、ここに具体的な時間数を書くことはできません。書けるのは中身のほうです。人間側が実際に手を動かしているのは、第3セクションで書いたとおりテーマの筋の判断と、公開可否の判断の2箇所で、調査・構成・執筆・点検の各工程は主にAI側の実行に任せています。つまり人間の関与は「長時間ずっと張り付く」形ではなく、要所で判断を差し込む形です。
とはいえゼロではありません。テーマがうまく決まらない回や、点検の指摘が多く出た回は、そのぶん人間側の往復が増えます。ここを書かずに金額だけ出すのは不誠実だと思うので、計測していないという事実も含めて併記します。
つまり正確には「月$20と、計測していないが確実に存在する人間側の判断時間で40記事」です。所要時間は書き手の慣れ・テーマの調査量・並行している仕事の状況で変わるため、当サイトの体感をそのまま他の方の見積もりに使うことはできません。
5-4. 🟡 上位プランを検討していない理由
Claudeには上位プラン(Max等)が用意されており、利用可能量が拡張されるとされています。ただし運営者はこれらを未契約のため、実際にどの程度作業効率が変わるかは書けません。料金と提供内容は公式サイトでご確認ください。
現状Proで足りている、というのが正直なところです。ボトルネックになっているのは利用量ではなく、前項のとおり人間側の判断時間だからです。AIツールの費用を全体としてどう配分するかという視点はAIサブスクの組み合わせと固定費の考え方にまとめています。
6. 40本規模で壊れた5箇所と、その修正履歴
ここが本記事の中心です。
先に前提を書きます。以下に挙げるのは、当サイト内部の法令点検工程で自ら見つけて予防的に修正したものであり、第三者からの指摘や行政処分を受けたものではありません。また、前編で書いた立ち上げ期のつまずき7件とは重複しない、記事数が増えたことで初めて出た事象だけを扱います。
6-1. 内部リンクの張り忘れと張り過多が同時に起きた
10本の頃は、新記事から既存記事へのリンクは手で全部把握できました。40本になると無理です。
起きたことは2つで、方向が逆です。新しい記事から古い記事へは張られるのに、古い記事から新しい記事へ張り直す作業が漏れる。 その結果、初期の記事だけがサイトの中で孤立していきました。逆に、書きやすい記事(1本で全体を見渡すタイプの記事)にはリンクが集中しすぎ、1記事に十数本以上が張られている状態も発生しました。
修正: 記事の役割を「入口になる記事」と「個別テーマの記事」に分け、どちらからどちらへ張るかの方向を決めました。あわせて、新記事を出したら既存記事側へも張り返す作業を、公開工程(段階⑤)の中に組み込んでいます。
6-2. 似たテーマが続けて出て、記事同士が食い合いかけた
テーマを在庫として持っていると、書きやすいものから手が伸びます。その結果、同じ系統の記事が短期間に連続して出そうになりました。
これは単に読者から見て単調というだけでなく、記事同士が同じ検索語を取りに行って共倒れするリスクがあります。
修正: 記事番号と紐づけて「この番号を消化したら次はこの系統」という順番を先に決め、同じ系統が連続しないようにしました。7月の7本は、この順番に沿って出しています。
6-3. 使っていないツールを、使っているかのように書きかけた
いちばん重い事象です。
AIに執筆させると、実際に契約していないサービスについても、体験談の調子で書けてしまいます。 文章としては自然なので、読み流すと気づきません。しかしこれは、読者に「運営者が使っている」と誤解させる書き方です。当サイトの法令点検工程でこの傾向が複数記事で見つかり、予防的に修正しました。
修正: 全記事の執筆前に、扱う情報を3段階で分類することを前置きにしました。
| 区分 | 対象 | 書き方 |
|---|---|---|
| 断定してよい | 自分で実際に課金・運用しているもの | 一人称の実体験として書く |
| ヘッジが必要 | 公式情報のみで確認したもの、契約していないもの | 出典を示し、断定しない |
| 書かない | 検証も出典確認もできないもの | 扱わない |
この分類を執筆担当への前提として毎回渡すようにしてから、同種の指摘は大きく減りました。執筆後に直すのではなく、書く前に区分を確定させておくことがポイントです。生成物を扱ううえでの権利面の判断はAI生成物の著作権と商用利用の考え方に、業務にAIを組み込む全体像は業務効率化に使うAIツールの全体像にまとめています。
6-4. セッションをまたぐと、前回の判断が消える
AIとの作業は、セッションが切れると文脈が失われます。40本規模になると、「なぜこの記事はこの構成にしたのか」「なぜこのテーマは書かないと決めたのか」といった過去の判断が、次のセッションに引き継がれません。
結果として、一度捨てたテーマを数週間後にまた検討し始めるという無駄が発生しました。
修正: 判断の結果を必ずファイルに残す運用にしました。構成案、捨てたテーマとその理由、次にやることの引き継ぎメモ。次のセッションはこれを読んでから始まります。第3セクションで書いた「成果物をファイルとして残す」設計は、この事象への対応でもあります。
6-5. そして失速期そのもの
5つ目は、第1セクションで書いた6月の失速です。これも「壊れた箇所」として数えます。
修正: 第4セクションのpubDate予約公開への切り替え。書く日と出す日を分離しました。
6-6. まとめると
5件のうち、技術的な問題は1件もありません。全部、記事が増えたことで人間側またはAI側の管理が追いつかなくなった、運用設計の問題です。ここが40本規模で学んだいちばん大きいことでした。
立ち上げ期に困ったのはサイトが動くかどうかでした。40本規模で困ったのは、書いたものが増えたあとに、それを管理し続けられるかどうかです。困りごとの種類が完全に入れ替わっています。前編を読み返すと、そこに書いてあるつまずきは1件も再発していません。代わりに、当時は存在すらしなかった問題が5件出ました。
言い換えると、サイトを作る難しさと、サイトを運用し続ける難しさは別物です。 これから始める方にとって、この記事より前編のほうが役に立ちます。逆に、すでに20本書いていて手が回らなくなっている方には、この5件のほうが自分の状況に近いはずです。
7. 役割分担が効いた領域・効かなかった領域
分業体制を「うまくいきました」で終わらせると、実態と違います。効かなかった領域のほうが、たぶん読む価値があります。
7-1. 効いた領域
① 法令面の抜けが減った これがいちばん大きい効果です。執筆と点検を別の担当に分けただけで、書き手が自分の文章をチェックするという構造的に無理のある作業がなくなりました。
② 構成の品質が安定した 構成を専任の工程にしたことで、記事ごとの粒度のブレが減りました。毎回同じ観点で構成が組まれるので、後から読み返したときの一貫性が明らかに変わっています。
③ 並行して進められる ある記事の執筆中に、別の記事の検索語調査を進められます。5段階が独立しているからこそできることで、7月のペース安定にも寄与しています。
④ 過去の判断を引き継げるようになった これは分業そのものというより、分業のために成果物をファイル化した副産物です。1か月前に「なぜこの構成にしたか」を後から読めるので、同じ検討を繰り返さなくなりました。単独運用のときは、この情報は全部その場限りで消えていました。
7-2. 効かなかった領域
① 最終的な編集判断 「この記事を出すか出さないか」は、任せられませんでした。AIは渡された構成に対して最善を尽くしますが、「そもそもこれを出すべきか」の判断はサイト全体の状況を見て決めるもので、記事単位の視点からは出てきません。
② テーマの筋の良し悪し 検索語の調査は任せられます。しかし「この語は数字上は取れそうだが、うちが書くと薄くなる」という判断は、最後まで人間側に残りました。書き手が何を持っているかを知っているのは書き手だけです。
③ 実体験があるかどうかの判定 第6セクションの3つ目と同じ問題です。そのサービスを本当に使ったことがあるかは、AI側からは判定できません。 契約状況を知っているのは運営者だけなので、ここは構造的に人間が持つしかない情報です。
7-3. わかったこと|自動化できるのは工程で、判断ではない
3つ並べてみると共通点があります。効かなかったのは全部、**「外部の情報ではなく、自分の状況を知らないと決められないこと」**でした。
工程は分けられます。作業は渡せます。しかし、事業として何をやるかの判断は渡せません。 これは別分野でも同じで、当サイトの運営者は同時期に100名規模の交替制シフト勤務組織向けの業務アプリも開発していますが、そちらでも実装は任せられる一方、「現場が本当に困っているのはどこか」の判断は現地を知っている人間の側に残りました。
事業としての形を整える手続きまわりはマネーフォワードで開業届を出した記録に、作業時間を単価としてどう見るかは文字起こし副業の単価と時間の考え方にまとめています。後者の「時間あたりいくらで見るか」という視点は、第5セクションのコスト換算を読むときの補助線になるはずです。
8. これから体制を作る人への現実的な順序
ここまで読んで「じゃあ最初から分業体制で始めればいい」と思われるかもしれませんが、それは勧めません。 当サイトは19本を単独運用で書いてから分けています。この順序には理由があります。
8-1. 先に1本を通しで書く
分業とは、工程を切って、それぞれに前提と禁止事項を渡すことです。その前提を書けるようになるには、自分で一度通しでやってみるしかありません。
何も書かないうちに役割を分けると、それぞれの役割に何を指示すべきかがわからず、結局「いい感じに書いて」を6回繰り返すことになります。これは分業ではなく、単に工程が増えただけです。
まず1本、自分で通しで書く。そのときに引っかかったこと、直したくなったことを、そのまま言語化して次の指示に入れる。これが最短だと思います。
当サイトの役割定義に書いてある内容も、ほとんどが実際に困ってから追記されたものです。最初から設計したわけではありません。「1段落は2〜4文まで」という指定は、読みにくい原稿が出てきた日に足しました。「断定的な最大表現を使わない」という指定は、点検で指摘が出た日に足しました。役割定義は、失敗の履歴が溜まっていくファイルだと考えたほうが実態に近いです。
だから、他人の役割定義をそのままコピーしても機能しません。そこに書いてある禁止事項は、その人が経験した失敗に対応しているからです。自分が同じ失敗をしていなければ、その1行の意味がわからず、いずれ守られなくなります。
8-2. 本数の目安|必要になるものが段階で変わる
当サイトの実感として、必要になるものは本数によって変わりました。
| 段階 | 必要になったもの |
|---|---|
| 〜10本 | 書く手順を固定すること。分業はまだ不要 |
| 10〜20本 | 品質基準の言語化。「毎回同じ形で出す」の担保 |
| 20〜40本 | 工程の分離と内部リンクの構造管理。ここで単独運用が破綻した |
| 40本〜 | 公開ペースの平準化(予約公開)。継続の仕組み |
逆に言うと、10本目の人が40本目の課題を先に解こうとすると、たいてい体制づくりだけで力尽きます。 当サイトも、20本を超えて実際に困るまで分業を入れていません。
8-3. 再現性について、正直に書きます
最後に条件を明記します。
本記事に書いた80日40本という記録は、当サイト1件の事例です。 運営者の作業時間、扱っているテーマの調査難易度、AIツールへの慣れ、そして別の仕事との兼ね合いという固有の条件の上に乗っています。
- 同じ手順で誰でも同じ本数が書けるとは言えません
- 記事数が増えることが、流入や収益につながるとは言えません(本記事はその検証をしていません)
- 本記事はあくまで作業量と体制の記録であって、成果の記録ではありません
参考にしていただくなら、本数そのものではなく**「どこで壊れて、何を分けたか」の順序のほう**だと思います。個人事業としてAI活用を組み立てる全体像は個人事業主のAI導入ロードマップに、季節性のあるテーマを運用に組み込んだ実例はAIで小学生の自由研究を進める方法にまとめています。
9. よくある質問(FAQ)
Q1. 40記事書くのにどれくらいの時間がかかりましたか？
A. 2026年5月6日から7月25日までの80日間ですが、内訳は5月28本・6月5本・7月7本と偏っています。1本あたりの作業時間は計測していないため、具体的な時間数は書けません。人間が関与しているのはテーマ判断と公開可否の2箇所で、残りの工程はAI側の実行に任せています。
Q2. サブエージェントは何個作りましたか？
A. 検索語の調査・構成の設計・本文の執筆・法令面の点検・技術実装・編集判断という工程単位で分けています。個数より「どこで工程を切るか」のほうが結果に効きました。最初から分けたわけではなく、単独運用が破綻してから分けています。
Q3. 途中で公開が止まったのはなぜですか？
A. 6月に5本まで落ちています。書けなくなったからではなく、書いた日にそのまま公開する運用だったため、手が空かない週が更新の空白になったからです。この後にpubDateの先出しへ切り替えました。
Q4. 月額$20以外にかかった費用はありますか？
A. Claude Proの月額$20のほかは、独自ドメインの年額とホスティングの無料枠のみです。有料テーマや有料の計測ツールは導入していません。固定費全体の考え方はAIサブスクの組み合わせと固定費の考え方にまとめています。
Q5. 同じやり方で記事を量産すれば検索流入は増えますか？
A. 増えるとは言えません。本記事が公開しているのは公開本数と運用体制の記録であり、流入や収益との因果関係を検証したものではありません。記事数は作業量の指標であって、成果を約束する数値ではないという前提でお読みください。
まとめ：次に何をするか
40記事の記録から取り出せる、読者が実際に取れる行動は次のとおりです。
- いま10本未満なら、体制づくりは後回しにして、まず1本を自分で通しで書き切ってください。指示を書けるようになるのはその後です
- いま20本前後で手が回らなくなっているなら、いちばん先に切るべき工程は「点検」です。書く担当と、書いたものをチェックする担当を分けてください
- 更新が止まりがちなら、書く量を増やすより先に、書いた日と出す日を分離してください。当サイトではこれが失速からの立て直しに直接効きました
- 本数が増えてきたら、新記事を出すたびに古い記事から張り返す作業を、公開の手順の中に組み込んでください。後からまとめてやるのは現実的ではありません
- どの段階でも、扱う情報を「自分で使っている / 公式情報だけ / 扱わない」の3つに分けてから書き始めてください。当サイトでは、書き上がってから直すより手戻りが少なくなりました
立ち上げの段階の話は前編の3週間で19記事を書いた運用ログへ。本記事はその続きとして、19本が40本になるまでに壊れたところと、直した形だけを書きました。
関連記事
- 3週間で19記事を書いた立ち上げ記録 — 本記事の前編。ドメイン取得から初期のつまずきまで
- AIで個人ブログを構築・運営した記録 — この運用を回している環境
- ブログ運営者向けAIワークフロー完全ガイド — 書くと決まった後の生産手順
- ブログのネタ切れをAIで解消する方法 — 何を書くかを決める前段の工程
- ConoHa WINGとエックスサーバーの比較 — WordPressで始める方向けの土台選び
- AIサブスクの組み合わせと固定費の考え方 — 月額をどう配分するか
- AI生成物の著作権と商用利用 — 書く前に押さえる権利面
- 業務効率化に使うAIツールの全体像 — 効率化の見取り図
- マネーフォワードで開業届を出した記録 — 事業としての体裁を整える
- 文字起こし副業の単価と時間の考え方 — 作業時間を単価で見る視点
- 個人事業主のAI導入ロードマップ — 全体の進め方
- AIで小学生の自由研究を進める方法 — 季節性テーマの運用例
- AIで夏の旅行プランを立てる — 同上
- 無料AIツール20選 — 課金せずに始める選択肢
出典・参考リンク（2026年7月時点で確認）
- Claude 公式サイト — プラン・料金・提供内容
- Claude Code 公式ドキュメント — サブエージェントの仕様
- Astro 公式サイト — コンテンツコレクションの仕様
- Cloudflare Pages 公式サイト — ホスティングの提供条件
本記事に記載した公開本数・公開日は、2026年7月25日時点の当サイトの記事ファイルにもとづく実数です。料金・仕様は各社の公式ページで最新をご確認ください。
著者情報・改訂履歴
著者: EJ（aikatsulab.com 運営）。AIツールの公式情報・規約・第三者レビューを横断調査し、個人事業主・副業ブロガー向けに比較ガイドを執筆しています。本記事の公開本数・運用体制・費用に関する記述は、当サイトの実際の運用記録（2026年5月6日〜7月25日、計40記事）にもとづくものです。Claude Proには実際に課金しています。掲載した運用データは当サイト1件の事例であり、収益や検索順位を保証するものではありません。
改訂履歴:
- 2026-07-25: 初版公開。40記事到達までの80日間の月別公開本数、役割別サブエージェントによる分業体制と5段階パイプライン、予約公開によるペース制御、月額$20の実コスト構造、40本規模で見つかった5件の課題と修正内容をまとめました。