日本の大企業がAI開発ツールを導入するまで：ベンダー側から見た実際の流れ

「エンジニアはすごく気に入っています。あとはセキュリティ審査ですね」

日本の大企業にAI開発ツールを提案していると、早い段階でほぼ必ずこの一言を聞きます。そして、導入までにかかる時間の大半はここから先です。

私は2021年から、Vercelで日本の大企業のお客様を担当しています。入社時は社内初の日本語対応カスタマーサクセスとして、今は暫定カントリーマネージャーとして日本のGo-to-Market全体を見ています。最近は、VercelのAIアプリビルダーであるv0に関わる仕事がどんどん増えてきました。導入の流れにはかなりはっきりした型があるので、発注側とベンダー側の両方に初日から持っておいてほしいチェックリストと一緒に、ここにまとめておきます。

始まりは興味から。ここは簡単です

導入が購買の判断から始まることは、ほとんどありません。エンジニアが個人アカウントで試してみたり、役員がイベントでデモを見たりして、「これ、業務で使えませんか」という相談が出てきます。普通の言葉で指示するだけで動く画面ができるのですから、便利さを説明する必要はあまりありません。

その相談が情シスやセキュリティ部門に届くと、セキュリティチェックシートが送られてきます。多くはExcelで、大企業だと数百行になることもあります。PoCが止まるのはだいたいここで、理由は地味です。回答自体はあるのに、日本語になっていない、シートの形式に合っていない。それだけで話が止まってしまいます。

セキュリティ審査で聞かれること

項目は会社によって違いますが、結論を左右するのは次の5つです。ベンダー側なら、最初のデモの前に日本語の回答を書面で用意し、それぞれに根拠となるポリシーページのリンクを付けておきましょう。発注側なら、まさにこれを聞いてください。

データの保持期間。 プロンプト、アップロードしたファイル、生成されたコードはどのくらいの期間保存されるのか。管理者が削除できるのか。契約が終わったらどうなるのか。
学習への利用。 入力や出力が、ベンダー自身あるいはその裏にあるモデル提供元の学習に使われるのか。デフォルトでオフなのか、オプトアウトが必要なのか。プランによって違うのか。
データの保存場所。 データはどこに保存され、プロンプトはどこで処理されるのか。この2つは別の質問です。アプリが東京でホストされていても、モデルは別の国で動いていることがあります。再委託先（サブプロセッサー）の一覧も求めましょう。
SSOとアカウント管理。 社内のIdPとSAMLで連携できるシングルサインオン。できればSCIMにも対応していて、退職者のアクセスがその日のうちに止まること。
監査ログ。 誰がいつ何を作成・共有・デプロイしたか。ログの保存期間と、エクスポートの可否。

プロンプトに個人情報が入る可能性があるなら、もうひとつあります。個人情報保護法には外国にある第三者への提供についてのルールがあり、ツールがそれにどう当てはまるのかは必ず聞かれます。「プランによります」という答えでも構いませんが、その場合は、そのお客様がどのプランなのかまで答えてください。

法務は日本語の規約を求めます

セキュリティ審査と並行して、法務が利用規約を一行ずつ確認します。米国企業の英語だけの規約だと、毎回同じところが問題になります。

日本語版はあるか。多くのベンダーは、英語を正本とした参考訳なら出せます。最初からそう伝えておきましょう。
準拠法と管轄裁判所。米国の裁判所でも最終的には受け入れられることが多いものの、すんなりとはいきません。
生成されたコードの権利は誰にあるのか。第三者の権利を侵害していた場合はどうなるのか。
反社条項。日本の契約書にはほぼ必ず入っていますが、米国のひな形にはありません。
支払い方法。カードではなく、円建ての請求書払い（銀行振込）。

そして予算です。4月始まりの年度で予算を組む会社が多く、年間の金額が決まっている方がはるかに好まれます。v0のようなユーザー数課金のサブスクリプションなら話は簡単で、人数を数えれば済みます。従量課金の場合は、利用量の見込みと上限を事前に合意しておかないと、最初に届いた想定外の請求書が、そのまま「やめる理由」になってしまいます。

PoCには期限と推進役を

期限のないPoCは、いつの間にか終わっている無料トライアルと同じです。本導入につながるPoCには、実際の成果物を抱えた小さなチーム、終了日、そして社内に報告する担当者がそろっています。

この担当者が社内の推進役で、日本の会社ではその仕事の多くが根回しです。理想は、稟議が回り始めた時点で、承認する人たちがすでに信頼している誰かからPoCの話を聞いている状態です。ここはベンダーには手が出せません。ベンダーにできるのは、推進役が社内で使える材料を切らさないことです。日本語での回答、定期的な相談の場、社内で見せられる事例などです。

PoCのチェックリスト：

チームは1つ、実際の案件も1つ。終了日を決める。
エンジニア以外を最低1人入れる（PM、デザイナー、業務部門の人など）。
発注側とベンダー側、それぞれに担当者を決める。
最後に何を見せるのかを、初日に合意しておく。

ハッカソンは数か月分を1日に縮めます

ハッカソンはコミュニティイベントに見えますが、私の知る限り、導入を一番速く進める方法でもあります。Anthropic、Raycast、Supabaseと共同開催したTokyo AI Hackathonでは、150人以上が57チームに分かれ、Claudeを使ったRaycast拡張機能やMCP連携をたった1日で作り上げました。

締め切りと観客があると、どんな研修よりも早くプロンプトの書き方が身につきます。そして最後のデモから、導入に必要なものが手に入ります。ツールを本気で推してくれる人たちと、その会社の業務に即した、実際に動く例です。これはそのまま稟議書に貼れます。社内で開催するなら、アカウントとSSOの設定は前日までに済ませておきましょう（最初の1時間をログインで潰さないためです）。テーマは実際の業務に結びつけ、デモは役職の高い人に見てもらうのがおすすめです。

v0で要件定義をプロトタイプにする

日本のプロジェクトは要件定義に多くの時間をかけます。SIerと一緒に進めることも多く、関係者が見たこともない画面を文章で説明した資料を承認する、という場面がよくあります。私はDGビジネステクノロジーとROUTE06が主催した「AI×要件定義」のウェビナーでv0を紹介しましたが、日本の大企業で最初に試すなら、今でもこの使い方をおすすめします。

打ち合わせの場でクリックできる画面を作り、業務部門の人にはスプレッドシートではなく、その画面を見て反応してもらいます。プロトタイプは、関係者への「問いかけ」として扱ってください。スクリーンショットとリンクを要件定義書に貼り、生成したコードを本番で使うかどうかは早めに決めておきます。大企業ではたいてい使いませんが、それで問題ありません。

見栄えのいい数字に頼らずに価値を測る

送ったプロンプトの数、生成されたコードの行数、割り当てたライセンス数。どれも数えるのは簡単ですが、ほとんど何も証明しません。自己申告の「削減時間」アンケートも似たようなものです。役員に見せるなら、私はこちらを選びます。

最初の打ち合わせから、クリックできるプロトタイプができるまでの時間。実際の案件で、導入前と導入後を比べる。
開発に入ってからではなく、プロトタイプの段階で見つかった要件の変更。
契約ライセンスのうち、実際に使っている人の割合の月次推移。
エンジニア以外で、何かを作ったり変更したりした人の数。
PoCチームが「これは手放したくない」と言っているもの。

実際の案件ひとつ分の正直なビフォーアフターは、合計値を並べたダッシュボードより説得力があります。

日本語でプロンプトを書く

プロンプトは、普段考えている言語でそのまま書いてもらうのが一番です。最近のモデルは日本語をよく理解しますし、英語の技術用語が混ざるのは、日本のエンジニアの普段の話し方そのものです。気をつけたいのは、人が読む出力の方です。言語、文体、表記ははっきり指定しましょう。

社内向けの経費申請フォームを作ってください。
- 画面の文言はすべて日本語、です・ます調で
- 氏名は「姓」「名」とそれぞれのフリガナの4項目
- 金額は円表示、3桁区切り
- 見出しには word-break: auto-phrase を指定

どの行も、書いておかないとモデル任せになってしまう部分です（フリガナや改行についてはこちらの記事で詳しく書いています）。

最後に、生成された文言は必ず日本語ネイティブの人に読んでもらいましょう。敬語は少しずれやすく、そのわずかなずれが、社内ツールを「どこか海外製っぽい」ものに見せてしまいます。

ベンダーの方へ。セキュリティの回答は、聞かれる前に日本語で送っておきましょう。