生成AIで作ったモック、
本番に出す前に確認したい15のこと

生成AIを使えば、画面が動くところまでは短い時間でつくれるようになりました。ただ、「動く」と「本番で安心して使える」の間には、まだいくつもの確認ポイントがあります。この記事では、モックを社内や顧客向けに公開する前に確かめておきたいことを、5つの観点・15項目のチェックリストにまとめました。あわせて、どこから手を付けるかの優先順位と、モックを活かして本番化する進め方もご紹介します。

「動く」と「本番で使える」のあいだにあるもの

生成AIを使えば、画面の見た目や基本的な操作は、驚くほど短い時間で形にできるようになりました。社内の担当者が自分で業務の画面をつくり、「これをそのまま使えないか」と考えるのは自然な流れです。

ただ、モックで見えているのは、システム全体のほんの一部です。実際に毎日使うには、誰が使えるのか、データはどこに残るのか、壊れたときにどう戻すのか、といった「見えない部分」が欠かせません。ここが欠けたまま公開すると、情報が見えてはいけない人に見えてしまったり、ある日データが消えてしまったりといった事故につながります。

見えない部分は、作った本人が気づきにくいところでもあります。モックは「動くこと」を確かめるためにつくるものなので、使う人が増えたときのこと、問題が起きたときのことまでは考えられていないのが普通です。それはモックの欠点ではなく、役割の違いです。

このコラムでは、見えない部分を5つの観点・15項目に分けて整理しました。上から順に読み、当てはまらない項目に印を付けていけば、今のモックに何が足りないかが分かるようにしています。

1. 認証と権限

最初に確かめたいのは、「誰が使えるのか」と「何ができるのか」です。モックは作った本人が試すことを前提にしているため、ログインがなかったり、全員が同じ操作をできたりすることがよくあります。社内向けでも、退職した人や別部署の人が見られてしまう状態は避けなければなりません。

• ログインの仕組みがある

  URLを知っていれば誰でも使える状態になっていないか。パスワードはそのまま保存せず、安全な形に変換して保存しているか。何度も失敗したときに、ログインを一時的に止める仕組みがあるかも確かめます。

• 役割ごとに「できること」が分かれている

  管理者・担当者・閲覧のみなど、役割によって見られる情報と操作を分けているか。役割は最初から細かくしすぎず、実際の業務に合わせて少ない数から始めるのが扱いやすい形です。

• 画面を隠すだけで済ませていない

  ボタンを非表示にしても、直接アクセスすれば操作できてしまう作りになっていないか。権限の確認は、画面ではなくサーバー側で行う必要があります。

役割と操作を表にしてみる

権限を整理するときは、役割と操作を表にすると抜けが見つかりやすくなります。たとえば、次のような簡単な表です。

2. データ

モックでは、データが画面の中だけに一時的にあったり、作った人の手元のファイルに保存されていたりすることがあります。本番で使うなら、データは決まった場所に保存し、誰が管理し、どう守るかを決めておく必要があります。

• データの保存先が決まっている

  画面の中や手元のファイルだけにデータがある状態ではないか。どこに保存し、誰が管理するのかを決めます。あとから変えにくい項目の設計ほど、最初に時間をかける価値があります。

• 入力内容をチェックしている

  必須項目の抜けや形式の誤りを、画面とサーバーの両方で確かめているか。画面だけのチェックは、少し工夫すれば通り抜けられてしまいます。

• バックアップと復旧の手順がある

  誤って消した、壊れたというときに、どこまで戻せるかを決めているか。バックアップは「取っている」だけでなく、実際に戻せることを一度試しておくと安心です。

3. セキュリティ

生成AIでつくったコードには、動かすために必要な鍵やパスワードが、そのまま書き込まれていることがあります。また、便利な部品（ライブラリ）を多く使うぶん、古いものが混ざっていないかの確認も欠かせません。

• 秘密情報がコードに書かれていない

  APIキーやパスワードが、コードや画面から見える場所に含まれていないか。秘密情報はコードとは別の場所で管理し、必要な環境にだけ渡すのが基本です。

• 使っているライブラリが更新されている

  古いままのライブラリに、既知の脆弱性が残っていないか。公開前に一度洗い出し、その後も定期的に確かめる仕組みをつくります。

• 個人情報の扱いを決めている

  どの情報を持つのか、誰が見られるのか、いつ消すのかを整理しているか。必要のない情報は、そもそも持たないのがいちばん安全です。

4. 品質とテスト

作った直後は動いていても、機能を足したり直したりするうちに、別の場所が壊れることがあります。人が毎回すべてを手で確かめるのは現実的ではないため、大事な操作は自動で確かめられるようにしておきます。

• 主要な操作に自動テストがある

  登録・更新・削除など大事な操作を、変更のたびに確かめられるか。すべてを一度にそろえる必要はなく、影響の大きい操作から順に増やしていきます。

• うまくいかないときの動きを決めている

  通信が切れた、入力が多すぎたといったときに、利用者が迷わない作りになっているか。エラーの画面に「次に何をすればよいか」が書かれているだけでも、問い合わせはぐっと減ります。

• 本番と同じ環境で試せる

  本番に出す前に確かめられる、ステージング環境があるか。本番で初めて動かすのではなく、同じ条件の場所で触ってから公開します。

5. 運用と引き継ぎ

公開はゴールではなく、使われ始めるスタートです。使っていくうちに、不具合が見つかったり、要望が出てきたりします。そのときに困らないよう、戻す・追う・引き継ぐの3つを用意しておきます。

• 変更を元に戻せる

  不具合が出たときに、ひとつ前の状態へ戻す方法があるか。戻せると分かっているだけで、改善のための変更にも踏み切りやすくなります。

• 動きを記録している

  エラーやアクセスの記録が残り、問題が起きたときに原因を追えるか。記録がないと、「何が起きたのか」を調べるところから始めることになります。

• 仕様が文書に残っている

  つくった人がいなくても、何がどう動くのかを確かめられるか。生成AIでつくったものほど、作った本人も細部を覚えていないことがあります。

本番化でよく起きる3つのつまずき

つまずき1：見た目を整えることから始めてしまう

モックを見せると、最初に出てくる要望の多くは、色や配置、文言といった見た目のことです。もちろん大切ですが、権限やデータの設計を後回しにして見た目を作り込むと、あとで裏側を直すときに画面も作り直すことになりがちです。順番は、裏側の土台を固めてから、見た目を仕上げるのが効率的です。

つまずき2：一部の人だけで公開を決めてしまう

作った担当者だけが確かめて公開すると、実際に使う人の業務に合わない部分が残りやすくなります。公開の前に、実際に使う人に本番と同じ環境で触ってもらい、「いつもの仕事がこの画面で回るか」を確かめておきましょう。

つまずき3：公開したあとの担当者が決まっていない

公開したあと、不具合の連絡や改善の要望を誰が受けて、誰が直すのかが決まっていないと、システムはすぐに止まった状態になります。公開前に、窓口と直す人、そして変更をどう反映するかの流れを決めておくことが大切です。

公開当日に確かめたいこと

準備が整っても、公開当日に慌てないように、最後に確かめておきたいことがあります。チェックリストの内容とあわせて、次の点を確認しておくと安心です。

• 本番環境に、テスト用のデータや仮の設定が残っていない
• 最初に使う人のアカウントと権限が、正しく用意されている
• バックアップが取れていて、戻し方を担当者が知っている
• 困ったときの問い合わせ先が、使う人に伝わっている
• 公開直後に動きを見守る担当者と時間を決めている

どこから手を付けるか：優先順位の付け方

15項目すべてに、最初から完璧に対応できている必要はありません。大切なのは、足りないところを把握したうえで、影響の大きいものから順に埋めていくことです。目安として、次の3つの段階に分けて考えると整理しやすくなります。

なかでも、ログイン・権限（画面だけでなくサーバー側での確認を含む）・データの保存先・秘密情報は、公開前に必ず確かめておきたい項目です。ここに不安があるまま公開するのは避けましょう。個人情報の扱いやバックアップも、公開までには整えておきます。一方で、自動テストや仕様の文書化は、使い始めてからも少しずつ増やしていけます。

モックを活かして本番化する進め方

モックは「捨てるもの」ではありません。画面の流れや項目の考え方には、業務を知っている人の判断が詰まっています。本番化では、見た目や操作の流れをできるだけ保ちながら、裏側を本番に耐える形へ置き換えていくのが効率的です。

EVOLOOPのモックの本番化では、お手元のモックや資料を共有いただき、このチェックリストの観点で足りないことを一緒に整理するところから始めます。AIが調査・実装・テストを速く進め、権限やデータ設計などの要所は人が確かめてから、ステージングでご確認いただき本番に反映します。

よくある質問

まとめ