はじめに
読書感想文のコーチングSKILLは、Agent Skillの設計に必要な「タスク分解」「対話制御」「状態管理」「コンテキスト管理」「品質評価」「人間とAIの責務分離」「ユーザー体験設計」を、小さな題材で一通り経験できるため、習作として非常に適しています。
特に重要なのは、読書感想文がAIに完成品を書かせることは容易だが、本人が考えて書けるように支援することは難しいという性質を持つ点です。
これは、実際のソフトウェア開発におけるAIエージェントの設計課題と共通しています。
1. Agent Skillの主要な設計課題を学べる
| 学習テーマ | 読書感想文コーチングでの実践 | 実務への応用 |
|---|---|---|
| タスク分解 | 読書体験の整理→問いかけ→構成→執筆→推敲 | 設計→実装→テストの工程分解 |
| 対話制御 | 回答内容に応じて次の質問を変える | 要件ヒアリング・設計支援 |
| 状態管理 | 既に聞いた内容、未整理の論点を保持 | 長時間タスクの進捗管理 |
| コンテキスト管理 | 本の情報、本人の感想、文章を区別 | 仕様・実装・検証結果の管理 |
| 責務分離 | AIは質問と助言、本人は判断と執筆 | Human-in-the-loop |
| 品質評価 | 感想の具体性、論理のつながりを確認 | レビュー・テスト・品質ゲート |
| 例外処理 | 本を読んでいない、感想が浮かばない | 入力不足・工程失敗からの復旧 |
| 再利用性 | 本や学年が変わっても同じSkillを使う | 汎用Agent Skillの設計 |
| ユーザー体験設計 | 学年・利用者の役割・習熟度に応じた支援方法の切り替え | ペルソナ設計・利用シナリオ設計・UX最適化 |
この題材の利点は、個々の設計課題を独立して学べるだけでなく、それらの関係を理解できることです。
例えば、学年に応じて質問を変えるには、利用者の属性を把握する必要があります。回答内容に応じて質問を変えるには、対話の状態を管理する必要があります。適切な質問だったかを確認するには、評価基準が必要になります。
つまり、一つのユーザー体験を成立させるために、Agent Skillの複数の設計要素が連携することを学べます。
2. 最も大きな学習効果は「AIに何をさせないか」の設計
通常の文章生成SKILLなら、入力された書籍情報をもとに読書感想文を生成すれば完了します。
しかし、コーチングSKILLでは、それを行ってはいけません。
- AIが感想を勝手に作らない
- 本人が考える前に模範解答を提示しない
- 本人の経験や感情を捏造しない
- 一度に大量の質問を投げない
- AI自身の解釈を正解として押し付けない
つまり、生成能力を最大化するのではなく、利用者の思考を最大化するようにAgentの行動を制約する設計が必要です。
例えば、子どもが「主人公がすごいと思った」と回答した場合、AIが「主人公の勇気と友情に感動したのですね」と解釈を補完してしまうと、本人の考えを誘導することになります。
この場合は「主人公のどんなところがすごいと思った？」と問いかけ、本人自身の言葉を引き出すことが適切です。
実務でも同様です。設計支援Agentが勝手に仕様を決定したり、レビューAgentが根拠のない修正を実施したりしては困ります。
Agent Skillの設計では、何を実行させるかだけでなく、何を実行させず、どの判断を人間に残すかを明確にする必要があります。
3. 状態遷移を伴うAgent設計を体験できる
読書感想文の作成は、複数の工程に分解できます。
- 読書体験を聞く：印象に残った場面を引き出す
- 感想を深掘りする：なぜそう感じたのかを問う
- 論点を整理する：書きたい主題を本人が選ぶ
- 文章を組み立てる：本人が下書きを作成する
- 振り返り・推敲：根拠・具体性・一貫性を確認する
このように工程を分解すると、単なるプロンプトではなく、状態を持ったワークフローとして設計できます。
例えば「印象に残った場面」が具体的になるまでは次の工程に進まない。ただし答えられなければ質問を変えたり、選択肢を示したりする。
また、文章を書いている途中で、主題がはっきりしていないことに気づく場合もあります。その際には、前の工程に戻って考えを整理する必要があります。
正常系だけでなく、停滞・後戻り・再開まで設計することがAgent Skillの理解につながります。
4. 品質評価の難しさを体験できる
読書感想文には、単一の正解がありません。しかし、品質を評価する観点は存在します。
例えば、以下のようなルーブリックを設計できます。
| 評価観点 | 確認すること |
|---|---|
| 主体性 | 本人自身の考えが表現されているか |
| 具体性 | 作中の場面を根拠にしているか |
| 深掘り | 「面白かった」で終わっていないか |
| 一貫性 | 主張と理由がつながっているか |
| 独自性 | 本人の経験や価値観と結びついているか |
さらに、成果物の品質とコーチングの品質を分けて評価できます。
- 成果物評価：完成した読書感想文は良い文章か。
- プロセス評価：AIが答えを与えず、本人の思考を引き出せたか。
例えば、完成した文章の品質が高くても、AIが文章の大部分を生成していた場合、コーチングとしては成功とはいえません。
反対に、文章の表現が未熟であっても、本人が自分の経験や考えを整理し、自分の言葉で書けるようになったのであれば、コーチングとして一定の成果があります。
これは、ソフトウェア開発において「生成されたコードが正しいか」と「Agentが適切な手順・権限・根拠で生成したか」を分けて評価する考え方につながります。
5. 利用者の違いを踏まえたユーザー体験設計を学べる
読書感想文のコーチングSKILLには、もう一つ重要な設計課題があります。それは、同じ目的を持つSkillでも、利用者によって適切な体験が異なることです。
5.1 学年によって必要な支援が異なる
読書感想文を書く本人の学年によって、理解力、語彙力、文章構成力、必要な支援は異なります。
例えば、同じ「主人公の行動について考える」という目的でも、質問の仕方は異なります。
| 対象 | 質問例 |
|---|---|
| 小学校低学年 | 主人公のどんなところが好きだった？ |
| 小学校高学年 | 主人公はどうしてその行動をしたと思う？ |
| 中学生 | 主人公の行動には、どのような考え方が表れていると思う？ |
| 高校生以上 | 主人公の選択を、作品全体の主題と関連づけてどう解釈できる？ |
同じ学年でも、読書経験や文章を書くことへの習熟度には違いがあります。そのため、最初に学年を把握したうえで、実際の回答内容に応じて質問の難易度を調整する必要があります。
5.2 Skillの利用者と感想文を書く本人は同じとは限らない
Skillを操作するユーザーと、実際に感想文を書く人が同一とは限りません。
例えば、次のような利用形態が考えられます。
| 利用者 | 利用目的 | Skillに期待する体験 |
|---|---|---|
| 児童・生徒本人 | 自分の感想文を書きたい | 対話を通じて考えを整理し、自分の言葉で書ける |
| 保護者 | 子どもの感想文作成を手伝いたい | 子どもへの問いかけ方や適切な助言を知ることができる |
| 教師 | 児童・生徒の文章作成を指導したい | 学年や習熟度に応じた指導方法、評価観点を得られる |
ここでは、単に回答の難易度を変えるだけでは不十分です。
本人が利用する場合は、AIが直接質問を投げかける対話型の体験が適しています。
一方、保護者が利用する場合は、AIが保護者に問いかけ方を提案し、保護者が子どもとの対話を進める体験が必要です。
教師の場合は、個々の感想文への支援だけでなく、授業での利用方法や評価基準の提示も求められます。
つまり、誰が操作し、誰を支援し、誰が最終的な成果物を作るのかを区別する必要があります。
5.3 初期対話そのものを設計する必要がある
利用者に適切な体験を提供するためには、Skillの起動直後に必要な情報を把握する必要があります。
例えば、最初の質問を次のように設計できます。
読書感想文のお手伝いをします。今回はどの立場で使いますか？
- 自分で読書感想文を書きたい
- 子どもの読書感想文を手伝いたい
- 児童・生徒への指導に使いたい
その後、利用者の役割に応じて学年や困っていることを確認します。
ただし、最初からすべての情報を入力させる必要はありません。
利用者がすでに「小学3年生の子どもが、感想文の書き出しで困っています」と説明しているのであれば、学年や利用目的を改めて質問する必要はありません。
利用者がすでに伝えた情報を活用し、不足している情報だけを必要なタイミングで確認することも、重要なユーザー体験設計です。
5.4 ユーザー体験設計から学べること
この題材から、Agent Skillのユーザー体験設計として、次のことを学べます。
- ペルソナ設計：誰がSkillを利用するのかを定義する。
- 利用シナリオ設計：どのような場面で、何を達成するために利用するのかを整理する。
- 初期対話設計：学年、利用者の役割、困っていることを必要最小限の質問で把握する。
- 適応的な対話設計：利用者の回答や習熟度に応じて、質問の難易度・内容・進め方を変更する。
- 操作負荷の最小化：利用者にSkillの内部構造や工程を意識させず、自然な対話で目的を達成できるようにする。
特に重要なのは、内部のワークフローを標準化しながら、外部に提供するユーザー体験を利用者に合わせて変えるという設計です。
これは実務においても、同じAIエージェントを開発者、レビュー担当者、プロジェクトマネージャーなど、異なる役割の利用者に提供する際に共通する課題です。
6. Skillのファイル分割も自然に学べる
習作としては、最初から複雑にせず、次の構成を推奨します。
reading-review-coach/
├── SKILL.md # Skillの目的・起動条件・基本ルール・参照先
├── README.md # Skillの概要・導入方法・使い方
├── references/
│ ├── user-experience.md # ペルソナ・利用シナリオ・役割別の体験設計
│ ├── coaching-flow.md # コーチングの工程・状態遷移・完了条件
│ ├── question-patterns.md # 思考を引き出す質問例・回答別の対応方法
│ └── evaluation-rubric.md # 感想文とコーチングの品質評価基準
└── examples/
└── sample-session.md # 利用者とAIの対話例・期待される振る舞い
SKILL.mdには、Skillの役割、起動条件、基本的な制約、参照先を定義します。
詳細な仕様は、責務ごとにファイルを分割します。
-
user-experience.md：利用者の種類、利用シナリオ、初期対話、役割別の支援方法を定義する。 -
coaching-flow.md：コーチングの工程、状態遷移、後戻り、完了条件を定義する。 -
question-patterns.md：質問のパターン、深掘り方法、回答に困った場合の対応を定義する。 -
evaluation-rubric.md：感想文とコーチングの品質評価基準を定義する。 -
sample-session.md：具体的な対話例を通じて、期待するAgentの振る舞いを示す。
ここで重要なのは、すべての指示をSKILL.mdに詰め込まないことです。
SKILL.mdを薄く保ち、必要な情報を適切なタイミングで参照する構成にすれば、Skillの保守性と再利用性が高まります。
また、ユーザー体験設計とコーチングの進行制御を分離することで、対象者が増えた場合も既存のワークフローを再利用しやすくなります。
これによって、何をするSkillなのか、誰にどのような体験を提供するのか、どう実行するのか、何をもって成功とするのかを独立して設計する習慣が身につきます。
7. 習作としての完成条件
単にSkillが動いたことを成功条件にするべきではありません。
次の5つが満たされた時点で、習作は完成と判断できます。
- 異なる書籍・利用者でも、同じSkillから対話を開始できる
- 利用者の回答に応じて、質問や工程を適切に変更できる
- AIが本人の感想を捏造せず、本人主体の文章作成を支援できる
- 対話ログと完成文章を、定義済みの評価基準で検証できる
- 学年や利用者の役割（本人・保護者・教師）に応じて、対話の内容、難易度、支援方法を切り替えられる
これらを検証するためには、異なる利用シナリオでSkillを試すことが有効です。
例えば、小学校低学年の本人が利用する場合、保護者が子どもを支援する場合、中学生が自分で感想文を書く場合など、複数のシナリオで動作を確認します。
また、利用者が回答に困った場合や途中で話題が変わった場合など、想定どおりに進まないケースも試す必要があります。
重要なのは、期待どおりの文章が生成されることだけでなく、期待どおりの支援プロセスが再現されることです。
まとめ
読書感想文のコーチングは、文章を生成するという簡単なタスクを、人間の思考を支援するという難しいタスクに意図的に変換したものです。
そのため、LLMへの指示文を書くだけでは解決できず、ワークフロー、状態、責務、評価、例外処理、ユーザー体験を考える必要があります。
さらに、学年や利用者の役割によって適切な支援方法が変わるため、同じSkillで複数の利用シナリオに対応する設計も学べます。
しかも、題材自体には専門的な開発環境も外部APIも必要ありません。Agent Skillの設計そのものに集中できることが、習作としての最大の利点です。
加えて、最初は単一のSKILL.mdだけで実現し、その後に状態管理、評価基準、ユーザー体験設計を追加していけば、プロンプトとAgent Skillの違いを段階的に体験できる教材にもなります。
Agent Skillを作ることは、単にLLMへ指示を与えることではありません。目的を達成するために、AIと人間の役割、行動の順序、判断基準、利用者の体験を設計することです。
読書感想文のコーチングSKILLは、その本質を小さな題材で学べる実践的な教材です。