AI・セキュリティ支援の見積もりの作り方｜あとで足せない項目

AI・セキュリティ支援の見積もりで赤字になる人は、金額の付け方を間違えているのではない。範囲の書き方を間違えている。作業そのものより、作業に付随する待ち時間、説明の場、関係者の調整に時間が溶けていく分野だからだ。この記事では、見積もりを出す前に固めておく前提条件、費目をどう分けるか、そしてあとから追加請求できずに自腹になりやすい項目を、実務の順番どおりに整理する。

見積もりは金額ではなく範囲を書く書類だ

見積書を「いくらでやるか」を伝える紙だと思っていると、必ず削られる。発注側は金額だけを見て他社と比べ、安いほうを選ぶ。そこで勝っても、範囲が曖昧なまま安値で受けることになるので、待っているのは消耗だけだ。

見積書の本体は、金額の行ではなく、その上下にある「何をやるか」「何をやらないか」「何を前提にしているか」の記述にある。ここが書けていれば、金額が高くても比較の土俵に乗る。書けていなければ、金額が安くても信用されない。

とくにAI・セキュリティ支援では、発注側が「どこまでやれば十分か」を自社で判断できていない。だから見積書が、そのまま作業の定義書として読まれる。読んだ発注者が社内で説明できる形になっているかどうかが、通るか通らないかを分ける。

見積もりを作る前に固める四つの前提

金額を計算し始める前に、次の四つを確定させる。ここが未確定のまま数字を出すと、あとで全部ずれる。

目的、つまり何のために依頼しているか

取引先や監査から求められて対応するのか、社内で事故があって再発防止をしたいのか、経営方針として整備を進めるのか。目的によって、必要な成果物の形式も深さも変わる。

外部から要求されている場合は、その要求文書が実質的な仕様書になる。見せてもらえるなら必ず見せてもらう。要求水準を知らずに作った成果物は、提出先で突き返される可能性がある。突き返されたときの作り直しは、たいてい無償で降ってくる。

範囲、つまりどこまでを見るか

対象となるシステムやサービスの数、対象となる部門の数、対象とする生成AIの種類。この三つを数で確定させる。「社内全体」という言葉は範囲ではない。数で書けるまで分解する。

分解できない場合は、分解すること自体を最初の工程として提案する。要件整理を独立した工程にするのは、この分野では標準的な進め方だ。

データ、つまり何を渡してもらえるか

構成図、規程類、ログ、アンケート結果、既存の資料。何が既にあって、何をこちらが作るのかを確認する。既存資料が整っている案件と、ゼロから作る案件では作業量が何倍も違う。

「資料はあります」と言われても、鵜呑みにしない。実物を一部見せてもらう。更新が5年前で止まっている構成図は、無いのと同じどころか、誤った前提を与えるぶん有害になる。

制約、つまり何ができないか

アクセスできない環境、聞き取りに応じられない部署、公開できない情報、決裁のスケジュール。制約は作業の効率を直撃する。

とくに多いのが、環境へのアクセス権が発注者側の手続きで数週間かかるケースだ。この待ち時間は作業ではないが、案件は拘束される。前提条件に書いておかないと、遅延の責任がこちらに来る。

進め方の設計そのものについては、外部の解説でも同じ順番が推奨されている。

進め方としては、①短期間での要件整理ワークショップ、②技術案とAI導入 見積もりのたたき台作成、③運用コストを含めたROI試算、④小さく始めて改善するロードマップ策定、という流れが現実的です。特に①の要件整理と③のROI試算は、事業側・現場側・情シス・経営層の認識を揃えるうえで重要なステップです。ここを丁寧に行うことで、後から「こんなに運用コストがかかるとは聞いていない」「ROIが合わない」といった齟齬を防げます。 出典: sophiate.co.jp

要件整理を先に置く理由は、発注側の認識を揃えるためであると同時に、受注側が範囲を確定させるためでもある。認識が揃っていない状態で出した見積もりは、揃った瞬間に無効になる。

費目を五つに分ける

一式いくらで出すのをやめる。費目を分けると、削られたときにどこを削るかの交渉ができる。一式だと、金額全体を値切られて終わる。

一つ目、調査とヒアリング

現状把握のための資料読み込み、聞き取り、環境の確認。ここは対象の数に比例するので、部門数やシステム数を掛け算で見積もる。

聞き取りは、実施時間だけでなく、日程調整と議事の整理を含めて考える。一件の聞き取りに対して、調整と整理でほぼ同じだけの時間がかかる。この分を入れ忘れると、聞き取りが多い案件で確実に赤字になる。

二つ目、成果物の作成

報告書、ガイドライン、チェックリスト、教育資料といった納品物そのものを作る作業。章立てとページ数の想定を前提条件に書き、それを基準に見積もる。

「ページ数は成り行きで」とすると、増えたときに追加請求できない。想定を書いておけば、大幅に超える場合に相談ができる。

三つ目、レビュー対応

提出後の指摘を反映する作業。ここを費目として独立させるのが重要だ。作成費に含めてしまうと、修正が増えたときに何を根拠に追加を求めるのかが説明できない。

ラウンド数を明記する。成果物を提出してから指摘を一括で受け取り、反映して再提出するまでを1ラウンドとし、上限を3回とするのが実務的な線になる。

四つ目、報告と説明

成果物を作るだけでなく、説明の場が求められることが多い。担当者への説明、部門長への報告、経営層向けのプレゼン、全社向けの研修。これらは全部別の作業だ。

説明の場は、資料の作り直しを伴う。経営層向けには要約と結論だけの版が要るし、現場向けには手順に落とした版が要る。同じ内容でも、聞き手が変われば別の成果物になる。ここを見積もりに入れていないと、無償の作り直しが何度も発生する。

五つ目、運用と継続

納品後の問い合わせ対応、定期的な見直し、外部環境の変化にあわせた更新。単発の案件なら「本見積もりに運用支援は含まない」と書き、必要なら別途の継続契約として提案する。

この分野は一度作って終わりにならない。新しい攻撃手法が出れば観点が増え、生成AIサービスの仕様が変われば記述が合わなくなる。だから継続の需要は必ず生まれる。生まれたときに別契約として出せる形にしておくのが、健全なやり方になる。

あとから足せない項目

ここからが本題だ。見積もりに入れ忘れると、まず追加請求できない項目を挙げる。

関係者の人数とレビューの回数

いちばん大きいのがこれだ。成果物の内容が変わらなくても、レビューする部署が増えるだけで作業は膨らむ。情報システム部門が確認し、法務部門が別の観点を出し、そのあと役員が三つ目の観点を出す。

前提条件に「レビューにご参加いただく部署は3部門を想定しています」と数で書く。数で書いておけば、増えたときに「当初は3部門と伺っておりましたので、追加分をお見積もりします」と事務的に話せる。書いていないと、何部門増えても同じ金額のままだ。

説明会や研修の実施

「作った資料をもとに、現場に説明してもらえますか」という依頼は、納品後に必ず来る。作成と実施は別の作業だと、最初に切り分けておく。

見積書に「成果物の説明は、担当者様向けのオンライン説明1回を含みます。部門別説明会、全社研修等は別途お見積もりとなります」と書く。この一行があるだけで、あとの会話が楽になる。

再診断と再確認

指摘した項目を発注者が直し、「直したので再度見てほしい」という依頼。これは修正ではなく新しい作業だ。含めるなら回数と範囲を書き、含めないなら「再診断は含まない」と明記する。

ここを曖昧にすると、相手が直すたびに見る流れになり、実質的に無償の運用支援を続けることになる。

情報の受け渡しと廃棄の手間

機密情報を扱う案件では、受け渡し方法の設計、安全な保管、案件終了後の削除と報告まで作業が発生する。これは目に見えないので、見積もりから落ちやすい。

落としても金額としては小さいが、問題は時間だ。相手のセキュリティ要件にあわせて手順を組む作業は、案件によっては数日かかる。相手の環境に専用端末の設定が必要な場合もある。前提条件に「情報の受け渡しは、貴社指定の方法にあわせて別途調整いたします」と書いておくと、大がかりになったときに相談できる。

権限やアカウントの取得待ち

環境にアクセスする権限の発行に、発注者側の社内手続きで2週間かかることは珍しくない。この間、こちらは着手できないが、納期は動かない。

前提条件に「作業環境へのアクセス権は、契約後5営業日以内にご提供いただくことを前提としています。提供が遅れた場合、納期は同日数分後ろ倒しとなります」と書く。納期の責任がこちらに来ない形にしておく。

外部サービスやツールの費用

診断ツール、検証環境、有償の情報サービス。誰が契約して誰が払うのかを決める。こちらが立て替える場合は費目として明示し、発注者が契約する場合はその旨を前提条件に書く。

生成AIサービスを使う場合は、費用の話だけでなく、機密情報を入力してよいかの確認が要る。入力しない前提なら明記する。ここを曖昧にしたまま進めるのは、この分野では避けたほうがいい。

前提条件の書き方

前提条件は、見積書の中でいちばん重要な欄だ。書き方には型がある。

数と日付で書く

「関係者が多い場合」ではなく「レビュー参加部署3部門まで」と書く。「早めにご提供ください」ではなく「契約後5営業日以内」と書く。数と日付で書かれた前提だけが、あとで根拠として機能する。

「〜を前提としています」で終える

前提条件の各行は「〜を前提としています」で終える。禁止や要求の形にすると、発注者は身構える。前提という言い方なら、条件の共有として受け取られる。

変わったときの扱いを一行足す

前提を並べたあとに「上記の前提に変更が生じた場合は、作業範囲および納期を再度ご相談させていただきます」と書く。この一行が、変更管理の入口になる。

書きすぎない

前提条件が二十行あると、発注者は読まない。読まれない前提は無いのと同じだ。効くのは、その案件で実際に動きそうな項目だけに絞ったときになる。多くても8項目までに収める。

相見積もりで比較されるときの整え方

複数社に見積もりを取っている案件では、比較のされ方を意識して作る。

費目の名前を一般的な言葉にする

自分だけが使っている言い方をやめる。調査、作成、レビュー対応、報告、運用。この程度の一般的な区分にしておくと、他社の見積もりと並べたときに比較できる。比較できない見積もりは、検討の土俵から外される。

除外項目を明示する

安く見える見積もりは、たいてい何かを含んでいない。こちらが含んでいる項目を明示し、含んでいない項目も明示すると、発注者は他社の見積もりを読み直す。この時点で、金額だけの勝負ではなくなる。

判断材料を一枚添える

見積書とは別に、進め方と想定される成果物の目次案を一枚添える。発注者は社内でこれを回して説明する。説明しやすい資料を出した相手が選ばれる。金額の差が大きくない場合、この一枚で決まることがある。

有効期限を書く

「本見積もりの有効期限は発行日から30日とします」と書く。半年後に「あの見積もりでお願いします」と言われる事態を防げる。半年経てば前提が変わっているのが普通だ。

概算と確定を分ける

要件が固まっていない段階で、確定見積もりを出さない。ここを混同すると、あとで身動きが取れなくなる。

概算は幅で出す

初期の相談段階では、幅を持たせた概算を出す。そのうえで「要件整理の工程を経て、確定のお見積もりを提出します」と伝える。幅で出すこと自体は不誠実ではない。むしろ、要件が固まっていないのに一点の数字を出すほうが、根拠がない。

要件整理を有償の工程にする

要件整理を無償の営業活動として全部やってしまうと、そこがいちばん大変な作業なのに一円にもならない。短期の工程として切り出し、その成果物として要件定義と確定見積もりを納品する形にする。

この形は発注側にとっても悪い話ではない。要件が固まった状態の文書があれば、他社に相見積もりを取ることもできる。取られる可能性を怖がるより、要件整理の質で選ばれるほうを狙ったほうが、結果的に強い。

撤退の条件を書いておく

要件整理の結果、そもそも想定していた進め方が合わないと分かることがある。その場合に、無理に本編に進まず終われる形にしておく。「要件整理の結果、ご要望の実現方法が当初想定と異なる場合は、あらためて進め方をご相談いたします」と書いておけば、双方が引ける。

見積書に書く項目と並べる順番

費目と前提条件が固まったら、実際の書面に落とす。並べる順番には意味がある。

表紙にあたる部分

件名、宛先、発行日、有効期限、そして合計金額。ここは事務処理で使われる欄なので、迷わず読める形にする。件名は「セキュリティ体制整備支援業務」のように、契約書の件名としてそのまま使える言い回しにしておくと、あとの手続きが早い。「ご提案」「お見積り」といった営業的な言葉を件名に混ぜると、社内稟議の書類として扱いにくくなる。

作業範囲の記述

合計金額の直後に、金額の明細ではなく作業範囲の記述を置く。読む順番として、金額を見た人が次に知りたいのは「これで何をしてくれるのか」だからだ。ここに三行から五行で、対象、実施する作業、納品する成果物を書く。

対象は数で書く。「対象システム3件、対象部門4部門」のように具体的に書けば、この時点で範囲の認識合わせが済む。成果物は名称と形式を書く。「現状評価報告書（PowerPoint形式、想定30ページ）」のように書くと、あとで分量の話ができる。

明細の行

ここで初めて費目ごとの内訳を並べる。行数は多くても十行程度にする。細かく割りすぎると、発注者は一行ずつ削ろうとしてくる。逆に一行にまとめると全体を値切られる。五つの費目を軸に、必要に応じて細分するくらいが扱いやすい。

数量の単位も揃える。人日で出すのか、一式で出すのか、対象件数あたりで出すのかを、案件の中で混在させない。混在すると発注者が合計を検算できず、根拠が疑われる。

含まない項目の欄

明細の下に「本見積もりに含まない作業」という欄を作る。除外を明細と同じ書面に置くのが要点だ。別紙に逃がすと読まれない。ここに、部門別説明会、再診断、運用支援、外部ツールの利用料など、この案件で発生しそうなものを並べる。

前提条件の欄

最後に前提条件を置く。数と日付で書いた項目を、多くても八行。そして変更が生じたときに相談する旨の一行で締める。この構成にしておくと、発注者が上から順に読むだけで、範囲と条件が頭に入る。

見積もりでよくある失敗

同じ失敗が繰り返し起きる。先に知っておけば避けられるものばかりだ。

相手の予算に金額を合わせにいく

「予算はこのくらいで」と言われると、その額に収まるように工数を削って計算し直したくなる。ここで削るべきは工数ではなく範囲だ。工数を削って同じ範囲を約束すると、実作業で必ず溢れる。溢れた分は自腹になる。

正しい対応は、範囲を落とした案を作り直すこと。「ご予算に合わせる場合、対象を2システムに絞り、説明会を含まない構成となります」と提示する。金額を下げるときは、必ず何かを外す。外さずに下げた見積もりは、受注した瞬間に負けが確定している。

苦手な作業を安く見積もる

慣れていない作業ほど時間がかかるのに、経験が浅いからという理由で安く出してしまう。実際は逆で、初めてやる工程には調べる時間と手戻りが乗る。得意な作業と同じ単価で計算すると、そこだけ大きく赤字になる。

初めての工程は、慣れた工程の1.5倍で見積もっておく。それで通らないなら、その案件は今回は見送るという判断もある。

打ち合わせの時間を数えていない

作業時間だけを積み上げ、打ち合わせを数えていない見積もりは非常に多い。定例が週一回で三カ月続けば、参加時間と準備と議事の整理でまとまった時間になる。しかも打ち合わせは分散して入るので、その前後の集中が切れる分も実質的な損失になる。

定例の頻度と期間を前提条件に書き、その分を報告と説明の費目に入れる。「定例ミーティングは週1回、1回あたり60分を想定しています」と書いておけば、増えたときに話せる。

修正の回数を書いていない

レビュー対応の費目を作っても、ラウンド数を書かなければ意味がない。何回でも受ける前提だと読まれてしまう。回数を書き、それを超えた場合の扱いも一行で添える。

有効期限がない

期限を書かない見積もりは、いつまでも有効なものとして相手の手元に残る。半年後に前提が変わった状態で発注されると、断りにくい。日付を一つ入れるだけで防げる。

見積もりを作るときの道具と型

毎回ゼロから作ると、書き漏らしが出る。型を持っておくと精度が安定する。

自分用のひな型を一つ持つ

表計算ソフトで、費目の行と前提条件の欄を固定したひな型を作る。案件ごとに数量と単価を入れ替えるだけにする。会計サービスの見積書機能を使う方法もあり、freeeやマネーフォワードのようなサービスなら、見積もりから請求書への転記が省ける。書式を作り込むより、そのまま請求に流れる形にしておくほうが、実務では効く。

前提条件のチェックリストを持つ

過去に痛い目を見た項目を、チェックリストとして蓄積する。アクセス権の期限、レビュー部署の数、説明会の回数、再確認の扱い、外部ツールの費用負担、情報の受け渡し方法。案件ごとに上から確認して、該当するものだけを前提条件に書く。

このリストは、一度作って終わりにしない。想定外の作業が発生するたびに一行足す。実際に赤字になった項目ほど、次からの見積もりを守ってくれる。

過去案件の実績時間を残す

見積もりの精度を上げる唯一の方法は、実際にかかった時間を記録することだ。費目ごとに、見積もった時間と実際にかかった時間を並べて残す。何回か貯まると、自分がどの費目を過小評価する癖があるかが見える。聞き取りを過小評価する人、成果物の作成を過小評価する人、レビュー対応を過小評価する人と、癖は人によって違う。

記録は凝った仕組みでなくてよい。案件名、費目、見積時間、実績時間の四列があれば足りる。この四列があるだけで、次の見積もりの根拠が体感ではなく数字になる。

生成AIを下書きに使うときの線引き

見積書の文言や前提条件の言い回しを整えるのに、生成AIを使うこと自体は問題ない。ただし、発注者から受け取った資料の中身をそのまま入力するのは避ける。とくにこの分野の案件では、相手の構成情報や課題そのものが機密にあたる。案件名や具体的な社名を伏せ、一般化した状態で相談するにとどめる。

独自データから見た見積もりの土台

見積もりの精度は、自分がどの種類の仕事をしているかを言語化できているかどうかに比例する。

AI関連の業務委託を分類すると、入口は大きく三つに分かれる。要件整理やルール作りが中心のAIコンサル・業務活用支援のお仕事、実装が中心のAIチャットボット・アプリ開発のお仕事、制作が中心の画像生成AI（Stable Diffusion等）のお仕事だ。見積もりの作り方は、この三つで大きく違う。実装系は成果物が動作で検収できるので範囲が書きやすい。コンサル系は成果物が判断の文書なので、レビュー対応と説明の場をどう見積もるかが勝負になる。自分がどちらの仕事をしているのかを取り違えると、見積もりの型ごと間違える。

職種としての仕事の中身を整理したい場合はソフトウェア作成者の年収・単価相場で求められる経験の幅を確認できる。非技術職の発注者に前提知識の水準を伝える材料としては、生成AIパスポートのような業務利用の基礎を体系立てて示せる資格が使いやすい。

在宅ワークとフリーランスの市場を20年運営してきた立場から見ると、見積もりが上手い人に共通しているのは、計算が速いことではなく「聞き取りが丁寧なこと」だ。前提条件の欄が具体的な人は、必ず初回のやり取りで細かく聞いている。聞いていないから前提が抽象的になり、抽象的だから守れない。見積もりの精度は、机の上ではなく打ち合わせの場で決まっている。

もうひとつ、運営者として見てきた限りでは、中間マージンが乗らない直接取引は見積もりの中身そのものを変える。仲介手数料が抜かれない手数料0%の形だと、同じ予算で発注者はより多くの工程を頼めるし、受け手は手取りが厚くなる。手取りに余裕があると、要件整理の工程を丁寧に置いたり、説明の場を一回多めに見込んだりといった、本来必要な工程を削らずに設計できる。削らずに済むから成果物の質が上がり、次の依頼につながる。逆に取り分が薄いと、真っ先に削られるのが要件整理と説明の場で、その二つを削った案件はほぼ確実に揉める。案件の取り方そのものを見直したい場合はAI機械学習 フリーランス案件の単価相場と成功のためのスキル・お金の全知識に全体像が整理されている。

よくある質問

Q. 見積書は一式で出してよいですか？

分けたほうがいい。調査とヒアリング、成果物の作成、レビュー対応、報告と説明、運用と継続の五つに分ける。一式で出すと金額全体を値切られて終わるが、費目が分かれていれば「今回は説明会を外して調整しましょう」といった交渉ができる。とくにレビュー対応を独立させておかないと、修正が増えたときに追加を求める根拠が示せない。

Q. 前提条件には何を書けばよいですか？

対象となるシステムやサービスの数、レビューに参加する部署の数、アクセス権の提供期限、既存資料の有無、成果物の想定ページ数や章立てを、数と日付で書く。抽象的な表現では根拠にならない。最後に、前提に変更が生じた場合は作業範囲と納期を再度相談する旨を一行添えると、変更管理の入口になる。項目は8つ程度までに絞る。

Q. あとから追加請求しにくい項目はどれですか？

レビュー参加者の増加、説明会や研修の実施、指摘を直したあとの再確認、機密情報の受け渡し手順の構築、アクセス権の取得待ち時間、外部ツールの費用。どれも見積書に書いていないと事後の請求が難しい。とくに説明の場は聞き手が変わるたびに資料の作り直しが発生するため、含む範囲を一行で明示しておく。

Q. 要件が固まっていない段階ではどう出せばよいですか？

幅を持たせた概算を出し、確定見積もりは要件整理の工程を経てから提出すると伝える。要件整理そのものを短期の有償工程として切り出し、その成果物として要件定義と確定見積もりを納品する形が実務的だ。固まっていない状態で一点の数字を出すと、あとから範囲が動いたときに交渉の根拠が何も残らない。

Q. 相見積もりで比較されるとき、何を整えるべきですか？

費目の名前を一般的な区分にして他社と並べて読める形にし、含む項目と含まない項目の両方を明示する。あわせて、進め方と成果物の目次案を一枚添えると、発注者が社内で説明しやすくなる。金額差が小さい案件では、この説明しやすさで決まることが多い。有効期限を書いておくことも忘れない。