「Claude Codeで長い実装を走らせている最中に外出しなければならなくなった。手元のMacはセッションを抱えたまま置いていくしかなく、移動中はスマホから進捗すら確認できない」。AIコーディングエージェントを日常的に使う人なら、一度は感じるもどかしさです。happier（ハピアー）は、まさにこの「端末をまたいでセッションを持ち歩けない」問題のために作られた、エンドツーエンド暗号化のリモート操作クライアントです。公式のタグラインは「Web, Desktop & Mobile client for Codex, Claude Code, OpenCode, Kimi, Augment Code, Qwen, fully end-to-end encrypted」。ひとことで言えば「AIコーディングセッションを、暗号化したまま端末をまたいで引き継ぐためのコンパニオンアプリ」です。ライセンスはMIT、GitHubで約1,100スター（2026年7月時点）を集めています。
この記事を読むと、①happierで結局何ができるのか（ローカルで走らせたエージェントのセッションを、デスクトップ・モバイル・Webから引き継いで操作する）、②どんな課題を解決するのか（端末をまたいだセッションの継続と、E2E暗号化によるプライバシー確保）、③何を代替できるのか（マルチデバイスでのエージェント操作に限れば、SSH＋tmuxの手作業や、各社独自のクラウド同期の代わりになりうる）が分かります。なお、そもそもClaude Codeの基本を固めたい方は、まずClaude Code完全ガイド2026：インストールから本番運用までを合わせて読むと、happierが担う”リモート操作レイヤー”の位置づけが掴みやすくなります。
- ・happierはClaude CodeやCodexなどのAIコーディングセッションを、端末をまたいで引き継げるOSSクライアント。
- ・最大の特徴は、セッション・メッセージをエンドツーエンド（E2E）暗号化したまま複数端末で共有すること。
- ・構成はRelay Server・Machine Daemon・UI/Appの3つ。Relayはセルフホスト可能。
- ・iOS/Android/デスクトップ/Webに対応し、既存セッションの閲覧・引き継ぎ・フォーク・リプレイができる。
- ・現時点はALPHAプレビュー。バージョンの整合が必要で、AnthropicやOpenAI公式とは無関係。
1. happierとは：AIコーディングセッションを端末をまたいで持ち歩くクライアント
happierは、Claude CodeやCodexなどのコーディングエージェントを、複数の端末から操作・継続するためのオープンソースのコンパニオンアプリです。エージェント本体を置き換えるものではなく、あくまで「既存のエージェントに、リモート操作とマルチデバイス連携という一枚のレイヤーを足す」という発想です。実体はTypeScriptが約90%を占め、CLI・デーモン・各種クライアントアプリからなります。
ポイントは、happierが単なる「リモートデスクトップ」ではないことです。よくあるSSHや画面共有は「遠くの画面をそのまま覗く」だけですが、happierはセッションそのものを構造化されたデータとして扱い、端末をまたいで引き継ぐことに主眼を置いています。しかもそのデータはエンドツーエンド（E2E）暗号化され、中継サーバーですら中身を読めない前提で設計されています。「便利さ」と「プライバシー」を同時に満たそうとしている点が、happierの立ち位置を決めています。
happierが束ねているのは、次の3つの性質だと整理できます。
・マルチデバイス継続：デスクトップで始めたセッションを、モバイルやWebから引き継いで続けられる
・E2E暗号化：セッションやメッセージは端末側で暗号化され、中継サーバーは平文を読めない
・エージェント非依存：Claude Code・Codex・OpenCode・Geminiなど、複数のエージェントを同じ枠組みで扱える
名前が示すとおり、happierの狙いは「エージェント運用のストレスを減らして、開発者を”より幸せ”にする」ことにあります。これまでも、ローカルのエージェントをリモートから触るために、SSHで入り直したり、tmuxでセッションを永続化したり（この手の”多重化”はherdr（エージェント版tmux）が得意とする領域です）といった工夫はありました。しかしそれらは「端末は繋がるが、スマホから快適に操作するのは難しい」「同期はできるが暗号化やデバイス間の引き継ぎまでは面倒を見ない」といった具合に、どこかで妥協が生じます。happierが新しいのは、マルチデバイス継続・E2E暗号化・エージェント非依存という3要件を、ネイティブアプリとセルフホスト可能なサーバーで一体として提供した点です。
- ・SSH＋tmux＝端末を繋ぐ汎用手段。happier＝セッションを暗号化したまま端末間で引き継ぐ専用クライアント。
- ・「遠くの画面を覗く」のではなく「セッションそのものを持ち歩く」のがhappierの発想。
2. なぜ必要か：端末をまたいでセッションが途切れる問題
happierが解決するのは、AIコーディングエージェントを”1台のマシンに縛りつけて”使うことで生じる不便です。エージェントは通常、開発マシン上のCLIとして走ります。1台の前に座り続けている間は快適ですが、席を立った瞬間に問題が始まります。
具体的な症状はこうです。
・デスクトップでClaude Codeに長い実装を任せたまま外出すると、移動中は進捗すら見られない
・エージェントが途中で許可（ファイル書き込みやコマンド実行）を求めて止まっているのに、気づけない
・別の端末から続きを触ろうとしても、セッションの文脈が引き継げない
・クラウド同期に頼ると、今度はセッションの中身をサービス提供者に預けるプライバシー上の不安が出る
従来の手段はこの一部しか解けません。SSHは端末を繋ぎますが、スマホから快適に操作するのは骨が折れますし、セッションの構造化された引き継ぎまでは面倒を見ません。各社独自のクラウド機能は便利な反面、セッションの中身をどこまで預けるのかという不安が残りがちです。「便利にすると中身を預けることになり、中身を守ると不便になる」——このトレードオフが、マルチデバイスでのエージェント運用を難しくしてきました。
- ・happierは現時点でALPHAプレビュー。公式も「あちこちバグがあるかもしれない」と明言しており、nightlyの開発ビルドは特に不安定。
- ・dev-channelのCLI・アプリ・デーモン・サーバーはバージョンを揃える必要があり、クラウドのサーバーが遅れる場合がある。本番運用ではなく検証から始めるのが安全。
- ・happierはAnthropic・OpenAI・Googleのいずれとも無関係の非公式プロジェクト（endorsedされていない）。
この問題は、エージェントの自律性が上がるほど深刻になります。長い作業を任せられるようになるほど、「席を外している間に進む」時間が増え、その間に発生する”確認待ち”に気づけるかどうかが、全体のスループットを左右するようになるからです。つまりエージェントが賢くなるほど、どこからでも介入できる手段の価値が上がるという関係にあります。happierは、この「便利さとプライバシーの両立」を、E2E暗号化を前提にしたマルチデバイス連携で埋めようとしています。
happierが解決の軸に据えるのは、セッションを暗号化されたデータとして端末間で共有するという一点です。これにより「デスクトップで開始→モバイルで確認・応答→再びデスクトップで継続」という往復を、中身を第三者に預けずに回せます。人間の役割は「1台に張り付く」ことから「どの端末からでも、必要なときだけ介入する」ことへと変わります。
3. happierの主な機能：セッション引き継ぎ・フォーク・音声・受信箱
happierの機能は「エージェントをどこからでも快適に操作する」ために選ばれています。主要機能を整理します。
既存セッションの閲覧・追跡・引き継ぎ：走っているセッションを一覧から選び、内容を追い、そのまま操作を引き取れます（Browse, follow, and take over existing sessions）。
セッションのフォークとリプレイ：あるセッションを分岐させて別の展開を試したり、過去のやり取りを再生して振り返ったりできます（Session forking and replay）。
マシン間のセッション引き継ぎ：あるマシンで始めたセッションを、別のマシンへ引き継げます（Session handoff between machines）。ターミナル・デスクトップ・Web・モバイルの間をシームレスに行き来できます。
コラボレーティブセッション：チームメイトと同じセッションを共有し、共同で作業できます（Collaborative sessions）。
音声アシスタント：ClaudeやconfiguredバックエンドをVoiceで操作できます。音声合成にはElevenLabs RealtimeやKokoro TTSといった選択肢が用意されています。
受信箱（Inbox）：複数セッションにまたがる許可リクエストを、1つの受信箱に集約して処理できます。「どのセッションが自分の応答を待っているか」を横断的に把握できます。
MCPサーバー連携／ローカルメモリ検索：MCPサーバーと統合でき、暗号化されたトランスクリプトをローカルで検索できます（Local memory search）。
エンタープライズ対応：GitHub OAuth・OIDC・mTLS・キーレスな外部認証に対応します（Enterprise-ready）。
対応するコーディングエージェントも広く、Claude Code・Codex・OpenCode・Gemini・GitHub Copilot・Pi・Kiro・Kilo・Kimi・Qwen・Augment Code など多数がサポートされています。クライアント側はiOS（App Store）・Android（Play Storeベータ＋APK）・macOS/Linux（CLI＋デスクトップ）・Web（app.happier.devまたはセルフホスト）を網羅します。
これらの機能に一本の筋を通しているのが「セッションを構造化データとして、暗号化したまま扱う」という思想です。単に画面を転送するだけなら、フォークやリプレイ、横断的な受信箱、ローカルでのメモリ検索といった機能は成立しません。happierはセッションを「持ち運べるデータ」として抽象化しているからこそ、こうした一段上の操作が可能になっています。Tailscale ServeやtmuxセッションとのIntegrationも用意されており、既存のリモート環境に馴染ませやすいのも実務上の利点です。
- ・「受信箱」で複数セッションの許可待ちを1か所に集約。どのセッションが自分を待っているかを横断で把握できる。
- ・「フォーク／リプレイ」でセッションを分岐・再生。試行錯誤や振り返りが、1本道のログではなく操作対象になる。
4. happierの3つの構成要素：Relay Server・Machine Daemon・UI/App
happierの内部は、大きく3つの構成要素で理解できます。Relay Server（中継サーバー）・Machine Daemon（マシン常駐デーモン）・UI/App（クライアント） の3つです。それぞれの役割を押さえておくと、happierが「どこで暗号化し、どこでエージェントを動かし、どこから操作するのか」がはっきりします。
・Relay Server（中継サーバー）：セッションやメッセージを保管し、UIとデーモンの間の通信を成立させる。セルフホストもクラウド（api.happier.dev）も選べる。
・Machine Daemon（マシン常駐デーモン）：ローカルのLLM／エージェントのプロセスとセッション状態を管理し、Relay経由で通信する。実際にエージェントが走る場所。
・UI/App（クライアント）：モバイル・Web・デスクトップのネイティブクライアント。Relayを通じて更新される、操作の窓口。
全体像を図にすると次のようになります。エージェントが実際に動くのは手元のマシン（Daemon側）で、Relay Serverはあくまで暗号化されたメッセージを中継する土管、UI/Appはどこからでも繋がる窓口、という三者の関係が見えてきます。
モバイル・Web・デスクトップ"] -->|"暗号化メッセージ"| Relay["Relay Server
保管・中継
セルフホスト可"] Relay -->|"暗号化メッセージ"| Daemon["Machine Daemon
エージェント実行
ローカルマシン"] Daemon -->|"セッション更新"| Relay Relay -->|"セッション更新"| App Daemon --> Agent["Claude Code / Codex
など各エージェント"]
この3層構造には、happierの思想がそのまま表れています。まずエージェントが走るのはあくまでDaemon側（＝あなたのマシン）であり、コードやモデルとのやり取りが手元で完結する点は変わりません。Relay Serverは中身を読めない中継役に徹するため、クラウド（api.happier.dev）を使ってもセッションの平文がサービス提供者に渡らない設計になっています。そしてUI/AppはRelay越しに更新を受け取る窓口なので、iOSでもWebでもデスクトップでも、同じセッションに同じように繋がれます。
セルフホストの選択肢が用意されているのも重要です。Relay Serverを自社インフラ内に立てれば、api.happier.devのクラウドを一切経由せず、社内ネットワークの中だけでマルチデバイス連携を完結させられます。エンタープライズ向けの認証（GitHub OAuth・OIDC・mTLS）と組み合わせれば、社内のセキュリティポリシーに沿った形でエージェントのリモート運用を組めます。「便利さのためにクラウドへ寄せる／プライバシーのために手元へ寄せる」を、構成要素の配置で選べるのがこの設計の柔軟さです。
5. マルチデバイスのセッション引き継ぎフロー：デスクトップからスマホへ
happierの真価は、実際の「引き継ぎ」フローに落とすと見えてきます。もっとも分かりやすいのが、デスクトップで始めたセッションを、外出時にスマホへ引き継ぐ流れです。順を追って見てみましょう。
まずデスクトップで happier を起動し、Claude CodeやCodexにタスクを指示してセッションを開始します。エージェントは手元のMachine Daemon上で走り、その状態は暗号化されてRelay Serverに同期されます。ここで席を立つ必要が出たら、デスクトップは閉じてしまって構いません——セッションはDaemonが抱えたまま生き続けます。
外出先では、スマホのhappierアプリを開きます。Relay Server経由で同じセッションが見えるので、進捗を追いながら、エージェントが求めてきた許可リクエストに受信箱から応答できます。必要なら、そのままモバイルからセッションを引き取って（take over）操作を続けられます。帰宅してデスクトップに戻れば、また手元から継続する——この往復を、セッションの文脈を失わずに回せます。
セッション開始"] -->|"暗号化して同期"| R["Relay Server
状態を中継"] R -->|"外出・端末を切替"| M["モバイルアプリ
セッションを閲覧"] M -->|"許可リクエストに応答"| Box["受信箱
複数セッションを横断"] M -->|"操作を引き取る"| R R -->|"帰宅・端末を切替"| D2["デスクトップ
継続"]
この「投げて、離れて、別端末で拾って、また戻る」というサイクルこそ、happierがもっとも輝く使い方です。ここで本質的なのは、人間の仕事が「1台のマシンに張り付くこと」から「どの端末からでも、必要なときだけ介入すること」へと変わる点です。エージェントの自律性が上がるほど、この”必要なときだけ触る”運用の価値は増していきます。
コラボレーティブセッションを使えば、この往復をチームにも広げられます。同じセッションをチームメイトと共有し、片方が席を外している間にもう片方が許可リクエストに応答する、といった連携も組めます。セッションを「持ち運べる・共有できるデータ」として抽象化したからこそ成立する使い方です。なお、これらのフローはすべてE2E暗号化の上で行われるため、端末を増やしても中身を第三者へ広げることにはなりません。
6. 他の手段との比較：SSH＋tmux・クラウド同期・GUIアプリとの違い
では、happierは既存の手段とどう違うのか。マルチデバイスでエージェントを操作する代表的なアプローチと比べて整理します。
| 観点 | happier | SSH＋tmux | 各社クラウド同期 | 画面共有／リモートデスクトップ |
|---|---|---|---|---|
| 主目的 | セッションのマルチデバイス継続 | 端末の永続化・多重化 | セッションの同期 | 遠隔の画面操作 |
| モバイル操作 | ネイティブアプリで快適 | 実用的でないことが多い | サービス次第 | 操作しづらい |
| E2E暗号化 | 前提として設計 | 通信路は暗号化（中身は別） | サービス次第 | 通信路のみ |
| セッションの引き継ぎ | 構造化データとして継続 | 端末は繋がるが引き継ぎは手動 | 可能なことが多い | 画面のみ |
| フォーク／リプレイ | あり | なし | サービス次第 | なし |
| セルフホスト | 可能（Relay） | 自前サーバー | 不可なことが多い | 環境次第 |
| 対応エージェント | 多数（Claude Code/Codex等） | 端末で動けば何でも | 提供元のものに限定 | 端末で動けば何でも |
| ライセンス | MIT | 各ソフトによる | 製品による | 製品による |
要するに、端末を繋ぐだけなら SSH＋tmux、特定サービス内の同期なら各社クラウド、エージェント非依存でマルチデバイス継続＋E2E暗号化まで面倒を見るのが happier、という住み分けです。SSH＋tmuxはエンジニアには馴染み深く強力ですが、スマホからの快適な操作やセッションの構造化された引き継ぎは苦手です。各社のクラウド同期は便利な反面、対象が提供元のエージェントに限られ、中身を預けるかどうかの判断も付いて回ります。
補足すると、happierはSSHやtmuxを”敵”とは見ていません。実際、Tailscale ServeやtmuxセッションとのIntegrationが用意されており、既存のリモート環境の上に馴染ませられます。ローカルでの多重化・永続化はherdr（エージェント版tmux）のような専用ツールが引き受け、その外側から複数端末で触るレイヤーをhappierが担う——という組み合わせは自然です。両者はどちらも「コーディングエージェントを走らせる」ことが主題ですが、happierはリモート／モバイルからの操作、herdrはローカルでの多重化、と役割がきれいに分かれます。
画面共有やリモートデスクトップと比べた最大の差別化は、happierが画面ではなくセッションそのものを扱う点です。画面転送は「遠くのピクセルを覗く」だけなので、フォークもリプレイも横断的な受信箱も成立しません。happierはセッションを暗号化された構造化データとして持つからこそ、これらの一段上の操作を可能にしています。「遠くの画面を覗く」から「セッションを持ち歩く」へ——この抽象化の違いが、happierの機能群を支えていると言えます。
- ・ローカルで複数エージェントを多重化・永続化したい → herdrなどの多重化ツールが刺さる。
- ・その外側から、スマホやWebでセッションを引き継ぎたい → happierが刺さる。
- ・社内で中身を外へ出したくない → Relay Serverをセルフホストし、mTLS/OIDCで固める。
7. happierのインストールと導入判断：向いている人・注意点
導入はワンライナーで始められます。まずはインストールから。
# macOS / Linux（公式インストーラ）
curl -fsSL https://happier.dev/install | bash
Windowsの場合はPowerShellから入れられます。
# Windows（PowerShell）
iwr https://happier.dev/install.ps1 -useb | iex
インストール後は、認証してからエージェントごとにセッションを起動します。使いたいエージェントをサブコマンドで選ぶ形が基本です。
# 認証（初回のみ）
happier auth login
# セッションを起動（エージェントを選ぶ）
happier # デフォルト
happier codex # Codex
happier opencode # OpenCode
happier gemini # Gemini
happier kimi # Kimi
happier qwen # Qwen
ソースからビルドして開発版を動かしたい場合は、次の手順です。dev-channelのCLI・アプリ・デーモン・サーバーはバージョンを揃える必要がある点に注意してください。
# ソースからビルド
npm i -g yarn
git clone https://github.com/happier-dev/happier.git
cd happier
yarn
yarn build
# 開発モード
yarn dev
# TUI を起動
yarn tui
# 本番ビルドと起動・停止
yarn build
yarn start
yarn stop
これだけで、認証したアカウントのもとで、選んだエージェントのセッションがRelay経由で各端末に同期されるようになります。CLIのサブコマンドでエージェントを切り替えるだけで、同じ操作体験のまま複数のエージェントを扱えるのがhappierの導入の軽さです。
happierが向いている人
・Claude Code・Codex・Geminiなどをローカルで走らせつつ、スマホやWebから続きを触りたい
・長時間実行をデスクトップに預けたまま外出し、移動中に許可リクエストへ応答したい
・セッションの中身を第三者に預けたくない、E2E暗号化・セルフホストを重視する
・チームで同じセッションを共有して協働したい
・GitHub OAuth・OIDC・mTLSなど社内認証と統合したい
慎重に判断すべきケース
・常に1台のマシンの前に座って作業する（マルチデバイスの必要が薄い）
・安定性が最優先の本番運用に、今すぐ載せたい（現状はALPHA）
・Anthropic/OpenAI/Google公式のサポートを前提にしたい（happierは非公式・無関係）
特に強調しておきたいのがALPHA段階であることです。happierは公式が「あちこちバグがあるかもしれない」と述べるALPHAプレビューで、とりわけnightlyの開発ビルドは非常に不安定です（部分的なコミットが含まれることがあります）。また前述のとおり、dev-channelのCLI・アプリ・デーモン・サーバーはバージョンを揃える必要があり、ホスティングされたクラウドサーバーが遅れる場合もあります。個人の検証や、セルフホストでの試用から始めるのが安全です。
ライセンスはMITで、この点は組み込みやすさに寄与します。ただし、happierが扱うのはコードやセッションという機微な情報です。クラウドのRelay（api.happier.dev）を使う場合とセルフホストする場合とで、情報がどこを通るかが変わるため、社内で使うならRelayの配置と認証方式を先に決めておくのが賢明です。
- ・現状はALPHAプレビュー。安定性が要る用途は避け、検証・試用から始める。nightlyは特に不安定。
- ・dev-channelの各コンポーネント（CLI/app/daemon/server）はバージョンを揃える。クラウドサーバーが遅れる場合あり。
- ・happierはAnthropic/OpenAI/Googleと無関係の非公式プロジェクト。公式サポートは期待しない。
- ・機微な情報を扱うため、Relayをセルフホストするか否か、認証（OAuth/OIDC/mTLS）をどうするかを先に決める。
まとめ
happierは、「AIコーディングエージェントを1台のマシンに縛りつけない」ために生まれた、E2E暗号化のリモート操作クライアントです。SSHやtmuxが端末を繋ぐのに対し、happierはセッションそのものを暗号化されたデータとして端末間で持ち歩くという一点で、明確に一歩踏み込みました。
- ・happierはClaude CodeやCodexなどのセッションを、端末をまたいで引き継げるOSSクライアント。
- ・セッション・メッセージをE2E暗号化したまま、デスクトップ・モバイル・Webで共有する。
- ・構成はRelay Server・Machine Daemon・UI/Appの3つ。Relayはセルフホスト可能で、OIDC/mTLSと統合できる。
- ・ローカル多重化はherdr、その外側からのリモート操作はhappier、という住み分けが自然。
- ・現時点はALPHA。バージョン整合が必要で、Anthropic/OpenAI/Googleとは無関係の非公式プロジェクト。
デスクトップで走らせたセッションをスマホから続けたい、という心当たりがあるなら、まずは curl -fsSL https://happier.dev/install | bash で入れて、いつものClaude CodeやCodexを1セッション、happier越しに別端末から覗いてみてください。ただしALPHA段階である点は念頭に、検証から始めるのが安全です。Claude Codeそのものの使い方を固めたい方はClaude Code完全ガイド2026：インストールから本番運用までを、より実践的な運用のコツはClaude Codeベストプラクティスガイド2026を合わせて読むと、happierを載せる土台が整います。
参照ソース
・happier-dev/happier (GitHub) — 公式リポジトリ。README・対応エージェント一覧・構成要素・インストール手順の一次ソース。
・happier 公式サイト — インストーラ・概要・各クライアントの入手先を案内する公式サイト。
・happier ドキュメント — セットアップ・構成（Relay/Daemon/App）・認証などの公式ドキュメント。
