2日間の演習は全部で4本です。課題の正式な文面と提出先は GitLab の Issue にあり、このページはその進め方を説明します。当日はこのページと GitLab を並べて進めます。
| 演習 | 日 | すること | 成果物 |
|---|---|---|---|
| 1-1 注入の検知 | Day1 | セッション開始時の検証3点を PowerShell で実装する | harness/session_start.ps1 のMR |
| 1-2 任せ方の差分 | Day1 | 同じ欠陥修正を2通りの任せ方で行い、差分を測る | 修正MRとふりかえりシート |
| 2-1 MR一周 | Day2 | 不整合バグを直し、CI・AIレビュー込みでマージまで通す | マージ済みMR |
| 2-2 基準の起案 | Day2 | AIレビュー基準の自社版を起案する | 基準(案)のMR |
共通の進め方
Issue を読む、ブランチを切る、MR で提出する
4本ともこの流れで進めます。個別の演習ページでは、この流れとの差分だけを書きます。
- 1GitLab の Issue 一覧から担当する演習を開き、課題と完了の条件を読みます。
- 2VSCode のターミナルで作業ブランチを切ります。名前は
ex/演習番号-ユーザー名です。git switch -c ex/1-1-taro.yamada - 3実装を進め、コミットして push します。
git add -A git commit -m "ex1-1: セッション開始検証を実装" git push -u origin ex/1-1-taro.yamada - 4push 結果に表示されるURL、または GitLab の画面から Merge Request を作成します。テンプレートが自動で入るので、空欄を埋めてください。
- 5CI と AIレビューの結果を確認し、指摘ごとに「対応する/しない」を判断して、理由をMRのコメントに書きます。
演習1-1 セッション開始時の注入検知
AIに食わせてはいけない状態を、機械で止める
古いブランチや想定外のフォルダでAIセッションを始めると、AIは古い前提のまま自信を持って作業します。人が気をつける運用では防げないため、セッション開始時に機械で検証して止める仕組みを作ります。実装は PowerShell スクリプト1本です。
検証の仕様
| 検証 | 合格の条件 | 違反時の動作 |
|---|---|---|
| 配置 | カレントフォルダ直下に .git と .gitlab-ci.yml がある | 理由を表示して終了コード1 |
| 鮮度 | origin/main から10コミット以上遅れていない | 遅れの数を表示して終了コード1 |
| ブランチ | ブランチ名が ex/ で始まる(main での作業は不可) | 現在のブランチ名を表示して終了コード1 |
- 1実装に入る前に、3つの検証をどう実現するか自分の言葉でメモに書き出します。使えそうな git コマンドの見当をつけるところまでが自分の仕事です。
- 2メモをもとにAIと壁打ちして、方針を固めてから生成させます。仕様表を丸ごと渡して「作って」で終わらせないでください。
- 3
harness/session_start.ps1として保存し、正常系と違反系(たとえば main のまま実行)の両方を実行して動作を確かめます。powershell -ExecutionPolicy Bypass -File harness/session_start.ps1 - 4共通の進め方に沿ってMRを作成します。
- 違反系の実行で、理由が表示されて止まる
- MRが作成され、AIレビューへの対応判断がコメントに残っている
演習1-2 任せ方の差分を測る
同じ修正を2通りで流し、判断軸を言語化する
見積一覧の検索条件の組み立てに、外部入力をそのままSQLへ連結している箇所があります。この修正を題材に、グループごとに指定された進め方で作業します。
| 進め方 | ルール |
|---|---|
| A：全任せ | 欠陥の特定から修正まで、AIの提案をそのまま採用する。人は実行と提出だけを行う |
| B：確認併用 | AIの提案ごとに、採用するかを自分で判断してから進める。書き換えてもよい |
- 1開始時刻を記録します。担当は
app/controllers/estimate_ctl.phpの検索条件です。 - 2指定された進め方で欠陥を特定し、修正します。実環境が PHP 5.4.45 のため、5.5以降の構文を使うと CI の lint-php54 で落ちます。
- 3共通の進め方に沿ってMRを作成し、終了時刻を記録します。
- 4ふりかえりシート(当日配布)に、所要時間・手戻りの回数・AIの提案を却下した箇所を記入します。
- 欠陥の内容と影響範囲を自分の言葉で説明できる
- MRとふりかえりシートがそろい、AとBの差分を全体共有で話せる
演習2-1 MRを一周させる
CIとAIレビューを最終ゲートにして、マージまで通す
在庫の引当処理が、複数の更新をトランザクションなしで実行しています。途中で失敗すると在庫と受注の状態が食い違う、実務でよくある形の欠陥です。この修正を題材に、MRの一周(作成、CI、AIレビュー、対応判断、マージ)を通しで体験します。
- 1担当は
app/controllers/stock_ctl.phpの引当処理です。どの更新がひとかたまりであるべきかを先に整理します。 - 2AIと壁打ちして修正し、共通の進め方に沿ってMRを作成します。
- 3パイプラインの3ジョブ(lint-php83、lint-php54、test)が通ることを確認します。落ちたらログを読み、AIに貼って原因を特定します。
- 4AIレビューのコメントを読み、指摘ごとに対応する/しないを判断して理由を書きます。
- 5ペアの相手のMRをレビューし、互いに承認してマージします。
- CIの3ジョブが通り、AIレビューへの対応判断が残った状態でマージされている
- 手元でPHPやDBを一度も動かしていない(すべてCI上で確認した)
tests/run_tests.php にあります。修正がテストの前提を変える場合は、テスト側の変更も同じMRに含めてください。演習2-2 AIレビュー基準の自社版
対応しない指摘を先に決め、確認作業を減らす
小さな改修ほどAIの指摘への対応と確認に時間がかかる、という課題への回答が、このリポジトリでは2つの実装になっています。差分の行数でレビューの深さを切り替える仕組みと、対応しない指摘を先に決めておく基準ファイルです。実物を確認し、自社版の初版を起案します。
- 1
.gitlab/ai-review-rules.mdとci/ai_review.shを読み、基準がどこでレビューに効いているかを確認します。 - 2小さな変更のMRを作り、浅いレビュー(差分80行以下)の挙動を実際に見ます。
- 3自社の開発を思い浮かべ、「必ず指摘するもの」「対応しない指摘」の自社版を ai-review-rules.md の形式で起案します。対応しない指摘には理由を3つ以上書きます。
- 4起案をMRにして、グループ内で読み合わせます。
- 基準ファイルの変更がレビュー結果を変えることを、実物で確認した
- 自社版の基準(案)がMRになっている
困ったとき
push で Authentication failed になります
パスワードは初回ログインで変更した後のものです。間違えた場合は、同じコマンドをもう一度実行すると入力し直せます。
CI が落ちました
MRの Pipelines タブから落ちたジョブを開くとログが読めます。ログの末尾をAIに貼って原因を聞くのが早道です。lint-php54 で落ちた場合は、PHP 5.5 以降の構文が混ざっています。
AIレビューのコメントが付きません
AIレビューはMRを作成・更新したときに動きます。数分待っても付かない場合は、パイプラインの ai-review ジョブの状態を確認し、講師にお知らせください。
間違えて main で作業を始めてしまいました
変更を保持したままブランチを切り替えられます。git switch -c ex/番号-ユーザー名 を実行してから、通常どおりコミットしてください。main への直接 push はサーバー側で拒否されるため、壊す心配はありません。