jcode

jcodeを選ぶ理由

jcode は AI コーディングをモデルではなく、その実行を支える基盤の問題として捉えています。開発環境を特定のモデルファミリーに結びつけず、エージェント実行環境と推論を分離しています。そのため、認証方法、提供元、モデルを変更したり、推論をローカルマシンに移したりしても、同じターミナルのワークフローを維持できます。

特徴的なのが、永続的なサーバー・クライアント構成です。jcode のデーモンがセッションを管理し、ターミナルクライアントが接続・切断しても作業を続行できます。ターミナルの各プロセスが独立したエージェントになる方式とは使い勝手が異なります。時間のかかる作業はワークステーションやリモートサーバーで継続し、別の作業は会話の終了を待たずに新しいセッションで進められます。

一つのコーディングアシスタントに順番に質問する使い方から先へ進んだ開発者には、特に意味のある設計です。jcode は、複数のエージェントが異なる作業の調査、実装、テスト、レビューを同時に進めることを前提に最適化されています。

プロジェクトは起動時間やセッション追加時のメモリ使用量など、実行時の詳しい測定結果も公開しています。開発側が何を最適化しているかを知るうえで参考になりますが、独立した性能保証ではなく、開発元によるベンチマークとして読む必要があります。

基本的な作業の流れ

最も簡単な使い方は一般的なコーディングエージェントと同じで、リポジトリを開いてターミナル UI を起動します。

jcode

対話画面が不要なタスクでは、同じ基盤をヘッドレスモードで実行できます。

jcode run "inspect the authentication flow and identify possible race conditions"

エージェントのプロセスを表示用ターミナルから分離すると、この構成の利点がより明確になります。永続デーモンを一度起動しておけば、後からクライアントを接続できます。

jcode serve
jcode connect

この方式では、コーディングエージェントを継続稼働するワーカーのように扱えます。一つのセッションにテスト失敗への対応、別のセッションにリファクタリング、さらに別のセッションに調査を任せ、三つの作業を一つの会話で順番に処理せずに済みます。

リポジトリ固有のルールは AGENTS.md にまとめるのが適切です。jcode はマシン全体の ~/AGENTS.md も読み込むため、リポジトリをまたいで使う個人のルールを設定できます。プロジェクトのルールはリポジトリ内に、個人の既定値はグローバル設定に置く、という分離を保つとよいでしょう。

長い会話では、/fork、/transfer、/rewind を使い分けて、膨らみすぎたコンテキストに対処できます。二つの方針を別々に試すなら分岐、作業は続けたいものの会話の蓄積で費用やノイズが増えたなら引き継ぎ、直近のやり取りで方向を誤ったなら巻き戻しが適しています。

活用例

従来の単一エージェントによるセッションだけでは、jcode の設計を十分に活かせません。並列で進める作業が増えるほど、この構成が役立ちます。

中規模のリポジトリでは、実装と検証を分ける方法が実用的です。一つのセッションでコードを変更し、別のセッションで変更箇所をレビューしたり、失敗したテストを調査したりできます。バックグラウンドのコマンドは実行を続けられるため、作業中のエージェントが何度もビルド状況を確認してターンを消費せずに済みます。

リモート開発にも向いています。実際のセッションとツールはデーモンが管理するため、ソースコードがあるデスクトップ、ホームラボのサーバー、クラウド VM 上で jcode を実行できます。追加のネットワークサービスを公開するより、SSH と tmux を組み合わせるシンプルな構成のほうが把握しやすいでしょう。

ssh mybox
tmux new -A -s jcode
jcode

これにより、ファイル操作、シェルコマンド、Git 操作、モデルの制御をリモートのチェックアウト先で実行できます。上級者は jcode のソケットを転送し、ローカルクライアントをリモートデーモンに接続することもできます。

サブスクリプションの利用枠を使い切りがちな開発者や、複数のモデルファミリーを試す開発者には、プロバイダーの抽象化も役立ちます。推論の接続先を変えても実行基盤を変更する必要はありません。OAuth によるサブスクリプション、API プロバイダー、OpenAI 互換サービス、ローカル環境を切り替えても、エージェント環境はほぼそのまま使えます。

TypeScript SDK と api-bridge により、プログラムからワークフローを制御できます。jcode は対話型 TUI にとどまらず、スクリプトや社内開発ツールに組み込むエージェント実行環境にもなります。

他のツールとの比較

jcode を Claude Code、Codex CLI、Gemini CLI、OpenCode、Aider と比較する際、どのモデルが最も良い答えを出すかだけでは十分ではありません。モデルは jcode と切り離して変更できる場合が多いため、長く使ううえではモデルを取り巻く実行基盤の比較が重要です。

特定の AI 提供元と密接に連携した公式エージェントを好むなら、Claude Code、Codex CLI、Gemini CLI は自然な選択です。特定ベンダーの既定の使い方よりも、複数の提供元で一貫したワークフローを維持したいなら、jcode が魅力的になります。

オープンソースとモデル選択の柔軟性を重視する開発者には、OpenCode や Aider のほうが近い比較対象です。その場合、jcode を選ぶ判断材料は、永続デーモンのセッション、組み込みメモリ、並列オーケストレーション、リモート接続、移行互換性、実行基盤をどこまでカスタマイズしたいか、といった構成上の違いになります。

多くのエージェントセッションを常時維持する場合、jcode の公開するリソース測定値も参考になります。プロジェクトはセッション追加時のメモリ増加量を特に最適化しています。ただし、普段一つのエージェントしか使わない人には重要度が低く、導入や移行の判断を常に左右する要素ではありません。

おすすめの構成

jcode は、設定できる機能をすべて使うより、シンプルに始めるほうがよいでしょう。まず信頼できる提供元とリポジトリの指示を用意し、実際の課題を解決する必要が生じてからメモリ、MCP サーバー、並列エージェントを追加します。

たとえば、控えめな構成では既定のプロバイダーを指定し、オーケストレーションは必要なときだけ有効にします。

[provider]
default_provider = "openai"

[features]
memory = true
swarm = false

MCP 連携で、ほかの貢献者も同じツールを使う必要がある場合、プロジェクト固有のサーバーはグローバル設定より .jcode/mcp.json に置くのが適切です。グローバルな MCP 設定は、どのプロジェクトでも使う個人用ユーティリティに使うとよいでしょう。

ローカル推論では、ホスト型の最先端モデルを使うとき以上にモデル選びが重要です。jcode はローカルエンドポイントに、特にストリーミング応答やツール・関数呼び出しなど、エージェントに必要な機能を求めます。会話でのコード生成が得意でも、ツール利用が不安定なモデルでは、エージェントとしての使い勝手が大きく下がる場合があります。

Swarm の同時実行数も、単に最大にするのではなく意図的に増やすべきです。並列エージェントは処理量を増やせますが、推論消費も増え、二つのワーカーがリポジトリの同じ領域を変更する可能性も高まります。最適な設定は CPU や RAM だけでなく、タスクの独立性とモデルの費用にも左右されます。

移行時の注意点

jcode は、既存のコーディングエージェントの利用者が負担を抑えて試せるよう、複数の互換機能を用意しています。

Claude Code ユーザーは MCP を移行しやすくなっています。jcode は Claude Code のユーザー設定とリポジトリ設定を直接読み込めるため、コピーを別途維持する必要がありません。互換性のある Claude 設定への変更は、そのまま jcode からも参照できます。

Codex CLI の場合は動作が異なります。jcode 独自の MCP 設定がまだなければ、Codex の設定から一度だけインポートできます。その後の jcode 設定ファイルは独立して管理されるため、Codex 側の変更が自動同期されるとは考えないでください。

既存のスキル集も、作り直さずに再利用しやすくなっています。jcode は独自の SKILL.md ディレクトリを認識し、Claude Code のプラグインディレクトリからもスキルを読み込めます。

進行中の作業を捨てずに jcode を評価する場合、セッション移行が便利です。Claude Code、Codex、OpenCode、pi のセッション再開に対応しています。別の実行基盤で始めたタスクを jcode に引き継ぎ、実行環境やオーケストレーションの挙動を試せるため、比較しながら評価しやすくなります。

移行は段階的に進めるのが安全です。元のコーディングエージェントを残し、互換性のあるプロジェクト指示や連携を適宜 jcode で再利用しながら、少数の実タスクを移してからチームの既定のワークフローを変えます。ベンチマークだけに頼らず、実際のリポジトリで編集、ツール実行、コンテキスト処理、モデルのルーティングの違いを確認できます。