初見の Java プロジェクトを Issue 駆動で直す

目的

課題Bは、あなたが書いていない Java のプロジェクトです。ここでやることは2つあります。

1つ目は、コードを読む前に、まず動かすことです。動いている画面を先に見ておくと、あとから「ここが変だ」と気づけます。画面を見ないままコードだけを読むと、何が正しい状態なのかがわからないまま読むことになり、時間がかかります。初見のコードに対して人が最初にやるべきなのは、読解ではなく観察です。

2つ目は、Skill をあとから足すことです。演習Aで配置したハーネスに、公式の Skill を3つ追加します。追加といっても、やることはフォルダのコピーと、テキストの貼り付けだけです。AI の設定があとから足せる部品でできていることを、足す動作そのもので確認します。

操作 1 Skill 3種を配置する

handson/_harness_kit/step2_kadaiB/.claude/skills/ の中にある4つのフォルダを、handson/.claude/skills/ の下にコピーします。エクスプローラでドラッグしても、VSCode のエクスプローラでコピーと貼り付けをしてもかまいません。ターミナルで実行する場合は、handson フォルダにいることを確認してから次を打ちます。

操作 2 コマンドを1本配置する

同じく _harness_kit/step2_kadaiB/.claude/commands/regression-check.md を、handson/.claude/commands/ にコピーします。演習Aで配置した selfcheck.md の隣に並びます。/regression-check は B-4 の発展課題で使います。

操作 3 CLAUDE.md に追記する

_harness_kit/step2_kadaiB/CLAUDE_追記.md を開き、中身をすべて選択してコピーします（Ctrl+A のあと Ctrl+C。Mac は Cmd+A と Cmd+C）。handson/CLAUDE.md を開き、いちばん下にカーソルを置いて貼り付け、保存します（Ctrl+S。Mac は Cmd+S）。

既にある内容は消さないでください。末尾に足すだけです。追記される内容は、課題Bの進め方、Issue の書き方、修正の決まり、テストの決まり、追加した Skill とコマンドの説明です。

操作 4 パネルを開き直す

CLAUDE.md と Skill の一覧は、セッションの開始時に読み込まれます。追記した内容を反映させるため、Claude Code のパネルをいったん閉じて、もう一度開いてください。

操作 5 アプリを起動する

VSCode のターミナルを開きます（Ctrl+`）。handson フォルダにいることを確認してから、kadaiB に移動して起動します。

ターミナルに大量のログが流れます。最後のほうに Started EquipmentApplication in 3.2 seconds のような行が出れば起動できています。このターミナルは閉じないでください。閉じるとアプリが止まります。以降のステップで別のコマンドを打つときは、ターミナル右上の分割アイコンで新しいターミナルを開いてください。

操作 6 ブラウザで画面を見る

ブラウザで http://localhost:8080/equipments を開きます。備品の一覧が20件、表形式で並びます。件数を数えて20件あることを確認してください（課題Aの50件とは別のデータです）。次に、画面上部の検索ボックス（「備品名で検索」と薄く書かれた入力欄）に PC と入力し、右隣の「検索」ボタンを押します。備品名に PC を含む1件だけに絞り込まれます。一覧に戻すときは、検索ボックスを空にしてもう一度「検索」を押します。

操作 7 詳細画面をいくつか開く

一覧の備品名はリンクになっています。上から順に、5件以上クリックして詳細画面を開いてください。一覧に戻るときはブラウザの戻るボタンか、画面下の「一覧へ戻る」を使います。正常に詳細が開く備品と、エラー画面（Whitelabel Error Page）になる備品があります。エラーになった備品の備品コードを控えておいてください。

自分で考える

生成物の名前と場所

• handson/.claude/skills/claude-automation-recommender/
• handson/.claude/skills/skill-creator/
• handson/.claude/skills/threat-model/
• handson/.claude/skills/_lib/
• handson/.claude/commands/regression-check.md
• handson/CLAUDE.md（末尾に追記した状態）
• 起動中のアプリ（http://localhost:8080）／ handson/memo.md の ## B-0

OK基準

• handson/.claude/skills/ に4つのフォルダが並んでいる
• handson/.claude/commands/ に selfcheck.md と regression-check.md の2本がある
• handson/CLAUDE.md の末尾に ## 課題B の進め方（演習B から追加） の見出しがある
• ターミナルに Started EquipmentApplication が出ている
• ブラウザの一覧画面に備品が20件並んでいる
• 詳細画面でエラーになる備品を1件以上見つけ、備品コードを控えた

追加と考察

初回の起動はライブラリのダウンロードが走るため、数分かかることがあります。事前セットアップで一度起動していれば、2回目以降は数十秒です。3分待っても進まないときは挙手してください。社内ネットワークの経路によっては外部のリポジトリに繋がらないことがあり、その場合は講師が用意した依存キャッシュに切り替えます。

配置の作業でやったことを整理すると、3つだけです。フォルダをコピーした（Skill）、ファイルを1本コピーした（コマンド）、テキストを末尾に貼り付けた（共有文脈）。特別なインストール作業も、設定画面の操作もありません。AI の振る舞いを変える仕組みは、置き場所が決まったただのテキストファイルです。ここが理解できると、社内で自分たちの規約を AI に守らせる方法が具体的に見えてきます。

発展課題

ブラウザで http://localhost:8080/h2-console を開いてください。接続画面が出ます。JDBC URL は jdbc:h2:mem:equipmentdb、ユーザー名は sa、パスワードは空欄のままです。Connect を押すと、データベースの中身を直接見られます。左のツリーから EQUIPMENT を選び、SELECT * FROM EQUIPMENT を実行してください。

画面に出ているデータと、テーブルの中身は一致していますか。特に NOTE 列と STOCK 列を見比べてください。画面で見えるものと、データそのものは別です。どちらを正として調べるかで、原因の見つかり方が変わります。

目的

初見のプロジェクトに対して、どこを自動化すると効くかを AI に提案させます。演習Aでは、講師が用意したハーネスをそのまま配置しました。実務では、その中身を誰かが考えて書く必要があります。ゼロから考えると重い作業ですが、たたき台なら AI が出せます。

もう1つの狙いは、読むだけの Skill と、書く Skill を区別することです。ここで使う Skill は提案しかしません。ファイルを1つも書き換えません。この性質は SKILL.md の中に宣言されています。

操作 1 提案を依頼する

Skill の名前は書いていません。それでも claude-automation-recommender が自動で選ばれます。選ばれる理由は B-5 で扱います。

操作 2 発火したことを確認する

応答の冒頭に、次の1行が出ます。

この Skill は読み取りのみを行います。ファイルの作成・変更はしません。

さらに応答のいちばん最後、実行サマリーの「従った設定」欄に claude-automation-recommender の名前が出ます。この2か所で発火を確認してください。出ていない場合は、依頼の言い方を変えて試します。

操作 3 5カテゴリの提案を読む

各提案には「効く理由」が付いています。この欄に、このプロジェクトで実際に見たファイル名が挙がっているかを確認してください。pom.xml や EquipmentServiceImpl.java のような具体名が出ていれば、プロジェクトを読んだ上での提案です。「一般的にテストは重要です」のような一般論だけなら、読まずに書いています。

操作 4 1件だけ選んで作らせる

提案の最後に、上位3件の優先順位が付いています。その中から1件だけ選び、実装を依頼します。

操作 5 作られたものを開いて読む

作られたファイルを VSCode で開いてください。中身を読まずに次に進まないでください。見るのは2点です。何をするものか日本語で読んで理解できるか。自分の職場で使うとしたら、どこを書き換える必要があるか。

自分で考える

生成物の名前と場所

• Skill を選んだ場合: handson/.claude/skills/〈名前〉/SKILL.md
• フックを選んだ場合: handson/.claude/settings.json（既存ファイルへの追記）
• サブエージェントを選んだ場合: handson/.claude/agents/〈名前〉.md
• handson/memo.md の ## B-1

OK基準

• 5カテゴリすべての提案が返ってきた（カテゴリの抜けがない）
• 「効く理由」に kadaiB の実在するファイル名が挙がっている
• 提案を1件選んで実装を依頼し、ファイルが実際に作られた
• 作られたファイルを開いて中身を読んだ
• memo.md の ## B-1 に選んだ理由が書けた

追加と考察

この Skill が提案しかしないのは、SKILL.md の先頭に次の1行が書かれているためです。

allowed-tools: Read, Glob, Grep

読む道具しか渡していないので、書きたくても書けません。だから操作4で「実際に作ってください」と別に頼む必要がありました。読むだけの AI と、書く AI を分けておくのは、チームで安全に運用するときの基本的な分け方です。調査や点検を読み取り専用にしておけば、途中で余計な変更が混ざりません。演習Aで使った reviewer サブエージェントも同じ考え方です。

もう1点、提案の質は「何を見たか」で決まります。この Skill は README.md、CLAUDE.md、ビルド定義、ソースの構造、テストの有無、既存の .claude/ の順に読みます。読む順番が SKILL.md に書いてあるから、毎回同じ品質で提案が出ます。人によって当たり外れが出ないことが、手順を固定する価値です。

発展課題

提案の内容はどう変わりましたか。kadaiB は Java と Maven のプロジェクト、kadaiA はあなたが作ったブラウザだけで動くアプリです。技術スタックが違うと提案が変わるなら、この Skill は何を見て判断していると考えられますか。

詰まったとき

目的

コードをいきなり直させず、まず AI に調べさせて、計画だけを出させます。演習Aでは、指示するとすぐにファイルが作られました。作るときはそれで進みますが、既にあるコードを直すときは事情が変わります。触っていい範囲がわからないまま書き換えられると、直ったかどうかの判断ができません。そこで、先に「どこを、どう直すつもりか」を文章で出させ、人間が読んでから承認します。

このステップの終わりに、バグを2件特定します。1件は画面にエラーが出るもの、もう1件はエラーが出ないものです。この2種類の見つけ方が違うことが、B-2 の中心です。

操作 1 Plan モードに切り替える

Claude Code パネルで Shift+Tab を押します。入力欄の近くにモードの表示が切り替わります。もう一度押すと元に戻ります。いまが Plan モードになっていることを目で確認してから進んでください。

操作 2 1件目を調べさせる

操作 3 返ってきた計画を読む

計画には、少なくとも次が書かれているはずです。原因があるファイルのパス、クラス名とメソッド名、何が起きているか（どの値が想定と違うか）、直す方針。ファイル名だけで、メソッド名まで書かれていない場合は追加で聞いてください。

操作 4 自分でコードを開いて確かめる

計画に書かれた場所を、VSCode で自分で開きます。AI が「ここが原因です」と言った行を、自分の目で読んでください。読むときの見方は次のとおりです。Java を書いたことがなくても判断できます。

• その行は、何かの値を使おうとしているか
• その値が「空っぽ」だったとき、どうなると書いてあるか
• 空っぽの場合の分岐が、どこにも書かれていないなら、それが原因の候補です

操作 5 2件目を、別の観点で調べさせる

1件目はエラーが出るので気づけました。2件目はエラーが出ません。エラーが出ないバグは、仕様と見比べないと見つかりません。仕様は handson/CLAUDE.md の ## 業務ルール（課題B） に5項目あります。

操作 6 出てきた候補を自分で確かめる

2件目の候補が出たら、必ず画面で確かめてください。AI が「ここが食い違っています」と言っただけでは、根拠になりません。候補が在庫の表示に関するものなら、一覧画面で在庫数がその境目の値になっている備品を探し、表示がルールどおりかを見ます。候補が日付の表示に関するものなら、同じ備品を一覧と詳細の両方で開き、見比べます。

自分で考える

生成物の名前と場所

handson/memo.md の ## B-2 に、次の形式で2件分を記録します。

## B-2

- 1件目: ファイル名 / メソッド名 / 症状（画面で何が起きるか）
- 2件目: ファイル名 / メソッド名 / 症状（どの業務ルールと食い違うか）

コードの変更は行いません。この時点で kadaiB の Java ファイルが1文字も変わっていないことが、このステップの正しい状態です。

OK基準

• Plan モードで依頼し、コードが変更されずに計画だけが返ってきた
• バグ候補を2件、ファイル名とメソッド名まで特定できた
• 特定した箇所のコードを、自分で開いて確認した
• 2件目については、画面で症状を確認した
• memo.md の ## B-2 に2件分を記録した

追加と考察

Plan モードの使いどころは3つです。

1. 初見のコードを扱うとき。どこに何があるかを把握してから触りたい
2. 触る範囲が広いとき。5ファイルにまたがる変更を一気に出されても読めない
3. 直し方が複数あるとき。方針を選んでから書かせたい

逆に、書き捨てのスクリプトや、失敗しても戻せる作業では、いちいち計画を挟むほうが遅くなります。モードは安全装置ではなく、読む順番の指定だと考えると使い分けやすくなります。

もう1つ、このステップでは AI に「調べて」と頼みましたが、判断は毎回あなたがしました。計画を読んで、コードを開いて、画面で確かめました。AI が出した根拠を、人が追えるかどうかが、この進め方の分かれ目です。

発展課題

エラー画面やターミナルに出ている長い英語のログ（スタックトレース）の、いちばん上の行をコピーして、そのまま貼り付けて聞きます。

スタックトレースは上から下へ「呼ばれた順の逆」に並びます。読み方を1回覚えると、AI に貼る前に自分で当たりを付けられるようになります。余裕があれば、3件目の食い違いも探してみてください。業務ルールは5項目あり、そのうち何項目が守られていないかを数えると、残りが見えてきます。

詰まったとき

目的

見つけた不具合を、他人が読んで再現できる形の文書にします。B-2 で見つけた2件は、いまのところあなたの頭の中と memo.md の走り書きにしかありません。この状態で AI に「直して」と頼むと、直す対象が毎回ぶれます。会話の中で説明し直すことになり、説明の粒度によって出てくる修正も変わります。

直す対象を先に文章で確定させるのが Issue 駆動の入口です。文章にすると、直したかどうかの判定基準も同時に決まります。

操作 1 テンプレートを読む

handson/kadaiB/issues/ISSUE_TEMPLATE.md を開きます。見出しは5つです。

この5つを増やしも減らしもしません。項目が決まっていることに意味があります。読む側が、どこに何が書いてあるかを探さずに済みます。

操作 2 記入例を読む

kadaiB/issues/ISSUE_001_詳細画面がエラーになる備品がある.md を開きます。B-2 で見つけた1件目は、既にこの形で起票されています。読むときに見てほしいのは、再現手順の粒度です。「詳細画面を開く」ではなく、どの備品のリンクを押したかまで書かれています。この粒度なら、初めて見る人でも同じ操作ができます。

操作 3 2件目のファイルを自分で作る

kadaiB/issues/ の下に、新しい Markdown ファイルを作ります。ファイル名は次の形です。症状を短く言い切る形にします。

ISSUE_002_〈内容がわかる名前〉.md

例) ISSUE_002_在庫5個の備品に要補充が出ない.md
例) ISSUE_002_購入日の表示形式が一覧と詳細で違う.md

操作 4 5見出しを埋める

ISSUE_TEMPLATE.md の中身をコピーして貼り付け、上から埋めます。埋めにくい欄は AI に相談します。

操作 5 再現手順を自分でなぞる

自分で考える

生成物の名前と場所

handson/kadaiB/issues/ISSUE_002_〈内容がわかる名前〉.md。中身は5見出しがすべて埋まった状態にします。空欄や「（記入予定）」を残さないでください。

OK基準

• ファイル名が ISSUE_002_ で始まり、内容がわかる日本語が続いている
• 5つの見出しがすべて埋まっている
• 「期待する動作」に、CLAUDE.md の業務ルール5項目のどれに当たるかが書かれている
• 「発生箇所」にファイル名とメソッド名が書かれている
• 再現手順どおりに操作して、実際に症状が再現した

追加と考察

Issue はここではローカルの Markdown ファイルです。本研修では課題管理ツールも共有リポジトリも使いません。それでも機能します。理由は、Issue の価値が保管場所ではなく、書く項目が決まっていることにあるからです。5項目が埋まっていれば、修正を依頼するときに @ でファイルを指すだけで、対象と判定基準がまとめて伝わります。

実務で使うときは、次の順で足していくと無理がありません。

1. まずテンプレートを決める（今日のこれ）
2. 置き場所をチームで1か所に決める
3. 必要になったら、課題管理ツールに移す

順番を逆にして、ツールから入ると「項目が埋まっていない Issue」が溜まります。埋める項目が決まっていないと、AI にも人にも渡せません。

発展課題

2案のうちどちらを選ぶかを決めるとき、あなたは何を基準にしましたか。変更が小さいこと、他の画面に影響しないこと、業務ルールへの合致、いずれも基準になります。選んだ基準を Issue の「修正方針」欄に1行書き足してください。この1行があると、あとから読んだ人が「なぜこの直し方にしたのか」を辿れます。

詰まったとき

目的

Issue を根拠に修正させます。「なんとなく直った」で終わらせず、直した根拠と、直った証拠を残します。証拠は2種類あります。1つは画面で見た結果です。人が目で見て確認します。もう1つはテストです。次に誰かが同じ場所を触ったときに、自動で確認されます。画面の確認は今日の自分のため、テストは明日の他人のためにあります。両方やります。

操作 1 Agent モードに戻す

Shift+Tab を押して、Plan モードを解除します。ここからはファイルを書き換えます。

操作 2 1件目を修正させる

Issue のファイルを @ で指して依頼します。ファイル名は途中まで打つと候補が出ます。

操作 3 差分を目で読んでから受け入れる

変更の提案が出たら、受け入れる前に、変更された行を読んでください。見るのは3点です。

• 変更されたファイルは、Issue の「発生箇所」に書いた場所と一致しているか
• 変更行数が、思っていたより多くないか（1つの Issue に対して、数行のはずです）
• Issue に書いていない箇所まで、ついでに整形されていないか

CLAUDE.md の ## 修正するときの決まり（課題B） に「1つの Issue につき1つの修正にします」と書いてあります。ついでの整形が混ざっていたら、その場で戻すよう伝えてください。

操作 4 アプリを再起動する

Java のコードを変えたので、アプリを起動し直します。アプリを動かしているターミナルで Ctrl+C を押して止めてから、もう一度起動します。

操作 5 ブラウザで直ったことを確認する

B-0 でエラーになった備品の詳細画面を、もう一度開いてください。エラー画面が出ず、詳細が表示されれば成功です。あわせて、壊れていなかった備品も1件開いてください。直した箇所が、元から正しかった表示を変えていないかを見ます。片方だけ見ると、直したつもりで別の場所を壊していることに気づけません。

操作 6 2件目を修正させる

再起動して、画面で確認します。2件目はエラーが出ないバグなので、確認する場所を自分で決める必要があります。業務ルールに合った表示になっているかを、該当する備品で見てください。

操作 7 テストを書かせる

2件とも直ってから、まとめて依頼します。頼み方の言葉に注目してください。

操作 8 テストを実行する

アプリを動かしているのとは別のターミナルを開きます（VSCode のターミナル右上にある、四角が2つに割れたアイコンが分割ボタンです）。kadaiB フォルダに移動して実行します。

ここで動くテストは3種類あります。このうち2つは、あなたが書いたものではありません。

最後に BUILD SUCCESS と出れば到達です。BUILD FAILURE と出た場合は操作9へ進みます。

操作 9 落ちたテストを直す

まず、どのテストが落ちたかを名前で確認します。ターミナルの出力から、次の形の行を探してください。

[ERROR] Failures:
[ERROR]   EquipmentAcceptanceTest.在庫が5個ちょうどの備品は要補充と判定される ...

日本語の部分がテストの名前です。この名前が、まだ直っていない業務ルールを指しています。EquipmentAcceptanceTest が落ちている場合は、自分が選んだ2件のほかにも業務ルールに反している箇所が残っているという意味です。その名前を手がかりに、もう1件直してください。手順は B-3 と B-4 の繰り返しで、ISSUE_003_... として起票します。

EquipmentServiceImplTest（自分で書かせたテスト）が落ちている場合は、テストのほうが間違っていることもあります。次の依頼に進んでください。

失敗したときのターミナルの出力をそのままコピーして貼り付け、依頼します。貼るのは Tests run: と FAILURE が含まれるあたりから、その下の詳細までです。全部貼っても問題ありません。

緑になるまで繰り返します。テストのほうが間違っている場合もあります。その場合は、テストを直すのか実装を直すのかを、業務ルールに戻って判断してください。

操作 10 Issue に修正結果を追記する

修正した2つの Issue ファイルの末尾に、次の見出しを足します。

## 修正結果

- 変更したファイル: 〈パス〉
- 変更内容: 〈1行から2行〉
- 確認方法: 〈画面のどこを見て確認したか〉
- テスト: 〈テストのクラス名とメソッド名〉

AI に書かせてもかまいませんが、確認方法の欄は自分の操作を書いてください。実際に見た画面のことです。

自分で考える

生成物の名前と場所

• handson/kadaiB/src/main/java/com/example/equipment/service/EquipmentServiceImpl.java（修正）
• handson/kadaiB/src/test/java/com/example/equipment/service/EquipmentServiceImplTest.java（新規作成）
• handson/kadaiB/issues/ISSUE_001_詳細画面がエラーになる備品がある.md（末尾に ## 修正結果 を追記）
• handson/kadaiB/issues/ISSUE_002_〈自分で付けた名前〉.md（同上）
• handson/memo.md の ## B-4

修正の対象が EquipmentServiceImpl.java 以外に及んだ場合は、その理由を Issue の修正結果に書いてください。

OK基準

• バグを 2件 修正した
• ブラウザで、修正前にエラーになっていた画面が正常に表示される
• 元から正しく動いていた画面が、壊れていない
• ./mvnw test が BUILD SUCCESS で終わる
• 自分で追加したテストが 2件以上 あり、どちらのバグに対応するかがコメントでわかる（配布時から入っている EquipmentAcceptanceTest の件数は数えません）
• 2つの Issue に ## 修正結果 が追記されている

BUILD SUCCESS にならないまま時間切れになった場合は、修正2件と画面での確認までで到達とします。残っている失敗テストの名前を memo.md の ## B-4 に控えて、次へ進んでください。

追加と考察

修正した箇所は、2件とも EquipmentServiceImpl.java の中にありました。画面が崩れていたので templates/ の HTML を疑った方や、URL の処理なので EquipmentController.java を疑った方もいると思います。実際には、判断をしている場所はサービス層に集まっています。「在庫が5個以下かどうか」「備考が空のときどう表示するか」は、どちらも判断です。どこを疑うかを絞れると、AI に渡す範囲も絞れます。範囲が絞れると、読ませる量が減り、返答も速く正確になります。

もう1点、テストを書いた効果はこの場では見えません。効くのは次に誰かが同じメソッドを触ったときです。今日の [20min] で書いたテストが、半年後の誰かの30分を守ります。AI に書かせると、この「あとで効く作業」の費用が下がります。従来は時間がないと真っ先に削られていた部分です。

発展課題

3件目のバグを自力で探してください。ヒントは出しません。始め方は B-2 と同じです。画面・データ・CLAUDE.md の業務ルールの3つを突き合わせます。業務ルールは5項目あり、そのうち2項目は今日直しました。残り3項目のうち、守られていないものがあるかを1つずつ確かめてください。見つけたら ISSUE_003_... を起票し、修正し、テストを足すところまでやってみてください。手順は B-3 と B-4 の繰り返しです。詳しい進め方は exercises/challenges/ch05_third_bug.md にあります。

さらに余裕があれば、B-0 で配置したコマンドを実行してください。

kadaiB/issues/ にあるすべての Issue をなぞり直し、./mvnw test を実行して、結果を1枚の表にまとめます。演習Aの /selfcheck と同じで、確認の手順そのものをコマンドに固定してある例です。結果は .work/B_regression.md に残ります。

詰まったとき

目的

自分のバグの探し方を Skill として書き出し、次のセッションでそれが自動で使われることを確かめます。B-2 でやったことを思い出してください。画面・データ・業務ルールの3つを突き合わせて、食い違いを探しました。この手順は、あなたが AI に説明したから実行されたものです。明日また同じことをするなら、また同じ説明をすることになります。

操作 1 Skill を作らせる

操作 2 3つの質問に答える

2つ目の質問がいちばん重要です。ここで挙げた言い方が、あとで Skill が選ばれる手がかりになります。あなたが実際に打ちそうな言葉で答えてください。かしこまった言い回しに直さないでください。

操作 3 できた SKILL.md を読む

handson/.claude/skills/〈名前〉/SKILL.md が作られます。開いて、特に先頭の description 欄を読んでください。

---
name: rule-mismatch-hunter
description: 業務ルールの記述と実装の食い違いを探します。「ルールと実装が合っているか調べて」「仕様と違う挙動を探して」「業務ルールと突き合わせて」のときに使います。
---

操作2で答えた言い方が、そのまま入っているはずです。入っていない場合は、いま書き足してください。手で直してかまいません。

操作 4 文脈をリセットする

これまでの会話がすべて忘れられます。さっき Skill を作った記憶も消えます。ここからは、Skill を作ったことを知らない状態の AI に話しかけることになります。消えるのは会話だけで、ファイルは消えません。

操作 5 Skill の名前を出さずに依頼する

Skill の名前も、ファイルのパスも書いていません。

操作 6 発火したかを確認する

応答のいちばん最後、実行サマリーの「従った設定」欄を見てください。さっき作った Skill の名前が出ていれば発火しています。出ていない場合も、この演習では失敗ではありません。理由は下の「追加と考察」で扱います。

自分で考える

生成物の名前と場所

handson/.claude/skills/〈自分で付けた名前〉/SKILL.md。名前は英小文字とハイフンだけを使います（例: rule-mismatch-hunter）。フォルダ名とファイル名の両方が正しくないと読み込まれません。

OK基準

• SKILL.md が作られ、先頭に name と description の2行がある
• description に、自分が実際に打ちそうな言い方が2つ以上入っている
• /clear を実行した
• リセット後の質問で、その Skill が使われた。または、使われなかった理由を自分の言葉で説明できる

追加と考察

発火しなかった場合も失敗ではありません。description に書いた言葉と、あなたが打った質問の言葉が離れていた、ということです。たとえば description に「仕様書との整合性を検証します」と書いて、質問で「ルールと違うところ探して」と打つと、離れています。Skill が発火する条件は description の文章です。

実務での使いどころを挙げます。

• レビューで毎回同じ指摘をしている → 指摘の観点を Skill にする
• 書式が決まった報告書を毎週書いている → 書式と手順を Skill にする
• 新しく入った人に毎回同じ説明をしている → 説明ではなく Skill を渡す

いずれも共通しているのは、すでに人間の頭の中にある手順を、外に出す作業だという点です。新しい技術を覚えるのではなく、いまやっていることを書き出すだけです。今日作った Skill も、B-2 でやったことをそのまま書き出しただけでした。演習Aで配置した kadaia-review も、講師が同じ作業をして作ったものです。配られる側から、作る側に回れることが、このステップで確かめたかったことです。

発展課題

発火しなかった場合は、description を書き直して、もう一度 /clear して試してください。書き直すときは、操作5で実際に打った文章に含まれる言葉を、description にそのまま入れてください。

発火した場合は、逆に、発火してほしくない質問でも発火してしまわないかを確かめます。/clear してから次のように打ってください。

ここで作った Skill が呼ばれてしまうなら、description が広すぎます。広すぎる description は誤発火します。誤発火した Skill は、関係ない作業に余計な手順を持ち込み、時間を食います。対象を絞る語（「業務ルールと」「仕様の記述と」など）を足して、もう一度試してください。

詰まったとき

目的

「バグを直す」と「危険を減らす」が別の作業であることを、実物の出力で確かめます。B-4 で直した2件は、どちらも「壊れているから直した」ものです。エラーが出る、ルールと違う。だから直しました。

このステップで扱うのは、壊れていないのに危ないものです。いまのコードは仕様どおりに動きますが、誰でも貸出操作ができます。ログインの仕組みがありません。これはバグではありません。そう作ったからです。それでも、社内に置くなら考えなければならないことです。演習Bの締めであり、第2回研修への入り口になるステップです。

操作 1 脅威モデルを作らせる

threat-model Skill が発火します。最初の応答の冒頭に、次の趣旨の宣言が出ます。

この Skill は静的解析のみを行います。対象コードの実行、外部への通信、
ファイルの変更（THREAT_MODEL.md の作成を除く）は行いません。

この宣言が出ることを確認してください。セキュリティの調査は、やり方によっては調査そのものが危険な操作になります。何をやって何をやらないかを、始める前に宣言させています。

操作 2 質問に答える

コードから読み取れないことを、3問まで聞いてきます。研修の想定でかまいません。

• 利用者は社内の人だけですか、社外にも公開しますか → 「社内のみ」
• 扱っているデータに、個人情報は含まれますか → 「含まない」
• 本番ではどこに置く想定ですか → 「社内ネットワーク内のサーバー」

答えられない場合は「わからないので既定値でお願いします」で進みます。

操作 3 待つ

実行には3分から5分かかります。待っている間に、次の問いを考えておいてください。「脅威」と「脆弱性」は、何が違うと思いますか。日本語としてはどちらも危ないことのように読めます。この2つを分けて使う理由を、あとで講師が説明します。

操作 4 出力を読む

handson/kadaiB/THREAT_MODEL.md が作られます。読む場所は4か所です。

操作 5 一番上の脅威を、コードに紐づけさせる

ファイルと行が返ってきたら、自分で開いて見てください。該当する行が、あなたが B-4 で直した箇所と同じかどうかも確認してください。

自分で考える

生成物の名前と場所

handson/kadaiB/THREAT_MODEL.md。途中経過の記録が handson/.work/threat_model_checkpoints.jsonl に残ります。この記録は消さないでください。

OK基準

• 最初の応答で、静的解析のみを行うという宣言が出た
• THREAT_MODEL.md が生成されている
• 守るべきもの・入口・脅威の並びが読み取れる
• 一番上の脅威について、コード上の該当箇所（ファイルと行）を挙げさせられた
• 今日直した2件が脅威と脆弱性のどちらだったかを、自分の言葉で言える

追加と考察

この Skill の元になっている実装は、Anthropic が公開しているリファレンス実装です。今回配ったのはコードを実行しない読み取り専用の部分だけです。元の実装には、対象のコードを隔離した環境で実際に動かして挙動を確かめる仕組みが含まれています。そちらは Docker と隔離実行の環境を必要とするため、研修の環境では動きません。

ここで確認しておきたいのは、セキュリティの調査は「読むだけ」と「動かす」で必要な環境がまったく違うという点です。読むだけなら普段の開発環境で回せます。動かすなら、壊れても困らない隔離された場所が要ります。社内で試すときも、この線引きから入ると話が進みます。

もう1点。THREAT_MODEL.md は完成品ではありません。人に確認しないと埋まらない前提が残っています（操作2で3問しか聞いていません）。AI が作れるのは、議論の出発点になる一覧までです。ここから先、どれを受け入れてどれに対処するかを決めるのは、いまのところ人の仕事です。

発展課題

優先順位の根拠に納得できましたか。納得できない場合、あなたが重く見ているものと、AI が重く見ているものが違います。前提を1行足して聞き直してください。

前提を1行足すだけで、上位が入れ替わることがあります。前提を伝えていないと、AI は一般的な想定で答えます。これは今日の演習全体を通して繰り返し出てきたことです。

詰まったとき