無料 GIF メーカー

使い方

1. 画像フレームをアップロードする。JPG・PNG・WebPファイルを2つ以上ドロップするか選択する。各ファイルがアップロード順にアニメーションの1フレームになる。ブラウザはローカルで読み込むため、サーバーには何もアップロードされない。
2. 必要に応じて並び替える。フレームをクリックし、「上に移動」/「下に移動」を使って順序を調整する。アニメーションは上から下の順に再生される。
3. フレームのタイミングを設定する。フレーム遅延スライダーで各フレームの表示時間（50〜2000ms）を設定する。100ms = 毎秒10フレーム、200ms = 5fps、500ms = ゆったりしたスライドショーのリズム。
4. ループ数と品質を選ぶ。Loop = 0は無限ループ（デフォルト値でほとんどのチャットクライアントが期待する設定）、1は1回再生。Quality 1は最高画質だが変換が最も遅い。10〜15が実用的な最適値だ。
5. 出力幅を選ぶ。「自動」はソースのサイズを維持する。400〜1000pxのプリセットはエンコード前に全フレームを指定幅にダウンスケールする。幅を小さくするとファイルサイズが劇的に小さくなる。
6. 「GIFを作成」をクリックしてダウンロードする。エンコードはブラウザ内で実行される。プログレスバーが完了するとプレビューが表示され、ファイルはワンクリックでダウンロードできる。

ビデオクリップをお持ちですか？専用のオンライン動画かGIF変換ツールツールはMP4 / WebM / MOVファイルからフレームを抽出する。このツールは画像シーケンス（スクリーンショット・デザインモックアップ・順番に動かしたい写真など）向けだ。

GIFフォーマット概要

Graphics Interchange Formatは1987年6月15日にCompuServeがリリースし、Steve Wilhite率いるエンジニアリングチームが設計した。1989年のGIF89a改訂版（現在も全てのブラウザが解析するバージョン）にはアニメーションタイミング・1ビット透明度・アプリケーション固有のメタデータブロックが追加された。現在GIFが最もよく知られているループアニメーションは元の仕様にはまったく含まれておらず、Netscapeが1995年9月にNavigator 2.0で「NETSCAPE2.0」アプリケーション拡張として追加した。この19バイトのブロックは今日でも全てのエンコーダーがループ数を宣言する方法だ。圧縮はLempel-Ziv-Welch（LZW）アルゴリズムを使用している。UnisysのU.S. LZW特許は2003年6月20日に失効した（国際的にも2004年半ばまでに同様に失効）。GIFは20年間特許フリーだ。

GIFが思いのほか大きい理由

フォーマットの3つの構造的な特性が組み合わさり、2026年においてGIFはアニメーションを配信する重い手段となっている：

• フレームあたり256色。各フレームは24ビットRGB空間から256色を抽出した8ビットインデックスパレットを持つ。写真やグラデーションはそのパレットまで減色する必要があり、細部が失われる（バンディング）か、損失を隠すためにディザリングパターンにバイトを費やす結果となる。
• フレーム間予測なし。現代のビデオコーデックはキーフレームとモーションデルタのストリームを格納するが、GIFは全フレームを独立して格納する。30フレームのアニメーションは基本的に30枚の別々に圧縮された画像をファイルに積み重ねたものだ。
• 1ビット透明度。ピクセルは完全に不透明か完全に透明かのいずれかだ。アルファチャンネルがないため、背景色と合わない背景の上で曲線形状がギザギザの端を見せる理由はこれだ。

実際の影響：5秒480pxのクリップはGIFなら簡単に5〜20MBになるが、MP4なら数百KBに収まる。ほとんどのソーシャルプラットフォームはGIFを5〜15MB前後に制限し、それより大きいものは除外される。配信先が自分で管理するモダンなウェブページなら、<video autoplay muted loop playsinline>に包んだMP4が技術的に優れた選択だ。ただし配信先のコーデックサポートが予測できない場合（チャットクライアント・READMEファイル・メール署名・課題管理ツールのコメント）はGIFが有利で、ビデオプレーヤー不要であらゆるプラットフォームの全リーダーが表示できる。

目安となる実践的な設定値

ピクセル面積のルール。ファイルサイズはフレームあたりのピクセル数に概ね比例するため、同じアスペクト比で出力幅を2倍にすると面積は4倍になる。320pxのGIFは640pxの同じアニメーションの約4分の1のサイズで、1280pxと比べると約16分の1のサイズだ。エンコード後ではなく、常にエンコード前にダウンスケールすること。

GIFを使うべき場合と別の形式を選ぶべき場合

• 配信先が予測できない場合はGIFが有利：チャットクライアント・メール・GitHub・Notion・Confluence・Jira・チケット管理システムなど。プレーンな<img>タグで埋め込んだGIFは1990年代からすべてのブラウザで自動再生され、ビデオプレーヤーのマークアップもコーデックチェックも不要だ。
• APNG（アニメーションPNG）は2023年にPNG仕様に正式に組み込まれた。24ビットカラーと本格的な8ビットアルファチャンネルをサポートするため、曲線形状がどんな背景の上でも綺麗に表示される。同じアニメーションのGIFよりファイルサイズは大きいことが多いが、品質は大幅に高い。
• アニメーションWebPはGoogleのフルアルファとロッシー / ロスレスモードを備えた汎用アニメーション形式だ。2026年時点のクロスブラウザサポートは約97%。チャットクライアントの対応はまちまちで（Discordは2024年末にネイティブのアニメーションWebPサポートを追加。SlackとiMessageはまだ一貫していない）。
• アニメーションAVIFは現在の形式の中で最もファイルサイズが小さい（GIFより桁違いに小さいことも多い）が、メッセージングアプリや画像編集ソフトのサポートはまだ静止AVIFより遅れている。
• MP4 / WebMビデオは自分で管理するウェブページに掲載する数秒を超えるアニメーションに最適だ。<video autoplay muted loop playsinline>が標準的なラッパーで、ブラウザのオートプレイポリシーはユーザー操作なしでミュートビデオを許可するため、GIFと見た目の動作は変わらずファイルサイズは一部に過ぎない。

プライバシーと処理速度

多くのオンラインGIF作成ツールは画像をサーバーにアップロードしてエンコードし、結果を返す。データ管理の観点から、未リリースUIのスクリーンショット・NDA対象のデザイン・子どもの写真など第三者に渡したくないものが他者のインフラを通過することを意味する。このツールはオープンソースのgif.jsライブラリを使いブラウザ内でエンコーダーを実行する。フレームはドラッグアンドドロップからGIFを構築するWeb Workerに直接渡され、ページから出るのはダウンロードをクリックしたときのエンコード済みファイルだけだ。速度はデバイスに依存する：簡単なリアクションGIFは1〜2秒、800pxの30フレームスライドショーは一般的なラップトップで10〜15秒かかることがある。

よくあるミス

1. サイズが大きく異なるフレーム。エンコーダーは最初のフレームの寸法を使用し、残りをレターボックスまたは引き延ばしで処理する。最もきれいな出力のために、アップロード前に全てのソースを同じサイズにトリミングまたはリサイズすること。
2. フレーム遅延をfpsで設定してしまう。スライダーはフレーム毎秒ではなくフレームあたりのミリ秒を設定する。100msは10fps、200msは5fps、500msは「0.5秒ごと」だ。アニメーションが遅く見える場合は遅延を下げ、速すぎる場合は上げる。
3. 品質値の誤解。数値が低いほど高品質（ただし低速）で、高いほど高速だが粗い。10が良いデフォルト値。重要なヒーロー画像には5まで下げ、ファイルサイズが重要な場合は15〜20まで上げる。
4. 出力幅が大きすぎる。幅を2倍にするとファイルサイズは4倍になる。チャットや大半のドキュメントには480pxで十分。GIF内のテキストを読みやすく保つ必要がある場合にのみ800pxを使う。
5. ループ数を誤って1に設定してしまう。プラットフォームによっては（特に以前のTwitterの動作）ループなしのGIFを静止画として表示する。1回再生の具体的な理由がない限り、Loop = 0のままにしておく。
6. 透明なPNGと透明でないJPGを混在させる。JPGフレームは不透明な背景を持ち、PNGフレームは透明な場合がある。エンコーダーはパレットごとに1つの透明色を選ぶため、混在したソースは予期しないハロー効果を生む。全てのフレームを事前に同じ形式に変換すること。
7. 長いアニメーションを作ろうとする。GIFは10秒を超えるものには不向きな形式で、ファイルサイズが手に負えなくなり、ほとんどの共有サービスはアップロードサイズを制限している。積極的にトリミングするか、長いコンテンツにはMP4 / WebPに切り替える。

よくある質問

何フレームまで追加できますか？

デバイスのメモリが快適に保持できる分だけ追加できる。エンコーダーはブラウザ内で完全に動作するためサーバー側の制限はないが、100フレーム・1000pxのGIFはエンコードにかなりの時間がかかり、数メガバイトのファイルになる。大半の用途では400〜600pxで5〜30フレームが最適だ。

どの画像形式をアップロードできますか？

ブラウザが画像としてデコードできるものならほぼ何でも対応している。JPG・PNG・GIF（最初のフレームを使用）・WebP・BMP・ほとんどのモダンな形式が対象だ。SVGのサポートはブラウザのキャンバスAPIに依存する。最もきれいな出力のために、全フレームを同じ形式・同じ寸法にすること。

GIFは透明度をサポートしていますか？

GIFは1ビット透明度のみサポートしており、ピクセルは完全に不透明か完全に透明かのいずれかでアンチエイリアスはない。半透明ピクセル（ドロップシャドウ・ソフトエッジ）を含むPNGフレームをアップロードすると、それらの半透明領域は不透明か選択した透明色のどちらかにスナップされ、フリンジが生じることがある。任意の背景に対してクリーンなアルファが必要なアニメーションには、APNGやアニメーションWebPの方が優れた形式だが、配信先によってサポートは異なる。

エンコードされたファイルはどこかにアップロードされますか？

いいえ。gif.jsエンコーダーはブラウザ内のWeb Workerで動作する。ソース画像はサーバーに送信されることはなく、エンコード済みの出力も同様だ。ページが一度読み込まれれば、オフラインでも動作する。

なぜGIFがこんなに大きいのですか？

GIF圧縮は現代の基準では非効率で、すべてのフレームが独自の256色インデックスパレットを持ち、フレーム間予測もない。最も効果的な対策は出力幅（ファイルサイズはピクセル面積に比例）とフレーム数の削減だ。チャット向け出力には幅を480px以下に制限し、アニメーションを重要なフレームのみにトリミングし、最小ファイルサイズのためにQualityの値を15〜20に向けて上げる。

作成済みのGIFを編集できますか？

直接は編集できない。このツールは個々の画像フレームから新しいGIFを構築するもので、既存のGIFをフレームに分解する機能はない。既存のGIFを編集するには、まずフレームを別々の画像として抽出し、修正または並び替えてから、新しいシーケンスとして再アップロードする必要がある。

関連ツール