AIの成果は「何％削減」だけで決めない——数学・工場・基幹刷新に共通する再現条件

AIのニュースには、分かりやすい大きな数字が並びます。未解決問題を100件以上解いた、開発工数を約8割減らした、AIを使えば古いシステムを速く刷新できる。どれも可能性を感じさせますが、その数字だけを自社の計画へ移すと、実証では成功したのに本番では続かないという落差が生まれます。

2026年9月22日に重なった三つのニュースは、その落差を考える材料になりました。OpenAIは数学者による独立諮問グループとの連携を発表し、社内モデルが100件を超える未解決問題を解決したと説明しました。キユーピーの工場シミュレーションでは、小規模モデルの開発工数が8.5人日から1.8人日へ減りました。一方、Gartnerの予測を紹介したITmedia エンタープライズの記事は、2026年に始まるメインフレーム離脱案件の70％超が意図した利益を生み出せない可能性を伝えています。

これは、AIが使えるか使えないかという対立ではありません。三件を並べると見えてくるのは、成果の数字より先に、誰が問題を定義し、どの環境で試し、誰が確かめ、別の規模へどう移すかを残す必要があるということです。本記事では、この一式を「再現条件」と呼びます。

結論——成功の数字には五つの再現条件を添えます

AIの成果を導入判断へ使うときは、削減率や解決件数を単独で記録しません。少なくとも次の五つを同じ成果票へ添えます。

再現条件	記録する問い	条件がないと起きること
対象	何を一件と数え、難しさをどう区分したか	小さな成功を全業務へ広げます
環境	どのデータ、道具、権限、実行場所を使ったか	試験環境だけの能力を本番能力と誤認します
比較	何と比べ、準備・確認・再作業を含めたか	見えない人手を削減分から外します
評価	誰が正しさと影響を確かめ、反対意見を公開できるか	開発側の自己採点で成果が閉じます
移送	規模、担当者、工場、システムが変わると何を再試験するか	一度の実証をそのまま横展開します

この五項目は、AIを慎重にしすぎて止めるための書類ではありません。どこまで再利用できるかを早く判断し、条件が違う場所だけを試し直すための地図です。条件を残せば、小さな成功を過小評価せず、大きな数字も過信せずに扱えます。

OpenAIの数学発表が示した「解けた」と「認められた」の違い

TechCrunchの報道によると、OpenAIはプリンストン高等研究所を拠点とする「Advisory Group on Mathematics and Artificial Intelligence」と連携します。同社は同じ発表で、社内モデルが数学の幅広い分野で100件を超える未解決問題を解決したと主張しました。

ここで大切なのは、100という件数をそのまま数学的な確定成果の数として読まないことです。問題が解けたというモデル側・企業側の主張と、証明が正しく新規性があり、先行研究の帰属が適切で、学術共同体が検討できる形で公開されたことは別の段階です。

背景には、ナビエ・ストークス方程式を巡る発表や、AI企業間の競争が論文化、引用、帰属を急がせることへの数学者の批判がありました。TechCrunchは、25人のフィールズ賞受賞者が名を連ねた公開書簡にも触れています。新しい諮問グループは成果の意義を評価し、公表の調整について助言でき、求められていない意見も出せます。メンバーは無報酬で、意見を公開できる点には独立性があります。

同時に限界も明確です。グループはOpenAI内部の数学研究の速度を遅くしたり、研究方針を決めたりする権限を持ちません。高等研究所自身も、助言はするがAI企業の意思決定権はなく、決定責任は企業に残ると説明しています。

日本企業がここから学べるのは、外部有識者を置けば独立評価が完成するわけではないことです。次の四つを分けて記録する必要があります。

1. 結果を閲覧できる範囲です。
2. 追加資料や再実行を求められる範囲です。
3. 公表前に異議を示せる範囲です。
4. 公開、延期、中止を決められる範囲です。

「第三者が参加」とだけ書くと、この四つが一つに見えます。閲覧だけできる人と、再現試験を要求できる人と、公開停止を決められる人では役割が違います。成果票には委員の肩書ではなく、使える資料、反証する時間、意見の公開権、決定権の有無を残します。

キユーピーの78.8％削減は、数字より土台が重要です

＠ITが紹介したキユーピーの事例では、工場シミュレーションソフト「Tecnomatix Plant Simulation」の小規模モデル開発にAIエージェントのDevinを使いました。従来8.5人日と見込まれた作業を1.8人日で完了し、78.8％削減したとされています。

この数字は魅力的ですが、記事は同時に適用範囲も示しています。現時点では小規模な一つのシミュレーションモデルでの実績です。初期には多数の不具合修正が必要で、基盤を整備した後に一回の作り直しで完了する段階へ進みました。したがって、78.8％はAIを接続した初日から自動的に得られた比率ではありません。

対象の仕事には三つの壁がありました。専用言語SimTalkは一般的な学習資料が少なく、汎用モデルが正しく書きにくいこと。実行環境はGUI中心のローカル環境で、クラウド上のAIが生成したコードをその場で試しにくいこと。専門チームの知識を他の担当者や工場へ展開する道筋が見えにくいことです。

対応も三層でした。クラウドのDevinへ専門用語、ルール、作業手順を集約し、誰が使っても学習資産へ到達できる入口を作りました。生成コードの実行と修正はローカルのDevin CLIへ切り出し、実際のPlant Simulationでエラーを見つけて直す循環を作りました。さらに、誤りの自動検出と作業ごとのPlaybookを整備し、一度の成功を次の仕事で再利用できる形にしました。

つまり、成果の本体はコードを速く書いたことだけではありません。クラウド上の知識、ローカル上の実行、専門家の判断をつなぐ試験設備を作ったことです。AIの速度は、その設備の上で初めて意味を持ちます。

ここで比較対象の作り方にも注意が必要です。8.5人日と1.8人日を比べるときは、次の時間を同じ箱に入れます。

• AIが参照する辞書や手順を初めて整える時間
• 専門家が期待する挙動を説明する時間
• ローカル実行環境とCLIを接続する時間
• 生成コードを試し、誤りを分類する時間
• 次回のためにPlaybookを更新する時間
• 完成したシミュレーションが現場の目的に合うか判断する時間

初期整備は将来の複数案件で再利用できるため、一件へ全額を負担させる必要はありません。ただしゼロとして扱うこともできません。「今回の作業時間」と「再利用する基盤整備時間」を分け、十件、五十件へ広げたときに一件当たりがどう変わるかを見る方が実態に近づきます。

この考え方は、AIで浮いた時間の配分を整理した記事ともつながります。削減時間は、そのまま利益ではありません。辞書の更新、例外の確認、現場への説明、次の担当者の育成へ配って初めて、継続できる能力になります。

小規模モデルから工場全体へ移すとき、難しさは直線で増えません

一つの小規模モデルが動けば、次は大規模な生産ラインや複数工場へ広げたくなります。しかし、規模が十倍になると工数も単純に十倍になるとは限りません。設備間の依存、停止条件、例外品、清掃、保全、作業者の交代、原材料の揺れが組み合わさるからです。

横展開では、モデルの大きさだけでなく差分の種類を見ます。

変わる条件	再試験する内容	人が決めること
生産品目	工程順、切替時間、不良条件	何を最適化し、何を守るか
設備	能力、停止、保全、代替経路	現実に許せる運転範囲
工場	レイアウト、人員、勤務、規程	共通化できない現場差
データ	欠損、時刻、単位、更新頻度	採用する基準値と例外
担当者	用語、権限、経験、説明方法	誰が最終判断を引き受けるか

AIがSimTalkを書けることと、工場の目的を選べることも分けます。生産量を最大化すると、段取り替え、在庫、残業、品質、保全のどれかへ負担が移るかもしれません。モデルが想定通り動くことはソフトウェア上の成功ですが、現場が安全に使えることは業務上の成功です。

小さな実証から次へ進む条件は「成功したから全工場へ」ではありません。「前回と同じ条件」「変わった条件」「まだ試していない条件」を三列に分け、変わった部分だけを意図的に試すことです。これが移送の再現条件になります。

メインフレーム刷新の失敗予測が示す、コード変換の外側

ITmedia エンタープライズの上半期まとめは、Gartnerが2026年6月に示した予測として、2026年に開始されたメインフレーム離脱プロジェクトの70％超が意図した利益を生み出せずに終わる可能性を紹介しました。要因の一つとして、複雑なレガシーコードの変換や移行に対する生成AI能力の過大評価を挙げています。

ここでも「AIは役に立たない」と読むのは早計です。同じ記事には、4.6億行のレガシーコード解析を、従来見積もりの6.5年から20時間へ短縮した事例が並びます。解析、候補抽出、現新照合の不一致原因提示など、狭く定義した工程ではAIの速度が大きく効く可能性があります。

問題は、コードを読んだことをシステム刷新の完了と数えることです。基幹システムには、仕様書へ残っていない商習慣、例外顧客への対応、月末だけの処理、障害時の手作業、規制への対応が埋まっています。変換後のコードが動いても、なぜその処理が必要だったかを失えば、業務は正しく続きません。

記事で紹介された日立の説明は、「足りないのはCOBOL人材ではなく、現行システムがなぜそうなっているか、業務がどうなっているかを知る人材」というものでした。AIが構文を変換できても、「なぜ」の採否は自動的に決まりません。古い例外を残すのか、標準業務へ戻すのか、法的義務なのか、過去の事故対策なのかを区別する必要があります。

さらに、日本では刷新を先送りしにくい事情があります。記事によれば、日立はVOS3の販売を2027年11月、保守を2034年12月に終了する方針です。SAP移行では、数億円規模の案件でも十五社すべてが提案を辞退した事例が紹介されました。AIを過信できず、経験者と外部支援も不足する中で、利用企業自身が構想を持つ必要があります。

この状況で残すべき再現条件は、コードの変換精度だけではありません。

• 現行と新システムで同じ結果になる取引の範囲
• 意図的に結果を変える業務と、その承認者
• 例外データと過去障害を含む試験集合
• 月末、年度末、災害、外部サービス停止時の縮退手順
• 切替後に旧環境へ戻せる時間と判断条件
• AIが提案し、人が採用または却下した変更の履歴

以前の記事では、検索・判定・生成・実行を分ける業務設計を整理しました。刷新でも同じです。コードを検索して説明する能力、移行対象を判定する能力、新コードを生成する能力、本番データへ適用する権限を一つのAIへまとめません。工程ごとに評価と停止条件を変えます。

三つのニュースに共通する「縮尺の罠」

数学、工場、基幹システムは別分野ですが、三件には同じ構造があります。

数学では、モデルが出した証明候補から、先行研究、帰属、公開、共同体の検討へ縮尺が広がります。工場では、一つの小規模モデルから、設備の依存、複数品目、現場の判断、他工場への展開へ広がります。基幹刷新では、コード解析から、業務意図、例外、移行、復旧、長期運用へ広がります。

最初の段階で測った数字は、次の段階でも必要ですが十分ではありません。問題は、規模が大きくなったことだけではなく、成果の意味を決める人と影響を受ける人が増えることです。

段階	目立つ成果	次の段階で増える問い
数学の解答候補	解決件数、生成速度	正しさ、新規性、帰属、公開手順
小規模シミュレーション	工数削減、動作成功	現場差、安全、保全、横展開
コード解析・変換	解析時間、変換率	業務意図、例外、切替、復旧、利益

この段差を越えるには、同じ評価を大きくするのではなく、評価者と試験を追加します。数学なら独立した専門家による再検討、工場なら現場担当者による実行条件の確認、刷新なら業務部門を含む現新照合と復旧訓練です。

日本企業が30日で作れる「成果の再現票」

大規模な評価制度から始める必要はありません。現在進行中のAI実証を一つ選び、30日で数字の根拠と移送条件を整えます。

最初の10日——成果の分母を固定します

まず、成果の一件を決めます。文書を生成した時点なのか、担当者が承認した時点なのか、実システムへ反映して利用者の目的が完了した時点なのかを揃えます。

次に比較対象を固定します。AI導入前の代表的な案件を、簡単、標準、例外の三群に分けます。平均時間だけではなく、待ち時間、差戻し、専門家の確認、失敗からの復旧も記録します。AI導入後も同じ群、同じ完了点で測ります。

削減率を出すなら、式と対象期間も残します。最も成功した一件だけを使わず、失敗や保留を分母から外さないことが重要です。

次の10日——環境を一つずつ変えます

実証と本番の違いを列挙し、一度に全部を変えません。担当者、データ量、権限、実行場所、期限のうち一つを変え、結果を比べます。

例えば、専門家が整えた入力だけでなく、欠損や古い表現を含む通常入力を渡します。開発者本人ではなく、引き継ぎを受けた担当者に実行してもらいます。クラウド上の模擬道具ではなく、読み取り専用の本番相当環境へ接続します。

結果が下がったら、モデルの性能不足と決めつけません。辞書、権限、道具、手順、担当者教育のどこで再現条件が失われたかを見ます。

最後の10日——反証と撤退を試します

成果を作ったチームとは別の担当者に、失敗させる試験を依頼します。古い規程、矛盾する入力、実行できない権限、外部サービス停止、時間切れを入れます。AIが勝手に補うのか、保留するのか、人へ戻すのかを記録します。

さらに、AIを停止し、残された辞書、Playbook、判断履歴だけで人が一件を完了できるか試します。完了できなければ、成果は特定のモデルや担当者へ依存しています。自動化率が高くても、移送可能性は低い状態です。

この30日で見る指標は、次の七つで十分です。

• 条件内完了率
• 例外を含む完了率
• 独立再現率
• 人の確認と再作業を含む完了一件時間
• 初期整備と継続運用を含む完了一件費
• 別担当者・別環境への移送成功率
• AI停止後の人による完了時間

一つの総合点へまとめないことも大切です。時間が減っても独立再現率が下がったなら、速度と信頼性の交換が起きています。移送成功率が低いなら、全社展開ではなく対象を限定する判断ができます。

出典と読み方

• OpenAIの数学諮問グループと未解決問題に関するTechCrunch報道：解決件数はOpenAIの主張として扱い、諮問グループの権限限界を併記しました。
• OpenAI発表を伝えるITmedia NEWS：数学者の公開書簡、過去の発表を巡る論争、助言の公開可能性を確認しました。
• キユーピーの工場シミュレーション事例を伝える＠IT：78.8％は小規模な一モデルでの実績であり、初期の不具合修正と基盤整備を含む経過を分けて扱いました。
• メインフレーム刷新を巡るITmedia エンタープライズのまとめ：70％超はGartnerの予測として扱い、AI以外の人材不足、業務意図、基幹系の影響も併記しました。

結論——次の会議では数字の右側を聞いてみませんか

AIの大きな成果を疑うだけでは、前へ進めません。反対に、数字をそのまま信じても本番には届きません。必要なのは、「どの条件で成立したか」「誰が別の方法で確かめたか」「環境が変わったら何を試し直すか」を数字の右側へ書き足すことです。

OpenAIの数学研究では、解答候補の速度に、独立した評価と公表の規範が追いつく必要があります。キユーピーの事例では、78.8％という削減率の背後に、専門用語、ローカル実行、誤り検出、Playbookがあります。基幹刷新では、コード変換の速さより、失われかけた業務意図、例外、切替と復旧を誰が引き受けるかが成否を左右します。

次のAI導入会議で「何％減りましたか」と聞いたあとに、「その結果を別の担当者、別のデータ、別の現場でも再現する条件は何ですか」と続けてみてはいかがでしょうか。その問いに答えられる実証こそ、日本企業が安心して大きくできる成果です。