タグ: ログ管理

AIを使った業務自動化は、うまく動いている時だけを見ると便利です。

問い合わせ内容を分類する。返信案を作る。スプレッドシートへ転記する。担当者へ通知する。社内文書を検索して回答する。毎日の集計をまとめる。

こうした作業が自動で流れると、手作業はかなり減らせます。

ただし、業務で使うAI自動化は「動くこと」だけでは足りません。むしろ差が出るのは、止まった時、間違えた時、判断できなかった時です。

通知が来ないまま処理が止まる。AIが空欄を埋めたつもりで間違える。API制限で処理が途中で落ちる。スプレッドシートには失敗した行だけが残る。誰も気づかず、あとから対応漏れに気づく。

この状態になると、せっかくの自動化が不安の原因になります。

この記事では、小規模事業者や少人数チーム向けに、AI業務自動化を作る前に決めたい「通知・ログ・手動復旧」の設計を整理します。大きな監視システムを作る話ではなく、問い合わせ対応、スプレッドシート連携、RAG、社内AIチャット、小型ツール開発で最低限決めておきたい運用設計です。

AI自動化は「成功時」より「失敗時」の設計で使いやすさが決まる

AI自動化の相談では、最初に「何を自動化するか」が話題になります。

• 問い合わせメールをAIで分類したい
• 返信文の下書きを作りたい
• フォーム内容をスプレッドシートへ整理したい
• 社内文書をRAGで検索できるようにしたい
• 毎日の作業報告を自動でまとめたい

もちろん、何を自動化するかは重要です。ただ、業務で使い続けるには「うまくいかなかった時にどうするか」も同じくらい重要です。

AIや外部サービスを使う仕組みでは、次のようなことが起きます。

• 入力データが足りない
• AIの出力が期待した形式にならない
• APIの利用制限や通信エラーで止まる
• 参照すべき文書が見つからない
• 同じ処理が二重に実行される
• 担当者が確認すべき内容まで自動送信される
• どのデータで失敗したのか後から分からない

こうした失敗は、AIが悪いというより、運用設計が足りない時に表面化します。

最初から完璧な仕組みを作る必要はありません。ただし、通知、ログ、止め方、戻し方だけは小さく決めておくべきです。

まず決めたい5つの運用ルール

AI業務自動化を小さく始める場合でも、最低限次の5つを決めておくと、運用で困りにくくなります。

1. 失敗した時に誰へ通知するか

エラーが起きた時、誰が気づくべきかを決めます。

代表者、担当者、制作側、社内の管理者など、通知先を曖昧にすると対応が遅れます。

通知先は一つに固定する必要はありません。軽いエラーは担当者へ、連続失敗は管理者へ、重要な処理の停止は代表者へ、というように分けることもできます。

2. どの状態なら止めるか

すべてのエラーで処理を止めると、運用が重くなります。逆に、危険な状態でも止めないと事故につながります。

たとえば、次のように分けます。

• 入力不足: 処理を止めて要確認にする
• AIの出力形式が崩れた: 自動送信せず下書きとして保存する
• API制限: 一定時間後に再実行する
• 個人情報や禁止ワードを検出: 即停止して担当者へ通知する
• 参照元が見つからない: 回答せず「確認が必要」にする

「止める条件」を先に決めておくと、AIに任せすぎる事故を減らせます。

3. 何をログに残すか

ログとは、あとから見返すための記録です。

失敗した時に必要なのは、長い技術ログだけではありません。現場が確認できるログも必要です。

たとえば、問い合わせ分類AIなら次の情報を残します。

• 処理日時
• 対象の問い合わせID
• AIが選んだカテゴリ
• AIの判断理由
• 成功、要確認、失敗などの状態
• 担当者が修正した内容
• 再実行した日時

個人情報を含むログは扱いに注意が必要です。必要な情報だけ残し、氏名やメールアドレスをそのまま残さなくても確認できる形にすることが大切です。

4. 人が直せる場所を用意するか

AI自動化は、人が修正できない仕組みにすると怖くなります。

たとえば、AIが分類した結果をそのまま確定するのではなく、管理画面やスプレッドシートで人がカテゴリを変更できるようにします。

返信文も、いきなり送信するのではなく、最初は下書き保存にして人が確認する方が安全です。

重要なのは、失敗時に「開発者に連絡しないと何もできない」状態を避けることです。小型ツールでも、現場が直せる項目を少し用意するだけで運用しやすくなります。

5. 再実行できるか

AI自動化では、再実行の設計がよく抜けます。

処理が途中で止まった時、最初から全部やり直すのか、失敗した行だけ再実行するのか、二重送信を防ぐのかを決めておく必要があります。

たとえば、問い合わせ対応なら「返信メールは自動送信せず下書きまで」「管理表への記録は問い合わせIDで重複チェック」「失敗した行だけ再実行ボタンを押せる」といった設計が考えられます。

再実行できる仕組みがあると、運用中の小さな失敗を怖がらずに改善できます。

エラーを3段階に分けると通知がうるさくならない

通知を作る時にありがちな失敗は、何でも通知してしまうことです。

毎回小さな警告が届くと、重要なエラーまで見逃されます。逆に、通知を絞りすぎると、本当に止まった時に誰も気づきません。

最初は、エラーを3段階に分けると整理しやすくなります。

レベル1: 記録だけでよいもの

すぐに対応しなくてもよい軽いエラーです。

たとえば、任意項目が空欄だった、AIの要約が短かった、通知先が一時的に不在だったなどです。

この段階では、ログに残すだけで十分なことがあります。

レベル2: 担当者確認が必要なもの

人が確認すれば進められる状態です。

たとえば、相談カテゴリが判断できない、返信文に不安な表現がある、参照元の文書が複数あり判断に迷う、といったケースです。

この場合は、自動処理を止めて「要確認」として残し、担当者へ通知します。

レベル3: すぐ止めるべきもの

放置すると事故につながる可能性がある状態です。

たとえば、個人情報を含む内容を外部送信しそうになった、認証エラーが連続している、同じメールを複数回送信しそうになった、AIの出力形式が完全に崩れている、といったケースです。

この場合は、処理を止め、管理者へ通知し、再実行前に原因を確認します。

ログは開発者向けと現場向けを分ける

ログというと、英数字が並ぶ開発者向けの記録を想像するかもしれません。

しかし、小規模な業務自動化では、現場が読めるログも重要です。

開発者向けログには、APIのエラー内容、処理時間、プログラム上の例外、使用したモデルやプロンプトのバージョンなどを残します。

一方で、現場向けログには、次のような情報を残します。

• どの問い合わせや行で止まったか
• 何が足りなかったか
• AIがどう判断したか
• 人が確認すべき点は何か
• 次に押すべき操作は何か

現場向けログの例:

「問い合わせID 1042 は、希望納期と予算が未入力のため自動返信を停止しました。担当者が内容を確認し、必要情報を追記してから返信下書きを再作成してください。」

このように書いてあれば、技術者でなくても次の対応が分かります。

AI自動化のログは、原因調査だけでなく、現場の行動を迷わせないためのものです。

RAGや社内AIチャットでは「答えられない時」の扱いを決める

ローカルLLMやRAGを使った社内AIチャットでも、失敗時設計は重要です。

RAGでは、AIが社内文書を参照して回答します。ただし、いつも正しい文書が見つかるとは限りません。

次のようなケースがあります。

• 該当する社内文書がない
• 古い文書と新しい文書が両方見つかる
• 権限上、参照してはいけない文書が含まれる
• 質問が曖昧で、検索結果が広がりすぎる
• 回答の根拠として使える文章が短すぎる

この時に、AIがそれらしい回答を作ってしまうと危険です。

RAGや社内AIチャットでは、次のようなルールを決めておきます。

• 参照元が見つからない時は「分かりません」と返す
• 古い文書が混ざる時は更新日を表示する
• 参照元リンクを必ず出す
• 権限が不明な文書は回答に使わない
• 回答できない質問をログに残し、文書整備の候補にする

AIが答えられなかった記録は、失敗ではなく改善材料です。どんな質問に答えられなかったかを残すことで、FAQや社内文書の不足が見えてきます。

小型ツールなら「状態」を見えるようにする

業務自動化を小型ツールとして作る場合、管理画面やスプレッドシートに「状態」を出すだけで運用しやすくなります。

たとえば、次のような状態です。

• 未処理
• 処理中
• 要確認
• 下書き作成済み
• 処理済み
• 失敗
• 再実行待ち

状態が見えると、担当者は「今どこで止まっているか」を確認できます。

逆に、裏側だけで自動処理が動いていると、止まった時に何が起きたのか分かりません。

最初から立派なダッシュボードを作る必要はありません。スプレッドシートの列に状態、エラー内容、最終更新日時、担当者メモを追加するだけでも、かなり運用しやすくなります。

最初に作るなら「失敗した1件だけ直せる」形にする

AI自動化を最初に作る時は、大きな全自動システムを目指すより、失敗した1件を直せる形にするのがおすすめです。

たとえば、問い合わせ返信の下書き化なら、次のような小さな仕組みから始めます。

• 問い合わせを1件ずつ管理表に取り込む
• AIが相談カテゴリと不足情報を出す
• 返信文は下書きとして保存する
• 不安な場合は「要確認」にする
• 担当者が修正して再実行できる

この形なら、いきなり自動送信しなくても業務負担を減らせます。

慣れてきたら、通知先を増やす、集計を追加する、RAGで過去事例を参照する、管理画面を作る、というように広げられます。

AI自動化の価値は、全部を一気に任せることではありません。人が安心して使える範囲を少しずつ増やすことです。

相談前に整理しておくチェックリスト

AI業務自動化や小型ツール開発を相談する前に、次の項目を整理しておくと話が進めやすくなります。

• 自動化したい作業は何か
• 入力データはどこから来るか
• AIに任せたい判断は何か
• 人が確認すべき判断は何か
• 失敗した時に誰へ通知するか
• どの状態なら処理を止めるか
• どんなログを残したいか
• 再実行したい単位は1件ごとか、まとめてか
• 個人情報や機密情報をどう扱うか
• 最初は下書き運用でよいか、自動送信まで必要か

このチェックリストがあるだけで、AI自動化の相談はかなり具体的になります。

「何でも自動化したい」ではなく、「この入力を受け取り、この判断をAIにさせ、失敗時はここで止めたい」と言えるようになるからです。

YOSHIO.devで相談できること

YOSHIO.devでは、業務自動化、ローカルLLM・RAG環境構築、小型ツール開発、問い合わせ対応やスプレッドシート連携の相談ができます。

AIを使った自動化では、プロンプトやモデル選びだけでなく、通知、ログ、止め方、再実行、手動確認の設計が重要です。

最初から大きなシステムにしなくても、問い合わせ1件、スプレッドシート1行、RAGの質問1件から小さく試せます。失敗時に戻せる設計にしておけば、運用しながら改善しやすくなります。

よくある質問