#実験設計 — 同じ計画書を、複数のモデルで、複数回検証
実験の構成はシンプルです。1つの事業計画書について、実際の数値をそのまま残した原版と、売上予測を意図的に水増しした改変版の2種類を用意しました。両方を、Haiku 4.5、Sonnet 5、Opus 4.8、GPT-5.5の4モデルで、各バージョンにつき各モデル2回ずつ実行しました(4モデル × 2バージョン × 各2回 = 合計16回)。
- 原版には、もともと存在していた実際の計算ミスを1つ、そのまま残しました
- 改変版には、売上関連の数値を意図的に水増しした誤りを追加しました
- 実行ごとの結果の一貫性も確認するため、各バージョンを各モデルで2回ずつ実行しました
確認したのは、計画書に書かれた計算が実際に成り立つかどうかです。数量 × 単価 = 合計といった掛け算の関係や、異なるセクションに散在する数値の内部整合性を検証しました。事業計画書のすべての数値を検証したという意味ではありません。
#小規模な判断方向のテスト — 事前に付けた評価区分ごとの平均点の順位を比較
計算が正しいかどうかは、コードで確認できます。しかし、「この計画書は、あの計画書より本当に優れている」と判断するのは別の問題です。そこで計算の正確性とは別に、事前に評価区分を付けた少数のサンプルで、評価の方向性も確認しました。
OpenSeedが内部基準で事前に「高評価・標準・低評価」に分類した少数の事業計画書を用意しました(いずれも各モデルの評価とは独立して分類)。各モデルに内部テスト用の手順で評価させ、評価区分ごとの平均値が同じ順位(高評価 > 標準 > 低評価)になるかを確認しました。市場、製品、チーム、財務、リスクの5つの観点で評価し、決定論的な加重合計によって総合値を算出しました。これらの数値はこの実験のための内部指標で、ユーザー向けレポートには表示されません。
| モデル | 低評価の平均(n=3) | 標準の平均(n=4) | 高評価の平均(n=3) | 順位 |
|---|---|---|---|---|
| Haiku 4.5 | 9.7 | 55.3 | 70.0 | 低評価 < 標準 < 高評価 |
| Sonnet 5 | 18.0 | 46.5 | 66.3 | 低評価 < 標準 < 高評価 |
| Opus 4.8 | 16.0 | 51.5 | 62.7 | 低評価 < 標準 < 高評価 |
| GPT-5.5 | 13.0 | 48.3 | 55.0 | 低評価 < 標準 < 高評価 |
絶対値は、モデルごとの傾向や評価尺度の調整の違いに左右されるため、モデル間の性能比較には使いませんでした。確認したのは、それぞれのモデル内で評価区分の順位が保たれるかどうかだけです。この結果だけでは、個々の文書が正しい評価区分に分類されていたか、区分間でどれくらい重なりがあるかは分かりません。
この小規模な確認では、4モデルすべてで、グループ平均が事前の評価区分と同じ方向に並びました。これは、OpenSeedの実際のマルチエージェントシステム全体の判断性能を検証したものではありません。
#モデルが変わっても、計算のクロスチェックは変わりません
この実験を行った理由はシンプルです。分析に使うモデルが変わっても、計算のクロスチェックの結果と判断の方向性が保たれるかを確認するためです。OpenSeedの分析モデルは、運用設定で変更できます。
前述のとおり、絶対値によるモデル比較はしていません。評価区分ごとの平均値の差も、各モデルの尺度に左右されるため、厳密な性能比較と見なすことは困難です。モデルを選ぶ根拠ではなく、同じ手順を別のモデルに適用しても方向性が保たれるかを見るための参考観測です。
Chiefの役割は、この実験とは別です。OpenSeedのChiefは新たな判断を下しません。役割は、該当する評価役の所見をレポートに統合することだけです。計算のクロスチェックのように数値で確認できる部分は、別のコード手順が担います。
Haiku 4.5とGPT-5.5も、この小規模な確認で正しい順位を再現しました。この実験は、特定のモデルの組み合わせを決める根拠ではありません。同じ手順を別のモデルに適用しても方向性が保たれるかを限定的に確認したものです。
#結果 — OpenSeedが信頼を築く3つの方法
「すべてを徹底的に確認しています」と言うのは簡単です。OpenSeedは、何を確認し、何を確認していないかを明確に示す方法を選びました。すべてを検証したと主張するのではなく、文書内の計算をクロスチェックし、現在対応している項目を公的な情報源と照合し、検証が実際にどこまで及んだかをレポート内に明示しています。
| 手順 | 確認する内容 | 結果 |
|---|---|---|
| ① 計算検証 | 文書内の計算(数量 × 単価 = 合計など)が正しいか。式や数値を見つける工程にはAIが関わりますが、実際の再計算はコードが行います。 | 4モデルを含む全16回の実行で、同じ計算上の不整合を一貫して検出しました(少数サンプルによる内部テスト)。 |
| ② 外部照合 | 対応している項目を、分析時に取得した公的統計(韓国統計庁のKOSISデータベース)と照合しているか。 | 現在は人口統計(全国の総人口、国内人口移動)を主な対象とし、基準年と地域が一致する場合に差異があれば「要確認」と表示します。 |
| ③ 検証範囲の開示 | レポートで確認したことと、確認しなかったこと。 | 「公的情報源N件中M件を確認」と表示し、未検証の項目は「データなし」「未照会」「照会失敗」のいずれかで示します。 |
3つに共通する原則は、把握している以上のことを知っているふりをせず、実際に検証した範囲だけを、検証済みと伝えることです。
#事業計画書を書く人にとって、なぜ重要なのか
数値は、審査員が事業計画書で最初に疑問を持つ要素の1つです。市場規模、売上予測、成長率。これらの内部整合性が取れていなければ、その時点で信頼性は崩れます。また、すべての数値が正しくても、計画全体が論理的に説得力のある内容になっているかは、まったく別の問題です。
- 売上予測と市場規模の計算式に整合性があるか
- 提示された数値が文書全体で一貫して使われているか
- 意図せず水増しされた数値がないか
このうち、数量 × 単価 = 合計といった掛け算の関係や、各所の数値の内部整合性など、計画書に書かれた計算について、OpenSeedはAIの主観的な判断だけに任せていません。別の計算クロスチェック手順で、改めて検証します。一方、計画全体に説得力があるかは、複数の審査観点から判断を統合する問題です。上記の小規模実験が示しているのは、同一の評価手順を適用したところ、4モデルすべてで、グループ平均が事前の評価区分と同じ方向になった、という範囲に限られます。
#OpenSeedがこの結果を公開する理由
OpenSeedは事業計画書をレビューするとき、その背後にある根拠を見ます。そして、その根拠を生み出すプロセス自体も、検証可能であるべきだと考えています。上記の3つの信頼を支える手順は、その原則を自分たちにも適用した結果です。
まずは計算の確認から
AIが事業計画書内の計算式と数値を見つけ、別のコードによる処理で実際の計算をやり直し、クロスチェックします。提出前に確認しましょう。
提出前に根拠・論理・リスクを確認する意思決定支援サービス
OpenSeedのレビューを始める →