ループの書き方

不具合の報告や機能の要望を受け取り、AIに調査・変更・検証を繰り返してもらう。その流れは、最初から常時自動実行にしなくても作れます。まずは1件を手動で渡し、「何を確かめたら終わるか」と「どこで人に戻すか」を決めましょう。

ここでは、コードの参照・編集・テスト実行ができるAIを想定します。チャットだけを使う場合は、人が変更とテストを行い、結果をAIへ返す形で試せます。

1章 AIに渡す作業と完了条件を用意する

最初に、作業の入口を1つに絞ります。不具合の報告票でも、要望をまとめたメモでも構いません。対象のコード、実行できるテスト、変更してよい範囲を添えます。

「絞り込みを直して」だけでは、AIが期待する動作を推測してしまいます。完了条件は、実際に確認できる形にします。次のような依頼を、作業指示の土台にできます。

対象は一覧の絞り込み処理です。まず関連コードを読み、原因候補と修正方針を示してください。変更は一覧と関連テストに限定します。完了条件は、指定条件に一致する項目がすべて表示され、条件を解除すると全件に戻ることです。既存テストも実行してください。仕様が不明な場合や変更範囲が広がる場合は、編集を止めて質問してください。反映は人が判断します。

一度に複数の問題を渡すより、まずこの1件で、入力から検証結果の報告まで通せるかを確かめます。

2章 バグ修正のループを作る

例として、「未完了の項目が3件あるのに、未完了で絞ると2件しか表示されない」という不具合を扱います。AIには、操作だけでなく、確認に使うデータも渡します。

• 準備：未完了3件、完了2件のデータを用意する。
• 操作：一覧で「未完了」を選ぶ。
• 現在の結果：未完了の項目が2件表示される。
• 期待する結果：未完了の3件が表示される。

AIには、まずコードと再現結果から原因を調べてもらいます。この時点では原因を決めつけず、どの処理が結果の欠落につながるのか、根拠を示してもらいましょう。

修正方針が作業範囲に収まっていれば、変更とテストへ進めます。繰り返しの条件も、指示として書いておきます。

修正後に、未完了での絞り込み、完了での絞り込み、条件解除を確認してください。失敗した場合は、期待する結果と実際の結果を比較し、原因を見直して再修正してください。確認のために完了条件を緩めないでください。各回の変更点と検証結果を記録してください。

人がテストする場合も、「まだ直っていない」ではなく、「未完了は3件になったが、条件解除後も3件のまま」と返します。観察した結果が具体的なら、AIも次に調べる場所を絞りやすくなります。

エラー表示が消えただけでは完了にしません。期待する件数が表示されることと、隣接する操作が引き続き動くことを確認します。実行できなかったテストは、未確認として報告してもらいます。

3章 機能開発のループを作る

今度は「一覧を優先度でも絞り込みたい」という要望を考えます。機能追加では、実装前に動作を決める必要があります。選択肢は何か、既存の絞り込みと併用できるか、解除するとどうなるかを整理します。

AIへの最初の依頼は、コード変更よりも要望の整理に向けます。

一覧に優先度の絞り込みを追加したいです。実装前に、決める必要がある項目を挙げてください。未決定の仕様は推測で確定せず、確認事項としてまとめてください。

例えば、人が「高・中・低を1つ選ぶ」「未完了条件と同時に使える」「未選択なら優先度で制限しない」と決めたら、その内容を完了条件に書き直します。「未完了かつ優先度が高の項目だけが表示される」のように、組み合わせも含めて確認できる表現にしましょう。

合意した条件をAIに渡した後は、小さく実装し、検証で不足が見つかれば変更へ戻します。

変更を試す場所を分ける方法に、ブランチがあります。ブランチは、元のコードから作業を分けて変更を進める仕組みです。次の模式図では、featureが機能追加、hotfixが緊急修正の作業に対応します。枝分かれした変更を確認してから合流させる、という関係に注目してください。この分岐構成をそのまま採用する必要はありません。

Qeef / 画像の出典 / CC BY-SA 4.0 / 表示用縮小版を使用。

4章 繰り返し実行の開始・停止を設定する

1件を通せたら、入力を定期確認する仕組みにつなぎます。定期実行は、利用するAIや外部の実行環境が対応している必要があります。AIへの指示を書くだけで、継続的な監視が始まるわけではありません。

実行環境に設定する条件と、AIに渡す判断ルールを合わせます。例えば、次のように決めます。

• 開始：10分ごとに作業一覧を確認し、「着手可能」のうち優先度が最も高い1件を選ぶ。
• 重複防止：作業IDと状態を保存し、着手時に「処理中」にする。同じIDを同時に開始しない。
• 再試行：最初の変更後、検証失敗による再修正は最大2回とする。
• 中断：仕様不明、必要な権限の不足、変更範囲の拡大、再試行上限への到達で止める。
• 引き渡し：条件を満たしたら「確認待ち」にし、人が変更内容と検証結果を確認する。

これは設定例です。最初は対象を1件ずつにすると、どの作業が何を変更したか追いやすくなります。複数の実行を同時に動かす場合は、作業状態を記録するだけでなく、同じ作業を同時取得しない仕組みも必要です。

AIの報告には、変更内容、完了条件ごとの結果、未確認事項を含めます。コードの統合や公開まで進める権限は、確認待ちにする段階とは分けて設定します。

5章 実行結果を次の指示に反映する

作業が終わったら、長い会話を残すだけでなく、次にも使える短い記録を作ります。「何を変更したか」「何を検証したか」「どこで止まったか」の3点で十分です。

例えば、絞り込みの修正後に条件解除の確認が抜けていたなら、次の依頼から「条件を解除した場合も確認する」を追加します。仕様の質問が何度も発生したなら、入力メモに「既存条件と併用したときの動作」という欄を設けます。

記録した内容が次回に自動で引き継がれるとは限りません。次の指示に添えるか、AIが参照する共通の作業ルールへ反映します。まずは小さな不具合を1件選び、完了条件と停止条件を渡して、検証結果が揃うところまで試してみましょう。