生成AIで生産性が上がっても売上が伸びない理由：機能追加競争から顧客価値の再設計へ

生成AIで開発速度や作業量が上がったのに、なぜ売上・継続率・利益が伸びないケースがあるのか。その理由を「社内の生産性」と「顧客が支払う価値」の違い、そして一部の顧客・担当者がAIで簡単な試作を作れる時代の競争構造から整理し、明日から見直せる指標と打ち手に落とし込みます。

🧭 テーマの主役：「生産性と売上の分離」とは何か

この記事の主役は、生成AIによって社内の生産性が上がっても、それだけでは顧客の支払意思や売上に変換されないことがある、という構造上の仮説です。ここでいう顧客は契約を決める顧客企業、利用者は日常的にサービスを使う担当者、提供者はサービスを開発・運用する側を指します。

日常の例えなら、厨房の料理人がAIという超高速な調理器具を手に入れ、同じ時間で10皿作れるようになった状態を想像してください。ところが、お客さんが欲しい料理は3皿だけで、残りの7皿は注文されていない。厨房の生産性は上がっていますが、店の売上は増えません。むしろ食材費と在庫、片付けだけが増える可能性すらあります。

ソフトウェアでも同じです。生成AIでコード、画面、帳票、連携機能を速く作れても、顧客が困っている問題をより大きく解決できなければ、機能数は売上になりません。さらに現在は、一部の顧客・担当者が生成AIを使って、低リスクな簡単な画面や小さな自動化の試作を作れます。「作れること」そのものの希少性が下がる領域が出てきたため、提供側は「何を作ったか」ではなく「顧客が自力では得にくい結果を、どのように継続提供するか」で競う必要があります。ここでいう「作れる」は、試作を動かせるという意味であり、本番運用を安全に維持できることまでを意味しません。

この構造を理解すると、次の判断ができるようになります。

• 生産性KPIと売上KPIが、どこで切れているかを見つける
• 機能追加ではなく、顧客の成果・継続・移行コストを改善する投資を選ぶ
• ユーザーがAIで自作できる機能と、サービスに残る価値を分ける
• 生成AIへの投資が、他のSaaS（Software as a Service、インターネット経由で継続利用するソフトウェア）の契約・更新や業務基盤を押し出していないか確認する
• 「作った量」から「使われ、成果が出て、契約され、利益が残った量」へ評価軸を変える

😓 動機：「たくさん作ったのに、なぜ買われないのか」

生成AIを開発現場に導入すると、まず現れる変化は分かりやすいものです。実装の初稿が速くなり、試作画面が増え、要望への返答も早くなる。「以前は1か月かかった機能が、数日でできた」という感覚も生まれます。ここまでは本当によい変化です。ただし、この変化は個別のタスクやチームの観測であり、売上や利益の増加を自動的に意味するものではありません。

しかし、経営会議で売上のグラフを見ると、線がほとんど動いていない。利用者に聞くと「便利そうだが、なくても困らない」と言われる。開発チームはさらに機能を足し、ユーザーはさらに多くの機能を見せられ、画面は賑やかになる。なのに、継続利用も契約更新も伸びない。この現象は、生成AIの性能不足だけでは説明できません。

理由の一つは、供給能力と需要が別の指標だからです。供給能力とは、社内がどれだけ速く成果物を作れるか。需要とは、顧客がその成果物によってどれだけ重要な問題を解決でき、対価を払いたいと思うかです。高速道路を増やしても、行き先が人気になるとは限らない。道を造る速度と、目的地の魅力は別問題です。

もう一つの理由は、開発側が「機能を完成させる」ことを成果にしやすい点です。機能は数えやすく、デモもしやすい。一方で「導入後に毎週使われたか」「顧客の処理時間や損失が減ったか」「解約理由が変わったか」は、計測と営業・サポートとの連携が必要になります。数えやすいものを追うと、いつの間にか売上の代わりに機能数を最適化してしまいます。

🧪 仮説：AI時代には「開発速度」ではなく「価値の変換率」がボトルネックになる

ここで仮説を置きます。生成AIによって作る速度が上がるほど、ボトルネックは実装ではなく、顧客課題の選定・導入・利用定着・支払いへの変換に移るのではないか。

この仮説は、工場の生産ラインに似ています。上流の機械を速くすると、検品、梱包、配送、店頭販売が詰まります。ソフトウェアでも、コード生成だけを高速化すれば、要件の優先順位、UX（User Experience、ユーザー体験）、営業提案、オンボーディング（導入初期に利用者が使い始めるまでを支援する活動）、サポート、請求が新しい待ち行列になります。

ここでいう価値の変換率は、厳密な会計用語ではなく、開発したものが顧客成果と事業成果へ変わる割合を考えるための実務上の見方です。なお、段階ごとの割合を掛け合わせれば売上や利益を予測できる、という意味ではありません。顧客や契約を同じ単位で追える場合に、どこで離脱が増えたかを診断するためのモデルです。たとえば、次のような段階を分けて観測します。

1. 作った：リリース可能な機能になった
2. 届いた：対象顧客に認知され、導入された
3. 使われた：継続的な利用行動が起きた
4. 成果が出た：顧客の時間、売上、品質、リスクが改善した
5. 契約された：契約、更新、追加購入に反映された
6. 利益が残った：提供コストを差し引いて、提供者の粗利・利益に貢献した

生成AIが主に押し上げるのは、開発供給側の「作った」に近い部分です。営業・サポート・分析でもAIは使えますが、少なくとも開発速度の上昇だけでは、2〜6の達成は保証されません。売上を増やすには、どこが落ちているかを直し、利益を残すには提供コストまで確認しなければなりません。

この図で重要なのは、売上と利益が最終段だけの問題ではないことです。機能が届いていなければ営業・導入が問題です。使われていなければ体験と習慣化が問題です。使われていても成果が出なければ、対象業務やデータ設計が問題です。成果が出ても契約されなければ、価格、契約、信頼、競合との差の説明が問題になります。契約されても提供コストが高ければ利益は残らないため、AI利用料だけでなく、導入・サポート・運用工数まで確認します。

🔬 検証：売上が伸びない6つの理由（本稿の仮説モデル）

ここからは、本稿の問題設定である「一部の顧客・担当者もAIを使うため、低リスクな簡単な機能は自分で試作できる」という変化を中心に、売上へつながらない理由を6つに分けます。ここには、提供者側が生成AIに予算を寄せた結果、他のSaaS（Software as a Service、インターネット経由で継続利用するソフトウェア）や業務ツールへ回せる余力が細るケースも含めます。これは売上停滞のすべてを説明する普遍法則ではありません。景気、競合、営業チャネル、価格、顧客構成など別の要因もあるため、実際には自社データでどの段階が詰まっているかを検証してください。

1. 「作れる機能」がコモディティ化し、差別化にならない

コモディティ化とは、以前は珍しかった機能が広く普及し、機能単体では価格や選定理由になりにくくなることです。以前なら、フォーム、簡単な集計、定型メール、要約画面を作れることが開発会社の強みになったかもしれません。しかし生成AIとノーコード／ローコード（コードをほとんど書かずにアプリを組み立てる開発手法）の普及によって、一部の顧客が低リスクな小さなツールを試作するハードルは下がっていると考えられます。顧客層、利用できるツール、社内の権限や規制によって状況は変わるため、すべての顧客が本番機能を自作できるという意味ではありません。

これは「すべてのソフトウェアが不要になる」という意味ではありません。料理で言えば、家庭用の調理器具が高性能になったからといって、レストランが消えるわけではない。ただし、「野菜を切るだけ」「決まった材料を混ぜるだけ」の作業は、外注する理由が弱くなる。外食店には、味の再現性、仕入れ、衛生、席、予約、接客のような、家庭で毎回そろえるのが面倒な価値が残ります。

ソフトウェアの差別化も同じです。単発の画面や小さなスクリプトではなく、次のような顧客側で再現しにくい資産が重要になります。

• 業界固有のデータモデルと業務ルール
• 既存システムとの安定した連携、権限、監査ログ
• 顧客の業務に合わせた導入・移行・教育
• 継続的な改善、障害対応、セキュリティ更新
• 複数部門・複数企業をまたぐワークフロー
• 結果に対する説明責任、SLA（Service Level Agreement、提供者が守るサービス水準の合意）

「機能を作る能力」が不要になるのではなく、機能を業務成果へ組み込む能力の相対的な価値が上がります。

2. 機能数を増やしても、利用者の成果が増えるとは限らない

機能追加は、開発チームにとって達成感があります。チケットが閉じ、リリースノートが書け、デモもできます。けれども、顧客が使うのは、画面に存在する機能の数ではなく、自分の仕事が前よりよくなる経路です。

新機能が使われない理由は、機能が悪いとは限りません。どこにあるかわからない、設定が難しい、既存の手順を変える必要がある、権限申請が面倒、結果が既存帳票とつながらない、といった導入摩擦が原因かもしれません。機能を追加するほど、学習負荷と選択肢が増えて、逆に使い始めにくくなることもあります。

プロダクトの価値は、リリース数ではなく、対象顧客が重要な行動を繰り返し、成果を確認できたかで見るべきです。機能を10個増やすより、主力顧客が週次で使う1つの流れから不要な入力を3項目減らす方が、継続には効く場合があります。

3. 生産性向上が「供給過剰」を生み、レビュー・サポート・運用が詰まる

生成AIで開発が速くなると、社内には「作れるから作る」圧力が生まれます。すると、要望の整理が追いつかず、レビュー待ち、テスト不足、ドキュメント不足、サポート問い合わせの増加が起こります。工場でいうと、完成品の数は増えたのに検品と出荷が追いつかない状態です。

DORA（DevOps Research and Assessment、開発・運用組織の能力を調査する研究プログラム）の2024年レポート、METR（Model Evaluation and Threat Research、AIの能力や影響を評価する研究組織）の2025年の開発者調査、GitHubの研究が示すように、AI支援の効果はタスク・経験・検証コストによって変わります。GitHubは特定のコーディング課題を速く完了できた実験結果を報告しています[3]。一方、METRの経験豊富なオープンソース開発者を対象にした研究では、文脈の重い実務でAI利用時の実測が事前の期待を下回ったと報告されています[2]。DORAの調査も含め、いずれも対象・条件のある研究であり、一般の組織全体へそのまま外挿はできません。だからこそ、生成速度をそのまま組織全体のスループットと見なすのは危険です[4]。

特に売上に効くのは、顧客に見える品質です。リリース後の不具合、予期せぬ仕様変更、問い合わせ対応の遅れは、機能数では帳消しにできません。速く作るほど、品質ゲート、リリース後の観測、顧客への説明を強くしなければなりません。

4. 一部の顧客がAIで試作できるため、「完成品」より「運用の面倒」が価値になる

ここが今回の中心論点です。一部の顧客企業の担当者が生成AIを使えば、簡単なCRUD（Create, Read, Update, Delete、データの登録・参照・更新・削除）画面や集計スクリプトを試作できる場合があります。その場合、提供側は「自分たちだけが作れる機能」を売りにしにくくなります。

しかし、ユーザーが自作できることと、ユーザーが自作したいことは別です。試作品を作ることはできても、本番運用には次の面倒が残ります。

• データを正しく定義し、重複や欠損を管理する
• 誰が何を見られるかを設定し、退職・異動時に更新する
• 既存の会計、顧客、在庫、認証システムと接続する
• 障害時に原因を追跡し、復旧し、利用者へ説明する
• 法令・契約・監査の条件を満たす
• 担当者が変わっても運用を続ける

AIは試作の初速を上げますが、運用責任の引き受けまでは自動で済ませてくれません。ここに、サービス事業者が提供できる価値があります。単に「機能を納品する」のではなく、「顧客の業務に安全に組み込み、成果が出るまで運用を支える」ことを商品化するのです。

5. 顧客が得た便益を、価格と契約へつなぐ設計がない

顧客の仕事が速くなっても、顧客がそれを価値として認識できなければ、値上げや追加契約にはつながりません。たとえば月に数分の短縮では、担当者が便利だと思っても、購買部門が予算を出すほどの優先度にならない場合があります。

逆に、売上機会の損失を防ぐ、監査対応を短くする、処理能力の上限を広げる、重要顧客の離脱を防ぐ、といった結果は、価格の説明と結びつきやすい。ここで必要なのは、AIの性能を説明することではなく、顧客の経営指標にどう影響したかを一緒に測ることです。

生成AIのROI（Return on Investment、投資利益率）を考えるときも、「何時間削減したか」と「その時間が何に変わったか」を分ける必要があります。空いた時間が現金支出の削減、追加処理、納期短縮、顧客維持のどれにつながったのかを確認しないと、便利さは売上の根拠になりません。

6. 生成AI投資が他の業務ツールの予算を押し出し、業務全体の成果が下がる

ここは見落とされやすい、もう一つの仮説です。生成AIの利用料、開発者向け契約、API（Application Programming Interface、ソフトウェア同士が機能やデータをやり取りする接続口）、GPU（Graphics Processing Unit、AI計算などを並列処理する半導体）、導入支援、教育、レビュー工数が膨らむと、会社は単に「AI費用が増えた」だけでなく、他のSaaSや必要な業務基盤を契約・更新する予算を失うかもしれません。

家計でいえば、便利な調理家電を買い足した結果、冷蔵庫の修理費や食材費を削るようなものです。調理速度は上がっても、保存、買い物、衛生という別の基盤が壊れれば、食卓全体の満足度は下がります。企業でも、生成AIの開発速度を上げる一方で、CRM（顧客関係管理）、分析、監視、セキュリティ、会計、顧客サポートなどのSaaSを縮小すれば、営業機会、顧客理解、運用品質が落ち、結果的に売上へ悪影響が出る可能性があります。

ただし、「AI投資が他のSaaSを必ず押し出している」と確認されたわけではありません。予算が年度単位で固定されているのか、追加投資枠があるのか、AIが既存ツールを置き換えているのか、単に新規費用として積み上がっているのかで意味は変わります。したがって、AI予算を単独で見るのではなく、テクノロジー予算全体のポートフォリオとして確認します。FinOps（クラウドなどの変動費を可視化し、事業成果と結び付けて継続管理する考え方）のように、AI費用だけでなく、関連する契約・利用量・業務成果を同じ台帳で追う発想です[6]。

最低限、次の3つを同じ期間で比較すると、押し出しの有無を仮説検証できます。

• AI関連の契約費、API利用料、インフラ費、人の運用・確認工数
• 他のSaaSの新規契約・更新・解約・席数削減と、その理由
• 営業、サポート、データ分析、セキュリティ、会計など、各業務KPIの変化

AIが既存SaaSの代替になり、重複契約を減らせるなら、予算圧迫ではなく合理化です。反対に、AIを追加しただけで既存ツールを減らせず、業務KPIも改善しないなら、AI投資が他の重要な投資を押し出している可能性があります。ここで見るべきは「AI費用の大小」ではなく、1円の技術予算をどこへ置くと顧客成果と利益が最大になるかです。

この判断では、機会費用（ある投資を選んだために、見送った別の選択肢から得られなかった価値）も意識します。たとえばAI関連の契約・API・運用に予算を追加したことで、営業管理、顧客分析、監視、セキュリティなどのSaaSの更新を見送ったなら、その見送りによる影響もAI投資の評価材料です。AIの請求書だけを見ていると、この会計上見えにくい損失を拾えません。

実務では、AIを導入した月以降について、次の3列を同じ期間で並べます。

この台帳の目的は、AI投資を一律に削ることではありません。AIが既存SaaSを置き換え、総コストと業務リスクを下げているなら継続すべきです。反対に、AIの利用量だけ増え、他の基盤も維持できず、顧客成果も変わらないなら、モデルの削減だけでなく投資配分そのものを見直す段階です。

📊 結果：KPIを「作った量」から「顧客価値の変換」に置き換える

ここまでの仮説と理由を、測定できる形に変換します。KPI（Key Performance Indicator、重要業績評価指標）は、数が多いほどよいわけではありません。生産性の上昇がどこで止まっているかを特定できるよう、段階別に置きます。

この表で、開発KPIだけが伸びて「届いた」以降が横ばいなら、追加実装より導入・営業・UXへの投資が優先です。「使われた」が伸びないなら、機能不足ではなく価値の入口がわかりにくい可能性があります。「成果が出た」が伸びないなら、顧客の業務そのものを理解し直す必要があります。

このループのポイントは、開発だけで閉じないことです。契約後の売上が提供コストを上回り、粗利が残るかまでを同じループで確認します。顧客課題の選定には営業・サポートの声が必要で、成果測定には顧客データが必要です。利用されない理由が導入の難しさなら、営業資料や設定画面を直す。成果が出ない理由がデータ品質なら、連携と運用を直す。問題が価格説明なら、成果レポートと料金単位を直す。AI費用のために別の重要なSaaSを見送っているなら、その機会費用も再投資の判断に含めます。開発はこのループの一部であり、全体ではありません。

💡 想定ケース：顧客が自作できる時代に、サービスの価値を組み替える

ここでは、社内業務向けの小規模SaaS（Software as a Service、インターネット経由で継続提供するソフトウェア）を想定します。以前のサービスは、顧客から要望を聞くたびに個別画面を作り、機能追加費用を請求していました。生成AI導入後、開発チームは試作を高速化し、月に作れる機能数は増えました。しかし顧客の反応は鈍い。なぜなら、顧客の担当者もAIを使って簡単な画面を作れるようになり、「その画面だけ」に費用を払う理由が薄くなったからです。さらに提供者側では、AIの契約費とAPI利用料が増えた一方、営業管理や顧客分析に使う別のSaaSの更新を見送っていました。新機能の供給能力は上がったのに、売る力と顧客理解の基盤が弱くなった、という状況です。なお、これは実在企業の事例ではなく、AI投資と他SaaSの予算競合が起きた場合を説明する想定ケースです。

そこで、提供価値を次のように組み替えます。

• 個別画面の受託制作ではなく、顧客データを安全に扱う共通基盤を提供する
• 顧客がAIで作った小さなツールを、認証・権限・監査ログ付きで運用できるようにする
• 既存の会計・販売・在庫システムと接続し、二重入力をなくす
• 利用状況を見ながら、月次で業務フローの改善提案を行う
• 機能の納品ではなく、「月末処理の完了時間」「入力ミス」「問い合わせ件数」などの成果を共有する

この場合、AIは競合ではなく、顧客と提供者の共同作業を速くする道具になります。顧客は自分で小さな試作を作れる。提供者は、その試作を本番の業務、データ、権限、運用へ接続し、壊れたときに戻せるようにする。価値の中心が「画面を作ること」から「安全に使い続け、成果を出すこと」へ移るわけです。

ここで重要なのは、導入効果を数字で確認することです。たとえば「月末処理の担当者作業時間」「差し戻し件数」「処理完了までの経過時間」「継続利用部門数」を導入前後で比較し、顧客と一緒に振り返ります。数値はここではあくまで測定項目の例であり、効果を保証するものではありません。効果が出なければ、機能を追加する前に対象業務、データ、導入手順を見直します。

🔥 ハマりポイント：売上を伸ばしたいチームが陥る4つの罠

生産性が上がった後ほど、開発チームは「もっと作れる」という誘惑にさらされます。ここでは、症状・原因・対処法をセットで整理します。

その1：「リリース数が増えたから成長している」と思う罠

症状は、リリース件数、コミット数、生成コード量は増えたのに、利用率や更新率が動かないことです。原因は、供給側の活動量を顧客側の成果と取り違えていること。対処法は、各機能に「対象顧客」「変える行動」「顧客KPI」「撤退条件」を紐づけ、リリース後に実際の利用と成果を確認することです。コードの山は、売上の山ではありません。

その2：「顧客が自作できるなら価格を下げるしかない」と思う罠

症状は、簡単な機能を無料化・値下げし続け、粗利だけが薄くなることです。原因は、売っていたものを機能単体だと決めつけていること。対処法は、機能、基盤、連携、運用責任、成果測定を分け、顧客が自作しにくい部分を商品として再設計することです。蛇口が安くなったからといって、水道管・浄水・保守まで無料になるわけではありません。

その3：「AIを使えば導入説明はいらない」と思う罠

症状は、デモでは好評なのに、本番ユーザーの利用が始まらないことです。原因は、顧客の権限、データ、既存手順、責任者が未整理なこと。対処法は、オンボーディングを製品の一部にし、初回価値到達時間（Time to Value、利用開始から最初の成果を感じるまでの時間）を測ることです。AIは説明資料を作れますが、顧客社内の合意形成までは代行しません。

その4：「高機能なら解約されない」と思う罠

症状は、機能一覧は増えたのに、顧客が使うのは一部だけで、更新時に「結局使わなかった」と言われることです。原因は、利用者が成果へ到達する主経路を設計していないこと。対処法は、主要なユースケースを絞り、使われていない機能を隠す・統合する・廃止する判断も持つことです。メニューが100品ある店より、注文すべき3品が明確な店の方が、初回客には親切なことがあります。

🔄 代替アプローチとの比較：何を売るかを選び直す

「機能を増やす」以外にも、売上と継続を伸ばす打ち手があります。大切なのは、顧客がAIで自作できる範囲と、提供者が引き受ける責任を分けて考えることです。

この比較で伝えたいのは、「顧客が自作できるなら終わり」ではなく、「顧客が自作する部分を前提に、提供者の役割を変える」ということです。顧客が作った小さな機能を安全な環境へ載せる、データをつなぐ、運用を引き受ける、成果を測る。こうした役割は、単体機能よりも継続契約と相性がよいと考えられます。

一方で、すべての企業が高価な伴走型へ移行すべきだとは限りません。課題が単純で、顧客が自力で安全に運用でき、導入後の支援も不要なら、低価格の機能提供が合理的です。顧客の自作能力を過小評価して囲い込むより、顧客が本当に外部へ任せたい部分を聞く方が、長期的な信頼につながります。

📌 注目ポイント：AI時代に残る価値を5つの層で見る

ここまでの議論を、サービス価値の層として整理します。上に行くほど機能単体から離れ、顧客の業務と継続運用に近づきます。

ただし、「自作難易度が高いから売れる」と単純化してはいけません。難しいものを作っても、顧客の課題が小さければ売れない。最初に顧客の重要課題を選び、その解決に必要な層だけを組み合わせることが大切です。高機能な金庫を作っても、誰も現金を預ける必要がなければ商売にはなりません。

🚀 取り込み方：今日・今週・今月で売上への変換率を測る

いきなり事業モデルを全面改修する必要はありません。まず、最近リリースした機能を1つ選び、「作った後」のどこで止まっているかを確認します。

今日（5分でできること）

機能を1つ選び、次の5行を埋めます。

• 対象顧客：誰の、どの業務を対象にしたか
• 変える行動：利用者は何をするようになるのか
• 顧客成果：時間、件数、品質、売上機会の何が変わるのか
• 支払理由：なぜ顧客は自作・代替・現状維持ではなく、料金を払うのか
• 撤退条件：どの期間・指標なら追加開発を止めるのか

この5行が書けない場合、問題は開発速度ではなく、価値仮説の曖昧さです。AIに文章を整えてもらうことはできますが、対象顧客と撤退条件を決める責任は人が持ちます。

今週

営業、サポート、開発、可能なら顧客を交え、対象機能について次のデータを同じ顧客群で確認します。

• 初回設定が完了するまでの時間
• 初回価値に到達するまでの時間
• 主要行動の週次利用率・継続率
• 手戻り、問い合わせ、エラーの発生数
• 顧客が報告した業務成果と、更新・拡張との関係
• AI関連費用と、他SaaSの新規契約・更新延期・解約・席数削減を同じ期間で比較する

集計できない項目は、まず10件程度を初期目安として顧客インタビューと利用ログの確認から始めます。ここで大事なのは、機能を褒めてもらうことではなく、「使わなかった理由」「自作した理由」「お金を払うなら何を任せたいか」を聞くことです。行動ログは顧客の本音を一意に決めるものではありませんが、機能要望、インタビュー、営業・サポート記録と組み合わせれば、仮説を作る有力な手掛かりになります。

今月

機能追加の前に、次のいずれかを小さく試します。

1. 導入手順を短くし、初回価値到達時間を比較する
2. 使われていない機能を隠し、主経路を一本化する
3. 顧客が自作した処理を、安全なデータ・権限・監査基盤へ接続する
4. 顧客KPIを記録した成果レポートを提供する
5. 利用料だけでなく、運用・連携・支援の価値を含む料金案を比較する
6. AIを追加したことで見送ったSaaSや業務基盤がないかを確認し、見送った場合の業務KPIへの影響を記録する

この1か月で、売上がすぐ増えるとは限りません。しかし「どこが詰まり、何を直せば支払いに近づくか」「AI投資が他の基盤投資を押し出していないか」という情報が得られます。情報なしで機能を増やすより、次の投資判断に使える分だけ前進です。

✅ 要点まとめ：AIで作る量が増えたからこそ、売るものを変える

この記事の要点を、短く圧縮します。生成AIは敵でも救世主でもなく、供給能力を押し上げる道具です。売上を伸ばすには、その速さを顧客価値へ向け直す必要があります。

• 社内の生産性向上は、顧客の支払意思や売上と同じではない。本稿の中心命題は、売上停滞を診断するための仮説モデルである
• 一部の顧客・担当者が低リスクな簡単な試作を作れる領域では、機能単体の希少性が下がり得る
• 差別化の中心は、機能から業務理解、データ連携、信頼、運用、成果改善へ移る
• リリース数ではなく、「届いた・使われた・成果が出た・契約され、利益が残った」を段階別に測る
• 売上が伸びないとき、追加開発より導入、UX、サポート、価格、成果測定が先の場合がある
• AIが既存SaaSを置き換えるなら合理化だが、追加費用として積み上がるだけなら、他の契約・更新を押し出す機会費用も確認する
• 顧客の自作を否定せず、自作したものを安全な本番運用へつなぐ役割を商品化できる
• 機能ごとに対象顧客、変える行動、顧客成果、支払理由、撤退条件を持つ

📅 今後の展望：ソフトウェア会社は「機能の供給者」から「成果の運用者」へ

今後、生成AIの性能が上がり、ユーザー側の自作能力も高まるほど、単純な画面、文章生成、集計、軽いワークフローはさらに安く速く作れるようになると考えられます。これは開発者にとって脅威である一方、顧客と同じ道具を使い、検証を速く回せる機会でもあります。

競争の焦点は、誰が最初に機能を作ったかから、誰が顧客の現場に定着させ、データを正しく扱い、失敗から復旧し、成果を説明できるかへ移るでしょう。AIがコードを書くほど、人間に残る仕事は「何を作るか」「何を作らないか」「誰が責任を持つか」「成果をどう測るか」です。

もちろん、すべてのサービスがコンサルティング化すればよいわけではありません。顧客が自力で使える低価格の部品、専門業務に深く組み込まれた基盤、運用を丸ごと任せられるサービスなど、複数の層を用意する方が現実的です。重要なのは、顧客の自作能力を前提に、自作より任せる価値がある場所を明確にすることです。

まとめ

生成AIにより生産性が上がったのに売上が伸びないケースがある理由は、AIが役に立たないからではありません。「作る」工程だけが速くなり、顧客に届く、使われる、成果が出る、契約される、利益が残る工程の設計が古いままだからです。もちろん、これはすべての売上停滞を説明する結論ではなく、開発供給側と顧客価値の接続を診断するための仮説です。

さらに一部の顧客・担当者はAIを使い、簡単な機能を試作できるようになりました。この変化は、ソフトウェア会社の価値を消すのではなく、価値の場所を移します。単体の画面やスクリプトを売るだけではなく、業務理解、データ連携、セキュリティ、運用、成果測定、継続改善を組み合わせる。顧客が自作できる世界で、顧客が自作しなくてもよい理由を作るのです。また、生成AI費用のために他のSaaS更新や顧客理解の基盤を削っていないかも、同じ投資判断の中で確認します。

この記事を読んだあなたは、次の機能追加会議で「何個作れるか」だけでなく、「誰の行動を変え、どの成果を生み、なぜ顧客が払い、提供コストを差し引いて利益が残るか、どこで撤退するか」を確認できるはずです。生成AIで増えた開発速度を、機能の山ではなく、顧客の成果と利益の残る継続契約へ変換する。それが、これからの生産性向上です。

参考文献

本文で参照した資料と、論点を深掘りするための関連資料を示します。研究結果は対象・条件のある観測であり、売上や自作能力についての一般法則を直接証明するものではありません。

1. Erik Brynjolfsson, Danielle Li, Lindsey R. Raymond, National Bureau of Economic Research, “Generative AI at Work,” Working Paper 31161. 顧客サポート業務における生成AI支援の効果を、担当者の経験差も含めて分析した研究。
   https://www.nber.org/papers/w31161
2. METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” 2025-07-10. 経験豊富なオープンソース開発者を対象に、AI利用時の実測と事前期待の差を検証した報告。
   https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
3. GitHub Blog, “Research: quantifying GitHub Copilot’s impact on developer productivity and happiness,” 2022-09-07. 特定のコーディング課題におけるCopilot利用の実験結果を紹介した報告。
   https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
4. DORA, “Accelerate State of DevOps Report 2024.” AI導入とソフトウェアデリバリーのスループット・安定性を含む、開発組織の能力に関する調査。
   https://dora.dev/research/2024/dora-report/
5. McKinsey, “The State of AI: Global Survey 2025.” AI利用の拡大と、実験から組織的な成果へ移行する課題を整理した調査。本文では背景資料として参照。
   https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
6. FinOps Foundation, “What is FinOps?” 変動する技術コストを可視化・最適化・継続運用する考え方を説明する公式資料。
   https://www.finops.org/introduction/what-is-finops/
7. NIST, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile,” NIST AI 600-1. 生成AIを導入・運用・評価する際のリスク管理を整理した公式資料。
   https://doi.org/10.6028/NIST.AI.600-1
8. Rui Software, 「『ROIはいくら？』と聞かれて慌てないために——生成AIの効果を数字で説明する6段階」. 生産性を便益・TCO・リスクへ分解する実務上の関連資料。
   https://rui.primasm.com/logs/genai_roi_explanation_workflow