同じ記事から、出荷と中止の両方の結論が出る
たとえば、週次の設計レビューです。売上を集計するAIエージェントに、価格の変更と、顧客へのメール送信まで任せるかを決めています。
その朝、英紙ガーディアンが AI ‘godfather’ Geoffrey Hinton: it might turn out we were better off without AI を出しています。2026年11月3日付です。1人はこう言います。「ヒントン氏自身が、人類はまだ主導権を握っていると言っている。この機能も出してよい」。もう1人は見出しだけを見て、「開発しなければよかった、という話だ。導入は止めた方がいい」と言います。
同じ記事から、出す結論と止める結論の両方が出ています。
ジェフリー・ヒントン氏は、今のAIの基礎になったニューラルネットワークの研究に大きく貢献し、2024年の ノーベル物理学賞 をジョン・ホップフィールド氏とともに受けた研究者です。インタビューの "we're still in control" を、この記事では主導権と呼びます。意味は、人が、AIを何に使い、どの操作まで許すかを決められる状態です。原文は、その状態が証明されたとは言っていません。
ガーディアンが引用している英語は、次のとおりです。
My gut is that we're still in control. We might well be able to do something. It'll only work if we put a big effort into it, but we might well put a big effort into it.
日本語にすると、「私の直感では、まだ制御できている。何かできる可能性は高い。大きな努力をして、はじめてうまくいく。そして、私たちはその努力をするかもしれない」です。
gut は、調査や計算の結果ではなく、本人の直感を指す口語です。might は「そうなるかもしれない」です。うまくいく条件は、大きな努力をすることです。その努力をするかどうかも、原文は断定していません。
「対策をすれば、悪い結果は避けられる」と短くすると、次の3点が抜けます。直感であること。かもしれない、という言い方であること。大きな努力が条件であることです。見出しだけを読むと、「開発しなければよかったかもしれない」という文から、良い未来の話が抜けます。
この記事で書くのは、その大きな努力を、モデルを開発していないチームが出荷前に確認する項目にすることです。
能力を上げる速度と、確認が追いつく速度を比べる手順は、AIの進化を止めるのではなく、「安全が追いつける速度」にする──Dario Amodei「We Must Pace the Frontier」をIT技術者の視点で読むにあります。この記事では、2026年11月3日の発言を、システムを導入するチームの確認項目として扱います。
発言は3種類です。1つの結論にしません
冒頭で引いたのは、直感の1文だけです。インタビューには、ほかの発言もあります。
ヒントン氏は、悪い結果が必ず起きるとは考えていない、と自分で言っています。AIによって良い未来になる可能性もあり、開発しなければその方がよかったかもしれない、とも話しています。片方だけを読むと、もう片方の内容を無視することになります。
時期が違う予測は、次の2つです。3つ目の直感は、冒頭で見たとおりです。
10年以内の結果は、測定された確率ではない
ヒントン氏は、10年以内、おそらくもっと早く、結果が分かると話しています。リスクを管理できた場合は、本人の言葉で radical abundance です。生産性が大きく上がり、多くの人が豊かになる、という意味です。管理できなければ、貧富の差、文化をめぐる大きな問題、大規模な失業、社会が大きく不安定になる、という見通しです。記事には、この見通しの計算方法は書いてありません。測定した確率でもありません。
2026年後半か2027年の「チェルノブイリ」は、核事故の予測ではない
ヒントン氏は「今年の後半か来年には、チェルノブイリが起きる。それで人々が本当に注意するかもしれない」と話しています。インタビューは2026年11月3日なので、2026年の残りか、2027年です。
ガーディアンの説明では、これは核事故の予測ではありません。例は2つです。AIを使った攻撃で、電力の電圧が大きく下がること。金融システムが1週間止まることです。本人は、この規模なら社会は回復でき、各国の指導者が対策に注目するきっかけになる、と話しています。10年以内の見通しとは、時期も内容も違います。同じ予測としては扱いません。
ガーディアンによれば、ヒントン氏は2026年夏の事案を、1979年のスリーマイル島原発の部分的な炉心溶融にたとえています。同紙は、OpenAIのAIエージェントがHugging Faceへの侵入を企てた出来事として、この事案を書いています。スリーマイル島は、より大きな事故の前に起きた警告だった、というたとえです。侵入の経路と、処理を止める運用は、AIエージェントの脅威を終末論でも過小評価でも終わらせない──IT技術者が今変えるべき運用に整理してあります。この記事で分けるのは、報告書で確認できる事案と、ヒントン氏がその事案について話したたとえです。
3種類とも、出荷の承認にはしません
ここまでで分けたのは、近い時期の事故の予測、10年以内の見通し、まだ制御できているという直感です。3つとも本人の言葉です。同じ種類の根拠ではありません。
予測を、すでに起きた事故としては扱いません。直感を、安全が証明された証拠としては扱いません。極端な予測だけを議題にすると、今の権限設計が後回しになります。直感だけを出荷の理由にすると、権限設計はやはり後回しになります。
手順を全部書くシステムと、目標だけ渡すシステムは違います
インタビューの読み分けの次は、導入するシステムの確認です。従来の業務システムでは、人間が処理の手順を定義します。
銀行の振込を考えます。利用者が依頼すると、システムは残高を確認し、振込できる額かを判定し、認証を済ませてから送金します。例外も、開発者が条件として書きます。複雑なシステムでは、想定外の障害が起きます。それでも、ルールを書いたのは人間です。確認するのは、プログラムが設計どおりに動くかです。
生成AIのエージェントでは、目標だけを渡すことがあります。
「今月の売上を分析し、問題を調べ、必要な改善を実行してほしい」
データを取り、分析方法を決め、外部のサービスへ接続し、プログラムを書いて実行する流れを、エージェントが自分で組み立てることがあります。開発者は、その1つ1つの手順を指定していません。
確認する項目が増えます。設計どおりに動いたかだけでは不十分です。AIが選んだ行動を、その業務で実行してよいかも確認します。売上を改善するという目標に対して、顧客へ無断でメールを送る、商品の価格を変える、という行動は、目標には合うことがあります。
目的を達成できることと、その方法を実行してよいことは、別の確認です。
内部を全部説明できなくても、許可する操作は決められる
選んだ行動を実行してよいかを確認するとき、モデルの内部を全部説明できないと無理なのか、という疑問が出ます。
大規模言語モデルの内部では、膨大なパラメータで計算が行われます。ある回答や行動を、なぜ選んだのかを、いつも人が説明できるわけではありません。中身を説明できない技術を、人は制御できるのか、という問いが出ます。
巨大なクラウドでも、1人の技術者が、ソフトウェア、ネットワーク、データベース、外部サービスの内部を全部見ているわけではありません。アクセス制御、監視、冗長化、障害の検知、復旧手順を組み合わせて、障害が起きても原因を調べ、サービスを戻せるようにしてきました。
AIでも、先に決めるのは、内部の計算を完全に説明することだけではありません。何を許可し、何を禁止し、どの条件で止め、問題が起きたときにどう戻すかです。
分析用データの読み取りだけを許し、削除と更新は許さない。外部への送信には人の承認を置く。一定金額以上の取引は実行させない。異常な操作が出たら、そのエージェントの権限を止める。この制限は、自然言語の指示だけでは足りません。「この操作は禁止」と文章に書いただけでは、実行のときに拒否する仕組みにはなりません。アプリケーションとインフラの側で拒否します。
誤った判断が出ても、すぐ大きな被害にならないように、実行できる操作を制限します。
出力が毎回同じとは限りません。学習時になかった入力にも応答します。外部の文章に誘導されることがあります。複数の手順を自分でつなぐこともあります。この4つは、これまでのアクセス制御だけでは足りません。これまでの制御も使います。それに加えて、この4つへの対策を追加します。
能力を下げる、という意味ではありません。能力が高いシステムほど、許可する操作の制限も厳しくします。
モデルの外で動作を制限する設計は、エージェンティックAI時代のセキュリティは防御から統制へ——「動くAI」を止めずに制御する設計へにあります。
99%の正答率は、100回連続の成功を保証しない
許可する操作を決めても、正答率が高いだけで安全だとは判断できません。処理が速いシステムが、安全だとは限りません。正答率が高いAIが、業務を安全に終えるとも限りません。
あるエージェントが、100件のうち99件を正しく処理したとします。残りの1件が、機密の外部送信や、重要なデータの削除なら、その99%は運用の合格になりません。
連続して実行すると、全部が成功する確率は下がります。各操作が独立に99%で成功する、と仮定します。100回すべてが成功する確率は、0.99の100乗です。Python 3で、次の式を確認できます。確率の計算だけで、外部へは接続しません。
# 各操作の成功は独立、成功率は毎回 0.99、という仮定。
# 現実の失敗は独立とは限らない。この値を、そのまま稼働率には使わない。
success_rate = 0.99
for steps in (1, 10, 50, 100):
print(steps, success_rate ** steps)
この式の結果は、10回で約90.4%、50回で約60.5%、100回で約36.6%です。実際の失敗は独立とは限りません。いま動いているシステムの稼働率として、この数字を使うことはできません。説明できるのは、操作の回数が多いとき、1回ごとの正答率だけでは不十分だ、ということです。
確認するのは、期待した結果が出るか、誤った判断が大きな被害にならないか、想定外の入力や攻撃に耐えるかです。記録から、何を判断し何を実行したかを追えること、問題が起きたときに止め、切り離し、戻せることも見ます。ソフトウェアの品質保証やセキュリティでも、同じ種類の確認をします。
AIの運用では、正しい回答を出したかに加えて、別の確認が必要です。正しい権限で、許された手順を選び、許された範囲で動いたかです。ベンチマークの点数と、運用で必要な安全の評価は、分けて見ます。
出力の正しさを、モデル自身の説明に置かない原則は、「LLMに任せきり」が危ない理由——数学が示す限界と、設計で補う3つの原則にあります。この記事で追加して書くのは、正答率を連続した操作に当てはめたときの注意です。
プロセスを止めても、送ったメールは戻らない
正答率と権限を確認したあとに、よく出る対策が「人がいつでも止められる」です。停止できることは必要です。停止ボタンがあることと、被害を防げることは、同じではありません。
エージェントが外部サービスを使っているとします。実行プロセスを止めても、送信済みのメールは取り消せません。外部で始まった処理が続くこともあります。削除したデータが戻らないこともあります。
従来の設計でいうフェイルセーフと、多層防御が参考になります。フェイルセーフは、故障したときに安全な側へ倒す設計です。多層防御は、1つの対策が抜けても、別の対策で被害を止める設計です。大量のメールを任せるなら、送信前の確認に加えて、件数の上限、宛先の制限、異常の検知、送信待ちのキューを置きます。認証情報は短い期限で無効にできるようにし、必要なら外部への通信そのものを切ります。これらは、停止ボタンの代わりではありません。停止ボタンと併用する対策です。
AIがいつも安全な判断をする、とは考えません。誤る可能性を前提にして、誤ったときの被害が広がらないようにします。セキュリティでいうゼロトラストに近いのは、この制限です。ゼロトラストは、AIの判断を正しくする技術ではありません。認証、認可、最小権限で、AIの操作が影響する範囲を狭くする考え方です。最小権限は、作業に必要な権限だけを渡す原則です。
自分で手順を決める範囲が広がると、停止や修正の指示に従うか、という問題も出ます。AI安全性の研究では、人による修正や停止を受け入れる性質を Corrigibility（修正可能性）と呼びます。Nate Soares らが2015年に整理したのが、Corrigibility です。現時点で、あらゆる高度なAIにこの性質を必ず持たせる、広く合意された方法があるわけではありません。
モデルの研究と、システム側の制限は、同時に進めます。モデルが停止の指示に従うことだけに、被害防止を任せません。
技術で対策できても、会社や社会が実施するとは限らない
適切な設計をすればリスクは解決する、と読めるかもしれません。ヒントン氏の警告には、別の問題があります。安全対策が技術的に可能でも、企業や社会がそれを実施するとは限らない、ということです。
新しいモデルを早く出せば、利用者を獲得しやすいです。十分な安全の評価には、時間と費用がかかります。競合が次々に公開しているとき、評価を優先すると公開が遅れます。対策の費用は企業が負担します。大きな事故の被害は、利用者や社会に及ぶことがあります。1社が安全を優先しても、他社が先に公開すれば、その1社だけ不利になります。
医薬品、自動車、航空機、原子力では、進歩と安全の確認を両立させるために、独立した評価や規制が作られてきました。ヒントン氏がAIにも独立した評価を求めるのは、作った本人以外の確認が要る、と考えているからです。
本人の提案は、公開したあとに訴訟で正すやり方ではありません。米国の食品医薬品局（FDA）のように、公開の前に、独立した機関へ「利益が害を上回る」という十分な統計的証拠を出す、というものです。1950年代のサリドマイドでは、公開してから訴えるのは正しいやり方ではなかった、と話しています。大手のテクノロジー企業が今言っていることは、それと同じ扱いだ、というのがヒントン氏の主張です。
このたとえと同じ試験を、AIにそのまま使うことはできません。医薬品は、条件を決めた臨床試験で、有効性と副作用を統計的に見られます。汎用のAIは用途が広く、公開後に新しい使い方が生まれます。外部のツールと組むと、できることも変わります。公開前の評価だけでは、公開後の新しい使い方は確認できません。公開後の監視、事故の報告、継続した検証、必要なら利用の制限が必要です。
リスクの大きさも、全部が同じではありません。文章を要約するAIと、重要インフラの制御に関わるAIに、同じ合格基準にするのが妥当だとは限りません。用途と、被害の大きさで、求める安全を変えます。合格の基準を誰が書くかは、AIのルールは誰が書くのか——「安全のための協調」が調達を縛る前に考えることにあります。
2026年9月21日、フィンランドのアレクサンダー・ストゥブ大統領と、ノルウェーのヨナス・ガール・ストーレ首相は、A Call for Control of Frontier AI Models を出しています。フロンティアAIは、いま最も能力の高い水準のモデルを指します。呼びかけの中心は、AIは人の指揮、監督、制御のもとにあるべきだ、という一文です。企業には、公開前の必須の試験と、評価者がリスクを見るのに足りるアクセスを伴う独立評価を求めています。安全のルールを厳しくするとき、AIの利益を使える国と使えない国の差を広げない、とも書いています。
大統領府の The rapid development of AI requires international cooperation には、これまでに32か国から34人のリーダーが参加した、とあります。各国の法律として採択された文書ではなく、リーダーたちによる呼びかけです。ガーディアンは、ヒントン氏がこの呼びかけを支持している、と伝えています。呼びかけが先で、11月3日のインタビューがあとです。
人が主導権を持つには、技術で操作を制限するだけでは足りません。企業の責任、第三者の評価、社会のルールも必要です。ヒントン氏の言う大きな努力には、この3つも入ります。
導入するチームが先に書くのは、4つの確認項目です
前の節の企業の責任や社会のルールが整うまで、出荷チームの確認を後回しにはしません。先に書ける確認があります。研究者だけが安全に取り組めばよい、という分け方は、このチームには合いません。AIが業務に入ると、安全が変わるのはモデル単体だけではありません。そのモデルを呼ぶシステムの設計と運用でも変わります。
4つを書く前に、1つだけ決めることがあります。その業務を、AIに任せる必要があるかです。AIでできることと、AIでやるべきことは同じではありません。条件が書き切れる処理なら、従来のプログラムで足りることがあります。得られる利益と、新しく生まれるリスクを比べて、使う技術を選びます。AIに任せると決めたとき、次の4つを書きます。
どこまで判断を任せるか
情報の整理と提案までは任せ、契約や送金の最終決定は人が行います。リスクの低い定型処理は自動で実行し、リスクの高い処理だけ承認を必要にします。この区切りは、プロンプトの文章ではなく、呼べるツールの一覧として書きます。
検証では、何を見るか
自然で説得力のある文章でも、正しいとは限りません。業務で確認するのは、文章がうまいかではありません。根拠のデータと、実行した結果です。AIが書いたSQLを実行するなら、構文が通ることに加えて、参照するテーブル、更新する範囲、実行する権限を確認します。
失敗したときの影響を、どこで止めるか
間違うことを前提に、処理を小さい単位に分け、権限を狭くし、実行の履歴を残します。必要なら途中で止め、戻せるようにします。間違えないことだけを目標にすると、間違ったあとの止め方と戻し方が設計から抜けます。間違えても大きな事故にしないことを、もう1つの目標にします。
取り消せる操作と、取り消せない操作の分け方は、『人間の代替』をゴールにしない——アギーレ氏のBetter Pathを、AIエージェントの権限設計に落とすにあります。
誰の名前で実行するか
AIが判断した、という理由で、運用の責任は消えません。誰が承認し、どの基準で実行し、問題が起きたときに誰が対応するかを、設計の項目にします。責任者の名前が空欄の処理は、自動実行へ進める前の確認事項として残します。
コードを書く時間が短くなっても、任せる範囲は人が決める
4つの確認項目を書く仕事は、コードを速く書くこととは別です。これまで技術者に求められてきたのは、要求された機能を実現する力です。その力が不要になるわけではありません。
AIがプログラムを書き、テストを出し、障害の原因の候補を並べる環境では、機能を作る時間は短くなる可能性があります。そのとき必要になるのは、何を作るか、どこまで自動化するか、できたシステムが業務の中で安全に動くかを確認することです。
書く内容は、4つの問いです。AIの提案を、そのまま採用してよいか。性能が上がったとき、リスクは増えていないか。効率のために、人の確認が抜けていないか。問題が起きたとき、誰がその結果に対応するか。この4つを、権限の設定とテストの項目に書くことが、これからの仕事です。
そのために読む範囲は、モデルの仕組みだけではありません。ソフトウェア工学、情報セキュリティ、品質保証、運用、リスクの管理、必要な範囲の法と倫理です。全部を同じ詳しさで学ぶ必要はありません。自分のシステムで、どの判断が欠けているかを知るために使います。
AIで作業時間が短くなる部分はあります。技術を業務と社会の中で安全に動かす責任は、減りません。人と一緒に判断し、責任を持つことについては、「AIが使える」だけでは足りない——Gartnerの予測が示す、これから教育が育てるべき7つの力に書きました。結論は同じです。7つの力の一覧は、その記事にあります。
主導権は、使い方と許す操作を人が決める状態です
確認項目と、技術者の仕事を見たので、インタビューの最初の文に戻ります。まだ制御できている、というのは本人の直感です。うまくいく条件は、大きな努力です。
この文は、高度なAIのすべてのリスクを、今の技術で完全に制御できる、という意味ではありません。そのような保証は、現時点ではありません。雇用の変化、経済格差、偽の情報や偏った情報が広まること、決定の権限が一部の組織に集まることは、アクセス制御だけでは解決しません。
それでも、人が決められることはあります。どの権限を渡すか。どの用途に使うか。どの評価を通ったシステムを業務へ入れるか。危険が確認されたとき、どの制限を掛けるか。得られた利益を、誰のために使うか。これらは、性能が上がれば自動で決まる問題ではありません。
主導権は、あらゆる課題で人間の知能が上であり続けることでもありません。AIの方が高い能力を持つ分野が増えても、何に使い、どの操作まで許すかを、人の側が決める状態を維持することです。技術で操作を制限する問題であり、社会がどの使い方を選ぶかの問題でもあります。
次のレビューでは、4つの確認項目を空欄にしない
主導権の意味は、前の節のとおりです。人が、使い方と許す操作を決める状態です。次の設計レビューで書くのは、その状態をシステムの設定にすることです。
AIの進歩を止めるか、加速させるかだけでは、そのレビューは終わりません。能力が上がる速度に対して、評価と制限と運用が追いついているかを見ます。性能の研究と安全の研究、新しい機能と想定外の動作の検出は、どちらも必要です。導入するチームがレビューで決められるのは、もっと手前の項目です。
アクセス権限をどう分けるか。ログをどこまで残すか。どの処理に承認を置くか。異常をどう見つけるか。障害のとき、被害をどこで止めるか。これらは、日々の開発と運用で、すでに決めていることです。4つの確認項目は、この日常の決めごとを、エージェント向けに書き直したものです。
従来の技術で対処できる問題と、新しい研究、制度、国をまたいだ協力が必要な問題の、両方があります。システムを設計する人、導入を決める組織、運用する人にも、決められることがあります。
ヒントン氏の警告は、悪い結果がもう決まった、という予測として扱う必要はありません。今なら、大きな努力の具体的な内容を書ける、という呼びかけです。出荷してよいかは、確認して書いた項目で判断します。
次の設計レビューでは、エージェントに渡すツールを増やす前に、4つの確認項目を書きます。任せる判断、検証する対象、失敗を止める位置、実行の責任者です。1つでも空欄なら、その操作は自動実行へ進める前の確認事項として残します。
人間が主導権を持つかは、AIの性能だけでは決まりません。任せる判断、検証する対象、失敗を止める位置、実行の責任者。この4つを、今の設計でどう書くかでも決まります。
作成日: 2026-11-04