新しく人が入るたびに、同じ説明を繰り返していませんか？
手順書やマニュアルが既に用意されていても「これ読んでおいて」で終わってしまい、新人がちゃんと読んだのか、もしくは読んで理解できたのかは分かりません。確認テストを付ければいいのは分かっているけれど、そのために時間を割く余裕は残念ながらない。
このマニュアルを投げたら、自動でeラーニング教材にしてくれたらいいのに。
そんな夢みたいな話があったら嬉しいですよね。実は、ClaudeCodeを使えば簡単にそれができちゃうんです。
今回はClaudeCodeで作成した、テキストのマニュアルを自動でeラーニングにしてくれる「教材ジェネレーター」をご紹介します。
作ったツールについて
今回作ったのは、Markdownファイルを1本渡すと、ブラウザで動く学習教材（静的HTML一式）が出てくるマルチエージェントです。
名前が分かりづらいので以降は「教材ジェネレーター」と呼びましょう。
例えば、私が使うときの指示はこれだけです。
教材ジェネレーターを起動して。/create-kyozai docs/ClaudeCode入門.md上記のパスは、eラーニング教材にしてほしいマニュアルになります。これはどんなドキュメントファイルでも実施可能です。
実際に出来たeラーニング教材がこれです。
教材のダウンロードは下記から実施可能です。
出てくるのは index.html を含む一式で、ダブルクリックすれば開きます。外部との通信は一切ありません。
ファイル内容は以下です。
| 項目 | 結果 |
|---|---|
| 入力 | Markdown 97,410字（115セクションに分割された） |
| 出力 | 5章・全32問・配点合計100点 |
| かかった時間 | 45分 |
| 人間がやったこと | 指示1行と、検品結果を見ての判断だけ |
eラーニング教材の何が良いのか
紙のマニュアルとの違いは、読ませて終わりにしないことです。教材の中身を分解すると、だいたい次の4つになります。
- 学習目標 — この章を終えたら何ができるようになるか
- 本文（資料） — 1画面あたりの分量が決まっている。マニュアルの丸写しでは成立しない
- 確認テスト — 章末に数問
- 合格基準 — 何割正解で修了とするか
上記のように読ませるだけでなく、合格基準まで設けることで新人メンバーがどこまで理解したのかを把握できるようになります。
6種類の設問形式
今回作ったものは、次の6形式に対応しています。
| 形式 | 内容 | 使いどころ |
|---|---|---|
| 選択 | 4択から1つ | 事実の確認 |
| 複数選択 | 当てはまるものをすべて | 網羅性の確認 |
| 並べ替え | 手順を正しい順に | 段階・順序 |
| 分類 | 項目を軸に沿って振り分ける | 種類分け、指標との対応 |
| 穴埋め | 用語を入力する | 用語の確認 |
| 記述 | 文章で答える | 判断・言語化 |
自動採点、進捗の保存（途中でブラウザを閉じても再開できる）、到達度の判定まで入っています。記述式だけは自動採点ができないので、模範解答とチェックポイントを見ながらの自己採点方式です。
便利なのは「記録が残る」こと
一番の変化は、理解したかどうかが記録に残ることでした。これまでのようにマニュアルを渡すだけでは読んだかどうかも分かりませんが、テストの点数は残ります。
そのほかにも、説明する人によって品質がブレない、一度作れば何人でも受講できる、手順が変わったときに直すのが一箇所で済む、日程調整が要らない、といった効果があります。
また、自分が知らない領域の勉強するときも、ブログ記事などのまとまった情報をそのまま入れるだけでeラーニング教材ができるので、資格試験などの自己学習にも活用できます。
エージェントの構成
実際のファイル
今回のツールは下記のファイルをClaudeCodeに読み込ませれば使うことができます。
kyozai-generator_portableダウンロード
処理の流れ
全体は5つの工程に分かれています。
| # | 工程 | 担当 |
|---|---|---|
| 1 | 取り込み（mdをセクションに分割） | スクリプト |
| 2 | 章立ての設計 | AI（1体） |
| 3 | 作問 | AI（章ごとに並列） |
| 4 | 組み立て・検証 | スクリプト |
| 5 | 検品 | AI（1体） |
ポイントは、AIとスクリプトの担当がはっきり分かれていることです。機械にできることは全部スクリプト側に寄せてあります。
コストを決めた3つの設計判断
作ってみて分かったのは、マルチエージェントは組み方次第で簡単に高くつくということでした。今回、次の3つを守っています。
判断1：完成データをAIに書かせない
最終的な教材データは330KBほどになりますが、これをAIに書かせていません。AIが書くのは章ごとの設問データだけで、それをつなぎ合わせて完成品にする作業はスクリプトがやります。
理由は単純で、AIに最終ファイルを出力させると、同じ内容のトークンを二重に払うことになるからです。設問を考えるときに1回、それを完成形に書き出すときにもう1回。後者は機械の仕事です。
判断2：並列にするのは作問だけ
章ごとの作問は、章の数だけ同時に走らせています。一方で、章立ての設計は絶対に分担させません。
章立てを決めるには文書全体を読む必要があります。これを複数のエージェントに分担させると、全文が人数分コピーされることになり、逆に高くつきます。速くもなりません。
サブエージェントは起動するだけで1体あたり1万トークンほどかかります。安易に増やすものではない、というのが実感です。実際、章が2つ以下なら分担させないほうが安く済みます。
判断3：各エージェントには担当範囲だけ渡す
作問を担当するエージェントには、資料の全文を渡していません。渡すのは次の3つだけです。
- 担当する章の設計情報（タイトル、ねらい、配点）
- その章が扱うセクションだけを抜き出した本文
- 書き出し先のパス
「全部読ませたほうが良い問題ができるのでは」と思いがちですが、章をまたいだ内容は問わない方針なので、渡す必要がありません。渡せばそのぶん請求されるだけです。
エージェントは2体だけ
役割を持たせたエージェントは2体です。
- 作問担当 — 章ごとの設問を作る。並列で起動される
- 検品担当 — できた設問の内容をチェックする
検品担当には、読み取りの権限しか渡していません。 ファイルを書き換えられないようにしたうえで、「ファイルの修正は行わないでください。報告だけがあなたの仕事です」と明記しています。
書く人とチェックする人を分けるためです。同じにすると、自分の書いた文章には甘くなります。
検品担当が見るのは内容だけです。配点の合計が100点になっているか、必須項目が埋まっているかといった形式面は、その前にスクリプトが検証を済ませています。機械で判定できることを、AIに確認させない。 これも効きました。
検品担当の最優先チェック項目は「原文に根拠が見つからない正解、または原文と矛盾する正解」です。ここが最も起きやすい事故だと分かっていたので、最初に見るよう指定しています。
フォルダ構成
kyozai-generator\
├─ .claude\
│ ├─ skills\create-kyozai\
│ │ ├─ SKILL.md 全体の手順書
│ │ └─ references\
│ │ ├─ course-schema.md 設問6形式の正確な仕様
│ │ └─ question-design.md 良い設問の作り方
│ └─ agents\
│ ├─ kyozai-writer.md 章ごとの作問（並列起動）
│ └─ kyozai-reviewer.md 内容面の検品
├─ template\ 教材ごとに変わらない共通部分
│ ├─ index.html
│ └─ assets\css\style.css, js\app.js
├─ scripts\
│ ├─ lib.ps1 共通処理（Markdown変換・データ出力・検証）
│ ├─ ingest-md.ps1 md → セクション分割
│ ├─ assemble.ps1 設問データ → 教材データ＋テンプレート配置
│ └─ validate.ps1 出力済みデータの単体検証
├─ work\<教材名>\ 途中の生成物（消してよい）
└─ output\<教材名>\ 完成品教材ごとに変わるのはデータと画像だけで、見た目と動きの部分は全教材で共通です。UIを直したいときは共通部分を直せば、以降作る教材すべてに反映されます。
もうひとつ、途中の生成物をすべてファイルに書き出しているのも意図的です。3章の設問だけ作り直す、といったことができます。全部を作り直さずに済むのは、時間の面でもコストの面でも大きいです。
かかる時間とトークン消費量
時間
9万字の資料を流したときの実際の記録です。
| 時刻 | 内容 |
|---|---|
| 15:24 | 取り込み完了（115セクションに分割） |
| 15:25 | 章立ての設計完了（5章、配点100点の割り振りまで） |
| 15:28〜15:37 | 作問（5章を並列。最も早い章で3分、最後の章で12分） |
| 16:09 | 組み立て・検品・修正まで完了 |
合計45分です。このうち人間がやったのは、最初の指示1行と、検品の指摘を見て直すかどうかを決めたことだけでした。
章立ての設計が1分で終わっているのが個人的には驚きで、9万字を読んで5章に束ね、各章に何点を割り振るかまで決まっています。ここを人間がやると、たぶん半日かかります。
トークン消費量（見積もり）
ここは実測値ではなく見積もりです。手順書のなかに「本文1万字あたり13〜15万トークン程度」という目安を書いてあり、それに当てはめると次のようになります。
97,410字 → およそ130万〜150万トークン
工程ごとのおおまかな内訳（これも見積もりです）。
| 工程 | 見積もり | 理由 |
|---|---|---|
| 取り込み | 0 | スクリプトだけで完結 |
| 章立ての設計 | 20〜30万 | 全セクションを読む必要がある |
| 作問（5体並列） | 50〜75万 | 1体あたり起動＋仕様書＋担当本文 |
| 組み立て | 0 | スクリプトだけ |
| 検品 | 20〜30万 | 原文と全設問を突き合わせる |
| 修正・再組み立て | 10〜20万 | 指摘の数による |
注意したいのは、文書量に対して線形以上に効くことです。倍の長さの資料を入れると、消費は倍では済みません。
エージェント自身に見積もらせる
トークンの消費量が不安なので、手順の最初に「事前見積もり」の工程を入れています。
処理を始める前に入力ファイルの文字数を数えさせ、2万字を超えていたら着手前にユーザーへ確認するようにしています。おおよその消費量と、「章を絞る」「対象範囲を限定する」といった代替案を1〜2行で伝えて、了承を得てから進む、という流れです。
コストの話を「気をつけましょう」で終わらせず、確認する工程として組み込んでおくほうが確実でした。9万字を何も考えずに投げて、あとから請求を見て青くなる、という事故を防げます。
先に挙げた3つの設計判断も、突き詰めればすべてトークン対策です。加えて細かい話ですが、途中のデータファイルで日本語が \uXXXX の形式にエスケープされないようにもしています。人にもAIにも読めなくなるうえ、トークンが数倍に膨らむからです。
注意点
実際に使ってみて分かった、気をつけるべき点をまとめます。
元のドキュメントの正確さ以上にはならない
当たり前の話ですが、古い手順書からは古い教材ができます。教材にする前に、元の資料が最新かどうかを確認してください。
事実確認は最後は人間の仕事
検品担当のエージェントを1体置いていますが、それでも最終確認は人間がやるべきです。特に危ないのは、原文に書いていない「一般論としては正しそうな補足」が混ざるパターンです。数字・固有名詞・手順の順番は重点的に見てください。
入力はMarkdownだけ
PDFやPowerPointを教材にしたい場合は、先にMarkdownへ変換する必要があります。また、見出しが2つ以上ないと、内容のまとまりではなく単純な文字数で分割されてしまいます。
図やスクリーンショットは自動化しにくい
画像は人間の担当として切り分けたほうが現実的です。
社外秘の資料を扱うなら、送信先を先に確認する
これは教材づくりに限らない話ですが、業務資料を投げる前に確認してください。
配るときはフォルダごと渡す
これは実際にやりかけた失敗です。index.html だけを渡すと、見た目や動きのファイルが付いてこないため、相手のパソコンで真っ白な画面が開きます。フォルダごとコピーするか、zipで渡してください。生成時に配布用のzipも一緒に作るようにしました。
出てくるのは完成品ではなく、たたき台
そのまま配れる完璧な教材が出てくるわけではありません。ただ、白紙から作るのとは別物です。1か月かかっていたものが45分になったうえで、手直しの時間を足しても、比較になりません。
どんなプロンプトで作ったか
先に1つ、手で作らせる
私は最初からエージェントを作ろうとしませんでした。まず、普通に教材を1つ作らせています。実際に打った指示がこれです。
これからWEBマーケティングの教材を作りたい。HTML/CSS/JavaScriptを使って、クイズを能動的に解くような感じにしたい。今まで作成したテキスト資料と画像ファイルを使ってローカルファイルで開ける形式にして
言っているのは完成物の姿だけで、作り方は一切指示していません。内容を整理すると、伝えているのは次の5点です。
- 何の教材か（WEBマーケティング）
- どんな技術で作るか（HTML/CSS/JavaScript）
- どんな体験にしたいか（クイズを能動的に解く）
- 手元に何があるか（既存のテキスト資料と画像ファイル）
- どう動いてほしいか（ローカルファイルで開ける）
この5つだけで、教材が1つできあがりました。
そのあとの一言
できあがった教材を見てから、こう言いました。
今回のように、mdを読み込ませれば、同じ形式でeラーニング教材を自動生成するエージェントがほしい
これだけです。結果として、mdを投入すれば簡易WEB教材を自動生成するエージェントができました。
エージェントを先に設計しようとしないほうがいい、というのが今回得た一番の教訓です。
先にエージェントから作ろうとすると、「良い教材とは何か」を言葉で定義する作業から始めることになります。1画面の分量は、設問は何問、選択肢の作り方は……と、決めなければいけないことが延々と出てきます。実物が1つあれば、「これと同じものを」で済みます。 できあがった教材そのものが仕様書の代わりになるからです。
手で作る1回は無駄になりません。それが仕様書になります。
日常的に使う指示は、短くする
完成後に使うときの指示は /create-kyozai <ファイル> の1行か、「このmdを教材にして」だけです。
毎回長いプロンプトを書かないと動かないものは、結局使わなくなります。使うときの指示をどれだけ短くできるかは、作る段階で意識しておく価値があったと考えています。
まとめ
- 教材づくりで重いのは本文ではなく、章立て・設問・整形。
- サンプル教材とツール一式はダウンロードして試せる。ClaudeCodeに読み込ませればすぐ動かせる
- マニュアルだけでなく、資格試験の勉強など自己学習用にも応用できる
- 日常的に使う指示は1行に収める。長いと使わなくなる
- AIに書かせるのは設問データだけ。整形・検証はスクリプトに寄せる
- 並列にするのは作問だけ。 全体を読む工程を分担させると、全文が人数分コピーされて高くつく
- 各エージェントには担当範囲だけ渡す
- 書く人とチェックする人を分ける。検品担当には書き込みの権限を渡さない
- 機械で判定できることを、AIに確認させない
- 途中の生成物をファイルに書き出すと、一部の工程だけやり直せる
- 長い文書はトークンが線形以上に効く。エージェント自身に事前見積もりをさせる
- エージェントを先に設計しない。1回手で作って、「同じものを自動生成して」と言う。 実物が仕様書になる
eラーニング教材をゼロから作る場合、過去に同じWEB教材を手作業でコーディングしていれば1か月以上かかっていました。ClaudeCodeを使えばたったの45分で、しかも自分が手を放している隙にどんどん進めてくれるので、とても助かりますね。皆さんもぜひ試してみてください。
