AIに任せて失敗したことと、直したルール

AIエージェントに仕事を任せる話をすると、「便利そう」と言われることが多いです。実際便利なのですが、失敗もしました。

この記事では、実際にやってしまった失敗と、そこから直したルールを書きます。失敗談は格好悪いですが、「どこでつまずくか」を先に知っておくと、同じ失敗を避けられます。自分の失敗がその役に立てば、失敗した甲斐があります。

失敗1：説明文の改行が崩れたまま出品した

一番痛かった失敗です。不用品の出品で、AIに作ってもらった説明文をそのまま使って出品したら、公開されたページでは改行が崩れて、文章が全部つながって表示されてしまいました。

結果、出品を取り消して、直してから再出品する羽目になりました。二度手間になっただけでなく、出品のタイミングも逃しました。

取り消しと再出品自体はすぐできますが、時間とタイミングを失いました。出品は「勢いのある時間帯」に出す意味があるので、出し直しは静かなダメージです。

原因は単純で、自分の確認不足です。「下書きを作ってもらった」という安心感で、公開された状態での見え方まで確認していませんでした。作る画面で正しく見えても、公開ページで同じに見えるとは限りません。

直したルール：公開は「公開後の画面」で確認する

この失敗からは、ルールを1つ作りました。文章や出品物は、公開ボタンの前だけでなく、公開された実際の画面で表示を確認して初めて完了とすること。特に改行や装飾は、編集画面と公開画面で見え方が違うことがあるので、必ず実物を見ます。

失敗2：頼み方が曖昧で、的外れな調査が返ってきた

初期の頃の失敗です。「副業の案件を調べて」とだけ頼んだら、条件に合わない案件ばかりが大量に返ってきました。当然です。何を重視して、何を外すべきかを伝えていなかったので、AIには判断のしようがありませんでした。

「AIの調査は使えない」と一瞬思いましたが、使えなかったのは頼み方の方でした。

当時の頼み方を振り返ると、「条件」を何も渡していませんでした。無料で始められること、過去に使ったことがあるものは除くこと、そういう自分の前提が、自分の頭の中にしかなかったのです。頭の中の前提は、書かなければ伝わりません。当たり前のことですが、「言わなくても分かるだろう」という思い込みが、この失敗の正体でした。人に仕事を頼むときと同じで、前提は言葉にして渡すものです。

直したルール：目的・条件・形式をセットで渡す

それ以降、調査を頼むときは「目的（何に使うか）」「条件（外すもの・重視するもの）」「形式（一覧にして合う・合わないで分ける）」をセットで渡すようにしました。これで的外れは激減しました。今ではこの頼み方を「型」として保存して使い回しています。

失敗3：形式を指定せず、長い文章を読み直す羽目になった

文章の下書きを頼んだときの失敗です。「書いて」とだけ頼んだら、長くて立派な文章が返ってきました。ところが、そのままでは使えません。自分の体験は入っていないし、言葉の癖も違う。結局、全文を読み直して、使える部分を拾って、書き直すことになりました。

「書いてもらったのに、書くより時間がかかった」という本末転倒です。原因は、返す形を指定していなかったことでした。

直したルール：下書きは「構成＋空欄」で頼む

それ以降、下書きは「見出しの構成を作って、体験を書く部分は空欄にしておいて」という形で頼むようにしました。AIに任せるのは骨組みと一般論の部分で、体験と判断は自分が書く。この分担にしてから、下書きは本当に「たたき台」として機能するようになりました。

頼み方の「形式」を指定することは、AIの出力を絞ることではなく、自分の後工程（読み直し・書き直し）の手間を先に消しておくことだと学びました。

失敗4：「任せたのに楽にならない」時期があった

地味ですが長く続いた失敗です。任せ始めた頃、AIの出した結果を確認するのに時間がかかって、「自分でやった方が早いのでは」と感じることがよくありました。

任せる量を増やすほど確認の量も増えるので、設計なしに任せると、仕事が「やる作業」から「確認する作業」に変わるだけで、総量は減りません。

直したルール：承認ラインを決めて、確認する場所を固定する

直し方は、任せる範囲を3段階に分けることでした。

• 間違えても実害がない作業（下調べ・観測・整理）は、確認を最小限にして任せる
• 文章や出品物は「下書きまで」。公開前に必ず自分が確認する
• お金が動くこと・公開・連絡は、必ず自分が最後に実行する

確認すべき場所が固定されると、「全部を不安で確認する」ことがなくなり、やっと楽になりました。任せるとは、確認をなくすことではなく、確認する場所を決めることだと分かりました。

失敗から分かった共通点

4つの失敗に共通しているのは、どれも「AIの能力」の問題ではなく、「任せる側の設計」の問題だったことです。

• 公開後の確認を決めていなかった
• 頼み方の条件を渡していなかった
• 返す形式を指定していなかった
• 確認する場所を決めていなかった

逆に言えば、設計さえ直せば、同じ失敗は繰り返しませんでした。AIに任せる作業は、任せる前の設計と、任せた後の確認の場所決めが本体で、AIの作業自体はその真ん中にあるだけ、という感覚です。

失敗は「直したルール」まで書いて残す

失敗談を書くもう一つの理由は、失敗そのものより「直したルール」の方が資産になるからです。

失敗は時間が経つと忘れます。でも、「公開は公開後の画面で確認する」のようなルールは、文章として残しておけば、次に似た作業をするときにそのまま使えます。自分は失敗するたびに、「何が起きたか」だけでなく「次からどうするか」を一文で書いて、一覧にしておくようにしました。

この一覧は、後から読み返すと結構面白いです。「あの失敗があったからこのルールがある」という対応が見えるので、失敗が「ただの損」ではなく「ルールの発生源」に変わります。失敗を面白がる、という考え方にも通じる部分です。

そして、この記事自体もその一覧から生まれました。失敗を記録しておく習慣がなければ、今日こうして書く材料もなかったわけで、失敗の「二次利用」としてはなかなか良い回収だと思っています。

失敗も含めた実験の数字と、その後の0→1への挑戦は、ブログとnoteで連載しています。まずはこちらから。

『AIに稼がせる実験、最初の1週間でやったこと』／ 全収支はnote → https://note.com/aiiomo/n/nc60b2ed77b34