条項の抜け落ち検出が、ひな形の記述の違いで揺れる
差異を洗い出す機能は、題材となる契約書の記述の違いで結果が変わります。文言の位置が異なるだけで抜け落ちと判定され、合格の線を引けません。
GENZ, Inc.
提供事業者のための
契約書レビューツールの
提供事業者のための
契約書レビューツールの品質を、第三者のテストで確かめる
開発・監修とは別の立場から、解析結果の揺れ・回帰・権限やログの挙動を確かめ、合議に使える形で結果をお渡しします。
支援事例
支援実績5,000件以上
契約書レビュー開発で検証が詰まる場面
契約書レビューツールの品質確認は、条項の抜け落ちや解析結果の揺れが書類の記述の違いに左右されます。期待結果を決めにくい箇所が残ると、回帰確認は手作業へ戻ります。詰まりやすい場面を現象の形で整理します。
条項の
指摘の結果が、解析の仕組みを更新するたびに変わる
解析の仕組みを更新するたび、既存の指摘が変わっていないかを確かめます。変化なのか元からの挙動かを判定できないと、全件の見直しへ戻ります。
ファイルの形式や体裁の差で、読み取り結果がずれる
PDFとWordを扱うツールでは、文字認識の結果が形式や体裁で変わります。読み取りのずれが解析結果へ及ぶため、入力条件を揃える必要があります。
監修で受けた観点を、確認手順へ落としきれない
監修で受けた観点は、確認手順の項目へ落とし込まなければ試験で拾えません。対応が曖昧だと、監修の内容が個別対応で閉じ、次の更新に残りません。
回帰の確認が手作業のまま、更新の日程に追いつかない
確認対象の契約書は更新のたびに増え続けます。手作業のままでは頻度に追いつかず、確かめた範囲を品質会議へ示せないため、合議が持ち越されます。
未検証のまま公開した場合の利用企業への影響
AI契約書レビューツールの指摘は、利用企業の契約審査の根拠になります。確認の範囲を示せないまま公開すると、誤りや見落としが審査へ流れ込みます。
第三者の視点で契約書レビューツールを確かめる観点
契約書レビューツールは、期待結果を一意に決めにくい領域を抱えたまま更新を重ねやすい構造にあります。第三者の視点で確かめる観点を、解析・回帰・読み取り・運用・権限に分けて示します。
自社ひな形だけで確認を済ませると、利用企業ごとの記述の違いで抜け落ち検出が外れる範囲が見えないまま、試用段階で個別対応が増えるおそれがあります。
条項の解析を、ひな形と実際の契約書の両方で確かめる
抜け落ち検出は題材の記述に依存するため、自社ひな形だけでなく実際の契約書でも結果を確かめます。記述の違いで結果が変わる範囲を、類型ごとに洗い出します。
確認する資料
- 期待結果一覧
- 差異記録表
- 判定基準書
更新前後の比較を残さないと、指摘結果の変化が「変わったのか、元からそうなのか」を判定できず、回帰確認が手作業へ戻るおそれがあります。
判定の再現性を、解析の更新の前後で並べて比べる
解析の仕組みが更新されるたび、更新前後の指摘結果を同じ契約書で並べて比べます。「変わったのか、元からそうなのか」を判定できるよう、差分の根拠を記録に残します。
確認する資料
- 回帰結果表
- 差分比較表
- 変更影響一覧
読み取りのずれを切り分けないまま進めると、原因調査のたびに調査の起点が定まらず、対応が個別化してしまうおそれがあります。
読み取りの精度を、ファイル形式と体裁のばらつきで確かめる
PDFとWordで読み取り結果が変わることがあります。文字認識と自然言語処理の各段でずれが生じる箇所を切り分け、体裁のばらつきが指摘へ及ぶ影響を確かめます。
確認する資料
- 形式別結果表
- 読取誤差一覧
- 切分記録書
利用工程まで追わない指摘は、審査の実務で外されたまま観点へ登録されず、次の開発時の観点整理を圧迫するおそれがあります。
指摘と修正案が、契約審査のどの工程で使われるかまで追う
指摘と修正案が、契約審査のどの工程で誰に使われるかまで追います。画面上で正しく見える指摘でも、審査の実務で外されて閉じる箇所を、利用場面に沿って検証します。
確認する資料
- 審査工程対応表
- 利用場面記録
- 指摘追跡表
権限と操作記録の挙動を試験結果として示せないと、審査の回答が設計文書の引用にとどまり、取引開始そのものが止まるおそれがあります。
権限と操作記録の挙動を、審査の質問に沿って確かめる
権限設定と操作記録の挙動を、情報セキュリティ審査の質問票に沿って確かめます。回答の裏づけを、設計文書の記述ではなく確認済みの試験結果として示せる形に整えます。
確認する資料
- 権限設定記録
- 操作記録一覧
- 審査回答根拠書
- 質問票対応表
テストの外注をどのように進めるか
機能追加から公開後の問合せ対応まで、各場面で詰まる確認作業を、外部の検証へ切り出して進める手順を示します。
STEP 01
対象の範囲と合否の線をそろえる「確認一式」で止めず、機能と類型の単位で分けます。
どう確かめるか
開発の反復に伴走して、更新のたびに確かめる
解析モデルの更新ごとに既存の指摘結果を確かめる作業は、確認対象の契約書が増えるほど社内の手作業では追いつきません。更新のたびに同じ範囲を外部で検証し、開発の反復に伴走して確認します。
- 01更新計画に対し確認に要する期間の見積を作り、対象範囲を機能単位で切り出します。
- 02監修担当の判断が「事案による」で止まる箇所を、合否の線の扱いとして明示します。
- 03切り出した範囲を文書化し、外部への発注の前提として合意します。
OUTPUT合意済みの対象範囲
STEP 02
確認の観点と題材の契約書を設計する期待結果が一意に決まらない箇所を先に洗い出します。
どう確かめるか
契約類型と記述のパターンを広い範囲で網羅する
対応する契約類型や記述の違いで結果が変わるため、題材は類型とパターンを広く取りそろえる必要があります。社内に偏った題材しかない場合、外部の検証で網羅の穴を埋めます。
- 01対象の契約類型ごとに、リスクとして扱う条項の観点を整理します。
- 02条項の抜け落ち検出に使う題材の契約書を、記述の違いを含めて選定します。
- 03期待結果が一意に決められない箇所は、判定の保留として観点に記録します。
OUTPUT観点と題材の設計書
STEP 03
実行し、原因の切り分けまで進める読み取り・解析・表示のどの段の差かを特定します。
どう確かめるか
第三者の視点で受け入れ判断の材料をそろえる
品質会議へ上程する際、「どこまで確かめたか」を第三者の結果として示せると、可否の合議が持ち越されにくくなります。社内だけの確認では説明が実施者自身の言葉に依存します。
- 01設計した観点と題材で検証を実行し、指摘結果の変化を確認します。
- 02想定と異なる結果は、読み取り・解析の判定・表示の各段で切り分けます。
- 03原因の帰属を実装側のみに置かず、観点側の未定義もあわせて記録します。
OUTPUT原因を切り分けた結果
STEP 04
報告し、次の更新へ観点を引き継ぐ試用や問合せで得た指摘を観点として登録します。
どう確かめるか
あとから示せる形で確認した範囲と結果を残す
試用で指摘された検出の外れや問合せの内容を観点として登録し、報告とあわせて残すことで、次の更新時の確認項目へそのまま引き継げます。個別対応で閉じる形にはしません。
- 01確認した範囲と残した範囲を、品質会議へ上程できる形式で報告します。
- 02利用企業の試用や審査で指摘された検出の外れを、観点として登録します。
- 03登録した観点を次の更新時の確認項目へ引き継ぎ、範囲の見直しに反映します。
OUTPUT引き継げる報告と観点
外注の前とあとで、社内の動きがどう変わるか
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 更新ごとの回帰確認が、委託側の定例作業として回り始めます
- 揺れのある機能の合格線が、文書化した判定基準として残ります
- 品質会議に、確かめた範囲と残した範囲の資料をそのまま上程できます
- 審査質問票に、確認済みの試験結果を根拠として回答できます
提供するテストの内容と対象範囲
解析の仕組み、更新への追随、文書と権限の扱い、判断材料の整備。GENZ が担うテストは、これらの工程に分かれます。各工程で確かめる対象と、お渡しする成果物の形を示します。
契約書の解析と指摘に関する機能テスト
契約書ファイルの読み取りから条文の解析、リスク条項の指摘、修正案の提示まで、形式や体裁の異なる題材を用いて機能の動作を検証します。
解析の更新に対する回帰テスト
解析の仕組みの更新前後で、同一の題材に対する指摘結果を比較し、既存の判定が変わっていないかを確認します。変動の有無と範囲を記録します。
文書の取り扱いと権限に関する検証
取り込んだ文書の保存と削除、権限設定、操作ログの挙動を検証します。情報セキュリティ審査の質問へ回答できる形で結果を整理します。
リリース判断に使う報告書の作成
確かめた範囲と残した範囲、判定の根拠を、品質会議でそのまま使える報告書にまとめます。揺れのある機能は合格の線の設計からご一緒します。
お問合せから結果のご報告までの流れ
AI契約書レビューツールのテストは、お問合せから結果のご報告まで、次の流れで進めます。
お問合せと確認したい範囲の共有
更新計画の日程や確認したい範囲、社内の工数の状況をお聞かせいただきます。
対象範囲の確認と費用の見積提示
切り出す範囲を機能単位で整理し、対象範囲と期間、費用をご提示します。
テスト計画の作成と内容のご承認
確認する項目と判定基準を計画書にまとめ、ご承認のうえで実施します。
検証の実施と確認結果のご報告
計画に沿って検証し、確認した範囲と残した範囲、検出した事象を報告します。
ツールそのものを第三者として確かめる
契約書レビューツールのテストについてご相談ください
ご相談では、更新内容に対するテスト範囲の切り分けと確認の優先順位、必要な工数の考え方を整理してお渡しします。品質会議への起案資料としてそのままお使いいただけます。