はじめに
AI に開発を任せるとき、最初の依頼で仕様をどこまで決めておくべきでしょう。私は Codex の Astra に既存の Web サービスを 2 件改修してもらい、動く画面を触りながら要件を具体化していきました。
対象は、Vtuber 活動用の公式サイト allegromoltov.jp と、クリエイター向けホームページ作成サービス Pianistro です。どちらも本番リリースまで進めました。
具体的な実装方法は指定せず、既存コードと公開環境の調査を依頼しました。その結果に応じて、フレームワークやホスティングを変更する判断も任せています。
ただし、最初の依頼だけで完成形が決まったわけではありません。実際に触れる画面ができて初めて、残したい体験や使いにくい操作を具体的に伝えられました。 この記事では、性能改善とサービス刷新という異なる 2 件から、その進め方を振り返ります。
依頼の方針
2 件に共通して伝えたのは、既存構成を維持することも、全面刷新することも目的にしない、という方針です。調査結果を根拠に技術を選び、計画だけで終わらず、本番反映と公開 URL での確認まで進めてもらいました。
一方、改修の目的は異なります。
| 対象 | 当初の課題 | 依頼した範囲 |
|---|---|---|
| allegromoltov.jp | 表示や操作が遅く感じられる | 原因の調査と性能・保守性の改善 |
| Pianistro | 実利用が少なく、サービスの方向性を見直したい | 提供価値の検討から実装・運用手順の整備まで |
Pianistro には、AI と会話しながらホームページを作る案もありました。ただし、それを固定要件にはせず、個人で継続運営できるサービスにすることを優先しました。
依頼に使ったプロンプトは記事末尾に掲載しています。
公式サイトの性能改善
構成を維持したままの改善
allegromoltov.jp の既存構成は Next.js と Vercel でした。サイトの規模を考えると Astro などへの移行も候補になると思い、構成を維持する必要はないと伝えています。
調査で見つかった主要な負荷は、日本語 Web フォントの大量先読みと外部埋め込みでした。変更前の HTML には 359 件のフォントの先読み指定がありました。ブラウザーで取得したフォントの転送量は約 5 MB に達していました。YouTube と Google Calendar も初期表示から読み込まれていました。
Astra が選んだのは、Next.js と Vercel を維持し、フォント配信・外部埋め込み・画像・静的生成を修正する方法です。全面移行をせず、測定で見つかった負荷へ直接対処する結果になりました。
測定結果
2026 年 10 月 4 日の Lighthouse による比較は次のとおりです。LCP は、画面内の主なコンテンツが表示されるまでの時間を表す指標です。
| 指標 | 変更前 | 変更後 |
|---|---|---|
| モバイルの Performance スコア | 55 | 73–78 |
| モバイルの LCP | 40.59–41.03 秒 | 4.28–4.50 秒 |
| モバイルの総転送量 | 約 7.5 MB | 約 0.66 MB |
| 自サイトのフォント転送量 | 約 5 MB | 約 0.39 MB |
| 自サイトのフォントリクエスト数 | 376–379 件 | 30 件 |
| デスクトップの Performance スコア | 63 | 99 |
Lighthouse 13.5.0 と HeadlessChrome 154 を使い、キャッシュを消去して測定しています。モバイルの前後を各 2 回、デスクトップの前後を各 1 回測りました。モバイルには、通信と CPU の遅延を模擬する標準設定を使っています。
操作後に見つかったアニメーションの欠落
性能改善後の本番サイトを見て、以前あったスクロールアニメーションが消えていることに気付きました。各セクションが下から浮かび上がる演出です。
最初の依頼には、重要な表示や操作を維持する条件を含めていました。ただ、アニメーションを保持対象として明記しておらず、改修後の確認で認識のずれが表面化しました。そこで、以前の演出を復活させつつ、性能改善を維持するよう追加で依頼しました。
Astra は、従来使っていたアニメーションライブラリの Motion を戻さず、ブラウザー標準の IntersectionObserver と CSS で演出を再実装しました。
ローカルの本番ビルドを比較すると、JavaScript と CSS の転送増加は合計 1,207 bytes、約 1.2 KB でした。フォントの先読み 0 件、初期表示時の iframe 0 件も維持しています。
Pianistro の刷新
実装とレビューによる仕様の具体化
Pianistro では、画面を操作してから仕様を変える場面がさらに多くありました。
既存システムの調査後、刷新版は Cloudflare Workers・D1・React などを使う構成で実装されました。しかし、現在の編集体験を Astra が最初から一度で提案したわけではありません。
たとえば、初期の画面では、プレビューが出た途端に多くのボタンが現れました。使える機能が増えても、次の操作を選べず迷ってしまいます。この感想を伝え、最初に見せる機能を絞り、操作を進めるとツールが開放される方向へ変更しました。
レビューでは、使いにくい箇所をその場で修正するだけでなく、関連する指摘をまとめて用語と設計書を先に更新するよう依頼しています。 ある変更依頼が別の変更依頼と矛盾するケースや、あるいは過去の変更依頼がそもそも対応不要になるケースがあったためです。
AI の役割と運用の範囲
提供価値の考え方も、開発中に具体化しました。最終的に軸にしたのは、使う人にも AI にも、なるべく新しいものを作らせないことです。
サイトの構成や画像など、選択肢や専用の入力欄で扱える内容には決まった操作を用意します。AI を使う範囲は、短いメモから紹介文を提案する補助などに絞りました。開発を担う Astra と、Pianistro の利用者向け機能で使う AI は別の役割です。
下書きの保存と公開も分けました。編集中の内容をすぐにプレビューへ反映し、公開するタイミングを選べるようにしています。最後に公開した内容へ戻す機能やカスタムドメイン機能も追加しました。
依頼の範囲には、画面の実装に加えて、利用申請の受付手順・利用者向けガイド・バックアップ/復旧・CI/CD の整備も含めています。本番リリースまで進めた一方、実利用に基づく継続率や月間費用の評価は運用開始後の課題として残っています。
考察
今回の経験で印象に残ったのは、Astra が作った画面を判断材料にして、自分の要求を具体化できたことです。
設計資料だけを読んでいた段階では、期待するユーザー体験を十分に言葉にできていませんでした。動く画面を触ることで、変更してほしい対象と理由を伝えやすくなりました。
ただし、動くものを早く作るだけでは、仕様が定まるとは限りません。指摘するたびに個別の修正を重ねると、画面同士の役割や操作が矛盾することもありました。今回の Pianistro では、レビューをいったん集め、設計書へ反映してから実装する進め方が必要でした。
この 2 件から得た学びは、AI へ渡す最初の依頼を詳細にし尽くす方法ではなく、触れる成果物と具体的なフィードバック、更新した設計を整合させつづける進め方が良さそうということです。とくに、自分で体験して評価できるサービスを作るときはこのやり方をおすすめしたいです。
まとめ
Codex Astra に既存 Web サービス 2 件の改修を依頼し、本番リリースまで進めました。公式サイトでは、既存構成を維持したまま初期表示の通信負荷を減らしました。Pianistro では、操作とレビューを繰り返し、編集体験と AI の役割を具体化しました。
Astra が実装を進めることで、動くものを触りがら次の要求を考えられました。その一方で、残したい体験の判断・仕様変更の取捨選択・運用開始後の評価は引き続き必要です。AI に実装を任せる際にも、この判断の機会を開発の途中に組み込んでおくことが大切だと感じました。
付録: 最初の依頼プロンプト
以下は改修開始時に渡した依頼です。
allegromoltov.jp の改修依頼プロンプト
# allegromoltov.jp 最適化・再構成プロジェクト
## ゴール
https://www.allegromoltov.jp/ の表示速度・操作感・保守性を改善し、2026年12月31日までに本番環境への反映と実URLでの動作確認まで完了してください。
このタスクでは、既存システムの延長線上で改善することを前提としません。
現状の技術構成・実装・ホスティング・配信方式・外部依存・サイトの用途をまず調査し、その結果をもとに、既存構成を維持するのか、一部を置き換えるのか、大きく再構成するのかを判断してください。
現在利用しているフレームワークやアーキテクチャを維持する必要はありません。
逆に、調査の結果として現行構成を維持することが最適であれば、不必要な刷新も行わないでください。
技術選定そのものをこのタスクの検討対象に含めます。
---
## 背景
現在の allegromoltov.jp は実際に公開・利用しているVtuber活動用の公式Webサイトです。
現状、ユーザーとしてアクセスした際の動作・表示がやや遅いと感じています。
ただし、原因については事前に仮説を固定しません。
フレームワーク、JavaScript量、画像、外部サービス、レンダリング方式、ネットワーク、ホスティングなど、特定の原因があるものとして扱わず、実測とコード調査から判断してください。
---
## 最初に行うこと
実装変更を始める前に、以下を調査してください。
- 現在のリポジトリ全体
- 現在のアーキテクチャ
- 使用している主要技術
- ビルド・デプロイ構成
- ホスティング環境
- 外部サービス・外部リソースへの依存
- 公開中サイトの実際の挙動
- ページ構成
- 現在提供している機能
- モバイルを含む主要な利用形態
- パフォーマンス上のボトルネック
- 保守・運用上の複雑性
- 現在の構成を維持するメリット・デメリット
- 別構成に変更する場合のメリット・デメリットと移行コスト
推測だけで技術的結論を出さず、可能な限り実測・コード・設定・実際の公開環境を根拠に判断してください。
---
## 計画
調査後、最適だと考える改善計画を立ててください。
計画では少なくとも以下を明確にしてください。
- 現状の主要な問題
- 問題の根拠
- 改善後に目指す状態
- 現在の構成を残す部分
- 変更または廃止する部分
- 技術構成を維持または変更する理由
- 実装の大まかな段階
- リスク
- 回帰確認が必要な箇所
- 本番移行方法
- 完了判定方法
「現在使われているから」という理由だけで既存技術を残さないでください。
一方で「新しい方がよさそう」という理由だけで全面刷新もしないでください。
総合的なユーザー体験、性能、保守性、複雑性、運用負荷を考慮して判断してください。
計画をリポジトリ内にも残してください。
---
## 実行方針
計画策定後は、計画の作成だけで終了せず、完了条件を満たすところまで実装を進めてください。
途中で当初計画が不適切だと判明した場合は、計画を修正して構いません。
局所的な改善を積み重ねることより、最終的に本番環境で良い状態になることを優先してください。
既存実装への変更量を最小化すること自体は目的ではありません。
同時に、必要性の薄い変更を大量に行うことも避けてください。
---
## 前提・制約
- 公開済みの公式Webサイトであり、本番利用を停止させないこと。
- 現在利用者から見えている重要な情報・導線・URLについて、意図しない破壊を避けること。
- URLやSEO上重要な構造を変更する場合は、その影響を確認すること。
- モバイル環境を含めて確認すること。
- セキュリティを低下させないこと。
- 秘密情報をコードやリポジトリに含めないこと。
- 運用・保守が必要以上に複雑になる構成を避けること。
- 個人で継続的に保守できること。
- 現行フレームワーク・ライブラリ・ホスティングを維持する義務はない。
- 新しい技術構成への置換を行う義務もない。
- 最終的な技術判断は調査結果を根拠として行うこと。
- 2026年12月31日までに本番反映まで終えること。
---
## 品質確認
変更前後について、可能な範囲で客観的に比較してください。
特定の評価ツールや指標だけを達成することを目的にはせず、実際のユーザー体験改善を重視してください。
少なくとも以下について問題がないことを確認してください。
- 初回アクセス
- ページ遷移
- モバイル表示
- 主要コンテンツ表示
- 外部リンク・外部連携
- 公開URLからのアクセス
- 本番環境でのみ発生する問題
- 明らかな表示崩れや機能回帰
- パフォーマンス
改善結果と、改善前後で確認できた差を記録してください。
---
# 完了条件
以下をすべて満たした時点で完了とします。
1. 現状調査が完了している。
2. 調査結果に基づく技術判断と改善計画が文書化されている。
3. 必要な実装・設定変更が完了している。
4. 本番環境へのデプロイが完了している。
5. デプロイ後に https://www.allegromoltov.jp/ へ実際にアクセスして確認している。
6. 公開URL上で主要機能・表示・操作が正常であることを確認している。
7. パフォーマンス上の主要問題が改善していることを確認している。
8. 重大な回帰がないことを確認している。
9. Gitリポジトリが本番デプロイ済みの最新状態を反映している。
10. 必要なドキュメントもリポジトリ上で最新化されている。
11. 未解決事項がある場合は、その内容・影響・今後必要な対応が明示されている。
最終報告では、単に変更内容を列挙するのではなく、
- 何が問題だったか
- 何を判断したか
- なぜその判断をしたか
- どの程度改善したか
- 本番で何を確認したか
- 今後残っている課題
を簡潔にまとめてください。
Pianistroの改修依頼プロンプト
# Pianistro 刷新・実運用開始プロジェクト
## ゴール
[https://www.pianistro.jp/](https://www.pianistro.jp/) を、実際に継続利用され、個人運営でも経済的・技術的に持続可能なサービスとして再設計し、2026年12月31日までに本番運用を開始してください。
既存Pianistroの延長線上で改善することは前提としません。
既存コード・既存機能・現在のサービス構造を調査したうえで、
- 既存システムを改善する
- 一部を再利用して大幅に作り直す
- ほぼゼロベースで再構築する
のどれが最適かを判断してください。
ゼロベース開発の方が単純・安全・保守しやすいのであれば、それを選択して構いません。
一方、既存資産に十分な価値がある場合は、それを活用してください。
既存コードを残すこと自体を目的にしないでください。
---
# 背景
Pianistroは現在、CREATIAファンクラブ会員向けに提供しているWebサービスです。
現在の利用料金は月額300円です。
現状、実利用ユーザーがほとんどおらず、単純に宣伝を増やすより、プロダクトの方向性そのものを見直したいと考えています。
候補となっている方向性の一つに、
「ユーザーがAIと対話しながら、自分のホームページを作成・更新できるサービス」
があります。
ただし、これは現時点では仮説です。
この案をそのまま実装することをタスクの前提にはしません。
既存Pianistro、ユーザー層、価格、競合状況、実装・運用コストを調査し、より良い方向性がある場合は別案を採用してください。
---
# 非常に重要な経済条件
Pianistroは個人運営のサービスです。
CREATIA上での料金は現在、1ユーザーあたり月額300円です。
毎月必ず300円以内の原価に収める必要はありません。
特に、新規ユーザーが最初にホームページを作成する期間については、AI利用量が多くなり、一時的にそのユーザー単体で赤字になっても構いません。
重要なのは、
**ユーザーの継続期間全体で見た収益が、AI API・インフラ・その他の運用原価を上回り、サービス全体として持続可能であること**
です。
LTVを前提とした原価設計を行って構いません。
ただし、極端な利用によって個人運営では負担できない費用が発生する構造にはしないでください。
---
# AstraおよびChatGPT Creditsについて
2026年12月31日までは、開発作業自体にはCodex Astraを積極的に使用して構いません。
一方で、これは期間限定の開発環境です。
現在付与されているChatGPT Creditsを、Pianistro本番サービスの将来的な運用原価として扱わないでください。
2027年以降も継続できることを前提として設計してください。
Pianistroの一般ユーザーが利用する本番機能について、Astraを常時利用できることを前提にしてはいけません。
特定のAIモデルやAIベンダーを使用することも事前には指定しません。
品質・コスト・可用性・保守性を含めて最適な構成を調査・比較・判断してください。
---
# 最初に行う調査
実装方針を決める前に、少なくとも以下を調査してください。
## 現行サービス
- 現在のPianistroの機能
- リポジトリ構成
- アーキテクチャ
- データ構造
- 認証
- CREATIAとの関係
- ユーザー管理
- 公開サイト生成・公開方法
- インフラ
- デプロイ方法
- 現在発生している固定費・変動費
- 保守上の問題
- 現在のUI/UX
- 現在存在するユーザーデータ
- 現在利用しているユーザーへの影響
## プロダクト
- 現在のPianistroが解決している問題
- 実際にユーザーが少ない理由として考えられる要因
- 想定ユーザー
- 月額300円という価格との整合性
- 既存のWebサイト作成サービス・AI系サービスとの差
- Pianistroとして成立し得る独自価値
- 継続利用する理由
- 一度サイトを作った後にも月額料金を払い続ける理由
特に最後の点は重要です。
「最初にホームページを作ったら、その後サービスを解約してよい」という構造になっていないか確認してください。
継続利用価値が必要です。
---
# AI機能について
AIを利用する場合でも、
「AIを使っていること」
そのものを価値としないでください。
ユーザーがより少ない知識・操作・時間で目的を達成できることを重視してください。
ユーザーとの自然言語による対話でサイトを作成・更新できる方向性は有力な候補ですが、その実現方法は指定しません。
AIが直接コードを生成する方式、構造化されたサイトを操作する方式、既存コンポーネントを組み合わせる方式など、特定のアーキテクチャを前提にしないでください。
品質・柔軟性・AI原価・実装難易度・保守性を比較して判断してください。
---
# 原価と持続可能性
本番運用開始前に、少なくとも以下を把握できる状態にしてください。
- 新規ユーザー1人を獲得した際の初期AI原価
- サイト初期構築期間の平均原価
- 継続利用時の月間AI原価
- インフラ原価
- その他の主要な変動費
- 1ユーザーあたりの概算LTV
- どの程度利用されると採算が悪化するか
- 異常利用時の最大リスク
机上の計算だけでなく、可能な範囲で実際のプロダクトを動かした計測結果を利用してください。
サービス運用後も原価を確認できる状態にしてください。
ただし、そのための具体的な実装方式は指定しません。
---
# 設計方針
調査結果をもとに、最適なプロダクト案を決定してください。
以下について明確な判断を行ってください。
- Pianistroは誰のためのサービスか
- 何を解決するサービスか
- なぜユーザーが利用開始するのか
- なぜユーザーが継続するのか
- AIをどこに使うのか
- AIを使わない方がよい場所はどこか
- 月額300円で成立するか
- 現行Pianistroから何を残すか
- 何を捨てるか
- 既存コードを利用するか
- ゼロベース開発にするか
- 既存ユーザー・データをどう扱うか
- 2026年12月31日までにどこまでを正式サービスとして提供するか
調査・判断・計画を文書化し、リポジトリにも残してください。
---
# 実装
計画作成だけで終了しないでください。
最終的に一般ユーザーが本番環境で実際に利用できるところまで実装してください。
途中で、
- 当初のプロダクト仮説が間違っていた
- 既存コードを利用しない方がよい
- 想定よりAI原価が高い
- UX上別の構造の方がよい
と判明した場合は、計画を変更して構いません。
初期計画への忠実さより、最終的に成立するサービスにすることを優先してください。
---
# 運用
「デプロイできた」だけでは完了ではありません。
個人で継続運営できる状態まで整えてください。
少なくとも以下について、運用方法が明確になっている必要があります。
- ユーザー登録・利用開始
- CREATIAとの関係
- ユーザー管理
- 障害発生時
- AIサービス障害時
- API費用増加時
- ユーザーデータの扱い
- 更新・デプロイ
- 問い合わせ対応
- 退会・利用停止
- サービス運営者が確認すべき情報
- 定期的に行うべき保守
個人運営で過度な作業が発生しないことを重視してください。
---
# マニュアル
正式運用開始時にはマニュアルを整備してください。
最低限、
## 利用者向け
- Pianistroとは何か
- 利用開始方法
- 基本的な使い方
- サイト作成方法
- サイト更新方法
- 公開方法
- 利用上の注意
- 困った場合の対応
## 運営者向け
- システム概要
- 本番環境の構成
- デプロイ方法
- 日常運用
- ユーザー管理
- 原価確認
- 障害時対応
- AI関連サービスの設定変更時の確認事項
- メンテナンス方法
- バックアップ・復旧に必要な情報
- 主要な設定・秘密情報の管理方法
を、実際の運用で使える内容として整備してください。
具体的なドキュメント形式は問いません。
---
# 前提・制約
- 2026年12月31日までに本番運用を開始する。
- 個人で継続運営可能であること。
- 月額料金は現時点で300円。
- 新規利用開始直後の一時的な赤字は許容する。
- 長期的にはLTVベースで黒字化できる構造にする。
- 期間限定のChatGPT Creditsに運用を依存しない。
- Astraを本番ユーザー向けモデルとしてすす常用することを前提にしない。
- 特定のAIモデル・ベンダー・フレームワークを事前に固定しない。
- 既存コードの維持を前提にしない。
- ゼロベース開発も許容する。
- 既存ユーザーデータがある場合は、破壊的変更前にその影響を把握する。
- セキュリティと秘密情報の管理を適切に行う。
- AI機能が想定外の高額請求につながる状態を避ける。
- 運用コストとAI利用コストを後から把握できること。
- 「作ったが誰も使わない」状態を避けるため、プロダクト価値そのものを検討対象とする。
---
# 完了条件
以下をすべて満たした時点で完了です。
1. 現行Pianistroの技術・機能・運用状況の調査が完了している。
2. プロダクトとしての問題点・利用されていない要因について仮説と根拠が整理されている。
3. 今後のPianistroのターゲット・価値・継続利用理由が明確になっている。
4. 既存システムを活用するか、部分刷新するか、ゼロベース開発するかの判断が完了している。
5. 判断理由が文書化されている。
6. 採用した新しいPianistroが実装されている。
7. Gitリポジトリが最新の本番状態を反映している。
8. 本番環境へのデプロイが完了している。
9. 本番URLから一般ユーザーとして主要な利用フローを実際に確認している。
10. ユーザーが本番環境でサービスを利用開始できる状態になっている。
11. 単なるテスト公開ではなく、実運用を開始している。
12. AIを利用する場合、その本番原価が計測・評価されている。
13. 月額300円と想定LTVを踏まえ、サービス継続可能性について説明できる状態になっている。
14. 異常利用による費用リスクが把握・管理されている。
15. 日常的な運用方法が確立している。
16. 利用者向けマニュアルが完成している。
17. 運営者向けマニュアルが完成している。
18. 既知の問題・残課題が整理されている。
19. 2027年以降、現在の期間限定ChatGPT Creditsが存在しなくてもサービスを継続できる状態になっている。
---
# 最終報告
完了時には、少なくとも以下をまとめてください。
- 調査で分かったこと
- 当初のPianistroの問題
- 最終的に選んだプロダクト方向性
- その方向性を選んだ理由
- 既存システムをどこまで利用したか
- 大きな技術判断
- 本番AI原価
- 想定する収益構造
- 本番デプロイ結果
- 実運用開始時の状態
- 実際に確認したユーザーフロー
- 運用方法
- マニュアルの場所
- 今後改善すべき点
このプロジェクトの目的は「AIを使ったWebサイトビルダーを作ること」ではありません。
**Pianistroを、ユーザーにとって価値があり、実際に利用され、月額300円を基礎として個人でも持続的に運営できるサービスとして成立させること**を最終目的としてください。