生成AIで作った業務システムは本番運用できる？プロが見るチェックポイント

生成AIで作った業務システムの本番運用とは、生成AIを使って開発した業務システムを、試作や検証の段階から一歩進めて、実際の業務で継続的に使うことです。生成AIのコーディング支援ツールを使えば、エンジニアでなくても動く業務システムを短期間で作れるようになりました。しかし、「動くこと」と「業務で安心して使い続けられること」は別の話です。

結論からいえば、生成AIで作った業務システムも本番運用できます。ただし、それはコードの品質やセキュリティ、テスト、非機能要件、運用体制といった観点で、本番運用に耐えられるかを確認できた場合に限られます。本記事では、生成AIで作った業務システムに潜むリスクと、プロが本番運用の前に確認するチェックポイントを、チェックリストとあわせて解説します。

 

 

 

 

１．生成AIで作った業務システムは本番運用できる？

生成AIで作った業務システムを本番運用できるかどうかは、生成AIを使ったかどうかではなく、本番運用に必要な品質を満たしているかどうかで決まります。まずは、試作と本番運用で求められるものの違いを整理しておきましょう。

 

試作と本番運用では求められる品質が違う

試作は、アイデアや画面の使い勝手を確かめるためのものです。限られた人が、限られたデータで使うことを前提にしているため、多少の不具合があっても大きな問題にはなりません。一方、本番運用では、多くの人が実際の業務データを使って毎日操作します。主な違いは次のとおりです。

 

 

試作の段階では問題にならなかった不具合やセキュリティ上の弱点が、本番運用では大きな事故につながることがあります。

 

本番運用できるかは「確認したかどうか」で決まる

生成AIで作ったシステムと、エンジニアが一から作ったシステムで、本番運用に求められる品質の基準は変わりません。違いがあるとすれば、生成AIで作った場合は、作った本人がコードの中身を十分に理解していないことが多く、品質を確認する工程が抜けやすい点です。

つまり、生成AIで作った業務システムでも、コードの品質やセキュリティ、テスト、非機能要件、運用体制を一つずつ確認し、問題を解消できていれば本番運用は可能です。反対に、「動いているから大丈夫」と確認を省いたまま本番運用を始めるのは危険です。

 

 

２．生成AIで作った業務システムに潜むリスク

生成AIが作るコードは、一見すると問題なく動いているように見えます。しかし、本番運用の視点で見ると、いくつかの典型的なリスクが潜んでいることがあります。生成AIを使った開発で注意したいリスクを5つ紹介します。

 

正常な操作では動くが、例外やエラーに弱い

生成AIは、指示された機能が「正常に動く」コードを作るのは得意ですが、想定外の操作やデータへの備えが不十分になりがちです。たとえば、必須項目が空のまま登録された場合や、同じボタンが二度押された場合、外部のサービスにつながらなかった場合などの処理が考えられていないことがあります。

試作では気づかなくても、多くの人が使う本番運用では、こうした例外的な状況が必ず発生します。その結果、データが二重に登録されたり、処理が途中で止まったりする事故につながります。

 

セキュリティ上の脆弱性が含まれることがある

AIが生成したコードには、セキュリティ上の弱点である脆弱性が含まれることがあります。たとえば、入力された値をそのままデータベースへの命令に使ってしまい、不正な操作を許してしまうケースや、ログインしていない人でもデータを見られる状態になっているケースです。

生成AIは指示されていないセキュリティ対策を自動で十分に行ってくれるとは限りません。作った本人がセキュリティの知識を持っていないと、弱点に気づかないまま公開してしまうおそれがあります。

 

古い書き方や、サポートが終了したライブラリを使うことがある

生成AIは、学習したデータをもとにコードを作ります。そのため、すでに推奨されていない古い書き方や、開発元のサポートが終了したライブラリを使ったコードを提案することがあります。

サポートが終了したライブラリには、脆弱性が見つかっても修正が提供されません。最初は問題なく動いていても、後から大きなリスクになる可能性があります。

 

データベースや権限の設計が考えられていない

画面を作ることを優先して開発を進めると、データベースの設計や、誰がどのデータを見られるのかという権限の設計が後回しになりがちです。利用者やデータが少ないうちは問題なく動いても、利用が広がるにつれて処理が遅くなったり、見せるべきでない情報が他の部署から見えたりする問題が起こります。

 

誰もコードの中身を説明できない

生成AIで作ったシステムでは、作った本人でさえ、コードの中身を説明できないことがあります。この状態では、不具合が起きたときに原因を特定できず、修正にも時間がかかります。作った本人が異動や退職をすると、システムに手を入れられる人が社内にいなくなってしまいます。

 

 

３．プロが見る本番運用前のチェックポイント

開発会社や経験のあるエンジニアなど、プロが生成AIで作った業務システムを本番運用に乗せる前には、大きく5つの観点で確認を行います。ここでは、それぞれの観点で何を確認するのかを解説します。

 

コードの品質とレビュー

まず確認するのは、AIが生成したコードの品質です。経験のあるエンジニアがコードを読み、次のような点をレビューします。

• 処理の内容を人が読んで説明できるか。不要な処理や、同じ処理の重複がないか
• 入力された値のチェックや、エラーが起きたときの処理が書かれているか
• 使っているライブラリが最新の安定した版か。サポートが終了したものが含まれていないか
• ライブラリのライセンスが、自社での利用条件に合っているか

AIが生成したコードは、一つひとつは正しく見えても、全体として見ると設計に一貫性がないことがあります。部分ごとではなく、システム全体の構成を見渡してレビューすることが大切です。

 

セキュリティ

業務システムは、顧客情報や取引データなど重要な情報を扱います。AIが生成したコードのセキュリティについては、次のような点を確認します。

• ログインの仕組みがあり、利用者ごとに見られるデータや操作できる機能が制限されているか
• 外部からの不正な入力によってデータベースを操作される「SQLインジェクション」や、画面に不正なプログラムを埋め込まれる「クロスサイトスクリプティング」などの代表的な脆弱性への対策ができているか
• パスワードや、外部サービスにつなぐためのAPIキーなどがソースコードに直接書き込まれていないか
• 外部のAIサービスを使う機能がある場合、どのようなデータを送っているか。社外に出してはいけない情報が含まれていないか

必要に応じて、脆弱性を自動で検出するツールによる診断や、専門の会社による脆弱性診断も検討しましょう。

 

テスト

本番運用の前には、システムが正しく動くことをテストで確かめます。生成AIで作った業務システムでは、特に次の点が重要です。

• 正常な操作だけでなく、入力ミスや二重の操作など、例外的な操作でも正しく動くか
• 整ったサンプルデータではなく、空欄や表記の揺れを含む、本番に近いデータで動作を確認したか
• 実際の業務の流れに沿って、現場の担当者が受け入れテストを行ったか
• 改修のたびに既存の機能が壊れていないかを確かめる、自動テストが用意されているか

AIを使えばテストコードも作成できますが、何をテストすべきかを決めるのは人です。業務を知る担当者とエンジニアが協力して、確認すべき項目を洗い出しましょう。

 

非機能要件

非機能要件とは、機能そのものではなく、性能や安定性など「どのように動くべきか」に関する要件です。試作では見落とされやすいため、本番運用の前に次の点を確認します。

• 想定する利用者の数やデータの量で、処理速度に問題がないか
• 定期的にバックアップを取っているか。障害が起きたときに、どこまでのデータを、どのくらいの時間で復旧できるか
• 誰がいつどのような操作をしたかを記録するログが残っているか
• システムが止まったときや異常が起きたときに、担当者が気づける監視の仕組みがあるか

 

運用・保守体制

最後に、本番運用を始めた後に誰がシステムの面倒を見るのかを確認します。不具合が起きたときの連絡先と対応の流れ、改修を行うときの手順と承認者、セキュリティ更新を行う担当者を決めておきましょう。あわせて、設計書や操作マニュアルを残しておくことも、担当者が変わったときに保守を引き継ぐうえで欠かせません。

本番運用を始めた後の保守体制の考え方については、AIで作ったシステムを誰が保守するかを解説した記事で詳しく紹介しています。

 

 

４．生成AIで作った業務システムの本番運用チェックリスト

ここまで紹介したチェックポイントを、本番運用前に確認できるチェックリストにまとめました。確認できていない項目が多いほど、本番運用でのトラブルのリスクが高くなります。

 

 

「エンジニア」の項目は、社内に経験のあるエンジニアがいない場合、開発会社などのプロにレビューを依頼して確認するのが現実的です。

 

 

５．自社で確認できる範囲と、プロに任せるべき範囲

生成AIで作ったすべての業務システムに、プロのレビューが必要なわけではありません。システムの用途や影響の大きさによって、自社だけで運用してよいものと、プロに確認を任せるべきものを分けて考えましょう。

 

自社で作って運用してよいシステム

次のような条件に当てはまるシステムは、自社で作って運用しても、トラブルの影響を小さく抑えやすいといえます。

• 個人や一つの部署の中だけで使う
• 止まっても手作業で代わりの対応ができ、業務全体に大きな影響が出ない
• 顧客情報や取引データなど、重要な情報を扱わない
• ほかのシステムのデータを書き換えない

たとえば、部署内の日報の集計や、Excelで行っている定型作業の自動化などが該当します。ただし、この場合でも、作った本人しか中身がわからない状態は避け、簡単な説明資料を残しておきましょう。

 

プロのレビューを受けるべきシステム

一方で、次のような条件に当てはまるシステムは、本番運用の前にプロのレビューを受けることをおすすめします。

• 顧客情報や個人情報、決済や請求など、お金に関わる情報を扱う
• 複数の部署の担当者が毎日使う
• 基幹システムなど、ほかの重要なシステムとつながっている
• 社外の取引先や顧客も利用する

こうしたシステムで事故が起きると、業務が止まるだけでなく、取引先や顧客からの信頼を失うことにもつながります。基幹システムのような重要なシステムを社内で開発・運用する場合の体制づくりについては、AIで基幹システムを内製化するメリットと注意点で解説しています。

 

 

６．生成AIで作った業務システムの本番運用に関するよくある質問

最後に、生成AIで作った業務システムの本番運用について、よく寄せられる質問にお答えします。

 

試作で作ったシステムは、作り直しになりますか？

必ずしも作り直しになるわけではありません。レビューの結果、構成に大きな問題がなければ、不足している部分を補強して本番運用に移せることもあります。一方で、データベースや権限の設計が根本的に不足している場合は、作り直したほうが結果的に早く、安く済むこともあります。その場合でも、試作で固めた画面や業務の流れは、新しいシステムの要件として生かせます。

試作で確かめた内容をもとに、自社業務に合ったシステムをAIを活用して作る方法については、AIスクラッチ開発とは何か、自社業務に合ったシステムをAIで作る方法で紹介しています。

 

コードのレビューだけを外部に依頼できますか？

依頼できる場合があります。開発会社の中には、他社や社内で作ったシステムのコードレビューや脆弱性診断を引き受けているところもあります。依頼する際は、ソースコードのほか、システムの構成図や使っているライブラリの一覧、想定している利用者数などをまとめておくと、相談がスムーズに進みます。

 

本番運用を始めるまでに、どのくらいの準備期間が必要ですか？

システムの規模や扱うデータの重要度、レビューで見つかった問題の量によって大きく変わるため、一概にはいえません。小規模なツールであれば短期間で確認できることもありますが、個人情報やお金を扱うシステムでは、修正やテストを含めて十分な期間を見込んでおく必要があります。本番運用を始めたい時期が決まっている場合は、早めにレビューを依頼し、準備期間を逆算して計画を立てましょう。

 

 

７．まとめ：生成AIで作った業務システムは「確認」して本番運用へ

生成AIで作った業務システムも、本番運用することは可能です。ただし、生成AIが作るコードは、例外的な操作への備えやセキュリティ対策、データベースや権限の設計が不十分なことがあり、作った本人も中身を説明できないことがあります。「動いているから大丈夫」と確認を省いたまま本番運用を始めるのは危険です。

本番運用の前には、コードの品質とレビュー、セキュリティ、テスト、非機能要件、運用・保守体制の5つの観点で確認を行いましょう。個人情報やお金を扱うシステムや、複数の部署で毎日使うシステムは、社内に経験のあるエンジニアがいない場合、プロのレビューを受けることをおすすめします。

生成AIで作ったシステムを本番運用に乗せたい場合や、試作をもとに業務で使えるシステムを作りたい場合は、業務分析から基幹システムの構築、運用・改善まで伴走するシステム開発サービスもご検討ください。実際にシステムを導入した企業の取り組みは、A.N.Sの導入事例で紹介しています。