企業AIのラストワンマイル——ボトルネックはモデルではなく「実装」にある

企業でAIを語るとき、視線はモデルに集まりがちだ。パラメータ数、計算資源、ベンチマーク。だが少し引いて見れば、モデルを成立させているのは一本の連鎖である。半導体があり、データセンターがあり、それを支える電力があり、電力を蓄える蓄電池がある。これらの条件が揃って、ようやく優れたモデルは動く。

しかし、モデルが動くことと、AIが企業の中で動くことは別だ。SoftBankの登壇者はこのセッションで、自社の立ち位置をその連鎖の最終工程——「実装」——に置いていた。モデルを社会に、企業の中に組み込み、安全に動かすところまでやって初めて、前段の投資は意味を持つ。ここが終わっていなければ、それはまだ半製品だ。

半導体から実装まで、飛ばせない連鎖

登壇者はまず、インフラの層について簡単に触れた。半導体が第一層、次がデータセンター、その先に電力と蓄電がある。目新しい順番ではないが、ここには見落とされがちな事実がある。AIの競争は単一の層で決まるものではなく、供給チェーン全体の競争だということだ。どこか一層が欠ければ、モデルは世に出ない。

そして連鎖の末端にあるのが「実装」である。モデルの能力を具体的な業務につなぎ、実際の仕事の成果に変える。登壇者は、そこが自社のポジションだと話す。

チャットボットではなく、全部門に広がるエージェント

彼らが描くのは「社員にチャット画面を一つ配る」姿ではない。各事業部門、バックオフィス、営業部門、開発部門にAIエージェントを入れていく。エージェントは個別に動くのではなく、互いに連携する。あるエージェントが情報を受け取り、別のエージェントが続きを処理する。

分業も変わる。AIが推論と実行を担い、人は意思決定に集中する。登壇者が示したのは、社員の日常業務のおよそ半分はエージェントが担える、という見立てだ。

注目すべきは「半分」という数字そのものではなく、AIを業務フローの外に置かず、中に入れている点にある。エージェントが部門をまたいで連携するということは、権限、データ、責任の境界を設計し直すということでもある。そしてそれは、次の問いに直結する。

エージェントが自律するほど、セキュリティを先に

6月、同社はAIへの攻撃を防ぐセキュリティサービスを発表した。理由はシンプルだ。エージェントがハッキングされれば、やってはいけない動きをしてしまう。そこまで行けば、それまでの効率化はすべて振り出しに戻る。

だから順番としては、防御を先に固め、そのうえで展開する。とくに日本の重要インフラだ。この順番の背景には、プレゼンでは語られにくいコスト構造がある。エージェントが自律するほど、突かれる入口は増える。データを読み、システムを操作し、人の代わりに実行できるようにするというのは、攻撃面を一回り広げることでもある。

FDE——まず本当の課題を見つけ、それからアーキテクチャを語る

では、実装は具体的にどう進めるのか。登壇者が示したプロセスは特別なものではない。まず顧客の本当の課題を特定し、技術スコープを設計し、アーキテクチャを設計し、プロトタイプを構築し、本番へ適用する。ごく一般的な開発の進め方だが、難しいのは、どの工程も飛ばさないことだ。

このプロセスで繰り返し登場する役割がFDE（Forward Deployed Engineer）である。Palantirが最初に実践したと言われ、いま多くの企業が導入し始めている。SoftBankにもFDEのチームがある。FDEは助言だけをするコンサルタントではなく、自分で手を動かして形にするエンジニアだ。

同社はFDEの能力を5段階に分け、そのうちいくつかを重点的に説明した。第1段階は、顧客の課題を理解し、状況が不透明でも技術スコープを定義できること。顧客と直接向き合い、プロトタイプから本番導入まで進められること。第4段階は、人一倍自分で手を動かし、技術と顧客要件、プロダクトの間をつなげること。そして最も重要なのが第3段階——システム設計、実装、本番化を判断できる力だ。

判断力とは具体的に何か。さまざまな業務ドメインで、このアーキテクチャを導入すれば動くのか、安全に動くのかを見極める力である。オープンソースや新しい言語の環境で実装し、安全だと判断する。そのうえで本番に持っていく。登壇者はこの能力が非常に希少だと述べ、だからこそFDEは少数精鋭の部隊なのだと話した。

レガシーシステムがエージェントの床になる

ただし、FDEだけでは足りない。日本の多くの企業には、SoftBank自身も含めて、長年作り上げてきたシステムがある。それを一気にAI化するのは非常に難しい。

登壇者は典型的な状態をいくつか挙げた。汎用機を使い続け、コードはCOBOL、GitHubにも上がっておらず、仕様書もなく、データはあちこちに散らばっている。そうした土台の上では、エージェントはそもそも動かない。だからまずクラウドリフトのような整備を行い、エージェントが安全に引き継げる土台にシステムを移す必要がある。

そのために彼らは新しい職種も作った。これまでTPMが担ってきた企画の機能、SREが担ってきた運用の機能を、それぞれ「AI版」として定義し、FDEとチームを組む。この細部が示すのは、実装が数人のエンジニアの英雄主義ではなく、職種と協働のしかたを組み直す仕事だということだ。

6週間で150件、それを1人が数時間で

登壇者は、自分で録った開発画面を流した。6週間でおよそ150件のバグと新機能の企画が積み上がったときの映像だ。

これまでのループはこうだ。バグを直し、デプロイし、レビューし、テストする。違えば戻し、もう少し改良したほうがいいかと考え、確認してからまたデプロイする。これを何度も繰り返す。いまは、1人が1時間ほどを1単位として反復し、5〜8時間でこの束をすべて終わらせるという。

速度を支えているのは「検証—実装—改善」のループである。仕様がまったくない場所でも、まず検証の定義と制約をエージェント向けの指示ファイルに書き、そのうえでエージェントに実装を続けさせる。「何が正しいか、何をしてはいけないか」を先に書き、そのあと速さを求める。この順番があって初めて、速さは品質に変わる。

もちろん、エンタープライズの要求が消えるわけではない。本番設計、セキュリティ、回答品質、ガバナンス、可用性は、進めながら同時に考える必要がある。でなければ、デモは速いが、リリースは遅いままだ。

実装とは、組織ごと移すこと

最後に登壇者は、企業のチームと一緒に進めたいと語り、エンジニアの募集にも触れた。冒頭の連鎖に戻ろう。半導体、データセンター、電力、蓄電がモデルの成立を決める。そして実装が、モデルを社会の働き方に変えられるかを決める。後者のほうが難しい。変えるのはモデル一つではなく、システム、権限、職種、そして人の意思決定の位置だからだ。