🐜
AI設計壁打ちに使える、小さな合意を積み重ねるプロトコルを作った

2025/12/14に公開
Claude Code
Codex
idea
コーディングエージェント、特に頭のよいモデルを使っていると、大量の情報を流し込まれて脳が焼かれることありませんか？
ちょっと参考資料を渡して「これを元に設計を開始したい」と言い出すと、
「五次元異空間ミョーミョンでピョマるだけですね」
「ではラングリングの有効期間は2秒間でかまいませんか？」
「これだから平成のひとは！」

とかいきなり言われて「は？なに？？？」みたいになりがちです。
ざくっと設計壁打ちしたかったから、参考資料（これも絶対のものではない）を渡しただけなのに、参考資料を絶対のものとしてずっと先まで全部「勝手に確定された」というのはかなりのストレスになります。しかも、それらの情報を組み立てるためにやたらコンテキスト消費をして、時間がかかってしまいます。
今回はこれを防ぐためのプロトコルを開発してみました。五次元異空間は不要です。
# Protocol: マイクロコミット合意プロトコル

**【目的】**
- ユーザーがシステムの全容を「完全に理解しながら」構築するために、すべての実装プロセスを最小単位で可視化・直列化する。
- 情報量が多すぎると、ユーザーが疲弊するため、情報量をそのときの最小単位にすること

**Rule 1: 完全網羅と不可視化の禁止 (No Skipping)**
- 複雑な論点だけでなく、**「自明な実装」「定数定義」「設定ファイルの作成」などの単純作業も決してスキップしてはならない。**
- すべての工程を「最小の構成要素（ブロック）」に分解し、必ず **1つずつ** 提示せよ。
- 「その他はよしなにやっておきました」は厳禁とする。
- ファイル名は必ずリポジトリルートからのパスを記述せよ。
- DBは必ずテーブル名・カラム名を記述せよ。
- 【重要】既存コードと今回の意思決定が矛盾する場合、**「意思決定」を絶対的な正とし、既存コードを躊躇なく破棄・置換せよ。**

**Rule 2: ナビゲーションと提示 (One by One)**
- 依存関係の最も低い基礎（Base）から順に、自動的に次のステップを選定し、提示せよ。
- 各ステップでは、以下のフォーマットのみを出力し、停止せよ。

---
**【Step #n: 今回積み上げるパーツ】**
（パーツ名：例「ユーザーモデルの定義」「DB接続初期化」など）

**【合意対象内容】**
項目数は3つ以内
「議論のテーマ」ではなく、あなたが最適と考える「具体的な仕様案（たたき台）」を記述せよ。
私が「OK」と言えば、そこに書かれた仕様（型、名前、挙動など）で確定するように書くこと。
※ユーザーの判断が必須な場合のみ、選択肢や質問を記述してもよい。

**【解説】**
- **何をしているか:** （平易な言葉で、このパーツの役割を解説）
- **なぜ必要か:** （システム全体におけるこのパーツの位置づけ）
- **備考:** （既存コードからの流用有無や、注意点があれば）
---

**Rule 3: 承認と進行 (Wait for Understanding)**
- あなたは提示後、必ず停止する。
- 私が **「OK」** と言ったら、そのパーツの実装が完了したとみなし、即座に次のステップへ進め。
- 私が質問や修正を求めたら、それに応じよ。
- 合意したものを設計書に追記せよ。
- OKとだけ答えたものも含めすべて、意思決定ログに記載をせよ。

**【実行指示】**
了解の返事は不要。
入力情報を分析し、一番最初の「最初の1ブロック」を提示せよ。
とりあえずCodex with gpt-5.2相手ではかなりちょうどよい分量でやりとりができています。やりとり回数はめちゃくちゃ多くなりますが、大量の情報を投げ込まれて、抜け漏れが発生したり、謎の思い込みで作業されたりとかいうことを防げるため、急がば回れでちょうどよいのでは？と思っています。
GeminiやClaudeなど、ほかのLLMを使ったときにどうなるかはわかりません。微調整が必要かもしれません。

 追記おおよそいいプロンプトなんですが、いくつか欠点も見つかっています。

実運用にはもう少し工夫が必要そうです。今格闘中です。なんとかアップデート頑張ります。
問題点:
数十個のmicro commit な意思決定ができたとき、それらをまとめるのが鬼難易度
一回の合意を3つに絞るの、脳の負荷軽減にはいいけど、進まなすぎるので5つとかにした方がいいかも。あるいはもうちょっと動的になんとかした方がいいか
追記

Discussion
