役割もモデルも同じままだ。変わったのは動かす CLI だけ。理由は単純で、委譲先が重かったからだ。

重さの正体は3つ

OMP は pi のフォークで機能過多

OMP は Mario Zechner の pi を can1357 がフォークしたもので、IDE 連携、LSP、ブラウザ、デバッガ、サブエージェントなどを足した「全部入り」だ。

調査と実装の委譲先に、これらの機能は要らない。むしろ、設定と拡張の管理コストだけが増える。base の pi で足りる。

設定・権限・状態が CLI ごとに別々

OMP と Codex は別の CLI なので、設定ファイルも権限システムもセッション管理も2本立てになる。旧スキルは「モデルと思考レベルの割り当てを CLI の設定ファイルに頼るな」と明記し、起動時のフラグで固定していた。

そのフラグ自体が CLI ごとに違う体系だった。OMP は --thinking xhigh、Codex は -c model_reasoning_effort=max。同じ「最上位の思考」を、別の名前と別のフラグで指定していた。

動かすとノイズが出る

委譲先を起動すると、拡張の再インストールが走り、警告が並び、権限の確認ダイアログが出る。詳しくは後述の動作確認で触れるが、起動のたびにこれが付きまとうのは地味に重い。

一方、モデルは最初から pi から使えた。opencode-go/deepseek-v4-flash は pi のモデルカタログにあり、gpt-5.6-luna も openai-codex プロバイダ経由で同じものが使える。

つまり重かったのはモデルではなく、CLI の側だった。

CLI でなく役割で固定する

置き換え後の構成はこうなった。オーケストレーターの固定もやめた。初版のスキルは Claude Code と Opus 5 を前提に書いていたが、今は「現在のエージェント」とだけ書く。固定するのは役割とモデルだけだ。

起動コマンドは、こう変わった。

# 変更前
herdr agent start omp --kind omp --pane <pane-id> -- \
  --model opencode-go/deepseek-v4-flash \
  --thinking xhigh

herdr agent start codex --kind codex --pane <pane-id> -- \
  --model gpt-5.6-luna \
  -c model_reasoning_effort=max

# 変更後
herdr agent start explorer --kind pi --pane <pane-id> -- \
  --model opencode-go/deepseek-v4-flash \
  --thinking max \
  --no-autoformat \
  --no-autofix

herdr agent start fixer --kind pi --pane <pane-id> -- \
  --model openai-codex/gpt-5.6-luna \
  --thinking max \
  --no-autoformat \
  --no-autofix

ここで1つ注意したいのが、xhigh と max の関係だ。OMP の xhigh は DeepSeek の reasoning_effort=max にマップされる値で、pi の max も同じ値を指す(DeepSeek API の互換マッピング )。思考レベルが一段上がったわけではない。名前の体系が pi に揃っただけだ。

見送った案: ツールの allowlist による読み取り専用の強制

pi には --tools read,grep,find,ls のように、使えるツールを制限する仕組みがある。調査役の読み取り専用を、プロンプトの指示でなく構造で強制できる。最初はこれを入れるつもりだった。

やめた理由は、allowlist のメンテナンスだ。新しいスキルやツールを追加するたびに、explorer 側にも同じリストを足さないといけなくなる。役割の分離は、引き続きプロンプトの指示で行うことにした。スキルには「explorer は読み取り専用。ファイルの変更は fixer だけ」とだけ書いてある。

動作確認で見つかった3つの問題

切り替えて実際に調査と実装を委譲してみて、3つの問題が見つかった。どれも最終版の構成で解消した。

1. 拡張の起動ごと再インストール

最初の版は、委譲先に専用の拡張構成を指定していた。すると起動のたびに拡張のインストールが走り、136パッケージを9秒かけて入れ直すログと、allow-scripts の警告が並んだ。スキル定義の衝突表示も出た。

対処は、委譲先も通常の pi 構成にすることだ。拡張とスキルの自動ロードに任せ、コマンドから拡張指定を外した。スキルには「委譲先は通常の pi の拡張・スキル・ツールを使う」とだけ書く。これで再インストールも警告も消えた。

2. 権限の確認ダイアログ

pi は本体には権限ダイアログを持たず、pi-permission-system という拡張が allow / ask / deny の判定と確認UIを足している。委譲先でも ask 判定のたびにダイアログが出て、往復が増えた。

これをスキルで回避しようとすると、スキルが肥大化する。設定で解決した。yoloMode: true にして、ask だけ自動承認にする。rm -rf や sudo などの deny ルールは残るので、危険操作の拒否は維持される。

3. herdr agent read に thinking が混ざる

これがいちばん効いた気づきだ。pi は思考ログを端末に書くので、herdr agent read が推論をそのまま拾う。長い調査だと、報告本文の前に思考が混ざり、最終回答の切り出しに注意が要る。

対処として、委譲先の報告を必ず専用ブロックで終わらせるルールをスキルに足した。

<HERDR_RESULT>
結論と根拠
</HERDR_RESULT>

読み手は最後の完全な HERDR_RESULT ブロックだけを引き継ぎ結果として扱い、前の thinking や進行ログは無視する。ブロックが見えない場合は、作業をやり直させず最終回答だけを再出力させる。長すぎる調査報告も、調査の再実行ではなく短いブロックの再出力で対応する。

残る制約

切り替え後、このスキルを前提にした continuous-improvement-loop を作り、laravel-encrypted-s3 を v1.0.0-RC3 まで改善した。

調査と実装の委譲は、その自律改善ループの中で実際に回っている。

ただ、切り替えてからまだ1日だ。この記事で報告できるのは、動作確認で見つけた3つの問題と対処までで、長期運用の実績はまだない。

thinking の混入はブロック規約で回避しているが、オーケストレーターが読み取るコスト自体は残る。前回の記事で書いた「ハブ&スポークのボトルネック」と「実装の待機時間」も、そのままだ。

委譲先を選ぶときの基準

スキルは j1nn0/skills で公開している。

npx skills@latest add j1nn0/skills -s agent-orchestration

今回の変更で得た基準は一つ。「委譲先は、CLI の機能の多さで選ばない。役割とモデルを固定できるかで選ぶ」。調査と実装に必要なのは、モデルの指定と思考レベルの指定が確実に効くことだけだ。その2つが固定できるなら、CLI はオーケストレーターと同じ1本でいい。