たとえば、小売企業が「店舗ごとの返品理由を毎日調べ、売り方や商品説明の問題を早く直したい」と考えているとする。ところが、調査のために人を置くほどの予算はない。月次の集計を眺めるだけで、個々の兆候は見過ごされている。
この仕事は、システムの発注書には載っていない。費用が見合わないと判断された時点で、案件になる前に消えているからだ。
AIで開発や分析の費用が下がったとき、SIerには、こうした仕事をもう一度検討する機会が生まれる。私が期待するのは、顧客が諦めていた業務を、実行でき、費用に見合うサービスに変えることである。
ただし、安く作れるようになれば、自動的に新しい予算が生まれるわけではない。誰が困っていて、何が改善し、誰が払うのか。そのつながりを作れるかどうかで、SIerの将来は分かれると思う。
AIに任せる仕事の大きさを、考え直す
この問いを考えるきっかけになったのが、Claudeの開発に携わるFelix Riesebergが2026年10月13日に公開した「How to be more ambitious: A tutorial for humans with models」だ。
Riesebergは、AI活用の野心をSpeed、Altitude、Depth、Rangeの四つに分ける。作業を速めることに加え、目的の抽象度を上げ、専門的な方法や生の情報まで掘り下げ、複数の分野に視野を広げるという整理である。結果をAI自身の評価だけで正当化せず、外部の手段で確かめることも求めている。
この整理を、SIerの提案に当てはめるとどうなるか。以下は、原文の分類を使った私なりの応用だ。
| 視点 | SIerが顧客と考える問い |
|---|---|
| Speed：速度 | 今の集計や開発を、どこまで速くできるか |
| Altitude：目的 | その集計によって、どの判断を改善したいのか |
| Depth：深さ | 集計値の背後にある記録を調べ、原因を確かめられるか |
| Range：広がり | システム、店舗運営、商品説明を一緒に変える必要はないか |
私がここから考えたいのは、AIへの指示が変わると、顧客が発注する仕事の範囲も変わり得る、ということだ。
集計表を作る依頼なら、価格は集計にかかる手間と比較される。返品による損失を早く見つけ、改善を続ける依頼なら、何を改善できたかが購買理由になる。扱うデータも、関わる部署も、契約の範囲も変わってくる。
以下の事業見通しと業務例は、公開資料を踏まえた筆者の仮説・提案である。原文が日本のSIer市場を予測しているわけではない。
発注書に載る前の仕事を見つける
既存の要件を同じ品質で安く実装する競争は、これからも続くだろう。富士通も2026年2月のAIドリブン開発基盤の発表で、人月ベースから顧客価値ベースへの転換を掲げている。ただし、これは同社の方針であり、業界全体の収益構造がすでに変わったという証拠ではない。富士通の発表
その先で、私が注目するのは、受注するまでの仕事だ。
従来の予算を前提に顧客が諦めていたことは、既存案件の見積もりを速くするだけでは見つからない。現場で何が後回しになっているかを聞き、実際の記録を見て、今なら採算が合うかを試す必要がある。
冒頭の例なら、「返品分析のシステムを作りませんか」と持ちかける前に、返品の原因が分からず困っている人と、その結果として発生している損失を確かめる。問題が店舗運営にあり、予算を持つのが商品部門なら、その二者をつなぐ仕事も必要になる。
作れること、使われること、対価が付くことは、それぞれ別の条件だ。
ここを飛ばすと、安い試作品は増えても継続契約にならない。しかも、小さな案件ほど、商談、データ接続、社内承認にかかる固定的な手間が重くなる。開発費だけが下がっても、営業と導入の費用が下がらなければ事業にはしにくい。
同じ業種の似た課題に対し、調査方法、接続方法、効果の測り方を再利用する。その蓄積があれば、これまで受けられなかった規模の仕事にも採算が合う可能性がある。
「返品レポート」を、改善が続く仕事へ変える
小売企業の例を、もう少し具体的に考えてみたい。これは実在企業の導入事例ではなく、サービス設計のための仮想例だ。
最初の段階では、返品理由を分類し、報告を作る。速くなった分だけ担当者の負担は減るが、報告を読んで判断する仕事は残る。
目的を引き上げるなら、異常がある商品や店舗を見つけ、対応する候補を絞るところまで扱う。ただし、返品率だけを見て原因を決めつけてはいけない。販売数、商品構成、キャンペーン、配送状況なども照合する必要がある。少数の販売に対する返品を、重大な異常と誤認することも避けたい。
さらに、返品の理由を商品説明や店舗での案内と突き合わせる。説明を変えるべきなのか、検品を変えるべきなのか、配送を調べるべきなのか。改善案が出たら、担当部門が実施を判断し、変更後の結果を確かめる。
この一連の仕事を支えるには、AIによる文章生成に加え、データ分析、業務設計、実装、効果測定が要る。異なる分野の肩書きをAIに演じさせるだけでは、その能力を得たことにはならない。必要な方法を選び、検証できる人が関わることが前提になる。
効果の測定にも工夫が要る。返品が減っても、単に売れなくなっただけかもしれない。返品率とともに販売や利益、問い合わせの変化を見る。比較できる店舗や期間を設け、季節性や同時期の施策による影響を切り分ける。切り分けられなければ、AI導入の成果として言い切らない。
ここまで設計できれば、SIerが提供する仕事は、レポートの納品から、問題の発見、対応、検証を繰り返す運用へ広がる。顧客が払う理由も、その運用が生む改善として説明しやすくなる。
成果への期待を、採算の合う契約にする
もっとも、「業務成果を売る」と言うだけでは、SIerの収益は安定しない。
販売や利益は、商品、天候、競合、顧客側の実行にも左右される。SIerが動かせない要因まで引き受けると、成果報酬は大きな不確実性を抱える。発見した問題への対応を顧客が見送った場合も、同じ報酬条件でよいのかを考える必要がある。
私は、最初から全面的な成果報酬にするより、段階を分けたサービスが現実的だと考える。
- 調査に対する対価：対象業務と使えるデータを調べ、改善の余地と実現条件を確かめる。進める価値がないと判断できることも、この段階の成果に含める。
- 導入に対する対価：対象を絞って実装し、合意した条件で動くことを確かめる。必要なデータ整備や担当部門の作業も見積もりに含める。
- 継続運用に対する対価：監視、検証、例外対応、改善を続ける。測定と帰属に合意できる部分では、成果に連動する料金も組み合わせる。
月額にすればよいという話でもない。問い合わせ、例外処理、モデル更新への追従が増えれば、固定料金のまま原価だけが膨らむ。対象業務、処理量、応答時間、追加変更の扱いを具体的にし、どこから料金や範囲を見直すかを決めておく必要がある。
見るべき採算は、AIの利用料と開発費だけではない。顧客側に残る確認作業も含めた費用である。
GoogleのDORAが2026年3月に公開した分析は、Googleのソフトウェアエンジニアによる1,110件の自由記述回答を調べ、生成で節約した時間が検証に移る負担を取り上げている。日本のSIerに同じ大きさの効果が出ると示す研究ではないが、生成時間だけでは生産性を測れないことを考える材料になる。DORAの分析と調査範囲
顧客が毎日AIの報告を大量に確認しているなら、その負担もサービスの成績に入れるべきだ。売りたいのは、確認すべきものが増え続ける仕組みではない。
市場が広がっても、SIerが選ばれるとは限らない
諦めていた仕事が実現可能になったとして、その売上がSIerに来る保証はない。標準的な業務ならSaaSの追加機能で足りるかもしれない。競争力の源泉となる仕事なら、顧客が自社で開発する方がよい場合もある。
AIを動かす汎用部品も、すでに公開されている。たとえばLangGraphには、処理を一時停止し、入力を受けて再開する仕組みと、その公開コード・テストがある。こうした部品の存在を踏まえると、「エージェントを動かせます」という説明だけで差を付け続けるのは難しいと私は考える。LangGraphの公式仕様、中断・再開の公開テスト
導入時には、採用する版の修正状況を確認し、認証、顧客ごとのデータ分離、保存期間、障害時の復旧を検証する必要がある。こうした保守も、サービスを提供し続ける費用に含まれる。
SIerが選ばれる余地は、複数のシステムと部署をまたぐ課題を解き、顧客の環境で継続して結果を出せるところにあるだろう。ただし、複雑さを維持して収益を得ようとすると、顧客は標準化や内製を選びたくなる。
再利用できる業務の型を持ち、個別対応を減らし、必要なら顧客へ引き継げる。それでも任せた方が得だと思ってもらえることが、継続契約を支える。
実装の選択も、この考え方に沿う。既存SaaSや定型的な処理で十分なら、それを使う。不確実な判断や探索が必要な部分にAIを使い、独自開発は顧客固有の価値がある部分に絞る。Anthropicも、エージェント設計では必要な複雑さを見極め、単純な構成から始める方針を示している。Anthropicの設計指針
これからの競争は、需要を見つける力でも分かれる
私が想定するのは、AIの普及に伴って、次の動きが並行して進む未来である。
既存の開発案件では、効率化を前提とした価格や納期が比較される。新しい業務では、何を実現すると価値があるかを見つけた会社が、発注書のないところから案件を作る。そして、よく似た課題が繰り返される領域では、SaaSや業種別サービスへの集約が進む。
この見立てが成り立つには、AIを含む総費用が下がり、必要な品質で運用でき、顧客側も業務を変えられることが必要だ。データの整備や確認にかかる費用が下がらなければ、小さな需要は案件にならない。標準製品で十分に解けるようになれば、需要が増えても個別開発の売上は伸びないかもしれない。
だから、成長を確かめるときには、AIの利用率や生成したコード量だけを見たくない。これまで予算が付かなかった仕事が有償契約になったか。その顧客が継続しているか。同じ種類の次の案件では、導入と運用の費用が下がっているか。このあたりに注目したい。
SIerの経営にも変化が要る。担当者の稼働を埋めることだけを評価すると、将来の顧客を見つける調査や、次の導入を安くする共通化に時間を割きにくい。AIで空いた能力を、次の需要を確かめる活動へ回す判断が求められる。
次の顧客訪問では、必要なシステムを聞くことに加え、こんな問いを置いてみたい。
本当は続けてやりたいのに、費用や人手を理由に諦めている仕事は何ですか。
そこで出てきた話を、すぐに大きな構想へ膨らませる必要はない。一つを選び、実際の記録で問題を確かめ、小さく試し、続ける価値を測る。
顧客の期待を広げ、その期待が現実の利益になるところまで確かめる。 AI時代のSIerには、この仕事を新しい事業に育てる余地がある。
工数削減が売上や利益にどう効くかは、AIで開発が100倍速くなったら、SIerの売上は100分の1になるのかで整理した。実際に業務を任せられる範囲の設計については、SIerの次の商品は企業がAIに任せられる範囲であるもあわせて読んでほしい。
公開資料の確認日：2026年10月15日。企業発表・調査の内容と、筆者による事業仮説を分けて記述した。市場規模や個社の業績を定量予測するものではない。
WRITTEN BY
コメント