自動投稿の仕組みを動かしていたとき、ログイン状態の確認を「開始から2.5秒後」に固定していました。画面の表示が間に合わず、ログイン切れと誤判定した一件です。自分のブログ運用で使っている投稿bot の話で、260社に提供している商品とは別物です。
処理は止まりました。ところが投稿台帳と公開先を突き合わせると、対象の記事はすでに投稿済みでした。ログインや投稿処理は無罪です。原因は、確認のやり方でした。
その日の帰り道、多摩川沿いを歩きながら考えていたのは、直したはずの処理がなぜ二重投稿しかけたのか、でした。原因は単純で、2.5秒待って一度だけ判定する方式が粗すぎたのです。必要な画面要素が表示されるまで一定間隔で確認する方式に変え、処理結果だけを信じず公開先の状態と台帳を照合する確認も加えました。
生成や投稿を自動化したあとに待っていたのは、拍手喝采ではありません。検品でした。
生成の神は御役御免になり、検証の神だけが本殿に居座っている
Michal Piszczek氏(Archdesk CTO)は、英語の原文「Verification Cost Is the New Bottleneck」でこう書いています。生成は安くなった。確認は安くなっていない、と。英語の原文は氏個人サイト(piszczek.pl)に、日本語訳はZennの記事「検証コストが新しいボトルネック」にあります。
出典にある「検証コストの構造」という表が刺さります。ボイラープレートも単体テスト付きの関数も、生成コストと検証コストが両方小さいのでボトルネックになりません。ところが分散システムの変更、セキュリティに関わる変更、規制対象ドメインの判断になると、生成コストは相変わらず小さいのに検証コストだけが跳ね上がります。これはPiszczek氏が示した出典側の表で、このあと出てくる表は私が自分のEC運用向けに作った別物です。「AIで生産性が10倍」という景気のいい話は、検証が軽い領域限定の話だった、ということになります。
生成の神は、もうお勤めを終えました。検証の神だけが本殿に残って、毎日お供え物(=人間の確認時間)を要求しています。
四天王が守る四つの陣、すべて突破できるのは3回に2回
Piszczek氏はさらに、自律エージェント時代ならではの理由を挙げています。エージェントは並列に動けますが、人間のレビュアーは並列に動けません。エージェントを10体走らせれば、10本のプルリクエストが同時に届きます。ここで効くのはモデルの賢さではなく、証拠を自動的に生成できるかどうかだ、という主張です。
そこで氏が提示するのが「Proof-Adjusted Autonomy(証明調整済み自律性、PAA)」という指標です。
`PAA = P(A) × P(C|A) × P(R|A,C) × P(T|A,C,R)`
記号ごとに書き下すとこうなります。
P(A) = 人手を介さずタスクが完了した割合
P(C|A) = 完了したもののうち、証拠(ログ・差分・テスト結果)が揃っている割合
P(R|A,C) = 証拠が揃ったもののうち、その証拠を検証可能な割合
P(T|A,C,R) = 検証できたもののうち、意思決定に間に合うタイミングで揃う割合
これは4つの独立したサイコロではなく、前の関門を通過したものだけが次の関門に進む条件付きの連鎖です。それでも各段階の通過率が0.9なら、掛け合わせは0.9⁴≒0.656にしかなりません。
私はこれを、四天王が守る四つの陣を、すべて突破して初めて本丸(=意思決定)にたどり着ける合戦だと思っています。後の陣は前の陣の結果を引き継ぎます。それでも各陣の通過率が9割なら、本丸を落とせるのは3回に2回。残り3回に1回は、どこかの陣で証拠が足りずに引き返す計算です。「90%自律」を謳うエージェントが、実際には約66%しか価値を出していないことになる、というのがPiszczek氏の指摘です。
ここまでが氏の論です。
ここから先は、EC運営に基づく私自身の考察です。
260社と700ユーザーを支えるなら、「成功しました」だけでは足りない
私は楽天やAmazon、中国輸入に携わりながら、自社システムを約260社、Chrome拡張を約700ユーザーに提供してきました。
利用者が増えると、同じ誤判定でも影響範囲が変わります。
冒頭の自動投稿の例では、処理ログだけを見れば「ログイン切れ」でした。しかし公開先では投稿済みでした。ログだけを信じて再実行すれば、二重投稿につながります。反対に、本当に未投稿なのに成功扱いすれば、公開漏れになります。
確認すべきは「プログラムが終了したか」ではなく「業務上、正しい状態になったか」です。
ECなら、商品登録APIが成功を返しただけでは足りません。実際の商品ページで価格、在庫、画像、配送条件が反映されたところまで確認して、ようやく仕事が終わります。
私は、5分の作業をサボるために5時間かけて自動化ツールを作る人間です(病名はまだ付いていません)。確認を全部人間に残すと、自動化した分だけ人間の仕事が詰まります。
新設したのは、生成を担当する部署とは別に、確認だけを担当する部署です。名付けて検証省。最初から工程として予算と時間を配分しておく、という意味です。
損失と頻度で選別し、関所を作ってから確認する
すべてを同じ熱量で読む必要はありません。
確認対象を、損失・頻度・自動検査の3軸で仕分けます。合わせて、どこで人の手を止めるかも先に決めておきます。
| 確認対象 | 損失 | 頻度 | 自動検査 | 止める場所 ||---|---|---|---|---|| 商品説明 | 大 | 高 | 仕様マスタとの項目照合 | 不一致なら公開停止 || 価格・送料 | 大 | 高 | 商品マスタとの差分検知 | 差分があれば更新停止 || 説明文の文字数・禁止語 | 小〜中 | 高 | 文字数・禁止語チェック | 条件違反なら再生成 || 問い合わせ返信 | 大 | 高 | 注文情報・規約との照合 | 顧客送信前に人間が承認 || 画像の見た目 | 中 | 中 | サイズ・形式は自動検査 | 内容は人間がプレビュー || コード変更 | 大 | 中 | テスト・静的解析・差分確認 | 不合格なら反映禁止 |
見る順番は、損失が大きく、頻度が高いものからです。
正誤を条件として書けるものは機械に渡します。文章の雰囲気や例外判断のように、条件だけでは決めにくい部分だけ人間に残します。
これは関所方式と呼べる仕組みです。街道の関所と同じで、合格条件を満たす荷物は自動で通し、満たさない荷物だけ番人(人間)が中身を検めます。「AIに確認させる」という宣言だけでは関所は機能しません。何を入力し、何と比較し、どの条件で止めるかまで決めて、初めて検査になります。
EC業務では、入力・判定・停止をセットで決める
商品説明 — コピーして使える型
入力は、商品仕様書とAIが生成した説明文です。型番、サイズ、素材、対応機種、付属品を項目ごとに照合します。仕様書にない性能や効果が本文にあれば不合格。差分のある項目を添えて再生成します。
「それっぽいから合格」は禁止です。それっぽさは、EC事故の正装です。
合格条件のテンプレートはこの形です。
仕様書にある項目が本文に過不足なく反映されている
仕様書にない性能・効果の記述がない
禁止語・誇大表現が含まれていない
文字数が規定範囲内
価格・送料 — 完全一致だけを通す
入力は、商品マスタと更新予定データです。価格、送料、ポイント倍率、販売期間を比較し、差分が許可された変更一覧に含まれていなければ止めます。
価格を1桁間違えて公開すれば、被害は一瞬で数字になります。たとえば1万円の商品を1,000円と誤表示したまま10件受注すれば、差額だけで9万円の損失です。確認1件にかかる時間はせいぜい5分、時給換算で数百円。9万円のリスクを、数百円の確認でケチる理由はありません。
価格変更は、AIの文章力を鑑賞する場所ではありません。私はこの一致確認を、両替商が金貨を一枚ずつ秤にかけていた作業に例えています。「だいたい合っている」を許さない工程です。
問い合わせ返信 — 自動送信していいのは「案」まで
自動返信で一番危ないのは、返金・キャンセル・個人情報・クレームが絡む案件です。入力は顧客の問い合わせ、注文情報、返品・配送ルール。注文番号、商品、配送状況、案内内容の整合を確認したうえで、この4種類を含む返信は自動送信しません。
AIは下書きまで。送信ボタンの手前には、人間の確認を残します。神社の神託が、巫女の口を通るまでは正式な託宣にならないのと同じです。人間の一手間が入るまで、その返信はまだ「案」でしかありません。
コード変更 — この記事で一番使える型
入力は、依頼内容、変更差分、既存のテストです。
合格条件は、たとえば次のように書けます。
指定された機能が受け入れ条件どおりに動く
エラー時に処理を継続せず、安全に止まる
自動テストと静的解析が通る
変更対象外のファイルに意図しない差分がない
ログや成功表示と、実際の保存・公開状態が一致する
これなら、AIへ依頼する前と、完成後の確認で同じ物差しを使えます。そのままコピーして、自分のプロジェクトの言葉に置き換えて使ってください。
「いい感じに直して」と頼むと、最後に「これは、いい感じなのか」という禅問答が始まります。勤務時間中に開く悟りではありません。
本番投入の順番は、戻せるかどうかで決める
「小さく本番に出す」が効くのは、限られた場面だけです。価格、決済、個人情報、顧客への一斉送信は、少数対象でも事故になります。これらは本番へ出す前に止める設計が必要です。
安全に段階を上げられる変更なら、次の順番で進めます。
1. テスト環境で、正常系と異常系を確認する2. 社内アカウントだけで動かす3. 影響範囲を限定した対象で試す4. 元に戻せる状態を確保して本番へ反映する5. 反映後に、ログではなく実データを確認する
各段階で、誰が止めるか、何を見て止めるか、どう戻すかを決めておきます。
ロールバックできない変更を「まず少しだけ」試すのは、少量の毒なら健康にいい、くらい危険な理屈です。
40分かかった作業を「30秒」と呼ぶのをやめる
測る指標は絞ります。まずはこの3つだけで十分です。
確認にかかった時間
確認時に見つけた不具合件数
確認を通り抜けた見逃し件数(公開後に発覚した分)
余力があれば、生成時間・修正件数・再生成回数・公開後の手戻り時間・影響範囲も足します。最初から8項目を追いかけると、指標を追うための確認作業が増えます。
たとえば生成が30秒で終わっても、確認・再生成・公開後対応まで含めて40分かかったとします。この作業の所要時間は30秒ではなく40分30秒で、確認込みの所要時間は生成単体のおよそ80倍です。私はこの差額を検証省への上納金と呼んでいます。生成の現場が浮かせたはずの時間を、そのまま検証の現場に納めている、という意味です。我が家は妻が中央銀行総裁を兼任していて、上納金が想定より重い月は真っ先に指摘が飛んできます。
生成後の検査を自動化し、人間が見る場所を限定できれば、業務全体は確実に速くなります。
今日やる1つ
自動投稿の誤判定を直したとき、私が追加したのは新しい生成機能ではありませんでした。
固定時間での一度きりの判定をやめること
実際の公開状態と台帳を照合すること
失敗時に、むやみに再実行しないこと
次に自動化すべきだったのは、生成ではなく検品でした。
今日やるなら、いま動いている自動処理のうち、成功ログと実際のデータを突き合わせていないものを1つ、洗い出すところからです。
本記事の数字例(9万円・80倍など)は説明用の仮定です。実際の損失額や確認時間は業種・商材によって大きく変わるため、自社の実データに置き換えたうえで、自己判断でご活用ください。