AI主導開発の功罪
昨今、IT関連の勉強会に参加していると「AIを利用したサービスを開発している」「AIを用いたソフトウェア開発を行っている」といった声が顕著に増えました。
先日、ある方から「うちの社長は生成AIマニアで、Difyを使って1〜2日で開発して納品している」と聞き、改めて生成AIの普及を実感しました。
Difyは、コーディングスキルがなくてもAIアプリケーションを簡単に作成できることを強みとする開発プラットフォームです。
同様のツールとしてはbolt.newやn8nなどが挙げられます。このようなプラットフォームを活用した超高速開発・納品は魅力的ですが、懸念したのは、その後の保守運用についてです。
ある程度の開発スキルを持つエンジニアがAIツールを補助的に利用する場合、問題が発生しても自力で修正する選択肢があります。
しかし、そうでない場合、プロンプトを書き換えて再生成したり、修正リクエストのプロンプトを投入したりするしかなく、根本的な解決が難しい可能性があります。
プラットフォーム側で自動コードレビューや脆弱性スキャンといった機能が提供されるとしても、AIによるブラックボックス化が保守性を低下させる懸念は残ります。
活用した開発経験がある方ならお分かりかと思いますが、AIは人間の意図を完全に理解できない場合があり、文脈から外れた機能やコードを生成することがあります。
これにより、期待通りの機能拡張ができなかったり、予期せぬ動作を引き起こしたりするリスクも考えられます。
過去のRPAブームでは、「保守できないRPAロボットが量産され、管理に困る」という問題が頻発しました。
同様の問題は、AIツールで開発されたソフトウェアでも起こり得ると考えられます。
RPAでは、プログラミング知識がなくても開発できる手軽さから、専門知識を持たない担当者が「とりあえず動けば良い」という感覚で作成し、その後の保守や改修が困難になるケースが多発しました。
AIツールによるソフトウェア開発も、このRPAの轍を踏む可能性があります。
業務プロセスや外部システムの変更があった際、AIが生成したコードが既存環境に合わなくなり、修正に膨大な手間がかかる可能性があります。
RPAと同様に、AIがブラックボックス化している場合、この問題はさらに深刻になります。
また、開発が容易であるゆえに、計画的な保守体制やドキュメンテーションがおろそかになり、「作りっぱなし」になってしまうリスクも潜んでいます。
もちろん、AIプラットフォーム側もこれらの課題を認識しており、アプリケーションの保守・運用に関する機能は進化していくでしょう。
しかし、RPAロボットの管理で情報システム担当者が苦労したのと同じことが、生成AIアプリ開発においても繰り返されるのではないかと懸念されます。
とはいえ、作業効率化を考えると、生成AIを全く使わないという選択肢は、競争力を考えると現実的ではありません。
今後は、運用・保守を考慮したこれらのツール利用のルール作りを検討していく必要があるでしょう。
