はじめに
こんにちは！開発エンジニアのクリスです！
今年も Google Cloud Next Tokyo 26 に参加してきました！
数あるセッションの中から、Day 1 の「Google Workspace 拡張開発の現在地 ― “AI 駆動開発”がもたらす変化と成果」のレポートをお届けします。
普段から Google Workspace や AppSheet を使った業務改善に取り組んでいる私にとって、「Workspace の拡張開発が生成 AI でどう変わるのか」というテーマは見逃せませんでした。保守性や運用負荷といった、拡張開発の「あるある」な悩みにも踏み込む内容で、とても実践的なセッションでした！
セッション概要
タイトル：Google Workspace 拡張開発の現在地 ― “AI 駆動開発”がもたらす変化と成果
登壇者：
- 大岡 咲菜 氏（NTTインテグレーション データ&アナリティクス事業本部クラウドインテグレーション部第四グループ）
- 北脇 孝太 氏（NTTインテグレーション データ&アナリティクス事業本部クラウドインテグレーション部）
日時・会場：Day 1（7 月 30 日）13:00 – 13:30 / Room 7（セッション ID：D1-GOL-03）
公式カタログの紹介文は以下のとおりです。
Gmail やドライブ、スプレッドシートなどを土台に、業務に合わせた独自の仕組みを作る――それが Google Workspace の拡張開発です。自動化、ワークフロー化、独自アプリの構築まで、できることは想像以上に広がっています。そして生成 AI の登場で、「何を使って、どう作るか」の答えも変わりつつあります。業務効率化や DX に取り組むご担当者様に向けて、AI が拡張開発にもたらす変化と成果、保守性の担保や運用負荷への対応、そして明日から活かせる選び方を、XIMIX の知見と具体事例とともにお話しします。
Google Workspace 拡張開発の現在地
セッションは「業務効率化は、欠かせないものである」という話から始まりました。
これまで Google Workspace 上の効率化といえば、GAS（Google Apps Script）や AppSheet が主流でした。ところが、扱うデータが増えるにつれて、その主流だった組み合わせだけでは不十分になってくる。だからこそ AI が必要になる ― という問題提起です。冒頭からいきなり刺さりますね（笑）。
拡張開発の 3 つの手段
そもそも「拡張開発」の手段は、大きく 3 つに整理できます。
| 手段 | 代表的なツール | 位置づけ |
|---|---|---|
| ノーコード | AppSheet、Google フォーム | 現場完結、スピード最重視 |
| ローコード | GAS | 現場完結、スピード最重視 |
| フルスクラッチ | Python、Java など | 大規模、複雑、高品質 |
ノーコードとローコードは現場完結でスピードを最重視するアプローチ、フルスクラッチは大規模かつ複雑な要件に高い品質で応えるアプローチ、という住み分けです。ここまでは、日々ツールを選んでいる感覚とぴったり重なりますよね。
なぜ「拡張開発」が必要なのか？
個人的に一番腑に落ちたのが、拡張開発の目的の説明でした。それは統制とガバナンスの強制です。
「このサイトは外部公開しないでください」「このファイルは共有しないでください」とお願いして回る運用、つまり人に依存したセキュリティ管理には、どうしても限界があります。ルールを守ってもらうのではなく、守らざるを得ない仕組みを作ってしまう。それを実現する手段が拡張開発である、という整理です。
効率化の文脈で語られがちな拡張開発を、ガバナンスの手段として位置づけるこの説明は、なかなか新鮮でした。
事例：Google サイトの作成申請をワークフロー化
その具体例として紹介されたのが、Google サイトの作成申請の事例です。
- 課題：Google サイトは誰でも自由に作成できてしまうため、情報漏洩のリスクがある
- 方法：AppSheet と GAS を組み合わせ、申請の仕組みを短期間で展開する
- 結果：承認プロセスがシステム化され、漏洩リスクを防げるようになった
「誰でも作れてしまう」状態を「申請して承認されたら作れる」状態に変える。やっていること自体はシンプルですが、これがまさに先ほどの「統制の強制」ですよね。しかもノーコードとローコードの組み合わせなので、短期間で展開できたというのがポイントです。
運用してみて見えてきた 3 つの課題
ここからが本題です。スピード重視で展開できるノーコード・ローコードにも、複雑な業務要件を載せていくうちに、当初は予見し得なかった運用上の課題が出てきたそうです。
課題 1：リリース管理が難しい
AppSheet は CI/CD ができません。つまり、変更をどう検証してどう本番に反映するか、というリリース管理の部分を仕組みで担保しづらいわけです。アプリが増えていくほど、ここは重くのしかかってきますよね。
課題 2：強引な設計による複雑化
複雑な処理を GAS 側で無理に担保しようとすると、実行時間の制限に引っかかったり、エラーハンドリングが不足したりする。「とりあえず GAS でやっておこう」を積み重ねた先に待っている展開で、心当たりのある方も多いのではないでしょうか（私も少し目が泳ぎました）。
課題 3：データ量による速度遅延
データが数万件規模になると、AppSheet の表示がとても遅くなります。そして速度を保つために、数ヶ月に一度データを整理するといった運用の手間が発生してしまう。ツールの得意な範囲を超えたところで、じわじわと運用コストに変わっていくパターンです。
“AI 駆動開発” がもたらす変化
これら 3 つの課題に対する答えとして提示されたのが、生成 AI ＋ フルスクラッチという組み合わせでした。
スピードと品質のトレードオフが消えた
従来の構図はこうでした。
| アプローチ | スピード | 複雑なロジックへの対応 |
|---|---|---|
| ノーコード / ローコード | 速い | 不向き |
| フルスクラッチ（従来） | 遅い | 得意 |
| 生成 AI ＋ フルスクラッチ | 速い | 得意 |
「速いが複雑なロジックには向かない」か「複雑なロジックに強いが遅い」か。この二択を前提に手段を選んでいたのが、これまででした。それが生成 AI によって、スピードと品質のトレードオフそのものが消えたというのです。
セッションでは QCD（品質・コスト・納期）の観点でも整理が示され、生成 AI ＋ フルスクラッチがそのすべてを満たす、という結論が提示されていました。
3 つの課題はこう解決される
そして、先ほどの課題がきれいに回収されます。
- 課題 1（リリース管理）：フルスクラッチなので CI/CD を組める
- 課題 2（強引な設計）：実行時間などのプラットフォーム固有の制限から解放される
- 課題 3（データ量）：ページネーションを実装すれば、表示速度の問題は解消できる
3 つとも「フルスクラッチなら普通にできること」なんですよね。これまではそのフルスクラッチのコストが高すぎて選べなかった。そのコストを生成 AI が下げてくれた、という筋書きです。とても納得感がありました。
保守性の担保と運用負荷への対応
とはいえ、速く作れるようになったからといって「じゃあ全部フルスクラッチで」とはいきません。ここからが、私が一番聞きたかったパートです。
強調されていたのは、品質管理と標準化が欠かせないということ。生成 AI を使った開発は、現状どうしても個人のスキルとノウハウに頼ってしまいがちで、そのまま進めると属人化が発生してしまいます。「あの人が AI で作ったアプリ、あの人しか触れない」という状態は、絶対に避けたいですよね。
そこで、要件定義から設計、製造、試験まで、工程ごとに AI の使い方を標準化し、成果物のレビューまで含めて仕組みに落とし込む、という取り組みが紹介されました。
導入効果
- 品質の担保
- スピードの向上
標準化というと「手間が増えてスピードが落ちる」と思われがちですが、AI の使い方をそろえることで品質とスピードの両方が上がったというのは、示唆的だと思います。
残された課題 ― AI は魔法の杖ではない
そしてセッションは、しっかり地に足のついた話で締められました。残された課題として挙げられたのは次の 3 点です。
- 設計の知識、特にインフラ設計の知識は依然として必要である
- AI は魔法の杖ではない
- 進化し続ける AI 技術と、新たなユースケースに対応していくための、標準化された継続的な運用が必要である
「AI は魔法の杖ではない」。この一言を、実際に生成 AI で開発を回している立場の方が言うからこそ、重みがありますよね。フルスクラッチが現実的な選択肢になった以上、どう作るかを判断するための設計力・インフラ知識はむしろ必要になる、というのは覚えておきたいところです。
まとめ
今回のセッションのポイントを、3 つに整理してみます。
- 拡張開発の目的は、統制とガバナンスの強制である。人がルールを守ることに依存しない仕組みを作ることこそが、拡張開発の価値である。
- ノーコード・ローコードの運用課題は、生成 AI ＋ フルスクラッチで解ける。リリース管理、プラットフォームの制約、データ量による遅延 ― これらは、スピードと品質のトレードオフが消えた今、無理を重ねて回避する必要がなくなった。
- それでも意思決定と標準化は人の仕事である。AI は魔法の杖ではなく、何を使ってどう作るかの取捨選択、そして品質を担保する標準化は残り続ける。
さいごに
Google Workspace の拡張開発は、私自身も AppSheet や Apps Script で日々向き合っているテーマです。一番の学びは、「これまで AppSheet や GAS に無理をさせていた部分は、生成 AI の力を借りてフルスクラッチ側に寄せてもいい」という選択肢が、現実的なコストで手に入ったということでした。
データ量が増えて重くなってきたアプリ、GAS で無理やり組んだ複雑な処理。心当たりのあるものがいくつか思い浮かんだので、まずは「そもそもこれはどの手段が適切なのか」を、標準化とセットで見直してみたいと思います！
生成 AI を味方につけた拡張開発、皆さんもぜひ試してみてください！
最後までお読みいただき、ありがとうございました！
簡単30秒