半導体・電力・通信・利用企業へのつながり

計算の需要が設備へ届くまで

AIサービスの利用が増えた場合でも、最初は既存設備の空き能力で処理されるかもしれません。追加の計算機が必要になって初めて、演算部品、記憶装置、ネットワーク機器などの調達につながります。さらに部品を作る企業が工場を増やすときに、製造装置や材料への需要が発生します。利用者数の増加から、すべての供給企業の売上へ一度に矢印を引くのではなく、途中の判断を分けて考えます。

計算機の中にも、演算の速さ以外の制約があります。必要なデータを記憶装置から届ける速さ、複数の部品を結ぶ仕組み、発熱、電源の供給が全体の処理能力に関わります。ある一つの部品を高性能にしても、別の部分が追い付かなければ利用者に見える結果は変わりにくい場合があります。このような全体の中で最も強い制約を、ボトルネックと呼びます。産業のつながりを見るときも、どこが制約になっているかを先に考えます。

半導体メーカーや装置メーカーを調べる場合は、AIという用途だけでなく、その企業の部品がどの種類の設備で使われるかを確かめます。先端の演算部品と、電源制御用の部品、測定装置では顧客や投資の周期が異なります。LavaCareerの産業マップはこうした機能上の関係を整理するものです。図に企業名があっても、その組合せの企業が実際に直接取引していることまで示すものではありません。

参照資料：Energy and AIThe NIST Definition of Cloud Computing

施設は電力・通信・建設と一体で動く

データセンターには、安定した電力、熱を外へ逃がす設備、通信経路、施設の監視、部品の交換や保守が必要です。設備を置ける建物があっても、必要な電力や通信が同じ時期に整わなければ、予定どおりにサービスへ使えない場合があります。計画される床面積や建設費と、実際に利用できる計算能力を同じものとして扱わないことが大切です。建設から運用へ移る間に別の専門企業が関わります。

電力需要との関係では、総量と時間帯を分けて考えます。年間の使用量だけでなく、最大でどれほど必要になるか、変動の大きさはどうか、障害時の供給をどう確保するかも設備設計に関わります。環境面の説明では、設備効率の改善と、利用全体の増加を分けます。一件あたりの電力使用が減っても、処理量がより大きく増えれば、全体の使用量が減るとは限りません。効率の改善をそのまま需要減少と読まないようにします。

通信では、遠くの施設へデータを送る時間や容量が業務の条件になります。遅延が小さいことが必要な機器の制御と、夜間にまとめて処理する集計では、適切な計算の場所が異なります。端末に近い場所で計算するエッジと、大きな施設に集中する方式を対立する選択肢とせず、仕事のどの部分をどこで処理するかとして考えます。この分担は通信会社、機器会社、ITサービス会社の仕事の接点にもなります。

参照資料：Energy and AI責任共有モデル

利用企業の業務が最後の接続点になる

基盤が整い、モデルが使えるようになっても、利用企業の業務へ接続する作業は残ります。データの形式、利用者の権限、回答を受けて行う判断、誤りを発見したときの手順を決めなければなりません。ITサービス企業やコンサルティング企業が支援する場合も、現場の業務担当者や管理者との調整が必要です。技術を調達することと、業務を変えることを二つの仕事として見ると、参入企業の役割が分かります。

金融、医療、製造などでは、扱うデータ、止まったときの影響、説明を求められる相手が異なります。一般的な文章の生成で便利だった方法が、そのまま重要な判断を任せる仕組みになるわけではありません。AIを使った結果を誰が確かめるか、どの状態なら人へ戻すかを決める仕事も、産業間の接続を支えます。利用企業に専門家がいなくても安全に使える、という宣伝と、実際に必要な運用を分けて調べます。

企業研究の演習では、医療機器の保守記録を整理する架空の仕組みを描きます。機器から記録を集め、通信で送り、保存し、検索し、要約し、担当者が確認するという順序です。各矢印に、責任者、形式、失敗時の扱いを書きます。どれか一つの企業の製品だけでは説明できない部分が現れたら、それが関連業界を学ぶ入口です。業界のつながりを知る目的は、成長分野の名前を増やすことではなく、価値が届くまでの分担を説明することにあります。

参照資料：AI Risk Management Framework責任共有モデル

障害の経路から依存関係を見つける

業務アプリケーションが一時的に使えなくなった架空例を考えます。画面の不具合、利用者の権限、モデルの呼び出し先、計算基盤、通信、施設の電源など、停止の原因は複数の層にあります。利用者に見える症状が同じでも、原因と復旧の担当は異なります。企業間の依存を理解するには、正常時の機能の流れに加えて、異常時にどの担当者へ確認するかの経路も描くと有効です。

一つのサービスが複数の外部提供者を使っていても、そのうちどれか一つが止まれば全体が使えない構成もあります。外部提供者の数を増やすことと、障害に強くなることは同じではありません。代替できる範囲、データの共有、切り替える判断、切り替え後の品質確認が必要です。複数契約を持つことだけで業務継続が保証されると考えず、具体的な切り替え手順を確認します。

この事例を企業研究へ戻すと、顧客が評価する運用能力を考えられます。提供者が監視や復旧にどこまで関与するか、利用企業が自ら対応する部分は何か、支援の契約がどうなっているかを調べます。平常時の計算速度だけでなく、異常時にも仕事を続ける仕組みが、継続的な取引の理由になる場合があります。

利用者が困ったときの窓口が一つでも、裏側の責任者が一つとは限りません。顧客へ説明する担当と、原因のある設備を直す担当が違う場合があります。契約と技術の二つの地図を描いておくと、平常時のサービス説明だけでは見えない役割が分かります。

参照資料：The NIST Definition of Cloud Computing責任共有モデルAI Risk Management Framework