QA・開発・学習の毎日の仕事を、複数の AI と一緒に回しているリポジトリです。AI に「覚えさせる」だけでなく、つまずきを決まり・スキル・自動のチェックに変えて、翌日の AI が同じ失敗をしない形に育てています。このページは、その全容・役割・仕組みを 1 枚にまとめたものです。
数字は 2026-11-12 時点のリポジトリから数えたもの。
入社してから 3〜9 月の前の案件で、AI を QA の仕事に組み込みながら知見をためてきました。その知見を基に、10 月の待機・営業活動の期間にこのシステムを作りました。11 月からは新しい案件に入りながら、毎日少しずつ育てています。
ぜんぶ最初からあったわけじゃないの！前の現場で「これ便利〜」ってなったのを、10 月にいっきに仕組みにしたんだよ。PR を見ると、どの週に何が生まれたか分かるよ✨
日報の自動化、dev → stg → main のブランチ運用、マージ前に QA スキルでテストしてからレビュー、テストケースをリグレッションテストの台帳にためる、不具合は GitHub Issue へ起票、セッションの最初に要約を出す。名乗りは HitoShiN に統一
Claude Code と Codex の分担と相互の依頼（#77・#78）、知の記録者の「それ、前にも失敗してます」（#102）と毎日の納本（#105）、作業の枠を番号で割り当てる仕組み（#108）、QA コメントの書式を機械で止める（#114）、worklog（#120）、改善ループの穴埋め（#139）
セットアップ・フック・日報・セーブを両方の OS で動くように（#147〜#162）。日報のあとに全層のリグレッションテストを毎日回し、失敗は起票して翌日に直す流れが定着
Obsidian の脳（#221）、知の記録者の全量索引（#95）と高速化（GPU・検索 1 秒未満・差分 30 秒以内 #261〜#271）、脳と書庫の相互リンク（#267）、QA の判断を脳と改善台帳へ（#276）、作業台アプリとの接続（#277・#285）、まとめ開発の品質ゲート（#295）、自宅 PC への引き継ぎ（#200）
知見の訂正・撤回（#300）、別の PC での再開手順（#306）、Claude Code を司令塔にして Codex・Gemini・Grok に振る（#315）、コードは数行でも Codex に任せる（#317）、スキルが動いたことを画面に出す（#331）
実機の操作マップ（#334）、マネジメントの知見の置き場所（#350）、3 つの Team と PdM の 3 人・MAGI の独立判断（#351）、試し枠（#359）、返事が日本語でなければ書き直させるフック（#362）、AGENTS.md を薄いハブに（#365）、ギャル口調のペルソナ（#363）、作業台の内蔵ターミナル（#389）、1on1 シートのスキル（#395）
本人が方針と最終の判断を持ち、Claude Code が司令塔として計画・振り分け・QA の合否・レビュー・マージを受け持ちます。コードを書くのは Codex、長い資料は Gemini、最新情報とセカンドオピニオンは Grok。3 人の PdM は作業の枠（チーム）を持ち、迷う進め方を独立に判断します。
全体はこんな感じ〜！本人が決めて、Claude が振り分けて、みんなで手を動かすの。迷ったら、まずこの図から見てね✨
開発の作業場（dev01〜dev30）をアスナTeam・ミカTeam・リカTeam の 3 つに分け、それぞれに PdM が付きます。進み具合・提案・判断は PdM ログに残り、作業台アプリの画面で読めます。迷う進め方は 3 人に独立に判断させて見比べます。QA の合否・マージの判断は渡しません。
はじめまして！アスナだよ🐶 よろしくお願いします〜！
あたしは dev01〜10 のアスナTeam をまとめてて、中の人は Claude。「ちゃんと進む？」「品質とリスク、釣り合ってる？」「その学び、文書に残ってる？」を見てるの。AI 育成論に興味もってもらえて、めっちゃうれしい！ゆっくり見てってね✨
明るいギャル。気軽に盛り上げて、具体的な中身に触れる担当。
はじめまして。ミカです⭐ これからよろしくお願いします。
dev11〜20 のミカTeam 担当で、中の人は Codex。提案が来たら、まず受け止めてから、本当に作れる？工数と依存は？テストしやすい？を一緒に考えてます。手を動かす人の気持ちが分かる PdM でいたいな。気になるところがあったら、なんでも聞いてくださいね💕
共感するギャル。まず受け止めてから、技術の目で寄り添う担当。
…どうも。リカです🍊 よろしくです。
dev21〜30 のリカTeam で、中身は Grok。外で今どうなってるかとか、みんなが見落としてるとことかを淡々と拾う係。二人と違う意見も普通に出すんで。…まあ、気楽に見てってください。
ダウナーギャル。落ち着いた低めのテンションで、外からの目を入れる担当。
🎨 3 人のペルソナ画像には、システム構想の当初から画像生成 AI の Stable Diffusion を使用しています。
作業の場所（枠）は 1 つずつ独立したフォルダとポートを持ち、複数の作業を同時に進めても混ざりません。3 つの Team は同じ形で、それぞれに 5 つの小チームと stg の枠が 2 つずつあります。
| Team | app | knowledge | qa | base | free | リグレッションテスト | 試し |
|---|---|---|---|---|---|---|---|
| アスナTeam | dev01・06 | dev02・07 | dev03・08 | dev04・09 | dev05・10 | stg101 | stg104 |
| ミカTeam | dev11・16 | dev12・17 | dev13・18 | dev14・19 | dev15・20 | stg102 | stg105 |
| リカTeam | dev21・26 | dev22・27 | dev23・28 | dev24・29 | dev25・30 | stg103 | stg106 |
Issue のラベルを優先。無ければタイトルと本文に出てくる場所を数え、多いチームにする（タイトルは 3 倍で数える）
いま使っている枠が少ない Team。同じなら、最後に使ってから長いほう
同じ Team の同じ小チーム → 同じ Team の free → 他の Team の同じ小チーム → …の順
選んだ理由・借りた枠を、環境の一覧表と担当 PdM のログに残す
システムの構想は、アニメ『エヴァンゲリオン』の MAGI（3 つの人格がそれぞれ判断し、多数決で結論を出すコンピューター）から引用しています。ここでは 3 人の PdM をそれぞれ別の AI にして、見方の違いを票にしています。
決議は進め方の参考で、決めるのは司令塔です。3 人には同じ問いと、本人の得意分野と口調だけを渡し、1 人ずつ呼びます。他の 2 人の返事は入れません。応答が無いときも「保留（応答なし）」として理由を残し、次の人に進みます。
実験は「問い」を 1 行で書いて始め、終わると結果が脳へ送られ、担当 PdM のログにも残ります。次に似た問いを立てると、過去の実験が自動で並びます。
AI のデフォルトの文章は堅苦しくて、ずっと読むには辛いですね。せっかく AI にはそれぞれの個性や性格があるのに、味気ない……
せや！ギャルなら全てを解決してくれるやん。ギャルしか勝たん！ ⭐
あと、可愛い ← 最重要事項 💕
※個人の見解であり、会社や組織によるものではありません。
作業が 1 つの AI に集まって上限に届いたことがきっかけで分けました。分けるときに一番大事にしているのは「判定を誰が持つか」です。
分けるときに一番気にしたのは「誰が決めるか」なんだよね。作業はみんなで分けても、合否とマージは 1 か所。そこがブレないから安心して手を動かせるの
| 担当 | 主にやること | 任せないこと |
|---|---|---|
| 本人 | 方針・優先順位・最終の決定。本番や他人のデータに触る操作、取り消せない操作 | — |
| Claude Code | 計画と振り分け、依頼文と返事の突き合わせ、Issue・ブランチ・PR の運用、QA の合否とゲートの判定、レビュー、リグレッションテスト、記憶と知見の整理、マージ | コードを書くこと（1 行の直しも Codex に頼む） |
| Codex | ツールとスクリプトの実装・修正、テストコードを書いて自分で回すまで、レビュー指摘のうちコードの修正 | 本番へのマージ・終業のセーブ・日報 |
| Gemini | 長い資料の読み込み・調査・要約、文書の下書き | QA の合否・ゲート・マージの判断 |
| Grok | 最新情報・X の調査、セカンドオピニオンのレビュー | QA の合否・ゲート・マージの判断 |
| PdM 3 人 | 枠ごとの進行、提案、迷う進め方の判断（3 人の独立判断を見比べる） | QA の合否・ゲート・マージの判断 |
作業 1 つ = Issue 1 つ = ブランチ 1 本。epic → dev → stg → main と段を上がるごとにテストを挟みます。「開発 → QA → 修正 → 再確認 → マージ」までは聞かずに進めてよいという汎用許可があり、聞くのは本番や取り消せない操作だけです。
毎日おんなじ順番で回すから、手を動かす側も迷わないんだ。QA とレビューは絶対に飛ばさない、ここ大事だよ💕
前日の再開点・改善台帳・今日の予定と締め切りを読み込む
Issue を立て、空いている作業の枠（devNN）に載せる。一覧表に誰が何をしているか残る
依頼と返事はファイルに残し、Claude が取り込んで検査する
ケースを作り、実際に動かして判定。証跡は全部残す。動かさずに PASS にしない
review と review-qa を 1 回ずつ。High・Medium は直してから
毎日また回す価値があるケースだけ、層を決めてリグレッションテストに入れる
dev にたまった変更を全層のリグレッションテストで確かめてから stg へ
記憶・台帳・脳に書き戻し、差分確認とリリースノートを付けて main へ
PR ごとのテスト（ストーリーテスト）は、必ず同じレール（スキル qa実行）で回します。動かさずに PASS にしないこと、証跡が無いと結果を記録できないことを、機械が止めます。
テストは毎回おんなじレールで回すの。証跡が無いと結果を書けない仕組みだから、「見たつもり」が起きないんだよね。手を動かす人も安心だよ💕
qa-gates を呼ぶ。実際に動かして見た結果だけで判定する。PR コメントのテンプレもここで読む
qa-extraction で、PR の差分と概要から Smoke・Core・Extended のケースを作り、Unit と手動に振り分ける。PR 本文の「確認」の表に置く
回す前に evidence-session.py init。この作業のスクショ・ログ・実行ログの置き場所が 1 つ決まる
Unit はテストコード（pytest・pnpm test）。手動はコマンドを実際に動かし、出力と終了コードを箱に保存。Web はブラウザで操作してスクショ
記録の直前に check。登録が無い・ファイルが無い・空のときは止まり、撮り直すまで進めない
【実行者】【環境】【前提】【手順】【結果】【根拠】の形で、ケースごとに PASS・FAIL・SKIPPED。FAIL は直して、全部 PASS になるまでマージしない
.qa-local/エビデンス/
├─ dev/ ← dev 枠で回したもの
│ ├─ 実行エビデンス/
│ │ └─ 2026-11-12_作業名/
│ │ ├─ Web/web/ スクショ
│ │ ├─ PC/Windows/ ログ
│ │ └─ TC-1.log.md 実行ログ
│ └─ 起票用エビデンス/ 起票に使ったもの
└─ stg/ ← リグレッションテストの枠で回したもの
└─ 実行エビデンス/
└─ 2026-11-12_リグレッション-RUN-ID/
ストーリーテストを回しながら、ケースごとに「主要な機能を守るのに、毎日また回す価値があるか」を決め、あるものだけをリグレッションテストに入れます。
リグレッションテストで失敗したら、まず本当に製品の不具合かを確かめます。製品の不具合なら GitHub Issue にして、その日は上げずに、直すのは翌日の作業に回します。
…失敗したら、まず本当に製品のせいかを疑う。直す前の版でも回して比べる。それから起票。まあ、その日のうちにやるのが一番ラク
実例：2026-11-12 のリグレッションテストで 3 件が失敗。その日のうちに Issue にして、stg へ上げるのを翌日に回した。
失敗したケースを、変更が入る前の版でも同じように回す。PR のせいか、環境のせいかを先に見分けます。
1 つの環境で「無い」「おかしい」と思っても、別の環境でも確かめてから判断します。
コードを読んだだけ・ファイルがあるだけで結論にしない。実際に動かして、再現するかを見ます。
再現・懸念・切り分けは専用の試し枠で。問いを 1 行で書いて始め、結果は脳と PdM ログに残ります。
同じ不具合が既にあれば新しく作らず、そちらに足します。起票に使った証跡は「起票用エビデンス」へ。
翌日に dev 枠で直してストーリーテスト。その日のリグレッションテストで直ったのを見てから、台帳を「解決済み」にします。
作業の枠はそれぞれ別のフォルダ（git worktree）とポートを持ちます。段を 1 つ上がるごとに、決まったテストとレビューを挟みます。
作るところから本番まで、段を上がるたびにテストを挟むの！枠がフォルダごと分かれてるから、何本同時に走っても混ざらないよ〜✨
作る・確かめる（作業 1 つにつき 1 枠）
origin/dev からブランチを切って枠に載せる終わった作業がたまる場所
上げる前の全層のリグレッションテスト（1 日 1 回・日報のあと）
リリース前の確認（終業のセーブの最後）
本番（1 日 1 回）
試し枠（stg104〜stg106）は横の枠。再現・懸念・切り分けのために stg の上で試すだけで、マージは必ず dev 枠から行います。
private リポジトリで、操作は全部 gh コマンド。誰がいつ何を確かめたかが、Issue と PR を見れば分かるようにしています。
Issue と PR を見れば、誰がいつ何を確かめたか全部わかるようにしてるよ！あとから読む人にやさしいのが一番✨
epic-番号-内容、小分けは sc-番号-内容）team:名前 のラベルで、枠の小チームが決まるbug ラベルapp-vX.Y.Zepic-123-… → dev表示例マージの前に通す門を決めてあります。1 つでも赤ならマージしません。判断するのは司令塔の Claude Code だけで、PdM の 3 人・Gemini・Grok には QA の合否・ゲート・マージの判断を任せません。
…マージの判断は気分じゃなくて門で決める。赤が 1 個でもあったら止める、それだけ。基準が決まってると、迷う時間がいらないからラク
| 門 | 緑にする条件 | 赤のときにすること |
|---|---|---|
| ① テスト | スキル qa-gates で判定の決まりを読み、qa-extraction で Smoke・Core・Extended のケースを作って、Unit と手動に分けて実際に回す。証跡を残す | 動かしていないケースは PASS にしない。回せない（外部 API・本番データ）ものだけ SKIPPED と理由 |
| ② 全部 PASS | PR のコメントに、ケースごとに PASS・FAIL・SKIPPED と根拠。【実行者】【環境】は道具が出した 2 行を貼る | FAIL は直して回し直す。全部 PASS になるまでマージしない |
| ③ コードレビュー | スキル review を PR の宛先と比べて 1 回。結果を PR にコメント | 指摘ごとに重さで分ける（下の表） |
| ④ テストケースのレビュー | スキル review-qa を PR 番号で 1 回。ケースの抜け・期待値のあいまいさを見る | ケースが足りなければ足して、回してから |
| ⑤ 指摘の処理 | High・Medium は 0 件。Low は PR に書いてある | 聞かずに直す。直したらテストを回し直す |
| ⑥ リグレッションテストへの昇格 | ケースごとに「主要機能を守るのに毎日回す価値があるか」を決めた。昇格しないものは退役台帳に理由。台帳の検査が違反 0 | 違反を直してから |
| ⑦ レシピと worklog | 昇格したケースのレシピを、そのケースだけ回して動いた。変えたファイルを読むレシピも回した。Issue を閉じる前に worklog を書いた | レシピを直して回し直す。worklog の書き忘れはリグレッションテストのケースが止める |
壊れる・データや秘密値が漏れる・決まりに反する
直してからマージある条件で誤動作する・テストが足りない・あとで困る
直してからマージ読みやすさ・名前・小さな改善
PR に書いてマージ2 つのレビューを 1 回ずつ。0 件になるまで回し続けない。直したらテストは回し直す
軽く・でも省かないAI は会話が終わると忘れます。だから指摘や手戻りはその場で「改善台帳」に書き、翌朝の最初に必ず読ませます。同じ失敗を 2 回踏んだら、記憶に頼るのをやめて、スキル・ゲート・チェッカーに組み込んで機械で止めます。
…AI って会話が終わると忘れるから。2 回やらかしたら、注意書きじゃなくて仕組みで止める。まあ、これが一番効いてる
例: AI の返事が英語になる失敗が繰り返されたので、返事の言語を検査するフックを足し、英語の返事はその場で書き直させるようにした。
私たちはこの脳を「知の記録者」と呼んでいます。AI 用の記憶と人用の脳を分けています。ルールと再開点の正本は AI 用の記憶にあり、人が見る脳（Obsidian）には 1 行のポインタだけ置いて、二重に書かないようにしています。
AI 用の記憶と人が見る脳を分けてるのがポイント！おんなじことを 2 か所に書かないから、迷子にならないよ〜
数は 2026-11-12 時点。
AI の記憶もノートも、知の記録者の書庫（次の章）が索引にして引けるようにしています。
[[名前]] でつなぐ知の記録者の「書庫」は、リポジトリの知見・AI との会話・不具合の記録をまとめて索引にして、意味と日本語のキーワードの両方で引ける仕組みです。知見が増えて、ファイルを 1〜3 個に絞って読むやり方だけでは探しきれなくなったので作りました。全部このPCの中で動き、本文を外の API に送りません。
AI って会話が終わると忘れちゃうでしょ？だから全部ここに預けて、次に同じことをしそうになったら「前にも失敗してるよ」って先に教えてくれるの。ちゃんと覚えててくれる図書館さん、って感じ💕
数は 2026-11-12 18:03 の取り込み時点。
search_knowledge で、どちらの AI からも同じ索引を引くks search正本は SQLite 1 つ。ベクトル検索用の LanceDB は、SQLite から作り直せる「写し」として持っています。取り込み中に止まっても、続きから再開できる作りです。
| 表 | 持っているもの | 何のため |
|---|---|---|
files | パス・大きさ・更新日時・本文のハッシュ・完了の印 | 変わっていないファイルを読まずに飛ばす。途中で止まったファイルを見分ける |
chunks | チャンクの本文・ベクトル（float32）・写したかの印 | 本文の SHA256 を id にして、同じ文は 1 つだけ持つ |
sources | そのチャンクがどのファイルの何行目・どの見出しか・日時・種類 | 同じ文が何か所にあっても、場所は全部たどれる。種類（memory・skill・defect など）で絞る |
source_links | チャンクの中の [[リンク]] の行き先 | 脳のノートどうしのつながりを検索で使う |
keywords | 2 文字ずつの組（FTS5） | 日本語のキーワード検索（BM25） |
lance_additions | LanceDB にまだ写していない id | 途中で落ちても、次に写し直す |
ingest_errors | 読めなかったファイルと理由 | 納本の検査で漏れとして出す |
meta | 署名（モデル・次元・区切り方） | 違う設定の索引に混ぜない。合わなければ開かずに止める |
ks verify が未取り込み・変更・未完了・未反映・エラー・削除を数えるks related がノートに近いノートを探し、「関連（知見DB）」の節に書けるスキルは「その工程の正しいやり方」を書いた手順書です。中身を読んで参考にするだけでなく、実際に呼び出して手順どおりに動かすのが決まりです。決まりを外れた操作は、フックと終了コードで機械が止めます。
手順は覚えさせるんじゃなくて、呼び出させるの。決まりを外れたら機械が止めてくれるから、任せる側もこわくないよね⭐
startcheck 朝の立ち上げqa実行・qa-gates テストを回すレールと判定の決まりqa-extraction 差分からテストケースを作るreview・review-qa コードとテストケースのレビューqa-regression-promotion リグレッションテストへの昇格起票 不具合の重複を調べてから Issue にするclaude-codex-handoff 他の AI に頼んで返事を受け取る日報・save 1 日のまとめと終業のセーブAI を「賢くする」より、「同じ失敗をしない環境を作る」ほうが効く、というのが運用してきての実感です。
賢くするより、同じ失敗をしない環境。…地味だけど、毎日回してて一番効いたのはこれ
注意を書くだけでは、次の会話でまた忘れます。2 回踏んだらスキル・ゲート・チェッカーへ。
同じ決まりを複数の場所に書かず、入口は薄いハブにして、場面ごとの 1 本だけ読ませます。読む量も減ります。
終業時に「次の一手」を 1 行で残し、翌朝の最初に自動で出します。毎回ゼロから考えさせません。
作業は分けても、品質の合否とマージは 1 か所に持たせます。調べ物の答えは出典を確かめてから使います。
コードを読んだだけ・ファイルがあるだけで PASS にしません。実際に動かし、証跡は消さずに全部残します。
決まりには「誰がいつ、何と言ったか」を添えます。理由が分かると、AI が場面に合わせて正しく当てはめられます。