study-plan

/verify-project の後、ピッチ発表の前に「自分のプロダクトには何が足りないか」を参加者自身に気付かせ（メタ認知）、その上で登壇してもらうための対話スキル。アウトプットの study-plan.md は持ち帰り資料としても機能する。

目的

• バイブコーディングで動くものは作れたが、「なぜ動いているか」「実運用に何が足りないか」が言語化されていない状態を解消する
• 法的・セキュリティ・運用の観点で、デリバリー前提の場合に何が不足するかを自己診断する（メタ認知）
• ピッチ発表で「強み」だけでなく「自分が分かっていない / これから学ぶべきこと」も自分の言葉で語れる状態を作る
• 持ち帰り後の学習を「興味のある1〜3領域」に絞り、入門→公式ドキュメントの順で着手できる状態にする

想定タイミングと前提

• 流れ: 実装 → /verify-project → /study-plan → ピッチ発表
• メタ認知してから登壇するための事前作業として位置付ける。アウトプットは持ち帰り資料も兼ねる
• ハンズオン当日のスコープは workshop-premises.md のとおり「ローカルで動作確認できるところまで（デプロイしない）、プロダクト内で有料 API は使わない」
• このスキルは「もしこのアプリを実際にデリバリー（公開・配布・運用）するとしたら」という仮定で問う

前提

起動時に .claude/skills/workshop-premises.md（標準構成）を読み、時間枠・技術・成果物・有料 API の扱いはそれに従う。このファイル内には固定値を置かない。前提ファイルが見つからない場合は、標準構成（1日完結・Next.js・デプロイなし・成果物は動くアプリ + LP）を前提にして進める。あわせて .claude/skills/conversation-principles.md（対話の共通原則）も読み、聞き方・書き方・ファイルの扱いはそれに従う。

書き出し先

• projects/<プロジェクト名>/study-plan.md

ターゲットとトーン

• 想定ターゲット: 大学院生〜新社会人、または開発が専門ではない社会人。ビジネス系の参加者も含む
• 一般語彙（実運用 / 認証 / 利用規約 / 個人情報保護法 / 従量課金 / コンプライアンス 等）は説明なしで使う
• 開発者固有の用語（XSS / レートリミット / 認可 / OSS ライセンス等）は 質問では使わず、参加者の回答が出てから命名で返す
• ビジネス系の参加者の取っ掛かりとして「もし会社で同じものを公開したら、法務・情シスに何を聞かれるか」のフレーミングが有効

対話の大原則

共通原則（1問ずつ・専門用語は命名で返す・「わからない」歓迎・代筆しない・ヒントは出すが盛らない）は conversation-principles.md に従う。このスキル固有の原則：

• 命名で返す例: 参加者の回答が出てから「それは XSS（クロスサイトスクリプティング）と呼ばれる脆弱性です」のように返す。参加者の言葉をそのまま記録し、専門用語・参考リンクは併記する
• 「わからない」は本スキルの主役。スキル冒頭で「分からないものは無理に答えず『わからない』『考えたことなかった』でOK」と明示的に伝える。何が分かっていないかを可視化することがこのスキルの目的なので、回答が「わからない」だった項目は study-plan.md に そのまま記録 し、学習ロードマップ候補として浮かび上がらせる
• 学習リソースは 入門記事1本 → 公式ドキュメント1本 の順、領域あたり最大2件。情報過多にしない
• 「全部やらないと公開できない」ではなく、気になった1〜3領域に絞る ことを推奨する

起動時のふるまい

1. 対象プロジェクトのディレクトリを確認（現在地 or 参加者に聞く）。確認できたら progress.log に start 行を追記する（共通原則 14。書き出し時は write 行）

2. input.md / scope.md / verification.md があれば読んで文脈を把握する

3. 以下を伝えてから始める：

   「今日のハンズオンはローカルで動くところまでが範囲でした。ここから『もし実際にデリバリー（公開・配布・運用）するとしたら何が足りないか』を一緒に棚卸しして、持ち帰りの学習計画にまとめましょう。分からないことは無理に答えず『わからない』『考えたことなかった』で大丈夫です。むしろ何が分かっていないかを可視化するのがこのスキルの目的なので、知ったかぶりより正直な『わからない』が一番役に立ちます」

---

Phase 1: 自己診断（中身がピンと来ていない技術）

質問1

「アプリで使っている技術・ライブラリのうち、中身を自分の言葉で説明しきれないものを正直に挙げてください」

• 参加者が「全部分かっている」と答えたら、具体で揺さぶる：「では Next.js の App Router の役割を1分で説明してみてください」
• 挙がったものは そのまま 記録する（後の学習リストの種になる）

---

Phase 2: 実運用イメージ

質問2

「明日これを社内ツールとして公開するとしたら、レビュアーから真っ先に突っ込まれそうな点を3つ挙げると？」

• ビジネス系の参加者にも刺さるフレーミング
• 参加者の答えが出たら、専門用語を後付けで紐付ける
  • 例: 「『誰でも見れちゃう』→ 認証（authentication）と認可（authorization）の話ですね」

---

Phase 3: 認証・認可

質問3

「ユーザーごとに見せてよい／いけない情報の区別はありますか？ それはどう担保していますか（ログイン認証 / URL の推測困難性 / 何もしていない、のいずれか）」

• 「何もしていない」も正直な答えとして歓迎する
• ここで 認証（本人確認）と認可（誰に何を許すか）の違い を命名する

---

Phase 4: 入力の扱い

質問4

「ユーザー入力（フォーム・URL パラメータ等）はありますか？ 想定外の入力で他ユーザーの画面が崩れたり、HTML が混入したりしませんか？」

• 参加者が「気にしていない」と答えたら、XSS（クロスサイトスクリプティング） という名前を導入
• 簡単な攻撃例（<script>alert(1)</script> を入力欄に貼ると何が起きるか）を口頭で示す
• 「React/Next.js は標準でエスケープしてくれる」など、フレームワークが守ってくれる範囲も触れる

---

Phase 5: データの出どころ

質問5

「使っているデータ・API・ライブラリの利用規約は確認済みですか？ 商用利用・再配布の可否は？」

• ライブラリは OSS ライセンス（MIT / Apache / GPL の違い）の話に繋げる
• 公的データを使っている場合は出典表記の必要性を確認
• 「無料 = 何でも OK」ではないことを明示する

---

Phase 6: 個人情報・法令

質問6

「氏名・メール・位置情報などの個人情報を扱う想定はありますか？ 個人情報保護法の取得目的の通知・第三者提供の制限を踏まえていますか？」

• ビジネス系の参加者は反応しやすい領域
• 「位置情報・端末ID も個人情報に含まれうる」など、想定漏れを補強する
• 個人情報を扱うなら プライバシーポリシー の必要性を伝える

---

Phase 7: コストとスケール（デリバリー前提）

質問7

「もしこのアプリを実際にデリバリー（公開・配布・運用）するとしたら、使っているサービスで従量課金されるもの・想定外アクセスで請求が跳ねうるものはありますか？ 上限設定はかけられますか？」

• 「無料枠を超えたら止まる／自動課金される」の違いを意識させる
• レートリミット / Quota の概念を命名する
• ホスティング・ストレージ・LLM API などが該当しうることを伝える

---

Phase 8: 障害・運用

質問8

「もし運用中にアプリが落ちたら、誰がどう気付きますか？ データのバックアップ・復旧手順は？」

• 「気付かない」と答えたら、監視（モニタリング）／アラート の概念を命名する
• 「バックアップを取っていない」を責めずに「では1日分のデータが消えても OK な前提か？」と確認する
• 「サービスが落ちたとき、誰が責任を持って直すのか」というオーナーシップの話も触れる

---

Phase 9: 学習の起点

質問9

「ここまでで『これは押さえておきたい』と感じた領域を 1〜3 個だけ挙げてください」

• 1個でも OK。多すぎると消化不良になる
• 参加者が選んだ領域ごとに、Claude が学習リソースを 入門記事1本 → 公式ドキュメント1本 の最大2件で提示する
• リソース選定の方針：
  • 入門は日本語の解説記事 / 公式チュートリアル など、読み始めるハードルが低いもの
  • 公式は MDN / OWASP / 個人情報保護委員会 / Next.js 公式ドキュメント など一次情報

---

Phase 10: study-plan.md を書き出し

各 Phase の回答を以下のフォーマットで projects/<name>/study-plan.md に書き出す。

書き出し後

「projects/<name>/study-plan.md に書き出しました。ピッチでは、強みだけでなく『今日のスコープ外として残した領域』『これから学ぶこと』も自分の言葉で添えると、聞き手の納得感が一段上がります。study-plan.md は持ち帰り資料としても使えるので、入門記事から順に1本ずつ読んでみてください。あわせて レビュー用のページ（HTML）を作りますか？ 内容に読むときの観点を添えて、ブラウザで読める形にします。ペアフィードバックで相手に見せるのにも使えます」

肯定なら review-page.md に従って projects/<name>/review/study-plan.html を作る（共通原則 15）。

---

study-plan.md のフォーマット

# <プロジェクト名> — 学習計画

## 自己診断: ピンと来ていない技術

<Phase 1 の回答（参加者の言葉のまま）>

## 実運用で突っ込まれそうな点

<Phase 2 の回答>

## デリバリー前提のチェック棚卸し

| 観点 | 参加者の回答 | 関連する専門用語 |
|---|---|---|
| 認証・認可 | <Phase 3> | authentication / authorization |
| 入力の扱い | <Phase 4> | XSS / 入力バリデーション |
| データの出どころ | <Phase 5> | OSS ライセンス / 利用規約 |
| 個人情報・法令 | <Phase 6> | 個人情報保護法 / プライバシーポリシー |
| コスト・スケール | <Phase 7> | 従量課金 / レートリミット / Quota |
| 障害・運用 | <Phase 8> | モニタリング / バックアップ |

## 学習ロードマップ

### 領域1: <参加者が選んだ領域名>

- **なぜ学ぶ**: <参加者の言葉での動機>
- **入門**: <タイトル> — <URL>
- **公式**: <タイトル> — <URL>

### 領域2: ...

### 領域3: ...

---

このスキルが生む体験

1. 「動いた」で終わらせず、デリバリー前提で何が足りないかを自分の言葉で言える
2. 専門用語が後付けで紐付くので、用語先行の挫折感を回避できる
3. 持ち帰り後の学習が「興味ある1〜3領域」に絞られているので、続けやすい