CSSアニメーションをAIで作るなら、動きを言葉で説明するより「動くコードを渡す」方が速く、正確です。CodeQuest.workのアニメーションギャラリーはコピペできるHTML/CSSを出力するので、その完成コードをそのままClaudeやChatGPTに読ませれば、解釈のブレないプロンプトになります。ゼロから言葉で指示するのではなく、すでに動く土台を渡して「ここをこう変えて」と頼む——これがAIとCSSアニメを共同制作する最短ルートです。
「ふわっと弾むボタンを作って」とAIに頼んだら、想像とまったく違う動きが返ってきた——CSSアニメーションをAIに任せると、この”解釈のズレ”で何度もやり直す羽目になりがちです。原因は、動きという視覚情報を言葉だけで正確に伝えるのが難しいから。タイミング・イージング・座標といった数値は、文章にした瞬間に曖昧になります。
この記事では、「動くコードこそが最強のプロンプトになる」という考え方を軸に、ギャラリーが出力するHTML/CSSをAIに渡してアニメーションをカスタム・合成・移植する具体的な手順を解説します。うまくいく指示の書き方、つまずきやすいポイント、そして完成したサイトを次の段階（SEO）へ進める流れまでを通してまとめます。
なぜ「言葉のプロンプト」はCSSアニメーションに向かないのか
CSSアニメーションは、@keyframesでの状態変化・duration（再生時間）・timing-function（イージング）・transformの座標など、多数の数値パラメータの組み合わせで動きが決まります。これを言葉だけで伝えようとすると、必ず情報が落ちます。
たとえば「弾むように出てくる」という指示。これだけでは、どこから出てくるのか、何秒かけるのか、弾みの強さ（cubic-bezierの値）はどれくらいか、最後に少し縮むのか——AIは判断材料がないため、毎回ちがう”それっぽい”動きを生成します。結果、こちらの頭の中にある動きに近づくまで、言葉を足しては試すループに陥ります。
そもそもAIへの指示は、抽象的な説明より具体例を与えるほうが出力の精度と一貫性が上がることが知られています（出典: Anthropic公式 プロンプトエンジニアリングガイド）。CSSアニメーションにおける「最高の具体例」とは、ほかでもない実際に動くコードそのものです。
動くコードが最強のプロンプトになる理由
結論から言えば、完成したCSSコードをAIに渡せば、動きの定義は100%正確に伝わります。コードには曖昧さがありません。animation-duration: 0.6s;と書かれていれば、AIはそれを0.6秒と理解します。言葉で「だいたい0.6秒くらい」と伝えるのとは、伝達の精度がまるで違います。
言葉のプロンプトとコードのプロンプトを、4つの観点で比べると違いは明確です。
| 観点 | 言葉のプロンプト | コードのプロンプト |
|---|---|---|
| 正確性 | 解釈のブレが出る | 数値まで一意に伝わる |
| 速さ | 近づくまで試行錯誤 | 動く土台から一発で改造 |
| 再現性 | 毎回ちがう結果 | 同じ入力なら同じ起点 |
| カスタム性 | ゼロから組み立て | 差分だけ指示すればよい |
ポイントは、動くコードは「すでに正解の一つ」であるという点です。AIはゼロから正解を探す必要がなく、与えられた動く土台を起点に「差分」だけを考えればよくなります。これは出力の安定性にも、こちらの意図の通りやすさにも直結します。だからこそ、CSSアニメーションギャラリー（コピペでコードを取得できる無料ツール）のように、最初から動くHTML/CSSが手に入るツールは、AI共同制作と相性が抜群なのです。
ギャラリーのコードをAIに渡す手順【4ステップ】
実際の流れは、次の4ステップです。言葉でアニメを生成させるのではなく、「動く土台を選んで → 渡して → 差分を指示して → 確認する」という順序になります。
ステップ1：ギャラリーで近い動きを選ぶ
まず、作りたいイメージに近い動きを実物で選びます。ゼロから言葉で発想するより、フェード・スライド・バウンス・3Dなど、動くサンプルを見比べて「これに近い」を起点にするほうが圧倒的に速いです。完成形のイメージが固まっていなくても、候補を眺めるうちに方向性が定まります。
ステップ2：HTML/CSSをコピーする
選んだアニメーションの@keyframes付きコードをコピーします。このときコードは省略せず、丸ごと渡せる状態にしておくのが重要です。AIに渡す”プロンプト本体”がこのコードになるため、一部だけ切り取ると、せっかくの正確さが損なわれます。
ステップ3：AIに渡して差分を指示する
コピーしたコードをClaudeやChatGPTに貼り、「このコードをベースに、何をどう変えたいか」だけを伝えます。動きの定義はコードが担うので、こちらは変更点（差分）に集中できます。指示の型は次のとおりです。
以下は動作するCSSアニメーションのコードです。
これをベースに、次の点だけ変更してください。
- 色をブランドカラー（#4f46e5）に変更
- 再生時間を0.6秒に
- 対象要素はボタン（<button>）に適用
- そのまま動く完成形のHTML/CSSで出力
【ここにギャラリーからコピーしたコードを貼り付け】ステップ4：出力を検証し、ツールで微調整する
AIの出力は必ずブラウザで動かして確認します。意図どおりなら採用、ズレていれば「もう少し弾みを強く」「最後に10%縮めて」と、また差分だけ伝えて詰めていきます。数値の微調整は、AIに頼むよりギャラリーツール上でパラメータを動かしたほうが速いケースも多いので、AIで大枠を作り、ツールで仕上げるという役割分担が効率的です。
実例：フェードインのコードを渡してボタン用に改造する
4ステップを、実際のコードで通してみましょう。ギャラリーにある「下からふわっと出るフェードイン」を土台に、送信ボタン用のアニメーションへ作り替えるケースです。
まず、ギャラリーからコピーした元のコード（動く土台）がこちらです。これがAIに渡す”プロンプト本体”になります。
.fade-box {
animation: fadeInUp 1s ease both;
}
@keyframes fadeInUp {
from { opacity: 0; transform: translateY(20px); }
to { opacity: 1; transform: translateY(0); }
}このコードを丸ごと貼り、変えたい点（差分）だけを箇条書きで指示します。指示文は次のとおりです。
以下は動作するCSSアニメーションです。これをベースに変更してください。
- 対象を送信ボタン（<button>）に
- 背景色 #4f46e5・文字色 白・角丸のボタンスタイルを付与
- 再生時間を0.6秒に短縮
- @keyframes名は衝突しないようリネーム
- そのまま動く完成形のHTML/CSSで出力
.fade-box { animation: fadeInUp 1s ease both; }
@keyframes fadeInUp { from { opacity:0; transform:translateY(20px);} to {opacity:1; transform:translateY(0);} }すると、動きの定義（下から16〜20px上がりながらフェードイン）を保ったまま、ボタン要素・色・速度だけが置き換わった完成形が返ってきます。
<button class="btn-fade">送信する</button>
<style>
.btn-fade {
background: #4f46e5;
color: #fff;
border: none;
padding: 12px 24px;
border-radius: 8px;
animation: btnFadeInUp 0.6s ease both;
}
@keyframes btnFadeInUp {
from { opacity: 0; transform: translateY(16px); }
to { opacity: 1; transform: translateY(0); }
}
</style>注目したいのは、「下からふわっと上がる」という動きの本質は一切ブレていない点です。もし同じ依頼を言葉だけ（「ボタンが下からふわっと出るアニメを0.6秒で」）で投げていたら、上がる距離もイージングも毎回変わったはずです。動くコードを土台にしたからこそ、変更は指示した差分だけにきれいに収まりました。あとはブラウザで動かし、必要なら「上がる距離をもう少し大きく」と差分を足して仕上げれば完成です。
コードを渡してAIにできること
動くコードを土台にすると、AIへの依頼はぐっと幅が広がります。ゼロから生成させるときは「うまく作れるか」が不安定でしたが、すでに動くコードがあれば、依頼は「これをどう変えるか」という確実性の高い作業に変わります。ここでは、実務でよく使う代表的な活用パターンを4つ紹介します。どれも共通して、土台のコードを丸ごと渡したうえで変更点を指示する流れです。
色・速度・イージングの変更
もっとも手軽な改造です。「色をサイトのテーマカラーに」「もう少しゆっくり」「跳ねる感じを強めに」など、感覚的な依頼でも、動く土台があればAIは該当の値（durationやcubic-bezier）を狙って書き換えてくれます。
複数アニメーションの合成
ギャラリーから2つのコードを渡して「フェードインしながらスライドアップする動きに合成して」と頼めば、単体では用意されていない複合的な動きを作れます。土台が2つとも”動く正解”なので、合成の失敗が起きにくいのが利点です。
React・Vue・Tailwindへの移植
素のHTML/CSSのコードを渡して「これをReactコンポーネントにして」「Tailwindのクラスで書き直して」と頼めば、フレームワークに合わせた形へ変換できます。動きの仕様はコードが保証するので、移植でニュアンスが変わる事故を防げます。
自分のコンポーネントへの適用
すでにある自分のボタンやカードのコードと、ギャラリーのアニメーションコードを両方渡して「この要素にこの動きを付けて」と依頼すれば、既存UIに動きを後付けできます。クラス名や構造の衝突もAIが調整してくれるため、手作業のマージより安全です。
どんなアニメーションを土台に選ぶとよいか
AI改造の成否は、最初に選ぶ土台によっても変わります。同じ「渡して改造する」でも、AIで化けやすいコードと、扱いにくいコードがあるからです。土台選びの段階で次の傾向を知っておくと、後の手戻りが減ります。
- 単一要素で完結する動き（フェード・スライド・バウンスなど）は、対象要素やパラメータの差し替えが効きやすく、改造に向く
@keyframesが素直に分離されたコードは、AIが構造を保ったまま書き換えやすい。逆に複数の動きが1つに絡まっていると編集が難しくなる- JavaScript依存が強い複雑な動き（物理演算・大量のDOM操作）は、土台にすると改造の副作用が読みにくくなりやすい
- まずシンプルな動きを土台に選ぶ。必要に応じてAIに「ここに〇〇の動きも足して」と段階的に複雑さを重ねるほうが安定する
迷ったときは、見た目が完成形に近いものより「構造がシンプルなもの」を選ぶのがコツです。土台が単純なほどAIは差分を正確に当てられ、出力を読んで自分で直すときの負担も小さくなります。最終的な見た目は、シンプルな土台にあとから要素を足していくほうが、コントロールしやすいのです。
AIに任せる部分・人が判断する部分
コードを渡す方式は強力ですが、何でもAIに丸投げすればよいわけではありません。良いアニメーションは「どう動かすか」より「どこに・どれくらい使うか」で決まるからです。AIに任せる範囲と、人が判断すべき範囲を分けて考えると、仕上がりの質が安定します。
| 役割 | 担当 | 内容 |
|---|---|---|
| 動きの実装・変換 | AI | コードの書き換え・合成・フレームワーク移植・デバッグ |
| 動きの選定・配置 | 人 | どの動きを選ぶか・どの要素に付けるか・どれだけ使うか |
AIは「指定した動きを正確に実装する」のは得意ですが、そのアニメーションがそのページに本当に必要か、過剰になっていないかまでは判断してくれません。ページ中の要素が一斉に動くと、かえって読みにくく安っぽい印象になります。動かす要素は絞り、ユーザーの視線を導きたい箇所（CTAボタン・重要な見出し・初回表示）に限定する——こうしたUX上の判断は、人が握っておくべき領域です。
言い換えると、AIは「動きを量産する道具」、人は「どの動きを採用し、どこで使うかを決める編集者」です。ギャラリーで土台を選ぶ段階と、最後に動作を確認する段階に人の判断を効かせれば、実装の手間はAIに預けつつ、デザインの質はコントロールできます。
うまくいく指示の書き方（ダメ例・良い例）
コードを渡すスタイルでも、指示の書き方で結果は変わります。コツは「コードを丸ごと貼る ＋ 変更点を箇条書き ＋ 出力形式を指定」の3点です。
| ダメな指示 | 良い指示 |
|---|---|
| 「かっこいいボタンのアニメを作って」 | 「このコードをベースに、ホバー時だけ発火・0.3秒・色#111に変更して」 |
| コードの一部だけ貼る | @keyframesまで含めて丸ごと貼る |
| 出力形式を指定しない | 「そのまま動くHTML/CSSで」と明記する |
「かっこいい」「いい感じに」のような主観的な言葉は、コードを渡していても解釈がブレます。変えたい点は具体的な値や条件で伝えるのが鉄則です。動きの土台はコードに任せ、言葉は”差分の指定”に徹する——この分担を意識すると、やり取りの回数が目に見えて減ります。
注意点・よくある失敗
コードを渡す方式でも、いくつかの落とし穴があります。違和感が出たら、まずここを疑ってください。
- コードを省略して渡す：
@keyframesや対象要素のスタイルを省くと、動きの定義が欠けてAIが推測で補う。丸ごと渡すのが大原則 @keyframes名の衝突：複数のアニメを合成・適用するとき、同名のキーフレームがあると上書きされる。AIに「名前が衝突しないようリネームして」と一言添える- ベンダープレフィックス：古い環境向けに
-webkit-等が必要なら、その旨を明示しないと省略されることがある - 出力を確認せず使う：AIの出力が必ず動く保証はない。ブラウザでの動作確認は省略しない
CSSアニメーションそのものの仕組み（@keyframesやtransition）をもう少し体系的に押さえておくと、AIの出力を読んで修正する精度が上がります。基礎を固めたい場合はWebアニメーション完全ガイド（Animate.css・AOS・IO・GSAPの比較）もあわせて読んでおくと、実装方法の引き出しが増えます。
アニメが完成したら、次はSEOで「見つけてもらう」
狙いどおりのアニメーションが付いて、思い描いたサイトが完成したら——最後の仕上げはSEOです。どれだけ作り込んでも、検索で見つけてもらえなければアクセスは生まれません。作ったページがきちんと評価される状態になっているか、公開前にチェックしておくのが次の一手です。
CodeQuest.work SEOなら、URLを入れるだけでページのSEOスコアと改善ポイントがその場でわかります。無料プランでも毎月3回までURL診断ができるので、完成したサイトの健康診断にそのまま使えます。
よくある質問
Q. ClaudeとChatGPT、CSSアニメ作りにはどちらが向いていますか？
どちらも動くコードを渡す方式に対応できます。一般にコードの構造を保ったまま丁寧に書き換える用途ではClaude、対話しながら素早く試す用途ではChatGPTが扱いやすいと言われますが、本記事の方式（コードを土台に差分を指示する）なら、どちらでも精度の高い結果が得られます。手元で使い慣れたほうで問題ありません。
Q. 言葉のプロンプトはもう一切不要ということですか？
いいえ。言葉は「何を変えたいか」という差分を伝えるために使います。要らなくなるのは「動きをゼロから言葉だけで説明する」工程です。動く土台はコードで渡し、変更点を言葉で添える——この役割分担が最も効率的です。
Q. ギャラリーのコードをAIに渡して改造したものは商用利用できますか？
CSSアニメーションのような汎用的な実装は、一般的なコードスニペットとして自分のプロジェクトに組み込んで利用できます。ただし利用条件は提供元の規約によるため、配布元の記載を確認してください。AIが生成・改変したコードについても、最終的な動作確認と責任は利用者側で行う前提です。
Q. AIが出力したコードが動かないときは？
まず@keyframes名やクラス名の衝突、対象要素のセレクタ違いを疑います。動かない箇所のHTMLとCSSをそのままAIに貼り、「この組み合わせで動かない原因を特定して直して」と差し戻すのが早道です。元のギャラリーのコードは動く状態なので、改造後に動かなくなった場合は”差分”のどこかに原因があります。
Q. 複雑な動きはGSAPなどのライブラリを使うべきですか？
スクロール連動や緻密なタイムライン制御が必要なら、GSAPなどのJavaScriptライブラリが向いています。一方、ホバーやローディング、出現演出といった単発のアニメーションは、CSSだけで軽量に実装できます。まずCSSで作れる範囲かを見極め、必要に応じてライブラリへ広げるのが現実的です。手法ごとの違いは比較ガイドで整理できます。
Q. デザインの知識がなくても使えますか？
使えます。むしろ「動く完成形を選んで渡す」方式は、ゼロから動きを設計する必要がないため、デザインや実装に不慣れな人ほど恩恵が大きい手順です。ギャラリーで気に入った動きを選び、変えたい点をAIに伝えるだけで、自分のサイトに合ったアニメーションを用意できます。
まとめ
CSSアニメーションをAIで作るコツは、動きを言葉で説明しようとしないことです。タイミングやイージングといった数値は言葉にすると必ずブレるため、すでに動くコードを”プロンプト”として渡し、変更点（差分）だけを指示するのが最短ルートになります。ギャラリーが出力するコピペ可能なHTML/CSSは、そのまま最高の入力素材になります。言葉でゼロから生成させる発想を捨て、「動く正解を渡して差分を指示する」という発想に切り替えるだけで、AIとのやり取りの回数も仕上がりの精度も大きく変わります。
「近い動きを選ぶ → 丸ごと渡す → 差分を指示する → 動かして確認する」の4ステップを回せば、色の変更から複数アニメの合成、フレームワークへの移植まで、思いどおりのカスタムが安定して作れます。AIで大枠を作り、ツールで仕上げ、完成したらSEOで見つけてもらう——この流れで、作ったものをしっかり届けるところまで進めましょう。
