ターミナルはもはや単なるShellではない：HerdrとFreshのランタイムアーキテクチャ深層解剖

🎥 動画を視聴する（YouTube）

ここ1年の間に、ローカル開発機上で自律型コーディングエージェント（Autonomous Coding Agents）を常時走らせる開発スタイルは、たまの実験ではなく、私の日常的なコード執筆の標準になりました。ある火曜日の午後、私のターミナルではHermesがバックグラウンドでデータベースクライアントをリファクタリングし、Claude Codeが隔離されたGitワークツリーで統合テスト群を走らせ、OpenCodeが新規APIの回帰テストを生成している……といった光景が当たり前になっています。

しかし、このマルチエージェント運用を続けるうちに、古くからある「見えない壁」にぶつかることになりました。従来のターミナルエミュレータが抱える設計限界です。

Windows Terminal、iTerm2、あるいはAlacrittyといった従来のターミナルエミュレータは、数十年前に「1人の人間が1つのShellと対話する」前提で設計されたものです。しかし、複数の自律型エージェントに作業を分散させた瞬間、この旧来モデルは崩壊します。どのアドバイザーが作業を完了したのか、どれがアサーションエラーでクラッシュしたのか、どれが対話的なAPIキー入力待ちで止まっているのかが一目でわかりません。エージェントが「修正した5個のファイル」を人間に確認してほしいとき、彼らにできるのは stdout にファイルパスの羅列を吐き出し、人間に手動でエディタにコピペさせることだけでした。

この構造的ボトルネックに対し、Rustエコシステムから全く異なる、しかし同様に先鋭的な答えを提示する2つの新興プロジェクトが登場しました：

  1. Herdr (herdr.dev)：自律型コーディングエージェントの生息地（Habitat）としてゼロから設計された、ターミナルマルチプレクサ兼バックグラウンドプロセス管理ランタイム。
  2. Fresh (getfresh.dev)：VS Code級の現代的編集体験とLSPをターミナル内にそのまま持ち込む、ゼロコンフィグのテキストエディタ兼ターミナルIDE。

両者はどちらも「ターミナルを単なる文字の格子ではなく、アプリケーションの実行基盤（Application Runtime）として扱う」という共通思想を持っています。しかし、そのアプローチは正反対のベクトルを向いています。両プロジェクトのアーキテクチャを13の工学的メタ次元で比較解剖し、さらにWindows名前付きパイプ（Named Pipe IPC）を通じて外部エージェントからFreshエディタを遠隔操作した実証記録をお届けします。

Herdr vs Fresh ターミナルランタイムアーキテクチャ比較

1. 同じ課題に対する2つの異なるアプローチ

HerdrとFreshのドキュメントと設計思想を注意深く紐解くと、そのコントラストは極めて鮮明です：

                  ┌──────────────────────────────────────────────┐
                  │       ターミナルをアプリのランタイムと見なす       │
                  └──────────────────────┬───────────────────────┘
                                         │
                 ┌───────────────────────┴───────────────────────┐
                 ▼                                               ▼
       [ HERDR: エージェントの生息地 ]                 [ FRESH: 人間のための作業台 ]
       ホスト単位：OSプロセス (Process)                ホスト単位：文書バッファ (Buffer)
       主たるアクター：AIエージェント                  主たるアクター：人間のエンジニア
       主目標：複数プロセスの協調と可観測性            主目標：ターミナル内での快適なコード編集
       "Run them anywhere. Leave them running."       "Zero configuration. No learning curve."

Herdr：エージェントのための群れ（Herd）の生息地

Herdrは、エージェント運用に特化したターミナルマルチプレクサ（tmux / zellij の進化系）として位置付けられています。ローカル環境にはすでに多数のエージェントが並行して活動している、という前提に立ちます。

  • メンタルモデル：PTY（擬似端末）のライフサイクルを完全に掌握するバックグラウンドServerと、着脱自在なTUIクライアントの分離設計。ノートPCを閉じても、クライアントを終了しても、バックグラウンドServerと子プロセス群は元の状態で稼働し続けます。
  • ホストの最小単位：OSプロセス（独立したターミナルPane）。
  • 核となる一級市民：エージェント（Agent）。Herdrはエージェントを明示的な5状態ライフサイクル・ステートマシン（working、blocked、done、idle、unknown）としてネイティブ認識し、監視します。
  • 運営主体：商用スタートアップ（シードラウンドで600万ドルを調達、クラウド版ウェイトリスト展開中）。

Fresh：人間のエンジニアに向けたターミナルIDE

Freshはこれとは対照的に、「エージェント時代であっても、人間がコードを書き、差分を読み、リファクタリングするための超高速で快適なエディタがターミナル内に必要だ」という立場をとります。

  • メンタルモデル：crossterm と ratatui 上に構築された最新鋭のエディタ。マルチカーソル、Ctrl+P によるコマンドパレット、マウスによる直感的な選択やドラッグ、設定GUIを、設定ファイルの泥沼なしにターミナル内で再現します。
  • ホストの最小単位：ドキュメントバッファ（Buffer + View）。内部データ構造には高速なPiece Tree（ピースツリー）とテキスト区間木を採用しています。
  • 拡張ランタイム：重厚なV8を排除し、QuickJS と oxc（Rust製JS/TSパーサー）による軽量TypeScriptランタイムを内蔵。
  • オープンソース基盤：Noam Lewis氏による独立系OSSプロジェクト（GPL-3.0-or-later）。

2. 13の工学的メタ次元によるアーキテクチャ比較

表面的な機能リストの比較にとどまらず、両者の設計思想を13のシステム工学的メタ次元に正規化して整理しました。

# 比較メタ次元 Herdr Fresh
01 基本ポジショニング エージェント向けランタイム / ターミナルマルチプレクサ ターミナルテキストエディタ / ターミナルIDE
02 並行性・基盤設計 ServerがPTYを独占管理、クライアント即時切断可能、Windows ConPTY完全対応 メイン描画ループ + Tokio非同期タスク + 独立QuickJSスレッド
03 概念的最小単位 Pane（OSレベルのターミナルPTYプロセス） Buffer + View（文書データと表示ビューの完全分離）
04 エージェントの扱い 一級市民（First-class）：5状態ステートマシン内蔵、遠隔マニフェスト動的適用 通常プロセス：OrchestratorによりGitワークツリー単位で管理
05 自動化・操作API Socket / 名前付きパイプCLI（herdr agent prompt, wait-output） fresh --cmd script run（TypeScript）および daemon open-file
06 永続化と復旧性 プロセス生存：クライアント切断耐性、OS再起動時のスナップショット復元 コンテンツ生存：デーモンモード（fresh -a）、Hot Exit（未保存自動復旧）
07 リモート・複数ホスト マシン統合：ローカルUIが遠隔SSHホストのPane群とクリップボードを一元集約 ファイルトンネリング：SSH/Python3経由のリモート編集、devcontainer直結
08 拡張機能ランタイム 多言語CLIバイナリ（宣言的 herdr-plugin.toml による契約） 組み込みQuickJS（rquickjs 0.11）+ oxc TypeScriptパーサー
09 サンドボックス保護 なし（プラグインはホストユーザー権限で直接実行） QuickJSサンドボックス + Workspace Trustによる明示的保護
10 設定と操作体系 TOML設定、プレフィックスキー（Ctrl+B）、マウスネイティブ対応 JSON設定（config.json）、モードレスキーバインド、GUIパレット
11 配布と導入形態 公式Shell/PowerShellスクリプト、Homebrew、Nix スタティックmusl単一バイナリ（自己更新内蔵）、winget、cargo、各種Linux
12 ガバナンスと商用性 VC出資の商用スタートアップ（600万ドル調達、クラウド連携） 個人開発の純粋OSS（Noam Lewis氏、GPL-3.0-or-later）
13 現在の成熟度 バージョン≥0.7、極めて速い開発サイクル、Windows正式対応 バージョン0.3.x、エディタコアは極めて堅牢、プラグインAPI実装率約61%

概念用語の対応関係

両者のアーキテクチャ用語を並べて比較すると、驚くほど構造的な共通項が見えてきます：

          HERDR の中核概念                       FRESH の中核概念
       ┌────────────────────┐               ┌────────────────────┐
       │     Workspace      │ ◄───────────► │ Workspace / Window │
       ├────────────────────┤               ├────────────────────┤
       │     Tab (View)     │ ◄───────────► │    Split / Tab     │
       ├────────────────────┤               ├────────────────────┤
       │    Pane (PTY)      │ ◄───────────► │   Buffer + View    │
       ├────────────────────┤               ├────────────────────┤
       │  Session (Server)  │ ◄───────────► │   Daemon (Server)  │
       ├────────────────────┤               ├────────────────────┤
       │  Agent (一級市民)  │ ◄───────────► │  (なし / 通常プロセス) │
       └────────────────────┘               └────────────────────┘

Herdrの Pane を Fresh の分割画面 Split、Session を Fresh の Daemon と読み替えれば、骨格はほぼ1対1に対応します。唯一にして決定的な分岐点は、Herdrが「エージェントを自律的なライフサイクルを持つ独立体」としてモデル化しているのに対し、Freshは「エディタの画面と文書バッファ」に主眼を置いている点です。

3. 実践検証：外部エージェントから名前付きパイプでFreshを遠隔操作する

マルチプロセスの大局的なオーケストレーションをHerdrが担う一方で、Freshは開発者の目の前に最高峰のTUIエディタ画面を提供します。しかし、AI駆動型開発において最大のボトルネックになりやすいのが「コードレビューにおける認知摩擦」です：

「トランシーバー vs 放送調整室」の構造的課題

  1. 従来のサブシェル＝トランシーバーの限界：
    通常のエージェント（run_command や bash、PowerShellサブプロセス）は、標準入出力がリダイレクトされた隔離サブシェル内で動きます。エージェントは、人間の画面上で今どのファイルが開かれ、カーソルがどこにあるかを一切知ることができません。修正箇所のレビューを促す際も、端末上にファイルパスを書き連ねて呼びかける（＝トランシーバーで話しかける）ことしかできません。
  2. Freshのデーモン構造＝投函口付きの放送調整室：
    Freshをデーモンモード（fresh -a またはバックグラウンドセッション）で起動すると、エディタは放送調整室のように振る舞います。端末の2Dレンダリングバッファをディスクに常時ストリーミングしつつ、Windows名前付きパイプ（\\.\pipe\fresh-<SESSION>.ctrl）を開いて構造化JSON-RPCコマンドを常時待ち受けます。

セキュリティ境界とオープンな連携チャネル

Freshには内蔵のTypeScriptスクリプトエンジン（fresh --cmd script run）があり、366種類ものエディタ内部APIを実行できます。しかし、セキュリティ保護の観点から、任意スクリプトの実行には内部権限トークン（$FRESH_CMD_TOKEN）が必須となっています。外部の未認証シェルが呼び出すと、即座に拒絶されます：

Error: no capability token: script evaluation is not authorized

これにより、悪意あるバックグラウンドスクリプトや不正なプロセスがエディタを勝手に操作するのを防いでいます。

しかしFreshには、意図的に認証なしで開放されている標準コマンドが存在します。それが fresh --cmd daemon open-file です。このコマンドはCapability Tokenを一切要求しません。外部のスクリプトやAIエージェントが、安全にファイルを開き、行範囲を指定し、人間のエディタ画面上にインラインMarkdown注釈を表示させることができます。

実際の開発シーンにおけるコード検索・レビューは、大きく2つのパターンに分かれます。私たちはその両方に対応する自動化パターンを検証・確立しました。

                         コード検索で結果がヒット
                                    │
                  ヒット箇所は1ファイルか、複数ファイルか？
                                  /   \
                    複数ファイル  /     \ 1ファイル内に複数箇所
                                ▼       ▼
                         [ パターン1 ]  [ パターン2 ]
                       daemon open-file .fresh-tour.json
                        複数タブ一括展開 コードツアー案内

パターン1：複数ファイルの一括展開（3〜5ファイル、各1箇所の重要箇所）

発生する課題

ユーザーが「MemPalace v2のハイブリッド検索がどのように組み込まれているか調べてほしい」とエージェントに依頼したとします。該当する重要箇所は、設定ファイル、実装モジュール、設計Wiki、ADR（意思決定記録）の4ファイルに散らばっています。

エージェントがこれらを1つずつ順番に開いてユーザーの確認を待っていては、作業のテンポが大きく削がれてしまいます。

技術的解決策

エージェントは daemon open-file コマンドをバッチ形式で1行にまとめ、すべての対象ファイル・行範囲・Markdown注釈を同時にFreshデーモンへ送信します。

運用の鉄則：自動化パイプラインでは、原則として --wait フラグを渡してはなりません。--wait を付けると、ユーザーがエディタ側でタブを閉じるまで外部エージェントの呼び出しスレッドが永久にブロックされてしまいます。

fresh.exe --cmd daemon open-file default `
  'AGENTS.md:70-92@"**ワークスペース規約**\nMemPalace v2 ハイブリッド検索の必須運用ルール。"' `
  'pyproject.toml:35-45@"**依存関係固定**\nmempalace の Git リビジョンピン留め設定。"' `
  'wiki/mempalace-v2-hybrid-retrieval.md:1-30@"**アーキテクチャ**\n3層ハイブリッド検索の設計概念とRRF統合式。"' `
  'docs/decisions/ADR-009-sqlite-hybrid-retrieval-for-mempalace.md:20-50@"**設計判断記録**\nDuckDBからSQLiteへ全面移行した決定背景。"'

画面上で起きること

  1. 左側ターミナルで作業するエージェントが、簡潔な検索分析結果を出力します。
  2. 右側ターミナルのFresh画面上で、4つのタブが一瞬で同時に開きます。
  3. 各タブは指定された行番号（70-92、35-45など）に自動スクロールし、対象コードブロックを視覚的にハイライトした上で、その役割を説明するMarkdownカード（@"..."）をインライン表示します。
  4. 開発者は手動でファイルを探す手間なく、即座にレビューに入ることができます。

Fresh 外部エージェントによる複数タブ一括展開と行ハイライト

パターン2：単一ファイル内の深掘り巡遊（同一ファイル内の複数重要箇所）

発生する課題

ユーザーが300行を超える単一のアーキテクチャ設計書（docs/terminal_orchestration.md）の内容を精読したいケースです。エージェントはこの文書の中から、特に重要な3つのセクションを検出しました。

ここでエディタの物理的な制約が発生します。テキストエディタのバッファは、ある瞬間に1つのスクロール位置しか保持できません。

  • エージェントが4箇所の行範囲を一度に送信すると、エディタは最後のヒット箇所（第4セクション）へ一気にスクロールしてしまい、ユーザーは第1〜第3セクションを見落とします。
  • かといって --wait を付けて1箇所ずつ送れば、エージェント側が1ステップごとに完全に停止してしまいます。

技術的解決策：Guided Code Tour（.fresh-tour.json）

Freshにはネイティブな Code Tour（コード巡遊） エンジンが組み込まれています。単一ファイル内の複数箇所を案内する場合、エージェントはワークスペース直下に一時的な .fresh-tour.json マニフェストを生成し、第1ステップのみを開いてユーザーにツアー機能の利用を促します。

エージェントが動的に書き出すツアー定義ファイル：

{
  "title": "Terminal Orchestration Architecture Tour",
  "description": "docs/terminal_orchestration.md の詳細ウォークスルー",
  "schema_version": "1.0",
  "steps": [
    {
      "step_id": 1,
      "title": "IPC Architecture & Named Pipes",
      "file_path": "docs/terminal_orchestration.md",
      "lines": [7, 26],
      "explanation": "## IPC アーキテクチャ\nデーモンのライフサイクル、Windows 名前付きパイプ (\\\\.\\pipe\\fresh-*.ctrl)、ゼロ遅延ディスクバッファ機構の解説。",
      "overlay_config": {
        "type": "block",
        "focus_mode": true
      }
    },
    {
      "step_id": 2,
      "title": "Decision Matrix: Direct vs. Fresh",
      "file_path": "docs/terminal_orchestration.md",
      "lines": [28, 54],
      "explanation": "## 判断マトリクス\n直接サブシェル `run_command` を使うべき場面と、`fresh` マルチプレクサを使うべき場面の判定基準。",
      "overlay_config": {
        "type": "block",
        "focus_mode": true
      }
    },
    {
      "step_id": 3,
      "title": "Capability Security Boundary",
      "file_path": "docs/terminal_orchestration.md",
      "lines": [56, 85],
      "explanation": "## セキュリティ境界\nスクリプト評価に `$FRESH_CMD_TOKEN` が必須である理由と、`daemon open-file` が外部連携用に開放されている仕組み。",
      "overlay_config": {
        "type": "block",
        "focus_mode": true
      }
    }
  ]
}

マニフェストを書き出した後、エージェントは第1ステップのフォーカスのみをトリガーします：

fresh.exe --cmd daemon open-file default 'docs/terminal_orchestration.md:7-26@"**Step 1 of 3: IPC Architecture**\nCtrl+P を押し \"Tour: Open Workspace Tour...\" を選択するとガイド付き巡遊が開始されます。"'

画面上で起きること

  1. Freshが第1ステップのコード範囲にスクロールし、フォーカスオーバーレイを適用します。
  2. ユーザーが Ctrl+P から Tour: Open Workspace Tour... を呼び出すと、サイドバーにクリック可能な巡遊レールが表示されます。
  3. ユーザーは自分のペースでキーボードの矢印キーを使い、文脈を失うことなく複雑な設計をステップバイステップで読み進めることができます。

Fresh 単一ファイル対話型コード導覧と Utility Dock

4. 実践的な選定指針：どちらをいつ使うべきか？

両方のランタイムを徹底的に使い倒した結果、選定の基準は非常に明快になりました：

                                 あなたの直面している課題
                                            │
        ┌───────────────────────────────────┴───────────────────────────────────┐
        ▼                                                                       ▼
[ 複数エージェントの統括と状態監視 ]                                    [ ターミナル内での高品質なコード編集 ]
- 5〜20個の自律エージェントを常時並行稼働させる                         - LSP補全、定義ジャンプ、マルチカーソルが必要
- 誰がブロックされているかをダッシュボードで即座に把握したい            - Git差分の精査やASTシンボル構造を探索したい
- 再起動や回線切断後もプロセスの稼働状態を維持したい                    - 外部エージェントに画面上のコードを遠隔ハイライトさせたい
- 複数リモートサーバーやモバイル端末から一括管理したい                  - 設定不要、単一バイナリでどこでも即座に動かしたい
        │                                                                       │
        ▼                                                                       ▼
     HERDR を選択                                                            FRESH を選択

推奨されるハイブリッド多層構成

HerdrとFreshは排他的な競合関係ではありません。むしろ、ツールチェーンの異なるレイヤーとして美しく重ね合わせることができます：

  • 外層基盤としての Herdr：ローカル端末のバックグラウンド基盤としてHerdrを常駐させます。エージェントたちのプロセスを統括し、Gitワークツリーごとに作業空間を分離し、サイドバーで全体の健康状態（working / blocked / done）を一元監視します。
  • 内層作業台としての Fresh：人間の介入が必要なコードレビュー、設定ファイルの編集、あるいはエージェントからのコードツアーを受け取る際、Herdrの特定Pane内でFreshを立ち上げます。

この構成を採ることで、マルチエージェント運用の高い可観測性を享受しつつ、ターミナルエディタとしての極上の操作性を一切犠牲にせずに済みます。

5. 総括

ターミナルを単なる文字の入出力ストリームから構造化されたアプリケーションランタイムへと進化させる試みは、人間とAIエージェントの協調開発のあり方を根本から変えつつあります。

エージェントが stdout の壁に閉じ込められている限り、コードレビューのたびに人間の手動コピペという摩擦が発生します。しかし、ターミナルがIPC制御バスとデーモン構造を備えた瞬間、エージェントは「画面上のコードを指差しながら人間と議論できる本物の同僚」へと進化します。

プロセスの生息地を極めるHerdrであれ、テキスト編集の極致を目指すFreshであれ、両者が切り拓いた地平は共通しています。ターミナルはもはや単にShellを叩く場所ではなく、次世代の開発ツールが躍動するプラットフォームそのものになったのです。