Google Chatのメッセージを集計して日報や問い合わせ台帳を作る仕組みを、Apps Scriptや社内ツールで組んでいる。ところが、ユーザー認証でChat APIを呼んで取れる送信者は users/1234567890 のようなIDだけで、誰の発言かを表に出すには、別のAPIで名前やメールを引き直す必要がありました。この「IDから人を引き直す」手間に関わる定義が、2026年9月に変わっています。
2026年10月5日に、Googleが公開しているChat APIの定義ファイル（googleapis/googleapis）の変更、Chat APIのDiscovery文書（v1、revision 20260928）、開発者向けのリリースノートとユーザーの識別に関するガイドを直接開いて読みました。ユーザー認証でメッセージやメンバーを取得したとき、条件を満たす相手については表示名・メールアドレス・アイコンのURLが返ると書かれています。本記事は資料調査と編集部の提案です。認証情報がないためAPIの実際の呼び出しは行っていません。
何が変わったのか：Userに2つの項目が増えた
Chat APIで人を表す User リソースに、2026年9月29日付のコミット（d6ec9a5、「feat: Expose avatar_url and email fields on User」）で email と avatarUrl の2項目が加わりました。あわせて、どの場面で値が入るかの説明が書き直されています。Chat APIの開発者向けリリースノートでも、9月28日付で一般提供（Generally Available）として告知されました。
変更前の User の説明は次の1文でした。
When returned as an output from a request, if your Chat app authenticates as a user, the output for a
Userresource only populates the user’snameandtype.
ユーザー認証（ユーザーとしてAPIを呼ぶ方式）では、返るのはリソース名（users/{user}）と種別（人かアプリか）だけ、という意味です。変更後は「スペースのメンバーであるか、呼び出したユーザーと以前からのつながり（prior affinity）がある場合を除き」という条件付きに変わりました。条件を満たすと、表示名・メール・アイコンのURLが返ります。
| 項目 | ユーザー認証で値が入る条件（原文の要約） | 変更前 |
|---|---|---|
displayName | 送信者・メンション・メンバーについて、条件を満たせば社内外とも | 返らない |
email | 同上 | 項目なし |
avatarUrl | 同上 | 項目なし |
isAnonymous | 条件を満たさないメンション相手などは true | 説明のみ変更 |
「以前からのつながり」の例として、メンバーの説明には「like a direct message (DM) conversation」とあり、呼び出したユーザーとダイレクトメッセージをしたことがある相手が該当します。一方、スペースのメンバーでもなく、つながりもない人がメンションされた場合は、isAnonymous が true になる例として新たに書かれました。
アプリ認証（Chatアプリ自身として呼ぶ方式）については、displayName は「always populated」と書かれています。email と avatarUrl の説明はユーザー認証の場合だけを述べており、アプリ認証で返るかは、開発者向けガイドを含め確認した資料からは読み取れませんでした。
値が入るのは「送信者・メンション・メンバー」の3か所
説明文は、値が入る場所を3つに限定しています。
- メッセージの
sender（送信者） - メッセージの
annotations（メンションされたユーザーなど） Membershipリソース（スペースのメンバー一覧）
Discovery文書上、メッセージの取得（spaces.messages.list・get）は chat.messages または chat.messages.readonly スコープ、メンバーの取得（spaces.members.list・get）は chat.memberships または chat.memberships.readonly スコープなどで呼べます。ユーザー認証で spaces.members.list を呼んだ場合、レスポンスの member は、定義どおりなら次の形になります（実際の呼び出し結果ではなく、Discovery文書の項目から組み立てた例です）。
{
"name": "spaces/AAAA1234/members/1234567890",
"member": {
"name": "users/1234567890",
"displayName": "山田 太郎",
"email": "taro.yamada@example.co.jp",
"avatarUrl": "https://…",
"type": "HUMAN"
},
"role": "ROLE_MEMBER"
}Node.js向けのクライアントライブラリ @googleapis/chat は、10月3日に公開された51.2.0の型定義に email? と avatarUrl? が入っていることを確認しました。Apps Scriptの高度なサービス（Advanced Chat Service）や他の言語のライブラリでの対応状況は、確認していません。
自動化の作り方がどう変わるか（編集部の整理）
これまで、ユーザー認証で取ったメッセージの送信者を人の名前やメールにするには、users/{user} のIDを使ってPeople APIなど別のAPIで引き直す必要がありました（変更前の説明では、返るのは名前と種別だけでした）。Chat APIの User.name の説明にも、{user} はPeople APIのPersonのIDと同じだと書かれています。
定義どおりに値が返るなら、送信者やメンバーの表示名・メールを、Chat APIの応答1回で受け取れる場面が増えます。たとえば次のような処理です。
- 問い合わせ用スペースの投稿を、送信者のメール付きでスプレッドシートに転記する
- スペースのメンバー一覧を、メールアドレスで社内の名簿と突き合わせる
- メンションされた担当者のメールに、未対応の投稿をまとめて通知する
ただし、条件を満たさない相手は従来どおり名前と種別しか返りません。email が空の場合に引き直す処理や、isAnonymous の相手を「不明」として扱う処理は残しておくのが安全です。スプレッドシートを台帳にした構成は、GASによる自動化の基本の考え方をそのまま使えます。
管理者が先に確かめること：社外の人のメールもアプリに渡る
説明文は、値が入る対象を「both internal and external users」（社内と社外の両方）としています。取引先を招いたスペースで、ユーザー認証のアプリがメッセージやメンバーを読むと、社外の担当者のメールアドレスもアプリ側に渡ることになります。
ここで注意したいのは、メンバー一覧の見え方を絞る設定との関係です。Chatには、スペースのメンバー一覧を見られる人を制限する機能があり（メンバー一覧を隠す設定の記事）、同じ9月の更新でAPIからもこの設定（viewSpaceMembership）を変更できるようになりました。この制限が、ユーザー認証のアプリが受け取る email にどう効くのかは、取得できた資料には書かれていません。社外を含むスペースでは、検証用のスペースで確かめるまで「制限していればアプリにも見えない」と決めつけないでください。
編集部としては、次の順で確認することを勧めます。
- ユーザー認証でChatを読むアプリを洗い出す。
chat.messages・chat.messages.readonly・chat.memberships系のスコープを許可しているアプリが対象です。Chatアプリの許可と停止の考え方はChatアプリの許可リストと停止の記事で整理しています - アプリの保存先を確認する。 取得したメールをスプレッドシートや外部のデータベースに残す場合、社外の人の個人情報を保存することになります。保存の目的と期間を決めます
- 検証用スペースで実際の応答を見る。 社内の人・社外の人・DMをしたことがない人を混ぜたスペースで、
emailが返る相手と返らない相手を確認します
組み込む前に知っておきたい落とし穴
- 全員分のメールが返る前提で作る。 返るのは条件を満たす相手だけです。メンバーでもなくつながりもない人がメンションされた場合は、
isAnonymousがtrueになります - アプリ認証でも同じと考える。 アプリ認証で
displayNameは常に返ると書かれていますが、email・avatarUrlについての記述はありません - 対象エディションを決めつける。 開発者向けのリリースノートは9月28日付の一般提供と告知していますが、対象エディションの記載はありません。Workspace Updatesは確認していません
- アイコンのURLを長期保存する。
avatarUrlの有効期間は資料に書かれていません。表示のたびに取り直す前提で扱うのが無難です
まずは、いまChatを読んでいる社内ツールが「ユーザー認証かアプリ認証か」と「取得した人の情報をどこに保存しているか」を確かめてください。そのうえで、検証用スペースで1回 spaces.members.list を呼び、返る項目を確認してから、引き直し処理を減らすかを決めるのが安全です。
2026年10月5日に、googleapis/googleapis のChat API定義ファイル（
google/chat/v1/user.proto・message.proto・membership.proto、commit d6ec9a5 とその直前）、Chat APIのDiscovery文書（v1、revision 20260928）、Chat APIのリリースノートと「Identify and specify Google Chat users」のガイド、google-api-go-client の履歴、npmの@googleapis/chat51.2.0 の型定義を直接取得して照合しました（資料調査）。自動化の整理と確認手順は編集部の提案です。認証情報がないためAPIの呼び出しは実施しておらず、実際の応答、アプリ認証での
Google Chatを使った業務の自動化や、Chatアプリの権限の見直しは、グリームハブのIT・Google Workspace 無料相談で承っています。扱う情報や社外とのやり取りの多さによって進め方が変わるため、お問い合わせからご相談ください。
参考資料
- googleapis/googleapis — commit d6ec9a5（Expose avatar_url and email fields on User）
- googleapis/googleapis — google/chat/v1/user.proto（d6ec9a5）
- googleapis/googleapis — commit f822db2（view space membership permission settings）
- Google Chat API — Release notes（2026年9月28日）
- Google Chat — Identify and specify Google Chat users
- Google Chat API Discovery document (v1)
- googleapis/google-api-go-client — chat/v1/chat-api.json（2d9e29d）
- npm registry — @googleapis/chat
