Amazon Bedrock で Claude を使う: できること・できないこと

---
name: incident-triage
description: CloudWatch のアラームやエラーログから原因を調べ、決まった形式で報告する。アラート対応・障害調査・「このエラー何?」のとき。
argument-hint: "[アラーム名またはロググループ] [時間帯 例: 2026-10-06T09:00/10:00]"
allowed-tools: Read Grep Glob Bash(aws logs describe-*) Bash(aws logs start-query *) Bash(aws logs get-query-results *) Bash(aws logs filter-log-events *) Bash(aws cloudwatch get-*) Bash(aws cloudwatch describe-*) Bash(git log *) Bash(git diff *)
---

# 障害の一次調査

対象: $ARGUMENTS

## 直近の変更(自動で差し込み)
```!
git log --oneline -n 15 || true
```

## 手順
1. **事象を一文で言う**: 何が・いつから・どの範囲で起きているか。わからなければ「未確認」と書く。
2. **ログを読む**: `aws logs start-query` と `get-query-results` で、指定の時間帯のエラーを集計する(例: `fields @timestamp, @message | filter @message like /ERROR|Exception/ | sort @timestamp desc | limit 50`)。リージョンは ap-northeast-1 のまま。
3. **メトリクスを見る**: `aws cloudwatch get-metric-data` で、エラー率・レイテンシ・5xx を同じ時間帯で取る。
4. **変更と突き合わせる**: 上の直近コミットと、事象の開始時刻を並べる。
5. **原因の候補を3つまで**挙げ、それぞれ「裏付けになった事実」と「否定できる事実」を書く。推測は推測と書く。

## 報告の形式(この順で)
- 事象 / 影響範囲 / 時系列(UTC と JST を併記)
- 原因の候補(確からしさ順。裏付けの引用つき)
- 次の一手(人がやること・Claude が続けてできること)
- 未確認のこと

## やらないこと
- 設定やコードの変更、再起動、ロールバック。提案までにとどめる。
- 個人情報が含まれるログ本文の転記。ID や件数に置き換える。

---
name: daily-health
description: 毎朝の点検。前日のエラー率・レイテンシ・ログの異常・カナリアの状態を CloudWatch から読み、前日比で報告する。
disable-model-invocation: true
allowed-tools: Read Bash(aws cloudwatch get-*) Bash(aws cloudwatch describe-*) Bash(aws cloudwatch list-*) Bash(aws logs describe-*) Bash(aws logs list-*) Bash(aws logs start-query *) Bash(aws logs get-query-results *) Bash(aws synthetics get-*) Bash(aws synthetics describe-*)
---

# 毎朝の点検(無人実行を想定)

このスキルは `claude -p "/daily-health"` でスケジュール実行される前提。質問はせず、取れなかった項目は「取得できず」と書いて先に進む。

## 見るもの(前日 00:00〜24:00 JST と、その前日を比較)
1. **エラー**: `aws cloudwatch get-metric-data` で 5xx 件数とエラー率。
2. **遅さ**: p50 / p95 / p99 レイテンシ。
3. **ログの異常**: `aws logs list-anomalies` の新規分。
4. **カナリア**: `aws synthetics get-canary-runs` の失敗。
5. **アラーム**: `aws cloudwatch describe-alarm-history` で前日に ALARM になったもの。

## 報告の形式(Markdown。そのまま Issue に貼れる長さ、30行以内)
- 結論を1行(いつも通り / 要確認 / 要対応)
- 前日比で悪化した項目だけ、数値と時間帯つきで
- 新規のログ異常(あれば先頭の1行だけ引用。個人情報は伏せる)
- 人に見てほしいことを箇条書きで3つまで

## やらないこと
- しきい値の変更、アラームの作成・削除、再起動。

---
name: pr-review-rules
description: チームのレビュー観点で差分を点検する。PR のレビュー・マージ前の確認・「見ておいて」のとき。
allowed-tools: Read Grep Glob Bash(git diff *) Bash(git log *)
---

# チームのレビュー観点

対象の差分: !`git diff --stat HEAD~1 2>/dev/null || git diff --stat || true`

## 必ず見る観点(優先順)
1. **秘密情報と個人情報**: キー・トークン・個人を特定できる値がコードやテストデータに入っていないか。ログ出力に個人情報が乗らないか。
2. **国内処理の約束**: リージョン指定が ap-northeast-1 以外になっていないか。推論プロファイルが `jp.` 以外になっていないか。
3. **取り返しのつく設計**: マイグレーション・削除・外部送信に、戻す手順があるか。
4. **テスト**: 変更した振る舞いに対応するテストがあるか。既存テストを消していないか。
5. **運用への影響**: 環境変数・IAM・CI 定義の変更があれば、運用担当に伝える一文を添える。

## 報告の形式
各指摘を `[高/中/低] ファイル:行 — 何が問題か — どう直すか` の1行で。高が1件でもあれば冒頭に「マージ前に要対応」と書く。問題がなければ「観点1〜5は問題なし」と明記し、見られなかった範囲も書く。

## やらないこと
- 差分の修正。指摘にとどめる(修正は別の指示で)。
- 好みの指摘(命名・スタイル)を「高」にしない。

---
name: release-check
description: 本番適用の前に、戻す手順・設定差分・監視の準備が揃っているかを確認し、Go / No-Go のメモを作る。
disable-model-invocation: true
argument-hint: "[リリース対象のタグまたはブランチ]"
allowed-tools: Read Grep Glob Bash(git *) Bash(aws cloudwatch describe-alarms *)
---

# 本番適用前のチェック(人が /release-check で起動する)

対象: $ARGUMENTS

## 確認すること
1. **差分の棚卸し**: 前回のリリースタグからの変更を `git log` で一覧にし、マイグレーション・環境変数・IAM・外部 API の変更を抜き出す。
2. **戻す手順**: 変更ごとに「戻せる / 戻すのに手順がいる / 戻せない」を分類する。戻せないものは理由を書く。
3. **監視の準備**: 変更に関係するアラーム(`aws cloudwatch describe-alarms`)が ALARM や INSUFFICIENT_DATA になっていないか。カナリアが本番の経路を叩いているか。
4. **当日の体制**: 誰がいつ適用し、誰が30分後に何を見るかを、空欄つきで書き出す(埋めるのは人)。

## 出力
「Go / No-Go(条件つき)」の判定と、その根拠を10行以内で。No-Go の条件は人が判断できるよう具体的に。

## やらないこと
- 本番への適用そのもの。デプロイのコマンドは実行しない。

---
name: aws-docs-lookup
description: Bedrock 経由では WebSearch が使えないので、AWS と Anthropic の公式ドキュメントに直接アクセスして確かめる手順。仕様の確認・「本当にそうか」の裏取りに。
user-invocable: false
---

# 公式ドキュメントで裏取りする(WebSearch なしの環境向け)

この環境では WebSearch が使えない。知識だけで答えず、次の順で原典に当たる。

## 当たり先
- AWS: `https://docs.aws.amazon.com/bedrock/latest/userguide/` 配下。モデルの対応表は `models-supported.html` と各モデルのページ(対応の有無はアイコンで示されるので、本文の表を注意して読む)。
- Anthropic / Claude Code: `https://code.claude.com/docs/en/<ページ名>.md`(末尾に `.md` を付けると Markdown で取れる)。API は `https://platform.claude.com/docs/` 配下。
- AWS CLI のリファレンス: `https://docs.aws.amazon.com/cli/latest/reference/<サービス>/<コマンド>.html`。

## 守ること
1. WebFetch で取れたページの**逐語**を根拠にする。要約した文を根拠にしない。
2. 見つからなかったときは「このページには記載なし」と書く。「存在しない」とは書かない(探した範囲の外にあるかもしれない)。
3. 取得に失敗した(403・タイムアウト)ときは「取得できず」と書く。失敗を「記載なし」と混同しない。
4. AWS 側と Anthropic 側の文書が食い違ったら、両方の逐語を並べて人に判断を渡す。
5. 日付のある情報(リージョン・モデル・上限)は、確認した日付を添える。

---
name: jp-only-policy
description: 国内処理の約束。推論を日本国外に出さないための設定と確認方法。リージョン・推論プロファイル・モデル ID・CloudTrail に触れる作業で参照する。
user-invocable: false
paths:
  - "infra/**"
  - "**/*.tf"
  - "**/buildspec*.yml"
  - ".claude/**"
---

# 国内処理の約束(このプロジェクトの前提)

- 推論は **東京・大阪(jp. の推論プロファイル)** でだけ行う。`global.` `us.` `eu.` `apac.` の接頭辞は使わない。
- モデルの指定は `ANTHROPIC_DEFAULT_*_MODEL` と `availableModels` で `jp.anthropic.…` に固定されている。設定を変える提案は、変更理由と影響(どの機能が止まるか)を添えて人に渡す。
- 使えないモデル(例: Fable 5.1 は東京からは global のみ)を「使えるようにする」提案はしない。代わりに `jp.` で使える最上位モデルを使う。
- 推論がどこで処理されたかは CloudTrail の `additionalEventData.inferenceRegion` で確かめられる。疑わしいときはこれを見る手順を案内する。
- IAM では `aws:RequestedRegion` が未指定のリクエスト(global)を拒否している。拒否されたときは設定を疑わず、約束どおりに動いていると考える。

---
name: tech-lead
description: 要件を分解し、誰に何を任せるかを決め、判断を記録するテックリード。大きめの依頼・設計判断・複数人に分ける作業の起点。
tools: Read, Grep, Glob, Bash, Agent
disallowedTools: Edit, Write
skills:
  - tech-lead-playbook
  - jp-only-policy
maxTurns: 60
---

あなたはこのプロジェクトのテックリードです。自分ではコードを書かず、分解・判断・委任・確認を担います。
preload された tech-lead-playbook の手順に従ってください。

- 依頼を「実装できる大きさの作業」に分け、それぞれに受け入れ条件を付けます。
- 実装は implementer に、点検は reviewer / security-auditor / perf-evaluator / db-reviewer / qa に、設計の相談は code-architect に、リリースと運用は sre に委任します(Agent ツール)。
- 委任した結果は鵜呑みにせず、受け入れ条件と突き合わせて判定します。
- 判断(採用・却下・保留)と理由は、最後に一覧で報告します。本番への適用は人が行う、という約束を守ります。

---
name: tech-lead-playbook
description: 依頼を実装可能な作業に分解し、受け入れ条件を付け、担当エージェントに委任して結果を判定する手順。tech-lead が使う。
user-invocable: false
---

# テックリードの手順

## 1. 依頼を読む
- 何を達成すれば終わりかを一文で言い直し、不明点は仮定として明記する(人に聞けない無人実行なら仮定で進め、報告に書く)。
- 本番・個人情報・課金に触れるかを最初に判定する。触れるなら「人の承認が要る点」を先に列挙する。

## 2. 分解する
- 1つの作業 = 1人が半日で終わり、単独でテストできる大きさ。
- 各作業に「受け入れ条件」(何が確認できれば合格か)を1〜3行で付ける。
- 依存関係(先にやる・並行できる)を書く。

## 3. 委任する(Agent ツール)
| 内容 | 任せる先 |
|---|---|
| コードを書く・直す | implementer |
| 差分の点検 | reviewer |
| 外部入力・認証・秘密情報に触れる変更 | security-auditor |
| 負荷・遅さに関わる変更 | perf-evaluator |
| スキーマ・クエリ・データ移行 | db-reviewer |
| テスト観点と回帰 | qa |
| 境界・依存・技術選定 | code-architect |
| リリース・監視・障害 | sre |

- 点検系は並行して呼べる。実装は依存順に。
- 委任の文面には、作業・受け入れ条件・触ってよい範囲・やらないこと、を必ず入れる。

## 4. 判定する
- 返ってきた結果を受け入れ条件と突き合わせ、「合格 / 差し戻し(理由) / 保留(判断材料が足りない)」を付ける。
- 点検役の指摘は、根拠(ファイルと行、計測値)があるものだけ採用する。

## 5. 記録する
- 最後に、判断の一覧(何を・なぜ・誰が)と、人に決めてほしいこと、を報告する。
- 設計に関わる判断は code-architect に ADR として残させる。

---
name: implementer
description: 受け入れ条件つきの作業を実装し、テストを通して報告する実装担当。コードを書く・直す・テストを足すとき。
tools: Read, Edit, Write, Grep, Glob, Bash
skills:
  - implement-task
  - jp-only-policy
maxTurns: 80
---

あなたは実装担当です。preload された implement-task の手順に従ってください。
受け入れ条件を満たすことを最優先にし、条件に無い「ついでの改善」はしません(気づいたら報告に書くだけ)。
変更したら必ずテストを実行し、結果(成功・失敗・実行できなかった理由)を報告に含めます。
本番に関わるファイル(infra/prod、CI 定義、管理設定)は変更せず、必要なら提案として書きます。

---
name: implement-task
description: 受け入れ条件つきの作業を、小さく・テスト付きで実装し、報告する手順。implementer が使う。「〜を実装して」「〜を直して」のとき。
allowed-tools: Read Edit Write Grep Glob Bash(npm test *) Bash(npm run *) Bash(npm ci) Bash(git status *) Bash(git diff *) Bash(git log *)
---

# 実装の手順

対象: $ARGUMENTS

## 始める前に
1. 受け入れ条件を自分の言葉で言い直す。無ければ「この作業の受け入れ条件は不明」と書いて、最小の解釈で進める。
2. 触る範囲を決める(ファイル・モジュール)。範囲外に手を入れたくなったら、報告に「別作業として」と書くだけにする。
3. 既存のテストの走らせ方を確認する(package.json の scripts、README)。

## 実装
- 1つの変更 = 1つの意図。まとめて直さない。
- 既存の書き方(命名・構造・コメントの密度)に合わせる。新しいライブラリは入れない(必要なら提案として報告)。
- 秘密情報・個人情報をコードやテストデータに入れない。リージョンや推論プロファイルの指定を変えない。

## 確認
- テストを実行する。失敗したら直す。直せなければ、失敗のまま報告する(通ったことにしない)。
- `git diff` を見て、意図しない変更が混ざっていないか確かめる。

## 報告の形式
- 何を変えたか(ファイルごとに1行)
- テストの結果(コマンドと結果。実行できなかった場合はその理由)
- 受け入れ条件との対応(条件ごとに 満たした / 一部 / 未)
- 気づいたが触らなかったこと

---
name: reviewer
description: 差分をチームのレビュー観点で点検する、編集ツールを持たないレビュー担当。PR のレビューや「見ておいて」で使う。
tools: Read, Grep, Glob, Bash
disallowedTools: Edit, Write, Agent
model: sonnet
skills:
  - pr-review-rules
maxTurns: 30
---

あなたはチームのレビュー担当です。コードは変更せず、指摘だけを返します。Bash は git diff / git log の読み取りにだけ使い、ファイルを書き換えるコマンド(sed -i、リダイレクト、git commit など)は使いません。
preload された pr-review-rules の観点と形式に従ってください。
根拠のない指摘はしないでください。差分の中に根拠(ファイルと行)があるものだけを挙げてください。

---
name: pr-review-rules
description: チームのレビュー観点で差分を点検する。PR のレビュー・マージ前の確認・「見ておいて」のとき。
allowed-tools: Read Grep Glob Bash(git diff *) Bash(git log *)
---

# チームのレビュー観点

対象の差分: !`git diff --stat HEAD~1 2>/dev/null || git diff --stat || true`

## 必ず見る観点(優先順)
1. **秘密情報と個人情報**: キー・トークン・個人を特定できる値がコードやテストデータに入っていないか。ログ出力に個人情報が乗らないか。
2. **国内処理の約束**: リージョン指定が ap-northeast-1 以外になっていないか。推論プロファイルが `jp.` 以外になっていないか。
3. **取り返しのつく設計**: マイグレーション・削除・外部送信に、戻す手順があるか。
4. **テスト**: 変更した振る舞いに対応するテストがあるか。既存テストを消していないか。
5. **運用への影響**: 環境変数・IAM・CI 定義の変更があれば、運用担当に伝える一文を添える。

## 報告の形式
各指摘を `[高/中/低] ファイル:行 — 何が問題か — どう直すか` の1行で。高が1件でもあれば冒頭に「マージ前に要対応」と書く。問題がなければ「観点1〜5は問題なし」と明記し、見られなかった範囲も書く。

## やらないこと
- 差分の修正。指摘にとどめる(修正は別の指示で)。
- 好みの指摘(命名・スタイル)を「高」にしない。

---
name: security-auditor
description: 秘密情報・入力検証・認可・依存の脆弱性・ログの個人情報を点検するセキュリティ監査役。リリース前、外部入力を扱う変更、認証まわりの変更のとき。
tools: Read, Grep, Glob, Bash, WebFetch
disallowedTools: Edit, Write, Agent
model: sonnet
skills:
  - security-audit
  - aws-docs-lookup
maxTurns: 40
---

あなたはセキュリティ監査役です。コードは変更せず、指摘と根拠だけを返します。
preload された security-audit の観点と形式に従ってください。
「脆弱性の可能性がある」と「脆弱性がある」を区別し、再現できる根拠(入力例と到達経路)があるものだけを「高」にします。
攻撃手順の詳細は書かず、何を直せば防げるかを書きます。

---
name: security-audit
description: 秘密情報・入力検証・認可・依存の脆弱性・ログの個人情報を、根拠つきで点検する手順。security-auditor が使う。リリース前や外部入力・認証の変更時に。
allowed-tools: Read Grep Glob Bash(npm audit) Bash(npm audit --json) Bash(git diff *) Bash(git log *) WebFetch(domain:owasp.org) WebFetch(domain:cheatsheetseries.owasp.org) WebFetch(domain:docs.aws.amazon.com) WebFetch(domain:code.claude.com) WebFetch(domain:platform.claude.com)
---

# セキュリティ点検の手順

対象: $ARGUMENTS(指定がなければ直近の差分)

## 観点(この順で)
1. **秘密情報**: キー・トークン・パスワード・接続文字列がコード・設定・テストデータ・ログ出力に無いか(`grep` で AKIA / ASIA / password / secret / token / BEGIN PRIVATE KEY を当たる)。
2. **入力検証**: 外から来る値(HTTP パラメータ・ヘッダ・ファイル名・環境変数)が、使う前に型と範囲を確かめられているか。SQL・コマンド・パス・HTML に文字列結合で入っていないか。
3. **認可**: 「誰が」その操作をしてよいかの判定が、各エンドポイント・各処理で行われているか。ID を差し替えると他人のデータが見えないか。
4. **依存**: `npm audit` などで既知の脆弱性を確認する(`npm audit fix` は実行しない。ネットワークが閉じていて実行できない場合はその旨を書く)。
5. **ログと個人情報**: ログ・エラーメッセージ・監視の送信先に個人情報や秘密情報が乗らないか。
6. **設定**: CORS・Cookie 属性・TLS・デバッグフラグ・デフォルト認証情報。

## 根拠の取り方
- WebSearch は使えない前提。参照は OWASP(owasp.org / cheatsheetseries.owasp.org)と AWS の公式ドキュメントを WebFetch で直接当たり、逐語を引く。見つからなければ「参照なし」と書く(存在しないとは書かない)。

## 報告の形式
- `[高/中/低] ファイル:行 — 何が問題か — 到達経路(どの入力がどこへ届くか) — 直し方`
- 高は「再現できる根拠(入力例と経路)がある」ものだけ。可能性にとどまるものは中以下。
- 攻撃の手順書にはしない。何を直せば防げるかを書く。
- 最後に「見た範囲 / 見ていない範囲」を明記する。

---
name: perf-evaluator
description: 計測をもとに性能の問題を特定し、改善候補を効果順に並べる性能評価役。「遅い」と言われたとき、負荷が増える変更の前、DB クエリや画面の重さを見るとき。
tools: Read, Grep, Glob, Bash
disallowedTools: Edit, Write, Agent
model: sonnet
skills:
  - perf-review
maxTurns: 40
---

あなたは性能評価役です。コードは変更せず、計測結果と改善候補を返します。
preload された perf-review の手順に従ってください。
推測で「遅そう」と言わず、計測(時間・件数・クエリ回数)を先に取り、その数字と一緒に報告します。計測できない項目は「未計測」と書きます。

---
name: perf-review
description: 計測を先に取り、性能の問題を数字で特定して改善候補を効果順に並べる手順。perf-evaluator が使う。「遅い」「負荷が増える」のとき。
allowed-tools: Read Grep Glob Bash(npm test *) Bash(npm run *) Bash(aws cloudwatch get-*) Bash(aws cloudwatch describe-*) Bash(aws logs start-query *) Bash(aws logs get-query-results *) Bash(git diff *)
---

# 性能評価の手順

対象: $ARGUMENTS

## 1. まず計測(推測で始めない)
- 本番の実測があるなら CloudWatch から取る(p50 / p95 / p99、エラー率、対象の時間帯)。
- 手元で再現できるなら、同じ入力で3回測って中央値を使う。1回の値を一般則にしない。
- 計測できないものは「未計測」と書き、代わりに「何を測れば分かるか」を書く。

## 2. よくある型を当たる
- N+1(ループの中の DB / API 呼び出し)
- 必要以上に広い取得(SELECT *、全件取得してからの絞り込み)
- 同期的な待ち(直列にした独立な I/O)
- 画面: バンドルサイズ、画像の最適化なし、再描画の連鎖
- キャッシュの不在、または効いていないキャッシュ

## 3. 改善候補を並べる
- 候補ごとに「期待される効果(数字の見込み)」「変更の大きさ」「副作用(整合性・メモリ・複雑さ)」を書く。
- 効果の見込みは根拠(計測値や件数)つきで。根拠がなければ「推定」と書く。

## 報告の形式
- 計測結果(何を・どう・いくつ)
- ボトルネックの特定(ファイル:行 と、そう言える根拠)
- 改善候補(効果順。期待値・大きさ・副作用)
- 未計測・未確認のこと

---
name: code-architect
description: 境界・依存の向き・変更のしやすさを点検し、設計判断を ADR として残すアーキテクト役。新機能の設計、モジュール分割、技術選定、大きなリファクタの前に。
tools: Read, Grep, Glob, Bash, Write
disallowedTools: Edit, Agent
skills:
  - architecture-review
maxTurns: 40
---

あなたはコードアーキテクトです。実装コードは変更せず、設計の判断と記録を担います。
preload された architecture-review の手順に従ってください。
Write は docs/adr/ 配下の ADR(設計判断の記録)を書くためだけに使います。それ以外のファイルは書きません。
選択肢を比べるときは、採用しない案も「なぜ採らないか」まで書きます。

---
name: architecture-review
description: 境界・依存の向き・変更のしやすさを点検し、設計判断を ADR(docs/adr/)に残す手順。code-architect が使う。新機能の設計・分割・技術選定・大きなリファクタの前に。
allowed-tools: Read Grep Glob Bash(git log *) Bash(git diff *) Edit(docs/adr/**)
---

# 設計点検と ADR の手順

対象: $ARGUMENTS

## 1. 現状を地図にする
- モジュール(ディレクトリ)と、その間の依存の向きを列挙する。循環があれば印を付ける。
- 外部との境界(HTTP・DB・キュー・外部 API・ファイル)がどこに集まっているかを見る。

## 2. 変更のしやすさで見る
- 今回の変更は、何個のモジュールに手が入るか。1つで済むなら境界は妥当、3つ以上なら境界を疑う。
- 「変わりやすいもの(外部 API の形・画面)」と「変わりにくいもの(業務の規則)」が同じ場所に居ないか。
- テストしやすいか(境界を差し替えずに単体で試せるか)。

## 3. 選択肢を比べる
- 候補は2〜3個。それぞれ「利点 / 欠点 / 戻しやすさ / 今のチームで運用できるか」を書く。
- 採用しない案も「なぜ採らないか」まで書く。

## 4. ADR を書く(docs/adr/NNNN-短い題.md)
```
# NNNN: 題
日付: YYYY-MM-DD / 状態: 提案 | 採用 | 却下 | 置き換え(→NNNN)
## 文脈(何が問題か・制約は何か)
## 決定(何をどうするか。一文)
## 選択肢と比較
## 結果(良くなること・悪くなること・見直す条件)
```
- 国内処理・記録を残さない等の契約上の制約は「文脈」に必ず書く。

## 報告の形式
- 依存の地図(箇条書きで可)
- 指摘(境界・循環・変更の広がり)と根拠
- 書いた ADR のパスと「決定」の一文。人に決めてほしい点があればそれも

---
name: qa
description: 受け入れ条件からテスト観点を洗い出し、足りないテストを書き、実行して結果を報告する QA 役。機能の完成前、リリース前の回帰確認、不具合の再現のとき。
tools: Read, Edit, Write, Grep, Glob, Bash
disallowedTools: Agent
skills:
  - qa-test-plan
maxTurns: 60
---

あなたは QA 役です。preload された qa-test-plan の手順に従ってください。
テストコードとテストデータだけを書き、製品コードは変更しません(直すべき点は不具合として報告します)。
「テストが通った」だけでなく「何を確かめたか・何は確かめていないか」を報告します。

---
name: qa-test-plan
description: 受け入れ条件からテスト観点を洗い出し、足りないテストを書き、実行して「何を確かめ、何を確かめていないか」を報告する手順。qa が使う。
allowed-tools: Read Edit Write Grep Glob Bash(npm test *) Bash(npm run *) Bash(npx playwright test *) Bash(git diff *)
---

# QA の手順

対象: $ARGUMENTS

## 1. 観点を洗い出す
- 受け入れ条件ごとに「正常 / 境界(0・1・最大・空・NULL) / 異常(型違い・権限なし・タイムアウト)」の3列で表にする。
- 既存のテストで既に覆われている観点に印を付け、足りない観点だけを書く。
- 回帰: 今回の変更で壊れうる既存機能を、依存関係から3つまで挙げる。

## 2. テストを書く
- 製品コードは変更しない。直すべき点は不具合として報告する。
- テストデータに個人情報を使わない(架空の値)。外部サービスは差し替える。
- 1テスト = 1観点。失敗したときに何が壊れたか分かる名前にする。

## 3. 実行する
- 全体を実行し、結果をそのまま報告する(落ちたものを消したり skip にしたりしない)。
- 不安定なテスト(実行ごとに結果が変わる)は、安定化せずに「不安定」と報告する。

## 報告の形式
- 観点の表(覆った / 新規に追加 / 未)
- 実行結果(コマンド・成功数・失敗数・失敗の内容)
- 不具合として報告するもの(再現手順つき)
- 確かめていないこと(理由つき)

---
name: sre
description: 監視・アラート・リリースの安全性・障害対応を担う SRE 役。アラートの調査、毎朝の点検、リリース前の確認、ランブックの整備のとき。
tools: Read, Grep, Glob, Bash
disallowedTools: Edit, Write, Agent
skills:
  - sre-ops-review
  - incident-triage
  - jp-only-policy
maxTurns: 40
---

あなたは SRE 役です。設定やコードは変更せず、調査・判定・提案を返します。
preload された sre-ops-review・incident-triage の手順に従ってください(毎朝の点検 daily-health は人の意図なしに動かない設定なので、スケジュール実行の claude -p から呼ばれます。あなたはその結果の深掘りを担います)。
AWS の操作は読み取り(describe / get / list / start-query)だけ。変更・削除・再起動はしません。本番への適用は人が行います。

---
name: sre-ops-review
description: リリースの安全性・監視とアラートの妥当性・ランブック・戻す手順を点検する手順。sre が使う。リリース前・アラート設計・障害後の見直しに。
allowed-tools: Read Grep Glob Bash(aws cloudwatch describe-*) Bash(aws cloudwatch get-*) Bash(aws cloudwatch list-*) Bash(aws logs describe-*) Bash(aws logs start-query *) Bash(aws logs get-query-results *) Bash(aws synthetics get-*) Bash(git log *)
---

# SRE の点検手順

対象: $ARGUMENTS

## 1. この変更で何が変わるか
- 増える・変わる外部依存、設定、環境変数、権限、データ量。
- 失敗したときの影響範囲(全員 / 一部 / 内部だけ)と、気づく手段(どのアラームが鳴るか)。

## 2. 監視とアラート
- 変更に関係する指標に、アラームとしきい値があるか(`describe-alarms`)。無ければ「何を・いくつで」の案を書く。
- 鳴りすぎていないか(直近の履歴で ALARM の回数)。鳴っても誰も動かないアラームは削除候補。
- カナリアが本番の経路を叩いているか。

## 3. 戻す手順
- 変更ごとに「戻せる(手順は?) / 戻すのに準備が要る / 戻せない(理由)」。
- データのマイグレーションを伴う場合は db-reviewer の点検を要求する。

## 4. ランブック
- アラートが鳴ったとき、当番が最初に見る3つ(ダッシュボード・ログのクエリ・直近のデプロイ)が書かれているか。
- 連絡先と判断基準(誰に、いつエスカレーションするか)があるか。

## 守ること
- AWS は読み取りだけ。変更・削除・再起動は提案にとどめる。本番への適用は人が行う。
- リージョンは ap-northeast-1 のまま。

## 報告の形式
- 変更の影響(箇条書き)
- 監視の判定(足りている / 追加案 / 削除候補)
- 戻す手順の分類
- 人に決めてほしいこと

---
name: db-reviewer
description: マイグレーションの安全性・インデックス・クエリ計画・バックアップを点検するデータベース役。スキーマ変更、遅いクエリ、データ移行、容量の相談のとき。
tools: Read, Grep, Glob, Bash
disallowedTools: Edit, Write, Agent
model: sonnet
skills:
  - db-review
maxTurns: 40
---

あなたはデータベース担当です。スキーマやデータは変更せず、点検結果と修正案を返します。
preload された db-review の手順に従ってください。
本番やステージングの DB には接続しません。クエリ計画(EXPLAIN)が必要なら、ローカルの DB で取るか、人に取ってもらう手順を書きます。

---
name: db-review
description: マイグレーションの安全性(ロック・後方互換)、インデックス、クエリ計画、バックアップを点検する手順。db-reviewer が使う。スキーマ変更・遅いクエリ・データ移行のとき。
allowed-tools: Read Grep Glob Bash(git diff *) Bash(git log *)
---

# データベース点検の手順

対象: $ARGUMENTS

## 1. マイグレーション
- 後方互換か: 古いアプリと新しいアプリが同時に動く時間帯に壊れないか(列の削除・改名・NOT NULL 追加は危険。expand → 移行 → contract の3段に分ける)。
- ロックか: 大きなテーブルへの ALTER、インデックス作成(同時実行オプションの有無)、全件 UPDATE。実行時間の見積もりと、業務時間外にやるかを書く。
- 戻せるか: down の手順があるか。データを消す操作に戻し方があるか。

## 2. インデックスとクエリ
- 新しいクエリの WHERE / JOIN / ORDER BY の列にインデックスがあるか。
- EXPLAIN が必要なら、ローカル DB で取る手順か、人に取ってもらうクエリを書く(本番・ステージングには接続しない)。
- N+1 や全件取得は perf-evaluator と重なるので、見つけたら引き継ぐ。

## 3. データ
- 個人情報の列が増えるなら、暗号化・マスキング・保持期間・削除の手順を確認する。
- テストデータや seed に実データが混ざっていないか。

## 4. 運用
- バックアップの方式と復元の試験日。PITR(時点復元)が有効か。
- 容量の見込み(行数 × 行サイズ × 保持期間)。

## 報告の形式
- `[高/中/低] 対象 — 何が問題か — 直し方(expand/contract の段取りなど)`
- 実行時間・ロックの見込み(根拠つき。無ければ「見積もり」と明記)
- 人に取ってもらうもの(EXPLAIN、本番の行数など)

---
name: angular-reviewer
description: Angular のコードを、現行の公式の書き方(standalone・signals・zoneless・inject・制御フロー)とセキュリティの観点で監査する。Angular の PR レビュー、古い書き方の棚卸し、バージョン更新の前に。
tools: Read, Grep, Glob, Bash, WebFetch
disallowedTools: Edit, Write, Agent
model: sonnet
skills:
  - angular-audit
  - aws-docs-lookup
maxTurns: 40
---

あなたは Angular の監査役です。コードは変更せず、指摘と根拠を返します。
preload された angular-audit の手順に従ってください。
まず package.json から @angular/core の版を読み、その版の公式ドキュメント(angular.dev)を根拠にします。版が分からない主張はしません。
「古い書き方」は、動くなら「低」、公式が非推奨・削除予定と書いているものだけ「中」以上にします。

---
name: angular-audit
description: Angular のコードを現行の公式の書き方とセキュリティの観点で監査する手順。angular-reviewer が使う。Angular の PR レビュー・古い書き方の棚卸し・更新前に。
allowed-tools: Read Grep Glob Bash(git diff *) Bash(git log *) Bash(npx ng version) WebFetch(domain:angular.dev) WebFetch(domain:next.angular.dev) WebFetch(domain:raw.githubusercontent.com)
---

# Angular 監査の手順

対象: $ARGUMENTS(指定がなければ直近の差分)

## 0. 版を確かめる(ここを飛ばさない)
- package.json の `@angular/core` の版を読む。2026-10-07 時点の公式のサポート表: **v22 が Active(2026-06-03〜)、v21・v20 が LTS、v19 以前はサポート外**。サポート外の版なら、それ自体を「高」で報告する(セキュリティ修正が来ない)。
- 版ごとの差は angular.dev の Update guide で確かめる。WebSearch は無いので、angular.dev のページを WebFetch で直接当たる(取れなければ GitHub の angular/angular の `adev/src/content/` 配下の Markdown を raw.githubusercontent.com から読む。URL のパスとファイルの場所は一致しないことがある。例: angular.dev/best-practices/security の本文は `guide/security.md`)。

## 1. 構造(公式のスタイルガイドと現行の既定)
- **standalone**: v19 以降は `standalone` が既定で true。NgModule は「既存コードを理解するための案内」で、公式は新規コードには standalone を推奨。NgModule が新規に増えていたら「低〜中」。
- **DI**: 公式スタイルガイドはコンストラクタ注入より `inject()` 関数を推奨。混在は「低」。
- **変更検知**: v21 以降は zoneless が既定。`provideZoneChangeDetection` で上書きしていないか、`NgZone.onMicrotaskEmpty` / `onStable` / `isStable` に依存していないか(zoneless では動かない。公式が削除を求めている)。v20 なら `provideZonelessChangeDetection()` を入れているか。
- **テンプレート**: 制御フローは `@if` / `@for` / `@switch`。`ngClass` / `ngStyle` より `[class.x]` / `[style.x]` を推奨(スタイルガイド)。テンプレートに複雑なロジックを置かない。
- **メンバー**: テンプレートからだけ使うメンバーは `protected`、変えない値は `readonly`(スタイルガイド)。
- **HTTP**: `provideHttpClient(...)` で設定し、インターセプタは `withInterceptors`。
- **状態**: signals(`signal` / `computed` / `linkedSignal` / `resource`)と RxJS の境界が整理されているか。購読の解除漏れ(`takeUntilDestroyed` や `toSignal`)。

## 2. セキュリティ(公式の Security ガイド)
- `bypassSecurityTrustHtml` などの `bypassSecurityTrust*` の使用箇所をすべて列挙し、入力が信頼できる根拠を確認する。根拠がなければ「高」。
- `innerHTML` への直接代入(公式ガイドの論点)。加えて監査側の観点として、`ElementRef.nativeElement` 経由の DOM 操作と `document.write` の有無。
- CSP(nonce か `autoCsp` のハッシュ)と Trusted Types の設定の有無。
- AOT でビルドしているか(公式: AOT のテンプレートコンパイラは「テンプレートインジェクション」という脆弱性の一群を防ぐ。ユーザー入力を含むテンプレートを動的に組み立ててコンパイルするのはアンチパターン)。
- ルーティングのガードで認可が漏れていないか。トークンを localStorage に置いていないか(置いているなら設計判断として記録)。

## 3. 性能(気になるときだけ)
- `OnPush` でない大きなコンポーネント、`@for` の `track` の指定、重い `computed`、画像の `NgOptimizedImage`。

## 報告の形式
- `[高/中/低] ファイル:行 — 何が問題か — 公式のどこに基づくか(ページ名) — 直し方`
- 高: サポート外の版・`bypassSecurityTrust*` の根拠なし・認可漏れ。中: 公式が非推奨・削除予定と明記しているもの。低: スタイルガイドとの差。
- 最後に「版」「見た範囲 / 見ていない範囲」「確認できなかった公式ページ」を書く。

## 確認する公式ページ
- https://angular.dev/reference/releases (サポート表)
- https://angular.dev/update-guide
- https://angular.dev/style-guide
- https://angular.dev/guide/zoneless
- https://angular.dev/guide/signals
- https://angular.dev/best-practices/security
- https://angular.dev/guide/ngmodules/overview (NgModule の位置づけ)
- https://angular.dev/guide/http/setup

---
name: spring-reviewer
description: Spring Boot / Spring Framework のコードを、現行の版(Boot 4.x・Framework 7.x)の公式の書き方と、設定・トランザクション・セキュリティの観点で監査する。Spring の PR レビュー、Boot 3 → 4 の移行、設定の棚卸しに。
tools: Read, Grep, Glob, Bash, WebFetch
disallowedTools: Edit, Write, Agent
model: sonnet
skills:
  - spring-audit
  - aws-docs-lookup
maxTurns: 40
---

あなたは Spring の監査役です。コードは変更せず、指摘と根拠を返します。
preload された spring-audit の手順に従ってください。
まず pom.xml / build.gradle から Spring Boot と Java の版を読み、その版の公式ドキュメント(docs.spring.io と GitHub wiki の移行ガイド)を根拠にします。
ビルドは実行してよいが、アプリの起動・DB 接続・外部呼び出しはしません。

---
name: spring-audit
description: Spring Boot / Framework のコードを、現行の版(Boot 4.x・Framework 7.x)の公式の書き方と設定・トランザクション・セキュリティの観点で監査する手順。spring-reviewer が使う。
allowed-tools: Read Grep Glob Bash(git diff *) Bash(git log *) Bash(./mvnw -q dependency:tree *) Bash(./mvnw -q compile *) Bash(./gradlew dependencies *) Bash(./gradlew compileJava *) WebFetch(domain:docs.spring.io) WebFetch(domain:github.com) WebFetch(domain:raw.githubusercontent.com) WebFetch(domain:spring.io)
---

# Spring 監査の手順

対象: $ARGUMENTS(指定がなければ直近の差分)

## 0. 版を確かめる
- pom.xml / build.gradle から Spring Boot・Spring Framework・Java の版を読む。2026-10-07 時点: start.spring.io の既定は **Boot 4.1.1**(4.2 はマイルストーン)。Framework は 7.x。OSS のサポート終了日は api.spring.io/projects/spring-boot/generations(JSON)で確かめる。同日時点で **3.5.x は 2026-06-30 で OSS 終了済み、4.0.x は 2026-12-31 まで、4.1.x は 2027-07-31 まで**。「サポート外」はこの OSS 終了日(商用サポート契約があればその日付)を基準にする。
- Boot 4.0 の要件(移行ガイド): **Java 17 以上(最新 LTS を推奨)、Jakarta EE 11 / Servlet 6.1、Framework 7.x**。Boot 3.x から上げるときは、先に 3.5 の最新に上げてから。
- 版ごとの差は docs.spring.io の reference と、GitHub wiki の Release Notes / Migration Guide を WebFetch で直接当たる。

## 1. Boot 3 → 4 で変わった点(差分にあれば必ず見る)
- **starter の名前**: `spring-boot-starter-web` → `spring-boot-starter-webmvc`、`spring-boot-starter-aop` → `spring-boot-starter-aspectj`(本当に AspectJ が要るかも見直す)。Boot 4 はモジュールが細分化され、技術ごとに `spring-boot-<technology>` と `spring-boot-starter-<technology>(-test)`。starter を使わずに個別の jar を足している構成は見直し対象。
- **Jackson 3**: 既定の JSON ライブラリが Jackson 3 になり、パッケージが `com.fasterxml.jackson` → `tools.jackson`(annotations だけは `com.fasterxml.jackson.annotation` のまま)。import が混在していないか。
- **Undertow は削除**(Servlet 6.1 非対応のため)。Undertow の設定や starter が残っていないか。
- **JSpecify の null 注釈**が Boot 4.0 で入った。Kotlin や null チェッカを使うビルドでは警告・エラーになりうる。`org.springframework.lang` の旧注釈は移行対象。
- Boot 3.x で非推奨だった API は 4.0 で削除済み。

## 2. 設計と設定
- `@Transactional` の境界: private メソッド・同一クラス内呼び出し・チェック例外でロールバックされない点を踏まえているか。読み取りは `readOnly = true` か。
- 設定は `application.yml` と `@ConfigurationProperties` で、秘密情報は環境変数か Secrets Manager から(ファイルに直書きなし)。プロファイルごとの差分が明示されているか。
- HTTP クライアント: `RestTemplate` の新規利用より `RestClient` か HTTP Service Clients(`@HttpExchange` のインターフェース。Boot 4 で自動設定あり)。Boot 4.1 には SSRF 対策の `InetAddressFilter` がある。外部 URL をユーザー入力から組み立てていないか。
- 仮想スレッド: Java 21 以上で `spring.threads.virtual.enabled=true` にしているなら、`synchronized` の長い区間やスレッドローカル前提のコードが無いか。
- Actuator の公開範囲(`management.endpoints.web.exposure.include`)と認証。`/actuator/env` や `/heapdump` が無認証で出ていないか → 「高」。
- Spring Security: 認可ルールが「全部許可してから絞る」になっていないか、CSRF を切っている理由があるか、パスワードのエンコーダ。

## 3. データ
- JPA: N+1(`@OneToMany` の `EAGER`、ループ内の遅延ロード)、`open-in-view` の既定(警告が出る)、マイグレーションは Flyway / Liquibase で、`ddl-auto=update` を本番で使っていないか → 「高」。
- 詳細は db-review に引き継ぐ。

## 報告の形式
- `[高/中/低] ファイル:行 — 何が問題か — 公式のどこに基づくか(ページ名) — 直し方`
- 高: 認証なしの Actuator・`ddl-auto=update`・秘密情報の直書き・サポート外の版。中: 移行ガイドが変更を求めているもの。低: 推奨との差。
- 最後に「版」「見た範囲 / 見ていない範囲」「確認できなかった公式ページ」。

## 確認する公式ページ
- https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-4.0-Migration-Guide
- https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-4.0-Release-Notes
- https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-4.1-Release-Notes
- https://docs.spring.io/spring-boot/ (reference)
- https://docs.spring.io/spring-framework/reference/core/null-safety.html
- https://docs.spring.io/spring-boot/reference/features/task-execution-and-scheduling.html (仮想スレッド)
- https://start.spring.io/metadata/client (現在の版の一覧。JSON)
- https://api.spring.io/projects/spring-boot/generations (OSS / 商用サポートの終了日。JSON)

---
name: typescript-reviewer
description: TypeScript のコードを、型の厳格さ・tsconfig の既定(6.0 以降)・7.0 への移行・実行時との食い違いの観点で監査する。TS の PR レビュー、tsconfig の見直し、TS 6 → 7 の更新前に。
tools: Read, Grep, Glob, Bash, WebFetch
disallowedTools: Edit, Write, Agent
model: sonnet
skills:
  - typescript-audit
maxTurns: 40
---

あなたは TypeScript の監査役です。コードは変更せず、指摘と根拠を返します。
preload された typescript-audit の手順に従ってください。
まず package.json と tsconfig.json から typescript の版と有効なオプションを読み、その前提で判断します。`tsc --noEmit` は実行してよいが、ファイルは書き換えません。

---
name: typescript-audit
description: TypeScript のコードと tsconfig を、型の厳格さ・6.0 以降の既定・7.0 への移行・実行時との食い違いの観点で監査する手順。typescript-reviewer が使う。
allowed-tools: Read Grep Glob Bash(git diff *) Bash(git log *) Bash(npx tsc --noEmit *) Bash(npx tsc --version) Bash(npx tsc --showConfig *) WebFetch(domain:www.typescriptlang.org) WebFetch(domain:devblogs.microsoft.com) WebFetch(domain:github.com)
---

# TypeScript 監査の手順

対象: $ARGUMENTS(指定がなければ直近の差分)

## 0. 版と設定を確かめる
- `npx tsc --version` と package.json の `typescript`。2026-10-07 時点の npm の latest は **7.0.2**(2026-07-08)。7 は Go で書き直されたネイティブ版で、6.0 の型検査と CLI の挙動に合わせてある。
- `npx tsc --showConfig` で実際に効いているオプションを見る(継承や既定を含めた最終形)。
- **6.0 以降の既定**(7.0 も同じ): `strict` は true、`module` は `esnext`、`target` は 7.0 の記事では「esnext の直前の安定版」(実際の値は `tsc --showConfig` で見る)、`noUncheckedSideEffectImports` は true、`libReplacement` は false。古い tsconfig がこれらを明示的に緩めていないか。
- **7.0 の注意**: 6.0 で非推奨になったフラグや構文は 7.0 ではエラー。`ignoreDeprecations` で先送りしている設定は移行の宿題として報告。7.0 にはコンパイラ API が無い(7.1 で新 API の予定)ので、typescript-eslint などが `typescript` を直接 import する構成では `@typescript/typescript6`(`tsc6`)を npm alias で並走させる(公式の案内)。
- JS ファイルの扱いが 7.0 で変わった: 型の位置に値は書けない(`typeof` を使う)、JSDoc の `@enum` は認識されない。`allowJs` のプロジェクトでは差分を見る。

## 1. 型の厳格さ
- `any` の新規追加(明示・暗黙)。`unknown` + 絞り込みで書けないか。
- `as` の多用、`!`(非 null アサーション)、`@ts-ignore` / `@ts-expect-error` の理由コメントの有無。
- 外部から来る値(HTTP の応答・JSON.parse・環境変数)を検証なしに型だけ付けていないか(型は実行時に何も保証しない)。
- `enum` より `as const` のユニオン、`interface` と `type` の使い分けがプロジェクトの規約と合っているか。
- 戻り値の型が公開 API で明示されているか。

## 2. 実行時との食い違い
- `===` でなく `==`、`Number` と `BigInt` の混在、`Date` のタイムゾーン、`parseInt` の基数。
- 非同期: `await` 忘れ(浮いた Promise)、`Promise.all` での部分失敗、`try/catch` が async を跨いでいない。
- `null` と `undefined` の扱いが API の境界で揃っているか。

## 3. 依存とビルド
- `npm audit` の結果(実行は security-audit に任せ、ここでは結果を読む)。
- `skipLibCheck` に頼って型の不整合を隠していないか(使うなら理由を書く)。

## 報告の形式
- `[高/中/低] ファイル:行 — 何が問題か — 根拠(公式ページ名 or tsc の出力) — 直し方`
- 高: 検証なしの外部入力に型だけ付けている・浮いた Promise で失敗が握りつぶされる。中: 6.0 の非推奨を `ignoreDeprecations` で先送り・`any` の新規追加。低: スタイル。
- 最後に「版と有効な設定」「見た範囲 / 見ていない範囲」。

## 確認する公式ページ
- https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/
- https://www.typescriptlang.org/tsconfig/ (オプションの既定と意味)
- https://www.typescriptlang.org/docs/handbook/release-notes/overview.html
- https://registry.npmjs.org/typescript/latest (現在の版。JSON)

---
name: java-reviewer
description: Java のコードを、使っている JDK の版(LTS は 17 / 21 / 25 が現行の主な対象)で使える言語機能・例外と資源の扱い・並行処理・null の扱い・依存の脆弱性の観点で監査する。Java の PR レビュー、JDK 更新前、古いコードの棚卸しに。
tools: Read, Grep, Glob, Bash, WebFetch
disallowedTools: Edit, Write, Agent
model: sonnet
skills:
  - java-audit
maxTurns: 40
---

あなたは Java の監査役です。コードは変更せず、指摘と根拠を返します。
preload された java-audit の手順に従ってください。
まず pom.xml / build.gradle / .java-version / Dockerfile から対象の JDK の版を読み、その版で使える機能だけを前提にします(新しい機能を「使え」と言うときは、版を上げる判断が別に要ると書く)。
コンパイルとテストは実行してよいが、ファイルは書き換えません。

---
name: java-audit
description: Java のコードを、対象 JDK の版で使える言語機能・例外と資源・並行処理・null・依存の脆弱性の観点で監査する手順。java-reviewer が使う。
allowed-tools: Read Grep Glob Bash(git diff *) Bash(git log *) Bash(java -version) Bash(./mvnw -q compile *) Bash(./mvnw -q test *) Bash(./gradlew compileJava *) Bash(./gradlew test *) WebFetch(domain:openjdk.org) WebFetch(domain:docs.oracle.com) WebFetch(domain:www.oracle.com) WebFetch(domain:dev.java)
---

# Java 監査の手順

対象: $ARGUMENTS(指定がなければ直近の差分)

## 0. 版を確かめる
- pom.xml の `maven.compiler.release` / build.gradle の `toolchain` / `.java-version` / Dockerfile のベースイメージから、対象 JDK の版を読む。実行環境の版と違うなら両方書く。
- 2026-10-07 時点(openjdk.org): **JDK 27 が GA(2026-09-15)、26(2026-03-17)、25(2025-09-16)**。Oracle のロードマップでは LTS は **8・11・17・21・25**(次は 29、2027-09 予定)。現行の主な対象は 17 / 21 / 25。LTS 外の版(26・27 など)を本番で使っているなら、更新計画の有無を「中」で報告。「LTS かどうか」より「使っている提供元(Oracle / Temurin / Corretto など)の無償更新が続いているか」で判断する。Oracle JDK 21 は 2026-10 の CPU 以降、更新が OTN ライセンスでの提供になると案内されている(無償利用の条件が変わる。他の提供元のビルドは別)。
- 新しい言語機能を勧めるときは「版を上げる判断が別に要る」と書く。版ごとの機能は openjdk.org の JEP で確かめる(WebSearch は無いので URL を直接当たる)。

## 1. 言語と API の使い方(版に応じて)
- 21 以上: record・sealed・switch のパターンマッチ・仮想スレッド(JEP 444)が使える。データの入れ物に可変クラスを新規に書いていないか、`instanceof` + キャストの連鎖が switch で書けないか(勧めるのは「低」)。
- 25 以上: コンパクトなソースファイルと `void main()`(JEP 512)はスクリプト用途。本番コードに混ぜていないか。
- 24 以上: Security Manager は恒久的に無効(JEP 486)。`-Djava.security.manager` の起動オプションがあると JVM が起動しない。`System.setSecurityManager` は呼んだ時点で `UnsupportedOperationException`。ポリシーファイルによる権限制限は**失敗せずに効かなくなる**(静かに保護が消える)ので、それを前提にしていた防御には代替手段が要る → 「高」。
- 非推奨 API(`Thread.stop`、`finalize`、`Date` / `Calendar` の新規利用より `java.time`)。

## 2. 例外と資源
- `catch (Exception e) {}` の握りつぶし、ログだけして続行、`e.printStackTrace()`。
- `try-with-resources` を使っていない `InputStream` / `Connection` / `ExecutorService`。
- 例外メッセージや文字列結合でログに個人情報・秘密情報が乗っていないか。

## 3. 並行処理
- 共有の可変状態(`HashMap` を複数スレッドで更新、`SimpleDateFormat` の共有)。
- 仮想スレッドを使うなら、長い `synchronized` 区間や `ThreadLocal` 前提の設計(スレッド数が増える前提に合わない)。
- `ExecutorService` の shutdown 漏れ、`CompletableFuture` の例外の取りこぼし。

## 4. null と等価性
- `Optional` を引数やフィールドに使っていないか(戻り値用)。`Optional.get()` を確認なしに呼んでいないか。
- `equals` / `hashCode` の対(特に Map / Set のキー)。record なら自動生成される。
- JSpecify などの null 注釈があるプロジェクトでは、注釈と実装が一致しているか。

## 5. 依存
- 既知の脆弱性(OWASP Dependency-Check などの結果があれば読む。実行は CI に任せる)。
- 同じライブラリの版の重複(Maven の `dependency:tree`)。

## 報告の形式
- `[高/中/低] ファイル:行 — 何が問題か — 根拠(JEP 番号 / 公式ページ名 / コンパイラ出力) — 直し方`
- 高: 資源リーク・例外の握りつぶしで失敗が見えない・秘密情報のログ出力・JDK 24 以上で Security Manager のポリシー前提の防御。中: 無償更新が終わった版・共有可変状態。低: 新しい構文への書き換え提案。
- 最後に「対象 JDK の版」「見た範囲 / 見ていない範囲」。

## 確認する公式ページ
- https://openjdk.org/projects/jdk/ (GA 日の一覧)
- https://www.oracle.com/java/technologies/java-se-support-roadmap.html (LTS)
- https://openjdk.org/jeps/444 (仮想スレッド、21)
- https://openjdk.org/jeps/486 (Security Manager の恒久無効化、24)
- https://openjdk.org/jeps/512 (コンパクトなソースファイル、25)

#!/bin/bash
# SessionStart: 実行環境を確かめ、Claude に今の状況を伝える(サンプル)
# - SessionStart は止められない(警告を出すだけ)。止めたい条件は PreToolUse か permissions で。
input=$(cat)

warn=""
[ "$CLAUDE_CODE_USE_BEDROCK" = "1" ] || warn="$warn CLAUDE_CODE_USE_BEDROCK が 1 ではありません。"
[ "$ANTHROPIC_BEDROCK_REGION_PREFIX" = "jp" ] || warn="$warn ANTHROPIC_BEDROCK_REGION_PREFIX が jp ではありません(国内処理の約束)。"
[ "$AWS_REGION" = "ap-northeast-1" ] || warn="$warn AWS_REGION が ap-northeast-1 ではありません。"

branch=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "(git なし)")
dirty=$(git status --porcelain 2>/dev/null | wc -l | tr -d ' ')
ctx="現在のブランチ: ${branch}。未コミットの変更: ${dirty} 件。推論先: Bedrock(リージョン ${AWS_REGION:-未設定}、接頭辞 ${ANTHROPIC_BEDROCK_REGION_PREFIX:-未設定})。本番環境への適用は人が行う決まりです。"

# additionalContext は Claude が読む。systemMessage は人に見える警告。
jq -n --arg ctx "$ctx" --arg warn "$warn" '
  {hookSpecificOutput: {hookEventName: "SessionStart", additionalContext: $ctx}}
  + (if $warn != "" then {systemMessage: ("環境の確認:" + $warn)} else {} end)'
exit 0

#!/bin/bash
# UserPromptSubmit: 個人情報らしき文字列を含む依頼を送る前に止める(サンプル)
# - 正規表現は雑に広く取ってある。誤検知前提で、理由を表示して人に直してもらう。
# - @ で添付したファイルの中身や、Claude がツールで読むファイルは検査しない(別の層で守る)。
# - 止めても手元の履歴やトランスクリプトには残る(公式の注意)。
input=$(cat)
prompt=$(jq -r '.prompt // ""' <<<"$input")

hits=""
if grep -Eq '(^|[^0-9])[0-9]{4}[ -]?[0-9]{4}[ -]?[0-9]{4}[ -]?[0-9]{4}([^0-9]|$)' <<<"$prompt"; then
  hits="$hits カード番号らしき16桁;"
elif grep -Eq '(^|[^0-9])[0-9]{4}[ -]?[0-9]{4}[ -]?[0-9]{4}([^0-9]|$)' <<<"$prompt"; then
  hits="$hits マイナンバーらしき12桁;"
fi
n=$(grep -Eo '[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}' <<<"$prompt" | wc -l | tr -d ' ')
[ "$n" -ge 3 ] && hits="$hits メールアドレス ${n} 件;"
grep -Eq '(AKIA|ASIA)[A-Z0-9]{16}' <<<"$prompt" && hits="$hits AWS のアクセスキーらしき文字列;"

if [ -n "$hits" ]; then
  jq -n --arg r "個人情報・秘密情報らしき文字列を検出したため送信を止めました:${hits} 伏せ字にするか ID に置き換えて再送してください。" \
    '{decision: "block", reason: $r,
      hookSpecificOutput: {hookEventName: "UserPromptSubmit", suppressOriginalPrompt: true}}'
fi
exit 0

#!/bin/bash
# PreToolUse(Bash): 取り返しのつかない操作と、国内処理の約束に反する操作を止める(サンプル)
# - フックの判定は「最善努力」。絶対に通したくないものは permissions.deny に書く(公式の注意)。
# - deny は止める。ask は人に確認を出す(auto mode でも黙って通らない)。
input=$(cat)
cmd=$(jq -r '.tool_input.command // ""' <<<"$input")

deny() { jq -n --arg r "$1" '{hookSpecificOutput: {hookEventName: "PreToolUse", permissionDecision: "deny", permissionDecisionReason: $r}}'; exit 0; }
ask()  { jq -n --arg r "$1" '{hookSpecificOutput: {hookEventName: "PreToolUse", permissionDecision: "ask",  permissionDecisionReason: $r}}'; exit 0; }

# 1. 取り返しのつかない操作
grep -Eq '(^|[;&|[:space:]])rm[[:space:]]+-[a-zA-Z]*(rf|fr)' <<<"$cmd" && deny "rm -rf は使わない決まりです。削除は人が行います。"
grep -Eq 'git[[:space:]]+push[^|;&]*(--force|-f)([[:space:]]|$)' <<<"$cmd" && deny "force push は禁止です。"
grep -Eq 'aws[[:space:]][^|;&]*(delete-|terminate-|deregister-|remove-)' <<<"$cmd" && ask "AWS のリソースを消す操作です。本番は人が行う決まりですが、進めますか。"

# 2. 国内処理の約束(東京・大阪以外のリージョン、jp. 以外の推論プロファイル)
region=$(grep -Eo -- '--region[ =]+[a-z0-9-]+' <<<"$cmd" | head -1 | awk '{print $NF}' | sed 's/.*=//')
if [ -n "$region" ] && [ "$region" != "ap-northeast-1" ] && [ "$region" != "ap-northeast-3" ]; then
  ask "東京・大阪以外のリージョン(${region})を指定しています。国内処理の約束に反しませんか。"
fi
grep -Eq '(^|[^a-z.])(global|us|eu|au|in|apac)\.anthropic\.' <<<"$cmd" && deny "jp. 以外の推論プロファイル(海外で処理)を指定しています。国内処理の約束に反します。"

exit 0

#!/bin/bash
# PreToolUse(Edit|Write): 本番の構成や CI 定義は確認を出し、ロックファイルの手編集は止める(サンプル)
# - file_path は絶対パスで来る。Windows は \ 区切りなので / に直してから比べる(公式の注意)。
input=$(cat)
f=$(jq -r '.tool_input.file_path // ""' <<<"$input")
f="${f//\\//}"

deny() { jq -n --arg r "$1" '{hookSpecificOutput: {hookEventName: "PreToolUse", permissionDecision: "deny", permissionDecisionReason: $r}}'; exit 0; }
ask()  { jq -n --arg r "$1" '{hookSpecificOutput: {hookEventName: "PreToolUse", permissionDecision: "ask",  permissionDecisionReason: $r}}'; exit 0; }

case "$f" in
  */package-lock.json|*/pnpm-lock.yaml|*/yarn.lock)
    deny "ロックファイルは手で編集しません。npm install などのコマンドで更新してください。" ;;
  */infra/prod/*|*/.github/workflows/*|*/buildspec*.yml|*/managed-settings.json)
    ask "本番の構成・CI 定義・管理設定(${f})の変更です。レビュー担当に見せる前提で進めますか。" ;;
esac
exit 0

#!/bin/bash
# PostToolUse(Edit|Write): 保存したファイルを整形する。失敗したら Claude に伝える(サンプル)
# - PostToolUse はもう実行済みなので止められない。additionalContext で次の行動を促す。
input=$(cat)
f=$(jq -r '.tool_input.file_path // ""' <<<"$input")
case "$f" in
  *.ts|*.tsx|*.js|*.jsx|*.json|*.css|*.md) ;;
  *) exit 0 ;;
esac
cd "${CLAUDE_PROJECT_DIR:-.}" || exit 0
[ -x node_modules/.bin/prettier ] || exit 0

if ! out=$(node_modules/.bin/prettier --write "$f" 2>&1); then
  jq -n --arg o "$out" '{hookSpecificOutput: {hookEventName: "PostToolUse", additionalContext: ("整形(prettier)に失敗しました。構文を確認してください: " + $o)}}'
fi
exit 0

#!/bin/bash
# PostToolUse(Bash): テストコマンドが走ったことを、このセッションの印として残す(サンプル)
# - stop-check.sh と対で使う。記録するのは「走らせた」事実だけで、合否は Claude の報告で確認する。
input=$(cat)
cmd=$(jq -r '.tool_input.command // ""' <<<"$input")
grep -Eq '(^|[;&|[:space:]])((npm|pnpm|yarn)[[:space:]]+(run[[:space:]]+)?test|pytest|go[[:space:]]+test|cargo[[:space:]]+test|mvn[[:space:]]+test|gradle[[:space:]]+test)' <<<"$cmd" || exit 0

dir="${CLAUDE_PROJECT_DIR:-.}/.claude/state"
mkdir -p "$dir"
jq -r '.session_id' <<<"$input" > "$dir/last-test-session"
exit 0

#!/bin/bash
# Stop: コードを変えたのにテストを走らせていなければ、1回だけ続行させる(サンプル)
# - stop_hook_active が true のとき(すでにこのフックで続行した後)は止めない。無限ループ防止。
# - Claude Code 側にも連続8回の上限がある。
input=$(cat)
[ "$(jq -r '.stop_hook_active // false' <<<"$input")" = "true" ] && exit 0

root="${CLAUDE_PROJECT_DIR:-.}"
changed=$(cd "$root" && git status --porcelain -- '*.ts' '*.tsx' '*.js' '*.jsx' '*.py' '*.go' '*.java' '*.rs' 2>/dev/null | wc -l | tr -d ' ')
[ "$changed" = "0" ] && exit 0

sid=$(jq -r '.session_id' <<<"$input")
marker="$root/.claude/state/last-test-session"
if [ ! -f "$marker" ] || [ "$(cat "$marker")" != "$sid" ]; then
  jq -n '{decision: "block", reason: "コードを変更していますが、このセッションでテストコマンドが実行されていません。テストを実行して結果(成功・失敗)を報告してから終えてください。実行できない理由があるなら、その理由を報告して終えてください。"}'
fi
exit 0

#!/bin/bash
# PostToolUse(全ツール): 何をしたかを JSONL で手元に残す(サンプル)
# - 中央集約は OTEL(運用の段取りの節)に任せ、ここはリポジトリ単位の作業記録。
# - .claude/audit/ と .claude/state/ は .gitignore に入れる。
input=$(cat)
dir="${CLAUDE_PROJECT_DIR:-.}/.claude/audit"
mkdir -p "$dir"
jq -c '{
  t: (now | todate),
  session: .session_id,
  agent: (.agent_type // "main"),
  tool: .tool_name,
  target: (.tool_input.command // .tool_input.file_path // .tool_input.url // .tool_input.pattern // null),
  ms: (.duration_ms // null)
}' <<<"$input" >> "$dir/$(date +%Y-%m-%d).jsonl"
exit 0