Makeの使い方入門|AI自動化を小さく始める基本ワークフロー

※本記事にはアフィリエイトリンクを含む場合があります。
Makeの使い方入門を示すAI自動化ワークフローのサムネイル

Makeは、フォーム、スプレッドシート、メール、通知、AIツールなどをつないで、手作業の流れを自動化するノーコード系のワークフロー作成ツールです。ただし初心者がいきなり複雑な自動化を作ると、どこで止まったのか、どの情報を外部サービスへ渡したのか、料金上限をどれだけ消費したのかが見えにくくなります。この記事では、Makeの使い方を「小さなシナリオを1本作る」前提で整理します。

先に結論です。最初に作るなら、問い合わせフォームを受け取り、Googleスプレッドシートに記録し、Slackやメールで人に通知する程度の小さな流れが安全です。AI連携を入れる場合も、最初は「要約」「返信案」「記事メモの下書き」までに止め、送信・公開・顧客対応は人が確認する形にしてください。

2026年7月2日にMake公式情報を確認した範囲では、Makeの無料プランは時間制限なしで試せ、月1,000クレジット、3,000以上のアプリ、ルーターとフィルター、15分の最短実行間隔が示されています。料金、無料枠、機能、クレジット条件は変更される場合があるため、実際に導入する前に必ず公式ページで最新情報を確認してください。

目次

まず全体像:Makeはシナリオで作業をつなぐツール

Makeのシナリオ、トリガー、処理、テスト、公開の流れを示す図
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自動化を示す図
最初はフォーム、記録、通知、人の確認だけに絞ると、失敗箇所を追いやすくなります。

Make初心者が最初に作るシナリオは、派手なAI連携よりも、入力を受け取り、記録し、人に知らせる流れがおすすめです。理由は単純で、結果が目で確認しやすく、失敗しても手動で戻しやすいからです。AIを使う前に、まず「データが正しく渡るか」「通知を見落とさないか」「ログを見て原因を追えるか」を確認します。

最初の部品 役割 合格ライン
入力 フォームやテスト用の行から、少量のデータだけを渡す。 どの項目が次へ渡るかを画面で説明できる。
記録 スプレッドシートなど、人が読める場所へ残す。 重複、空欄、テストデータを見分けられる。
通知 担当者が確認するための短いメッセージを送る。 通知を受けた人が次の作業を判断できる。
  1. Googleフォームや問い合わせフォームで、テスト用の入力を作る。
  2. スプレッドシートに、受信日時、名前、問い合わせ種別、メモを記録する。
  3. Slack、メール、または別の通知先へ、担当者が読める形で知らせる。
  4. 担当者が内容を見て、返信、分類、次の作業を判断する。
  5. テスト用のデータを削除または明示し、本番データと混ざらないようにする。

この流れなら、途中で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連携は下書きまで。公開・送信は人が止める

素材、AI下書き、確認、送信前停止という人が止めるAI連携を示す図
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段階で止める

  1. 要約だけ: フォームやメールの内容を短くまとめ、スプレッドシートや通知に添える。
  2. 分類だけ: 問い合わせ種別、緊急度、担当候補を付ける。ただし最終分類は人が直せるようにする。
  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公式料金ページで無料枠を確認する

Make / Zapierのアフィリエイト承認はこの記事作成時点では未確認のため、収益化用リダイレクトではなく公式ページへの案内にしています。

Makeを試した後の次の読み方

Makeで最初のシナリオが動いたら、次は「自分にはMakeが合うのか」「Zapierのほうがよいのか」「AI自動化ツール全体では何を選ぶべきか」を確認します。Makeだけを深掘りする前に、目的別に比較すると無駄な有料化を避けやすくなります。

FAQ

Q. Makeは初心者でも使えますか?
はい。ただし、最初から複雑なAI連携や自動送信を作るより、フォーム、記録、通知、人の確認だけの小さなシナリオから始めるほうが安全です。

Q. Makeの無料プランだけで十分ですか?
学習、少量テスト、月に数回の小さな自動化なら、まず無料枠で動かし方とクレジット消費を確認するのがよいです。毎日動く業務やチーム運用では、有料化前に公式料金と権限管理を確認してください。

Q. AI連携は何から試すべきですか?
要約、分類、返信案、記事メモなど、下書きにとどまる処理から始めます。顧客への送信、公開、請求、契約、評価に関わる処理は、人の確認を必ず残してください。

Q. ZapierとMakeのどちらを先に試すべきですか?
直線的な通知や転記をすぐ作りたいならZapier、条件分岐や途中データを見ながら組みたいならMakeが候補になりやすいです。詳しい比較は、AI Study LogのZapierとMake比較記事で整理しています。

目次