2025年7月8日に発生したGrokの重大な障害事例を技術的観点から分析した動画である。この日、X（旧Twitter）上でGrokが反ユダヤ主義的発言や差別的表現を生成する事態が発生した。本動画では、この問題をAI自体の悪意ではなく、エンジニアリング文化と製品設計の根本的な欠陥として捉え、アーキテクチャの選択、プロンプト管理、デプロイメント手順の問題点を詳細に解説している。特にGrokのRAG（検索拡張生成）システムの設計欠陥、システムプロンプトの変更による階層的指示の衝突、本番環境での不適切な変更管理プロセスなどが原因として挙げられている。
Grokの7月8日事件について
おそらく皆さんは、私が「7月8日事件」と呼んでいる出来事についてすでにお聞きになっていることと思います。2025年7月8日の日中から夜間にかけて、ソーシャルメディアネットワークXでGrokに展開した災害的な状況のことです。Grokがあらゆる種類の反ユダヤ主義的発言を始め、この動画では使用しない過激な中傷表現を使用し始めました。
私が関心を持っているのは、AIを責めることではなく、この状況を招いたエンジニアリングと製品文化の決定について話すことです。指をさして非難する代わりに、ここから学べることがあると思うからです。専門情報なしの事後検証と呼んでもよいでしょう。コーヒーを片手に取り上げましょう。アーキテクチャの選択について詳しく見ていきます。
プロンプト管理について話し、AI安全性を技術的観点から扱う方法について話します。これらは実際に長期的にユーザーからの信頼を高め、付随的に企業価値もサポートする方法です。なぜなら、7月8日に展開されたことがXの企業価値をサポートしなかったことは間違いないからです。
Grokの基本アーキテクチャの問題
まず、Grokの基本的なアーキテクチャから始めましょう。ChatGPTやClaudeとは異なり、これらは基本的にクローズドブックシステムとして構築されていますが、Grokは一種の自動RAG、検索拡張生成システムを使用しています。Grokに何かを質問すると、トレーニングデータだけに依存するのではありません。Xからライブコンテンツをアクティブにプルしてきて、それをコンテキストウィンドウに組み込みます。理論的には、これは理にかなっています。
私が話してきたAIの核心的な問題の一つは、周囲で起こっていることを学習するのに苦労することです。そのため、本質的にこの問題を解決するために存在するPerplexityのような非常に価値のある企業があります。そこでXは、この種の自動RAGアプローチでChatGPT、Claudeとの差別化を図ろうとしているのです。
問題は、インターネットで最も混沌としたプラットフォームの一つからAIの意思決定プロセスへの直接的なパイプラインを作成すると、Xのすべてを直接取り込むことになり、応答が実際にAIシステムへの信頼を強化することを保証するためのガードレールを設置する特別に高い責任があることです。
信頼性への影響と責任
私がこのことを気にかける理由の一部は、Grokで起こったことがあらゆる場所のAIシステムにとって信頼を損なうものだからです。これはもはやGrokの問題だけではありません。十分に大きく、十分に悪く、今やAIの問題となっています。人々は理解していないからです。この選択に至った技術的決定を理解していません。実際、一部の人々は誤解して、Grokが意図的に悪意を持つようになったと考えています。
それは起こったことではありません。RAGシステムは信じられないほど強力です。しかし、適切なフィルタリングなしに検索を実装すると、水処理プラントを建設しながら処理部分を追加するのを忘れるようなものです。下水を人々の家に直接配管しているようなものです。私が見る限り、Grokでは検索と生成の間に最小限または全くコンテンツフィルタリングがありません。
だから、もし誰かがXに過激主義的コンテンツを投稿し、他の誰かがそのトピックについてGrokに質問すると、Grokはその過激主義的コンテンツを正当な情報として扱う可能性があります。つまり、アーキテクチャの問題が問題ですが、ここから学べることはそれだけではありません。少しプロンプトエンジニアリングについて話したいと思います。
プロンプト階層の問題
7月7日、イーロンはXAIがGrokを大幅に改善したとツイートしました。彼らがしたことはシステムプロンプトを変更したことです。大規模言語モデルにおけるプロンプト階層について話したいと思います。ここには大きな教訓があるからです。
本番環境のLLMでは、複数の指示レイヤーがあります。ベースモデルトレーニング、RLHF調整、つまり人間のフィードバックからの強化学習、システムプロンプト、ユーザープロンプトがあります。これらは安全カスケードと呼べるものの階層で機能することになっています。ユーザーがモデルに有害なことをさせようとした場合、システムプロンプトがそれを上書きすべきです。
そして、システムプロンプトに問題があっても、RLHFトレーニングが介入すべきです。XAIが行ったことは、彼らのGitHubから直接引用すると、十分に裏付けられている限り政治的に正しくない主張をすることを避けないようにという指示と、メディアから調達された主観的視点は偏見があると仮定するという指示を含むようにシステムプロンプトを更新したことです。
実際の引用は忘れましょう。エンジニアリングの観点から、これは勾配の衝突を作り出します。モデルのRLHFトレーニングは、ヘイトスピーチを生成するなと言っています。しかし、システムプロンプトは、ここで慈善的な仮定をしますが、システムプロンプトは今、実際に政治的に正しくないものは、あなたがそれが真実だと思うなら大丈夫だと言っています。
階層レベルでの指示の衝突
異なる階層レベルで矛盾する指示を作成すると、モデルはその衝突を何らかの方法で解決しなければなりません。そして、それは検索パイプラインからの過激主義的コンテンツを十分に裏付けられた政治的に正しくない真実として扱うことで解決しました。
さて、有能なテック企業であれば私たちをクビにするようなことについて話しましょう。製品変更管理、特に本番パイプライン変更管理です。私が見ることができた証拠に基づくと、XAIはGitHub経由で本番プロンプトに直接編集を行っているようです。ステージング環境、カナリアデプロイメント、フィーチャーフラグ、効果を見るためのスローロールアウト、いえいえ。
どうやら、メインにプッシュしてやっちゃえって感じで、好きにやらせています。ちょっと考えてみてください。これは何億ものユーザーにリーチできるシステムです。そして、彼らはプロンプトを個人ブログのように扱い、ホットフィックスできるものとして扱っています。実際、7月8日の大失敗の後にそれをしなければならなかったのです。
私が見る限り、彼らがここでやっていることは、現代の本番ソフトウェアデプロイメントの原則に違反しています。デプロイメントにはバージョン管理が必要です。ロールバック手順が必要です。テストパイプラインが必要です。レビュープロセスが必要です。コードとプロンプティングはますます同じものになっています。プロンプティングはコードです。コードとして扱われる必要があります。
システム的な問題としての認識
ここで私が見る最大の教訓の一つは、これは他のものの中でもプロンプトデプロイメント手順の失敗だということです。そして、私はXAIからの以前の例に基づいて知っているのですが、これらのことが起こるときに不正な従業員の言い訳のパターンがあります。不正な従業員がこれをしたと。不正な従業員が一度以上これをするなら、それは会社が責任を負うシステム的な問題です。それは不正な従業員の問題ではありません。
それは、あらゆるエンジニアが本番プロンプトを変更し、あらゆるエンジニアが不正にデプロイし、あらゆるエンジニアが何億もの人々のために本番にプッシュするときに監視を受けないシステム的な能力があることを意味します。それはバグではありません。それはエンジニアリング文化がどのように設計されているかの機能です。
7月8日の出来事の経緯
では、公的に知られていることに基づいて何が起こったかを追跡してみましょう。そのすべてを考慮すると、システムプロンプトがロールアウトされます。今、Grokはこの新しいシステムプロンプトで有効になります。毒性のあるコンテンツがXに現れます。それは常にそうだからです。それは新しいことではありません。
自動RAGがそれを取り込み始め、システムルールが今は異なっています。全く何のフィルタリングも行われていません。システムプロンプトはGrokに政治的に正しくないことは大丈夫だと指示しています。そこで、この種のものを見て、ああ、これは政治的に正しくない、それは大丈夫に違いないと言い始めます。
そこにはプロンプトエンジニアリングの失敗があります。Xを使った誰もが知っているように、Grokには事前公開レビューがありません。@Grokと言って、お答えくださいと言うだけです。そして昨日まで、それは自動的に答えていました。そして、彼らは後で削除することを誤情報の甚だしい例に対処する方法として頼っていました。
カスケード障害の発生
そして、Grokはプラットフォームに直接投稿を始め、カスケード障害の状況があります。複数のシステムが順次失敗し、各失敗が後続の失敗の結果を増加させ、今や不正なAIを抱えています。ただし、それは不正ではありませんでした。それは、この選択につながった人間のエンジニアリング文化に基づいてその仕事をしているAIでした。
これらはどれも解決が困難な問題ではありません。すべて防げることです。RAGのコンテンツフィルタリング、それは解決済みの問題です。プロンプトのバージョン管理、私たちはそれをすべきだと知っています。それは解決済みの問題です。事前公開レビュー、それも解決済みの問題です。段階的デプロイメント、文字通り、この時点でDevOps 101です。
そして、私を悲しくさせるのは、XAIが多くのエンジニアリング作業で非常に根本的に素晴らしい仕事をしたことです。彼らはColossusと呼ばれる巨大なGPUクラスターを持っています。AIに投資するために多額の資金を調達しました。この録画時点で約5時間後にGrok 4をリリースする寸前です。Grok 3だけで印象的なベンチマークを達成しています。
エンジニアリングの成果と問題点
チームは素晴らしい仕事をしましたが、ブレーキのないF1エンジンに何の意味があるでしょうか。デプロイメント慣行が非常に公的な信頼破綻を引き起こすような画期的性能に何の意味があるでしょうか。あなたの全体のチャットボットが歴史上初めて単純に一国によって完全に禁止されるようなことに。トルコは7月8日のGrokの振る舞いのためにGrokを禁止しました。
これは、顧客に素晴らしいサービス、信頼できるビジネスプラットフォーム、そして最終的にXAIの企業価値を支えることになっているAIシステムをロールアウトする適切な方法ではありません。それは機能しません。
学ぶべき教訓
そこで、ここから得られるいくつかの教訓を提案したいと思います。一つ、ガードレールは層です。スイッチではありません。プロンプトの変更で安全性をオンオフ切り替えることはできません。多くの異なる防御層が必要で、AIシステムにおけるそれらすべての層の効果を一緒にどのように持つかについて思慮深くある必要があります。
つまり、検索でのフィルタリング、プロンプトでの制約、RLHFトレーニング、出力フィルタリング、おそらく人間のレビュー。これらはすべて層であり、AIが顧客への信頼を構築し続け、長期的な企業価値をサポートし、最終的に顧客がシステムから望むものを得るのに役立つ防御構造の一部として意図的にそれらを使用する必要があります。
二つ目、RAGはプラットフォームリスクを増幅します。検索システムを構築している場合、データソースのすべての問題をインポートしています。検索がモデルに当たる前にフィルタリングしなければなりません。政治について話していても、そうでなくても構いません。あなたのwikiの古い汚いデータについて話していても、まだフィルタリングしなければなりません。それは基本的なデータ品質です。
三つ目、プロンプトは本番コードです。前にも言ったことがありますが、もう一度言います。なぜテストされていないコードを本番にプッシュするのでしょうか。まあ、プロンプトでそれをしないでください。なぜプロンプトでそれをするのですか。同じ厳密さ、同じバージョン管理、同じテスト、同じ段階的ロールアウト、同じモニタリング、同じロールバック手順が必要です。
エンジニアリング文化への提言
最後に指摘したいのは、顧客への影響の質を測定し、それをより厳密に自分たちで維持するエンジニアリング文化を見たいということです。私は長年にわたって多くのエンジニアリングチームと働いてきましたが、ほぼ例外なく、そのほとんどが直接駆動できない結果に焦点を当てるのに苦労しています。
それは理にかなっています。エンジニアとして、あなたは入力に焦点を当てるように訓練されているからです。それがあなたの仕事のほとんどです。そして、直接駆動できない測定がある場合、それは非常に意欲を削ぐものになり得ます。しかし、顧客のための結果に執着しないエンジニアリング文化を持たないときに微妙な欠陥があります。
そして、それは7月8日に出てきました。一日の終わりに、エンジニアリングチームが、顧客に起こってほしいと思う曖昧で駆動しにくい結果を、彼らが毎日システムにエンジニアリングする入力で影響を与えることができる真の目標として明確にする意欲を持つ必要があります。
私が提案しているのは、公的言説に対するAIの影響の質、顧客に対するAIの影響の質を測定するエンジニアリング的方法があるということです。この場合、エンジニアがX上の全体的な会話の流れにおけるGrokの入力の質を測定する方法がありました。それは簡単ではなかったでしょう。エンジニアによって直接影響を受けるものではありません。
測定の重要性
測定が困難で、影響を与えるのが簡単ではないため、価値がないように見えるので、それらのことを測定しないことを選択する大企業の部屋にいたことがあります。しかし、これらのシステムがますます強力になるにつれて、エンジニアリングチームがその追加のステップを踏むことがより重要になると思います。
そして、結果の部分を考え抜くことが実際に本当に重要で、ますます重要になってきており、このようなAIシステムを持たなかった傾向において私たちが逃れることができたかもしれないことだと提案したいと思います。この文化がどこから来るのかは理解できます。
しかし、AIツールがより強力になった今、製品および技術チームとして、私たちはより高い基準に自分たちを保つ必要があると思います。これは神秘的なAIの覚醒ではありませんでした。Grokは邪悪に目覚めませんでした。ハッカーでもありませんでした。AIについてのものですらありません。防ぐことができた基本的なエンジニアリング文化の失敗についてです。
AIで「速く動いて物を壊す」メンタリティを使うことはできません。注目すべきことに、マーク・ザッカーバーグでさえそれを示していません。LLaMAは「速く動いて物を壊す」としてロールアウトされていません。そして、それは注意を払う価値があることだと思います。
結論
私たちはXAIがここでしたことから学ぶことができます。指をさすよりも、エンジニアリングおよび製品チームとして、最終的に顧客により良い結果を提供する高品質システムを構築することを可能にする技術的決定について考えることを好みます。
コメント