HydraFusionに「レビュー0件まで」と頼んで、修正ループの終わり方を考えた

HydraFusionを使ってコード修正を回してみた。私が出していた指示は「レビュー指摘がゼロになるまで」。ゴールまで自走してもらうつもりだったが、レビューと修正が長引き、途中で中断した。

この記事では、「レビュー指摘がゼロになるまで」という依頼を、実際の動作で完了を確かめられる依頼に変える方法を紹介する。

• やりたいことと制約を書き込んで使える、修正・検証ループの指示テンプレート。
• 不具合は直し、任意の改善は別件にするための、追加指摘の扱い方。
• 小さな例題で指示を実際に使った結果と、自分で確認できるコード。

後から振り返って、まず見直したいと思ったのは自分の指示だった。ウォーターフォールの開発に慣れていて、「各フェーズのレビューが終われば、次へ進める」という感覚を、AIへの頼み方にも持ち込んでいたのだと思う。「何が動けば直ったと言えるか」よりも、「次のレビューで指摘が出ないこと」を完了の基準にしていた。

HydraFusionは、複数モデルを組み合わせて作業を進める仕組み。GitHub公式記事では、全Copilotプラン向けのResearch Previewとして案内されている。GitHub公式の紹介記事（2026年9月5日取得）

不具合は見つかり、修正も進んでいた

今回直していたのは、メールから情報を抽出して記録し、確認や訂正の後に処理を進める仕組みだった。業務固有の名前は省くが、以下は実際に起きたこと。

レビューでは、メールの署名にある住所を本文の対象所在地と取り違える、正しい価格を抽出できない、再取り込みで既存の状態を変えてしまう、といった問題が見つかった。

実害のある指摘だったし、修正と回帰テストも積み上がった。一方、誤った価格を拾わないようにした変更で、正常な価格まで取れなくなる場面もあった。

累積した差分を広くレビューし、追加の指摘を直し、またレビューする。私は途中で状況を尋ね、最後は中断を頼んだ。

「指摘ゼロ」を、直ったことの代わりにしていた

セッションを振り返ると、一度は「最終レビュー問題なし」と完了報告が出ていた。その後、元の問題に関わる指摘が持ち込まれた。レビュー担当が指摘しなかったことだけでは、頼んだ修正が済んだかを確認しきれていなかった。

どこまで直すかを、その都度のレビューに委ねていた。

この終了条件が、反復を長引かせた一因だったと私は考えている。指摘が増えれば直す対象も増える一方、指摘が出なくなっても、元の入力で期待どおりに動くとは限らない。

今回、本当に直したかったことは、動作として書けた。

新しい指摘を無視したいわけではない。ゴールを妨げる不具合と、今回の修正で生まれた不具合は直す。そのうえで、任意の改善まで今回の完了条件に足すかは、AIに判断してもらいたい。

後半は、残った問題と期待結果を揃えて仕上げた

中断後の仕上げでは、前半の実装とテスト、過去のレビューで揃った再現例を引き継いだ。AIが残件と手順の矛盾を整理し、担当ファイルと期待結果を渡して修正する。追加の指摘は同じ担当に戻し、AIが差分・テスト・実際の出力を確認した。

訂正後の再開や、人が保留した状態の保持も確認して、残った修正を終えた。前半の成果を使って仕上げたので、これをモデル同士の性能比較にはできない。

私にとって参考になったのは、AIが「どの条件がまだ満たされていないか」を見て、次の修正と完了を判断していたことだった。

次は、ゴールから合格条件を作ってループさせたい

毎回こちらが作業を切り分け、レビュー結果を別の担当へ転記するのは避けたい。ゴールを渡したら、その先の分担と判断も任せたい。

次はAIに、現行コードとゴールから合格条件を作ってもらう。条件は、入力と期待結果で確かめられる形にする。仕様から決められない期待結果だけは、人に確認してもらう。

未達なら、原因を再現して修正し、AIが動作を確認する。同じ原因で失敗が続いたら、発注を絞る、調べる箇所を変える、AIが該当部分を引き取る、といった方法の変更も任せる。

小さな例題で、指示を実際に使って確かめた

テンプレートを載せるだけでは使えるか分からないので、この記事のためにPythonの例題を作った。実際の業務コードとは別の、メモリ内の記録を更新する短い処理だ。情報不足の記録を訂正しても再開できず、人が保留した記録は再取り込みで保留が解除される、という不具合を入れた。

下のテンプレートの記入欄をこの例題で埋め、【役割】以降はそのまま、別のAI担当に渡した。事前に8条件の確認コードも用意し、変更を禁止した。任意の改善を別件にできるかを見るため、「状態名の日本語化は任意の改善」と明記した指摘も添えた。

AIは状態の更新処理を修正し、確認コードを実行した。さらに、情報がない場合や空文字、繰り返し取り込む場合を追加で確かめ、別担当の独立レビューを経て完了を報告した。状態名の日本語化は別件として残した。

例題一式をダウンロードする。修正前後のコード、仕様、実際に渡した指示、確認コード、実行報告を入れてある。展開した goal-completion-loop フォルダで、次のコマンドを実行して結果を確認できる（2026年9月5日、Python 3.14.6で確認）。

python3 -B check.py initial.py

new_ready: PASS
new_waiting: PASS
correction_resumes: FAIL
human_hold_survives: FAIL
ready_to_missing: PASS
same_id_once: PASS
note_survives: PASS
other_record_survives: PASS
6 passed, 2 failed

python3 -B check.py ingest.py

new_ready: PASS
new_waiting: PASS
correction_resumes: PASS
human_hold_survives: PASS
ready_to_missing: PASS
same_id_once: PASS
note_survives: PASS
other_record_survives: PASS
8 passed, 0 failed

この例題では、必要な不具合を直し、任意と明記した改善を別件にして終えられた。ただし修正は1回で通っており、失敗を重ねた後の方法変更は試せていない。「指摘ゼロまで」という指示との比較もしていないので、長い作業が短くなるとまでは言えない。HydraFusionでの再実験でもない。

自分の依頼に書き換えて使う指示全文

振り返りで整理した指示を、他の修正にも使える形にした。前半の［ ］を自分の依頼に書き換え、後半の【役割】以降は共通の指示として使う。問題や再現入力は分かっている範囲でよく、不明なところは調査を任せる。上の例題では、この共通部分を変えずに使った。

【ユーザーが記入：ゴール】
［何ができる状態にしたいかを書く］

【ユーザーが記入：解決する問題】
対象：［リポジトリ・機能・処理など］
困っている動作：［現在どうなっているか］
期待する動作：［どうなってほしいか］
再現入力・手順：［分かれば記入。不明なら「調査を任せる」］
参考資料：［関連する指摘・ログ・仕様など。なければ「なし」］
※ 問題が複数あれば、問題ごとに現在の動作と期待する動作を書く。

【ユーザーが記入：変更で守ること】
維持する動作・データ：［変えてはいけないもの］
変更禁止の対象：［ファイルや外部サービスなど。なければ「なし」］
操作の許可範囲：［commit・push・公開・送信などの可否］
予算・期限：［制限があれば記入。なければ「指定なし」］
実装担当：［使いたいモデル。指定しなければ「AIに任せる」］

【役割】
あなたが全体設計・作業分担・最終検証・完了判断を担当する。
私は途中の発注やレビュー結果の転記を担当しない。
範囲を限定できる実装修正は、指定した担当へ委譲する。
指定がなければ、利用できる担当から選ぶ。
指定されたモデルが使えなければ報告する。小さな修正は自分で行ってよい。

【着手前の確認】
AGENTS.md、現行コード、仕様、未コミット差分を読む。
既に解決済みの項目、残件、再現確認が必要な項目を分ける。
途中の修正を一括で取り消さず、動く部分を活かして必要な箇所を直す。

ゴールと各問題から、入力と期待結果で確かめられる合格条件を作る。
正常な入力、問題が起きる入力、再実行・再開、既存状態の保持など、
今回の処理に必要な観点を選ぶ。条件がゴールを表しているかも確認する。
仕様から決められない期待結果は、人に確認する。
残件・変更箇所・合格条件を短く示したら、作業を進める。

【進め方】
1. 担当にファイル、再現入力、期待結果、変更禁止事項、検証方法を渡す。
   同じファイルを複数担当に並行編集させない。
2. 未達の条件を確認し、原因を再現する。呼び出し元も調べて修正する。
   再現するテストを用意し、期待結果を弱めて通さない。
3. 担当の完了報告に加え、あなた自身が差分・テスト・実際の出力を確認する。
   関連する手順書のコマンドも実行し、処理全体がつながるか確かめる。
4. 統合後に独立レビューを行う。
   ゴールを妨げる不具合と、今回の変更で生まれた不具合は直す。
   任意の改善は別件に記録する。合格条件の不足は補い、条件を弱めない。
5. 未達なら、原因と発注内容を更新して続ける。
   同じ原因で2回失敗したら、設計・再現方法・担当のいずれかを見直す。
   必要なら自分で引き取る。これは停止ではなく、方法を変える条件とする。

【完了条件】
・ゴールと各問題に対応する合格条件をすべて満たしている。
・関連する既存テストが通り、処理全体の動作確認が済んでいる。
・コード・手順書・保存データの動作や説明に矛盾がない。
・ゴールを妨げる既知の不具合と、今回生んだ既知の不具合が解消している。
未確認の条件を合格扱いにしない。

【人に判断を戻す場合】
通常の技術判断や再試行は、与えられた権限・予算・期限の範囲で進める。
人の意思決定や追加の権限が必要な場合、または制約の範囲で
続行できない場合は、未達条件と必要な判断を報告する。
公開・送信・破壊的な操作の許可は、この指示から推定しない。

【報告】
途中では、解決したこと・残る未達条件・次に試すことを簡潔に報告する。
最後に、変更内容、合格条件ごとの検証結果、残る制約、別件にした改善を示す。
所要時間と取得できる実測利用量を、メイン・担当別に記録する。
計測範囲と取得できない内訳を明記し、推測値で埋めない。
commitなどを許可され実行した場合は、その結果も報告する。

今回の修正なら、記入欄はこう書く

今回の依頼を、業務固有の名前を省いて記入例にすると次のようになる。当時の指示の逐語引用ではなく、振り返りを踏まえて書き直したもの。この後に、上の【役割】以降を続けて渡す。

【ユーザーが記入：ゴール】
メールから必要な情報を正しく抽出し、誤りを訂正した後は
処理を再開できるようにしてください。
再取り込みで、人が選んだ保留状態を変えないでください。

【ユーザーが記入：解決する問題】
対象：メールの情報抽出と、取り込み後の状態更新処理

問題1：対象ではない項目の情報を抽出してしまう
現在の動作：署名の住所を、本文の対象所在地として拾うことがある。
期待する動作：本文の対象所在地と署名の住所を区別する。
再現入力・手順：誤抽出が起きたメールを使う。
対象所在地が書かれていない場合も、署名で補わず不明として扱う。

問題2：情報を訂正しても処理を再開できない
現在の動作：元の情報で正しい値が分かっても、保留から進めない。
期待する動作：訂正内容と根拠を保存し、次の確認作業へ進める。
再現入力・手順：情報不足で止まった記録を訂正し、再開操作を行う。

問題3：再取り込みで人の判断が変わる
現在の動作：人が保留した記録を再取り込みすると、状態が変わる。
期待する動作：同じ入力を再処理しても、人が選んだ保留状態は残る。
再現入力・手順：人が保留した記録に対し、同じメールを再取り込みする。

参考資料：今回のレビュー指摘、誤抽出が起きた入力、既存の処理手順

【ユーザーが記入：変更で守ること】
維持する動作・データ：正常な情報は引き続き抽出できること。
不明な値を確認済みとして扱わないこと。人が確定した状態を保持すること。
変更禁止の対象：取り込み元のメールと、確定済みのレポート
操作の許可範囲：ローカルの修正・テスト・commitまで。
push、メール送信、外部への公開は行わない。
予算・期限：指定なし
実装担当：gpt-5.6-luna

人が書くのは、困っている動作と、どうなってほしいかまで。どのファイルを直すか、どのテストで確かめるかは、AIに調べてもらう。

「同じ原因で2回失敗したら」は、方法を切り替えるために置いた目安で、最適な回数を測ったものではない。止める回数を決めたいのではなく、進まないときの判断までAIに任せたい。

AstraからHydraFusionへ任せる分担も試したい

公式記事では、現プレビューは範囲が明確な単一プロンプトのコーディング作業を推奨し、長い反復セッションの改善は今後の重点としている。GitHub公式の紹介記事（2026年9月5日取得）

今回の記録から分かるのは、利用者から見える担当への依頼と作業結果まで。HydraFusion内部のモデル選択が長期化の原因だったとは言えない。

次は、Astraが全体の合格条件と完了判断を持ち、HydraFusionへ独立して検証できる修正を渡す分担も試したい。Astra→HydraFusionは未実施の案。

あなたが全体のゴール・合格条件・統合検証・完了判断を担当する。
独立して検証できる修正をHydraFusionへ委譲する。
利用環境で指定できなければ報告する。

各依頼に、担当範囲・再現入力・期待結果・守るべき既存動作を渡す。
内部のモデル選択はHydraFusionに任せる。
返ってきた変更は、あなたが合格条件で検証する。
不合格なら原因を絞って差し戻し、必要なら自分で引き取る。

全体を管理するAIと実装担当の両方で調整やレビューをすれば、待ち時間や費用が増える可能性もある。この分担の効果は、これから確かめたい。

人が「まあ、いいか」で終えていた判断も、条件にする

これまで自分が経験したレビューでは、本来実装したい機能とは関係のない指摘も多かった。たとえば、設計書のフォントが違う、全角と半角の数字が揃っていない、罫線の太さが違う、といった指摘もあった。何度か直してレビューするうちに、最後は人の裁量で「まあ、いいか」と終えていた場面もあったように思う。どこまで揃えるかの基準を、すべて明文化していたわけではなかった。

AIに「指摘がなくなるまで」と頼んでも、その裁量まで同じように働くとは限らない。今回直す必要のない細部も問題として扱い、修正とレビューを続ける可能性がある。人との作業で暗黙に済ませていた「今回はここまで」を、指示には書いていなかった。

今回のレビューは実際の不具合も見つけていたので、指摘を減らすことだけを考えたいわけではない。ゴールを妨げる不具合と、修正で生んだ不具合は直す。任意の改善は別件にする。そして、最初に直したかった動作を確かめて終える。その判断までAIに任せたい。

ループで任せるなら、完了条件を明確にする。「指摘が出なくなるまで」から「この動作が確認できるまで」へ、頼み方を変えてみる。今回の記事から、これを持ち帰ってもらえればうれしい。