AI業務活用支援の見積もりの作り方｜あとで足せない項目

2026年6月5日

朝比奈蒼

この記事のポイント

✓AI業務活用支援見積もりの出し方を
✓受注後の実務から逆算して解説
✓あとから追加できなくなる項目

AI業務活用支援の見積もりの出し方でつまずく原因は、金額の決め方ではありません。工程の切り出しが粗いまま提出し、あとから足せない項目を無償で抱えることにあります。結論から書きます。この仕事の見積書で最も重要なのは合計欄ではなく、前提条件と受け入れ基準の2つです。この2つが書かれていない見積書は、契約後に発生する追加作業をすべて自分の負担に変えます。この記事では、工程の分け方、あとから請求できなくなる項目の具体例、前提が崩れたときの扱いまで、受注後の実務から逆算して手順を整理します。

見積もりを作る前に確定させておくこと

見積もりは、確定した情報の上にしか成り立ちません。ところがAI業務活用支援の相談は、相手の側も何を頼めばよいのか分かっていない状態で始まることが多く、確定していない前提のまま金額だけを求められがちです。ここで急いで数字を出すと、その数字が一人歩きします。

確定させるべきは3点です。第一に、対象となる業務の単位です。部署名や「営業の効率化」といった括りではなく、「見積書の作成」「問い合わせメールの一次返信」というレベルまで落とします。第二に、終わったと判断する状態です。納品物なのか、担当者が独力で運用できる状態なのかで、作業量は大きく変わります。第三に、相手の社内から出せる時間です。伴走型の支援は相手の時間が前提になっているため、ここが空欄のまま組んだ計画は必ず遅れます。

この3点が埋まらないうちは、金額ではなく進め方を提示します。「まず業務の棚卸しまでを一区切りとして、その結果を見て次の範囲を決める」という提案は、相手の社内でも通りやすい形です。段階を切ることは支援者側の保険であると同時に、依頼する側の稟議を助ける手順でもあります。この領域でどこまでが支援の範囲とされるかはAIコンサル・業務活用支援のお仕事で整理されている業務の分類が目安になります。

相手が想定している「一式」の中身を分解する

「AI活用の支援を一式でお願いしたい」という依頼を受けたとき、相手の頭の中には具体的な作業が3つか4つしかありません。一方で支援者が実際に踏む工程は、その何倍もあります。この差が、後の食い違いの正体です。

分解の手順は単純です。相手が挙げた作業を紙に並べ、その前後に必要な準備と確認を書き足していきます。たとえば「議事録の自動化」と言われたら、その前には録音方法の統一、用語辞書の整備、機密情報の扱いの決定があり、その後には出力形式の調整、担当者への説明、運用ルールの文書化が続きます。この一覧を相手に見せると、多くの場合その場で驚かれます。驚いてもらうことが目的です。一式という言葉が指す中身を共有できれば、見積もりの説明は半分終わっています。

支援の型によって見積もりの立て方が変わる

支援の型は伴走型、受託開発型、研修型に大別できます。伴走型は期間に対する見積もりが基本になり、成果物ではなく関与の密度で組み立てます。受託開発型は成果物と受け入れ基準を先に定義し、そこから工数を積みます。研修型は準備と実施の回数で決まり、教材の権利の扱いを別途書く必要があります。

厄介なのは、依頼が3つの型をまたぐ場合です。「仕組みを作って、使い方を教えて、その後も相談に乗ってほしい」という依頼は、受託開発と研修と伴走の複合です。これを一本の金額でまとめると、どの部分が終わったのかが判定できません。型ごとに区切って項目を立て、それぞれに終了条件を書くのが実務的な解決です。

見積書を構成する項目の並べ方

項目の並べ方には順番があります。時系列に並べるのが最も伝わりやすく、相手が自社の動きを想像しやすくなります。

調査と設計の工程

最初に来るのは現状の調査です。業務の手順を聞き取り、実際の資料を確認し、どこに時間がかかっているかを特定します。この工程を見積書に立てない人が多いのですが、実際には全体の作業量のかなりの部分を占めます。相手からすると「話を聞くだけ」に見えるため、項目として明示しないと存在しないものとして扱われます。

設計は、調査の結果をもとに、どの作業をどう置き換えるかを決める工程です。使うツールの選定、入出力の形式、権限の設計、例外時の扱いまで含みます。ここで手を抜くと後の作業がすべて後戻りします。設計の成果物を文書として納品対象に含めておくと、工程の存在が相手に見えます。

実装と検証の工程

実装は、実際に動く形を作る工程です。プロンプトの整備、テンプレートの作成、既存システムとの接続、動作確認までが含まれます。接続を伴う場合は、相手側のシステム管理者の協力が前提になるため、その調整時間も項目として立てます。開発の比重が大きい案件では、工程の分け方そのものがアプリケーション開発のお仕事で扱われる進め方に近づきます。

検証は、作ったものが業務で使えるかを確かめる工程です。ここで重要なのは、誰が何をもって合格と判断するかを事前に書いておくことです。受け入れ基準がないと、検証は終わりません。「担当者が違和感なく使えるまで」といった曖昧な基準は、実質的に無期限の修正義務になります。

定着と引き継ぎの工程

作ったものが使われるようにする工程です。説明会の実施、手順書の作成、問い合わせへの対応が含まれます。この工程は、相手が最も過小評価する部分です。導入すれば使われると考えている会社は少なくありませんが、実際には使われないまま放置される例のほうが多く見られます。

引き継ぎには、運用を誰が担うかの決定が含まれます。相手の社内に担当者が決まっていない場合、事実上の運用を支援者が続けることになります。契約が終わっても問い合わせが来る状態は、ここを曖昧にした結果です。手順書や運用ルールを文書として整える作業は、体裁が整っているほど社内で定着します。文書の様式や書き方の基礎はビジネス文書検定が扱う範囲と重なり、この素養があると引き継ぎの成功率が上がります。

あとから足せない項目

見積書に書かなかったせいで、後から請求できなくなる項目があります。ここが本題です。以下は、いずれも「言われなかったからやらなかった」が通用しない性質を持っています。

前提条件

最も重要でありながら、最も抜けやすい項目です。前提条件とは、この見積もりが成り立つために相手側が満たすべき条件のことです。対象業務は初回に特定した範囲に限ること、必要な資料は着手から2週間以内に提供されること、担当者は指名され打ち合わせに参加できること、既存システムへの接続が必要な場合は管理者の協力が得られること。こうした条件を書いておかないと、条件が崩れた際の遅延と追加作業をすべて支援者が引き受けることになります。

前提条件は、相手を疑う文章ではありません。相手の社内で誰が何を用意するのかを明確にする文章です。実際、この欄があることで相手の社内調整が進むという効果があります。「資料を2週間以内に出す必要がある」と書かれていれば、担当者はその根拠を持って社内に依頼できます。前提条件は支援者の防具であり、同時に相手の武器でもあります。

環境とアカウントの用意

どのツールを誰の契約で使うかは、着手前に決めておくべき項目です。相手が契約すると思っていたのに用意されていない、あるいは支援者のアカウントで作業を進めた結果、契約終了後に相手が使えなくなるという行き違いが起きます。

見積書には、必要な環境の一覧と、その手配を誰が行うかを書きます。アカウント発行、権限の付与、社内ネットワークからの接続許可まで含めます。これらの手配は相手の情報システム部門が動く必要があり、想定より時間がかかることがあります。手配が遅れた場合に着手日をずらす旨も、前提条件の一部として書いておきます。

データの整備作業

AI活用の成否は、渡すデータの質でほぼ決まります。そして、そのデータはたいてい整っていません。表記が揺れている、複数の様式が混在している、更新が止まっている。この整備作業は、量によっては実装より重くなります。

見積もりの段階で実物を見ていない場合、この項目は必ず条件付きにします。「提供されるデータが一定の形式で揃っていることを前提とし、整備が必要な場合は別途見積もる」と書いておけば、後から交渉ができます。書いていなければ、整備は支援の一部として無償で期待されます。データの前処理が省ける状況では作業時間が大きく変わることは、次の記述からも読み取れます。

従来の方法では、図面を見ながら手作業で数量を拾い出したうえで表計算ソフトに入力するため、「毎回同じ作業で時間がかかる…」と感じていた方も多いでしょう。 AI積算なら、PDFや画像の図面を自動で読み取り、必要な数量をすぐに抽出できるため、作業時間が従来の半分以下になることも珍しくありません。

読み取りの精度は、元の資料の状態に強く依存します。整った資料が揃っている前提での効果と、揃っていない現場での効果は別物です。この差を見積もりの前提として明示しておくことが、後の期待値のずれを防ぎます。

検証と受け入れの基準

何をもって完了とするかを書かない見積書は、完了しません。受け入れ基準は、可能な限り判定できる形で書きます。「指定した10件のサンプルで、担当者が修正なしに使える出力が7件以上得られること」のように書けば、判定は明確です。数値化が難しい場合でも、「担当者が単独で1件を最後まで処理できること」という状態で書けば判定できます。

基準がないまま検証に入ると、相手の担当者が思いついた要望が次々に追加されます。個々の要望は小さく、断りにくい形で来ます。基準が書いてあれば、「その要望は基準の範囲外なので、別途整理します」と返せます。この一言が言えるかどうかが、終盤の負担を左右します。

修正の回数と範囲

検証で出た指摘への対応は、回数を区切ります。区切っていない見積書は、無制限の修正義務を含んでいると解釈されます。2回までを含む、それを超える場合は別途、という書き方が一般的です。

回数だけでなく、範囲も書きます。基準に照らして不足がある場合の修正は含む、基準に含まれない新しい要望は含まない、という区別です。この区別があると、修正と追加開発の線引きが会話でできるようになります。

教育と問い合わせ対応

説明会を何回行うか、資料を作るか、実施後の質問にいつまで答えるか。これらは相手にとって当然含まれていると考えられがちな項目です。含めるなら回数と期間を書き、含めないなら含まないと書きます。書かないという選択肢はありません。

問い合わせ対応は特に、期間を切らないと契約終了後も続きます。「納品後30日間のメールでの質問対応を含む」と書けば、それ以降は別の話として交渉できます。相手との関係が良好なほど断りにくくなるため、最初に書いておく価値があります。

権利と再利用の取り決め

作成したプロンプト、テンプレート、手順書を、支援者が他の案件で再利用してよいかは、後から決められない項目です。何も書かなければ、相手が全面的な権利を主張する余地が残ります。逆に、汎用的な手法まで独占されると、支援者は同じ領域の仕事を請けられなくなります。

書き方としては、相手の業務固有の内容は相手に帰属し、汎用的な手法やひな型は支援者が引き続き利用できる、という切り分けが実務的です。研修教材を作る場合は、社内での再配布の範囲も決めます。この項目は金額に直接影響しませんが、その後の仕事の自由度を左右します。

既存のやり方からの切り替え作業

新しい手順を作ることと、今のやり方をやめることは別の作業です。切り替えの当日には、旧手順との並行運用、過去データの移行、関係部署への周知、外部の取引先への連絡が発生します。この作業は実装の一部として無償で期待されやすいのですが、実際には関係者が多く、調整に時間がかかります。

見積書には、切り替えの範囲を明示します。並行運用の期間を何日とするか、過去のデータをどこまで移すか、周知の資料を誰が作るか。特に過去データの移行は、量と状態によって作業量が跳ね上がる典型例です。「移行対象は直近の稼働分のみとし、それ以前の分は対象外」といった形で範囲を切っておかないと、着手後に全件の移行を求められる場合があります。切り替えの失敗は業務そのものを止めるため、相手の期待も高くなります。だからこそ、含む範囲と含まない範囲を先に書いておく必要があります。

見積もりを作る手順

項目が分かったら、順番に組み立てます。

工程を書き出してから時間を当てる

先に金額を考えると、工程が金額に引きずられます。まず工程をすべて書き出し、それぞれに必要な時間を当て、最後に単位あたりの考え方を掛けます。この順番であれば、相手から金額の調整を求められたときに、どの工程を削るかという会話に持ち込めます。一式でまとめた見積もりでは、削る対象が見えないため、全体を下げる交渉になります。

工程を書き出す際は、自分が手を動かす時間だけでなく、打ち合わせ、調整、待ち時間も含めます。相手の返答待ちで進まない期間は、支援者の稼働として計上できなくても、案件を占有する期間として存在します。期間の見積もりには、この待ち時間を織り込みます。

前提条件を先に書いてから見直す

前提条件を書くと、書いている途中で確認漏れが見つかります。「担当者は誰か」「資料はいつ出るのか」を書こうとして、まだ聞いていないことに気づくという流れです。前提条件は、確認事項の一覧としても機能します。

書き終えたら、それぞれの条件が崩れた場合に何が起きるかを想像します。崩れる可能性が高く、影響が大きい条件については、崩れたときの扱いも併記します。「資料の提供が遅れた場合、着手日を同日数だけ後ろにずらす」という一文があるだけで、遅延の責任が明確になります。

段階に分けて提示する

全体を一括で提示するか、段階に分けるかは選択できます。段階に分けると、相手は最初の判断を小さくできます。支援者は相手の実行力を確認しながら次に進めます。相手の社内でも通りやすい形です。

実際に、秋田化学工業株式会社では見積もり作成時の図面探索時間が「1〜2日から5〜10分」に大幅短縮され（出典：「図面の原価見積もりは自動化できる？見積もり業務を大幅削減する方法とは」）、株式会社プラポートでは見積もり回答時間が「1時間から20分」へと66%削減を実現しています（出典：「製造業の革新的技術！中小企業でもできる図面から自動で見積もりを作成するAI技術」）。出典: smart-generative-chat.com

見積もり業務そのものを効率化した事例が出ているように、資料の探索や過去案件の参照は自動化の余地が大きい領域です。支援者自身の見積もり作成でも、過去に作った項目一覧をひな型として持っておくと、抜けが減り、作成時間も短くなります。

前提が崩れたときの扱い

見積もりは予測であり、外れます。重要なのは、外れたときにどう扱うかを先に決めておくことです。

変更が起きたら都度書き残す

範囲の変更、条件の変更、日程の変更は、口頭で合意しても記録がなければ存在しないのと同じです。打ち合わせの議事録に、決まったこととして一行残します。相手に確認の返信をもらえれば、証跡として十分です。

変更のたびに追加の請求をするかどうかは、案件との関係で判断します。小さな変更をすべて請求すると関係が硬直します。ただし、請求しない場合も記録には残します。記録があれば、変更が積み重なった段階で「ここまでの追加分をまとめて整理させてください」と切り出せます。記録がなければ、その会話自体が始められません。

追加分は範囲と時間で説明する

追加の見積もりを出すとき、金額の話から入ると交渉になります。範囲と時間の話から入ると、説明になります。「当初の範囲は1業務でしたが、対象が3業務に増えたため、調査と設計の工程がそれぞれ増えます」という説明であれば、相手も社内で説明できます。

相手が社内で説明できる形にすることは、支援者の利益でもあります。担当者が上司に説明できずに立ち往生すると、追加分は宙に浮きます。宙に浮いた作業は、たいてい支援者が飲むことになります。

見積書の様式と伝え方

同じ内容でも、渡し方によって伝わり方が変わります。様式は相手の社内で回覧されることを前提に組み立てます。

使う道具は相手に合わせる

表計算ソフトで作るか、文書ソフトで作るか、PDFで固めて渡すかは、相手の社内の慣習に合わせるのが無難です。稟議に添付する必要がある会社では、印刷して読める形式が求められます。逆に、社内のやり取りが全面的にオンラインで完結している会社では、編集できる形式のほうが扱いやすい場合があります。初回のやり取りで、相手がどの形式のファイルを送ってきたかを見れば、おおよその見当がつきます。

管理の道具も決めておきます。見積もりの版が複数になると、どれが最新か分からなくなります。ファイル名に日付と版番号を入れ、変更した箇所を1行で添えるだけで、相手の社内での混乱を防げます。版が変わった理由が書かれていない見積書は、担当者が上司に説明できず、そこで止まります。止まった案件は、たいてい理由が伝わらないまま流れます。

数字の根拠を1枚に添える

見積書そのものは項目と金額の一覧ですが、その後ろに根拠を1枚添えると、質問の量が減ります。各工程に何日を見込んでいるか、その日数の内訳は何か、誰の作業を想定しているか。この1枚があると、相手は自社の判断材料として使えます。

根拠を出すことに抵抗を感じる人もいますが、出さないことによる不信のほうが実害が大きいと考えられます。相手が知りたいのは安いかどうかではなく、この金額で本当に終わるのかどうかです。工程と日数が示されていれば、その問いには答えられます。1枚で足りる資料なので、作る手間に対して効果は大きい部類に入ります。

金額の調整を求められたときの対応

提示した見積もりに対して、下げてほしいと言われる場面は必ず来ます。ここでの対応の仕方が、その後の関係を決めます。

削るのは工程であって品質ではない

調整を求められたとき、全体を一律に下げるのは最も避けたい対応です。作業量が変わらないまま対価だけが下がるため、途中から手を抜くか、無理を続けるかの二択になります。どちらも結果は良くありません。

正しい対応は、工程を削ることです。調査の範囲を狭める、対象業務を1つに絞る、定着支援を含めない、教育を資料の提供までにする。削った内容と、それによって相手側が引き受けることになる作業を、はっきり伝えます。「この部分を外すと、手順書の作成は御社側で行っていただく形になります」と説明すれば、相手は判断できます。工程を分解した見積書を作っておく本当の理由は、この会話を成立させるためです。

値引きの代わりに条件を変える

金額を動かさずに相手の負担感を下げる方法もあります。支払いを分割にする、着手時と完了時に分ける、期間を延ばして月あたりの負担を平準化する。相手の制約が予算の総額ではなく単月の枠にある場合、この調整だけで話がまとまります。

相手の事情を聞かずに値引きに応じると、次の案件でも同じ水準が基準になります。一度下げた条件は戻せません。何に困っているのかを一度確認してから対応を選ぶという順番を守るだけで、不要な値引きの多くは避けられます。

市場を長く見てきた立場からの観察

20年この市場を見てきた立場から言えば、見積もりで揉める案件は、金額が高すぎたから揉めるのではなく、何が含まれているのか分からないから揉めます。同じ内容でも、工程が分解され、前提条件が書かれ、含まれないものが明示されている見積書は、金額の交渉に入る前に信頼を得ます。逆に一式で丸めた見積書は、金額が控えめでも「本当にこれで足りるのか」という不安を残します。

運営者として見てきた限りでは、継続して依頼される人ほど、見積書を提案書として使っています。項目を並べることで、相手の社内に「何をやる取り組みなのか」を伝える資料になるからです。これは中間に人が入らない直接取引の形で特に効いてきます。手数料0%で直接やり取りできる在宅ワーク仲介サイトの仕組みでは、条件の説明も交渉も当事者同士で行うため、書面の質がそのまま成約率に反映されます。仲介が入ると条件の細部が薄まり、後から範囲が広がる傾向が見られます。手取りが厚くなるという以上に、条件を自分の言葉で決められることの価値が大きいと言えます。

自分の作業がどの職種の水準に近いかを把握しておくと、工程ごとの時間の当て方にも根拠が持てます。開発や接続の比重が大きい場合はソフトウェア作成者の年収・単価相場、資料整備や手順書作成が中心の場合は著述家，記者，編集者の年収・単価相場が、それぞれ近い領域として参照できます。隣接分野の相場感を知っておくと、値付けの説明に一貫性が出ます。

見積書を資産として積み上げる

一度作った見積書は、次の案件のひな型になります。工程の一覧、前提条件の文面、含まれないものの書き方は、案件が変わっても大部分が流用できます。案件が終わるたびに、想定より時間がかかった工程と、書いておけばよかった前提条件を一行ずつ追記していくと、数件分で実用的なひな型ができます。

正直なところ、見積書の作成は面倒な作業です。ただ、この面倒を前倒しで払うか、契約後に無償の作業として払うかの違いでしかありません。前倒しで払ったほうが、確実に安く済みます。周辺領域の案件でも同じ構造が働くため、AI・マーケティング・セキュリティのお仕事のように専門性が近い分野へ広げる際も、ひな型はそのまま流用できます。海外の依頼者とやり取りする場合の書面の作り方はUpworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法に具体例があり、条件の明示という点では国内案件と考え方は変わりません。働き方全体の設計を見直したい場合はWebマーケティングフリーランスで海外ノマド！年収、スキル、成功への道も参考になります。

よくある質問

Q. 見積書に前提条件はどこまで書けばよいですか？

対象業務の範囲、資料提供の期限、担当者の指名、必要な環境やアカウントの手配責任、既存システムへ接続する場合の協力体制の5点は最低限書きます。加えて、条件が崩れた場合の扱いも併記します。資料の提供が遅れたら着手日を同日数ずらす、といった一文があるだけで遅延の責任が明確になり、後から交渉する足場が残ります。

Q. 修正対応は何回まで含めるのが一般的ですか？

回数を区切ることが重要で、2回程度を含め、それ以上は別途とする書き方がよく使われます。回数と同時に範囲も書きます。受け入れ基準に照らして不足がある修正は含み、基準に含まれない新しい要望は含まない、と区別しておくと、修正と追加開発の線引きを会話で処理できます。区切らないと無制限の修正義務と解釈されます。