「AIバブルがはじけるのでは」という話が、投資家向けの議論だけで終わらなくなってきました。理由はシンプルで、資金・電力・設備という現物の制約が、いまの拡大ペースと正面からぶつかり始めているからです。ゴールドマン・サックスは、データセンターの電力需要が2030年までに大きく伸びうる、という見通しを公表しており、電力インフラがボトルネックになり得るという議論は産業側でも現実味を帯びています（AI to drive 165% increase in data center power demand by 2030 | Goldman Sachs）。マッキンゼーも、AIワークロードとハイパースケラーの戦略が電力・立地・供給網の制約とセットで動いていく、という整理を示しています（The next big shifts in AI workloads and hyperscaler strategies | McKinsey）。

ここで誤解しやすいのは、「AIが終わるかどうか」です。ドットコム・バブルのあとに消えたのは「インターネット」ではなく、持続する収益構造を作れなかった物語のほうでした。検索、EC、クラウドのように業務の骨格に刺さった基盤は残りました。AIも同じで、熱狂の反動が来たとしても消えるのは「デモが派手なだけ」の導入であり、コスト・遅延・ガバナンス・運用に耐えた実装は残ります。

この記事では、巨大モデル中心の競争が一段落したあとも、現場のエンジニアに残る論点を「スモールAI」と配置設計の観点から整理します。関連して、エージェント型AIの本質や責任ある実装の話は別稿で扱っています（Qiitaの投稿一覧（mhamadajp））。

なぜ「どのAIが一番賢いか」だけ追うと危ないのか

いまの現場では、プロトタイプ段階ではクラウドの汎用モデルを叩けば一気に進みます。しかし本番に近づくほど、課題はモデルの頭の良さから単位経済と制御に移ります。トークン課金が積み上がる、レスポンスが遅くてUXが壊れる、ログと個人情報の境界が監査で突かれる、障害時に誰が止めて誰が説明するのかが曖昧になる——こうした問題は、賢いモデルを1つ足しただけでは解けません。

つまりIT技術者に求められるのは、モデル比較の趣味ではなく、1リクエストあたりいくらで、何ミリ秒で、どの品質を出すかを設計に落とす力です。ここができるチームは、バブルのあとも「AIを使えるチーム」ではなく「AIを運用できるチーム」として評価されやすくなります。

Big AIとスモールAI——二極化は「対立」ではなく「役割分担」です

これからのAIは、ざっくり二つの居場所に分かれていきます。

クラウドで伸びる「Big AI」

OpenAIやGoogleのように、巨大な汎用モデルをクラウドで提供し続ける流れは、複雑な推論、広い知識、マルチモーダル処理、企業横断の共通基盤として引き続き強いです。PoCから本番への橋渡しとして、まずここに乗るのは合理的な場面が多いでしょう。

手元と社内に寄る「スモールAI」

もう一方は、端末内や社内環境で動かすスモールAIです。万能ではありませんが、用途を絞ることで速さ、コスト、データの持ち出しリスク、運用の単純さという強みが出ます。ここが「劣化版」ではない理由は、現場システムの多くが数百ミリ秒や数円の差で成立か不成立かが決まるからです。

NVIDIAの研究側も、エージェント用途におけるスケーラビリティの観点から小型言語モデル（SLM）の位置づけを整理しており、レイテンシやコスト面での現実的な利点を説明しています（Small Language Models are the Future of Agentic AI | NVIDIA Research、How Small Language Models Are Key to Scalable Agentic AI | NVIDIA Technical Blog）。GPU企業自身がSLMの話を前面に出すのは、市場が「大きいほど正義」だけでは動かないことを示すサインでもあります。

プラットフォーマーが示す方向——「全部クラウド」からの撤退ではなく「最初は手元」

スモールAIが注目される理由を、きれいな理想論だけで語ると現場に刺さりません。泥臭い要件のほうが説得力があります。

プライバシーとデータ境界

GoogleはGemini NanoをAndroidのAICore上で動かし、オンデバイス推論の基盤として位置づけています。開発者向けドキュメントでは、AICoreがデバイス上での基盤モデル実行を担うこと、オンデバイス処理によるプライバシー上のメリットが説明されています（Gemini Nano | Android Developers）。ML KitのGenAI APIに関するブログでも、オンデバイス実行の文脈が繰り返し強調されています（On-device GenAI APIs as part of ML Kit | Android Developers Blog）。

MicrosoftはPhi Silicaを、WindowsのCopilot+ PC向けにデバイス上で動く小型言語モデルとして説明しています（Phi Silica, small but mighty on-device SLM | Windows Experience Blog）。Learn上のプラットフォーム概要でも、NPU上の実行や低遅延用途が明記されています（Platform card - Phi Silica | Microsoft Learn）。

AppleはApple Intelligenceでオンデバイス処理を基本とし、より重い処理が必要な場合にPrivate Cloud Computeへ拡張する設計を公開しています（Introducing Apple Intelligence | Apple Newsroom）。プライバシー設計の説明はセキュリティ研究のブログでも詳しく読めます（Private Cloud Compute | Apple Security Research）。

これは「クラウドが悪い」という話ではありません。最初に手元で処理できる設計に寄せたほうが、ユーザー体験とデータ統制の両方で勝ちやすい、という判断が大手にも見えます。

レイテンシが業務を殺すとき

あなたがWebバックエンドを書いているなら、体感として分かるはずです。チャットUIなら数秒待てても、入力補助、端末内検索の前処理、監視アラートの一次分類、コールセンターのリアルタイム提案、医療現場のメモ下書き、製造ラインのエッジ判断では、待ち時間が積もると作業手順そのものが破綻します。ここではスモールAIが本命になりやすく、研究コミュニティでもエージェント文脈でのSLMの位置づけが進んでいます（先述のNVIDIA ResearchおよびTechnical Blog）。

コストが「トークン単価」だけでは測れないとき

SREやFinOpsの視点に立つと、APIの従量課金は入口に過ぎません。帯域、再試行、ガードレール、ログ保管、監査対応、インシデント時の切り戻しまで含めると、トラフィックが増えるほど周辺コストのほうが効いてくることがあります。だから現実的な構成は、「高難度だけBig AI、それ以外は小型モデル・ルール・キャッシュで吸収」に寄っていきます。Phi Silicaのような製品が低遅延・ローカル配置を前面に出すのも、この圧力の表れです（Windows Experience Blog、Microsoft Learn）。

ハードウェアとランタイムが変えた前提——「推論＝GPU必須」が一部崩れ始めた

モバイルエンジニアや組み込み寄りの読者には刺さる変化があります。ArmはSME2（Armv9系CPU向けの行列演算拡張）とKleidiAIを組み合わせてオンデバイス推論を加速する、という説明を公開しています（Boost AI inference with SME2 and KleidiAI | Arm）。PyTorch側も、ExecuTorchとArm SME2を組み合わせたオンデバイス推論の高速化をブログで紹介しており、具体例としてインタラクティブセグメンテーションのレイテンシ改善が示されています（Accelerating On-Device ML Inference with ExecuTorch and Arm SME2 | PyTorch Blog）。

これが意味するのは、すべての現場でGPUクラスタが必須になるわけではない、ということです。CPU・NPU・量子化モデル・軽量ランタイムを組み合わせれば、スマホ、PC、エッジで「十分役に立つ」推論が増えます。インフラエンジニアにとっては、GPU不足のニュースばかり見なくてよい、という慰めではなく、配置の選択肢が増えるという設計上のラッキーです。

ここまで読んで「うちはまだチャットボットのPoCだよ」と思う読者もいると思います。実はPoCほど、あとで効いてくるのが配置の選択です。最初に「とりあえず一番大きいモデル」を選ぶと、デモは通りやすい一方で、利用ログが増えた瞬間に課金・遅延・データ持ち出しが同時に襲ってきます。要件は「賢さ」よりレイテンシ目標（p95）、1日あたりの想定リクエスト数、失敗時の許容挙動から書き出すと後工程が楽です。スモールAIは、その前提を満たす現実解として表に出てきています。

いまの職種から見た「明日の仕事」——具体例でつなげます

抽象論で終わらせないために、よくある役割ごとに当てはめます。

アプリケーションエンジニア（Web／API）

あなたがやっているのは、おそらくルーティング、認可、キャッシュ、レート制限、観測可能性の実装です。明日も同じですが、追加されるのはモデルゲートウェイの設計です。入力を受けたら、まず小型で分類し、PII（個人情報）が混ざるならマスキング、難易度が高いだけクラウドの大モデルへ、失敗時はルールベースへ戻す——この段階的デグレードをAPIとして実装できる人が強くなります。いまのBFFやAPI Gatewayの経験は、そのまま応用できます。

たとえば社内の問い合わせポータルなら、最初の一行目で「契約／請求／技術」のどれかを小型モデルか学習済み分類器で振り分け、添付ログの要約だけをオンデバイスまたはVPC内の小型で作り、顧客固有の解釈が要る最終回答だけをBig AIに渡す、という流れが現実的です。こうすると、トークンは減るだけでなく、誤回答の影響範囲も「最終段」に閉じやすくなります。ECのカスタマーサポートでも同型で、配送状況の照会はルールと検索で足り、感情が高ぶった長文だけ追加の推論に回す——全部を同じモデルに投げないことがコストと品質の両面で効きます。

モバイル／クライアントエンジニア

オンデバイス推論は、端末の発熱、バッテリー、モデル配布、OSバージョン差分といういつものクソみたいな制約とセットです。Gemini NanoやPhi Silicaのように、OS・SDKが用意する「公式の置き場所」に乗るか、自前でExecuTorch系に寄せるかはプロダクト戦略次第ですが、どちらにせよネットワーク無しで何ができるかが要件定義の中心に入ります（Android Developers、Microsoft Learn）。

現場イメージとしては、営業が顧客訪問中にメモを取るアプリなら、クラウドへ原文を送らず端末内で下書き整形だけ済ませ、確定送信は既存の同期基盤に乗せる、といった切り方が現実的です。オフライン時に「何もできない」ではなく、機密を持ち出さずにできることを先に決めると、UXの説明もセキュリティの説明も一本につながります。

データ基盤／MLエンジニア

特徴量パイプラインの近くに、小型モデルによる前処理やタグ付けが増えます。学習はクラウドでも、推論はVPC内やエッジに寄せる構成は、データガバナンスの都合で選ばれます。ここで問われるのは、精度だけでなく再現性、バージョン管理、監査ログです。いまのMLOpsの知識は、名前がGenerativeに変わっても半分はそのまま通じます。

夜間バッチで大量ドキュメントを要約・タグ付けする処理は、スループット優先でBig AIに寄せがちですが、日中のオペレーションが「その要約を検索して即返す」なら、検索インデックス側に小型の再ランキングやクエリ拡張を載せたほうが体験が安定します。同じ“要約”でも、作る工程と読む工程で最適な置き場所が違う、という発想が重要です。

SRE／プラットフォームエンジニア

可用性の物語は変わりません。変わるのは、依存先が「自社サービス＋外部API」になったことです。レート制限、サーキットブレーカー、フォールバック、コストアラート、キャパシティ計画は、これまで通り必要です。さらに電力・データセンター供給の制約は、クラウドの価格と提供リージョンの戦略にも影響しうるので、インフラのニュースを経営と同じテーブルで見る場面が増えます（両者の整理は、その前提を読む材料になります）。

金曜夕方に外部モデルAPIが遅延したとき、いまのあなたならキャッシュとキューで凌ぐはずです。AIでも同じで、「モデルが遅い」ではなく「ユーザー体験が破綻しない」 をSLOに置くと自然とハイブリッド構成に寄ります。スモールAIは、その“つなぎ”を安く作る部品になります。

セキュリティ／コンプライアンス

「モデルに送っていいデータは何か」を、ポリシーではなく技術的境界で担保する圧力が強まります。オンデバイス、VPC内推論、トークン化、ログのマスキングは、いまの秘密管理やDLPの延長線です。AppleのPrivate Cloud Computeのように、設計を公開して説明責任を果たす方向も参考になります（Apple Security Research）。

バブルのあとに残る設問——派手な予測より地味な四行

最後に、設計のチェックリストを短く置きます。これは箇条書きの「作業手順」ではなく、レビュー会議で白板に書くための四つの問いとして使ってください。

そのAIはどこで動くのか。社外公開の汎用チャットと高度推論はクラウドのBig AIに寄せ、端末内補助や高頻度の分類・抽出はスモールAIに寄せる——境界を言語化できるか。

何を守るのか。個人情報、顧客秘密、学習データの持ち出し、ログの保存先は、契約と実装の両方で一致しているか。

いくらで回るのか。トークン単価だけでなく、再試行、監査、人のレビュー工数まで含めた単位経済で見ているか。

止まったときに誰が責任を持つのか。モデル障害、誤生成、プロンプトインジェクション、データ越境——オペレーションとエスカレーションが決まっているか。

熱狂の反動は来ても、あなたの仕事は「消える」方向に進みにくい

AIバブルがはじけるかどうかを、エンジニアが毎日気に病む必要はありません。恐れるべきは、熱狂のなかで「モデルを呼べば価値が出る」と誤解したまま本番に載せて、あとからコストと監査と遅延で焼けることです。

これから強くなるのは、巨大モデル礼賛でも、ローカル至上主義でもなく、業務要件に応じてAIを分解し、配置し、観測し、止められる人です。いまあなたが積み上げているAPI設計、クライアント制約への耐性、運用の型は、そのままスモールAI時代の土台になります。

同じテーマを別角度から深掘りしたい場合は、著者の他記事もあわせて参照ください（Qiitaの投稿一覧（mhamadajp））。

作成日：2026年4月7日