はじめに
先日、個人サイトを作って公開しました。
日英バイリンガルの技術ブログ + 自己紹介、完全静的生成、運用費ゼロ。 スタックは Astro + TypeScript + GitHub Pages です。
この記事は「何で作るか」を決めるまでの話です。 実装のあれこれ（Content Collectionsとか、記事取り込みパイプラインとか）はまた別の記事にします。選定だけで1本になってしまったので。
（そもそもなんで個人サイトなのか、はこの記事の一件がきっかけです。Zennの自動翻訳がデフォルトONで来たあの騒動。実はnoteのアカウントも持っているんですが^[note自体は悪くないんです。ただ技術記事の置き場としては、Markdownの表が書けない（コミュニティの回避策が「KaTeX数式で表を偽装する」）という時点で候補から外れていました。あと運用していての体感として、検索やAEOの面で強いとも感じられなかった、というのもあります。]、あちらも気づいたら翻訳がオプトイン済みになっていた。翻訳に人一倍こだわりがある身として、コントロールが自分の手元にある場所が欲しくなった、という流れです。）
タイミングの話もしておくと、「そのうち個人サイト作るか〜」と思いながら仕事のばたばたで寝かせていたところに、新世代のコーディングエージェント（Claude Fable 5）が出ました。新しいエージェントの実戦投入先としてもちょうどいい。腰が上がった直接のきっかけは、正直これです。 （エージェントと一緒にどう作っていったかは、これも実装編のほうで）
先に白状すると、この選定の動機は「趣味」と「実験」と「前から検証したいことがあった」の三つ巴です。実利だけでは説明がつきません。 そして私は、趣味の技術選定では「せっかくだし」を正式な評価項目として認めていいと思っている派です。
その話も込みで、順番に行きます。
何が作りたかったか
要件を並べるとこうなります。
- ブログ中心のサイト（記事40本強を移植 + 今後も書く）
- 日英二言語（日本語の記事と英語の記事を、すでに両方書いて運用している。ここが後で効きます）
- 記事資産はgitで管理したい（プレーンテキスト + 履歴 + どこへでも移行できる状態を保つ）
- 完全静的（サーバー管理はしたくない。運用費ゼロ）
- SEO / AEOは正面からやる（ここが今回の個人的テーマ）
最後の項目に「？」となった人のために、少し自分の話をします。
趣味だからこそ、SEO全部盛りにできる
私は元SEOの人間です。「元」というか、キャリアの原初がSEOでした。約10年前、最初の肩書きが「SEO対策・Webディレクター」。検索に引っ掛けたくてalt属性にこだわる私と、「そんなの適当でいいだろ」の上司とで、画像ひとつをああだこうだやっていた、あの時代が私の始まりの地です。 そこから色々と派生して、現在は第六期。「色々」の中身は長くなるので、プロフィールに譲ります。
ただ、主戦場を離れてもうずいぶん経ちます。 知識のアップデートはしていても、手を動かして施策を全部積む機会は、実務ではもう回ってきません。多分ね。
そして実務でSEOをやったことがある人なら分かると思うんですが、SEO施策って会議で死ぬんですよ。
- 「構造化データ？それ入れると何PV増えるの？」
- 「hreflang？英語版そんなに見られてないよね？」
- 「OGP画像の自動生成？手動でよくない？」
ひとつひとつは正しい施策でも、費用対効果の説明コストで削られていく。 最終的に残るのは title と meta description と、あとちょっと、みたいな。
でも趣味のサイトなら、そもそも会議がない。
JSON-LD全種盛り（BlogPosting / BreadcrumbList / Person / WebSite）、日英ペア記事のhreflang相互設定、ビルド時のOGP画像自動生成、AIクローラを明示的に許可するrobots.txt、セマンティックHTMLの見出し設計。 仕事では「そこまでやる？」と言われるフルコースを、全部積める。
つまり個人サイトは、私にとってSEO/AEOの実験場なんです。 「SEO意識でサイトを作り込むなんて、正直、趣味じゃないとできない」という逆説。
実験場というのは、計測も含みます。 Search Console登録もGA4のタグも自分の手で入れて、データを自分で持つ。借り物のプラットフォームだと、計測はサービス側が見せてくれる範囲までです。Dev.toの内蔵アナリティクスは優秀な方で、claude.ai や perplexity.ai からの流入まで見えて面白かった。一方noteは、ビュー数とスキがわかる程度で流入元がほぼ見えない。API名やモデル名まで具体的に書き込んだ長文の技術記事で検証しても、計器が粗いと結果の解像度も粗くなるんですよね。検証したい人間にとって、計器を選べないのは結構つらい。 Zennはその点で独特で、内蔵の統計こそビュー数程度ですが、GA4を自分で接続できる。借り物の土地に自前の計器を持ち込める稀有な例で、実際うちのZenn流入分析はこれでやっています。 自サイト + GA4なら、カスタムチャネルグループでAI流入を独立チャネルとして抽出する、みたいな設計から自由にできます。
個人的に一番やりたい実験はGeminiの計測です。 gemini.google.com の独立リファラは取れるはず。でも、Google検索のAIモード / AI Overview経由の流入は google.com に混ざって区別がつかない（はず）。この「GoogleのなかのGemini」がどこまで切り分けられるか、自分のデータで確かめられるのは自サイトだけなんですよね。
だから技術選定の最重要要件は「検索エンジンとAIに読まれやすい構造を、こちらの自由に作れること」でした。
なぜAstroか
その前に、前提をひとつ確認しておきます。 このサイトが完全静的なのは、我慢や妥協ではなく、動的でなければならない理由がひとつもなかったからです。コメント欄は持たない^[これは実体験込みの判断です。Dev.toで記事が少し跳ねた途端、AIボットやリポジトリ宣伝アカウントの突撃が始まり、都度運営に相談することになりました。「そういうのが来るレベルに来たか」という妙な感慨はあるものの、受け付け窓口を持てば管理義務が生まれる。感想はプラットフォーム側の転載記事で受け取れれば十分です。]、検索はタグ索引で足りる、three.jsでぐりぐり動かす演出も要らない。 誤解のないように言うと、動きがないわけではありません。テーマ切替も全画面メニューもホバー演出も、うちのサイトはそれなりに動きます。ただ、その程度の動きはCSSと素のJSで全部足りる。フレームワークのランタイムを積まないと出せない動きが、ブログには存在しなかった、というだけの話。 ブログは文字を読む場所で、盛れば盛るほど本文から遠ざかる。要件が静的なら、静的が自然形。というか、要らないものは要らない。それだけの話です。 AI時代、読む側も作る側も、認知負荷は少ないに越したことがないですしね。
この前提が決まると、候補は一気に絞れます。見送った順に。
Next.js: ブログには過剰
まず名前が挙がる定番。でも要件は「静的なブログ」です。 App Router、SSR、ISR、あの辺の強力な機能は全部使わない。使わない機能のための複雑さとクライアントランタイムだけが残る。
高機能なフレームワークって、使わない機能もメンテナンスコストに化けるんですよね。アップデートのたびに「うちに関係ある変更か？」を判断するコストとして。
Hugo / 11ty: 速いけど、伸びしろの向きが違う
静的サイトジェネレーターの老舗たち。ビルドは爆速だし、ブログを置くだけなら全然アリ。
見送った理由は拡張の方向性です。 記事の取り込みパイプラインやOGP生成を TypeScriptで書いて型で守りたい（普段の開発と地続きにしたい）という好みに対して、HugoはGoテンプレート、11tyはその中間。悪いのではなく、私の手に馴染む向きじゃなかった。
WordPress: 第一期の古巣
キャリア最初期、WordPressでサイトを作る仕事をしていました。なので懐かしさはある。 でも要件に対してはサーバー・DB・セキュリティ更新という「運用」が付いてくる時点で外れます。静的でいいものに動的の維持費を払わない。
それに加えてセキュリティ。 WordPressは世界のCMSシェアの覇者で、それは攻撃側から見れば一番費用対効果のいい的ということでもあります。wp-loginへの総当たり、プラグインの脆弱性、更新が止まったテーマ。ボットは相手を選ばず巡回してくるので、持っているだけで防御義務が発生する。 古巣に世話になった身としても、いま個人ブログのためにあの防御義務を背負う理由は見つかりませんでした。
Astro: コンテンツ特化という思想の一致
で、Astroです。決め手は3つ。
- コンテンツファーストの設計: Content Collectionsで記事をZodスキーマ付きの型で管理できる。フロントマターの型エラーがビルド前に出る。ブログという用途に対して思想がまっすぐ
- デフォルトでJSゼロ: 出力は素のHTML。インタラクションが必要な部分だけ「島」としてJSを積む（アイランドアーキテクチャ）。静的サイトのパフォーマンスがデフォルトで担保される = SEO要件と直結
- 触ったことがなかった: これを理由に数えていいのが趣味です
3つ目、ふざけているようで本気です。
新しいフレームワークに触れておくことは、それ自体が資産になります。 実際、Astroを触っていたおかげでTypeScript 7がGAした時に「実プロジェクトで検証して記事を書く」が即できたわけで、触っているものの数だけ、時事に反応できる領域が増える。
それと、ちょうどアーキテクチャまわりの模索をしたい時期でもありました。 アイランドアーキテクチャ、話には聞いてたけど実際どんなもんかね〜、という。フレームワークは道具ですが、アーキテクチャは考え方なので、一度手で覚えれば他の現場にも持ち帰れる。お試しアイランドアーキテクチャチャレンジも、立派な選定理由のひとつです。 （で、実際にやってみてどうだったかは、これがなかなか面白いオチになったので別記事にします）
エコシステムの空気感（何が活発で、何が7.1待ちで、みたいな）は、ドキュメントを読むだけでは入ってこない。手を動かしている場所からしか入ってこないんですよね。
GitHub Pages vs Cloudflare Pages、どっちを選ぶか
フレームワークより悩んだのが実はこっちです。
そもそも自分でサーバーを持つか問題
先に一番大きな分岐から。VPSを借りて独自運用する選択肢も、一応あります。自由度は最強です。
でも、昨今のWebの治安を思い出してください。 公開した瞬間から始まる脆弱性スキャン、ボットの絨毯爆撃、依存パッケージのCVE通知。静的なブログひとつのために、パッチ適用とログ監視の生活を背負うのか？という話です。
「攻撃面をそもそも持たない」のは、それ自体が立派なセキュリティ戦略です。 守るものが最初から存在しなければ、守る作業も発生しない。
サイトが育って動的な何かが必要になったら、その時に持てばいい。撤退ならぬ「参入の余地」だけ残して、今回は持たない側に倒しました。
念のため付け加えると、完全静的にしても攻撃面がゼロになるわけではありません。残るのは依存パッケージのサプライチェーンと、ビルドパイプライン。ここは持たない選択では消えない領域なので、別途締める必要があります（この話はそれだけで1本書けるので、いずれ）。
候補たち
- GitHub Pages: 無料、Actionsでデプロイ、gitと一体
- Cloudflare Pages: 無料枠が太い、CDNが速い、privateリポジトリでもOK、ヘッダー制御やリダイレクトも柔軟
- Vercel / Netlify: DXは最高。ただし無料枠は個人・非商用の条件付きで、規約の勾配がある
Vercel / Netlifyは、規約の勾配を趣味サイトで気にしたくないのと、静的サイトにはDXの強みが活きにくいのとで、早めに外しました。 つまり2026年現在、個人の静的サイトは実質「GitHub Pages か Cloudflare Pages か」の二択だと思っています。
正直に言うと、今の時代にゆるく個人サイトをやるなら、Cloudflare Pagesはかなり有力です。
privateリポジトリのままデプロイできるし、_headersや_redirectsでの制御もできる。GitHub Pagesの「publicリポジトリ必須（無料枠）」「クライアントサイドリダイレクトしかできない」という制約と比べると、機能面ではだいたい勝ってる。
それでもGitHub Pagesにした理由
- 生活圏がGitHubだから: コードもプロフィールもGitHubにある。サイトのリポジトリがそのままポートフォリオの一部になる（プロフィールのピン留めに刺せる）。白状すると「生活圏」の割に草はスカスカだったんですが（手元のgitで完結する作業が多い）、サイト公開は放置していたGitHubプロフィールを整えるついででもあり、これから生活圏にする宣言込みの選定です
- 構成要素を増やしたくなかった: アカウント、ダッシュボード、障害情報を見る場所。管理対象は少ないほど続く。趣味の継続率は摩擦の少なさで決まる
- 静的サイトに高機能はいらない: ヘッダー制御もエッジ関数も、完全静的サイトには出番がない。使わない自由度は複雑さ
- たぶん吹っ飛ばない: 個人サイト運営の歴史は、ブログサービスの終了と仕様変更に振り回されてきた歴史でもあります。GitHubごと消える世界線は、世界中のコード資産と心中する世界線なので、持続性の心配としては最下位に置いていい
つまり機能比較ではCloudflareくんの勝ち、摩擦比較でGitHub Pagesの勝ち。うちは後者を取りました。 ゆるく長く、が目的関数なので。
実際、周りにはCloudflare派も普通にいます。すでにWorkersを使っていたり、独自ドメイン前提だったりと、あちらが生活圏の人ならCloudflareが正解。つまりこの二択、機能表ではなく「自分の生活圏がどっちにあるか」で決めるのが摩擦最小の答えだと思います。
それと、要件の伏線をひとつ回収します。 すでに日英二言語で記事を書いて運用している身としては、記事資産が全部プレーンテキスト + gitで一元管理されていることの価値が大きい。二言語分の記事とペア関係の管理・更新・移行が、全部リポジトリ内で完結する。
この「手元にある」の価値は、noteで身に沁みた実感でもあります。 あちらには、公開分に「まだネットの海に流していない下書きの山」まで合わせると4桁本の文章が溜まっているんですが、本数がそのくらいになった頃から、アカウント内検索の精度が体感で落ちました。検索が完全一致志向なので、助詞をひとつ間違えると出てこない。自分は書いた文章を覚えているタイプなので一節をそのまま入れて探すんですが、それでもなかなか出てこないことがある（なぜか一致しているはずなのに出てこないことも）。 ちなみにこの「一致してるのに出ない」、私の勘違いではなく実際に原因を追った方の記録があります。1,348本を運用する方が完全一致でもヒットしない記事を見つけ、運営報告の末に「検索の表示不具合」として修正された事例。しかもその方の仮説が「AI自動翻訳機能のフィルター誤判定が関係しているのでは」というもので、翻訳機能の余波はこんなところにまで顔を出すのか、という。 自分の書いた文章を、自分で発掘できない。 プラットフォームの検索機能は借り物なので、不便でも自分では直せません。プレーンテキスト + gitなら、grep一発です。
外側の検索についても同じことが言えます。 仮にGoogleにインデックスされない記事が出ても、自サイトならsitemapを確認して、Search Consoleでインデックス状況を見て、URL検査から再リクエストまで、全部自分の手で打てる。プラットフォーム上では「運営に報告して祈る」がほぼ唯一の打ち手なのと対照的です。 検索に出ない事態は起きうる。起きたときに、自分で動けるか。ここが借り物と自分の土地の違いです。 そしてgit管理ということは、ホスティングへのロックインが実質ゼロということでもあります。Cloudflareに移りたくなったらリポジトリを繋ぎ直すだけ。「GitHub Pagesを選ぶ」は、実は「いつでも乗り換えられる状態のまま選ぶ」でもある。摩擦で選んだ癖に退路は確保してある、というずるい構成です。
この退路、保険としては割と本気で考えています。 さっき「GitHubは吹っ飛ばない」と書きましたが、それはサービスの話。アカウントが止まる事態は普通にありえます。実際、最近知人がセキュリティ関連の活動まわりでアカウントBANに遭うのを見ました。事情はどうあれ、運営の判断ひとつでアカウントは止まりうる。 そして帰ってこない、という…。 AI管理や対応も良くも悪くも増えましたからね。 プラットフォーム依存のリスクは、GitHubだって例外ではないんです。 でもgitは分散型なので、リポジトリの完全なコピーは常にローカルにもある。土地は借り物でも、荷物は常に手元にある。仮に明日アカウントが止まっても、記事資産は1バイトも失われません。
github.ioサブドメインとSEOゼロスタート論
ここで元SEO畑の育ちとして触れておきたいのが、github.io サブドメインの話。
「GitHubのドメインパワーに乗れるのでは」と思うかもしれませんが、乗れません。
github.io は Public Suffix List（PSL）に登録されているからです。
PSLは「ここから先はそれぞれ別の登録ドメインとして扱え」という境界のリストで、github.io がそこに載っている以上、username.github.io は事実上それぞれが独立したドメイン。Cookieも分離されるし、検索エンジンからの評価も完全にゼロからのスタートです。
ちなみにこれはGitHub Pagesに限った話ではなく、pages.dev（Cloudflare Pages）も netlify.app も vercel.app も、主要ホスティングのサブドメインは軒並みPSL登録済みです。Cookie分離のセキュリティ要件がある以上、入っていない方がおかしい。つまりどこを選んでもデフォルトサブドメインはゼロスタート。
SEO観点では、github.ioサブドメインと新規の独自ドメインは、ほぼ同じ土俵。 「じゃあ年1,000円ちょっとで独自ドメイン買った方がよくない？」は正論で、実際うちも後から独自ドメインに移せる構成にしてあります（当面は見送り。理由は単純で、ゼロスタートならどっちでもゼロスタートだから、急ぐ理由がない）。
ただ、ゼロスタートをそこまで恐れていないのには理由があります。 note・Zenn・Dev.toという借り物のドメインで、ドメインパワー以外の攻略はもう検証が終わっているんですよ。検索意図に合わせたタイトル設計、AIに引用される構造、流入の9割がオーガニックになる書き方。プレイブックは手元にある。 （検証の締めくくりとして書いたまとめがAEO 2026年1月時点の検証と見解です。文字量の実験はそれ以前に散々やっていて、あの記事自体は「あえて文字数と情報密度を限界まで詰めた場合」の最終標本です。ちょうどnote公式が「書ける文字数が増えました」とアナウンスしていた時期ですが、実測の答えは「適切な文字量のラインは別にある。上限が増えても、そこまで使う意味はない」。奇しくも、検証場だったnoteに置いてきた一番の大物がこの検証記事、という） 残る変数はドメインの信頼だけで、これは時間と記事数でしか育たない。 記事数だけ多くてもですし、スキの数とかいうのも変数ですけどね。 だから焦らず、のんびり育てるフェーズと割り切っています。
ゼロスタートで実際どう戦えているのか？は、実測データが集まってきたらまたどこかでするかも。
趣味の技術選定は、最適化目標が違う
仕事の技術選定は、リスク・保守性・チームのスキルセット・撤退可能性で決めます。 「せっかくだし新しいの触りたい」は、チームの選定会議では最弱の意見です。正しく最弱であるべきでもある。
でも趣味は違う。
- 学び: 触ったことがないものに触る価値。趣味で触っておいたものは、仕事の引き出しに静かに追加される
- 制約: 運用費ゼロ、管理対象最小、続けられる摩擦の低さ
- 楽しさ: 作っていて気分がいいか
この3つで最適化していい。というか、楽しさを外すと趣味プロジェクトは死ぬので、外してはいけない。
仕事の基準を趣味に持ち込むと「実績のある枯れた構成で作りましょう」になって、学びも楽しさも減る。逆に趣味の基準を仕事に持ち込むと事故る。 基準が違うのはどちらかが間違っているからではなく、最適化しているものが違うからです。
おわりに
というわけで、Astro + GitHub Pages。完全静的、運用費ゼロ、今の時代にやれること全部盛り。 フレームワークは「触ったことがなかった」で選び、ホスティングは「摩擦が少ない」で選びました。
仕事の選定会議でこれ言ったら一蹴されると思います。 でも趣味なので、会議がない。最高。
記事はgitにある。いつでも引っ越せる。いつでも乗り換えられる状態のまま、今はここにいる。 ゼロスタートのドメインを、借り物の土地で検証済みのプレイブックで、のんびり育てていくフェーズです。
「せっかくだし」で選んだものが、結果的に一番長く触り続けられる。 趣味ってそういうものだと思っています。
実装編（Content Collections設計、記事取り込みパイプライン、ビルド時OGP生成）と、ゼロスタートSEOの実測データ編は、また別の記事で。