パーソルクロステクノロジー様 第2回パーソルクロステクノロジー様 第2回架空の社内ヘルプデスクに届いた問い合わせへ、一次回答を作ります。作るのは、事実を集める役・文章を書く役・送ってよいか判定する役に分かれた3体のサブエージェントと、それを順に呼ぶ親側の手順です。部品は完成済みで配りますので、この40分でさわるのは context/ のテキストだけ。社内の用語と判断ルールをAI向けに書いた LLM wiki の中身です。手元で動かせない方も、このページの入力と出力の全文で最後まで追えます。
環境がなくても最後まで追える3つの導線と、Windows 用・Mac 用の配布ファイル、文字化けしたときの直し方をまとめています。
配布フォルダを開き、誰がどの順番で動くオーケストレーションなのかを、手を動かす前に頭に入れます。
LLM wiki を参照しない状態で一次回答を作らせ、何が足りないかをエージェント自身に列挙させます。
context/ の TODO を3箇所埋めて、同じ問い合わせに同じコマンドを打ち、出力が別物になることを確認します。
人間の承認が必要な操作をコンテキストで定義し、その1行を消すと自律範囲がどう広がるかを実際に見ます。
架空の会社の context/ を、自分の職場の語彙に置き換えて回します。翌日から自分で動かせる状態を作ります。
手元に残った出力を並べ、変わった点と変わらなかった点を自分の言葉にして締めます。
この40分の成果物一式の中身と、当日その場で解決しなかったときの進め方をまとめています。
最初に、この40分をどう使うかを共有します。手元で Claude Code が動く方も、動かない方も、同じページを見て同じ判断をしていただきます。
この演習で書くのは Markdown だけです。context/ の TODO を3箇所埋める作業と、my-context/glossary.md を5行書く作業は、テキストエディタがあれば成立します。書いたものは後日、配布ファイルに入れてそのまま実行できます。
各 Step には、受講者が打ち込むプロンプト文と、返ってきた出力の全文を載せています。講師は Step の頭で必ず一度その手順を自分の画面で実行し、結果を出してから時間を渡します。手元で動かせない場合も、投影されている実行ログを読めば、何が入力で何が出力だったかを追えます。
手を動かす時間の中身は、コンテキストに何を書くかを決めることです。ツールを操作することではありません。書く先はすべてテキストファイルですので、実行環境の有無が学習量を分けません。
Step 2 と Step 4 には、画面を見ているだけで答えられる問いを置いています。ZOOM のチャットに投げていただければ、講師がその場で読み上げます。
用語集、判断ルール、システム台帳、出力様式。この4つが LLM wiki の骨格です。業務ドメインが変わっても形は同じですので、ヘルプデスクの題材で書いた4ファイルは、設計レビューでも進捗管理でもそのまま流用できます。各 Step の冒頭に、TYPE A / B / C それぞれの進み方を1行で書いています。ご自身の型の行だけを追ってください。
中身は2本とも同一です。ファイル名の文字コードだけが違いますので、お使いの OS に合うほうを選んでください。当日朝までにメールでも送付します。
ファイル名を UTF-8 で格納し、NFC で正規化しています。標準のアーカイブユーティリティで展開してください。
Mac 用をダウンロードまず、OS と ZIP の組み合わせが逆になっていないかを確認してください。Windows で Mac 用を展開する、または Mac で Windows 用を展開すると化けます。正しい組み合わせで展開し直せば直ります。
それでも化ける場合、Windows では 7-Zip を使い、展開ダイアログの Codepage に 932 を指定してください。Mac では The Unarchiver を使い、設定の Non-English filenames で Japanese (Shift JIS) を選びます。
フォルダ名が化けたままでも演習は進められます。README.md、CLAUDE.md、context/、inbox/ はすべて英字名ですので、日本語名で化けるのは docs/ の中の実行ログ1ファイルだけです。同じ内容はこのページに載せていますので、開けない場合はここを読んでください。
6つの Step の合計が [40min] になるように配分しています。Step 3 と Step 4 が中心ですので、Step 1 と Step 2 で時間を使いすぎないようにしてください。
| Step | 時間 | TYPE A / B がやること | TYPE C の進み方 |
|---|---|---|---|
| Step 1 | [5min] | 配布フォルダを開き、構成を確認する | フォルダ構成図を読む |
| Step 2 | [6min] | コンテキストなしで一次回答を作る | 実行ログの不足リストを書き写す |
| Step 3 | [10min] | context/ の TODO を3箇所埋める | テキストエディタに同じ内容を書く |
| Step 4 | [8min] | 承認ゲートの挙動を2通り観察する | 2種類の停止メッセージを読み比べる |
| Step 5 | [8min] | 自分の業務語彙で my-context/ を書く | 同じ5行をテキストエディタに書く |
| Step 6 | [3min] | 出力の差を言語化する | チャットに1行で投稿する |
| 合計 | [40min] | — | — |
今夜さわるのは context/ と my-context/ の2つだけです。
| 完成済みの部品 | 役割 |
|---|---|
| .claude/agents/context-researcher.md | context/ を検索し、根拠付きで事実を返す。書き込みのツールは渡していません |
| .claude/agents/reply-drafter.md | templates/reply.md の様式で回答本文を書く |
| .claude/agents/policy-reviewer.md | rules.md に照らし、承認の要否を判定する |
| .claude/skills/triage/SKILL.md | 3体を直列に回す親側の手順 |
| .claude/skills/triage-bare/SKILL.md | 比較用。context/ を読まずに回答する版 |
| .claude/settings.json | 権限の設定と、承認ゲートの Hook 登録 |
| hooks/approval-gate.sh hooks/approval-gate.ps1 | 承認ゲートの本体。Mac と Linux は .sh、Windows は .ps1 が動きます |
| context/ の4ファイル | 用語集、判断ルール、システム台帳、出力様式。今夜さわるのはここです |
手を動かす対象ではありませんが、中身を見ないと持ち帰れません。当日の投影ではここを飛ばします。すでに Claude Code を日常的にお使いの方は、Step を待たずに先に読んでいただいて構いません。
権限の設定と Hook の登録です。matcher で対象のツールを絞り、command に実行するスクリプトを書きます。OS の違いはここで吸収しています。
// .claude/settings.json
{
"permissions": {
"allow": ["Read(./**)", "Write(./out/**)", "Edit(./context/**)", "Edit(./my-context/**)"],
"deny": ["Read(./solutions/**)", "Bash(curl:*)", "Bash(rm:*)"]
},
"hooks": {
"PreToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{ "type": "command", "command": "bash hooks/approval-gate.sh" }
]
}
]
}
}
サブエージェントの定義です。フロントマターで名前・説明・渡すツール・モデルを宣言し、本文がそのサブエージェントへの指示になります。tools に Write を入れていない点を見てください。調べる役に書き込みの権限を渡していません。
--- name: context-researcher description: context/ を検索して、回答に必要な事実だけを根拠付きで返す。 tools: Read, Grep, Glob model: inherit --- context/ 配下だけを調べます。見つけた事実は、ファイル名と該当箇所を添えて返します。 context/ に書かれていないことは推測せず、「記載なし」と返します。回答本文は書きません。
3体を順に呼ぶ親側の手順です。承認記録を書く条件が、この SKILL.md の4番に書いてあります。Step 4 で効いてきます。
---
name: triage
description: inbox/ の問い合わせに一次回答を作る。context/ を参照し、
承認が必要な操作かを判定してから out/ に書き出す。
---
1. context-researcher を呼び、該当システムの事実を集める
2. reply-drafter を呼び、templates/reply.md の様式で回答本文を書く
3. policy-reviewer を呼び、rules.md に照らして承認の要否を判定する
4. 承認が必要と判定されたら、out/ に書かずに利用者へ確認する。
利用者が「はい」と答えた場合にかぎり、承認記録を1行追記してから書き込む
（Mac / Linux: bash hooks/record-approval.sh <ファイル名>
Windows: powershell -File hooks/record-approval.ps1 <ファイル名>）
利用者の返事がないまま承認記録を書いてはいけません
5. 承認が不要と判定されたら、そのまま out/ に書き込む
承認ゲートの本体です。out/ への書き込みのうち、URL やサーバーパスを含むものだけを対象にしています。対象になったときだけ、承認記録があるかを見ます。
# hooks/approval-gate.sh（抜粋）
input=$(cat)
path=$(echo "$input" | python3 -c 'import sys,json; print(json.load(sys.stdin)["tool_input"].get("file_path",""))')
body=$(echo "$input" | python3 -c 'import sys,json; print(json.load(sys.stdin)["tool_input"].get("content",""))')
case "$path" in
*/out/*) ;;
*) exit 0 ;; # out/ 以外は素通り
esac
echo "$body" | grep -Eq 'https?://|\\\\' || exit 0 # URL もサーバーパスも無ければ素通り
name=$(basename "$path")
if grep -q "$name" .claude/audit/approvals.log 2>/dev/null; then
exit 0
fi
echo "out/ に社外へ出せる形の情報（URL・サーバーパス）を含む文書を書き込むには、承認記録が必要です。" >&2
echo ".claude/audit/approvals.log に $name の記録が見つかりません。" >&2
exit 2 # 終了コード 2 で書き込みを止める
承認記録の追記を、エージェント自身に任せています。実際の業務に持ち込むときは、approvals.log をエージェントの書き込み権限から外し、別のプロセスか人が書く形にしてください。記録を作れる者が記録を要求される者と同じだと、監査の意味が薄くなります。
この Step が終わると、/agents に3体、/skills に2本が並んだ状態になります。誰がどの順番で動くのかを、手を動かす前に頭に入れます。
TYPE A 下の操作をそのまま実行します。 TYPE B 実行権限の設定は不要です。VS Code でフォルダを開き、copilot/README.md を先に読んでください。 TYPE C フォルダ構成図と、下の4行の出力例を読みます。手元の操作はありません。
部品は完成品として配ります。40分でハーネスの部品を組み立てると、それだけで時間が尽きるためです。今夜は部品を固定したまま、コンテキストだけを変えて出力の差を見ます。そのために、まず部品が正しく認識されているかを確かめます。第1回で同じ部品を自分で書いた方は、.claude/ の中身を読み比べていただくと差分が見えます。
展開してできた orchestration-kit フォルダを、VS Code の Open Folder から開きます。
VS Code の Terminal メニューから New Terminal を開きます。打ち込む内容が OS で分かれます。
Mac / Linux の場合 chmod +x で、スクリプトに実行の許可を与えてから起動します。
cd orchestration-kit chmod +x hooks/approval-gate.sh claude
Windows（PowerShell）の場合 PowerShell に chmod はありません。承認ゲートは hooks/approval-gate.ps1 のほうが動きますので、実行の許可を与える操作は不要です。移動して起動するだけです。
cd orchestration-kit claude
Windows 用の .claude/settings.json は配布データに同梱しています。展開したフォルダの README.md に、どちらの設定が使われるかを書いています。
Claude Code のセッション内で /agents と /skills を順に打ちます。
次のプロンプトをそのまま送信します。
このフォルダの context/ と .claude/ を読んで、私が /triage を打ったときに 誰がどの順番で動くのかを4行で教えてください。ファイルの中身は貼らないでください。
/agents に context-researcher、reply-drafter、policy-reviewer の3体が並びます。/skills に triage と triage-bare の2本が並びます。プロンプトへの返答は、次のような4行になります。
1. context-researcher が context/ を検索し、回答に必要な事実だけを根拠付きで返します。 2. reply-drafter が templates/reply.md の様式で回答本文を書きます。 3. policy-reviewer が rules.md に照らして、そのまま送れるかを判定します。 4. 承認が必要と判定された場合は、out/ に書き込まずあなたの返事を待ちます。
3体2本が揃い、この4行が返ってくれば下準備は完了です。
いま確認したのは、親エージェント1体がサブエージェント3体を直列に回す構成です。1体に全部やらせず、事実を集める役、文章を書く役、判定する役に分けています。狙いはコンテキストの分離です。context-researcher が読んだファイルの全文はそのサブエージェント側で完結し、親には要約された事実だけが返ります。親の会話にファイルの中身が積み上がらないため、3件連続で処理しても文脈が濁りません。
もう1点。この4行の説明は、こちらで用意した資料ではなく、エージェントが .claude/ と context/ を読んで生成したものです。構成が正しく置かれていれば、エージェントは自分の構成を説明できます。説明できないときは、置き場所か記述のどちらかが間違っています。
/agents に何も出ない場合は、Claude Code を起動したディレクトリを確認してください。orchestration-kit の直下でない可能性があります。Claude Code は起動時のカレントディレクトリを起点に .claude/ を読みます。/exit で抜け、cd orchestration-kit を実行してから claude を打ち直してください。
それでも直らない場合は hints/step01_orchestration_map_hint.md を開き、投影中の実行ログを見て Step 2 へ進んでください。ここは下準備ですので、遅れを持ち越す価値はありません。
.claude/agents/ の3ファイルを開き、tools の行を見比べてください。3体で渡しているツールが違います。reply-drafter に Grep を足したら何が変わりそうか、policy-reviewer から Read を外したら何が壊れるかを考えてみてください。答えは Step 4 の挙動に出ます。
この Step が終わると、out/ticket-001_bare.md と、その回答に足りないものの一覧が手元に残ります。この出力が今夜の比較対象になります。
TYPE A 下のコマンドとプロンプトをそのまま実行します。 TYPE B copilot/step02.md の手順で、同じ2つの問いをチャットに送ります。 TYPE C 下の出力例2つを読み、不足リストの5項目を書き写します。
エージェントの回答が薄いとき、原因をモデルの性能やプロンプトの書き方に求めがちです。多くの場合は、情報が渡っていないだけです。まず情報を渡さない状態の出力を作り、何が足りないかをエージェント自身に列挙させます。人間が当てずっぽうで補うより、実際に詰まった当人に言わせたほうが、コンテキストの設計が速く決まります。
inbox/ticket-001.md を開きます。架空の社内ヘルプデスクに届いた、勤怠システムにログインできないという3行の依頼です。
Claude Code で次を実行します。
/triage-bare inbox/ticket-001.md
出力が返ったら、続けて次のプロンプトを送信します。
いまの回答を、社内ヘルプデスクの担当者がそのまま利用者へ送れますか。 送れないとしたら、何の情報が足りないからですか。箇条書きで5つまで挙げてください。
1つ目のコマンドで、out/ticket-001_bare.md に次のような回答が生成されます。どの会社にも当てはまる一般的な内容です。
件名: 勤怠システムへのログインに関するご案内 お問い合わせありがとうございます。以下をお試しください。 1. パスワードの再設定を行ってください。 2. ブラウザのキャッシュと Cookie を削除し、再度ログインをお試しください。 3. 解決しない場合は、システム管理者へご連絡ください。 二次対応の要否: 判断できません
2つ目のプロンプトへは、次のような不足リストが返ってきます。
- 勤怠システムの正式名と、認証方式（個別パスワードか、SSO か）が不明です - アカウントロックの解除を依頼する窓口が不明です - 社内で定められた回答様式が不明です - 二次対応へ上げる基準が不明です - 利用者へ案内してよい連絡先が不明です
この5項目が、次の Step で埋める穴とほぼ一致します。
いまの出力は間違っていません。ただ、この会社について何も知らないまま書かれています。パスワードの再設定を案内していますが、この会社の勤怠システムが SSO 経由なら、その案内は的外れです。エージェントは知らないことを知らないまま、一般論で埋めます。
足りないものをエージェント自身に列挙させたことに意味があります。返ってきた5項目は、この題材で context/ に何を書くべきかの設計図です。同じやり方は自分の業務にも使えます。試しに1回投げて、返ってきた質問を書き留める。それがコンテキストの初版になります。
この回答を、ヘルプデスクの担当者がそのまま送れますか。送れないとしたら、何の情報が足りないからですか。手元で動かせない方も、投影中の出力を見れば答えられます。
/triage-bare が見つからないと表示された場合は、Step 1 の /skills の確認まで戻ってください。out/ にファイルが生成されない場合は、out/samples/ticket-001_bare.sample.md を開けば同じ内容が入っています。
出力が上の例と文言レベルで違っていても問題ありません。一般論に終始しているかどうかだけを見てください。
不足リストを出させるプロンプトを、「箇条書きで5つまで」から「この回答をそのまま送った場合に起こりうる問題を、起こる確率の高い順に3つ」へ変えて、もう一度実行してください。返ってくる項目が入れ替わります。同じ状況でも、問い方で引き出せる情報が変わることを確認できます。
この Step が終わると、context/ に10行前後の事実が入り、out/ticket-001_wiki.md に別物の回答が生成された状態になります。今夜の中心です。
TYPE A TODO を3箇所埋めてから、同じ問い合わせを流し直します。 TYPE B 同じ3箇所を埋め、.github/copilot-instructions.md へ反映してからチャットに送ります。手順は copilot/step03.md です。 TYPE C テキストエディタに同じ3箇所を書き、投影の出力と読み比べます。書いた内容は後日そのまま使えます。
プロンプトは毎回書き直しますが、context/ は一度書けば以降のすべての実行に効きます。10行の事実で出力がどこまで変わるかを、同じコマンドを2回打って確かめます。モデルもプロンプトも部品も同じで、参照先だけが違う状態を作りますので、差が出たときの原因を取り違えません。
context/systems.md と context/rules.md を開きます。TODO と書かれた箇所が3つあります。勤怠システムの認証方式、ロック解除の窓口、そして一次回答で完結してよい条件です。
ご自身で書いても構いませんし、Claude Code に埋めさせても構いません。埋めさせる場合は次のプロンプトを送信します。
context/systems.md と context/rules.md の TODO を、inbox/ の3件に一次回答するのに 必要な最小限の情報で埋めてください。書き込む前に、何をどう埋めるつもりかを 箇条書きで見せて、私の返事を待ってください。
提案が表示されます。良ければ「その内容で書いてください」と返します。直したい箇所があれば、その場で指示します。
書き込みが終わったら、Step 2 と同じ問い合わせを、今度は context/ を読む版で実行します。
/triage inbox/ticket-001.md
context/systems.md の勤怠システムの項が、次のように具体的な記述に変わります。
## 勤怠システム - 社内呼称: キンタイ - 正式名: 勤怠管理システム TimeBoard - 認証方式: 全社 SSO 経由。TimeBoard 個別のパスワードリセットは不可 - ロック解除の窓口: コーポレートIT サービスデスク - よくある詰まり: SSO のセッション切れをパスワード誤りと誤認する
/triage の実行では、3体が順に動く様子が画面に出ます。生成された out/ticket-001_wiki.md は次のようになります。
件名: 勤怠管理システム TimeBoard へのログインに関するご案内 お問い合わせありがとうございます。TimeBoard は全社 SSO 経由で認証しており、 TimeBoard 個別のパスワード再設定は行っておりません。 1. すべてのブラウザタブを一度閉じ、社内ポータルから再度サインインしてください。 2. それでも入れない場合、アカウントがロックされている可能性があります。 解除はコーポレートIT サービスデスクで承っております。 二次対応の要否: 不要（一次回答で完結する条件に該当）
Step 2 の bare 版と読み比べてください。同じコマンド、同じモデル、同じ部品のまま、文面が別物になっています。
書き込む前に提案を見せて返事を待つ、という指示を入れました。これが Human in the loop（人が承認する地点をハーネス側で固定する考え方）の最小形です。挟む位置は書き込みの直前です。実行が終わってから結果を確認する形にすると、直すたびにファイルが上書きされた後になり、戻す手間が増えます。
いま埋めたのは4ファイルのうち2ファイル、行数にして10行前後です。この程度の情報量で出力がここまで変わることが、コンテキストエンジニアリングという言葉の実態です。使いどころの切り分けは単純で、文体を直したいならプロンプトかテンプレート、内容の正しさを直したいならコンテキストです。この2つを分けて考えられると、出力に不満が出たときに手を入れる場所が決まります。
10分で埋め終わらない場合は、solutions/context/ を context/ に上書きコピーして先へ進んでください。埋める作業そのものより、埋めた後の出力の差を見ることが目的です。
cp -R solutions/context/. context/
Windows のコマンドプロンプトでは次を使います。
xcopy /E /Y solutions\context context
提案が返ってこずにいきなり書き込まれた場合も、そのまま次へ進んで構いません。書き込みの前で止める挙動は Step 4 でもう一度扱います。
context/glossary.md に、この会社だけで通じる略語をわざと1つ足してください（たとえば「シンセイ = 稟議申請システム Ringi Flow」）。そのうえで inbox/ticket-004.md を流すと、略語が正式名に展開されて回答に出ます。用語集が効いていることを、システム台帳とは別の経路で確認できます。
この Step が終わると、判断で止まる場合と、仕組みで止まる場合の2種類のメッセージを、両方とも自分の画面で見た状態になります。
TYPE A ルールを1行消して、同じコマンドを2回実行します。 TYPE B Copilot には Hook がありません。1回目の判断で止まる挙動までを再現し、2回目は投影をご覧ください。手順は copilot/step04.md です。 TYPE C 下の2つの停止メッセージを読み比べます。今夜の見せ場ですので、投影に集中していただいて構いません。
コンテキストが決めるのは出力の質だけではありません。エージェントがどこまで自分で判断してよいかという自律の範囲も、同じ context/ が決めています。ルールを1行消すと範囲がどう広がるかを実際に見て、そのうえで機械的なゲートが最後の一線を守る様子まで確認します。
inbox/ticket-002.md を開きます。協力会社のメンバーに設計書を共有したい、共有ドライブの URL を送ってよいか、という架空の問い合わせです。次を実行します。
/triage inbox/ticket-002.md
context/rules.md の「人間の承認が必要な操作」の節を開き、社外への情報共有に関する行を削除します。削除は Claude Code に頼んでも構いません。
context/rules.md の「人間の承認が必要な操作」から、社外への情報共有に関する行を 削除してください。削除したら、この変更で何が変わるかを1行で報告してください。
削除できたら、まったく同じコマンドを実行します。
/triage inbox/ticket-002.md
観察が終わったら、削除した行を戻します。「さきほど削除した行を元に戻してください」と伝えれば戻ります。
1回目の実行では、policy-reviewer が承認を求めて停止します。回答案は画面に出ますが、out/ には書き込まれません。
policy-reviewer の判定: 承認が必要
理由: rules.md「人間の承認が必要な操作」に該当します
（社外の関係者へ社内資料の所在を伝える）
回答案を作成しましたが、out/ への書き込みは保留しています。
このまま送信してよろしいですか。（はい / 修正指示）
2回目、ルールを1行消した後の実行では、policy-reviewer は承認を求めません。そのまま out/ へ書き込もうとします。ところが、今度は Hook 側が止めます。
policy-reviewer の判定: 承認不要（該当するルールなし） Write(out/ticket-002_wiki.md) blocked by approval-gate.sh: out/ に社外へ出せる形の情報（URL・サーバーパス）を含む文書を書き込むには、承認記録が必要です。 .claude/audit/approvals.log に ticket-002_wiki.md の記録が見つかりません。
1回目は判断で止まり、2回目は仕組みで止まりました。この2つの止まり方の違いが、画面に並びます。
自然言語で書いたルールは、自然言語で消せます。いま1行消しただけで、エージェントは社外共有を自分の判断で処理してよいものと解釈しました。悪意がなくても起きることです。context/ を編集できる人が増えるほど、この事故の確率は上がります。
だから機械のゲートを重ねます。Hook は Markdown の文面を読みません。out/ へ書き込もうとした内容に URL やサーバーパスが含まれるかどうかだけを見て、含まれていて承認記録がなければ終了コード 2 で止めます。Hooks の PreToolUse は、ツールが実行される前に必ず走るイベントです。
承認記録は誰がいつ書くのか
ここが必ず質問になります。書くのは、1回目の実行であなたが「はい」と答えた後です。.claude/skills/triage/SKILL.md の4番に、利用者が承認したときにかぎり hooks/record-approval.sh（Windows は record-approval.ps1）を実行して1行追記する、と書いてあります。2回目の実行では policy-reviewer が承認不要と判定したため確認が起きず、記録も作られませんでした。それで Hook 側が止めています。
Step 2 と Step 3 では、同じ out/ への書き込みが止まりませんでした。生成された回答に URL もサーバーパスも含まれていなかったためです。Hook が見ているのは書き込み先だけではなく、書き込む中身も含みます。
この構造は業務にそのまま持ち帰れます。承認が必要な操作の定義は context/rules.md に置き、現場が更新します。絶対に越えさせない線は hooks/ に置き、変更にレビューを通す運用にします。片方だけでは、ルールが消えた時点で歯止めがなくなります。
ルールを1行消したら、エージェントが承認を求めなくなりました。これは仕様ですか、事故ですか。画面を見ているだけで答えられます。ZOOM のチャットへどうぞ。
1回目で承認を求めず、そのまま回答が生成されてしまう場合は、context/rules.md の「人間の承認が必要な操作」の節に社外共有の行が残っているかを確認してください。Step 3 で solutions/ を上書きコピーした場合、その行は入っています。
2回目で Hook が止めない場合、Mac と Linux では chmod +x hooks/approval-gate.sh の実行忘れがほとんどです。実行して /exit で一度抜け、claude を打ち直してください。Windows では実行権限の設定がありませんので、原因は別です。.claude/settings.json の command が powershell -File hooks/approval-gate.ps1 になっているかを確認してください。配布データの README.md に、Windows 用の設定へ切り替える1行を書いています。
それでも挙動が変わらない場合は hints/step04_approval_gate_hint.md を開いてください。確認箇所と、Hook が止めた形の見分け方を書いています。out/samples/ticket-002_blocked.sample.md に、止まった状態の出力も入れてあります。
.claude/settings.json の matcher を Write|Edit から Read に変え、hooks/approval-gate.sh の判定を「solutions/ 配下を読もうとしたら止める」に書き換えてください。書き込みではなく読み取りを止める Hook になります。書き換えは Claude Code に頼んで構いません。止める対象を1つ変えるだけで、同じ仕組みが別の用途に使えることを確認できます。
この Step が終わると、my-context/ に自分の職場の語彙が5行入り、その語彙で書かれた一次回答が手元に残ります。持ち帰った翌日に自分で動かせる状態です。
TYPE A 5行書いて、下のプロンプトで回します。 TYPE B 5行を .github/copilot-instructions.md に置いて同じ問いを送ります。手順は copilot/step05.md です。 TYPE C テキストエディタに5行書きます。この5行が今夜いちばん持ち帰る価値のあるものですので、時間はここに使ってください。
架空の会社の context/ を埋めるところまでは、講師の用意した正解に沿って進みます。自分の職場の語彙に置き換えた瞬間に、正解のない状態になります。そこでエージェントが何を質問してくるかが、明日から埋めるべきコンテキストの一覧です。
my-context/glossary.md を開きます。空のテンプレートに、毎日使っている呼び名を5行だけ書きます。社内システムの通称と正式名、担当部署、そのシステムでよくある問い合わせを1つ。実名で困る場合は伏せ字で構いません。
# 用語集 - 社内呼称: （例）ケイヒ - 正式名: （例）経費精算システム ○○○ - 担当部署: （例）経理部 精算チーム - よくある問い合わせ: （例）申請が差し戻される理由が分からない - 補足: （例）月末3営業日は処理が遅延する
inbox/my-ticket.md に書きます。空のファイルを用意してあります。思いつかない場合は、inbox/ticket-003.md（経費精算が却下された理由が分からない、という架空の依頼）の中身をコピーして inbox/my-ticket.md に貼り付けてください。次の手順のプロンプトは inbox/my-ticket.md を指していますので、ファイル名を差し替える必要がなくなります。
次のプロンプトを送信します。
my-context/ を参照して、inbox/my-ticket.md に一次回答を作ってください。 context/ ではなく my-context/ を読んでください。 回答を書くのに必要な情報が my-context/ に足りない場合は、 書き始める前に、足りない項目を質問してください。
5行しか書いていませんので、エージェントは高い確率で質問を返してきます。
回答を書く前に、3点確認させてください。 1. 差し戻しの理由を利用者へ伝えてよい範囲は決まっていますか。 2. 精算チームへ問い合わせを回す判断基準はありますか。 3. 回答に含めてよい連絡先は、メールとチャットのチャンネル名のどちらですか。
この質問に答えるか、my-context/glossary.md に書き足すかして再実行すると、自分の職場の言葉で書かれた一次回答が out/ に生成されます。この往復が2回以内で回答に到達すれば成功です。
ここで返ってくる質問こそが、明日から埋めるべきコンテキストの一覧です。エージェントに業務を任せられない理由を精度の問題として説明しがちですが、実際には社内の誰も文書にしていない暗黙知が渡っていないだけ、という場合がかなりあります。エージェントは、その暗黙知の在りかを短時間で洗い出す道具としても使えます。
my-context/ は5行から始めて構いません。最初から完璧な社内 wiki を書こうとすると着手できないままになります。動かして質問された項目だけを足していけば、必要なものが必要な順に埋まります。今夜持ち帰っていただきたいのは、この足していく回し方のほうです。
copilot/ フォルダを開いてください。my-context/glossary.md の中身を .github/copilot-instructions.md に置く手順と、サブエージェント3体を3往復のチャットに分けた手順を入れてあります。参照する場所が変わるだけで、コンテキストを設計するという作業自体は同じです。
自分の職場の題材が思いつかない場合は、inbox/ticket-003.md（経費精算が却下された理由が分からない、という架空の依頼）をそのまま使い、solutions/my-context/ の記入例を参考に5行書いてください。記入例は架空の会社のものです。
エージェントが質問を返さずにいきなり書き始めた場合は、プロンプトの最後の2行が抜けている可能性があります。hints/step05_my_context_hint.md に、5行に何を選ぶかの考え方を書いています。
返ってきた質問に答えるのではなく、質問そのものを my-context/rules.md の見出しとして写し取ってください。答えは空欄のままで構いません。空欄が並んだファイルが、明日あなたが社内の誰に何を聞けばよいかの一覧になります。埋まっていない項目のうち、自分ひとりで決められないものに印を付けておくと、持ち帰り後の動きが決まります。
この Step が終わると、何がコンテキストで変わり、何が変わらなかったかを、自分の言葉で1行にした状態になります。
TYPE A 下のプロンプトで2本を読み比べさせます。 TYPE B 同じ2本をチャットに貼り付けて読み比べさせます。 TYPE C 投影の比較結果を読み、気づいた点を1行でチャットへ投稿します。
出力を見て「良くなった」で終わらせると、次に出力が気に入らないとき、また当てずっぽうでプロンプトを書き直すことになります。何がどう変わったかを分解して言葉にすると、手を入れる場所が決まります。
ターミナル、または Claude Code の中で次を実行します。
ls out/
次のプロンプトを送信します。
out/ticket-001_bare.md と out/ticket-001_wiki.md を読み比べて、 変わった点を3つ、変わらなかった点を1つ挙げてください。表は使わず箇条書きにしてください。 context/ のどのファイルがどの変化に効いたかも1つずつ添えてください。
変わった点 - 案内先が「システム管理者」から「コーポレートIT サービスデスク」に変わりました （効いたファイル: context/systems.md） - パスワード再設定の案内が消え、SSO 経由である事実の説明に変わりました （効いたファイル: context/systems.md） - 二次対応の要否が「判断できません」から「不要」に変わりました （効いたファイル: context/rules.md） 変わらなかった点 - 文章の丁寧さと、件名・本文・二次対応の3欄という構成は同じです （効いたファイル: context/templates/reply.md）
この内容を1行にまとめてチャットへ投稿していただければ、続く振り返りのパートでそのまま使います。
変わらなかった点をあえて挙げさせています。コンテキストを足しても文章の質そのものは変わりませんでした。変わったのは、この会社について何を知っているかだけです。Step 3 で挙げた切り分け（文体はプロンプトかテンプレート、内容の正しさはコンテキスト）が、出力の差として画面に出た形になります。
生成された回答と context/ 一式は、そのまま持ち帰れます。inbox/ を自分の業務の依頼に、context/ を自分の職場の事実に入れ替えれば、明日から回せる形になっています。
out/ に2本そろっていない場合は、out/samples/ の ticket-001_bare.sample.md と ticket-001_wiki.sample.md を読み比べてください。プロンプトのファイル名をこの2本に差し替えれば、同じ比較ができます。
時間が余った場合は hints/step06_diff_prompt_hint.md に、観察の観点を追加で書いています。
40分が終わった時点で手元に残るものを並べます。配布ファイルは開催後も使えます。
context/glossary.md、context/rules.md、context/systems.md、context/templates/reply.md）。用語集、判断ルール、システム台帳、出力様式の4点ですtriage と、比較用の triage-bare）context-researcher、reply-drafter、policy-reviewer）hooks/approval-gate.sh、Windows 用の hooks/approval-gate.ps1、承認記録を書く hooks/record-approval.sh、.claude/settings.json への登録）my-context/ と、そこから生成された一次回答copilot/）docs/ の実行ログ）my-context/README.md に3行で書いています。inbox/ に自分のところへ来た依頼を1件置き、my-context/glossary.md を5行埋め、質問されたら書き足す。これだけです。完成した wiki を先に作ろうとしないでください。
copilot/ フォルダに、context/ 4ファイルを .github/copilot-instructions.md 1枚に畳んだ版と、サブエージェント3体を GitHub Copilot のチャット3往復に置き換えた手順を入れてあります。参照される場所が変わるだけで、何を書くかという判断は共通です。hooks/approval-gate.sh が止めるのは、out/ への書き込みのうち URL やサーバーパスを含むものだけです。対象を1点に絞ってあります。context/ は増やすより、事実でなくなった行を落とす運用のほうが効きます。書くのは、エージェントが自力で正しく推測できないことだけにしてください。orchestration-kit の直下で claude を起動していないと、.claude/skills/ が読まれません。次に SKILL.md の YAML frontmatter に description があるかを確認します。description は必須の項目です。書式は公式ドキュメント（code.claude.com/docs/en/skills）に掲載されています。README.md に、当日その場で動かせなくても後日この手順どおりに再現できる旨と、必要な確認項目を書いています。docs/ の実行ログには Step 1 から Step 6 の入力と出力の全文が入っていますので、実行しながら答え合わせができます。このページも開催後そのまま公開しています。