AIにほぼ任せてポートフォリオサイトをつくった
経緯
ポートフォリオサイトをつくろうと決めてから、最初にやったのはAIにサイトの構成を相談することだった。
自分の中にあったのは「静かで、心地よくて、長く見ていても疲れないサイトにしたい」という、ぼんやりしたイメージだけ。どんなセクションが要るか、どういう順番で並べるか、コピーのトーンはどうするか。そのあたりをAIと壁打ちしながら固めていった。
セクション構成が決まったあとも、コンポーネントの実装、APIルートの設計、コンテンツのスキーマ定義と、やることは多かった。でもその大半は、自分がゼロから書いたものではない。AIにやりたいことを伝えて、出てきたコードを読んで、直して、組み込む。その繰り返しでサイトの骨格ができていった。
自分がやったこと
AIに実装を任せた分、自分の手が空いた。その時間を何に使ったかというと、ほとんどスタイルの調整だった。
余白の取り方、テキストの行間、色のトーン、ホバー時のトランジション速度、スクロールしたときのリズム。AIが出してくるCSSは「正しいけど、なんか違う」ということが多い。要素は正しく配置されているのに、全体を眺めると空気感が合わない。その「なんか違う」を潰していく作業に、制作時間の大きな割合を使った。
たとえばローディング画面。「Maymai.dev」の文字が一文字ずつ浮き上がって、線が伸びて、ラベルがフェードインする。構造やアニメーションの骨格はAIが書いたものだが、各要素のディレイを30msずつずらすのか40msにするのか、フェードアウトまでの間を0.8秒にするのか1秒にするのか。そういう調整は画面を見ながら自分で決めた。2回目以降はsessionStorageでスキップする制御や、prefers-reduced-motionで丸ごと非表示にする判断も、AIに聞いて実装してもらったものだけど、「初回だけ見せたい」という意図は自分のものだった。
色についても同じで、サイト全体のカラーパレットはかなり時間をかけて選んだ。AIに候補を出してもらうこともあったが、最終的にはブラウザで実際に当ててみて決めている。数値で見ると微差なのに、画面の印象がまるで変わる。ここは人間がやるしかない部分だった。
技術スタック
サイトの構成を簡単に書いておく。
Astro 6 をフレームワークに選んだ。ページの大部分を静的HTMLとして出力して、動きが必要な箇所だけクライアントJSを読み込む。ポートフォリオのような読みもの主体のサイトには素直に合っていた。共有スクリプトとAPIルートは TypeScript、スタイルは SCSS でscoped styleと共通定義を組み合わせている。
ヒーローセクションの背景には Pixi.js 8 でクラゲを浮かべている。傘の開閉、触手の揺れ、ポインターへの追従といった描画ロジックはAIに書いてもらったものがベースで、自分は主にクラゲの配置と色味を調整した。PC用に7体、モバイル用に5体のプリセット座標があり、DevToolsでビューポートを切り替えながら一つずつ位置を詰めていった。Pixi.jsはawait import('pixi.js')で動的に読み込んでいるので、トップページ以外にはバンドルが乗らない。prefers-reduced-motionが有効なら初期化自体をスキップする。
ホスティングとサーバーサイド処理は Cloudflare Workers に統一した。ブログと制作物の各記事につけたいいね機能は、Cloudflare KV にカウントを保存して、クライアント側はlocalStorageで重複防止している。APIルートではtypeとslugをバリデーションしていて、開発環境ではKVの代わりにインメモリのMapにフォールバックする仕組み。この辺の設計もAIに「ローカルでKVが使えない場合どうする？」と聞いて出てきた方式がそのまま使えた。
コンテンツ管理はAstroの Content Collections で、blogとworksそれぞれにZodスキーマを定義してMarkdownを置く構成。blogのdescriptionとtagsはoptionalにした。書くときの心理的ハードルは低いほうがいい。
別プロジェクトページのギャラリーには Swiper を使っている。サイトマップは @astrojs/sitemap でAPIルートを除外して生成。
ビルドはnode scripts/generate-assets.mjs && astro buildの2段階、デプロイはastro build && wrangler deployで通る。
苦労した点
Cloudflare環境のデバッグ
WorkersのランタイムはNode.jsと微妙に異なる。cloudflare:workersからのimportがローカルのastro devでは動かなくて、環境判定の分岐を入れる必要があった。wrangler devとの挙動の違いにも何度か引っかかった。ここはAIに聞いても「理屈上はこうなるはず」という答えしか返ってこなくて、実機で試して潰すしかなかった。
AIが出すコードとの距離
AIが出すコードは動く。動くけど、自分のSCSS設計やBEM命名と噛み合わないことが多かった。変数名やクラス名の付け方、セレクタの粒度、ミックスインの使いどころ。そのまま貼ると既存のスタイル体系と馴染まないので、結局手で書き直す場面は少なくなかった。
逆に言えば、「こういうコードにしたい」という自分の基準があるから書き直せる。基準がなければAIの出力をそのまま使うことになるし、それはそれで動くから問題ないのかもしれない。でも細部に自分の手が入っていないサイトは、たぶん自分で触り続ける気にならない。
レスポンシブの地道な調整
セクションごとのPC/SP切り替え、クラゲのプリセット座標の分岐、ナビゲーションの表示切り替え。レスポンシブ対応はAIに構造を出してもらっても、実際の画面で見ると詰めが甘い箇所が多くて、DevToolsでサイズを変えながら一つずつ直していった。この作業が地味にいちばん時間を食った気がする。
感想
AIに任せてよかったのは、実装の初速が速かったことと、自分の手をスタイルの調整に集中させられたこと。コンポーネントの骨格やAPIの設計を自分でゼロから考えていたら、見た目のトーンを詰める時間はもっと少なかっただろう。
自分がこのサイトの制作でやったことを正直に振り返ると、AIが出してきたものを読んで、選んで、直して、並べた、という表現がいちばん近い。でもそれは「何もしていない」とは違うと思っている。何を採用して何を捨てるか、どこを直してどこはそのまま使うか。その判断の積み重ねがサイトのトーンをつくっている。
ブログはこの記事がまだ最初の一本で、ここから増やしていくつもりだ。
実はこの記事も全部AIなんだ。