Google Antigravityとデザイナーの協業、実際に使ってみて思ったこと
この記事では、デザイナーである私がAIコーディングツール「Google Antigravity」を使ってみて感じたことを、備忘録としてまとめています。
きっかけは、このブログの運用で発生した技術的な問題でした。Contentfulの帯域幅制限を超過してしまい、画像配信の仕組みをなんとかしなければならない喫緊の課題がありました。普段なら、ケーススタディを検索してエラーコードと何十時間も睨めっこするところですが、「AIコーディングツールがあれば、手っ取り早くなんとかなるのでは」と思い、試してみることにしました。
なお、記事内ではAntigravityの具体的な使い方には触れませんが、使用したモデルはClaude Opus 4.5です。
この記事のターゲット
AIコーディングツールに興味があるデザイナーの方
個人ブログやサイトを自分でメンテナンスしている方
エンジニアとの協業をより円滑にしたいと考えている方
実際にやってみたこと：Cloudflare R2への画像移行
以下は、バックエンドの知識がほぼ皆無な素人によるAIとの協業イメージです。大雑把に書いてありますが、だいたい流れは合っています。専門家から見たら大した問題ではないでしょうか、私にとっては死活問題でしたので、わからないなりに奮闘した経緯になります。ご笑納ください。
帯域幅の超過
ある日、Contentfulから「おまえのブログ配信の帯域がやばき量なのでなんとかしなさい（意訳）」的なアラートメールが届きました。原因は明白で、このブログの画像をContentfulから配信する実装をしていたため、Contentfulのプランの帯域幅（月間あたりのデータ転送量）を超過してしまっていました。
このブログの構築は以下で紹介しています。大部分は当時のままです。
そんなわけで、このブログでは約1,300枚の画像をContentfulで管理しています。記事数が増えるにつれてビルドのたびにダウンロードされる画像の量も増え、いつの間にか上限に達してしまっていたのです。
応急処置としてのdownloadLocal無効化
とりあえずアラートメールをAIに突っ込んで「帯域がヤバいので対策を考えてください」のような指示をしました。まずは応急処置として、Gatsbyの設定でdownloadLocalを無効化することを提案されたのでそのまま実装してもらいました。
これにより、ビルド時にContentfulから画像をダウンロードせず、CDNのURLを直接参照するようになるとのことでした。gatsby-config.jsの該当箇所を特定し、修正案を提示してくれました。
ただ、流石にバックエンドに疎い私でもこれが帯域問題にクリティカルに効くものではないことはわかります。画像は引き続きContentful CDNから配信されるため、根本的に解決するはずがないと思いました。
localFileパターンへの切り替え
次にデプロイサーバー上に画像を保存して、そこから配信させるというのはどうか、のような指示をAIにして検討してもらいました。目論見としては、本番ビルド時のみdownloadLocalを有効にし、画像をNetlify側に静的ファイルとして保存する方法でした。こうすることで、ビルド時に一度だけダウンロードした画像をNetlify CDNから配信できます。
ただ、ここで日本語ファイル名の問題に直面しました。一部の画像ファイル名に日本語が含まれており、Gatsbyのプラグインがエラーを起こしていたのです。Antigravityと一緒にデバッグを進め、該当するプラグインにパッチを当てるスクリプトを作成しました。
しかし、その後も別のエッジケースが発生し、完全な解決には至りませんでした。それに、うまくいったとしても、Netlifyの有限の帯域を食い潰すのも時間の問題と思われたので、これも根本的な解決にはならないと思っていました。
Cloudflare R2への移行
なので、根本的に解決する方法を考えることに方針を転換するようAIに伝えました。そこで、いくつかのCDNに画像を移管して配信することを提案されましたが、どれも有償プランで月数十ドルの課金が発生することがわかり、このブログのわずかな広告収入では赤字運営をしなければならないことを一瞬覚悟しました。
ただ諦めたくなかったので、「無料で済む方法でなんとかしなさい」的な指示をしたところ、Cloudflare R2への移行を提案してもらいました。
Cloudflare自体は知っていましたが、R2がどんなサービスなのか料金プランまでは知らなかったのですが、R2はS3互換のオブジェクトストレージで、10GBまでは無料でなんと帯域転送量が無料ということを教えてくれました。そして、以下のような作業計画を提案してくれました。
Contentfulから全アセット情報をエクスポートし、マッピングファイルを作成
R2へのアップロードスクリプトを作成
GatsbyからR2のURLを参照するカスタムコンポーネントを作成
Netlifyビルド時に差分のみ同期する仕組みを追加
そんな素敵なものがあるならなぜ最初から提案してくれないのかと思いましたが、良さそうだったのでそれで実装を進めてみることにしました。
約1300アセットのアップロード
まず、マッピングファイルの作成とアップロードスクリプトの実装は比較的スムーズに進みました。R2はS3互換のAPIを持っているため、AWS SDKをそのまま使えるらしく、AIがよしなにスクリプトを生成してくれました。
アップロードを実行してみると、約1300件のアセットが正常に完了しました。 AIが生成したスクリプトには、既存アセットのスキップ機能や並列処理の仕組みが最初から含まれていて、効率的に処理できました。
ブログへの反映もほとんど一瞬で終わり、こんな一瞬で終わるとは、とちょっと怖かったです。
再びの日本語ファイル名問題
ところが、ブログを確認してみると、一部の画像が表示されていませんでした。AIに原因を調べもらうと、日本語を含むファイル名のアセットがR2に正しくアップロードされていなかったということでした。
問題の原因は、マッピングファイルを作成する際にURLエンコードされたファイル名を使っていたことらしく、実際にダウンロードされたファイルは生のファイル名（日本語のまま）で保存されているため、パスが一致しなかったと詳細に教えてくれました。
AIにほぼデバッグを任せ、ディレクトリを走査して実際に存在するファイルを見つける処理を追加して再度アップロードを実行し、今度は全アセットが正常に配信されることを確認できました。
R2への完全移行
最終的に、すべての画像がR2で設定したカスタムドメイン経由で配信されるようになりました。Contentfulの帯域幅使用量は限りなくゼロになり、今後は記事が増えても安心です。
計算上はあと20年は無償プランで戦えます。ありがとう、AI。
使ってみて感じたこと
「何をしたいか」を伝える力が試される
AIは指示がなければ動きません。「Contentfulの帯域を改善したい」ではなく、「Contentfulの帯域幅を節約するために、根本的に配信の仕組みを変えたい」と伝える必要があったのかなと思います。
これは、プロダクトに期待する振る舞いや仕様をエンジニアに伝えるときのスキルとほぼ同じだと感じました。曖昧な要望では、期待通りの結果は得られません。
技術的な対話の解像度が上がる
作業を進めるなかで、「なぜこの書き方をするのか」「この処理は何をしているのか」といった質問を繰り返しました。おかげで、今まで「なんとなく動いている」と思っていた裏側の部分への理解が多少深まりました。
エンジニアから「この実装は難しい」と言われたとき、その「難しさ」の輪郭が少し見えるようになったような気がします。（気がするだけです）
万能ではないことを知る
一方で、限界も感じています。生成されたコードが「動く」ことと「良い」ことはイコールではありません。
実際、日本語ファイル名の処理で何度かバグを踏んでいて謎の挙動を繰り返していたので強制的に止めて、「今何をしていますか？私には無意味な検証を繰り返しているように見えますが」のような指示を送ってやり方を見直しさせる場面も多くありました。
それ以外にも一部のエッジケースへの対応などは、やはり自分で考える必要がありました。
デザイナーがAIコーディングツールを使うメリット
ここまでの体験を振り返ると、デザイナーがAIコーディングツールを使うメリットは少なからずあると感じています。
まず、要望を言語化する力が鍛えられます。AIへの指示を通じて、自分が何をしたいのかを構造的に整理するスキルが自然と身につきます。これは普段のプロダクト開発で発生する開発者とのコミュニケーションにもそのまま活きるような気がします。
次に、技術への理解が深まります。今回の作業を通じて、今まで「なんとなく動いている」と思っていた部分への解像度が多少上がりました気がします。
そして、小さな実験を自分で試せるようになります。個人プロジェクトであれば、思いついたアイデアをすぐに検証できる。これは、デザイナーにとって大きな武器になると思います。Figmaで絵を描くステップをすっ飛ばしていきなりLo-Fiな動くプロダクトが作れるわけですから。
結局、デザイナーはコードを書くべきなのか
私の現時点での答えは、「ゼロから書けるようになる必要はないが、AIと一緒なら案外なんとかなる」です。
今回の体験を通じて思ったのは、AIコーディングツールはデザイナーにとって「コードを書くためのツール」というよりも、「エンジニアリングの世界を覗くための窓」のようなものだということです。覗いてみると、今まで見えなかったものが少しだけ見えるようになる。それだけでも、普段の仕事に良い影響があるように感じています。
もちろん、今回うまくいったのは個人ブログという「壊れても誰にも迷惑がかからない環境」だったからです。業務のプロダクト開発では、セキュリティや保守性の観点から、やはり品質に責任を持てる人の目が必要だと思っています。
もし興味があれば、まずは業務とは関係のない小さなプロジェクトから始めてみてはいかがでしょうか。失敗しても大丈夫な環境で試行錯誤するのが、最初の一歩として最適だと思います。
