「外部のシステム開発会社に依頼しなくても、AIで業務システムを作れるのでは？」
生成AIの進化によって、企業が自社でシステムを開発する「内製化」の選択肢が広がっています。
以前は専門のエンジニアが必要だったプログラムの作成も、AIが支援してくれるようになりました。
そのため、社内の担当者がAIを使って、Excelの集計ツールや業務アプリを作成するケースも考えられます。
しかし、ここで注意したいことがあります。
AIでシステムを作れることと、企業として安全に使い続けられることは別問題です。
例えば、業務で使うシステムには、データの保護、不具合への対応、保守、担当者の引き継ぎなど、開発した後にも多くの仕事があります。
今回は、DX担当ちゃま男と先輩の会話を交えながら、AIによるシステム内製化で企業が見落としやすい5つのリスクと、中小企業が取るべき対策を解説します！
AIによる業務システムの内製化とは？
DX担当 ちゃま男先輩！最近はAIがプログラムを作ってくれるから、システム開発を全部社内でできるようになるんじゃないですか？
ちゃま男の先輩以前より、社内で開発できることは増えているよ。
ただし、プログラムを作成することと、安全に運用できるシステムを構築することは別なんだ。
内製化とは、社内でシステムを作ること
システムの内製化とは、外部の開発会社へ全面的に委託するのではなく、社内の人材が中心となってシステムを開発・改善することです。
例えば、次のようなシステムが考えられます。
- Excelデータの自動集計ツール
- 在庫管理アプリ
- 社内の問い合わせ管理システム
- 設備点検の管理アプリ
- 見積書の作成支援ツール
最近はAIコーディングツールだけでなく、kintoneのようなノーコードサービスを組み合わせることで、業務システムを構築する選択肢も増えています。
ノーコードとは、プログラムを大量に書かなくても、画面上の操作などでアプリを構築できる仕組みのことです。
ただし、ノーコードを使っていても、業務要件や権限管理、運用ルールの確認は必要です。
リスク① セキュリティやアクセス権限に問題が残る
最初に注意したいのが、情報セキュリティです。
例えば、AIを使って顧客管理システムを作成したとします。
画面では顧客情報を正しく表示できていても、本来閲覧できない社員まで情報を見られる状態になっているかもしれません。
また、AIを使った開発では、ソースコードや社内データを外部のAIサービスへ送信する場合があります。
そのため、情報の取り扱いにも注意が必要です。
具体的に確認したいこと
- 誰がデータを閲覧できるのか
- 誰がデータを登録・変更・削除できるのか
- 管理者アカウントの権限は適切か
- 顧客情報や個人情報を安全に扱えるか
- AIサービスへ送信する情報は適切か
AIが作ったコードでもレビューが必要
GitHubは、AIが生成したコードについて、人間によるレビューやテストが重要であると公式ドキュメントで説明しています。
AIが生成したプログラムには、不正確な処理やセキュリティ上の問題が含まれる可能性があるためです。
参考：GitHub公式｜AIによって生成されたコードを確認する
リスク② データの整合性が保たれない
2つ目は、データの整合性です。
整合性とは、複数の情報が矛盾せず、正しい状態に保たれていることを意味します。
例えば、在庫管理システムで同じ原材料を2人の担当者が同時に出庫した場合を考えてみましょう。
在庫が10個ある状態で、2人がそれぞれ8個ずつ出庫しようとした場合です。
適切な仕組みがなければ、双方が「在庫は10個ある」と判断し、合計16個の出庫処理を受け付けてしまう可能性があります。
これは、画面の見た目だけではわからない問題です。
異常な操作への対応も確認する
例えば、次のようなケースです。
- 同じデータを二重に登録する
- 通信が途中で切れる
- 数値にマイナスの値を入力する
- 複数の担当者が同じデータを変更する
- 登録処理の途中でエラーが発生する
このような状態でも、データが正しく保たれるように設計・検証する必要があります。
DX担当 ちゃま男：
普段の操作で問題なく動いていても、安心できないんですね！
ちゃま男の先輩：
そうなんだ。
特に在庫や金額などを管理するシステムでは、普段と違う操作が行われた場合でも、データが正しく保たれることが重要なんだよ。
リスク③ システムを作った担当者しか管理できない
3つ目は、属人化です。
属人化とは、特定の担当者しか業務や仕組みを理解していない状態のことです。
例えば、ある社員がAIを使って業務ツールを作成したとします。
最初は便利に使えていても、担当者が異動・退職した後に不具合が発生したらどうなるでしょうか。
プログラムの保存場所や管理方法、外部サービスとの接続方法がわからなければ、修正が難しくなる可能性があります。
AIで作ったシステムにも管理資料が必要
最低限、次のような情報を残しておきましょう。
- システムの目的と利用部署
- 管理責任者
- プログラムの保存場所
- 利用している外部サービス
- データの保存先
- 設定変更の方法
- バックアップ・復旧手順
また、プログラムを変更した場合には、変更履歴を残すことも重要です。
Gitなどのバージョン管理ツールを利用すると、以前の状態を確認しやすくなります。
バージョン管理とは、ファイルの変更履歴を保存し、必要に応じて過去の状態を確認できる仕組みです。
リスク④ 開発費用は安くても、保守費用が増える可能性
4つ目は、システムの維持管理にかかる費用です。
AIによってプログラムの作成時間が短くなると、開発費用も抑えられるように感じるかもしれません。
しかし、業務システムは作成して終わりではありません。
実際には、次のような作業が必要になります。
- ソフトウェアの更新
- セキュリティ上の問題への対応
- 不具合の修正
- 業務ルールの変更への対応
- 利用者からの問い合わせ
- バックアップと復旧確認
例えば、開発時は短時間で完成しても、毎月多くの修正作業が発生する場合、運用費用が大きくなる可能性があります。
システムの費用は開発時だけで比較しない
| 費用の種類 | 確認する内容 |
|---|---|
| 初期開発費用 | システムを作るための費用 |
| テスト費用 | 動作や安全性を確認する費用 |
| 運用費用 | サーバー・ライセンスなどの費用 |
| 保守費用 | 更新・不具合修正などの費用 |
| 教育・引継ぎ費用 | 社員が使い続けるための費用 |
これらを含めた費用を考えることが重要です。
このような、導入から運用までを含めた費用を「総保有コスト（TCO）」と呼ぶことがあります。
AIで安く作れたとしても、長期間の運用まで含めて安いとは限らないのです。
リスク⑤ 不具合が起きたときの責任者が決まっていない
5つ目は、運用責任の問題です。
例えば、AIを使って作成した受注管理システムに不具合が発生し、注文データが正しく登録されなくなった場合です。
そのとき、誰が原因を調べ、誰が業務への影響を判断するのでしょうか。
AIが作ったシステムだからといって、AI自身が業務上の責任を負うわけではありません。
企業として利用する以上、適切な管理体制を整える必要があります。
責任を分担することが重要
| 担当 | 主な役割 |
|---|---|
| 業務責任者 | 業務上の判断と利用ルール |
| 開発担当者 | プログラムの修正・技術的な対応 |
| IT管理者 | 権限・セキュリティ・運用環境 |
| 経営者 | 投資判断と重要なリスクへの対応 |
小規模な企業では、一人が複数の役割を兼ねる場合もあります。
その場合でも、誰が最終的に判断するのかを決めておくことが重要です。
では、AIによるシステム内製化はやめた方がいい？
DX担当 ちゃま男先輩！ここまで聞くと、AIでシステムを作るのは危険だから、全部外注した方がいい気がしてきました。
ちゃま男の先輩必ずしもそうではないよ。
AIを使った内製化にはメリットもあるんだ。
大切なのは、どんな業務を内製化するか、どの部分に専門家の確認が必要かを見極めることだね。
内製化に向いている業務と慎重に扱うべき業務
例えば、次のように考えることができます。
| 業務の種類 | 考え方 |
|---|---|
| 個人用の集計ツール | 社内ルール内で試験的に内製化しやすい |
| 部門内の問い合わせ管理 | 権限や運用ルールを確認して導入 |
| 社内の設備点検管理 | 記録の正確性や履歴管理を確認 |
| 重要な在庫・受発注管理 | データ整合性や業務停止時の影響を厳格に確認 |
| 給与・個人情報・重要な制御システム | 専門的な設計・レビュー・検証が特に重要 |
※これは一般的な判断の例です。実際のリスクは利用者数、データの重要性、外部接続などによって異なります。
中小企業は何をすべきか？AI内製化のための5つの実践策
優先度① AI開発に利用してよい環境を決める
まず、会社で使用を認めるAIツールと、利用してよい情報の範囲を決めましょう。
個人アカウントで業務上の機密データを扱わないなど、具体的なルールを設けます。
IPAも、AI利用者向けのセキュリティ資料で、営業秘密の取り扱いなどについて注意を促しています。
優先度② 業務への影響に応じて開発ルールを分ける
試作品と、本番業務に使用するシステムでは、求められる管理水準が異なります。
例えば、重要な顧客情報を扱うシステムでは、専門家によるレビューを必要とするなどのルールを設けましょう。
優先度③ 本番導入前にテストする
正常な操作だけでなく、異常な操作や通信エラーが発生した場合も確認しましょう。
特に、データの二重登録、権限の問題、入力ミスなどは重要です。
また、AIにテストを作らせる場合でも、テスト内容が十分かどうかを人が確認する必要があります。
優先度④ 管理責任者と保守方法を決める
システムの管理責任者、プログラムの保存場所、更新方法、障害時の連絡先などを決めておきます。
担当者が退職した場合にも引き継げるようにしておきましょう。
優先度⑤ 開発費用だけでなく運用費用と効果を確認する
最後に、開発にかかった時間だけでなく、運用開始後の保守負担や業務改善の成果も確認します。
例えば、作業時間の削減効果と、修正・保守にかかった時間を比較します。
効果が小さく運用負担が大きい場合は、既存の業務サービスを利用する方が合理的な可能性もあります。
AI内製化と既存の業務プラットフォームを組み合わせる方法
すべての業務システムを、AIでゼロから開発する必要はありません。
例えば、kintoneのような業務プラットフォームを使い、データ管理やアクセス権限などの基本機能を利用しながら、必要な部分だけをカスタマイズする方法があります。
ただし、既存サービスを利用している場合でも、追加開発した部分の品質や権限管理は確認する必要があります。
既存の仕組みで対応できる部分と、独自開発が必要な部分を分けることが重要です。
関連サービス｜製造業の業務に合わせたシステム構築と運用支援
ラック・インターナショナル株式会社では、kintoneなどを活用し、中小製造業の業務に合わせたシステム構築や、導入後の運用改善を支援しています。
AIによる開発や内製化を検討する場合でも、実際の業務要件、必要な機能、運用体制などを整理することが重要です。
内製化する部分と外部の専門家へ依頼する部分を検討する際にも、業務内容に応じたシステム構成を考える必要があります。
まとめ｜AIでシステムを作れる時代こそ運用責任が重要
生成AIによって、システム開発の一部を効率化できるようになりました。
しかし、企業として安全に使い続けるためには、セキュリティ、データの整合性、保守、管理責任などを考える必要があります。
AIによる内製化が必ず危険というわけではありません。
一方で、システムを作ることが簡単になったからといって、管理の負担がなくなるわけでもありません。
重要なのは「AIで作れるか」ではなく、「会社として責任を持って使い続けられるか」です。
まずは自社でAIによって作成された業務ツールを洗い出し、管理者、保存場所、アクセス権限、保守方法が明確になっているか確認してみましょう。
参考資料
※本記事は2026年11月4日時点の公開情報に基づいています。リスクの分類と実務対策は、公開資料を参考に整理したものであり、すべての企業で同じ対策が必要という意味ではありません。
