GitHub DesktopとGitHub.com（ブラウザ）は何が違うのですか？

GitHub.comはGitHub社のサーバー上にあるデータを見るための画面で、自分のパソコンの中身を操作する権限は持っていません。GitHub Desktopは自分のパソコンにインストールするアプリで、パソコン内のファイルの変更を読み取り、サーバーに送信（push）できます。ローカルで直した内容をネットに反映させるには、GitHub Desktop側でpushする必要があります。

Cloudflareで「ビルドは成功しているのに公開されているサイトが変わらない」ときはどうすればいいですか？

ビルドの成功（Recent builds）と、実際に公開される内容が切り替わること（Active deployment）は別の情報として表示されます。まず画面をリロードして、Active deploymentのバージョンIDが最新のビルドに対応したものに変わっているか確認します。それでも変わらない場合は、Deploymentsタブで最新のバージョンが表示されているか、時間を置いて再度確認します。

Cloudflareで独自ドメインを紐付けてから、実際にそのドメインで表示されるまでどのくらいかかりますか？

私の場合は数分でした。「Domains」タブから「Add Domain」でドメインを追加すると、SSL証明書の発行が行われ、その後にそのドメインでアクセスできるようになります。追加した直後はまだ表示されないことがあるので、少し時間を置いてから確認するとよいです。

AstroサイトをCloudflareで公開するのに1時間30分かかった話。迷ったのは「どこで操作するか」だった

Astroで作ったサイトをローカルで表示できるようになってから（前回の記事）、次はこれをインターネット上に公開するところまでやった。GitHubにpushして、Cloudflareで独自ドメインが表示されるようになるまで約1時間30分。

前回と同じ結論を、また書くことになる。詰まったのは、コードではなかった。 今回は「今どの画面を、何のために操作しているのか」が分からなくなることの連続だった。

そもそもAstro・GitHub・Cloudflareとは何か

三つとも、作業を始めた時点では名前しか知らなかった。先に簡単に整理しておく。

Astro：ページの構造や見た目を組み立てるための土台（フレームワーク）。書いたファイルから、実際にブラウザで表示されるHTMLを生成してくれる。
GitHub：書いたコードの変更履歴を保管しておく置き場所。自分のパソコンで直したファイルを「これで確定」という単位（コミット）にまとめて送ると、そこから先はインターネット上のどこからでも参照できる状態になる。
Cloudflare：GitHubに新しい変更が送られてきたことを検知して、自動でサイトをビルドし直し、公開してくれるサービス。独自ドメインの管理もここで行う。

つまり「GitHubに送る（push）」ことが、そのまま「Cloudflareが公開中のサイトを更新する」ことにつながっている。

なぜこの組み合わせを選んだかというと、Claudeに勧められたからだ。 他にも選択肢はあるはずだが、比較して選ぶための判断軸を自分は持っていなかった。だから、Claudeが提案してくる構成をそのまま採用した。これが最適な組み合わせなのかは分からない。ただ、比較検討に時間をかけて着手が遅れるより、動くものを早く一つ作ってみることを優先した。

この「送る」という操作自体はワンクリックで終わる。難しかったのは、どこから送ればいいのかだった。

やったこと

手順	内容
1	ローカルの変更をGitHubにpush
2	Cloudflareでビルド・デプロイが走ったことを確認
3	Cloudflareに独自ドメイン（tsukurite.dev）を紐付け

一つひとつは単純な作業のはずだった。実際には、各ステップで「これで合っているのか」が分からず、そのたびに止まった。

つまずき①　GitHubの「どこ」を操作すればいいのか分からなかった

コミット（変更の記録）自体はできていた。次にやるべきは「push」だと分かっていたが、pushできる場所がどこなのか分からなかった。

ブラウザでGitHub.comのリポジトリページを開いて、pushボタンを探した。無かった。当然で、pushはブラウザからはできない。 ブラウザ版のGitHub.comは、GitHub社のサーバー上にあるデータを見るための画面で、自分のパソコンの中身に触る権限を持っていない。実際に操作するのは、パソコンに別途インストールした「GitHub Desktop」というアプリの方だった。

同じ「GitHub」という名前でも、見ている画面によって役割がまったく違う。この区別が分かっていなかったことに、しばらく気づけなかった。

つまずき②　Cloudflareの画面が「今どの状態か」を読み取れなかった

pushが終わったあと、Cloudflareのダッシュボードを開いた。ここでまた止まった。

「Recent builds」には、pushした内容のビルドが**成功（緑のチェック）**で出ている
しかし「Active deployment」のバージョンIDは、さっきから変わっていない

ビルドが成功しているのに、公開されているサイトの情報が更新されていないように見えた。壊れているのか、単に画面がまだ反映されていないだけなのか、その場では判断がつかなかった。

抜け出せた方法

画面をそのままスクリーンショットで貼り付けて、「この画面はどういう状態？」「次に何をすればいい？」とAIに聞き直した。

これが一番早かった。自分で用語を調べて理解しようとするより、今見えている画面をそのまま見せて、今の状態と次の一手だけを教えてもらう方が、迷う時間が圧倒的に短くなった。

独自ドメインの設定も同じ進め方だった。

Cloudflareの「Domains」タブを開く（最初は「No custom domains」と表示されていた）
「+ Add Domain」から tsukurite.dev を追加
一覧に tsukurite.dev が表示されたことを確認
数分待ってから https://tsukurite.dev を開くと、表示された

ここは手順自体は短かったが、「本当にこれで合っているのか」の確認を毎回AIに挟みながら進めた。

分かったこと

今回も、詰まったのはコードの中身ではなかった。 「今どの画面を見ていて、それが何を意味するのか」が分からないことの方が、作業時間の大半を占めた。

もうひとつ気づいたことがある。今回の作業だけで、VS Code、GitHub Desktop、GitHubのブラウザ画面、Cloudflareのダッシュボードと、複数の異なるアプリ・サービスを行き来することになった。しかも表示は基本的に英語（Active deployment、Custom Domains and Routes、Recent builds、など）。

非エンジニアが自分でサイトを作って公開するには、コードを書く力より前に、次の2つが必要なのだと思う。

初めて見るアプリやサービスの画面を、抵抗なく触ってみられること
ある程度の英語を、翻訳せずそのまま読めること

どちらもプログラミングの知識ではない。むしろこちらの方が、非エンジニアにとっての実質的なハードルだと感じた。

次は、Google Search Consoleへの登録と、AI引用の計測を始めるところまでやる。