AS部DS4課の越後です。
今回は、Claude Code上で3つのAIエージェントを組み合わせて、研修課題の「作成→実行→レビュー」を自動化した話を書きます。
この記事のポイント
- 課題作成者・トレーニー・トレーナーの3エージェントで研修課題を設計した
- AIに「初心者役」を演じさせることで、受講者が躓くポイントを事前に洗い出せた
- 最終的に「AIに聞きながら進める」前提の課題設計に転換し、手順書のスリム化にも成功した
背景：研修課題の設計、どうやって品質を担保する？
社内のタスクフォースで、ある技術領域の研修課題を作ることになりました。ステップバイステップで小さなWebアプリを構築していく形式の、全8ステップの課題です。
ここで問題になるのが、「この課題、初心者にとって本当にちょうどいい難易度なのか？」 ということです。
課題を作る側はすでにその技術を知っているので、初心者がどこで躓くかを正確に予測するのが難しい。ヒントが足りなくて詰まるのも困るし、手順を書きすぎて「写経」になるのも困る。
理想を言えば、課題を作ったらパイロット受講者に解いてもらい、フィードバックを受けて改善するサイクルを回したい。でも人間のパイロット受講者はいつでも捕まるわけではないし、フィードバックサイクルにも時間がかかる。
そこで考えたのが、Claude Codeのサブエージェント機能を使って「初心者役のAI」に課題を解かせ、躓きポイントを洗い出すというアプローチでした。
3 Agent アーキテクチャの設計
このシステムは3つの役割を持つエージェントで構成されます。
sequenceDiagram
participant C as 課題作成者
participant T as トレーニー
participant R as トレーナー
C->>C: ステップの課題指示を作成
C->>T: 課題指示を渡して実行を依頼
T->>T: 隔離環境で課題を実行
T-->>C: 成果物 + 説明 + 躓き報告
C->>R: 成果物のレビューを依頼
R->>R: 品質・理解度を評価
R-->>C: レビュー結果 + 課題への改善提言
C->>C: 観察結果を記録し、課題仕様を改善
課題作成者（Assignment Creator）
全体を統括するメインのエージェントです。各ステップの課題指示を作成し、トレーニーとトレーナーの結果を見て課題を改善します。スコープ・難易度・完了条件・ヒント量の判断権限を持ちます。
トレーニー（Trainee）
「初心者」として課題を解くサブエージェントです。課題指示に従って実装し、躓いたポイントや分からなかった概念を報告します。Git worktreeで隔離された環境で作業するので、メインのコードベースを汚しません。
トレーナー（Trainer）
シニアエンジニアの視点でレビューするサブエージェントです。トレーニーの成果物を評価するだけでなく、課題作成者への改善提言（「ここにヒントを追加すべき」「この完了条件では不十分」など）も行います。
1ステップのサイクル
各ステップは以下のサイクルで回します。
flowchart LR
A[課題作成者が<br/>課題指示を作成] --> B[トレーニーが<br/>課題を実行]
B --> C[トレーナーが<br/>レビュー]
C --> D{合格？}
D -->|不合格| B
D -->|合格| E[課題作成者が<br/>観察結果を記録し<br/>課題を改善]
E --> F[次のステップへ]
重要な制約として、各ステップは最大2イテレーションとしました。2回で収束しない場合は課題作成者が判断して次に進みます。これがないと無限に改善ループが回り続けてしまいます。
実装のポイント
エージェント間通信はファイルベース
特別なプロトコルは不要です。トレーニーが書いたコードと説明テキストをトレーナーが読み取ってレビューする、というシンプルなファイルベースの連携です。Claude Codeのサブエージェント機能がそのまま使えます。
トレーニーの隔離
トレーニーはGitのworktree機能で隔離された作業環境を使います。各ステップごとにブランチを切り、前のステップの成果をベースに段階的に機能を積み上げます。ステップが完了したらworktreeは破棄するので、メインブランチがクリーンなまま保たれます。
観察記録の蓄積
各ステップの観察結果（トレーニーの躓き・トレーナーの提言）は、内部ドキュメントとして記録します。最終的な課題仕様書には含めませんが、「なぜこのヒントを追加したのか」「なぜこの完了条件にしたのか」の根拠として非常に価値があります。
やってみて分かったこと
8ステップ分のサイクルを回した結果、いくつかの興味深い発見がありました。
発見1: AIトレーニーは「何」は分かるが「なぜ」が分からない
環境構築のステップで、トレーニーは各ファイルの「何をしているか」は正確に説明できました。しかし、「なぜそうなっているか」への理解が浅かったのです。
例えば、認証コンポーネントについて「ログインしていないとページが見えない仕組み」と正しく説明しましたが、なぜアプリのルートレイアウトに置くのか（アプリ全体を認証で保護するため）という設計意図には触れていませんでした。
また、自動生成されるファイルを手動で編集してしまうリスクも発見しました。これは実際の初心者もやりそうなミスです。
→ 改善: 「なぜそうなっているか」を問う完了条件の追加、自動生成ファイルへの注記
発見2: 環境起因のエラーは確実に躓く
APIと連携するステップでは、クロスオリジンリクエストのエラー（CORS）で躓くことが分かりました。自分のコードが悪いのか、サーバー側の設定が問題なのか、初心者には切り分けができないのです。
また、HTTPエラー（404や500）をエラーとして検知しない実装をしてしまう盲点も見つかりました。
→ 改善: トラブルシューティングセクションの追加、エラーハンドリングのヒント強化
発見3: 「教科書的に知っていても実践で忘れる」パターンがある
フィルタやソートの実装ステップでは、データの変換パイプライン（フィルター → ソート → 表示）の接続ミスが頻発しました。特に、ソート処理が元のデータを破壊してしまう問題は、概念としては知っていても実装時に忘れがちなパターンです。
→ 改善: ヒントセクションに「よくある落とし穴」として明示的に追加
発見を反映した最終成果物
docs/assignment/ ├── README.md # 課題概要書 ├── steps/ # 各ステップの課題シート ├── templates/ # 受講者の提出テンプレート ├── trainer/ # トレーナー向け資料 │ ├── evaluation-sheet.md # 評価シート │ ├── oral-check-list.md # 口頭確認リスト │ └── answer-keys/ # 各ステップの回答例 ├── learning-map.md # 学習マップ └── internal/ # 観察記録（課題改善の根拠）
「初心者がここで躓くはず」という推測ではなく、「AIトレーニーが実際にここで躓いた」という観察に基づいた課題設計ができた点が、このアプローチの最大の価値です。
AI活用前提の課題設計への転換
3エージェントサイクルで課題を作った後、もう一つ大きな転換がありました。
当初は「手順を全て記載して順番に進める」形式で課題を作りました。しかし、受講者がAIを自由に使える前提なら、要件だけ記載して「AIに聞きながら進める」形式のほうが実務に近いのではないか、と気づいたのです。
具体的には以下の変更を行いました。
- 受講者向け課題シートをスリム化（例: 280行 → 80行）。「何を作るか」は書くが「どう作るか」は書かない
- 削除した手順・コード例はトレーナー用回答例に移動。評価基準として活用
- 「AIの活用ヒント」セクションを追加。質問例を2〜3個提示し、AIに聞きながら進める動線を作る
これは3エージェントサイクルで一度詳細な課題を作り、その上でスリム化するという「膨らませてから削る」プロセスだったからこそできた転換です。いきなりスリムな課題を書こうとすると、何を書いて何を省くべきかの判断が難しいですが、詳細版があれば「これはAIに聞けばわかる」「これはヒントがないと進めない」の仕分けが容易になります。
まとめ
うまくいったこと
- AIトレーニーは「初心者っぽい躓き方」を再現してくれる。環境起因のエラー、設計意図の理解不足、実践での落とし穴など、実際の受講者が遭遇しそうなポイントを事前に洗い出せた
- トレーナーの「課題への改善提言」が具体的なアクションになる。単なるコードレビューではなく「課題としてどう改善すべきか」の視点が得られる
- 観察記録が蓄積されるので、課題の設計判断に根拠が生まれる
注意が必要なこと
- AIトレーニーは「本当の初心者」とは違う。基礎的なプログラミング知識はあるので、「ターミナルの使い方が分からない」レベルの躓きは再現できない
- 収束条件の設定は必須。最大イテレーション数を決めておかないと、延々と改善ループが回り続ける
- ステップ数が多いと管理が煩雑になる。8ステップは回せたが、自動化の余地はまだある
このパターンの汎用性
「作成者・実行者・レビュアー」の3役が存在するワークフローであれば、このパターンは研修課題に限らず応用できます。
- ドキュメントの品質検証: ドキュメント作成 → AIがドキュメント通りに実装 → レビュアーが実装品質を評価
- テストケースの妥当性検証: テスト設計 → AIがテストを実行 → レビュアーがカバレッジを評価
- チュートリアルの検証: チュートリアル作成 → AIが手順通りに実行 → レビュアーが再現性を評価
Claude Codeのサブエージェント機能とGit worktreeの組み合わせは、こうした「複数の視点でのイテレーティブな検証」に適したプラットフォームだと感じました。
