Harness は、モデルの外側にある仕事の設計。
OpenCode、Plugins、OmO、Pi、oh-my-pi、Codex。名前を並べるのではなく、どこで実行し、どう引き継ぎ、どう受け入れるかを考える。
研究ノート01
まず Model と Harness を分ける。
モデルの回答能力と、作業環境に何ができるかは別の問題だ。
Harness はモデルを仕事に参加させる外側の仕組みだ。ファイル、編集、Shell、LSP、ブラウザ、権限、Context、分担、報告まで含む。モデルだけがワークフローではない。
同じモデルでも、Harness が違えば読めるファイル、使えるツール、並行実行、確認に戻る場所が変わる。名前の比較だけでは、結果を決める条件を隠してしまう。
先に仕事がどこで終わるかを決め、そのあとでモデルを選ぶ。
- CONTEXT
- 必要な資料をモデルに渡す
- TOOLS
- 読む・直す・実行する手段
- POLICY
- できることと止まる場所を決める
02
Plugin は作業環境をイベントにつなぐ。
OpenCode の Plugin は魔法のボタンではなく、確認できる拡張の境界だ。
OpenCode の公式ドキュメントでは、Plugin は project または global の .opencode/plugins に置け、npm からも読み込める。permission、tool.execute、session、message などのイベントに接続できる。
まず AI に公式ドキュメントを読ませ、Plugin のイベントと制限を平易な言葉に直してもらう。そのうえで、自分が解決したい反復作業を話し合い、どのイベントで介入し、どの Context を読み、いつ確認に戻るかを設計する。
Plugin はすべての能力を開くものではなく、一つの明確な動作を AI に任せる境界だ。小さな試作から始め、差分、権限、出力、Shell 引数、データの範囲を確認してから残す。
- 01
LOAD
project / global / package
- 02
HOOK
決めたイベントで介入する
- 03
REVIEW
差分・権限・出力を見る
03
OmO は編成を広げ、コストも広げる。
複数の Agent が、そのまま良い判断になるわけではない。
oh-my-opencode（資料では oh-my-openagent という名前も使われる）は、OpenCode を複数 Agent、役割、LSP / AST ツール、MCP の組み合わせへ広げる。計画、研究、実装、Review を並行する仕事には魅力がある。
OmO は自分が主に開発で使う作業面だ。複数ファイルの理解、計画、実装、Review が必要なときに仕事を分けて引き継がせる。ただし小さな仕事には厚すぎる。引き継ぎ、設定、実行状態で問題が出たら Codex に切り替え、差分と受け入れ確認を一つの作業面へ戻す。
編成の層が厚くなるほど Context、モデル設定、Hook、権限、失敗経路も増える。OmO は既定のスイッチではなく、まず小さな引き継ぎを試してから広げる作業モードとして扱う。
| 手順 | GAIN | COST | STOP |
|---|---|---|---|
| 並行研究・専門役割・ツール連携 | 含む | 含まない | 含まない |
| 増える Context・権限・引き継ぎ | 含まない | 含む | 含まない |
| 一つの Agent に戻る判断 | 含まない | 含まない | 含む |
04
Pi は Agent を組み立てられる端末へ戻す。
oh-my-pi は IDE のような機能を、組み立てられる核に置く。
OpenCode は、Plugin を project または global の設定から読み込み、イベントやツールを足していける比較的厚い作業台として見ている。Pi は最小の terminal coding harness として core loop を小さく保ち、必要な機能を extension、skill、package で組み立てる方向だ。oh-my-pi はそこへ LSP、AST、Browser、Python、Subagents、SDK、RPC を足す。最初から持つ機能と、使う側が後から組み立てる部分が違う。
DeepSeek Harness は developer preview の研究対象で、モデル、ツール、session、sandbox、loop までを plugin として差し替えられる設計を示している。MiniMax Code は別の方向で、公式リポジトリでは terminal coding agent として、検索、plugin、multimodal tool、既存モデルの接続を一つの作業面にまとめる。どちらも日常開発では使っていないので、ここは資料を読んで整理した設計の比較だ。
自分の場合、GPT 系のモデルは native Harness に戻した方が、プロジェクトの読解からツール呼び出し、差分、受け入れ確認までが一続きになりやすい。Cursor も似ていて、Composer 2.5 と Grok 4.6／4.7 は Cursor の中で使う方がまとまりがよく、外へ出すと Context やツールの引き継ぎで迷うことがある。これは今の自分の使い方から出てきた感想だ。
CORE
Agent loop と端末作業
EXTENSIONS
LSP・AST・Browser・Subagents
OWNERSHIP
設定・更新・互換性
05
Codex は依頼・変更・受け入れを一本につなぐ。
大切なのは、差分が人の手に戻ることだ。
Codex CLI はモデルだけでなく、プロジェクトの読解、編集、コマンド、approval を同じ面に置く。変更を差分とテストへ戻しやすい。
OpenCode、Codex、Pi を置き換えの順位で見ない。Context の渡し方、ツール、権限の停止点、結果の戻り方が違う。
送信、公開、デプロイの前には、人が確認できる停止点を残す。それが Harness の最後の責任だ。
- DIFF
- 何を変えたか
- CHECKS
- どう確認したか
- BOUNDARY
- まだしていないこと
06
日常の主力は、OpenCode と Codex。
他の Harness は、違いを知るために試している。
日常の開発では OpenCode と Codex を使っている。OpenCode は複数ファイルを読み、計画、実装、Review まで続ける主な作業面。Codex は同じプロジェクトで差分、コマンド、テスト、受け入れ確認を一つにつなぎやすい。
Pi、DeepSeek Harness、MiniMax Code などは、どのようにモデルを接続し、Context を保ち、ツールと権限を扱うかを見るための試用だ。主力を置き換えるためではなく、今の道具の良さと限界を理解するために触っている。
Google の Gemini CLI も、Google の OAuth を第三者 Harness がそのまま借りる形には制限がある。第三者の開発環境から使うなら、Google AI Studio の API key や Vertex AI のように、公式に用意された経路を使う必要がある。
- DAILY
- OpenCode / Codex
- STUDY
- Pi / DeepSeek Harness / MiniMax Code
- ACCESS
- 公式 API と権限の境界