フォロー中が1,300人台になって困ったこと
私は、noteで相互フォローを中心にフォローを増やしてきました。気づくと、フォロー中が1,300人台になっています。人数が増えるほど、タイムラインは流れてしまい、読みたい人の記事が埋もれます。そこで、フォローの整理（棚卸し）をすることにしました。
手作業で整理するなら、1人ずつプロフィールを開き、「フォロー中」のボタンから解除することになります。1,300人を、活動状況を見ながら判断するのは、現実的ではありません。そこで、確認しながら少しずつ外せる自作ツールを作りました。この連載は、その設計から運用までの記録です。
整理の基準は、次の2つに絞りました。
- 最近、記事を書いたり、スキをしたりしていない人（活動していない人）
- 自分をフォローしてくれていない人（フォロバなしの人）
ただし、ツールに任せきりにはしません。「調べる」までを自動化し、「外す」前には、必ず自分の目で一覧を確認する運用にしました。
2026年10月時点で確認できたこと
最初に、公式の機能を確認しました。画面から1人ずつ解除する方法しか見つからず、フォロー中の人をまとめて整理する機能は確認できませんでした。note株式会社は、法人向けに外部サービスから記事を作成・管理できるAPIの提供開始を発表しています（発表ページ）。ただし、題名から読み取れる対象は記事の作成・管理で、フォローの整理に使えるものは見つけられませんでした。
そこで、noteのWebサイトが内部で使っている、公開されていないAPI（以下、非公式API）を調べることにしました。先行して調べている方々の記事が、大きな手がかりになりました。たとえば、2026年版のエンドポイントを調査した記事や、フォロワーが1,000人までしか確認できないことを報告した記事です。
ただし、非公式APIは、予告なく変わります。記事の内容を鵜呑みにせず、必ず自分の環境で確かめ直しました。この連載に書く内容は、すべて2026年10月時点のものです。
非公式APIを使う前に決めた5つのルール
非公式APIは、noteが公開を約束しているものではありません。使うなら、自分で守るルールを、先に決めておく必要があります。私が決めたのは、次の5つです。
- 対象は自分のアカウントだけ。他人の情報を集める用途には使わない。
- アクセスは少なく、ゆっくり。通常は1秒間隔、解除は5〜10秒おきに、1回20人まで。
- パスワードは扱わない。ログインが必要な処理は、ブラウザでログイン済みの情報を、一時的に渡す方式にする。
- 実行の前に、人が確認できる形にする。既定は一覧表示だけにする。
- おかしな応答が返ったら、その場で止まる。
noteの利用規約は変更されることがあり、自動化した操作が制限される可能性もあります。実行する前に、最新の利用規約を確認してください。この連載は個人の検証の記録で、noteとは無関係です。
先に分かった仕様上の制約
設計に入る前に、仕様上の制約を洗い出しました。ここで知ったことが、後の設計を大きく左右しました。
| 制約 | 内容 | 設計への影響 |
|---|---|---|
| 一覧の表示上限 | フォロー中・フォロワーの一覧は、新しい順に1,000人まで。51ページ目は空 | 1,000人を超える分は、一覧から見えない。別の手段で補う（第3回） |
| フォローした日 | 一覧の1人分の項目に、日付は含まれない | 新規フォローの保護を、別の方法で行う（第6回） |
| 1日のフォロー上限 | 約100人と報告されている（公式には非公開の推定値） | 保護する人数の目安に使う（第6回） |
| 書き込みの認証 | 解除には、ログイン状態が必要 | Cookieを一時的に渡す（第4回） |
特に、一覧が1,000人までしか見えない点は、「フォロワー一覧と照合して、フォロバなしを探す」という素朴な方法が、そのままでは使えないことを意味していました。
設計方針：調べる処理と外す処理を分ける
全体は、3つのスクリプトに分けました。①活動チェック、②フォロバなしチェック、③フォロー解除です。①と②は、結果をCSVファイルに書き出します。③は、そのCSVを読んで解除します。処理を分けて、間にCSVを挟むのには、理由があります。
- 解除する前に、人がCSVを開いて確認し、外したくない人を除外できる。
- 調べる処理は時間がかかるが、解除は、同じCSVを使って、少しずつ何度でも実行できる。
- 解除が途中で失敗しても、調べ直さなくてよい。
もう1つの方針は、解除の既定を「一覧表示だけ」にしたことです。実際に外すのは、--executeを付けたときだけです。
python note_unfollow.py # 一覧を表示するだけ（解除しない）
python note_unfollow.py --execute # 確認のうえ、実際に解除する安全装置は、最初から設計に入れる
安全装置は、後から付け足すと抜けが出ます。そこで、最初から次の仕組みを、設計に含めました。実装の詳細は、第4回と第6回で書きます。
- フォローしたばかりの人は、一定期間、対象から外す（新規保護）
- 外したくない人のリスト（ホワイトリスト）
- 解除の直前に、もう一度、相手の状態を確認する
- CSVが古いときは、解除を中止する
- 失敗が続いたら、自動で止まる
- 解除の記録を、ログに残す
「調べた時点」と「外す時点」の間にも、状況は変わります。たとえば、調べた後で相手がフォローを返してくれることもあります。誤って外さないための工夫が、この連載の中心テーマの1つです。
この連載の全体像と、使った技術
連載は、実際に作業を進めた順に、全6回で構成しています。各回は、単独でも読めるようにしました。
- 第1回（この記事）：設計と調査
- 第2回：活動していない人を見つける判定ロジック
- 第3回：フォロバなしの判定と、1,000人の壁
- 第4回：フォロー解除の実装と、安全設計
- 第5回：設定のJSON化と、画面（GUI）化
- 第6回：トラブルシューティング
開発は、「調べる処理」から順に作り、通信を伴わない部分は、そのつど、模擬データでテストしました。実際のnoteに対する動作は、少人数から試して確かめる、という進め方を徹底しています。
使った技術は、Pythonの標準ライブラリと、requests・tzdata、そして設定を保存するJSONファイルだけです。有料のツールやサービスは、使っていません。検証環境は、WindowsとPython 3.9以上です。
まとめ
第1回では、整理ツールを作る動機と、2026年10月時点で確認できた仕様、そして設計方針をまとめました。要点は、次の3つです。
- 公式のまとめて整理する機能は確認できず、非公式APIを、自分のアカウントの範囲で、慎重に使う。
- 一覧は1,000人までしか見えないなど、仕様上の制約を先に洗い出す。
- 調べる処理と外す処理を分け、既定は一覧表示だけにして、人が確認する。
次回は、活動していない人を見つける「活動チェック」の判定ロジックと、そこで出会った落とし穴を紹介します。
