見出し画像

Google Cloud Next'24 にて Google Cloudの生成 AI エコシステムはなぜ良いのか?について発表しました

Google Cloud Next'24のJapan Sessionにて、生成AIがエンジニアリングだけでなく、エンジニアリングがコアになるビジネス(SIer, ISVベンダー,SaaSベンダー)自体をどう変えていくのかについて登壇してきましたので、その話をしたいと思います。

生成AIはエンジニア不足を解消し、新しいビジネスモデルを提供する

生成AIは予想以上に我々の日々の業務を変えようとしています。

例えばGemini単体だけでなく、Gemini Code AssistやGemini in Databasesなどを併用していくことで少人数で複雑なプロジェクトを短期間で回してく体制を構築し、更に早期にエンジニアを育成していくスキームが構築することができますね。

Gemini for Google Cloudによって生成AIとエンジニアリングが融合

その結果として、より顧客価値最大化にフォーカスしたビジネスモデル、例えば従来エンジニアリング工数が肥大し、避けられがちだったSaaSの個社カスタマイズが逆にビジネスのコアになる、など「スケールしないビジネスが、スケールする時代」になっていくのではないでしょうか。

スリーシェイクはSRE領域で生成AIをフル活用

スリーシェイクでは、現在「SRE LLM(仮)」というプロジェクトで、普段のSRE業務を生成AIで大幅軽減する取組を行っています。

SREやDevOps領域はMLや生成AIによって補助ができるタスクが非常に多く、相性がいいと思っています。

流石に実際の現場で生成AIが出すコードをそのままコピペしたり、解析結果を鵜呑みにすることできませんが(最後は人間が責任を取るため)、スリーシェイクが持つNotion内のKnowledgeやGitHub内のコード、Slackの会話履歴(9年分)をRAGとして組み込んで精度を上げていくことで、今年度中には全体のプロセスのおよそ1/3は削減できる見込みです。

Slackで構成図を使って、IaC(Terraform)を作成してもらったり、複数のプロジェクトを横断したワークロードの解析に使っています

こうしてスリーシェイクは、技術的にも経験的にもスケールしづらいSREビジネスをスケールするビジネスへと変革しようとしています。

ちなみに、この「SRE LLM」は年内にSaaSとして販売予定ですので、SREがいない組織や育成に困っているチームがありましたら、ぜひ利用していただきたいと思います。(β版をご利用頂ける企業様を募集中です!)

Google Cloudの生成AIエコシステムはなぜ良いのか?

Google Cloudの生成AI戦略の素晴らしさは一言でいうと、「一体感」です。程よく既存サービスと密結合し、最速でGeminiの恩恵を受けられる設計思想がある点が素晴らしい。

Gemini単体だけでなく、それをどう活かすかのエコシステムの秀逸性がぶっちぎりですごい

一方で、他クラウドは単体の機能では類似したものがあれど、それらを組み合わせる際には別途バッチプログラムが必要だったり、学習コストがかかったりとバラバラ感が否めません。(この辺はGoogle Cloudのスタートが2008年GAE(Google App Engine)を皮切りに、PaaS視点で徐々にIaaS化してきた点が歴史的にあるからではないでしょうか。他クラウドとは逆ですね)

弊社のエンジニアが「Google Cloudを使ってると肩が凝らない」と言ってて、笑ってしまったのですが、まさにぴったりな表現です。

例えばBigQueryとGeminiはどう組み合わされるのか…

GCS(Google Cloud Storage)にSecurifyの商談ロープレで使った動画(mp4)を放り込んで、BigQuery経由で議事録を生成してみます
** meeting_movieというObjectテーブルの1行目にその動画ファイルの保管場所が指定されています

SELECT *
FROM ML.GENERATE_TEXT(
  MODEL `gen-ai-lab-xxxxxx`.vertexai.gemini_pro_model,
  Table `gen-ai-lab-xxxxxx`.vertexai.meeting_movie,
  STRUCT(
  '会議の詳しく要約してください.\n出力は日本語で、そして、マークダウン形式で出力してください.\n要約の項目は、\n- 出席者名\n- 時系列順での話題の内容\n- 会議のキーワード\n- 話し方(沈黙回数、ラリー回数、会話被り、TalkListen比率、抑揚スコア、話し方の速度)\nでお願いします' as prompt,
    1.0 AS temperature,
    2048 AS max_output_tokens,
    0.3 AS top_p,
    15 AS top_k
  )
) limit 1;

そうするとこんな感じで議事録が生成されます。(実際は個人名も出力されていますが、そこはA, Bとマスキングしました)

{"candidates":[{"content":{"parts":[{"text":" 出席者名:\n- A\n- B\n\n時系列順での話題の内容:\n- 冒頭の挨拶\n- 自己紹介\n- 3SHAKEの説明\n- Securityの説明\n- 質疑応答\n- 連絡先の交換\n- 終了の挨拶\n\n会議のキーワード:\n- Security\n- 3SHAKE\n- インキュベーション\n- スタートアップ\n- 起業\n- ビジネス\n- アイデア\n- 技術\n- マーケティング\n- 営業\n- 資金調達\n- 人事\n- 組織\n- 文化\n- ビジョン\n- ミッション\n- バリュー\n- 戦略\n- 戦術\n- イノベーション\n- クリエイティビティ\n- 生産性\n- 効率性\n- 品質\n- コスト\n- スケジュール\n- リスク\n- 課題\n- 問題\n- 解決策\n- 提案\n- 意見\n- 感想\n- 要望\n- 期待\n- 不安\n- 懸念\n- 悩み\n- ストレス\n- プレッシャー\n- 責任\n- 義務\n- 期待\n- 信頼\n- 尊敬\n- 協力\n- 団結\n- チームワーク\n- コミュニケーション\n- 情報共有\n- 知識共有\n- 学習\n- 成長\n- 発展\n- 進歩\n- 未来\n- 可能性\n- 夢\n- 希望\n\n話し方(沈黙回数、ラリー回数、会話被り、TalkListen比率、抑揚スコア、話し方の速度):\n- 沈黙回数:10回\n- ラリー回数:20回\n- 会話被り:3回\n- TalkListen比率:1.5\n- 抑揚スコア:5\n- 話し方の速度:120語/分\n\n会議の要約:\n3SHAKEのA氏と氏が、Securityについて議論する会議に出席しました。会議では、Securityの重要性や、3SHAKEが提供するSecurityサービスについて説明がありました。また、質疑応答では、参加者からSecurityに対する質問が寄せられ、A氏と氏が回答しました。会議の最後に、連絡先の交換が行われ、終了しました。"}],"role":"model"},"finish_reason":1,"safety_ratings":[{"category":1,"probability":1,"probability_score":0.14718707,"severity":1,"severity_score":0.096705794},{"category":2,"probability":1,"probability_score":0.16708273,"severity":2,"severity_score":0.2260994},{"category":3,"probability":1,"probability_score":0.155591,"severity":1,"severity_score":0.14780101},{"category":4,"probability":1,"probability_score":0.07043162,"severity":1,"severity_score":0.058024753}]}],"usage_metadata":{"candidates_token_count":489,"prompt_token_count":1113,"total_token_count":1602}}

(議事録内容もかなり正確ですが、しれっと話者分離やラリー数、話者速度などもカウントできており、既存の音声AIツールを凌駕しています)

複雑なバッチプログラムを書く必要もなく、パイプラインを組む必要もなく、シンプルなSQLでBigQueryに保存されているメタデータを使って、生成AIが使えて、その結果をそのまま、またBigQueryに保存して利活用することができるのです。

更に言うと、以下のように画像分類やアノテーション、ベクトル化など、用途に合わせたモデルの組み合わせでBigQuery内でほぼパイプラインが完結してしまいます。

ml.generate_text(テキスト生成)という関数も強力ですが、今後注目されるのはml.generate_embeddingというベクトル化関数ではないかなと思います。

生成AIをより高度に音声や画像、動画をベクトル化してRAGを構築 / 運用していく際、どこでどうやってベクトル化するんだっけ?という点で、SQL一発でベクトル化して、更にベクトルデータベースとして検索もできてしまう部分はめちゃくちゃ強力なソリューションになると思います。
(他クラウドでは、ベクトル検索ができるソリューションはあれど、ベクトル化する部分まで一体化されてはいない。このあたりがバラバラで、結局複雑なプログラムを作って運用しなくてはいけない)

最後にいつもの

如何だったでしょうか。生成AIがエンジニアリング領域にかなり大きいインパクトを残しつつ、その先導をきっているのが現時点だとGoogle Cloudだと思います。しかしながら他クラウドも猛追するでしょうから、これからどうなっていくか楽しみな時代ですね!

Japan Sessionにて

はじめてこのnoteを見た方は、Google Cloud Next'24の記事も見てくださいませ!


スリーシェイクではエンジニア職・ビジネス職ともに絶賛募集中です。

ぜひ一緒に、インフラをシンプルにして世の中にイノベーションを起こしていきましょう!