第1部
私が実際にやっている "現物"
特別なツールではありません。すべて「置き方」の工夫です。
現物 1
CLAUDE.md ＝ AIへの「館内マップ」
Claude Code には、プロジェクトごとの説明書を CLAUDE.md に置く仕組みがあります（Codex だと AGENTS.md）。AIは作業前に必ずこれを読みます。
私はここに細かいルールをびっしり書くというより、「どこに何が入っているか」をざっくり書いて、前提（コンテキスト）として渡しています。実際の私のCLAUDE.mdの一部はこんな感じです👇
# リポジトリ構成（CLAUDE.md より抜粋）
- 3行日報/ … DXチーム向けの日報
- AI業務推進/ … AI活用推進の計画
- AI推進プロジェクト/ … 有志チームの運用（専門/汎用）
- Chatwork通知/ … 通知Bot群
- ツール/ … 汎用スクリプト置き場
毎回「口で説明する」のをやめるため
これがあると、AIに毎回「このリポジトリはこういう構成で、あの情報はあそこで…」と説明しなくて済みます。AIが自分で「あの件はこのフォルダだな」とたどれるようになります。＝ AIへの地図です。
テスターチームなら：「テストはこのコマンド」「PR前はここを確認」「この領域は勝手に触らない」を AGENTS.md / CLAUDE.md に置けば、Claude Code / Codex が最初から分かった状態で動きます。
現物 2
チームごとのフォルダ
この「専門的寄りチーム」も、私の中ではこう整理しています。
専門的寄りチーム/
├ README.md （このチームは何か＝目的メモ）
├ メンバー情報.md （誰がいて、何を期待しているか）
├ インパクトフィルター.md （チームのゴール・成功の基準）
├ 1ヶ月後アンケート.md （みんなの声）
├ 文字起こし/ （毎回の定例の記録／日付＋回数で命名）
├ 第2回・第4回・第5回/ （回ごとの資料）
└ archive/ （使い終わった古い版）
業務（チーム）ごとに分ける
全部を1か所に入れると、AIが「今どのチームの話？」と迷い、関係ない情報まで読みに行きます。区切ると「このフォルダ＝このチームの世界」と一発で伝わります。
「目的メモ」を置く（README・メンバー情報・インパクトフィルター）
フォルダの"地図"です。今回の第5回スライドも「このフォルダを読んで作って」と頼んだだけで、チームの文脈に沿った内容が出てきました。
テスターチームなら：チーム用フォルダを1つ作って、テスト観点表・バグ票・議事録・目的メモを"その中に"集約すれば同じ形です。
現物 3
ログを自動で溜める仕組み
前回お伝えした「会議準備の自動化」、実物はこんな形です。
work-log-collector/
├ README.md （使い方の説明書）
├ src/
│ ├ collector.py （毎日チャット発言を自動で集める係）
│ ├ meeting.py （前回会議〜今日をまとめる係）
│ └ report.py （期間を指定してまとめる係）
└ logs/
├ 2026-06-04.md （その日のログ／自動で溜まる）
└ archive/ （使い終わったログの置き場）
なぜ毎日ログを溜めるのか
会議のたびに「この2週間、何やったっけ」と思い出すのは毎回ゼロから探す無駄。先に毎日溜めておけば、会議前は「溜まったものをまとめるだけ」になります。
なぜ係を3つに分けているのか
1つの巨大プログラムに全部入れると、1か所直すと全体が壊れます。係ごとに分ければ直したい部分だけ安全に直せます。
なぜ archive/ があるのか ← ここ、特に大事
理由は2つ。
1. 最新版を1つに保つため
表に出ているのは「まだ使っていない最新ログ」だけ。古いのが混ざると、AIがそれも読んで時間を無駄にしたり、古い情報で間違えたりします。
2. 消さずに残すため
古いログも後から見返せるよう、消さずに archive へ"退避"。消すと取り戻せませんが、archive なら安全です。
テスターチームなら：バグ報告が決まった場所に毎回溜まる → 会議前に「今週のバグ傾向まとめて」で自動レポート。対応済みの古い票は archive へ移し、今追うものだけ表に残す。
第2部
テスターチームの "最初の一歩"
ここからは、開発→テスターで今日から作れる「型」を3つ。これが ② のいちばん実践しやすい入口です。
型 1
テスト依頼テンプレート
BEFORE
「この機能、テストお願いします」
→ どこを見れば？ どんな条件で？ 過去の類似テストは？ と聞き返しが発生
AFTER
依頼を"型"に流すだけで、Claude Code / Codex がテスト観点・正常/異常/境界値・テストコード案・抜け漏れを出せる
# テスト依頼テンプレート
## 対象機能 例：イベント申込フォーム
## 変更内容 例：申込完了後の表示文言を変更
## 影響範囲 例：申込画面 / 完了画面 / 通知メール
## 受け入れ条件 （満たすべき条件を箇条書き）
- 未入力ならエラーが出る
- 正常入力なら完了画面へ進む
- 受付終了イベントでは申込ボタンが出ない
## 関連ファイル フロント / API / テスト
## 参考にする既存テスト 例：tests/xxx.spec.ts
## AIにやってほしいこと 観点洗い出し / テストコード案 / 抜け漏れ
## 人間が確認すること 仕様とのズレ / 会員体験で重要な観点
これは「テストをAIに丸投げ」ではなく、「AIがテストに参加できるよう、依頼の入口を整える」ということ。
型 2
バグ報告テンプレート
BEFORE
チャットでバグが流れる → 誰かが読む → 聞き返す → 再現確認 → 開発へ共有
AFTER
テンプレ入力 → AIが分類・再現手順整理・重要度の仮判定・調査候補ファイルを出す → 人間が確認 → Issue化
# バグ報告テンプレート
## 発生したこと 例：申込ボタンを押しても完了画面に進まない
## 期待していた動き 例：申込完了画面が表示される
## 発生環境 端末 / ブラウザ / ユーザー種別 / 日時
## 再現手順 1. 2. 3.
## スクショ・ログ 保存場所：
## 影響範囲 例：イベント申込に影響あり
## AIにやってほしいこと 分類 / 再現手順の整理 / 重要度の仮判定 / 関連コード候補
バグ報告そのものを、AIが扱いやすい形に変えている例。報告の精度がばらつかなくなります。
型 3
（発展）繰り返す作業は Skill にする
Claude Code / Codex には、よく使う指示・参照資料・スクリプトを1パッケージにまとめる「スキル」の仕組みがあります。
test-review-skill/
SKILL.md （やってほしいことの本体）
references/
テスト観点一覧.md （毎回参照する資料）
重要度判定基準.md
scripts/
run-tests.sh （必要なら実行スクリプト）
毎回同じ指示を打つのをやめて、繰り返す仕事を「AIの作業メニュー」にするイメージです。