holaOS レビュー: Electron 製エージェントワークスペースを導入前にどう判断するか
Open-source agentic workspace enterprises can make their own. Connect the systems you already run — 100+ integrations, MCP, chat tools, apps, browser, local files — with shared memory. Any agent (Claude Code, Codex), any model, or BYOK. Set up in clicks, not months. Local-first: your data never leaves your machines.
ひと目でわかる
- これは何？
- holaOS は、アプリ、チャットツール、MCP、複数のエージェントをひとつのローカル環境に同居させる TypeScript 製デスクトップワークスペースである。統合の広さとメモリ共有が売りだが、ライセンス表記は NOASSERTION のままで、導入判断には確認すべき点が残る。
- 誰に向いている？
- Slack や Feishu に意思決定が流れ、Notion やブラウザをエージェントに操作させたいチームには、holaOS の「アプリとエージェントを同じ画面に並べる」設計は素直に効く。逆に、サーバー側でバッチ処理を回したい場合や、macOS 以外の CI 上でヘッドレスに動かしたい場合には向かない。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。最後のコミットは 25 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
holaOS が埋めようとしている「文脈が届かない」問題
エージェントに仕事をさせる場合、詰まるのはモデルの性能より前の段階であることが多い。要件は Slack のスレッドで決まり、変更は Feishu のグループで共有され、最終的な成果物だけが Notion に残る。エージェントに渡せるのはその最後の断片だけで、途中の会話は渡らない。holaOS はこの断絶を、チャットツールと業務アプリをワークスペースに直接つなぐことで埋めようとしている。README は「Most work context never makes it into a document. It's in a Slack thread, a Feishu group, a DingTalk message.」と述べており、対象読者は Slack、Feishu、DingTalk、WeChat のいずれかを使い、その会話をエージェントの入力にしたいチームである。個人開発者が単発のスクリプトを書く用途ではなく、複数人が同じ接続とメモリを共有する前提の設計になっている。
HolaApps はチャット欄ではなく実 UI をエージェントの隣に置く
多くのエージェント製品は、操作の結果をチャットのテキストとして返す。holaOS の HolaApps はそこを変え、Notion やブラウザなどのアプリをエージェントの横に本物の UI として開く。README の表現では「every app is a live UI (Notion, a browser, your own app), not a transcript」であり、エージェントがアプリ内で操作している様子をそのまま見て、任意の時点で人間が引き継げる。仕組みとして重要なのは双方向の同期で、人間が手でクリックしたり入力した内容がそのままエージェントの文脈になる。つまり「さっき何をしたか」を毎回説明し直す工程が消える。任意の URL と MCP サーバーを指して自分の HolaApp を作れると README は説明しているが、その自作アプリの権限がどこまで及ぶのかは README の範囲では読み取れない。
接続の三層: Integrations、MCP、Skills と Combos
能力の追加は三つの層に分かれている。第一層は Integrations で、Gmail、Notion、Slack、GitHub、Linear などと OAuth 一発でつなぐ。README は「50+ more」と書き、冒頭の説明では「100+ integrations」と書いている。数え方の定義が示されていないため、この数字は導入判断の根拠にはしないほうがよい。第二層は MCP で、任意の Model Context Protocol サーバーを接続してツールを増やせる。コミュニティ製サーバーのインストールにも触れている。第三層は Skills で、ワークフローを一度パッケージ化すれば任意のエージェントが呼び出せる。これらを束ねたものが Combos で、Skills と Integrations をまとめて一回のインストールで配れる。設計上の利点は、接続をエージェント単位ではなくワークスペース単位で持つ点にある。README は「every agent inherits the same connections」と述べており、Claude Code から Codex に切り替えても接続を組み直さずに済む。
エージェントとモデルを差し替え可能にする代償
holaOS は Claude Code、Codex、そして自前の holaOS エージェントを同一ワークスペースで並走させ、メモリ、ツール、Skills、アプリを共有すると説明している。モデル側も、アカウント一つで複数のモデルを使う経路と、OpenAI、Anthropic、または OpenAI 互換・Anthropic 互換のエンドポイントに自分のキーを持ち込む BYOK の経路が用意されている。ここで注意したいのは、README が挙げるモデル名が特定時点のラインナップだという点である。Kimi K3、GLM 5.2、GPT 5.6、Claude Opus 5、Fable 5 といった名前が並ぶが、これは製品の恒久的な仕様ではなく、更新されうる記載として読むべきである。もう一点、エージェントを差し替えても「同じ結果になる」と README は書いているが、異なるエージェント実装が同じ Skills を同じ手順で解釈する保証は、この資料からは確認できない。共有されるのは文脈とツールであって、推論の癖までは共有されない。
ローカルファーストが意味することと、意味しないこと
holaOS は Electron 製のデスクトップアプリで、macOS（Apple Silicon と Intel）、Windows、Linux に対応すると README のバッジが示している。データが機械の外に出ないという主張は、この配布形態と整合する。ただしローカルファーストという言葉がカバーする範囲は限定される。BYOK で外部プロバイダの API を呼ぶ場合、プロンプトと文脈は当然そのプロバイダに送られる。README 自身が BYOK について「those run on your account, not your holaOS plan」と書いており、課金経路の話であって送信先の話ではない。つまり「データが外に出ない」は、既定のモデル経路とローカルに置いたファイルやアプリの状態についての主張として読むのが正確である。IM 連携も同様で、Slack や Feishu のメッセージを読む以上、その内容はローカルのワークスペースに入る。アクセスはツール単位・スコープ単位で付与し、承認するまで読まないと README は説明しているので、権限設計はここで調整することになる。
動かすまでに何をするか
提供されたリポジトリ情報から確認できる起動手順は限られている。README には Quick Start へのアンカーがあり、本文のナビゲーションから docs の getting-started ページへ誘導される構成になっている。リポジトリは TypeScript で書かれ、既定ブランチは main、CI は GitHub Actions の ci.yml で回っている。パッケージマネージャやビルドコマンドの具体名は、この資料には現れないため断定できない。デスクトップアプリとして配布される以上、最初の一歩はソースからのビルドではなく、配布されたアプリを入れてワークスペースを開くことだと考えるのが自然だが、これも README の記述から直接は確認できない。確実に言えるのは、セットアップの中心がコードを書くことではなく、ワークスペース内で Integrations の OAuth を通し、MCP サーバーを登録し、IM 連携のスコープを承認するという操作になるという点である。導入検討の初期段階では、ビルド手順を読むより先に getting-started のドキュメントで対応 OS と初期設定の流れを確認したほうが早い。
向かない場面と、代わりに検討する構成
holaOS が適さないのは、ヘッドレスで動かしたい場合である。Electron のデスクトップアプリが前提なので、サーバー上で常時動かすバッチや、CI の中でエージェントを走らせる用途には構造が合わない。もう一つ、共有メモリを全エージェントに効かせる設計は、逆に言えば分離が難しいということでもある。機密性の異なるプロジェクトを同じワークスペースに同居させる運用では、メモリの分離単位がどこにあるのかを先に確認する必要がある。代わりに検討できる構成として、MCP サーバーを自前で立てて各クライアントから個別に接続する方法がある。この場合、接続とメモリはクライアントごとに独立し、共有したい文脈は自分で受け渡すコードを書くことになる。holaOS が省いているのはまさにその配線であり、配線を自分で書きたい、あるいは書ける体制があるなら、汎用の MCP サーバー群のほうが構成の見通しはよくなる。逆に、配線こそが目的でないチームにとっては、ワークスペース単位で接続とメモリを持つ holaOS のほうが記述量は少なくなる。
ライセンス表記の食い違いと保守コスト
このリポジトリで最も注意を要するのはライセンスである。リポジトリのメタデータでは License が NOASSERTION となっており、自動判定ができなかったことを示す。一方で README のバッジは Modified Apache 2.0 と表示している。この二つは一致していない。Apache 2.0 に修正条項が付く場合、その条項が何を制限するのかで企業導入の可否は変わる。ここは推測で埋めず、リポジトリ内のライセンスファイルを直接読んで確認する以外にない。保守の観点では、既定ブランチ main への最終 push が 2026-08-21、latest リリースが 2026-08-06 であり、この資料の時点で継続的に更新されている。ただし更新の頻度そのものは、統合の互換性が保たれる保証にはならない。Gmail、Notion、Slack などの OAuth スコープや API は外部要因で変わり、MCP サーバーも独立に更新される。ワークスペースに多数の接続を載せるほど、壊れたときにどこを直すかの切り分けが重くなる。導入時は、業務上必須の接続を二、三個に絞ってから広げるほうが、後の切り分けは楽になる。
編集部の結論
Slack や Feishu に意思決定が流れ、Notion やブラウザをエージェントに操作させたいチームには、holaOS の「アプリとエージェントを同じ画面に並べる」設計は素直に効く。逆に、サーバー側でバッチ処理を回したい場合や、macOS 以外の CI 上でヘッドレスに動かしたい場合には向かない。Electron デスクトップが前提だからである。導入前に確認すべきは三点で、第一にリポジトリの License が NOASSERTION と表示され README のバッジは Modified Apache 2.0 と食い違っているため実際の条件をリポジトリ内のライセンスファイルで直接読むこと、第二に README が挙げる対応モデル名が時点依存の記載であること、第三に 100+ integrations や 50+ という数字が何を数えたものかドキュメントで裏が取れるかどうかである。
コミュニティノート