約6分で読める記事です。ポイントをギュッとまとめましたので、ぜひ最後までどうぞ！
目次
AIコーディングツールで社内システムを内製する動きが広がり、「AIでSaaSが終わる」という言い方をSNSで見かけるようになりました。私はその、終わると言われている側で9期目のSaaSを運営しています。結論から書くと、作れるようになったのは事実だと思っています。ただ、作れることと、それを動かし続けられることの間には、まだ距離があります。
はじめに正直なところを書いておくと、「自社で作るので解約します」と言われた経験は、今のところほとんどありません。商談でそういう話題になることも、現状ではあまりないというのが実感です。
とはいえ、うちのお客様は以前からAPI（外部サービスとデータをやり取りする仕組み）を活用して自社の仕組みを組んでいることも多いので、内製で実現できる確率自体は高いと見ています。技術的に不可能だから頼まれている、という関係ではありません。
それでも、実際に手を出した場合には、メンテナンスのコストと原価のコストを把握した時点で辞めることになるのではないかと思っています。作り始めることと、来月も再来月も同じ精度で動かし続けることは、必要になる能力が違うからです。
この違いがいちばん分かりやすく出るのが、設計の段階です。
たとえばXの投稿を集めて集計したい、という要件があったとします。AIに「投稿を取得して集計したい」と伝えて、そのまま組んでもらうと、投稿データをまとめて取得してCSVに保存し、そこから集計するという形になることが多いはずです。動きます。要件も満たしています。
ただ、実際にはその前にやっておいたほうがいいことがあります。件数だけを先に把握することです。Xには件数を返すための仕組みが用意されていて、まず規模を確認してから本検索をかければ、必要のないデータを取りに行かずに済みます。しかもX APIの仕様では、投稿そのものを取得する量には月間の上限と従量の課金があり、件数を返すエンドポイントはその上限を消費しない扱いになっているとされています。つまり順番を1つ入れ替えるだけで、毎月の請求額が変わります。
これは知識の差というより、根本的な設計能力の差だと思っています。AIは知識の補完はしてくれます。聞けば count と search の違いも教えてくれるでしょう。でも「先に件数を見てから取りに行く」という段取りは、要件だけを伝えられた側からは出てきません。全体の設計には経験が必要で、そこが抜けたまま組み上がったものには、必ず穴が空きます。
先ほど書いた原価の話も、突き詰めるとここに行き着きます。内製が高くつくのはAPIの利用料が高いからというより、必要のないデータまで取りに行く設計になっているからです。同じツールを使っても、出来上がるものは同じになりません。
もうひとつ、内製の話で見落とされやすい点があります。精度の判定です。
作ったシステムが正しい数字を出しているかどうかを検証する場面でも、結局はAIに聞くことになりがちです。作った本人に判断する材料がなければ、そうするしかありません。ただ、その時点で構成には穴が空いていると考えたほうがいいと思っています。作る側と確かめる側が同じであれば、見落としはそのまま通過してしまいます。
セキュリティの領域では、この問題がすでに事例として報告されています。情報システム部門向けのメディアが公開している事例集では、非エンジニアがAIツールで作った社内システムに共通する落とし穴として、認証と認可の設計漏れが挙げられていました。ある企業では、営業部門が独自に構築した顧客データベースが、3カ月後に「認証なしで全顧客情報が読める状態」だったと判明したケースが紹介されています。原因として指摘されているのは、AIが提案したコードの安全性を、作った本人が判断できないという構造そのものでした。
怖いのは、動作確認では気づけないところです。画面は開くし、データも出る。表示された結果が合っているように見える。判定できる人が関わっていない限り、その状態は誰にも指摘されないまま続きます。セキュリティに限った話ではなく、集計の精度でも同じことが起きます。
こう書くと内製に反対しているように読めるかもしれませんが、そうではありません。うちでも作っているものはあります。
会計まわりと請求まわりは買っています。この領域は専門性が高く、制度の変更にも追随し続ける必要があるので、外に任せたほうがコストが見合うと判断しています。自分たちで設計できるかどうかとは別の話です。
一方で、営業ツールは自作しました。理由ははっきりしていて、自社サービスを拡張する形にすれば、営業が顧客データと照らし合わせながら使えるからです。既存のデータと接続することに価値があるものは、外から買ってきたものでは同じ形になりません。
線引きの基準として使っているのは、専門性が社外にあるか、それとも自社のデータの中にあるか、という点です。事故が起きたときの被害の大きさで分ける整理の仕方もありますが、私の場合はこちらのほうが判断しやすいと感じています。
AIコーディングツールの登場で、作れる範囲は確実に広がりました。実現性の面では、多くの業務システムが内製の射程に入っていると思います。ただ、そこで止まらずに動かし続けようとすると、設計の経験と、出来上がったものを判定できる目が要ります。AIが埋めてくれるのは知識であって、経験ではありません。作れるかどうかを考える前に、出来上がったものが正しいかを自分で判定できるかどうかを見ておいたほうがいいと思っています。
そのうえで、作るか買うかの線引きを先に決めておくと、迷いが減ります。専門性が社外にあるものは買い、自社のデータと接続することに価値があるものは作る。この2つを分けておけば、「作れるから作る」で進んで後から引き返す事態は避けられるはずです。終わると言われている側から見ていても、この線引きができている会社との付き合い方は、これまでとそれほど変わっていません。
