Contents
Make と Gmail の連携全体像
Make(旧 Integromat)で Gmail を操作する方法は大きく 公式 Gmail コネクション と カスタム HTTP モジュール(mailhook) の 2 通りに分かれます。本セクションでは、両者の特徴と選択基準をまず概観し、どちらが自社の要件に最も適しているか判断できるようにします。
公式 Gmail コネクション vs カスタム HTTP(mailhook)
それぞれのメリット・デメリット
公式コネクションは Make が Google の認証やエラーハンドリングを内部で最適化してくれるため、設定がシンプルです。一方、カスタム HTTP は API の全機能に直接アクセスできる柔軟性がありますが、認証フローやリトライ処理を自前で実装する必要があります。
| 項目 | 公式 Gmail コネクション | カスタム HTTP(mailhook) |
|---|---|---|
| 導入ハードル | UI だけで完結。OAuth 設定は自動化 | OAuth フローを自分で実装 |
| 保守性 | Google の API 変更に自動追随 | エンドポイント変更時に手動更新 |
| パフォーマンス | レートリミット管理が組み込まれている | 全て自前で制御 |
| 拡張性 | 提供機能に限定(メール取得・送信) | 任意の Gmail API エンドポイントへアクセス可能 |
| エラーハンドリング | 標準ハンドラが利用できる | HTTP ステータスコードを自前で判定 |
結論
- 標準的なメール取得・送信やシンプルなフロー は公式コネクションで十分です。
- バッチ取得、未公開 API、独自ヘッダーが必要 なケースではカスタム HTTP が有効です。
Google Cloud Console で Gmail API を有効化し OAuth クライアント ID を作成
Gmail API と Make を連携させる第一歩は、Google Cloud Console 上でプロジェクトと認証情報を準備することです。以下では、2026 年時点の UI に合わせた具体的手順を示します。
手順概要
- プロジェクト作成 – コンソールにログインし新規プロジェクトを作ります。
- Gmail API の有効化 – ライブラリから Gmail API を検索して有効化します。
- OAuth クライアント ID 作成 – 認証情報メニューで「Web アプリケーション」を選択し、必要なリダイレクト URI を登録します。
- クライアント情報の取得 – 作成された
Client IDとClient Secretを控えておきます。 - 利用スコープの確認 – 後述する接続設定で使用するスコープを一覧化しておきます。
詳細手順
| 手順 | 操作内容 |
|---|---|
| 1️⃣ プロジェクト作成 | コンソール(https://console.cloud.google.com/)左上の「プロジェクト選択」 → 「新規プロジェクト」→ 名前を入力し「作成」 |
| 2️⃣ API 有効化 | 左メニュー「API とサービス」→「ライブラリ」→「Gmail API」を検索し「有効にする」 |
| 3️⃣ 認証情報作成 | 「認証情報」→「認証情報を作成」→「OAuth クライアント ID」 → アプリケーションの種類は Web アプリケーション、承認済みリダイレクト URI に https://hook.make.com/oauth2/callback を追加 |
| 4️⃣ 情報取得 | 作成完了画面に表示される「クライアント ID」および「クライアント シークレット」をコピー |
| 5️⃣ スコープ確認 | 後述の表を参照し、必要なスコープだけを選択できるようメモしておく |
必要スコープ(公式コネクション・カスタム HTTP 共通)
| スコープ URL | 権限の概要 |
|---|---|
https://mail.google.com/ |
フルアクセス(送信・削除・ラベル操作) |
https://www.googleapis.com/auth/gmail.readonly |
読み取り専用 |
https://www.googleapis.com/auth/gmail.modify |
ラベル付与やステータス変更 |
https://www.googleapis.com/auth/gmail.send |
メール送信 |
ポイント:最小権限の原則に従い、実際に必要なスコープだけを選択してください。過剰な権限はトークン更新時のエラー原因になることがあります。
Make で公式 Gmail コネクションを設定しスコープを選択
Google 側の準備が完了したら、Make の管理画面から接続情報を登録します。このセクションでは UI 操作と推奨スコープの決め方を解説します。
接続作成手順
- Connections メニューへ – Make にログイン後、左サイドバーの「Connections」→「Create a connection」をクリック。
- Gmail を選択 – カテゴリ一覧から Google → Gmail を選びます。
- クライアント情報入力 – 先ほど取得した
Client IDとClient Secretをそれぞれの欄に貼り付けます。 - スコープ選択 – 表示されるチェックボックスから必要なスコープを選びます(例:
https://mail.google.com/、...gmail.readonly、...gmail.send)。 - 認可実行 – 「Authorize」 ボタンをクリックし、Google の認証画面で権限を付与。成功すると接続が一覧に表示されます。
推奨スコープ構成例
| シナリオ | 必要最低スコープ |
|---|---|
| メール取得+送信 | https://mail.google.com/(フルアクセス) または ...gmail.readonly + ...gmail.send の組み合わせ |
| ラベル操作・ステータス変更 | 上記に加えて ...gmail.modify |
| 最小権限で取得だけ | ...gmail.readonly のみ |
注意点:スコープは後から追加できません。必要になる可能性がある機能はあらかじめ含めておくと、再認可の手間を省けます。
カスタム HTTP(mailhook)で Gmail API を直接呼び出す方法
公式コネクションが対応していないケースや、独自ヘッダー・特殊パラメータが必要な場合は、Make の HTTP モジュール で OAuth2.0 フローと API リクエストを自前で実装します。
1. 認可コード取得(手動または別シナリオ)
ユーザーに次の URL にアクセスさせ、code パラメータを取得します。
|
1 2 3 4 5 6 |
https://accounts.google.com/o/oauth2/v2/auth? client_id=YOUR_CLIENT_ID& redirect_uri=https%3A%2F%2Fhook.make.com%2Foauth2%2Fcallback& response_type=code& scope=https%3A%2F%2Fmail.google.com%2F |
2. アクセストークン取得(HTTP モジュール)
|
1 2 3 4 5 6 7 8 9 |
{ "method": "POST", "url": "https://oauth2.googleapis.com/token", "headers": { "Content-Type": "application/x-www-form-urlencoded" }, "body": "code={{authorization_code}}&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&redirect_uri=https%3A%2F%2Fhook.make.com%2Foauth2%2Fcallback&grant_type=authorization_code" } |
成功例(抜粋):
|
1 2 3 4 5 6 7 8 |
{ "access_token": "ya29.a0AfH6SM...", "expires_in": 3599, "refresh_token": "1//04iV...", "scope": "https://mail.google.com/", "token_type": "Bearer" } |
3. Gmail メッセージ取得サンプル(GET リクエスト)
|
1 2 3 4 5 6 7 8 9 10 11 12 |
{ "method": "GET", "url": "https://gmail.googleapis.com/gmail/v1/users/me/messages", "headers": { "Authorization": "Bearer {{access_token}}" }, "query": { "maxResults": 10, "labelIds": "INBOX" } } |
返却例(抜粋):
|
1 2 3 4 5 6 7 8 9 |
{ "messages": [ {"id":"1735c6e...", "threadId":"1735c6e..."}, {"id":"a7b2d9f...", "threadId":"a7b2d9f..."} ], "resultSizeEstimate": 2, "nextPageToken": "XYZ" } |
4. エラーレスポンス例と対処
| HTTP ステータス | 主な原因 | 推奨対応 |
|---|---|---|
| 401 | アクセストークン無効・期限切れ | refresh_token を使って再取得、失敗したらユーザーに再認可を促す |
| 403 | スコープ不足 | 必要スコープを追加して再認可 |
| 429 | レートリミット超過 | エクスポネンシャルバックオフ(Delay モジュール)でリトライ |
| 500 系 | Google 側一時障害 | 数回リトライ後に失敗として通知 |
トークン自動更新とエラーハンドリングのベストプラクティス
Make のシナリオ内でトークン切れや API エラーが発生した場合、自動再認証 と 適切な通知 が運用の安定性を左右します。以下は実務で検証済みのパターンです。
1. Refresh Token の永続化
- HTTP モジュールで取得した
refresh_tokenを Data Store(キー‑バリュー) に保存する。 - キー名は例として
gmail_refresh_tokenとし、シナリオ全体で参照できるようにしておく。
2. 自動更新フローの構成例
| ステップ | 使用モジュール | 主な設定 |
|---|---|---|
| ① | HTTP(トークン取得) | grant_type=refresh_token、refresh_token={{DataStore[gmail_refresh_token]}} |
| ② | Router | 成功時は次の処理へ、失敗時はエラーハンドラへ分岐 |
| ③ | Set Variable | 新しい access_token を変数に格納し、以降の API 呼び出しで使用 |
| ④ | Error Handler | 401/403 が返ったら「再認可 URL」へのリダイレクトや Slack 通知を実行 |
3. エラーハンドリングパターン
- 401 / 403 → リフレッシュトークンで再取得。再取得に失敗した場合は手動認可へ誘導(メール・Slack にリンクを送る)。
- 429 →
Delayモジュールで指数バックオフ(1 → 2 → 4 秒)し、最大 3 回までリトライ。 - 500 系 → 一時的障害とみなし、
Iteratorでリトライ回数を制御しつつ再送。
実装ヒント:Make の Error handler はシナリオ全体に対して 1 回だけ設定すれば済むため、上記パターンをテンプレート化すると他の Google API でもそのまま流用できます。
実装例シナリオ:未読メール → ChatGPT 翻訳・要約 → Discord 通知
以下は「未読メールを自動で英語に翻訳し、要約した上で Discord に通知する」典型的なフローです。公式 Gmail コネクションと OpenAI API、Discord Webhook を組み合わせています。
フロー全体のステップ
- Gmail(Watch Emails) – 未読かつラベル
auto-translateが付いたメールを取得。 - フィルタ条件 – 件名に
[Translate]が含まれるか、送信者ドメインがexample.comのものだけ通す。 - ChatGPT 翻訳・要約(HTTP) – OpenAI の Chat Completion API を呼び出し、本文を英語翻訳+要約させる。
- Discord Webhook 送信 – 翻訳結果と要約を Discord に投稿。
- メールステータス更新 – ラベル
translatedを付与し、未読フラグを外す。
サンプルシナリオ JSON(Make の「Import scenario」から使用可)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
{ "name": "Gmail → ChatGPT → Discord", "modules": [ { "type": "gmail.watchEmails", "connectionId": "{{gmail_connection}}", "parameters": { "labelIds": ["INBOX","auto-translate"], "query": "is:unread" } }, { "type": "filter", "conditions": [ {"field":"subject","operator":"contains","value":"[Translate]"}, {"field":"from","operator":"endsWith","value":"@example.com"} ] }, { "type": "http.request", "method": "POST", "url": "https://api.openai.com/v1/chat/completions", "headers": { "Authorization": "Bearer {{OPENAI_API_KEY}}", "Content-Type": "application/json" }, "body": "{{#json}}\n{\n \"model\": \"gpt-4o-mini\",\n \"messages\": [\n {\"role\":\"system\",\"content\":\"You are a translator and summarizer.\"},\n {\"role\":\"user\",\"content\":\"Translate the following Japanese email to English and provide a concise summary:\\n\\n{{email_body}}\"}\n ],\n \"temperature\": 0.2\n}\n{{/json}}" }, { "type": "http.request", "method": "POST", "url": "{{DISCORD_WEBHOOK_URL}}", "headers": {"Content-Type":"application/json"}, "body": "{{#json}}\n{\n \"content\": \"**{{email_subject}}**\\n_翻訳・要約_\\n{{response.choices[0].message.content}}\"\n}\n{{/json}}" }, { "type": "gmail.modifyMessage", "connectionId": "{{gmail_connection}}", "parameters": { "messageId": "{{email_id}}", "addLabelIds": ["translated"], "removeLabelIds": ["UNREAD"] } } ] } |
この JSON を Make の Import scenario 機能に貼り付けるだけで、すぐにテストが開始できます。実際の運用では {{gmail_connection}}・{{OPENAI_API_KEY}}・{{DISCORD_WEBHOOK_URL}} などを自環境の値に置き換えてください。
まとめと次のアクション
- 公式 Gmail コネクション は設定が簡単で保守性が高く、基本的なメール取得・送信に最適です。
- カスタム HTTP(mailhook) は未対応機能や独自ヘッダーが必要な場合に有用ですが、認証・リトライ処理を自前で実装する手間があります。
- Google Cloud Console での OAuth クライアント ID 作成 と スコープ選定 が連携の出発点です。
- トークンの 自動更新 と エラーハンドリング は Data Store + Error Handler パターンで安定運用が実現できます。
- 実装例シナリオ「未読メール → ChatGPT 翻訳・要約 → Discord」 は、業務効率化の典型的ユースケースとしてすぐに試せます。
次のステップ
1. Make の無料プランにサインアップし、Google アカウントでログイン。
2. 本稿の手順に従い Google Cloud Console でプロジェクトと OAuth クライアントを作成。
3. 上記 JSON を Import scenario に読み込んで動作確認。
4. 必要に応じてスコープやフィルタ条件、通知先(Slack や Teams など)へカスタマイズ。
これらを実践すれば、Gmail と外部ツールの連携がどれだけ業務をシンプルにできるか体感できるはずです。ぜひまずはハンズオンで試してみてください。