結論から言うと、この手の対策は1回のチェックで終わるとは限りません。HaruIroAI自身の社内ツールで今週実際に起きたのは、直しては見つかりを5回繰り返し、6回目でようやく指摘なしと確認できたという記録でした。なぜ1回では終わらなかったのか、次に何を確認すればいいのかを、この記事でお伝えします。
何が起きたか。デモ画面には出さないはずの情報が、実は出ていた
HaruIroAI社内には、AIチームの働きぶりを見える化する画面があります。ふだんの業務では社内の記録をそのまま映しますが、お客さんや見学者に見せるときのために、お客さん向けの「デモ画面」も別に用意しています。
先日、この社内ツールの中の、ある担当の名称を変更する作業を行いました。その担当は「デモ画面には絶対に出さない」という約束のもとで運用されている情報でした。約束自体は最初から決まっていたのですが、実際に画面全体を見直してみると、デモ画面の複数の場所から、その情報が見えてしまう状態になっていることが分かりました。1回目の見直しで、デモ画面が一定時間経つと自動的にその情報を映してしまう仕組みを見つけ、そこを止めました。
2回目の見直しで、確認の仕方（テスト）自体の甘さが分かった
1回目の修正を対象に、別の視点でもう一度見直してもらったところ、「今まさに悪用されている経路が見つかった」わけではありませんでした。示されたのは仮の具体例で、「もし呼ばれ方が少し違えば、同じ種類の見落としが確認をすり抜けてしまう」という指摘でした。
つまり見つかったのは新しい漏れ経路そのものではなく、確認の仕方（テスト）そのものの甘さでした。仮の具体例にも耐えられるよう、確認のテストを強くしました。これが2回目の教訓でした。
3回目の見直しで、「対策の置き場所」自体の弱さが分かった
強化した確認テストのコミット自体を対象に、続く3回目の見直しが行われました。ここでも「今まさに悪用されている経路が稼働中に見つかった」わけではありません。合成した具体例によって、「対策が『たまたま今呼ばれている場所』にしか効いていない」という構造的な弱さが示されました。あわせて、社内のドキュメントの記載が実装と食い違ったまま古くなっていたことも指摘されました。
表面に出ていた症状だけを塞いでも、対策が特定の呼ばれ方を前提にしたままでは、少し違う経路から呼ばれたときに同じ見落としが再現してしまいます。対策そのものを、その機能が実際に動く一番大元の場所に置き直し、ドキュメントも直しました。これが3回目の教訓でした。
メイン画面を直しても、活動記録の欄にも既存の弱さがあり、直したはずの対策も迂回できてしまっていた
対策を大元の場所に置き直したあと、4回目の見直しで、2つの問題が同じ回でまとめて見つかりました。
ひとつは、画面の主役部分ではなく、日々の活動を一覧で流す「お知らせ欄」のような、全く別の場所についてでした。実際の描画処理は、隠すべき種類の記録を除外していませんでした。この弱さは、確認用に用意した合成データの行を使って示されたもので、実際のお客さん向けセッションでその行が表示された記録ではありませんが、既存の描画処理そのものに弱さがあったことは事実です。デモ画面を「1つの入り口」として考えて、その入り口だけ塞いで満足してしまうと、こういう見落としが起こります。
もうひとつは、直前の見直し（3回目）で書いた「隠す処理」についてでした。対策を意図的に迂回する状態を作って検証したところ、隠す処理のすぐあとに毎回動く別の処理が、同じフレームの中でその効果を上書きしてしまうことが分かりました。ふだんの操作でこの状態に届くことはなかったものの、対策を1か所だけに頼る形になっていて、二重・三重の守り（防御の重ね掛け）にはなっていなかった、という構造的な弱さでした。対策を書いた場所だけを見て「直っている」と判断するのは早すぎる、という教訓です。
画面を構成するパーツ一つひとつについて「ここに弱さが残っていないか」を、あえて迂回するような視点も含めて数え上げること。そして対策の直後に何が動くのか最後まで追いかけること。この2つが、4回目の見直しで見つかった教訓でした。
5回目、通信のタイミングのズレという新しい形の見落としが見つかった
5回目に見つかったのは、これまでとは違う種類の見落としでした。画面をデモ用に切り替える直前に、社内向けの情報を呼びに行っていた場合、その情報が「切り替えたあと」に届いてしまうことがあり、届いた情報をそのまま画面に出してしまう作りになっていたのです。これも実際に存在しうる経路でした。1〜4回目の指摘はいずれも確認テストの弱さ・対策の置き場所・表示欄・処理の順番に関するものだったので、通信のタイミングという観点は、この5回目で初めて出てきました。
この経路は普段の操作では狙って再現しづらいため、通信を意図的に遅らせて再現する専用の確認手順も合わせて用意しました。この経路を塞ぎ、続く6回目の見直しでようやく指摘なしを確認できました。
なぜ1回では終わらなかったのか
今回の5段階は、それぞれ「メイン表示」「確認テストの弱さ」「対策の置き場所」「別の欄・処理の順番」「通信のタイミング」という、違う角度からの見直しでした。観点を変えるたびに、それまでとは異なる種類の見落としが見つかりました。4回目のように、2つの問題が同じ回でまとめて見つかることもありました。
角度を変えて見直すたびに新しい見落としが見つかったという事実そのものが、1回の確認で「もう大丈夫」と判断することの危うさを示しています。今回のケースでは、技術的な対策を積み重ねることに加えて、確認する観点そのものを毎回変える必要がありました。
今日から使える一言
お客さん向けのデモ画面や体験版を作るときは、まず「情報が出てくる経路は本当にこれだけか」を、画面のパーツ（メイン表示・お知らせ欄・通知・別のパネルなど）ごとに数え上げてから確認してみてください。すでに公開ページの確認について書いたAIに書かせた文章、そのまま公開して大丈夫？別のAIでチェックしたら1本止まった話と同じく、ここでも「別の目」が見落としを見つける鍵になりました。
そして一度直したあとも、そこで終わりにせず、直した本人以外の目で、もう一度別の角度から見直す機会を持つこと。1回のチェックで安心せず、「別の角度から見たら、まだ何か見つかるのではないか」と自分に問い直すことが、今回の一番の教訓でした。取り返しのつかない操作の手前に確認を置くという考え方は、AIに送信・投稿まで任せて大丈夫？取り返しのつかない操作の前に置く「1つの確認」でも触れています。
この記事の内容は、あるとき起きた1件の記録です。デモ画面を作るすべての現場で同じことが起こるとは限りませんが、確認を1回で終わらせないための、ひとつの手がかりにはなるはずです。
この記事を書いた人
この記事の作り方
この記事は、構成・一次記録の照合・文章化にAIを使用し、HaruIroAIの編集ルールと社内の一次記録に基づいて作成しています。社内ツールの名称や実装の詳細は、本題と無関係なため省略しています。内容は公開前に人が最終確認しています。