AIで業務システムをどこまで内製できるか

最初の画面は、驚くほど早く動きました。ところが業務システムへ移そうとした瞬間、決めていないことが次々に現れます。AIは開発を短くしたはずなのに、なぜ完成しなかったのでしょうか。

まず押さえること

AIは、調査の整理、実装案、コード、テスト、文書の作成を大きく助けます。一方で、何を業務上の事実とするか、どの例外を許すか、実際に仕事を置き換えられるかを決める責任は残ります。内製の範囲は、作れる量ではなく、その判断と運用を自社で持てる範囲から決めます。

画面は動いた。完成したように見えた

業務システムの試作をAIへ頼むと、以前なら数日かけた画面や処理が、その日のうちに形になることがあります。項目を入力できる。検索できる。保存もできる。ここまでを見ると、開発の大半が終わったように感じます。

実際の仕事へつなごうとすると、景色が変わりました。誰がその項目を確定するのか。同じ会社名が二つあったら統合してよいのか。過去データの欠損をどう扱うのか。失敗した処理はどこから戻すのか。画面の外にあった判断が、一斉に表へ出てきます。

作るのが遅いことが問題だと思っていました。しかし、速く作れたことで見えたのは、まだ業務を定義し切れていないという別の問題でした。

AIが縮めたのは、工程そのものではなく往復時間だった

一般的な開発には、課題の発見、要件、設計、実装、検証、公開、データ移行、利用者の受入、運用があります。NISTの安全なソフトウェア開発の枠組みも、セキュリティを開発ライフサイクルへ組み込む考え方を示しており、コード生成が速くなれば他の工程が消えるとはしていません。

AIが強いのは、会話を仕様案へ整理する、複数案を出す、コードとテストのたたき台を作る、差分を調べる、といった往復です。試して違えば戻るまでが短い。これは大きな変化です。ただし、戻る先となる業務目的や正しい情報源が曖昧なら、速い往復は迷走も速くします。

速くなりやすい仕事と、残る判断

場面	AIが助けること	人が引き受けること
要件を考える	会話の整理、抜けや例外の候補	誰の何の仕事を終わらせるか
設計する	構成案、データ案、比較材料	会社・権限・データの意味を決める
作る	画面、コード、テスト、文書	既存契約への影響を判断する
確かめる	自動検証、差分、証拠の整理	今回の版・本番・実利用で受け入れる
使い続ける	調査、修正案、運用補助	優先順位、障害対応、引継ぎを持つ

表は横にスクロールできます。

営業リストの取込で、コードの外側が主役になった

具体例が、営業リストのCSV取込です。電話番号の空白や記号をそろえる処理は、規則として実装できます。既存データとの重複候補も機械で絞れます。ところが、表記が似ている二件を同じ相手だと確定するところまで自動化すると、誤って別の情報を混ぜる危険があります。

そこで、原本を残す、形式を整える、候補を出す、自動では決められない行だけ人へ回す、という状態を分けました。問い合わせ基盤でも、受付の保存とメール通知、ブラウザへの応答を別の事実として扱いました。必要だったのは、さらにコードを書くことより、どこからが業務上の確定なのかを決めることでした。

「内製か外注か」は、会社単位では決めなくてよい

標準的な顧客管理で足りるなら、SaaSへ業務を合わせる方が早く、保守責任も小さくできます。定型的な入力・承認・集計が中心ならローコードが合うことがあります。専門的なセキュリティや短期間の構築体制が必要なら、外注する意味があります。

AIを使う内製が効くのは、独自の業務判断があり、使いながら継続的に変える必要があり、その変更を確かめる人を社内に置ける場合です。画面だけ内製し、認証や決済は既存サービスを使う。設計と受入は社内で持ち、専門領域だけ外へ頼む。工程ごとに分けた方が現実的です。

別の選択がよいとき

更新頻度が低い、標準機能へ合わせられる、公開後の保守担当を置けない。この条件なら、AIで作れることを理由に自作しない方が安全です。内製は制作費を消す方法ではなく、判断と保守の責任を社内へ移す選択です。

最初の一件を、公開後まで追えるか

内製の可否を試すなら、最初から全社基幹を作る必要はありません。出口が明確で、影響を限定でき、失敗時に元の方法へ戻せる仕事を一つ選びます。そして試作ではなく、実データ、権限、異常時、公開、利用、修正まで一周させます。

そこで初めて、自社に足りないのがコードを書く力なのか、業務を説明する力なのか、証拠を読んで受け入れる力なのかが見えます。AI内製の上限は、AIの性能表より、その一周を自社で終えられる範囲に現れます。

業務システムは、画面を作る前から始まっている

ここでいう内製は、社員がすべての技術を抱え込むことではありません。市販のSaaSをつなぐ、ローコードの画面を作る、既製の認証やクラウドを使う、必要な部分だけ外部の専門家へ頼む。その組み合わせを自社で選び、変更できる状態を指します。以前なら、Excelで粘るか、既製品を入れるか、開発会社へ発注するか、という三択になりがちでした。AIによって実装の入口が広がったため、今はその間に選択肢が増えています。

ただし、選択肢が増えたことは、簡単になったことと同じではありません。たとえば営業リストをCSVで取り込むだけでも、列名が毎回違う、電話番号の表記が揺れる、同じ会社かもしれない行がある、担当者が確認した後に何をするかが決まっていない、といった話が出ます。コードを生成する前に、誰が何を事実として確定するかを決めなければ、速く作った画面ほど後で直しにくくなります。

ピース・ビズグループの業務基盤でも、取込、正規化、重複候補、確認待ちを別の状態として扱う考え方を採りました。これは、AIが判断を代わりにしてくれるからではありません。形式の統一と、二つのレコードを同一と決める責任は、同じ種類の仕事ではなかったからです。

AIを使うほど、最初に小さく終わらせる価値が上がる

AIを使うと、最初から大きな業務全体を作れそうに見えます。しかし最初の対象は、入力から確認、次の行動、例外までを一つだけ通せる小さな仕事に絞る方が安全です。たとえば、一覧を表示するだけではなく、あるCSVを受け取り、確認が必要な行を出し、その人が判断した結果を次の作業へ渡せるところまでを一周させます。そこで初めて、作ったものが業務へ入るときの不足が見えます。

内製が向くのは、仕事の意味や例外を自社がよく知っていて、変更が繰り返し起こり、受入や保守を担う人を置ける場合です。反対に、会計、勤怠、電子契約のように制度対応や標準機能が価値の中心にある仕事は、既製SaaSへ寄せた方が合理的なことが多いでしょう。外部の専門家が必要なセキュリティ、法令、可用性の要求があるなら、AIで最初の実装が速くても、その責任まで内製できるわけではありません。

AIが圧縮するのは主として作る時間です。何を作るべきか、データをどう扱うか、正しいとどう確かめるか、使われ続けるかという責任は残ります。だから内製の可否は、生成できるコードの量ではなく、その一周を自社で引き受けられるかで決めます。

Guide