Content is user-generated and unverified.

Vibe Coding研修詳細タイムテーブル

M1: 導入とマインドセット転換（30分）

0-5分：問題提起

キラーフレーズ： 「GitHubのCopilotは便利だけど、客先で『これ、データどこに送られてるんですか？』って聞かれたら答えられますか？」

実際に話す内容：

画面共有：某大手企業のAI利用ガイドライン（実例）
「SESの皆さんが直面する現実：使いたいけど使えない、このジレンマを今日解決します」
データ：国内企業の68%がAI導入を検討するも、実際に導入は12%という現実

5-15分：Vibe Codingの本質

キラーフレーズ： 「ChatGPTにコードをコピペして『直して』って言うのは、もう古い。AIが横に座って一緒にコーディングする時代です」

理解してほしいこと：

Chat型：人間が指示 → AI が回答 → 人間がコピペ（分断された作業）
Vibe型：AIが開発環境に常駐し、文脈を理解して自然にサポート

実際に話す内容：

実演：「従来のやり方」vs「Vibe Coding」のライブ比較
「指示待ち部下」vs「優秀なペアプログラマー」の例え
開発速度3倍向上の実データ表示

15-25分：セキュリティ懸念の正しい対処法

キラーフレーズ： 「『AIは危険』じゃない。『どこの誰が作ったAIを、どこのサーバーで動かすか分からない』のが危険なんです」

理解してほしいこと：

問題はAI技術そのものではなく、データの流れと管理
Azure OpenAI = Microsoftの日本データセンター、企業向けSLA、ログ管理

実際に話す内容：

図解：データフローの可視化（ローカル→Azure Japan→ローカル）
「コンプライアンス担当者にはこう説明してください」実演
実際の導入承認書類のテンプレート提示

25-30分：研修全体の学習戦略

キラーフレーズ： 「今日学ぶ12のスキル、全部覚える必要はありません。M2〜M4だけでも現場の生産性は2倍になります」

実際に話す内容：

ロードマップ提示：「明日から使う」「1週間後に追加」「1ヶ月後にマスター」
「無理に全部やろうとして挫折するより、1つずつ確実に」

M2: 基本環境構築（45分）

0-5分：ツール選定戦略

キラーフレーズ： 「ツールは武器です。シチュエーションに合わせて使い分けができるエンジニアが強い」

理解してほしいこと：

gemini-cli：軽量、高速、ちょっとした確認に最適
Claude Code：ターミナル主体、サーバー作業やCLI開発向け
Cline：VSCode統合、フロントエンド開発やGUI作業向け

実際に話す内容：

場面設定：「急ぎのバグ修正」「新規API開発」「UI調整」での使い分け
「全部覚えなくていい、まずは1つ選んで使いこなそう」

5-20分：gemini-cli環境構築

キラーフレーズ： 「APIキーの扱いを間違えると、月末に請求書で心臓が止まります」

実際に話す内容：

画面収録：Google AI Studioでのプロジェクト作成を最初から最後まで
「環境変数設定、絶対に.bashrcに直書きしないでください」の警告
実演：export GEMINI_API_KEY=sk-xxx... → gemini "Hello world"
トラブル実演：「Command not found」エラーの解決法

20-35分：Claude Code環境構築

キラーフレーズ： 「Anthropicのモデルは『考えてから書く』。雑なプロンプトでも質の高いコードが出ます」

実際に話す内容：

Anthropic Console画面の実操作を録画
料金体系の説明：「1リクエスト約2-5円、月額制限設定の重要性」
実演：claude "Pythonでファイル読み込み関数作って" → 出力解説
「Claudeは推論ステップを見せてくれるので、AIの思考が分かります」

35-45分：Cline (VS Code) 環境構築

キラーフレーズ： 「ClineはVSCodeの中で生きています。ファイル構造を理解して、プロジェクト全体を見渡してコードを書きます」

実際に話す内容：

Extensions検索「cline」から「Install」までの画面録画
Azure OpenAIの画面で「Keys and Endpoint」の場所を指差し
実演：.envファイル作成とAZURE_OPENAI_API_KEY設定
「初回のAsk Agent、緊張の瞬間ですね」→実際にHello World

M3: 初回体験（30分）

0-10分：安全な初回タスクの選び方

キラーフレーズ： 「AIを使うときの鉄則：『壊れても大丈夫なもの』から始める。本番環境でいきなり使うのは自殺行為です」

理解してほしいこと：

「新規ファイル作成」「単体関数」「テストコード」から始める
「既存の重要ファイル直接編集」は慣れてから
必ずgitで管理された環境で実験

実際に話す内容：

「私も最初、既存のAPIをAIに直させて、2時間後にサーバーが落ちました」（失敗談）
チェックリスト提示：「初回タスクに適したもの・適さないもの」
「バックアップ取ってますか？git status確認してますか？」

10-20分：実際の操作体験

キラーフレーズ： 「魔法の瞬間です。『配列をソートして』って言ったら、言語を指定してないのに、プロジェクトファイルを見て自動でPythonで書いてくれました」

実際に話す内容：

画面録画：「配列をソートする関数を作って」をClineに指示
AIの出力を1行ずつ解説：「ここでPythonを選んだ理由」「docstringまで書いてくれる」
「このコードをそのまま使いますか？私ならここを修正します」
実演：出力されたコードを実際に実行してテスト

20-30分：トラブルシューティング

キラーフレーズ： 「AIが思ったのと違うコードを書いたら、腹を立てる前に『自分の指示が曖昧だったかも』と考えてください」

実際に話す内容：

実演：「Rate limit exceeded」エラーの画面とその対処
実演：曖昧な指示「いい感じにして」→微妙な出力→具体的な指示「○○を××に修正」→良い出力
「AIは優秀な新人エンジニア。具体的に指示すれば期待通りに動きます」
実際のエラーログ例とその読み方

M4: 作業ログとgit連携（45分）

0-10分：なぜ作業ログが重要なのか

キラーフレーズ： 「客先で『この機能、誰が作ったんですか？AIですか？』と聞かれて、『はい』としか答えられないエンジニアは信用されません」

理解してほしいこと：

SESの価値は「技術力」だけでなく「説明責任」「品質保証」
AIを使ったことを隠すのではなく、「AIを適切に活用して品質を担保した」と説明できることが重要
ログは自分の身を守る保険でもある

実際に話す内容：

実例：「AIが書いたコードにバグがあって、『なぜこの実装にしたのか』を説明できずに信頼失墜したケース」
「AIツールは『魔法の箱』ではありません。使いこなすプロフェッショナルが必要」
「ログがあれば、問題発生時も迅速に原因特定・修正できます」

10-25分：効果的な作業ログの書き方

キラーフレーズ： 「このテンプレート、私が3年間の試行錯誤で作りました。これがあれば客先でも堂々と報告できます」

実際に話す内容：

画面に実際のテンプレートを表示：

## AIタスクログ
**日時:** 2025-06-30 14:30
**ツール:** Cline (Azure OpenAI GPT-4)
**タスク:** ユーザー認証機能の実装
**入力プロンプト:** [実際のプロンプトを記録]
**出力結果:** [生成されたコードの概要]
**人間の判断:** [採用/修正/却下の理由]
**検証結果:** [テスト実行結果]
**課題・改善点:** [次回への改善ポイント]

実演：実際にこのテンプレートを使って作業ログを作成
「コピペして使ってください。最初は面倒でも、慣れれば5分で書けます」

25-40分：git連携による履歴管理

キラーフレーズ： 「git commit -m "AI generated"は最悪です。何を生成したか分からない。『feat: AI実装によるユーザー認証API追加(Claude/プロンプト詳細は作業ログ参照)`これが正解」

実際に話す内容：

ターミナル画面で実演：適切なcommit messageの書き方
実演：ブランチ戦略「feature/ai-experiment」での安全な実験
「commitログを見れば、チームメンバーも『これはAIが書いたから注意深くレビューしよう』と分かります」
.gitignoreに作業ログファイルを追加する設定

40-45分：チーム共有とレビュープロセス

キラーフレーズ： 「AIを使ったことを後ろめたく思う必要はありません。『効率化ツールを使いこなすプロ』として堂々としてください」

実際に話す内容：

Slackやチャットでの報告例：「本日の作業でAIツールを活用し、○○機能を実装しました。作業ログは△△に保存済み」
「客先への月次報告でも『AI活用による効率化と品質向上』として正々堂々と報告」
「隠すのではなく、プロフェッショナルな活用として示す」

M5: よくある失敗とRule設計（60分）

0-15分：テスト時ハードコーディング問題

キラーフレーズ： 「AIは『今動けばいい』で考えます。人間は『1年後もメンテナンスできるか』で考えないといけません」

理解してほしいこと：

AIは具体例で学習しているため、テストコードでも具体的な値を書きがち
ハードコーディングされたテストは時間が経つと壊れる
「動的な値検証」の重要性

実際に話す内容：

画面に悪い例を表示：

javascript

// ❌ AIが書きがちな悪いテスト
expect(user.createdAt).toBe("2024-01-01T00:00:00Z");
expect(user.id).toBe(123);

「この画面を見た瞬間に『あ、これAIが書いたな』って分かりますよね」
良い例を表示：

javascript

// ✅ 正しいテスト
expect(user.createdAt).toMatch(/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z$/);
expect(user.id).toBeGreaterThan(0);

「これをRuleに書きます：『テストでは動的な値検証を行い、固定値ハードコーディングを避ける』」

15-30分：セキュリティホールの作り込み

キラーフレーズ： 「AIに『SQLでユーザー情報を取得して』と言ったら、SQLインジェクション脆弱性満載のコードが出てきました。これが現実です」

実際に話す内容：

実際に危険なコード例を画面表示：

python

# ❌ 危険：SQLインジェクション脆弱性
query = f"SELECT * FROM users WHERE name = '{user_input}'"

「もしuser_inputに '; DROP TABLE users; -- が入ったら...」
ハッカーの攻撃例をアニメーションで説明
安全なコード例：

python

# ✅ 安全：パラメータ化クエリ
cursor.execute("SELECT * FROM users WHERE name = %s", (user_input,))

「これもRuleに：『データベースクエリは必ずパラメータ化し、直接文字列結合を禁止』」

30-45分：パフォーマンス無視とアーキテクチャ破綻

キラーフレーズ： 「AIは『動くコード』は書けますが、『本番で耐えられるコード』は人間が考えないといけません」

実際に話す内容：

ひどいコード例を表示：

python

# ❌ O(n²)の無駄なループ
for user in users:
    for order in orders:
        if order.user_id == user.id:
            user.orders.append(order)

「1000ユーザー×1000注文＝100万回ループ。AIは『動けばいい』で考えるんです」
改善版：

python

# ✅ O(n)の効率的な処理
orders_by_user = defaultdict(list)
for order in orders:
    orders_by_user[order.user_id].append(order)

「Rule：『O(n²)以上の計算量になる場合は最適化案を提示』」

45-60分：.clinerulesファイルの作成

キラーフレーズ： 「このRuleファイル、AIの性格を変える魔法の呪文です。これがあるかないかで、出力の品質が10倍変わります」

実際に話す内容：

実際の.clinerulesファイルを画面表示：

# セキュリティルール
- データベースクエリは必ずパラメータ化する
- ユーザー入力は全て検証・サニタイズする
- 認証が必要なAPIには適切な認証チェックを追加

# テストルール  
- テストでは固定値ハードコーディングを避ける
- エッジケースを必ず含める
- モックオブジェクトの適切な使用

# パフォーマンスルール
- O(n²)以上の処理は最適化を検討
- 不要なDB クエリは避ける

「これをプロジェクトルートに置くだけで、AIが『このプロジェクトのルール』を理解します」
実演：Ruleあり・なしでの出力比較

M6: 制御されたPlan/Actプロセス（45分）

0-10分：「いきなり書かせる」危険性

キラーフレーズ： 「AIに『ユーザー管理機能を作って』といきなり言うのは、新人に『適当にシステム作って』と丸投げするのと同じです」

理解してほしいこと：

仕様が曖昧なまま実装を始めると、必ず手戻りが発生
AIは「推測」で実装するが、その推測が正しいとは限らない
Plan → Act → Reviewの3段階で品質を担保

実際に話す内容：

失敗例の動画：「ECサイトを作って」→AIが勝手に決済機能まで実装→セキュリティホール満載
「曖昧な指示ほど危険なものはありません。AIは『分からない』とは言いません」
成功例：段階的に仕様を固めてから実装した場合の品質の違い
「Plan段階で10分使えば、Act段階の手戻りで1時間失うのを防げます」

10-25分：Planモードの効果的活用

キラーフレーズ： 「『設計を考えて』と言った時のAIの回答、これが優秀なシステムアーキテクトのそれです。無料でコンサルティングを受けているようなもの」

実際に話す内容：

画面録画：Clineに「ユーザー管理機能の設計を考えて」を実際に指示
AIの回答を解説：「データベース設計、API設計、セキュリティ考慮、エラーハンドリング...全部考えてくれています」
実演：設計案の中の曖昧な部分を質問で明確化
- 「パスワードの暗号化方式は？」
- 「セッション管理はどうする？」
- 「権限管理はロールベース？」
「この段階で人間が『ここは変更』『ここは追加』と指示します」

25-40分：Actモードでの実装と制御

キラーフレーズ： 「Plan通りに実装が進んでいるか、常に監視してください。AIが『いいアイデア思いついた！』と勝手に仕様変更することがあります」

実際に話す内容：

実演：確定したPlanを元にActモードで実装開始
「ここ、重要なポイントです。AIが実装中に『こうした方がいいかも』と仕様を変更しようとします」
実際の画面：AIが実装中に提案してきた変更を表示
「『いったんストップ。Planに戻って検討しましょう』と言えるかどうかがプロの判断」
部分実装での動作確認：「1つのAPIができたら必ずテスト実行」

40-45分：Memory Bankとの連携

キラーフレーズ： 「Memory Bankは、AIの『プロジェクトの記憶』です。これがないと、毎回ゼロから説明することになります」

実際に話す内容：

画面で実演：設計決定をMemory Bankに保存
「なぜこの設計にしたか、どんな代替案を検討したか、全て記録しておきます」
実演：別のセッションでMemory Bankを参照して一貫した実装
「チームメンバーが変わっても、Memory Bankがあれば設計意図が伝わります」

M7: 実用ユースケース①（コードレビュー）（30分）

0-10分：AIコードレビューの可能性

キラーフレーズ： 「人間のレビューは『この変数名分かりにくい』。AIのレビューは『この実装だとメモリリークします』。どちらも大切です」

理解してほしいこと：

AIは24時間疲れずにレビューしてくれる
セキュリティホールやパフォーマンス問題を機械的にチェック
人間は設計思想やビジネスロジックをレビュー
併用することで漏れのないレビューが可能

実際に話す内容：

統計データ表示：「AIレビューで検出される問題の種類トップ10」
「人間が見落としがちな問題：境界値チェック、エラーハンドリング、リソースリーク」
実例：「私がレビューし忘れて本番で障害になった事例」
「コードレビューの工数が50%削減されました」という導入企業の声

10-25分：実践的なコードレビュー

キラーフレーズ： 「この関数、一見普通に見えますが...AIに見せてみましょう。『セキュリティ的に危険』『パフォーマンス改善の余地あり』即座に指摘してくれます」

実際に話す内容：

画面に問題のあるコードを表示：

python

def get_user_data(user_id):
    conn = sqlite3.connect('database.db')
    cursor = conn.cursor()
    query = f"SELECT * FROM users WHERE id = {user_id}"
    result = cursor.execute(query).fetchall()
    return result

実演：このコードをClineにレビュー依頼
AIの指摘内容を読み上げ：
- 「SQLインジェクション脆弱性があります」
- 「データベース接続がクローズされていません」
- 「エラーハンドリングがありません」
「人間だと『動くからOK』で見過ごしがちですが、AIは容赦なく指摘します」
改善されたコードも生成：パラメータ化クエリ、適切なクローズ処理、try-catch

25-30分：レビュー結果の活用戦略

キラーフレーズ： 「AIのレビュー結果をそのまま鵜呑みにしてはいけません。『なぜこれが問題なのか』を理解して、チーム全体のスキルアップに繋げましょう」

実際に話す内容：

実例：AIが指摘した問題の優先度付け
- 「セキュリティ：即修正必須」
- 「パフォーマンス：負荷次第で対応」
- 「可読性：リファクタリング時に対応」
Slackでのレビュー結果共有例：「今日のAIレビューで見つかった共通課題」
「AIレビューの結果を元に、チームの弱点を把握して勉強会のテーマにする」

M8: 実用ユースケース②（コミット文・リファクタ）（30分）

0-15分：自動コミットメッセージ作成

キラーフレーズ： 「『fix bug』『update code』なんてコミットメッセージ、もう卒業しましょう。AIが『何を』『なぜ』『どう変更したか』まで書いてくれます」

理解してほしいこと：

良いコミットメッセージは未来の自分とチームメンバーへの投資
AIは変更内容を客観的に分析して適切な粒度で要約可能
Conventional Commits準拠で一貫性のあるメッセージを自動生成

実際に話す内容：

悪いコミットメッセージ例を画面表示：

  fix bug
  update
  change stuff
  work in progress

「これ、3ヶ月後に見て何をやったか分かりますか？」
実演：複数ファイルを変更後、Clineに「適切なコミットメッセージを考えて」
AIが生成したメッセージ例：

  feat: ユーザー認証APIにJWT実装
  
  - POST /auth/loginエンドポイントを追加
  - JWT生成・検証ロジックの実装
  - ミドルウェアによる認証チェック機能
  - パスワードハッシュ化にbcryptを採用
  
  Breaking Change: 既存の認証方式から移行が必要

「これなら1年後でも『何をやったか』一目瞭然です」

15-30分：AI支援リファクタリング

キラーフレーズ： 「リファクタリングは『動くコード』を『美しいコード』に変える芸術です。AIは優秀な芸術家の助手になってくれます」

実際に話す内容：

汚いコード例を画面表示：

javascript

function calc(a,b,c,d,e) {
  if(a==1) {
    if(b>c) {
      return d*e+100;
    } else {
      if(c>50) return d*e-50;
      else return d*e;
    }
  } else {
    return 0;
  }
}

「この関数、動きますが...メンテナンスしたくないですよね」
実演：Clineに「このコードをより読みやすくして、適切な関数名と変数名をつけて」
AIがリファクタリングした結果：

javascript

function calculateOrderTotal(orderType, quantity, unitPrice, basePrice, discountThreshold) {
  if (orderType !== ORDER_TYPE.PREMIUM) {
    return 0;
  }
  
  const subtotal = basePrice * unitPrice;
  
  if (quantity > unitPrice) {
    return subtotal + PREMIUM_FEE;
  }
  
  const discount = quantity > discountThreshold ? BULK_DISCOUNT : 0;
  return subtotal - discount;
}

「関数名から処理内容が分かる、変数名が意味を持つ、ロジックが明確。これがプロのコードです」
設計パターンの適用例：Strategy pattern、Factory patternの自動適用
「リファクタリング前後で必ずテストを実行。動作が変わっていないことを確認」

M9: MCP環境構築（60分）

0-15分：MCPの基本概念

キラーフレーズ： 「MCPは『AIの五感を拡張する技術』です。今までAIは目も耳も手もなかった。MCPで『ファイルを見る』『データベースに触る』『APIを呼ぶ』ができるようになります」

理解してほしいこと：

MCP = Model Context Protocol（AIがもっと多くのデータにアクセスできる仕組み）
従来：人間がデータを取得してAIに渡す→MCP：AIが直接データにアクセス
セキュリティ：AIに何をアクセス許可するかを細かく制御可能

実際に話す内容：

アナロジー：「今までのAIは『目隠しした状態で料理しろ』と言われているようなもの」
図解：MCP導入前後のデータフロー比較
「ファイルシステム、データベース、外部API、すべてAIが直接アクセス可能」
セキュリティ面の説明：「読み取り専用」「特定フォルダのみ」など権限設定
「企業導入でも安心：何にアクセスできるかは人間が完全制御」

15-35分：基本的なMCPサーバー構築

キラーフレーズ： 「設定ファイル3行書くだけで、AIがプロジェクト全体のファイルを理解できるようになります。魔法みたいでしょう？」

実際に話す内容：

画面録画：MCPサーバーの設定ファイル作成

json

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-filesystem", "./src"],
      "env": {}
    }
  }
}

「この3行で、AIが./srcフォルダ内のすべてのファイルを読めるようになります」
実演：MCP接続前後でのClineの理解度の違い
- 接続前：「ファイル構造を教えて」→「分かりません」
- 接続後：「ファイル構造を教えて」→プロジェクト全体の詳細な解析
「ファイルの中身まで読んで、関数の依存関係まで理解してくれます」
トラブルシューティング：よくある接続エラーとその解決法

35-55分：カスタムMCPサーバーの作成

キラーフレーズ： 「ここからが本番です。あなたの会社の独自システムに、AIを直接接続してみましょう」

実際に話す内容：

実演：データベース接続MCPサーバーの実装

python

# database_mcp_server.py
import sqlite3
from mcp.server import MCPServer

server = MCPServer("database")

@server.call_tool("get_users")
def get_users():
    conn = sqlite3.connect('company.db')
    return conn.execute("SELECT * FROM users").fetchall()

「これでAIが『現在のユーザー数は？』と聞かれたら、直接データベースから取得できます」
API連携MCPサーバーの例：社内Slack、GitHub、Jiraとの連携
実演：「今日のチケット一覧を取得して」→Jira APIから最新情報を取得
セキュリティ設定：読み取り専用権限、IP制限、認証トークン管理
「MCPサーバーが増えるほど、AIがあなたの会社の『何でも知ってる同僚』になります」

55-60分：運用時の注意点

キラーフレーズ： 「MCPは強力な武器です。でも銃を持った子供にならないよう、責任を持って運用しましょう」

実際に話す内容：

セキュリティチェックリスト表示：
- 機密データへのアクセス制限
- ログ監視とアクセス履歴
- 定期的な権限見直し
パフォーマンス注意点：「大量データ取得時のタイムアウト設定」
トラブル事例：「MCPサーバーが落ちてAIが使えなくなった時の対処法」
監視とアラート：「MCPサーバーの死活監視は必須」

M10: Advanced技術（45分）

0-20分：Git Worktreeによる並行開発

キラーフレーズ： 「『ブランチ切り替えめんどくさい』『複数の機能を同時に試したい』Git Worktreeは、その悩みを一発で解決します」

理解してほしいこと：

通常のgit：1つのディレクトリで1つのブランチのみ
worktree：複数のディレクトリで複数のブランチを同時に作業可能
AIとの相性：複数のAIエージェントが独立して作業できる

実際に話す内容：

困った場面の再現：「機能A開発中に緊急のバグ修正依頼」
従来の方法：「stash → checkout → fix → commit → checkout → stash pop」
実演：Git Worktreeの作成

bash

# メインプロジェクト：/project/main (mainブランチ)
# 機能開発用：/project/feature-auth (feature/authブランチ)  
# バグ修正用：/project/hotfix (hotfix/payment-bugブランチ)
git worktree add ../project-feature-auth feature/auth
git worktree add ../project-hotfix hotfix/payment-bug

「3つのターミナル、3つのVSCodeで、3つの作業を同時進行」
実演：各worktreeで異なるAIタスクを並行実行
競合解決のコツ：「worktree間でのファイル競合をAIに解決してもらう」

20-40分：ターミナルでの複数プロセス並行実行

キラーフレーズ： 「tmuxは『ターミナルを部屋分けする技術』です。AIエージェントごとに個室を与えて、お互い邪魔せずに作業してもらいましょう」

実際に話す内容：

画面分割の実演：tmux起動とセッション管理

bash

# セッション作成と命名
tmux new-session -d -s ai-development
tmux new-window -t ai-development -n "claude-code"
tmux new-window -t ai-development -n "gemini-cli" 
tmux new-window -t ai-development -n "cline-output"

実演：各ウィンドウで異なるAIタスクを実行
- Window1: Claude Codeでバックエンド開発
- Window2: gemini-cliでドキュメント生成
- Window3: Clineの出力監視
「3つのAIが同時に働いて、あなたは指揮者として全体をコントロール」
ログ管理の工夫：

bash

# 各AIの作業ログを自動保存
claude code 2>&1 | tee claude-$(date +%Y%m%d_%H%M%S).log

プロセス間の情報共有：「AIが生成したファイルを別のAIがレビューする流れ」

40-45分：効率化のためのワークフロー設計

キラーフレーズ： 「最適化の順番を間違えないでください。まず『何をやるか』を決めて、次に『どれを並列化できるか』を考える。技術先行は失敗の元です」

実際に話す内容：

ワークフロー設計の思考法：
1. タスクの依存関係を洗い出し
2. 並列化可能な部分を特定
3. ボトルネックを見つける
4. 適切なツールを選択
実例：Webアプリ開発の並列化戦略
- 「API開発」「フロントエンド開発」「テスト作成」を同時進行
- 各担当AIの役割分担と成果物の統合方法
生産性測定指標：
- 作業時間の短縮率
- コード品質の維持度
- エラー発生率の変化
「数字で効果を証明できないと、客先や上司を説得できません」

M11: バックグラウンドエージェント（45分）

0-15分：Devinの特徴と活用場面

自律的なタスク実行能力の理解
**デモ：**複雑な問題解決のアプローチ
人間との協調パターン
適用可能なタスクの見極め

15-30分：Cursorの統合開発体験

**デモ：**AIペアプログラミングの実践
リアルタイムコード提案の活用
プロジェクト全体の文脈理解
**実演：**実際の開発フロー

30-45分：ツールの使い分け戦略

タスクの複雑さに応じた選択基準
チーム開発での役割分担
ROI測定と効果検証
将来性と投資判断

M12: 統合演習（60分）

0-10分：演習課題の設定

課題：「ユーザー登録・認証機能付きTodoアプリ」
要件定義と制約条件
使用技術スタックの選定
品質基準と完成度の定義

10-50分：実践開発

**Phase1：**Plan作成と設計検討（10分）
**Phase2：**環境構築とベース実装（15分）
**Phase3：**機能実装とテスト（15分）
**Phase4：**リファクタリングと品質向上（10分）
各Phaseで学んだ技術の統合活用
作業ログとgit管理の実践

50-60分：振り返りと改善点

実際に作成したアプリケーションの評価
使用したツールの効果測定
改善できる点と今後の学習計画
現場導入に向けた段階的計画

補足：各モジュール共通の構成要素

学習支援ツール

**チートシート：**各モジュールの重要ポイント要約
**トラブルシューティング集：**よくある問題と解決法
**実践テンプレート：**すぐに使える設定ファイルやコード例

段階的習得支援

**必須レベル：**最低限覚えるべき内容
**推奨レベル：**業務効率化に直結する内容
**発展レベル：**将来への投資となる内容

現場適用支援

**即座適用：**明日から使える技術
**1週間後：**慣れてから導入する技術
**1ヶ月後：**チーム全体に展開する技術

Content is user-generated and unverified.

Vibe Coding研修 詳細タイムテーブル

M1: 導入とマインドセット転換（30分）

0-5分：問題提起

5-15分：Vibe Codingの本質

15-25分：セキュリティ懸念の正しい対処法

25-30分：研修全体の学習戦略

M2: 基本環境構築（45分）

0-5分：ツール選定戦略

5-20分：gemini-cli環境構築

20-35分：Claude Code環境構築

35-45分：Cline (VS Code) 環境構築

M3: 初回体験（30分）

0-10分：安全な初回タスクの選び方

10-20分：実際の操作体験

20-30分：トラブルシューティング

M4: 作業ログとgit連携（45分）

0-10分：なぜ作業ログが重要なのか

10-25分：効果的な作業ログの書き方

25-40分：git連携による履歴管理

40-45分：チーム共有とレビュープロセス

M5: よくある失敗とRule設計（60分）

0-15分：テスト時ハードコーディング問題

15-30分：セキュリティホールの作り込み

30-45分：パフォーマンス無視とアーキテクチャ破綻

45-60分：.clinerulesファイルの作成

M6: 制御されたPlan/Actプロセス（45分）

0-10分：「いきなり書かせる」危険性

10-25分：Planモードの効果的活用

25-40分：Actモードでの実装と制御

40-45分：Memory Bankとの連携

M7: 実用ユースケース①（コードレビュー）（30分）

0-10分：AIコードレビューの可能性

10-25分：実践的なコードレビュー

25-30分：レビュー結果の活用戦略

M8: 実用ユースケース②（コミット文・リファクタ）（30分）

0-15分：自動コミットメッセージ作成

15-30分：AI支援リファクタリング

M9: MCP環境構築（60分）

0-15分：MCPの基本概念

15-35分：基本的なMCPサーバー構築

35-55分：カスタムMCPサーバーの作成

55-60分：運用時の注意点

M10: Advanced技術（45分）

0-20分：Git Worktreeによる並行開発

20-40分：ターミナルでの複数プロセス並行実行

40-45分：効率化のためのワークフロー設計

M11: バックグラウンドエージェント（45分）

0-15分：Devinの特徴と活用場面

15-30分：Cursorの統合開発体験

30-45分：ツールの使い分け戦略

M12: 統合演習（60分）

0-10分：演習課題の設定

10-50分：実践開発

50-60分：振り返りと改善点

補足：各モジュール共通の構成要素

学習支援ツール

段階的習得支援

現場適用支援

Vibe Coding研修詳細タイムテーブル