講義進行ガイド

本ハンドブック全体(第1〜14章+共通参考)を使って講義を行う講師のための資料である。

事前準備物統合チェックリスト

各章のsetup文書(事前インストールチェックリスト)に散在していた項目を、講義開始前に一度で確認できるようまとめました。講義開始の最低1日前に参加者へこのリストを告知し、現場でインストール問題により時間を浪費しないようにする。

全体時間配分表

全ての節を丁寧に扱い、実習は参加者自身がタイピング(またはコピー&ペースト)する時間を含めて算定しました。休憩時間は別途である。

📅 1日目 — 一般ユーザー: マルチエージェント実践活用

📅 2日目 — IT専門家: アーキテクチャ・新規作成・キャップストーン

章別講師ノート

第1章: AI時代の業務革新(導入)

この章は、第2章の技術的概念に先立って「なぜAIを学ぶべきか」という動機を確立する導入部である。統計カード(McKinsey 78%+など)を見せてAI導入の加速を実感させ、AI活用3段階(利用者→活用者→設計者)の表で参加者に自身の現在位置を把握させる。

ハーネスエンジニアリング必要性比較ボックス(ハーネスなし vs あり)は、後の第2章で詳しく扱う概念のプレビューである。ここでは「感覚」だけを伝え、技術的詳細は第2章に譲る。Klarnaの事例(230万件の会話=700名の相談員)は、AIが人を代替するのではなく役割を再配置することを強調するのに有用である。

第2章: 概念

この章は、以降すべての章で使う用語(オーケストレーター、スペシャリスト、ハンドオフ、サブエージェント)の基準点となるため、ペースを落としてもよい。比喩(料理、新入社員、宅配送り状)をホワイトボードに描きながら説明すると理解度が大きく向上する。

第3章: ガードレールと権限モデル

第6章§2実習の直前に配置されている理由がある。サブエージェントを直接作る前に「何を許可し何を止めるか」を先に決める習慣をつけるためである。危険作業3段階分類表を見せながら、「あなたが今から作るreviewerはどの段階に該当しますか?」とあらかじめ問いかけると、第6章§2実習へ自然につながる。

第4章 · デザイン基盤とアクセシビリティ

色を装飾ではなく状態と行動の契約として説明する。グレースケールでもエラー、選択、次の行動が分かるかを確認する。

第5章 · i18n設計とコンテンツ品質

自然な翻訳だけでなく、キー、長い文字列、日時・通貨、エラー状態を確認させる。

ウォームアップ実習: テトリスからパックマンまで

休憩1の直後、第6章の本格的な実習の前に行う。claude.aiまたはClaude Codeを使用し、第6章でグループごとにツールを分けるのとは異なり、全員が同じプラットフォームで進める。

テトリス(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の単一エージェントの限界(コンテキスト過負荷)を直接体験したことを想起させる。「このウォームアップで感じたことを、続く第6章実習でツール別サブエージェントとしてさらに深く体験します」と第6章へつなぐ。

第6章§1/第6章§2: 実習

参加者を4グループ(Claude Desktop App/Claude Code/Antigravity Desktop/Antigravity CLI)に分け、それぞれ異なるツールで同じシナリオを進めさせると、最後に結果を比較する際に共通参考の「ツール比較」内容がはるかによく伝わります。

第7章(軽め): ai-workspace-standardsの紹介

1日目では第8章実習に必要な最小限の概念のみを扱う。リポジトリとは何か、コアファイル4種の役割、variantとは何か、そしてスキャフォールディングによるプロジェクト作成の基本的な流れだけを伝えれば十分である。L0→L1→L2→L3階層構造やモデルティアリングなどは2日目の深掘りで扱う。

第8章: 既存variantの活用(1日目)

この実習は第8章全体が既存variant活用に割り当てられる。G-1(co-consult Physical AI市場調査)は40分、G-2(co-deck韓食世界化発表資料)は40分で、2つの実習合計80分の十分な時間を確保した。これが2日間ワークショップの中核実習時間である。

new-project.tsの実行時に実際にGitHubクローンが長く時間がかかる場合があるため、この実習を始める前にあらかじめワークスペースをクローンしておくよう事前告知することが重要です(上記の事前準備物チェックリスト参照)。

第9章: 2つのモデル比較+カンバン(2日目)

2日目に配置される。カンバン節は、実際に社内ヘルプデスク/サポートチームの運用経験がある参加者がいれば、その経験を先に聞いてから始めるのが効果的である。「なぜ必要か」を理論として説明する前に、「チケットが滞留した経験はありますか?」から始めると共感が早く形成されます。IT専門家対象であるため、GitHub Projects/Jira連携など実務的な実装方法まで言及するとよい。

第10章: ai-workspace-standardsアーキテクチャ(2日目)

2日目では1日目の軽い紹介を引き継ぎ、L0→L1→L2→L3階層構造、templates・variant 13種の内部構造、モデルティアリング、セッション開始チェックリスト、まだ実装されていない高度化ロードマップ(§5)まで詳しく扱う。L3プロジェクトアップグレードは独立した第12章で扱う。すべてを暗記させる必要はなく、「なぜこの階層構造が必要なのか」という動機さえ確実に伝われば十分である。

第11章: ワークフローデザインパターン

5つのオーケストレーションパターンを復習した後、コードレビュー・市場調査・プレゼンテーションなどの実際のワークフロー事例を見せる。「この業務にはどのパターンが合うか?」の意思決定ツリーを一緒に解いてみる。

第12章: L3プロジェクトアップグレード(2日目)

第10章§1で学んだフォークモデルの実際の活用編である。「L1テンプレートが変わっても自分のプロジェクトには自動的に反映されない」という点を想起させながら始める。LOCKED・MERGE・PRESERVE・SYNC_IF_NEWERにTEMPLATE TREE SYNCなどを加えた主要分類のうち、MERGEのワークスペース管理マーカー構造を視覚的に見せると理解度が高まる。--dry-runを先に実行する習慣を強調し、実際のスクリプト実行は講師がデモすることを推奨する。

共通参考: ツール比較(2日目)

2日目に配置される。1日目の第6章§1/§2実習で参加者がツールを直接体験しているため、「先ほど使ったツールでこれがなぜこう動作したのか」という形で振り返りながら進めると、純粋な講義よりはるかに没入度が高くなります。IT専門家対象であるため、teammateMode(in-process vs tmux)、Agent Managerの内部構造など技術的詳細を深く扱うことができる。

第13章: 新規variant作成

この章は2日目に配置される。1日目に既存のバリアント(variant)を直接扱った経験を基に、今回は自分だけのバリアント(variant)を最初から作ってみる。実習(D-1)50分+講義20分で構成する。

第14章: 新規variant昇格

2日目後半に配置される。第13章で作ったco-retailプロトタイプを昇格準備する段階である。

第15章: Domain Operating Model

第14章の昇格実習の直後、キャップストーン設計の直前に置かれた理論章である。「昇格されたテンプレートには何が生まれるのか」への答え — ステージ・RACI・判断ゲートがデータとして宣言されるDomain Operating Model構造(ADR-0083・0084)を扱う。

第16章: キャップストーン実習

2日目の中核実習である。1日目(既存variant活用)と第13章(新規variant作成)の経験を全て合わせ、参加者自身の実際の業務にマルチエージェントチームを適用する設計を直接行わせる。

この章には正解がないことを先に明確にしてください。参加者が「何を作ればよいか」戸惑う場合は、講師が自身の例(例: 「毎週の会議録アクションアイテム整理」)を先にデモして質問の流れを見せるのが効果的である。時間が切迫していれば、4段階全てを実行するよりも、最低限1〜2段階(問題定義・ガードレール決定)までは全員が終え、3〜4段階は宿題として残してもよいです。

まとめ

2日間全体の振り返り。1日目に既存のバリアント(variant)でエージェントチームを稼働させた経験と、2日目に新規のバリアント(variant)を直接作り昇格させた経験をつなげて整理する。

章別確認質問

各章を終えるたびに以下の質問を投げかけて理解度を確認してください。正解を当てることが目的ではなく、参加者自身に説明させることが目的である。

📅 1日目確認質問

📅 2日目確認質問