この記事の結論
note毎日投稿が続かない原因は在庫切れです。2026年7月11日にAI並列生成で下書き100本(計121,249字)を約20分で書き上げ、同日中にnoteへ全数投入した実録の手順・時間・失敗を公開します。
【実践講座】Claude Code 2daysセミナー(第二の脳構築講座)の詳細を見る →
# note毎日投稿が続かない人へ|AIで下書き100本を1日で作った実録【2026年】
note毎日投稿が続かない原因は、意志の弱さではなく下書きの在庫切れです。僕は2026年7月11日、AIエージェント10体の並列生成でnote下書き100本・合計121,249字を約20分で書き上げ、同日中にnoteへ全数投入しました。この記事は、その手順・所要時間・失敗と対策を、すべて実測データで公開する実録です。
なぜnoteの毎日投稿は続かないのか?
続かない最大の原因は、「書く」と「公開する」を同じ日にやる設計にあります。毎晩ゼロから書く運用は、忙しい日や気分が乗らない日に必ず止まります。解決策は在庫です。下書きのストックが十分にあれば、毎日の発信は「選んで、確認して、公開する」だけの数分の作業に変わります。
僕自身、マーケティング会社の代表でありながら、自分のnoteは典型的な「続かない人」でした。記事の末尾に「また書きます」と書いておきながら、次の投稿まで数ヶ月空いたことが何度もあります。書きたい気持ちはあるのに、目の前の案件が優先で、夜には書く体力が残っていない。SNS発信が続かない経営者の典型例そのものです。
ここで大事なのは、これを根性の問題として扱わないことです。発信が止まる瞬間を観察すると、止まる理由はほぼ毎回同じでした。「今日は何を書くか」を決めるところから始めるから、着手が重いのです。テーマ決め・執筆・推敲・公開を毎回ワンセットでやる限り、1本あたり1〜2時間はかかります。これを365日続けられる経営者は、ほとんどいないと思います。
そこで発想を変えました。ストック運用とは、記事を書く工程と公開する工程を切り離し、下書きの在庫から選んで公開する発信の運用方式である。製造業でいえば、受注のたびに一から作るのではなく、見込み生産で在庫を持つ考え方です。在庫が100本あれば、毎日1本公開しても100日間は「執筆ゼロ」で発信が続きます。
問題は、その在庫100本を誰がいつ作るのかです。ここでAIを使いました。以下、実際にやったことを全部書きます。
AIで「note下書き100本」を作ったとは、具体的に何をしたのか?
2026年7月11日の1日で、テーマ表100本の設計、AIエージェント10体による並列執筆、note.comへの自動下書き投入、アイキャッチ画像の全数設定までを実施しました。生成した本文は合計121,249字、1本平均1,212字です。公開は一切しておらず、100本すべて下書き状態で人間の承認待ちにしています。
まず全体像を実測値で示します。数値はすべて、当日のファイルとログから機械的に集計したものです。
| 項目 | 実測値 | 計測方法 |
|---|---|---|
| 実施日 | 2026年7月11日 | ファイルの保存時刻+投入ログ |
| 生成本数 | 記事100本(テーマ表・ログ類を含め計108ファイル) | 保存フォルダの実ファイル数 |
| 本文の総文字数 | 121,249字(空白除く) | 100ファイル全数を機械計測(2026年7月28日再計測) |
| 1本あたりの文字数 | 平均1,212字(最短868字・最長1,354字) | 同上 |
| 生成体制 | AIエージェント10体並列(1体につき10テーマ担当) | テーマ表の割当記録 |
| 生成時間 | 11時54分テーマ確定→11時59分〜12時14分に100本保存 | ファイルの保存時刻 |
| note投入 | 12時02分〜14時38分(約2時間37分)で100本 | 投入ログのタイムスタンプ |
| 投入結果 | 最終100本成功(途中失敗7回・自動中断1回) | 投入ログの成功・失敗行の集計 |
| 下書きURL | 100本すべて別URL(重複ゼロ) | 投入ログのURL全数照合 |
| アイキャッチ | 最終監査で100本すべて設定済み | 全数監査ログ |
内容の内訳も設計しています。100テーマのジャンル構成は、日常24本・人生20本・仕事18本・組織16本・マーケ13本・採用9本です。仕事の話ばかりでは読者が疲れるので、日常の小ネタと人生観の記事を厚めに配分しました。この比率は、過去に反応が良かった記事の傾向から決めています。
保存フォルダの構成にも触れておきます。108ファイルの内訳は、記事100本のほか、テーマ表・投入ログ・アイキャッチの監査ログなどの管理ファイル8つです。つまり成果物と同じ場所に「何を・いつ・どうやって作ったか」の記録が全部残っています。この記事の実測値をいま正確に書けているのも、当日のログが1行単位で残っているからです。
ポイントは、「AIに100本書かせた」こと自体ではありません。テーマの重複を排除した設計図を先に作り、生成から投入までを検証可能なログ付きで実行したことです。ここを省くと、似たような記事の山ができて在庫として使い物になりません。
実際の手順とかかった時間は?
当日の実測タイムラインは次の通りです。11時54分にテーマ表100本を確定、11時59分〜12時14分に100本の本文ファイルが出揃い、12時02分にnoteへの投入を開始、14時38分に100本目の投入が完了しました。生成が約20分、投入が約2時間37分。テーマ設計から投入完了まで、3時間かかっていません。
工程は5つに分かれます。
手順1: テーマ表100本を先に確定する
いきなり記事を書かせず、まず「番号・テーマ・ジャンル・角度メモ」の4項目だけのテーマ表を100行作りました。角度メモとは「コンビニの新商品を必ず手に取ってしまう→マーケ屋の職業病を考察→新奇性の本質へ着地」のような、話の落とし所の1行指定です。この段階で投稿済み記事14本と既存ドラフト10本に照合をかけ、重複テーマをゼロにしてから確定しています(照合記録はテーマ表に残しています)。
手順2: AIエージェント10体に10本ずつ割り当てる
並列生成とは、複数のAIエージェントにテーマ表を分担させ、同じ型に従って同時に記事を書かせる生成方式である。僕はClaude Codeのサブエージェント10体に、1体あたり10テーマずつ割り当てました。全員が同じ執筆指示書(後述のマスタープロンプト)を読み込むため、書き手が10体いても文体は揃います。テーマ表の確定が11時54分、100本のファイルが揃ったのが12時14分。この20分間、僕は見ているだけでした。
手順3: note.comへ自動で下書き投入する
下書き投入とは、生成した記事ファイルをnoteのエディタへ自動転記し、公開せず下書き状態で保存する工程である。ブラウザの自動操作でnoteのエディタを開き、タイトルと本文を1本ずつ転記して保存します。投入ログには「ファイル名・タイトル・下書きの編集URL・時刻」が1行ずつ記録され、連続成功時の間隔は1本あたり約66秒でした(12時台〜14時台の連続成功時のタイムスタンプ差分から算出(平均66.5秒))。
量産の自動化で一番怖いのは、前の記事の内容が次の記事に混ざる「値の持ち越し」です。100本を同じ画面で流す以上、1回の取り違えで別記事のタイトルに別記事の本文が入る事故が起こり得ます。そこで投入完了後に、ログへ記録された編集URLを全数照合しました。結果は100本すべて別URLで、重複ゼロ。転記先の取り違えが1件も無かったことを、目視ではなく機械照合で確認しています。
[IMG: 投入ログの実物。ファイル名・記事タイトル・編集URL・時刻が1行ずつ記録されている様子]
手順4: 失敗をログで検知してリトライする
投入は一発では終わりませんでした。3本が本文転記エラーで計7回失敗し、「3連続で失敗したら自動停止する」安全装置が1回作動しています。原因を修正してリトライし、最終的に100本すべての投入に成功しました。失敗の中身は後の章で詳しく書きます。
手順5: 全数監査で仕上がりを検品する
全数監査とは、量産した成果物の全件を機械的に検査し、欠落や不備をログとして記録する検品工程である。投入後に100本の下書きURLを機械照合したところ、URLの重複はゼロ。一方でアイキャッチ画像の監査では25本の未設定が見つかりました(顛末は失敗の章で書きます)。量産は作って終わりではなく、この検品までがワンセットです。
[IMG: 当日のタイムライン図解(11:54テーマ確定→12:14生成完了→14:38投入完了)]
AIに書かせて品質は大丈夫なのか?
品質を決めるのはAIの性能ではなく、型の言語化の精度です。僕は自分の文体・記事構成・価値観・禁止事項を1本の指示書に明文化し、過去記事の照合リストでテーマ被りを排除した上で生成しています。それでも公開の判断は100%人間に残しています。この二段構えが品質の正体です。
順に説明します。マスタープロンプトとは、本人の文体・記事構成・価値観・禁止事項を明文化した、AI向けの執筆指示書である。僕のnote用の指示書には、次の要素が入っています(原文は営業秘密に近いので、構造だけ公開します)。
- ペルソナ: 経歴と人柄の温度感。「完璧な社長ではなく、迷うし失敗する普通の人」という自己認識まで指定
- 文体ルール: 一人称・文の長さ・語尾のバリエーション・改行の付け方。禁止事項(上から目線・自慢・ビジネス書口調)も明記
- 記事構成の型: 違和感→自分の失敗→気付き→読者への展開→自虐オチ、の5ステップ
- ジャンル別ルール: 採用記事は会社説明をせず思想を語る、人生記事は答えを押し付けない、など6ジャンル分
- タイトルと書き出しの型: 過去の公開記事から抽出した実パターン
- 固定パーツ: 記事末尾に毎回入れる採用導線の定型文
重要なのは、この指示書が「うまい文章を書け」という抽象命令ではなく、過去の実記事から抽出した再現手順になっている点です。実際、書き出しの型は公開済み記事に共通していた「セリフを2〜3連発してから問いかける」パターンをそのまま規則化しています。
もう1つの品質装置が照合リストです。被り防止インデックスとは、公開済み記事の一覧を生成前にAIへ照合させ、テーマの重複を防ぐための照合リストである。過去記事のタイトル・書き出し・URLを一覧化しておき、新しいテーマ表を作る際に必ず突き合わせます。今回の100テーマは、この照合を通過したものだけで構成しました。
それでも、AIが書いた初稿をそのまま公開することはしません。100本すべて下書き止まりで投入したのはそのためです。品質の最終判定は、型ではなく人間の目でやります。実際、投入後の見直しで2本の本文を修正しました(修正もログに記録が残っています)。
実際に何につまずいたのか?失敗3つと対策
つまずきは大きく3つありました。①本文の一括入力で行間が崩れて読み味が死ぬ、②保存時の確認ダイアログで自動操作が停止する、③段落の境界で句点の位置がずれる。投入ログ上も3本が計7回失敗し、自動中断が1回発生しています。いずれも対策済みで、最終的には100本すべて投入に成功しました。
成功談だけ書いても再現できないので、失敗の中身を具体的に書きます。
失敗1: 一括入力で「のっぺり本文」になった
最初の投入方式は、本文をエディタへ一括流し込みする方法でした。速いのですが、全行が均等な段落として貼り付き、行間がのっぺり開いた読みにくい本文になります。noteは段落ごとに余白が付くため、「関連する数文は詰めて、話の切れ目にだけ空行を入れる」メリハリが読み味の生命線です。これが全部潰れました。
この仕上がりには僕自身が2回NGを出し、投入スクリプトを作り直させています。対策は、一括流し込みを禁止し、段落グループ単位で改行を制御しながら転記する方式への変更でした。自動化で最初に壊れるのは、こういう「人間が無意識にやっている細部」です。
失敗2: 保存時の確認ダイアログで止まる
noteのエディタはページを離れようとすると「保存されていません」系の確認ダイアログを出します。人間には親切な機能ですが、自動操作にとっては進行を止める壁です。通常の画面遷移ではこのダイアログを処理できず、専用の遷移処理を組んでようやく突破できました。最終的には、ダイアログ処理を最大6回リトライする仕組みをスクリプトに組み込んでいます。
失敗3: 段落境界で句点がずれる
一番地味で、一番厄介だったのがこれです。段落グループの境界で、文末の句点が次の段落の先頭に紛れ込む転記バグが起きました。目視では気づきにくく、全数チェックで発覚したものです。対策は、入力位置を都度確定してから次のグループを転記する方式への変更でした。
おまけの失敗: アイキャッチの取りこぼし25本
本文の投入が終わった後、全数監査でアイキャッチ画像の未設定が25本見つかりました。下書き一覧では画像の有無が一目で分かるので、ここが歯抜けだと在庫の管理性が一気に下がります。対策として、未設定の記事だけを抽出→画像を自動設定→再監査、というループを回しました。途中で設定に失敗する記事が何本も出ましたが、リトライを繰り返し、最終監査は「100本設定済み・欠落ゼロ」で完了しています。どの記事にどの画像を設定したかも、ログに1行ずつ残る設計です。
失敗が教えてくれたこと
3本の転記失敗(計7回)と自動中断1回は、すべてこの種の画面側の挙動が原因でした。ここから得た教訓は2つです。1つ、自動化は「動いた」ではなく「全数検証して合っていた」で完了とすること。2つ、失敗をログに残す設計にしておくと、リトライも原因究明も速いこと。アイキャッチ25本の欠落を検知できたのも、全数監査をログで回していたからです。
100本のストックで運用はどう変わるのか?
毎日の意思決定が「今日は何を書くか」から「今日はどれを出すか」に変わります。毎日1本公開しても100日分、週3本なら約8ヶ月分の在庫です。人間の仕事は執筆から品質判断(承認)に移り、忙しさで発信が止まる構造そのものが消えます。僕の実務では、発信は「数分の確認作業」になりました。
この変化は、単なる時短ではありません。運用の設計図が変わります。
第一に、公開フローが「下書きの在庫→本人の承認→公開」に固定されます。AIが生成するのは下書きまでで、公開ボタンは必ず人間が押す。対外発信の責任の所在を曖昧にしないための、意図的な線引きです。量産とガバナンスは両立できます。
第二に、発信が「気分の仕事」から「仕組みの仕事」になります。在庫が見えていれば、旅行や繁忙期の前に公開予定を組めますし、在庫が減ってきたら補充バッチを回すだけです。継続の正体は根性ではなく段取りだ、というのが100本作ってみた僕の結論です。
時間の面も単純計算してみます。仮に1本90分かけて自力で100本書くと150時間、営業日換算で約19日分の労働です。今回の実測では、テーマ表の確定から投入完了までの当日の拘束が3時間弱。もちろんこの手前に型の言語化という仕込みがありますが、仕込みは一度作れば次のバッチでも使い回せます。2回目以降ほど効いてくる投資です。
第三に、ここで作った仕組みは発信以外にも転用できます。今回のパイプラインは「型の言語化→照合→並列生成→自動投入→全数監査」という汎用構造で、実はブログ量産に限らず、AIでの業務量産全般に同じ型が使えます。うちの会社では同じ考え方で広告レポートや調査業務も自動化しており、その全体像はClaude Codeで会社を「第二の脳」にする完全ガイドで詳しく解説する予定です。業務別の実測は中小企業のAI業務自動化Before/After実測にまとめます。
なお、2026年7月時点でこの100本はまだ「在庫」です。ここから毎日の承認・公開運用に載せていくので、公開後の反応データはいずれ続編として書きます。成果を先に約束するのではなく、実測が出たら実測を書く。このコラムはその方針で運用します。
100本のストックは、その後どう消化されたのか?(2026年8月の実測)
量産から23日後の2026年8月3日時点で、公開した記事は13本でした。うち12本が7月11日に量産した100本から、1本が翌7月12日に追加生成した50本からの公開です。この間、在庫切れによる中断は一度も起きていません。確認方法は、noteの公開フィードのタイトルと生成フォルダ内のタイトルを機械照合したものです。
具体的な公開日はこうです。7月12日・13日・17日・19日・20日・21日・22日・24日・26日・28日・30日・31日・8月3日。空いた最長の間隔は4日で、平均するとおおよそ1.8日に1本のペースでした。量産の翌日から公開が始まっている点が、在庫型運用のいちばん分かりやすい効果だと思います。
在庫の残りは、量産した合計150本から公開分を引いて約137本です。同じペースなら8か月分近く残っている計算になります。
ここから分かることを3つ書きます。
第一に、在庫があると「書く日」と「出す日」が分離します。7月中旬から下旬にかけて、僕は広告の運用改善やサイト改修に時間を取られていましたが、発信は止まっていません。書く時間が取れない日に発信が途切れるという、毎日投稿がいちばん壊れやすいポイントを構造的に外せます。
第二に、在庫は自動では減りません。公開は1本ずつ僕が読んで選んでいるため、23日で13本という消化ペースは「意図的にこの速さにした」結果です。100本あるからといって100日連続で機械的に流すのは、読者との関係を考えると得策ではないと判断しました。
第三に、在庫があっても書きたいときは書きます。その日に感じたことや時事のテーマは、在庫と関係なく新規で書けばいい。在庫は「書かない自由」を確保するためのもので、書く行為を置き換えるものではありません。ここを取り違えると、量産は発信の熱量を下げる方向に働きます。
自社で再現するには何から始めればいいか?
順番は4つです。①自分の型の言語化(文体・構成・価値観・禁止事項)、②公開済みコンテンツのインデックス化、③まず10本の小ロットで品質検証、④問題なければ並列生成と自動投入へ拡張。最初から100本を狙わないでください。型と検品体制を先に作るのが、結果的に最短ルートです。
各ステップの実務ポイントを補足します。
①型の言語化。自分の過去記事を5〜10本並べて、書き出し・構成・語尾・締めの共通点を抽出します。ここで「うまく書け」ではなく「この順番でこう書け」まで具体化できるかが、AIっぽい一般論記事との分かれ目です。過去記事が無い場合は、まず自力で数本書いてから型を抽出する方が確実です。
②インデックス化。公開済み記事の一覧(タイトル・書き出し・URL)を1ファイルにまとめます。地味な作業ですが、これが無いと量産した瞬間にテーマ被りが起き、在庫の価値が下がります。
③小ロット検証。いきなり100本ではなく、10本作って全部自分で読んでください。違和感のある表現をすべて型にフィードバックしてから、次のロットに進みます。僕の場合も、行間の崩れのような「読んで初めて分かるNG」は小ロット段階の往復で潰しています。
④拡張。型が安定したら、並列生成と自動投入に進みます。なお本文の生成だけならChatGPTのような対話型AIでも可能ですが、過去記事との照合・100ファイルの管理・noteへの自動投入まで含めるなら、ローカルのファイルとブラウザを操作できるClaude Codeのような環境が前提になります(2026年7月時点の僕の実務での結論です)。
従来のやり方との違いを早見表にまとめます。
| 観点 | 根性型(毎晩ゼロから書く) | ストック型(AI量産+人間承認) |
|---|---|---|
| 毎日の作業 | テーマ決め〜執筆〜公開で1〜2時間 | 在庫から選んで確認・公開(数分) |
| 止まる理由 | 忙しさ・気分・ネタ切れ | 在庫切れのみ(補充バッチで回避) |
| テーマ被り | 記憶頼み | インデックス照合で機械的に排除 |
| 文体の一貫性 | 日によってブレる | 型(指示書)で一定に保つ |
| 品質の担保 | 書きながら自分で判断 | 公開前の承認工程に集約 |
| 初期コスト | 不要 | 型の言語化と環境構築が必要 |
初期コストの行が、唯一ストック型が負ける点です。ここを自社でやるか、外部の力を借りて一気に立ち上げるかは、社内のリソース次第だと思います。型の言語化や発信の仕組み化を含めた支援はウラカタのマーケティング支援サービスでも行っています。
まとめ
- note毎日投稿が続かない原因は意志ではなく在庫。「書く」と「公開する」を切り離すと発信は止まらなくなる
- 実測では、テーマ表100本の確定からnote投入完了まで1日(生成約20分・投入約2時間37分・本文計121,249字)
- 品質はAI任せにしない。型の言語化とテーマ照合で作り込み、公開判断は100%人間に残す
- つまずきは行間崩れ・確認ダイアログ・句点ずれの3つ。すべて対策済みで、失敗ログごと再現手順にした
- 再現するなら、型の言語化→インデックス化→10本の小ロット検証→拡張の順。最初から100本を狙わない
よくある質問
AIが書いたnote記事だと読者に気づかれませんか?
型の言語化の精度次第です。文体・構成・失敗談の温度感まで指示書に落とせば、本人らしさは相当再現できます。ただし最終判断は人間の承認に残すべきで、僕も公開前に全本文を自分で確認する運用にしています。
毎日投稿には何本のストックがあれば安心ですか?
最低2週間分の14本を推奨します。在庫が1週間分を切ったら補充する運用にすれば、繁忙や体調不良で書けない日があっても発信は止まりません。僕は100本、つまり毎日投稿で約3ヶ月分の在庫を一度に作りました。
ChatGPT単体でも同じことはできますか?
本文の生成だけなら可能です。ただし過去記事との被り照合・100ファイルの管理・noteへの自動下書き投入まで含めると、ローカルのファイルとブラウザを操作できるClaude Codeのような環境が必要でした(2026年7月時点)。
テーマが100本も被らずに作れるものですか?
生成前の照合がすべてです。公開済み記事と既存ドラフトの一覧をAIに渡し、重複のないテーマ表を先に確定してから書かせます。実測では投稿済み14本・既存ドラフト10本との重複ゼロで100テーマを設計できました。
量産した記事はそのまま公開してもいいですか?
推奨しません。うちは100本すべて下書き止まりで投入し、公開は毎回人間が承認しています。対外発信の最終責任はAIに移せないので、「生成は自動・公開判断は人間」という線引きが実務ではいちばん安全です。
