講座の概要

本講座は全3回シリーズの最終回として、第2回で固めた仕様を実際のコードへ落とし込み、実装・テストまで進めた結果を紹介します。
実装では、仕様をAIへ渡し、コード生成、実行、画面・ログ確認、修正、再実行を繰り返す高速な改善サイクルを取り上げます。
テストでは、正常系・異常系・境界値・状態遷移・権限などの観点をAIに広げてもらい、人間が重要領域を判断する考え方を解説します。
さらに、「テスト空間の地図」を人間とAIの共通認識として活用し、テストの網羅性や選定根拠を説明できる形にする方法を紹介します。
最後に、全3回の実証を振り返りながら、生成AIが減らせる「作業」と、人間に残る「判断・検証・品質責任」を整理します。

このウェビナーで得られること

生成AIにコードを書かせれば、システム開発は大幅に楽になる。 そう聞くと、「仕様さえ決まれば、あとはAIに任せれば完成するのではないか」と考える方もいるかもしれません。

しかし、今回実際に業務アプリの実装・テストまで進めて分かったのは、 「コードが生成されたこと」と「業務で使えるシステムが完成したこと」は全く同じではない、ということです。

本ウェビナーでは、生成AIを使ってコード生成、実行、修正、テストを進めた実体験をもとに、 AIに任せやすい作業と、人間が確認・判断しなければならない領域を具体的に整理します。

また、生成AIに大量のテストケースを作らせるだけではなく、 テストすべき領域を「テスト空間の地図」として可視化し、 AIがケースを広げ、人間が重要度やリスクを判断するという実践的な考え方も紹介します。

全3回シリーズの最終回として、 「生成AIで業務アプリをどこまで作れるのか」という問いに対して、 どこまでAIに任せられ、どこから人間が責任を持つべきなのかを整理できる内容です。

全3回シリーズ 最終回：実装・テストまで生成AIと進める

本記事は、「生成AIで業務アプリをどこまで作れるのか」全3回シリーズの最終回、第3回です。

第1回では、QRコードを使った副資材・スペアパーツ補充依頼システムを実際に作り、 小規模な業務アプリであれば、生成AIを使いながら自分たちで形にできる可能性があることをご紹介しました。

第2回では、企画・要件定義・設計という上流工程に焦点を当て、 生成AIが論点を細かく展開し、仕様を具体化することには強い一方で、 意思決定や長期的な整合性の確認には人間の役割が重要であることを取り上げました。

そして最終回となる今回は、第2回までに固めた仕様を実際のコードへ落とし込み、 実装・テストを進める中で生成AIがどこまで役に立ったのか、 そして人間が担わなければならなかった役割は何だったのかを整理します。

実装は「一発完成」ではなく、高速な修正サイクル

今回の実装では、第2回までに確定した仕様をもとに、 ChatGPTへ「この仕様を実現するコードを作ってください」と依頼しました。

使用した主な技術は、Google Apps Script、HTML、Spreadsheet、Driveなど、 Google Workspaceの標準的な機能です。

実際の進め方は非常にシンプルでした。

  • 確定した仕様をAIへ渡す
  • AIがコードを生成する
  • 人間が実際の環境へコードを入れて実行する
  • 画面・ログ・動作を確認する
  • 問題や想定との違いをAIへ返す
  • AIが原因を推定し、修正案を生成する
  • 修正後に再度実行する

このサイクルを繰り返しながら実装を進めました。

生成AI開発というと、 「仕様を入力すれば完成したコードが一気に出てくる」 というイメージを持たれがちです。

しかし、実際には環境設定、権限、実データ、画面表示、通知、端末など、 コード以外の要素もシステムの動作に大きく影響します。

そのため、実感としては 「コーディングという仕事がなくなった」 というよりも、 「実装と修正のサイクルを非常に速く回せるようになった」 という表現の方が適切でした。

コーディングそのものは大幅に効率化できた

今回の実績では、実装に約10.4時間、テストに約2.5時間を要しました。

第2回までに実施した要件定義約1.3時間、設計約5.8時間を含めると、 上流工程は約7.1時間です。 シリーズ第1回でご紹介した通り、全体では約2.7人日の作業となりました。

もちろん、これは小規模な社内向けアプリであり、 Google Apps ScriptやGoogle Spreadsheetなど、生成AIが比較的扱いやすい技術を使ったケースです。 すべてのシステム開発で同じ結果になるわけではありません。

それでも、HTML画面、Google Apps Scriptによる処理、Spreadsheetへのデータ登録、 通知処理などを人間がゼロからすべて記述する場合と比べると、 コードを書く作業そのものはかなり効率化できました。

また、実装工程でも重要だったのは、 プログラムの細かな文法を書く能力以上に、 「何を実現したいのか」を明確にAIへ伝えることでした。

AIはコードの文法を補うことができます。 しかし、実現したい動作が曖昧であれば、曖昧な仕様をそのままコードにしてしまいます。

「コードが生成された」＝「完成」ではない

コード自体にエラーがなくても、実際に動かしてみると様々な問題が発生します。

今回も、

  • 画面上のボタンが想定と違う動きをする
  • Spreadsheetに入る値が期待した形式と異なる
  • デプロイ設定が原因で動作しない
  • 権限設定によって想定外の表示になる
  • 通知が期待したタイミングで届かない

といった問題がありました。

その際は、 「このボタンを押すと、この画面になりました」 「このエラーが表示されました」 「この値がSpreadsheetに入りませんでした」 といった実際の現象をChatGPTへ伝えます。

必要に応じて画面キャプチャやログも共有し、 AIに原因候補と修正案を考えてもらいました。

実装工程では、人間がAIの「目と手」になる

今回の実証で特に印象的だったのが、 実装工程では人間がAIにとっての「目」と「手」になる、という役割分担です。

AIは、渡された仕様書やコード、ログ、エラーメッセージを見ることはできます。

しかし、人間が情報を与えなければ、

  • スマートフォンでQRコードを正しく読めたか
  • 写真が正しく登録されたか
  • メール通知が届いたか
  • 権限設定が正しく機能しているか
  • 現場で操作しやすい画面になっているか

といった、実際の環境で起きていることを直接確認することはできません。

そのため実装は、 「AIが考える → 人間が実環境で試す → 結果をAIへ返す → AIが修正案を出す」 という共同作業になります。

生成AIがコードを書けることと、現実の環境まで自動的に理解できることは別の問題です。

生成AIはテストケースをどう広げるのか

実装だけでなく、テストケースの洗い出しでも生成AIは大きな力を発揮しました。

AIは仕様を読みながら、複数の観点からテストケースを展開します。

  • 正常系：通常操作で正しく動くか
  • 異常系：不正な入力やエラー時にどうなるか
  • 境界値：0、1、上限値などで正しく動くか
  • 状態遷移：承認前・承認後・取消後など状態による違い
  • 権限：一般利用者・管理者などユーザー別の動作
  • データ条件：日付や営業日、データ有無などによる違い

第2回で要件を複数の判断軸に分解したのと同様に、 テスト工程では同じ仕様を「正常・異常・境界・状態・権限」といった別の方向から再び展開していきます。

ただし、AIが自動的に数学的な完全網羅を保証しているわけではありません。

AIはテストケースを「広げる」ことを得意としますが、 どこが重要なのか、どこまで確認すれば十分なのかは人間が判断する必要があります。

人間とAIで「テスト空間の地図」を共有する

今回の経験から、今後さらに有効だと考えているのが、 人間とAIで「テスト空間の地図」を共有する方法です。

まず、生成AIにテストの切り口を幅広く洗い出してもらいます。 たとえば、ステータス、権限、入力条件、データ状態、操作などです。

次に、それらの組み合わせを可視化し、 テストすべき領域の全体像を作ります。

その地図を人間が確認し、

  • 業務上そもそも成立しない組み合わせ
  • 同じ結果になるためまとめられる組み合わせ
  • 障害が起きた場合の影響が大きい重要領域

を判断します。

そして、残った重要領域について、 生成AIに境界値、異常系、状態遷移、必要に応じてペアワイズなどを使って詳細なテストケースへ展開してもらいます。

こうすることで、 AIは「広げる・細かくする」ことを担当し、 人間は「全体を見る・不要領域を除く・リスクを判断する」ことを担当できます。

また、 「なぜこのテストで十分だと判断したのか」 という質問に対しても、 どの領域を対象にし、何を除外し、どの方法で詳細化したのかを説明しやすくなります。

「テストが通った」＝「業務で使える」ではない

機能テストがすべて通ったとしても、それだけでシステムが業務で使えるとは限りません。

今回も最後には、スマートフォンを使って、

  • QRコードを読み取る
  • 写真を撮影する
  • 補充依頼を登録する
  • 管理側で処理する
  • 通知を確認する
  • 完了まで進める

という一連の業務シナリオテストを行いました。

その理由は、一つ一つの機能が正しく動いていても、 画面遷移が分かりにくい、操作順が不自然、スマートフォンでは入力しづらい、 といった問題が残っている可能性があるからです。

こうした問題は、実際の利用者が実際の環境で操作して初めて分かります。

つまり、AIがテストケースを作れることと、 AIがシステムの品質を保証できることは同じではありません。

「実際の業務が成立するか」という最終的な品質判断は、人間に残ります。

小規模業務アプリと本番システムは分けて考える

今回のような生成AIを活用した開発は、特に小規模な業務アプリとの相性が良いと考えられます。

たとえば、

  • 利用者が限定されている
  • 扱うデータ量が大きくない
  • 障害が起きた場合の影響が限定的
  • 業務改善用の試作やMVPとして利用する

といった領域です。

一方で、次のようなシステムは同じ感覚で進めるべきではありません。

  • 基幹システム
  • 停止すると生産に大きな影響が出るシステム
  • 外部顧客向けのサービス
  • 個人情報や重要データを大量に扱うシステム

本番システムとして運用する場合には、 セキュリティ、権限、バックアップ、監視、障害対応、性能、変更管理、保守体制など、 コード以外の品質も考える必要があります。

これは生成AIが役に立たないという意味ではありません。

AIによって作業時間を減らしながら、 専門家が設計・品質・運用の判断により多くの時間を使えるようにする。 この考え方の方が現実的です。

全3回の実証で見えたこと

全3回を通して、「生成AIで業務アプリをどこまで作れるのか」を検証してきました。

第1回：小規模な業務アプリは作れるのか

第1回では、QRコードを使った補充依頼システムを実際に開発し、 小規模な業務アプリであれば、生成AIを使ってかなり具体的な形まで作れることを確認しました。

第2回：企画・要件定義・設計ではどう使えるのか

第2回では、生成AIが論点を展開し、仕様を具体化し、成果物を作ることに強いことが分かりました。 一方で、何を選択するのかという意思決定や、全体方針との整合性を判断する役割は人間に残ります。

第3回：実装・テストではどう使えるのか

そして今回の第3回では、コードを書く作業やテストケースの展開も大幅に効率化できることを確認しました。

ただし、実環境での確認、システム全体の統合、テストの優先順位、業務として成立するかどうかの判断、 そして最終的な品質責任は、人間が担う必要があります。

生成AIは人間の仕事をなくすのではなく、仕事の中身を変える

全3回の実証を通して最も強く感じたのは、 生成AIは人間の仕事をすべてなくすものではない、ということです。

むしろ、人間の仕事の中から「作業」を大きく減らし、 「判断・検証・レビュー」の重要性を高めていくものだと考えています。

システム開発で言えば、

  • コードを書くことよりも、「何を作るのか」
  • 作れたことよりも、「本当に正しいのか」
  • 動くことよりも、「実際の業務で使えるのか」

といった問いに答えることが、これまで以上に重要になります。

まとめ

生成AIを活用することで、コード生成、修正、テストケース作成など、 システム開発における多くの作業を大幅に効率化できる可能性があります。

一方で、生成AIは実際の現場を自動的に理解できるわけではなく、 生成されたコードやテストケースが業務上正しいことを保証するわけでもありません。

人間が実環境で確認し、リスクを判断し、成果物をレビューし、 最終的な品質に責任を持つことは引き続き重要です。

生成AIは万能ではありません。 しかし、人間とAIが適切に役割分担すれば、 これまで費用対効果が合わず放置されていた“小さな業務課題”を解決するための強力なサポートツールになります。

生成AIは「作業」を減らし、人間が「何を作るのか」「本当に正しいのか」「業務で使えるのか」を考える時間を増やす。 それが、今回の全3回の実証を通じて得た一つの結論です。