友人がAI／バイブコーディングで作ったアプリ「使ってみない？」、導入して問題ないかを整理しました

AIやバイブコーディングによって、業務をよく知る人が自分でアプリや業務システムを作れる時代になってきました。現場の不満や業務の細かな流れを理解している人が、そのまま仕組みに落とし込める。これは大きな変化ですし、既存のSaaSやパッケージを見直す流れも今後さらに強くなると思います。

ただし、企業が導入を検討する立場に立つと、別の論点が出てきます。

それは、「良いアプリかどうか」だけではなく、その案件をどう審査するかです。

特に、友人や知人、取引先など、関係性のある相手が作ったアプリには注意が必要です。こうした案件は、普通のベンダー提案よりも審査が甘くなりやすいからです。

なぜ知人案件は危ないのか

知人案件が危ない理由は、技術そのものより、導入判断のプロセスが崩れやすいことにあります。

話しやすいので確認を省略しやすい
相手を知っているので安心した気になりやすい
価格が柔軟そうで、正式手続きを飛ばしやすい
現場理解があるため、デモの印象が良くなりやすい
「まずは試すだけ」という言い訳で社内導入しやすい

要するに、知人案件は技術審査の前に、社内統制を緩めやすいのです。

企業として本当に注意すべきなのは、アプリの出来以上に、この「審査の緩み」です。

導入判断を感情で進めないための基本原則

まず前提として、知人案件でも、通常のベンダー提案と同じ土俵で扱うべきです。むしろ、感情が入りやすい分だけ、通常以上に手順を明確にしたほうがよいです。

最低限、次の原則は崩さないほうがよいです。

1. 提案者と審査者を分ける

現場で「使いたい」と思っている人が、そのまま導入判断までしてはいけません。少なくとも、別の視点で止められる人を入れるべきです。

2. PoCと本番導入を明確に分ける

「ちょっと試す」と「業務で使う」は別です。ここを曖昧にすると、PoCのつもりが実質本番になります。

3. 友人案件でも例外扱いしない

知人だから契約を簡単にする、確認を減らす、口約束で進める。これはやめるべきです。むしろ逆です。

企業側の審査フローはこう設計したほうがよい

知人が作ったアプリを受け入れる時は、最低限、次の順で見るべきです。

STEP1 提案の魅力ではなく、対象業務を確認する

最初に見るべきは、「便利そうか」ではなく、どの業務に入るのかです。

顧客管理、案件管理、見積、請求、勤怠、在庫など、業務の中心に近い領域なら、審査は厳しめにするべきです。逆に、補助的な社内ツールなら、限定利用の余地があります。

つまり、最初の分岐は「アプリの魅力」ではなく、「業務影響の大きさ」です。

STEP2 PoCで扱ってよい範囲を先に決める

PoCをするなら、始める前に線を引く必要があります。

何を試すのか
誰が使うのか
どのデータを入れてよいのか
どこまでが試験利用なのか
いつ終了判定をするのか
本番採用の条件は何か
中止時にどう戻すのか

これが決まっていないPoCは、単なる曖昧導入です。

STEP3 責任分界を確認する

知人案件で特に曖昧になりやすいのが責任分界です。

障害時は誰が対応するのか
何時まで連絡可能なのか
どこまで無償で対応するのか
仕様変更は誰が負担するのか
データ破損時の責任はどうなるのか

ここが曖昧だと、トラブル時に友情ではなく摩擦が残ります。

STEP4 保守体制と継続性を確認する

知人が一人で開発しているケースは多いです。そこが最大のリスクになることがあります。

確認すべきなのは次の点です。

保守担当は本人しかいないのか
ドキュメントはあるか
ソースや設定は引き継げる状態か
本人が忙しくなった時に止まらないか
継続開発の体制があるか

「何かあれば本人に聞けばよい」は、企業運用としては弱いです。

STEP5 データと権限の考え方を見る

導入側が最低限確認すべき論点は明確です。

データはどこに保存されるのか
バックアップはあるか
復元方法は決まっているか
認証はどうなっているか
権限は役割ごとに分けられるか
ログは残るか
退職者や異動者のアカウント管理は可能か

ここが曖昧なら、PoCの段階でも入れるデータをかなり絞るべきです。

STEP6 出口を確認する

導入時に見落とされがちですが、かなり重要です。

利用をやめる時、データはどう返却されるのか
他システムへ移行できるのか
どの形式でデータを出せるのか
途中解約時の条件はどうなるのか

出口がないシステムは、導入後に交渉力を失います。

PoCのつもりが本番化するのが最も危ない

知人案件で最も起きやすい失敗はこれです。

最初は試験導入のつもりだった。
一部メンバーだけで使う想定だった。
正式契約も、正式ルールも、まだだった。
しかし便利なので現場で広がった。
気づけば止められなくなった。

この流れは珍しくありません。

そして、この状態が一番危ないです。正式導入ではないのに、実務が依存している。責任分界は曖昧。管理者も不明確。障害時の対応も未定。これでは、システムの問題以前に、社内統制として弱いです。

こういう場合は導入を急がないほうがよい

次のどれかが曖昧なら、導入は急がないほうがよいです。

PoCと本番の線引きがない
保守担当者が開発者本人しかいない
データ保存場所とバックアップ方法が不明
権限管理とログ取得の考え方がない
契約終了時のデータ返却方法が決まっていない
顧客情報や案件情報を扱うのに責任分界が曖昧
現場責任者の判断だけで進もうとしている

便利そうに見えても、ここが曖昧なら業務導入としてはまだ早いです。

企業が守るべきなのは、関係性ではなく業務

知人が作ったアプリを導入する時に一番危ないのは、技術そのものより、確認を省略しやすいことです。

好意がある。
話しやすい。
安く始められる。
そうした条件は、むしろ審査を甘くします。

企業が守るべきなのは、友人関係ではなく業務です。便利そうだから入れるのではなく、社内の基準で通せるかどうかで決める。それができないなら、導入はまだ早いです。

ということで、友人がAI／バイブコーディングで作ったアプリを「使ってみない？」と言ってきた時に必要なのは、期待や好意ではなく、社内の審査フローを崩さないことだと思います。知人案件ほど、普通に審査する。むしろ少し厳しく見る。その姿勢が、結局は自社を守ります。