An AI framework
for an entire OSOS全体のための
AIフレームワーク
As AI UX Lead, I authored the org-wide ChromeOS AI UX Guide: the privacy, conversational-UX, and pattern-library spine that every generative AI feature in ChromeOS now ships against.AI UXリードとして、組織全体で運用されるChromeOS AI UXガイドを執筆しました。プライバシー、会話型UX、パターンライブラリの基盤となる文書で、ChromeOSのすべての生成AI機能はこの基準に沿って出荷されています。
Each org built their own AI. The seams showed.各組織が自前のAIをつくり、継ぎ目が見えた。
When Google leadership pushed generative AI everywhere at once, every product surface in ChromeOS started shipping its own take. Different consent flows. Different disclaimer copy. Different sparkle icons. Different ideas of what “AI” was even called.Googleの経営層が一斉に生成AIを推し進めたとき、ChromeOSのすべてのプロダクト面が、それぞれの解釈で出荷を始めました。同意フローが違う。免責文言が違う。スパークルアイコンが違う。「AI」をどう呼ぶかすら、各チームで違っていました。
The result was the kind of incoherence users feel before they can name it: a help bubble in one app and a side panel in another, both apparently doing the same thing, neither agreeing on what it was. Few designers in the org had worked on natural-language or conversational UX before; most were extending conventional UI patterns into a paradigm those patterns weren't built for.結果として、ユーザーが言葉にする前に感じ取る種類の不整合が生まれました。あるアプリではヘルプの吹き出し、別のアプリではサイドパネル。同じことをしているはずなのに、その正体については何も一致していない。組織内に自然言語UXや会話型UXの経験を持つデザイナーは少なく、多くは従来のUIパターンを、本来想定されていないパラダイムへと拡張しようとしていました。
ChromeOS needed a single source of truth: one document a PM, designer, or engineer could open before any genAI feature went into review, and walk out knowing exactly what was required to ship.ChromeOSには、ひとつの基準文書が必要でした。PM、デザイナー、エンジニアが、生成AI機能をレビューに出す前に開けば、出荷に必要な要件が正確にわかる、そんな一冊です。
Sixteen years of AI UX. One framework to show for it.AI UX 16年。その集大成が、ひとつのフレームワークになった。
By the time the AI push hit ChromeOS, I had spent ten-plus years on AI-adjacent products: synthetic voice (Descript / Overdub), conversational platforms (Bixby, Viv), and assistant frameworks (Samsung). That experience was why I was lead designer on the ChromeOS Machine Intelligence team.AIの波がChromeOSに届いた頃、私はすでに10年以上、AI隣接のプロダクトに関わっていました。合成音声(Descript / Overdub)、会話型プラットフォーム(Bixby、Viv)、アシスタントのフレームワーク(Samsung)。その経験があったからこそ、ChromeOS Machine Intelligenceチームのリードデザイナーを任されていました。
I gathered every pattern I'd built or seen break across those products, every privacy and security pitfall I'd watched ship and ship again, and every conversational-UX best practice from inside and outside Google. The framework was an attempt to compress a decade of “this is how this kind of feature actually behaves under pressure” into something a team could read on a Tuesday.これまでに自分が組み立て、あるいは壊れていくのを見てきたパターン。何度も出荷されては繰り返されたプライバシーとセキュリティの落とし穴。Googleの内外で蓄積された会話型UXのベストプラクティス。それらをすべて集めました。このフレームワークは、「この種の機能は、現場の圧力下で実際にこう振る舞う」という10年分の知見を、火曜日の午後にチームが読み切れる形に圧縮する試みでした。
From research to publication.リサーチから公開まで。
The work moved through four overlapping phases. Each one ended with a deliverable specific enough that the next phase could begin without me in the room.仕事は、重なり合う4つの段階を経て進みました。各段階の終わりには、私がその場にいなくても次の段階を始められるだけの、十分に具体的な成果物が残るようにしました。
Map the strategic chaos before designing into it.設計に踏み込む前に、戦略の混乱を地図にする。
I started by interviewing the internal AI teams, plus marketing, privacy, and security. The biggest blocker to shipping AI features wasn't UX; it was unresolved strategy upstream. The questions piling up at every review:まず社内のAI各チームに加え、マーケティング、プライバシー、セキュリティへのインタビューから始めました。AI機能の出荷を最も阻んでいたのはUXではなく、上流で未解決のままになっていた戦略でした。レビューのたびに積み上がっていた問いは次のようなもの:
- Will Bard / Gemini be monetized through Google One? When? At what tier?Bard / GeminiはGoogle Oneで有料化されるのか?いつ?どの階層で?
- If Bard is paid, what happens to the built-in AI features in ChromeOS? Do those become paid too?Bardが有料なら、ChromeOSの組み込みAI機能はどうなる?それも有料化されるのか?
- Branding — when do we use the AI gradient on icons? When does the Sparkle icon appear?ブランディング ― AIグラデーションをアイコンに適用するのはいつ?スパークルアイコンを出すのはいつ?
- Naming — is it “Bard,” “Gemini,” “Powered by Gemini,” “Powered by Google AI”?呼称 ―「Bard」?「Gemini」?「Powered by Gemini」?「Powered by Google AI」?
- Privacy — which features are default-on (opt-out) and which require explicit consent?プライバシー ― どの機能が既定でオン(オプトアウト)で、どの機能が明示的な同意を必要とするのか?
- Quota and rate limits — what does the user see when they hit one?クォータとレート制限 ― 上限に達したとき、ユーザーには何が見えるのか?
I facilitated those conversations across orgs and pulled writers and visual designers in early, because the brand and the privacy baseline could not be settled by any single team alone.これらの議論を組織横断で進行し、ライターやビジュアルデザイナーを早い段階から巻き込みました。ブランドとプライバシーの基準は、単一のチームだけでは決められないからです。
Specify the baseline UX every AI feature ships against.すべてのAI機能が拠るべきUXの基準を定める。
Once Google-level direction stabilized, the visual / motion team, writers, privacy, and UX (me) sat down and specified the floor. Concretely, we defined:Google全体の方向性が落ち着いた段階で、ビジュアル/モーション、ライター、プライバシー、そしてUX(私)で集まり、最低基準を定義しました。具体的には次の通りです:
- Which feature classes require a consent form before being enabledどの種類の機能が、有効化の前に同意フォームを必須とするか
- User-facing messaging — accuracy disclaimers, “AI is not always right,” etc.ユーザー向けの文言 ― 精度に関する免責、「AIは常に正しいとは限らない」など
- Naming conventions — how to refer to AI in copy (do's, don'ts)命名規則 ― コピー内でAIをどう呼ぶか(やる/やらない)
- Required UI elements — disclaimer placement, contextual bubbles, consent flows, settings IA必須のUI要素 ― 免責の配置、文脈的な吹き出し、同意フロー、設定の情報設計
- Iconography, color, and motion language for AI surfacesAI面でのアイコン、色、モーションの言語
Best practices for an org that hadn't designed conversational UX before.会話型UXを設計したことのない組織のための、実践の指針。
Most ChromeOS designers had not built natural-language or conversational features. The largest section of the guide was a working primer on how those interactions actually behave. The chapters (confidential in detail; structure shown):ChromeOSのデザイナーの多くは、自然言語や会話型の機能を組み立てた経験がありませんでした。ガイドの最も大きな章は、これらのインタラクションが実際にどう振る舞うかをまとめた実用的な入門書です(詳細は機密、構成のみ掲載):
- Single-turn vs. multi-turn — when each is appropriate単発のやりとりvs. 複数ターン ― それぞれが適している場面
- Contextual follow-ups — reducing user typing through carried context文脈を引き継ぐフォローアップ ― ユーザーの入力を減らすために
- Autonomous vs. human-in-the-loop — choosing the right autonomy level自律実行vs. 人を介在させる設計 ― 適切な自律度の選択
- Data retention best practices — what to keep, what to forget, what to exposeデータ保持の指針 ― 何を保持し、何を忘れ、何を見せるか
- Response verbosity — how long the summary should actually be応答の長さ ― 要約は実際どれくらいであるべきか
- Multi-modal input and output — when text isn't the right shapeマルチモーダルの入出力 ― テキストが適切な形でないとき
- Quota vs. rate limits — and why users feel them differentlyクォータとレート制限 ― ユーザーの体感がなぜ違うのか
A checklist that intercepts features before review.レビュー前に機能を受け止めるチェックリスト。
We published the guide org-wide. It became the foundational checklist that PMs, UX, and engineers walk through before entering leadership reviews and privacy / security launch gates. Coherence across AI features measurably improved; design-to-launch velocity went up because the contested questions were resolved upstream of any single feature.このガイドを組織全体に公開しました。PM、UX、エンジニアが、経営層レビューやプライバシー / セキュリティのローンチゲートに入る前に通る、土台となるチェックリストとして機能しています。AI機能間の一貫性は計測可能なかたちで向上し、設計からローンチまでの速度も上がりました。争点となる問いが、個別の機能より上流で解決されるようになったからです。
One guide, every AI feature in the OS shipped against it.ひとつのガイドに沿って、OSのすべてのAI機能が出荷された
The guide became the floor for genAI work across ChromeOS. Reviews started with “did you check the guide?” instead of relitigating brand, privacy, and naming on every feature. Two years later, it is still in use as the foundation for ChromeOS AI UX.このガイドはChromeOS全体の生成AI作業の最低基準になりました。レビューは「ガイドは確認した?」から始まり、ブランドやプライバシー、命名を機能ごとに蒸し返すことがなくなりました。2年経ったいまも、ChromeOSのAI UXの基盤として使われ続けています。
If your business needs an expert AI designer, we can help.あなたの事業に専門のAIデザイナーが必要なら、力になれます。
A decade of shipping AI products means strategy, philosophy, and design concept arrive together. Your product can thrive, be loved, and be free of the privacy or branding backlash that derails most genAI launches.AIプロダクトを10年以上出荷してきたからこそ、戦略・哲学・デザインコンセプトをひとまとめで持ち込めます。プロダクトを伸ばし、ユーザーに愛され、多くの生成AIローンチで起きるようなプライバシーやブランドの批判とは無縁に進む ― そういうプロダクトを一緒に届けられます。