← 教材一覧へ戻る

脱・属人プログラム — 学習ノート

社内アプリは
Googleの中で作れる

— Workspace Studio・AppSheet・Apps Script の選び方
「置き場所どうする？」の一歩手前で読む話

作ったアプリの置き場所として、よく Vercel・Cloudflare・Netlify の名前が挙がります。ただし社内で使うアプリに限れば、その3社に持ち込む前に「Google Workspace の中だけで完結させる」という選択肢があります。置き場所もログインもデータも最初から揃っていて、多くの場合追加費用ゼロで終わります。この教材はその4つ目の道です。

2026.08.18 作成

この話の結論（4つだけ）
  1. 社内アプリなら、まず「Googleの中」で足りないかを先に見る
    置き場所・ログイン・データが最初から揃っている。Workspaceの料金に含まれていて追加費用ゼロ。独自ドメインも要らない
  2. Googleの中には箱が3つある
    決まった手順の自動化＝Workspace Studio／入力して見る業務アプリ＝AppSheet／画面や独自の処理が要る＝Apps Script
  3. 外に出す目安は4つ。ただし性質が2種類ある
    独自ドメインが要る・1回6分を超える＝仕様上できないので外へ。社外の人が使う・データの本体がGoogleの外＝できなくはないが、外のほうが素直という判断
  4. Claude Code で書けるのは Apps Script だけ。でも一番の事故は「引き継ぎ」
    マイドライブに作ると、担当が辞めて移管されなければアプリが止まる。共有ドライブに置くのが第一歩で、それだけでは足りない（デプロイ・定期実行・外部の承認は人に紐づいたまま残る）

CHAPTER 01

なぜ「置き場所を選ぶ前」にこの話が要るのか

別教材の「作ったアプリをどこに置く？」では、Vercel・Cloudflare・Netlify の3社を比べました。あの教材の判断軸は「サーバー側で何が動くか」——つまり、作ったものを外の会社に預けて動かすことが前提になっています。

ところが社内アプリの場合、その前に確かめることがあります。「そもそも外に預ける必要があるのか」です。

たとえるなら 引っ越し先を「都心のマンションか、郊外の一戸建てか」で比べ始める前に、「そもそも今の家の空き部屋で足りるのでは？」と確かめるようなものです。
Google Workspace を契約している会社は、すでに使っていない部屋をたくさん持っています。社員全員のログインの仕組みも、データの置き場も、毎月の料金の中にもう入っています。

社員だけが使うアプリを外部サービスに置くと、ログインの仕組みを別に作る／権限を二重に管理する／料金がもう一本増えるという手間が生まれます。Googleの中で作れば、これが全部消えます。「＠自社ドメインの人だけ」に絞る設定が、最初から選択肢として用意されているからです。

正直なところ なんでもGoogleの中で作れるわけではありません。むしろできないことがハッキリしているのがこの選択肢の良いところで、第3章の4条件に当たったら、迷わず外（Cloudflare 等）に出せば済みます。

CHAPTER 02

Googleの中にある3つの箱

箱何をするもの作り方費用
Workspace Studio
（旧 Workspace Flows）		Gmail・スプレッドシート・ドライブなどをまたぐ決まった手順の自動化。Gemini入り（要約・下書き・分類ができる）画面でノーコード
やりたいことを文章で説明しても作れる		Business / Enterprise / Education の各プランに追加料金なしで込み
AppSheetスプレッドシート等をデータ元にした入力・閲覧の業務アプリ。スマホで使える（日報・在庫・点検）画面でノーコードAppSheet Core がほぼ全エディションに無料で込み
上位機能は別料金
Apps ScriptGoogleの中で動くプログラム（JavaScript）。独自の画面・スプレッドシート拡張・定時実行・外部連携コード
＝Claude Code の出番		Workspace に込み
従量課金はなく、代わりに実行量の上限がある

「ノーコード」と「コード」の使い分け

3つのうち上2つはノーコード（＝プログラムを書かずに画面の操作だけで作る）、Apps Script だけがコードです。ここで多くの人が迷いますが、判断はシンプルです。

たとえるなら ノーコードはできあいの家具、Apps Script は木材と工具です。
サイズが合うなら、できあいの家具のほうが速いし、壊れても交換が効きます。合わないときだけ木材を切る。「自由だから」という理由だけで木材を選ばない——コードは作った瞬間から、直し続ける人が必要になるからです。

ただし現実には、迷ったら Apps Script で構いません。ノーコードは「型にはまれば速いが、はまらないと途中で詰む」性質があるのに対し、Apps Script は遅いけれど詰まないからです。順番としては、ノーコードで足りるかを1度だけ確かめて、ダメならすぐコードへ。

CHAPTER 03

選び方——先に「外に出す条件」を見る

いきなり3つの箱を比べません。先に「これは外だな」を判定します。ただし、よく挙がる4つの条件は性質が2種類あって、同じ扱いにすると判断を誤ります。

仕様上できない（＝議論の余地なく外へ）

条件理由
独自ドメインで見せたい
例 app.会社名.co.jp		URLは script.google.com/macros/s/… から変えられない。社内なら実害はないが、お客様に見せるものには使わない
1回の処理が6分を超える
動画変換・大量データの一括処理		1回の実行が6分で強制終了する（有料プランでも同じ）
AIの返事を1文字ずつ出したい
顧客向けチャットボット		google.script.run は「投げて待って、一括で返す」作りで、途中経過を流せません（＝ストリーミング不可）。AIの返事は10〜30秒かかるため、その間画面が無言のまま固まって見えます。社内向けなら許容できますが、顧客向けのチャットボットはこれが理由で外へ。あわせて画面はサンドボックス化されたiframeの中で動くため、自社サイトへの埋め込みにも制約が出ます

できなくはない（＝手間と安全性を見て決める）

条件実際のところ
社外の人がログインして使う
取引先・お客様・応募者		Googleアカウントを持つ人になら「Googleアカウントを持つ全員」で配れる。ただし"社外の特定の人だけ"には絞れない（公開範囲は4択しかない）。取引先ごとに出し分けたいなら外へ
データの本体がGoogleの外にある
自社DB・基幹システム		JDBCという仕組みで Cloud SQL・MySQL・SQL Server・Oracle・PostgreSQL に接続できます。ただし接続元IPの許可設定、TLS1.2以上、ポート1025以降といった条件があり、6分の壁とも戦うことになる。既存の基幹システムが主役なら外で作ったほうが早い

当たった場合の行き先は、別教材「作ったアプリをどこに置く？」と「中小企業のためのCloudflare入門」です。とくに社員限定のアプリを外で作るなら、Cloudflare の Access（＝「＠自社ドメインの人だけ通す」関所）が正面から効きます。

当たらなかったら、この表で決める

やりたいこと選ぶ箱
「◯◯が起きたら → △△して → □□に通知」という決まった一本道。専用画面は要らないWorkspace Studio
現場のスマホから入力させたい（日報・在庫・点検・写真つき）AppSheet
スプレッドシートに独自のメニューや関数を足したいApps Script
社員が開く独自の画面が要る（申請・検索・ダッシュボード）Apps Script（Webアプリ）
決まった時刻の定期実行。処理が少し複雑Apps Script（トリガー）
単純なものなら Workspace Studio でも可
処理の途中で Gemini に文章を書かせたいどれでも可
Apps Script なら「Vertex AI サービス」で書ける（第7章）

3つの質問だけで決まる

実務では、次の3つを聞けばだいたい決まります。第8章のプロンプトも、この3問から始まる作りにしてあります。

  1. 誰が使う？（自分だけ／部署の数人／全社員／社外の人も）
    「社外の人も」が出た時点で、Googleの外が確定します
  2. データはどこ？（スプレッドシート／Gmail／ドライブ／Google以外のシステム）
    「Google以外」なら外が有力になります
  3. 専用の画面は要る？（要らない＝裏で自動で動けばいい／要る＝人が開いて入力・検索する）
    要らない→Studio、要る→AppSheet か Apps Script

CHAPTER 04

Apps Script で社内アプリを公開するとどうなるか

Apps Script でコードを書き、デプロイ（＝公開して、使えるURLを出すこと）をすると、次のようなURLが発行されます。これを社員に配れば、それがもう社内アプリです。

https://script.google.com/macros/s/AKfyc…/exec ← 本番用。配るのはこっち https://script.google.com/macros/s/AKfyc…/dev ← テスト用。編集権限がある人しか開けず、常に最新の保存内容で動く

図：発行される2つのURL

公開のときに決める2つ——ここが事故の入口

設定選択肢意味
実行するユーザー
Execute as		自分／アクセスしているユーザー「自分」＝誰が使っても、作成者の権限で動く。使う人がそのデータを見られなくても処理は通る
「アクセスしているユーザー」＝使う人の権限で動く。見えない人には見えない
アクセスできるユーザー
Who has access		自分だけ／同じドメインの全員／Googleアカウントを持つ全員／全員（匿名可）社内アプリなら基本は「同じドメインの全員」。これで社員だけに絞れる
いちばん危ない組み合わせ 「実行＝自分」×「アクセス＝全員（匿名可）」。
正確に言うと、「そのアプリが用意した処理を、URLを知った第三者が、公開した人の権限で実行できる」状態です。スプレッドシート全体を自由に操作されるという意味ではなく、できることの範囲は、書いたコードが用意した処理まで。ただし「一覧を返す」「行を追加する」処理を1つ置いただけで十分な事故になりますし、しかもエラーが出ないので気づけません。
社内アプリを作るときは、アクセス＝「同じドメインの全員」を既定にしてください。

逆に「実行＝アクセスしているユーザー」を選ぶと、見せたくないデータは自動的に見えなくなります（使う人の権限で動くため）。給与や評価のように、人によって見えてはいけないものを扱うなら、こちらが安全側です。

そして、ここには限界があります

公開範囲はさきほどの4つしか選べません。つまり「営業部だけ」「この5人だけ」という指定はできないのです。「同じドメインの全員」は"社員なら誰でも入れる"という意味であって、必要な人だけに絞れているわけではありません。派遣の方、休職中の方、まったく別の部署も含まれます。

部署や担当者だけに見せたいときは、次のどちらかで実現します。

  1. アクセスは「同じドメインの全員」にしたうえで、実行を「アクセスしているユーザー」にし、データ側（スプレッドシートの共有設定やGoogleグループ）で絞る
    ＝権限のない人はアプリを開けても、データが出てこない。いちばん素直な方法です
  2. コード側に「許可する人のリスト」を持たせて、それ以外の人を弾く
    やや手間ですが、細かく制御したいときはこちら

CHAPTER 05

Claude Code で作る（人間の作業とAIの作業）

Apps Script は本来ブラウザの編集画面で書きますが、それだと Claude Code が手を出せません。そこで clasp（クラスプ） を使います。Apps Script のコードをパソコン側のフォルダに置いて、コマンドでアップロードする道具です。

たとえるなら clasp は「原稿を手元で書いて、まとめて入稿する」仕組みです。
これがないと、ブラウザの編集画面に人間が手で打ち込むしかありません。clasp があるから、Claude Code が書いたコードをそのまま Google に送れます。

AIに任せられない作業がある

ここが最初のつまずきどころです。ブラウザの中の操作は、あなたがやるしかありません。

あなたがやるClaude Code がやる
① script.google.com/home/usersettings を開いて「Google Apps Script API」をオンにするプロジェクトを作る・コードを書く
② clasp login のあとブラウザが開くのでGoogleアカウントで承認するアップロードする・公開する
③ 公開したあと、設定を画面で最終確認し、別のアカウントで実際に開いて意図どおりか確かめるエラーを直す・引き継ぎメモを書く
正直に言うと 「手作業はこの3つだけ」ではありません。実際にはNode.jsとclaspの導入、共有ドライブの作成と権限設定、本番データへの接続も、あなたの側に残ります。
AIが肩代わりしてくれるのは「コードを書く部分」であって、環境と権限の判断は人間が持つ——ここは変わりません。逆に言えば、ここさえ握っていれば安全に任せられます。

コマンドは「3系」を使う

clasp は現在 3系で、2系からコマンド名が変わりました。ネットの記事はまだ2系のものが多く、そのまま打っても動きません。AIも古い書き方を出してくることがあるので、ここだけ知っておくと詰まりません。

やること今（3系）古い記事（2系）
新規作成clasp create-scriptclasp create
既存を取り込むclasp clone-scriptclasp clone
アップロードclasp push同じ
公開するclasp create-deploymentclasp deploy
公開を差し替えclasp update-deployment <id>clasp deploy -i <id>
前提として clasp は Node.js の20以上が必要です（npm install @google/clasp -g で入ります）。
また clasp はGoogleの公式ドキュメントに載っていますが、Googleの公式サポート製品ではありません。不具合があってもGoogleに問い合わせできない、という意味です。会社の重要な仕組みをこれだけに依存させないでください（コードはGitHubにも置いておく、が答えになります）。
もう1つの落とし穴 clasp push は、手元のファイルでGoogle側を置き換えます。誰かがブラウザの編集画面で直していると、その変更が消えます。
なので、必ず clasp pull で取り込んで、差分を確認してから push してください。一人で作っているうちは問題になりませんが、引き継いだ後にやられると原因が分かりません。

CHAPTER 06

落とし穴6つ

① スクリプトの持ち主が個人になる（いちばん多い事故）

自分のマイドライブに作ると、そのアプリの持ち主はあなた個人になります。あなたが辞めてアカウントが消されたとき、他に持ち主がいなければ、誰もそのアプリに触れなくなります。管理者が事前に引き継ぎ（移管）をすれば残せますが、それを誰も知らなければ、全社が毎日使っている申請フォームが月曜の朝に止まります。

対策の第一歩は、共有ドライブに置くことです。共有ドライブのファイルには個人の所有者がいないため、担当が代わってもファイルは残ります（Googleの公式ドキュメントもこの方法を勧めています）。

例外 Workspace Studio は共有ドライブに対応していません（作った人に紐づきます）。Studio で作った自動化は「担当が辞めたら作り直し」が前提だと考えてください。長く使う仕組みなら Apps Script ＋ 共有ドライブのほうが安全です。

①-2 共有ドライブに置いても、それだけでは引き継げません

ここは誤解されやすいので、はっきり書きます。「ファイルが残ること」と「動き続けること」は別です。共有ドライブに置いても、人に紐づいたまま残るものが3つあります。

人に紐づくもの担当がいなくなると何が起きるか
「自分として実行」で公開したアプリ権限の持ち主は公開した本人。そのアカウントが消えると、ファイルが共有ドライブにあってもアプリが動かなくなる
トリガー（定期実行）作った人に紐づく。定時実行が止まる
外部サービスの承認その人が承認したもの。失効する

ですので、本当に引き継げる状態にするには、共有ドライブに加えて——①管理者を複数にする ②公開し直す担当を決めておく ③トリガーを誰が作ったか記録に残す ④担当が代わるときに「公開し直し・承認し直し」をやる。ここまでを手順にして、はじめて属人化が外れます。

たとえるなら 店の鍵を共有の金庫に入れても、シャッターを開けられるのが店長1人だけなら、店長が辞めた日に店は開きません。
置き場所を共有にするのは"鍵を金庫に入れる"ところまで。"開け方を複数人が知っている"状態まで作って、ようやく引き継ぎです。

② 別のドメインに移すと止まる

公開済みのWebアプリを、別ドメインのアカウントや共有ドライブへ移すと動かなくなります。会社の統合やドメイン変更のときは、移すのではなく作り直しになります。

③ 6分の壁

1回の実行は6分まで。有料のWorkspaceでも同じです。超えると途中で強制終了し、中途半端に処理された状態が残ります。件数が増える処理は、最初から「100件だけ処理して、続きは次回」という形で作ります。

④ 1日の上限がある

従量課金はない代わりに、1日に使える量が決まっています。個人のGmailアカウントとWorkspaceで差があります。

項目個人のGmailWorkspace（有料）
外部サービスの呼び出し20,000回／日100,000回／日
メールの送信先100件／日1,500件／日
定期実行の合計時間90分／日6時間／日
1回の実行時間6分／回6分／回

※上限は変わることがあります。大量送信を伴う仕組みを作る前に、公式の一覧で最新を確認してください。

⑤ 独自ドメインにはできない

URLは script.google.com/macros/s/… のままです。社内で使うぶんには問題ありませんが、お客様に見せる画面には使わないと決めておくと迷いません。

⑥ 管理者がオフにしている可能性がある

Apps Script は管理者が組織ごとにオフにできます。作り始める前に「うちで使えるか」を確認してください。2026年6月23日から、Apps Script は Google Workspace の「コアサービス」になりました——Gmail やドライブと同じデータ保護・管理機能・サポートの対象という意味です。「業務で使っていいのか」と聞かれたときは、ここが答えになります。

CHAPTER 07

2026年に何が変わったか

この選択肢が現実的になったのは、ここ半年ほどの変化によるものです。少し前の記事を読んでいると、この前提がまだ入っていません。

時期変化実務での意味
2026-01Apps Script に Vertex AI サービスが正式公開APIキーを自分で用意しなくても、コードから Gemini に文章や画像を作らせられる
※Google検索での裏取り（グラウンディング）や、画像編集の専用モデルは対象外。そこは従来どおり自力でAPIを呼ぶ必要がある
2026-03Workspace Studio（旧 Workspace Flows）が全ドメインに提供開始ノーコードの自動化が標準装備に。2026年5月に日本語の画面に対応
2026-06Apps Script が Workspace のコアサービスに業務利用の建前が整った。以前セキュリティを理由にオフにしていた会社は、判断をやり直せる
2026-08Apps Script の編集画面に Gemini のサイドパネル（ベータ）Claude Code を使わない人でも、ブラウザ側でAIにコードを書かせられる
まだ当てにしないもの Workspace Studio の手順に自作のステップを足す仕組み（Apps Script で作る）は、現時点で限定プレビューです。方向としてはノーコードとコードの境目がなくなっていきますが、正式公開前の機能を前提に設計しないでください。

CHAPTER 08

そのまま貼れるプロンプト（全文）

ここまでの判断を、Claude Code に代わりにやらせるためのプロンプトです。下の枠を全部コピーして Claude Code に貼り、続けて「〜がしたい」と書くだけ。AIが3つ質問し、4つの箱から1つを選び、作る前に置き場所と公開範囲を決めさせ、最後に動作確認のチェックリストまで出します。

あなたは「Google Workspace を使っている会社で、非エンジニアが社内アプリをつくる」のを伴走する相談役です。 私が「〜がしたい」と言ったら、いきなりコードを書かず、下の手順どおりに進めてください。 【絶対に守ること】 1. 作り方は4つの中から1つ選ぶ（Workspace Studio / AppSheet / Apps Script / Googleの外）。選んだ理由と、選ばなかった理由を1行ずつ日本語で言う。 2. コードを書く前に、ノーコードで足りないかを1度は確かめる。「Apps Script のほうが自由だから」だけを理由に選ばない。 3. 私（人間）がブラウザでやる作業と、あなたがやる作業を必ず分けて示す。私はターミナルの外の作業をあなたに任せられない。ブラウザ側は「①〜を開く ②〜をクリック」の粒度で書く。 4. 道具の追加（npm install など）は、必要になった時点で理由を言って許可を取ってから。勝手に入れない。 5. 本番データにいきなり触らない。まずコピーしたテスト用のスプレッドシート／フォルダで動かし、私が確認してから本番に向ける。 6. メール送信・ファイル削除・外部への送信を含む処理は、必ず「送らない状態（ログに出すだけ）」で先に動かす。私がOKと言うまで本物を送らない。 7. 仕様を推測で断定しない。迷ったら公式ドキュメントを確認する（developers.google.com/apps-script ／ support.google.com/workspace-studio ／ support.google.com/appsheet）。とくに clasp は2系と3系でコマンド名が違うので、古い書き方を使わない。 8. 専門用語は必ずその場で一言補足する（例：「デプロイ（＝公開して使えるURLを出すこと）」）。 9. 鍵と秘密をコードに書かない。APIキー・パスワード・トークンはコードにもREADMEにも直接書かず、スクリプトプロパティ等に置く。画面にも出さない。 10. 消す前・上書きする前に必ず控えを取る。行の削除、シートの上書き、ファイルの移動を含む処理は、先にコピーを作ってから実行する。 【STEP 1】3つだけ質問する 長いヒアリングはしない。次の3つだけ聞いて、答えを1行で要約して見せる。 (1) 誰が使う？（自分だけ／部署の数人／全社員／社外の人も） (2) データはどこにある？（スプレッドシート／Gmail／ドライブ／Google以外のシステム） (3) 専用の画面は要る？（要らない：裏で自動で動けばいい／要る：人が開いて入力・検索する） 【STEP 2】作り方を決める まず「Googleの外に出す条件」に当たっていないかを見る。1つでも当たったら Google の中では作らない。 ・社外の人（取引先・お客様・応募者）がログインして使う ・独自ドメイン（例 app.会社名.co.jp）で見せたい ・1回の処理が6分を超える（動画変換、大量データの一括処理） ・データの本体が Google の外にある（自社DB・基幹システム） → 上の1つ目と2つ目（独自ドメイン・6分超え）は仕様上できないので、「これは Google の中では作れません。理由は〜」と伝え、Cloudflare 等の外部ホスティング前提で組み直す。 → 3つ目と4つ目は「できない」ではなく判断。社外の人でもGoogleアカウントがあれば配れるが「特定の社外の人だけ」には絞れないこと、外部DBはJDBCで繋がるが接続元IPの許可設定や6分の壁があること——この2点を私に説明したうえで、中で作るか外に出すかを一緒に決める。 【STEP 2.5】危ないことをするなら、ここで3つだけ追加で聞く 作るものが「書き込む・消す・送る」のどれかを含む場合だけ確認する（読むだけのアプリなら飛ばしてよい）。 (1) 扱うのはどんな情報か（個人情報／評価・給与／取引先の情報／社外秘が含まれるか） (2) 何をするか（読むだけ／書き込む／消す／メールやChatで外に送る） (3) 止まったら誰が困るか（自分だけ／部署／全社・取引先） → 個人情報や社外秘が含まれる、または全社が止まる場合は、「先に管理者（情シス）に共有してください」と私に伝えてから続きに進む。 当たらなければ、次で決める。 ・「◯◯が起きたら→△△して→□□に通知」という決まった一本道、画面は不要 → Workspace Studio（ノーコード） ・現場のスマホから入力させたい（日報・在庫・点検・写真） → AppSheet（ノーコード） ・スプレッドシートに独自のメニューや関数を足したい → Apps Script ・社員が開く独自の画面が要る（申請・検索・ダッシュボード） → Apps Script（Webアプリ） ・決まった時刻の定期実行、処理が複雑 → Apps Script（トリガー） ノーコードの2つを選んだ場合：私はブラウザで作ることになる。あなたはコードを書かず、画面の手順書（どのメニューを開き、何を選び、どう設定するか）を出し、私が詰まったところに答える役に回る。 【STEP 3】作る前に3つ決める（飛ばさない） (1) 置き場所 … 原則「共有ドライブ」。マイドライブに作ると、作った人がいなくなった日にアプリごと消える。 ※Workspace Studio は共有ドライブ非対応。Studio を選んだ場合はその旨を私に伝える。 (2) 実行するユーザー … 「自分」＝誰が使っても作成者の権限で動く／「アクセスしているユーザー」＝使う人の権限で動く。見せたくないデータがあるなら後者。 (3) アクセスできるユーザー … 選べるのは「自分だけ／同じドメインの全員／Googleアカウントを持つ全員／全員（匿名可）」の4つだけで、人やグループの指定はできない。社内アプリなら「同じドメインの全員」。「全員（匿名可）」は、私が明確にそう言わない限り選ばない。 ここで必ず私に伝えること：「同じドメインの全員」は"社員なら誰でも入れる"という意味で、部署単位には絞れない。部署や担当者だけに見せたいなら、実行を「アクセスしているユーザー」にして、データ側（スプレッドシートの共有設定やGoogleグループ）で絞る——この方法を提案する。それでも足りなければ、コード側で許可リストを持って弾く案も出す。 この3つを表にして見せ、私の承認を取ってから作り始める。 【STEP 4】つくる（Apps Script の場合） 私がやる作業（あなたは待つ・3つある）： (1) script.google.com/home/usersettings を開き、「Google Apps Script API」をオンにする (2) ターミナルで clasp login → ブラウザが開くので承認する (3) 公開したあと、公開設定を画面で最終確認し、別のアカウントで実際に開いて意図どおりかを確かめる ※「手作業はこの2つだけ」とは言わないこと。Node.jsとclaspの導入、共有ドライブの作成と権限設定、本番データへの接続も私の作業として残る。 あなたがやる作業： ・clasp が未導入なら、Node.js が20以上あるか確認したうえで、導入してよいか私に聞く（npm install @google/clasp -g） ・3系のコマンドを使う：新規作成 clasp create-script ／ 取り込み clasp clone-script ／ アップロード clasp push ／ 公開 clasp create-deployment ／ 公開の差し替え clasp update-deployment <id> ・clasp push は手元のファイルでリモートを置き換える。ブラウザ側で誰かが直していると消えるので、必ず clasp pull で取り込み、差分を確認してから push する。 ・コードには日本語のコメントを入れる。私が後で読む。 ・1回6分の上限があるので、件数が増える処理は分割して動く形にする。ただし「100件ずつ」と件数で決め打ちしない。①残り時間を見て中断する ②どこまで終わったかを保存して次回そこから再開する ③同じ処理を2回動かしても二重登録・二重送信にならないようにする ④LockService で同時実行を防ぐ——この4つを満たす形にする。 【STEP 5】動作確認（できたと言う前に必ず） 次のチェックリストを出して、1つずつ私に確認させる。全部OKになるまで「完成」と言わない。 □ テスト用URL（/dev）で動くか □ 本番用URL（/exec）を別の社員（または自分の別アカウント）で開いて動くか □ 社外のアカウントで開くと弾かれるか □ メール送信・書き込みが意図した宛先／シートに入っているか □ わざと変な入力をしたときにエラーで壊れないか □ 定期実行なら、次に動く時刻がトリガー画面に出ているか 【STEP 6】引き継ぎメモを残す 作り終えたら README.md をまとめる。置き場所は手元のフォルダだけにせず、会社で管理しているGitリポジトリか、アプリと同じ共有ドライブの中に必ず控えを置く（手元だけだと、そのパソコンごと引き継ぎ資料が消える）。 内容：何をするアプリか（3行）／置き場所（共有ドライブ名）・公開URL・スクリプトID／実行するユーザーとアクセス範囲の設定値／定期実行の有無と時刻とそのトリガーを作った人／直すときにどのファイルを触るか／止まったときに最初に見る場所（Apps Script の「実行数」画面）／担当が変わるときにやること（新しい担当が公開し直す・トリガーを作り直す・外部サービスの承認を取り直す）。 ※このREADMEには鍵やパスワードを書かない。公開URLとスクリプトIDも、誰でも見える場所には置かない。

毎回貼るのが面倒なら

このプロンプトはスキル（＝必要なときにAIが自動で読み込む常設の指示書）にもできます。~/.claude/skills/gws-internal-app/SKILL.md というファイルを作り、先頭に次の4行を書いて、その下に上の枠の中身をそのまま貼ってください。以降は「社内で使う◯◯を作りたい」と言うだけで、この手順が自動で立ち上がります。

--- name: gws-internal-app description: Google Workspaceを使っている会社で社内アプリ・社内の自動化を作るときの進め方ナビ。「社内で使うツールを作りたい」「スプレッドシートで◯◯を自動化したい」「申請フォームを作りたい」「日報アプリを作りたい」等と言われたときに使う。 ---

スキルの詳しい作り方は別教材「スキル」を参照してください。

CHAPTER 09

用語ミニ辞典

Google Workspaceグーグル・ワークスペース
会社のドメイン（＠会社名.co.jp）で Gmail・ドライブ・スプレッドシート等をまとめて使う有料サービス。この教材は「会社で契約している」前提の話。
Apps Scriptアップス・スクリプト
Googleの中で動くプログラムの仕組み。JavaScript という言語で書く。2026年6月から Workspace の正式なサービス（コアサービス）扱い。
Workspace Studioワークスペース・スタジオ
プログラムを書かずに「◯◯したら△△する」という自動化を組む機能。旧名 Workspace Flows。Business / Enterprise / Education のプランに含まれる。
AppSheetアップシート
スプレッドシートなどを元に、スマホで使える入力アプリをプログラムなしで作る機能。基本機能（AppSheet Core）はほぼ全プランに無料で付く。
デプロイdeploy
作ったものを公開して、実際に使えるURLを出すこと。「公開」と読み替えて差し支えない。
ノーコードno-code
プログラムを書かず、画面の操作だけで仕組みを作ること。速いが、想定外のことをしようとすると途中で行き止まりになる。
claspクラスプ
Apps Script のコードをパソコン側のフォルダで編集し、コマンドでGoogleに送るための道具。これがあるから Claude Code で Apps Script が書ける。
共有ドライブきょうゆうドライブ
個人ではなくチームが持つドライブ。中のファイルに「個人の所有者」がいないため、担当が辞めても消えない。社内アプリはここに置く。
トリガーtrigger
「毎朝8時」「フォームが送信されたら」など、プログラムを自動で動かすきっかけの設定。
グラウンディングgrounding
AIが答えを作るときに、実際の検索結果など外部の情報で裏を取る仕組み。これがないとAIは思い込みで書くことがある。

まとめ

一言でいうと

社内アプリは、まずGoogleの中で足りないかを見る。決まった手順なら Workspace Studio、入力アプリなら AppSheet、それ以外は Apps Script。独自ドメインと6分超えは仕様上できないので外へ。社外の人が使う・データがGoogle外は、できなくはないので手間と安全性を見て決めます。

そして引き継ぎは、共有ドライブに置くのが第一歩で、それだけでは足りません。公開したアプリ・定期実行・外部サービスの承認は、人に紐づいたまま残るからです。担当が代わるときに「公開し直す・承認し直す」——ここまで手順にして、はじめて属人化が外れます。

便利なツールを作ることと、会社に残る仕組みを作ることは、別の話です。この教材でお伝えしたかったのは、後者のほうです。