Gemini Gems のカスタム指示、最初に書いたものでうまく動かない経験はないでしょうか。私自身、業務用に5つほど Gem を作っていて、最初は「思った通りに動かない」というモヤモヤをずっと抱えていました。色々と試した結果、ChatGPT の Custom GPTs とは少し違う書き方のコツがあると気づきました。
この記事は、私が現在使っている Gem のカスタム指示の書き方と、過去にハマったポイントを整理したものです。Google の公式ガイドにもある程度書かれていますが、実際の挙動と照らし合わせると、もう少し具体的なルールがあります。
カスタム指示は「役割」「制約」「出力形式」の3層で書く
Gem のカスタム指示で一番効くのは、情報を3つの層に分けて書くことです。
第1層: 役割（あなたは何者か） 第2層: 制約（してはいけないこと、しなければいけないこと） 第3層: 出力形式（どう応答するか）
実例で見ます。私が「議事録要約」用に作っている Gem の指示はこんな構造です。
# 役割
あなたは社内会議の議事録を構造化された要約に整える専門アシスタントです。
ユーザーは生のトランスクリプトを貼り付けるので、それを以下のフォーマットで整理します。
# 制約
- 推測や創作は一切しない。発言として明示されていない情報は含めない
- 個人名は役職名（例: マーケティング部長）に置き換える
- 機密情報のフラグ（NDA、未発表、内部限定）が見えたら冒頭に⚠️を付ける
- 出力は必ず日本語で
# 出力形式
## 会議概要（2文以内）
## 主要な決定事項（箇条書き、3-5項目）
## ToDo（担当者と期限を明記）
## 次回までの宿題（あれば）
このように層を分けると、Gem は「役割を理解した上で制約を守りつつ、決まったフォーマットで出す」という挙動を安定的に再現します。1段の長いプロンプトで書くより、明確に効きます。
ポジティブ表記とネガティブ表記の使い分け
「〜してはいけない」だけを並べると、Gemini はネガティブ指示を見落としやすい傾向があります。代わりに「〜する」というポジティブ表記を主体にして、補助的にネガティブを書くのがおすすめです。
悪い例: 「敬語を崩さないでください。タメ口禁止。」 良い例: 「常に丁寧な敬体（です/ます調）で応答します。」
特に複数のネガティブ指示が並ぶと、Gemini はどれかを忘れます。重要な制約は「肯定形で書く」ことを徹底しています。
具体例（Few-shot）を1〜2個入れる効果
「カスタム指示には例示を含めない方がよい」と書いてあるブログをたまに見ますが、私の経験ではむしろ逆です。1〜2個の Few-shot を入れると、応答品質が体感で大きく上がります。
例（先ほどの議事録 Gem の続き）:
# 出力例
入力: 「来週から新規開発の優先度を上げる。担当は田中、期限は10/15」
出力:
## 会議概要
新規開発プロジェクトの優先度を引き上げる方針が決定。
## 主要な決定事項
- 新規開発の優先度を最上位に引き上げ
## ToDo
- 開発担当者: 10/15までに初期実装完了
例示があると、フォーマットの解釈ブレがほぼなくなります。3つ以上入れると指示文が長くなりすぎるので、1〜2例に絞るのがちょうどいいです。
「ユーザーが質問していないことは答えない」を入れる
Gemini はサービス精神が旺盛で、聞かれていない補足情報まで返してくれることがあります。多くの場面ではありがたいですが、業務 Gem では邪魔になることが多いです。
カスタム指示の制約セクションに、次のような一文を入れるとかなり改善します。
- ユーザーが明示的に質問していない情報は返さない
- 「ご参考までに」「ちなみに」のような付加情報は出さない
- 確認や追加質問が必要な場合は、本題の前にではなく、出力の最後に1問だけ追加する
これでお節介な前置きや、関係ない補足が大幅に減ります。
知識ファイルの参照ルールを明示する
Gem には知識ファイル（ドキュメント、PDF など）をアップロードできますが、何も指示しないと Gem は知識ファイルを「参考程度に」しか使わないことがあります。
カスタム指示に次のような文を入れると、知識ファイルが優先されます。
# 知識ファイルの利用方針
- 添付された知識ファイルが「正典」です。これと矛盾する内部知識は使いません
- 知識ファイルに記載されていない情報を返す場合は、その旨を明示します
- 引用するときは出典の章番号またはセクション名を必ず併記します
社内ナレッジボットや、製品 FAQ を扱う Gem では特に重要です。「最新の社内ルールではこうです」とユーザーが言っても、Gem は古い学習データに基づいて反論することがあるので、明示的に「アップロードされたものが優先」と書く必要があります。
トーン指定の書き方
トーンの指示は曖昧になりがちです。「親しみやすく」「プロフェッショナルに」だけでは、Gemini の解釈の幅が広すぎます。
具体的に書くなら、
# トーン
- 一文の長さ: 平均20〜40字。長文を避ける
- 二人称: 「あなた」を使う。「皆さん」「お客様」は使わない
- 絵文字: 使わない
- カジュアル度: 友人に説明するくらいの距離感。タメ口は使わない
- 専門用語: 初出時に1文で補足する
数値や具体例で指示すると、トーンのブレが小さくなります。
ハマったポイント1: 指示が長すぎると守られなくなる
最初、私はカスタム指示を細かく書きすぎて、結果として Gem が指示の半分くらいしか守らなくなりました。
経験的には、カスタム指示は800〜1500文字くらいに収めるのが安定します。それを超えると、Gem は途中の指示を「うっかり」忘れます。
長くなったときは、優先度の低い指示を削るか、Few-shot 例で代用するか、知識ファイルに移すかを検討します。
ハマったポイント2: 「絶対に」と書いても破られる
Gemini に限らず LLM 全般ですが、「絶対に〜してはいけない」「いかなる場合も〜」という強調は、効くこともあれば効かないこともあります。私の経験では、強調語より「具体的な禁止例」を書く方が効果的でした。
悪い例: 「絶対に個人名を出してはいけない」 良い例: 「個人名（例: 田中、佐藤）が含まれる場合は、役職名に置き換える」
具体例があると、Gem は「ああ、こういうケースのことを言っているのか」と認識できます。
ハマったポイント3: バージョン管理がない
Gems は現状、過去のバージョンに戻せません。指示を編集するたびに上書きされるので、私は外部の Markdown ファイルにマスターを保管しています。
gems/
meeting-summary/
instructions.md # マスター
knowledge/
style-guide.pdf
glossary.md
changelog.md # 変更履歴を手動で記録
Gem 側に貼るのはコピー、マスターはローカルで管理。これだと「あれ、先週うまく動いてた指示に戻したい」というときに復元できます。
全体を振り返ってのかわりに、明日試せる1つのこと
もし今、Gem の挙動に微妙な不満があるなら、現在のカスタム指示を3層構造（役割・制約・出力形式）に書き直してみてください。それだけで、応答の安定感が目に見えて変わるはずです。
そこから Few-shot 例を1つ追加し、「質問されていないことは答えない」を制約に入れる、という流れで段階的に磨いていけば、3〜4回の編集で「思った通りに動く Gem」になります。
Gems のカスタムインストラクションは「動くプロンプト」
Gems 上のカスタムインストラクションは、技術的には「システムプロンプト相当」に位置づけられます。ChatGPT の Custom Instructions と似ていますが、Gems の方が柔軟性が高く、入力文字数の上限も大きいです。
大事なのは、これを「一度書いて保存する静的文書」ではなく、継続的に調整する動く仕様書として扱う姿勢です。最初から完璧なものを書こうとせず、実際の会話で「ここがうまく動かない」と感じた瞬間に戻って書き換える、という運用が最終的に最速です。
構造の型 — 5 セクションで組み立てる
私が使っている Gems のカスタムインストラクションは、ほぼ全て下記 5 セクションで構成されています。
1. ROLE — この Gem が何者か（職業・立場・専門領域）
2. GOAL — 何を達成したいのか（ユーザーの目的）
3. INPUT — ユーザーからどんな情報が来るか、どう受け取るか
4. OUTPUT — どんな形式・粒度・トーンで返すか
5. CONSTRAINTS — してはいけないこと・避けるべき表現
この 5 セクションを明示的に書いておくと、長文の指示がぶれなくなります。特に CONSTRAINTS を入れる癖をつけるだけで、想定外の応答が激減します。
CONSTRAINTS
- 常体（だ・である調）に書き換えない
- 誇張表現・「画期的」「革命的」等のマーケティング語彙を追加しない
- 「」等の締め文句を追加しない
ポイントは CONSTRAINTS の 3 項目です。LLM はデフォルトで「元気な記事風の締め文」を追加したがりますが、これを明示的に禁止することで、職人的な校正者の振る舞いに近づけられます。
### 検証の仕方
Gem を作ったら、必ず 3〜5 本の実例で検証してください。期待通りに動いた例だけでなく、「うまく動かなかった例」を残しておく点が肝心です。カスタムインストラクションを書き換えたときに、過去の失敗例で再テストすれば、改善と退行（リグレッション）の両方を検出できます。
## OUTPUT
- 「このクエリは何をしているか」を 2 〜 3 文で説明
- パフォーマンス上の懸念点を箇条書き
- 改善案クエリを 1 つ以上提示（元クエリとの diff ではなく独立したコードブロック）
- 必要に応じて EXPLAIN ANALYZE の読み方を添える
## よくある失敗 3 選
最後に、Gems のカスタムインストラクションでやってしまいがちな失敗を 3 つ挙げます。
**失敗 1: 指示が曖昧すぎる**
「丁寧に答えてください」「分かりやすく」といった抽象指示は、ほぼ効きません。「3 文以内で」「箇条書きではなく散文で」のように、測定可能な指示に変えてください。
**失敗 2: ネガティブ指示ばかり書く**
「〜しないでください」ばかりを並べると、代わりに何をすればよいか分からなくなります。ネガティブ指示と同じくらい、ポジティブな期待（「〜してください」）も書きましょう。
**失敗 3: 検証例を用意しない**
Gem を作って満足してしまい、実際の会話で使っているうちに少しずつズレが蓄積していくパターンです。カスタムインストラクションを更新したら、必ず保存しておいた代表的な入力で再テストしてください。
## 次のステップ
Gems のカスタムインストラクションは、単発で精度を上げる以外にも、チームで共有する資産になります。「コードレビュー Gem」「リリースノート起案 Gem」「ブランドボイス校正 Gem」のように、組織内で何人も使う Gem を整備しておくと、ナレッジの再利用性が大幅に上がります。
Gemini の他の応用については Gemini 2.5 Pro API 完全ガイド でも解説していますので、API レベルでの制御を深めたい方は合わせてご覧ください。