バイブコーディングで作った試作を、社内で本番運用するには。認証・権限・データ・環境・保守体制の5つの準備

社内で試作を見せたら好評で、「部署全体で使いたい」と言われたものの、そのまま広げてよいか迷っていませんか。

この記事では、バイブコーディング（Vibe Coding。AIに指示を出しながらコードを書かせる開発）で作った試作を、社内で本番運用するまでに整える5つの準備と、試作のコードを土台にするかの決め方を解説します。

試作と本番運用は何が違うのか？

違いは、使う人と直す人が別になることです。試作の段階では、作った本人が使い、困ったら本人がAIに頼んで直します。そのため、ログインが共有のパスワードでも、データが本人のパソコンにあっても、困る人がいません。

本番運用は、部署の数十人が毎日使い、止まると業務が止まる状態を指します。使う人は、作った人に頼らずにログインし、自分の分のデータだけを扱えなければなりません。作った本人が休んだり異動したりしても、別の人が直せなければなりません。

試作で確かめたのは「この画面と業務の流れで役に立つか」です。本番運用に移すときは、それに加えて、画面には出ない5つの準備（認証・権限・データ・環境・保守体制）が要ります。

試作のまま広げるとどうなるか？

試作のまま使う人を増やしても、しばらくは問題が表に出ません。困るのは、人が入れ替わったときと、何かが壊れたときです。

共有のパスワードでログインしていると、異動した人や退職した人も使い続けられます。誰がデータを書き換えたかも、後から追えません。データが作った人のパソコンや個人のアカウントにあると、その人が離れた時点で、部署のデータに誰も触れなくなります。

また、使われている試作をそのままAIに直させると、直している途中の状態が全員の画面に出ます。直した結果が壊れていれば、その時点で部署の業務が止まります。そのとき「誰に連絡すればよいか」が決まっていなければ、作った本人に連絡が集中します。

本番運用の前に整える5つの準備

1. ログインを会社のアカウントにそろえる（認証）

ログインには、社員が普段使っているGoogle WorkspaceやMicrosoft 365のアカウントを使います。この方式をシングルサインオン（SSO）と呼びます。会社のアカウントでログインする形にすると、退職でアカウントが止まった時点で、試作から作ったツールも使えなくなります。

共有のパスワードと、ツールの中だけで作った個別のアカウントは、本番運用の前にやめます。どちらも、人が入れ替わるたびに誰かが手で消す必要があり、消し忘れが残るためです。

2. 役割ごとに、見られる範囲と変えられる範囲を決める（権限）

使う人を、役割で2〜3種類に分けます。たとえば「自分の担当分だけを見て入力する人」「部署全体を見て承認する人」「設定を変える管理者」です。役割ごとに、どのデータを見られて、何を変えられるかを表にします。

表ができたら、役割の違うアカウントを2つ用意して、見えてはいけないデータが見えないかを試します。

3. データの置き場所と、戻し方を決める（データ）

部署のデータは、会社が契約しているデータベースやクラウドの保存先に置きます。作った人のパソコンや、個人のアカウントで作ったスプレッドシートには置きません。

置き場所が決まったら、次の3つを決めます。

• バックアップの頻度。毎日なのか、更新のたびなのか
• 戻し方。誤って消したときに、誰がどの手順で前日の状態に戻すか
• 社外に送るデータの範囲。ツールの中で生成AIのAPIを呼んでいるなら、個人情報や取引先の情報を送ってよいか

戻し方は、決めるだけでなく一度試します。バックアップがあっても、戻す手順を誰も知らなければ、消えたときに使えません。

4. 試す場所と、使う場所を分ける（環境）

部署が毎日使う場所（本番環境）とは別に、直したものを先に試す場所（検証環境）を用意します。 AIに直させるのは検証環境のほうで、そこで動きを確かめてから本番環境へ移します。

本番環境へ移す操作は、決まった人が行います。移したあとに不具合が見つかったときに、前の版へ戻す手順も用意しておきます。こうしておくと、直している途中の状態が部署の画面に出なくなります。

5. 直す人と、困ったときの窓口を決める（保守体制）

次の3つを、本番運用の前に決めます。

• 直す人。不具合を直し、機能の追加を引き受けるのは誰か。作った本人なのか、情報システム部門なのか、外部の会社なのか
• 窓口。使っている人が「動かない」「こうしてほしい」と伝える先。作った本人の個人チャットにしない
• 止まったときの連絡。業務が止まったときに、誰に連絡し、何時間以内に誰が対応を始めるか

試作を作った人が引き続き直す場合も、仕様と直し方を書き残し、2人目が直せる状態にしておきます。

試作のコードは、そのまま本番に使えるのか？

使えるかどうかは、コードを読んでから決めます。画面の構成や業務の流れは、試作で確かめたものをそのまま引き継げます。一方、認証とデータの置き場所は、試作の段階では仮の作りになっていることが多く、後から差し替えるとツール全体に手が入ります。

判断には、エンジニアに次の2つを確かめてもらいます。

• 認証とデータの置き場所を差し替えられる作りか。差し替えが一部の修正で済むなら、試作を土台に育てます
• AIが書いたコードを、別の人が読んで直せるか。同じ処理があちこちに書かれ、直す箇所を追えないなら、試作は仕様書として使い、本番用に作り直します

作り直す場合でも、試作は無駄になりません。「この画面で、この順番で入力すれば業務が回る」という確認は、すでに済んでいます。作り直しの判断の進め方は、GAS・マクロ・PowerAppsのツールを直し続けるか作り直すかでも扱っています。

まとめ

1. 社員の会社アカウントでログインする形（SSO）にしましょう。
   共有のパスワードと、ツールの中だけで作った個別のアカウントをやめます。
2. 役割ごとに見られる範囲と変えられる範囲を表にし、2つのアカウントで試しましょう。
   見えてはいけないデータが見えないかを確かめます。
3. データを会社の保存先に移し、バックアップから戻す手順を一度試しましょう。
   生成AIに送ってよいデータの範囲も決めます。
4. 検証環境を用意し、直したものはそこで確かめてから本番環境へ移しましょう。
   前の版へ戻す手順も用意します。
5. 直す人・窓口・止まったときの連絡を決め、試作のコードを土台にするかをエンジニアに確かめてもらいましょう。
   作った本人がいなくても直せる状態が、本番運用の前提になります。

弊社では、Vibe Codingでつくられたコードのレビューと保守から、本番運用に向けた作り直しまでを行っています。試作を部署に広げる前に確かめたい箇所があれば、お気軽にご相談ください。