ハーネスこそが本質である – パーソナルなエージェントハーネスがソロ開発を強化する方法
TL;DR – ハーネスは、単一の開発者がはるかに低いAIコストでチーム規模の生産性を達成できるための支点である。
パーソナルでモジュール式のLLMハーネス(著者の brayness リポジトリ)は、計画、実行、批判、昇格の各フェーズを調整し、安価なコンシューマーモデルが大部分の作業を担い、フロンティアモデルは高インパクトタスクに限定する。これによりフロンティアモデルの使用量は約75%削減され、ソロプロジェクトが大規模チームの作業と同等の信頼性を持つようになった。
核心的な洞察:ハーネスはLLMを構造化された開発パイプラインに変える
結論: 良く設計されたハーネスは、LLM呼び出しを繰り返し可能な役割(探索、計画者、作業者、批判者、促進者)に抽象化し、開発者は高レベルな意思決定に集中できる一方で、システムが日常的なコーディングを処理する。
- ハーネスは自己完結型のディレクトリ(
brayness/)に存在し、設定(AGENTS.md)、プロンプト、計画、スキル、拡張機能、およびartifacts/サンドボックスを含む。 - 3つのUIフロントエンド(Cursor、Claude、Pi)は同じハーネス状態を共有しており、モデルの切り替えがスムーズである。
- 安価なタスク(例:単純なリファクタリング)を Deepseek‑v4‑flash に委任し、フロンティアモデル(Claude、Fable)を計画や批判に限定することで、著者はフロンティアモデルのトークン消費量を3分の1に削減した。
ハーネスのアーキテクチャ
結論: ハーネスはディレクトリ駆動型で役割ベースのワークフローであり、任意のターミナルやUIから呼び出せる。
brayness/
├── AGENTS.md # 宣言的なスキル定義
├── AGENTS.local.md # ローカルオーバーライド
├── bin/ # 実行可能ラッパー
├── prompts/ # 再利用可能なプロンプトテンプレート
├── plans/ # 複雑な機能のDAG定義
├── skills/ # 高レベルな機能(探索、計画者、…)
├── extensions/ # モデル固有のアダプタ(例:Piブリッジ)
├── artifacts/ # 生成ファイル用のサンドボックス
└── work/ # プロジェクトのソースツリー(realness、blog、…)
- 探索 – コンテキストを収集(開いているバッファ、バウル、インタビュー記録)。
- 計画者 – フロンティアモデルを使ってタスクのDAGを構築する。
- 作業者 – DAGのノードを繰り返し処理し、コンシューマーモデルを呼び出してコードを生成する。
- 批判者 – 2回目のパス(しばしばフロンティアモデル)を実行し、簡素化、テスト、検証を行う。
- 促進者 – 精簡な引き継ぎ(リリースノート、コミュニケーション)をフォーマットし、必要に応じてフロンティアモデルで仕上げを行う。
コスト効率の良いモデル割り当て
結論: 安価なコンシューマーモデル(Deepseek‑v4‑flash)と時折のフロンティアモデルのバーストを組み合わせることで、高コストのトークン使用量を75%削減できる。
- コンシューマータイア – メンテナンスの大部分、単純なリファクタリング、反復的なコード生成を処理する。
- フロンティアタイア – 計画、最初のタスクの種まき(プレウォーク技術)、批判フェーズで、より高い推論品質が求められる場合に使用する。
- 動的切り替え – 著者は、共有されたハーネス状態のおかげで、Cursor、Claude、Piの間をスムーズに切り替えながらワークフローに支障をきたさない。
"私は2つの20ドルのプランでクライアントの対応と自分のプロジェクトの本格的な進捗を両立でき、DeepseekやFableのインジェクションのためにPiに切り替えることもできる。" – Scott Fryxell
実世界の応用:Realness カメラアプリ
結論: poster-driver スクリプトを通じてアプリを公開することで、ハーネスはヘッドレスChromeを駆動し、ベクターグラフィックのポスターを自動生成できる。
- LLMが再利用可能なnpmスクリプト(
npm run make:animation …)を書いたため、ハーネスはこれに追加のトークンコストなしに何十億回も実行できるようになった。 - ファイルシステムAPIアクセス(Braveで有効化)により、ハーネスはクリエイティブ資産を開発者の作業ディレクトリに直接同期できる。
- この統合は、AI強化ツールが単純なWebアプリをプログラマブルなクリエイティブパイプラインに変える可能性を示している。
コミュニティの反応 – 他者からの声
- コスト vs. 速度: あるコメントでは、ソロ開発者が4人で3か月かかるプロジェクトを月500ドルで完了でき、12万ドルの費用を削減できると指摘。フロンティアモデルはスピードのために「明らかに選ぶべき」だと主張している。
"今、私は月4万ドルではなく月500ドルを支払って、同じ成果を3倍速で得ている。"
- モデル多様性への懸念: 一部のユーザーは、1つのプロバイダーに依存することへの懸念を示しており、今後の使用量制限の引き上げによりFableから切り替えざるを得なくなると警告している。
"Anthropicがついに50%の使用量増加を実施したとき…私はワークフローを切り替えざるを得なくなる。"
- シンプルなワークフローの推奨: 複雑な役割分割は過剰設計だと主張するコメントも複数あり。実用的なアプローチは、LLMに簡潔な指示を与えて出力を確認し、必要に応じて変更を求めるというものだ。
"LLMを最も効果的に使う方法は、少し指示を与えてコードを見て、その後変更を求めるということだ。"
- セキュリティとサンドボックス: シェルアクセスを完全に持たないハーネスの構築を提案する声も上がっている。
"なぜ誰も、完全なシェルアクセスを持たないハーネスを作ろうとしていないのか理解できない。それならはるかに安全になる。"
- 一般的な合意: 多くのユーザーが、ハーネスが今や普遍化しており、個人でハーネスを所有できる能力が生産性の大幅な向上につながると共感している。
"今や、ほぼすべての人がハーネスを持っているし、その美しさは、自分だけのバージョンを所有できるということだ。"
開発者への実践的な教訓
- 小さなスタートから: 探索 と 作業者 のみを持つ最小限の
AGENTS.mdを定義し、ボトルネックに直面した時点で 批判者 と 促進者 を追加する。 - 安価なモデルを活用: Deepseek‑v4‑flash(または任意のオープンウェイトモデル)を日常的なコード生成に使い、Claude/Fableは計画や高リスクのリファクタリングに限定する。
artifacts/に状態を永続化: すべての生成ファイルをサンドボックス内に保持することで、メインリポジトリを汚染せず、監査を簡素化できる。- 促進を自動化: 短い「促進」ステップ(例:自動でmarkdown要約を生成)を導入することで、作業の共有が保証され、静かにリリースして忘れられるリスクを低減できる。
- モデル非依存性を維持: ハーネスの背後でモデル呼び出しを抽象化することで、プロバイダー(Cursor ↔ Claude ↔ Pi)を書き換えずに切り替えられる。
今後の方向性
- ファインチューニング & LoRA: コミュニティメンバーは、オープンウェイトモデルにLoRAアダプタを統合することで、独自のパーソナライズが可能になり、プロプライエタリなフロンティアAPIに依存しなくなる可能性を示唆している。
- セキュリティレイヤー: モデル呼び出し前に決定論的な事前チェック(例:静的解析)を追加することで、大規模な破壊的編集のリスクを軽減できる。
- 標準化されたハーネス仕様: より多くの開発者がハーネスを採用するにつれ、
AGENTS.mdとDAG定義の共有スキーマがエコシステムの相互運用性を促進するだろう。
結論: パーソナルなLLMハーネスは、原始的なモデル呼び出しを、規律的でコスト効率の良い開発パイプラインに変換し、ソロ開発者が従来のチームと同等、あるいはそれ以上の生産性を達成できるようにする。
Sources
関連
- プロジェクト
- Dispatch
- Dispatch
- Dispatch
- Dispatch