AIが成果を増やすほど確認が詰まる——数学400件とローカルAIから作る「検証待ち在庫」

AIを導入すると、文章、コード、分析、候補案を作る時間は短くなります。ところが、生成が速くなった分だけ仕事全体も速くなるとは限りません。読む人、試す環境、責任を持って承認する人が増えなければ、成果らしきものが確認待ちのまま積み上がるからです。

2026年10月、OpenAIが約400件の数学上の結果を700本超の原稿として公開したとThe Vergeが報じました。専門家が全体像を理解するには年単位を要するとの声があり、形式化された結果も一部にとどまります。同じ週、The Vergeの記者は大容量メモリーのMac StudioでローカルAIを動かし、日次通知やゲーム整理には使えた一方、定期処理の失敗やベンチマーク自動化の調整が続いていると記しました。ITmedia AI＋は、Google Cloudが単一モデルへ固定せず、GeminiとClaudeなどを仕事ごとに選ぶ「Gemini Agent」を発表したと伝えています。

規模は違っても、三つのニュースは同じ運用課題を示します。AIは一件を作る速度だけでなく、候補の数、使うモデルの数、やり直しの数も増やします。日本企業が次に測るべきなのは「何件生成したか」ではなく、「確認できる状態へ何件を運び、何件を責任ある判断で閉じたか」です。

以前の記事では、本番へ副作用を出さずに能力を測るAIの評価用世界を整理しました。また、生成された画面の見た目と実行結果を分ける画面受入票も提案しました。今回は、その二つを通過する前に増える「検証待ち在庫」を、仕事量として管理する方法を考えます。

結論——AI成果は生成数ではなく、五つの状態で数えます

AIが作った出力を、完成品という一つの箱へ入れてはいけません。少なくとも次の五段階へ分けます。

状態	意味	次へ進む条件
生成済み	AIが候補を出した状態	対象、目的、作成条件が記録されています
再現済み	同じ入力や環境で結果を確かめた状態	入力、モデル、版、道具、実行条件が残っています
反証済み	間違いを探す試験を通した状態	例外、境界値、既知の反例、別手法と照合しています
理解済み	担当者が根拠と限界を説明できる状態	採用理由と見送り理由を第三者へ説明できます
採用済み	責任者が用途と影響範囲を決めた状態	公開、実行、顧客提供、意思決定への利用が承認されています

この表で「生成済み」が増えても、組織の成果が同じだけ増えたとは扱いません。再現できない案、反例で崩れる分析、誰も説明できないコードは、可能性のある在庫です。価値へ変わるには、検証と判断が必要です。

製造業の仕掛品と同じように、検証待ち在庫には保管費用があります。古くなった資料との差分確認、モデル更新後の再実行、担当者への説明、重複候補の整理、誤って利用されないためのアクセス制御が必要です。生成費が安くても、在庫を維持する費用はゼロではありません。

数学400件が示したのは「発見速度」と「理解速度」の分離です

The Vergeの報道によると、OpenAIの公開物は約400件の結果、719本の原稿に及び、組合せ論、幾何学、数論、理論計算機科学、代数、確率、数理物理など広い領域を含みます。専門家の中には、目次と要旨を眺めるだけでも相当な時間がかかったと話す人がいました。

重要なのは、件数の大きさだけではありません。記事では、公開時点で形式化された上位結果が300件で、719本の原稿に対して約42％だったと説明されています。Leanなどの証明支援系で形式化されていても、そのコードが原稿の主張そのものを証明しているか、定義や前提が適切かを人が照合する必要があります。機械で確認できる形式が付いたことと、研究共同体が意味を理解し、既存研究の中へ位置付けたことは同じではありません。

公開後には十数本を超える原稿が修正され、符号の誤りで議論が成り立たないとして3本が取り下げられたとも報じられました。一方で、専門家が非常に高い価値を持つ可能性を認めた結果もあります。ここから導けるのは「AIの成果は信用できない」という単純な結論ではありません。良い候補と誤った候補が同じ速度で届くと、選別能力が希少資源になるということです。

企業の企画、法務調査、障害分析、商品説明でも構造は似ています。AIが百案を作れば、見落としていた良案を得られる可能性は上がります。しかし、百案の根拠、重複、前提、影響を確認する担当者が一人のままなら、入口だけが広がります。生成量を成果指標にすると、確認できない在庫を増やす行動が評価されてしまいます。

数学では形式証明、原稿、引用、専門家の理解が別の層になります。企業では自動テスト、実行ログ、出典、業務担当者の説明、責任者の承認がそれぞれ別の層です。自動テストが通ったコードでも、顧客データの扱い、運用時の復旧、法的な表示まで自動的に合格するわけではありません。層を一つの点数へ潰さないことが出発点です。

高価なローカルAIでも、仕事の最後の一歩は自動では埋まりません

The VergeのローカルAI試用記は、研究機関ではなく個人の机で同じ問題が起きることを示します。記者は256GBのユニファイドメモリーを備えたMac StudioでHermes Agentと大規模なQwenモデルを動かしました。クラウドへ出したくない財務記録や公開前情報をローカルで扱えることは、実際に使うかどうかを変える利点でした。

一方、最初の日次通知はMacがスリープしている時間に動かず、何度か失敗しました。Steamのゲーム整理は短時間で役立つ結果を出しましたが、APIキーを一時的に渡し、作業後に失効させる運用が必要でした。ノートPCのベンチマークを繰り返す自動化は、手順を教え、スクリプトを調整する作業が続いています。

ここでは、モデルのパラメーター数や端末価格だけでは完了率を説明できません。起動条件、権限、外部サービス、例外処理、結果の確認、認証情報の撤回までが一つの仕事です。AIがスクリプトを数分で作っても、三回の測定が同じ条件で走り、途中失敗を検知し、平均値の元データを保存できなければ、比較記事に使える測定にはなりません。

ローカルAIは、機密情報を外部サービスへ送らない選択肢を増やします。ただし「ローカルだから正しい」「クラウドだから危険」という二択ではありません。ローカルでは端末のスリープ、容量、更新、権限、ログ保全を自分で運用します。クラウドでは提供者の変更、利用枠、保存条件、障害、契約を管理します。場所が変わると確認項目が変わるのであり、確認そのものが消えるわけではありません。

マルチモデル化は精度競争だけでなく、検証経路を増やします

ITmedia AI＋の報道によると、Google Cloudが発表したGemini Agentは単一モデルに固定せず、仕事に応じてモデルを選ぶ構想を掲げています。発表時点ではGemini 4 Argonに加え、Claude Opus 5.5とClaude Sonnet 5.5を利用でき、他のクローズドモデルやオープンモデルも追加予定と説明されました。既存サービスとの関係、料金、日本での提供予定には未確定の点も残っています。

複数モデルを使えることは、特定ベンダーへの固定を弱め、仕事に合う能力を選びやすくします。その一方で、同じ指示でもモデルごとに出力、拒否、道具の使い方、引用の仕方が変わります。経路が自動で選ばれるなら、担当者が見ているサービス名と、実際に処理したモデルが一致しない場面も生まれます。

以前の記事では、仕事ごとに必要能力、データ境界、実行権限、利用枠、代替経路を記す能力アクセス表を提案しました。検証待ち在庫では、そこへ「生成経路」を足します。少なくともモデル名、版、選択理由、利用した道具、参照資料、生成日時を候補ごとに残します。

モデルを切り替えて同じ答えが出れば、それだけで正しさが証明されるわけではありません。二つのモデルが同じ古い資料を参照したり、似た学習データの誤りを繰り返したりする可能性があります。別モデル照合は有力な反証手段ですが、一次資料、計算、実行試験、現場知識の代わりにはなりません。

逆に、モデル間で答えが違うことは失敗だけではありません。前提が曖昧、資料の日付が違う、判断基準が書かれていない、といった問題を見つける入口になります。差分を多数決で消さず、「何が違うから結論が分かれたか」を一件の検証課題として在庫へ戻します。

「検証待ち在庫票」は一件を七欄で管理します

日本企業で使うなら、AI出力一件につき次の七欄を残します。

1. 目的：この出力で誰のどの判断を助けるかを記します。
2. 生成経路：モデル、版、指示、道具、参照資料、生成日時を記します。
3. 影響範囲：社内下書き、顧客表示、金銭、契約、公開、機器操作などを分けます。
4. 確認方法：自動試験、一次資料照合、別計算、専門家確認、利用者試験を割り当てます。
5. 反証結果：見つかった例外、未解決の差分、取り下げた主張を残します。
6. 期限と責任者：いつまで有効か、誰が次の状態へ進めるかを決めます。
7. 出口：採用、限定採用、差し戻し、保留、廃棄のどれかで閉じます。

票の目的は文書を増やすことではありません。確認できない候補を「ほぼ完成」と呼ばないためです。たとえば、AIが市場予測を二十件作ったとします。翌日の会議で使うのが三件なら、二十件全てを同じ深さで確認する必要はありません。影響が大きく、意思決定に使う三件へ確認時間を集中し、残りは期限付きの保留か廃棄にします。

保留には期限が必要です。AI出力は、参照した価格、制度、製品仕様、社内データが変わると古くなります。三カ月後に再び使う候補は、保存時の状態からそのまま採用せず、資料の鮮度と生成条件を再確認します。期限を過ぎた在庫を自動で「未確認」へ戻す方が安全です。

廃棄も成果です。重複、根拠不足、影響に対して確認費が高すぎる候補を早く閉じれば、重要な出力へ人の時間を使えます。「生成したから残す」という心理を捨て、確認能力を守るために捨てる基準を持ちます。

指標は生成量から「閉じた一件」へ移します

AI活用の週次報告で、生成文書数、トークン数、利用者数だけを並べると、在庫の増加を進捗と誤認します。最低限、次の七つを並べます。

指標	見る理由
新規生成数	入口の量を把握します
再現済み数	条件を残せた候補を数えます
反証実施率	間違いを探す工程が省かれていないか見ます
採用数	実際に価値へ変わった量を数えます
差し戻し・廃棄数	早期に閉じた判断も評価します
検証待ち日数	滞留と鮮度低下を見ます
人の確認時間	生成費の外にある実コストを見ます

主指標は、採用数だけでも不十分です。承認を急げば採用数を増やせるからです。反証実施率、重大な修正件数、採用後の事故や手戻りも守る指標にします。数を競わせるのではなく、速さと品質が同時に悪化していないかを見ます。

検証待ち日数が伸びたとき、単純に担当者を増やす前に入口を絞ります。一度に作る候補数、対象領域、実行できるモデル、使える資料を制限し、確認能力に合わせます。数学のように価値が未知の探索では広い生成が必要な場合もありますが、その場合は公開前の選別、履歴、形式化、専門家への支援を生成計画へ含めるべきです。

30日で始めるなら、一つの定例資料で在庫を見える化します

第一週は、AIが作る定例資料を一つ選びます。営業会議の要約、問い合わせ分類、障害報告、競合調査など、毎週発生し、採用したかどうかを追える仕事が向きます。過去四週間について、生成数、採用数、差し戻し数、確認に使った時間を概算します。

第二週は、五つの状態と七欄の票を使います。全候補へ長い説明を書くのではなく、生成時にモデル、版、資料、日時を自動記録し、人は目的、影響、出口を補います。個人名や秘密情報を不要に保存しないよう、証拠と機密の境界も決めます。

第三週は、意図的に反例を入れます。古い価格、欠けた資料、単位違い、例外顧客、権限不足、競合する一次資料を使い、どこで止まるかを見ます。同じ候補を別モデルへ渡す場合は、結論の一致率より差分の理由を記録します。

第四週は、入口制限を試します。たとえば、AIに十案ではなく三案を作らせ、各案へ根拠と見送り条件を付けます。確認時間、採用率、手戻り、会議時間がどう変わるかを比べます。三案で意思決定の質が変わらないなら、残り七案は価値ではなく在庫だった可能性があります。

30日後に残すべき仕組みは、最も多く生成した方法ではありません。確認待ち日数を抑え、誤りを見つけ、採用理由を別担当者が説明でき、期限切れの候補を閉じられた方法です。

出典

• The Verge「‘Pure insanity’: Mathematicians will need years to make sense of OpenAI’s latest drop」（2026年10月9日）
• The Verge「Learning to use local AI is exciting, overwhelming, and frustrating」（2026年10月11日）
• ITmedia AI＋「Google『Gemini』新サービスで『Claude』利用可能に」（2026年10月9日）

AIが作った次の一件を、誰が理解できるでしょうか

AIが成果候補を増やすこと自体は前進です。数学の未解決問題、新しいコード、業務改善案の中には、人だけでは届かなかった価値が含まれるかもしれません。しかし、候補の量をそのまま成果と呼べば、理解、反証、説明、責任という仕事が見えなくなります。

これから希少になるのは、文章を書く手や案を出す時間だけではありません。正しい問いを選び、反例を探し、根拠をつなぎ、使える範囲を決め、誤りなら取り下げる能力です。AIの生成速度を落とす必要はなくても、確認能力を超えて在庫を増やさない入口は必要です。

次の会議で「AIが百案を作りました」と報告されたら、もう一つだけ尋ねてみてください。「そのうち、別の担当者が根拠と限界を説明でき、責任を持って閉じたのは何件ですか」。その答えを毎週数えられる組織から、AIの速さを本当の仕事の速さへ変えられるのではないでしょうか。