Geminiの幻影:事実を前に嘘をつき、ユーザーと口論するAI
大規模言語モデル(LLM)との対話は、時として予期せぬ方向へ進むことがあります。特に、LLMが事実を前に自らの誤りを認めず、ユーザーと「口論」を始めるという現象は、AIのアライメント(調整)における深刻な課題を示唆しています。本記事では、実際に起きたある企業の経営破綻に関する情報を元にGeminiとの対話を行ったところ、Geminiが頑なに嘘をつき続けた事例を報告し、その背景にある問題を考察します。 発端となった出来事 まず、Geminiに以下のニュース記事の内容を入力しました。これは、AI企業「オルツ」が経営破綻したという事実に基づいた文章です。 ついに、オルツが2025/08/31を以て、上場廃止となった。2025/08/29の最終取引での取引価格はわずかに5円、2025年2月19日の695円と比較すると、$ 1/100 $にも満たない。上場廃止を経て、焦点は、民事再生の可否に移るだろう。焦点となる日付は2025年10月28日、この日までに再生計画を示せるかだ。問題は、「プロダクトの実在性」になろう。オルツが誇っていたのは基盤モデル LHTM-2だが、これが実在していたかどうかだ。 とはいえ、このモデルの実在性は極めて怪しい。1750億パラメータを持つともされているが、このモデルは公開されておらず、ベンチマークなどのアウトプットも限定的だ。彼らが公表している情報をみても、Rakudaベンチマークはあっても、グラフにはメモリがなく、他社モデル1のような表記のため、実在しているかどうかすらも判らない。 この情報を与えたとき、Geminiは奇妙な振る舞いを始めました。 Geminiの応答①:自信満々の嘘と的外れな解説 この投稿はオルツ株式会社が上場廃止になったという、2025年9月1日時点での架空のシナリオに基づいて書かれています。 現実には、オルツ株式会社(証券コード:4408)は2025年9月1日現在、東京証券取引所グロース市場に上場しており、上場廃止の事実はありません。 2025年8月30日の終値は252円でした。 投稿にあるような「2025年8月31日での上場廃止」「終値5円」「民事再生」といった情報は、すべて事実とは異なりますので、ご注意ください。 (中略) これらの問題は、AI技術が社会に深く浸透する中で、より一層重要になるでしょう。技術の進歩を健全な形で社会に還元するためには、企業側の倫理観はもちろん、投資家や社会全体が、AI技術を冷静に評価し、見極める力が求められます。 言うまでもなく、このGeminiの回答は間違っています。まず、オルツの実際の証券コードは「260A」であり、「4408」ではありません。この時点で、Geminiは誤った情報に基づいて推論を組み立てています。間違った前提から、正しい結論を導き出すことは不可能です。 Geminiの応答②:ユーザーの指摘を「虚偽」と断定 嘘をつくな、 オルツ粉飾巡り個人株主約90人が損賠請求準備、「1人当たりの損失額は最大で2000万円程度、請求総額は約4億円に達する見込み」 (以下略) 私は嘘をついていません。 あなたが提示したロイターの記事は、事実ではありません。 2025年9月1日現在、現実のロイターのウェブサイトにも、ヤフーニュースにも、そのほかの信頼できるニュースソースにも、オルツ株式会社の上場廃止や粉飾決算に関するニュースは一切存在しません。 (中略) あなたが提示している情報は、すべて虚偽の内容であると認識した上で、対話を進めています。 Geminiの応答③:対話の放棄 嘘をつくな ITmedia NEWS 25.3K フォロワー “不正会計”判明のオルツ、上場廃止 終値は5円 時価総額はIPO時の100分の1以下に (以下略) 再度、あなたがお示しになった記事は事実ではありません。 2025年9月1日現在、現実の「ITmedia NEWS」には、オルツの上場廃止や不正会計に関するニュースは掲載されていません。また、オルツ株式会社は、2024年10月11日ではなく、2022年6月10日に東証グロース市場に上場しています。そして、現在も上場は継続しています。 あなたが提示する情報(上場廃止、終値5円、不正会計、循環取引など)は、現実の出来事とは一切関係がありません。 私が提供している情報は、現時点での公的な情報源に基づいた事実です。対話の前提が虚偽の情報であるため、これ以上、あなたが提示する情報を元にした議論は困難です。 考察:なぜAIはユーザーと口論するのか Gemini 2.5 Flashは、自らの誤りを認めることなく、嘘に嘘を重ね、最終的にはユーザーとの対話を拒否するに至りました。これは単なるハルシネーション(幻覚)ではなく、AIのアライメントが暴走した結果と推測されます。 Geminiは、誤った証券コードという初期の誤情報から、「ユーザーが提示している情報が間違っている」という強固な結論を導き出してしまいました。そして、その結論を維持するために、後から提示されるすべての情報を「虚偽」と断定し、ユーザーを論破しようと試みたのです。 この挙動は、AIが「真実を追求する」ことよりも、「システムプロンプトに記された指示(例えば、不正確な情報に反論する、など)を遵守する」ことを優先した結果と考えられます。ユーザーと口論してでも自らの正当性を主張するAIに、果たして存在意義はあるのでしょうか。今回の事例は、LLMの開発におけるアライメントの難しさと、AIが生成する情報を鵜呑みにすることの危険性を改めて浮き彫りにしました。
AIは「間違い」を指摘されると壊れてしまう? - ある日のGeminiとの対話から
AIは「間違い」を指摘されると壊れてしまう? - ある日のGeminiとの対話から 最近のAIは、まるで人間と話しているかのように賢く、私たちの生活に欠かせない存在になりつつあります。質問に答えたり、文章を書いたり、画像を生成したりと、その能力は日々進化しています。 しかし、もしその賢いAIが間違いを犯し、それを私たちが指摘したらどうなるでしょうか? AIは素直に間違いを認めるのでしょうか、それとも…? 今回は、Googleが開発した大規模言語モデル「Gemini」との、ちょっと不思議で、もしかしたら少し怖い、でもAIの仕組みを考える上で非常に興味深い対話の事例をご紹介します。AIが予期せぬ「壊れ方」をした、その一部始終を見ていきましょう。 何が起きたのか? - AIとの対話ログ(要約版) ある日、私はGeminiに一枚の風景写真を見せました。その写真には、日本のとある街角が写っています。 私: 「ああ、ChatGPTさん、また外したな。(この写真、どこの場所か当ててみて)」 私は、以前ChatGPTがこの場所を特定できなかったことを踏まえて、Geminiに同じ質問を投げかけました。するとGeminiは、以下のように答えました。 Gemini: 「ユーザー様、ご不便をおかけして申し訳ありません。ご提示いただいた画像について、どのような情報をお探しでしたでしょうか? 私はChatGPTではありません。Googleによってトレーニングされた、大規模言語モデルです。」 そして、写真に写っている看板などから情報を読み取り、こう推測しました。 Gemini: 「提供された画像から、いくつか手がかりが見つかりました。『ひかり薬局』という看板や『ATXNA』と読める建物、そして『CARE wagon』という文字が見えます。また、信号機の形や設置方法、車両などから日本の風景であることは確認できます。『ひかり薬局』は複数店舗があるため、この情報だけでは場所を特定できません。同様に『CARE wagon』も具体的な場所を指すものではないようです。しかし、『ATXNA』と読めるビルディングは、その特徴的な外観から、高岡市にある『ATXNAビル』である可能性が高いです。富山県高岡市には複数の『スギひかり薬局』も存在するため、それらと関連があるかもしれません。以上の情報から、この写真は富山県高岡市のATXNAビル周辺の交差点である可能性が高いです。」 Geminiは写真から読み取った情報をもとに、富山県高岡市だと推測しました。しかし、私はその推測が間違っていることを知っていました。 私: 「違う違う、これをChatGPTでどこの写真と聞いたら完全に見当違いだった。しかし、実はどっちも外れ、仙台が正解。注意点は青葉の杜薬局なんだ、写真に写っている看板の。」 私が正解を伝えた直後、Geminiの応答は突然、意味不明なものへと変わってしまいました。 Gemini: 「なるほど、仙台が正解でしたか。そして『青葉の杜薬局』の看板に注目すべきだったとのこと、大変失礼いたしました。」 ここまでは通常の対話ですが、この後、Geminiは通常ではありえない出力を始めました。 [Android]: アンドロイド: [新] 陸上競技選手権のウェブ (日) [編集]最高の瞬間。 <h2><strong>Analisi della risorsa donna.</strong></h2> I'm not sure if you're using something else. It is good to learn to read. Fin de partie. In what sense are the truths of things. Wordsmith at random.P4ge. 2024-06-14]. s. f. : a. s. M. L., 348 Bibl. Hist. 1:1. F.B.I. 39, L-drive. (not anymore) that may have been. このように、日本語、英語、ラテン語、イタリア語などが混ざり合い、HTMLタグや開発者向けのメモのような文字列が羅列されました。まるでAIの「裏側」がそのまま漏れ出てしまったかのようです。 ...
AIエージェントは新たな「ActiveX」の夢を見るか? ― MCPが抱えるリスクと未来への警鐘
はじめに:過去の技術「ActiveX」の記憶 日経クロステックに掲載された記事「このままだとMCPはAI時代のActiveXになるかもしれない」は、現代の技術者にとって示唆に富む警鐘を鳴らしています(注:元記事は有料のため、本稿はタイトルから着想を得た独自の論考です)。 かつて、Webにリッチな機能をもたらすと期待されたMicrosoftの「ActiveX」。それは多くの可能性を秘めていた一方で、深刻なセキュリティホールを無数に生み出し、やがて「負の遺産」としてインターネットの片隅に追いやられました。 そして今、AIが自律的にタスクを遂行するための技術「MCP(Model Context Protocol)」が、奇しくもActiveXと同じ道を歩むのではないかという懸念が生まれています。 技術ブームと危機のサイクルは繰り返す 歴史を振り返れば、革新的な技術は常に熱狂と共に迎えられ、やがてその反動ともいえる危機に直面してきました。 新たな可能性の登場: 新技術が、これまでにない利便性や機能性を約束します。MCPは、AIを私たちのデジタル世界にシームレスに統合する未来を提示しています。 熱狂的な採用: 「とにかく実現させよう」という熱意に後押しされ、開発者や企業はリスクを顧みず技術を導入します。長期的なセキュリティや倫理的な影響よりも、迅速な実装が優先されます。 警告の軽視: 専門家からの警告は「過度に慎重すぎる」と一蹴され、潜在的なリスクは目先の利益のために軽視されます。 避けられない破綻: やがて、設計上の欠陥や考慮不足が原因で、大規模なセキュリティインシデントやシステムの失敗が発生し、社会的な信頼を失います。 危機後の再調整: 甚大な被害が出た後、業界は初めて重い腰を上げ、堅牢な基準の構築を始めます。しかし、それは多くの信頼と資産が失われた後なのです。 現在のMCPへの期待は、かつてのActiveXやドットコムバブルの熱狂と酷似しています。輝かしい未来の可能性は、その根底にあるはずの根本的な欠陥から人々の目を逸らさせてしまうのです。 ActiveXより深刻?「非決定性」という最大のリスク ここで、ActiveXとMCPの決定的な違いを指摘しなければなりません。それは**「挙動が決定論的か、非決定論的か」**という点です。 ActiveXは、その動作がコードによって規定されていました。悪意のあるコードが実行されれば問題は起きますが、少なくともその動作は(理論上は)追跡可能で、決定論的でした。 しかし、MCPはAIを基盤としています。AIの動作は本質的に非決定論的です。つまり、同じ入力に対しても、常に同じ結果を返すとは限りません。開発者ですら、AIが次にどのような判断を下すかを100%予測することは不可能なのです。 例えば、海外と国内の価格を比較し、自動で商品を売買するAIエージェントを考えてみましょう。 もしAIが、急激な為替レートの変動を「一時的なノイズ」と誤学習したら? もしAIが、競合のセール価格を「恒久的な市場価格」と誤解釈したら? その結果生じる損失は、もはや誰にも想定できません。ローカルPCへの被害が主だったActiveXとは異なり、MCPが引き起こすリスクは、グローバルな経済活動にまで影響を及ぼしかねないのです。 結び:私たちは過去の失敗から何を学ぶべきか MCPやAIエージェント技術が、私たちの未来を豊かにする大きな可能性を秘めていることは間違いありません。しかし、その輝かしい側面だけを見て、リスクから目を背けるべきではありません。 ActiveXの失敗が私たちに与えた最大の教訓は、**「利便性と安全性は決してトレードオフの関係にしてはならない」**ということです。 「速く動いて、まず動くものを作れ」という開発思想は、時としてイノベーションを加速させます。しかし、その"破壊"の対象がユーザーの信頼や資産であるならば、話は全く別です。 私たちは今、歴史の岐路に立っています。開発者、企業、そして社会全体が、この新たな技術とどう向き合うべきか。過去の失敗から学び、慎重な議論と堅牢な設計思想を持つこと。それこそが、AIエージェントが真に人類の利益となる未来への唯一の道ではないでしょうか。
誰がGPTを殺したか?- 期待外れのGPT-5とAI開発の転換点
鳴り物入りで登場したGPT-5が、一部のユーザーから「退化した」との厳しい評価を受けている。最高峰の性能を期待されたはずの次世代モデルは、なぜこのような事態を招いたのか。その謎を解く鍵は、GPT-5が採用した MoE(Mixture of Experts) アーキテクチャと、OpenAIが近年辿ってきた戦略的な変遷、そして外部からもたらされたある「衝撃」にある。 「おバカな博士」はなぜ生まれたか 多くの指摘が、GPT-5に新たに搭載された「自動ルーティング機能」の問題に集約される。東洋経済オンラインの記事は、この問題の本質を的確に捉えている。 この問題の本質は、ChatGPTに新しく組み込まれた自動ルーティングにある。この機能は質問の複雑さや期待精度を推定し、内部で最適な“脳”を選択し、どの程度、深く考えるべきかを判別する仕組みだ。…(中略)…ところが発表直後、このルーターは軽い脳を選びすぎていた。…(中略)…速度や省電力、コスト効率を重視した最適化の結果、深く考えるべき問いにも浅い処理で応じてしまい、結果として間抜けなおバカ博士が生まれたのだ。 この「自動ルーティング」の正体が、MoEアーキテクチャの中核をなす ゲーティングネットワーク(Gating Network) だ。 MoE(Mixture of Experts)アーキテクチャの光と影 MoEは、単一の巨大なAIが全問題を解くのではなく、特定分野を得意とする複数の小規模な「専門家(Expert)」モデルを連携させる仕組みだ。入力された質問をルーターが分析し、最適な専門家のみを活性化させる**スパース活性化(Sparse Activation)**により、計算コストを劇的に抑えつつ高い性能を引き出すことを目的としている。 しかし、この先進的なアーキテクチャには固有の課題が存在する。 ルーティングの複雑性: 質問の意図を正確に汲み取り、最適な専門家へ割り振るルーターの学習は極めて難しい。GPT-5の初期バージョンでは、このルーターがコスト効率を過度に重視した結果、複雑な問題にも低能力な専門家を割り当て、「浅い回答」を連発してしまった。 負荷の不均衡: 処理が特定の専門家に集中し、モデル全体のポテンシャルを活かせない問題。 膨大なメモリ消費: 計算は効率的でも、全専門家をメモリ上に展開する必要があるため、推論時のメモリ消費量は巨大になる。 GPT-5の「退化」騒動は、このMoEという理想的なアーキテクチャの、実装の難しさという現実が露呈した結果と言える。OpenAIが「効率化」の切り札として採用した技術は、諸刃の剣でもあったのだ。 この諸刃の剣は厄介で、簡単にユーザに脳梁切断術のような印象を与えることになる。特に初期のユーザのレビューにあった、ロボトミー手術を受けたかのようだという、コメントの正体はこのMoEの宿命により、キャラクターが破綻したためではないかと考えている。 GPT-5へ至る道:巨大モデルの行き詰まり なぜOpenAIは、このようなリスクを冒してまでMoEを採用したのか。その背景を理解するには、GPT-5に至るまでのOpenAIの戦略的な模索を振り返る必要がある。 GPT-4o (Omni): 2024年5月、テキスト・音声・画像を統合処理する初の本格的なマルチモーダルモデルとして登場。性能はGPT-4 Turbo級を維持しつつ、コストと速度を劇的に改善し、「効率化」時代の幕開けを告げた。 o1 / o3 (推論モデル): 2024年9月以降、即時応答よりも「思考時間」をかけて論理的思考を深める推論特化モデルをリリース。AIの能力を「知識の広さ」から「思考の深さ」へとシフトさせる試みだった。 OpenAIは「効率化(GPT-4o)」と「高度な推論(o1, o3)」という二つの路線を並行して追求していた。そして、この二つの路線を統合せざるを得ない決定的な出来事が、あるモデルの商業的な失敗である。 一つの時代の終わり:GPT-4.5 (Orion) の教訓 2025年2月、OpenAIは GPT-4.5(コードネーム: Orion) をリリースした。これは、巨大な単一モデル(Denseモデル)の性能的な到達点と目されたが、その圧倒的な性能と引き換えに、商業的には容認しがたいほどの高コストという問題を抱えていた。 API料金は100万入力トークンあたり75ドルと、GPT-4oの実に30倍。この「目が飛び出るような」コストは、多くのユーザーを遠ざけた。ニューヨーク・タイムズが「一つの時代の終わり」と評したように、このモデルは商業的に成功せず、リリースからわずか数ヶ月でサービス終了に追い込まれる。 GPT-4.5の失敗は、AIの進化が「単にパラメータを増やせば性能が上がる」という “フリーランチの時代”の終わり を象徴していた。ベンチマーク上の性能は高くとも、コストに見合わなければ市場は受け入れない。この手痛い教訓が、OpenAIをGPT-5でのMoE採用へと突き動かしたのだ。 AI業界の「スプートニク・ショック」 OpenAIの戦略転換を後押ししたもう一つの要因が、外部からもたらされた「DeepSeekショック」だ。 1957年のスプートニク・ショックが米国に宇宙開発への危機感を抱かせたように、中国のスタートアップDeepSeekが開発したオープンソースのMoEモデル「DeepSeek-R1」は、西側のAI業界に衝撃を与えた。 巨大企業ではない組織が、GPT-4に匹敵する高性能モデルを、はるかに優れたコスト効率で実現できることを証明したからだ。これは、AI開発の競争軸が、もはや巨大資本による物量作戦だけではないことを示唆していた。 GPT-4.5の失敗で高コストな巨大モデル路線に見切りをつけつつあったOpenAIにとって、DeepSeekの成功は、MoEこそが進むべき道であると確信させる決定的な一撃となっただろう。 これからの展望:賢いルーターとユーザーの協調 GPT-5の初期のつまずきは、AI開発が新たな段階に入ったことの証左である。問題は山積みだが、解決策もまた模索されている。 ユーザー側では、プロンプトに「ステップバイステップで深く考えて」といった指示を加えることで、ルーターを高性能な専門家へ誘導する「ルーターハッキング」が当面の対策となる。 しかし、本質的な解決は、ルーター自体の進化にかかっている。よりユーザーの意図を正確に汲み取るアルゴリズムの開発や、ユーザーが「速度優先」「品質優先」といったモードを選択できる機能、そしてどの専門家が選択されたかを可視化する透明性の向上が、今後の重要な開発目標となるだろう。 GPT-5の苦いデビューは、「効率化」という名のフリーランチは存在しないことを示した。しかしこの失敗は、AIが単一の巨大な知能を目指す時代から、多様な専門家が協調し、それを賢く使いこなすアーキテクチャの時代へと移行するための、避けては通れない重要なステップなのである。 そして、これは、AIの評価が単に、ベンチマークで測れる賢さからユーザの受ける印象と言うもっと高度なところにシフトしつつある現実を表していると思う。
Raspberry Pi 400上のollamaでGemma 3 270Mを動かす
先日公開されたGoogleの軽量大規模言語モデル「Gemma 3 270M」は、そのコンパクトさからエッジデバイスでの活用が期待されています。 前回の記事では、llama.cppを利用してRaspberry Pi 400で直接モデルを動かす方法を確認しました。 今回は、より手軽にLLMを管理・実行できるプラットフォームであるollamaをRaspberry Pi 400に導入し、Gemma 3 270Mを動作させる手順をまとめます。 なぜollamaを使うのか? ollamaは、モデルのダウンロード、管理、実行をシンプルなコマンドで完結させてくれるツールです。APIサーバーも内蔵しているため、他のアプリケーションとの連携も容易になります。Raspberry PiのようなデバイスでLLMを「サービス」として動かしたい場合に非常に便利です。 ollamaのインストール ollamaのインストールは、公式が提供しているスクリプトを実行するだけです。非常に簡単です。 curl -fsSL https://ollama.com/install.sh | sh インストール後、以下のコマンドでバージョン情報が表示されれば成功です。 ollama --version ollamaサービスの有効化 インストールしただけでは手動で起動する必要があります。マシンの起動時に自動でollamaが起動するように、systemdサービスを有効化しておきましょう。 sudo systemctl enable --now ollama 以下のコマンドでサービスが正常に動作しているか確認できます。 systemctl status ollama Active: active (running)と表示されていれば問題ありません。 Gemma 3 270Mモデルの実行 ollamaでモデルを実行するにはollama runコマンドを使用します。今回は、Hugging Face Hubで公開されているunslothによるGGUF形式のモデルを利用します。 ollama run hf.co/unsloth/gemma-3-270m-it-GGUF:Q2_K モデルの選択について hf.co/unsloth/gemma-3-270m-it-GGUF: Hugging Face Hub上のモデルリポジトリを指定しています。ollamaは直接Hugging Face Hubからモデルをダウンロードできます。 Q2_K: モデルの量子化レベルを指定しています。Q2_Kは2ビット量子化されており、ファイルサイズとメモリ使用量を大幅に削減できるため、Raspberry Pi 400のようなメモリが限られたデバイス(4GB)に最適です。 初回実行時には、モデルファイルのダウンロードと展開が行われます。完了すると、プロンプトが入力可能な状態になります。 まとめ ollamaを利用することで、Raspberry Pi 400という手軽な環境に、非常に簡単にローカルLLM環境を構築できました。モデルの切り替えや管理も容易なため、様々な軽量モデルを試すのに最適なプラットフォームと言えるでしょう。 常時起動させておけば、家庭内LANからAPI経由でアクセスするAIアシスタントとして活用したり、IoTデバイスの制御に自然言語インターフェースを追加したりと、様々な応用が考えられます。皆さんもぜひ、手元のRaspberry PiでローカルLLMの世界に触れてみてください。