🦀

【Google Gemini】マジで使うGemを5つ紹介

hako@札幌

2025/12/21に公開

はじめに

今回は、私がよく使うGeminiのGemを紹介します！！

弊社では、12月からGoogle Workspaceを導入しております。経緯はこちらの記事にまとめております！

Gemは無料Geminiユーザーでも活用できます！！

この記事で伝えたいこと↓↓↓

全体像解説

Gem...？？

ざっくりとですが、出力内容をカスタマイズしたGeminiを作れるぐらいの認識で良いと思います。

頻繁に繰り返すタスクの詳しいカスタム指示を書いておくことで、作業の効率化ができます。

Gemたちの紹介

さっそくよく使うGemを紹介します。
内容によってはWebエンジニアでなくでも活用できると思います！！

難しくわからない技術記事の全体像を掴みたいとき

よくわかっていない技術の記事や論文、外国の技術ブログなどを解説してもらうときによく使っています。
ポイントとしては図解を含めて、わかりやすく説明してもらうことです。
イメージしてから概要をまとめ、再度技術記事を読んで理解を深めるという流れです。

カスタム指示

出力例

以下の記事を解説してもらいました...！
（この記事がわかりにくいのではなく、私が知識不足で理解できていないためですからね...！）

出力例

3行要約（TL;DR）

LLMの回答精度を評価する「LLM-as-a-Judge」において、評価基準の曖昧さによる「評価のゆらぎ」が課題となっていた。
解決策として、教育分野などで用いられる「ルーブリック（明確な評価基準表）」を導入し、評価観点とレベルごとの定義を言語化した。
このルーブリックをプロンプトに組み込むことで、LLMによる評価の一貫性が向上し、実運用可能なレベルの自動評価体制が構築できた。
何がすごいの？（Why & Context）

LLMを活用したプロダクト開発では、モデルの回答品質を継続的に評価することが不可欠です。しかし、人手による評価はコストがかかりすぎ、LLM自身に評価させる「LLM-as-a-Judge」は、指示が曖昧だと評価結果が毎回変わってしまう（ゆらぎ）という問題がありました。
この記事のすごい点は、人間が感覚的に行っていた評価基準を、「ルーブリック」という構造化されたドキュメントに落とし込むプロセスを確立したことにあります。単に「正確に評価して」と指示するのではなく、「正確性とは何か」「S評価とA評価の違いは何か」を定義し、それをLLMへの入力（プロンプト）とすることで、評価者の「主観」を排除し、機械的で一貫性のある自動評価を実現しました。これは、LLMの品質管理を効率化する上で非常に実践的なアプローチです。
【図解】仕組みのビジュアライズ
後述
知っておくべきキーワード

記事の理解を深めるために、以下の3つの重要単語を押さえておきましょう。
LLM-as-a-Judge（AIによる自動評価）
高性能なLLM（GPT-4など）を「裁判官」に見立て、別のモデルが生成した回答の品質を採点させる手法です。人手による評価に比べて圧倒的に低コスト・高速ですが、指示が不十分だと「気分（確率的挙動）」で点数が変わってしまう課題があります。
ルーブリック (Rubric)
評価の「観点（正確性、安全性など）」と、各レベル（S/A/B/C）における「具体的な達成基準」を言語化した評価表のことです。「なんとなく良い」ではなく、「〇〇が含まれていればA、さらに△△があればS」のように構造化することで、LLMの曖昧な判断を防ぎます。
カッパ係数 (Cohen's Kappa)
2人の評価者（ここでは「人間 vs AI」または「AI vs AI」）の評価が、偶然の一致を除いてどれくらい食い違っていないかを示す統計指標です。この記事では、ルーブリック導入後にこの数値が改善したことを指標として、評価システムの信頼性を証明しています。

生成された画像はこちら

全体像解説

長いMarkdownを散文的に短い説明にするとき

生成AIの出力する包括的な調査レポートは、特に指定しなければ文章量が多く、箇条書きなど構造的にしっかりしています。（しっかりしすぎて少し冗長な場合もありますが...）
そういったときにこのGemを利用することで、短くして要約をしてもらったりしています。

カスタム指示の中にある一部は、Claudeの公式ドキュメントにあるプロンプト例を組み込んでいます。

カスタム指示

出力例

圧縮前のMarkdown

 RAG-Anything 解説レポート
 1. エグゼクティブサマリーRAG-Anythingは、「あらゆる形式のデータ（テキスト、画像、表、数式など）をひとつの統合された知識として扱える」、最新のRAG（検索拡張生成）フレームワークです。
従来のRAGが苦手としていた「複雑なレイアウトのPDF」や「図表を含む専門文書」の内容を、人間が読むように正確に理解・検索できる点が最大の特徴です。主に香港大学（HKUDS）の研究チームによって開発・公開されました。

 2. 背景：従来のRAGの限界これまでの一般的なRAGシステムには、以下のような課題がありました。

テキスト偏重: 画像やグラフの中に書かれている重要な数字や情報を無視してしまう。

構造の喪失: 表（テーブル）のデータがバラバラのテキストとして処理され、意味が通じなくなる。

文脈の分断: 図とその解説文が離れ離れに検索され、「どの図の解説か」がAIに伝わらない。
RAG-Anythingは、これらの課題を解決するために**「マルチモーダル（多形式対応）」かつ「構造維持」**のアプローチを採用しています。

 3. RAG-Anythingの仕組み（コア技術）RAG-Anythingは単にテキストを読み込むだけでなく、文書内の要素同士の**「つながり」**を理解します。

 ① マルチモーダル・エンティティ抽出文書内の要素を以下の4つに分類して認識・抽出します。
テキスト

画像（図解、写真）

表（テーブルデータ）

数式（科学論文などの数式）

 ② デュアル・グラフ構造（Dual-Graph）抽出したデータをバラバラにせず、以下のようなグラフ（ネットワーク）構造として保存します。これがRAG-Anythingの核心技術です。


構造の種類
役割


意味的グラフ
「この画像」と「このテキスト」は内容的に関連している（Semantic Match）

構造的グラフ
「この表」は「第3章」の下にある（Hierarchy Preservation）

これにより、**「第3章にある売上推移のグラフについて教えて」**といった、場所や文脈を指定した質問にも正確に回答できるようになります。

 4. 主な機能とメリット
 あらゆるファイルを「知識」化PDF、Markdown、Word文書などを投げ込むだけで、中身の図表や数式を含めてデータベース化（インデックス化）します。

 高精度な「クロスモーダル検索」
Text-to-Image: テキストで検索して、関連する図版を見つける。

Image-to-Text: 図版に関連する解説テキストを見つける。

Any-to-Any: 質問の意図に合わせて、最適な形式（図、表、文章）の情報を組み合わせて回答する。

 専門文書に強い金融レポート（大量の表）、医学論文（画像と解説）、技術マニュアル（図解と手順）など、これまでのAIが読み取りにくかった文書で特に威力を発揮します。

 5. 既存技術との比較

項目
従来のRAG (Naive RAG)
RAG-Anything


対応データ
主にテキストのみ
テキスト、画像、音声、表、数式

PDF処理
テキスト抽出のみ（図は無視）
レイアウト解析し、図表も理解

データ構造
単純な切り分け（チャンク）
知識グラフ（つながりを保持）

回答精度
図表に関する質問に弱い
図表の内容も踏まえて回答可能

処理コスト
軽い
グラフ構築のため比較的重い


 6. まとめRAG-Anythingは、「ただ文字を検索する」時代から、「文書全体を構造ごと理解する」時代への進化を象徴する技術です。
特に、企業の社内ナレッジ（マニュアルや報告書）は図表を含んでいることがほとんどであるため、実務レベルでのRAG活用において、この「Anything（なんでも扱える）」というアプローチは事実上の標準になっていくと考えられます。

構造の種類	役割
意味的グラフ	「この画像」と「このテキスト」は内容的に関連している（Semantic Match）
構造的グラフ	「この表」は「第3章」の下にある（Hierarchy Preservation）

項目	従来のRAG (Naive RAG)	RAG-Anything
対応データ	主にテキストのみ	テキスト、画像、音声、表、数式
PDF処理	テキスト抽出のみ（図は無視）	レイアウト解析し、図表も理解
データ構造	単純な切り分け（チャンク）	知識グラフ（つながりを保持）
回答精度	図表に関する質問に弱い	図表の内容も踏まえて回答可能
処理コスト	軽い	グラフ構築のため比較的重い

出力例

 RAG-Anything 概要RAG-Anythingは、香港大学の研究チームによって開発された、テキスト、画像、表、数式などあらゆる形式のデータを統合的な知識として扱う次世代の検索拡張生成フレームワークです。従来のRAGがテキスト偏重であり、複雑なPDF内の図表やレイアウト構造を無視してしまうという課題に対し、このシステムは文書内の要素間のつながりを維持したまま理解することで解決を図っています。

 コア技術と仕組みその核心技術は、文書からマルチモーダルなエンティティを抽出し、それらを意味的および構造的なつながりを持つDual-Graph（二重グラフ構造）として保存することにあります。このグラフ構造により、単なるキーワード一致だけでなく、特定の章にある図表の文脈や、画像とテキストの関連性を考慮した高度なクロスモーダル検索が可能になります。

 利点と展望結果として、金融レポートや技術マニュアルのような図表を多用する専門文書においても、ユーザーの意図に合わせて最適な形式で情報を提示できます。単なる文字検索から文書全体の構造的理解へと進化したこの技術は、企業の複雑なナレッジ活用における新たな標準となるアプローチです。

Issue作成アシスタント

Geminiとの対話で技術調査を行ったあとに、実際にIssueを作成するときに役立つGemです。

カスタム指示

出力例

 RAG-Anythingの導入検証およびPoC環境の構築
 概要提供されたレポートにあるRAG-Anythingフレームワークを用いて、マルチモーダルRAGの実証実験環境を構築します。従来のRAGシステムでは対応が困難であった、複雑なレイアウトを持つPDFや図表、数式を含むドキュメントに対して、構造と文脈を維持したまま情報の検索が可能かどうかを検証することが目的です。香港大学の研究チームが開発したこの技術を採用することで、画像や表データの欠落を防ぎ、回答精度の向上を目指します。

 詳細本タスクでは、RAG-AnythingのGitHubリポジトリおよび関連論文を参照し、ローカルまたは開発サーバー上に動作環境を構築します。具体的には、まず公式リポジトリからコードを取得し、必要な依存ライブラリをセットアップして基本動作を確認してください。
環境構築後は、テキスト、画像、表、数式が混在するサンプルドキュメント（決算資料や技術マニュアル等を想定）を用意し、インデックス化のプロセスを実行します。その際、レポートで言及されているマルチモーダル・エンティティ抽出機能と、デュアル・グラフ構造（意味的グラフおよび構造的グラフ）が正しく生成されているかを確認してください。
最後に、実際に「図表の内容」や「特定のセクションにある数値」を問うクエリを投げ、Text-to-ImageやAny-to-Anyの検索挙動を評価します。従来の単純なテキスト抽出型RAGと比較して、どの程度文脈理解や回答精度が向上しているかを定性的に評価し、チームに共有するための簡易レポートを作成してください。

 完了条件
 RAG-Anythingの動作環境（Python環境等）が構築され、エラーなく起動すること

 サンプルPDFのインジェストが完了し、マルチモーダルデータのインデックスが作成されていること

 テキストによる質問に対し、関連する図表やグラフの内容を含めた回答が生成されること

 検証結果および既存技術との差異をまとめた簡易レポート（またはWikiページ）が作成されていること

 実装上の注意点RAG-Anythingはグラフ構造の構築処理を行うため、従来のNaive RAGと比較してインデックス作成時の計算コストや時間がかかると予想されます。検証時はGPUリソースの確保や、処理時間の計測も併せて行ってください。また、日本語ドキュメントに対するエンティティ抽出の精度が未知数であるため、まずは英語のサンプルで動作を確認し、その後に日本語データでの挙動を確認する段階的なアプローチを推奨します。

 対応ブランチ名の提案feature/verify-rag-anything-poc

ドメインストーリーテリング

ドメイン知識を可視化するモデリング手法の一つであるドメインストーリーテリングをGemにしました。
こちらのGemにつきましては、以下の記事で紹介しております！！

Webサイトアニメーションの言語化

最後はWebサイト制作のときに使うようなピンポイントな利用シーンですが、
既存サイトのアニメーションの解析や、説明をGeminiに聞くことができるGemです。

カスタム指示

出力例

BOTANIST Sustainableの解析

ご提示いただいたWebサイト「BOTANIST Sustainable」 (https://sustainable.botanistofficial.com/) を拝見しました。
このサイトは、単なる情報の羅列ではなく、「森の循環」や「呼吸」を感じさせるような、有機的でストーリーテリングなモーションデザインが特徴です。ユーザーのスクロール操作に合わせて、物語を読み進めるように要素が展開されています。
以下に、フロントエンドエンジニア兼モーションデザイナーの視点で、このサイトのアニメーションを深掘りして言語化・解説します。

 🔍 アニメーション分析: BOTANIST Sustainable全体を通して貫かれているのは、**「Organic & Flow（有機的で淀みのない流れ）」**です。機械的な動き（Linear）を極力排除し、植物が成長したり風になびいたりするような自然な「ゆらぎ」を演出しています。

 1. 動きの言語化 (Visual Breakdown)A. ヒーローエリア（FV）の導入: 「静かな目覚め」
トリガー: ページロード（window.onload / DOMContentLoaded）。
詳細:
フェードとスケール: メインビジュアルが、わずかに拡大（Scale Up）しながら、ゆっくりと不透明度（Opacity）を上げて現れます。
テキストのスタガー: キャッチコピーなどのテキストは、行ごと、あるいはブロックごとに**Stagger（時間差）**を設けて、下から上へ translateY で浮き上がります。
印象: いきなり表示されるのではなく「霧が晴れる」ような演出により、ブランドの持つ「優しさ」や「自然への敬意」を表現しています。
B. スクロール連動のパララックス（視差効果）: 「奥行きのある森」
トリガー: スクロール（Scroll）。
詳細:
視差のレイヤー構造: 背景にある植物の画像やテクスチャが、手前のテキストよりも「遅れて（またはゆっくり）」移動しています。
速度差: Background Speed < Foreground Speed の関係性を作ることで、擬似的な奥行き（Z軸）を感じさせます。
印象: Webサイトという2次元の平面に、森の中にいるような3次元的な空間の広がりを与えています。これが「没入感」の正体です。
C. 画像のマスク表示（Reveal）: 「カーテンを開ける」

トリガー: ビューポートへの侵入（Intersection Observer / ScrollTrigger）。

詳細:

クリッピングマスク: 画像が表示される際、単にフェードインするのではなく、clip-path や親要素の overflow: hidden を利用して、幕が上がるように画像が見えてくる演出が見受けられます。

イージング: Power2.out や Expo.out のような、初速が速く、終わり際がゆっくり止まるイージングが採用されており、上品な所作を感じさせます。

 2. 技術スタックと実装 (Technical Implementation)ソースコードの挙動とクラス名の命名規則（推測）から、以下のスタックが濃厚です。
アニメーションエンジン: GSAP (GreenSock Animation Platform)
このレベルの複雑なタイムライン制御とスクロール連動（ScrollTrigger）は、GSAPの独壇場です。CSS Animationだけでは管理しきれない「スクロール位置に応じたミリ秒単位の制御」を行っているはずです。
スムーススクロール: Lenis あるいは Locomotive Scroll
標準のブラウザスクロールではなく、慣性（Inertia）の効いた「しっとり」としたスクロール感があります。これにより、アニメーションがカクつかず、滑らかに同期します。
構造: HTML5 / CSS3 (Sass) / Vanilla JS (or jQuery mix)
実装のポイント: GPUアクセラレーションと合成レイヤー

滑らかさを維持するために、動かすプロパティは top や left ではなく、必ず transform: translate3d(x, y, z) を使用しているはずです。これにより、ブラウザのレンダリング処理をGPUに委譲し、再レイアウト（Reflow）を防いでいます。

 3. 簡易コード例 (Concept Code)このサイトの核となる「スクロールに応じてふわっと浮き上がるテキスト（スタガー効果付き）」を GSAP で実装する場合のコンセプトコードです。
// GSAPとScrollTriggerプラグインの登録
gsap.registerPlugin(ScrollTrigger);

// ターゲットとなるセクション内の要素を全て取得
const sections = document.querySelectorAll('.js-fade-section');

sections.forEach((section) => {
  // そのセクション内のテキストや画像を取得
  const elements = section.querySelectorAll('.js-fade-element');

  // アニメーションの設定
  gsap.fromTo(elements, 
    {
      y: 60,          // 60px下からスタート
      opacity: 0,     // 透明
      clipPath: 'inset(100% 0% 0% 0%)' // 必要に応じてマスク効果
    },
    {
      y: 0,           // 定位置へ
      opacity: 1,     // 不透明に
      clipPath: 'inset(0% 0% 0% 0%)',
      duration: 1.2,  // 1.2秒かけて実行（少し長めで優雅に）
      ease: "power3.out", // 自然な減速感
      stagger: 0.15,  // 要素ごとに0.15秒ずつ遅らせる（これが重要！）
      scrollTrigger: {
        trigger: section, // セクションが...
        start: "top 80%", // 画面の上から80%の位置に来たら発火
        toggleActions: "play none none reverse", // スクロールバックで戻すか等の設定
        // markers: true // 開発時はこれでデバッグ
      }
    }
  );
});


 4. UX/UI視点の評価このサイトのアニメーションは、単なる装飾（Decoration）を超え、UX（ユーザー体験）の一部として機能しています。

ブランドの一貫性: 「サステナブル」「ボタニカル」というキーワードが持つ、優しさや時間の流れを、ゆったりとしたイージングと慣性スクロールで見事に体現しています。キビキビ動きすぎると、このブランドイメージは損なわれます。

視線誘導（Guidance）: 遅れて表示される（Stagger）テキストや、視差効果によって、ユーザーの視線を自然に「次に読んでほしい場所」へと誘導しています。

読み手のストレス軽減: 情報が一気に出現せず、スクロールに合わせて適度な量ずつ提示されるため、認知的負荷（Cognitive Load）が低く、心地よく読み進められます。

 次のステップもしよろしければ、**「このサイトのような『慣性スクロール（スムーススクロール）』をご自身のプロジェクトに導入するための、最小構成のコード」**を作成しましょうか？あるいは、特定のセクション（例：円グラフが動く部分など）に絞って深掘り解説することも可能です。

まとめ

私が業務でも、日常生活でもよく使っているGemを5つ紹介しました。
今回紹介したように、Gemはエンジニアリングの領域だけでなく、日々のちょっとした作業を強力にサポートしてくれます。
自分だけのアシスタントを量産できるのがGemの最大のメリットだと思います。

無料版でも利用できるので、ぜひみなさんも自分好みのGemを作って、業務効率化や学習に役立ててみてください！

GitHubで編集を提案

マーベリックスのテックブログPublication

北海道札幌発・株式会社マーベリックスのテックブログです。フロントエンド、バックエンド、AWS、AI駆動開発まで、エンジニアの日常と実験を気ままに発信していきます。

はじめに

この記事で伝えたいこと↓↓↓

Gem...？？

Gemたちの紹介

難しくわからない技術記事の全体像を掴みたいとき

カスタム指示

出力例

長いMarkdownを散文的に短い説明にするとき

カスタム指示

出力例

RAG-Anything 解説レポート

1. エグゼクティブサマリー

2. 背景：従来のRAGの限界

3. RAG-Anythingの仕組み（コア技術）

① マルチモーダル・エンティティ抽出

② デュアル・グラフ構造（Dual-Graph）

4. 主な機能とメリット

あらゆるファイルを「知識」化

高精度な「クロスモーダル検索」

専門文書に強い

5. 既存技術との比較

6. まとめ

RAG-Anything 概要

コア技術と仕組み

利点と展望

Issue作成アシスタント

カスタム指示

出力例

RAG-Anythingの導入検証およびPoC環境の構築

概要

詳細

完了条件

実装上の注意点

対応ブランチ名の提案

ドメインストーリーテリング

Webサイトアニメーションの言語化

カスタム指示

出力例

🔍 アニメーション分析: BOTANIST Sustainable

1. 動きの言語化 (Visual Breakdown)

2. 技術スタックと実装 (Technical Implementation)

3. 簡易コード例 (Concept Code)

4. UX/UI視点の評価

次のステップ

まとめ

Discussion