画面ができた。それで、エンジニアの仕事まで終わったことにするな

問い合わせを登録し、担当者を割り当て、履歴を検索する。欲しかった画面が、AIとのやり取りでその日のうちに動いた。何度か自分で入力してみても、思ったとおりに使える。「これなら、明日から同僚にも使ってもらえそうだ」。そこで、もう一度立ち止まってください。

早く形にできたのは、確かな成果です。実物があれば、使い勝手を確かめ、欲しい機能を話し合えます。ただ、自分が仮のデータで試せたことと、他の人の情報を預かって仕事を続けられることは、同じではありません。

できた機能の中に、まだ確かめていない仕事まで「終わったもの」として混ぜないでください。

この記事は、作ることをやめるためではなく、次に何を確かめれば使える範囲を広げられるか、その見取り図を持つための記事です。

画面が動いた。その成果に、まだ終わっていない仕事を混ぜない

問い合わせ管理の試作品で、登録、検索、担当変更が一度ずつ成功したとします。そこで確認できたのは、その利用者、そのデータ、その操作順、その環境で期待した結果が返ったことです。試作としては十分な成果ですが、他の人と実際の業務で使う条件まで、一緒に確かめたことにはなりません。

ここで大切なのは、成功を小さく言うことではありません。「何ができたか」と「どの条件まで確認したか」を分けることです。この区別がなければ、試作の成功が、まだ試していない人やデータへ使い始める理由に変わってしまいます。

違う人が使う、失敗する、止まる。そのときの仕事は残っている

たとえば、自分には見えてよい問い合わせでも、別の部署の人に同じように見えてよいとは限りません。画面からボタンを隠しただけで、情報を取得する別の経路まで閉じたかは分かりません。「誰が何を見て、何を変更してよいか」を決め、その条件で確かめる仕事が残ります。

外部への返信にも、画面だけでは分からない状態があります。顧客には届いたのに、手元には「未送信」と残った。もう一度押せば、二通目が届くかもしれません。必要なのは表示の修正だけでなく、どこまで処理が終わったかを調べ、重複や取りこぼしを見つけ、訂正する方法です。

そして、今日の自分が直せることは、来月の同僚が直せる証拠ではありません。設定の場所、変更の理由、問題の見つけ方、止め方、戻し方が本人の記憶だけにあるなら、不在の日にはそこが仕事の行き止まりになります。

「作る」の中には、動く機能を用意する仕事と、動かしてよい条件を決め、確かめ、使い続けられるようにする仕事があります。 エンジニアの仕事を代替できたと言うなら、画面に出ない後者も、何が誰に移ったのかを説明する必要があります。

全部を一人で身につけろ、という意味ではありません。AIや利用サービスが担う部分も、他の人に支援してもらう部分もあります。ただし、「その仕事を担う設計がある」と「その設計が働くと確かめた」は別です。担当者の肩書も、AIの「対応済み」という返答も、確認結果の代わりにはなりません。

「後でAIに直してもらう」で進めてよい範囲を分ける

架空のデータを使い、外部へ送信せず、元へ戻せる試作なら、触って問題を見つけ、すぐ直す進め方が役立ちます。一方で、実際の顧客情報を表示する、メールを送る、他のシステムの記録を更新する場合、修正を頼むより先に結果が相手へ届きます。

漏れた情報は、コードを直しても回収できません。相手側で完了した処理は、手元の画面を戻しても消えません。異常に気づく方法がなければ、修正が必要だと分かるきっかけもありません。

次の操作に進む前に、自分がこれから何を増やすのかを見てください。

• 実データを入れるなら、送信先と、そこへ入れてよい情報を確かめる。
• 他の人に使ってもらうなら、その人の権限で見える情報と実行できる操作を試す。
• 外部への送信や更新をつなぐなら、途中で失敗した結果をどう調べ、訂正するかを確かめる。
• 自分以外へ引き継ぐなら、その人が設定を確認し、困ったときに連絡・停止できるかを確かめる。

これはすべてのアプリに同じ試験を課す一覧ではありません。次に広げる範囲から、必要な確認を選ぶための例です。業務上の許可が要る操作や、自分では影響を判断できない設定は、権限を持つ担当者と確認します。

分からないまま本番へ進まないことと、分からないから作るのをやめることは、違います。

研究の「91％」は、自分の確認を省く理由にも脅す数字にも使わない

2026年9月5日付のarXiv第3版「Understanding the (In)Security of Vibe-Coded Applications」は、GitHubから一定の基準で9,041件のバイブコーディング・アプリを特定しました。8,695件のWebアプリのうち、公開稼働を確認した984件から200件を無作為に抽出し、182件で少なくとも一つの脆弱性を報告しています。方法と結果は研究本文 で確認できます。

この結果を「AIで作ったアプリの91％は危険」と言い換えてはいけません。対象は特定の開発手段と選定基準に合う公開アプリで、人が作った同条件のアプリとの比較ではありません。自社で事故が起きる確率や、AIだけが原因だという因果関係も示していません。

それでも、公開されて実際に動いていたアプリを別の観点で調べると、アクセス制御、認証、入力の扱いなどに弱点が見つかったという事実は残ります。「動いた」「公開できた」「AIへ安全性も指示した」は、確認を終える根拠にはなりません。

NISTのSecure Software Development Framework 1.1 も、安全なソフトウェア開発を、実装時の一度の検査だけでなく、設計、レビュー、実行コードの検証、部品の来歴、公開後の脆弱性対応を含む仕事として整理しています。これは個別のAIアプリの安全を保証するものではなく、何を開発と運用の仕事に含めるかを話すための共通枠組みです。

自分で確かめることと、支援が必要なことを分けて先へ進む

次に機能を足す前に、作れたものの隣へ三つの欄を作ってください。「できた機能」「実際に確認した条件」「まだ確かめていない仕事」です。

たとえば、問い合わせ登録はできた。一人の試験アカウントで、架空の情報を登録・検索した。別部署からの閲覧、通信が切れた後の再送、自分が不在のときの管理は未確認。この書き方なら、成功を捨てずに、まだ同僚へ広げてはいけない理由と、次に頼みたい確認を示せます。

自分で試せる条件は、業務へ影響しない環境で確かめます。誰の情報を見せてよいかは、その情報を管理する人へ確認します。試験の組み方や失敗の影響を判断できなければ、対象の画面・設定・試した結果を添えて、詳しい人へ相談します。「全部見てください」より、何が分からないかを渡すほうが、支援を受けやすくなります。

費用や時間を報告する場合も同じです。AIで短くできた作業と、他の人やサービスへ移った作業と、まだ誰もしていない作業を分けます。未着手の確認や保守を、削減できた仕事へ数えてはいけません。

作れたことは、次を確かめるための足場です。次に機能を足す前に、まだ終わっていない仕事を一つ、見えるところへ出してください。

参考資料

• Understanding the (In)Security of Vibe-Coded Applications（arXiv第3版） 
• NIST SP 800-218：Secure Software Development Framework