「クライアントから『リッチなアニメで動きのあるサイトに』と言われたけど、予算ってどれくらい見ればいいの？」

制作会社・ディレクターの皆さん、こうした相談を受けたとき、即答できますか？アニメーション実装は「ちょっと動かす」と「リッチに動かす」で費用が10倍違うこともあります。

今回はアニメ実装の予算感と発注のコツを、ライブラリ別・難易度別に整理します。

結論：アニメは「3段階」に分けて考える

※あくまで目安。デザインの複雑さ・調整回数で変動します。

① CSSアニメで足りるケース

「企業サイトのキレイ目な動き」程度なら、CSSアニメで十分です。

• セクションのフェードイン・スライドイン
• ボタンのホバーで色変化・伸縮
• 背景のループアニメ
• ローディング画面

軽量で速度も速いので、SEOにも有利です。Core Web Vitals記事でも触れたように、過剰なJSアニメは速度悪化の原因に。

② GSAP（ScrollTrigger）が必要なケース

「スクロールに連動して要素が動く」「画面の中で要素が連続的に変化する」レベルになると、GSAPが必須です。

• パララックス（背景と前景の異なるスクロール速度）
• ピン留め（要素が画面に固定された状態でアニメ）
• 横スクロール風の演出
• テキストの一文字ずつアニメ

制作会社が知っておきたいGSAPの料金事情：商用利用は基本的にライセンス不要ですが、ライセンス料がかかるパターン（Bonusプラグイン）もあります。

③ WebGL / Lottieを使うリッチ系

3Dモデル・パーティクル・ピクセル単位の制御が必要な場合は、Three.js・WebGLが選択肢。

Lottieはアニメーション特化のJSONフォーマット。After Effectsで作ったアニメをそのまま再生できる、軽量で品質も保てる便利な手法です。

発注時に伝えるべき情報

• 参考サイトURL（「こんな動きにしたい」具体例）
• アニメ箇所の優先度（必須 / あったら良い）
• 動きの仕様（速度・タイミング・トリガー）
• 対応ブラウザ・デバイス（iOS Safariも動く？）
• パフォーマンス要件（速度を犠牲にしないか）

「とりあえず動かして」の罠

「とりあえず動きあれば」と発注すると、実装フェーズで認識ズレが頻発します。「思ってたのと違う」となって何度も修正、結局割増料金。

事前に参考サイトURLを3つ以上用意して、「この中で言うと②に近い」と指定するのがおすすめ。

パフォーマンスのトレードオフ

リッチなアニメは見栄えしますが、ファーストビューの表示速度を遅くする可能性があります。

• JSサイズが増える → 初期ロード遅延
• 計算量が多い → スクロール時のカクつき
• モバイルで重い → 離脱率増加

クライアントには「アニメリッチ vs 高速表示」のトレードオフを事前に説明しましょう。

ライブラリ選定はコーダー側に委ねるべき？

結論：選定理由を聞ける関係なら委ねるのが正解。ライブラリの強み弱み・案件規模・運用フェーズまで考慮した選定は、現場感がないとできません。

「なぜそれを選んだか」を説明できるコーダーは信頼できます。

まとめ

アニメ実装は「3段階の費用感」と「具体的な参考URL」で発注精度がぐっと上がります。パフォーマンスとのトレードオフもクライアントに事前共有を。

「リッチアニメで提案したい案件がある」「GSAPやLottieに強いコーダーを探している」という方は、おくだ屋のパートナーサービスからお気軽にご相談ください。