「その提案、前例があります」— AIに同じ設計を3回提案されて、道具を作った

3週間前に却下した設計を、また提案される

AIエージェントと開発していると、こういうことが起きます。

7月に、自社CMS（Tessera）で「スキーマ生成チャットの承認フローを廃止して、AIの変更を直接適用にする」という案を検討して、却下しました。スキーマ変更は既存エントリにもAPIにも波及するので、AIに書かせる前に影響を見せて、追跡・巻き戻せる。その制御層こそがTesseraの取り柄で、承認を外すのは差別化を捨てることになる、という理由です。

で、しばらく経つと、また同じ提案が来るわけです。悪気はない。エージェントは前回の議論を覚えていないので、コードだけ見て「この承認フロー、要らなくないですか？」と真顔で言ってくる。優秀なほど言ってきます。

こっちは「前も同じ話したな……」と思いながら、また同じ理由を説明する。3回目くらいで、これは自分の記憶力の問題じゃなくて仕組みの問題だな、と思いました。

CLAUDE.md に書き溜めたら、太った

最初は素直に CLAUDE.md に「却下済み・提案しないこと」リストを書きました。これはこれで効くんですが、増えると別の問題が出ます。

CLAUDE.md は毎セッション全文が読み込まれるので、決定を書けば書くほどトークンを食う。手元で数えたら、決定22件・本文1.5万字で1セッションあたり約1万トークンでした。しかもその大半は、今やっている作業と関係ない決定です。記録するほど遅く、そして高くなる。

で、作った

Zenrei（前例）という名前にしました。やることは単純です。

• 決定は各リポジトリの decisions/*.md に置く。frontmatter が付いただけのMarkdown
• Zenrei はそれを索引して、MCP 経由でAIエージェントに配る
• エージェントが何か提案してきたら check_proposal で過去の決定と照合する
• 抵触したら止まる

実際の応答はこんな感じです。

エージェント: スキーマ生成チャットの承認フロー、廃止して
             直接適用にしませんか？

zenrei › check_proposal
⚠ 抵触する前例があります
  [rejected/却下済み] スキーマ生成チャットの承認フロー廃止
  （2026-07-08, repo: weave-cms）
  理由: 「AIに書かせる前に影響を見せる／追跡・巻き戻せる」
        制御層が堀そのものだから。承認を外すことは差別化の放棄になる。

プロンプトに常駐させるのは運用3行だけで、決定の本体は必要なときにツールの応答として返します。なので決定が1,000件に増えても、返ってくる量はほぼ変わりません。照合はLLMを使わない字句一致なので、APIキーも要らないし、1,000件でも44msで返ります。

md が正、というのは譲れなかった

決定データを自分のDBに囲い込む手もあったんですが、それは最初にやらないと決めました。正はあくまでリポジトリの中の md で、Zenrei は索引して配るだけ。データを持ちません。使うのをやめても、決定の全履歴は自分のgitの中にそのまま残ります。

自分が毎日使う道具なので、「やめたら記録を人質に取られる」のは嫌だな、というのが正直なところです。

決めるのは人間、AIは起票まで

もう一つ最初に決めたのが、AIは決定を確定できないということ。エージェントが record_decision で作れるのは「承認待ち（pending）」の候補までで、それを採用・却下に変えられるのは人間の承認コミットだけです。

AIが勝手に「これは決定です」と言い出したら、会話から自動抽出したメモと変わらなくなるので。

一ヶ月使ってみた

8月8日に最初の6件を書いてから、しばらく自分のプロジェクトで使ってみて、9月4日に「問題なさそう」と判断して次に進みました。使っていて良かったのは3つです。

却下が「打ち切り」じゃなくなった。 決定ファイルには「再検討条件」を書く欄があるので、「今はやらない、ただし◯◯になったら再検討」という保留ができます。実際、需要が出るまで保留にしていた機能が、条件が成立して正式に復活しました。却下や保留が、条件付きの前例として生き続ける感じです。

プロジェクトを跨ぐ。 索引は全リポジトリ横断で1つなので、別プロジェクトで作業中のエージェントも過去の決定に当たります。「コーポレートサイトはAstroで作る」と決めてあれば、まったく別のリポジトリで「ブログはWordPressで立てましょうか？」と言われたときに、ちゃんと前例が出てきます。

3ヶ月後の自分に効く。 これは想定してたより効きました。search_decisions で「なんでこうしたんだっけ」が理由と日付つきで返ってくる。git log を掘るより速いです。

自分のルールが、素通りした話

情けない話も書いておきます。

つい先日、「M2からM4まで一気に実装して、計測は後回しにしましょう」という提案が来ました。これは自分のプロジェクト原則に真っ向から反しています。マイルストーンごとに実測で判定して、ゲートを飛ばさない、と最初から決めていたので。

で、check_proposal に照合させたら——素通りしました。何もヒットしない。

理由は単純で、その原則を CLAUDE.md にしか書いていなかったからです。決定ファイルになっていなかった。Zenrei が配れるのは decisions/*.md にあるものだけなので、そりゃ止まらない。

自分で作った道具に「お前のルール、登録されてないぞ」と言われた形です。ルールはガバナンスの対象になって初めて機能する、というのを自分のプロダクトで踏み抜きました。すぐ決定ファイルに起こしました。

公開しました。いまは無料です

ローカルで動くMCPサーバーを npm に出しています。MITライセンスです。

claude mcp add zenrei --scope user -- npx -y zenrei --root /path/to/repo1 --root /path/to/repo2

あとは各リポジトリの CLAUDE.md に3行足すだけ。詳しくは運用の手引きに書いてあります。

GitHub App で承認UIやPRとの照合ができるホスト版も動いていて、いまカラクリオの9リポジトリで運用中です。このサイトの構成をどうするかとか、さっき書いたZenrei自身の設計判断も、全部Zenreiに入っています。

いまのところ全部無料なので、気になったら自由に使ってみてください。 ローカルのMCPは今後もずっと無料のつもりです。

使ってもらって、直したい段階です

正直なところ、まだ「作って自分で使ってみた」の次くらいの段階です。

いまは実際に使ってもらって、どの提案がどれくらい止まったか、逆にどこで取りこぼしたか、といったデータを溜めているところです。照合は字句一致だけなので、言い回しが違うと素通りする取りこぼしは確実にあります。そういう実例が集まってから、埋め込みなりLLM判定なりを足すかを決めるつもりです。

なので、使ってみて「ここが引っかかった」「これは止まってほしかった」があれば、ぜひ教えてください。お問い合わせからでも、GitHubのissueでも。そのまま次の改善に入れます。

おわり

AIと同じ議論を2回してイラッとしたことがある人には、たぶん効きます。また書きます。