Gemini Sparkを触る勉強会をやってみて考えた、ノーコードAIエージェントとこれからのエンジニア

2026年8月21日、Google公式のAIエージェント構築機能「Gemini Spark」を実際に触ってみる勉強会が開催された。事前資料を作らず、公式ドキュメントを画面に出しながらライブで動かすという形式だったが、その中で浮かび上がってきたのは、「AIエージェント導入時代のエンジニアの役割が確実に変わる」という現実である。Gemini Sparkはコードを書かずにプロンプトだけでエージェントを構成でき、スケジューリングもできる。発表者自身が「これは可能性がある」と感じた通り、従来のシステム開発とは全く別の選択肢が生まれたのだ。

注目すべきは、大企業のAI活用事例の実態である。Google Cloud Next Tokyoの基調講演やAI活用事例集を改めて調査すると、Gemini Enterpriseのような既製サービスを使った事例が圧倒的に多い一方で、フルスクラッチで開発した事例は驚くほど少ない。なぜか。理由は複数あるが、最大のものはモデル進化速度への適応問題だ。大企業の本番システムを0から作れば通常1年以上かかる。その間に生成AIモデルは劇的に高性能化する。完成時には「何のために1年かけたのか」という状況に陥りかねない。これは決して仮説ではなく、実際に起きうる速度で進化している。一方、ノーコード・ローコードなら立ち上がりが早く、プロバイダー（Google）が常にアップデートしてくれる。モデル進化に自動で追従できるメリットは、開発期間の短さだけでは説明できない競争優位性である。

中小企業の実務判断としては、AIエージェント導入時にいきなりフルスクラッチに走るべきではない。むしろノーコード・ローコードで小さく始めるべきだ。理由は三つ：現場がAIエージェントの可能・不可能を自分の手で理解できる、初期コストが安い、モデル進化に追従できる。そのうえで、どうしても解けない高難度な部分だけをエンジニアが作る。Gemini Enterpriseの強さはここにある。ノーコードと本格開発エージェント（ADK）を同じガバナンス下に置け、組織ノウハウが実装に紐づかず組織資産として蓄積される。エンジニアの役割は「何をスクラッチで作るか」から「何を組み合わせるか」へ。この転換が、これからの企業競争力を分ける。