非エンジニアの営業が、Claude Codeで "6人のAIチーム"を作って提案書を書かせてみた
この記事は「非エンジニアがClaudeを触ってみた/やってみた」シリーズの記事です。
⚠️ 注意： 本記事に登場する「株式会社イシカワカンパニー」は架空の企業であり、提案書の内容（サービス構成・費用・事例等）はすべて本記事のデモンストレーション用に作成したものです。実際のクラスメソッドが提供しているサービス内容・価格・実績とは一切関係ありません。
提案書、1人で書くのつらくないですか？
クラスメソッドで営業をしている石川です。エンジニアではありません。
営業の仕事で避けて通れないのが提案書の作成です。そして、これが結構大変。
-
1人で書くと視点が偏る。 自分では良いと思ったのに、お客様に刺さらなかった経験、ありませんか
-
レビューを頼みたいが、周囲も忙しい。 「ちょっと見てもらえますか」が言いにくい
-
AIに丸投げしてみたが、表面的。 「提案書を書いて」と頼んだら、どの顧客にも使えそうな一般論が出てきた
そんなとき、ふと思いました。
「実際の提案って、調査担当・設計担当・レビュアーがいるチーム作業だよな。このチーム体制をAIで再現できないか？」
Claude Codeには「エージェント」という仕組みがあり、役割と指示を定義したAI担当者を作れます。
定義ファイルはMarkdown（テキストファイル）で書くだけ。コードは不要です。
非エンジニアの私でも作れるのか？ 実際にやってみました。
まず3人チームを作ってみる
いきなり大人数はあらぬ方向に進んでしまわないか心配だったので、Claudeに相談しながらまず最小構成の3体を作りました。
① 調査担当 → 顧客情報を整理
↓
② ライター → 提案書を執筆
↓
③ レビュアー → 品質チェック
Claudeと対話しながら、それぞれの定義ファイル（Markdown）を作成。繰り返しますが、コードは一行も書いていません。
またAIチームの実力を試すため、営業なら「あるある」と思えるリアルな設定を用意しました。
架空の顧客「株式会社イシカワカンパニー」
株式会社イシカワカンパニー（食品メーカー、従業員300名、年商120億円）
- 基幹システムがオンプレで稼働10年、HW保守切れが迫る
- EC会員3万人分のカード情報を保有。漏洩リスクが放置状態
- 同業他社がランサムウェア被害に遭い、経営層が危機感
- 情シスは2名で手一杯
- 3年前に別SIerで移行PoCが頓挫した過去
提案先は3名。それぞれ以下のポジション、考えを持っているとします。
- 社長（「いくらかかる？信用は？」）
- 管理部長（コスト番人、従量課金が不安）
- 情シスリーダー（前向きだが手一杯）
3人が作成した提案書は物足りない？
出てきた提案書が以下となります。
課題→解決策→コスト→次のステップという流れはできています。
でも、「この提案でお客様の心が動くか？」と聞かれると...難しい。
個人的に資料を見て主に気になったのは以下のポイントです。
| 気になった点 | 3人の回答 |
|---|---|
| 誰に向けた提案か | エグゼクティブサマリーなし。いきなり課題から |
| 3年前の頓挫について | 「段階移行で対応」の一文のみ |
| コスト比較 | 2列の簡易表。前提条件なし |
| 情シスへの配慮 | 「MSPで補います」の一文 |
3人では物足りない！ロールを追加してクオリティUPだ！
Claudeに相談し、以下のように3つの役割を追加しました。
┌─────┼─────┐
リサーチ/設計/批判者 ← 3人が並列で動く
└─────┬─────┘
構成担当 ← 3人の出力を統合
↓
ライター ⇄ 編集長 ← 書く→レビュー→修正→承認
追加された3人のうち、最大のキーパーソンは批判的レビュアー（Devils Advocate）。
「顧客にこう突っ込まれたらどうする？」を徹底的に洗い出す役割です。
3人版にはこの「穴を探す人」がいませんでした。
さらに「レビュアー」が「編集長」に進化。
4つの軸（顧客視点・論理・So What?・構成）でレビューし、基準を満たさなければライターに差し戻すように指示を出しました。
6人体制の提案書は、より多角的かつ論理的なものに
同じお題で実行しました。
Phase 4で編集長がレビューしたところ、「再修正が必要」。必須修正4点を指摘。
- TCO比較が「こちらに都合の良い数字」に見える
- 管理部長の従量課金不安への直接回答がない
- 情シスリーダーへの配慮が具体性不足
- セキュリティの緊急性が構成上埋もれている
その後ライターが修正版を作成し、再レビュー。スコア4.75/5.0で承認されました。
そして完成したものが以下となります。
3人 VS 6人ここが変わった
同じお題から出てきた2つの提案書。特に差が際立った3つのポイントを比較してみます。
比較1：PoC頓挫への向き合い方
| 3人版 | 6人版 | |
|---|---|---|
| 内容 | 「段階移行で対応」の一文 | 前回との5項目対比表＋Go/No-Go判定基準＋決裁フロー＋食品業界事例 |
| 深さ | 論理的には正しいが、一言で終わり | 「前回と何が違うのか」を構造的に証明 |
なぜ差が出たか：批判者が「最大の心理障壁と思われる、管理部長は3年前に予算を承認して失敗した経験がある。“段階移行だから大丈夫”では感情的に不十分」と指摘しています。
これを受けて構成エージェントが独立セクションを設計し、ライターが対比表を入れ、編集長がGo/No-Go基準の具体化をさらに要求しました。
比較2：TCO比較の説得力
| Header | 3人版 | 6人版 |
|---|---|---|
| シナリオ数 | 2列（オンプレ vs AWS） | 3シナリオ（現状維持/AWS従量/AWS+固定化） |
| 前提条件 | 記載なし | トラフィック量・データ量・為替等を明示 |
| 誠実さ | 「クラウドの方が安い」一辺倒 | 割高になる4ケースを正直に開示 |
なぜ差が出たか：批判者が「有利な数字だけ並べると営業トークに見える」、編集長が「数字の信頼を失った時点で提案は終わる」とフィードバック。
「不利な情報もあえて出す」という判断は、人間のレビュアーでもなかなかできないポイントです。
比較3：情シスリーダーへの配慮
| 3人版 | 6人版 | |
|---|---|---|
| 配慮の深さ | 「MSPで補います」の一文 | フェーズ別タスク一覧＋工数内訳＋代行作業一覧 |
| メッセージ | なし | 「移行完了後、週8時間を取り戻せます」 と具体的な提示 |
なぜ差が出たか：編集長が「佐藤リーダーの本音は“楽になるのか、もっと忙しくなるのか”。MSPの説明だけでは不安は解消されない」と必須修正を指示。
数字で負荷を見せ、ポジティブなメッセージで締める構成になりました。
差を生んだのは「批判者」と「フィードバックループ」
批判的レビュアーの威力
3人版には「提案の穴を探す人」がいませんでした。6人版では批判者が事前にこんな指摘を出していました。
-
「“3年前もSIerに任せて頓挫した。なぜ今回は大丈夫？”と聞かれる」
-
「TCO比較が恣意的に見えるリスク」
-
「セキュリティ専業ベンダーに案件を切り出されるリスク」
これらの指摘が構成エージェントに渡り、提案書の構造そのものを変えたと思われます。
編集長のフィードバックループ
3人版はライターが書いて終わり。
対して6人版は「書く→指摘→直す→確認」のループがあり、これが品質を押し上げました。特に「再修正が必要」の判定で出た必須修正4点が、最終稿の完成度を大きく変えています。
やってみて気づいたこと
AIへの指示は「後輩への業務マニュアル」と同じ。 エージェント定義は「まず顧客の課題を整理して」「こういう観点でチェックして」とMarkdownに書くだけ。コードは書いていません。
業務知識がなければAIチームも動けない。 一番時間をかけたのはAIチームの構築ではなく、架空顧客の設定を練る作業でした。 「3年前にPoCが頓挫した」「管理部長は従量課金に不安」。リアルな設定があってこそ、AIチームが深い提案を出せます。
裏を返せば、良い提案書の作成には品質の良い情報が求められるでしょう。この点は営業としてのヒアリング力が非常に求められますし、その得た情報を全社横断的に活用できるよう格納できるか組織体制も今後より求められると言えそうです。
「批判者」を1体足すだけで変わる。 6体すべてが必要かと言われると、批判的レビュアー1体だけでもかなり変わると思います。「この提案の弱点はどこか」を洗い出してくれる存在は、品質を一段階引き上げます。
まとめ：まずは1人、曖昧でもとりあえず始めてみましょう
いきなり大人数のチームを作る必要はありません。
まずは「レビュアー」1人を追加するところから。 自分が書いた提案書をClaudeに「顧客の立場で弱点を指摘して」と頼むだけでも、視点が広がります。
そこから必要に応じて、批判者を追加し、構成担当を追加し、少しずつ拡張していけばいいだけです。Claudeに「こういうエージェントを作りたい」と相談すれば、定義ファイルも一緒に作ってくれます。
触れば触るほど、次にこれをやってみたらどうだろうかと興味が出てくるのもClaudeの魅力だと感じました。
皆さん思い思いのチームを作成してみてください。
最後に、トラブル回避のためにAIが出力したものは必ず全体に目を通しましょう。
出てきた提案書を使うのは自分自身です。
前提に間違いがないか、出力された結果は論理的で整合性が取れているかは要確認となります。
