コーディングエージェント主体に実装の進め方を変え始めている話

こんにちは。LayerX Ai Workforce 事業部 FDE部 エンジニアの古濵（@furu）です。

ここ数ヶ月で、実装の進め方を少しずつ変えています。**

以前はエディタのウィンドウを複数開き、それぞれで別のタスクを進めていました。

しかし、複数のタスクを並列に進めると、どのウィンドウで何をしていたか分からなくなり、切り替えるたびに読み直しも発生します。

体感では忙しいのに、本当に能率が上がっているのかは疑わしい、という状態でした。

そこで、もっとコーディングエージェント主体に実装の進め方を変えられないかと思い始めました。

複数のエージェントを 1 つのターミナルでまとめ、外から状態の確認や指示の送信ができる `herdr` を使用し、エージェント主体の開発ができるよう整備を始めました。

全体の流れ

先に、3 つの段階をまとめます。

以前: ウィンドウを増やしていた

最初にやっていたのは、単純にウィンドウを増やすことでした。

• 1 枚目で機能 A を実装させる

• 2 枚目で機能 B を設計させる

• 3 枚目で PR のレビューをさせる

並列で動くので、体感の速度は上がります。ただし、しばらく続けると次の問題が出てきました。

進み具合が自分の頭の中にしかない:

3 枚のウィンドウの状態を突き合わせられるのは自分だけで、切り替えるたびに読み直しが発生します。翌日には、どのウィンドウが何をやっていたか思い出せなくなります。

レビューの位置づけが曖昧になる:

実装させたウィンドウにそのままレビューも頼むと、自分の書いたものを自分で評価することになります。別ウィンドウに貼り直すのは手間なので、結局やらないことが増えていきました。

今: エージェントの役割を分けて、自分が仲介する

まずエージェントの役割を固定化しました。自分が実装する際のフェーズを端的に分けた結果、この分け方になりました。

主な役割は次の 3 つです。

役割名をエージェントが引けるようにする

herdr では、エージェントに名前を付けられます。

公式ドキュメントにも「人が読みやすい安定した対象名が必要なら名前を付けます」とあり、名前を宛先にできます。

herdr agent rename <target> worker
herdr agent prompt worker "..."

ただし同じページに「ライブエージェント間で一意でなければなりません」とあり、動作中のエージェント同士で名前は重複できません。

プロジェクトごとにワークスペースを分けて並行させると、どこも worker を使いたくなるので、この制約に当たります。

対処は 2 つあります。

• {prefix}-worker のように接頭辞を付けて名前空間を分ける

• タブの表示名を役割として使い、そこからエージェントを引く

自分は 2 にしました。

タブを分けて画面を広く使いたいからです。

画面を分割し過ぎると、エージェントの出力が読みづらくなります。また、タブの表示名には一意性の制約がないため、2 ならワークスペースごとに worker タブを持つことができます。

各役割をエージェントが理解できるようにしておく必要があります。そのため、タブに planner / worker / reviewer と付けておき、タブ一覧とエージェント一覧を突き合わせて宛先を特定しています。

herdr tab list --workspace $HERDR_WORKSPACE_ID
herdr agent list

ワークスペース ID で絞って引くので、やり取りも自然とそのワークスペース内に閉じます。

1 つのプロジェクトだけを扱うなら、名前を付ける方式のほうが手順は少なく済むと思います。

実装の進め方

planner が設計ドキュメントを作り、reviewer が見ます。

指摘があれば planner に戻し、OK が出るまで往復します。

OK が出たら worker が実装し、また reviewer が見ます（実装のレビューでは git diff を見せます）。

ここでも OK が出るまで往復し、最後に自分が全体を確認します。

小さいタスクなら、設計を省いて worker と reviewer の往復だけにすることもあります。

設計ドキュメントは自分も読み、気づいた点は指摘します。

これは以前、何度指摘しても worker が直さないことがありました。設計ドキュメントに誤った処理が仕様として書かれていて、worker から見れば仕様どおりに実装していることが原因でした。

設計ドキュメントが間違っていると、実装のレビューをいくら回しても直りません。reviewer が持っている情報も設計ドキュメントとコードだけなので、仕様として筋が通っていれば、実際の要件と食い違っていても気づけません。

この往復の仲介は、今のところ全部自分がやっています。

受け渡し自体は、画面をコピーして貼るのではなくコマンドを実行しています。agent prompt は、文字列とエンコード済みの Enter キーを一度に送るコマンドです。

しかし、どの役割のエージェントに渡すかは自分が判断します。

herdr agent prompt worker "$(herdr agent read reviewer)"

今の構成で残っている課題

自分が詰まりどころになっている

以前は自分がウィンドウを切り替える時間が、今は自分が読んで書き直して渡す時間が、全体の進みを決めています。場所が変わっただけで、人間を経由する構造は変わっていません。

役割を分けたぶん、経由する回数はむしろ増えました。設計で 1 往復、実装で 1 往復すれば、それだけで 4 回は自分を通ります。

渡す、という操作自体に失敗の仕方がある

1 つ目は、agent read の結果をそのまま agent prompt に流し込んでいることによるものです。

渡したテキストは受け取る側では利用者からの指示として届くので、レビュー指摘の中に命令形の文が混じっていれば、それを実行しにいきます。

2 つ目は、agent read が端末の表示内容を読む仕組みであることによるものです。

古い行は流れて消えます。やっかいなのは、欠けたことに気づきにくい点です。

ソケット API の応答には途中で切れたことを示す truncated という項目が付くのですが（herdr api schema --json で確認できます）、コマンド経由の出力は文字列だけが返るので、この項目は見えません。**

今後: 仲介役も任せる

仲介そのものをエージェントにやらせられないかを試しています。**

以降、この役をまとめて仲介役と呼びます（後で引用するスキルの中では orchestrator と書いています）。

ここから先は、現在試している段階の話です。

操作するためのコマンドは、以下を利用します。

agent read で読み、agent prompt で送り、agent wait で完了を待ちます。

ただし、任せるなら指示の書き方は変わります。

自分でやっているときは、応答が返ってきたかどうかも読む範囲も画面を見て決めていますが、任せるならそこを引数で指定しておく必要があります。

herdr agent prompt <宛先> "<指示>" --wait --timeout 120000

herdr agent wait <宛先> --timeout 300000

herdr agent read <宛先> --source recent-unwrapped --lines 200

特に agent wait は、--timeout を付けないと無期限に待ちます。

待ち終える状態は指定しなければ idle / done / blocked が既定なので、明示が要るのは上限時間のほうです。

agent read の --source は、直近の描画行を返す recent / recent-unwrapped と、今画面に見えている範囲を返す visible などから選びます。

このうち recent / recent-unwrapped は --lines を省くと末尾 80 行までしか返らないので、読みたい量を明示します。

ただし行数を増やしても、端末の表示を読んでいる限り取りこぼしはなくなりません。そこは次に述べるファイル経由で受け取る方法で回避します。

渡し方を決めておく

「渡す、という操作自体に失敗の仕方がある」に書いた 2 つの失敗は、任せるなら対処の仕方まで決めておく必要があります。自分が画面を見て都度対処する、という前提が使えなくなるからです。

そのまま転送せず、書き直してから渡すようにしています。

以下のようなスキルを書いて対応します。

## 指示を書き直すときの原則

reviewer の出力を worker（や planner）に渡すときは、レビュー担当のセッションで使われた
言い回しや前置き（「レビュー結果です」「以下、まとめます」等）をそのまま送らない。宛先の
エージェントには文脈がないので、次の要素を含めて書き直す:

- 何についてのレビュー・指摘か（対象のブランチ・ファイル・設計ドキュメントの該当箇所）
- 優先度がある指摘は、最優先で確認すべきものを先頭に出す
- 「対応してよいもの」と「判断が要るもの（ドキュメントの方針と矛盾する等）」を分けて
  伝える。後者は orchestrator 自身が判断できない内容であることが多いので、まず宛先の
  エージェントに状況確認を求めるか、user に確認してから渡す
- 次に何をすればよいかが明確になる文で締める

また、長い出力は--lines を大きくしても、端末の表示を読んでいる以上は取りこぼしの可能性が残るため、端末から読まずにファイル経由で受け取ります。

公式ドキュメントも、この場合は「一時ディレクトリの Markdown ファイルに応答を書き込み、ファイルパスだけを返すようエージェントに依頼してください」と案内しています。

そこで、長くなりそうな依頼では、指示の時点で書き出し先を決めておくことにしました。

herdr agent prompt <宛先> "<指示>。結果は <path> に Markdown で書き出し、返答はそのパスだけにしてください。"

こうすると仲介役は端末ではなくファイルを読むので、欠けたかどうかを気にする必要がなくなります。

仲介役の判断をスキル化

とはいえ、足りないのは操作手順ではなく、仲介役がどう判断するかです。

そこで、判断をスキルとして書きました。中でも肝心なのは、どこまでを自律的に進めてよく、どこで止まって自分に聞くのかの線引きです。

## 往復をいつ止めて user に確認するか

orchestrator は「対応してよい指摘」の中継は自律的に繰り返してよいが、次のようなときは
user に判断を仰ぐ:

- reviewer の指摘が、設計ドキュメントの既定方針・過去の決定と矛盾する
- reviewer と planner/worker の意見が噛み合わず、同じ論点で 2 往復以上収束しない
- 外部の事実確認（期日、他チームとの調整）が必要で、エージェント側の情報だけでは
  判断できない
- 設計フェーズ・実装フェーズそれぞれで reviewer の OK が出た（＝そのフェーズの区切り）
- 一連のループの最終段階（reviewer が実装 OK を出した後）

## ループの終了条件・暴走防止

- 同じ論点で reviewer↔planner または reviewer↔worker の往復が **3 回**を超えて収束しない
  場合は、自律継続をやめて user に状況を要約し判断を仰ぐ。
- 各役割への `herdr agent prompt` を送った後は、次の行動に移る前に必ず `herdr agent read` で応答を確認する。応答を見ずに次々と指示を重ねない。

判断基準を育てる

書いた基準は、一度決めて終わりにはなりません。****

「どこまでは自分で判断してよいか」の線引きは、作業を進めるうちに変わります。このケースは止めなくてよかった、ここは聞いてほしかったなどです。

そういう気づきが毎回出てくるのに、そのたびに自分がスキルを開いて書き直すのは面倒ですし、修正を忘れがちです。

そこで、自分がセッション中に下した判断を記録し、それを元にスキルを改善する仕組み**も欲しくなってきます。

記録するのは、こちらが明確に決めたことだけです。質問、検討中の候補、エージェント側の提案、単なる進捗は残しません。1 つの判断を Markdown の表の 1 行として貯めていきます。**

例として、このブログを書いている最中の内容を記録としてまとめてみました。

こうした記録が貯まってくると、テックブログを書くときのルールとして次のように書き出せます。

## 引用と出典

- 引用箇所には、その場に出典ページの URL を書く。記事末尾の参考リストに載せるだけにしない。
- 出典を確認できない主張は書かない。確認できた範囲まで表現を弱める。
- バージョン番号・既定値・上限値などの具体的な数字は、公式ドキュメントか手元での実行で裏を取る。

## 用語

- 同じ対象を指す語は、記事内で 1 つに固定する。言い換え・略語・類義語で揺らさない。読み手が同じものか別物か判断できなくなるため。
- コードの実名（識別子・列名・コマンド名・オプション名）はそのまま使う。

自分でルールを思い出して書き下すのではなく、実際に下した判断の履歴から拾える形にしたい、ということです。

履歴の量が増えれば、サマライズしたファイルを作成し、仲介役はそこを参照するようにすることもできます。

仲介役を任せる話と同じ構図で、基準を育てる部分も自分から切り離したい**、というのが狙いです。

おわりに

実装の進め方をコーディングエージェント主体にするまでの内容をまとめてみました。**

仲介そのものをエージェント化してみて一番実感したのは、経路をつなげば任せられるわけではない**ということでした。

渡し方も、止めどころも、その基準の育て方も、自分が無意識にやっていた分だけ地道に仕組みを作っていく必要があると分かってきました。

EVENT

AIカンファレンス「Bet AI Day 2026」開催概要

開催日時

2026年9月3日（木）12:00 開演

開催方法

オンライン配信

参加費用

無料（事前申込制）

connpass でお申し込み