AIエージェント導入後の運用と保守｜月次点検で見る3つの数字と止める基準

AIに業務を任せ始めた最初の1か月は、誰もが結果をよく確かめます。出力を一件ずつ見て、間違いがあれば手で直すところまでは、多くの会社でできています。

問題は、その後の運用です。問題なく動いているように見え始めると、月を追うごとに確認が減り、やがて誰もログを開かなくなります。

そして半年後、取引先からの指摘で初めて大きな間違いに気づく、ということが起こります。

この記事では、AIエージェントを導入したあと、任せた業務を毎月点検する手順をまとめます。見るのは「処理した件数」「人が直した件数」「止まった件数」の三つだけで、月初の30分ほど（当社の目安）で終わる形を想定しています。

あわせて、精度が落ちたときに疑う順番と、止める基準を先に決めておくことをお勧めします。

任せた業務は止まらずに誤りが混じる

AIの精度が落ちるとき、仕組み全体が止まって使えなくなることはあまりありません。

よくあるのは、大半は正しく、一部だけ間違えている状態です。見た目は問題なく動いており、データも流れ、処理件数もふつうに数えられます。

しかし、紛れ込んだ間違いは、人が意識して確かめない限り見つからず、そのまま後の工程へ流れます。金額を誤った見積書が送られたり、違う内容のまま受注が登録されたりします。

そのため、出力をなんとなく眺めるだけでは足りません。数字で定期的に把握する必要があります。

ずれの原因は、大きく次の三つに分かれます。

• 入力データの変化：取引先の様式の変更、担当者の交代による書き方の違い
• 業務の決まりの変更：単価の決め方、出荷や納期の数え方の見直し
• ツール・AIの更新：基盤のモデルの入れ替え、機能や仕様の変更

どれも、AIが壊れたわけではありません。前提が変わっただけで、その前提は業務の中で常に変わるため、定期的な点検が要ります。

月次点検で見る三つの数字

点検の項目が多いと、続かなくなります。確かめる数字は、処理した件数・人が直した件数・止まった件数の三つに絞ります。

この記事では、手順を具体的に示すために、自動化ツールのn8nを例にします。当社でも実際に運用しており、自社のサーバーに置けば実行履歴を手元に残せるためです。

n8nを勧める記事ではありません。よく使われる自動化ツールで、三つの数字をどこで見るかを下の表にまとめました。

月次で確かめる項目	Power Automate	Google Apps Script	Zapier	n8n
処理した件数	クラウドフローの実行履歴	「実行数」の一覧	Zap history	Insightsの実行回数
止まった件数	実行履歴の「失敗」	「実行数」でステータスが失敗のもの	Zap historyのErrored	Insightsの失敗率、Executionsの一覧
人が直した件数	記録されない	記録されない	記録されない	記録されない

表のいちばん下の行が、この記事でいちばんお伝えしたいことです。人が直した件数は、どのツールにも記録されません。

n8nのInsightsは、本番の実行だけを数え、手動のテスト実行とサブワークフローは含みません（出典：n8n Docs）。

また、無料で使える範囲では直近7日の要約だけです。期間を選べるダッシュボードは、n8n CloudのPro・Enterpriseと、自社サーバーのBusiness・Enterpriseで使えます。

ツールごとの違いは、Zapier・Make・n8nの比較で紹介しています。

処理した件数は前の月と比べる

対象の月にAIが処理した件数の合計です。前の月の数と並べて比べます。

n8nでは「Executions」の一覧で確かめます。いつ動き、成功したか失敗したかが、一件ずつ時系列に並びます。

この画面は一件ごとの記録で、月の合計件数は表示されません。集計のダッシュボードは上位のプランに限られるか、そもそもツールにない場合もあります。

件数が保たれているか増えていれば、現場で日常的に使われている証拠です。件数が減っていれば、現場がAIを通さず別の経路で処理しているかもしれません。

件数が急に減った月は、現場に聞き取りをしてください。使いにくいと感じた担当者が、何も言わずに手作業へ戻していることもあります。

人が直した件数は自社で記録する

AIの出力を人が直した件数です。「人が直した件数 ÷ 処理した件数」で出す修正率が、月次点検でいちばん大切な数字です。

注意したいのは、この数字はn8nをはじめ、自動化ツールの画面には出ないことです。

ツールが判定できるのは、処理が最後まで終わったかどうかまでです。出力した見積りの金額や判定が、業務として正しかったかまでは分かりません。

そのため、人が直したことを自社で記録します。記録用のシートは、スプレッドシートかExcelの一枚で足ります。

手間に思えるかもしれませんが、直す作業はどのみち発生しています。そのときにシートへ一行足すだけです。

比べる相手は、自社の運用初月の数字にしてください。適切な修正率は業種や業務で違うため、他社の平均と比べても意味がありません。

• 修正率が上がり続けている：入力の様式や業務の決まりなど、前提がずれているサイン
• 修正率が下がり続けている：良さそうに見えて、確認が形だけになり見落としている可能性

とくに0％に近づいていく場合は、後者を疑ってください。どちらの可能性も頭に置いて、数字を見ることが大切です。

止まった件数は失敗だけを絞り込む

エラーや、判定できない入力のために、処理が途中で止まった件数です。

n8nでは、「Executions」の一覧に赤い表示で出ます。期間とステータス（Error）で絞り込めば、失敗だけを抜き出せます。

処理が止まること自体は、悪いことではありません。読めない入力を無理に処理せず、人に判断を渡したのなら、設計どおりに動いていると言えます。

危ないのは、止まらずに、間違った結果を正常として出し続けることです。これは止まった件数には表れず、主に人が直した件数の記録で見つけます。

実行履歴は思ったより早く消える

いざ件数を数えようとしても、ツールに履歴が残っていないことがあります。

自動化ツールは、実行の記録をいつまでも残してくれるわけではありません。残る期間や件数には上限があり、ツールとプランで違います。

ツールごとの履歴の保存期間

主なツールで実行履歴が残る期間は、2026年9月時点で次のとおりです。

ツール	実行履歴が残る期間	補足
Power Automate	実行の開始から30日	クラウドフローの場合
Zapier	29〜69日	期間を変えられるのはEnterpriseだけ
n8n Cloud	Starter 7日、Pro 30日	Enterpriseは上限なし
n8n（自社サーバー）	14日か1万件（初期設定）	設定で変えられる
Google Apps Script	日数の記載なし	公式は「長くは残らない」と説明

出典：Microsoft Learn、Zapier、n8nの料金ページ、n8n Docs、Google for Developers

n8nを自社サーバーで動かす場合、初期設定では14日を過ぎたものか、1万件を超えた分から古い順に消えます。処理は止まらないので、履歴だけが静かに消えていきます。

1日に何百件も動く仕組みでは、月末に集計しようと開いたら、月初の履歴がもう消えていた、ということが起こります。

ツールを解約すると、過去の履歴はすべて見られなくなります。保存期間の設定を確かめないまま運用していると、あとから調べ直すこともできません。

実行のたびに自社のシートへ残す

避ける方法は単純で、処理が動くたびに、自社で管理するシートへ一行書き出す仕組みを作っておきます。

組み込むのは、次の二つです。

• 成功した処理の記録：ワークフローの最後に、シートへ一行書き込む処理を足す
• 失敗した処理の記録：エラーのときに動く「Error Trigger」で、同じシートへ書き込む

成功の記録に残す項目は、「実行した日時」「案件番号」「動いたワークフローの名前」の三つで足ります。

Error Triggerは、エラー用のワークフローを一つ作り、各ワークフローの設定（Settings）にある「Error workflow」で選びます。

手動のテスト実行では動かないので、本番の実行で確かめてください（出典：n8n Docs）。

同じエラー用のワークフローから、メールやチャットへ知らせる処理もつなげられます。止まったことに、月末を待たずに気づけます。

この二つを入れておけば、月末の点検で開くのは自社のシート一枚で済みます。ツールの保存期間やプランに左右されません。

このシートを「修正の記録」と同じファイルにまとめておけば、三つの数字が一か所にそろいます。消えた履歴は後から戻せないので、運用を始める月に組み込んでください。

AIに渡す権限と、監査のためのログの設計は、次の記事で詳しく扱っています。

履歴が残る場所と読み方

点検の数字を出すには、運用の履歴が要ります。履歴は主に次の四か所に残ります。

• 自動化ツールの実行履歴
• ワークフロー上の承認・却下の履歴
• 基幹システムなどのデータの変更履歴
• 送ったメールやチャットの控え

n8nで失敗の原因を調べるときは、「Executions」の一覧から対象の実行を開きます。どのノードで止まったかが、画面で一目で分かります。

見るポイントは、止まった工程が「データの読み取り」か「外への送信・書き込み」かです。読み取りなら入力側の形式、送信なら接続先のAPI・認証・宛先の設定を疑います。

月次点検のためには、履歴が少なくとも次の二つを満たしている必要があります。

• 人の操作とAIの自動の操作を区別できる
• 正常に終わった記録だけでなく、失敗の記録も残っている

この二つがそろわないと、修正率やエラーの割合を正しく数えられません。形式の美しさより、必要なときに見られて、消えないことを優先してください。

直した理由を四つに分けて記録する

直した件数を数えるだけでは、翌月からの改善につながりません。直した理由を分けて記録しておくと、打つ手が見えてきます。

理由は、次の四つの分類で足ります。記録は、シートに一行メモを残す程度で構いません。

直した理由	例	偏ったときの対策
入力の読み違い	FAXの画像がかすれていた、様式が変わっていた	取引先に様式をそろえてもらう。読み取りの前に人が仕分ける
AIの判断の誤り	単価の選び方や、納期の答え方を誤った	指示の文面や参照している資料を見直す。社内で難しければ開発の相手に相談する
決まりの変更漏れ	社内の決まりが変わったのに、AIの設定が古いまま	業務を変えるときにAIの設定も直す手順を、社内の流れに入れる
ツール側の変更	更新のあとで動きが変わった	更新の日付と、直した件数が増えた日を照らし合わせる

分類ごとに数えると、どこに手を打つかが決まります。読み違いが多ければ入口を、判断の誤りが多ければ指示や資料を直します。

決まりの変更漏れは、AIの欠陥ではなく運用の漏れです。単価や納期の決まりを変えるときは、AIの設定を直す人と日付も一緒に決めてください。

精度が落ちたら疑う順番を決めておく

精度が落ちたと感じたとき、あてもなく調べるより、切り分けの順番を先に決めておくほうが原因に早くたどり着けます。

順番は、入力データ、業務の決まり、ツールやモデル、指示の文面です。外から来る変化を先に確かめ、指示の文面（プロンプト）は最後に見ます。

疑う順番	見分け方	当てはまる目安	対処
入力データ	失敗した実行の元データを見る	特定の取引先や様式に集中している	様式の確認、人による仕分け、その分だけ一時的に手作業
業務の決まり	修正の記録を項目ごとに見る	取引先に関係なく、特定の項目や数値に集中している	AIの設定を直す、業務を変えるときの手順を見直す
ツール・モデル	エラーが増えた日と更新日を照らし合わせる	ある日を境に全体で一斉に増えた	前の版やモデルに戻す、新しい環境に合わせる
指示の文面	上の三つで説明がつかないとき	境目がなく、少しずつ増えている	確かめ用の20件で前後を比べ、一か所ずつ直す

指示の文面から先に手を付けないでください。文面を変えれば出力は何かしら変わるので直った気になりますが、原因がほかにあれば翌月以降にまた起きます。

さらに、文面を変えたことで、何が効いたのかを確かめられなくなります。

取引先の様式の変更とモデルの更新が、同じ月に重なることもあります。その場合も、この順番で一つずつ原因を確かめてください。

入力データが変わっていないか

切り分け方：直した案件を取引先ごとに並べ替えます。n8nなら「Executions」から該当の実行を開き、元のFAXの画像やメールの本文と、AIの読み取り結果を突き合わせます。

当てはまる目安：直した件数やエラーが、特定の取引先や様式に集まっている場合です。ある日を境に、その取引先だけで失敗が出ているときも当てはまります。

対処：取引先に様式を変えたかを確かめます。そのうえで、次の三つから選びます。

• 前の様式に戻してもらうよう頼む
• 読み取りの前に、人が仕分ける工程を足す
• その取引先の分だけ、一時的に手作業へ戻す

業務の決まりが変わっていないか

切り分け方：修正の記録を見て、直した内容に共通の型がないかを確かめます。たとえば、全取引先で単価の計算だけが直されている、といった型です。

現場の担当者に「最近、計算の基準や業務の決まりを変えましたか？」と聞くのも有効です。現場は、決まりの変更がAIに影響することを意識していないことがよくあります。

当てはまる目安：取引先に関係なく、特定の項目や数値に直しが集中している場合です。AIの動きは変わっておらず、正解の基準のほうが変わっています。

対処：AIの設定や参照する資料を、新しい決まりに合わせて直します。あわせて、「決まりを変えるときはAIの設定も直す」という社内の決まりを足してください。

ツールやモデルが更新されていないか

切り分け方：エラーが急に増えた日付と、自動化ツールやAIのモデルの更新日を照らし合わせます。Insightsの平均実行時間が、ある日を境に大きく変わった場合も手がかりになります。

当てはまる目安：取引先や項目に関係なく、ある日を境に全体で一斉に精度が落ちたり、エラーが増えたりしている場合です。

対処：ツールの更新履歴を確かめ、自社サーバーで動かしているなら前の版に戻します。モデルの更新が原因なら、APIで前のモデルを指定し直すか、新しいモデルに合わせて指示を調整します。

前のモデルの指定は一時しのぎです。Anthropicは、提供を終えたモデルへのリクエストは失敗すると案内しており、提供終了の少なくとも60日前に通知します（出典：Claude Docs）。

通知が届いたら、新しいモデルで確かめてから切り替えてください。更新の履歴は記録に残し、次の切り分けに生かします。

AIのサービスそのものが止まったときの備えは、ChatGPT・Claude障害と混雑への備え方で紹介しています。

指示の文面が古くなっていないか

切り分け方：ここまでの三つに当てはまらない場合に、初めて検討します。指示の文面を最後に直した日と、その後の業務の変化を比べます。

当てはまる目安：ある日を境にではなく、長い期間をかけて少しずつ間違いが増えている場合です。例外の品目や新しい取引先など、特定の条件で誤りやすいときも当てはまります。

対処：直す前に、過去の案件から確かめ用のデータを20件ほど用意し、直す前の正解率を測ります。直したあと、同じ20件で測り直して比べます。

文面は一か所ずつ直し、複数の箇所を同時に変えないようにします。この20件は、ツールやモデルを更新したあとの確かめにも使えます。

止める基準は止まる前に決める

月次点検でいちばん大切なのは、自動化を止める基準を先に決めておくことです。

問題が起きた現場で止めるかどうかを決めようとしても、落ち着いて判断できません。止めれば業務が止まり、続ければ誤りが広がるという板挟みになり、判断が遅れるためです。

止める条件と止める人を決める

条件は、数字と止め方を組にして決めておきます。下は記入例で、数字は業務に合わせて決めてください。

条件（例）	止め方（例）
修正率が運用初月の2倍を超えた	翌月は一時的に手作業へ戻す
取引先へ誤ったデータを1件でも送った	そのワークフローをすぐ止める
同じ型の判断の誤りが3回続いた	その処理を止め、原因を切り分ける

あわせて、止める権限を誰が持つかも決めておきます。経営者だけに権限を集めると、不在のときに誤りが放置されるおそれがあります。

現場の責任者や運用の担当者にも、止める権限を渡してください。夜間や休日に自動で動く仕組みなら、そのときに誰が止めるかまで決めておきます。

止めたあとに再開する条件も、先に決めておきます。原因が分からないまま再開すると、同じ問題がまた起きます。

送る工程だけを止める

止め方は、全部自動か全部手作業かの二択でなくてもかまいません。

外への送信や書き込みの工程だけを止め、読み取りと下書きまではAIに続けさせる止め方もできます。業務全体を止めずに、大きな危険だけを外せます。

n8nでワークフローごと止めるときは、メニューから「Unpublish」を選びます。

n8nの2.0からは有効・無効の切り替えがなくなり、編集した内容は「Publish」するまで本番に反映されません（出典：n8n Help Center）。

送信のノードだけを止めるなら、そのノードを「Deactivate」で無効にし、公開し直します。止め方の段階を用意しておくと、担当者もためらわずに止められます。

送る前に人が確かめる設計は、送る前に止める業務自動化の設計で紹介しています。

保守を外に頼むときの分担

点検で問題が見つかっても、直す人が決まっていなければ止めたままになります。点検は自社で行い、直す作業は誰が受け持つかを作業ごとに決めておくと、止まる期間を短くできます。

下は分担の一例です。きれいに分かれるものではなく、業者がどこまで受け持つかは契約によるため、自社の契約に合わせて書き換えてください。

作業	自社	業者（契約による）
月次点検と記録	行う	結果を共有してもらう
止める判断	行う（止める権限を持つ）	相談に乗ってもらう
取引先の追加・単価表の更新	自社でできる形にしておく	最初の設定
様式の変更への対応	人による仕分けなどの応急の対応	読み取りの作り直し
ツールやモデルの更新	更新の知らせを受け取る	確かめてから切り替える

n8nを自社サーバーで動かす場合、ツールの更新は自社か業者のどちらかが受け持つことになります。誰が更新するかが決まっていないと、古い版のまま放置されがちです。

保守に含まれる範囲や、伴走の期間の決め方は、次の記事で詳しく扱っています。

点検シートと年に一度の見直し

毎月の点検は短く、年に一度は仕組みそのものを見直します。どちらも、見る項目を決めておくと続けやすくなります。

月次点検は一枚のシートで足りる

点検を続けるこつは、記入する様式を決めて、できるだけ簡単にしておくことです。

点検シートに書く項目は、次の五つで足ります。

• 点検した日と、点検した人
• 三つの数字（処理した件数・人が直した件数・止まった件数）
• 直した理由の内訳
• 点検で気づいたこと
• 決めたこと（続ける・直す・止める）

月初の30分ほどで終わる量に抑えてください（当社の目安）。重い作業にすると、忙しい月に飛ばされ、そのまま続かなくなります。

点検の担当は、2人以上決めてください。1人だけだと、異動や体調不良で一度途切れた途端に、誰も見なくなります。

点検する日は、業務が集中する月末を避け、比較的時間のある月初にするのがおすすめです。

AIのAPIを使っている場合は、その月の利用料も一行書いておくと、件数と費用の変化を並べて見られます。料金の見方は業務用途のLLM使用料金で紹介しています。

年に一度見直すこと

毎月は追わないものの、年に一度は見直したい項目があります。

• APIキーとアクセス権限：不要な権限が残っていないか、期限が近くないか
• ログの保存期間の設定：点検や監査に要る期間を保てているか
• ツールの契約と料金プラン：使っていない上位プランやオプションがないか
• 使っているAIのモデル：提供終了の予定が出ていないか
• 運用の体制と連絡先：異動や退職で、止める権限を持つ人がいなくなっていないか
• 任せている業務そのもの：組織の変更などで、業務自体が要らなくなっていないか

とくに最後の、業務そのものが要るかは見落とされがちです。要らなくなった業務を、AIが効率よく処理し続けていたということも起こりえます。

AIに渡している社内データの範囲も、同じ機会に見直すとよいでしょう。決め方は生成AIに社内データを渡していい範囲で整理しています。

まとめ

AIに任せた業務でいちばん危ないのは、導入したあと放っておかれることです。見た目は正しく動いているため、誰も誤りに気づかないまま影響が広がります。

月初の30分ほどの点検で、半年後に取引先から指摘される前に気づけるようになります。まずは運用を始める月に、「修正の記録」のシートを一枚用意するところから始めてください。

点検で直すところが見つかっても、相談できる相手がいなければ止めたままになってしまいます。

当社（株式会社ニューロシンク）のAIエージェント導入支援は、既存のサービスを組み合わせることを基本に、足りない部分はカスタム開発で補います。

1業務10万円（税別）から、訪問1日で稼働させ、稼働後3か月の伴走と1か月後の訪問まで含みます。月額の保守契約は任意です。