卒業論文
青山学院大学 地球社会共生学部 地球社会共生学科
臼井千瑛
指導教員：古橋大地 教授
©︎ FuruhashiLaboratory/ChihanaUsui, CC BY 4.0
本資料は中間発表段階のドラフトです。プロトタイプの実装まで進んだ段階のため、IMRaDのうちIntroduction・Methodsを中心に構成し、Results・Discussionに代えて「今後の展望」「決めきれていない部分・まだわかっていない部分」を記載しています。
中間発表用の簡易プロトタイプ「おとさんぽ」（Soundwalk）を、GitHub Pagesで公開している。
https://furuhashilab.github.io/2026gsc_ChihanaUsui/
スマートフォンのブラウザで開き、屋外で位置情報とコンパス（iPhoneでは「動作と方向」）の利用を許可して使用する。
- 最初の画面で、目的地までの距離とBGMを選ぶ
- 現在地を取得し（精度が±30m以内になると自動で次に進む）、周辺のランドマークから目的地を選ぶ
- その場で回転し、音が最も大きくなる向きを確かめる（キャリブレーション）
- 音を頼りに歩く
- 到着またはギブアップで結果を表示し、記録を保存する
- 距離の選択：近所（約15分・直線300〜500m）、ちょっと遠く（約30分・直線700〜1000m）、長く歩く（約1時間・直線1500〜2000m）、カスタム（100〜3000m）。時間は、歩行速度を分速80m、音を頼りに探すことで実際の歩行距離が直線距離の約2倍になると仮定した目安である
- 関東（1都6県）については、OpenStreetMapのデータ（Geofabrikが配布する2026年11月3日時点の関東の抽出データ、kanto-latest.osm.pbf）から目的地の候補（約21万件）を前もって取り出し、約5km四方の区画ごとのファイル（
data/lm/）としてアプリに同梱している。スマホは現在地の周りの区画だけを読み込むため、通信量が少なく、外部のサーバーが不調でも確実に目的地を選べる。区画ファイルの作成にはtools/make_tiles_pbf.py（pyosmiumを使用）を使った。立入禁止・私有地（access=private／no）の場所は除外し、公園などの面は、外周の重心を目的地の位置とする - 関東以外の場所や、同梱データに候補がない場合は、OpenStreetMapのデータ（Overpass API）から、選んだ距離の範囲にある場所をランダムに1か所選ぶ。候補は3段階に分け、上の段階から優先して選ぶ。立入禁止の場所は除外する
- ランドマーク：公園、遊び場、庭園、神社、寺院、教会、祠、像・アート作品、記念碑・史跡、噴水、眺望地点、見どころ、博物館・美術館、図書館
- 名前のある身近な場所：カフェ、飲食店、郵便局、地域の施設、駅
- 名前のあるバス停
- 直近15回に目的地になった場所は、なるべく選ばない
- 検索は、サーバーの負担が小さい矩形の範囲指定で行う。4つの公開サーバーに、5秒ずつずらして順に問い合わせ、最初に応答したものを使う。一時的なエラー（HTTP 429・502・503・504）のときは、4秒待って同じサーバーにもう一度問い合わせる。検索結果は端末内に1日保存し、同じ場所（約100m四方）で再び遊ぶときはサーバーに問い合わせない
- すべてのサーバーから取得できない場合は、理由を表示し、「もう一度探す」か「ランダムな地点で遊ぶ」かを選べる。あわせて、各サーバーに小さな問い合わせを送る接続テストを自動で行い、結果を表示する（原因の切り分け用）
- 目的地の名前はゲーム中は伏せ、結果画面で表示する
- コンパスの向きと目的地の方角の差に応じて音量が変わり、目的地の方向を向くと最大になる
- 時間制限は設けず、プレイヤーが「この向きに出発」を押して歩き始める
- 歩行中も、ヒントからキャリブレーションをやり直せる
- コンパスが使えない場合は待機し、iPhone／Androidそれぞれの許可方法を表示する
- BGMをループ再生し、距離に応じて音量とこもり具合（ローパスフィルター）を変える。遠いほど小さく、こもった音になる
- 残り50mで近距離モードに切り替わる。合図の音が鳴り、音量の変化が大きくなり、はっきりした音になる（GPSのぶれによる切り替わりの繰り返しを防ぐため、60mを超えると通常モードに戻る）
- 向きの強調：歩いている方向（GPSから得られる進行方向。得られないときは直近4m以上の移動から計算）と、目的地の方角を比べる。目的地の方向（約45度以内）に歩き出した瞬間に一度だけ音を大きく明るくし、離れる方向（約120度以上）に歩き出した瞬間に一度だけ小さくこもった音にする。その後、約10秒かけて元の音に戻す。立ち止まると判定をリセットし、再び歩き出したときにもう一度反応する。GPSの精度が±25mより粗いときは判定しない
- 正しい向きの合図：約10秒前の位置と比べて、8m以上歩き、かつ目的地の方向（約45度以内）に進んでいれば、小さく「ピピッ」と鳴らす。BGMの音量に関係なく一定の小さな音量で鳴らし、間隔は30秒以上空ける
- 片耳イヤホンで使えるよう、すべての音をモノラルで再生する。立体音響は使用しない
- GPSのぶれを抑えるため、距離を指数平滑化（直前の値と新しい値を一定の割合で混ぜて滑らかにする処理）してから音に反映する
- 到着判定は、目的地から15m以内（公園など面積のある場所は中心から30m以内）とする
- 歩行中の画面には距離を表示しない。代わりに、音の変化の意味（大きくなる、こもる、ピピッ、残り50mの合図、到着の音）を一覧で表示する
- OtoLogicの4曲から選べる
- 選ぶときに、冒頭20秒を試聴できる
- ヒント1：キャリブレーションのやり直し
- ヒント2：レーダー（ドラゴンレーダーのように、自分を中心に目的地の位置を点で表示する。コンパスが使えるときは、レーダーを開いたときのスマホの前方を上にして描く（開いている間は回転しない）。直線距離と、歩いた場合の目安の時間、30秒前より近づいたかどうかも表示する）
- ギブアップ：ゲームを終了し、目的地を地図で表示する
- 一時停止：音と時間の計測を止める。一時停止中の移動は、歩いた距離に含めない
- 結果画面に、目的地の名前、かかった時間、歩いた距離、直線距離、ヒント使用回数、地図（スタート、目的地、歩いた道のり）を表示する。距離の設定、直線効率（直線距離÷歩いた距離）、一時停止、BGMは「くわしい記録」に折りたたんで表示する。ヒントの種類ごとの回数や強調の回数は、CSVに記録する
- 記録は端末のブラウザ内（localStorage）に保存し、「これまでの記録」で一覧と詳細を確認できる。CSVでの書き出しと全削除に対応する
- 位置情報と記録は端末内だけで処理・保存し、開発者を含む外部には送信しない
- 関東では、目的地をアプリに同梱した場所データから選ぶため、現在地の座標は送信しない。ただし、現在地の周りの区画ファイル（約5km四方）をGitHub Pagesから読み込むため、おおよその地域（数km単位）はGitHubのサーバーのアクセス記録に残りうる（公開者がこの記録を見ることはできない）
- 関東の外、または同梱データに候補がない場合のみ、約100m単位にぼかした現在地をOverpass APIに送信する
- 結果画面の地図を表示するときは、その周辺の地図画像をOpenStreetMapのサーバーから読み込む
- 音のテスト（室内用）：スライダーで距離を変え、歩かずに音の変化を確かめられる。向きの強調と「ピピッ」の音もボタンで試せる
- iPhoneの消音モード対策：消音スイッチがオンでも音が鳴るよう、再生用の音声モードに切り替える
- 開発者表示：GPSの精度、距離、方位などの内部の値を表示する
- 画面が自動で消えないようにする（対応している端末のみ）
- 困ったときは（help.html）：許可の設定、GPS、音、スマホの持ち方、記録、プライバシーなどをQ＆A形式でまとめたページ。アプリ内のエラー表示からも、該当する項目へ直接移動できる
- 初回の許可の案内：ブラウザの許可画面が出る前に、何を許可するのかと位置情報の使い方を説明する画面を表示する（初回と、許可が拒否された後のみ）
- 振動：iPhoneのブラウザでは使えないため保留。必要に応じてオプションとして追加する
- 距離に応じて間隔が変わる音：焦りを感じさせる可能性があるため停止している（プログラム内には残している）
- 画面が消えると、音とGPSが止まる（Webアプリの制約）
古橋研究室の生成AI利用ガイドラインに従い、使用した生成AIを記載する。
本研究では、プロトタイプ（index.html、help.html、tools/make_tiles_pbf.py、data/lm/）の作成に、全面的にAnthropic社の生成AI「Claude」を活用した。仕様の検討、プログラムの作成、地図データの加工、テキストの作成、GitHubへの反映（commit・push）をClaudeが行い、筆者は機能や仕様の決定、スマートフォンでの動作確認、データや楽曲の入手と選定を行った。AIによる出力結果は筆者が確認し、実際に動かして検証したうえで、誤りや不具合は指摘して修正させた。
使用した生成AI（種類・バージョン・使用年月日）：
- Claude デスクトップアプリ（Coworkモード）/ Claude Sonnet 4.6, 2026-10-28, https://claude.ai
- Claude デスクトップアプリ（Coworkモード）/ Claude Opus 5.5, 2026-10-28, 2026-11-03, 2026-11-05, 2026-11-06, https://claude.ai
- ChatGPT / GPT-6 Astra, 2026-11-03, https://openai.com/index/gpt-6-astra/（楽曲素材をリポジトリで公開する方法についての相談に使用）
Claude デスクトップアプリ（Coworkモード）とClaude Opus 5.5は、古橋研究室のAIツール名リスト（v2.4.0、2026-09-04時点）に掲載されていないため、URLを併記した。
補足：
- モデルは、Claude デスクトップアプリで設定したものを記載している（Claude Sonnet 4.6のモデルID：claude-sonnet-4-6、Claude Opus 5.5のモデルID：claude-opus-5-5）
- Claudeは、筆者のPCの作業フォルダと、GitHubのアクセストークン（公開リポジトリへの書き込み権限のみ）を使って作業した
- Claudeが作成・変更したコミットには、末尾に「Co-Authored-By: Claude」の記載がある。日時ごとの変更内容は、GitHubのコミット履歴で確認できる
- 生成AIによる画像生成は使用していない。アプリ内のロゴや図（波の線、レーダーなど）は、Claudeが書いたプログラムで描画している
実際に歩いて試しながら、次の順に機能を追加・変更した。変更の理由も記録しておく。詳しい変更内容は、GitHubのコミット履歴にも残している。
- 最初のデモ（仮称SoundNav）を作成した。GPSによる現在地の取得、ランダムな目的地の生成、コンパスによるキャリブレーション、距離に応じた音量の変化、到着判定、結果表示を実装した
- GitHub Pagesで公開し、スマートフォンで試せるようにした
- 詳細な仕様に合わせて作り直した。歩行中の音をビープ音から持続する音に変更し、近づくほど間隔が短くなる音は、焦りを感じさせる可能性があるため停止した。残り50mの近距離モード、4段階のヒント、一時停止、室内用の音のテストを追加した。歩行中は、画面を見ない設計に合わせて距離を表示しないようにした
- BGM：合成音では単調だったため、OtoLogicの楽曲（CC BY 4.0）に変更した。著作権の扱いを確認し、再配布が認められている素材を選んだ。選ぶときに冒頭20秒を試聴できるようにした
- キャリブレーション：コンパスの許可が得られないまま時間が過ぎてしまう問題があったため、時間制限をなくし、プレイヤーが出発のタイミングを決める形にした。許可の方法の案内も追加した
- 目的地：完全ランダムな地点では、私有地や入れない場所が選ばれる問題があったため、OpenStreetMapに登録された公園・神社・像などのランドマークから選ぶ方式に変更した。あわせて、距離を4段階から選べるようにし、結果を記録として保存できるようにした
- 名前：アプリ名を「おとさんぽ」（英語名Soundwalk）とした
- 方向の分かりやすさ：実際に歩いたところ、音量の変化だけでは正しい方向に進んでいるかの判断が難しかった。そこで、正しい方向に歩き出した瞬間に音を強調する「向きの強調」と、正しい方向に歩き続けたときの小さな合図（「ピピッ」）を追加した。強調は、反応が遅いと分かりにくいため、GPSの進行方向を使って歩き出しにすぐ反応し、向きが変わった最初の1回だけ鳴らす形にした
- 使いやすさ：iPhoneの消音モードで音が鳴らない問題に対応した。許可の画面で「許可しない」を選ぶと元に戻すのが手間なため、許可を求める前に案内する画面を追加した。困ったときに見るQ＆Aのページ（help.html）を追加した
- プライバシー：位置情報の使い方の説明を追加し、目的地の検索サービスに送る位置を約100m単位にぼかすようにした
- デザイン：既存のアプリとの差別化のため、白を基調としたデザインに変更した。結果画面は、主要な数値だけを大きく表示する形に整理した
- README：中間発表時点の内容に更新し、Claimを実装に合わせて修正した
- 目的地の取得：目的地がほぼ毎回ランダムな地点になってしまう問題があった。調査の結果、公開されているOverpass APIのサーバーが不調（HTTP 502や応答なし）であることが分かった。サーバーの混雑時の応答の見分け、複数サーバーの利用、検索結果の保存、接続テストなどを追加したが、外部サーバーに頼る限り安定しないと判断した
- 目的地データの同梱：関東の場所データ（約21万件）を前もって取り出し、約5km四方の区画ファイルとしてアプリに同梱する方式に変更した。これにより、関東では通信の状態に関係なく、すぐ確実にランドマークを目的地にできるようになった。最初は地図ソフト用の形式（シェープファイル）から作ったが、神社が含まれていなかったため、すべての情報を含む形式（.osm.pbf）から作り直した
- 目的地の候補：ランドマークが見つからない場合でも身近な場所が目的地になるよう、候補を3段階（ランドマーク → 名前のあるカフェ・駅など → バス停）に広げ、直近の目的地が続かないようにした。大きな公園は、広さに応じて到着判定の範囲を広げた
- ヒントのレーダー：距離の輪だけでは分かりにくかったため、ドラゴンレーダーのように、自分を中心に目的地を点で表示する形に変更した。船のレーダーのように波で更新する形も試したが、意図した見え方と違ったため、開いたときの向きで1回だけ描く形にした。ヒントの順番は、情報が少ない順に並べ替えた
- 「ピピッ」：向きが微妙なときにも頻繁に鳴っていたため、判定を目的地の方向から約45度以内に厳しくし、間隔を30秒に1回までにした
- 探索中の画面に、音の変化の意味の一覧を追加した
- ヒントの「大まかな方角」を削除した。歩きながらでは方角（北・東など）を確かめにくく、方向を確かめる役割がキャリブレーションのやり直しと重なっていたため。ヒントは、やり直し → レーダー → ギブアップの3つになった
- 実際に歩いて、音の変化の付け方（強調の強さ、合図のタイミング、距離と音量の対応）を調整する
- デモ動画を撮る
- 「やってみて分かったこと」と、最終発表までの計画をまとめる
本リポジトリの文章およびコードは、CC BY 4.0で公開する（©︎ FuruhashiLaboratory/ChihanaUsui）。
ただし、sound/フォルダの楽曲はOtoLogicの著作物であり、OtoLogicの定めるCC BY 4.0に従う。詳細はsound/README.mdを参照。
音楽：OtoLogic（https://otologic.jp）
目的地の候補（公園・神社・像など）と、結果画面の地図には、OpenStreetMapのデータを使用している。data/lm/のファイルは、Geofabrikが配布するOpenStreetMapの抽出データ（2026年11月3日時点）から作成したもので、ODbL 1.0に従う。地図・場所のデータ：© OpenStreetMap contributors（ODbL）
地図の表示には、Leaflet（BSD 2-Clause License）を使用している。lib/leaflet/のファイルはLeafletの配布物であり、ライセンスはlib/leaflet/LICENSEに従う。
出発時のコンパスキャリブレーションと、歩行中は「目的地までの距離」と「進んでいる向きが合っているかどうか」に応じた音の変化（音量、音のこもり具合、短い合図）のみを用いることで、画面を見ず・両耳を塞がずに安全に、かつゲームとして楽しみながら、身近なランドマークに到達できる。
既存の位置情報ゲームは、地図が画面上に表示され、それに従って歩行する仕組みのものが大半で、歩行中の視覚的な注意をアプリに向けさせる設計になっている。歩行中の「ながらスマホ」は事故の原因となり危険である。また、「風景を見ながら歩くのを楽しむ」という点に重点を置くゲームは少ない。
本研究では、現在地の周辺にある公園や神社などのランドマークからランダムに選んだ目的地に対し、出発地点でコンパスキャリブレーションを行い、歩行中は目的地までの距離と、進んでいる向きが合っているかどうかを音の変化だけで伝える、音のみのナビゲーションシステムを開発する。目的地の方向そのものは歩行中に音で示さず、プレイヤーが自分で方向を探る。これにより、画面を見ず、かつ両耳を塞がない（モノラル・片耳イヤホン対応）安全な散歩体験の実現を目指す。
- 地図表示型ナビゲーション／記録アプリ（例：ALKOO by NAVITIME）は、到達圏探索の技術を用いて経由地をランダムに選ぶなど工夫があるが、地図を見ながら歩くことが前提になっている。
- ランダム目的地型アプリ（Dokoka, Wherewalk）は、行き先を伏せて発見を楽しませる面白い仕組みを持つが、矢印や地図など視覚情報に依存している。
- 位置情報ゲーム型アプリ（ポケモンGO、Ingress）は、収集・陣取り等の要素によって非常に強い継続動機を生み出すことに成功しているが、常時画面を確認する必要があり、「ながらスマホ」による事故等が社会問題として指摘されてきた。歩くことをゲームで包む設計は継続には効くが、「風景を楽しみながら歩く」という体験そのものからは距離ができてしまう。
- 音声によるナビゲーション研究は、主に視覚障害者支援の文脈で発展してきた（SWAN, audioGPS, Microsoft Soundscape, NavCog等）。これらは空間化された音（バイノーラルオーディオ）でビーコンを定位し、体の向きを常に音源へ追従させる方式が中心であり、両耳を塞ぐ形になるため屋外歩行時の安全性（周囲の音の聞こえにくさ）に懸念がある。
- アンビエントな音声誘導研究（Hearing the Way Forward, CHI 2023）や、音楽をナビゲーションに統合する研究（Guided by Music）など、「地図を見ない」誘導手法の研究も近年蓄積されつつある。
出発時の方向キャリブレーションと、歩行中の距離と進行方向の正しさに応じた音のフィードバックのみを用いて、画面を見ず・両耳を塞がずに安全に、かつ楽しみながら身近なランドマークに到達できるナビゲーションシステムを開発し、その実用性・安全性・面白さを明らかにすることを目的とする。
- 目的地に安全に導く方法は他にもある（立ち止まって画面を確認する、3D音響で正確に方向を示す、等）。本研究では、あえてそうした手段を採らない。歩行中に伝えるのは「距離」と「今の向きが合っているかどうか」だけで、目的地の方向そのものは示さない。こうして情報を絞ることで、安全性とゲームとしての面白さ（自分で方向を探る楽しさ）を両立させる設計を提案する。
- 目的地を地図データ（OpenStreetMap）に登録された公共のランドマークから選ぶことで、完全ランダムな地点で生じる私有地・立入困難な場所への誘導のリスクを減らし、身近な場所の発見につなげる。
- 既存の音声ナビゲーション研究の多くが前提とする「両耳・空間オーディオ」への依存を避け、モノラル・片耳イヤホンでも成立する設計を提示することで、音声ナビゲーション研究に安全性の観点から新しい選択肢を示せる。
- 空間情報系の技術（GPS、方位角計算など）を、位置情報ゲームという体験デザインに応用する実践例を示せる。
実装の詳細は「実装した機能」を参照。
- 目的地生成：OpenStreetMapのデータから、選んだ距離の範囲にある公園・神社・像などのランドマークをランダムに1か所選ぶ。候補がない場合はランダムな地点とする
- 出発時キャリブレーション：その場で回転し、目的地の方向を向くと音量が最大になる。時間制限は設けない。ヒントとして歩行中にやり直すこともできる
- 歩行中フィードバック：
- 距離：BGMの音量とこもり具合を、距離に応じて対数的に変える。残り50mで近距離モードに切り替える
- 進行方向の正しさ：正しい向きに歩き出した瞬間に音を強調し、離れる向きでは弱める。正しい向きに歩き続けると小さな合図を鳴らす。目的地の方向そのものは示さない
- 音の種類：OtoLogicの楽曲4曲から選択する。すべてモノラルで再生し、片耳イヤホンでも使えるようにする。立体音響は使用しない
- 振動：iPhoneのブラウザでは使えないため、現時点では使用しない
- ヒント：キャリブレーションのやり直し → レーダー（自分を中心に目的地を点で表示、直線距離と目安の時間） → ギブアップ（地図表示）
- 事後振り返り：かかった時間、歩いた距離、直線距離、ヒント使用回数、歩いた道のりの地図を表示し、記録として端末内に保存する
実装はAIによるプログラミング支援を活用して進めている。実装形態はWebアプリとし、GitHub Pagesで公開している。
- 位置情報：Geolocation API
- コンパス：DeviceOrientationEvent
- 音：Web Audio API
- 目的地の候補：OpenStreetMap（Overpass API）
- 地図の表示：Leaflet、OpenStreetMap
※ブラウザで動くため、画面が消えると音とGPSが止まる、iPhoneでは振動が使えない、などの制限がある。最終発表までに問題が大きいと判断した場合は、ネイティブアプリ化も検討する。
比較実験（他のアプリ・型との対決形式）ではなく、提案システム単体のフィールドテストによって、実用性・安全性・面白さを検証する方針とする。
- 客観指標：到達所要時間、ヒント使用回数、実移動距離／直線距離比、実際に画面を確認した回数・時間（安全性を実測で裏付ける指標）。アプリの記録をCSVで書き出して集計する
- 主観指標：満足度、面白さ、認知負荷（作業のしんどさを測るアンケート手法の利用を検討）、安全に歩けたと感じたか
- 中間発表（11月）：プロトタイプのデモと、実際に歩いて分かったことを報告する
- 中間発表後：自分や周りの人で歩いて試し、音の変化の付け方（強調の強さ、合図のタイミング、距離と音量の対応）を調整する
- 12月のAdvent Calendarで実装・実験の進捗を報告する
- フィールドテストを実施し、卒論提出（1月上旬）に向けて結果をまとめる
- 評価実験の被験者数・実施期間・実施場所
- 画面を確認した回数・時間の測り方
- 距離の設定ごとの所要時間の目安が、実際に合っているか
- 向きの強調や合図の強さ・タイミングの最適な値
- 電子コンパスの精度（磁気干渉によるズレ）が、キャリブレーションにどの程度影響するか
- OpenStreetMapのデータが古い・不正確な場合に、入れない場所が目的地になるリスクへの対応
- 画面が消えると止まるなどのWebアプリの制約が、評価実験の支障になるかどうか（なる場合はネイティブアプリ化を検討する）