1. 第 2 回振り返りと本日のゴール
本日 3 時間で、自チームの開発ワークフローに AI を組み込む 1 ヶ月計画を作って持ち帰ります。手を動かす演習はブラウザ Gemini（対話型）で行います。全員が確実に使える環境だからです。Copilot / Cursor / Claude Code のような IDE のエージェント機能は、対象を絞って次回以降に扱う発展テーマとして、講師デモで世界観だけお見せします。
1.1 本日のタイムテーブル
| 時刻目安 | セッション | 形式 | 持ち帰るもの |
|---|---|---|---|
| 0:00 - 0:15 | オリエンテーション | 共有 | 本日の進め方の理解 |
| 0:15 - 0:55 | リスクマネジメントとガバナンス | 講義 | エンジニア固有のリスク判断軸 |
| 0:55 - 1:50 | Gemini を用いた開発タスク体験（演習 1〜5） | ハンズオン | 上流〜運用の AI 活用体感 |
| 1:50 - 2:40 | 開発ワークフロー改善と振り返り（演習 6 + デモ） | ハンズオン + デモ | ワークフローマップ、チームルール雛形 |
| 2:40 - 2:50 | 振り返りと閉会 | 共有 | 1 ヶ月後の試行計画 |
1.2 配布データの展開
配布データ ZIP を、研修開始前にデスクトップへ展開してください。
配布データの中身
③エンジニア/配布データ/ ├── README.md ├── handson_guide.md ├── hints/ ← 演習 1〜6 答え合わせ用 │ ├── step01_masking_hint.md ← 入力前のマスキング判断 │ ├── step02_requirement_decompose_hint.md │ ├── step03_code_review_hint.md │ ├── step04_test_generation_hint.md │ ├── step05_bug_analysis_hint.md │ └── step06_workflow_map_hint.md ├── templates/ │ ├── 開発ワークフロー×AI活用マップ_テンプレート.csv │ ├── PRレビュー観点リスト_テンプレート.md │ └── AI併用コーディング_チームルール雛形.md ├── demo_data/ │ ├── マスキング練習_生ログ.txt │ ├── 要件メモ_新規機能.md │ ├── レビュー対象コード_python.py │ ├── テスト対象関数_python.py │ └── 障害ログ_dummy.txt └── _reference_完成例/ ← 研修中は開かない
_reference_完成例/ は答え合わせ用です。講師の指示があるまで開かないでください。本物のコード、社内リポジトリ情報、顧客データは入力しないでください。すべて配布データの架空コードを使ってください。業務では「どこを伏せてどこを残すか」を自分で判断します。その線引きは Section 03 の演習 1 で練習します。無料の個人向け Gemini は入力が品質改善に使われる場合があるため、業務データを扱うときは会社が契約したプラン（入力を学習に使わない設定）を使ってください。
2. リスクマネジメントとガバナンス
本セッションは座学中心です。エンジニア固有の 3 つのリスク（著作権・脆弱性・コードレビュー方針）を押さえ、Linux Kernel と Anthropic の最新方針を見ながら、自社向けガバナンスの作り方を考えます。
2.1 著作権・ライセンスリスク
2025 年に Doe v. GitHub 訴訟（GitHub Copilot 集団訴訟）が和解。GitHub は「学習データと一致する出力をブロックするフィルタ」と「出典帰属オプション」の提供義務を負いました。ただし「類似コード」は射程外で、実務では引き続き注意が必要です。
GitHub Copilot の「duplicate detection filter」は Business / Enterprise 契約で有効、Cursor / Claude Code / Gemini Code Assist もそれぞれ類似機能を提供。ただし Copilot Coding Agent（自律実行モード）には現時点でフィルタが適用されない穴があります。実務では「フィルタ＋人間レビュー＋商用契約」の三段構えが現実解です。
2.2 脆弱性リスク
押さえる脆弱性パターン
| パターン | 具体例 | 対策 |
|---|---|---|
| SQL インジェクション | 文字列連結クエリ、ORM 不使用 | パラメータ化クエリ、SAST |
| 認証情報のハードコード | API キー、DB パスワードのコード埋込 | 環境変数、シークレットマネージャ |
| 個人情報のログ出力 | print/logger で氏名・契約番号を出力 | マスキング、ログレベル管理 |
| Slopsquatting | AI が推奨した架空パッケージを攻撃者が実在登録 | 依存パッケージ実在確認、SCA |
| プロンプトインジェクション | コメント経由で AI エージェントを乗っ取り | Claude Code / Gemini CLI で CVE 報告例あり |
Cymulate が 2025 年に CVE-2025-54794（Claude Code パス制限バイパス）／ CVE-2025-54795（Claude Code コマンドインジェクション、CVSS 8.7）を公開。Claude Code、Cursor、GitHub Copilot Agent、Gemini CLI のすべてに対し、コメント経由の「Comment and Control」攻撃が成立することが報告されています。出典：Cymulate ／ SecurityWeek
2.3 コードレビュー方針：Linux Kernel と Anthropic の最新ルール
Signed-off-by: は AI 禁止、代わりに Assisted-by: AGENT_NAME:MODEL_VERSION タグを必須化。責任は提出者の人間に帰属、完全自動生成パッチは拒否。CLAUDE.md（規約）+ REVIEW.md（観点）でカスタマイズ可、PR 承認は人間に留保。社内導入後、実質コメント付き PR が 16%（導入前）→ 54%（導入後）に上昇したと報告。「AI に任せる / 人間が握る」の基本線引き
AI に任せて良い（叩き台レベル）
- 定型コードの初稿生成
- リファクタリング提案
- テストケースの叩き台
- ログ要約・エラー解析
- ドキュメント・コメント生成
- 設計レビュー観点出し
人間が必ず握る（最終判断）
- アーキ最終決定
- 本番デプロイ承認
- セキュリティ要件の最終判断
- 重要顧客向けの実装判断
- AI による意思決定（採用・契約可否・与信・給付可否等は禁止）
国内外の規制動向（2026 年前半）
2.4 ベストプラクティス：DORA 2025 と業界実態
3. Gemini を用いた開発タスク体験
5 つの演習を Gemini で体験します。入口に置くのは「入力前のマスキング判断」です。今回いちばん身につけてほしい、どこまで伏せて入れるかの線引きを最初に手を動かして覚えます。続いて上流（要件分解）／レビュー／テスト／障害分析の 4 工程。すべて「考える → 書く → 実行 → 答え合わせ」の 4 ステップで、Step 4 で配布データの hints/ を開きます。
Gemini は使うアカウントの種類で「入力が学習に使われるか、人が中身を見るか」が変わります。会社アカウント（Google Workspace）は契約上、入力が学習に使われない設計です。それでも機密情報や個人情報は、念のため入れないのが実務の主流です。迷ったら入れない、やむを得ないときだけ次のマスキングをする、と覚えてください。
| データの種類 | 無料版の Gemini | 個人の有料プラン | 会社アカウント（Workspace） |
|---|---|---|---|
| 入力が学習に使われるか | 初期設定では使われることがある（設定でオフ可） | 無料版と同じ（オフ可） | 契約上、使われない |
| 機密情報（社外秘・契約・技術情報） | 原則入れない | 原則入れない | 学習されない設計でも原則入れない。必要時はマスキング |
| 個人情報（氏名・連絡先・顧客データ） | 入れない | 入れない | 原則入れない。必要時は伏せ字で最小限だけ |
| 要配慮個人情報（健康・医療・病歴など） | 入れない | 入れない | 原則 NG。社内の承認手順と伏せ字化のうえ最小限 |
会社アカウントは契約で学習されない設計でも、念のため入れない・迷ったら入れない、を徹底してください。この表は一般的な目安です。何を入力してよいかの最終判断は、必ず自社の情報取り扱いガイドラインに従ってください。
マスキング代表 4 手法
| 手法 | どうする | 例 |
|---|---|---|
| ダミー置換（今回の中心） | 実名・社名を仮の呼び名へ一律置換 | 田中花子→顧客A、○○健保→A社 |
| 列ごと削除 | CSV の個人情報列を丸ごと消す（塗るより確実） | 氏名・電話・住所・メールの列を削除 |
| 一般化 | 細かい値を大きなくくりへ丸める | 37 歳→30 代、142,853 件→約 14 万件 |
| 仮名化 / 匿名化 | 記号へ置換。仮名化は対応表で戻せる、匿名化は戻せない | 田中花子→U001（対応表は別に厳重保管） |
配布データの demo_data は、はじめから顧客Aや <DB_HOST> の形で用意しています。実務では本物のデータをそのまま扱わず、AI に渡す前にこの形へ加工してから使うためです。本セッション冒頭で、講師が加工前の生データを画面で見せ、どこをどう置き換えるかを実演します（手元での加工は任意）。加工後の状態が、そのまま AI に貼ってよい状態の見本になります。
3.1 演習 1：入力前のマスキング判断 [ 13 min ]
本物のデータをそのまま入れないの一歩先です。全部消すと Gemini が働けず、残しすぎると漏れます。その中間を自分で決める練習をします。
demo_data/マスキング練習_生ログ.txt（架空、顧客 ID・氏名・認証情報・内部ホスト名・実データが混在）を読み、Gemini に入れてはいけない箇所に印を付ける<DB_HOST>、142,853 件 → 約 14 万件）hints/step01_masking_hint.md で「伏せる／残す」の線引きと、伏せても原因にたどり着ける理由を確認「この 1 行が外に出て困る人がいるか」で決めます。困る人がいれば伏せる、エラー種別やスタックトレースのような技術的事実だけなら残す。認証情報（API キー・パスワード・トークン・Webhook）は、形を変えても入れません。この線引きはチームルール雛形 第 2 条の可否テーブルと対応しています。
認証情報と個人情報が消え、Traceback・件数の桁が残ったマスキング版を 1 つ作れた。
3.2 演習 2：要件分解と仕様ドラフト [ 10 min ]
demo_data/要件メモ_新規機能.md（架空、健診ダッシュボード要件）を読んで、曖昧な点を 5 個メモhints/step02_requirement_decompose_hint.md を開いて、参考プロンプトと _reference_完成例/仕様書ドラフト_想定出力.md の粒度を確認曖昧点を 3 個以上抽出し、機能仕様ドラフトの見出しが埋まった。
3.3 演習 3：コードレビュー観点出し [ 12 min ]
demo_data/レビュー対象コード_python.py（架空、あえて問題を含むコード 30 行）を Gemini に貼って 5 観点（バグ・セキュリティ・パフォーマンス・可読性・テスト）で指摘出し期待される指摘件数：8〜15 件。SQL インジェクション、個人情報のログ出力、二重ループの論理バグなど Critical 4 件・Major 5 件・Minor 3 件程度が出ているはず。答え合わせは hints/step03_code_review_hint.md と _reference_完成例/コードレビュー指摘_想定出力.md。
5 観点それぞれに最低 1 指摘が付き、AI レビュー後に人間確認の一言を添えた。
本演習の運用イメージは「PR を立てた直後に AI で 1 周セルフレビュー」。レビュアー人間に渡す前のセルフチェックとして使うと、レビュアー負荷が大幅に減ります。ただし「AI レビュー → 人間レビュー」の 2 段階は崩さないでください。
3.4 演習 4：テストケース生成 [ 10 min ]
demo_data/テスト対象関数_python.py（架空、保険料算出関数）に対して、pytest のユニットテストを 3 段階（正常系 5 件以上・境界値 5 件以上・異常系 5 件以上）で生成AAA パターン（Arrange / Act / Assert）と命名規則（test_<対象>_<条件>_<期待結果>）を必ず指定。答え合わせは hints/step04_test_generation_hint.md と _reference_完成例/テストケース_想定出力.py。
正常系・境界値・異常系の 3 段階が揃い、命名規則が指定どおりになった。
3.5 演習 5：バグ原因特定 [ 10 min ]
demo_data/障害ログ_dummy.txt（架空、Lambda の MemoryError ログ）を Gemini に投げて、原因仮説を 3 件、確認手順つきで出させる「過去の経緯（先月までは正常、2 週間前にリファクタ、契約数が前月 +12%）」を AI に必ず伝える。これが仮説の質を決める。答え合わせは hints/step05_bug_analysis_hint.md と _reference_完成例/バグ原因分析_想定出力.md。
原因仮説が 3 件出て、各仮説に確認手順が 1 つ以上付いた。
AI は「ログにある事実」と「一般論」は得意ですが、「自社固有の運用知識」「過去の自社インシデント」は知りません。社内 NotebookLM に過去のポストモーテム集を入れて検索式で組み合わせる運用が現実解。AI が「○○ライブラリのバグです」と言ってきたら、必ず該当バージョンの GitHub Issues を確認してください。
4. 開発ワークフロー改善と振り返り
本日の集大成。自チームの開発ワークフロー 7 工程を棚卸しして、AI 活用マップを作ります。その後、Copilot / Cursor / Claude Code の世界観を講師デモで共有し、最後にチームルール雛形を埋めて終わります。
4.1 演習 6：開発ワークフロー × AI 活用マップ [ 30 min ]
用意するもの
配布データの templates/開発ワークフロー×AI活用マップ_テンプレート.csv を Google スプレッドシートで開いてください。
- 新規スプレッドシート作成
- ファイル → インポート → アップロード → 上記 CSV
- 「現在のシートを置換」
- ファイル名を「自分の名前 _開発ワークフロー×AI活用マップ_v1」
7 工程
| 工程 | AI が得意 | 人間が握るべき |
|---|---|---|
| 1. 要件定義 | 曖昧性指摘、想定 FAQ、類似事例検索 | ステークホルダ合意、優先度判断 |
| 2. 設計 | 観点リスト、ADR ドラフト、技術選定比較 | 最終アーキ決定、トレードオフ判断 |
| 3. 実装 | コード補完、リファクタ、コメント生成 | アーキ整合性、複雑なロジック設計 |
| 4. レビュー | 5 観点指摘、規約チェック | 優先度判定、設計意図検証、承認 |
| 5. テスト | テストケース生成、テストデータ生成 | 受入基準定義、ビジネスロジック検証 |
| 6. デプロイ | デプロイスクリプト、変更履歴 | 本番承認、ロールバック判断 |
| 7. 運用 | ログ要約、インシデント仮説、ポストモーテム初稿 | 根本原因確定、対策決定 |
hints/step06_workflow_map_hint.md で観点確認、_reference_完成例/開発ワークフロー×AI活用マップ_完成例.csv を比較7 工程が埋まり、上位 3 件に○が付いた。
4.2 AI 駆動開発ツールデモ（講師画面） [ 12 min ]
受講者の手元操作は不要。今回の軸はブラウザ Gemini（対話型）です。以下の IDE エージェントは、対象を絞って次回以降に扱う発展テーマとして世界観だけ共有します。「こういう世界がある」を知っておくための時間です。
主流は Claude Code / GitHub Copilot / Cursor の 3 強です。経験の長い開発者は平均 2.3 ツールを併用し、Claude Code は自律的なタスク実行、Copilot / Cursor はインライン補完という役割分担で使い分けています。出典：Developers Digest（2026/6）
3 ツールの役割の違い（自律実行／インライン補完）を 1 行で言えるようになった。
Copilot Free / Pro / Pro+ の対話データは既定でモデル学習対象になり得ます。Business / Enterprise は契約上学習対象外で除外されます。法研システムズ様のような業界では、必ず Business / Enterprise 契約で導入することが前提となります。出典：GitHub Blog
4.3 チームルール雛形作成 [ 8 min ]
templates/AI併用コーディング_チームルール雛形.md を自チーム版に書き換え完成度よりも「議論を始める叩き台」を作ることを優先。第 2 回までに整理した自部署計画書のセキュリティ判断を、ここに転記してください。リーダー・マネージャと合意するのは研修後 1 週間以内が目安。
入力禁止データの可否テーブルが自チームの実データ名で 1 行以上埋まった。
4.4 振り返りと閉会 [ 残り時間 ]
ブレイクアウトで 3 つを共有してください。
- 自チームのワークフローで AI が最も効きそうな工程
- ガイドライン整備で 1 番悩みそうな点
- 1 ヶ月後に試してみたい 1 件
5. 質疑応答・閉会
5.1 全 3 回シリーズの総括
| 回 | テーマ | 到達点 |
|---|---|---|
| 第 1 回 | 完全入門編：生成 AI との向き合い方 | 業務で 1 件 AI を使えた成功体験 |
| 第 2 回 | 基礎研修：リテラシーとプロンプト実践 | 自部署 AI 活用計画書 v1 |
| 第 3 回（本日） | エンジニア向け：AI 活用と業務効率化 | 開発ワークフロー × AI 活用マップ + チームルール雛形 |
5.2 1 ヶ月後のレビュー推奨
1 ヶ月後にやること
- マップで「○」を付けた上位 3 件のうち、最も気軽に始められる 1 件をチームに導入
- 1 ヶ月後に効果測定（時間削減 / 品質指標 / 心理的ハードル変化）
- チームルール雛形を v1 に磨き、リーダー・マネージャと合意
- 結果を講師（安田）までメールでご共有いただけると、次回以降の研修教材に活かさせていただきます
5.3 用語集
本日のゴールは「自チームに 1 件 AI を組み込む 1 ヶ月計画」でした。マップに書いた 1 件、ぜひ来週から試してみてください。1 ヶ月後の振り返り結果を、安田までお知らせいただけると幸いです。次の研修テーマ（運用定着、AI ガバナンス深掘り、SaaS 開発特化など）のご相談もお気軽に。
参考リンク
- Gemini Code Assist 公式：codeassist.google
- Gemini for Google Cloud Pricing：cloud.google.com/products/gemini/pricing
- Gemini Code Assist Security / Privacy：docs.cloud.google.com
- Gemini Code Assist Release notes：developers.google.com
- GitHub Copilot Plans：github.com/features/copilot/plans
- GitHub Copilot 学習データポリシー変更（2026/4）：github.blog
- Cursor Pricing：cursor.com/pricing
- Claude Code 公式：claude.com/pricing
- Anthropic Code Review（2026/3）：claude.com/blog/code-review
- 2026 Agentic Coding Trends Report (Anthropic)：anthropic.com (PDF)
- Linux Kernel Coding Assistants 公式：docs.kernel.org
- Doe v. GitHub case updates：githubcopilotlitigation.com
- Veracode 2025 GenAI Code Security Report：veracode.com
- Apiiro: 4x Velocity 10x Vulnerabilities：apiiro.com
- Snyk Slopsquatting Mitigation：snyk.io
- Cymulate CVE-2025-54794/54795（Claude Code）：cymulate.com
- SecurityWeek: AI Code Agents Vulnerable to Prompt Injection：securityweek.com
- DORA State of AI 2025：dora.dev/dora-report-2025
- Stack Overflow 2025 AI Survey：survey.stackoverflow.co/2025/ai
- Microsoft Research: SPACE of AI：microsoft.com/research
- Google AI in software engineering：research.google
- メルカリ Project Double：engineering.mercari.com
- NTT ドコモ Copilot 導入事例：nttdocomo-developers.jp
- AI for Requirements Engineering (arXiv 2511.01324)：arxiv.org/html/2511.01324v3
- GenIA-E2ETest (arXiv 2510.01024)：arxiv.org/html/2510.01024v1
- STORIA法律事務所 AI と著作権 第 5 回：storialaw.jp/blog/12056
- claude-code-security-review GitHub Action：github.com/anthropics/claude-code-security-review
Givery, Inc. ／ 株式会社 法研システムズ 御中