AIエージェントによる業務自動化は、デモでは簡単に動きます。難しいのは、毎日決まった時刻に人手を介さず回り続け、しかも壊れたときに気づける状態を保つことです。TOMAS TECH では自社のタイ拠点で、メール、予定、会議録音、見積、フォローアップタスク、社内通知を扱う複数のAIエージェントを日次運用しています。本記事では、その運用で実際に踏んだ7つの落とし穴と、そこから決めた設計ルールを、他社が再利用できる形で公開します。
結論：AIエージェントの自動化は「賢さ」ではなく「壊れたと気づける設計」で決まる
自動化が止まる原因は、モデルの精度不足だけではありません。私たちの運用で実際に業務価値を落としたのは、次のような地味な事象でした。接続が切れているのに処理が正常終了して0件を返す。同じ案件を毎朝新規タスクとして起票し直す。集計の分母に社内メモが混ざっていて結論が反転する。設定ファイルが2か所にあり、直したほうが読まれていない。
これらはいずれも「AIが間違えた」のではなく、エージェントの周辺、つまり入力の健全性、記録の一意性、監視、承認の境界の設計が足りなかったことによるものです。したがって社内自動化の設計中心は、次の5点になります。
- 入力が取れなかったことと、入力が0件だったことを区別できるか。
- 同じ事象を二度書かないための識別子を、実装から独立して定義できるか。
- 出力に分母と対象期間が付いているか。
- 人が最終承認する操作と、エージェントが自走してよい操作の線が引かれているか。
- 壊れたとき、誰にいつどうやって伝わるか。
以下では、この5点がなぜ必要になったかを、実際の失敗の順で説明します。AI導入そのものの進め方を先に整理したい場合はタイ企業向けAI導入ロードマップを、外部委託を含む調達の観点はバンコクのAI開発会社の選び方を参照してください。
何を自動化したのか：バックオフィス9系統の日次エージェント
前提を共有するために、対象範囲を先に示します。いずれも社内業務であり、顧客システムではありません。
| 系統 | 入力 | エージェントの出力 | 人が残す判断 |
|---|---|---|---|
| メール往復ログ | 社内メールクライアント | 送受信をデータベースへ蓄積（社内配信・広告は除外） | 対応要否の最終判断 |
| 予定取り込み | 業務カレンダー | 当日・翌日の予定を会議録データベースへスタブ作成 | 予定そのものの登録・変更 |
| 会議録の反映 | ICレコーダーの文字起こし | 予定行へ要約を突合、非日本語は翻訳して併記 | 内容の正誤確認 |
| 見積の同期 | 基幹システム（PostgreSQL） | 見積の増分同期とオープン日数の更新 | 金額・条件の決定 |
| フォローアップ抽出 | 上記すべて | 当日やるべき対応をタスクデータベースへ起票 | 優先順位と実行 |
| 返信下書き | メール往復ログ | メールの下書きを作成（送信はしない） | 文面の確定と送信 |
| 予定ギャップ検査 | メール＋カレンダー | メールで確定したのに未登録の予定を検出し通知 | カレンダーへの登録 |
| 期限アラート | 人事の在籍データ | 期限が近い対象者と通知期限を算出して起票 | 評価と処遇の決定 |
| 朝の通知 | タスクデータベース | 担当者へ番号付きの未完了タスクをチャット送信 | 完了報告 |
共通する形は「収集 → 正規化 → 記録 → 通知」であり、生成AIが担うのは主に正規化（分類・要約・翻訳・突合）の部分です。記録先は業務側が普段見ている場所（タスク管理と会議録のデータベース、業務チャット、メールの下書きフォルダ）に限定し、エージェント専用の画面を新設していません。担当者に新しい画面を覚えてもらう自動化は、運用が始まった週から見られなくなるためです。
なお、送信・登録・決定にあたる操作はエージェントに渡していません。メールは下書きまで、予定ギャップは検出と通知まで、期限アラートは算出と起票までです。この線引きの理由は後述します。
落とし穴1：失敗が「0件」に化ける
最も長く気づけなかった失敗はこれです。メールを取得して記録するジョブが、接続の前提が失われた状態でも正常終了し、「対象0件」として完了報告を出し続けていました。ログはすべて成功、通知も「本日の対象はありません」。実際には15日間、1件も取れていませんでした。
原因は、実装が「取得結果が空だった」と「取得自体ができなかった」を同じ空配列で表現していたことです。エージェントは空配列を受け取り、忠実に「0件」と報告しました。誰も嘘をついていないのに、業務は15日間止まっていたわけです。
対策として、私たちは全ジョブに次の三つを入れました。
- 接続の健全性を、件数とは別の信号として記録する。 取得元へ到達できたか、認証が通ったか、対象期間の問い合わせが成功したかを、件数0とは独立に保存する。
- 「0件が続いたら異常」とみなす。 平日の業務メールが2日連続で0件になることは、この規模の拠点では起こりません。連続0件の日数を持ち、閾値を超えたら成功ではなく警告として通知する。
- 完了報告に取得元の状態を必ず書く。 「0件」ではなく「接続OK・対象期間24時間・該当0件」と書く。人が読んだ瞬間に違いが分かります。
一般に、バッチ自動化の監視は「失敗したら鳴る」設計になりがちですが、AIエージェントは失敗を丸めて成功にしてしまう性質があります。沈黙を異常として扱う監視（デッドマン方式）を最初から入れてください。
落とし穴2：冪等キーがぶれると、毎朝すべてが新規に見える
同じ検査を毎日走らせる以上、「すでに起票済みの案件を二度起票しない」ことが必須になります。私たちはこれを、対象を一意に表す文字列のハッシュ（冪等キー）で判定しています。
ここで二度失敗しました。キーを組み立てる際の区切り文字と連結順を、実装のたびに書き直してしまったのです。区切りが変わればハッシュは完全に変わります。結果として、前日までに起票済みの案件がすべて「新規」と判定され、同じ内容のタスクが積み上がりました。二度目に踏んだとき、冪等キーの計算式を仕様として固定し、実装側で組み立て直すことを禁止しました。
再利用できる形にすると、次の三点です。
- 冪等キーの定義は文章で1か所に書き、コードから参照する。 「日付 と 対象の並び を
|で連結し、SHA-1 の先頭12文字」のように、区切り文字まで含めて仕様化する。 - キーの材料に、実行時刻や実行環境を混ぜない。 現在時刻、ホスト名、ファイルパスが混ざると、同じ事象が毎回別物になります。
- 重複検出の結果を可視化する。 「新規n件・既存更新m件・変更なしk件」を毎回出力すれば、比率が跳ねた日に気づけます。全件が新規になっていれば、その時点で分かります。
落とし穴3：「検索できるはず」の機能が、実環境では使えない
設計時に当然できると思っていた検索が、本番環境では使えないことがあります。私たちの場合はメール本文の全文検索でした。標準の絞り込み構文はクライアントを不安定にし、全文検索用の演算子は環境側で無効化されており、非同期の検索APIは完了を通知しない、という三重の制約でした。
重要なのは、この制約が例外ではなく前提だと受け入れて設計を変えたことです。本文検索を諦め、件名と送受信アドレス、期間で候補を絞り、本文の判断は取得後にエージェント側で行う構成に切り替えました。処理量は増えますが、動く方が価値があります。
AI業務自動化の要件定義では、次を必ず実機で確認してください。カタログとAPIリファレンスだけで判断すると、実装の後半で作り直しになります。
- 検索・絞り込みの構文が、実際のデータ量で完了するか（サンプル100件ではなく、本番相当の件数で試す）。
- 非同期APIが完了を通知するか。ポーリングが必要なら、その終了条件は何か。
- 添付・本文・カスタム項目に、権限とライセンスの制約がないか。
- レート制限に達したときの挙動。リトライ間隔と上限は提供元の資料で確認する（例：Microsoft Graph、Notion API はいずれも公開資料に制限値と推奨動作が記載されています）。
落とし穴4：分母を書かないと、集計の結論が反転する
蓄積したデータを横断集計して傾向を出す段階で、別の問題が出ました。会議録データベースを対象に「顧客ごとの接触頻度」を集計しようとしたところ、顧客名の項目が半数近く空欄で、さらに顧客との会議ではない社内メモが数百件混ざっていました。要約が入っているのは、ある時点以降に登録されたレコードだけでした。
このまま集計すれば、「接触が少ない顧客」は本当に少ないのか、単に名前が入っていないだけなのかを区別できません。分母を書かない集計は、それらしい結論を出してしまうぶん、無言のエラーより危険です。
私たちが決めたルールは次のとおりです。
- 集計結果には必ず 対象期間・母集団・除外条件・欠損率 を併記する。
- 欠損が一定割合を超える項目は、集計に使う前に補完手段を用意する（今回はマスターとの正規化突合で自動補完し、既存値は上書きしない方針にしました）。
- 「入っているレコードだけで見た比率」と「全レコードに対する比率」を両方出す。片方だけを見ると必ず誤読します。
- データの性質が変わった時点（項目追加、運用変更）を境界として明示し、その前後をまたぐ集計は注記する。
これは生成AIに限った話ではありませんが、エージェントは指示された集計を疑わずに実行し、断定的な文章にして返すため、分母の欠落が結論の断定と結びつきやすい点に注意が必要です。
落とし穴5：日付と時刻は、環境ごとに黙ってズレる
タイ拠点と日本本社をまたぐ運用では、時刻の扱いが継続的な事故要因になります。私たちが踏んだのは次の三つです。
一つ目は、シェル環境によってタイムゾーン指定が無視され、意図せず協定世界時（UTC）で動いていたことです。エラーにはならず、日付が1日ずれた結果だけが残ります。二つ目は、日本拠点の相手からのメールが日本時間で書かれているのに、カレンダーはタイ時間で登録されており、7時間の差を人が暗黙に補正していたことです。三つ目は、過去の作業日を「実行中の現在時刻」から逆算してしまい、実際の作成日と食い違ったことです。
対策は単純ですが、徹底が要ります。
- エージェントの内部表現はタイムゾーン付きの日時に統一する。 素朴な日付文字列を持ち回らない。
- 表示は拠点のローカル時刻、保存は絶対時刻という原則を、記録先ごとに決めておく。
- 過去の日付は推論せず、実データ（更新日時、メールのヘッダ）から取る。
- 実行環境のタイムゾーン設定は、起動時にログへ出力して毎回確認できるようにする。
落とし穴6：読み書きの間に、キャッシュと同期が挟まっている
自動化の出力先が社内システムや自社サイトの場合、書いたはずの内容が消える現象に出会います。私たちが確認したのは二種類です。
一つは、コンテンツ配信ネットワークのエッジキャッシュです。書き込み直後に読み出すと古い内容が返り、それを基に次の更新を作ると、直前の変更を上書きして消してしまいます。対策は、読み出しに必ずキャッシュ回避を付けること、書き込み後に読み戻して内容を確認することの二点です。
もう一つは、クラウド同期フォルダ上で成果物を生成した場合です。同期の途中でファイルが差し替わり、修正が反映されないまま完成物ができあがります。対策として、生成処理はローカルの作業領域で実行し、完成物を検証してから同期フォルダへ配置する運用に変えました。
いずれも、原因を知らなければ「エージェントが指示どおりに直さなかった」と誤解する種類の事象です。自動化の検証は、書き込み後に読み戻して突き合わせるところまでを1セットにしてください。
落とし穴7：設定の正本が2か所にあると、直したほうが読まれない
運用が育つと、同じ処理の定義が複数の場所に存在するようになります。私たちの場合、定期実行が読む定義と、手動実行が読む定義が別ディレクトリに複製されていました。片方だけを修正し、翌朝も同じ不具合が出て初めて気づきました。
これはAI特有の問題ではありませんが、エージェント運用では影響が大きくなります。エージェントは指示された場所を読み、そこに書かれたとおりに実行するため、古い定義を読んだ場合も自信を持って完走するからです。人間なら「あれ、直したはずなのに」と手が止まりますが、エージェントは止まりません。
- 定義の正本を1か所に決め、他方は参照のみにする。複製が必要なら生成物として扱い、手で編集しない。
- 実行ログに、どのパスの定義を読んだかを出力する。
- 定義を変更したら、次回の自動実行の結果まで確認して初めて完了とする。
人の承認をどこに残すか：自律度を段階で決める
ここまでの落とし穴を踏まえると、「どこまでエージェントに任せるか」は感覚ではなく、影響の可逆性で決めるべきだと分かります。私たちは操作を次の段階に分け、下から順に開放しています。
| 段階 | 操作の例 | 取り消しやすさ | 現在の扱い |
|---|---|---|---|
| L1 読む | メール・予定・基幹データの取得 | 影響なし | 自動 |
| L2 記録する | データベースへの蓄積、要約の付与 | 修正で戻せる | 自動 |
| L3 起票する | タスクの新規作成、期限の算出 | 削除で戻せる | 自動（冪等キー必須） |
| L4 下書きする | 返信メールの下書き作成 | 送らなければ影響なし | 自動 |
| L5 知らせる | 担当者への通知、アラート | 取り消せないが害は小さい | 自動（宛先を限定） |
| L6 送る・登録する | メール送信、予定登録、社外への公開 | 取り消せない | 人が実行 |
| L7 決める | 金額、処遇、契約条件 | 取り消せない | 人が実行 |
L5とL6の間に線を引いているのが要点です。通知までは自動、外部に影響する操作は人という単純な規則にすると、現場が判断に迷いません。この線引きは、生成AIの誤りが「読み違い」ではなく「もっともらしい断定」として現れることへの備えでもあります。誤りの検出可能性が低いほど、承認の位置は手前に置く必要があります。
なお、通知の自動化にも固有の失敗があります。私たちの場合、通知用のボットの利用権限が作成者本人に限定されていたため、他の担当者宛に送ったつもりの通知が誰にも届いていませんでした。送信APIは成功を返します。通知系は「送信した」ではなく「相手の画面に出た」まで一度は実機で確認してください。
運用に乗せるための最小構成
以上を、これから始める組織向けの最小要件として整理します。派手な機能より、この7項目が揃っているかどうかが継続の分かれ目でした。
| 要素 | 最低限やること | 省くとどうなるか |
|---|---|---|
| 入力の健全性 | 接続・認証・期間問い合わせの成否を件数と別に記録 | 失敗が0件として通り続ける |
| 冪等性 | 事象を一意にするキーを仕様として固定 | 二重起票、または全件新規 |
| 実行記録 | 読んだ定義・対象期間・新規/更新/変更なしの件数 | 何が変わったか誰も説明できない |
| 監視 | 連続0件・連続失敗・実行されなかったことの検知 | 沈黙したまま止まる |
| 再実行 | 同じコマンドで途中から再開できる | 失敗のたびに手作業の復旧が要る |
| 承認境界 | 外部影響のある操作を人に残す | 誤送信・誤登録が起きてから気づく |
| 出力の但し書き | 分母・期間・除外条件を必ず併記 | 集計の結論を誤る |
この7項目には、大規模なプラットフォームも専用の監視基盤も必要ありません。私たちの構成でも、記録先は既存の業務ツール、実行は日次のスケジューラ、監視は同じチャットへの通知です。先に必要なのは道具の追加ではなく、失敗の見え方を決めることでした。
始め方：小さく作り、壊し方から確認する
社内自動化を検討している場合、次の順序を推奨します。生成AIの評価や検証計画の詳細はAI PoCの費用項目と成功基準、社員側の習熟は生成AI社員研修の実技試験も併せて参照してください。
- 1系統だけ選ぶ。 毎日発生し、遅れても致命傷にならず、正解が事後に確認できる業務が向いています。私たちの場合はメールの蓄積でした。
- 記録先を既存ツールにする。 新しい画面を作らない。人が普段見る場所に出す。
- L4（下書き）で止める。 最初から送信させない。1〜2週間、下書きの質を人が採点する。
- 壊し方を先に試す。 接続を切る、権限を外す、対象を空にする。そのとき通知がどう見えるかを確認し、区別できなければ設計を直す。
- 連続0件のアラートを入れてから、無人運転に移す。
- 2系統目以降は、冪等キーと実行記録の書式を1系統目と揃える。 系統ごとに流儀が違うと、監視も引き継ぎもできなくなります。
- 四半期に一度、出力の分母を点検する。 運用の変化でデータの意味は静かに変わります。
FAQ
AIエージェントの業務自動化に、どのくらいの規模の体制が必要ですか？
私たちの構成は、業務を理解している担当者が中心となり、既存の業務ツールとスケジューラの上に組み立てたものです。専任のAI基盤チームは置いていません。ただし、これは自社の内部業務であり、失敗しても社外に影響しない範囲だからこそ成立しています。顧客システムや設備に関わる自動化は、要件定義、試験、運用の体制を別途設計してください。
生成AIの精度は、どのくらいあれば実務に乗りますか？
単独の精度指標では判断できません。重要なのは、誤りが起きたときに人が気づけるか、そして取り消せるかです。取り消せる操作（記録、下書き）は多少の誤りを許容できます。取り消せない操作（送信、登録、決定）は、精度が高くても人の承認を残すのが現実的です。
まず何から自動化すべきですか？
毎日発生し、正解が事後に確認でき、遅れても致命傷にならない業務です。逆に、月次で発生し、正解が誰にも分からず、遅れると即座に損失が出る業務は最初の対象に向きません。
自動化した処理が止まったことに、どうやって気づきますか？
「失敗したら通知する」だけでは足りません。連続して0件が続いていないか、そもそも実行されたか（デッドマン方式）を監視してください。私たちが最も長く気づけなかった障害は、すべて「成功して0件」という形で現れました。
社内データを生成AIに渡してよいですか？
自社の情報分類と契約条件によります。少なくとも、どのデータがどこへ送られ、どこに保存され、学習に使われるかを利用規約と設定で確認してください。タイで個人データを扱う場合はPDPAの適用範囲を専門家と確認し、必要最小限のデータだけを渡す設計にしてください。
エージェントにメールを送信させてもよいですか？
私たちは送信させていません。下書きまでを自動化し、送信は人が行います。誤送信は取り消せず、相手との関係に直接影響するためです。将来的に開放する場合でも、宛先の限定、送信前の確認、送信ログの監査を先に用意すべきだと考えています。
まとめ：自動化の成否は「静かに壊れたとき」に決まる
AIエージェントによる業務自動化で私たちが学んだのは、難所は生成AIの能力ではなく、その周辺にあるということでした。接続が切れても成功と報告されること、識別子が変わると同じ案件が別物になること、分母を書かない集計が断定的な結論を出すこと、キャッシュと同期が変更を飲み込むこと、定義の複製が古いほうを生かし続けること。いずれも派手な障害ではなく、静かに業務価値を削る種類の事象です。
したがって設計の順序は、機能を増やす前に、壊れ方を決め、壊れたときの見え方を作ることです。 入力の健全性を件数と分けて記録し、冪等キーを仕様として固定し、出力に分母を添え、外部に影響する操作は人に残す。この4点を最初に入れておけば、系統が増えても運用は破綻しませんでした。
タイ拠点のバックオフィス業務や、基幹システムと連携する社内自動化の設計でお困りの場合は、TOMAS TECHのお問い合わせページからご相談ください。対象業務と既存システムが分かれば、どこから着手し、どこに承認を残すべきかを具体化できます。
参考情報
- NIST, AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
- OWASP, Top 10 for Large Language Model Applications 2025: https://genai.owasp.org/llm-top-10/
- ISO, ISO/IEC 42001:2023 Artificial intelligence management system: https://www.iso.org/standard/42001
- Microsoft Learn, Microsoft Graph throttling guidance: https://learn.microsoft.com/en-us/graph/throttling
- Notion, API request limits: https://developers.notion.com/reference/request-limits
- ETDA, AI Governance Practice Center (AIGPC): https://www.etda.or.th/th/Our-Service/AIGC/index.aspx
- PDPC Thailand, Personal Data Protection Committee: https://www.pdpc.or.th/
