反対材料を出させ、決めるのは人｜事業計画をAI3役で作り直した当社の型

AIに事業計画を書かせると、顧客、入口、数字が、それらしい形で並びます。それでも、出てきた計画を信じていいか分からない、という感覚が残ることがあります。賛成しかしない相手に、自社の前提がどこで崩れるかを聞いても、返ってこないことが多いからです。

私は2026年8月23日、事業計画を作り直す作業を、起草、反証、監査の3役に分け、決めるのは自分、という型で進めました。v1まで約20分、4件の決定まで約30分でした（前段の議論を含めると約2時間）。3つのAIを使う自慢ではありません。反対材料を義務づけ、最後は人が裁定する、という話です。

AI3役と人の裁定という役割の分け方

役割は次の4つです。

起草役（PdM）は Claude Code です。現状の実測値を集め、事業計画 v0 を1枚に書きます。中身は顧客、入口、商品の段階、粗利の感度、KGI と KPI です。

反証役と偵察は Grok（CLI）です。web で一次情報を6問調べます。対象は公的統計、公式の価格情報、補助金の公式ページで、URL を付けます。v0 の「崩れる前提」を深刻度順に5つ出し、数字の矛盾、代替案、ファネルへの反証を書きます。

監査役は Codex（CLI）です。社内の正本文書と実装コードを読み、v0 が正本と矛盾する箇所を行番号付きで出します。KPI が実際に自動計測できるかを実装から判定し、数字を検算し、承認前に直す点を書きます。

裁定と決定は、経営者本人である私です。3者の所見を突合した司会（Claude Code）のまとめを読み、決定を下します。この日の決定は4件でした。

ポイントは、賛成を増やすことではありません。反証役の仕事は、崩れる前提を書くことです。監査役の仕事は、正本と実装との食い違いを書くことです。決める役は AI ではありません。

事業計画を作り直した当日の流れ

同日、議論はターミナル1本に3者の発言を流し、私は画面で見ていました。

17:07、司会が議論ログを開始しました。 17:08、v0 を提示し、同時に Grok（偵察と批判）と Codex（監査）を並走で起動しました。 17:10、司会が自分でも一次情報を裏取りし、補助金の公式ページを取得しました。 17:17、Grok が完了しました。調査269行、批判171行です。 17:18、司会が Grok の引用を一次資料（公的レポートの PDF）で突合しました。Grok の1箇所を「言い過ぎ」と訂正しています。報告書は「観察」であって「推奨」ではない、という指摘です。 17:24、Codex が完了しました。監査151行です。 17:25、司会が「一致した指摘」と「対立点と裁定」を整理しました。 17:26、v1 を提示しました。 17:34、私が4件を即決し、正本化しました。中身は、承認、中段商品の価格帯、外部パートナーの稼働の扱い、自分の時間単価です。

v1 まで約20分、4件の決定まで約30分でした（前段の議論を含めると約2時間）。速さを売りにする話ではありません。反対と監査が、同じ画面に乗った、という記録です。AI の出力をそのまま正本にはしていません。

3者が一致した指摘

一致した指摘は、採用しました。当社の場合、次の4つです。

1つ目。最初に置いた KGI は、契約件数、売上、事例本数、リード件数の4本でした。根拠がありません。正本にあった「伴走1社」を KGI の先頭に戻し、まだ握れていない供給、つまり外部パートナーの実装に依存する受注は、KGI から外しました。

2つ目。制約は固定費ではなく、経営者の時間です。KGI に「時間内で達成」を入れ、時間を金額換算した「経済的な固定費」を別に置きます。枠組みは、私の師である西順一郎氏の戦略会計です。粗利から固定費を引いたものが利益、という見方です。

3つ目。KPI は10項目ありました。現行の自動レポートで、定義どおり計測できるものは0件でした。Codex が実装を読んで判定しています。計測の仕組みは、別の実装計画に切り出しました。

4つ目。売上の感度計算に、計算違いがありました。Codex の検算で判明しています。

当社の場合、反証と監査を役割にしたから、この4つが先に出ました。

割れた点と経営者本人の裁定

割れたのは、新しい入口です。古い社内システムの作り替えを、どこまで計画に乗せるか、という点でした。

Grok は、需要の証明が無い、と見ました。公的統計では、中小企業の多くは標準パッケージへ移行しています。同等機能の SaaS は広く出ており、補助金は登録済みツールが対象です。

Codex は、新しい入口を第一ターゲットと同格にすると、軸がぼける、と見ました。

私の仮説は、古いシステムの悩みはファネルの上段になる、というものです。

裁定は、私が下しました。仮説は「検証対象」として残します。KGI に「新入口の有料検討2件、受注1件、0件なら年末に捨てる」を置きます。中段商品は、「作り替えの計画書」から「移行判断書」へ再定義します。SaaS で済むか、作り替えが要るか、を先に判断する、という意味です。差別化は「業務を変えない移行」です。根拠は、公的レポートの観察です。カスタマイズしている企業は、移行先でもカスタマイズを続ける、という記述でした。

AI が割れたとき、多数決にはしませんでした。仮説を捨てるのでも、KGI の先頭に据えるのでもありません。検証対象として期限と件数を付けた、というのが人の裁定です。

AIの反対材料が判断を変えた実例

この日の前段で、反対材料を義務づけるルールが、判断を動かしたやりとりがあります。

司会（Claude Code）が、「受託を増やすと主力 KGI から注意が逸れる」と反対材料を出しました。私は、「実装を外部パートナーに渡すなら、その前提は崩れる」と反論しました。司会は前提の誤りを認め、撤回しています。

反対を出すことが役割だから、前提の誤りが表に出ました。反対材料を義務づけるルールがあるから起きたやりとりです。

もう1つあります。前日に「受託はサイトに載せない」と決め、正本に書いていました。翌日、日報の作り替えが本番保守まで回り、実装と保守を担う体制も整ったので、私は「載せて受ける」に変えようとしました。司会は「昨日の正本と矛盾する」と止めました。私は「前提が変わったのに、昨日決めたことを守ることにプラスがあるのか」と聞きました。司会は、「守ること自体に価値はない。正本の書き換えは判断のゲートではなく、食い違いを防ぐ記録だ」と位置づけを訂正し、その日のうちに正本を書き換えました。

正本は、昨日の自分を縛る錠ではありません。前提が変わった日に、理由を添えて書き換える記録です。変えた事実と理由が残るから、次の判断で同じ議論を繰り返さずに済みます。

監査役に渡した内部文書と、司会が読んでいたもの

この議論が1日で成立した前提を、先に書いておきます。3つのAIの性能の話ではなく、司会と監査役が何を読める状態にあったかの話です。当日の議事録から、実際に参照されたものだけを挙げます。

これらは、この日のために用意したものではありません。判断のルール文書は2026年3月から132回書き換え、正本文書は事業ごとに分け、実測はレポートとして毎日自動で届くようにし、本の内容は要約にして読ませてあります。間違えた日にルールを直し、決めたことを正本に書く。その積み重ねが、監査役に渡す「内部文書」の中身です。

逆に言えば、1つのAIで同じ型を回すときも、渡すものはこの4つです。正本が無ければ、まず「自社のルールと数字を1枚にする」ところから始まります。次の手順は、それを前提に書いています。

1つのAIで同じことを進める手順

3つの AI が揃っていないと、この型は使えない、という話ではありません。同じ AI でも、会話（セッション）を分ければ、同じ手順を踏めます。

まず起草役の会話です。現状の実測値を渡し、顧客、入口、商品の段階、感度、KGI と KPI を1枚に書かせます。これが v0 です。

次に反証役の会話です。自社の内部文書は渡しません。公開情報と叩き台だけを渡します。独立性を保つためです。「賛成でも反対材料を出せ」「一次情報の URL を付けろ」と指示します。崩れる前提を深刻度順に出させ、数字の矛盾、代替案、ファネルへの反証も出させます。

次に監査役の会話です。こちらには内部文書を渡します。整合性を見るためです。「自社の既存ルールや数字と矛盾する箇所を、行番号で出せ」と指示します。KPI が計測できるか、計算が合うかも、ここで見ます。

決めるのは人です。AI には決定の選択肢を出させ、選択肢ごとに推奨と理由を付けさせます。推奨をそのまま採用する必要はありません。当社の当日も、割れた点は多数決ではなく、私の裁定でした。

結果は1枚の正本に書きます。昨日の決定と食い違ったら、当日中に書き換えます。

自分でやる型は、この手順です。会話を3つに分け、反証には内部を渡さず、監査には内部を渡し、最後は人が決める。ツールが1つか3つかより、役割が混ざっていないか、のほうが大きい、と私は見ています。

この型を自分の会社で回したい方へ

この記事の型は、経営者本人が手を動かす「自分でやる型」そのものです。当社は、自分で生成AIを触ってはいるが業務に組み込めていない経営者本人に、月2回の面談とチャットで伴走しています。古い社内システムを自分で作り替えた記録は「古いPHP5の日報をClaude Codeで作り替え本番保守まで続けた記録」に書きました。まずは「無料で相談する」からで構いません。

よくある質問

3つのAIを契約していないと、この型は使えないか

使えなくはありません。前の節のとおり、同じ AI でも会話を分ければ、起草、反証、監査を別々に演じさせられます。当社の当日は3つのツールを並走させましたが、それは所要時間の話であって、型の条件ではありません。

AIが出した一次情報は、どこまで信じてよいか

そのまま信じません。当社の場合、Grok の引用を、司会が公的レポートの PDF で突合しています。1箇所は「言い過ぎ」でした。報告書の観察を、推奨であるかのように読んでいたためです。反証役に URL を付けさせることと、人が一次資料を開くことは、別の作業です。

反対材料を出すと、話が進まなくなるのではないか

当社の場合、進みました。一致した指摘は採用し、割れた点は人が裁定しています。v1 まで約20分、4件の決定まで約30分です（前段の議論を含めると約2時間）。反対を出さないほうが早い、というより、根拠の無い KGI や計測できない KPI、計算違いが、先に出てきた、という記録です。

昨日の決定と食い違ったとき、どちらを守るか

守ること自体に価値はありません。当社の場合、正本の書き換えは判断のゲートではなく、食い違い防止の記録です。当日中に書き換えます。昨日の文面を残したまま、今日の判断だけが進む、という状態を避けるためです。

まとめ

• AI に事業計画を書かせたあと、「信じていいか分からない」が残るなら、賛成を増やすより、役割を分ける。
• 起草、反証、監査を分け、反証には内部文書を渡さず、監査には渡す。決めるのは人。
• 当社の場合、3者が一致した指摘（根拠の無い KGI、時間制約、計測できない KPI、計算違い）は採用した。
• 割れた点は多数決にせず、仮説を検証対象として期限と件数を付けた。
• 1つの AI でも会話を分ければ足りる。結果は1枚の正本に書き、食い違ったら当日中に書き換える。