担当者：鈴木 祥護
活動内容
ポスター作成
次回の作業
ポスター制作・提出
syogo のすべての投稿
HTML5
担当者：鈴木祥護
活動内容
表示バグの改善・修正
ポスター作成
１枚目完成
２枚目情報量過多により収まらないため選別作業必須
内容確定
次回の作業
ポスター２枚目の作成
HTML5
担当者：鈴木祥護
活動内容
・動画編集
・パワーポイント内容、配置決め
次回の作業
ポスター作成
MIRABAのサブドメイン
https://20242019-suzukishogo-cmd.github.io/miraba/
HTML5
作業担当者：鈴木 祥護
作業日 ：2026年2月13日
作業内容
MAP（REQUEST詳細）画面において、
詳細カードに記載された住所を自動検索し、正しい位置へマップを初期表示させる処理の精度向上を行った。
併せて、今後の実運用を見据えた住所データ構造の再設計検討を実施した。
■ 作業目的
・REQUEST詳細画面表示時に、
対象住所へ正確にマップを初期表示させる
・ジオコーディングの曖昧性を排除し、
卒業研究提出レベルの安定設計へ引き上げる
・将来的な本番運用を想定し、
住所データ構造の見直しを行う
■ 作業内容
① ジオコーディング精度向上対応
OpenStreetMap（Nominatim API）を利用し、
REQUEST住所から緯度経度を取得する仕組みは実装済み。
今回の修正内容：
・countrycodes=jp を追加（日本限定検索）
・住所ログ出力によるデバッグ強化
・段階的フォールバック検索の実装
【検索方針】
-
「都道府県＋市区町村＋番地」で検索
-
失敗時は番地を除外して再検索
-
それでも失敗した場合はフォールバック座標を使用
→ 精度向上と安定性の両立
②住所データ構造の再設計検討
【現行保存構造】
prefecture
city
detailAddress
【問題点】
・政令指定都市の「区」情報が不安定
・市区町村の粒度が不統一
・曖昧検索を誘発する構造
③今後の正しい設計方針
将来拡張を見据えた理想構造：
prefecture（都道府県）
city（例：札幌市）
ward（例：北区）
town（例：あいの里三条）
block（例：1丁目13番3号）
lat
lng
■ 技術的整理
【現在の状態】
・マップ表示自体は正常
・ジオコーディングAPIは正常応答
・誤座標の原因は住所の曖昧性
【解決策方向性】
・保存時の住所正規化
・市区町村の完全保持
・検索時の段階的照合
・lat/lng 初回保存キャッシュ化（再検索防止）
■ 今後の課題
・REQUEST保存時に市区町村を完全保持する設計変更
・郵便番号検索との統合精度向上
・ジオコーディング失敗時のUI表示改善
・lat/lng保存処理の確実化
・DB構造の最終確定（localStorage → IndexedDB 連携安定化）
ＨＴＭＬ５
作業担当者：鈴木 祥護
作業日 ：2026年2月12日
作業内容
MAP（REQUEST）機能の完成度向上を目的とし、
以下3点を確定仕様として安定動作させる段階まで到達させた。
・都道府県フィルターの正式実装
・保存ボタンのトグル仕様化
・REQUEST詳細画面での住所連動MAP表示（自動ジオコーディング）
■ 作業目的
MAP（REQUEST）機能について、
UI設計段階から一歩進み、
実運用を想定した安定仕様へ引き上げることを目的とした。
■ 作業内容詳細
① REQUEST保存ボタン仕様の再設計
【従来仕様】
・1クリック保存のみ
【修正後】
・トグル式（保存 ⇄ 保存解除）へ変更
【実装内容】
・localStorage（miraba_saved_requests）で配列管理
・保存済み判定によりボタンUIを動的切替
・「保存済み」表示＋クラス付与
・自分のREQUESTは保存不可仕様
【確定判断】
UX向上および実運用を想定した仕様として正式確定
② MAPフィルター機能の完成
（方面 → 都道府県 連動設計）
【地域データ設計】
北海道方面／東北／関東／中部／近畿／中国／四国／九州
47都道府県を完全網羅
【動作仕様確定】
・「方面から選択」モード採用
・方面選択 → 該当方面の県を動的生成
・県未選択時：方面全体でフィルタ
・県選択時：都道府県単位でフィルタ
【設計思想】
ユーザーの柔軟性を阻害しないフィルタ設計
・「関東ならどこでも探したい」
・「東京都だけ探したい」
双方に対応可能な構造とした。
③ MAP詳細画面：住所自動検索 → 初期値自動設定
【従来問題点】
・常に東京駅が初期表示
・REQUESTごとの住所が反映されない
【改善仕様】
① 緯度経度が保存済みなら即表示
② 未保存ならNominatimで住所ジオコーディング
③ 成功時：lat / lng を保存
④ 失敗時のみ東京駅をfallback
・完全非同期処理で再設計
・map生成は1回のみ
【到達点】
REQUESTごとに異なる住所へ自動センタリングを実現
④ UI調整
・REQUESTカード高さ調整
・フィルタ枠の拡張
・「REQUESTを取り下げる」ボタンを
淡い紅色＋丸みデザインへ変更
・終了済みラベルの視認性を維持
■ 現在の到達点
MAP機能は以下が完成状態：
✓ REQUEST投稿
✓ REQUEST一覧表示
✓ 保存／解除トグル
✓ 自分のREQUEST管理
✓ 終了処理（論理削除）
✓ 方面・都道府県フィルタ
✓ 住所自動検索
✓ 詳細MAP連動表示
MAP（REQUEST）機能はUI・基本機能ともに完成段階へ到達。
■ 次工程
・近くフィルタ（現在地連動）
・MAPピン実装
・MAP右パネルUI微調整
・API制限対策（ジオコーディングキャッシュ強化）
・全画面間でのユーザ情報連携（取得IDの生成）
ＨＴＭＬ５
作業担当者：鈴木 祥護
作業日 ：2026年2月10日
作業内容
MIRABA の MAP（REQUEST）画面について、
REQUESTを「探す・出す・保存する・再利用する」一連の流れを
UI設計として整理・確定し、将来の実装を見据えた完成度まで引き上げた。
■ 作業目的
・MAP（REQUEST）画面において、
REQUESTの一連の利用フロー
（探す／出す／保存する／再利用する）をUI設計として整理する
・卒業研究として、
画面構成・遷移・思想を説明可能な設計状態にする
■ 今日の作業
1．MAP画面 全体構成の確定
・MAP画面を 左右2カラム構成 に固定
左：REQUESTを探す／一覧表示
右：REQUESTを出す／保存REQUEST管理
・既存のサイドバー構造および
data-page による画面遷移方式は維持
2．REQUEST一覧UIの完成
・今後、多数のREQUESTが表示されることを前提に一覧フィールドを設計
・同時表示件数は 約4人分＋α を基準とした
・半透明シルバー基調の枠を採用し、
一覧専用のスクロールバーを実装
・REQUESTカードの表示要素を以下で確定
ユーザアイコン
ユーザ名
日付
確認するボタン
・「確認する」操作から
map-detail.html へ遷移する設計を維持
3．REQUESTを出すフォームUI完成
・REQUEST作成フォームを完成レベルまで設計
・入力項目を以下に整理
日時（開始・終了）
住所（郵便番号検索前提）
REQUEST内容
概要
連絡事項
・「REQUESTを探す」枠と同一思想のデザインで統一
・スクロール前提とし、
高級感と操作性を両立したUIに調整
4．思想メッセージの配置整理
・思想分においてrequest依頼者・受注者ともに不安要素防止を見越して呼び掛ける
・REQUESTを出すボタンの配置
・操作と思想が同時に視認できるUXに変更
5．保存REQUEST機能のUI設計確定
・保存REQUEST用の 専用枠 を新規設計
・配置は右カラム（map-right）内、
REQUEST作成フォームの下に配置
・枠仕様を以下で確定
横幅：REQUESTを出すフォームと同一
高さ：左側REQUEST一覧の下端と揃える
・表示内容
タイトル：「保存したREQUEST」
保存されたREQUESTをカード形式で表示
・表示形式はREQUEST一覧（request-item）と完全共通とし、
ユーザアイコン、ユーザ名、サイズ、色を統一
6．保存 → 再利用の画面遷移フロー確定
以下の画面遷移フローを確定した。
MAP.html（REQUEST一覧）
→ 確認
MAP-detail.html（REQUEST詳細＋保存）
→ 保存
MAP.html（保存REQUEST一覧）
→ クリック
MAP-detail.html（REQUEST詳細 再表示）
・保存REQUEST専用の新UIは作成せず、
既存のREQUESTカードを再利用
・壊れにくく、拡張可能な設計として整理
■ 本日時点の到達点
・MAP画面UI：完成レベル
・REQUEST関連画面の役割分担および遷移仕様：確定
・保存REQUEST機能：UI設計完了（実装は次工程）
■ 次回作業予定
・実マップとの連携
・ユーザ情報（名前・アイコン）との連携
・全体の動作テスト
HTML5
作業担当者：鈴木 祥護
作業日 ：2月9日
作業内容
MIRABA の MAP（REQUEST）画面について、
UI設計を完成レベルまで引き上げ、
卒業研究として説明可能な設計状態に整理した。
■ 今日の目標
・MAP（REQUEST）画面のUI設計を完成レベルまで仕上げる
・「REQUESTを探す」「REQUESTを出す」両枠の視認性・操作性を改善する
・卒業研究として、設計意図を説明できる状態に整理する
■ 活動内容
MAP画面 全体UIの調整・完成
・左側「REQUESTを探す」枠、右側「REQUESTを出す」枠について
レイアウト・配色・装飾を統一
・MIRABAの世界観に合わせ、
暗めトーンをベースにブルー／シルバーハイライトを用いたデザインに調整
・画面全体として、役割の異なる2枠が直感的に理解できる構成とした
REQUESTを出すフォームの改善
・フォーム内容が画面外にはみ出る問題を確認
・フォーム専用の縦スクロールを実装し、
画面全体のレイアウトを崩さずに入力可能な構造に変更
・スクロールバーは細め・シルバー調とし、
常時主張しない高級感のあるデザインを採用
住所入力UIの再設計
・住所入力を自由入力方式から、
「郵便番号 → 都道府県 → 市区町村 → 詳細住所」
という 構造化入力方式に変更
・郵便番号検索ボタンを設置し、
外部APIを用いた自動住所入力の設計を実装
・入力ミスや表記ゆれを防止し、
将来的なMAP連携を見据えたデータ構造とした
フォームUIの細部調整
・input / select / textarea のデザインを統一
・都道府県 select における色差問題について、
ブラウザ仕様を理解した上で制御方法を整理
・日付入力（カレンダーUI）については、
世界観とのズレを認識した上で、
実装の安定性を優先しブラウザ標準UIを採用する判断を行った
設計判断の整理
・現段階で 実装しない機能 と
将来実装予定の機能 を明確に切り分け
・卒業研究として
「なぜこの設計にしたのか」を説明できる状態に整理
■ 次回の作業予定
MAP画面の完成（機能面）
・ユーザー情報（名前・アイコン）との連携
・REQUESTクリック時の詳細表示とMAP表示の連動
実マップとの連携検討
・Leaflet 等を用いた実マップ表示への差し替え検討
・現在のダミーMAP構造を活かした段階的実装
REQUEST機能の実装
・REQUESTデータの保存・取得処理
・REQUESTが実際に行える環境の構築
動作テスト
・画面遷移・表示の動作テスト
・UI崩れ、入力不具合の確認
・卒業研究提出レベルでの安定性確認
html5
作業担当者：鈴木 祥護
作業日 ： ２月６日
作業内容
プロフィール画面の追加機能に対応のため再定義
・プロフィールは
「人物の象徴」と「付随情報」を明確に分離する画面とする
・情報の重要度に応じて、視覚的レイヤーを分離する
情報レイヤー構造
【人物の核（正規・固定）】
・アバター
・表示名
・（将来）ユーザID（本人のみ確認可能）
【準公開・可変情報】
・年齢
・生年月日（公開／非公開 任意）
・性別（公開／非公開 任意）
・住所（都道府県のみ公開）
【活動情報】
・投稿数
・利用期間
■ 表示ルール（確定）
・初期状態は 表示名のみ表示
・それ以外の項目は 非表示 または「–」表示
・未入力項目は必ず「–」で表示する
・年齢と生年月日は別項目として扱う
→ どちらか一方のみ表示可能な設計
・住所は 都道府県のみ公開（プライバシー保護）
■ デザイン・世界観の確定
【前提】
・背景（画面全体）は変更しない
・MIRABAの「落ち着いた暗さ」は維持する
【問題点】
・暗すぎて見づらい
・黒 × 黒で情報階層が分かりづらい
【解決策（確定）】
・カード内のみ明るくする
・特に「アイコン＋名前」領域を
別レイヤーとして強調する
4. 今後の想定タスク（効率重視）
・profile-hero のデザインを完成レベルまで仕上げる
・プロフィール画面を
「UI完成」
「JS機能追加完了」
・メッセージ画面の新規追加機能に応じた画面設計再定義詳細機能の定義ui設計図の作成
html5
-
作業担当者：鈴木 祥護
作業日 ：2月5日RIGHT画面の役割定義
・RIGHT画面を、ユーザー投稿を時系列で表示するタイムライン画面として位置づけ
・TOP画面の体験価値を補完する「閲覧中心の画面」として設計
・操作を最小限に抑え、情報の流れを重視した構成とした -
画面構造設計
・投稿カードを最小単位とした縦方向レイアウトを採用
・ユーザー情報、投稿テキスト、画像、コメント導線を
一つのカード内で完結させる構造とした
・RIGHT画面はJSによる動的生成を前提とし、
HTML構造を固定したままデータを差し替える設計を採用 -
コメントUIの責務分離
・コメント表示用（comment-preview）と入力用（comment-panel）を明確に分離
・表示と入力を混在させないことで、UXの混乱を防止
・コメントは新しいものが上に表示される降順構造とした
・表示件数を制限し、スクロール前提のUIとした -
画像表示仕様
・画像は正方形（aspect-ratio: 1 / 1）表示に統一
・複数画像選択を可能としつつ、表示は常に1枚のみ
・左右ボタンによる切り替え方式を採用
・投稿画面およびマイページと仕様を完全に共通化 -
完了判定
・RIGHT画面はUI設計および構造設計ともに完成扱いとする
・今後の追加機能実装は行わない
■ プロフィール画面 報告内容
-
プロフィール画面の役割定義
・プロフィール画面を「ユーザー情報の閲覧専用画面」として設計
・編集操作は別画面（プロフィール編集）に分離し、
表示と入力の責務分離を徹底した -
画面構造設計
・全画面共通サイドバーを維持し、main領域のみをプロフィール専用構成とした
・ユーザー名、基本情報を中心に、落ち着いた情報配置を採用
・過度な装飾を避け、公共性・信頼性を意識した構成とした -
編集画面との分離設計
・編集ボタンから専用の編集画面へ遷移する構造を採用
・プロフィール画面自体には入力要素を持たせない
・将来的な公開／非公開制御を想定したデータ構造を前提とした -
デザイン方針
・高級感・ガラス感・あたたかさ（ダーク寄り）の世界観を踏襲
・余白と文字色を重視し、視認性と落ち着きを両立
・MIRABA全体のトーンを崩さない画面デザインとした -
完了判定
・プロフィール画面およびプロフィール編集画面は
UI設計・構造設計ともに完成扱いとする
・以後の改修・追加作業は行わない
HTML５
作業担当者：鈴木 祥護
作業日 ：2月4日
プロジェクト全体の最終整理
・設定、フレンド（メッセージ）、マイページ、投稿画面、RIGHT画面について
UI設計および画面構造を確定
・全画面共通サイドバー固定構造、data-pageによる画面遷移仕様を最終仕様として整理・共有
次回の作業
① right画面：複数枚画像投稿（最優先）
② プロフィール：公開／非公開制御