Hulyとは｜Linear・Jira・Slack・Notionを1つに束ねる自己ホストOSSワークスペース

チーム開発の裏側には、いつの間にか増えていくSaaSの束がある。課題管理は Linear か Jira、チャットは Slack、ドキュメントは Notion、予定は Motion——それぞれ月額を払い、データはあちこちに散らばる。Huly（hcengineering/platform） は、その散らばりを1つに畳もうとするオープンソースの統合ワークスペースだ。開発元は Hardcore Engineering。GitHubスターは2.6万を超え（2026年7月時点）、公式は自らを「Linear・Jira・Slack・Notion・Motion のオールインワン代替」と位置づけ、TypeScript で書かれたOSSとして活発に開発されている。

まず、Huly が実際にどんな画面なのかを見てほしい。1つのアプリの中に、課題のカンバン・受信箱・プロジェクトが同居している——これが「Everything App（すべてのアプリ）」を名乗る所以だ。文章で機能を並べるより、この1枚を見るほうが「何ができるツールか」は早く伝わるはずだ。

この記事では Huly を、当サイトの3つの問い——①このOSSは結局何ができる／②何を解決する／③何を代替できるのか——に沿って、公式リポジトリ（README・アーキテクチャ資料）をベースに整理する。派手な宣伝ではなく、自己ホストの現実的なコストと、ライセンス・サービス終了という見落としがちな注意点まで踏み込む。

Huly（hcengineering/platform）とは——「すべてのアプリ」を名乗る統合ワークスペース

結論から言えば、Huly は「チームの作業道具を1つのアプリに集約する」プロジェクトだ。

Huly を理解するうえで、まず3つの名前を切り分けておくと混乱しない。

つまり、これから Huly を使う人にとっての実体は「自分のサーバーに立てるOSSの統合ワークスペース」だ。ホスト版に登録して使う道は、間もなく閉じる。「Huly を試す＝huly.io に登録する」と早合点すると行き止まりに当たるので、この記事も最初から最後まで一貫して「自己ホスト前提」で読み進めてほしい。

Huly の思想は明快で、「チームの operations（運営）を1つのワークスペースで回す」ことにある。課題を追い、仲間と話し、ドキュメントを書き、予定を組み、採用や顧客管理まで——本来は別々のSaaSに分かれていた営みを、1つの箱に集める。当サイトで解説した OSSプロジェクト管理ツール Plane が「課題管理に特化したOSS」だとすれば、Huly はその周辺の道具ごと丸ごと束ねにいく、より野心的な立ち位置だ。

なぜ今この発想が刺さるのか。背景には、SaaSの「積み上がり」への疲れがある。チームが成長するほど、課題管理・チャット・ドキュメント・予定・採用と、契約するツールは増えていく。それぞれは便利でも、全体として見ると、月額はユーザー数ぶんだけ膨らみ、データは各サービスのサイロに分断され、「あの議論はSlackだったかNotionだったか」を探す時間が積もる。Huly が突きつけるのは、「そもそも、これらは1つのアプリであってはいけないのか？」という問いだ。開発元の Hardcore Engineering は、この問いに「Everything App（すべてのアプリ）」という答えを掲げ、実際に動くものとして公開している。

もちろん「全部入り」を掲げるツールは過去にもあった。Huly が現実味を持つのは、オープンソースで、自己ホストできるからだ。ベンダーに囲い込まれる代わりに、コードもデータも自分の手の内に置ける。次章から、その「何ができるか」を具体的に見ていく。

3つの疑問——Hulyは何ができ、何を解決し、何を代替するのか

Huly について、当サイトの読者が求める3つの問いに答える。

②が Huly の存在理由の核だ。チームが増えるほどSaaSの請求は積み上がり、データは各サービスのサイロに閉じ込められる。Huly はそれを「自分のインフラに置いた1つのアプリ」に畳むことで、コストとデータ主権の両方を取り戻そうとする。

この発想は、Slackの代替を狙う Mattermost や、SalesforceのOSS代替 Twenty CRM とも同じ系譜にある——違いは、Huly がそれらを個別にではなく、まとめて1つで置き換えにいく点だ。

③の「何を代替するか」は、裏を返せば「Huly に何を期待すべきでないか」も教えてくれる。Huly は Linear や Notion のすべての機能を1対1で完全再現するものではない。各SaaSは自分の領域で長年磨かれており、細部の使い勝手では専用ツールに一日の長がある。Huly の狙いは「各領域で80点を、1つのアプリで、自分のインフラ上に」揃えることだ。だから移行を検討するときは、「今使っている機能のうち、本当に必要なものは Huly でも足りるか」を、自分たちのワークフローで確かめるのが失敗しないコツになる。全部を一度に移すのではなく、まず課題管理やドキュメントといった中核から試すのが現実的だ。

主要モジュール——Tracker・Chat・Documents・仮想オフィスまで一つの箱に

Huly の中身は、用途ごとのモジュール（プラグイン）の集合だ。それぞれが、既存の有名SaaSに対応している。この「プラグインの集合」という作りは、Huly が単なる完成品ではなく拡張可能な土台であることを示している。必要なモジュールを使い、不要なものは前に出さない——チームの使い方に合わせて、ワークスペースの構成を変えられる。

代表的なモジュールを整理する。

とりわけ Huly を特徴づけるのが、仮想オフィス（Love） と 共同編集ドキュメント だ。単なる課題管理ツールではなく、「チームがそこで過ごす場所」を目指しているのが伝わる設計だ。ナレッジ・ドキュメント領域の全体像は、当サイトの ドキュメント/ナレッジ系OSSまとめ も合わせて読むと位置づけが掴める。

仮想オフィス（Love）——リモートチームの「気配」を再現する

love プラグインが提供する仮想オフィスは、Huly が「作業ツール」以上を目指していることの象徴だ。テキストチャットだけでは失われがちな「いま誰がオンラインで、どの部屋にいるか」という気配を、音声・映像のプレゼンスで再現する。物理オフィスの「ちょっと声をかける」に近い体験を、リモートでも成立させようという狙いだ。Slack のスレッドと通話を別々に使うのではなく、チャットと空間を同じアプリの中で連続させる点が、単なる Slack 代替との差になっている。

共同編集ドキュメント——Y.js CRDT が支える同時編集

Huly のドキュメントは、Notion のように書けるだけでなく、複数人が同時に同じページを編集できる。これを支えるのが Y.js の CRDT（Conflict-free Replicated Data Type） だ。CRDT は「複数の編集を、どんな順序で適用しても最終結果が一致する」ように設計されたデータ構造で、ネットワークの遅延や同時編集の競合を、ロックなしで自動的に解決する。collaborator サービスがこれを担い、チームが同じ仕様書やメモをリアルタイムに育てられる。ナレッジがサイロ化せず、課題やプロジェクトと地続きに置ける点が、外部のドキュメントSaaSを併用するのとは違う体験を生む。

採用・品質管理まで——業務アプリの土台としての Huly

Huly は開発チームの道具にとどまらない。採用管理（Recruit/ATS）は履歴書の解析（rekoni サービスが PDF/DOCX から情報を抽出）を備え、人事（HR）や顧客・リード管理（CRM/Lead）も持つ。さらに管理文書・製品・トレーニングといった 品質管理（QMS） 系のモジュールまで用意されている。README が Huly を「CRM のような業務アプリ開発を加速する堅牢なフレームワーク」と表現する通り、Huly は単一の完成品というより、業務アプリを載せる土台でもある。実際、他社（例：TraceX）が Huly Platform の上に独自プロダクトを構築している。

こうした「1つに束ねる」発想を、単機能のOSSと比べると位置づけがはっきりする。

この表が示す通り、Huly の価値は「範囲の広さ」と「データ主権」にある一方、コストは「サーバー運用の重さ」として現れる。次章で、その自己ホストの実際を見ていく。

自分のサーバーで動かす——Huly のセルフホスト

Huly.io のホスト版が終了する以上、これからの使い方は自己ホスト一択だ。幸い、公式は Docker ベースの手軽な導入路（huly-selfhost）を用意している。読者が実際に実行する手順として、公式のコマンドを引く。

まず、セルフホスト用リポジトリを取得してセットアップスクリプトを走らせる。

# huly-selfhost を取得してセットアップ
git clone https://github.com/hcengineering/huly-selfhost.git
cd huly-selfhost
./setup.sh

セットアップが済んだら、nginx の設定を有効化し、Docker Compose で全サービスを立ち上げる。

# nginx 設定を有効化して起動
sudo ln -s $(pwd)/nginx.conf /etc/nginx/sites-enabled/huly.conf
sudo nginx -s reload
sudo docker compose up -d

とにかく素早く試したいだけなら、対話式のクイックスタートも用意されている。

# クイックスタート（1行）
git clone https://github.com/hcengineering/huly-selfhost.git && cd huly-selfhost && ./setup.sh --quick

setup.sh は、公開するホスト名（ドメインやIP）を対話で尋ね、それに合わせて nginx とサービスの設定を生成する。社内やVPN内で使うのか、インターネットに公開するのかで、ここの答えが変わる。本番でインターネットに公開するなら、リバースプロキシでのHTTPS化（TLS証明書の取得）と、ファイアウォールでの必要ポートの制御を、立ち上げと同時に設計しておきたい。Huly はチームの機微なデータ（課題・チャット・顧客情報）を扱うため、「とりあえず全ポート開放で公開」は避けるべきだ。まずは閉じた環境で検証し、公開は設計を固めてから——という順序が安全になる。

なお、ソースコードから自分でビルドする道（この platform リポジトリを Microsoft Rush でビルド）は、コントリビューターや深くカスタマイズしたい開発者向けだ。こちらは rush install → rush build → rush docker:build といった手順を踏み、GitHub のパッケージレジストリ認証（read:packages 権限のトークン）やサブモジュールの初期化も必要になる。ビルドには約35GBのディスクを消費するため、気軽に試す用途には向かない。多くの人にとっては、上記の huly-selfhost（Docker）が現実的な入口になる。

自己ホストで気に留めておきたいのは、「立てたあとの運用」だ。Huly は複数のデータベースやストレージを抱えるため、バックアップの対象が1つではない。業務の中核データを載せるなら、DB（MongoDB もしくは CockroachDB/PostgreSQL）とオブジェクトストレージ（MinIO）の両方を定期的に退避する運用を、最初に設計しておきたい。ホスト版 Huly.io の終了時にも「データをバックアップして移行せよ」と案内されている通り、データを自分で持つということは、その保全も自分の責任になる、ということでもある。

アーキテクチャと技術——30以上のマイクロサービスとCRDT

Huly の「1つのアプリで全部」を支えているのが、思いのほか本格的な分散アーキテクチャだ。ここを知っておくと、必要スペックの理由も腑に落ちる。

Huly は TypeScript で書かれ、UIは Svelte、モノレポは Microsoft Rush で管理される。Svelte はコンパイル時に無駄を削るため、機能の多いアプリでも軽快に動きやすく、Huly のように画面要素が豊富なプロダクトと相性がよい。Rush は多数のパッケージ（Huly は150前後のプラグイン・サービスに分かれる）を1つのリポジトリで束ねて依存関係を統制するための道具で、これだけの規模のモノレポを回すための選択だ。実行時は30以上のマイクロサービスに分かれ、中核の transactor（トランザクションエンジン）が WebSocket 接続を保持して、課題やメッセージの変更を即時に全員へ同期する。ドキュメントの共同編集は、collaborator サービスが Y.js の CRDT で担い、同時編集の衝突を自動で解決する。

技術構成から読み取れるのは、Huly が「趣味の全部入り」ではなく、本番のチーム運用に耐えることを最初から狙って設計されているという点だ。即時同期・全文検索・スケーラブルなデータストア・イベント駆動——これらは、少人数のメモアプリには要らないが、数十〜数百人が同時に使う業務基盤には欠かせない要素だ。裏を返せば、この本格志向こそが自己ホストの重さの正体でもある。

下の図は、主要サービスとデータ層の関係を単純化したものだ。

データ層について、ひとつ補足しておく。従来の Huly は主データベースに MongoDB を使っていたが、現在は CockroachDB（分散SQL）や PostgreSQL への移行が進んでいる。あわせて全文検索に Elasticsearch、ファイル・添付の保管に S3互換の MinIO、サービス間のイベント配信に Redpanda（Kafka互換）、キャッシュに Redis を使う。この構成の厚みこそが、Huly が「軽量アプリ」ではなく「自分で運用するプラットフォーム」である理由だ。

もう少し噛み砕くと、それぞれの部品には役割分担がある。認証を受け持つ account がログインと権限（JWT）を管理し、front がWebサーバとして画面を配信する。実際のデータ操作の心臓部が transactor で、ここが WebSocket 接続を保持し続けることで、誰かが課題を動かした瞬間に、他のメンバーの画面へ変更が流れ込む——この「即時性」が、Huly を単なるフォーム入力ツールと分ける。全文検索の fulltext は Elasticsearch を、ファイル配信は MinIO を裏で使い、rekoni は PDF や履歴書からテキストを抽出する。30以上という数字は多く見えるが、要は「リアルタイム同期・検索・保管・解析」という役割を、それぞれ独立したサービスに分けているということだ。

この分散構成は、SaaSを1つに束ねるという目標の裏返しでもある。1つのアプリで課題もチャットもドキュメントも扱う以上、内部は相応に複雑にならざるを得ない。ユーザーから見た「シンプルな1つの箱」は、裏側の「複数サービスの協調」によって成り立っている。自己ホストするなら、この裏側を運用する覚悟が、そのまま導入のハードルになる。

ライセンスと注意点——EPL-2.0とHuly.io終了

最後に、Huly を紹介するうえで最も誠実に伝えるべき2点を書く。機能の魅力だけでなく、ここまで含めて判断してほしい。

ひとつはライセンスだ。Huly は Eclipse Public License 2.0（EPL-2.0） で提供される。これは「弱いコピーレフト（weak copyleft）」に分類されるライセンスで、MIT や Apache のような完全に自由な（パーミッシブな）ものではない。

Huly.io の終了は、一見ネガティブに見えるが、見方を変えれば「OSSの自己ホストという本来の強みに立ち返る」出来事でもある。ホスト版に依存していれば、運営の都合でサービスが消えたときに手も足も出ない。だが自己ホストなら、サーバーとデータは自分の手の内にある。Huly が掲げる「データを所有する」という価値は、皮肉にもホスト版の終了によって、いっそう明確になったと言える。

この一件は、SaaS全般に通じる教訓でもある。便利なホスト型サービスは、提供元が続ける限りは最高の体験を与えてくれるが、その継続はこちらの手に握られていない。業務の中核データをどこに置くかは、機能の good/bad とは別の、事業継続（BCP）の問題だ。OSSの自己ホストは運用の手間と引き換えに、この「サービスが消えても困らない」という保険を手に入れる選択肢だと言える。Huly を検討することは、そのトレードオフをチームとして引き受けるかどうかを考えることでもある。

なお、本記事のスター数・必要スペック・サービス終了時期などの数値・日付は、2026年7月時点の公式情報に基づく。開発の速いプロジェクトなので、導入時には必ず公式リポジトリと公式サイトで最新を確認してほしい。

まとめ——Huly は「SaaS散乱」への現実的な答えか

Huly は、「チームの道具が増えすぎる」という多くの組織が抱える課題に、「1つのOSSに束ねて自分で持つ」という明快な答えを出したプロジェクトだ。

向いているのは、複数のSaaSをまたいで運用していて、コストとデータ主権を理由に「自分たちのインフラへ寄せたい」中〜大規模のチームだ。逆に、機能を1つだけ軽く使いたいなら Plane や Mattermost のような単機能OSSのほうが手軽だろう。CRM だけを自己ホストしたいなら Twenty が候補になる。

導入を判断するときの軸は、突き詰めれば2つだ。ひとつは「SaaSの散らばりに、実際に困っているか」。ツールが2〜3個で足りているなら、束ねる旨みは小さい。5個も6個もまたいでいて、データの分散と月額に頭を悩ませているなら、Huly の統合は効いてくる。もうひとつは「自己ホストの運用を引き受けられるか」。30以上のマイクロサービスと複数のデータストアを、バックアップ込みで面倒みる体力（人・サーバー・時間）があるか。この2つに「はい」と言えるチームにとって、Huly は数少ない現実的な選択肢になる。

自己ホストの運用コストを受け入れられるなら、Huly は「SaaS散乱」への、いま最も野心的な回答のひとつである。ホスト版という近道が閉じたいま、その真価は「自分で立てて、自分で持つ」ところにこそ表れる。ツールの数だけ増えていく請求書とサイロ化したデータに疲れているなら、一度、検証環境に立てて触れてみる価値は十分にある。

参照ソース

・hcengineering/platform（Huly Platform・GitHub・EPL-2.0）
・Huly 公式サイト（huly.io）
・hcengineering/huly-selfhost（Docker セルフホスト）
・Huly Platform README（機能・導入・アーキテクチャ）