awesome-gemma徹底解説｜Google公式Gemmaリンク集111本の内訳と使い分けを実測で読む

awesome-gemmaは、GoogleのGitHub組織 google-gemma が2026年8月19日に公開したGemma関連リソースのリンク集だ。Gemma 4の情報は公式ドキュメント・Hugging Face・推論ベンダー各社・個人ブログに散らばっていて、「まず何を読めばいいのか」が分からない状態が続いていた。このリポジトリはその索引を名乗るものだが、中身は英語の一行説明が付いたリンクの列挙で、どれが公式でどれがコミュニティか、どこから読めば最短かは書かれていない。

そこで本記事では、リポジトリを実際にcloneして111本のエントリを機械集計し、リンク先ドメインで公式とサードパーティを分類し、git履歴から公開直後の2日間で何が入れ替わったかまで確認した。数値はすべて2026年8月23日時点の実測値である。

この記事ではGemmaエコシステムの索引としてawesome-gemmaを解説します。LLM全般の仕組み・モデル比較・ローカル実行の基礎は LLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版 をご覧ください。

awesome-gemmaとは——Google公式orgが公開したGemmaエコシステムの索引

awesome-gemmaは、Google DeepMindのオープンモデルファミリー Gemma に関するリソースを1つのREADMEに集約した、いわゆる「awesomeリスト」形式のリポジトリだ。README冒頭は公式ロゴのSVGとGemma公式サイトへのリンクで始まり、awesome.re のバッジが貼られている。

置かれている組織は google-gemma。この組織には他に Gemma Cookbook（★3,978）、gemma-translator（★1,287）、gemma-skills（★964）が並んでおり、awesome-gemma（★253）は最も新しい一本にあたる。組織のプロフィールは「Get started building with the Gemma」で、フォロワーは約1,000。

11のセクションと、それぞれが答えている問い

READMEの目次は11セクション（Models と Inference は下位に2つずつサブセクションを持つ）で構成されている。セクション名だけ見ても中身が想像しづらいので、実際のエントリ数と「そのセクションが答えている問い」を対応させたのが次の表だ。

件数は「- [ で始まるリンク行」を機械カウントした実数で、README内のMarkdownリンク総数は113本（差の2本は目次外の本文リンク）。エントリの4割弱（Demos 17＋Good Challenge 14＋In Space 2 ＝ 33本）はショーケースであり、ツールやドキュメントではない点は、リストを開く前に知っておくと期待値がずれない。

自分の手元でリストを検索できるようにする

awesome-gemmaはGitHub上で読むよりも、cloneして grep したほうが速い。リポジトリはREADMEとLICENSE、ロゴSVG2枚しか無く、cloneは一瞬で終わる。

# リポジトリを取得（README・LICENSE・ロゴのみ。数百KB）
git clone https://github.com/google-gemma/awesome-gemma
cd awesome-gemma

# 「ローカル実行」に関する行だけ抜き出す
grep -nE '^- \[' README.md | grep -iE 'ollama|llama.cpp|lm studio|litert|jax'

# セクション見出しと件数を一覧する
awk '/^#{2,3} /{s=$0; c[s]=0; o[++n]=s} /^- \[/{c[o[n]]++} END{for(i=1;i<=n;i++) printf "%3d  %s\n", c[o[i]], o[i]}' README.md

3つ目のコマンドが、本記事の表で示した件数をそのまま再現する。リストが更新されたときに「何が増えたか」を自分で数え直せるので、ブックマークしておくより実用的だ。

111エントリの内訳を実測する——Google公式52本・サードパーティ59本

awesomeリストを読むときに最初に知りたいのは「これはベンダーの宣伝資料なのか、コミュニティの知見なのか」だ。awesome-gemmaはGoogleの組織にあるので前者に見えるが、実際にリンク先のホスト名で分類すると、単純な二分法にはならなかった。

Google管理ドメイン（ai.google.dev / deepmind.google / aistudio.google.com / Google Cloud系 / kaggle.com / Hugging Face上の google アカウントとコレクション / google-* GitHub組織）を数えると52本、それ以外が59本。全体としてはほぼ半々だが、セクション単位で見ると偏りが強い。

読み取れるのは、「モデルそのもの」はGoogleが完全に握り、「動かし方」はエコシステムに任されているという構造だ。Core Modelsが6本すべて公式、Variantsが16本中15本まで公式コレクション。一方でInference（Local 13＋Hosted 14＝27本）は21本がサードパーティで、Tutorialsに至っては公式が1本も無い。

この構造は、リストの使い方にそのまま影響する。モデルの仕様や重みを探すときは、このリストのリンクがそのまま一次ソースになる。だが「どう動かすか」「どれが速いか」を探すときは、リンク先はGoogleの見解ではなく各ベンダーの自社ドキュメントであり、比較の軸は自分で立てる必要がある。

数え直すためのコマンド

上の分類は次のコマンドで再現できる。ホスト名の判定リストは自分の関心に合わせて足せばよい。

# リンクURLを抽出してホスト名ごとに集計する
grep -oE '\]\(https?://[^)]+\)' README.md \
  | sed -E 's|^\]\(https?://||; s|/.*$||; s|\)$||' \
  | sort | uniq -c | sort -rn | head -20

# Google管理ドメインの本数を数える
grep -oE '\]\(https?://[^)]+\)' README.md \
  | grep -cE 'ai\.google\.dev|deepmind\.google|aistudio\.google|cloud\.google|developers\.google|blog\.google|kaggle\.com|huggingface\.co/(collections/)?google|github\.com/google'

ホスト名の集計では huggingface.co が24本で最多、次いで github.com 16本、kaggle.com 16本、x.com 11本と続く。Hugging Faceがモデル配布の実質的な正本になっていることが、リンク構成からも読み取れる。

推論27本の使い分け——ローカル13本とホスティング14本のどこで線を引くか

エントリ数で見ればInferenceは27本と最大の実務セクションだが、リストは13＋14を並べるだけで選び方を書いていない。ここが読者にとって一番迷う場所なので、実際の住み分けを整理する。

ローカル13本——「まず動かす」から「端末に載せる」まで

READMEのInference / Localには、HF Transformers・llama.cpp・Unsloth・Ollama・LM Studio・vLLM・SGLang・AI Edge Gallery・LiteRT・JAX・React Native（ExecuTorch）・GenieX（Qualcomm）・Dockerの13本が並ぶ。到達地点で整理すると次のようになる。

Core Modelsセクションに「Gemma 4 QAT」と「Gemma 4 Mobile QAT」が独立して並んでいるのが、この表の裏付けになっている。QAT（Quantization-Aware Training）チェックポイントは、後から量子化するのではなく量子化前提で学習した重みで、ローカル実行の前提として公式が別枠で用意しているものだ。VRAMが足りないときに真っ先に見るべきはランタイムの乗り換えではなく、こちらの重みである。

Ollamaでの最短手順は次の通り。モデル名の名前空間はREADMEがリンクしている ollama.com/library/gemma4 に対応する。

# Ollama をインストール（macOS / Linux）
curl -fsSL https://ollama.com/install.sh | sh

# Gemma 4 を取得して対話開始（サイズ別タグは library ページで確認する）
ollama run gemma4

# 手元で動かせるサイズを先に見積もる：物理メモリとGPUメモリを確認
free -h 2>/dev/null || sysctl -n hw.memsize | awk '{printf "RAM: %.1f GB\n", $1/1024/1024/1024}'
nvidia-smi --query-gpu=name,memory.total --format=csv 2>/dev/null || echo "NVIDIA GPU なし（CPU/統合メモリで実行）"

サイズ別のタグ名はリリースごとに変わるため、ollama run gemma4 で引かれる既定タグをそのまま使うか、READMEがリンクしているライブラリページで現在の提供タグを確認してから指定するのが確実だ。Ollama自体の設定・APIの叩き方・よくあるエラーは Ollamaとは？使い方・インストール・モデル選び・エラー対処まで｜ローカルLLM完全ガイド2026年版 に詳しい。そもそも手元のマシンでどのサイズが動くのか分からない場合は、llmfit完全ガイド：今のPCで動くローカルLLMを1コマンドで判定するツール の判定を先に通しておくと、13本を試す前に候補が絞れる。

ホスティング14本——GPUを持たない側の選択肢

Inference / Hostedには、Gemini Enterprise Agent Platform（旧Vertex AI）・OpenRouter・Cerebras・NVIDIA・AMD・AI Studio・Cloud Run・LiveKit・Together AI・Modal・Fireworks・BaseTen・Runpod・Cloudflareの14本が並ぶ。ここで注目したいのは、リンク先URLに含まれるモデル名が提供元ごとに違うことだ。

同じ「Gemma 4を使える」でも、実際に返ってくるモデルはサイズもMoE構成も量子化形式も違う。ベンチマークや料金を比較する前に、リンク先が何を配信しているかを確認しないと、比較そのものが成立しない。Cloudflareだけが26B A4Bを選んでいるのは、MoEのアクティブパラメータが小さくエッジ配信に向くためと読める。

なお、Runpodのエントリだけは docs.runpod.io/tutorials/serverless/run-gemma-7b を指しており、Gemma 4ではなく初代Gemma 7B時代のチュートリアルが残っている。リスト全体がGemma 4を前提に整えられているなかで、ここだけ世代が古い。こうした取りこぼしは、リンク先URLを一本ずつ見ないと気づけない。

Gemma派生モデル16種とファインチューニング6本——「用途で切られた別モデル群」

Variantsセクションの16本は、awesome-gemmaのなかで最も情報密度が高い部分だ。ここに並んでいるのはGemma 4の派生版という以上に、目的ごとに別物として設計されたモデル群で、汎用チャットのGemma 4本体とは置き換え関係にない。

16本の守備範囲

開発者が実務でまず触るのはEmbeddingGemmaとFunctionGemmaの2本だろう。前者は検索側、後者はツール呼び出し側という、いずれもLLMアプリの土台になる部分を担う。EmbeddingGemmaを検索に使う構成そのものの設計は RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ で扱っている考え方がそのまま当てはまる。

一方でMedGemma・TxGemma・Cell2Sentence-Scale・DolphinGemmaはドメイン研究のためのモデルで、汎用の開発案件で採用する場面は限られる。16本を「Gemmaのバージョン違い」として横並びに見ると、必要のないものまで検討対象に入ってしまうので、まず用途で5系統に切ってから該当する系統だけを見るのが効率的だ。

なお、awesome-gemmaが指すGemma 4本体のサイズ構成は、Research and Evaluationセクションのテクニカルレポート項目に「E2B, E4B, 12B, 26B A4B, and 31B」と明記されている。このうち12Bについては Gemma 4 12B｜エンコーダレス・マルチモーダルで256K文脈を16GBノートで動かすオープンモデル でアーキテクチャと実行要件を個別に扱っている。

ファインチューニング6本の構成

Fine-Tuneセクションは6本と少ないが、公式3本・OSS 3本というバランスが取れている。

Apple Silicon向けが2本（Gemma Multimodal Tuner・MLX Tune）入っているのは、リストの性格をよく表している。NVIDIA GPUを前提としない追加学習経路が公式リストに載る程度には、MacでのローカルLLM開発が一般化したということだ。日本の個人開発者にとっては、この2本が最も現実的な入口になる可能性が高い。

git履歴で読む「公開直後の2日間」——リンクが一斉に付け替えられた

awesome-gemmaはコミットがまだ2本しか無い。だからこそ、git履歴を追うだけでキュレーションの意図が読めるという珍しい状態にある。

何が起きたか

・2026-08-19 23:27 JST：Initial commit。READMEとロゴのみで、LICENSEファイルは無し
・2026-08-21 01:48 JST：More links, add license, and add codeowner。226行追加・14行削除

2本目のコミットで、Apache-2.0のLICENSE（201行）と .github/CODEOWNERS が新設された。公開から約26時間、ライセンス表記が無い状態でリストが公開されていたことになる。awesomeリスト形式のリポジトリはCC BY-SAやCC0を採用する例も多いなかで、Apache-2.0が選ばれたのはGoogleの他リポジトリと揃えたためと読める。

より興味深いのは、追加ではなく「付け替え」が起きている点だ。Variantsセクションの8本（DiffusionGemma・EmbeddingGemma・FunctionGemma・MedGemma・ShieldGemma 2・VaultGemma・Gemma Scope 2・Gemma-APS）は、初コミットでは ai.google.dev のモデルカードや deepmind.google の製品ページを指していたが、2本目のコミットですべてHugging Faceのコレクションへ差し替えられた。同様に llama.cpp のエントリも、個別のGGUFリポジトリからコレクションURLへ変更されている。

付け替えが意味すること

これは単なるリンク整理ではない。「Gemmaのモデルを探す入口はHugging Faceである」という方針が、公開翌日に明確化されたと読める。実際、集計したホスト名でも huggingface.co が24本と最多で、公式ドキュメント（ai.google.dev）の5本を大きく上回る。

同じコミットで、Start Hereから Gemma 4 on Kaggle（Kaggleのモデルコレクション）が削除され、代わりに Gemma on X（公式Xアカウント）が追加された。Vertex AIのエントリ名も「Gemini Enterprise Agent Platform (Formerly Vertex AI)」へ改称されている。

リスト自体の更新頻度が低い状態で、この4本の追加が一度に入ったことは、Hosted側の網羅性がまだ流動的であることも示している。今後リストを参照するときは、git log で最終更新を確認してから読むのが確実だ。

# 最終更新と変更内容を確認する
git -C awesome-gemma log --date=iso --format='%ad  %s'

# 前回読んだときから何が変わったかを見る
git -C awesome-gemma diff HEAD~1 HEAD -- README.md | grep -E '^[+-]- \['

なお .github/CODEOWNERS に登録されているのは @maartengr の1名で、これはTutorialsセクションに3本掲載されている「A Visual Guide to Gemma 4」シリーズのニュースレターの書き手と同じハンドルだ。キュレーターと掲載コンテンツの書き手が同一であることは、リストの性格を判断するうえで踏まえておいてよい事実である。

awesome-gemmaの弱点——使う前に知っておくべき3点

情報の地図としては有用だが、そのまま信頼して読み進めると困る点が3つある。いずれも実測で確認したものだ。

1. 111本のうち11本がX投稿——ログインなしでは読めない可能性がある

リンク先ホスト名の集計で x.com は11本。内訳はTutorials 4本、Demos and Applications 4本、Research and Evaluation 2本、Start Here 1本（公式アカウント）だ。

問題はX投稿がリンク先として持つ耐久性にある。投稿は削除・非公開化されうるし、閲覧にログインを求められる場面もある。とくにResearch and Evaluationに入っている ChessBench と TERMS-Bench は、ベンチマークという性質上あとから参照される可能性が高いのに、参照先がツイート1本という状態になっている。同セクションの他3本（arXiv 2本、Artificial Analysis 1本）と比べて、証跡としての強度が明確に落ちる。

引用や社内資料で使う場合は、X投稿を出典にせず、そこからリンクされている一次資料（論文・リポジトリ・ベンチマークのページ）まで辿ってから記録するのが安全だ。

2. Awesomeバッジは付いているが、本家インデックスには収載されていない

READMEには awesome.re のバッジが貼られている。ただし、awesomeリストの総本山である sindresorhus/awesome のREADME（78KB）を取得して検索したところ、gemma の出現は0件だった。

# 本家 awesome リストに収載されているか確認する
curl -sL https://raw.githubusercontent.com/sindresorhus/awesome/main/readme.md \
  | grep -ci gemma
# → 0（2026-08-23 時点）

これは不正というわけではない。awesome.reのバッジは自分で貼るもので、本家インデックスへの掲載は別途プルリクエストと審査が必要な手続きだからだ。「バッジが付いている＝awesomeコミュニティの品質基準を通過している」ではないという一般的な注意が、このリポジトリにも当てはまるというだけである。公開4日目という時期を考えれば、これから申請される可能性も十分ある。

3. 日本語資料は0本——一次ソースを直接読む前提になる

READMEを japan / japanese / qiita / zenn / .jp/ で検索しても該当は0件。Tutorials 12本はすべて英語圏の個人ブログ・ニュースレター・X投稿で、唯一の非英語圏トピックが「Turning Gemma 4 into an Old Korean Translator」（古典韓国語翻訳）という状況だ。

つまり日本の開発者にとって、awesome-gemmaは「日本語の解説を探す場所」ではなく「英語の一次ソースの住所録」として機能する。リンク先の公式ドキュメントとHugging Faceコレクションを直接読む前提でないと、リストの価値は半減する。

それでも、地図としては役に立つ

弱点を並べたが、awesome-gemmaを否定しているわけではない。Gemma関連の情報が「モデル＝Google／実行＝エコシステム」という構造で分かれていることを、1ページで俯瞰できる資料は他に無い。とくに次の使い方では明確に時間を節約できる。

・派生モデルの棚卸し：EmbeddingGemma・FunctionGemma・ShieldGemma 2のような「知らないと探せない」モデルの存在を一度に把握する
・推論経路の網羅確認：自分が知らない配信経路（Cloudflare Workers AI・Modal・LiveKitなど）が無いか確認する
・更新の差分監視：cloneして git log を追えば、Googleがどこへ導線を寄せようとしているかが分かる

逆に「Gemma 4の使い方を学ぶ」「どのランタイムが速いか比較する」目的では、このリストは出発点にしかならない。判断材料は自分で作る必要がある。

まとめ

awesome-gemmaは、読めばGemmaが使えるようになるリストではない。Gemmaに関する情報がどこに置かれているかを示す地図であり、その地図の縮尺は「モデルは公式・実行はコミュニティ」という非対称な構造で描かれている。この非対称性を先に理解しておけば、公式docsをそのまま信じてよい場所と、自分で比較軸を立てるべき場所を取り違えずに済む。

cloneして git log を追える状態にしておけば、Googleが今後どこへ導線を寄せるかも読み取れる。単なるブックマークではなく、差分を監視する対象として手元に置くのが、このリポジトリの一番効率のよい使い方だ。

参照ソース

・google-gemma/awesome-gemma（公式リポジトリ・README / CONTRIBUTING / LICENSE / .github/CODEOWNERS） — 111エントリの実数、セクション構成、リンク先ドメイン分類、Footnotesの「公式サポート対象外」表記、CODEOWNERSの登録者
・google-gemma（GitHub組織） — awesome-gemma ★253、cookbook ★3,978、gemma-translator ★1,287、gemma-skills ★964 の実測値
・sindresorhus/awesome（本家インデックスのREADME） — gemma の出現0件（raw取得・78,803バイトを検索）
・google-deepmind/gemma（JAX参照実装） — ★5.7k / Apache-2.0。Inference / Local の「JAX」エントリの実体
・google/tunix（JAXネイティブのポストトレーニング） — ★2.4k / Apache-2.0。Fine-Tune セクションの実体
・google-ai-edge/gallery（オンデバイス実行のショーケース） — ★24.5k / Apache-2.0。Inference / Local の「AI Edge Gallery」エントリの実体