地図・予算・AIを備えた自己ホスト旅行計画OSS「TREK」の仕組み

「グループ旅行の計画を Notion に、地図の共有を Google Maps に、予算の割り勘は別のアプリに」——複数ツールを行き来する非効率さに悩みつつ、プライバシー面からクラウド SaaS への集中投資も避けたい。そんな要件を一つのアプリで満たそうとする自己ホスト型（セルフホスト型）OSS が mauriceboe/TREK です。

TREK は「Your trips. Your plan. Your server.」というキャッチコピーの通り、旅行計画・地図・予算・パッキング・旅日記・訪問国トラッキングを自分のサーバー上に統合できるツールです。加えて、リアルタイム協働編集・PWA によるモバイル対応・MCP サーバー内蔵による AI 連携という、比較的新しい要素を初期段階から備えています。

一方、実運用に載せる際には、AGPL-3.0 の適用範囲や SQLite のスケーラビリティ、類似 OSS との棲み分けなど、確認しておくべき論点がいくつかあります。エンジニアが短時間で「自チームで採用してよいか」を判断できる情報は、README を斜め読みするだけでは不足しがちです。

本記事では公式 README・公式サイト・GitHub リポジトリメタ情報を出典として、TREK の機能全体像・技術スタック・導入の考え方・類似 OSS との違いを整理します。動作検証やスクリーンショット取得は行っておらず、ドキュメントベースの整理に限定しています。実際の挙動や画面遷移は公式デモや自環境で確認してください。

TREKとは何か

TREK は自己ホスト型（セルフホスト型）の旅行・旅程プランナーで、公式リポジトリの説明では「A self-hosted travel/trip planner with real-time collaboration, interactive maps, PWA support, SSO, budgets, packing lists, and more.」と紹介されています（出典: mauriceboe/TREK 公式リポジトリ）。旅程の作成から予約・費用・パッキング・旅日記までを 1 つのサーバーに集約する点が特徴で、Docker や Kubernetes（Helm）で配布されており、PWA としてスマートフォンから利用することも可能です。

リポジトリの基本情報

gh api /repos/mauriceboe/TREK で取得したメタ情報の要点は次の通りです。

archived と fork がいずれも false であることから、本家として現役で開発が継続されているリポジトリだと確認できます。読み手が心配する「メンテナンス停止」「派生元との違いが分からない」といった懸念に該当しない構成です。

より詳しい調査ログや検討背景は、リポジトリ内 README と公式サイト liketrek.com が一次情報として整備されています。

「Your trips. Your plan. Your server.」が意味するもの

README のサブタイトル「Your trips. Your plan. Your server.」は、旅行計画に含まれる位置情報・写真・宿泊予約といった機密性の高いデータを、外部 SaaS ではなく自分の管理するインフラに閉じたい層に向けたメッセージです。旅程は個人・グループ・企業出張のいずれもプライベート情報を大量に扱うため、「クラウドに預けたくない」というニーズが選定理由になりやすい分野といえます。

AGPL-3.0 の適用範囲

TREK は AGPL-3.0 で公開されています。個人利用や社内で完結する自己ホスト運用の範囲では、既存の OSS 運用と大きな差はありません。一方、ネットワーク越しに第三者へ改変版のサービスを提供する場合、改変内容も AGPL-3.0 で公開する義務が生じます（ネットワーク帰属条項）。組織で採用する場合は、想定する利用形態が「社内向け」か「顧客・一般ユーザー向け」かによって、法務・セキュリティ観点の確認事項が変わる点に注意してください。

主要機能の全体像

TREK は README の「What you get」節で機能群を紹介しています。全体を眺めると単なる旅程管理を超え、旅の設計から実行・記録・精算までのライフサイクルを一つのアプリでカバーする構成になっています。ここでは「自チームが必要とする機能があるか」を素早く見極められるよう、6 つの領域に整理します。機能の詳細と最新スクリーンショットは公式サイト liketrek.com 経由でも確認できます。

旅程計画

• ドラッグ＆ドロップによる日別プラン編成
• Leaflet または Mapbox GL によるインタラクティブ地図（3D 建物・地形・ルート可視化・写真マーカー・クラスタリング）
• 場所検索: Google Places（写真・レビュー・営業時間）または OpenStreetMap（API キー不要）
• 場所インポート: Google Maps / Naver Maps 共有リスト、GPX / KML / KMZ / GeoJSON
• ルート最適化と Google Maps へのエクスポート
• 天気予報: Open-Meteo による 16 日予報（API キー不要）＋気候履歴フォールバック
• タイムスタンプ付きの日別ノート、カテゴリフィルター

地図描画や場所検索については、Mapbox のような商用地図と、キー不要な OpenStreetMap を切り替えられる点が特徴です。商用契約なしに地図中心の運用を始められるため、PoC・社内利用時の初期コストを抑えやすい構成です。

旅の管理

• 予約管理（フライト・宿泊・レストラン）: KDE Itinerary によるメール・PDF からのインポート
• 経費管理・割り勘（Splitwise 相当）: 人別・日別内訳、多通貨、清算
• パッキングリスト: カテゴリ・テンプレート・進捗管理、荷物重量トラッキング（オプション）
• ドキュメント管理（1 ファイル ≤ 50 MB）
• PDF エクスポート（旅程・写真・ノート）

割り勘機能は「グループ旅行の幹事」ペインを直接カバーする要素で、多くの旅行計画 OSS が扱っていない領域です。旅の管理を一つのサーバーに閉じたい層にとって、これらが同じ UI に統合されている点は大きな判断材料になります。

コラボレーション

• WebSocket によるリアルタイム同期（複数ユーザーが同時編集）
• 招待リンク（ワンタイム／再利用可、有効期限指定）
• SSO（OIDC: Google / Apple / Authentik / Keycloak など）
• 2FA（TOTP + バックアップコード）
• Passkeys（WebAuthn）
• グループチャット・共有ノート・投票・日別チェックイン（Collab アドオン）

同時編集が「即時反映」される点は、後述の類似 OSS 比較でも差別化ポイントとして扱います。SSO と Passkeys まで揃っているため、社内向け SaaS 相当の認証要件をそのまま満たしやすい構成です。

モバイル対応と PWA

• iOS・Android にブラウザから直接インストール可能
• Workbox によるオフライン対応（Service Worker がタイル・API・アップロードをキャッシュ）
• フルスクリーン・スプラッシュ画面・セーフエリア対応

App Store／Google Play への公開を経ずにモバイル配布できる構成のため、企業内での配布・アップデートのハードルが低い点は運用コストに直結します。

AI・MCP 連携

• OAuth 2.1 認証付き MCP サーバー内蔵
• 150 種以上のツール、30 種のリソース
• 27 個の OAuth スコープ（13 のパーミッショングループ）
• プリセットプロンプト: trip-summary / packing-list / budget-overview

MCP（Model Context Protocol）サーバーが標準搭載されているため、AI クライアントから旅程生成・パッキング作成・予算集計・訪問国更新までを操作対象にできます。旅程管理 OSS でこの粒度の MCP サーバーを内蔵している例は 2026 年時点でも少なく、TREK の独自性の一つです。

アドオン群

管理者トグルで機能単位のオン／オフを切り替えられます。README では以下のアドオンが挙げられています。

• Lists / Costs / Documents / Collab
• Vacay: 個人休暇プランナー（100 か国以上の祝日カレンダー・繰越）
• Atlas: 訪問国の世界地図・バケットリスト・ストリーク
• Journey: マガジン風の旅日記（Immich・Synology Photos 連携）
• AirTrail: 自己ホスト AirTrail からのフライトインポート
• MCP: OAuth 2.1 対応の Model Context Protocol サーバー

社内利用時に必要な機能だけを有効化して露出面積を絞れるため、要件が明確な組織にとって取り回しやすい構造です。

技術スタックとアーキテクチャ

TREK のバックエンドは Node.js 22 と NestJS 11 で構築されており、データストアは SQLite（./data/travel.db）です。フロントエンドは React 19 + Vite + TypeScript + Tailwind、状態管理は Zustand、地図には Leaflet と Mapbox GL、リアルタイム同期には ws パッケージによる WebSocket を採用しています。認証は JWT を軸に、OAuth 2.1・OIDC・Passkeys（WebAuthn）・TOTP MFA が統合されています（出典: mauriceboe/TREK 公式リポジトリ の「Tech stack」節）。

バックエンド構成

Node.js 22 + NestJS 11 という組み合わせは、TypeScript のエコシステムに慣れたバックエンドエンジニアにとって取り組みやすい構成です。DI コンテナ・モジュール分割・パイプ／ガード等の抽象が標準化されているため、独自機能を追加する際にも既存パターンに沿って拡張しやすい設計になっています。

SQLite をメインストアに採用している点は「シングルバイナリで気軽に自己ホストしたい」というユースケースに合っています。反面、書き込みが集中するワークロードや、複数ノードでの水平スケールが前提のワークロードは想定されていません。ライブラリ層で PostgreSQL 等の別 DB に差し替える公式手順は README 上に示されていないため、想定利用規模に合わせて設計段階から見極める必要があります。

フロントエンド構成

React 19 + Vite + TypeScript + Tailwind + Zustand という現代的な組み合わせで、地図描画には Leaflet と Mapbox GL の両方をサポートしています。フロントエンドの実装に手を入れたい場合、React 実務経験者であれば構造を追いやすいでしょう。TSX ベースで UI を拡張・カスタマイズしたい組織にとってはとっつきやすい構成です。

認証・セキュリティ

• JWT ベースの認可
• OAuth 2.1 対応（MCP サーバーとの統合含む）
• OIDC による SSO（Google / Apple / Authentik / Keycloak 等）
• Passkeys（WebAuthn）による認証
• TOTP MFA + バックアップコード
• ドキュメントの at-rest 暗号化キー（ENCRYPTION_KEY 環境変数）

自己ホスト OSS としてはかなり幅広い認証手段を初期状態で備えている点が特徴です。Passkeys と OIDC の両立が可能なため、社内認証基盤との連携も想定しやすい構成です。

スケーラビリティの現実的な目安

SQLite の書き込み並列度に上限があるため、大規模グループ・多テナント SaaS 用途をそのまま乗せる構成には向いていません。README では想定同時ユーザー数の明示的な数字は示されていませんが、次の観点で妥当性を検討するとよいでしょう。

• 想定される最大同時編集人数（十数人までの小〜中規模グループが現実的）
• データ量の伸び（ドキュメント・写真の合計サイズ、./data・./uploads ボリュームのサイズ推移）
• バックアップ戦略（自動バックアップの保持期間、リストア検証の頻度）

大規模運用を検討する場合は、事前に PoC で書き込みボトルネックの計測を行い、想定ユーザー数と SQLite の限界を突き合わせる工程を挟むのが安全です。公式が提供する Discord コミュニティ では運用上のフィードバックがやり取りされているため、類似規模の運用事例を確認する場としても活用できます。

導入と運用の全体像

TREK は Docker・Docker Compose・Helm チャートで配布されており、単体起動から Kubernetes 上の運用まで公式が想定する経路をたどれます。ここでは実行手順の丸写しではなく、「どの選択肢がどのユースケースに向くか」という判断軸を整理します。詳細な手順や環境変数一覧は Docker Hub の mauriceboe/trek イメージ および 公式リポジトリ README が一次情報です。

起動オプションの選択肢

• 動作確認のみを行う場合: docker run による単発起動が最短
• 本番運用を見据えるが単一ノードで十分な場合: Docker Compose によりリバースプロキシ・バックアップ運用と組み合わせる
• 既に Kubernetes 基盤がある組織: Helm チャートによるデプロイ

公式 README には最短の起動手順として次のコマンドが提示されています。

ENCRYPTION_KEY=$(openssl rand -hex 32) docker run -d -p 3000:3000 \
  -e ENCRYPTION_KEY=$ENCRYPTION_KEY \
  -v ./data:/app/data -v ./uploads:/app/uploads mauriceboe/trek

（出典: mauriceboe/TREK 公式リポジトリ README「Get started in 30 seconds」）

このコマンドで生成される ENCRYPTION_KEY は、ドキュメント等の at-rest 暗号化に使われます。値を失うと過去データが復号できなくなるため、シークレット管理ツールに保存しておく運用が前提になります。

Kubernetes を選ぶ場合、Helm リポジトリを追加してデプロイする経路が README で案内されています。デプロイの詳細な values 定義は README と Helm チャートリポジトリを直接確認してください。

リバースプロキシと WebSocket の注意点

本番運用時は TLS 終端を担うリバースプロキシ（Nginx・Caddy 等）の背後で TREK を運用する構成が基本です。TREK はリアルタイム同期に WebSocket を利用するため、リバースプロキシ側で Upgrade / Connection ヘッダを透過させる設定が必須です。多くのリアルタイム系 OSS 導入時に詰まる論点なので、事前にリバースプロキシの設定サンプル（proxy_read_timeout の延長・WebSocket アップグレード対応）を用意しておくと安全です。

環境変数と初期セットアップ

• ENCRYPTION_KEY: at-rest 暗号化キー（必須。上記コマンドで自動生成）
• ADMIN_EMAIL / ADMIN_PASSWORD: 初回管理者アカウントの seed に使用。未指定時はコンテナログに一時パスワードが出力される
• OIDC・SMTP・通知系（webhook・ntfy）はダッシュボードまたは環境変数で構成可能

初回起動直後は管理者アカウントで OIDC・SMTP・アドオン有効化などの初期設定を進める流れになります。運用フェーズに入ったら、環境変数の変更履歴を Git 管理下に置くと再現性のある構成管理が可能です。

バックアップと更新

• 自動バックアップ（スケジュール・保持期間設定可能）
• 通知先: メール（SMTP）・webhook・ntfy・アプリ内通知センター
• ./data と ./uploads の永続化が必須（Docker Volume でマウント）

ENCRYPTION_KEY を rotate する場合は既存データの再暗号化が必要になるため、鍵ローテーション手順の運用ドキュメントを整備してから運用に載せることが望ましいです。詳細な運用フローや将来的な機能追加のロードマップは、公式が公開している ロードマップ Kanban で参照できます。

類似OSSとの比較

「TREK を選ぶか、別の OSS を選ぶか」を短時間で判断するために、旅行系の自己ホスト OSS を 3 つの軸で比較します。ここでは代表的な類似リポジトリとして AdventureLog・itskovacs/trip・open-wanderer/wanderer を取り上げ、機能範囲・技術スタック・想定用途の観点で棲み分けを整理します。

AdventureLog（seanmorley15/AdventureLog）との比較

AdventureLog は「訪問地の記録（ログ）」を主軸に、旅程計画を追加機能として備える構成です。技術スタックは SvelteKit + Django + PostGIS で、PostgreSQL + PostGIS を必須とします。

• 主眼が「行った場所を記録すること」なので、事後のログ・共有に強い
• リアルタイム同時編集は TREK ほど強化されておらず、複数人で「今」計画を作り込むワークフローは TREK が優位
• MCP による AI 連携・Splitwise 相当の割り勘機能は TREK 独自
• 一方、PostgreSQL + PostGIS のスキーマ設計に慣れている組織にとっては、AdventureLog のバックエンド構成の方が拡張しやすい

「旅行の思い出をきちんと残したい」用途では AdventureLog、「複数人で計画をリアルタイムに作り込みたい」用途では TREK、という棲み分けになります。

itskovacs/trip との比較

itskovacs/trip は POI（Point of Interest）マップ管理に特化したミニマリスト志向の OSS です。Python バックエンド + TypeScript フロントエンドで構成されており、シンプルな旅程管理と OIDC 認証が中心です。

• 「シンプルな POI マップだけで十分」という要件には TRIP が適合
• パッキング・予算・旅日記・PWA・MCP 連携は TREK のみ
• 学習コスト・運用コストを最小化したい用途には TRIP、オールインワンで幹事業務まで賄いたい用途には TREK

TRIP は MIT ライセンスであるため、ライセンス面の柔軟性が最優先ならこちらも有力な選択肢です。

open-wanderer/wanderer との比較

Wanderer は GPS トレイル（登山道・ランニングルート）データベースに特化した OSS です。旅行計画というより、Komoot や Strava からのインポートを前提としたトレイル管理ツールに近い位置づけです。

• 用途カテゴリが異なる（旅行 vs アウトドアアクティビティ）
• GPX インポートは両者で共通するが、目的が違うため代替関係にはなりにくい
• 山行・ランニング記録が中心なら Wanderer、複合的な旅行計画なら TREK

選定チェックリスト

上記を踏まえ、実際に採用可否を判断する際は次の観点を順に確認するのが実務的です。

• AGPL-3.0 で提供する形態が組織のポリシーに合致するか（顧客・第三者へのネットワーク提供を伴う場合は特に）
• 想定同時編集人数と SQLite の並列度が釣り合うか
• 必要な機能（旅程・地図・予算・パッキング・旅日記・訪問国・休暇）のうち、自チームで使う機能が過剰・不足していないか
• SSO・Passkeys・at-rest 暗号化を含む認証要件を満たせるか
• MCP による AI 連携を活用する予定があるか（無ければ TRIP など軽量な OSS も有力候補）
• 既存の技術スタック（Node.js / React 系）と親和性があるか

「オールインワン・リアルタイム・AI 連携」を重視するなら TREK、「シンプル・軽量」を重視するなら TRIP、「訪問地の記録が主目的」なら AdventureLog、という切り分けが実務的な判断軸になります。

活用シーンと採用時の注意点

TREK の機能構成から想定される活用シーンと、採用前に確認しておくべき論点をまとめます。読者が「意思決定を先送りにしがちな論点」に先回りする観点で整理しています。

フィットする活用シーン

• グループ旅行の幹事: 複数人での日別プラン編成・予算割り勘・パッキング共有をまとめて回せる
• 社内ハッカソン・研修合宿の運営: 参加者への案内・パッキングリスト共有・費用精算を一元化できる
• 出張履歴管理: 訪問国・出張記録・費用精算・PDF エクスポートを組織で運用
• 訪問国・休暇管理: Atlas・Vacay アドオンにより、個人単位の旅行ログ／休暇プランナーを社内展開
• 個人プロジェクトとしての PoC: Docker 一発で立ち上がるため、自己ホスト OSS の実験としても始めやすい

採用前に確認すべき論点

• ライセンス: AGPL-3.0 のネットワーク帰属条項が組織のサービス形態と両立するか。特に外部提供を伴う場合、法務・セキュリティ観点の確認が必要
• スケール: SQLite ベースの単一ノード運用が前提。大規模化・水平スケールが要件なら別 OSS または自作を検討する
• ローカライズ: README では日本語（JA）を含む 20 言語対応を掲げているが、UI 文言・ドキュメントの網羅性は環境ごとに要確認。社内展開時は文言サンプルを事前確認しておくとよい
• 認証要件: OIDC・Passkeys・2FA・at-rest 暗号化の各要件を組織のセキュリティポリシーと突き合わせる
• MCP 連携: OAuth 2.1 スコープの粒度が組織の AI 利用ポリシーに合致するか。特に外部 LLM から旅程データを操作させる場合はスコープ設計を先に検討する

これらの論点は README・公式サイト・Discord コミュニティ で公開されている情報を組み合わせて確認できます。運用開始前に一次情報でクロスチェックすることをおすすめします。

まとめ

TREK は、地図・予算・AI・リアルタイム協働編集を一つのサーバーで完結させたいエンジニアに向けた、自己ホスト型のオールインワン旅行計画 OSS です。TypeScript／NestJS／React 19／SQLite というモダンな技術スタックで構築され、PWA・MCP・SSO・Passkeys といった新しめの要素まで初期段階から備えています。スター数 8,960・フォーク 741 という指標と、archived=false / fork=false という状態は、本家として現役開発が続いていることを裏付けています。

一方、AGPL-3.0 のネットワーク帰属条項や SQLite の書き込み並列度は、組織で採用する前に必ず突き合わせておきたい論点です。「オールインワン・リアルタイム・AI 連携」の三点セットを重視する場合は TREK が有力候補になりますが、シンプルな POI 管理で十分なら TRIP、訪問地ログ主体なら AdventureLog といった選択肢もあります。

まずは公式リポジトリの mauriceboe/TREK と 公式サイト liketrek.com で機能を眺め、必要に応じて Docker Hub の mauriceboe/trek イメージ を使った PoC で自チームのユースケースに合うかを検証する、という順で意思決定に進むとスムーズです。