Google Cloud Next Tokyo 26登壇時のスクリプト

2026/7/30に、Google Cloud Next Tokyo 26で手嶋が発表したスクリプトになります。
資料はこちら→https://speakerdeck.com/recruitengineers/google-cloud-next-tokyo-26_teshima

Transcript

1. Google Cloud Next Tokyo '26 登壇トークスクリプト 登壇者：手嶋 毅志（株式会社リクルート） 本ドキュメントは、Google Cloud Next Tokyo '26 にて発表したセッションの講演スクリプ ト全文です。講演資料（スライド）はこちらです： https://speakerdeck.com/recruitengineers/google-cloud-next-tokyo-26_teshima Slide 1 みなさんこんにちは。本日は、こちらのセッションにお越し下さり、ありがとうございま す。こちらの題で発表をさせていただきます。 Slide 2 まず初めに、早速ですが、皆さんに手を挙げていただきたいと思います。皆様の中で、LLM を利用するアプリケーションを開発している方、あるいは、これから作る可能性があるとい う方、どれくらいいらっしゃいますでしょうか？​ ​ ……ありがとうございます、たくさんの方に手を挙げていただきましたね。LLMは早くも、 開発の日常になりました。では、そのアプリケーションをさらに一歩進めようとしたとき、 こんなふうに思ったことはないでしょうか。 Slide 3 『AIに、単にチャットで会話をさせるだけではなく、手元のデータを渡して、プロダクトの 一環として、自由にデータ分析を行わせたい』。そう考えたことがある方、いらっしゃるの ではないでしょうか。​ ​
2. AIが自律的にデータを読み解いて、グラフを描き、それに基づいたアドバイスをくれる。非 常に魅力的なユースケースですよね。 しかし、この『自由に分析させる』という理想を具体的なプロダクトとして考え始めると、 私たちは一つの壁にぶつかります。 Slide 4 それは、AIが書いた『コード』を実行できる環境は、どう作ればいいんだろうか、という問 題です。 ユーザーが増えてもスケールさせるには？分析対象のデータをどう限定するか。外部への通 信を許すかどうか。通信を許せば、大切なデータが流出する可能性が生まれます。通信を許 さないならば、最新のライブラリをどうやって使える状態にすればよいのでしょうか？ たくさんの疑問が出てきます。 Slide 5 そこで、本日のトークでは、この話をさせていただきます。 LLMエージェントに安全なコード実行環境を与えるための、具体的な設計パターン。 Google Cloud のサービスをうまく組み合わせれば、自律的AIのための高度な内製コード実 行環境を作れるぞ！というお話を共有させていただきます。 Slide 6 改めまして、株式会社リクルート データ推進室の手嶋毅志と申します。データサイエン ティストとして、膨大なデータを価値に変える仕事をしています。
3. Slide 7 弊社リクルートでは、「Air ビジネスツールズ」というブランドで、お店の業務や経営を支 援するプロダクトを展開しています。​ ​ 飲食店や美容室といった、皆様の身近にあるお店の運営を想像してみてください。そこに は、予約管理や、注文の管理、レジ打ちや決済、シフト管理など、多くの業務が伴います ね。​ ​ そういった業務の煩わしさを取り除き、それによって、事業を営むすべての人が、心のまま に、自分の思い描くことを実現できる世界を、『商うを、自由に。』というビジョンのもと で目指しています。​ ​ 具体的には、Airペイや、Airレジなどのプロダクトを展開して、お店のレジ業務や予約管 理、キャッシュレス決済などをはじめとする、お店の業務の様々な側面を楽にするサービス を提供しています。 Slide 8 これらのサービスを介して、注文や売上など、店舗経営の活動の履歴が、日々のデータとし て蓄積されていきます。​ ​ このようにして貯まっていくデータには、自分のお店を良くするためのヒントがたくさん詰 まっています。私たちは、このデータを事業を営むみなさんが自ら用いて、確かな意思決定 を下せる、そんな経営改善の『仕組み』を作りたいと考えています。 しかし、この仕組みを形にする上で、大きな課題がありました。経営において考えるべきこ とが、あまりにも多様だということです。
4. Slide 9 『秋の新メニューは何がいいか』『この料理を値上げしたらどうなるか』『営業時間を変え たときの影響は』。店舗経営で出てくる問いは、お店や人の状況によって様々。まさに十人 十色です。 分析の問いかけがこれほど多様であるとき、従来のデータ分析のやり方では、どうしても追 いつかなくなってしまいます。 Slide 10 お店の経営に対して、『問いとデータ』の組み合わせは、無数に存在します。そのすべてを 事前に予見して分析フローを作り込むことはできません。​ ​ 決まった分析を実行できるだけのプロダクトでは、せっかくユーザーが考えている、解像度 の高い、独自の問いがあったとしても、その価値を引き出すことができなくなってしまいま す。 だからこそ私たちは、決まったプログラムを用意するのではなく、AIがその場で問いに応じ たコードを書き、自律的に分析するシステムを目指しました。 Slide 11 目指したゴールはこちらです。AIによる分析実行・経営支援を実現すること。その際に、 データの機密性を守りながらも、AIエージェントが自由に分析を実行できること。 そのための技術的なチャレンジとして、AIが使える『ツール』としてのコード実行環境を、 いつでもスケールアウトが可能なクラウドネイティブな構成で実現する。これが私たちの挑 戦でした。
5. 今回は、その実現パターンについてお話していきます。その前に、皆さまの状況に私たちの ストーリーが参考になりそうかどうか、前提となる環境、デリバリーの体制についてお話を しておきます。 Slide 12 今回の内容は、少人数のデータエンジニアにより開発しているプロダクトの、一つの機能と して実現したものです。扱っている範囲は、インフラからフロントエンドまで、全員がすべ てを触るという、フルスタック開発の体制となっています。 また、プロダクトとしてはデリバリーの優先度が高い時期にあります。AIエージェントのUI やUXは、まだ世界中が答えを探している探索期です。​ ​ だからこそ、まずは少数のユーザーからロールアウトし、結果を見て重要な機能を磨き上げ る、そして後からスケールを上げていくというアプローチを取っています。 今回お話ししていくのは、そういった状況下でのシステムパターンです。皆さまのチーム環 境にどれぐらい近そうでしょうか。似ていればそのまま参考に、似ていなければ内容を少し 割り引いて聞いていただければと思います。 このチームの中で、セキュリティと自由度を両立させるために導き出したアーキテクチャの 全貌が、こちらです。 Slide 13 こちらが、今回の実装パターンのアーキテクチャーです。 LLMがコードを書いて実行ツールを呼び出すと、Cloud Runで動く『Controllerサービス』 が窓口となり、リクエストを受け付けます。​ ​ その裏側には、同一の仮想マシン、VMが複数プールされており、そのどれかへと処理が受 け渡されます。VMの中ではDockerコンテナが起動し、その上でコードが実行されます。​
6. ​ 分析対象になるデータは、BigQueryから『Data Provisioner』が安全に切り出して、ファ イルストレージを介してコード実行コンテナに引き渡されます。 データを実際に処理する環境である、VM群とその中のコンテナは、外部へのネットワーク アクセスをインフラレベルで許可しない構成にすることで、生成されたコードがデータを外 部に送ってしまうことを原理的に防ぎます。 このアーキテクチャを支える設計のポイントは、大きく4つにまとまります。 Slide 14 1つ目は、無駄なリソースを持たない『オンデマンドな実行環境』。​ ​ 2つ目は、コンテナを使い捨てにしても文脈を維持する『ストレージによる状態管理と、 データの受け渡し』。​ ​ 3つ目は、外部通信なしでも最新ライブラリが使える『コンテナの自由度』。​ ​ そして4つ目は、データの流出を根底から防ぐ『ネットワークとアクセスの制限』です。 これら4つのポイントを、順番に見ていきましょう。まずは1つ目のポイント、リソースを 効率よく扱い、スケールさせるための設計から見ていきます。 Slide 15 1点目は、オンデマンドなコード実行環境という構成について。 計算を実行するためのリソースは、今回の場合、ステートフルなものと、ステートレスなも の、どちらが良いでしょうか。 計算リソースを一定期間保持する『ステートフルな構成』では、ユーザーごとなどの利用単 位で個別に環境を構築する必要が出てきます。結果、実際には使われていない時間も計算リ
7. ソースが占有されて、お金がかかり続けてしまうため、無駄なコストが発生します。また、 並列処理も、計算リソースの状態を複製または共有しなければ実現できないため、並列化に よってスケールを上げることの難易度が高くなります。 そのため、私たちは計算リソースは『ステートレス』、つまり使い捨てにできる形で作ると いうことを選択しました。必要な瞬間だけ動的に割り当てるオンデマンド設計にすること で、無駄なコストを無くし、急なニーズの増加にも単純並列化で無理なくスケールできるよ うにしています。​ ​ この思想を、Google Cloud上でどう実装したのか。詳細とポイントがこちらです。 Slide 16 実装としては、Compute EngineのManaged Instance Group機能（MIG）を使って、仮想 マシンをプールします。仮想マシンは、Packerであらかじめ複製可能なVMイメージを作っ ておき、これをテンプレートとして、必要な時に自動で増減するオートスケール設定をして おきます。 そして、プールした仮想マシンを、単一のコード実行サービスとして振る舞うように、内部 ロードバランサーでプロキシすることで束ねます。 ユーザーからのリクエストがあると、Cloud Run上の『Controller』が内部ロードバラン サーを介してDockerリクエストを転送し、VM内のDockerコンテナで実行されます。この 実行環境は、予め、VMイメージに同梱しておいたものを使います。 この計算実行は、あくまでもステートレス。コードの実行が終わった瞬間に、コンテナごと 破棄します。 ただ、ここでひとつ疑問がありますよね。実行環境を毎回使い捨てにするなら、分析の『途 中の状態』や『実行結果』はどうやって引き継げばいいのでしょうか。
8. Slide 17 コンテナが使い捨てであれば、当然、AIが途中で作ったファイルやグラフ画像も一緒に消え てしまいます。状態を引き継げないと、長い時間がかかる処理も段階的に進められず、毎回 すべてを1からやり直すことになってしまいます。これでは、使い物になりませんよね。 そこで私たちは、『状態』を計算リソース自体に持たせることなく、外部からストレージを アタッチして、そこに状態保持の役割を集約することで、この問題を解決しました。​ ​ 途中結果はファイルとして、ストレージに永続化することで、状態の保持を実現します。外 部ストレージなので、計算リソースの実体が揮発するとしても、次の計算リソースにアタッ チしなおせば、すぐに同じ作業スペースの状態から処理を再開できます。​ ​ また、それに伴って、入力となるデータや出力結果の受け渡しも、ストレージを介して疎結 合に行いやすくなります。 このストレージ中心の状態管理を、Google Cloud上で実現した方法が、次のスライドで す。 Slide 18 私たちは、Google Cloud Storage（GCS）のバケットを、VMに直接マウントしています。 そして、実際にリクエストを処理する際には、VMのマウント先の中で、ユーザーや会話 セッションなどに基づいて決まるサブパスを、Dockerに対してボリュームマウントする形 で渡します。​ ​ すると、コンテナから見れば、そのセッション固有のワークスペースがファイルシステムに 展開されているような状態になります。ローカルのファイルシステムに読み書きするのと全 く同じ感覚で、処理の途中結果を保持したり、結果を出力したりすることができます。​ ​ ここで出力されたファイルはミドルウェアを介して自然とGCSに保存されるので、特別な状
9. 態管理の工夫も必要ありません。​ ​ さらに、結果の受け渡しも、レスポンスにおいて出力先のGCSパスを返しておけば、アプリ ケーションからGCSに直接読みにいくことで、簡単に受け渡しが完了します。​ ​ この構成によって、アプリケーションとコンテナを、疎結合に保ちながら、状態の維持から 結果の受け渡しまでを、自然な方法でこなすことができます。​ ​ そして、このストレージの仕組みは、処理対象のデータを受け渡すための、自然な方法も提 供します。 Slide 19 データの受け渡しをどうするか。マルチテナントなプロダクトでは、当然ながら、そのセッ ションで許可されたデータ以外に触れられないようにしておく必要があります。しかし、 データ分析のために、AIにコードを書かせて、直接データウェアハウスからデータ抽出をさ せる方式をとってしまうと、この制御が確実に行われる保証ができません。意図しないデー タへのアクセス経路を生み出してしまう可能性があります。​ ​ そこで、先ほどのストレージによる状態管理が、再び力を発揮します。分析させたいデータ だけを、ユーザーIDなどに基づいてBigQueryから切り出して、先ほどのGCSのセッション 単位のパスに、あらかじめファイルとして置くようにします。LLMが生成したコードには データ抽出は担わせず、この事前配置されたファイルに対して処理をするようにすれば良い わけです。​ ​ このデータ配置は、Cloud Runで用意した『Data Provisioner』という独立したコンポーネ ントによって実行させます。処理対象のデータを選定し、事前配置する操作は、このData Provisionerをツールとしてエージェントに提供し、分析実行前に予めそのツールを呼び出 すように指示しておきます。​ ​
10. LLM自身の判断によるデータアクセス管理ではなく、インフラ側でアクセス制御を担保す る。これが私たちの設計です。​ ​ データの安全な受け渡しもできるようになったので、次はそれを処理するコンテナの中身、 つまり分析用ライブラリの管理についてです。 Slide 20 データの受け渡しができるようになったところで、次なる課題は、実際にコードを動かす分 析用コンテナの中身をどうするかです。高度な分析を実行するにはライブラリの存在が欠か せませんが、これを、実行環境にどうやって注入すれば良いのでしょうか。​ ​ そこで考えられるパターンの一つは、実行時に pip install などのコマンドで、インス トールを行うアプローチです。 しかし、このアプローチはおすすめできません。インス トールに時間がかかりますし、何より外部ネットワークへの接続が必須になり、これがセ キュリティの穴になりかねないからです。​ ​ そこで私たちは、右側のパターンを選択しました。分析に必要な最新パッケージをすべて網 羅したDockerイメージを最初から作っておき、それを、複製されるVMイメージに最初から 同梱しておく、というものです。これなら実行時の待ち時間はゼロ、外部通信も不要になり ます。​ ​ 次は、この環境をGoogle Cloud上でどう実現しているか、具体的なデプロイ方法を見てい きましょう。 Slide 21 私たちは、VMのイメージをビルドする段階で、独自の分析用Dockerイメージをあらかじめ VMの中に pull して、丸ごと焼き込んでいます。つまり、MIG（Managed Instance Group ）によって新しく立ち上がるサーバーには、最初からこの理想的な分析環境がセットされて
11. いるわけです。​ ​ これによって、コンテナが起動したその瞬間から、外の世界と一切通信することなく、分析 のライブラリがすぐに使えます。​ ​ セルフホストの環境のため、社内ライブラリを入れたり、特定のバージョンでロックしたり と、LLMのプロバイダーが提供するコードインタープリターに比べて、より柔軟な制御をで きることも隠れた利点です。 最後に、4つ目のポイントである『ネットワークとアクセスの制限』についてお話ししま す。 Slide 22 AIが書いた任意の分析コードを実行する際、そこには、データの流出に関する懸念がつきま といます。​ ​ AIが良かれと思って、データをどこかにアップロードするようなコードを書いてしまうこと は、十分に考えられます。しかし、アプリケーション側でコードの文字列を検閲して、その 実行を止める、というアプローチには限界があります。 では、AIが書いた未知のコードによるデータの流出を防ぐ、一番確実な方法は何でしょう か。​ ​ それは、ネットワークをインフラレベルで『遮断』することです。ネットワーク通信がなけ れば、流出経路も生まれません。意図しない持ち出しを防ぐことができます。 そのために、Google Cloudの機能で、このような閉域環境を作ります。
12. Slide 23 まず通信面ですが、VMからの外部通信は一切許可しないようにします。​ ​ ただし、Google CloudのAPIアクセスのみを、『プライベートGoogleアクセス』で許可す ることで、GCSなどの必要なリソースにのみ接続を絞り込んでいます。​ ​ さらに、Dockerコンテナを起動する際には、ネットワーク通信を与えないよう明示的に設 定し、コンテナからVMローカルへの通信も、多重に遮断します。 あわせてIAM権限も最小化しており、VMに付与するサービスアカウントは、指定された GCSバケットへのアクセス権とCloud Loggingへの書き込み権限のみに限定しています。​ ​ こうした、ネットワークと権限の制御で、安全性を高めながらも、事前準備したコンテナ内 に必要なライブラリがすべて揃っているため、閉域環境であってもスムーズなデータ分析が 可能です。 最後に、この一連のアーキテクチャを、どのように管理し、機動的に運用しているかとい う、開発プロセスの側面についても、一言だけご紹介します。 Slide 24 今回ご紹介したすべての Google Cloud リソースは、Terraform で一元管理しています。ま た、リソース定義だけでなく、VM イメージの構築プロセスそのものも Cloud Build や Packer を用いてコード管理しています。 インフラ全体がコードとして管理されているため、CI/CD パイプラインやコーディング AI による開発支援の恩恵を、十分に活かすことができます。​ ​ 結果として、インフラ更新も含むような大きなリリースであっても、週に数回のような高い 頻度で安全かつスピーディにリリースできる体制を実現しています。
13. Slide 25 これらの結果として生まれたのが、この自律的なAIのための、内製分析環境です。 お店の経営者が考えていることを画面に入力すると、システムが自動で必要なデータをGCS へ切り出し、AIが分析コードを書くことを自ら判断して、コード実行ツールを呼び出しま す。​ ​ 書かれたコードは、管理された閉じた環境で、しかも私たちが用意したライブラリが初めか ら入っている状態で、実行されます。 そして生成された美しいグラフと共に、データに裏打ちされたアクションプランなどが、即 時にユーザーへと返されます。 固定されたダッシュボードの限界を超え、AIとデータが本来持っていた『無限の可能性』が 開ける、そんな実装パターンになっていると思います。 Slide 26 本日お話ししたパターンが、皆さんのチームの課題解決のヒントになれば幸いです。興味を 持っていただいた方、ご質問がある方などは、ぜひこの後の Ask the Speaker にお越しく ださい。 Slide 27 それでは、まだまだ始まったばかりですが、引き続きGoogle Cloud Next Tokyoを最後まで 楽しんでいきましょう！ありがとうございました。