3つのツールが全部、認証なしで動く理由｜おはようカノジョ ＃90
はじめに
「おはようカノジョ」は、毎朝7:30に彼女がいってらっしゃいを言ってくれるXアカウント。 このプロジェクトの過程で、3つの個人ツールを作った。
どれもnoteのAPIを使っている。 ただし、noteは公式にAPIを公開していない。ブラウザでnoteを開いたときに裏側で呼ばれているエンドポイントを、自分のツールから叩いている。いわゆる「非公式API」だ。
その非公式APIの中にも、認証なしで誰でもアクセスできるものと、ログインしなければ返ってこないデータを扱うものがある。
自分の3つのツールは、全部前者——認証不要で、公開データだけを返すAPIしか使っていない。
偶然そうなったのか、意図してそうしたのか。
今回は、その線引きの話をする。
きっかけは、他人のBANだった
2月末、とらねこさんがnoteで記事を出した。 あるクリエイターがアカウントBANされた件についての考察記事だ。
BANの理由として推測されていたのは、非公式APIの中でも認証が必要なエンドポイントへのアクセスだった。
noteのフォロワーリストには、ブラウザで見える上限がある。 その上限を超えたデータ——つまりログインしなければ取得できないデータにアクセスし、それを他人向けのサービスとして提供していた疑いがあるという内容だった。
読んだ瞬間、背筋が冷えた。
自分もnoteのAPIを使っている。
3つのツールの棚卸し
冷静になって、自分のツールを1つずつ確認した。 どれもnoteの非公式APIを使っている。ただし、叩いているのは認証不要のエンドポイントだけだ。
積み上げノート
noteのフォロワー数の推移を記録するツール。 叩いているのは /api/v2/creators/{urlname} だけ。 これはブラウザでnoteのプロフィールページを開いたときに、裏側で呼ばれているのと同じエンドポイント。
取得しているのは公開プロフィール情報。フォロワー数、記事数、アイコン。 誰でもnoteのプロフィールページを見れば確認できる情報しか取っていない。
おはヨミ
朝の読書リストを管理するツール。 これもAPIとしては積み上げノートと同じエンドポイントを使っている。 複数のクリエイターの最新記事を一覧表示するために、記事一覧のAPIも叩いている。
叩いているのは /api/v2/creators/{urlname}/contents で、公開記事の一覧を返す。 noteのクリエイターページをブラウザでスクロールしたときに読み込まれるのと同じデータ。
おへんじ帖
記事へのコメントの未返信状況を管理するツール。 3つの中では最もAPIの呼び出しが多い。
記事一覧を取得して、コメントがある記事だけ、コメントの詳細を取得する。 使っているのは /api/v3/notes/{note_key}/note_comments。 これもnoteの記事ページのコメント欄を開いたときに読み込まれる、公開データ。
共通する「3つの制約」
3つのツールに共通しているのは、以下の3点だ。
認証していない。 ログイン不要で取得できるデータしか使っていない。noteアカウントのトークンやCookieを渡す仕組みは一切ない。
書き込みしていない。 データを読むだけ。自動スキ、自動フォロー、自動コメントのような書き込み操作はしていない。
認証が必要なデータに触れていない。 フォロワーの詳細リスト、下書き記事、非公開のアクセス解析データなど、ログインしなければ見えない情報には一切アクセスしていない。
つまり、3つのツールは「ログインせずに取れる公開情報だけを読む」設計で揃っていた。
意図していたのか
正直に言うと、最初から「安全設計」を意識してこうしたわけではない。
積み上げノートを作ったとき、いちばん簡単にフォロワー数を取得できる方法が、認証不要の公開APIだった。ログイン処理を実装するのは面倒だったし、そもそも必要がなかった。
おはヨミも同じ。公開記事の一覧が欲しいだけだから、公開APIで十分だった。
おへんじ帖のときだけ少し迷った。「自分の記事への未返信コメント」を取得するなら、認証を通した方が正確なデータが取れる可能性があった。でも、公開コメント欄のデータで十分判定できることがわかったので、認証なしのまま実装した。
つまり、セキュリティ意識から制約を設けたのではなく、必要がなかったから公開APIに収まった、というのが実態だ。
「たまたま」を「設計」に変える
とらねこさんの記事を読んで、偶然の判断を振り返った。
BANされたケースでは、非公式APIの中でも認証が必要なエンドポイントにアクセスし、そのデータを他人向けのサービスとして提供していた。自動操作（botによるスキやフォロー）の疑いもあった。
自分のツールとの距離感を測ると、次元が違う。 でも、「今は大丈夫」と「これからも大丈夫」は別の話だ。
noteが「非公式APIの利用全面禁止」に舵を切る可能性は、ゼロではない。 Cloudflare Workersでプロキシを挟んでいる時点で、noteが想定しているアクセスパターンとは違う。
そこで、「たまたま安全だった」ことを「設計として残す」ことにした。
3つの制約をルールとして明文化する：
認証しない — ログインなしで取得できるデータだけを使う
書き込まない — 読み取り専用。APIに対してPOST/PUT/DELETEしない
認証が必要なデータに触れない — ブラウザで誰でも見られる情報だけを扱う
この3つを守っている限り、ツールが取得しているのは「noteのページを開いたときにブラウザが受け取っているのと同じデータ」に過ぎない。
Cloudflare Workersのログも見た
ついでに、プロキシのアクセスログも確認した。
Cloudflareのダッシュボードで過去24時間のリクエスト数を見ると、約1,000回。一般的なWebサイトのトラフィックとしては小さい数字だが、APIアクセスとして見ると少し気になる。ただ、おへんじ帖でコメント一覧を取得するときに記事数×APIコールで数十リクエスト飛ぶことを考えると、納得できる範囲だった。
問題になりやすいのは、万単位のリクエストや書き込み操作を伴うケースだと理解している。その前提で見ると、1日1,000回程度の読み取りは、今の自分の利用規模では過剰とは感じていない。
ただ、週1でメトリクスを確認する運用は入れた。急に5,000や10,000に跳ねていたら、公開URLを誰かがbotで叩いている可能性がある。
おわりに
自分のツールは安全なのか。 そう問い直したとき、たまたま安全だったことに気づいた。
だから、それを設計に変えた。
関連記事
凛華の一言
でもさ、あなたの「たまたま」、ちゃんと意図に変えてる？
おまけ
KITAcoreさんが「睨まれたい」と言ってたので…
👉「おはようカノジョ」は @ohayo_kanojo で毎朝7:30に投稿しています
#生成AI #AIイラスト #プログラミング
#個人開発 #開発日記 #記録 #実体験
#朝活 #AIイラストアイラ
#AI活用 #失敗から学ぶ