毎日ポチポチ消耗していませんか？ noteの読者候補を探すスキ回り戦略と自動化ガイド

はじめに：毎日ポチポチとスキを押し続けて、疲れていませんか？

noteの運用実験ログ（無料記事A）をご覧いただき、ありがとうございます。

記事Aでは、noteのフォロワー数と対象記事のスキ数の推移を記録しています。スキ回りとフォローバックを組み合わせた運用のため、スキ単独の効果とは断定できません。

この記事を読んで、

「自分も同じように毎日スキを押して、読者を増やしてみよう！」

と意気込んだ方も多いのではないでしょうか。

……ですが、ちょっと待ってください。

もしあなたが今、「適当にタイムラインに流れてきた記事をポチポチ押すだけ」の作業を繰り返しているなら、対象の探し方を一度見直してみてください。

ターゲットを定めずにスキを配るだけでは、自分の発信に関心を持つ読者との接点につながるとは限らないからです。

1日30分、1時間と画面を見つめ、何十回もブラウザのタブを行ったり来たりして、得られたのは義理のスキが数個だけ……。これでは本来もっと時間をかけるべき「記事の執筆」や「コンテンツの推敲」が疎かになってしまいます。

では、「一体誰の記事を、どう探し、どうやって効率的にアプローチしていけばよいのか？」

本記事では、手作業で消耗しないための「読者ターゲット選定の思考法」から、裏側の通信の仕組み（非公式API）、そして作業を自動化・仕組み化するためのシステム設計論まで、初学者の方にもわかりやすくロジカルに解説します。

1. スキ回りで消耗する人と、成果に繋がる人の決定的な違い

1-1. 闇雲なアプローチが「時間の無駄」に終わる理由

note運用で最もやってはいけないのが、「とにかく誰でもいいから数を打つ」という運用です。

たとえば、あなたが「副業プログラミングの学習法」について発信しているとします。そこで、たまたま見かけた「日々の料理日記」や「ペットの可愛い写真」にスキを押して回ったらどうなるでしょうか？

相手が通知欄を見て「どんな人だろう？」とプロフィールを開いてくれたとしても、並んでいるのはプログラミングの技術論です。相手の関心と合わなければ、そのままページを閉じるかもしれません。

自分の発信ジャンルに関心を持ってくれそうな人を探すことが、継続的に読んでもらうための一つの出発点です。

1-2. 狙うべきは「特定テーマにスキを押している、アクティブな書き手」

では、どこを探せば「濃い見込み読者」が見つかるのでしょうか。

ここで、一つの実践的な運用仮説を立ててみます。

【運用仮説】

自分と同ジャンル・同テーマの人気記事に「スキ」を押しているユーザーは、その話題に関心を持っている可能性がある。

さらにその中で、「自分自身でもnoteに記事を投稿しているクリエイター」は、noteの通知欄をこまめにチェックし、他のクリエイターとの交流にも前向きである可能性が高い。

noteには「読むだけの専門読者」と「自身も記事を書くクリエイター」がいます。

ただし、読む人と書く人のどちらが頻繁に通知を確認するかは、この実験では検証していません。

継続的に記事を投稿していることは、活動状況を見る手がかりにはなります。

つまり、

同ジャンルの人気記事にスキを押している人を探す

その中から「自身も記事を投稿している人」をピックアップする

その人の記事を読み、本当に良いと思った内容にスキを届ける

この3つのフィルターを通すだけで、手当たり次第にアプローチするのと比べて、関心の近い書き手との接点を探しやすくなる、という仮説です。効果の倍率を実測したものではありません。

1-3. 具体例：ターゲット読者を一本釣りする選定の仮説

具体的にイメージしてみましょう。

あなたの発信テーマ： 「未経験からのWebライター独立ノウハウ」

ステップ1（記事の選定）： note内で「#Webライター」「#ライター初心者」と検索し、直近で多くのスキを集めている人気記事（先輩ライターの体験談など）を探します。

ステップ2（ユーザーの確認）： その人気記事にスキを押している人の一覧を開きます。

ステップ3（書き手の選別）： プロフィールを確認し、「初案件を受注しました！」「クラウドソーシング挑戦日記」といった記事を直近で投稿している人を見つけます。

ステップ4（アプローチ）： その人の記事を拝読し、共感した記事にスキを届けます。

相手から見れば、「まさに今自分が頑張っているライティングの分野で、役立つ知見を発信している先輩からリアクションが届いた」状態になります。あなたの記事に関心を持ってもらうきっかけになるかもしれません。

1-4. 運用の大原則：「スキ返し」を当然の見返りと思わないこと

ただし、運用にあたって絶対に忘れてはならないマインドセットがあります。

それは、「スキ返しやフォローバックを当然の権利として期待してはならない」ということです。

相手があなたの記事を読んでスキを返すか、フォローするかは、100%相手の自由です。こちらのアクションはあくまで「存在を知ってもらうための小さな挨拶」に過ぎません。

見返りを求めてギラギラした運用をすると、文章の端々にそれが透けて見え、逆に敬遠されてしまいます。「自分の記事を必要としてくれそうな人に、誠実に届ける」という姿勢を常に保ってください。

2. 手作業の限界：なぜあなたの貴重な執筆時間が奪われるのか

2-1. 成果を出すための手動6ステップ

上記の戦略を手作業（ブラウザ操作）で行う場合、以下のプロセスを1人ずつ丁寧に進めることになります。

[1. 関連ジャンルの記事を検索]
             ↓
[2. スキしたユーザー一覧を開く]
             ↓
[3. ユーザーのマイページを開き、記事の有無を確認]
             ↓
[4. 投稿されている記事を実際に読む]
             ↓
[5. 共感できる記事にスキを押す]
             ↓
[6. 誰にアクションしたかを台帳・スプレッドシートに記録]

2-2. どこで時間が溶けていくのか？ ボトルネックの解剖

この作業を実際にやってみると、想像を絶する時間と集中力が奪われることに気づくはずです。

画面遷移の無限ループ：

一覧からユーザーページを開き、さらにその人の記事を開き……と、ブラウザのタブが何十個も開き、PCの動作も思考も重くなります。

「記事を書いていない人」を引く無駄足：

スキ一覧の中には、記事を1本も書いていない読者専用アカウントも多数混ざっています。プロフィールを開いて「記事がありません」と確認するだけの不毛な時間が積み重なります。

「この人、前にも押したっけ？」の確認コスト：

過去にアクションした相手かどうかを記憶やスプレッドシートと照合する作業は、頭のリソースを激しく消耗します。

日々の記録の手間：

運用ログを毎日手入力でメモする作業にも時間がかかります。

本来、あなたが最も時間を使うべきなのは「読者の心を動かすオリジナル記事の執筆」のはずです。単純な確認作業やクリック作業に貴重なエネルギーを奪われていては本末転倒です。

3. テクノロジーで作業を効率化する：非公式APIによるデータ取得

この「探索・選別・確認」という泥臭い作業を、プログラミングやテクノロジーの力で効率化できないか？

そこで登場するのが、noteの裏側で動いている「非公式API（内部API）」を活用するアプローチです。

3-1. 非公式API（内部通信）の正体とは

私たちが普段ブラウザやスマホアプリでnoteを見ているとき、画面上にはボタンや画像が綺麗にレイアウトされています。しかし、その裏側では「サーバーに対してデータを要求し、JSON形式のテキストデータを受け取って画面に描画する」という通信が行われています。

公式な開発者向けドキュメントは公開されていないものの、「ブラウザとサーバーの間で日常的に使われている通信の規格（内部エンドポイント）」のことを、非公式API（内部API）と呼びます。

※技術的な注意点：

非公式APIは一般公開が保証された仕様ではありません。note運営側のアップデートによってURLやパラメータが予告なく変更されたり、アクセス制限がかかったりするリスクを常に考慮する必要があります。

3-2. 対象記事を特定する「記事キー」の見つけ方

noteの記事URLを観察すると、末尾に英数字の羅列があることがわかります。

https://note.com/sample_creator/n/n123456789abc

このURLの末尾にある n123456789abc が、システム上でその記事を一意に識別するための「note_key（記事キー）」です。プログラムからデータを取得する際も、このキーを指定してリクエストを送信します。

3-3. データの取得先（エンドポイント）と通信の仕組み

既存のnote-liker実装では、次の通信を使っています。

• 通信プロトコル：HTTPS

• HTTPメソッド：GET

• エンドポイント：https://note.com/api/v3/notes/{note_key}/likes

このパスは、リポジトリの src/lib/automation/likeEngine.ts と src/lib/noteClient.ts で確認しました。

2026年9月16日のこの環境からの読み取り確認はHTTP 403となり、最新の本番レスポンスは取得できませんでした。以下は既存コードで確認できた仕様と、未検証の範囲を分けて示しています。

3-4. 一覧の取得とログイン認証

既存コードは、公開記事のスキ一覧をCookieなしで取得する設計です。

ただし、認証不要の設計であっても常にアクセスできるとは限りません。アクセス制限や仕様変更で失敗した場合は停止して状況を確認し、制限の回避を試みないでください。

3-5. ページネーション（分割読み込み）の確認範囲

既存コードはページ指定なしで1回だけ取得しており、全件取得を保証していません。

page、offset、limit などの有効なパラメータ、ページの終端判定は、このリポジトリと今回の確認では確定できませんでした。未確認の値を付けてループする例は掲載していません。

追加ページを扱う前に、実際の一覧画面が送るリクエストとレスポンスを確認してください。

3-6. 取得できるデータ・取得できないデータの境界線

既存コードが参照している階層は data.likes[].user です。

上の表は本番レスポンスの完全な仕様書ではありません。アイコンURLや総件数、ページ送りフラグは今回確認できていません。

メールアドレス、パスワード、ログイン履歴、非公開の下書きは、ここで扱う公開データ取得の対象外です。

3-7. スキ一覧を取得する最小コード（骨格）

以下はJavaScriptの fetch で1回だけ読み取る最小例です。Cloudflare Workersでも使えるWeb標準APIで記述しています。本番での取得成功は未確認で、スキの送信は行いません。

async function readNoteLikes(noteKey) {
  if (!/^n[a-zA-Z0-9]+$/.test(noteKey)) {
    throw new Error("記事キーを確認してください");
  }
  const response = await fetch(
    "https://note.com/api/v3/notes/" + noteKey + "/likes",
    {
      headers: { Accept: "application/json" },
      redirect: "manual",
      signal: AbortSignal.timeout(10_000),
    },
  );
  if (response.status !== 200) {
    throw new Error("取得を停止しました（HTTP " + response.status + "）");
  }
  if (!response.headers.get("content-type")?.includes("application/json")) {
    throw new Error("想定外の形式のため停止しました");
  }
  const payload = await response.json();
  const likes = payload?.data?.likes;
  if (!Array.isArray(likes)) {
    throw new Error("想定したdata.likesがありません");
  }
  return likes.flatMap((item) =>
    item?.user && typeof item.user === "object" ? [item.user] : [],
  );
}

// Workerのfetchハンドラーなど、実行する処理の内側から呼び出します。
// await readNoteLikes("nb87045e2da44");

これは通信の読み方を示す最小例です。現行note-likerの noteClient.ts は、タイムアウトや形式確認に加えてレスポンスのサイズも制限しています。 教材では、その既存の通信処理を使用します。

3-8. 【最重要】「一覧の取得」と「スキの送信」は別物である

技術を学ぶ上で、絶対に混同してはならない境界線があります。

それが、「一覧の取得」と「スキの送信」は、技術的にまったく別物であるという事実です。

読み取りにもサーバー負荷やアクセス制限への配慮が必要です。

一方で、スキの送信は「あなたのアカウントとして実際にリアクションを書き込む」操作であり、セッショントークン（ログイン情報）の取り扱いや、アクセス頻度の制御が必要となります。

4. 自動化で後悔しないための「安全設計」7つのチェックポイント

もしあなたが「スキの送信までプログラムで自動化したい」と考えるなら、適当なスクリプトを走らせてはいけません。プラットフォームに迷惑をかけず、自身のアカウントを健全に運用するためには、以下の7つの安全設計が必須となります。

4-1. ターゲットの自動選別フィルター

取得したユーザー全員に手当たり次第にスキを送っては、最初の手作業の失敗と同じです。

「直近で記事を投稿しているクリエイターだけに絞り込む」といった判定フィルターをプログラム側に組み込みます。

4-2. 同一ユーザーへの重複送信防止機構

昨日スキを送った相手に、今日も明日も自動でスキを送り続けたらどうなるでしょうか？ 相手からすれば不気味ですし、スパム行為と判断されてしまいます。

過去にアクションした相手と記事のIDを記録し、履歴を照合します。送信後にJSONへ追記するだけでは、同時実行や送信直後の異常終了で再送が起きます。送信前の予約、排他制御、結果不明時の停止も必要です。

4-3. 動作ログの記録と見える化

プログラムが動いている最中、「今誰をチェックし、何件スキップし、何件のアクションを完了したのか」が後から一目でわかるログ記録（ロギング）機能を設計します。

4-4. 万が一のエラー時に暴走させない「緊急停止機能」

ネットワークの不調や一時的な通信エラー（HTTP 429や403など）が発生した際、プログラムが無制限にリトライを繰り返すとサーバーに過度な負荷をかけてしまいます。異常を検知したら即座に処理を中断する安全弁（フェイルセーフ）を必ず設けます。

4-5. 自分の手で完全にコントロールできる実行管理

「完全放置」をうたう杜撰なツールに頼ってはいけません。実行したい時に手動でスタートし、止めたい時にコマンド一つで安全に止められる、自分自身の管理下に置く設計が重要です。

4-6. 最重要資産である「認証情報」を漏洩させない防壁

自身のアカウントにログインするための認証情報（Cookieやトークン）を、プログラムのコード内に直書きしてはいけません。万が一の流出を防ぐため、環境変数などで管理し、.envファイルを使う場合はGitの追跡対象から除外します。ファイルのアクセス権限を制限し、画面共有やログへの出力も避けてください。

4-7. 予告なき仕様変更に立ち向かう保守性

非公式APIである以上、いつ仕様が変わってもおかしくありません。エラーが起きた際に「通信のどこが変わったのか」を自分で調査し、素早くコードを修正できる保守性の高い設計にしておく必要があります。

5. 手作業の消耗戦から抜け出す「2つのルート」：B/C徹底比較

ここまで読んでいただき、ありがとうございます。

note運用の本質は、「手作業のルーティンに時間を溶かすこと」ではなく、「良質な記事を書き、それを本当に求めている読者に届けること」です。

そして、そのための巡回やデータ選定は、仕組み化によって大幅に効率化できます。

手作業の消耗戦から抜け出し、スマートな運用環境を手に入れるために、当サイトでは「自分で作って完全にコントロールする教材（B）」と、「運営がシステムを保守する既存サービス（C）」という2つの選択肢を用意しました。

【B】自分で構築する買い切り教材 vs 【C】既存サービス「note-liker」

教材Bを購入せずに、Cへ直接申し込めます。Cはいつでも解約でき、無料期間中に解約すれば請求されません。詳細はサービス紹介と販売条件をご確認ください。

約150件/日、約4,500件/月は実行するスキの目安で、獲得するスキ数ではありません。

あなたはどちらを選ぶべき？ 失敗しない判断基準

💡 ルートB（自作教材）が向いている方：

「教材代を買い切りにしたい」「自分でコードを書き換えて、除外条件などを細かくカスタマイズしたい」という方には、有料教材Bが最適です。プログラミングの基礎知識は必要ですが、自分だけの資産として自分のCloudflare環境で設定と保守を行えます。Workers、D1、Queues、Durable Objects、Cronを組み合わせた、現行note-likerの仕組みを扱います。

💡 ルートC（note-liker）が向いている方：

「環境構築でエラーが出てつまずきたくない」「noteの仕様が変わるたびにコードを直すなんて面倒」「とにかく今日からすぐに手作業の時間を減らしたい」という方には、クラウドサービスのnote-likerが最適です。まずは7日間の無料トライアルで、運用の手間がどれだけ軽くなるかを実際に体験してみてください。

お申込み・ご参加のご案内

【選択肢B】自分の手でシステムを構築・コントロールしたい方へ

重複防止ロジックから安全な定期実行まで、自作システムの構築を学ぶ教材を準備しています。

【買い切り2,980円予定】教材の内容と販売状況を見る

(※本教材はシステム構築手順を提供する教材であり、フォロワー増やスキ数の増加を保証するものではありません。著作権は著者に帰属します)

【選択肢C】今すぐ面倒な作業を手放し、執筆に専念したい方へ

利用者側での開発環境やCloudflareの構築は不要です。ブラウザから設定するだけで、手作業の消耗戦から解放されるクラウドツールです。

【7日間無料トライアル】既存サービス「note-liker」を試してみる

(※初期設定はお客様自身で行っていただく必要があります。利用規約をご確認の上お申し込みください)