AIプロジェクトの完成日は「保守開始日」——722本公開とFDE放棄予測から作る成果引継ぎ票

AIが答え、コード、企画、分析を作り終えた瞬間を、プロジェクトの完成日と呼んでよいのでしょうか。出力が正しくても、根拠をたどれない、担当者が替わると直せない、外部ベンダーが離れると動かない状態なら、その成果はまだ組織の資産になっていません。

2026年10月、OpenAIは社内モデルが作った数学成果を722本の原稿として公開しました。NTTデータら三社は、消費者データから商品企画、処方、原材料、製造条件までをつなぐAI基盤の構築を発表しました。一方、Gartnerは、ベンダーのFDEが作るAIエージェントの70％が2028年までに企業で使われず、放棄されると予測しています。

三件は、研究、商品開発、企業システムという別の領域です。しかし共通する境界があります。AIが成果を生成した日と、別の人がその成果を読み、直し、止め、再利用できるようになった日は同じではありません。本稿では後者を「保守開始日」と呼び、日本企業が生成物を一過性のデモで終わらせないための成果引継ぎ票を提案します。

前回は、AIで減った時間が確認者や外部サービスへ移っていないかを見る負担移転票を整理しました。また、結果だけでなく許可された資料や道具を通ったかを確かめる経路合格も扱いました。今回は、その結果と経路を誰が翌月も保守できるのかへ焦点を移します。

結論——生成完了と保守開始を分けます

AIプロジェクトの完成条件は、優れた結果が一度出たことではありません。少なくとも、次の五つを別の担当者が再現できることです。

1. 何を入力し、どの版のモデル、道具、データで作ったかをたどれます。
2. 結果を採用した理由と、採用しなかった候補を説明できます。
3. 誤りや環境変更が見つかったとき、どこを直すか分かります。
4. ベンダーや開発者が離れても、社内担当者が一件を完了できます。
5. 続ける価値がなくなったとき、安全に停止し、必要な記録を残せます。

この五つがそろった日が保守開始日です。生成日より遅くても問題ありません。むしろ、その差を見えるようにすると、試作を本番と誤認せず、外部支援の終了条件も決めやすくなります。

OpenAIの722本は「生成量」より公開後の仕事を増やします

OpenAIは10月6日、未公開の社内モデルが作った数学成果を、722本の原稿としてGitHubへ公開したと発表しました。The Vergeによると、内容は関連する論文をまとめた372の結果群に分かれ、OpenAIは「数百」の未解決問題に対する解答を含むと説明しています。同社は平均的な結果に、ChatGPT Proの思考時間換算で約三時間分の計算を使ったとも主張しています。

この発表を「AIが722件の数学問題を解決した」と短縮すると、重要な段階を落とします。722は原稿数であり、372は関連成果をまとめた群の数です。問題の新規性、証明の正しさ、引用の適切さ、既存研究との重複は、数学者が原稿を読んで初めて確定します。OpenAIの公表は成果候補の大規模な公開であり、学術共同体による最終的な承認を意味しません。

数学とAIに関する独立助言グループAGMAIは、AI企業へ、結果を速やかに公開し、可能なら既存の学術経路を使い、モデル名、プロンプト、計算費用などを示すよう求めていました。また、数学成果をモデルの販促物として扱わないよう促しています。OpenAIは今回、GitHub上に原稿の改訂と引用の手順を設け、将来は引用、説明、提示方法を改善するとしています。

ここで始まるのは公開作業の終了ではなく、保守です。誤りの指摘をどの原稿へ結び付けるのか、改訂版と旧版をどう区別するのか、引用を追加した理由をどう残すのか、複数原稿が同じ前提に依存するとき影響範囲をどう示すのかが必要です。生成速度が上がるほど、読む側の人数と時間が自動的に増えるわけではありません。公開後の訂正能力が、生成能力に追いつく必要があります。

日本企業のAI成果も同じです。市場分析を百本作れても、担当者が翌月に前提データを更新できなければ、資料はすぐ古くなります。コードを百機能作れても、依存ライブラリーの更新や脆弱性対応を担当できなければ、公開した日から負債になります。成果数を数えるダッシュボードには、未確認数、訂正待ち数、所有者不明数も並べるべきです。

FDE型AIの70％放棄予測は、モデル性能の予測ではありません

Gartnerが公表した予測を伝えるITmedia NEWSの記事によると、ベンダーのフォワードデプロイドエンジニアリング、つまりFDEによって作られたAIエージェントの70％が、2028年までに企業で使われず放棄されると見込まれています。さらに、継続的な顧客ニーズをベンダーの中核製品へ反映できる例は20％未満になると予測しています。

この70％は、現在稼働する全システムを観測した確定値ではなく、Gartnerの将来予測です。FDEという名称で販売されるサービスのすべてが同じ品質でもありません。したがって、「FDEは失敗する」「外部人材を使うべきではない」と結論付ける材料にはなりません。

重要なのは、記事が紹介する三つの原則です。FDEは、深い製品知識と顧客環境の密接な統合が本当に必要な問題へ使います。社内の業務専門家、技術者、利用者へ重要な知識を共有し、作業へ反映します。そして、出口戦略を最初から明確にします。

失敗は、AIが技術的に動かないときだけ起こるわけではありません。デモは動くものの、次の変更をベンダーしか行えない。利用部門は画面の使い方を知っていても、評価データや停止条件を知らない。契約終了後に、プロンプト、接続設定、例外一覧、監査記録がどこへ残るか決まっていない。この状態では、利用率が上がる前に構造的な依存が完成します。

外部専門家を使う価値は、短期間で内部知識へ到達し、製品の制約を理解し、現場に合う形へ適応できることです。ただし、その速度を買う契約と、永続的な運用を買う契約は分けます。毎月の支援がなければ一件も直せないなら、成果物ではなく継続サービスを購入しています。それ自体が悪いのではありませんが、内製化したと誤認してはいけません。

以前の記事では、無料、有料、限定提供、オープンモデルを業務へ割り当てる能力アクセス表を提案しました。今回追加すべき欄は、能力の提供元が変わったとき、誰が設定、評価、復旧を引き継ぐかです。使える能力だけでなく、保守できる能力を配る必要があります。

NTTデータらの構想は「企画から製造条件まで」をつなぎます

インテージ、NTTデータ、NTTデータビジネスシステムズは、食品、飲料、日用品などの商品開発をAIで一気通貫に支援する戦略的連携を発表しました。インテージの小売店パネルと消費者パネルのデータを起点に、市場規模、シェア、購買行動を分析し、NTTデータの商品企画特化型AIエージェントでコンセプト、価格、売り上げ仮説を評価します。

企画は、NTTデータビジネスシステムズのFooDesignerへ接続されます。そこで処方、原材料、包材、原価、品質管理、製造条件など、商品化に必要な仕様へ落とし込む構想です。企画だけを大量に作るのではなく、製造可能性と組み合わせて手戻りを減らす狙いがあります。

これは、日本企業がAIの出力を業務の次工程へ接続する具体例です。同時に、発表時点では今後、消費財メーカーや小売業で実証と検証を進める段階です。商品開発の速度向上やヒット率がすでに広く実証されたと読むことはできません。三社は、企業ごとの開発工程と既存システムを踏まえ、再利用可能なAI資産としてサービス化を検討するとしています。

「一気通貫」という言葉は便利ですが、責任まで一つになるわけではありません。市場データから見つけた需要、AIが作った商品仮説、処方と原材料、原価、品質、製造条件には、それぞれ異なる担当者と合格基準があります。前段の誤りが後段へ流れたとき、どこへ戻すかも必要です。

例えば、購買データの分類が変われば、狙う市場と売り上げ仮説が変わります。原材料の供給条件が変われば、企画は魅力的でも製造できません。品質基準が更新されれば、同じ処方を再採用できない場合があります。AIの流れをつなぐほど、入力版と判断版を結ぶ変更履歴が重要になります。

再利用可能なAI資産にするには、プロンプトやエージェントだけを保存しても足りません。どの商品の、どの段階で、どのデータを使い、どの担当者が何を却下し、最終的にどの仕様が製造へ進んだかを残します。再利用する単位は「賢いエージェント」ではなく、入力、判断、例外、合格、差し戻しを含む一つの工程です。

三つのニュースに共通する「生成後の空白」

数学原稿、FDE型AI、商品開発基盤には、生成後の空白があります。

領域	AIが作るもの	生成後に必要な仕事	保守できないと起きること
数学研究	証明候補、原稿、要約	正しさ、新規性、引用、改訂、撤回	誤りや重複が大量の原稿へ埋もれます
FDE型導入	顧客向けエージェント、連携、画面	知識移管、評価更新、障害対応、契約終了	ベンダー離脱と同時に変更不能になります
商品開発	市場仮説、コンセプト、処方候補	品質、原価、供給、製造条件、差し戻し	前段の誤りが商品化工程へ広がります

共通する問題は、AIが作った内容を誰も理解していないことだけではありません。理解している人がいても、その人が唯一の修正者なら、組織の成果にはなっていません。専門家の知識をなくす必要はありませんが、専門家が休み、異動し、契約を終えても、問題を検知して適切な人へ渡せる状態が必要です。

もう一つの空白は、終了です。成果を改善し続ける計画は作っても、いつ停止するかを決めないプロジェクトは多くあります。利用が減ったエージェント、更新されないデータ、所有者のいないAPI、古いモデルへの接続が残ると、費用と攻撃面だけが続きます。保守開始日は、廃止条件を決める日でもあります。

日本企業向けの「成果引継ぎ票」

大規模な台帳から始める必要はありません。AIを使う一つの業務について、次の九欄を一枚へまとめます。

欄	記録する内容	合格の目安
完了対象	何を終えれば一件か	人の承認や実システム反映まで含めます
成果版	出力、モデル、プロンプト、データ、道具の版	後日同じ構成を特定できます
根拠	採用判断を支えた資料と観測	出力から参照元へたどれます
所有者	業務、技術、データ、セキュリティの担当	一人ではなく役割別に決まっています
変更窓口	誤り、要望、障害を受ける場所	利用者が迷わず報告できます
再試験	変更時に必ず試す代表例と例外	通常、難例、失敗例を含みます
引き継ぎ	別担当者が使う資料と演習	開発者なしで一件を完了できます
縮退	AI停止時の手作業と代替経路	重要業務を許容時間内に続けられます
廃止	停止、保存、削除、通知の条件	所有者不在や低利用を放置しません

この票で最も見落としやすいのは、成果版です。モデル名だけでは再現できません。システム指示、検索対象、接続API、権限、温度などの設定、日付、参照データの版が変われば、同じ質問でも結果が変わります。すべての内部状態を保存できなくても、採用判断を説明できる最小構成を残します。

所有者も一人にまとめません。業務の正しさを決める人、システムを動かす人、データ利用を許可する人、事故時に止める人は異なる場合があります。「AI担当」という一つの名前で包むと、異動時に全責任が空席になります。

引き継ぎは文書を渡すだけでは完了しません

引き継ぎ資料が十冊あっても、新しい担当者が一件を処理できなければ、移管は完了していません。最も小さな確認方法は、開発者を会議から外し、後任者だけで通常例を一件、例外を一件、停止を一回実行してもらうことです。

通常例では、入力から承認まで進めます。例外では、古いデータ、欠損、矛盾、権限不足を入れ、人へ戻せるかを見ます。停止では、モデルや外部APIを使えない状態にして、手作業や別サービスへ戻れるかを確認します。

質問できた回数を失敗と数える必要はありません。重要なのは、質問先が個人の記憶だけでなく、更新可能な窓口になっていることです。後任者がどこで迷ったかを記録し、手順、画面、用語、警告を直します。引き継ぎ試験は人を評価する試験ではなく、成果物の保守性を評価する試験です。

外部ベンダーから社内へ移す場合も同じです。契約終了直前に資料を一括で受け取るのではなく、設計中から社内担当者が評価データを更新し、変更を一回行い、障害を一回復旧します。出口戦略を文書の納品条件ではなく、社内による完了演習に変えます。

30日で保守開始日を作る方法

最初の一週間は、現在使っているAI成果を一つ選びます。利用件数が多いものより、開始と終了が分かり、担当者が替わる可能性のあるものが向きます。問い合わせ回答、商品企画、社内検索、コード修正などから一つに絞ります。

二週目は、成果版と所有者を記録します。現在のモデル、指示、データ、接続、権限、代表入力、合格条件を書きます。完全な再現を目指して止まるより、採用理由と差し戻し先を説明できる最小セットを作ります。

三週目は、別担当者による引き継ぎ試験を行います。通常例、例外、停止を一回ずつ試し、開発者への質問、見つからなかった資料、足りなかった権限を記録します。成功率だけでなく、どこで人を呼んだかを見ます。

四週目は、修正と廃止を試します。データの項目名を変える、外部APIを止める、評価基準を一つ更新するなど、小さな変更を入れます。次に、利用者へ停止を通知し、記録を保存し、権限を外す仮想廃止を行います。続け方だけでなく終わり方まで再現できた日を保守開始日とします。

見るべき七つの指標

導入後は、生成件数や利用率に加えて次の七つを分けて見ます。

1. 独立完了率です。開発者やベンダーなしで一件を終えた割合です。
2. 変更完了時間です。データ、規程、モデルの変更を反映する時間です。
3. 訂正滞留数です。誤りの報告から修正版公開まで残る件数です。
4. 所有者明確率です。業務、技術、データ、停止の担当が決まった割合です。
5. 縮退成功率です。AI停止時に許容時間内で業務を続けた割合です。
6. 再利用成功率です。別案件へ移したとき、追加作業を含めて合格した割合です。
7. 廃止完了時間です。通知、保存、権限削除、接続停止までの時間です。

一つの総合点にはしません。独立完了率が高くても、訂正が長く滞留するなら、使うことはできても直す能力が不足しています。再利用率が高くても、例外を外しているなら横展開を急げません。廃止に数カ月かかるなら、接続とデータの所有が複雑すぎます。

出典

• ITmedia NEWS「FDEが開発したAIエージェントの7割は使われず、単なるコンサルティングが販売される」
• MONOist「AIが『ヒットの種』から商品化まで一気通貫、NTTデータらが基盤構築で連携」
• ITmedia NEWS「OpenAI、社内AIがリーマン予想の関連難問を証明と主張」
• The Verge「OpenAI drops another batch of mathematical breakthroughs」

結論——AI成果を「誰かが作ったもの」から「誰でも直せるもの」へ

OpenAIの722本の公開は、AIが一度に多くの研究候補を作る時代を示しました。同時に、改訂、引用、検討、訂正という公開後の仕事を増やします。NTTデータらの構想は、企画を商品化工程へつなぐ可能性を示しますが、工程をまたぐほど版と責任の引き継ぎが必要です。FDE型AIの放棄予測は、優秀な外部人材がいても、知識移管と出口がなければ成果が残らない危険を示します。

AIプロジェクトの完成日を、最初の成功デモや本番公開日に固定する必要はありません。別の担当者が通常例を完了し、例外を戻し、変更を反映し、停止後も業務を続けられた日を、保守開始日として記録します。

次のAI導入会議では、「いつ動きますか」に加えて、「誰が来月直せますか」「担当者が替わった日に何が残りますか」と聞いてみてはいかがでしょうか。生成速度が上がる時代ほど、成果を受け取り、直し、終わらせられる組織が、AIの価値を長く使えるはずです。