2026/4/27

生成AI開発の進め方|PoCからプロトタイプ・本番までの全工程

システム開発にもAIが使われる時代に

生成AIは私たちのビジネスや生活において多くの変革をもたらしています。システム開発の現場でも生成AIが使われており、作業効率とコストが大幅に改善されています。

生成AIによって開発の手法がどれほど改善されても、実はシステム開発プロジェクトにおける「成果物が思ってたのと違う」という悲劇は起こり得るのです。今回は、生成AI時代にこそ発注者が把握しておくべきシステム開発の進め方について解説します。

AIが改善できること、人じゃないとできないこと

生成AIがシステム開発の作業を改善したというのは事実ですが、具体的にAIはシステム開発において何を改善できるのでしょうか。生成AIが貢献できる点の一つとして、開発初期段階においてプロンプト(指示文)から短期間で画面イメージやプロトタイプを作れてしまうことが挙げられます。これまでは人間が一からコードを書いていたのですが、その作業を今では生成AIがかなりの割合で代替してくれます。

一方で、開発の前段階となる「現場でどう使われるのか」というシナリオが間違っていれば、間違ったシステムが超高速で出来上がるだけになり、結果的に誰も使わないシステムを生み出してしまいます。システム開発が失敗して手戻りや炎上を起こす原因の多くは、「誰が何のために何をするのか」というユーザーシナリオ(ユーザーストーリー)が定義できていないことにあります。これに関して生成AIはアイデアの提案や整理に貢献できますが、社員がシステムをいつどのように使うかは人が決める必要があります。

したがって、AIが普及した今の時代でもシステム開発はユーザー目線で人間が設計しない限り、誰にも使われないシステムができてしまうのです。

シナリオを軸にした発注側のシステム開発の進め方

システム開発を成功させるためには、発注者自身がシナリオを用意し、開発チームと協力して検証を進める必要があります。

手順1:やりたいことのシナリオをリスト化する

まずは社内で「誰が、何をしたいのか」という要求をリストアップし、ビジネス的な優先度をつけます。これを作ることで、プロジェクトのテーマやゴールがブレにくくなるメリットがあります。そのリストを開発会社に持ち込み、技術的な実現性や、現場のユーザーが実際に使いこなせるかという目線でフィルタリング(絞り込み)を行います。

手順2:動くプロトタイプで早期にシナリオを検証する

続いて、開発の初期段階で動くプロトタイプ(試作品)を作成してもらいます。人間は言葉だけではシステムのイメージを正確に共有することが難しいため、画面を見ながら実際に自分の業務に各機能が合うか、想定したシナリオ通りに業務が進められるかを確認します。データは本番に近い「構造」のサンプルデータ(個人情報はマスキングまたはダミー化したもの)を使うと、より実践的なフィードバックができます。個人情報保護や情報セキュリティの観点から、プロトタイプ段階で実顧客情報を無加工で使うのは避けましょう。

手順3:シナリオをベースに共にテストを行う

ある程度開発が進んだら、想定されたシナリオを基にテストを実施します。開発ベンダーの多くは、言われた機能を作ることは得意でも、発注側のビジネスの背景や目的までは考えてくれません。そのため、システムをテストする際はベンダーに丸投げせず、発注側も一緒になってシナリオ通りの動きができるか確認することが重要です。

シナリオ駆動開発のチェックリスト

  • 誰が、何を、なぜ行うのかというシナリオ(背景)が言語化できているか
  • 言葉や静止画だけでなく、動くプロトタイプを使ってシナリオを検証しているか
  • ベンダー任せにせず、発注者自身もテストや動作確認に参加する体制があるか
機能リストだけ
  • バーコードを読み取る
  • 合計金額を表示する
  • 現金で会計する
  • レシートを印刷する

誰が・どんな状況で・どんな順序で使うかが不明。機能は正しく動いても現場では使えない。

シナリオで伝える

レジ担当者として、混雑時に会計列を止めないために、割引シールを貼った商品は1タップで単価変更したい。

また、現金とクーポン併用の会計も1画面で完結させたい。

返品対応は管理者呼出なしで処理したい。

誰が・いつ・どんな制約下で使うかが明確で、エンジニアが適切な設計を選べる。

シナリオ不在の失敗事例とシナリオ共有による成功事例

よくある失敗例:

ある中規模スーパーでレジシステムをリニューアルしました。発注者は「バーコードで商品を読み取り、合計金額を表示する」という基本機能だけを伝えていました。システム会社は機能としては正しく動くものを作りましたが、運用が始まると次々に問題が発覚しました。

  • 割引シールを貼った商品の単価変更に5タップ必要で、混雑時に2レーン分の行列が伸びた
  • 現金とクーポン併用の会計で画面遷移が3画面にまたがり、打ち直しが頻発した
  • 返品処理の導線が「管理者呼出」必須で、1件あたり3〜5分のロスが発生した

原因は、現場のオペレーターが「どんな場面で・どんな順序で・どんな割り込みを受けながら」使うかというシナリオが要件に含まれていなかったことでした。機能一覧は正しくても、シナリオが欠けると現場では使えないシステムになります。

成功例:

訪問看護事業所の記録システム開発では、単に機能のリストを渡すのではなく、「訪問看護師が利用者宅で、その場で看護記録をつけたい。なぜなら帰社してから30件分を思い出して記録すると記憶違いが起きるからだ」といった具体的なシナリオと背景を共有しました。これにより、エンジニアは「オフライン保存」「前回記録の自動呼び出し」「音声入力」など複数の技術選択肢を検討できるようになりました。さらにプロトタイプを実際の看護師に触ってもらい、車内での片手操作や訪問先のネットワーク環境まで確認した結果、現場に定着するシステムが完成しました。

まとめ

生成AIは人間より格段に優秀なはたらきをする時がありますが、あくまでも作業効率を高めてくれるツールです。下記のポイントを押さえながら、AI時代のシステム開発を成功させていきましょう。

  • 生成AI時代は開発が高速化するため、基盤となるシナリオ定義がより重要になる
  • 単なる機能一覧ではなく、ユーザーの振る舞い(誰が、何を、なぜ)を軸にする
  • 言葉の解釈ズレを防ぐため、動くプロトタイプでシナリオを検証する
  • 開発会社はビジネスの背景までくみ取らないため、発注側もテストに協力する

FAQ

Q1. シナリオ(ユーザーストーリー)はどこまで細かく書けばよいですか?

A. 発注側は「誰が・何を・なぜ」という主語と動詞のセットで主要シナリオを言語化することに集中してください。例外シナリオ(エラー時や離脱時など)の洗い出しはシステム会社がリードしてくれることが多いので、発注側が最初から全パターンを網羅する必要はありません。大切なのは、主要な業務フローの背景と目的をしっかり伝えることです。

この知識を実践してみませんか?

ゼロスタートなら、初期費用0円で動くプロトタイプを体験できます。