戦争とエネルギー価格高騰にAIバブル崩壊が追い打ちをかけるかもしれない

　 私が思うに，いま世界経済において最も懸念されるのはイランを起点とする戦争の拡大による混乱であり，次いでそれが何とか避けられた場合でも続きそうな，原油とそれに連動したエネルギー全般の価格による景気後退である。

　しかし，石油にばかり目を奪われている場合ではない。トランプ政権がイランを攻撃する以前から，AIバブルの崩壊が懸念されているからだ。AIは本質的にハードウェアでなくソフトウェアであるが，これを用いてクラウドサービスを行うためにはデータセンターを必要とする。伊豆久氏のレポートによれば，アマゾン，メタ，マイクロソフト，アルファベットはソフトウェア・情報サービス企業のはずなのに，近年設備投資を急速に増やしている（アップルはそれほどでもない）。ところがOlivia Wang氏のレポートによれば，アメリカにおけるデータセンター建設計画は，主に電力がボトルネックとなって着工が遅れており，その計画の30～50％は年末までに稼働開始に至らない可能性が高いというのである。これはイラン攻撃の前の話であることにも注意してほしい。

　これまでも工場や光ファイバーケーブルに対して起こったように，データセンターと，それに電力を供給する電力産業に過剰投資が起こっていないのか。AIはどのみち発達する。AIが人間社会に何をもたらそうと，このビジネスチャンスが見過ごされるはずはない。しかし，アメリカを中心にエクイティを用いてファイナンスされる新興産業は，ブームと破裂を繰り返しながら成長する。それが歴史の教訓だ。次回の破裂は迫っていないのかを，よく観察する必要がある。戦争，エネルギー価格高騰にAIバブル崩壊が追い打ちをかける可能性に注意しなければならない。

Olivia Wang, Data center outlook: half of 2026 pipeline may not materialize, Sightline Climate, February 24, 2026. 
https://www.sightlineclimate.com/research/data-center-outlook

伊豆久「米国IT企業のデータセンター投資と各社の財務構造」『証研レポート』1753号，2025年12月。
https://www.jsri.or.jp/publication/periodical/report/1753_02/

あまりにも機能しないIT業界の多重下請けシステム

　IT業界における多重下請けシステムの機能不全が指摘され始めたのはいつからなのだろうか。アプリの世界ではすでにアジャイル開発が普通になっているのに，SIerを頂点とするシステムベンダーの世界はあまりに変わっていないように見える。
　多重下請けは製造業にも存在するし，ユーザーや元請けの側に交渉力があって下請けの負担が重いことは，日本のどこでも同じである。しかし，自動車部品などでは系列・下請け関係の中で製品のQCDと産業競争力が向上し，また1次サプライヤーが設計開発能力，さらには研究開発能力を磨いてきたことも事実である。IT業界は今後の産業構造変化をリードする立場なのに，QCDの面で下請けの負の側面ばかり目に付く。どうしてこうなるのか。学部の講義で系列・下請けの構造と変容を扱っているが，それは主に自動車部品を対象としており，いわば機能している下請けの話である。それと対比する意味で覚書にしておきたい。
　ひとつはユーザー側のIT部門が弱い。記事にもある通り，ユーザーの側で投入労働量が平準化できないことと終身雇用慣行の矛盾があって，人数をぎりぎりに絞っている。さらに社内および役所内でのIT部門の立場が弱く，ビジネスプロセス全体をITを使って変革する主導権を持たされていないし（国立大学大学で言うとハンコを失くす業務改革権限を持たされていないとか！），最悪，ビジネスプロセスがわからないのに要件定義をして発注する。その発注が開発コンペになっているのかどうかがよくわからない。役所では競争入札をして価格で決定しているのではないか。
　ここで元請けたる1次ベンダーがしっかりしていればいいのだろうが，1次ベンダーも人数をぎりぎりに絞っているために外注することになる。以下同じ。つまり，外注を「専門家に頼む」のではなく「投入工数の調整」を主要因として行っている。なので，本来ワンチームで行った方が効率的かもしれないところまで分割して外注し，ウォーターフロー式で開発する。そして，仕事があれば出し，なくなれば切るので，金の切れ目が縁の切れ目になりやすい。
　ウォーターフロー式とは開発の流れ作業であるから，仕様が確定していて不確実性がない場合は機能する。ところが，仕様変更，設計変更が頻繁に生じる。そこには，アプリの世界はもともと開発しながら新しいことを考え，使用も設計を変更していった方がよいものができるという積極的要因と，ユーザーの力がなくて要件定義のところが詰められていないという消極的要因がある。後者もあるとはいえ，アジャイル方式とオープンソースならば開発者の創意工夫によって提案され，開発プロセスにすぐ反映される。しかし，ウォーターフォール式かつ多重下請けなので，二つの欠点が起こる。一つは修正に時間と手間ばかりかかること。もう一つは，元請けから下請けへの一方的押し付けを通して変更が実行されることだ。コストは下請け持ちである。
　ユーザーと1次ベンダーの開発能力が量・質ともに低いということは，ユーザーとつきあい，1次ベンダーと付き合っても働かされるだけで勉強にならないということである。そしてアプリの世界ではユーザーと直接接していないとよいものがつくれない。なので，下請けシステムには学習機能がうまく働かない。
　それでもユーザーが1次ベンダーに発注して多重下請けに頼るのは，開発者が名目上は大手でないと不安だとユーザーが判断するからだ（『日経』の方の記事参照）。1次ベンダーは大手企業であり，トラブルに対する耐久力が強い。だから受注できる。仕事の質ではなく，規模によって受注できてしまうのだ。

シェア先
中島聡「なぜ、日本政府が作るソフトウェアは使えないモノばかりなのか？」MAG2NEWS，2020年6月3日。
https://www.mag2.com/p/news/453485

「コロナ接触確認アプリ、導入1カ月遅れの曲折」『日本経済新聞』2020年6月1日。
https://www.nikkei.com/article/DGXMZO59771810Z20C20A5TJC000/