5つのAIに多数決を取っても、票の数では決まらなかった話

IT・仕事術

記事内に広告が含まれています。

少数意見を条件に変える、パネルと裁定の運用

この記事でわかること

  • 外部AI5者によるパネル(複数AIの合議体)と、5者中3者で可決するラインの使い方がわかります。
  • 評価者が3者だった頃の3者中2者から、5者中3者に変えた経緯と、観点の種類が増えたことの意味がわかります。
  • 全員一致でも、差が小さければ仮採用にとどめる扱いと、実行前に前提の確認を通す理由がわかります。
  • 第2サイト選定で候補1に4票、候補3に1票、候補2に0票となった結果から、多数派の条件が設計を修正し、少数意見が検証の項目として残る流れがわかります。
  • 5者中3者に届かないときの扱いと、変更の提案が不成立なら現状を維持する場面がわかります。
  • 最終判定を多数決にしない運用と、場面ごとに実際に決めたものの対応がわかります。

なぜ、5つのAIに聞くのか

私は判断の材料として、外部AI5者のパネルを使っています。パネルは複数AIの合議体で、参加するのはChatGPT、Claude、Gemini、DeepSeek、Grokです。同じ質問を5者に投げ、可決ラインは5者中3者、つまり3oo5で設定しています。

この可決ラインは、当初の方式から私の指示で変更したものです。当初は評価者が3者で、3者中2者が同じ案を支持すれば採用とする方式でした。評価者が5者になり、可決の線は5者中3者に引き直しました。どちらの場合も、線に届かなければ多数決は不成立です。3oo5という表記は、5者のうち3者という意味です。

5者に広げて変わったのは、票の数だけではありません。5者はそれぞれ別のAIで、同じ質問への答えにも違いが出ます。たとえば、これまでの選定では、法的な問題を指摘する者もいれば、利用者の感覚から反対する者もいました。制作の分業では、さらに役割が分かれます。Geminiは素材整理、Grokは読者モニター、DeepSeekは執筆、ChatGPTは検証、Claudeは最終判定を担います。この違いがあるから、私は5者の票と理由を並べて読んでいます。票が同じ数でも、理由の力点が違うことがあります。

進行役のAIであるMuseが議長として集約と仮判定を行います。仮判定は、票を数えたうえでの暫定的な整理です。ただし、Museが総合判断を独断で決めないことも私の指示です。判定の際には「他に調査することがないか」も各者から募ります。これは、票を数える前に、判断材料の抜けを見つけるためです。

多数決は、結論を出す装置ではなく、意見の差を見える形にする装置です。

私がパネルに期待しているのは、賛成か反対かの数字だけではありません。どの条件が争点になり、どの前提が共有され、どこにリスクが残るのかを、票と理由の形で見えるようにすることです。だからこそ、可決ラインを満たしても、そのまま実行しない場合があります。

先に決めておく境界

私の運用では、権限を三つの層に分けています。上位から、私本人の方針と実測、進行役の裁定、パネルの多数決です。裁定は、前提を確認して手順を決めることです。実測は、実際に試して測ることです。私本人の方針と実測は多数決にかけません。進行役の裁定は前提確認とプロセスの制御を担います。パネルの多数決は、意見の差と条件の抽出を担います。

権限の三層(私本人の方針と実測、進行役の裁定、パネルの多数決)

票で決めないものの基準は、既定の方針があること、結果が不可逆であること、私本人の実測でしか分からないことです。この基準に当てはまるものは、票を取る前に多数決の対象から外します。

票にかける前に、票で決めてはいけないことを決めておきます。

たとえば、子ども向け紹介動画で「子どもが遊ぶ実映像を使う」という提案がありました。私は、家族の映像を普及目的に使わないという既定方針を持っています。この提案は、その方針に反するため、票にかける前に不採用になりました。反対票が多かったからではなく、票で決めてはいけない領域だったからです。基準を先に置いておくと、提案が出た時点で「これは票の対象ではない」と判断できます。票を取ってから揉めるのでは遅いのです。

少数意見は、捨てるものではなく、条件に変えて残すものです。

少数意見を残すといっても、結論を曖昧にするのではありません。少数意見が示しているリスクを、リスク登録、設計条件、測定項目のどれかに変換して残します。そうすることで、多数決の結果だけでなく、後から確かめるべき条件も一緒に残ります。

全員一致でも、決まらない

子ども向け学習アプリの音声を選ぶパネルでは、統一の声として候補A(Aria)が5者全員一致でした。ただし、複数者から留保が付きました。候補A(Aria)と他候補の差は実質「を」1件分しかなく、順位は暫定だという留保です。これは、読み上げた音声を文字起こしと照合した際に見つかった不一致が、助詞の「を」1件だけだったという意味です。5者全員が同じ候補を推しても、その差が「を」1件分では、順位として確定とは言えません。私はこれを、全員一致だから即採用とは扱いませんでした。

そこで採用は仮採用とし、「量産前に全件を複数回生成して失敗率を見る」ことが条件になりました。失敗率とは、生成がうまくいかなかった割合のことです。量産とは、同じ設定でまとめて作ることです。少量の試作ではなく、全件を複数回生成して確かめます。この条件を置いたうえで、仮採用という形にしました。

このやり取りの途中で、1者への提出文に候補の秒数の誤記がありましたが、訂正文を送って再回答を得ており、票の前に材料の正確さを確認した実例でもあります。結論は変わりませんでしたが、材料の誤りを残したまま票を数えることはしませんでした。

その後、私本人の試聴で、案内系は候補A(Aria)、励ましは別の声という、用途で分ける形に最終決定が変わりました。全員一致は強い材料でしたが、最終決定をそのまま固定したわけではありません。仮採用に置き、私の耳で聞き直し、用途ごとに声を分けます。時系列で追うと、全員一致から最終決定までに三つの手順が入っています。全員一致は出発点でしたが、終点ではありませんでした。

4対1で勝っても、設計は変わる

第2サイト選定では、候補が3案ありました。年収の壁の判定ツールが候補1、退職・失業給付ナビが候補2、相続手続きの期限管理が候補3です。票は候補1に4票、候補3に1票、候補2に0票でした。候補1への4票は全員が条件付きで、候補3への1票はClaudeによる条件付きの票でした。可決ラインである5者中3者を満たしたため、候補1を条件付き採用としました。

ここで重要だったのは、候補1に4票入ったこと自体ではありません。4票に付いた条件が収束し、当初設計への実質的な修正要求になったことです。私は「当初設計のままでは採用されたとは扱わない」としました。票の数は勝っていても、設計はそのままでは通らなかったわけです。

条件の集約で、看板に使うつもりだった「約200万人」という数字は根拠が弱く使えないことになりました。看板とは、サイトの入口で目に入る見出しのことです。数字が強いと、それだけで説得力があるように見えます。しかし、根拠が弱い数字を入口に置くと、後で崩れたときにサイト全体の信頼が落ちます。そこでこの数字は外しました。あわせて、手取り額は入力だけでは確定できないため、表示は加入の判定と金額の幅に絞ることになりました。手取りは入力だけでは決まらず、幅で示すしかありません。この二点が、4票の条件から出てきた設計の変更です。当初設計のままなら、看板の数字と確定額の表示が残っていました。4票の条件を読んだことで、その二つが外れたのです。

候補3に1票を投じたClaudeの少数意見も、棄却しませんでした。候補1は制度変更の頻度と手取りの非決定性で構造的に不利だという反論です。制度が変われば判定は古くなり、手取りが決まらなければ表示はぼやけます。私はこれを、検証ゲート、つまり後で確かめるための確認項目に変換して残しました。候補3への法的指摘も引き継ぎました。専門家への成果報酬型の紹介は規制で不可という指摘で、候補1が落ちた場合の再審査の前提として残しています。

少数意見は、捨てるものではなく、条件に変えて残すものです。

4対1という票は、候補1が勝ったことを示します。しかし、勝った候補1の中身は、4票の条件によって変わっています。看板の数字を外し、表示を加入の判定と金額の幅に絞ります。票の数は同じ4票でも、条件を読まなければ設計は見えません。だから私は、多数派の票だけでなく、多数派に付いた条件と、少数派が示したリスクをセットで扱っています。

票が割れたときの決め方

票にかける前に、票で決めてはいけないことを決めておきます。

5者中3者に届かなければ、多数決は不成立とします。その場合、共通地盤の集約と実測への付託を行い、それでも決着しない事項だけを私本人に上げます。共通地盤とは、5者が共通して言っていることです。票が割れたことを、そのまま私の独断で埋めるのではありません。共通して言えることを集め、実測で確かめられることに寄せ、残った争点だけを私が引き取ります。

初回のサイト選定は、評価者が3者の段階で行われました。候補は3案で、英語入試の学校絞り込みと併願カレンダーが候補1、親の介護の開始期ナビが候補2、副業・フリーランスの申告診断が候補3です。当時の事前ルールは3者中2者で、残りの2者、DeepSeekとClaudeは、同じ案への支持が3者中2者に届かない場合に加わる予備でした。票は候補1に2票、候補2に1票、候補3に0票でした。候補1への2票はChatGPTの条件付きの票とGeminiの採用可の票で、候補2への1票はGrokの票です。候補1は当時の線である3者中2者に到達し、条件付き採用になりました。3者で票が2対1に分かれても、2票側を条件付きで採用し、「実証で困りごとと課金理由が確認できなければ候補1を取り消して候補2を再審査する」という取り消し条件をセットで残しました。実証とは、実際に試して確かめることです。候補1はその後、試用版の公開まで進みました。線に到達した採用でも、取り消して別の候補を再審査する条件を外しません。これがこの事例の要点です。

投稿順の入れ替え案では、方式の支持が割れて多数決が成立せず、現行の順序を維持しました。こちらは不成立なら現状維持という扱いです。変更するか否かを問う提案では、不成立は「変更しない」こと自体が結論になります。決めなければならない事項が残る場合にだけ、共通地盤の集約と実測への付託に進みます。初回のサイト選定は線に到達して条件付き採用、投稿順は不成立で現状維持でした。どちらも、票数だけで決めたのではありません。進める場合は取り消し条件を置き、進めない場合は現状を保ちます。この二つの扱いを、私は場面に応じて使い分けています。

実行の前に、裁定で前提を見る

ブログ記事3本の統合では、投票はA案(統合すべき)に1票、B案(統合しない)は0票、C案(条件付きで統合)に4票でした。統合の方向は全員が支持しました。多数派の条件が実装を決め、統合先を別の記事に変更し、1本は統合対象から除外しました。一方、実施時期については「Google AdSenseの審査中に実施」と「Google AdSenseの審査完了後」が対立しました。これは票ではなく、議長が第三の方式を裁定として採用して解きました。準備と検証は審査の結果を待たずに先行し、URLの変更だけを同日中に一括で行うことで、作業の影響を1日に閉じ込めました。各者が挙げた「追加で調査すべきこと」から、検索データの実測が判断材料に加わりました。実施時期のように、どちらを選んでも作業が進む論点は、票を割るより、第三の方式を作ったほうが早く決まります。

重複下書きのゴミ箱移動では、5者に同一の質問をして5者全員が賛成しました。それでも実行前に、議長が2点を確認しました。内容が公開済み記事に保存され、本文が最終稿と一致すること。ゴミ箱移動は復元可能で、完全削除ではないこと。全員一致でも、前提の確認を通してから実行し、完全削除はしませんでした。賛成の票が5票そろっていても、前提が崩れていれば実行してはいけません。ここで確認した2点は、どちらも実行の前にしか確かめられないことです。

写真スタンプの批評では、1者であるGeminiが本人確認の都合で回答を取得できず、4者の範囲で統合を進めました。未取得であることは記録に残しました。弱点の指摘は4者全員一致で、修正の第1弾として実施しました。個別のアイテムで意見が割れたものは、任意の修正として私の判断に残しました。5者のうち1者が欠けたまま進める場合は、欠けたことを記録に残します。欠けたまま全員一致と言わないための記録です。

多数決は、結論を出す装置ではなく、意見の差を見える形にする装置です。

実行の前に行う裁定は、票を数え直すことではありません。前提が正しいか、実行が不可逆でないか、私の既定方針に反していないかを確認することです。この確認があるから、全員一致や多数派の票を、そのまま実行に直結させずに済みます。

最終判定は、多数決ではない

この連載の記事や小説の最終判定は多数決ではありません。Claude 1者が理由を示して差し戻す最終判定制です。第2回の制作では、その差し戻しによって記事の結論自体が組み替わりました。当初は「観測条件を変えれば解ける」という結論でしたが、差し戻しで、成功のときに変わっていたものが実は2つあったことが判明し、結論は「変えるのは一度に1つずつ」という形に組み替わりました。票では決められない種類の正しさがあることを、私はこの運用で確認しています。

パネルの多数決は、意見の差と条件を抽出する場です。進行役の裁定は、前提確認とプロセスを制御する場です。私本人の方針と実測は、多数決にかけない上位の層です。最終判定をClaude 1者に置くのは、票の多寡ではなく、理由を示して差し戻す役割を分けるためです。最終判定は票とは別の物差しで、1者の差し戻しが記事の結論を変えることもあります。

おわりに

多数決の役割は、結論を出すことではなく、意見の差と条件を見える形にすることでした。実際に決めるのは、少数意見を条件に変換し前提を確認する裁定と、票にかけない方針を持つ私本人です。場面ごとの対応は、次の表の通りです。

場面票実際に決めたもの
紹介動画の提案票にかけていない家族の映像を普及目的に使わないという既定方針に反するため、票を取る前に不採用としました
声の選定候補A(Aria)が5者全員一致、ただし順位は暫定という留保付き仮採用とし、量産前に全件を複数回生成して失敗率を見る条件を置き、後に私の試聴で案内系と励ましを分けました
第2サイト選定候補1(年収の壁の判定ツール)に4票、候補3(相続手続きの期限管理)に1票(Claude)、候補2(退職・失業給付ナビ)に0票候補1を条件付き採用し、4票の条件から看板の数字を外して表示を加入の判定と金額の幅に絞り、候補3への1票を検証ゲートに変換しました
初回のサイト選定(評価者3者の段階)候補1(英語入試の学校絞り込みと併願カレンダー)に2票(ChatGPT・条件付き/Gemini・採用可)、候補2(親の介護の開始期ナビ)に1票(Grok)、候補3(副業・フリーランスの申告診断)に0票当時の3者中2者の線に到達したため候補1を条件付き採用し、実証で困りごとと課金理由が確認できなければ候補2を再審査すると決めました
投稿順方式の支持が割れて多数決が不成立現行の順序を維持しました
記事統合A案に1票、C案に4票統合の方向を採用し、多数派の条件で統合先の変更と除外を決め、実施時期は議長の第三方式で裁定しました
重複下書き5者全員が賛成議長が2点の前提を確認してからゴミ箱移動し、完全削除はしませんでした
スタンプ批評Geminiは未取得で、4者の範囲4者全員一致の弱点指摘を第1弾修正とし、個別に割れたものは任意修正として私の判断に残しました
最終判定多数決ではないClaude 1者が理由を示して差し戻し、第2回は記事の結論自体を組み替えました

制作分業は、第2回と同じ担当で次の通りです。

担当役割
Gemini素材整理
Grok読者モニター
DeepSeek執筆
ChatGPT検証
Muse進行・版管理・仮判定
Claude最終判定

票は意見の差を示してくれます。しかし、票の数だけでは、条件の重みも、不可逆な結果も、私の既定方針も決まりません。だから私は、票にかける前に票で決めないことを決め、少数意見を条件に変え、実行前に裁定で前提を見ます。この順序を守ることで、多数決を結論装置ではなく、設計の材料として使っています。

IT・仕事術
nomariをフォローする
のまりの休日 ~気ままに時々プチライフハック~

コメント

タイトルとURLをコピーしました