AIに「やらせる」だけでは足りない：実行するエージェントと証明するモデルの融合

「このアプリを作って」「競合サービスを調べて」「ブラウザ上で手続きを完了して」。こうした指示を、AIが数分で実行できるようになりつつある。

しかし、ここで見落とされがちな問題がある。AIが仕事を終えたように見えることと、本当に正しく仕事を終えたことは、まったく別だ。

ブラウザを操作して複雑な作業を片づけるAIエージェントと、証明支援系からフィードバックを受けて数学的推論を改善する巨大モデル。一見すると、前者は実務、後者は研究であり、接点がないように見える。だが両者は、AIの次の段階を考えるうえで同じ問いに答えようとしている。

AIは、答えを出す機械から、結果を検証しながら世界に介入する機械へ変わるのか。

この問いの核心は、モデルの大きさではない。AIが自分の出力を、外部の現実によって検査し、修正できる設計になっているかどうかである。

「できる」と「正しい」の間にある巨大な溝

テキスト生成型のAIは、もっともらしい文章やコードを出力する。しかし、その出力が現実の環境で機能するかどうかは、生成した瞬間には確定していない。

たとえば、動画配信サービスの複製を作るよう指示されたAIが、画面構成、再生機能、検索、ユーザー導線を短時間で組み立てたとする。見た目だけなら、完成品に見えるかもしれない。だが実際には、動画が途中で止まる、特定の画面幅で崩れる、ログイン状態が失われる、検索結果と再生対象が一致しない、といった問題が残っている可能性がある。

人間の開発者なら、ブラウザを開き、ボタンを押し、入力を変え、エラーを読み、コードを修正する。この反復によって、設計図は製品へ近づいていく。ブラウザを操作するAIエージェントの重要性は、単にクリックを自動化することではない。AIの出力を、現実の反応にさらすことにある。

同じ構造は数学にも存在する。数学的な証明を生成するモデルは、自然言語で説得力のある説明を書くだけでは不十分だ。証明支援系に受理されなければ、その証明は成立したとはいえない。形式化されたルールに照らして拒否され、どこが誤っているかというフィードバックを受け、再び推論を組み立て直す必要がある。

ここには、AIの信頼性を考えるための重要な区別がある。

生成は可能性を作る。検証は現実性を決める。

AIの能力が急速に伸びているように見える理由の一つは、生成能力だけを測っているからだ。だが、実際の仕事で価値を生むのは、候補を大量に作ることではない。失敗を発見し、修正し、再試行し、最終的に受け入れられる結果へ到達することである。

AIの本当の進歩は、最初から正しい答えを出すことではない。間違いを、外部の現実から学習できることだ。

ブラウザと証明支援系は、同じ種類の教師である

ブラウザは、AIにとって単なる道具ではない。ある意味では、巨大な採点システムである。

AIが検索欄に誤った入力をすれば、期待した結果が返らない。購入手続きで必須項目を埋めなければ、次の画面に進めない。コードを書いても、ボタンを押したときに何も起きなければ、その実装は失敗している。ブラウザは、世界を完全に説明してくれるわけではないが、少なくとも「その操作が通ったか」「画面が変化したか」「目的に近づいたか」という観測可能な信号を返す。

証明支援系も同じである。証明支援系は、AIの文章を褒めたり、意図を推測したりしない。公理と規則に照らして、受理するか拒否するかを返す。この厳格さが、モデルの推論を訓練する信号になる。

両者の違いは、環境の性質にある。ブラウザの世界は曖昧で、外部サイトの仕様変更、ネットワーク障害、表示の遅延、ユーザーの状態などが入り込む。一方、形式化された証明の世界は、より閉じており、受理条件が明確だ。それでも、学習の基本構造は驚くほど似ている。

1. AIが行動や推論を生成する
2. 外部の環境が結果を返す
3. 結果の失敗点を特定する
4. 次の試行で方針を修正する

このループを、生成と検証の閉ループと呼ぶことができる。

従来のAI利用は、依頼して回答を受け取り、人間が最後に確認するという一方向の流れだった。閉ループ型のAIは、回答を出した後に自分でテストし、検査し、必要なら作り直す。人間はすべての中間手順を監督するのではなく、目的、制約、合格条件を定義する役割へ移っていく。

これは、AIに自主性を与えるという話だけではない。むしろ重要なのは、自主性に制約を与えることである。自由に行動するAIは便利だが、自由に間違えるAIでもある。信頼できるエージェントとは、何でもできるシステムではなく、何をすれば成功と判定されるかが明確なシステムだ。

自然言語は、命令ではなく仕様になる

アプリ、ゲーム、ブラウザ拡張機能をテキスト指示だけで作れるという現象は、ソフトウェア開発の入り口を変えている。これまで、アイデアを実装に変換するには、プログラミング言語、開発環境、設計パターン、デバッグの知識が必要だった。

しかし、自然言語がそのまま実装指示になると、最初の障壁は大きく下がる。問題は、作れるかどうかから、何を作ったことにするのかを定義できるかどうかへ移る。

「動画を再生できるアプリを作って」という指示は、まだ仕様として粗い。どの形式の動画か。再生に失敗したときはどう表示するか。通信が遅いときはどうするか。字幕は必要か。視聴履歴は保存するのか。スマートフォンで操作できるか。こうした条件がなければ、AIは自分にとって最も簡単な解釈を採用する。

つまり、自然言語による開発では、コードを書く能力よりも合格条件を言語化する能力が重要になる。

数学の証明でも同じだ。単に「この命題を証明して」と言うだけでは、探索空間が広すぎる。使える補題、許容される公理、証明の形式、計算量の制約などが明確になるほど、検証可能な推論が可能になる。

ここから、AI時代の仕様書について新しい見方が得られる。

仕様書とは、作りたいものの説明ではない。失敗を検出するための観測条件の集合である。

動画再生アプリの仕様に「再生ボタンがある」と書くより、「有効な動画を選択すると、二秒以内に再生状態へ移行し、通信失敗時には再試行可能なエラーを表示する」と書いたほうが、AIは自分の仕事を検査できる。数学で「証明を作る」と言うより、「形式検証を通過する項を構成する」と定義したほうが、成功条件は明確になる。

この考え方は、AIに仕事を任せるすべての人に関係する。良い指示とは、詳しい指示ではない。判定可能な指示である。

次の競争は、モデルの性能より検証環境の設計になる

巨大なモデルは、より多くの候補を生成し、より長い手順を計画し、より複雑な関係を扱える。しかし、モデルの性能だけを高めても、検証環境が弱ければ、失敗の速度が上がるだけかもしれない。

たとえば、AIが百個のウェブサイト案を作れても、アクセシビリティ、表示速度、セキュリティ、法的要件を確認できなければ、実務上の価値は限定的だ。逆に、比較的小さなモデルでも、明確なテスト環境と反復的なフィードバックがあれば、狭い領域で非常に高い信頼性を発揮できる。

これは、AIシステムを評価する尺度を変える。これまで私たちは、モデルに「何を知っているか」「どれほど自然に答えられるか」を尋ねてきた。これからは、次のような質問が重要になる。

1. 失敗をどのように検出するのか
2. 検出した失敗を、次の試行にどう反映するのか
3. 途中で危険な操作を止められるのか
4. 成功を誰が、何によって判定するのか
5. 結果を再現できるのか

この視点に立つと、ブラウザエージェントと証明モデルは、異なる製品ではなく、検証環境の異なるエージェントに見えてくる。

ブラウザエージェントの環境は、現実のサービスや画面である。証明モデルの環境は、形式規則と証明支援系である。前者は柔軟だが不安定で、後者は厳密だが限定的だ。将来的に強力なシステムが実現するなら、それは両方の性質を組み合わせるだろう。

つまり、自然言語で目的を理解し、ブラウザや開発環境で行動し、形式テストや実行テストで検証し、失敗の原因を分析して再試行するシステムである。最終的な理想は、人間の代わりに考えるAIではない。考えた結果を、現実と論理の両方に照らして確かめられるAIだ。

人間に残る仕事は「作業」ではなく「現実の設計」である

AIが作業を引き受けるほど、人間の役割は消えるのではなく、上流と下流へ移動する。

上流では、何を作るべきかを決める必要がある。顧客の本当の問題は何か。どの制約を優先するのか。どの失敗は許容できず、どの失敗は許容できるのか。下流では、AIの成果物が現実に導入された後、誰にどんな影響を与えるかを見なければならない。

AIがブラウザ上で手続きを完了できるなら、その手続きが本当に本人の意図に沿っているかを確認する必要がある。AIがアプリを生成できるなら、そのアプリが個人情報をどう扱うかを確認しなければならない。AIが数学的に正しい証明を作れても、その定理が現実の意思決定に適切に使えるとは限らない。

形式的な正しさと、目的への適合性は別物である。証明支援系は論理的な誤りを見つけられるが、そもそも証明すべき命題の選び方までは決めてくれない。ブラウザは操作の成功を返せるが、その操作が倫理的に妥当かまでは保証しない。

だから人間の最重要スキルは、AIをうまく使うための小技ではなく、検証可能な世界を設計する能力になる。

仕事をAIに任せるときは、依頼文を長くする前に、次の三つを定義するとよい。

1. 目的: 最終的に何を変えたいのか
2. 制約: 何をしてはいけないのか
3. 検証: 何が起きれば成功とみなすのか

この三つが揃えば、AIは単なる文章生成器から、試行錯誤する実行者へ変わる。逆に、検証がなければ、どれほど流暢なAIでも、成果物を大量に生産するだけの幻覚装置になりうる。

Key Takeaways

1. AIへの依頼には、必ず合格条件を含める 「作って」ではなく、「この入力に対してこの結果になり、失敗時にはこの状態を返す」と指定する。判定可能な指示ほど、エージェントは自律的に改善できる。

2. 生成と検証を別工程にしない コード、文章、調査結果を一度受け取って最後に確認するのではなく、テスト、実行、比較、再試行を最初からワークフローに組み込む。

3. AIの能力ではなく、フィードバックの質を設計する 「違う」と言うだけでは弱い。どの条件に違反したか、どの観測結果が期待と異なるかを機械的に返せる環境を作る。

4. 自然言語を仕様書として使う 機能の説明だけでなく、境界条件、禁止事項、エラー時の挙動、成功の測定方法まで書く。詳しさより、検査可能性を優先する。

5. 最終判断を自動化しない領域を決める AIが論理的に正しい結果を出しても、目的、倫理、責任の問題は残る。自動実行の範囲と、人間の承認が必要な地点を事前に線引きする。

AIの未来を、より賢いチャットボットの登場として考えると、本質を見失う。大きな変化は、モデルが一度で正解を言えるようになることではない。モデルが、外部の世界から拒否され、失敗を観測し、計画を修正し、再び行動できるようになることだ。

ブラウザを操作するエージェントは、AIに現実との接点を与える。証明支援系は、AIに厳密な拒否と受理を与える。この二つを結びつけると、AIの知性を測る新しい定義が見えてくる。

知性とは、答えを出す能力だけではない。自分の答えが現実に耐えるかどうかを確かめ、耐えなければ作り直す能力である。

これから価値を持つのは、AIに最も多くの仕事をさせる人ではない。AIが間違えたとき、すぐに発見できる環境を作る人だ。AI時代の優れた仕事は、完成品を一度で生成することではなく、間違いが見える仕組みの中で、完成へ向かう反復を設計することなのである。