修士論文 仮構成・意義の整理（全面改稿ドラフト）

作成日: 2026-05-02。これは確定稿ではなく、研究の切り口・意義・方法を検査するための作業メモ。

参照注意: このファイルは 2026-05-02 の途中段階の広げたドラフトであり、現時点の最新版ではない。「委譲条件」「ズレ」「役割別の意義」が前に出すぎている箇所がある。今後のまとめ文章では、研究の入口・定義・意義については 2026-05-02-reframed-background-problem-purpose-significance.md と 2026-05-02-significance-as-conceptual-contribution.md を優先する。

0. この改稿での前提

このドラフトでは、研究の中心を「README をどう書けば AI が読むか」や「Claude Design の使い方」に置かない。インターンで扱っている README、Files、Claude Code の skill、Figma Make、Claude Design、デザインシステムの GitHub リポジトリなどは、研究対象そのものというより、AI に実行を委任するために、人間側・組織側がどのような意図・制約・評価基準を外部化しなければならないかを観察できる環境として扱う。

また、「人間側は何を期待していたか」を毎回心理的に切り出して記録する、という方向にはしない。ここで見るべき「期待」は、主観的な気分ではなく、次のような作業上の前提として扱う。

  • 何を AI に任せたつもりだったのか
  • どこまでを AI が判断してよく、どこから人間が判断する必要があったのか
  • どのデザイン原則・コンポーネント・トーン・ブランド規約を守るべきだったのか
  • 何が出力されれば「使える」と判断できたのか
  • 失敗したとき、情報の不足・解釈のズレ・参照の不足・評価基準の曖昧さのどこに原因が見えたのか

つまり、本研究で扱うのは「期待」という内面の推測ではなく、委譲を成立させる条件である。

1. 研究題名（仮）

第一候補

AI に実行を委任するデザイン実践における、意図・制約・評価基準の外部化に関する考察

第二候補

AI 介在型サービス設計における委譲の成立条件——自然言語・デザインシステム・評価基準のあいだに生じるズレの整理

第三候補

AI が実行を担うデジタルサービスにおける相互作用構造の変化——意図の表出化と委譲条件の観点から

第四候補

AI が実行を担うデザイン実践における人間の役割変化——判断基準の外部化・評価・方向づけの観点から

短い言い換え

  • AI 時代のデザインにおける「任せるための設計」
  • 自然言語でデザインを委譲するとき、何を明示する必要があるのか
  • AI 介在型 UI / UX における、意図・制約・評価の受け渡し
  • AI による制作実行と、人間による判断・評価・方向づけ

2. 研究の背景

近年、ChatGPT、Gemini、Claude、Cursor、Claude Code、Figma Make、Claude Design、Genspark、Canva の AI 機能など、自然言語で依頼し、AI が実行や生成を担うツールが急速に広がっている。これらのツールでは、ユーザーは従来のようにボタン・メニュー・スライダー・画面遷移を一つずつ操作するだけでなく、「こういう画面を作って」「この資料をスライド化して」「このブランドに合う UI にして」「このコードベースのルールに従って実装して」といった形で、目的や意図を自然言語で渡し、実行を AI に委任する。

この変化は、単に入力手段がキーボードやマウスからチャットに変わったという話ではない。従来の UI では、ユーザーは操作対象を見ながら、自分の手で段階的に行為を選び、システムの反応を見て修正していた。たとえば Figma で画面を作る場合、フレームを作り、Auto Layout を設定し、コンポーネントを配置し、色や余白を調整する。PowerPoint でスライドを作る場合も、テンプレートを選び、見出しを置き、図を作り、視覚的なバランスを見ながら編集する。ここでは、ユーザーの認知負荷は主に「どの操作をどの順番で行うか」「どの UI 要素を使えばよいか」にかかっていた。

一方、Figma Make や Claude Design のようなツールでは、ユーザーは最初から細かい操作を積むのではなく、「採用管理 SaaS の管理画面を作って」「社内向けの説明スライドをブランドガイドラインに沿って作って」「既存のデザインシステムに合う Web アプリ画面にして」といった依頼を行う。このとき重要になるのは、操作手順ではなく、何を作りたいのか、どの制約を守るべきか、どの既存資産を参照すべきか、どの水準ならよい出力と言えるのかである。

つまり、AI が実行を担う場面では、認知負荷がなくなるのではなく、負荷の位置が変わる。操作の負荷は下がるが、目的・意図・文脈・制約・評価基準を外部化する負荷が上がる。これは一般ユーザーが AI サービスを使う場面にも、デザイナーや開発者が AI ツールを使う場面にも現れる。

たとえば、Genspark のようなサービスでは、トップページに自由入力欄だけでなく、「AI スライド」「AI ドキュメント」「AI 画像生成」などの目的別入り口が並ぶ。これは、ユーザーの自由な言語化に任せきるのではなく、サービス側が先に意図カテゴリを提示し、ユーザーが「何を頼みたいか」を選びやすくする設計と見なせる。ChatGPT や Gemini でも、「さらに詳しく調べますか」「次にこの観点を深掘りできます」といった提案が表示されることがある。これも、ユーザーが自分の意図を次の依頼へ展開するための補助と捉えられる。

さらに、Claude Code や Cursor のような開発支援ツールでは、自然言語で実装を依頼できる一方で、プロジェクト固有のルール、コンポーネントの使い方、テスト方針、ファイル構成、禁止事項を明示しておかなければ、AI は一般的にはそれらしいがプロジェクトには合わないコードを書きやすい。そのため、ルールファイル、README、skill、AGENTS.md、デザインシステム文書などが重要になる。これらは単なるドキュメントではなく、AI に委譲するための媒介物である。

インターンで取り組んでいる、社内デザインシステムを Claude Design や Claude Code などの AI ツールが参照しやすい形に整える試行錯誤も、この流れの中に位置づけられる。GitHub 上にすでに構造的に管理されているデザインシステムがあっても、それがそのまま AI にとって「使える知識」になるとは限らない。AI は資料を読んでいるように見えて、重要なコンポーネントを使わなかったり、ブランドトーンを外したり、既存の設計意図を反映しない出力を生成することがある。そこで README にファイル構成と読むべき順序を書いたり、skill として判断基準を明文化したり、例や禁止事項を追加したりする必要が生じる。

この実践は、特定ツールのハックではなく、より一般的には、AI に任せるために、人間や組織が持っていた暗黙の判断基準をどのように外部化するかという問題である。

同時に、この変化はデザイナーの役割にも関わる。Figma や Illustrator で手を動かして画面やグラフィックを作る作業の一部が AI によって代替・補助されるとき、「デザイナーは不要になるのか」という議論が起こりやすい。しかし、より概念的に捉えるなら、これは職能の消失というより、実行の一部が AI に移ることで、人間側に残る設計行為が変化するという現象である。人間側には、何を良いとするかを見分ける審美眼、ブランドらしさやプロダクトらしさを保つ意思、情報設計やコンポーネント選択の判断基準、AI の出力を評価して次の方向を与える役割が残る。さらに、その判断基準を skill、デザインシステム、レビュー観点、サンプル、禁止事項として外部化すること自体が、AI 介在型のデザイン実践における新しい設計行為になりうる。

3. 問題意識

AI ツールの導入をめぐる議論では、「モデルの性能が上がれば解決する」「プロンプトをうまく書けばよい」「デザインシステムを読み込ませればよい」といった言い方がされやすい。しかし実際には、それだけでは説明しきれないズレが起こる。

たとえば、Claude Design に組織のデザインシステムを渡したとしても、AI が出力する画面が期待したほどデザインシステムに沿わないことがある。このとき原因は一つではない。

  • そもそも AI が必要なファイルを参照していない
  • 参照はしているが、どのルールが優先されるべきか分かっていない
  • コンポーネントの見た目は近いが、使いどころを誤っている
  • 色やタイポグラフィは合っているが、情報設計や余白のリズムが合っていない
  • 依頼者側が「デザインシステム準拠」と言ったとき、何を準拠とみなすかを明示できていない
  • AI がどこまで自律的に判断してよいかが決まっていない
  • 出力後の評価観点が共有されていない

これらをすべて「AI が期待通りに動かなかった」とまとめてしまうと、どこを改善すればよいか分からない。プロンプトを直すべきなのか、README を直すべきなのか、デザインシステムの構造を変えるべきなのか、評価基準を追加すべきなのか、そもそも AI に委譲する範囲を狭めるべきなのかが見えなくなる。

同じことは、エンドユーザー向けの AI サービスにも起こる。ユーザーが ChatGPT に旅行計画を頼む、Gemini に調査を頼む、Genspark にスライドを作らせる、Figma Make に画面を生成させる、といった場面で、ユーザーは「いい感じにやってほしい」と思う。しかし AI は、ユーザーの頭の中にある「いい感じ」の判断基準をそのまま知っているわけではない。出力が悪いとき、それはモデル性能の問題だけではなく、目的・制約・文脈・評価基準の受け渡しが不十分だった可能性がある。

ここで重要なのは、「ユーザーにもっと詳細なプロンプトを書かせればよい」という単純な話ではない。むしろ、どの情報をユーザーが言語化すべきで、どの情報は UI やテンプレートやデザインシステムや履歴や候補提示が補助すべきなのかが設計問題になる。AI 時代の UI / UX では、操作ステップを分かりやすくするだけでなく、委譲に必要な情報をどう引き出し、どう補い、どう評価可能にするかが問われる。

4. 研究の中心仮説

現時点での中心仮説は次のように置ける。

AI が実行を担うデジタルサービスやデザイン実践では、ユーザーや組織の負担は単純に減るのではなく、操作の負担から、意図・制約・評価基準を外部化し、AI とのあいだで委譲条件を整える負担へ移動する。

この仮説に、もう一つの補助仮説を加える。

AI が制作や実装の実行を担うほど、人間の役割は「手を動かして作ること」だけから、「何を良いとするかを定義し、その判断基準を AI が扱える形に外部化し、出力を評価して方向づけること」へ重心を移していく。

この仮説は、以前から考えてきた「認知負荷の移行」と接続している。ただし、ここでは「言語化負荷」という言葉だけでは足りない。なぜなら、必要なのは単に長い文章を書くことではなく、AI が実行に使える形で、目的・文脈・制約・参照資産・優先順位・評価基準を配置することだからである。

したがって、本研究では「言語化」を広く捉え直す。言語化とは、プロンプト文を書くことだけではない。

  • チャットに依頼文を書くこと
  • UI が目的カテゴリを提示すること
  • README が参照順序を示すこと
  • skill が判断基準を明示すること
  • デザインシステムがコンポーネントの使い分けを記述すること
  • サンプル画面が「良い出力」の例として機能すること
  • チェックリストが評価観点を共有すること
  • 承認 UI が委譲範囲を制御すること

これらはすべて、AI に委譲するための外部化である。研究の焦点は、自然言語そのものではなく、AI に任せるために必要な情報が、どのような媒介を通じて外に出されるのかにある。

この意味で、AI 介在型のデザインにおける「人間らしい価値」は、単に手作業の巧みさに閉じない。むしろ、どの方向に探索するか、何を採用しないか、何をブランドらしいと判断するか、どの程度の水準を60点・80点・100点とみなすか、といった評価と方向づけに現れる。AI は大量の案を生成できるが、その案が「このサービスにとって良い」と言えるかどうかは、まだ人間や組織が持つ価値判断に依存する。したがって本研究では、AI への委譲条件とあわせて、AI の出力を評価し方向づける人間側の役割も扱う。

5. 研究目的

本研究の目的は、AI が実行を担うサービスやデザイン実践において、委譲を成立させるために何を考慮すべきかを、認知・相互作用・設計の観点から整理することである。

より具体的には、次の三点を目指す。

第一に、従来の UI / UX で重視されてきた「操作しやすさ」「分かりやすさ」「フィードバック」といった観点が、AI 介在型の体験ではどのように拡張される必要があるのかを整理する。たとえば、ボタンの位置や画面遷移だけでなく、ユーザーが AI に何を委譲しているのか、どの段階で人間が確認・承認するのか、AI の判断根拠をどの程度見せる必要があるのか、といった観点を扱う。

第二に、AI に実行を委任する際に生じるズレを分類する。たとえば、資料があるのに参照されない「参照のズレ」、ルールを読んでいても意味を取り違える「解釈のズレ」、適用すべき優先順位を誤る「優先順位のズレ」、出力の良し悪しを人間側が判断できない「評価のズレ」、どこまで AI に任せてよいか曖昧な「委譲範囲のズレ」などである。

第三に、それらのズレを踏まえて、AI を用いたサービス設計・デザイン実践・プロダクト開発において、どのような論点を見落とさないようにすべきかを示す。これは強い意味での「設計原則の提言」ではなく、今後の研究や実務が検討すべき場所を整理するための論点の地図である。

第四に、AI が画面設計、グラフィック、スライド、UI 実装などの実行を担うようになる中で、デザイナーやプロダクト開発者に残る役割を、職能論ではなく相互作用構造の変化として整理する。つまり、「デザイナーは何を作る人か」ではなく、AI が作れるようになったとき、人間は何を判断し、何を外部化し、どこで出力に介入するのかを問う。

6. 研究課題

RQ1: AI に実行を委任する場面では、どの情報が外部化される必要があるのか

たとえば、画面生成やスライド生成を AI に任せる場合、ユーザーや組織は何を明示する必要があるのか。目的、利用文脈、対象ユーザー、デザインシステム、ブランドトーン、禁止事項、出力形式、評価基準などのうち、どれがどの場面で重要になるのかを整理する。

RQ2: 外部化が不足したとき、どのようなズレが起きるのか

AI が資料を読まない、読んでも使わない、見た目だけ真似る、意図と異なる判断をする、出力後の評価が難しい、といった失敗を分類する。これは「AI が悪い」と一括りにせず、相互作用のどこでズレたのかを見えるようにするためである。

RQ3: 既存の認知・HCI・HAI の枠組みで、どこまで説明できるのか

ノーマンの7段階モデル、メンタルモデル、実行のガルフ／評価のガルフ、エンビジョニングのガルフ、Human-AI Interaction のガイドラインなどを参照し、どこが継承でき、どこで拡張が必要になるかを整理する。

RQ4: AI 介在型のサービスやデザイン実践を改善するために、どのような問いを設計時に持つべきか

最終的には、プロダクトデザイナー、UX リサーチャー、PM、開発者が、AI 機能や AI ツールを設計・導入・評価するときに使える問いの形へ落とす。たとえば、「この機能では、ユーザーは何を AI に委譲しているのか」「委譲の境界は UI 上で分かるか」「AI が守るべき制約はどこに表現されているか」「出力の評価基準はユーザーに見えているか」といった問いである。

RQ5: AI が制作・実装の実行を担うとき、人間側に残る設計行為は何か

デザイナーやプロダクト開発者の役割を、「手を動かして制作する人」から「判断基準を形成し、AI が扱える形に外部化し、出力を評価し、次の方向を与える人」へと捉え直せるかを検討する。具体的には、審美眼、ブランドの意思、情報設計の暗黙知、デザインシステムの運用、レビュー観点、AI への指示・制約の設計が、どのように人間側の役割として残る／強まるのかを見る。

7. インターン環境の位置づけ

インターンで取り組んでいることは、研究の中心素材になりうる。ただし、それは「社内の Claude Design 導入事例」として前面に出すという意味ではない。むしろ、AI にデザイン実行を委譲するために、人間や組織が何を外部化しなければならないかを観察できる実践環境として位置づける。

現在のインターン環境では、社内にある GitHub ベースのデザインシステム、Figma のデザイン資産、Claude Design、Figma Make、Claude Code、skill、README、Files などが関わっている。これらはそれぞれ別々のツールや資料に見えるが、概念的には次のような役割を持つ。

  • デザインシステム: 組織のデザイン判断やコンポーネント利用規則を蓄積するもの
  • GitHub リポジトリ: ルールや資産を構造的に管理するもの
  • README: AI や人間が全体構造と読む順序を把握するための入口
  • skill: AI に特定の判断基準や作業手順を渡すための媒介
  • Claude Design / Figma Make: 自然言語から画面・スライド・プロトタイプを生成する実行環境
  • Claude Code: コードやドキュメントを編集し、プロジェクト固有の規則に従って実装する実行環境
  • 人間のレビュー: AI の出力が組織の基準に合っているかを判断する評価過程

この環境では、「AI に作らせる」と言っても、実際には多くの媒介が必要になる。デザインシステムがあるだけでは足りず、どのファイルを読むか、どのルールを優先するか、どのコンポーネントを使うか、どの出力を良しとするかを、AI が扱える形にする必要がある。ここに、研究として扱える切り口がある。

観察単位は「期待」ではなく「委譲エピソード」

人間側が何を期待していたかを心理的に記録するのではなく、作業単位として「委譲エピソード」を見る。

委譲エピソードとは、たとえば次のような一まとまりである。

  1. AI に任せた作業
    例: 社内デザインシステムに沿ったランディングページを作る、既存 UI パターンに沿った管理画面を作る、ブランドに沿ったスライドを作る

  2. AI に渡した媒介
    例: README、デザインシステム文書、コンポーネント一覧、Figma ファイル、既存画面、skill、プロンプト

  3. AI の出力
    例: 画面案、スライド案、HTML、React コンポーネント、ワイヤーフレーム

  4. 出力で起きたズレ
    例: 色は合っているがコンポーネントの使い方が違う、余白がブランドらしくない、禁止されている表現を使った、情報設計が浅い、既存の UI パターンを参照しなかった

  5. 改善のための介入
    例: README に参照順を追記する、skill に When to use / When not to use を書く、良い例・悪い例を追加する、評価チェックリストを作る

  6. 介入後の変化
    例: 参照率が上がった、出力の一貫性が増した、別の失敗が出た、人間側のレビュー観点が明確になった

このように見ると、研究対象は「人間の期待」ではなく、委譲がうまく成立した／しなかった構造になる。

8. 想定される分析カテゴリ

8.1 参照のズレ

必要な資料やデザインシステムが存在しているにもかかわらず、AI がそれを読まない、または読んだ形跡が出力に現れない状態。README やファイル構成が入口として機能していない場合に起こる。

例: Claude Design にデザインシステム Files を渡しているのに、生成された画面がデフォルトの汎用的な SaaS UI のようになる。

8.2 優先順位のズレ

複数の資料やルールがあるとき、どの情報を優先すべきか AI が判断できない状態。

例: ブランドカラーよりも一般的な UI ライブラリ風の色使いを優先してしまう。既存コンポーネントを使うべき場面で、新しい見た目を作ってしまう。

8.3 解釈のズレ

AI がルールを読んではいるが、意味を取り違えている状態。

例: 「カードコンポーネントを使う」と書かれているためカード風の見た目を作るが、本来のデザインシステムではカードを使うべき情報単位が決まっており、その意味的な使い分けまでは反映されていない。

8.4 適用のズレ

AI がルールやコンポーネントを理解しているように見えるが、最終出力に安定して反映されない状態。

例: 最初の画面では余白ルールを守るが、次の画面では崩れる。スライド1枚目はブランドに合うが、後半で汎用テンプレートのようになる。

8.5 評価のズレ

AI の出力に対して、人間側が何を基準に「よい」と判断すればよいか曖昧な状態。

例: 見た目は整っているが、本当に社内デザインシステム準拠と言えるのか判断しにくい。レビューする人によって「良い」の基準が変わる。

8.6 委譲範囲のズレ

AI がどこまで自律的に判断してよいか、どこから人間が確認すべきかが曖昧な状態。

例: AI が画面構成まで勝手に決めてよいのか、コンポーネント選択だけ任せるのか、文章や情報設計まで任せるのかが決まっていない。

8.7 修復ループのズレ

失敗したときに、次に何を修正すれば改善するのかが分からない状態。

例: プロンプトを直すべきか、README を直すべきか、skill を直すべきか、デザインシステム側の説明不足なのか判断できない。

8.8 判断基準の外部化不足

人間や組織の中には判断基準があるが、それが AI の実行に使える形で明示されていない状態。これは「AI が読まない」以前に、そもそも何を守るべきか、何を良いとするかが外部化されていない場合に起こる。

例: デザイナーは「このブランドらしくない」と判断できるが、その理由が余白、角丸、言葉遣い、情報密度、写真のトーン、コンポーネントの使い方のどこにあるのかが文書化されていない。そのため AI に何度生成させても、見た目は整っているがブランドの味が出ない。

8.9 人間側の評価・方向づけの不足

AI が出力を生成したあと、人間がそれをどう見て、どの観点で修正方向を与えるかが曖昧な状態。生成物が増えても、評価と方向づけが弱いと、試行錯誤は増えるが品質は上がりにくい。

例: AI が10案の画面を出したが、どれをなぜ採用するか、どの案のどの要素を次に活かすかを言語化できず、「なんとなく違う」という修正依頼だけが繰り返される。

9. 既存研究・概念との接続

ノーマンの7段階モデル

ノーマンの7段階モデルは、目標、計画、行為の設定、実行、知覚、解釈、評価という流れでユーザーの行為を捉える。本研究では、この構造自体は参照できるが、AI 介在型の体験では各段階の担い手と表出形式が変わると考える。

従来の UI では、行為の設定と実行はユーザーの操作として現れた。AI 介在型の体験では、実行が AI に委譲され、目標・計画・行為の設定がプロンプトや UI 選択、参照資料、skill、デザインシステムとして外部化される。つまり、7段階モデルはそのまま捨てるのではなく、どの段階が AI に移り、どの段階が人間に残り、どの段階が媒介物として外に出るのかを見るために使える。

実行のガルフ／評価のガルフ

従来の実行のガルフは、ユーザーがやりたいことをシステム上の操作に変換できるかという問題だった。AI 介在型の体験では、これは「やりたいことを AI に実行可能な委譲条件として渡せるか」という問題に変わる。評価のガルフも、単に出力を見て成功か失敗かを判断するだけでなく、「なぜこの出力になったか」「どの制約を守ったか」「次に何を修正すべきか」を判断できるかという問題になる。

メンタルモデル

AI 介在型サービスでは、ユーザーはシステムを単なる道具ではなく、意図を汲む相手のように扱いやすい。ここで期待の人間化が起こる可能性がある。ただし、教授からのフィードバックにもあったように、メンタルモデルという語は広い。したがって本文では、メンタルモデルを「ユーザーが、AI の能力・制約・反応の仕方について持つ予測の枠組み」として一旦限定し、必要に応じてスキーマや知覚／認知の議論と分ける。

HAI ガイドライン

Amershi et al. の Human-AI Interaction ガイドラインや、生成 AI 向けの設計原則は、AI が不確実性を持つこと、ユーザーに適切な期待を形成させること、必要に応じて人間が介入できることを重視している。本研究はそれらを参照しながら、特にデザイン・UI・アプリ・スライド生成のような生成実行を委譲する場面に焦点を当てる。

エンビジョニングのガルフ

LLM との相互作用では、ユーザーが「AI に何ができるか」「どう頼めばよいか」「どのような出力を期待できるか」を想像しにくい。この問題は、Figma Make や Claude Design のようなデザイン生成ツールでも現れる。ユーザーは「管理画面を作って」と言えるが、その結果としてどの粒度の情報設計・コンポーネント選択・コピーライティング・ビジュアル表現が必要になるかを最初から明確に想像できるとは限らない。

デザイナーの役割変化

AI が画面、スライド、グラフィック、UI 実装の一部を担うようになると、デザイナーの役割は「実行者」から「判断者」「編集者」「方向づける人」「組織知を外部化する人」へ重心を移す可能性がある。これは、デザイナーが不要になるという話ではなく、デザイナーの価値が、手作業の実行だけでなく、判断基準の形成と運用に現れるようになるという話である。

ここでの判断基準には、単なる美しさだけでなく、情報の優先順位、コンポーネントの意味的な使い分け、ブランドの一貫性、ユーザーの認知負荷、アクセシビリティ、プロダクトの思想、組織としての「らしさ」が含まれる。AI が実行を担うほど、これらの判断基準を暗黙のままにしておくことは難しくなり、skill、デザインシステム、チェックリスト、サンプル、レビューコメントとして外部化する必要が出てくる。

10. 研究方法・方針

10.1 文献レビュー

HCI、HAI、認知負荷、メンタルモデル、生成 AI UX、AI エージェント、デザインシステム、プロンプトベースのインタラクションに関する文献を整理する。目的は、先行研究を網羅することだけではなく、本研究で使う概念の射程を明確にすることである。

特に以下を重点的に見る。

  • ノーマンの7段階モデル、実行のガルフ、評価のガルフ
  • メンタルモデル、スキーマ、知覚と認知の区別
  • Human-AI Interaction ガイドライン
  • LLM におけるエンビジョニングのガルフ
  • 生成 AI アプリケーションの設計原則
  • インテント指向 UI / 自然言語 UI に関する実務論
  • デザインシステムの AI ネイティブ化、組織知の形式知化に関する事例
  • AI 時代におけるデザイナーの役割、Human-AI co-creation、デザイン実践の変化に関する議論

10.2 公開サービス・ツールの観察

ChatGPT、Gemini、Claude、Genspark、Figma Make、Claude Design、Cursor、Claude Code、Canva AI など、自然言語で生成や実行を委譲するツールを観察する。ここでは、出力品質の優劣を比較するのではなく、次の点を見る。

  • ユーザーに何を入力させているか
  • 目的カテゴリやテンプレートをどう提示しているか
  • AI がどこまで自律的に実行する設計か
  • 人間が確認・修正・承認する接点がどこにあるか
  • 失敗したときに、修正の手がかりがあるか
  • 生成物の評価基準が UI 上に現れているか
  • 人間が「良い／悪い」を判断するための観点が支援されているか
  • AI が生成した複数案を、人間が比較・選択・方向づけるための UI や会話があるか

10.3 インターン実践の探索的ケース記録

インターン環境は、統制実験ではなく、探索的なケース記録として扱う。社内情報や固有名詞は匿名化し、研究では具体的な成果物そのものではなく、委譲の構造とズレの型を扱う。

記録する場合の単位は、次のような簡易フォーマットにする。

委譲エピソード ID:
作らせようとしたもの:
使ったツール:
渡した媒介物:
出力で起きたズレ:
改善のために追加・変更した媒介:
改善後の変化:
見えてきた論点:

ここでも、人間の内面的期待を細かく記録するのではなく、何を任せ、何を渡し、どこでズレ、何を足すと改善したかを見る。

10.4 概念整理と図式化

文献と観察を往復しながら、AI に実行を委譲する場面における構造を図式化する。たとえば、以下のようなモデルを検討する。

人間・組織の意図
  ↓ 外部化
媒介物（プロンプト / UI / README / skill / デザインシステム / 例 / 評価観点）
  ↓ 解釈
AI の生成・実行
  ↓ 出力
人間による知覚・解釈・評価
  ↓ 修復
媒介物・判断基準・委譲範囲の更新

この図式は最終的に洗練する必要があるが、現段階では、研究が何を見ているかを説明する足場になる。

11. 期待される成果

11.1 委譲条件マップ

AI に実行を委譲する際に考慮すべき条件を整理する。

  • 目的: 何を達成したいのか
  • 文脈: 誰に向けたものか、どの場面で使うのか
  • 制約: 守るべきルール、ブランド、法務・倫理、アクセシビリティ
  • 参照資産: デザインシステム、既存画面、コンポーネント、過去資料
  • 優先順位: 複数ルールが衝突したとき何を優先するか
  • 委譲範囲: AI が判断してよい範囲、人間が確認すべき範囲
  • 評価基準: 何をもって良い出力とするか
  • 判断基準: 何を「らしい」「良い」「採用しない」と判断するか
  • 人間の介入点: どの段階で人間が評価・選択・方向づけを行うか
  • 修復手段: 失敗したとき、何を直せばよいか

11.2 ズレの分類

AI 介在型のデザイン実践やサービス利用で起きるズレを、参照、優先順位、解釈、適用、評価、委譲範囲、修復ループの観点から整理する。

11.3 既存フレームとの接続表

ノーマンの7段階モデル、実行／評価のガルフ、メンタルモデル、HAI ガイドラインなどが、AI 介在型の体験を説明するうえでどこまで有効で、どこに補助線が必要かを示す。

11.4 設計・研究のための問い

最終的に、以下のような問いを提示できるとよい。

  • この AI 機能では、ユーザーは何を AI に委譲しているのか
  • 委譲の範囲は UI 上で明示されているか
  • AI が守るべき制約は、どこに表現されているか
  • ユーザーは、自分が何を言語化すべきか分かるか
  • 言語化しきれない情報を、UI やテンプレートが補っているか
  • 出力が失敗したとき、ユーザーは次に何を修正すればよいか分かるか
  • 出力の評価基準は共有されているか
  • AI の判断に対して、人間が確認・撤回・修正できる接点があるか
  • 既存のデザインシステムや組織知は、AI が扱える形に外部化されているか
  • AI に任せることで、どの認知負荷が減り、どの認知負荷が増えているか
  • 人間が評価・選択・方向づけを行う接点は設計されているか
  • デザイナーの暗黙知やブランドの意思は、AI が扱える媒介物として表現されているか

11.5 人間側に残る設計行為の整理

AI によって制作実行の一部が自動化されるとき、人間側に残る設計行為を整理する。

  • 判断基準をつくる: 何を良いデザインとみなすかを言語化する
  • 制約を設計する: AI が守るべき範囲、禁止事項、優先順位を定める
  • 方向を与える: 生成された案のどこを伸ばし、どこを捨てるかを決める
  • 評価する: 出力が目的・ブランド・ユーザー文脈に合っているかを見る
  • 暗黙知を外部化する: デザイナーの経験的判断を skill やデザインシステムに落とす
  • ブランドの意思を保つ: コモディティ化しやすい生成物に対して、固有の態度やらしさを維持する

12. 研究の意義

本研究の意義は、AI ツールの使い方を紹介することではない。また、特定のプロンプト技法や特定ツールの攻略法を提示することでもない。意義は、AI に実行を委任する場面で起きているズレを、設計・認知・相互作用の問題として説明できる形にすることにある。

現在、生成 AI ツールは「誰でも自然言語で作れる」「非デザイナーでも画面やスライドを生成できる」「AI がコードやデザインを実行してくれる」と語られやすい。しかし、実際に使うと、自然言語で頼めることと、良い出力が安定して得られることの間には距離がある。特にデザインや UI のように、見た目、構造、コンテキスト、ブランド、情報設計、利用者の認知が絡む領域では、AI が実行するために必要な前提が多い。

この距離を「プロンプトが悪い」「モデルがまだ弱い」とだけ説明すると、設計上の論点が見えなくなる。本研究は、その距離を、委譲条件の不足やズレとして捉え直す。つまり、AI に任せるためには、目的、文脈、制約、参照資産、評価基準、委譲範囲がどのように表現されている必要があるのかを整理する。

加えて、本研究は「AI が作れるようになったとき、人間は何をするのか」という問いにも応答する。デザイナーや開発者の手作業がすぐになくなるという話ではなく、手を動かす作業の一部が AI に移ることで、人間側の価値が判断基準の形成・外部化・評価・方向づけにより強く現れるという視点を示す。これは、AI 時代のデザイナー論を職能の存続論争として扱うのではなく、AI 介在型の相互作用構造の中で、人間に残る設計行為を整理する試みである。

この整理によって、プロダクトデザイナーや UX リサーチャーは、AI 機能を評価するときに、単に「便利か」「速いか」だけでなく、「ユーザーは何を委譲しているのか」「何を言語化する負担が残っているのか」「失敗したときの修復経路はあるか」を見られるようになる。PM や開発者は、AI 機能をロードマップに入れるときに、「モデルを入れる」だけでなく、「委譲の境界」「制約の表現」「人間の確認点」を議論できる。研究者にとっては、AI 介在型の体験を、既存の HCI / HAI の枠組みに接続しながら扱うための語彙が得られる。

この研究は、明日から使える万能チェックリストを出すことを目指すものではない。ただし、最終的には、サービス設計や研究計画の場で使える問いを提示することを目指す。たとえば、「この AI ツールは何をユーザーに言語化させているか」「どの情報は UI が補助すべきか」「AI が守るべき制約はどこに置かれているか」「出力の評価基準は誰に見えているか」といった問いである。こうした問いがあれば、AI 介在型のサービスを評価・設計するとき、毎回ゼロから考え直す必要が減る。

13. この研究がもたらすもの

デザイナー・UX リサーチャーに対して

AI 機能や AI ツールを評価するとき、従来のユーザビリティ評価だけでは拾いにくい論点を見つける視点を提供する。たとえば、出力の見た目が整っているかだけでなく、ユーザーが意図をどの程度明示する必要があったのか、AI がどの制約を守ったのか、修正の会話がどのように進んだのかを見ることができる。また、AI が画面やスライドを生成できるようになったときに、デザイナーの役割を「手で作ること」だけに閉じず、判断基準をつくり、外部化し、AI 出力を評価して方向づけることとして捉え直せる。

PM・開発者に対して

AI をサービスに組み込むとき、単に「生成できる機能」を追加するだけでなく、委譲範囲、制約、承認、撤回、評価基準を要件として扱う視点を提供する。

研究者・学生に対して

変化が速い AI 領域で、特定ツールの短命な現象に引きずられず、認知と相互作用の構造として論じるための方法を提供する。

自分自身の研究実践に対して

インターンで触れている AI ツール活用の試行錯誤を、単なる実務経験ではなく、研究上の観察環境として位置づけられる。これにより、「AI とデザインを扱っている」という広いテーマが、委譲条件の整理という具体的な切り口を持つ。

14. 章立て案

第1章 序論

  • AI が実行を担うサービス・ツールの広がり
  • デザイン、UI、アプリ、スライド生成などへの影響
  • 研究の問いと目的
  • インターン環境の位置づけ

第2章 関連研究

  • ノーマンの7段階モデル
  • 実行のガルフ／評価のガルフ
  • メンタルモデル
  • Human-AI Interaction
  • LLM とエンビジョニングのガルフ
  • 生成 AI UX / AI エージェント / デザインシステム

第3章 AI 介在型相互作用の整理

  • 操作から委譲へ
  • 言語化負荷から外部化負荷へ
  • 委譲条件の構成要素
  • 人間・AI・システム・媒介物の関係
  • 実行の委譲と、人間側に残る判断・評価・方向づけ

第4章 事例観察・実践記録

  • 公開サービスの UI パターン観察
  • インターン環境の匿名化された委譲エピソード
  • ズレの分類
  • 改善介入のパターン

第5章 考察

  • 既存フレームで説明できること／できないこと
  • メンタルモデルのギャップの性質変化
  • 期待の人間化と委譲境界
  • デザインシステムや組織知の外部化との接続
  • デザイナーの役割変化を「実行」から「判断基準の設計」への移行として捉えられるか

第6章 結論

  • 委譲条件マップ
  • 設計・研究のための問い
  • 限界と今後の課題

15. 現時点での言い切り候補

論文の中心的な主張として、現時点では次のような言い方が候補になる。

AI が実行を担うサービスにおいて重要になるのは、単に自然言語で依頼できることではなく、目的・文脈・制約・評価基準をどのように外部化し、AI と人間のあいだで委譲条件を成立させるかである。

AI 介在型の UI / UX では、操作の分かりやすさに加えて、委譲の分かりやすさ、制約の渡しやすさ、出力の評価しやすさが設計対象になる。

生成 AI によるデザイン支援の失敗は、モデル品質だけでなく、参照・解釈・適用・評価・委譲範囲のズレとして分解できる。

デザインシステムや README や skill は、単なる補助資料ではなく、AI に委譲するための媒介物として捉えられる。

AI がデザインの実行を担うほど、人間側の役割は、作業の実行だけでなく、判断基準を形成し、AI が扱える形に外部化し、出力を評価して方向づけることへ重心を移す。

デザイナーの暗黙知や審美眼は、AI 時代に不要になるのではなく、AI の生成物を評価し、ブランドの一貫性を保ち、組織のデザイン判断を媒介物として整備するために重要になる。

16. まだ詰めるべき点

  • 「委譲条件」という語を使うか、「行動契約」「外部化」「媒介物」など別の語を中心にするか
  • エンドユーザー側の AI サービス利用と、作る側の AI デザイン実践をどの程度同じ論文内で扱うか
  • インターン環境をどこまで本文に出せるか、匿名化の範囲
  • 観察ログをどの程度残せるか
  • 研究として「提言」と言うか、「論点整理」「考慮事項」「問いの提示」と言うか
  • 教授から指摘されたメンタルモデル、知覚／認知、世代差をどの章で扱うか
  • 「デザイナーの役割変化」を中心に寄せすぎると職能論になりすぎるため、あくまで委譲条件と人間側に残る判断行為の話として扱う必要がある