開発者がコンテンツでオーディエンスを築く方法 — Blog・YouTube・Newsletter・Twitter、2026年のクラフト(深掘り) 日本語

プロローグ — 2026年、コンテンツを作る理由が変わった

10年前、開発者が blog を書く理由はシンプルだった。「Google に検索されて、将来の雇用主に見つけてもらう。」それだけ。

2026年は違う。3つの discovery surface がほぼ同時に崩れて、別の形でまた立ち上がった。

• SEO の死と再生。 Google の AI Overviews(旧 SGE)、Perplexity、ChatGPT search が SERP を蝕んだ。「クリックが起こらない検索」が default。analytics graph は下がる。それでも — あなたの文章は前より多く読まれている。ただし、人間ではなく LLM に。
• LLM があなたの文章を読む。 training data で1回、推論で毎日 N回。ChatGPT が「Next.js 13 で ISR はどうやる?」に答えるとき、その答えの一部は誰かの blog だった。その誰かがあなたになり得る。「LLM に引用されるように書く」のが SEO の新しい定義。
• Discovery はアルゴリズムに移った。 Twitter/X For You、LinkedIn feed、YouTube の recommendation、dev.to の trending、Hacker News の front page — 検索ではなくアルゴリズムが新しい読者へあなたを連れていく。検索は「再訪問」の surface で、アルゴリズムは「発見」の surface。

変わっていないこともある。文章が上手い開発者は今でも稀。 AI が average を無料化したぶん、稀がもっと稀になった。average は LLM が5秒で吐く。あなたにしか書けないもの — 圧縮された1時間の experience、狭く深い taste、正直な failure — だけが生き残る。

この記事は monetize ではなく craft の話。広告単価、sponsorship、paid membership の conversion は別記事。ここでは 何を作るか、どう始めるか、どの channel に何が合うか、自分の voice の見つけ方、やってはいけないこと を扱う。

先に結論 — 2026年で最も過小評価されている1つの channel は 自分の domain で動き続ける personal blog 。13章で擁護する。

---

1章 · 何を書くか・撮るか — コンテンツの4象限

blog を始めるときの最も多い詰まりは「書くことがない」ではない。**「書くことが多すぎてどれを書けばいいか分からない」**だ。4象限で整理するときれい。

• Tutorial + Search — long shelf life、slow start。1本良く書けば5年もつ。LLM が最も引用する。blog、dev.to、自分の domain が合う。
• Tutorial + Algorithm — short burst、fast feedback。YouTube、Twitter thread が合う。Fireship モデル。
• Essay + Search — long shelf life に authority が乗る。最も難しく、最も価値がある。自分の domain blog と Hacker News。
• Essay + Algorithm — 最速の audience build。Twitter、LinkedIn の short-form。risk は volatile で trust が積み上がらないこと。

最初は1象限を選ぶ。4つ同時にやると4つとも中途半端になる。最も安全な選択は Tutorial + Search を6か月、その後にもう1象限を足す。理由 — 検証が即時(コードが動けば文章は正しい)、self-esteem の barrier が低い(説明そのものが価値)、LLM が引用する。

アイデアが尽きない3つの鉱脈

1. 「今日検索したけど答えがなかったこと。」 最良の鉱脈。答えがない = market がある。その日の夜に書く。
2. 「自分の PR で senior が指摘したこと。」 検証済みの学び。「Code review で学んだ N個」シリーズは枯れない。
3. 「6か月前の自分に送りたい文章。」 最も authenticity がある。読者は常に6か月前のあなた。

書いてはいけないもの

• "OOO とは何か?" 系 — Wikipedia と LLM に勝てない。
• 1次出典のない summary 記事 — 価値が負。
• 会社自慢の記事 — careers ページでやる。
• "10個の X" 系 listicle — 2018年に終わった。

---

2章 · 小さく始める — 最初の100本ルール

content creation の最大の嘘は「continuous にやれ」。抽象すぎて行動にならない。実戦の rule は2つ。

Rule 1 — 最初の100本は捨てるつもりで書く

成功した開発系 creator のほぼ全員が同じことを言う。「最初の1年に書いた文章はひどかった。」Fireship、Theo、Josh Comeau、Lee Robinson、Dan Abramov、全員。最初の100本は 自分の voice を見つける期間 であって、audience を得る期間ではない。

YouTube なら最初の30本。Twitter なら最初の500 tweet。newsletter なら最初の20号。この時期に「なぜバズらない?」を問うのは1 km 走って「なぜマラソンで優勝できない?」を問うのと同じ。

Rule 2 — 投稿頻度は週1本、ただし6か月間

頻度が肝だが、設定が高すぎると折れる。週1本、6か月(= 26本) が最も検証された entry slot。その後は本人が増やすか減らすか決める。

毎日書く必要はない。毎日 収集 する。その日触れたコード、詰まった問題、良かった PR comment — 小さな note に残す。日曜の夜にそのうち1つを選び、記事にする。Cleanshot で screenshot、Notion で draft、月曜の朝に自分の blog へ移す。

「小さく」の本当の意味

• 800字でも記事。2,000字が平均だが、完結すれば800字で十分。最初は短く。
• 1記事に1つの結論。2つ入れると両方弱くなる。
• code snippet は1〜3個で十分。5個以上ならその記事は GitHub repo になるべきだった。
• 表紙画像はテキスト1行で十分。Figma は良いが、最初はその時間を文章に使う。

---

3章 · Channel 経済学 — 5つの surface を一望

この表が記事の中心。channel ごとに時間・audience・depth・monetize・AI 時代の影響が違う。

一行サマリ

• Personal blog — 長期戦。AI 時代の追い風が最強、2026年で最も過小評価。13章。
• YouTube — 最速の audience、最も高い制作 cost。Fireship モデルは模倣しづらい。
• Newsletter — 「自分が所有する channel」の唯一の答え。2025年の trend は Substack → Beehiiv。
• Twitter/X・LinkedIn — distribution surface。home base ではない。別の場所へ traffic を送る道具。
• dev.to・Hashnode — 最初の読者を得る bootstrap。home base は自分の domain。

---

4章 · Personal Blog — 長期戦の home base

先に結論。すべての開発者は自分の domain の blog を持つべき。 channel 選択の前にある foundation。

なぜ自分の domain か

• Data の所有。 Medium・dev.to・Hashnode は政策をいつでも変える。Medium は2020年に paywall を入れた。dev.to はアルゴリズムを頻繁に変える。domain はあなたのもの。
• URL stability = LLM 引用 stability。 LLM が学ぶ時、URL が変わらないことで引用が安定する。domain hosting は platform より長生き。
• 信頼の重み。 yourname.dev/post と medium.com/@username/post は違って読まれる。前者の方が authority が乗る。
• Portfolio と融合。 blog + about + projects が1 domain にあれば自己紹介が完結する。

Stack

最も多い組み合わせ — Next.js + MDX + Tailwind + Vercel 。この blog もそう。代替。

• Astro — 最速の build、最軽量の static site。2025年で share が急上昇。
• Hugo — build が本当に速い。Go template の学習 curve あり。
• Jekyll + GitHub Pages — 0円、0運用。analytics が弱いのが trade-off。
• Notion → 静的 site (Notion API + Next.js) — 執筆 UX は最高、検索の重みは下がる。

運用 5原則

1. 1記事に1 URL、永遠に。 URL を変えない。redirect しても LLM 引用は損なわれる。
2. RSS は ON。 死んでない。むしろ復活。RSS reader はアルゴリズム疲れの人達の home base。
3. 多言語を真剣に。 韓国語のみの blog は pool の5%。English + Japanese + Korean の triple なら pool が100倍。AI 翻訳は2024年から十分に良い。
4. 検索を block しない。 robots.txt で GPTBot・ClaudeBot・Google-Extended を全部 block するのは LLM 引用を捨てるのと同じ。policy は本人の選択。2026年に llms.txt standard も定着、追加推奨。
5. Comment は無くてもいい。 Disqus は重いし広告がつく。GitHub Discussions を繋ぐか、Twitter reply の link を貼るかでいい。

最初の6か月の目標

• 26本(週1本 × 26週)
• RSS subscriber 100人
• 1本が Hacker News top 30 入り(無ければもう6か月)
• LLM 引用を一度試す(自分の記事 title を ChatGPT で検索して source に出るか確認)

---

5章 · YouTube — Fireship モデルは真似できるか

Fireship(Jeff Delaney)の100秒シリーズは開発系 YouTube の標準を書き換えた。2026年時点で約350万 subscriber、1動画あたり1〜5百万 view。真似する人は多いが、本当に成功した人は少ない。理由を見る。

Fireship モデルの解剖

• 1本100秒〜8分。 「退屈する時間を与えない」が第1 rule。
• 平均 cut 間隔1〜3秒。 視覚刺激が止まらない。
• B-roll が圧倒。 コードだけ見せない。meme・illustration・screen capture・短い映像が overlay。
• Title こそ hook。 "Next.js in 100 seconds." 検索とアルゴリズム両方を取る。
• 圧縮率。 6時間分の docs を100秒へ。これが最も難しい。

入門者が真似しづらい理由

• 1本あたり平均10〜20時間の編集。本業ありでは無理。
• 1秒単位の編集 sense は1年以上の訓練が必要。
• 100秒に圧縮する curation は5年以上の経験が前提。

入門者に向く YouTube モデル3つ

1. Theo / t3.gg モデル — "live + 整理"。 live coding や live reaction を撮って切る。自然さが武器、編集は軽い。
2. Primeagen モデル — "code review live"。 他人のコードや PR を見ながら意見を出す。content source が無限。
3. Josh tried Coding モデル — "essay 動画"。 slide + 音声 + たまにコード。編集軽め、depth は深い。

入門者にとって100秒モデルは罠。最初の30本は「10分で1テーマをちゃんと説明する」が安全。

Tool stack

• 録画 — Descript(編集と録画統合)、Loom(最も簡単)、OBS(最も自由)、Riverside(高品質 interview)。
• 編集 — Descript(テキストベース)、Final Cut Pro / DaVinci Resolve(正統)。
• Thumbnail — Figma + Photoshop。最初は Figma だけ。
• 音声 — Shure SM7B は贅沢。Rode NT-USB Mini で十分に始められる。

---

6章 · Newsletter — 所有 channel の唯一の答え

2026年の distribution の真実を一行。アルゴリズムは借りるもの、email list は所有するもの。 Twitter が X になり、アルゴリズムが4回変わる間も、email list はあなたのまま。

3 platform 比較(2026年基準)

2025年の trend を一行。「Substack から Beehiiv への移住」。政治論争と algorithm volatility で Casey Newton、Lenny Rachitsky 等の top が Beehiiv や self-host へ移った。新規 starter には Beehiiv が安全な default。

Newsletter の content モデル3つ

1. Curation + commentary — 「今週の dev news + 自分の一言」。 entry が最も易しく、最も長く回る。The Pragmatic Engineer、Tech Ladders、JavaScript Weekly。
2. Deep dive — 「週1テーマで5,000字」。 最も難しく、最も価値がある。Pragmatic Engineer paid、Lenny's Newsletter。
3. 「My week」 — 開発者の1週間日記。 軽いが trust 蓄積に強い。素材切れの risk。

運用原則

• 隔週が一番回る。 毎週は本業が揺れ、月1は忘れられる。
• 最初の100人は1次・2次人脈で埋める。 「email を50人に直接送る」が全 newsletter の起点。
• Blog → newsletter の自動転送を ON。 blog が home base で newsletter はその digest。RSS-to-Email。
• Paywall は遅く。 無料 subscriber 1,000人を超える前に paid 化すると無料 pool が育たない。

---

7章 · Twitter/X・LinkedIn・Bluesky — Distribution surface

home base ではない。home base へ traffic を送る道具。この区別ができないと Twitter 中毒で終わる。

2026年の現況

• Twitter/X — 開発系 distribution の依然 No.1。For You アルゴリズムは外部 link を down-rank すると見られて、image・thread が強い。API 閉鎖以降、外部 tool eco は崩壊。
• LinkedIn — senior 開発者・manager の pool が最大。tone が違う:1人称 story、改行多め、emoji 抑制。外部 link にアルゴリズム penalty があるとされ、最初の comment に link を貼る pattern が標準。
• Bluesky — 2024〜2025 の爆発後、2026 で成長鈍化。開発 community は一部移ったが discovery が弱い。「tech Twitter の一部」程度。
• Threads — Meta の答え。2026 で巨大化したが開発 community 占有率は低い。
• Mastodon — 小さくても固い community。fediverse 好きの開発者集団が home。

良い tweet の5 pattern

1. 断言 + 根拠 — 「ORM は95%のケースで損。理由3つ。」 続きは reply で展開。
2. 逆転の opener — 「みんな React 好きだが、私は7年 Backbone を使ってる。理由:」 curiosity がアルゴリズムに刺さる。
3. Screenshot が body。 code screenshot は tweet 本文より長くてもいい。Carbon、Ray.so、Cleanshot。
4. 数字1個。 「12倍速」「47%減」「わずか3分で」。tweet 1本に正確な数字を1個。
5. Thread は7個以内。 長くなると離脱する。depth は home base(blog)へ。

LinkedIn tone の細部

• 1行目 = hook。「今日 team が4時間で data loss を復旧した。」
• 2行目 = 改行。
• 短い段落。1段落1〜2文。
• 最後の行に question。「あなたならどうした?」
• 外部 link は最初の comment へ(penalty 回避)。
• emoji は0〜1個。営業のように見せない。

やってはいけないこと

• Twitter を home base にする — アルゴリズムは借り物。
• LinkedIn を「就活 tone」にしすぎる — senior は瞬時に見抜く。
• Bluesky に賭けきる — distribution が弱い。

---

8章 · Community surface — dev.to・Hashnode・Hacker News・Lobsters

home base でも distribution でもない、community bootstrap。最初の読者を連れてくる速い入り口。

dev.to

• 強み — entry が最も簡単。Markdown をそのまま貼れる。初投稿でも50〜500 view。
• 弱み — アルゴリズムが頻繁に変わる。SEO が自分の domain より弱い。data 所有0%。
• 2026 活用 — 自分の blog に先に公開 → 7日後 canonical URL を付けて dev.to に cross-post。両取り。

Hashnode

• 自分の domain mapping が無料 — dev.to の一段上。
• ただし build が host 依存 — data export は可能だが Next.js ほど自由ではない。
• 最初の6か月の bootstrap には良い。1年後に自分の stack に移住。

Hacker News

• 開発 discovery の頂点。一度 front page に入れば通常50,000〜500,000 view。
• 投稿の仕方 — 自分で投稿せず友人に任せる。spam ring は即 ban。最も安全なのは「投げて忘れる」。
• 時間帯 — UTC 14:00〜20:00 に新しい記事が乗りやすい。週末は traffic 少ないが競争も少ない。
• title は本文1文目より強くする。「Why X」 より「X is broken. Here is why.」

Lobsters

• HN より狭く深い。systems・languages・security が強い。
• 招待制 — 招待が barrier だが、入れば comment 品質が最高。
• 一度 first page に入っても traffic は HN の1/20、でも comment は最深。

Reddit r/programming · r/webdev · r/golang etc.

• subreddit ごとに rule が厳しい。self-promotion を禁じる場所も多い。
• でも刺さると HN の次の traffic。投稿前にその subreddit の rule を熟読。

---

9章 · Conference talk · Podcast — Slow channel

content building の最後の2 surface。速い channel ではない。ただし、1本良く作れば 5年もつ trust が積み上がる。

Conference talk

• 最初の talk は地元の meetup。 30分、聴衆30人。恐怖を削る。
• 次は地域 conference。 JSConf KR、FEConf、PyCon KR、NDC、DEVIEW。CFP 締切を calendar に。
• Global はその次。 React Summit、JSNation、KubeCon。talk video が YouTube に上がれば、それがそのまま content。
• CFP の書き方。 title + 5文 abstract + 3文 takeaway。普段 blog で書いている topic がそのまま素材。

Podcast

自分で host する podcast は推奨しない。時間がかかりすぎて、最初の6か月で listener 30人を超えるのが難しい。代わりに 他人の podcast に guest で出る。

• Latent Space — AI engineer podcast の頂点。Swyx と Alessio。
• Changelog — open source・developer interview の standard。10年以上続く。
• Software Engineering Daily — 毎日新しい interview。guest pool が最大。
• CoRecursive — developer storytelling。深さがある。
• 日本 — Rebuild.fm、fukabori.fm、Misreading Chat、ajitofm 等。

guest に呼ばれるには — 自分の blog に良い記事5〜10本が必要。それが名刺。

---

10章 · Tool stack — 2026 standard

最後の実用章。書く道具がそのまま自分の手になる。

執筆 flow

• 収集 — Apple Notes か Bear。速く。
• 下書き — Notion。multimedia 埋め込みと collab が良い。
• 公開 — MDX (自分の blog)。VS Code + Markdown All in One + Vale。
• 画像 — Cleanshot X(screenshot)、Figma(thumbnail・絵)、Excalidraw(diagram)、Carbon・Ray.so(code 画像)。

動画・録画

• 録画 — Loom(簡単)、Descript(録画+編集)、OBS(自由)。
• 編集 — Descript(テキストベース)、Final Cut Pro / DaVinci Resolve(正統)。
• Transcript — Whisper Large v3(OSS)、MacWhisper(Mac UI)。

Newsletter

• Beehiiv — 新規 default。
• Substack — 既に pool があるなら維持。
• Buttondown — 開発者寄りの minimal。

Analytics

• Plausible / Umami — cookieless、軽量。
• Posthog — 深い analytics 必要時。
• Google Analytics は2026年には非推奨。

AI 補助

• Claude / ChatGPT — 草稿の磨き、文法 check。
• Grammarly — 英文のみ。
• DeepL — 多言語翻訳。Korean → English → Japanese workflow の core。
• 絶対に — LLM に結論を決めさせない。 結論は人間。LLM は polish。

---

11章 · 自分の voice の見つけ方

この記事で最も抽象的、最も重要。tool と channel は1年で身につく。自分の voice は5年かかる。

Voice は発見ではなく彫る

最初は好きな writer の tone を真似る。自然で推奨される。1年経つと真似た tone が衝突し始める。その衝突点で自分の tone が出る。

• Dan Abramov の言 — 「複雑なものを簡単に説明するな、簡単なものを正確に説明しろ。」
• Julia Evans の illustration — 「今日学んだ小さな1片。」
• Patrick McKenzie (patio11) の business 視点 — 「このコードは誰の金をどう動かすか。」
• jbee(韓国開発 blogger)— 正直な1人称と anti-hype。
• 日本 — mizchi の率直な opinion、ymotongpoo の長文 essay、Songmu の深い OSS 系 post。

あなたはそれらのどの組み合わせ?どこで自分の tone が出る?1年分を一気に再読すると見える。

Tone を早く見つける4 exercise

1. 自分の1年分を一気に読む。 繰り返す word、繰り返す文型 — それが自分の tone。
2. 親しい5人に自分の記事3本を見せる。 「これ誰が書いたっぽい?」の答えが tone。
3. 絶対使わない word を10個書き出す。 "leverage"・"synergy"・"incredible" — 使わない word が tone を作る。
4. 1記事を声に出して録音して聞く。 自分の口調と違いすぎたら、それは仮面。

Option vs Opinion

開発 content tone の最大の二極。

• Option 記事 — 「A・B・C があり、各々こういう pros/cons。」 balanced だが忘れられる。
• Opinion 記事 — 「B を使え。A は罠、C は overkill。」 叩かれるが、覚えられる。

最初は option 記事から。書き続ければ opinion が自然に出る。出てきたら恐れず opinion を書く。無関心より反対の方が良い。

---

12章 · AI 時代の content — LLM があなたの文章を読む

2026年 content の最大の変数。もう先送りできない章。

2度読まれる

• Training data で1度。 GPT-5、Claude 4.5、Gemini 2.5 の training set に入り得る。入れさせない選択もできる(GPTBot・ClaudeBot・Google-Extended を robots.txt で block)。
• 推論で毎日 N度。 Perplexity、ChatGPT search、Claude web search が回答時に RAG であなたの記事を取る。毎日。

LLM が引用するように書く — GEO (Generative Engine Optimization)

GEO は2025年に出た新語。SEO の LLM 版。

1. 明確な定義文。 「X は Y。」 1文で始める。LLM は定義文を最も引用する。
2. 数字付きの比較。 「A は B より12% 速い。」 数字のある文は引用率が5倍(複数の GEO 研究の consensus)。
3. List。 Bullet が散文より引用される。
4. URL stability。 LLM の training data の URL が生きていることで引用が維持される。
5. llms.txt 追加。 2026年に定着した standard。site root に llms.txt を置いて LLM に「この site の core 文書」を伝える。

引用を block することもできる

• User-agent: GPTBot Disallow: /
• User-agent: ClaudeBot Disallow: /
• User-agent: Google-Extended Disallow: /
• ただしこれは traffic も止まる。policy は本人の選択。

1つの正直な変化

検索 traffic は落ちる。だが 「あなたの記事を見た人」の数は同等か、むしろ増えている。 ただ ChatGPT 越しに見ているだけ。GA で traffic が落ちたから content を止めるのは signal の読み違い。

---

13章 · 2026年で最も過小評価された channel — Personal blog 擁護

7章で先送りした擁護をする。

4つの擁護論

1. AI 時代の通貨は URL。 LLM が引用できる form は文章で、文章の住所は URL。tweet は URL があっても揮発する。video は URL があっても引用しづらい。blog 記事は両方を持つ。
2. アルゴリズム依存が0。 Twitter も LinkedIn も YouTube も、algorithm が一度変われば traffic が半分。自分の domain blog は algorithm 変動の影響を受けない。検索 algorithm が変わっても — RSS・newsletter・LLM 引用は残る。
3. 長期 asset。 5年前の記事が今日も traffic を運ぶ。YouTube 動画は5年後も再生されるが algorithm がほぼ surface しない。tweet は24時間で消える。blog 記事は5年もつ asset。
4. 他の全 channel の home base になる。 Twitter thread は blog 記事の要約。newsletter は blog 記事の digest。YouTube 動画は blog 記事の visualization。conference talk は blog 記事の発表。blog が無いと他の全 channel が浮く。

それでも blog が外される理由

• 「もう遅い」 — 嘘。AI 時代の content eco は再開している。
• 「traffic が出ない」 — 焦り。最初の6か月は出ないのが default。6年の asset を6か月で評価しない。
• 「書くことがない」 — 嘘。今日検索したものが次の記事。
• 「design が悪い」 — 逃避。default の Tailwind template で十分。design は100本書いた後で気にする。

一行結論

自分の domain blog が home base、他の全 channel はそこから借りて、そこへ送り返す distribution。 2026年に content を始めるなら、まず domain を買い、まず "Hello World" を公開する。

---

エピローグ — 1年後のあなたへ

5年後のあなたは2種類のどちらか。

(A) 30本の記事、0本の動画、newsletter 200人、RSS 50人。traffic は微妙だが — 会社外の誰かがあなたを知っている。PR comment に「これあなたの記事で読んだ」と返ってくる。LinkedIn DM に採用 offer。conference CFP が通る。5年の asset が積まれた。

(B) Twitter follower 2,000人、blog 記事 0本。home base が Twitter、algorithm が月ごとに変わる。volatility shock 一度で0に戻る。content を集める場所がない。Twitter を離れると痕跡が消える。

A になる道は単純。domain を買い、MDX を敷き、記事1本を書き、日曜ごとに1本書き続ける。 6か月、26本。それだけ。

Day-zero checklist — 今日始める人の最初の7つ

1. domain を買う(yourname.dev か yourname.io)。
2. Next.js + MDX template を1つ clone(この blog もそう)。
3. Vercel で deploy。5分。
4. "Hello World" 記事を1本公開。
5. RSS を ON にして自分の RSS reader に追加。
6. 今週中にもう1本。今日検索して答えが無かった何か。
7. 日曜の夜に毎週1本。6か月間。

7つの anti-pattern — 最も多い失敗

1. Twitter を home base にする — algorithm は借り物。
2. 最初の記事を大きく構えすぎる — 800字で記事。出せ。
3. 「design first」の罠 — design に100時間かけるなら記事100本書ける。
4. 3か月で辞める — 6か月で結果が出ないのが default。
5. 他人の blog を1:1で真似 — voice は時間が彫る。真似は1年まで。
6. comment 0で絶望する — comment は付かないことがある。RSS subscriber が真の signal。
7. 早すぎる monetize — subscriber 1,000人前に paid 化しない。pool が育たない。

次回予告

• 開発者 content の monetize — 広告・sponsor・paid membership・講座・本の経済学(2026)
• 「LLM に引用させる」 — GEO 実戦 guide
• 最初の100本の典型 trap — 1年分を週ごとに診断する

「content を作る理由が1から10に増えた。だが始める人は減った。だから今始めることが過去最大の見返りを与える。」

— 開発者 content creation、終わり。

---

参考 / References

Platform

• Substack — https://substack.com
• Beehiiv — https://www.beehiiv.com
• Kit (旧 ConvertKit) — https://kit.com
• Buttondown — https://buttondown.com
• dev.to — https://dev.to
• Hashnode — https://hashnode.com
• Medium — https://medium.com
• Hacker News — https://news.ycombinator.com
• Lobsters — https://lobste.rs
• Bluesky — https://bsky.app
• Threads — https://www.threads.net
• Mastodon — https://joinmastodon.org

Tool

• Descript — https://www.descript.com
• Loom — https://www.loom.com
• Cleanshot X — https://cleanshot.com
• Figma — https://www.figma.com
• Excalidraw — https://excalidraw.com
• Carbon — https://carbon.now.sh
• Ray.so — https://ray.so
• Plausible — https://plausible.io
• Posthog — https://posthog.com

学ぶ価値のある開発者 blog ・ channel

• Julia Evans (jvns.ca) — illustration + 短文 depth の standard
• Dan Abramov (overreacted.io) — essay blog の頂点
• Josh Comeau (joshwcomeau.com) — interactive 記事 design standard
• Patrick McKenzie / patio11 — business 視点の深い記事
• Fireship / Jeff Delaney (YouTube) — 100秒モデル
• Theo / t3.gg (YouTube + blog) — live + 整理
• Lenny Rachitsky — newsletter design standard
• Casey Newton / Platformer — 独立 journalism モデル
• The Pragmatic Engineer / Gergely Orosz — depth と cadence の balance
• Swyx / Latent Space — AI engineer content の頂点
• mizchi — 日本 frontend の率直 opinion
• ymotongpoo — 長文 essay
• Songmu — OSS 系の深い post

Meta · data

• llms.txt — https://llmstxt.org
• robots.txt for AI crawlers (Google-Extended, GPTBot, ClaudeBot)
• IndieWeb — https://indieweb.org
• RSS specification — https://www.rssboard.org

全 content は結局文章。動画は文章の visualization、tweet は文章の compression、talk は文章の発表。文章を上手く書く開発者が最も遠くまで行く。2026年は特に。