Gemini Gems のカスタムインストラクションは、書いた直後は思った通りに動いてくれます。ただ、長く運用していると「最近なんか言うこと聞かなくなった気がする」と感じる場面が必ず出てきます。これはモデル側のアップデート、自分の業務の変化、追加した例のノイズなど、複数の要因が絡んだ結果です。
この記事は、Gems のカスタムインストラクションを「書き始めるとき」ではなく「書き直すとき」に焦点を当てた実用記事です。何度も Gems を作って運用してきた立場として、書き直しの判断軸と手順をまとめます。
書き直しが必要な 5 つの兆候
私が「これは書き直しどき」と判断しているシグナルは、次の 5 つです。
第 1 に、同じプロンプトを 3 回投げて、毎回違う構造の答えが返ってくる場合です。リリース直後はフォーマットが安定していたのに、徐々にバラついてきたら、インストラクションのどこかが効かなくなっているサインです。
第 2 に、特定のキーワードに引きずられて関係ない応答を始めるケースです。たとえば「Stripe」と書いただけで、自分の意図と関係なく Stripe API の汎用的な解説を返し始めるなら、インストラクション側の優先順位が崩れています。
第 3 に、文体の指定（敬体・常体・カジュアル等）が守られなくなる場面です。これはモデル側のアップデートで指定の効きが弱くなることがあるため、書き直しの王道理由になります。
第 4 に、過去に確実に動いていた例外処理（「英語で聞かれたら英語で答える」など）が無視されるようになったケースです。これはインストラクションの順序や強調の仕方を見直すサインです。
第 5 に、自分の業務の主軸が変わったのに、Gems の前提が古いままのケース。これは Gems が悪いというより、自分の側の更新タイミングです。
「効かなくなる」原因のほとんどはインストラクションの肥大化
私が複数の Gems を運用してきた中で、書き直しが必要になる最大の原因は「追加した例外指示の累積」です。最初は 200 文字程度のシンプルなインストラクションだったものに、運用しながら「この場合はこう」「この場合はこう」と追記し続けると、いつの間にか 2000 文字を超え、相互に矛盾する指示が混在する状態になります。
この状態のインストラクションは、モデルが「結局どれを優先すればいいか分からない」という状態に陥りやすく、応答品質が落ちます。書き直すときは、追加してきた例外を全部いったん捨てて、本当に必要な軸だけ残す勇気が必要です。
安全に書き直す 4 ステップ
書き直しは、いきなり本番の Gems を上書きするのではなく、次の手順で進めるのが安全です。
第 1 に、現状のインストラクションをバックアップします。テキストとしてエディタに貼り付けて、gems-backup-YYYY-MM-DD.txt のような形で保存しておきます。書き直しが失敗したときに戻せる場所がないと、心理的に書き直しに踏み切れません。
第 2 に、「この Gems が解決すべきタスクは何か」を 1 文で書き直します。長くなった指示の中で、最も重要なたった 1 つのゴールを言語化することで、書き直しの軸が固まります。
第 3 に、新しいインストラクションを「最小限の指示 → 例 → 例外」の順で構成し直します。例は 2〜3 個に絞り、例外は本当にプロダクションで起きたケースだけに絞ります。
第 4 に、書き直したものを別名の Gems として保存し、1 週間並行で使ってから旧 Gems と入れ替えます。並行運用期間に出てきた違和感を新インストラクションに反映させてから本番化するのが、品質を落とさずに移行するコツです。
書き直し後のインストラクション例
参考までに、私が運用しているライティングサポート用 Gems の現在の構成（簡略化したもの）を共有します。
# 役割
日本語の技術記事を執筆する際の校正パートナー。
# 守るべき軸
- 文体は敬体（です/ます調）で統一。常体は使わない。
- 専門用語の初出には簡単な定義を添える。
- コードブロックは必ず言語指定付きで提示する。
# 出力形式
- 箇条書きより本文を優先（読みやすさを重視）
- 提案は最大 3 個まで（過剰な代替案は出さない）
# 例外
- ユーザーが「常体で」と明示した場合のみ常体に切り替える
- ユーザーが英語で質問した場合は英語で回答する
これくらいのサイズに削ぎ落とすと、モデルが指示を取りこぼすリスクが大幅に下がります。
モデルアップデート直後にチェックする習慣
Gemini のモデル更新後 1〜2 日のうちに、自分の主要な Gems をいくつか触って動作確認するのを習慣にしています。Gemini 3.2 のリリース直後にも、私の Gems のうち 1 つで「文体指定が弱くなる」現象を確認したため、その場で書き直しました。アップデート直後の小さなチェックは、後から「いつから変わったんだろう」と探し回る時間を確実に減らします。
チームで Gems を共有しているときの注意
複数人で同じ Gems を使っている場合、書き直しは事前共有が必須です。「自分は新インストラクションで使っている」「他の人は旧インストラクションのまま」という状態になると、Gems の挙動が人によって違うように見える混乱が発生します。
書き直しの差分を共有するときは、変更前と変更後をテキストで並べて見せるのが確実です。Slack や Notion に貼り付けるだけで、レビューと合意形成の両方が同時に進みます。
次のアクション
明日からできることは、自分が今もっとも頻繁に使っている Gems のインストラクションを、文字数だけ確認することです。1500 文字を超えていたら、書き直し時期に入っている可能性が高いです。短い Gems のほうが、長い Gems より確実に効きます。