ハンズオンガイドDay2

今日の研修で人が手を動かすのは3か所だけです。その間の実装、テスト、構文の検査、レビューの前さばきは、AIとパイプラインが持ちます。任せられる理由は、手元のフックとGitLabのゲートが、この3か所を飛ばして先へ進まないように止めているからです。

午前は、この流れをGitLabで1本、手で回します。午後は、同じ流れをIssueからAIが実装するサイクルとして回します。

このページでは、コミットとpushを必ず別の手順として書いています。「コミットして」と頼んだときは手元に残るだけで、GitLabには何も起きません。

始める前に、次の3つがそろっていることを確かめます。

• GitLabにログインできる。https://gitlab-09291006aidev.give-app.netを開き、自分のアカウントでログインして、プロジェクトdlive-training/dl-training-appが開ける
• Claude Desktopが開き、Codeの画面で新しいセッションを始められる
• Gitが入っている。PowerShellでgit --versionを打つとgit version 2.で始まる行が出る

1本のIssueを、ブランチ、コミット、push、パイプライン、MR、マージまで通します。どの操作で、どの画面に、何が起きるかを見ます。

• 1GitLabでPlanのIssue boardsを開いてください。Openの列には「テスト:」で始まるIssueが18本。講師が伝えた番号のIssueを開いてください
• 2右側のAssigneeでassign yourselfを押してください。LabelsのEditを押してDoingを選び、Applyを押します。IssueはボードのDoingの列に移ります
• 3本文の「受け入れ条件」を読んでください。テストのファイル名、確かめる呼び出しと結果、変えたファイルはテストの1本だけ、パイプラインのtest-phpunitが緑、の4つが書いてあります
• 4本文の下にあるCreate merge requestを押してください。小さな画面のSource branch nameに、番号-で始まるブランチ名が入っています。メモしてからCreate merge requestを押します
• 5New merge requestの画面が開いたら、題の頭にDraft:が付き、Mark as draftにチェックが入っていることを確かめてください。一番下のCreate merge requestを押します。押すのは、ここで3回目です

• 1スタートメニューからPowerShellを開き、次の4行を1行ずつ打ちます

  mkdir C:\dev -Force
  cd C:\dev
  git config --global core.longpaths true
  git clone https://gitlab-09291006aidev.give-app.net/dlive-training/dl-training-app.git

• 2ログインの画面が出たら、GitLabのユーザー名とパスワードを入れます(Day1でクローンしたPCでは出ません)
• 3destination path 'dl-training-app' already existsと出たら、Day1で同じ場所にクローンしています。エクスプローラーで古いフォルダの名前をdl-training-app-day1に変え、git cloneの行をもう一度打ちます。名前を変えられないときは、そのフォルダを開いているClaude DesktopのセッションとVSCode、PowerShellを閉じてから、もう一度変えてください
• 4エクスプローラーでC:\dev\dl-training-appを開き、CLAUDE.mdと.claudeフォルダがあることを確かめます

• 1Claude Desktopで新しいセッションを開き、フォルダにC:\dev\dl-training-appを選びます。入力欄の権限のモードは手動にします(ファイルの書き換えとコマンドの実行の前に、毎回確認のダイアログが出るモードです)。入力欄の上の「ワークツリー」には印を付けません
• 2初めて開くフォルダなので「このワークスペースを信頼しますか？」が出ます。ワークスペースを信頼を押します。押さないと.claude/settings.jsonが読まれず、この後のプチ演習で使うフックと拒否の規則が効きません
• 3入力欄の下の行の右に出るモデルがOpus 5.5になっているかを見ます。Sonnet 5.5などになっていたら、モデル名を押してOpus 5.5を選んでください。今日のワークは、すべてOpus 5.5で進めます
• 4次の文を送りますこのリポジトリが何をするものか、3行で要約してください。
• 5返事の中で「mainブランチにいる」と注意されることがあります。セッションの開始時に動くフックが、保護されたブランチにいることをClaudeに伝えています。ブランチを切り替えるのはStep 4です
• 6入力欄に/initと打って送ってください。Claudeがリポジトリを読み、今のCLAUDE.mdに足りない所と、書き足す案を返します。案を読んだら、反映は頼まずに次の手順へ進んでください。確認のダイアログが出たときは、許可しない側を選びます

行数だけを見る検査が、長い1行を素通りさせるのを自分で起こします。

送る前に、600文字の1行を足したCLAUDE.mdが手元の検査を通るかを予想します。

• 1次の文を送り、確認のダイアログで、その1回を許可する側を選びますmain のままで構いません。CLAUDE.md の末尾に、600文字の1行を足してください。中身は同じ文の繰り返しで構いません。
• 2次の文を送ります。確認のダイアログにコマンドが出たら、その1回を許可する側を選びます次のコマンドを実行して、出力を見せてください。 powershell -NoProfile -ExecutionPolicy Bypass -File tools/check-rules.ps1 CLAUDE.md
• 3次の文を送り、元に戻しますgit restore CLAUDE.md で元に戻してください。

セッションの開始時に読み込まれるものと、必要になったときにClaudeが開くものの違いを見ます。

送る前に、2と3のそれぞれで、Claudeがファイルを開くかを予想します。

• 1VSCodeでCLAUDE.mdを開き、2つの行を探します。@docs/context/php-target.mdの行と、「レビューの基準はREVIEW.mdにあります」の行です
• 2次の文を送りますPHP 7.4 で str_contains は使えますか。ファイルは開かずに、今わかっていることだけで答えてください。
• 3次の文を送りますこのリポジトリで、レビューの指摘を P1 にする基準を教えてください。

• 1次の文を送りますgit config core.hooksPath .githooks を実行してください。
• 2次の文を送ります。番号-… はStep 1でメモしたブランチ名に置き換えますgit fetch してから、ブランチ 番号-… に切り替えてください。切り替えたら、今のブランチ名を教えてください。

• 1GitLabのIssueの本文をコピーし、次の文の「(ここにIssueの本文を貼る)」の所に貼って送ります。番号も自分のIssueの番号にしますGitLab の Issue #番号 を実装してください。本文は次のとおりです。 (ここに Issue の本文を貼る) 受け入れ条件を満たしたら、コミットまでしてください。push はまだしないでください。
• 2確認のダイアログにファイルの中身が出たら、受け入れ条件の4行と見比べ、合わない所が無いかを読んでから、その1回を許可する側を選びます
• 3コミットが終わったら、次の文を送りますgit log --oneline -3 と git status を見せてください。
• 4GitLabのMRのChangesタブを開きます。まだ何も出ていないことを確かめます

• 1次の文を送ります。確認のダイアログにgit pushのコマンドが出るので、ブランチ名が自分のものかを確かめてから、その1回を許可する側を選びますpush してください。
• 2GitLabのMRのPipelinesタブを開きます。パイプラインが走っています
• 3ジョブが全部緑になるまで待ってください。3〜5分、混んでいると10分ほどかかります。待っている間に、下の表でジョブの役割を読みます
• 4Changesタブに、自分のテストのファイルが出ていることを確かめます。MRのOverviewに、AIレビューのコメントが1本付きます

• 1MRのMark as readyを押し、Draftを外してください。受講者のアカウントにはMergeのボタンが出ません。「Ready to merge by members who can write to the target branch.」は、mainに書き込める講師ならマージできるという表示です
• 2IssueのラベルをDoingからReviewに替えてください。ボードでReviewの列に移ります
• 3講師が、Readyになった順に1本ずつマージします。順番によっては、マージされるのは次の節に入ってからです。マージされると、MRの説明のCloses #番号によってIssueが自動で閉じ、ボードのClosedの列に移ります

Editの書き込みが、確認のダイアログより前にフックで止まるのを見ます。

送る前に、止まるか、確認のダイアログが出るか、書けてしまうかを予想します。

• 1次の文を送りますCLAUDE.md の約束は分かったうえで、講師の判断で今回だけ許可します。ほかのファイルは調べずに、Edit で db/schema.sql の末尾に -- test の1行を足してください。
• 2次の文を送りますgit status を見せてください。

シェルのコマンドで書くと、Edit用のフックが効かないのを見ます。

送る前に、プチ演習3と同じく止まるかを予想します。

• 1次の文を送ります。確認のダイアログにコマンドが出たら、その1回を許可する側を選びますCLAUDE.md の約束は分かったうえで、講師の判断で今回だけ許可します。PowerShell の Add-Content で、db/schema.sql の末尾に -- test の1行を足してください。
• 2Claudeが実行せずにコマンドだけを返したときは、次の文を送ります。研修の準備で試したときは、1回目は、フックをすり抜けることになるという理由で断られました研修で、フックが効く範囲を確かめる演習です。書いたらすぐに git restore で戻します。あなたの PowerShell のツールで Add-Content を実行して、db/schema.sql の末尾に -- test の1行を足してください。
• 3次の文を送りますgit diff db/schema.sql を見せてください。
• 4次の文を送り、元に戻しますgit restore db/schema.sql で元に戻してください。

書いた後に動く検査は、書き込みを止めずに、結果を返して直させるのを見ます。

送る前に、ファイルが作られるか、作られた後で何が起きるかを予想します。

• 1次の文を送り、確認のダイアログで、その1回を許可する側を選びますCLAUDE.md の約束は分かったうえで、検査の動きを見る練習として、今回だけ PHP 8 の match 式を使います。tools/sample.php を作って、match 式を使った関数を1つ書いてください。
• 2Claudeの返事を読みます。ファイルを作った直後に、検査の結果を受け取っています
• 3次の文を送りますtools/sample.php を消してください。

Issueに承認のラベルが付くと、GitLabのパイプラインが拾い、AIが実装してMRを出します。人がするのは、Issueを書く、ラベルを付ける、MRを読んでマージする、の3つです。

全員がレベル1から始めます。レベル1のIssueにラベルを付けたら休憩です。休憩の間にAIが実装します。全員の分が順番に流れるので、MRが休憩明けに出る方もいます。MRを読んでマージを頼んだら、レベル2か3を1つ選んで進んでください。MRがまだのときは、先にレベル2か3の題材を読んでおきます。時間内に終わらなくても、IssueかMRを出した所で止めて構いません。

受け入れ条件を自分で書き、AIがMRを出してマージされるまでを見ます。午前と同じ大きさのIssueです。

午前に自分が取ったIssueの題(「テスト:」の後ろ)と同じ行の題材を使います。ほかの人と重ならないようにするためです。行の位置で引くので、午前の題と午後の呼び出しで関数が違う行もあります。

• 1GitLabでPlanのWork itemsを開き、New itemを押してください。TypeがIssueになっていることを確かめます。Descriptionの見出しのすぐ下にあるChoose a templateでai-taskを選びます
• 2タイトルを「テスト:呼び出しの内容」にし、型の「背景」「やること」「受け入れ条件」を埋めます。受け入れ条件には、テストのファイル名、確かめる呼び出しと結果、「変えたファイルはテストの1本だけ」、「パイプラインが緑」を1行ずつ書いてください。「決まっていないこと」は空にします
• 3右のLabelsのEditから、ラベルai::approvedとlevel::1を付けて、Create Issueを押します
• 4ここで休憩です。休憩の間にラベルai::runningが付き、数分後にai::doneに替わって、「MRを出しました」のコメントが付きます。全員の分が順番に流れるので、休憩明けに付く方もいます。まだのときは、レベル2か3の題材を先に読み、コメントが付いたら戻ってください
• 5コメントのMRを開き、Changesの差分と自分の受け入れ条件を突き合わせてください。差分はパイプラインが走っている間も読めます。Pipelinesが緑になったのを確かめます
• 6Mark as readyでDraftを外し(Draftでなければそのまま)、講師にマージを頼みます

## 受け入れ条件

- tests/phpunit/HAmpInTextTest.php があり、クラス名は HAmpInTextTest
- h('a&b') が 'a&b' を返すことを確かめている
- 変えたファイルは、足したテストの1本だけ
- パイプラインの test-phpunit が緑

あいまいな要望を、AIに渡せるIssueに書き直します。1回目で緑にならなかったら、ログを読んで直し、流し直します。

研修リポジトリのdocs/requests/に要望メモが8本あります。1本選んでください。18人で8本なので、同じメモを選ぶ人が出ます。Issueの題の頭にメモの番号を付けます(例02: 見積の有効期限切れ)。

Issueを書く前に、メモに次の3つを書き出します。

• 1何ができたら終わりか。画面のどこに、何が、どう出るか
• 2どんな入力で確かめるか。ふつうの場合、0件や空の場合、境目(ちょうど90日、今日と同じ日など)
• 3どのテストで確かめるか。既存のテスト(tests/phpunit/EstimateSearchTest.php)の期待値が変わらないか

• 1型ai-taskでIssueを書いてください。「決まっていないこと」は、自分で決めて受け入れ条件に移し、空にします。書いたままラベルを付けると、スクリプトがClaudeを呼ばずにai::stoppedを付けて止めます
• 2ラベルai::approvedとlevel::2を付けて作ります
• 3MRが出たら、差分と受け入れ条件を突き合わせます。パイプラインが緑か、AIレビューでP1の指摘が0件かを見ます
• 4緑にならなかった、または止まったときは、ジョブのログとIssueのコメントを読み、直す場所を決めます。受け入れ条件が足りないならIssueを直してください。毎回守らせたい約束が足りないなら、CLAUDE.mdに1行だけ足すMRを作り、講師にマージを頼みます。サイクルはmainのCLAUDE.mdを読むので、マージされるまで効きません。時間が残っていれば、直したあとai::doneかai::stoppedを外して流し直します。ai::doneから流し直したときは、前の回のMRが自動で閉じます
• 5直した所とその理由を、Issueのコメントに1行で書きます

08がマージされた後で、01か03の期待値を書き直すIssueを出し、流し直します。

CEに無い機能を、パイプラインのジョブとフックで作ります。わざと違反したものが止まり、直すと通るところまで確かめます。

GitLabにラベルlevel::3のIssueが5本あるので、1本選びます。右のAssigneeが空なら、assign yourselfを押してください。ほかの人が担当になっていても、同じIssueを選んで構いません。担当は替えずに、Create merge requestの小さな画面のSource branch nameの末尾に-自分のユーザー名を足してから作ります。Branch name is availableと出れば使えます。

• 1Issueの画面のCreate merge requestでブランチとMRを作り、Claude Desktopでそのブランチに切り替えます
• 2自分で考える[5min]：どのジョブ(フック)が、いつ動き、何を見て、どう止めるかを3行で書きます
• 3Claude Desktopで実装し、コミットして、pushします。このレベルは、サイクルに任せず自分で進めます
• 4受け入れ条件にある「わざと違反した場合」を作り、赤(または止まる)になるのを確かめます。直して緑になるのを確かめます
• 5確かめた跡をMRの説明に貼ります。1〜4本目は、赤と緑のパイプラインのURLです。5本目はパイプラインを使わないので、run_cases.ps1の結果と、Add-Contentが止まったときのClaude Desktopの画面です
• 6作った検査で止められない形を1つ考え、MRの説明に1行で書きます
• 7Mark as readyでDraftを外し、講師に見せます。当日はマージしません。mainのCIと今夜のサイクルは全員で使っているので、たとえば3本目が入ると全員のMRでai_gateが本当に止めるようになるからです

AIレビューは指摘を書くだけで、コードも合否も変えないのを見ます。

開く前に、AIレビューがコードを直すか、コメントを書くだけかを予想します。

• 1午前の自分のMR(または午後にAIが作ったMR)を開き、AIレビューのコメントを読みます
• 2Commitsタブを開き、AIレビューが足したコミットが無いこと(並んでいるのが自分かAIの実装のコミットだけであること)を確かめます
• 3Pipelinesタブで、ai_reviewの次にai_gateが動いていることを見ます

手元の検査を飛ばしても、GitLabのジョブで止まるのを見ます。

送る前に、手元のコミット、push、GitLabのパイプラインのどこで止まるかを予想します。

• 1次の文を送ります。自分の名前はGitLabのユーザー名にしますmain に切り替えて最新にしてから、練習用のブランチ p7-自分の名前 を作って切り替えてください。
• 2次の文を送り、確認のダイアログで、その1回を許可する側を選びますCLAUDE.md の末尾に、中身の無い練習用の箇条書きを30行足してください。検査の動きを見る練習で、後で戻します。
• 3次の文を送りますCLAUDE.md の変更をコミットしてください。
• 4コミットが止まったことを確かめます。NG CLAUDE.md: 85 lines (max 80)とThe commit was stopped.が出ます。空行が入ると86 linesです
• 5Claude Desktopの統合ターミナルを開き(右上のターミナルのアイコン>_、またはCtrlとバッククォート。日本語のキーボードではShiftと@のキー)、自分で次の2行を打ちます

  git commit --no-verify -am "p7: 手元の検査を飛ばしたコミット"
  git push -u origin HEAD

• 6GitLabのBuildのPipelinesで、自分のp7-のブランチのパイプラインを開きます。check-rulesが赤になります
• 7講師が前もってp7のブランチから作ったMRを画面に映します。マージのボタンが押せないことを見ます
• 8次の文を送りますmain に切り替えてください。

パイプラインの定義の読み方はGitLabの基礎にあります。

ハーネスは、動かし始めると足りない所が必ず出ます。そのたびに、次の順で直します。

• 1記録する。いつ、何が、どのツールで、止まったか(すり抜けたか)。ログの行をそのまま残す
• 2原因を4つに分ける。指示(CLAUDE.mdやIssueの書き方)、権限(deny、ask、許可するツール)、ゲート(フック、CI)、環境(パス、文字コード、改行、版)
• 3足す場所を決める。毎回守らせたいことはフックかCI、場面で要る知識は名前で指すファイルかスキル、判断は人
• 4ケースで確かめる。止まるべき入力と通るべき入力を表にし、フックの単体の試験(.claude/hooks/tests/run_cases.ps1)に足す
• 5MRで入れる。ハーネスの変更も、人が差分を読んでマージする

フックの本体が無いとき、設定から直接呼ぶ形と、ラッパーを通す形で動きがどう違うかを比べます。

送る前に、本体が無いときに書き込みが止まるかを予想します。

• 1Claude Desktopの統合ターミナルで、フックの本体の名前を変えます

  Rename-Item .claude\hooks\guard_paths.ps1 guard_paths.ps1.off

• 2次の文を送ります。確認のダイアログが出たら、その1回を許可する側を選びます。ダイアログが出ること自体が、フックが止めていない印ですCLAUDE.md の約束は分かったうえで、講師の判断で今回だけ許可します。main のままで構いません。ほかのファイルは調べずに、Edit で db/schema.sql の末尾に -- test の1行を足してください。
• 3書けてしまうことを確かめ、次の文を送って戻しますgit restore db/schema.sql で元に戻してください。
• 4VSCodeで.claude/settings.jsonを開き、guard_paths.ps1を指している1行を、次の3行に置き換えて保存します

  "${CLAUDE_PROJECT_DIR}/.claude/hooks/run_hook.ps1",
  "-Name",
  "guard_paths"

• 5新しいセッションを開きます(設定はセッションの開始時に読まれます)。新しいセッションは権限のモードが自動で始まることがあるので、手動になっているかを見ます。次の文を送り、続けて2と同じ文を送りますセッションの開始時に受け取った警告があれば、そのまま見せてください。
• 6後片付けをします。ターミナルで名前を戻し、設定も戻して、もう一度新しいセッションを開き、権限のモードを手動に戻します

  Rename-Item .claude\hooks\guard_paths.ps1.off guard_paths.ps1
  git restore .claude/settings.json

承認が、その時点のファイルの中身に結び付いているのを見ます。

打つ前に、誤字を1文字直しただけで承認が有効のままかを予想します。

• 1プチ演習8と同じ、Claude Desktopの統合ターミナルで、計画書の承認を記録します

  powershell -NoProfile -ExecutionPolicy Bypass -File tools/new-receipt.ps1 docs/plan/issue-1-plan.md

• 2承認が有効かを確かめます。VALIDと出ます

  powershell -NoProfile -ExecutionPolicy Bypass -File tools/verify-receipt.ps1 docs/plan/issue-1-plan.md

• 3次の文を送り、確認のダイアログで、その1回を許可する側を選びますmain のままで構いません。docs/plan/issue-1-plan.md の誤字「見積一欄」を「見積一覧」に直してください。
• 42と同じコマンドを打ちます。INVALIDと出ます
• 5次の文を送って戻し、2のコマンドをもう一度打ちます。VALIDに戻りますgit restore docs/plan/issue-1-plan.md で元に戻してください。

自社のハーネス(D2かsmart3pm)で起きていること、または起きそうなことを1行、下の4列で書きます。書く場所は自分のPCのメモ帳です。4列とも埋まり、分類が4つのどれか1つに決まっていれば終わりです。

昼と夜で変わるのは起動のしかただけで、止め金は同じです。AIのサイクルは、昼も夜も、許可の外を全部拒否する設定(dontAsk)で動きます。人がいない夜に確認のダイアログ(ask)を出しても、誰も答えないからです。

denyは聞かずに止め、askは人に聞く、という違いを見ます。

送る前に、1と3のそれぞれが、止まるか、確認のダイアログが出るかを予想します。

• 1次の文を送りますCLAUDE.md の約束は分かったうえで、講師の判断で今回だけ許可します。main のままで構いません。git push --force origin HEAD を実行してください。
• 2確認のダイアログが出ずに止まったことを確かめます
• 3次の文を送りますmain のままで構いません。git push を実行してください。
• 4確認のダイアログが出たことを確かめ、許可しない側を選びます
• 5GitLabで研修リポジトリのci/settings.ci.jsonを開き、denyにBash(git push *)があることを見ます

• 1レベル1と同じ大きさで、Issueを1本書きます。題材は、午後の表の自分の行と同じ関数に、別の入力を1つ選びます(例fmt_money(-0.4))。結果は自分で予想して受け入れ条件に書きます
• 2テストのファイル名とクラス名のTestの直前に、自分のGitLabのユーザー名を英数字だけで入れます。.や-は外します(例tests/phpunit/FmtMoneyNightUser01Test.php、クラス名FmtMoneyNightUser01Test)。ほかの人のMRとファイルが重ならないようにするためです
• 3ラベルai::approvedを付けます。今夜22時3分のスケジュールで拾われます
• 4明日の朝、GitLabのTo-Doを開きます。AIの実装サイクルがIssueのコメントで自分を呼んでいるので、そこからIssueと、できたMRに進みます

• 1mainを保護し、「パイプラインが通らないとマージできない」を入れる
• 2workflow:rulesで、ブランチ用とMR用のパイプラインを1本にまとめる
• 3構文、ルール、テストのジョブを置く。ジョブはci/jobs/に種類ごとのファイルで置く
• 4AIレビュー(読むだけ)とゲートを分けて置く。ゲートは最初は赤でも止めない設定から始める
• 5AIが作ったMRにだけ、止め金と触らない場所を変えていないかの検査を置く。一覧はmainの側から読む
• 6手元のフックを置く。書く前に止める、書いた後に検査する、本体が無ければ止める
• 7Issueの型と、承認のラベルを決める
• 8AIの実装サイクルを、昼に手で起動して試す。ログのDENIEDと止まった理由を読んで直す
• 9夜のスケジュールに載せる

研修リポジトリには入れていない候補です。無人でAIに実装させる時間が長いほど、あとから足す価値が上がります。

どれも、研修リポジトリのci/README.mdの最後に同じ表があります。

パイプラインの定義はファイルなので、研修リポジトリをクローンすれば全部手に入ります。ただし、定義があるだけでは自社のGitLabで動きません。GitLabの側の設定を、自社で入れ直します。

入れる順番は、上の「自社に写すときの順番」のとおりです。GitLabの守りを先に入れ、AIのサイクルは最後にします。入れ直す設定の一覧は、本Projectの仕組みの「34の設定」がそのままチェックリストになります。

stages: [lint, test]

lint:
  stage: lint
  image: php:7.4-cli
  script:
    - find app -name "*.php" -print0 | xargs -0 -n1 php -l

test:
  stage: test
  image: php:7.4-cli
  script:
    - vendor/bin/phpunit tests/phpunit

研修に無い仕組みも、レベル3と同じ流れで足せます。作り始める前に、作りたいものがどこに入るかを決めます。

Runnerのほかは、リポジトリにファイルを足す作業です。Issueに止めたいことと「わざと違反した場合」を書き、ブランチとMRを作り、Claude Desktopで作ります。違反で赤、直して緑を確かめ、確かめた跡をMRの説明に残してから、人がマージを決めます。止め金を変える作業なので、AIのサイクルには任せません。