AIエージェントを2セッション×各6〜8体で並列に走らせ、自社のWebツール棚を1日で29本から100本に増やしました。
並列化で品質が落ちる原因は、エージェントの能力よりも「指示の書き方」と「成果の受け取り方」の設計にありました。
本記事では、その日にバグを4件見つけた過程から、効いた条件と踏んだ落とし穴を手順の形でまとめます。

前提

作業内容: ブラウザで動く小さなWebツール（消費税計算・勤務時間計算・角印作成・PDF処理など）を1本ずつ追加する
体制: 親セッション1つからサブエージェントを起動し、1体に1ツールを割り当てる
規模: 2セッション×各6〜8体を並列実行
構成: 各ツールは <ツール名>/app.js に本体があり、台帳（JSON）・一覧ページ（HTML）・共通CSSを全ツールで共有している
検査: 公開一覧と、ツールごとの合格条件をまとめた検査表を突き合わせて出力を確かめる

結果は29本→100本。見つかったバグは4件、エージェントが指摘した「指示そのものの誤り」が2件でした。

手順：並列で回すときの指示と受け取りの設計

1. 検査の中身をプロンプトに書き込む

最も効いたのが手順1です。「実装して」だけを渡すと、エージェントは「動いた」の時点で止まります。検査の中身を具体的に書いて初めて、欠陥が表に出てきます。

悪い例:
消費税ツールを作って。検証してから終わること

良い例:
端数処理3通り（切捨/四捨五入/切上）で数字を出せ。
105円×10%=10.5 がそれぞれいくつになるか報告に含めよ

良い例の指示で、実際にバグが出ました（後述の「起きたこと」1）。

2. 実装の判断根拠を報告に書かせる

「なぜその実装にしたか」を報告に書かせると、根拠を書けない判断が本人に見えるようになります。実際に返ってきた根拠は次の3つです。

角印の2文字を上下に積んだ理由: 「2列だと『山田』が左から読まれて『田山』に見え、誤解を生む」
字形を枠に合わせる際、縦横比の歪みに上限を入れた理由: 「上限が無いと『一』が枠いっぱいの棒に化ける」（実際に『一』で検品したうえでの報告）
拡大した画像が少しぼやけることを、指示されないままFAQへ書いていた

3. 指示を疑ってよい、と明示する

最も質の高かった報告は「指示された仕様に無理があるので、実装せずに報告します」でした。以後、プロンプトに次の一文を入れています。

指示された仕様に無理があると判断したら、実装せずに根拠を添えて報告すること。
指示どおりに作って壊れているより、止めて報告するほうが価値がある

4. 共有ファイルを触らせない

並列化の必須条件です。複数エージェントに同じファイルを触らせると壊れます。分担は以下の表のとおりにしました。

担当	触ってよい範囲
サブエージェント	`<自分のツール>/app.js` だけ
親	台帳・一覧ページ・共通CSSなど共有ファイル全部を直列で

台帳に入れるJSON・一覧ページのHTML・1行の説明といった登録情報は、サブエージェントに戻り値として返させ、親が貼り付けます。

5. 検査条件は実装した本人に書かせる

プロンプトに「検査条件」欄を用意し、実装したエージェント自身に埋めさせます。DOMの構造も、どの前操作をしないと保存できないかも、書いた本人が最もよく知っているためです。

手順1〜5をまとめたプロンプトの骨組みは以下のとおりです。

## 担当
<ツール名>/app.js だけを編集する。台帳・一覧ページ・共通CSSは触らない

## 検査
<具体的な入力と、報告に含める出力値>

## 報告に含めるもの
- 実装の判断根拠
- 検査条件（ready条件・前操作・押すボタンのID・合格線）
- 登録情報（台帳JSON・一覧HTML・1行の説明）

## 仕様に無理がある場合
実装せずに根拠を添えて報告すること

起きたこと／落とし穴

1. 四捨五入では見えない1円ずれ

親は四捨五入だけで検算して通していました。切り捨てを指定されたエージェントが、次の値を踏んで報告してきました。

110 / 1.1
// 99.99999999999999 → 切り捨てで 99円

四捨五入では誤差が吸収されるため、表に出ないバグでした。

2. 指示した仕様が日勤で壊れていた

勤務時間ツールで「深夜帯との重なりから休憩を丸ごと引く」と指示したところ、エージェントから以下の反論が返ってきました。

その規則は日勤で壊れます。9:00〜23:00・休憩60分だと深夜の重なりが1時間しかないため、休憩60分を丸ごと引くと深夜0分になる（昼に取った休憩で深夜手当が消える）。

反論のとおりだったため、按分方式に変えました。指示の誤りとして返ってきたもう1件は、base64の増加率でした。どちらも数字を根拠に返ってきています。

3. 親が書いた検査条件が5回外れた

親がDOMを見て書いた検査条件は、5回外れました。

外し方	中身
前操作の書き忘れ	「並べ替えてから保存」の仕様を知らず、押しても保存されない
ボタンIDの決めうち	`#dl` だと思ったら `#xlsx` / `#cpng` / `#dlreport`
ready条件の取り違え	タブの奥にある完了サインを待ち、前操作に到達しない
textarea を textContent で読む	`<textarea>` は `.value` に入れても `.textContent` は空のまま。判定が永久に false
合格線が甘い	「10,000回で±5%以内」。乱数の揺らぎの幅を考えていなかった

5件とも「実装は正常なのに検査が落ちる」形で、実装のバグは1件もありませんでした。

4. 検査のNGに本物が混ざる

出力検査が3本で「保存したファイルが落ちてこない」と出しました。報告前に実機で再現を取ると、3本とも正しく動いており、画面には次の案内が出ていました。

並び順が元のままです。ページを入れ替えてから保存してください
抜き出すページを選んでください

検査側が前操作（選択・並べ替え）を書いていなかっただけでした。一方、同じ入口で調べた別のツールでは本物のバグ（比率固定が画像の端で壊れる）が出ています。誤検出が5回続いた後に、本物が来た形です。

5. 「動くけれど役に立たない」は検査を通る

PDFの修復ツールは、指示どおりに作ると「修復できません」しか返さないツールになることが実測で分かりました。エラーは出ず、画面も正常に動くため、検査は全部通ります。実装したエージェントが実物のPDFで試して初めて判明しました。

6. 戻り値を回収できないことがある

完了通知に報告本文が乗らない場合がありました。transcript には全文が残っていますが、素朴に「最後の発言」を取ると失敗します。追加で質問したエージェントは、最後の発言が「消す箇所なし」のような短い返答になっているためです。

7. 検査表への登録漏れが「判定なし」で素通りする

ツールを足す側と検査表を持つ側が分かれていると、登録し忘れたツールが「判定なし」で素通りします。エラーも警告も出ず、検査を通ったように見えます。

実際に69本中20本が未検査のまま公開されていました。「44本ぶんの記録に対して公開61本」という別の警告もありましたが、本数のズレしか見ていないため、登録漏れはそちらも通り抜けていました。

8. 書いた本人が「書いたつもり」になる

親が登録時に止めたものは2件です。

参照実装からカテゴリを写し間違えていた（TXTツールなのに excel）
「PDF内の文字を選択できない」がFAQから抜けていた。app.js の冒頭コメントには「FAQに明記」とあるのに、本体には入っていなかった

対処

検査のNGは検査側を先に疑い、毎回実機で確かめる

「落ちとし穴」3・4への対処として、運用ルールを次の2行にしました。

1. 検査のNGは、まず検査側（前操作・ID・ready条件・合格線）を疑う
2. ただし本物が混ざるので、人に報告する前に必ず実機で再現を取る

疑うことと、確かめないことは別です。検査結果をそのまま「バグ発見」として人に投げると、相手の時間を奪ううえ、次から検査結果を信用してもらえなくなります。

戻り値の回収ルールを変える

transcript から報告を拾う規則を以下に変えました。

登録情報を含む発言を優先して採る。
無ければ、いちばん長い発言を採る。

回収率は 7/9 から 9/9 になりました。

検査表との差分を機械で取る

「気をつける」では登録漏れを防げません。公開一覧と検査表を突き合わせて、判定条件が無いツールを名指しで出す仕組みを入れました。入れた当日に、自分が追加した4本をその仕組みで捕まえています。

検出器は、検出できることを確かめて初めて検出器になります。わざと1本外して警告が出ること、戻すと警告が消えることまで確認しました。

できないことの書き落としは親が必ず見る

できないことの書き落としは、利用者が使ってから気づく形になり、最も悪い結果になります。FAQの抜けとカテゴリの写し間違いは、登録時に親が成果物をそのまま入れずに読むことで止めました。

副次効果として数える

その日見つかったバグのうち2件はサブエージェント発で、どちらも指示していない発見でした。

KPI計測の二重計上（共通関数が内部でイベントを出しているのに、呼び出し側でもイベントを出していた）
消費税の1円ずれ

作業者が増えると、「前からそう書いてあるから正しいだろう」が効かない目が増えます。既存コードを新しい目で読み直す機会として、並列化の効果に数えてよいと考えています。

まとめ

「検証してから終わること」ではなく、具体的な入力と報告すべき出力値をプロンプトに書く
判断根拠と「仕様に無理があれば止めて報告」をプロンプトに入れると、指示の誤りまで返ってくる
サブエージェントは自分の app.js だけを触り、共有ファイルは親が直列で更新する
検査条件は実装した本人に書かせ、検査のNGは検査側を先に疑いつつ毎回実機で確かめる
検査表の登録漏れは差分を機械で取り、検出器そのものもわざと1本外して動作を確かめる