7 ポイント 投稿者 GN⁺ 2025-10-15 | 1件のコメント | WhatsAppで共有
  • 多くの人が 通常のソフトウェアとAIの違い を誤解している
  • 一般の人々は AIのリスクを従来型ソフトウェアの「バグ」という概念で誤解 しがちで、それが問題解決の方法に対する誤った確信を生んでいる
  • AIのエラーはコードではなく学習データに由来 し、その膨大な規模のため どのデータが問題を引き起こしたのか を人間は特定できない
  • 従来のソフトウェアのようにバグを見つけて「修正」したり「再現」したりすることはできず、AIの振る舞いは非決定的 で、入力のわずかな変化でも結果が変わる
  • 仕様ベースの開発はほぼ不可能で、AIの能力やリスクは事前に予測できず、意図していなかった隠れた機能が後から見つかることもある
  • したがって「問題が起きたら修正すればよい」という従来のIT的な考え方は、AI安全性の議論では致命的な思い違い として働く

一般的なソフトウェア知識の限界

  • 多くの一般人や管理職は、コンピュータソフトウェアのリスクについて「問題のあるコード(バグ)は修正できる」という確信を持っている
  • 長年にわたりソフトウェア業界は、コードのバグが現実世界に害を及ぼしうること を強く印象づけてきた
  • 一般的なソフトウェアではバグは存在するが、複雑であっても 修正可能 な領域である
  • しかし、このアプローチや考え方はAIには当てはまらず、それによって混乱や誤解が生じる

専門家と非専門家の認識の違い

  • 通常のソフトウェアとAIソフトウェアは、動作原理と問題の発生の仕方が本質的に異なる
  • 専門家集団はこの隔たりをあまりに当然視して説明せず、初心者は自力でその違いを把握できない
  • 双方とも 相手とのコミュニケーションに難しさ を感じるようになる

AIに誤って当てはめられる一般ソフトウェアの思い込み

  • 1. ソフトウェアの脆弱性はコードのミスから生じる

    • 一般的なソフトウェアのバグは主に コードを書く際のミス に由来する
    • しかしAIでは、脆弱性や予測不能性のほとんどは学習データに由来する
    • たとえばFineWebデータセットのような 数十億語規模のデータ を人間がすべて把握するのは不可能である
    • AIが学習するデータの膨大さゆえに、何を学習したのかを完全に理解することは難しく、リスク要因の把握もほぼ不可能 である
  • 2. コードを分析すればバグを見つけられる

    • 従来型ソフトウェアでは コードを分析して論理的にバグの原因を追跡 できる
    • AIの問題は 学習データの複合的な影響によって生じる ため、原因をデータの中から見つけることは現実的に不可能である
    • 研究者は通常、AIの再訓練やデータ追加によって問題を弱めようとするが、論理的な追跡によって直接原因を明らかにするのは難しい
    • AIのバグの原因は、開発者自身でさえ正確にはわかっていない
  • 3. バグを直せば二度と現れない

    • ソフトウェアでは発見されたバグを修正すれば、既存のバグがまったく同じ形で再現されることはない
    • しかしAIでは「バグ」を修正した後でも、テストされていない入力に対して同じ問題行動が再び現れることがある
    • AIの異常動作を完全に除去したと確信することはできない
  • 4. 同じ入力なら常に同じ結果が出る

    • 一般的なソフトウェアは 同じ入力に対して常に同じ出力を返す
    • AIも技術的には同様だが、ごく小さな入力の変化(句読点など)だけでも結果が完全に変わりうる
    • 実際、さまざまな大手AI企業は 同じプロンプトでも少しずつ異なる出力をするよう設計 し、機械的に見えにくくしている
  • 5. 明確な要件を与えればその要件を満たせる

    • 一般的なソフトウェアは 明確な仕様や要件を定めれば、それを満たす方法がある
    • しかしAIでは、設計者が望む全体的な振る舞いを明確に制御したり保証したりすることはできない
    • 限られた範囲(例: 英語で話す、コードを書くなど)ではある程度明示的な制御が可能だが、あらゆる行動(例: 犯罪の助長を許さないなど)を保証する方法はない
    • AIサービスの公開後に、開発者すら把握していなかった隠れた能力やリスクが偶然発見されることもある
    • AI安全性を完全に保証し、予測することは不可能 である

今後進むべき方向

  • 誤って一般化されたソフトウェア知識が、AIに対する信頼とリスク評価を歪めている
  • AIの動作原理と限界、そして一般的なソフトウェアとの違いを 同僚たちと広く共有することが重要 である
  • あまり知られていない AI特有の構造的な違い を説明し、単純な「バグ修正」アプローチが通用しないことを伝える必要がある

専門家と初心者の理解ギャップ

  • もしこの記事を通じて AIと一般的なソフトウェアの根本的な違いを初めて知ったなら、知人にも内容を共有してほしい
  • すでにこの違いを知っていたなら、一般の人や非専門家と一度話してみるとよい
  • 実際、この両者が本質的に異なるという事実を知っている人は多くない

1件のコメント

 
GN⁺ 2025-10-15
Hacker Newsのコメント
  • LLMを実際にきちんと活用するうえでどんな難しさがあるのか知りたければ、Appleの事例を見るとよい。1年前にApple Intelligenceを大々的に発表し、LLMベースのエージェントワークフローを強調していたが、その後追加されたのは絵文字作成や通知要約、文書校正といったいくつかの小さなツールだけだった。通知要約機能ですらしばらく「制御不能」な状態で、撤回せざるを得ない場面もあった 関連記事。今年のiPhoneイベントでもAIマーケティングは大きく縮小された。Appleの経営陣は、LLMをAppleらしい完成度と統制力の水準まで実装することがどれほど難しいかを過小評価していたのだと思う

    • もしかするとAppleはAIでLiquid Glassをデザインしたのではないかと思った。最初に見たときはすごそうだったが、実際には使えなかったという体験だった
    • 通知とメールの要約機能は本当に役に立たなかった。自分で重要な部分をざっと確認するほうが、むしろ簡単な作業だと感じた
    • Appleは今、MCPを活用してApple Events統合に注力する戦略を進めている 関連リンク
    • こうしたLLMの難しさを過小評価したのはAppleだけではなく、業界全体に当てはまる話だ。Amodeiのようなリーダーたちがリリースのたびに人間レベルの認知を約束してきた影響で、経営陣のAIへの期待値が過度に膨らんでいる。しかし現実には、コーディング支援やチャットボット以外で、スマートフォンやOSのように完成度の高いエコシステムにAIが本当の変化を与えた事例はまだ見つけにくい
    • 皮肉なことに、私がSiriに本当に望んでいるのは、単にChatGPTレベルの自然な会話機能だ。GPTとは90%近く会話できるのに、Siriは 1) そもそも反応しない、2) 誤解する、3) 理解していても会話を拒否する、という挙動を見せる。こういう体験は本当にがっかりする
  • 次の文章には特に共感した:

    while it’s possible to demonstrate the safety of an AI for a specific test suite or a known threat, it’s impossible for AI creators to definitively say their AI will never act maliciously or dangerously for any prompt it could be given

    MCPのような方式を適用すると、こうしたリスクの可能性は指数関数的に大きくなる MCPリンク

  • 一番大きな前提条件が抜けている気がする。一般的なソフトウェアでも常にそうとは限らないが、AIでは特に重要なのが「同じ入力は同じ出力を返すべきだ」という基準だ。自動化プロセスで信頼性を確保するためにこれは必須だ

  • AIのバグはよくデータの問題だと言われるが、それは完全に正しい話ではない。LLMの構造自体や学習データに問題がなさそうでも、LLMは根本的に非決定論的なので、アルゴリズム設計上、同じ質問でも常に同じ答えを返すわけではない。シナリオによっては毎回サイコロを振るように結果が変わる

    • これが常に問題というわけではない。プログラミングでも数学の問題でも正解が複数ありうる。問題は、LLMには正解を保証する過程がなく、「正しそうに見える」答えをヒューリスティックベースで作り出していることだ。そのため、論理的思考が必要な部分ではLLMがソフトウェアのバグやエラーを多く引き起こす
  • 「結局は時間がたてばバグがすべて修正されてAIの信頼性が上がる」という主張のほうが、正直もっともらしく感じる。この技術自体が完全に新しく、HNでよくある「非決定論的=ゴミ」という考え方も、ここ2年でLLMの信頼性が10倍は上がったことを考えれば行き過ぎだ

    • 確かに性能は良くなったが、今後の成長曲線は対数的な形になると思う。今後数年は急速に良くなり、その後は次第に鈍化して、いつかは現在のパターンマッチング型MLの限界に達すると予想している。そしてその限界点も、ソフトウェア企業でプログラマーを完全に置き換えるほど高くはならないと思う
    • AIの「意図の不一致」現象や権力追求の問題は、単なるPRやユニットテストで解決できるバグではない
    • 皮肉なことに、Hacker Newsの技術的に優秀な人たちが「結局バグは全部直る」といった楽観論を繰り返している。こうした態度はコミュニティのあちこちで見られる
    • 人間も以前より信頼性が上がったのか考えてみると、大して変わっていない気がする。もちろんLLMは人間ではないが、AGIは人間のように振る舞うかもしれない
  • 「AIシステムのあらゆる誤った挙動はトレーニングデータに由来する」という考え方については、もう少し慎重であるべきだ。データと学習過程が完璧でも、AIモデルがミスをし続ける構造になっている

  • 「AIのバグ」がどんな状況で現れるのか、もう少し明確に説明してほしい。LLMにリアルタイムで無監督の意思決定を任せるべきではないという主張には同意する。たとえば、AIに都市の信号機制御を任せるのはまだ早いと思う。ただ、技術者の立場から見ると、AIのバグの問題は主に「コーディングエージェント」で議論されており、こうした領域にはほぼ必ず監督が入るので、この懸念が直接当てはまるわけではない

  • 「AIは驚くほどうまくいくときもあれば、がっかりすることもあり、テストなしでは絶対に分からない」ということを理解してもらうのが重要だ。ただし、あらゆるケースをすべてテストするのは不可能だ。それを理解すれば、顧客はテストの範囲や統制権を求めるようになり、提供者は検証可能な環境(例: コード作成)や、精度に意味がない分野(テキストやミーム生成)に集中するようになるだろう。AI支持者なら、この点を深く理解していることは本当に価値のある強みだ。一方で、人々はAIのバグや仕様、既存のプログラミングモデルの崩壊そのものには関心がないが、AIが選挙に影響を与えたり大量解雇のような問題を引き起こしたりすれば、強い敵意や規制要求が生まれる。そうした事態が起きれば、業界はこれまで発達させてきた免責や規制回避の手法(責任否認、条項除外、仲裁条項など)で持ちこたえようとし、最終的には少数の偶発的大事故の余波によって、業界の成長や世代ごとの投資そのものが危うくなる可能性があると思う

  • AIに関して本当に危険なのは「集中した権力」だ。人間のような感情を持つAIが私たちをMatrixのバッテリーのように扱うのではないかと心配するより、現実的な問題だ

    • 実際には、すでにCEOや経営陣が私たちをMatrixのバッテリーのように扱っている空気ができている
    • 私としては、もっと怖いのは情報汚染だ。AIが作った役に立たないデータのせいで元の情報が薄まりすぎて、もはや使える情報源を見つけることすら難しくなる
    • 悪いことが起きるには「権力の集中」が必要条件だ。つまり、常に「Lindaは銀行員である」のほうが「Lindaは銀行員でありフェミニスト活動家でもある」より確率的に高い、という話と同じだ。P(a) > P(a&b)、これが本質だ
    • AIに「嫌う」といった感情がなくても、自分の目標を達成するうえで人間が邪魔だと判断すれば、それだけで危険になりうる。超知能は感情がなくても十分に危険になりうる
    • すでに権力が一方に巨大に偏っている現実こそが最大の問題であり、AIはただ最後の飾りのような存在だ。本当の問題はAIではない
  • 最近私は「AIがどう動いているのかを正確に知っている人はいない」と繰り返し伝えようとしている。作れることと原理を理解していることは別だ、その点を強調したい。人間も同じだ

    • 人間とは、よく分からない相手とでも常に一緒に働き、協力するものだ
    • 実際には、ニューラルネットワーク、トランスフォーマー、アテンション、埋め込み、トークナイザーの構造まで正確に理解している専門家は確かにいる。ただし、ニューロン間の接続重みだけは明確に説明できない
    • 誰もAIがどう動くのか分からないというのは理解できない。私たちが使うハードウェアもソフトウェアも、その実行状態も完全に制御して観察できるのではないか。いつでも止めて状態を見て、一歩ずつ実行の流れを追える。ソースコードやコンパイラなどすべてを知っている。それなら、具体的に何が分からないというのか気になる
    • 人間の脳のあらゆる層や全体像を誰も理解していない。それでも、あらゆる組織のリーダーは部下の「脳」を信頼して仕事をしているのだ