https://roboco.io/ja/tags/continuous-improvement/ Recent content in Continuous-Improvement on ROBOCO Hugo ja Sat, 10 Oct 2026 10:00:00 +0900 https://roboco.io/ja/posts/software-factory-failures-into-rules/ Sat, 10 Oct 2026 10:00:00 +0900 https://roboco.io/ja/posts/software-factory-failures-into-rules/ <blockquote> <p>「この経路には成功率に応じた実行制限がなく、制限を設けない理由も見つからなかった（The lane has no rate gate, and I found no reason for that）」 – OpenClaw ClawSweeper PR #1855<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup></p> </blockquote> <figure><img src="https://roboco.io/posts/images/Dohyun.png"><figcaption> <h4>チョン・ドヒョン - ROBOCO首席コンサルタント</h4> </figcaption> </figure> <hr> <p>この記事は、4回シリーズ「オープンソースプロジェクトから学ぶソフトウェアファクトリーのベストプラクティス」の最終回です。</p> <p><strong>シリーズの構成</strong></p> <ol> <li><a href="https://roboco.io/ja/posts/software-factory-best-practices-from-open-source/">判定基準と12のリポジトリ：何をファクトリーと呼び、どこで動いているのか</a></li> <li><a href="https://roboco.io/ja/posts/software-factory-who-merges/">誰がマージするのか：リスクに基づく委任と権限構造</a></li> <li><a href="https://roboco.io/ja/posts/software-factory-evidence-before-fix/">証拠でふるいにかけるファクトリー：「修正前には失敗する」ことの証明</a></li> <li>失敗をルールに：自己改善ループとその限界（本記事）</li> </ol> <p>冒頭の引用は、OpenClawの自動実装ワーカーが1週間で52回成功し256回失敗したあと、それを報告したPRに書かれた一文です。そのPRは、失敗率が高いと自動実装を止める仕組みを追加しました。<sup id="fnref1:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup> 失敗を発見し、原因を突き止め、二度と起きないようにルールや仕組みを変えること。これが<a href="https://roboco.io/ja/posts/software-factory-best-practices-from-open-source/">第1回</a>で定めた判定基準の6番目、自己改善ループです。<sup id="fnref:2"><a href="#fn:2" class="footnote-ref" role="doc-noteref">2</a></sup></p> <p><a href="https://roboco.io/ja/posts/software-factory-evidence-before-fix/">第3回</a>では、証拠の仕組みも回避されたり、意図を見落としたりしうることを見ました。<sup id="fnref:3"><a href="#fn:3" class="footnote-ref" role="doc-noteref">3</a></sup> 今回は、そうした失敗が起きたあとを扱います。プロジェクトは失敗をどこに、どのような形で戻しているのでしょうか？ そして、そのループはどこで途切れるのでしょうか？ 数値はこれまでの回と同じく、2026年10月10日にGitHub APIで取得した値です。</p> <h2 id="tldr">TL;DR</h2> <ul> <li>観察したファクトリーは、失敗を4つの場所に戻しています。エージェント向けの指示とスキル、CIチェック、サーバーやワークフローの仕組み、そして自動化を止めたり縮小したりする決定です。</li> <li>事例をもとに、私は3つのことを勧めます。失敗を根拠とともに記録すること、原因をエージェントではなく指示文と仕組みに求めること、そして可能であれば指示とCIチェックを一緒に直すことです。</li> <li>今回の公開資料の調査では、最後の段階である効果確認の運用記録は限られていました。ルールを追加した記録は多いものの、そのルールが守られているかを定期的に自動で確認する記録は見つけにくいものでした。取り消した決定が記憶されず、同じミスが繰り返された事例もあります。</li> </ul> <hr> <h2 id="1-自己改善ループの4つの段階">1. 自己改善ループの4つの段階</h2> <p>自己改善ループは4つの段階に分けられます。失敗を発見し、原因を診断し、ルールや仕組みに変え、その効果を確認することです。各段階がリポジトリでどのように見えたかをまとめると、次のとおりです。</p> <table> <thead> <tr> <th>段階</th> <th>リポジトリで観察した例</th> </tr> </thead> <tbody> <tr> <td>1. 発見</td> <td>OpenClawの失敗率の集計、OpenHandsの日次検証、Beadsによるマージ済みPR 440件の監査、Vercel AI SDKの<code>factory-flawed</code>ラベル</td> </tr> <tr> <td>2. 診断</td> <td>Astroの「合理化の余地」の診断、OpenClawによる指示の切り詰めの発見、Claude Codeによる権限モードの誤作動の発見</td> </tr> <tr> <td>3. ルール化</td> <td>Beads・OpenClaw・Bunの指示の修正、Astroのスキルの修正、mastraのサーバー側の仕組みの追加、OpenClawのサーキットブレーカー</td> </tr> <tr> <td>4. 効果確認</td> <td>公開記録は限られている。Astroはスキル評価（eval）を作ったが、CIにはつないでいない</td> </tr> </tbody> </table> <p>前の3つの段階は複数のプロジェクトで観察されました。4番目の段階は、今回の調査では公開された記録だけではほとんど確認できませんでした。この差については、記事の後半で改めて扱います。</p> <hr> <h2 id="2-失敗を根拠とともに記録する">2. 失敗を根拠とともに記録する</h2> <p>ルールだけを残して理由を消すと、あとでそのルールを守るべきか廃止すべきかを判断できなくなります。エージェントも、ルールの範囲を推測しなければなりません。うまく機能しているプロジェクトは、ルールのそばに、そのルールを生んだ出来事を残しています。</p> <p>最も徹底しているのはBeadsです。メンテナー向け指針の「マージの規律（Merge Discipline）」節は2026年6月12日に追加され、根拠としてマージ済みPR 440件を2か月にわたって監査した結果を挙げています。<sup id="fnref:4"><a href="#fn:4" class="footnote-ref" role="doc-noteref">4</a></sup> 「先行事例の確認（Prior art）」節は2026年7月27日に追加され、その前日に起きた出来事を「きっかけとなった出来事（Motivating incident）」として記しています。作成から44日たったPRが20日間マージ可能な状態で待っている間に、作成から5日の重複PRが一つのコメントもなく自動マージされた出来事です。その結果、すべてのレビューの前に同じテーマのオープンなPRを探す手順が義務になりました。<sup id="fnref:5"><a href="#fn:5" class="footnote-ref" role="doc-noteref">5</a></sup> <code>CODEOWNERS</code>のコメントにも、マイグレーション事故を起こしたPRの番号が書かれています。<sup id="fnref:6"><a href="#fn:6" class="footnote-ref" role="doc-noteref">6</a></sup></p>