制作の動機

目まぐるしく変わる事業方針と、頻繁に追加されるスペック·機能要求に対応するために作りました。

コメント

入社後から継続的に高度化を重ね、最終的に SaaS に至ったソリューションです。 Flunti サイトの中核として、現在も高度化を続けています。

主な特徴

• 01マルチテナントルーティング: URL スコープ /[vendor]/[workspace] で企業·機関別に入口を分離、ミドルウェアで URL リライト / 権限分岐
• 02企業情報に基づく動的なメインページ·テーマ (ブランドカラーは Material Color Utilities でランタイム生成)
• 03Role ベースの機能 on/off: RoleProvider / RoleSweep / usePermission でページ·コンポーネント単位の制御
• 04TanStack Query + Next.js fetch API 統合 (serverPararellFetcher + HydrationBoundary)、ベンダー prefix query key でマルチテナントキャッシュ分離
• 05コンテンツタイプ: 動画講義、クイズ、プロジェクト、オフラインコース、セミナー、学習ロードマップ
• 06管理者アドミン (コース / 講義 / タグ / モデレーション + 権限 + 受講統計) + リセラー向け B2B 出店フロー

担当した役割

• 01プロジェクトのセットアップ、実装、アーキテクチャ定義
• 02proxy.ts (middleware) で権限 · 企業情報 · 認証情報を fetch し page header へ提供
• 03TanStack Query + Next.js fetch API 統合 fetcher 作成、各ページ fetcher で SSR / hydration を単純化
• 04entities 層の API 自動生成スクリプト作成と全面適用
• 05主要機能の実装: ロードマップ一覧 / 詳細、講義一覧 / 詳細、VOD、Quiz、Project、掲示板 (QNA / お知らせ / FAQ) など

制作の動機

オン·オフライン講義の需要に応じて出席モジュールを別途用意し、オンライン講義の場合はページ内でプラットフォームのアカウントを用いて Zoom 講義を受講できるようにしました。 アドミンはこれらすべてを一箇所で管理·確認できるよう構築されています。

コメント

2024 年末 〜 2025 年初頭に進めていたプロジェクトを教訓に立ち上げたプロジェクトです。 FE 側でもキャッシングをある程度導入し、API コール頻度や最適化により注意を払って実装しました。

主な特徴

• 01動的に管理可能なメニュー
• 02メイン LMS (Flunti) とは別に、クラスマネジメント専用の権限体系を実装
• 03多様なクラスマネジメント機能 (ライブ / VOD / 出席 / 掲示板) をサポート
• 04スケジュール状況板の提供および日程ベースのコンテンツ生成

担当した役割

• 01プロジェクトのセットアップ、実装、アーキテクチャ定義
• 02Zoom SDK を用いた Live 機能の実装
• 03Flunti の一部機能を踏襲しつつ改良
• 04動的な掲示板生成のための page wrapper 実装 (QNA / Notice / FAQ / Common の 4 種)
• 05出席ダッシュボードの作成およびショートカットページの実装

制作の動機

必要な在庫維持コストを削減し、注文充足までの時間を短縮することで、物流全体の効率を引き上げるために作成しました。

コメント

開発者として初めて主導的に担当したプロジェクトです。 FE アーキテクチャ全般を担当し BE は補助として参加、共通関数 · サンプルページ · 機能モジュールの作成およびリファクタリングを担いました。

主な特徴

• 01依頼企業の要件に合わせたチューニングが可能
• 02基本的な Warehouse Management フローを内蔵
• 03三者物流 (3PLA) に対応
• 04Vue 3 + TypeScript + Spring Boot ベース

担当した役割

• 01レガシー nexacro を Vue 3 + TypeScript + Spring Boot へマイグレーション
• 02API 呼び出し / レスポンスの最適化
• 03フォーム / グリッド / 検索条件など主要機能のモジュール化およびサンプルコード作成
• 04検索条件の動的生成ロジックをリファクタリング (再利用性 / 保守性の向上)
• 05WS ベースの通知システム実装 (リアルタイム通知 + メッセージ)
• 06PDF.js + Fabric.js による図面機能の実装

制作の動機

プロジェクト数の増加に対してデザインの断片化が目立ち始めていました。 これを防ぐため、基準となるデザインシステムを構築しました。

コメント

Document ページ (SSG)、Storybook / Plugin、CLI などの利便機能まで揃えて仕上げたデザインシステムです。 1 年が経った今もよく使われており、時折コンポーネントが追加されることもあります。

主な特徴

• 01非常に充実したコンポーネントラインナップ (40+ 種)
• 02SSG で生成された Document ページ + Storybook によるコンポーネント Preview
• 03Storybook にはデザイナーとの迅速な協業のため、Notion API を活用した comment plugin を実装
• 04Document ページ内に Icon をすぐ検索·利用できる専用ページを提供
• 05デザイントークン値も自動でパースされ、ページ上にそのまま表示

担当した役割

• 01デザインシステムの core · Document · Storybook のための monorepo 構築 (pnpm workspace)
• 02MD ファイルベースで SSG 化した静的 Document ページの作成
• 03GitHub Actions の配備スクリプト作成および配備
• 04他プロジェクトでの利用 / 更新のための CLI コマンド作成

制作の動機

継続的な人員減少のなかで AI 活用を最大化する必要があり、AI によるコードの一貫性確保と生産性向上のために用意しました。

コメント

チームメンバーが同じ LLM ドキュメントを参照して一貫したコードを生成できるよう、マークダウンドキュメントを継続的に高度化しています。 PR レビュー / widgets · features コンポーネント生成 / テストコード作成 / PR description 作成など、よく使うコマンドとスキルを合わせて整理し、チーム規約や既存コードを根拠とした規約、デザイントークンガイドまで文書化しています。

主な特徴

• 01実装 · テスト · レビューなど業務全般で使われる skills / commands を提供
• 02チーム規約 + 既存コードを根拠とした規約をドキュメント化
• 03デザイントークンガイドも収録

担当した役割

• 01プロジェクト Document ページの作成
• 02skills / commands インストール用 CLI の作成
• 03上記内容を配備するための GitHub Actions 作成

制作の動機

従来のフローは「デザイナーの Figma 作業 → FE パブリッシング → ロジック作業」の順序で、Figma → FE パブリッシング工程がボトルネックでした。 ワイヤーフレームベースのデザインシステムを用いたページ生成をデザイナーに提案し、design-studio がこれを自動化することで、ボトルネックがほぼ解消しました。 変更後のフロー: ワイヤーフレーム作成 → design-studio でページ生成 → FE はページを見てパブリッシング完了 → デザイナーは生成されたページを基に Figma に文書化。

コメント

このソリューションを構築した後、デザイナーから「非常に有用だ」というコメントを受けており、自身も日常業務でその有用性を十分に実感しています。

主な特徴

• 01ワイヤーフレームを与えるだけで Flunti デザインシステム (Design System) に沿ってページを自動生成
• 02自動 commit コマンド対応
• 03FE アーキテクチャ (FSD) に合わせて features / widgets 単位のコンポーネント + Mock entities を自動生成し、迅速なパブリッシングを実現

担当した役割

• 01ページ生成のためのプロンプト作成およびコマンド化
• 02生成されたページのプレビュー用 Next.js ベース SSG プロジェクトの作成
• 03ページ配備のための GitHub Actions スクリプト作成

制作の動機

システム全体を一箇所で管理したいという社内要望がありました。 当時 BE 人員の退職で一人に作業が集中していた一方、FE は比較的余裕があったため、FE 側で Drizzle を導入し View 層を ORM で直接取得してデータを表示し、Create / Update / Delete のロジックのみ実装された API と組み合わせて、社内メンバーが Flunti システムを操作できるアドミンを実装しました。

コメント

実装過程で AI を積極的に活用し、短期間で作業を仕上げたプロジェクトです。

主な特徴

• 01View と Action の分離 (ORM での View 参照 / API による更新)
• 02社内アドミンのみがアクセス可能なよう設計されたページ構成

担当した役割

• 01全体の実装
• 02Drizzle の pull 機能を活用した DB schema 生成、および AI を用いた select repository の生成
• 03各アドミンページの作成

制作の動機

velog · tistory · medium といったプラットフォームもありますが、試したい技術を自由に適用できる場が必要でした。

コメント

4年間スタックを変え続けた痕跡がブランチにそのまま残っているブログです。 長期運用とレガシーマイグレーションを継続しており、現在は Vercel + 別バックエンドの構成でサイトを運営しています。

主な特徴

• 01Article: マークダウンベースの長文 (MDX + remark/rehype レンダリング)
• 02Notice: メインページに公知 + 最新 Article を自動表示
• 03Article list: タグ別フィルタリング + キーワード検索 (タイトル / 本文)
• 04Log ページ: 短文タイムライン
• 05コメント / カテゴリ / 画像添付 (自前イメージサーバ経由)
• 06管理画面ダッシュボード: 統計 / モデレーション / 記事ステータス管理
• 07Vue → Svelte → Next.js へ 4 年間スタック移行
• 08AWS Cognito → NextAuth → better-auth と認証を進化
• 09AWS Lightsail 自前運用 → Vercel + 別 BE (b-hub) に分離 (セキュリティ責任の分離)
• 10Tailwind v3 → v4 マイグレーションでデザインシステム全体を手動再構成

制作の動機

会社で SaaS を作る楽しさから、個人プロジェクトとしても挑戦してみたくなりました。 velog や medium のような SaaS 型ブログも自作できる自信を得て、Hono でどこまでフルスタックを攻められるか試したかったのです。

コメント

Hono + React SSR + Island でフルスタックを自前構築しました。 Astro から学んだ island を適用する絶好の機会で、実際に成功しました。

主な特徴

• 01初期は Cloudflare Workers 単一構造 → FE/BE/Admin 3-repo へ分離進化 (管理画面は CSR で別)
• 02Hono + React SSR + Island アーキテクチャ (Astro から着想)、3 プロセス並列 dev 環境
• 03Cloudflare Free Tier でコスト 0 円運用、smart_placement で D1 近接リージョン自動配置
• 04自前の image-convert-server (Lightsail) で Cloudflare R2 の sharp 非対応を回避
• 05rehype-remark で双方向 md ↔ html エディタ (contentEditable + dnd-kit)
• 06kataru.dev/<userSubpath> マルチテナント (domain.service + gateway.route で分岐)

制作の動機

shields.io の存在は知っていましたが、いつサービス終了するかわからない外部サービスに依存したくありませんでした。 過去に Next.js の @vercel/og が Satori を使っていたことを思い出し、「自分も Satori で作ってみよう」と動機づけられました。

コメント

最小のコードで最も頻繁に使われるツールです。 README 1 行のバッジが毎日表示される状況で、外部サービスに依存せず自身でコントロールしています。

主な特徴

• 01Satori (JSX → SVG) + @resvg/resvg-wasm (SVG → PNG) パイプラインを Hono 上に自前で組立
• 02Vercel 関数で wasm ファイルパスを直接掴んで初期化する環境分岐処理
• 03URL クエリだけで全てカスタマイズ: Tailwind クラスを URL にそのまま渡せる (tw-to-css)
• 04内蔵アイコンスラッグ + 任意の favicon を読込 (icojs で .ico 動的デコード)
• 05韓国語フォント (Noto Sans KR) 内蔵で韓国語バッジ生成可

制作の動機

NAVER ウェブトゥーンを愛読する中で、いつも読んでいる作品をその都度探して開くのが煩雑で、ブックマークページも別途遷移しなければならない不便さがありました。 これを解決するため、Chrome 拡張を作成してメインに新しいタブを差し込み、パースした作品の中からチェックしたものだけを表示する機能を作り、Chrome Extension Store に公開しました。

コメント

MV2 → MV3 マイグレーション、Chakra → shadcn 移行、Bun 自前ビルドパイプラインの 3 つを一度に整理しました。 韓国のウェブトゥーンドメインで実際に利用されている拡張機能です。

主な特徴

• 01Chrome Manifest V3 + chrome.storage.local: Content Script (DOM 操作) + Popup (React) 構成
• 02v1 → v2 再構築: Chakra UI → shadcn 移行、Vite/CRXJS → Bun 自前ビルドパイプライン
• 03Proxy オブジェクトでライブラリなしのリアクティブ状態管理 (Vanilla パターン)
• 04権限最小化: host_permissions 1 個 (comic.naver.com)、permissions 1 個 (storage)
• 05Bun ビルド + adm-zip でストア提出用 zip 自動生成、Vite/Webpack 依存ゼロ
• 06実ユーザー 30 名、1 年 5 ヶ月の無更新でも正常動作 (NAVER マークアップ安定)

制作の動機

会社で AMS / WMS を作っていた経験があり、その根幹となるユーザー別言語 · タブ · カスタマイズ可能な ADMIN コア機能を、自身のサイドで実装することに集中しました。 自身は React 派ですが、最初の会社が Vue + Spring Boot の環境だったためです。

コメント

2024 年時点の模範的フルスタック構成 (Vite 4 + Vue 3.4 + Spring Boot 3.2 + JWT) を備えました。 React 本拠以外にも会社スタックを深く扱えることを示した事例です。

主な特徴

• 01Vue 3.4 + Vite 4 + Pinia (persistedstate) + vue-i18n 9 (サーバサイド: DB の Locale エンティティから fetch)
• 02Spring Boot 3.2.2 + Java 17 + Spring Data JPA + Spring Security + JJWT 0.11 + Redis Reactive
• 03JWT フィルタの抽象化: AbstAuthProcessFilterImpl で共通部を分離、JwtAuthFilter で拡張 (もう 1 段抽象化)
• 04タブシステム (keep-alive + Pinia): addCache/getCacheList/removeCache/refreshCurrentTab の 4 関数で同期
• 05メニュー-ロール動的権限: Menubyrole · RoleByUser の独立エンティティ + 複合キーでロール別メニュー決定
• 06DaisyUI テーマプリセット + 自作グリッド (CRUD · マスキング · 行スタイル): ag-grid を段階的に置換中

制作の動機

ナムウィキのようにスクロールバーに目次が出るのがセンセーショナルでした。 従来の ToC ライブラリはサイドバーにテキストを描きますが、本ライブラリは空いている空間 (スクロールバーの隣) を活用します。

コメント

依存ゼロで React / Vue / Svelte / Vanilla どの環境でも軽量に import できます。 1 日で v1 を publish し、累計 459 ダウンロードを記録しています。

主な特徴

• 01依存をなくしました
• 02tsdown (Rolldown ベース) で ESM + CJS + .d.ts のデュアル出力
• 03IntersectionObserver の代わりに rAF ポーリング + Map トラッキング: Next.js 16 cacheComponents 環境対応
• 04WeakMap → Map に変更: 参照切れケースで明示的な cleanup を保証
• 05History API monkey-patch + popstate で SPA ナビゲーション時に一括整理
• 06GitHub Actions + NPM SLSA Provenance: 検証済みビルドのみ publish

制作の動機

もともと使っていたアプリ snoww がサービス終了しました。 この機会に勉強も兼ねて、一度自分で作ってみようという気持ちで始めました。

コメント

ML 不使用、ルールベースで綺麗に動作する活動検出を実装しました。 スロープ環境を前提としたオフラインファースト設計で構築しています。

主な特徴

• 01Expo SDK 54 + RN 0.81 + expo-router 6 + New Architecture、NativeWind 4 + @rn-primitives (shadcn-RN)
• 02自作のルールベース活動検出: 3 状態 (skiing/lifting/resting) 自動遷移、ML 不使用で平滑化 + 差分
• 03ノイズフィルタ: speed 3 件移動平均、altitude 5 件差分、accuracy > 50m 破棄、3 秒の遷移遅延
• 04バックグラウンド位置追跡: BestForNavigation 1 秒/1m、Foreground Service 通知 (Android)、ActivityType.Fitness
• 05expo-sqlite 4 テーブル (sessions/locations/runs/photos): ローカル優先 + is_synced でサーバ同期
• 06expo-maps (MapLibre から移行)、クラッシュ復旧、トラッキングシミュレータ、ko/ja/en i18n

制作の動機

毎日 AI 関連の話題を探して読むのに費やす時間が惜しいと感じていました。 よく見るサイトを一括で巡回し、デイリー / ウィークリーレポートを自動作成することにしました。

コメント

LLM 1 プロバイダに縛られない Fallback Chain を構成しました。 韓 · 日 · 英の多言語を同時運用して言説の違いを比較でき、自身の毎日 9 サイト巡回時間をゼロにしました。

主な特徴

• 01Turborepo + Bun workspaces: apps/parser (Python 3.12 + uv) + apps/web (Next.js 16) + packages/db (Drizzle MySQL)
• 02LLM Fallback Chain 5 種: Ollama Cloud / Ollama Local / omlx (Apple MLX) / OpenRouter / OpenAI
• 03韓 · 日 · 英 同一期間 · 同一構造のレポート: 言語別の視点の違いを比較可
• 04cron 自動化: 毎時 RSS、1 時間に 2 回キーワード抽出、毎日 00:30 日次、毎週月曜週次、14 日 / 8 週 backfill
• 05本文補強 (trafilatura) + cloakbrowser でアンチボット回避、原語のままキーワード抽出 (翻訳禁止プロンプト)
• 06Docker (Playwright Python + Noto CJK + cron + tini)、運用コスト事実上 0 円 (Ollama free + Vercel + ローカル)

制作の動機

Android 端末を導入したのですが、iCloud カレンダーが Android に馴染みませんでした。 iPhone · Mac · Android · Windows どこでも同じカレンダーを使いたく、CalDAV 標準をサポートすればあらゆるアプリでそのまま利用できます。

コメント

自身の生活向上のために作り、統合しました: 全デバイスで同じカレンダー、一度の .mobileconfig ダウンロードで iPhone 自動登録。 現在すべての予定をここで管理しています。

主な特徴

• 01CalDAV 双方向同期: Apple Calendar / Thunderbird / GNOME Calendar など標準クライアント互換
• 02iOS .mobileconfig をブラウザで直接生成: plist XML を download、ワンクリックで iOS/macOS に CalDAV 自動登録
• 03Next.js 16 + React 19 + React Compiler 有効、shadcn + Radix + Tailwind 4
• 04@dnd-kit ドラッグ/リサイズ: EventLayout/ResizePreview/MovePreview で複数週 span 衝突を回避
• 05proxy.ts で Vercel WAF を回避: CalDAV の PROPFIND / REPORT など非標準メソッドを caldav.hyns.dev 経由
• 06Server Action 認証 forward + CSRF (Origin/Host)、Nanum Gothic + M+ 1 Code の CJK フォントを直接ホスト

制作の動機

毎朝シャワー後に Siri を呼ぶルーティンを簡素化し、天気を視覚的にはっきり確認するために ESP32 でダッシュボードを作成しました。 ちょうど手元に ESP32 があったため、一度自分で組んでみることにしました。

コメント

組み込みを実際に構築・体験・利用しています。 ファームウェア (C++) → b-hub (TypeScript) → MySQL → KMA のフルスタックの流れを完成させ、Web では当然視していたメモリ・画面バッファ・フォント描画を機械側から再考する契機になりました。

主な特徴

• 01ESP32-D0WD-V3 + ILI9341 2.8" TFT (320×210) + XPT2046 抵抗膜タッチ: "Cheap Yellow Display"
• 02State machine: BOOT → WIFI_SETUP → LOCATION_SEARCH → WEATHER ⇄ SETTINGS / DISPLAY_SETTINGS
• 032 ボル式ハングルキーボードを自前実装 (位置検索用): ライブラリなしで作成、再利用可能に分離
• 04u8g2 unifont ハングル + drawJamoGlyph() で互換字母をピクセル描画
• 05自己復旧: 60 秒 heap 監視、KST 00 / 12 時に自発 reboot、fetch all-or-nothing (stale 維持)
• 06b-hub /weather/* プロキシ: KMA API キー非露出、格子座標変換を委任、weatherApiKey でクォータ管理

制作の動機

保守が散らかっていました。各 Toys ごとにバックエンドを別々に作るのは N 倍の負担でした。 認証 / デプロイ / DB / 画像処理 / キャッシュを 1 箇所に集約することを決め、BBlog 移行時点 (2025) に同時計画を開始しました。

コメント

Toys 別の散乱を 1 箇所に統合しました。 mail ドメインと自前の Web メールクライアントで Outlook を代替し、毎回インストールしていたものを Web で処理しています。

主な特徴

• 01Bun on Vercel Functions + Hono 4 + @hono/zod-openapi (OpenAPI 3 + Swagger UI 自動)
• 028 ドメイン (blog · calendar · weather · mail · drive · spotify · resume · badge)、40+ テーブルにユーザー FK を一貫適用
• 033-tier ハイブリッドストレージ: R2 hot / Mac Studio middle (予定) / Google Drive cold、lifecycle cron で自動 promote / evict
• 04RFC 4791 CalDAV サーバを自前実装 (ctag · sync-token · ICS export · subscription token)
• 05Vercel サイドカー構成: caldav-proxy (DDoS bypass 用 PROPFIND/REPORT) + upload-server (4.5MB ペイロード制限回避)
• 06API Token 多層認証 (better-auth セッション / apiToken テーブル / ドメイン別 weatherApiKey、IoT 用クォータ分離)