繰り返し作業をAIで自動化する設計 — どこを任せ、どこを人が残すか

自動化の判断基準は精度ではなく誤りのコストである

問い合わせメールの一次分類を自動化するとします。カテゴリ分けを間違えても担当者が数分で振り分け直せるなら、多少の誤分類は許容できます。一方、返金処理や顧客データの削除を自動化する場合、一度実行してしまうと取り消しが難しく、誤りのコストは桁違いに高くなります。この2つを同じ基準で「AIの精度が90%あれば十分か」と問うこと自体が設計ミスです。

自動化を設計するときは、タスクごとに「誤ったときの被害の大きさ」と「元に戻せるかどうか」を先に書き出す必要があります。被害が小さく可逆な作業はAIに任せる余地が大きく、被害が大きく不可逆な作業は、どれほどモデルの性能が上がっても人の確認を外すべきではありません。これはモデルの世代が変わっても変わらない設計原則です。

ルールが固定されたタスクは決定的なスクリプトに任せる

ファイル名を「YYYYMMDD_顧客名.pdf」の形式に統一する、CSVの列順を並べ替える、特定のフォーマットで請求書番号を採番する——こうした作業には共通点があります。入力から出力への変換ルールが完全に定義でき、例外がほぼ発生しないという点です。この種のタスクにAIを使うと、むしろ再現性が落ちます。同じ入力を渡しても、モデルやプロンプトのわずかな違いで出力が揺れる可能性があるためです。

正規表現や単純なスクリプトであれば、同じ入力には常に同じ出力が返り、テストで動作を保証できます。ノーコードツールの条件分岐やフォーマット関数も同様に決定的です。ルールが固定されているタスクほど、AIより先に「if文で書けないか」を検討する価値があります。

入力の表現が揺れる非構造化タスクはAIが機能する場面

顧客からの自由記述の問い合わせを内容ごとに振り分ける、長文の議事録から決定事項だけを抜き出す、契約書の条項を要約する——これらは決定的なルールで書き切れません。「返金してほしい」という要望は「お金を返してもらえますか」「キャンセルして全額戻してください」など無数の表現で届くためです。ここでAIは、表現の揺れを吸収して意味を捉えるという、スクリプトが苦手とする役割を担います。

この種のタスクを自律的に連鎖させる設計はAIエージェントの仕組みを分解した記事で扱った「計画・実行・観察」のループに近づきます。ただし単発の分類や抽出であれば、エージェント化までせず、AIを1ステップの部品として組み込むだけで十分な場合がほとんどです。

不可逆な操作には人の確認を残す設計にする

自動化の設計でもっとも見落とされやすいのが、AIやスクリプトの判断をそのまま実行に直結させてしまう配線です。たとえば問い合わせの内容を分類した後、「返金」に分類されたものを人の目を通さず自動で処理してしまうと、誤分類が金銭的な損失に直結します。人を残すべきは、操作そのものが不可逆かどうかで決めるべきであり、AIの精度が高いか低いかで決めるべきではありません。

実際に定型業務へAIを組み込んだ現場の記録では、レビューの手間がゼロにはならず、むしろ「どこまで人が見るか」の線引きが継続的な調整点になっていました。ChatGPTを定型業務に組み込んだ3か月の記録でも、確認作業自体は減らず、確認の質が変わったと報告されています。自動化は人の作業をゼロにする設計ではなく、人の注意を配分し直す設計です。

非決定性をワークフローの中核に置いてしまう失敗パターン

よくある失敗は、AIの出力をそのまま条件分岐のトリガーに使うことです。「AIが『承認』と判断したら次のステップに自動で進む」という設計は、AIの出力が構造化されたJSONであっても、モデルが期待外のキーや値を返す可能性を消せません。分岐の根幹にAIの生の出力を置くと、ワークフロー全体の信頼性がモデルの気まぐれに従属してしまいます。

もっとも、この問題はモデル側の進化でいくらか緩和されています。主要なAIベンダーは構造化出力やツール呼び出しの機能を提供しており、出力形式が崩れる頻度は以前より下がっています。とはいえ、形式が正しくても内容の判断が誤っている可能性は残ります。形式の検証と内容の妥当性検証は別問題であり、後者を省略した自動化は長期的に事故を起こします。

実装の骨格 — 判定・実行・検証・エスカレーションの4段階

実務で崩れにくい自動化は、おおむね次の4段階で構成されています。まず「判定」でタスクの種類とリスクレベルを決定的なルールで振り分け、次に「実行」でルールが固定された部分はスクリプトに、表現が揺れる部分はAIに処理させます。続く「検証」では、AIの出力が想定した形式・範囲に収まっているかを機械的にチェックし、最後に「エスカレーション」で、検証を通らなかったものや不可逆な操作を人に戻します。

ノーコードツールでAIステップを組み込む場合も、この4段階を意識すると設計が安定します。具体的な適用境界はZapier・Makeの適用境界を扱った記事で扱っています。自動化を「どこまで任せられるか」という一本の線で考えるのではなく、タスクごとにこの骨格へ当てはめ直す作業こそが、設計の本体です。どこまで人を残すかという判断は、モデルの性能が上がった後も、組織側が下し続けなければならない意思決定として残ります。