100%AIで作られた会社ブログシステムの効果で、アクセス数が伸びまくっている

シンジです。タイトルは願望です。実際伸びてはいますが、短期間に複数の変更を同時に行ったので、何が要因でアクセスが伸びたとは言えないのですが、Webサイト、せっかく作るなら「超軽量」で「SEOもAEOも対策」してて「書きやすい」のはもちろん、「セキュリティ対策バッチリ」にしたいわけなので、それをやりましたよっていう全貌です。

この記事の3行まとめ

- 2026年3月7日にWordPressからAstro + Notion + AWS Amplifyへ完全移行してから2ヶ月半。検索流入（GSC実測）は日次平均でクリック+43%、表示回数+53%、平均掲載順位9.68→7.77に動きました。

- ただしこれは「移行したから伸びた」という単純な因果ではありません。同じ2ヶ月半に新規記事33本の公開・構造化データ整備・Core Web Vitals改善を並行しており、すべてが交絡しています。本記事は数値を出典付きで示し、解釈の限界も正直に書きます。

- 当社クラウドネイティブのブログサイトとして強調したいのは、セキュリティ運用の構造的な変化です。PHP・WordPress管理画面・データベース・プラグインという、WordPress由来の常時稼働する攻撃面が構造的に消えました。Notion・Amplify・CI/CD・npmサプライチェーン・計測タグといった攻撃面は別に残るため、それらの統制は別途必要です。

前回の記事（2026年3月7日公開）では、WordPressをやめてAstro + Notion + AWS Amplifyに移行した直後のコスト削減とアーキテクチャを解説しました。AIが全てを開発し、構築しています。

本記事はその続編です。移行から約2ヶ月半（2026年3月7日〜5月19日）の運用で「実際に何が起きたか」を、GSC・GA4・PageSpeed Insights・アクセスログ・リポジトリ履歴の自社実測データと、Astro / Google / AWSなどの公式ドキュメントを根拠に報告します。前回記事と重複する移行理由やコスト比較は最小限にとどめ、運用の継続・SEO/AEO施策・実測データ・Astro 6へのアップグレードという新しい論点に紙幅を割きます。

なお、本記事は「2ヶ月半の初動レポート」です。検索エンジンの評価は数ヶ月から年単位で動くため、ここで示す数字はあくまで短期間のスナップショットであり、最終結論ではありません。

1. 新ブログシステムで何が起きたか（数値サマリー先出し）

このセクションの3行まとめ

- 検索流入・サイト流入ともに日次平均では増加方向。

- パフォーマンスはPageSpeed Insightsの3回計測中央値で主要ページが緑域。

- セキュリティ面では、依存パッケージの既知脆弱性をゼロに保ったまま運用を継続。

移行後2ヶ月半の主要指標を先に出します。各数値の出典と但し書きは後続セクションで詳述します。

数字が動いた要因は移行だけではありません。この点はセクション5で正直に切り分けます。

2. 採用スタックの現在形：Astro 6 × Notion CMS × AWS Amplify

このセクションの3行まとめ

- データフローは「Notionで書く → StatusをPublishedに変える → 自動でビルド・デプロイ」の一本道です。

- 移行時はAstro 5系で稼働していましたが、2ヶ月半のあいだにAstro 6へアップグレードしました。

- Astro 6への移行はセキュリティ対応がきっかけで、コードの書き換えはほぼ発生しませんでした。

アーキテクチャ（現在形）

公開のデータフローは前回記事から変わっていません。執筆者がNotionに記事を書き、ステータスを「Published」に変えると、Notion AutomationがAWS AmplifyのWebhookを叩いてビルドが走り、静的ファイルが配信される、という流れです。

flowchart LR
  Author[執筆者] -->|記事作成 / Status=Published| Notion[(Notion CMS<br/>唯一のデータソース)]
  Notion -->|Automation Webhook| Amplify[AWS Amplify<br/>ビルド & ホスティング]
  Amplify -->|astro build + pagefind| Dist[静的ファイル<br/>HTML / JS / WebP]
  Dist --> CF[Amplify Hosting CDN配信]
  CF --> Reader[読者]
  Amplify -->|ビルド通知| Slack[Slack #notify-blog-cloudnative]

ポイントは、実行時にコードを動かすサーバーが一つも無いことです。読者に届くのは事前にビルドした静的ファイルだけで、Notion（外部SaaS）が編集と認証を引き受けます。このアーキテクチャがセキュリティ面で効いてくる話は、セクション6で詳述します。

Astro 5.x → 6.xへのアップグレード

移行公開時（2026年3月7日）はAstro 5系で稼働していました。その後5月15日にAstro 5.18.0 → 6.3.3へアップグレードしています。

きっかけは新機能ではなく、依存パッケージの既知脆弱性の解消でした。GitHubのDependabotがtransitive依存（Vite、h3、devalueほか）に複数の脆弱性アラートを出しており、これを根本から消すにはAstro本体のメジャーアップグレードが最短だったためです。アラートはhigh 6件・moderate 11件・low 3件の計20件ありましたが、アップグレード後はDependabot・npm audit ともに0件になりました。

注目すべきは、メジャーアップグレードにもかかわらず本ブログのコード書き換えがほぼ発生しなかったことです。Astro v6公式アップグレードガイド（"Upgrade to Astro v6"）が挙げる破壊的変更には、Astro.glob() の削除、<ViewTransitions /> コンポーネントの削除、Vite 7化、Node 22.12以上の要求などがあります。本ブログはこれらの削除対象APIを最初から使っていなかったため、影響を受けませんでした。

アップグレード後のビルドは正常に完走し（799ページ生成）、ユニットテスト33件もパスしました。実作業としては package.json の依存バージョンとlockfileを更新し、Astro 6が古いバージョンを引きずる一部パッケージを overrides で明示固定しただけです。

ここから言えることは、「メジャーアップグレードを脆弱性対応として淡々と実行できる」状態を保てているかが運用の質だ、ということです。フレームワークの選定時に「破壊的変更の影響範囲が小さい構成にしておく」ことが、後々のアップグレードコストを決めます。

なお、Astro 6の新機能（Zod 4対応や import.meta.env の挙動変更など）を本ブログで能動的に活用することはいまのところありません。

3. 移行後2ヶ月半に追加・改善した運用要素

このセクションの3行まとめ

- Notion CMSには「意図しない書き換えを防ぐ」ためのロック機構を足しました。

- ビルドパイプラインはキャッシュとNodeバージョンの最適化で短縮しました。

- OGP画像生成は「全記事生成でタイムアウト」する問題を、生成対象を絞ることで解消しました。

Notion CMSのチューニング

NotionをCMSにすると、Notion AIによる自動補完（Autofill）が便利な反面、SEO上は変えてはいけない値まで勝手に書き換えてしまうリスクがあります。これを防ぐため、2ヶ月半のあいだに次のロック機構を追加しました。

• Slugの不変性保証：URLはSEOの根幹なので絶対に変えません。Notion側の Locked Slug プロパティとリポジトリ内の slug-lock.json の二層で保護し、ビルド末尾で重複検査を走らせています。
• Excerpt（meta description）のロック：excerpt-lock.json で初回ビルド時の説明文を固定し、AI Autofillによる再生成を防ぎます。
• 著者プロフィールDBの新設：肩書き・経歴・SNSを別のNotion Databaseで管理し、記事ページと著者ページに表示。E-E-A-T（経験・専門性・権威性・信頼性）の観点で著者情報を明示しています。
• アイキャッチの代替テキスト（Eyecatch Alt）プロパティ：アクセシビリティと画像SEOのための代替テキストを運用入力できるようにしました。

ビルドパイプラインの継続改善

移行直後は、1記事更新するたびに起きるビルドに約25分かかっていました（外部画像の取得が累積するため）。記事をビルド時にキャッシュする3層構造（メモリ → ファイル → Notion API）を導入し、キャッシュヒット時にはNotion APIコールをゼロにしたことで、約77秒まで短縮しました。

さらに5月には、CIのNodeバージョン管理を見直し（Node 22 → 24 / Active LTS）、nvm install のオプションを最適化することで、通常時のビルドを3分47秒 → 2分43秒（約28%短縮）に改善しています。

現在の観測では、この構成のまま1分を切るのは現実的ではありません。Amplify Hostingのビルド前後処理・アーティファクト処理を含めた固定的な時間が約77秒あり、Astro build（約24秒）やPagefind（約12秒）を数秒削っても全体への効きは限定的でした。Amplifyを捨てることで実現可能ではあるものの、費用対効果を見て、CloudFront自前構成への移行などは見送りました。「速くできる限界」を見極めるのも運用判断です。

公開ペース

移行後2ヶ月半で新規に公開した記事は 33本（WordPress移行記事を除く、Notionでゼロから執筆したもの）。週あたり約3本強のペースです。執筆はNotion上で行い、公開はステータス変更ひとつ。インフラを意識せずに書き続けられる状態を維持できています。

note.cloudnative.co.jp の廃止と統合

別ドメインで運用していた note.cloudnative.co.jp（note pro契約、9記事）を、2026年4月30日に廃止し、blog.cloudnative.co.jp への301リダイレクトに統合しました。note側の記事は非公開化済みです。

統合した理由は3つあります。

(1)「コーポレートサイト」「技術ブログ」「note」と3つあったメディアをAstro+Notion基盤に集約し、執筆者の認知負荷と運用工数を下げる。

(2) 同じ会社のメディアを別ドメインで運用すると、E-E-A-Tや被リンクの観点で評価が分散する。

(3) note proの月額(当社契約時で月8万円)と、当社にとっての統合後メリットを比較したときに、当社の場合は割に合わなかった。

note pro自体の価値を否定したいわけではありません。プラットフォーム内のおすすめ枠で記事を露出してもらえる、公開フローの運用をある程度プラットフォーム側に委ねられる、という価値は実在します。ただし当社の場合は、自社コンテンツの強さと検索流入が既にあり、加えて今回構築したAstro+Notion基盤での執筆体験(Markdownの表が扱えるなど)も担保できたため、note pro側の価値が相対的に薄くなった、というだけの話です。プラットフォームに育ててもらうフェーズの組織には、依然としてnote proは良い選択肢だと考えています。

note側で記録されていた累計ビューは、9記事合計で59,181ビュー / 748スキ / 4コメントでした(2026-05-20時点、note管理画面より)。ただしこのうち約65%を「また病院がVPN経由でやられたわけだがVPNは悪だね」1記事(38,792ビュー)が占めており、これはnoteのおすすめ枠経由のバイラルが効いた特異値です。noteの「ビュー」はGA4のセッションともGSCのクリックとも測定対象が違うため、本記事の他の数値と同一スケールで並べないでください。あくまでnoteプラットフォーム内の参考値として併記したものです。

現在は全てのnote記事に301リダイレクトを設定しているので、note時代の被リンクは現ブログにシグナルとして引き継がれています。

4. SEO/AEO施策の実装詳細

このセクションの3行まとめ

- 構造化データ（JSON-LD）を @graph で統合し、全記事にBlogPostingとBreadcrumbListを出力しています。

- Core Web Vitalsはフォントの見直しが効き、主要ページでPageSpeedスコアが緑域に入りました。

- AEO（AI検索最適化）については、Googleの公式見解と自社の実測を両方正直に並べます。

構造化データ（JSON-LD）

移行初期は構造化データを個別の <script> タグに分散出力していましたが、5月15日に @graph 形式へ統合しました。記事ページでは BlogPosting + BreadcrumbList を基本に、本文にFAQがある記事では FAQPage を、サイト全体には Organization を出力しています。

実装上のハマりどころも共有します。当初FAQの検出をNotionのブロック構造から行っていましたが、ビルドキャッシュがヒットするとブロック配列が空になるため検出が機能しませんでした。レンダリング済みHTMLから検出する方式に切り替えて解決しています。キャッシュ前提のアーキテクチャでは「どの段階のデータを見るか」で挙動が変わる、という教訓です。

Core Web VitalsとPageSpeed Insightsの実測値

パフォーマンス改善で最も効いたのは、画像ではなくフォントでした。

当初は「画像が重い」という仮説で画像最適化を進めましたが、最も遅いページ（後述の claude mythos記事）はモバイルPerformanceが60から動きませんでした。真因は、約1.1MBの日本語（CJK）フォントサブセットがアイキャッチ画像のダウンロードと帯域を奪い合い、LCP（最大コンテンツの描画）を悪化させていたことでした。Latin部分だけをself-hostし、日本語はOSフォントに委譲する形に変えたところ、当該ページのモバイルPerformanceは60→99、LCPは約5.7秒短縮しました。

2026年5月20日にPageSpeed Insights API（3回計測の中央値）で再測定した主要ページのスコアは次のとおりです。

（出典：PageSpeed Insights、2026-05-20計測。CLSは全ページほぼ0.000）

正直な但し書きを3つ。

(1) 上の数字は3回計測の中央値です。単発ではDesktopで外れ値（セキュアブート記事で1回35、claude mythos速報記事で1回63）も出ており、スコア単体ではなくLCP / CLS / TBTとフィールド計測を併せて評価するのが妥当です。

(2) これは PSIのLab（ラボ＝合成環境）スコアであり、実ユーザーの体感値（CrUXフィールドデータ）とは異なります。実測のために web-vitals ライブラリでGA4へフィールド計測を送る仕組みも別途導入しました。

(3) INP（Interaction to Next Paint）はユーザー操作に依存する指標で、今回のPSI APIのLighthouse結果では inp_ms が null だったため、上表には含めていません。今後はCrUX / GA4への web-vitals 送信など、フィールド計測で評価します。

AEO（Answer Engine Optimization）：公式見解と実測の両論併記

AI検索（AI OverviewsやAI Mode）への最適化について、Googleの公式見解と本ブログの実測を、どちらも隠さず並べます。

Googleは「Optimizing your website for generative AI features on Google Search」で、次のように明言しています（いずれも公式ドキュメントからの引用）。

"You don't need to create new machine readable files, AI text files, markup, or Markdown to appear in generative AI search."

（生成 AI 検索に出るために、機械可読ファイルや AI 用テキスト、マークアップ、Markdown を新たに作る必要はない）

"Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add."

（生成 AI 検索に構造化データは必須ではなく、追加すべき特別な schema.org マークアップも存在しない）

"You don't need to write in a specific way just for generative AI search."

（生成 AI 検索のためだけに特別な文体で書く必要はない）

これを本ブログの運用方針に引き寄せて整理すると、少なくともGoogle検索に関しては「AEO専用の別施策」を作るより、通常のSEO基盤と一次体験に基づく良質な本文を整える方が筋がよい、という結論になります。決め手は非コモディティな良質コンテンツである、というのがシンジの理解です。

これを踏まえた本ブログの実測です。AI 検索向けの目印として llms.txt / llms-full.txt を用意してありますが、2026-05-06〜05-19 の14日間・全310万リクエストの AWS Amplify アクセスログを集計した結果、AI 系ボット( ChatGPT-User・GPTBot・ClaudeBot・PerplexityBot・OAI-SearchBot・Bytespider・meta-externalagent ほか11種、計34,281リクエスト )からこれらのファイルへのアクセスは1件も確認できませんでした。一方で同じ AI 系ボットは通常の記事HTMLは大量に取得しており、サイトが AI から無視されているわけではありません。読まれてはいるが、llms.txt という別経路は使われていない、というのが実測です。

(出典：AWS Amplify アクセスログ実測、2026-05-06〜05-19 UTC、計310万リクエスト中の集計)

この結果は Google公式が「生成AI検索のために新しい機械可読ファイルを作る必要はない」と明言している立場と整合的ですが、本データだけで「すべてのAI検索エンジンが恒久的にllms.txtを読まない」とまで一般化はできません。維持コストが低いので残してありますが、「これがAI検索対策になっている」という説明は事実に反するため、しません。

一方で、結論先出しの構成・質問形式の見出し・FAQセクションは、AI検索のためというより人間の読者にとって読みやすいから採用しています。構造化データも、AI検索のためではなく、通常の検索のリッチリザルト向けに正当な範囲で維持しています。目的を取り違えないことが大事だと考えています。

旧URLの301リダイレクト

WordPress 時代の記事は /数字/ 形式のURLを持っており、これらをAmplifyのリダイレクトルールで301として処理しています。静的サイトではHTTPステータスコードをアプリケーション実行時に返せないため、Astro側のHTMLベースの遷移に頼るのではなく、恒久移転をHTTPステータスとして明示できるCDN／ホスティング層で処理する設計にしました。Google公式もサーバーサイドの恒久リダイレクトを強い正規化シグナルとして扱うため、URL移行ではこの形が最も明確です。移行に伴って発生した旧URLの404を点検し、対象URLがすべて301経由で200を返すことを確認しました。

5. 実測データで見る2ヶ月半（最重要セクション）

このセクションの3行まとめ

- 検索（GSC）もサイト流入（GA4）も、日次平均では増加方向に動きました。

- ただし移行・新規記事・SEO施策が同時進行のため、これは相関であって「移行が原因」と断定はできません。

- 流入を牽引したのは、移行後に新規執筆したAI・セキュリティ系の記事群でした。

ここが本記事の核心です。まず因果と相関の区別を明確にしておきます。移行後2ヶ月半には、(a) WordPress → Astro移行、(b) 新規記事33本の公開、(c) 構造化データ・速度・内部リンクの改善、がすべて同じ期間に起きています。したがって、以下の数字の変化を「移行したから伸びた」と単純に結びつけることはできません。あくまで「移行後にこう動いた」という観測事実として読んでください。

GSC：検索パフォーマンス（日次平均で正規化）

出典は Google Search Console の実測値（2026-05-20 エクスポート、検索タイプ＝ウェブ）。Pre を 2025-10-01〜2026-03-06（157日）、Post を 2026-03-07〜2026-05-19（74日）とし、期間長の違いを打ち消すため日次平均に正規化しました。

表示回数とクリックが日次平均で増え、平均掲載順位も改善しました。CTRがわずかに下がっているのは、表示回数の伸びが（まだ順位が高くない長尾クエリも含めて）クリックの伸びを上回ったため、と整合的に説明できます。

検索クエリの中身も変化しました。Pre期間の上位は notion議事録 cursorプライバシーモード などでしたが、Post期間の上位は claude mythos copilot cowork mythos といった、移行後に書いたAIトピックのクエリが占めています。コンテンツの更新がクエリ構成に反映された形です。

GA4：トラフィックとチャネル（日次平均で正規化）

出典は GA4 の実測値（2026-05-20 エクスポート）。期間は GSC と揃え、Pre を 2025-10-01〜2026-03-06（157日）、Post を 2026-03-07〜2026-05-19（74日）としています。ただしひとつ但し書きがあります。GSC が測るのは検索結果のインプレッション／クリック、GA4 が測るのはサイト全体のセッションで、測定対象が異なります。したがって両者の絶対値を直接突き合わせて比較することには意味がありません。各データソース内での Pre/Post 比較として読んでください。

チャネル別のセッション構成（日次平均）は次のとおりです。

オーガニック検索が引き続き7割超を占める検索依存型のメディアであることは変わりません。一方で、Organic Socialが日次平均で約3.7倍（30→110/日）に増え、構成比でも 2.9%→7.4%に伸びています。

Claude mythos記事を中心とした流入分析

GA4 の Post 期間における上位ランディングページ（セッション数順）を見ると、流入を牽引しているのは移行後に新規執筆した記事群だとわかります。

（出典：GA4実測、Post期間。(not set) 行は除外）

特徴は2つ。(1) 上位はAIとセキュリティのトピックに集中しています。当社の専門領域と検索需要が重なった記事が伸びている、という素直な結果です。(2) 新規ユーザー数がセッション数に対して非常に高い比率を占めています（claude mythos記事は約87%、11,497 / 13,204）。新しい読者の入口として機能しています。

同時に、WordPress移行記事（/27745/ など数字URLの記事）も上位に残っており、新規記事も移行記事も両方が流入を支えています。「古い移行記事は価値が低い」という思い込みは、データ上は当たっていませんでした。

Google Discoverの実態

移行後の Discover 流入を確認するため、GSC の Discover レポートも取得しました。Discover 確認期間(2026-03-06〜2026-05-19)の実測値は次のとおりです。

(出典：GSC Discoverレポート、2026-05-20エクスポート)

ウェブ検索のPost期間CTR(2.90%)と比べると、DiscoverのCTRは約2.7倍高い数値です。ユーザーのフィードに合致して表示された記事はクリック率が高い、というDiscoverの性質が反映されています。

ただし、特定の1記事と特定の3日間に流入が極端に集中しているのが内訳です。

生成AI生産性パラドックス記事1本で クリック全体の95.5% を占めています。さらに日次推移を見ると、2026-03-31〜04-02の3日間でクリック合計の約96%が発生(3-31だけで3,196クリック / 38,397表示)し、その後5月にかけてDiscoverからの流入は実質的にゼロまで戻りました。国別でも日本が 98.3% で、海外フィードへの波及はほぼありませんでした。

つまりDiscoverに「継続的に効いている」のではなく、特定の1記事が短期間アルゴリズムの波に乗った結果、というのが実態に近い解釈です。CTRが高いのも、フィードに表示された母集団が(短期バイラルにより)関心の強い読者層に絞られていたため、と説明できます。

Discoverからの流入は数字としては無視できない規模でしたが、再現性のある成果として扱うべきではありません。Discoverのアルゴリズムは編集者にとってブラックボックスで、コントロールが効きません。本ブログとしては、検索からの安定的な流入を主軸とし、Discoverは「たまたま乗ったら加算される」チャネルとして位置づけます。

6. セキュリティ観点での効用

このセクションの3行まとめ

- WordPress が構造的に抱えていた攻撃面（PHP・データベース・プラグイン・管理画面）は、静的サイト化によって配信面から消えました。

- 依存パッケージの既知脆弱性は、Dependabotとメジャーアップグレードの運用でゼロに保っています。

- セキュリティヘッダーやCSPは導入済みですが、未完の部分も正直に書きます。

ゼロトラストやSaaSセキュリティを生業とする会社のブログとして、ここは正確に書きます。誇張も過小評価もしません。

消えた攻撃面（構造的な事実）

WordPress は、PHP ランタイム・MySQL・プラグイン・管理画面（wp-login.php / wp-admin）が常時稼働するスタックです。これは WordPress が悪いという話ではなく、動的 CMS というアーキテクチャ上、それぞれが独立した更新・脆弱性管理の対象になり、恒常的なパッチ運用が必要になる、という構造の話です。

移行後のスタックには、PHPもデータベースも管理画面もありません。読者に配信されるのは事前ビルド済みの静的ファイルだけで、編集と認証は外部SaaSのNotionに分離されています。

ここで表現を正確にします。「移行したらログイン試行がゼロになった」と言いたくなりますが、それは不正確です。正しくは、ログイン画面という攻撃面そのものが存在しない、です。wp-login.php のような恒常的なブルートフォースの標的が構造的に無いため、「ゼロ」という計測値を出すまでもなく、攻撃の対象になるエンドポイントが消えています。攻撃試行の件数比較のような実測ログは本記事では取得していないので、件数の増減は主張しません。あくまで「攻撃面が構造的に縮小した」という事実までにとどめます。

加えて、2026年4月末に note.cloudnative.co.jp を廃止して当ブログに統合した(セクション3で詳述)結果、管理対象の外部SaaSと公開権限の管理対象が1つ減りました。サプライチェーン監視対象や認証情報の管理対象も縮小しており、これも運用ガバナンスとしては小さくない効用です。

サプライチェーンと依存管理

静的サイトでも、ビルド時に使う依存パッケージはサプライチェーンのリスク源です。ここは運用で守ります。

• 既知脆弱性をゼロに保つ：セクション2で書いたAstro 5→6アップグレードが好例です。Dependabotの20件（high 6 / moderate 11 / low 3）を、メジャーアップグレードで一気にゼロにしました。
• ビルドの再現性：依存のインストールを npm install から npm ci（lockfile固定）に変え、Astroが引きずる一部パッケージは overrides でバージョンを明示固定しています。
• 環境変数の取り違え防止：CI環境では .env の上書きを無効化するガードを入れ、ローカルの設定が本番ビルドに混入しないようにしています。

セキュリティヘッダーとCSP

HSTS、X-Content-Type-Options、X-Frame-Options、Referrer-Policy、Permissions-Policy などのセキュリティヘッダーは、Amplifyの customHttp.yml で全パスに配信しています。

CSP（Content Security Policy）は、まずReport-Onlyモードで実トラフィックの違反を観測してかEnforce（強制）モードへ段階的に移行しました。現在は default-src 'self' を基本に、object-src 'none'、frame-ancestors 'self' などを強制しています。

ただし、正直に書くべき残課題があります。現在のCSPには script-src と style-src に 'unsafe-inline' が残っています。これはXSS防御の観点では本来撤廃したい部分です。

撤廃を阻んでいる本当の壁は、(a) 記事ごとに動的に変わる JSON-LD ブロックと、(b) WordPress から移行した Notion 本文の style="..." 属性(約14,700件)です。とくに後者を style-src-attr のハッシュ列挙で塞ごうとすると、CloudFront のヘッダーサイズ上限に抵触します。当初は Astro のスコープ付き CSS も壁になると見ていましたが、実測ではビルド時に8ハッシュへ収束するため、こちらは問題になりませんでした。

撤廃自体は実現可能で、script-src 側はインラインスクリプトを外部 .ts 化して 'unsafe-inline' を外す、style-src 側はscoped styleのハッシュ自動注入と style-src-attr 'unsafe-inline' 温存を併用するハイブリッド案を社内で設計済みです。ただし現時点では意図的に実装を後回しにしています。残存する攻撃経路が「NOTION_API_KEY 漏洩 → 編集権限取得 → 本文へのインラインスクリプト注入」という直列に絞られ、その手前のNotionトークン保護のほうが一次防御として効くこと、object-src 'none' / base-uri 'self' / frame-ancestors 'self' で攻撃面を限定済みであること、編集権限が社内メンバーに限定されていることから、実セキュリティROIが限定的という判断です。「CSPを入れたからXSSは完全に防げている」とは、現時点では言えません。

加えて、HSTS preload は提出ドメイン配下のサブドメイン全体に影響するため、blog.cloudnative.co.jp 単体の技術対応だけでは判断できません。cloudnative.co.jp 全体の HTTPS 運用方針とサブドメイン棚卸しを終えてから申請可否を判断する必要があり、現時点では list への登録自体はまだ行っていません。あまり効果も期待できないように思います。

7. まとめ

移行から2ヶ月半。検索流入もサイト流入も日次平均では増加方向に動き、主要ページの速度は緑域に入り、依存パッケージの既知脆弱性はゼロを保っています。

数字が動いた要因は移行・新規記事・SEO施策が交絡しており、「移行が原因で伸びた」と単純化はできません。本記事の価値は、派手な成功譚ではなく、短期間の運用で何を実装し、データがどう動き、何がまだ未完なのかを出典付きで開示したことにあると考えています。

WordPress をやめて静的サイトにしたことの一番の効用は、PVの増加そのものよりも、「インフラの脆弱性管理に追われず、コンテンツに集中できる状態」と「WordPress由来の常時稼働する攻撃面が構造的に縮小した状態」を同時に手に入れたことだと、2ヶ月半運用してみて実感しています。

何よりも、AIに読まれるサイトを、AIが作っているというところも時代を感じるポイントです。

付録：関連リソース

• 前回記事：WordPressをやめてAstro + Notionに移行した話（コスト削減・アーキテクチャ編）
• Astro v6公式アップグレードガイド
• Google：生成AI検索向けの最適化ガイド