失敗談5分で読める要約版2026-10-18

AIにバグ修正を任せる前に、原因と修正方針を分けて確かめる

軽いバグ修正のつもりが、レビューと差し戻しの往復になりました。原因が分かったことと、そのまま実装できる方針が揃ったことは別でした。AIへの指示の不足と、修正候補の実装ミスを分けて振り返ります。

停止の印なのに、開くとまだ処理している

個人開発のmany-ai-cliのRust版で、黄色い停止表示が気になりました。まだ開いていない停止を知らせる印なのに、処理中でも付くことがありました。

原因をMarkdownにまとめ、子セッションへ実装と検証を任せたこと自体は意図どおりです。ただ、開始と終了の対応や再接続などを後から確認する形になり、修正候補の実装ミスも重なって手戻りが続きました。

終了通知の条件まで広げたのは親側の判断でした。モデルやエフォートの違いは比較しておらず、子の性能だけを原因にはできません。

旧処理では、端末の出力が3秒途切れるとHubが作業中の状態も落としていました。画面側の5秒という条件は作業時間の下限で、無出力を待つ時間ではありません。待ち時間を延ばすだけでは、静かな処理を取りこぼします。

最後はCodexの開始・完了・中断の記録を使い、Hubが作業中の状態を保持する修正に絞りました。無出力でも現在のターンが続いていれば作業中を保ち、対応する終了で既存の判定へ戻します。画面側の新しい判定や通信は増やしていません。

bugfixの文書が「調査を始められる依頼」なのか「すぐにコードを直せる依頼」なのかを分けることにしました。使う証拠がどこで作られ、開始と終了をどう対応させるかまで確認してから実装へ渡します。

不明点が方針を左右するなら、その調査から任せます。手戻りが続いたら編集を足す前に方針を見直す。この仕組みはまだ設計提案で、共通ルールへの導入や効果の検証はこれからです。

修正案が行き詰まった経緯、採用した範囲、確認済みと未確認の境界はQiitaの全文にまとめています。