How large Japanese companies actually adopt AI coding tools

“The engineers love it. Now it has to get through security.” If you sell AI developer tools to large companies in Japan, you’ll hear some version of that sentence early, and it’s where most of the calendar goes.

I’ve worked with Japanese enterprise customers at Vercel since 2021, and more and more of that work involves v0, Vercel’s AI app builder. The order things happen in is consistent enough to write down, so here it is.

Curiosity comes first, and it’s the easy part

Adoption rarely starts with a purchasing decision. An engineer tries the tool on a personal account, or an executive sees a demo at an event, and a team asks whether they can use it at work. Nobody needs convincing that a working screen from a plain-language prompt is useful.

Then the request reaches the IT department (情シス) or the security team, and they send a security questionnaire (セキュリティチェックシート), usually an Excel file, which at a large company can run to a few hundred rows. This is where most pilots stall, and usually for a boring reason. The answers exist, but not in Japanese, and not in the shape of the sheet.

The security review

The rows vary from company to company, but five topics decide it. If you’re the vendor, have written answers to these in Japanese before the first demo, with a link to the policy page behind each one. If you’re the buyer, ask for exactly this:

• Data retention. How long are prompts, uploaded files and generated code kept? Can an admin delete them? What happens to them when the contract ends?
• Training. Are customer inputs or outputs used to train models, by the vendor or by the model provider behind it? Is that off by default or opt-out, and does it change by plan?
• Data location. Where is data stored, and where are prompts processed? Those are two separate questions: the app can be hosted in Tokyo while the model runs somewhere else. Ask for the list of subprocessors.
• SSO and provisioning. SAML single sign-on with the company’s identity provider, and ideally SCIM, so people who leave lose access the same day.
• Audit logs. Who created, shared or deployed what, and when; how long the logs are kept; whether they can be exported.

One more if personal data might end up in a prompt: Japan’s privacy law (個人情報保護法) has rules on handing personal data to a third party abroad, and someone will ask how the tool fits them. “It depends on your plan” is a fine answer, as long as you also say which plan they’re on.

The legal review wants Japanese

Security and legal (法務) usually run in parallel, and legal reads the terms line by line. English-only terms from a US company raise the same questions every time:

• Is there a Japanese version? Most vendors can offer a reference translation (参考訳) with the English text as the binding one. Say so upfront.
• Governing law and court. A US jurisdiction is often acceptable in the end, but not quickly.
• Who owns the generated code, and what happens if it infringes someone’s rights.
• The anti-social forces clause (反社条項), which Japanese contracts almost always include and US templates don’t.
• Payment by invoice and bank transfer in yen (請求書払い), not a card.

Then there’s the budget. Many Japanese companies run an April-to-March fiscal year and strongly prefer a fixed annual number. A seat-based subscription like v0 is easy: count the people. Usage-based billing needs a forecast and spend limits agreed in advance, or the first surprising invoice becomes the reason to stop.

A pilot team with a deadline, and a champion

A pilot with no deadline is a free trial that expires quietly. The ones that turn into adoption have a small team with a real deliverable, a date, and one person who reports back.

That person is the champion, and in a Japanese company much of their job is nemawashi (根回し, talking to each stakeholder before the formal decision). When the ringi (稟議, the approval document that circulates for sign-off) goes out, the people approving it should already have heard about the pilot from someone they trust. A vendor can’t do that part. What a vendor can do is keep the champion supplied with Japanese-language answers, office hours and examples they can show internally.

Keep the pilot to one team and one real project with an end date. Put at least one non-engineer on it (a PM, a designer, someone from the business side), name an owner on each side, and agree on day one what you’ll show at the end.

Hackathons compress months into a day

Hackathons look like community events, and they’re also the fastest adoption tool I know. I co-organized the Tokyo AI Hackathon with Anthropic, Raycast and Supabase, where more than 150 participants in 57 teams built Claude-powered Raycast extensions and MCP integrations in a single day.

A deadline and an audience teach prompting faster than any training session, and the demos at the end give a rollout what it needs: people who now believe in the tool, and working examples in the company’s own context that can go straight into the ringi. If you run one inside a company, set up accounts and SSO before the day, because nobody should spend the first hour on login. Pick a theme tied to real work. Have someone senior watch the demos.

Prototype requirements with v0

Requirements definition (要件定義) is where Japanese projects spend a lot of time, often with a system integrator, and often with stakeholders approving documents that describe screens they have never seen. I presented v0 at a webinar on AI and requirements definition hosted by DG Business Technology and ROUTE06, and it’s still the use case I’d start with.

Build a clickable version during the meeting and let the business side react to a screen instead of a spreadsheet. Treat the prototype as a question for the stakeholders: put screenshots and a link in the requirements document, and decide early whether any of the generated code will be kept. In an enterprise, it usually won’t be, and that’s fine.

Measure value without vanity numbers

Prompts sent, lines generated and seats assigned are easy to count and prove very little. Self-reported “hours saved” surveys aren’t much better. What I’d rather put in front of an executive:

• Time from the first meeting to a clickable prototype, before and after, on a real project.
• Requirement changes caught at the prototype stage instead of during development.
• Active users as a share of licensed users, month by month.
• How many people outside engineering built or changed something.
• What the pilot team says they’d refuse to give back.

One honest before-and-after on a real project is worth more than a dashboard of totals.

Prompting in Japanese

Let people prompt in the language they think in. Current models handle Japanese well, and mixing in English technical terms is how Japanese engineers talk anyway. What needs care is the output that people will read, so be explicit about language, register and typography:

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

That asks for an internal expense form: all copy in Japanese in the polite form, the name as family name and given name with a katakana reading for each, amounts in yen with thousands separators, and phrase-aware line breaks in headings. Each line covers something a model will otherwise leave to chance. (More on those details in Localization is not translation.)

Then have a native speaker read the generated copy. Keigo (honorific language) is easy to get slightly wrong, and slightly wrong keigo is what makes an internal tool feel foreign.