Secure Vibe Coding Training
DAY 2

実践プロジェクト開発 +
社内資格認定

自分の業務課題を題材にVibe Codingで実用ツールを開発する。セキュリティチェックを繰り返し実践し、最後に社内資格認定テストに挑む1日。

4時間
座学 + ハンズオン + テスト
社内資格認定
Timetable
タイムテーブル
時間内容形式詳細
0:00 - 0:10 Opening 座学 Day 1復習、セキュリティリスク4分類クイック確認
0:10 - 0:30 Session 02 Part 1 座学 + 演習 効果的なプロンプトの書き方
0:30 - 0:50 Session 02 Part 2 座学 + 共有 宿題共有と課題設定
0:50 - 1:00 休憩 - -
1:00 - 2:20 Session 03 ハンズオン 実践プロジェクト開発（80分）
2:20 - 2:30 休憩 - -
2:30 - 2:55 Session 04 Part 1 発表 + 議論 成果発表 + 相互セキュリティレビュー
2:55 - 3:25 Session 04 Part 2 テスト 資格認定テスト（15分回答 + 15分解説）
3:25 - 3:40 Session 04 Part 3 座学 総括
3:40 - 4:00 Closing - 質疑応答 / 閉会 / アンケート

座学+発表 85分 / ハンズオン 80分 / テスト 30分 / 休憩 20分 / Opening+Closing 25分 = 合計240分

Opening — 0:00-0:10
Day 1 復習 -- セキュリティリスク4分類の確認

Day 1 で学んだセキュリティリスクの全体像をクイックに振り返る。4分類とチェックリスト4カテゴリを頭に入れ直してから Day 2 の実践に入る。

4
セキュリティリスク分類
4
チェックカテゴリ
5
セキュリティチェックポイント
セキュリティリスク4分類

1. 情報漏洩リスク

機密情報をAIに入力してしまう、生成コードに認証情報を埋め込んでしまうといった危険。プロンプトにパスワードや社内データを含めた時点でリスクは発生する。

2. 知的財産リスク

AIが生成したコードに既存のオープンソースが混入し、ライセンス汚染を起こす可能性がある。権利関係の不透明さが法的リスクに直結する。

3. マルウェアリスク

生成コードに意図しない外部通信やファイル操作が含まれるケース。レビューなしにそのまま実行すると、社内ネットワークに脆弱性を持ち込む。

4. データプライバシーリスク

個人情報や顧客データの取り扱いに関するリスク。個人情報保護法への抵触は、技術的な問題ではなくコンプライアンス上の問題になる。

分類主なリスクチェック観点発生タイミング
情報漏洩プロンプトへの機密情報混入入力チェックAIへの指示時
知的財産ライセンス汚染・権利侵害共有チェックコード共有時
マルウェア外部通信・不正ファイル操作生成チェックコード生成直後
プライバシー個人情報の不適切な取扱い出力チェック実行・出力時
チェックリスト4カテゴリ
入力
→
生成
→
出力
→
共有
参考リンク
IPA セキュリティガイドライン 経済産業省 AI事業者ガイドライン Samsung ChatGPT情報漏洩事例 - Cybernews 生成AIによる事件5選 - AI総研 企業における生成AI活用の落とし穴 - NTTデータ
Session 02 — Part 1 — 0:10-0:30
プロンプトエンジニアリング -- 効果的なプロンプトの書き方

AIに正確かつ安全なコードを書かせるには、プロンプトの質がすべてを決める。曖昧な指示が生むリスクと、具体的な指示が生む安全性の差を3パターンの比較で体感する。

曖昧なプロンプト vs 具体的なプロンプト
観点曖昧なプロンプト具体的なプロンプト
入出力不明確 -- AIが推測で補うファイルパス・形式を明記
ライブラリ制限なし -- 何でも使う使用可能なものだけ列挙
セキュリティ制約なし -- 外部通信も混入禁止APIを明示
レビュー容易性何が正解か判断困難期待動作と照合可能
再現性毎回違うコードが出る安定した出力を得やすい
Pattern 1 : 曖昧な指示 vs 具体的な指示
BAD -- 曖昧
Excelを処理するスクリプト作って

汎用的すぎるコードが生成される。外部ライブラリを勝手にimportし、どのファイルを読むかも不定。何が起きるか予測できないコードほど危ないものはない。

GOOD -- 具体的
列Aに社員番号、列Bに氏名、列Cに部署が入ったCSVファイル（data/members.csv）を読み込み、部署ごとの人数を集計してoutput/summary.csvに出力するPythonスクリプトを作成してください。外部ライブラリは使わず、標準ライブラリのcsvモジュールのみ使用してください。

入出力パスが明確、ライブラリ制約あり。生成コードの予測可能性が高く、レビューも容易になる。

Pattern 2 : 一括依頼 vs 段階的依頼
BAD -- 一括依頼
売上データを分析して、グラフを作って、レポートを生成して、メールで送信するスクリプトを作ってください

複雑すぎて不具合の発見が困難。メール送信権限が混入し、意図せず社外にデータを飛ばすリスクを孕む。

GOOD -- 段階的
Step 1: まず、売上データのCSVを読み込んで月別に集計する関数を作ってください。外部ライブラリは使いません。

-- 動作確認 + セキュリティチェック --

Step 2: 次に、集計結果をCSVに出力する関数を追加してください。出力先はoutput/フォルダに限定してください。

機能ごとにチェックでき、不要な権限の混入を未然に防げる。

Pattern 3 : 制約なし vs セキュリティ制約付き
BAD -- 制約なし
GASでスプレッドシートのデータをまとめてください

どのAPIを使うか、どこにアクセスするかが制限されない。UrlFetchApp や GmailApp を呼ぶコードが紛れ込む可能性がある。

GOOD -- 制約付き
GASでアクティブなスプレッドシートのSheet1からA2:C10の範囲のデータを読み取り、A列の値ごとにC列の合計を計算してください。

制約:
- SpreadsheetAppのみ使用
- UrlFetchApp使用禁止
- GmailApp、DriveApp使用禁止
- Logger.logでデータの中身は出力しない

許可するAPIを明示し、禁止するAPIを列挙する。生成コードがスコープ外の操作を行わないことを保証できる。

プロンプト4要素

効果的なプロンプトには必ず4つの要素が含まれる。「制約」の欄を空にしたまま生成ボタンを押さないこと。

目的
何をしたいか
CSVを部署別に集計
入力
何を受け取るか
data/sales.csv
出力
何を出すか
output/summary.csv
制約
何を禁止するか
外部通信禁止等
要素問い記述例
目的 何をしたいか CSVファイルを部署別に集計したい
入力 何を受け取るか data/sales.csv（A列:部署、B列:金額）
出力 何を出すか output/summary.csv に部署別合計を出力
制約 何を使わないか / 守るべきルール 外部ライブラリ不使用、外部通信禁止
プロンプト品質チェックリスト

プロンプトをAIに送信する前に、この5項目を確認する。1つでも欠けていると生成コードの品質が下がる。

プロンプトの構造

効果的なプロンプトは層構造を持つ。最上位の「制約」がコード全体の安全性を規定し、下層に向かって具体的な指示が並ぶ。

セキュリティ制約（禁止API、外部通信禁止、ログ制限）
出力仕様（ファイルパス、データ形式、エンコーディング）
処理ロジック（集計方法、フィルタ条件、ソート順）
入力定義（ファイル構造、列名、データ型、範囲）
段階的依頼法 -- 一度に全部頼まない

コード生成と動作確認を交互に繰り返す。1ステップごとにセキュリティチェックを挟むことで、問題を小さい段階で検知できる。

読み込み
→
Check
→
処理
→
Check
→
出力
→
Check
データ読み込み部分を作る 入力ファイルパス、データ形式を明示
動作確認 + セキュリティチェック 不審な import や外部通信がないか確認
処理ロジックを追加 集計・変換などのビジネスロジック
動作確認 + セキュリティチェック 処理結果が意図通りか、データ漏洩がないか
出力部分を追加 出力先パス制限、フォーマット指定
動作確認 + セキュリティチェック 最終確認、不要ファイルの出力がないか
コンテキスト提供テクニック
ファイル構造を先に伝える -- プロジェクトのディレクトリ構成を示してからコード生成を依頼する。AIが既存ファイルとの整合性を保ったコードを書きやすくなる。
データの型を明示する -- 「A列は数値、B列は日付（YYYY-MM-DD形式）」のように型と書式を指定する。型の曖昧さが原因のバグを未然に防げる。
エッジケースを指定する -- 「空行がある場合はスキップ」「金額が負の値の場合はエラーを返す」など例外ケースを伝えることで堅牢なコードが出る。
既存コードを見せる -- 関連する既存コードを添付し「このスタイルに合わせて」と指示する。コーディング規約やプロジェクトの慣習が自動的に引き継がれる。
演習

自分の業務課題を1つ選び、プロンプト4要素（目的・入力・出力・制約）の形式で書いてみる。隣の人と交換して「制約が足りているか」を確認し合う。

参考リンク
Prompt Engineering Guide GitHub Copilot Best Practices GitHub Copilot Chat OWASP LLM Top 10: Prompt Injection Prompt Injection対策 - OpenAI テキスト生成AI導入・運用ガイドライン - IPA
Session 02 — Part 2 — 0:30-0:50
宿題共有と課題設定

Day 1 の宿題「業務でVibe Codingで解決したい課題」を共有し、Session 03 で取り組むテーマを確定する。テーマが決まらない人向けにサンプルテーマも用意している。

グループ共有

2-3人のグループで宿題内容を共有する。自分の課題を30秒で説明し、他のメンバーから「セキュリティ上気になる点」を1つずつもらう。

共有の進め方
グループ編成
2分
→
宿題発表
10分
→
全体共有
5分
→
まとめ
3分
VSCode向けテーマ例
IDテーマ概要難易度
V1CSV列の並べ替えツール指定した列順にCSVを並べ替えて出力低
V2重複データ検出ツールCSVの特定列で重複する行を検出低
V3月次売上レポート生成売上CSVから月別集計を行いテキストレポートを出力中
V4複数CSVの統合ツール複数のCSVファイルを1つに統合中
V5データ検証ツールCSVの各列に対してバリデーションルールを適用高
GAS向けテーマ例
IDテーマ概要難易度
G1シート間データコピーSheet1のデータをSheet2にコピー低
G2条件付き行の抽出特定条件に合う行だけを別シートに抽出低
G3部署別集計ダッシュボード部署ごとの集計結果を別シートに自動生成中
G4月次データの自動集計月ごとのシートから年間サマリーを作成中
G5スプレッドシートの自動フォーマットデータに応じてセルの色分けや書式を自動設定高
段階的開発の5ステップ

Session 03 の80分間はこの5ステップで進行する。時間配分の目安を頭に入れておくこと。

Step 1
要件整理
→
Step 2
プロンプト設計
→
Step 3
生成+Check
→
Step 4
テスト
→
Step 5
改善+Check
Step内容時間目安成果物
Step 1要件整理10分要件メモ（目的・入出力・リスク）
Step 2プロンプト設計10分4要素を含むプロンプト文
Step 3コード生成 + セキュリティチェック1回目15分生成コード + チェック結果記録
Step 4テスト実行・動作確認10分ダミーデータによる実行結果
Step 5改善依頼 + セキュリティチェック2回目・3回目25分改善済みコード + 最終チェック結果
課題選定チェックポイント
課題が決まらない場合

テーマ例の中から難易度「低」か「中」を選ぶことを推奨する。初めてのVibe Coding実践で高難度に挑むと、80分では時間が足りない。まず小さく成功体験を積むことが先決。

参考リンク
Google Apps Script Reference GitHub Copilot Best Practices GAS Authorization Scopes - Google Developers AI生成コードのサイバーセキュリティリスク - Georgetown CSET
Session 03 — 1:00-2:20
実践プロジェクト開発（80分）

ここからが本番。自分で設定した業務課題に対して、Vibe Codingで実際にツールを開発する。各ステップでセキュリティチェックを忘れずに。

Step 1 : 要件整理（10分）

手順書の要件整理テンプレートに記入する。以下の4項目を空欄なく埋めることが目標。

Step 2 : プロンプト設計（10分）
プロンプトに必ず含めるもの
  • 目的 + 入力 + 出力 + 制約（プロンプト4要素）
  • セキュリティ制約（使用禁止ライブラリ、外部通信禁止、ログ出力制限 など）
  • 使用言語と実行環境の明記

プロンプトをテキストファイルに書き出してから Copilot に渡すと、後で見返せる。いきなりチャット欄に打ち込むのではなく、一度手元で整理する習慣をつけたい。

Step 3 : コード生成 + セキュリティチェック 1回目（15分）

AIが生成したコードをそのまま実行しない。まずチェックリストを1行ずつ確認する。

1回目チェックのポイント

  • import / require されているライブラリは指定通りか
  • 外部URLへのアクセス（fetch, UrlFetchApp 等）がないか
  • ファイル読み書きのパスが想定範囲内か
  • console.log / Logger.log に機密データが出力されていないか
  • ハードコードされた認証情報がないか
見落としやすい危険パターン
// 危険: 外部通信が混入している例 const response = await fetch('https://api.example.com/data'); // NG // 危険: 認証情報のハードコード const API_KEY = 'sk-abc123...'; // NG // 危険: 機密データのログ出力 console.log('顧客名:', customerName); // NG
問題が見つかったら

修正内容を具体的に指示する。「セキュリティ的に直して」ではなく「3行目の fetch を削除し、ローカルファイルからの読み込みに変更してください」と書く。曖昧な修正依頼は曖昧な修正を呼ぶ。

Step 4 : テスト実行・動作確認（10分）

ダミーデータを使って実行し、結果が期待通りか確認する。実データは絶対に使わない。

Step 5 : 改善依頼 + セキュリティチェック 2回目・3回目（25分）

追加機能や改善を依頼するたびに、新しいコードに対してセキュリティチェックを実施する。機能追加は新たなリスクの追加と同義。

改善内容をプロンプトで依頼 追加機能や修正点を具体的に記述
セキュリティチェック 2回目 追加コードに新たなリスクが紛れていないか
最終調整・仕上げ コメント追加、不要コード削除、整理
セキュリティチェック 3回目（最終） 全体通しで確認 + 共有前チェック（カテゴリ4）
セキュリティチェック3回のタイミングと焦点
回タイミングチェック焦点対応カテゴリ
1回目 初回コード生成後 import/外部通信/ファイルパス/認証情報 入力+生成
2回目 機能追加・修正後 追加処理のリスク/新たなAPI使用 生成+出力
3回目 完成時 全体通し確認/共有前チェック/権限 全4カテゴリ
環境別チェックポイント
VSCode共通
import文の確認
ファイルI/Oの範囲
外部URLアクセス
console.logの中身
GAS固有
SpreadsheetApp以外の使用
UrlFetchAppの混入
GmailApp/DriveAppの排除
権限承認画面の確認
共通注意
機密データのログ出力
ハードコード認証情報
実データの使用禁止
エラー時の情報露出
よくある問題と対処法
問題原因対処法
プロンプトが漠然としている 入出力の形式が未定 「入力ファイルの形式と出力ファイルの形式を具体的に書きましょう」
生成コードが長すぎて理解できない 一括依頼をしている Copilotに「このコードを短く簡潔に書き直してください」と依頼
GASの関数名がおかしい CopilotがGAS特有のAPIを知らない場合がある 「Google Apps Script用に修正して」と再依頼
GASが6分でタイムアウトする データ量が多すぎる データ量を減らすか処理を分割する
セキュリティチェックを飛ばしている 開発に集中して忘れる チェックは実行前に必ず。ここを飛ばすとテストに響く
なぜ3回もチェックするのか

1回のチェックで安全と言い切れるほどAI生成コードは単純ではない。機能を追加するたびにコードの構造が変わる。前回OKだった部分も、追加コードとの組み合わせで新しいリスクが生まれ得る。手間に感じるかもしれないが、この反復が「安全にVibe Codingを使いこなす力」になる。

参考リンク
OWASP Code Review Guide Google Workspace Security Google Apps Script Reference AI生成コードのレビュー方法 - GitHub Docs AI Generated Code Security Risks - Veracode AI生成コードの脆弱性パターン - Endor Labs
Session 04 — Part 1 — 2:30-2:55
成果発表 + 相互セキュリティレビュー

開発した成果物を発表し、他の受講者の目でセキュリティレビューを行う。自分では気づけなかったリスクを他者が見つけてくれる体験がこのセッションの核心。

発表フォーマット（1名5分）
課題説明
30秒
→
プロンプト紹介
1分
→
デモ
2分
→
チェック結果
1分
→
質疑
30秒
課題の説明（30秒） 何を解決するツールを作ったのか
プロンプト設計の紹介（1分） 4要素をどう書いたか、特にセキュリティ制約の内容
成果物デモ（2分） ダミーデータで動作を見せる
セキュリティチェック結果（1分） 3回のチェックで何を発見し、どう対処したか
質疑応答（30秒） 聴講者からの質問・コメント
相互セキュリティレビュー手順

1. ペアを組む

隣の人とペアを組む。できれば異なるテーマ（VSCode組とGAS組）でペアを組むと視点が広がる。

2. 自分のコードを相手に見せる

「何をするコードか」を口頭で説明してからコードを見せること。背景情報なしでコードだけ渡しても的確なレビューはできない。

3. チェックリストで相手のコードをレビュー

チェックリスト4カテゴリを相手のコードに適用する。気になる点はメモに書き出してフィードバックの準備をする。

4. フィードバック

見つけた指摘事項を相手に伝える。「ここは問題ない」「ここが気になった」を具体的に。褒めるべき点も見逃さない。

レビューフィードバック記録テンプレート
チェック観点結果コメント
入力チェック（機密情報の混入）OK / NG自由記述
生成チェック（不審な処理）OK / NG自由記述
出力チェック（不要データの出力）OK / NG自由記述
共有チェック（ライセンス・承認）OK / NG自由記述
総合コメント良かった点 / 改善点
議論ポイント

レビューで見つかった指摘事項を全体で共有する。「自分では気づかなかったが他者に指摘されたリスク」があれば、それがまさにレビューの価値。1人でチェックリストを回すのと、他者の目が入るのとでは発見率が段違いに変わる。

Session 04 — Part 2 — 2:55-3:25
社内資格認定テスト

2日間の集大成。このテストに合格すると、社内でVibe Codingを実務利用するための資格が付与される。

出題数
5問
選択式3問 + 記述式2問
回答時間
15分
+ 解説15分
合格基準
5問中4問正解
資格付与
項目内容
合格基準 5問中4問正解
合格者 社内資格付与 -- Vibe Coding の実務利用が解禁される
不合格の場合 後日再受験可能（問題は差し替え）
再受験方法 研修担当に連絡し、日程を調整
テスト出題範囲
範囲Day出題内容
セキュリティリスク4分類Day 1各分類の理解、具体例の判断
チェックリスト4カテゴリDay 1各カテゴリの適用場面
セキュリティチェック5ポイントDay 1生成コードの確認項目
プロンプト4要素Day 2効果的なプロンプトの構造
インシデント対応Day 1-2想定外の権限要求時の行動
合格のための学習ポイント
4分類を正確に覚える -- 情報漏洩・知的財産・マルウェア・データプライバシー。各リスクの具体例を1つずつ言えるようにしておく。
「入力してはいけない情報」の判断基準 -- 「この情報が外部に出たら困るか」が判断軸。一般知識や文法の質問は問題ない。
チェックの対象を具体的に言えるか -- 「外部通信」「ファイルアクセス範囲」「不要ライブラリ」の3つは必ず押さえる。
想定外の事態に「まず止める」 -- 権限要求が来たら許可せず中止。原因を確認してから再実行。
記述式は「リスク+対策」のセット -- リスクだけ書いて対策がない、対策だけ書いてリスクがない場合は不正解。
テストに臨む前に

テストの目的は「落とす」ことではなく、Vibe Codingを安全に使う最低限の知識が身についているかの確認。Day 1 のリスク4分類、チェックリスト4カテゴリ、Day 2 のプロンプト4要素を理解していれば合格できる内容になっている。

Session 04 — Part 3 — 3:25-3:40
総括 -- 2日間の振り返りとこれから
2日間の学習成果
観点Day 1 で手に入れたものDay 2 で手に入れたもの
知識セキュリティリスク4分類プロンプト4要素の書き方
ツールチェックリスト4カテゴリ段階的依頼法
体験初めてのVibe Coding業務課題をVibe Codingで解決
実践セキュリティチェック5ポイント相互レビューで「他者の目」の価値を実感
認定--資格認定テストで知識の到達度を確認

Day 1 で手に入れたもの

  • セキュリティリスク4分類の理解
  • チェックリスト4カテゴリの習得
  • 初めてのVibe Coding体験
  • セキュリティチェック5ポイントの実践

Day 2 で手に入れたもの

  • プロンプト4要素（目的+入力+出力+制約）の書き方
  • 自分の業務課題をVibe Codingで解決した経験
  • 相互レビューで「他者の目」の価値を実感
  • 認定テストで知識の到達度を確認
今後の自走ガイド
開発時は必ずセキュリティチェックリストを使う -- 慣れても省略しない。印刷してデスクに置いておくくらいで良い。
共有時はカテゴリ4を実施し、上長承認を得てから渡す -- 自分だけで使うツールでも、他者に渡す際は必ずこのステップを踏む。
困ったときはデジタルワークプレイスチームに相談する -- 1人で判断に迷うケースは必ず出てくる。その時に相談できる相手を持っておくことが安全の担保になる。
定期的にチェックリストの内容を見直す -- AI技術は進化する。新たなリスクに対応するため、チェック項目も更新し続ける。
成功事例を共有する -- うまくいった活用方法を部署内で共有すれば、組織全体のスキルが底上げされる。
資格取得者の責任と権限
区分内容
許可範囲 VSCode + GitHub Copilot、Google Apps Script でのVibe Coding
求められること チェックリストによるセキュリティ検証の実施
承認プロセス ツール共有前に上長承認を得る（カテゴリ4の遵守）
情報共有 新たなリスクやインシデントを発見した場合は即時共有する
資格は「自由にやっていい」の意味ではない

資格は「ルールを理解した上で使ってよい」という許可証。チェックリストを省略した開発や、承認なしのツール配布は資格の取り消し対象になり得る。安全に使い続けることが、組織全体のAI活用を前に進める。

次のステップ -- 研修の先にあるもの
資格取得
→
実務で活用
→
事例を共有
→
組織に展開

短期（1-2週間）

  • 研修で作ったツールを業務で試用する
  • チェックリストを印刷してデスクに常備
  • 小さな課題で練習を重ねる

中期（1-3ヶ月）

  • 新しい業務課題にVibe Codingを適用
  • 成功事例を部署内で共有
  • 後輩に使い方を教える機会を作る
参考リンク
経済産業省 AI事業者ガイドライン IPA セキュリティガイドライン GitHub Copilot Best Practices Samsung ChatGPT情報漏洩事例 - Cybernews GitHub Copilot 知的財産訴訟 - Saveri Law OWASP LLM Top 10: Prompt Injection AI生成コードのサイバーセキュリティリスク - Georgetown CSET テキスト生成AI導入・運用ガイドライン - IPA
Closing — 3:40-4:00
質疑応答 / 閉会 / アンケート
質疑応答

2日間の研修内容について、疑問や不安が残っている点があれば質問を受け付ける。実務で使い始めた際に「こういう場面ではどうすればいいか」という具体的な質問を歓迎する。