今日のアジェンダ

1. HCIの基礎：人とコンピュータの相互作用、ユーザビリティ、ノーマンの設計原則
2. ユーザーシナリオ：「誰のどんな課題を解決するか」を言語化する
3. プロトタイピング：手描きとAI画像生成でアイデアを形にする

HCIとは何か

HCI (Human-Computer Interaction, ヒューマンコンピュータインタラクション)

• 人間とコンピュータの間の 相互的な交流作法を研究する学際分野
• コンピュータ科学、人間工学、認知心理学・社会学・デザインなど多分野が関わる
• 物理的側面（入力装置・出力装置）と認知的側面（理解・記憶・判断）の両方を扱う
• 1980年代に確立。「動くシステム」を「使われるシステム」に変えるための知識体系

キーワード：

• インタフェース：人とコンピュータが接する面・情報交換の手段
• インタラクション：そこで生まれる相互作用そのもの

HCIが扱う領域の広がり

HCIは「人とコンピュータの間のすべて」を扱うので、扱うトピックも広い

インタラクションスタイルの変遷

コンピュータと人間の対話方式は、人間側の負担を減らす方向に進化してきた

ユーザビリティとは何か

ノーマン『誰のためのデザイン？』に記された7つの原則

1. 発見可能性：今「何ができるか」「どんな状態か」が、見ただけで分かる
2. フィードバック：自分の操作が届いたか・処理が今どこまで進んだかが、すぐ伝わる
3. 概念モデル：「こう動くはず」というユーザーの予想と、実際の動きが一致する
4. アフォーダンス：そのモノで「何ができるか」の可能性が、使う人の能力と噛み合っている
5. シグニファイア：「どこを・どう操作するか」のヒントが、目で見て分かる
6. 対応づけ：操作する場所と起こる結果の対応が、直感に沿っている
7. 制約：「できないこと」を物理・論理・意味・文化の力で作り、エラーを未然に防ぐ

1. 発見可能性 (Discoverability)

操作可能なもの・現在の状態・次に取れる行動が、自然に読み取れること

具体例：

• ボタンが立体的に見えると、押せることが分かる
• リンクに下線がある、クリックできることが分かる
• 選択中のタブが色で強調されていると、今ここにいることが分かる
• 「次へ」「保存」ボタンが常時画面下に出ていると、次の行動が分かる

逆に、上スワイプの隠しメニューやホバーで初めて出るボタンは、発見可能性を犠牲にしている

2. フィードバック (Feedback)

自分の操作が届いたか・処理は今どこまで進んだか、がユーザーへ伝わること

具体例：

• ボタンを押した瞬間に色が変わる
• 送信完了の「送信しました」トースト
• ロード中はスピナー、長時間処理は進捗バー
• スマホでタップしたときの軽い振動

ただしすばやく・豊かに・節度を持ってが鉄則。夜中3時に「終わりました」と鳴る食器洗い機のように、過剰なフィードバックがあると、ユーザーの混乱を生む

3. 概念モデル (Conceptual Model)

これはこう動くもの、というユーザーの頭の中の説明のこと

具体例：ノーマンが体験した旧型冷蔵庫のつまみ

• 冷蔵室と冷凍室に別々のつまみ → 「2つの独立センサーで別々に温度調節している」と思い込む
• しかし実体はサーモスタットも冷却装置も1つ。つまみは「冷気の振り分け比率」を変えるだけ
• だから片方を動かすと両方の温度が変わる

つまみのレイアウト＝ システムイメージ が、間違ったメンタルモデルを誘発した。ChatGPTを検索エンジンと誤解するのも同じ構図

4. アフォーダンス (Affordance)

モノの性質と、それを使う主体の能力との間の「関係性」 (＝何ができるかの可能性)のこと

具体例：椅子は「支える」をアフォードする

• 大人にとっては「持ち上げる」もアフォードする
• 幼児にとっては重すぎて、持ち上げはアフォードしない
• ボールは「投げる」「バウンドさせる」、ノブは「回す」「押す」「引く」、平らな板は「押す」をアフォードする

モノ単体の属性ではなく、「誰が・何のために使うか」によって変わる可能性を指す。したがって、同じモノでも、関わる主体が違えばアフォーダンスは変わる

5. シグニファイア (Signifier)

「どこで・どうやって」その行為を行うべきかを伝える、知覚可能な手がかりのこと

具体例：

• ボタンの立体的な見た目 → 押せそうと感じる (意図的)
• リンクの下線 → クリックできそうと感じる (意図的)
• スワイプ方向の矢印アイコン → どこに動かせるかが分かる (意図的)
• 駅のホームに並ぶ人の列 → もうすぐ電車が来ると分かる (偶発的)

アフォーダンス＝ 何ができるか ／ シグニファイア＝ どこで・どうやってか。意図的に置かれたものも、偶然そう見えてしまうものも、どちらもシグニファイア

6. 対応づけ (Mapping)

操作と結果の関係が、空間・身体・文化のどれかで「そう感じる」方向と一致していること

具体例：

• 音量ボタンは、上のボタンで音が大きく、下のボタンで小さくなる
• 地図アプリのピンチ操作は、指を広げると拡大、つまむと縮小する
• ガスコンロのつまみは、左のつまみが左のコンロ、右のつまみが右のコンロに連動する
• 動画プレイヤーのシークバーは、左に向かうほど過去、右に向かうほど未来に遷移する

うまく対応づけられていれば、図もラベルも指示もなしに使い方が伝わる

7. 制約 (Constraints)

「できないこと」を作ることで、エラーを未然に防ぎ、行為を導くこと

具体例：大学のレポート提出システム (4種類が同時に効く)

• 物理的制約：添付ファイルはPDFしか選べない (拡張子チェックでそもそも他形式は弾かれる)
• 文化的制約：締切は「23:59」と24時制で表示 (日本の慣習)。赤字＝警告、緑＝OK
• 意味的制約：「提出」ボタンは画面下、「戻る」は左上。送信アイコンは紙飛行機マーク
• 論理的制約：必須項目を1つでも埋め忘れると「提出」が押せない (残りが埋まれば自動で押せるようになる)

フォームのバリデーションは、すべてこの「制約」を応用したエラー予防策

設計でヒューマンエラーに備える

エラーの2分類 (ノーマン)：

設計でできる対策：

• 削除前の確認 / Gmail 送信取り消し / Ctrl+Z / 下書き自動保存
• 制約で物理的にエラーを防ぐ (形式チェック、権限制御)
• エラー時の文言は「原因」と「次の行動」を伝える

「失敗してもリカバリできる」と知っていると、ユーザーは安心して新機能を試せる

ニールセンの10ヒューリスティック

自作プロダクトを上から順にチェックすることで、弱点が見える

認知科学に基づくUI設計の法則

人間の知覚・記憶の特性を踏まえて設計判断の根拠にする

「大学生のプレゼン練習」を題材に課題を言語化してみる

最初から「AIがどう解決するか」は決めない。まず、今の体験を小さく見る

課題仮説の4点セット

ユーザーが抱える課題は4つに分けると書きやすい

この4点セットが、以降のペルソナ・AS-IS・HMWの土台になる

主役ユーザーを仮置きする

ペルソナ ＝ 変えたい瞬間の主役を、具体的なひとりの人物として仮置きしたもの

人物設定を作り込むためではない。設計判断をするための仮の主役を置く

ペルソナに書くこと

人物設定ではなく、設計判断に効く情報だけを書く

• 属性：名前、年齢、ひとことで言うとどんな人か
• 状況：いつ、何をしようとしているか
• 目標・行動：達成したいこと、今のやり方
• 困りごと：どの瞬間で何に困るか

迷子になりやすい書き方

• 好きな食べ物や趣味を盛りすぎる
• 「ユーザー」ではなく「自分の都合」だけになる
• 「AIが採点してくれる人」のように解決策を混ぜる

「プレゼンが苦手」→「発表前日に録音してみたが、どこを直せばよいか分からない」

ペルソナ例：公大 太郎 (19歳)

AS-ISシナリオとして記述する

ペルソナをベースに200〜300字のシナリオを作ってみる (AIに生成させる)

中間発表の前日、太郎は自宅で3分発表の練習をしている。スライドは一通り作ったが、話してみると途中で何を言いたかったのか分からなくなる。スマホで録音して聞き返してみるが、「なんとなく早口」「課題の説明が弱い気がする」以上のことは分からない。友達に聞いてもらうには時間が遅く、先生に事前確認してもらう機会もない。太郎は少しだけ原稿を直し、「たぶん大丈夫」と思うことにするが、不安は残ったままだ。

この段階では、まだ「発表練習AI」は登場しない。現在の体験をそのまま見る

シナリオから洞察文を作る

シナリオをそのまま画面にしない。まず、設計で扱える課題に圧縮する

How Might We (HMW) で問いに変える

HMW は、課題を プロトタイプで答えられる問い に変える道具

TO-BEシナリオで価値を確認する

中間発表の前日、太郎はスマホに向かって3分発表を録音する。録音後、AIは「課題説明が長いが、誰が困っているかが見えにくい」「解決策の前に具体例を1つ入れると伝わりやすい」と返す。太郎は原稿を直し、もう一度録音して、本番で意識する点を決める。

AS-IS と TO-BE の差分 が、プロダクトの提供価値になる

参考：本当のニーズは「体験」から見つける

今日の4点セット、ペルソナ、シナリオはすべて仮説。仮説は、ユーザーの実際の体験で更新する

ユーザーの 声 は大事。ただし、声だけではなく 練習の流れ を見る

→ 詳細はユーザーテストの回 (第7回) で扱う

プロトタイプとは何か

完成前の「お試し版」。アイデアを目に見える形にしたもの。「検証用」で、捨てる前提で作るもの

なぜ作るのか：

• 早く失敗できる：実装するよりお試しの段階で気づいた方が圧倒的に早い
• 言葉より伝わる：言葉で100行で説明するより画面1枚を見せる方が分かりやすい
• ユーザーの反応が得られる：「説明を聞いた感想」より「触った感想」の方が信頼できる
• 作る側の頭の整理になる：描こうとすると、自分が何を分かっていなかったかが浮き彫りになる

どのように作るのか：

• 最初に問題を決め打ちせず、試作と観察を繰り返すなかで本当の問題を見つける
• 速さ × 多さ、が良いプロトタイプの条件。1個だけ凝るより、10個粗く作る方がいい

2種類のプロトタイプ

プロトタイプは「何を確かめたいか」で大きく2つに分けられる
両方を必ず作るわけではなく、検証したい問いに応じて選ぶ

デザインプロトタイプの忠実度

完成品にどれだけ近いか (＝忠実度; Fidelity) で分類できる

忠実度が高い = 良い、ではなく、段階に応じて使い分ける
アイデア発散の段階でHi-Fiを作ると、修正コストが高くなる

ファンクショナルプロトタイプの代表手法

プロトタイプ段階で使える検証手法は実に多様。「実験＝ABテスト」だけではない

AIプロダクトでの実例

「中身がAI」だからこそ、見た目より先に AIの振る舞いそのもの を試したい

AIの精度や応答内容は、人間が代行しても「ユーザー体験」としては十分試せる。実装前に「そもそも欲しがる人がいるか」を確認できる

プロトタイプとプレトタイプ

「デザイン / ファンクショナル」の軸とは別に、何に答えるかで分類する考えもある

AIプロダクトは「作る前にプレトタイプ」が特に有効。学習・推論コストが大きい分、需要のない機能を実装する損失も大きい

どちらを先に作る？

開発フェーズによって、優先するプロトタイプの種類が変わる

AI機能を含む場合は特に、オズの魔法使いやコンシェルジュ型で「人がAIの振る舞いを代行しても価値があるか」を確かめてから、学習・実装に進む。先に作りすぎないことが最大の節約

AI画像生成でモックアップを作る

できること：

• 手描きや言葉での説明から、UIのモックアップ画像を生成
• 配色・雰囲気・スタイルのバリエーション出し
• プレゼン用のビジュアル素材

プロトタイプ作成に役立つAIサービス：

• ChatGPT：チャット中で画像生成。テキスト指示が反映されやすい
• Gemini：Google統合。日本語プロンプトも安定
• Claude Design：インタラクティブに要素を操作

AI画像生成モックアップの注意点

① 文字は崩れる
特に日本語は精度が低い。ボタンの位置を確認する用途で「文字の意味」は別途決める

② 結果はランダム
同じプロンプトでも毎回違う絵が出る → 何枚か生成して選ぶ

③ ピクセル精度は出ない
「ボタンを5px左に」のような微調整は不可能。雰囲気を掴む下絵 と捉える

④ コードに直結しない
画像が生成されても、そのままアプリにはならない → 最終的にはFigma等で整える、または v0 / Uizard などのコード生成系AIを併用する

AI画像生成は「初稿のラフ」を高速に作るための道具

今日学んだこと

次回：第4回 中間プレゼンテーション

個人でプレゼンテーションを行う。発表内容は、解決したい課題、プロダクトのコンセプト、UIプロトタイプなど。講師や他の受講生のフィードバックを受け、後半の開発方針を具体化する。また、チームビルディングを行う。

課題：身近な人 (自分でもOK) が抱えている課題を1つ見つけて、それを解決するアプリのコンセプトを考えて、3分のプレゼンテーションにまとめてください。

• 聞き手に「誰のどんな問題を解決するか」が伝わるプレゼンにしてください
• 「どのように解決するか」が分かるアプリのイメージをAIで作成して入れてください
• 資料はPDF形式で発表前日の23:59までにMoodleにアップロードしてください

a日程：5/26 (火)　b日程：6/2 (火)