--- title: AI Ready な組織のための UX について - だれのためにつくる UI が、だれのための UX になるのか - tags: author: [蜜葉](https://docswell.com/user/mitsuba_yu) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/LE1Y2YXX7G.jpg?width=480 description: Alterbooth x KAG Meetup TECH TALK / 2026 published: July 17, 26 canonical: https://docswell.com/s/mitsuba_yu/5MQGN8-2026-07-17-200858 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/LE1Y2YXX7G.jpg) Alterbooth x KAG Meetup T E C H TA L K / 2 0 2 6 AI Ready な組織のための UX について - だれのためにつくる UI が、だれのための UX になるのか YUKI IZUMOTO / @mitsuba_yu # Page. 2 ![Page Image](https://bcdn.docswell.com/page/GEWGRGNKJ2.jpg) Profile • Yuki Izumoto a.k.a 蜜葉 • @mitsuba_yu • Microsoft MVP for Developer Technologies (15th) • Designer / Developer / Photographer • 洋酒とカメラとものづくりが好き。 • https://c-mitsuba.hatenablog.com # Page. 3 ![Page Image](https://bcdn.docswell.com/page/47ZLRL3NJ3.jpg) History • softdevice inc - UI/UXデザインを専門とするデザインコンサルティングファーム • Fenrir inc - デザインとアプリ開発を強みとするソフトウェア開発会社 • Internet Initiative Japan Inc. - 老舗のインターネット事業者 • Freelance - 個人事業主として独立 • silkyfeel LLC 起業 - 仮説からPrototypeを制作し、ブランディングとシステム開発を行う Development Studio • スクラムマスター / サブマネージャー / CTO室 at KAG <- here !! # Page. 4 ![Page Image](https://bcdn.docswell.com/page/YJ6WRWX9JV.jpg) Recently • 最近はInnerSourceやスクフェスのイベントで 組織文化形成や、仕様駆動開発とチーム ル グ デ ビ の話をしています。 ィン と育成 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/GJ5M8MXDJ4.jpg) Caution ! 今日の話は、すべて個人的見解で、いま検証しているものです。 これが正しい、あれがダメ、という話ではありません。 且つ、全社展開の段階ではなく、MVPを開発して周辺でPoCしている状態です。 5/76 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/LE3W8W4QE5.jpg) Agenda 1 事 実 ｜ いま起きていること 2 一 幕 ｜ あるプロダクトの話 3 見立て ｜ だれのためにつくる UI が、だれのための UX になるのか 4 打ち手 ｜ プロダクトのユーザーを “人” から “AI” に置き換えたら 5 実 6 まとめ 証 ｜ 作って、確かめる # Page. 7 ![Page Image](https://bcdn.docswell.com/page/8EDKMKQW7G.jpg) Today’s Takeaway 今日は、プロダクト設計思想の話をします。 01 02 クセルのほかに プロ クトは「どの流れに溶け込むか」 「振る舞い」がある から設計を始める 全員の隣に AI がいる組織では、 人にプロダクトを意識させず、 AI のためにつくる UI が、人のための UX になる。 仕事の流れの中に自然に入れる。 ピ ダ UI の投資先には、 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/V7PKRKLXJ8.jpg) 01 / 06 FACT Changes in KAG 事実：いま起きていること 1 08 / 26 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/2JVVRVQ3JQ.jpg) FA C T / いま、KAG で起きていること。 300+ 人を超える全社員が、 ロールに関係なく Claude を使える。 エンジニアも、デザイナーも、営業も、コーポレートも、経営 層も。 09 / 26 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/5EGLMLWYJL.jpg) FA C T / 日々、いろんなものが作られる。 • 業務の困りごとを、本人がそのままプロダクトにする。 • 議事録も、検討メモも、比較表も、なにもかもが Claude との対話から生まれる。 • 言われて作るんじゃなくて、困っている本人が作る。 この勢いは、すごくいい。個人のアウトプットの量と質が上がり続けている。 10 / 26 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/4JQYRY367P.jpg) 02 / 06 STORY One Product Story 一幕：あるプロダクトの話 2 11 / 26 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/K74W8W1ME1.jpg) 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 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/LJ1Y2YGYEG.jpg) STORY / では、共有はどうする？ 1 問題になるのは、作った HTML の共有方法。 2 であれば、それも Claude で作ってしまおう、と作り出す。 3 できたプロダクトの流れが、こちら。 13 / 26 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/GJWGRGK172.jpg) STORY / 普通に作ると、こうなる。 01 人 Claude で検討結果を html で出力する 05 操作 有効期限を設定する 02 人 ファイル共有を依頼される 06 操作 アップロード完了、URL が発行される 03 操作 メールアドレスでアカウントを作る／ログイン 07 人 出力された URL をコピーする 04 操作 ファイルをドラッグ＆ドロップで選択 08 人 Slack などで URL を共有する 14 / 26 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/4EZLRLZX73.jpg) / 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 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/Y76WRWZP7V.jpg) “ 普通に作ると、そうなるね。 16 / 26 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/G75M8MWP74.jpg) “ 普通に作ると、そうなるね。 と、同時に…… 17 / 26 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/9J29K9QZER.jpg) “ 使わないなぁ… たかだか手元のファイルを渡したいだけで、 そんなめんどいこと、やってられない… 18 / 26 # Page. 19 ![Page Image](https://bcdn.docswell.com/page/DEY4N4WNJM.jpg) “ 使わないなぁ… たかだか手元のファイルを渡したいだけで、 そんなめんどいこと、やってられない… と、思ったわけです。作った人には申し訳ないけど。 18 / 26 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/VJNYXY9V78.jpg) 03 / 06 HYPOTHESIS UI for Whom? 見立て：だれのためにつくる UI が、だれのための UX になるのか 3 20 / 26 # Page. 21 ![Page Image](https://bcdn.docswell.com/page/YE9P8P2VJ3.jpg) HYPOTHESIS / だれのための UI ？ • そもそも僕たちは、もう画面を操作したくない。 • ブラウザ作業は、なんでもかんでも Claude in Chrome にお願いする。 • なんなら、それすら Claude に操作させる。 • AI が操作できないツールには、煩わしささえ感じる。 日頃Webサービスを開発している僕たちは…だれのための UI を作っているんだ…？ 21 / 26 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/GE8D8D54ED.jpg) UI for Human ? / UI for AI ? 気づけば、人のための UI を、AI に使わせている。 これからの僕たちは、だれのための UI を設計すべき？ 22 / 26 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/LELMRMYV7R.jpg) APPROACH UI for AI = UX for Human 全ての作業を AI を起点に行うのであれば、 AI から手を離さず使えるプロダクト設計こそが、 AI を第一ユーザーとしたプロダクト設計こそが、 人のための UX を実現できるのでは？ 23 / 26 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/4JMYRYNNJW.jpg) 04 / 06 RE :DESIGN Shifting the user from "human" to "AI" 打ち手： プロダクトのユーザーを “人” から “AI” に置き換えたら 4 24 / 26 # Page. 25 ![Page Image](https://bcdn.docswell.com/page/PJR9R9D479.jpg) RE:DESIGN / 解決したい課題：「共有してください」が、増えた。 渡す側 貰う側 組織全体 渡すたびに、 お願いすること自体に、 何があるかを、誰も知らない。 説明が必要。 気が引ける。 「見えるとこに置きましょう」 はだれもしない。 目立つ成果物が出ると、五月雨に 「ください」と頼むのは、 「ください」が飛んでくる。 相手の時間を奪うこと。 頼まれるたびに資料を探して、背景と文脈 を毎回説明する。 作る時間は AI で縮んだのに、渡す時間は 成果物が増えると、どこに何があるか誰も 把握できない。頼む以前に存在を知らな それが分かっているから、 い。作った側も見つけてもらえず、車輪の 欲しくても言い出しにくい。 再発明が起きる。 縮まらない。 26 / 26 # Page. 26 ![Page Image](https://bcdn.docswell.com/page/PEXQRQ1ZJX.jpg) RE:DESIGN / 解決したい課題：そもそも情報は、 人に「ください」と頼んで出してもらうものなのか? たとえば CI 理想のワークフロー AIの日常化 仕組みとしての 自動収集 手作業をなくし、 埋め込む 全員の隣に AI がいる 現在 • テスト結果や ルドの状態を、 • 同じことをもっと広くやれない • いまは全員の隣に AI がいます。 人に頼んで集めている現場はあ りません。 • 収集が仕事の流れに埋め込まれ ているからです。 か。 • 情報の提供や共有を手作業にし ない。 • 日々のワークフローの中に、ご く自然に AI との対話が入ってき ています。 • 日々のワークフローに埋め込め ないかと考えていました。 ビ 26 / 26 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/3EK9R92VED.jpg) RE:DESIGN ユーザーを ”人” から ”AI” に置き換えたら？ プロダクトのファーストユーザーを、AI に変えてみる。 人のための画面を作り込むのをやめて、AI から見たプロダクトの姿をデザインする。 26 / 26 # Page. 28 ![Page Image](https://bcdn.docswell.com/page/L73W8WYQ75.jpg) RE:DESIGN / 仮説の絵：UI の主戦場は、ピクセルから振る舞いへ これまで 人 操作を覚える → UI 画面 フォーム → プロダクト → UI 画面 検索・一覧 → 人 自分で探す 入れるのも、取り出すのも、人が画面を操作する。 これから 人 日頃の作業をClaudeから → 発話 それぞれの AI 操作を引き受ける → プロダクト AIのUI → AIのUI それぞれの AI 結果を取り出す → 人 Claudeから返答がくる 応答 AI にとっての UI は画面ではなく、API と振る舞い。人は自分の AI と話すだけです。 16 / 33 # Page. 29 ![Page Image](https://bcdn.docswell.com/page/87DKMK5WJG.jpg) 05 / 06 R E : PRODUCTION Build and Verify 実証：作って、確かめる。 5 17 / 33 # Page. 30 ![Page Image](https://bcdn.docswell.com/page/VJPKRKGXE8.jpg) DEMO 「これ公開して」 → https://statichtml.../d/xxxxxxxx LIVE DEMO — statichtml 19 / 33 # Page. 31 ![Page Image](https://bcdn.docswell.com/page/2EVVRV63EQ.jpg) RE:PRODUCTION / つくった検証機：statichtml Claude がつくった HTML を、「Claudeから離れず社内共有する」プロダクトです。 さっきの共有ツールと、課題は同じ。 作り方の前提を変えると体験がどう変わるかを、確かめたい。 検討メモや比較表みたいな Claude との対話の成果物を、人と話すためのドキュメント共有をシームレスに行います。 人向けの画面は最小限で、閲覧ポータルのみ。アカウント登録画面もアップロードフォームもありません。 そのかわり AI のための入口と出口を作り込みました。 18 / 33 # Page. 32 ![Page Image](https://bcdn.docswell.com/page/57GLMLNYEL.jpg) RE:PRODUCTION / 道具を持ち替えない、ということ これまでの共有 1 作業を終える 2 共有ツールを開いて、サインイン(確認コード) 3 ファイルをドラッグ&ドロップ 4 共有ボタンを押して、有効期限を選ぶ 5 URL をコピーして、チャットに貼る statichtml 「これを公開して」 → URL が返る。タイトルもタグも、対話していた Claude が付ける。 対話の続きのまま共有が終わる。持ち替えがない。 「日々のワークフローに溶け込む」=「AIとの検討・開発作業の流れのまま、公開可能にする」ということ。 人がプロダクトのところへ移動するんじゃなくて、プロダクト = AIが仕事の流れに差し込んでくる。 20 / 33 # Page. 33 ![Page Image](https://bcdn.docswell.com/page/4EQYRYQ6JP.jpg) 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 # Page. 34 ![Page Image](https://bcdn.docswell.com/page/KJ4W8WNM71.jpg) 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 # Page. 35 ![Page Image](https://bcdn.docswell.com/page/LE1Y2Y5Y7G.jpg) 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 # Page. 36 ![Page Image](https://bcdn.docswell.com/page/GEWGRG51J2.jpg) 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 # Page. 37 ![Page Image](https://bcdn.docswell.com/page/47ZLRLNXJ3.jpg) RE:PRODUCTION / 認証認可は最初だけ。KAG では GWS を採用。 人の入口 AI の入口 Google ログイン + Cookie 30 日、社内ドメイン制限。 OAuth 2.1（MCP の標準） URL を開くだけの人のための、いつもの認証。 Claude 自身でクライアント登録して、 Proof Key for Code Exchange 日頃の会社生活でログインしてるはずなので、 (PKCE: クライアントと認可サーバー間で照合する 共有されたドキュメントを見るだけであれば、 「使い捨ての秘密鍵」) でトークンを取り、refresh を回す。 ほぼ気にすることはない。 人がやるのは、初回にブラウザで「許可する」を押すだけ。 とはいえ、これもプロダクト設計思想を十分に伝えていれば、Claudeが全て実装してくれる。 25 / 33 # Page. 38 ![Page Image](https://bcdn.docswell.com/page/YJ6WRW8PJV.jpg) RE:PRODUCTION / MVP の範囲 今回は、Claudeからの共有、Claudeからの追加編集、社内アカウント連携、のみ実装。 共同ブラッシュアップはハドルで交互に進むので、楽観ロックはコストに見合わない。要るようになってから足す。 同時更新の制御は「後勝ち + 更新者記録」まで 共同ブラッシュアップはハドルで交互に進むので、楽観ロックはコストに見合わない。要るようになってから足す。 検索は AI に寄せる 検索インデックスを作らず、一覧とタグを AI に読ませる。件数が増えたら考える。 どういった知見・成果物の蓄積方法がよいか、まだまだ検討中。今回はその１つの実現方法として。 28 / 33 # Page. 39 ![Page Image](https://bcdn.docswell.com/page/GJ5M8M9PJ4.jpg) 06 / 06 CONCLUSION まとめ 次の改善プロダクトを考えるときに。 6 31 / 33 # Page. 40 ![Page Image](https://bcdn.docswell.com/page/9E29K92Z7R.jpg) CONCLUSION / デザインの本質は戦略を具体化する事 具体 「見た目を整えること」だけが、デザインではない。 表層 表層的な見栄えやユーザビリティに留まらず、 ビジュアルデザイン レイアウトデザイン 骨格 企業やサービスの本質的な提供価値に直結する インフォメーションデザイン ナビゲーションデザイン 重要な役割を担う。 構造 UX を 5 つの階層で捉える 情報設計 インタラクションデザイン • 戦略 → 要件 → 構造 → 骨格 → 表層 の 5 階層で構成 要件 要件定義 • 各階層を行き来しながら、検討を深める • 抽象的な戦略を具体化し、求められるサービスへ磨き上げる → そのプロセスそのものが、デザインの役割。 戦略 ユーザーニーズ 目的・目標設定 抽象 UX の 5 階層モデル Jesse James Garrett 「Elements of User Experience」 # Page. 41 ![Page Image](https://bcdn.docswell.com/page/D7Y4N4YNEM.jpg) CONCLUSION 貴庁限り /「人のためのWeb UIと画面」 から 「AIのためのAPIと振る舞い」に 構造をリフレーミングする AI とのインタラクション（これから） Web UI（これまで） 具体 表層 骨格 構造 要件 戦略 抽象 ビジュアルデザイン レイアウト・ナビゲーション 情報デザイン 情報設計 → → インタラクションデザイン → 要件定義 → ユーザーニーズ・目的／目標 → Description ＝ モデルへのプロンプト 説明文の書き方が、AIの“使いこなし”を決める ツールの I/O・レスポンス エラー設計 ツールと引数の設計 今回の主題 AI との対話フロー AI に渡す操作 ＝ 提供するツールの定義 変わらない （誰の、何を助けるか） UX の 5 階層モデル Jesse James Garrett 「Elements of User Experience」を、AI とのインタラクションに読み替え # Page. 42 ![Page Image](https://bcdn.docswell.com/page/VENYXYPVJ8.jpg) 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 # Page. 43 ![Page Image](https://bcdn.docswell.com/page/Y79P8P3VE3.jpg) THANK YOU 誰もがAIを使う時代のその先。 プロダクトの形は、 “見て操作する" から “自ら振る舞う" へ 変わるかもしれない。 AIの振る舞いを開発することが、人のための UX になる…かも？ @mitsuba_yu