Amazon S3からCloudflare R2への移行

2026-05-22T00:00:00+00:00
以前「ブログをZolaに移行、AWSの後始末</a>」で、Next.js + Amplify構成のブログをZolaへ移し、Amplifyを含む大半のAWSリソースを削除しました。ただ、そのとき1つだけ削除せずに残したものがあります。有償のWEBフォントを配信するためのS3バケットとCloudFrontです。
本記事では、この最後のAWSリソースをCloudflare R2へ移した記録をまとめます。題材はフォント1つですが、個人ブログのスタティックなリソースをS3とR2のどちらに置くか、という選択の話でもあります。
移行前の構成</h2>
配信していたのは有償のWEBフォントです。このフォントはライセンス上、誰でもwoff2ファイルをダウンロードできる状態にしておくわけにはいきません。一方でWEBフォントである以上、ブラウザからは取得できる必要があります。この相反する要件を、移行前はAWS側で次のように満たしていました 1</a>。
woff2ファイルをS3バケットに保管し、その前段のCloudFrontから配信</li>
CloudFront FunctionでリクエストのRefererヘッダを検査し、ブログのドメイン以外からのアクセスを遮断</li>
S3バケットポリシーにも同じReferer条件を設定し、CloudFrontを経由しないS3への直接アクセスも遮断</li>
フォントがCloudFrontのドメイン(ブログとは別オリジン)から読み込まれるため、S3側のCORS設定でブログのドメインからの要求のみを許可</li> </ul>
ブログのCSSでは、すべての @font-face</code> がこのCloudFrontのURLを参照していました。
Cloudflare R2 への移行</h2>
ブログのワークロードは、すでにCloudflareに移っていました。ホスティングはCloudflare Workersの静的アセット配信で動いており、フォントだけをAWSに残しておく理由は薄くなっていました。配信元をS3 + CloudFrontからCloudflare R2に移すと、次のメリットがあります。</p>

AWSとCloudflareに分かれていたインフラの一本化</li>
Referer制限のための仕組み(CloudFront Function・バケットポリシーの条件・CORS)の全廃</li>
フォントの同一オリジン配信化(別オリジンへの preconnect</code> やCSP調整が不要)</li>
R2のストレージ無料枠(10GB)に収まる配信コスト</li>
</ul>
特に大きいのは2番目です。R2バケットは、公開設定を有効にしない限り外部から到達できるURLを持たず、フォントへのアクセス手段はWorkerからのR2 Bindingだけになります。S3 + CloudFrontでは、公開バケットへのアクセスをReferer条件で絞り込む必要がありました。R2では公開URLがそもそも存在しないため、アクセス元を判定する仕組み自体が要らなくなります。守るための要素が減ることは、設定ミスの余地が減ることでもあります。</p>
移行後の保護モデル</h2>
新しい構成では、フォントの保護を4つのレイヤーで担保しています。</p>
#</th> レイヤー</th> 設定の実体</th> 防ぐ脅威</th></tr></thead>

1</td> バケット非公開</td> r2.dev 無効・カスタムドメイン未割当・CORS なし</td> バケット URL の直接スクレイプ、検索エンジンの索引</td></tr>
2</td> R2 Binding 経由のみ</td> [[r2_buckets]]</code> 宣言により同一 Cloudflare アカウント内に限定</td> 他アカウントや外部ネットワークからの参照</td></tr>
3</td> Worker が公開面を制限</td> /fonts/<file></code> パスのみを公開し、不正なキーは弾く</td> パストラバーサル、任意キーの READ、バケット列挙</td></tr>
4</td> 長寿命クレデンシャル不在</td> R2 API トークンを発行しない</td> コミットや CI ログ経由のトークン漏洩</td></tr>
</tbody></table>
設計の本質は、ライセンス違反が最も起きやすい経路、つまり公開バケットのURLがクローラに拾われて検索結果に載ることを消す点にあります。閲覧者がDevToolsからフォントを保存する行為や、第三者サイトからのホットリンクは別レイヤーの問題で、WEBフォント配信の仕組み上、完全には防げません。必要ならWorkerにReferer許可リストを足すこともできますが、今回は入れていません。私が利用しているフォントのライセンスでは、ライセンシーのドメインから配信することが求められていて、リクエスト元の検査までは要件になっていないためです。ただし、これはフォントごとに異なります。CORSやドメイン制限を技術的保護措置としてEULAで義務づけているフォントもあるので、利用するフォントのライセンスは必ず確認してください。</p>
Worker と R2 の構成</h2>
実装は驚くほど小さく収まりました。まずR2バケットを作成します(ここでは web-fonts</code> という名前にします)。公開設定は無効のままにし、S3と同じキー名でwoff2をアップロードします。あとはWorkerからbindingでつなぐだけです。</p>
wrangler.toml</code> にR2バケットのbindingを宣言します。</p>
name</span> =</span> "blog"</span></span>
main</span> =</span> "src/index.js"</span></span>
compatibility_date</span> =</span> "2026-02-17"</span></span>
</span>
[</span>assets</span>]</span></span>
directory</span> =</span> "./public"</span></span>
binding</span> =</span> "ASSETS"</span></span>
</span>
[[</span>r2_buckets</span>]]</span></span>
binding</span> =</span> "FONTS"</span></span>
bucket_name</span> =</span> "web-fonts"</span></span></code></pre>
Worker本体は、/fonts/</code> で始まるリクエストをR2に取り次ぎ、それ以外は静的アセットに渡すだけです。</p>
const</span> FONTS_PREFIX</span> =</span> "/fonts/"</span>;</span></span>
</span>
export default</span> {</span></span>
  async</span> fetch</span>(</span>req</span>,</span> env</span>) {</span></span>
    const</span> url</span> =</span> new</span> URL</span>(req</span>.</span>url)</span>;</span></span>
</span>
    if</span> (url</span>.</span>pathname</span>.</span>startsWith</span>(FONTS_PREFIX))</span> {</span></span>
      const</span> key</span> =</span> decodeURIComponent</span>(url</span>.</span>pathname</span>.</span>slice</span>(</span>FONTS_PREFIX</span>.</span>length))</span>;</span></span>
      // Only flat keys in R2 (no subdir, no traversal). Anything else falls</span></span>
      // through to static assets — the theme also publishes under /fonts/.</span></span>
      if</span> (</span>key</span> && !</span>key</span>.</span>includes</span>(</span>".."</span>)</span> && !</span>key</span>.</span>includes</span>(</span>"/"</span>))</span> {</span></span>
        const</span> obj</span> =</span> await</span> env</span>.</span>FONTS</span>.</span>get</span>(</span>key</span>)</span>;</span></span>
        if</span> (</span>obj</span>)</span> {</span></span>
          const</span> headers</span> =</span> new</span> Headers</span>()</span>;</span></span>
          obj</span>.</span>writeHttpMetadata</span>(</span>headers</span>)</span>;</span></span>
          headers</span>.</span>set</span>(</span>"Content-Type"</span>,</span> "font/woff2"</span>)</span>;</span></span>
          headers</span>.</span>set</span>(</span>"Cache-Control"</span>,</span> "public, max-age=31536000, immutable"</span>)</span>;</span></span>
          headers</span>.</span>set</span>(</span>"ETag"</span>,</span> obj</span>.</span>httpEtag)</span>;</span></span>
          return</span> new</span> Response</span>(obj</span>.</span>body</span>, {</span> headers</span> }</span>)</span>;</span></span>
        }</span></span>
      }</span></span>
    }</span></span>
</span>
    return</span> env</span>.</span>ASSETS</span>.</span>fetch</span>(</span>req</span>)</span>;</span></span>
  },</span></span>
};</span></span></code></pre>
最後にCSSの参照先を書き換えます。@font-face</code> の src</code> は、これまでCloudFrontの絶対URLを指していましたが、同一オリジンの相対パス /fonts/</code> に変わります。</p>
@font-face</span> {</span></span>
  font-family</span>:</span> "WebFont"</span>;</span></span>
  src</span>:</span> url</span>(</span>"/fonts/WebFont-Regular.woff2"</span>)</span></span>
    format</span>(</span>"woff2"</span>);</span></span>
  font-display</span>:</span> swap</span>;</span></span>
  font-weight</span>:</span> 400</span>;</span></span>
  font-style</span>:</span> normal</span>;</span></span>
}</span></span></code></pre>
CSS内のすべての @font-face</code> で、CloudFrontの絶対URLを /fonts/</code> で始まる相対パスに置き換えます。デプロイはmainへのpushでGitHub Actionsが wrangler deploy</code> を実行する流れに乗せます。</p>
つまずいた点</h2>
デプロイ用のAPIトークンの権限不足でつまずきました。GitHub Actionsが使う CLOUDFLARE_API_TOKEN</code> は旧構成(静的アセット配信のみ)のときに発行したもので、Workers Scriptsの編集権限しかありませんでした。R2 bindingを含むWorkerを wrangler deploy</code> すると、宣言したバケットの存在確認でR2のAPIを呼び出すため、初回のpushは code: 10000 Authentication error</code> で失敗しました。</p>
幸い、Cloudflare Workersのデプロイは原子的です。失敗時は旧Workerが稼働し続けるため、復旧作業中もサイトは旧CloudFront経由でフォントを配信し続け、見た目は保たれていました。</p>
対応として、APIトークンにAccountスコープの Workers R2 Storage: Edit</code> を追加しました。最終的に付与した権限セットは次のとおりです。</p>
スコープ</th> パーミッション</th> 用途</th></tr></thead>

Account</td> Workers Scripts: Edit</td> Worker スクリプトのデプロイ</td></tr>
Account</td> Workers R2 Storage: Edit</td> R2 binding 宣言時のバケット存在確認</td></tr>
Account</td> Account Settings: Read</td> アカウント情報の照会</td></tr>
Zone</td> Workers Routes: Edit</td> カスタムルートの設定</td></tr>
User</td> Memberships: Read</td> /memberships</code> API の呼び出し</td></tr>
User</td> User Details: Read</td> wrangler whoami</code> 相当の照会</td></tr>
</tbody></table>
Cloudflare公式の「Edit Cloudflare Workers」テンプレートにはR2の権限が含まれていません。新しいbinding(R2 / D1 / KV / Queuesなど)をWorkerに足すときは、デプロイ前にCIトークンの権限を見直すのが安全です。トークンを差し替えたあとは、失敗したジョブだけを再実行しました。</p>
DEPLOY_ID</span>=</span>$(</span>gh</span> run list --branch main</span> \</span></span>
  --workflow="<デプロイ用ワークフロー名>" --limit</span> 1</span> \</span></span>
  --json databaseId --jq '.[0].databaseId'</span>)</span></span>
gh</span> run rerun "</span>$DEPLOY_ID</span>" --failed</span></span></code></pre>AWS リソースの撤去</h2>
R2配信が本番で安定したことを確認してから、AWS側を停止しました。撤去対象はCloudFrontディストリビューション、CloudFront Function、S3バケットの3つです。ディストリビューションIDは aws cloudfront list-distributions</code>、バケット名は aws s3 ls</code> で確認できます。以降のコマンドでは、それぞれの識別子を変数に入れてあるものとします。</p>
DIST_ID</span>=</span>"<対象ディストリビューションのID>"</span></span>
FUNCTION_NAME</span>=</span>"<Referer を検査していた CloudFront Function 名>"</span></span>
BUCKET</span>=</span>"<フォントを置いていた S3 バケット名>"</span></span></code></pre>
CloudFrontディストリビューションは、いきなり削除できません。先に Enabled = false</code> で無効化し、設定が全エッジに伝播するのを待ってから削除します。</p>
aws</span> cloudfront get-distribution-config --id "</span>$DIST_ID</span>"</span> \</span></span>
  ></span> /tmp/dist-config.json</span></span>
jq</span> -r '.ETag' /tmp/dist-config.json</span> ></span> /tmp/dist-etag.txt</span></span>
jq</span> '.DistributionConfig | .Enabled = false' /tmp/dist-config.json</span> \</span></span>
  ></span> /tmp/dist-config-disabled.json</span></span>
aws</span> cloudfront update-distribution --id "</span>$DIST_ID</span>"</span> \</span></span>
  --if-match "</span>$(</span>cat</span> /tmp/dist-etag.txt</span>)</span>"</span> \</span></span>
  --distribution-config "file:///tmp/dist-config-disabled.json"</span></span></code></pre>
update-distribution</code> は Status: InProgress</code> を返します。Status: Deployed</code> に戻るまで伝播を待ちます(実測で約3分)。</p>
until</span> [</span> "</span>$(</span>aws</span> cloudfront get-distribution --id "</span>$DIST_ID</span>"</span> \</span></span>
  --query 'Distribution.Status' --output text</span>)</span>"</span> =</span> "Deployed"</span> ];</span> do</span></span>
  sleep</span> 30</span></span>
done</span></span></code></pre>
Deployed</code> に戻ったら削除します。</p>
ETAG</span>=</span>$(</span>aws</span> cloudfront get-distribution --id "</span>$DIST_ID</span>"</span> \</span></span>
  --query 'ETag' --output text</span>)</span></span>
aws</span> cloudfront delete-distribution --id "</span>$DIST_ID</span>" --if-match "</span>$ETAG</span>"</span></span></code></pre>
CloudFront Functionの削除では、describe-function</code> で取得した現在のETagを delete-function</code> に渡します。注意点として、FunctionはDEVELOPMENTとLIVEの2つのステージを持ち、両者を別々に更新しているとETagが食い違います。私の環境ではDEVELOPMENT側が新しく、describe-function --stage DEVELOPMENT</code> で取ったETagでなければ PreconditionFailed</code> になりました。</p>
ETAG</span>=</span>$(</span>aws</span> cloudfront describe-function --name "</span>$FUNCTION_NAME</span>"</span> \</span></span>
  --stage DEVELOPMENT --query 'ETag' --output text</span>)</span></span>
aws</span> cloudfront delete-function --name "</span>$FUNCTION_NAME</span>" --if-match "</span>$ETAG</span>"</span></span></code></pre>
最後にS3バケットを空にして削除します。</p>
aws</span> s3 rm "s3://</span>$BUCKET</span>" --recursive</span></span>
aws</span> s3api delete-bucket --bucket "</span>$BUCKET</span>"</span></span></code></pre>
ACM証明書は、CloudFrontのデフォルトドメイン(*.cloudfront.net</code>)のまま運用していて発行していなかったため、削除対象はありませんでした。これでフォント配信に関わるAWSリソースはすべて無くなり、配信はR2経由に一本化されました。</p>
移行して変わったこと</h2>
移行の前後で、AWS側にあったCloudFrontディストリビューション、CloudFront Function、S3バケット、バケットポリシー、CORS設定がすべて消えました。残ったのはR2バケット1つと、ごく短いWorkerスクリプト1つです。</p>
今回移したのはフォント一式というごく小さなリソースで、Cloudflareの無料枠の範囲で十分にまかなえています。コスト面より、管理対象のサービス数が減ったことのほうが効きます。フォント1種類のためにCloudFrontとS3とFunctionの3サービスを横断して設定を追っていた状態から、Cloudflareのダッシュボード内で完結する状態になりました。</p>
今回はフォントが題材でしたが、結論はもっと一般的だと考えています。個人ブログのスタティックなリソースの置き場所としては、Amazon S3 + CloudFrontよりもCloudflare R2のほうが向いています。R2なら公開URLを持たせずにWorkerから読め、S3のように公開バケットを設定で囲い込む手間がいりません。ホスティングがCloudflareにあれば置き場も同じプラットフォームにまとまり、費用も無料枠と転送料無料で個人規模なら気になりません。</p>
S3が劣るという話ではありません。ただ、個人ブログの規模で、すでにCloudflareを使っているなら、スタティックなリソースはR2に置くのが素直な選択だと思います。</p>



より確実な構成にするなら、S3バケットを非公開にしてOAC(Origin Access Control)経由でのみ読ませる方法もありました。ただしWEBフォントはページの一部としてブラウザに読み込まれる以上、閲覧者によるダウンロードまで完全に防ぐことはどのみちできません。完全な防御は不可能だという前提で、ある程度は妥協した構成でした。 ↩</a></p>
</li>
</ol>
</section>


無料で始める Cloudflare セキュリティ対策
2026-03-23T00:00:00+00:00


</span>公開翌日に何が起きたか</h2>
先日の記事で紹介した生成AIを使ったAsk</a> ページを公開した翌日、CloudflareのObservabilityを確認したところ、攻撃と思われるリクエストが並んでいました。</p>

GET /.env</code> — 環境変数ファイルの探索</li>
/checkout</code>, /plans</code>, /signup</code> — SaaS系パスの総当たり</li>
/wp-login</code>, /wp-admin</code>, /xmlrpc.php</code> — WordPress管理画面の探索</li>
/api/v1/stripe/config.js</code>, /api/v2/payment/keys.js</code> — 決済APIの設定ファイル探索（Stripeはオンライン決済プラットフォーム）</li>
config.php</code>, /api/system/info</code> — サーバー情報の収集</li>
</ul>
主にWordPressなどのCMSやStripeなどの決済サービスを狙ったスキャンです。静的サイト＋Workerという構成なのでそんなサービスは乗せていないのですが。公開されているエンドポイントに対してよく狙われる既知のパスを片っ端から叩いているのでしょう。</p>
実害はありませんが、放置するのも気持ちが悪いですし、Workers AIのNeuronsを無駄に消費されるのは避けたいところです。Cloudflareの無料プランのセキュリティ機能で対策しました。</p>
対策1: Bot Fight Mode</h2>
最も手軽な対策です。Cloudflareダッシュボードの Security > Bots</strong> から、ワンクリックで有効化できます。</p>
Bot Fight ModeはCloudflareが持つボットの行動パターンデータベースを使い、自動化されたアクセスを検出して計算コストの高いチャレンジを返します。検索エンジンのクローラーなど検証済みの正当なボットは通過させる仕組みです。</p>
設定はON/OFFだけで、細かなチューニングは有料プラン（Super Bot Fight Mode）の機能になります。それでも、汎用的なスキャンボットの大半はこれで弾けます。</p>
注意点として、Bot Fight Modeは外部サービスからのWebhookやRSSリーダーのフィード取得など、正当な自動アクセスもブロックする場合があります。無料プランではWAFルールによるバイパス（Skip）ができないため、これらのサービスに影響が出た場合はBot Fight Mode自体を無効にする必要があります。</p>
対策2: WAF カスタムルール</h2>
Bot Fight Modeをすり抜けるアクセスに対しては、WAF（Web Application Firewall）のカスタムルールで対処します。無料プランでは5つまでルールを作成できます。</p>
ルール1: 許可パスの制限（ホワイトリスト）</h3>
最も効果が高いルールを最優先に配置します。ask.codedchords.devは /</code>（フロントエンド）と /api/</code>（Workers API）しか使わないので、それ以外を全てブロックします。</p>
(http.host eq "ask.codedchords.dev")</span></span>
and not (http.request.uri.path eq "/" or http.request.uri.path contains "/api/")</span></span></code></pre>
Actionは Block</strong>、Place atは First</strong> に設定します。</p>
「正当なパスだけを許可する」ホワイトリスト方式なので、攻撃者がどんなパスを試してもすり抜けられません。ただし、対象サイトの構成を把握している必要があります。新しいパスを追加した際にルールの更新を忘れると自分自身のコンテンツがブロックされるため、サイト構成を変更したらルールも見直してください。</p>
ルール2: スキャンパスの遮断（ブラックリスト）</h3>
ルール1はaskサブドメイン限定なので、ドメイン全体に適用する汎用ルールも設定します。WordPressやphpMyAdminなど、よく狙われるパスへのアクセスを一括でブロックします。</p>
Security > Security rules > Create rule</strong> から、以下のExpressionを設定します。</p>
(http.request.uri.path contains ".env")</span></span>
or (http.request.uri.path contains "wp-login")</span></span>
or (http.request.uri.path contains "wp-admin")</span></span>
or (http.request.uri.path contains "xmlrpc.php")</span></span>
or (http.request.uri.path contains "phpmyadmin")</span></span>
or (http.request.uri.path contains "wp-content")</span></span>
or (http.request.uri.path contains "wp-includes")</span></span></code></pre>
Actionは Block</strong> です。</p>
このルールはサイトの構成に依存しないため、Cloudflareで管理しているドメイン全体に適用できます。WordPressを使っていないサイトであれば、デメリットはありません。</p>
対策3: Rate Limiting</h2>
Bot Fight ModeとWAFルールを通過したリクエストに対する最後の砦です。同一IPからの過剰なリクエストを制限します。</p>
Security > Security rules > Rate limiting rules</strong> から設定します。</p>
項目</th> 設定値</th></tr></thead>

対象</td> http.host eq "ask.codedchords.dev"</code></td></tr>
判定基準</td> IP</td></tr>
レート</td> 10リクエスト / 10秒</td></tr>
Action</td> Block（10秒間）</td></tr>
</tbody></table>
無料プランではRate Limitingルールは1つまで、ブロック期間は最大10秒という制約があります。大規模な攻撃には有料プランのRate Limiting（より長いブロック期間、より多くのルール）が必要ですが、スキャンボット対策としては十分です。上記の設定値は一例です。ページ内のリソース数や想定されるアクセスパターンに応じて調整してください。</p>
なお、今回はWorkers側にも /api/ask</code> エンドポイントに対して同一IP 60秒間10リクエストの制限を入れています。CloudflareのRate Limitingはインフラ層での粗いフィルタリング、Workers側はアプリケーション層での細かな制御という役割分担です。</p>
3層防御の全体像</h2>
設定した対策を整理します。</p>
レイヤー</th> 対策</th> 役割</th></tr></thead>

第1層</td> Bot Fight Mode</td> 既知のボットパターンを自動検出</td></tr>
第2層</td> WAF カスタムルール</td> 不正なパス・不要なパスを遮断</td></tr>
第3層</td> Rate Limiting</td> 過剰なリクエストを制限</td></tr>
</tbody></table>
いずれもCloudflareの無料プランで利用でき、設定はダッシュボードからの操作だけで完結します。</p>
まとめ</h2>
これらの設定を適用した直後から、Observability上でスキャン系のリクエストがブロックされていることを確認できました。Workers AIのNeuronsが無駄に消費されることもなくなっています。</p>
個人サイトであっても、公開すればスキャンボットは来ます。「小規模だから狙われない」ということはありません。ボットは規模を問わず、見つけたエンドポイントを片っ端から叩きます。</p>
Cloudflareを使っているなら、無料プランの範囲でもBot Fight Mode、WAFカスタムルール、Rate Limitingの3つを設定するだけで、大半の自動化されたスキャンは防げます。設定にかかる時間は10分程度です。特にWorkers AIやAPIエンドポイントを公開している場合は、不要なリクエストによるリソース消費を防ぐためにも早めの対策をおすすめします。</p>
References</h2>


    
Cloudflare</a>. "Bot Fight Mode"</li>
Cloudflare</a>. "Custom rules"</li>
Cloudflare</a>. "Rate limiting rules"</li>
</ul>

</div>



Cloudflare Workers AI + Vectorize で RAG
2026-03-20T00:00:01+09:00



Table of Contents</summary>

</details>
</span>何を作ったのか</h2>
このブログのナビゲーションに「ask」というメニューを追加しました。
私のデジタル分身(bot)に質問できるページが表示されます。質問を入力すると、ブログ記事の内容を踏まえて私っぽい回答を返します。</p>
ブログに書いてある話題はもちろん、書いていない話題についても「私ならこう答えるだろう」という推測で回答を生成します。
ただし、たかだか個人ブログの文書量ですから大した学習量ではないため、平気で嘘をつきます。それも含めて楽しんでもらえればと思います。</p>
たとえば、こんな質問を投げてみます。</p>


    </div>
    
        Q&A の例</strong>
        Q:</strong> CIOも設置せず、IT Governanceの取り組みを行なわない理事長が「生成AIを導入したい」と言っています。どうすべきですか？</p>
A:</strong> その理事長に、生成AIの導入が「新しいシステムの導入」と違うことを説明する必要があります。生成AIは、組織の判断の中枢に組み込まれ、自社固有の文脈で動く必要があります。そのためには、IT部門だけでなく、業務部門の理解と協力が必要です。
また、生成AIの導入には、データの整備、セキュリティの確保、コンプライアンスの確保などの準備が必要です。CIOを設置せず、IT Governanceの取り組みを行なわない組織では、これらの準備を十分に整えることが難しいでしょう。（以下、省略）</p>

    </div>
</div>

私が答えそうな回答を返してきました。ブログ記事の内容をベースにしつつ、ペルソナの設定に基づいた回答を生成しています。</p>
ソースコードはGitHubで公開しています。</p>

</iframe>

動機</h2>
仕事を終えて職場を変えることになったとき、同僚が「質問できなくなるので、あなたのbotがあればいいのに」と言ってくれました。ありがたい話です。真に受けました。</p>
もう1つの動機は、せっかくブログをCloudflare Pagesに移行したのでWorkers AIも試してみようという技術的な興味です。Workers AI、Vectorize、Workersを組み合わせたRAGシステムを自分で組んでみたかったですし、構築過程がそのままブログのネタになるのも都合が良いと思いました。</p>
アーキテクチャ</h2>
処理フローはシンプルなRAGパターンです。</p>
まず事前処理として、ブログ記事をVectorizeに投入しておきます。</p>
Coded Chords - Cloudflare

Amazon S3からCloudflare R2への移行

無料で始める Cloudflare セキュリティ対策

Cloudflare Workers AI + Vectorize で RAG
