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