18
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

並列で思考を分けたら、AIレビューの精度もコンテキスト効率も同時に上がった話

18
Last updated at Posted at 2026-06-23

はじめに

AIにコードレビューをやらせるとき「1つのエージェントに全部チェックさせる」のをやめて、複数の専門エージェントに並列で分業させる 構成に変えたら、精度が体感で大きく上がりました。

ただ、本当の収穫は精度向上そのものより、「並列で思考を分ける」こと自体が、コンテキスト効率とハルシネーション対策を同時に解決していた ことに気づけたことでした。


1人のAIに全部任せると浅くなる

最初は、1つのサブエージェントに14観点(要件整合性、セキュリティ、DB/ORM、テスト…)を全部チェックさせていました。

これだと、専門性が薄い指摘ばかり返ってきたり、重要な観点を素通りされたり、煽った Critical が量産されたり、と全部が浅くなる。

原因はシンプルで、1つのコンテキストに観点を詰め込みすぎている からです。プロンプトもコードも膨大になり、後半の観点は読み飛ばされ、思考の方向性も定まらない。「全部見ろ」は構造的に無理がある、と判断しました。


三段構えのアーキテクチャ

そこで構造をこう変えました。

各レイヤーの役割はこんな感じです。

レイヤー1: 専門レビュアー(並列)
観点ごとに専属エージェントを立てて、並列で動かす。各エージェントには「自分の領域だけ深く見ろ。他は他レビュアーに任せろ」と指示する。今回は6人にしましたが、観点の数はプロジェクト次第です。

レイヤー2: Aggregator(統合役)
6人分の指摘には重複や矛盾が含まれるので、別のAIに集約・整理させる。複数レビュアーが同じ箇所を指摘した事実を「確度の高いシグナル」として明示するのがポイント。

レイヤー3: Self-Critique(検証役)
Aggregator の出力をそのまま信じず、さらに別のAIに「これ本当に妥当か?事実か?」を再評価させる。これでハルシネーションと過剰指摘を削る。

並列化するのは専門レビュアーだけです。Aggregator と Self-Critique は前段の結果を受けるので順次実行になります(Claude Code では1メッセージ内に複数の Agent 呼び出しを並べると並列起動になる)。


なぜこの構造が効くのか

この設計は「分業して精度を上げる」だけじゃなく、生成AIが構造的に抱えている2つの問題を同時に解いている と気づいたのが、運用してみての一番の発見でした。

1. コンテキスト効率: 並列化で1人あたりの負荷を下げる

1人のAIに14観点を全部見せると、プロンプトもコードも膨大になり、コンテキストを食い潰します。観点が後ろにあるほど読み飛ばされ、コードベースを深く読み込む余裕も残らない。「全部見ろ」と言いつつ、実態は「広く浅く」になっている状態です。

並列に分けると、各エージェントは自分の観点に必要な情報だけを深く読める。1人あたりのコンテキスト負荷は減っているのに、全体として見える範囲はむしろ広がっている。さらにエージェントごとに思考の方向性が「Security専任」「Migration専任」と強制されるので、専門性も担保される。

「並列化=速くなる」だけじゃなく、「並列化=深く見られる」というのが、本質だと思っています。

2. ハルシネーション対策: 生成と検証を別エージェントに分離する

1人のAIが出した結論は、間違っていても誰も気づけません。同じAIに「自分の出力をチェックして」と頼んでも、出力時のバイアスを引きずって同じ誤りを正しいと判定しがちです。自分の答案を自分で採点しているようなもの

この構造では、

  • 6人が 独立に 出力する → 「1人だけが言っている指摘」と「複数が言っている指摘」が自然に分離される
  • Self-Critique が 別エージェントとして 検証する → 生成と検証が完全に分離される

つまり「自分の出力を自分でチェックすることの限界」を、構造的に回避できる。これがハルシネーション削減の本質だと思います。


トレードオフ

良いことばかりではなく、コストもあります。壁時計時間は1.3〜1.5倍(並列なのでそこまで増えない)、トークン消費は2〜3倍 です。ネックはトークン消費量。

重要な変更にだけマルチエージェント・レビューを適用し、軽い変更は単独レビューで済ませる、という使い分けが現実的です。

また、領域によって効き目に差があります。セキュリティや移行整合性のように 観点が明確な領域 では大きく効きますが、ビジネスロジックバグのように ビジネス文脈そのものが必要な領域 ではAIだけでは限界があり、人間レビューが必要でした。


まとめ

精度が上がったことで一番嬉しかったのは、人間がAIのレビュー結果を信用できるようになってきた ことでした。

単独レビュー時代は「これ本当か?」と疑いながら全部自分でも確認していたので、AIを使っているのに作業量が減らなかった。今は「複数レビュアーが指摘 + Self-Critique 通過」のものは高確度で信用できるので、人間は判断と意思決定に集中できる。レビュー時間も手戻りも明確に減っています。

AIに何をやらせるかより、AIをどう組み合わせるかを設計するフェーズ に入ってきたな、というのが今回の所感です。1人のAIに頑張らせるより、複数のAIを並列で動かして役割を分けたほうが、構造的にいろんな問題が解ける。「1人のAIで頭打ち」を感じている人がいたら、ぜひ並列分割を試してみてください。


参考


株式会社シンシアでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら:

シンシアでは、年間100人程度の実務未経験の方が応募し技術面接を受けます。その経験を通し、実務未経験者の方にぜひ身につけて欲しい技術力(文法)をここでは紹介していきます。

18
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
18
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?