AI時代に汎用AIを使うべきか、特化型AIエージェント製品を導入すべきか、自社開発すべきか：最新研究・事例によるシステム導入の考え方

Overview

企業向けAIを自社開発した場合、本番運用に至るのはわずか5%であり、自社開発だけでなく既存製品の汎用AIや特化型AIエージェントを適材適所で導入することが、企業のAI導入の成功率を高めます。本稿は、ITプロジェクト失敗の研究と事例、そして2025年以降のAI企業調査をもとに、汎用AI・特化型AIエージェント・自社開発の3つの選択肢を、業務の性質で使い分ける考え方を整理します。結論としては、「モデルは買い、データは自社で持ち、ワークフローは業務の性質で選ぶ」こと、そして迷ったら汎用AIから始め、特化型、自社開発へと可逆的な順序で進むことが重要です。

はじめに

AIの進歩はめざましく、ほとんど全ての企業や組織にとって、AI導入は必須の検討事項になっていると思います。AI導入の選択肢としては大きく2つあり、既存製品を導入すること、もしくは自社開発をすることです。そしてAIに関して既存製品を導入することは、２つの選択肢に分かれ、汎用AIを導入すること、特化型AIエージェントを導入することがあります。これらは導入対象となる業務によって選択を分ける必要があり、本稿ではその考え方に最新の研究や実務事例を踏まえて整理します。

本コラムの新規性は、次の4点にあります。

• 既存製品導入と自社開発の成功事例・失敗事例・成功確率を比較している：ITプロジェクトの失敗については多くの事例や統計が語られてきましたが、「既存製品を導入した場合」と「自社開発した場合」で、成功と失敗の両方を同じ土俵で比較した整理は多くありません。本稿では、両者の成功事例・失敗事例と、調査研究が示す成功確率を並べ、どちらか一方が安全という単純な結論にならないことを示します。

• 失敗の要因を、システム導入の工程に沿って漏れなく重複なく整理している：ソフトウェア工学・行動経済学・情報システム研究のそれぞれに失敗要因の研究が蓄積されていますが、互いに異なる用語で語られ、実務家が全体像をつかみにくい状態にあります。本稿では、企画から運用までの5つの工程に沿って要因を配置し、既存製品導入に固有の要因、自社開発に固有の要因、両者に共通する要因を区別します。

• 「どの業務が既存製品に向き、どの業務が自社開発に向くか」を、経営学の理論で判断できる：Williamson（1985）、Barney（1991）、Carr（2003）、Wardley（2020）らの理論を、「差別化」「資産特殊性」「市場成熟度」「変化速度」という4つの判断軸に翻訳し、業務の性質から導入形態を導けるようにします。

• 「汎用AI」「特化型AIエージェント」「自社開発」の3つの選択肢を、カスタマイズの有無も含めて対象業務と対応づけている：2025年以降に公表された企業調査（MIT NANDA, 2025; Menlo Ventures, 2025）は、AIにおいても自社開発の本番到達率が既存製品の半分程度にとどまることを示しています。本コラムでは、汎用AIと特化型AIエージェントの違いを「対象とする市場」「提供する価値」「組み込まれている知識」の観点から整理し、それぞれをカスタマイズせずに使う場合と、カスタマイズして使う場合に分けて、適する業務を示します。

システム導入の成功事例・失敗事例

システム導入の判断を考える前提として、まず「どのような成功と失敗が起きているのか」を確認します。失敗は自社開発に限られた現象ではなく、既存製品の導入でも繰り返されています。同時に、成功事例を見ると、既存製品導入と自社開発のそれぞれに、成功するための明確な条件があることがわかります。

既存製品導入

既存製品導入の成功事例

既存製品導入の成功事例に共通するのは、「製品を業務に合わせて作り込むのではなく、業務を製品の標準に合わせた」こと、そして「段階的に導入した」ことです。

• Hershey（2002年）：失敗の3年後、同じ製品で成功した事例：1999年にERPの一斉切り替えで大規模な出荷障害を起こしたHersheyは、2002年に同じSAPシステムの大規模アップグレードを実施し、今度は予定より早く、予算を約20%下回って完了させました（Koch, 2002）。変わったのは製品ではなく進め方であり、需要の閑散期に切り替えを行い、テストと教育に十分な期間を取り、段階的に移行したことが成功の要因とされています。

• Nike（2001〜2006年）：段階的導入への転換：Nikeは2000年に需要予測システムの導入で約1億ドルの売上機会を失う失敗を経験しましたが、その後の基幹システム刷新では「一度にすべてを切り替えない」方針に転換し、地域ごと・業務ごとに数年かけて段階的に導入しました。この転換により、2006年までに大きな障害を起こさずに刷新を完了しています（Koch, 2004）。

• Netflix（2008〜2016年）：基盤は買い、差別化は作る：Netflixは2008年のデータベース障害を契機に、自社データセンターからAWSへの移行を開始し、2016年に最後のデータセンターを閉鎖しました（Netflix, 2016）。サーバーやデータベースなどの基盤は外部のクラウドを利用する一方、推薦アルゴリズムや配信の制御といった差別化の核となる部分は自社開発を続けています。「何を買い、何を作るか」を明確に分けた代表的な事例です。

• Capital One（2020年）：金融機関によるクラウド全面移行：米国の大手銀行Capital Oneは、8つのデータセンターをすべて閉鎖し、2020年にインフラをAWSに全面移行しました（Capital One, 2020）。規制産業である金融機関でも、インフラ層を外部製品に委ね、顧客向けアプリケーションやデータ分析に自社の開発資源を集中させる判断が可能であることを示しました。

既存製品導入の失敗事例

既存製品導入の失敗事例に共通するのは、製品を標準のまま使わず、自社の業務に合わせて大きく作り込んだこと、あるいは切り替えの方法を誤ったことです。

• FoxMeyer Drug（1996年）：米国の医薬品卸大手FoxMeyerは、SAP R/3と倉庫自動化システムの導入に失敗し、1996年に破産申請に至りました。想定を大きく超える処理量と、並行して進めた倉庫再編の複雑さが原因とされ、ERP導入失敗の象徴的事例となっています。例えば、新システムが一晩に処理できた注文は約1万件で、旧システムの約42万件を大きく下回り、受注を処理しきれない状態が続いたと報告されています。

• Hershey（1999年）：菓子大手Hersheyは、ERP・顧客管理・サプライチェーン計画の3システムを、需要ピークのハロウィン直前に同時稼働させました。受注処理の混乱によって約1億ドル相当の注文が出荷できず、四半期利益は19%減少しました。導入スケジュールの圧縮と、一斉切り替え（ビッグバン）方式が主因と分析されています。

• Lidl（2018年）：ドイツの小売大手Lidlは、7年間で約5億ユーロを投じたSAP導入プロジェクトを2018年に中止しました。SAPの標準が在庫を小売価格で評価するのに対し、Lidlは仕入価格で管理する従来の方式にこだわり、大規模なカスタマイズを積み重ねたことが破綻の原因とされています（Handelsblatt, 2018）。

• Birmingham City Council（2022年〜）：英国最大の地方自治体であるバーミンガム市は、SAPからOracle Fusionへの基幹システム移行で、当初約1,900万ポンドの予算が1億ポンド超に膨らみ、財務報告や監査に支障が生じました。外部監査人は、標準機能で対応できるはずの業務に対して過剰なカスタマイズを行ったことを主因の一つとして指摘しています（Grant Thornton UK LLP, 2023）。例えば、銀行取引の照合という標準機能で処理できるはずの業務を独自仕様にした結果、照合が手作業に戻り、数万件の未処理が積み上がったと報告されています。

自社開発

自社開発の成功事例

自社開発の成功事例に共通するのは、”その業務が競争優位の核であり、市場に適切な製品が存在せず、開発と改良を続ける組織能力があった”ことです。

• Walmart（1990年代〜）：サプライチェーンの独自システム：Walmartは1991年に取引先と販売・在庫データを共有する独自システム「Retail Link」を構築し、店舗ごとの販売実績を取引先にリアルタイムで開示することで、補充の精度と速度で競合を大きく引き離しました。Bessen（2022）は、こうした市販されていない独自ソフトウェアが、小売業における同社の優位の源泉になったと分析しています。

• Amazon（2000年代〜）：社内基盤がそのまま事業になった事例：Amazonは小売事業を支えるために独自に構築した計算基盤・ストレージ・データベースを、2006年以降AWSとして外部に提供し、現在では同社の利益の大半を生む事業に育てました。自社開発したシステムが、自社の業務効率化にとどまらず新しい事業そのものになった事例であり、独自開発が正当化される最も強い形といえます。

• Inditex（Zara）（2000年代）：業務モデルに合わせた簡素な独自システム：Zaraを展開するInditexは、2週間で企画から店頭までを回す独自の業務モデルを支えるために、店舗端末から本部の生産計画までをつなぐシステムを自社で開発しました。Ferdows et al.（2004）は、同社のシステムが技術的には簡素である一方、業務モデルに完全に適合しており、市販の製品では実現できない競争優位を生んでいると分析しています。

• JPMorgan Chase（2024年〜）：規制産業における自社開発AI：JPMorgan Chaseは、外部の基盤モデルを社内基盤上で利用する「LLM Suite」を自社開発し、2024年に展開を開始して2025年までに約20万人の従業員が利用する規模に広げました（JPMorgan Chase, 2025）。金融規制のもとで機密データを外部に出せないこと、巨大な技術組織と年間数十億ドルの技術予算を持つこと、独自データが差別化の核であることという条件がそろった事例です。

自社開発の失敗事例

自社開発の失敗事例に共通するのは、巨大な独自システムを長期間かけて一括で構築しようとしたこと、複数の組織の成果物を統合する責任者が不在だったこと、そして要件が最後まで変わり続けたことです。

• 英国NHSの国家プログラム（NPfIT）：2002年に開始された英国国民保健サービスの電子カルテ統合プログラムは、約100億ポンド以上を投じたのち、2011年に事実上解体されました。英国下院の公会計委員会は「史上最悪のIT大失敗の一つ」と評しています（House of Commons Committee of Public Accounts, 2013）。中央集権的に巨大な独自システムを一括で開発しようとしたこと、現場の医療機関ごとに異なる要件を反映しきれなかったこと、契約した開発企業との関係が破綻したことが主因とされています。例えば、全国で統一された電子カルテを目指したにもかかわらず、病院ごとに診療の手順や記録の様式が異なり、現場が使える形に落とし込めないまま開発企業が相次いで撤退しました。

• 米国Healthcare.gov：2013年10月に公開された医療保険取引所サイトは、公開初日に数百万人のアクセスに対してわずか数人しか登録を完了できず、大規模な立て直しを要しました。複数の請負業者が分担して開発した独自システムを統合する責任者が不在だったこと、要件が公開直前まで変更され続けたこと、負荷テストが本番直前まで実施されなかったことが監査で指摘されています（U.S. Government Accountability Office, 2014）。

• Hertzのウェブサイト・アプリ開発：レンタカー大手Hertzは2016年からコンサルティング会社に委託して新しいウェブサイトとモバイルアプリを開発しましたが、納品物が動作しないとして2019年に3,200万ドルの返還と損害賠償を求めて提訴しました。要件の変更、モバイル対応の欠落、テストの不足が争点となり、独自開発を外部に委託しても「委託先を変えれば解決する」問題ではないことを示す事例となりました。例えば、タブレット向けの画面サイズへの対応が契約に含まれているかどうかをめぐって両者の認識が食い違い、発注側が要件を明確に定義し検収する能力を欠いていたことが浮き彫りになりました。

• 金融機関の勘定系システム：大手銀行の勘定系刷新は、複数年・数千億円規模の独自開発になることが多く、稼働後に大規模障害を繰り返した事例が各国で報告されています。長期にわたる開発期間中に要件と技術が変化すること、複数ベンダーの成果物を統合する難しさ、稼働後にシステムの全体像を理解する人材が社内に残らないことが、障害の背景として分析されています。例えば、開発に10年近くを要したプロジェクトでは、着手時に選んだ技術が稼働時には旧世代になっており、保守できる技術者の確保そのものが課題になりました。

システム導入の成功確率

個別の事例だけでは、どちらの形態がどれくらいの確率で成功するのかはわかりません。本章では、調査研究が示す成功確率を確認します。

既存製品導入の成功確率

• ERP（基幹システム）の導入の成功率は約50％弱：既存製品導入の代表であるERPについて、Panorama Consulting Group（2023）の継続調査は、導入企業の半数前後が予算または期間を超過し、当初期待した効果を十分に得られたと回答する企業は半数に満たないと報告しています。一方で、プロジェクトの規模が小さく撤退が容易であるため、極端な失敗は少ないです。既存製品の導入は、業務領域ごとに分割して契約・解約できるため、1件あたりの投資額と失敗時の損失が限定されます。例えば、営業支援ツールの導入に失敗しても、損失は数か月分の利用料と移行費用にとどまり、企業の存続に関わることはまれです。

• SaaSライセンスの利用率は60%程度：導入そのものは完了しても、契約したライセンスが使われないという形の失敗は広く見られます。Zylo（2023）の調査では、企業が契約しているSaaSライセンスのうち約40%が未使用で、1社あたり年間約1,700万ドルが無駄になっていると報告されています。例えば、部門ごとに別々のプロジェクト管理ツールを契約した結果、全社で5種類の同種ツールが並存し、どれも定着しないといったケースです。

• AIの導入成功率において既存製品導入は自社開発の2倍：MIT NANDA（2025）は、外部ベンダーとの提携によって導入したAIツールの本番到達率が約67%であったのに対し、自社開発したツールは約33%にとどまったと報告しています。既存製品を選ぶことが成功を保証するわけではありませんが、成功確率を大きく引き上げることは、AIにおいても確認されています。

自社開発の成功確率

• 自社開発の成功率は30%程度：Standish Groupが継続的に公表しているCHAOSレポートでは、予算・期間・満足度のすべてを満たしたソフトウェアプロジェクトは全体の3割前後で、約2割は中止または未使用に終わり、残りの半数は予算超過・遅延・機能不足のいずれかを抱えた状態で完了しています（Standish Group, 2015, 2020）。成功の定義や調査対象には議論がありますが、この比率は20年以上大きく変わっていません。

• 自社開発の規模別の成功率は大規模は6%、小規模は61％：Standish Group（2015）の規模別集計では、小規模プロジェクト（100万ドル未満）の成功率が61%であるのに対し、大規模プロジェクト（1,000万ドル超）では成功は6%、失敗（中止または未使用）は43%に達します。プロジェクト規模が大きくなるにつれ成功率は急落します。McKinseyとオックスフォード大学が5,400件以上のITプロジェクトを分析した調査では、予算1,500万ドル以上の大規模プロジェクトは平均で予算を45%、期間を7%超過し、当初想定した価値を56%下回っていました（Bloch et al., 2012）。例えば、同じ組織が同じ開発チームで取り組んでも、1億円のプロジェクトを10本に分ける場合と、10億円のプロジェクトを1本で行う場合では、後者が「予算・期間・価値をすべて達成する」確率は前者の10分の1程度にまで下がる、ということです。

• AIの自社開発では成功率は5％：MIT NANDA（2025）は、企業向けのカスタムAIツールについて、評価に至った企業が60%、パイロットに進んだ企業が20%、本番運用に至った企業はわずか5%であると報告しています。従来のソフトウェア開発と比べても、AIの自社開発は本番到達の壁が高いことがわかります。

システム導入の失敗の要因

既存製品導入と自社開発のそれぞれの失敗要因を整理します。システム導入を「企画・投資判断」「要件定義・製品選定」「設計・開発・カスタマイズ」「テスト・移行・稼働」「運用・保守・進化」の5つの工程に分け、各工程で生じる要因を整理します。

既存製品導入の失敗の要因

既存製品の導入では、製品本体の設計・開発・保守はベンダーが担うため、失敗の要因は”製品を選ぶ段階”と”製品を自社に合わせる段階”、そして”組織側の変化”に集中します。

工程1：企画・投資判断

• 導入形態の誤判断：差別化の核となる業務を、標準製品で済ませてしまう判断です。資源ベース理論（Barney, 1991）が示すように、市場で誰でも買える製品は競争優位の源泉にはならないため、自社の強みそのものである業務を既存製品に置き換えると、強みが失われます。例えば、独自の需要予測の精度で競合に勝っていた小売企業が、標準的な需要予測モジュールに切り替えた結果、競合と同じ精度に「平準化」されてしまうケースです。

• 補完的投資の予算化漏れ：Brynjolfsson et al.（2021）は、ITやAIなどの汎用技術の導入効果が当初は現れず、後になって加速する「生産性のJカーブ」を示しました。その理由は、業務プロセスの再設計・人材の再教育・組織構造の変更といった無形資産への補完的投資が必要であり、それが計測されないコストとして先行するためです。既存製品の導入では「ライセンス料と導入支援費」だけが予算化され、業務を標準に合わせるための現場の作業や教育が見積もられないことが典型です。例えば、経費精算システムを導入したものの、承認ルールの見直しと管理職への教育を行わなかったため、紙の申請書とシステム入力の二重運用が続いた、という事例です。

• 「導入すれば効果が出る」という前提：Aral & Weill（2007）が示したように、IT投資の効果は投資額ではなく組織のケイパビリティによって決まります。製品の機能一覧を見て効果を期待する判断は、この前提を欠いています。例えば、顧客管理システムを導入しても、営業担当者が商談記録を入力する習慣と、その記録を使って指導する管理職の行動がなければ、システムは「高価な住所録」にとどまります。

工程2：要件定義・製品選定

• 業務と製品のミスフィットの見落とし：Davenport（1998）は、ERPのような企業システムがベンダーの想定する「業務の進め方」の前提を組み込んでおり、導入企業は「システムを業務に合わせるか、業務をシステムに合わせるか」という戦略的な選択を迫られると述べました。Soh et al.（2000）は、製品と組織の不一致（ミスフィット）をデータ・機能・出力の3種類に分類し、選定段階でこの不一致を評価しないまま導入を進めると、後の工程でカスタマイズによる解消を迫られることを示しています。例えば、

• ベンダーと製品の継続性評価の不足：製品の機能比較に終始し、ベンダーの財務状況、顧客基盤、製品ロードマップ、買収された場合の影響、データのエクスポート手段を評価しないまま契約することです。Shapiro & Varian（1999）が示したように、ソフトウェアはデータ形式・業務手順・従業員のスキルが特定製品に依存するため、乗り換えに大きなコストがかかります。例えば、スタートアップが提供する勤怠管理ツールを全社導入した後にそのベンダーが買収され、1年後にサービス終了が通知されたものの、過去の勤怠データを一括で取り出す手段が契約に含まれていなかった、というケースです。

• 発注側のケイパビリティの不足：ITアウトソーシング研究のレビュー（Lacity et al., 2009）は、外部に委ねる場合であっても、要件を定義し、ベンダーを評価・統制する能力を発注側が保持していることが成果を左右すると一貫して報告しています。この能力を失った企業は、ベンダーの提案を評価できず、導入支援会社の言うままに不要な機能やカスタマイズを契約してしまいます。例えば、情報システム部門を縮小して外部委託に切り替えた企業が、ERPの更新時に「どの業務にどの設定が必要か」を自社で説明できず、導入支援会社が前回と同じ設定を踏襲した結果、すでに廃止した業務のための機能に費用を払い続けた、という事例です。

工程3：設計・開発・カスタマイズ

• 過剰なカスタマイズ：Brehm et al.（2001）は、ERPの調整方法を「設定（パラメータ変更）」から「パッケージのソースコード改変」まで9段階に分類し、段階が深くなるほど、技術的リスク・保守コスト・ベンダーサポートの喪失が増大することを示しました。多くの企業は「カスタマイズ」を一括りに捉えがちですが、設定の範囲で収まる調整と、コードに手を入れる改変とは性質が全く異なります。例えば、承認フローの段数を設定画面で3段から4段に変えるのは設定ですが、「部長が不在のときは課長2名の承認で代替する」という独自ルールをプログラムとして追加するのは改変であり、製品のバージョンアップのたびに動作確認と修正が必要になり、ベンダーの保守コスト増大や、ベンダーサポートの喪失につながります。

• 連携部分の複雑化：製品本体に手を入れなくても、他システムとの連携を多数作り込むと、連携部分が実質的な独自システムになります。例えば、ERPと既存の販売管理システム、倉庫システム、会計システムの間に数十本のデータ連携を構築した結果、どれか一つの製品をバージョンアップするたびにすべての連携の再試験が必要になり、「製品は買ったが、連携の保守に専任チームが必要」という状態になるケースです。

• 設定の複雑化と属人化：コードを書かない設定であっても、長年の積み重ねで誰も全体像を理解できない状態になることがあります。例えば、顧客管理システムに10年間で数百の項目と自動化ルールが追加され、新しいルールを追加すると既存のルールと干渉して予期しない動作が起きるようになった、という事例です。

工程4：テスト・移行・稼働

• テストとデータ移行の軽視：既存製品は「動作が保証されている」という思い込みから、自社の設定・データ・連携を含めた業務シナリオのテストが省略されがちです。Somers & Nelson（2001）はERP導入の成功要因を調査し、「データの正確性」と「ソフトウェアのテスト」を導入段階の重要要因として挙げ、Redman（1998）は低品質なデータが企業の業務コストを押し上げる仕組みを整理しています。例えば、製品単体では正しく動く請求処理が、旧システムから移行した顧客データに含まれていた不整合（同じ顧客が複数の表記で登録されている等）によって二重請求を起こした、というケースです。

• 一斉切り替えのリスク：旧システムから新システムへ一度に切り替える方式は、問題が発生した際の影響範囲が最大になります。Hersheyは需要ピーク直前に3システムを同時稼働させ、受注処理の混乱を招きました。段階的な移行や並行稼働は費用がかかりますが、大規模な失敗を避けるための保険として機能します。例えば、同じHersheyが2002年の更新では閑散期を選び、段階的に切り替えたことで成功したのは、この教訓の裏返しです。

• 現場の受け入れ不足：既存製品は業務の進め方を変えることを前提とするため、現場が変更を受け入れなければ、稼働直後に旧来の手順や個人の表計算への「逆戻り」が起きます。例えば、新しい購買システムが稼働した後も、現場の担当者が従来どおり電話で発注し、後からシステムに入力する「後追い入力」が常態化し、在庫データが実態と乖離した、という事例です。

工程5：運用・保守・進化

• ベンダーの方針変更とロックイン：Farrell & Klemperer（2007）が理論的に整理したように、スイッチングコストはベンダーに価格支配力を与えます。2023年のBroadcomによるVMware買収後、ライセンスの永続版が廃止されサブスクリプションへ移行し、多くの企業で費用が数倍に増加したことは、その代表的な事例です。製品の提供終了や、ベンダーそのものの倒産・買収もこの要因に含まれます。

• カスタマイズした部分の保守負担：工程3で製品に加えた改変は、製品のアップデートのたびに再検証と修正が必要になります。Erlikh（2000）が示したように、ソフトウェアのライフサイクルコストの大半は保守であり、改変部分の保守は自社の負担になります。例えば、クラウド型ERPが年4回の自動アップデートを行うたびに、独自に追加した帳票や処理ロジックの動作確認に数週間を要し、アップデートが「改善」ではなく「負担」になっているケースです。

• 組織変革の遅れと定着の失敗：システムが稼働しても、業務プロセスと組織が変わらなければ効果は現れません。Aral & Weill（2007）が示したように、効果を決めるのは組織のケイパビリティであり、工程1で補完的投資を予算化しなかった結果が、この工程で「使われないシステム」として顕在化します。例えば、前章で触れたZylo（2023）の調査が示す「約40%のライセンスが未使用」という状態は、この失敗の集積です。

• SaaSの乱立とデータの分断：部門ごとに個別のSaaSを契約した結果、同じデータが複数のシステムに分散し、全社的な把握が難しくなる現象です。例えば、営業部門・カスタマーサポート部門・マーケティング部門がそれぞれ別の顧客管理ツールを使い、同じ顧客の情報が3か所で食い違っている、という状態です。

自社開発の失敗の要因

自社開発では、企画から保守までのすべての工程を自社が担うため、失敗の要因は5つの工程すべてに現れます。とくに、要件の可変性・複雑性・保守コストといったソフトウェア固有の性質に起因する要因と、計画錯誤・エスカレーションといった人間の判断に起因する要因が、プロジェクトの規模と期間に比例して深刻化する点が特徴です。既存製品導入ではベンダーが引き受けてくれる部分を、自社開発ではすべて自社が引き受けることになります。

工程1：企画・投資判断

• 導入形態の誤判断：差別化につながらない業務を自社で作る判断です。取引コスト理論（Williamson, 1985）は、標準的で、要件が安定し、多数の供給者から調達できる業務は市場から買う方が合理的であることを示していますが、実務では「自社の業務は特殊だ」という思い込みや、過去の経緯によって判断が歪められます。Carr（2003）が指摘したように、コモディティ化した技術領域への過剰な投資は、優位を生まずに費用とリスクだけを増やします。この判断ミスは後続のあらゆる工程の失敗の起点になります。例えば、会計・給与・勤怠といった、法令で手順がほぼ決まっている業務を「自社の運用に合わないから」という理由で独自開発し、法改正のたびに改修費用を払い続けている企業は少なくありません。

• 計画錯誤による費用・期間の過小評価：Kahneman & Tversky（1979）は、人が計画を立てる際に過去の類似事例（外部の視点）を無視し、目の前の計画の詳細（内部の視点）から見積もる傾向を指摘しました。その結果、期間と費用は系統的に過小評価されます。Flyvbjerg（2006）は対策として、類似プロジェクトの実績分布から見積もりを補正する「参照クラス予測」を提案しています。前章のべき乗分布の研究（Flyvbjerg et al., 2022）は、この参照クラスがどのような形をしているかを実証的に示したものであり、独自開発の規模が大きいほど分布の裾は厚くなります。例えば、「要件は固まっているので18か月で完成する」という見積もりは、同種のプロジェクトの実績が平均27%超過・6件に1件が3倍という分布（Flyvbjerg & Budzier, 2011）に従うことを無視した「内部の視点」の典型です。

• 補完的投資の予算化漏れ：既存製品と同様に、業務の再設計・教育・組織変更の費用が「開発費」の外側に置かれます（Brynjolfsson et al., 2021）。自社開発ではさらに、開発した後の運用体制（監視、問い合わせ対応、障害対応）の人員が見積もられないことが多くあります。Lientz & Swanson（1980）は、稼働後の保守・運用に要する工数が開発工数を上回ることを大規模調査で示しており、この工数を予算に含めない計画は構造的に不足します。例えば、開発チーム10名で構築したシステムの稼働後に、障害対応と改修要望への対応で開発チームの半分が張り付きになり、次の開発に着手できなくなった、という事例です。

• スコープの肥大化と一括構築志向：複数の業務領域を一つの巨大なシステムとして一括で構築しようとする判断は、規模・期間・統合の複雑さをすべて増大させます。Flyvbjerg et al.（2022）は、技術要素間の相互依存が連鎖反応を起こし、極端なコスト超過につながるメカニズムを提示し、Flyvbjerg & Gardner（2023）は、小さな単位を繰り返し組み立てるモジュール型のプロジェクトが一括構築型よりはるかに安全であることを示しています。NHSのNPfITは、この一括構築志向の帰結を示す事例です（House of Commons Committee of Public Accounts, 2013）。例えば、「せっかく作るなら販売・在庫・会計・人事をすべて統合しよう」という判断は、各領域の遅延が互いに影響し合う構造を自ら作ることになります。

工程2：要件定義・製品選定

• 要件は使い始めてから必ず変わる：Brooks（1987）は、ソフトウェアには道具や手法では解消できない「本質的な難しさ」があり、その一つが「使われ始めると必ず変更を求められる」という性質（可変性）だと指摘しました。利用者は動くものを見て初めて本当に必要なものに気づき、法律や業務も開発中に変わるため、どれだけ丁寧に要件を固めても「完成すれば終わり」にはなりません。既存製品ではこの変化への対応をベンダーが引き受けますが、自社開発では自社が永久に追い続けることになります。

• 要件定義の主体の不在：自社開発では、「何を作るか」を決める、かつ開発の知見・技術がシステム会社の人員並みに保有する責任者が発注する業務部門側に必要です。開発外注先を含め開発チームは「どう作るか」は決められますが、「どの業務を、どの順番で、どこまで」は業務を知る人にしか決められないからです。Hofmann & Lehner（2001）は、業務側の関与の度合いがプロジェクトの成否を最も強く説明することを示し、Standish Group（2015）も「利用者の関与」を成功要因の最上位に挙げています。この責任者が不在のまま開発が始まると、要件は外注先のシステム会社の推測か、現行システムの模倣で埋められます。例えば、業務部門が「今のシステムと同じことができればよい」としか言わず、開発チームが現行画面を一つずつ再現した結果、20年前の業務手順を新技術で作り直しただけのシステムができあがった、という事例です。

• 発注側（委託する場合）のケイパビリティの不足：自社開発を外部に委託する場合、要件を定義し、進捗と品質を評価する能力を発注側が保持していなければ、納品物を評価できません（Lacity et al., 2009; Feeny & Willcocks, 1998）。米レンタカー大手Hertzの事例（Webサイトおよびモバイルアプリの全面刷新プロジェクトが失敗したとして、委託先のアクセンチュアを相手取り、3,200万ドル以上の損害賠償）は、この能力の欠如が訴訟に至るまで放置された例と解釈できます（Hertz Corp. v. Accenture LLP, 2019）。例えば、委託先から毎月提出される進捗報告を「順調」と受け取り続け、納品の3か月前になって初めて主要機能が動いていないことに気づく、というパターンです。

工程3：設計・開発・カスタマイズ

• 複雑性と相互依存による連鎖的な遅延：Brooks（1975）の「遅れているプロジェクトに人員を追加すると、さらに遅れる」という法則は、コミュニケーションのコストが人数の二乗で増えることに由来します。独自に設計したシステムは構成要素間の相互依存が多く、一箇所の遅延や設計変更が他の要素へ連鎖します。Flyvbjerg et al.（2022）が極端なコスト超過のメカニズムとして挙げたのも、この連鎖反応です。例えば、データベースの設計変更が、それを参照する画面・帳票・連携処理のすべてに波及し、1週間の変更作業が3か月の手戻りになる、という構造です。

• 技術的負債の蓄積：Cunningham（1992）が「技術的負債」という比喩で示したように、納期を優先した設計上の妥協は、その後の変更コストを継続的に押し上げます。自社開発では負債の返済（リファクタリング）を自社で計画的に行う必要があります。例えば、「とりあえず動くように」と同じ処理を複数箇所にコピーして実装した結果、仕様変更のたびにすべての箇所を探して修正する必要が生じ、修正漏れによる不具合が繰り返される、という事例です。

• 統合責任の不在：複数の開発会社や部門が分担して開発する場合、全体を統合し、品質に責任を持つ主体が不在になることがあります。Healthcare.govの監査（U.S. Government Accountability Office, 2014）は、統合責任者の不在を主要な失敗要因として指摘しました。例えば、画面を担当する会社、データ処理を担当する会社、外部機関との接続を担当する会社がそれぞれ「自分の担当範囲は完成した」と報告しているのに、つなげると動かない、という状態です。

• 技術選定の誤り：長期の開発では、着手時に選んだ技術が完成時には陳腐化している、あるいは特定の技術者にしか扱えない技術を選んでしまうことがあります。Bisbal et al.（1999）は、こうして生まれる「レガシーシステム」が、保守できる人材の減少と技術の陳腐化によって組織の変化を妨げる構造を整理しました。米国の会計検査院は、連邦政府の基幹システムの多くが数十年前の言語で書かれ、保守できる技術者の退職が差し迫ったリスクになっていると報告しています（U.S. Government Accountability Office, 2016）。例えば、特定の開発言語に精通した責任者の判断でその言語を採用したものの、その人物の退職後に後任を採用できず、保守が止まった、という事例です。

工程4：テスト・移行・稼働

• テストとデータ移行の軽視：負荷テスト、業務シナリオに基づく受け入れテスト、旧システムからのデータ移行の検証が、納期の圧力によって圧縮されることです。Healthcare.govでは負荷テストが本番直前まで実施されず、Hertzではモバイル対応のテスト不足が争点となりました。例えば、公開初日に想定の10倍のアクセスが集中することは事前に予測できたにもかかわらず、その負荷でのテストが公開1週間前に初めて行われ、問題が見つかっても修正が間に合わなかった、という経緯です。

• 一斉切り替えのリスク：旧システムから新システムへ一度に切り替える方式は、問題が発生した際の影響範囲が最大になります（Markus & Tanis, 2000）。自社開発では「並行稼働のための二重の運用コストを払いたくない」という判断から一斉切り替えが選ばれやすくなります。例えば、英国のTSB銀行は2018年4月の週末に顧客口座を新しい勘定系基盤へ一斉に移行しましたが、翌週から約190万人の顧客がオンラインバンキングを利用できなくなり、復旧費用と顧客補償で約3億3,000万ポンドの損失を計上しました。独立調査は、移行前のテストが不十分なまま一斉切り替えを決断したことを主因として指摘しています（Slaughter and May, 2019）。

• エスカレーション：止められない：Keil（1995）は、失敗が明らかになりつつあるITプロジェクトが継続・追加投資されてしまう現象を「エスカレーション」として分析しました。すでに投じた費用への執着、責任者の面目、「あと少しで完成する」という認識のずれが、撤退判断を遅らせます。自社開発は撤退がすなわち投資の全損を意味しやすいため、エスカレーションが長期化します。例えば、NHSのNPfITは、開始から数年の時点で主要な開発企業が撤退し、現場の採用が進まないことが明らかになっていましたが、「すでに数十億ポンドを投じている」という理由で解体の判断が2011年まで先送りされました。

工程5：運用・保守・進化

• 保守コストの過小評価：Lientz & Swanson（1980）の古典的な調査以来、ソフトウェアのライフサイクルコストのうち保守・運用が占める割合は半分以上であることが繰り返し確認されており、Erlikh（2000）は企業システムでは85〜90%に達すると推計しています。「開発費」を基準に自社開発と既存製品を比較することは、費用の大半を無視した比較になります。例えば、開発費1億円のシステムは、10年間の保守・改修・基盤更新で追加の2〜5億円を要することが一般的であり、既存製品の10年分の利用料と比較すると数十倍以上大きくなることが一般的です。

• 継続的な変更と基盤技術の世代交代：Lehman（1980）が定式化した「ソフトウェア進化の法則」は、実際に使われるプログラムは継続的に変更されなければ満足度が低下し、変更を続けるほど複雑性が増大することを示しています。加えて、OSやブラウザの更新、セキュリティ脆弱性への対応、法令改正への追随、クラウド化やAPI化といった基盤技術の世代交代が、価値を維持するための「防衛的な保守」として継続的に発生します。例えば、2010年代前半に構築したシステムの多くは、ブラウザの仕様変更、サーバーOSのサポート終了、暗号化方式の更新のたびに改修を迫られ、「機能は何も変わっていないのに、維持するだけで毎年費用がかかる」状態になっています。

• 人材の流出と知識の属人化：独自システムの知識は、それを作った人材に蓄積されます。Rigby et al.（2016）は、開発者の離職によってソフトウェアの知識が失われる度合いを定量化し、特定の人物しか理解していないコードの割合が離職後の保守リスクを決めることを示しました。担当者の異動や退職によって「誰も中身を理解していないシステム」が生まれることは、多くの企業に共通する現象です。既存製品では標準機能に関する知識が市場で流通しているため、人材の入れ替えに対する耐性が高くなります。例えば、設計書が更新されないまま10年間改修が重ねられたシステムで、唯一全体を理解していた担当者が退職し、以後は「触ると壊れるので誰も触らない」システムになった、という事例です。

• 組織変革の遅れと定着の失敗：既存製品と同様に、システムが稼働しても業務プロセスと組織が変わらなければ効果は現れません（Aral & Weill, 2007）。自社開発では「現行業務をそのまま再現する」要件になりやすいため、業務改善の機会そのものを逃すことがあります。Hammer（1990）は、既存の業務手順をそのまま自動化することを「牛の通り道を舗装する」と呼び、効果を生まない典型として批判しました。例えば、紙の申請書をそのまま画面にしたシステムは、入力の手間を減らすどころか、紙に記入してからシステムにも入力する二度手間を生みます。

既存製品導入と自社開発の失敗要因の相違点

共通点

• 判断の起点である「導入形態の誤判断」は、どちらにも共通する：差別化の核を既存製品で済ませる誤りと、差別化しない業務を自社で作る誤りは、同じ判断軸（差別化・資産特殊性・市場成熟度）を欠いたことから生じます。例えば、「他社が自社開発しているから」「他社がこの製品を使っているから」という横並びの判断は、どちらの方向にも誤ります。

• 補完的投資の軽視と組織変革の遅れは、技術ではなく組織の問題であり、どちらの形態でも起きる：Brynjolfsson et al.（2021）のJカーブとAral & Weill（2007）の組織ケイパビリティの研究が示すように、システムの価値は業務プロセスと人材の変化によって生まれます。例えば、新しいシステムの稼働後に業務手順書を更新せず、研修も行わなかった企業は、既存製品でも自社開発でも「使われないシステム」を抱えます。

• 発注側・業務側のケイパビリティの不足は、どちらの形態でも致命的になる：要件を定義し、成果物を評価し、ベンダーや開発チームを統制する能力は、外部に委ねられません。例えば、情報システム部門を極端に縮小した企業は、既存製品の選定でも自社開発の委託でも、相手の提案の妥当性を判断できなくなります。

• テストの規律と切り替え方法の失敗は、どちらの形態でも同じ形で現れる：負荷テストの省略、データ移行の検証不足、一斉切り替えは、製品の出自に関係なく障害を引き起こします。例えば、Hershey（既存製品）とHealthcare.gov（自社開発）は、形態は異なりますが「本番直前までテストが行われず、一斉に稼働した」という点で同じ失敗です。

異なる点

• 自社開発に固有の失敗は、規模・期間・自社固有コードの量に比例して増大する：計画錯誤、連鎖的な遅延、技術的負債、保守コスト、人材の属人化は、いずれも「自社が抱える独自コードの量」と「プロジェクトの規模・期間」の関数です（Flyvbjerg et al., 2022; Lientz & Swanson, 1980）。例えば、同じ「販売管理」でも、既存製品を設定して3か月で稼働させた場合と、2年かけて独自開発した場合では、後者は要件の変化・人員の入れ替わり・技術の陳腐化に晒される期間が8倍になります。

• 既存製品導入に固有の失敗は、選定段階の評価と、カスタマイズの深さに集中している：製品と自社業務のミスフィットの見落としとベンダー評価の不足は工程2で、過剰なカスタマイズは工程3で、ロックインは工程5で現れますが、根はすべて「製品を標準のまま使うか、作り込むか」の判断にあります（Soh et al., 2000; Brehm et al., 2001）。深いカスタマイズを選んだ瞬間に、自社開発に固有の要因も同時に抱え込むことになります。例えば、Lidlは既存製品を導入したはずでしたが、7年間・5億ユーロという規模と期間は、大規模な自社開発と同じリスク構造を持っていました（Handelsblatt, 2018）。

• 失敗したときの損失の大きさは自社開発の方が大きい：既存製品は契約の解除や乗り換えという撤退経路があるため、失敗の損失は「それまでの利用料と移行費用」に限定されやすいのに対し、自社開発の失敗は投資の全損になりやすく、Keil（1995）が示したエスカレーションも長期化します。例えば、SaaSの導入失敗は数千万円の損失で済むことが多い一方、NHSのNPfITは約100億ポンドの大半が回収できませんでした。

• 保守と進化の責任の所在が異なる：既存製品ではセキュリティ対応・法令改正対応・基盤技術の世代交代をベンダーが全顧客に対してまとめて行うのに対し、自社開発ではすべて自社が担います（Lehman, 1980; Erlikh, 2000）。例えば、消費税率や社会保険料率の改定は、既存製品であればベンダーのアップデートで吸収されますが、自社開発では毎回自社の改修になります。

既存製品導入と自社開発の対象となる業務

これまでの整理から、失敗を避ける鍵は「どの業務を既存製品で、どの業務を自社開発で導入するか」の判断にあることがわかります。この判断は「システム全体」ではなく「業務単位」で行う必要があります。

既存製品導入と自社開発を分ける判断軸

既存製品導入が適切な業務と自社開発が適切な業務を判断するには、経営学で蓄積してきた４つの理論を踏まえて検討することができます。

• 差別化の軸（資源ベース理論）：Barney（1991）は、持続的な競争優位は、価値があり（Valuable）、希少で（Rare）、模倣困難で（Inimitable）、組織的に活用されている（Organized）資源からのみ生まれると論じました。市場で誰でも買える製品は、定義上、希少でも模倣困難でもありません。この業務を独自の方法で行うことが顧客から見た優位につながる場合にのみ、自社開発が候補になります。例えば、Walmartの補充精度やZaraの商品回転の速さは顧客が同社を選ぶ理由そのものであり、それを支えるシステムは差別化の軸を満たします。

• 資産特殊性の軸（取引コスト理論）：Williamson（1985）は、内製が有利になる条件として、取引相手を替えられない「資産特殊性」が高いこと、将来の要件が読めない「不確実性」が高いこと、取引の「頻度」が高いことの3つを挙げました。Nelson et al.（1996）はこれをソフトウェア調達に適用し、「業務の独自性」と「要件の不確実性」の2軸で、パッケージ購入・カスタム開発・自社開発の適否を整理しています。例えば、給与計算は法令で手順が決まっており同業他社と本質的に同じであるため資産特殊性は低く、既存製品が適します。

• 市場成熟度の軸（コモディティ化の理論）：Carr（2003）は、ITも電力や鉄道と同様に普及とともにコモディティ化し、それ自体では競争優位を生まなくなると論じました。Wardley（2020）は、あらゆる技術や活動が「創発→独自構築→製品→コモディティ」という段階を経て進化することを示し、段階ごとに適切な調達方法が異なることを指摘しています。創発段階のものは自社で試行するしかありませんが、製品段階に入れば購入が、コモディティ段階に入れば従量課金の利用が合理的になります。例えば、2000年代初頭には自社でサーバーを持つしかなかったコンピューティング基盤は、現在ではクラウドというコモディティになっており、Netflixのように自社データセンターを閉鎖する判断が合理的になりました。

• 変化速度の軸：業務を規定する要件（法規制、技術標準、顧客の期待）の変化が速い領域では、追随コストを外部化できる既存製品の優位が大きくなります。変化がほとんどなく安定した業務であれば、内製の保守負担は相対的に軽くなります（Nelson et al., 1996; Lehman, 1980）。例えば、電子帳簿保存やインボイス制度のように制度改正が続く領域では、ベンダーが全顧客分の改修をまとめて行う既存製品の方が、自社で毎回改修するより圧倒的に効率的です。

既存製品導入が適切な業務

• 標準的な間接業務：差別化の軸・資産特殊性の軸・市場成熟度の軸の3つが一致して「既存製品」を示す領域です。多くの企業において、業務の8〜9割はここに該当します（Carr, 2003; Quinn & Hilmer, 1994）。例えば、会計、給与計算、経費精算、人事管理、勤怠管理、電子メール、ファイル共有、ウェブ会議などは、同業他社と異なるやり方をしても顧客は評価せず、成熟した製品市場があり、法令改正への追随が頻繁に必要です。

• 業界共通の業務：業界内で手順が概ね共通しており、業界向けの製品が複数存在する業務です（Davenport, 1998）。例えば、顧客管理、在庫管理、購買、プロジェクト管理、カスタマーサポートの問い合わせ管理などは、自社固有に見えても、同業他社と本質的に同じ業務であることがほとんどです。

• 自社固有に見えるが、差別化にはつながらない業務：「自社のやり方」が存在するものの、そのやり方自体が顧客から選ばれる理由になっていない業務です。この場合、製品を作り込むのではなく、業務を製品の標準に合わせるか、固有部分だけをL3で外付けします（Soh et al., 2000; Brehm et al., 2001）。例えば、独自の承認フロー、社内報告書の書式、部門ごとに異なる経費の科目体系などは、多くの場合、歴史的経緯で残っているだけであり、標準に合わせても事業への影響はありません。

• 複数の製品をつなぐ業務フロー：業務そのものは標準的でも、複数の製品にまたがるデータの受け渡しが自社固有である場合です。例えば、受注システムで受けた注文を在庫システムで引き当て、会計システムで請求するという一連の流れは、各製品は既存製品を使いつつ、製品間の連携をAPIやローコードツールで構成するのが適切です（Hasselbring, 2000）。

• 変化が速く、追随コストが大きい業務：法令・制度・技術標準の変更が頻繁な業務は、変化速度の軸から既存製品が強く推奨されます（Nelson et al., 1996）。例えば、税務申告、電子契約、個人情報保護やセキュリティに関する認証対応は、制度の改定ごとにベンダーがまとめて対応する方が、自社で追い続けるより確実です。

• コモディティ化したインフラ：市場成熟度の軸でコモディティ段階にある領域は、所有せず利用する形態が合理的です（Carr, 2003; Wardley, 2020）。例えば、サーバー、ストレージ、データベース、認証基盤、メール配信基盤などは、NetflixやCapital Oneの事例が示すように、規制産業や大規模企業であっても外部のクラウドを利用する判断が主流になっています（Netflix, 2016; Capital One, 2020）。

自社開発が適切な業務

• 差別化の核であり、市場に製品が存在しない業務：4つの軸のうち差別化と資産特殊性が高く、市場成熟度が創発・独自構築段階にある業務です。Bessen（2022）が示したように、独自ソフトウェアは大企業の競争優位の源泉になっていますが、それは業務そのものが差別化の源泉であり、それを支えるソフトウェアが市場に存在せず、開発と継続的な改良を支える組織能力と資本を持つ、という条件がそろった場合です。例えば、WalmartのRetail Link、Zaraの生産計画システム、Amazonの物流・推薦システムは、構築当時、同じことができる製品が市場に存在しませんでした。

• 独自データを活かす分析・判断の仕組み：自社だけが持つデータ（顧客の行動履歴、長年の取引記録、独自の計測データなど）を使い、その活用方法が競争優位につながる領域です。Teece（1986）の補完資産の理論が示すように、価値はシステムそのものではなく、データという補完資産に宿ります。例えば、保険会社が数十年分の事故データから独自の料率算定モデルを構築する場合、モデルの構築基盤は既存のクラウドやライブラリを使いつつ、算定ロジックそのものは自社で開発します。

• 差別化の核だが、製品が存在する領域の「自社固有部分」：業務の大半は既存製品で処理できるが、競争優位につながる一部のロジックだけが自社固有である場合です。この場合、製品を改変するのではなく、固有部分を独立したシステムとして自社開発し、製品とAPIで疎結合につなぎます。Baldwin & Clark（2000）が示したように、標準化されたインターフェースで切り分けられたモジュールは独立して進化でき、Christensen & Raynor（2003）は、コモディティ化した層の隣接層に利益が移ることを指摘しています。例えば、ECサイトの基盤は既存製品を使いながら、自社の競争優位となる価格設定のアルゴリズムや推薦ロジックだけを自社で開発し、APIで製品に組み込む構成です。

• 事業そのものがソフトウェアである場合：提供するサービスの中核がソフトウェアである企業にとって、そのソフトウェアは定義上、差別化の核です（Andreessen, 2011）。例えば、Netflixにとっての配信・推薦システム、Amazonにとっての購買体験は、既存製品で代替すれば事業そのものが成り立ちません。ただし、こうした企業であっても、会計・人事・インフラなどの周辺業務は既存製品を使っています。

自社開発をする場合の前提条件

自社開発をする場合は、前提条件として次の3条件がそろっている必要があります。

• 対象業務が競争優位を生むこと：その業務を独自のやり方で行うことが、顧客が自社を選ぶ理由に直接つながっていることです。Barney（1991）の資源ベース理論によれば、持続的な競争優位を生む資源は「価値があり、希少で、模倣困難で、組織的に活用されている」ものに限られ、市場で誰でも買える製品でまかなえる業務は定義上この条件を満たしません。Quinn & Hilmer（1994）は、自社が世界最高水準になれる活動だけを内部に残すべきだと論じ、Moore（2005）は、業務を「顧客が自社を選ぶ理由になるコア」と「必要だが競合と同じやり方でよいコンテキスト」に分け、コアは時間とともにコンテキストへ移っていくと指摘しています。ここで重要なのは、判定を現場の「うちの業務は特殊だ」という主張ではなく、顧客の視点で行うことです。Soh et al.（2000）が示したように、現場が「特殊」と感じる業務の多くは、歴史的経緯で残った手順にすぎず、顧客にとっての価値とは無関係です。例えば、Walmartの補充精度やZaraの商品回転の速さは、顧客が店を選ぶ理由そのものであり、それを支えるシステムはこの条件を満たしました（Bessen, 2022; Ferdows et al., 2004）。一方、「当社の承認フローは5段階で特殊だ」という主張は、顧客にとって何の価値も生まないため、この条件を満たしません。

• 市場に適切な製品が存在しないこと：市場に適切な製品が存在しないことを「思い込み」ではなく「調査」で確認したうえで選ぶべきものです。Wardley（2020）が示したように、あらゆる技術は「創発→独自構築→製品→コモディティ」と進化し、製品段階に達した領域で独自構築を続けることは、費用とリスクだけを増やします（Carr, 2003）。Nelson et al.（1996）の枠組みでも、自社開発が合理的になるのは「業務の独自性が高く、かつ市場に適合する製品がない」場合に限られます。したがって、着手前に、対象業務を扱う製品が複数のベンダーから提供されているか、その製品を標準のまま、あるいは設定と連携の範囲で自社の業務に適用できるかを、実際に試用して確認する必要があります。例えば、Walmartが1991年にRetail Linkを自社開発したのは、取引先と販売データをリアルタイムで共有する製品が当時市場に存在しなかったからです（Bessen, 2022）。逆に、2023年に「製品がない」という理由で自社開発された社内文書の検索・要約の仕組みの多くは、2025年には複数の特化型製品が同等以上の機能を提供するようになっており（Menlo Ventures, 2025）、この条件は一度確認すれば終わりではなく、定期的に再確認が必要です。

• 改良・保守の人材・予算・組織があること：自社開発は「作って終わり」ではなく、構築後5年、10年にわたって改良と保守を続ける体制を持てるかが問われます。Lientz & Swanson（1980）以来、ソフトウェアのライフサイクルコストの過半は稼働後の保守・運用に費やされることが繰り返し確認されており、Erlikh（2000）は企業システムでは85〜90%に達すると推計しています。つまり、自社開発を選ぶとは、開発費の数倍の保守費（既存製品の数十倍以上のコスト）を将来にわたって負担すると決めることです。この体制には3つの要素が必要です。第一に人材です。Rigby et al.（2016）が示したように、独自システムの知識は作った人に集中するため、主要な開発者が離職しても引き継げる複数名の体制と文書化が前提になります。第二に予算です。Boehm（1981）の経験則では年間保守費は開発費の15〜20%程度に達し、これに基盤技術の世代交代に伴う刷新費（Lehman, 1980）が加わります。第三に組織です。Feeny & Willcocks（1998）は、システムを事業に活かし続けるには、事業と技術をつなぐ思考、設計の統制、ベンダーや開発チームの管理といった中核能力を社内に保持する必要があると論じ、Aral & Weill（2007）は、IT投資の成果が投資額ではなくこうした組織のケイパビリティで決まることを実証しています。Bessen（2022）が示した「独自ソフトウェアで競争優位を築いた企業」も、例外なく大規模な技術組織と継続的な投資を伴っていました。例えば、JPMorgan Chaseが自社開発を選べたのは、規制上の制約と独自データという差別化の核があったことに加え、年間数十億ドルの技術予算と数万人規模の技術者を抱えていたからです（JPMorgan Chase, 2025）。逆に、開発者が2〜3名しかいない組織が自社開発を選ぶと、その数名の離職がそのままシステムの寿命になります。

汎用AI、特化型AIエージェント、自社開発の対象となる業務

ここではAIに着目し、既存製品を汎用AIと特化型AIエージェントに分け、自社開発も含め３つの選択肢がどのような業務を対象とすることが適切なのか整理します。前章の4つの判断軸はAIにもそのまま適用できますが、AIには従来のソフトウェアと異なる性質があるため、まず「そもそもAIの導入が適切な業務は何か」から確認します。

AI導入が適切な業務

AIは従来のシステムと異なり、業務横断的に関わり、出力が確率的で、能力の境界が事前に予測しにくいという性質を持ちます。したがって「AIを導入するか」の前に、「この業務はAIに向いているか」を業務単位で判断する必要があります。

• 業務の大半が言語・文書・画像の処理と判断で構成されている：Eloundou et al.（2023）は、米国の労働者の約80%が業務タスクの少なくとも10%に、約19%が業務の半分以上に大規模言語モデルの影響を受けると推計しました。影響が大きいのは、文書の読解・作成・要約・分類・照合といった、情報を扱う業務です。例えば、契約書のレビュー、問い合わせへの回答、申請書類と基準との照合、コードの作成といった業務は該当しますが、現場での物理的な作業や対面での交渉はこの条件を満たしません。

• 出力の正誤を確認する手段がある：AIは同じ入力に異なる出力を返し、誤りを含むことがあります。したがって、出力が正しいかどうかを人間または別の仕組みで検証できる業務が適しています（NIST, 2023）。例えば、法令の条文と図面を照合する審査業務では、AIが指摘した根拠条文を審査者が確認できるため適していますが、正解が存在せず、後からも検証できない予測となる業務はAIの誤りが見過ごされやすくなります。

• AIの能力の境界の内側にある：Dell’Acqua et al.（2023）は、コンサルティング会社の758人を対象とした実験で、AIが得意なタスクでは生産性が大幅に向上する一方、一見似ているが境界の外側にあるタスクでは、AIを使った方がむしろ正答率が19ポイント低下することを示しました。この「ギザギザの境界（jagged frontier）」は、適用範囲を実際に試さなければ確定できないことを意味します。例えば、同じ「文書の要約」でも、一般的な報告書の要約は境界の内側にあり、複数の資料を突き合わせて矛盾を見つける作業は境界の外側にあることがあります。導入前に自社の実際の業務データで小規模に試すことが不可欠です。

• 担当者の熟練度にばらつきがあり、底上げの余地が大きい：Brynjolfsson et al.（2025）は、顧客サポート部門へのAI導入によって1時間あたりの解決件数が平均14%増加し、経験の浅い担当者では34%増加した一方、熟練者ではほとんど効果がなかったことを示しました。AIの効果は「組織の平均を熟練者の水準に近づける」形で現れます。例えば、新人が多く入れ替わりの激しいコールセンターや、経験の浅い担当者が複雑な基準を参照しなければならない審査業務では効果が大きく、少数の熟練者だけで回っている業務では効果は限定的です。

• 誤りが生じた場合の責任と是正の仕組みを設計できる：Moffatt v. Air Canada（2024）の裁定が示したように、企業はAIの出力に対して従業員と同じ責任を負います。したがって、誤りを検知し、是正し、責任を負う仕組みを設計できる業務であることが条件になります。例えば、社内向けの文書作成支援は誤りがあっても社内で修正できますが、顧客に直接回答するチャットボットは、誤った案内がそのまま法的責任になります。

• 頻度が高く、1件あたりの処理が定型的である：AIの導入には評価データの整備や業務への組み込みという固定的な初期投資が必要なため、処理件数が多い業務ほど投資を回収しやすくなります。例えば、月に数千件の問い合わせ対応や数百件の書類審査は適していますが、年に数件しか発生しない特殊な案件は、人間が対応する方が合理的です。

汎用AIと特化型AIエージェントの違い

そもそも汎用AIと特化型AIエージェントは何が違うのでしょうか。両者は「対象とする市場」「提供する価値」「組み込まれている知識」「利用の単位」「課金の考え方」の5つの観点で区別できます。

• 対象とする市場が異なる：汎用AIを提供するOpenAI、Anthropic、Google（Gemini）などは、「グローバルな知識労働の代替・増強」を枠組みとし、世界の知識労働の人件費（約25兆ドル）全体を対象市場と位置づけています。一方、特化型AIエージェントは、特定業界の人件費支出を対象市場と再定義しています。例えば、法務のHarveyは「法務サービス市場1兆ドル（従来のソフトウェア支出は約400億ドル）」を、カスタマーサービスのSierraは「カスタマーサービス支出400億ドル」を対象市場としています（Taima, 2026）。

• 提供する価値が「増強」か「業務の代替」かで異なる：汎用AIは、従業員一人ひとりの作業を補助し、生産性を高める「増強」を提供します。特化型AIエージェントは、特定の業務プロセスそのものを引き受ける「代替」を目指しており、Sequoia Capitalはこれを「ソフトウェアを売るのではなく、仕事そのものを売る」という意味で「Service-as-a-Software」と呼んでいます。例えば、汎用AIは弁護士が契約書を読む速度を上げますが、特化型AIエージェントは契約書のレビューという業務を一次的に実行し、弁護士は結果を確認する役割に移ります。

• 組み込まれている知識とワークフローが異なる：汎用AIが提供するのは基盤モデルの能力そのものであり、業務固有の知識・手順・判断基準は利用者が与える必要があります。特化型AIエージェントは、基盤モデルの上に、その業界の知識ベース、専門家による評価データ、業務の手順、規制への対応、既存の業務システムとの連携を製品として組み込んでいます。例えば、建築確認審査の特化型製品であれば、建築基準法令の体系、図面の読み取り方、審査機関ごとの運用、審査記録の様式が製品に組み込まれており、利用者がこれらを一から教える必要はありません。

• 利用の単位が「個人」か「業務プロセス」かで異なる：汎用AIは個人が対話形式で使う道具であり、組織の業務プロセスの外側にあります。特化型AIエージェントは業務プロセスの中に組み込まれ、業務システムとデータをやり取りしながら動作します。例えば、汎用AIで作成した文書は担当者が手作業で業務システムに転記しますが、特化型AIエージェントは審査システムや顧客管理システムから直接データを受け取り、結果を書き戻します。

• 課金の考え方が異なる：汎用AIは利用者数（席数）に応じた課金が中心であるのに対し、特化型AIエージェントは処理した業務量や成果に応じた課金に移行しつつあります。これは、特化型が「人件費予算」を獲得対象としていることの反映です。例えば、カスタマーサービスの特化型製品では「解決した問い合わせ1件あたり」の課金が採用されています。

• 両者の市場の現在地：特化型AIエージェント企業の売上は急速に伸びているものの、対象市場に対する達成度はまだごくわずかです。例えば、Cursor（ソフトウェア開発）は年換算売上20億ドルで対象市場の約0.13%、Harvey（法務）は1.9億ドルで約0.02%、Sierra（カスタマーサービス）は1.5億ドル超で約0.04%、OpenEvidence（医療）は1億ドル超で約0.4〜0.5%にとどまります。特化型AIエージェントは「市場の入口の入口」にあり、今後とも大きく拡大していくことが想定されています。

汎用AIが適切な業務

カスタマイズしない場合

ChatGPT、Microsoft Copilot、Claude、Geminiなどの、特定の業務に限定されない対話型AI製品を、そのまま利用する形態です。従業員が個人の生産性向上のために利用する形態が中心です（Bommasani et al., 2021）。

• 文書の下書きと推敲：メール、報告書、提案書などの文章を書き始める作業と、書いた文章を整える作業です。Noy & Zhang（2023）は、文書作成業務にChatGPTを用いた実験で、作業時間が約40%短縮し、成果物の品質も向上したことを示しました。例えば、顧客への英文メールの下書きや、社内報告書の文章の推敲は、業界や職種を問わず効果が確認されている用途です。

• 要約と情報の整理：長い文書や会議の内容から要点を抽出し、構造化する作業です。Dell’Acqua et al.（2023）は、コンサルタント758人を対象とした実験で、アイデア出し・文章作成・分析といったAIの得意領域のタスクでは、完了数が12%増え、所要時間が25%短縮し、品質が40%向上したことを示しました。例えば、会議の録音から議事録を作成する、数十ページの資料の要点を1ページにまとめる、といった作業です。

• 翻訳と多言語対応：他言語の文書の読解と、自分の文章の他言語への変換です。Eloundou et al.（2023）は、翻訳や文章作成を含む言語処理中心の職務が、大規模言語モデルの影響を最も強く受ける領域であると推計しています。例えば、海外の取引先からの契約書案を読む、多言語の顧客向け案内文を作る、といった作業です。

• コードの作成補助：プログラムや表計算の関数、スクリプトを書く作業の補助です。Peng et al.（2023）は、GitHub Copilotを使った開発者が、使わなかった開発者より55.8%速く課題を完了したことを対照実験で示しました。例えば、表計算の複雑な関数の作成、データ集計スクリプトの作成、既存コードの解説などです。

• 構成案やアイデアの生成：資料の構成、企画の選択肢、問いかけの切り口など、考え始めるための材料を出す作業です。Dell’Acqua et al.（2023）の実験でも、新製品のアイデア出しや市場セグメントの提案といった創造的なタスクはAIの得意領域の内側にありました。例えば、プレゼン資料の構成案を複数パターン出す、ワークショップの論点を洗い出す、といった作業です。

• 定型的な顧客対応の回答案：よくある問い合わせへの回答文を作る作業です。Brynjolfsson et al.（2025）は、顧客サポート部門へのAI導入で1時間あたりの解決件数が平均14%、経験の浅い担当者では34%増加したことを示しました。例えば、返品方法や営業時間といった定型の問い合わせへの回答案を作り、担当者が確認して送る、という使い方です。

これらに共通するのは、業務横断的で、個人単位で完結し、結果を本人がその場で確認できるタスクであることです。一方で限界もあり、MIT NANDA（2025）が「学習ギャップ」と呼んだように、汎用AI製品は業務の文脈を記憶せず、フィードバックから学習せず、自社の業務フローに適応しないため、複雑で継続的な業務では使われなくなります（単純なタスクでは70%がAIを選ぶ一方、複雑で長期的な業務では90%が人間を選ぶという結果です）。また、従業員が個人契約の製品を業務に使う「シャドーAI」は、機密情報の外部送信や責任の所在といった統制上の課題を生むため、禁止ではなく公式導入と利用ルールの整備で対処する必要があります（MIT NANDA, 2025; Haag & Eckhardt, 2017）。

カスタマイズする場合

汎用AI製品に対して、自社の指示文（システムプロンプト）、参照させる社内文書、呼び出せる社内システムの機能を設定し、特定の用途向けの「社内アシスタント」として構成する形態です。ChatGPTのGPTs（OpenAI, 2023）、ClaudeのProjects（Anthropic, 2024）、Microsoft Copilot Studio（Microsoft, 2023）のように、製品側が用意した設定機能を使うもので、コードを書かずに構成できます。

• 社内知識を参照した一次回答：社内規程、マニュアル、過去のQ&Aなど、文書として存在する知識を参照して質問に答える業務です。外部文書を検索して回答に反映する「検索拡張生成（RAG）」として研究が進んでおり（Lewis et al., 2020）、製品側の設定機能で実現できます。例えば、情報システム部門への「VPNの設定方法」、人事部門への「育児休業の申請手順」といった定型的な問い合わせの一次回答です。

• 自社の様式・口調に沿った文書の生成：汎用AIの出力を、自社の書式や表現の基準に合わせる業務です。Noy & Zhang（2023）が示した文書作成の効率化効果は、見本と指示を設定して自社の基準に沿わせることで、個人差なく組織全体で再現できます。例えば、顧客向けメールの文面を自社のトーンに統一する、報告書を所定の見出し構成に整える、といった作業です。

• 受信文書の分類と振り分け：問い合わせや申請を内容に応じて分類し、担当部署や優先度を判定する業務です。Brynjolfsson et al.（2018）は、入出力が明確で頻度が高いタスクほど機械学習に適すると整理しており、分類はその典型です。例えば、問い合わせフォームの内容を「請求」「技術」「解約」に分類し、担当者に振り分ける、という作業です。

• 複数の既存ツールにまたがる個人作業の自動化：カレンダー、メール、文書、表計算といった汎用的な業務ツールを横断する作業です。Microsoft（2023）のCopilot Studioのように、製品側が業務ツールとの連携機能を提供しています。例えば、会議の録音から議事録を作成し、決定事項をタスク管理ツールに登録し、関係者にメールの下書きを用意する、という一連の作業です。

• 新任者の立ち上がり支援：業務の手順や社内用語を、経験の浅い担当者が自分で調べられるようにする用途です。Brynjolfsson et al.（2025）は、AIの効果が経験の浅い担当者で最も大きい（34%の生産性向上）ことを示しており、社内知識を参照させたアシスタントはこの効果を狙うものです。例えば、新入社員が「この申請は誰の承認が必要か」を社内規程から即座に確認できるようにする、という使い方です。

限界はあり、この方法で埋められるのは「知識の参照」までであり、「業務の実行」ではありません。業務システムの中でデータを受け取り、判断し、結果を書き戻すという業務プロセスへの組み込みには向いていません（MIT NANDA, 2025）。例えば、審査基準の文書を参照させれば「この条文はどう解釈するか」には答えられますが、申請された図面を読み取り、該当条文と照合し、審査記録を作成するという業務そのものは実行できません。また、設定した指示文や参照文書の品質、回答の正確さの検証、文書の更新は自社の責任であり、参照文書が古いままだと誤った回答が続き、基盤モデルの更新で振る舞いが変わることもあります（Gao et al., 2023; NIST, 2023）。したがって汎用AIのカスタマイズは「社内文書を参照する一次回答」と「個人作業の効率化」までを対象とし、業務プロセスへの組み込みが必要になった段階で特化型製品か自社開発に移行するのが合理的です。

特化型AIエージェントが適切な業務

カスタマイズしない場合

法務文書のレビュー、医療記録の作成支援、建築確認審査、カスタマーサポート、経理処理など、特定の業務領域に特化して設計されたAI製品を、標準の機能と手順のまま利用する形態です。基盤モデルの上に、その業務領域の知識・データ・ワークフロー・評価基準・規制対応を組み込んでおり、業務システムとの連携を前提とします。

• 法務文書のレビューと契約分析：契約書の条項チェック、判例・法令の調査、文書の作成支援です。Menlo Ventures（2025）によれば、法務は医療に次いで垂直型AIへの支出が大きい領域（6.5億ドル）であり、Harveyのような特化型製品は判例・法令・契約書の体系を製品に組み込んでいます。例えば、取引契約の条項を自社の標準条項と照合し、逸脱箇所と根拠を提示する、という業務です。

• 医療記録の作成と診療情報の参照：診察内容の記録、医学文献やガイドラインの参照です。Menlo Ventures（2025）では医療が垂直型AI支出の最大領域（15億ドル）であり、OpenEvidenceのような製品は医学文献と診療ガイドラインを組み込んでいます。例えば、診察の会話から診療記録の下書きを作成し、医師が確認して確定する、という業務です。

• カスタマーサポートの一次対応と処理の実行：問い合わせの受付から、顧客情報の参照、返金や予約変更といった処理の実行、記録までを一つの流れとして行う業務です。Sierraのような製品は、この流れ全体を顧客管理システムと連携した形で提供しています。Brynjolfsson et al.（2025）が示した顧客サポートでの生産性向上も、業務システムに組み込まれたAIによるものでした。例えば、配送状況の問い合わせに対して、注文管理システムの実データを参照して回答し、必要なら再配送の手配まで行う、という業務です。

• ソフトウェア開発の支援と自動化：コードの作成、修正、レビュー、テストです。Peng et al.（2023）が示した55.8%の高速化に加え、Cursorのような開発特化型の製品はコードベース全体を理解した補完や複数ファイルの編集を提供し、特化型AI製品の中で最も売上が大きい領域になっています。例えば、既存のコードベースを理解したうえで新機能を実装し、テストを生成する、という業務です。

• 法規制や基準に基づく審査・照合：申請書類や図面を法令・基準と照合し、適合性を判定する業務です。Eloundou et al.（2023）は、規則に基づく文書の確認・照合を含む業務が大規模言語モデルの影響を強く受ける領域であることを示し、こうした領域では法令の体系、文書や図面の読み取り方、機関ごとの運用を製品に組み込んだ特化型製品が登場しています。例えば、建築確認審査において、提出された図面と建築基準法令を照合し、該当条文を根拠として指摘事項の案を作成する、という業務です。

• 経理・バックオフィスの定型処理：請求書の処理、仕訳、経費の確認、各種申請の処理です。MIT NANDA（2025）は、注目を集めるのは営業・マーケティング領域だが、実際に最大の効果が出ているのはバックオフィスであり、外部委託費や代理店費の削減として年間数百万ドル規模の効果を生んだ事例を報告しています。例えば、受領した請求書を読み取り、発注データと照合し、会計システムに仕訳を起票する、という業務です。

これらに共通するのは、専門知識・法規制・業界固有のデータ形式が業務を規定しており、基盤モデルの汎用的な能力だけでは実務水準に届かない領域であること（Dell’Acqua et al., 2023）、そして業界内で手順と判断基準が概ね共有されており、標準の製品で高い適合度が得られることです（Davenport, 1998; Soh et al., 2000）。MIT NANDA（2025）が成功企業の特徴として挙げた「業務に深く統合され、時間とともに学習するツール」は、特化型製品が提供しようとしているものです。例えば、Morgan Stanleyは、OpenAIとの提携により自社の10万件以上の調査レポートをもとにファイナンシャルアドバイザー向けの検索・要約システムを構築しましたが、これはモデル層を外部から調達し、データ層を自社が保有し、ワークフロー層をベンダーと共同で構築した「ベンダーとの共同開発」の良い事例です（Morgan Stanley, 2023）。

カスタマイズする場合

特化型製品が用意している設定の範囲で、自社の判断基準・手順・様式・承認フローを反映し、自社の業務システムとAPIで接続する形態です。設定や連携に留め、製品本体の改変には踏み込まないという原則は従来のソフトウェアと変わりません（Brehm et al., 2001）。

• 組織ごとの判断基準・様式の反映：判断の根拠（法令・基準・ガイドライン）は業界で共通でも、組織ごとに重点の置き方、記録の様式、指摘の表現が異なる業務です。Strong & Volkoff（2010）は、組織とシステムの不一致を機能・データ・利用性・役割・統制・組織文化の6種類に整理し、設定で吸収すべきものと業務側を変えるべきものを区別する必要性を示しています。

• 既存の業務システムとの連携：特化型製品を既存の受付システム、顧客管理システム、文書管理システム、会計システムとつなぎ、人手による転記をなくす業務です。Hasselbring（2000）が示したように、連携は個別の接続を積み重ねるのではなく、製品が提供する標準の接続機能（API）の範囲で構成することが保守性の条件になります。例えば、カスタマーサービスの特化型製品を自社の注文管理システムと接続し、返品や配送状況の問い合わせにAIが実データを参照して回答できるようにする、という構成です。

• 人の確認ポイントと承認フローの設定：AIが一次処理を行い、どの条件で人が確認・承認するかを定める業務です。NIST（2023）のAIリスク管理枠組みは、リスクの大きさに応じた人の監督と、誤りを検知・是正する手順の設計を求めています。例えば、審査の指摘事項のうち、重大な不適合に関わるものは必ず審査員が確認してから申請者に通知する、金額が一定以上の返金は上長の承認を経る、といった設定です。

• 専門家のフィードバックの反映：利用者である専門家の修正や評価を、製品の改善に反映する仕組みの活用です。Brynjolfsson et al.（2025）が分析した顧客サポートのAIも、熟練者の対応記録を用いて、全担当者に同様の知見を提供する仕組みでした。

• データの参照範囲と権限の設定：部門・役割ごとにAIが参照できるデータと実行できる処理の範囲を定める業務です。NIST（2023）は、データの取り扱い範囲とアクセス権限の明確化をAIシステムの統治の基本要素としています。例えば、支店の担当者には自支店の顧客データのみを参照させ、本部の管理者には全体の集計を参照させる、という設定です。

限界として、製品が前提とする業務の流れと自社の流れが根本的に異なる場合、設定の積み重ねでは解決しません。従来のソフトウェアのミスフィット（Soh et al., 2000）と同じく、業務側を変えるか、別の製品を選ぶか、固有部分を切り離すかの判断が必要です。製品の外側に独自処理が増え始めたら、それは「特化型製品が業務に合っていない」か「その部分は自社開発すべき差別化の核である」かのいずれかであり、次に述べる自社開発の判断に移ります（Brehm et al., 2001）。

自社開発が適切な業務

基盤モデルのAPIを利用し、自社のデータを検索・参照させる仕組み（RAG）、モデルの追加学習（ファインチューニング）、複数の処理を組み合わせたエージェントなどを自社で構築する形態です（Lewis et al., 2020; Bommasani et al., 2021）。

• 市場に特化型製品が存在しない新しい領域：自社の業務が市場成熟度の軸で「創発」段階にあり、適切な特化型製品がまだ存在しない領域です（Wardley, 2020）。ただし、特化型製品の市場は急速に拡大しているため（Menlo Ventures, 2025）、「今は存在しない」が「来年も存在しない」とは限らず、自社開発を続ける理由を定期的に問い直す必要があります。例えば、自社固有の設備や工程を対象とする異常検知のように、業界内でも自社にしか存在しない業務は、製品が登場するまで自社で構築するしかありません。

• 規制や機密性の制約から、外部製品にデータを渡せない領域：規制上、顧客データや機密データを外部のサービスに送信できず、自社の管理下で動作する仕組みが必要な業務です。例えば、JPMorgan Chaseが自社開発を選んだ理由の一つは、金融規制のもとで機密データを外部に出せないことでした（JPMorgan Chase, 2025）。ただし、この制約は多くの場合、特化型製品の提供形態（自社環境内での稼働、データの非学習利用の契約）によって解消できるため、本当に自社開発でなければならないかを確認する必要があります。

• 自社の製品・サービスそのものにAIを組み込む場合：提供するサービスの中核がソフトウェアである企業にとって、そこに組み込むAIは定義上、差別化の核です（Andreessen, 2011）。例えば、自社のSaaS製品に顧客向けのAI機能を追加する場合、その機能は競合製品との差別化要素であり、外部の特化型製品をそのまま組み込むことは差別化を放棄することになります。ただし、この場合もモデル層は外部から調達し、ワークフローとデータの層を自社で開発するのが一般的です。

自社開発の判断では、AIシステムを「モデル層」「ワークフロー層」「データ層」に分けて考えます。モデル層はコモディティ化が最も速く、API経由で利用し特定のベンダー（OpenAIやGoogleなど）に固定しない設計を保ちます。データ層は最も重要な補完資産であり、自社開発や特化型AIではエクスポート機能を確保します（Teece, 1986）。ワークフロー層は、個人の汎用的な作業であれば汎用AI、業界共通の業務であれば特化型製品、差別化の核であり製品が存在しなければ自社開発、という対応になります。人命・財産・法的権利に関わる領域で専門家による開発・保守・評価体制を自社で構築できないなら、その体制を持つ特化型製品を選びます（NIST, 2023; Moffatt v. Air Canada, 2024）。

AI導入のフレームワーク

ここでは、これまでの整理を踏まえて、AI導入をどのように検討していくべきか、その実務的なフレームワークをステップごとに提示します。判断は「システム全体」ではなく「業務単位」で行うこと、そして「一度決めたら終わり」ではなく定期的に見直すことが、この枠組みの前提です。

ステップ1：業務を分解し、コアとコンテキストに分ける

• システム単位ではなく業務単位で考える：「基幹システムを作るか買うか」「AIを導入するか」という問いの立て方は、それ自体が失敗の始まりです。基幹システムは会計・購買・在庫・販売・生産など、性質の異なる多数の業務で構成されており、それぞれに適した形態は異なります。まず業務を、判断可能な粒度まで分解します。

• 各業務をコアとコンテキストに分類する：Moore（2005）の区別に従い、各業務を「顧客が自社を選ぶ理由に直接つながる業務（コア）」と「必要だが、競合と同じやり方で問題ない業務（コンテキスト）」に分けます。現場の担当者は自分の業務を「特殊で重要」と感じる傾向があるため、分類は経営層と現場が共同で、顧客の視点から行う必要があります。

• コアは少数に絞る：コアに分類される業務は少数にとどまるのが通常です。Prahalad & Hamel（1990）は、コアコンピタンスを5〜6個より多く挙げる企業はその意味を取り違えていると述べ、Moore（2005）は、活動は時間とともにコアからコンテキストへ移るため、資源の大半はコンテキストに消費されると論じています。分類の結果、コアが多数に上った場合は、「他社がやっていないか」「顧客がそれを理由に自社を選んでいるか」を一つずつ問い直すと、多くはコンテキストに移ります。例えば、10の業務を分類して6つがコアになった、という結果は、ほぼ確実に基準が甘いことを示しています。

• AIに向いている業務に限定する：「AI導入が適切な業務」の章で示した条件（言語・文書中心か、出力を検証できるか、能力の境界の内側か、熟練度のばらつきがあるか、責任と是正の仕組みを設計できるか、頻度が高いか）を業務ごとに確認します。

ステップ2：5つの判定テスト

前章の4つの軸に、実行可能性の軸を加えた5つのテストを、業務ごとに順に適用します。

• 差別化テスト：この業務を独自の方法で行うことは、顧客から見て価値があり、競合が容易に真似できず、持続的な優位につながるか。VRIOの4条件を満たす場合のみ「はい」とし、「はい」であれば自社開発を検討します。「いいえ」であれば、以下のテストで買い方を決めます。例えば、Walmartにとっての補充システムは「はい」ですが、同社の経費精算は「いいえ」です。

• 資産特殊性テスト：この業務の進め方は自社に固有か、それとも同業他社と本質的に同じか。同じであれば既存製品導入、固有であれば「その固有性は差別化テストを通過しているか」を再確認します。差別化につながらない固有性は、業務側を標準に合わせる対象です。例えば、「当社の承認は5段階」という固有性は、差別化につながらないので標準の3段階に合わせる対象です。

• 市場成熟度テスト：この業務を対象とする製品市場は、進化のどの段階にあるか。複数のベンダーが競合し、機能が標準化されている（製品・コモディティ段階）なら既存製品導入、製品が存在しないか未成熟（創発・独自構築段階）なら自社開発、という対応になります。例えば、顧客管理は成熟した製品市場がありますが、自社の特殊な製造工程の最適化は製品が存在せず自社開発になることがあります。AIの場合は、汎用AIで足りるか、特化型製品が存在するか、存在しないかの3段階で確認します。

• 変化速度テスト：この業務を規定する要件はどれくらいの速さで変化するか。変化が速い領域では、追随コストを外部化できる既存製品の優位が大きくなります。例えば、法令改正が毎年ある業務や、基盤モデルの進化に直接影響される業務は、追随を既存製品導入によってベンダーに委ねる方が合理的です。

• ケイパビリティテスト：自社は、このシステムを作り、稼働後も5年、10年にわたって改良・保守し続ける人材・予算・組織を持っているか。持っていない場合、他のテストが自社開発を示していても、既存製品でカスタマイズするか、共同開発によって製品側に自社要件を取り込む道を探ります。例えば、開発者が2名しかいない組織が自社開発を選ぶと、その2名の退職がシステムの寿命になります。

5つのテストのすべてが自社開発を示す業務だけが、自社開発の対象になります。1つでも既存製品導入を示すテストがあれば、それは自社開発のリスクを示す警告として扱い、既存製品導入（汎用AI・特化型AIエージェント）を検討します。とくにケイパビリティテストは、他の4テストの結果を覆す拒否権を持ちます。

ステップ3：ライフサイクル全体の費用と価値を評価する

• 開発費ではなく総保有コスト（TCO）で比較する：自社開発の費用は、初期開発費だけを見ると大きく過小評価されます。年間保守費は開発費の15〜20%に達し（Boehm, 1981）、保守・運用がライフサイクルコストに占める割合は5〜7割（Lientz & Swanson, 1980）から企業システムでは85〜90%（Erlikh, 2000）と推計されているため、10年の総保有コストは初期開発費の3〜10倍になります。既存製品の見積もりには、利用料に加えて、業務変更のコスト、連携部分の保守費、将来の乗り換え費用を含めます。例えば、Panorama Consulting Group（2024）の調査では、ERP導入プロジェクトの費用の中央値は45万ドル（対象企業の年商の約0.2%）であるのに対し、Bloch et al.（2012）が分析した大規模な独自開発プロジェクトは予算1,500万ドル以上であり、製品導入の比較し、自社開発は典型的に20〜30倍の開きがあります。そのうえで自社開発側には、この初期費用の3〜10倍の保守・刷新費が将来にわたって加わります。ただし、既存製品でもカスタマイズで深く作り込めば同じ桁に膨らむことは、Lidl（約5億ユーロ）やBirmingham市（1億ポンド超）の事例が示すとおりです（Handelsblatt, 2018; Grant Thornton UK LLP, 2023）。

• 参照クラスで見積もりを補正する：自社の見積もりに対して、同種のプロジェクトの実績分布（Flyvbjerg et al., 2022）を当て、とくにコスト超過が2倍以上になる確率を明示的に評価します。この確率を経営層が受容できない場合、その業務を自社開発の対象から外すか、規模を分割して個々の失敗が致命的にならないようにします。例えば、「6件に1件は予算が3倍になる」という実績分布を前提に、「3倍になっても事業に致命的でない規模」まで1件あたりの投資を分割します。

• 撤退コストと撤退の容易さを評価する：どの形態においても、「うまくいかなかったときにどれだけの損失で止められるか」を評価します。既存製品の解約と乗り換え、自社開発の中止と代替手段への移行、それぞれに要する費用と期間を見積もり、撤退の選択肢に価値を認めます（Keil, 1995）。この柔軟性の価値は、不確実性が高い領域ほど大きくなります（Fichman, 2004）。例えば、特化型AI製品を1年契約で試し、効果がなければ解約するという選択肢は、同じ機能を自社開発する場合には存在しません。

• Jカーブを前提に評価期間を設定する：導入後1〜2年の効果だけで判断すると、必要な補完投資を打ち切ることになりかねません。評価期間は少なくとも5年を設定し、その間の補完投資（業務再設計・教育）を予算に含めます（Brynjolfsson et al., 2021）。例えば、AIによる審査支援を導入した初年度は、審査員がAIの指摘を確認する手順に慣れるまで処理時間がむしろ増えることがあり、この期間を「失敗」と判断して打ち切ると、効果が出る前に投資を放棄することになります。

• AIの場合の費用構造の違い：基盤モデルのAPIは利用量に応じた従量課金であり、費用は固定費ではなく変動費になります。これは業績変動への耐性を高める一方、利用が拡大するほど費用が増えます。McKinsey（2026）の調査では、20%の企業がAIの運用コストが利用の制約になっていると回答しています。また、推論コストは急速に低下し続けているため、現在の価格を前提に「自社でモデルを運用する方が安い」と判断することは危険です。例えば、1件あたりの処理コストが1年で数分の一になることは珍しくなく、見積もりには価格低下のトレンドを織り込む必要があります。

ステップ4：工程ごとの失敗要因に対応するチェックポイントを置く

失敗の要因の章で整理した工程別の要因に対して、工程ごとに次のチェックポイントを設けます。

• 企画・投資判断の段階で確認すること：業務単位で導入レベルと責任者を決めた台帳があるか、見積もりが参照クラス（同種プロジェクトの実績分布）で補正されているか（Flyvbjerg, 2006; Flyvbjerg et al., 2022）、業務再設計・教育・運用体制といった補完的投資が予算化されているか（Brynjolfsson et al., 2021）、一括構築ではなく業務単位に分割されているか（Flyvbjerg & Gardner, 2023）を確認します。これらは「導入形態の誤判断」「計画錯誤」「補完的投資の漏れ」「スコープの肥大化」に対応します。例えば、「基幹システム刷新」という一つの稟議ではなく、会計・購買・在庫のそれぞれについて導入レベルと責任者と予算を分けて記載した稟議になっているか、という確認です。

• 要件定義・製品選定の段階で確認すること：製品と業務のミスフィットを洗い出し、「業務を変える」か「切り離す」かを決めたか（Soh et al., 2000; Davenport, 1998）、ベンダーの継続性・データのエクスポート手段・契約解除条件を評価したか（Shapiro & Varian, 1999）、要件定義とベンダー管理を担う自社人材がいるか（Feeny & Willcocks, 1998; Lacity et al., 2009）を確認します。AIの場合はこれに加えて、実際の業務データで小規模に試し、能力の境界を確認したか（Dell'Acqua et al., 2023）を確認します。例えば、製品のデモを見て選定するのではなく、自社の過去案件を数十件投入して、どこで製品が正しく処理できなかったかの一覧を作ってから契約する、という確認です。

• 設計・開発・カスタマイズの段階で確認すること：製品本体の改変に該当する作り込みが発生していないか、設定と連携の範囲に収まっているか（Brehm et al., 2001）、全体を統合し品質に責任を持つ主体が明確か（U.S. Government Accountability Office, 2014）、技術的負債の返済が計画されているか（Cunningham, 1992; McKinsey, 2020）を確認します。例えば、開発中に「この要望は設定で対応できるか、コードを書く必要があるか」を変更要求ごとに判定し、コードを書く場合は責任者の承認を必須にする、という運用です。

• テスト・移行・稼働の段階で確認すること：負荷テスト・受け入れテスト・データ移行の検証が計画どおり実施されたか（Somers & Nelson, 2001; U.S. Government Accountability Office, 2014）、段階的な移行や並行稼働を検討したか（Markus & Tanis, 2000）、「続ける・変える・止める」を判断するステージゲートがあり、判断者が推進者と分かれているか（Keil, 1995）を確認します。AIの場合はこれに加えて、誤りの検知と是正の手順、責任の所在が決まっているか（NIST, 2023; Moffatt v. Air Canada, 2024）を確認します。例えば、稼働判定会議の議長をプロジェクト推進者ではなく別部門の責任者とし、「テストで未解決の重大事項がゼロでなければ稼働しない」という基準を事前に文書化しておく、という運用です。

• 運用・保守・進化の段階で確認すること：保守体制と予算が確保されているか（Lientz & Swanson, 1980; Boehm, 1981）、担当者の交代に備えた文書化と知識共有があるか（Rigby et al., 2016）、業務プロセスの変更と教育が実施されているか（Aral & Weill, 2007）、ベンダーの価格改定・製品終了への対応策があるか（Farrell & Klemperer, 2007）を確認します。AIの場合はこれに加えて、基盤モデルの更新・廃止への追随手順と、出力品質の継続的な監視があるか（NIST, 2023）を確認します。例えば、稼働後1年の時点で「設計書は最新か」「主要な開発者が1人抜けても保守が続くか」「ライセンスの利用率は何%か」を点検する、という運用です。

ステップ5：定期的に見直す

• 年次で市場成熟度テストを再実行する：自社開発している領域について、「この1年で製品市場に変化はなかったか」を確認します。製品が登場していれば、内製を続ける理由を改めて問い直します。AIの領域では特化型製品の登場が速いため、この見直しは半年ごとが望ましい頻度です。例えば、1年前に「製品がないので自社開発した」社内文書の検索・要約の仕組みは、現在では複数の製品が同等以上の機能を提供している可能性が高いといえます。

• コアの陳腐化を検知する：かつて差別化テストを通過した業務が、競合の追随や業界の標準化によってコンテキストに変わっていないかを確認します。例えば、10年前には独自の強みだったオンライン注文の仕組みは、現在では業界全体の標準機能になっていることが多く、その部分の内製を続ける合理性は失われています。

• 人材とケイパビリティの変化を反映する：主要な開発者の離職や組織変更があった場合、ケイパビリティテストの結果は変わります。人材の状況に応じて、自社開発から既存製品導入への縮退、あるいは製品ベンダーとの共同開発への移行を検討します。例えば、自社開発したAIの仕組みの設計者が退職した時点で、同等の特化型製品への移行を真剣に検討すべきです。

• 迷ったときの原則：判断に迷う業務は、いったん既存製品導入で導入し、運用しながら差別化の余地を確認します。後から自社開発に移行することは可能ですが、自社開発で始めて後から既存製品導入に戻すことは、投じた開発費を放棄することを意味するため、はるかに困難です。不確実性のもとでは、可逆的な選択肢から始めることが合理的です。例えば、AIの導入では、まず汎用AIで個人の作業を支援し、次に特化型製品で業務プロセスに組み込み、それでも埋まらない差別化の核だけを自社開発する、という順序が、最も損失の少ない経路です。

おわりに

ほとんど全ての企業や組織にとって、AI導入は必須の検討事項になっている中で、既存製品を導入すること、もしくは自社開発をすることという選択があり、どのように判断していくべきか、迷われている方々も多くいると思います。本項の内容が検討や判断の指針になればと思います。

参考文献

• Andreessen Horowitz. (2025). How 100 enterprise CIOs are building and buying gen AI in 2025. a16z. 概要：企業CIO100人への調査に基づき、AIアプリケーションの調達が自社開発から外部製品購入へ移行していること、5モデル以上を併用する企業が37%に達したこと、ソフトウェア開発領域でコードの大半をAIが生成する企業が現れていることなどを報告した調査レポート。

• Aral, S., & Weill, P. (2007). IT assets, organizational capabilities, and firm performance: How resource allocations and organizational differences explain performance variation. Organization Science, 18(5), 763–780. 概要：IT投資の成果は投資額ではなく、IT資産の構成と組織のケイパビリティ（スキル・デジタル化された業務プロセス・IT活用の文化）の組み合わせで決まることを実証した研究。

• Barney, J. (1991). Firm resources and sustained competitive advantage. Journal of Management, 17(1), 99–120. 概要：持続的な競争優位は、価値があり・希少で・模倣困難で・組織的に活用される資源から生まれるとする資源ベース理論（VRIO）の原典。

• Bessen, J. (2022). The new Goliaths: How corporations use software to dominate industries, kill innovation, and undermine regulation. Yale University Press. 概要：WalmartやAmazonなどが市販されていない独自ソフトウェアで競争優位を築き、産業の集中と新規参入の停滞を招いていると論じた著作。自社開発が競争優位になる条件を示す。

• Bloch, M., Blumberg, S., & Laartz, J. (2012). Delivering large-scale IT projects on time, on budget, and on value. McKinsey Quarterly. 概要：オックスフォード大学との共同研究で5,400件超のITプロジェクトを分析し、大規模プロジェクトは平均で予算を45%超過し、価値は56%不足することを示した報告。

• Bloomberg. (2025, May). Klarna CEO says AI customer service push went too far, plans to hire humans again. Bloomberg News. 概要：KlarnaのCEOがAIによる顧客対応の品質低下を認め、人間の担当者を再び採用する方針を示したインタビュー報道。

• Brehm, L., Heinzl, A., & Markus, M. L. (2001). Tailoring ERP systems: A spectrum of choices and their implications. Proceedings of the 34th Hawaii International Conference on System Sciences. 概要：ERPの調整方法を「設定」から「ソースコード改変」まで9段階に分類し、段階が深くなるほど技術的リスク・保守コスト・サポート喪失が増大することを示した研究。

• Brooks, F. P. (1975). The mythical man-month: Essays on software engineering. Addison-Wesley. 概要：「遅れているプロジェクトに人員を追加するとさらに遅れる」というブルックスの法則を含む、ソフトウェア開発管理の古典。

• Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering. IEEE Computer, 20(4), 10–19. 概要：ソフトウェアの困難を「本質的な困難」（複雑性・同調性・可変性・不可視性）と「偶有的な困難」に分け、前者は道具や手法では解消できないと論じた論文。

• Brynjolfsson, E., Li, D., & Raymond, L. (2025). Generative AI at work. Quarterly Journal of Economics, 140(2), 889–942. 概要：顧客サポート部門への生成AI導入によって生産性が平均14%向上し、とくに経験の浅い担当者で効果が大きかったことを示した大規模な実証研究。

• Brynjolfsson, E., Rock, D., & Syverson, C. (2021). The productivity J-curve: How intangibles complement general purpose technologies. American Economic Journal: Macroeconomics, 13(1), 333–372. 概要：汎用技術の導入効果は、無形資産への補完的投資が先行するため当初は現れず、後に加速する「Jカーブ」を描くことを示した研究。

• Capital One. (2020, December 1). Capital One completes migration to the cloud and closes its last data center [Press release]. 概要：米国の大手銀行が8つのデータセンターをすべて閉鎖し、インフラをAWSに全面移行したことを発表した企業公表資料。規制産業におけるインフラ層の外部化の事例。

• Carr, N. G. (2003). IT doesn’t matter. Harvard Business Review, 81(5), 41–49. 概要：ITは電力や鉄道と同様にコモディティ化したインフラとなり、それ自体は競争優位を生まないため、支出の最小化とリスク管理に重点を置くべきだと論じた論文。

• Cunningham, W. (1992). The WyCash portfolio management system. OOPSLA ’92 Experience Report. 概要：短期的な近道として積み上げた設計上の妥協が、後の変更コストを継続的に押し上げることを「技術的負債」という比喩で初めて表現した報告。

• Davenport, T. H. (1998). Putting the enterprise into the enterprise system. Harvard Business Review, 76(4), 121–131. 概要：ERPが業務の進め方に関するベンダーの前提を組み込んでおり、導入企業は「システムを業務に合わせるか、業務をシステムに合わせるか」の戦略的選択を迫られると論じた論文。

• Dell’Acqua, F., McFowland, E., Mollick, E. R., Lifshitz-Assaf, H., Kellogg, K., Rajendran, S., Krayer, L., Candelon, F., & Lakhani, K. R. (2023). Navigating the jagged technological frontier: Field experimental evidence of the effects of AI on knowledge worker productivity and quality (Working Paper No. 24-013). Harvard Business School. 概要：758人のコンサルタントを対象とした実験で、AIの能力の境界が「ギザギザ」であり、境界の内側では生産性が大幅に向上する一方、外側では正答率が低下することを示した研究。

• Eloundou, T., Manning, S., Mishkin, P., & Rock, D. (2023). GPTs are GPTs: An early look at the labor market impact potential of large language models. arXiv:2303.10130. 概要：米国の労働者の約80%が業務タスクの10%以上に、約19%が50%以上に大規模言語モデルの影響を受けると推計し、AIが汎用技術であることを示した研究。

• Erlikh, L. (2000). Leveraging legacy system dollars for e-business. IT Professional, 2(3), 17–23. 概要：企業システムのライフサイクルコストのうち保守・運用が85〜90%を占めると推計し、レガシーシステムの維持費用の大きさを指摘した論文。

• Farrell, J., & Klemperer, P. (2007). Coordination and lock-in: Competition with switching costs and network effects. In M. Armstrong & R. Porter (Eds.), Handbook of industrial organization (Vol. 3, pp. 1967–2072). Elsevier. 概要：スイッチングコストとネットワーク効果が市場競争に与える影響を理論的に整理し、スイッチングコストが供給者に価格支配力を与える仕組みを示した文献。

• Ferdows, K., Lewis, M. A., & Machuca, J. A. D. (2004). Rapid-fire fulfillment. Harvard Business Review, 82(11), 104–110. 概要：Zara（Inditex）が2週間で企画から店頭までを回す業務モデルを、自社開発した簡素な情報システムと一体で運用していることを分析し、業務モデルに完全に適合したシステムが競争優位を生む仕組みを示した論文。

• Flyvbjerg, B. (2006). From Nobel Prize to project management: Getting risks right. Project Management Journal, 37(3), 5–15. 概要：計画錯誤への対策として、類似プロジェクトの実績分布から見積もりを補正する「参照クラス予測」を提案した論文。

• Flyvbjerg, B., & Budzier, A. (2011). Why your IT project may be riskier than you think. Harvard Business Review, 89(9), 23–25. 概要：1,471件のITプロジェクトを分析し、平均のコスト超過は27%だが、6件に1件はコスト超過200%・期間超過70%に達する「ブラックスワン」であることを示した論文。

• Flyvbjerg, B., Budzier, A., Lee, J. S., Keil, M., Lunn, D., & Bester, D. W. (2022). The empirical reality of IT project cost overruns: Discovering a power-law distribution. Journal of Management Information Systems, 39(3), 607–639. 概要：5,392件のITプロジェクトを分析し、コスト超過がべき乗分布（ファットテール）に従うことを示した研究。正規分布を前提とした見積もりが極端な超過を過小評価することを警告する。

• Gartner. (2025, June 25). Gartner predicts over 40% of agentic AI projects will be canceled by end of 2027 [Press release]. 概要：エージェントAIプロジェクトの40%超がコスト・不明確な価値・不十分なリスク管理を理由に中止されると予測し、数千の自称ベンダーのうち実際にエージェント機能を持つのは約130社とする「エージェント・ウォッシング」の横行を指摘した発表。

• Grant Thornton UK LLP. (2023). Birmingham City Council: Statutory recommendations under Section 24 of the Local Audit and Accountability Act 2014. 概要：バーミンガム市のOracle導入における予算超過と財務管理の機能不全について、過剰なカスタマイズを主因の一つとして指摘した外部監査人の報告。

• Handelsblatt. (2018, July). Lidl stoppt Milliardenprojekt mit SAP. Handelsblatt. 概要：7年間・約5億ユーロを投じたLidlのSAP導入中止と、在庫評価方式へのこだわりによる過剰なカスタマイズを原因として報じた記事。

• House of Commons Committee of Public Accounts. (2013). The dismantled National Programme for IT in the NHS (Nineteenth Report of Session 2013–14). The Stationery Office. 概要：英国NHSの電子カルテ統合プログラム（NPfIT）の解体後の費用と教訓を検証し、中央集権的な巨大独自開発の問題を総括した議会報告。

• JPMorgan Chase. (2025). LLM Suite named 2025 “Innovation of the Year” by American Banker. JPMorgan Chase Technology Blog. 概要：外部の基盤モデルを社内基盤上で利用する自社開発ツール「LLM Suite」の展開経緯と利用規模を説明した企業公表資料。

• Kahneman, D., & Tversky, A. (1979). Intuitive prediction: Biases and corrective procedures. TIMS Studies in Management Science, 12, 313–327. 概要：人が計画を立てる際に過去の類似事例を無視して内部の視点から見積もる「計画錯誤」を指摘し、外部の視点による補正を提案した論文。

• Keil, M. (1995). Pulling the plug: Software project management and the problem of project escalation. MIS Quarterly, 19(4), 421–447. 概要：失敗が明らかになりつつあるITプロジェクトが継続・追加投資されてしまう「エスカレーション」の要因を分析し、撤退判断の仕組みの必要性を示した研究。

• Klarna. (2024, February 27). Klarna AI assistant handles two-thirds of customer service chats in its first month [Press release]. 概要：外部の基盤モデルを用いて自社開発したAIアシスタントが、顧客対応の3分の2を処理し700人分の業務に相当すると発表した企業公表資料。

• Koch, C. (2002). Hershey’s bittersweet lesson. CIO Magazine. 概要：1999年のERP一斉切り替えで出荷障害を起こしたHersheyが、2002年の大規模アップグレードでは閑散期の段階的移行と十分なテストによって予定より早く予算を下回って完了させた経緯を報告した記事。

• Koch, C. (2004). Nike rebounds: How (and why) Nike recovered from its supply chain disaster. CIO Magazine. 概要：2000年の需要予測システム導入失敗の後、Nikeが基幹システム刷新を地域・業務ごとの段階的導入に転換し、2006年までに大きな障害なく完了させた経緯を報告した記事。

• Lacity, M. C., Khan, S. A., & Willcocks, L. P. (2009). A review of the IT outsourcing literature: Insights for practice. Journal of Strategic Information Systems, 18(3), 130–146. 概要：ITアウトソーシングの実証研究を体系的にレビューし、選択的アウトソーシングの優位、契約設計、発注側のケイパビリティの重要性を実務向けに整理した文献。

• Lehman, M. M. (1980). Programs, life cycles, and laws of software evolution. Proceedings of the IEEE, 68(9), 1060–1076. 概要：実際に使われるプログラムは継続的に変更されなければ満足度が低下し、変更を続けるほど複雑性が増大するという「ソフトウェア進化の法則」を定式化した論文。

• Lientz, B. P., & Swanson, E. B. (1980). Software maintenance management: A study of the maintenance of computer application software in 487 data processing organizations. Addison-Wesley. 概要：企業のソフトウェア保守活動を大規模に調査し、ライフサイクルコストの過半が保守に費やされることを初めて体系的に示した古典的研究。

• McKinsey & Company. (2026). The state of AI: Global survey 2026. QuantumBlack, AI by McKinsey. 概要：97カ国1,719人への調査に基づき、AIの利用率は88%に達する一方、EBITへの影響を報告する企業は37%にとどまること、回答者の80%が個人の生産性向上を実感していること、32%の企業がAIコーディングツールによる自社開発を選んだこと、20%の企業がAIの運用コストを利用の制約と感じていることなどを報告した調査レポート。

• Menlo Ventures. (2025). 2025: The state of generative AI in the enterprise. Menlo Ventures. 概要：企業の生成AI支出を分析し、外部製品購入が76%・自社開発が24%と前年から購入側へ大きく移動したこと、垂直特化型AIへの支出が35億ドルに達したこと、自律的なエージェントを運用している企業は16%にとどまることなどを報告した調査レポート。

• MIT NANDA. (2025). The GenAI divide: State of AI in business 2025. Massachusetts Institute of Technology. 概要：52組織へのインタビューと153人への調査に基づき、生成AIパイロットの95%が損益上の効果に至っていないこと、外部製品の本番到達率（67%）が自社開発（33%）の2倍であること、定着を妨げる「学習ギャップ」の存在を報告した調査レポート。

• Moffatt v. Air Canada, 2024 BCCRT 149 (Civil Resolution Tribunal of British Columbia, 2024). 概要：チャットボットの誤った案内について航空会社の責任を認め、賠償を命じたカナダの裁定。

• Moore, G. A. (2005). Dealing with Darwin: How great companies innovate at every phase of their evolution. Portfolio. 概要：企業の活動を差別化を生む「コア」と必要だが差別化を生まない「コンテキスト」に分け、あらゆる活動は時間とともにコアからコンテキストへ移行すると論じた著作。

• Nelson, P., Richmond, W., & Seidmann, A. (1996). Two dimensions of software acquisition. Communications of the ACM, 39(7), 29–35. 概要：取引コスト理論をソフトウェア調達に適用し、「業務の独自性」と「要件の不確実性」の2軸でパッケージ購入・カスタム開発・自社開発・外注の適否を整理した論文。

• Netflix. (2016, February 11). Completing the Netflix cloud migration. Netflix. 概要：2008年のデータベース障害を契機に開始したAWSへの移行を2016年に完了し、最後の自社データセンターを閉鎖したことを報告した企業公表資料。基盤を外部に委ね、差別化の核を自社開発する分離の事例。

• Panorama Consulting Group. (2023). The 2023 ERP report. Panorama Consulting Group. 概要：ERP導入企業への継続調査に基づき、予算・期間の超過率や目標達成率を報告する年次レポート。ERP導入の半数前後が予算または期間を超過し、期待した効果を十分に得た企業は半数に満たない実態を示す。

• Shapiro, C., & Varian, H. R. (1999). Information rules: A strategic guide to the network economy. Harvard Business School Press. 概要：情報財の経済的性質（スイッチングコスト、ロックイン、ネットワーク効果、標準化）を体系的に整理した、情報経済学の実務向け基本書。

• Soh, C., Kien, S. S., & Tay-Yap, J. (2000). Enterprise resource planning: Cultural fits and misfits: Is ERP a universal solution? Communications of the ACM, 43(4), 47–51. 概要：病院のERP導入を分析し、製品と組織の不一致（ミスフィット）をデータ・機能・出力の3種類に分類したうえで、カスタマイズによる解消が長期コストを膨らませることを示した研究。

• Standish Group. (2015). CHAOS report 2015. The Standish Group International. 概要：ソフトウェアプロジェクトの成功・課題あり・失敗の比率を継続的に調査した報告。成功率は3割前後で推移していることを示す。

• Standish Group. (2020). CHAOS 2020: Beyond infinity. The Standish Group International. 概要：CHAOSレポートの2020年版。成功率が20年以上大きく変化していないこと、成功要因として意思決定の遅延の抑制を挙げたことで知られる。

• Taima, M. (2026, June 12). AIエージェント企業はどれだけ大きな市場を狙うべきか — TAMの理論・事例・最新研究. mign. https://www.mign.io/articles/57854/ 概要：汎用AI企業（OpenAI、Anthropic、Google）が知識労働全体を、業界特化AIエージェント企業（Harvey、Cursor、Sierra、OpenEvidenceなど）が特定業界の人件費支出を対象市場とする構造を整理し、Service-as-a-Softwareの概念と各社の売上・対象市場・達成度を定量比較したコラム。

• Teece, D. J. (1986). Profiting from technological innovation: Implications for integration, collaboration, licensing and public policy. Research Policy, 15(6), 285–305. 概要：イノベーションの利益は発明者ではなく、商業化に必要な補完資産の保有者に流れる条件を示した、技術戦略論の最重要文献の一つ。

• U.S. Government Accountability Office. (2014). Healthcare.gov: Ineffective planning and oversight practices underscore the need for improved contract management (GAO-14-694). 概要：Healthcare.govの立ち上げ失敗について、統合責任者の不在、要件の頻繁な変更、テストの不足を指摘した米国会計検査院の監査報告。

• Wardley, S. (2020). Wardley maps: Topographical intelligence in business. Creative Commons（オンライン公開）. 概要：技術や活動が「創発→独自構築→製品→コモディティ」と進化することを前提に、事業の構成要素を地図として描き、段階ごとに適切な調達方法を選ぶ手法を体系化した著作。

• Williamson, O. E. (1985). The economic institutions of capitalism: Firms, markets, relational contracting. Free Press. 概要：資産特殊性・不確実性・頻度の3要素によって、取引を内部化すべきか市場に委ねるべきかが決まることを精緻化した取引コスト経済学の基本書。

• Zylo. (2023). 2023 SaaS Management Index. Zylo. 概要：企業のSaaS契約データを分析し、契約済みライセンスの約40%が未使用で、1社あたり年間約1,700万ドルが無駄になっていることを報告した調査レポート。