記事更新の自動化は「品質ゲート」で決まる｜公開前の7つの関門と28項目チェックリスト（2026年）

「記事の更新を自動化したい」という相談では、話の中心がすぐに「AIでどれだけ速く書けるか」に移ります。けれども、実際に運用を始めてから困るのは、書く速さではありません。書き上がったものを、誰が、何を見て、公開してよいと決めるのかが決まっていないことです。

書く工程を自動化すると、記事は増えます。確認が人の注意力だけに頼っていると、誤った数値、切れたリンク、誤った説明文、代替テキストのない画像、スマートフォンで崩れる表といった見落としも、本数に比例して増えます。

この記事では、記事の制作から公開までを一本の流れ（パイプライン）として捉え、その途中に置く品質ゲート（公開前に通過を求める関門）の作り方を整理します。作業の棚卸しから自動化の範囲を決める方法は、別の記事「サイト運用のAI・自動化は棚卸しから」で扱いました。今回はその続きとして、記事の更新に絞って、もう一段具体的に書きます。

この記事が主に根拠にした情報：Google Search Central のスパムポリシー（2026年8月28日更新）と「ユーザー第一のコンテンツ」（2026年10月5日更新）、Pew Research Center のリンク切れ調査（2024年5月）、WebAIM Million 2026年版、web.dev の Web Vitals。

1. いま何が起きているか：量産への対策と、壊れていくウェブ

ここ2〜3年で、検索エンジンもウェブそのものも、「数を出せば届く」とは言いにくい方向に動いています。目立つのは、量産への対策、切れていくリンク、減らないアクセシビリティの問題の3つです。

Google は「低品質で独自性のない内容」を45%減らしたと発表

Google は2024年3月5日、コアアップデートと新しいスパムポリシーを発表しました。このとき、検索結果の低品質で独自性のない内容を40%減らす見込みだと説明し、同年4月26日の追記で、実際には45%減ったと報告しています。

同じ発表で加わったのが「大規模なコンテンツの不正使用（scaled content abuse）」というポリシーです。自動化か人手か、その組み合わせかを問わず、順位を操作する目的で大量のコンテンツを作ることを対象にしています。記事更新の自動化は、この線の手前にとどまるように設計する必要があります。

2013年のページの38%は、もう見られない

Pew Research Center が2024年5月17日に公表した調査では、2013年に存在したウェブページの38%が、調査時点で見られなくなっていました。2023年のページでも8%がすでに消えていました。

記事の中のリンクも同じで、ニュースサイトのページの23%、政府機関のページの21%に1本以上のリンク切れがあり、Wikipedia のページの54%に切れた参考文献のリンクがありました。出典を丁寧に張る記事ほど、リンク切れを抱えます。

アクセシビリティの問題は、むしろ増えている

WebAIM は毎年、100万サイトのトップページを自動で検査しています。2026年2月の調査では、95.9%のページで WCAG 2 の不適合が検出され、1ページあたりの検出エラーは平均56.1件でした。2025年はそれぞれ94.8%と51件で、悪化しています。

最も多いのは文字と背景のコントラスト不足で、83.9%のページにありました。上位6種類のエラーを図にまとめます。

低コントラスト以外のエラーは記事の更新のたびに入り込みうるもので、公開前の関門で機械的に止められる種類のエラーです。

2. 記事更新の自動化で、自動にするもの・しないもの

記事の公開までの工程を「機械に任せる作業」と「人が持つ判断」に分けると、関門の置き場所が自然に決まります。基準は、前回の記事で整理したものと同じです。正解が外から決まっているか、失敗したときに戻せるか。リンクが200を返すかどうかは外から決まりますが、ある数値が今も正しいかどうかは、人が出典を見ないと決まりません。

右の列が空になる工程はありません。自動化の目的は、人が判断に使える時間を増やすことです。

「全自動公開」を勧めない理由

AIが書いた記事をそのまま公開する仕組みは、技術的には数時間で作れます。Google が公開前に人が事実確認とレビューを行うことが重要だと明記していることに加え、誤った情報は公開した瞬間に検索エンジンやAIの回答に拾われることがあり、ページを戻しても拾われた情報は戻りません。新しい記事も、数値の更新も、誤字の修正も「サイトへの1つの変更」として扱えば、同じ関門を通せ、バージョン管理・テスト・ロールバックといったソフトウェア開発の道具がそのまま使えます。

3. 品質ゲートとは何か：7つの関門の全体像

品質ゲートは、公開の前に必ず通らなければならない検査の集まりです。ソフトウェア開発では「テストが通らなければ本番に出さない」という形で広く使われています。記事の運用に当てはめると、次の7つの関門になります。リンクやテストはほぼ機械で済み、事実確認と承認はほとんど人の仕事です。

この表で大事なのは右の列です。「落ちたらどうなるか」が決まっていない検査は、関門ではなく参考情報にすぎません。警告が出ても公開できる仕組みでは、警告はやがて誰も見なくなります。

「止める検査」と「知らせる検査」を分ける

すべての検査で公開を止めると、運用が回らなくなります。結果が明確で誤検出が少ないもの（リンク切れ、構造化データの文法エラー、ビルドの失敗）は止める検査に、判断の余地があるもの（表示の差分、速度のわずかな悪化）は知らせる検査にして、承認者の判断材料にします。

4. 関門1：事実確認（数値・固有名詞・日付・出典）

最初の関門は、最も自動化しにくい事実確認です。AIが書いた文章は、もっともらしいが誤っている数値や、存在しない出典を含むことがあります。Google も、生成AIは事実を取り出すのではなく、ありそうな単語の並びを予測しているため誤りうる、と説明しています。

この関門の目的は、記事の中の「確かめられる主張」をすべて一覧にし、それぞれに出典を対応させることです。

確かめる対象を機械に抜き出させる

確認する対象を探す作業は自動化できます。数字、日付、割合、金額、固有名詞、法令名、「〜によると」の文を機械で抜き出し、一覧にします。

料金や制度の数値に次に確認する日を書いておくと、古い数値のまま残る記事が減ります。

出典は「一次情報」まで遡る

調査を紹介したニュース記事は、数値を丸めたり調査年を書き落としたりしていることがあります。原典（調査会社、当局、規格の発行元）まで遡り、原典のURLを出典にします。見つからなければ使わないか、「〜と報じられています」と出典つきで書き、判断した人と日付を記録します。

AIに「事実を確認して」と頼むと、確認したような文章が返ってきますが、それは確認の記録ではありません。AIに任せてよいのは抜き出しと突き合わせの補助までで、「正しい」と判断するのは出典のページを自分で開いた人です。

5. 関門2：リンクの確認（リンク切れ・リダイレクト・内部リンク）

2つ目の関門は、最も自動化しやすいリンクの確認です。すべてのリンクのステータスコードを確かめます。リンクは時間とともに切れるので、公開済みの記事の定期的な検査も必要です。

ステータスコードごとの扱い

Google のドキュメントでは、429を除く4xxのエラーは同じように扱われ、インデックスから外されると説明されています。301（恒久的な転送）は強いシグナル、302（一時的な転送）は弱いシグナルとして扱われます。

429や5xxは、相手のサーバーの一時的な事情で公開が止まらないよう「知らせる」にし、2回続けて失敗したら止めます。

使える道具と内部リンク

リンクの検査は無料の道具で始められます。手で回すなら W3C Link Checker、自動化の仕組み（CI）に組み込むならファイル単位で検査できる lychee が使いやすく、自サイトの404や「ソフト404」（正常を返しながら中身がエラーのページ）は Google Search Console が知らせてくれます。

内部リンクも確認対象です。記事を消すときは、その記事へリンクしている記事の一覧を先に出し、URLを変えるときは古いURLから301で転送します。

6. 関門3：構造化データとメタ情報

3つ目の関門は、検索結果やSNS、AIの回答に出る情報の確認です。タイトル、ディスクリプション、構造化データ、画像の代替テキストは、本文以上に多くの人の目に触れます。Google の「生成AIコンテンツの使い方」も、これらのメタ情報を事実確認とレビューの対象に挙げています。

構造化データは、機械による文法の検査と、人による内容の確認の両方が必要です。

Google の一般的なガイドラインが求めること

Google の一般的なガイドラインは、ページに見えていない内容をマークアップしないこと、種類ごとの必須プロパティを入れること、Rich Results Test と URL 検査ツールで確かめること（通っても誤りが残ることはある）を求めています。違反には手動による対策が取られ、リッチリザルトの対象から外れることがあります。

記事の構造化データと日付

記事には Article や BlogPosting（Schema.org の型）を使います。Google の記事の構造化データのページでは、必須のプロパティはなく、headline、image、datePublished、dateModified、author などを推奨としています。著者は1人ずつ別の author として書き、名前の欄に肩書きや会社名を混ぜないよう求めています。

dateModified には注意が必要です。Google は表示する日付と構造化データの日付を一致させるよう求め、「ユーザー第一のコンテンツ」のページは、内容をほとんど変えずに日付だけを新しくすることを、検索エンジン向けのコンテンツの兆候として挙げています。自動化の仕組みが、ファイルを保存しただけで更新日を書き換えていないかを確かめてください。

サイトマップの lastmod も同じで、Google は「一貫して、検証できる形で正確」な場合にだけ使うと説明しています。著作権表示の年の更新は大きな変更に当たらず、priority と changefreq は無視されます。

FAQ の構造化データをどうするか

Google は2023年8月に FAQ リッチリザルトを著名な政府・健康関連サイトに絞り、2026年5月7日からは表示しなくなりました（ドキュメントも同年6月15日に削除）。検索結果の見た目のために FAQ を足す理由はほぼなくなりました。それでも入れる場合は、本文に見えている質問と答えだけを、本文と一字一句そろえてマークアップするのが安全です。

7. 関門4：アクセシビリティ

4つ目の関門は、障害のある人を含む誰もが記事を読めるかの確認です。図1のとおりエラーは減っておらず、しかも自動の検査でわかる範囲には限りがあります。

自動検査で見つかるのは、問題の半分強

axe-core を開発する Deque は、1万3,000以上のページと約30万件の問題を分析し、自動テストで見つかる問題は57.38%だったと報告しています。W3C の WAI（Web Accessibility Initiative）も、評価ツールは判定を手助けするだけだと説明しています。「エラー0件」は合格ではありません。

コントラスト比の基準は、WCAG 2.2 の達成基準1.4.3（レベルAA）で、通常の文字は4.5:1以上、大きな文字（18ポイント以上、または14ポイント以上の太字）は3:1以上です。基準は切り上げずに判定するので、4.499:1は不合格です。

記事ごとに入り込みやすい4つ

DevNJ が見てきた範囲では、記事の更新で入り込むエラーは、空またはファイル名のままの代替テキスト、h2 の次に h4 が来る見出し、「こちら」のようなリンクの文言、文字を画像にした図の4つがほとんどです。この記事の図をSVGで書き、説明文を付けているのも、4つ目を避けるためです。

8. 関門5：表示確認と表示速度

5つ目の関門は、記事が実際の画面でどう見えるかの確認です。編集画面で正しく見えても、公開ページでは表がはみ出したり、重い画像で遅くなったりします。

見た目の確認：スクリーンショットの差分

見た目の確認は、スクリーンショットを基準画像と比べて行います（たとえば Playwright の toHaveScreenshot）。ただし表示はOS、ブラウザ、設定、ハードウェアで変わるため、Playwright は基準画像を同じ環境で作って比べるよう勧めています。

記事の運用では、新しい記事、記事の一覧ページ、表や図を多く含む代表的な記事1本の3つを、スマートフォン幅（375px）とパソコン幅で撮れば足ります。差分が意図した変更か崩れかを決めるのは人なので、これは「知らせる検査」です。

速さの確認：Core Web Vitals の基準

表示の速さは、web.dev が示す Core Web Vitals で見ます。LCP（最も大きな要素が表示されるまでの時間）は2.5秒以下、INP（操作への応答）は200ミリ秒以下、CLS（レイアウトのずれ）は0.1以下が「良好」です。判定は、実際の利用者の読み込みの75パーセンタイルで、スマートフォンとパソコンを分けて行います。

公開前に使えるのは実験環境の「ラボデータ」です。Lighthouse は LCP と CLS を測れますが、INP は測れず、TBT（合計ブロック時間）で代用します。公開前はラボデータで大きな悪化を止め、公開後は実際の利用者のデータ（フィールドデータ）で確かめる、という二段構えになります。

記事の更新で表示速度を悪くする原因の多くは、大きすぎる画像です。画像1枚あたりのファイルサイズの上限（たとえば300KB）を決めて、超えたら止める検査にすると、速度の悪化をかなり防げます。この上限は DevNJ の目安で、サイトの作りによって変わります。

9. 関門6：テスト（ビルド・HTML・既存機能）

6つ目の関門は、記事の追加がサイト全体を壊していないかの確認です。記事は一つのファイルでも、一覧ページ、タグのページ、サイトマップ、言語の切り替えなど、多くの部品に影響します。

記事の運用で回すテスト

DevNJ のコラムでも、必須項目、日英の対、図の文字のはみ出しを公開前にスクリプトで確かめています。数十行で書ける検査ですが、人が毎回目で確かめるより確実です。

自動化の基盤と費用

テストを自動で回す仕組みは CI（継続的インテグレーション）と呼ばれます。代表的な GitHub Actions は、公開リポジトリなら標準の実行環境が無料で、非公開リポジトリでも GitHub Free で月2,000分、Pro と Team で月3,000分の無料枠があります。超えた分は、Linux の2コアで1分0.006ドルです。記事の検査は数分で終わるため、月に数十本の更新なら無料枠に収まるのが普通です。

DORA の指標の「変更の失敗率（デプロイのうち、直後に対応が必要になった割合）」も使えます。公開後に修正や取り下げが必要になった記事の割合を数えてください。

10. 関門7：承認とロールバック

最後の関門は人の判断です。6つの関門を通っても、公開してよいかを決めるのは人です。そして、すぐに戻せる状態を用意しておくことが、この関門のもう半分です。

リスクに応じて承認者の数を変える

すべての変更に同じ承認を求めると、誤字の修正に1日かかり、承認が形だけになります。

「緊急」では関門の一部を飛ばせますが、飛ばしたことを記録し、24時間以内に通し直すことを条件にします。例外の通り道がないと、急ぎのたびに仕組みの外で公開されます。

ロールバックは「手順」ではなく「ボタン」にする

ロールバック（元の状態に戻すこと）は、障害が起きてから手順書を探すようでは間に合いません。記事を Git などで管理していれば、直前の変更を取り消して再公開するだけで戻せます。DevNJ の目安は、戻すと決めてから15分以内に戻せることです。DORA の「失敗したデプロイからの復旧時間」に当たり、実際の時間を記録すると弱いところが見えてきます。

最後の「振り返り」を点線にしたのは、忙しいと最初に省かれる工程だからです。差し戻しの理由の記録は、関門のほうを改善する手がかりになります。

11. Google の方針と品質ゲートの関係

ここで、最も気になる Google の評価との関係を整理します。結論は、AIを使ったかどうかでは評価は変わらないが、価値を足さない量産は問題になるということです。品質ゲートは、この線の手前にとどまるための仕組みでもあります。

「大規模なコンテンツの不正使用」の定義

Google のスパムポリシー（2026年8月28日更新）は、大規模なコンテンツの不正使用を「利用者の役に立つためではなく、主に検索順位を操作する目的で多数のページを生成すること」と定義し、作り方は問わないとしています。例には、生成AIで価値を足さずに多数のページを作ること、スクレイピングした内容を同義語への置き換えや翻訳などの自動変換で量産すること、複数のページを価値を足さずにつなぎ合わせることが挙がっています。

多言語サイトを運用している事業者は、「翻訳」が自動変換の例として明記されていることに注意してください。日本語の記事を機械翻訳しただけの英語版を並べると、この例に近づきます。

「人を第一に考えたコンテンツ」の問い

Google の「有用で信頼性の高い、ユーザー第一のコンテンツの作成」（2026年10月5日更新）は、コンテンツを「誰が、どのように、なぜ」作ったかを問うよう勧めています。中でも「なぜ」が最も重要で、検索からの訪問を集めることが主な目的であってはならないとしています。

AIが内容の大部分を生成した場合は、読者が知りたい場面ではそれを説明するよう勧め、AIの顔写真や架空の経歴で著者を装うことは欺瞞としています。

方針を関門に置き換える

Google は好ましい文字数はないとし、特定の文字数に合わせて書くことを検索エンジン向けの兆候に挙げています。文字数を満たすために中身を薄めるのは逆効果です。

12. 費用と工数の幅

費用は、どこまで自動にするかで変わります。いずれも DevNJ の目安で、実測の統計ではなく、サイトの作りと本数で上下します。円は1ユーロ＝約176円（欧州中央銀行の参照レート、2026年10月22日）で換算しています。

3つの段階

月額は CI の実行時間、プレビュー環境、監視の道具の利用料で、段階2は無料枠に収まることも多くあります。外注する場合は、時間単価で総額が大きく変わります。仮に時間単価80ユーロとすると、段階1は320〜640ユーロ（約5.6万〜11万円）、段階2は1,280〜2,560ユーロ（約23万〜45万円）、段階3は3,200〜6,400ユーロ（約56万〜113万円）になります。

1本あたりの確認時間はどう変わるか

次の表は、日英2言語で月4本を公開するモデルサイトで、1本あたりの確認時間を見積もったものです（DevNJ の目安）。

減るのは機械で判定できる関門で、事実確認と承認の時間はほとんど減りません。月4本の日英なら、1か月で約7時間（95分－40分＝55分×8ページ）が浮く計算です。この時間を本数を増やすことに使うか、事実確認を厚くすることに使うかは、運用の方針として決めておきます。

13. よくある失敗

DevNJ が見てきた失敗をまとめます。いずれも、仕組みそのものではなく、仕組みの周りの決めごとが抜けていたことが原因です。

最も多いのは1行目です。検査の数を増やすより、出た警告に必ず誰かが対応する状態を保つほうが効きます。

14. 日本と欧州で比べる

日本と欧州の両方に記事を出す事業者は、関門を両方の前提に合わせる必要があります。ここでは記事の運用に関係する範囲だけを比べます。個別の判断は専門家に確認してください。

AI法では、公共の関心事を伝えるAI生成の文章でも、人が確認し編集上の責任を持つ場合は表示の対象外とされています（棚卸しの記事の第8章を参照）。関門1と7で確認者と承認者を記録しておくことが、その説明になります。

日本では、記事の中に商品やサービスの紹介を含む場合、景品表示法のステルスマーケティング規制（2023年10月1日施行）が関係します。外部に記事を依頼したり、AIに比較記事を書かせたりするときは、広告であることが読者に分かる表示を関門のチェック項目に入れておきます。

15. ケースで考える（架空の3社）

説明のために作った架空の3社（実在の企業ではありません）で、規模・本数・リスクによって合う段階が変わることを見ます。

A社は、いきなり仕組みを作るより、28項目を1〜2か月手で回し、実際に止まった項目から自動化するのが近道です。B社は価格の誤りがそのまま苦情につながるため、価格を最重要の確認項目にし、オランダ語を読める人がいない時期はオランダ語版の公開を止める判断も選択肢です。C社はすべての記事を「重要」に分類して2名で承認し、段階3の投資は、誤った記事を1本出したときの損失と比べて判断します。

16. 導入の手順

品質ゲートを導入する手順を、8つにまとめます。最初の4つは道具を使わずにできます。

1. 公開の流れを書き出す。いま、誰が、どの順番で、何を確かめて公開しているかを1枚にまとめる
2. 過去の差し戻しと修正を集める。直近半年で公開後に直した記事と、その理由を一覧にする
3. 28項目のチェックリストを自社用に削る。関係ない項目を外し、足りない項目を足す
4. 「止める」「知らせる」を決める。項目ごとに、落ちたら公開を止めるかを決める
5. 手で1〜2か月回す。記事ごとにチェックリストを付け、止まった項目を記録する
6. 止まった実績のある項目から自動化する。リンク、構造化データ、ビルドから始めるのが無難
7. 承認とロールバックを決める。リスク別の承認者と、戻す手順を書き、1回練習する
8. 月1回、数字で見直す。差し戻しの件数、公開後の修正の割合、復旧にかかった時間を見る

手順6は、使われない検査を作らないための順番です。

17. チェックリスト（7つの関門×4項目＝28項目）

公開前に確かめる28項目です。自社の運用に合わせて削り、足りないものを足して使ってください。

関門1：事実確認

• 数値・日付・固有名詞・法令名を一覧にした
• すべての数値に原典（一次情報）のURLがある
• 確認者の名前と確認日を記録した
• 料金や制度の数値に、次に確認する日を決めた

関門2：リンク

• 記事内のリンクがすべて200を返す（転送は書き換えた）
• 404・410のリンクは差し替えたか外した
• 内部リンクの行き先が存在する
• 公開済み記事の月1回の全件検査が動いている

関門3：構造化データとメタ情報

• JSON-LD が Rich Results Test などで文法エラーなしと出る
• 構造化データの内容が、ページに見えている内容と一致する
• title とディスクリプションを人が読み、誇張がない
• dateModified は内容を変えたときだけ動いている

関門4：アクセシビリティ

• すべての画像に、意味を伝える代替テキストがある
• 見出しの階層が飛んでいない
• 文字と背景のコントラスト比が4.5:1以上（大きな文字は3:1以上）
• リンクの文言だけで行き先が分かる

関門5：表示確認と表示速度

• スマートフォン幅（375px）とパソコン幅で表示を確かめた
• 表や図が画面からはみ出していない
• 画像1枚あたりのファイルサイズが上限以内
• Lighthouse の LCP・CLS が前回から大きく悪化していない

関門6：テスト

• サイトのビルドが最後まで通る
• front matter の必須項目と形式が正しい
• HTML の妥当性の検査でエラーがない
• 他の言語版との対と hreflang が正しい

関門7：承認とロールバック

• 変更のリスク区分を決め、必要な人数が承認した
• AIが下書きした部分を承認者が把握している
• 直前の版に戻す手順があり、15分以内に戻せる
• 公開後15分・24時間・7日の確認の担当が決まっている

18. まとめ

• 記事更新の自動化は、書く工程より先に、公開前の関門を決めることから始める
• 機械で判定できるものは自動で回して止め、数値が正しいか、公開してよいか、戻すかの判断は人に残す
• Google はAIの利用自体を問わないが、価値を足さない量産、自動翻訳での量産、日付だけの更新は問題になる
• 費用は3段階で初期4〜80時間。1本あたりの確認はおおむね95分から40分前後に減るが、事実確認と承認の時間は減らさない
• 28項目のチェックリストを1〜2か月手で回し、止まった実績のある項目から自動化する

参考にした情報源

Google の方針（Google Search Central・Google）

• Spam policies for Google web search — Google Search Central：大規模なコンテンツの不正使用の定義と例（2026年8月28日更新）
• Creating helpful, reliable, people-first content — Google Search Central：「誰が・どのように・なぜ」、日付の更新、文字数（2026年10月5日更新）
• Guidance on using generative AI content on your website — Google Search Central：公開前の事実確認、メタ情報と構造化データの確認
• New ways we're tackling spammy, low-quality content on Search — Google：2024年3月の発表、低品質な内容の45%減
• General structured data guidelines — Google Search Central：見えない内容をマークアップしない、検証、手動による対策
• Article structured data — Google Search Central：推奨プロパティと著者の書き方
• Influence your byline dates in Google Search — Google Search Central：表示する日付と構造化データの日付
• Build and submit a sitemap — Google Search Central：lastmod の扱い、サイトマップの上限
• How HTTP status codes, and network and DNS errors affect Google Search — Google Search Central：4xx・5xx・転送の扱い
• Changes to HowTo and FAQ rich results — Google Search Central Blog：2023年8月の FAQ・HowTo の変更
• Latest Google Search documentation updates — Google Search Central：FAQ リッチリザルトの終了（2026年5月7日）
• Rich Results Test — Google：構造化データの検証

ウェブの品質・アクセシビリティ（web.dev・W3C・Schema.org）

• Web Vitals — web.dev：LCP・INP・CLS の基準、75パーセンタイル、ラボとフィールド
• Understanding Success Criterion 1.4.3: Contrast (Minimum) — W3C：コントラスト比4.5:1と3:1
• Selecting Web Accessibility Evaluation Tools — W3C WAI：評価ツールの限界
• BlogPosting — Schema.org：記事の型の定義
• W3C Link Checker — W3C：リンクの検査
• Nu Html Checker — W3C：HTML の妥当性の検査

調査・統計

• When Online Content Disappears — Pew Research Center：2013年のページの38%が消失、ニュースページの23%にリンク切れ（2024年5月17日）
• The WebAIM Million — WebAIM：2026年のトップページの不適合95.9%、平均56.1件、エラーの種類
• Automated Accessibility Testing Coverage — Deque：自動テストで見つかる問題は57.38%
• DORA's software delivery metrics — DORA：変更の失敗率、失敗したデプロイからの復旧時間

道具

• Visual comparisons — Playwright：スクリーンショットの差分と環境の違い
• GitHub Actions billing — GitHub Docs：無料枠（月2,000分・3,000分）と1分あたりの料金
• lychee — GitHub：ファイル単位のリンク検査
• Lighthouse CI — GitHub：表示速度の検査を CI で回す
• axe-core — GitHub：アクセシビリティの自動検査

欧州と日本のルール

• Transparency obligations under Article 50 of the AI Act — 欧州委員会：AI生成文の表示と、人の確認による例外
• European Accessibility Act — 欧州委員会：適用日と零細事業者の扱い
• ステルスマーケティングに関する景品表示法の規制 — 消費者庁：2023年10月1日施行
• Directive 2005/29/EC（不公正取引方法指令） — EUR-Lex：対価を得た記事広告の明示（附属書I 第11項）
• 障害を理由とする差別の解消の推進 — 内閣府：2024年4月からの合理的配慮の義務化
• Euro foreign exchange reference rates: Japanese yen — 欧州中央銀行：円換算に使った参照レート（2026年10月22日、175.97円）

いずれも2026年10月22日に確認したものです。方針・ルール・料金は変わるため、判断の前に公式サイトで最新の内容を確認してください。工数と費用の目安は DevNJ が置いた仮の目安で、実測の統計ではなく、サイトの規模と体制で変わります。