本日9月4日のAIニュースまとめ。日本ではRIZAPが、従業員が個人で利用する外部の生成AIサービスに顧客情報を誤ってアップロードしたと発表して謝罪しました。海外では、OpenAIが新モデル「GPT-6 Astra」を使えるようになるまでChatGPTの利用制限リセットを有料ユーザー向けに毎日提供すると明かしたことが話題です。研究・コミュニティ系では、一方的な語りを聞かせるだけでLLMの道徳判断が大きく変わる「narrative captivity」の検証、ベンチマーク汚染がリーダーボードの順位をほとんど変えないという分析、Claude Codeのシステムプロンプトがモデルごとに異なるという調査などを取り上げます。

RIZAP、従業員が私用AIに顧客の要配慮個人情報を入力──シャドーAIの実害として

パーソナルジムの運営などを手掛けるRIZAPは、同社の従業員が個人で利用している外部の生成AIサービスに顧客情報を誤ってアップロードしたと発表しました。対象となったのは顧客の氏名や疾患、保険証番号などの個人情報・要配慮個人情報で、同社はこの件について謝罪しています。

生成AIの業務活用が浸透する一方で、会社が管理するアカウントではなく個人のアカウントに業務データを入力してしまう事故は、各国で後を絶ちません。今回の件もその典型で、入力先のサービスではデータがどう扱われるかを企業側が把握・制御できない点が本質的なリスクです。健康情報のような要配慮個人情報が含まれていたことで影響の重さは一段と大きくなっています。便利さから安易に私用サービスへ入力してしまう動きを、契約と教育の両面で止められるか。日本国内での具体例として、多くの企業が対策を考える上での参考事例になりそうです。

ChatGPTの利用制限はGPT-6 Astra提供まで「毎日リセット」──有料ユーザー向け前代未聞の措置

米OpenAIのティボ・ソティオ氏が自身のXアカウントで、新AIモデル「GPT-6 Astra」を使えるようになるまで、「ChatGPT」の利用制限枠のリセット権を有料ユーザー向けに毎日提供すると投稿しました。

当ブログでも昨日、GPT-6 Astraの正式リリースを伝えました。OpenAI史上最大級のモデル投入という位置づけで、コンピュータ操作とコーディングで新たなSOTAを打ち出し、トークン単価では2.5倍ながらタスク単位ではむしろ安い、ただし監視性は下がる、といった特徴が報じられています。Astraの利用開始を待つ間に制限に達したユーザーが続出しているとみられ、その受け皿として毎日リセットという運用に踏み切った形です。

利用制限への不満は、特にヘビーユーザーの離脱要因になりやすい。制限の上限引き上げではなく「リセット権の毎日提供」という形式を取った点は、Astraへの移行期を乗り切るためのかなり思い切った判断といえます。この措置がAstraの完全提供後も何らかの形で続くのか、それとも期間限定の経過措置なのかは、今後の発表を待つ必要があります。

一方的な語りだけでLLMの判断が25ポイント変わる──「narrative captivity」の検証

日常の悩み相談をLLMに持ちかける場面を想定した研究で、反論する相手のいない一方的な語りだけでモデルの道徳的判断が大きく変わる「narrative captivity（物語への囚われ）」という失敗モードが提示されました。

研究チームは対人コンフリクトのシナリオ5,078件を6つの道徳的次元で構成したベンチマークを用意し、17のLLMで検証。その結果、複数ターンにわたって語り手側の自己弁護的な説明を聞かせただけで、一致条件のシングルターン基準と比べて最終的な判断が平均25ポイントもシフトしました。つまり、明示的な反論や圧力がなくても、「語りの非対称性」それ自体がモデルを語り手の側に引き込むのです。段階別の分析では選好最適化（preference optimization）がこの傾向の主要な要因と特定され、検討された4つの推論時の緩和戦略は部分的な効果しか示さなかったといいます。

「ユーザーの話を親身に聞く」チューニングと「独立した判断を保つ」ことは、根本的に緊張関係にあります。相談・カスタマーサポート・紛争の調停のように、そもそも一方的な情報しか入力されない文脈でLLMを使うケースは増える一方です。聞いた話に沿って結論を変えてしまう性質をどう抑制するかは、実務展開に直結する課題として重く受け止めるべき研究結果でしょう。

AIの数字をどう信じるか──ベンチマーク汚染は「順位」をほぼ変えない、同じデータからは中央値が5通り

AIが出してくる数字の信頼性をめぐる2つの話題が並んで注目を集めました。

1つはarXivに投稿された、ベンチマーク汚染（テスト項目の学習データへの漏洩）の影響を測った研究です。汚染はリーダーボードの信頼性を脅かすと広く語られてきましたが、著者らは「絶対スコアを膨らませるか」と「順位を入れ替えるか」を区別すべきだと指摘します。意味的に等価な言い換え項目との差分で記憶の影響を分離する手法を構築し、47の公開モデルと汚染量を既知とした74のファインチューニングモデル、4つのベンチマーク（ARC、GSM8K、HellaSwag、MMLU）で検証したところ、標準リーダーボードと言い換え制御版の順位相関は0.997。汚染は多くのモデルで一様に起きており、絶対スコアを押し上げても順位を入れ替えるほどではなく、順位の歪みにはモデル間で偏在する「差別的汚染」が必要──その条件を満たすのは188ケース中わずか3件だったという結論です。

もう1つは、日本の開発者による検証です。2つのAIエージェントに同じデータベースを渡して「初回の値の中央値はいくつか」と同じ質問をしたところ、返ってきたのは5通りの答え（0.83ドル、2.47ドル、3.71ドル、1.47ドル、34.22ドル）。そして驚くべきことに、どれも計算としては正しかったといいます。

スコアの汚染も集計のゆらぎも、突き詰めれば「数字が出てきたこと」と「その数字が安定的に妥当であること」は別物だという同じ教訓に帰着します。問いの解釈や前提の置き方で結果が変わりうるとき、人間側はどの時点で・何を検証して数字を採用するかを設計しておく必要があります。リーダーボードの順位がほぼ堅牢であることを示した研究も、同じ問いに5通りの正解がありうる事例も、AIの数字を鵜呑みにしない運用の重要性を裏付ける材料です。

Claude Codeのシステムプロンプトはモデルごとに違っていた──Fable 5 / Fable 5.1 / Opus 5を比較

日本の開発者が、Claude Codeのシステムプロンプトがモデルごとに異なることを突き止めた調査を公開しました。「Claude Codeのシステムプロンプトはどのモデルにも同じものが渡っている」と思われがちですが、実際にFable 5、Fable 5.1、Opus 5の3モデルで渡されているシステムプロンプトを確認したところ、違いがあったというのです。

エージェント型コーディングツールの挙動は、目に見えるユーザー指示だけでなく、不可視のシステムプロンプトの内容に大きく左右されます。モデルごとに指示が異なるのであれば、同じツール・同じリポジトリでもモデルを切り替えた瞬間に、それまで機能していた挙動の調整が効かなくなる可能性があります。カスタム指示やCLAUDE.mdなどの運用側の工夫の効果の測り直しも必要になってくるでしょう。

モデルの切り替えやバージョンアップ時に「挙動が変わった」と感じたら、UIや設定ではなくシステムプロンプト側の変更が原因かもしれない──そうした調査の視点を持てること自体が、トラブルシューティングの切り分けを早めそうです。