DIY & HOME

iPhoneだけでWebサイトを作って公開してみた
GitHub × Cloudflare PagesでCony DIY HoustonをDIY

Xで流れていく実験ログを、あとから自分でも探せる形で残したい。そこから始めて、独自ドメイン取得、GitHub、Cloudflare Pages、HTML編集まで、立ち上げ〜初回公開はiPhoneだけで進めました。その後はPreview運用やPCでのデスクトップ表示確認、Google Search Consoleまで少しずつ仕組みを足しています。

公開日：2026年9月14日最終更新：2026年9月14日

公開後のCony DIY HoustonトップページをiPhoneで表示した画面 — 現在のトップページ。Xと同じロゴ・ヘッダー画像・ネイビー×ゴールドをWebにも持ち込みました。ブラウザUIは記事用にクロップしています。

先に結論：今の構成

役割	使っているもの
独自ドメイン	Cloudflare Registrar
HTML・画像の管理	GitHub Private Repository
公開	Cloudflare Pages
本番 / Preview	main / draft
サイト構成	静的HTML + 共通 style.css + 記事テンプレート
作業端末	立ち上げ〜初回公開：iPhone 公開後の表示確認：iPhone + PC
アクセス確認	Cloudflare Web Analytics
Google検索の確認	Google Search Console

なぜWebサイトを作ったのか

Xで実験を記録していると、「前のGerman Weissbierは何℃だったっけ？」「芝に1 inch撒くのに何分だったっけ？」と、自分の過去投稿を自分で探すことが増えてきました。

Xは、その瞬間の途中経過や失敗を残すにはすごく使いやすい。一方で、数週間・数か月後に結果だけ探そうとすると、投稿が流れていて意外と大変です。

そこで役割を分けることにしました。

X = live log：途中経過、失敗、速報。
Web = organized archive：あとから自分でも探せる整理版。

「Webサイトを作ること」そのものが目的というより、これから試すことを残しやすい仕組みを作るのが目的でした。

構成はCloudflare + GitHub + Cloudflare Pages

まず独自ドメイン conydiyhouston.com をCloudflare Registrarで取得しました。取得時の表示価格は$10.46。Cloudflare Registrarは、レジストリとICANNの料金にマークアップを載せず「at cost」で提供する方針を案内しています。^[1]

Cloudflareでconydiyhouston.comが10.46ドルと表示された取得画面 — ドメインを探したときの画面。記事では必要部分だけにクロップしています。

HTMLや画像はGitHubのPrivate Repositoryで管理。最初はREADMEだけの、ほぼ空のリポジトリから始まりました。

READMEだけが入ったCony DIY Houstonの初期GitHubリポジトリ — GitHubもほぼ初見。最初はREADMEだけでした。

そのGitHubリポジトリをCloudflare Pagesへ接続。Cloudflare PagesはGitHubやGitLabと連携し、接続したブランチへ変更をpushすると自動でビルド・デプロイできます。^[2]

GitHubを更新

Cloudflareが自動デプロイ

Webサイト更新

Cloudflare PagesでCony DIY Houstonの初回デプロイに成功した画面 — 最初のデプロイ成功。「Region: Earth」と出たときは、とりあえずWebに出たことだけは分かりました。

Windows VPSも候補でした。
余っているWindows VPSにIISを立てる案も考えました。それはそれでDIYとして面白い。でも今回は「サーバーを管理すること」より「記事を気軽に増やせること」を優先して、静的サイト + GitHub + Cloudflare Pagesにしました。

立ち上げ〜初回公開まではiPhoneだけ

今回いちばん自分でも意外だったのが、ドメイン取得からGitHub、Cloudflare設定、HTML編集、画像アップロード、初回公開までをiPhoneだけで完結できたことです。公開後は、写真や動画の見え方を確認するためにPCでもデスクトップ表示をチェックするようになりました。なので正確には「サイトの立ち上げ〜初回公開はiPhoneだけ」です。

GitHubにはブラウザ上でファイルを直接編集する機能があり、Web UIからリポジトリ内のファイルを編集できます。^[3] ただし、スマホでやりやすいかは別問題。ファイル名、拡張子、フォルダ、Cloudflareの設定場所など、何度も「どこ？」になりました。

そのたびに画面をスクショしてChatGPTへ送り、「次はこれだけ」と1画面ずつ進める方式にしました。最初から全手順を理解していたわけではなく、分からない画面が出るたびに確認して進めた感じです。

最初のサイトは“Website coming soon.”だけだった

初めて独自ドメインで表示されたサイトは、かなり潔いものでした。

Cony DIY Houstonの初期サイトでWebsite coming soonとだけ表示されている画面 — 最初の公開版。ほぼ文字だけです。

そこからXで使っているプロフィールロゴ、ヘッダー画像、ネイビー×ゴールドをWebにも持ち込んでいきました。途中ではヘッダー画像を背景にして、その上へWeb側の文字を重ねる案も試しています。

ヘッダー画像の上にWebサイトの文字を重ねた制作途中のCony DIY Houstonトップページ — 途中案。雰囲気は出たけれど、スマホで見ると文字が渋滞しました。

最終的には、ヘッダー画像は画像として独立して見せる → 説明文はその下に分離。現在のトップページの形へ落ち着きました。失敗案を一度通ったことで、何が読みにくいのかも分かりやすかったです。

記事を増やせるように、HTMLも“仕組み化”した

最初はトップページだけでしたが、記事を1本ずつゼロから作るやり方では続きません。そこで途中から、共通デザインをstyle.cssへ分離し、記事用のHTMLテンプレートを用意しました。

images、article-template.html、index.html、style.cssを分けたGitHubリポジトリ構成 — READMEだけだったリポジトリが、images、article-template.html、style.cssを持つ構成へ。

共通CSS色、カード、記事本文、フッターなどを共通化。記事ごとにデザインを作り直さない。

記事テンプレート日英切替、公開日、本文、参考文献、質問フォーム、X導線まで基本形を固定。

カテゴリページHomebrewing、Pool、Lawn & Garden、DIY & Home、Shisha、Cooking & Lifeに整理。

日英別URL日本語と英語を別ページにし、同じ内容をそれぞれ読みやすく整理。

Xの実験ログを、あとでWeb記事に整理する

最初に記事化したのは、BeerDroidで仕込んだGerman Weissbierでした。

Xでは、発酵中の泡、温度変更、途中の疑問、実飲結果などをその場で投稿。Webでは、それらを後から時系列や結論が分かる形へ整理しています。

調べる

→

試す・測る

→

Xでリアルタイム記録

→

Webで整理

BeerDroidでGerman Weissbierを仕込んだ記事を見る →

今ではBeerだけでなく、Pool、Lawn & Garden、DIY & Home、Shisha、Cooking & Lifeも同じ考え方で増やせるようになりました。

公開後は、draft → Preview → main に運用を改善

サイトを公開してからは、公開中のページを直接いじらないように運用も変更しました。現在はmain = 本番、draft = 編集中として、draft側のCloudflare Previewで確認してからmainへマージしています。

Cloudflare PagesのGit連携は、production branch以外のブランチに対してPreview deploymentを作れるため、この運用と相性が良いです。^[2]

draftへ反映

→

Previewで確認

→

Pull Request

→

mainへ公開

アクセス数もCloudflareで確認できるようにした

公開後はCloudflare Web Analyticsも有効化しました。CloudflareはWeb Analyticsをprivacy-firstのReal User Monitoringとして案内しており、Page viewsや訪問、ページ体験の指標を確認できます。^[4]

まだサイトを作ったばかりなので、数字そのものより「どの記事が読まれ始めたか」を見る用途で使っていくつもりです。

公開後はGoogle Search Consoleで「検索からどう見えるか」も確認

サイトを一般公開したあとは、Google Search Consoleでドメインプロパティの所有権を確認し、sitemap.xmlを送信しました。GoogleのSitemaps reportでは、サイトマップの送信履歴や取得エラーを確認できます。^[5]

さらにURL Inspectionでトップページや主要記事をライブテストし、Googleから取得可能かを確認。必要なページはインデックス登録もリクエストしました。URL Inspectionは、Googleに登録されている状態の確認、ライブURLのテスト、インデックス登録リクエストに使えます。^[6]

公開後まもなく、Search Consoleから検索インプレッションの収集開始通知が届き、トップページや一部の記事で表示回数・クリックのデータが出始めました。Cloudflare Web Analyticsが「サイトへ来たあとのアクセス」を見る道具なら、Search Consoleは「Google検索でどう見つけられているか」を見る道具、という感じで使い分けています。

やってみて分かったこと

① 立ち上げならiPhoneだけでも意外といける快適とは言えない場面もあるけれど、GitHubとCloudflareのWeb UIだけで初回公開まで進められた。公開後のPC確認は別に使うと便利。

② 最初から完成形を作らなくていい文字だけ → 失敗したHero → 現在、と段階的に直した方が判断しやすかった。

③ 共通CSSとテンプレが効くサイト作りより「中身を残す」ことに時間を使えるようになった。

④ WebもDIYだった家やプールと同じで、調べて、試して、失敗して、直すの繰り返しだった。

まとめ

一番良かったのは、Webサイトそのものより「実験を残せる仕組み」ができたこと。

Xはライブの実験ログ。Webは整理した備忘録。GitHubとCloudflare Pagesで更新の流れを作り、立ち上げから初回公開まではiPhoneだけでも構築できました。

これからも、調べる → 試す → 測る → 比べる → Webに残す、を続けていきます。

Research. Try. Fail. Learn. Enjoy.

参考文献

Cloudflare Docs, Cloudflare Registrar — Overview. Cloudflare Registrarの「at cost / no markup」の説明。公式ドキュメント
Cloudflare Docs, Git integration — Cloudflare Pages. GitHub/GitLab連携、自動デプロイ、Preview deploymentの説明。公式ドキュメント
GitHub Docs, Editing files. GitHubのWeb UIからリポジトリ内ファイルを編集する方法。公式ドキュメント
Cloudflare Docs, Cloudflare Web Analytics. privacy-first analyticsとReal User Monitoringの説明。公式ドキュメント
Google Search Console Help, Sitemaps report. Search Consoleでサイトマップを送信し、処理状況やエラーを確認する方法。公式ヘルプ
Google Search Console Help, URL 検査ツール. Googleインデックスの状態確認、ライブURLテスト、インデックス登録リクエストの説明。公式ヘルプ

※スクリーンショット内の価格・UI・メニュー名は、制作時点（2026年8〜9月）の表示です。サービス側の画面や価格は今後変わる可能性があります。

この記事について質問・コメントがありますか？

GitHubやCloudflareで同じような静的サイトを作ってみたい、iPhoneだけでどこまでできるのか気になる、という質問があればお気軽にどうぞ。

Xでは制作中の失敗も含めて更新中

Webでは整理した完成版を残していますが、Xでは「今ここで詰まった」「こう直した」といった途中経過も更新しています。

Xで Cony DIY Houston を見る →

← DIY & Homeの記事一覧へ