AIを使った業務の自動化が、ある朝いきなり動いていない。あるいは動いてはいるのに、いつもと違う結果が出ている。一人社長や小規模事業では、こうした場面で相談できる情報システム担当がいないことがほとんどです。結論から言うと、AI自動化が止まったときは「直す」より先に、影響範囲を確かめ、実行記録（ログ）を読み、原因を5つの型に切り分け、二重実行を避けて再実行し、担当と連絡先を決め、最後に記録を残す、という6つの順番で動くと慌てずに済みます。
この記事は、特定のツールの操作手順ではなく、AIエージェント・定期実行・連携ツールのどれにも共通する「止まったときの設計」を、任せる側の視点で整理したものです。ツールごとの料金や制限の数値は扱いません。また、記事中の例は「仮の例」と明記したもので、実在の会社や事故の紹介ではありません。そもそも何を任せるかを決めたい方は、当媒体の一人起業のAI社員、最初に任せる業務の選び方を先に読むと、この記事の前提がつかみやすくなります。
止まったときの結論：直す前に影響範囲・記録・担当を確かめる
自動化が止まったときの最初の仕事は修理ではなく状況の把握で、影響範囲、実行記録、担当の3点を確かめてから原因探しに入ります。
止まった自動化を前にすると、すぐに設定画面を開いて直したくなります。しかし、原因が分からないまま設定を触ると、元の状態が分からなくなり、同じ処理が二重に走ることもあります。順番を決めておくだけで、この種の二次被害はかなり減らせます。この記事では、次の6つの手順を使います。
| 順番 | やること | 答えを出したい問い |
|---|---|---|
| 1 | 影響範囲の確認 | どの業務、どの相手、どの期間に影響が出ているか |
| 2 | ログ・実行記録を見る | 最後に正常に動いたのはいつで、どこで止まったか |
| 3 | 原因の切り分け | 入力・権限や認証・上限・仕様変更・手順のどれか |
| 4 | 二重実行を避けた再実行 | やり直しても同じ処理が重ならないか |
| 5 | 担当と連絡 | 誰が判断し、誰に何を知らせるか |
| 6 | 再発防止の記録 | 次に同じことが起きたとき、誰が読んでも動けるか |
この表の順番が大事なのは、前の手順の答えが次の手順の入力になるからです。影響範囲が分からなければ、ログのどの期間を見るべきかが決まりません。原因が分からなければ、再実行してよいかも決まりません。以降の節で、1つずつ具体的に見ていきます。
「止まった」と「おかしな結果」は別の事故として扱う
自動化の不具合は、処理が動かない「停止」と、動いたのに中身が違う「誤結果」に分かれ、後者のほうが気づきにくく、影響が広がりやすい性質があります。
止まった場合は、いつもの通知やレポートが届かないので、気づく手がかりがあります。一方、おかしな結果は、処理自体は成功と表示されているため、人が数字や文面を見て初めて気づくことが多くなります。同じ「不具合」でも、確認する順番が違います。
| 種類 | 見え方 | 最初に確認すること | 先に守ること |
|---|---|---|---|
| 停止（動かない） | 通知やレポートが届かない、処理待ちが溜まる | 最後に成功した実行の日時 | 手作業で代替できる業務を人が引き取る |
| 誤結果（動いたが違う） | 数字が合わない、文面が不自然、宛先が違う | どの実行から違いが出たか、すでに外へ出たものはあるか | 外へ出る処理（送信・投稿・更新）を一時停止する |
| 部分停止（一部だけ動く） | 特定の相手や店舗の分だけ抜ける | 抜けた対象の共通点（入力の形、担当、条件） | 抜けた対象への影響を個別に確認する |
誤結果で特に大事なのは、「すでに外へ出たもの」の有無です。お客様への送信、SNSへの投稿、帳票の更新のように、人の目を通らずに外へ出る処理がある場合は、原因探しより前にその処理を止めます。AIに任せる範囲と、人が確認する地点の考え方は、当媒体のAIエージェントで業務を自動化する手順で詳しく整理しています。
最初の確認：影響範囲を「業務・相手・期間」で切り出す
影響範囲の確認とは、止まった処理が関わる業務、その結果を受け取る相手、問題が出ている期間の3つを書き出して、被害の大きさを見積もる作業です。
慌てているときほど、「全部おかしいかもしれない」と感じてしまいます。そこで、紙でもメモでもよいので、次の3つの問いに答えを書きます。
- 業務：この自動化は、どの仕事の一部か。止まると誰が困るか。
- 相手：結果を受け取るのは、社内の自分か、お客様や取引先か。
- 期間：最後に正常だったと分かっているのはいつか。おかしくなったのはそれ以降のどこからか。
3つが書き出せると、緊急度が決まります。たとえば、社内の自分だけが見る日次の整理レポートが1日止まった場合は、手作業で代替しながら原因を探せます。お客様への自動返信が誤った内容で送られている可能性がある場合は、送信そのものを先に止める必要があります。日次の売上整理のように、元データと突き合わせて確認する運用の考え方は、当媒体の日次売上レポートをAIで整理するが参考になります。
期間については、「最後に正常だった時点」を、思い込みではなく記録で確認するのがコツです。昨日の朝は動いていたはず、という記憶があっても、実際には数日前から一部が抜けていた、ということは起こり得ます。次の節で扱うログが、その裏づけになります。
ログ・実行記録の見方：いつ、何が、どこまで進んだかを読む
ログとは、システムが「いつ・何を・どう処理したか」を時系列で残した記録のことで、止まった原因を探すときの最も確かな手がかりになります。
専門的に聞こえますが、読み方の基本は家計簿に近いものです。日付の順に並んだ行を、最後に正常だった行から順にたどり、最初に様子が変わる行を探します。ツールによって表示名は「実行履歴」「アクティビティ」「ジョブの記録」など異なりますが、見る観点は共通です。
| 見る項目 | 何が分かるか | 読み取り方 |
|---|---|---|
| 実行日時 | 定期実行が予定どおり始まったか | 予定の時刻に行がなければ、起動そのものが失敗している |
| 実行結果（成功・失敗・一部失敗） | どこまで終わったか | 「成功」でも件数が少なければ、入力が欠けている可能性がある |
| 処理した件数 | 入力と出力の量 | 前日までの件数と比べて、急に増減していないか |
| エラーメッセージ | 失敗の理由の手がかり | 原文のまま控え、意味が分からなければ提供元の案内で調べる |
| 実行した人・アカウント | 誰の権限で動いたか | 担当者の異動や退職後に権限が切れていないか |
ここで1つ注意があります。エラーメッセージは、そのまま原因を言い当てているとは限りません。表示されている文言は症状であり、原因は別にあることがあります。メッセージは書き換えずに控え、前後の行の状況と合わせて判断します。
ログがそもそも残っていない、または見つからない、という状況もあります。その場合は、今回の対応を機に「何を記録として残すか」を決めておくのが次への備えになります。この点は、後半の「再発防止の記録」の節で扱います。
原因の切り分け：入力・権限認証・上限・仕様変更・手順の5つの型
自動化が止まる原因の多くは、入力、権限や認証、上限、仕様変更、手順の5つの型のどれかに当てはまり、型ごとに確認する場所が決まっています。
ここでいう「認証」とは、ツール同士がつながるときに「この呼び出しは許可された本人のものだ」と確かめる仕組みのことです。パスワードや連携の許可の有効期限が切れると、昨日まで動いていた処理が突然止まることがあります。「上限」とは、一度に処理できる量や回数の決まりのことで、扱う量が増えた月に初めて引っかかる場合があります。具体的な数値はツールごとに異なるので、この記事では書かず、各ツールの公式の案内で確認することを前提にします。
| 型 | よくある兆候 | 確認する場所 | 人が先にやること |
|---|---|---|---|
| 入力 | 件数が急に減る、空欄や形式違いが混ざる | 元データ、受け取り口の設定 | 元データの更新漏れや書式の変更を確かめる |
| 権限・認証 | ある時点から全件が失敗する、許可に関する文言が出る | 連携の許可状態、アカウントの有効性 | 担当者の変更や有効期限の切れを確かめる |
| 上限 | 量の多い日だけ途中で止まる | 各ツールの利用状況と公式の案内 | 処理を分割できるか、頻度を下げられるかを検討する |
| 仕様変更 | 設定を触っていないのに動きが変わる | 提供元のお知らせ、更新情報 | 変更点を読み、影響する手順を洗い出す |
| 手順 | 自動化の途中で、人が行う作業の抜けが出る | 運用メモ、担当の引き継ぎ記録 | 人が受け持つ工程が誰の仕事か確かめる |
切り分けのコツは、「全件が失敗しているのか、一部だけか」を最初に見ることです。全件が同じ時点から失敗しているなら、権限・認証や仕様変更のように、全体に効く原因を疑います。一部だけなら、入力の形や上限のように、特定の対象に偏る原因を疑います。この見方だけで、調べる範囲をかなり絞れます。
AIを使った処理には、もう1つ特有の事情があります。AIの出力は、同じ入力でも毎回まったく同じになるとは限りません。そのため、結果がおかしいときは、プログラムの不具合だけでなく、入力の指示文や参照資料の変更も原因候補に入れます。AnthropicのエンジニアリングブログBuilding effective agentsでは、エージェントの自律性が高いと「higher costs, and the potential for compounding errors」、つまりコストが増え、誤りが積み重なる可能性があると述べられています。出典はAnthropic「Building effective agents」です。誤りが積み重なる前に、途中の結果を人が見られる設計にしておくことが、切り分けの助けにもなります。
仮の例：日次の整理レポートが届かなかった朝を6つの手順でたどる
仮の例を使うと、影響範囲の確認からログの読み取り、再実行、連絡、記録までの流れが、1本の筋として見えるようになります。
以下は、説明のために作った仮の例です。実在の会社や実際の事故ではありません。小さな焼き菓子の販売事業で、毎朝、前日の注文データをAIで整理し、売れ筋のメモを自分宛てに送る自動化を動かしているとします。
| 手順 | この仮の例で行うこと | 結果の扱い |
|---|---|---|
| 1. 影響範囲 | メモが届いていない。受け取るのは自分だけで、お客様には送られない。期間は今朝の1回分 | 緊急度は低い。手作業で注文一覧を見ながら原因を探せる |
| 2. ログ | 実行履歴を開くと、予定の時刻に実行の行はあるが、処理した件数が0件になっている | 起動はできている。入力が空だった可能性が高い |
| 3. 切り分け | 注文データの出力元を見ると、前日に出力の列の並びを変えていたことが分かった | 型は「入力」。形式違いで読み取れなかった |
| 4. 再実行 | 列の並びを元に戻し、同じ日付を指定して1回だけ再実行する。メモは自分宛てなので重なっても影響は小さい | 再実行前に「宛先は自分のみ」と確認してから実行 |
| 5. 連絡 | 共同で見ている家族に「今朝のメモは遅れて届く」と一言知らせる | 実害が出る前に伝える |
| 6. 記録 | 「出力の列を変えるときは、整理の設定も同じ日に確認する」と運用メモに追記する | 同じ原因の再発を減らす |
この例のポイントは、手順4で「宛先は自分のみ」と確かめてから再実行している点です。同じ流れでも、宛先がお客様なら、再実行の前にもう1つ確認が必要になります。次の節で、その考え方を説明します。
二重実行を避けた再実行：冪等性という考え方
冪等（べきとう）性とは、同じ処理を何度やり直しても結果が1回分と同じになる性質のことで、再実行で二重送信や二重登録を起こさないための基本です。
やり直したくなるのは自然ですが、止まった処理は「途中まで進んでいた」可能性があります。たとえば、まとめて送る処理が半分ほど終えたところで止まり、それを最初から再実行すると、送信済みの相手には2通目が届きます。これを防ぐ考え方が冪等性です。
この言葉は、インターネットの通信の仕組みを定めた標準文書でも使われています。IETFのRFC 9110には、ある方法が「冪等」とされるのは「the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request」、つまり同じ要求を複数回行っても、サーバーへの意図した効果が1回行った場合と同じであるとき、という趣旨の定義があります。出典はIETF「RFC 9110 HTTP Semantics」9.2.2節です。この定義は通信の方法についてのもので、業務の自動化に直接当てはまるとは限りませんが、「やり直しても結果が重ならない」という考え方を、日常の業務に置き換えて使うことはできます。
| やり直したい処理 | 重なると起きること | 重ならないようにする工夫 |
|---|---|---|
| お客様へのメッセージ送信 | 同じ内容が2通届く | 送信済みの宛先に印を付け、未送信の分だけを再実行する |
| 台帳や表への行の追加 | 同じ行が2行できる | 注文番号などの一意の目印で、既にあるかを先に確かめる |
| SNSや記事の投稿 | 同じ投稿が重複して公開される | 公開済みかを画面で確認してから、未公開の分だけ再実行する |
| 集計・要約の作成 | 古い結果と新しい結果が並ぶ | 日付を指定して作り直し、古い版は上書きまたは無効と明記する |
小規模な運用で実行しやすいのは、「処理済みの印」を1列つけておく方法です。表計算の1列に「送信済み」「登録済み」と記録し、再実行する前にその列を見て、未処理の行だけを対象にします。複雑な仕組みがなくても、この1列で二重実行の多くは防げます。
予約確認や連絡のように、お客様に直接届く処理では、この考え方がさらに重要です。店舗での連絡の設計については、当媒体の店舗のAI業務効率化｜予約連絡とシフト連絡の文面をAIで作る型と確認手順で整理しています。
再実行の前に人が確認する地点を置く
再実行は人の承認を挟んでから行うのが安全で、確認する地点を事前に決めておけば、慌てた状況でも判断がぶれません。
Anthropicの同じ記事には、エージェントが「pause for human feedback at checkpoints or when encountering blockers」、つまり確認の地点や行き詰まったときに人の意見を求めて一時停止できる、という説明があります。さらに、停止条件として最大の反復回数のような上限を入れて制御を保つことは一般的だと述べ、サンドボックス、つまり本番に影響しない試験用の環境で十分に試すことを勧めています。出典はAnthropic「Building effective agents」です。
これを小規模な運用に置き換えると、再実行の前に次のチェックを行う形になります。
| 確認 | はい・いいえの意味 |
|---|---|
| 原因は特定できたか | いいえなら再実行しない。原因不明のまま繰り返すと同じ失敗が重なる |
| すでに外へ出た処理はないか | あるなら、その対象を除外してから再実行する |
| 宛先はお客様や取引先を含むか | 含むなら、少数でまず試し、内容を人が見てから残りに進める |
| 失敗したら元に戻せるか | 戻せないなら、実行前に現状を控える |
| 再実行の回数に上限を決めたか | 決めていないなら、2回続けて失敗したら止めて相談する、のように先に決める |
この表の最後の項目は、「失敗したらまた押す」を繰り返さないためのものです。同じ原因のまま何度も実行すると、状況の把握が難しくなります。2回目で止める、と決めておくと、担当に相談するきっかけにもなります。問い合わせ対応のように、お客様への文面が絡む場面での人の確認の置き方は、当媒体のAI社員に問い合わせの一次対応を任せる手順も参考になります。
担当と連絡：誰が止め、誰が直し、誰に知らせるかを決める
担当の設計とは、止める人、原因を調べる人、判断する人、知らせる人を、事故の前に決めておくことで、一人社長でも役割を分けて書き出せます。
一人で事業をしていると、全部を自分でやるので担当を決める必要がない、と感じるかもしれません。しかし、止まったときに「自分が忙しくて対応できない日」を想定すると、代わりに動ける人が必要です。家族、外部の専門家、ツールの提供元のサポートなど、頼れる先を書き出しておくだけでも違います。
| 役割 | やること | 一人社長の場合の置き方 |
|---|---|---|
| 止める人 | 外へ出る処理を一時停止する | 自分。停止の方法を1行でメモしておく |
| 調べる人 | ログを読み、原因の型を絞る | 自分。難しければ提供元のサポートや外部の専門家 |
| 判断する人 | 再実行してよいかを決める | 自分。ただし宛先がお客様なら2回目の確認者を置く |
| 知らせる人 | お客様や関係者へ、必要な範囲で連絡する | 自分。連絡文の雛形を先に用意しておく |
お客様へ連絡する場合は、事実と今後の対応を分けて、短く正確に書きます。原因が確定していないうちは、「原因を確認しています」と書き、推測を事実のように書かないことが大切です。連絡文の例を1つ挙げます。これも仮の例です。
「本日お送りした確認メールに、内容の誤りがありました。お手数ですが、先ほどのメールは破棄し、あらためてお送りするメールをご確認ください。ご迷惑をおかけし、申し訳ありません。」
このように、何が起きたか、相手に何をしてほしいか、おわびの3点だけを書くと、読み手が迷いません。AIに文面の下書きを作らせる場合も、最後は人が読んでから送るようにします。
再発防止の記録：障害メモの型を決めて残す
再発防止の記録とは、起きたこと、原因、直した内容、次回の確認点を短いメモに残すことで、次に止まったときの対応時間を縮める手段になります。
記録は長い文書である必要はありません。次の6つの欄を、そのままコピーして埋められる形にしておくと、続けやすくなります。
| 欄 | 書く内容 | 書き方の例（仮の例） |
|---|---|---|
| 日付と発見者 | いつ、誰が気づいたか | 10月の朝、自分がメモ未着で気づいた |
| 影響範囲 | 業務・相手・期間 | 社内メモのみ、1回分 |
| 原因の型と詳細 | 5つの型のどれか、何が起きたか | 入力。出力元の列の並びを変更した |
| 直した内容 | 何を変え、どう再実行したか | 列の並びを戻し、同日付で1回だけ再実行 |
| 連絡した相手 | 誰にいつ何を知らせたか | 家族に口頭で連絡 |
| 次回の確認点 | 再発防止のために決めたこと | 出力元を変えるときは整理の設定も同日に確認する |
この記録は、次に同じ原因が出たときの手がかりになるだけでなく、「何度も同じ型が出ている」ことに気づく材料にもなります。入力の型が続くなら、元データの受け渡しの方法を見直す、という判断につなげられます。
書くときの注意として、推測と確認済みの事実を分けて書いてください。「たぶん権限が切れた」と「ログに許可に関する文言が出ていた」は別の情報です。後から読む人が事実を取り違えないように、確認した方法も一言添えます。
止まる前の備え：平時に決めておく4つのこと
止まったときに慌てないための備えは、平時に記録の置き場、停止の方法、連絡先、手作業の代替手順の4つを決めておくことです。
備えは大がかりである必要はありません。次の4つを、1枚のメモにまとめておくだけで、対応の質が変わります。
- 記録の置き場：実行履歴をどこで見るか。何日分残るかをツールの案内で確認し、必要なら定期的に控えを取る。
- 停止の方法：外へ出る処理を、どこをどう操作すれば止められるか。
- 連絡先：提供元のサポート窓口、頼れる人、お客様への連絡の経路。
- 手作業の代替：自動化が使えない間に、同じ業務を人が行う最小限の手順。
特に4つ目の手作業の代替は、見落とされやすい項目です。自動化に慣れると、元の手作業のやり方を忘れてしまいます。月に一度でも、手作業の手順を見直して更新しておくと、止まった日の業務の遅れを小さくできます。営業の調べものを自動化している場合は、元の調べ方の記録が代替手順になります。出典の確認から候補の整理までの流れは、当媒体の営業リサーチをAIで効率化するにまとめています。
運用全般の考え方や、事業の実践に近い学びは、当媒体の運用・業務のカテゴリと、導入・実践のカテゴリに記事を順次まとめています。自分の業務に近い記事から読み進めてください。
よくある質問（FAQ）
- Q1. ログの読み方が分からないとき、最初に何を見ればよいですか。
- 最後に正常だった実行の日時と、最初に結果が変わった実行の日時を探します。その2点の間で何が変わったかが、調べる範囲になります。エラーメッセージは書き換えずに控え、提供元の案内で意味を調べてください。
- Q2. 止まった処理は、とりあえずもう一度実行してよいですか。
- 原因が分からないうちは控えてください。途中まで進んでいた処理は、最初から実行すると一部が二重になることがあります。宛先に誰が含まれるか、すでに外へ出た分はないかを確認してから再実行します。
- Q3. 結果は「成功」なのに内容がおかしいのは、なぜですか。
- 処理の成功は「最後まで動いた」ことを示すだけで、中身が正しいことまでは保証しません。入力データの欠け、指示文や参照資料の変更、AIの出力のばらつきなどが候補です。処理した件数を前日と比べるのが、最初の手がかりになります。
- Q4. 一人で運用していても、担当を決める必要はありますか。
- あります。自分が対応できない日を想定して、頼れる人や窓口を書き出しておくと安心です。役割を「止める・調べる・判断する・知らせる」に分けて書くだけでも、慌てたときの迷いが減ります。
- Q5. お客様に誤った内容が届いたかもしれないときは、どうしますか。
- まず外へ出る処理を止め、すでに届いた範囲を確認します。連絡は、何が起きたか、相手にしてほしいこと、おわびの3点を短く書きます。原因が確定していなければ、推測を事実のように書かず、確認中であることを伝えます。
- Q6. 障害メモは、どのくらい詳しく書けばよいですか。
- 日付、影響範囲、原因の型、直した内容、連絡した相手、次回の確認点の6欄が埋まれば十分です。長い文章より、次に読む人がすぐ動ける短さを優先してください。
まとめ：影響範囲、記録、担当を先に決めて、二重実行を避ける
AI自動化が止まったときは、直す前に、影響範囲を業務・相手・期間で切り出し、ログで「最後に正常だった時点」を確かめます。原因は入力・権限や認証・上限・仕様変更・手順の5つの型で切り分け、全件か一部かを見ると絞りやすくなります。再実行は、冪等性の考え方で二重実行を避け、人の確認を挟んでから行います。担当と連絡先は平時に決めておき、起きたことは6欄の短いメモに残します。
最初の一歩としては、いま動かしている自動化を1つ選び、「停止の方法」「記録の置き場」「連絡先」「手作業の代替」の4つを書き出してみてください。何を任せるかの整理から始めたい方は、一人起業のAI社員、最初に任せる業務の選び方も参考にしてください。