コーディングエージェントを使っていて、いちばん怖い瞬間はいつでしょうか。多くの人にとって、それは「こちらの意図を確かめないまま、AIがいきなりコードを書き換え始めたとき」です。曖昧な指示を勝手に解釈し、的外れな実装を大量に生成し、何を根拠にそう変更したのかも残らない——この「推測駆動」の事故は、AIに任せる範囲が広がるほど深刻になります。
その事故を構造的に防ごうとするのが、本記事で解説する Gajae-Code（ガジェコード、コマンド名 gjc） です。TypeScript製・MITライセンス・GitHubで約1,300スターを集めるこのオープンソースは、自らを「外部コーディングエージェント・ハーネス」と位置づけます。キャッチコピーは「Encode intention. Decode software.（意図をエンコードし、ソフトウェアをデコードする）」。
Gajae-Codeの肝は、エージェントに deep-interview → ralplan → ultragoal という明示的なワークフローを課し、「推測する前に、聞いて・計画して・証拠を残す」ことを強制する点にあります。しかも Codex・Claude Code・OpenCode といった既存ツールの「隠れプラグイン」にはならず、それらの横で併走する外部ハーネスとして動きます。AIに本気で実装を任せたい開発者にとって、その設計思想と使い方を、公式情報をもとに読み解いていきます。
当サイトのAIエージェント基盤の全体像は AIエージェントフレームワーク比較ガイド2026 でも整理しています。あわせてどうぞ。
- ・Gajae-Code（gjc）は Codex・Claude Code 等の横で動く外部コーディングエージェント・ハーネス。
- ・deep-interview→ralplan→ultragoal で「聞く→計画→証拠つき実行」を強制し、推測駆動の事故を防ぐ。
- ・tmux-backed の並列ワーカー（team）と隔離worktreeで、安全に・並列に作業できる。
- ・4つのワークフロースキル＋4つの役割エージェント（executor/architect/planner/critic）に絞った小さな設計。
- ・0.7.0でTelegram等への通知SDK、0.6.0でrlm（研究/REPLモード）・computer-useを追加。
1. Gajae-Codeとは — 既存エージェントの「横」で動く外部ハーネス
Gajae-Code（gjc）は、あなたが選んだリポジトリやワークツリーから起動する外部のコーディングエージェント・ハーネスです。「ハーネス」とは、当サイトでも繰り返し扱ってきた、エージェントを安全に・構造的に動かすための実行環境一式を指します。LLMそのものでも、コードを書く本体でもなく、その周りを固める「枠組み」——計画を立てさせ、変更を隔離し、何をしたかの証拠を残す、という規律を提供する層です。
公式が強調するのは「意図的に、Codex CLI・Claude Code・OpenCode・Claw Code の隠れプラグインではない」という設計です。これらのツールに同化して中身を書き換えるのではなく、それらの隣で起動して、構造化された計画・永続的な証拠・tmuxベースのワーカー・隔離worktreeを足す——という立ち位置を取ります。
この「外部・併走」という選択が、Gajae-Codeの第一の特徴です。普段使っているコーディングエージェントを捨てる必要はありません。「もっと慎重に、計画と証拠を残しながら進めたい」ときに、その横で gjc を立ち上げる。既存のワークフローを壊さずに、規律だけを足せるのです。導入も一行で済み、bun install -g gajae-code でグローバルに入れたあとは、対象のリポジトリへ移動して gjc を起動するだけです。普段の開発フローに「もう一段の慎重さ」を後付けする感覚に近く、合わなければ使わなければよい、という気軽さも、外部ハーネスという立ち位置ならではの利点です。
・形態：外部から起動するCLIハーネス（gjc）。TypeScript製
・ライセンス：MIT（オープンソース、ただしベータ段階）
・導入：bun install -g gajae-code（スコープ版 @gajae-code/coding-agent も）
・対応OS：Linux（x64/arm64）・Windows（x64）・macOS（Apple Silicon/Intel）
・位置づけ：Codex・Claude Code・OpenCode 等の「横」で併走する外部ハーネス
なお公式は、Gajae-Codeを「実験的・ベータ段階のプロジェクト」と明記しています。荒削りな部分があり、重要な作業で頼る前には出力を検証すべき、という但し書きがある点は、導入前に押さえておくべき正直な前提です。
2. 核心思想 — 「推測する前に、聞いて・計画して・証拠を残す」
Gajae-Codeが解こうとしている問題は、「コーディングエージェントが推測でいきなりコードを書く」ことです。その対策として、gjc は明示的なワークフローを課します。中核は3段階です。
第一段階は deep-interview（深い面談） です。曖昧な要求を、具体的で実装可能な要件へと変換します。「とりあえず作って」を、AIが勝手に解釈して走り出す前に、必要な前提を質問で詰める——この「推測する前に聞く」工程が、後戻りを劇的に減らします。
第二段階は ralplan（計画と批評） です。コードを変更する前に、実装のアプローチそのものをレビューします。計画を立て、その計画を批評し、筋の悪い方針を着手前に潰す。「変更する前に計画する（plan before mutation）」という原則の実装です。
第三段階は ultragoal です。ゴールを追跡し、リビジョン・チェック・完了の証拠を記録しながら実行します。gjc ultragoal create-goals で承認済みの計画からゴールを作り、complete-goals で完了まで進める。「証拠つきで実行する（execute with evidence）」——何を、なぜ、どう変更し、それが正しいと確認できたのか、を残すのです。
そして必要に応じて、第四の team が加わります。tmuxベースのワーカーを協調させ、並列実行が本当に役立つ大きなタスクを分担します。公式も「gjc team ... は、協調する複数ワーカーが本当に役立つときにだけ加える」としており、常時オンにする機能ではなく、タスクの規模に応じて選ぶオプションです。
この4段階を、実際のコマンドに落とすと流れが見えやすくなります。要求を詰める段では対話的に質問が走り、計画が固まったら gjc ultragoal create-goals で承認済みの計画から追跡可能なゴール群を生成し、gjc ultragoal complete-goals で一つずつ完了へ進めます。各ゴールには「何を変えたか・なぜか・どう確認したか」が紐づき、途中で止めても再開できる状態が残ります。つまり「思いつきで書き換えて、あとから何をしたか分からなくなる」という典型的な事故を、コマンドの構造そのもので起こりにくくしているわけです。重要なのは、これらが努力目標やドキュメント上の推奨ではなく、ワークフローを進めるうえで通らざるを得ない「関門」として実装されている点です。
「聞いてから書く」「計画してから変える」「証拠を残す」——どれも当たり前ですが、人間もAIも省略しがちです。Gajae-Codeの価値は、これらを明示的なワークフロー（deep-interview→ralplan→ultragoal）として強制する点にあります。規律を意志に頼らず、仕組みで担保する。これは当サイトで扱った loop-engineering や writing-loop の「停止条件・検証ゲート」とも通じる発想です。
3. 主要機能 — スキル・ロール・tmux・worktree・証拠
Gajae-Codeは、機能を絞り込んだ「小さく強い」設計を掲げています。公式は「肥大化したデフォルトのスキル動物園を作らない。gjcはこの手法をより良くすることで改善する」と明言します。提供されるのは、4つのワークフロースキルと4つの役割エージェントです。
ワークフロースキルは前述の4つ（deep-interview・ralplan・ultragoal・team）。役割エージェントは次の4つで、書き込みできるのは executor だけという権限分離が効いています。
| 役割エージェント | 役割 |
|---|---|
| executor | 範囲を限定した実装・修正・リファクタ（書き込み可） |
| architect | アーキテクチャとコードレビューの評価（読み取り専用） |
| planner | 手順と受け入れ基準の設計（読み取り専用） |
| critic | 計画の批評と実行可能性レビュー（読み取り専用） |
この「実装役と評価役を分ける」構造は、当サイトでも繰り返し取り上げてきた Maker/Checker 分離そのものです。architect・planner・critic は読み取り専用で、勝手にコードを書き換えません。実装は executor に限定される。これにより、レビューと実装が混ざって暴走するのを防ぎます。
なぜこの分離が効くのかというと、コーディングエージェントが暴走する典型パターンが「自分で計画し、自分で実装し、自分で『できた』と判定する」自己完結ループだからです。批評役が実装権限を持つと、指摘した側がそのまま手を入れてしまい、第三者の目が機能しません。Gajae-Codeは architect/planner/critic から書き込み権限を構造的に剥奪することで、「評価する人は書かない、書く人は評価しない」という役割分担を強制します。これは loop-engineering の Evaluator-Optimizer や、当サイトの writing-loop が掲げる「執筆者は自分の合否を判定しない」という原則と、まったく同じ発想です。エージェントの世界でも、品質を担保するのは賢いモデル単体ではなく、役割を分けた構造だという点を、gjc は具体的な権限設計として示しています。
スキルを意図的に絞り込んでいるのも同じ思想の延長です。公式が「肥大化したデフォルトのスキル動物園を作らない」と述べるとおり、たくさんの機能を浅く並べるのではなく、deep-interview→ralplan→ultragoal という一本の太い背骨を磨き込む方針を取っています。機能が少ない分、何を・どの順で使えばよいかが明確で、エージェントの挙動も予測しやすくなります。
加えて、Gajae-Codeは実行基盤として次を備えます。
・tmuxネイティブ実行：gjc --tmux でtmuxバックドのリーダーセッションを起動。team で複数ワーカーを協調
・隔離worktree：gjc --tmux --worktree my-task-branch でリスクのある／レビュー対象の作業を独立したworktreeに隔離
・画像入力：gjc @screenshot.png "何を直す？" のようにCLIで画像を渡せる。TUIではクリップボードからの貼り付けも
・永続的な証拠（receipts）：ゴール・リビジョン・チェック・完了証拠を記録し、後から検証可能に
4. アーキテクチャ — 外部から差し込む規律のレイヤー
Gajae-Codeが、既存のコーディングエージェントとどう噛み合うのかを概念図で整理します。
要求を具体化"] IV --> PL["ralplan
計画＋批評"] PL --> GATE{"計画を承認?"} GATE -->|"NO"| PL GATE -->|"YES"| UG["ultragoal
証拠つき実行"] UG --> TEAM["team（任意）
tmux並列ワーカー"] GJC -.隔離.-> WT["worktree / tmux"] UG --> EV["receipts
証拠を永続化"] TEAM --> CODE["既存エージェントやツールで実装"]
この図が示すのは、Gajae-Codeが「実装の手前と周辺に、規律のレイヤーを差し込む」存在だということです。開発者の指示はまず deep-interview と ralplan を通り、計画が承認されるまでコード変更（ultragoal）に進めません。これは当サイトの create-article ワークフローにある「Editor Gate（ブリーフが通らなければ書き始めない）」と同じ、着手前の停止条件です。
実行は隔離されたworktree／tmuxセッションの中で行われ、結果は receipts として証拠化されます。Gajae-Code自身は必ずしも全てのコードを書くわけではなく、既存のエージェントやツールと併走しながら、計画・隔離・証拠という「壊れやすい部分」を引き受ける——そういう分業の設計です。
この「壊れやすい部分」という表現は重要です。コーディングエージェントを実務に投入したとき、実際に事故が起きるのは「コードを生成する瞬間」よりも、その前後——要求の取り違え、計画なしの着手、変更が本体に直接漏れること、後から検証できないこと——にあります。gjc はまさにこの前後の工程に規律を差し込むので、コード生成の中身は Codex でも Claude Code でも構わない、という割り切りが成立します。言い換えれば、Gajae-Code は「より賢く書くツール」ではなく「安全に・追跡可能に進めるためのレール」であり、どのエンジン（モデルやCLI）を載せても効く中立的な層を狙っている、ということです。だからこそ「隠れプラグインにはならない」という設計判断が一貫します。特定ツールに同化してしまえば、その中立性とレールとしての価値が失われるからです。
5. 新機能 — モバイル通知・rlm・computer-use
Gajae-Codeは活発に開発が進んでおり、近年のリリースで興味深い機能が加わっています。いずれも「エージェントに任せる範囲を広げつつ、人間が要所で介入・検証できる」方向の機能で、本記事の主題である「規律」と一貫しています。
0.7.0：コーディングエージェントへのモバイル回答。設定一度きりの通知SDKと、管理されたTelegramリファレンスdaemonが追加されました。各セッションが loopback WebSocket の発見ファイルと、汎用の action_needed／reply プロトコルを公開し、Telegram・Discord・Slack・モバイルアプリ・ローカルツールが「保留中の問い合わせ」を表示し、回答を端末スクレイピングなしで返せます。エージェントが質問してきたら、スマホから答えて作業を進められるわけです。gjc daemon がボットトークンごとに安全なlong-pollの所有者を1つだけ保ち、新セッションがきれいに接続します。
0.6.0：rlm（研究/REPLモード）。エージェントループ上で動く Jupyter ノートブック風の研究セッションです。共有の永続Pythonカーネルに支えられ、python＋read＋web_search というハードゲートされたツールセットを持ちます。実行結果は .gjc/rlm/<session>/notebook.ipynb に集約され、終了時に report.md を生成。gjc rlm で起動します。
0.6.0：computer-use。実験的な、オプトインのデスクトップ操作ツール面です。ネイティブのスクリーンショット／入力バインディングに支えられ、設定とツール登録でゲートされたうえで、エージェントが画面を見てマウス／キーボードを操作できます。
computer-use のようなデスクトップ操作や、自律的な実行は強力ですが、Gajae-Code自身が「実験的・ベータ」と明言しているとおり、重要な作業では必ず出力を検証してください。隔離worktree・読み取り専用ロール・承認ゲート・receiptsは、その検証を支えるための仕組みです。便利さと安全性はトレードオフであることを忘れずに。
6. どんな人に向くか、他のハーネスとの違い
Gajae-Codeの立ち位置を、近接するツールと比較して整理します。
| 観点 | 素のコーディングエージェント | マルチエージェントIDE（例: Orca） | Gajae-Code（gjc） |
|---|---|---|---|
| 主目的 | 対話しながら実装 | 複数エージェントの艦隊管理 | 計画・証拠・隔離の規律を足す |
| コード変更前のゲート | 基本なし | ツール次第 | deep-interview→ralplan で必須 |
| 証拠の永続化 | 限定的 | 限定的 | receipts で記録 |
| 並列実行 | なし | worktree並列が中心 | tmux team（必要時のみ） |
| 既存ツールとの関係 | それ自体 | 各エージェントを束ねる | 横で併走（同化しない） |
Gajae-Codeが特に向くのは、次のような人々です。
第一に、AIに大きめの実装を任せたいが、推測で突っ走られるのが怖い開発者です。deep-interview と ralplan の承認ゲートが、着手前に方針を固めてくれます。
第二に、作業の証跡（なぜそう変更したか）を残したいチームです。receipts による証拠の永続化は、レビューや後追いで効いてきます。
第三に、tmuxや隔離worktreeでの作業に慣れた開発者です。gjc --tmux --worktree は、リスクのある変更を本体から隔離して試すのに向きます。
第四に、既存のCodex/Claude Codeを捨てたくない人です。Gajae-Codeはそれらに同化せず横で動くため、現在のワークフローを壊さずに規律だけを足せます。
一方で留意点もあります。ベータ段階ゆえの荒削りさ、tmux前提の機能（ネイティブWindowsではWSL推奨）、そして Bun での導入が前提な点です。とはいえ、「小さく強い手法を磨く」という明確な思想と、Maker/Checker分離・承認ゲート・証拠化という堅実な設計は、AIに実装を任せる時代の規律として学ぶ価値があります。
Gajae-Code（gjc）は、コーディングエージェントの「推測でいきなり書く」事故を、deep-interview→ralplan→ultragoal という明示的ワークフローで構造的に防ぐ外部ハーネスです。読み取り専用ロールと書き込み可能なexecutorの分離、計画承認ゲート、receiptsによる証拠化、tmux team の並列、隔離worktree——いずれも「AIに任せつつ、暴走させない」ための実直な仕組みです。Codex/Claude Codeを捨てずに横で併走できるので、いまのワークフローに規律だけを足したい人に向きます。ベータ段階ゆえ検証は必須ですが、その検証を支える設計自体が、このプロジェクトの思想を体現しています。
まとめ
本記事では、外部コーディングエージェント・ハーネス Gajae-Code（gjc） を解説しました。
その本質は、「推測する前に、聞いて・計画して・証拠を残す」という規律を、意志でなくワークフローで強制することにあります。deep-interview で要求を具体化し、ralplan で計画を批評し、承認されて初めて ultragoal が証拠つきで実行する。実装役（executor）と読み取り専用の評価役（architect/planner/critic）を分け、tmux team で並列化し、隔離worktreeとreceiptsで安全性と追跡性を担保する。
そして Codex・Claude Code・OpenCode の「隠れプラグイン」にならず、横で併走する——この「外部ハーネス」という立ち位置が、既存のワークフローを壊さずに規律を足せる柔軟さを生んでいます。
ベータ段階ゆえの荒削りさはありますが、「小さく強い手法を磨く」という思想と、計画・検証・証拠を中心に据えた設計は、AIに実装を任せる時代の規律として示唆に富みます。推測駆動の事故に心当たりがあるなら、bun install -g gajae-code で、まずは deep-interview から試してみてください。
よくある質問（FAQ）
Q1. Gajae-Code（gjc）とは何ですか? Codex・Claude Code・OpenCode などの横で動く、外部のコーディングエージェント・ハーネスです。deep-interview→ralplan→ultragoal という明示的ワークフローで「聞く→計画→証拠つき実行」を強制し、tmux並列ワーカーや隔離worktree、証拠（receipts）の永続化を備えます。TypeScript製・MITライセンス・約1,300スター。
Q2. 既存のCodexやClaude Codeを置き換えるものですか? いいえ。Gajae-Codeは意図的にそれらの「隠れプラグイン」にはならず、横で併走する外部ハーネスとして動きます。今のコーディングエージェントを捨てずに、計画・証拠・隔離といった規律だけを足せます。
Q3. deep-interview→ralplan→ultragoal とは何ですか? gjcの中核ワークフローです。deep-interviewが曖昧な要求を具体的な要件に変換し、ralplanがコード変更前に計画を立てて批評し、ultragoalがゴールを追跡しながら証拠つきで実行・検証します。計画が承認されるまでコード変更に進めない設計です。
Q4. どうやって導入しますか?
Bunで bun install -g gajae-code（または @gajae-code/coding-agent）。Linux・Windows・macOS（Apple Silicon/Intel）に対応し、スタンドアロンのリリースバイナリやソースビルドも選べます。起動は gjc、tmuxセッションは gjc --tmux、隔離worktreeは gjc --tmux --worktree <名前>。
Q5. team（並列実行）はいつ使いますか?
協調する複数ワーカーが本当に役立つ大きなタスクのときだけです。公式も「parallel tmux workers help するときに限り gjc team ... を加える」としており、常用ではなく必要なときの選択肢です。
Q6. 安全に使えますか? Gajae-Codeは実験的・ベータ段階であり、公式も重要な作業では出力の検証を求めています。一方で、読み取り専用の役割エージェント・計画承認ゲート・隔離worktree・receiptsによる証拠化など、安全に使うための仕組みが設計に組み込まれています。computer-useのような強力な機能はオプトインでゲートされています。
参照ソース
・Gajae-Code（Yeachan-Heo/gajae-code 公式リポジトリ） — 本記事が解説した一次情報。ワークフロー・スキル・ロール・インストール手順
・Gajae-Code 公式サイト — クイックスタート・アーキテクチャ・ハーネスノート
・gajae-code（npm） — パッケージ配布元
