案件の受注やフォームからの問い合わせをきっかけに、Google Chat に専用のスペースを作り、担当者を入れておく。Apps Script や社内ツールで自動化すると便利ですが、通信が途中で切れて処理を再試行したときに、同じ名前のスペースが2つできる、あるいは2回目が ALREADY_EXISTS で失敗して後続の処理が止まる、という問題が起きることがあります。
Google Chat API のスペースの作成には、この再試行を安全にするための requestId があります。10月初めに公開された API 定義では、スペースの説明（description）の上限が150文字から4,096文字に広がっています。案件の概要や連絡先を説明欄にまとめて書けるようになります。
この記事は、Chat API の公開されている API 定義（Discovery 文書）と、Google が公開している Node.js 用クライアント googleapis の型定義を2026年10月12日に確認して整理したものです。実際の API の呼び出しは行っていません。2026年10月16日にデベロッパー向けのリリースノートとガイドも確認しましたが、requestId や説明の上限の変更を扱った記載は見つからなかったため、提供時期は API 定義の変化から読み取れる範囲で書いています。なお、ガイドはスペースの作成・更新の前提条件として、Google Chat を使える Business または Enterprise の Google Workspace アカウントを挙げています。
requestIdで「同じリクエストなら同じスペース」にする
スペースを作る方法は2つあります。スペースだけを作る spaces.create と、初期メンバーを入れて作る spaces.setup です。どちらにも requestId を指定できます。
API 定義の説明は次のとおりです。
Specifying a request ID makes the request idempotent, which ensures that multiple identical requests with the same request ID result in only a single space being created. Subsequent requests with the same request ID return the existing space and do not update the space, even if the requested details differ from the current state.
同じ requestId で何度送っても、作られるスペースは1つで、2回目以降は既存のスペースが返ります。推奨は「A random UUID」です。
ただし、効かせるには条件があります。説明に書かれている注意点を要約します。
- 2回目以降も同じ内容・同じ認証情報で送る。 別のユーザーの認証で同じ
requestIdを使うとエラーになります - 2回目に内容を変えても、スペースは更新されない。 名前や説明を直したい場合は
spaces.patchで別に更新します - 返ってくるスペースは中身が揃っていない場合がある。 「the API echoes the space in your request with the system-assigned resource name populated」とあり、最新の状態は
spaces.getで取り直すよう案内されています
実装で大事なのは、requestId を再試行のたびに作り直さないことです。たとえば問い合わせのIDや案件番号ごとに UUID を1つ発行してスプレッドシートやデータベースに保存し、再試行ではその値を使い回します。再試行の処理の中で毎回 UUID を作ると、別のリクエストとして扱われ、二重作成を防げません。
googleapis の型定義を版ごとに見ると、この requestId は 2026年8月31日公開の 178.0.0 にはなく、9月10日公開の 180.0.0 から入っています。API への追加もこの期間と考えられますが、Google の公式の告知では確認できていません（2026年10月16日時点のリリースノートに該当する項目はありません）。
説明は4,096文字、ガイドラインは5,000文字
スペースの説明とガイドライン（ルール）は spaceDetails に入れます。API 定義の上限は次のとおりです。
| 項目 | 上限 | 備考 |
|---|---|---|
表示名 displayName | 128文字 | 種類が SPACE のときは必須。組織内で同じ名前があると ALREADY_EXISTS |
説明 spaceDetails.description | 4,096文字 | 2026年9月24日公開の googleapis 182.0.0 の型定義では150文字 |
ガイドライン spaceDetails.guidelines | 5,000文字 | 変更なし |
説明の上限は、10月3日公開の 183.0.0 から「Supports up to 4,096 characters」に変わっています。150文字では案件名と担当者くらいしか書けませんでしたが、4,096文字あれば、案件の概要、関係するドライブのフォルダ、期日、問い合わせ元の情報（社内で共有してよい範囲）などをまとめられます。
あとから説明を書き換える場合の注意もあります。spaces.patch の updateMask の説明に「You must pass both description and guidelines in the update request as SpaceDetails」に続けて「If you only want to update one of the fields, pass the existing value for the other field.」とあります。説明だけを書き換える場合も、ガイドラインの現在の値を一緒に送る必要があります。先に spaces.get で現在の値を読んでから更新する流れにしておくと安全です。
表示名の重複で失敗する点も、自動作成では事前に考えておきたいところです。案件番号を表示名に含めるなど、組織内で重ならない名前の付け方を決めておくと、ALREADY_EXISTS の発生を減らせます。
初期メンバーは49人まで グループはIDで指定
spaces.setup の memberships には、作成者以外に最大49件を指定できます（「The set currently allows up to 49 memberships (in addition to the caller)」）。作成者は自動で入るので含めません。
指定の方法には決まりがあります。
- 社内のユーザー:
users/メールアドレスで指定できます。People API や Directory API のユーザーIDでも指定できます - 社外のユーザー: Gmail や他社の Workspace のユーザーは、メールアドレスで指定する必要があります
- Google グループ:
groups/グループIDで指定します。説明には「Group email is not supported」とあり、グループのメールアドレスでは指定できません。ID は Cloud Identity Groups API の lookup で取得するよう案内されています。グループを入れられるのは種類がSPACEのときだけです
担当チームをグループで管理しているなら、グループのIDを先に調べて設定に保存しておくと、案件ごとにメンバーを並べる必要がなくなります。
社外のユーザーを入れる場合は、作成時の externalUserAllowed も確認します。説明では「Optional. Immutable.」とされ、作成後には変えられません。社外の協力会社と同じスペースを使う運用なら、作成時に決めておく必要があります。
Chatアプリとして作るときの注意
ユーザー本人ではなく、Chat アプリ（サービスアカウント）として作る場合は、条件が増えます。spaces.create の説明から要点を挙げます。
- 管理者の承認（administrator approval）が必要で、スコープは
chat.app.spaces.createまたはchat.app.spaces - 種類が
SPACEのときはspace.customerの指定が必要 - アプリはメンバーとして追加されるが、スペースの管理者にはならない。初期状態ではメンバーの誰でもアプリを外せる。管理者だけに限りたい場合は
permission_settings.manage_appsをmanagers_allowedにする
自動化のアプリが外されると、その後の通知や更新が止まります。業務の仕組みとして使うスペースなら、manage_apps の設定を作成時に入れておくのが安全です。
実装前に決めておくこと
ここまでの API 定義を踏まえた、編集部の提案です。
- 作成のきっかけと
requestIdの保存先を決める。 問い合わせIDや案件番号と UUID を1対1で保存し、再試行では同じ値を使う - 表示名の付け方を決める。 組織内で重ならないよう、番号や日付を含める
- 説明に書く項目と、書かない項目を決める。 説明はスペースのメンバー全員が読めます。社外のユーザーを入れる場合は特に、個人情報や見積もりの金額をそのまま書かない
- メンバーはグループで渡す。 グループのIDを事前に調べておく
- Chat アプリとして作るなら、管理者の承認と
manage_appsを確認する
API でメッセージを検索・ピン留めする方法はChat APIでメッセージ検索とピン留め、送信者のメールアドレスを取得する条件はChat APIで送信者のメールが取れるように、スペースの基本的な使い方はGoogle Chat 活用ガイドで整理しています。
確認した範囲
2026年10月12日に、Google Chat API の Discovery 文書（chat.googleapis.com、revision 20261008）と、npm に公開された googleapis 178.0.0・180.0.0〜185.0.0 の Chat API の型定義を確認しました（資料調査）。2026年10月16日に、Discovery 文書（revision 20261013）で本文の引用が変わっていないこと、デベロッパー向けのリリースノートとガイド（スペースの作成・初期メンバーつきの作成・更新）に
requestIdと説明の上限の変更を扱った記載がないことを確認しました。Chat API の呼び出し、Apps Script からの利用、Chat の画面での表示は試していません。Google Workspace Updates では、該当する告知を見つけられていません。
Google Chat や Apps Script を使った業務の自動化は、IT・Google Workspace 無料相談からお問い合わせください。
