この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。
Google Contactsを、単なる「メールアドレス帳」ではなく、個人の連絡先とGoogle Workspaceのディレクトリ情報を使い分けるためのサービスとして整理します。Google公式のContactsヘルプ、People API、Domain Shared Contacts API資料を確認し、一般利用者・管理者・開発者それぞれの視点からまとめます。
情報確認基準日：2026-09-19
まず結論：Google Contactsは何？
Google Contactsは、名前、メールアドレス、電話番号などの連絡先情報を保存・整理するGoogleのサービスです。
GmailなどGoogleのサービスから相手を探すときにも関係します。ただし、Google Workspaceの組織では「自分で登録した個人連絡先」と「組織のDirectoryにあるユーザー情報」を同じものだと思わないことが重要です。
Google全体ではどこにある？
| 観点 | 位置づけ |
|---|---|
| 大分類 | Google / Google Workspaceの連絡先・人物情報 |
| 主な目的 | 人の連絡先情報を保存・検索・整理する |
| 個人向けの中心 | Google Contacts |
| 開発者向け | People API |
| Workspace組織情報 | Domain Directory |
| 組織共通の外部連絡先 | Domain Shared Contacts API |
| 一緒に使う代表サービス | Gmail、Calendar、Google Workspace |
flowchart TB User[利用者] --> Contacts[Google Contacts] Contacts --> Personal[自分の連絡先] Contacts --> Other[Other contacts] Workspace[Google Workspace] --> Directory[組織Directory] Developer[開発者] --> People[People API] People --> Personal People --> Other People --> Directory Admin[管理者] --> Shared[Domain Shared Contacts]
「連絡先」と「組織Directory」は違う
ここがGoogle Contactsを理解するうえで重要です。
People APIでは、認証された利用者自身のContactsを読み書きできるほか、Google Workspace利用者は権限に応じてドメイン内のプロフィールやドメイン連絡先を検索できます。
一方、組織内ユーザーの情報は個人のContactsとは別の情報源です。Google公式も、People APIが複数の情報源を統合して人物情報を返すことを説明しています。
| 種類 | 例 | 主な管理主体 |
|---|---|---|
| 個人Contacts | 自分で登録した取引先 | 利用者 |
| Other contacts | Googleサービス利用中に候補として蓄積された相手 | 利用者側 |
| Domain profile | 自社・自組織のユーザー | Workspace組織 |
| Domain shared contact | 全社で共有したい外部連絡先 | Workspace管理側 |
一般利用者・事務職ではどう使う？
たとえば取引先の担当者を登録する場合、
氏名
会社名
メールアドレス
電話番号
補足情報
などを連絡先として整理できます。
ラベルを使えば、「取引先」「プロジェクトA」のように分類することもできます。
ただし、業務で個人情報を登録する場合は、組織の情報管理ルールに従います。パスワードやAPIキーなど、連絡先ではない秘密情報をメモ欄へ保存する用途には使いません。
Google Workspaceでは何が変わる？
Workspaceでは、個人の連絡先だけでなく組織Directoryが関係します。
そのため、Gmailなどで名前を入力した際に候補として出てくる相手が、必ずしも自分のContactsへ手動登録した人物とは限りません。
Google Workspaceでは、管理者の設定や権限に応じてドメイン内プロフィールや連絡先情報を利用できます。
さらにWorkspaceでは、同じ組織内のユーザーへ自分の連絡先管理を委任する機能があります。Google公式によると、連絡先の委任は同一ドメインまたは同一組織内で利用し、Directory管理者側で連絡先共有が有効である必要があります。
開発者向け：People APIとは？
Google Contactsのデータをプログラムから扱う中心的なAPIが People API です。
People APIでは、認証ユーザーのContactsについて、一覧取得、検索、作成、更新、削除などを扱えます。またGoogle Workspaceでは、権限に応じてドメインのプロフィールや連絡先を検索できます。
代表例は次の通りです。
| やりたいこと | People APIの例 |
|---|---|
| 自分の連絡先一覧 | people.connections.list |
| 連絡先を検索 | people.searchContacts |
| 新規連絡先作成 | people.createContact |
| 既存連絡先更新 | people.updateContact |
| 連絡先削除 | people.deleteContact |
| 組織Directory検索 | people.searchDirectoryPeople |
| 連絡先グループ管理 | contactGroups |
People APIのサービスエンドポイントは people.googleapis.com です。
APIで安全に試すなら読み取りから
最初から連絡先を大量作成・削除するより、テスト用Googleアカウントまたは許可された環境で読み取りから始めます。
たとえば自分のContacts一覧を取得する基本形は次の考え方です。
GET /v1/people/me/connections ?personFields=names,emailAddresses Host: people.googleapis.com
確認すること：自分が想定した連絡先だけが返るか。
成功条件：HTTPエラーではなく、許可したフィールドの連絡先情報を取得できること。
personFields を変えると、取得対象フィールドを絞れます。必要のない情報まで取得しない設計は、プライバシー面でも重要です。
OAuth scopeに注意
People APIで連絡先を作成する場合、Google公式の people.createContact はContactsへのOAuth権限を要求します。
OAuth scopeは「アプリへどこまでアクセスを許すか」を表します。
読み取りだけで済む処理に書き込み権限を持たせる、といった過剰な権限設計は避けます。
また、OAuth token、client secret、実在するメールアドレス、実ユーザーIDなどをGitHubへ保存しません。
Domain Shared Contacts APIとは？
Workspaceには、組織全体で共有する外部連絡先を扱うDomain Shared Contacts APIもあります。
Google公式は、このAPIを「Google Workspaceドメインの全ユーザーと共有する外部連絡先」を取得・更新するものとして説明しています。
重要なのは、これは外部連絡先用だということです。
Google公式は、内部ユーザーやグループの情報をこのAPIで作成すると、重複や予期しない動作につながる可能性があるため、内部ユーザー情報の管理にはDirectory APIを使うよう案内しています。
flowchart LR
A[人物情報を管理したい] --> B{誰の情報?}
B -->|自分の私的な連絡先| C[Google Contacts / People API]
B -->|組織内部ユーザー| D[Workspace Directory / Directory API]
B -->|全社共有する外部連絡先| E[Domain Shared Contacts API]
この切り分けを覚えると、Contacts関連APIをかなり理解しやすくなります。
Microsoft 365で考えると？
Microsoft 365経験者なら、Google ContactsだけをOutlookの「連絡先」と一対一対応させるより、
個人のContacts
組織Directory
組織共有の外部連絡先
を分けて理解する方が安全です。
| Google側 | Microsoft側で近い考え方 |
|---|---|
| Google Contacts | Outlookの個人連絡先 |
| Workspace Directory | Microsoft 365 / Entra ID側の組織ユーザー情報 |
| People API | Microsoft Graphの人物・連絡先関連APIを用途別に確認 |
| Domain Shared Contacts | 組織で共有する外部連絡先の仕組みを別途設計 |
製品構造やAPIは同一ではありません。「アドレス帳」という画面だけではなく、誰が管理する人物情報なのかを見ることがポイントです。
IT管理者が見るポイント
管理者は特に次を分けて考えます。
組織内部ユーザー
個人が所有するContacts
組織共通の外部連絡先
連絡先委任
APIからのアクセス権限
「全社員へ見せたいから各ユーザーのContactsへ同じデータをコピーする」といった設計をする前に、DirectoryやDomain Shared Contactsの用途を確認します。
セキュリティと個人情報
連絡先は氏名、メールアドレス、電話番号、所属など個人情報を含みやすいデータです。
必要のない情報を登録しない
APIでは必要最小限のscopeとフィールドを使う
実在する個人情報をサンプルコードへ埋め込まない
OAuth tokenやclient secretを保存しない
大量更新前にバックアップ・テスト・権限を確認する
同じユーザーへのAPI変更要求は順番に処理する
Google公式はPeople APIで、同一ユーザーに対する変更リクエストを順次送信するよう案内しています。並列で大量更新する設計は避けます。
安全にGUIで試す
Google Contactsを開く。
実在人物ではなくダミーのテスト連絡先を1件作る。
ラベルを1つ付ける。
検索して見つかることを確認する。
テストが終わったら不要なダミー連絡先を削除する。
成功条件：作成したダミー連絡先を検索でき、ラベルで整理できること。
最初に変えるなら、ラベルだけを変更して「人物データ」と「分類」の違いを確認すると安全です。
公式情報
次に何をすればよい？
一般利用者・事務職なら、まずダミー連絡先を1件作り、ラベルと検索を試します。
IT管理者なら「個人Contacts」「内部Directory」「全社共有の外部連絡先」の3種類を分けて、自組織で誰がどの情報を管理するのか整理します。
開発者ならPeople APIを有効化したテスト環境で、書き込みより先にContactsの読み取りから始め、必要なOAuth scopeと取得フィールドを最小化します。
Papanda TRY：ContactsはCSV比較で目に見せる
架空の3名だけを使い、Google Contactsへ取り込むCSVの列とOutlook等のCSV列を並べるデモにします。開発する場合はPeople APIを確認します。メールはexample.comなどのダミー値を使います。Daily Code候補：google-contacts-csv-sample。
結局どういうサービス？
Google Contactsは、Googleで人の連絡先情報を管理するための個人向けの入口です。
Google Workspaceでは、それに組織Directoryや共有外部連絡先という別の人物情報が加わります。開発者はPeople API、管理者はDirectoryやDomain Shared Contactsも含めて、「誰の情報を、誰が管理するのか」で使い分けると全体像を理解しやすくなります。
