最近は、構成・デザイン・実装までの一連の工程をAIを活用して見直し、既存の制作フローを組み直せないか日々試行錯誤しています。

現在、主に使っているのは以下のツールです。

• Google AI Studio
• Google Stitch
• Google Antigravity
• Figma
• Perplexity（調査用）

構成案・ワイヤー制作フェーズ

まず最初に行うのが、いわゆる構成案の作成です。  

この段階の最終成果物としては、通常の制作と同じように、画面構成がわかる構成案を作成するイメージです。

ここでは主に Google AI Studio を活用しています。  

事前の業界知識などは別途必要になりますが、それらを前提にしたうえでAIに指示を出し、ワイヤーとして落とし込んでいきます。

ただし、指示の仕方を工夫しないと、いわゆるAIっぽいワイヤーや、デザイン要素が強く出すぎたワイヤーになってしまうことがあります。

そのため、最初の段階で余計な装飾を避けることや、情報設計を優先することを意識して指示するようにしています。

最終的にはHTML形式で出力させたうえで、Figma上に html to design で貼り付ける場合もあれば、画像としてFigmaに貼る場合もあります。

なお、html to design は無料プランだと月10回までの制限があるため、実務で使う場合は、有料契約にするか、画像で対応するか、あるいは一度 Google Stitch に移植したうえで Figma に落とし込む、という形になります。Google Stitch には、Figma へのコピー機能もあります。

個人的には、Google AI Studio で作成したワイヤーを Google Stitch に移す際に、一発でうまくいかないケースがあったため、今は AI Studio → Figma で進めることが多いです。

あえてFigmaへ移すのは、フィードバックなどのコミュニケーションを取りやすいからです。

実務上も、Figma上でやり取りしたほうが進めやすいと感じています。

デザイン制作フェーズ

デザインについても、Google AI Studio を活用しています。

すでにワイヤーがある状態なので、それをベースにGoogle AI Studioへ指示を出し、デザインを作っていく流れです。

この段階で大変なのは、指示を的確に出さないと、まず意図しない成果物が返ってくることです。

また、1ページであればまだよいのですが、複数ページにまたがる場合は、デザインガイドラインをしっかり固めておかないと、全体のデザインが破綻しやすくなります。

Google AI Studio には、プロジェクト内で共通の指示を出せる機能があるため、それを活用しています。

また、対応しているかは不明ですが、design.md のような形でデザインガイドラインを作成し、それもあわせて読ませることで、ある程度アウトプットが安定するようにも感じました。

なお、1つのスレッドで扱えるトークン数には上限があるため、超えた場合は別スレッドを立ち上げるようにしています。

しっかりとしたデザインに仕上げるのは、思っていた以上に大変でした。

実務的にきちんとフィードバックできること、そしてこちら側にも引き出しがあることが重要なのだと感じています。

ここでもアウトプットはHTMLファイルです。

実装済みデザインとして出てくるため、これも Figma へ画像として貼る、もしくは html to design などで移管しながら、関係者とコミュニケーションを取っていきます。

実装フェーズ

実装については、Google Antigravity を利用しています。

すでにデザインがHTMLで出ているため、それをベースに実装を始める形です。

AIは、インラインでファイルを出してくるケースもあるため、まずは環境をしっかり整えることが大切だと考えています。

たとえば、ディレクトリ構成やスタイル・スクリプトの切り出しを整えておくことです。

AI生成データは Tailwind などを使っているケースも多いので、インラインのまま進めるのではなく、適切に環境を整えたうえで進めていきます。

そのうえで、使用するCMSや要件に合わせて、デザインフェーズで作成した静的なHTMLを調整していきます。

Google Antigravity には、使用するCMSの仕様書などをあらかじめ読ませておくことで、一定その仕様に沿って実装してくれる印象があります。

また、実装後にこちらに確認を求めてくる機能もあるため、コードは書かないが、チェックはしっかり行うという実用的な運用が可能です。

直近でアップデートされていますが、IDE環境のほうがこちらの運用には近いと感じています。

逆に、IDEではないタイプはバイブコーディングの思想が強そうです。IDEではない方を使う場合は、Cursorのような別ツールと併用するのがおすすめです。

実際にIDEではない方も試してみましたが、ボタンを押して進める作業が中心だったため、個人的にはIDE環境のほうが、編集箇所もリアルタイムで見られて安心でした。

このような流れで、AIを活用しています。

Google は有料プランを使っており、データの取り扱いについても設定面を確認しながら使っています。マスキングだけでは不安なこともあるため、自分の運用上は、こうした設定を前提にするのが安心だと感じています。

構成だけ、実装だけ、デザインだけという使い方もありますが、せっかくAIを入れるのであれば、既存のワークフローを大きく変える形にできないか、日々調整しています。

AI活用で感じたこと

実際にAIを活用してみて感じるのは、前提としてドメイン知識がないと構成の手が止まることです。

また、デザイン指示をしっかり出せないと、うまくいきません。

さらに、実装の知見がないと、予期せぬものが紛れ込むこともあります。

そのため、各工程の知見はしっかり身につけていく必要がありそうだと感じています。

加えて、AIにも上限があるため、コスト面の考慮も必要です。

一方で、単純な作業に限ればAIのほうが強い場面も多く、今後は、各工程における成果物への責任を負わない人は厳しくなっていくのではないかと感じています。

• 構成やデザインであれば、事業ドメインを踏まえて提案できる人。
• 実装であれば、コードに問題がないかをしっかり責任を持てる人。

そういった役割が、より重要になっていくのではないかという印象です。