jcode 徹底解説 — 高速・省メモリなRust製エージェントハーネス

最近、jcodeに関する投稿をXで見かけたので、実際にインストールして使ってみました。jcodeは「軽量・高速」というのが売りのAIコーディングエージェントです。この記事では、インストール手順や実際に使ってみた感想などを紹介します。

はじめに

jcode は、Rust で書かれた AI コーディングエージェント・ハーネスです。開発者は「The most RAM efficient harness（最も RAM 効率の良いハーネス）」を謳っており、公開ベンチマークではメモリ使用量・起動速度の両方で既存のエージェント環境（Claude Code, opencode, Cursor Agent, Codex CLI など）を大きく上回る結果が出ています。

ただし、こうした性能数値は実際の作業では体感しにくい面もあります。

本記事では性能だけでなく、内蔵メモリや Swarm などの機能面も含めて、公式ドキュメントと公開ベンチマークをもとに整理しました。実際にインストールして使った結果も合わせて書いています。

リポジトリ: https://github.com/1jehuang/jcode

jcode とは

jcode は、ターミナル上で動作する AI コーディングエージェントです。以下の特徴があります

なぜ今 jcode なのか

2025-2026 年にかけて、AI コーディングエージェントは多数のツールが登場し、選択肢が増えています。その中で jcode が注目されるきっかけは、公開ベンチマークの性能数値です：

※1 ローカル埋め込みオフ時の値です（詳細は「メモリ使用量」を参照）。10 セッション並列時は jcode 約 117 MB に対し opencode 約 3.2 GB と 27 倍以上の差がつきます。

これらの数値は公式が公表しているもので、計測方法・バージョ・環境に依存します。あくまで参考値として見てください。実務での体感差がどの程度かは「ベンチマークの限界」で詳しく説明します。

インストール

インストール方法は OS ごとに分かれます

macOS / Linux

公式のインストールスクリプトです。最新リリースをダウンロードし、jcode を PATH に追加します：

curl -fsSL https://jcode.sh/install | bash

macOS（Homebrew）

Homebrew を使う場合は次の 2 コマンドです：

brew tap 1jehuang/jcode
brew install jcode

ソースからビルド

ソースからビルドする場合は、リポジトリをクローンして cargo でビルドし、PATH にシンボリックリンクを作成します：

git clone https://github.com/1jehuang/jcode.git
cd jcode
cargo build --release
scripts/install_release.sh

アンインストール

アンインストールにも公式スクリプトが用意されています。何も指定せずに実行すると、バイナリとランチャーは削除されますが、設定・認証・セッションは残ります。再インストールすれば作業環境をそのまま引き継げるため、まずはこちらでよいと思います。

curl -fsSL https://raw.githubusercontent.com/1jehuang/jcode/master/scripts/uninstall.sh | bash -s -- --yes

• 完全削除したい場合
  --purge を付けると、設定・認証・セッション・ログ・メモリまで全て削除されます。壊れたインストールからの復旧など、初期状態に戻したいときに使います
• 削除対象を事前確認したい場合
  --dry-run を付けると、何が削除されるかのプレビューのみ表示されます（実際には削除されません）
• 削除される場所
  実行中の jcode サーバは自動停止され、~/.local/bin/jcode（ランチャー）と ~/.jcode/builds/（インストール済みバイナリ）が削除されます

インストール時に、ログイン項目と拡張機能へ「バックグラウンドでのアクティビティ」として登録されます。アンインストール時はこれも忘れずに削除してください（macOS）

完全削除のコマンドは以下になります

curl -fsSL https://raw.githubusercontent.com/1jehuang/jcode/master/scripts/uninstall.sh | bash -s -- --purge --yes

Homebrew で導入した場合は、このスクリプトではなく brew uninstall jcode を使います（tap の削除は brew untap 1jehuang/jcode）。

クイックスタート手順

プロバイダの設定

初回起動時はプロバイダのログインが必要です。サブスクリプションを契約しているサービスを選んでログインします：

# Claude サブスクリプション
jcode login --provider claude

# OpenAI / ChatGPT
jcode login --provider openai

# Google Gemini
jcode login --provider gemini

# GitHub Copilot
jcode login --provider copilot

# ローカルの Ollama
jcode login --provider ollama

プロバイダは Opencode GO を設定し、OPENCODE_GO_API_KEY に API キーを設定、モデルを指定したらそのまま動きました。主要プロバイダなら簡単そうです。

基本コマンド

ログインできたら、以下のコマンドで使い始められます：

# TUI を起動
jcode

# 非対話的にコマンド実行
jcode run "hello, what files are in this project?"

# セッションを名前指定で再開
jcode --resume fox

# バックグラウンドサーバとして起動し、別クライアントから接続
jcode serve
jcode connect

# 音声入力
jcode --voice

スラッシュコマンド

TUI 内で / をタイプすると、ファジーマッチでコマンドが候補表示されます。代表的なものをまとめます：

プロバイダの詳細

jcode はサブスクリプション型の OAuth フローと、直接 API キーを使う方式の両方をサポートしています。

ネイティブプロバイダ

公式のログインフローが用意されているプロバイダは次のとおりです

OpenAI 互換エンドポイント

OpenRouter, DeepSeek, Moonshot AI, Hugging Face, Nebius などは、プリセットプロファイルが用意されています：

# 名前付きプロファイルでログイン
jcode login --provider openrouter
jcode login --provider deepseek

# カスタムエンドポイント
printf '%s' "$MY_API_KEY" | jcode provider add my-api \
  --base-url https://llm.example.com/v1 \
  --model my-model-id \
  --api-key-stdin \
  --set-default

カスタムエンドポイントでは、API キーをシェルの履歴に残さずに設定できるのが便利です。

ローカルサーバ

ローカルで動かしているモデルサーバも利用できます：

# Ollama
jcode login --provider ollama

# LM Studio
jcode login --provider lmstudio

# 認証不要のローカル vLLM
jcode provider add local-vllm \
  --base-url http://localhost:8000/v1 \
  --model Qwen/Qwen3-Coder-30B-A3B-Instruct \
  --no-api-key \
  --set-default

ヘッドレス環境（SSH）

ブラウザが開けない SSH などの環境では、--no-browser フラグで認証 URL を表示し、別端末から完了できます：

jcode login --provider claude --no-browser

主要機能

メモリ（Agent Memory）

jcode のメモリシステムは、人間のような記憶の仕組みを実装しています。各ターンをセマンティックベクトル（文章の意味を数値の配列で表したもの）に変換し、会話の中で関連する記憶を自動的に呼び戻します

Swarm（マルチエージェント協調）

同一リポジトリ内で複数のエージェントを立ち上げると、サーバが自動的に管理します：

• ファイル変更通知
  エージェント A が編集したファイルをエージェント B が読んでいる場合、サーバが通知します
• エージェント間メッセージ
  DM、ブロードキャスト、リポジトリ単位のグループ送信ができます
• 自律スウォーム
  エージェント自身がチームメイトを spawn し、Coordinator / Worker 構造で並列タスクを実行できます

UI と描画

実際に使ってみた印象: 一方で、UI はシンプルすぎるように感じました。また、思考（reasoning）部分がそのまま表示されてしまうのも気になりました。

ブラウザ自動化

Firefox Agent Bridge をバックエンドとしたブラウザ操作ツールが内蔵されています：

jcode browser status
jcode browser setup

サポートするアクション：open, click, type, fill_form, select, screenshot, eval, scroll, upload, press など

自己開発（Self-Dev）

エージェントに「自己開発モードに入れ」と指示すると、自身のソースコードを編集・ビルド・テストし、バイナリを再読み込みして作業を継続します。Rust で書かれているため、リフレクションやスクリプティングではなく、実際のコンパイルを伴う自己改良ができるのが特徴です。

クロスハーネス・セッション再開

他のハーネスで中断したセッションを jcode で再開できます：

/resume

Claude Code, Codex CLI, opencode, pi のセッションからの復帰に対応しています。

設定ファイル

設定は ~/.jcode/config.toml に記載します。例えば以下のように書きます：

[provider]
default_provider = "openai"

[display]
centered = true

[features]
memory = true
swarm = true

[keybindings]
side_panel_toggle = "alt+m"
new_terminal = "alt+enter"

スキルシステム

スキルは SKILL.md を含むディレクトリで、~/.jcode/skills/ にインストールします。opencode のカスタムスキルと互換性があり、Claude Code のプラグインディレクトリからも読み込み可能です。

スキルは起動時にはロードされず、会話のセマンティックベクトルとマッチしたときに自動的に注入されます（メモリと同様の仕組みです）。

MCP 対応

jcode は MCP（Model Context Protocol、LLM が外部ツールと連携するための標準プロトコル）サーバをサポートしています：

{
  "mcpServers": {
    "filesystem": {
      "command": "/path/to/mcp-server",
      "args": ["--root", "/workspace"],
      "env": {}
    }
  }
}

設定ファイルは ~/.jcode/mcp.json（グローバル）と .jcode/mcp.json（プロジェクトローカル）です。Claude Code の設定ファイル（~/.claude.json, .mcp.json）も自動検出します。

他のエージェント環境との比較

メモリ使用量

1 セッションでは 167 MB（埋め込みオフ時 27.8 MB）で、1 セッション追加あたり約 10 MB ずつ増えるのが特徴です。対して opencode は 1 セッション追加で約 318 MB 増えるため、並列セッション数が増えるほど差が開きます。

起動速度（Time to First Frame）

ベンチマークの限界

上記の数値は印象的ですが、実際に使った体感インパクトは限定的です。ここは正直に述べておきます。

• 起動速度の差は実質無意味に近い
  LLM 応答（数秒〜数十秒）が支配的で、起動 14 ms と 1,036 ms の差はその中に埋もれます。意味があるのは短命コマンドを大量に実行する場合や、TUI の描画・スクロールの滑らかさ（フリッカの有無）くらいです。実際に使ってみても、速度は結局モデル（LLM）の応答速度に支配されるため、ハーネスの高速性はあまり意味がないと実感しました
• メモリ削減も 1〜3 セッション運用なら誤差
  最近の開発機（16-64 GB）では 27 MB と 371 MB の差は体感できません。真価を発揮するのは 10 セッション以上の並列運用や、CI・低スペック機・サーバ・Termux など資源制約のある環境です
• ベンダー自身の公表値
  計測方法・バージョン・環境に依存するため、あくまで参考値として捉えるべきです

つまり、性能よりも機能面（内蔵メモリ、Swarm、ブラウザ自動化、自己開発、クロスハーネス再開）こそが真の差別化ポイントであり、性能数値は「できるだけ省資源にしたい」という要件がある場合の判断材料と考えるのが適切です。

アーキテクチャの違い

opencode ユーザー視点での比較（現時点）

私は普段 opencode を利用しているため、opencode ユーザーが jcode を検討する際の観点で、現時点のメリット・デメリットを整理します。

結論（現時点）

機能面（内蔵メモリ、Swarm、ブラウザ自動化など）では jcode に分があります。一方、性能面（RAM・起動速度）は「ベンチマークの限界」で述べたとおり実務での実感が限定的で、「今日から opencode を捨てて乗り換えるべきか」 と聞かれれば、現時点ではまだ opencode の安定運用実績とエコシステムに勝る面があります。

私の方針としては、しばらくは opencode を使いながら、jcode も試してみる というスタンスです。実際に使ってみた限りでは荒削りな面が目立ちましたが、進化が速いツールなので今後もウォッチしていく予定です。

まとめ

実際に使ってみた感想ですが、売りの省メモリ・高速起動については自分の使い方だとそこまでメリットがないなという印象です。セッションも同時に２〜３くらいしか開きませんし（これ以上開くと、人間の方が追いつかないので）、この程度ならメモリの圧迫があまり気になりません。

私の使っている環境（Mac）の搭載メモリが多いこともありますが、積極的に乗り換えるモチベーションは低いというのが現時点での感想です。

ある/Aru

IT＆機械学習エンジニア/ファイナンシャルプランナー（CFP®)

XContact

専門分野は並列処理・画像処理・機械学習・ディープラーニング。プログラミング言語はC, C++, Go, Pythonを中心として色々利用。現在は、Kaggle, 競プロなどをしながら悠々自適に活動中 保有資格：CFP, マンション管理士、管理業務主任、宅建士など