IFTTT連携で業務を自動化する実例

**国内のホワイトカラーの業務のうち約30％は、現在の技術で自動化可能と推定されています。**¹ 国際的な分析でも似た傾向が示され、² 定型的な情報転記や通知、記録作業がボトルネックになっている現実は変わりません。専用のワークフロー基盤を整備する前に、軽量な自動化レイヤーを先に当てて効果を測る判断は、意思決定の速度を上げます。IFTTTはコンシューマ寄りの印象が強い一方で、Webhookによる即時トリガー（外部イベントを受けて即座に実行される仕組み）⁴とSlackやGoogle Workspaceとの連携³⁹により、日々の運用を下支えする補助線として十分に機能します。特に監視・通知・ログ記録の3領域では、規模が小さくても効果が見えやすく、ケースによっては初週から週3〜10時間規模の時間削減が見込まれることもあり（RPAの一般事例でも近い削減幅が報告されています）⁵、導入の心理的コストに対して費用対効果を取りやすいのが特徴です。

IFTTTで何を自動化するか：価値と設計の前提

IFTTTの強みは、既存SaaSのイベントや状態変化をトリガーに、ノーコードで他サービスを呼び出せる点にあります。さらにWebhookの「Receive a web request」と「Make a web request」を活用すると、社内システムと外部SaaSの間を薄い接着剤のようにつなげられます。⁶ ビジネス的には、着手コストが低いスモールスタートで運用回収までのリードタイムを短縮できることが最大の価値です。技術的には、IFTTTがポーリング（一定間隔で状態を確認する方式）型のトリガーを多く持つ一方、Webhookは事実上リアルタイムで動くため、通知と記録のワークロードに向きます。⁴ 可用性の観点では、IFTTTはミッションクリティカルな唯一の経路にせず、冗長経路や再試行戦略を併設するのが前提になります。セキュリティでは、IFTTT側のキーはスコープが広くなりがちなので、呼び出し用途と検証用途でキーやシークレットを分離します。到達先の受信サーバ側では、共有トークンによる認証、リクエストあたりのレート制御、時刻付きノンス（一定時間のみ有効な乱数）での再送防止を組み合わせる設計が現実的です。

レイテンシはトポロジに依存しますが、Webhookであれば数百ミリ秒から秒単位で完了するのが一般的です。ポーリング型のトリガーはプランによって実行間隔が変わるため（数分〜1時間のレンジ）⁷、SLAを求めるケースではWebhook主導に寄せるのが安全です。コストはアカウント/ユーザー単位課金が中心で、小規模チームから段階的に展開すれば、月額の支出より先に工数削減の効果が立ちやすいのが通常のパターンです（価格は変動し得るため、最新の公式情報確認を推奨します）。

実例で学ぶ：Slack通知、GitHub、Google Workspaceの連携

アラートの一次ハブ：社内サービスからIFTTT WebhooksでSlackへ

インシデントの予兆を社内システムで検知したら、IFTTTのイベントをトリガーしてSlackに要約を流すのが最短経路です。³ サーバ側からはHTTPS POSTでIFTTTのイベントを叩き、アプレット側でSlack送信を組み合わせます。重要なのは、送信失敗時の再試行と、メッセージ重複の抑止です。以下はNode.js（Node 18以降）での実装例です。

import crypto from 'node:crypto';

const IFTTT_EVENT = process.env.IFTTT_EVENT;
const IFTTT_KEY = process.env.IFTTT_KEY;
const IFTTT_URL = `https://maker.ifttt.com/trigger/${IFTTT_EVENT}/with/key/${IFTTT_KEY}`;

function dedupeId(payload) {
  return crypto.createHash('sha256').update(JSON.stringify(payload)).digest('hex');
}

async function postWithRetry(url, body, { retries = 3, baseDelayMs = 250 } = {}) {
  let lastErr;
  for (let i = 0; i <= retries; i++) {
    try {
      const res = await fetch(url, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(body),
        signal: AbortSignal.timeout(5000)
      });
      if (!res.ok) throw new Error(`HTTP ${res.status}`);
      return await res.text();
    } catch (e) {
      lastErr = e;
      await new Promise(r => setTimeout(r, baseDelayMs * Math.pow(2, i)));
    }
  }
  throw lastErr;
}

export async function notifySlackThroughIFTTT(alert) {
  const id = dedupeId({ t: alert.type, ts: alert.timestamp });
  const value1 = `[${alert.severity}] ${alert.title}`;
  const value2 = alert.summary;
  const value3 = `dedupe:${id}`;
  return postWithRetry(IFTTT_URL, { value1, value2, value3 });
}

アプレット側ではvalue1〜3をSlackメッセージとして整形できます。重複抑止のためにハッシュを同梱し、Slack側で同一ハッシュを含むメッセージを抑制するルールを別途用意すると安定します。より踏み込むなら、SlackのBlock Kit（リッチなメッセージ構造）を使うためにIFTTTの「Make a web request」で直接SlackのIncoming Webhookを叩く構成にし、IFTTTはイベントハブとして割り切るのも有効です。⁹

運用ログの永続化：IFTTTから自前の受信エンドポイントへ

アプレットの末端を自前APIに向けると、イベントの監査やメタデータ拡張が容易になります。IFTTTからの着信は認証が弱くなりがちなので、最低限の共有トークンで保護し、IPレート制限を併用します。以下はExpressでの受信例です。

import express from 'express';

const app = express();
app.use(express.json());

const SHARED_TOKEN = process.env.IFTTT_SHARED_TOKEN;

app.post('/hooks/ifttt', (req, res) => {
  const token = req.headers['x-shared-token'];
  if (token !== SHARED_TOKEN) return res.status(401).send('unauthorized');

  const { value1, value2, value3 } = req.body || {};
  const record = {
    title: value1,
    body: value2,
    meta: value3,
    receivedAt: new Date().toISOString()
  };
  // TODO: 永続化（例：BigQuery/Firestore/TimescaleDB）
  console.log('ifttt_event', record);
  return res.status(204).end();
});

app.listen(3000, () => {
  console.log('listening on :3000');
});

この構成により、Slackなど外部SaaSに流す前に自社の監査ログへ必ず着地させる「中央線」を作れます。IFTTTからの到達率に不安がある場合でも、アプレットの末尾を自前APIに向けておけば再配送や再構成が容易です。時刻付きノンスとユニークキー制約（例：record.idの一意制約）を組み合わせれば冪等性も担保できます。

GitHubリリースを起点に、プロダクト運用のToDoを作る

タグ付けやRelease作成をトリガーにIFTTTを呼び出すと、通知やチケット作成、状況の共有が統一されます。CIから直接IFTTT Webhooksを叩く例を示します。

name: notify-ifttt-on-release
on:
  release:
    types: [published]

jobs:
  ping:
    runs-on: ubuntu-latest
    steps:
      - name: Call IFTTT
        env:
          IFTTT_EVENT: release_published
          IFTTT_KEY: ${{ secrets.IFTTT_KEY }}
        run: |
          set -euo pipefail
          curl -sS -X POST \
            -H 'Content-Type: application/json' \
            -d '{"value1":"'"${{ github.repository }}"' v'"${{ github.event.release.tag_name }}"'","value2":"'"${{ github.event.release.html_url }}"'","value3":"actor:'"${{ github.actor }}"'"}' \
            https://maker.ifttt.com/trigger/${IFTTT_EVENT}/with/key/${IFTTT_KEY}

この通知を受けてSlackにポストし、さらに自前APIにミラーすれば、人的な周知漏れを減らせます。関連する設計指針は、関連記事の解説も参考になります。Slack運用を自動化する設計や、Googleスプレッドシート自動化、SSO運用タスクの自動化などを踏まえると、チーム横断の見える化が加速します。

異常系を怖がらない：BashとPythonで堅牢に叩く

小さな自動化は壊れ方も小さくすべきです。HTTPの断続的な失敗は珍しくないため、軽い再試行を入れておきます。

#!/usr/bin/env bash
set -euo pipefail

url="https://maker.ifttt.com/trigger/$IFTTT_EVENT/with/key/$IFTTT_KEY"
payload=$(jq -n --arg v1 "$1" --arg v2 "$2" --arg v3 "$3" '{value1:$v1,value2:$v2,value3:$v3}')

for i in 0 1 2; do
  if curl -sS -m 5 -H 'Content-Type: application/json' -d "$payload" "$url"; then
    exit 0
  fi
  sleep $(( 2 ** i ))
done

echo "IFTTT call failed" >&2
exit 1

Pythonを使う場合はタイムアウトと例外処理を忘れないようにします。

import os
import json
import time
import requests

IFTTT_EVENT = os.environ["IFTTT_EVENT"]
IFTTT_KEY = os.environ["IFTTT_KEY"]
URL = f"https://maker.ifttt.com/trigger/{IFTTT_EVENT}/with/key/{IFTTT_KEY}"

def trigger(value1, value2, value3, retries=3):
    data = {"value1": value1, "value2": value2, "value3": value3}
    for i in range(retries + 1):
        try:
            res = requests.post(URL, json=data, timeout=5)
            res.raise_for_status()
            return res.text
        except Exception as e:
            if i == retries:
                raise
            time.sleep(2 ** i)

if __name__ == "__main__":
    print(trigger("deploy", "staging ok", "actor:ci-bot"))

Google Workspaceとの橋渡し：Apps Scriptで記録を残す

運用時系列の薄い台帳をスプレッドシートに残しておくと、障害の振り返りやKPIの集計が楽になります。IFTTTの「Make a web request」でApps ScriptのWebアプリにPOSTし、行追加します。⁸

/**** Google Apps Script ****/
function doPost(e) {
  const token = e.parameter.token;
  if (token !== PropertiesService.getScriptProperties().getProperty('SHARED_TOKEN')) {
    return ContentService.createTextOutput('unauthorized').setMimeType(ContentService.MimeType.TEXT);
  }
  const body = JSON.parse(e.postData.contents);
  const sheet = SpreadsheetApp.openById(PropertiesService.getScriptProperties().getProperty('SHEET_ID')).getSheetByName('log');
  const now = new Date();
  sheet.appendRow([now.toISOString(), body.value1, body.value2, body.value3]);
  return ContentService.createTextOutput('ok').setMimeType(ContentService.MimeType.TEXT);
}

このWebアプリの公開URLにクエリ文字列でtokenを付け、IFTTTからPOSTします。シンプルですが、ダッシュボードを別途用意していない状況でも最低限の可視化が得られます。Apps Script側のトークンはスクリプトプロパティに保持し、半年〜四半期ごとの定期ローテーションを運用ルールとして決めておくと安全です。

運用設計：セキュリティ、レイテンシ、可用性をどう担保するか

鍵の取り扱いは最初に線引きします。IFTTTキーは環境変数やシークレットマネージャで保持し、送信専用のサービスアカウントに紐づけて露出範囲を狭めます。受信側では共有トークン、IP制限、レートリミット、そして冪等性の確保を組み合わせます。重複実行は必ず発生しうるため、アプリケーションレベルでのデデュープが必要です。先の例のようにイベントのハッシュをメタ情報に含めるほか、受信ストレージでユニークキー制約を使うと堅牢になります。ワンタイムノンス＋有効期限（例：発行時刻＋5分）を検証し、期限外のリクエストは拒否するだけでも再送事故を減らせます。

レイテンシはWebhookで数百ミリ秒〜数秒の範囲に収まりやすい一方、外部SaaS間の連鎖では遅延が累積します。エスカレーションや承認系など人間のアクションに直結するフローは、IFTTTだけに依存せず、バックアップ通知経路（例：Slack＋メールやSMS）を平行させると安心です。可用性は失敗時の再試行で担保するのが基本ですが、連打による副作用がある操作ではキューイングや遅延実行に切り替えます。到達性を監視するため、ヘルスチェック用のダミーイベントを定期送信し、一定時間内に到着しなければアラートする仕組みを自社側に用意しておくと、プラットフォーム障害の検知が早まります。

監査とプライバシーの観点では、メッセージ本文に個人情報や秘匿情報を入れない原則を徹底します。どうしても必要な場合は、IFTTTではなく社内の安全なAPIにメタデータだけを流し、フロントのオブザーバビリティ基盤から詳細にアクセスさせる方式に寄せます。運用ルールとして、IFTTTのキーやApps Scriptのトークンは四半期ごとのローテーション、退職・権限変更時の即時失効、変更履歴の記録（監査ログ）を最初に決めておくと事故を抑えられます。

導入の進め方とROIの見立て

初期段階では通知と記録のペアに絞るのが吉です。まずはプロダクトのライフサイクルに沿って、デプロイ、リリース、障害の三場面でアプレットを用意します。三つのアプレットが安定したら、社内の日報や当番管理、軽い承認フローなどに広げます。IFTTTはノーコードであるがゆえに、誰でも作れて誰でも壊せる側面があります。ワークスペースのオーナーを明確にし、命名規約、接続先の棚卸し、バックアップ経路の有無をドキュメント化するだけで、運用事故は減ります。レビュー文化を取り入れ、アプレットの変更はプルリクに準じた承認を通す運用にすれば、規模が大きくなっても破綻しません。

ROIは時間削減で評価します。通知・記録系の自動化は、1回あたり1〜2分の手作業を消し、日に数十回発生する場面を直撃します。例えば一日30回の作業を平均90秒短縮できれば、日当たり45分、月20営業日で約15時間の削減です。時給4,000円相当の開発者が担当しているなら、月あたり約6万円の価値になります。別の現実的なシナリオでは、1分削減×50回/日で月約16.7時間、時給3,000円換算で約5万円相当の削減です。IFTTT Pro/Pro+のコストは小規模チームでも月額で数百円〜数千円台に収まるケースが一般的で（価格は変動しうるため要確認）、導入・調整に初回2〜4時間を投じたとしても、数日〜数週間で回収できる目安になります。ワークロードの偏差が大きいチームでは、繁忙時の手作業を吸収するバッファとしても効きます。

まとめ：軽量な接着剤で、チームの速度を底上げする

IFTTTは重厚なBPMやiPaaSの代替ではなく、日々の運用を支える軽量な接着剤です。Webhookを軸にSlackやGitHub、Google Workspaceとつなげれば、今日から運用の手触りが変わります。まずは通知と記録のペアから始め、冗長経路と監査の仕組みを添えて安定化し、効果が見えたらチーム全体に展開する。その一歩が、開発組織の実効速度を着実に押し上げます。

**始めるのに十分な要素は揃っています。**今日、どのイベントをSlackに流し、どの記録を自社の中央線に着地させるか。最小のアプレットを一つ選び、ここに挙げたコードを環境に合わせて差し替え、まず運用の1分を取り返してください。積み上がる削減の先に、チームの創造的な時間が戻ってきます。

参考文献

McKinsey & Company. The future of work in Japan: Accelerating automation after COVID-19. https://www.mckinsey.com/featured-insights/asia-pacific/the-future-of-work-in-japan-accelerating-automation-after-COVID-19?sid=3461985008#:~:text=to%20deliver%20more,more%2C%20the%20tight%20labor%20market
McKinsey & Company. The future of work in Japan: Accelerating automation after COVID-19 — Exhibit 3. https://www.mckinsey.com/featured-insights/asia-pacific/the-future-of-work-in-japan-accelerating-automation-after-COVID-19?sid=3461985008#:~:text=Companies%20can%20get%20ahead%20of,Exhibit%203
Slack ヘルプセンター. Slack 対応自動化アプリ（IFTTT 連携の概要）. https://slack.com/intl/ja-jp/help/articles/13373269464211-Slack-%E5%AF%BE%E5%BF%9C%E8%87%AA%E5%8B%95%E5%8C%96%E3%82%A2%E3%83%97%E3%83%AA-#:~:text=IFTTT%20%E3%81%A7%E3%81%AF%E3%80%81%E3%80%8Cif%20this%2C%20then%20that%E3%80%8D%E3%81%A8%E3%81%84%E3%81%86%E6%9D%A1%E4%BB%B6%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B9%E3%83%86%E3%83%BC%E3%83%88%E3%83%A1%E3%83%B3%E3%83%88%E3%81%AB%E3%82%88%E3%81%A3%E3%81%A6%E3%80%81Web,%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E5%90%8C%E5%A3%AB%E3%82%92%E9%80%A3%E6%90%BA%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%99%E3%80%82Slack%20%E5%AF%BE%E5%BF%9C%20IFTTT%20%E3%82%A2%E3%83%97%E3%83%AA%E3%82%92%E4%BD%BF%E3%81%88%E3%81%B0%E3%80%81%E6%9D%A1%E4%BB%B6%E3%81%A4%E3%81%8D%E3%83%AC%E3%82%B7%E3%83%94%E3%81%AB%E3%82%88%E3%81%A3%E3%81%A6%E3%80%81Slack%20%E3%81%AE%20%E3%83%81%E3%83%A3%E3%83%B3%E3%83%8D%E3%83%AB%E3%81%A7%E6%9B%B4%E6%96%B0%E6%83%85%E5%A0%B1%E3%82%92%E5%8F%97%E3%81%91%E5%8F%96%E3%82%8B%E3%81%93%E3%81%A8%E3%81%8C%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%99%E3%80%82
IFTTT ヘルプ. What is the difference between polling Applets and realtime Applets? https://help.ifttt.com/hc/en-us/articles/4412435510171-What-is-the-difference-between-polling-Applets-and-realtime-Applets#:~:text=Polling%20Applets%20run%20after%20IFTTT,every%20hour%20for%20Free%20users
Microsoft in Business Japan. NTTデータが牽引する“ホワイトカラー革命” — RPAによる業務自動化の実例. https://www.microsoft.com/ja-jp/industry/blog/microsoft-in-business/2019/06/28/ntt-data-leads-white-color-revolution-automating-tasks-with-rpa/#:~:text=%E6%97%A5%E6%9C%AC%E3%81%A7%E3%81%AF%E3%80%81%E5%B0%91%E5%AD%90%E9%AB%98%E9%BD%A2%E5%8C%96%E3%81%AB%E3%82%88%E3%82%8B%E5%8A%B4%E5%83%8D%E4%BA%BA%E5%8F%A3%E3%81%AE%E6%B8%9B%E5%B0%91%E3%81%8C%E5%96%AB%E7%B7%8A%E3%81%AE%E8%AA%B2%E9%A1%8C%E3%81%A7%E3%81%99%E3%80%82%E6%9C%80%E8%BF%91%E8%A9%B1%E9%A1%8C%E3%81%AE%20RPA%20,%E4%BB%A5%E4%B8%8B%E3%80%81NTT%E3%83%87%E3%83%BC%E3%82%BF%29%20%E3%82%82%E6%8F%90%E4%BE%9B%E3%81%99%E3%82%8B%E5%9B%BD%E7%94%A3%20RPA
IFTTT ヘルプ. What are Webhooks? https://help.ifttt.com/hc/en-us/articles/34771177340315-What-are-Webhooks#:~:text=Webhooks%20are%20one,to%20constantly%20check%20for%20updates
IFTTT ヘルプ. What is the difference between polling Applets and realtime Applets?（Realtime Applets の説明） https://help.ifttt.com/hc/en-us/articles/4412435510171-What-is-the-difference-between-polling-Applets-and-realtime-Applets#:~:text=Realtime%20Applets
IFTTT ヘルプ. What are Webhooks?（curl 等の利用例） https://help.ifttt.com/hc/en-us/articles/34771177340315-What-are-Webhooks#:~:text=Some%20platforms%2C%20like%20IFTTT%2C%20Google,line%20utilities%20such%20as%20%60curl
IFTTT サービスページ. Slack integration on IFTTT. https://ifttt.com/slack#:~:text=IFTTT%20allows%20you%20to%20enhance,in%20your%20chosen%20Slack%20channels