AI Ready な組織のための UX について - だれのためにつくる UI が、だれのための UX になるのか -

Alterbooth x KAG Meetup T E C H TA L K / 2 0 2 6 AI Ready な組織のための UX について - だれのためにつくる UI が、だれのための UX になるのか YUKI IZUMOTO / @mitsuba_yu

Profile • Yuki Izumoto a.k.a 蜜葉 • @mitsuba_yu • Microsoft MVP for Developer Technologies (15th) • Designer / Developer / Photographer • 洋酒とカメラとものづくりが好き。 • https://c-mitsuba.hatenablog.com

• http://c-mitsuba.hatenablog.com

History • softdevice inc - UI/UXデザインを専門とするデザインコンサルティングファーム • Fenrir inc - デザインとアプリ開発を強みとするソフトウェア開発会社 • Internet Initiative Japan Inc. - 老舗のインターネット事業者 • Freelance - 個人事業主として独立 • silkyfeel LLC 起業 - 仮説からPrototypeを制作し、ブランディングとシステム開発を行う Development Studio • スクラムマスター / サブマネージャー / CTO室 at KAG <- here !!

Recently • 最近はInnerSourceやスクフェスのイベントで 組織文化形成や、仕様駆動開発とチーム ル グ デ ビ の話をしています。 ィン と育成

Caution ! 今日の話は、すべて個人的見解で、いま検証しているものです。 これが正しい、あれがダメ、という話ではありません。 且つ、全社展開の段階ではなく、MVPを開発して周辺でPoCしている状態です。 5/76

Agenda 1 事 実 ｜ いま起きていること 2 一 幕 ｜ あるプロダクトの話 3 見立て ｜ だれのためにつくる UI が、だれのための UX になるのか 4 打ち手 ｜ プロダクトのユーザーを “人” から “AI” に置き換えたら 5 実 6 まとめ 証 ｜ 作って、確かめる

Today’s Takeaway 今日は、プロダクト設計思想の話をします。 01 02 クセルのほかに プロ クトは「どの流れに溶け込むか」 「振る舞い」がある から設計を始める 全員の隣に AI がいる組織では、 人にプロダクトを意識させず、 AI のためにつくる UI が、人のための UX になる。 仕事の流れの中に自然に入れる。 ピ ダ UI の投資先には、

01 / 06 FACT Changes in KAG 事実：いま起きていること 1 08 / 26

FA C T / いま、KAG で起きていること。 300+ 人を超える全社員が、 ロールに関係なく Claude を使える。 エンジニアも、デザイナーも、営業も、コーポレートも、経営 層も。 09 / 26

FA C T / 日々、いろんなものが作られる。 • 業務の困りごとを、本人がそのままプロダクトにする。 • 議事録も、検討メモも、比較表も、なにもかもが Claude との対話から生まれる。 • 言われて作るんじゃなくて、困っている本人が作る。 この勢いは、すごくいい。個人のアウトプットの量と質が上がり続けている。 10 / 26

02 / 06 STORY One Product Story 一幕：あるプロダクトの話 2 11 / 26

STORY / HTML 共有が、流行った。 • 議事録や比較検討など、Claude が出力する様々なドキュメントを HTML にするのが流行りましたね。 • KAG でも例に漏れず、大いに活用しています。 REFERENCE Using Claude Code: The unreasonable effectiveness of HTML (2026/5/20) https://claude.com/blog/using-claude-code-the-unreasonable-effectiveness-of-html 12 / 26

• https://claude.com/blog/using-claude-code-the-unreasonable-effectiveness-of-html

STORY / では、共有はどうする？ 1 問題になるのは、作った HTML の共有方法。 2 であれば、それも Claude で作ってしまおう、と作り出す。 3 できたプロダクトの流れが、こちら。 13 / 26

STORY / 普通に作ると、こうなる。 01 人 Claude で検討結果を html で出力する 05 操作 有効期限を設定する 02 人 ファイル共有を依頼される 06 操作 アップロード完了、URL が発行される 03 操作 メールアドレスでアカウントを作る／ログイン 07 人 出力された URL をコピーする 04 操作 ファイルをドラッグ＆ドロップで選択 08 人 Slack などで URL を共有する 14 / 26

/ HTML Share Web Service ゴール：Claude で作った検討結果の HTML を、関係者に URL で共有する PHASE 1 / 人 Claude で検討結果を html で出力する 1-a. 操作 1-b. 操作 Claude 検討結果を html 形式で出力させる OS 生成された html ファイルをローカルに保存する ・保存先(Downloads など)を覚えておく ↓ PHASE 2 / 人 ファイル共有を依頼される → サービスでアップロードする 2-a. 操作 ブラウザ 2-1. 操作 ブラウザを開き、サービスの URL にアクセスする メールアドレスでアカウントを作る / ログインする ・URL を思い出す(ブックマーク / 過去の Slack を検索) ・初回:登録してアカウント作成 ・2回目以降:再ログイン 2-3. 操作 2-c. 操作 サービス 有効期限を設定する 2-b. 操作 サービス OS 保存しておいた html ファイルを Finder 等で探す 2-4. 操作 サービス アップロードを実行し、完了を待つ 2-2. 操作 サービス ファイルをドラッグ&ドロップで選択する サービス アップロード完了、URL が発行される ・どのくらいの期限が適切か、その場で判断する ↓ PHASE 3 / 人 3-1. 操作 出力された URL をコピーする サービス 発行された URL を選択してコピーする ↓ PHASE 4 / 人 Slack などで URL を共有する 4-a. 操作 Slack に切り替え、依頼者のチャンネル / DM を開く Slack 4-b. 操作 URL を貼り付けて送信する Slack

“ 普通に作ると、そうなるね。 16 / 26

“ 普通に作ると、そうなるね。 と、同時に…… 17 / 26

“ 使わないなぁ… たかだか手元のファイルを渡したいだけで、 そんなめんどいこと、やってられない… 18 / 26

“ 使わないなぁ… たかだか手元のファイルを渡したいだけで、 そんなめんどいこと、やってられない… と、思ったわけです。作った人には申し訳ないけど。 18 / 26

03 / 06 HYPOTHESIS UI for Whom? 見立て：だれのためにつくる UI が、だれのための UX になるのか 3 20 / 26

HYPOTHESIS / だれのための UI ？ • そもそも僕たちは、もう画面を操作したくない。 • ブラウザ作業は、なんでもかんでも Claude in Chrome にお願いする。 • なんなら、それすら Claude に操作させる。 • AI が操作できないツールには、煩わしささえ感じる。 日頃Webサービスを開発している僕たちは…だれのための UI を作っているんだ…？ 21 / 26

UI for Human ? / UI for AI ? 気づけば、人のための UI を、AI に使わせている。 これからの僕たちは、だれのための UI を設計すべき？ 22 / 26

APPROACH UI for AI = UX for Human 全ての作業を AI を起点に行うのであれば、 AI から手を離さず使えるプロダクト設計こそが、 AI を第一ユーザーとしたプロダクト設計こそが、 人のための UX を実現できるのでは？ 23 / 26

04 / 06 RE :DESIGN Shifting the user from "human" to "AI" 打ち手： プロダクトのユーザーを “人” から “AI” に置き換えたら 4 24 / 26

RE:DESIGN / 解決したい課題：「共有してください」が、増えた。 渡す側 貰う側 組織全体 渡すたびに、 お願いすること自体に、 何があるかを、誰も知らない。 説明が必要。 気が引ける。 「見えるとこに置きましょう」 はだれもしない。 目立つ成果物が出ると、五月雨に 「ください」と頼むのは、 「ください」が飛んでくる。 相手の時間を奪うこと。 頼まれるたびに資料を探して、背景と文脈 を毎回説明する。 作る時間は AI で縮んだのに、渡す時間は 成果物が増えると、どこに何があるか誰も 把握できない。頼む以前に存在を知らな それが分かっているから、 い。作った側も見つけてもらえず、車輪の 欲しくても言い出しにくい。 再発明が起きる。 縮まらない。 26 / 26

RE:DESIGN / 解決したい課題：そもそも情報は、 人に「ください」と頼んで出してもらうものなのか? たとえば CI 理想のワークフロー AIの日常化 仕組みとしての 自動収集 手作業をなくし、 埋め込む 全員の隣に AI がいる 現在 • テスト結果や ルドの状態を、 • 同じことをもっと広くやれない • いまは全員の隣に AI がいます。 人に頼んで集めている現場はあ りません。 • 収集が仕事の流れに埋め込まれ ているからです。 か。 • 情報の提供や共有を手作業にし ない。 • 日々のワークフローの中に、ご く自然に AI との対話が入ってき ています。 • 日々のワークフローに埋め込め ないかと考えていました。 ビ 26 / 26

RE:DESIGN ユーザーを ”人” から ”AI” に置き換えたら？ プロダクトのファーストユーザーを、AI に変えてみる。 人のための画面を作り込むのをやめて、AI から見たプロダクトの姿をデザインする。 26 / 26

RE:DESIGN / 仮説の絵：UI の主戦場は、ピクセルから振る舞いへ これまで 人 操作を覚える → UI 画面 フォーム → プロダクト → UI 画面 検索・一覧 → 人 自分で探す 入れるのも、取り出すのも、人が画面を操作する。 これから 人 日頃の作業をClaudeから → 発話 それぞれの AI 操作を引き受ける → プロダクト AIのUI → AIのUI それぞれの AI 結果を取り出す → 人 Claudeから返答がくる 応答 AI にとっての UI は画面ではなく、API と振る舞い。人は自分の AI と話すだけです。 16 / 33

05 / 06 R E : PRODUCTION Build and Verify 実証：作って、確かめる。 5 17 / 33

DEMO 「これ公開して」 → https://statichtml.../d/xxxxxxxx LIVE DEMO — statichtml 19 / 33

RE:PRODUCTION / つくった検証機：statichtml Claude がつくった HTML を、「Claudeから離れず社内共有する」プロダクトです。 さっきの共有ツールと、課題は同じ。 作り方の前提を変えると体験がどう変わるかを、確かめたい。 検討メモや比較表みたいな Claude との対話の成果物を、人と話すためのドキュメント共有をシームレスに行います。 人向けの画面は最小限で、閲覧ポータルのみ。アカウント登録画面もアップロードフォームもありません。 そのかわり AI のための入口と出口を作り込みました。 18 / 33

RE:PRODUCTION / 道具を持ち替えない、ということ これまでの共有 1 作業を終える 2 共有ツールを開いて、サインイン(確認コード) 3 ファイルをドラッグ&ドロップ 4 共有ボタンを押して、有効期限を選ぶ 5 URL をコピーして、チャットに貼る statichtml 「これを公開して」 → URL が返る。タイトルもタグも、対話していた Claude が付ける。 対話の続きのまま共有が終わる。持ち替えがない。 「日々のワークフローに溶け込む」=「AIとの検討・開発作業の流れのまま、公開可能にする」ということ。 人がプロダクトのところへ移動するんじゃなくて、プロダクト = AIが仕事の流れに差し込んでくる。 20 / 33

RE:PRODUCTION / プロダクトの導線設計 入口 AIのUI／入れる 出口 人 「公開して」 人 AIのUI／取り出す 「似た検討は?」 更新 受け取った人 AIのUI／磨く 「直して」 → 各 Claude → 各 Claude → MCP 接続 検索して読む その Claude 読んで編集 人のUI 流れに溶かす → → publish_html /mcp list / get /mcp update_document → URL 発行 → 人 → 対話に返る 答えが返る みんな 同じ URL 閲覧ポータル 1 枚 最小限だけ 運用 → /mcp Google OAuth・社内ドメイン制限 git push main へ → Azure Pipelines CI/CD → App Service API・ポータル・MCP 21 / 33

RE:PRODUCTION / 実装はよくある技術（ C# / ASP.NET Core / Azure ） アプリ C# 4 ファイル ASP.NET Core → minimal API・.NET 10 Azure Blob データ リモート MCP Streamable HTTP インフラ App Service B1 × 1 台 盛らない 課金は B1 と Storage だけ デリバリー git push main へ → → Azure Pipelines build & deploy 同居・約400行 Azure Table → 共有したいHTML 本体 OAuth 2.1 認可 メタデータ + OAuth 状態 → 全員の Claude 知らず知らずのうちに機能が増える 22 / 33

RE:PRODUCTION

/ AI への導線は MCP で。
リモート MCP サーバーというと大ごとに聞こえますが、ASP.NET Core ではAddMcpServer()をつけたすだけでも実装可能。
あとは日頃のAPIと同じように実装して、Attributeをつけるだけ。

builder.Services.AddMcpServer()
.WithHttpTransport(o => o.Stateless = true)

// セッションを持たない

.WithTools<McpTools>();
app.MapMcp("/mcp");
[McpServerTool(Name = "update_document")]
public async Task<string> UpdateDocument(string id, string html, ...)

とはいえ、実装は全部Claudeにお任せで、実際は１行も読んでない。.NETなら簡単にできるって知ってたしね。

23 / 33

RE:PRODUCTION

/ 画面の代わりに、何を書くのか。
WebUIを捨てた分、つまりピクセルでのプロダクト表現を捨てた分、AIにとってのUIはツール定義に移ります。

画面設計にあたるのがツールと引数の設計、UX ライティングにあたるのが description。
[McpServerTool(Name = "publish_html")]
[Description("HTML ドキュメントを社内共有ポータル statichtml に公開し、
社内限定の共有 URL を返す。ユーザーが「これを公開して」と言ったときに使う。
title は内容を読んで付けた簡潔な日本語タイトル(20字以内)、
tags は内容を解釈した日本語タグ約10個。")]
public async Task<string> PublishHtml(
[Description("公開する完全な HTML")] string html,
[Description("日本語タイトル(20字以内)")] string title,
[Description("日本語タグ約10個")] string[] tags)
{
var (email, name) = CurrentUser();

// 認証済みユーザー

var id = await store.CreateAsync(/* 保存 */);
return $"公開しました: {BaseUrl()}/d/{id} …";

// AI が読んで人に伝える文

}

書いているのは、ほとんど日本語。この文章がフォームのラベルやプレースホルダーの代わりで、説明文の書き方ひとつで、付くタグの質が変わります。

24 / 33

RE:PRODUCTION / 認証認可は最初だけ。KAG では GWS を採用。 人の入口 AI の入口 Google ログイン + Cookie 30 日、社内ドメイン制限。 OAuth 2.1（MCP の標準） URL を開くだけの人のための、いつもの認証。 Claude 自身でクライアント登録して、 Proof Key for Code Exchange 日頃の会社生活でログインしてるはずなので、 (PKCE: クライアントと認可サーバー間で照合する 共有されたドキュメントを見るだけであれば、 「使い捨ての秘密鍵」) でトークンを取り、refresh を回す。 ほぼ気にすることはない。 人がやるのは、初回にブラウザで「許可する」を押すだけ。 とはいえ、これもプロダクト設計思想を十分に伝えていれば、Claudeが全て実装してくれる。 25 / 33

RE:PRODUCTION / MVP の範囲 今回は、Claudeからの共有、Claudeからの追加編集、社内アカウント連携、のみ実装。 共同ブラッシュアップはハドルで交互に進むので、楽観ロックはコストに見合わない。要るようになってから足す。 同時更新の制御は「後勝ち + 更新者記録」まで 共同ブラッシュアップはハドルで交互に進むので、楽観ロックはコストに見合わない。要るようになってから足す。 検索は AI に寄せる 検索インデックスを作らず、一覧とタグを AI に読ませる。件数が増えたら考える。 どういった知見・成果物の蓄積方法がよいか、まだまだ検討中。今回はその１つの実現方法として。 28 / 33

06 / 06 CONCLUSION まとめ 次の改善プロダクトを考えるときに。 6 31 / 33

CONCLUSION / デザインの本質は戦略を具体化する事 具体 「見た目を整えること」だけが、デザインではない。 表層 表層的な見栄えやユーザビリティに留まらず、 ビジュアルデザイン レイアウトデザイン 骨格 企業やサービスの本質的な提供価値に直結する インフォメーションデザイン ナビゲーションデザイン 重要な役割を担う。 構造 UX を 5 つの階層で捉える 情報設計 インタラクションデザイン • 戦略 → 要件 → 構造 → 骨格 → 表層 の 5 階層で構成 要件 要件定義 • 各階層を行き来しながら、検討を深める • 抽象的な戦略を具体化し、求められるサービスへ磨き上げる → そのプロセスそのものが、デザインの役割。 戦略 ユーザーニーズ 目的・目標設定 抽象 UX の 5 階層モデル Jesse James Garrett 「Elements of User Experience」

CONCLUSION 貴庁限り /「人のためのWeb UIと画面」 から 「AIのためのAPIと振る舞い」に 構造をリフレーミングする AI とのインタラクション（これから） Web UI（これまで） 具体 表層 骨格 構造 要件 戦略 抽象 ビジュアルデザイン レイアウト・ナビゲーション 情報デザイン 情報設計 → → インタラクションデザイン → 要件定義 → ユーザーニーズ・目的／目標 → Description ＝ モデルへのプロンプト 説明文の書き方が、AIの“使いこなし”を決める ツールの I/O・レスポンス エラー設計 ツールと引数の設計 今回の主題 AI との対話フロー AI に渡す操作 ＝ 提供するツールの定義 変わらない （誰の、何を助けるか） UX の 5 階層モデル Jesse James Garrett 「Elements of User Experience」を、AI とのインタラクションに読み替え

CONCLUSION 次のプロダクトを考えるときに TA K E A W AY 0 1 TA K E A W AY 0 2 プロダクトは、 AI Ready な組織であれば、 日々の仕事のフローに溶け込ませる 溶け込み先は「AI との対話」になる ツールを作るからといって、 300人全員が AIを利用できる環境であれば、 ツール都合でに人の行動を変えさせない。 AI をファーストユーザーにした作り方が解の１つになる。 「どの画面を作るか」ではなく ともすれば、これまで当たり前だと思っていた、 「どの流れに溶け込むか」かの、体験設計から始める。 コストの高い画面設計は不要になるかもしれない。 32 / 33

THANK YOU 誰もがAIを使う時代のその先。 プロダクトの形は、 “見て操作する" から “自ら振る舞う" へ 変わるかもしれない。 AIの振る舞いを開発することが、人のための UX になる…かも？ @mitsuba_yu