【ITニュース解説】Behind the Scenes: Building WordPress Static Site Guardian with Kiro

このニュース記事は、人気のあるウェブサイト作成ツールであるWordPressで作成したウェブサイトを、より安全に公開するための技術的な取り組みについて解説している。具体的には、WordPressサイトを静的なファイル群としてエクスポートし、それをクラウド上に展開する際に、セキュリティを強化する仕組みを構築した事例と、その過程で利用されたツール「Kiro」について触れている。

まず、なぜWordPressサイトを「静的」にするのかという点から説明する。通常のWordPressサイトは、訪問者がアクセスするたびにデータベースから情報を取得し、動的にページを生成する。この動的な仕組みは、セキュリティ上の脆弱性の原因になったり、アクセス集中時にサーバーに負荷がかかったりする可能性がある。そこで、WordPressで一度ページを作成したら、それをHTML、CSS、JavaScript、画像などの静的なファイルとして出力する方法がある。これを「静的サイトエクスポート」と呼ぶ。静的サイトは、サーバーへの負荷が非常に少なく、高速で、セキュリティ上の攻撃を受けにくいという大きなメリットがある。しかし、静的サイトを公開する場合でも、例えば特定のユーザーだけにアクセスを許可したいといった要件がある。このプロジェクトは、そのような静的なWordPressサイトを「保護」するための方法を扱っている。

この保護を実現するために、Amazon Web Services（AWS）というクラウドサービスの様々なコンポーネントが利用される。主なサービスは以下の通りである。

• Amazon S3 (Simple Storage Service)：インターネット上にファイルを保存するためのサービスである。静的エクスポートされたWordPressのファイル群はS3バケットに保存される。
• Amazon CloudFront: ウェブコンテンツを高速に配信するためのサービスである。世界中に分散されたサーバーからコンテンツを配信し、ウェブサイトの表示を速くする。このプロジェクトでは、CloudFrontがS3に保存された静的サイトのコンテンツを配信するが、特定の条件を満たしたユーザーにのみアクセスを許可する「署名付きCookie」という仕組みと組み合わせて利用される。
• Amazon Cognito: ユーザー認証や認可を管理するためのサービスである。ユーザーがログインする際に、そのユーザーが誰であるかを確認し、アクセス権限を管理する役割を果たす。
• AWS Lambda: サーバーを管理することなくコードを実行できるサービスである。特定のイベントが発生したときにコードが実行される。このプロジェクトでは、ユーザーが認証された後に、サイトへのアクセスを許可する「署名付きCookie」を発行する処理をLambdaが担う。
• Amazon API Gateway: ウェブアプリケーションが外部からアクセスするための「API（Application Programming Interface）」を作成、公開、管理するためのサービスである。Lambdaが署名付きCookieを発行する際のリクエストを受け付ける窓口として利用される。
• AWS CloudFormation: AWSのリソース（S3バケット、CloudFrontディストリビューション、Lambda関数など）をコードとして記述し、自動的に構築および管理するためのサービスである。手動設定の手間を省き、一貫性のある環境を自動で構築できる。

ニュース記事の著者は、これらのAWSアーキテクチャについては詳しいものの、特にCloudFormationのテンプレートを手書きする経験はあまりなかったという。手作業で複雑なCloudFormationテンプレートを作成するのは時間がかかり、エラーも発生しやすい。そこで、著者は「Kiro」というツール（コード生成AIのようなもの）に、必要なAWSリソース群を記述した「スタック」（CloudFormationのテンプレートによって構築される一連のAWSリソース群）を自動で生成してもらうことを試みた。

著者はKiroに対し、構築したいシステムの「核となるアイデア」を具体的に指示した。「静的エクスポート用S3バケット」「署名付きCookieによる保護付きCloudFront」「Cookie発行のためのAPI GatewayとLambda」「Cognitoとの統合ポイント」といった要素である。Kiroが最初に生成したCloudFormationテンプレートは、完璧ではなかったが、いくつかの細かい修正とリソースのライフサイクル調整を行うだけで、数時間のうちにシステムを動作させることができたという。これは、Kiroが大規模なテンプレートの「足場作り」という、時間と労力がかかる部分を大幅に加速させたことを示している。

システムが一度動作するようになった後、著者はさらにKiroに「リバース仕様」（逆向きの仕様）の生成を依頼した。これは、実際に構築されたシステムから、そのシステムが満たすべき「要件」、システムの「設計」、そして残された「タスクリスト」といったドキュメントを自動で生成させるという試みである。一見すると無駄に思えるかもしれないが、著者はこのリバース仕様が非常に価値のあるものだったと述べている。この仕様は、構築された設計に一貫性があることを確認でき、残りの作業を明確にするためのチェックリストを提供し、将来的に他の人々と共有できる公式なドキュメントとしても機能したのである。

このリバース仕様をガイドとして、著者はさらにシステムに不足していた要素を追加した。例えば、コンテンツを効率的にキャッシュするための「キャッシュポリシー」の設定、システム全体が意図通りに動作するかを確認する「エンドツーエンドテスト」の追加、そしてデプロイ後に不要なリソースをクリーンアップするためのチェック機能などである。また、Kiroに生成されたシステムが、そのリバース仕様に合致しているかを「検証」させることで、いくつかの見落としを発見し、システムの品質を向上させることができた。

このプロジェクトを通じて著者が得た教訓は、Kiroが全ての課題を魔法のように解決したわけではないものの、特に著者が慣れていないCloudFormationの大規模なテンプレート作成といった「退屈で時間のかかる部分」を大幅に加速させたという点である。また、システム構築後に「リバース仕様」を生成させるという手法は、プロジェクトの整理とドキュメント作成において非常に有効な手段であったことが示されている。結果として、CloudFormationの経験が限られていたにもかかわらず、著者は短期間で完全に動作する「SAR（Serverless Application Repository）テンプレート」（AWSのサーバーレスアプリケーションを共有・デプロイするためのテンプレート）を公開することができた。これは、AIを活用することで、新しい技術領域への挑戦や効率的な開発が可能になることを示唆する事例である。