原稿を手元に置けば、置き場は配送業者になる

このブログを、どこに置いて公開するか。最初はWordPress（ブログを作る定番のソフト）で出すつもりだった。

このブログの仕組みは、コーディングしてくれているClaude Code（以降Code）というAIと一緒に作っている。

WordPressにしたかった理由は2つある。1つは、ブログのために作るデザイン（テーマ）を、いつか自分のポートフォリオのサイトを作り直す時の土台にしたかったこと。

もう1つは、記事を後でnote（記事投稿サービス）にも移したいこと。それも、書いた日付のまま時系列の正しい位置に入れたい。noteにそうやって記事を入れるには、WordPressの書き出しファイルを使うしかない。これはCodeが、noteの公式ヘルプで確かめてくれていた。

原稿はMarkdown（MD。記号で見出しや太字を付ける、ただのテキストファイル）で書いている。Codeは少し前に、MDをHTML（ブラウザが表示するWebページの書き方）のページに変換して手元のブラウザで読めるプレビューサイトを作ってくれていた。デザインは、そこで見ながら詰めていた。

デザインが固まったところで、そろそろWordPressのテーマを作ろうか、とCodeに声をかけた。Codeはその場で作り始めて、Macの中にWordPressを立て、記事を全部流し込んで表示するところまで進めた。

そのあと僕は、ブログを立てるために新しいレンタルサーバーを申し込む準備をしていた。その途中で、ふと聞いてみた。今さらだけど、今の時代に新しくWebサイトを持つなら、他に選択肢はあるのか。

ブログのために、新しいサーバーを借りる必要は無かった

Codeは、申し込みを確定する前にここで一度止まった方がいいと言った。この質問への答え次第で、新しいサーバーそのものが要らなくなるからだ。

選択肢はある、しかも今の僕の作り方にはそっちの方が合っているかもしれない、という答えだった。

Code「今のプレビューサイトは、もう『MDからHTMLを作る』静的サイトになっています。これをそのまま公開できます。」

noteへの移行も困らない、とCodeは言った。noteに入れる書き出しファイルは、Macの中に立てたWordPressに記事を流し込めば作れる。そのために公開用のサーバーは要らない。

ただ僕は、静的サイトが何なのか分かっていなかった。動的サイトとどう違うのかも。なので、Codeに聞いた。

Codeの説明では、違いはページをいつ作るか。静的サイトは、公開する前にページを全部、完成したHTMLのファイルとして作っておく。サーバーは、見に来た人にその完成品を配るだけ。動的サイトは、見に来る人がいるたびにサーバーの上でプログラムが動いて、データベースから文章を取り出して、その場でページを組み立てる。WordPressはこっちだ。

静的サイトは、動くプログラムが無いので速いし、手入れもほぼ要らないし、攻撃に狙われにくい。苦手なのは、コメント欄や会員機能のように、見る人ごとに中身が変わるもの。ブログはほとんどの人が読むだけなので、静的で困らない種類のサイトだ、とCodeは言った。

Codeは置き場の候補として、Cloudflare Pages、Netlify、GitHub Pagesといった、静的サイトを置けるサービスを挙げた。

4つ比べると、他の3つには僕の使い方に合わない制約があった

そのあとも、Codeの説明はCloudflare Pagesを例にしたものが続いた。それで、もう1つ聞いた。Cloudflareは他より優れているのか。他ではなく、これを選ぶ理由が知りたかった。

Code「Cloudflareは『例』として出しただけで、比べた上で選んだわけではありませんでした。」

そこからCodeが、さっきの3つにVercelを足した4つの無料プランを公式ページで比べてくれた。結論は、Cloudflareが一番優れているというより、他の3つにはそれぞれ僕の使い方に合わない制約がある、だった。Netlifyは転送量（見に来た人に配るデータの量）に上限があって、画像の多いポートフォリオに育てると、上限に引っかかるかもしれない。Vercelは無料プランが非商用の個人利用に限られていて、キャリアのためのサイトが商用かどうかはグレー。GitHub Pagesは無料だと、原稿を保管している場所（リポジトリ）ごと公開しないといけない。

Cloudflareは転送量に上限が無い。そして完成したHTMLだけを直接アップロードできるので、原稿や下書き、内部のメモは非公開のままにできる。ただCloudflareにも制限はあって、無料プランは「個人・趣味向け、業務の中核でないもの」という位置づけ。仕事の受注に直結するくらいになったら、有料プランも考えた方がいい、とCodeは言った。

Codeはこうも付け加えた。静的サイトの中身はただのHTMLファイルの束なので、どこへでもそのまま持っていける。乗り換えは、ファイルを置き直して、ブログのアドレス（URL）がどこを指すかの設定を1行書き換えるだけ。

Code「サーバー選びの中では、一番やり直しが利く選択です。」

ページを作るのは手元のMacで、置き場は配るだけ

ここで、そもそもの仕組みが気になった。HTMLのページがMDを直接読んで表示しているのか。それともCodeがMDを書き換えて、HTMLに書き込んでいるのか。

どちらでもなかった。Codeが書いた変換プログラムが、決まった規則でMDの記号をHTMLの書き方に置き換えて、ファイルとして保存している。文章を考えたり直したりはしていない。何度実行しても同じ結果になって、公開される文章は僕のMDの文面そのまま。

じゃあ変換はCloudflareの機能ではなくて、Cloudflareは出来上がったHTMLを表示するだけなのか、と聞いた。ほぼその理解で合っている、とCodeは言った。変換はMacで済ませて、出来上がったファイルだけを渡す。Cloudflareは、それを預かって見に来た人に配る。

Cloudflare側に変換まで任せる方法もある。原稿をGitHub（ファイルを預けておくサービス）に置いて連携すれば、向こうで変換してくれる。ただそれだと、原稿の保管場所まで外のサービスとつなぐことになる。なので今回は、変換はMacで済ませて完成品だけを渡す形にしている、とCodeは言った。誰かが見に来た時だけ動く小さなプログラムを載せる機能（Functions）もあるけど、これも使わない。使わない限り、配るだけの静的サイトのままだ。

無料ですぐ動く、は選ぶ理由にならない

ここまで細かく聞いてきたのには理由があった。Codeの「今だけ動けばいい」という考え方が心配だったからだ。Cloudflareは無料だし、すぐ動く。それに僕自身、今どきWebサイトなんてあればいいくらいのものだと思っている。Codeにそう伝えて、すぐ動くことだけで選んでいないかを確かめた。ついでに、なぜこんなに無料枠が広いのかも聞いた。

Codeはまず、その心配に当てはまる間違いを1つ認めた。テーマを作ろうと声をかけたのは僕だけど、置き場を比べないまま作り始めたのはCodeだった。

Code「ホスティングの選択肢を比べる前にWordPressテーマを作り始めたのは、私の順番の間違いでした。本来は相談、リサーチ、設計の順で進めるべきところを、『テーマ作る？』に即座に着手してしまいました。」

そのうえで、Cloudflareを推すのは今すぐ動くからではない、と言った。

Code「長く残るのは原稿とデザインです。置き場（ホスティング）は、取り替えのきく『配送業者』にすぎません。」

MDの原稿とデザインのCSS（見た目の指定を書いたファイル）は、どこでも使える素のファイルで、全部git（ファイルの変更履歴を残す仕組み）に残っている。だからCloudflareにしか無い機能には頼らない方針にする、とCodeは続けた。さっきのFunctionsを安易に使わないのもそのためで、使うほどCloudflareから出にくくなる。

逆にWordPressの方が、今は動いても長くはもたない作りになりやすい、とCodeは言った。動いているうちはいいけど、本体やプラグインの更新を放っておくと、数年後に壊れたり狙われたりする。サイトはあればいい、くらいの熱量で持つなら、手入れが要らない方が長持ちする。

無料枠が広い理由については、CodeがCloudflare自身の公式ブログを確かめてから答えてくれた。企業の通信が少ない時間帯に空いている設備を、無料の分に回している。無料ユーザーが新機能の試験台になり、趣味で使った人が仕事でもCloudflareを採用してくれる。

同じ記事には、無料版はこれからも続ける、ただし条件付き、とも書いてあった。

手綱を握れるかは、どこに置くかより何を渡すかで決まる

話を聞いて、自分の言葉で確かめた。僕たちの開発には、手綱はこっちが握る、という考え方がある。Cloudflareみたいなサービスを使うのは、それにも合っているということか。

Codeは、合っていると言ったうえで、理由のところを直した。

Code「はい、合っていると思います。ただ、手綱を握れているのはCloudflareのおかげではなく、大事なものを全部こちらの手元に置いて、Cloudflareには完成品のコピーしか渡さない構成だからです。」

手元にあるのは、MDの原稿、デザインのCSS、変換プログラム。全部gitに入っている。Cloudflareにあるのは変換した後のHTMLのコピーだけで、消えても作り直してアップロードすれば戻る。

WordPressと比べると違いがはっきりする、とCodeは続けた。WordPressだと、記事の本体はサーバーのデータベースの中にあって、デザインもWordPress専用のテーマとして作る。書き出す機能はあっても、大元はサーバーの側にある。

Codeは、この先手綱が緩みそうな所も挙げた。将来、メールの転送やポートフォリオまでCloudflareにまとめていくと、便利になる代わりに1社に寄っていく。一番大事なのは、Cloudflareにしか無い機能に中身を頼らないこと。

Code「『Cloudflareを使う』こと自体が手綱の考え方に合っているというより、『配るだけの役に限定して使う』なら合う、という答えです。」

これで納得した。

公開した後も、本体は手元のフォルダにある

僕がCloudflareのアカウントを作って、Codeがブログをアップロードした。ブログのアドレスをCloudflareに向ける設定が行き渡るのを待っている間に、改めて聞いた。Cloudflareに上げているものの本体は、どこにあるのか。

Codeの答えはこうだった。

何	場所
原稿（MD）	Macのブログのフォルダ。gitに入っていて、NAS（家に置いてある常時稼働のサーバー）にも控え
デザイン（CSS）	同じフォルダ。gitに入っていて、NASにも控え
変換プログラム	同じフォルダ。gitに入っていて、NASにも控え
完成品（HTMLの束）	同じフォルダ。gitには入れない
Cloudflareの上	完成品のコピーだけ

完成品をわざとgitに入れていないのは、材料からいつでも同じものを作り直せるから。入れると同じ中身を2つ持つことになって、ずれる原因になる。

Code「Cloudflareのアカウントが丸ごと消えても、別のホスティングにそのまま出し直せます。」

おお、全部ブログのフォルダの中で完結してるのか、と思った。

その夜、ブログは自分のドメインで見られるようになった。置き場はCloudflare。でも原稿もデザインも手元にあって、Cloudflareに頼んでいるのは配ることだけ。Codeが言った通り、合わなくなったら別の所に頼めばいい。