AIと個人サイトをつくった記録。5人のキャラが動く画面を公開するまで

使っていなかった個人サイトを、ちゃんと使いたい。最初にAIへお願いしたのは、ポートフォリオとブログのあるサイトでした。

そこから、普通すぎる気がする、もっとアニメーションを見せたい、と何度かやり取りして、今は五人のオリジナルキャラが出てくるサイトになっています。スイは、かなりお気に入りです。

今回は、完成した画面の紹介からもう少し踏み込んで、どういう順番でつくったのかを残します。デザイン、コード、画像づくりをCodexと進めた記録です。方針を伝え、出てきた画面に感想を返し、それをもとに実装と修正を重ねました。この記事も、制作時のやり取りと実際のファイル・履歴をもとにAIとまとめています。

1. 最初は、普通のポートフォリオだった

仕事でつくったものには、公開できないものもあります。それなら、自分で試したものを制作物にして、その過程もブログに載せよう。まずはそういうサイトにするつもりでした。

ただ、できたものを見て、AIっぽさが気になっていました。フォントなのか、配置なのか。その時点では、原因をうまく言い切れていません。

そこで、好きなものを並べました。アニメ、ゲーム、謎解き、ダイビング。そこから、次の三つの方向を見比べています。

この段階では簡単な謎も置いていました。でも、それだけでは欲しかった体験にならず、いったん外しています。謎解きは、あとでちゃんと設計してつくりたい。

代わりに欲しくなったのが、文章を読まなくても、見ているだけで楽しい画面でした。アニメーションをたくさん見せたい、と伝えたところから、今のトップページに近づいていきます。

2. キャラの絵と、画面の動きを分けた

最初にミオがいて、ナギとレン、そこへスイとリクが加わりました。キャラの雰囲気については、前の制作記録にも書いています。

絵はAIで生成した、背景が透過されたPNGです。現在使っている五人の立ち絵は、それぞれ1024×1536ピクセル。人物だけの画像にしておくと、Web側で文字や模様を前後に重ねられます。

スイでほしかったのは、緑系、ロングヘア、静かな雰囲気。画像生成では、そうした特徴をオリジナルキャラとしてまとめました。キャラの絵が決まったあとも、画面の配色や登場する速さはコード側で調整しています。

今のトップページでは、一枚の立ち絵を移動・拡大・回転させ、文字、帯、リング、紙吹雪を組み合わせています。キャラが変わったときに、背景色だけでなく構図や動く速さも変える。スイの登場は、リクよりゆっくりです。

役割は、おおむねこのように分けました。

3. 6秒ずつ、7つのカットで42秒

演出は、最初から五人・42秒だったわけではありません。制作メモでは、ミオの30秒・5カットの版を経て、キャラが増え、現在の7カットになっています。

一つのカットは6秒。七つで42秒です。実際のスイの設定は、次のようなデータになっています。

{
  name: '静かなひらめき',
  scene: 5,
  character: 'sui',
  tag: 'SUI / A QUIET SPARK',
  lines: ['静かな、', 'ひらめき。'],
  caption: '小さな想いにも、翼はある。',
  word: 'SUI',
  accent: '#77bba0',
  duration: 6000
}

このデータを読み、JavaScriptの時計で現在のカットを決めます。文字や人物の登場にはWeb Animations API、紙吹雪にはCanvas、背景の繰り返す動きにはCSSを使っています。

触れる部分もつけました。キャラをタップすると短い台詞が出る。好きなカットへ移る。再生位置を変える。一時停止する。

たくさん動かす一方で、動きを止められることも必要でした。別のタブを見ている間や、作品紹介のダイアログを開いている間は演出を止めます。端末の「動きを減らす」設定にも合わせています。

42秒のトップページを見る

4. 「止められない」のところで、帯が画面を覆った

途中で、「とめられないのところだけおかしいかも」と伝えたことがあります。

制作メモをたどると、原因は画面上部の帯に、下側の位置指定が残っていたことでした。帯が必要以上に広がり、画面を覆ってしまっていました。上部の帯の配置を直し、キャラの後ろに来るよう重なり順も変えています。

スマホでは、集合カットの文字と顔が重なる問題や、カット選択時に演出領域の内側がスクロールしてしまう問題もありました。配置を調整し、演出領域には overflow: clip を使う修正をしています。

コードの検査が通っていても、実際に見ると「ここが変だな」と分かる部分がある。キャラの顔、見出し、操作ボタンが収まるかを、PCと幅390ピクセルの画面で確かめました。

こういう修正も、完成画面と一緒に残しておきたいです。

5. WordPressの記事を、Astroへ持っていった

サイトを公開する段階で、前から使っていた st26life.com のWordPressも整理することになりました。つくった画面を置くだけでなく、記事を書き続けられる形にしたかったからです。

現在は、記事をMarkdownで持ち、AstroでHTMLを生成して、Cloudflare Workersから配信しています。AIと文章やコードを編集し、その変更をGitで一緒に追える構成です。

途中ではChatGPT Sitesの仮公開URLで見た目を確認し、その後Cloudflareの確認用URLへ移しました。既存の記事やURLを確認してから、自分のドメインへ切り替えています。

公開されていたWordPressの記事3本と固定ページ1本を移しました。本文、公開日、既存URL、画像、アフィリエイトのリンク先を引き継ぎ、古い ?p=... 形式のURLにも転送を用意しています。

確認は、目で読むだけにしませんでした。ビルド時のスクリプトが、元の記事から保存した124個のテキストブロックと、リンク先・画像などを照合します。「デザインを変えたら、昔の記事の一部が消えていた」を見つけるための検査です。

公開コンテンツの取り込みとは別に、元のWordPressのファイルとデータベースもバックアップしました。バックアップや認証情報は公開用のリポジトリに入れていません。復元して一式を動かす予行演習までは行っていないので、移行の記録にもその点を残しています。

6. 記事を書く、確認する、マージして公開する

今の記事更新は、次の順番です。

1. Markdownで下書きをつくる。
2. 作業用のブランチで本文と画像を整える。
3. テストとビルドを通し、Cloudflareのプレビューで確認する。
4. mainブランチへマージして、本番サイトに反映する。

下書きをつくるコマンドも用意しました。

pnpm new-post my-note "記事のタイトル"

新しい記事は draft: true で始まります。この間は公開ページにも記事一覧にも出ません。確認用のブランチで draft: false にしてプレビューし、公開する内容が整ったらマージします。

記事ごとのURLは本文ファイルの設定で決められます。ファイル名の都合で、公開済みのURLを変えなくて済むようにしています。

このサイトでは、GitHubとCloudflareを接続してビルドとデプロイを動かしています。毎日の記事の自動生成や、Geminiとの接続はまだ有効にしていません。まず、実際につくったものを根拠に記事を書いていくところからです。

7. コミットは細かく、記事は読める単位に

これからは、サイトもマダミスも「完成しました」だけで終わらせず、過程を発信していきたい。

そのために、今後のコミットには、具体的な変更に加えて、理由と確認結果を残すルールを入れました。PRにも、きっかけ、変更前後、公開してよい画像、まだできていないことを短く記録します。

一つの修正や、一組の素材を、一つのコミットにする。記事にするときは、同じ目的の変更を束ねる。コミット一覧をそのまま貼るより、読む人が制作の流れを追えるようにしたいです。

ここまでの代表的な履歴も残しておきます。日付は日本時間です。リポジトリは現在非公開なので、短いIDは制作記録を照合するためのものです。

なお、最初のGitコミットには、すでに動くトップページが入っています。三案の比較やキャラ追加の初期段階は、制作時のやり取りと残していた試作・メモをもとに振り返りました。Git導入後の変更から、コミット単位でたどれるようになっています。

8. サイトの中に、五人の居場所をつくる

最初は見て楽しむ画面だったのが、キャラたちと遊ぶ場所にもなってきました。

2026年10月3日時点では、短編マダミス「消えたエンドロール」と、その前夜を過ごす「灯りのついた準備室」を公開しています。

マダミスでは、用意した一つの事件を調べ、キャラと会話し、推理します。AIが毎回新しい事件を無限に生成する仕組みは、まだつくっていません。準備室では事件の前夜として、五人の掛け合いを読んだり、自分の言葉で話しかけたりできます。

普段の交流があるから、事件が起きたときにもその世界に入り込める。そういう場所をつくっていきたいです。

新しいキャラも増やしたいし、謎解きや脱出ゲームも別の作品として考えたい。どんなふうに話し、誰と仲がよくて、何をつくって過ごしているのか。その過程ごと、ここに残していきます。

五人の準備室へ行く