Vibe codingの用途と限界

自由に作れる環境を用意する

企業のCTOは、より多くの人が業務の知識をソフトウェアのアイデアに変えられるよう支援できます。財務、運用、営業、エンジニアリングの各部門に参加を呼びかけます。時間、合成データ、sandbox API、支援を用意してください。

インストール、アカウント、入力してよい情報の範囲を明確にしたうえで、さまざまなツールで検証できるようにします。ブラウザー上のアプリ作成ツール、コーディング支援ツール、ローカルのエージェントでアイデアを試せます。ツールを選んだだけでは、会社の情報をアップロードしたり、本番システムに接続したりする許可は得られません。

有用な試作品をエンジニアリングチームやプラットフォームチームへ引き継ぐ簡単な手順を公開します。作成者は、解決したい問題、業務フローの例、確認できた価値を伝えます。作成者自身が、そのサービスのセキュリティチームや運用チームになる必要はありません。

何を確かめたいのかを明確にする

Vibe codingは通常、作りたいソフトウェアの説明から始まります。生成されたコードを受け入れ、画面上の結果を見て次の変更を指示します。この用語には複数の意味があります。このガイドでは、作業を指示する人が実装上の各判断を必ずしも理解していない進め方を指します。

この方法は学習に役立ちます。簡単な画面を作ると、承認プロセスの手順が多すぎると分かることがあります。一時的なスクリプトでファイル形式を評価できます。試作品があれば、具体的な設計について話し合えます。コードを廃棄しても、得られた知識は残せます。

まず、観察できる答えがある問いを設定します。例えば「チームのマネージャーは、この承認プロセスを理解できるか」です。この問いの範囲は明確です。一方、経費精算システムの開発依頼には、データ保護、アクセス制御、運用、責任の所在も含まれます。

火曜日に作った銀行アプリの試作品

架空の例を考えます。火曜日、財務担当者がLovableを使い、架空の銀行取引からダッシュボードを作りました。支出を分類し、未払いの請求書を表示します。これでチームは、有用な業務フローを検討できます。

誰かが会社の銀行口座への接続を提案します。アプリに「試作品」と表示されていても、接続すると失敗の影響が変わります。

APIによっては、読み取り権限で残高、取引履歴、顧客名、支払参照情報が見えます。支払いも許可する接続なら、誤動作で実際のお金が動く可能性があります。実際の権限範囲を確認してください。銀行への接続に、必ず支払権限が含まれるわけではありません。

デモだけでは、利用者が許可された口座だけを閲覧できるとは確認できません。ボタンを隠すだけでは、アクセス権限の制限を強制できません。OWASPは、口座やレコードの権限確認がないと他の利用者のデータが漏れる仕組みを説明しています。

支払APIの**冪等性（idempotency）**とは、同じリクエストを繰り返しても、意図した効果が重複しない性質です。Stripeはその実装例を説明しています。実際に使うプロバイダーの動作、制限、再試行の規則を確認してください。アプリをロールバックしても、銀行が処理済みの支払いは取り消されません。

この例は、Lovableの不具合を示すものではありません。Lovable自身のセキュリティガイドも、シークレットの保護、サーバー側の確認、データポリシーのテスト、継続的なレビューを求めています。どの作成ツール、エージェント、手書きのアプリにも、同じ証拠の基準を適用してください。

実システムに接続する前にアクセスを確認する

合成データとsandboxアカウントで業務フローのテストを続けます。本番にアクセスする前に、サービス、セキュリティ、プラットフォームの各責任者がアプリと実行環境を検証します。

銀行やプロバイダーが承認した接続手順を使います。必要な口座と権限だけを付与してください。非公開の認証情報は、プロンプトやブラウザーのコードに含めず、承認済みのシークレット保管先に置きます。支払いが必要なら、支払承認の担当と限度額を定めます。アクセスの取り消し、不具合の調査、不審な活動への対応方法を検証してください。

これらは、機密情報や本番の認証情報をシステムへ入れる前に決める必要があります。正式な本番リリースまで待つと、手遅れになることがあります。次にデータの境界と企業のITインフラを学んでください。

利用を広げる前に責任を決める

架空のデータを使う実験は、短期間かつ少人数で終わる場合があります。他の人がアプリに依存するようになったら、利用に伴う責任を定めます。

1. 責任者を決めます。
2. 利用を許可する人とデータを特定します。
3. 障害時の対応を決めます。
4. ソースコードと設定をリポジトリに保管します。
5. 別の人がシステムを調べ、再現できることを確認します。

すべてのスクリプトに企業向けプラットフォームが必要なわけではありません。機密データを扱わない個人用の整形ツールなら、支払承認アプリより少ない管理策で済みます。誤りの影響を評価してください。誤りを検出し、その影響を元に戻せるか確認します。

試作品の利用を広げる前に、問題について学んだことと、実装についての証拠を分けます。画面を残して内部のコードを置き換える方法もあります。用途を制限する方法もあります。一時的な実験として試作品を残すこともできます。

デモの後も脆弱性に対応する

デモが成功しても、保守に重大な抜けがあるかもしれません。コードを変更しなくても、依存関係について新しい脆弱性情報が公表されることがあります。リリース時のスキャンが示すのは、その時点の状態です。

アプリを使い続けるなら、脆弱性の発見、評価、修正を継続する担当者が必要です。修正は本番へ反映し、検証を完了しなければなりません。この対応プロセスがなければ、スキャナーがあっても脆弱性への曝露は解消されません。

実際のツールと設定で何が提供されるか確認してください。後の継続的な脆弱性管理で、スキャンの失敗やデプロイ済みバージョンを含む全体のプロセスを説明します。

次の変更をレビューしやすくする

明確な受入基準を示し、小さな変更を一つエージェントに依頼します。実行してよい操作を明記してください。変更差分を確認します。誤った実装を不合格にできる確認を実施します。リリースの責任が明確になるまでは、デプロイを別の判断として扱います。

NIST Secure Software Development Frameworkは、安全な開発のための幅広い実践を説明しています。不足する管理策を評価する際の参考にしてください。フレームワークを暗記する必要はありません。ソフトウェアが他の人に影響を与える前に、不足する証拠を特定する必要があります。