note を使いたくても使えない理由と運営にお願いしたいこと
長年 note を使いたいと思っているが恒常的な利用に踏み切れない理由について今さらまとめる試み。
はじめに
note を使いたい理由と、使わない（使えない）理由がある。今回はそのことについてまとめようと思う。
簡単にまとめようと思ったのだが結局いつもの癖で長文・駄文になってしまったので、結論を先に述べると、note には公式 API (特に記事投稿用エンドポイント) とマークダウンの完全サポートをしてほしい。この 2 つを満たせれば note を本格的に使いたいと思えるし、特にエンジニアはそう思っている人が多いと予想する。
使いたい理由
まずは使いたい理由について述べようと思う。
見られる機会が多いから
インターネットを使っていて note を知らない日本人はあまりいないと思う。ネットでなにか調べ物をしていて、今までに一度も note の記事に出くわしたことがないっていうのは稀だと思う。また、ブログのように自分の考えていることや思っていること、日々の出来事などを発信したいと思ったとき、アメブロやはてなブログのような老舗のブログサービスが出てくるが、最近ではその中に note という選択肢が出てくるように思う。それくらい利用者や認知度は拡大していると考える。
そうなると必然的に自分が note で書いたときに見られる機会は、自前でブログを立ち上げるよりも多くなるはずだ。サービス全体として人気があることで Google などの検索エンジンでも優位に働く（SEO に強い）という側面もあれば、note という一つのプラットフォーム内でレコメンドされたりすることで多くの人の目に触れるという側面もある。
有料記事が書ける
これが note の中でも特に強みとなる機能だと思う。一昔前までのブログサービスというのは、無料で記事を書ける場を提供する代わりに、投稿者が収益化をするという機会はほぼなかったように思う。執筆で収益を得るには本を出版するなどのハードルの高いものであった。
しかし note の登場によりインターネット上にブログ感覚で記事を投稿し、その記事を有料に設定するだけで誰でも気軽に執筆で収益化ができるようになった。ホリエモンの言葉を拝借するなら「執筆による収益化の民主化」と言えるだろう。
これを個人レベルのブログで実装しようと思ったらそこそこ大変になる。支払い機能を自前で実装するか、Stripe に代表されるオンライン決済処理代行サービスを利用する必要がある。いずれも手軽にブログを始めるといった範疇からは大きく外れる。
それに、ユーザ（読者）に課金してもらうということは利用規約やプライバシーポリシーなども厳密に定義しなければならない。また、後述する静的サイトジェネレーターを使用してブログをホスティングする場合は上記のような課金システムを実装することは技術的に難しくなる。
従来の個人ブログの収益化モデルといったら広告ほぼ一択となるが、広告で稼ごうと思ったら一記事一記事に課される制約が大きくなる。広告主の機嫌を損ねる記事は書けないし、Google AdSense などの広告プラットフォーマーの意向にそぐわないといけない。
また「いかに他者にとって有益な文章が書けるか」ではなく「いかに閲覧数を稼げるか」に焦点が向き、数字のために書かれたどうでもいい記事がインターネットの海に散乱することが往々にしてある（断っておくがすべてがそうとは言わない）。YouTube に代表されるように、広告収益モデルが今でも主流であることを否定するつもりはないが、人類に提供できる価値を考えたときに、必ずしもこれが最適であるとは思えない。
それに、広告が蔓延することで汚染されると考える。広告だらけのウェブページは可読性が悪いし見た目を汚す。読者にとって表示される広告は異なる。自分のブログだとしても読者にどのように見えているのかを把握することができない嫌悪感は拭い難いものがある。
さらにいえばまったく興味のない広告が表示されることだってある。それでもその広告を表示するために、今も大量のトラフィックが広告表示のために費やされている。これも一種の汚染と言えるのかもしれない。
だいぶ広告の批判になってしまったが、それと違い読者から直接金銭を求める収益モデルは、本当に読者のために書かれる可能性が高い。少なくともそうしたインセンティブが働くと考える。それが note が流行った理由の一つでもあるのではないかと思う。単に「稼げる」だけでなく質の高いコンテンツが提供される仕組みが読者と著者の間に相乗効果を生んでいると捉えられる。
使わない（使えない）理由
正直なことを言えば note で思ったことや考えたこと、出来事などを日常的に書きたいという気持ちはかなり強い。書きたいことは山ほどある。もともと文章を書くことは（得意ではないが）好きなので、多くの人に見られるなら、そしてそれにより収益化が見込めるなら、かなり意欲的に執筆できそうな気がする。
しかし、冒頭で話したとおり、使わない理由がある。使えないというのは語弊があるのだが、筆者にはデータを残す際のポリシーがあり、note ではそのポリシーをどうしても満たすことが現状ではできないのであえて使わないと言ったほうが正しい。
ではそのポリシーとは何なのか。
Git / GitHub で執筆記事を管理したい
Git というのはプログラマー（エンジニア）に多く利用されるソースコード（プログラム）のバージョン管理システムだ。GitHub は Git によって管理されたソースコードをサーバ上にホスティングして複数人での開発を可能とする、世界で最も有名なプラットフォーム（サービス）である。バージョン管理システムとは何かについては本稿とは関係ないのでここでは割愛する。
本来、Git はソースコードを管理するためのツールなのだが、実はファイルであればなんでも管理することができる。つまりまさにこの記事のようなテキストデータもファイルとして手元のパソコンで執筆して保存しておけば Git で管理することができる。
そして、それを Web 上で管理できる GitHub には、GitHub Pages という便利なサービスが存在する。これは、まさにこういったブログ記事をインターネット上で公開できるサービスである。これを使えば記事の内容を変更履歴含めて細かくバージョン管理しつつ、Web サイト上で公開することができる。
これは非常に便利なサービスで筆者も愛用しているのだが、一方でほぼ個人ブログという位置づけになるので、SEO などがまっさらな状態から始めなければならない。また note のようにプラットフォーム化されているわけでもないので、同じ note 利用者の中でレコメンドされて発見してもらう、といったこともない。せいぜい SNS 等でリンクを貼って宣伝する、あるいは拡散してもらう程度だ。
なので、よほど優れた記事を定期的に書き続けて人気を得るか、もともとインフルエンサーで知名度がある場合を除き、あまり多くの人に見てもらうことはできない。また、先述したとおり、仮に多くの人が見てくれたとしても収益化をすることが難しい。
ならば、記事の元データは Git / GitHub で管理しつつ、それを note に公開することで、他の人に見てもらう際には note を見てもらうと言った手法が考えられる。ただし、手元のパソコンでファイルで書いたものを Git / GitHub で管理しつつ、それとは別で note にもコピペするというのは手間になる上に二重管理となってしまう。もし既存の記事を編集したいとなった場合も手元で編集してそれをまた note にコピペするという手間が毎回発生する。
これを解決する方法としては API を使って自動化するという方法がある。API が何なのかについても深入りすると説明が長くなりこの記事で伝えたいことから逸脱するため説明は省略するが、これを使えば
- 手元のファイルで記事を執筆する
- Git に記事を追加する
- GitHub にプッシュ（アップロード）する
- GitHub Actions で追加された記事を外部に投稿する
と言ったことができるようになる。そうすれば、GitHub にプッシュした記事が自動的に既存のブログサービス（たとえば note）に投稿されるようになるし、編集した際にも似たようなことをすれば自動化できる。
公式 API が提供されていない
しかし、note に記事をプログラム経由で投稿するためには API という仕組みが必要で、それは note が提供している必要がある。そして note は、残念ながらこの API の提供を公式でサポートしていない。
noteが公式で公開しているAPIはありますか？ – noteヘルプセンター
ちょっと調べると、非公式 API というものが見つかる。これは note が内部的に使用している API のエンドポイント（API の入口のようなもの）を、意図的に自身の書いたコードで使用することで note の Web 画面で行われているのと同等の処理をコード内で実行することができる、というものである。
しかし、あくまで「非公式」である。公式の場合は、具体的にどのようなエンドポイントがあって、どのようなパラメータ（入力値）を送るとどのような処理が実行されるというのをドキュメントとして公開してくれる。エンジニア（利用者）は、そのドキュメントを読みながらコード内でそのサービス内の処理を自動化したりデータを集計したり様々なことができる。
また、公式である以上は急に使えなくなったりしたら困るので、仕様変更などを行う際には API のバージョンを上げるなどして、既存の（古い）仕様で API を叩いていたとしても動作するように考慮してくれる場合が多い。
ところが note の場合は非公式なので、急な仕様変更があるかもしれない。もちろん非公式なのでアナウンスもされない。その場合は、その都度コードを書き換えないといけない。しかも公式でドキュメント化されているわけではないので、仕様が変更されたらどのような変更があったのかを自分で調査する必要がある。これが恒常的に利用したい場合には大きなコストとなる。
さらに問題はある。Git で管理された記事を自動的に note にアップロードするためには、記事投稿用のエンドポイントが必要になるが、どうやら note では記事投稿用のエンドポイントが存在していない……？ ようなのだ。
非公式 API の情報を軽くさらっただけで実際にどんなエンドポイントがあるのかなどを独自に調査したわけではないし実際に非公式 API を試したわけでもないので確かなことは言えない。実際、調べてみると記事を自動投稿するエンドポイントとそれを叩くためのサンプルコードを紹介している記事も見つかる。
うさぎでもわかる🐰note非公式APIで記事を自動投稿する方法｜taku_sid🐰エージェント
しかし、404 Not Found になってしまって結局 API の利用は諦めて手動投稿にする、といった技術記事も見つかった。
仮にうまいこと投稿を自動化できるような仕組みを構築できたとしても、仕様変更されたらそのたびにコードを改修しなければいけないのはコストだし、しかも先ほどの記事の自動投稿の方法を紹介する記事でも、ログイン部分はスクレイピング（API を叩かずに仮想的なブラウザをコード内で操作する手法）をしている。これは note の HTML が書き換わるだけで動作しなくなる可能性が高いので、非公式 API よりもさらに仕様変更に脆いコードとなる。さらに言えばスクレイピングはサーバ側に比較的負荷がかかりやすい処理だから運営側から制限をかけられる可能性もあるしスクレイピングができないように対策される可能性もある。
というわけで、現時点での筆者の結論としては、note に記事を自動投稿する仕組みを構築し、恒常的にそれを利用するのはあまり現実的ではないと判断した。
マークダウンが完全にはサポートされていない
もう一つ note を敬遠する理由がある。それはマークダウンが完全にはサポートされていないことだ。
マークダウンというのは構造化された文章を簡単に記述できる記法のことで、たとえば # 見出し と書くと見出しとして表示されたり、[note](https://note.com) と書くと note のようにテキスト付きのリンクを生成したりすることができる。他にも画像の貼り付けや太字、表などを表現する様々な記法が存在するが、それほど数は多くないのと比較的直感的に書けるというのがあり、特にエンジニアの間で人気の文書入力ツールとなっている。
note ではこのマークダウンを一部サポートしているものの、完全にはサポートされていない。
たとえば画像の貼り付けは（本来のマークダウンではサポートされているが）note のマークダウンではサポートされていない。また表の挿入もマークダウンではできない。
こうなると、Git での記事データの管理と相性が悪い。プレーンテキスト（テキストファイルに書き込んだ生のテキストデータ）をそのまま note 上できれいに表示することができないので、たとえば表を挿入したり画像を貼り付けたりしたかったら、ベースとなる文章（表や画像以外のテキスト部分）をコピペしたあとで note の編集画面上で手動で対応しなければならない。これは自動化からはかなり程遠いものとなる。
これは余談だが、note の編集画面はマークダウンを前提としているわけではないので、マークダウンで書こうが UI から装飾を選択しようが、その内容は編集画面上に即時反映される。たとえば見出しを書いたら、編集画面上でも文字が大きくなって表示される。
このような UI を WYSIWYG（ウィジウィグ; What You See Is What You Get (「見たままの通り」の意) のそれぞれの単語の頭文字を取ったアクロニム）と言うのだが、個人的にはこの WYSIWYG が好きではない。文章を入力したそばから装飾のついた文字に変換されてしまうので、その直前に装飾されていない文字を挿入したくなったときに融通が効かなかったりして入力しづらいことがあるからだ。成果物（執筆した記事）が読者に表示される際にはきれいなフォーマットで見せてほしいが、執筆はプレーンなほうがありがたい。コードでもブログ記事でもなんでも、なにか文字を入力する際はプレーンで入力したい派閥の人間だ。
まとめ
要するに note を（使いたくても）使わない理由は以下のとおりだ。
- 公式 API が提供されていない → 自動化が難しい → Git / GitHub で管理できない
- マークダウンが完全にサポートされていない → テキストファイルとして記事の内容を完全には管理できない → Git / GitHub で管理できない
そう、つまり、筆者は記事を Git / GitHub で管理したいのだ。Git で管理すれば
- 記事の細かい変更履歴を残すことができる
- 手元のパソコンに元データを保存しつつサーバ上（たとえば GitHub）にもそれと同じ内容のものを保存できる
- パソコンを新しくしてもサーバ上から簡単に手元に同じものを複製できる（note のようなサービスであればエクスポート機能がそれに該当する）
- 特定のサービスでエクスポートできるデータのフォーマットに依存しない（移行が非常に容易）
といったメリットを享受することができる。
特定のサービスにデータ（note でいうそれぞれの記事）を依存するのはできる限り避けたいという思いがある。どのサービスがいつ終了するかわからない。その「いつか」のために使っている大量のサービスで定期的にエクスポートを行うのは骨が折れる。それにエクスポートされたデータのフォーマットはそれぞれのサービスでまちまちだ。今後もっといいサービスが現れて引っ越しをしたいとなったとき、今まで使っていたサービスとこれから新しく使うサービスで、エクスポート・インポートできるデータのフォーマットが異なれば容易に移行はできない。ましてやエクスポート機能がないサービスなどもってのほかだ。
だから、そういったサービスはあくまでインターフェースとして活用し、大切なデータは Git で管理したい。それを実現するための API やマークダウンの完全なサポートは、筆者にとって最も重要な要件である。
おわりに
まあこれは筆者自身がエンジニアであり、エンジニアに極端に偏った意見であることは重々承知している。note はエンジニアのための記事投稿サービスではなく、もっと幅広い利用者を対象としたサービスであるから、note 側がこれらのニーシュな要望を満たすインセンティブは低いのだろう。
しかし、技術的な発信をしている note の利用者も多く見受けられるので、少なくともエンジニアからも支持されているサービスであることは間違いないはずだ。それに、非公式 API 一覧を作っている人も多々見かけるので、API の需要があることも確かだ。
この 2 つさえ満たせれば note をメインの発信の場とすることができるのにな、と思いつつ、アカウントの作成から早 5 年が経過した。5 年経っても未だに公式 API の提供すらないということなのだから、やはり note を使うのは諦めるべきなのだろうか……。あるいは、自分のポリシーを曲げてでも note に迎合して小銭を稼ぐべきなのだろうか……。note に対する批判のようにも受け取られると思うが、それだけ note は魅力的であり、また期待しているのである。これが note の運営に届き、これらの機能が提供・改善されることを願うばかりである。
もしよければページ下からこの記事のリアクションをつけてもらえるとありがたいです。このブログは収益化をしていないため、みなさんのリアクションが更新継続の励みになります。