- 生成AI
- アニメーション
【GSAP】公式SkillsでGSAP制作はどう変わる?AI出力を検証

AIを使ったGSAPアニメーション制作では、AIがどれだけGSAPを理解しているかで、出力されるコード品質が大きく変わります。
そこで活用したいのが、GSAPをAIに正しく理解・実装させるための公式Skillsです。
この記事では、GitHubで公開されているGSAP Skillsの導入方法から、Skillsあり・なしでAIの出力がどう変わるのか、さらにAIへ分かりやすく指示を出すコツまで、実際の検証を交えながら解説します。
目次
Skillsとは何か
Skillsとは、AIに対して特定分野の知識やルールを補足するための仕組みです。
今回扱うGSAP Skillsは、GSAPに関する知識や推奨構文、設計パターンをAIへ追加学習させるためのデータセットです。
GitHub上では、以下のような内容が整理されています。
- 基本構文
- プラグインの使い方(推奨のコードや禁止事項など)
- Reactでアニメーションを作成したい場合の使用方法
など。
これにより、AIがGSAPの文脈を理解しやすくなり、より実践的なコードを返しやすくなります。
GSAP Skillsの導入手順
GSAPの公式SkillsはGitHubから確認できます。
基本的な導入の流れは以下です。
1. リポジトリを確認する
GitHub上では、GSAPに関する知識セットや使用例が整理されています。
まずはREADMEを確認しましょう。
※英語のページですが、ブラウザの翻訳機能を使えば日本語で確認できます。Chomeをお使いの場合はページ上で右クリックして「日本語に翻訳」を選択するとページ全体を翻訳できます。
2. AIツールへ読み込ませる
Claude CodeやCodeXなど、使用したいAIツールに読み込みます。
読み込み方法はツールごとに異なるため、詳細はREADMEを確認してください。
今回はCodexを使用します。Codexの場合は、以下のコマンドでインストールできました。
npx skills add https://github.com/greensock/gsap-skills

デモサイトを使ってAIにアニメーション指示する
今回は検証用として、シンプルなデモサイトを用意しました。
構成は以下のような一般的なLPイメージです。
- FV
- サービス紹介セクション
- 製作実績セクション
- CTAエリア

このサイトに対して、AIへGSAPアニメーションの実装を依頼し、「Skillsなし」と「Skillsあり」でどのような違いが出るのかを検証していきます。
どちらも同じHTML、CSSを使用したサイト・同じ指示内容で実行し、生成されるコードやアニメーションの違いを確認します。
今回AIへ渡したプロンプトはこちらです。
# 依頼内容
GSAPとScrollTriggerを使用したモダンで洗練されたWebアニメーションを追加してください。
# 実装したいアニメーション
1. ファーストビュー(FV)のロード演出:
- メインの見出しをタイピング風に表示する(一文字ずつ出現させ、タイピング風のバーを用意する)。
- 説明文は少し遅れてフェードインさせる。
- ボタンも順番に表示させる。
2. スクロール連動のFV演出:
- スクロールを開始すると、FV全体が一時的にその場に固定され、メインタイトルとテキストが画面の奥へと吸い込まれるように縮小・フェードアウトしながら、次のセクションを引き寄せる演出にする。
3. 実績セクション:
- 実績カードが右から左へ流れる「横スクロール」の演出にする。
4. その他:
- 指定のない箇所(サービスセクション等)には、サイトの雰囲気に合わせたおすすめのアニメーションをScrollTriggerを使って追加してください。
# 満たすべき条件
- 実務レベルのコードと見た目にする。
- 高級感があり、静かで洗練された雰囲気を意識したイージングや速度設定にすること。
- アニメーションは幅が300px以上の時とし、それ未満の表示への考慮は不要。
こちらのプロンプトでAIがどこまで意図を理解できるか、また実務的なコードを出力できるか比較してみます。
Skills導入前と後のAI出力結果(見た目や動き)を比較する
Skillsありのサイト
できたサイトはこちらです。
見た目の話をすると、
おおよそ指示通りではありますが、ちょっと動きが不安定に感じました。
まずFVのタイピングアニメーションが上手くいってません。
文字の後ろにバーがあるのが理想の動きですが、文字の下に出てしまっています。
また、実績では、要素のフェードインと横スクロールを同時に行おうとしているせいか、最初にカクつきを感じます。
横スクロールが終わったタイミングでもガクッとなってしまっています。
では次に、Skillsなしで出力したサイトも見て行います。
Skillsなしのサイト
できたサイトはこちらです。
こちらも全体の方向性としてはある程度指示通りに実装されていました。
ですがSkillsありの時と同様、FVのタイピングアニメーションが上手くいっていなかったり、横スクロールで少しカクつきを感じました。
致命的な問題もあり、ページ途中でリロードすると動作が崩れてしまいます。
原因を確認すると、FVのタイピングアニメーションなどが完全に終わるまで、pin(要素の固定)を設定するScrollTriggerが生成されないようになっていました。
そのためページ途中までスクロールした状態でリロードすると、ScrollTriggerの初期化タイミングがズレてしまいます。
結果としてレイアウトが崩れたり、アニメーションが開始されなかったりと、ページ全体に問題が発生していました。
単純にGSAPのコードを書けるだけではなく、ScrollTriggerの初期化タイミングやリロード時の挙動まで考慮できているかが実務ではかなり重要だと感じます。
Skills導入前と後のAI出力結果(コード)を比較する
それでは、Skillsありとなしとで出力されたコードを比較してみます。
Skillsありのサイト
Skillsなしのサイト
コードを比較してみると、大きい違いはいくつかありました。
1.ScrollTrigger.batch()を使っていた
Skillsありのコードでは、サービスカードのアニメーションに ScrollTrigger.batch() が使用されていました。
ScrollTrigger.batch(serviceCards,
batch() は、複数要素のアニメーションを効率良く管理できる機能です。
今回のようなカード一覧では、複数の要素が同時に画面へ入ってくることが多いため、パフォーマンス面や管理面でメリットがあります。
一方、Skillsなしでは gsap.from() をそのまま実行する構成になっていました。
batchを使用しない場合、各要素が画面に入るたびに、その要素単体でスクロール判定とアニメーション処理が実行されます。例えば要素が100個あれば、100回分の判定と処理が個別に発生します。
一方 batchは、短い時間内に画面へ入ってきた要素を内部でまとめて管理し、配列として onEnter に渡してくれます。
そのため stagger と組み合わせることで、自然な時間差アニメーションを効率良く実装できます。
今回のような複数要素が一度に画面へ入るケースでは、batchを使用する方が効率的で、Skillsありのコードは実務を意識した構成になっていると感じました。
2. GSAP推奨のレスポンシブ方法になっていた
Skillsありでは、レスポンシブでgsap.matchMedia()を使用していました。
const mm = gsap.matchMedia();
GSAP公式で推奨されている書き方で、画面サイズごとにアニメーションを切り替えやすくなっており、ブラウザのウィンドウサイズが変更された際にもアニメーションの適用・解除が動的に切り替わります。
一方、Skillsなしではwindow.matchMedia()を使用していました。しかもロード時にしか判定しないため、ウィンドウサイズを変更した際に対応できません。
const desktopQuery = window.matchMedia("(min-width: 300px)");
gsap.matchMedia()を使うと、リサイズ時のメディアクエリごとの処理やクリーンアップを自動化できて非常に便利です。
3.toggleActionsを使っていた
Skillsありでは、複数箇所で toggleActions が使われていました。
toggleActions: "play none none reverse"
これによって、「画面に入ったら再生し、戻ったら逆再生する」といった細かい制御ができるようになっています。
一方、SkillsなしではtoggleActionsがなく、onceが多く使われていました。
once: true
こちらは「一度だけ再生する」というシンプルな設定で、分かりやすい反面、細かな再生制御はできません。
そのためSkillsありの方が単純にアニメーションを動かすだけではなく、ScrollTriggerの仕様まで理解して実装している印象を受けました。
4. バグになりにくい構成になっていた
Skillsなしでは「ロード演出が終わってからScrollTriggerを生成する」という流れになっていました。そのため、ページ途中でリロードすると、pin位置やスクロール計算が崩れてしまう問題が発生していました。
一方、Skillsありでは、DOMContentLoaded時点でScrollTriggerを生成しており、初期化タイミングがかなり安定しています。
この違いはかなり大きく、単純にGSAPでアニメーションを作成するだけでなく、GSAPの仕様や動作を理解している印象を受けました。
比較して感じたこと
Skillsありの方がGSAPの仕様に則ったコードになっていました。
特にbatch() やgsap.matchMedia()、toggleActionsなど、GSAPを理解している実装が含まれていた点は大きな違いです。
ただし、Skillsありでも完璧なアニメーションを最初の出力で出せるわけではなく、確認や調整は人間側で行う必要があると感じました。
AIに伝わりやすい指示の作り方
今回検証していて感じたのは、AIへアニメーションを依頼する際は、できるだけ具体的に指示を書くことが重要だという点です。
実は記事内で紹介したプロンプト以外でもいくつか試したのですが、「タイピング風に表示する」などの具体的な動きを含めたり、「高級感があり、静かで洗練された雰囲気を意識」などのイメージまで伝えることで、意図に近いコードが出やすくなりました。
特にGSAPのような演出系では、「何を動かすか」だけではなく、「どう感じてほしいか」まで言語化することが大切だと感じます。
なお、今回紹介したプロンプトは、Skillsあり・なしでどのような違いが出るかを比較する目的だったため、あえて細かく指定しすぎない形にしています。
もし具体的なイメージや動きが決まっている場合は、それをできるだけ言語化して伝えるのがおすすめです。
また、「どう指示を書けば良いか分からない」という場合は、プロンプトの作成自体をAIへ相談しながら進めるのもおすすめです。
まとめ
今回は、GSAP Skillsを導入した状態と導入していない状態で、AIがどのようなコードを出力するのかを比較してみました。
実際に試してみると、Skillsを使うことでGSAPらしい構成やScrollTriggerを意識したコードが出やすくなると感じました。
特に、「ScrollTrigger.batch()」「gsap.matchMedia()」「toggleActions」など、GSAPを理解していないと出てきにくい実装が含まれていたのは大きな違いであり、メリットと言えるでしょう。
一方で、Skillsを入れたからといって必ず高品質なアニメーションになるわけではありません。
実際には意図した動きにならなかったり、カクつきが発生したりする場面もあり、最終的な調整や品質確認は人間側で行う必要があります。
そのため、Skillsは「高品質なコードを自動生成するもの」というより、「よりGSAPを理解したコードを出しやすくする補助」と考えるのが良さそうだと思いました。
ぜひSkillsを導入してみて、AIを活用したGSAPアニメーション制作を試してみてください!
ドコドア エンジニア部
このブログでは、アプリ開発の現場で培ったフロントエンド、バックエンド、インフラ構築の知識から生成AI活用のノウハウまで、実践的な情報をアプリ開発に悩む皆様へ向けて発信しています!
【主な技術スタック】 Flutter / Firebase / Svelte / AWS / GCP / OpenAI API