セルフコンシステンシーとは？複数サンプリングと多数決の実装・費用設計を実装目線で解説【2026年版】

同じ問いを1回だけ解かせるのか、5回解かせて答えの多い方を採るのか。この差だけで正答率が動くという報告が、2022年3月に出ています（Wang et al., arXiv:2203.11171）。手法名はセルフコンシステンシー（self-consistency、自己整合性）。考え方は単純ですが、実装に落とすと「複数候補をどう作るか」「答えをどう数えるか」「費用が何倍になるか」の3か所で必ず詰まります。この記事では、その3か所を実装の解像度で分解し、採用してよい処理と見送るべき場面まで言い切ります。

まとめ：セルフコンシステンシーを掛ける条件と、掛けない境界

セルフコンシステンシーとは、同じプロンプトを複数回走らせて複数の推論経路を作り、そこから抽出した答えを突き合わせて最も多く現れたものを採用する、デコード段階の手法です。プロンプトの文面を書き換える技法ではなく、呼び出し方を変える技法だという点が実装上の出発点になります。1回の生成の中で完結しないので、アプリケーション側にサンプリングと集約のコードが増えます。

実装で最初に確認するのは、使うAPIに複数候補をまとめて返すパラメータがあるかどうかです。2026年8月時点で、Anthropic の Messages API には相当するパラメータがなく、必要な本数だけリクエストを並列に投げる形になります。OpenAI は Chat Completions に n がある一方、Responses API は複数回の呼び出しが必要という仕様です。Google の生成設定には candidateCount があります。つまり「1リクエストでN本」が前提にならないため、並列実行と失敗時の再試行を自前で持つ設計が既定になります。

もう一段やっかいなのが、多様性の作り方です。原典の手法は温度を上げてサンプリングにばらつきを出すことを前提にしていました。ところが最新世代のモデルでは temperature や top_p といったサンプリング指定を受け付けなくなったものがあり、そのモデルでは「温度で散らす」という手が使えません。多様性は指示文の言い換えや例示の入れ替えなど、入力側で作る方向に寄ります。

掛けるかどうかの線引きは、答えの形と誤答の損失で決まります。答えが数値・分類ラベル・真偽といった離散値で、同じ答えを機械的に数えられる処理であれば成立する方式です。そのうえで、1件を取り違えたときの損失が、追加サンプル分の費用と待ち時間を上回るなら掛ける価値があります。逆に、答えが長文で一意に数えられない処理、レイテンシ予算が1回分しかない処理、同じ入力に同じ出力を返す再現性が要件になっている処理では、掛けても投資が回収できません。全件に一律で掛けるのではなく、1本目の確信度が低い件と誤りの損失が大きい項目だけに回す2段構えが、費用対効果の合う実装形になります。

セルフコンシステンシーの定義と、単発生成との処理・費用構造の違い

まず、この手法がプロンプト技法の一種として語られる場面と、デコード戦略として語られる場面の両方があるため、そこを整理してから実装へ降ります。

多様なサンプリングと答えの抽出、多数決という3工程への分解手順

原典の要旨は、貪欲デコード（各ステップで最も確率の高い一手を選ぶ方式）を置き換えるデコード戦略として提示されています。多様な推論経路をサンプリングし、サンプルした経路を周辺化することで、最も整合的な答えを選ぶ、という説明です。ここでいう周辺化とは、途中の道筋の違いは捨てて最終的な答えだけを集計する操作を指します。

実装に落とすと、次の3工程です。第1に、同じ問いに対して中間ステップを含む出力をN本得ます。第2は、各出力から最終的な答えだけを機械的に取り出す工程です。第3に、取り出した答えを数え、最も多かったものを採用します。第2工程が実務でいちばん軽視されやすく、そして最も壊れやすい箇所です。

前提として、各出力に中間ステップが含まれている必要があります。答えだけを返す出力を何本集めても経路の多様性は生まれず、単に同じ答えが並ぶだけになりがちだからです。中間ステップを書かせる指示文の設計そのものはChain of Thoughtとは？CoTプロンプトの書き方・推論モデルでの扱いと限界で扱っているため、本記事では前提として置き、以降はサンプリングと集約の側に集中します。

一貫性が高いことと答えが正しいことがずれる条件と、その扱い方

この手法が拾えるのは、モデルの出力が確率的に揺らぐことによる誤りです。5本のうち3本が正解に届き2本が別々の値を出すなら、多数決は正解側に寄ります。揺らぎを統計的に吸収する装置だと考えると、適用範囲の見当がつきます。

逆に拾えないのは、モデルが一貫して同じ誤りに到達する場合です。前提知識が誤っている、問題文の解釈自体を取り違えている、といった原因では、5本すべてが同じ誤答へ収束します。このとき多数決の一致率は高く出るため、指標だけを見ると「確信度が高い」と誤読しかねません。一致率を確信度の代理指標として使うなら、この誤読の可能性を運用側の前提に明記しておく必要があります。

したがって、この手法は事実性の担保とは別物として扱います。参照すべき根拠を与える方向の対策は、AIハルシネーション対策｜プロンプト・RAG・検出APIで誤答を減らす実装手順の系統が受け持ちます。ばらつきを潰す手法と、根拠を与える手法。この2つは目的が違うので、どちらかで代替しようとすると必ず穴が残ります。

実装手順：サンプル数・多様性の作り方・集約規則をどう決めるか

ここからが実装です。呼び出し方を変える手法なので、設計判断はAPIの仕様と集約コードの側に集中します。

複数候補パラメータの有無と、並列リクエストで組むときの実装の形

2026年8月時点の状況を整理すると、下表のようになります。1リクエストでN本まとめて受け取れるかどうかで、実装量が変わります。

ベンダをまたいで使う実装であれば、「N本を並列に投げて集める」側に寄せた抽象化を1枚かぶせるのが素直です。まとめ取得ができるAPIでも、並列呼び出しに落とす実装は動きます。逆は動きません。

並列呼び出しにすると、単発呼び出しでは表に出なかった論点は3つです。1つ目はレート制限で、N本を同時に投げると1件あたりの同時接続数はそのままN倍です。2つ目は部分失敗の扱いで、5本のうち1本が失敗したときに4本で多数決を取るのか、再試行して5本を揃えるのかを先に決めておく必要があります。3つ目はタイムアウトで、全本の完了を待つ設計だと1件の応答時間は最も遅い1本が基準です。実務では、規定本数に達した時点で残りを打ち切る設計にしておくと、末尾の遅延を切り落とせます。

経路の多様性を作る設定と、最新世代で温度指定が外れたことの影響

原典の手法は、温度を上げてサンプリングにばらつきを持たせることを前提にしていました。同じプロンプトから異なる推論経路を引き出す装置が温度だったからです。この前提が、2026年時点では一様に成り立ちません。

最新世代のモデルには、temperature・top_p・top_k といったサンプリング指定を受け付けず、指定するとリクエスト自体がエラーになるものがあります。既定値以外を拒否するモデルも同様です。この世代では、出力の散らばりを呼び出し側のパラメータで作るという手が塞がれるため、多様性は入力側で作ることになります。具体的には、指示文の言い回しを数種類用意して振り分ける、few-shot の例示の順序や組み合わせを変える、問いの提示順を入れ替える、といった手当てです。パラメータ側の可否と各値の決め方は推論パラメータとは？temperatureとtop_pの決め方・推論モデルでの非対応で扱っているため、そちらを前提に、本記事では「使えないときに何で代替するか」に絞ります。

入力側で多様性を作る場合、注意点が1つあります。指示文を変えると、経路だけでなく答えの傾向まで変わってしまうことがある点です。言い換えの候補を作ったら、まず1種類ずつ単独で走らせて正答率がほぼ揃うことを確かめ、そのうえで混ぜます。傾向の異なる指示文を混ぜた多数決は、揺らぎではなく指示文の癖を集計しているだけになりかねません。

自由記述の答えを数えられる形へ落とす正規化と集約規則の作り方

多数決は「同じ答え」を数える操作なので、同じ答えを同じと判定できなければ成立しません。ここが実装の主戦場になります。

最初に決めるのは、答えの取り出し方です。本文末尾を正規表現で拾う実装は、書式が揺れた瞬間に壊れます。構造化出力の機能を使い、最終的な答えを独立したフィールドとして出させる形が堅い実装になります。中間ステップは自由記述のまま出させ、答えのフィールドだけを型で縛る、という分担です。

次が正規化です。数値なら桁区切りと単位と小数点以下の桁数を揃え、日付なら書式を1つに寄せ、分類ラベルなら候補集合を先に決めて列挙型で受け取ります。金額を「1,200円」「1200」「約1200円」と3通りで受け取れば、正解が3本あっても票が割れて多数決が壊れます。正規化の設計は、集約規則の設計とほぼ同義だと考えて差し支えありません。

集約規則そのものは、単純多数決から始めます。同数で並んだときの決め方（1本目を優先する、確信度の高い方を採る、判定不能として人手へ回す）を先に定義しておくと、運用に入ってから慌てずに済みます。答えが自由記述で正規化しきれない処理では、この手法は成立しません。無理に文字列の類似度で束ねようとすると、束ね方のしきい値が新しい調整対象として増えるだけです。

サンプル数の決め方と、途中で打ち切る条件をどこに置くかの判断

本数Nは、費用と精度の交換レートで決めます。机上で決めず、手元のデータで実測するのが早道です。手順は次のとおりです。まず評価用データを用意し、N=1、3、5、7、9 で正答率を測ります。次は、Nを増やしたときの正答率の伸びを差分で比較する工程です。差分が費用の伸びに見合わなくなった手前で止める、というのが基本の決め方です。

この曲線は課題によって形が変わります。伸びが3本でほぼ頭打ちになる課題もあれば、9本まで伸び続ける課題もあります。他社事例のNをそのまま持ち込む判断が当たらないのは、この形が事前に読めないからです。評価用データの設計や指標の選び方はLLM評価とは？指標・データセット設計・評価ツールの選び方の範囲になります。

本数を固定せず、途中で打ち切る形にすると費用が下がります。1本ずつ結果を集め、ある答えが規定票数に達した時点で残りのサンプリングを止める、という早期打ち切りです。3本連続で同じ答えが出た件では、残り2本を投げても結論が変わらないためです。並列で全本を同時に投げる実装だとこの節約は効かないので、逐次と並列を混ぜる（まず3本を並列、決着しなければ追加で2本）といった段階実行に落とします。

費用と待ち時間の増え方と、全件適用を避ける絞り込みの設計手順

この手法の採否は、精度の伸びと費用の伸びを同じ土俵に載せて初めて判断できます。見積もりの粒度が粗いと、導入後に請求額で驚くことになります。

N倍になる部分とならない部分を切り分ける見積もりの実測手順と判断軸

費用の増え方は、入力側と出力側で異なる動きです。出力トークンは、本数にほぼ比例する部分です。中間ステップを含む出力をN本作るので、そこは素直にN倍と見ておきます。入力トークンも同じプロンプトをN回送るためN倍ですが、こちらはプロンプトキャッシュが効く条件を満たせば実効の単価が下がります。共通の前置きが長い実装ほど、この差が大きく効く設計です。

実測の手順は3段です。第1に、1本あたりの入力トークンと出力トークンを実際の応答から取得します。第2は、想定するNを掛け、月次の処理件数を掛けて概算を出す工程です。第3に、そこへキャッシュが効く範囲の単価差を反映します。待ち時間は、並列実行なら最も遅い1本に、逐次実行なら本数分の合計に近い値です。同時実行数の上限に当たると並列でも順番待ちが生じるので、上限値も見積もりの入力に含めます。

1本目の確信度で対象を絞る、2段構えの実装と判定基準の置き方

全件に一律で掛けると費用がそのままN倍になりますが、実務ではその必要がない件が大半を占めます。1本目で答えが明快に出る件にまで5本を回すのは、単なる払い過ぎです。

そこで有効なのが、2段構えです。まず1本走らせ、追加サンプルを回す条件に当たった件だけ残りを回す設計です。条件の置き方は3通りあり、組み合わせて使えます。1つ目は項目の重要度で、金額・日付・数量など誤りの損失が大きいフィールドを含む件に限る形。2つ目は自己申告の確信度で、モデルに確信度を出力させて低い件を拾う形。3つ目は検証器で、簡易なルールや別モデルで1本目の答えを検査し、疑わしい件を拾う形です。

どの条件でも、拾い上げ率を運用しながら測ります。拾い上げ率が高すぎれば全件適用と費用が変わらず、低すぎれば導入した意味が薄くなります。この線引きは業務ごとに違うため、実データで詰めるほかありません。設計から実測までを社内リソースだけで回しにくい場合は、生成AI開発・AI受託開発のような外部の受託体制と組み合わせて、評価データの整備と費用試算を先に片づける進め方もあります。

採用してよい処理の条件と、見送るべき3つの場面を分ける判断基準

ここまでの整理を、採否の条件に落とします。曖昧に残さず、条件付きで言い切ります。

答えが離散で、誤答の損失がサンプル費用を上回る処理という条件

採用してよいのは、次の3条件がすべて揃う処理です。第1に、最終的な答えが数値・分類ラベル・真偽・選択肢のいずれかで表現でき、正規化すれば機械的に数えられること。第2に、1件を取り違えたときの損失が、追加サンプル分の費用と待ち時間を上回ること。第3に、誤りの原因がモデルの揺らぎであって、知識不足や問題設定の取り違えではないこと。

3つ目の見極めは、導入前に必ず通します。誤った件を10件ほど手で読み、同じ誤答に一貫して落ちているのか、件ごとに違う誤り方をしているのかを見ます。同じ誤答へ一貫して落ちているなら、この手法では動きません。プロンプトの前提条件を足すか、参照情報を与えるか、モデルそのものを見直す方が近道です。

推論モデルと組み合わせるときに前提が崩れる箇所と、その見極め方

思考機構を内蔵した推論モデルと組み合わせる場合、前提が2か所で崩れます。1か所目は多様性の作り方で、前述のとおりサンプリング指定を受け付けないモデルがあり、温度で散らす手が使えません。2か所目は費用で、思考にかかる出力トークンがそのまま本数分積み上がるため、非推論モデルで見積もったN倍よりも増え幅が大きくなります。

この世代では、本数を増やす前に思考の深さを設定側で1段上げたときの伸びを先に測る順序が妥当です。深さの設定で足りるなら、集約コードを持たずに済むぶん実装を軽くできます。それでも届かないときが、初めて本数を増やす検討へ進む段階です。この判断は、多段推論の方式選定という一段上の枠で整理されており、マルチステップ推論とは？多段推論の仕組みと実装3方式・採用判断にベンチマーク別の改善幅と方式ごとの費用構造をまとめています。本記事の内容と併せて読むと、方式の選定から実装まで一本の線でつながります。

導入を見送ると判断してよい3つの条件と、代わりに置く手当ての形

見送ってよいのは、次の3条件のいずれかに当たる場合です。1つ目は、答えが長文の要約や文章生成で、同じ答えを数える操作が成立しない処理。この場合は、複数生成したうえで別モデルに採点させる方向が代替になります。2つ目は、レイテンシ予算が1回分しかない対話型の処理。ここは思考の深さの設定と指示文の改善で詰めるのが現実的です。3つ目は、同じ入力に同じ出力を返す再現性が要件になっている処理で、サンプリングにばらつきを持たせる手法とは正面からぶつかります。

いずれの場合も、代替を置かずに見送るだけにすると、元の誤答率がそのまま残ります。見送りを決めたら、その処理で何が誤りの主因なのかを1つ特定し、そこに手当てを1つ置く。この対応をセットにしておくと、後から「検討したが何もしていない」という状態を避けられます。

よくある質問

セルフコンシステンシーとCoT（思考の連鎖）は同じものですか？

別物ですが、組み合わせて使う関係にあります。CoTは中間ステップを書かせるプロンプトの書き方で、経路は1本です。セルフコンシステンシーは、そのCoT出力を複数本作って答えを突き合わせる、呼び出し方の側の手法になります。原典もCoTを前提に置いており、中間ステップを出さない出力を何本集めても効果は出にくくなります。

サンプル数は何本にすればよいですか？

手元のデータで実測して決めます。目安としてN=3から始め、5、7と増やしながら正答率の伸びを測り、伸びが費用の増加に見合わなくなった手前で止めるのが基本形です。伸びの止まり方は課題ごとに違うため、他社の事例値をそのまま持ち込む判断は当たりません。早期打ち切りを入れると、平均本数を規定本数より下げられます。

1回のリクエストで複数の答えをまとめて取得できますか？

APIごとに仕様は異なるものです。2026年8月時点で、OpenAI の Chat Completions には n、Google の生成設定には candidateCount があり、一括取得が可能です。一方、Anthropic の Messages API には相当するパラメータがなく、OpenAI の Responses API も複数回の呼び出しが必要とされています。ベンダ横断で使う実装なら、並列呼び出し前提で組むほうが移植しやすい設計です。

温度を指定できないモデルでも使えますか？

使えますが、多様性の作り方を入れ替える必要があります。サンプリング指定を受け付けないモデルでは、指示文の言い回しを数種類用意する、few-shot例示の順序や組み合わせを変える、といった入力側の手当てで経路を散らします。ただし言い換えによって答えの傾向まで動くことがあるため、候補ごとに単独の正答率が揃うことを先に確かめてから混ぜてください。

答えが一致すれば正しいと考えてよいですか？

そうとは限りません。モデルが一貫して同じ誤りに到達する種類の課題では、全サンプルが同じ誤答へ収束し、一致率だけは高く出ます。一致率は確信度の代理指標として扱えますが、正しさの証明にはなりません。事実性が要件なら、参照情報を与える対策や検証器による突き合わせを別に置いてください。

関連記事

• マルチステップ推論とは？多段推論の仕組みと実装3方式・採用判断を実装目線で解説【2026年版】
• Chain of Thoughtとは？CoTプロンプトの書き方・推論モデルでの扱いと限界を実装目線で解説【2026年版】
• 推論パラメータとは？temperatureとtop_pの決め方・推論モデルでの非対応を実装目線で解説【2026年版】
• LLM評価とは？指標・データセット設計・評価ツールの選び方を実装視点で解説【2026年版】
• AIハルシネーション対策｜プロンプト・RAG・検出APIで誤答を減らす実装手順