ハクソク

世界を動かす技術を、日本語で。

バックプレッシャーが必要なすべてです

2日前原文(lucasfcosta.com)

概要

  • コーディングエージェント活用の2つの典型的な方法の問題点を指摘
  • 人間のレビュー負荷を減らす「バックプレッシャー」の重要性を解説
  • バックプレッシャーの自動化による効率的な開発プロセスの提案
  • Lintやテスト、手動検証など具体的な導入方法を紹介
  • 人間は最終レビューや設計判断に集中できる環境構築のすすめ

コーディングエージェント運用の課題とバックプレッシャー導入の意義

  • コーディングエージェント の一般的な使い方には2つの問題点が存在
    • 完全放任運用 ：LLMに自由にコードを書かせる方式
      • 高速だが バグ や 混乱、 過剰なPR 発生の温床
      • 人間のレビューが追いつかず、品質低下リスク
    • 逐次人間介入 ：すべての変更を人間が細かくレビュー
      • 安全だが 遅すぎて自動化のメリットが減少
      • 細かな判断まで人間が指示するため 委譲効果が薄い
  • 第三の選択肢として、 エージェント自身が自動で品質検証 を行う手法を提案
    • 長時間の無人作業 を安全かつ有用に
    • 低品質なPR の発生を抑制し、レビュー負担軽減

システムエンジニアリングにおけるバックプレッシャーの概念

  • バックプレッシャー ：下流工程が上流に「これ以上受け入れ不可」と伝える仕組み
    • 自動テスト が最も身近な例
      • テストに通らないPRはそもそもレビュー対象外
      • テストスイート が人間の代わりに品質担保
    • 型（Type） も強力なバックプレッシャー
      • TypeScript導入以前はバグ検出が困難
      • 型による制約で「不可能な状態」を未然に防止
      • 型エラーで即座に作業停止、人間レビューの効率化
  • CIパイプライン や リンター、E2Eテスト、カナリアリリース なども自動ガードレールとして機能
  • LLMが高速にコード生成 する現代では、人間が唯一のバックプレッシャーになりがち
    • 人間が逐一レビュー・指摘・修正を繰り返す「高コストなクリップボード」状態
    • 自動化されたバックプレッシャー の必要性

バックプレッシャー自動化の実践手法

  • テスト失敗・型エラー・ベンチマーク落ち・レビューエージェントによる差し戻し などを自動化
    • 人間は 最終レビュー や 設計判断 に専念
  • npx @lucasfcosta/backpressured コマンドで本記事のスキル導入可能
    • /backpressured <ゴール説明> で自動ループ開始
    • BACKPRESSURE.md でチェック内容カスタマイズ可

バックプレッシャー導入例と具体的チェック項目

  • /goalコマンド によるエージェント自動作業の品質向上
    • 初期は「機能実装」に偏り、テストや品質検証が抜けがち
    • 品質基準（Lint, テスト, commitチェック等） を毎イテレーションで必須化
      • 各パッチごとに 全チェック通過を義務
      • 不合格時は 即修正・再検証
  • 手動検証 の自動化
    • cURLや実ブラウザによるUI/API動作確認
    • docker-compose起動やDBスキーマ設定 等のスキルをエージェントに習得させる
    • obra/superpowers builder でエージェントに実行方法を教える
  • プロンプト例
    • 機能要件＋品質基準（Lint, テスト, commit_check.sh等）を明記
    • 「すべての基準を満たすまで次のパッチ作成を禁止」
    • 「問題が残る場合は理由を説明」

まとめ：自動バックプレッシャーによる開発効率化

  • 人間がボトルネックになる構造 からの脱却
  • 自動化された品質ガードレール による低品質PRの減少
  • エージェントが自律的に品質担保 し、人間は本質的な判断に集中
  • バックプレッシャー設計・導入 がAI時代のソフトウェア開発効率化の鍵

Hackerたちの意見

エージェントが自分でキャッチすべき詳細を、チームメイトがレビューしなきゃいけない低品質なPRの数も減るはずだね。ああ、もう。

└

もう少し詳しく説明してくれない？

「この投稿では、あまり明白でない第三のアプローチについて説明します。それは、エージェントが人間が介入する前に自分の作業をもっと検証できる方法を構築することです。」これは少なくとも1月から明らかだったことで（Geoffrey Huntleyが「すべてはラルフループだ」と発表して以来）、私がやってきたのは、すべてを自動化できるように十分なオーケストレーションツールを構築することです。開発コンテナの立ち上げ、ビルド、ユニットテストの実行、統合テストの実施、そして最終的にはエンドユーザーとしてソフトウェアを使うことです。それから、すでにしっかりした基盤の上にパフォーマンス目標を設定して、自動化されたエージェント（「ジム」）が自律的に反復できるようにして、「完了した」と知らせてくれるのです。これは、サブスクリプションを利用していてAPIを使っていない場合にはうまくいかないかもしれません（トークンはすぐに消費されるので）が、私には非常に生産的でした。

└

じゃあ、どのライセンスを使ってるの？

└

ここから私の生産性向上が来てるんだ。今はプロジェクトごとに移動できる特別なハーネスを使っていて、テストのオーケストレーションをやってる。仕事の大半は、早めにプロンプトをセットアップして、それをループさせて機能が動いている証拠が返ってくるのを待つだけ。トークンの使用を最適化してきたおかげで、Claudeはプロセスの大部分で非常にタイトなforループを作って、トークン数をさらに減らしてくれる。いい感じだよ。仕事での苦労がかなり減った。

└

20倍のClaude CodeとCodexプランでかなりのことができるよ。APIコールに比べて、はるかに安いからね。

└

でも、それって全部でどれくらいのコストがかかるの？生産性が上がるのは疑わないけど、Open Clawの guy が1ヶ月で130万もトークンに使ったって記事を見ると、すごいスピードに達するドラッグレース用エンジンが、1レースの後に完全に再構築しなきゃいけないことを思い出すよ。

└

うん、これは多くの人にとって明らかだったね。特に、Chernyがこのことについて超人気のスレッドで投稿した4ヶ月前からはね… https://x.com/bcherny/status/2007179861115511237

└

おそらくサブスクリプションに入っていてAPIを使ってないとこれが機能しないのは理解してるけど、私にはすごく生産的だったよ。無限のお金でも持ってるの？

└

残りの段落の説明の方が重要だよ。「長時間の無人セッションを、完全に人間をループから外さずに役立つほど安全にすることが目標です。また、エージェントが自分でキャッチすべき詳細をレビューするために、チームメイトが低品質なPRを確認する回数を減らすべきです。」 >「完全に人間をループから外さずに役立つほど安全に」 これは、AIの使用、支援、採用の基本的な概念で、コード生成だけじゃなくて、あらゆる分野に当てはまるよ。要するに、LLMやML、DLを含むAIは、専門家が安全性と品質のゲートキーパーとして機能する原則に基づいて動作する自動化ツールの一つなんだ。賢明で責任ある意思決定のためにね。[1] ドメインの専門知識が本当の防壁だったんだよ (brethorsting.com) (519コメント): https://news.ycombinator.com/item?id=48340411

└

たくさんの企業が巨大なマイクロサービスを構築してしまって、ローカルではユニットテスト以上のことができないのが残念だよ。変更の影響を推測するしかなくて、マージしてデプロイして、自分のアカウントやテストアカウントの機能フラグをオンにするまで分からないんだ。このループは遅くて、彼らが支払うコストかもしれないけど、エージェントにとっては安全じゃないから、大きな後退になるよ。

これはコーディングエージェント101みたいだね：強力なフィードバックループを構築すること。何か見落としてる？

└

うーん、ここでのバックプレッシャーのアナロジーはあまり見えないな。エージェントが常に新しいものを生産していることを暗示してるけど、解決策は非常に詳細な仕様や目標だから、それは実際には不可能だよね。

└

いや、この文章には新しいことは何もないよ。この方法論はすでにソフトウェアコミュニティによって採用され、さらに最適化されている。

「バックプレッシャー」という用語の使い方が少し間違ってるんじゃない？OPは最初に正しい定義を引用してるしね：> システム工学において、バックプレッシャーは、下流のコンポーネントが上流に対してこれ以上の作業を受け入れられないことを知らせるメカニズムです（この場合の「下流のコンポーネント」は人間のレビュアーです）。でも、彼らが提案している対策は実際にはそれを行っていない。むしろ、エージェントの提出速度を遅くし、低品質な提出を「下流」に到達する前に排除する固定スロットル要素のようなものだよ。人間の開発者が提出をレビューする実際のキャパシティ（または意志）との関連が見えない。

└

これは、すでに欠陥のある比喩の誤った使い方だね。圧力は等方的だよ。指向性の圧力は意味がないし、他の工学の無関係な分野の流体アナロジーと同じだ。

└

作者です。ご指摘ありがとうございます。バックプレッシャーは理想的な比喩や用語ではないかもしれませんね。以前の投稿から来たものですが、あなたが言っていることを正確に考えたことはありませんでした。それは私の責任です。

└

それは間違ってるし、たぶんそれが気に障るのはもっと少なくていいはずなんだ。リーンの人たちはこれについて長い間話してきたよ： - シングルピースフローは、大きなバッチを作って一度に下流に送るのではなく、一度に一つのことに取り組むことを意味する。そうすることで、下流が間違ったものを生産する前に拒否するチャンスができる。 - 自動化（または自働化）は、機械が何かが間違っているときにそれを検出し、その時点で続行しない能力を与えることを意味する。 - ポカヨケは、構造的に結果を適合させるプロセスだ。これらの用語のどれもが、この文脈ではバックプレッシャーよりも良いと思う。（これで気づいたのは、リーンの人たちが新しいコードを書くロボットが直面する問題に数十年も取り組んできたこと。リーン哲学の半分は、人々の創造性にポジティブな選択肢を持たせるプロセスや構造を設定することに関するもので、彼らの責任のレベルに過度な要求をしないこと。これが、コードを書くロボットにも求めていることなんだ。彼らが得意なことの利点を捕らえたいけど、無数の間違いに悩まされるのは避けたい。だから、単に間違いを指摘するだけじゃなくて、リーンの人たちのように考えなきゃいけないんだ。）

シンプルで明らかなアイデアについての長い投稿だけど、いろんな実装があるね。主な問題は、1) APIの使用がめちゃくちゃ高いこと、2) Claudeが全自動化を非常に高くすること、3) モデルが主導権を持つフローは無駄な停止（チェックポイント）に偏っていること。これを「バックプレッシャー」とは呼ばないよ。生産者と消費者の不均衡とかそんなのはないからね。著者はただ構造化されたフィードバックループを提案しているだけだと思う。これは、複数の信頼できないけど非常に複雑なコンポーネントからなるシステムの組織原則についての議論で、この「バックプレッシャー」はその一側面に過ぎない。個人的には、実行可能なシステムモデルのフレームワークは、メンタルモデルとしても具体的な実装ガイドラインとしても生産的だと思う。エージェントSDKが悪いのと、カスタムハーネスを作るのが難しいのが少し問題かな。

└

https://en.wikipedia.org/wiki/Back_pressure

└

モデルが主導権を持つフローは無駄な停止に偏っている そのバイアスの原因について詳しく教えてくれない？私の経験では、Qwen3.6、Claude Sonnet 4.6、Opus 4.6/4.7は、指示とテスト方法があればできる限り動くと思う。Opus 4.8の限られた経験では、フィードバックのために少し早めに止まることがあるけど、それは前提を確認してくれるところや、範囲の変更を特定してくれるところで嬉しいと思ってる（例えば、次の作業が別のコミットやマージリクエストに値する場合）。それは無駄な停止ではなく、正当な停止だと思う。

└
  1. Claudeはすべての自動化を非常に高価にするつもりだって。 え、何があったの？？
└

エージェントがチェックポイントのために一時停止しないようにするには、停止条件が満たされるまで再実行する決定論的な外ループを作ればいいと思う。チームは、コード主導とエージェント主導の間を移行するネストされたワークフローを書ける必要があると思うし、人間が関与するチェックポイントもサポートするべきだね。うちのスタートアップでも、これがどうあるべきかを考えてるところだよ（https://www.amika.dev/）。モデルラボもここでの能力を向上させてるし、Codexの「/goal」やClaude Codeのダイナミックワークフローもあるしね。API使用コストについてのポイントは変わらないけど、モデルの知能は毎月安くなってる！作業のすべての部分にフロンティアモデルを使う必要はないよ。

これがフックの役割だよ。フックは特定の条件下で基準を指定できるから（エージェントが完了したと思ってユーザーに返す準備ができているときなど）、エージェントが数ターン深く入った後に忘れちゃうことがないし、平文の指示を読むために別のLLMインスタンスを起動する必要もない。LLMが生成したコードを自動的に検証できるシステムを持つのは絶対に理にかなってるけど、こういう決定論的な合格/不合格の条件に対して非決定論的なシステムに頼る必要はないよ。[1] https://code.claude.com/docs/en/hooks

└

俺も全く同じことを考えてた。フックを実装する場所はたくさんあるよね（gitフック、Claudeフックなど）。気になってるのは、特定のシステム部分を予期しない/不要な変更からどうやって確実に守るかなんだ。例えば、Claudeがテストをコメントアウトしたり書き直したりして通そうとする場合とか。俺の考えは、実装の特定の部分でテストの変更を自動的に元に戻すことだけど、それだとちょっと堅苦しくて、リファクタリングみたいなことを妨げるかもしれない。

これや他の検証を考えている人は、長いプロンプトや複雑なスキルから離れて、フックを見ていくべきだよ。すべてのチェックをストップフックやgitコミットフックに入れれば、リポジトリのドキュメントがエージェントに、作業を止めたときにチェックが自動的に実行されることを伝えられるし、見つかった問題を修正するはず。QAプロセスの終わりに決定論を再導入するのは素晴らしいことだよ。フックのおかげで、エージェントが自分の作業をスキップしたり忘れたりすることがないと知るのは、すごく安心する。

└

piサブエージェント（最大8つのサブエージェントを並行して持つことができる長いチェーンを形成できる）とClaude Codeの新しいワークフローフィーチャーは、すごく便利な抽象化で、すぐに設定できると思うよ。

└

100%同意だね。誰が監視者を監視するかなんて話はなしで、プリコミットフックとして強制すべきだよ。これの一番いいところは、他の人が同じようにエージェントを設定しているかどうかを心配しなくて済むこと。毎回ちゃんと機能するから。

俺はいつも標準的なワークフローを使ってるけど、問題になったことはないよ。 - タスクとゴールを定義して、短い仕様書を書く（マークダウンでOK） - エージェントをプランモードにして、フェーズごとにプランをディスクに書き込ませる。必要ならその場でプランを修正。 - 各エージェントにフェーズを担当させて、進行中のドキュメントとして更新させる（難しいフェーズがあればモデルを切り替える） - 完了するまでクリアして繰り返す これを複雑にしたことは一度もなくて、企業規模のプロジェクトでも個人プロジェクトでもうまくいった。何か見落としてるのかな？

└

あなたがやってることはいいと思うよ。私も似たようなワークフローを持ってるけど、ここでのアイデアは、手動の承認作業をコード化されたテストで自動化することなんだ。生成が簡単だから、できるだけ多く作って、何をテストするかをよく考えれば、エージェントが逸脱することも少なくなって、自律性が増すよ。

自分専用のエージェントを作って、カーネル開発みたいにパッチを生成して、それをレビューしてマージしてるんだ。https://github.com/hsaliak/std_slop/blob/main/docs/mail_mode... このエージェントは、コーディングステップ以外の変更を無効にしてこのワークフローを強制するんだ。最近、ループ処理も追加したよ。https://github.com/hsaliak/std_slop/blob/main/docs/mail-loop... これで、手動でのレビューと自動化の両方の良いとこ取りができてる。エージェントが最初に通過すると、最高の品質が得られることが多いよ。

自分自身の真実のソースを作成して、その作業を検証する再帰的なワークフローを作ったよ。https://github.com/try-works/recursive-mode