コーディングエージェントへの「逆圧力（Backpressure）」の適用：自律性を高めるアプローチ

コーディングエージェントを使用する際、通常は以下の 2 つのアプローチが考えられますが、それぞれ限界があります。

• 放置と期待値

  • LLM を監視なしで実行し、リポジトリが壊れないことを祈る方式です。
  • 迅速で刺激的ですが、バグや混乱した変更を招きやすく、人間レビュー速度に追いつきません。
  • 最終的にレビュー基準が低下し、理解していないコードがマージされるリスクが高まります。

• 完全な手動レビュー

  • エージェントを拡張されたオートコンプリート扱いし、人間の審査員が細部までレビューさせる方式です。
  • 安全ですが、「スピード」を損なうほど過剰になります。
  • すべての決定に人間が介入することは、実質的な委任（エンパワーメント）の欠如を意味します。

本稿では、これらの明らかな方法ではなく、第 3 のアプローチ、「人間が介入する前にエージェント自身が作業を検証できる仕組みを作る」について紹介します。このアプローチは、人間をループから完全には外さずに、長時間の無監視セッションを有用かつ安全なものにし、低品質な PR の数を減らすことを目標とします。

---

逆圧力（Backpressure）とは？

システム工学において、**「逆圧力（backpressure）」**とは、下流が処理能力に余裕がない場合、上流のプロデューサーに対して信号を送り、負荷を調整させる機構です。

• 逆圧力が不足している場合

  • プロデューサーは好きなだけワークを生成できますが、消費者（処理側）はその不整合を吸収せざるを得ません。
  • 結果として、消費者は遅延を起こしたり、破損したり、あるいは速度維持のために質の低下を許したりします。

• 開発現場における逆圧力

  • 「プロデューサーが未整備な状態で仕事を拒絶する」形をとります。
  • 最も典型的な例が自動テストです。理想はすべてのテストパス（グリーン）するまでレビューを待つこと。これにより、テストスイートはコードを整える前の最後の砦となります。

• 型（Types）の役割

  • TypeScript などは、「不可能な状態」を技術的に不可能にすることで逆圧力を追加します。
  • コンパイラや型システムが境界でエラーを検出・拒絶するため、人間レビュー前に多くのミスマッチを防ぎます。
  • 型はテストよりも上流に位置し、高価な人間レビューを短く安全なものにします。

• AI 開発の現状と課題

  • LLM が高速にコードを生成する文脈では、デフォルトの逆圧力は「人間自身」（手動レビュー）になっています。
  • 別のレビューボットを導入しても、単なる高価なクリップボード化するだけの皮肉な結果になりがちです。

• 目標：自動化された逆圧力の実装

  • **「人間を AI ループにおけるデフォルトの逆圧力から排除すること」**が次のステップです。
  • 早期に失敗するテストや、先制攻撃的な型のチェックなどによって、低レベルな品質問題を自動処理し、人間は最終的な設計判断や高レベルのフィードバックに集中できるようにします。

---

実装：逆圧力の構築方法

Claude の

/goal

コマンドを使用を開始した際、初期のプロンプトには機能への焦点が強すぎて、必要なテストや全体的な品質基準（エッジケースなど）が欠落していました。その結果、モデルが早すぎる勝利宣言をし、人間が手動で介助する必要に迫られていました。

これを解決するために、自動化された逆圧力機構を

/goal

ループに追加しました。

主要な逆圧力機構一覧

一般的な考え方は、自動化されたチェックとレビューをループに徐々に追加し、モデルが消費側の期待に頻繁に対峙させ、問題発生前に自身で修正できるようにすることです。

1. リンティング、テスト、簡単な検証スクリプト
2. cURL やブラウザを使った手動テスト
3. ベンチマリング
4. レビューエージェント（機能性、テスト、型、簡潔さ）
5. プランニングフェーズレビュー
6. ビジュアルデザインレビュー
7. PR モニタリング

以下に各メカニズムの具体的な実装とプロンプト例を説明します。

1. リンティング、テスト、簡単な検証スクリプト

これが最も単純で明らかな逆圧力の形態です。プロジェクトにテストスイートとリンターがあれば、すぐに利用できます。

• 課題
  • LLM はテストを実行しますが、進行中でテストが緑色を保つことを忘れてしまいます。
• 解決策
  • 品質チェックを含むプロンプト拡張を行いました。コミットメッセージチェッカーなどの検証スクリプトの実行も追加しました。
• 重要なポイント
  • **「各反復でチェックを実行する」**ことが非常に有効です。これにより、モデルは早期の問題を検知・解決します。

改善後のプロンプト構造例

/goal implement support for <brief feature description>. Here are the feature's acceptance criteria:
1. <first criterion: i.e. the button X must be disabled while the form is submitting>
2. <second criterion: i.e. the front-end must show an error message if the API returns a 400>
3. <third criterion: i.e. redirect the user to the dashboard after a successful submission>

+The task is not done until all of the above acceptance criteria are satisfied. Additionally, the following quality criteria must also be met:
+1. The linting is passing
+2. Tests are all green
+3. The new behavior is covered by tests
+4. The commit_check.sh script is passing

+Run these quality checks in _each_ iteration. Do NOT wait until the end to run them. You should run them after writing each patch, and you should not write a new patch until all checks are passing.
+If any of the above criteria are not met, you must inspect the failure, fix the issue, and run the check again. Do not stop after writing the patch. Stop only after the acceptance criteria are satisfied, or after you can explain exactly what is blocking you.

2. cURL とブラウザを使った手動テスト

自動テストには限界があります。実際のブラウザ動作や API エンドポイントへの叩き（cURL）では捕捉できない問題が存在します。

• 実装内容
  • モデルに

    obra/superpowers

    を使用して、ローカル環境でのアプリ実行、データベーススキーマ設定、一般的なトラブルシューティングを学習させました。
  • プロンプトを更新し、Claude がそのスキルを使って手動チェックを行うように指示しました。

プロンプトの追加例

+After you're done iterating, use the `run_local_dependencies`, `run_backend`, and `run_frontend` skills to run the application locally and test the new behavior manually. You can use `cURL` commands to test the API endpoints and the Playwright MCP to test the front-end on a real browser. You should run these manual checks at least once before considering the task done, but you can run them more than once if you think it's necessary to catch issues that automated tests might have missed.
+If any of the above criteria are not met, you must inspect the failure, fix the issue, and run the check again. Do not stop after writing the patch. Stop only after the acceptance criteria are satisfied, or after you can explain exactly what is blocking you.

• 効果
  • 自動化チェックの反復後、タスク完了前には必ずローカル環境での動作確認を必須とします。

3. ベンチマリング

パフォーマンスに敏感なアプリケーション向けにベンチマリングを追加しました。

• 課題
  • 実行と解釈が難しかったため、モデルが頻繁に実行しやすくする改善を行いました（10 分間待機せず簡易チェック）。
  • 構造化された出力をディスクとコンソールに書き込み、変化が改善か回帰かを理解しやすくしました。

プロンプトの追加例

+5. Run the benchmarks using the `run_benchmarks` skill. See the acceptance criteria inside it.
+After you're done iterating:
  +1. Use the manual testing skills (described above).
  +2. Use the `run_benchmarks` skill to run the full benchmarking suite. See the acceptance criteria inside it.

4. レビューエージェント（機能性、テスト、型、簡潔さ）

レビューエージェントは追加した最も効果的な逆圧力の形態の一つでした。初期段階では明らかなバグを捕捉しましたが、品質問題（可読性、過度な複雑さなど）は残っていました。これらを客観化するスキルを構築し、各反復で実行するよう指示しました。

プロンプトの追加例

+6. Use the `review_agent` skill to review the code
Run these quality checks in _each_ iteration. Do NOT wait until the end to run them. You should run them after writing each patch, and you should not write a new patch until all checks are passing.
After you're done iterating:
  +1. Use the manual testing skills (described above).
  +2. Use the `run_benchmarks` skill to run the full benchmarking suite. See the acceptance criteria inside it.
  +3. Run the `review_agent` skill one last time, but now tell it to review the changeset as a whole.

5. プランニングフェーズレビュー

前述のメカニズムは実装フェーズを対象としていますが、モデルが最初から間違ったアプローチを選ばないことを保証するために、コード作成前にプランレビューを追加しました。

• 手法
  • Claude が初期プランを生成した直後、実装開始前に、

    review_agent

    スキルを使って基本的なアプローチの妥当性を確認します。
  • 承認されるまで反復させます（軽量なプランで可読性の詳細は defer）。

プロンプトの追加例

+Before writing any code, produce a lightweight plan that focuses on the overall approach and architecture, _not_ on implementation details. Then, use the `review_agent` skill to review the plan and confirm the fundamental approach is sound. Keep iterating on the plan until the reviewer approves it, and only then move on to the implementation.

6. ビジュアルデザインレビュー

フロントエンドでは、レイアウトや間隔などの可視化された問題を自動テストは捕捉できません。この逆圧力も重要です。

• 手法
  • Playwright MCP を用いてスクリーンショットを取得し、Figma や Linear チケットの画像と比較するスキルを作成しました。
  • ヘッダーからフッターまでを分割してレビューするように指示します。

プロンプトの追加例

+6. Run the `visual_review` skill to review the actual screenshots of the new feature against the design specifications
7. Use the `review_agent` skill to review the code
After you're done iterating:
  +1. Use the manual testing skills (described above).
  +2. Use the `run_benchmarks` skill to run the full benchmarking suite. See the acceptance criteria inside it.
  +3. Run the `review_agent` skill one last time, but now tell it to review the changeset as a whole.

7. PR モニタリング

レビューエージェントを導入しても、衝突や CI フォール、他のレビュアーからのコメントによる問題が依然として発生します。PR をオープンした後一定時間監視するスキルを追加しました。

• 動作
  • 新しいコメントや CI ステータス変更、マージ衝突を検知した場合にモデルを通知し、解決まで継続します。

プロンプトの最終形例

After you're done iterating:
  +1. Use the manual testing skills (described above).
  +2. Use the `run_benchmarks` skill to run the full benchmarking suite. See the acceptance criteria inside it.
  +3. Run the `review_agent` skill one last time, but now tell it to review the changeset as a whole.
  
+If all the above have been done, approved, and there is nothing else left to do:
  +1. Open the PR with the changes.
  +2. Use the `monitor_pr` skill to monitor the PR for any new comments, CI status changes, or merge conflicts for the next 24 hours. If any of those issues are detected, address them before considering the task done.

+If any of the above criteria are not met, you must inspect the failure, fix the issue, and run the check again. Do not stop after writing the patch. Stop only after the acceptance criteria are satisfied, or after you can explain exactly what is blocking you.

---

まとめ：完全な逆圧力ループの構成

最終的な逆圧力ループは、目標からクリーンにマージされる PR までの全段階でチェックゲートを持つものとなります。

• 事前検証
  • プランレビュー（アプローチの妥当性）
• 反復中検証
  • リンティング、テスト、型チェック、ベンチマーク、コードレビュー
• 完了後検証
  • 手動テスト、ベンチマーク、統合レビュー
• 最終ゲート
  • PR モニタリング

---

まとめと次のステップ：ソースコードの利用

この逆圧力ループをパッケージ化し、スキルとして公開しました。GitHub の

[@lucasfcosta/backpressured](https://github.com/lucasfcosta/backpressured)

でソースコードが公開されています。

インストール方法

ターミナルで以下のコマンドを実行します。

npx @lucasfcosta/backpressured

その後、Claude に対して

/backpressured <goal description>

を実行するか、明示的にこのスキルを使用するように指示します。

今後の展望

• SKILL.md

  でワークフローをパッケージ化するか、モデルに直接組み込むかを検討しています。
• いずれにせよ、逆圧力を加える方向性はソフトウェア開発の未来であると考えられます。
• 「人間が機械のミスを捉えることに依存するシステムは、人間の限界によって制限される」というマクスウェルの悪魔（Maxwell's demon）の教訓が成り立ちます。
• より構造を持つ逆圧力が、よりスマートなエージェントよりも優れています。