はじめに こんにちは、リテールハブ開発部の杉森です。 Vercel Labs が開発しているローカル API エミュレータ「emulate」が面白そうだったので、実際に触りながら AWS SDK (S3) との互換性、GitHub / Google の OAuth フロー、本番 API への切り替えまでを試してみました。 emulate とは emulate は Vercel Labs が開発しているオープンソースのローカル API エミュレータです。GitHub、Google、Slack、Stripe、AWS など 12 のサービスをローカルで再現でき、単なるモック（固定レスポンスを返すだけ）ではなく、ステートフルなデータストアと OAuth フローを備えています。 npx emulate の1コマンドで 12 サービスがポート 4000〜4010 で起動します。設定ファイルは不要で、デフォルトのユーザーとトークンが自動で作成されます。 emulate v0.4.1 vercel http://localhost:4000 github http://localhost:4001 google http://localhost:4002 slack http://localhost:4003 apple http://localhost:4004 microsoft http://localhost:4005 okta http://localhost:4006 aws http://localhost:4007 resend http://localhost:4008 stripe http://localhost:4009 mongoatlas http://localhost:4010 Tokens test_token_admin -> admin 起動直後から Authorization: Bearer test_token_admin で全サービスの API を呼び出せます。 # ユーザー情報を取得 curl http://localhost:4001/user -H "Authorization: Bearer test_token_admin" # リポジトリを作成 curl -X POST http://localhost:4001/user/repos \ -H "Authorization: Bearer test_token_admin" \ -H "Content-Type: application/json" \ -d '{"name":"hello-world"}' レスポンスは本物の GitHub API と同じ JSON 構造です。ステートフルなので、上で作成したリポジトリに対して Issue や PR を追加するといった操作もできます。 実際に試してみた emulate v0.4.1 / Node.js v22 の環境で、以下の3つの観点から検証しました。 AWS SDK (S3) との互換性: SDK 経由でそのまま使えるか GitHub / Google OAuth フローの実装: OAuth を含むアプリをローカルで開発できるか 本番 API への切り替え: 2 で作ったアプリのコードを変えずに本番で動かせるか AWS SDK (S3) との互換性を検証する emulate の AWS エミュレータが、AWS SDK v3 からそのまま使えるかを検証しました。検証には @aws-sdk/client-s3 3.1028.0 を使用しています。 emulate の認証の仕組み emulate ではすべてのサービスが Bearer トークン認証に統一されています。実際のサービスではそれぞれ認証方式が異なりますが、emulate 上ではどれも同じ Authorization: Bearer でアクセスできるようになっています。 また、登録されていないトークンでリクエストしても、フォールバック機構によりデフォルトユーザー（admin）として認証が通ります。テストコードでトークンの値を気にせず書けるのは便利でした。 この仕組みが AWS SDK との互換性に直接関わってきます。 困った点と対応内容 AWS SDK v3 から emulate の S3 エミュレータを使うには、以下の2つの対応が必要でした。 1. endpoint のパスが合わない emulate のルートは /s3/:bucket/:key 形式ですが、AWS SDK は /bucket/key にリクエストを送るため、パスが一致しません。endpoint を localhost:4007/s3 にすることでパスを合わせます。 2. 末尾スラッシュでルートが一致しない AWS SDK は PUT /s3/bucket-name/ のように末尾スラッシュ付きでリクエストを送りますが、emulate のルート定義にスラッシュがないためマッチしません。SDK ミドルウェアで末尾スラッシュを除去することで対応しました。 対応後の動作結果 上記2つの対応を入れることで、CreateBucket、PutObject、GetObject、ListObjectsV2、ListBuckets、DeleteObject といった主要な S3 操作はすべて動作しました。 なお、AWS SDK は SigV4 署名を送りますが、emulate は SigV4 を解釈しません。前述のフォールバック認証によりデフォルトユーザーとして通るため、credentials の値は { accessKeyId: "dummy", secretAccessKey: "dummy" } で動きます。 ただし、Presigned URL、S3 イベント通知、SQS との連携などは未対応です。AWS SDK のより広い互換性が必要な場合は別のライブラリ等を検討した方が良さそうです。emulate の AWS エミュレータは「REST API の形状をテストする」用途向けという印象です。 補足: 本記事で触れたルートのパス不一致や Presigned URL 未対応については、修正の PR がすでに存在しております。マージされれば上記の回避策は不要になりそうです。 OAuth フローを組み込む emulate を使ってみて特に便利だと思ったのは OAuth フローのエミュレーションです。GitHub OAuth でサインインして PR 一覧を表示するアプリを作って検証しました。 シード設定で初期データを定義する emulate は YAML で初期データ（シード）を定義できます。起動時にユーザー、リポジトリ、OAuth App が自動で作成されます。 github : users : - login : admin name : Admin User email : admin@example.com repos : - owner : admin name : test-repo auto_init : true oauth_apps : - client_id : emu_github_client_id client_secret : emu_github_client_secret name : PR Viewer App redirect_uris : - http://localhost:3000/auth/callback 以下は、今回作ったアプリの OAuth フローです。 emulate にアクセスすると、以下のような認可画面が表示されます。 シードで定義したユーザーをクリックするだけで認可が完了します。トークン交換や API コールは本物の GitHub API と同じエンドポイントで動作するため、アプリ側のコードは本番と同じ実装がそのまま使えます。 なお、シード設定は宣言的なデータ定義のみに対応しており、PR のようなリソースはシードで作成できません。API 経由で投入する必要があります。 Node.js から直接起動して開発環境を自動化する emulate は CLI（ npx emulate ）だけでなく、Node.js のコードから直接起動する API（ createEmulator ）も提供しています。これを使って、emulate の起動、テストデータの投入、Web サーバーの起動を1コマンドにまとめました。 import { createEmulator } from "emulate" ; const github = await createEmulator ({ service : "github" , port : 4001 , seed : config }) ; const google = await createEmulator ({ service : "google" , port : 4002 , seed : config }) ; npm run dev だけで全部起動する体験は快適でした。 本番 API への切り替えを検証する server.js はすべてのエンドポイント URL を process.env から読み取る設計にしました。emulate と本番の切り替えは .env.local と .env の読み分けだけで行えます。 # .env.local（emulate 用） GITHUB_URL=http://localhost:4001 GITHUB_API_URL=http://localhost:4001 GITHUB_CLIENT_ID=emu_github_client_id GITHUB_CLIENT_SECRET=emu_github_client_secret GITHUB_OWNER=admin GITHUB_REPO=test-repo # .env（本番用） GITHUB_URL=https://github.com GITHUB_API_URL=https://api.github.com GITHUB_CLIENT_ID=<実際の Client ID> GITHUB_CLIENT_SECRET=<実際の Client Secret> GITHUB_OWNER=<実際のオーナー名> GITHUB_REPO=<実際のリポジトリ名> { " scripts ": { " dev ": " node --env-file=.env.local dev.js ", " start:prod ": " node --env-file=.env server.js " } } 本番の GitHub OAuth App を作成し .env に設定して npm run start:prod で起動したところ、コード変更なしで本物の GitHub 認可画面が表示され、実際の PR 一覧が取得できました。 観点 emulate 本番 GitHub 認可画面 emulate のユーザー選択画面 GitHub の実際の認可画面 認可の操作 ユーザーをクリック 「Authorize」ボタン データ テストデータ リポジトリの実際の PR API キー 不要 実際の Client ID / Secret Google OAuth + Gmail API も同じパターンで追加しました。emulate 用の環境変数は以下の通りです。 # .env.local（emulate 用） GOOGLE_URL=http://localhost:4002 GOOGLE_TOKEN_URL=http://localhost:4002/oauth2/token GOOGLE_API_URL=http://localhost:4002 GOOGLE_CLIENT_ID=emu_google_client_id GOOGLE_CLIENT_SECRET=emu_google_client_secret # .env（本番用） GOOGLE_URL=https://accounts.google.com GOOGLE_TOKEN_URL=https://oauth2.googleapis.com GOOGLE_API_URL=https://www.googleapis.com GOOGLE_CLIENT_ID=<実際の Client ID> GOOGLE_CLIENT_SECRET=<実際の Client Secret> まとめ 3つの検証観点ごとに結論を整理します。 AWS SDK (S3) との互換性: endpoint のプレフィックス追加と末尾スラッシュ除去の2つの回避策を入れれば、主要な S3 操作は動作する。ただし Presigned URL 等は未対応で、より広い互換性が必要なら 別のライブラリを検討した方が良い。 GitHub / Google OAuth フローの実装: シード設定と認可画面の自動生成により、OAuth App の登録やテストユーザーの作成なしで OAuth フローを含むアプリの開発を始められる。OAuth フローをローカルで手軽にテストできるのは便利だった。 本番 API への切り替え: エンドポイント URL を環境変数に切り出しておけば、コード変更なしで本番に切り替えられる。 興味がある方はぜひ試してみてください。 参考リンク emulate GitHub リポジトリ emulate 公式ドキュメント

G-gen の奥田です。当記事は、2026年3月19日に開催された Agentic AI Summit 2026 Spring で筆者と弊社の今野が登壇したセッション「Gemini Enterprise と ADK で実現する業務特化型エージェント開発の最前線 — ユーザー認証連携における Google Workspace 操作の実装方法と事例を公開」のレポートです。 セッションの概要 なぜ AI エージェントにユーザー認証が必要なのか サービスアカウントのリスク OAuth 2.0 によるユーザー認証連携 デモ : 議事録カレンダー登録エージェント デモの概要 Google Workspace への応用 なぜ ADK を選んだのか コードの実装 構成図とソースコードのディレクトリ構成 エージェントの定義 認証トークンの取得とカレンダー API の呼び出し 開発中に遭遇した落とし穴 ADK の State オブジェクト LiteLLM のセキュリティに関する注意 Gemini Enterprise へのデプロイ 参考リンク セッションの概要 当セッションでは、AI エージェントが Google Workspace のサービスを操作する際に不可欠な ユーザー認証連携 をテーマに、実装方法と事例を紹介しました。 セッション前半では、AI エージェントにおける認証の重要性を具体的なシナリオで解説し、議事録から Google Calendar にイベントを自動登録するエージェントのライブデモを行いました。後半では、 Gemini Enterprise 、 Agent Development Kit （以下、 ADK ）、 Agent Engine を組み合わせたアーキテクチャと、 OAuth 2.0 連携の実装ステップを紹介しました。 参考 : Gemini Enterprise 参考 : Agent Development Kit（ADK） 参考 : Agent Engine 参考 : OAuth 2.0 Agentic AI Summit 2026 Spring での実績は以下のとおりです。 合計 オンライン オフライン CSAT G-gen セッション 741 名 556 名 185 名 3.9 なぜ AI エージェントにユーザー認証が必要なのか サービスアカウントのリスク AI エージェントを業務で利用する場合、「エージェントが誰として外部サービスにアクセスするのか」が重要な設計課題です。 たとえば、社員 A さんが AI エージェントに「来週の火曜日に会議を入れて」と依頼したとします。エージェントは A さんの代わりに Google Calendar を操作する必要があります。このとき、システム共通のサービスアカウントに権限を一括付与して動かすと、エージェントは A さんだけでなく B さんや他の組織の C さんのカレンダーにもアクセスできてしまいます。 技術的には動作しますが、業務での利用には適しません。AI エージェントは人間と違い、バックグラウンドで大量のデータに触れることができます。だからこそ「誰として動いているのか」を明確に設計することが不可欠です。 OAuth 2.0 によるユーザー認証連携 この課題の解決策が OAuth 2.0 を使ったユーザー認証連携です。 仕組みはシンプルです。ユーザーが一度ログインして権限を許可すると、エージェントはそのユーザーのアクセストークンを使って API を呼び出します。エージェントはそのユーザーの権限の範囲内でしか動作しません。 A さんの AI エージェントが行った操作は「A さんが自分の権限で実行した」という記録です。コンプライアンスの観点でも重要なポイントです。 デモ : 議事録カレンダー登録エージェント デモの概要 セッションでは、議事録や ToDo メモからタスクを抽出し、Google Calendar にイベントを自動登録するエージェントのライブデモを行いました。 デモの流れは以下のとおりです。 Gemini Enterprise 上でエージェントを起動し、OAuth 認証を完了する 直近のカレンダー予定を確認する 日時とタイトルを入力してイベントを追加する 約 6,300 文字の架空の議事録（ポータルサイトプロジェクト）をエージェントに渡す エージェントが議事録から 9 個の ToDo を抽出し、カレンダーに一括登録する 不要なプライベートの予定を削除する デモで約 6,300 文字の議事録を使用したのは、 Gemini の従来の強みである大規模コンテキストウィンドウを利用するため です。長文の議事録であっても分割せずに一度で処理できることを示す狙いがありました。 エージェントは 9 個のタスクを抽出しましたが、そのうち 2 つは会議のアイスブレイク時に話題に上がったプライベートな内容（入学式の話）でした。エージェントがこれらを業務タスクと同列に扱ってカレンダーに登録しました。 デモ後半では「プライベートの予定を削除」と入力するだけで、エージェントが自律的に予定の性質を判断し、該当するイベントのみを削除しました。これは、エージェントが文脈を理解し、カレンダーの内容を自律的に評価した実践的な事例です。 このエージェントの導入効果として、 議事録 1 件あたりのカレンダー登録作業を手動10分から自動で1分程度に短縮 できます。タスクの抜け漏れを防ぐ実用的なエージェントです。 Google Workspace への応用 今回のデモでは Google Calendar を題材にしましたが、同じ OAuth 2.0 連携の仕組みを使うことで、Google Workspace の各サービスにも応用できます。 Gmail では、エージェントがユーザー本人としてメールボックスに下書きを作成したり、宛先・件名・本文を含むメールを送信できます。たとえばミーティングの議事録をまとめて関係者にフォローアップメールを自動送信するといった使い方が可能です。 Google ドキュメント や Google スライド では、箇条書きや構成案を渡すだけでドキュメントやスライドの雛型を作成できます。ユーザーはブラッシュアップやクリエイティブな作業に集中できます。 Google ドライブ では、ユーザー自身がアクセス権を持つファイルだけを検索できるため、他者のファイルに触れるリスクがありません。社内ドキュメントをナレッジベースとして RAG 構成と組み合わせる使い方が効果的です。 共通するポイントは、すべての操作がユーザー本人の権限の範囲内で動作することです。 なぜ ADK を選んだのか エージェント開発のフレームワークには LangChain や CrewAI など複数の選択肢があります。今回 ADK を採用した理由は大きく2つです。 1つ目は、 Google Cloud のエコシステムで完結させたかった ことです。フロントエンドの Gemini Enterprise、実行基盤の Agent Engine、そして開発フレームワークの ADK をすべて Google Cloud のサービスで統一することで、認証トークンの受け渡しやデプロイがマネージドサービス間でシームレスに連携します。前述のとおり、 tool_context.state を通じた OAuth トークンの自動受け渡しは、この統一されたエコシステムがあってこそ実現できる仕組みです。 2つ目は、 ADK と OAuth 2.0 を組み合わせた実装事例がまだ少なかった ことです。ADK 自体の利用例は増えていますが、Gemini Enterprise の OAuth 連携と組み合わせて Google Workspace を操作するパターンは、2026年4月現在でも公開事例が限られています。今回のセッションとデモを通じて、この実装パターンを広く共有したいという意図がありました。 コードの実装 構成図とソースコードのディレクトリ構成 構成図は以下です。 ソースコードは GitHub で公開しています。 参考 : G-gen-Tech-Blog/agentic-ai-summit-2026-spring-session-report リポジトリのディレクトリ構成は以下です。 . ├── __init__.py ├── agent.py # エージェント定義 ├── tools.py # ツール関数（Calendar API 操作） ├── config.py # 設定値の管理 ├── requirements.txt # 依存パッケージ ├── .env_example # 環境変数のサンプル ├── .gitignore └── README.md エージェントの定義 以下は ADK でエージェントを定義する agent.py の全体です。49 行でエージェントの定義が完結しています。 # agent.py from google.adk.agents.llm_agent import Agent from . import tools from google.adk.models.lite_llm import LiteLlm root_agent = Agent( name= "calendar_agent" , model=LiteLlm( "vertex_ai/gemini-3-flash-preview" , vertex_location= "global" ), description= "議事録を解析して Google Calendar にイベントを登録するエージェント" , instruction= """あなたは議事録からTodoを抽出して Google Calendar に登録するアシスタントです。 以下の手順で作業してください。 1. ユーザーから議事録を受け取る。 - ファイルパスが渡された場合は read_todo_file ツールでファイルを読み込む。 2. テキスト内容を解析し、議事録からTodoとそれに関係する情報を抽出する: - 日付・時刻（今年は2026年。月/日 の形式なら 2026年として解釈する） - イベントタイトル - 説明（あれば） - 終日イベントかどうか 3. 抽出した各イベントについて create_calendar_event ツールを呼び出して登録する。 - 日時は ISO 8601 形式にする（例: 2026-02-20T14:00:00） - 終日イベントの場合は日付のみ（例: 2026-03-01）、end_datetime は翌日にする - 時間の指定がない場合は終日イベントとして扱う - 終了時刻の指定がない場合は開始から1時間後を終了時刻とする - タイムゾーンは Asia/Tokyo 4. Todo テキストに参加者（メールアドレス）の記載があれば attendees に指定する。 ユーザーが参加者を指定した場合は、そのメールアドレスを追加する。 5. 登録結果をユーザーに報告する。 注意事項: - すべての日時は日本時間 (JST, Asia/Tokyo) を基準とする。 時刻の指定がある場合は日本時間として解釈すること。 - テキストは自由形式。「2/20 14:00 美容院」のようなフォーマットもあれば、 文章形式の場合もある。柔軟に解析すること。 - 日付が曖昧な場合は確認を求める。 """ , tools=[ tools.read_todo_file, tools.create_calendar_event, tools.list_calendar_events, tools.update_calendar_event, tools.delete_calendar_event, ], ) Agent クラスの model に LiteLlm で gemini-3-flash-preview （2026年4月現在）を指定しています。 instruction にはシステムプロンプトとして議事録の解析手順を記述し、 tools に呼び出し可能なツール関数を登録しています。 ADK では LiteLlm を使うことで Gemini 以外のモデル（Claude、GPT など）にも切り替えられます。 参考 : ADK LiteLLm ドキュメント 認証トークンの取得とカレンダー API の呼び出し 今回の構成で最も注目すべきポイントは、Gemini Enterprise・ADK・Agent Engine の3つのサービスが連携してユーザーの認証トークンをシームレスに受け渡す仕組みです。 通常、OAuth 2.0 を使ったアプリケーション開発では、トークンの取得・保存・リフレッシュ・有効期限の管理といった複雑な認証フローを開発者自身が実装する必要があります。しかし、Google Cloud のエコシステムではこの課題が解消されています。ユーザーが Gemini Enterprise 上で OAuth 認証を完了すると、取得されたアクセストークンは Agent Engine のセッションに自動で保存されます。ADK のツール関数では、引数として渡される ToolContext の state からそのトークンをわずか1行で取得できます。 この「Gemini Enterprise（認証 UI）→ Agent Engine（トークン管理）→ ADK（トークン利用）」という一連の流れが、Google Cloud のマネージドサービス間で自動的に実現される点が、このエコシステムの大きなメリットです。 以下の get_calendar_service 関数がその実装の核心です。 from google.oauth2.credentials import Credentials from googleapiclient.discovery import build from google.adk.tools import ToolContext def get_calendar_service (tool_context: ToolContext): """ Agent Engine 環境で Google Calendar サービスを認証・生成します。 """ # 1. 環境変数から管理画面で設定した ID を取得 auth_id = os.getenv( "AUTH_ID" ) # 2. トークンの取得を試みる access_token = tool_context.state.get(auth_id) if not access_token: access_token = tool_context.state.get( "authentication" ) # 3. トークンが見つからない場合 if not access_token: raise ValueError ( "認証トークンが取得できませんでした。" "チャット画面で Google ログインを完了させているか確認してください。" ) # 4. 取得したトークンでカレンダーサービスを構築 creds = Credentials(token=access_token) return build( "calendar" , "v3" , credentials=creds) ポイントは tool_context.state.get(auth_id) のわずか1行です。この1行の背後では、以下の処理が Google Cloud のマネージドサービスによって自動的に行われています。 Gemini Enterprise がユーザーに OAuth 同意画面を表示し、認可コードを取得する Agent Engine が認可コードをアクセストークンに交換し、セッションの state に保存する ADK のツール関数が ToolContext 経由でそのトークンを取得する 開発者が実装するのは tool_context.state.get(auth_id) でトークンを取り出し、 Credentials に渡す部分だけです。トークンの取得フロー、リフレッシュ、有効期限の管理はすべてマネージドサービス側が担います。 認証フローの実装が、Google Cloud のマネージドサービス連携により数行のコードに集約されています。 以下は、メインのツール関数である create_calendar_event です。 def create_calendar_event ( summary: str , start_datetime: str , end_datetime: str , tool_context: ToolContext, description: str = "" , timezone: str = "Asia/Tokyo" , attendees: list [ str ] | None = None , ) -> dict : """Google Calendar にイベントを作成する。""" service = get_calendar_service(tool_context) s_dt = start_datetime.strip() e_dt = end_datetime.strip() # 終日イベントかどうかの判定 is_all_day = ( "T" not in s_dt) and ( ":" not in s_dt) if is_all_day: s_dt = s_dt.replace( "/" , "-" ) e_dt = e_dt.replace( "/" , "-" ) event_body = { "summary" : summary, "description" : description, "start" : { "date" : s_dt}, "end" : { "date" : e_dt}, } else : if " " in s_dt: s_dt = s_dt.replace( " " , "T" ) if " " in e_dt: e_dt = e_dt.replace( " " , "T" ) event_body = { "summary" : summary, "description" : description, "start" : { "dateTime" : s_dt, "timeZone" : timezone}, "end" : { "dateTime" : e_dt, "timeZone" : timezone}, } if attendees: event_body[ "attendees" ] = [{ "email" : email} for email in attendees] event = service.events().insert(calendarId= "primary" , body=event_body).execute() return { "status" : "success" , "event_id" : event[ "id" ], "summary" : event[ "summary" ], "html_link" : event[ "htmlLink" ], } get_calendar_service(tool_context) を呼び出すことで、ログイン中のユーザーの権限で Google Calendar API を操作しています。終日イベントと時間指定イベントを date と dateTime で区別し、 attendees パラメータで参加者の追加にも対応しています。 開発中に遭遇した落とし穴 ADK の State オブジェクト 開発中、認証トークンの中身を確認しようとした際に以下のエラーに遭遇しました。 # やりたかったこと：state の中身を一覧表示したい print (tool_context.state.keys()) 上記の様に入力すると、以下の結果になります。 AttributeError: 'State' object has no attribute 'keys' ADK の State オブジェクトは、標準の Python 辞書（ dict ）ではなく、Python の MutableMapping プロトコルにも準拠していません。辞書のように値の取得や代入はできますが、 .keys() や .items() といった標準的なメソッドは持っていません。これはバグではなく、会話状態の差分追跡を確実に行うための意図的な設計です。 注意すべき点として、ADK には以下2つの state が存在します。 session.state tool_context.state （ context.state ） session.state は標準の Python 辞書（ dict ）であるため .keys() や .items() が通常どおり使えます。 一方、ツール関数の引数として渡される tool_context.state は前述の State オブジェクトであり、これらのメソッドは使えません。 session.state.keys() は正常に動作するのに tool_context.state.keys() ではエラーになるため、両者を混同するとデバッグ時に混乱を招きます。 ツール関数内では tool_context.state を使うため、 .get() メソッドで安全に値を取り出す必要があります。 # 正しい方法：.get() で安全に取得 access_token = tool_context.state.get(auth_id) 操作は .get() や直接代入（ tool_context.state[key] = value ）に留めることが推奨されます。ADK を使ったエージェント開発を始める方は、この仕様を事前に把握しておくとデバッグ時間を節約できます。 参考 : Context - Agent Development Kit (ADK) LiteLLM のセキュリティに関する注意 LiteLLM v1.82.7 / v1.82.8 は、サプライチェーン攻撃（TeamPCP）により侵害されました（2026年3月24日）。本デモの GitHub リポジトリのサンプルコードでは v1.83.0（攻撃後の正規リリース、2026年3月31日公開）にピン留めしています。 詳細は以下を参照してください。 参考 : LiteLLM 公式セキュリティアップデート 参考 : GitHub Issue #24518（タイムライン） Gemini Enterprise へのデプロイ 作成したエージェントを Agent Engine にデプロイした後、Gemini Enterprise のコンソールからエージェントを追加できます。画面からの操作のみでデプロイが完了します。 ユーザーごと、またはグループごとにエージェントの利用権限を管理することも可能です。組織全体への安全な展開が実現できます。 参考リンク 参考 : Agentic AI Summit 2026 Spring 参考 : 登壇資料 参考 : G-gen-Tech-Blog/agentic-ai-summit-2026-spring-session-report（ソースコード） 以下の動画でセッションの実演をご覧いただけます。 奥田 梨紗 (記事一覧) クラウドソリューション部データインテリジェンス課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025&2026 Follow @risa_hochiminh

この記事で分かること Safie AI Studio（セーフィー エーアイ スタジオ）の基本的な使い方 使う前に知っておきたいSafie AI Studioのアーキテクチャ Safie AI Studioを使うメリット 対象読者 Safie AI Studioに興味を持ってくれた方 映像をリアルタイム解析するプロダクトを実際に運用されている方 映像をリアルタイム解析するプロダクトをこれから開発する予定の方 はじめに！ Safie AI Studio というプロダクトのTech PdM（テクニカル・プロダクトマネージャー）を担当している松木と申します！プロダクトの仕様の