バイブコーディングで作った社内ツールを本番で使う前に確認すること
バイブコーディングは、作りたいものを自然な言葉でAIに伝え、AIが書いたコードを細かく読まずに動かしながら仕上げていく作り方を指す言葉です。Claude CodeやCursorのようなAIコーディングツールの普及で、エンジニアでない社員が自分の業務に合わせた小さなツールを作れるようになりました。
集計の自動化、申請フォーム、顧客リストの管理画面など、バイブコーディングで作った社内ツールが、気づけば部署の毎日の業務に組み込まれていることも珍しくありません。作った本人にとっては便利な道具でも、他の人が使い、実際の顧客データが入り、止まると業務が困る状態になれば、それはもう本番のシステムです。
問題は、作るときには見えなかった論点が、本番で使い始めてから表に出ることです。誰でもアクセスできる状態になっていた、APIキーが画面のコードに埋め込まれていた、作った人が異動して誰も直せない、といった事態は、作り方ではなく運用の準備で防げます。
この記事では、バイブコーディングという言葉の出どころを確認したうえで、AIで作った社内ツールを本番で使う前に確認すべきこと（認証・権限、データの置き場所とバックアップ、秘密情報、保守する人）をチェックリストの形で整理し、開発会社に相談した方がよいサインも紹介します。
バイブコーディングの出どころと、業務で使うときの位置づけ
バイブコーディング（vibe coding）という言葉は、AI研究者のAndrej Karpathy氏が、2025年2月（日本時間では2月3日）にXへ投稿した文章の中で「私がバイブコーディングと呼ぶ新しい種類のコーディング」として紹介したものです。投稿では、雰囲気（vibes）に身を任せ、コードが存在することすら忘れる新しいコーディングだと説明し、AIの提案はいつも「すべて受け入れる」を押して差分を読まない、エラーが出たらそのままAIに貼り付ける、といった作り方を紹介していました。
注目したいのは、同じ投稿の中で、これは使い捨ての週末プロジェクトなら悪くない、と用途を限定していた点です。言葉はその後広く使われるようになり、英国のCollins辞書は「vibe coding」を2025年の「Word of the Year」に選んでいます。
業務で考えると、AIを使ってツールを作ること自体と、コードを読まずに作ることは分けて考える必要があります。前者はエンジニアでも日常的に行っている開発の手段の一つです。後者は、試作や自分だけの作業補助には向いていますが、他の人やデータを預かる用途では、作った後の確認が欠かせません。
| 使い方 | 例 | 本番利用の前に必要なこと |
|---|---|---|
| 自分だけの作業補助 | 手元のCSVを整形するスクリプト | 元データを壊さないこと、社外秘の情報をどのAIに入力したかの把握 |
| 部署内で共有するツール | 案件の進捗一覧、申請フォーム | この記事のチェックリスト全体 |
| 顧客や取引先の情報を扱う、社外からアクセスされる | 顧客向けの問い合わせ受付、取引先の発注画面 | チェックリストに加え、専門家によるコードとセキュリティの確認 |
参考：Andrej Karpathy氏の投稿（2025年2月3日）／X
参考：Collins’ Word of the Year 2025: AI meets authenticity as society shifts／Collins Dictionary
社内ツールが本番になったときに起きやすい問題
バイブコーディングで作ったツールは、作った人の画面で思いどおりに動いていれば完成したように見えます。しかし、本番で使い始めると、動作確認の段階では表に出なかった問題が起きやすくなります。よくあるのは次のようなものです。
- URLを知っていれば誰でも開ける状態で公開されていた
- ログインはあるが、全員が全データを閲覧・削除できる
- 外部サービスのAPIキーやデータベースのパスワードが、ブラウザから見えるコードに書かれていた
- データが作った人のパソコンや、個人で契約した無料のクラウドに置かれていた
- バックアップがなく、誤操作で消えたデータを戻せなかった
- 作った人が異動・退職し、エラーが出ても誰も直せなくなった
- AIが選んだ外部ライブラリが古いまま更新されず、脆弱性が放置された
どれも、作り方の巧拙というより、本番で使うための準備が抜けていることが原因です。AIは頼まれたものを作るのは得意ですが、頼まれていない「誰が見てよいか」「消えたらどうするか」までは、指示しなければ考慮してくれません。逆に言えば、確認すべき点を知っていれば、作った本人がAIに追加で指示して直せるものも多くあります。
自分のツールが「本番」に当たるかどうか迷う場合は、次の三つを考えてみてください。一つでも当てはまれば、本番として扱う方が安全です。
- 作った本人以外に、毎週のように使っている人がいる
- 顧客、取引先、従業員など、実在する人の情報が入っている
- 一日止まったら、誰かの業務が止まる、または手作業に戻さなければならない
反対に、どれにも当てはまらない試作の段階であれば、細かい確認は後回しにして、まず業務に役立つかを試すことを優先して構いません。確認の手間を最初からすべてにかけると、試してみる価値のある工夫まで止まってしまうためです。
本番で使う前に確認するチェックリスト
ここからは、部署内で共有する規模のツールを想定したチェックリストです。すべてに「はい」と答えられない項目があれば、その項目を直してから本番で使うか、使う範囲を限定します。
認証と権限
- ツールを開くにはログインが必要になっている
- ログインには会社のアカウント（Google WorkspaceやMicrosoft 365など）を使い、退職者は自動的に使えなくなる
- 閲覧だけの人、編集できる人、削除や設定変更ができる人が分かれている
- 画面のボタンを隠すだけでなく、サーバー側でも権限を確認している
- 誰がいつ何を変更したかの記録が残る
会社のアカウントでログインする仕組みにしておくと、入退社の管理を既存の手続きに任せられます。ツール専用のIDとパスワードを個別に配る形は、退職者のアカウントが残りやすいため避けた方が安全です。
データの置き場所とバックアップ
- データが会社の契約しているサービスや環境に置かれている（個人のパソコンや個人契約のクラウドではない）
- 個人情報や取引先の情報を扱う場合、その置き場所が社内の規程で認められている
- 定期的なバックアップがあり、実際に戻せることを一度試している
- 誤って削除したときに、どの時点まで戻せるかが分かっている
バックアップは取っているだけでは不十分です。戻す手順を一度試しておかないと、いざというときに戻せないことが分かる、ということが起こります。
秘密情報（APIキー・パスワード）
- APIキーやパスワードが、コードやブラウザで動く部分に直接書かれていない
- 秘密情報は環境変数や、クラウドの秘密情報管理の仕組みに置かれている
- コードを共有リポジトリに置く場合、過去の変更履歴にも秘密情報が残っていない
- 漏れたときに無効化して作り直す手順と、その担当者が決まっている
AIとのやり取りの中でAPIキーをそのまま貼り付けると、コードに書き込まれたり、会話の記録に残ったりします。秘密情報は会話に貼らず、置き場所だけをAIに伝えるのが基本です。
保守する人と変更の手順
- ツールの担当者と、その人が不在のときの代わりの人が決まっている
- コードが会社の管理する場所（社内のリポジトリなど）に保存されている
- 何のためのツールで、どのデータをどこから取っているかを書いた簡単な説明書がある
- 変更は本番とは別の環境で試してから反映している
- 使っている外部サービスの契約者と、費用の支払い方法が会社として把握されている
保守する人の問題は、作った直後には意識されにくい一方で、最も長く影響が残る論点です。作った人が説明書を書き、代わりの人と一緒に一度修正を試してみるだけでも、属人化の度合いは大きく下がります。
Claude Codeなどを業務で使うときに会社として決めること
バイブコーディングで社内ツールを作る人が増えると、個々のツールの確認だけでなく、AIコーディングツールの使い方そのものを会社として決める必要が出てきます。
たとえばAnthropicの料金ページ（2026年11月時点）では、Claude Codeは個人向けのProを含むすべての有料プランに含まれています。一方で、シングルサインオン（SSO）や一元的な請求管理は個人向けプランにはなく、法人向けのTeamやEnterpriseで提供されています。Team・Enterpriseでは、既定で入力内容をモデルの学習に使わない扱いになっており、Enterpriseでは監査ログやロールベースのアクセス管理も用意されています。社員が個人で契約したプランで業務のコードやデータを扱うと、こうした管理が効かない状態になります。料金やプランの内容は変わることがあるため、契約前に公式ページで確認してください。
会社として決めておきたいのは、次のような事項です。
| 決めること | 内容の例 |
|---|---|
| 使ってよいツールと契約 | 会社が契約した法人向けプランに限る。個人契約での業務利用は認めない |
| 入力してよい情報 | 顧客の個人情報や本番のデータベースの中身はAIに貼り付けない。必要ならテスト用データを使う |
| AIに与える権限 | 本番環境のパスワードや削除権限を持たせない。ファイル削除や外部への送信を伴う操作は人が確認してから実行する |
| コードの置き場所 | 会社が管理するリポジトリに保存し、個人のパソコンだけに置かない |
| 公開の承認 | 他部署や社外が使う形で公開する前に、情報システム担当か外部の専門家が確認する |
ルールは厳しすぎると、誰にも言わずに作る人が増えるだけです。「作るのは自由、共有して本番で使う前には確認を通す」という線の引き方にすると、現場の工夫を止めずにリスクを抑えやすくなります。
開発会社に相談した方がよいサイン
チェックリストの多くは、作った本人がAIに指示して直せます。ただし、次のような状態に当てはまる場合は、社内だけで抱えず、開発会社や外部のエンジニアに相談した方が安全です。
- 顧客や取引先の個人情報を扱う、または社外の人がアクセスする
- 決済、請求、在庫の引き当てなど、誤りがお金に直結する処理がある
- エラーをAIに直させるたびに別の場所が壊れ、修正が収束しない
- 利用者が増えて、表示が遅い、同時に更新するとデータがおかしくなる
- 作った人も、コードのどこで何をしているか説明できない
- 既存の基幹システムや会計システムとデータをやり取りしたい
相談するときは、画面の操作の流れ、扱っているデータの種類と件数、利用者の人数、コード一式、使っている外部サービスの一覧を用意しておくと、話が早く進みます。
相談の結果として取りうる選択肢は、主に三つです。
| 状況 | 選択肢 |
|---|---|
| 機能は足りていて、構成も大きくは崩れていない | コードとセキュリティを確認してもらい、問題箇所だけ補強する |
| 同じ用途の既製サービス（SaaS）が要件を満たす | ツールは試作と割り切り、既製サービスに移る |
| 業務の中核になっていて、データ量や利用者が増え続けている | 今のツールを仕様の見本として、設計からやり直して作り直す |
バイブコーディングで作ったツールは、作り直すことになっても無駄にはなりません。実際に使われた画面と業務の流れは、そのまま要件の見本になり、ゼロから要件を説明するより正確に意図が伝わります。
まとめ
バイブコーディングは、Karpathy氏が使い捨ての週末プロジェクトを念頭に紹介した作り方で、試作や個人の作業補助には大きな力を発揮します。ただし、他の人が使い、実際のデータが入り、止まると業務が困る状態になった社内ツールは、作り方にかかわらず本番のシステムとして扱う必要があります。
本番で使う前には、認証と権限、データの置き場所とバックアップ、秘密情報の扱い、保守する人と変更の手順を確認してください。あわせて、使ってよいAIツールと契約、入力してよい情報、AIに与える権限を会社として決めておくと、現場の工夫を止めずにリスクを抑えられます。
まずは社内で使われているAI製のツールを一覧にし、それぞれについてこの記事のチェックリストを当てはめてみることから始めるとよいでしょう。個人情報やお金に関わるもの、修正が収束しないものがあれば、早めに専門家の確認を受けてください。