TREKとは｜セルフホスト型の旅行プランナーOSS｜MCPサーバー内蔵でAIが旅程を組む

旅行の計画は、いつも道具が散らばる。行き先の候補は Google マップの保存リスト、宿と航空券の予約確認は受信トレイの奥、割り勘は Splitwise、持ち物は紙かスプレッドシート、そして当日の変更はグループLINEに流れて消えていく。「旅程の一次情報が、どこにあるのか誰も分からない」——これは多くの人が一度は経験する、旅行計画の構造的な問題だ。

TREK は、その散らばりを一枚に畳み込む セルフホスト型の旅行プランナーOSS だ。地図・予算・パッキングリスト・旅日記、そして AI連携（MCPサーバー） までを1つのアプリに統合し、Dockerコンテナ1つで自分のサーバーに立てられる。TypeScript製・AGPL v3で公開され、2026年3月の公開から数か月でGitHubスターは9,000を超えた（2026-07-06時点で9,209）。本記事では、TREKが結局何ができて、何を解決し、何を代替できるのかを、公式リポジトリとドキュメントを一次ソースに整理する。

TREKのMCPサーバーは、単なる「AIおまけ機能」ではなく、OAuth 2.1のフルフローを備えた読めるお手本でもある。MCPサーバーを設計・構築する観点で本記事を読むなら、まず土台として MCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアル を押さえておくと、TREKの実装がどの設計判断に当たるのかが見えてくる。

TREKとは — セルフホスト型の旅行プランナーOSSが解決する「散らばり」問題

TREKの自己紹介は、READMEの一文に凝縮されている。まずは公式の言葉を引く。

地図・予算・パッキングリスト・旅日記、そしてAIを内蔵した、セルフホスト型のリアルタイム共同旅行プランナー。
原文：“A self-hosted, real-time collaborative travel planner — with maps, budgets, packing lists, a journal, and AI built in.”（mauriceboe/TREK README）

キーワードは3つある。セルフホスト（データを自分のサーバーに置く）、リアルタイム共同編集（複数人が同時に旅程を編集し、WebSocketで即座に同期する）、そして旅行に必要な機能を全部入りにしていること。TripItやWanderlogのようなSaaSに旅程を預けるのではなく、Dockerコンテナ1つを自分で立て、その中に旅の一次情報をすべて集約する——これがTREKの立ち位置だ。

当サイトの読者が最初に知りたいのは「このOSSは結局何ができて、何を解決するのか」だろう。TREKの答えは明快だ。旅行計画で発生する「情報の断片化」を、1つのアプリに統合して解く。行き先の候補（場所）、その並び替え（日程）、移動（ルート最適化）、泊まる・乗る・食べる（予約）、いくらかかったか（費用の割り勘）、何を持っていくか（パッキング）、そして旅の記録（旅日記）——旅の前・中・後のすべてのフェーズを、1つのデータベースの中で完結させる。

技術的な前提として、TREKは「SaaSの代替」ではなく「セルフホストOSSの選択」であることは強調しておきたい。開くだけで使える手軽さの代わりに、自分でホスティングする運用コストを引き受けることで、データ主権（旅程・位置情報・費用という極めてプライベートなデータを外部に渡さない）を得る。これは、同じ思想を持つ他のセルフホストOSS（家計簿・写真・ドキュメント管理など）と同じトレードオフの上に立っている。

TREKで何ができるか — 計画・費用・パッキング・旅日記の主要機能

TREKの機能は多いが、READMEでは6つのグループに整理されている。ここでは読者の「何ができる」に直接効く順で、実際の画面とともに主要機能を見ていく。

まず旅程づくりの中心が、ドラッグ&ドロップの日程プランナーとインタラクティブな地図だ（冒頭のファーストビュー画像がこの画面である）。場所を検索して（Google Places または APIキー不要のOpenStreetMap）、日ごとに並べ替え、地図上でルートを可視化する。ルート最適化で自動並べ替えし、そのままGoogle マップへエクスポートもできる。地図はLeaflet／Mapbox GLで、3D建物・地形・写真マーカー・クラスタリングに対応する。場所は共有されたGoogle マップ／Naver マップのリストや、GPX・KML・KMZ・GeoJSONのファイルからインポートできる。

次に、旅のお金を担うのが Costs アドオンだ。Splitwise方式で費用を記録・分割し、1人あたり・1日あたりの内訳、精算（誰が誰にいくら払えば清算されるか）、多通貨に対応する。旅行の割り勘専用アプリを別に使わなくてよくなる、実利の大きい機能だ。

予約管理では、航空券・宿・レストランをステータスや確認番号・添付ファイル付きで管理する。特筆すべきは、予約確認メールやPDFから予約情報を読み込む機能で、これはKDE Itineraryを利用している。パッキングリストはカテゴリ・テンプレート・担当者割り当て・進捗トラッキングに対応し、任意でバッグの重量トラッキング（iOS風の分布表示）もできる。ドキュメントマネージャは旅程・場所・予約にファイル（各50MBまで）を添付でき、旅程全体をカバーページ付きのPDFにエクスポートできる。

そして旅のあとを彩るのが Journey（旅日記）だ。雑誌風のレイアウトで、エントリ・写真（Immich／Synology連携）・地図・気分を記録する。訪問国を世界地図に塗る Atlas、100か国以上の祝日を持つ個人の休暇プランナー Vacay など、旅の周辺までアドオンでカバーする。

これらの機能の多くはアドオンとして実装され、管理者が有効・無効を切り替えられる。必要な機能だけを載せて軽く保てるということだ。共同編集はWebSocketでリアルタイムに同期し、招待リンク（使い切り／再利用可・期限付き）、ロールベースのアクセス、グループチャット・共有メモ・投票・当日のチェックインといった Collab スイートも揃う。

アーキテクチャと30秒セットアップ — TypeScript製をDockerで自前運用

TREKは一枚岩のようでいて、フロントエンドとバックエンドが明確に分かれた構成だ。まずは全体像を図で押さえる。

技術スタックはモダンなTypeScript一色だ。バックエンドはNestJS 11、状態はZustand、リアルタイム同期は素のws（WebSocket）、認証はJWT＋OAuth 2.1＋OIDC＋WebAuthn（Passkeys）＋TOTP。データストアはSQLiteで、data/とuploads/という2つのボリュームに収まる。外部依存を最小化する設計で、天気はOpen-Meteo（APIキー不要）、地図はOpenStreetMap（キー不要）で始められる。

セットアップは驚くほど短い。公式の「30秒で起動」は、暗号化キーを生成してコンテナを立てる一行だ。

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

http://localhost:3000を開けば動く。初回起動時にadminアカウントが作られ、ADMIN_EMAIL／ADMIN_PASSWORDを渡さなければ資格情報がコンテナログ（docker logs trek）に出力される。本番運用では、read-only・no-new-privileges・cap_drop: ALLなどを盛り込んだDocker Compose例が公式に用意されている。TLS終端のリバースプロキシ（Nginx／Caddy、WebSocket対応が必要）の背後に置く前提だ。

services:
  app:
    image: mauriceboe/trek:latest
    read_only: true
    security_opt: [ "no-new-privileges:true" ]
    cap_drop: [ "ALL" ]
    ports: [ "3000:3000" ]
    environment:
      - ENCRYPTION_KEY=${ENCRYPTION_KEY:-}   # openssl rand -hex 32
      - APP_URL=${APP_URL:-}                 # OIDC・メール・MCP発見に必須
    volumes:
      - ./data:/app/data
      - ./uploads:/app/uploads
    restart: unless-stopped

Kubernetesを使うなら、Helmチャート（helm repo add trek https://mauriceboe.github.io/TREK）も提供される。iOS／AndroidではブラウザからPWAとしてインストールでき、Service Workerがタイル・API・アップロードをキャッシュしてオフラインでも動く。「自分のサーバーに立てた旅行アプリを、ホーム画面のネイティブアプリのように使う」——セルフホストOSSとしての完成度は高い。

MCPサーバー内蔵という最大の差別化 — AIが旅程を組む

ここからが、当サイトがTREKを取り上げる理由の核心だ。TREKは Model Context Protocol（MCP） のサーバーを組み込みで持つ。これにより、Claude DesktopやCursorのようなMCP対応のAIアシスタントから、旅行データを構造化API経由で読み書きさせられる。公式ドキュメントの説明を引く。

TREKは組み込みのModel Context Protocol（MCP）サーバーを含み、Claude Desktop・Cursor・その他MCP対応クライアントといったAIアシスタントが、構造化APIを通じてあなたの旅行データを読み書きできるようにする。
原文：“TREK includes a built-in Model Context Protocol (MCP) server that lets AI assistants — such as Claude Desktop, Cursor, or any MCP-compatible client — read and modify your trip data through a structured API.”（TREK MCP.md）

規模も本格的だ。150以上のツールと30のリソースを公開し、AIに「旅程を作る・日程を組む・パッキングリストを作る・予算を管理する・訪問国をマークする」といった操作をフルに任せられる。trip-summary／packing-list／budget-overviewという定型プロンプトも同梱され、Atlas・Collab・Vacayといったアドオンが有効なら、それらのツールも自動で露出する（addon-aware）。「AIに旅程を丸ごと組ませる」という、少し未来的な体験が現実に動く。

MCP対応クライアントとの接続は、mcp-remoteを挟むだけだ。Claude Desktopの設定はこうなる。

{
  "mcpServers": {
    "trek": {
      "command": "npx",
      "args": ["mcp-remote", "https://your-trek-instance.com/mcp"]
    }
  }
}

MCPが「なぜOSSにとって重要な差別化なのか」は、当サイトでも繰り返し扱ってきた論点だ。アプリがMCPサーバーを持つということは、そのアプリの機能が、人間のUIだけでなくAIのインターフェースにも開かれることを意味する。この「MCPをアプリの正しいインターフェースとして据える」思想は、「MCP is all you need」Pydantic作者が語るMCPの正しい使い方とsampling完全解説 で論じられているとおりだ。TREKは、旅行という具体的なドメインでその思想を実装した好例といえる。

同じ「自然言語で自分のアプリを操作させる」発想は、旅行以外のドメインにも広がっている。たとえばワークフロー自動化の領域では、n8n MCP｜Claude Codeから自然言語でn8nワークフローを構築するMCPサーバー が、n8nのノードをAIに組ませる。TREKのMCPは、その「旅行版」だと捉えると位置づけが分かりやすい。

MCPのOAuth 2.1とスコープ設計 — 本番級の権限モデルを読む

TREKのMCPが技術的に注目に値するのは、認証をきちんとやっているからだ。世の多くのMCPサーバーがローカル前提の静的トークンで済ませるのに対し、TREKは外部公開を想定したOAuth 2.1のフルフローを実装している。ここは、MCPサーバーを本番運用したい開発者にとって、そのまま設計の教材になる。

OAuth 2.1を選んだクライアントは、次の流れでトークン管理不要で繋がる。クライアントが/.well-known/oauth-protected-resource（RFC 9728）で認可サーバーを発見し、/.well-known/oauth-authorization-serverでメタデータを取得、動的クライアント登録（DCR／RFC 7591）で自分自身を登録する。するとブラウザにTREKの同意画面が開き、ユーザーがスコープ（権限）を選んで許可すると、/mcpエンドポイントにオーディエンス束縛（RFC 8707）された短命アクセストークンとローテーションするリフレッシュトークンが渡される。

認証方式は3種類あり、外部クライアントにはOAuth 2.1が推奨される。静的APIトークン（trek_接頭辞・全権・無期限）は非推奨で、将来のバージョンで廃止予定だ。使うとAIクライアント側に非推奨警告が出る。下表は公式ドキュメントの認証方式マトリクスを日本語化したものだ。

スコープはtrips:read／trips:write／budget:writeのようにリソース×操作で切られ、13の権限グループ（Trips／Places／Atlas／Packing／Budget／Reservations／Collaboration／…）にまたがる27種が定義されている。:writeは同一グループの:readを含意する（例：budget:writeは予算の読み取りも許可）。AIに与える権限を「旅程は書き換えていいが削除は不可、予算は読み取りだけ」といった粒度で絞れるわけだ。

この「MCPを外部公開する際の認証・スコープ・監査」という論点は、Anthropic自身が本番設計の原則として整理している。Model Context Protocolで本番エージェントを構築｜Anthropic公式の設計原則と認証・最適化パターン と読み比べると、TREKの実装がその原則をどう具体化しているかが見えてくる。「動くお手本」と「設計原則」を突き合わせるのが、MCPサーバーを自作するときの一番の近道だ。

TREKは何を代替できるか — TripIt/Wanderlog/Splitwise比較

読者の3つ目の問い「何を代替できるのか」に答える。TREKのGitHubトピックにはtripit・wanderlog・wanderlustが並び、開発者自身がこれらSaaSの対抗として位置づけていることが分かる。機能面では、旅程管理・地図保存・割り勘・パッキングを1つに束ねるので、複数のアプリを置き換えうる。ただし「セルフホストである」という一点が、あらゆる比較の前提を変える。

表を一言でまとめれば、TREKは「TripItの旅程＋Splitwiseの割り勘＋Google マップの保存リスト＋パッキングアプリ」を1つに束ね、それを自分のサーバーで動かし、さらにAIから操作できるようにしたものだ。特にAI連携（MCP）は、既存の旅程SaaSが一般に提供していない差別化点で、「AIに旅程を組ませたい」というニーズにはTREKが現状ほぼ唯一の選択肢になる。

一方で、割り勘の専用アプリとしての深さ（Splitwiseの通知・リマインド・アプリ体験）や、旅程SaaSの自動取り込み網の広さでは、専業サービスに一日の長がある場面もある。TREKは「1つに束ねる」ことと「自分で持つ」ことに価値を置くツールであり、それが刺さるかどうかは、あなたがデータ主権と統合をどれだけ重視するかで決まる。

導入前の注意点 — AGPL・地図APIキー・セルフホスト運用

最後に、導入前に知っておくべき現実的な注意点を挙げる。誇張なく、公式情報から読み取れる範囲でまとめる。

まずライセンス。TREKはAGPL v3だ。個人・家族での自己ホスト利用なら通常は気にならないが、改変版をネットワーク越しにサービス提供する場合、改変ソースの公開義務が生じる。商用でSaaS的に再提供したい場合は、AGPLの条項を必ず確認すること。

次に外部依存とキー。天気（Open-Meteo）と地図（OpenStreetMap）はAPIキー不要で始められるが、Google Placesの写真・評価・営業時間や、Mapbox GLの高度な地図表現を使うにはそれぞれのAPIキーが要る。OIDCによるSSOやメール通知（SMTP）を使うにはAPP_URLをはじめとする環境変数の設定が必要で、MCPのOAuth自動発見にも公開URLとしてのAPP_URL設定が前提になる。

TREKは20言語（日本語・韓国語・アラビア語RTLを含む）に対応し、管理パネルからユーザー・招待・バックアップ・APIキーを一元管理できる。SaaSに慣れた人には運用の手間が増えて見えるかもしれないが、その手間こそが「自分の旅のデータを、自分のサーバーに置く」という選択の対価だ。手軽さを取るならSaaS、主権と統合とAI連携を取るならTREK——この軸で選べば判断を誤らない。

まとめ — TREKはAI時代のセルフホストOSSの好例

TREKは、旅行計画の「散らばり」を1つのセルフホスト・アプリに畳み込む旅行プランナーOSSだ。地図・予算・パッキング・旅日記を統合し、TripItやSplitwise、Google マップの保存リストを1つで代替する。TypeScript／NestJS／React／SQLiteという素直なスタックで、Dockerコンテナ1つから始められる。

だが当サイトがTREKを推す最大の理由は、そのMCPサーバーにある。OAuth 2.1のフルフロー（RFC 9728／7591／8707）、27種のスコープ、リプレイ検知付きのリフレッシュ・ローテーション——「MCPサーバーを外部公開したいが、認証をどう設計すればいいのか」という実務の問いに、TREKは動くお手本で答える。旅行という具体的なドメインに落ちているぶん、抽象的な仕様書よりも読み解きやすい。

旅の道具としても、MCPサーバー実装の教材としても、TREKは「AI時代のセルフホストOSS」がどう作られるかの1つの回答だ。まずは公式デモ（demo.liketrek.com）で触り、気に入ったらDocker一発で自分のサーバーに立ててみるのがいい。そして開発者なら、/mcpのOAuthフローをぜひ一度、自分のClaudeから叩いてみてほしい。自分のアプリがAIのインターフェースに開かれるという感覚は、一度味わうと戻れない。

関連記事 — MCPをもっと深く

TREKのMCPサーバーを「実装の参考」として読むなら、MCPそのものの理解を深める次の記事が役立つ。

・MCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアル：TREKのMCP実装が、どの設計判断に当たるのかを逆算できる土台
・Model Context Protocolで本番エージェントを構築｜Anthropic公式の設計原則と認証・最適化パターン：TREKのOAuth 2.1・スコープ設計と突き合わせるべき公式原則
・「MCP is all you need」Pydantic作者が語るMCPの正しい使い方とsampling完全解説：「MCPをアプリの正しいインターフェースに据える」思想の背景
・n8n MCP｜Claude Codeから自然言語でn8nワークフローを構築するMCPサーバー：TREKと同じ「自然言語で自分のアプリを操作させる」発想の別ドメイン版

参照ソース

・mauriceboe/TREK（GitHub 公式リポジトリ・AGPL-3.0）
・TREK MCP Integration（公式ドキュメント MCP.md）
・TREK Releases（v3.2.1・GitHub）
・TREK Live Demo（公式デモ）
・Model Context Protocol（MCP 公式サイト）
・RFC 7591 — OAuth 2.0 Dynamic Client Registration Protocol
・RFC 8707 — Resource Indicators for OAuth 2.0
・RFC 9728 — OAuth 2.0 Protected Resource Metadata
・KDE Itinerary（予約メール/PDF取り込みの基盤）
・Open-Meteo（APIキー不要の天気API）