AI

AI駆動開発の落とし穴は「設計」と「保守」――非エンジニア時代の役割分担

目次

「うちの若手が、Claude Codeとかいうやつで経費精算のアプリ作ってきたんですよ。これ、もう開発会社いらないんじゃないですか」

ある中小企業の社長が、打ち合わせの席でそう切り出される場面に、最近よく出会います。画面を見せてもらうと、確かに動いている。デザインも悪くない。入力した内容がスプレッドシートに溜まり、上長に通知も飛ぶ。一晩でここまで作ったというのは、数年前なら考えにくい話です。

非エンジニアでも「動くもの」を作れる時代になったのは、本当です。Claude CodeやCodexに代表されるAI駆動開発は、もはや一部の開発者だけのものではなくなりました。ただ、業務システムの引き取り相談を受ける現場で見えてくるのは、その半年後の景色です。作ること自体は民主化されました。一方で、設計と保守をAIと本人に任せきりにすると、半年から1年で行き詰まる現場が目立ちます。

既存記事 AIで内製は中小企業に本当に向くのか は「内製化全体の線引き」を扱いました。ここはその先の話で、「作る・設計する・保守する」をどう分担するかに絞ります。半年後に何が起きるかの詳しい話は既存記事側を、本記事は3工程の分け方を、と読み分けてください。

非エンジニアがAI駆動開発で「業務システムを作る」は、もう特別な話ではない

非エンジニアでも業務システムを形にできるのか、という問いには、2026年時点で「小規模なものは作れる」と答えるのが現実的です。Claude Codeをはじめとするツールが、コードを書く部分の負担を実際に下げているからです。

バイブコーディングという作り方の浸透

バイブコーディングとは、自然言語のプロンプトでAIに指示を出し、生成されたコードをほぼそのまま受け入れていく作り方を指します。コードを1行ずつ精読するのではなく、動かして確かめながら進める。エンジニアの間ではここ1〜2年で日常になり、非エンジニアの間にもじわじわ広がっています。

相談を受ける中小企業の現場でも、若手社員が業務の合間に社内ツールを組み立ててくる、という話が以前より明らかに増えました。経費精算、出退勤の集計、簡単な在庫の見える化。これまでなら外注するか、Excelの限界の中でしのいでいた領域です。

「作る」のハードルが下がったのは事実

ハードルが下がったのは、コードを書く部分です。要件を日本語で書けば、AIが画面と裏側の処理を一通り組み立ててくれる。動くかどうかを確かめながら修正する作業も、AIとの対話で進められます。

ただし、ここで一度立ち止まる必要があります。「動くものができた」と「業務で使い続けられる」の間には、これまでと変わらない距離があります。その距離の中身が、次に整理する「作る・設計する・保守する」の3工程の違いです。

「作る」「設計する」「保守する」は別々のスキル

業務システムを社内に持つということは、3つの異なるスキルを揃えることです。AI駆動開発で楽になったのは、このうち「作る」の部分だけです。設計と保守は、必要な力の中身が違います。

役割やることAIにできる範囲人に必要なもの
作る画面・処理・データの登録機能を組み立てる自然言語の指示でかなり書ける業務を言語化する力
設計するデータの持ち方、権限、業務との接続、将来の拡張余地を決める個別の判断は出せるが、業務全体を踏まえた選定は不得手業務知識と、プログラミング全般の知識
保守する不具合の特定と修正、外部サービスの仕様変更追従、セキュリティ更新既知のエラーの調査は速い。本番に手を入れる責任は持てないコードの読み解きと、止まった時に動ける体制

3つのうち1つでも欠けると、業務システムは「持っているけれど使い続けられない状態」に向かいます。AI駆動開発のニュースで語られているのは、ほぼ「作る」の話だけです。残りの2つは、語られていないだけで何も変わっていません。

「作る」と「設計する」を非エンジニアがやることの落とし穴

非エンジニアがAIで作る時、設計と作るを分けずに進めることがほとんどです。これは初動の速さの源でもあり、同時にあとから一番効いてくる落とし穴でもあります。設計を意識しないまま積み上げたコードは、後から触る人にとって地図のない街と変わりません。

AIに任せた「設計」が半年後に直せないコードを生む理由

AIが書いたコードを、誰も設計の観点で確認せずに本番に入れると、半年後に直せないコードが残ります。理由は、AIが個別の指示には答える一方、システム全体としての筋を通す責任は持たないからです。

同じ機能が複数の場所に書かれる

非エンジニアがAIと対話しながら追加機能を入れていくと、同じような処理が画面ごとに少しずつ違う形で書かれていきがちです。最初に作った経費精算と、後から足した出張申請で、金額のチェックロジックが微妙に違う。動いてはいるが、片方の不具合を直しても、もう片方には反映されない、ということが普通に起きます。

これは「リファクタリング」と呼ばれる整理整頓の概念をAIに伝えずに進めていることが原因です。AIは聞かれたことに答えるのが得意ですが、聞かれていない既存コードとの整合まで毎回見にいくとは限りません。

権限とデータの境界が曖昧になる

業務システムでもう1つ怖いのが、誰がどのデータを見られるか、という権限の設計です。AIに「経費を申請する画面を作って」と頼んだとき、AIは黙って「ログインしたユーザーが自分の経費を見られる」状態を作ります。ただ、業務上は経理部だけが全社の経費を見られる必要がある、上長は自分の部下のものだけ見える必要がある、といった条件が必ず後から出てきます。

設計の段階でこれを織り込まずに作ったコードに、後から権限を足すのは、本質的に作り直しに近い作業になります。半年後に「全員に全部見えていた」と気付き、その時点でデータが溜まっている、というのが一番悪い結末です。

セキュリティの観点もそのまま残る

AI駆動開発で生成されたコードに、SQLインジェクションやクロスサイトスクリプティングといった古典的な脆弱性が紛れ込む例は、セキュリティベンダーからも繰り返し報告されています。トレンドマイクロは2026年4月の記事で、バイブコーディングの本質的なリスクは「AIが安全性の低いコードを生成すること自体ではなく、利用者がコードを十分に検証せずに本番に入れてしまうこと」だと指摘しています。 また、機密情報をそのままコード内に含むハードコーディングが行われるとソースコードの流出=企業の存続すら脅かす状況となります。

業務システムは、社内とはいえ顧客の個人情報や取引データに触れます。設計のレビューを素通りすると、こうした脆弱性をそのまま社内に持ち込み、後から気付くことになります。

出典: トレンドマイクロ「バイブコーディングの本当のリスク」（2026年4月公開）

AIに任せた「保守」が回らない理由――書いた本人も中身を語れない

AIに保守を任せられるか、と聞かれれば、現時点では「個別の調査は速いが、本番に手を入れる責任は人が持つしかない」というのが答えです。そして、AIに作ってもらったコードは、書いた本人すら中身を説明できないことが多い。ここが保守の本当の壁です。

「自分で作った」けれど「自分でも読めない」状態

AI駆動開発の現場でよく聞くのが、「3か月前にAIと一緒に作ったけれど、いま見ると何が書いてあるか分からない」という話です。これは恥ずかしいことではなく、構造的に起きます。コードを1行ずつ理解しながら書いたのではなく、動くかどうかで進めたからです。

業務システムは、必ず不具合が出ます。取引先のシステム変更、ブラウザの仕様更新、消費税率の見直し、人事異動。きっかけはいくらでもあります。そのとき、書いた本人が中身を語れない状態だと、AIに「直して」と頼んでも、AIは前提が分からないまま新しいコードを足し、傷口が広がります。

「保守する」は止まった時に動ける体制のこと

引き取りの現場では、「ふだんは動いているが、月末だけ落ちる」「特定の取引先からのデータだけ取り込めない」といった、本人も再現できない不具合に出会います。こうした不具合は、AIに状況を説明する前に、まず本番のログを見て原因を切り分ける作業が必要です。ここはコードを書く力よりも、本番環境で慌てずに動ける体制の問題です。

確定実績で言えば、塗装業30名規模の引き取り案件は、まさに「担当者が退職して誰も触れない状態のシステムを引き取って保守体制を構築した」案件でした。これはAI由来ではない事例ですが、原因は同じ構造に行き着きます。AI駆動開発で作ったシステムも、放っておけば同じ道をたどります。退職を待たずに、最初から「保守は誰がやるか」を設計の中に組み込む必要があります。

役割分担はどう決めると無理がないか――「作るは社内、設計レビューと保守はプロ」のかたち

役割分担の現実解は、「作るは社内、設計レビューと保守はプロ」のかたちが、中小企業にとって一番無理がありません。社内で作る速さを活かしつつ、設計と保守の責任を分散させる組み方です。

たとえばこんなケース：見積もり補助ツールを社内で作りたいとき

たとえば、現場の若手が見積もり補助ツールをAIで作りたい、と相談された中小企業を想定してみます。ここで一気通貫で社内に任せるのではなく、次のように分けます。

まず、要件と画面のイメージは社内で詰める。実際に使う現場担当が、業務に合うかどうかを一番分かっているからです。次に、データの持ち方と権限の設計、外部サービス（会計ソフトや顧客管理ツール）との接続方法について、開発会社にレビューを依頼する。ここは半日から1日のスポットで十分です。コードを書くのは社内とAIで進める。本番投入の前に、もう一度開発会社にコードのレビューと脆弱性のチェックを受ける。そして公開後の保守は、月額固定ではなく実働ベースで開発会社に持ってもらう。

役割分担チェック表

社内とプロでどちらが担うかを、最初に明文化しておくと迷いがなくなります。

項目社内（AI＋本人）プロ（開発会社）
業務の要件整理主担当助言のみ
画面・操作感の設計主担当助言のみ
データ構造・権限の設計案を出すレビューと最終判断
コードの実装主担当（AIと一緒に）必要に応じてレビュー
本番投入前のセキュリティチェック自己点検主担当
公開後の障害対応一次切り分け復旧の責任
法令・税制変更への追従検知改修

この分担なら、社内のスピード感を保ちつつ、設計と保守の責任を開発会社が持つ形になります。月額固定の保守契約だと「使わない月の費用」が重く、社内主体の開発と相性が悪いのですが、実働ベースの保守なら使った月だけの請求になるので、組み合わせやすくなります。設計レビューやスポットでのご相談を入口に、設計と保守を切り離して任せる組み方が、実際の現場でも見られます。

経営者は何を整えておくべきか――AI駆動開発時代の3つの構え

AI駆動開発を社内に取り込むなら、経営者の立場で3つだけ整えておくと、半年後の景色が変わります。技術の細かい話ではなく、判断の枠組みの話です。

1. 「作る」と「設計する」と「保守する」を分けて見る

社員が「AIで作ってきました」と言ってきたとき、「動いた」だけで判断しないことです。データの持ち方と権限はどうなっているか、書いた本人が3か月後にも読めるか、不具合が出たときに誰が直すか。この3つを確認する習慣を、最初の1本目から付けておきます。

2. 本番に入れる前のレビューを、外部に1度通す

社内で完結させたい気持ちは分かりますが、業務システムは顧客や取引先のデータに触れる以上、社内の目だけで本番に入れるのは無理があります。半日から1日のスポットレビューで、設計とセキュリティの観点を外部に一度通す。これだけで、半年後の地雷の多くは防げます。

3. 保守の枠を、月額固定にこだわらない

社内で作るスタイルと、月額固定の保守契約は、相性が良くありません。使った月だけ請求する実働ベースの保守を選択肢に入れておくと、社内主導でも開発会社の手を借りやすくなります。経済産業省の「中堅・中小企業等向けDX推進の手引き2025」でも、内製と外部活用の組み合わせ方が一つの論点として整理されています。

出典: 経済産業省「中堅・中小企業等向けDX推進の手引き2025」（2025年3月公開）

まとめ：作るは民主化された。設計と保守は分担で守る

非エンジニアがAI駆動開発で業務システムを作れるようになったのは、間違いなく事実です。経費精算でも、見積もり補助でも、在庫の見える化でも、社内で組み立てられるところまで来ました。

ただし、そのまま社内とAIだけで設計と保守まで抱え込むと、引き取り相談を受ける範囲では、半年後に直せないコードと、誰も中身を語れない本番環境が残るケースが目立ちます。

「作る」を社内のスピードで進めつつ、「設計のレビュー」と「保守」を外部のプロに分担する。この組み方が、中小企業にとって今いちばん現実的な落とし所です。月額固定の保守契約に縛られず、必要な月だけ動く形なら、社内主導の開発とも無理なく組み合わせられます。社内に作る文化が芽生えたタイミングこそ、設計と保守の置き場所を一緒に決めておく好機です。

システムレスキュー

他社が断った業務システムも含め、保守と継承を専門に扱います。月額固定ではなく、実働ベースの料金で必要な月だけ稼働します。

/service/system-rescue/

よくある質問

Claude CodeやCodexで作ったコードでも、引き取って保守できますか

引き取れます。AI駆動開発で生成されたコードは、人が書いたコードと構造が異なる部分もありますが、読めないわけではありません。AIが書いたコードも含めて、書いた本人が中身を語れなくなった業務システムの引き取りを行っています。状態に応じて、必要な部分だけ整理する段階保守の進め方も選べます。

関連記事