この記事は、発注側がAI開発の支援会社を選ぶ際の判断材料に関する検証シリーズの1本である。成果物を「動くもの」だけに定義すると、どこまで検証されたものかが契約書から読み取れなくなる。自社の検証レポートの構成をもとに、成果物として何を定義すればよいかを整理する。
この記事で分かること
- 「動くもの」だけを成果物にすると何が起きるか
- 検証レポートを成果物に含めるとはどういうことか
- レポートの中身として何を定義すればよいか
この記事で分からないこと(正直に書く)
- ここで挙げる項目を契約に入れれば、納品後のトラブルを避けられるかどうか
- 検証レポートの形式が業界で標準化されているかどうか
「動くもの」だけを成果物にすると何が起きるか
成果物を「画面が動くこと」「応答が返ること」だけで定義すると、納品時点でその実装がどこまで検証されたものかが契約書から読み取れなくなる。動くことと、想定外の入力に対して誤った情報を出さないことは別の性質の話であり、後者は見た目だけでは確認できない。発注側が「見えるもの=完成品」として受け取ってしまうと、検証範囲についての認識が食い違ったまま検収が進んでしまう。
検証レポートを成果物に含めるという考え方
自社が運営する対話エージェント基盤では、成果物に実装そのものだけでなく、出荷前に敵対的な質問を投げて確認した幻覚率・失敗モードの合否・盲検評価のスコアをまとめた検証レポートを含める設計を取っている(出所: 自社の運用記録、確認日2026-09-06)。これは「検証済みだから安全」という主張のためではなく、どこまで確認し、どこから先は確認していないかを納品時点で切り分けるための資料として位置づけている。
レポートの中身として何を定義するか
検証レポートに含めるべき項目として、自社の運用では次の3つを軸にしている。1つ目、想定した質問に対してどれだけ正しい根拠にもとづいて回答できたか(hit率)。2つ目、根拠のない主張をしていないか(幻覚率)。3つ目、想定される失敗のパターンごとに合否を確認したか(失敗モードの検査)。数値を示す際は、何件の検証で得た数値かという標本数を添える。0件だったという結果だけを「0%」と表記すると、標本数によって実際に起こり得る上限が変わってしまうため、標本数なしの「0%」という主張は、それ単独では意味を持たない(出所: 自社の運用記録、確認日2026-09-06)。この考え方は、公開前に基準を満たさないものを出さないという運用にもつながっており、RAGの公開前ゲートの作り方の記事で扱った、検査結果を見て公開の可否を判断する仕組みとも接続している。
契約書に成果物としてどう落とすか
検証レポートを成果物として契約書に落とす際は、レポートの提出自体を検収条件にするだけでなく、レポートに含める項目(検証件数、幻覚率、失敗モードの合否)をあらかじめ定義しておく必要がある。検証件数を定義せずに「検証済みレポートを提出する」とだけ書くと、提出する側が都合の良い範囲だけを検証して満たしたと主張できてしまう。発注側が確認すべきは、レポートが存在するかどうかではなく、レポートの中に検証件数が明記されているかどうかである。
前提を確認しないまま受け取る危うさ
検証レポートという形式が整っていること自体が、内容の正しさを保証するわけではない。体裁の整った資料ほど、その根拠になっている検証件数や条件を確認する動機が生まれにくい。前提を確認せずに整った資料を信じる危うさは、複数エージェントの批判レビューに前提条件シートが要る理由の記事でも扱っている構造である。
成果物の定義や検証レポートの中身について相談したい場合は、お問い合わせから編集部まで連絡してほしい。支援形態の違いは姉妹記事「支援形態の違い」、支援会社の選び方は「支援会社の選び方」を参照してほしい。
よくある質問
Q1. 成果物を「動くもの」だけに定義すると何が問題なのか
動くことと、誤った情報を出さないことは別の性質の話であり、後者は見た目だけでは確認できない。検証範囲についての認識が発注側と支援側で食い違ったまま検収が進んでしまう。
Q2. 検証レポートには何を含めればよいか
想定した質問への正答率(hit率)、根拠のない主張をしていないか(幻覚率)、想定される失敗パターンごとの合否(失敗モードの検査)の3つを軸に、それぞれ何件の検証で得た数値かという標本数を添える。
Q3. なぜ標本数を添える必要があるのか
0件だったという結果を標本数なしに「0%」と表記すると、実際に起こり得る上限が読み取れなくなる。標本数が少なければ、0件でも一定の確率で発生し得るという前提を残す必要がある。
Q4. 検証レポートを契約書に成果物として書く場合、何に注意すればよいか
レポートの提出自体を検収条件にするだけでなく、含める項目(検証件数・幻覚率・失敗モードの合否)をあらかじめ定義しておく。検証件数を定義しないと、提出側が都合の良い範囲だけを検証して満たしたと主張できてしまう。