Makeは、フォーム、スプレッドシート、メール、通知、AIツールなどをつないで、手作業の流れを自動化するノーコード系のワークフロー作成ツールです。ただし初心者がいきなり複雑な自動化を作ると、どこで止まったのか、どの情報を外部サービスへ渡したのか、料金上限をどれだけ消費したのかが見えにくくなります。この記事では、Makeの使い方を「小さなシナリオを1本作る」前提で整理します。
先に結論です。最初に作るなら、問い合わせフォームを受け取り、Googleスプレッドシートに記録し、Slackやメールで人に通知する程度の小さな流れが安全です。AI連携を入れる場合も、最初は「要約」「返信案」「記事メモの下書き」までに止め、送信・公開・顧客対応は人が確認する形にしてください。
2026年7月2日にMake公式情報を確認した範囲では、Makeの無料プランは時間制限なしで試せ、月1,000クレジット、3,000以上のアプリ、ルーターとフィルター、15分の最短実行間隔が示されています。料金、無料枠、機能、クレジット条件は変更される場合があるため、実際に導入する前に必ず公式ページで最新情報を確認してください。
まず全体像:Makeはシナリオで作業をつなぐツール

Makeでは、自動化のまとまりを「シナリオ」として作ります。シナリオの中には、最初のきっかけになるトリガーと、その後に実行する処理を並べます。たとえば、フォームが送信されたら、回答内容をスプレッドシートへ記録し、担当者へ通知する、という流れです。
初心者が最初に理解したいのは、Makeが魔法のAIツールではなく「決めた順番で処理を動かす道具」だという点です。AI要約やAI下書きも組み込めますが、入力、処理、出力、確認者を決めなければ、便利な自動化ではなく、責任の所在があいまいな処理になります。
| Makeの基本要素 | 初心者向けの意味 | 最初に決めること |
|---|---|---|
| シナリオ | 1本の自動化の設計図です。 | どの作業を、どこからどこまで自動化するか。 |
| トリガー | 自動化を始めるきっかけです。 | フォーム送信、行追加、メール受信など、開始条件を1つに絞る。 |
| モジュール | アプリごとの処理部品です。 | 記録、通知、要約、下書きなど、何を実行するか。 |
| ルーター / フィルター | 条件によって処理を分ける仕組みです。 | 問い合わせ種別、金額、重要度など、分岐条件を必要最小限にする。 |
| 実行履歴 / ログ | どこまで動いたかを確認する記録です。 | 失敗時に誰が見て、何を手動で戻すか。 |
この考え方は、AI Study LogのWordPress運用にもそのまま当てはまります。記事制作では、キーワード台帳、下書き、画像、メタ情報、公開、公開後チェックが順番につながります。どこかを自動化する場合も、いきなり「記事公開まで全部自動」にするのではなく、まずは台帳更新、確認リマインド、下書きメモ作成など、失敗しても人が戻せる部分から始めるほうが安全です。
| 自動化してよい範囲 | Makeで任せること | 人が残す判断 |
|---|---|---|
| 台帳更新 | フォームや表の入力を決まった列へ記録する。 | 内容が正しいか、公開してよい情報かを確認する。 |
| 確認リマインド | 期限やステータスを見て担当者へ通知する。 | 通知を受けた後の優先順位と対応内容を決める。 |
| 下書きメモ | 素材を要約し、返信案や記事メモの形に整える。 | 事実確認、表現、送信・公開の可否を判断する。 |
MakeとZapierの違いは、最初から気にしすぎなくてよい
Makeを調べ始めると、Zapierとの比較も気になります。Zapierは9,000以上のアプリ連携を公式に示しており、Makeは3,000以上のアプリ連携と視覚的なワークフロー作成を打ち出しています。どちらが絶対に上というより、直線的に早く作りたいならZapier、条件分岐や途中データを見ながら組みたいならMakeが候補になりやすい、という整理で十分です。
この記事ではMakeの使い方に絞ります。ZapierとMakeの違いを詳しく見たい場合は、公開済みのZapierとMakeの違い、複数ツールから選びたい場合はAI自動化ツール比較を先に読むと、この記事の位置づけが分かりやすくなります。
30分テストで見る3つのポイント
Makeを本格的に学ぶ前に、30分だけ試すなら「作れるか」より「説明できるか」を見ます。自動化は一度動くと便利ですが、担当者が変わったとき、入力項目が増えたとき、外部サービスの仕様が変わったときに、仕組みを説明できないと保守できません。
| 30分テストで記録すること | メモ例 | 次に直す判断 |
|---|---|---|
| 入力項目 | 名前、メール、問い合わせ種別、自由記述だけを渡した。 | 不要な項目を減らし、個人情報を渡しすぎていないかを見る。 |
| 実行結果 | テスト行が1行作られ、担当者へ1通だけ通知された。 | 重複実行や空欄があれば、条件やフィルターを先に直す。 |
| 戻し方 | テスト行を削除し、通知スレッドにテスト完了と残した。 | 戻し方を説明できなければ、本番データには接続しない。 |
30分テストの目的は、完成した自動化を作ることではありません。入力、実行結果、戻し方を短く残し、次に広げてよい範囲と、まだ広げない範囲を分けることです。
| 30分後の状態 | 次の一手 | 理由 |
|---|---|---|
| 入力、途中データ、戻し方を説明できる | テスト回数を少し増やす | 原因追跡の準備ができているため。 |
| 動いたが、どこで何が渡ったか説明できない | モジュールを減らして作り直す | 本番化すると失敗時に直せないため。 |
| 通知や記録が重複する | 条件、対象データ、実行間隔を見直す | 便利さより誤通知を減らすほうが先だからです。 |
| 30分テストの確認軸 | 見ること | 初心者向けの基準 |
|---|---|---|
| 入力を説明できるか | どのフォーム、表、メール、ファイルをきっかけに動くのか。 | 入口を1つに絞り、1文で説明できる。 |
| 途中データを追えるか | 名前、メール、問い合わせ種別、メモなどが次の処理へどう渡るか。 | 項目名が分からないままAIへ渡していない。 |
| 失敗時に止められるか | 通知先、ログ、手動修正の手順が決まっているか。 | 失敗したときに誰が気づき、何を戻すかを説明できる。 |
この3点を説明できれば、Makeの細かい操作をまだ完璧に覚えていなくても、次に学ぶべき場所が見えます。逆に、シナリオは動いたのに入力項目や戻し方を説明できない場合は、便利さより先に運用リスクを直す段階です。
最初の1本はフォーム、スプレッドシート、通知から作る

Make初心者が最初に作るシナリオは、派手なAI連携よりも、入力を受け取り、記録し、人に知らせる流れがおすすめです。理由は単純で、結果が目で確認しやすく、失敗しても手動で戻しやすいからです。AIを使う前に、まず「データが正しく渡るか」「通知を見落とさないか」「ログを見て原因を追えるか」を確認します。
| 最初の部品 | 役割 | 合格ライン |
|---|---|---|
| 入力 | フォームやテスト用の行から、少量のデータだけを渡す。 | どの項目が次へ渡るかを画面で説明できる。 |
| 記録 | スプレッドシートなど、人が読める場所へ残す。 | 重複、空欄、テストデータを見分けられる。 |
| 通知 | 担当者が確認するための短いメッセージを送る。 | 通知を受けた人が次の作業を判断できる。 |
- Googleフォームや問い合わせフォームで、テスト用の入力を作る。
- スプレッドシートに、受信日時、名前、問い合わせ種別、メモを記録する。
- Slack、メール、または別の通知先へ、担当者が読める形で知らせる。
- 担当者が内容を見て、返信、分類、次の作業を判断する。
- テスト用のデータを削除または明示し、本番データと混ざらないようにする。
この流れなら、途中でAIが間違った文章を作るリスクがありません。個人情報や顧客情報を扱う場合も、最初に外部サービスへ渡す項目を把握しやすくなります。社内規程、契約、学校や研究機関のルールがある場合は、Makeに接続する前に「どのサービスへ何を送るか」を必ず確認してください。
最初のシナリオを作る前の準備
実際にMakeの画面を開く前に、ノートやスプレッドシートで次の5点を決めておくと迷いにくくなります。Makeの操作方法を覚えるより先に、業務の境界を決める作業です。
| 準備項目 | 書いておく内容 | 初心者が避けたい失敗 |
|---|---|---|
| 目的 | 何を減らしたいのか。転記、通知、下書き、確認漏れなど。 | 「AIで便利にする」だけで始め、成果が測れない。 |
| 入力 | どのフォーム、メール、表、ファイルから始まるか。 | 複数の入口を同時に扱い、原因追跡ができなくなる。 |
| 出力 | どこへ保存、通知、下書き作成するか。 | 通知先が多すぎて、誰が確認するか分からない。 |
| 確認者 | 人が見るタイミングと、OK/NGの判断基準。 | 自動送信まで進め、誤送信に気づけない。 |
| 戻し方 | 失敗したときに削除、修正、再実行する手順。 | 自動化が止まった後、手動で復旧できない。 |
この準備表は、Makeの画面操作を減らすためではなく、後で自分やチームがシナリオを説明できる状態にするためのものです。特に本番データを扱う前は、目的、入力、出力、確認者、戻し方の5点を1行ずつでも残してください。
AI Study Logの運用メモからの判断軸です。WordPress記事制作でも、記事台帳、画像、本文、メタ情報、公開後チェックを一気に自動化すると、どこで品質を確認したのかが見えにくくなります。小さな自動化ほど、ログと人の確認を残しやすく、後から改善しやすいです。
初心者が最初に試しやすい8つの使い道
Makeは「何でも自動化できそう」に見えるため、最初の題材選びで迷いやすいです。次のように、作業が小さく、結果が見えるものから試すと、無料枠やクレジット消費、権限設定の感覚もつかみやすくなります。
| 使い道 | 最初に試すこと | 人が確認すること |
|---|---|---|
| 問い合わせ受付 | フォーム送信をスプレッドシートに記録し、担当者へ通知する。 | 問い合わせ種別、個人情報の扱い、返信担当者。 |
| メール下書き | 受信内容から返信案を作り、下書きとして保存する。 | 事実誤認、失礼な表現、送信先、添付ファイル。 |
| 会議メモ整理 | 議事録メモをタスク、決定事項、保留事項に分ける。 | 決定事項の抜け、責任者、期限、社外秘情報。 |
| PDF確認依頼 | 共有フォルダに入ったPDFを検知し、確認依頼を送る。 | ファイルの権限、機密性、要約可否。 |
| ブログ運用 | 公開予定日、下書き状態、画像準備状況を台帳に集める。 | 記事品質、公式情報の確認日、画像とメタの整合。 |
| 営業メモ | フォームやCRMの新規行を通知し、次のタスクを作る。 | 顧客情報の扱い、重複登録、優先度。 |
| 社内FAQ | 質問フォームを記録し、既存FAQ候補を担当者へ返す。 | 回答の正確性、規程変更、公開範囲。 |
| 請求・経費チェック | 受信メールや表の更新を検知し、確認待ちリストへ入れる。 | 金額、日付、税区分、承認者。 |
この8例に共通するのは、最終判断を人に残している点です。Makeは作業の流れを整える道具であり、判断責任を消す道具ではありません。特にメール送信、請求、契約、採用、医療、教育評価、顧客対応のような領域では、AI下書きや自動通知を使っても、最後の確認者を明確にしておく必要があります。
1本目のシナリオ名とメモの残し方
初心者ほど、シナリオ名を軽く扱いがちです。しかし、後から見る人にとっては、名前とメモが最初の運用ドキュメントになります。たとえば「フォーム通知」だけでは、何のフォームか、誰に通知するか、本番なのかテストなのかが分かりません。
| 残す項目 | 例 | 理由 |
|---|---|---|
| シナリオ名 | test_contact_form_to_sheet_notify_review | テスト、本番、入口、出力、確認待ちが分かる。 |
| 目的メモ | 問い合わせを記録し、担当者が返信前に確認する。 | 自動化の範囲を広げすぎないため。 |
| 接続アプリ | フォーム、Google Sheets、Slack、必要ならAI下書き。 | 権限確認とトラブル調査をしやすくするため。 |
| 手動戻し | テスト行を削除し、誤通知はスレッドで訂正する。 | 失敗時に止まらず復旧するため。 |
この程度のメモでも、数週間後に見返したときの分かりやすさが変わります。自動化は作った直後より、直すときに差が出ます。1本目から「後で直せる名前」を付けると、Makeの学習が作業の使い捨てで終わりにくくなります。
AI連携は下書きまで。公開・送信は人が止める

MakeはOpenAIやAnthropic ClaudeなどのAI系アプリとも連携できます。公式ヘルプセンターにもOpenAI、Anthropic Claude、Google Sheets、Gmailなどの人気アプリが表示されています。ただし初心者が最初からAIに送信文や公開文を自動送信させるのはおすすめしません。AIの出力は便利ですが、入力情報の不足、文脈の誤解、古い情報、過剰な断定が混ざる可能性があるためです。
AI連携を入れるなら、まずは「人が読むための下書き」に限定します。問い合わせ内容を要約する、返信の候補を3つ作る、会議メモをタスク候補に分ける、ブログの見出し案を作る、といった用途です。送信、公開、請求、権限変更、顧客への回答は、初期段階では自動実行しないほうが安全です。
| AIに任せる範囲 | Makeで作る出力 | 止める場所 |
|---|---|---|
| 要約 | 問い合わせや会議メモの要点を短くまとめる。 | 担当者が原文と照合してから次へ進む。 |
| 分類 | 問い合わせ種別、緊急度、担当候補を付ける。 | 最終分類や優先度は人が直せる状態にする。 |
| 下書き | 返信案、記事メモ、タスク候補を作る。 | 送信、公開、請求、契約処理には直結させない。 |
AI連携は、要約、分類、下書きのどれか1つに絞って試すと、どこで人の確認を入れるべきかが見えます。最初から3つを同時に入れるより、1つずつログを見てから広げるほうが安全です。
個人情報と機密情報の扱いは、ツール選定より先に確認します。Make公式のセキュリティページでは、SOC 2 Type II、SOC 3、GDPRへの言及、データ保存や暗号化、ログデータの既定保存期間などが説明されています。ただし、あなたの会社や学校が外部AI・外部SaaSへの入力を許可しているかは別問題です。規程、契約、顧客同意、社内ルールを確認してから接続してください。
AI連携で最初に作るなら、この3段階で止める
- 要約だけ: フォームやメールの内容を短くまとめ、スプレッドシートや通知に添える。
- 分類だけ: 問い合わせ種別、緊急度、担当候補を付ける。ただし最終分類は人が直せるようにする。
- 下書きだけ: 返信案、記事メモ、タスク分解を作る。自動送信や自動公開にはつなげない。
この3段階なら、AIが間違えても人が気づきやすくなります。Makeのシナリオ名にも「draft」「review」「manual check」など、確認待ちであることが分かる言葉を入れておくと、後から見た人も本番自動化と混同しにくくなります。
AI下書き用の指示例
「以下の問い合わせ内容を、担当者が確認するために要約してください。未確認情報は断定せず、返信文は送信せず、確認すべき点を箇条書きにしてください。」
このように、AIへ渡す指示にも「人が確認する」「送信しない」「未確認情報を断定しない」を入れておくと、下書きの性格がはっきりします。Makeの役割は、この指示を一定の形式で渡し、結果を担当者が見られる場所へ置くことです。
AIへ渡さないほうがよい情報
最初の自動化では、AIに渡す情報を減らすほど安全です。問い合わせ本文を丸ごと渡す前に、分類に必要な項目だけで足りないかを考えます。氏名、住所、電話番号、契約番号、社内評価、請求情報などは、AI処理に本当に必要かを個別に確認します。
特に、顧客情報、医療・教育・採用・金融・契約に近い情報、未公開の事業計画、社外秘資料は、ツールのセキュリティページだけで判断しません。Make公式がセキュリティやデータ保護の説明をしていても、あなたの組織がその使い方を許可しているとは限らないためです。
よくある失敗と修正方法
| 失敗 | 起きる理由 | 修正方法 |
|---|---|---|
| テストデータと本番データが混ざる | テスト用のフォーム、表、通知先を分けていない。 | テスト専用シートと通知先を作り、本番前に削除手順を確認する。 |
| 通知が多すぎて見られない | すべての更新を通知している。 | 重要度や種別でフィルターし、人が見るべきものだけ通知する。 |
| AI下書きが断定しすぎる | プロンプトに確認条件や禁止表現を入れていない。 | 「未確認情報は断定しない」「人が確認する前提」と明記する。 |
| クレジットを想定より使う | 短い間隔で何度も実行する設計になっている。 | 実行間隔、対象行、テスト回数を減らし、ログで消費を確認する。 |
| 退職者や担当変更で止まる | 個人アカウントや個人通知先に依存している。 | チーム用の接続、共有フォルダ、運用メモを整える。 |
失敗例は「Makeが悪い」という話ではなく、設計を大きくしすぎたときに起きやすい運用事故です。最初の1本は、見える入力、見える出力、見える確認者に絞ることで、失敗時の修正も小さくできます。
無料で試す前に確認する料金・権限・保守のチェック

Makeは無料で試せるため、初心者でも始めやすい一方で、仕事で使うなら確認すべき点があります。特に料金単位、接続権限、ログ、個人情報、手動復旧は、便利さより先に見ておきたい項目です。
| 確認項目 | 見る場所・考え方 | 判断の目安 |
|---|---|---|
| クレジット | Make公式料金ページで、無料枠、月間クレジット、実行間隔を確認する。 | 最初は少数のテストデータだけで動かし、消費感をつかむ。 |
| 権限 | 接続するGoogle、Slack、メール、AIサービスの権限範囲を見る。 | 必要以上に広い権限を求める設計は避ける。 |
| ログ | 実行履歴、失敗時の表示、エラー通知を確認する。 | 失敗箇所を説明できないシナリオは、本番投入しない。 |
| 個人情報 | フォーム、メール、PDF、顧客データに個人情報が含まれるか確認する。 | 不要な項目は渡さない。必要なら匿名化や項目削減を先に行う。 |
| 手動戻し | 誤記録、誤通知、重複登録が起きたときの戻し方を書く。 | 人が数分で戻せる範囲から自動化する。 |
有料化を考えるのは、無料枠で小さなシナリオが安定し、担当者がログを見て説明でき、手動戻しの手順も分かった後で十分です。Make公式料金ページでは、無料プランのほか、Core、Pro、Teams、Enterpriseなどのプランと、クレジット単位の説明が示されています。月額だけで判断せず、自分のシナリオが何回実行され、どの処理がどれだけクレジットを使うのかを確認してください。
無料で足りる人、有料化を検討する人
| 状況 | 判断 | 理由 |
|---|---|---|
| 月に数回のテスト、個人の学習、少量の通知 | 無料で試す範囲からでよい | まずは操作感、ログ、権限、クレジット消費を確認する段階だからです。 |
| 毎日動く業務通知、複数アプリ連携、チーム共有 | 有料化を検討 | 実行回数、保守、共有、権限管理の重要度が上がるためです。 |
| 顧客情報、請求、契約、公開文を扱う | 料金より先に規程確認 | 外部サービス接続、AI入力、ログ保存、責任範囲の確認が必要です。 |
| 担当者がログを読めない、戻し方がない | 本番導入はまだ早い | 自動化の失敗に気づけず、手作業より危険になる可能性があります。 |
CTA前の判断です。Makeを試す価値があるのは、1本目のシナリオの目的、入力、出力、確認者、戻し方を説明できる場合です。まだ説明できない場合は、公式料金ページへ進む前に、この記事の準備表へ戻って自動化範囲を小さくしてください。
まずは公式条件を確認してから、小さなシナリオを1本だけ作ってください。この記事の流れで試すなら、無料枠、クレジット、接続アプリ、実行間隔を公式ページで確認し、フォームから記録・通知までのシナリオをテスト環境で作るのが安全です。
Make / Zapierのアフィリエイト承認はこの記事作成時点では未確認のため、収益化用リダイレクトではなく公式ページへの案内にしています。
Makeを試した後の次の読み方
Makeで最初のシナリオが動いたら、次は「自分にはMakeが合うのか」「Zapierのほうがよいのか」「AI自動化ツール全体では何を選ぶべきか」を確認します。Makeだけを深掘りする前に、目的別に比較すると無駄な有料化を避けやすくなります。
- ZapierとMakeの違いを比べたい人: ZapierとMakeの違い|AI自動化でどちらを選ぶべきか比較
- AI自動化ツール全体から選びたい人: AI自動化ツール比較|Zapier・Make・ChatGPT連携の始め方
- 予定やタスク管理の自動化に寄せたい人: AIスケジュール管理ツールおすすめ比較
- ブログ運用でAIを使いたい人: AIブログの始め方
FAQ
Q. Makeは初心者でも使えますか?
はい。ただし、最初から複雑なAI連携や自動送信を作るより、フォーム、記録、通知、人の確認だけの小さなシナリオから始めるほうが安全です。
Q. Makeの無料プランだけで十分ですか?
学習、少量テスト、月に数回の小さな自動化なら、まず無料枠で動かし方とクレジット消費を確認するのがよいです。毎日動く業務やチーム運用では、有料化前に公式料金と権限管理を確認してください。
Q. AI連携は何から試すべきですか?
要約、分類、返信案、記事メモなど、下書きにとどまる処理から始めます。顧客への送信、公開、請求、契約、評価に関わる処理は、人の確認を必ず残してください。
Q. ZapierとMakeのどちらを先に試すべきですか?
直線的な通知や転記をすぐ作りたいならZapier、条件分岐や途中データを見ながら組みたいならMakeが候補になりやすいです。詳しい比較は、AI Study LogのZapierとMake比較記事で整理しています。
