2026-10-10訂正：旧題名の「バグのないコードが勝手に完成」、未裏付けの稼働・納品実績、削減率を撤回しました。費用の算術、GPT-5.4料金、Judgeの費用、削除行を失うコード例を訂正しています。以下は設計案と仮定を置いた試算であり、パイプラインの通し動作・本番稼働は今回確認していません。
1. はじめに：生成・レビュー・テストをどう分担するか
AIによるコード生成を継続的な開発に使うには、生成結果を確認し、失敗時に止め、変更を安全に採用する仕組みが必要です。レビューやテストの一部をAIとツールへ分担しても、仕様の判断や採用責任は残ります。
本記事では、n8nを使い、**Writer（実装）、Critic（レビュー）、Judge（検証結果の整理）**を分ける構成を示します。異なるモデルを使うことやテスト通過は、バグがないことの証明ではありません。処理回数と費用を制限し、人間へ戻す条件を明示することが設計の中心です。
2. アーキテクチャ：役割を分けたレビュー・修正ループ
1つのLLMに生成と自己評価を任せると、同じ見落としを繰り返す可能性があります。ここでは役割を分け、固定したテスト結果と変更差分を確認できるようにします。モデル間の合意も、正しさを保証しません。
各エージェントの役割
| 役割 | モデル・ツールの例 | 担当すること |
|---|---|---|
| Writer | Claude Sonnet 4.6 | 要件と制約に沿ったコード生成 |
| Critic | GPT-5.4 | 境界条件、権限、状態、エラー処理のレビュー |
| Judge | Gemini 3.1 Pro Preview | テスト結果とレビュー指摘の整理 |
| テスト実行 | E2B | 隔離した環境で事前に定義したテストを実行 |
| 採用判断 | 人間 | 原典・差分・検証結果を確認し、採用や公開を判断 |
モデルは役割の候補で、比較評価による優劣の証明ではありません。Geminiの試算に使うAPIモデル名はgemini-3.1-pro-previewです。
ループの流れ
- 人間が要件、入力・出力、制約、完了条件、必要なテストを用意する。
- n8nがWriterに実装を依頼する。
- Criticが変更箇所をレビューする。
- E2B等で固定したテストを実行し、Judgeが結果を整理する。
- 不合格なら上限内で修正し、上限到達・結果不明なら保留する。
- 合格候補を
pending_reviewとして保存し、人間へ確認を依頼する。
旧稿の「70点以上ならデプロイ可」は削除しました。LLMの採点は補助情報です。テスト条件、重大なレビュー指摘の解消、独立レビュー、人間の承認を採用条件にし、公開・デプロイ・納品は別の許可を必要とします。生成コードは信頼できない入力として扱い、テスト環境にも本番の認証情報や不要な外部通信権限を渡しません。
3. ループ回数とAPI費用を制限する
コード全量や履歴を繰り返し送ると、入力費用と待機時間が増えます。旧稿はこの問題を実測した事例のように書いていましたが、請求証跡を示せないため実績の主張を撤回します。
旧試算の算術訂正
旧稿に記載した条件をそのまま計算すると、次の値です。
15,000 tokens × 3モデル × 50回 × 5タスク × $10 / 1,000,000
= $112.50 / 日
$112.50 × 30日 = $3,375 / 月
旧稿の$337 / 日は計算誤りでした。上の$10 / 1Mも仮の混合単価であり、入力と出力を分けた各社の料金や実際の請求額を表しません。最適化後とタスク数・反復数・品質が異なるため、両者から削減率は算出しません。
対策①：修正の種類に応じたモデル選択
複雑な設計と限定した修正で、同じモデルを使う必要があるかを評価します。Claude Haiku 4.5等の安価な候補へ切り替える場合も、同じテストとレビュー条件を維持します。安価なモデルで失敗が増えるなら、再処理込みの費用が高くなることがあります。ローカルモデルにも計算資源や保守の費用があります。
対策②：削除を失わない変更コンテキスト
旧稿の「変更後の行だけを比較するコード」は、削除された行を出力できませんでした。例えばsafe\nunsafeからsafeへの変更を、差分なしと誤認します。
正しいunified diffが用意できる場合はそれを渡します。用意できない場合は、レビュー対象を1ファイルに絞り、変更前と変更後の両方を渡す方が、削除情報を落とす独自差分より確実です。以下は後者の例で、差分生成器ではありません。
// n8n Codeノード。上流で同じ対象ファイルの両版と試行番号を用意する。
const { before_code, after_code, feedback, attempt_count } = $input.first().json;
if (typeof before_code !== 'string' || typeof after_code !== 'string' ||
typeof feedback !== 'string') {
throw new Error('Missing code or review feedback');
}
if (!Number.isInteger(attempt_count) || attempt_count < 1 || attempt_count > 3) {
throw new Error('Invalid attempt count');
}
return [{
json: {
system_prompt: 'Review the same file before and after the change. Preserve intended deletions. Return the complete corrected file.',
before_code,
after_code,
critic_notes: feedback,
attempt_count,
},
}];
この例の入力検証はローカルで確認しました。n8nへの組み込みは未確認です。ファイル名・コミット等の対応付けは上流で行い、異なる版を混ぜないようにします。依存箇所が必要な場合は文脈を追加し、トークン削減だけでレビューの品質を落とさないことが前提です。
対策③：試行回数・費用・時間の上限と保留先
**最大試行回数を3回（初回を含む）**と定義します。1回目の失敗後は2回目、2回目の失敗後は3回目へ進み、3回目も失敗したら再生成せずDLQ等へ保留します。上のコードは番号の検証だけで、カウンターの更新や分岐は別途n8n側で実装します。
試行回数に加え、1タスクの入力・出力上限、総予算、実行時間を制限します。記録には要件ID、対象版、試行番号、失敗理由、テスト結果、pending_review等の状態を残します。秘密情報を含む入力全文を通知しません。
通信タイムアウトでは結果が不明なことがあります。保存・通知などの副作用が確定したかを確認し、同じ処理を二重に実行しないようにします。自動処理の保留と、成果物の採用・納品完了を区別します。
費用試算：全3モデルとサンドボックスを含める
以下は1日5タスク、各役割1呼び出し、修正なしという仮定です。APIの標準USD単価を2026-10-10に確認しました。Geminiの出力1,000トークンはthinkingを含む課金対象出力の仮定です。
| 呼び出し | 1回の入力 / 出力 | 入力 / 出力単価（1M） | 5回分の費用 |
|---|---|---|---|
| Writer: Claude Sonnet 4.6 | 8,000 / 2,000 | $3 / $15 | $0.2700 |
| Critic: GPT-5.4 | 6,000 / 1,000 | $2.50 / $15 | $0.1500 |
| Judge: Gemini 3.1 Pro Preview | 6,000 / 1,000 | $2 / $12（入力200k以下） | $0.1200 |
| E2B: 2 vCPU・4 GiB | 10秒 × 5実行 | $0.000046 / 秒 | $0.0023 |
| 合計 | $0.5423 / 日 |
$0.5423 × 30日 = $16.269 ≒ $16.27 / 月です。再試行、n8n基盤、保存・通信、固定プラン料金、税、為替等は含んでいません。E2Bの10秒はコードの処理時間だけでなく、課金対象のサンドボックス稼働時間としての仮定です。準備・待機・停止まで長ければ増えます。
追加のHaiku 4.5呼び出しを入力2,000・出力500トークンと仮定すれば、2,000 × $1 / 1M + 500 × $5 / 1M = $0.0045 / 回です。修正時にはCritic、Judge、テストも追加され得るため、この額だけを修正ループの総費用とは扱いません。
料金の根拠：Claude Sonnet 4.6、Claude Haiku 4.5、GPT-5.4、Gemini API、E2B。実際のusage、サンドボックス稼働時間、請求を照合するまで、月額や削減率を運用実績とは呼びません。
4. 設計フロー：合格候補と保留を分ける
旧稿の「約30秒で納品した」という記述を撤回します。以下は実行証跡ではなく、実装する際のフロー案です。
外部呼び出しの失敗や結果不明も、通常の成功経路へ流さず保留へ送ります。通知はレビュー依頼や保留の知らせであり、「納品完了」ではありません。
5. まとめ：自動化する範囲と止める条件を決める
役割分担は、生成結果を検査し、必要な確認を人間へ戻すための設計です。複数モデルの利用だけで品質は保証できません。
導入前に、同じ要件・固定テストで合格率、見落とし、再試行回数、総費用、確認工数を比較します。本稿で確認したのは公式料金、試算の算術、掲載Codeノード例のローカル処理です。n8n・各モデル・E2Bをつないだ通し動作と、実際の改善効果は未確認です。
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表。AI × Web × 業務自動化の開発・検証に取り組んでいます。
技術選定・品質・運用の判断材料を、検証範囲と制約を示して発信しています。
AI導入や業務自動化の技術選定・設計整理については、対応できる範囲を確認のうえご相談を承ります。