常日頃感じている問題意識
TmuxとClaud Codeを使って、Multi Agent開発を行うことが日本のTech界隈では流行っている。確かに、便利だし開発の推進力も以前より増し、そのタスクアウトプットの品質もそれなりに高いものになっている。
かといって、どこまで行ってもEngineer側にAgentアウトプットに対する「認知負債」が一定程度押し付けられている状況は変わらないと思う。
もちろん、Claude CodeのOpus4.6で、SuperPowerを入れて、MultiAgent稼働をさせれば相当複雑なタスクでも一定の出力を得ることができていることは確かに、個人的体験としても間違いない。
しかし、事業として相応の品質のものを作って、顧客企業に提供するための開発を行う、テック起業家にとっては、「便利になったけど便利になっただけ」の状態でしかない。
つまり、開発は便利になった。しかし、その成果物が、顧客企業に提供するための品質として、あるいは保守運用上の効率として、セキュリティとして、問題ないものなのか、確認するプロセスが必ずしも便利になったとは思えない。
もちろんテストコードをAgentに書かせればいいし、セキュリティ検証もAgentにやらせればいいのだが、果たして、人間が自らコードを書いていたときに比べて、人間が書いていたからこそ実現されていた保守性や検証可能性は担保されているだろうか。
確かに、それらの問題意識を便利にしてくれるSKILLやGitRepositoryは登場しているのかもしれない。僕がそれらを知らないだけかもしれない。でも、僕が知らないということは知らない人の方が大半なのでは？
当面の流儀
ということで、結局、当面はクラシックな手順を踏んで、これら、Agentの生成したコードの品質や保守運用の効率、セキュリティを検証するための手順を採用しようと思う。
よっぽどいいSKILLやWorkflowが社会全体（少なくともテック界隈全体）に浸透するまでは、それでいい気がする。保守的な考え方かもしれないが、安心は得られる。
手順メモ
そこでやっているのは以下の通り。
Step1: Issueを発行
- Working DirectoryにおいてAgentに、人間が感じているIssueをまずは伝え、人間側の懸念Intentの言語化や、実際のCodeに対する検証などを行う
- その結果を見ながら、希望する方向性や懸念を伝え、AgentにCoding上の、方向性やTodoをより精緻に整理させる
- 整理させたら、それらを一つ一つのIssue Ticket（.md）に保存させる（<--非常に古典的）
ここで使ったプロンプトはこうだ
ここまでの調査に関する、私のQA Intentとそれに対する調査事項のreportを、
@.qa_session/reports にMDで出力してください。
またこれらに対して考えうる開発用Issueチケットを、
@.qa_session/issuesに独立して保存してください。
別のAgentが見ても着手できるように、
- 背景、
- 着手箇所、
- 課題、
- 解決方針、
- 理想とするゴール像、
- ユーザーに確認を依頼すべき事項
を含めて開発しやすいように配慮しておくこと。しっかり考えること。
Step2：認知負債を抑えたHandover資料を生成
Issue Ticketに保存させた後、このIssue Ticketを、何も知らないAI Agentが見てもすぐ着手しDeal with itできるように、あるいは人間が後から見返してもすぐに文脈を思い出して適切な論点や指示を出せるように、「認知の揮発や不在」を前提としたHandover資料を書かせるのだ。
そのプロンプトは以下の通りだ。
ユーザーの認知負債を抑えるための機構ないしドキュメントを設けておくこと。
<Points>
・後から読み返してQuick Turn Aroundが可能であること
・Agentに作業タスクを振る際に独立して手放しでやらせて問題ないのか
・Agentに作業タスクを振る際に気をつけるべき観点ないしアクションポイント
・追加の質問事項や追加ISSUEが到来したときに情報の揮発を不正で自己更新できるようにしておく
</Points>
など、認知負債を極限まで下げる工夫を講じておいて。
プレーンな事前情報なしのAgentでも着手できるようなものが好ましい。
かつ、各ISSUEに上記資料を参照する一文をコメントアウトなどで設けておくこと。
このプロセスを僕は毎回やっている。
何がいいかと言えば、
- 何をやっていたか忘れていてもここを見させればAgentがプレーンな状態から即座に文脈を復元してくれる
- いざという時は、どこのタイミングでバグが含む開発をしたのかトレースバックができる
ということだ。
上記のPromptの結果出力される応答は以下の通りだ。
Confirming the final configuration.
⏺ Searched for 1 pattern (ctrl+o to expand)
⏺ Completed. Overview of the created Cognitive Debt Reduction Mechanism:
.qa_session/
├── README.md ← 2-minute overview. Reading order guide.
├── AGENT_RUNBOOK.md ← Check before delegating to Agent. Autonomy, pitfalls, and completion criteria.
├── ARCHITECTURE_CONTEXT.md ← Tech map for zero-knowledge starts. Includes self-update rules.
├── reports/
│ └── QA-001_*.md ← Investigation history and rationale.
└── issues/
├── INDEX.md ← Central registry. Delegation-ready column, templates, self-update rules.
└── ISSUE-001 to 007_*.md ← Reference comments added to all entries.
Design choices implemented to reduce cognitive debt:
┌────────────────────────────┬────────────────────────┬──────────────────────────────────────────────────────┐
│ Feature │ Location │ Effect │
├────────────────────────────┼────────────────────────┼──────────────────────────────────────────────────────┤
│ Quick Turn-Around Table │ README.md │ Identifies "what to read" in 2s based on objective. │
├────────────────────────────┼────────────────────────┼──────────────────────────────────────────────────────┤
│ Delegation Readiness Table │ INDEX.md + RUNBOOK.md │ Instant judgment on whether to assign to an Agent. │
├────────────────────────────┼────────────────────────┼──────────────────────────────────────────────────────┤
│ Pitfalls & Exit Criteria │ RUNBOOK.md Section 3 │ Defines "what not to do" and "definition of done." │
├────────────────────────────┼────────────────────────┼──────────────────────────────────────────────────────┤
│ Copy-Paste Templates │ INDEX.md │ Ready to paste immediately when launching an Agent. │
├────────────────────────────┼────────────────────────┼──────────────────────────────────────────────────────┤
│ Glossary │ CONTEXT.md Section 1 │ Prevents Agents from stalling on specific jargon. │
├────────────────────────────┼────────────────────────┼──────────────────────────────────────────────────────┤
│ File Map (Copy-Ready) │ CONTEXT.md Section 2 │ Minimizes time spent searching for file paths. │
├────────────────────────────┼────────────────────────┼──────────────────────────────────────────────────────┤
│ Dual-System Diagram │ CONTEXT.md Section 3 │ Forces understanding of the biggest trap first. │
├────────────────────────────┼────────────────────────┼──────────────────────────────────────────────────────┤
│ Self-Update Rules │ End of each file │ Prevents info decay. Defines update timing/targets. │
├────────────────────────────┼────────────────────────┼──────────────────────────────────────────────────────┤
│ HTML Comment Ref Lines │ Header of all ISSUES │ Ensures navigation to vital docs from any issue. │
└────────────────────────────┴────────────────────────┴──────────────────────────────────────────────────────┘
※実際には日本語で出力されており以下の通り：
まとめ
ファクトベースとして開発の中間ドキュメントを残していき、かつそれらが正しいことを保証するとともに、我々の認知負債も抑え、すぐに着手できるような内容を残していくのが、今の所の私のベストプラクティスだ。
古典的だが、結局、セキュリティ検証する作業をAIに代替させる際も、こっちの方が楽だったりする。