- Lottieはベクターグラフィックアニメーションのためのオープンファイルフォーマットで、Adobe After Effectsで作成したアニメーションをWebやモバイルで簡単に再生できるようにする
- アニメーションはJSONフォーマットで保存され、キーフレーム、イージングカーブ、レイヤー情報など、すべてのアニメーション要素を含んでいる
- このフォーマットは拡張性、解像度非依存、多様なレンダラー実装などを備えたオープン標準であり、数多くの企業がユーザー体験向上に活用している
- Lottie Animation Community (LAC) はLinux Foundation傘下の非営利オープンソースプロジェクトであり、このフォーマットを業界標準へと発展させることを目標としている
- 仕様書、検証ツール、実装、ロードマップなどがコミュニティによって開発・公開され、誰でも参加できる透明で協調的な構造で運営されている
Lottieとは何か
概要
- Lottieは2015年にHernan Torrisiによって開発されたオープンソースのベクターアニメーションフォーマット
- After Effectsで作成したアニメーションをLottie JSONファイルとして書き出し、さまざまなプラットフォームで再生できる
- 現在はWeb、モバイル、TVなど多様なプラットフォームで広く使われている標準的なフォーマット
特徴
- ベクターグラフィックベース
- ピクセルベースではなく**幾何学的な図形（線、曲線など）**で構成されており、解像度に依存せず鮮明な画像表現が可能
- トゥイーン（Tweening）
- アニメーターが定義したキーフレーム間の変化を自動的に補間（interpolate）する方式
- 複雑なモーションを手動で作らなくても滑らかなアニメーション演出が可能
- JSONベースのフォーマット
- JSONで表現されているためWebでの送信が容易で、既存ツールで編集したり自動化処理したりしやすい
- オープン標準なので誰でも実装を作成でき、相互運用性に優れている
- 成熟したエコシステム
- プレイヤー、アセット、制作ツール、ライブラリなど、多様なエコシステムがよく整備されている
- Airbnb、Googleなど数多くの企業が利用しており、さまざまなツールやフレームワークでサポートされている
Lottie Animation Community (LAC)
- Lottieの標準化と普及のためにLinux Foundation傘下に設立された非営利コミュニティ
- Lottieファイルフォーマットをクロスプラットフォームのアニメーション標準として確立することを目標としている
- Joint Development Foundationのガバナンスのもとで運営され、オープンな協業方式を志向している
- 明確な仕様文書、検証ツール（Validator）、実装一覧、ロードマップなどを通じてエコシステムの基盤を提供
- 誰でも参加し貢献できる構造で、透明性とコミュニティ主導の発展を重視している
1件のコメント
Hacker Newsの意見
Lottieを使うたびに惜しいと感じるのは、アイデア自体は本当に素晴らしく、アニメーターがすでに使っているツールからそのままアニメーションを抽出できる点は魅力的なのに、実装の仕方があまりにも残念だからです。この分野では、もっとコンパクトなバイナリ形式のほうがずっと適しているのに、数値データの塊をわざわざJSONで保存しています。しかもJSONが外部ファイルを参照できるため、実際には複数ファイルがフォルダに入っていたり、ファイルがbase64でJSON内にインライン化されていたり、あるいは全体が圧縮された単一ファイルとして提供されたりします。Webで読み込むと、非常に大きなSDKを読み込まなければならず、このアニメーションは複数ファイルを別々に読み込むか、あるいは1つのファイルを何度も別のパーサー（JSON、base64、png、lottie、zipなど）で処理する必要があります。.lottieファイルを使うとJSバンドルにzip展開器まで含める必要があり、別の.lottieプレーヤーには2MBのwasm blobが含まれていますが、なぜそうなるのかよく分かりません。私たちのアプリではこのせいでアプリ容量削減にかなり苦労しましたが、幸いクリティカルパスでは使っていなかったので、この程度で済みました。アニメーション最適化、パスやインラインの問題の手修正、ベクターがpngに変わるバグ対応など、多くの泥臭い作業が必要でした。しかもブラウザは複数のアニメーションを同時再生するとあまり耐えられず（特に低性能デバイスで）、JSとDOMでのアニメーション処理効率は思ったほど良くありませんでした。週末プロジェクトとして時間があれば、これを最適化したSVGスプライトに変換し、CSSトランジションで再生したらもう少し良くなるか実験してみようかと思っています
本当にその通りで、After EffectsからLottieへ書き出すワークフローは特にひどかったです。多くのレイヤーやスタイルが書き出しで正しく動かないため、モーションデザイナーにどの機能を使ってよくて、どの機能は使ってはいけないかを一つひとつ説明しなければならず、この点はデザイナーにも不評でした。実際、単純に動画としてレンダリングしてインタラクションに合わせて再生するほうが、むしろはるかに軽く、作業量も少なかったです。Riveについても聞いたことがあり、こちらはLottieの問題点を補う方向に注力しているようです。ただ、まだ自分では使っていないので、結果はケースバイケースかもしれません
以前勤めていた会社では、Webアプリのバンドルサイズが8MB（圧縮後で約2MB）ありましたが、調べてみると大半がLottieライブラリ（2MB）とたった4つのアニメーションでした。そのうち2つのアニメーションを削除し、残りはLottieと一緒に遅延読み込みにしました。それでもデザイナーやほかの開発者に、8MBのバンドルがどれほど大きな問題かを納得してもらえず、結局この戦いには負けたような気分です
ブラウザがLottieアニメーションを複数同時に再生するとあまり耐えられない、という点には同意します。2000年代初頭にも、アニメーションFlash広告だらけのWebページはたくさんありましたが、性能問題はあったとしても、当時のシングルコアCPUでも十分動いていました
一方で、JSON形式は圧縮すると非常に小さくなりますし、JavaScript VMに読み込む効率も良いほうです
私がLottieを使ったときの選択肢はmp4とLottieの間でした。mp4と比べるとLottieのほうがずっと小さかったです
オープンな共通フォーマットでアニメーションを扱うという考え方は気に入っています。ただ実際には、Web開発者がCSSやSVGアニメーション（もっと軽く、調整もしやすい）を学ぶより先に、Lottie（ライブラリやラッパーだけでも数百KB増え、アニメーションごとの追加容量も大きい）をあまりにも気軽に選んでしまうのが残念です。Lottieのメインサイトではファイルが小さいと誇っていますが、比較対象がGIFやPNGだけで、SVG/CSSアニメーションとは比較していない点も気に入りません。ただし、ネイティブモバイルアプリではかなり相性が良い気がします
Lottieの本質的な意義は、CSSトランジションのような単純なアニメーションではなく、もっと複雑で自由度の高いアニメーション（小さな漫画のようなもの）にあります。TelegramメッセンジャーのLottie製アニメーションステッカー（例: https://tlgrm.eu/stickers/Princess）を見るとよく分かります
実際のところ、経験上Lottieが最も真価を発揮するのは、デザイン制作ツール、特にAfter Effectsからのターゲットフォーマットとしてです。添付記事でも、まさにこの点がLottieとそのファイルフォーマットの本来の強みとして言及されています。これを手で直接書く人はいません。私はモバイルアプリ開発者としてLottieアニメーションを扱ったことはありますが、制作者ではありませんでした
「CSSやSVGアニメーションをもっと学ぶべきだ」という話に補足すると、Web 1.0時代のFlashは最高でした。CSSやほかの標準は、Flashが提供していた体験にいまだに十分追いつけていません。Flashは動画フォーマット、アニメーションフォーマット、プログラミング環境、動画プレーヤー、対話型UIシステム、ゲームエンジン、MMO開発エンジン、インフォグラフィックツールなど、何でもできる万能ツールでした。Adobeがフォーマットとプレーヤーをオープンにしていれば、今でも生き残っていたはずです。CSS/SVG/HTML/JSだけが唯一の道だという固定観念を捨てるべきで、40年経ってもなお似たような問題を抱えているのを見ると、車輪の再発明を試みる価値はあります
LottieアニメーションをSVG+JSにコンパイルすることもできるのではないでしょうか。そういうツールがまだないだけだと思います
CSSアニメーション（そして最新のWeb Animations API）はハードウェアアクセラレーション可能ですが、こうしたライブラリ群（Lottieなど）はそうではありません
LottieとRiveの両方について、埋め込みと実装の観点で最低限の経験がありますが、Riveのほうがずっと良い体験でした。もし将来LottieとRiveのどちらかを選ぶことになったとき、私が見落としている点があるのか気になります
Riveはまだ使ったことはなく、動向を追っています。Lottieを作った開発者が2年ほど前にRiveチームに加わったという事実は興味深いです。この分野で新しいツールを評価するときは、Riveを必ず候補に入れるつもりです。自分が関わったプロジェクトでは、デザイナーが求めるアニメーションに対してLottieのファイルサイズを正当化するのが難しく、かなり強く反対していました。SVGatorも成功裏に使ったことがあります。Lottieがファイルサイズへの言及なしにあちこちで過大宣伝されていること（特にWebflowのようなツールや業界インフルエンサーなど）にもうんざりしていて、Lottieにぴったりの用途があるのは間違いないにせよ、一般的な用途の大半にはもっと良い選択肢があると思っています
Riveというツールは聞いたことがありませんでしたが、自分のプロジェクトに使えそうで、かなりわくわくする発見です。こういう情報があるからHNを見るのをやめられません
うちの会社のUIライブラリは、animated component（スピナー、プログレスバーなど）にlottie-webを使っています。ところが https://airbnb.io/lottie/#/community-showcase のページを開くと、会社のノートPCのファンが狂ったように回り始めます。CSSで作っていたら、こんな影響はなかったのではと思います
Lottieのコンセプトは本当に素晴らしいのですが、実際に使うと作業はとても大変です。RiveはLottieで問題だった部分を解決しようとしている新しいプラットフォームです。特に動的データ更新は、Lottieでは実質的にほぼ不可能です。それでも私たちはLottieで、Tracker.GGのValorant Backtrack（Spotify Wrappedに似た形式）において、動的データ更新されるアニメーションを実装しました（デモ: https://tracker.gg/valorant/backtrack/episode6/00d0aa2d-94d3-49ff-823c-8123f2b62848/eyJtb2RlIjoiY29tcGV0aXRpdmUifQ==/0）。そのために、ソースファイル（After Effects）内の名前付きレイヤーに直接アクセスし、各スライドが別々のLottieファイルになるようにして、スライド間の自然な遷移を手作業で実装しました。Lottie自体には動的なレイヤーアクセスが標準で備わっていないため、別ライブラリでLottieインスタンスを制御し、その上に独自のデータ制御レイヤーを作りました。デザイナーとエンジニアの間で何度も繰り返し作業が必要で、協業には不向きなフォーマットです。場合によっては、レイヤー属性を実際のデフォルト値（たとえば色）でターゲティングするような手法まで使わなければなりませんでした。フォーマット自体が本当に扱いづらいです。今後はRiveを使ってみたいと思っています
私たちはPBS KIDSのブランドアニメーションに何年もLottieを使っています。他のフォーマットと比べてさまざまな利点があり、2D平面でのランタイムレンダリングが増えると性能低下はありますが、複数のパイプライン（ゲーム、アプリ、動画）すべてに無難に統合できます。比較的低性能なデバイスやプラットフォーム（Rokuなど）には、たいてい静止画像を提供しています。After Effectsとのワークフローのおかげで、1人のデザイナーがループアニメーションを作れば、Lottie/Bodymovin json、Mov（放送/YouTube用）、SVG（低性能向け）まで一通り書き出せます。Flash以後としては非常に良い暫定的な代替フォーマットでした。今ではRiveも使っており、既存のjsonアニメーションを新しいワークフローに持ち込むこともできます。この分野の中心的人物（たとえばPixiのMat Groves、CloudKidのMatt Karlなど）とも仕事をしたことがありますが、Flash移行期には皆がそれぞれ異なる方法やプラグイン、数式、書き出しフォーマットを試していました。そうした個々の取り組みにはそれぞれの居場所があり、タイムラインベースのアニメーションにおけるソフトウェア構造上、フォーマット間の相互運用性の問題は常に存在します。結局は、プロジェクトに最も適したツールを選ぶことが重要です
私たちのサイト（https://resonancy.io）のアニメーション作成にlottielabを使いましたが、エディタは本当にSVGベースでよくできていて、オンラインツールの中では最高でした。全体として滑らかな体験でした。ただし、lottielabの独自圧縮ホスティングサービスに書き出さないと、アニメーション容量が大きすぎてランディングページで使うのはほぼ困難でした。圧縮ホスティングで平均400%ほどサイズを削減できたので、結局月30ドル払ってホスティングしています。代替フォーマットは探すつもりですが、アニメーション制作プロセスをもう一度やり直したくはありません。以前Reactベースのアニメーションライブラリを使った経験では、複雑なアニメーションを直接組むのはとても大変でしたが、lottielabでは思い描いたものを比較的簡単に作れました。Riveはまだ使っていませんが、試すつもりです。Lottieフォーマットをうまく圧縮してくれる外部ツールやライブラリがあれば勧めてほしいです
SWFの何が問題なのか分かりません。仕様は公開されていますし、とても効率的です。セキュリティ面の懸念が大きいなら、Turing完全な高級機能だけ外して実装することもできるはずです。兄弟コメントの「結局はまた別のJSONフォーマットにすぎない」という評価には同意します。非効率なWeb環境に慣れきった開発者世代が、効率という概念そのものを忘れてしまったように感じます
今日におけるアニメーション付きベクターグラフィックス生成のSOTA（最先端）は何なのか気になります。LLMはSVGパスを美しく描くのが得意ではなく、diffusion系画像モデルもビットマップしか扱えません。After Effectsと組み合わせた生成AI Illustratorへの需要は大きいので、誰かが革新的な試みをしてくれることを期待しています
Rive（競合サービス）の問題点は、芸術的な観点から直感性に欠けることです。ペンやブロブツールで直接描けず、特定のワークフローに合わせる必要があり（多くはSVGをインポート）、Flashのような直感的UIとはほど遠いです。もちろん興味深い機能は多いですが、Flashほど手軽で直感的な環境ではありません