kaneoをDocker Composeで動かして見えた、Jira代替の現実

Jira を使いこなせていないのに、やめる踏ん切りもつかない。
そういうチームは意外と多いんじゃないでしょうか。

かといって Notion でタスク管理を始めると、今度は自由すぎてフォーマットが人によってバラバラになる。
気づけば「ツールをどう使うか」を議論する時間のほうが、実際の開発より長くなっていたりします。

そんな痛みに対して、ひとつの答えを出そうとしているのが kaneo です。
GitHub スター数 5,000 超（2026年7月時点）を記録し、TypeScript 製の OSS プロジェクト管理ツールとして注目を集めています。

実際に Docker Compose で立ち上げて触ってみた結果を、一次情報として書きます。
「使えるか使えないか」の二択ではなく、「どういうチームなら kaneo がフィットするか」という判断軸を持ち帰ってもらうのがゴールです。

Jira は重すぎる、Notion は自由すぎる──kaneo という選択肢

kaneo の設計思想は、公式のキャッチコピーに凝縮されています。

「All you need. Nothing you don't.」

これだけ聞くと「どのツールも言いそうなこと」と思うかもしれません。
ただ kaneo の場合、この言葉を実現するために「削ぎ落とす」方向に振り切っているのが特徴です。

Jira が重い理由のひとつは、機能の多さそのものではなく、「使わない機能が視界に入り続ける」ことだと思っています。
エピック・スプリント・ストーリーポイント・カスタムワークフロー・ダッシュボード……それぞれは便利な機能ですが、5人のチームがシンプルなタスク管理をしたいだけなら、ほとんどがノイズになります。
セットアップだけで半日かかり、「ちゃんと使おう」とルールを整備するうちに、ツール管理が目的化していく。
そのパターンを経験したことがある人には、kaneo の潔さは刺さります。

MIT ライセンスで公開されており、フロントエンドは React、バックエンドは Hono（TypeScript）、データベースは PostgreSQL という構成です。
モノレポ構成で管理されていて、コードベースは読みやすく整理されています。
コントリビュートしやすい設計になっているのも、スター数が伸びている理由のひとつかもしれません。

Docker Compose で kaneo を立ち上げる

セットアップには大きく2つの方法があります。
ひとつは drim という CLI を使ったワンクリック起動、もうひとつは Docker Compose を手動で組む方法です。

drim は自動で HTTPS まで面倒を見てくれる手軽さがありますが、構成の細かい制御が難しくなります。
「何が動いているかを把握したい」「既存のインフラに組み込みたい」という場合は、Docker Compose を手動で組むほうが後々の取り回しがいいです。

以下は実際に動かした docker-compose.yml の構成例です。

services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: kaneo
      POSTGRES_PASSWORD: your_password
      POSTGRES_DB: kaneo
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U kaneo"]
      interval: 5s
      timeout: 5s
      retries: 5

  api:
    image: ghcr.io/usekaneo/kaneo-api:latest
    environment:
      DATABASE_URL: postgresql://kaneo:your_password@postgres:5432/kaneo
      JWT_SECRET: your_jwt_secret
      CORS_ORIGIN: http://localhost:5173
    depends_on:
      postgres:
        condition: service_healthy
    ports:
      - "1337:1337"

  web:
    image: ghcr.io/usekaneo/kaneo-web:latest
    environment:
      VITE_API_URL: http://localhost:1337
    ports:
      - "5173:5173"
    depends_on:
      - api

volumes:
  postgres_data:

これで docker compose up -d を叩けば、しばらくして http://localhost:5173 にアクセスできるようになります。
初回起動時はマイグレーションが自動で走るので、少し待つ必要があります。

詰まりやすいポイントが2つあります。

ひとつは DATABASE_URL のホスト名。
Docker Compose のネットワーク内では、PostgreSQL のホスト名はサービス名である postgres になります。
ホスト側から直接 API を動かす場合（ローカル開発で pnpm dev するなど）は localhost に変える必要があります。
これを見落とすと「DB に繋がらない」エラーが出て、原因に気づくまで地味に時間を取られます。

もうひとつは CORS_ORIGIN の設定。
Web サービスのオリジン（デフォルトでは http://localhost:5173）を API 側の CORS_ORIGIN に正確に一致させないと、ブラウザでリクエストがブロックされます。
本番環境に持っていくときは、ここをドメインに合わせて変えるのを忘れずに。

実際に触ってわかった操作感と、正直な機能評価

起動直後の画面は、拍子抜けするほどシンプルです。
プロジェクトを作り、ボードを開いて、タスクを追加する。
その一連の操作が、ほぼ迷わずできます。

Jira で初めてプロジェクトを作ったときの「どのテンプレートを選べばいいんだ」「スクラムとカンバンどっちにすべきか」という選択疲れが、kaneo にはありません。
ボードを開けばカラムがあって、カードを作れる。
それだけです。

タスクへのアサイン・ステータスの変更・説明文の追記といった基本操作は直感的で、チームメンバーへの招待も数ステップで完了します。
UI のレスポンスが速いのも好印象で、Jira でよくある「保存してから画面が更新されるまでの微妙な待ち時間」がほぼありません。

ただ、使い込んでいくと「ないもの」が見えてきます。
現時点で kaneo に存在しない機能を正直に挙げると、こうなります。

スプリント管理：イテレーションを切って速度を計測する機能はない。スクラムで回しているチームには致命的。
ロードマップ・ガントチャート：中長期の計画を可視化する手段がない。エピック単位での進捗管理も現時点では非対応。
外部インテグレーション：GitHub の PR とイシューを紐づける、Slack に通知を飛ばすといった連携機能がない。開発フローに組み込もうとすると手動の橋渡しが必要になる。
カスタムフィールド：タスクに「見積もり時間」「優先度」以外の属性を追加できない。チーム固有のメタデータを持ちたい場合は詰まる。
通知機能：アサインされたタスクが変更されても、ツール内外への通知がない。チームが大きくなるほど「気づかない」問題が出てくる。

これらの欠如が実務でどう響くかは、チームの使い方次第です。
「タスクの存在と担当者と状態を全員が把握できればいい」という段階なら、上記のどれも今すぐ必要ではないかもしれません。
一方で、スプリントレビューをやっていたり、ステークホルダーにロードマップを見せる必要があるチームには、現時点の kaneo は力不足です。

セルフホストの現実：データ主権を得る代わりに払うコスト

SaaS のプロジェクト管理ツールを避けたい理由として「データを外に出したくない」「ユーザー数が増えると費用が跳ね上がる」という声をよく聞きます。
kaneo のセルフホストは、その両方に対する答えになります。
MIT ライセンスなのでライセンス費用はゼロ、データは自分たちのサーバーに置けます。

アップデートの手軽さも特筆に値します。
マイグレーションは API 起動時に自動実行される設計になっているため、バージョンアップはイメージを pull して再起動するだけで済みます。

docker compose pull
docker compose up -d

マイグレーションスクリプトを手動で当てる必要がなく、運用負荷はかなり低いと感じました。

ただし、手軽さに油断してはいけない部分があります。
それが PostgreSQL のバックアップです。

SaaS であれば、ベンダーがバックアップを取ってくれています。
セルフホストでは、それが丸ごと自分たちの責任になります。
定期的に pg_dump を実行してバックアップを取る仕組みを、最初から組み込んでおくべきです。

docker exec kaneo-postgres-1 \
  pg_dump -U kaneo kaneo \
  > backup_$(date +%Y%m%d_%H%M%S).sql

これをそのまま cron に仕込んでおくだけでも、最低限の保険になります。
バックアップ先を S3 互換のオブジェクトストレージにするなど、もう一段の対策を入れるとより安心です。

実コストの感覚としては、VPS 代が月数百円〜数千円程度（スペックによる）、そこに定期的なアップデート確認や障害対応の工数が乗ります。
「ライセンス費用がゼロ」は事実ですが、「無料で運用できる」とは少し違います。
その工数を払える体制があるかどうかが、セルフホストを選ぶ前提条件です。

SaaS を避けたい理由が「なんとなくコストが高そう」という漠然とした感覚だけなら、正直なところ Linear の無料プランや GitHub Issues で十分なケースも多いです。
「データを自分たちで管理する必然性がある」という明確な理由があってはじめて、セルフホストの運用コストが正当化されます。

kaneo が「ちょうどいい」チームと、そうでないチーム

ここまで触ってきた実感をもとに、フィットするチームとそうでないチームを整理します。

kaneo が向いているチーム：

5〜15人程度の小規模チームで、スプリント管理よりもシンプルなタスクの見える化が優先事項
Jira を導入したものの設定・管理コストに疲弊していて、「もっと軽いものに乗り換えたい」と感じている
データをセルフホストしたい明確な理由があり、PostgreSQL の運用・バックアップを自分たちで回せる

kaneo が向いていないチーム：

スクラムでスプリントを回していて、バーンダウンチャートや速度計測が必要
GitHub の PR・コミットとイシューを紐づけて開発フローを一元管理したい
非エンジニアのステークホルダーにロードマップや進捗を定期的に共有する必要がある

正直に言うと、「Jira を使いこなせていないが捨てられない」チームへの処方箋として kaneo は悪くない選択肢です。
ただし、それは「Jira の代替として同じことができる」という意味ではありません。
「Jira でやっていたことの半分しかできないが、その半分で十分なチームには十分」という意味です。

ツールを変えることで解決する問題と、ツールを変えても解決しない問題は別物です。
「タスクが散らかっている」「誰が何をやっているかわからない」という課題は、kaneo で解決できます。
「チームのプロセスが整っていない」「優先度の判断基準がない」という課題は、どんなツールを入れても解決しません。

まず試すなら、本番環境に入れる前にローカルで Docker Compose を立ち上げてみるのがいちばん早いです。
30分もあれば動くので、「自分たちのチームに合うかどうか」の感触は掴めるはずです。

株式会社ホコサキは、山口県宇部を拠点に Web 制作・業務システム開発・AI 活用支援・DX 推進に取り組んでいます。
kaneo のようなツール選定や、セルフホスト環境の構築・運用についてご相談があればお気軽にどうぞ。
詳しくはお問い合わせページからご連絡ください。