運用と乗り換え
Makeの自動化例｜Excel・メール・ChatGPT
転記・通知・分類をどうつなぐ？3つの具体例で処理の流れを分解し、難しい部分と人間が残す仕事を整理します。
公式資料に基づくLevel Aの設計例です。実機で試した体験談ではありません。
月曜日にコピー、火曜日にもコピー、水曜日はなぜか同じ内容をもう一度コピー。 その仕事に判断がいらないなら、人間の担当を卒業させられるかもしれません。
Makeは、普段使うWebサービス間で「何かが起きたら、次に何をするか」を設定する自動化ツールです。この記事ではサービスの総合紹介ではなく、実際の仕事をどういう順番の処理に分解するかに絞って説明します。実機を操作したレビューではありません。公式が公開する連携機能を使った設計例です。
最初に3つ：どんな仕事をどうつなぐ？
| やりたい仕事 | Makeに設定する流れ | 人間に残す仕事 |
|---|---|---|
| フォームの問い合わせを台帳とチャットへ反映 | フォーム受信 → 情報を整形 → 台帳へ追加 → 担当へ通知 | 対応方針の判断・返信 |
| Excelの行をChatGPTで要約・分類 | Excel新規行 → OpenAIへ送信 → 結果を保存 | 分類精度の確認・例外処理 |
| 毎朝のメール内容を整理 | 対象メール取得 → 条件分岐 → 一覧に保存・通知 | 重要な内容の確認 |
どの例も「すべての操作がどの環境でも可能」という意味ではありません。具体的なTrigger/Action、認証権限、保存先、実行間隔は個々に確認します。
例1｜問い合わせの転記と担当者通知をつなぐ
フォームへの問い合わせを「担当者がメールを開く → 顧客台帳へコピー → Slackで連絡」と処理しているとします。
Makeで考えると、フォーム受信 → データ取得 → Google Sheetsに行を追加 → Slackへ通知です。先頭のフォームがWebhook送信に対応しているか、定期取得で確認する必要があるかはフォーム側の機能によります。
- 開始条件（Trigger）を決める。新規フォーム送信、または対応するイベントの検知。
- 取得データを確認する。氏名・会社名・メール・問い合わせ本文などの項目。
- 項目を対応付ける（Mapping）。「氏名」をシートの氏名列へ、「本文」を問い合わせ内容列へ。
- Google Sheetsへ保存する。保存済みIDなどで重複登録を避ける設計を検討する。
- Slackへ通知する。「新規問い合わせ：〇〇社／担当者に確認依頼」など、必要最小限の情報だけ送る。
- 失敗時を決める。接続が切れたら誰が気付くか、再実行で二重登録しないか。
ここで自動化されるのは、あくまで転記・連絡です。見積回答やクレームへの対応判断まで自動的に正しくなるわけではありません。業務は短くできますが、責任まで短くはできません。
例2｜Excelに新しい行ができたらChatGPTで分類する
Microsoft 365 Excelのテーブルに新しい行を追加 → OpenAIで内容を分類 → 結果を保存。これはMake公式のExcel×OpenAI連携紹介で確認できる種類の設計です。
たとえば問い合わせ一覧に、自由記述の「要望」が追加されたとします。Excelの Watch Table Rows など、対象ファイル構造に合うTriggerで新しい行を取得し、OpenAIのアクションへ文章を渡します。モデルへの指示は、例えば「カテゴリを見積・サポート・その他の3つから選び、JSON形式で返す。判断不能はその他」とします。
戻された分類結果を保存するには、対象Excelの更新Action、シート構造、行IDの扱いを確認します。AIに処理を渡すことと、AIの判断を正解として扱うことは別問題です。重要な案件は人間がレビューする導線を残してください。
なお、「ChatGPTを使う」という言い方でも、実際の自動化ではOpenAI APIなどの接続設定・料金が必要になる場合があります。ChatGPTの個人向け契約がMakeからのAPI呼び出し費用を自動的に含むわけではありません。
例3｜メールを条件ごとに振り分ける
指定条件のメールを取得 → 件名・差出人などで判定 → 担当者へ通知／一覧へ保存。何を実行できるかはメールサービスの連携モジュールと権限に依存します。
最初は「差出人が特定のアドレスなら通知」のような単純条件で十分です。Routerで流れを分け、Filterで通す条件を決めます。自由記述から意図を読み取りたい場面だけAIを使う構成にすれば、通常処理とAI処理の費用を区別しやすくなります。
機密メール全文をAIに渡す前に、入力データとサービス側のデータ取扱条件を確認してください。送れたからといって、送ってよいとは限りません。
Scenario、Module、Triggerとは？
Makeは仕事の流れを Scenario と呼び、その中に処理部品である Module を置きます。新しいデータの検知など、処理の開始条件が Trigger。その後にデータの作成・検索・更新・送信などの Action が続きます。前段のデータを次に渡すのが Mapping です。
ノーコードでも、どの列に何の値を入れるか、エラー時にどう扱うかは人間が決めます。「コードを書かなくてよい」と「設計しなくてよい」は同義ではありません。
料金は何に左右される？
Makeの Operations はモジュールがデータを処理・確認する実行単位、Credits は主な課金単位です。通常の非AIアプリでは原則 1 Operation = 1 Credit ですが、処理するデータの束（bundle）数によってOperationは増減し、一部のAI機能は利用量に応じた可変Creditsが発生します。
仮に、1イベントで標準モジュールが4回実行される設計なら、月1,000イベントで4,000 Creditsという説明用の算術ができます。実行履歴に基づく検証結果ではありません。トリガーのチェック、複数レコード、再試行、AI、外部API利用料金などを含まないため、請求予想と同一視しないでください。
自動化は仕事を減らしてくれますが、請求書まで自動的に小さくしてくれるわけではありません。
プラン比較は Makeの基本情報 と Make Creditsの詳しい解説 へ。この記事では業務を組み立てる判断に集中します。
最初の1本を選ぶときのチェック
- 手順が毎回ほぼ同じで、作業回数が多いか
- 各アプリに必要なTrigger/Actionが存在するか
- 保存先、権限、機密情報の取り扱いに問題がないか
- 失敗を検知し、修正する担当者がいるか
- 導入後の保守時間とCredits・外部サービス費用を差し引いても価値があるか
1回しか使わない処理なら、Scenarioを作るより自分で済ませた方が早いこともあります。自動化は、仕事が増えるほど褒められる趣味ではありません。
まだ調べますか？
- Make自体が自分に合う？ Makeとは？概要・料金・導入判断 — まず導入する必要があるか
- 使うといくらかかる？ Make Credits — 処理量と費用の条件を詳しく
- 他サービスとどちらを選ぶ？ Make vs Activepieces — 実行場所やCreditsの違いを比較
公式資料・検証範囲
Level A：公式資料に基づく説明です。実機検証・請求額の実測ではありません。