https://blog.keyuki.net/tags/github/ Recent content in GitHub on Keyuki Blog Hugo en Sat, 09 May 2026 10:46:38 +0900 https://blog.keyuki.net/posts/hugo-blog-image-management-cloudflare-r2/ Sat, 09 May 2026 10:46:38 +0900 https://blog.keyuki.net/posts/hugo-blog-image-management-cloudflare-r2/ <h2 id="最初は画像もリポジトリに入れればいいと思っていた">最初は画像もリポジトリに入れればいいと思っていた</h2> <p>HugoはMarkdownと画像をまとめてGitHubで管理できるのが強みのひとつです。記事ごとにフォルダを作り、その中に <code>index.md</code> と画像をまとめて置く「Page Bundle」という構成が使えるので、記事と素材の対応が分かりやすくなっています。</p> <pre tabindex="0"><code>content/posts/ 2026-05-01-my-article/ index.md cover.webp diagram.png </code></pre><p>この構成は直感的で、最初はこれで十分だと思っていました。</p> <p>ところが記事が増えていくにつれて、アイキャッチ画像・サムネイル・OGP画像を毎回用意するようになります。1記事あたり3〜5枚の画像が増えていくと、リポジトリのサイズがじわじわ膨らんでいくのではないかという、不安に駆られました。まだ、ほとんど記事書いてないですけど。Markdownファイル本体は数KBなのに、画像だけで数MBという状況はよくないのでは？と思うようになりました。</p> <h2 id="githubリポジトリが重くなるのが気になった">GitHubリポジトリが重くなるのが気になった</h2> <p>Gitはテキストファイルの差分管理が得意なツールです。しかしバイナリファイル（画像・動画など）は差分を持たず、変更のたびにファイル全体が履歴として積み上がります。</p> <p>たとえばアイキャッチ画像を差し替えると、古い画像も新しい画像もGitの履歴に残ります。<code>git clone</code> するたびにその全履歴を取得することになるので、リポジトリが年単位で成長すると無視できないサイズになります。</p> <p>CI/CDやCloudflare Pagesのビルドも同様で、ビルドのたびにリポジトリ全体をチェックアウトします。画像が増えれば増えるほど、ビルド時間に影響する可能性があります。</p> <p>「ブログ本文の変更履歴」と「画像アセットの保管場所」は、そもそも性質が違います。そう気づいてから、分けて管理したほうがすっきりすると思いました。</p> <h2 id="cloudflare-r2を画像置き場にした">Cloudflare R2を画像置き場にした</h2> <p><a href="https://www.cloudflare.com/developer-platform/r2/">Cloudflare R2</a>はCloudflareが提供するオブジェクトストレージです。Amazon S3と互換性のあるAPIを持ちつつ、<strong>エグレス料金（データ転送料）がかからない</strong>のが特徴で、個人ブログの画像配信には手頃な選択肢です。</p> <p>無料枠は、ストレージ10GB・Class Aオペレーション（書き込み）100万回/月・Class Bオペレーション（読み込み）1000万回/月となっています。個人ブログで画像を置く用途であれば、まずストレージが上限に達することはありません。読み込み回数についても、1000万回というのは1日あたり約33万リクエストに相当します。そもそも個人ブログにそれだけのPVがあれば、もうブログで飯が食えています。このブログには当然そんなPVはないので、無料枠で一生やっていける気がしています。</p> <p>このブログはCloudflare Pagesで配信しているので、Cloudflare側に画像も寄せると運用がまとまりやすくなります。R2バケットにカスタムドメインを設定することで、画像URLを <code>https://images.keyuki.net/...</code> という形で統一できます。</p> <p>記事のフロントマターには画像URLだけを書きます。画像本体はリポジトリに存在しません。</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-yaml" data-lang="yaml"><span style="display:flex;"><span><span style="color:#f92672">featured_image</span>: <span style="color:#ae81ff">https://images.keyuki.net/uploads/2026/05/sample-eyecatch.webp</span> </span></span><span style="display:flex;"><span><span style="color:#f92672">thumbnail_image</span>: <span style="color:#ae81ff">https://images.keyuki.net/uploads/2026/05/sample-thumb.webp</span> </span></span><span style="display:flex;"><span><span style="color:#f92672">images</span>: </span></span><span style="display:flex;"><span> - <span style="color:#ae81ff">https://images.keyuki.net/uploads/2026/05/sample-og.jpg</span> </span></span></code></pre></div><h2 id="hugo側ではurlを参照するだけにした">Hugo側ではURLを参照するだけにした</h2> <p>移行後のリポジトリには、記事本文・テンプレート・CSS・設定ファイルだけが残ります。画像本体はR2に置き、Hugoはそこへのパスを参照するだけになりました。</p> <p>フロントマターで使っているフィールドの役割も整理しています。</p> <ul> <li><code>featured_image</code>: 記事ページのメインビジュアル</li> <li><code>thumbnail_image</code>: 記事一覧のカードに表示するサムネイル</li> <li><code>images</code>: SNSシェア時のOGP画像（TwitterカードやOGタグで使用）</li> </ul> <p>この分担は<a href="https://blog.keyuki.net/posts/pagespeed-blog-image-optimization/">前の記事で書いたPageSpeed改善の取り組み</a>とも関連しています。</p> <p>少し管理は面倒になりましたが、快適にサイトが見れるようにやっていくには、これがいいと今のところ思ってます。</p> <h2 id="よかったこと">よかったこと</h2> <p>リポジトリを軽く保てるのが一番の効果でした。</p> <ul> <li>画像を差し替えてもGit履歴に古いファイルが積み上がりません。R2上で上書きすれば終わりです。</li> <li>アイキャッチ・サムネイル・OGPと用途別の画像を整理して置きやすくなりました。</li> </ul> <h2 id="気をつけること">気をつけること</h2> <p>移行してよかった一方で、いくつか注意点もあります。</p> <p><strong>R2側のURL設計が後から変えにくい。</strong> 記事から参照しているURLを変えると、過去記事の画像が壊れます。最初からディレクトリ構造とファイル命名規則を決めておく必要があります。</p> <p><strong>画像を消すと記事の表示が壊れる。</strong> GitHubのように「削除もバージョン管理する」という感覚はR2にはありません。不要になった画像でも、参照している記事がないか確認してから消す必要があります。</p> <p><strong>GitHubだけ見ても画像の実体がわからない。</strong> リポジトリを見ても画像は見えません。バックアップや棚卸しは別途R2側で行う必要があります。</p> <p><strong>キャッシュと公開設定に注意する。</strong> R2バケットのパブリックアクセス設定やCloudflareのキャッシュ設定を間違えると、画像が表示されなかったりキャッシュが意図せず残ったりします。</p> <p>「R2に置けば解決」ではなく、運用ルールをセットで決めることが大事だと感じました。</p> <h2 id="今の運用ルール">今の運用ルール</h2> <p>実際にやっていることをまとめると、こんな感じです。</p> <p><strong>ディレクトリ構成</strong>: 年月で分けています。</p> <pre tabindex="0"><code>uploads/ 2026/ 05/ article-slug-eyecatch.webp article-slug-thumb.webp article-slug-og.jpg </code></pre><p><strong>ファイル命名規則</strong>: 記事のslugをベースに、用途をsuffixで区別します。</p>