AIの答えが安定しないとき、同じ問いを何度か解かせて、いちばん多かった答えを採る方法があります。自己整合性、あるいはself-consistencyと呼ばれます。
20,000回ずつ試行したところ、1回の正解率70%は9回の多数決で97.8%まで上がりました。ところが50%を切ると、回数を増やすほど下がります。
同じ問いを複数回解かせ、いちばん多かった答えを採ります。答えがばらつくことを前提にした方法です。
自己整合性は、同じ問いを何度か解かせて、最も多く出た答えを採用する方法です。1回の答えに賭けるのをやめる、という発想になります。
この方法は、答えが毎回同じだと成立しません。ばらつきがあり、そのなかで正解がいちばん多く出るという状態が前提になります。
ですから毎回同じ答えを返す設定では効きません。ばらつかせる設定にしたうえで使うことになります。
もうひとつの前提が、各回が互いに影響しないことです。前の答えを見せてから解かせると、そちらに引きずられて同じ誤りが繰り返されます。
Anthropicも、複数の作業を並行して動かす使い方を案内しており、まっさらな文脈で見たほうが、直前に自分が書いたものに引きずられずに済むと述べています。独立させることの効き目は、ここでも同じです。
自分で見直させる方法は自己反省の記事で、枝分かれさせて探す方法はTree of Thoughtの記事で扱っています。自己整合性は、独立した複数の答えを取って数える点が両者と違います。
運用してみて気づいたのは、答えが割れた問いは、そもそも難しい問いだということでした。5回中3対2で割れたなら、多数決の結果を採るより人に回すほうが確実です。編集部では、割れ方も一緒に記録するようにしています。
Run multiple Claude sessions in parallel to speed up development, run isolated experiments, or start complex workflows.原文Claude Code Docs「Best practices for Claude Code」 この内容の有効期限2027-02-17
20,000回ずつ実際に試行しました。1回70%は9回で97.8%まで上がり、1回40%は9回で26.3%まで下がります。
自己整合性がどこまで効くのかを、実際に回して測りました。条件は1回あたりの正解率を変え、多数決の回数も変えて、それぞれ20,000回ずつ試行です。
乱数は固定の種から作っているので、何度実行しても同じ結果になります。誤答は3種類に散るものとして扱いました。
// 1回の解答。正解率 p で正解し、外すときは3種類の誤答のどれかに散る
function answerOnce(p) {
if (rand() < p) return 'correct';
return `wrong${Math.floor(rand() * 3)}`;
}
// n回解かせて最も多かった答えを採る
function majority(p, n) {
const count = {};
for (let i = 0; i < n; i++) {
const a = answerOnce(p);
count[a] = (count[a] || 0) + 1;
}
let best = null, bestN = -1;
for (const [k, v] of Object.entries(count)) if (v > bestN) { best = k; bestN = v; }
return best === 'correct';
}
1回あたりの正解率ごとに、多数決の回数を変えて 20,000回ずつ試行
1回の正解率 1回 3回 5回 9回
50% 49.8% 58.6% 66.6% 79.4%
60% 59.7% 71.5% 81.0% 91.8%
70% 69.8% 82.8% 91.1% 97.8%
80% 79.9% 92.0% 97.2% 99.7%
誤答が1種類に集中している場合(同じ間違いを繰り返す)
1回の正解率 1回 3回 5回 9回
40% 40.1% 35.9% 31.6% 26.3%
50% 50.0% 50.2% 49.6% 49.6%
60% 59.6% 64.9% 68.1% 73.3%
上の表は素直に伸びています。1回70%が9回で97.8%ですから、効き目は小さくありません。
ただし伸び方は一定ではありません。70%の行を見ると、3回で82.8%まで上がるのに、9回にしても97.8%です。3回への投資がいちばん効いています。
費用は回数に比例します。ですから9回に増やすかどうかは、残りの数%をどれだけ欲しいかで決まります。
下の表が本題です。1回40%の場合、9回の多数決で26.3%まで下がりました。回数を増やすほど悪くなっています。
理由は多数決の性質そのものです。最も多く出た答えを採るのですから、誤答のほうが多く出る問いでは、誤答が確実に選ばれます。回数を増やすほど、その確実さが増していきます。
誤答が1種類に集中している場合も効きが落ちます。1回50%では、何回に増やしてもほぼ50%のままでした。
上の表で50%が9回で79.4%まで上がったのは、誤答が3種類に散っていたからです。散っていれば正解が相対的に最多になりますが、集中していればその効果は消えます。
正解率が50%を切ると、回数を増やすほど誤答が確実に選ばれる。
A fresh context improves code review since Claude won’t be biased toward code it just wrote.原文Claude Code Docs「Best practices for Claude Code」 この内容の有効期限2027-02-17
3回から始めます。増やす前に、1回あたりの正解率が50%を超えているかを確かめてください。
自己整合性を使うかどうかは、1回あたりの正解率を測ってから決めます。測らずに回数を増やすと、逆効果になる場合があります。
必要なのは1つの数字だけです。同じ問いを何回か解かせて、正解した割合を出します。試験の作り方はシミュレーション評価の記事で扱っています。
50%を切っているなら、多数決に進んではいけません。前の節のとおり、増やすほど悪くなります。
2番目はFew-shotの記事で、3番目はツール利用の記事で扱っています。いずれも回数を増やすより先に効きます。
回数はそのまま費用になります。3回なら3倍、9回なら9倍です。誤答が出たときの後始末より安いかどうかで判断してください。
誤答が人手での訂正で済むなら、多数決は割に合わないかもしれません。逆に誤答が外部に出てしまう構成なら、3倍の費用は安いことになります。
多数決には、僅差で決まった場合も同じ扱いになるという弱点があります。5回中3対2と5回中5対0を区別しません。
ですから割れ方も記録し、僅差なら人に回す作りにしておくと安全です。承認の設計はHITLの記事で扱っています。
50%を切っているなら、回数を増やす前に問いのほうを直す。
Beyond parallelizing work, multiple sessions enable quality-focused workflows.原文Claude Code Docs「Best practices for Claude Code」 この内容の有効期限2027-02-17
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る