Gem の共有が止まる場所は三つあります。相手の一覧に出ないときに見る順番

受託でお手伝いしているサイトの運用手順を Gem にまとめて、先方のご担当者にお渡ししようとした午後のことでした。共有のアイコンを押すつもりで画面を見たのですが、そのアイコンがどこにも見当たりません。

私は最初、自分のアカウントの権限を疑いました。管理コンソールを開ける立場ではありませんでしたので、先方の情シスにお問い合わせいただくところから始めるつもりでおりました。

ところが原因は、もっと手前にありました。その Gem の「知識」に、共有に対応していない形式のファイルを一枚だけ足していたのです。いま思えば、画面に出ていない機能の理由をいちばん遠いところから探しにいく癖が、私にはあったのかもしれません。

止まっている場所を先に決めてから、人に尋ねます。 この順番にしてから、情シスへのお問い合わせが一往復で終わるようになりました。

Gem の共有は、Gem 本体・管理コンソール・ドライブという三つの場所で止まります。どこで止まっているかによって、直せる人が変わります。

共有のアイコンが出ていないなら、原因は二つに絞れます

仕事用・学校用のアカウントで共有のアイコンが表示されないとき、Gemini アプリのヘルプが挙げている理由は二つだけです。

症状	原因	直せる人
共有のアイコンが出ない	共有に対応していない形式のファイルが Gem に含まれている	自分（ファイルを差し替える）
共有のアイコンが出ない	組織の管理者が Gem の共有をオフにしている	Workspace 管理者

ファイルを添えた Gem を共有できるのは、端末のファイルか Google ドライブのファイルを載せている場合に限られます。「知識」にそれ以外の形式が混ざっていると、Gem ごと共有できなくなります。NotebookLM のノートブックも、共有する Gem のソースには使えません。

ここで分かるのは、アイコンが出ていないからといって管理者の設定が原因だとは限らない、ということです。先に「知識」を開いて、載せたファイルの出どころを一つずつ見てまいります。私自身、ここを飛ばして人に尋ねてしまった側でしたので、手順として書き残しておきます。

管理コンソールのトグルを切っても、過去の共有までは止まりません

管理者側の設定は一箇所です。管理コンソールのメニューから「生成 AI」→「Gemini アプリ」と進み、「Gem sharing」まで下りて「Allow users to share Gems」を切り替えます。操作には Gemini の設定を扱う管理者権限が必要です。

このトグルは、組織のメンバーが Gem を共有できるかどうかと、共有された Gem を使えるかどうかの両方を決めます。

ただし、Workspace 管理者向けのヘルプには見落としやすい但し書きが添えられております。この設定をオフにしても、すでに共有済みの Gem はドライブの中から引き続きアクセスでき、共有もできます。

つまりこのトグルは、これから起きる共有の蛇口であって、すでに流れた水を戻す栓ではありません。情報を止めたいときに管理コンソールだけを見ていると、止まったつもりで止まっていない状態が残ります。

私はここで線を引き直しました。これから配る量を決めるのが管理コンソール、すでに配った先を数えるのがドライブ。 用途が違う二つを、同じ画面で解決しようとしていたのが最初の誤りでした。

設定したのに直らないときは、グループと反映待ちを疑います

管理者側で設定したのに特定の人だけ使えない、という相談は二つの理由に集約されます。

一つは適用範囲です。この設定は組織部門（OU）単位でも、設定グループ単位でも適用できます。そしてグループの設定は組織部門の設定を上書きします。部署の組織部門でオンにしたつもりでも、その人が属する設定グループでオフになっていれば、オフが勝ちます。

もう一つは時間です。変更が行き渡るまで最大 24 時間かかることがあります。通常はもっと早く反映されますが、「設定した直後に試して、直っていないから設定が間違っていると判断する」という筋道は、ここで折り返してしまいます。

症状	先に見る場所	確かめ方
一部の人だけ共有できない	設定グループ	その人の所属グループで同じ設定がどうなっているかを開く
全員が共有できない	組織部門	最上位の組織部門から順に継承を追う
設定を変えた直後だけ直らない	反映待ち	時刻を控えて翌営業日に再確認する
オフにしたのに共有が生きている	ドライブ	共有済みの Gem のファイルを開いてアクセス権を見る

Workspace の機能が出てこないときの切り分けは、Gemini の新機能が Workspace に出てこないとき、待ちと不具合を切り分ける順序にも書きました。待ちと不具合を分けて考える癖は、Gem の共有でもそのまま効きます。

共有した Gem はドライブに置かれます

共有した Gem は、Google ドライブの新しいフォルダに保存されます。Gem に載せたファイルも同じフォルダに入ります。

ここが三つ目の場所です。ドライブの共有設定は、そのまま Gem にも適用されます。 組織外への文書共有を許可している組織では、Gem も組織外へ共有できます。外部共有を閉じている組織では、Gem だけを外へ出すことはできません。Gem に固有の外部共有ポリシーというものは、用意されていないのです。

そして、あるユーザーの Gem へのアクセス権を外すと、そのユーザーのドライブからその Gem が消えます。

誰が今アクセスできるのかは、ドライブ側から数えられます。個人開発で使っている Apps Script のプロジェクトに、次のような確認用の関数を一つ置いております。

/**
 * 共有した Gem が保存されているドライブのフォルダを開き、
 * ファイルごとに一般アクセスと編集者・閲覧者を書き出します。
 * 実行前に Gemini アプリの [Gem] → [その他] → [ドライブで探す] を開き、
 * 実際のフォルダ名を FOLDER_NAME に入れてください。
 */
function auditSharedGemAccess() {
  const FOLDER_NAME = 'Gems'; // 環境によって名前が異なります
  const folders = DriveApp.getFoldersByName(FOLDER_NAME);
 
  if (!folders.hasNext()) {
    Logger.log('フォルダが見つかりません: %s', FOLDER_NAME);
    return;
  }
 
  const files = folders.next().getFiles();
  let checked = 0;
 
  while (files.hasNext()) {
    const file = files.next();
    try {
      const editors = file.getEditors().map(function (u) { return u.getEmail(); });
      const viewers = file.getViewers().map(function (u) { return u.getEmail(); });
      Logger.log(
        '%s | 一般アクセス=%s | 編集者=%s | 閲覧者=%s',
        file.getName(),
        file.getSharingAccess(),
        editors.join(', ') || '(なし)',
        viewers.join(', ') || '(なし)'
      );
      checked++;
    } catch (e) {
      // 自分がオーナーでないファイルは権限の一覧を取得できません
      Logger.log('%s | 権限を取得できませんでした (%s)', file.getName(), e.message);
    }
  }
 
  Logger.log('確認したファイル: %s 件', checked);
}

実行すると、ログにはこのような行が並びます。

運用手順 Gem | 一般アクセス=PRIVATE | 編集者=(なし) | 閲覧者=staff@example.com
旧・入稿チェック Gem | 一般アクセス=DOMAIN_WITH_LINK | 編集者=(なし) | 閲覧者=(なし)
確認したファイル: 2 件

try で囲んでいるのは、自分がオーナーでないファイルで権限の一覧が取れず、そこで止まると残りの Gem を見ないまま終わってしまうからです。一件の失敗で棚卸しが途切れないようにしております。

getSharingAccess() が返す値は、PRIVATE のほかに DOMAIN、DOMAIN_WITH_LINK、ANYONE、ANYONE_WITH_LINK があります。上の例の二行目のように、リンクを知っていれば開ける状態のまま残っている Gem は、この列で拾えます。共有を解く前にドライブ側でできることは、Drive を Gemini に見せたくないなら、共有を解除する前に試せる設定がありますにまとめました。

Gem は開けるのに答えが違うときは、ファイルの権限が別に渡っています

Gem のアクセス権と、Gem に載せたファイルのアクセス権は、別々に渡ります。共有の操作中に「ファイルへのアクセス権も共有しますか」と尋ねられ、閲覧者・閲覧者（コメント可）・編集者から選ぶ場面がそれです。

ここを飛ばすと、相手の手元では Gem そのものは開くのに、知識として載せたファイルが読めません。同じ指示を与えても、返ってくる答えが自分の画面と食い違います。「共有できていない」ではなく「共有はできているのに噛み合わない」という形で表に出ますので、原因にたどり着くまでに時間がかかります。

逆に編集者として渡した相手は、カスタム指示も載せたファイルも書き換えられます。書き換えられれば、Gem の答えも変わります。渡しているのは役割であって、答えの固定ではないのです。

期間を区切りたいときは、共有相手ごとに有効期限を付けられます。外部の協力者に一時的にお渡しする場面では、こちらのほうが後始末が軽く済みます。

確かめる順番

順番	見る場所	分かること
1	Gem の「知識」	共有に対応していない形式のファイルが混ざっていないか
2	共有のアイコンの有無	自分で直せるのか、管理者に依頼するのか
3	管理コンソールの Gem sharing	組織としてこれからの共有を許しているか
4	設定グループと反映待ち	一部の人だけ違う理由がここにないか
5	ドライブのフォルダ	すでに配った先と、外へ出ている Gem がないか

まずは、いま共有している Gem を一つ選んで、[Gem] →[その他] →[ドライブで探す] を開いてみてください。自分の Gem がドライブのどこに置かれているかを一度見ておくと、次に「共有できない」と言われた日に、どの画面を開くかで迷わなくなります。

お読みいただきありがとうございました。