AI を使うと、これまで時間のかかっていた作業が驚くほど早く終わることがあります。例えば、WordPress のコアとプラグインの更新です。この作業は、更新ボタンを押すだけでは終わりません。まず万一に備えてファイルとデータベースのバックアップを取り、更新によってテーマやカスタマイズが壊れないかを確かめる。ステージング環境を用意し、更新前後を見比べ、干渉しそうな箇所を一つずつ追いかける。この確認だけで数時間から数日かかることもあります。
ここに AI を使うと、話が変わります。更新前後でコアやプラグインのコードがどう変わったかを差分で洗い出し、その変更点がサイト側のテーマやカスタマイズと衝突しないかを突き合わせる。この読み解きを AI にやらせれば、数分で「壊れる箇所はない」ところまで確かめられます。バックアップは相変わらず同じ時間がかかりますが、確認の工程だけが一気に縮みます。
これは一例にすぎません。原因の調査、影響範囲の洗い出し、大量の情報の突き合わせ。手を動かす時間より、調べて確かめる時間のほうが長い作業なら、どの分野でも同じことが起きているはずです。
さて、この作業をいくらで見積もればいいのでしょうか。
見積書から消えるのは、価格ではなく「何をやったか」
AI と見積もりの話題では、「作業が速く終わると工数ベースでは安くなってしまう」という価格の問題がよく語られます。しかし実際には、その手前で別のことが起きます。
数分で終わる作業は、独立した項目として書きにくくなるのです。
見積書の一行は、それなりの重みを持っています。何時間もかかる工程だから一行を割く、という感覚が書き手の側にある。数分で終わると分かっている作業にわざわざ一行を立てて金額を書くのは、大げさに感じてしまうのです。だから「復旧作業一式」「保守対応」といった大きな項目の中に含めてしまう。悪意はなく、むしろ良心からそうします。
しかし読む側には、その事情は見えません。項目にないものは、実施されるのかどうか分からない。分からなければ、確認するしかありません。
見積書には、価格表としての機能のほかに、何をやるか・何をやったかを伝える機能があります。AI 時代に先に揺らぐのは、価格よりもこちらの機能なのだと思います。
買われているものは、時間ではない
価格の話に戻ります。「すぐできたなら安くなるはずだ」という理屈は、買われているものが作業時間だと定義したときにだけ成立します。実際に買われているものを分解すると、次のようになります。
- 結果：サイトが安全に動き続けている状態
- 速さ：脆弱性が塞がるまでの時間の短さ
- 保証：「壊れていない」と専門家が判断して引き受けること
- 責任：万一不具合が出たときに対応する窓口があること
このうち、作業時間に比例するものは一つもありません。工数ベースの見積もりは、これらを測るための便利な代理指標だっただけです。AI によって作業時間と価値の相関が壊れた今、捨てるべきは価値の側ではなく、代理指標の側です。
とくにセキュリティ対応では、速さそのものが価値になります。脆弱性が放置される時間が短いほど、攻撃を受ける可能性は下がる。早く終わったことは、値引きの理由ではなく、むしろ成果です。
この構造自体は新しいものではありません。弁護士の30分の相談料は時間相応の価格ではありませんし、修理工が「どこを叩くか知っていること」に対価を求める話も昔からあります。買われているのは判断と責任です。
エンジニアの仕事も、その形に近づいています。AI の出力が正しいかを判断できるのは、AI なしでも同じ作業ができる人だけです。「壊れる箇所はない」という AI の答えを見て、それを鵜呑みにせず、どこを追加で確かめるべきかが分かる。そのうえで最終的に「問題ない」と引き受ける。数分で終わったレビューの価値は、この最後の一言の重さで決まります。
「手作業なら」という換算が、橋渡しになる
とはいえ、発注する側の事情もあります。見積書を受け取った担当者は、それを持って社内の承認を得なければなりません。検収や稟議が工数ベースの世界観で回っている以上、手作業換算の項目と金額が並んでいなければ、担当者は上や先方に説明ができない。「手作業で行った場合の見積もりとして出してほしい」という要望が出るのは、そういう事情からで、これも合理的です。
これは値付けの理屈から見ても、筋が通っています。手作業であれば必要だったはずの項目と工数に値付けをして、AI で速く終えた差分は、AI を使いこなす側の利益として残す。速さの成果は発注する側に、効率化の利益は投資した側に配分される形です。逆に、AI で短縮した時間をそのまま工数表に反映して値引きすると、AI を使いこなせるようになるまでに投じた学習や環境整備の利益を、すべて相手へ移転することになります。続けるほど苦しくなる構造です。
時間は書かない。項目は書く
ここまでを一行にすると、こうなります。時間は書かないが、項目は書く。
価格は「脆弱性対応一式」のような成果ベースに寄せていくとしても、実施内容の列挙は、むしろ手作業の時代より細かく書くべきです。冒頭の更新作業であれば、こうなります。
- ファイル・データベースのバックアップ取得
- 更新差分の影響調査（テーマ・カスタマイズとの衝突有無の確認）
- WordPress コア・プラグインの更新
- 更新後の表示・機能の動作確認
- 更新起因の不具合が出た場合の復旧対応
どれも所要時間は書きません。数分で終わる項目も、数時間かかる項目も、同じ一行として並びます。AI で溶かしてよいのは作業だけで、項目まで溶かしてはいけません。
注目してほしいのは最後の一行です。これがなければ、売っているのは作業です。更新して、確認して、終わり。あとから不具合が見つかっても、範囲外の話になります。この一行があると、売っているものが変わります。「壊れなかったこと」を引き受けることになるからです。万一壊れたら、自分の責任で直す。作業ではなく、結果を保証している。
AI の出した「問題ない」を、最終的に自分の言葉として引き受ける。
その覚悟を見積書の上で形にすると、この一行になります。数分で終わった作業に値段がつくとしたら、根拠はここにしかありません。
では、なぜ項目を書くのか
ここで正直に認めておくべきことがあります。項目を細かく並べたところで、技術に詳しくない相手がその価格を適正だと判断できるわけではない、ということです。
「更新差分の影響調査」と書かれていても、それが1万円の仕事なのか10万円の仕事なのかは、専門外の人には分かりません。項目が増えれば価格の根拠が伝わる、というのは書き手側の思い込みです。
では発注する側は、何を見て価格を判断しているのか。実際には内訳ではなく、相見積もりで他社と比べるか、外部で見聞きした相場と照らすか、これまでの仕事の積み重ねから「この人がこの額を出すなら妥当だろう」と信じるか、そのいずれかです。価格の妥当性は、見積書の中ではなく外側で決まっています。
だとすれば、項目を書く目的は価格の正当化ではありません。二つあります。ひとつは、担当者が社内や先方に「これだけのことをしてもらう」と説明するための材料になること。もうひとつは、作業のあとで「何をしてもらったか」を確認できる記録になることです。
この区別は大事だと思っています。項目は、価格を納得させる道具ではなく、仕事の輪郭を示す道具です。輪郭がはっきりしていれば、何が含まれ、何が含まれないかで揉めることが減る。価格そのものへの信頼は、その積み重ねの先に、ゆっくりと生まれてくるものなのでしょう。
発注する側が求めているのは、早く安全に使える状態に戻ることです。速さも安全も、値引きの理由ではなく価値そのものだと私は考えています。ただし、その価値は黙っていても伝わりません。何をして、どこまで引き受けるのか。それを書いて初めて、相手は仕事の輪郭を掴めます。
AI が作業を見えなくしていく時代だからこそ、何をしたかを見えるように書く。そして、その結果を引き受けると書く。見積もりの技術は、これから作文の技術になっていくのだと思います。