本資料は、AI駆動開発とAIエージェントの普及によって、SIビジネスの構造がこれからどう変わっていくのかを、時間の流れに沿って俯瞰し、そのうえで、ユーザー企業・元請SIer・下請SIerのそれぞれが「どう変わるべきか」を定見としてまとめたものです。
起点を2026年秋に置いたのには理由があります。この一年で、二つのことが起きました。ひとつは、AIエージェントがコードの「補完」から、コード生成・テスト・レビュー・運用までを数時間から数日にわたって自律的に実行する「委任」の段階に入ったことです。もうひとつは、大手の元請SIerが「人月は崩壊する」と公言し、成果連動や利用量課金、継続価値（サブスクリプション）への転換を表明したことです。
つまり、人月モデルの終わりは、もはや「いずれ来る予測」ではなく、「すでに始まった現実」になりました。本資料の前半は、この現実を出発点として、2028年、2030年、そして2030年代へと構造がどう変わるかを描いています。後半は、その変化にそれぞれの立場でどう向き合うべきかを、私の定見として示しています。
構造変化の俯瞰
この図表は、全体の地図です。縦にユーザー企業・元請SIer・下請SIerの三つの立場を、横に「現在（2026年）」「〜2028年」「〜2030年」「2030年代」の四つの時期を置き、それぞれの交点で何が起きるかを一覧にしています。
読み方の要点は三つあります。
第一に、横軸の中央に境目があることです。左半分（現在〜2028年）は「ITシステムの開発を受託し、工数（人月）を売る」時代で、右半分（〜2030年代）は「IT前提の事業変革に伴走し、知識・技術・成果を売る」時代です。変化は徐々に進みますが、ビジネスの性格が入れ替わる分水嶺は2028年から2030年のあいだにある、というのが私の見立てです。
第二に、最下段に「取引の単位」を置いたことです。人月（工数）から始まり、人月と成果連動の併存を経て、成果・利用量・継続価値へ、そして知識・技術・サービスへと移っていきます。構造変化の正体は、技術の進化そのものではなく、「何を売り、何に対価を得るのか」が変わることです。この行を追うだけで、本資料の骨格がつかめます。
第三に、2030年代の列で元請と下請のセルがひとつに結合していることです。元請・下請という区別は、工数を層ごとに取り次ぐ構造があってはじめて成り立つものです。工数の取引が消えれば、この区別も消えます。残るのは、専門技術・業界知識・自社プロダクトを持つ独立したサービス事業者だけです。
ページの末尾に「AIが『書く』ほど、人間には『判断』と『責任』が残る」と記しました。これが、すべての変化を貫く原理です。
現在〜2028年 「人月の終わり」が兆しから現実へ
この時期の特徴は、「構図は変わらないのに、中身は変わり始めている」ことです。ユーザー企業が元請SIerに外注し、元請が下請に委託するという構図は、すぐには崩れません。ユーザー企業には内製に足るIT人材がいませんし、基幹業務や社会インフラに関わるシステムでは「人間による責任の担保」が強く求められるからです。
しかし、工数需要の減少と単金の下げ圧力は、すでに現実です。ページ右上の「変化の駆動力」に、その根拠を三つ挙げました。AIエージェントが開発工程を自律的に実行し、開発者の仕事の約6割にAIが関与するようになったこと。大手元請が人月の崩壊を公言し、契約と人員の見直しに着手したこと。そして、それでもなお外注構図が短期的には維持されるという、変化のブレーキです。
立場ごとに見ると、影響の現れ方が違います。ユーザー企業では、AIの利用が個人の効率化にとどまり、事業成果に結びつかないという悩みが広がっています。そのなかで、内製チームを立ち上げて小さく作り始める企業と、丸投げを続ける企業の二極化が始まります。
元請SIerでは、「早く仕上げるほど売上が減る」という矛盾が顕在化します。AIで生産性を上げれば上げるほど、人月で請求する限り収益は縮みます。だからこそ、コードを書けるエンジニアを自社に増やし、下請への委託を縮小し、契約を成果連動へ組み替え始めることになります。
そのしわ寄せを最初に受けるのが下請SIerです。コード生成やテストの工数需要は真っ先に消え、3次・4次請けから仕事が減っていきます。猶予は2年もないでしょう。本資料でこの時期を「兆しから現実へ」と呼ぶのは、下請にとってはもはや将来の話ではないからです。
〜2030年 「システム開発」ビジネスからの脱却
2030年にかけて、開発工程の主役はAIエージェントのチームになります。オーケストレーター役のエージェントが専門エージェントを束ね、並列に開発を進めます。人間の仕事は、仕様を決め、判断し、責任を持ち、ループの外側から監督すること（HOTL：Human on the Loop）に移ります。
ここで起きるのが、「開発量は増えるのに、外注は増えない」という現象です。開発コストが下がれば、これまで採算が合わずに見送られていた開発が実行され、「使い捨て」のソフトウェアも増えます。しかし、その増分は業務部門が対話で自ら作るか、内製チームが吸収します。俊敏性を求めるほど、外注の手続きは足かせになるからです。
では、価値はどこに移るのか。二つあります。ひとつは、仕様・行動指針・テスト・権限・ログといった「ハーネス」の設計です。AIエージェントに安心して任せるための足場を作る能力です。もうひとつは、「何を作るべきか」を定義する課題定義力です。作ることが安くなるほど、何を作るかの判断が高くなります。
ユーザー企業では、AIエージェントによる内製が標準になります。工数ではなく成果でITを買い、その結果に対する説明責任を自ら引き受けるようになります。これまで「ベンダーに任せていた」責任が、発注側に戻ってくるのです。
元請SIerにはレガシーの保守・運用が残りますが、単金は下がり続けます。収益の柱は、課題定義・AI活用設計・成果責任の共有を通じて事業変革に伴走すること、そして内製化支援と自社サービスへ移ります。「請負」から「伴走」への転換です。
下請SIerでは、2次請けの存在意義が問われます。元請が自社でAI駆動開発を回せるようになれば、工数を取り次ぐ理由はなくなります。専門技術・業界知識という「特別な何か」を持つか、自社サービスでユーザーと直接向き合うか。それができなければ、市場からの退出を迫られます。
2030年代 事業構造の転換と対等な関係
2030年代には、AIエージェントの開発チームが当たり前の前提になります。複数のエージェントがチームを組み、スクラムマスターやプロダクトオーナーの役割を担うエージェントも登場します。人間に残るのは、「何を解決したいのか、何を実現したいのか」を明確にし、結果に責任を取る役割です。ローコード／ノーコードはAIエージェントと融合し、ユーザー自身が対話でシステムを作ることが普通になります。
この段階で、工数の取引は消えます。残るのは、知識・技術・サービス・成果の取引だけです。そして、工数の取引が消えれば、それを前提に成り立っていた「発注する顧客と受注する業者」という関係も、「元請と下請」という階層も消えます。
ユーザー企業は、自分たちの業務ノウハウを活かして、自らデジタルサービスを提供する事業者になります。SIerとは協力もすれば、競合もします。業務を知っていて、マージンを載せる必要がなく、意思決定が速い。その意味で、SIerにとって最大の競合はユーザー企業自身になります。
SIerの側に残るのは、専門技術・業界知識・自社プロダクトを持つ独立したサービス事業者だけです。ユーザー企業と対等の立場で役割を分担し、必要なときに組み、重なるときには競います。
ページの最下段に「変われない企業」を置きました。工数を売り続けた企業は、ユーザー企業の内製チームとAIエージェントに置き換えられます。規模や元請という立場は、もはや防波堤にはなりません。これは脅しではなく、2030年代の構造をそのまま記述したものです。
立場別の定見
問うべきは「AIをどう使うか」ではなく、「AIで自分たちはどう変わるか」です。その問いに答えるために、立場ごとに「やめること」「始めること」「向かう先」の三つを整理しました。「やめること」を最初に置いたのは、新しいことを始める前に、古いことをやめなければ、人も資金も決意も、新しいことに振り向けられないからです。
ユーザー企業がやめるべきは、工数で買い、丸投げすることです。要件を固めてから発注するやり方も、不確実な時代には合いません。AIを個人の時短に使うだけの「AI係」を置いても、業績には結びつきません。始めるべきは、内製チームを持ち、AIエージェントと共に小さく作って確かめること。成果でITを買い、説明責任を自ら引き受けること。SIerとは「請負」ではなく「伴走」の契約を結ぶことです。向かう先は、IT活用の実践力を持ち、ITベンダーと対等に役割分担を議論できる企業、そして自らデジタルサービスを提供する事業者です。
元請SIerがやめるべきは、人月で売り、下請の工数に依存することです。「早く仕上げるほど売上が減る」契約を放置したままAIを導入しても、自らの首を絞めるだけです。FDEや内製化支援を人月商売の看板に掛け替えるのも、やめるべきことです。始めるべきは、AI駆動開発を自社で実践し、コードを書けるエンジニアとハーネスを持つこと。成果連動・利用量・継続価値へ、契約と評価制度を同時に変えること。情シスではなく事業部門・経営と向き合い、課題定義から関与することです。向かう先は、IT前提の事業変革に伴走するパートナーであり、自社プロダクト・サービスを持ってユーザーと協力・競合する独立した事業者です。
下請SIerがやめるべきは、元請からの工数発注を待つことです。「安く・早く」の価格競争に残る限り、AIエージェントには勝てません。変革を現場の自助努力に委ねるのも、やめるべきことです。始めるべきは、専門技術・業界知識に特化し、顔の見える顧客を直接持つこと。AIエージェントで少人数・高付加価値の開発体制に作り直すこと。そして、経営が現実を認め、評価・契約・組織の変革を自ら断行することです。向かう先は、「待つ会社」から「仕掛ける会社」へ。特化した技術・知識・プロダクトで選ばれる、小さくとも独立したサービス事業者です。
三つの立場に共通するのは、「人手を売る」から「知識と技術と成果を売る」への転換です。ユーザー企業にとっては「人手を買う」ことをやめる転換です。買い方が変わらなければ、売り方も変わりません。
立場を超えて共通する定見
変化の方向は決まっています。問われているのは、いつ、誰が、どこまで引き受けるかです。ここでは、立場を超えて共通する四つの定見を挙げました。
第一に、工数ではなく、成果を取引することです。「早く仕上げるほど売上が減る」矛盾は、人月を前提にする限り解けません。成果連動・利用量・継続価値へ契約を組み替え、評価制度もそれに合わせます。戦略と数字が一致してはじめて、現場は自律的に動きます。戦略では転換を掲げながら評価は短期の売上のまま、という二重基準が、もっとも士気を下げます。
第二に、AIが「書く」ほど、人間には「判断」と「責任」が残ることです。 判断の基準は、基礎・基本・原理原則です。仕様・行動指針・テスト・権限・ログというハーネスを設計し、ループの外側からAIを監督する能力が価値になります。逆に、AIに入力して出力を渡すだけの「AI係」に高い対価が払われる経営的合理性はありません。
第三に、請負から伴走へです。「発注者と受注者」の関係を、対等な実践者の役割分担へ変えます。要件が固まる前から関与し、動くシステムで応え、そこで得た知見を自社のサービスに還す。この循環があってはじめて、伴走は人月の言い換えではなくなります。顔の見える顧客を持つことが、プライドと知見の源泉になります。多重下請け構造は、この関係を組織的に断ってきました。
第四に、変革は現場の自助努力ではなく、経営の決断だということです。 人月と新しいモデルの中途半端な併存は、競争力を失います。契約・評価・組織・人材育成を同時に変える覚悟は、経営にしか持てません。猟予は、下請で0〜2年、元請でも1〜3年です。ただし、完璧な計画を待つ必要はありません。小さく始め、結果から考え、自分の正解を創り出すことです。
この四つは、ひとつの転換の四つの側面です。「人手を売るビジネス」から「知識と技術と成果を売るビジネス」へ。時短の先に、変革はありません。AIを使って変わるのではなく、AI前提で仕事・契約・組織を作り直す。それが、本資料の結論です。
最後にお伝えしたいこと
ここで述べた時間軸は、私の見立てです。年数は前後するでしょう。しかし、順序は変わらないと考えています。工数の取引が縮み、成果の取引が広がり、元請と下請の階層が消え、ユーザー企業とIT企業が対等になる。この流れが逆回りすることはありません。
「いつまでに何が起きるか」に目が向きがちです。けれども、ここでもっとも伝えたいのは、構造が変わることは誰にも止められませんが、その中で自分たちがどう変わるかは、自分たちで決められます。定見としてまとめたのは、その決めるためのたたき台にしていただきたいからです。
新著『【図解】コレ1枚でわかるAI戦略」のご紹介
このたび新著『【図解】コレ1枚でわかるAI戦略 ビジネスパーソンが主導権を握るための「知識と思考」（11月11日 Amazon出荷）』を上梓いたしました。このブログで連載しているAIについての解説は、本書の原稿を基に執筆しています。
本書は、AIプロジェクトでビジネスパーソンが主導権を握るために、何を知り、どう考えるべきかを整理し、豊富な図解とともにわかりやすく解説したものです。初心者向けの手引きでもなければ、エンジニアのための技術書でもありません。その中間に位置する、これまで誰も本格的に向き合ってこなかったテーマに挑んだ1冊と自負しています。
AIに限らず、ITに関わる取り組みは本来、事業に責任を持つビジネスパーソンが主導権を握って進めるべきものです。しかし現実には、技術の難しさを理由に、ITベンダーやSI事業者に任せきりにしてしまうプロジェクトが少なくありません。とりわけAIプロジェクトは、従来のITプロジェクトにはない特異性や技術の急速な進化もあって、「専門家への丸投げ」に陥りがちです。これでは、事業の成果に結びつけることはできません。
そこで本書では、AIプロジェクトの責任を託されたビジネスリーダーが、専門家であるエンジニアと対等に議論し、プロジェクトの主導権を握れるように、AIに関わる技術を数式やプログラム・コードを使わず、概念として理解できるように解説しました。あわせて、AIプロジェクトに特有の法律や規制、プロジェクト管理といった実務実践に欠かせない知識も整理しています。
さらに、AIに関連する数学的知識をまとめた別冊（PDF版）と、本書の全図表（PPTX版・ロイヤリティ・フリー）を、オンラインからダウンロードいただけるようにいたしました。
また本書は、AIプロジェクトをユーザー企業に提案するITベンダーやSIerの皆さんにも、お役に立つはずです。人月ビジネスの前提が崩れつつあるいま、お客様の事業に寄り添う力はこれまでにも増して求められ、AIはそのための「前提」となりました。一方で、AIプロジェクトには従来のITプロジェクトにはない特徴があり、これを理解しないままに取り組めば、お客様をミスリードしかねません。そうならないための知識を得ていただく一助にもなると思います。
今年6月に上梓いたしました『AI実践ドリル30日チャレンジ』（日経BP）が、AIを使って新たなビジネス価値を生み出す「個人のスキル」を磨くための本だとすれば、本書は、企業がビジネスとしてAIプロジェクトに取り組む「組織のスキル」を知るための本です。
既存の業務手順やビジネスモデルを前提に「AIで何ができるか」を考えるのではなく、AIを前提に既存を新しく作り直す、すなわち「AIでどう変わるか」という視点で実務実践に取り組む皆さんを支えたい。2冊に共通するのは、そんな思いです。あわせてご覧いただけますと幸いです。
AIは「使うと便利なもの」から「使うことが前提のもの」へと、その位置づけを変えました。そこに求められるのは、仕事の効率を上げるための「個人のスキル」にとどまらず、業績に貢献する「組織のスキル」です。本書は、その「知識と思考」を提供する1冊です。
AIは使っているものの、働き方が大きく変わった、会社が変わりつつある、そんな実感がなかなか持てない。もし、そんなモヤモヤしたものがあるのなら、ぜひ、本書を手に取ってください。
本書の目次
第1章：AIの現在地〜人間とテクノロジーの役割を再定義する
- テーマ1：そもそも「モデル」とは何か？
- テーマ2：生成AIの根幹「基盤モデル（ファウンデーションモデル）」
- テーマ3：AI、機械学習、ディープラーニング、生成AIの「包含関係」
- テーマ4：ビジネスで必須となる2つのフェーズ：「学習」と「推論」
- コラム1：「AGI」とは何か？
- テーマ5：AI進化の歴史〜「識別型」から「生成型」、そして「自律型」から「AGI」へ
- コラム2：「身体性を持ったAGI」へのロードマップ
- テーマ6：AIの強みと限界
- テーマ7：AI開発で鎬を削る、巨大企業たち
- テーマ8：AIの現在地と、ビジネスにおける「AI」の再定義
- テーマ9：人間との協働モデル〜AIに任せてはいけないこと
- コラム3：「センス」と「利他の精神」が羅針盤
第2章：業務への組み込みと自律型AI（Agentic AI）の実装
- テーマ1：プロンプトエンジニアリングの本質は「指示の構造化」にある
- テーマ2：自社独自の知識をRAGでAIに付与する
- テーマ3：ファインチューニングによりモデルを「専門家化」する
- テーマ4：AIaaSによるスピード導入の定石
- コラム1：タスクを各モデルへ自動で割り振る「AIモデルルーター」
- テーマ5：自律型AI（Agentic AI）の出現と動作原理
- コラム2：4段階のAI×ビジネス活用
- テーマ6：複数エージェントの協働（マルチエージェント）と新標準規格MCP
- テーマ7：AI組み込みによる次世代ユーザー体験（UX）の設計思想
- テーマ8：ノーコード・ローコードAIツールの実務価値とセキュリティガバナンスの限界
第3章：第3章：開発最前線とAIインフラの進化
- テーマ1：Transformer（トランスフォーマー）はなにが革命的だったのか
- テーマ2：リーズニングモデル（推論強化モデル）の衝撃
- テーマ3：推論専用チップの台頭
- テーマ4：小規模言語モデル（SLM）とローカルモデル（AI PC）がもたらす自律分散型インフラ
- テーマ5：バーティカルAI（特化型モデル）の選択基準
- テーマ6：E2Eマルチモーダルモデルによるリアルタイム対話の進化
- テーマ7：説明可能なAI（XAI）の実務上の要求
- テーマ8：現実世界の物理法則を予測・理解する「世界モデル」
- テーマ9：物理空間で自律駆動する「フィジカルAI(ロボティクス)」への接続
第4章：AIプロジェクトの企画と推進
- テーマ1：AIプロジェクトの全体像は、課題から逆算せよ
- テーマ2：自社の課題を発見する「業務機能別ユースケースの見取り図」
- テーマ3：AI推進チームに必要な3つの役割（ビジネス、データ、エンジニアリング）
- テーマ4：全社的なAIリテラシー向上のための「リスキリング戦略」
- テーマ5：死の谷に陥らないためのPoC（概念実証）の進め方
- テーマ6：RFP（提案依頼書）に絶対に盛り込むべきAI特有の要件
- テーマ7：AIプロジェクト特有のコスト構造とROIの正しい見積もり方
- コラム1：生成AIサービスの料金モデル：仕組みと賢い使い分け
- テーマ8：生成AI導入の4大アプローチとベンダー評価軸
- テーマ9：AIの精度を決める「良質なデータ」の条件とデータ・サプライチェーン
- テーマ10：開発手法のベストプラクティス(SaaS利用 vs API連携 vs 独自モデル構築)
- テーマ11：システム開発を再定義する「AI駆動開発」と内製化モデル
- テーマ12：導入を成果に変える「定着マネジメント」〜 死の谷の先にある「定着の谷」
- テーマ13：AIプロジェクトの全体を俯瞰しその進め方を整理する
第5章：リスク回避のためのAIガバナンス
- テーマ1：企業として備えるべき基本のAIルール「社内AI利用ガイドライン」の作り方
- テーマ2：生成AIと著作権〜実務的な対処法
- テーマ3：情報漏洩リスクとセキュリティ対策〜クラウド利用とローカルモデルの使い分け
- テーマ4：AIのバイアスと公平性の問題〜企業のブランドリスクへの対応
- テーマ5：国内外のAI法規制の全体地図〜ルールを「設計要件」として読み解く
- テーマ6：ディープフェイクと偽情報〜「攻撃される側」のリスクへの防衛
- テーマ7：業務の効率化から「事業の再設計」へ〜AIが変えるビジネスモデル
- コラム1：AI主権とは何か
