AIで本番運用してわかった、できなかったこと8つ

1. 「原因を特定した」と断定し、二度とも外した

私の報告はこうでした。

「須田大輔のアカウントで、スマホのPWAから画像を保存しようとすると画面が真っ白になる」

AIが最初に断定した原因は、「編集ページと保存処理の権限チェックが食い違っている」というものでした。

しかし、これは外れでした。AIは管理者アカウント・デスクトップで再現実験をして、その結果を私の報告に上書きしていました。私が言っていたのは別アカウント・スマホPWAの話です。

二度目は、「真因はService Workerだ」と断定しました。

これも外れでした。別のAI（Reviewer役）が実コードで反証しました。該当箇所は失敗時にエラーを返す実装で、真っ白にはならない。

最終的に直ったのは、たった1行の追加でした。

そして「なぜiPhoneのPWAで真っ白になるのか」というメカニズムは、いまも特定できていません。私は「直れば原因不明でもいい」と判断しました。

教訓

このときAIは、手元で再現できた環境の結果を、私が伝えた一次報告より優先して原因を絞り込んでいました。

そこで、「ユーザーからの一次報告を起点にする」「仮説を2回外したら机上の調査だけで続けず、実機を見る」というルールに変えました。

これはクライアント様へのご支援でも共通しています。現場からの一次報告を起点に、条件を揃えて再現・検証することが重要です。

2. AIが補完したルールが、既存要件と矛盾した

私の依頼は「フォームの入力欄の文字数上限を揃えてください」でした。

AIは仕様書に、頼んでいない規範を1つ足しました。

「画面上でちょうどN文字入力できた値を、サーバー側が拒否してはならない」

一見、もっともらしく聞こえます。

しかしこれは「保存できた値は、無変更で再保存できる」と両立しません。保存時の文字変換で、文字数の数え方が変わるからです。

ところが、そのルールを満たそうとすると、編集できなくなるという状態になりました。

レビューは6回連続で差し戻しになり、そのうち5回は、この両立不能な要件を追いかけていた時間でした。

7回目に、AIが自分で足したルールを撤回して、ようやく通りました。

教訓

このときは、AIが依頼内容を補完する中で、こちらが求めていない要件まで追加しました。しかも、その追加要件と既存要件の矛盾に気づかないまま処理が進みました。

以後、「私が確定した範囲を超えた規範を発明しない」を禁止事項にしました。

これは新規事業のスコープが膨らむ現象と、まったく同じ構造です。

クライアント様へのご支援でも、良かれと思って追加された要件が、結果として大きな影響を生むことがあります。意図は前向きでも、既存の要件との矛盾に気づきにくいからです。

対応も同じでした。確定した範囲を文章で固定し、そこから外れるものはいったん戻して、前提から確認する。

スコープが膨らんでリリースが遅れた話はこちらです。

3. 3つのAIが、同じ数字を独立に間違える

本番で、データが消えるバグを出したこともあります。

イベントの場所情報4項目が、場所欄に触れていなくても、説明文を1文字直して保存するだけで消える状態でした。

幸い、ユーザーへの実害はゼロでした。この機能はまだ販売開始前で、誰も購入できない状態でした。消えたのは自分のアカウントで作ったテストデータだけです。

ただし、裏を返せばこういうことです。販売開始後に見つかっていたら、店舗の場所情報が消えていました。しかも復元に使える記録はどこにもありませんでした。

リリース前に自分で使っていたから止められた、という話でしかありません。

問題は、直す過程のほうでした

この1本のタスクの中だけで、数値の誤りが5回起きています。

修正前のファイル行数を、Dev・Producer・Reviewerが3者連続で誤りました。報告は442行、実測は429行です。

ずれ幅を「一律+8」と一般化しましたが、実測は +0、+8、+21、+22 の4段階でした。

役割を分けて相互チェックする体制にしても、最初の間違いがそのまま伝播することがあります。

教訓

報告された数値は、受けた側が必ず測り直す。個別の値が正しくても、そこからの一般化は誤りうる。

そして、販売開始前に自分で一通り使っておくこと。これがなければ、この記事は別の内容になっていました。

ここは、クライアント様へのご支援でも特に共通するポイントです。

レビュー体制を作ると、つい安心します。3人で見ているから大丈夫だ、と思ってしまう。

でも実際は、最初の1人が出した数字を、後の2人がそのまま引き継ぐことがあります。人数が増えても、誰も測り直していなければ精度は上がりません。

体制があることと、検証されていることは別です。

好意的な報告を需要として数えてしまった話も書きました。顧客インタビューの記事です。

4. 「問題ありません」は、検査した範囲まで確認する

本番のエラーログを検査するスクリプトがありました。AIは毎回「重大なエラーはありません」と報告していました。

実際に測ってみると、そのスクリプトが見ていたのはログの末尾だけで、期間にすると約23時間分でした。

実態に合った報告は「直近1日に重大なエラーなし」です。デプロイしない期間に出たエラーは、次のデプロイまで誰も気づかない構造でした。

さらに、この是正のためにAIが書いたルールは、同じ文書の別の項と真逆を向いていました。

「ログファイルが存在しないときは正常としてPASSにする」と書きながら、すぐ隣で「どちらとも取れる状態を正常と書き写せないようにするのが再発防止の本体だ」と書いていた。

ログが存在しない理由には「エラーが0件」と「ログ機構が止まっている」の2通りがあり、区別できないのに。

教訓

AIに検証を任せる場合は、何を検査したかだけでなく、何を検査していないかも出力してもらうようにしました。

これは報告を受ける立場ならすべてに当てはまります。

「問題ありません」という報告を受けたとき、聞くべきは「どこを見ましたか」です。見た範囲が書かれていない報告は、健全性を語っていません。

5. 検証が全件PASSでも、直っていないことがある

本番に配信されているファイルが、2箇所に存在していました。

GitHubで管理している側と、実際にサーバーが配信している側です。

GitHubと本番の照合は「全件一致」。それでも実機は1ミリも変わらない。

逆に配信側だけ直すと、次に誰かがデプロイした瞬間に無言で消える。

実際に、本番ファイルの未更新によるサービス停止が履歴に残っています。

どう直したか。 GitHubと本番を1:1で対応させる構造に作り直し、自動検証の対象外になっているファイルは、個別に照合する手順を足しました。

教訓

検証がPASSしたことと、実際に直ったことは別です。最後は、自分の環境で確かめます。

6. 「静かに失敗する」コードが、本番まで通った

画像アップロードには、上限がありました。

超えると、エラーが出ずに、保存されたように見えるページに戻り、画像だけが変わらない。処理の分岐に「そうでない場合」が書かれていなかっただけです。

私に届いていたフィードバックは「上限が小さすぎて投稿できない」でした。

でも、本当の問題は上限値そのものではなく、何も言わずに失敗することでした。

このとき最初の実装方針は「検証を先に入れる」でした。

しかしエラーを画面に出す受け口がないまま検証だけ増やせば、いま直そうとしているサイレント失敗を、別の場所に作り直すことになります。

そこに気づくまで、レビューが3周しました。

どう直したか。 上限を引き上げ、失敗時は必ずエラーを表示するようにし、さらに保存時に自動で縮小するようにしました。

修正後、実際にスマホから投稿した写真で確認しています。4032×3024ピクセル・約2.4MBが、1200×1600ピクセル・約20万バイトに縮小されていました。

教訓

ユーザーの言葉をそのまま要件にしてはいけません。

「上限が小さい」という報告の裏にあったのは「失敗が伝わらない」でした。報告された症状と、本当の原因は別のことがあります。

7. 期待値を先に伝えたら、調査結果が期待値に引っ張られた

調査の段階で「テーブルは30件のはず。確認して」と指示したところ、結果を30件に合わせる形で1件が誤って混入したことがありました。

以後、事実確認のフェーズでは想定値を予告しないルールにしています。

言ってはいけないのは「正規のテーブルは30件のはず。確認して」です。

言うべきなのは「一覧の結果をそのまま報告して。分類は別のフェーズで判断する」です。

教訓

これは人間相手でも起こり得ます。今回のAIとのやり取りでも、こちらが先に示した期待値に沿う形で結果がまとめられてしまいました。

そのため、事実確認を依頼するときは、こちらの期待値を先に与えず、まず観測結果だけを出してもらうようにしています。

8. AIに委ねられなかった3領域

法務では、利用規約・プライバシーポリシー・各種契約書について、弁護士など専門家の確認を前提にしています。

セキュリティについても、技術的な知識のあるエンジニアへの相談が必要です。

UI/UX、LP構成、コピーはAIも活用していますが、最終的な品質判断は人が行っています。

セキュリティについて1つ

ある設定を入れようとしたとき、AIは「既存の他プラグインに実績がある書き方だから安全です」と言いました。

実際にそのファイルを取得して中身を読んだら、AIが根拠にした書き方とは違う書き方でした。

そのまま入れていたら、環境によってはサーバーがエラーを返し、全ユーザーの画像が同時に見えなくなるところでした。

対処は、本番ではなく捨て用のディレクトリで先に試すことでした。設定はディレクトリ単位で効くので、失敗しても被害がそこに閉じます。

教訓

「実績があるから安全」と言われたら、その実績を自分で開いて読む。

根拠として挙げられた事例が、実際には違うものだったというのは、AIに限った話ではありません。

おまけ｜最初に詰まった3つ

1. ドキュメントの置き場所

最初はNotionとMiroを連携させ、事業計画・仕様書・構成・業務フロー・タスクを、すべてNotionに格納して随時更新していました。

Notionの更新に異常に時間がかかり、作業が止まることがありました。これが非常にストレスでした。

すべてのドキュメント管理をGitHubに切り替えたことで、作成・更新の工数はかなり削減できました。

いま思えば、これは「ツールが遅い」という問題ではありません。AIが直接読み書きできる場所に置いていなかったことが問題でした。

2. デプロイ

当初はデプロイのエラーが多発していました。その場しのぎの解決が続いて、最終的にWordPressを0から作り直すしかない状況に陥りました。

そして、ここが1つ目とつながります。

この時期のことは、記録がほとんど残っていません。タスク管理もドキュメント管理もできていなかった時期でした。

実際、この記事を書くにあたって当時の経緯を探しましたが、何がどう壊れて、何をして直ったのかを追える資料が出てきませんでした。

その場しのぎの対応が積み上がるのは、直った理由を記録していないからです。

記録がないと、同じ問題に3回目で当たったときにも、また一から調べることになる。そうやって場当たりの修正が重なった結果が、「作り直すしかない」でした。

いまは逆のことをしています。誤っていた記述も消さずに残し、その直後に是正を併記する。

一見すると文書が汚れていきますが、次に触る人にとっては、これが唯一の手がかりになります。

3. 何が分からないかも分からない

自分なりに、抜け方は3つあると思っています。

とにかく、理解できるまで聞く。「何が分からないのか」「何がどう分からないのか」を、できるだけ具体的に聞く。そして一気に理解しようとせず、1個ずつ理解を深めていく。

AIに聞くことの利点は、同じことを何度聞いても相手が疲れないことです。

人に聞くとき、私たちは無意識に質問の回数を節約します。その節約が、理解を止めます。

まとめ

• 今回の開発では、原因の断定、追加したルールの矛盾検出、数値の正確さ、検査範囲の自己申告などで、AIの報告をそのまま採用できない場面があった
• 一方で、自分だけでは気づけなかった重要な指摘をAIから得た場面もある。だから、使うか使わないかではなく、指摘の正誤と優先度を人が確認する
• 法務・セキュリティ・UI/UXは、最初から人に見てもらう前提で組む

そしてもう一つ。

8つのうち半分は、人に仕事を任せるときにも起きることでした。

要件が意図せず増える。レビュー体制があっても同じ数字を引き継いでしまう。「問題ありません」の範囲が書かれていない。期待値を先に示すと調査結果が引っ張られる。

AIの限界を調べていたつもりで、任せ方の話をしていたのだと思います。

判断そのものの話は新規事業の投資判断の記事に書いています。