Kaneo vs Jira：無料は本当に有料を置き換えられるか？

結論から：「無料」と「置き換えられる」は別問題です。Kaneo は MIT オープンソース＋セルフホストで、シート課金を自分たちの運用工数に置き換えます。Jira Cloud は 10 人以下なら永久無料ですが、11 人目で Standard 有料トラックへ押し上げられます。GitHub 中心の iOS / Flutter / AI 小チーム（2〜8 人）が Jira 機能の約 20% しか使っていないなら、Kaneo の方がコスパが良い ことが多い。複雑なワークフロー、監査コンプライアンス、部門横断レポートが必要なら、Jira の完全代替は依然として難しい です。

本記事は「Atlassian の請求を続けるべきか」と悩むテックリード、個人開発者、リモート小チーム向けです。機能対照表で威嚇するのではなく、実際の場面から書きます——Jira を 3 年契約して Workflow エディタを 5 回も開かなかったチームは少なくありません。

データ確認日：2026 年 8 月 5 日。Kaneo バージョン参考 v2.9.x。Jira Free プラン制限は Atlassian 公式ドキュメントに基づく。

1. なぜまた「Jira 無料代替」が話題になるのか

2024 年末にオープンソース化された Kaneo は GitHub で jira-alternative や linear-alternative タグとともに注目を集めました。UI がすっきり、セルフホスト可能、人数課金なし——一方 Jira の Free プランも 10 人以下向けに存在し続けています。「Jira はもともと無料」と誤解する人も多いですが、Automation 回数・ストレージ・権限には明確な上限があります。

本質的な問いは「どちらが安いか」ではなく、プロジェクト管理ツールに何を解決させたいか です。よくある誤判断は二つ。五人のスタートアップが Jira Premium 級の期待を持ちながら、実際はカードをドラッグして PR をリンクするだけ——。もう一つは Kaneo を無理にセルフホストし、バックアップとアップグレード担当がいないまま PostgreSQL ディスク満杯で Sprint が止まるパターンです。

VPSSpark の読者のなかには、GitHub・クラウド Mac ビルド枠・場合によって Confluence には既にお金を払いながら、Jira Standard だけがスタンドアップ参加者が増えるたびに膨らむ——そんな請求構成も見ます。「無料代替」検索が増えるのは思想ではなく、使われなくなったツールへのシート課金を止めたいからです。

「軽量コントロールプレーン＋重量実行プレーン」の構成——VPS で Git とプロジェクト管理、クラウド Mac で iOS ビルド——を組むなら、セルフホスト Git とクラウド Mac iOS CI の FAQ も参照してください。コントロールプレーンは削れるところを削り、実行面（Xcode・署名・Archive）は妥協しない、というのが鉄則です。

2. 核心概念：Kaneo と Jira それぞれが何か

2.1 Kaneo：「少ないほど良い」ためのセルフホスト看板

Kaneo は MIT ライセンスのオープンソース PM ツールで、React フロント＋Hono API＋PostgreSQL 構成です。公式ドキュメント によると、リスト／看板ビュー、ラベルと優先度、期限と担当者割当、そして ネイティブ GitHub Issue 同期 を提供します。毎日 GitHub にいる開発チームにとって、これが最大の差別化です。

導入は drim CLI のワンクリックか Docker Compose の手動セットアップ。シート課金はなく、コストは VPS・DB バックアップ・投入できる運用時間です。2026 年上半年も MCP や OAuth など AI ワークフロー向け拡張が続き、静的看板だけでなく開発ツールチェーン側へ寄せている兆候があります。

Kaneo が意図的に薄い領域：内蔵 OKR、ITIL サービスカタログ、3,000 プラグインのマーケットプレイス。バックログが GitHub、リリースノートが README にあるチームにはメリット。ステータス遷移ごとに不変監査ログが法務要件なら、スクリーンショット比較の前に自分がどちらの陣営か正直に見極めてください。

2.2 Jira Cloud：ワークフローエンジン＋ Atlassian エコシステム

Jira は Atlassian のエンタープライズ Issue・プロジェクト基盤です。強みは プログラム可能なワークフロー（状態機械、条件付き遷移、ポスト関数）、Confluence・Bitbucket・Jira Service Management とのバンドル、大規模組織向け権限・監査ログ・コンプライアンス認証。Free は 10 ユーザー、2 GB、月 100 Automation——アジャイル試行には足り、本番ペースには足りないことが多いです。

Atlassian 公式プラン説明 では、Free に高度権限と監査ログは含まれません。10 人超で Standard トライアルが自動開始、人数を減らさなければ有料 Standard へ。Standard はシート課金で 2026 年の年払い参考 $8.15/人/月——5 人でも年 $480 超、Confluence 追加前です。

3. 実践：それぞれ最小構成で動かす

3.1 Kaneo クイックセルフホスト（drim 経路）

テスト VPS（2 vCPU / 4 GB RAM）で公式ワンクリックスクリプトを実行し、PostgreSQL イメージ取得込みで約 15 分で通しました：

curl -fsSL https://assets.kaneo.app/install.sh | sh
drim setup
# ドメイン、PostgreSQL パスワード、管理者アカウントを入力
# 完了後 https://pm.yourdomain.com にアクセス

初回フロー：Workspace 作成 → Project → Issue インポートまたは手動作成 → 看板ビューへ切替。GitHub を OAuth で接続後、対象リポジトリの双方向 Issue 同期を有効化。カスタムフィールドの膨張は意図的に避けました——Kaneo の哲学は Jira 式フィールド肥大化への抵抗 です。Linear や GitHub Projects に慣れた開発者なら 30 分以内に使い始められることが多いです。

3.2 Jira Cloud Free 開設と境界の触り方

Jira 側は単純：Atlassian 登録 → Cloud サイト作成 → Free 選択 → メンバー招待（≤10）。Scrum または Kanban プロジェクトを作ればデフォルトワークフローでドラッグ可能。時間を食うのは 過剰設定——カスタム Issue タイプ、大量 Screen、Automation ルール。多くのチームが「Jira 管理者」副業に陥ります。

Free プランでは三つの境界を意図的に試してください：① 10 人目と 11 人目招待時のシステムメッセージ；② 当月 101 回目の Automation が制限されるか；③ 添付合計が 2 GB に近づいたときのアップロード挙動。機能リストより、いつ有料へ押し上げられるかを知る方が実務的です。

4. Cloud Mac / Apple Silicon との連携シーン

VPSSpark 読者には iOS・Flutter・AI Agent 開発者が多く、PM ツール自体は Xcode を動かしません。しかし ビルド失敗、リリースブロック、証明書期限切れ が素早く見え、担当が付き、クローズできるかは PM 基盤次第です。典型的な三層は次のとおり：

• 計画面（Kaneo または Jira）：Sprint 計画、Bug 優先度、バージョンマイルストーン。
• コード面（GitHub）：PR、Review、Issue 番号とコミットメッセージの紐付け。
• 実行面（クラウド Mac / Apple Silicon）：Xcode Archive、TestFlight アップロード、Flutter iOS ビルド、夜間 CI 回帰。

リモートチームでは実行面を VPSSpark クラウド Mac mini M4 に置く利点が見落とされがちです。ビルドログ、署名エラー、xcodebuild 終了コードを Webhook で Kaneo タスク説明や Jira Comment に書き戻せば、当番メンバーが VNC でターミナルを漁る必要が減ります。Apple Silicon ユニファイドメモリは大規模 Swift リンクで同価格 x86 VPS より安定し、M4 待機約 4W は 7×24 ビルドノードに向きます。

Windows でドキュメント・コミュニケーション、Mac でビルドという分担なら、Mac と Windows の全方位比較 も参考に。PM ツールはブラウザからどの OS でも触れるべきですが、iOS ビルド実行面は macOS に残す——「コントロールプレーンはセルフホスト可、実行面はクラウド Mac」というレイヤー分けの理由です。

5. コスト・性能・リスク：表だけでは足りない

5.1 リスク：無料構成で実際に噛みつく部分

Kaneo 側： DB バックアップが VPS スナップショットだけで异地副本がなければ、Project 誤削除は復旧不能かもしれない。バージョンアップは Changelog を追う必要があり、セルフホストは自動で最新に漂わない。唯一の運用担当が退職しドキュメントがなければ「ログインはできるが触れない」僵死状態に。

Jira 側： Free の Automation クォータは忙しい Sprint で突然頭打ち。10 人上限は「インターンを 1 人追加」にも厳しい。Atlassian エコシステムに長期依存すると移行コストが巨大——Issue 履歴、カスタムフィールド、プラグインデータを OSS へきれいに持ち出すのは困難です。

6. よくある質問（FAQ）

Kaneo は Jira を完全に置き換えられるか？

一概にはいえません。「誰が何をいつまでにやるか、GitHub PR と結びついているか」が核心なら Kaneo で足ります。SOX 監査、複雑な承認チェーン、ポートフォリオ管理、Service Desk 連動が必要なら Jira がデフォルト答案のままです。正直な基準：Jira 管理画面を開き、過去 90 日で実際に変更した Workflow ルールの数——ゼロなら、使っていない能力に課金している可能性が高いです。

Jira 無料版で足りるか？

≤10 人のプロダクト検証段階なら足ります。三つのトリガーに注意：人数、Automation 回数、ストレージ。どれか一つが天井に当たったら「要件を下げる」か「Standard に上げる」か——中間はありません。

Jira から Kaneo への移行は難しいか？

タイトルと説明は CSV で出して入れられますが、カスタムフィールド、Workflow 履歴、プラグインデータはほぼ無損失移行不可。現実的な道は 新 Sprint を Kaneo で開始 し、旧 Jira は読み取り専用アーカイブ、移行期は GitHub Issue を単一番号源にすることです。リリース直前の週ではなく、静かな週に移行を。新 Jira フィールド追加凍結を宣言し、エクスポート集合を安定させてください。

併用はできるか？

可能です。対外コンプライアンスは Jira、内部イテレーションは Kaneo、GitHub を真実源として双方向同期——ただし衝突時にどちらが正か文書化してください。ステータスを二重管理する方が、ツール代の二重払いよりつらいです。

7. まとめ：無料は有料を置き換えられるか？

タイトルに戻ると：無料が有料を置き換えるのは、本当に「無料の能力スライス」だけが必要なときに限る 。Kaneo はシート代を運用責任と交換し、Jira Free は請求を機能上限と将来のアップグレード圧力と交換します。VPSSpark 読者に多い iOS / Flutter / AI 小チーム向けの提案：

• ≤8 人・GitHub 中心・硬性コンプライアンスなし → まず Kaneo を試す。浮いたシート代をクラウド Mac ビルドノードへ。
• 10 人に近く Automation や監査が重い → Jira に留まる が、使わない Premium 幻想は捨てる。
• 迷ったら → 2 週間並行パイロット。「Issue をクローズするまでの手数」と「ビルド失敗が自動コメントされるか」で測る——機能表より説得力がある。

PM ツールは目立たない存在であるべき——コードより頭を使うべきではありません。Kaneo でも Jira でも、実行面は安定したネイティブ macOS に置き、Archive と TestFlight アップロードが Sprint 終盤のロシアンルーレットにならないようにしましょう。