「AIを使えば開発費は安くなりますか」。業務システムの受注開発をしていると、ここ一、二年でこの質問を受ける機会がはっきり増えました。結論から言えば、工程によって効き方がまったく違います。コードを書く部分は確かに速くなりました。一方で、速くならない部分、むしろAIを挟むことで手戻りが増える部分もあります。
この記事では、中小企業向けの業務システム開発という文脈に絞って、AI支援（生成AIやコーディングエージェントの利用）が効いた場面と効かなかった場面を整理します。発注側が見積書や提案書を読むときのチェックポイントとしても使える形にまとめました。
前提:ここで言う「AI支援」とは何を指すか
用語を揃えておきます。
- LLM（大規模言語モデル）:大量の文章を学習し、文脈に沿った文章やコードを生成するAIモデルのこと。ChatGPTやClaudeなどの対話型サービスの中核にあります。
- コーディングエージェント:開発者の指示を受けて、ソースコードの読み取り・編集・テスト実行などを半自動で進める開発支援ツール。単に文章を返すだけでなく、プロジェクトのファイルを実際に書き換える点が従来の対話型と異なります。
- RAG（検索拡張生成）:社内文書やデータベースを検索し、その結果をAIに読ませたうえで回答させる仕組み。学習させ直さずに自社情報を扱えるため、社内問い合わせ対応などでよく使われます。
本稿で「AI支援が効いた」と書くとき、それは開発会社側の生産性が上がったという意味と、システムの機能そのものにAIを組み込んだという意味の両方を含みます。この2つは混同されがちですが、費用の出方も失敗の仕方も別物です。
工程別に見た、AI支援の効き方
受注開発の流れを工程に分け、現場感覚での効き方を整理すると次のようになります。
| 工程 | AI支援の効き方 | 理由 |
|---|---|---|
| 業務ヒアリング・要件定義 | 限定的 | 暗黙知と社内政治が中心。情報がそもそも文書化されていない |
| 仕様書・画面設計のドラフト作成 | 効く | 叩き台を作る作業。人間が直す前提なら速い |
| 既存コードの読解・調査 | よく効く | 担当者が退職したシステムの構造把握などで威力を発揮 |
| 定型的な実装（CRUD画面、帳票出力） | よく効く | パターンが確立しており、学習データも豊富 |
| テストコード作成 | 効く | 後回しにされがちな工程を低コストで埋められる |
| 外部システム連携・レガシー接続 | 効きにくい | 相手側の仕様が非公開・独自であることが多い |
| 性能・セキュリティなどの非機能要件 | 効きにくい | 実測と判断が必要。生成物の妥当性を人が確認する手間が残る |
| 受け入れテスト・運用引き継ぎ | 限定的 | 業務が回るかどうかは現場でしか確かめられない |
見積書を読むときは、「どの工程の工数が、AI利用を理由に減っているのか」を確認してください。実装工数だけが減っていれば妥当な提案である可能性が高い一方、要件定義や受け入れテストの工数まで一律に圧縮されている見積りは、後で追加費用として跳ね返りやすい構造です。
効いた場面:情報が形になっているところ
AI支援がはっきり効くのは、入力が既に何らかの形式で存在している作業です。たとえば次のような場面です。
- 十数年前に外注したシステムの改修を頼まれたが、設計書が残っていない。ソースコードをAIに読ませて処理フローの説明を書き起こさせ、それを人間が検証して設計書を再構成する。
- Excelで運用してきた受注管理表をWeb化する際、既存シートの列構成と入力規則をもとに、データベースのテーブル定義案と入力画面の雛形を生成させる。
- 既存の業務マニュアルPDFを対象にRAGを構築し、新人からの定型的な問い合わせに一次回答させる。
いずれも共通するのは、正解に近いものが既に社内にあり、AIは形式変換をしているだけという点です。この種の作業は検証も比較的容易で、間違っていればすぐ分かります。
効かなかった場面:情報が人の頭の中にあるところ
逆に、期待したほど効かない、あるいは逆効果になりやすいのは次のような領域です。
1. 要件が文書化されていない業務
「この取引先だけ締め日が違う」「この承認は部長が不在のとき課長が代行するが、金額が一定を超えると社長決裁」といったルールは、たいてい誰の頭の中にもあるのに、どこにも書かれていません。AIはこれを推測で埋めてしまうことがあり、もっともらしい仕様書が出てくるぶん、誤りに気づきにくいという厄介さがあります。
2. 外部システムとの連携
会計ソフトや業界特化パッケージとの連携は、相手側の仕様書が限定公開であったり、実装が仕様どおりでなかったりします。学習データに含まれていない情報についてAIは当てずっぽうを返しやすく、結局は実機で試す以外にありません。
3. 非機能要件と技術的負債
生成されたコードは「動く」ことは多いのですが、「10年運用できる」かどうかは別問題です。設計の一貫性が崩れたコードが積み上がると、後の改修コストが膨らみます。これが技術的負債（短期的な実装の都合で、将来の修正コストが増える状態）です。AIで実装が速くなったぶん、設計レビューに時間を割り当て直すのが現実的な運用です。
4. 判断の責任が伴う処理
与信判断、人事評価、価格設定など、結果に責任が伴う判断をAIの出力にそのまま委ねる設計は推奨できません。経済産業省・総務省の「AI事業者ガイドライン」（2024年公表、以降改定あり）でも、人間による関与や説明可能性の確保が論点として扱われています。実装上は、AIの出力を提案にとどめ、確定操作は人が行う導線にしておくのが無難です。
法令・ガイドラインまわりで押さえる点
詳細は個別に確認が必要ですが、発注時に話題に出しておきたい項目を挙げます。
| 観点 | 確認すること |
|---|---|
| 個人情報 | 顧客データを外部AIサービスに送信するか。送信するなら「個人情報の保護に関する法律」上の整理（委託・第三者提供の扱い）がついているか |
| 学習への利用 | 利用するAIサービスの規約で、入力データが学習に使われない設定になっているか |
| 著作権 | 生成物の権利関係。文化庁の「AIと著作権に関する考え方について」（2024年）が論点整理の出発点になります |
| ガイドライン | 「AI事業者ガイドライン」（2024年公表）に沿った社内ルールがあるか |
| 契約 | AI生成コードの瑕疵・保守責任の分界点が契約書に書かれているか |
特に最後の項目は抜けやすいところです。AIが生成したコードに不具合があった場合の責任は、ツールの提供者ではなく、それを採用して納品した開発会社にあると考えるのが実務上の整理です。契約書にAI利用の記載がない場合でも、通常の請負契約と同じ責任が残るという前提で話を進めてください。
中小企業が小さく試すための進め方
いきなり基幹システムをAI前提で作り直すのは勧めません。次の順序で範囲を広げるのが安全です。
- 社内文書の検索・要約から始める。失敗しても業務が止まらず、効果が体感しやすい領域です。
- 既存システムの調査・ドキュメント化を開発会社に依頼する。属人化の解消という、AIと関係なく価値のある成果が残ります。
- 定型業務の部分自動化に進む。この段階で初めて、人の判断を挟む導線を設計します。
- そのうえで、本格的なシステム刷新を検討する。
また、社内にAI利用の最低限のルール（入力してよい情報の範囲、利用を許可するサービス、生成物のレビュー手順）を文書で持っておくと、開発会社との会話がスムーズになります。
まとめ
AI支援は、業務システム開発の「形式変換に近い作業」で確実に効き、「人の頭の中にある情報を引き出す作業」では効きません。したがって、AIを使うからという理由で全工程の費用が一律に下がることは期待しないほうがよく、実装工数が圧縮されたぶんを要件定義や設計レビューに振り向ける提案のほうが、結果的に総コストを抑えられる可能性があります。
発注側のチェックポイントは、(1) どの工程の工数が減っているか、(2) 外部AIサービスへのデータ送信の有無と規約の扱い、(3) 生成コードの品質保証と責任分界の契約記載、の3点です。この3つが説明できる相手なら、AI活用の実態が伴っていると判断してよいでしょう。
弊社では、既存システムの調査・ドキュメント化といった小さな範囲からのご相談も承っています。「どこから手を付けるべきか分からない」という段階でも、工程の切り分けからご一緒します。