Coffee Break

構築から執筆・画像作成までAI任せ！？Astro×Cloudflareの無料枠で作るブログの裏側（GitHub連携）

Wed, 28 Oct 2026 00:00:00 GMT

「Astro + Cloudflare + GitHubの組み合わせなら、無料で爆速のブログが公開できるらしい」。私はネットで、そんな記事を見かけました。しかし、最新のWeb技術の具体的な手順なんて、私にはさっぱり分かりませんでした。

※この記事でいう「無料」は、ブログの構築・公開に各サービスの無料枠を使うという意味です。独自ドメインの取得・更新や、利用するAIサービスの料金は別です。無料枠にも上限があります。静的ファイルの配信については、Cloudflareの料金・制限の説明を確認してください。

そこで、AI（Codex）に向かってお願いをしてみました。「AstroとCloudflareとGitHubを組み合わせて無料で構築したいのだけど、よく分からないから手伝って！」そうやって、手取り足取り教えてもらいながら、何度かチャットで会話を重ねてみました。すると……なんと、あれよあれよという間にブログのシステムが完成してしまった（というより、構築してもらった）のです！

しかも、実はここだけの話があります。ブログに投稿している記事の文章も、私が書いているわけではありません。「こんな内容で書いて」とAIにお願いして書いてもらったものです。さらに、その記事のテイストに合うようなアイキャッチ画像も、AIに作ってもらっています。見出し（H2）直下に差し込む画像も、文章に合わせてAIに作ってもらっているのです。

つまり、私はAIと会話しているだけです。それだけで、システムの構築から執筆、イラスト作成までがすべて完結してしまったというわけです。

ただ、AIが作った文章は、日本語が少し不自然だったり、内容が「？」と思うときがたまにあります。そのため、公開前にしっかりと自分の目でチェックして、修正をする必要はあります。それでも、イチから自分で書くよりは断然ラクです。

しかし、ここで大きな問題が発生しました。ブログが「できちゃった」のは良いものの、どうやって構築されたのかが全く分かりません。裏側でどんなシステムが、どのように連携して動いているのでしょうか。ブログの持ち主である私自身が、全く分かっていなかったのです。

これでは今後の運用もできません。何かトラブルが起きても、完全にお手上げ状態です。そこで、説明の記事をCodex自身に書いてもらいました。

それがこちらの記事です。AstroブログをCloudflare Workersで公開した記録

ところが、私には読みづらく感じられました。内容が専門的すぎるだけでなく、文章もちょっと変で、よく分かりませんでした。そこで、Codexとさらに会話を重ねながら、改めてこの記事を作成することにしたのです。

このブログを設計し、裏側のシステムをまるっと管理してくれているCodexに、改めて依頼をしました。「さっきの記事をもっと初心者にもわかりやすく説明して！」とお願いしたのです。そして、「ここってどういう意味？」「ここはこう直して」と何度かやり取りを続けました。

その結果として出来上がったのが、今あなたが読んでいるこの記事です。ブログの構成と公開までの仕組みを、初心者にもわかるようにまとめ直しました。

この記事は、AIの力で「できてしまった」ブログの裏側を紐解いたものです。AI自身に解説してもらって仕組みを理解した、私の備忘録でもあります。

1. そもそも、このブログは何で作られているの？（Astroの役割）

WordPressを使わず「Astro」を採用

AIの解説：「WordPressではなく、Astroというシステムを使いました」

ブログといえば、WordPress（ワードプレス）が有名です。しかし、今回Codexが選んだのは「Astro（アストロ）」というツールでした。そして、「Fuwari」というブログ用のデザインテンプレートを使っています。

このブログでは、WordPressのようにログインして記事を書く管理画面を用意していません。私は自分のパソコン上で、記事のファイルを編集する運用にしています。「Markdown（マークダウン）」というテキストファイルに、直接文字を書いていく仕組みです。

記事の文章もAIが書いている

Markdownは、見出し（#）や太字（**）などを簡単な記号で表現するためのルールです。そのルールで書いた文章を、Markdownファイルとして保存します。

ただ前述の通り、このMarkdownファイルの中身を書いているのも実はAIです。私が「コーヒー器具のお手入れについて書いて」と指示を出します。すると、AIが文章を書いてくれます。画像も一緒に作ってくれます。私はそれらを、指定されたフォルダ（例：src/content/posts/coffee-care/）にポンポンと保存しているだけなのです。

ページを先に作っておくから、表示の負担が少ない

Astroは、このテキストファイルや画像を読み込みます。そして、読者がブラウザで見られる「Webページ（HTML）」にあらかじめ変換してくれるツールです。

このブログは、読者がページを開くたびにデータベースから本文を取り出す仕組みを使っていません。あらかじめ作ったページを配るので、表示に必要な処理を少なくできます。ただし、実際の表示速度は画像の大きさや通信環境にも左右されます。

Astroには、アクセスに応じてページを作る機能もあります。ここで説明しているのは、このブログで採用した「先にページを作っておく」方式です。Astro公式の説明でも、この違いを確認できます。

2. ブログのデータはどこに保存されているの？（GitHubの役割）

GitHubという「非公開の金庫」

AIの解説：「記事や画像、設定ファイルはGitHubという金庫にしまってあります」

管理画面がないなら、AIが書いてくれた記事データや画像はどこに保存されるのでしょうか。Codexがデータの保管先に指定したのは、「GitHub（ギットハブ）」というサービスでした。

公開する記事や画像、ブログの設定ファイルは、このGitHubに保存しています。パスワードなどの秘密情報は保存しません。ここは「非公開リポジトリ」と呼ばれる場所です。一般の人には公開せず、私や、私がアクセスを許可した人・連携サービスだけが利用できる保管庫です。

アカウント作成からAIがお手伝い

完成したブログのページ自体は、世界中の誰でも見られます。一方、設定ファイルや変更履歴を置くリポジトリ自体は非公開です。ただし、公開した記事の本文や画像は、ブログを通じて誰でも読んだり保存したりできます。

実は作業開始当初、私はGitHubのアカウントすら持っていませんでした。最初は自分のパソコンの中だけで、ブログの形を作りました。その後、Codexに手伝ってもらいながら、初めてGitHubのアカウントを作りました。そして自分用の保管庫を用意して、ようやくデータを移したのです。

3. どうやってインターネットに公開しているの？（Cloudflareの役割）

全自動で公開する「Cloudflare Workers」

AIの解説：「Cloudflare Workersが、全自動でブログを組み立てて配っています」

では、GitHubの金庫に入れたデータを、どうやって世界中に公開しているのでしょうか。

独自ドメイン（nishikobe.com）で表示させるためには、仕組みが必要です。

ここで登場するのが「Cloudflare Workers（クラウドフレアワーカーズ）」です。Codexは、私の代わりに公開用のサーバーとしてCloudflareを設定してくれました。

そして、このブログ専用の「Worker（働くロボットのようなもの）」を一つ作ってくれていました。

複雑な設定もAIと二人三脚で

このWorkerに、先ほどのGitHubをつなぎます。

すると、「GitHubに新しい記事のデータが届いたら、自動的にブログを組み立てて公開してね」という指示が働きます。

このような自動化の設定（Workers Builds）が組み込まれていたのです。

Cloudflareの公式資料にも、GitHubなどへのプッシュをきっかけにビルドとデプロイを行う仕組みが説明されています。

もちろん、私はCloudflareのアカウントも持っていませんでした。 GitHubのアカウント作成に続き、Cloudflareのアカウント開設もCodexにお願いしました。

この複雑そうな自動連携の設定まで、すべてCodexに手取り足取り手伝ってもらいました。完全に二人三脚で準備を進めたのです。

4. 自動公開の罠！パソコンで保存しただけでは更新されない

ブログを更新するための3つのステップ

ゼロから一緒にアカウントを作り、AIが設定してくれた仕組みは本当に素晴らしいです。

しかし、初心者の私が一番戸惑ったのが「記事の更新方法」でした。

「パソコンでファイルを上書き保存しただけでは、ブログは一切更新されない」という事実です。

Codexに「AIが書いた記事を保存したのに、ブログが変わらないよ！」と泣きつきました。

すると、ブログを更新するには以下の3つのステップを踏む必要があると教わりました。

ファイルの保存： AIが生成した文章と画像を、パソコン上のフォルダに保存する。
Git（ギット）へのコミット： 「ここを追加した」という変更履歴をパソコン内に記録する。
GitHubへのプッシュ： 記録した変更履歴を、インターネット上のGitHubへ送信する。

このブログでは、3番目の「GitHubの本番用ブランチ（main）へプッシュする」という行動がスイッチになります。

これで初めて、Cloudflareの自動公開ロボットが動き出すのです。

「ビルド」と「デプロイ」の違いでつまずく

さらに、Cloudflareが動き出した後も安心できません。公開処理には2つの段階があります。

ビルド（生成）： Markdownのテキストファイルを、ブラウザで読めるWebページ（HTML）に変換・組み立てる作業です。
デプロイ（公開）： 組み立て終わったWebページを、実際のサーバーに配置して世界中から見られる状態にすることです。

「ビルドに成功しました！」というメッセージが出ても、まだ終わりではありません。

その後の「デプロイ」が終わっていなければ、新しい記事は読者に届かないのです。

実際、GitHubとの連携エラーで権限が足りないことがありました。

古いサイトのキャッシュが残り続けるなど、デプロイの段階で何度もつまずきました。

だから今では、Cloudflareの管理画面で「デプロイが完了したか」を最後まで必ず見届けるようにしています。

5. 人間とAIで分担！失敗を防ぐ「公開前の入念なチェック体制」

プログラムチェックはCodex（AI）の担当

自分がよく分かっていないシステムだからこそ、いきなり本番に公開するのはとても危険です。

そこで今は、作業の役割分担をしています。

Codex（AI）の担当：裏側でのプログラム自動チェック 公開前には、Codexに以下のコマンド（検証プログラム）を実行してもらう運用にしています。検査できる範囲はコマンドごとに異なります。
- pnpm check（型などのチェック）：AstroやTypeScriptのコードに、型の不整合などがないか。
- pnpm build（ビルド）：手元のパソコン環境でエラーなくHTMLを作れるか。
- pnpm verify（このブログ専用の検証）：生成したページのリンク先ファイルや画像が存在するか、代替テキストなどの設定があるか。
- pnpm secrets:check（このブログ専用の検査）：秘密情報によくある文字列のパターンが、ファイルに混ざっていないか。

目視確認は私（人間）の担当

私（人間）の担当：プレビュー画面の目視確認 Codexのチェックが終わった後、まずはパソコン上でプレビュー画面を開きます。 AIが書いてくれた文章がおかしくないかをチェックします。 AIが作ってくれたアイキャッチ画像や見出し下の画像が、意図した通りに綺麗に並んでいるか。人間の感覚が必要なこの部分を、自分の目でしっかりと確認します。

最終確認と、別サイトへの「安全装置」

最終確認と公開のスイッチ： Codexから、それぞれのチェック結果の報告を受けます。検査を通過しても、文章の正しさや、あらゆる不具合がないことまで保証されるわけではありません。それを確認したら、私が最終的な公開スイッチである「GitHubへのプッシュ（送信）」を行います。

実を言うと、「後々、2つ目や3つ目の新しいブログも作れるようにしておきたいな」と思い立ちました。

そこで、Codexに頼んで複数サイトを管理できる仕組みを、追加で構築してもらっていました。

現時点では、まだ別サイトは一つも存在していません。 しかし将来を見据えて、パソコン内のフォルダ構造はすでに複数サイト対応になっています。

そのため、設定を間違えて架空のサイトや別の場所にデータを送ってしまわないように注意が必要です。

公開前には「送信先の名前（設定ファイル）が本当にこのブログ用のもので合っているか？」をチェックします。

Codexと一緒に最終確認する安全装置も整えています。

【まとめ】AIが組んだブログ公開の仕組み・対比表

Codexに教えてもらった「ブログ公開までの作業フェーズ」をまとめました。

また、「採用されているツールの役割」も一覧にしています。私のような初心者でも理解できるように作成した表です。

1. ブログ公開までの3ステップと人間・AIの役割分担

ステップ	作業する場所	主に行うこと	誰が担当するか（注意点）
① 執筆・事前確認	自分のパソコン<br>（ローカル環境）	・AIによる記事執筆と画像作成<br>・コマンドによる各種エラーチェック<br>・プレビューでのレイアウト目視確認	AI：記事執筆、画像作成、エラーチェック（自動）<br>人間：プレビューの目視確認<br>※「上書き保存」しただけでは公開されません。
② 記録・送信	自分のパソコン → GitHub<br>（非公開リポジトリ）	・パソコン内で変更履歴を記録（コミット）する<br>・GitHubのmainへ送る（プッシュ）	人間：公開の最終スイッチを押す<br>※このブログでは、mainへのプッシュが自動公開の合図になります。
③ 変換・公開	Cloudflare<br>（本番サーバー環境）	・テキストをWebページに変換（ビルド）<br>・サーバーに配置して公開（デプロイ）	Cloudflareの自動ロボット<br>※「ビルド」と「デプロイ」は別工程です。完了まで見届けましょう。

2. ブログを裏側で支えるツールたちの役割

ツール・用語名	システム分類	AI（Codex）が設定した役割
Astro / Fuwari	ページ生成ツール / ブログテーマ	記事データから高速なWebページ（HTML）を生成するシステム。「Fuwari」というデザインをベースに使用。
Pagefind	サイト内検索エンジン	記事を変換するタイミングで検索用のデータを作り、ブログ内でキーワード検索ができるようにする仕組み。
GitHub	ソースと変更履歴の保管サービス	記事・画像・設定を保管する「金庫」。本番用ブランチへのプッシュを、Cloudflareで公開する合図にする。
Cloudflare Workers / Workers Builds	ページの配信 / ビルド・公開の自動化	Workers BuildsがGitHubへのプッシュを受けてページを生成・公開し、Workers Static Assetsが完成したページや画像を読者へ配信する。
Markdown	テキスト記述言語	管理画面の代わりに記事を書くためのルール。この中身の文章もAIに書いてもらっています。

「無料で公開したい」とAIにお願いしただけで出来上がってしまったブログですが、仕組みを紐解いてみると、複数の最新ツールが賢く連携していることが分かりました。

最初は各サービスのアカウントすら持っておらず、システムの裏側もサッパリでした。

しかし、アカウント作成から記事の執筆、画像の生成、そして面倒なエラーチェックまで、すべてAI（Codex）に任せています。

そうやって二人三脚で運用することで、自分だけでは難しかったブログ作りを進められました。

仕組みを少しずつ理解しながら、記事の内容と公開結果は、これからも自分の目で確かめていこうと思います。

AstroブログをCloudflare Workersで公開した記録｜GitHub連携と独自ドメイン設定

Tue, 27 Oct 2026 00:00:00 GMT

このブログは、Codexと対話しながらAstroで作りました。記事や設定をGitHubに保存し、Cloudflare Workersで公開しています。URLには、以前から持っていた nishikobe.com を使いました。

ところが、公開するまでに何度か手が止まりました。GitHubとの接続でエラーが出て、公開用トークンの権限も見直しました。独自ドメインをつないだ後は、古いサイトが見え続けました。

この記事では、2026年10月にブログを作った手順と、つまずいた場面を順に書きます。操作画面は変わることがあるので、自分で設定するときはリンク先の公式資料も確認してください。

Astroでブログを作り、GitHubからWorkersへ公開した

Fuwariを土台に、Astroで記事を作った

土台に選んだのは、Astroのブログテーマ「Fuwari」です。記事はMarkdownファイルに書きます。冒頭にタイトル、公開日、カテゴリーを書き、その下に本文を続けます。

たとえば、コーヒー器具のお手入れの記事は src/content/posts/coffee-care/index.md にあります。書き直すときは、このファイルを編集します。ブラウザー上の管理画面は使っていません。

Astroで記事や一覧ページをHTMLに変換してから、Workers Static Assetsで配信します。読者がページを開くたびに、データベースから本文を取り出す仕組みは使っていません。

静的なブログをWorkersへ公開する方法は、CloudflareのAstroガイドにも載っています。

ただ、Fuwariを入れるだけで、このブログの今の状態になるわけではありません。日本語の記事、プロフィール、カテゴリー、画像の置き方をこのサイトに合わせて直しました。検索や公開前の検査も、テーマとは別に加えています。

記事を書いたら、PCでページを開きました。Markdownファイルを読んだだけでは、見出しや画像がどう並ぶか分かりません。

このブログでは、記事一覧のアイキャッチと、H2見出しの直下に置く画像を別々に作っています。入れ忘れがないかも、表示されたページで見ました。

サイト内検索にはPagefindを使っています。検索用データができるのはビルド時です。開発用の画面で記事が読めても検索は試せないため、ビルド後のプレビューを開きました。

ソースをGitHubに保存し、公開の起点にした

記事や設定ファイルは、GitHubの非公開リポジトリに保存しました。非公開なのはソースです。完成したブログのページは、URLを知っていれば誰でも見られます。

作業を始めたころは、GitHubのアカウントもありませんでした。手元でブログを作り、アカウントとリポジトリを用意してから、Cloudflareへつなぎました。

公開に使うのは main ブランチです。PCで記事を直しても、それだけでは公開ページは変わりません。変更をGitに記録してGitHubへ送ると、Cloudflareの公開処理が始まります。

Gitに残した記録を見れば、後でどこを変えたかもたどれます。

PCのファイルを保存すること、Gitに変更を記録すること、GitHubへ送ることは別々です。サイトを直したのに公開が変わらないときは、どこまで進んだかを見ます。

PCには複数のサイトを置けるようにしています。その中で、Coffee BreakのGitリポジトリは独立させました。別サイトのファイルや公開先と混ざるのを防ぐためです。

公開先の取り違えを防ぐため、サイトごとに設定を分けた

後からPC上のフォルダーを複数サイト用に整理しました。Coffee Breakは sites/coffee-break/ にあります。一方、GitHubのリポジトリには、このブログのファイルだけを置いたままです。

Cloudflareは、GitHubに置いたリポジトリの一番上の階層からファイルを読み込みます。PC上では sites/coffee-break/ に置いていますが、GitHubにはこのブログのファイルだけを送っているため、Cloudflareのビルドルートは / です。

サイトごとに設定ファイルを作り、GitHubのリポジトリと公開に使うブランチを書いています。Cloudflareのアカウント、Worker名、公開URLもここにまとめました。

このサイトでは site.config.json に接続先を書き、wrangler.jsonc にWorkerの設定を置いています。公開前に送信先を調べるスクリプトも用意しました。画面を開いて記憶を頼りに選ぶ回数を減らすためです。

別サイトはGitHubやCloudflareのアカウントが異なるかもしれません。Coffee Breakの接続先を、そのまま共通設定にはできません。

公開前には、設定ファイルとGitの送信先が合っているかを調べます。別のリポジトリやWorkerへ送ってしまえば、Coffee Breakは更新されません。サイトが増えた今は、送信先の名前まで見てから公開します。

Workers Buildsで、更新を公開へつなげた

公開先には新しいWorkerを一つ作りました。既存のWorkerには触れていません。このWorkerにGitHubのリポジトリをつなぎ、main に変更を送るとビルドが始まるようにしました。

Workers Buildsでは、GitHubに変更が届くとビルドが始まります。必要なソフトを入れ、AstroをチェックしてHTMLを作る工程です。

続くデプロイで、Wranglerが生成済みのファイルをWorkerへ反映します。公式の設定資料にも、この流れが載っています。

ビルド時には、Astroのチェック、HTMLの生成、サイト独自の検査を順に行います。pnpm build ではPagefindの検索データも作ります。

Cloudflareの設定画面では、ビルドコマンドとデプロイコマンドを別々に入力しました。前者は公開するファイルを作り、後者はそのファイルをWorkerへ送ります。どちらか一方だけ終わっても、記事の更新は読者に届きません。

pnpm verify では記事や内部リンク、画像の代替テキストを調べます。pnpm secrets:check は、公開するファイルに秘密情報の既知のパターンが混じっていないかを調べるコマンドです。

**ビルド成功だけでは、新しいページはまだ見られません。**HTMLを作る工程と、Workerへ公開する工程は別です。Cloudflareの履歴では、対象のコミットがデプロイまで進んだかを見ました。

公開前にビルドと表示を確認した

記事を追加するときは、まずPCで文章と画像を見ます。それから型チェックとビルドを行い、生成されたファイルを検査します。エラーがなくても、最後にプレビューで記事と一覧を開きます。

最初の4記事を揃えたとき、Astroの型チェックは通りました。ビルド後には記事と一覧のHTMLに加え、Pagefindの検索データもできていました。

生成物の検査では、記事数とページ数、サイト内のリンクや画像を照合しました。ページ自体ができても、リンク先が欠けていることはあり得るからです。

手元で実行するコマンドは次の四つです。Cloudflare側のビルドにも同じ検査を入れました。PCで通ってもCloudflare上で失敗することはあるので、GitHubへ送った後の履歴も見ます。

pnpm check
pnpm build
pnpm verify
pnpm secrets:check

アイキャッチは記事一覧のカードだけに表示します。記事ページの冒頭には出しません。代わりに各H2の直下へ、その話題に合う画像を置きます。

画像が読み込まれるか、スマートフォンの幅でもアイキャッチが横長に見えるかは、公開前に確認する項目です。

カテゴリー名は日本語、URLは英語にしています。たとえば「コーヒー」のURLは coffee。この記事には「ブログ運営」を新設し、URLは blogging にしました。

表示名だけを追加すると、カテゴリーのリンク先が意図しないURLになることがあります。新しいカテゴリーでは、名前とURLを一緒に設定します。

記事一覧に表示されたカテゴリー名を押して、対応する一覧が開くかも見ます。ファイルの中で「ブログ運営」と書けていても、リンクが違えば読者は記事をたどれません。

構築当初は、検索エンジンに載せないための noindex を付けていました。その後、この設定を外し、サイトマップを用意しました。検索結果に載るかどうかはGoogleの判断ですが、少なくともサイト側で掲載を止める設定は取り除いています。

GitHub連携とビルド用トークンの設定でつまずいた

GitHubアカウントの登録から始めた

GitHubのアカウントを持っていなかったので、登録から始めました。ブログのファイルを保存し、Cloudflareとつなぐためです。

メールアドレスを入力したところ、Email domain could not be verified というエラーが出ました。使っていたのは hotmail.com です。

その後、アカウントは作れました。何がエラーの原因だったかは分かっていません。hotmail.com では登録できない、という意味ではありません。

ブログ用の非公開リポジトリを作り、サイトのファイルを送りました。Cloudflareが読み込むのは、このリポジトリの中身です。PCで記事を直しても、GitHubへ送るまでは公開に使われません。

登録時のエラーを越えても、Cloudflareとの連携でまた止まりました。GitHubへの登録と、二つのサービスの接続は別の作業です。どちらで止まっているのか、画面を見て切り分けました。

Cloudflareとの接続エラーを解消した

Cloudflareの作成画面でGitHubとの接続を選ぶと、GitHubに認可画面が開きました。画面に出た名前は「Cloudflare Workers and Pages」。今回の公開先はWorkersです。

認可画面では、Cloudflareがアクセスできるリポジトリを選びます。Coffee Breakのリポジトリだけを対象にしました。

認可画面は別ウィンドウで開きました。許可する前にアカウント名と対象リポジトリを見ます。「すべてのリポジトリ」と「選んだリポジトリだけ」では、許す範囲が違うからです。

認可を進めた後、Cloudflareに「Gitアカウントへの接続エラー」が出ました。GitHubに入った連携アプリを確認し、今回のインストールを解除しました。Cloudflareの画面から接続をやり直すと、先へ進めました。

エラーの原因までは分かっていません。今回分かったのは、連携アプリを入れ直した後に接続できたことだけです。同じ表示が出ても、誰にでもこの方法が必要とは限りません。

同じエラーが出たら、まずGitHub側でアプリの状態と対象リポジトリを見てください。確認する場所はCloudflareのGit連携資料にも載っています。

すでに別サイトでも連携アプリを使っているなら、解除する前に影響を確かめる必要があります。

最初のビルドを止めて、権限を整理した

GitHubとの接続後は、ビルドと公開に使うAPIトークンを設定しました。先に自分で作ったWorkers向けのトークンは、候補に出てきません。そこで、Cloudflareの作成画面からビルド用トークンを作りました。

表示された権限には、Workersのほかにデータベース、ストレージ、AIなども含まれていました。このブログでは使っていない機能です。そのまま公開を始める前に、権限を整理することにしました。

初回だけ、ビルドが途中で止まるようにコマンドを設定しました。Workerとトークンを作ってから、権限を直すためです。最初の履歴は「失敗」と出ましたが、このときは予定どおりでした。

通常のビルドコマンドの代わりに、終了コード1を返す短いコマンドを入れました。Cloudflare上では失敗の履歴になりますが、デプロイには進みません。権限を直す時間を作るための、一時的な設定です。

CloudflareのAPIトークン画面で、不要な権限を外しました。残したのは、アカウントに対する「Workersスクリプトの編集」と「アカウント設定の読み取り」です。

ただ、管理画面ではWorker一つにだけ権限を絞れませんでした。対象アカウント内のWorkersに及ぶ設定です。トークン名にブログの名前を付けても、操作できる範囲までブログ専用になるわけではありません。

公開先のWorker名は wrangler.jsonc に指定してあります。それでも、設定ファイルの公開先とトークンが操作できる範囲は別です。両方を見ておくと、権限を絞ったつもりで広く残してしまうのを防げます。

初回ビルドを止めたのは、今回の画面でトークンを作るために選んだ方法です。毎回必要な手順ではありません。公開を許す前に、そのトークンで何を操作できるかを見ることが肝心でした。

設定を戻し、デプロイ完了まで確認した

権限を直したら、ビルドコマンドを通常の設定へ戻します。途中で設定画面を再読み込みした際、保存前の入力が消えたこともありました。控えていたコマンドと環境変数を入れ直し、保存内容を見ました。

トークンを編集した直後、Workerの設定画面では「利用できません」と出たこともあります。トークン一覧で有効なことを確かめ、設定画面を再読み込みすると、名前が正しく表示されました。表示だけで新しいトークンを作り直さずに済みました。

ビルドは、依存関係のインストールから始まります。Astroのチェック、HTMLと検索データの生成、生成物の検査が終わると、npx wrangler@latest deploy で公開します。

Cloudflareの画面では、ビルドが終わったところで閉じず、デプロイの完了まで見ました。

設定を戻した後は「ビルドを再試行」を使いました。ログで通常のコマンドに変わっているかを先に見て、最後にデプロイの成功表示を確認します。途中に Uploaded と出ても、それだけでは公開完了とは判断しません。

意図して止めた初回と、その後に成功した回は、同じ「ビルド履歴」に並びます。「失敗」の行が残っていても、それだけで現在の公開状態は分かりません。新しい履歴の日時とコミットを見て、どこまで進んだかを確かめました。

接続が済めば、記事を更新するたびに認可画面を開く必要はありません。変更を main へ送ると、Workers Buildsが動きます。

最初に決めた公開先とビルドコマンドは、その後の更新にも使われます。設定内容を残しておけば、次に更新が止まったときも見直せます。

独自ドメインへの切り替えは、DNSと画面表示を分けて確かめた

所有していた nishikobe.com をWorkerに接続した

nishikobe.com は、ブログを作る前から持っていたドメインです。Workerでサイトを公開できた後、このドメインをつなぎました。

迷ったのは、ドメインをどこまで使うかでした。coffee.nishikobe.com なら、元のトップページを残したままブログを追加できます。選んだのは nishikobe.com そのもの。以前のWebサイトをCoffee Breakに置き換える形です。

このドメインでメールは使っていません。そのため、今回はWebサイトの切り替えを中心に進めました。メールを使っているドメインなら、メール用のDNSレコードも確認が必要です。

Cloudflareにドメインを追加し、WorkerのCustom Domainとして nishikobe.com を接続しました。サイトの設定ファイルに書くURLも、同じ名前に変えます。記事の正規URLや案内先が、実際の公開先とずれないようにするためです。

Worker名を変えることと、訪問者が使うドメインを変えることも別の設定です。ドメインだけ切り替えて、サイト内に古いURLが残らないよう、公開URLを持つ設定ファイルも見直しました。

CloudflareのCustom Domains資料によると、Workerにドメインを割り当てる際は、必要なDNSレコードと証明書が用意されます。画面で接続状態を確かめ、Workerの初期URLはオフにしました。訪問者には独自ドメインを使ってもらう設定です。

Workers Buildsの最新の履歴は「準備完了」。それでも、nishikobe.com で正しいページが開くとは限りません。次はDNSを調べました。

DNSに旧サーバーの情報が見えた

PCで nslookup を実行すると、以前のサーバーのIPv4アドレスが表示されました。同じ画面にはCloudflareのIPv6アドレスもあります。古い情報と新しい情報が混ざって見えました。

DNSは、ドメイン名から接続先を調べる仕組みです。ただ、nslookup の結果が一つあるだけでは、どこに古い情報が残っているか分かりません。Cloudflareの設定か、問い合わせ先のDNSサーバーか。すぐにレコードを削除せず、順に調べました。

まず見たのはネームサーバーです。これは、そのドメインの接続先を正式に答えるサーバーを指します。ドメイン登録先で指定した名前がCloudflareの案内と違えば、Workerの設定が正しくても届きません。

CloudflareのDNS設定資料にも、ドメイン追加後にネームサーバーを切り替える手順が載っています。

ネームサーバーを切り替えた直後は、問い合わせ先によって答えが違うことがあります。旧サーバーのIPが一度出たからといって、公開失敗とは決められません。次は問い合わせ先を指定して比べました。

問い合わせ先を変えて、DNSの切り替えを確認した

Cloudflareの公開DNSと、このドメインに割り当てられたネームサーバーへ直接問い合わせます。PCで実行したのは次のコマンドです。

nslookup -type=A nishikobe.com 1.1.1.1
nslookup -type=A nishikobe.com margaret.ns.cloudflare.com

-type=A はIPv4の接続先を調べる指定です。二つ目の問い合わせ先は、このドメインに割り当てられたネームサーバーです。自分のドメインで試す場合は、Cloudflareの画面に出た名前に置き換えてください。

このとき、どちらの問い合わせにもCloudflareのIPv4アドレス 104.21.88.22 と 172.67.171.250 が返りました。先ほどPCで見た以前のサーバーの接続先は含まれていません。少なくとも、この二つの問い合わせではCloudflareの接続先が返った、という結果です。ただ、ここでDNSの確認は終わりませんでした。Aレコードを問い合わせた時点では新しいIPアドレスが返っていましたが、ネームサーバーの応答は別の動きを見せたからです。

そこで、Cloudflareの公開DNSに対してNSレコードも調べました。

nslookup -type=NS nishikobe.com 1.1.1.1

NSレコードは、そのドメインのDNS情報を管理するネームサーバーを示します。最初の数回は uns01.lolipop.jp と uns02.lolipop.jp が返り、その後はCloudflareの margaret.ns.cloudflare.com と mike.ns.cloudflare.com が返りました。ところが、Cloudflareの名前が続いた後に、Lolipopの名前へ戻ることもありました。

数分の間に同じコマンドを何度か実行したところ、旧ネームサーバーとCloudflareのネームサーバーが交互に見える時間帯がありました。返答に含まれる二つの名前の順番も入れ替わりました。毎回同じ結果になるわけではなく、画面を見ているだけでは、どちらが最終状態なのか判断しにくい状況でした。

このとき、1.1.1.1のキャッシュ更新ページを開き、nishikobe.com のNSレコードとAレコードを更新しました。その後も同じNS問い合わせを続けると、Cloudflareのネームサーバーが何度も返る一方で、Lolipopのネームサーバーが返る回もありました。キャッシュ更新の操作だけで、すべての応答がただちに揃ったわけではありません。

ここで分かったのは、1.1.1.1に問い合わせたときの応答が、確認するたびに変わって見えたことです。なぜその切り替わりが起きたか、どのキャッシュや経路が関係したかまでは特定できませんでした。したがって、「キャッシュを更新すれば必ず直る」とは言えません。私は、キャッシュ更新後も数回に分けて照会し、返答の推移を記録しました。

確認するときは、AレコードとNSレコードを混同しないことも大切です。AレコードはIPv4の接続先、NSレコードはDNS情報を管理するサーバーを示します。Aに新しいIPが返っていても、NSの応答が落ち着いたとは限りません。両方を確認したうえで、実際のページ表示も別に見ました。

この結果だけで、すべてのDNSサーバーが切り替わったとは言えません。実際、1.1.1.1にネームサーバーを問い合わせると、旧サーバーの名前が返ることもありました。DNSの応答とブラウザーの表示は分けて確かめる必要があります。普段のブラウザーには、まだ古いサイトが出ていました。

シークレットウィンドウでは新サイトが表示された

同じ https://nishikobe.com/ を、シークレットウィンドウで開いてみました。こちらには新しいCoffee Breakが表示されます。一方、普段のウィンドウでは旧サイトのままです。

シークレットウィンドウで開けたなら、独自ドメインから新サイトに届いています。通常のウィンドウだけ表示が違う理由は、ブラウザー側にもありそうです。

シークレットウィンドウは、普段のウィンドウに残った情報の影響を受けにくい状態で試せます。ただし、表示の違いだけで原因まで特定はできません。

シークレットウィンドウでも旧サイトが出るなら、DNSやCustom Domainの設定を見直すところでした。今回は新サイトが見えたので、まず通常のブラウザーを再起動しました。

ブラウザーを再起動すると、通常画面も新サイトになった

ブラウザーを終了して立ち上げ直すと、通常のウィンドウにもCoffee Breakが表示されました。再起動で直ったことは確かです。ただ、旧サイトの表示にブラウザー内の何が影響していたかまでは調べていません。

振り返ると、「公開できたか」には少なくとも三つの確認がありました。ビルドが終わったか、DNSが向いたか、ブラウザーで開けるか。どれか一つを見ただけでは足りません。

確認する段階	今回見たもの	分かったこと
ビルドとデプロイ	最新のコミットの履歴が準備完了か	ビルドとデプロイの工程が完了したか
DNS	公開DNSとCloudflareのネームサーバーへの問い合わせ	確認した接続先がCloudflareへ向いているか
ブラウザー表示	通常とシークレットの両方で同じURLを開く	実際に新しいブログが見えるか

次に同じ構成で作るなら、GitHubへ送った後のビルドとデプロイ、DNS、ブラウザー表示の順に見ます。記事ページまで開いて、ようやく公開の確認が終わります。

現在、Coffee Breakは独自ドメインから開けます。作ってみて難しかったのは、設定した後に「どこまで動いたか」を見極めることでした。同じところで止まった人は、ビルド、DNS、ブラウザーのどこで表示が変わるかを順に見てみてください。

コーヒーミルの選び方｜量・挽き目・手入れで決める

Tue, 27 Oct 2026 00:00:00 GMT

コーヒーミルを探し始めると、手動か電動か、刃の種類は何か、と選択肢が次々に出てきます。最初に決めたいのは、普段一度に挽く量です。そこから使う抽出器具と、片付けにかけられる手間を考えると、必要な機能が見えてきます。

この記事では特定の商品を順位づけしません。買った後も使い続けやすいかを、三つの順番で確認していきます。

まず、普段挽く量から手動か電動かを考える

一杯ずつ淹れるなら、手動ミルも候補になります。ハンドルを回す時間がかかるので、毎朝何杯分も用意するなら、その作業を続けられるか想像してみてください。店頭で試せる場合は、握りやすさや回しやすさも確かめたいところです。

電動ミルは、まとめて挽く機会が多い人に向いています。ただし、置き場所と電源が必要です。購入前には本体の寸法に加え、豆を入れる部分と粉を受ける容器の容量を確認しましょう。

容量は「何杯用」という表示だけでなく、グラム数で比べると分かりやすくなります。たとえばHARIOの手動ミル「セラミックスリム」は、公式の商品ページでコーヒー粉24g・2杯用と案内されています。自分が一度に使う豆の量と照らし合わせてみてください。

挽き目は、普段使う器具に合わせる

挽き目は、挽いた粉の細かさです。ペーパードリップとフレンチプレスでは、目安となる挽き目が違います。UCCは、ペーパードリップには中細挽き、フレンチプレスには中細挽きから粗挽き程度を紹介しています（ペーパードリップ、フレンチプレス）。

商品を選ぶときは、使う器具に合う範囲を調整できるか見ます。「細挽きから粗挽きまで」と書いてあっても、調整の幅や一段ごとの変化は製品ごとに違います。エスプレッソにも使いたいなら、メーカーがその用途を明記しているか確認してください。

刃の方式も気になるかもしれません。回転刃で豆を砕くもの、臼のような刃ですりつぶすものなどがあります。方式名だけで良し悪しを決めず、メーカーの挽き目の案内と、調整方法が分かりやすいかを確かめる方が、使う場面に合った選択につながります。

掃除の手順を買う前に調べる

豆を挽くと、刃や粉の通り道に細かな粉が残ります。受け容器だけでなく、刃の周りへ手が届くかを説明書で見ておきましょう。取り外せる部品や、水洗いできる範囲は製品ごとに異なります。

同じ「コーヒーミル」でも、手入れの方法は共通ではありません。HARIOのセラミックスリムは公式案内で臼部分の分解と水洗いを説明しています。一方、BaratzaのEncore ESPの説明書は、刃や本体内部を水で洗わず、ブラシで掃除するよう案内しています。実際には購入した製品の説明書に従ってください。

候補が二つまで絞れたら、次の順に見比べると判断しやすくなります。

確かめること	見る場所
一度に使う豆が入るか	容量の表示
抽出器具に合う挽き目を選べるか	メーカーの用途・調整案内
毎回の掃除が負担にならないか	取扱説明書の清掃手順
置き場所に収まるか	本体寸法、ハンドルやコードの位置

ミルを選んだ後は、いつも同じ量の豆を挽いて、挽き目を少しずつ動かしてみてください。味の変化を比べたいときは、ドリップコーヒーの淹れ方で豆と湯の量もそろえると分かりやすくなります。

製品の仕様と手入れの方法は2026年10月27日に確認しました。購入時は、現行モデルの説明書を確かめてください。

コーヒー豆の品種を知る｜ティピカ・ブルボンなど4つの名前

Tue, 27 Oct 2026 00:00:00 GMT

豆の袋に書かれた「ブルボン」「ゲイシャ」。気になる名前ですが、味を想像しようとしても、違いがつかみにくいかもしれません。品種を知るには、まず「アラビカ」との関係を整理すると分かりやすくなります。

ここでは代表的な四つの名前を取り上げます。どれもアラビカ種の品種ですが、木の姿や来歴はそれぞれ違います。飲むときは、品種名を一つの手がかりにしてください。

アラビカは「種」、ブルボンはその中の「品種」

コーヒーには、広く栽培されているアラビカ種とカネフォラ種があります。カネフォラ種は、一般に「ロブスタ」という呼び名でも知られています。これはコーヒーの木を分ける、種の段階の話です。

ティピカやブルボン、カトゥーラ、ゲイシャは、アラビカ種の中にある品種です。World Coffee Research（WCR）の品種カタログも、アラビカとロブスタを分け、その中で品種を紹介しています。

産地や精製方法は、さらに別の情報です。たとえば「ブラジル」は生産国、「ウォッシュド」は収穫後の処理方法を指します。袋に並ぶ言葉を全部「品種」だと思わず、何を表す名前かを一つずつ見てみましょう。

四つの品種には、それぞれ異なる来歴がある

WCRの品種カタログをもとに、ティピカ、ブルボン、カトゥーラ、ゲイシャの来歴をまとめました。表に挙げた木の高さや系統は、カップの味を示すものではありません。

品種	どんな品種か
ティピカ	背が高く、収量は低め。アラビカの歴史で重要な系統の一つ
ブルボン	背が高く、カトゥーラなどにつながる系統。高地での品質の可能性が高いと評価される
カトゥーラ	ブルボンから生じた自然突然変異。木が小さく、密に植えやすい
ゲイシャ（パナマ系統）	エチオピア由来の系統がパナマで広まった。花を思わせる香りで知られる

ティピカとブルボンは、コーヒーの品種を調べると繰り返し登場します。そこからカトゥーラのような品種が生まれたことを知ると、豆の名前に系譜があると分かります。詳しい栽培特性はWCRのティピカ、ブルボン、カトゥーラの解説で確認できます。

ゲイシャについては、表記だけで同じ系統と決めつけない方がよさそうです。WCRのゲイシャ（パナマ）のページは、パナマで知られる特定の系統を説明しています。販売店の説明に、産地や農園、精製方法まで書かれているかも見てください。

品種名は、味を探すための手がかりにする

同じ品種名の豆でも、栽培された場所や収穫後の精製、焙煎によって飲んだ印象は変わります。品種名だけで酸味や苦味を言い当てるのは難しいでしょう。

豆を選ぶときは、品種名に加えて産地、精製方法、焙煎度を見ます。初めての品種なら、店の味の説明を読み、好みに近そうな少量の豆を買うと試しやすいでしょう。飲んだ後に「香りが好き」「後味が軽い」など、一言だけでも残すと次の豆選びに役立ちます。

二種類を比べるなら、豆と湯の量、挽き目、淹れ方をできるだけそろえます。違いを感じても、それが品種だけから生まれたとは限りません。まずは自分がどちらをまた飲みたいと思うかを確かめてみてください。淹れ方をそろえる手順は、ドリップコーヒーの基本で紹介しています。

品種の分類、来歴、栽培特性はWCRの品種カタログを2026年10月27日に確認しました。掲載画像は分類や飲み比べを表すイメージで、枝の見た目だけで品種を判別する図ではありません。

ドリップコーヒーの淹れ方｜一杯分の量と注ぐ順番

Tue, 27 Oct 2026 00:00:00 GMT

ドリップコーヒーを淹れるたびに味が違うなら、まずは粉と湯の量をそろえてみてください。毎回の基準ができると、次は何を変えればよいか考えやすくなります。

ここでは、ペーパーフィルターを使って一杯分を淹れます。UCCの公開レシピを目安にしながら、道具の準備から片付けまで順に進めましょう。

一杯分の粉と湯を量ってから始める

用意するのは、ドリッパーとそれに合うペーパーフィルター、粉、ポット、カップです。できれば、粉と湯を量るためのはかりも使います。サーバーを使う場合は、淹れる量に合ったものを選んでください。

UCCの一杯分の目安は、粉10〜12g、注ぐ湯160ml、できあがり約140mlです。湯の一部は粉に残るため、注いだ量とカップに入る量は同じになりません。まずは粉12gと湯160mlで試し、飲んでから調整してもよいでしょう。

湯は沸騰させた後、少し落ち着かせます。UCCのペーパードリップの手順では92〜96℃を目安にしています。温度を測れないときは、熱い湯を扱うことに気をつけながら、同じ手順で繰り返すことを先に意識してください。

最初に粉を湿らせ、湯を数回に分けて注ぐ

フィルターをセットし、粉を入れて表面を軽く平らにします。初めに少量の湯を注ぎ、粉全体を湿らせて約20秒待ちます。UCCは中細挽きの粉12gに対し、蒸らしの湯約20ml・約20秒を一例として示しています。

蒸らしには、粉に湯をなじませ、粉の中のガスを逃がす役割があります。注いだ湯が一か所だけを通らないよう、中心から外へ小さな円を描いて、乾いた粉を残さないようにします。

蒸らした後は、湯を何回かに分けて注ぎます。粉の面が大きく崩れないように、中心付近からゆっくり注いでください。蒸らしに使った分も含め、合計で約160mlが目安です。注ぎ終わったら湯が落ちるのを待ち、カップに移します。

やけどを防ぐため、カップやサーバーは安定した台の上に置きます。抽出中は器具が熱くなるので、動かすときは取っ手を持ちましょう。

好みと違ったら、一度に一つだけ変える

薄く感じたら、次の一杯では粉を少し増やしてみます。濃く感じたら、粉を減らすか湯を増やす方法があります。UCCのカップ別レシピも、粉量、湯量、挽き目の調整例を示しています。

粉量、湯量、挽き目を同時に変えると、どれが味に影響したか分からなくなります。たとえば「粉を12gから少し減らす」と決めたら、湯量と挽き目はそのままにします。豆の名前と変えた点をメモしておくと、好みの一杯をもう一度淹れやすくなります。

味の感想は「軽い」「苦味が強い」など、普段の言葉で十分です。慣れてきたら挽き目にも目を向けてみてください。ミルをこれから選ぶ方は、コーヒーミルの選び方も参考になります。

抽出後はフィルターと粉を取り除き、ドリッパーやサーバーを製品の説明書に沿って洗います。器具別の洗い方は、コーヒー器具のお手入れにまとめました。

粉量、湯量、蒸らし、湯温はUCCの公開資料を2026年10月27日に確認しました。豆や器具によって適した条件は変わるため、数値は出発点としてお使いください。

コーヒー器具のお手入れ方法｜ドリッパー・サーバー・ミルの片付け方

Mon, 26 Oct 2026 00:00:00 GMT

ドリッパーやサーバーは水洗いできても、ミルの刃は水にぬらさないほうがよい場合があります。器具を洗う前に、部品ごとに水洗いできるか確かめましょう。

同じ種類の器具でも、洗える範囲や使える洗剤は製品によって異なります。ドリッパーとサーバーの洗い方、ミルの掃除方法を順に説明します。手入れを始める前に、お使いの製品の取扱説明書も確認してください。

まず、器具を水洗いできるか確かめる

器具を流しに運ぶ前に、取り外せる部品を確認します。電動器具は電源を切り、プラグを抜いてから手入れしてください。水洗いできる部品が分からないときは、型番を手がかりに取扱説明書を確認しましょう。

器具・部品	手入れのしかた	確認すること
ドリッパー・サーバー	使用後に洗い、水気を切って乾かす	水洗い・洗剤・食洗機に対応しているか
ミルの刃や粉の通り道	残った粉をブラシなどで払う	外せる部品と水洗いできる範囲
電動器具の本体	電源を切り、プラグを抜いてから手入れする	本体を拭く方法と、触れてよい部分

たとえばシロカのコーヒーメーカーのお手入れ案内では、水洗いできる部品と、洗えないミル・本体を分けて説明しています。お使いの器具も、部品ごとに確認してください。

ドリッパーとサーバーは、洗った後によく乾かす

器具が冷めたら、使用済みのフィルターと粉を捨てます。水洗いできるドリッパーとサーバーは、取扱説明書に従って洗い、よくすすぎましょう。水気を切り、内側や注ぎ口に水滴が残っていないことを確かめてからしまいます。

使う洗剤やスポンジは、製品の案内に従ってください。HARIOの「V60 珈琲王2」取扱説明書では、同製品のドリッパーを柔らかいスポンジと中性洗剤で洗うよう案内しています。

硬いたわしでこすったり、食洗機に入れたりする前に、お使いの器具が対応しているか確かめましょう。

ミルは、水洗いできる部品を確かめてから掃除する

ミルの粉受けを空にしたら、刃の周りや粉の出口に粉が残っていないか見ます。電動ミルを掃除するときは、電源を切ってプラグを抜いてから始めてください。刃に指を入れず、ブラシが届く範囲の粉を払います。

カリタのミルに関する案内では、多くの機種でカッターを水洗いせず、ホッパーや粉受けに残った粉を乾いた刷毛で払うよう説明しています。

シロカの対象機種でも、ミルには付属ブラシを使います。Baratzaの手入れ案内では、刃の周りをブラシで掃除し、取り外したホッパーと粉受けを洗って十分に乾かす手順を紹介しています。

ミルは、部品ごとに水洗いできるか確かめてから掃除しましょう。分解できる範囲や部品を戻す向きは、機種によって異なります。粉が奥に残っていても、説明書にないところまで分解せず、記載された手順に沿って掃除してください。

汚れが落ちないときは、器具に合った方法を確かめる

普段どおりに洗っても落ちない汚れは、器具の材質に合った方法で手入れします。メリタのお手入れ解説では、ステンレスポットに付くコーヒーの着色汚れと、ガラスポットに付く水垢を分けて説明しています。

使える洗浄剤は材質や部品によって異なります。お使いの器具の説明書で確認してください。

食洗機で洗える？

食洗機で洗えるかどうかは、製品ごとに異なります。HARIOの「V60 珈琲王2」には、食洗機で洗える部品があります。

シロカの対象機種は食洗機に対応していません。ドリッパーやサーバー、ふたなど、部品ごとに説明書を確認してください。

ミルはどのくらいの頻度で掃除する？

掃除の頻度はミルによって異なります。使うたびに粉が残っていないか見ておきましょう。

定期的な掃除の頻度は、取扱説明書で確認してください。ツインバードのCM-D457の案内では、同機種のミルを1週間に一度掃除し、豆の種類を変えるときにも手入れするよう勧めています。この頻度はCM-D457の場合です。

製品ごとの洗い方を知っておくと、使った後も迷わず片付けられます。ミルを選ぶ際に掃除のしやすさも確かめたい方は、ミルの選び方をご覧ください。ドリップの手順は、ドリップコーヒーの基本で紹介しています。