〜EmpX と DevX を混ぜると、使いづらくなる？〜
はじめに
「誰でも作れる時代」がやってきた
昨今、AIを取り巻く環境は劇的に変化している。
Vibe Coding（バイブコーディング） の登場により、「こんな感じで作って」という自然言語の指示だけでアプリケーションが生成できるようになった。Claude Code, Codex, Cursor、GitHub Copilot、Replit Agent などのAIコーディングツールは、もはやエンジニアの標準装備になりつつある。
さらに、ノーコード/ローコード開発プラットフォーム（Dify、n8n、Microsoft Copilot Studio など）の進化により、プログラミング知識がなくても社内向けAIエージェントを構築できる時代が到来した。
これまで「開発チームに依頼して数ヶ月待つ」必要があった社内ツールが、今では現場の担当者が数日で作れてしまう。
「ChatGPTのようなものを社内でも使いたい」
「問い合わせ対応を自動化したい」
「ドキュメント作成を効率化したい」
こうした声に対して、「じゃあ作ってみよう」と気軽に着手できる環境が整ったのだ。
しかし、「作れる」と「使われる」は別の話
ところが、いざ開発を始めてみると、こんな違和感を感じたことはないだろうか。
- 一般社員には「難しそう」「何を入力すればいいかわからない」と敬遠される
- 開発者からは「自由度が低い」「ブラックボックスすぎて改善できない」と不満が出る
- 結果として、誰にも刺さらない中途半端なアプリになる
- ローンチしたものの、1ヶ月後にはほとんど使われなくなる
技術的には作れるのに、なぜ使われないのか？
その原因の多くは、ユーザーを一括りにしてUXを設計してしまうことにある。
「社内の全員が使えるように」という善意の設計が、皮肉にも「誰にとっても使いづらい」プロダクトを生み出してしまうのだ。
本記事の目的
本記事では、社内AIエージェント開発において重要となる
toE（Employee）/ toD（Developer）というターゲット分離と、
それぞれに最適化された EmpX / DevX の考え方を、事例・ユースケースを交えて整理する。
この考え方を理解することで、「作ったけど使われない」という悲劇を防ぎ、本当に価値のある社内AIエージェントを構築できるようになるはずだ。
toE / toD とは何か
用語の定義
まず、本記事で使用する toE / toD という用語を明確に定義しよう。
| 用語 | 正式名称 | 意味 | 対象者 |
|---|---|---|---|
| toE | to Employee | 一般社員向け | AIを「使う」人 |
| toD | to Developer | 開発者向け | AIを「作る・育てる」人 |
これは、BtoB（Business to Business）やBtoC（Business to Consumer）のような、「誰に向けたプロダクトか」を明示する表記法である。
社内AIエージェントには、この2種類のユーザーが存在する。そして、この2種類をきちんと分けて設計することが、成功の鍵となる。
なぜ「toE / toD」という分け方なのか
「社内向けアプリなんだから、社員全員がユーザーでしょ？」
そう思うかもしれない。しかし、実際にはこの2つのグループは、AIエージェントに求めるものがまったく異なる。
- toE（一般社員）：AIに「答え」を求める。仕組みには興味がない。
- toD（開発者）：AIを「制御」したい。仕組みを理解し、改善したい。
この違いを無視して「全員向け」に設計すると、どちらにとっても中途半端なプロダクトになってしまう。
toE（to Employee）：一般社員向け
特徴
- 社内の一般社員（営業、人事、経理、製造、企画など）
- ITやAIは本業ではない
- アプリは「業務を終わらせるための手段」であり、それ自体が目的ではない
- 新しいツールの学習に割ける時間は限られている
典型的なユーザー像
「営業事務のAさん」
日々の見積書作成、顧客対応メール、会議の議事録作成に追われている。
ITツールは「教えられたことだけやる」タイプ。
新しいツールには興味があるが、使い方を覚える時間がもったいないと感じる。
目的・ニーズ
早く、正しく、考えずに業務を終わらせたい
このペルソナにとって、AIは「魔法の杖」であってほしい。
「何か入力したら、正しい答えが出る」——それだけでいい。
AIがどう動いているか、どんなプロンプトが裏で走っているか、そんなことには興味がない。
重視するポイント
- 迷わない（何をすればいいか明確）
- 失敗しない（間違った操作ができない設計）
- すぐ終わる（最小のステップで結果が得られる）
toD（to Developer）：開発者・IT担当向け
特徴
- 社内の開発者、情シス、IT担当、テクニカルリード
- AIエージェントを作る・育てる・運用する立場
- 保守・拡張・再利用・トラブルシューティングを考える必要がある
- システム全体のアーキテクチャを理解している（または理解する必要がある）
典型的なユーザー像
「情報システム部のBさん」
社内向けアプリの開発・保守を担当。
現場から「こういう機能がほしい」という要望を受け、実装する役割。
「なぜ動かないのか」「どう改善するか」を常に考えている。
目的・ニーズ
安全に、効率よく、継続的に作り続けたい
このペルソナにとって、AIは「制御可能なシステム」であってほしい。
中身が見えて、挙動が予測でき、問題が起きたら原因を特定できる。
そうでなければ、本番運用なんて怖くてできない。
重視するポイント
- 透明性（AIの思考過程が見える）
- 制御可能（プロンプトやフローをカスタマイズできる）
- 再現性（同じ入力に対して予測可能な出力が得られる）
- 運用性（ログ、監視、バージョン管理ができる）
なぜこの分離が重要なのか
toEとtoDは、同じAIエージェントに対して、まったく異なる期待を持っている。
| 観点 | toE | toD |
|---|---|---|
| AIへの期待 | 「答えをくれる」 | 「制御できる」 |
| 学習意欲 | 低い（覚えたくない） | 高い（理解したい） |
| エラー時の反応 | 「壊れた」「使えない」 | 「なぜ？原因は？」 |
| 成功の定義 | 業務が終わった | システムが安定稼働 |
この2つを混同したままプロダクトを作ると、必然的に「どちらにも中途半端」な結果になる。
EmpX と DevX はまったく別のUXである
用語の定義：EmpX / DevX とは
toE / toD が「誰に向けたプロダクトか」を示すのに対し、
EmpX / DevX は「その人たちにどんな体験を提供するか」を示す概念である。
| 用語 | 正式名称 | 意味 | 関連するターゲット |
|---|---|---|---|
| EmpX | Employee Experience | 従業員体験 | toE（一般社員） |
| DevX | Developer Experience | 開発者体験 | toD（開発者） |
つまり、toE / toD = ターゲット（誰に）、EmpX / DevX = 体験設計（何を） という関係だ。
なぜ「体験」を分ける必要があるのか
「ターゲットが違うのはわかった。でも、同じアプリで両方対応できないの？」
答えは No だ。なぜなら、EmpX と DevX が追求する価値は真逆だからである。
EmpX（従業員体験）とは
EmpX（Employee Experience） とは、一般社員がAIエージェントを使う際の体験全体を指す。
EmpXが目指すもの
- 「使いやすさ」：何も考えなくても操作できる
- 「安心感」：間違った操作ができない設計
- 「迷わなさ」：次に何をすべきか明確
EmpXの設計思想
「AIを使っている」と意識させない。
ただ「業務が終わる」という結果だけを提供する。
一般社員にとって、AIは手段であり目的ではない。
彼らが求めているのは「AIと会話すること」ではなく、「仕事を早く終わらせること」だ。
DevX（開発者体験）とは
DevX（Developer Experience） とは、開発者がAIエージェントを構築・運用する際の体験全体を指す。
DevXが目指すもの
- 「透明性」：AIの思考過程が見える
- 「柔軟性」：プロンプトやフローを自由にカスタマイズできる
- 「デバッグしやすさ」：問題が起きたとき原因を特定できる
DevXの設計思想
「AIを制御できる」という安心感を提供する。
ブラックボックスではなく、理解可能なシステムとして扱える。
開発者にとって、「中身がわからないシステム」は恐怖でしかない。
本番運用するためには、「なぜこの出力になったのか」を説明できる必要がある。
EmpX と DevX の違い：詳細比較
同じ「AIエージェント」を扱っていても、
toE と toD では UX の正解が真逆になることが多い。
| 観点 | EmpX（toE） | DevX（toD） |
|---|---|---|
| 自由度 | 低い方が良い（選択肢を絞る） | 高い方が良い（何でもできる） |
| 入力方式 | 選択式・定型・ガイド付き | 自由記述・プロンプト・コード |
| 出力形式 | 結果だけをシンプルに | 中間過程・ログ・メタ情報も |
| エラー設計 | そもそも起きない設計 | 原因が特定できる設計 |
| 説明方法 | 画面内ガイド・ツールチップ | ドキュメント・API仕様書 |
| 習熟曲線 | 限りなくゼロに近く | ある程度の学習を前提 |
| カスタマイズ | 不要（標準のまま使う） | 必須（自分好みに調整） |
具体例で見る「真逆のUX」
例：入力フォームの設計
EmpX（一般社員向け） ── ボタンを押すだけ。何を入力すべきか考える必要がない。
DevX（開発者向け） ── すべてを細かく設定できる。自由度が高い。
なぜ混ぜると失敗するのか
EmpX と DevX を同じ画面・同じUXで両立させようとすると、
どちらにとっても使いづらいものになりがちである。
よくある「混ぜてしまった」UI
結果
- 一般社員：「詳細設定？プロンプト？怖い…触らないでおこう」
- 開発者：「詳細設定が隠れてて面倒。プロンプトの編集範囲が狭い」
両方の機能があるのに、両方が使いづらい。これが「混ぜた」UIの末路である。
事例①：問い合わせ対応AIエージェント
社内ヘルプデスクや総務への問い合わせを自動化するAIエージェントを例に、
EmpX と DevX の違いを具体的に見てみよう。
toE（一般社員）向けUX ── EmpX
画面イメージ
回答画面イメージ
UX設計のポイント
-
選択式が主役
- 「問い合わせ内容を選ぶ」だけで解決へ導く
- 自由入力も可能だが、選択肢を先に提示
- 「何を聞けばいいかわからない」を防ぐ
-
出力は「最終回答」だけ
- AIの思考過程は見せない
- ツール呼び出し（DB検索、FAQ参照）も裏で実行
- ユーザーが見るのは「答え」だけ
-
「AIに聞いている」感を出さない
- 「AIが回答しました」ではなく「ヘルプデスクの回答」
- チャットUIよりも、Q&A形式のほうが安心感がある
- 「間違うかもしれない」という不安を与えない
成功指標
- 問い合わせ解決率
- 人間対応への escalation 率
- 利用継続率
toD（開発者）向けUX ── DevX
管理画面イメージ
UX設計のポイント
-
すべてを制御可能に
- プロンプトは自由に編集
- ツール（外部連携）のON/OFFを選択
- パラメータ（温度、トークン数）の調整
-
実行ログが見える
- どのツールが呼ばれたか
- どんな中間結果があったか
- なぜこの回答になったか
-
改善サイクルを回せる
- ABテスト機能（プロンプトAとBを比較）
- 品質ダッシュボード（解決率、満足度推移）
- 失敗ケースの分析（なぜ解決しなかったか）
成功指標
- デプロイ頻度
- 障害復旧時間（MTTR）
- プロンプト改善によるKPI向上率
事例②：資料作成・要約AIエージェント
ドキュメント作成業務を支援するAIエージェントでも、
EmpX と DevX は明確に分けて考える必要がある。
EmpX のユースケース
典型的なシナリオ
| シナリオ | ユーザーの操作 | 期待する結果 |
|---|---|---|
| 会議議事録を要約 | 音声ファイルをアップロード → 「議事録作成」ボタン | 整形された議事録が出力 |
| 資料を1枚にまとめる | PDFをアップロード → 「エグゼクティブサマリー」選択 | A4 1枚のサマリー |
| 上司向け報告書作成 | データファイル → 「週次レポート」テンプレート選択 | 報告書フォーマットで出力 |
UI設計例
ポイント
- 操作は「ファイル選択＋目的選択」の2ステップのみ
- 「どう要約するか」は聞かない（ベストな方法で自動実行）
- 専門用語を使わない（「トークン」「プロンプト」などは表示しない）
DevX のユースケース
開発者は、EmpX で提供する「テンプレート」を作成・調整する。
作業内容
| 作業 | 具体的な操作 |
|---|---|
| 要約粒度の定義 | 「3行要約」「1ページ要約」「章ごと要約」のルール設定 |
| 文体の調整 | 「である調」「ですます調」「ビジネス敬語」の切り替え |
| 部署別テンプレート | 営業向け、技術向け、経営向けの出力フォーマット作成 |
| 誤出力検知 | 「機密情報が含まれていないか」「数値に矛盾がないか」のチェックルール |
| 品質調整 | ログを見ながらプロンプトを改善 |
管理画面例
推奨アーキテクチャ：UX起点の三層構造
ここまでの議論を踏まえ、社内AIエージェントの推奨アーキテクチャを提案する。
各層の役割
| 層 | 対象ユーザー | 目的 | 特徴 |
|---|---|---|---|
| EmpX層 | 一般社員 | 業務を完了させる | 安心・簡単・迷わない |
| Agent層 | - | AIの実行基盤 | 共通化・ガードレール |
| DevX層 | 開発者 | AIを構築・改善する | 透明性・制御可能性 |
重要な設計原則
1. EmpX と DevX は物理的にUIを分ける
「同じ画面に両方の機能を詰め込む」のではなく、
完全に別のアプリ・別のURLとして提供することが重要。
2. Agent層は両方から利用される共通基盤
EmpXの画面からもDevXの画面からも、同じAgent層を利用する。
これにより、開発者がDevX層で行った改善が、自動的にEmpX層にも反映される。
3. ユーザーは自分に必要な層だけを見る
一般社員は EmpX層 だけを見る。DevX層の存在すら知らなくていい。
開発者は DevX層 で作業し、EmpX層の使われ方をログで確認する。
よくある失敗パターン
社内AIエージェント開発でありがちな失敗を、toE / toD 分離の観点から整理する。
失敗①：一般社員にプロンプト入力を求める
症状
「まずはプロンプトを入力してください」
「より良い結果を得るには、具体的に指示してください」
なぜ失敗するか
- 一般社員は「プロンプト」という概念を知らない
- 「何を書けばいいかわからない」で離脱する
- 書いても「思った結果が出ない」→「使えない」と判断される
解決策
- プロンプトはDevX層で開発者が設計
- EmpX層では選択式・テンプレート化された入力のみ
失敗②：開発者に「裏側は触れない」制約を課す
症状
「このAIツールは設定変更できません」
「プロンプトはベンダーが管理しています」
「ログは見られません」
なぜ失敗するか
- 問題が起きても原因を特定できない
- 改善したくても手が出せない
- 「ブラックボックス」への不信感が蓄積
解決策
- DevX層を用意し、開発者には完全な制御権を渡す
- ログ、プロンプト、パラメータすべてを開示
- 「自分たちで改善できる」状態を作る
失敗③：EmpXの安心感を優先しすぎて拡張不能
症状
「一般社員が混乱するから、機能は最小限に」
「シンプルさ重視で、カスタマイズ機能は付けない」
なぜ失敗するか
- 現場の多様なニーズに対応できない
- 「ちょっと違う用途」に使えない
- 利用シーンが限定され、普及しない
解決策
- EmpX層はシンプルに保ちつつ
- DevX層で「テンプレートの追加」「ユースケースの拡張」ができるようにする
- 新しいニーズに素早く対応できる仕組みを持つ
失敗④：DevXを優先しすぎて利用者が増えない
症状
「開発者は便利に使っているが、一般社員は誰も使っていない」
「機能は豊富だが、敷居が高いと言われる」
なぜ失敗するか
- 「できること」の説明ばかりで「やりたいこと」に対応していない
- 技術者目線のUIで、非技術者が迷う
- 利用者数が少なく、投資対効果が出ない
解決策
- EmpX層の設計に、現場社員の声を反映する
- 「業務ベースのユースケース」から逆算してUIを設計
- 技術用語を排除し、業務用語で説明
失敗パターンまとめ
| 失敗パターン | 根本原因 | 対策 |
|---|---|---|
| プロンプト入力を求める | toEとtoDを混同 | 層を分離 |
| 裏側を触れない | DevX層の欠如 | 開発者向け管理画面を用意 |
| 拡張不能 | EmpX層のみ設計 | DevX層で拡張可能に |
| 利用者が増えない | DevX層のみ設計 | EmpX層を現場目線で設計 |
まとめ
本記事で伝えたかったことを整理する。
3つのポイント
1. 社内AIエージェントは「全員向けアプリ」ではない
「社内の全員が使える」という理想は美しいが、
それを追求するとかえって「誰にも使われない」アプリになる。
2. toE と toD は別のプロダクトだと考える
一般社員（toE）と開発者（toD）では、求めるものが根本的に異なる。
同じ画面で両方を満たそうとしないこと。
3. EmpX と DevX を明確に分離することで、初めてスケールする
- EmpX層：シンプル、安心、業務に集中
- DevX層：透明、柔軟、改善可能
この2つを物理的に分け、それぞれを磨き込むことで、
両方のユーザーに愛されるプロダクトになる。
本当に重要なこと
AIエージェント開発において重要なのは
「どんなAIを使うか」ではなく
「誰のUXを最優先するか」を決めることである。
GPT-5.2を使うか、Claudeを使うか、Geminiを使うか。
の議論の前に、まず「誰のために作るか」を明確にしよう。
ユーザーが定義できていないプロダクトは、
どんなに優れたAIを使っても、成功しない。
おわりに
もし社内で AI エージェントを展開しようとしているなら、
まずは toE / toD を分けて言語化するところから始めてほしい。
やってみてほしいこと
それだけで、設計・議論・合意形成の質は大きく変わるはずです。
この記事が、あなたの社内AIエージェント開発の一助になれば幸いである。