Antigravityを使い始めて１週間が経ちました。

AIの知識がほぼゼロの状態から、「実務でどこまで使えるのか試してみよう」と思い立ち、Antigravityと一緒にこのブログを作り始めてから約1週間が経ちました。

初日に深夜の約2時間で土台を立ち上げ、独自ドメインで公開したときは、「勢いでここまで来てしまった」という感覚でした。しかしそこから本業の合間に、1日1〜2時間ほどの作業をコツコツと積み重ねてみたところ、気づけばひと通りの機能が揃ったブログへと育っていました。

• サイト内全文検索（モーダル＆検索専用ページ）
• 目次の自動抽出とスクロール追従（Scroll-Spy）
• 記事ごとの動的OGP画像生成（@vercel/og）
• コードのシンタックスハイライト（Shiki）とワンクリックコピー
• 記事内の会話吹き出しUI（Speech Balloon）
• 画像のクリック拡大（ライトボックス）
• パンくずリスト、タグ一覧、関連記事、RSS配信、JSON-LD構造化データ

自分ひとりなら1ヶ月以上かかっていたかもしれない機能が、なぜ1日わずか1〜2時間・実質1週間でここまで揃ったのか。

今回は、AIと一緒に進めたこの1週間の開発プロセスと、制作の中で見えてきた気づきをまとめてみました。

タイムラインで見る1週間の開発ダイジェスト

この1週間、具体的にどんなペースで開発が進んでいったのかを振り返ってみます。

Day 1（初日）：開始から2時間で本番公開へ

初日は、とにかく「発信の土台を形にすること」が目標でした。

Next.jsのセットアップからPRECSSのディレクトリ構成、microCMSのAPI連携、そしてVercelへのデプロイまで、AIが提示する手順に沿って確認と判断を繰り返していきました。

以前の記事でも書いた通り、AIの走るスピードに圧倒されて「AIに使われているような感覚」になりながらも、作業開始から約2時間後には独自ドメイン（designer-ka2ya.com）でサイトがインターネット上に公開されました。

Day 2〜3：読者のストレスを減らすUI調整

土台が動いたところで、次はスマートフォンでの見やすさや読書体験の改善に着手しました。

実際にスマホで表示を確認してみると、目次（TOC）が画面からはみ出したり、ドロワーメニューの開閉時に画面が不自然にスクロールしたりと、細かなバグがいくつも見つかりました。

1日1時間ほど時間をとり、気になった部分のコードをAIに修正してもらいながら、実機で触り心地を確かめる作業を続けました。

Day 4〜5：技術ブログに必要な機能をまとめて拡張

サイトの表示が安定してきた4日目と5日目には、一般的な技術ブログに求められる機能をまとめて実装していきました。

• 動的サイトマップ（sitemap.xml）と robots.txt
• パンくずリストとタグ機能（/tags/[id]）
• 関連記事ウィジェットと前後の記事ナビゲーション
• コードのシンタックスハイライト（Shiki）
• RSS 2.0フィード配信（/feed.xml）
• 記事ごとの動的OGP画像自動生成（@vercel/og）

本来ならライブラリの選定やAPI仕様の調査に時間がかかる分野ですが、「こういう機能を入れたい」と伝えることで、AIが必要なパッケージのインストールから設定ファイルの記述まで組み立ててくれます。

この2日間で、ブログとして必要な機能が一通り整いました。

Day 6〜7：会話UIの実装と細部の調整

機能が揃った終盤の2日間は、デザインのディテールと表現力の強化に時間を使いました。

とくに印象に残っているのが、記事内でAIとのやり取りを表現するための「会話吹き出しUI（Speech Balloon）」の実装です。

この提案を採用し、AIアイコンとして自作キャラクター「Gravit Rabbit」を配置して会話形式で読めるようにしました。

他にも、記事内の図解をタップすると全画面表示される「画像ライトボックス」や、ヘッダー・フッターの均等グリッドレイアウトなど、気になっていた細かな部分を調整していきました。

なぜ1日1〜2時間でここまで作れたのか？

平日の夜やスキマ時間のわずかな作業量で、なぜスムーズに開発が進んだのか。振り返ってみると、3つの理由がありました。

「コードを書く作業」から解放され、「決める作業」に集中できた

従来のWeb制作では、TypeScriptの型定義を書いたり、APIのエラーハンドリングを調べたり、ビルドエラーと格闘したりする「実装の作業」に多くの時間を取られがちでした。

今回は、そうした技術的な実装作業をAIに任せることができました。

その結果、自分は「どんな機能があれば読者が使いやすいか」「この余白やフォントサイズは適切か」といった、体験の設計やデザインの判断（ディレクション）に時間を使うことができました。

AIの「得意」と「苦手」を理解して役割分担した

1週間作業を続ける中で、AIの得意な領域と苦手な領域がはっきりと見えてきました。

• AIの得意分野:
  • 正確な構文でのコード生成
  • APIやライブラリの連携
  • エラーログの解析と原因特定
  • 単純作業の自動化
• AIの苦手分野:
  • 「心地いい」と感じる微細な余白やフォントのバランス
  • 読者の視線誘導や心理的なリズム感
  • ブランドとしての独自性や世界観の構築

「骨組みやロジックの実装はAIに効率よく任せ、見た目の美意識や読後感の調整は人間が主導する」。この役割分担ができたことが、スピードとクオリティを両立できた一番の要因でした。

最初に「PRECSS」というCSS設計規約を決めていた

個人的に大きかったのが、初日にCSSの設計ルールとして「PRECSS」を採用したことです。

AIにコードを書かせると、コンポーネントごとに場当たり的なCSSが増えていき、開発が進むにつれてコードの管理が難しくなってしまうことがあります。

今回は最初に「接頭辞（.l-, .c-, .p-, .u-）を使ってクラス名を整理する」というルールを指定したため、1週間で新機能を追加していってもCSSが破綻せず、最後まで見通しの良い状態を保つことができました。

1週間やってみてわかった「AIと働くリアル」

実際に1週間AIと向き合ってみて感じたのは、AIは「指示さえ出せば勝手に何でもやってくれる存在」ではないということです。

むしろ感覚としては、「手は非常に早いけれど、指示がないと動けないアシスタント」と一緒に仕事をしているような感覚でした。

「何を作りたいのか」「なぜそれが必要なのか」という目的を人間がしっかり示してあげれば、AIは驚くべきスピードと正確さで形にしてくれます。逆に、指示が曖昧だと予期しない方向へ進んでしまうこともあります。

デザイナーがプロジェクトの「監督」となり、AIが「頼れるエンジニア」として伴走してくれる。この関係性ができたとき、個人の制作スピードは大きく加速するのだと感じています。

気になる「トークン消費」とコスト感

AIと毎日のように開発を進める中で、もうひとつ気になっていたのが「トークン消費（利用枠やコスト）」のリアルな消費ペースでした。

「コードをたくさん書かせたり、大きな修正を頼むと、あっという間に週の利用上限に達してしまうのではないか？」と最初は心配していました。しかし、実際に1週間フルで作業してみた結果、消費した量はWeekly Limit（週間上限）の半分くらいでした。

平日の夜やスキマ時間に1日1〜2時間ほどみっちり開発を進めても、週の制限枠を半分ほど残した状態で運用できたことになります。これなら作業途中で上限に引っかかって手が止まる心配もなく、安心して制作を続けられます。

ここまで消費を抑えられた一番の理由は、タスクに応じたモデルの使い分けでした。

• Gemini 3.8 Flash（普段使い・基本モデル）:
  日常的なチャットのやり取り、細かなCSSの調整、バグ修正、文章の推敲などはすべてFlashを指定。レスポンスが非常に早く、トークン消費も控えめなため、作業の大半はこれで十分に完結します。
• 上位モデル（Gemini 4 Argon など / 要所のみ）:
  初日のアーキテクチャ設計や、原因特定が難しい複雑なエラーの調査など、「深く考えさせたいここぞという場面」でのみ限定して切り替え。

「基本は軽量なFlashでテンポよく進め、難所だけ上位モデルに頼る」というメリハリをつけたことで、ストレスなく快適に1週間の開発を終えることができました。

何でも最上位モデルに投げるのではなく、タスクの重さに応じて適切な相棒を選ぶことも、AIと長く付き合うための大切なポイントだと感じています。

おわりに

1週間前は「AIってどこまで使えるんだろう？」という半信半疑のスタートでした。

しかし今では、ゼロから立ち上げたこの場所で、自分で書いた記事が世界中に配信され、日々の試行錯誤をリアルタイムに記録できるようになっています。

「プログラミングができないから」と後回しにしていたアイデアも、AIと一緒なら、短い時間で動く形にできる実感が持てました。

デザイナーにとっても、AIは表現の幅を広げる心強いツールになりそうです。

まだまだ改善したいアイデアはたくさんあるので、これからもこのサイトを育てながら、現場での気づきを発信していきたいと思います。