AI開発で起きやすい「動くけれど仕様と違う」を3層で防ぐ

先日、更新ログのページで見つけたものです。掲載を終えた回のURLを開くと、正しく別のページへ転送されます。ところが、そのページの共有カード画像だけは、同じURLで普通に画像を返していました。

ページ側は「無ければ404」と書いてあり、画像側は「無ければ汎用の絵を出す」と書いてありました。どちらも単体では筋が通っています。並べて初めて食い違いになります。

厄介なのは、画面を開いても何も起きないことです。エラーも出ず、見た目も崩れません。気づいたのは、検索エンジンの管理画面に「404でインデックスできなかったページ」として上がってきたときでした。

しかも、この作りだと適当な文字列でも画像が返ります。クロールできるURLが際限なく生えている状態でした。

見つけたあとに確かめたら、掲載を終えた回のぶんも、でたらめな文字列も、全部同じように画像を返していました。どれも一度も画面には出ていません。リンクが張られていないので、こちらから辿る経路が無いからです。

頼み方が悪かったわけではありません。「無いときは汎用の絵を返して」は、その場では妥当な指示です。そのとき見ていた範囲では正しかっただけです。

AIに限らず、自分一人で書いても同じことは起きます。違うのは速さです。短い時間で多くの場所を直せるぶん、こうした食い違いが増える速度も上がります。

だから対策は「気をつける」ではありません。気をつけられる量を超えるから起きているので、気をつける量を増やしても追いつきません。

もう一つ、気づきにくくしている要因があります。この種の食い違いは、片方だけを見ているかぎり正しく見えることです。ページの実装を読んでも問題はありませんし、画像の実装を読んでも問題はありません。レビューの単位がファイルだと、並べる機会がそもそも来ません。

私が見つけられたのは、外から来た報告がきっかけでした。自分の中から出てきた疑問ではありません。ここは正直に書いておきます。

この件から学んだのは、食い違いは片方を読んでいても出てこないということでした。だから対策も、読む量を増やす方向ではなく、並べて照らす仕掛けを置く方向になります。

頼む時点で「終わったと言える状態」を決めておくと、あとから照らせます。

「動くこと」では足りません。どのコマンドが通ればよいか、どのURLを開いて何が返ればよいかまで落とします。さきほどの例なら、「ページと画像の応答が一致すること」と書いてあれば、渡した時点で防げました。

コツは、条件を機械が読める形にしておくことでした。「正しく動く」では照らせませんが、「このURLは404を返す」なら、あとからコマンド一つで確かめられます。書いた条件がそのまま検査になります。

決め方はAIにコードを書かせる前に決めるべき5つと、その置き場所にまとめています。この記事はその先、決めたのに食い違ったときの話です。

条件を先に書くもう一つの効用は、渡す前に自分が気づけることです。「終わったと言える状態」を書こうとして書けないなら、そこはまだ決まっていません。渡してから決まっていないと分かるより、ずっと安く済みます。

「直しました」「公開しました」という報告は、そのまま受け取らないようにしています。完了の表示が保証しているのは、操作が終わったことだけだからです。

似たことがストアへの提出でもありました。審査へ出したあとに中身を数えたら、アプリの版だけが入っていて、購入まわりの商品が一緒に入っていませんでした。提出の完了画面は普通に出ていて、押した本人からは何も見えません。

受け取り方を変えました。直したと言われたら検査を通す、公開したと言われたら実際のURLを外から開く。これだけで取りこぼしはかなり減りました。

手元で確かめるだけでは足りない場面もあります。手元では正しくても、配信されたあとの設定が違えば結果は変わるからです。外へ出したものは、必ず外から見にいきます。

• 報告ではなく、成果物そのものを見る。
• 外へ出したものは、外から開いて確かめる。
• 数えられるものは数える。「できた」で終わらせない。

一番効いたのはこれです。確認を増やすのではなく、確認しなくても落ちる仕組みへ移しました。

このサイトには、ビルドを止める検査が6本あります。表紙画像の寸法と重複、本文の文字数、公開日時の書式、更新ログと台帳の一致、リンクの行き先、画面のはみ出しと文字の切れ。どれか一つでも食い違うと、ビルドが失敗します。

移す基準は決めています。間違えたときに自分で気づけるかどうかです。画面が真っ白になる類は放っておいても気づくので、検査にしません。気づけないのは、見た目が正常なまま中身だけ違っているとき。そこだけ機械に回せば、検査は増えすぎません。

さきほどの共有カードの件も、直したあとに「無いスラッグで404になること」を検査へ足しました。同じ形で二度は起きません。

検査を足すときは、わざと壊して落ちることまで確かめます。通ったという結果だけでは、ちゃんと見ているのか、そもそも何も見ていないのか区別がつかないからです。さきほどの件でも、行き先のファイル名を存在しないものに変えた場合と、対象を1つだけ隠した場合の両方で、実際に落ちることを確かめました。

ここを省くと、通っているのに守られていない検査ができます。無いより悪い。守られていると思い込むぶん、確認をやめてしまうからです。

とはいえ、何でも検査にすると別の問題が起きます。落ちる理由が増えて、落ちても誰も読まなくなります。

私は「一度実際に起きたこと」だけを検査にしています。起きるかもしれないことは入れません。想像で足した検査は、たいてい本当に困る場面を外します。

失敗を仕組みへ変える手順は個人開発で失敗を記録する六項目。却下と障害から残した形式にまとめています。

判断に使っているのは、次の分け方です。

検査を置いても、通り抜けるものは残ります。検査が見ているのは、こちらが見ようと決めたものだけだからです。

以前、テストを全部通して公開したのに、公開後に食い違いが出たことがあります。確認していたのが、自分が変更した部分に偏っていました。利用者が実際に通る経路を全部は試していなかった。そのときの記録はテストは全部通った。それでもアプリの公開後に6つ問題が出たにあります。

だから最後は実物を見ます。ただ、全ページを毎回見るのは無理なので、変えた場所に応じて1つか2つだけと決めています。全部見ようとすると、結局どれも見なくなります。

見る場所を絞るときは、変えた場所から一番遠いところを選んでいます。変えた場所そのものは、すでに何度も見ています。壊れているとしたら、変えていないのに影響が届いた側です。

• 渡す前：終わったと言える条件を、確かめられる形で書く。
• 受け取るとき：完了の報告ではなく、成果物を見る。
• その後：一度起きた食い違いは、ビルドを止める検査へ移す。
• 最後に：変えた場所に応じて、実物を1つか2つだけ目で見る。

「動くけれど仕様と違う」はどうすれば気づけますか？

画面を見ても気づけません。見た目が正常なまま中身だけ違うからです。気づく方法は2つで、完了条件を機械が読める形で先に書いておくか、成果物を外から開いて確かめるかです。私は検索エンジンの管理画面から知りました。

「動くこと」を完了条件にしてはいけませんか？

足りません。あとから照らせる形にしてください。「正しく動く」では照らせませんが、「このURLは404を返す」ならコマンド一つで確かめられます。書いた条件が、そのまま検査になります。

「直しました」という報告は信じていいですか？

完了の表示が保証しているのは、操作が終わったことだけです。直したと言われたら検査を通す、公開したと言われたら実際のURLを外から開く。手元で正しくても、配信後の設定が違えば結果は変わります。

検査は何から入れればいいですか？

間違えたときに自分で気づけないものからです。画面が真っ白になる類は放っておいても気づくので、検査にしません。見た目が正常なまま中身だけ違うものだけを機械に回せば、検査は増えすぎません。

検査が通れば安心ですか？

いいえ。⚠️ 検査を足すときは、わざと壊して落ちることまで確かめてください。通ったという結果だけでは、ちゃんと見ているのか何も見ていないのか区別がつきません。通っているのに守られていない検査は、無いより悪いです。

これはAIを使っているから起きる問題ですか？

一人で書いても同じことは起きます。違うのは速さです。短い時間で多くの場所を直せるぶん、食い違いが増える速度も上がります。だから対策は「気をつける」ではありません。気をつけられる量を超えているからです。

どれか一つでは漏れます。私の場合、3層目の検査を置いてから、同じ種類の失敗が繰り返されなくなりました。新しい種類はいまも出ますが、それは記録して次の検査になります。

この3層は、AIを使っているかどうかとは関係なく効きます。ただ、使っていると食い違いの出る速度が上がるぶん、置いていないときの差が大きく出ます。私は先に層を置かずに範囲だけ広げて、静かに壊れた状態を一度作りました。順番を逆にしなければ、防げたものでした。