某日、業務において書類のチェック処理が課題になっていたので、 頭の整理も兼ねて、AWSで組んでみることにした。

ここで作ろうとしているのは社内ブログ記事のチェックシステムだ。 社内ブログ記事に限定して構築するが、汎化すれば様々なチェック処理に活用できるので、あくまでもプロトタイプ的な位置づけとなる。

構成は以下のようなものとなる。

■構成図

システム構成図

■業務要件

  • 実際は業務部門のユーザーが利用する。
  • ブログ記事のチェックロジックは色々あるが、プログラムチェックとAIチェックを組み合わせる。
  • ユーザーはAIと対話することでチェックロジックを作成・変更できる。
  • チェックロジックはプラグインとしてシステムに組み込まれる。
  • DBを用意し、チェックロジックからDBサービス経由でアクセスする。 （DBは高くなるので今回はスタブにする可能性あり）

前置きが長くなったが、上記システムの制作の軌跡を備忘として残していきたいと思う。

■AWSサービス選定にあたって

私はAWS Builderとして体系的な学習をしたわけではない。 サービス選定はGPT-5.1に相談して決めている。だから、もしかしたらAWSのセオリーから外れている点もあるかもしれない。 いったん作ってみて、AWSの諸先輩方に教えを請いたいと思っている。

……AI Builders Dayで聞いてみよう！

■(1) フロント／ユーザー認証

CloudFront + S3 + Cognito

メモ：CloudFrontは外部アクセスの入口、S3はオブジェクトストレージ、Cognitoはユーザー管理のマネージドサービス。

まずCloudFrontの設定から。

GPT-5.1にCanvasを作るように指示し、CloudFrontの構築手順を問う。

元々、ユーザー管理については自前で実装しようとしていたが、Cognitoを使えば良いとわかった。 ……AWSはマネージドサービスが手厚い感がある。

ついでにGitHubのCIパイプラインも学習しておこう。 GitからCIでデプロイできるように。

ところで、git initをした際、gitからブランチの名称をmasterからmainに変えるようアドバイスがあった。これについては、もともとGitのデフォルトはmasterだったが、近年、「master/slave」という言葉が人種差別・奴隷制を連想させるという問題意識が強まり、その流れの中で、より中立的なmainに変えていこうという動きが起きたという歴史があるそうだ。

横道にそれたが、簡単なSPAの作成とリポジトリ作成まではできた。ここまでのハマりポイントは特になかった。Cognitoを使ったユーザー認証において少し手間取ったくらいで、全体的にスムーズに進んだ。次回は自動デプロイから作業をしていく。

作業ログ1

作業ログ2

以下、GPT-5.1と作成したビルドログ（手順メモ）。

■ブログ記事チェックエンジン ビルドログ

このドキュメントは、AWS 上にブログ記事チェックエンジンを構築する際の作業ログです。

0. 前提情報

  • リージョン: us-west-2 オレゴン
  • システム名: ブログ記事チェックエンジン PoC

1. CloudFront の設定

1-0. 事前確認

1-1. CloudFront ディストリビューション新規作成 Step1 Get started

  1. CloudFront コンソールを開き、左メニューの Distributions から Create distribution をクリック
  2. “Get started” 画面で次を設定
    • Distribution name: blog-checker-web-dist など任意のわかりやすい名前
    • これはタグ的な名前であり、URL には影響しない
    • Description: 空のままでよい（必要なら後で追記）
    • Distribution type: Single website or app を選択
    • Domain: 今は空のまま（Route 53 の独自ドメインを後で使う場合に設定）
    • Tags: 任意。必要であれば Project = blog-checker-web などを追加
  3. 右下の Next をクリックし Step2 Specify origin へ進む

1-2. CloudFront ディストリビューション新規作成 Step2 以降

  1. Step2 Specify origin
    • Origin type: Web を選択
    • Origin domain: S3 バケット blog-checker-web-XXXX（例：blog-checker-web-example）をプルダウンから選択
    • 例：example-bucket.s3.us-west-2.amazonaws.com
    • 「この S3 バケットは S3 Web サイトで設定されています。このディストリビューションを Web サイトとして使用する予定の場合は、バケットエンドポイントではなく S3 ウェブサイトエンドポイントを使用することをお勧めします。」と表示されても、特に変更しない
    • その他はデフォルトのまま Next へ
  2. Step3 Enable security
    • このステップでは CloudFront に AWS WAF Web Application Firewall を紐付けるかを選択する
    • ブログ記事チェックエンジン PoC ではまずコストと設定をシンプルにするため、セキュリティ保護を有効にしないでください を選択する
    • 「既存の WAF 設定を使う」「新しい WAF を作成する」は使用しない
    • Use monitor mode もオフのままにする
    • 後から必要になった時点で WAF を追加で関連付けることができる
    • 画面右下の Next をクリックし Step4 Configure distributions へ進む
  3. Step4 Configure distributions
    • Default cache behavior 内で次を設定
    • Viewer protocol policy: Redirect HTTP to HTTPS を選択
    • Allowed HTTP methods: GET, HEAD を選択（当面はこれで十分）
    • Cache policy: Managed-CachingOptimized を選択
    • Compress objects automatically: 有効のまま
    • 他の設定はデフォルトのまま Next
  4. Step5 Get TLS certificate
    • 一旦は “Use the default CloudFront certificate” を選択
    • 独自ドメインを使う場合は後日 ACM 証明書を設定する
    • Next で最終確認画面へ
  5. Step6 Review and create
    • 設定内容を確認し、問題なければ Create distribution をクリック

1-3. ディストリビューション設定とデフォルトキャッシュビヘイビア

  1. Default cache behavior セクションで
    • Viewer protocol policy: Redirect HTTP to HTTPS を選択
    • Allowed HTTP methods: GET, HEAD を選択（当面はこれで十分）
    • Cache policy: Managed-CachingOptimized を選択
    • Compress objects automatically: 有効のまま
  2. 他の設定はデフォルトのままとし、細かいチューニングは後日検討

1-4. ドメインと証明書まわり

  • 一旦は CloudFront が自動で発行するドメイン名 xxxx.cloudfront.net をそのまま利用する
  • 独自ドメインを使う場合は後日、以下を設定する方針
    • Alternate domain name (CNAME)
    • ACM 証明書

1-5. ディストリビューション作成と動作確認

  1. 画面下部の Create distribution をクリックし作成を開始
  2. Distributions 一覧で対象ディストリビューションの Status が Deploying から Enabled になるまで待機
  3. Status が Enabled になったら、その行の Domain name をメモ
  4. ブラウザで https://{CloudFront の Domain name}/index.html にアクセスし、S3 にアップロードした index.html のログイン画面が表示されることを確認
  5. https://{CloudFront の Domain name}/ にアクセスしたときに AccessDenied となる場合は、以下の手順で CloudFront のデフォルトルートオブジェクトを設定する
    1. CloudFront コンソールで対象ディストリビューションを開き、一般 General タブで 編集 Edit をクリック
    2. Default root object に index.html と入力
    3. 変更を保存し、ステータスが Deployed になるまで数分待つ
    4. 再度 https://{CloudFront の Domain name}/ にアクセスし、index.html が表示されることを確認

1-6. S3 バケットポリシーの更新 OAC 用

  1. CloudFront コンソールで対象ディストリビューションを開き、Origins タブを選択
  2. オリジンとして設定した S3 バケット行を選び Edit をクリック
  3. 画面内の「Update bucket policy」欄に表示されているサンプルポリシーをコピー
  4. 別タブで S3 コンソールを開き、対象バケット → Permissions → Bucket policy を表示
  5. 既存ポリシーを CloudFront 提示のサンプルポリシーで置き換え、保存
  6. Block public access は有効のまま、CloudFront OAC 経由のみでアクセスさせる構成にする
  7. 必要に応じて、S3 website endpoint へのパブリックアクセスを無効化する（本番運用時）

2. S3 静的ホスティングバケットの作成

2-1. Webホスティング用バケット作成

  1. AWS コンソール右上のリージョンが 米国西部 オレゴン us-west-2 になっていることを確認
  2. サービス一覧から S3 を開く
  3. 「バケットを作成」をクリック
  4. 一般的な設定
    • AWS リージョン: 米国西部 オレゴン us-west-2 のまま
    • バケット名: blog-checker-web-example など一意な名前を入力（小文字とハイフンのみ）
    • 既存のバケットから設定をコピー: 何も選ばずそのまま
  5. オブジェクト所有者
    • 「ACL 無効 推奨」を選択したままにする
    • オブジェクト所有者は「バケット所有者」のままでOK
  6. このバケットのブロックパブリックアクセス設定
    • 4つのチェックボックスはすべてオンのままにしておく
    • 注意書きに「パブリックアクセスを許可しない」と出ている状態でOK
    • 後で CloudFront の OAC とバケットポリシーでアクセスを許可する方針
  7. 下の方へスクロールし、バージョニングや暗号化などはデフォルトのまま（今回は何も変更しない）
  8. 画面右下の「バケットを作成」をクリック
  9. バケット一覧に今付けた名前が表示されていることを確認し、ビルドログに実際のバケット名をメモ

2-2. 静的Webサイトホスティングの有効化

  1. AWS コンソールで S3 を開く
  2. バケット一覧から、さきほど作成した blog-checker-web-example など対象バケットの バケット名のリンク をクリック
  3. バケット詳細画面の上部にあるタブから Properties プロパティ をクリック
  4. Properties 画面を下方向にスクロールし、Static website hosting 静的Webサイトホスティング のセクションを探す
  5. Static website hosting セクションの右側にある Edit 編集 ボタンをクリック
  6. Hosting type の選択肢から Host a static website 静的ウェブサイトをホストする を選択
  7. Index document に index.html と入力
  8. Error document は空でもよいが、後で作る場合は error.html と入力しておく
  9. 画面右下の Save changes 変更を保存 をクリック
  10. Static website hosting セクションに Bucket website endpoint が表示されるので、URL をビルドログにメモ

2-3. 初期コンテンツのアップロード

ここではローカルの blog-checker-web/dist/ にある index.html を、S3 バケットにアップロードする。

  1. ローカルで blog-checker-web/dist/index.html が存在することを確認
  2. AWS コンソールで S3 を開き、対象バケット blog-checker-web-example などのバケット名リンクをクリック
  3. 上部タブが Objects になっていることを確認
  4. 画面右上の 「アップロード」 ボタンをクリック
  5. アップロード画面で 「ファイルを追加」 をクリックし、ローカルの dist/index.html を選択
  6. 画面下部までスクロールし、ストレージクラスなどはデフォルトの「スタンダード」のままでよい
  7. アクセス許可はデフォルトのまま（パブリックアクセスは後で CloudFront OAC 経由にする）
  8. 右下の 「アップロード」 ボタンを押す
  9. アップロード完了メッセージが出たら、Objects タブに戻り index.html が1件表示されていることを確認

3. Cognito ユーザプールの作成

ここでは、ブログ記事チェックエンジンのログイン認証に使う Cognito ユーザプールを作成する。フロントエンド（CloudFront + S3）のログイン画面から接続するための準備までを行う。

3-1. ユーザプールの新規作成

  1. AWS コンソール右上のリージョンが US West (Oregon) us-west-2 であることを確認
  2. サービス一覧から Cognito を開く
  3. 左メニューの User pools ユーザープール を選択
  4. 右上の Create user pool をクリック
  5. “Configure sign-in experience” 画面で次を設定
    • Cognito user pool を選択（外部IdPは今回は使わない）
    • サインインオプション: Email のみにチェック（ユーザ名ではなくメールアドレスでログイン）
    • Next をクリック
  6. “Configure security requirements” 画面
    • パスワードポリシー: デフォルトのまま（最小8文字など）でよい
    • Multi-factor authentication (MFA): No MFA を選択（PoCのため）
    • その他の設定はデフォルトのまま Next
  7. “Configure sign-up experience” 画面
    • Self-service sign-up: 必要に応じて ON（自分でサインアップしたい場合）
    • Required attributes: email のみ Required にする
    • Attribute verification: Email にチェック（メール検証）
    • Next をクリック
  8. “Configure message delivery” 画面
    • デフォルトの Cognito email provider を使用（SES は設定しない）
    • Next をクリック
  9. “Integrate your app” 画面
    • User pool name: blog-checker-user-pool など分かりやすい名前
    • アプリケーションクライアントの設定は 3-2 で行うため、そのまま Next
  10. Review 画面で設定内容を確認し、問題なければ Create user pool をクリック
  11. 作成されたユーザプールID（例: <your_user_pool_id>）をメモ

3-2. アプリクライアント（Webフロント用）の作成

  1. 作成したユーザプールを開き、左メニューから App integration → App clients を選択
  2. Create app client をクリック
  3. App client name に blog-checker-web-client などを入力
  4. Authorized client type:
    • Public client を選択（フロントエンドJavaScriptから直接呼び出すためシークレットは持たない）
  5. Authentication flows:
    • USER_PASSWORD や USER_SRP のようなユーザパスワード認証フローを有効化（デフォルトのままでよい）
  6. OAuth 2.0 設定は当面スキップしてもよい（必要になったら Hosted UI と併せて設定する）
  7. その他の設定はデフォルトのまま Create app client をクリック
  8. 作成された App client ID（例：<your_app_client_id>）をメモ

3-3. ドメイン設定（Hosted UI 用・将来のための準備）

  1. ユーザプール画面の App integration → Domain name を開く
  2. Cognito ドメインのプレフィックスに blog-checker-auth など一意な文字列を入力
  3. auth.us-west-2.amazoncognito.com などのドメインが問題なく取得できることを確認し、保存
  4. 生成されたドメインURL（例: https://<your-domain-prefix>.auth.us-west-2.amazoncognito.com）をメモ

3-4. CloudFront / フロントエンドとの接続準備メモ

フロントエンド（https://<your-cloudfront-domain>/）から Cognito に接続するために必要な情報:

  • リージョン: us-west-2
  • User Pool ID: <your_user_pool_id>
  • App client ID: <your_app_client_id>
  • Cognito ドメイン: https://<your-domain-prefix>.auth.us-west-2.amazoncognito.com

これらは後で assets/js/app.js に設定値として埋め込み、ログインフォームから Cognito のサインインAPIを呼び出す実装に使う。

Hosted UI を使う場合は、Cognito 側のアプリクライアント設定で Callback URL / Sign out URL に CloudFront の URL を登録する必要がある（後続タスク）。

4. Git / GitHub 初期設定メモ

4-1. ローカルリポジトリの作成

  1. ローカルで blog-checker-web/ ディレクトリに移動
  2. 次を実行して Git リポジトリを初期化
cd blog-checker-web
git init
  1. .gitignore を作成し、dist/ や一時ファイルを除外（後で追記してもよい）
# .gitignore の例
node_modules/
dist/
.DS_Store
.env
  1. 初回コミット
git add .
git commit -m "Initial commit: blog checker web skeleton"

4-2. GitHub リポジトリとの連携

  1. GitHub 上で新しいリポジトリを作成
    • リポジトリ名: blog-checker-web-demo
    • README や .gitignore の自動生成はどちらでもよい（今回はローカルから push）
  2. GitHub が表示する git remote / push コマンドを参考に、ローカルから次を実行
git remote add origin git@github.com:<your-account>/blog-checker-web-demo.git
git branch -M main
git push -u origin main
  1. 上記コマンド実行により、GitHub 上の <your-account>/blog-checker-web-demo リポジトリに初期コードを反映

4-3. デプロイとの関係

  • 将来的に GitHub Actions で自動デプロイする場合は、この blog-checker-web-demo リポジトリをトリガーにする想定。
  • 当面はローカルから S3 へのアップロード（手動またはシェルスクリプト）とし、GitHub はコード履歴管理とバックアップ用途から始める。

■今後のタスク候補メモ

  • ローカルデプロイスクリプト（deploy.sh）を作成し、dist/ -> S3 と CloudFront キャッシュ無効化を自動化
  • GitHub Actions ワークフロー（.github/workflows/deploy.yml）を追加し、main ブランチへの push をトリガーに自動デプロイ
  • ブログ記事チェックロジックをプラグイン風に整理し、将来の申請書チェックプラグイン構造に寄せて設計
  • 認証済みユーザ情報（id_token）を使って、将来の API Gateway / Lambda 連携のための Authorization ヘッダ付与処理を検討

※ CloudFront ドメイン名、Cognito の User Pool ID / Client ID、GitHub アカウント名などの固有情報は、ブログ公開用にプレースホルダ（<your-...> や xxxx.cloudfront.net など）に置き換えています。