※このストーリーは、noteで発信した記事を転載しています。
目次 毎日、誰かが「人間がやらなくていい作業」をしている 自己紹介と、一つの告白 60分の手作業が「10秒」に。魔法の正体は『GAS』 現場でよく見るリアルな課題 今回の授業で「手段」として選んだのはGAS 60分 → 10秒の衝撃 【講義の核心】「AIに丸投げ」はなぜ失敗するのか まず、動くものはできる 「丸投げ」が失敗する本質 考えるための道具として「Webの3層構造」を知る 考えた内容をAIに正確に伝える「4要素」 エラーが出てきた時の対応方法 「考えることをやめた瞬間に、AIに使われる側になる」 【カンリーの実例】「3層のアーキテクチャ」で作った商談管理システム おわりに:「規模の壁」と、次へのステップ 魔法には限界もある 明日から始められること 毎日、誰かが「人間がやらなくていい作業」をしている 「スプレッドシートから別のシステムへのコピペ」「未提出者を目視で探して、BCCに一人ずつメアドを貼り付けて催促メール」「名簿と現物の突き合わせ確認」… こういう作業に、今日も誰かの時間が奪われています。 昨年投稿したAdvent Calendarの記事 をきっかけに、先日ZEN大学の「デジタルトランスフォーメーション時代の働き方」という授業で大学生向けに90分登壇する機会をいただきました。
伝えたかったのは、ツールの使い方ではなく、 「人間がやらなくていい作業を、どう機械に渡すか」という考え方 です。 今日はその講義のハイライトをお届けしながら、私が日々実践していることを書いてみます。
自己紹介と、一つの告白 改めて、株式会社カンリーのAX(AI Transformation)部に所属している池田と申します。 カンリーは「カンリー店舗集客」というクラウドサービスを主軸とするスタートアップで、私はAI活用を通じた各部署の業務プロセスの変革を社内で推進しています。そんな私が登壇の冒頭で学生さんたちに言った一言があります。 「私、コードは一切書けません」 コードが書けなくても、AIを使えば業務を変えられる。ただし、ただ「AIに丸投げ」するだけでは失敗します。今日は講義で学生の皆さんに伝えたリアルをお伝えします。
60分の手作業が「10秒」に。魔法の正体は『GAS』 現場でよく見るリアルな課題 今回の授業では、まず「現場でよく見るめんどうな作業」を4つ紹介しました。
提出状況を目視で確認して、未提出者に1件ずつ催促を送る BCCにメアドをコピペして、何十件かに分けてメールを送る 複雑なシステムへの手入力でミスが多発する 紙のリストと現物を人間の目で1件1件突き合わせる これ全部、「人間がやらなくていい作業」です。
今回の授業で「手段」として選んだのはGAS さまざまなAIやツールが溢れている今、何から始めればいいか分からない、という方も多いと思います。私自身、日々の業務ではAIエージェントからノーコードツールまで幅広く使っています。 その中で今回の大学授業で取り上げたのが、 Google Apps Script(GAS) です。 選んだ理由はシンプルで、「無料・インストール不要・今日から使える」という条件が学生さんに最適だったから。そして何より、AIとの組み合わせで威力を発揮しやすいツールだからです。 GASは、Google のだいたいのサービスをAIで生成したコードで自動化できます。GmailもスプレッドシートもGoogle カレンダーも、さらにSlackや他社ツールとのAPI連携まで対応しています。
60分 → 10秒の衝撃 授業で紹介した例がこれです。「講義の参加者50人分の専用フォルダを、それぞれに課題ファイルをコピーして権限設定して作ってほしい」というタスク。
「めんどうなことは機械にやってもらう」 ——これがすべての出発点です。
【講義の核心】「AIに丸投げ」はなぜ失敗するのか まず、動くものはできる 授業の後半、こんなオーダーをそのままAIに入れてもらいました。 「スマホから申し込める画面が欲しい。名前・学年・学籍番号・参加したい日・質問の4つを入力させて。Google フォームよりかっこいいやつ。申し込んだらスプレッドシートにデータが溜まるように。申し込んだ人には『ありがとう』って画面を出して」 AIはちゃんと「それっぽいフォーム」を作ってきます。動く。見た目もそこそこ。
要望をそのまま入れた時のフォームがこちら
でも実際に「これ、明日のイベントで使おう」と思ったとき、問題が次々と出てくるかと思います。
必須・任意の区別がない 「申し込む」を押したら確認画面なしで即送信される 何かあった時の連絡先がない 申込受付メールを返信した方が良いのでは 学籍番号にバリデーション(半角英数字のみ等)がない 全日程参加したい人の選択肢がない 個人情報を取るのに同意欄がない AIは悪くありません。 私が「指示しなかったこと」を、AIはやらなかった だけです。
「丸投げ」が失敗する本質 ここが今日の一番大事なポイントです。 AIに丸投げすると失敗する理由は、「コードが書けないから」でも「AIの精度が低いから」でもありません。 「何が必要かを自分で考えないまま、AIに投げているから」 です。 先ほどのフォームで言えば、そもそも「申し込みフォームに何が必要か」を自分で考えていない。UXはどうあるべきか。個人情報を扱う責任は何か。ユーザーが操作を間違えたときどうするか。これらを考えずにAIに丸投げすれば、「動くけど使えないもの」が出てくるのは当然です。 (もちろん、依頼者に「これで問題ないか」について確認をとることも重要です。)
考えるための道具として「Webの3層構造」を知る では、どうすれば漏れなく考えられるか。 そのために授業で紹介したのが、Webサービスの基本構造です。世の中のサービスは基本的にこの3層でできています。
Amazon、X(旧Twitter)、大学の履修登録システム——全部この構造です。 この3層を頭に置くと、「何を考えるべきか」の視点が変わります。
フロントエンドの視点 で考える → 「確認画面はいるか?」「入力ミスをその場で教えるか?」 バックエンドの視点 で考える → 「重複登録を防ぐロジックはいるか?」「エラーが起きたとき何を返すか?」 データベースの視点 で考える → 「個人情報を保存するなら同意は必要か?」「どのデータを残してどれを捨てるか?」 3層構造は「AIへの指示をうまくするためのテクニック」ではありません。 自分が作ろうとしているものを、漏れなく考えるための思考の枠組み です。そしてその考えをAIに渡すことで、初めて「使えるもの」が出てくる。
※調整したフォームはこちら(もっと考慮要件あるかも)
考えた内容をAIに正確に伝える「4要素」 自分の頭で要件を整理できたら、次はそれをAIに正確に渡す番です。 講義で紹介した「失敗しないプロンプトの4要素」がこれです。 ① 前提を伝える 何をどういった形で実装したいか、という現状を具体的に書く。 ② 実現したい機能を明確にする 「何をトリガーに、何をどう動かしたいか」などをセットで書く。 ③ 制約条件を書く 「重複は避ける」「エラー時はメッセージを出す」など、守ってほしいルールを明示する。 ④ 実装前にAIに確認させる 「不明な点があれば実装前に聞いてください」と一言添えるだけで、認識のズレを事前に防げる。 要するに、 3層構造で「何が必要か」を考え、4要素でそれをAIに渡す 。この2ステップが、「丸投げ」と「活用」を分ける境界線です。
先ほどの申込フォームの内容に照らし合わせると、以下のようなプロンプトを入れました。
スマホから申し込みができ、標準のGoogle フォームよりもデザイン性が高く、スプレッドシートにデータが自動蓄積されるWebフォームシステムのコードを作成してください。 ■前提 ・フロントエンドは HTML / CSS / JavaScript で実装し、 GAS (Google Apps Script)のWebアプリとして公開すること。 ・バックエンドは GAS を使用し、送信データを指定のGoogle スプレッドシートへ保存すること。 ・モバイルファーストで、スマホから見やすく洗練されたモダンなデザイン(Tailwind CSS やBootstrap等の利用を推奨)にすること。 ■画面構成 以下の 3 つの画面を、JavaScriptを用いてページ遷移なしで切り替える仕様にすること。 入力画面:ユーザーが情報を入力する画面。最下部にはトラブル時の「お問い合わせ先(事務局メールアドレス等)」を明記すること。 確認画面:送信前に誤入力がないか確認する画面(「修正する」「申し込む」ボタンを設置)。 完了画面:「お申し込みありがとうございます」というメッセージと、事務局の連絡先を再度大きく表示するサンクスページ。 ■入力項目とバリデーション条件 名前 【必須】 メールアドレス 【必須】(正しいメールアドレス形式かチェック。自動返信の宛先になります) 学年 【必須】(セレクトボックス形式: 1 年〜 4 年など) 学籍番号 【必須】(半角英数字のみ許可。全角等それ以外の文字が入力された場合は、リアルタイムでエラーメッセージを表示して送信不可にする) 参加希望日 【必須】(チェックボックス形式。「第 1 回」「第 2 回」「第 3 回」を用意し、複数選択可。全部参加の場合はすべてにチェックを入れる想定) 質問 【任意】(テキストエリア) 個人情報の取り扱いに関する同意 【必須】(「同意する」のチェックボックス。チェックしないと確認画面へ進めない仕様) ■実現したい機能(バックエンド / GAS ) ・フロントエンドからデータを受け取り、スプレッドシート(シート名:「申し込みデータ」)の A 列から順(タイムスタンプ、名前、メールアドレス、学年、学籍番号、参加日、質問)に書き込む処理。 ・スプレッドシートへの書き込み完了と同時に、ユーザーのメールアドレス宛に「自動返信メール(申し込み控え)」を送信する処理。 ・自動返信メールの本文には、入力内容の控えに加え、「内容の変更やキャンセル、その他何かあった際のお問い合わせ先」を必ず記載すること。 ■制約・考慮事項 ・送信ボタンの連続タップによる「二重送信」を防止するため、送信処理中はボタンを無効化(ローディング表示など)すること。 ・コピペしてすぐに動作確認ができるよう、 GAS の コード . gs と index . html に分けた形の具体的なコードを提示すること。 ・スプレッドシート ID や事務局のメールアドレスなど、後から変更する可能性が高い値は、コード冒頭で変数としてまとめて定義しておくこと。 ■質問・確認事項 実装にあたり、要件に矛盾がある場合や、スプレッドシートの事前準備(ヘッダー行の設定など)で私が行っておくべき作業があれば、コード提示の前に教えてください。 スマホから申し込みができ、標準のGoogle フォームよりもデザイン性が高く、スプレッドシートにデータが自動蓄積されるWebフォームシステムのコードを作成してください。 ■前提 ・フロントエンドは HTML / CSS / JavaScript で実装し、 GAS (Google Apps Script)のWebアプリとして公開すること。 ・バックエンドは GAS を使用し、送信データを指定のGoogle スプレッドシートへ保存すること。 ・モバイルファーストで、スマホから見やすく洗練されたモダンなデザイン(Tailwind CSS やBootstrap等の利用を推奨)にすること。 ■画面構成 以下の 3 つの画面を、JavaScriptを用いてページ遷移なしで切り替える仕様にすること。 入力画面:ユーザーが情報を入力する画面。最下部にはトラブル時の「お問い合わせ先(事務局メールアドレス等)」を明記すること。 確認画面:送信前に誤入力がないか確認する画面(「修正する」「申し込む」ボタンを設置)。 完了画面:「お申し込みありがとうございます」というメッセージと、事務局の連絡先を再度大きく表示するサンクスページ。 ■入力項目とバリデーション条件 名前 【必須】 メールアドレス 【必須】(正しいメールアドレス形式かチェック。自動返信の宛先になります) 学年 【必須】(セレクトボックス形式: 1 年〜 4 年など) 学籍番号 【必須】(半角英数字のみ許可。全角等それ以外の文字が入力された場合は、リアルタイムでエラーメッセージを表示して送信不可にする) 参加希望日 【必須】(チェックボックス形式。「第 1 回」「第 2 回」「第 3 回」を用意し、複数選択可。全部参加の場合はすべてにチェックを入れる想定) 質問 【任意】(テキストエリア) 個人情報の取り扱いに関する同意 【必須】(「同意する」のチェックボックス。チェックしないと確認画面へ進めない仕様) ■実現したい機能(バックエンド / GAS ) ・フロントエンドからデータを受け取り、スプレッドシート(シート名:「申し込みデータ」)の A 列から順(タイムスタンプ、名前、メールアドレス、学年、学籍番号、参加日、質問)に書き込む処理。 ・スプレッドシートへの書き込み完了と同時に、ユーザーのメールアドレス宛に「自動返信メール(申し込み控え)」を送信する処理。 ・自動返信メールの本文には、入力内容の控えに加え、「内容の変更やキャンセル、その他何かあった際のお問い合わせ先」を必ず記載すること。 ■制約・考慮事項 ・送信ボタンの連続タップによる「二重送信」を防止するため、送信処理中はボタンを無効化(ローディング表示など)すること。 ・コピペしてすぐに動作確認ができるよう、 GAS の コード . gs と index . html に分けた形の具体的なコードを提示すること。 ・スプレッドシート ID や事務局のメールアドレスなど、後から変更する可能性が高い値は、コード冒頭で変数としてまとめて定義しておくこと。 ■質問・確認事項 実装にあたり、要件に矛盾がある場合や、スプレッドシートの事前準備(ヘッダー行の設定など)で私が行っておくべき作業があれば、コード提示の前に教えてください。 copy
※これを全部書けなくて大丈夫です。AIと対話しながら要件を足していくやり方で問題ありません。
エラーが出てきた時の対応方法 ここまで詳細に要件を伝えても、いざ実行すると赤い文字でエラーが出たり、想定と違う動きをしたりすることはよくあります。でも、ここで「やっぱり自分には無理だ」と諦める必要はまったくありません。
プログラミング知識がゼロの私たちには、「壁打ち」というもう一つの魔法があります。
エラーが出たら、悩まずにそのエラーメッセージをそのままコピーして「こんなエラーが出ました。どう直せばいいですか?」とAIに投げ返せばいいのです。AIは「申し訳ありません、この部分の記述が抜けていました」と、修正版のコードと直した理由を丁寧に教えてくれます。
1回の指示で完璧なものを作ろうとするのではなく、エラーが出たらAIに相談し、対話しながら一緒に完成させていく。この「壁打ち」の感覚を持つことが、AIを使った業務改善で挫折しない最大のコツです。
「考えることをやめた瞬間に、AIに使われる側になる」 講義の最後に伝えた言葉です。 AIが普及するほど、「AIを使う人」と「AIに使われる人」の差は広がります。その分岐点は技術力ではなく、 思考を手放さないこと だと私は思っています。
【カンリーの実例】「3層のアーキテクチャ」で作った商談管理システム 授業ではカンリー社内で実際に動いているシステムを紹介しました。 スプレッドシートを「冷蔵庫(データベース)」に、GASを「厨房(処理)」に、Looker StudioのグラフをGASのHTML画面に埋め込んで「ホール(見える部分)」に。 Looker Studio(現:データポータル)とは、Google が無料で提供するBIツールです。スプレッドシートと直結していて、データが更新されると自動でグラフが変わります。このグラフをiframeでGASのHTML管理画面に組み込むことで、「入力すればグラフが更新される一枚岩の管理画面」が完成しました。
期日超過の案件をSlackに自動アラート通知 KPIや商談一覧の一画面での管理 ほぼリアルタイムで更新されるグラフ・分析画面 社内報告用の資料を手作業で作る仕事が、ゼロになりました。使っているのは全部無料のGoogle サービスです。 このシステムを設計するとき、私が最初にやったのはコードを書くことでも、AIに丸投げすることでもありませんでした。「冷蔵庫・厨房・ホール、それぞれに何が必要か」を考えることでした。
おわりに:「規模の壁」と、次へのステップ 魔法には限界もある 一点、誠実にお伝えしたいことがあります。 「50人分のフォルダ作成なら10秒」でも、「全国100万人分になったら?」という話をしました。処理に時間がかかりすぎてシステムがパンクする。そのとき必要になるのが、計算量やアルゴリズムといった情報学の基礎知識です。 GASはあくまで入口です。「魔法をもっと大規模に安全に使いたい」と思ったとき、その先の学びが必要になる。講義の最後はそのバトンを担当講師である小田先生に渡す形で締めました。
明日から始められること 明日、自分の周りの小さな「めんどう」をAIに相談してみてください。 ただし、相談する前に少しだけ考える。「この作業、何をしているか」「何があれば自動化できるか」——その10分の思考が、AIのアウトプットをまったく変えます。 コードが書けなくても、ITは武器になります。その体験を、90分で届けられたとすれば、嬉しいです。 授業の最後に、Google Meetのチャットにこんなメッセージが流れてきました。 「めっちゃくちゃわかりやすかったです」 「やっと完成!!感動です」 「うまくいきました。本当にありがとうございました。」 正直、これが一番嬉しかったです。知識の話より、 「自分の力でプログラムが動いた」 という体験が、何かのきっかけになってくれたら十分だと思っています。 カンリーのAX部では、こうしたAI活用・業務改善の知見を社内外で発信していきます。「うちでもやってみたい」「話を聞いてみたい」という方は、ぜひお声がけください。
※求人募集もしています。