leale
第2期 Day 3
石垣商店
株式会社leale — AI 活用 企業研修 第2期（Claude 中級）

Day 3：アプリの共同製作
— 5人で1つを作り、運用に載せる

Day 1 の型（ブランチ → PR → レビュー → 自動公開）と Day 2 のエージェントを総動員して、
5 人で 1 つの業務アプリを同時に作り、本番公開し、台帳と点検の仕組みに載せるまで。
「個人で作れる」から「チームで作り続けられる」への最終日。

顧客
株式会社石垣商店
業種
銅・真鍮加工 製造業
参加者
5名（第2期選抜）
日程
2026年10月19日
0:00-0:20題材を決める
0:20-1:05要件定義と分担
1:15-2:35分担して同時開発
2:45-3:45統合・公開
3:55-4:30運用と修了式
Opening 0:00 - 0:20

最終日へ
— 今日は「5人で1つ」を作る

🎯 Day 3 のゴール

5 人が同じリポジトリで役割を分けて 1 つの業務アプリを作り、PR とレビューを通して統合し、会社の Cloudflare で本番公開する。台帳・担当・点検まで決めて、明日から運用できる状態で終える。

3 日間の振り返り（5分）

1
Day 1（9/25）：チームで使う環境

会社の置き場4層と PC の道具5層、標準リポジトリと共有スキル3本、アプリ台帳、ブランチ → PR → レビュー → 自動公開の型

2
Day 2（10/5）：AI エージェントの構築

会社の API キー、clasp で GAS を PC から、問い合わせ仕分けエージェント、安全装置4点セット、点検スキル

3
Day 3（今日）：アプリの共同製作

上の全部を使って、5人で1つを作る。役割分担・同時開発・統合・公開・運用設計・修了

宿題の確認：①エージェントの分類精度を改善して PR を出せましたか ②「エージェントを点検して」は実行しましたか ③設定シート B1 は OFF になっていますか（今日、本番接続の判断をします）

今日の進め方 — 5 人で 1 つを同時に作る

今までは「1 人 1 アプリ」でした。今日は同じリポジトリを 5 人が同時に触ります。これが共同製作で、Day 1 で練習した PR とレビューが本番で効きます。

要件を
全員で決める
→
担当を
分ける
ぶつからない分け方
→
各自ブランチで
Claude と作る
→
PR → 相互
レビュー → 統合
→
本番公開
運用に載せる
今日いちばん大事なこと：速く作ることではなく、5 人の手が同じ場所でぶつからずに進むこと。これができれば、参加していない社員が増えても同じやり方で回ります。
Live Poll — 題材決め
今日、5人で作る業務アプリはどれにしますか？
QRコード
（講師設定）
スマホで
QR を読み取り投票
問い合わせ受付 & 進捗台帳（Day 2 のエージェントを組み込む）
製造実績の入力 & 見える化
見積依頼の受付 & 要点整理
日報の入力 & 週次まとめ
📋 講師：Day 2 の投票結果を先に見せてから投票させる。迷ったら「問い合わせ受付 & 進捗台帳」を推す（Day 2 のエージェントをそのまま組み込め、フロント・バック・DB の3部品が全部登場するため教材として最良）。以降の資料はこの題材を例に書いてある。
Section 1 / ワーク 0:20 - 1:05 / 45分

要件定義と分担設計
— 何を作り、誰がどこを持つか

🎯 ゴール

作るものの画面・データ・処理が紙一枚で共有され、5 人の担当がぶつからないように分かれている。

1-1. Claude と要件定義をする（20分・全員）

いきなり作り始めると、5 人がバラバラのものを作ります。先に「何を作るか」を文章にして全員で合意します。書くのは Claude、決めるのは人間です。

Claude のチャットに貼るプロンプト（代表者が画面共有しながら）
石垣商店（銅・真鍮加工の製造業、社員13名）で使う「問い合わせ受付 & 進捗台帳」を5人で作ります。 まず要件定義を手伝ってください。日本語で、私たちに質問しながら進めてください。 決めたいこと： 1. 誰が使うか（受付担当・営業・製造・管理者）と、それぞれが何をしたいか（1行ずつ） 2. 画面は何枚必要か（例：受付フォーム／一覧・進捗／詳細） 3. スプレッドシートに持つ列（項目名と説明） 4. Day 2 で作った「問い合わせ仕分けエージェント」をどこで使うか 5. 今日の4時間で「ここまで作る」範囲と、「今日はやらない」ことの線引き 不明な点は私たちに質問してください。決まったら requirements.md として保存してください。
用語：要件定義＝作る前に「誰が・何を・なぜ」を決めること。スコープ＝今日やる範囲。やらないことを決めるのが、時間内に完成させる最大のコツです。
Claude に質問させる形にすると受講者が答えるだけで要件が固まる。講師は「今日はやらない」を必ず 3 つ以上出させる（認証・権限・メール返信の自動送信など）。requirements.md はこの後リポジトリに入れ、PR の判断基準になる。

1-2. 3 つの部品に分けて考える（10分）

Day 1 で習ったフロント・バックエンド・データベースに、今日の題材を当てはめます。分担はこの部品の線で切ると、作業がぶつかりません。

部品今日のもの置き場触るファイル
フロント（画面）受付フォーム画面／一覧・進捗画面Cloudflare Pagesindex.html / list.html
バックエンド（処理）保存する・読み出す・更新する窓口GAS（Web アプリ）api.gs
データベース（保管）問い合わせ台帳・設定・ログGoogle スプレッドシートシート定義＋sheet.gs
エージェント（自動）分類・要約・至急通知GAS（Day 2 の資産）agent.gs
ぶつからない分け方の原則：「1 人 1 ファイル」。同じファイルを 2 人が同時に直すと競合します。どうしても共通で触る所（データの列）は、先に全員で決めて動かさない。

1-3. 5 人の担当を決める（15分・ワーク）

役割担当作るもの完成の目安
A：受付画面＿＿＿＿問い合わせを入力して送る画面（index.html）入力して送信でき、送信後にお礼が出る
B：一覧・進捗画面＿＿＿＿届いた問い合わせの一覧と状態変更（list.html）一覧が出て、状態を「対応中／完了」に変えられる
C：バックエンド＿＿＿＿保存・読み出し・更新の窓口（api.gs）画面から呼ぶと、シートに読み書きできる
D：データ＋エージェント＿＿＿＿シート設計と Day 2 のエージェント接続（sheet.gs/agent.gs）新規の問い合わせに分類と要約が入る
E：レビュー＆公開＿＿＿＿PR のレビュー、Cloudflare 設定、README と台帳全員の PR が通り、本番 URL が出る
E（レビュー＆公開）は待ち時間が長い役です。手が空いたら詰まっている人を助け、README を先に書き始めてください。実務でもこの役が品質を決めます。
5 名でちょうど 1 人 1 役。欠席で 4 名になったら D が E を兼ねる（または講師が E に入る）。役割は固定せず、途中で「自分の担当が終わったら助けに行く」を推奨。逆に、自分の担当外のファイルを勝手に直さないことを徹底させる（競合と混乱の元）。
☕ 休憩 10分（1:05 - 1:15）
Section 2 / ハンズオン 1:15 - 2:35 / 80分

分担して同時開発
— ブランチ・PR・レビューを実戦で

🎯 ゴール

5 人が同じリポジトリでそれぞれのブランチで作り、PR を出し合い、相互レビューでマージする。競合が出ても自分たちで解消できる。

2-1. 土台を用意する（15分）

HANDS-ON — E（公開担当）＋全員

リポジトリを作り、全員が手元に取り込む

  1. E：Claude に「Organization ishigaki-shoten に private リポジトリ toiawase-daicho を作って、requirements.md と README の骨組みを入れて push して。main は直接 push 禁止・PR 必須・レビュー1名の設定も入れて」
  2. E：作った空のシート（Day 2 と同じ構成＋問い合わせ台帳）の URL を全員に共有
  3. 全員：「ishigaki-shoten/toiawase-daicho を clone して、自分の作業ブランチ feat-（自分の担当） を作って」
  4. 全員：「requirements.md を読んで、私の担当（A〜E のどれか）の作業内容を3行で確認させて」
所要時間：15分
用語：clone＝会社の棚から自分の手元にコピーすること。ブランチ＝本番（main）を汚さない自分専用の作業コピー。5 人が同時に作れるのはこの仕組みのおかげです。

2-2. 各自が担当分を作る（40分）

自分の担当ファイルだけを触ります。requirements.md を Claude に読ませてから頼むのがコツです。

A：受付画面の担当
requirements.md を読んで、受付フォーム画面 index.html を1ファイルで作ってください。 - 入力項目は requirements.md の台帳の列に合わせる - 送信すると、バックエンドの窓口（URLは後で差し替えられるよう先頭に定数で置く）に送る - 送信後は「受け付けました」と表示する。二重送信を防ぐ - スマホでも使える見た目。石垣商店らしい配色（落ち着いた銅色を差し色に） - 外部ライブラリは使わない 私の担当は index.html だけです。他のファイルは触らないでください。
B：一覧・進捗画面の担当
requirements.md を読んで、一覧・進捗画面 list.html を1ファイルで作ってください。 - バックエンドから問い合わせ一覧を取得して表で表示する（URLは先頭に定数で置く） - 分類・急ぎ度で絞り込める。急ぎ度「高」は目立つ色にする - 各行の状態を「新規／対応中／完了」に変更でき、変更はバックエンドに送る - データがまだ無いときは「まだ問い合わせはありません」と表示する - スマホでも崩れないこと 私の担当は list.html だけです。他のファイルは触らないでください。
C：バックエンドの担当
requirements.md を読んで、GAS の Web アプリとして api.gs を作ってください。 - doPost：受付フォームからの送信を台帳シートに1行追加する（受付日時と初期状態「新規」も入れる） - doGet：台帳の一覧を JSON で返す - 状態更新：行を指定して状態を「対応中／完了」に変える - 画面（Cloudflare Pages）は別ドメインなので、CORS で呼べるようにする - 入力チェック（空・長すぎ）を入れ、エラーは日本語のメッセージで返す - APIキーや個人情報をログに残さない clasp push して、Web アプリとしてデプロイする手順（アクセス権の設定含む）を教えてください。 私の担当は api.gs だけです。他のファイルは触らないでください。
D：データ＋エージェントの担当
requirements.md を読んで、次を作ってください。 1. sheet.gs：台帳シートの列定義と、初期化する関数（見出し行を作る）。Day 2 と同じ「設定」「ログ」シートも用意し、 キルスイッチ・実行ログ・件数上限をそのまま使えるようにする 2. agent.gs：Day 2 の問い合わせ仕分けエージェントを、この台帳向けに移植する - 新規の行（分類が空のもの）を最大10件まで処理する - Claude API で 分類・3行要約・急ぎ度 を判定し、その行に書き込む - 急ぎ度が高いものだけ担当者に社内通知する（社外へは送らない） - 設定シートのキルスイッチが OFF なら何もしない 私の担当は sheet.gs と agent.gs だけです。他のファイルは触らないでください。
E：レビュー＆公開の担当
このリポジトリの README.md を、ishigaki-standards/README_TEMPLATE.md の形式で書いてください。 requirements.md を読んで、何のアプリか・使い方・主担当と副担当（5人の役割）・直し方・扱うデータ・レベルを埋める。 公開URLとバックエンドURLは、決まり次第あとで差し替えられるよう「（未設定）」と書いておいてください。 書けたらブランチ feat-docs で PR を出してください。 その後、他のメンバーから PR の URL が届いたら「レビューして」で順番に確認します。
40 分は短い。講師は C（バックエンド）を最優先で見る。C が詰まると A・B が繋げられず全体が止まるため。A・B は先に見た目だけ作り、バックエンドの URL は後で差し替える設計にしてある。D は Day 2 の資産をコピーするだけなので比較的速い。

2-3. PR を出し合い、相互レビューでマージ（25分）

全員

Day 1 で練習した型を、本番で回す

  1. 各自：「ここまでをコミットして push して、main への PR を出して。変更点を2行で説明して」
  2. 各自：PR の URL を全員に共有（チャットか口頭）
  3. E＋隣の人：「この PR をレビューして（URL）」→ 共有スキルが差分を読んで指摘
  4. 指摘を受けた人は「〇〇を直して push して」（PR は自動更新）
  5. 問題なければ E が「この PR を承認してマージして」
  6. 競合が出たら「競合を解消して」。後からマージする人ほど起きます。想定内です
所要時間：25分
レビューで必ず見ること：①秘密情報（キー・取引先名）が混ざっていないか ②自分の担当外のファイルを触っていないか ③README に書いた使い方と合っているか。Day 1 の共有スキルがこの 3 点を見ます。
☕ 休憩 10分（2:35 - 2:45）
Section 3 / ハンズオン 2:45 - 3:45 / 60分

つなげて、動かして、公開する
— 3 つの部品が 1 つのアプリになる瞬間

🎯 ゴール

フロント・バックエンド・データベース・エージェントがつながり、本番 URL で 5 人全員が触れる状態になる。

3-1. つなぐ（20分）

HANDS-ON — C と E が中心、全員で見る

バックエンドの URL を画面に入れる

  1. C：GAS を Web アプリとしてデプロイし、/exec の URL を共有（アクセス権は「全員」、実行は「自分」）
  2. A・B：「index.html（list.html）の先頭の定数に、このバックエンドURLを入れて push して」→ PR → E がマージ
  3. E：Cloudflare Pages でこのリポジトリを GitHub 連携して公開（Day 1 の 3-3 と同じ手順）
  4. 出てきた https://toiawase-daicho.pages.dev を全員に共有
所要時間：20分
用語：CORS＝別のドメイン（Cloudflare の画面）から GAS を呼ぶときの許可の仕組み。ここで「読み込めない」エラーが出たら、まず Claude に「CORS のエラーが出た。直して」と貼ってください。頻出のつまずきです。
GAS Web アプリのデプロイは「新しいデプロイ」→種類「ウェブアプリ」→アクセスできるユーザー「全員」。社外に出したくない場合は「同じ組織内の全員」だが、Pages から匿名で呼ぶ構成では「全員」が必要。テストデータしか入らないことを 1-1 のスコープで確認済みにしておく。

3-2. 全員で触ってバグを出す（20分）

全員

5 人で同時に使ってみる

  1. 全員がスマホと PC から受付フォームにテストの問い合わせを入れる（実在の取引先名は使わない）
  2. 一覧画面に出るか、5 人同時でも壊れないかを見る
  3. D：エージェントを実行 → 分類・要約・急ぎ度が入るか確認
  4. 見つかった不具合を口頭で担当者に伝える（担当者が自分のブランチで直して PR）
  5. 直ったら E がマージ → 自動で本番が更新されることを全員で確認
所要時間：20分
ここが共同製作の山場です。「見つける人」「直す人」「通す人」が分かれていて、それでも 5 分で本番が直る。これが Day 1 で作った型の威力です。

3-3. 本番に向けるかを決める（20分・判断）

アプリは動きました。では実際の問い合わせを流すか。これは技術ではなく経営判断です。全員で次のチェックを通してから決めます。

確認項目基準今日の状態
扱うデータ取引先名・金額が入るなら L3 扱い＿＿＿＿
止め方誰でもすぐ止められる（キルスイッチ）＿＿＿＿
記録実行ログと履歴が残っている＿＿＿＿
担当主担当・副担当が決まり README にある＿＿＿＿
社外への送信自動送信していない（人が押す）＿＿＿＿
費用月の上限が設定済み＿＿＿＿
推奨：まず2 週間は社内のテスト運用。実際の問い合わせは手で写して入れ、分類の精度を見る。それから本番接続を判断する。急がないことが、結果的に早い。
ここで「今日から本番で」と言い出す受講者が必ず出る。止めるのではなく、上の表の空欄を一緒に埋めて、埋まらない項目があることを本人に気づかせる。埋まっているなら止める理由はない。判断は石垣商店のもの。
☕ 休憩 10分（3:45 - 3:55）
Section 4 / 運用設計・修了 3:55 - 4:30 / 35分

運用に載せて、全社へ広げる
× 第2期 修了

🎯 ゴール

今日作ったアプリが台帳・担当・点検に載り、参加していない社員へどう広げるかが決まる。

4-1. 台帳に載せて、点検の予定を入れる（10分）

Claude のチャットに貼るプロンプト（E が実施、全員で確認）
今日作った toiawase-daicho を台帳に登録して。 アプリ名「問い合わせ受付＆進捗台帳」、主担当「（氏名）」、副担当「（氏名）」、 レベル「（L2 / L3）」、扱うデータ「（テスト運用中は社内テストデータのみ）」。 README に次も追記してください： - 5人の役割分担（誰がどのファイルを持つか） - 止め方（設定シート B1 を OFF）と各URL（本番・バックエンド・シート・スクリプト） - テスト運用の期間と、本番接続を判断する日 - 直し方：必ずブランチを切って PR。main へ直接 push しない
週
テスト運用の確認

2 週間、主担当が週 1 回「エージェントを点検して」を実行し、分類の精度と失敗率を見る

月
棚卸し（Day 1 の型）

責任者が台帳を見て「使っている／止める」を決める。副担当が空のものを埋める

四半期
事例共有会

全社員に向けて、実際に効いた活用を共有。第1期受講者の再点火の場にする

4-2. 参加していない社員へどう広げるか（10分・ワーク）

第1期は全社員が受けました。第2期はこの 5 人です。5 人が全社の窓口になるための決めごとを 3 つだけ決めます。

決めること案今日決める
相談の受け口「AI でこれできない？」を誰に言えばよいか。5 人のうち誰でも／部署ごとの担当＿＿＿＿
新しいアプリの作り方相談を受けた 5 人が「台帳に登録して」の型で作る。作りたい人には Day 1 の環境構築を案内＿＿＿＿
共有の場四半期の事例共有会／月次の棚卸し結果を社内に一言で共有＿＿＿＿
広げ方のコツ：全員に環境構築をさせない。使う人と作る人を分け、作る人だけがこの 3 日間の型を持つ。使う人には URL を配るだけでよい。
石垣商店は社員13名・第2期選抜5名。残り8名に同じ研修は不要で、「相談すれば 5 人が作ってくれる」状態が最も費用対効果が高い。ここを曖昧にすると「作れる人が増えない／相談先が分からない」の両方が起きる。leale への継続相談（月次棚卸しの同席）の話もこのタイミングで。
CERTIFICATE OF COMPLETION
AI 活用 企業研修 第2期（Claude 中級）修了
株式会社石垣商店
チームで使う AI・Claude 環境の構築（Day 1）
AI エージェントの構築と安全な運用（Day 2）
5 人での業務アプリ共同製作と本番公開（Day 3）
上記の全課程を修了されたことを証します
2026年10月19日
株式会社leale
Live Poll — 第2期の振り返り
明日から、この型で会社のアプリを作り続けられそうですか？
QRコード
（講師設定）
スマホで
QR を読み取り投票
作り続けられる。次の題材も決まっている
作れるが、詰まったときの相談先が欲しい
共同開発（PR・レビュー）にもう少し慣れが必要
会社としての体制づくりを一緒に進めたい
📋 講師：結果に応じて継続支援を提案する。「相談先が欲しい」「体制づくり」が多ければ月次伴走（棚卸し同席＋随時相談）の提案へ。
第2期 修了 TAKEAWAYS

3 日間のまとめ

TAKEAWAY 01

会社が持ち、社員が招待される

GWS・GitHub Organization・Cloudflare・Claude。全部を業務メールで会社名義に。退職も異動も招待の付け外しで済む。

TAKEAWAY 02

手順は共有スキルにする

「台帳に登録して」「公開して」「レビューして」「エージェントを点検して」。1 人が書いた手順が pull だけで全員の手順になる。

TAKEAWAY 03

自動で動くものには安全装置を

キルスイッチ・実行ログ・件数上限・人の承認。社外に出る操作は人が押す。この線引きはアプリでもエージェントでも同じ。

TAKEAWAY 04

5 人で作れたなら、会社で作れる

1 人 1 ファイル、ブランチ → PR → レビュー → 自動公開。この型があれば、人が増えても同じ速さで回る。

明日からの3つ

①2 週間のテスト運用：主担当が週 1 回「エージェントを点検して」。分類の精度をメモし、頼み方（プロンプト）を業務の言葉で直す。
②月 1 回の棚卸し：責任者が台帳を見て「使っている／止める」を決める。副担当が空のアプリを埋める。
③相談の受け口を社内に告知：「AI でこれできない？」の行き先を全社員に伝える。作るのはこの 5 人でよい。

詰まったときは leale へ。3 日間おつかれさまでした。