提案書はAIに一度ボコボコにさせてから出す

3行まとめ

• 提案書や施策をひとりで作る人向けに、AIを「潰す側」に固定してレビューさせる型を、プロンプトの実物と実行ログつきで書いた
• 架空の提案書に穴を8個仕込んで実演。素の「どう思う？」との差は、検出力より出力の形に出た
• 一番難しいのは、返ってきた指摘の採否を自分で決めること。検証用の一次資料は記事末尾の付録にある

レビューのない成果物

エンジニアだった頃、自分の成果物には必ずレビューがあった。
雑なコードを書いても、マージされる前に誰かが止めてくれた。
品質は自分の注意力ではなく、仕組みで守られていた。

企画側に回って最初に戸惑ったのは、その仕組みが消えたことだった。

施策の提案書、制度の設計書、経営層向けの資料。
上長の確認はある、という反論はあるだろう。
だが多くの場合それは承認であって、観点を決めて壊しにかかるレビューではない。
同僚は自分の業務で手一杯だし、そもそも社内に同じテーマを検討している人がいない。
壁打ち相手がいないまま、ひとりで作ったものが実質ノーレビューで経営会議に出る。

コードなら怖くてできない運用を、私自身、企画側では平気でやっていた。

この記事では、そのレビュアー不在をAIで埋める方法を書く。
AIに感想を聞くのではなく、批判する役割を明示的に与えてレビューさせる。
私はこれを敵対的レビューと呼んで、日常的に運用している。
発想自体は新しくない。
組織論で言うレッドチームや devil's advocate の、AI相手の焼き直しだ。
新しいのは、ひとりで回せるようになったことのほうだ。

なぜ「どう思う？」ではダメなのか

提案書をAIに貼り付けて「どう思う？」と聞く。
これでも、何かしらの指摘は返ってくる。
実際、後述する架空の提案書を素の聞き方で見せてみたら、褒め言葉では済まず、主要な穴はあらかた指摘された。
今のAIは、素で聞いてもそれなりに斬ってくる。

それでも、素の質問をレビューとは呼べない。
何をどこまで見た結果なのかが分からないからだ。
観点の選択はAI任せで、返ってくる形も、相談の返事だったり批評だったりと揺れる。
AIにはユーザーに同調しやすい性質もあり（sycophancy と呼ばれる、よく知られた挙動だ）、私の体感では、草案を一緒に作った会話の続きで意見を求めると甘い側に振れやすい。

コードレビューを思い出してほしい。
良いレビュアーが見ているのは、壊れるとしたらどこか、だ。
そして観点を決めて見るから、誰がいつ読んでも見落とす場所が大きくは変わらない。
型が保証するのは、この「何を、どういう姿勢で見たか」という入力の側だ。
返ってくる指摘の中身は毎回揺れる。
それでも、4つの観点を潰す側の目で通した、という土台だけは毎回変わらない。

それをAIにやらせるには、役割と観点を明示的に設計する必要がある。

敵対的レビューの型

私が回している型は、セッションの分離、攻撃観点の指定、プロンプト、収束条件の4つでできている。
私は普段Claudeを使っているが、型自体に特定ツール依存の要素はないので、役割と観点を指定できるチャットAIなら通用するはずだ。

草案とレビューでセッションを分ける

草案を作った会話の中で「じゃあ批判して」と頼むのは避ける。
同じセッションのAIは、草案を一緒に作った文脈に引きずられて、私の体感では成果物に甘くなりやすい。
書いた本人にレビューさせない、という人間の組織と同じ理屈だ。
レビューは文脈を持たない別セッションでやる。
新しい会話を立ち上げて、成果物だけを渡す。

攻撃観点を指定する

「批判して」とだけ頼むと、批判の網羅性がAI任せになる。
私は毎回、次の4観点を指定している。

• 穴：根拠が示されていない主張、論理の飛躍
• 矛盾：文書内で言っていることが食い違っている箇所
• 漏れ：本来検討すべきなのに触れられていない論点。リスク、コスト、代替案、反対意見
• 過剰：目的に対してやりすぎな範囲や投資

経験上、読み返して自分で気づけるのは穴と矛盾まで。
漏れには二種類ある。
知っているのに書き忘れたものは、読み返しや指摘で思い出せる。
怖いのは自分の知識の外にある漏れで、これはいくら読み返しても出てこない。
敵対的レビューで一番ありがたいのは、この種の指摘だ。

プロンプト

実際に使っているものをそのまま載せる。

あなたはこの提案書のレビュアーです。私の味方をする必要はありません。
経営会議でこの提案を潰す側の役割で、以下の4観点から批判してください。

- 穴：根拠が示されていない主張、論理の飛躍
- 矛盾：文書内で言っていることが食い違っている箇所
- 漏れ：本来検討すべきなのに触れられていない論点（リスク・コスト・代替案・反対意見）
- 過剰：目的に対してやりすぎな範囲・投資

指摘は重大度順に並べ、それぞれ「どこが」「なぜ問題か」「経営層ならどう突っ込むか」を
セットで書いてください。褒める必要はありません。
重大な指摘がなければ「重大指摘なし」とだけ答えてください。

工夫しているのは役割の固定と、褒め言葉の封じ込めだ。
冒頭で味方でないことを明言し、潰す側の役割に固定する。
「経営層ならどう突っ込むか」を言わせると、指摘がそのまま想定問答になる。
最後の二行は褒めの出口を塞ぐためのもので、これを書かないと同調バイアスが戻りやすい。

注意点をひとつ。
末尾の一文は、重大性の一次判定をAIに委ねる設計でもある。
軽微な指摘まで自分で仕分けたい場合は、「重大指摘なしの場合も、軽微な指摘は列挙してください」に変えるといい。

収束条件

指摘を受けたら改訂し、改訂版をまた別セッションのレビューにかける。
このとき渡すのは改訂版だけで、前の指摘の履歴は渡さない。
毎回まっさらなレビュアーに見せるためだ。

これを、新しい重大指摘が出なくなるまで繰り返す。
完全なゼロは目指さない。
レビューの出力は毎回揺れるので、回すたびに何かしらは出るからだ。
重大かどうかの線引きも、AIの表示ではなく自分で決める。
私は、経営会議でその場で答えられない指摘を重大として扱っている。
つまりこの収束は品質の証明ではなく、書き手として答えられる状態になった、という確認にすぎない。
体感では、1巡目で構造の問題、2巡目で詰めの甘さが出て、3巡目には打ち切れることが多い。

3巡しても新しい重大指摘が止まらない場合、私の経験では、前提が曖昧なまま書いているか、指摘同士が対立しているかのどちらかだった。
ループで粘らず、対立している論点を整理して、自分か上位者の判断に切り替える。

揺れへの対処としては、同じ版に並列で何度かレビューをかけて、指摘の和集合をまとめて潰す手もある。
私が逐次で回しているのは、1巡ごとに直したほうが、トータルで読む量が少なく済むからだ。

ダメな提案書はどう変わるか

型だけでは伝わらないので、実際にやってみせる。
お題は架空だが、レビューのログは実際にAIが返したものだ。

開発部門への生成AIコーディング支援ツール導入、という提案書を、ありがちな詰めの甘さを残したまま書いた。

期待効果

コーディング効率が30%向上し、開発部門全体（150名）で年間約9,000万円相当の工数削減が見込める。

導入計画

全エンジニア150名に一斉導入する。ツールは直感的に使えるため、追加の教育コストは不要である。
導入スケジュール：契約後1ヶ月目に全社展開、2ヶ月目に全エンジニア向け活用研修（2週間）を実施。

費用

ライセンス費：月額6,000円 × 150名 = 月90万円（年1,080万円）
費用対効果：9,000万円の削減効果に対し1,080万円の投資であり、ROIは約8.3倍。

パッと見はそれっぽい。
これに先ほどのプロンプトでレビューをかけた。
モデルはClaude、実行は1回きりで、結果の選り好みはしていない。
指摘が8件、重大度順に返ってきて、一言目は「この提案書は経営会議を通りません」。
上位から3件を抜粋する。

指摘1【穴・重大】9,000万円という効果額の算定根拠が一切ない
数字の導出過程がブラックボックス。エンジニアの業務時間のうちコーディングは一部（一般に3〜5割）であり、仮にコーディングが30%効率化しても総工数の削減は10%前後にしかならないが、その換算過程が示されていない。
経営層の突っ込み：「9,000万の計算式を今この場で書いてくれ」「30%はどのベンダーのマーケティング資料から持ってきた？」

指摘2【穴・重大】ROI 8.3倍は幻。工数削減はキャッシュを1円も生まない
人件費は固定費であり、工数が削減されても、人員を減らすか浮いた工数で追加の売上を作らない限り、財務上の効果はゼロ。みなし効果と実際のキャッシュアウトを同じ土俵で割り算しており、財務的に成立していない。
経営層の突っ込み：「その9,000万は、P/Lのどこに、いつ現れるんだ？」

指摘4【漏れ・重大】セキュリティ・知財・顧客契約リスクへの言及がゼロ
このツールは自社・顧客のソースコードを外部サービスに送信する。受託開発であれば顧客との契約でAIツール利用が制限されている可能性があり、無断利用が発覚すれば契約違反・取引停止。これに触れていない提案は稟議の土俵に乗らない。
経営層の突っ込み：「顧客のコードをこのツールに入れていいと、どの契約書に書いてある？」

このほか、教育コスト不要と言いながら2週間の全員研修を組んでいる矛盾（150名×2週間は約6人年。人件費に換算すればライセンス費の数倍の隠れコストだ）、効果未検証のままの150名一斉導入、効果測定のKPIと撤退基準の欠落まで、残り5件が続いた。

白状すると、この草案には、レビューが検出できるかを試すための穴を8個仕込んでいた。
レビューは8個すべてを拾った。
そのうえで、仕込んでいない指摘を4件返してきた。
1件の指摘が複数の穴をまとめて突いてくるので、8件の指摘に12論点が入っている勘定になる。
草案の全文、仕込んだ穴のリスト、レビューの応答全文は、検証できるよう記事末尾に付録として置いた。

わざと開けた穴が見つかること自体は、当然と言えば当然だ。
実際、対照として素の「どう思いますか？」でも見せてみたが、こちらも仕込みの大半を拾い、後述するキャッシュの論点まで出してきた。
検出力だけなら、この草案レベルの穴には素の質問でも足りる。
差が出たのは出力の形だ。
素の応答は、褒めどころと改善提案が混ざった相談の返事。
型の応答は、重大度順の指摘と想定問答。
そのままレビュー結果として扱えるのは後者で、私が型を使い続けている理由もそこにある。

もうひとつ、このデモで見てほしいものがある。
想定外の指摘の扱いだ。

想定外の筆頭が指摘2だった。
工数削減の金額換算が甘いことは、仕込んだ本人なので分かっていた。
だが、削減効果がそのままキャッシュになるわけではない、という財務の論点は、私の想定になかった。
自分の知識の外にある漏れは、いくら読み返しても出てこない。
それが外から来た瞬間だ。

ただし、この指摘をそのまま飲んでもいない。
「1円も生まない」は言い過ぎで、残業代や外注費の削減、増員の抑制など、工数削減がキャッシュに効くルートはある。
言い過ぎだが、換算の道筋を書いていないのは事実。
そう判断して、浮いた工数の使途を明記するという形で部分的に採用した。
返ってきた指摘を検証して、採る部分と流す部分を決める。
実は、この採否の判断がこの型でいちばん頭を使うところだ。

改訂では、一斉導入への指摘を逆手に取って提案の構造ごと変えた。
150名一斉導入（年1,080万円）の承認を求めるのをやめ、30名×3ヶ月のパイロット（約54万円）の承認を求める提案に組み替えた。
効果は計算式とKPIを決めてパイロットで実測する計画に置き換え、浮いた工数を何に使うかを明記し、セキュリティと契約確認の節を新設した。

改訂後の依頼事項はこうなった。

ご依頼事項

パイロット導入（30名・3ヶ月・ライセンス費 約54万円）の承認。
3ヶ月後にKPIの実測値を報告し、アクティブ利用率60%以上かつPRサイクルタイム10%以上の改善で全社展開を再上程する。基準未達の場合は契約を終了する。

「1,080万円ください、ROIは8.3倍です」が、「54万円で検証させてください、ダメなら止めます」に変わっている。
改訂版の全文は付録に置いた。

これで完成ではない。
改訂版をレビューにかければ、パイロットの選定基準や成功基準の数値など、次の指摘が出るだろう。
それでも、求める承認が年1,080万円の全社導入から54万円の検証に変わり、根拠がベンダーの数字から自社で実測する計画に置き換わった時点で、文書の通りやすさは別物になっている。
敵対的レビューは粗探しの道具に見えて、実際には提案を通りやすい形に組み替える道具になる。
想定問答を用意して守るより、突っ込まれる前に提案の形を変えてしまうほうが効く。

落とし穴

運用して分かった注意点も書いておく。

大前提として、機密の扱いは自分の会社のルールに従うこと。
提案書を社外のAIに貼る行為は、実例の指摘4が言うコードの外部送信と同じ構造を持っている。
会社が認めたツールとプランを使い、渡してよい情報の範囲を確認してから使う。
この記事の実例が指摘しているリスクを、この記事の運用で踏んだら世話がない。

まず、AIの指摘を全部は飲まないこと。
敵対的レビューを指示されたAIは、役割に忠実であろうとして、的外れな批判や過剰な要求もしてくる。
体感では、1巡目の指摘のうち1〜2割は採用していない。
採否を決めるのは自分であり、全指摘に対応したことは品質の証明にならない。

文脈を知らないがゆえの指摘も混ざる。
予算枠や決定済みの前提を知らないレビュアーは、社内では解決済みの論点を突いてくる。
ただ、これはノイズと切り捨てる前に一度考える価値がある。
文書だけ読んだ読み手が同じ疑問を持つなら、その前提は文書に書き足すべきだからだ。
書くべきでない前提なら、流していい。

次に、重大指摘ゼロを安全証明だと思わないこと。
レビューを通っても、責任は書き手にある。
AIが演じる経営層は一般論の経営層であり、自社の役員が実際に気にする論点、社内の力学、過去の経緯は知らない。
そこは人間が自分で足すしかない。

最後に、全部の成果物にやらないこと。
敵対的レビューは1巡ごとに読んで直すコストがかかる。
数千字の提案書なら、私の場合1巡あたり30分から1時間、3巡で半日仕事になる。
だから、対外に出るものと、あとから引き返せない判断を含むものに絞ってかけている。
社内の軽いメモまでやるとレビュー疲れして、肝心なときに省略するようになる。

おわりに

企画側の成果物には、コードレビューにあたる仕組みがない。
AIに批判する役割を明示的に与えれば、その穴はかなり埋まる。
道具立てはプロンプト1枚で済むが、本当に要るのは、返ってきた指摘の採否を自分で判断する覚悟のほうだ。

なお、ここに書いたのは私ひとりの運用の型で、4つの要素のどれがどれだけ効いているかを分離して検証したわけではない。
自分の環境で崩して試して、効いた形を残してほしい。

敵対的レビューは、私が回している運用の一部でしかない。
アイデアの壁打ちから施策に育てて、成果物に仕上げるまでの全体の型は、別の記事で書く。

付録：デモの一次資料

本文のデモを検証できるよう、素材を加工せずに置いておく。

草案v1 全文（穴を8個仕込んだ版）

生成AIコーディング支援ツール導入のご提案

背景

生成AIによる開発支援は業界標準になりつつあり、当社も早急に導入すべき段階にある。

期待効果

コーディング効率が30%向上し、開発部門全体（150名）で年間約9,000万円相当の工数削減が見込める。

導入計画

全エンジニア150名に一斉導入する。ツールは直感的に使えるため、追加の教育コストは不要である。
導入スケジュール：契約後1ヶ月目に全社展開、2ヶ月目に全エンジニア向け活用研修（2週間）を実施。

費用

ライセンス費：月額6,000円 × 150名 = 月90万円（年1,080万円）
費用対効果：9,000万円の削減効果に対し1,080万円の投資であり、ROIは約8.3倍。

仕込んだ穴リスト（8個）と検出対応

#	仕込んだ穴	検出
1	効率30%向上に根拠なし	指摘1
2	30%から9,000万円への換算根拠なし	指摘1（コーディング比率の欠落まで特定）
3	教育コスト不要と研修2週間の矛盾	指摘3（研修コスト約6人年の試算付き）
4	セキュリティ（コード外部送信）の漏れ	指摘4
5	顧客契約上の制限リスク	指摘4
6	導入しない場合の比較軸なし	指摘8
7	パイロットなしの一斉導入	指摘5
8	ライセンス費以外のコスト欠落	指摘3と6

仕込んでいないのに返ってきた指摘：ROIのキャッシュ問題（指摘2）、ツール比較選定の欠如（指摘6）、KPIと撤退基準の欠如（指摘7）、導入理由がバンドワゴン論法（指摘8の前半）。

敵対的レビューの応答 全文（Claude・1回実行・無編集）

提案書を潰す側の視点でレビューしました。結論から言うと、この提案書は経営会議を通りません。重大度順に指摘します。

指摘1【穴・重大】9,000万円という効果額の算定根拠が一切ない

• どこが：「コーディング効率が30%向上し、開発部門全体(150名)で年間約9,000万円相当の工数削減」
• なぜ問題か：数字の導出過程が完全にブラックボックス。逆算すると「150名 × 年間人件費600万円 × 10%」あたりだが、30%と言いながら10%相当の金額になっており、計算前提すら文書内で再現できない。さらに致命的なのは、エンジニアの業務時間のうちコーディングは一部(一般に3〜5割)である点。仮にコーディングが30%効率化しても、総工数の削減は10%前後にしかならないが、その換算過程が示されていない。
• 経営層の突っ込み：「9,000万の計算式を今この場で書いてくれ。単価いくら、コーディング時間比率いくら、何を掛けて9,000万になった?」「30%という数字はどのベンダーのマーケティング資料から持ってきた? 自社での実測値か?」

指摘2【穴・重大】ROI 8.3倍は幻。工数削減はキャッシュを1円も生まない

• どこが：「9,000万円の削減効果に対し1,080万円の投資であり、ROIは約8.3倍」
• なぜ問題か：人件費は固定費であり、工数が削減されても人員を減らすか、浮いた工数で追加の売上を作らない限り、財務上の効果はゼロ。「工数削減相当額(みなし効果)」と「実際に支払うライセンス費(キャッシュアウト)」を同じ土俵で割り算しており、財務的に成立していない。浮いた工数の使途(採用抑制なのか、案件受注増なのか)が書かれていない以上、投資対効果は評価不能。
• 経営層の突っ込み：「その9,000万は、P/Lのどこに、いつ現れるんだ? 来期の採用計画を減らすのか? 売上目標を上げるのか? どちらも書いてないなら、確実なのは年1,080万のコスト増だけだ」

指摘3【矛盾】「教育コスト不要」と言いながら2週間の全員研修を計画している

• どこが：導入計画の「追加の教育コストは不要である」と、同じ段落の「2ヶ月目に全エンジニア向け活用研修(2週間)を実施」
• なぜ問題か：文書内で正面衝突している。しかも150名 × 2週間 = 約300人週 ≒ 6人年分の工数であり、人月単価で換算すれば数千万円規模。ライセンス費1,080万円を上回る可能性が高い隠れコストなのに、費用欄に1円も計上されていない。これを含めるとROIの計算は根本から崩れる。加えて「1ヶ月目に全社展開、2ヶ月目に研修」という順序も不自然で、未教育のまま1ヶ月使わせる計画になっている。
• 経営層の突っ込み：「教育コスト不要なら、なぜ2週間も研修するんだ? 研修が必要なら『直感的に使える』は嘘だし、150名を2週間拘束するコストはいくらだ? それを費用に入れたらROIはいくつになる?」

指摘4【漏れ】セキュリティ・知財・顧客契約リスクへの言及がゼロ

• どこが：文書全体。リスクの章そのものが存在しない。
• なぜ問題か：生成AIコーディングツールは (1) 自社・顧客のソースコードを外部サービスに送信する、(2) 生成コードのライセンス汚染・著作権の帰属問題がある、(3) 受託開発であれば顧客とのNDAや契約でAIツール利用が制限されている可能性がある。特に(3)は、無断利用が発覚すれば契約違反・取引停止という導入メリットを一瞬で吹き飛ばすリスクであり、これに触れていない提案は稟議の土俵に乗らない。情報システム・法務のレビューを通した形跡もない。
• 経営層の突っ込み：「顧客のコードをこのツールに入れていいと、どの契約書に書いてある? 事故が起きたときの責任は誰が取る? 法務とセキュリティ部門の確認は取ったのか?」

指摘5【過剰＋漏れ】効果未検証のまま150名一斉導入。パイロット導入という代替案の検討がない

• どこが：「全エンジニア150名に一斉導入する」
• なぜ問題か：30%という効果仮説が未検証のまま、いきなり全社展開に全額コミットする設計になっている。20〜30名・3ヶ月のパイロットなら月十数万円で効果を実測でき、その結果を持って全社展開を判断できる。段階導入という誰でも思いつく代替案を検討した形跡がなく、「検討の浅さ」自体が提案の信頼性を損なっている。また、全エンジニアが均等に使う前提だが、利用意向調査もなく、使わない社員のライセンスは丸ごと死に金になる。
• 経営層の突っ込み：「なぜ最初から150名なんだ? まず30名で3ヶ月回して、実測値を持ってもう一度来なさい、で何がまずい?」

指摘6【漏れ】ツールの比較選定がない。そもそも「どのツール」かすら書いていない

• どこが：文書全体。ツール名が一度も出てこない。
• なぜ問題か：価格も特性もセキュリティ要件対応も異なる選択肢が複数あるのに、選定基準も比較表もない。「月額6,000円」という具体的な単価だけが書かれており、実質的に特定ツールありきで比較検討を省略した提案に見える。また、企業導入ではSSO・監査ログ対応の上位プランが必要になることが多く、単価6,000円で収まる保証もない。
• 経営層の突っ込み：「何のツールの話をしている? 相見積もりは? エンタープライズプランだと単価はいくらに跳ねる?」

指摘7【漏れ】効果測定の方法と撤退基準がない

• どこが：期待効果・導入計画のどちらにも、KPI・測定方法・中止判断の記述がない
• なぜ問題か：「30%向上」を何でどう測るのか(PR数? リードタイム? 自己申告?)が定義されていないため、導入後に成否を判定できず、失敗してもずるずる契約が続く構造になっている。また、AI生成コードによるレビュー工数増・品質低下という負の効果を測る指標もない。
• 経営層の突っ込み：「半年後、この投資が成功だったか失敗だったか、何の数字で判断するんだ? 効果が出なかったら誰がいつ止める?」

指摘8【穴】「業界標準になりつつある」という導入理由が論理として成立していない

• どこが：背景の「業界標準になりつつあり、当社も早急に導入すべき段階にある」
• なぜ問題か：「他社がやっているから」は投資理由にならない(バンドワゴン論法)。自社の開発現場のどの課題(納期遅延? 採用難? コスト圧力?)を解決するための投資なのかが書かれておらず、「早急に」の根拠(導入しない場合に何をいつ失うのか)も示されていない。背景と期待効果が接続していない。
• 経営層の突っ込み：「当社の何の課題を解決する投資なんだ? 導入しなかったら、いつ、何が起きる?」

（このあと「提案を通したいなら最低限直すべき点」として、パイロット化・計算式の明示・研修コストの計上・リスク評価の追記・比較表とKPIの追加、の5点が提示された）

改訂版v2 全文（1巡目の指摘を反映した状態）

生成AIコーディング支援ツール パイロット導入のご提案（改訂版）

背景と課題

開発部門では直近2年、採用が計画を下回る一方で受注は増えており、開発リードタイムの長期化が顧客満足と受注機会の損失につながり始めている。生産性向上の選択肢として、生成AIコーディング支援ツールの導入を検討したい。
ベンダー各社は「コーディング効率30%向上」等を公称するが、当社での効果は未実証のため、小規模なパイロットで実測してから展開可否を判断する。

ご依頼事項

パイロット導入（30名・3ヶ月・ライセンス費 約54万円）の承認。

効果検証の設計

• 効果試算の式：削減工数 = 対象者の人件費 × コーディング時間比率 × 効率化率。比率と効率化率はパイロットで実測する
• KPI：PRサイクルタイム、週次アクティブ利用率、開発者アンケート
• 継続判断（3ヶ月後）：アクティブ利用率60%以上、かつサイクルタイム10%以上の改善で全社展開を再上程。基準未達の場合は契約を終了する
• 削減工数の使途：受注済み案件のリードタイム短縮に充て、来期の増員計画（3名）の抑制につなげる

セキュリティと契約

• 本ツールはソースコードを外部サービスに送信するため、情報システム部・法務部の事前確認を承認条件とする
• 顧客との契約でAI利用に制約があるコードは対象外とし、パイロットは自社プロダクト開発チームに限定する
• 入力コードをモデル学習に使わせない設定（オプトアウト）を必須とする

ツール選定

候補3ツールを、データの取り扱い・単価・エディタ対応の3点で比較し、学習オプトアウトと監査ログに対応する候補Aを第一候補とする（比較表は別紙）。

費用（パイロット）

• ライセンス費：月額6,000円 × 30名 × 3ヶ月 = 54万円
• 研修：導入時オンボーディング2時間 × 30名（工数として計上）
• 運用：管理者工数 0.1人月 × 3ヶ月

スケジュール

承認後2週間で対象チーム選定と利用ガイドラインの整備、1ヶ月目に研修と利用開始、以後3ヶ月計測、終了後2週間で結果報告と展開判断。

※ 本文に書いたとおり、この改訂版は1巡目の指摘を反映した段階のもので、ここからさらにレビューを回す。

対照：素の「どう思いますか？」への応答（同じ草案・別の新規セッション・無編集の要旨）

冒頭は「率直に言うと、このまま経営会議に出すと数字の根拠と内部矛盾を突かれて差し戻されるリスクが高い草案です」。

以下が列挙された。

• 「教育コスト不要」と研修2週間の矛盾（研修の機会費用は数千万円規模でROIが崩れる）
• コーディング効率30%を部門工数30%削減と読み替える飛躍（コーディング比率を掛けると効果は3分の1以下になり得る）
• 9,000万円の算出根拠の欠如（1人あたり年60万円という逆算が平均人件費と整合しない）
• 工数削減をそのまま金額価値とみなす換算の問題（人員削減も増員回避もしないならキャッシュは浮かない）
• パイロットなしの一斉導入（定着率リスク、未使用ライセンスの死に金化）
• ツール選定・セキュリティ検討の欠落

一方で「方向性自体は妥当」「単価の桁感は現実的」という評価や、「効果試算を計算式つき3ケースに」「パイロット承認に絞る」といった改善提案も混ざった、相談への返事の形だった。

本文で書いたとおり、検出された論点の多くは敵対的レビューと重なる。違いは出力の形（重大度順、想定問答、批判への固定）にある。