Makeとは？アプリをつなぐ自動化の機能・料金・使い方を解説
Makeのシナリオ、モジュール、クレジットを整理。Google SheetsからSlackへ通知する公式例をもとに、最初の自動化を組み立てる手順を紹介します。
情報確認日：2026年11月5日。公式ページ本文を確認した原稿です。外部アプリの接続やシナリオの実行は行っていません。料金は申し込み時に最新条件を確認してください。
リード
表に追加された情報を見つけて、チャットへ転記する。別の担当者へ同じ内容を知らせる。こうした繰り返しの作業を、アプリ同士の接続として組み立てるサービスがMakeです。公式サイトでは、アプリやデータ、AIを視覚的につなぐ自動化を案内しています。Make公式サイト
最初から業務全体を自動化する必要はありません。「何が起きたら、どの情報を、どこへ渡すか」を一つ決めるところから始められます。この記事では、基本用語と利用量の考え方を整理し、公式の入門例をもとに、通知の仕組みを作る流れを紹介します。
Makeとは
Makeでは、一連の自動処理を「シナリオ」と呼びます。その中に置く各アプリの処理が「モジュール」です。公式入門ガイドは、Google Sheetsの新しい行を見つけ、Slackへ通知するシナリオを例に説明しています。最初のシナリオ
この例なら、表の新しい行を検知する役割と、メッセージを送る役割を分けて考えられます。画面上でつながっていても、送る情報の中身まで自動的に正しく決まるとは限りません。編集部としては、接続先より先に、業務上必要な項目を洗い出すことを勧めます。
たとえば問い合わせの共有なら、受付日、相談内容、担当者が必要かもしれません。一方、通知先に個人情報をすべて載せる必要があるとは限りません。何を渡せば次の担当者が動けるかを決めると、構成も確認事項も絞れます。
できること（主な機能）
作業の開始条件と、その後の処理をつなぐ
シナリオの起点になるトリガーは、フォーム回答やメールの到着、表への行追加など、処理を始めるきっかけを表します。公式ガイドのGoogle Sheetsでは、Watch New Rowsを選んで新しい行を監視します。最初のアプリを追加
編集部の考え方として、開始条件は文章で書いてみると整理できます。「毎日何となく確認する」ではなく、「新しい申込行を見つけたら、担当チャンネルへ一度知らせる」と定義します。対象と結果が曖昧なままだと、動作していても目的を果たしたか判定できません。
通知が必要ない行や、記入途中の行をどう扱いたいかも考えます。最初の試作では条件を増やしすぎず、基本の一件が正しく流れるかを見ると、修正する場所を特定しやすくなります。
前の処理の情報を、次の処理へ渡す
Makeの「マッピング」は、あるモジュールの出力を、次のモジュールの入力に割り当てる操作です。公式のSlack例では、Google Sheetsの値をメッセージ本文の必要な位置へ配置します。データのマッピング
固定の文章と変わる値を分けて考えるのがポイントです。「新しい相談が届きました」は固定でも、名前や相談内容は行ごとに変わります。編集部なら、先に完成形の通知文を一つ書き、どこをデータで置き換えるか印を付けます。
姓と名の間の空白、空欄になった項目、長い文章が入った場合も確認します。内容が正しくても読みにくい通知では、その後に読む人の手間が残ります。転記ができたかだけでなく、受け取る人が理解できるかも試作の評価対象です。
入出力と処理回数を確かめる
各モジュールは、ひとまとまりのデータである「バンドル」を扱います。公式ヘルプでは、モジュール上の出力表示から入出力を確認でき、データ件数によって後続処理の回数が増えることを説明しています。Operationsの説明
これは、線を二つつないだら処理も必ず二回で済む、という意味ではありません。先頭から複数のデータが渡ると、次の処理がそれぞれを扱う場合があります。画面の見た目と利用量を分けて考える必要があります。
編集部としては、テスト時に「入力した件数」「届いた件数」「表示された処理回数」を並べて記録することを勧めます。一件の成功だけで判断せず、複数件を流した場合に何が変わるかを確認すると、運用時の見通しを持ちやすくなります。
動かす頻度を決める
シナリオのスケジュールには、一定間隔、毎日、曜日などの指定があります。初期設定は15分間隔で、設定できる最短間隔はプランに依存します。On demandは、手動実行やAPI呼び出しなどを待つ方式です。スケジュール設定
頻度は「早いほどよい」で決めず、業務がどれくらい待てるかで考えます。翌営業日に確認できればよい集計と、担当者への早い通知が必要な受付では、求める間隔が異なります。編集部なら、許容する待ち時間を先に決めてから設定を選びます。
料金プラン
Makeの公式記事では、Freeに月1,000クレジットがあり、Core、Pro、Teams、Enterpriseが有料の選択肢として紹介されています。確認時は料金ページ本文から現在の金額一覧を一貫して取得できなかったため、本稿では有料プランの金額を固定して掲載しません。公式のプラン紹介／料金ページ
確認する項目 | 見方 |
|---|---|
Freeの利用枠 | 月1,000クレジットの案内を確認 |
有料プランの料金 | 選ぶクレジット量と請求周期を料金画面で確認 |
実行の頻度 | 必要な間隔を選べるプランか確認 |
外部AIの費用 | Make側の利用量と外部サービス側の料金を分ける |
運用全体の費用 | 通常処理に加え、試験や修正時の利用も見込む |
クレジットは、すべての操作で常に同じ量になるわけではありません。公式ヘルプによると、一般的な非AIアプリでは一つのoperationが一クレジットに対応します。一方、AI機能にはトークンなどによって消費量が変わるものがあります。Creditsの説明
自分の接続で外部AIを使う場合、Makeの処理に対するクレジットとは別に、AI提供元への料金が発生する構成もあります。Makeの枠が足りていれば、すべての外部利用料も含まれる、と考えないようにしましょう。
編集部としては、最初の月から理想の本数を処理できる前提で選ぶより、小さな試作の消費量を見てから必要枠を考えることを勧めます。通常の入力件数だけでなく、月末にまとめて増えるケースや、設定を修正して試し直す作業も想定します。
一件の処理量から月間量を考えるときは、あくまで自分の構成で得た値を使います。他の人の「月にこれだけで足りた」という例は、アプリ、頻度、件数が異なる可能性があります。見積もりに使った条件を残しておくと、利用量が増えた理由も確認しやすくなります。
使い方の手順：表の情報を通知へつなぐ
以下は公式ガイドに沿った作成の流れです。実際に接続・実行する前に、扱ってよいデータと通知先を決めてください。編集部では本稿のために外部アプリへ接続したり、メッセージを送ったりしていません。
1. テスト用の表と、通知の完成形を準備する
まずは実際の顧客情報を使わず、意味の分かる架空データを数行用意する方法を勧めます。列名と通知の文章を合わせ、どの項目がどこへ入るかを決めます。「名前だけ」「本文が空欄」など、普段起こりそうな状態も試せるようにします。
完了条件も先に書きます。たとえば「新しい一行に対して通知が一件届き、必要な項目が正しく読める」と定めれば、設定の成否を確かめやすくなります。単に画面にエラーが出なかったことを完了条件にしないのがポイントです。
2. シナリオを作り、最初のモジュールを置く
公式手順では、Create a new scenarioから作成画面を開き、名前を付けます。中央の追加操作からGoogle Sheetsを探し、Watch New Rowsを選びます。モジュール追加の公式手順
名前には、入力元と目的が分かる言葉を入れると管理しやすくなります。編集部の例なら「テスト表の新規行を通知」といった名称です。試作と本番用を見分けられる名前にしておくと、あとで設定を見直す際の混同を避けやすくなります。
3. 接続するアカウントを確認する
Google Sheetsの例では、Create a connectionから接続を作り、Googleアカウントを選んでアクセスを許可します。接続は後のシナリオでも利用できます。アプリによって認証方法は異なります。接続の公式手順
仕事用と個人用のアカウントがある場合、対象の表を持つアカウントかを確かめましょう。認証できたことと、目的のデータへ接続できたことは分けて確認します。接続名にも用途を残すと、後から担当者が設定を見たときに判断しやすくなります。
4. Slackの通知内容へ値を割り当てる
公式ガイドでは、SlackのSend a MessageとGoogle Sheetsのモジュールを組み合わせ、通知先と本文を設定します。本文に前段の値を差し込み、モジュール設定とシナリオを保存します。マッピングの公式手順
テストの通知先には、内容を確認してよい場所を選びます。本文を作るときは、項目名と値を対応させます。相談内容と連絡先が入れ替わっていないか、未入力の値があっても読み取れるかを、完成形の通知文と比べて確認しましょう。
5. 一度実行し、両方のアプリで結果を見る
Run onceによる試験では、モジュールの出力表示を開いて処理内容を確認し、Slack側でも届いた内容を照合します。公式ガイドの「All」を選ぶ例は既存行も対象にするため、対象データの範囲を理解してから実行します。シナリオのテスト
テストであっても実際の通知が届く点を意識します。結果が違ったら、最初から全体を書き直すより、表の値、前段の出力、後段の入力、通知結果の順に確認すると、どこで食い違ったかを整理できます。
6. 頻度を決め、運用の担当を残す
内容と件数が合ったら、必要なスケジュールを設定します。公式ガイドでは設定を保存したうえでシナリオを有効にする流れです。実行予定の設定
編集部としては、稼働を始める前に、通知が止まったときの確認担当と、設定変更の連絡先を決めることを勧めます。自動化の仕組みを作った人だけが内容を理解していると、引き継ぎの際に困ります。入力元、通知先、頻度、想定件数を短いメモに残しておきましょう。
向いている人・向かない人
編集部の判断では、複数のアプリ間で同じ情報を転記していて、入力と結果を具体的に説明できる人に向く候補です。最初の構成を小さく作り、入出力を確かめながら改善したい人にも検討しやすいでしょう。
反対に、仕事の判断基準がまだ決まっておらず、何をすれば完了なのか説明できない段階では、先に業務の整理が必要です。動作や費用を一度も確認せずに任せたい場合も、導入後の運用と期待が合わない可能性があります。
自動化の価値は、つないだアプリの数だけでは決まりません。担当者の確認が早くなるのか、転記漏れを見つけやすくなるのかなど、実際の仕事に戻して評価することを勧めます。
似たツールとの違い
Zapierも、アプリをつなぐワークフローを提供し、公式ページでは条件分岐、データの整形、スケジュールなどを紹介しています。Makeでは、シナリオ上のモジュールとバンドルを確認しながら構成する流れを、本稿の入門例で見てきました。Zapierのワークフロー
どちらが簡単かは、使いたいアプリと処理内容によって判断しましょう。編集部なら、同じ「表の一行を通知する」題材で、接続方法、項目の指定、結果の確認、料金の数え方を比較します。接続可能なアプリの総数だけで結論を出さないことが大切です。
注意点
利用量は、シナリオ数やモジュール数だけでは判断できません。件数と実行頻度、AIを使う場合の消費方式を合わせて見ます。公式のCreditsとOperationsは異なる概念を説明しているため、古い記事の「操作回数」をそのまま現在の料金に当てはめないようにします。
また、表の列や通知先の運用が変わると、以前正しく作った設定も見直しが必要になることがあります。編集部の運用案として、元データの形式を変える際は、通知内容も一緒に確認する手順を決めておくとよいでしょう。
自動化した後も、受け手が使える情報になっているかを見ます。通知が多すぎて読まれない場合は、送信成功とは別に、業務としての設計を見直す余地があります。
まとめ
Makeは、アプリ間の処理をシナリオとして組み立て、入出力を確認しながら自動化を考えるサービスです。最初は、入力元と通知先が明確な小さな題材で試すと、モジュール、マッピング、クレジットの関係を理解しやすくなります。
接続して終わりにせず、必要な情報が届いたか、処理件数と利用量が想定どおりかを確認しましょう。その結果をもとに、対象業務やプランを広げるか判断することを勧めます。
