NTTデータがCodexを約9,000人へ展開、インシデント分析は30分に｜発注先がAIで速くなった時、保守費の見積もりはどうなるのか

結論：ベンダーの生産性は上がっている。それが見積もりに反映されているかは、別の話である

OpenAIが公開した顧客事例で、NTTデータグループがChatGPT EnterpriseとCodexを技術職・非技術職を含む約9,000人規模に展開し、インシデント分析を30分に短縮したと紹介されています。同社は2025年5月にOpenAIとのグローバルな戦略提携を開始しており、その延長線上の取り組みとされています。

ここで一つ、誠実さのために書いておきます。この「30分」という数字について、比較の基準となる従来の所要時間や、その測定方法は公表資料上で明示されていないという指摘があります。したがって本記事では、この数値を「同社が公表した成果」として扱い、削減率を他社に当てはめて論じることはしません。

それでも、この事例には発注側が読み取るべき重要な事実があります。日本を代表するシステムインテグレーターが、9,000人という規模で開発・運用の現場にAIを入れているという事実です。これは実験ではなく、業務のやり方そのものの変更です。

そして、ここに発注側から最も見えにくい変化が潜んでいます。あなたの会社のシステムを開発・保守しているベンダーの内部生産性は、この数年で確実に変わっています。にもかかわらず、あなたが受け取る見積もりの構造は、おそらく去年と同じ形をしている、という変化です。

3行サマリー（先に結論）

• NTTデータグループがChatGPT EnterpriseとCodexを約9,000人規模で展開、インシデント分析を30分に短縮したとOpenAIの事例で公表（比較基準・測定方法は非開示との指摘あり）。
• 発注側の論点は「AIで安くなったはずだ」という値下げ要求ではなく、人月単価×工数という見積もりの前提が静かに変わっているという認識。
• 交渉軸は「同じ金額で何が増えるか」へ移す。開発費より先に、毎月固定で払っている保守費・運用費を点検するのが費用対効果が高い。

要点表：この事例から読み取ること

発注側から見えないところで起きていること

システム開発・保守の見積もりは、日本では長く「人月」を基本単位としてきました。単価（1人が1ヶ月働くといくらか）に、必要な工数（何人月かかるか）を掛ける方式です。

この方式には合理性があります。作業量が読みにくい仕事について、投入する人的資源で価格を決めるのは、双方にとって分かりやすい。問題は、その工数の見積もり根拠が、発注側からはほぼ検証できないという点にあります。

「この改修には3人月かかります」と言われたとき、発注側にできるのは、他社の見積もりと比べるか、過去の類似案件と比べるかくらいです。3人月が妥当かどうかを内側から検証する手段はありません。

ここにAIが入ると何が起きるか。コードを書く、テストを書く、ログを読み解く、ドキュメントを作る——こうした作業の一部が、以前より短時間でできるようになります。つまり同じ「3人月」の中身が、以前より多くの成果を含むようになる、あるいは以前なら3人月かかった作業が2人月で終わる、という変化が起きます。

しかし、見積書の書式は変わりません。「3人月」と書かれた紙が届き、去年と同じ単価が掛けられ、去年と同じ金額が請求されます。中で何が起きているかは、見積書からは読めません。

「値下げしろ」は交渉として弱い

ここで多くの経営者が考えるのが、「AIで効率化したなら安くしてほしい」という要求です。感情としては自然ですが、交渉としては弱手です。理由は3つあります。

理由1：ベンダー側にも投資がある AIツールの利用料、教育、品質保証の仕組み作り。生産性向上は無料で降ってきたものではなく、投資の結果です。「効率化した分を全部よこせ」という要求は、投資回収の否定になります。

理由2：単価は下げにくい構造にある 人材の獲得競争は激化しており、エンジニアの人件費は上昇傾向です。ベンダーとしては、生産性向上分を人件費の上昇で相殺している、という説明が成り立ちます。この説明を数字で反証するのは、発注側にはほぼ不可能です。

理由3：値下げは品質低下の口実になる 価格だけを削ると、削られるのはたいていレビューやテストの工程です。表面上は同じ成果物が納品され、数ヶ月後に不具合として顕在化します。

では、どうするか。交渉軸を「金額」から「同じ金額に含まれる範囲」へ移すことです。

交渉軸の置き換え：同じ金額で何が増えるか

具体的には、次のような要求に組み替えます。

この組み替えには利点があります。ベンダー側にとって、値下げは利益の直接的な減少ですが、範囲の拡大は生産性向上分の再配分で吸収できる余地があります。つまり、双方が受け入れやすい着地点になります。

そして発注側にとっては、実は値下げより価値が大きい場合が多い。自動テストが整備されれば、次の改修の品質と速度が上がります。ドキュメントが更新されていれば、将来ベンダーを変える際の引き継ぎコストが下がります。これらは、10%の値引きよりも長期的な効果が大きい投資です。

開発費より先に、保守費を見直す

もう一つ、順序の話をします。多くの企業は「新しいシステムを作るとき」に見積もりを厳しく見て、「毎月払っている保守費」は見直しません。しかし、費用対効果の観点では逆です。

保守費は、契約が続く限り毎月・毎年発生する固定費です。しかも、その内訳を最後に確認したのが何年前か思い出せない、という会社が少なくありません。

保守契約を見直すときに確認すべきは、次の5点です。

確認1：何が含まれているか 障害対応、問い合わせ対応、軽微な改修、セキュリティパッチの適用、バージョンアップへの追随。このうち何が含まれ、何が別料金かを一覧にします。

確認2：実際にどれだけ使ったか 過去1年の問い合わせ件数、障害件数、改修依頼件数を出してもらいます。契約が実態に対して過大か過小かを判断する材料になります。

確認3：対応時間の実績 一次回答までの時間、解決までの時間の実績値を求めます。契約書に書かれた目標値ではなく、実績です。AIによる分析の高速化が本当に効いているなら、この数字に表れているはずです。

確認4：担当者の体制 自社を担当しているのは何人で、そのうち自社システムを理解している人は何人か。属人化していないかを確認します。

確認5：AI活用の有無と品質保証 保守作業にAIをどの程度使っているか、生成されたコードや調査結果を誰がどう検証しているかを確認します。これは値下げ交渉のためではなく、品質の担保状況を知るためです。

生成されたコードの責任は誰にあるか

AI活用が進むにつれ、必ず論点になるのが品質と責任の所在です。ここは契約で明確にしておくべき領域です。

発注側として押さえるべきは、シンプルな一点です。AIを使ったかどうかにかかわらず、納品物の品質責任はベンダーにある、という原則を契約に維持することです。

具体的には、次のような確認をします。

• 生成AIを用いて作成したコード・設計・ドキュメントについて、人によるレビューの体制はどうなっているか。
• 第三者のライセンスに抵触するコードが混入した場合の責任はどちらにあるか。
• 生成物に起因する不具合が発生した場合の瑕疵担保（契約不適合責任）の扱いは通常と同じか。
• 自社のソースコードや業務情報を、AIサービスへ送信しているか。送信している場合、その学習利用の有無はどうなっているか。

最後の項目は、品質ではなく情報管理の観点です。自社のソースコードや仕様書が、ベンダーの使うAIサービスに送られている可能性は現実にあります。それ自体が直ちに問題とは限りませんが、知らないまま送られている状態は避けるべきです。

保守契約の型ごとに、見直しの切り口が違う

保守契約には型があり、それぞれ見直しの入り口が異なります。自社の契約がどれに当たるかを確認してください。

型1：月額固定・作業量無制限型

毎月定額で、問い合わせや軽微な改修に対応する形です。使う側からは分かりやすい一方、実際の作業量との乖離が生じやすい型でもあります。

見直しの切り口は、実績の可視化です。過去1年の対応件数と工数を出してもらい、月額との対応関係を確認します。実績が契約に対して大幅に少ないなら、金額の見直しか、範囲の拡大かを交渉できます。逆に実績が多いなら、その契約は割安だということです。

型2：月額固定＋従量型

基本料金に加え、一定量を超えた分を都度請求する形です。追加請求の内訳が妥当かが論点になります。

見直しの切り口は、追加請求が発生した案件の内訳確認です。「本来は基本料金の範囲では」と思われる作業が従量側に計上されていないか、区分の基準が明確かを確認します。

型3：都度見積もり型

保守契約を結ばず、必要が生じるたびに見積もりを取る形です。一見安く見えますが、緊急時の対応が保証されない点がリスクです。

見直しの切り口は、緊急時の対応可否です。「障害が起きたとき、何時間以内に対応してもらえるのか」を確認し、答えが曖昧なら、保守契約を結ぶ方向の検討が必要です。

型4：SaaS利用料に含まれる型

クラウドサービスの利用料に保守が含まれる形です。個別の交渉余地は小さいですが、プランの見直しやライセンス数の適正化で費用は動きます。

見直しの切り口は、利用実態との照合です。使われていないアカウント、不要になった上位プランがないかを確認します。

相見積もりの取り方——比較できる形で取る

保守や開発の見積もりを複数社から取っても、比較できないことがよくあります。各社が異なる前提で、異なる粒度で書いてくるためです。

比較可能にするには、こちらから枠を指定する必要があります。次の資料を用意して各社に渡してください。

渡すもの1：現状の説明資料 現在のシステム構成、利用者数、月間の処理件数、過去1年の障害・改修の件数。数字がないと、各社は保守的に（＝高めに）見積もります。

渡すもの2：求める作業範囲の一覧 何を含めてほしいかを、こちらから列挙します。障害対応、問い合わせ対応、軽微な改修、セキュリティパッチ適用、バージョンアップ追随、定期報告。各項目について「必須」「あれば望ましい」「不要」を指定します。

渡すもの3：回答書式 工程別・項目別に金額を記入する表を用意し、その形式で回答するよう依頼します。書式を揃えるだけで、比較の労力が劇的に下がります。

渡すもの4：前提条件の質問欄 「見積もりにあたって前提とした条件」を記入する欄を設けます。ここに書かれた内容が、後の追加費用の争点になります。事前に書かせておくことに意味があります。

この4点を用意する手間は半日程度です。それだけで、見積もりの比較可能性と、その後の交渉の質が変わります。

AI活用時代に、ベンダーをどう選ぶか

最後に、選定基準そのものの見直しについて触れます。従来の選定基準は、実績・体制・価格が中心でした。ここに加えるべき観点があります。

観点1：ドキュメントを残す文化があるか

AI活用で開発が速くなるほど、記録が残りにくくなる傾向があります。「何をどう作ったか」の記録を成果物として提供する姿勢があるかは、数年後の保守性を左右します。

確認方法は簡単です。「納品物に含まれる文書の一覧を見せてください」と依頼し、実際のサンプルを求めてください。

観点2：属人化していないか

自社の案件を理解している技術者が1名しかいない状態は、ベンダーの規模に関わらず起こります。その1名が離職した瞬間に、対応品質が落ちます。

「当社の案件を把握している方は何名いますか」という質問は、失礼にはあたりません。

観点3：品質の検証をどう行っているか

AIが生成したものであれ人が書いたものであれ、検証の仕組みがあるかが品質を決めます。レビューの体制、テストの範囲、リリース前の確認手順を聞いてください。

観点4：値上げの説明ができるか

人件費の上昇を理由に単価改定が提示されることがあります。それ自体は正当ですが、改定の根拠を説明できるかどうかは確認すべきです。説明を求めることは、値切りとは違います。

観点5：断ることがあるか

これは逆説的な基準ですが、「その要望はやめたほうがよい」と言えるベンダーは信頼できます。すべての要望に「できます」と答える相手は、後で問題が出ます。

見積書に書かせるべきこと

次回の見積もり取得時に、次の形式で内訳を求めてください。これは値下げのためではなく、比較可能性を作るためです。

この6項目が揃った見積書は、複数社の比較が可能になります。総額だけの見積書は、比較しているようで比較になっていません。

FAQ

Q1. うちの開発会社は中小です。この話は大手SIerだけの話ではないですか。 A. 規模を問わず、開発現場でのAI活用は広がっています。むしろ人手が限られる中小ベンダーほど、AIによる効率化の恩恵は大きい可能性があります。確認の仕方は同じです。

Q2. ベンダーにAI活用状況を聞くのは失礼になりませんか。 A. 発注側が納品物の作られ方を確認するのは正当な行為です。実際、大手企業の調達では標準的な確認項目になりつつあります。聞き方を「監査」ではなく「体制の確認」とすれば、関係を損ねずに進められます。

Q3. 「AIは使っていません」と回答された場合はどう考えればよいですか。 A. それ自体は問題ではありません。ただし、同業他社が効率化を進めている中で使っていないなら、その分の競争力について確認する余地はあります。品質重視の判断である場合もあるため、理由を聞くのが妥当です。

Q4. 保守費の内訳開示を拒否されました。 A. 拒否される合理的な理由は考えにくい領域です。「契約範囲の確認」という形で、含まれる作業と含まれない作業の一覧だけでも求めてください。それも出ないなら、契約の見直しを検討する材料になります。

Q5. 交渉した結果、ベンダーとの関係が悪くなりませんか。 A. 適切な確認を行うことで関係が壊れるなら、そのほうが問題です。ただし、進め方は重要です。突然の値下げ要求ではなく、「契約更新にあたって内容を整理したい」という文脈で始めるほうが建設的です。

Q6. 事例の「30分」という数字は信用できますか。 A. 公表元は当該企業とOpenAIです。比較の基準と測定方法が示されていない以上、他社が自社の期待値として使うべき数字ではありません。事実として押さえるべきは「大規模に展開されている」という点です。

Q7. どこから手を付けるのが効率的ですか。 A. 現在支払っている保守契約の内訳確認からです。新規開発の見積もり精査より、既に払っている固定費の点検のほうが、着手が早く効果も出やすい領域です。

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、次回の契約更新前に第三者の点検を挟む価値があります。

• 保守費を毎年同じ金額で払い続けているが、内訳を確認したことがない。
• 見積書が総額だけで、工程別の内訳や前提条件が書かれていない。
• 複数社から見積もりを取ったが、書式が違いすぎて比較できない。
• ベンダーのAI活用について、品質・情報管理の観点で確認したいが聞き方が分からない。

GXOは開発ベンダーの立場でも、特定製品を売る立場でもないため、発注側の代理人として見積もりと契約を読む役割を担えます。開発・保守の見積もりと契約の点検はシステム開発・DXの相談、AI活用の妥当性判断はAI導入診断、AI機能そのものの実装検討はAI開発・活用の相談、社内の現状整理から始めたい場合はDX成熟度診断が入口です。手元の見積書を持ち込んでいただく形でも構いません。お問い合わせからお気軽にどうぞ。

ベンダーが速くなったこと自体は、発注側にとっても悪い話ではありません。問題は、その変化が見積書に一行も反映されないまま、契約が自動更新されていくことです。

参考文献

• OpenAI「NTT DATA Group cuts incident analysis to 30 minutes with Codex」（一次・事例公開）: https://openai.com/index/ntt-data/

※本稿で紹介した事例の数値は、公表元の発表によるものです。比較の基準値および測定方法が明示されていない点にご留意ください。他社において同等の効果が得られることを示すものではありません。記述は2026年7月24日までに確認できた内容に基づきます。