生成AIを活用した開発の限界 〜複雑なシステムほど、人の出番が増えるという話〜

「生成AIに頼めば、プログラムなんてあっという間に作れる時代になった」――そんな話を聞いたことがある方も多いのではないでしょうか。実際、簡単な処理であれば、生成AIにお願いするだけで動くコードがすぐに出てきます。もはや魔法のような便利さです。

ところが、いざ実務で本格的に使ってみると、「あれ、思ったより万能じゃないぞ？」という場面に出くわします。特に、複数のシステムを連携させるような複雑な開発になると、生成AIの限界が一気に見えてきます。

「生成AIによってエンジニアの仕事がなくなる」という話題も、定期的に世間を賑わせています。しかし、現場で実際に生成AIを使ってシステム開発に携わっている方ほど、「いやいや、そう簡単な話じゃないですよ」と感じているのではないでしょうか。

今回は、この「単純な開発ではうまくいくのに、複雑な開発になると途端につまずく」という現象について、現場目線でお話ししたいと思います。

第1章：単純な依頼は得意中の得意

まず、生成AIが得意とする領域から確認しておきましょう。

ひとつのファイルの中で完結するような、シンプルな処理。これは生成AIの独壇場と言ってもいいでしょう。たとえば、エクセルのVBAで「A列のデータを並び替えて、B列に重複を除いた一覧を出力する」といった処理であれば、ひとことお願いするだけで、しっかり動くコードが返ってきます。しかも、こちらが想像していたよりも丁寧にコメントまで入れてくれたりします。気が利く新人のようです。

ホームページの簡単なお問い合わせフォーム、データを集計するだけのマクロ、テキストを整形する小さなスクリプト。こうした「ひとつの目的が明確で、扱う対象も限定的」な開発であれば、生成AIは強力な味方になってくれます。

ここまでなら、「生成AIすごい！もう人間いらないんじゃない？」と感じてしまうのも無理はありません。

第2章：システム連携が入った瞬間に難易度が跳ね上がる

ところが、話が「複数のシステムをつなぐ」となった途端、状況は一変します。

身近な例で考えてみましょう。エクセルVBAで開発する場合、ひとつのエクセルファイルの中だけで完結する処理であれば、生成AIへの指示出しは比較的シンプルです。「このシートのデータを集計してください」「この条件で並び替えてください」と伝えれば、概ね期待通りのコードが返ってきます。

ところが、「Aというエクセルファイルからデータを読み取って、Bというエクセルファイルに転記し、さらに条件によってCというファイルにも反映させる」となると、話は急に難しくなります。指示する側の負担が一気に増えるのです。

「Aのファイルのどのシートの、どの範囲のデータを、どんな条件で読み取って、Bのどこに、どういうルールで書き込むのか」――これを文章で漏れなく伝えようとすると、それだけで長大な指示書になってしまいます。少しでも条件を伝え忘れると、AIは勝手にそれらしく補完してしまい、結果として意図しない動きをするコードができあがります。

しかも、出てくるコードの量が膨大になりがちです。数百行、場合によっては千行を超えるコードが返ってくることもあります。動かしてみて不具合があったとき、その大量のコードを解読して、どこがおかしいのかを突き止める作業は、相当な根気と時間を要します。「自分で書いたほうが早かったのでは？」と頭を抱えることになりかねません。

第3章：若手社員からの正直な声

実際、若手の社員からこんな声を聞いたことがあります。「複雑なシステムを作るときは、生成AIを使っても、結局は検証に時間がかかってしまって、あまり効率化につながらないんですよね」と。

これは非常に的を射た意見だと感じました。生成AIは確かに高速でコードを生成してくれますが、そのコードが本当に正しく動くか、意図通りの処理になっているかを確認する作業は、人間がやらなければなりません。コードが複雑になればなるほど、この検証作業の負担は雪だるま式に増えていきます。

結果として、「生成にかかる時間は短くなったけれど、検証に時間がかかって、トータルではあまり変わらない」という状況が生まれます。下手をすると、「最初から自分で設計しながら書いたほうが、確実で早かった」となることすらあります。

第4章：解決のヒントは「設計は人間、実装はAI」

では、複雑なシステム開発において、生成AIをどう活用すればいいのでしょうか。

私が現時点で有効だと感じているのは、「設計は人間がしっかり行い、関数レベルの細かい単位で生成AIに指示を出す」というやり方です。

具体的には、こういう流れになります。まず、人間が全体の設計を考えます。「このシステムは、こういう処理の流れで動かす。そのために、Aという機能と、Bという機能と、Cという機能が必要だ」という形で、システムを小さな部品に分解します。そして、それぞれの部品ごとに、生成AIに「Aという機能を実現するコードを書いてください」と依頼するのです。

この方法であれば、生成AIに渡す指示はシンプルになりますし、出てくるコードも短く、検証もしやすくなります。最終的に、人間がそれらの部品を組み合わせて、ひとつのシステムとして仕上げる、という形です。

料理にたとえるなら、生成AIは「優秀な下ごしらえ担当」と考えるのが分かりやすいかもしれません。野菜を切る、肉に下味をつける、出汁を取る。こうした個別の作業は任せられます。しかし、「どんな料理を作るか」「どの順番で調理するか」「最終的にどう盛り付けるか」という全体の設計は、料理人である人間が考える必要があるのです。料理人不在のキッチンで下ごしらえだけが進んでも、出てくるのは謎の食材の山だけ、ということになりかねません。

第5章：「エンジニアは不要になる」という議論への違和感

「生成AIによってエンジニアの仕事がなくなる」という議論を、定期的に耳にします。確かに、簡単なコードを書くだけの仕事であれば、生成AIに置き換えられていく流れは避けられないでしょう。

しかし、これまで大規模なシステム構築に携わってきたエンジニアの仕事を、生成AIが丸ごと代替できるかというと、現実はそんなに甘くありません。むしろ、これまで大きなシステムを設計したり構築したりした経験のない人が、いきなり生成AIを使って複雑なシステムを作ろうとしても、到底うまくいかないのが現実です。

なぜなら、システム開発で本当に難しいのは「コードを書くこと」ではなく、「全体をどう設計するか」「業務をどう整理してシステムに落とし込むか」という上流の部分だからです。この部分は、過去の経験や、業務への深い理解、関係者との地道な対話の積み重ねがあってはじめて可能になります。生成AIは、ここを肩代わりしてくれるわけではありません。

つまり、「人間に何ができて、何ができないのか」「業務の本質は何で、どこをシステム化すべきか」を理解している人がいて、はじめて生成AIは応用できるのです。逆に、こうした基礎的な力がないまま生成AIに頼ろうとすると、出てきたコードの良し悪しすら判断できず、結局は使いこなせないまま終わってしまいます。

道具がどれだけ進化しても、それを使いこなす土台となる力は、結局のところ人間の側に求められるのですね。

おわりに：万能ではないけれど、頼れる相棒

生成AIは、確かに開発の世界を大きく変えました。簡単な処理であれば、これまでの何倍ものスピードで作れるようになりました。しかし、複雑なシステムになるほど、人間の設計力と検証する目が必要になる、という現実もあります。

大切なのは、生成AIを「全部やってくれる魔法の杖」と期待しすぎないことです。得意なところは思いきり任せて、苦手なところは人間がカバーする。この役割分担ができてはじめて、生成AIは本当の意味で業務効率化に貢献してくれます。

そして、その役割分担を上手に行うためには、人間の側に「業務を理解する力」「全体を設計する力」「成果物を評価する力」が必要です。生成AIが進化すればするほど、皮肉なことに、こうした人間ならではの力の重要性は増していくのではないでしょうか。

技術が進化しても、結局は「使う人間の力量」が問われる。これは、どの時代になっても変わらない真理なのかもしれませんね。