Apps ScriptやGoogleカレンダーの連携で、毎週の定例会議や取引先との打ち合わせを自動で作っている。ところが共同主催者は会議が始まってから手で付けるしかなく、主催者が遅れると入室の承認や画面共有の許可で会議が止まる。この「共同主催者を事前に決めておけない」問題に、Google Meet REST APIの正式版（v2）が答えを出しつつあります。
2026年10月4日に、Meet APIのDiscovery文書（v2、revision 20260928）と、Googleが公開しているAPI定義ファイル（googleapis/googleapis）を直接取得して読みました。10月5日には、Meet APIのリリースノートとメンバー管理の開発者向けガイドも確認しています。会議スペースのメンバーを扱う6つのメソッドがv2に入り、役割として共同主催者（COHOST）を指定できます。一方で、どのエディションで使えるか、カレンダーで作った会議にそのまま使えるかは、確認した資料には書かれていません。本記事は資料調査と編集部の提案で、認証情報がないためAPIの実際の呼び出しは行っていません。
v2に入った6つのメソッドと上限
Discovery文書の spaces.members には、次の6つのメソッドがあります。必要なOAuthスコープは meetings.space.created で、取得（get）と一覧（list）だけは meetings.space.readonly でも呼べます。
| メソッド | 用途 | スコープ | 原文にある上限・既定 |
|---|---|---|---|
create | メンバーを1人登録 | created | email が作成時に必須 |
get | 1人を取得 | created / readonly | — |
list | 一覧を取得 | created / readonly | 既定250件、最大500件 |
patch | 1人の役割を変更 | created | updateMask で項目を指定 |
batchUpdate | 同じスペースの複数人を一括変更 | created | 1回で最大500人 |
delete | 登録を削除 | created | — |
list の pageSize は、500を超える値を指定しても500に切り詰められ、「Maximum might change in the future.」と上限が今後変わり得ることも書かれています。
以前はv2betaのDeveloper Previewだった
googleapis/googleapisの履歴を見ると、2026年9月9日のコミット（62cbe96）で、メンバーの管理機能が「Meet v2 GA API」に追加されています。このコミットの直前のv2beta定義では、作成・取得・一覧・削除の4つに「[Developer Preview]」の表記がありました。同じコミットでv2betaからこの表記が外れ、変更（patch）と一括変更（batchUpdate）が加わり、一覧の既定件数も25件から250件に変わっています。
Meet APIのリリースノートには、2026年9月11日付で「spaces.members リソースが一般提供（Generally Available）になった」と書かれています。会議の前でも最中でも、メンバーの管理と共同主催者の割り当てができるという説明です。GoogleのGoクライアント（google-api-go-client）でも、9月16日の自動生成コミットでmeet/v2のrevisionが20260421から20260910に上がり、members が加わりました。
指定できる役割は「共同主催者」だけ
Member リソースが持つ項目は name（リソース名）、email、role の3つです。role の値は2つしかありません。
COHOST: Discovery文書の説明は「Co-host role.」の1行です。開発者向けガイドには、会議中に会議を一緒に管理できるが、自動の記録類（録画・文字起こしなど）の設定と、主催者による管理（moderation）の設定は変えられない、と書かれていますROLE_UNSPECIFIED: 役割を指定しない状態です。説明によると、参加した時点で会議の設定に応じて「contributor（参加者）」か「viewer（閲覧のみ）」のどちらかになります
つまりAPIで事前に決められるのは「共同主催者にするかどうか」だけです。閲覧のみの参加者を個別に指定する値はv2にはありません。
もう1つ大事なのが Member の説明文の「These users can join the space without knocking.」です。メンバーとして登録した人は、ノック（入室リクエスト）なしで入れます。編集部の読み方では、登録は「共同主催者の指定」であると同時に「入室の事前許可」でもあります。入室承認の設計はGoogle Meetの参加者承認機能の記事で整理しています。
定義ファイルには、役割と会議の管理機能の関係も書かれています。SpaceConfig の Moderation（主催者による管理）の説明には、管理をオンにすると共同主催者の管理（co-host management）などが使えるとあります。また、既定で閲覧のみで参加させる設定（defaultJoinAsViewerType）には、Member で役割を明示した人はその役割で参加するという注記があります。
カレンダーやApps Scriptで作った会議に使えるか
ここが、定例会議を自動化している担当者にとって一番の確認点です。メンバーを登録・変更・削除するメソッドが求めるスコープは meetings.space.created で、その説明は「…your Google Meet conferences created by the app.」で、対象は「そのアプリが作った会議」です。
GoogleカレンダーAPIで予定に会議を付ける場合、conferenceData.createRequest で会議を作ります。カレンダーAPIのDiscovery文書によると、作られた会議の conferenceId は会議コード（例: aaa-bbbb-ccc）です。Meet APIの spaces.get は spaces/{meetingCode} の形で会議コードからスペースを引けます。ただし、カレンダー経由で作られた会議が「アプリが作った会議」として扱われ、メンバーを登録できるのかは、取得できた資料には書かれていません。図の下段を「未確認」としたのはこのためです。
| 作り方 | メンバー登録 | 注意点 |
|---|---|---|
Meet APIの spaces.create で作り、URLを予定に載せる | スコープの説明上、対象になる | 予定と会議を自分で結び付けて管理する |
カレンダーの createRequest で作る | 未確認 | 会議コードは長期保存しない |
| 人が手でカレンダーから作った会議 | 未確認 | アプリが作った会議ではない |
会議コードは長期保存しないよう spaces.get の説明に書かれています。一般に最後の利用から365日で失効し、別の会議に再利用されることもあるため、台帳には spaces/{space} の形のリソース名を保存します。カレンダーAPI側も、同じ会議情報を複数の予定で使い回すと意図しない人に会議の詳細が見える恐れがあると警告し、予定ごとに createRequest で新しい会議を作るよう求めています。
組み込むときの手順（編集部の提案）
ここからは、Discovery文書の記述をもとにした編集部の提案です。実際の呼び出しはしていないため、エラーの内容や反映のタイミングは確認していません。
- 会議の作り方を決める。 確実に対象になるのは、自分のアプリが
spaces.createで作ったスペースです。カレンダーで作る運用を続けるなら、検証用のアカウントで登録を試してから広げます - 台帳にリソース名を残す。
spaces.createの応答のname（spaces/...）と、予定のIDを対応させて保存します - 共同主催者を登録する。
emailは作成時に必須です
POST https://meet.googleapis.com/v2/spaces/{space}/members
Content-Type: application/json
{
"email": "cohost@example.com",
"role": "COHOST"
}- 担当者の交代は一括で反映する。
batchUpdateは同じスペースの最大500人までです。上の階層のupdateMaskにroleを指定すると、各リクエストのroleだけが更新されます - 登録内容を照合する。
listは既定で250件ずつ返るため、nextPageTokenがなくなるまで取得してから台帳と突き合わせます
既存の自動化に組み込む場合は、スプレッドシートを台帳にしたGASによる自動化の基本の構成を応用できます。開発者向けガイドには、Java・Node.js・Pythonのクライアントライブラリに加えて、Apps Scriptの UrlFetchApp でRESTを直接呼ぶ例が載っています。Apps Scriptの拡張サービス（高度なサービス）で使えるかは確認していません。
組み込む前に知っておきたい落とし穴
updateMaskに*を指定する。 原文の説明では、*は全項目の更新になり、送らなかった項目は削除されますbatchUpdateの階層ごとの指定を食い違わせる。 上の階層を省いて各リクエストだけにupdateMaskを付けると、未対応としてエラーになります。両方に付けるなら同じ値にします。両方とも省くと、送らなかった項目の削除を含めて全項目が更新されますuser項目を前提にする。 v2betaのMemberには、ユーザーIDで指定するuser項目が「[Developer Preview]」付きで残っていますが、v2のMemberにはありません。v2ではemailで指定します。なお、v2のDiscovery文書と開発者向けガイドには既定の返却項目として「name,email,role,user」とあり、定義ファイル（v2）の「name,email,role」と食い違っています。応答にuserが含まれるかは、実際に呼んで確かめてください- エディションや外部ユーザーの扱いを決めつける。 共同主催者を付けられるエディション、組織外のアドレスを共同主催者にできるか、一度に登録できる総人数は、Discovery文書・定義ファイル・開発者向けガイドのどれにも書かれていません
- 同じ会議で自動メモや録画も設定する。 同じv2の更新で、
SpaceConfigに録画・文字起こし・自動メモの自動開始の設定も入りました。これらの設定は共同主催者には変えられないため主催者側で決めておきます。自動メモの既定値は組織の設定でも変わるため、Meetの自動メモの既定変更の記事とあわせて確認します
まずは、いま自動で作っている会議が「アプリが作った会議」かどうかを確かめてください。カレンダー経由で作っているなら、検証用アカウントで members.create を1回呼び、通るかどうかを見てから、作り方を変えるかを決めるのが安全です。
2026年10月4日に、Meet APIのDiscovery文書（v2、revision 20260928）、googleapis/googleapisのMeet定義ファイル（v2・v2beta、commit 62cbe96とその直前）、google-api-go-clientの履歴、GoogleカレンダーAPIのDiscovery文書を直接取得して照合しました。10月5日にMeet APIのリリースノート（9月11日の一般提供）と、メンバー管理・認証の開発者向けガイドを確認しています（資料調査）。手順と落とし穴は編集部の提案です。認証情報がないためAPIの呼び出しは実施しておらず、対象エディション、カレンダーで作った会議への適用、Apps Scriptの拡張サービスでの対応状況は未確認です。
会議の自動作成やGoogle Workspaceの権限設計の見直しは、グリームハブのIT・Google Workspace 無料相談で承っています。会議の作り方や外部とのやり取りの多さによって進め方が変わるため、お問い合わせからご相談ください。
参考資料
- Google Meet REST API release notes
- Manage meeting space members（Google Meet REST API ガイド）
- Google Meet API Discovery document (v2)
- googleapis/googleapis — google/apps/meet/v2/resource.proto
- googleapis/googleapis — google/apps/meet/v2/service.proto
- googleapis/googleapis — google/apps/meet/v2/meet_v2.yaml
- googleapis/googleapis — commit 62cbe96（Meet v2 GA に Member を追加）
- googleapis/googleapis — google/apps/meet/v2beta/resource.proto
- googleapis/google-api-go-client — meet/v2/meet-api.json
- Google Calendar API Discovery document (v3)
