バイブコーディングを業務で使うときの注意 試作には向くが、公開の前に人が確かめる

自社の「基盤とセキュリティ」の準備度は？10問・約3分で確かめる（無料・登録不要）

生成AIの進歩で、プログラムを書いた経験がない人でも、「こんな画面がほしい」と頼むだけで、動くアプリを作れるようになってきました。このような作り方は、バイブコーディングと呼ばれています。現場の困りごとを、現場の人が自分で解決できる可能性が広がる一方、会社として気をつけたい点もあります。この記事では、業務でバイブコーディングを使うときの考え方を整理します。

バイブコーディングは、どんな場面に向いていますか？

バイブコーディングの強みは、考えたことをすぐに形にできることです。たとえば、次のような場面で役立ちます。

• 試作：新しい業務の道具やサービスの画面を、まず動く形にして関係者と話し合う
• 個人の作業の効率化：表の整形やファイルの名前の付け替えなど、くり返しの作業を自動にする
• 限られた人だけが使う社内の道具：部署の中だけで使う集計や入力の補助

これらに共通するのは、使う人が限られ、問題が起きても影響が小さく、すぐに直したり使うのをやめたりできることです。

反対に、社外の人が使うWebサイトやアプリ、個人情報や取引の情報を扱う仕組み、社内の基幹のシステムにつながる仕組みは、そのままでは向いていません。動いているように見えても、中身に問題が隠れていることがあるためです。

AIが作ったプログラムには、どんな問題が潜みやすいですか？

AIが作るプログラムは、頼んだとおりに動くことを優先して作られがちです。そのため、次のような点が手薄になることがあります。

• 入力された値をそのまま使ってしまい、外部から想定外の操作をされる
• ログインや権限の確かめ方が甘く、本来見られない情報が見えてしまう
• パスワードや接続のための鍵を、プログラムの中に書き込んでしまう
• 古い部品や、使っていない機能が残ったままになる

IPA（情報処理推進機構）の「安全なウェブサイトの作り方」は、届け出の多い脆弱性や影響の大きい脆弱性を取り上げた資料です。SQLインジェクション、OSコマンド・インジェクション、クロスサイト・スクリプティング、CSRF、セッション管理の不備など11種類の脆弱性について、根本的な解決策と影響を抑える対策を示しています。AIが作ったプログラムを確かめるときも、こうした資料を物差しにすると、見るべき点がはっきりします。

公開した後の運用も大切です。IPAの「安全なウェブサイトの運用管理に向けての20ヶ条」では、不要なファイルやページを公開しないこと、ソフトウェアを更新すること、ログを確かめること、通信を暗号化すること、定期的に脆弱性診断を受けることなどが挙げられています。作って終わりではなく、誰が保守するのかまで決めておく必要があります。

国の「AI事業者ガイドライン（第1.2版）」でも、AIを使う側の会社には、出力の精度とリスクの程度を理解し、確かめたうえで使うことが求められています。AIが作ったプログラムも、AIの出力の一つです。

会社として、何を決めておけばよいですか？

現場の工夫を止めずに、問題を防ぐために、次の4つを決めておくとよいでしょう。

1. 作ってよい範囲：個人の試作や部署の中の道具は自由に作ってよい、社外に出すものは手続きを経る、といった線を引く
2. 使ってよいツールとデータ：会社が認めたAIのツールを使い、本番の個人情報や機密情報を試作に使わない
3. 公開の前の確認：社外に公開するもの、個人情報やお金を扱うもの、基幹のシステムにつなぐものは、技術がわかる人がコードを確かめ、必要に応じて脆弱性診断を受ける
4. 登録と保守の担当：作った道具を一覧にし、誰が保守するかを決める。作った人が異動や退職をしても止まらないようにする

社員が会社の知らないところでAIのツールやアプリを使う状態は、いわゆるシャドーAIの一つでもあります。禁止するよりも、安心して使える道と手続きを用意するほうが、結果として管理しやすくなります。ソフトウェア開発全体でのAIの使い方は、ソフトウェア開発へのAIの使い方と注意、自社のAIアプリの確かめ方は自社のAIアプリのセキュリティの確かめ方をご覧ください。

作った道具は、どう育てていけばよいですか？

バイブコーディングで作った道具は、使われるうちに「もっとこうしたい」という要望が増えていきます。最初は個人の試作だったものが、気づけば部署全体の仕事を支えている、ということもあります。

そのため、使う人や扱う情報が増えたときには、作った道具の位置づけを見直す場面を設けておくと安心です。たとえば、次のようなときが見直しの合図になります。

• 使う人が、作った本人以外にも広がったとき
• 個人情報や取引先の情報を扱うようになったとき
• 社外の人が見る画面や、ほかのシステムとのつながりが加わったとき

こうしたときは、技術がわかる人に中身を確かめてもらい、必要であれば作り直しや、正式なシステムへの置き換えも検討します。試作でわかった「現場で本当に必要な機能」は、正式なシステムを作るときの要件として役立ちます。バイブコーディングを、現場の声を形にして確かめる手段として位置づけると、会社としての生かし方が見えてきます。