見出し画像

AIで作った自動化ツールは、外部の都合で止まる|僕がやっているのは、失敗メールをAIに見せることだけ

前回の記事では、AIの答えを別のAIにチェックさせる仕組みを1か月半やってみて、やめた話を書きました。

今回は、もう少し地味な話です。AIに頼んで作ったツールを、そのあとどうやって使い続けているか、という話。

「AIでこんなツールを作りました」という記事はたくさんあります。僕自身、何本も書いてきました。でも「作ったツールが、そのあとどうなったか」を書いた記事は、あまり見かけないんですよね。

半年ほど毎日動かし続けてみて分かったことを、先に言ってしまいます。

自動化は、自分が何もしていなくても止まります。 しかも、こちらの都合とは全然関係ないタイミングで。

ただ、これは困った話ではありません。むしろ最近は「そんなに大したことじゃないな」と思うようになりました。今回は、実際にどんな止まり方をしたのか、そのとき僕が何をしているのか、そしてなぜ大したことではないと思えるようになったのかを書いてみます。

いつも通りですが、僕はコードが1行も書けません。全部AIに日本語で伝えて作ってもらっています。


ある朝、59件が全部「要確認」で返ってきた

9月15日の朝の話です。

eBayに出品する商品の候補を毎日自動で探す処理を動かしているんですが、その日の結果を見たら、メルカリの価格を調べる部分だけ、**59件が全部「要確認」**になっていました。

「要確認」というのは、僕が作ったツールの中での印です。「自信がないので人間が見てください」という意味で、自動で処理を進めずに止めてくれます。1件や2件なら普通にあることです。でも59件全部というのは、明らかにおかしい。

前日の14日は正常に終わっています。そして僕は、この部分のコードを8月29日から1行も触っていません。つまり、こちらは何も変えていないのに、一晩で動かなくなったわけです。

調べてもらったら、原因はメルカリ側でした。検索結果ページの作りが変わっていたんです。

変わったのは2つ。1つは、商品タイトルを入れている箱の種類が `span` から `p` というものに変わったこと。もう1つは、画面の外にある商品カードが、スクロールして見えるようになるまで中身が空っぽのままになる作りに変わったことです。

僕のツールは「`span` という箱の中に商品名が入っている」という前提で読みに行っていたので、箱の種類が変わった瞬間、何も読めなくなりました。41枚あったカードのうち26枚が、中身のない「空箱」の状態だったそうです。

ここが面白いところで、見た目は何も変わっていません。僕が普通にメルカリを開いても、昨日と同じ画面が出てきます。変わったのは裏側の作りだけ。人間には気づきようがないけれど、ロボットには致命的、という種類の変化です。



止まる原因は、だいたい自分の外側にある

この半年で起きた「急に動かなくなった」を並べてみると、原因がきれいに分類できました。

  1. 相手サイトのページの作りが変わった(メルカリの検索結果)

  2. 相手サービスが項目を1つ増やした(Amazon広告のダウンロード画面)

  3. 相手サービスのURLが変わった(Amazon広告の管理画面)

  4. 相手から届くデータに、想定外の文字や言葉が混ざっていた(記号だけの単語、見慣れない日付の書き方)

共通しているのは、どれも僕が何かをしたから止まったわけではないということです。相手のサービスが、相手の都合で、こちらに何の断りもなく変わる。

3番のURL変更なんて、本当にそれだけの話です。7月14日、Amazonの広告管理画面のURLが `advertising.amazon.co.jp` から `advertising-japan.amazon.com` に変わりました。

僕が作ったChrome拡張機能は「このURLのページで動く」と指定して作ってあります。なのでURLが変わった瞬間、画面に表示されていたはずの理想入札単価のバッジが、何も言わずに消えました。

直し方は、指定するURLのリストに新しいURLを1行足すだけ。作業時間は5分もかかっていません。


こういうことが続くと、だんだん考え方が変わってきます。何もせずにずっとうまくいくものって、なかなか厳しいんじゃないですかね。

自分の中だけで完結するものなら、仕組みを作れば永遠に動くかもしれません。でも他社が絡んでくるものだと、変更はうちだけじゃなくて、相手側でも起こるわけです。Amazonからデータを取るなら、Amazon上でデータの扱いが変わることもあるし、保存場所が変わることもあるし、アップロードする形式が変わることもある。

だから「壊れないツールを作る」のではなく、変化に対応していく。今はそういうものだと思っています。



「チェック数が4ではありません:5」で、朝5時に止まった

9月9日の朝5時、Amazon広告の自動調整が止まりました。出ていたエラーはこれです。

キャンペーンダウンロードのチェック数が4ではありません:5

Amazonの広告管理画面には、データをダウンロードするときに「何を含めるか」を選ぶチェックボックスがあります。僕のツールは、必要な4つにチェックが入った状態を作ってからダウンロードボタンを押す、という動きをします。

そして押す直前に「本当に4つになっているか」を確認してから進むようにしていました。安全確認ですね。

ところがAmazonが、そのダイアログに「キャンペーンの掲載枠データ」という項目を新しく追加したんです。しかも最初からオンの状態で。結果、チェックが5つになって、僕のツールは「想定と違う」と判断して止まりました。

ここで大事なのは、止まったこと自体は正しい動作だったということです。もしこの確認がなかったら、余計なデータが入ったファイルをそのままアップロードしていたかもしれません。止まってくれたおかげで、実害はゼロでした。

問題は、確認の仕方が「数」だったことの方です。

数で確認していると、相手が1つ足しただけで止まります。しかも、本当に知りたいのは「必要な4つが入っていて、余計なものが入っていないか」であって、「合計が4つかどうか」ではないんですよね。

極端な話、必要な項目が1つ抜けて、要らない項目が1つ入っていたとしても、合計は4つのままです。数を数えるやり方では、この入れ替わりを絶対に見抜けません。

なので、数えるのをやめました。「この名前の項目が入っていること、それ以外は外れていること」を、名前で確認する形に変えたんです。

こうすると、Amazonが今後どれだけ項目を増やしても、知らない項目は自動的にオフに倒れるので止まりません。同じ日の9時21分に直して再実行し、実際の画面で新しい項目がちゃんとオフになるところまで確認できました。



5時間半、静かに空回りしていた話

ここまで「相手が変わるから止まる」という話をしてきましたが、自分側の作りが原因のこともあります。これがいちばん見つけにくい。

7月8日、13時に動くはずだった仕入元の価格チェックが実行されませんでした。

調べてもらったら、朝の8時58分から、ツールを動かしているサーバーが10.4秒ごとに再起動を繰り返していたことが分かりました。起動ログが毎時およそ346件、5時間で1700件を超えていたそうです。

原因は、サーバーを起動する経路が2つあって、その2つが同じ入口を取り合っていたことでした。相手サービスは何も悪くありません。僕の側の作りの問題です。

怖いのは、これがエラー画面として出てこなかったことです。見た目には何も起きていない。パソコンの前に座っていても気づけない。実際には朝からずっと空回りしていました。

幸いこのときは、データを書き込む前の段階で止まっていたので、おかしなデータが残ることはありませんでした。あとで起動の経路を1本にまとめて、二度と取り合いが起きないようにしてもらっています。

ではなぜ気づけたのかというと、13時のジョブが失敗したという通知メールが届いたからです。ここが次の話につながります。



僕の作業は、失敗メールをAIに見せることだけ

正直なところを書きます。

タスクが成功している限り、その後ろにある潜在的なエラーには気がつきません。

たとえばAmazonの広告ツールなら、広告データを取得して、入札単価を調整して、最後までやりきれたら「成功」として扱われます。成功と出ている間は、中で何か危ういことが起きていても、僕には見えません。

その代わり、うまくいかなかったときには必ずメールが届くようにしてあります。失敗したとき、要確認が出たとき、処理が途中で止まったとき。毎日いろいろなタスクがスケジュールで動いているので、日々の僕の仕事は、要するに「うまくいかなかったというメールに対処していく」ことです。

そして、その対処が何かというと——メールの内容を、そのままClaude CodeやCodexのスレッドに貼るだけです。

失敗メールには、ダメだった原因も分かる範囲で書いてあります。それをそのまま投げる。極端な話、メールの内容を言わなくても「このタスクが失敗しました」と伝えるだけでも大丈夫です。

あとはAIが原因を調査して、構造的にどこを改善したらいいのかまで提案してくれて、修正もしてくれます。

僕がやっているのは、メールが届いたらスレッドでAIに教えてあげる、それだけ。だから特別な技術はいらないんじゃないかなと思っています。コードが読めなくても、エラーメッセージの意味が分からなくても、貼り付けることはできますよね。

逆に言うと、この通知を作っていなかったら成立しません。7月8日の5時間半の空回りも、通知メールがなければ何日も気づかなかったはずです。

そして、いちばん厄介だったのは、実は通知が出せなかったケースでした。拡張機能のバッジが消えた件です。エラーは出ません。ただ、あるはずのものが表示されないだけ。これは僕が画面を見て「あれ、出てないな」と思うまで分かりませんでした。

作った当初の僕は、「うまくいく道」しか頼んでいませんでした。今は、それと同じくらいの熱量で「うまくいかなかったときに、どうやって僕に伝わるか」を一緒に頼むようにしています。



その場しのぎで直すと、同じ形でもう一度来る

ただ、AIに任せていれば全部うまくいくかというと、そうでもありません。

同じ不具合が2回出ることがあります。 これはAIのモデルの能力にもよるし、こちらの指示の出し方にもよります。

実際に、まったく同じ形の再発を2件やっています。

1つ目は、記号だけの単語。

Amazon広告の自動調整では、お客さんがAmazonで検索した言葉を取り込んで使っています。その中に、たまに「記号だけの単語」が混ざるんです。

5月31日、「木 □ チップ」という検索語が原因で処理が一部失敗しました。このときの直し方は、「□ のような記号のリストを作って、それが入っていたら除外する」というものでした。

そして8月5日、また同じ形で失敗しました。533件のうち2件。今度の犯人は、半角スペースのうしろに付いたハイフン「-」です。ハイフンは、作った記号リストに入っていませんでした。

2つ目は、日付の書き方。

請求書や領収書のPDFから発行日を読み取って自動で保存するツールがあります。7月11日、AnthropicのPDFで発行日が読めませんでした。このときの直し方も同じで、「Date of issue」「Date paid」といった書き方をリストに追加して解決しています。

そして9月16日、また止まりました。同じAnthropicの、今度は返金のPDF。書いてあったのは「Date issued」でした。「Date of issue」から of が消えて、issue が issued になっただけ。リストに載っていないので読めません。

この2つは、構造がまったく同じです。今回起こった問題には対処したけれど、言葉が少し違うだけで同じように引っかかる直し方をしてしまった。つまり、構造的には直っていなかったわけです。

なので今は、「その場しのぎをやめよう」というより、最初からその場しのぎをやらないように意識しています。

具体的には、修正を頼むときに毎回「この失敗は、必ず同じことが起こらない仕組みで直せるのかどうか」という観点を先に伝えています。目の前の1件を通すことではなく、同じ形が二度と来ない形にすることを目的にしてもらう、という頼み方ですね。


実際、2回目のときはどちらもその方向で直してもらいました。記号の方は「文字も数字も1つも入っていない単語は除外する」という考え方に。日付の方は「発行日っぽい言葉を含んでいて、支払日っぽい言葉を含まない短いラベルなら発行日とみなす」という判定に変えています。どちらもリストが要りません。

ちなみに、こういう変更で怖いのは「直したつもりで、今まで正しく動いていた分まで壊す」ことです。なので日付の方は、これまで正しく処理できていた132件のPDFを変更の前後で全部分類し直して、結果が1件も変わっていないことを確認してから入れ替えました。記号の方も、直近の検索語30,760語に新しいルールを当てて、増える除外が68件(全体の0.22%)に収まることを見てから反映しています。



構造から直せるようになったのは、モデルが変わったからだと思う

この「構造的に直す」というやり方、少し前まではここまでうまくいっていませんでした。

変わった理由は、たぶんAIのモデルの性能が上がってきたことです。

GPT-5.6 Solを使っていた頃と、今のGPT-6 Astra。Claude側も、以前とは別物のOpus 5やFable 5.1が使えるようになりました。過去とはちょっと次元の違うAIが、構造的な問題を調査して、解決策まで提示してくれる。

だから、その場しのぎの対応ではなく、「構造上どこを直したら同じ問題が起こらないか」を出してもらう作業の精度が、かなり高くなったと感じています。このあたりは本当に楽になりました。

以前なら、僕の側で「いや、それだと似た言葉でまた引っかかるのでは」と気づいて指摘しないといけない場面がありました。今はそこまで含めて提案が返ってくることが増えています。



まとめ:変化に対応していけばいいだけ

外部のサービスと連携するツールを作るなら、変化に対応していけばいいだけなので、別に大したことではないと思います。

やることを整理すると、こうなります。

  1. うまくいかなかったときに通知が来るようにしておく(これだけは作るときに一緒に頼んでおく)

  2. 通知が来たら、その内容をAIのスレッドに貼る

  3. あとはAIが調べて、改善策を練って、実装してくれる

  4. 頼むときに「同じことが二度と起こらない形で直せるか」だけ添える

2と4以外、僕の能力を使う場面が正直ほとんどありません。誰でも対処できると思います。すごい時代になりましたよね。

自動化を作ろうと思っている方にお伝えしたいのは、最初の1個目から「うまくいかなかったときにどう気づくか」を一緒に頼んでおくことです。作るときは面倒に感じますが、後から足すよりずっと楽ですし、これがあるかどうかで自動化が「頼れるもの」になるか「たまに黙って嘘をつくもの」になるかが決まります。

止まることを不安に思う必要は、そんなにないんじゃないかなと思っています。

同じように自作ツールを運用している方の参考になれば嬉しいです。

いいなと思ったら応援しよう!

Mutsu チップは自由です。無理せず、気持ちでいただければ嬉しいです。強制ではないので、気軽にお考えください。ありがたくAPIコストに当てさせていただきます。