AIへの投資は「どこかから奪う」しかない

予算が増えない中でAIプロジェクトの資金を確保する、これは、ITリーダーの判断力を試す課題となっている。予算制約はこれまでも存在したが、Cレベルの経営層や取締役会からAIを最優先にせよというプレッシャーが加わり、ITリーダーは極度の緊張にさらされている。資金の再配分、システム更新の先送り、ベンダーやツールの統合——リスクとイノベーションのバランスを保ちながら、あらゆる手段を講じなければならない。

「AIへの支出は予算の増加スピードをはるかに上回っている。CIOたちは資金を『見つけている』のではない。他のどこかから『奪っている』のだ」と、Twisted ConsultingのファウンダーでAI・ビジネスオペレーションコンサルタントのKayla Williams氏は言う。「今AIに投じられている資金は、ほぼ例外なく、すでに計画されていた何かの予算を奪っている。それが不都合な真実だ」。

調査会社ISGのディスティングイッシュドアナリスト兼ディレクター、Alex Bakker氏は、優先順位の選択が困難なトレードオフを生んでいると指摘する。「AIを拡大したい組織は、わずかな予算成長分をほぼすべてAIに充てるか、内部予算を再配分するかしかない」。再配分には時間もかかり、古いアプリの廃止や技術的負債の解消といった措置が必要になるという。

Williams氏によると、最も多いパターンは、AIを優先するために長期的な最適化プロジェクトを先送りにするケースだという。「インフラの整理、システムの再構築、緊急でないプラットフォームのアップグレードは、すぐに事業インパクトが見えないという理由で後回しにされている。これらのプロジェクトは重要だ。しかし予算が逼迫すると、短期的な効率化や人員削減を約束するAIが優先される」。

削り方にも変化が見られるようだ。「将来を見据えた完璧な設計より、今すぐ使えるものを——そんな割り切りが広がっている。CIOは規模を絞り、統合も最小限に、カスタマイズも後回しにしてAI展開にゴーサインを出している。技術的負債が積み上がることはわかっている。それでも今は、前に進むしかないというのが現実だ」。

「1四半期で成果を出せなければ凍結」——判断基準を明確に

ビデオ監視技術メーカーIC RealtimeのCTO、Andrew Nassar氏の判断基準はシンプルだ。即座に業務効率の改善を証明できないツールは採用しない。成果が出なければ「凍結」し、判断は原則1四半期で下す。

実際に凍結されたのが、カスタマーサポート向けのチャットボット導入案件だ。パイロットでは顧客がサポート記事にたどり着けず、問い合わせ電話がむしろ増えた。立ち上げには数十万ドルが必要な上、維持・設定・プログラミングを担うチームも別途必要だった。

「（チャットボットプラットフォームを導入し、）スイッチを入れれば動くというものではない」とNassar氏は言う。先送りの判断は予算だけでなく、複雑性とリスクが理由だった。

「AIに1ドル使うなら、どこか別の場所で1ドル削る」——ゼロサムルール

データプラットフォームプロバイダーのUnidataのデータ収集チームリード、Hanna Parkhots氏は徹底的な削減を実施した。データ検証ソフトの予算を40%カット、3つのプロジェクト管理ツールを1つに統合し、年間約4万7000ドルを捻出。AIベースの品質管理ソフトを導入し、データ分析速度を73%向上させた。

最も苦しかったのは、データアナリスト契約社員の予算を30%削減したことだ。約8万5000ドルをAIソフトウェアに充て、残ったスタッフを補完する形にした。災害復旧テストを四半期から半年に変更し、約1万2000ドルも節約した。

「AIに1ドル使うなら、どこか別の場所で1ドル削る」——Parkhots氏はこのルールを社内に徹底している。「習慣でやっていることと本当に価値があることを見直す、ゼロサムゲームだ」。

インフラ投資を12〜18カ月先送り——浮いた予算をAIへ

デジタルマーケティング会社Helium SEOのCTO、Paul DeMott氏は、サーバー容量の拡張とネットワーク改善を12〜18カ月先送りにした。「既存インフラで十分だったから」というのが理由で、IT年間インフラ予算の約30%をAI開発とAPI費用に充てることができた。サーバーは容量の限界近くで稼働しているが、「AIツールが生み出す価値は、パフォーマンスの微改善を上回る」と言う。

DeMott氏はさらに、AIと直接関係のない新機能開発も棚上げにした。「ユーザー体験を段階的に改善する予定だった機能をエンジニアリングリソースのAI統合に充てた。遅延した機能について顧客から問い合わせがあったが、AIツールの可能性を示すと好意的な反応だった」。

ジュニアが上級職の仕事をこなす——リソースモデルの再定義

プロフェッショナルサービスプラットフォームプロバイダーKantataのCISOおよびデータ保護責任者、Taison Kearney氏は、AIが従来のリソースモデルを変えられるかどうかを検証している。具体的には、これまで上級職が担っていた業務をジュニア・低コストの人員がこなせるようになるかどうかだ。「そのシフトがコスト方程式を大きく変え、AI投資の増加を相殺できる」と言う。

同社では社内AIカウンシルを設立し、組織横断的なアイデアを集めている。ツール要件、総投資額、推定ROI、ビジネスケース、内部開発・変更管理の必要量といった一貫した基準で各アイデアを評価する。Kearney氏はこう強調する。「アプローチは単に『予算を増やす』ことではなく、AIが最大の効率改善と測定可能なROIをもたらせる分野に投資を再配分することだ。限られた予算を実験的な取り組みに分散させるのではなく」。

ベンダー統合と契約再交渉——AI費用を捻出するもう一つの手段

AIの普及に伴い、ベンダーの統合と契約の再交渉も進んでいると先述のコンサルタント、Williams氏は指摘する。「重複するツールを積極的に削減し、ライセンス数を減らし、更新を遅らせることでAIプラットフォームやサービスのための余地を作っている。AI支出は、これまで手いっぱいのチームが吸収していた手作業の代替として正当化されるケースもある」。

IC RealtimeのNassar氏は既存のツールスタックを活用してAIプロジェクトに対応し、必要に応じてサブスクリプションを小幅に増やす戦略をとる。「小さく始めて、パイロットが結果を出したらスケールアップする」という考え方だ。今年のAI予算はIT予算全体の5〜10%程度で、来年は倍増か3倍になる見込みだという。

Helium SEOのDeMott氏はさらに踏み込み、ツールスタックを「積極的に」削減・統合してサブスクリプションコストを約40%削減。その節約分をAIプラットフォームとエンジニア採用に充てた。現在のベンダーとは契約を再交渉して好条件を引き出した。

本当のリスクは「何を先送りにするか」ではない

International SeawaysのCIO兼CISOのAmit Basu氏は、問題の本質は別のところにあると指摘する。CIOが苦労しているのは予算の確保ではなく、ガバナンスやリスクへの配慮なしに急速なAI導入を求める経営幹部や取締役会への対応だというのだ。

「既存のKPIはアウトプットを測るが、学習速度やモデルの成熟度、リスクの発見といった指標は測られていない。速く動いているように見えながら、実際の進歩を遅らせている組織がある」とBasu氏は言う。即座のROIが出なければ「失敗」と判定されるパイロットも多く、CIOの本当の課題は予算ではなく「組織が責任を持って対応できる以上のスピードで動くよう求められること」だと言う。

「本当のリスクは、何を先送りにするかではない。適切なガードレールなしにAIが導入されているかどうかだ」。同社ではAI導入の前にインフラ、データプラットフォーム、セキュリティへの投資を優先するケースもある。「AIは、組織が長年必要としていた投資を促す触媒になっている」。

AIに乗り遅れることの方が、大きなリスク

AIの速いペースが予想外の難しさをもたらしているとNassar氏は言う。「来週どんなツールが出るかわからない。それが怖い部分だ」。同時に、AIの加速は無視できない現実だとも認める。「選択肢はない。（AI投資は）人類史上最大の設備投資になるのではないか」。

CIOたちの予算判断は軽々しく行われているわけではないとWilliams氏は言う。「ほとんどのCIOは、今の安定を将来の競争力と引き換えにしているとわかっている。それでも動くのは、AIに乗り遅れることの方が、他のイニシアティブを先送りにするよりもはるかに大きなリスクだからだ。今後れをとれば、追いつくコストは今の比ではない」

アーキテクチャ選定の基準が違う

日米のSIを技術面で比べるとき、まず押さえるべきは「何を正解とみなすか」の基準だ。日本のSIでは、長期運用と安定稼働を前提に、障害時の影響範囲が読みやすい構成、監査や手続きが通りやすい構成、運用負荷が予測しやすい構成が選ばれやすい。これはミッションクリティカルなシステムを多く扱ってきた歴史の延長であり、止めないことが最大の価値である環境では自然な選好でもある。

米国のSIでは、クラウドのマネージドサービスを前提に、拡張性と変更容易性を優先する設計が前面に出やすい。もちろん安定稼働は最重要だが、その安定を「事前に作り込み過ぎて守る」のではなく、「計測し、復旧し、改善し続ける」ことで担保する思想が強い。たとえば、単一の強固なシステムにまとめるより、疎結合なサービスとして分割し、障害の隔離や部分的な更新を可能にする。結果として、初期の設計段階から運用の計測や自動化が組み込まれ、アーキテクチャの評価軸に運用指標が入りやすくなる。

この違いは、オンプレかクラウドかという単純な話ではない。日本でもクラウドは普及し、米国でも規制や要件でオンプレやハイブリッドを選ぶ。差が出るのは、技術選定の場で誰が何を判断材料にし、どこに不確実性を許容するかだ。日本では要件を固めて最適解を選ぶ方向に寄りやすく、米国では不確実性を残したままでも動かしながら学習する方向に寄りやすい。ここが、後述する開発プロセスの差にも直結していく。

---

開発プロセスの中心にあるものが違う

日本のSIが得意としてきたのは、工程を定義し、レビューとテストを積み上げ、品質を管理して納期通りに提供するやり方だ。工程ごとの成果物が明確で、関係者が多くても合意形成を取りやすい。品質の考え方も、仕様への適合と例外処理の網羅、障害の未然防止に重心がある。これは大規模案件で強い。変更が少ないほど強く、変更が多いほど苦しくなる、という性格を持っている。

米国のSIが得意としやすいのは、短いサイクルで価値を届け、実際の利用や運用データから学び、次の改善に反映するやり方だ。ここでの中心は、工程よりもフィードバックループにある。仕様が完全でなくても動くものを早く出し、使われた結果を見て優先順位を変える。そのため、プロジェクト管理も「計画を守る」より「価値が出る方向へ舵を切り続ける」ことに重心が置かれる。

このプロセス差は、アジャイルかウォーターフォールかという言葉の対立で語られがちだが、実際にはもっと深い前提の違いがある。日本の現場は、品質と責任を守るために合意形成を厚くし、合意の外側にある変更を例外扱いしやすい。米国の現場は、変更を織り込み、変更を管理することで責任を果たしやすい。前者は「確定したものを確実に作る」ことに強く、後者は「確定できないものを確かめながら作る」ことに強い。どちらの局面なのかを見極めないと、手法だけ移植しても摩擦が増える。

---

DevOpsと運用自動化の位置づけ

日米の差が特に出やすいのが、DevOpsと運用自動化の扱いだ。日本のSIは運用に強い一方、運用は「守りの仕事」として位置づけられ、開発と運用の役割が組織的に分かれやすい。結果として、運用の都合で変更が慎重になり、開発は運用に配慮して手続きを増やし、リリースが重たくなることがある。これは責任を果たすための合理でもあるが、変化の速度を求められる領域では足かせにもなる。

米国のSIでは、運用は「価値を作るための継続活動」として扱われやすい。CI/CDやInfrastructure as Code、監視とアラート、ログとトレース、インシデント対応の訓練などが、最初から設計に含まれ、運用の成熟度がプロダクトの競争力に直結するという考え方が強い。運用の目的は、障害をゼロにすることだけではなく、障害が起きても早く検知し、早く復旧し、再発を防ぎ、コストを最適化し続けることへ広がる。つまり、運用の強さがスピードを支える。

日本のSIが持つ運用の強みは、実はDevOps的な方向へ伸ばしやすい資産でもある。強い運用文化があるからこそ、計測と自動化と改善のサイクルを組み込めば、安定と速度の両立が可能になる。ただし、そのためには、運用を「後工程の受け手」に固定せず、開発段階から運用設計を一体化する必要がある。運用手順を増やして安全を担保するのではなく、自動化と可観測性によって安全を担保し、変更の頻度を下げずに守る、という発想転換が求められる。

---

セキュリティとコンプライアンスの統合

セキュリティや監査対応は、日米ともに最重要だが、プロセスへの埋め込み方に違いが出やすい。日本のSIでは、セキュリティは要件として定義され、レビューやテストで確認し、監査に備える、という流れになりやすい。慎重で堅い反面、セキュリティ確認が開発の後半に寄ると、最後に大きな修正が発生しやすい。結果として、セキュリティが「遅くする要因」として感じられ、現場の心理的摩擦が生まれることがある。

米国のSIでは、DevSecOpsの考え方が比較的浸透しており、コードの静的解析や依存関係の脆弱性チェック、設定のポリシー管理などを、パイプラインの中に組み込みやすい。セキュリティレビューを人の手続きだけに頼らず、ツールと自動化で「守る速度」を上げる発想が強い。さらに、権限管理や鍵管理、監査ログの設計などが、運用の計測と同様にアーキテクチャの評価軸に入るため、設計段階から統合されやすい。

ここでも重要なのは、セキュリティ重視かどうかではなく、セキュリティを速度と両立させるための構造を持っているかだ。日本のSIは、手続きを丁寧に積み上げる強みがある。その強みを活かしながら、自動化できる検査を自動化し、レビューの焦点を「人にしか判断できない部分」に寄せることができれば、セキュリティを高めつつスピードも上げられる。セキュリティはブレーキではなく、安心して速く走るための仕組みとして扱えるようになる。

---

レガシー刷新の進め方が違う

技術選定とプロセスの違いが最も難しく表れるのが、レガシー刷新、いわゆるモダナイゼーションだ。日本のSIは、既存システムの複雑な業務要件と運用実態を理解し、置き換えに伴うリスクを丁寧に管理することに強い。だからこそ、大規模な刷新では、段階移行の計画、データ移行の整合、周辺システムとの接続、運用引継ぎなど、失敗が許されない論点を網羅しやすい。

米国のSIでは、段階的に価値を切り出しながら移行する進め方がより強調されやすい。既存を一気に置き換えるより、外側から機能を剥がし、API化し、徐々に新しい側へ移す。ここでの狙いは、学習しながら移行し、途中でも価値が出る状態を作ることにある。移行の途中でアーキテクチャや優先順位を変えることを織り込み、投資対効果を見ながら進める。

日本でモダナイゼーションが難しくなりがちなのは、レガシーの理解が深いがゆえに、最初から完全な移行計画を作ろうとしてしまう点にある。もちろん計画は必要だが、計画に時間をかけ過ぎると、移行の価値が出る前に環境が変わる。逆に米国型の進め方をそのまま持ち込むと、ガバナンスや監査、業務の安定を軽視しているように見え、関係者の合意が取れない。両者をつなぐ鍵は、段階移行を前提にしつつ、各段階で品質と運用の要件を満たす設計を最初から織り込むことだ。日本のSIの強みは、ここで活きる。

---

日本SIが「強みを活かして速くなる」方法

日米の差を埋めるために、日本のSIが米国のやり方をそのまま真似る必要はない。むしろ、日本が得意な品質と運用の強さを維持したまま、速度を生む構造を足していくほうが現実的だ。ポイントは、現場の頑張りで速くするのではなく、標準化と自動化で速くすることにある。

標準化とは、個別案件の事情を無視して共通化することではなく、共通化できる部分を切り出して再利用可能にすることだ。設計の型、環境構築の型、テストの型、監視の型、障害対応の型を整備し、プロジェクトの立ち上がりを速くする。自動化とは、運用の安全を手続きで担保するのではなく、ツールと仕組みで担保することだ。レビューを無くすのではなく、機械的なチェックを自動化して、人が見るべきポイントに集中する。リリースを減らすのではなく、小さく安全に頻繁に出せるようにする。ここにDevOpsと可観測性が効いてくる。

さらに、速度を出すには意思決定の設計も欠かせない。短いサイクルで価値を出すには、優先順位を決める責任者が必要で、変更の判断を迅速に行える体制が必要になる。日本のSIは、合意形成を丁寧に作る力がある。その力を、意思決定を遅らせる方向ではなく、意思決定に必要な材料を早く揃える方向へ使えるようになると強い。品質を守るために止まるのではなく、品質を守りながら進める仕組みを作る、という方向だ。

日米SIの技術とプロセスの差は、結局のところ「変化を前提に設計しているかどうか」の差として現れる。日本のSIが持つ安定と品質の強みは、変化に弱いことと同義ではない。変化を管理し、計測し、自動化し、改善し続ける構造を組み込めば、安定はむしろ速度の土台になる。止めない力を、変え続ける力へ接続する。それが、クラウド以降の時代に日本SIが発揮できる、最も実務的で再現性の高い進化だ。