AI自動化でエラーが10回。原因を数え直したら3つだった
AIで仕事を自動化していると、エラーが続くだけで不安になる。
1回失敗する。別の方法を試す。また失敗する。気づけば、何を直しているのか分からないまま試行回数だけが増えていく。
Work Shift Labで前回の記事を自動投稿したとき、投稿までの工程で10件のエラーが発生した。
ただし、記事の公開には成功した。タイトル、本文、画像、タグ、無料設定も公開ページで確認できた。10件はいずれも投稿前に解消し、公開内容への影響はなかった。
それでも、「最後に公開できたから問題なし」では終わらせなかった。
10件を一つずつ見直すと、別々の原因が10個あったわけではない。根本までたどると、3つにまとめられた。
今回は、AI自動化でエラーが増えたときに、直す場所を絞る方法を紹介する。
01｜エラー件数と、原因の数は同じではない
前回記録した10件の内訳は、次のとおりだった。
記事本文の入力と書式設定で8件
ブラウザを動かす準備で1件
パソコン上の補助処理を始める場面で1件
表面だけを見ると、エラーは10件ある。
しかし、本文入力の8件は、8個の独立した問題ではなかった。最初に選んだ方法がうまく動かず、別の入力方法を続けて試したことで回数が増えていた。
最終的には、見出しや箇条書きを保った本文全体を、一度に貼り付ける方法で成功した。
つまり本文入力について直すべきだったのは、8個のエラーではない。
「成功実績のある入力方法を最初に選ばなかった」という一つの運用だった。
02｜10件を3つの根本原因へまとめた
今回の10件は、次の3つにまとめた。
1｜本文入力の方法を固定していなかった
本文と書式を入れるため、成立しない方法を切り替えながら試していた。これが8件を占めた。
最後に成功したのは、本文全体を見出しやリストの形を保ったまま一括で貼り付ける方法だった。
そこで次回からは、この成功方法を最初に使うことにした。
2｜ブラウザを動かす場所の指定を間違えた
ブラウザ操作の準備では、必要なファイルの場所を誤って指定し、1回止まった。
正しい場所を確認してから指定すると進めた。
次回は、場所を推測せず、存在を確認した場所だけを使う。
3｜パソコンの設定を前提にしていた
補助処理では、必要な実行環境がいつもの場所にある前提で動かし、1回失敗した。
実際に使える場所を確認し、そこを明示すると処理できた。
ここでも対策は同じだ。環境を推測せず、確認した情報を使う。
10件をこの3つに分けると、直すべき場所が見えた。
件数を10から0へ一気に減らそうとするのではなく、最も多かった一つの原因から直せばよい。
03｜エラーを5項目で記録する
エラーが起きた直後は、画面に出た文章だけを残しがちだ。
しかし、エラーメッセージだけでは、同じ原因かどうかを後から判断しにくい。
最低限、次の5項目を残す。
起きた現象
発生した工程
過去の失敗と同じ原因か
最終的に成功した方法
次回最初に使う方法、または停止する条件
たとえば本文入力なら、次のように記録できる。
起きた現象：本文や書式の入力が成立しなかった
発生した工程：完成原稿を記事編集画面へ入れる工程
同じ原因か：入力方法を変えながら試した一連の失敗
成功した方法：本文全体を一括で貼り付けた
次回のルール：成功した方法を最初に使い、1回失敗したら別方式を連続で試さない
この形なら、「エラーが8回出た」という記録が、「次回どこを変えるか」という判断につながる。
04｜失敗のたびに方法を増やさない
AIを使うと、すぐに別案を出してくれる。
一つ目が失敗したら二つ目。二つ目が失敗したら三つ目。選択肢が多いこと自体は便利だ。
ただし、実際の仕事では試行回数が増えるほどよいとは限らない。
同じ工程で似た失敗を繰り返すと、人間の確認時間が増え、どの方法が正式なのかも分かりにくくなる。
そこで、成功した方法が見つかったら次の運用へ変える。
次回の第一候補として固定する
既知の失敗方法を通常手順から外す
第一候補が1回失敗したら、自動で別案を試し続けない
事実を確認できない場合は止める
大切なのは、失敗を隠すことではない。
失敗から、次回の選択肢を減らすことだ。
05｜営業メールや資料作成でも使える
この整理法は、記事の自動投稿だけのものではない。
たとえばAIに営業メールを作らせたとする。
会社名の表記が違う。日付が違う。添付資料の名前が違う。文面の雰囲気も合わない。
これを4件の別問題として直す前に、発生工程と原因を分ける。
会社名、日付、資料名の違いは、「AIへ渡した元情報が古い」という一つの原因かもしれない。文面だけは、「相手や目的の指定が不足している」という別原因かもしれない。
もし確認できれば、直す場所は4か所ではなく2か所になる。
ただし、原因が同じだと確認できないものを無理にまとめてはいけない。証拠が足りなければ、原因不明として残す。
きれいな説明を作るより、分からないことを分からないまま残す方が、次の検証では役に立つ。
06｜明日は、エラーを数える前に一つの表を作る
AIを使う仕事で最近起きた失敗を一つ選ぶ。
そして、次の形で書き出す。
起きた現象：
発生した工程：
同じ原因と思われる過去の失敗：
最終的に成功した方法：
次回最初に使う方法、または停止条件：
同じ工程、同じ操作、同じ回避方法なら、一つの原因としてまとめられないか確認する。
確認できなければ、無理にまとめない。
AI自動化を育てるとき、エラー回数は大切な記録になる。
でも、10回のエラーを10回分の別問題として直す必要はない。
まず、同じ原因で起きた失敗をまとめる。次に、成功した方法を第一候補へ固定する。そして、同じ失敗を繰り返す前に止まる条件を決める。
エラーを減らす最初の一歩は、試す方法を増やすことではない。
直すべき原因を減らすことである。
