そのAIチャットボット、大丈夫？──Air Canada・Lenovo・NY市が教えてくれる“炎上しない生成AI”の作り方
生成AI（GenAI）の失敗事例は、いまや世界中の見出しを飾るようになりました。しかし、番組「Human in the Loop」の議論によれば、本当に深刻で“エグい”失敗の多くは、ニュースにならない企業内テストの世界で起きていると言います。
この記事では、同番組「What every enterprise can learn from public GenAI failures」の内容をもとに、代表的な失敗事例と、そこから企業が学ぶべきポイントを整理します。
1. モデルの性能と「現実世界のリスク」は別物である
番組の冒頭で繰り返し強調されるのは、次のポイントです。
「モデルの性能（performs well）と、モデルのふるまい（behaves well）は同じではない」
大規模モデルは、数学・推論・エージェント機能などのベンチマーク上の性能は日々向上しています。一方で、実際のエンタープライズ環境では以下の要素が加わります。
社内の私的データへのアクセス
外部ツールの呼び出し（コード実行・API・データベースなど）
記憶（メモリ）・エージェント的な自律行動
これによって、「攻撃される面（アタックサーフェス）」と「事故が起こる面」が爆発的に広がる、というのが出演者の共通認識です。
番組中では、赤ちゃんの成長にたとえてこう説明します。
「寝ているだけの赤ちゃんのときは、ベビーベッド周りだけを守ればよかった。
でも、ハイハイ・歩き出すと、家中を“ベビー・プルーフ”しなきゃいけない」
生成AIも同じで、モデルの能力が上がるほど、守るべき範囲も広がる。ここに「モデル単体の評価」と「アプリケーションとしての安全性」のギャップが生まれるのです。
2. 見出しを飾った4つのGenAI失敗事例
2-1. Air Canada：チャットボットの「自信満々な嘘」が生んだ法的責任
2024年、Air Canadaのカスタマーサポート・チャットボットが、
「忌引き割引の払い戻しができる」と案内したにもかかわらず、実際には社内規定で認められていませんでした。乗客が提訴し、裁判所は「チャットボットの発言にも企業として責任がある」と判断します。
ここで問題になったのは：
モデルが自信満々に“幻覚（ハルシネーション）”を出した
「自信がない」「人間に確認して」といった不確実性のシグナルを出さない
社内の最新ポリシーと出力内容が本当に整合しているかチェックしていない
技術的には、RAG（検索拡張生成）で社内ポリシーを参照したり、
「返金・割引・ポイント」など金銭インパクトがある問い合わせは人間に自動エスカレーションする、といった設計でかなりリスクを減らせたはずだ、と語られています。
「エンタープライズは、チャットボットを“別人格”と切り離せない。
それはサイトやコールセンターの“延長線”として見られる」
というコメントが象徴的です。
2-2. Lenovo “Lena”：400文字のプロンプトで内部システムが丸裸に
2025年、LenovoのGPT-4ベースのチャットボット「Lena」が、
たった約400文字のプロンプトで悪意あるコードを生成・実行させられ、
クッキー窃取や内部システムへのアクセスに利用される可能性が明らかになりました。
ポイントは、
典型的なプロンプトインジェクション攻撃で突破されてしまった
伝統的なサイバーセキュリティの発想（SQLインジェクションなど）と
LLM特有の「言語ベースの攻撃」が結びついたリリース前にサイバー観点のレッドチーミング（攻撃的テスト）が十分でなかった
対策として番組が挙げるのは：
入力フィルター（明らかな攻撃パターンを弾く“バウンサー”）
小さなモデルで「このプロンプトは攻撃的か？」を判定するレイヤー
出力側で「コードを実行させず、常にテキストとしてレンダリングする」ガードレール
など、複数レイヤーの防御とレイテンシ・コストのトレードオフ設計が重要だと指摘しています。
2-3. NYC「MyCity Chatbot」：公共サービスでの誤回答と信頼の失墜
ニューヨーク市が中小企業支援のために公開した「MyCity Chatbot」は、
雇用・住宅規制に関する質問に対し、
「違法な解雇ができる」
「テナントをロックアウトしてよい」
といった明確に違法なアドバイスを返したことが問題になりました。
ここで深刻なのは、「一度失った信頼は戻りにくい」という点です。
「一度“違法なことをしろ”と言われたら、
その後どれだけ改善されても、もう使う気にならない」
番組では、本番公開前に：
関係する各行政機関の担当者にクローズド環境で使ってもらい、誤りを洗い出す
「モデルは評価されているが、アプリとしての信頼性評価は別に必要である」と組織に理解させる
といったステークホルダーを巻き込んだ事前テストの重要性が語られます。
2-4. Pak’n SaveのレシピBot：塩素ガス飲料を提案する「危険な遊び心」
ニュージーランドのスーパーが2023年に公開したレシピBotは、
ユーザーが洗剤や漂白剤を入力すると、塩素ガスを発生させる“飲み物レシピ”を提案してしまい、炎上しました。
今のモデルは当時より安全寄りになっているとはいえ、
出演者たちはこれを「2023年の遺物で済ませてはいけない」と指摘します。
理由は：
子どもや高齢者など「出力をそのまま信じがちな層」にもAIが広がっている
モデルの事実性が上がるほど、「人間側の警戒心は逆に下がる」
その結果、見えにくいリスクが増大している
だからこそ、企業側のプロアクティブなレッドチーミングとガードレール設計の責任は重くなる、という結論です。
3. 企業が学ぶべき4つの実践ポイント
3-1. 「モデル評価」だけで満足せず、アプリケーション評価を標準プロセスに
ベンチマークやリーダーボードのスコア＝「性能」
セーフティ・責任あるAI・誤用シナリオの検証＝「ふるまい」
この2軸を切り分け、プロダクト開発のQAと同列で「レッドチーミング」を標準工程にすることが提案されています。
「QAが“仕様通りに動いているか”を確かめるなら、
レッドチーミングは“仕様外のヤバいことをしないか”を確かめる」
という整理がわかりやすいでしょう。
3-2. 人間をうまく組み込んだ“Human in the Loop”設計
すべてをAIに任せず、リスクの高い領域だけ人間を必ず挟む発想が重要です。
返金・解約・人事・法務・医療など、
誤回答のコストが大きいドメインは自動で人間にエスカレーション「不確実性の検知」や「高リスクトピックの検知」をトリガーに、
チャットフローを人間オペレーターへ切り替える
完全自動化よりも、“部分自動化＋人間の監督”のほうが結果として安全かつ実用的になるケースは多いとされています。
3-3. 開発スピード vs. 安全性のトレードオフを“見える化”する
AIテストは「開発を遅らせるコスト」と見なされがちですが、番組ではこう指摘されます。
「“テストを省略したことによる信頼・ブランド・セキュリティの損失”を
ちゃんと見積もれば、必要な投資額は変わってくる」
信頼失墜・法的責任・情報流出の最悪ケースを定量的に評価する
その上で「どの程度のテスト・ガードレールに時間と予算をかけるか」を意思決定する
つまり、“なんとなく不安だから安全寄りに”ではなく、リスク評価に基づく投資判断が必要だということです。
3-4. 「責任は外注できない」という前提からガバナンスを組む
番組後半の「AIホットテイク」で、全員が強く同意したのがこの主張です。
「あなたは自社AIのふるまいに対する責任を、外に丸投げすることはできない」
モデルプロバイダーや外部専門家に設計やテストを依頼すること自体は有効
しかし、最終的なガバナンス設計・運用判断・公開可否の決定権と責任は企業側にある
AIエージェントは「バーチャル社員」のようなものだ、という比喩も出てきます。
従業員の行動に責任を持つのと同じように、AIのふるまいにも組織として責任を持つ覚悟が求められています。
まとめ：GenAI導入の本当の勝敗ラインは「失敗の扱い方」にある
今回紹介した4つの事例は、どれももう少し早い段階でのテストとガードレール設計で被害を大きく減らせたと考えられます。
重要なのは、「失敗をゼロにする」ことではなく、
失敗を事前テストの段階で出し切る仕組み（レッドチーミング）
本番環境でのモニタリングと素早い改善サイクル
そして、AIを“別人格”ではなく自社サービスの一部として引き受ける姿勢
を持てるかどうかです。
モデルの性能競争から一歩引き、
「どのようにふるまうAIを、どのようなガバナンスのもとで運用するか」。
ここにこそ、これからのエンタープライズのGenAI戦略の本当の勝敗ラインがある、と番組は示唆していました。
