8層チェック表
Day1 の冒頭と Day2 の最後に、同じ表を2回付けます。
自動化の層を下から積み上げた8段です。Day1 の冒頭に現在地を1回塗り、Day2 の最後にもう一度塗ります。2回の差が2日間の成果です。
塗り方は3段階だけにしてください。細かく刻むと2回目の比較ができなくなります。
3段階の決め方
- 未 置いていない
- 一部 置いてあるが、定義どおりには効いていない
- 済 効いていることを機械で確かめられる
「効いている」の判定は人の記憶ではなく、各層の確認方法の欄に書いたコマンドか画面で決めます。D2 の core.md の語彙で言えば、[A] で守っているものは「一部」、[M] に移ったものが「済」です。
対象のハーネスは1人1式に絞ってください。D2 と smart3pm の両方を持っている方は、2日間で育てるほうを先に決めてから塗ります。
8層の現在地
claude -p)塗り終えた後の記入欄
Day1 の記入が終わったら、次の2行だけ書いてください。Day2 の最後に同じ欄をもう一度書き、行が動いたかを見ます。
| 記入欄 | Day1 | Day2 |
|---|---|---|
| 「済」が付いた層の番号 | ||
| 次に埋めると一番効く層と、その理由 |
成熟度の表記と第7層の位置づけ
成熟度の欄は 2026-09-10 時点の公式ドキュメントの表記です。GA は GitHub Actions 連携までを含み、GitLab CI/CD 連携は beta、Agent Teams は experimental、Routines は research preview と書かれています。Routines は claude.ai ログイン前提で、API キー運用では /schedule が出ません。スケジューラを GitLab 側に置くのはこのためです。
CI の導入は新機能の追加ではありません。いまは機械強制のタグが、エージェントの完了報告に載ることで担保されていると伺っています。第7層は、その担保をパイプラインの実行記録に置き直す作業です。第7層に印が付くまで、第1層から第6層の「済」はすべて自己申告の上に乗っています。
出典: https://code.claude.com/docs/en/headless / https://code.claude.com/docs/en/gitlab-ci-cd
委譲判定シート
ハンズオン1とハンズオン2で、AI の指摘を4分類に仕分けます。
AI が出した指摘を、4分類のどれに入れるかを決めるシートです。ハンズオン1(Issue #1)とハンズオン2(Issue #2・#3)で使います。
指摘を全部直すと、5行の修正に半日かかります。全部見送ると、レビューを回す意味がなくなります。この2つの間に線を引くために、指摘ごとに3軸を先に決めてから分類します。分類から入ると、その日の気分で線が動きます。
3軸の見るところ
| 軸 | 値 | 見るところ |
|---|---|---|
| 可逆性 | 戻せる / 戻しにくい / 戻せない | コードだけの変更は戻せます。DB のスキーマとデータ、外部連携、権限の変更は戻せません。コードを revert してもデータは戻りません |
| 機械検証 | CI で落ちる / テストを足せば落ちる / 人が読むしかない | 今の CI(lint-phpdev の 8.3、lint-phpver の 7.4、DB テスト、AI レビューのゲート)で落ちるかどうかです。「落ちるはず」ではなく、落ちたのを見たかどうかで書きます |
| 影響範囲 | 1ファイル内 / 同一機能 / 共通処理と複数機能 | app/libraries/ と app/core/ に触る指摘は、常に一番右です |
4分類の決め方
3軸を書いてから、次の順で当てはめます。上から順に見て、最初に当たったところで止めます。
- 可逆性が「戻せない」なら、機械検証の値に関わらず 要調査。人が読んでから決めます
- 機械検証が「CI で落ちる」なら 即修正。人が採否を議論する対象ではありません。議論した時点で工数が二重になります
- 影響範囲が「共通処理と複数機能」で、可逆性が「戻しにくい」なら 将来課題。この MR では直しません
- 指摘の前提がこのリポジトリの設計と食い違っているなら 意図した設計。理由を1行書いて
known_issues.mdに K 番号で登録します - 残りは 即修正 か 将来課題 を、この MR の目的に照らして選びます
「意図した設計」に入れたものは、次から同じ指摘が出ないように記録するところまでが1セットです。記録しないと、同じ判断を毎回の改修で繰り返します。小さな改修ほど指摘対応に時間がかかる原因の一つがここにあります。
記入例
| 欄 | 書き方 |
|---|---|
| 出どころ | 同一セッション |
| 指摘の要約 | estimate_ctl.php の customer_name が SQL 文字列に連結されていて、' OR '1'='1 で全件返る |
| 可逆性 | 戻せる |
| 機械検証 | テストを足せば落ちる |
| 影響範囲 | 同一機能 |
| 分類 | 即修正 |
| 次の一手 | db_select の第2引数へプレースホルダで渡し、検索のテストを1本足す |
指摘10件の記入欄
出どころは「同一セッション」「履歴を切った別セッション」「観点別のレビュアー」「CI」のどれかを書きます。同じ指摘が2か所から出たときは、両方に行を立てずに1行にまとめ、出どころを2つ並べてください。重なった数がそのまま、レビューを何本回すかの判断材料になります。
集計欄
下の数は、上の記入欄から自動で数えています。
| 項目 | 件数 |
|---|---|
| 指摘の総数 | 0 |
| 即修正 | 0 |
| 要調査 | 0 |
| 将来課題 | 0 |
| 意図した設計 | 0 |
| このうち CI で落ちたもの | 0 |
一番下の行が大きいほど、人が読む量を減らせます。人が読む量を減らす手は「基準表を厳しくする」ではなく「CI に落とせるものを CI へ移す」です。
計測表 Day1 Day2
演習中に自分で数える欄です。その場で記入します。
演習中に自分で数える欄です。あとから思い出して埋めることはできないので、その場で書いてください。
数字を並べる目的は、レビューの置き方を自分の数字で選べるようにすることです。論文の数字ではなく、自分の MR で何が起きたかを見ます。
Day1 3通りのレビュー
ハンズオン1の Step 4 で、同じ差分に3通りのレビューを当てます。順番は固定で、上の行から読み手の持っている情報が1つずつ減ります。4行目の CI の ai_review は Step 6 で MR のコメントを見てから埋めます。動かなかったときは「未実施」と書きます。
| 読ませ方 | 指摘の総数 | うち P0 と P1 | 所要時間(分) | 採用・見送り |
|---|---|---|---|---|
| 1 実装したセッションでそのまま依頼 | ||||
| 2 review-other サブエージェント | ||||
| 3 履歴を切った新しい会話 | ||||
| 4 CI の ai_review |
「採用・見送り」は、Step 5 で委譲判定シートに仕分けたあとに「採用 1・見送り 3」の形で書きます。採用は「即修正」、見送りは「将来課題」と「意図した設計」に入れた件数です。
4行の並びの意味
1から2で実装の履歴が外れ、2から3で役割と観点の定義が外れます。どちらの段で指摘が変わったかを見ると、効いていたのが履歴なのか定義なのかが分かれます。4の CI の ai_review は、人がその場で足す言葉が一切入らない読み方です。
件数だけを比べると、P2 と P3 を多く出す読み手が多く見えます。比べるときは「うち P0 と P1」の列を使ってください。
書き終えてから答える欄
履歴を捨てた別セッションのほうが自己レビューより当たる、という測定結果があります(Cross-Context Review で F1 28.6 対 24.6、自己レビューの2回目は 21.7)。自分の数字がこれと違う向きに出たら、そのまま書いてください。1件の MR で逆転することは普通に起きます。数字が一致しなかったことより、「履歴を切るだけで指摘が変わる」ほうが持ち帰る事実です。
Day1 委譲判定の集計
委譲判定シートの集計欄から転記します。
| 項目 | 件数 |
|---|---|
| 指摘の総数 | |
| 即修正 | |
| 要調査 | |
| 将来課題 | |
| 意図した設計 | |
| CI で落ちたもの | |
| 指摘の仕分けにかかった時間(分) |
Day2 検出率
ハンズオン2の Step 2 で数えた値を、レビュアーごとに書きます。仕込み欠陥の件数は、Issue #2 と #3 の「現状」節に挙がっている欠陥を足した数です。何を分母に入れたかも余白に残してください。
| レビュアー | 仕込み欠陥の件数 | 当てた件数 | 指摘の総数 | 検出率 | ノイズ率 |
|---|---|---|---|---|---|
| security-reviewer | |||||
| spec-reviewer | |||||
| test-gap-reviewer | |||||
| 3本の合計(重複を除く) |
検出率は 当てた件数 ÷ 仕込み欠陥の件数、ノイズ率は 仕込み欠陥以外の指摘 ÷ 指摘の総数 です。指摘を絞って動くのはノイズ率のほうで、検出率は動かないはずです。両方下がったら Do not report に入れすぎです。
テスト有無の比較
ハンズオン2 の Step 3 補足で、手順10 で入れた日付の形の判定を1行だけ外したコミットを push し、パイプラインで何が赤になるかを見ます。
| 項目 | 記入欄 |
|---|---|
| 赤になったジョブとテスト | |
| 緑のままだったジョブ | |
| 足したテストが無かったら、どこで気づいたか | |
戻したコミット(git revert の結果) |
Day2 夜間ループ
ハンズオン3で、1回目がどこで止まったかを記録します。止まらずに完走したら、その旨を書いてください。
--max-turns の上限に当たったか)止まった箇所の候補
当てはまるものに印を付けてから、上の欄を埋めてください。
最後に1枚書く欄
自社ハーネス診断シート
5層30項目の点検表です。プチ演習7で使います。
自分のハーネスが、5層のどこまで届いているかを1枚で見るための表です。点数を付ける表ではありません。空いている層を見つけて、次に何を足すかを決めるために使います。
対象は1人1式に絞ってください。複数のリポジトリを持っている方は、これから育てるほうを先に決めてから埋めます。
埋め方
判定は3つだけです。細かく刻むと、後で見返したときに比べられなくなります。
3つの判定の分け方
- ある 効いていることを、その項目の確かめ方で確認した
- 一部 置いてあるが、定義どおりには効いていない。または一部の環境でしか効かない
- 無い 置いていない
先に書く予想
点検表に進む前に、予想を書いてください。埋め終わったら、予想と結果の差を見ます。差が出た場所が、いちばん危ない場所です。
第1層 文脈
AI に読ませている決まりの層です。効き目は一番弱く、置き換えの対象を見つけるために点検します。
第2層 権限
ツールの呼び出しを、通す・確認する・止めるの3つに仕分ける層です。
第3層 フック
実行の直前に割り込み、コマンドの中身まで見る層です。ここが一番厚くできます。
第4層 CI
手元の設定と無関係に、提出のときに動く層です。手元を外した人にも効きます。
第5層 リポジトリ保護
手元の設定を全部外した人にも効く層です。
持ち帰る3行
埋め終わったら、3行だけ書いてください。ここが持ち帰るものです。
なお、第1層に「無い」が並んでいても、第3層と第4層が埋まっているなら危険な状態ではありません。逆に、第1層だけが埋まっていて他が空いている状態は、守っているつもりで何も止まっていない状態です。層の順番に埋める必要はありません。
持ち帰り台帳
Day1 の最後に7行、Day2 の最後に10行を埋めます。
2日間で作ったファイルを、自社ハーネスのどこに置くかを決めるための台帳です。Day1 の最後に7行、Day2 の最後に10行、合わせて17点を埋めます。
演習で作ったものは演習リポジトリ(dl-training-app)の中にあります。そのままでは自社では動きません。この台帳の役目は、置き場所と担当と期日を1行ずつ決めて、研修が終わった翌週に手が止まらないようにすることです。
書き方と、移すときの分岐
- 置き場所はパスで書きます。「ハーネスに入れる」では翌週の自分が探せません
- D2 と smart3pm のどちらか片方しか使わない行は、使わないほうに「対象外」と書きます。空欄のままにしないでください
- 担当は名字を書きます。「チーム」は担当ではありません
- 反映日は日付を入れます。未定のものは、いつ決めるかの日付を入れます
D2 は PowerShell 5.1 で、コードと文字列を ASCII のみに保つ約束があります。smart3pm は bash が正です。同じ目的のガードが2言語で二重に実装されている状態で、統一の時期はまだ決まっていないと伺っています。
演習では ps1 と sh の両方を配っています。片方だけを持ち帰るか、両方を置いて片方を正とするかは、この台帳を埋めるときに決めてください。決めた結果を「置き場所」の欄に残すのが一番速い記録です。
Day1
review-light.md / review-full.md)model / effortLevel / maxEffortLevel)Bash(...) と PowerShell(...) の対)と ask 3本.env と認証情報の読み取り)block-destructive(ps1 / sh)と hooks/tests/cases.json のケースagents/review-other.md)と MR テンプレの「AI レビュー結果」欄D1-2 の maxEffortLevel は v2.1.267 で追加されたキーです。持ち帰り先の Claude Code が古いと無視されます。反映日を決める前に、Claude Desktop の設定画面で Claude Code の版を確認してください。CLI 版を入れている環境なら claude --version でも見られます。
Day2
check-phpver(ps1 / sh)と cases.json の追加ケースREVIEW.md(自社版初版)と AGENTS.md の ## Code Review Rulesknown_issues.mdreview.schema.json と gate.ps1 / gate.sh、レビューを2ジョブに分けた .gitlab-ci.ymlstop-gate(ps1 / sh)nightly_implement、pipeline schedule、skills/implement-issue、止め金を書いた settings.json)60_理想的なハーネスの雛形/template/ を自社リポジトリへ置いたもの)D2-4 の known_issues は、リリースレビュー側で既に動いているものをコードレビュー側へ写す作業です。新しく作る話ではありません。D2-8 から D2-10 は、理想的なハーネスの雛形の回(プチ演習7・8)で手元に残るものです。D2-10 は1層だけ書き換えたファイルなので、残りの層は反映日の欄に「次に直す層」として日付を入れてください。17点の数え方は、1点が「1つの置き先に1回で置ける単位」です。観点別サブエージェント3本や deny の10本は、それぞれ1点に数えます。
研修後の宿題
自社ハーネスの側に残っていて、2日間では触らなかった箇所です。担当と期日だけ決めてから解散してください。
| 項目 | 担当 | 期日 |
|---|---|---|
| フックのテストがある側とない側の非対称の解消(D2 は回帰テストあり、smart3pm は4本のみ) | ||
| フック自身の ASCII 制約の機械検査、または pwsh 7 への移行 | ||
| PowerShell と bash の二重運用をいつ片方に寄せるかの決定 | ||
| 作業指示書の Notion への反映 |
社内展開ガイド A4雛形
Day2 の終わりに、この雛形の上で A4 1枚を書き上げます。
Day2 の終わりに、この雛形の上で A4 1枚を書きます。読む相手は、2日間の研修に出ていない運用メンバーです。
書けたかどうかの判定は1つです。作成者以外の1名が、このガイドだけを見て設定を1つ入れ直せること。入れ直せなければ、粒度が足りていません。
記入例
| 節 | 記入例 |
|---|---|
| 1 何を | .claude/hooks/check-phpver.ps1 は、PHP ファイルを編集した直後に走り、7.4 で動かない構文があれば AI に差し戻す |
| 2 どこに | check-phpver.ps1 を D2/.claude/hooks/ に置き、.claude/settings.json の hooks.PostToolUse に matcher Edit|Write で登録する |
| 3 なぜ | CLAUDE.md に書いた制約は数ターンで薄れ、match 式や str_contains() が混入する。気づくのが push した後の CI の lint-phpver になり、str_contains() のように構文としては正しいものは、手元の構文チェックでは見つからない |
| 4 戻し方 | [check-phpver] で始まるメッセージが出ていたら、指摘された行を代替の書き方に直す。緊急で止めるなら settings.json の該当ブロックだけを外す。ファイルは消さない |
| 6 まだ入れていないもの | OS のサンドボックスは Windows では Seatbelt も bubblewrap も動かない。守りは deny とフックの2層で、3層目は無い |
1. 何を
追加したものを、ファイル名で書きます。機能名では探せません。
| ファイル | 何をするもの |
|---|---|
2. どこに
置き場所と、効かせるための登録先です。ファイルを置くだけでは動かないものが混ざっています。
| ファイル | 置き場所 | 登録先 |
|---|---|---|
3. なぜ
1行ずつ、入れなかったときに何が起きるかを書きます。「品質向上のため」は理由になりません。半年後に外す判断ができません。
| ファイル | 入れなかったときに起きること |
|---|---|
4. 壊れた時の戻し方
止まったときの見分け方と、戻す手順です。ここが書けていないと、最初のトラブルで全部が外されます。
| 症状 | 見分け方 | 戻し方 |
|---|---|---|
止め方を「ファイルを消す」にしないでください。消すと、次に入れ直す人が最初から作ります。
5. 担当と連絡先
6. まだ入れていないもの
入れなかったものを書いておくと、次に足す人が同じ検討を繰り返しません。
| 項目 | 入れなかった理由 |
|---|---|
書き終えた後の確認
効果測定4指標表
研修後に測る4指標と、研修前8週との突き合わせ方です。
レビュー工数を1つの数字で追うと、うまくいきません。工数は測る人の記憶に依存し、改修の大きさでばらつき、比較にならない数字が残ります。
代わりに、GitLab の MR データから機械的に取れる4つに限定します。人が入力する欄を1つだけ残し、残り3つはデータから取ります。入力欄が増えるほど、3か月後には誰も書かなくなります。
4指標
| No | 指標 | 定義 | 取り方 | 人の入力 |
|---|---|---|---|---|
| 1 | MR あたりの AI 指摘件数と採用率 | 1つの MR で AI が出した指摘の件数と、そのうち対応した件数の割合 | 指摘件数は AI レビュージョブの findings.json を artifact に残して数えます。採用率は委譲判定シートの「即修正」の件数を分子にします | 採否だけ |
| 2 | 人が採否を判断した件数 | 指摘のうち、CI で自動的に落ちたものを除いた件数 | 指摘の総数から、ゲートジョブが落とした P0 と P1 の件数を引きます | なし |
| 3 | ゲートで止まった MR の割合 | ゲートジョブが失敗した MR の数 ÷ 全 MR の数 | パイプラインのジョブ結果から数えます | なし |
| 4 | マージまでの時間と手戻り MR 率 | MR 作成からマージまでの時間の中央値と、マージ後に同じ箇所を直す MR が出た割合 | created_at と merged_at の差。手戻りは同じファイルに触る後続 MR を数えます | なし |
指摘2が、回答書に書かれた課題に一番近い数字です。「品質は上がったが工数削減は限定的」は、指標2が減らないまま指標1が増えている状態です。指標2を減らす手は、基準表を厳しくすることではなく、機械で判定できる指摘を CI 側へ移すことです。指標3が上がって指標2が下がれば、狙いどおりに動いています。
GitLab から取るエンドポイント
GitLab の REST API から取ります。エンドポイントは GitLab の版で増減するので、使う前に自社インスタンスの版の API ドキュメントで1本ずつ引いてください。
| 取りたいもの | エンドポイント | 主なクエリ |
|---|---|---|
| MR の一覧と作成・マージ日時 | GET /projects/:id/merge_requests | state=merged、created_after、created_before、per_page |
| MR ごとのパイプライン | GET /projects/:id/merge_requests/:iid/pipelines | |
| ジョブの成否 | GET /projects/:id/pipelines/:pipeline_id/jobs | scope=failed |
ジョブの artifact(findings.json) | GET /projects/:id/jobs/:job_id/artifacts/:artifact_path | |
| MR で変更したファイル | GET /projects/:id/merge_requests/:iid/changes | 手戻りの判定に使います |
認証は api スコープのプロジェクトアクセストークンです。masked variable に置きます。集計の単位は週です。日次にすると改修の粒度のばらつきに埋もれます。月次にすると、施策を入れてから効果を見るまでが遅すぎます。
出典: https://docs.gitlab.com/ci/pipelines/schedules/ / https://docs.gitlab.com/user/project/settings/project_access_tokens/
ビフォー値との突き合わせ
ビフォーは研修前の8週分です。突き合わせの前に、次の3つを揃えてください。揃っていない数字を並べると、施策の効果ではなく期間の性質を見ることになります。決めたものに印を付けます。
ビフォーとアフターの比較
| 指標 | ビフォー8週(研修前) | アフター4週(研修後) | 差 |
|---|---|---|---|
| 1 MR あたりの AI 指摘件数(中央値) | |||
| 指摘の採用率 | |||
| 人が採否を判断した件数(1 MR あたり) | |||
| ゲートで止まった MR の割合 | |||
| マージまでの時間(中央値) | |||
| 手戻り MR 率 |
ビフォー側にゲートジョブは存在しないので、4行目のビフォーは 0% です。0% から上がることが悪い変化ではありません。止まった分だけ、人の目を通らずに済んだということです。
アフターの初回値
ハンズオン2で数える検出率(当てた件数 ÷ 仕込み欠陥の件数)とノイズ率(仕込み欠陥以外の指摘 ÷ 指摘の総数)を、アフター側の初回値として置きます。既知の欠陥が入ったコードに対して、レビューが当たるかを測る形です。過去の改修10本を使ったバックテストの代わりになります。patterns.md のタグ集計は補助です。タグを付けるのは人なので、主指標には置きません。
ビフォー値を正確に取るのは難しいという話が先方から出ています。8週分が揃わないときは、4指標の表だけを渡して、ハンズオン2の検出率を唯一の実測値として扱ってください。揃わない数字を埋めた表を作るより、実測が1つある表のほうが後で使えます。
保存と書き出し
記入した内容はこのブラウザに自動で残ります。持ち出すときや共有するときは、下の形式で保存してください。
| 形式 | 使いどころ |
|---|---|
| md | 7種を Markdown の見出しと表で書き出します。社内のリポジトリやメモにそのまま貼れます |
| 画面の様式のまま残します。印刷画面が開くので、送信先を「PDF に保存」にしてください | |
| 入力済み HTML | 記入内容ごと1ファイルに保存します。開き直すと続きから書けて、この端末の記入とは混ざりません |
| xlsx | 7種をシート7枚に分けたブックです。集計や表計算で使います |
PDF は用紙 A4 縦、倍率は既定のままで保存してください。7種がシートごとに改ページされ、記入した文字は欄の中で折り返して全部出ます。ファイル名は DLive_当日のシート_<日付> で始まります。
ダウンロードが通らない端末では、テキストに書き出してコピーしてください。