AI が書いて AI が審査する OSS へ再現と検証を添えて修正を送った話 #OSSコントリビュート

AI が書いて AI が審査する OSS へ再現と検証を添えて修正を送った話 #OSSコントリビュート

Beads で踏んだ不具合を Claude Code と直し、上流へ送りました。送った先の開発元も、AI で修正を作り直して審査していました。結論としては、AI が修正を書き、AI が審査する場でも、受け入れの決め手は不具合の再現と修正の検証でした。
2026.11.03

はじめに

Beads を Claude Code と組み合わせて使っているなかで、stealth で初期化していないリポジトリでもエージェントが git 操作をためらうようになりました。原因は bd init --stealth が設定をユーザー設定へ書き込む不具合でした。Issue と修正の PR を送り、マージされました。修正を AI が書き、審査も AI が行う場でも、受け入れの決め手は不具合の再現と修正の検証でした。

本記事では、Beads を使っている方に向けて確認と対処の方法を書きます。また、AI エージェントで OSS へ修正を送りたい方に向けて、送ってみて感じたことを書きます。

なお、Beads の使い方については過去に次の記事で紹介しています。

https://dev.classmethod.jp/articles/beads-agent-state-management-automation-scope/

https://dev.classmethod.jp/articles/beads-priority-and-notes-operation/

Beads とは

Beads は、AI コーディングエージェント向けの課題管理ツールです。bd コマンドで課題と依存関係を管理し、bd prime の出力をエージェントのセッションへ注入して、作業の文脈を引き継げます。

https://github.com/gastownhall/beads

不具合と対処

bd init --stealth は、Beads のファイルを git の管理対象から外し、リポジトリを汚さずに初期化するオプションです。stealth で初期化したリポジトリには設定 no-git-ops: true が書き込まれ、bd prime がエージェントへ git 操作を行わないよう指示します。

ところが、ユーザー設定のファイルが既にあり、リポジトリ側の設定ファイルがまだ無い状態で初期化すると、この設定がユーザー設定へ書き込まれていました。ユーザー設定は同じマシンの全リポジトリで読まれるため、stealth で初期化していないリポジトリでも同じ指示が出ます。git コマンドの実行自体が止まるわけではありません。エージェントが指示に従って git 操作を控えるという形で現れます。

原因は、設定の保存先を起動時に読み込んだ設定ファイルにしていたことです。初期化の時点ではリポジトリ側の設定ファイルがまだ無いため、保存先はユーザー設定のままでした。

修正では、保存先をリポジトリの .beads ディレクトリに明示するよう、次の 1 行を置き換えました。

cmd/bd/init.go
 			if stealth {
-				if err := config.SaveConfigValue("no-git-ops", true, beadsDir); err != nil {
+				if err := config.SetYamlConfigInDir(beadsDir, "no-git-ops", "true"); err != nil {
 					fmt.Fprintf(os.Stderr, "Warning: failed to set no-git-ops in config: %v\n", err)
 				}
 			}

※実際の差分には理由を説明するコメントも含まれますが、ここでは省いています。

影響の有無は、stealth で初期化していないリポジトリで値を表示すると確認できます。true が返れば、ユーザー設定から漏れている可能性があります。

check-no-git-ops.sh
bd config get no-git-ops
grep -n no-git-ops ~/.config/bd/config.yaml

bd config show は値ごとに出所を表示しますが、手元の v1.1.2 では、ユーザー設定から来た値でも出所が (config.yaml) と表示され、リポジトリ側の設定と区別できませんでした。そのため、ユーザー設定のファイルを grep で直接確認します。

見つかった行は、エディタで削除します。開発元のレビューでも指摘されているとおり、bd config unset no-git-ops はリポジトリ側の設定を編集するため、ユーザー設定の行は消えません。stealth を使うリポジトリでは、.beads/config.yaml に no-git-ops: true があることもあわせて確かめておくと安心です。

修正は 2026 年 11 月 2 日にマージされましたが、執筆時点の最新版 v1.3.2 には含まれていません。修正を含む版が出るまでは、同じ条件で stealth の初期化をすると再び書き込まれる点に注意してください。

上流への貢献

Issue #7938 で現象と再現手順を報告し、次の PR を送りました。

https://github.com/gastownhall/beads/pull/7939

調査・実装・文案の作成は Claude Code に任せました。不具合が本物であることを示すため、Claude Code に指示し事実確認を徹底しました。 具体的には、ダウンロードした公式バイナリを隔離した環境で動かして再現を確かめ、修正前に失敗し修正後に成功するテストを、開発元の手順どおり Linux のコンテナで取り直しました。また、原因の説明に、不具合が入ったコミットを根拠なく断定した箇所があったため、別のモデルに計画を反証させて取り下げました。PR には、再現手順、原因、修正前後のテストの結果を含めました。

Beads の開発元は、PR を AI のエージェント群で処理するパイプラインを運用しています。 PR を受け取ったパイプラインは不具合を再確認し、私の PR とは別に 2 つの修正案を独立に作って比べました。3 案の修正の中身は同じで、テストはより分離性の高い版に置き換わりました。その後、外部のレビュアーが Issue に書いた再現手順をそのまま実行して、修正前に不具合が出て修正後に出ないことを確かめました。審査では、修正を戻すとテストが失敗し、修正後に成功することが確かめられました。最後に、メンテナによる承認を経てマージされました。

学び

今回は、私の側では Claude Code が修正を書き、開発元の側ではパイプラインが同じ修正を独立に作って審査しました。修正のコードは双方の AI が同じものを作れたため、判断の拠り所になったのは、不具合が本物であることと、修正で直ることの証拠でした。 AI が書いて AI が審査する場では、再現と検証を自分で確かめて PR に添えることが、送る側の最も大事な仕事だと感じました。

さいごに

bd init --stealth を使ったことがある方は、ユーザー設定の no-git-ops の行を確認してみてください。AI エージェントと OSS の修正を作る方は、再現と修正前後の検証を自分で確かめ、PR に添えて送ってみてください。PR を受け入れてくださった Beads の開発元の皆さんに感謝します。本記事が、Beads を使っている方や、AI で OSS へ貢献したい方の参考になれば幸いです。


Claudeならクラスメソッドにお任せください

クラスメソッドは、Anthropic社とリセラー契約を締結しています。各種製品ガイドから、業種別の活用法、フェーズごとのお悩み解決などサービス支援ページにまとめております。まずはご覧いただき、お気軽にご相談ください。

サービス詳細を見る

この記事をシェアする

AI白書

関連記事