Claude Codeでnoteを自動投稿する仕組みの全手順｜毎日1本を90本続けた記録

「オウンドメディアを毎日更新すると決めた。3週間で止まった」。

コンテンツ運用が折れる場所は、たいてい「書く力」ではありません。キーワードを選ぶ・記事を書く・画像を作る・入稿する・公開する・記録するという6つの工程を、毎日ひとりで回し続ける段取りのほうが先に折れます。

当社は2026年5月から、企業noteを毎日1本ペースで約90本公開してきました。ただし、毎朝手作業で入稿していたわけではありません。Claude Codeに定時タスクを組み、下書き入稿・公開・在庫管理といった「執筆の前後の段取り」を仕組みにしたからです。執筆そのものは、人が設計した台帳と品質基準の上でAIを活用する方式で、ここは後述のとおり「全自動」にしていません。

本記事では、その仕組みの全体像と実装手順を、当社の運用記録そのまま公開します。うまくいった部分だけでなく、ブラウザ自動操作で実際に壊れた4つの落とし穴と、自動化してはいけない工程も含めて書きます。

この記事の要点

• note運用は「執筆」「入稿」「公開」「記録」に分解でき、当社は4本の定時タスクに割り当てて回している
• 在庫管理の考え方が要。「下書き済みの件数＝あと何日ぶん公開できるか」という1つの指標に集約する
• 最初に壊れるのは執筆ではなくブラウザ操作。タブ・画像挿入・アイキャッチ設定で実際につまずいた
• 「全自動」にはしていない。キーワードをどこに置くか（自社かnoteか）は人が決める工程として残している
• 約90本の実測は週間PV233・最高650PV。仕組み化しても伸びない記事型は伸びない——量の担保と質は別問題

note運用が折れるのは「書く」工程ではない

まず前提の整理です。企業noteを毎日更新する作業を工程に分解すると、こうなります。

多くの人が「AIに記事を書かせれば運用が回る」と考えますが、実際に手が止まるのは2以外の全部です。特に4の入稿は、1本あたり画像を4〜6枚扱うと手作業で20分以上かかり、これが毎日続くと確実に折れます。

つまり自動化すべき本体は執筆ではなく、「執筆の前後にある段取り」です。

当社の構成｜4本の定時タスクで在庫を切らさない

結論から言えば、当社は役割の違う4本の定時タスクにnote運用を分割しています。1本の巨大な自動化タスクを作らないことが安定運用の鍵でした。

この分割にした理由は3つあります。

1. 執筆と公開を別タスクにすると、失敗が連鎖しない。 執筆バッチが失敗しても、在庫が残っていれば翌朝の公開は止まりません。逆に公開でつまずいても、書き上げた記事は下書きとして残ります。

2. 「週1でまとめて設計する」ほうが品質が安定する。 毎日1本ずつ書くと、その日のリサーチ結果だけで書くことになります。週1で7本まとめて設計すると、キーワード間のカニバリ（共食い）を見ながら配分できます。

3. セーフティネットを別に持つ。 週次バッチが5本しか作れなかった週も現実にあります。水曜のタスクが在庫を数え、足りなければ執筆まで踏み込む設計にしてから、公開の欠落が起きにくくなりました。

在庫は「下書きの件数＝残り公開日数」に集約する

自動化で最も効いた設計判断が、これです。

公開待ちの下書きフォルダの件数を数えるだけで、「あと何日ぶん公開できるか」が分かる状態にした。

当社のローカルには、記事ごとのフォルダが「下書き前」「下書き後」「投稿済み」の3段階で並んでいます。noteへの下書きアップが完了したフォルダには `.note_uploaded` という空ファイル（マーカー）を置きます。

• 「下書き後」の件数＝note下書き済み＝残り公開日数（毎朝1本消費するので、12件なら12日ぶん）
• FIFOキー＝マーカーファイルの更新時刻。最古の1本から公開する
• マーカーが無いフォルダ＝アップの取りこぼし。水曜タスクがここを回収する

在庫の指標を1つに絞ると、判断が単純になります。水曜タスクの分岐は「取りこぼしが1件以上あるか」「在庫が5件以上あるか」の2条件だけで、あとは自動で動きます。

自動化の設計で難しいのは処理そのものではなく、「今どういう状態か」を数え方1つで表せるようにすることです。ここを曖昧にすると、タスクが毎回状況判断に迷い、二重投稿や公開漏れを起こします。

記事生成は「台帳」を正本にする

記事の中身をその場の思いつきで決めないために、キーワードの供給順は1枚の台帳（Markdownの表）に集約しています。2026年8月時点の実データは次のとおりです。

台帳の並び順は「サービス加重ラウンドロビン」にしています。1周12スロットの並びを固定し（SEO代行4：AI導入支援3：Claude Code2：フォーム営業2：AI教室1）、各サービスから順番に供給する方式です。こうすると、その週に気分が乗ったサービスの記事ばかりが増える偏りを、設計段階で防げます。

定時タスクは「台帳の上から未着手を7件取る」だけで、何を書くかの判断をしません。判断は台帳を作るときに済ませておき、実行時には持ち込まない——これが自動化を安定させる原則です。

最初に壊れるのは執筆ではなくブラウザ操作

ここが実装でいちばん時間を取られた部分です。noteはAPI公開型のCMSではないため、下書き入稿と公開はブラウザ自動操作で行っています。実際にぶつかった4つの落とし穴を、そのまま共有します。

落とし穴1｜既存の編集タブから別記事へ遷移できない

note編集画面が開いているタブで別URLへ遷移しようとすると、ブラウザの「Leave site?（このサイトを離れますか）」ダイアログで止まります。自動操作はここで詰まります。

対処：記事ごとに新しいタブを作り、終わったら閉じる。 「1記事＝1タブ」を鉄則にしてから、この種の停止は起きなくなりました。

落とし穴2｜画像はダウンロード経由で入らない

本文への画像挿入を、画像URLをスクリプトで取得して入れる方式で試すと安定しませんでした（ローカルの画像をブラウザ内から読み込ませる経路がブロックされる）。

対処：macOSのクリップボード経由に切り替えた。 `osascript` でPNGをクリップボードに載せ、エディタ上でペーストする方式です。地味ですが、これが最も確実でした。画像挿入直後はフォーカスがキャプション欄に移るので、そのままキャプションを入力して確定する——という「操作の順番」まで手順に固定しています。

落とし穴3｜アイキャッチ設定の失敗を「タブが背面だから」と誤診断した

シェア画像（OGP）に効くアイキャッチ設定が何度も失敗し、当初は「タブが背面（非表示）だと失敗する」と結論づけていました。これは誤りでした。

真因はメニュー項目の取り違えです。noteの画像追加メニューには「画像」と「画像をアップロード」の2つがあり、前者は本文挿入用。前者を選ぶと本文に画像が入るだけで、アイキャッチにはなりません。入力欄自体も、アイキャッチ用と本文用でIDが別物でした。

正しい項目を選ぶよう直したら、背面タブでも問題なく成功しました。自動化のデバッグでは「環境のせい」と結論づける前に、人間の操作手順そのものを疑うべきだった、という教訓です。

落とし穴4｜note の予約投稿は有料プラン限定だった

当初は「週末に7本を予約投稿で並べれば、公開タスクは不要」と考えていました。しかしnoteの日時予約は有料プラン（月額500円）の機能で、無料プランでは日時指定ができません。

対処：予約に頼らず、毎朝7時の公開タスクで1本ずつ公開する。 結果的にこちらのほうが良く、公開前に本文の長さ・タイトル一致・アイキャッチの有無を検証するチェックを挟めるようになりました。

「公開」だけは慎重側に倒す

公開は対外発信です。ここだけは自動化の設計思想を変え、迷ったら止まる方向に振っています。実装している安全弁は5つです。

自動化を作るとき、つい「必ず1本公開する」ことをゴールにしたくなります。しかし対外発信では、空振り（今日は公開しない）よりも誤射（間違ったものを公開する）のほうが高くつきます。ゴールは「毎日公開する」ではなく「間違ったものを公開しない」に置くべきでした。

自動化しても人が決めること｜どこに置くかの判断

ここが本記事でいちばん伝えたい部分です。この仕組みは「全自動」ではありません。人が判断する工程を、意図的に2つ残しています。

1つ目は、キーワードをどこに置くかの判断です。 当社は2026年8月から、記事の置き場所を役割で分けました。

理由は、noteが外部リンクを全てnofollowにし、canonical（正規URL）を自社に向けられない仕様だからです。同じテーマを両方に置くと、ドメイン評価の強いnote側が正規と判定され、自社サイト側が検索結果から消えます。この判断は自動化できません。台帳のキーワード1件ごとに「自社行き／note行き」を人が振り分けています。

2つ目は、品質ゲートです。 当社は全記事に「一次情報を最低1つ入れる」を必須条件にしています。自社の実測数字、サービス設計の一次データ、運用の失敗談のいずれか。一般論の再構成だけで書ける記事は、自動化できても公開しないというルールです。

この2つを人の工程として残しているので、「毎日必ず1本」ではありません。条件を満たせない日は公開を見送ります。自動化の目的は本数の達成ではなく、判断以外の作業から手を離すことです。

なお当社がClaude Code導入支援で最初に伴走するのも、まさにこの線引きの部分です。ツールの使い方ではなく「どの工程を自動化し、どこを人に残すか」の設計が、実務で使える自動化とそうでないものを分けます。

成果と限界｜約90本の実測値

仕組みで担保できたのは「量」です。では成果はどうだったのか。実測値を出します。

正直に言えば、爆発的な数字ではありません。そしてここが重要なのですが、仕組み化しても伸びない記事型は伸びませんでした。

• 伸びた型：「ひとり○○×N業務」型（スキ83）、実用リスト型（累計650PV）、痛み起点型
• 伸びなかった型：価格・相場の羅列（スキ6〜13）、「○○とは」の抽象解説（スキ10〜11）

詳しい内訳は企業noteを毎日更新して90本公開した実測データ全公開にまとめています。

自動化で解けるのは「続かない」という問題だけです。「刺さらない」は自動化では解けません。この2つを混同すると、量産して疲弊するだけの運用になります。

非エンジニアが同じ仕組みを作るなら、この順序で

最後に、これから作る方への順序です。当社は営業・マーケティング側の人間が組んでおり、専任のエンジニアはいません。順序を間違えなければ再現できます。

1. 工程を書き出す：まず自分の運用を6工程に分解して紙に書く。自動化はここからしか始まらない
2. 台帳を作る：次に書く順番を1枚の表に固定する。実行時に判断を持ち込まないため
3. 図解・画像から自動化する：テンプレ化した画像生成から着手する。ここは最も相性が良く、失敗しても損害がない。執筆はAIの下書きを使うにしても、構成・一次情報・編集基準を先に人が決める
4. 入稿を自動化する：ブラウザ操作は落とし穴が多い。1操作ずつ検証を挟む手順書として書く
5. 最後に公開を自動化する：安全弁（1回1本・照合・迷ったら止まる）を先に決めてから着手する
6. 記録を自動化する：台帳更新と重複防止マーカー。ここを最後にすると、途中の設計ミスに気づける

3から先を1度に作ろうとすると、必ずどこかで壊れて原因が分からなくなります。1工程ずつ動かして、動いた形を手順書として残すのが最短でした。当社の定時タスクは現在23本動いていますが、そのうちnote運用に関わるのは4本だけです。小さく分けたほうが、壊れたときに直せます。

よくある質問

Q. Claude Codeでnoteの完全自動投稿はできますか？

技術的には、キーワード選定から公開までを人が触らずに回すことは可能です。ただし当社は「全自動」にしていません。キーワードの配置判断（自社サイトかnoteか）と品質ゲートは人の工程として残しています。対外発信は、間違ったものを出すコストが高いためです。

Q. noteの予約投稿機能を使えば、自動化は不要ではないですか？

noteの日時予約は有料プラン（月額500円）の機能で、無料プランでは日時指定ができません。また予約で並べると、公開直前の検証（本文の長さ・アイキャッチの有無など）を挟めません。当社は毎朝の公開タスクで1本ずつ検証してから公開する方式にしています。

Q. 非エンジニアでも同じ仕組みを作れますか？

当社はエンジニアではない人間が組んでいます。要点は、プログラムを書く力よりも業務を工程に分解し、手順書として言語化する力です。営業・マーケティングで手順書やトークスクリプトを作ってきた人のほうが、むしろ向いています。

Q. 自動化すると記事の質は落ちませんか？

質が落ちるのは、自動化したからではなく品質の条件を定義しないまま量を増やしたからです。当社は「一次情報を最低1つ含む」を全記事の必須条件にし、これを満たせない記事は公開しません。条件を先に決めれば、量と質は両立できます。

Q. ブラウザ自動操作は不安定になりませんか？

不安定になります。当社も4つの落とし穴（タブ遷移、画像挿入、アイキャッチのメニュー取り違え、予約投稿の仕様）でつまずきました。対策は、1操作ごとに「増えたか・入ったか」を検証し、失敗したら1回だけ再試行して、駄目ならその事実を報告して止まる設計にすることです。黙って進むほうが危険です。

Q. 毎日更新は本当に必要ですか？

必要とは言えません。当社の実測でも、週間PVの主力は「3ヶ月前に公開した古い記事」でした。毎日更新の価値は本数そのものではなく、型の検証回数を稼げることにあります。どの記事型が刺さるかを早く知るために量を出し、分かったら本数より密度に寄せる、という順序が現実的です。

---

執筆・監修：佐々木 優希（AIリモートワーカー代表／上場企業 営業統括 兼 AI責任者）。本記事の運用データ・実装手順はすべて当社の自社運用記録に基づきます（2026年8月時点）。