Make（旧Integromat）で業務を自動化する実例
McKinseyは、現在の技術で業務の少なくとも30%が自動化可能だと報告している^1^. Gartnerもハイパーオートメーションの潮流を指摘しており、関連市場が2022年に約6,000億米ドル規模へ達すると予測している^2^. 現場感覚としても、SaaSがAPIを開けば、結合のコストは一気に下がる。問題は、結合そのものより、その先の運用にあるという点だ。運用は痛みを伴う。権限、監査、リトライ、重複防止、可観測性。ここを越えられない自動化は、試験運用のまま終わる。
だからこそ、Make（旧Integromat）をあえてビジネスクリティカルな領域にどう適用するかを冷静に見直したい。ノーコードの表面だけで判断せず、アーキテクチャ、セキュリティ、リリース管理、SLO（サービス目標値）という観点で設計すると、単なる“つなぎ”が継続運用に耐える“仕組み”へ変わる。本稿では、CTOやエンジニアリングマネージャーが意思決定に使える具体性を重視し、実例と実装コードを提示しながら、Makeでの業務自動化をプロダクション品質に引き上げる手順を示す。
Makeを選ぶ理由と設計原則
Makeの強みは、HTTP・Webhook・ルーター・イテレーター・エラーハンドラー・データストアといったオーケストレーション（処理の流れを制御する）構成要素が一枚のシナリオに収まる点にある。Zapierに比べて分岐と並列化の表現力が高く、n8nのセルフホスト柔軟性には及ばないが、SaaSとしての運用負荷低減と拡張性のバランスがとれている。選定の鍵は、Makeを“システム・オブ・レコード（唯一の正とする台帳システム）”にはしないことだ。データの唯一の真実は業務のSaaSや自社DBに置き、Makeは自動化のオーケストレーターに徹する。この方針が、ロールバックや監査、パフォーマンスチューニングの自由度を大きく残す。
アーキテクチャ方針と重複防止
イベント駆動で考えると、エッジからの入力はWebhook、内部結合はHTTPモジュールで統一すると見通しが良くなる。重複防止はidempotency key（冪等性キー。同一リクエストの重複実行を防ぐための識別子）で担保するのが定石だ^3^. 送信側でペイロードの正規化とハッシュ化を行い、Make側ではデータストアにキーを保存して同一キーの再処理を避ける。観測については、相関ID（correlation ID。処理の追跡用ID）を全ホップで渡し、Makeからログ基盤へメトリクスを送る。これにより、失敗の局在化とMTTR（平均復旧時間）の短縮が得られる。
// 例1: Node.js から Make Webhook へ安全に送る（リトライ＋冪等性）
import crypto from 'crypto';
import fetch from 'node-fetch';
const WEBHOOK_URL = process.env.MAKE_WEBHOOK_URL; // 例: https://hook.eu1.make.com/xxxx
const SECRET = process.env.IDEMPOTENCY_SECRET;
function idempotencyKey(payload) {
const canonical = JSON.stringify(payload);
return crypto.createHmac('sha256', SECRET).update(canonical).digest('hex');
}
async function postWithRetry(payload, attempt = 0) {
const key = idempotencyKey(payload);
const headers = { 'Content-Type': 'application/json', 'X-Idempotency-Key': key };
const body = JSON.stringify({ ...payload, correlationId: key });
try {
const res = await fetch(WEBHOOK_URL, { method: 'POST', headers, body });
if (!res.ok) {
const text = await res.text();
throw new Error(`HTTP ${res.status} ${text}`);
}
return await res.json().catch(() => ({}));
} catch (err) {
if (attempt < 5) {
const backoff = Math.min(32000, 1000 * 2 ** attempt);
await new Promise(r => setTimeout(r, backoff));
return postWithRetry(payload, attempt + 1);
}
throw err;
}
}
// 使用例
postWithRetry({ event: 'invoice.created', amount: 19800, currency: 'JPY' })
.then(console.log)
.catch(e => console.error('failed:', e));
セキュリティと権限設計
Makeの接続情報はコネクションとして暗号化保存され、ワークスペースとロールで可視性を制御できる。実務では、発火側のWebhookは長いランダムURLだけに頼らず、送信時にHMAC署名（共有鍵でメッセージの改ざん検知を行う方式）を付与し、受信側で検証する^4^. Makeが外部APIにコールバックする場合も同様で、共有シークレットでヘッダ署名を付けることで、なりすましを抑止できる。ネットワーク層ではCloudflareやAPI GatewayでIP制限とレート制限を掛け、守りを多層にする。
// 例2: Cloudflare Workers で Make からのコールバック署名を検証
export default {
async fetch(request) {
const secret = (await CF_SECRET.get('WEBHOOK_SECRET')) || '';
const signature = request.headers.get('x-signature') || '';
const body = await request.text();
const enc = new TextEncoder();
const key = await crypto.subtle.importKey(
'raw', enc.encode(secret), { name: 'HMAC', hash: 'SHA-256' }, false, ['sign']
);
const raw = await crypto.subtle.sign('HMAC', key, enc.encode(body));
const expected = [...new Uint8Array(raw)].map(b => b.toString(16).padStart(2, '0')).join('');
if (expected !== signature) {
return new Response('invalid signature', { status: 401 });
}
// ここで安全に処理
return new Response('ok');
}
};
実例で学ぶ：開発・コーポレート・SREの自動化
まず開発プロセスの実例から。GitHubのリリースと同時に、変更履歴を集約して社内外ドキュメントへ反映し、Slackで要点を配信する。コミットメッセージやPRのラベルをMakeで集約し、NotionやConfluence APIへ整形投入する。これにより、週次で手作業だったリリースノート作成が、ビルド完了の数秒後に配信される運用へ移行できる可能性がある。重要なのは、相関IDでビルド番号を起点に全フローを追跡できる点だ。障害時もどこで落ちたかがすぐに見える。
// 例3: リリース後に Make Webhook を叩くビルドスクリプト
import fetch from 'node-fetch';
const url = process.env.MAKE_RELEASE_WEBHOOK_URL;
const payload = {
tag: process.env.GITHUB_REF_NAME,
repo: process.env.GITHUB_REPOSITORY,
changelog: process.env.CHANGELOG || '',
buildNumber: process.env.BUILD_NUMBER,
};
async function main() {
const res = await fetch(url, {
method: 'POST',
headers: { 'content-type': 'application/json' },
body: JSON.stringify(payload)
});
if (!res.ok) {
const text = await res.text();
throw new Error(`failed to notify Make: ${res.status} ${text}`);
}
console.log('notified');
}
main().catch(e => { console.error(e); process.exit(1); });
次にコーポレートの実例。請求書処理は定型作業の代表だ。Gmailに届くPDFをDriveへ保存し、MakeでOCRとパースを行い、ERPのAPIと付き合わせる。差異が既定の閾値を超えた場合のみSlackで承認フローに乗せ、承認が押されたら仕訳を確定させる。合計金額の丸めや通貨換算など微妙な仕様はサーバ側の小さな検証APIに寄せ、Makeはオーケストレーションに集中させるのが保守性の面で得だ。
# 例4: FastAPI で Make からの検証リクエストを受ける
from fastapi import FastAPI, Header, HTTPException
from pydantic import BaseModel
import hmac, hashlib, os
app = FastAPI()
SECRET = os.getenv("VERIFY_SECRET", "")
class Invoice(BaseModel):
number: str
amount: float
currency: str
items: list
@app.post("/validate")
async def validate(invoice: Invoice, x_signature: str = Header(default="")):
body = invoice.json().encode("utf-8")
expected = hmac.new(SECRET.encode("utf-8"), body, hashlib.sha256).hexdigest()
if expected != x_signature:
raise HTTPException(status_code=401, detail="invalid signature")
# ドメイン固有の検証
if invoice.amount <= 0:
return {"ok": False, "reason": "amount must be positive"}
return {"ok": True, "rounded": round(invoice.amount, 2)}
最後にSREの実例。アラートのノイズは意思決定の質を削ぐ。CloudWatchからのイベントをEventBridgeで集約し、Makeで時間帯やコンテキストに応じて抑制・グルーピングし、Slackに要約だけを流す。メッセージにはRunbookのリンクとサイレンスURLを付け、担当者が1タップで抑制できるようにする。過去の同一事象かどうかは、ハッシュキーを使って短時間キャッシュする設計が効く。こうした設計は、不要な通知の削減や一次対応の時短につながることがある。
# 例5: AWS Lambda で SNS から受け取り Make に転送（Python）
import json
import os
import time
import hashlib
import hmac
import requests
WEBHOOK = os.environ.get("MAKE_ALERT_WEBHOOK")
SECRET = os.environ.get("ALERT_SECRET", "")
def id_key(payload):
canonical = json.dumps(payload, sort_keys=True)
return hashlib.sha256(canonical.encode("utf-8")).hexdigest()
def sign(body: str):
return hmac.new(SECRET.encode("utf-8"), body.encode("utf-8"), hashlib.sha256).hexdigest()
def handler(event, context):
record = event["Records"][0]
msg = json.loads(record["Sns"]["Message"]) if "Sns" in record else record
payload = {"event": "cloudwatch", "data": msg, "ts": int(time.time())}
body = json.dumps(payload)
headers = {"content-type": "application/json", "x-idempotency-key": id_key(payload), "x-signature": sign(body)}
for attempt in range(5):
try:
res = requests.post(WEBHOOK, data=body, headers=headers, timeout=5)
if res.status_code < 300:
return {"status": "ok"}
raise Exception(f"HTTP {res.status_code}: {res.text}")
except Exception as e:
time.sleep(min(2 ** attempt, 16))
return {"status": "failed"}
運用で効く工夫とコスト効果
運用の勝ち筋は、テスト、リリース、可観測性をセットで回すことに尽きる。テストはシナリオ単体のモック実行と、Webhooksへ実際に叩き込むコントラクトテストを併用する。リリースはシナリオを複製してステージング用の接続に切り替え、ブループリントのJSONをリポジトリで管理しながら、変更差分をレビューする。可観測性は、Makeの実行ログから成功・失敗・再試行・レイテンシを抽出し、外部にメトリクスを送ってSLOを立てる。成功率を指標にするなら、再試行後の成功を含めるかどうかを明確にし、ページャの条件を決めておくと、夜間の不要な起床が減る。
// 例6: Jest による Webhook コントラクトテスト（Node）
import fetch from 'node-fetch';
describe('make webhook contract', () => {
const url = process.env.MAKE_TEST_WEBHOOK_URL;
it('responds within 1500ms and echoes correlationId', async () => {
const payload = { event: 'test', value: 1 };
const started = Date.now();
const res = await fetch(url, {
method: 'POST',
headers: { 'content-type': 'application/json' },
body: JSON.stringify(payload)
});
const elapsed = Date.now() - started;
expect(res.ok).toBe(true);
expect(elapsed).toBeLessThan(1500);
const json = await res.json();
expect(json.correlationId).toBeDefined();
});
});
コスト効果は、実データに基づく検証が前提だ。参考までに、一般的なバックオフィスや開発運用の定型タスクに対する試算の考え方を示す。例えば請求書照合フローで、担当者の入力・照合作業が40分/日から10分/日に減るケースを想定すると、月間では約10〜12時間の削減に相当する。開発プロセスでは、リリースノートの集約と配信が30分/リリースから数分に短縮されると、週2回のリリースで月約4時間が浮く。SREのアラート抑制では、設計次第で夜間の不要アラートが大幅に減ることがあり、オンコール負荷の低減に寄与しうる。SaaS連携のレイテンシは一般に数百ms〜数秒台が目安で、レート制限やバッチ化を適切に設計すると、p95が1〜2秒台に収まることもある。人件費を時給6,000円と仮定した場合、上記のような削減時間が積み上がれば月あたり9万〜12万円程度の効果が期待できる試算になる。一方で、シナリオの構築・保守に月3〜5時間を投じるといったコストも発生するため、対象業務と環境に応じて費用対効果を都度評価したい。
ガバナンスと監査に耐えるために
変更管理はブループリントのエクスポートでGit管理し、レビューと承認のプロセスに乗せる。シークレットはMakeのコネクションに留め、シナリオ内にハードコードしない。承認が必要な業務フローでは、Slackのボタン押下を唯一の切り替え点にせず、最終的な確定処理をサーバ側のAPIに逃がし、監査ログと相関IDで両方から辿れるようにする。インシデント対応では、Makeの実行IDから該当イベントの全トレースを引き出し、外部ログ基盤で1クリック検索できる導線を作ると、手当ての速さが段違いになる。こうしたガバナンスやチェンジマネジメントの整備は、ハイパーオートメーションを成功させる前提条件とされる^5^。
実装の落とし穴と回避策
外部APIのレート制限は静かに失敗を生む。バーストしやすいフローはキューイングと間引きを意識し、Makeのルーターで高優先の支払系と低優先の通知系を分けておく。冪等性を怠ると、ネットワークの一時失敗をリトライしただけで重複登録が発生する^3^. 処理結果の最終判定はシステム・オブ・レコード側に寄せ、Makeの判断で確定させない。タイムゾーンや通貨丸めのような“地味な破壊要因”は境界に関数を置いて厳密に扱い、フローの中核を共通化する。最後に、人が介在する承認フローは、タイムアウトを決めて遷移を含めて自動化する。放置状態を計測できるようにしておくと、のちの改善が早い。
現場導入の初期は、シナリオの数学的な複雑さが膨らみがちだ。分岐が多すぎると、可視化の恩恵が減る。ルールを共通部品に寄せ、Makeから小さな検証APIを呼ぶ構成に切り替えると、図の枝葉が消えて、レビュー可能性と保守性が一段上がる。実装言語はチームの得意を使えばよい。NodeでもPythonでも、契約はHTTPだ。以下のGASは、スプレッドシートの変更をMakeへ通知する小さな例だ。SaaSと台帳が混在する現場でも、入力の起点を揃えるだけで整流化が進む。
// 例7: Google Apps Script でシート更新を Make に通知
function onEdit(e) {
const url = PropertiesService.getScriptProperties().getProperty('MAKE_SHEET_WEBHOOK');
const payload = {
sheet: e.source.getActiveSheet().getName(),
range: e.range.getA1Notation(),
value: e.value,
ts: Date.now()
};
const options = {
method: 'post',
contentType: 'application/json',
payload: JSON.stringify(payload)
};
UrlFetchApp.fetch(url, options);
}
まとめ
自動化の価値は、作業を減らすことにとどまらない。例外を例外として扱える設計を持ち込み、誰が見ても追える可観測性をセットにすると、チームの意思決定そのものが変わる。Makeは、その入口として十分に戦える道具だ。表面のノーコードに安住せず、アーキテクチャとセキュリティと運用の目線で組み込めば、業務は静かに、しかし確実に軽くなる。
最初の一歩は小さく、観測は大きく。今日の単調な転記や通知をひとつ選び、Webhookと冪等性キーを備えたミニシナリオから始めてほしい。相関IDを通し、成功率とレイテンシを必ず記録する。1週間後、数字で手応えが見えたら、次のボトルネックに手を伸ばす。そうした連鎖が、チームの時間を取り戻すいちばんの近道になるはずだ。
参考文献
-
McKinsey Global Institute. How many of your daily tasks could be automated? https://www.mckinsey.com/mgi/overview/in-the-news/how-many-of-your-daily-tasks-could-be-automated
-
Gartner. Gartner Forecasts Worldwide Hyperautomation-Enabling Software Market to Reach Nearly $600 Billion by 2022. https://www.gartner.com/en/newsroom/press-releases/2021-04-28-gartner-forecasts-worldwide-hyperautomation-enabling-software-market-to-reach-nearly-600-billion-by-2022
-
Stripe Docs. Idempotent requests. https://docs.stripe.com/api/idempotent_requests
-
Snyk. Verifying webhook signatures. https://snyk.io/blog/verifying-webhook-signatures/
-
KPMG. Hyperautomation: Taking automation to the next level. https://kpmg.com/nl/en/home/insights/2024/09/hyperautomation.html