バイブコーディングで「作れた」。何を確かめて、完成と言っているのか

事業責任者：AIで欲しかったシステムができた。外注するより安かった。「これ、自分たちだけで作れるじゃん」となる気持ちも分かります。ただ、その手応えから、設計やレビュー、保守まで自分たちだけで担えると判断するのは、相当危うい。

本人に専門家を軽視する意図がなくても、未確認のままレビューや保守を外すなら、起きていることは同じです。自分に見えていた機能ができたことで、見えていなかった仕事まで終わったことにしていませんか。

エンジニア代表：入力して、保存して、一覧で見る。そういうCRUDの画面は、かなり速く作れるようになりました。ただ、その画面の裏で、何を業務ルールとして決め、どの非機能要件を満たすのかは残ります。本人の要望に出ていなかった条件を洗い出すことも、要件定義や設計の仕事です。

事業責任者：その仕事を知らないまま、なくてもよかったと判断しているわけでしょう。作れたものは、自分が欲しかったものの形かもしれない。そこから、会社の情報や仕事を預けられるものになったと、何を根拠に言っているのか。今日はそこをはっきりさせたいです。

情シス：扱うものによって、確認する範囲も違います。架空のデータで画面を試し、本番の情報やアカウントから切り離す。その条件を確認して試せるなら、先に形にする価値はあります。そこへ顧客情報や更新権限を足したときに、試作のままの判断で進めてしまうのが問題です。

エンジニア代表：まず、APIのオブジェクト単位の認可と、テナント分離を見ます。ログインできた本人が、その契約を読んでよいか、変更してよいか。画面からボタンを消していても、API側で権限を検証していなければ、別の顧客のデータに触れられる可能性があります。

情シス：SSOを付けたから安心、という説明では足りないですね。RBACで役割を分けたとしても、顧客や部署の境界まで制限できているかは別です。DBのRLSを使う構成なら、ポリシーだけでなく、接続ロールがその制限をバイパスしないかも確認します。

エンジニア代表：入口ごとに、どの層で認可を強制しているかを追う必要があります。管理用の権限でDBへ接続する経路があれば、そこはどう制限するのか。別の顧客、別の権限でアクセスを試すところまで見ないと、境界が守られているとは言えません。

情シス：管理者権限のシークレットを、ブラウザ側へ渡していないかも見ます。公開用のキーと区別できているか。実装した本人が区別できないまま公開していたら、画面が正しく動くことは安心材料になりません。

事業責任者：ここまで確かめていないのに、「認証もAIが付けたので完成です」と業務へ持ち込む。それは、顧客情報を預けてよいという説明になっていません。分からないところを残したまま、分かる人を不要とする。その判断には、はっきりブレーキをかける必要があります。

情シス：「社内だけ」でも同じです。社員全員に同じ情報を見せてよいとは限らないし、退職や異動で権限を外す仕事も残る。社内という言葉で、認可設計やアカウント管理を省略できるわけではありません。

エンジニア代表：こちらは、成功したときより、失敗の仕方が気になります。会計側では登録済みなのに、応答が戻る前にタイムアウトしたらどうするか。送信側にエラーが出たことは、相手が処理していない証拠にはなりません。

情シス：現場が「失敗したなら、もう一度」と押したら、請求情報を二重に登録するかもしれない。逆に、怖くて押せなければ、登録されたかどうかを人が調べることになりますね。

エンジニア代表：そこで、APIの冪等性キー、業務上の一意性を守るユニーク制約、トランザクション境界を考えます。キーを付けるだけでも足りません。同じ処理のリトライで同じキーを使う設計か、相手のAPIがどの期間・範囲で重複を抑えるのかまで見ます。

情シス：自分のDBだけ整合していても、会計側の処理は取り消せない場合がありますよね。こちらをロールバックすれば全部元通り、とは言えない。

エンジニア代表：一つのDBトランザクションで、外部APIの処理まで一緒に確定できるとは限りません。部分成功をどう記録し、再実行や突き合わせで整合させるか。タイムアウト、リトライの競合、同時実行まで含めて結合テストをする。正常系が一回通っただけでは、この仕事は終わっていません。

「不具合が出たらAIで直す」と言っても、コードを直すことと、すでに会計側へ登録された情報を確認・訂正することは別の仕事です。その後始末を誰ができるか分からないまま、失敗時の設計を後回しにはできません。

事業責任者：こういう条件を詰めていた人の仕事は、きれいに動く画面には出てこない。でも使う側は、二重にならず、抜けずに処理されることを期待する。その期待を引き受けていた部分を、AIで画面ができたから不要になったと数えてはいけないですね。

情シス：ここでは、AIで開発したアプリに加えて、動作中のAIに情報を渡す条件も入ってきます。元の共有フォルダで閲覧権限を設定していても、コピーした検索インデックスやベクトルDBに、その制限がそのまま働くとは限りません。

エンジニア代表：RAGを組んで検索できた、で終わらせないということです。文書のACLをチャンクにも対応付け、検索時に利用者の権限でフィルタリングする。権限変更や文書削除を、インデックスへどう反映するかも決める。ここが抜けると、本人が元のフォルダでは開けない内容を、検索経由でLLMへ渡してしまうかもしれません。

情シス：渡した後で「見せないで」と指示すればよい、という扱いにはしたくないですね。検索結果の段階で何を渡せるかを制御する。そのうえで、取得した文書に紛れた指示による、間接プロンプトインジェクションも別に考えます。

エンジニア代表：RAGを付けても、読ませた文章をAIがどう扱うかという問題は残ります。接続したツールに送信や更新の権限があれば、誤った動作の影響も変わる。プロンプトだけに境界を任せず、ツール側の権限や実行可能な操作を絞る設計が要ります。

事業責任者：最初は、資料を探すのが便利になっただけだった。慣れてきて、「そのままメールも送って」「ついでに記録も更新して」と足していく。本人は改善のつもりでも、任せているものが変わっているんですよね。前にうまくいったことを、次の権限を渡してよい理由にしてはいけない。

情シス：OAuthスコープやサービスアカウントの権限も、その都度見直します。読み取り専用にすれば更新の影響は抑えられますが、読んだ情報を誰に返すかは残る。外付けのアシスタントという呼び方でも、どの情報に届き、どこへ出せるかでリスクは変わります。

事業責任者：ここまでの話に、「それも全部AIにチェックさせています」と返ってきたら、どうですか。分からないところはAIに直させたし、テストも通った。それなら、専門家を入れる理由はないと言われそうです。

エンジニア代表：チェックを使うことには賛成です。ただ、SAST、依存ライブラリの脆弱性スキャン、結合テストでは、見ているものが違います。何を対象にして、どんな条件を試した結果なのか。コードカバレッジが高くても、別テナントのデータにアクセスするテストがなければ、その境界を確かめたことにはなりません。

情シス：本番のIAMポリシー、シークレットの配布先、ネットワークの公開範囲。コードを見せたAIに、そこまで見えているとも限りません。実装だけを読んだ結果の「問題なし」を、そのまま稼働環境全体の評価にはできないです。

エンジニア代表：誰がどのデータを操作してよいか、どこで二重処理を防ぐか、どの失敗を許容するか。まず、そのシステムで守るべき条件が要る。その条件自体が抜けていたら、同じ前提で実装とテストを作らせても、抜けたところは残り得ます。別のAIへ聞き直すだけで解消するとは限りません。

事業責任者：確認すべきことも分からない。返ってきた回答が十分かも判断できない。それで「安全まで確認済み」として業務で使うのは、無責任です。AIから安心できる返事をもらったことを、自分が判断できるようになったことにしてはいけない。

エンジニア代表：人が一度見た場合も同じです。エンジニアが触ったという事実だけで保証にはならない。どの条件を、どの環境で、どう確かめたのかを説明する。私たちの側も、それを具体的に示せなければ、専門家という肩書を置いただけになります。

情シス：運用も、バックアップの設定があるだけでは終わりません。RPOとRTOを業務側と決めて、復元後のデータと業務の再開まで確かめる。どこまでのデータ損失を許容し、どれだけの停止時間に耐えられるのか。実際に戻したとき、その条件を満たせるかが問題です。

エンジニア代表：変更時の回帰テストやロールバック手順も残ります。最初のリリースで動いたことと、変更しながら使い続けられることは別です。こうした仕事がAIで短くなるのは歓迎します。でも、未実施のものは未実施として扱わなければいけない。

事業責任者：設計や検証、引き継ぎまで入った見積もりと、自分が払ったAIの利用料を比べて「こんなに削減できた」と言う。まだ誰もやっていない仕事を、なくせた仕事に混ぜるのはやめてほしい。あとで現場が手で直したり、情シスが調べたりするなら、その負担は会社に残っています。

情シス：上の立場の人が作ったものだと、現場が不安を言いにくいこともあります。使ってくれたことを、品質や運用への合意にしてはいけません。誰が面倒を見て、誰が止めるのか。そこが曖昧なままなら、利用者や接続先を増やす判断も、確認や保守の担当・予算を外す決裁も止める必要があります。

エンジニア代表：すでに業務が依存しているなら、停止したときの影響とデータ保全も見ます。いきなり消すのではなく、危険な操作を抑え、代わりの手順へ戻せるかを確認する。できている部分を活かしながら、足りない仕事を具体的にしていくのが次の作業です。

事業責任者：だから、私たちも「危ないから止める」で終わってはいけない。何が足りないかを見つけ、必要な仕事をAIも使って進め、使い続けられるところまで整える。作った、試した、導入した。その先を誰が担うのかまで決めることに、会社としてAIを使う意味があります。