セルフホストの旅程管理ツールTREKを社内出張に使えるか検証した

出張の行程管理って、最初は「Notionでいいじゃないか」で始まるんですよね。
テンプレートを作って、メンバーに共有して、最初の1〜2回はうまく回る。
でもそれが月に何度も、人数が増えてくると、じわじわ崩壊していきます。

セルフホスト型の旅程管理ツール TREK（mauriceboe/TREK） を「社内ツールとして本番運用に耐えるか」という目線で検証しました。
機能紹介よりも、デプロイの現実・SSO連携の難所・運用コストの見積もりに重心を置いています。

Notionとスプレッドシートで出張管理が静かに崩壊していく話

よくあるパターンはこうです。
スプレッドシートで旅程を作ると、複数人が同時に編集したときにセルが競合する。
Notionはブロック単位の編集なのでまだマシに見えますが、同じブロックを触ると衝突が起きて、どちらかの変更が消える。

それだけなら「気をつければいい」で済むかもしれません。
本当に厄介なのは、情報が散逸していくことです。

「新幹線の時刻はSlackで共有した」「ホテルの予約確認メールはメールのまま」「集合場所はNotionに書いたけどどのページだっけ」——こういう状態、心当たりありませんか。
旅程の本体はNotionにあるのに、関連情報がSlack・メール・Googleドライブに分散して、結局「直前にSlackで確認する」という運用になる。

地味に痛いのが権限管理の粗さです。
Notionはページ単位でしか権限を制御できないので、「この出張の予算情報は経理担当だけ見られるようにしたい」みたいな細かい制御が難しい。
スプレッドシートも似たようなもので、シート単位の保護はできても、行・列レベルの制御は運用でカバーするしかない。

「出張管理専用ツールを入れるほどでもないよな」という判断が積み重なって、結局ずっとNotionのまま。
ただ、その「ほどでもない」が積み重なると、いつの間にか「誰かが毎回Notionを整理する係になっている」という状態になっていたりします。
そういう背景があって、セルフホスト型の旅程管理ツールとして TREK が気になりました。

TREKの機能を「社内出張ユースケース」で読み解く

2026年4月時点の情報として、TREKはリリースから5週間で4,400超のスターを獲得し、v3.0.8まで進んでいます。
バックエンドはNestJS 11、リアルタイム同期はWebSocket、認証はJWT + OAuth 2.1 + OIDC + Passkeys（WebAuthn）+ TOTP MFAという構成です。
AGPL-3.0ライセンスなので、社外に提供しない社内利用であればライセンス上の問題はありません。

機能を 社内出張・現地視察の文脈 で評価すると、こんな仕分けになります。

社内で活きる機能：

• リアルタイムコラボ（WebSocket） — 複数人が同時に行程を編集しても競合しない。Notionで一番困っていた部分がここで解消される
• 予算管理（多通貨対応・人別分割） — 出張精算の前段として、費用の概算を旅程と同じ場所で管理できる
• 予約管理（フライト・ホテル・レストラン） — ファイル添付付きで予約確認書を旅程に紐づけられる。情報散逸の防止に直結する
• パッキングリスト — 現地視察チームで「持ち物チェックリスト」として使うと地味に便利。カテゴリ分けとプログレス追跡がある
• PWA（オフライン対応） — 現地でネットが不安定でも旅程を参照できる
• SSO（OIDC対応） — 社内IdPと連携できれば、アカウント管理の手間がなくなる

社内では使いどころが微妙な機能：

• MCP連携（ClaudeによるAI旅程生成） — 個人旅行では面白いが、社内出張の行程はほぼ決まっているので出番が少ない
• 訪問国アトラス・旅行統計 — 個人の旅行記録向けで、社内用途では不要
• ジャーナル機能 — 出張報告書の下書きには使えなくもないが、専用ツールには劣る

リリースペースが速い分、荒削りな部分も正直あります。
JWTまわりのセキュリティ上の懸念がコミュニティから指摘されており、OIDC設定の一部がUI操作前提で環境変数での完全自動化が未実装という点も社内展開では引っかかります。
「勢いがある」と「本番投入できる」は別の話なので、その温度差は念頭に置いておく必要があります。

Dockerで最小構成を立ち上げる

TREKはDocker Composeで立ち上げるのが基本です。
backendとfrontendが別コンテナで動作し、backendが3000番ポート、frontendは別ポートで配信される構成です。
以下は動作確認のための参考例です。実際に使う際は 必ず公式リポジトリの最新のdocker-compose.ymlを確認してください。

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: trek
      POSTGRES_USER: trek
      POSTGRES_PASSWORD: changeme
    volumes:
      - db_data:/var/lib/postgresql/data

  backend:
    image: ghcr.io/mauriceboe/trek-backend:3.0.8
    restart: unless-stopped
    depends_on:
      - db
    environment:
      DATABASE_URL: postgresql://trek:changeme@db:5432/trek
      ENCRYPTION_KEY: "32バイト以上のランダム文字列をここに"
      ADMIN_EMAIL: admin@example.com
      ADMIN_PASSWORD: "初回起動用の強いパスワード"
      TRUST_PROXY: 1
      FORCE_HTTPS: "true"
    ports:
      - "3000:3000"
    volumes:
      - trek_data:/app/data

  frontend:
    image: ghcr.io/mauriceboe/trek-frontend:3.0.8
    restart: unless-stopped
    depends_on:
      - backend
    ports:
      - "8080:80"

volumes:
  db_data:
  trek_data:

つまずきやすいポイントを先に書いておきます。

ADMIN_EMAIL と ADMIN_PASSWORD は初回起動時のみ有効 です。
どちらか一方でも省略すると、メールアドレスは admin@trek.local、パスワードはランダム生成されてサーバーログに出力されます。
必ずペアで設定してください。一度でもユーザーが存在する状態になると、これらの変数は以後無視されます。

trek_data ボリュームの永続化を忘れると痛い目を見ます。
データディレクトリには暗号化キーや各種設定ファイルが格納されるため、コンテナを再作成したときにボリュームがなければ全部消えます。
db_data（PostgreSQL）と trek_data（アプリデータ）の両方を必ずボリュームマウントしてください。

FORCE_HTTPS と TRUST_PROXY はリバースプロキシ前提の設定 です。
FORCE_HTTPS を true にすると 301 リダイレクト・HSTS・secure Cookie フラグが有効になりますが、TLSを終端するリバースプロキシ（nginxやCaddy）の背後に置く場合のみ使う設定です。
TRUST_PROXY は前段のプロキシ台数を数値で指定するもので、クライアントIPや X-Forwarded-Proto を正しく取得するために必要です。

SSO連携の設定方針と、社内展開で詰まるポイント

KeycloakやAuthentikなど既存のIdPをすでに社内で運用しているなら、OIDCクライアントとして登録するだけで接続できます。
OIDC関連の主要な環境変数はこうなります。

OIDC_ISSUER=https://auth.example.com/realms/your-realm
OIDC_CLIENT_ID=trek
OIDC_CLIENT_SECRET=your-client-secret
OIDC_ONLY=true
OIDC_ADMIN_CLAIM=groups
OIDC_ADMIN_VALUE=trek-admins

OIDC_ONLY を true にすると、パスワードログインと新規登録が無効化されます。
最初のSSOログインが自動的に管理者になる挙動なので、社内展開では管理者用アカウントでSSOログインしてから他のメンバーを招待する流れになります。

OIDC_ADMIN_CLAIM と OIDC_ADMIN_VALUE は、IdPのトークンに含まれるクレームを使って管理者権限を自動付与する設定です。
上の例では groups クレームに trek-admins が含まれているユーザーを管理者として扱います。
Keycloakならロールマッピング、Authentikならグループメンバーシップをクレームとして渡せるので、IdP側の設定と合わせて調整してください。

ここまでは比較的スムーズなのですが、 現時点で一つ制約があります。
OIDC_ISSUER・OIDC_CLIENT_ID・OIDC_CLIENT_SECRETなどの基本的な接続設定は環境変数で行えますが、一部の詳細設定はUIからのクリック操作が必要な状態です。
CI/CDパイプラインで完全にコードベースで管理したい場合、初回セットアップだけUIを触る必要が残ります。
これは Issue #48 として対応待ちになっているので、何がUIでしか設定できないかの詳細はそちらを確認してください。

もう一つ、社内展開で許容判断が必要な問題があります。
JWTまわりのトークン無効化 の件です。
コミュニティ（r/selfhosted）でのコードレビューで「ログアウトエンドポイントが存在せず、JWTは発行から24時間有効でブラックリストの仕組みもない」という指摘が上がっています。
これが現在も未対応かどうかは公式Issueでの確認が必要ですが、導入前に確認しておくべき点です。

出張管理ツールとして扱う情報の機密度が高くなければ、許容範囲と見ることもできます。
一方で、退職者や異動者のアクセスを即時無効化したい要件がある場合は、現時点での対応状況を必ず確認してから判断してください。

本番運用に踏み切る前に見積もっておくこと

セルフホストの最大のメリットはデータを自分のインフラで管理できることですが、それは同時に「面倒ごとも全部自分で持つ」ということです。

永続化とバックアップはまず押さえておく必要があります。
PostgreSQLのデータ（db_data）とアプリデータ（trek_data）の両方を定期的にバックアップする仕組みが必要です。
pg_dump を cron で回すのが最小コストですが、「バックアップを取っているつもりで取れていない」という事故は定期的なリストア確認でしか防げません。

アップデート追従のコストも見ておく必要があります。
TREKはリリースペースが速く、機能追加の恩恵がある一方で、breaking changeへの追従コストでもあります。
ENCRYPTION_KEY の導入時には移行処理が発生しましたが、このケースは自動移行が実装されていて、起動時に ./data/.jwt_secret から ./data/.encryption_key へ自動昇格する仕組みになっています。
とはいえ、すべてのバージョンアップがこれほど親切とは限りません。
イメージタグを latest に固定せず、バージョンを明示的に指定して管理し、アップデート前にCHANGELOGを確認する習慣をつけておくと、breaking changeに踏み抜くリスクを減らせます。

Kubernetes環境への展開はHelmチャートが用意されているので、すでにk8sクラスタを運用しているチームはそちらも選択肢に入ります。

最後に、導入判断の軸を整理しておきます。

導入を検討してよい状況：

• 出張・現地視察が月に複数回あり、複数人が関わる
• 旅程・予約・費用の情報がSlack・メール・Notionに散逸していて、毎回誰かが整理している
• KeycloakやAuthentikなど社内IdPがすでにあり、SSO連携のコストを吸収できる
• セルフホストの運用（バックアップ・アップデート追従）を担当できるエンジニアがいる

見送った方がよい状況：

• 出張が年数回・少人数で、Notionで今のところ回っている
• インフラの運用リソースがなく、SaaSの方がトータルコストが低い
• JWTの即時無効化が必要な要件がある（退職者対応など）
• OIDC設定の完全自動化が必須のCI/CDパイプラインを組んでいる

TREKは「勢いがあって機能的に面白い」と「本番運用に完全に耐える」の間のどこかにいるプロジェクトです。
今の段階で社内ツールとして投入するなら、JWTまわりの問題とOIDC設定の制約を把握した上で、ステージング環境で十分に検証してからにするのが現実的な判断だと思います。
逆に、出張管理の情報散逸に本当に困っていて、運用コストを引き受けられるチームであれば、試してみる価値は十分にあります。

---

株式会社ホコサキは山口県宇部市を拠点に、Web制作・業務システム開発・AI活用・DX推進をやっている会社です。
OSSの評価や社内ツールの選定、セルフホスト環境の構築支援など、こういった技術的な判断を一緒に考えることもやっています。
気になることがあれば お問い合わせ からどうぞ。