- ITコンサルのAgentforce活用とは、営業の業務ごとにAIの下書きと人の判断を分けて設計する進め方です。
- ITコンサルの営業でAIに任せやすいのは、引合いの整理、現行業務の調査、PoCの設計案のような材料づくりです。
- ITコンサルの営業では、引き受けの可否、最終の人日、SOWの責任の範囲を人が決め、顧客と合意します。
- ITコンサルのAI活用は、受注と失注の提案書と実績の工数を記録に残してから、次の引合い1件で試します。
ITコンサルの受託営業で時間がかかっているのは、引合いを受けるかどうかを見極める作業や、見積の根拠を過去の案件から探す作業ではないでしょうか。提案書の文章を書く作業は、その後に続く工程の一部です。ITコンサルのAgentforce活用とは、SalesforceのAgentforceを使い、引合いから導入後の追加提案までの営業の業務ごとに、AIに出させる下書きと人が決める判断を分けて設計する進め方のことです。
そこで本記事では、ITコンサルの営業でAgentforceに任せられる業務と人に残す判断を、当社自身の受託営業での使い方をもとに解説します。なお、Agentforceの機能や価格は変わりやすいため、本記事は2026年11月時点で確認できた公式の情報にもとづいています。
- ITコンサルティング会社の営業がAgentforceに任せる8つの業務
- なぜ偏る？ITコンサルの営業が人に依存する3つの理由
- ITコンサルの営業がほかの業界と違う3つの点
- Agentforceが参照するITコンサルの4つの社内記録
- 手順4選｜ITコンサルのAI活用を1案件で始める
- ITコンサルのAI活用でつまずく3つの落とし穴
- ITコンサルのAgentforce活用を3つの時点で測る
- AI活用を先に進めるべきITコンサルの3つの条件
- ITコンサルでAI活用を急がなくてよい3つの条件
- ITコンサルがAgentforceを入れる費用3内訳
- ITコンサルがAgentforce導入支援会社を選ぶ3つの見極め方
- 【一問一答】ITコンサルのAgentforce活用に関するよくある質問
- ITコンサルティング会社はAgentforceで提案と見積の根拠を会社に残す
ITコンサルティング会社の営業がAgentforceに任せる8つの業務
ITコンサルの営業でAgentforceに任せられるのは、引合いから導入後の追加提案までの8つの業務で、どの業務にも人が持ち続ける判断があります。ITコンサルティングを行う当社では代表の本田が自ら営業しており、2026年の初めから、8つの業務のうち引合いの受付、現行業務の調査、PoCの設計の3つをAgentforceのエージェントで動かしています。残りの5つの業務は、代表の本田が自分で行うか、手作業の型や別の生成AIを使っているため、本記事で書くのはAgentforceで組む場合の一般論です。当社の営業でAgentforceを使い始めてからの導入前と後の変化は、別の記事にまとめました。そこでここでは、ITコンサルの営業でAgentforceに任せられる8つの業務と、それぞれに人に残す判断を解説します。
| 業務 | 当社で使っているもの | AIに出させるもの | 人に残す判断 |
|---|---|---|---|
| ①引合いの受付 | Agentforce | 相手企業の要約と仮説 | 引き受けの可否 |
| ②現行業務の調査 | Agentforce | 記録と調査の整理 | 顧客への確認 |
| ③提案書の作成 | 代表が自分で作成 | 組むなら構成の下書き | 課題の定義 |
| ④工数の積算 | 代表が自分で積算 | 組むなら過去の実績 | 最終の人日 |
| ⑤PoCの設計 | Agentforce | 検証範囲と基準の案 | 成功の基準 |
| ⑥競合との差別化 | 手作業の型 | 組むなら比較の材料 | 他社への言及 |
| ⑦SOWの調整 | 代表が自分で作成 | 組むなら条項の下書き | 責任の範囲 |
| ⑧導入後の追加提案 | 別の生成AI | 組むなら利用の変化 | 提案の時期 |
業務①引合いの受付｜引き受けの可否は人が決める
1つ目は「引合いの受付｜引き受けの可否は人が決める」です。ITコンサルの引合いは、問い合わせの文面が短く、相手の事業も課題もまだ分からない段階で届くことがほとんどで、受けるかどうかを決める前に調べることが多くなります。
当社では、代表の本田が引合いを受けると、Agentforceのエージェントに4つのものを出させています。相手企業の要約、課題と解決の仮説、自社のCRMから探した過去の類似案件、初回ヒアリングの質問項目の下書きです。代表はこの4つを読んでから、初回の打ち合わせで何を確かめるかを決めています。
ITコンサルの引合いを引き受けるかどうかは、エージェントの下書きを読んだうえで代表の本田が決めています。下書きに出てくるのは公開情報と過去の記録から組み立てた仮説で、予算を組む時期や社内の体制といった顧客固有の事情は、打ち合わせで聞いて初めて分かるからです。引合いの業務をAIに任せるときは、引き受けの可否を決める材料のうち、どこまでが下書きで、どこからが聞いて確かめる事情なのかを先に分けておきます。
業務②現行業務の調査｜顧客への確認は人が行う
2つ目は「現行業務の調査｜顧客への確認は人が行う」です。ITコンサルの提案は、顧客の今の業務の流れを把握するところから始まり、この調査が浅いと、後の提案書も見積もずれていきます。
当社では、現行業務の調査にもAgentforceのエージェントを使っています。エージェントが参照するのは、Salesforceに残している商談と取引先の記録、打ち合わせの議事録、そしてWebで調べた相手企業の情報です。代表の本田は、エージェントがこれらを並べて整理した下書きを見て、まだ聞けていない業務や、記録の間で食い違っている点を確かめています。
議事録と公開情報から組み立てた業務の流れは、あくまで当社の側から見た推定にとどまります。顧客の担当者が実際にどの順で仕事を進め、どこで手が止まっているのかは、本人に聞いて確かめるしかありません。下書きで見えた空白を次の打ち合わせの質問に変え、顧客への確認は代表が自分の言葉で行うようにしています。
業務③提案書の作成｜課題の定義は人が書く
3つ目は「提案書の作成｜課題の定義は人が書く」です。ITコンサルの提案書は、顧客の課題をどう定義するかで中身のほとんどが決まります。
当社では、提案書の骨子は代表の本田が自分で作っています。エージェントで動かしているのは前段の引合いと現行業務の調査までで、提案書の作成にはAgentforceを使っていません。提案の骨子は見積の前提になり、見積の責任は人が持つという考え方から、この業務を人の手に残しています。
Agentforceで組むなら、過去の提案書と現行業務の調査の下書きをエージェントに参照させ、章立てと各章に入れる材料の候補を出させる形になります。受注した提案書の構成を手がかりにすれば、ゼロから章立てを考える時間は減らせる可能性があります。
課題の定義には顧客固有の事情が入ります。同じ業種の過去の提案書をなぞっただけではその顧客が抱える事情とずれた提案になりやすく、どちらの形でも課題の定義は人が書く必要があります。
業務④工数の積算｜最終の人日は人が決める
4つ目は「工数の積算｜最終の人日は人が決める」です。ITコンサルでは、工数の積算がそのまま見積の金額になります。
当社では、工数の積算は代表の本田が自分で行っています。積算の結果は顧客に出す見積の根拠になり、その数字の責任と顧客との合意は人が持つものだと考えているからです。
Agentforceで組むなら、案件ごとの見積と実績の工数をSalesforceに残しておき、似た規模の案件で作業ごとに何人日かかったかをエージェントに一覧にさせる使い方が考えられます。見積書そのものの作り方は、見積作成のAI活用の考え方が参考になります。
過去の実績は作業の種類と規模が近い案件の数字で、今回の顧客の体制や既存システムに固有の仕様までは反映されていません。そのため、AIに実績を一覧にさせる形でも、最終の人日は数字の根拠を顧客に説明できる人が決める必要があります。
業務⑤PoCの設計｜成功の基準は顧客と決める
5つ目は「PoCの設計｜成功の基準は顧客と決める」です。PoC（概念実証）は、本格的な導入の前に範囲を絞って試す段階で、何をどこまで確かめるかの設計で結果の読み方が変わります。
当社では、PoCの設計にAgentforceのエージェントを使っています。エージェントに出させているのは、検証範囲の案と成功基準の案、関係者の把握、そしてほかのエージェントへの影響の有無の確認です。代表の本田はこの案を読み、範囲が広がりすぎていないか、関係者に漏れがないかを確かめてから顧客との打ち合わせに持っていきます。
ITコンサルのPoCでは、成功の基準を顧客と話して決めます。成功の基準には顧客が社内で説明するときに使う数字の根拠が入り、当社の側だけで決めた基準は顧客の判断に使えないからです。エージェントの案は、顧客と話す論点をそろえるための材料として使っています。
業務⑥競合との差別化｜他社への言及は人が選ぶ
6つ目は「競合との差別化｜他社への言及は人が選ぶ」です。ITコンサルの提案では、顧客がほかの会社にも声をかけていることが多く、自社の提案がどこで違うのかを示す必要があります。
当社では、競合との差別化は手作業の型で考えています。提案のたびに、自社の強みと顧客の課題が重なる点を決まった順で書き出し、どれを提案書に入れるかを代表の本田が決める形です。
Agentforceで組むなら、過去の商談で顧客が比べていた会社や、失注したときの理由をSalesforceに残しておき、似た商談の比較の材料をエージェントに並べさせる方法があります。
他社に触れるかどうかと、どう触れるかは、人が選ぶ必要があります。他社の名前を出した比較は、事実の確認が不十分なまま顧客に渡ると信頼を損ない、提案の中身より先にその点を問われることになるからです。自社の強みと顧客の課題の重なりで違いを示せるなら、他社の名前は出さずに、重なる点を提案書の冒頭の章にまとめる書き方で足ります。
業務⑦SOWの調整｜責任の範囲は人が合意する
7つ目は「SOWの調整｜責任の範囲は人が合意する」です。SOW（作業範囲記述書）は、作業の範囲、成果物、前提条件、責任の分担を書いた文書で、受託の案件では契約後の進め方を決める文書になります。
当社では、契約とSOWは代表の本田が自分で作り、顧客と調整しています。SOWは見積の前提を文章にしたもので、その内容で顧客と合意する責任は人が持つからです。
Agentforceで組むなら、過去のSOWの条項と、案件の途中で範囲を変えた履歴を残しておき、似た案件で使った条項の候補をエージェントに出させる形になります。条項の書き方をそろえる作業は、AIに任せやすい部分です。
どの作業を範囲に入れ、どこから先を顧客の責任にするかは、人が顧客と話して合意する必要があります。条項の候補が過去の案件でうまくいった書き方でも、今回の顧客の体制に合わなければ、契約後の範囲の争いの原因になるからです。
業務⑧導入後の追加提案｜提案の時期は人が決める
8つ目は「導入後の追加提案｜提案の時期は人が決める」です。ITコンサルでは、導入した仕組みの使われ方が見えてくると、次の改善や対象の業務の拡大を提案できる場面が出てきます。
当社では、追加提案の材料集めに別の生成AIを使っており、Agentforceのエージェントでは動かしていません。提案するかどうかは、代表の本田が自分で決めています。
Agentforceで組むなら、導入後の問い合わせや利用状況の記録をエージェントに参照させ、変化があった顧客と次に提案できるテーマの候補を出させる使い方ができます。追加提案の基準やデータの設計は、Agentic CRMのアップセル設計の考え方が参考になります。
どちらの形でも、提案の時期は人が決めます。顧客の予算の時期や社内の体制の変化は記録に残りにくく、材料がそろっていても、顧客が検討できる時期でなければ提案は進みません。以上が、ITコンサルの営業でAgentforceに任せられる8つの業務でした。
なぜ偏る？ITコンサルの営業が人に依存する3つの理由
前章では、ITコンサルの営業の8つの業務と、それぞれに人に残す判断を見てきました。そもそも、なぜITコンサルの営業は特定の人に偏りやすいのでしょうか。それは、ITコンサルの営業では、判断の材料と根拠が個人の手元に残りやすいからです。業務を営業AIエージェントに任せる前に、偏りが生まれる理由を先に知っておけば、AIを入れた後も同じ人に確認が集まり続ける状態を避けられます。そこでここでは、ITコンサルの営業が人に依存する3つの理由を解説します。
理由①引合いの判断が担当者の経験に頼るから
まず、ITコンサルの引合いは相手の業種も規模も依頼の中身も毎回違い、受けてよい案件かどうかの基準を文書にしていない会社では、引き受けの判断が担当者の経験に頼りがちです。
たとえば、問い合わせに「来期に基幹システムの入れ替えを検討している」とだけ書かれていた場合、経験のある担当者は、予算がすでに決まっているのか、比較の段階なのかを最初の返信で確かめます。経験の浅い担当者は、その確認をせずに提案の準備に入り、数週間後に予算が無いと分かることもあるでしょう。
このように、引合いの判断は過去の案件で何が起きたかを覚えている人ほど早く正確になるため、判断の材料となる過去の案件が記録に残っていなければ、経験のある担当者に確認が集まり続けます。
理由②工数の根拠が個人の表計算に残るから
次に、見積を作る担当者は、過去の案件で作業ごとに何人日かかったかを自分の表計算にまとめて手元に持ち、次の見積で参照していることがよくあります。
この表計算は、項目の分け方も更新の時期も、作った本人にしか分かりません。作業の区分が案件ごとに違っていたり、実績が無く見積の数字だけが残っていたりして、本人以外には読み解けないこともあります。担当者が異動したり退職したりすると、見積の根拠ごと会社から消え、次の担当者はまた一から積み上げることになります。
ITコンサルの見積が属人化するのは、実績の工数が会社の記録に残っていないからです。AIに工数を出させたい場合も、参照する実績が個人の表計算にしかなければ、AIが読めるものはありません。
理由③提案書とSOWが案件のフォルダに散らばるから
最後に、ITコンサルでは、提案書もSOWも案件のたびに作られ、案件名のフォルダに保存されたまま、ほかの案件から探せない状態で残りがちです。
具体的には、似た業種の案件で過去にどのような課題を定義し、どの条項で範囲を区切ったのかを知りたくても、フォルダの名前から中身を推測して開いていくしかありません。どの提案が受注し、どれが失注したのかが記録されていなければ、うまくいった提案書を選ぶことも難しくなります。SOWの範囲を案件の途中で変えた経緯も、メールや議事録に分かれて残り、フォルダの中の最終版からは読み取れません。
結果として、過去の提案書の場所と中身を覚えている人に、次の提案の相談が集まります。偏りを減らすには、提案書とSOWを1つの場所にそろえ、受注と失注を区別して残しておく必要があります。
ITコンサルの営業がほかの業界と違う3つの点
ここまで、ITコンサルの営業が特定の人に偏る理由を見てきました。AIの使い方を考えるうえでは、ITコンサルの営業がほかの業界の営業とどこで違うのかを押さえておくと、8つの業務のうちどこに人の判断を残すべきかの理由が見えてきます。ITコンサルが売っているのは人の作業と成果物で、見積と提案書と契約が持つ意味もほかの業界とは同じではありません。そこでここでは、ITコンサルの営業がほかの業界と違う3つの点を解説します。
違い①工数の見積がそのまま価格になる
1つ目の違いは「工数の見積がそのまま価格になる」点です。ITコンサルでは見積の人日がそのまま価格になり、製品を売る営業のように、あらかじめ決まった価格表から値引きの幅を決める形にはなりません。
ITコンサルでは、作業ごとの人日を積み上げた合計が価格になるため、見積の段階で作業の範囲と難しさを読み違えると、そのまま赤字の案件になります。人日の見積は、顧客の体制や既存のシステムの状態といった顧客固有の事情によって大きく変わるため、過去の案件の数字をそのまま当てはめることはできません。
だからこそ、工数の積算でAIに任せられるのは過去の実績を並べるところまでで、最終の人日は顧客の事情を聞いた人が決める必要があります。当社で工数の積算を代表が自分で行っているのも、この違いがあるからです。
違い②提案書が納品物の設計を兼ねる
2つ目の違いは「提案書が納品物の設計を兼ねる」点です。ITコンサルの提案書には、顧客の課題、解決の方法、作業の進め方と成果物までが書かれ、受注した後はその内容がそのまま作業の計画になります。
つまり提案書は、受注を取るための営業資料であると同時に、納品の範囲を顧客に約束する文書でもあります。提案書に書いた解決の方法が顧客の事情と合っていなければ、受注した後に作業の計画を立て直すことになり、見積の前提も崩れます。
このため、提案書の骨子を決める人と、見積の責任を持つ人は同じであるほうが進めやすくなります。提案書の下書きをAIに任せる場合も、課題の定義と解決の方法は、顧客と話した人が自分で書く形にしておきましょう。
違い③契約後の範囲の争いがSOWで決まる
3つ目の違いは「契約後の範囲の争いがSOWで決まる」点です。受託の案件では、作業の途中で顧客から追加の要望が出ることが多く、それが当初の範囲に入るのかどうかを判断する拠り所がSOWになります。
範囲の争いの元は、契約の前の段階にあることが少なくありません。IPAの資料が引用しているJUASの2016年の調査では、ユーザー企業のシステム開発で工期遅延の理由のうち55%が要件定義の問題でした。この数字は、範囲を決める工程での問題が、工期の遅れの理由の半分以上を占めていたことを示しています。ITコンサルの営業に限らない、10年近く前の調査の数字です。
ITコンサルのSOWで責任の範囲を決めるのは顧客と合意した人で、AIの条項の候補は判断の材料にとどまります。以上が、ITコンサルの営業がほかの業界と違う3つの点でした。
Agentforceが参照するITコンサルの4つの社内記録
ITコンサルの営業がほかの業界と違う点を見てきましたが、Agentforceにこれらの業務を任せるには、エージェントが読む記録が社内にそろっている必要があります。Agentforceは、Salesforceに残っている取引先や商談などの標準のデータを参照して答えを組み立てるため、記録が無ければ下書きの質は上がりません。ITコンサルでは、ほかの業界の営業記録に加えて提案書や工数、PoC、SOWの記録が必要で、提案と見積の下書きはAgentforceがこの4つの社内記録を読んで作ります。そこでここでは、Agentforceが参照するITコンサルの4つの社内記録を解説します。
記録①受注と失注を区別した過去の提案書
1つ目は「受注と失注を区別した過去の提案書」です。提案書の構成や課題の定義の仕方をAIに参照させるなら、どの提案書が受注につながり、どれが失注したのかが分かる形で残っている必要があります。
受注と失注の区別が無いまま提案書をまとめて読ませると、エージェントは失注した提案の構成も同じ重みで参照し、うまくいかなかった書き方を下書きに持ち込むことがあります。区別の印は、商談の結果と提案書の保存先を結びつけるだけでも付けられます。
あわせて、失注した理由を一言でも残しておくと、次の提案で同じ論点を避ける材料になります。受注と失注の印と失注の理由の2つがそろえば、エージェントは過去の提案書を次の提案の下書きに参照できるようになります。
記録②案件ごとの見積と実績の工数
2つ目は「案件ごとの見積と実績の工数」です。工数の積算でAIに過去の実績を並べさせるなら、案件ごとに見積の段階で何人日を見込み、実際に何人日かかったのかの両方が残っている必要があります。
作業の種類ごとに見積と実績を並べて残しておけば、似た案件で読み違えやすい作業がどこなのかが見えてきます。見積の工数だけでは見積が正しかったのかどうかが分からず、実績の工数だけではどの作業で見込みとずれたのかを追えないため、両方を並べて残します。
ITコンサルで工数の下書きをAIに任せるには、見積と実績の工数を作業の種類ごとに並べて残しておきます。この記録が無い段階で工数をAIに出させても、根拠を説明できない数字が並ぶだけになります。
記録③PoCの検証項目と判定の結果
3つ目は「PoCの検証項目と判定の結果」です。PoCの設計でAIに検証範囲の案を出させるなら、過去のPoCで何を検証し、どの基準で成功と判定したのか、その結果がどうだったのかが残っている必要があります。
PoCの記録は、終わった後の報告書の中に埋もれていることが多く、検証項目と判定の結果だけを取り出して探せる状態になっていない場合があります。検証項目、成功の基準、判定の結果、本格導入に進んだかどうかの4つを、商談の記録に結びつけて残しておくと扱いやすくなります。
この記録があれば、エージェントは似た案件で使った検証項目を候補として出せるようになります。成功の基準を顧客とどう決めたかの経緯は記録に残りにくいため、その部分は人が補う前提で設計しておきましょう。
記録④SOWの条項と変更の履歴
4つ目は「SOWの条項と変更の履歴」です。SOWの調整でAIに条項の候補を出させるなら、契約時の条項と、案件の途中で範囲を変えた履歴の両方が残っている必要があります。
変更の履歴まで残すのは、手戻りの多くが早い段階に原因を持つからです。IPAの資料が引用しているJUASの2014年の調査では、ユーザー企業のシステム開発で手戻りが起きた件数のうち85%が設計段階からの手戻りで、後工程に進むほど修正の負荷が大きくなると示されています。範囲の変更が起きた条項を見れば、次の案件で先に確かめるべき点が分かります。なお、この調査はITコンサルの営業に限ったものではありません。
条項ごとに、どの案件で変更が起きたのかを残しておくと、似た案件の契約の前に確かめる条項をエージェントに挙げさせられます。以上が、Agentforceが参照するITコンサルの4つの社内記録でした。
手順4選｜ITコンサルのAI活用を1案件で始める
前章では、Agentforceが参照する4つの社内記録を見てきました。4つの記録をすべて一度にそろえようとすると、準備だけで数か月が過ぎてしまいます。ITコンサルのAI活用で小さく始めたい場合は、次の引合い1件を試す対象に決め、その案件に必要な記録から順にそろえる進め方が向いています。当社がAgentforceのエージェントで動かしているのも、8つの業務のうち3つに絞った範囲です。そこでここでは、ITコンサルのAI活用を1案件で始める4つの手順を解説します。
| 手順 | やること | 押さえる点 |
|---|---|---|
| ①提案書に印 | 受注と失注を区別する | 失注の理由も一言残す |
| ②工数を締める | 案件の終わりに実績を記録 | 作業の種類ごとに残す |
| ③条項をそろえる | SOWの雛形を1つにする | 変更の履歴も残す |
| ④1件で比べる | 下書きと人の版を並べる | 直した箇所を記録する |
手順①受注と失注の提案書に印を付ける
最初に行うのは、過去の提案書に受注と失注の印を付ける作業です。印は直近の1年ほどの案件から付け始めれば、試す段階で参照するには足ります。直近に絞るのは、担当者が残っていない古い案件の結果まで調べ直すと、作業が止まりやすいからです。
印を付けるときは、商談の結果と提案書の保存先を結びつけ、失注した案件には理由を一言で残しておきます。「価格」「時期」「他社の提案」のように、選べる理由を3つから5つに決めておくと、後から並べたときに傾向が読めるようになります。
ITコンサルのAI活用では、エージェントが読む記録の質は、AIの設定より先に行う受注と失注の印付けで決まります。提案書の整理に時間がかかる場合は、次の引合いと同じ業種の提案書から先に印を付けるとよいでしょう。
手順②案件の終わりに実績の工数を締める
提案書の印がそろったら、次は案件が終わるたびに実績の工数を締める決まりを作ります。これから終わる案件で確実に残すほうが、過去の案件の実績をさかのぼって集めるより、記録の精度は高くなります。
具体的には、案件の終わりに、見積の段階で作業ごとに見込んだ人日と、実際にかかった人日を並べて記録します。作業の種類は、要件定義、設計、構築、テスト、定着のように、自社の見積で使っている区分に合わせておくと、次の見積とそのまま比べられます。見込みと実績の差が大きかった作業には、ずれた理由も一言添えておきましょう。次の見積で同じ読み違いを避ける材料になります。
締める担当と時期は、先に決めておきます。決めていない記録は、案件が忙しい時期ほど後回しになるからです。たとえば案件の終了報告と同じ日に締めると決めておけば、記録が抜けにくくなるでしょう。
手順③SOWの条項を1つの雛形にそろえる
工数の記録の決まりができたら、SOWの条項を1つの雛形にそろえます。案件ごとに条項の書き方が違うと、似た条項を探すことも、変更の履歴を比べることも難しくなるためです。
雛形には、作業の範囲、成果物、前提条件、責任の分担、範囲を変えるときの手続きの5つの項目を置き、案件ごとに中身を書き込む形にします。あわせて、案件の途中で範囲を変えた場合は、どの条項をどう変えたのかと、変更を求めたのが顧客か自社かを雛形の項目に沿って残しておくと、営業の段階で防げた変更かどうかを後から見分けられます。
この雛形があれば、エージェントに条項の候補を出させる段階でも、どの項目の候補なのかがはっきりします。雛形をそろえておけば、AIを入れない場合でも、契約後の範囲の争いを減らせます。
手順④次の引合い1件で下書きと人の版を比べる
最後に、次の引合い1件を選び、AIの下書きと人が作った版を並べて比べます。小さく始めたい場合は、試す業務も引合いの受付のように1つに絞ると、どこで下書きが役に立ち、どこで人の手直しが要ったのかを追いやすくなります。
比べるときは、人が直した箇所を記録しておきます。たとえば、相手企業の要約のうち事実の誤りを直したのか、質問項目のうち顧客固有の事情に合わせて足したのかを分けて残すと、次にエージェントへの指示をどう直すかが見えてきます。
直す箇所が減らないうちに試す業務を増やすと、どの業務のエージェントの指示を直せばよいのかが分からなくなるため、業務は1つずつ足していきます。以上が、ITコンサルのAI活用を1案件で始める4つの手順でした。
ITコンサルのAI活用でつまずく3つの落とし穴
前章ではITコンサルのAI活用を1案件で始める手順を見てきましたが、記録や運用の準備が足りないまま進めてつまずく会社は少なくありません。ITコンサルでは、提案書と工数とSOWの扱いに固有の落とし穴が3つあり、どれも参照させる記録と人の確認の設計が足りないときに起きます。落とし穴を避ける手立ても、記録の残し方と、人が確かめる項目の決め方の2つです。そこでここでは、ITコンサルのAI活用で起きやすい3つの落とし穴を解説します。
落とし穴①失注した提案書が参照先に混ざる
1つ目の落とし穴は、失注した提案書が参照先に混ざることです。提案書のフォルダをまとめてAIに読ませると、受注した提案書と失注した提案書が区別なく扱われます。
その結果、エージェントが出す章立ての案に、失注した提案で使った構成や、顧客に受け入れられなかった解決の方法が入ってくることがあります。下書きを読む人が過去の経緯を知らなければ、うまくいかなかった書き方をそのまま次の提案に持ち込むことにもなりかねません。とくに、提案書を書いた担当者が異動した後、経緯を知らない人がエージェントの下書きを読む場面で起きやすくなります。
ITコンサルで提案書をAIに参照させるときは、受注と失注を区別してから読ませます。区別が付けられない提案書は、参照先から外しておくほうが安全です。
落とし穴②実績の工数が記録されていない
2つ目の落とし穴は、実績の工数が記録されていないことです。見積の工数は見積書に残るため記録があるように見えますが、実際に何人日かかったのかは、案件の管理表や個人のメモにしか残っていない場合がよくあります。
この状態で工数の下書きをAIに出させると、エージェントは見積の段階の数字だけを参照し、過去に読み違えた見積をそのまま次の見積の根拠にしてしまいます。見積が実績より少なかった案件が続いていれば、その傾向まで引き継ぐことになります。
実績の工数が残っていないことに気づいたら、工数の下書きを任せる段階は後に回し、まずは手順②の決まりで実績を締めることから始めましょう。数件分の実績がそろうまでは、工数の積算は人が行うほうが確実です。
落とし穴③SOWの下書きをそのまま顧客に出す
3つ目の落とし穴は、SOWの下書きをそのまま顧客に出すことです。AIが出す条項の候補は、過去の案件で使った書き方をもとにしているため、文書としては整って見えます。
条項の候補には今回の顧客の体制や前提条件が反映されていないことがあり、そのまま出すと、契約後に「その作業も範囲に入っていると思っていた」という争いの原因になります。違い③で触れたJUASの調査でも、工期の遅れの理由の多くは要件定義の問題でした。AIの下書きのどこまでを人が確かめるかは、誤答をどこまで許せるかの考え方で決めておくと迷いません。
SOWの下書きは、顧客に出す前に、範囲と責任の分担を人が1項目ずつ読み直す決まりにしておく必要があります。以上が、ITコンサルのAI活用でつまずく3つの落とし穴でした。
ITコンサルのAgentforce活用を3つの時点で測る
前章で見た3つの落とし穴を避けて始めたら、次は効果をどう測るかを決めておきます。ITコンサルのAgentforce活用は、試す時期、広げる時期、続ける時期で見るべき指標が変わり、同じ指標で最初から最後まで測ると判断を誤ります。代表の本田の感覚では、当社の引合いと現行業務の調査で準備の時間は半分以下になり、それ以上に確認の抜け漏れが減りました。これは測った数字ではありません。社内の説明に使うなら、指標は試す・広げる・続けるの3つの時点で替え、最後の6か月目は受注後に範囲が変わった件数で測ると先に決めておきます。そこでここでは、ITコンサルのAgentforce活用を測る3つの時点を解説します。
時点①試す1か月｜提案書の初版までの日数
試す時期の1か月目は、引合いを受けてから提案書の初版ができるまでの日数を数えます。引合いの整理や現行業務の調査をAIに任せた効果は、提案の準備にかかる日数に最初に表れるからです。
数え方は、引合いを受けた日と提案書の初版を顧客に出した日を案件ごとに記録するだけで足り、試す前の数件についても同じ日数を記録しておけば、試した後の数字と比べられます。ITコンサルの案件は規模によって準備の日数が大きく違うため、案件の規模の区分を一緒に残しておくと比べやすくなります。
この時期は件数が少なく、1件の大きな案件で日数の平均が動きます。1か月目は日数の変化を見るだけにとどめ、効果があったかどうかの判断は次の時点に回すのが確実です。
時点②広げる3か月｜見積と実績の工数の差
広げる時期の3か月目は、見積と実績の工数の差を見ます。引合いと調査の下書きで顧客の事情を早く把握できるようになれば、見積の段階での読み違いが減るはずだからです。
数え方は、手順②で決めた記録をもとに、案件ごとに見積の人日と実績の人日の差を出し、その差が見積の何割にあたるかを並べます。作業の種類ごとに差を見ると、要件定義やテストのように読み違えやすい作業がどこなのかが分かり、見積より実績が多かった案件と少なかった案件を分けて並べれば、読み違いが見込みの不足なのか過大なのかも区別できます。
この指標は、案件が終わらないと数字が出ないため、3か月の時点で数件しか集まらないこともあります。件数が少ないうちは、差が大きかった案件で何を読み違えたのかを振り返る材料として使いましょう。
時点③続ける6か月｜受注後に範囲が変わった件数
続ける時期の6か月目は、受注した後に作業の範囲が変わった件数を数えます。現行業務の調査とPoCの設計の質が上がれば、契約の前に確かめておくべき点が先に見つかり、受注後の範囲の変更が減ると考えられるからです。
数え方は、SOWの変更の履歴から、範囲を広げた変更と狭めた変更を分けて数えます。顧客の追加の要望で範囲が広がった場合と、当初の見積の読み違いで広げた場合も分けておくと、営業の段階で防げた変更がどれなのかが見えてきます。
範囲の変更は、顧客の事情でも起きます。そのため件数の増減だけで判断せず、変更の理由を1件ずつ確かめたうえで、AIの下書きで防げたものがどれだったかを数えるようにしましょう。以上が、ITコンサルのAgentforce活用を測る3つの時点でした。
AI活用を先に進めるべきITコンサルの3つの条件
ここまで、ITコンサルのAgentforce活用の始め方と測り方を見てきました。AI活用の効果が出やすいのは、営業の業務のうち準備にかかる時間が大きく、その準備の材料が社内に残っている会社です。準備の材料が社内に残っていない会社の条件は、次の章で取り上げます。自社が当てはまるかどうかを確かめてから進めれば、試した後の判断もしやすいでしょう。そこでここでは、AI活用を先に進めるべきITコンサルの3つの条件を解説します。
条件①提案書を案件ごとに一から作っている
1つ目の条件は「提案書を案件ごとに一から作っている」ことです。過去の提案書が社内にあるのに、毎回白紙から章立てを考えている会社では、引合いと調査の下書きをAIに任せたときの効果が大きくなります。
提案書を一から作っている会社では、似た業種の過去の提案書を探す時間と、顧客の情報を集める時間の両方がかかっています。この2つはAIの下書きに置き換えやすい作業で、人は課題の定義と解決の方法を考えることに時間を使えるようになります。
提案書の型がすでに社内で決まっていて、案件ごとの差が小さい会社では、AIの下書きで減らせる時間は限られます。提案書を作るたびに何時間かかっているかを、一度数えてみてはいかがでしょうか。
条件②SOWの範囲で揉めた案件がある
2つ目の条件は「SOWの範囲で揉めた案件がある」ことです。受注した後に、作業の範囲をめぐって顧客と認識が食い違った経験がある会社では、契約の前の調査とPoCの設計を厚くする意味が大きくなります。
範囲で揉める案件は、現行業務の調査で聞けていなかった業務があったり、PoCで確かめる範囲が曖昧なまま本格導入に進んだりしたことが原因になっている場合があります。調査とPoCの設計の下書きをAIに任せ、聞けていない点や関係者の漏れを先に確かめる形にすると、こうした原因を契約の前に見つけやすくなります。
揉めた案件があるなら、まずはその案件のSOWの変更の履歴を見返し、どの段階で確かめておけば防げたのかを洗い出してから、AIに任せる業務を選びましょう。
条件③見積を作れる人が限られている
3つ目の条件は「見積を作れる人が限られている」ことです。工数の積算ができる人が社内に1人か2人しかおらず、その人の予定が空かないと見積が出せない会社では、実績の工数を記録に残す取り組みに意味があります。
見積を作れる人が限られる原因は、理由②で見たように、実績の工数が個人の表計算に残っていることにあります。AI活用を進めるために実績の工数を会社の記録に残し始めると、見積の根拠をほかの人も読めるようになり、AIを使わない場面でも見積の相談が特定の人に集まりにくくなります。
最終の人日を決める責任は、引き続き見積を作れる人が持ちます。AIに過去の実績を並べさせて根拠を探す時間を減らし、その人が人日を決める時間を確保しましょう。
ITコンサルでAI活用を急がなくてよい3つの条件
前章では、AI活用を先に進めるべき条件を見てきました。営業の準備にかかる時間が小さい会社や、AIに読ませる記録を社内に置けない会社は、AI活用を急がずに様子を見て構いません。こうした会社では、費用と手間に見合う効果が出にくいためです。急がない判断をするときも、その理由を言葉にしておくと、状況が変わったときに見直しやすくなります。そこでここでは、ITコンサルでAI活用を急がなくてよい3つの条件を解説します。
条件①提案が定型の価格表で済む
1つ目の条件は「提案が定型の価格表で済む」ことです。作業の範囲がほぼ決まったサービスを、決まった価格表で提案しているITコンサルでは、引合いのたびに工数を積み上げる必要がありません。
この場合、営業の準備でAIに任せられる作業は、相手企業の情報を集める程度に限られます。提案書も価格表に沿って作れるため、AIの下書きで減らせる時間は小さく、Agentforceの利用料と設計の手間に見合わないことがあります。たとえば、決まった範囲の導入作業を一式の価格で売っている場合、引合いのたびに確かめるのは、依頼がその範囲に収まるかどうかだけです。
定型のサービスを売る会社でも、導入後の追加提案で個別の見積が必要になる場合があります。その場合は、追加提案の業務だけを対象にして、効果があるかを確かめるところから始めましょう。
条件②受託より製品の販売が中心である
2つ目の条件は「受託より製品の販売が中心である」ことです。自社で開発したソフトウェアの販売が売上の中心で、受託の案件が少ない会社では、本記事で見てきた工数の積算やSOWの調整の業務がそもそも少なくなります。
製品の販売が中心の営業では、見積も価格表とライセンスの数で決まる場合が多く、商談の進め方がITコンサルの受託営業とは違います。AIの使い方も引合いの整理や商談の記録の要約が中心になり、本記事の8つの業務とは重なる部分が少なくなります。
受託の案件が一部にある会社であれば、受託の案件の引合いだけを対象に試すことはできます。売上のうち受託が占める割合を確かめてから、AIを入れる範囲を決めましょう。
条件③顧客の資料を社外に置けない契約が多い
3つ目の条件は「顧客の資料を社外に置けない契約が多い」ことです。秘密保持契約で、顧客から預かった資料を指定の場所以外に置けない案件が多い会社では、現行業務の調査やPoCの設計で読ませたい記録の多くを、AIの参照先に入れられません。
この場合、AIに読ませられるのは自社の提案書のうち顧客の資料を含まない部分や、公開情報に限られます。参照先が限られると下書きの質も上がらず、試しても効果が見えにくくなります。たとえば、現行業務の調査で受け取った業務の流れの図を参照先に入れられなければ、エージェントが整理できるのは打ち合わせで聞いた内容の要約までです。
資料をどこに置けるかは、契約ごとに違います。顧客の資料を社外に置けない契約が多いITコンサルは、Salesforceに置ける情報の範囲から任せる業務を選びます。
ITコンサルがAgentforceを入れる費用3内訳
前章までで、AI活用を進めるかどうかを判断する材料はそろいました。進めると決めたら、次に必要になるのが費用の見立てです。ITコンサルがAgentforceを入れる費用は、Salesforceに払う利用料、社内で記録を整える時間、外部に設計を頼む場合の費用の3つの合計です。利用料だけで考えると、総額を読み違えます。とくにITコンサルでは、受注と失注の仕分けや工数の記録に、社内の時間がかかりやすいでしょう。そこでここでは、ITコンサルがAgentforceを入れる費用を3つの内訳に分けて解説します。
内訳①Flex Creditsで払う利用料
1つ目の内訳は「Flex Creditsで払う利用料」です。Agentforceの料金には、エージェントが処理を実行するたびにクレジットを消費する考え方があり、Salesforceの価格ページではFlexクレジットは100,000クレジットあたり60,000円、Agentforceのアクションは1回あたり20 Flexクレジットと示されています（2026年11月時点）。1回のアクションに換算すると12円です。社内の担当者が使う場合のAgentforceユーザーライセンスは、Flexクレジットを前提に、ユーザーあたり月600円と示されています。
引合いの業務で試算すると、月に10件の引合いを1件あたり5つのアクションで整理する設計なら、月50回のアクションで1,000クレジットを使い、利用料は600円ほどです。
1件の整理で動くアクションの数は、エージェントの設計によって変わります。試す時期に実際の消費を確かめてから、広げる時期の予算を組むようにしましょう。
内訳②受注と失注を仕分ける社内の時間
2つ目の内訳は「受注と失注を仕分ける社内の時間」です。ITコンサルがAgentforceを入れる費用のうち、最も大きくなりやすいのは受注と失注を仕分ける社内の時間です。手順①で見たように、過去の提案書に受注と失注の印を付け、失注の理由を残す作業は、AIに参照させる前提になります。この時間は見積書には出てこないため、費用として見落とされがちです。
見込んでおく時間は、主に次の3つです。
- 提案書の仕分け・・・過去の提案書と商談の結果を結びつけ、受注と失注の印を付ける時間
- 工数の記録・・・案件の終わりに見積と実績の工数を並べて残す時間
- 雛形づくり・・・SOWの条項を1つの雛形にそろえ、変更の履歴を残す時間
これらは営業の担当者や見積を作る人の時間を使うため、通常の業務と並行して進めると後回しになりがちです。対象を直近1年ほどの案件に絞り、担当と期限を決めて進めることで、社内の時間を読みやすくできます。
内訳③設計を外部に頼む場合の支援費
3つ目の内訳は「設計を外部に頼む場合の支援費」です。エージェントの指示やアクションの設計、参照させる記録の範囲の決め方を社内で決めきれない場合は、外部の支援会社に設計を頼むことになります。
支援費は支援の範囲によって大きく変わり、設計から構築、定着までをまとめて頼む形もあれば、社内で構築し、設計の確認だけを頼む形もあります。ITコンサルは自社で構築できる人がいることが多いため、後者の形を選ぶと支援費を抑えられることが少なくありません。
どの形を選ぶ場合も、見積の段階で、記録の整理を支援の範囲に含めるのか、社内で行うのかを確かめておきましょう。内訳②の社内の時間と内訳③の支援費は、どちらが記録を整えるかによって大きさが入れ替わるためです。
ITコンサルがAgentforce導入支援会社を選ぶ3つの見極め方
費用の内訳を見てきましたが、内訳③のように外部の支援を使う場合は、どの会社に頼むかで設計の中身が変わります。ITコンサルがAgentforce導入支援会社を選ぶときは、業界を問わない基準に加えて、工数とSOWと受託の案件管理という固有の事情を見ます。見積と契約の業務に合う設計になるかどうかは、支援会社がこの事情を理解しているかしだいです。そこでここでは、ITコンサルがAgentforce導入支援会社を選ぶ3つの見極め方を解説します。
見極め①工数の見積とAIの下書きを分けて設計するか
1つ目の見極め方は「工数の見積とAIの下書きを分けて設計するか」です。ITコンサルでは工数の見積がそのまま価格になるため、AIに出させる過去の実績の一覧と、人が決める最終の人日を、設計の段階で分けておく必要があります。
支援会社の提案を見るときは、工数の下書きを誰が確かめ、最終の人日を誰が決めるのかが、設計の中に書かれているかを確かめましょう。AIが見積の数字まで出す設計になっている場合は、その数字の根拠をどう説明するのかを聞いておく必要があります。
総合系のSIer、特化系の支援会社、フリーランスのどれに頼む場合も、この点を確かめます。打ち合わせの段階で、工数の積算の業務をどう扱うかを具体的に聞いてみると、ITコンサルの事情を理解しているかが分かります。
見極め②SOWと責任の分担を設計に含めるか
2つ目の見極め方は「SOWと責任の分担を設計に含めるか」です。AIの設計の話になると、エージェントの指示やアクションの作り方に話が集中し、SOWの条項や責任の分担がどう扱われるかが後回しになることがあります。
ITコンサルの営業では、SOWの下書きをAIに出させる場合でも、顧客と合意するのは人です。支援会社がこの線を設計の中で引いているかどうかは、SOWの業務をAIに任せる範囲と、人が確かめる項目を、具体的に説明できるかどうかで分かります。
ITコンサルが支援会社を選ぶときは、SOWの責任の分担まで設計に含めているかを確かめます。契約後の範囲の争いを減らすという目的に照らして、設計の提案を読みましょう。
見極め③受託の案件管理の項目を理解しているか
3つ目の見極め方は「受託の案件管理の項目を理解しているか」です。ITコンサルの案件管理には、見積と実績の工数、PoCの判定の結果、SOWの変更の履歴のように、製品を売る営業の商談管理には無い項目が要ります。
これらの項目を理解していない支援会社は、Salesforceの標準の商談の項目だけでエージェントを組みがちで、ITコンサルの業務で参照したい記録が設計から抜け落ちます。AIエージェント導入支援の会社を比べるときは、受託の案件管理でどの項目を残すべきかを、打ち合わせで具体的に挙げられるかを確かめておきましょう。
ITコンサルは社内で構築できる人がいることが多く、自社で構築するので設計レビュー・アドバイザリーだけ頼みたい場合もあるでしょう。その場合は、Agentforce導入・定着支援の設計レビュー・アドバイザリーで、設計書や構成を一度確認するスポットと、構築期間中に定期的に相談を受ける定例から選べます。要求定義から本番公開までをまとめて頼む場合の期間はおよそ3か月で、定着の支援は本番公開後3か月からです。Agentforce導入・定着支援では無料相談も受け付けています。業界を問わずソリューション営業でAIに任せる業務と支援会社の選び方は、別の記事で比べました。
以上が、ITコンサルがAgentforce導入支援会社を選ぶ3つの見極め方でした。
【一問一答】ITコンサルのAgentforce活用に関するよくある質問
ここまで、ITコンサルの営業でAgentforceに任せられる業務と人に残す判断、参照する記録、始め方と測り方、費用、支援会社の見極め方を見てきました。最後に、ITコンサルのAgentforce活用を検討する担当者から出てきやすい疑問をまとめておきます。質問の順番は、AIにどこまで任せてよいかの線引きから、実際に試すときの進め方へと、検討が進む順です。そこでここでは、ITコンサルのAgentforce活用に関するよくある質問を6つ取り上げます。
章立てと各章の材料の候補を出させるところまでで、課題の定義と解決の方法は人が書きます。当社でも、Agentforceのエージェントで動かしているのは引合いの受付、現行業務の調査、PoCの設計の3つで、提案書の骨子は代表の本田が自分で作っています。提案の骨子は見積の前提になり、見積の責任は人が持つためです。
使えますが、顧客の資料をSalesforceの中に置いてよいかを、契約ごとに先に確かめる必要があります。社内の担当者が使うエージェントは利用者と同じ権限とセキュリティ設定に従うため、参照できる範囲は権限で絞れます。当社の現行業務の調査でも、エージェントに参照させているのは商談と取引先の記録、議事録、Webで調べた相手企業の情報の3つです。
引合いの受付から試すのが進めやすいと考えます。引合いは件数が多く、相手企業の要約や質問項目の下書きのように、人が直した箇所を比べやすい作業が多いためです。当社も2026年の初めから、引合いの受付、現行業務の調査、PoCの設計の3つでAgentforceのエージェントを動かしており、いずれも提案の前の材料づくりにあたる業務です。
本記事では、SOW（作業範囲記述書）を、作業の範囲、成果物、前提条件、責任の分担を書いた文書として扱っています。受託の案件では、契約後に追加の要望が出たとき、それが当初の範囲に入るかを判断する拠り所になります。当社では、契約とSOWは代表の本田が自分で作って顧客と調整しており、SOWの業務にAgentforceは使っていません。
検証範囲と成功基準の案をAIに出させ、関係者を確かめたうえで、成功の基準を顧客と決める順で進めます。当社のPoCの設計では、エージェントに検証範囲の案、成功基準の案、関係者の把握、ほかのエージェントへの影響の有無の確認を出させ、代表の本田が範囲の広がりすぎと関係者の漏れを確かめてから顧客と話しています。
使えます。材料づくりを任せる効果が出やすいのは、営業の準備に使える人の時間が限られる少人数の会社のほうです。当社でも代表の本田が自ら営業しており、引合いの受付、現行業務の調査、PoCの設計の3つにAgentforceのエージェントを使っています。人に残しているのは、顧客固有の事情と数字の根拠を確かめる判断です。
ITコンサルティング会社はAgentforceで提案と見積の根拠を会社に残す
ITコンサルの営業でAgentforceを使うなら、提案書や見積をAIに作らせる前に、その根拠になる記録を会社に残します。ここまで見てきたように、ITコンサルの営業では、引合いの整理、現行業務の調査、PoCの設計案といった材料づくりに多くの時間が使われる一方で、引き受けの可否、課題の定義、最終の人日、成功の基準、SOWの責任の範囲のように、顧客固有の事情と数字の根拠をもとに人が決めるべき判断があります。
提案と見積の根拠を会社に残すには、AIの設定より先に、受注と失注を区別した提案書、案件ごとの見積と実績の工数、PoCの判定の結果、SOWの変更の履歴を会社の記録に残し、次の引合い1件で下書きと人の版を比べるところから始めます。記録が会社に残れば、AIを使う場面でも使わない場面でも、提案と見積の根拠を特定の人の手元だけに置かずに済みます。本記事の内容が、自社のITコンサルの営業でAIに任せる業務と人に残す判断を決める材料として、少しでもお役に立てれば幸いです。
