miruomo.com

サービス概要

使用技術

技術	用途
Next.js	フロントエンド
TypeScript	型安全な開発
Firebase	認証・リアルタイムDB
Gemini API	AI 英会話応答生成

開発の思い

サービス概要

使用技術

技術	用途
Next.js	フロントエンド
JavaScript	実装言語
Firebase	認証・画像ストレージ・DB

開発の思い

サービス概要

使用技術

技術	用途
Next.js	フロントエンド
TypeScript	型安全な開発

開発の思い

サービス概要

ハンドドリップコーヒーのレシピとタイマーを一画面で確認できるWebアプリです。 タイマーは数字ではなくインジケータ形式で表示することで、 ドリッパーを注視しながらでも感覚的に進捗を把握できます。

開発の思い

明石高専珈琲研究会に入会し、ハンドドリップを始めました。 レシピ・タイマー・スケールをそれぞれ別に管理しながら ドリッパー内部も確認するのは想像以上に難しく、「一画面で完結するツールがあれば」と感じたことが開発のきっかけです。

コーヒースケール（重量と時間を同時に計れる専用器具）は 当時購入が難しかったため、手持ちのキッチンスケールとタイマーで代用していました。 このアプリを作ることでスケールを買わずに2年間コーヒー生活を楽しんでいます。 珈琲研の先輩から「このアプリすごいね」と声をかけてもらえたことも、自分にとって嬉しい体験でした。

技術選定の理由

Next.js + TypeScript

それまでPages Routerでの開発経験はあったが、 本プロジェクトでApp Routerを初めて採用。 Next.jsの開発環境に慣れていたこと、Vercelへのデプロイ親和性も選定理由のひとつ。

localStorage

1晩での開発を想定していた(深夜テンション)ため、バックエンドを持たない構成を選択。 設定の永続化にはlocalStorageへのJSON直保存を採用。 保存するのはコーヒーレシピの設定値のみで、このユースケースでは十分と判断しました。

こだわり

タイマーの進捗をインジケータ形式で視覚化することに最も開発時間を費やしました。 数字だけでなく視覚的な残量表示にすることで、 ドリッパーから目を離さずに操作できるUXを目指しました。

開発で直面したこと

App Router の学習コスト

layout.tsx と page.tsx の役割分担(データの受け渡し・layoutの継承)を十分に理解しないまま実装を始めたため、 認識の誤りに起因するバグの修正に苦労しました。 1晩開発の中で最もコストがかかった部分です。

サービス概要

就活・個人ブランディングを目的としたポートフォリオサイトです。 制作物・経歴・技術記事へのリンクをまとめています。

過去にリリースした作品はサブドメインでデプロイしており、このサイトから各プロジェクトのライブデモへアクセスできます。

現在開発中です。

開発の思い

3年ほど前からポートフォリオサイトを作りたいと考えていましたが、長岡技科大に入学しNUTMEGに加入した先で先輩のサイトに触発され、ようやく重い腰を上げて開発を始めました。

単なる作品一覧にとどまらず、自分らしさが伝わるサイトにしたいという思いから、デザインの方向性を固めるところから丁寧に取り組みました。 リファレンスとなるサイトを複数収集・分析し、「技術と個性が同居する、動きのあるポートフォリオ」をコンセプトに設定。 アクセントカラー（#FF301D）は赤い色が好きなことと、普段使っている名刺のアクセントカラーと統一したかったことから決定しました。

また、このサイト自体がPhase 1（MVP公開）とPhase 2（Three.js導入）に分かれた段階的な開発計画のもとで作られており、差し替えを前提とした設計を意識して実装しています。

Claude を活用した開発フロー

デザイン設計から実装まで、一貫してClaudeと壁打ちしながら進めました。

• コンセプト設計 — リファレンスサイトの分析・カラー選定・Three.jsの演出設計をClaude Chatで壁打ち
• 仕様書作成 — ワイヤーフレーム・デザイントークン・実装手順を含む設計仕様書をClaude Chatで生成
• 実装 — Claude Codeを活用してコーディング

技術選定の理由

Astro + TypeScript

コンテンツ中心の静的サイトに適したフレームワークとして採用。 インタラクティブな箇所にのみReact Islandsを使用することで、不要なJavaScriptの配信を最小限に抑えられる点を評価しました。

React（Islands）

インタラクティブなコンポーネント（Worksカード一覧など）に限定して採用。 Astroのアーキテクチャに従い、必要な箇所にのみ差し込む設計にしています。

GSAP

スクロール連動アニメーションの実装に採用。 Phase 2でScrollTriggerを有効化し、Three.jsカメラオブジェクトのスクロール連動制御に使用する予定です。

設計上のこだわり

Phase 1 / Phase 2 の段階的設計

Three.jsの導入（Phase 2）を後から差し込めるよう、Hero・Worksセクションにプレースホルダーコンポーネントを設置しています。 Phase 2では <CameraScene /> に1行差し替えるだけでThree.jsのカメラオブジェクトが有効になる構成です。

i18n の骨格

日英対応（Phase 2）を見越して、コンポーネント内にテキストをハードコードせず、src/i18n/ui.ts を通じたテキスト管理を最初から採用しています。 Phase 2では翻訳テキストを追記し、設定のコメントを外すだけで有効化できます。

画像最適化

全画像にAstroの <Image /> コンポーネントを使用し、ビルド時の自動WebP変換とlazyloadingを適用しています。

サービス概要

明石高専スポーツ大会の情報を一元配信する特設サイトです。 お知らせバナーによるリアルタイム告知と、 Google スプレッドシートと連携した得点速報機能を実装しました。

複数の競技会場に分かれた大会で、他会場の結果をリアルタイムに確認できる手段として Web研究部の活動として開発・運用しました。

2022年度の開発・運用経験を生かしてアップデートされた2023年度版特設サイトがこちらになります。

開発の思い

スポーツ大会では競技間の移動・進行遅延が連鎖的に起きやすく、 また会場が複数に分かれているため他競技の結果を把握しづらいという課題がありました。 「Webサイトで情報を一元管理できれば解決できる」と思い、 2021年には存在しなかった特設サイトを自分たちで立ち上げることにしました。

当日は得点速報をリアルタイムで更新し、参加者から喜んでもらえたことで 「作ったものが実際に使われる」体験を初めて得ることができました。

技術選定の理由

HTML + CSS + JavaScript

当時の自分たちの技術スタックに合わせてシンプルな静的サイトとして構築しました。

Google Sheets API

得点速報の更新をエンジニア以外のメンバーでも行えるようにするため、 Googleスプレッドシートをデータソースとして採用しました。 スプレッドシートを更新するだけでサイトに反映される仕組みにしています。

開発で直面したこと

トーナメント表の更新コスト

当日のトーナメント表はPowerPointで図を更新するたびに 画像をエクスポートしてレンタルサーバにアップロードする運用でした。 試合が進むたびに手作業が発生し、当日の運用負荷が高かったことが課題として残りました。

レンサバ直接編集によるサイト障害

コードはレンタルサーバの管理画面上で直接編集していたため、 div タグの閉じ忘れによってサイトが崩壊するという障害が発生しました。 この経験が翌年以降にGitHubでのバージョン管理へ移行するきっかけとなりました。

サービス概要

2022年版特設サイトの課題を解消した、明石高専スポーツ大会2023の情報配信サイトです。 Googleスプレッドシートをデータソースとして、得点速報・対戦表・トーナメント表を一元管理。 スプレッドシートを更新するだけで対戦表が自動反映され、 後半の試合の「未定」欄もチーム名に自動で置き換わる仕組みを実装しました。

2022年版はこちら。

開発の思い

2022年版ではPowerPointでトーナメント表を手作業で更新するたびに画像をエクスポートしてサーバにアップロードするという運用が大きな負荷でした。 また、レンタルサーバの管理画面上で直接コードを編集していたためdiv タグの閉じ忘れによるサイト崩壊も経験しました。

2023年版ではこれらの課題をすべて解消することを目標に設計を見直しました。 スプレッドシートの編集だけで対戦表・トーナメント表まで自動更新される仕組みを作り、当日の運用コストを大幅に削減できました。

技術選定の理由

Astro

Web研にモダンな技術を導入することを当時主導しており、その一環としてAstroを採用しました。 HTML・CSS・JSの記法をそのまま活かせるAstroは、他のメンバーにとっても学習コストが低く、チームへの導入に適していると判断しました。 自分自身もAstroを実プロダクトで使ってみたいという動機もありました。

Google Sheets API

試合結果や対戦表の更新は非エンジニアのスポーツ大会運営メンバーが行うため、新規にCMSを導入するよりも普段から使い慣れたGoogleスプレッドシートをデータソースとして採用しました。 2023年版では得点速報だけでなく対戦表・トーナメント表もスプレッドシートから配信する設計に拡張し、エンジニア以外のメンバーでも当日の情報更新を完結できる運用を実現しました。

2022年版からの改善点

課題（2022年）	改善（2023年）
トーナメント表をPowerPointで手作業更新・アップロード	スプシ編集で自動反映
得点速報のみスプシ連携	対戦表・トーナメント表もスプシから配信
レンサバ管理画面で直接編集	GitHubでバージョン管理・Vercelデプロイ
後半試合の対戦相手が「未定」のまま	確定次第チーム名に自動更新

サービス概要

3秒動画を撮影・結合・保存するまでをアプリ内で完結させるPWAです。 撮影・トリミング・結合という3ステップの煩雑さをなくし、 テンポ感のある日常Vlogをワンフローで作れることを目指しています。

現在開発中です。

開発の思い

ThreadsでおしゃれなVlogの撮り方として「3秒動画をつなげるだけ」という 手法を知り、試してみたところたしかにテンポ感のある映像になりました。 ただ、撮影→トリミング→結合の作業が分散していて続けるのが大変で、 一つのアプリ内で完結する手段が欲しいと感じたことが開発のきっかけです。

Claude を活用した開発フロー

このプロジェクトでは、開発前の設計からコーディングまで一貫してClaudeを活用しました。

1. 要件定義・設計 — Claude Chatで仕様を壁打ちし、docs/要件定義書.md と docs/設計仕様書.md としてリポジトリに設置
2. UIデザイン — Claude Designでアプリ画面を設計し、エクスポートしたファイル群もリポジトリに設置
3. CLAUDE.md生成 — 上記のドキュメントを参照させてCLAUDE.mdを生成、ルートに設置
4. 実装 — Claude Codeがこれらすべてをコンテキストとして読み取った状態で開発開始

ドキュメントを「単一の真実」としてリポジトリで管理し、 AIが常に設計意図を参照できる環境を整えた上でコーディングに入る、 というワークフローの検証も本プロジェクトの目的のひとつでした。

技術選定の理由

Next.js + TypeScript

これまでの開発で慣れた構成を採用。 PWA対応・Vercelデプロイとの親和性も選定理由のひとつ。

IndexedDB

動画データをブラウザ内に保存するためサーバーレスで完結する構成を選択。 localStorageでは扱えないバイナリデータの永続化にIndexedDBを採用。

ffmpeg.wasm

動画のトリミング・結合処理をサーバーサイドなしでブラウザ上で実現するために採用。 WebAssemblyベースのffmpegをブラウザで動かすことで、 アップロード不要のプライベートな動画処理を可能にしました。

現在の課題

開発途中でほぼ同様の機能を持つsetlogの存在を知り、 差別化をどう図るか検討中です。

サービス概要

大切な記念日を忘れないための、シンプルで強力なカレンダーアプリです。 「あの日から何日経ったっけ？」「次の記念日はいつだっけ？」という悩みを解消します。

PWAに対応しているため、スマホのホーム画面に追加してアプリのように利用できます。また、毎朝9:00に当日の記念日をプッシュ通知でお知らせするため、大切な日を見逃すことがありません。

開発の思い

パートナーとの記念日を管理するサービスを探していたものの、 理想に合うアプリが見つからなかったため、自作することにしました。 現在もパートナーと2人で実際に使い続けています。

AI駆動の開発フロー

このプロジェクトでは、開発全体を通じてAI（Gemini）を活用しました。

1. 仕様の言語化 — 要件定義・設計仕様書・開発手順をAIとの壁打ちで作成
2. 実装サイクル — AIの指示に沿って実装を進め、バグはAIと一緒にデバッグ
3. 仕様変更への対応 — 変更はまずドキュメントの更新から始め、コードに反映

ドキュメントを「単一の真実」として管理するこのフローは、 個人開発でも仕様の一貫性を保つ上で有効だと感じました。

技術選定の理由

Next.js + TypeScript

AIコーディングおよびNoSQL使用を前提に、型安全な開発環境を優先。 Vercelとのデプロイ親和性も選定理由のひとつ。

Firebase

スピード優先の個人開発にマッチしたサーバーレス構成。 RDB不要でリアルタイムDBを組める点を評価。

PWA

プッシュ通知の実装と、インストール不要でネイティブアプリに近いUXを実現するために採用。

Vercel Cron Jobs

2年前のハッカソンでFCMの実装に失敗した経験から、今回は定時実行と通知配信を分離する設計を選択。 設定のシンプルさと未経験技術への挑戦を兼ねて採用。

TailwindCSS + shadcn/ui

開発速度を優先し既存ライブラリを採用。 shadcn/uiは未経験だったためあえて選定し、知見を積む機会とした。

開発で直面したこと

自己申告の納期

パートナーに「1週間後に見せる」と宣言してしまったため、短期間での完成が必須でした。機能の優先順位を明確にし、MVP（最低限動くもの）を先に完成させてから改善を重ねる進め方で乗り切りました。

プッシュ通知の実装

過去のハッカソンで同様の実装に失敗した経験があったため、技術選定の段階から慎重に設計を検討しました。（技術選定参照） 結果として今回は問題なく実装でき、過去の失敗を活かせた部分でもあります。

AIツールのコンテキスト制約

GitHub Copilotを使わずGeminiのチャット形式で開発したため、リポジトリ全体をコンテキストとして渡せない制約がありました。 必要なコードを都度貼り付けながら進めることでカバーしました。

サービス概要

2人の会話をリアルタイムで音声認識し、その発話を「投球」に見立てて3Dアニメーションで可視化するWebアプリです。

マイク2本から話者ごとに音声を取得・文字起こしし、GeminiとルールベースによるAI分析でその発話を球種・球速・コースにマッピング。Three.jsで3Dボールが公園グラウンドを投球されるアニメーションとして表示し、会話の流れを「配球チャート」として可視化します。

HACK U KOSEN 2025 OSAKAにて優秀賞（審査員賞）を受賞。

https://hacku.yahoo.co.jp/kosen2025/

開発の思い

HACK U KOSEN 2025 OSAKAは約2週間の開発期間のハッカソンでした。

チームでFigJamを使ってアイデアを発散させた結果、ある観察に行き着きました。「高専生はゲームや専門の話はとても得意だが、日常会話のキャッチボールが苦手な傾向がある」というものです。

そこから「会話のキャッチボール」というメタファーが生まれ、「可視化してしまおう」というコンセプトに収束しました。多くのアイデアが出た中で、チームが「これだ」と納得できるコンセプトに絞り込んだことが、受賞につながった大きな要因だったと感じています。

発表前日ギリギリまで開発・発表準備を続け、最終的に優秀賞を受賞できたことはチーム全員にとって大きな達成感となりました。

チームと自分の役割

5人チームで、自分はアイデア出しと設計フェーズを主に担当しました。

• アイデア発案・収束 — FigJamでの発散を主導し「会話のキャッチボール可視化」というコンセプトに収束
• コンセプト設計 — 発話を球種・球速・コースに変換するマッピング設計（X軸：合理性↔共感性、Y軸：テンション高低）を考案
• システム設計 — DFD・データフロー設計・型定義をチームで議論しながら主導。FigJamで設計図を管理しチームで共有

プロダクトの仕組み

発話の「内容」と「勢い」を2軸で分析し、球種・球速・コースに変換します。

発話の特徴	変換先
話す速さ・テンション	球速（例：早口 → 高球速）
テンションの高低	コースのY軸（高い → 高め、低い → 低め）
合理的な話し方か共感的な話し方か	コースのX軸（合理性 ↔ 共感性）
発話の内容・文脈	球種（ストレート・カーブ・スライダーなど）

技術選定の理由

Google Cloud Speech-to-Text

Web Speech APIも候補に上がりましたが、過去プロジェクトでの精度の問題から採用を見送り。 DeepgramとGoogle Cloud STTを比較検討した結果、日本語認識精度と安定性を優先してGoogle Cloudを採用しました。

Gemini API + ルールベース処理の併用

発話の球種・コース判定にGeminiを採用。会話履歴を配列で渡すことで文脈を活かした分析を実現しました。ただしLLMだけでは出力の安定性が担保しにくい部分（球速などの定量的な指標）はルールベース処理で補完する設計にしています。

Three.js + Blender

球種ごとに異なる軌道をベジェ曲線で数式表現。公園の背景・キャラクター・ボールはBlenderで制作しThree.jsで表示させています。

Jotai

音声・テキスト履歴・分析結果という異なるライフサイクルのデータを分離管理するために採用。ため池GO!でのRecoil→Jotai移行の経験が活きました。

設計上のこだわり

「何を作るか」の解像度

単に「会話を可視化する」ではなく、球種・球速・コース・配球チャートという野球のメタファーを一貫して使うことで、展示会でも直感的に伝わるプロダクトになりました。コンセプトの言語化に時間をかけたことが、実装・発表・受賞すべてに繋がりました。

DFDによる設計の共有

実装前にFigJamでDFDを描き、データの流れをチーム全員で把握した状態で開発をスタートしました。音声・テキスト・分析結果を別オブジェクトで管理しIDで紐付ける設計も、この議論から生まれました。

受賞

HACK U KOSEN 2025 OSAKA 優秀賞（審査員賞）（2025年12月20日）

サービス概要

兵庫県いなみ野ため池ミュージアムと共同開発した、 東播磨地域のため池を巡るデジタルスタンプラリーWebアプリです。 現地に設置されたQRコードを読み込み、位置情報と照合することでスタンプを取得できます。 チェックイン時には「いきものガチャ」でそのため池に生息する生き物を収集でき、 図鑑・マップ・ランキング機能を通じてため池の自然や歴史を学ぶことができます。

2025年5月のリリース以降、累計利用者数は約1,000人・総チェックイン数は約10,000回を記録。 10代以下から70代まで幅広い年代に利用されています。

開発の思い

2023年12月、当時のWeb研顧問の先生から 「兵庫県からデジタルスタンプラリー製作の話が来ているが、興味があるか」と声をかけられました。 面白そうだと思い、2日ほどでQRコードを読み込んで位置情報と照合するだけのプロトタイプを作成。 反応が良く、そのまま県側で開かれている会議に参加できる流れとなりました。 翌2024年から有志メンバーを追加で募り、本格的な開発がスタートしました。

それまでは自分のためだけのプロダクトしか作ってきませんでしたが、このプロジェクトではクライアントがついた状態での企画・開発・運用・メンテナンスを約2年にわたって経験しました。 ユーザの声を反映して機能を改善し、高齢者の利用が多いとわかったときはUIを簡易化・文字サイズを拡大するなど、実際に使われるサービスを育てる経験が大きな自信となっています。

また、大阪・関西万博への2度の出展、農林水産省での広報活動、学術イベントDEIM2026での発表など、開発の枠を超えた活動の機会を得たことも、このプロジェクトが自分にもたらした大きな収穫です。

チームと自分の役割

10人弱のチームでの開発で、自分はリードエンジニアを担当しました。 UIデザインは明石高専建築学科の方が主導しました。

• 設計・アーキテクチャ — システム全体の設計とDBスキーマ設計を主導
• フロントエンド / バックエンド — 主要機能の実装を全般にわたって担当
• コードレビュー — 他メンバーのコードレビューと技術的な質問への対応

チームメンバーから技術的な方針の判断を求められることが多く、リードとしての責任感と、教えながら進める経験を積みました。

技術選定の理由

Next.js + TypeScript

SSRによるモバイルでの表示最適化と、Reactのコンポーネント指向による開発効率を評価して採用。 ユーザ入力が多いアプリのため、型安全な開発環境を最初から整えました。

PostgreSQL + Prisma

個人開発ではNoSQLを使うことが多かったが、ユーザ・スポット・いきもの・チェックイン履歴・キャンペーンなど複雑なリレーションを持つ大規模なサービスになることを想定し、初めてRDBMSを採用する技術的挑戦をしました。 ユーザ入力値を扱う箇所が多いため、生のSQLを記述せずPrismaの型安全なクエリビルダーを利用し、SQLインジェクション等の脆弱性を構造的に排除しました。

Jotai（Recoilからの移行）

開発途中でMetaがRecoilのサポートを終了したため、Jotaiへ移行しました。 APIの設計思想が近く、移行コストを最小限に抑えられた点を評価しました。

PWA

スマホのホーム画面からアプリのように起動できるUXを実現するために採用。 現地でのチェックイン操作という使われ方に適していると判断しました。

QRコード + 位置情報照合

不正利用（現地に行かずにスタンプ取得）を防ぐ手段としてNFC APIも検討しましたが、iOSのブラウザでは非対応であったため採用を断念。 QRコード読み取りと位置情報照合を組み合わせることで、コストを抑えながら「実際にその場所にいること」を担保する設計を選択しました。

こだわり・工夫

子供から高齢者まで使えるUI/UX設計

リリース後の利用データから高齢者の利用が多いことが判明し、アプリフローの簡易化・文字サイズの拡大・操作ステップの削減などを実施しました。 想定外のユーザ層にも届いたことで、実際に使われるサービスとして育てる難しさと面白さを学びました。

チェックイン時の例外処理設計

位置情報の取得失敗・権限拒否・不正なURLパラメータ・重複チェックインなど、現地での操作で発生しうる様々なエラーケースをフローチャートで整理し、それぞれに適切なモーダルとメッセージを実装しました。 「距離が離れています」「チェックイン済みです」など、ユーザが次のアクションを取りやすいエラー表示を意識しました。

ガチャのレアリティ設計

場所限定の貴重種（アサザなど）を設定することで、 遠方のため池への訪問動機を生み出す設計にしました。

A/Bテストによる効果検証

キャンペーン残り日数・達成状況の表示施策がユーザ行動に与える影響を DID（差分の差法）を用いて分析。 施策ありのA群はスタンプ収集までの時間が約1.5時間、 クーポン交換までの時間が約8.5時間短縮される傾向が確認されました。

メディア掲載 / 出展歴

メディア

• 【記事】神戸新聞NEXT（2025.01） — ため池の生態系、ゲームで学んで
• 【Yahooニュース掲載・記事・ラジオ】ラジトピ・ラジオ関西（2025.01） — 位置情報活用したゲーム開発
• 【記事】加古川経済新聞（2025.06） — 東播磨地域を巡るデジタルスタンプラリー
• 【YouTube】BAN-BANテレビ「ひがタン！」（2025.08） — アプリを体験しながら紹介
• 【記事】明石高専 公式ニュース（2025.06） — EXPO共鳴フェス出展報告

イベント出展・活動

• 大阪・関西万博「ひょうごフィールドパビリオンフェスティバル2025」（2025.05）
• 大阪・関西万博「EXPO共鳴フェス」（2025.06）
• 農林水産省 広報イベント（期間限定アクセスポイント設置）
• DEIM2026 発表
• いなみ野ため池巡りロゲイニング（2024.11、2025.11）

※ 制作実績として掲載する許可を得ています。