「AIを導入して、開発費を10％下げる」——こういう目標が、期初にトップダウンで降りてくる。

現場は困惑しながらAIコーディングツールを配り、数か月後に「思ったほど下がらなかった」という報告が上がる。ここ1〜2年、あちこちで繰り返されている光景です。

なぜこうなるのか。私たちは、原因はツールの性能でも現場の習熟度でもないと考えています。測っている対象が最初からずれているからです。

AIが下げたコストは、実は片方だけだった

ソフトウェアを作る作業は、雑に分ければ2つしかありません。

• 生成：仕様書を書く、設計する、コードを書く
• 検証：それが正しいか確かめる

この10年、この2つはだいたい同じ重さでした。ところが生成AIは、片方だけを劇的に安くしました。

コードを書く時間は10分の1になった。一方、そのコードが自社の製品で本当に正しく動くかを確かめる時間は、ほとんど1ミリも短くなっていません。レビューは相変わらず人間の目で行い、結合試験は相変わらず時間がかかる。

つまりAI導入とは、生成と検証のバランスを、意図的に片側へ倒す行為です。生成量を増やせば増やすほど、検証というボトルネックに負荷が集まる。ここを理解しないまま「たくさん作らせた＝効率化した」と数えると、話が合わなくなります。

現場が肌で感じている「AI使っても、なんか楽になった気がしない」という感覚は、正確です。楽になった工程と、負荷が増えた工程が、別の人の担当になっているだけのことが多い。

測るべき数字はひとつしかない

だから、AI導入の効果を測る式は、本来これだけです。

正味の効果 ＝ AIで減った作業時間 −（AIの出力を確かめ、直すのにかかった時間）

引き算です。ここを引かずに前半だけ報告すると、実態と乖離します。具体的に考えてみます。

ケースA：中核ロジックをAIに書かせた

人間なら3日かかる実装が、半日で出てきた。2.5日の削減。しかし、その製品固有の前提を満たしているかを読み解くのに、熟練者が2日かかった。さらに結合試験で2件の想定外が出て、修正に1日。

→ 正味 −0.5日。マイナスです。

ケースB：仕様書どうしの突き合わせをAIにやらせた

要求仕様と機能仕様の対応表を人力で作ると2日。AIなら10分。人間がチェックして「この3件は誤り」と直すのに1時間。

→ 正味 ＋1.8日。しかも、人間が見落としていた矛盾を2件発見。

同じ「AIを使った」でも、結果は真逆です。違いを生んでいるのはAIの賢さではありません。出てきたものが正しいかどうかを、どれくらい安く判定できるかです。

「検証の安さ」で仕事を並べ替える

この物差しで社内の作業を並べ替えると、優先順位がはっきりします。

AI導入は、この表の上から順に手を付けるのが定石です。多くの組織がいきなり最下段（プロダクトを作らせる）から始めて、検証の重さに潰されています。

特に見落とされがちなのが2段目、自然言語のまま扱える上流工程です。仕様書に対して「定義されていない条件を列挙して」「この2つの文書で矛盾している箇所を挙げて」「正常系・異常系・境界値に整理して」と頼む。返ってくるのは日本語なので、担当者はその場で読んで正誤を判断できます。間違っていても、読めば分かる。この「間違いが安く見つかる」という性質が、決定的に重要です。

しかもこの領域は、従来レビュアーの体力と根気に依存していた部分でもあります。300ページの仕様書を人間が最後まで同じ集中力で読むのは無理ですが、AIは最後まで同じ精度で読みます。人間が苦手で、検証が安い。ここが最初に取るべき場所です。

既存製品の改修と、ゼロからの開発は、別の話として扱う

もうひとつ、議論を混乱させているのが「AI活用」をひとくくりにすることです。既存製品のエンハンスと新規スクラッチでは、結論が逆になります。理由は単純で、参照できる”正解”が手元にあるかどうかです。

長く続いている製品には、要求仕様、機能仕様、設計書、ソースコード、テスト仕様、障害報告、変更履歴といった蓄積があります。これは資産です。AIにこれらを参照させれば、「この変更はどこに波及するか」「この記述は既存仕様と矛盾していないか」といった問いに、かなりの精度で答えられます。答え合わせの材料が社内にあるからです。

一方、新規スクラッチには、その材料がありません。AIが出したものを「何と照らして」正しいと言うのか。この問いに答えられないまま大きな単位を任せると、検証コストが青天井になります。

ここで難しいのは、新規開発のほうがAIの見栄えがいいことです。ゼロから動くものが出てくるので、デモとしては派手になる。一方、地味な仕様書のクロスチェックのほうが、実際の利益は大きい。社内で最初に成功事例として選ぶべきは、派手なほうではありません。

検証コストを最後まで押し上げるもの ― 暗黙知

工程を下流に降りていくほど、検証は難しくなります。その主因は、AIの能力不足ではありません。そもそも渡していない前提です。現場の判断は、仕様書に全部は書かれていません。

• この製品では、この条件のときだけ処理を変える
• この装置はこのタイミング制約を破ると現場で止まる
• この2つのデータは形式は同じだが、意味が違う
• このインターフェースには、10年前の経緯から来る制約がある
• この書き方は動くが、過去に障害を起こしたので使わない

こうしたことを、その組織のベテランは知っています。人間同士なら、口頭の但し書きや察しで補われてきた。AIには、それがありません。

そして厄介なのは、AIが「その前提を知りません」と止まってくれるとは限らないことです。与えられた範囲で、もっともらしいものを出します。一般論としては完璧に正しく、その製品では致命的に間違っている実装が、平然と出てくる。

これはレビューで最も見つけにくい種類の誤りです。文法もアーキテクチャも綺麗で、テストも通る。知っている人が見ないと分からない。だから熟練者の時間を食う——つまり検証コストが跳ね上がります。

AI導入で開発費が下がらない最大の理由は、ここにあります。生成は安くなったのに、暗黙知を持つ少数のベテランに検証負荷が集中し、そこが新しいボトルネックになる。人が増えていないのに、確認だけが増える。

だから、暗黙知の棚卸しが「仕事」になる

ここから導かれる結論は、私たちにとってかなり実務的です。人間が持っている暗黙知を掘り起こし、言語化し、AIが読める形にして置いておく。これがAI時代の技術組織における、新しい中核業務になります。

対象は正式な設計文書だけではありません。むしろ文書になっていないものが本命です。

• 過去の障害から生まれた「二度とやらない」ルール
• 顧客固有の要求と、その背景にある事情
• 社内の略語、隠語、独自用語
• 性能・セキュリティ上の前提条件
• 「普通こうする」で済まされてきた実装上の作法
• ベテランがレビューで毎回同じ指摘をしている、その指摘そのもの

最後のひとつは狙い目です。レビューで繰り返し出る指摘は、明文化されていない知識が漏れ出ている場所だからです。障害報告書も同じで、あれは「その組織でしか起きない失敗のカタログ」であり、暗黙知の鉱脈です。

実感を伴った例

大げさな話に聞こえるかもしれませんが、私たち自身、ずっと小さい規模で同じことをやっています。

自社では日次の定型業務をAIに任せていますが、その指示書には、業務手順だけでなく過去にハマった落とし穴が書き足されています。「この情報源はアクセスが弾かれるので使うな」「日本語をこの渡し方をすると文字化けするので、必ず別の方法で渡せ」といった具合です。

これらは最初は誰の頭の中にもなかった知識で、失敗して初めて分かったものです。書き残さなければ、AIは毎回同じ失敗をします。書いた瞬間から、二度と起きません。

AIは、教えられていないことを知りません。しかし、教えたことは忘れません。

この非対称性をどう使うかが、そのまま組織の差になります。そしてこの知識は、外から買えません。インターネット上の文献をどれだけ学習したモデルでも、その会社の製品で10年前に何が起きたかは知らないからです。AIの基礎性能が上がるほど、差がつくのは「自社にしかない知識をどれだけ綺麗に接続できたか」のほうへ移っていきます。

人間の仕事は減るのではなく、上流へ移る

こう書くと「結局人間が大変になるだけでは」と思われるかもしれませんが、変わるのは仕事の重心です。これまでは、頭の中の知識を使って自分で書いていました。これからは、頭の中の知識を、他者（AI）が実行できる精度まで明文化する工程が増えます。

このとき必要なのは、プロンプトの書き方のテクニックではありません。何が本質的な前提条件なのかを見抜き、曖昧さなく言葉にする能力です。

そしてこれは、優秀な設計者がずっとやってきたことそのものです。良い設計書を書ける人、新人への説明が上手い人、レビューで的確に急所を突く人。その能力の市場価値が、むしろ上がる。

「ドメイン知識の価値が下がる」のではなく、「ドメイン知識をAIが使える形に変換できる人の価値が上がる」。私たちはそう見ています。

削減率は、目標ではなく測定結果である

冒頭に戻ります。「AIを入れるので10％削減」という置き方の何が問題か。引き算をする前に、答えを決めてしまっていることです。現実には、工程ごとに結果はばらけます。

• この工程は40％短縮できた
• この工程はほぼ変わらなかった
• この工程は確認の手間が増えたので、AIを使わないことにした

3つ目の結論が出せる組織は健全です。「使わない」を選べない状態でAI導入を進めると、数字を作るために効果のない場所にまで適用され、静かに品質が削れていきます。順番としては、こうなるはずです。

1. 工程を分解する
2. 各工程の検証コストを見積もる（ここが肝）
3. 検証が安い工程から、小さく試す
4. 削減時間と確認時間の両方を実測する
5. 品質指標が悪化していないか確認する
6. 効いた工程だけ、範囲を広げる

削減率は、この結果として最後に出てくる数字です。前提条件として置くものではありません。

「失敗しないこと」ではなく「小さく失敗すること」を目標にする

新しい技術なので、外れは必ず出ます。避けられません。したがって目標は「失敗しない」ではなく、「失敗が小さいうちに分かる」であるべきです。

• 検証が安い工程から
• 限定された機能で
• 人間が全量レビューできる規模で
• 導入前後を数字で比べられる形で

この条件を満たしていれば、外れても失うのは数日です。当たれば、そこだけ広げればいい。

「AIならできるはず」という期待も、「AIは危ういから使わない」という拒絶も、どちらも判断を先送りしている点では同じです。必要なのは、どこまで任せ、どこで人が確かめ、何を教え込むのかを、開発プロセスとして設計することです。

まとめ

1. AIが安くしたのは生成だけで、検証は安くなっていない。この非対称性が全ての起点
2. 測るべきは「削減時間 − 確認・修正時間」。前半だけ数えない
3. 着手順は検証が安い工程から。上流の自然言語処理は費用対効果が高い
4. 既存製品の改修と新規スクラッチは分けて考える。差は“正解”が社内にあるか
5. 下流の検証コストを押し上げているのは暗黙知。AIは知らないことを、知らないと言わずに埋めてくる
6. だから暗黙知の棚卸しと構造化が、新しい中核業務になる
7. 削減率は目標ではなく測定結果

結局のところ、問われているのは「AIに何を書かせるか」ではありません。

AIが正しく仕事をするために、自分たちが何を知っていて、それをどこまで明確に渡せるか。

そしてこれは、優れた設計者が暗黙のうちにやってきた判断を、組織の資産として置き直す作業です。AI時代に価値が下がるどころか、最も価値の高い仕事のひとつになっていくと考えています。