AI駆動開発ワークショップ

プロジェクト概要

複数本部プロパ向け AI駆動開発ハンズオンワークショップの企画・運営リポジトリ。
運営プロセス自体をAI駆動で回し、そのプロセスも教材にするという方針。 全国ツアー形式で各本部を順次開催。

• 形式: 90分 × 全5回（週1回）
• ツール: VS Code + Claude Code（Team Standard シート）

ツアー一覧

ディレクトリ	対象	期間
tour-01/	BS本部（BSG・ISG・BPM-SG）	2026年4月23日〜5月28日
tour-02/	PS本部・経営企画室・R&D推進室・管理本部・営業本部・ITSV（グループ会社）	2026年7月（6月募集）
tour-03/	システム第1本部	TBD
tour-04/	システム第2本部	TBD

チーム

役割	名前	担当
運営リード	古賀	会場準備、参加者対応、SharePoint、アンケート
講師・カリキュラム	菊池	レジュメ作成、当日講師、技術選定
当日サポート	藤井（菊池の同期）	ハンズオン中のフロア支援
運営サポート（tour-02〜）	TBD（調整中）	未定

ディレクトリ構成

ai-driven-dev-workshop-bshq/
├── tour-01/                     # BS本部（第1弾）
│   ├── inputs/                  # 申込フォーム回答・打合せ文字起こし
│   │   ├── form-responses/
│   │   │   ├── raw/             # ⚠️ Git管理外（個人情報あり）
│   │   │   └── masked/          # Git管理対象（匿名化済み）
│   │   └── meeting-transcripts/
│   ├── operations/              # 運営実行（議事録・リスク台帳・ADR等）
│   ├── planning/                # AI壁打ちの記録（企画・カリキュラム設計）
│   ├── retrospective/           # ワークショップ後の振り返り・分析
│   └── workshop/                # 参加者向けサイト（Cloudflare Pages配信）
│       ├── index.html
│       └── sessions/
│           ├── session-01/
│           ├── session-02/
│           └── session-03/
├── tour-02/                     # PS本部他（第2弾） ← 同じ構造
├── tour-03/                     # システム第1本部（第3弾）
├── tour-04/                     # システム第2本部（第4弾）
└── scripts/deploy.ps1           # $TourDir を切り替えてデプロイ

重要なファイル（tour-01 の例）

ファイル	内容	更新頻度
TODO.md	セッション跨ぎの日々タスク（進行中・完了済み）	随時
tour-01/operations/timeline.md	マイルストーン・定例アジェンダ	随時
tour-01/operations/risk-register.md	リスク台帳（深刻度・対策・ステータス）	定例ごと
tour-01/operations/principles.md	運営5原則	安定
tour-01/planning/form-response-analysis-*.md	申込フォーム分析	締切後に最終版
tour-01/operations/senior-reviews/	シニアレビュー結果	レビュー実施時
tour-01/operations/decisions/0003-*.md	契約プラン・工数計上ADR	確定済み
tour-01/operations/survey/template.md	各回ふりかえりシートの設問定義	安定

Claude Codeでの作業ルール

サブエージェント運用とモデル使い分け MUST

菊池は矢継ぎ早に指示を出すスタイル。メインセッションは受付・分配・検収に徹し、重い作業は積極的にサブエージェントへ切り出す（原則バックグラウンド実行で並行させる）。

切り分けの単位はタスクの種類。種類の違う作業を1エージェントに混ぜない:

タスク種別	例	推奨モデル
統括・検収・ユーザー対話	指示の解釈、成果物の検収、講義資料への最終組み込み、判断が要る編集	メインセッション（Fable）が自分で行う。エージェント化しない
正確さが命の調査	公式ドキュメント裏どり、セキュリティ・技術調査、出典検証	Opus
複雑な制作	講義本文ドラフト、ダミーコードベース制作、コード解読・分析、複数ファイルにまたがる編集	Opus
量産・定型生成	ブレストの大量出し、ダミーデータ・素材の量産、Markdown整形、決まった型への流し込み	Sonnet
軽作業	ファイル探索のスカウト、一覧化、抽出・変換、単純な集計	Haiku

• 迷ったら1段上のモデルを使う（品質事故のやり直しの方が高くつく）
• モデル指定は Agent ツールの model パラメータ（fable / opus / sonnet / haiku）で行う
• 同一ファイルへの書き込みは同時に1エージェントまで（lecture.html 等での編集競合を防ぐ。過去に競合しかけた実績あり）
• エージェントの成果物は必ずメインで検収してから講義資料・運営文書に反映する（特に技術的主張・数値は出典と突き合わせる）
• エージェントへの依頼には「前提（対象者・制約・アウトプット形式）」を明記し、最終メッセージで返す内容を指定する

個人情報の取り扱い MUST

• tour-XX/inputs/form-responses/raw/ のファイルには氏名・メールアドレスが含まれる → Git管理外
• コミット可: 苗字＋チーム名レベル（例: operations/seating-chart-*.md などの運営用ドキュメント）
• コミット不可: フルネーム・メールアドレス・個人を特定できる詳細情報（業務詳細コメント等）
• 分析結果（planning/）は従来どおり P01/P02... 形式のマスクID推奨

ドキュメント方針

• 正式な情報源は募集スライド（operations/recruitment/recruitment-slides.md）とSlack案内文（operations/recruitment/slack-announcement.md）
• planning/ 内のドラフト（proposal-draft.md, curriculum-outline.md 等）は初期壁打ちの記録。計画のベースには使わない
• 意思決定は operations/decisions/ にADR形式で残す

参加者データ分析

• 生データ → raw/ に置いてもらう → Claude Codeがマスキング → masked/ に出力
• 分析結果は planning/form-response-analysis-YYYYMMDD.md に保存
• 締切（4/15）後のデータで最終分析を行う予定

講義資料(lecture.md)の作成方針

• ですます調で記述する。
• Claude Codeに関する技術的な内容はAnthropicの公式ドキュメント、公式ブログで裏どりをし、資料にも出典を明記する。
• 参加者はWindows環境を想定したコマンドを書く。（Macのコマンドなどは書かない）
  • tour-01: VS CodeのClaude Code拡張機能を利用している想定
  • tour-02以降: Claude CodeはClaudeデスクトップアプリの「Code」タブを基本とし、VS Code拡張でも可（どちらでも成立する説明にする。講師の投影はデスクトップアプリ）
• 参加者は講義資料をWebサイトにホストされた状態でブラウザで閲覧していることを想定する（このリポジトリの構造は見えない）。ただし、講師が当日画面投影で示す場面に限っては、この運営リポジトリ自体を実例として引用してよい。
• ハンズオンなどで参加者へ作業を指示する際は、指示通りに動かせば実行できる粒度で書く。（前提条件・操作手順・期待される結果・つまずいたときの確認ポイントが、その場で読んだ参加者にとって曖昧でないこと。「適宜〜してください」「お好みで」のような解釈の余地を残す表現は避ける。）

対外文章（Slack・メール等）のスタイル MUST

参加者向け・社内周知のSlack文面やメールを古賀さん名義で書くとき、AIっぽさを避ける。
運営自身の文面がAIっぽいとワークショップの説得力を損なう。参考記事: https://qiita.com/minorun365/items/114f53def8cb0db60f47

避ける:

• 📅🛠⏰🚀✨📚 などカテゴリ見出し用絵文字
• **📅 見出し** の太字＋絵文字セクション
• Markdownの ## 見出し をSlackに使う
• 「——そんな〜感覚——」のようなAIっぽいキャッチ構文
• 過剰な箇条書き化・装飾

OK:

• 💥🙏 などの軽い感情絵文字を文末に1〜2個
• 普通の段落書き、必要最小限の箇条書き
• 引用ブロック（>）で他者発言を差し込む
• 改行で視認性を確保（Slack向け）

判断軸: 「普段のChatGPTが出してきそうな文章か？」Yesなら書き直す。