AIプロジェクトを進める上で、多くの組織が共通して直面する課題があります。皆さんのチームでも、「あの人しかAIを使いこなせていない」という状況に心当たりはありませんか？
それは、「AI活用の属人化」です。
一部のメンバーは生成AIを魔法のように使いこなす一方で、他のメンバーは従来通りのやり方で時間をかけている。これでは、組織全体の生産性は向上しません。35年以上のシステム開発の歴史を振り返っても、個人の「職人技」に依存した仕組みは、決して長続きしないものです。
GoogleのGemini AdvancedやEnterprise版で利用できる「Gems（ジェムズ）」機能は、この課題を解決するために設計されたツールと言えます。個人の知識やプロンプトをパッケージ化し、チーム全員が使える「専用エージェント」として利用できるからです。
Gemsの運用に、高度なプログラミングスキルは必ずしも必要ありません。ゲーム開発においてキャラクターの行動ルールを設計するように、業務への理解とシステム思考に基づくルール作りが重要になります。
本記事では、技術者が不在の部門でも実践できる、安全で持続可能なGemsの運用体制について解説します。まずはプロトタイプとして「動くもの」を作り、チーム全体のスキルアップを目指していきましょう。
なぜ「Gems」なのか？チャット共有では解決できない組織課題
「プロンプトを共有すればいい」という意見もあります。しかし、一般的な傾向として、社内Wikiやドキュメントで「おすすめプロンプト集」を公開していても、有効活用されているケースは多くありません。
単純なテキスト共有には限界があるからです。皆さんも、長大なプロンプトをコピペして失敗した経験はありませんか？
属人化するプロンプト技術の弊害
プロンプト集の運用には、コストとリスクがあります。
- コピー＆ペーストの手間とミス: ドキュメントからプロンプトを探し、コピペし、変数を書き換える作業は煩雑です。ゲームの隠しコマンドを毎回手入力するようなもので、結局は自己流に戻ってしまいます。また、プロンプトの一部を誤って消してしまう可能性もあります。
- コンテキストの欠落: 優れた出力には、プロンプトだけでなく、事前の前提条件（コンテキスト）の定義が不可欠です。役割定義やトーン＆マナーの指定を毎回入力するのは非効率です。
- 更新のタイムラグ: 業務ルールが変わったとき、Wiki上のテキストを修正しても、各メンバーが手元に保存しているプロンプトまでは更新されません。
「履歴の共有」と「スキルの資産化」の違い
チャット履歴の共有は、過去の事例の共有に過ぎません。「あの時どうやったか」を知ることはできても、「今すぐ同じことを再現する」ためのツールにはなり得ません。
一方で、Gemsを作成するということは、知識や思考プロセスを「再現可能なツール」としてカプセル化することを意味します。これは、AIパイプライン最適化の考え方にも通じます。
- 入力: 「新商品の特長AとB」
- Gems（思考プロセス）: ターゲット分析 → 訴求点の抽出 → 文章構成 → 推敲
- 出力: 「ターゲットに刺さる営業メール案」
ユーザーは中間の複雑なプロセスを意識する必要がありません。複雑な処理を裏側に隠蔽し、誰でも同じ結果を得られるようにすること。これが「スキルの資産化」です。
Gems導入で目指すべきゴール：業務品質の平準化
Gems導入のゴールは「時短」ではなく「品質の平準化」に置くことが重要です。
目指すべきは、「新入社員でも、Gemsを使えば一定の品質のアウトプットが出せる」状態です。
例えば、日報作成、顧客への一次返信、会議の議事録要約などにGemsを適用することで、経験豊富な社員は単純作業から解放され、若手社員は業務遂行が可能になります。これこそが、AI駆動型組織の第一歩です。
1. チーム体制設計：技術者不在でも回る「3つの役割」
「AIエージェントの運用」と聞くと大掛かりなプロジェクトチームを想像するかもしれませんが、部門内での活用であれば、既存のメンバーで対応可能です。
重要なのは、「誰が責任を持つか」を明確にすることです。エンジニアがいなくても、以下の3つの役割を定義してください。
Gemsオーナー（業務熟知者）の任命
最も重要な役割です。プロンプトエンジニアリングのスキルよりも、「その業務の知識がある」ドメインエキスパートを任命してください。
- 適任者: チームリーダー、業務フローに詳しい中堅社員
- 役割: Gemsへの指示（インストラクション）の作成、出力品質の判定。
Gemsの精度は、指示書に書かれる内容で決まります。「顧客には丁寧語で」ではなく、「謝罪時は『恐れ入りますが』を使い、解決策を必ず2つ提示する」といった具体的な内容を言語化できるのは、現場の担当者です。
テスター（若手・利用者）の巻き込み
作成したGemsを実際に使い、フィードバックする役割です。「その業務に詳しくない若手」や「AIに懐疑的なメンバー」を入れるのがポイントです。
- 適任者: 新入社員、若手メンバー
- 役割: プロトタイプ版の使用、使いにくい点や意図しない回答の報告。
経験豊富な社員は無意識に「AIが答えやすい入力」をしてしまいますが、初心者は想定外の入力をします。ゲームのデバッグ作業のように、様々な角度からテストを行うことで、Gemsの堅牢性を高めることができます。
管理者（リスク監視）の配置
全体のリスクコントロールを行う役割です。情報システム部門の代わりとして、ガバナンスを担います。
- 適任者: 部門マネージャー、課長クラス
- 役割: 公開承認、アクセス権限の管理、利用ルールの策定。
ここで重要なのは、「技術的な管理」ではなく「業務的な責任」を持つことです。「このGemsが出した回答を、お客様に送って問題ないか？」という判断ができる人が担当するべきです。AIの判断根拠を説明可能にするXAI（説明可能なAI）の視点を取り入れ、なぜその出力になったのかを検証できる体制が理想的です。
2. 作成・公開プロセス：野良Gemsを生まないワークフロー
組織でGemsを運用する際、最も避けるべき事態は「野良Gems」の乱立です。管理されていないAIエージェントが大量に存在すると、どれが最新で信頼できるものなのか判別できなくなり、結果として誰も使わなくなるリスクがあります。
これを防ぐために、明確なワークフロー（承認プロセス）を導入することが不可欠です。
ニーズ収集と優先順位付け
まずは「何でもかんでも作らない」ことが大切です。以下の基準で作成するGemsを選定します。
- 頻度が高い: 毎日、あるいは毎週発生する業務か？
- 定型度が高い: ルールやフォーマットが決まっているか？
- 影響度が適切: ミスがあってもリカバリー可能か？（自動発注などのクリティカルな処理は避ける）
スプレッドシートなどで「Gems要望リスト」を作成し、チーム内で投票を行うのも効果的です。現場の課題感が大きい領域から着手しましょう。
プロトタイピングとサンドボックス検証
オーナーはまず、自分の個人アカウントや非公開設定でGemsを作成します。これを「サンドボックス（砂場）環境」として扱います。
Geminiの最新モデルを活用することで、複雑な指示出しに対する理解度も高まっています。完璧を目指さず、まずはプロトタイプとして作成し、リンク共有機能を使って限定的にテスターへ展開しましょう。「まず動くものを作る」というアジャイルなアプローチが、開発スピードを劇的に引き上げます。
検証ポイント:
- 意図したフォーマット: 指定した形式で出力されるか？
- ユーザビリティ: 前提知識がないメンバーでも迷わず操作できるか？
- 精度と安全性: ハルシネーション（事実と異なる生成）のリスクは許容範囲内か？
※最新のGeminiモデルでは推論能力が強化されていますが、必ず人間によるファクトチェックのプロセスを組み込むことを推奨します。
「承認済みGems」としての公式リリース手順
テストをクリアしたら、部内への公式リリースです。ここで重要なのが「バージョン管理」と「台帳登録」によるガバナンスです。
- Gems名称のルール化:
【公式】営業メール作成_v1.0のように、公式か私的か、バージョンはいくつか、ひと目で分かる命名規則を設けます。 - 説明文の整備: Gemsの説明欄（Instructions）だけでなく、共有時の案内にも「用途」「入力すべき情報」「注意事項」「最終更新日」を明記します。
- 台帳への登録: 管理者が管理する「公式Gems一覧」にリンクを掲載し、そこを正（Single Source of Truth）とします。
Google Workspaceの共有ドライブ内に、Gemsへのリンクとマニュアルをまとめたドキュメントを置くのが管理しやすい方法です。チャットツールで流してしまうと、更新情報が埋もれてしまうため注意が必要です。
3. 品質維持とアップデート：陳腐化させないメンテナンス術
システム開発の世界では「リリースした日がシステムが最も新しい日」と言われますが、AIエージェントの運用においては、この常識は通用しません。
Geminiの基盤モデル（LLM）は急速に進化を続けており、プラットフォーム自体の機能も日々拡張されています。そのため、作成して終わりではなく、環境の変化に合わせてGemsを「育てていく」意識が不可欠です。
月次レビュー会でのフィードバック収集
月に一度、チーム内で「Gemsレビュー会」を開催することを強く推奨します。
- 「最近、このGemsの回答が少し冗長になってきた気がする」
- 「新しい製品ラインナップが発表されたので、知識ベースに追加してほしい」
- 「このGems、実はもう誰も使っていない」
といった定性的な意見を収集します。Googleフォームなどで常時フィードバックを受け付ける仕組みも有効ですが、対話の中でこそ、改善のヒントや新たな活用アイデアが生まれるものです。皆さんのチームでも、定期的な「AIの健康診断」を実施してみてはいかがでしょうか。
モデルアップデート時の動作確認
Googleは定期的にGeminiのモデルをメジャーアップデートします。
モデルが進化すると、推論能力や処理速度が向上する一方で、同じプロンプト（指示）に対する解釈が変化することがあります。以前は詳細な指示が必要だったタスクが、最新モデルではシンプルな指示で十分になったり、逆に「深読み」しすぎて冗長な回答を返すようになったりする現象は珍しくありません。
モデル更新のアナウンスがあった際は、Gemsのオーナーが主要なエージェントを実際に動かし、期待通りの挙動をするか動作確認（リグレッションテスト）を行ってください。特に高度な推論モデルを利用している場合は、プロンプトの微調整が必要になることがあります。
使われないGemsの統廃合基準
利用頻度が低いGems、あるいは役割を終えたGemsは、定期的に整理しましょう。
断捨離の判断基準（例）:
- 利用率の低下: 直近1ヶ月で利用者が極端に少ない。
- 標準機能による代替: Gmail統合機能（AI Inboxなど）やGeminiの基本機能が強化され、専用のGemsを使う必要がなくなった。
- 業務プロセスの変更: 対象となる業務自体が廃止または変更された。
特に、GeminiとGoogle Workspaceの統合が進むにつれ、以前はGemsで作り込んでいた機能が、プラットフォームの標準機能として提供されるケースが増えています。「いつか使うかも」で放置すると、古い情報や非効率な手法を温存することになり、チームの生産性を下げる要因になりかねません。デジタルな整理整頓は、運用の質を保つための重要なタスクです。
4. リスク管理とオンボーディング：安心して使い続けるために
セキュリティとリスク管理は重要です。ここを疎かにすると、取り組みが制限される可能性があります。
入力データの取り扱いルール（個人情報・機密情報）
まず、利用しているGeminiのエディションを確認してください。Gemini BusinessやGemini Enterpriseであれば、入力データがGoogleのAIモデルの学習に使われることはありません。
しかし、それでも「入力してはいけない情報」のルールは定めるべきです。
- NG: 具体的な顧客の個人名、電話番号、クレジットカード情報、未発表のプロジェクトの詳細。
- OK: 一般化された顧客属性、公開済みの製品情報、社内の一般的な業務フロー。
「迷ったらマスキング（黒塗り）する」というルールを徹底しましょう。例えば、特定の顧客名ではなく、一般化された名称に置き換えて入力するだけで、リスクは低減します。
ハルシネーション（嘘）への耐性をつける教育
AIは不正確な情報を出力することがあります。もっともらしい情報や架空の製品スペックを生成することがあります。
これを防ぐ技術的なアプローチとして、社内データを参照させて回答精度を高めるRAG（検索拡張生成）が有効です。最近では、複数の情報源から複雑な関係性を読み解くGraphRAGや、図表や画像データまで含めて根拠とするマルチモーダルRAGといった技術も登場し、AIが参照できる情報の幅と精度は飛躍的に向上しています。
しかし、どれほど技術が進化しても「ハルシネーション（もっともらしい嘘）」のリスクをゼロにすることはできません。 最終的には「利用者のリテラシー向上」が最も確実な防御策です。
「AIの出力は、あくまで優秀なアシスタントのドラフト」
新人が作った資料をチェックせずに客先に出すことはないように、必ず人間が目を通し、事実確認（ファクトチェック）を行う必要があります。この「Human-in-the-Loop（人間が介在するループ）」を業務フローに組み込むことが、最強のリスク管理になります。
新メンバーへのGems利用講習パッケージ
新しくチームに加わったメンバーには、PCのセットアップと同じように「Gemsセットアップ」の時間を設けましょう。
- ツールの場所: 公式Gems一覧へのアクセス権付与。
- 使い方の実演: 実際にGemsを使って業務を行うデモを見せる。
- 禁止事項の伝達: データ入力ルールとファクトチェックの徹底。
これらをまとめたスライドや動画を用意しておけば、オンボーディングのコストも下がります。
まとめ：まずは「スモールスタート」で成功体験を
ここまで、情報システム部門が不在でも可能なGemsの運用体制について解説してきました。
準備することが多いと感じたかもしれませんが、最初から完璧な体制を作る必要はありません。
まずは、チームで頻繁に行われている「作業」を一つだけ選んでください。そして、それを解決するGemsを作り、メンバーと試してみましょう。
成功の鍵は「小さく始めて、改善する」こと。 プロトタイプ思考で仮説を即座に形にして検証することが、ビジネスへの最短距離を描きます。
もし、PoC（概念実証）を経て、「大規模に全社展開したい」「基幹システムと連携したエージェントを作りたい」というフェーズに進むのであれば、専門家のサポートも検討してください。
AIは、活用するチームに力を与えてくれます。チームだけの「相棒」を作り始めましょう。
コメント