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

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

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

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

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

この記事の要点

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

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

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

実際に手が止まるのは2以外の全部です。特に4の入稿は、画像を4〜6枚扱うと手作業で20分以上かかり、毎日続くと折れます。

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

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

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

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

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

2. 「週1でまとめて設計する」ほうが品質が安定する。 7本まとめて設計すると、キーワード間のカニバリ（共食い）を見ながら配分できます。

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

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

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

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

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

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

水曜タスクの分岐も「取りこぼしが1件以上あるか」「在庫が5件以上あるか」の2条件だけです。

難しいのは処理そのものではなく、「今どういう状態か」を数え方1つで表すことです。ここが曖昧だと、二重投稿や公開漏れが起きます。

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

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

台帳の並び順は、サービスごとの比率（SEO代行4：AI導入支援3：Claude Code2：フォーム営業2：AI教室1）で順番に供給する方式です。気分が乗ったサービスの記事ばかり増える偏りを、設計段階で防げます。

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

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

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

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

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

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

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

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

対処（当初）：macOSのクリップボード経由に切り替えた。 `osascript` でPNGをクリップボードに載せ、エディタ上でペーストする方式です。

対処（2026年8月末以降）：貼り付け自体をやめた。 エディタが内部で使っている保存処理をブラウザ内から直接呼ぶ方式に移り、本文・画像・アイキャッチの入稿でキー入力と貼り付けが不要になりました。ただし公式に公開された仕組みではないので、仕様が変われば止まる前提で、保存後に本文の長さと画像の有無を必ず検証しています。

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

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

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

正しい項目を選ぶよう直したら、背面タブでも成功しました。「環境のせい」と結論づける前に、操作手順そのものを疑うべきでした。

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

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

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

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

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

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

人が決めている2つの工程｜どこに置くかの判断

この仕組みには、人が判断する工程が2つあります。自動化できないからではなく、判断を人に置いたほうが結果が良いからです。

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

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

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

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

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

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

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

爆発的な数字ではありません。本数が約2倍になっても、note経由の問い合わせは累計2件です。そして、仕組み化しても伸びない記事型は伸びませんでした。

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

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

自動化で解けるのは「続かない」だけです。「刺さらない」は自動化では解けません。

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

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

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

3から先を1度に作ろうとすると、壊れたときに原因が分からなくなります。1工程ずつ動かして、動いた形を手順書として残すのが最短でした。

よくある質問

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

できます。キーワード選定から公開まで人が触らずに回すことは技術的に可能です。そのうえで当社は、キーワードの配置判断（自社サイトかnoteか）と公開前の品質確認を人の工程に置いています。対外発信は間違ったものを出すコストが高く、この2つは判断が結果を大きく変えるためです。逆に、入稿・画像挿入・記録といった判断の要らない工程は完全に自動で回しています。

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

日時予約は有料プラン（月額500円）の機能です。また予約で並べると、公開直前の検証を挟めません。当社は毎朝1本ずつ検証してから公開しています。

Q. Claude Codeでnoteの下書き保存までAPIで自動化できますか？

できます。ただしnoteは公開APIを提供していないので、ログイン済みブラウザ上でエディタと同じ保存処理を呼ぶ形になります。当社は2026年8月末にこの方式へ移り、画像の貼り付けとキー入力が不要になりました。仕様変更で止まる前提で、保存後に本文の長さ・画像・アイキャッチを毎回検証し、合わなければ止めて報告します。

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

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

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

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

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

不安定になります。当社も上記4つの落とし穴でつまずきました。対策は、1操作ごとに「増えたか・入ったか」を検証し、失敗したら1回だけ再試行して、駄目ならその事実を報告して止まる設計にすることです。黙って進むほうが危険です。

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

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

---

執筆・監修：佐々木 優希（AIリモートワーカー代表／上場企業 営業統括 兼 AI責任者）。本記事の運用データ・実装手順はすべて当社の自社運用記録に基づきます（2026年8月時点・2026年11月6日に在庫・入稿方式・問い合わせ数を更新）。