This case study describes the work at a high level. Specific metrics, internal tooling configurations, agent instructions, and proprietary processes have been generalized or anonymized to respect client confidentiality. The frictions, architecture, and design thinking remain authentic to my contribution. このケーススタディは、取り組みを高いレベルで概観したものです。具体的な数値、社内ツールの構成、エージェントの指示、独自のプロセスは、クライアントの機密保持のため一般化または匿名化しています。課題、アーキテクチャ、デザイン思考の核心は、私の貢献に忠実なものです。
I designed 10 AI agents for the product-development flow. プロダクト開発フローのために、10のAIエージェントをデザインした。
Not demos — working teammates. Born from the team's real pain, built inside a locked-down enterprise stack, running in production with 42 designers. デモではない — 実際に働く仲間たちだ。チームの現実の痛みから生まれ、閉ざされたエンタープライズ環境の中で作られ、42人のデザイナーの現場で稼働している。
Diagnosis診断The system I was working in私が置かれていた仕組み
The problem was never the tools. It was the shape of the org.問題はツールではなかった。組織のかたちだった。
Business and Technology scoped every project before design or strategy entered the room. There was no budget to test, so the highest-position opinion won. By handoff, the good UX was already out of scope. Everyone felt it — the designers, the strategists, even the design leaders. No one could move it. ビジネスとテクノロジーが、デザインもストラテジーも部屋に入る前に、すべてのプロジェクトのスコープを決めていた。テストの予算はなく、だから一番役職の高い人の意見が通った。ハンドオフの頃には、良いUXはとっくにスコープの外だった。全員が感じていた — デザイナーも、ストラテジストも、デザインのリーダーさえも。だが、誰にも動かせなかった。
One project. Pain at every stage.ひとつのプロジェクト。あらゆる工程に痛み。
This was the normal flow — and the point where design lost control at each step.これが通常の流れ — そして各ステップで、デザインが主導権を失っていく場所だ。
The through-line: at no point did design hold the evidence, the scope, or the timing. Frustration pooled at every stage.一本の筋： どの地点でも、デザインは証拠もスコープもタイミングも握っていなかった。あらゆる工程に不満が溜まっていった。
Design leaders saw it. They still couldn’t change it.デザインのリーダーも見えていた。それでも変えられなかった。
Everyone, even the leaders, got overruled somewhere up the chain. So as a single designer I stopped trying to rewrite the org — and started architecting AI into the exact moments where it hurt, inside the workflow everyone already used. 全員が — リーダーですら — どこかで上に覆された。だから一介のデザイナーである私は、組織を書き換えようとするのをやめ、みんながすでに使っているワークフローの中で、痛みが走るまさにその瞬間にAIを設計として組み込み始めた。
Method手法How I found what to build何を作るかの見つけ方
I couldn’t fix the org. So I found exactly where it hurt — and built for that.組織は直せなかった。だから痛むその場所を正確に見つけ — そこに向けて作った。
I sat down with more than sixteen designers and strategists, one hour each, and listened. Then I turned the raw frustration into a map — and the map into a build list. The agents further down this page are simply the bets that survived it. 16人を超えるデザイナーとストラテジストと、一人1時間ずつ向き合い、耳を傾けた。そして生の不満を地図に変え — 地図を「作るものリスト」に変えた。このページの先に出てくるエージェントたちは、そのプロセスを生き延びた賭けにすぎない。
Listen → map → pilot.聴く → 地図化する → 試す。
A working agent was never one prompt — it was a stack of files.効くエージェントは、単一のプロンプトではなかった — ファイルの束だった。
Each one I built was really a small filesystem: a workflow file that sequenced the steps, an agent-definition file that fixed its role and rules, and separate deep-knowledge files it reasoned from. Studying BMAD’s spec-driven method taught me the lesson — it’s this structure, not clever wording, that lets an agent do genuinely fine-grained work.私が作ったものは、実際には小さなファイルシステムだった — 手順を並べるワークフローのファイル、役割とルールを定めるエージェント定義のファイル、そしてそこから推論するディープナレッジのファイル群。BMADの仕様駆動の手法を学んで腑に落ちた — エージェントに本当にきめ細かい仕事をさせるのは、気の利いた言い回しではなく、この構造だ、と。
And I earned it the hard way: version after version of each Gem, testing the outputs, feeding a Gem’s own results back in to sharpen its instructions — until it was reliable enough to hand to a 40-person team.そしてそれは、地道にしか得られなかった — 各Gemを何バージョンも作り、出力をテストし、Gem自身の結果をまた読み込ませて指示を研ぎ直す。40人のチームに手渡せる信頼性に届くまで、それを繰り返した。
What I built私が作ったもの
Sixteen interviews. Forty pains. Ten agents that answered them.16のインタビュー。40の痛み。それに応えた10のエージェント。
The whole diagnosis pointed to one move: stop patching the org, and build. Each structural failure got a purpose-built agent aimed straight at it — Master Brain, Justin, Sally, the WDS studio — and more. Here is each one, and the failure it replaced. 診断のすべてが、ひとつの手を指していた — 組織を継ぎ接ぎするのをやめ、作る。構造的な欠陥のひとつひとつに、それを狙い撃つ目的特化型のエージェントを当てた — Master Brain、Justin、Sally、WDSスタジオ — そして、まだ続く。以下、その一つずつと、置き換えた欠陥を示す。
The deep dive — each system, up close.深掘り — 各システムを、間近で。
Everything above is the whole story in brief. Read on for how each agent actually works — or jump with the rail on the left.ここまでで全体像は完結。この先は、各エージェントが実際にどう働くか。左のレールからもジャンプできる。
Master BrainThe organizational memory組織の記憶
One project brain. Every answer, on demand.ひとつのプロジェクトの脳。あらゆる答えを、その場で。
Knowledge lived in heads, emails, and research PDFs no one had time to read — the research team ran deep brand studies five to eight times a year that never reached a busy project. Deep experts were underused. So I built a single place that holds it all and answers back. 知識は人の頭の中、メール、そして誰も読む時間のないリサーチPDFの中にあった — リサーチチームは年に5〜8回も深いブランド調査を行うのに、それが忙しいプロジェクトに届くことはなかった。深い知見を持つ人ほど活かされていなかった。だから私は、すべてを保持し、そして答えを返す単一の場所を作った。
Brand Master Brainブランド Master Brain
Brand history, voice, and standards — so every project inherits what the brand already knows about itself.ブランドの歴史、ボイス、基準 — すべてのプロジェクトが、ブランド自身の既知を受け継ぐ。
Research Master Brainリサーチ Master Brain
Every deep study the research team produces — finally readable on demand, pulled into whichever project needs it.リサーチチームが生む深い調査のすべて — ようやく必要なときに読め、必要なプロジェクトへ引き込める。
Project Master Brain
プロジェクト Master Brain
All project scope, business docs, CX strategy, technical requirements, and every meeting transcript — synthesized into answers in real time. Ask it anything the project has ever known.プロジェクトのスコープ、ビジネス文書、CX戦略、技術要件、そしてすべての会議の書き起こし — それらをリアルタイムで答えへと合成する。このプロジェクトが知っていたことなら、何でも聞ける。
Instant onboarding即時オンボーディング
New teammates get productive in minutes — even an auto-generated onboarding video from 120+ sources.新メンバーが数分で戦力に — 120以上のソースから自動生成したオンボーディング動画まで。
Deep-dive on demand深掘りは随時
Ask anything, go as deep as the project needs — no gatekeeper, no waiting.何でも聞け、プロジェクトが要る深さまで潜れる — 門番も待ちもなし。
Tangled requirements, answered絡んだ要件に回答
Activation, account creation, add-a-line — business + technical complexity resolved in seconds.アクティベーション、アカウント作成、回線追加 — ビジネス×技術の複雑さを数秒で解く。
Never stale古びない
Every meeting transcript is in within 24 hours. The brain keeps learning.すべての会議の書き起こしが24時間以内に。脳は学び続ける。
It answered the questions no one had time to answer.誰も答える時間のなかった問いに、答えた。
Mobile activation, account creation, add-a-line — where business rules and technical requirements tangle together, the Project Master Brain replied accurately and fast, saving real hours. On one payment-flexibility initiative it could articulate the entire business case on demand: the customer suspension gap, the recoverable nine-figure annual revenue, and the three “how might we” questions the design had to answer. That’s the difference between a file archive and an organizational memory. モバイルのアクティベーション、アカウント作成、回線追加 — ビジネスルールと技術要件が複雑に絡み合う場所で、プロジェクトMaster Brainは正確に、速く答え、実際に何時間も節約した。ある支払い柔軟化のイニシアチブでは、ビジネスケース全体をその場で語れた — 顧客の利用停止ギャップ、回収可能な9桁ドル規模の年間売上、そしてデザインが答えるべき3つの「How might we」まで。ファイル置き場と「組織の記憶」の違いが、ここにある。
Justin CaseEdge Case Detectorエッジケース検出
Break the logic before a line of code exists.コードが1行も書かれる前に、ロジックを壊す。
The name is the pitch — built to check things just in case. A Gemini Gem wired to a dedicated NotebookLM of edge-case detection resources, Justin runs a structured deep scan on a design before it ever reaches a developer's queue. 名前がそのままコンセプトだ — 「念のため」（just in case）確認するために作られている。エッジケース検出のリソースを溜め込んだ専用のNotebookLMに接続されたGemini Gem。Justinは、デザインが開発者のキューに届くよりも前に、構造化されたディープスキャンを実行する。
Designers design the happy path. Users don't live there.デザイナーはハッピーパスを描く。ユーザーはそこには住んでいない。
Every flow hides the same three traps — and they all come due at the most expensive possible moment.どんなフローにも、同じ3つの罠が隠れている — そしてそのすべてが、最も高くつく瞬間に牙をむく。
Four layers. Every gap ranked. No code written yet.4つの層。すべてのギャップを順位づけ。まだコードは1行もない。
Fed the Project Master Brain, an Initiative Alignment Brief, and optionally the existing UI, Justin scans across four layers and returns a ranked matrix — each gap paired with an open question product and engineering must resolve before build.プロジェクトのMaster Brain、イニシアチブ整合ブリーフ、そして任意で既存のUIを与えられると、Justinは4つの層をスキャンし、順位づけされたマトリクスを返す — 各ギャップには、開発が始まる前にプロダクトとエンジニアリングが解くべき問いが添えられる。
Type #audit — get 20–40 ranked questions engineering has to answer.#audit と打つ — エンジニアが答えるべき20〜40の問いが返る。
Each catch is phrased as a question, not a complaint. Real ones from a single payment feature: what happens to a payment made at 11:59 PM when the system suspends the account at 12:02 AM? Does a user in Guam (UTC+10) see “Day 0” while US-Eastern servers still say “Day −1”? If AutoPay batches lock 24–48 hours ahead, does the user get double-billed? What does five rage-clicks on “Pay” during a 60-second API hang actually charge? 検出はどれも、不満ではなく問いの形をとる。ある支払い機能ひとつからの実例 — 23:59の支払いは、システムが0:02に口座を停止する場合どうなる？ グアム（UTC+10）のユーザーには「Day 0」でも、米東部サーバーはまだ「Day −1」では？ AutoPayが24〜48時間前にロックするなら、二重請求は起きない？ APIが60秒固まる間に「支払う」を5回連打したら、いくら請求される？
SallyPrincipal CX StrategistプリンシパルCXストラテジスト
No budget to test? Test against human psychology.テスト予算がない？ なら人間の心理でテストする。
A Gemini Gem paired with a dedicated NotebookLM knowledge base, Sally fills the void where user testing should have been — stress-testing a flow against behavioral science instead of the highest-paid person's opinion. Gemini Gemと専用のNotebookLMナレッジベースを組み合わせたSallyは、本来ユーザーテストがあるべきだった空白を埋める — 会議室で一番給料の高い人の意見ではなく、行動科学に照らしてフローを負荷試験する。
analysis8ステップ
分析
She runs the whole audit across three layers.3つの層にわたり、監査をまるごと走らせる。
Not an opinion. A verdict — with a number.意見ではなく、判定を — 数字とともに。
Auditing a device-activation flow against its persona, Sally found it treats an owner (who already holds the device) like a shopper (who needs to buy) — triggering “double-payment anxiety” and abandonment at the exact screen where a cart total appears. デバイスのアクティベーションフローをペルソナに照らして監査したSallyは、すでにデバイスを持つ所有者を、これから買う買い物客のように扱っていることを見抜いた — カート合計が表示されるまさにその画面で、「二重支払いへの不安」と離脱を引き起こしている。
Never one answer — always a ladder of options.答えはひとつではない — 常に、選択肢の階段。
For each friction, Sally returns three tiers — quick fix, standard, north star — each with its reasoning attached. One example, for a manual serial-number entry that violated Fogg's Ability principle:それぞれの摩擦に対し、Sallyは3段階を返す — クイックフィックス、スタンダード、ノーススター。それぞれに根拠が添えられる。Foggの「能力」の原則に反していた、シリアル番号の手入力の一例：
A UX evaluatorUXの評価者
Feed her the three files and she graded the finished flow — a multi-lens analysis of where the design fought human psychology, scored and cited. Powerful, but it happened after the design was done.3つのファイルを渡すと、彼女は完成したフローを採点した — デザインが人間の心理と衝突する箇所を、多角的に分析し、スコアと根拠をつけて。強力だが、それはデザインが終わった後の話だった。
A design partnerデザインの相棒
Now she helps shape the design, not just test it — framing the brief, proposing the strategy, and generating ranked options before a pixel is committed. Not a grade at the end; a collaborator at the start.いまや彼女は、デザインをただ試すのではなく、形づくるのを助ける — ブリーフを整え、戦略を提案し、1ピクセルも確定する前に順位づけした選択肢を生む。終わりの採点ではなく、始まりの共同作業だ。
What Sally producesSallyが生み出すもの
- Initiative Alignment Briefs — framing a project's business case and CX opportunity before design work starts.イニシアチブ整合ブリーフ — デザイン作業が始まる前に、プロジェクトのビジネスケースとCX上の機会を明確にする。
- CX Audit Reports — detail report, executive summary, and slide deck, scored sub-score by sub-score.CX監査レポート — 詳細レポート、エグゼクティブサマリー、スライド資料。サブスコアごとに採点される。
- Strategic Options slides — for each friction found, ranked solution paths with trade-offs a designer can defend to stakeholders, not a single fix handed down.戦略的選択肢のスライド — 発見された摩擦それぞれに対して、デザイナーがステークホルダーに説明できる、トレードオフ付きの解決パスを提示する。単一の答えを下すのではない。
The team's gain is threefold: instant self-auditing without testing budgets or lead times, scientific consistency — every screen held to the same ISO and behavioral-science standards — and internal validation, so designers walk into stakeholder reviews with evidence instead of hope. チームが得たものは3つ。テスト予算もリードタイムも要らない即時のセルフ監査。すべての画面が同じISOと行動科学の基準で評価される科学的な一貫性。そして社内での検証 — デザイナーは祈りではなく、証拠を持ってステークホルダーレビューに臨めるようになった。
WDSWhiteport Design Studio · 5-agent collectiveWhiteport Design Studio · 5体のコレクティブ
Agentic design, carried into a browser tab.エージェント駆動のデザインを、ブラウザのタブの中へ。
The agent workflows that power Claude Code and Codex live in the engineer's terminal — a place our product-design org simply could not go. No CLI. No VS Code. No API. Just Gemini in a Chrome tab. My core contribution was to rebuild that terminal-grade, agent-led design process as a set of Gems the whole team could open, share, and run — inside the one locked-down stack we were allowed to touch. Claude CodeやCodexを動かすエージェントのワークフローは、エンジニアのターミナルの中にある — プロダクトデザインの部署が、そもそも足を踏み入れられない場所だ。CLIもなし。VS Codeもなし。APIもなし。あるのはChromeのタブの中のGeminiだけ。私の中心的な貢献は、そのターミナル級のエージェント主導のデザインプロセスを、チーム全員が開き、共有し、実行できるGemとして作り直したことだった — 私たちが唯一触れることを許された、閉ざされたスタックの中で。
The engineer's terminalエンジニアのターミナル
Command line, spec-driven agents, version control, direct model access. Powerful — and completely off-limits to designers.コマンドライン、仕様駆動のエージェント、バージョン管理、モデルへの直接アクセス。強力 — そしてデザイナーには完全に立入禁止だった。
across私が
運んだ
One browser tabひとつのブラウザタブ
Strategy, UX, and product-design teams had exactly one approved AI surface — Gemini in a browser. Installing anything else was a battle.ストラテジー、UX、プロダクトデザインの各チームに許された唯一のAIの窓口 — ブラウザの中のGemini。それ以外を入れるのは、一つひとつが闘いだった。
From one giant prompt to a filesystem.ひとつの巨大なプロンプトから、ファイルシステムへ。
My first agents were single, sprawling prompts — and they collapsed under their own context. The fix was architectural: break each agent into small, versioned parts — a workflow that sequences the steps, and separate knowledge files it loads only when needed.最初のエージェントは、単一の肥大化したプロンプトだった — そしてそれ自身のコンテキストの重さで崩れていった。解決策はアーキテクチャにあった。各エージェントを、小さくバージョン管理された部品へと分解する — ステップを順序づけるワークフローと、必要なときだけ読み込む別立てのナレッジファイルに。
Authored in Claude Code, deployed as a Gem. The agent stopped forgetting — and I stopped fighting the window.Claude Codeで記述し、Gemとしてデプロイした。エージェントは忘れなくなり — 私はコンテキストウィンドウと格闘しなくなった。
NotebookLM worked alone. Google Drive worked for everyone.NotebookLMは一人では動いた。Google Driveはみんなで動いた。
Solo, a Gem wired to my own NotebookLM was brilliant. The moment I shared it, it broke — the knowledge and sources didn't travel with the Gem. So I moved the workflow and knowledge files onto Google Drive: one shared, governable source that every teammate's Gem could load the same way.一人で使う分には、自分のNotebookLMに接続したGemは見事に動いた。だが共有した瞬間に壊れた — ナレッジやソースがGemと一緒には運ばれなかったのだ。そこで、ワークフローとナレッジのファイルをGoogle Driveへ移した。全員のGemが同じやり方で読み込める、共有され統制の効く単一のソースへ。
That turned a personal trick into an organizational capability — the real unlock for a 40-person team.これが、個人の小技を組織の能力へと変えた — 40人のチームにとっての、本当の解錠だった。
I installed VS Code myself — then wired Figma to it.VS Codeを自分で入れ — そこにFigmaをつないだ。
In a design org where even installing VS Code was a fight, I set it up, connected it to AI, and linked it to Figma via MCP. Suddenly I could turn Figma frames into code, build the design system as real tokens, and feed those tokens back into prototyping.VS Codeを入れることすら闘いだったデザイン部署で、私はそれを立ち上げ、AIにつなぎ、MCP経由でFigmaと連携させた。すると、Figmaのフレームをコード化し、デザインシステムを実際のトークンとして構築し、そのトークンをプロトタイピングへ還流できるようになった。
The payoff was fidelity: AI prototypes that obeyed the brand from the very first prompt, because they were grounded in the actual design-system code.見返りは忠実度だった — 最初のプロンプトからブランドに従うAIプロトタイプ。実際のデザインシステムのコードに接地していたからだ。
It spread because I never issued a decree.広まったのは、号令をかけなかったからだ。
The org was siloed and stiff; a top-down “everyone use AI now” was never going to land. So instead of replacing the product-development flow, I found the exact moment each role felt pain and slipped a genuinely useful agent into it — then connected those moments back into the flow. 組織はサイロ化し、硬直していた。トップダウンの「今すぐ全員AIを使え」が根づくはずもなかった。だから私は、プロダクト開発のフローを置き換えるのではなく、各役割が痛みを感じるまさにその瞬間を見つけ、本当に役立つエージェントをそこに滑り込ませた — そしてその瞬間を、フローへとつなぎ直していった。
The result: a five-agent design studio.その結果 — 5体のエージェントによるデザインスタジオ。
Codenamed after Norse gods, the WDS agents relay a brief forward — brief → strategy → interaction → architecture → visuals — each a Gem I designed, each grounded in shared Drive knowledge. Built on BMAD's spec-first discipline, but retargeted from shipping code to shaping concepts precise enough to hand a developer.北欧の神々にちなむコードネームを持つWDSのエージェントたちは、ブリーフをリレーで前へ送る — ブリーフ → 戦略 → インタラクション → アーキテクチャ → ビジュアル。それぞれが私の設計したGemで、それぞれが共有Driveのナレッジに接地している。BMADの仕様先行の規律の上に築きつつ、狙いをコードの実装から、開発者に渡せるほど精密なコンセプトの造形へと向け直した。
Fed the Project Master Brain and an alignment brief, the studio relays the work forward — and out the other side comes a CX/UX strategy, multiple solution scenarios, and prototyping prompts ready for Gemini Canvas or Figma Make. On one payment project it took a tangled brief from chaos to concept: strategy first, then interactive prototypes built on the brand's real design-system tokens — and when the team wanted breadth, dozens of interaction variations of the same flow, generated at once. プロジェクトのMaster Brainと整合ブリーフを受け取ると、スタジオは仕事を前へリレーする — 反対側から出てくるのは、CX/UX戦略、複数のソリューションシナリオ、そしてGemini CanvasやFigma Makeですぐ使えるプロトタイピングプロンプトだ。ある支払いプロジェクトでは、もつれたブリーフをカオスからコンセプトへと導いた — まず戦略、次にブランドの実際のデザインシステム・トークンに基づくインタラクティブなプロトタイプ。そして幅が欲しいときは、同じフローの数十のバリエーションを一度に生成した。
Clara & Alex — the Guardian and the BuilderClara と Alex — 番人と建築家
Workflow Transformationワークフローの変革
The workflow sequence stayed the same: BRD, CX Playbook, User Journey, Design, Prototype, Handoff, QA, Launch. But every phase now has an AI agent running in parallel — surfacing context, validating assumptions, catching edge cases. ワークフローの流れ自体は変わっていない。BRD、CXプレイブック、ユーザージャーニー、デザイン、プロトタイプ、ハンドオフ、QA、ローンチ。だが、いまや各フェーズでAIエージェントが並行して動いている — 文脈を引き出し、前提を検証し、エッジケースを捕まえる。
New Workflow with AI AgentsAIエージェントを組み込んだ新しいワークフロー
Scale & Outcomesスケールと成果
After: Designers operated at the strategic level the role was always supposed to require. They made decisions. They challenged assumptions. They designed with evidence.
Same pipeline. Fundamentally different output. ビフォー： デザイナーは戦術的に動いていた。壊れたプロセスが残した隙間を埋めていた。受け身だった。疲弊していた。
アフター： デザイナーは、この役割が本来求めていたはずの戦略的なレベルで動くようになった。意思決定を下した。前提に異を唱えた。証拠に基づいてデザインした。
同じパイプライン。まったく異なるアウトプット。