PoC で止まらず本番へ。汎用的な機能は任せ、自社独自の業務に AI エージェント構築を

Google Cloud が主催する「Agentic AI Summit '26 Fall」の2日目は、エンジニア向けの基調講演で幕を開けた。テーマは「エージェント開発の最前線。試すから、本番で動かすへ」。MC は Google Cloud のデベロッパーアドボケイト（開発者に技術を伝える役割）、佐藤一憲氏が務めた。Google Cloud の Prashanth Subrahmanyam 氏と石原祥太郎氏、Google DeepMind の Rody Davis 氏が最新の技術を紹介し、荏原製作所の田中紀子氏と岡村森氏、Sakana AI の湯聿津氏、エイベックスの山田真一氏が、自社でエージェントを作って動かしている現場の話を持ち寄った。

筆者は、この技術を自社の経営にどう当てはめるかという目で話を聞いた。

MC を務めた Google Cloud の佐藤一憲氏

「エージェントの時代」に入った

MC の佐藤氏に紹介されて最初に登壇したのは、Google Cloud で Cloud Developer Relations のマネージャーを務める Prashanth Subrahmanyam 氏だ。英語のセッションで、今日のテーマはエージェントを試す段階から本番で動かす段階へどう運ぶかだと語り、「We are in the era of agents.」（私たちはエージェントの時代にいる）と言い切った。

Google Cloud の Prashanth Subrahmanyam 氏

氏が映したのは、企業とソフトウェアの関係が3つの波で変わってきたことを示すスライドだ。題は「The Next Wave of Growth: Agentic Work」。企業の次の成長は、人の隣で切れ目なく働く自律型の AI エージェントから生まれる、と添えられている。

最初の波は「Digitization（デジタル化）」で、ソフトウェアは道具だった。仕事をするのは人で、ソフトウェアはその成果を保存する。効率化の対象は、一つひとつの作業の自動化とデータの保管だ。

次の波が「Conversational AI（対話型 AI）」で、AI はアシスタントになった。人が指示を出し、AI が応え、人がそれを組み立てる。何かを決めるときも、組み立てるときも、毎回人の手が要る。

そしていま来ている3つ目の波が「Agentic Workplace」で、AI は同僚（Coworker）になる。スライドによれば、エージェントは自律性とアイデンティティを持ち、自ら先回りして動く。デジタルのチームの正規のメンバーとして働くという。氏は、エージェントが人に代わって、長い時間をかけて多くの仕事をこなすようになる、と語った。

企業とソフトウェアの関係は、3つの波で変わってきた

筆者にとって、この日いちばん腹に落ちたのがこの図だった。2つ目の波までは、AI に聞いて、返ってきた答えを人がつなぎ合わせる。3つ目の波では、仕事のひとまとまりを AI に任せる。アイデンティティを持つとは、社員証のように「誰として、どこまでの権限で動いているか」が分かる、ということだろう。経営の側から読むと、AI を同僚として迎えるなら、何を任せ、どこまでの権限を渡し、誰が仕事ぶりを見るのかを決めなければならない。これは技術部門だけでは決められない。人を採用して配属するときと同じく、経営が引き受ける判断だと思う。

本番で動かすには「載せたあと」がある

氏はここで本題に入った。エージェントの利用は広がっているが、本番環境でエージェントを動かすのは非常に難しい。それはエンジニアリングの課題だ、と氏は語る。従来のソフトウェア開発には、DevOps や SDLC（企画から運用までの開発の工程）といった実践が積み上がってきた。エージェントも同じように、Agent Development Lifecycle、略して ADLC として考える必要があるという。

スライドに並んだ段階は6つある。1つ目の Setup で環境を整えて使うモデルを選び、2つ目の Build でプロンプトを書き、データとツールをつなぐ。3つ目の Deploy で、エージェントをパッケージにしてクラウドの実行環境に載せる。

「しかし、それだけでしょうか」と氏は問いかけた。本当に難しいのはここからだという。4つ目の Govern では、本番で動くエージェントにセキュリティポリシーとアクセス制御を徹底して適用する。5つ目の Evaluate では、品質の自動テストと安全性の評価を常に回し、エージェントが本来の仕事をしているかを確かめる。6つ目の Publish では、組織の中で安全に使えるようにエージェントを公開する。「エージェントには利用者が必要です」という一言が印象に残った。

エージェント開発の6段階。後半の3つは載せたあとの仕事だ

筆者なりに言い換えると、作って載せるまでが前半の3つで、載せたあとに見張り、測り、届けるのが後半の3つだ。後半の3つは、技術の話というより、社内のルール、品質の管理、社内への展開の話に近い。人を雇えば、就業規則を示し、仕事ぶりを評価し、力を発揮できる部署に配属する。エージェントにも同じことが要る。試作はうまくいったのに本番に進めない企業が多いのは、この後半を誰が持つのかが決まっていないからだと思う。

モデルから実行基盤、統制までをひとつのスタックで

ADLC の各段階に合わせて、Google Cloud は道具をそろえている。氏はモデル、作る道具、動かす場所、統制の順に紹介した。

モデルでは、フロンティアモデル（最先端の大規模モデル）である Gemini 4 Argon の一般提供を発表した。複雑な業務の流れをこなす性能が高く、実際のソフトウェア開発、サイバーセキュリティの防御、金融や法務のような規制の厳しい知的業務で実力が示されているという。数日前には、次のフロンティアモデル「Carbon」を発表し、一部のテスターへの提供を始めたことも明かした。一方で氏は「企業は選択肢を求めている」とも語り、Anthropic や OpenAI、オープンモデルなど、他社のモデルも同じプラットフォームで使えることを強調した。

作る道具は2つある。1つは Google Antigravity だ。デスクトップアプリ、CLI（コマンドで操作する道具）、IDE（開発環境）の拡張機能、プログラムから呼ぶ SDK のどれを使っても、同じハーネス（エージェントを動かす土台の仕組み）で動く。もう1つが ADK（Agent Development Kit）で、エージェントをプログラムで組み立てるための部品セットだ。ADK 2.0 では、処理の流れをグラフ（図）として組めるようになり、複数のエージェントの協調や、状況に応じて変わる流れも作れる。Skill Registry に登録されたスキル（仕事の手順をまとめたもの）を、動きながら探して使う仕組みもある。さらに Agents CLI を使えば、普段使っているコーディング支援の AI が、ADK でエージェントを作って載せる専門家に変わるという。

動かす場所としては、大規模な運用に向く GKE、使っていないときは動いている分をゼロまで減らせるサーバーレスの Cloud Run、エージェント専用の Agent Runtime を選べる。Agent Runtime には、記憶、会話の管理、動きを観測する仕組みが最初から付いている。

統制については、氏は「まさにそこでガバナンスが重要になる」と前置きした。プラットフォームで動くすべてのエージェントに、暗号技術で守られた固有の ID（Agent Identity）が付く。サブエージェントも1つずつ ID を持つ。そして Agent Gateway が、ガードレールとポリシーをリアルタイムにエージェントへ適用する。先ほどの3つの波のスライドで、エージェントが「アイデンティティを持つ」と書かれていたのは、この仕組みのことだ。

氏は、半導体からモデル、データ基盤までをまとめて持ち、安全に使える状態で届けられるのが Google Cloud の強みだと述べた。そして最後に、会場へこう呼びかけた。「もうプロンプトを書くのはやめて、エージェントの構築を始めてほしい」。

「選ぶ」から「束ねる」へ：Sakana AI の Fugu

Prashanth 氏の呼びかけに続いて登壇したのは、Sakana AI の R&D Chief Scientist、湯聿津氏だ。湯氏はまず、会社のロゴから話を始めた。魚の群れの中に、1匹だけ赤い魚がいる。赤い魚は、これまでと違う発想で考えたいという姿勢を表す。群れの方は、市場にある多くのモデルやエージェントの違いを生かし、集合知として製品を強くしたいという考えを表しているという。

Sakana AI R&D Chief Scientist の湯聿津氏

その考えを形にした製品が「Sakana Fugu」だ。湯氏は「Sakana Fugu はモデルではない」と言う。Gemini や GPT など、各社の強力なモデル群の上に、指揮者（Conductor）の役を担うモデルを載せ、それを訓練している。Fugu は、こうしたモデルをどう組み合わせれば仕事をやり遂げられるかを学んでいく。

製品ラインは3つある。湯氏は、横軸に費用、縦軸に性能をとったグラフで説明した。既存のモデルは、同じ費用ならこれ以上の性能は出ない、という限界の線（パレートフロンティア）の内側に並んでいる。Fugu の使命は、この線を外側へ押し広げることだという。旗艦の Fugu Ultra は性能の高さを追い、Fugu Max は費用の制約の中で性能を引き上げる。もう1つの Fugu X は特定の分野で強みを伸ばす系列で、その例がサイバーセキュリティに特化した Fugu Cyber だ。

成果も示した。Fugu Ultra の第2版は、各社の最先端モデルと同等かそれ以上の性能を出している。比べた相手のうち一部の最新モデルは、Fugu が束ねる候補にまだ入っていなかったという。Fugu Cyber も、セキュリティの代表的な試験で、セキュリティ向けの最先端モデルを上回った。さらに前夜には、社内のエージェントと Fugu を組み合わせて数学のコンテストに出場し、1位を取ったと明かした。Fugu は、Sakana AI 自身の日々の研究も支えているという。

仕組みは4つの要点にまとめられた。1つ目は、単純なルーティング（振り分け）ではなく、オーケストレーションだということだ。「こんにちは」のような簡単な問いなら、安い小型のモデルを選んで答えを返す。「このコードベースを確認して」のような複雑な依頼では、あるモデルに最初の作業をさせ、別のモデルにレビューさせてから答えを返す。2つ目は拡張性で、同じモデルの新しい版が出ても、能力が前の版と似ていれば Fugu を学習し直さずに差し替えられる。Fugu 自体は小さなモデルなので、新しいモデルを加えるときの学習も軽く済む。3つ目は堅牢さだ。公開と社内の試験をもとに、モデルごとに能力の形（プロファイル）を作っておき、あるモデルが止まったら、能力が最も近いモデルに切り替える。プロファイルを並べると、得意分野を補い合うモデルの組み合わせも見えてくる。4つ目は、学習と運用の基盤に Google Cloud を使っていることだ。学習には Gemini platform の GPU とデータ保管を、システムの健全性の監視には BigQuery とダッシュボードを使っているという。

Fugu は振り分けではなく、複数のモデルに仕事を分担させる

前日の Tokenomics のセッションでは、依頼ごとに難しさを判定し、品質を満たせるモデル1つへ自動で振り分ける「ルーティング」が紹介された。費用を大きく下げながら、品質は最上位モデルだけで処理した場合に近い水準を保つ使い方だ。Fugu も、簡単な依頼なら同じように小さなモデルに任せる。違いは、難しい依頼では仕事を分け、複数のモデルにチームを組ませることにある。会社にたとえるなら、ルーティングは案件を見て担当者を1人決める受付で、Fugu はメンバーを集めて分担を決めるプロジェクトマネージャーに近い。

経営の目で読むと、モデルの使い分けには2つの目的がある。定型の仕事を安く回すことと、間違えると痛い仕事の質を上げることだ。前者は振り分けで足りるが、後者にはチームを組ませる発想が要る。もう1つ、能力の形を見える化しておき、誰かが抜けたら近いスキルの人が入るというのは、人員配置そのものだ。モデルが数か月で入れ替わる時代に、特定のモデルに賭けず、束ね方の側で変化を吸収する。筆者はこれを、AI への投資を守る考え方として受け取った。

2人で始めて全社へ：荏原製作所

続いて登壇したのは、荏原製作所の田中紀子氏と岡村森氏だ。テーマは「全社を巻き込む生成 AI 活用から AI エージェント実践へ」。

田中氏は金融機関で25年間、IT、デジタル、DX の推進に携わり、2023年7月に荏原製作所へ入社した。入社して2か月で岡村氏と2人で小さくプロジェクトを立ち上げ、全社に広げてきた。以来3年、生成 AI の全社プロジェクトを率いている。

荏原製作所 データストラテジーユニット ユニットリーダーの田中紀子氏

荏原製作所は、ポンプから始まり、いまは半導体製造装置メーカーとしても知られる。創業114年、従業員はグローバルで約2万人。スライドによれば、2025年の売上収益は9,582億円、営業利益は1,138億円で5つのカンパニーのうち半導体製造向けの精密・電子カンパニーが売上の36％を占める。シンガポールのマーライオンの噴水にも、同社のポンプが使われているという。

田中氏が示した「AI 活用の全体像」は、経営の目で見て興味深い一枚だった。中心にあるのは、岡村氏らが中心になって内製した「EBARA AI Chat」だ。社内に眠るナレッジを、Google Cloud 上の安全な環境で AI が検索して答える。閲覧権限の管理や多言語対応を作り込み、社内に散らばっていた問い合わせの窓口をここに集めた。検索の機能はほかのシステムから呼べる API として提供し、最近は AI エージェントの機能も載せている。あわせて Gemini や NotebookLM、Gemini Enterprise などの外部サービスの活用も進めている。

筆者が目を留めたのは、同じ図の左側に「EBARA AI Community」という柱が立っていたことだ。活用事例の共有、学びのコンテンツ、役員インタビュー、コンペの開催が並ぶ。コミュニティサイトも内製し、事例の共有やコンペをそこで回しているという。図の土台には、最新技術の調査、ユースケースの検討、規制動向とガバナンスの調査も置かれている。

荏原製作所の AI 活用の全体像。左端に AI Community の柱

システムを作るだけでなく、人が使いこなすための場と、守るためのルールを、最初から同じ図に描いている。Prashanth 氏が語った ADLC の後半、つまり統制し、評価し、組織に届ける部分を、事業会社の側から形にしている例だと思う。筆者は本業で研修の仕事をしているので、役員インタビューやコンペまで含めて「使われる仕組み」を設計している点に目が向いた。

ここから岡村氏が、具体的な取り組みを紹介した。まずは問い合わせ業務での活用だ。EBARA AI Chat には、IT システムや総務、人事など、社内のさまざまな問い合わせのナレッジが集まっている。国内のグループ会社の従業員が使い、1日の利用回数は2,500〜4,000回で推移しているという。

荏原製作所 シニアデータエンジニアの岡村森氏

岡村氏は「先ほどプロダクションはハードとありましたが」と、Prashanth 氏の話を受けて切り出した。本番で運用すると、さまざまな課題が出てくる。その一つが回答の精度だ。精度が低い原因は、モデルの性能、ハーネスやプロンプト（AI の動かし方）、そもそも答えに必要なナレッジがないことの3つに分かれる。「システムをリリースすること以上に、リリースした後に実際にどう改善を続けるかというところが非常に重要なポイントでした」と岡村氏は語った。

改善のポイントは「開発者だけでは改善しない」ことだったという。総務の問い合わせなら、業務をいちばん知っているのは総務の担当者だ。ただ、担当者の全員が SQL や Python で利用ログを分析できるわけではない。そこで荏原製作所は、「分析できる人を増やすのではなく、分析そのものを AI に支援させる」道を選んだ。利用件数などの決まった集計は BigQuery（Google Cloud のデータ分析基盤）で自動化し、「なぜこの質問が増えているのか」「低評価の回答に共通点はあるか」といった読み解きを Gemini に任せる。結果は、担当者が部門内や上長にそのまま共有できるレポートに仕上げられ、AI から半自動で届く。レポートには集計結果だけでなく、「この問い合わせが増えているので、新しいナレッジを追加しよう」といった次の行動まで必ず含めている。

問い合わせが来て、ログがたまり、AI が分析し、改善点を見つけてナレッジを直す。直したナレッジが、また問い合わせに使われる。このループを回した結果、総務の領域では、AI が適切に答えられた割合が、レポート導入前の2026年3月の50.2％から、導入後の5月には71.1％に上がった。AI チャットの利用数も増えたという。岡村氏は、自己解決率が上がっただけでなく、「AI を作って終わりではなく、改善し続けられる仕組みに変えられた」点に大きな価値を感じていると語った。

部門の責任者がそのまま判断に使える形でレポートが出てくる、という点がいい。経営の側から見ると、AI の改善を IT 部門だけの宿題にせず、業務を持つ部門の判断の流れに組み込んでいる。「分析できる人を増やすのではなく」という一言も響いた。全員に分析のスキルを身につけさせる前に、業務を知る人が AI の助けで判断できる仕組みを先に作る。人材育成の順番として、とても現実的だと思う。

岡村氏が力を入れているもう一つの取り組みは、「AI エージェントをエンジニアだけのものにしない」ことだ。技術の進化が速いからこそ、完璧な使い方を決めてから全社に広げるのではなく、さまざまな背景を持つ社員にまず試してもらう。そのための入り口を、社員のスキルに合わせて用意している。

1つは、社内用の AI Gateway だ。社員が自分で Google Cloud のプロジェクトを作って Gemini を呼び出すこともできるが、それではプロジェクトの管理や認証、セキュリティまで利用者が考えなければならない。そこで、社内で管理する窓口を通して生成 AI を提供し、認証には社内の仕組みを使う。利用者は AI を自分の業務にどう組み込むかだけに集中でき、自分の利用状況やコストも確認できる。スライドによれば、約110人が Python のアプリや Google Apps Script（表計算などに付いた簡単なプログラム）から使っている。岡村氏は「全員がコードを書けるわけではない」と前置きしたうえで、AI の力を借りながら Apps Script で業務と AI を組み合わせる動きが、さまざまな部署で生まれていると話した。

もう1つは、コードを書かない社員のための Google Workspace Studio だ。ノーコードで AI エージェントを作れる道具を入り口にし、国内外のグループ社員が参加する社内コンペを開いている。投稿された事例は Gemini で翻訳され、グローバル拠点で使われる22の言語で読めるという。スライドに映った第2回のコンペは、提出期間がちょうどこの日、10月30日までだった。岡村氏は、こうして「誰か一人の成功体験を会社全体で共有できる仕組み」に変えていきたいと語った。

筆者なりに整理すると、荏原製作所は入り口を3段に分けている。専門チームは問い合わせの AI を内製し、改善の仕組みを回す。少しコードを書ける社員には、統制とコストの管理を会社が引き受けた窓口を渡す。コードを書かない社員には、ノーコードの道具とコンペという場を用意する。全員にプログラミングを教えるのでも、専門家だけに任せるのでもない。社員がそれぞれ手の届く範囲で AI を試せるようにし、統制は裏側で会社が持つ。経営の側から見ると、これは人材育成の設計図としても読めると思う。

岡村氏は最後に、AI が質問に答えるものから、業務を実際にこなすものへ変わっていくと語った。半導体や水インフラ、エネルギーなど、社会や産業を支える領域で AI エージェントを生かし、「熱と誠」の精神で持続可能な社会を支えていきたいと締めくくった。

MC の佐藤氏は、2016年ごろから機械学習と AI の進化を見てきた立場から、課題は変わらないと受けた。「モデルがいくら賢くても」、AI を現場に位置づけるところが「一番のラストワンマイルであり、ハードル」だという。佐藤氏はこれを、DX に代わる言葉として AX とも呼んだ。荏原製作所はそこを本当に丁寧にやっている、という評だった。

作業台から組立ラインへ：Antigravity

続いて登壇したのは、Google DeepMind で Antigravity の開発者向けの発信を担う Rody Davis 氏だ。Antigravity は、エージェントにソフトウェア開発を任せるための Google の開発環境である。

Google DeepMind の Rody Davis 氏

氏は「2026年は、AI とソフトウェアエンジニアリングにとって特別な年になった」と切り出した。転換点は2025年12月だという。スライドには、2025年12月の Gemini 3 Flash から、2026年2月の Gemini 3.1 Pro、半ばの Gemini 3.8 Flash、そして10月の Gemini 4 Argon と Carbon まで、10か月でモデルが次々と更新された流れが並ぶ。氏によれば、これまで個人の開発者には手の届かなかったことが、いまでは半日の作業で実現できるようになった。

今年の初めまでは、AI がよいコードを書けても、複雑なシステムには人の手厚い監督が要った。モデルとハーネス（エージェントを動かす土台）が成熟するにつれ、1行ずつの入力補完や開発画面の中のチャットから、エージェント専用の環境へと開発の形が移ってきた。Antigravity は、最初からエージェントに任せる前提の開発環境として作られ、共通の土台をデスクトップアプリ、CLI、エディタの拡張機能、SDK の4つの入り口から使えるようにしている。

ここで氏が持ち出したのは、日本の「ソフトウェアファクトリー」の歴史だった。1969年に日立が横浜に世界初のソフトウェア工場を設け、1977年には東芝府中工場が続いた。MIT のマイケル・クスマノ教授が記録したように、日本はソフトウェアを職人芸から、再利用できる部品と厳しい品質の関門を備えた、再現できる規律へと変えてきたという。

その考え方をエージェントの時代に持ち込もう、と氏は語る。1つのチャットで作業するのは、作業台に職人が1人いるようなものだ。入力して確かめる人の速さが、そのまま限界になる。広げるには、作業台から並列の組立ラインへ移る必要がある。その一歩目が、チャットでのやり取りから、組み立てて仕事を任せる形への移行だという。Antigravity には /boost と /teamwork-preview という指示が用意されている。/boost は、少数のサブエージェントを一直線の組立ラインのようにつなぎ、範囲を決めて実行し、結果を確かめて返す。/teamwork-preview は、専門の役割を持つエージェントのチームを組み、互いの仕事を批評し合って磨く。必要に応じて50を超えるサブエージェントを立ち上げ、長いときは数日動き続けるという。

氏自身の働き方も変わった。以前はキーボードの前で素早いやり取りを重ねていたが、いまは大きな仕事を任せて、翌朝には検証済みの成果を受け取って仕上げるという。ただし、その前に、安心して任せられる安全策と、問題が起きても戻せる備えが要る。長い仕事を任せるときは、ブラウザからワークステーションにつなぎ、スマートフォンや腕時計で通知を受け取って、人の確認が必要な場面で介入できるようにしている。

氏は、日本生まれのもう一つの考え方を持ち出した。トヨタ生産方式で知られる「自働化」、つまり人の知恵を付けた自動化だ。スライドによれば、見張りのいる機械は人1人に機械1台で、糸が切れると不良品の布が山のようにできた。1924年の豊田佐吉の自動織機は、糸が切れた瞬間に自ら止まる。だから1人で40台を見られ、人が出ていくのは異常が起きたときだけでよかった。氏は、見張りのいない AI が誤った前提のままトークンを大量に使い続けるのも同じだとして、欠陥をすぐに見つけてラインを止め、後ろの工程に流さない仕組みを、エージェントの組立ラインにも持ち込もうと語った。

自ら止まる自動織機だから、1人で40台を見られた

その成果も数字で示された。Google の親会社 Alphabet の社内では、10万人を超える人が毎月 Antigravity を使っている。エージェントが書いて取り込まれたコードは35％増え、本番に出したあとで取り消すやり直しは30％減った。検証を作業の流れの中に組み込んだことで、速さと品質を両立できたという。

工場を支えるのは記録だ。Antigravity では、エージェントのやり取りの全履歴、計画書、検証の記録、作業場を、1つのフォルダにまとめて残す。だから、問題が起きても止めて、切り替え、続きから再開できる。氏は安定して回すための習慣として、会話ごとに隔離した作業場を使うこと、調べる段階と作る段階で会話を分けること、課題管理のチケットに要件と変更と検証の成果をまとめることの3つを挙げた。

最後に、工場の組み立て方が示された。まず、作業者となるサブエージェントを、指示やルールを書いた文書で定義する。次に、ラインごとの手順を標準作業手順書のようにスキルとして書き、どの材料で始め、どの検証済みの成果で終えるかを決める。3つ目が、読み取り専用で品質を確かめ、必要ならラインを止める検査役のエージェントだ。これらを1つのプラグインにまとめれば、チームの誰でも同じ工場を動かせる。プラグインのマーケットプレイスには、Google Cloud や Workspace、外部のパートナーのものを含め、65を超える検証済みのプラグインがそろったという。あとは、新しい課題の登録や毎日の定時、CI（テストや組み立てを自動で回す仕組み）からの知らせを合図に、ラインが自動で動き出す。

動き出したラインは、自分で直す。検査役が方針違反やテストの失敗、セキュリティの問題を見つけると、トヨタの「アンドン」のようにすぐにラインを止め、不良なコードを外に出さない。直すのは、出来上がった成果物だけではない。手順書にあたるスキルや作業者の定義そのものを直し、走るたびにライン全体が賢くなるようにする。スライドはこれを「ポカヨケ」になぞらえていた。設計上の本当の判断が必要な場面に来ると、ラインは記録を残したまま止まり、人のスマートフォンに知らせて判断を仰ぐ。氏は「Escape the chat. Scale with intelligence.」（チャットから抜け出し、知性とともに広げよう）というスライドで講演を締めくくった。

工場の組み立て方の細部までは、筆者にはとても追い切れなかった。それでも、この話が経営の言葉で語られていることはよく分かった。区切られた持ち場、標準作業手順書、検査役、止める仕組み、そして例外のときだけ人が判断する体制だ。会場では、何度となく「隔離（isolated）」という言葉が出てきたのが印象に残った。作業場を区切るから、失敗が広がらず、並べて同時に動かせ、誰が何をしたかが残り、やり直せる。1人で40台の織機を見られた理由も、機械の賢さより、その仕組みにあった。任せる範囲を区切り、止まる条件を決め、例外のときに誰が判断するかを決める。AI に大きく任せる前に経営が決めるべきことは、そこにあると思う。

使って当たり前にする：エイベックス

続いて登壇したのは、エイベックスで IT 統括室のゼネラルプロデューサーを務める山田真一氏だ。山田氏は「もともと私もエンジニアというわけではなく」と自己紹介した。Web デザイナーから始まり、映像制作や、ファンクラブ、EC、配信など同社のデジタル事業をシステムの面から担ってきた。2017年からはデータ基盤を統括し、いまは全社の AI 推進を担っている。

エイベックス IT 統括室 ゼネラルプロデューサーの山田真一氏

エイベックスは、音楽やアニメ、映像を中心に、IP（作品やキャラクターなどの知的財産）を軸に事業を広げる会社だ。山田氏は、同社の AI 推進には4つの柱があると説明した。業務を変える、人を育てる、支える仕組み、そして AI の環境である。業務を変える柱では、徹底した業務量の調査をしたうえで、間接部門や管理部門を中心に改善を進める。人を育てる柱には、研修、ワークショップ、社員一人ひとりの相談に乗る相談会、e ラーニングと理解度テストが並ぶ。

筆者が目を留めたのは、支える仕組みの柱だ。全社のガバナンスを定めたうえで、直近では評価制度の中にも AI の活用を取り入れたという。山田氏は「AI はこれから使おうというものではなく、すでに使っていて当たり前のもの」と語り、その経営のメッセージを全社に広げている。評価制度に入れるということは、使うかどうかを個人の興味に任せないということだ。使って当たり前、という前提を制度で示している。研修の仕事をしている筆者には、これは大きな一歩に見えた。研修でいくら学んでも、評価と結びつかなければ、現場の行動はなかなか変わらないからだ。

山田氏は、同社がたどった道のりも率直に振り返った。エイベックスは2024年、独自に構築した社内の AI チャットボットを展開した。セキュリティの不安や、自社ならではの価値をどう生むかを考えて、多くの企業が自社独自の AI を作っていた時期だ。ところが実際にやってみると、Gemini をはじめとする AI そのものがどんどん進化していく。そうなると、使う側にとっては、汎用の AI をそのまま使う方が便利になる。AI の進化に合わせて自社の仕組みを育て続けるのは、費用の面でも開発の人手の面でも難しい。そこで翌2025年に Gemini を全社に展開し、それまでのチャットボットは並行して運用したあとで閉じた。「AI システムは非常に陳腐化も早い」と山田氏は語った。

Rody 氏のスライドにあったとおり、モデルは10か月で4世代入れ替わっている。自社で作った仕組みが、あっという間に汎用の道具に追い越される。経営の側から見ると、ここで問われているのは、作ったものを手放す判断をどれだけ早く下せるかだと思う。並行して運用してから閉じる、という手順も含めて、現実的な判断だ。

そこで同社は方針を見直した。陳腐化の早い汎用的な機能は、既存のサービスに任せる。自社で開発するのは、自社に固有の課題や独特な業務に絞る。そのうえで山田氏が意識しているのは2つだ。1つは、テーマを慎重に選ぶこと。汎用の AI が進化しても簡単には置き換わらないもので、実現しやすく効果が見込めるものだけを手がける。もう1つは、内製で小さく作ること。スライドには、過剰な投資を避けてスピードを重んじ、「陳腐化して破棄することも織り込み済み」とあった。この2つを徹底した結果、独自に作った AI の約8割が、PoC（試作と検証）で止まらず本番で稼働しているという。

独自開発は自社に固有の課題に絞り、約8割が本番稼働した

PoC で止まらない、という点がこの日の聴きどころの一つだった。試作はうまくいったのに本番に進めない、という声はいまも多くの企業で聞く。エイベックスの答えは、技術より前の「何を作らないか」の判断にある。汎用の道具に任せるものと、自社で作るものを分け、作るものも捨てる前提で小さく始める。経営が決められることだし、経営にしか決められないことだと思う。

この日、山田氏が持ってきた事例は「経理承認 AI エージェント」だ。経理の承認業務では、申請の内容と、それに付いた証憑（領収書や請求書などの裏づけ資料）を目で照らし合わせ、問題がなければ承認する。件数が多く手間がかかるため外部に委託しているが、その委託費も年々増えていた。そこで、照合から承認までを AI エージェントに担わせることにした。

ここには2つの壁があった。1つは、ほかのシステムからつなぐ口（API）のない古い業務システムだ。10年以上使っているシステムは簡単には入れ替えられず、新しいつなぎ口を後から作るのも大変で、既存の業務に影響が出かねない。もう1つは、マニュアルに書かれていない判断基準だ。細かいローカルルールが、担当者の目視の中にだけあった。どこの会社にもありそうな課題だ。

エイベックスの答えは、AI エージェントが人と同じ画面を操作して確認する、というものだった。つなぎ口がないなら、人と同じようにブラウザの画面を操作すればよい。スライドによれば、Google Cloud 上で動くエージェントが、Document AI で証憑の中身を読み取り、Gemini 3.8 Flash で照合と画面の操作を担う。ただし、すべてを AI に任せているわけではない。決まった手順で確実に処理すべき部分はコードで書き、柔軟さが要る部分だけを AI に任せる。判断基準はプロンプト（AI への指示書）として、経理部門と協議しながら作り、更新している。

設計で目を引いたのは、「AI は確実なものだけを承認する」という考え方だ。業務の流れは変えず、承認の条件だけを人より厳しくした。人の承認者なら、ちょっとした間違いがあっても経験から「これは問題ない」と判断できる。AI に同じことをさせると、もっともらしい誤り（ハルシネーション）で判断を間違える恐れがある。だから、少しでも疑わしいものは担当者に回して人の判断を仰ぐ。山田氏は「安全性を重視した」と語った。Rody 氏の言う自働化、つまり異常のときだけ人が出ていく仕組みを、経理の現場で形にした例としても読める。

もう一つの壁、書かれていない判断基準には、意外な形で向き合うことになった。スライドによれば、AI は業務マニュアルどおり正しく動いていた。ところが実際のデータで確かめると、AI の判断の方が経理部門の判断より厳しかった。マニュアルは厳密に作られていたが、実務にはさまざまな例外があり、それが担当者の暗黙知になっていたのだ。現場からは「もっと緩くしてもいい」という声も出た。そこで同社は、マニュアルにこだわらず、担当者の暗黙知を取り込みながらプロンプトを調整している。例外をすべて組み込んでから出そうとすれば、いつまでたっても出せない。見通しが立った段階で動かし始め、走りながら直していく。処理できた分だけ、業務は軽くなるからだ。

山田氏は最後に3つの点をまとめた。テーマ選びは慎重にし、汎用の AI に簡単に置き換わらないものを選ぶ。確実なものだけを AI に任せ、すべてを求めずに走らせながら直す。そして、暗黙知を形式知にできれば、仕組みが変わっても有効だ。今回作った仕組みがいずれ汎用の AI に置き換わったとしても、書き出したルールはそのまま使い回せる。それが社内の資産になるという。締めのスライドは「最初から理想形を目指さず、処理できた分だけ成果を得る」だった。

MC の佐藤氏も、この数字に驚きを隠さなかった。AI や機械学習の PoC は8割方が実運用に進めない、というのがこれまでの定説だった。エイベックスの現場では、その逆に8割が実際に使われている。「よく言われているのとは逆なんですよね」と佐藤氏は語った。

この3つ目が、筆者にはいちばん響いた。作った仕組みは捨てる前提でもよい。だが、書き出した判断基準は残る。前日のセッションでも、AI に「売上とは何か」を教えるのは、エンジニアではなく業務と経営の仕事だという話があった。経理のローカルルールを言葉にするのも、同じ仕事だ。AI への投資というと道具や仕組みに目が行きがちだが、本当に積み上がるのは、自社の知を言葉にした部分なのだと思う。

佐藤氏も、同じ点に共感したと語った。AI エージェントで作るシステムそのものが価値なのではなく、エージェントと一緒に作り上げる過程で、暗黙知から形にされた知識に価値がある。佐藤氏自身も、デモや製品を作るとき、最初は何ができ上がるのか、何が問題なのか分からないことが多いという。これまで一人で戦っていたその作業を、AI エージェントと一緒に、自分の中にある暗黙の要件を洗い出して形にしていく。それが価値を生んでいるのだという。

研究の現場でも「道具」から「主体」へ：AI for Science

基調講演の最後に登壇したのは、Google Cloud の Cloud AI デベロッパーアドボケイト、石原祥太郎氏だ。1か月ほど前に加わったばかりで、日本の開発者コミュニティの声を製品チームにつなぐ役割を担う。人工知能学会の理事でもあり、前職では新聞社で研究開発に携わり、言葉を扱う AI の分野で査読付きの論文を発表してきた。テーマは「AI for Science」、科学のための AI 活用である。

Google Cloud デベロッパーアドボケイトの石原祥太郎氏

石原氏は、AI for Science には3つの側面があると説明した。物理や化学などの各分野が AI を使うことで研究を深めること、AI そのものが科学的な発見をすること、そして両者が深く結びついて研究のやり方自体が変わっていくことだ。スライドでは、科学技術振興機構（JST）研究開発戦略センターの報告書『AI for Scienceの動向2026』を出典に示した。

石原氏がいちばん強調したのは、AI の位置づけの変化だった。これまで AI は、研究者が使う支援の道具という意味合いが強かった。2024年のノーベル化学賞につながった AlphaFold も、AI でタンパク質の立体構造を予測し、専門知識を持つ研究者の探索を助けるものだった。それがエージェント型になり、AI が自律的に研究を進める動きが世界的に目立っているという。Prashanth 氏が冒頭で示した、道具からアシスタント、そして同僚へという3つの波が、科学研究の世界でも起きている。

もう一つ石原氏が強調したのは、こうした成果が論文で終わらず、製品として使える段階に来ていることだ。「研究論文として出てすごいよねで終わるのではなくて、皆様の個々の事業の中でどういうふうに活かせるのかを考えられるフェーズに来ている」と語り、その例として AlphaEvolve を紹介した。Google Cloud ですでに使える AlphaEvolve は、AI 自身が進化を重ねながら、問題を解くためのコードを書き換えていく製品だ。どんな指示を出すか、どのモデルを使うか、何をもって良しとするかの評価の仕方、出発点となるコードは、これまでどおり研究者やエンジニアが用意する。そのうえで、評価の基準に沿ってコードを書き換え、最適な形へと進化させていく部分を AlphaEvolve が担う。

スライドには、エージェントがプログラムを書き換えながら改善を重ねていく様子が映った。人が設計した評価の軸がどれだけ良くなるか、どう書き換えれば良い方向に進むかを、AI が自ら探っていく。研究論文として発表されたものが、いまは Google Cloud の中で使える。石原氏は費用の話にも触れた。AI エージェントを回し続ける以上、相応のコストはかかる。それでも、数パーセントの最適化が大きな利点につながる課題があるなら検討してほしい、という。Google 自身も、データセンターの効率化に AlphaEvolve を使い、大きな改善につなげた例があるそうだ。専門家の勘どころが要るところでも、道具を使って利益を得られるようになってきている、と石原氏は締めくくった。

経営の目で読むと、ここで問われるのは技術よりも費用と効果の見合いだ。数パーセントの改善に大きな価値があるのは、自社のどの課題なのか。それを見極めるのは、事業を知る経営の仕事だ。

ここでも、評価の基準は人が決める。この日の登壇者は、それぞれの言葉で同じことを語っていたように思う。Prashanth 氏の ADLC の「評価」、荏原製作所の回答品質のレポート、Sakana AI のモデルごとの能力の形、エイベックスの判断基準。AI がどれだけ自律的になっても、何をもって良しとするかを決める仕事は人の側に残る。

モデルの良し悪しから、現場で使える土台へ

最後に MC の佐藤氏が、この日の話をまとめた。スライドには、Sakana AI は単一のモデルからオーケストレーションへ、荏原製作所は全社に試せる場をつくり成功体験を共有資産に、エイベックスはテーマを絞り内製で小さく作って約8割が本番稼働、と並んだ。佐藤氏は、モデルの能力だけではなく、その下にあるエージェントのプラットフォームがこれからの勝負どころになると語った。そして、「このモデルがいい」「このモデルが悪い」という話ではなく、現場の非エンジニアに創造的に使ってもらえるプラットフォームはどれかを考える段階に来ている、と会場に語りかけた。

非エンジニアの筆者にとって、この一言は心強かった。この日の主役は、モデルの性能よりも、それを現場で使える形にする土台と、それを使いこなす組織の側にあったように思う。

取材を終えて

登壇者がそれぞれの言葉で語っていたことは、驚くほど同じ方向を向いていたように思う。経営の側から読むと、3つのことが見えてきた。

1つ目は、何を自社で作り、何を任せるかの判断だ。荏原製作所は EBARA AI Chat を自社で作り、改善の仕組みごと育て続けている。エイベックスは、自前のチャットボットを閉じて汎用の Gemini に切り替えた。一見すると逆の判断に見える。だが、分け方の物差しは同じだ。社内のナレッジと、それを直し続ける流れは荏原製作所に固有のものだ。エイベックスも、経理承認のような自社に固有の業務にだけ、独自の開発を絞っている。Rody 氏のスライドが示したとおり、わずか10か月で新しいモデルが次々と出ている。汎用の部分は任せ、自社に固有の部分に投資を集める。その線を引くのは経営の仕事だ。

2つ目は、モデルの使い分けも経営の判断になったことだ。前日の Tokenomics のセッションでは、依頼ごとにふさわしいモデル1つへ振り分けて費用を下げるルーティングが紹介された。この日の Sakana AI は、難しい依頼では複数のモデルにチームを組ませ、単独のモデルを上回る質を狙う。定型の仕事は振り分けで費用を守り、間違えると痛い仕事は束ねて質を取りに行く。Prashanth 氏によれば、エージェントのトークン消費は半年で14倍になった。どの仕事にどれだけ使うかは、技術の問題から予算配分の問題に変わりつつある。

3つ目は、AI に大きく任せるほど、人が決めることがはっきりしてくるということだ。会場では何度となく「隔離（isolated）」という言葉を聞いた。Rody 氏の織機は、異常のときに自ら止まるから1人で40台を見られた。エイベックスは、確実なものだけを AI に承認させ、疑わしいものは人に回す。荏原製作所は、次の行動まで書いたレポートを、現場から上長へそのまま回せる形で届けている。どれも、任せる範囲を区切り、止まる条件を決め、例外のときに誰が判断するかを決めている。そして、何をもって良しとするかの基準と、暗黙知を言葉にした判断基準は、仕組みが変わっても会社に残る。

筆者は本業で研修の仕事をしている。この日の話を聞いて、育てるべき人材の姿が変わってきたと感じた。エージェントを組み立てる技術は、プラットフォームの側がどんどん引き受けていく。残るのは、業務を分解して任せ方を決める人、自社の判断基準を言葉にできる人、評価の物差しを決めて例外のときに判断できる人だ。どれもプログラミングより業務の知識が要る。まずは自社の業務を一つ選び、AI に任せる部分と人が決める部分を書き出してみる。それが、試すから本番へ進むための最初の一歩になると思う。

開催概要

出典：Agentic AI Summit '26 Fall 公式ページ