クラウド / システム
プロンプトでこのウェブサイトを作った方法では、AI を使って古い WordPress サイトを AWS S3 と CloudFront 上の静的サイトへ移行した経緯を紹介しました。想定外だったのは、個人サイトが短期間で複雑なソフトウェアプロジェクトに変わってしまったことです。
いつの間にか増えた複雑さ
最初は数ページだけでした。その後、天気予報、トレーニングデータ、ゲーム、セキュリティチェック、自動デプロイ、そして9言語に対応しました。英語に加えてドイツ語、スペイン語、中国語、フランス語、ブラジルポルトガル語、日本語、ヒンディー語、オランダ語を追加しました。読者にとっては便利になりましたが、各言語で HTML、ナビゲーション、フィード、メタデータ、検証項目が増えました。
私たちの見通しは甘かったのです。「静的サイトだから、更新のたびに9言語すべてを再生成しても安いはずだ」と考えていました。実際には、英語の記事を少し直しただけでも、フォントのインストール、画像生成、各言語のナビゲーション、サイトマップ、セキュリティチェックを待つことになりました。9言語すべてを1つの必須リリース工程にしていたのです。
全言語の処理終了が公開条件でした
問題は多言語化ではなく、依存関係の設計にありました。
安全対策が障害になることもある
GitHub では、シークレットスキャンとの衝突、再現可能なビルドの差異、フォントのダウンロード停止、ワークフロー設定ミス、AWS IAM 権限不足などに遭遇しました。ある復旧作業では534個の公開オブジェクトを検査し、501個は想定どおり、24個に差異があり、9個の新規ページは読み込めませんでした。
各対策には意味がありましたが、組み合わせると小さな修正さえ難しくなります。自動化を増やしても、自動的に改善されるわけではありません。 チェックが失敗したら、安全策を外すのではなく原因を調べるべきです。
新しい構成：英語を先に、残り8言語は後から
主言語のリリースを、確認済みの翻訳作業から切り離すことにしました。
短いほど良い
この図は目標とするリリース順序であり、実際に本番でこの順序が確認できた証拠ではありません。翻訳の承認情報は、英語原稿の厳密な SHA-256 ハッシュと結びつきます。英語原稿が変われば以前の承認は無効です。翻訳がないのに英語の文章を翻訳済みとして公開してはいけません。
再現可能なビルド、OIDC、最小限の AWS 権限、予算チェック、CloudFront のキャッシュ無効化をしないことは維持します。
実際に確認できたこと
PR #119～#122 では、英語記事のコンパイラ、レビュー済み8言語用のコンパイラ、英語 → 他言語 → 全体整合性チェックの順番を実装しました。手動テストには AWS 書き込み権限がありません。段階的な本番公開は承認変数でロックされており、従来の OIDC ワークフローも S3 アップロード前に全体チェックを実行します。
したがって、CI が成功しただけでは「英語が公開され、他言語が処理中だった」証明にはなりません。以前のシャドーテストには sourceToHtmlBuildComplete=false、productionDeploymentApproved=false、S3 書き込み0件と記録されています。
計測できた時間短縮
2026年11月7日、9言語の変更履歴に対する2件の似た更新を比較しました。これは旧来の全体パイプラインの計測であり、段階的な本番リリース同士の比較ではありません。
| 指標 | 改善前 | 改善後 | 差 |
|---|---|---|---|
| オフライン CI | 3分38秒（218秒） | 3分18秒（198秒） | 9.2%短縮 |
| 全サイト品質検証 | 2分55秒（175秒） | 2分27秒（147秒） | 16.0%短縮 |
| Gitleaks | 56秒 | 67秒 | 11秒増加 |
| Semgrep | 10秒 | 11秒 | ほぼ同じ |
| pip-audit | 13秒 | 12秒 | ほぼ同じ |
| PR作成からマージ | 41分50秒 | 34分29秒 | 7分21秒短縮 |
短いほど良い
品質検証はオフライン CI に含まれる時間なので足し算してはいけません。セキュリティジョブは並列に動きます。今回の文書変更では Semgrep と pip-audit の重いスキャン工程はスキップされていました。2回の測定だけでは持続的な改善の証明にもなりません。
同じアセットの重複チェックを減らし、ナビゲーションの SHA-256 を再利用し、Python と Sharp のダウンロードをキャッシュし、各生成処理の時間を見えるようにし、文書だけの変更には高速な経路を用意しました。
英語の高速経路
独立したシャドーベンチマークでは、英語 HTML の契約検証が0.562秒でした。対象は英語60ページ、アセット96件、内部 HTML リンク514件です。英語のマージ検証の模擬実行は15秒、他言語の501ファイルは変更なしでした。
これは部品と模擬実行の時間であり、マージから実際の S3 公開までの時間ではありません。15秒と198秒をそのまま比較するのは誤解を招きます。
Pull Request から公開ページへ
PR はデプロイではありません。テストとレビュー、マージの後、リリース処理は正確なファイル、SHA-256 マニフェスト、AWS 権限、予算を検証します。それから S3 にアップロードします。CloudFront は有料の無効化をせず、通常の TTL で更新されます。
本当の段階的リリースを証明するには、T0 英語マージ、T1 英語検証終了、T2 英語 S3 アップロード確認、T3 翻訳処理の開始・終了、T4 8言語のアップロード確認を記録します。読者が何分早く英語版を読めたかは、この証跡で判断します。
AI とデバッグする
ChatGPT は失敗した PR のログを読み、修正案を作り、次の CI 実行を確認できます。夜間にはとても便利です。ただし、チャットが無期限に自律動作する保証ではありません。利用可能なセッションとツール、最終的な人間の確認が必要です。
一番大きな教訓
単に処理秒数を減らすだけでは不十分です。最初に価値を届ける結果を、すべての後続作業に依存させないことが重要です。英語は先に、8言語は同じ品質基準で後から届ける。実際の短縮時間は本番データで確かめていきます。