AIがコードを書く時代、SIerは何を売るのか① | AI駆動開発時代、SI契約の結び直しを考える

*自社の知見·技術*

開発の各工程にAIを組み込む――いわゆるAI駆動開発が、現場に急速に広がっている。だがこの変化は、単に「コードを書くのが速くなった」というだけの話ではない。

生成AIとAI Agent（以下、Agent）が日々の開発に定着し始めた瞬間から、SI契約を成り立たせてきた前提ーー何を作り、どう作り、誰がどこまで担い、どんな品質を保証し、いくらで売るのか――それらが、いま問い直されている。本稿では、この変化の正体を明らかにしたうえで、SI契約をどこから組み直していくべきかを考える。

序章　人月モデルが直面する構造的限界

市場は伸びている。それでも不安は消えない

日本の国内IT市場は、2025年に前年比9.7%増の27兆8,953億円に達した（IDC Japan）。このうちプロジェクトベースのSI市場だけでも3兆5,728億円規模にのぼり、2029年に向けて年率9.1%で拡大していくと予測されている。生成AIの業務利用率も伸びており、日本企業全体で55.2%（総務省『令和7年版 情報通信白書』）、言語系生成AIに限れば41.2%（JUAS『企業IT動向調査2025』）に達している。
市場は拡大している。技術も普及している。それでも、SI業界の経営層が抱える不安は深まる一方である。理由は単純だ。仕事の価値を「人月」で測り、それで見積もってきたやり方が、実態に合わなくなってきたからである。

人月モデルでは価値を表現できなくなった

ある実在の案件を、新旧二つの式に並べてみる。
旧来モデル：10人月 × 150万円 ＝ 1,500万円
AI駆動開発モデル：3人月 × 150万円 ＋ Agent実費200万円 ＝ 650万円
同じものを納めるのに、受託側の売上は約57%減る。富士通の社内検証では、GitHub Copilot 利用者の9割以上が生産性向上を実感したと報告されている。日本企業のAgent導入による生産性向上は概ね16〜30%の水準にあるとされる。案件単位で人月を圧縮するには、十分な効果である。

問題は価格ではなく、契約の前提である

発注側にとっては歓迎すべき変化のはずだが、受託側からみれば「AIを入れるほど、自社の売り上げが減っていく」という逆風になる。これを単なる値引きの問題と捉えてしまうと、その先で起きていることを見落とす。揺らいでいるのは値段ではない。何に対して、いくら払ってもらうのか――その対価の決め方そのものが、揺らいでいるのである。
人月という単位は、ソフトウェア開発を「人間が労働時間を投じることで価値を生む仕事」と捉えてきた時代の遺産である。Agentが工程の主要部分を担う今、より少ない人月で同じ成果を出せる熟練者ほど、人月モデルのもとでは安く請けることになる。能力が高いほど売上が落ちる――この逆転を正さないかぎり、業界に次の数年はない。

SI契約を支える五つの前提

打つべき手は、人月単価を引き上げることでも、Agentによる開発費用を上乗せすることでもない。何を作り、どう作り、誰がどこまで担い、どんな品質を約束し、いくらで売るのか。これらを一つずつ、しかし互いの関係を踏まえながら組み直していくしかない。
では、何を組み直せばよいのか。AI駆動開発によって書き換わるのは、次の五つの前提である。

五つはそれぞれ独立した話ではない。一つだけを書き換えても、必ずどこかで矛盾が生まれる。だから本稿では、この五つを一つずつ見ながら、最後に全体をもう一度つなぎ直していく。

第1章　納品物が変わる

これまでの納品物は何だったのか

これまでSI契約において受託側が納品してきた成果物は、大きく三つに整理できる。ソースコード、仕様書・設計書、そして運用マニュアルである。
AI駆動開発の時代になったからといって、それらが突然まったく別のものへ置き換わるわけではない。むしろ従来の成果物が、Agentに読み取られ、再利用できる形へと進化すると考えたほうが実態に近い。

AI時代の納品物はどう変わるか

「知識資産」や「設定資産」という言葉は新しい概念のように聞こえる。しかし実際には、これまで人が読むために作られてきた仕様書やマニュアルが、AIが理解し再利用可能な資産へ発展したものと捉えることができる。語彙の構造化（Ontology）は設計書に記載されていた用語定義の発展形であり、業務ルールの形式化は従来の意思決定ロジックをAIが利用できる形に整理したものと言える。さらにAgentプロンプトは、人向けの作業手順書をAIが直接理解・実行できる形へ変換したものと考えればイメージしやすい。
さらにAI駆動開発では、これまで属人化し、成果物として扱われることの少なかった応用設計や運用ノウハウも、明確な納品対象となる。受託側が培ってきた知見そのものが、「第四の納品物」として初めて可視化されるのである。

検収基準も変わる

納品物が変われば、完成の定義も変わる。
従来は、コードがコンパイルでき、仕様書どおりに動作し、本番環境で稼働すれば検収は完了だった。しかしAI駆動開発では、それだけでは十分ではない。
ナレッジベースに必要な知識が十分に蓄積されているか。Agentが期待どおりの判断を安定して続けられるか。人による介入頻度は許容範囲に収まっているか。そして、想定された範囲の中で継続的かつ自律的に判断できる状態になっているか。
こうした点が、新しい検収基準となっていく。

新しく生まれる「資産の帰属」という論点

そして、ここでSI契約に新しい論点が生まれる。
それは、「この資産は誰のものなのか」という問いである。
知識資産や設定資産には、特定プロジェクトだけでなく、他業界や他顧客へも展開可能な汎用的価値が含まれる。そのため、所有権だけでなく、利用権や再利用権まで含めて契約上どのように整理するかが重要になる。
すべてを発注側へ帰属させれば、受託側は蓄積した知見を横展開できず、生産性向上の余地を失う。一方、すべてを受託側が保有すれば、発注側はAgentを運用するために受託側へ依存し続けることになりかねない。
AI駆動開発では、コードだけではなく、知識資産・設定資産・ノウハウといった資産ごとに権利関係を設計することが不可欠になる。SI契約は、成果物の定義だけでなく、「何を誰の資産として扱うのか」を契約で明確に定める時代へと入りつつある。

第2章　開発の進め方が変わる
―― 三層循環構造への移行

これまでの開発プロセスでは対応できない

納品物が変われば、その作り方も変わる。
これまでのSI開発は、要件定義から基本設計、実装、テストへと工程が一方向に流れ、本番稼働をもってプロジェクトが完了する「直線型」の開発モデルを前提としてきた。
しかしAI駆動開発では、この前提が成り立たない。
Agentは知識資産をもとに動作し、その知識資産は運用を通じて継続的に更新される。実装だけを進めても十分ではなく、知識を整備し、Agentを運用し、その結果を再び知識へ反映する。この循環そのものが開発プロセスになる。

三層循環構造への転換

その結果、開発は「知識を整える場」「人とAgentが共同で実行する場」「運用を通じて育て続ける場」という三つの場が循環する構造へ移行していく。
知識を整える場では、業務用語やルール、判断基準、過去事例を整理し、Agentが判断できる土台を作る。プロジェクト初期に集中的に整備されるが、本番稼働後も運用を通じて継続的に更新される。
共同で実行する場では、要件定義から設計、実装、テストまでを、人とAgentが協働して進める。Agentがドラフトや実装案を生成し、人は判断やレビュー、最終的な意思決定を担う。
育て続ける場では、本番稼働後の利用状況を見ながら、Agentの判断品質を確認し、知識や設定を更新していく。従来の保守が障害対応や仕様変更への対応を中心としていたのに対し、この段階では資産そのものを成長させ続けることが目的になる。
三つの場は順番に進むわけではない。運用で得られた知見は知識資産へ反映され、その知識の更新が次の開発品質を高める。こうした循環を繰り返すことで、Agentの判断精度とシステム全体の価値が継続的に向上していく。

プロジェクトリーダーの役割も変わる

この変化は、プロジェクトリーダーの役割にも及ぶ。
Gartnerは2025年5月、「2027年までにソフトウェアエンジニアリングリーダーの職務の約70%で、生成AIを監督する責任が明示されるようになる」と予測している。また、プラットフォームチームを持つ組織の約70%が、社内開発基盤へ生成AI機能を組み込むとも見込んでいる。
つまり、リーダーの役割は「人月を管理すること」から、「Agentを管理し、知識資産を育てること」へと構造的に変化していくのである。

「完成」の意味も変わる

そして、「完了」の意味も書き換わる。
従来は、本番稼働がプロジェクトの終着点だった。しかしAI駆動開発では、本番稼働は資産を育て始めるスタートラインにすぎない。
Agentが期待どおりの判断を継続して行い、人の介入を最小限に抑えながら安定して運用できる状態になって、初めて「完成」と呼べる。

保守・運用は「資産を育てる仕事」になる

その意味で、これまで付随業務として扱われることも多かった保守・運用フェーズは、AI駆動開発では資産価値を高め続ける中核的な活動へと位置付けが変わっていく。

第3章　要件と責任分担が変わる
ーー 丸投げ・一括請負が成り立たない

これまでのSI契約では、受託側は「作る側」、発注側は「使う側」という役割分担が前提だった。
しかしAI駆動開発では、この前提が大きく変わる。
Agentは要件定義の段階から活用される一方で、適切に動作するためには業務知識が欠かせない。その業務知識を最も多く持っているのは発注側であり、受託側だけでは十分な知識資産を構築できない。AI駆動開発は、発注側と受託側が協力してAgentを育てることを前提とした開発へ変わっていく。

AIは「共同作業」を前提とする

この変化は、海外の調査にも表れている。
Writer社の2025年エンタープライズAI調査では、経営層の68%が、IT部門と業務部門の摩擦が高まっていると回答している。また、McKinseyの『State of AI 2025』では、Agentの実証実験に取り組む企業は62%に達する一方、全社的な業務で本格活用できている企業は約10%にとどまるとしている。
技術の進化に対し、組織や役割分担の見直しが追いついていないことが、多くの企業に共通する課題となっている。

受託側の役割が変わる

その中で、受託側の役割も変わる。
従来のようにコードを書くことだけが中心ではない。Agentの設計、知識資産の整備、業務ルールの形式化、人とAgentの役割分担の設計、本番稼働後のチューニング、KPIに基づく改善サイクルの運営など、Agentが継続的に価値を発揮できる環境を設計し、育てることが中核業務になる。コーディングは、その一工程として位置付けられるようになる。

発注側も「育てる側」になる

一方、発注側にも新しい役割が求められる。
業務の暗黙知を言語化し、知識資産として提供すること。Agentの判断結果をレビューし、改善のためのフィードバックを行うこと。業務KPIを定義し、その達成状況を評価すること。そして最終的な業務判断の責任を担うこと。
つまり、発注側は「成果物を受け取るだけの立場」ではなく、Agentを共に育てる当事者へと変わる。

契約書に書くべきことが変わる

このように双方の役割が変わる以上、契約書で定めるべき内容も変わる。
発注側は、どの範囲の業務知識を、どの程度の粒度で提供するのか。Agentのチューニングを誰が実施するのか。Agentの判断結果を誰が承認するのか。誤った判断が行われた場合、最終的な責任は誰が負うのか。これらを事前に整理しなければ、AI駆動開発では契約どおりにプロジェクトを進めることは難しい。
AI駆動開発において、丸投げや一括請負が成り立たない理由はここにある。Agentは受託側だけでは育てられず、発注側だけでも活用できない。両者が役割と責任を分担しながら継続的に改善を続けることが、プロジェクト成功の前提になるのである。

第4章　品質の基準が変わる
ーー 「逃げられる状態」を売る

ここまで読み進めると、多くの発注側は一つの疑問を抱くだろう。
受託側が知識資産や設定資産を構築し、Agentの運用まで担うのであれば、ベンダーロックインはむしろ強くなるのではないか。これは購買部門や監査部門、コンプライアンス部門が必ず確認する論点である。
人月モデルでは、ベンダーを変更しても、人月という共通の考え方があったため、一定の連続性を保つことができた。しかしAI駆動開発では、Agentの設計思想、知識資産の整理方法、判断ルール、運用方法まで含めて各社のやり方が大きく異なる。
発注側から見れば、ベンダーを変更できなくなるリスクは、これまで以上に高まる。
この不安に答えられなければ、AI駆動開発は企業の標準的な調達手法にはなり得ない。

ベンダーロックインへの不安にどう答えるか

そこで重要になるのが、新しい品質基準である。
AI駆動開発では、「システムが動くこと」だけでは品質を評価できない。将来にわたって安心して運用できること、その状態を契約として保証できることが品質になる。
その品質を構成するのが、次の五つの「可〜性」である。
可再現性：同じ条件であれば、Agentが安定して同じ品質の結果を返せること。
可監査性：Agentの判断過程や知識資産を第三者が確認でき、監査に耐えられること。
可説明性：Agentがなぜその判断に至ったのかを、人へ説明できること。
可換性：ベンダーや担当者が変わっても、運用を継続できること。
可継承性：知識資産や設定内容を、別の担当者や組織へ円滑に引き継げること。

品質への投資は「安心」を買うこと

知識資産が整備されていなければ、判断は再現できない。設定内容が整理されていなければ、監査やベンダー変更は難しい。判断根拠が記録されていなければ説明責任は果たせず、十分なドキュメントがなければ引き継ぎもできない。
つまり、知識資産と設定資産への投資こそが、新しい品質を支える基盤になる。
だからこそ、整備にかかるコストの意味も変わる。
それは受託側の工数ではなく、「いつでも他社へ引き継げる状態」を実現するための投資である。発注側は、安心して選択肢を持ち続けるために費用を支払うのである。

「逃げられる状態」が信頼を生む

ここで、一つの疑問が生まれる。
「可換性」を高めることは、自ら顧客が離れやすい状態を作ることではないか。しかし実際には、逆である。顧客は、いつでも離れられると確信できる相手だからこそ、安心して長期的な関係を築く。
Red Hatはオープンソースを基盤としたビジネスモデルによって高い信頼を獲得した。AWSも、他クラウドへのデータ移行を支援する仕組みを提供することで、利用者の安心感を高めている。トップティアの経営コンサルティングファームも、「私たちがいなくても組織は回る状態を作る」と約束することで、高い価値を提供してきた。
共通しているのは、「逃げられない状態」を売っているのではなく、「いつでも逃げられる状態」を品質として提供していることである。
AI駆動開発のSI契約でも、同じ発想への転換が求められる。
これからの品質とは、システムが動くことではない。知識資産と設定資産が適切に整備され、必要であれば他社へ引き継ぐこともできる。その安心まで含めて提供することが、新しい品質基準なのである。

第5章　見積もり・費用が変わる
ーー 3年TCOで考える新しい価格構造

ここまで見てきたように、AI駆動開発では、納品物、開発の進め方、要件と責任分担、品質基準のすべてが変わる。そうであれば、見積もりや費用の考え方だけが従来のままであるはずがない。序章で示した「3人月×150万円＋Agent利用料200万円＝650万円」という見積もりを、もう一度振り返ってみよう。
この式には、一つ大きな欠落がある。
受託側が長年蓄積してきた知見やノウハウが、価格の中にほとんど表現されていないことである。3人月で成果を実現できた背景には、応用設計のパターン、Agent活用のノウハウ、人Agentの役割設計、知識資産の整備手法など、多くの蓄積が存在する。しかし、それらは人月という単位だけでは評価できない。
だからといって、新しい費用を積み上げ、単発の見積額だけを大きく引き上げればよいわけでもない。発注側から見れば、「AIだから倍額です」という説明では、稟議は通らない。そこで必要になるのが、単発の見積額ではなく、3年間の総保有コスト（TCO）で考える視点である。

単発の見積もりから、3年TCOへ

AI駆動開発では、初期構築費には、人件費やAgent利用料だけでなく、知識資産の整備、メソドロジーの適用、品質保証のための設計などが含まれる。そのため、初期費用は従来よりやや高くなることがある。
しかし、その価値は、その後の運用フェーズで現れる。
知識資産を継続的に活用し、Agentを改善し続けることで、保守・運用コストや業務効率は長期的に改善される。その結果、3年間で見れば、発注側は総保有コストを抑えながら、より高い業務成果を得られる。
一方で受託側も、初期構築だけに依存するビジネスから脱却できる。運用支援や知識資産の改善、成果に応じた報酬などを組み合わせることで、継続的な価値提供に応じた収益を得られるようになる。
つまり、AI駆動開発では、「初期費用を抑えるか、高くするか」という議論ではなく、「長期的な価値をどのように分け合うか」という発想へ転換するのである。

四層の価格構造で価値を表現する

そのための価格構造として、本稿では次の四層モデルを提案している。
コスト回収層：人件費やAgent利用料など、プロジェクトを遂行するための直接コスト
価値創出層：知識資産、メソドロジー、再利用可能なノウハウなど、受託側が提供する付加価値
品質保証層：可再現性・可監査性・可説明性・可換性・可継承性を実現するための品質への投資
成果共有層：業務成果やKPI達成に応じて、発注側と受託側が価値を共有する仕組み

3年TCOで比較すると何が変わるか

では実際に3年TCOで比較するとどうなるのか。

図2は、その考え方を3年間のTCOで比較した例である。AI駆動開発では、初期構築費は1,800万円となるが、その内訳は人件費やAgent利用料だけではない。メソドロジー、知識資産の構築、品質保証への投資を含んでいる。そのため初期費用は従来より約2割高く見える。
3年間で見ると、顧客はTCOを1,600万円削減できる。一方、受託側も初期構築だけに依存せず、継続運用と成果共有によって契約価値を高められる。つまり、「発注側だけが得をする」「受託側だけが得をする」のではなく、長期的な価値を両者で共有する契約へと転換できるのである。

世界でも価格モデルは変わり始めている

この考え方は、本書独自のものではない。
a16zは2024年末のレポートで、AI時代の価格モデルはOutcome-Basedへ移行すると整理している。また、Bessemer Venture Partnersの『AI Pricing Playbook』では、プラットフォーム利用料・利用量課金・成果報酬を組み合わせる価格モデルが提唱されている。さらに、グローバルでは、人件費（Time & Material）だけでなく、方法論や知見への対価（Methodology Premium）、成果報酬（Value-Share）を組み合わせる価格モデルも広がりつつある。

価格ではなく、「価値」を設計する時代へ

AI駆動開発SI契約では、こうした世界的な潮流に加え、「価値創出」と「品質保証」を価格として明示することが重要になる。人月とAgent利用料だけではAI駆動開発の価値を十分に表現できないという問題意識は、今や世界共通になりつつある。AI駆動開発では、見積もりは工数を積み上げるためのものではない。知識資産、品質保証、そして生み出す成果まで含めて、顧客と受託側が長期的な価値をどう分かち合うかを設計するものへと変わっていく。その変化は、価格モデルの変更ではなく、SI契約そのものの転換なのである。

第6章　業界が問われている、六つの問い

ここまで、AI駆動開発によって書き換わる五つの前提を見てきた。最後に、受託側と発注側それぞれが、いま向き合うべき三つの問いを示したい。

受託側に問われること

• 第一に、過去案件で積み上げてきた応用設計のパターンは、棚卸しされ、価格を付けられる資産として整理されているか。

• 第二に、既存顧客との契約の中で、運用フェーズの位置付けや知識資産の帰属について、対話を始められているか。

• 第三に、自社の語彙構造化や業務ルールの形式化を、コーディングとは別の価値として提案書に書ける状態になっているか。

発注側に問われること

• 第一に、調達ガイドラインには、「資産帰属」「Agent改修権」「監査要件」を盛り込む準備ができているか。

• 第二に、AI関連調達の意思決定に、IT部門だけでなく、購買・監査・コンプライアンス部門も参画しているか。

• 第三に、社内のドメイン知識を言語化し、受託側と共有できる体制――例えばドメインオーナー制度のような仕組み――は整っているか。

六つの問いが、組み直しの出発点になる

この六つの問いに「まだ」が一つでも残っているなら、それが組み直しを始める最初の一歩になる。
AI駆動開発への移行は、一度にすべてを変えることではない。自社に不足しているものを見つけ、一つずつ整えていくことが、新しいSI契約への第一歩となる。

結章　契約書を、組み直す

五つの変化は、すべてつながっている

本稿では、AI駆動開発によって書き換わる五つの前提を見てきた。
納品物が変わる。開発の進め方が変わる。要件と責任分担が変わる。品質基準が変わる。そして、見積もり・費用の考え方も変わる。
重要なのは、この五つはそれぞれ独立した変化ではないということである。
一つだけを書き換えても、必ずどこかで矛盾が生まれる。価格を多層化しても、品質保証を契約に位置付けなければ発注側は安心できない。開発の進め方を循環構造へ変えても、人月契約のままでは継続的に資産を育てるインセンティブは生まれない。知識資産を納品物に加えても、その帰属や利用権を定めなければ、新しい契約は成立しない。

組み直すべきなのは、SI契約全体

つまり、組み直すべきなのは個別の制度ではなく、SI契約全体なのである。
これまでの契約は、「人月」という共通言語を前提として組み立てられてきた。しかしAI駆動開発では、知識資産、Agent、継続運用、品質保証といった新しい要素が価値の中心になる。
その変化に合わせて、契約もまた、新しい価値を前提に設計し直さなければならない。

発注側と受託側が、ともに設計する時代へ

この変化を、「受託側が負担する話」「発注側が負担する話」と分けて考えていては前に進まない。
AI駆動開発では、契約、役割分担、品質、価格を、発注側と受託側がともに設計することが求められる。
どちらか一方が最適化されても、もう一方が従来の考え方のままであれば、新しい契約は機能しない。

AI駆動開発は、契約から始まる

AI駆動開発は、単なる技術論ではない。
発注側と受託側が、新しい価値をともにつくるために、契約の前提そのものを組み直すことである。
その変化は、すでに始まっている。

会社概要

会社名：株式会社イー・ビジネス
所在地：〒105-6405 東京都港区虎ノ門1丁目17番1号 虎ノ門ヒルズビジネスタワー5階
設立：2007年6月12日
社員数：333名（2026年2月現在）
コーポレートサイト：https://www.e-business.co.jp/