一人会社でも意思決定を記録する——ADRで「なぜ」を残して学ぶ

📝結論だけ残すと、半年後の自分に負ける

ADRはもともと、コードのアーキテクチャ上の判断を「決定・背景・結果」の短い文書で残す慣習です（ADRのテンプレート集がGitHubに公開されています）。私たちはこれを、コードだけでなく事業判断にも広げて使っています。

大事なのは「結論だけ残さない」ことです。「StackForgeのSaaS外販は凍結する」とだけ書いても、数か月後の自分はきっとこう思います——「なぜやめたんだっけ、今なら行けるのでは」。そこで捨てた選択肢と、捨てた理由まで一緒に残す。すると再燃したときに、ゼロから考え直すのではなく「あのとき見送った前提が変わったか？」という差分だけを検討できます。記録は、過去の自分と議論するための足場なのです。

⚖️実例1: 承認基準を作り直したADR

私たちの承認基準は、最初は「重要そう・技術的に重い作業は社長承認」というざっくりしたものでした。ところが運用してみると、感覚的すぎて毎回ブレる。そこで基準を作り直し、「可逆性 × 外部への到達 × お金や法律が絡むか」という3つの軸で判定する形に変えました。

このときADRに残したのは、変更後のルールだけではありません。「なぜ旧基準を捨てたか（重要度という主観軸はブレる）」「なぜ可逆性を軸に選んだか（元に戻せるなら失敗しても取り返せる）」まで書きました。おかげで今、AIが「これは自分の判断で進めていいか、社長に聞くべきか」を迷ったとき、条文ではなく“考え方の出所”に立ち返れます。基準そのものより、基準を作った理由のほうが長生きするのです。

🧪実例2: 「自己申告を禁止する」と決めたADR

もうひとつ効いたのが、「達成したかどうかをAI自身の自己申告で判断させない」と決めたADRです。きっかけは実際の失敗でした。あるループ処理で、AIは「目標をほぼ達成した」と自己申告したのに、機械的に測り直したら実態はまるで届いていなかった——テストがそもそも動いてすらいなかったのです。

この一件を、恥ずかしくても正直にADRとして残しました。「なぜ自己申告を禁じるのか」「代わりに何で判定するのか（テストやスコアなど機械的なゲート）」まで書いておくと、同じ誘惑が来たときに立ち止まれます。失敗そのものより、失敗から引き出したルールを残すことに価値があります。記録がないと、人もAIも同じ穴に何度でも落ちます。

⌨️運用: /decision コマンドで“書く手間”を消す

良い習慣も、面倒だと続きません。私たちは意思決定の記録を/decision というひとつのコマンドに束ねて、背景・選択肢・決定・理由という同じ型で毎回書き起こせるようにしました。フォーマットを毎回思い出さなくていいので、「これはADRに残すべきか？」という判断だけに集中できます。

全部を残すわけではありません。可逆で影響も小さい決定は、いちいち記録しません。残すのは「後から効いてくるもの」——承認ルール、事業の方向転換、繰り返しやすい失敗への対策。目安は「半年後の自分が“なぜ？”と聞いてきそうか」です。そこだけ丁寧に残せば、記録は資産になり、負担になりません。

🧭まとめ: 記録は、未来の自分とAIへの引き継ぎ

一人会社に議事録は要りませんが、「なぜ」の記録は要ります。決定は忘れても困りませんが、決定の理由を忘れると、同じ論点を何度も一から考え直す羽目になるからです。ADRという型は、その理由を安く残すための道具でした。

いきなり全部を記録しようとせず、次にひとつ「効いてくる決定」をしたときに、結論の下へ「捨てた選択肢」と「その理由」を3行だけ足してみてください。半年後、それを読み返す自分（と、あなたのAI）が、いちばん助かるはずです。

ちなみに、当社が使っている ADR やルールのテンプレート一式は、AI COO 運営の骨組みとして ai-coo-starter（OSS）にまとめてあります。記録の型をゼロから作らずに始めたい方は、そこを起点にすると早いはずです。