この記事ではAIコーディングの新しいハーネスを取り上げます。Vibe Coding・AIコーディング全般の概念は Vibe Codingとは？2026年完全ガイド をご覧ください。
jcodeが3,600星を集めた理由：Claude Codeへの本気の挑戦状
jcode は、ジェレミー・ホワン（1jehuang）が2026年1月に公開したRust製コーディングエージェントハーネスだ。公開からわずか4か月で3,600 stars超、2026年4月30日にはGitHub Daily Trendingにも掲載され、本記事執筆時点（2026-05-05）でも1日に500〜600 stars伸び続けている。
注目される理由は単純だ。jcodeのREADME冒頭にはこう書かれている。
“The next generation coding agent harness to raise the skill ceiling. Built for multi-session workflows, infinite customizability, and performance.”
「スキル天井を上げる次世代コーディングエージェントハーネス」——これは事実上、Claude Code・Codex CLI・Cursor Agentに対する挑戦状だ。そして公開ベンチマークを見る限り、その挑戦は単なる宣伝文句ではない。
ここで重要なのは、jcodeがClaude Codeを置き換えに来ているのではない点だ。jcodeはClaude API・OpenAI API・Geminiなど30以上のLLMプロバイダーをサポートし、Claude Codeのセッションをインポートする「セッション横断レジューム」も備える。つまり、Claude Codeで書いたコードをjcodeで続きから書ける。ハーネスを乗り換える摩擦をゼロにしようとしている——これがjcodeの戦略だ。
Claude Codeにない4つの機能
jcodeの真価は、Claude Codeが現時点で実装していない4機能にある。順番に見ていこう。
1. セマンティック記憶グラフ：トークンを使わずに過去文脈を呼び戻す
jcodeは全ての会話ターンをローカル埋め込みモデル（all-MiniLM-L6-v2）でベクトル化し、petgraph ベースのグラフ構造に保存する。次のターンが始まるとコサイン類似度検索で関連する過去ノードを自動取得し、必要に応じて検証用サイドエージェント（GPT-5.3 Codex Spark等）に妥当性を確認させてからコンテキストに注入する。
ノードとエッジの構造は次の通り。
| 種類 | 内容 |
|---|---|
| Node | Memory（記憶本体）、Tag（タグ）、Cluster（クラスタ） |
| Edge | HasTag、InCluster、RelatesTo {weight}、Supersedes（上書き）、Contradicts（矛盾）、DerivedFrom |
| 検索 | 埋め込みヒット → BFS走査 → サイドエージェントによる検証 |
| 動作モード | 非同期（ターンNの記憶はターンN+1から利用可能） |
Claude CodeでもCLAUDE.mdやMemoryツールで記憶を扱えるが、それらは明示的にツール呼び出しが必要で、毎回コンテキストにロードされるためトークンを消費する。jcodeのセマンティック記憶は ツール呼び出し不要・関連時のみロード のため、長期セッションで威力を発揮する。
“human like memory system which allows the agent to automatically recall relevant information to the conversation without actively calling memory tools or being a token burner”
2. Swarm（エージェント並列）：自動コンフリクト解決つき
同じリポジトリで複数のjcodeエージェントを起動すると、サーバが自動的に管理する。エージェントAがファイルを編集している間にエージェントBがそのファイルを読んでいた場合、サーバはBに「コードがあなたの足元で動いた」と通知する。
Unix socket"] A["🦊 Agent fox
backend修正"] B["🐻 Agent bear
frontend修正"] C["🦉 Agent owl
テスト追加"] Sub1["子Swarm worker 1"] Sub2["子Swarm worker 2"] Server --- A Server --- B Server --- C A -.->|"ファイル変更通知"| B A -.->|"DM/ブロードキャスト"| C A -->|"swarm tool"| Sub1 A -->|"swarm tool"| Sub2
エージェント間にはDM・ブロードキャスト・リポジトリスコープのメッセージングがあり、メインエージェントが子Swarmを自律生成することも可能だ。git worktreesで人力で並列化する必要がなくなる。
これはClaude Codeにない機能だ。Claude Codeでも複数ペインを開けるが、各ペインは互いの存在を知らない。jcodeはサーバ層で並列エージェントの一級サポートを提供する。
3. agent-grep：grepにファイル構造を載せる
jcodeに同梱される agent-grep は、grepの戻り値に関数一覧・行オフセット・ファイル構造を付与してエージェントに返す。さらに、ハーネスレベルで「エージェントが既に読んだ部分」を追跡し、その部分は自動的に切り詰めて返す。
$ agent-grep "validate_token" src/
src/auth.rs:42 fn validate_token(token: &str) -> Result<Claims>
context: [pub fn ..., async fn ...] ← 同ファイル内の他関数も提示
truncated: 既読部分を省略しています（lines 100-200）
src/middleware.rs:15 fn validate_token_middleware(...)
「ファイル全体を読まなくても何が定義されているか分かる」という設計思想で、コンテキストウィンドウの節約効果が大きい。Claude Codeのgrepはファイル名と行のみ返すため、エージェントは本文を読みに行かざるを得ない。
4. セッション横断レジューム：Claude Codeから続きを書く
これがjcodeの最大のフックだ。READMEから引用する。
“Resume sessions from different harnesses. Claude code broke on you? Resume the session from jcode and continue where you left off. Session resume is supported for codex, claude code, opencode, and pi.”
つまり、Claude Codeで作業していたセッションをjcodeで再開できる。逆方向の互換性は保証されないが、ハーネス乗り換えコストを実質ゼロにする戦略だ。
# 過去のセッション一覧を出す
jcode --list-sessions
# 動物名で指定して再開（jcodeはセッションに動物名を割り当てる）
jcode --resume fox
# Claude Codeのセッションを引き継ぐ
jcode --resume --from claude-code
これは Claude Code vs Cursor 2026年比較 で議論した「ハーネスベンダーロックイン問題」への、ハーネス側からの回答だ。
アーキテクチャ：単一サーバ・複数クライアントのデーモン構成
jcodeを「ただのCLIツール」と思って読むと混乱する。実態は Unixソケット経由のクライアント・サーバアーキテクチャ だ。
/run/user/$UID/jcode.sock"] Reg["~/.jcode/servers.json"] Provider["Provider層
Claude / OpenAI / Gemini / 30+"] MCPPool["MCP プール
セッション間で共有"] Memory["セマンティック記憶
petgraph + MiniLM"] S1["🦊 Session fox"] S2["🐻 Session bear"] S3["🦉 Session owl (idle)"] Sock --- Provider Sock --- MCPPool Sock --- Memory Sock --- S1 Sock --- S2 Sock --- S3 end Client1["Client A
(jcode)"] -.->|"Unix socket"| Sock Client2["Client B
(jcode connect)"] -.->|"Unix socket"| Sock iOS["iOS App
(Tailscale経由・予定)"] -.->|"network"| Sock
特徴を整理する。
- 初回
jcode起動時：setsid()でデーモンを完全分離して起動。以降のjcode呼び出しは既存サーバへのクライアント接続になる /reloadコマンド：サーバが同じソケットを保持したまま新バイナリへexec()。クライアントは指数バックオフ（1s→30s）で自動再接続- アイドルタイムアウト：5分間クライアントがゼロなら自動シャットダウン
- MCPプール：複数セッションでMCPサーバを共有（
shared: true指定時）。Claude Codeはセッションごとにspawnする - 命名規則：サーバには形容詞（”blazing”）、各セッションには動物名（”fox”）が付与され、
🔥 blazing 🦊 foxのように表示される
この構成のおかげで、10セッション同時稼働でも追加セッションあたり約10MBのRAMで済む。Claude Codeは追加セッションあたり213MB必要だ（後述の比較表参照）。
Claude Code / Codex CLI / Cursor Agentとの比較
主要なコーディングエージェントハーネス4種を、機能・性能・価格の観点で並べる。
| 項目 | jcode | Claude Code | Codex CLI | Cursor Agent |
|---|---|---|---|---|
| 実装言語 | Rust | Node.js | Node.js | Node.js / Electron |
| ライセンス | MIT | プロプライエタリ | プロプライエタリ | プロプライエタリ |
| 起動時間 | 14ms | 3,437ms | 883ms | 1,950ms |
| RAM（1セッション） | 167MB | 387MB | — | — |
| RAM（10セッション） | 261MB | 2,301MB | 335MB | 1,632MB |
| LLMプロバイダー数 | 30+ | Claudeのみ | OpenAIのみ | 限定 |
| セマンティック記憶 | ✅ ローカル埋め込み | ❌ | ❌ | ❌ |
| エージェント並列（Swarm） | ✅ 自動コンフリクト解決 | ❌ | ❌ | ❌ |
| セッション横断レジューム | ✅ 4ハーネス対応 | ❌（自分のみ） | ❌ | ❌ |
| agent-grep | ✅ | ❌ | ❌ | ❌ |
| 自己改変モード | ✅ | ❌ | ❌ | ❌ |
| MCP対応 | ✅ プール共有 | ✅ | ✅ | 一部 |
| ブラウザ自動化 | ✅ Firefox統合 | ❌ | ❌ | 一部 |
| 公式IDE統合 | TUI／iOSアプリ予定 | TUI／VS Code拡張 | TUI | 専用IDE |
性能差のうち最も衝撃的なのが起動時間245倍と10セッション時のRAM 8.8倍だ。Claude Codeを5〜10セッション開いて使う開発者なら、Apple Silicon Macでも2〜3GBがClaude Codeのために消える。jcodeなら同じ用途で261MBで済む。
ただし機能の成熟度ではClaude Codeが圧倒的に優位だ。jcodeはまだ4か月のプロジェクトで、74のオープンissueを抱える。エンタープライズSLAやサポート、Anthropicが直接運用するビジネス保証はない。
インストールと起動：Homebrew・スクリプト・ソースビルド
公式の導入手段は3つ。
# 1. macOS - Homebrew
brew tap 1jehuang/jcode
brew install jcode
# 2. macOS / Linux - 公式スクリプト
curl -fsSL https://raw.githubusercontent.com/1jehuang/jcode/master/scripts/install.sh | bash
# 3. Windows - PowerShell
irm https://raw.githubusercontent.com/1jehuang/jcode/master/scripts/install.ps1 | iex
cargo install jcode は2026年5月時点で未公開である点に注意。Rustエコシステム標準のインストール経路は使えない。crates.io公開待ちだ。
ソースから入れる場合：
git clone https://github.com/1jehuang/jcode.git
cd jcode
cargo build --release
./scripts/install_release.sh
初回起動とプロバイダー設定：
# プロバイダーログイン（OAuth起動）
jcode login --provider claude
jcode login --provider openai
# 自前のOpenAI互換プロバイダー（vLLM、Ollama等）
jcode provider add my-llm \
--base-url http://192.168.1.50:8000/v1 \
--model Qwen/Qwen3-Coder-30B-A3B-Instruct \
--api-key-stdin \
--set-default
# TUIを起動
jcode
# 単発コマンド実行
jcode run "READMEの誤字を修正してPRを作成"
# 過去セッション再開
jcode --resume fox
# サーバを永続起動して別ターミナルから接続
jcode serve
jcode connect
設定ファイルは ~/.jcode/config.toml、MCPは ~/.jcode/mcp.json。初回起動時に ~/.claude/mcp.json と ~/.codex/config.toml から自動インポートされるので、Claude CodeやCodexユーザーは追加設定なしで始められる。
向いてる人・向いてない人：選択フロー
スペックだけ見るとjcodeに乗り換えたくなるが、現実的にはトレードオフがある。判断フローを示す。
同時稼働するか？"} Q2{"複数LLMプロバイダーを
切り替えたいか？"} Q3{"エンタープライズSLA・
商用サポートが必須か？"} Q4{"Claude API一択で十分？"} Q5{"Vibe Coding/Compose重視か？"} JC["✅ jcode 強く推奨"] JCC["✅ jcode 推奨
（Claude Codeとの併用）"] CC["✅ Claude Code"] CG["⚠️ Claude Code
（jcodeはまだ早い）"] CR["✅ Cursor Agent"] Start --> Q3 Q3 -->|Yes| CG Q3 -->|No| Q1 Q1 -->|Yes| JC Q1 -->|No| Q5 Q5 -->|Yes| CR Q5 -->|No| Q2 Q2 -->|Yes| JCC Q2 -->|No| Q4 Q4 -->|Yes| CC Q4 -->|No| JCC
jcodeが向いている開発者
- 5セッション以上を同時に動かす開発者（メモリ効率の差が決定的）
- ローカルLLM（Ollama、LM Studio、vLLM）とクラウドLLMを混在させたい人
- ハーネスのソースコードを読んで挙動を理解したい人（Rust 12万行、MITライセンス）
- セマンティック記憶やSwarmといった実験的機能を試したいハーネスエンジニアリング志向の人
- パフォーマンスベンチマークを「数字」で確認したい開発者
現時点で向いていない人
- Anthropicの公式サポート・SLA・契約が必要な企業ユーザー
- VS Code・JetBrainsの統合UIに依存している人（jcodeはTUI中心、IDE統合は限定的）
- 学習コストを最小にしたい初心者（ハーネスの概念自体を理解する必要がある）
- TypeScript・Nodeエコシステムの拡張プラグインを多用している人
特にエンタープライズ用途では、Cursor代替の検討対象としてContinueを比較した記事 と同じ判断軸——ライセンス・サポート・既存ワークフロー——が決定的になる。jcodeはこの3軸では現時点で不利だ。
設定ファイルの構造とMCP共有
jcodeを使い始めて最初に戸惑うのは、設定ファイルが3層構造になっている点だ。Claude Codeのようなフラットな構成ではない。
| パス | 役割 |
|---|---|
~/.jcode/config.toml |
プロバイダー定義・既定モデル・サーバ設定 |
~/.jcode/mcp.json |
グローバルMCP（全セッション共通） |
.jcode/mcp.json |
プロジェクト固有MCP（リポジトリに同梱可） |
.claude/mcp.json |
Claude Code互換用フォールバック |
~/.config/jcode/*.env |
プロバイダーごとのAPIキー（gitignoreすべきもの） |
実際の config.toml は次のような構造になる。
[provider]
default_provider = "my-llm"
default_model = "Qwen/Qwen3-Coder-30B-A3B-Instruct"
[providers.my-llm]
type = "openai-compatible"
base_url = "http://192.168.1.50:8000/v1"
api_key_env = "JCODE_PROVIDER_MY_LLM_API_KEY"
default_model = "Qwen/Qwen3-Coder-30B-A3B-Instruct"
[[providers.my-llm.models]]
id = "Qwen/Qwen3-Coder-30B-A3B-Instruct"
context_window = 128000
MCPプール共有を有効にすると、複数セッションが同じMCPサーバプロセスを共有する。shared: true フラグでセッション数によらずMCPサーバは1プロセスで済むため、ファイルシステムMCPやデータベースMCPのリソースを節約できる。
{
"servers": {
"filesystem": {
"command": "/usr/local/bin/mcp-server-filesystem",
"args": ["--root", "/workspace"],
"shared": true
}
}
}
この設計は 「ハーネスもプロバイダーもMCPも、それぞれ独立して入れ替え可能」 というjcodeの哲学を反映している。Claude Codeはハーネス・プロバイダー・MCPがAnthropic製品としてバンドルされるが、jcodeは各層を分離する。自由度と引き換えに学習コストは増える。
なぜいまRust製ハーネスなのか
Node.js製のClaude CodeやCodex CLIで困るのは、長時間使うときのメモリリークとコールドスタートだ。Node.jsのVM起動とJITウォームアップだけで300〜500ms、Claude Codeはさらにビジネスロジックのロードで3秒台に達する。
Rustに置き換えると、起動が1万分の1〜250分の1のオーダーになり、RAMフットプリントも2〜10倍小さくなる。これはRustの言語特性（GC不要、ゼロコスト抽象）の単純な勝利だ。
ただしRust移植にはコストがかかる。ハーネスはLLMプロバイダーごとのAPI差異、MCP仕様、TUI描画、ファイル監視、プロセス管理、OAuth、認証情報のキーチェーン統合——これらすべてを実装する必要がある。jcodeは2026年1月から4か月で12万行のRustコードを書き上げており、開発者ジェレミー・ホワン（1jehuang）は単独で進めているように見える。mermaid-rs-renderer（独自Rust製Mermaidレンダラー、純粋Rust実装で1800倍高速と謳う）や handterm（独自TUI端末ライブラリ）といった周辺ライブラリも自作しているところに、本気度が表れている。
まとめ：ハーネスエンジニアリングの新基準
jcodeは「Claude Codeを置き換える」プロジェクトではなく、「Claude Codeにない実験的機能をRustで先取りする」プロジェクトだ。セマンティック記憶・Swarm・agent-grep・セッション横断レジュームの4機能は、いずれも近い将来Claude CodeやCodex CLIにも実装されてもおかしくない方向性で、その意味でjcodeはハーネスエンジニアリングの試金石になる。
ハーネス自体の評価軸が「どのLLMが使えるか」「補完速度はどうか」から、「セッション間でどれだけ知識が継続するか」「複数エージェントを安全に並列稼働できるか」へとシフトしつつある——その転換点を体現しているのがjcodeだ。
Claude Code vs Cursor比較 で整理したように、ハーネスは「個人の好み」で選ぶフェーズを終え、「同時セッション数」「LLM選択の自由度」「サポート要件」の3軸で技術的に選定するフェーズに入っている。jcodeはその新しい軸を提示した最初のRust製ハーネスだ。今すぐ乗り換えるかどうかは別として、動向を注視する価値があるプロジェクトであることは間違いない。
