NASAの「今日の天文写真」(APOD、Astronomy Picture of the Day の略で毎日1枚の天体画像と解説を公開するサービス) を使い、AIが毎日自動で「宇宙のポストカード」を生成・公開する個人開発プロジェクトが公開されました。EventBridge・Lambda・Amazon Bedrockというサーバーレス構成（サーバー管理不要でイベント駆動的に処理を実行する仕組み）を組み合わせた事例で、バックエンドだけでなくフロントエンドの設計判断にも参考になる点があります。
特にフロントエンドエンジニアにとって興味深いのは、生成AIの出力をどう「型にはめて」画面に渡すかという設計です。この記事では、その仕組みをフロント目線で分解し、自分のプロジェクトに応用できるかを判断する材料を整理します。
何が行われているのか
このプロジェクトは「Cosmic Postcard」と名付けられたエージェント（人の操作なしに自律的にタスクを実行するプログラム）です。毎日自動でNASAの天体写真を取得し、Amazon Bedrock（AWSが提供する生成AIの基盤モデルをAPI経由で呼び出せるサービス）でタイトル・詩的なメッセージ・AIの所感という3つの創作テキストを生成します。
生成された結果はAmazon S3（AWSのオブジェクトストレージサービス）に latest.json と latest.jpg という2つのファイルとして保存されます。フロントエンドはHTML・CSS・JavaScriptだけで構成された軽量なアプリで、この latest.json を読み込んで画面に描画する仕組みです。
注目すべきは、ボタン操作もユーザー入力も一切ない点です。EventBridge（AWSのイベントスケジューラ）が毎日決まった時刻にLambda関数を起動し、処理が完結します。フロント側は「最新の1件を表示するだけ」という単純な役割に絞られています。
技術的な仕組みを段階的に見る
この構成を支える技術的なポイントは3つに分解できます。順番に見ていきます。
1. プロンプトの構造化による出力の予測可能性
生成AIを使う際によくある悩みが、出力フォーマットが毎回微妙に揺れる問題です。このプロジェクトでは、汎用的なチャット形式のプロンプトではなく、「タイトル」「ポストカードのメッセージ」「所感」という3つのフィールドを明示的に指定した構造化リクエストを投げています。
これはフロントエンド側の実装を大きく左右します。出力が構造化されていれば、JavaScriptで data.title data.message data.reflection のように決め打ちでアクセスでき、パース処理やバリデーションの複雑さを抑えられます。逆に構造化が甘いと、フロント側でテキストの正規表現処理や例外ハンドリングが膨らみ、保守性が落ちます。
2. 静的JSON配信というシンプルなAPI設計
フロントエンドがAPIサーバーを直接呼ぶのではなく、S3に置かれた latest.json を静的ファイルとして取得する設計も特徴的です。これはREST APIやGraphQLのような動的エンドポイントを用意せず、生成結果をファイルとして「置いておく」アプローチです。
この設計は更新頻度が低いコンテンツ（1日1回の更新など）と相性が良く、サーバーレス構成全体の運用コストを抑えられます。一方で、リアルタイム性が必要な用途や、ユーザーごとに異なる結果を返す必要がある場合には向きません。自分のプロジェクトがどちらに近いかを見極める判断材料になります。
3. 予測可能なファイルパスによるキャッシュとの付き合い方
latest.json という固定名で常に最新版を上書きする設計は、フロントの実装をシンプルにする一方、ブラウザキャッシュやCDN（Content Delivery Network、コンテンツ配信網）のキャッシュと衝突しやすい設計でもあります。
実際にこの構成を自分で試す場合は、S3の前段にCloudFrontなどのCDNを置くかどうか、置く場合はキャッシュのTTL（Time To Live、キャッシュの有効期限）をどう設定するかを確認する必要があります。更新のたびに同じファイル名を上書きする設計では、キャッシュ無効化（invalidation）の仕組みか、ファイル名にタイムスタンプを含めるかの判断が必要になります。
関連技術との比較で見る位置づけ
この構成を、フロントエンドエンジニアが普段触れる技術と比較すると理解が深まります。
静的JSON配信というアプローチは、Next.jsのISR（Incremental Static Regeneration、一定間隔で静的ページを再生成する仕組み）やGatsbyのビルド時データ取得と発想が近いものです。違いは、ビルドパイプラインを使わずLambda関数が直接ファイルを生成・配置している点です。SSG（Static Site Generation）のビルドステップを、サーバーレス関数で代替していると捉えると理解しやすくなります。
また、エッジランタイム（CloudflareやVercelのEdge Functionsのように、利用者に地理的に近い拠点で処理を実行する仕組み）との比較も有効です。今回の構成はLambdaがリージョン単位で実行されるため、エッジでの実行ではありません。もし配信先がグローバルで、取得元に近い場所で処理したい場合は、Lambda@EdgeやCloudflare Workersへの置き換えも選択肢になります。
今日確認できること
自分のプロジェクトでこの構成を参考にするかどうかを判断するために、次の点を確認してみてください。
- 更新頻度: コンテンツが1日数回以下の更新であれば、静的JSON配信は有力な選択肢になります
- 出力フォーマット: 生成AIを使う場合、プロンプトでフィールドを明示的に指定できているか見直してみてください
- キャッシュ設計: 固定ファイル名を使う場合、CDNのTTL設定とキャッシュ無効化の手段を事前に決めておくと事故を防げます
- コスト試算: Bedrockの呼び出し回数・Lambdaの実行時間・S3のリクエスト数は、AWSの料金計算ツールで事前に概算できます
Amazon Bedrockを初めて使う場合は、AWSマネジメントコンソールの「Bedrock」画面からモデルアクセスのリクエストが必要です。リージョンによって利用できるモデルが異なるため、使いたいモデル（Claude系やTitan系など）がどのリージョンで提供されているかを事前に確認しておくと手戻りが減ります。
まとめ
今回の構成から読み取れるポイントは次の3つです。
- 生成AIの出力は構造化してリクエストすることで、フロント側の実装が大幅に単純化できます
- 更新頻度が低いコンテンツなら、動的APIより静的ファイル配信の方が運用コストを抑えられます
- 固定ファイル名で上書きする設計は、CDNキャッシュとの付き合い方を事前に決めておく必要があります
自分のプロジェクトで生成AIの出力を画面に表示する機会があれば、まずプロンプトの構造化とレスポンスの保存形式から見直してみると、実装の見通しが立てやすくなります。