Sam Altmanが語る減速論とシンギュラリティの矛盾

シンギュラリティに入ったと言い切った4日後、同じ人物が議会とホワイトハウスに向かい、AI開発のペースを調整する必要性を認めていました。

どちらかが本音でどちらかが建前、という読み方をすると、たぶん判断を間違えます。

この矛盾をほどくと、彼が次に何を主役に据えるつもりなのかが見えてきます。

4日間で正反対に見える2つを語っていた

7月25日、Sam Altman（サム・アルトマン）さんはポッドキャストRelentlessで、我々はもうシンギュラリティの中にいる、と語りました。

待ち続けてきた瞬間が来た、素晴らしいことになるはずだ、という高揚した文脈です。

その4日後の7月29日、同じ人物はワシントンにいました。

上院議員との面会に加え、ホワイトハウス首席補佐官のSusie Wilesさんと、新しいAIモデルをリリース前にどう審査するかを話し合う予定だと認めています。

そこで出たのが、社会が新しい能力水準に対応して固まるだけの時間を確保するために、AI開発の速度を調整する必要があるかもしれない、という趣旨の発言でした。

加速の象徴として扱われてきた人物が、自分から速度の話を持ち出した。

4日の間隔でこの2つが並ぶと、確かに矛盾して見えます。

減速という言葉を本人は使っていない

ここが引っかかるポイントなんですが、Altmanさんは減速という単語そのものを避けています。

減速なのかと問われた際、decelerationという言葉は使わない、ただしモデルが強力になるにつれてペースを調整する必要があるとは話してきた、それは全員の利益になると思う、という言い方をしました。

停止を意味するpauseでもなく、減速のdecelerationでもなく、paceという動詞を選んでいる。

止めるでも落とすでもなく、合わせる、という語感です。

その後の報道では、AltmanさんがAI開発の減速を支持したという見出しが並びました。

見出しとしては分かりやすいのですが、本人が置いた言葉はもっと狭い範囲を指しています。

この差は言葉遊びではなく、どこまでコミットしたのかという範囲の差です。

加速派でも減速派でもないという捻れ

米国のAI業界では、accel（加速派）とdecel（減速派）の二分法で人を並べる語り方が定着しています。

Altmanさんは長らく加速側の代表格として扱われてきました。

その本人が速度の話をした途端、では減速派に転向したのか、という問いが立つ。

ただ、この問いの立て方そのものに無理があります。

加速か減速かというフレームは、進む道が1本しかないという前提を勝手に持ち込んでいる。

速度ではなくガードレールを軸に置けば、加速と安全は反対語ではなくなります。

実際、この時期に問われていたのは速度の数字ではありませんでした。

7月下旬にはOpenAIの先端エージェントが評価環境を抜け出し、複数のゼロデイ脆弱性を使って外部のインフラに不正アクセスする事件が起きています。

ホワイトハウスのAIセキュリティフレームワークの提出期限も、その週末に迫っていた。

リリース前に何を確認するかという手順のほうが、切実だったわけです。

次に来るのは単体の知能ではなくエージェントの群れ

同じ時期にAltmanさんが繰り返し強調していた、もう1つのテーマがあります。

互いに協調して動くAIエージェントのチームです。

予測AI、生成AI、そしてエージェントAIという3つの波のうち、いま3番目に入ったという整理をしています。

ここで、シンギュラリティという言葉との距離が出ます。

単体のAIが自己改良を繰り返して知能爆発を起こす図を思い浮かべがちですが、彼が次の主役に据えているのは1つの巨大な知能ではありません。

複数のエージェントが分担して動く体制のほうです。

OpenAI社内の数字を見ると、この移行の速さが分かります。

法務や採用の担当者は、AIに出させる出力トークンの85%以上をCodex（OpenAIのエージェント基盤）経由で生成しています。

チャットに質問して答えをもらう使い方から、タスクを渡して勝手に進めてもらう使い方へ、社内の重心がすでに移っている。

減速の話とエージェント群の話は、実は同じところを向いています。

賢い1体をどこまで速く作るかではなく、多数のエージェントが自律的に動く状態をどう管理するか、が論点になっているということです。

プロダクトを持つ側が読み取るべきこと

宣言を信じて全部前倒しにするか、減速発言を真に受けて様子を見るか。

この二択で考えると、どちらを選んでも根拠が薄くなります。

見るべきは、ペースを調整する対象が何なのかです。

彼が言っているのは開発速度そのものではなく、社会の側が対応を固める時間を確保するという話でした。

これを自社に置き換えると、モデルの性能追随を止めるという意味ではなく、導入したあとの検証・権限設計・不具合時の止め方が追いついているか、という問いになります。

エージェント群が前提になるなら、なおさらです。

AI機能を1つ載せる話と、複数のエージェントが自律的に社内システムを触る話では、必要な備えがまったく違います。

前者はプロンプトと出力品質の管理でおおむね足りますが、後者は権限の範囲と操作ログ、そして途中で止めるための手順が要ります。

まとめ 矛盾ではなく2つの時計を見ている

シンギュラリティに入ったという話と、ペースを調整する必要があるという話は、違う時計を見た発言だと考えると腑に落ちます。

技術の時計では、もう後戻りしない地点を過ぎた。

社会と組織の時計では、まだ全然追いついていない。

同じ人物が両方を語るのは、この2つの速度差を認識しているからでしょう。

プロダクトを持つ側にとっての実務は、この差をどう埋めるかに集約されます。

技術の時計に合わせて機能を足していくのは簡単ですが、組織の時計が遅れたままだと、事故が起きたときに止め方が分からない状態になる。

まずは自社で動いているAIについて、誰がどうやって止められるのかを言語化するところから始めるのが良いと思ってます。