【Google Cloud Next Tokyo '26】Gemini Sparkを触ってわかったノーコードAIエージェントの立ち位置
はじめに
2026年8月21日(金)の19時から、「Gemini Sparkを触る会」という勉強会を個人主催で開催しました。
事前資料は作らず、公式ドキュメントを画面に出しながらライブで触る、という形式です。YouTube Liveで配信したのでアーカイブも残っています。
この記事では、勉強会でGemini Sparkを触ってみて考えたこと ——「ノーコードAIエージェントの立ち位置」と「これからのエンジニアの役割」について書きます。
Gemini Sparkとは
Gemini Sparkの存在を知ったのは、7月30日のGoogle Cloud Next Tokyo Day 1の基調講演でした。
Gemini Appの画面から使える機能で、ざっくり言うとクラウド上のAIエージェントを、ノーコード・プロンプトのみで作れるというものです。
- コードを書かずにプロンプトだけでエージェントを構成できる
- 定時実行のスケジューリングができる
- 夜間や就寝中に走らせておくタスクも、プロンプトだけで組める
「作る」の敷居が一段下がった感覚があって、これは可能性があるなと思い、勉強会をやってみることにしました。
勉強会の形式:事前資料なし・ライブ中心
今回、事前準備をしっかりやるのではなく、自分で色々触ってみてライブ中心で進めるという形にしました。
結果としてこれが良かったです。
- 発表者である自分自身が面白い
- 聞いている側も、生の動きを見られる
- スライドに焼き直す手間がないぶん、情報が新鮮なまま届く
新機能は、スライドを作った瞬間から陳腐化が始まります。公式ドキュメント自体がよくできているので、それを画面に出して喋るほうが正確で速い。準備コストがほぼゼロで登壇できる形式として、今後も使えそうだと感じました。
気づき:活用事例に「フルスクラッチ」が少ない
ノーコードでAIエージェントを触ったあと、Google Cloud Next Tokyoの基調講演のアーカイブを見返し、会場で配布されていたAI活用事例集も改めて読み直してみました。
そこで気づいたことがあります。
Gemini EnterpriseやGoogle Workspaceで業務効率を改善した、という話が非常に多い。逆に、フルスクラッチで作った事例は少ない。
基調講演でもGemini Enterpriseの話が多く、ローコード系の話題が中心でした。エンドユーザー企業が登壇しているセッションでも同様の傾向がありました。
これは偶然ではなく、いくつか構造的な理由がありそうです。
事例として出しやすい
フルスクラッチで開発したものは、社内の機密に触れる部分が多く、外に出しにくい。横展開もしにくい。
一方、Gemini Enterpriseのような標準サービスを使った事例は、他社でも再現できる形になっているので、活用事例集に載せやすいし、カンファレンスでも発表しやすい。
成果が出るのが早い
業務のドメイン知識を持っているのはビジネスサイドです。その人たちが自分でGemini Enterpriseを触って業務改善するほうが、エンジニアに依頼するより成果が出やすい。エンジニアに任せると、どうしても時間がかかる領域があります。
ノーコード・ローコードから小さく始めるべき理由
以上を踏まえると、AIエージェントを導入するにあたっては、いきなりフルスクラッチで作るより、まずノーコード・ローコードで小さくスタートするほうが合理的だと考えるようになりました。
理由は3つあります。
1. 現場がAIエージェントを理解する手段になる
現場の人が自分の手で触って、何ができて何ができないかを掴む。これは資料を読んで理解するのとは質が違います。
2. 投資対効果で有利
初期導入コストが安く、立ち上がりが早い。SaaS的なプロダクトなので、バージョンアップは提供元(Google)がやってくれる。常に最新の状態に追従していける。
3. モデルの進化速度に対して、開発期間が長すぎる
これが一番大きい理由です。
大企業の本番システムを作ろうとすると、普通に1年、場合によってはそれ以上かかります。生成AIで同じことをやると、作っている間にモデルが劇的に高性能になってしまう。
完成した頃には「自分たちは何をやっていたんだろう」という状態になりかねない。実際にそういうことが起きうる速度で進化しています。
エンジニアの役割はどう変わるか
エンジニアという職業は、どうしてもフルスクラッチで作ることを前提に考えがちです。自分もそうでした。
でも、プログラマの美徳のひとつは「怠惰(Laziness)」であるはずです。作らなくて済むなら作らない、という発想も大事にしないといけない。
ただし、「サービスを組み合わせる」のは決して簡単な仕事ではありません。
たとえばGoogleのプロダクトを組み合わせるなら、Google Cloud認定資格で問われるようなベストプラクティスを、知識として持ったうえで運用に落とし込む必要があります。これは十分に高度な仕事です。
そしてスクラッチ開発が消えるわけでもありません。むしろ、組み合わせでは解けない高難度な部分だけが残っていく。ここは非エンジニアがバイブコーディングで作るのは難しい領域です。
つまり、AI駆動開発時代のエンジニアは、大きく2つの方向に分かれていくのではないかと考えています。
| 方向性 | 役割 |
|---|---|
| デベロッパー的 | 組み合わせでは解けない、難易度の高い部分をスクラッチで開発する |
| クラウドエンジニア的 | サービスを最適にインテグレートし、ソリューションを設計する |
もちろん両方できる人もいるでしょうが、この2つが軸になっていくイメージを持ちました。
Gemini Enterpriseの強さ
ここまでノーコード・ローコードの話をしてきましたが、ひとつ補足しておきたいことがあります。
Gemini Enterpriseは、ノーコード・ローコードでも使えるし、ADK(Agent Development Kit)で作ったAIエージェントを載せることもできる。
つまり、両方を同じ場所に置けます。
- 非エンジニアがノーコード・ローコードでどんどん使い倒す
- どうしても難しい部分は、エンジニアがADKでエージェントを作って載せる
そのうえで、Gemini Enterprise最大のメリットはITガバナンスが効くことだと思っています。Google Workspaceと同様のガバナンスモデルになるので、情シス的にも導入判断がしやすい。エージェントを載せていっても管理が効く、というのは運用上かなり大きい話です。
社内ノウハウの共有という観点でも有利です。フルスクラッチでRAGを構築するより、標準機能で整備したほうが楽ですし、ノウハウが特定の実装に紐づかず組織に溜まっていく。
まとめ
Gemini Sparkを触ってみて、実際に手を動かしたこと自体よりも、そこから「AIエージェントとどう付き合うか」を考え直すきっかけになったのが大きかったです。
- ノーコード・ローコードで小さく始めるほうが、現場理解・投資対効果・モデル進化速度への追従、いずれの観点でも有利
- エンジニアの役割は「高難度スクラッチ」と「最適なインテグレーション」に分かれていきそう
- Gemini Enterpriseは、ノーコードとADKの両方を同じガバナンス下に置ける点が強い
- 作ることだけが業務効率改善ではない
一方で、業務投入を考えるなら確認しないといけないことが残っています。
- ノーコードで組んだエージェントの挙動の再現性をどう担保するか
- トレースはどこまで取れるのか、内部がどれだけ観測できるのか
- 誰が作ったエージェントの責任を、誰が持つのか
このあたりは、いずれ検証して書きたいと思います。
勉強会のアーカイブはYouTubeに残っているので、実際の動きを見たい方はそちらもどうぞ。
Discussion