講義進行ガイド
本ハンドブック全体(第1〜13章+共通参考)を使って講義を行う講師のための資料である。
事前準備物統合チェックリスト
各章のsetup文書(事前インストールチェックリスト)に散在していた項目を、講義開始前に一度で確認できるようまとめました。講義開始の最低1日前に参加者へこのリストを告知し、現場でインストール問題により時間を浪費しないようにする。
gh auth loginが可能なGitHubアカウント。アカウントがない参加者には第4章§2-A実習準備節の登録案内に事前に従うよう告知agy)のインストール完了。第4章§2-A実習準備節のOS別スクリプトで検証bun --version、git --versionが正常に出力されることを確認git clone https://github.com/5throck/ai-workspace-standards.gitをワークスペースルート位置(Windows C:\git、macOS/Linux ~/git)に事前にクローン全体時間配分表
全ての節を丁寧に扱い、実習は参加者自身がタイピング(またはコピー&ペースト)する時間を含めて算定しました。休憩時間は別途である。
📅 1日目 — 一般ユーザー: マルチエージェント実践活用
| 区分 | 内容 | 形態 | 予想時間 |
|---|---|---|---|
| 導入 | 講義目標・2日間全体のロードマップ紹介、事前準備物の確認 | 講義 | 10分 |
| 第1章 | 今なぜAIなのか(導入統計)、AI活用の3段階(利用者→活用者→設計者)、ハーネスエンジニアリングの必要性(ハーネスなし vs ありの比較)、マルチエージェントの原理(単一 vs マルチ比較表)、実務時間短縮事例、本ワークショップのロードマップ | 講義 | 30分 |
| 第2章 | Prompt→Context→Harnessの流れ、ハーネスエンジニアリングの定義、単一エージェントの限界、マルチエージェントチームの構成要素(オーケストレーター・スペシャリスト・ハンドオフ契約)、サブエージェント(事前定義 vs 動的生成)、オーケストレーションパターン5種と再試行・ロールバック・エスカレーション、動的チーム構成とワークフローの組み合わせ、AGENTS.md標準 | 講義+確認質問 | 45分 |
| 第3章 | ガードレールの必要性、危険作業の3段階分類(読み取り/書き込み/破壊的)、最小権限の原則(toolsフィールド)、人による承認ゲート、隔離(worktree・sandbox)、監査ログと可観測性 | 講義 | 20分 |
| ウォームアップ実習 | テトリス(バイブコーディング、ハーネスなし10分)+パックマン(単一プロンプト失敗体験後、企画→開発→QAの3段階マルチエージェント25分)+気づきの整理(5分) | 実習(参加者自身) | 40分 |
| 第4章§1+第4章§2 | 4つのツール(Claude Desktop App/Code、Antigravity Desktop/CLI)でのサブエージェント定義・呼び出し・逐次パイプライン・動的チーム構成・並列実行・モデルティア比較実習(G-1/D-1/D-2/P-1/P-2) | 実習(参加者自身) | 80分 |
| 第5章(軽め) | ai-workspace-standardsリポジトリ概要、コアファイル4種(AGENTS.md・CONSTITUTION.md・CLAUDE.md・GEMINI.md)、variantとは何か、スキャフォールディングによるプロジェクト作成の基本 | 講義 | 20分 |
| 第6章(①既存活用G-1) | co-consultでPhysical AI市場調査プロジェクトをスキャフォールディング・稼働 — 4段階設計フレームワークの適用、7段階コンサルティングワークフローの稼働、成果物レビュー・ハンドオフの追跡 | 実習(参加者自身) | 40分 |
| 第6章(②既存活用G-2) | co-deckで韓食世界化発表資料をスキャフォールディング・稼働 — 発表テーマフレームの設定、11段階パイプラインの稼働、成果物のレビュー・改善、TTS・自動スライド設定 | 実習(参加者自身) | 40分 |
| 1日目まとめ | 本日学んだ内容の要約、2つのvariant(co-consult vs co-deck)の構造比較の振り返り、2日目の予告(IT専門家セッション) | ディスカッション | 10分 |
| 1日目合計 | 約5時間35分(休憩除く) | ||
📅 2日目 — IT専門家: アーキテクチャ・新規作成・キャップストーン
| 区分 | 内容 | 形態 | 予想時間 |
|---|---|---|---|
| 1日目復習 | コア概念の要約、第6章既存variant活用実習の成果共有 | ディスカッション | 10分 |
| 第8章§1 | L0→L1→L2→L3階層構造の詳細、フォークモデル、ファイル別SSOTの流れ | 講義 | 15分 |
| 第8章§2 | エージェント・スキル・スクリプトのライフサイクル管理 | 講義 | 15分 |
| 第10章 | 第10章・L3プロジェクトアップグレードの使い方、ファイル処理5分類、スナップショット・ロールバック、昇格との方向性の違い | 講義 | 15分 |
| 第9章 | ワークフローデザインパターン — 構成要素、ドメイン別事例、選択ガイド | 講義 | 15分 |
| 共通参考 | 4つのツール構造の一覧、Claude Desktop App vs Code(サブエージェント定義、teammateMode)、Antigravity vs agy(Agent Manager、/goal・/agent・/agents)、マルチエージェント対応範囲比較表、実習ツール選択ガイド、AGENTS.md統合構造 | 講義 | 25分 |
| 第7章 | サービスチケットモデル、開発ツール+variantモデル、カンバンベース運用の必要性、両モデルの長短所比較 | 講義+ディスカッション | 30分 |
| 第11章(①新規作成D-1) | co-retail Phase Aプロトタイプの作成 — create-l3-scaffold、ドメインエージェント定義(researcher・writer)、AGENTS.mdロスターの更新、agent:verify | 実習(参加者自身) | 40分 |
| 第11章(②講義) | 最初から作る(Phase A→B) vs 既存プロジェクトの昇格、2つの経路の違いと選択基準 | 講義 | 20分 |
| 第12章・新規variant昇格 | プロトタイプの検証(validate-templates・agent:verify)、昇格チェックリスト/マニフェストの作成(参加者実習)、実際の昇格パイプライン実行(講師デモのみ) | 実習+デモ混合 | 60分 |
| 第13章・キャップストーン実習 | 自身の反復作業を選び、4段階(問題定義・ガードレール設計・サブエージェント実装・検証振り返り)を自ら設計 | 実習(参加者自身) | 60分 |
| キャップストーン発表 | 1〜2名が自身のワークフローを短く共有、参加者フィードバック | 発表 | 15分 |
| まとめ | 2日間全体の振り返り、Q&A、用語集/FAQ案内、次のステップ案内 | ディスカッション | 15分 |
| 2日目合計 | 約5時間40分(休憩除く) | ||
章別講師ノート
第1章: AI時代の業務革新(導入)
この章は、第2章の技術的概念に先立って「なぜAIを学ぶべきか」という動機を確立する導入部である。統計カード(McKinsey 78%+など)を見せてAI導入の加速を実感させ、AI活用3段階(利用者→活用者→設計者)の表で参加者に自身の現在位置を把握させる。
ハーネスエンジニアリング必要性比較ボックス(ハーネスなし vs あり)は、後の第2章で詳しく扱う概念のプレビューである。ここでは「感覚」だけを伝え、技術的詳細は第2章に譲る。Klarnaの事例(230万件の会話=700名の相談員)は、AIが人を代替するのではなく役割を再配置することを強調するのに有用である。
参加者アクティビティ 「現在自分はAI活用3段階のうちどこに近いと思いますか?」を挙手で投票させると、第2章への興味が生まれる。第2章: 概念
この章は、以降すべての章で使う用語(オーケストレーター、スペシャリスト、ハンドオフ、サブエージェント)の基準点となるため、ペースを落としてもよい。比喩(料理、新入社員、宅配送り状)をホワイトボードに描きながら説明すると理解度が大きく向上する。
参加者アクティビティ §4の3つのパターン(ファンアウト/パイプライン/検証後適用)のうち1つを選び、「自分たちのチーム業務に適用するなら?」を隣の人と1分ずつ話し合わせることを推奨する。第3章: ガードレールと権限モデル
第4章§2実習の直前に配置されている理由がある。サブエージェントを直接作る前に「何を許可し何を止めるか」を先に決める習慣をつけるためである。危険作業3段階分類表を見せながら、「あなたが今から作るreviewerはどの段階に該当しますか?」とあらかじめ問いかけると、第4章§2実習へ自然につながる。
ウォームアップ実習: テトリスからパックマンまで
休憩1の直後、第4章の本格的な実習の前に行う。claude.aiまたはClaude Codeを使用し、第4章でグループごとにツールを分けるのとは異なり、全員が同じプラットフォームで進める。
テトリス(10分): 講師が先に1分間デモを行い、参加者がそれに続く。「HTML Canvasでテトリスゲームを作って」と入力すると、バイブコーディングだけで即座に動作する結果が得られる。修正要求(背景色、スコアボードなど)も問題なく反映される。この時点で「この程度の複雑さ(~200行)ならハーネスなしでも十分である」ことを強調する。
パックマン(25分): まず単一プロンプト(「HTML Canvasでパックマンゲームを作って」)で試させ、2〜3分間失敗を体験させる — キャラクター移動・ゴーストAI・衝突判定・マップ設計が同時に入ると、コードが絡まって動作しない。その後、3ステッププロンプトを画面に表示する。Step 1企画エージェント(「パックマンの機能一覧とマップ構造を仕様書としてまとめる」)→Step 2開発エージェント(「上記仕様書に基づきHTMLパックマンコードを作成」)→Step 3 QAエージェント(「このコードのバグを見つけて修正」)。各ステップ約7〜8分。
気づき(5分): テトリス(~200行)とパックマン(~1,000〜1,500行)のコード量の違いを見せながら、第2章§2の単一エージェントの限界(コンテキスト過負荷)を直接体験したことを想起させる。「このウォームアップで感じたことを、続く第4章実習でツール別サブエージェントとしてさらに深く体験します」と第4章へつなぐ。
第4章§1/第4章§2: 実習
参加者を4グループ(Claude Desktop App/Claude Code/Antigravity Desktop/Antigravity CLI)に分け、それぞれ異なるツールで同じシナリオを進めさせると、最後に結果を比較する際に共通参考の「ツール比較」内容がはるかによく伝わります。
参加者アクティビティ G-1、D-1、D-2(動的チーム構成の観察)は全員実習。P-1(並列実行)・P-2(モデルティア比較)は時間が足りなければ講師の画面デモで代替可能。Agent Teams設定(`.claude/settings.json`)やmodelフィールドの入れ替えは、グループごとに1人だけ試しても概念は伝わる。
第5章(軽め): ai-workspace-standardsの紹介
1日目では第6章実習に必要な最小限の概念のみを扱う。リポジトリとは何か、コアファイル4種の役割、variantとは何か、そしてスキャフォールディングによるプロジェクト作成の基本的な流れだけを伝えれば十分である。L0→L1→L2→L3階層構造やモデルティアリングなどは2日目の深掘りで扱う。
共通参考: ツール比較(2日目)
2日目に配置される。1日目の第4章§1/§2実習で参加者がツールを直接体験しているため、「先ほど使ったツールでこれがなぜこう動作したのか」という形で振り返りながら進めると、純粋な講義よりはるかに没入度が高くなります。IT専門家対象であるため、teammateMode(in-process vs tmux)、Agent Managerの内部構造など技術的詳細を深く扱うことができる。
第7章: 2つのモデル比較+カンバン(2日目)
2日目に配置される。カンバン節は、実際に社内ヘルプデスク/サポートチームの運用経験がある参加者がいれば、その経験を先に聞いてから始めるのが効果的である。「なぜ必要か」を理論として説明する前に、「チケットが滞留した経験はありますか?」から始めると共感が早く形成されます。IT専門家対象であるため、GitHub Projects/Jira連携など実務的な実装方法まで言及するとよい。
ディスカッション 「自組織ならどちらのモデルが合うか?」を5分間の小グループディスカッション後、発表。第8章: ai-workspace-standardsアーキテクチャ(2日目)
2日目では1日目の軽い紹介を引き継ぎ、L0→L1→L2→L3階層構造、templates・variant 11種の内部構造、モデルティアリング、セッション開始チェックリスト、まだ実装されていない高度化ロードマップ(§5)まで詳しく扱う。L3プロジェクトアップグレードは独立した第10章で扱う。すべてを暗記させる必要はなく、「なぜこの階層構造が必要なのか」という動機さえ確実に伝われば十分である。
第10章: L3プロジェクトアップグレード(2日目)
第8章§1で学んだフォークモデルの実際の活用編である。「L1テンプレートが変わっても自分のプロジェクトには自動的に反映されない」という点を想起させながら始める。LOCKED・MERGE・PRESERVE・SYNC_IF_NEWERの5分類のうち、MERGEのワークスペース管理マーカー構造を視覚的に見せると理解度が高まる。--dry-runを先に実行する習慣を強調し、実際のスクリプト実行は講師がデモすることを推奨する。
--dry-runを実行させると、より実感がわく。
第6章: 既存variantの活用(1日目)
この実習は第6章全体が既存variant活用に割り当てられる。G-1(co-consult Physical AI市場調査)は40分、G-2(co-deck韓食世界化発表資料)は40分で、2つの実習合計80分の十分な時間を確保した。これが2日間ワークショップの中核実習時間である。
new-project.tsの実行時に実際にGitHubクローンが長く時間がかかる場合があるため、この実習を始める前にあらかじめワークスペースをクローンしておくよう事前告知することが重要です(上記の事前準備物チェックリスト参照)。
第11章: 新規variant作成
この章は2日目に配置される。1日目に既存のバリアント(variant)を直接扱った経験を基に、今回は自分だけのバリアント(variant)を最初から作ってみる。実習(D-1)40分+講義20分で構成する。
参加者アクティビティ D-1(co-retail Phase Aプロトタイプを自ら作成)は全員実習。1日目のG-1でエージェント定義ファイルのfrontmatter構造をすでに見ているため、今回は直接researcher・writerを作ってみる。時間が厳しければ、ペア活動(1人がタイピング、1人が検証コマンドを実行)で進めてもよい。第9章: ワークフローデザインパターン
5つのオーケストレーションパターンを復習した後、コードレビュー・市場調査・プレゼンテーションなどの実際のワークフロー事例を見せる。「この業務にはどのパターンが合うか?」の意思決定ツリーを一緒に解いてみる。
第12章: 新規variant昇格
2日目後半に配置される。第11章で作ったco-retailプロトタイプを昇格準備する段階である。
講師デモ専用 実際のl3-to-variant-pipeline.tsの実行は、git履歴に影響を与える非可逆的な作業である。参加者全員に真似させるのではなく、講師が画面共有で1回実行して見せるだけで十分である。参加者が自分で試してみたい場合は、講義終了後、個人環境(ワークショップ専用クローンフォルダ)で行うよう案内してください。
参加者アクティビティ PROMOTION_CHECKLIST.md項目の確認とvariant.jsonマニフェストの作成までは全員実習可能である。
第13章: キャップストーン実習
2日目の中核実習である。1日目(既存variant活用)と第11章(新規variant作成)の経験を全て合わせ、参加者自身の実際の業務にマルチエージェントチームを適用する設計を直接行わせる。
この章には正解がないことを先に明確にしてください。参加者が「何を作ればよいか」戸惑う場合は、講師が自身の例(例: 「毎週の会議録アクションアイテム整理」)を先にデモして質問の流れを見せるのが効果的である。時間が切迫していれば、4段階全てを実行するよりも、最低限1〜2段階(問題定義・ガードレール決定)までは全員が終え、3〜4段階は宿題として残してもよいです。
参加者アクティビティ 完了チェックリストを活用して各自どこまで終えたかを自分で示させ、キャップストーン発表の時間に1〜2名が自身のワークフローを短く共有するようにする。まとめ
2日間全体の振り返り。1日目に既存のバリアント(variant)でエージェントチームを稼働させた経験と、2日目に新規のバリアント(variant)を直接作り昇格させた経験をつなげて整理する。
章別確認質問
各章を終えるたびに以下の質問を投げかけて理解度を確認してください。正解を当てることが目的ではなく、参加者自身に説明させることが目的である。
📅 1日目確認質問
- AI活用3段階(利用者・活用者・設計者)のうち、現在自分はどこに近いと思いますか?
- 「ハーネスなしでAIを使うこと」と「ハーネスを備えて使うこと」の最大の違いは何ですか?
- 単一のAI vs マルチエージェントチーム — コンテキスト・検証・並列性の観点でそれぞれどのような長短所がありますか?
- プロンプトエンジニアリングとハーネスエンジニアリングの違いを一文で説明してみてください。
- サブエージェントを「事前定義」する方式と「動的生成」する方式の長短所は?
- 並列ファンアウトとパイプライン、どちらを使うかは何を基準に決めますか?
- 危険作業3段階(読み取り/書き込み/破壊的)のうち、reviewerサブエージェントとファイル削除作業はそれぞれどこに該当しますか?
- 再試行・ロールバック・エスカレーションのうち何を選ぶかは、どのような基準で判断しますか?
- テトリスはバイブコーディングでうまく作れましたが、パックマンはなぜ単一プロンプトでは作りにくかったのですか?
- パックマンを企画→開発→QAに分けたことと、1つのエージェントにすべて任せたことの違いは何ですか?(→第2章§2の役割衝突)
- writerとreviewerを並列で呼び出すと、なぜ失敗する可能性がありますか?
- Claude Desktop Appでフックが発火しないという事実を知らなかった場合、どのような事故が起こり得ますか?
- D-2で同じサブエージェントチームなのに、リクエストによって投入構成が変わったのはなぜですか?
- AGENTS.md、CONSTITUTION.md、CLAUDE.md、GEMINI.md — それぞれどのような役割を果たしますか?
- バリアント(variant)をスキャフォールディングすると、プロジェクトフォルダに何が生成されますか?
- co-consultの7段階コンサルティングワークフローにおいて、Phase 1.5(相互検証)がなぜ必要ですか?
- 4段階設計フレームワークにおいて「検証基準」が数値で測定可能でなければならない理由は何ですか?
- co-consult(レポート)とco-deck(発表資料)のエージェント構成がなぜこれほど異なるのですか?
📅 2日目確認質問
- CONSTITUTION.mdはどの階層の共有標準ですか? L0(ワークスペースルート)のSSOTは何ですか? L2/L3プロジェクトでcontext.mdはどのような役割を持ちますか?
- L1→L2が「フォーク」で終わる理由は何ですか?
- エージェント役割別のモデルティアリングがなければ、どのような問題が生じますか?
- LOCKEDとMERGE分類の違いは何ですか?
- なぜ
--dry-runを先に実行すべきですか?
- teammateModeのin-processとtmuxの違いは?
- サービスチケットモデルにカンバンがないと、具体的にどのような問題が生じますか?(可視化されたキュー/WIP制限/優先順位のうち1つを選んで説明)
- Phase Aプロトタイプを
Projects/に作る理由は何ですか?templates/に直接作ってはいけないのですか? - エージェント定義の
handoff_toとhandoff_fromが食い違うと、agent:verifyではどのように現れますか?
- コードレビューワークフローにおいて「検証後適用」パターンがなぜ必須ですか?
- 5つのドメイン事例のうち、自身の業務と最も似ているパターンはどれですか?
- 最初から作る経路と昇格経路のうち、「設計が使用に先立つ」という表現はどちらに該当しますか?
- reconcile段階と
_ORIGIN.mdの手動移管は、それぞれ何を処理しますか?
- 自身が選んだ反復作業は、§2の3つの限界(コンテキスト過負荷/役割衝突/並列性の欠如)のうちどれが原因でチームが必要でしたか?
- サブエージェントを作る前にガードレールから決めた理由は何ですか?