生成AIで業務アプリをどこまで作れるのか｜全3回シリーズ 第1回

全3回シリーズ：生成AIで業務アプリをどこまで作れるのか

生成AIは、文章作成、翻訳、調べものなどで活用される機会が増えています。 一方で、会社から「生成AIを活用してください」と言われても、実際にはそれ以外の使い道が思いつかないという方も少なくありません。

そこで本シリーズでは、「生成AIで業務アプリをどこまで作れるのか」というテーマを、全3回に分けて検証します。 第1回となる今回は、社内で必要になる“ちょっとしたシステム”を、生成AIと一緒に自前で作れるのかを実験した結果をご紹介します。

今回の目的は、生成AIが仕事をすべて自動で行ってくれるかどうかを検証することではありません。 生成AIを、要件整理、設計、実装、テストを支援する“開発パートナー”として活用した場合、どこまで現実的に業務アプリを作れるのかを確認することです。

なぜ“ちょっとしたシステム”が必要になるのか

現場には、日々の業務の中で小さな不便が多く存在します。 たとえば、Excelで管理している作業を少し楽にしたい、簡単な入力画面がほしい、紙の申請を小さくデジタル化したい、といった課題です。

こうした課題は、業務上は確かに困っているものの、システム会社に依頼するには規模が小さすぎることがあります。 また、社内IT部門があっても、日々の運用保守や問い合わせ対応に追われ、小さな改善案件まで手が回らないケースもあります。

その結果、本格的なシステムを導入するほどではないが、放置すると手間やミス、欠品、過剰在庫につながるような“小さな不便”が残り続けてしまいます。

今回の題材：副資材・スペアパーツの補充システム

今回の実験では、製造業でよくある副資材や設備スペアパーツの補充業務を題材にしました。 副資材やスペアパーツは、生産に必要なものではある一方で、本格的な在庫管理システムの対象になっていないこともあります。

管理が不十分な場合、必要なときに在庫がない、あるいは不安だから多めに持ちすぎてしまうといった問題が起きます。 一方で、専用のシステムを導入するほど大規模な業務ではないことも多く、“ちょっとしたシステム”が欲しくなる領域です。

そこで今回は、生成AIにアプリケーション開発をサポートさせることで、このような小規模な補充システムを自前で構築できるのかを検証しました。

今回の前提条件

今回使用したのは、一般的に利用できるChatGPT Plusです。 開発者向けの特別なAIツールではありません。 システムは、Google SpreadsheetとGoogle Apps Scriptを中心に構築しました。

最初に人間が入力したのは、細かな仕様書ではなく、「副資材やスペアパーツを簡単に管理したい」という相談レベルの内容です。 そこから生成AIが、承認は必要か、数量変更はできるか、分納はどう扱うか、キャンセルはどうするかといった質問を返し、人間が業務としてどうしたいかを答えていきました。

つまり、AIが勝手にすべてを決めたわけではありません。 人間が業務判断を行い、AIがその判断を要件、設計、プログラム、テスト手順へ整理していくという役割分担で進めました。

• 人間：業務としてどうしたいかを判断する
• 生成AI：要件整理、設計、実装、テスト手順作成を支援する
• 開発環境：Google Spreadsheet、Google Apps Script、HTMLなどを活用する
• 目的：本番想定の大規模開発ではなく、小規模アプリのプロトタイプ検証を行う

実際に作成したアプリの流れ

今回作成した補充システムでは、現場でQRコードを読み取り、補充依頼を登録し、購買側で承認を行い、発注番号や納期を登録し、最後に納品・完了まで進める流れを確認しました。

単なる入力フォームではなく、現場から購買、納品完了までの一連の業務フローとして動くことを重視しています。 スマートフォンの実機でも確認し、QRコード読み取りから依頼、承認、発注、納品、完了までの流れを一通り試しました。

今回の検証では、見た目の完成度よりも、小規模な業務アプリとして実際の業務フローを最後まで通せることを重視しました。

開発にかかった時間

今回の開発では、各工程の作業時間を記録しました。 要件定義が約1.3時間、設計が約5.8時間、環境構築が約1.8時間、コーディングが約10.4時間、テストが約2.5時間です。

合計は約21時間45分で、1人日を8時間とすると約2.7人日でした。 これは今回の小規模な新規アプリでの実験結果であり、すべての開発にそのまま当てはまるものではありません。

一方、AIなしで同程度のものをゼロから作る場合の比較用目安としては、9〜20人日程度が想定されます。 今回の検証では、通常業務の合間に少しずつ進めても、短期間でプロトタイプから実機確認まで到達できる可能性が見えました。

生成AIが貢献したポイント

今回、生成AIが大きく貢献したのは、単にコードを書いたことだけではありません。 要件定義で決めた内容を設計へ引き継ぎ、設計内容を実装へ反映し、さらにその内容を理解したままテスト手順まで作成できた点が大きな効果でした。

通常の開発では、要件、設計、実装、テストの各工程で情報が途切れたり、認識違いが起きたりすることがあります。 今回のように生成AIを伴走役として使うことで、工程間のつながりを保ちやすくなり、手戻りの削減にもつながる可能性があります。

また、プログラム知識が十分でない人でも、AIの質問に答え、AIの指示を確認しながら進めることで、ある程度のところまで開発を進められることが分かりました。

生成AIは万能ではない

一方で、生成AIを使えばどんなシステムでも簡単に作れるというわけではありません。 今回の検証は、Google Apps Script、HTML、Spreadsheet、Google標準APIなど、生成AIが比較的扱いやすい技術を使った小規模な新規アプリでした。

そのため、COBOL、RPG、ABAP、PL/Iなどで作られた既存システムの改修や、大規模ERP導入に、今回の結果をそのまま当てはめることはできません。

ただし、そうした大規模案件であっても、生成AIがまったく使えないわけではありません。 要件整理、Fit & Gap分析、設計書作成、テストシナリオ作成など、生成AIが支援できる領域は多くあります。

小さな課題解決とプロトタイプ検証に向いている

今回の検証から見えたのは、生成AIが社内の“小さな不便”を解決する選択肢になり得るということです。 これまで費用や人手の問題で放置されていた小さな業務課題に対して、生成AIを使いながら自前でプロトタイプを作るという進め方が現実的になりつつあります。

また、本格的なシステムを導入する前に、プロトタイプを作って業務要件を具体化する使い方も有効です。 実際に動くものを作ることで、ベンダーに伝える要件や仕様をより具体的にでき、システム開発会社とのコミュニケーションもスムーズになります。

つまり、生成AIを使った業務アプリ開発は、「すべてをAIに任せる」ものではなく、「人間が業務判断を行い、AIが開発作業を支援する」ことで、小さな改善を前に進めるための手段だと考えるべきです。

第2回以降の内容

本シリーズは全3回で構成されています。 第1回では、生成AIを使って実際にどのような業務アプリを作ったのか、どのくらいの工数がかかったのか、どのような可能性と限界が見えたのかを紹介しました。

次回は、実際にどのようなプロンプトを使い、ChatGPTとどのような会話をしながら要件定義や設計を進めたのか、具体的な作業の様子をご紹介する予定です。

まとめ

生成AIは、仕事を自動で全部やってくれる万能ツールではありません。 しかし、業務アプリ開発における要件整理、設計、実装、テストの各工程を支援する大きなサポートツールになり得ます。

特に、今回のようなGoogle SpreadsheetやGoogle Apps Scriptを使った小規模な新規業務アプリであれば、生成AIと一緒に進めることで、短期間でプロトタイプを作れる可能性があります。

一方で、レガシーシステム改修やERP導入、大規模開発に今回の結果をそのまま当てはめることはできません。 適用しやすい領域と、慎重に考えるべき領域を分けて考えることが重要です。

もし現在、社内に「システム会社に依頼するほどではないが、何とかしたい小さな業務課題」があるなら、生成AIを開発サポート役として活用することは、十分に検討する価値があります。

生成AIを活用した小規模業務アプリ開発は、現場の小さな課題を解決し、将来的なDXや本格的なシステム導入につなげるための現実的な第一歩です。