私が作ったメルマガ配信の仕組みには、こういう作りが混ざっていました。メールの送信に失敗した読者を、自動で「配信停止」に回す。一見すると、まっとうな処理に見えます。
こんにちは。AIでDXを加速する専門家、ばんのです。
この作りの何が危ないかというと、失敗の原因が読者側にあるのか、こちら側にあるのかを区別していなかった点です。もし送信元のサーバーが一時的に止まれば、その瞬間に配信中の全員が同時に失敗します。そして全員が配信停止に回されます。読者名簿が、一晩で空になるということです。
この作りは、実際に事故を起こす前に見つけて直しました。ただし、動かして見つけたのではありません。普通に使っている限り、この処理は正しく動いてしまうからです。
第1回では、既製の配信ツールを使わずに自作を選んだ理由を書きました。第2回は、その続きです。AIが書いたコードを、私がどうやって確かめているのか。コードを一行ずつ読み込むのとは違う方法なので、プログラミングの経験がない方でもそのまま使える手順になっています。
この記事を読むとわかること
- AIが書いたコードの、いちばん危ない壊れ方
- 「動いたから大丈夫」が通用しない理由
- 私が毎回踏んでいる、4つの確認手順
- 実際に監査で出てきた指摘の中身
AIが書くコードは「だいたい正しい」から危ない
誤解されがちですが、AIが書くコードは雑ではありません。むしろ、指示した内容についてはきちんと動くものが出てきます。私が指示を出す立場で8週間やってみて、そこは信頼できると感じています。
問題は、指示していないことです。
私が出した指示は「送信に失敗した人には、それ以上メールを送らないで」でした。これは正しい要望です。存在しないアドレスに送り続けると、送信元の評価が下がって、まともな読者にもメールが届かなくなるからです。
AIはこの指示どおりのものを作りました。私も「そのとおりのものが来た」と確認しました。ここまでは何も間違っていません。
抜けていたのは、私の指示のほうです。「失敗」には2種類あることを、私が言っていませんでした。
| 失敗の種類 | 例 | 正しい対応 |
|---|---|---|
| 相手側の問題 | アドレスが存在しない 退会済み | 以降、その人には送らない |
| こちら側の問題 | 送信サーバの不調 送信元IPが一時的にブロックされた | 時間をおいて送り直す |
この2つを区別せずに「失敗したら配信停止」とすると、こちら側の障害で名簿が消えます。しかも厄介なのは、この違いが平常時にはまったく表に出てこないことです。送信が成功している限り、どちらの処理も呼ばれません。テスト登録して一通り動かしても、当然のように全部通ります。
動かして確かめるという方法は、こういう作りに対して無力です。壊れるのは、うまくいかなかった日だけだからです。
私が毎回踏んでいる4つの手順
そこで、コードの中身を追わなくても実行できる形に手順を決めました。メールを送る部分やお金に関わる部分では、毎回この4つを踏んでいます。
手順1. 作らせる前に「どう壊れるか」を言葉にする
機能を頼む前に、私はAIに一度こう聞きます。「この機能が最悪の壊れ方をすると、何が起きますか」。
これはコードを書かせる質問ではありません。危ないところを先に洗い出すための質問です。今回の例でいえば、ここで「送信元側の障害と宛先側の問題を取り違えると、全員が配信停止になります」という答えが出てきます。
出てきた壊れ方は、そのまま次の指示に足します。「こちら側の障害では読者を止めないこと」という一文が仕様に入れば、AIはそれを守って書きます。指示に入っていないことは守られない、というだけの話です。
手順2. 書かせるAIと、検査するAIを分ける
これがいちばん効きました。
書いた本人に「これで合っていますか」と聞くと、たいてい「合っています」と返ってきます。人間と同じです。自分の書いたものの粗は見えません。
なので私は、コードを書く役と、それを検査する役を、別々に立てています。検査役には「直さなくていいので、危ないところだけ挙げてください」と伝えます。修正権限を与えないのがポイントで、直す側に回ると「直したから大丈夫」で話が終わってしまうからです。
そして、1周では終わりません。冒頭で書いた配信停止の件は、検査を4周させてようやく指摘が出尽くしました。1周目で直した箇所が、2周目で別の問題を生む。それを直すと3周目で今度は違う角度の指摘が出る。この繰り返しです。
読者からの返信を受け取る機能では、6周かかりました。指摘がゼロで返ってくるまで回す、と決めています。
手順3. 直す前に、わざと失敗させて確かめる
ここが、私が途中から入れた工程です。
問題が見つかったら、修正を頼む前に、まず「その問題が起きたときに警告を出す仕掛け」を作らせます。今回でいえば、送信をわざと失敗させて、送信元側の障害を模した応答を返す仕掛けです。
そのうえで、修正前の状態で一度動かします。ここで警告が出れば、問題が実在することの証明になります。出なければ、そもそも私の理解が間違っていたということです。
この順番を守ると、見せかけの修正を弾けます。実際、AIから「修正しました」と返ってきたもののうち2件が、この工程で「直っていない」と判明しました。修正を先にやっていたら、私は気づかずに本番へ上げていたはずです。
直す前に赤信号が点くのを自分の目で見る。この一手間だけで、確認の精度がまるで変わります。
手順4. 確認の仕掛けを、捨てずに残す
手順3で作った仕掛けは、確認が終わっても消しません。ファイルとして残しておきます。
半年後に別の機能を足したとき、この仕掛けをもう一度走らせれば、昔直した問題が復活していないかを数十秒で確認できます。自分で作ったものを長く使うつもりなら、ここは省かないほうがいいところです。今のところ、この確認用のコードが約2,300行たまっています。
検査で実際に出てきた指摘
4周の検査で何が出てきたのか、非エンジニアの方にも中身が伝わるものを3つ挙げます。どれも、動かしただけでは絶対に見つからないものです。
1. 相手のサーバーが書いた文章を、信じて判断していた
メールの送信に失敗すると、相手のサーバーからエラーの文章が返ってきます。最初の作りは、その文章に特定の単語が入っているかどうかで「読者側の問題」かを判断していました。
ですがこの文章は、こちらが書いたものではありません。相手が自由に書けるものです。検査で出てきた指摘はこうでした。送信元のIPアドレスがブロックリストに載ると、すべての宛先から同じ文言が同時に返ってくる。その文言が判定条件に引っかかると、名簿全員が一度に配信停止になる。
結局、判定はエラーに付く決められた番号のうち「宛先が存在しない」を意味するものだけに絞りました。他人が書いた文章を、自分の重要な判断材料にしないという話です。
2. 再送が、自分自身を数えていた
「短時間に大量の失敗が出たら、送信を止めて様子を見る」という安全装置を入れました。これ自体は正しい設計です。
ところが、この失敗の件数に、再送の失敗まで含めていました。すると、再送が失敗する、件数が増える、安全装置が働いて止まる、また再送する、という輪ができます。安全装置が、自分の作った失敗で自分を止め続けるわけです。
数えるのは最初の1回の失敗だけ、という一行の条件で解決しました。ただ、この輪は図に描いてもらうまで私には見えませんでした。
3. 上限を増やしたら、過去に打ち切ったものが復活した
再送を試す回数の上限を、5回から20回に増やしました。数字を1つ変えるだけの、いちばん安全に見える変更です。
ここで出た指摘が「過去に5回で打ち切った古い記録が、上限を20回にした瞬間にすべて対象へ戻ります」でした。何ヶ月も前に配信を諦めたメールが、まとめて送信されるということです。
数字を変えるだけの変更が、過去のデータに遡って効く。この種の副作用は、言われるまで発想そのものがありませんでした。
結局、何を確かめているのか
4つの手順を並べましたが、やっていることを一言でまとめると、コードの中身ではなく壊れ方を確かめているということです。
17,000行を一行ずつ読んで正しさを保証するのは、現実的ではありません。仮に全部読めたとしても、今回のような不具合は、その一行だけを見ても正しく見えるので気づけません。ですが「送信元が一時的に止まったとき、読者名簿はどうなるのか」という問いなら、コードを開かずに立てられます。そして、その答えは実際に失敗させてみれば目で確認できます。
AIと作るときに効いてくるのは、コードを読む力よりも、この問いを出す力のほうでした。
よくある質問
Q1. 検査を4周も回すと、時間がかかりませんか
かかります。ただし、私が待っているだけの時間です。指示を出したら別の作業に戻れるので、体感の負担は思ったほどではありません。むしろ、事故が起きてから読者に謝る時間のほうがはるかに高くつきます。
なお、全部の変更でこれをやっているわけではありません。画面の文言を直すだけの変更なら、そのまま反映します。メールの送信と読者データに触るときだけ、必ず全工程を踏むと決めています。
Q2. 検査役のAIは、何か特別なものを使っているのですか
同じAIです。役割を変えて呼んでいるだけです。「あなたは検査担当です。修正はせず、危険な箇所とその理由だけを報告してください」と伝えれば、それらしく振る舞ってくれます。
大事なのはAIの種類ではなく、書いた側に採点させないことです。
Q3. 指摘が正しいかどうかは、どう判断するのですか
判断しません。手順3で確かめます。
指摘が来たら「その問題が本当に起きるところを見せてください」と返します。実際に再現できれば本物ですし、再現できなければ取り下げになります。ここを議論で決めようとすると、私に判断材料がないので必ず押し切られます。
Q4. それでもバグが残ることはありますか
あります。この記事で紹介した仕組みも、そもそもは運用の途中で作り直したものです。最初から完璧なものを作る方法は、私は知りません。
やっているのは、取り返しがつく失敗と、つかない失敗を分けることです。読者名簿が消えるのは後者なので、そこには時間をかけます。
ばんのの視点：AIに聞くべきは「作って」より「どう壊れるか」
バイブコーディングの話題は「こんなものが作れた」に集まりがちです。実際、作るところはもう驚くほど簡単になりました。私も8週間で17,000行のものを作れています。
ですが、自分の仕事で使う道具として置くなら、作れることと任せられることは別の話です。そして両者を分けるのは、コードを書く力ではなく、壊れ方を先に想像する力でした。これは業務の中身を知っている人のほうが得意な領域です。「このデータが消えたら何が困るか」は、AIより私のほうがよくわかっています。
何かを作らせるとき、指示を出す前に一度だけ「これが最悪の壊れ方をすると、何が起きますか」と聞いてみてください。私が8週間で覚えたことの中で、これが最も費用対効果の高い一言でした。
次回予告
第3回は、メールを受け取る側の話です。
配信システムを作ると、当然ながら読者から返信が来ます。それを管理画面で読めるようにしたところ、送信元を偽ったメールが混ざり込むという、想定していなかった問題にぶつかりました。差出人の欄は、誰でも好きな文字を書けてしまうからです。
本物の返信だけを通すために何を確認すればいいのか。ここでも設計を何度も間違えたので、その記録をお届けします。
【公開しました】第3回：本物の返信だけを通すために、設計を4回間違えた話
