Coded Chords - Security

CloudflareのAI対策見直しとAIエージェント対応度診断

2026-07-08T00:00:00+00:00

Table of Contents</summary> </details>

2026年2月、Cloudflareへ移転した際の記事</a>で、AI学習クローラー対策としてContent Signals Policy、Block AI bots、AI Labyrinthという3層構成を紹介しました。あれから4か月、AIによるアクセスの重要性はさらに増しています。改めてこのブログのCloudflare設定を見直すとともに、Cloudflareが新しく公開したAgent Readinessスキャナーで「AIエージェントへの対応度」を診断してみました。</p>

Managed robots.txtまわりを再確認する</h2>

まず、AI Crawl Controlのダッシュボードを一通り確認しました。</p>

Block AI training botsは「Block on all pages」のままで変更していません。このブログのコンテンツはCC BY-NC-ND 4.0(非営利・改変禁止)で公開しているので、商用LLMの学習データとして使われることは元々ライセンスの意図と衝突します。学習目的のクローラーは全ページで拒否するのが一貫した方針です。</p>

Content Signalsでは、Managed robots.txtをオンにしています。</p>

AI Crawl ControlのCrawlers一覧では、クローラーごとの許可/ブロックを個別に確認しました。</p>

カテゴリ</th> 例</th> 設定</th></tr></thead>

AI Crawler(学習用)</td> GPTBot、ClaudeBot、Bytespider、Amazonbot、TikTok Spider、Meta-ExternalAgent</td> Block</td></tr>

AI Search / AI Assistant</td> Applebot、PerplexityBot、ChatGPT-User</td> Allow</td></tr>

Search Engine Crawler</td>

Googlebot、BingBot</td>

Allow</td></tr> </tbody></table>

Crawlers一覧の分類も、学習目的のクローラーを拒否するという方針のとおりでした。あわせてAI Labyrinth(クロールルールを無視するボットに偽コンテンツを読ませるハニーポット機能、Beta)も確認しましたが、2月から変わらずONのままでした。</p>

「混在クローラー」という新しい論点</h2>

今回の見直しで、2月時点にはなかった変化に気づきました。レガシー機能「Block AI bots」の設定画面に、次のような予告が表示されていたのです。</p>

On September 15, mixed-purpose crawlers that are used both for search indexing and for training AI will be included in blocking AI training.</p> </blockquote>
ここで言う混在クローラーとは、前段のCrawlers一覧でSearch Engine CrawlerやAI Searchに分類し、学習とは無関係としてAllowにしていたGooglebot、Applebot、BingBotのことです。検索とAI学習を1回のクロールで同時に行うため両者を切り分けられず、学習ブロックを選んでいるサイトでは最も制限の強いルールを適用する、というのが実質的な立場だと考えられます。そのままでは検索エンジン経由の流入もAI検索・AIアシスタント経由の露出も失うため、「Mixed purpose crawlers will continue to be allowed」を選び、混在クローラーは引き続き許可する設定にしました。</p>
レガシー機能は9月15日に廃止され、後継の「Configure AI bot policies」に一本化されます。こちらはボットを3種類に分類し、それぞれ個別にAllow/Blockを選べる形になっていました。</p>
分類</th> 説明</th> 設定</th></tr></thead>
Search</td> 検索エンジンのインデックス用ボット</td> Allow(Recommended)</td></tr>
Agent</td> ユーザーの質問への回答生成のために参照するボット</td> Allow(Recommended)</td></tr>
Training</td>
AI学習用にコンテンツをスクレイピングするボット</td>
Block(Recommended値はBlock on pages with ads)</td></tr> </tbody></table>
Trainingだけ、広告のないこのブログの事情に合わせて推奨値の「Block on pages with ads」から「Block」に変更しました。</p>
AIエージェント対応度を診断してみた</h2>
Cloudflareはisitagentready.com</a>という無料の診断ツールを公開しています。</p>
この診断ツールでは、サイトのAIエージェントへの対応度(Agent Readiness)を診断してくれます。</p>
このブログのURLでスキャンしたところ、次のようなものでした。</p>
当サイトのAgent Readiness</figcaption> </figure>
個人ブログサイトでは該当しない項目</h3>
改善項目として、10個の指摘を受けました。ただし、10個のうち6個はいずれも「稼働しているAPIやエージェントサービスがあること」を前提にした指摘でした。</p>
指摘</th> 規格</th> 該当しない理由</th></tr></thead>

DNS for AI Discovery (DNS-AID)</td> IETFドラフト、Linux Foundation 2026年発表</td> 他のAIエージェントから発見・接続されるエージェントサービス(チャットボット、MCPサーバー等)を運用していない</td></tr>
API Catalog</td> RFC 9727</td> カタログ化すべきAPIが存在しない</td></tr>
OAuth/OIDC discovery metadata</td> RFC 8414 等</td> 認証保護されたAPIや会員機能がない</td></tr>
OAuth Protected Resource Metadata</td> RFC 9728</td> 同上</td></tr>
auth.md</td> WorkOS提唱</td> OAuth Protected Resource Metadataを前提とする、同上の理由</td></tr>
MCP Server Card</td> SEP-1649(標準化進行中)</td> MCPサーバーを運用していない</td></tr> </tbody></table>
このブログは静的コンテンツを配信するだけのサイトで、APIやエージェント向けサービスは一切運用していません。この種の指摘は、SaaSやEC、API提供事業者向けのチェックリストとしては妥当ですが、個人ブログにはそもそも対象が存在しませんでした。</p>
対応した項目</h3>
「ホームページにLink response header(RFC 8288)がない」という指摘もありました。ツールの提案はrel="api-catalog"</code>やrel="service-doc"</code>でAPIカタログやAPI仕様書を指すというものでしたが、このブログにAPIはないので、この提案どおりに実装しても意味がありません。</p>
代わりに、Linkヘッダーの仕組み自体はこのブログでも使い道があると考え、次の2つを指すヘッダーを追加しました。</p>
/</span></span> Link: </license/>; rel="license", </atom.xml>; rel="alternate"; type="application/atom+xml"</span></span></code></pre> rel="license"</code>はIANA登録済みの正式なrelationで、CC BY-NC-ND 4.0を明記したライセンスページ(/license/</code>)をAIエージェントが機械的に検出できるようにします。学習ボットのブロックと合わせて、コンテンツの利用条件を多層的に伝える形になりました。rel="alternate"</code>はZolaが生成するAtomフィード(/atom.xml</code>)へのリンクで、フィードの発見性を高めます。</p> 対応を見送った項目</h3> 残る3個は、対応自体は可能でも今回は見送りました。</p> Markdown for Agentsは、Accept: text/markdown</code>のリクエストにHTMLの代わりにMarkdownを返す機能です。CloudflareのAI Crawl Control上では確認できましたが、Proプラン以上限定(2026年7月時点で月$20〜25)のため、Freeプランの現状ではロックされていました。個人ブログの一機能としてはコストに見合わないと判断し、見送りました。</p> WebMCPは、ブラウザ内蔵のAIエージェントにnavigator.modelContext.provideContext()</code>でサイトの操作(検索など)を直接公開する仕組みです。現状はEarly Preview Program参加者限定の実験段階で、一般のブラウザではまだ有効化されていません。このブログの操作対象もpagefindによる検索程度で薄く、標準化が進んだ段階で再検討することにしました。</p> Agent Skills discovery indexは、/.well-known/agent-skills/index.json</code>にサイト固有の作業手順(SKILL.md)を公開する仕組みです。コンテンツサイト向けの想定用途は「文章校正」「カテゴリ分類の提案」といった編集アシスタント業務で、これは既に自分のClaude Code環境でローカルに完結しています。v0.2.0のドラフト段階でエコシステムの普及状況も未検証なため、こちらも見送りとしました。</p> まとめ</h2> Agent Readinessスキャンの10個の指摘を並べてみると、その多くはAPIやSaaS、エージェント向けサービスを運用している事業者を想定したチェックリストだと分かりました。静的な個人ブログにとって本当に意味のある「AI対応」は、実は範囲が絞られます。当サイトでの結論は次のとおりです。</p> CC BY-NC-NDライセンスの意図に沿って、学習目的のクローラーは技術的にブロックする</li> robots.txtのContent Signalsとライセンスページへのrel="license"</code>で、利用条件を機械可読な形でも表明する</li> 検索エンジンやAI回答エンジンからの参照は妨げず、露出の機会は残す</li> WebMCPやAgent Skillsのようなドラフト段階の規格には、実際に普及するまで様子見の姿勢を崩さない</li> </ul> 2月の記事で組んだ多層防御の骨格は変わっていませんが、Cloudflare側の仕様変更(混在クローラーの扱い)に合わせて設定を追随させ、Agent Readinessという新しい物差しで一度棚卸しをしたことで、このブログのAI対応の現在地を再確認できました。</p> References</h2> Cloudflare</a>. "Giving users choice with Cloudflare's new Content Signals Policy"</li> Cloudflare</a>. "robots.txt setting"</li> Cloudflare</a>. "Your site, your rules: new AI traffic options for all customers"</li> Cloudflare</a>. "Introducing the Agent Readiness score"</li> Cloudflare</a>. "Pro Plan Overview"</li> IETF</a>. "DNS for AI Discovery"</li> DNS-AID</a>. "AI Agent Discovery via DNS"</li> IETF</a>. "RFC 9727: The api-catalog Well-Known URI and Link Relation Type"</li> IETF</a>. "RFC 8288: Web Linking"</li> WorkOS</a>. "auth.md — Open Protocol for Agent Registration"</li> Model Context Protocol</a>. "MCP Server Card (SEP-1649)"</li> Cloudflare</a>. "Agent Skills Discovery RFC"</li> Agent Skills</a>. "Agent Skills"</li> Chrome Developers</a>. "WebMCP Early Preview Program"</li> </ul> </div> メッセージングアプリの匿名性考察 2026-07-01T10:00:00+09:00 Table of Contents</summary> </details> Threema GmbH（以下、Threema社）の公式ブログに「システムレベルの匿名性についての記事</a>」という記事が投稿されました。</p> メッセージングアプリの匿名性について論じています。以前、市川の強盗傷害事件をきっかけに暗号化やメタデータで機能比較した記事</a>を書きましたが、匿名性という観点はなかったのでこの記事を参考に解説したいと思います。</p> メッセージングアプリの匿名性について</h2> Threema社の技術記事では、匿名性を二種類に分けています。</p> 水平的匿名性</dt> 会話の相手に対する匿名性です。ユーザー名だけで連絡先を交換できれば、相手は電話番号や本名を知りません。対等な利用者どうしの間で成り立ちます。</dd> 垂直的匿名性</dt> サービス運営者に対する匿名性です。登録時に電話番号やメールアドレスを渡していなければ、運営は身元を特定する手がかりを持ちません。利用者とサービスという上下の関係で成り立ちます。</dd> </dl> Threema社は、ユーザー名機能で水平的匿名性は広まったものの、プライバシー保護で本当に重要なのは垂直的匿名性であり、これはセキュリティにおけるエンドツーエンド暗号化に相当する基盤だと主張します。あくまで同社の枠組みですが、この二軸はアプリを見比べる土台として使えます。</p> 垂直的匿名性の重要性について</h2> なぜ運営に対する匿名性がそれほど問題になるのでしょうか。</p> メッセージングアプリでは、登録時に電話番号やメールアドレスを要求するものがあります。</p> ユーザー名で連絡先を交換できるサービスでも、相手にこうした個人情報を見せずに済むだけで、登録の段階では運営に渡しています。電話番号やメールアドレスは本人確認や他サービスの登録にも使われる、生活に密着した識別子です。運営がこれを保持していれば、別々の文脈で集めた情報を同一人物に結びつける手がかりとして使えてしまいます。</p> この紐付けは、広告で収益を上げるサービスでは特に意味を持ちます。利用者の行動を束ねてプロフィールを作るほど広告の精度が上がるので、複数の情報源を統合する動機がもともと働きます。電話番号やメールアドレスのような確実な識別子があれば、その統合は格段にやりやすくなります。メッセージの中身が暗号化されていても、誰がいつ誰と連絡したかというメタデータや、それを個人に結びつける識別子までは覆い隠せません。</p> メッセージングアプリの匿名性の比較</h2> ここまでの軸で、私が知る範囲の主要なアプリを並べてみます。</p> 暗号化の強さと、運営に対する匿名性は別物だという点に注目してください。暗号化の対応範囲やメタデータ収集、法執行機関への開示といった機能面の詳しい比較は前回の記事</a>にまとめたので、ここでは匿名性の軸に絞ります。</p> アプリ</th> 登録時に必要な個人情報</th> 運営に対する匿名性</th></tr></thead> LINE</td> 電話番号</td> なし</td></tr> WhatsApp</td> 電話番号</td> なし</td></tr> iMessage</td> 電話番号または Apple Account</td> なし</td></tr> Signal</td> 電話番号</td> なし</td></tr> Element / Matrix</td> なし（メールは任意）</td> サーバー次第</td></tr> Threema</td> なし</td> 運営は満たすと主張</td></tr> Session</td> なし</td> 高い</td></tr> SimpleX</td> なし</td> 最も高い部類</td></tr> </tbody></table> 国内利用者の多いLINEは、もう少し細かく見ておきます。LINEのメッセージはLetter Sealingと呼ぶ技術で暗号化されていますが、50人を超えるグループトーク、グループ音声・ビデオ通話、LINEミーティング、アルバム、ノートは対象外で、通信路のTLS暗号化にとどまります。この範囲は運営が技術的に中身へアクセスし得ます。そして匿名性の面では、登録に電話番号が必須なので運営に対する匿名性は持ちません。自治体などが市民の申請にLINEを使うケースが増えていますし、たまに企業でも業務で使用しているケースを見かけます。セキュリティ意識の低さには驚きます。</p> WhatsAppとiMessageも、垂直的匿名性はありません。メッセージの暗号化に対応していますが、登録にはWhatsAppが電話番号、iMessageが電話番号かApple Accountを必要とします。この時点で運営に対する匿名性は持ちません。特にWhatsAppを運営するMeta社は広告を収入源としているので、個人情報に関連したメタデータを収集してグループ内の他社と共有している可能性があります。中身は守られても、誰といつ繋がったかまでは隠せません。</p> ただし、Signalのメタ情報の電話番号、登録日、最終接続日のみ。</p> </aside> 暗号化に強いというイメージのSignalも垂直的匿名性はありません。ユーザー名機能が2024年に加わり、電話番号を教えないまま連絡できるようになりました(水平的匿名性)が、アカウントの作成には今も電話番号が必須です。 Signalを運営するのはSignal Foundationという非営利団体ですが、拠点はカリフォルニア州です。つまり米国の管轄下なので、米国の捜査機関の要求があれば開示義務があります。</p> ElementはMatrixというオープンなプロトコルの上に作られています。登録に必要なのは、選んだサーバー上のユーザー名とパスワードだけで、電話番号は要りません。メールアドレスはパスワード再設定用に任意で登録でき、サーバーによっては不正利用対策で求められることもあります。利用者はmatrix.orgのような公開サーバーを選んで登録するのが一般的で、自前でサーバーを立てることもできます。運営に対する匿名性は、結局どのサーバーを信頼するかに依存します。</p> 結局、垂直的匿名性を保持しているのは、Threema、Session、SimpleXのみです。</p> 垂直的匿名性の代償</h2> 垂直的匿名性の仕組みと、その代わりに払う利便性のコストを見ておきます。</p> Threemaは電話番号やメールアドレスを必要とせず、アカウントはランダムに割り当てられたThreema IDだけで機能します。ユーザーはThreema IDを交換しメッセージの送受信を行ないます。伝えるのはThreema IDのみなので、運営や相手に身元を明かさずに通信できます。 Threemaを使用していることすら秘匿する為にGoogle Playなどに依存せずThreemaを入手・購入できる手段も提供しています。 Threema IDはThreema社により管理されており、「IDが誰か」はThreema社に把握されませんが「いつ・どのIDと通信したか」は論理的にはThreema社で把握可能です。ただし、Threema社は広告やトラッキングを行なわないというポリシーを持ち、収益源を買い切り課金に置いています。</p> SimpleXは、利用者を識別する固定IDを一切持たない設計です。電話番号やユーザー名はもちろん、ランダムなIDすら使いません。仕組みは一方向のメッセージキューで、接続ごとに送信用と受信用の別々のキューを持ち、通常はそれぞれ別のサーバーを経由します。サーバーから見えるのは不透明なキューへの孤立した配送だけで、送信者と受信者を結びつけられません。サーバー同士も通信せず、配送が済んだメッセージは保存しません。</p> SessionはもともとSignalのフォークとして始まりました。電話番号やメールなどの個人データも不要で、ランダムなSession IDという66文字程度の公開鍵をアカウントのIDとして使います。メッセージは多数の有志ノードからなるオニオン型のネットワークを経由し、どのノードも送信者と受信者の両方を知ることはありません。運営は2024年10月に、暗号化技術への規制圧力を背景としてオーストラリアからスイスへ拠点を移し、現在はスイスのSession Technology Foundationが運営しています。コードはQuarkslabによる独立監査を受けています。SimpleXとの違いは、Sessionが永続的なアカウントのIDを持つ点です。</p> これらの高い匿名性には、現実的な代償が伴います。</p> いずれも、相手に直接リンクやQRコード、IDを渡さなければ会話を始められない</li> 従って、電話番号やユーザー名で気軽に相手を見つけることはできず、なんらかの方法で相手と直接これらの情報を交換する必要がある</li> </ul> 一番問題になるのは、相手も同じアプリを入れている必要があるところでしょう。いずれもマイナーなアプリなので、匿名性のために連絡相手の数と手軽さを大きく差し出すことになります。この利便性の低さは、日常使いを考えるうえで無視できないトレードオフです。</p> メッセージングアプリについて私の選択</h2> ここまで匿名性の強さで並べてきましたが、強ければ強いほどよい、という話ではありません。匿名性がどれだけ効くかは、相手があなたの身元を知っているかどうかで変わります。</p> 私は以下のように考えています。</p> 関係</th> 説明</th></tr></thead> 家族</td> 当然対面しており、インストールするアプリも管理可能。機微なメッセージ交換もあり</td></tr> 友人</td> 対面しているが、アプリの管理は困難。機微なメッセージ交換は限定的</td></tr> 他人</td> 必ずしも対面していない。アプリの管理は不能。機微なメッセージはなし</td></tr> </tbody></table> このように考えると、家族とは水平的匿名性は不要で垂直的匿名性が必要です。前回の記事でも軽く触れましたが、私自身は家族との連絡用にThreemaを選んでいます。 SimpleXやSessionでもよいのですが、かなり以前からThreemaを使用しており、特に問題もないために使用を続けています。</p> 友人も同様です。知り合いなので水平的匿名性は不要ですが、垂直的匿名性は必要です。しかし、現実的には垂直的匿名性を実現するために、先に記述した「代償」のため友人に対応するアプリを導入してもらうことは困難です。そのため諦めて必要な場合は、友人にはメールかSMSでのコンタクトを依頼しています。暗号化、匿名性は放棄すると言うことです。 LINEなどを使っていると「じゃ、LINEで」と言われるので、私はLINEなどのアプリは使わずインストールさえしていません。</p> ネットで知り合ったような他人については、どちらの匿名性も重要だと思います。しかし、私は、匿名のままネットで知り合った相手とメッセージングアプリを使って通信するようなニーズはないので無視します。</p> まとめ</h2> LINE・WhatsApp・iMessage・Signalなど主要なメッセージングアプリは、暗号化や水平的匿名性は実装されていますが、垂直的匿名性は担保されていません。LINEなど「なりすまし防止、復旧、法令遵守」などを理由に電話番号への紐付けを強化しています。自治体などでLINEを使用するケースが多いようですが、あれは個人特定を行政として放棄しているとしか思えません。</p> 私にとって必要なのは垂直的匿名性です。メッセージの中身が暗号化されていても、運営に身元や「誰といつ通信したか」を握られては、プライバシーを守ったことになりません。一方、相手に対しても名乗らない水平的匿名性は、私個人にはほとんど必要ありません。</p> 両方の匿名性を保てるのは、Threema・Session・SimpleXの3つです。</p> 米国報道機関ではSignalが使用されているケースが多いようです。</p> </aside> 両方の匿名性が必要なのは、相手や運営に身元を伏せたまま連絡したい場面だけです。こうしたニーズは犯罪目的での使用を想起するかもしれませんが、内部告発や情報提供など正当な目的のためにも必要です。米国では報道機関が情報提供の窓口としてメッセージングアプリの宛先などを公開しています。日本ではこうした使い方はほとんど根づいておらず、全く遅れています。</p> 大切なのは、自分がどちらの匿名性を必要とするのかを見極めることです。垂直的匿名性はほとんどの人に効きますが、水平的匿名性まで求めるかは人によって大きく変わります。私自身は、身元を隠す必要のない家族との連絡に、垂直的匿名性を保ちつつ扱いやすいThreemaを使っています。</p> References</h2> Threema</a>. "Anonymity at the System Level: The Ultimate Privacy Protection"</li> Threema</a>. "Statement on ETH Findings"</li> ETH Zurich Applied Cryptography Group</a>. "Three Lessons from Threema"</li> Signal</a>. "Keep your phone number private with Signal usernames"</li> Signal Foundation</a>. "Signal Foundation"</li> SimpleX Chat</a>. "How SimpleX works"</li> Session</a>. "Introducing the Session Technology Foundation"</li> Session</a>. "Session code audit by Quarkslab"</li> WhatsApp Help Center</a>. "About end-to-end encryption"</li> Apple Support</a>. "iMessage security overview"</li> Element</a>. "Creating a Matrix Account"</li> LINE Help Center</a>. "Letter Sealing"</li> LINEヤフー</a>.「LINE暗号化状況レポート（2025年）」</li> </ul> </div> 三菱UFJ銀行のPPAP廃止は、半歩前進で半歩後退 2026-06-08T00:00:00+00:00 三菱UFJ銀行が2026年6月8日付で「当行からの添付ファイル送信方法の変更に関するご案内</a>」を公表しました。日本を代表するメガバンクがまだPPAPやっていたと衝撃を受けました。内容を読んで考えさせられたので記録しておきます。</p> 三菱UFJ銀行のアナウンス</h2> 要点はシンプルです。</p> 同行は、お客さま側のセキュリティを確保するため、パスワード付き添付ファイルのメール送信を原則取り止めると発表しました。 2026年7月18日より順次、添付ファイルを送る際は専用のダウンロードサイトを利用する方式へ変更されます。</p> 理由として挙げられているのは次の2点です。これまでの「メールでパスワード付きZIPファイルを送り、パスワードを別送する方法」、いわゆる PPAP</strong> は、ファイルが暗号化されているためメール受信時のマルウェアチェックが困難であること。そして近年、パスワード付きZIPファイルを悪用したサイバー攻撃の事例が確認されていることです。</p> 新方式では、同行の役職員が添付ファイルを送る際、メール本文に専用ダウンロードサイトへアクセスするためのURLを記載します。受け手はそのサイトにアクセスし、別送されるダウンロード専用のパスワードを使ってファイルを取得します。</p> PPAPの何が問題だったのか</h2> PPAPの是非については、昨年「AWSからSMSにメッセージを送る</a>」という記事で一度整理しました。</p> そのとき、機密文書をメールで送る手段を秘匿性と本人確認性の観点で並べて評価したのですが、結論は変わっていません。</p> PPAP、つまり暗号化ファイルとパスワードを同じ経路で送る方法は、1通盗まれればすべて漏洩します。パスワードを別メールにしても、同じメールインフラを流れる以上、傍受や誤送信のリスクは本質的には下がりません。加えて、暗号化されたZIPはメールゲートウェイでウイルススキャンできないため、マルウェアの運び屋になりやすい。三菱UFJ銀行が今回理由として挙げているのは、まさにこの最後の点です。</p> ですから、PPAPをやめるという判断そのものは正しいと思います。日本でも2020年に政府がPPAPの廃止方針を打ち出して以降の流れに沿っていますし、銀行という立場で旗を振る意味も小さくありません。</p> 新方式は本当に安全になったのか</h2> 問題は、その置き換え先です。</p> 新方式は「メール本文にダウンロードサイトのURLを記載し、パスワードは別送する」というものでした。マルウェアスキャンの観点では確かに前進しています。ファイルが暗号化ZIPとしてメールに乗らなくなるので、受信側のゲートウェイで中身を検査できるようになるからです。</p> しかし、フィッシング耐性という観点では、むしろ後退しかねません。</p> ひとつは、銀行が自ら「メール本文のURLをクリックさせる」習慣を送信先に植え付けてしまう点です。銀行はこれまでフィッシング対策として、「当行からのメールにURLは記載しません」「メール内のリンクは開かないでください」と顧客には教育してきたはずです。メールの送信先は顧客ではないと思いますが、今回はその逆を習慣づけることになります。なりすましメールに偽のダウンロードURLが貼られていても、利用者は見分けがつかなくなります。</p> もうひとつは、「パスワードを別送する」という発想がPPAPのままという点です。日ごろ支援しているコンサルテーション会社やITベンダーはちゃんと技術的に支援できなかったんでしょうか？</p> URLとパスワードを両方メールで送るのであれば、構造的にはPPAPの暗号化ZIPをWebサイトに置き換えただけです。同じ経路を流れる以上、傍受や誤送信による漏洩リスクは解決していません。マルウェアの問題は片付いても、秘匿性の問題は手つかずなのです。</p> 整理すると、今回の変更は「マルウェアスキャン」という一点ではマシになる一方で、フィッシング耐性では弱点を抱え込む、惜しい設計だと感じます。</p> 本来あるべき姿</h2> 以前の記事</a>でも書きましたが、現実的なのは認証付きのクラウドストレージで共有する方法でした。受け手がログインして初めてファイルにアクセスできる仕組みなら、URLが単体で漏れても無効ですし、誰がいつアクセスしたかのログも残せます。パスワードを別送する必要すらありません。</p> メールの送付先は取引業者だと思いますから、銀行が共通の認証を払い出すのは困難です。たとえばBoxやDropboxのようなクラウドストレージであれば、受け手は無料のアカウントを気軽に作れます。銀行側が取引先ごとにアカウントを発行・運用しなくても、受け手がログインして初めてファイルにアクセスできる仕組みを成り立たせられるわけです。 URLが単体で漏れても無効ですし、誰がいつアクセスしたかのログも残ります。</p> さらに言えば、この方式ならメールにリンクを書く必要すらありません。ファイルを共有すれば、受け手にはクラウドストレージ側から「共有されました」という通知が届きます。受け手は自分が信頼しているサービスにログインしてファイルを取りに行くだけです。冒頭で挙げた、メール内URLをクリックさせる習慣づけという問題が、根本から消えてなくなるのです。</p> より根本的な解はないのか</h2> もっとも、銀行ともあろうものがファイルの受け渡しを外部のクラウドサービスに丸ごと預けるのも、それはそれで引っかかります。委託先管理やデータの所在、サービスへの従属といった問題が新たに生じるからです。だとすれば、現実的な落としどころは、銀行が認証付きの受け渡しポータルを自前で持つことでしょう。インターネットバンキングという認証基盤と運用ノウハウをすでに備え、取引先の本人確認も日常的に行っている組織です。 Boxがやっていることを内製すればよいだけです。技術力と体力の両面で、銀行はそれができる立場にあります。</p> では、もっと教科書的な根本解はないのか。あります。受け手の証明書でメールそのものを暗号化・署名するS/MIME、いわゆるPKIです。外部サービスやポータル、パスワードの別送といった仕組みが一切要らず、本人性と秘匿性をエンドツーエンドで担保できる、理屈のうえでは最も美しい解です。</p> ところがPKIは、米国ですら普及しませんでした。証明書の発行や管理が高コストで手作業が多く、ユーザーごと・端末ごとに鍵を入れて回る運用負荷に耐えられなかったためです。そして決定的なのは、送り手と受け手の双方が対応していないと成り立たない</strong>という両側依存です。暗号化して送るには、相手があらかじめ証明書を用意していなければなりません。相手が対応していなければ、文字どおり意味がない。この鶏と卵の構造ゆえに、誰も最初の一歩を踏み出せませんでした。受け手に「アカウントを作ってログインする」という自己完結した操作しか求めないポータル方式に世界が流れたのは、そのためです。</p> それでもリーダーシップを期待したかった</h2> ここで私が惜しいと思うのは、まさにこの一点です。 PKIが普及しなかった最大の理由が「最初の一歩を誰も踏み出せなかった」ことなら、その一歩を踏み出せる体力と影響力を持つ組織こそ、日本を代表するメガバンクのはずです。</p> 率先してS/MIMEを導入し、添付ファイルをやり取りするような主要な取引先には導入を促す。場合によっては証明書発行の基盤を貸し出したり、運用を支援したりする。そうやって両側依存の壁を、影響力のある側から崩していく。そんなリーダーシップを見せてくれたら、日本全体のメール文化が一段前に進んだかもしれません。</p> 現実的な着地は認証付きポータルでよいと思います。ただ、PPAPをやめるという入口が正しかっただけに、出口がもう一歩踏み込めなかったのは惜しい。日本をリードする銀行のやることだからこそ、ここにこそリーダーシップを期待したかった、というのが私の正直な感想です。</p> References</h2> 株式会社三菱UFJ銀行</a>. 「当行からの添付ファイル送信方法の変更に関するご案内」（2026年6月8日）</li> Coded Chords</a>. 「AWSからSMSにメッセージを送る」（2025年6月9日）</li> </ul> </div> 無料で始める 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> SPFのDNSルックアップ上限10回、あなたの組織は大丈夫？ 2026-03-03T00:00:00+00:00 </div> 転載元</strong> この記事は Zenn</a> に掲載した記事の転載です。</p> </div> </div> </p> Table of Contents</summary> </details> はじめに</h2> 「ある日突然、自組織からのメールが取引先に届かなくなった」——そんな事態が、メール配信サービスを複数利用している組織で実際に起こり得ます。原因は、SPF（Sender Policy Framework）のDNSルックアップ上限です。</p> 外部のメール配信サービスを導入するたびにSPFレコードへ include</code> を追加していくと、気づかないうちに上限へ近づきます。しかも、上限超過のトリガーは自組織の操作ではなく、外部サービス側の設定変更かもしれません。</p> 本記事では、SPFのDNSルックアップ上限の仕組みを解説し、上限超過のリスクと対策を整理します。</p> SPFの仕組みとDNSルックアップ上限</h2> SPFは、メールの送信元ドメインが「どのサーバーからの送信を許可しているか」をDNSのTXTレコードで宣言する仕組みです。受信側メールサーバーは、送信元IPアドレスがSPFレコードに含まれているかを検証し、正当な送信元かどうかを判断します。</p> SPFレコードの例を示します。</p> v=spf1 ip4:192.0.2.0/24 include:spf.example.com ~all</span></span></code></pre> この例では、192.0.2.0/24</code> のIPレンジからの送信と、spf.example.com</code> が許可する送信元を正当とみなします。</p> SPFの検証は受信側メールサーバーで行われます。メールを受け取ったサーバーが送信元ドメインのSPFレコードをDNSに問い合わせ、送信元IPが許可されているかを確認します。この検証過程でDNSルックアップが発生しますが、RFC 7208（Section 4.6.4）により、1回のSPF検証で実行できるDNSルックアップは最大10回と制限されています。この制限は、SPF検証によるDNSサーバーへの負荷を防ぐために設けられたものです。</p> すべてのメカニズムがDNSルックアップを消費するわけではありません。消費するメカニズムとしないメカニズムを表にまとめます。</p> メカニズム / 修飾子</th> DNSルックアップ</th></tr></thead> ip4</code> / ip6</code></td> 0回（IP直接指定のためDNS不要）</td></tr> a</code></td> 1回</td></tr> mx</code></td> 1回（＋MXレコードが指すAレコードの解決）</td></tr> include</code></td> 1回＋参照先のSPFレコード内のルックアップ</td></tr> redirect</code></td> 1回</td></tr> exists</code></td> 1回</td></tr> </tbody></table> 重要なのは include</code> の挙動です。include</code> は参照先のSPFレコードをさらに評価するため、参照先に include</code> や a</code> が含まれていれば、それらも合算されます。つまり、1つの include</code> が実際には複数回のルックアップを消費する場合があります。</p> includeの入れ子で上限に近づく実例</h2> 架空の組織 example.or.jp</code> を例に考えます。この組織では業務メールに加えて、メールマガジン配信に3つの外部サービスを利用しています。SPFレコードは以下のようになっています。</p> v=spf1 ip4:192.0.2.0/29 ip4:198.51.100.1 include:spf.mail-a.example include:spf.mail-b.example include:spf.mail-c.example include:spf.bizmail.example ~all</span></span></code></pre> 各エントリのDNSルックアップ数を確認します。</p> エントリ</th> DNSルックアップ</th></tr></thead> ip4:192.0.2.0/29</code></td> 0回（IP直接指定）</td></tr> ip4:198.51.100.1</code></td> 0回（IP直接指定）</td></tr> include:spf.mail-a.example</code></td> 1回</td></tr> include:spf.mail-b.example</code></td> 1回＋内部で3回 = 4回</td></tr> include:spf.mail-c.example</code></td> 1回</td></tr> include:spf.bizmail.example</code></td> 1回</td></tr> 合計</strong></td> 7回 / 上限10回</strong></td></tr> </tbody></table> 一見すると余裕がありそうですが、問題は spf.mail-b.example</code> の内部構造です。このSPFレコードは以下のようになっています。</p> v=spf1 exists:%{i}.spf.mail-b1.example exists:%{i}.spf.mail-b2.example include:spf.mail-b3.example ~all</span></span></code></pre> include</code> 1つで4回のルックアップを消費しています。そして、この内訳は外部サービス側の設定に依存しています。</p> ここに大きなリスクがあります。外部サービスがインフラ変更に伴いSPFレコードへ include</code> や a</code> を追加すれば、自組織が何も変更していなくてもルックアップ数が増加します。たとえば spf.mail-b.example</code> が内部で1つ include</code> を追加するだけで、合計は8回になり、上限までわずか2回です。さらに別のサービスも同様の変更をすれば、上限を超えてしまいます。</p> 上限を超えるとどうなるか</h2> SPFのルックアップ数が10回を超えると、SPFの検証結果は permerror</code>（恒久的エラー）になります。これは「SPFレコードが壊れている」とみなされる状態です。</p> permerror</code> が発生すると、受信側メールサーバーの設定に応じて以下のいずれかが起こります。</p> メールが拒否される（バウンス）</li> 迷惑メールフォルダに振り分けられる</li> DMARCのSPF判定がfailとなり、DMARCポリシー次第でメールが拒否される</li> </ul> 特に厄介なのは、この問題が自組織側からは気づきにくい点です。送信自体は正常に行われ、送信者にはエラーが返らない場合もあります。受信側で静かにスパム判定されるため、「最近メールの返信が来ない」「メルマガの開封率が急落した」といった間接的な兆候で初めて気づくことになります。</p> 自分のドメインのルックアップ数を確認する方法</h2> dig</code> コマンドでSPFレコードの内容を確認できます。</p> dig</span> +short TXT example.or.jp</span> |</span> grep</span> spf</span></span></code></pre> 表示されたSPFレコードに含まれる include</code> 先も再帰的に確認する必要があります。</p> dig</span> +short TXT spf.mail-b.example</span></span></code></pre> 手動での再帰的な確認は手間がかかるため、オンラインツールの利用も有効です。</p> MXToolbox SPF Record Lookup</strong> — SPFレコードの内容とDNSルックアップ数を自動計算してくれる</li> dmarcian SPF Surveyor</strong> — SPFレコードの構造をツリー表示で可視化できる</li> </ul> これらのツールにドメイン名を入力するだけで、現在のルックアップ数と上限までの余裕を確認できます。定期的にチェックしておくことをお勧めします。</p> 対策</h2> SPFルックアップ上限の問題に対して、短期的な対策と中長期的な対策があります。</p> まず短期的な対策として、メール送信経路を棚卸しします。SPFレコードに登録されている include</code> やIPアドレスが、現在も使われているかを確認します。利用を終了したサービスの include</code> が残っていると、ルックアップ数を無駄に消費するだけでなく、そのサービスのIPレンジが自ドメインの正当な送信元として許可されたままになります。これはなりすましに悪用されるリスクでもあります。</p> 次に、メール配信サービスの統合を検討します。メルマガ配信に複数のサービスを併用している場合、1つに統合すれば include</code> の数を減らせます。配信実績の分析も一元化でき、コスト管理も簡素化されます。</p> これらの根本対策とは別に、技術的な回避策も存在します^{1</a></sup>。ただし運用上の注意点があるため、まずは送信経路の整理を優先すべきです。</p>} 最後に、中長期的な対策としてDMARCポリシーの段階的強化があります。DMARCはSPFとDKIMの認証結果に基づいて、認証失敗時のメール処理方針を宣言する仕組みです。ポリシーは以下の順で強化します。</p> p=none</code>（監視モード）でDMARCレポートを収集し、全送信経路の認証状況を把握する</li> 全経路でSPF・DKIMがpassすることを確認したうえで p=quarantine</code>（隔離）に移行する</li> 一定期間の監視後、問題がなければ p=reject</code>（拒否）に移行する</li> </ol> 送信経路が整理されていれば、この移行は技術的には難しくありません。逆に、送信経路が乱立したままでは各経路の認証状況を把握すること自体が困難であり、DMARC強化は事実上不可能です。</p> まとめ</h2> SPFのDNSルックアップ上限10回は、メール配信サービスを複数利用する組織にとって見落とされがちなリスクです。外部サービスの include</code> は入れ子構造でルックアップ数が膨らみ、しかも外部サービス側の変更で自組織のルックアップ数が増加するという、制御しにくい特性があります。</p> まずは自分のドメインの現在のルックアップ数を確認してみてください。上限に近づいている場合は、不要な include</code> の削除やサービスの統合を検討し、DMARCポリシーの強化と合わせてメール配信の信頼性を確保していくことが重要です。</p> 技術的な回避策としてSPF MacroとSPF flatteningがあります。SPF Macroは exists</code> メカニズムと変数を組み合わせてルックアップ数を抑える手法です。SPF flatteningは include</code> 先のIPアドレスを直接 ip4</code> / ip6</code> で記述してルックアップを削減する手法です。ただしflatteningは参照先のIPが変更されたときに追従が必要なため、自動化ツールなしでの運用は推奨しません。 ↩</a></p> </li> </ol> </section> Cloudflare無料プランだけで個人サイトのセキュリティが完結した話 2026-02-20T00:00:00+00:00 TL;DR</h2> Cloudflareのアドバンテージは、次の3点です。</p> 無料プランだけでWAF・ボット対策まで揃う、セキュリティの充実度</li> DNS統合だからこそ、煩雑でリスクの高い設定をワンクリックで実現</li> AIクローラー対策やページ先読みなど、最新トレンドへの即応</li> </ul> つい3日前にCloudflareへ移転した</a>ばかりです。構成はシンプルで、Cloudflareでドメインを取得し、GitHubリポジトリと連携して静的コンテンツをCloudflare Pages1</a></sup>へデプロイしています。この構成だけでも思いの外多くの恩恵が得られたので、まとめておきます。</p> Cloudflareでの設定</h2> Cloudflareのダッシュボードで有効にした機能を、カテゴリごとに紹介します。いずれも無料プランで利用でき、ほとんどがトグルひとつで有効にできるものです。なお、本記事の機能名やβ表記は2026年2月時点のCloudflare管理画面のUIに基づいています。</p> Edge Certificates</h3> Cloudflareが発行・管理するSSL/TLS証明書と、HTTPS通信に関する設定です。</p> 項目</th> 説明</th></tr></thead> Always Use HTTPS</td> HTTP でアクセスが来た場合に自動的に HTTPS へ301リダイレクトしてくれるので、暗号化されていない通信を防げる。</td></tr> HSTS</td> .dev</code> ドメイン^{2</a></sup>を使用しているので私の場合あまり恩恵がないが、ブラウザレベルでHTTPSが強制できる。</td></tr>} Minimum TLS Version</td> サイトに接続する際に許可するTLSプロトコルの最低バージョンの指定。TLS 1.0 と 1.1 は既知の脆弱性があるので、私はTLS1.2にしている。</td></tr> Opportunistic Encryption</td> HTTPでアクセスしてきたブラウザに対して「暗号化接続も利用可能ですよ」と通知する仕組み。.dev</code> の場合、HTTPアクセスが発生しないので実質的に意味がない。</td></tr> TLS 1.3</td> Minimum TLS Version を 1.2 に設定し、この TLS 1.3 をオンにしておけば、「最低 1.2、対応していれば 1.3 を使う」という構成になる。</td></tr> Automatic HTTPS Rewrites</td> http://</code> をCloudflare が自動的に https://</code> に書き換えて「混在コンテンツ（mixed content）」の問題を防いでくれる。</td></tr> Certificate Transparency Monitoring</td> 自分が意図していない証明書が第三者によって発行された場合（ドメインの不正利用や乗っ取りの兆候）通知してくれる</td></tr> </tbody></table> Security</h3> ボット対策、DDoS防御、WAFなど、サイトを外部の脅威から守るための設定です。</p> 項目</th> 説明</th></tr></thead> AI Labyrinth</td> まだβ機能だが、robots.txt 等のクロールルールを無視して勝手にサイトをスクレイピングするボットに対して偽コンテンツを読ませて学習データを汚染させるという「ハニーポット」的な機能</td></tr> Block AI bots</td> AI学習用クローラーをブロックする機能</td></tr> Bot fight mode</td> 悪意のあるボット（スパム、クレデンシャルスタッフィング、DDoS等）を検知すると、JavaScriptチャレンジを出して人間かどうかを確認する</td></tr> Browser Integrity Check</td> 訪問者のHTTPヘッダーを検査して、不正なUser-Agentやスパムボットによく見られる異常なヘッダーパターンを検出し、脅威が見つかった場合はブロックページを表示する。</td></tr> Challenge passage</td> チャレンジ（CAPTCHA等）をクリアした訪問者が、再度チャレンジを求められるまでの有効時間</td></tr> HTTP DDoS attack protection</td> HTTPレイヤーのDDoS攻撃を自動検知・緩和する。無料プランでもCloudflare Free Managed Ruleset（基本的なWAFルール）が付属する</td></tr> Manage your robots.txt</td> Cloudflare が robots.txt を自動管理するβ機能。Content Signals Policyを選択すると、コンテンツの利用意図を用途別（検索・AI入力・AI学習）に宣言できる</td></tr> Network-layer DDoS attack protection</td> DDoS保護</td></tr> </tbody></table> DNS</h3> DNS応答の改ざん防止やメールのなりすまし対策など、ドメインの信頼性を高める設定です。</p> 項目</th> 説明</th></tr></thead> DNSSEC</td> DNSレスポンスに暗号署名を付与して、DNS応答の偽造（DNSキャッシュポイズニング等）を防ぐ</td></tr> Email Security</td> 有効にしてDMARCの設定。メール送信の予定はないので、SPFは"v=spf1 -all"で設定。DMARCは"v=DMARC1; p=reject"</td></tr> </tbody></table> Speed</h3> 通信プロトコルの最適化やページ先読みなど、サイト表示を高速化するための設定です。</p> 項目</th> 説明</th></tr></thead> Web analytics using real user measurement (RUM)</td> 実際の訪問者のブラウザからパフォーマンスデータ（ページ読み込み時間など）を収集する。Cookieを使わないプライバシー重視の計測方式</td></tr> Speed Brain</td> ユーザーがリンクをクリックする前にページを先読みする機能。Speculation Rules API を使い、体感的なページ遷移が高速になる</td></tr> HTTP/2</td> HTTP/1.1の後継。1つの接続で複数リクエストを並行処理（多重化）でき、ページ読み込みが高速になる</td></tr> HTTP/3</td> HTTP/2の次世代版。TCPの代わりにQUICプロトコルを使い、接続確立が高速でパケットロス時の劣化も少ない</td></tr> HTTP/2 to Origin</td> Cloudflareとオリジンサーバー間の通信にもHTTP/2を使う設定</td></tr> 0-RTT Connection Resumption</td> TLS 1.3で接続済みのクライアントが再訪問時にハンドシェイクの最初の往復を省略でき、再訪問者の初回リクエストが速くなる</td></tr> </tbody></table> 以前のプラットフォームとの比較</h2> 昨年までAmazon Amplify、先月までGitHub Pagesで運用していました。上記で挙げたCloudflareの機能が、それぞれの環境ではどうだったかを比較してみます。特にセキュリティ列の差に注目してください。</p> ○: 標準/無料で利用可能</li> △: 別途設定や追加費用で対応可能</li> ×: 非対応</li> −: 該当なし</li> </ul> 機能</th> Amplify + CloudFront</th> GitHub Pages</th> コメント</th></tr></thead> Always Use HTTPS</td> ○</td> ○</td> </td></tr> HSTS</td> △（手動設定）</td> ○</td> AWSだけ手動設定の手間がかかる</td></tr> Minimum TLS Version</td> ○</td> ×</td> GitHub Pagesは古いTLSを拒否できず、セキュリティポリシーを徹底しにくい</td></tr> Opportunistic Encryption</td> ×</td> ×</td> HTTP接続の暗号化への誘導は他のサービスでは提供されていない</td></tr> TLS 1.3</td> ○</td> ○</td> </td></tr> Automatic HTTPS Rewrites</td> ×</td> ×</td> 他では混在コンテンツを自分で探して直す必要がある</td></tr> Certificate Transparency Monitoring</td> △（ACMの一部）</td> ×</td> 不正な証明書発行の早期発見に差が出る</td></tr> AI Labyrinth</td> ×</td> ×</td> ワンクリックでAIスクレイピングに対抗できる機能は他にない</td></tr> Block AI bots</td> △（WAFルールで対応）</td> ×</td> AWSは自前でルールを書く手間とWAF費用がかかる</td></tr> Bot fight mode</td> △（WAF Bot Control有料）</td> ×</td> AWSで同等機能を得るにはBot Control（月額$10〜＋リクエスト従量課金）が必要</td></tr> Browser Integrity Check</td> △（WAFで部分的）</td> ×</td> AWSでは同等ルールの自作が必要で、運用負荷が高い</td></tr> Challenge passage</td> △（WAF）</td> ×</td> Cloudflareはチャレンジの有効期間まで細かく制御できる</td></tr> HTTP DDoS attack protection</td> △（WAFは有料）</td> ×</td> 無料でWAFまで付くのはCloudflareの大きな強み</td></tr> Manage your robots.txt</td> ×</td> ×</td> 増え続けるAIクローラーへの対応を自動化できる機能は他にない</td></tr> Network-layer DDoS attack protection</td> ○（Shield Standard）</td> ○</td> </td></tr> DNSSEC</td> ○（Route 53）</td> △（DNS providerに依存）</td> Cloudflareはワンクリック、DNS一体管理なので設定が圧倒的に楽</td></tr> Email Security</td> ○（Route 53）</td> △（DNS providerに依存）</td> 同上。DNS管理とセットなのでSPF/DMARCの設定も迷わない</td></tr> Web analytics (RUM)</td> △（CloudWatch RUM有料）</td> ×</td> Cloudflareは追加費用なしでCookie不要の計測が使える</td></tr> Speed Brain</td> ×</td> ×</td> ページ先読みによる体感速度向上は他のサービスでは提供されていない</td></tr> HTTP/2</td> ○</td> ○</td> </td></tr> HTTP/3</td> ○</td> ×</td> GitHub Pagesは2026年2月時点でHTTP/3未サポート</td></tr> HTTP/2 to Origin</td> ○</td> −</td> オリジンサーバーがある構成でのみ意味がある</td></tr> 0-RTT</td> ×</td> ×</td> 再訪問時の体感速度に差が出る。他のサービスでは無料で提供されていない</td></tr> </tbody></table> AI時代のコンテンツ保護</h2> Cloudflareの無料プランには、AIクローラーに対応する機能が複数用意されています。これらは独立した機能ですが、組み合わせると多層的な防御になります。</p> 機能</th> レイヤー</th> 役割</th></tr></thead> Content Signals Policy</td> 意思表示</td> robots.txt内でコンテンツの用途別に許可/拒否を宣言する。強制力はなく、善意あるクローラーへの「お願い」</td></tr> Block AI bots</td> 技術的ブロック</td> Cloudflareが「AI学習用」と分類するクローラーをWAFレベルでブロックする。検索エンジンやAIアシスタントは対象外</td></tr> AI Labyrinth</td> 欺瞞防御</td> ブロックを無視するクローラーに偽コンテンツを読ませ、学習データを汚染させるハニーポット</td></tr> </tbody></table> ポイントは、Content Signals PolicyとBlock AI botsの役割分担です。Content Signals Policyでは search=yes, ai-input=yes, ai-train=no</code> のように宣言し、「検索やAI回答での引用はOKだが、モデルの学習には使うな」という意思を伝えます。しかし宣言はあくまで「お願い」なので、AI学習用クローラーに対してはBlock AI botsがWAFレベルで実際にアクセスを遮断します。それでもすり抜けてくるクローラーにはAI Labyrinthが偽データを食わせます。</p> さらに、AI Crawl ControlのCrawlersタブではクローラーごとに個別のAllow/Blockを設定できます。たとえば「ChatGPT-Userは許可するがBytespiderはブロックする」といった細かい制御も可能です。</p> この多層構成により、AI検索からの流入を確保しつつ学習目的のスクレイピングは拒否するという運用が、無料プランだけで実現できます。</p> Cloudflareの評価</h2> 比較表を振り返ると、Cloudflareの強みは大きく3つあります。</p> 1つ目は、無料プランでのセキュリティの充実度です。AWSで同等のボット対策やWAFを実現しようとすると、AWS WAFやBot Controlの追加費用と自前でのルール作成が必要でした。GitHub Pagesではユーザーが設定できるセキュリティ機能はほとんどありません。Cloudflareでは、AIボットのブロック、Bot fight mode、WAFまで無料プランに含まれており、しかもダッシュボードのトグルひとつで有効にできます。</p> 2つ目は、DNS・証明書・セキュリティ・CDNがひとつのダッシュボードに統合されている点です。AWSではRoute 53、CloudFront、ACM、WAFと複数サービスをまたいで設定する必要がありました。GitHub PagesではDNSが外部依存のため、DNSSECやSPF/DMARCの設定は利用するDNSプロバイダ次第でした。Cloudflareではドメイン取得からDNSSEC、メールセキュリティ、デプロイまで一箇所で完結するため、設定の見通しがよく管理も楽です。</p> 3つ目は、他のサービスでは提供されていない独自機能です。前述のとおり、Content Signals PolicyからBlock AI bots、AI Labyrinthまで、AIクローラーへの多層的な対応が無料プランだけで揃います。加えて、Speculation Rules APIを活用したSpeed BrainやTLS 1.3の0-RTT再接続など、パフォーマンス面でも独自の機能が提供されています。特にAIクローラー対策は今後ますます重要になる領域であり、「意思表示」と「技術的ブロック」と「欺瞞防御」を組み合わせた構成がワンクリックで手に入るのは大きな安心感があります。</p> 個人の静的サイトという用途では、Cloudflareの無料プランだけで「やりたいことが全部できる」状態になりました。以前はAWSの複数サービスを組み合わせて実現していたことが、Cloudflareではひとつのダッシュボードで、しかも無料で手に入ります。移行してよかったと素直に思います。</p> Cloudflare Pagesは現在、Cloudflare Workersとの統合が進んでいる</a>。将来的にはWorkersの静的アセット機能に一本化される見込みだが、Pages自体も引き続き利用可能。 ↩</a></p> </li> .dev</code> ドメインはGoogleが管理しているTLDで、HSTS Preload ListにTLD単位で登録済みなので最初からHTTPSが強制される。 ↩</a></p> </li> </ol> </section> Zolaブログを新ドメイン取得 + Cloudflare移転 2026-02-17T00:00:00+00:00 </div> NOTE</strong> この記事は Zenn.dev</a> に掲載した記事の転載です。</p> </div> </div> TL;DR（Zola利用者向け）</h2> Cloudflare ProxyとGitHub Pagesの組み合わせでは、Let's Encrypt証明書のHTTP-01チャレンジを妨げるリスクがある</li> Cloudflare PagesのCI/CDはv2以降Zolaをサポートしていない（issue #3</a>は2023年からOpen）。GitHub Actions + wrangler deploy</code>で代替可能</li> </ul> はじめに</h2> 以前、Amazon Amplify + Next.js + Tailwind CSSで運用していたブログをGitHub Pages + Zolaに移行しました。GitHub Pagesはシンプルで運用コストが低い一方、カスタムHTTPレスポンスヘッダーを設定できないという制約があります。以前の記事</a>でも書きましたが、セキュリティスキャナーで警告が出る状態をずっと気にしていました。</p> では、Cloudflareに持っていくかと移転をはじめたところ、いくつかひっかかりポイントがあったので共有します。</p> 新ドメインの取得</h2> 移転にあたり、新ドメインcodedchords.dev</code>を取得しました。旧ドメインから変更した理由は2つあります。</p> Cloudflareの無料プランではDNSをCloudflareに移管する必要がある。旧ドメインはFastMailでメール運用しておりDNSもFastMailに移管済みのため、Cloudflareへの再移管が難しい</li> 旧ドメインは長年の運用とブログ改築の結果、404でインデックスされないページが多数あり、これを機に一新してもよい</li> </ul> TLDは.dev</code>を選びました。.dev</code>はGoogleが管理するTLDで、HSTSプリロードリストに登録されています。ブラウザレベルでHTTPS接続が強制されるため、セキュリティ面で最初から一段高い状態が保証されます。</p> Cloudflare Workers への移行</h2> セキュリティヘッダーを設定するために、Cloudflareを利用する方針で検討を進めました。最終的にCloudflare Workersの静的アセット機能に落ち着くまでに、2つのアプローチで挫折しています。</p> 案1: Cloudflare Proxy + Transform Rules（断念）</strong>。最初に検討したのは、CloudflareのProxyを有効にしてTransform Rulesでレスポンスヘッダーを追加する方法です。GitHub Pagesをオリジンとし、Cloudflareを前段に配置する構成です。しかし、GitHub PagesのLet's Encrypt証明書は90日ごとにHTTP-01チャレンジで自動更新されます。Cloudflare Proxyが間に入るとチャレンジがGitHubへ届かず、更新が静かに失敗する可能性があります。証明書の期限切れでサイトが突然表示不能になるリスクがあり、静的ブログで証明書を定期監視するのは割に合いません。この案は見送りました。</p> 案2: Cloudflare Pages CI/CD（断念）</strong>。次に、Cloudflare PagesのCI/CDでZolaをビルドしてそのままホスティングする方法を試みました。しかし、Cloudflare Pagesのv2ビルドシステムではZolaがサポート対象から外れており、ビルドが通りません。この問題はGitHubのissue</a>で2023年から報告されていますが、2026年2月現在もOpenのままです。リポジトリにZolaバイナリを同梱するワークアラウンドも提案されていますが、スマートとは言えないためこの案も断念しました。</p> 案3: Cloudflare Workers 静的アセット（採用）</strong>。最終的に採用したのが、Cloudflare Workersの静的アセット機能です。CloudflareはWorkersとPagesを統合する方針で、今後の機能開発はWorkersに集中されます。Workersの静的アセット機能は_headers</code>ファイルをネイティブにサポートしており、セキュリティヘッダーの設定が可能です。SSL証明書もCloudflareが一元管理するため更新の問題は発生しません。ビルドはGitHub Actionsで行い、wrangler deploy</code>でデプロイする構成にしました。Zolaのバージョンも自分で管理できます。</p> 移行手順は以下のとおりです。</p> Cloudflare DashboardのWorkers & Pagesから「Upload your static files」でプロジェクトを作成。後で上書きされるので適当なファイルを1つアップロードするだけでよい</li> 既存のGitHub Actionsワークフロー（deploy.yml</code>）を修正。Zolaのビルド部分はそのまま流用し、デプロイ先をCloudflare Workersに変更する。リポジトリにwrangler.toml</code>を追加し、GitHub Repository SecretsにCloudflareのアカウントIDとAPIトークンを登録</li> </ol> name</span>:</span> Deploy to Cloudflare Workers</span></span> </span> on</span>:</span></span> push</span>:</span></span> branches</span>:</span></span> -</span> main</span></span> workflow_dispatch</span>:</span></span> </span> permissions</span>:</span></span> contents</span>:</span> read</span></span> </span> concurrency</span>:</span></span> group</span>:</span> "deploy"</span></span> cancel-in-progress</span>:</span> false</span></span> </span> jobs</span>:</span></span> deploy</span>:</span></span> runs-on</span>:</span> ubuntu-latest</span></span> steps</span>:</span></span> -</span> name</span>:</span> Checkout</span></span> uses</span>:</span> actions/checkout@v4</span></span> with</span>:</span></span> submodules</span>:</span> recursive</span></span> </span> -</span> name</span>:</span> Setup Zola</span></span> uses</span>:</span> taiki-e/install-action@v2</span></span> with</span>:</span></span> tool</span>:</span> zola@0.22.1</span></span> </span> -</span> name</span>:</span> Build</span></span> run</span>:</span> zola build</span></span> </span> -</span> name</span>:</span> Deploy to Cloudflare</span></span> uses</span>:</span> cloudflare/wrangler-action@v3</span></span> with</span>:</span></span> apiToken</span>:</span> ${{ secrets.CLOUDFLARE_API_TOKEN }}</span></span> accountId</span>:</span> ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}</span></span> wranglerVersion</span>:</span> "4"</span></span> command</span>:</span> deploy</span></span></code></pre> Workersにカスタムドメインcodedchords.dev</code>を追加。CloudflareがDNSレコードを自動設定してくれる</li> GitHub Pagesを無効にする。Settings → PagesでSourceをNoneに変更するが、GitHub Actionsが選択されている状態ではNoneに変更できないため、一度Branchに切り替えてから設定する</li> </ol> 移転後はGoogle Search Consoleに新ドメインのプロパティを追加し、サイトマップを送信しました。</p> セキュリティヘッダーの設定</h2> Cloudflare Workersの静的アセット機能は、ビルド出力に_headers</code>ファイルを含めるとレスポンスヘッダーに自動適用します。Zolaのstatic/_headers</code>に以下を配置しました。</p> /*</span></span> X-Content-Type-Options: nosniff</span></span> X-Frame-Options: DENY</span></span> Referrer-Policy: strict-origin-when-cross-origin</span></span> Permissions-Policy: camera=(), microphone=(), geolocation=()</span></span></code></pre> CSPは見送りました。SoundCloud、YouTube、OpenStreetMap、GoatCounter、Giscus、はてなブログカードなど外部リソースが多く、許可リストの管理コストに対して静的サイトでの実益が限定的なためです。</p> 旧ドメインからの転送</h2> 旧ドメインへのアクセスを新ドメインに転送する必要があります。旧ドメインのDNSはFastMailで管理しておりCloudflareへの移行は行わないため、Cloudflare Redirect Rulesは使えません。</p> そこで、リダイレクト専用の静的サイトを生成する方法をとりました。Zolaでzola build</code>すると全ページのHTMLが生成されます。aliasesによるリダイレクトページも含まれるため、以前Next.jsで運用していた時代のパスもカバーされます。この全HTMLをmeta refreshリダイレクトページに差し替えて、別リポジトリに配置し、旧ドメインでGitHub Pages配信する構成です。</p> 各リダイレクトページの内容は以下のようになります。</p> <!DOCTYPE</span> html</span>></span></span> <</span>html</span>></span></span> <</span>head</span>></span></span> <</span>meta</span> charset</span>=</span>"utf-8"</span> /></span></span> <</span>link</span> rel</span>=</span>"canonical"</span> href</span>=</span>"https://codedchords.dev/（対応パス）"</span> /></span></span> <</span>meta</span></span> http-equiv</span>=</span>"refresh"</span></span> content</span>=</span>"0; url=https://codedchords.dev/（対応パス）"</span></span> /></span></span> </</span>head</span>></span></span> <</span>body</span>></</span>body</span>></span></span> </</span>html</span>></span></span></code></pre> Pythonスクリプトで、Zolaビルドからリダイレクトページの差し替え、不要ファイルの削除、CNAME配置までを一括実行しています。通常ページ367件とaliasページ226件、合計593件のリダイレクトを生成しました。aliasページはZolaが生成したmeta refreshのリダイレクト先（正規パス）を読み取り、新ドメインの正規パスに直接転送します。GitHub Actionsでデプロイを自動化しています。</p> この方法であれば全ページ・全パスをカバーできます。GitHub Pagesではサーバーサイドの301リダイレクトが設定できないため、meta refresh + canonicalの組み合わせが現実的な最善策です。FastMailのDNS変更も不要で、既存のCNAME/Aレコードをそのまま利用できます。</p> まとめ</h2> GitHub PagesからCloudflare Workersへの移転で得た知見をまとめます。</p> Cloudflare ProxyとGitHub Pagesの組み合わせでは、Let's Encrypt証明書のHTTP-01チャレンジを妨げるリスクがある</li> Cloudflare PagesのCI/CDはv2以降Zolaをサポートしていない（issue #3</a>は2023年からOpen）。GitHub Actions + wrangler deploy</code>で代替可能</li> Cloudflare Workersの静的アセット機能は_headers</code>ファイルでセキュリティヘッダーを簡単に設定できる</li> 旧ドメインからの転送は、meta refreshリダイレクトの静的サイトを生成する方法で全パスをカバーできる</li> </ul> .dev</code>ドメインのHSTSプリロードに加え、Cloudflare Workers側でセキュリティヘッダーも設定できるようになり、セキュリティスキャナーの警告も解消されました。</p> GitHub Pagesのセキュリティヘッダー警告、無視していいの？ 2026-02-06T00:00:00+00:00 </div> NOTE</strong> この記事は Zenn.dev</a> に掲載した記事の転載です。</p> </div> </div> TL;DR</h2> GitHub Pagesではセキュリティヘッダーを設定する機能がなく、スキャナーの警告がでる</li> セキュリティスキャナーの警告は「ベストプラクティス未達」であり「脆弱性」ではない</li> GitHub Pagesでは大抵静的サイトのため、放置しても実質的なリスクは低い</li> 自前でホスティングしたWordPressなどの動的サイトは必ず対応すべき</li> </ul> セキュリティヘッダーとは何か</h2> セキュリティスキャナーでよく指摘される6つのHTTPレスポンスヘッダーがあります。</p> ヘッダー</th> 目的</th> 設定しないリスク</th></tr></thead> Strict-Transport-Security (HSTS)</td> HTTPS接続を強制</td> HTTPへのダウングレード攻撃</td></tr> Content-Security-Policy (CSP)</td> XSS攻撃を防止</td> 悪意あるスクリプト実行</td></tr> X-Frame-Options</td> クリックジャッキング防止</td> 偽サイトへの埋め込み</td></tr> X-Content-Type-Options</td> MIMEスニッフィング防止</td> ファイル種別の誤認識</td></tr> Referrer-Policy</td> リファラー情報の制御</td> URLパラメータの漏洩</td></tr> Permissions-Policy</td> ブラウザ機能の制御</td> カメラ等の不正利用</td></tr> </tbody></table> これらのヘッダーは、Webサーバーがレスポンスに含めることで、ブラウザにセキュリティ関連の指示を与えます。</p> GitHub Pagesの制限</h2> GitHub Pagesは静的サイトホスティングサービスですが、 HTTPレスポンスヘッダーをカスタマイズする機能がありません</strong>。</p> .htaccess</code> は使えない（Apache設定ファイル）</li> nginx.conf</code> も使えない（Nginx設定ファイル）</li> GitHub側で固定されたヘッダーが返される</li> </ul> どうしてもセキュリティヘッダーを設定したい場合は、Cloudflare CDNを前段に置けばTransform Rulesでヘッダーを追加できます。ただし、Cloudflareの無料プランはネームサーバー移管が必須です。</p> 既存のDNSサービスを使い続けたい場合、この方法は採用しづらいです。</p> 静的サイトと動的サイトでリスクが違う</h2> セキュリティヘッダーの重要度は、サイトの種類によって大きく異なります。 GitHub Pagesでも動的なSPAをホストできますが、ここではZolaやHugoなどのSSGで生成した純粋な静的サイトを想定しています。</p> 観点</th> 静的サイト（SSG生成）</th> 動的サイト（WordPress等）</th></tr></thead> ユーザー入力</td> 受け付けない</td> フォーム等で受け付ける</td></tr> サーバーサイド処理</td> なし</td> PHP + DB</td></tr> 管理画面</td> なし</td> /wp-admin</code> 等が存在</td></tr> XSSリスク</td> ほぼなし</td> 高い</td></tr> クリックジャッキング</td> 影響軽微</td> 管理画面が標的になる</td></tr> </tbody></table> WordPressでセキュリティヘッダーが未設定の場合、管理者がログイン中にクリックジャッキング攻撃を受けたり、 XSS経由でマルウェアを注入されたりするリスクがあります。</p> 判断基準：いつ対応すべきか</h2> 以下のフローチャートで判断できます。</p>