繰り返し作業をAIで自動化する：定型業務の仕組み化

受信メールの内容を見てフォルダに振り分ける、週次レポートの数字をコピーして定型文に貼り込む、問い合わせフォームの内容を要約して担当者に転送する——こうした作業は一つひとつは数分でも、毎日・毎週続けると年間で相当な時間になります。しかも「判断はほぼ固定されているのに、毎回人が手を動かしている」という点が共通しています。AIとノーコード連携ツールを組み合わせると、この種の定型業務は仕組み化できます。ただし、自動化に向く作業と、判断の余地を残すべき作業を見誤ると、誤った通知や誤送信が自動で大量発生するという逆効果も起こり得ます。

前提 — 自動化に向く作業とそうでない作業を分ける

自動化の第一歩はツール選びではなく、作業の棚卸しです。1週間、自分が繰り返している作業をメモし、それぞれについて「判断基準が毎回ほぼ同じか」「間違えたときの影響が小さいか」の2点を確認します。振り分け・要約・定型文の生成のように基準が明確な作業は自動化に向きますが、契約条件の最終確認や社外への公式回答のように、間違いが直接損害につながる作業は人の判断を残すべきです。ここではZapier、Make、Google Apps Scriptを例に使いますが、いずれも2026年時点の機能であり、UIや料金体系は変更される可能性があるため、実際に使う際は各社の公式ドキュメントで最新の仕様を確認してください。

手順 — 定型業務を仕組み化する4ステップ

①トリガーとアクションを言葉で書き出す

「メールが届いたら」「スプレッドシートに行が追加されたら」のように、何をきっかけに、何をするかを日本語の一文で書きます。この時点でAIをまだ登場させず、人がやっている作業をそのまま言語化するのがコツです。

②AIに任せる部分だけを切り出す

トリガーとアクションの間に「内容を読んで判断する」「文章を要約・整形する」という工程があれば、そこがAIの担当範囲です。ZapierはAI Actionsという機能で、Zap内の任意のステップからAIモデルを呼び出し、その出力を次のステップに渡す構成に対応しています※1。Makeも同様にAIモジュールをシナリオに組み込めます※3。

③プロンプトに出力形式を固定する

自動化では人が毎回出力を見て調整するわけではないため、プロンプトの出力形式のブレが即エラーにつながります。次のように、後続処理が読み取れる形式を明示します。

次のメール本文を読み、以下のJSON形式のみで出力してください。
説明文や前置きは不要です。
{
  "category": "見積依頼 / 問い合わせ / その他 のいずれか",
  "summary": "40字以内の要約",
  "urgent": true または false
}

（ここにメール本文を貼り付け）

④小規模なテストデータで1週間試す

いきなり全件を自動処理に流さず、コピーした環境やテスト用フォルダで1週間分の実データを流し、出力を人が目視で確認します。誤分類やJSON形式の崩れが出た場合は、プロンプトの指示を具体化するか、選択肢を絞り込みます。

確認 — ここまでできればどう見えるか

正しく組めていれば、テスト対象のメールやフォームの内容ごとに、指定した形式のcategory・summary・urgentが返ってきて、次のステップ（通知の振り分けやシート追記）が正しい場所に反映されます。形式が崩れて後続処理がエラーになる場合は、プロンプトの出力形式指定が弱いか、モデルへの入力に余計な文字列が混ざっている可能性があります。

つまずきやすい点 — 誤りが自動で拡散する

自動化の怖さは、人が間に入っていた時代なら気づけた小さな誤りが、そのまま次の処理へ流れ込んでしまう点にあります。言語モデルは「わからない」と答えるより、もっともらしい推測で答えるほうが評価上得をしやすい構造があるとする分析もあり※4、自動化ではこの傾向がそのまま誤分類や誤送信として表に出ます。もっとも、これは自動化をやめる理由にはなりません。重要度の高い分岐だけ人の承認ステップ（Slack通知で承認ボタンを押すまで次に進まない、など）を挟む設計にすれば、誤りの影響範囲を限定できます。一方で、個人情報や契約金額など社外秘のデータを外部AIサービスに渡す構成にする場合は、利用するツールのデータ利用規約と自社のポリシーを事前に確認してください。

次の一歩

単発のトリガー・アクションが組めたら、次は複数のAIツールをつないで一連の業務フローとして設計する段階です。設計の考え方は業務ワークフローを設計する記事で扱っています。また、Zapier・Make以外にコードを書かずにワークフローを組みたい場合の選択肢と実例はノーコードAI自動化の記事にまとめました。