ユーザインタフェースの基礎

• 日程: Day 2 / セッション7
• 時間: [14:30-15:00]
• 形式: 座学
• ゴール: UIの種類（CUI/CLI/GUI）とWebブラウザの構成要素（HTML5、DOM、JavaScript、JSON）を（条件: 用語を挙げながら）自分の言葉で説明できる（基準: 各用語につき一文以上）。購買行動モデル（AIDMA、AISAS、AISCEAS）の違いを一言で言える
• 学習形式: 対話型解説＋AIディスカッション

前のセッションで非機能要件を定義しました。今度は、システムの「顔」の話です。

いきなりですが、質問です。あなたが「使いやすい」と感じるアプリはどれですか？ その理由を一言で言えますか？

「なんとなく使いやすい」は答えになりません。この「なんとなく」を言語化するのが、UI（ユーザインタフェース）の学びです。

• 午前中に作ったプレゼンテーション一覧は、UIの「設計図の素」です
• このセッションでUIの基礎用語を押さえます
• 次のセッションで、実際にワイヤーフレームとして形にします

つまりここは、Day1〜2で積み上げた「見えない情報の設計」を「見える形」に変える直前の準備運動です。

UIとは「利用者とコンピュータシステムの入出力仕様」です。人間とシステムの境界面（インタフェース）を指します。

たとえ話をしましょう。UIはレストランの「メニューと店員」のようなものです。厨房（機能）がどれだけ優秀でも、メニューが読めなければ注文できません。注文（入力）と配膳（出力）の仕様が、レストランのUIです。

ここで少し考えてみてください。「良いUI」とはどんなUIでしょうか？ 30秒、自分の答えを作ってから読み進めてください。

よくある答えと、その先にある視点を並べます。

• 「きれいなUI」→ 惜しい。装飾が美しくても迷子になるサイトはあります
• 「説明がいらないUI」→ 良い線です。ドアの取っ手を見て引くか押すか迷わないのが理想です
• 「ペルソナが目的を達成できるUI」→ この研修での答えです

対比で確認します。ボタンが大きく色鮮やかでも、支出の合計がどこにも表示されない家計簿は「良いUI」ではありません。逆に、白黒で地味でも、開いた瞬間に今月の残額が分かる家計簿は「良いUI」です。なぜなら、良し悪しの基準は見た目ではなく「ペルソナの価値」だからです。Day1の「誰にとっての価値か」が、ここでも判断基準になります。

「良いUI」と「悪いUI」の同じ機能の対比例（家計簿の支出入力）:

悪い例: [テキスト欄] ← 「2026-07-06,食費,480」とカンマ区切りで入力させる
良い例: [日付ピッカー] [カテゴリ選択] [金額欄(数字のみ)] [保存ボタン]

入力される情報は同じです。違うのは「入出力仕様」だけです。

• UIの良し悪しは「見た目」ではなく「ペルソナが目的を達成できるか」で判断する
• UIは入出力の「仕様」である。つまり設計対象であり、センスだけの世界ではない

世界初の本格的なGUIは、1973年に Xerox PARC（パロアルト研究所）が作った「Alto」に載っていました。ウィンドウ、アイコン、マウス。全部Altoが先駆けです。1979年、若きスティーブ・ジョブズがPARCを見学し、このGUIに衝撃を受けて Lisa と Macintosh の開発に突き進んだ、という逸話は有名です。ゼロックス社内ではAltoの価値が十分に「情報」として伝わらず、商業的成功は他社に持っていかれました。価値ある情報も、伝わらなければ価値を生まない。IAの教訓そのものです。

UIには大きく分けて次の種類があります。

• CUI（Character User Interface）: 文字ベースのUI全般。画面に文字で応答する
• CLI（Command Line Interface）: CUIの代表格。コマンドを1行ずつ打って操作する（ターミナル、シェル）
• GUI（Graphical User Interface）: 図形・アイコン・マウスやタッチで操作する

「GUIが新しくて偉い」わけではありません。対比してみましょう。100個のファイル名を一括変更するなら、CLIの1コマンドが最速です。GUIで100回クリックするのは苦行です。逆に、初めて使う人に家計簿をつけてもらうなら、GUIが適切です。「毎回コマンドを打て」では誰も続きません。

つまり、「誰が・何を・どれくらいの頻度で」行うかで最適なUIは変わります。ここでもペルソナが判断基準です。

同じ「支出一覧の表示」でも、UIによって姿が変わります。

# CLI: コマンドで一覧表示
$ kakeibo list --month 2026-07
2026-07-01  食費      480
2026-07-03  交通費    340

GUIなら、同じ情報が表とグラフで表示されます。情報は同じ、入出力仕様が違うだけです。

• CLI/GUIは優劣ではなく適材適所。ペルソナと利用頻度で選ぶ
• 「情報」と「UI」は分離できる。同じ情報を複数のUIで見せられる

今もプロの開発者はCLIを多用します。理由は「自動化できるから」です。GUIのクリック操作は記録も再現も難しいですが、CLIのコマンドはコピペで再実行でき、スクリプトにもなります。「人に優しいのがGUI、機械（と玄人）に優しいのがCLI」と覚えると、使い分けの感覚がつかめます。

現代のシステムの多くは「クライアントサーバ型」です。役割分担はこうです。

• クライアント（ブラウザ）: プレゼンテーション（見せる・入力を受ける）を担当
• サーバ: 機能（計算・保存・検索）を担当
• 両者の間を、データ（多くはJSON）が行き来する

Webブラウザの構成要素を一言ずつ押さえます。

• HTML5: ページの構造と意味を記述する言語。見出し・段落・フォームなどを定義する
• DOM（Document Object Model）: HTMLをプログラムから操作するための木構造のモデル。JavaScriptはDOMを通じて画面を書き換える
• JavaScript: ブラウザ内で動くプログラミング言語。入力チェックや画面更新、サーバとの通信を担う
• JSON（JavaScript Object Notation）: データ交換フォーマット。クライアントとサーバの「共通語」

なお、かつては RIA（Rich Internet Application） と呼ばれる、Flash等でブラウザ内に豊かな操作性を実現する技術が主流の時期がありました。現在はHTML5とJavaScriptがその役割を吸収し、さらにスマートデバイス（スマホ・タブレット）がUIの主戦場になっています。だからこそUI設計では、次のキーワードが重要になります。

• マルチプラットフォーム / Universal: PC・スマホ・タブレットのどれでも使える設計
• UX: UIを含む、利用者の体験全体。IAはUXの1要素でした（Day1参照）
• ワイヤーフレーム: 画面の構成要素を線と枠で描いた設計図。次のセッションで作ります

JSONは「情報モデルがそのまま通信に乗った姿」です。今日の午前に作った情報モデル「支出記録」は、こう流れます。

{
  "date": "2026-07-06",
  "category": "食費",
  "amount": 480,
  "memo": "昼食"
}

属性名がそのままキーになっていることに注目してください。情報モデルが良ければ、JSONも自然に良くなります。

• ブラウザ＝プレゼンテーション、サーバ＝機能、間をJSONが繋ぐ。この分離がDay3（REST）・Day4（実装）の土台になる
• DOMは「HTMLの操作口」。JavaScriptが画面を動かせるのはDOMがあるから

JSONの生みの親ダグラス・クロックフォードは「私はJSONを発明していない。自然界から発見しただけだ」と語っています。実際、JSONの仕様書はわずか数ページです。当時主流だったXMLは仕様が分厚く、タグだらけで人間に読みにくいものでした。「単純なものが生き残る」の好例です。

UIの設計には「利用者がどう行動するか」のモデルも役立ちます。代表的な購買行動モデルを一言ずつ。

• AIDMA（アイドマ）: 注意→興味→欲求→記憶→行動。マスメディア時代のモデル。「覚えて後で買う」
• AISAS（アイサス）: 注意→興味→検索→行動→共有。ネット時代のモデル。「調べて買って広める」
• AISCEAS（アイシーズ／アイセアス）: 注意→興味→検索→比較→検討→行動→共有。比較サイト時代のモデル。「じっくり比べてから買う」

違いを一言で言うなら、**「記憶する時代（AIDMA）→検索・共有する時代（AISAS）→比較・検討する時代（AISCEAS）」**という利用者行動の進化です。

なぜUIの話に購買行動が出てくるのでしょうか。ここで考えてみてください。ECサイトのUIに「レビュー欄」「比較表」「SNS共有ボタン」があるのはなぜでしょう？ そう、AISAS/AISCEASの「検索・比較・共有」を支えるためです。ペルソナの行動モデルが、置くべきUI要素を決めるのです。

最後にもう一つ問いかけです。あなたの開発テーマのシステムは、何年使われる想定ですか？ 1年？ 5年？ 10年以上？

• 1年で捨てるキャンペーンサイトなら、流行のUIに全振りしてよい
• 10年使う業務システムなら、流行より「変わらない情報の設計」が重要になる
• UIの流行は数年で変わるが、情報モデルは長生きする。だから情報の設計とシステムの設計を分離する価値がある

この問いに正解はありません。AIと議論してみましょう。「保守期間10年のシステムでUIに流行技術を使うリスクを教えて」と聞くと、議論が深まります。

家計簿システム（ペルソナ: 節約したい新社会人）にAISCEASを当てると、UI要素が導けます。

検索(Search) → 「カテゴリ別に支出を検索できる画面」
比較(Comparison) → 「先月と今月の支出比較グラフ」
共有(Share) → 「今月の節約成果を画像で書き出す機能」

• 3モデルの違いは「記憶→検索・共有→比較・検討」の一言で言えるようにする
• 行動モデルとペルソナから、UI要素を「根拠を持って」導けるのがIA流のUI設計

AIDMAの原型は1920年代、アメリカの広告実務家サミュエル・ローランド・ホールの著作にさかのぼります。つまり100年前の理論です。ラジオ広告の時代に生まれたモデルが、いまだにマーケティングの教科書に載っている。一方でAISASが提唱されたのは2000年代、インターネット普及後です。モデルは時代の「利用者の行動」を写す鏡であり、行動が変われば作り直される。まさにモデリングの「単純化とパターン」の実例です。

• 「私の開発テーマ『（自分のテーマ）』のペルソナにとって、CLIとGUIのどちらが適切ですか？ 理由も教えてください」
• 「HTML、DOM、JavaScript、JSONの関係を、レストランのたとえで説明してください」
• 「AIDMA、AISAS、AISCEASの違いを、家計簿アプリのユーザ獲得を例に説明してください」

今回学んだことを一言でまとめると「UIは入出力の仕様であり、その良し悪しはペルソナが決める」です。

• UIの種類（CUI/CLI/GUI）は優劣ではなく適材適所
• ブラウザ＝プレゼンテーション、サーバ＝機能、間をJSONが繋ぐ
• 購買行動モデル（AIDMA→AISAS→AISCEAS）は利用者行動の進化を写す
• システムの保守期間が長いほど、「情報の設計」の分離が効いてくる

次のセッションでは、午前に作ったプレゼンテーション一覧を、いよいよワイヤーフレームとして描きます。今日の成果物が「見える形」になる時間です。

• CUI/CLI/GUIの違いと使い分けの基準を、一文ずつで言えますか？
• HTML5・DOM・JavaScript・JSONの役割を、それぞれ一言で説明できますか？
• AIDMA・AISAS・AISCEASの違いを一言で言えますか？

• 参考リンク: MDN Web Docs（HTML・DOM・JavaScript・JSONの公式学習リソース）、『The Elements of User Experience』（Jesse James Garrett）
• 発展課題: 自分がよく使うアプリを1つ選び、「良いUIだと思う点」「悪いUIだと思う点」を各2つ挙げ、ペルソナの視点で理由を書いてみる。AIに反論させてみると理解が深まる