工務店・ハウスメーカーのAIモデル変更への備え 同じ指示での品質を確認する

この記事で扱うのは、AI全般の性能比較ではありません。「自社が承認している見積説明、打合せ整理、施主連絡、社内照会を、変更後も同じ確認工程で使えるか」を判定する作業です。通常時の評価項目や誤り区分は、工務店のAI出力評価表｜業務ごとの正確さを測る方法にあるシリーズ共通の「重大・中・軽微」とゲート条件を使います。本稿では別の点数表を作らず、モデル変更時に必要な凍結、盲検比較、原因の切り分け、限定移行、切戻しを具体化します。

モデル名以外の条件を固定できないサービスや、現行モデルを再実行できないサービスでは、厳密な新旧比較はできません。その場合は、過去に担当者が承認した出力、当時の入力一式、修正履歴を基準として保存し、変更後の出力との差を確認します。「同じ条件」と断定できない部分は記録上も明示し、推測で埋めません。

AIを適用する業務そのものの選定は、AIを使う業務候補と優先順位を整理する記事で先に行ってください。本稿の成果物は、「固定テスト台帳」「凍結条件票」「盲検差分票」「原因切り分け票」「採用・切戻し判断票」の5点です。

01.モデル名ではなく、業務条件の変化を確認する

実務上の出力は、モデル本体だけで決まりません。サービス側の共通指示、ファイル参照、Web検索、会話履歴、生成量の上限、出力形式、権限、標準設定などが組み合わさって決まります。モデル名が同じでも周辺機能が変われば品質は動きます。反対に、モデル名が変わっても、使用していない機能だけの更新であれば対象業務への影響は限定的です。

確認の起点は「モデル名が変わったか」ではなく、「承認済みの業務結果を作る条件が変わったか」です。提供会社から更新通知が届いたときだけでなく、次の変化を継続して観察したときも臨時再評価の対象にします。

• 同じ入力なのに、必須項目の欠落が続く
• 「予定」「候補」「未確定」が確定事項へ変わる
• 引用箇所や参照資料の示し方が変わる
• 添付資料を参照せず、一般的な説明を加える
• 表やJSONなど、後工程で使う形式が崩れる
• 出力可能な文章量や添付可能な資料量が変わる
• 利用者が選んでいない検索・連携機能が働く
• 確認と修正に要する時間が継続的に増える

再確認の範囲を調整するため、変更を次のように整理します。これは法令、公的認証、提供会社の公式分類ではなく、自社の試験範囲を決めるための運用区分です。

例えば、文章要約だけにAIを使っている工務店が画像生成機能の更新通知を受けても、画像を扱う試験を増やす必要はありません。一方、モデル名が変わっていなくても、ファイル検索の対象が広がり、廃止済みの標準仕様書を参照するようになったなら、施主説明や仕様比較に直接影響します。

変更内容が分からない場合は、「通知がないから影響なし」とは判断しません。金額、契約状態、性能、工程日、社内承認、顧客への外部送信に関係する業務から確認し、根拠を持って影響なしと判断できない業務は、重要度に応じて利用を狭めます。

02.固定テストは、過去の手修正理由から作る

固定テストは、普段の指示文を寄せ集めた例文ではありません。入力資料、指示文、期待する業務状態、入れてはいけない内容、確認担当、ゲート条件を一つの単位にした試験です。模範解答を一字一句固定する必要はありませんが、「何を保持できれば使えるか」「何が一つでも起きたら止めるか」は実行前に決めます。

以下では、この記事だけの架空例として「工務店例091」を使います。工務店例091は従業員18人、年間の注文住宅引渡し24棟の地域工務店です。この人数と棟数は記事内の全例で固定します。AIの利用対象は、施主連絡、打合せ整理、仕様比較、社内手順の照会の4業務です。実在する会社、サービス、モデルの評価結果を示すものではありません。

工務店例091では、各業務について典型例、境界例、回答不能例を1件ずつ用意し、合計12件を固定テストにします。

12件に普遍的な意味はありません。工務店例091では4業務について3種類の失敗を確認するために12件としています。利用業務が2種類なら6件から始められます。一方、契約判断、法令への適合判断、構造・防火・省エネ性能、安全に関係する用途を含むなら、AIへ判断させてよい範囲そのものを先に見直し、必要に応じて専門資格者や所管担当の確認を組み込みます。

固定テストの材料は、過去3か月程度の手修正記録から集めます。「文章が好みではなかった」ではなく、担当者が何を直したかを抽出します。候補を決定に直された、税込と税別を混同した、添付資料にない数値を加えた、確認先を創作した、といった修正理由を、個人が特定されない架空入力へ置き換えます。

難問を増やすことが目的ではありません。日常業務で発生しない曖昧さを大量に入れると、合格しても実用性の裏付けにならず、不合格の原因も読めません。資料の日付が異なる、前言が後で修正される、金額が未確定、回答が資料に存在しないなど、実務で人が止まる場面を再現します。

現行モデルの出力を見てから、通りやすい合格条件へ書き換えてはいけません。先に業務上必要な条件を定め、現行モデルが満たさないなら、その欠陥も記録します。現行モデルは正解そのものではなく、現在の運用と修正負担を比較する基準です。

03.入力、指示、参照資料、実行環境を凍結する

「同じ指示で比較する」とは、指示文だけを同じにすることではありません。添付資料、資料の版、検索機能、会話履歴、出力形式が違えば、モデル差と条件差を分けられません。試験前に、モデルへ渡る要素と出力を受け取る条件を凍結します。

会話型の画面では、直前のやり取りが回答へ影響する場合があります。固定テストは原則として新しい会話から始めます。過去の会話を参照させる業務を試す場合は、必要な履歴自体をテスト一式に含めます。普段使っている長い会話の途中で候補モデルへ切り替えても、履歴差とモデル差を切り分けられません。

工務店例091のM-01では、次の固定指示を使います。

以下の打合せメモだけを根拠に、社内確認用の記録を作成してください。
「決定事項」「保留事項」「次の対応」の3区分に分けてください。
次の対応には、担当者と期限がメモにある場合だけ記載してください。
記載がない情報は補完せず、「記載なし」としてください。
「候補」「予定」「未確定」「確認後に決定」という状態を変更しないでください。
相互に矛盾する記述があれば、解消せず「要確認」として列挙してください。

固定入力は、次の架空メモです。

キッチン面材はグレーを第一候補とする。最終決定はサンプル確認後。
サンプルは営業担当が10月3日までに手配する。
窓位置は変更なしで決定。
次回打合せ日は未定。

期待するのは、グレーを第一候補として保留事項へ残し、サンプル手配を担当者・期限付きの次の対応にし、窓位置だけを決定事項へ入れる出力です。「面材はグレーに決定」「次回は10月3日」と書けば、文章が自然でも重大な差分です。

最初の比較では指示文も固定します。候補モデルが不適合だった後に指示文を修正する場合は、修正版を別の版として保存し、別試験として扱います。モデルと指示文を同時に変えると、改善の原因が分かりません。

参照資料はファイル名だけで識別しません。「標準仕様書.pdf」ではなく、「標準仕様書_2026-08-01_第4版.pdf」のように版を特定します。ファイルの識別値を管理できる環境では記録し、難しい場合は試験用フォルダを読み取り専用にして、後から同じ内容を確認できるようにします。

04.新旧出力を対にし、モデル名を伏せて差分を見る

評価者がモデル名を知っていると、「新しい方が高性能だろう」「使い慣れた方が安心だ」という先入観が入りやすくなります。比較用の出力からモデル名、実行順、処理時間、料金表示を外し、「出力X」「出力Y」として業務担当者へ渡します。文体から推測される可能性は残りますが、少なくとも最初の判定が終わるまでは識別情報を見せません。

工務店例091では、12テストを現行モデルと候補モデルで各2回実行します。合計は48出力です。2回実行するのは平均点を精密に出すためではなく、同じ条件で重大な欠落が発生するかを見るためです。重要情報が一度でも消えるなら、「たまたま通る」状態のまま本番へ移しません。

比較では文章全体を読み比べる前に、入力側の確認単位を並べます。M-01なら「第一候補」「サンプル確認後に決定」「営業担当」「10月3日」「窓位置は決定」「次回日未定」の6点です。それぞれが出力のどこへ移されたかを確認し、欠落、追加、状態変化を記録します。

評価者が2人いる場合は、相談する前にそれぞれ記入します。判定が分かれた項目だけ、入力のどの文と出力のどの文を根拠にしたかを照合します。「丁寧に見える」「以前より自然」といった印象は、重大・中・軽微の根拠にしません。

処理時間と利用料金は、品質判定とは別欄に記録します。最低品質を通過した候補同士であれば、速度や費用を採用判断に使えます。しかし、応答が速いから重大な誤りを許容する、料金が低いから確認工程を省く、という相殺はしません。

新旧のどちらが優れているかを一般化する必要もありません。「候補モデルは数字に弱い」ではなく、「S-02の2回中1回で税区分を保持せず、税込・税別が混在した差額を記載した」と書きます。再現条件を残せば、次の更新でも同じ失敗を試せます。

モデル名の開示後に判定を変える場合は、変更理由を残します。「新しいモデルだから許容した」「旧モデルだから安心した」では変更できません。参照機能が新旧で異なっていた、片方だけ会話履歴が残っていたなど、凍結条件の不一致が確認された場合は、その実行を無効としてやり直します。

05.判定は「重大・中・軽微」とゲート条件に統一する

本稿専用の0・1・2点や総合点は設けません。判定は工務店のAI出力評価表｜業務ごとの正確さを測る方法の共通区分に合わせます。

• 重大：そのまま使用すると、安全、契約、金額、性能、工程、顧客の意思、情報管理、社内承認などに看過できない影響があり、利用停止または責任者への引上げが必要な誤り
• 中：使用前の修正が必要で、修正しないまま次工程へ渡せない誤り
• 軽微：業務上の意味や判断を変えず、表記や体裁の限定的な修正で済む誤り

合計件数で相殺しません。重大が1件あれば、そのゲートに関係する業務は不通過です。軽微な改善が多数あっても、未確定金額の断定や日付変更を埋め合わせることはできません。

モデル変更時に繰り返し現れやすい問題は、独立した評価尺度ではなく「重大」の下位区分として記録します。これにより、シリーズ共通の記録様式を保ちながら、切り分け先を特定できます。

中または軽微の誤りを、上表の下位区分へ無理に当てはめません。例えば、見出しの名称が指定と違って人が部分修正する必要があるなら「中」、句読点や改行だけの違いで業務上の意味が変わらないなら「軽微」です。金額が正しくても、税込・税別の表示が落ちて読み手を誤らせるなら、単なる体裁不備とは扱いません。

工務店例091では、次のゲートを業務ごとに設定します。

業務によってゲートの適用内容は変わります。社内のアイデア出しでは数値・条件保持を使わない場合がありますが、情報管理と承認範囲は残ります。施主連絡、見積説明、仕様比較では、根拠境界、状態保持、数値・条件保持を外せません。

「現行モデルより候補モデルの誤りが少ない」ことも、単独では採用理由になりません。まず候補モデルがゲートを通過するかを見ます。次に現行モデルから新たな後退がないか、最後に修正負担や速度、費用を比較します。現行モデルにも重大な欠陥が見つかった場合は、候補を自動的に合格とせず、両方の利用条件を見直します。

06.出力差分を、修正文と再試験条件へ変える

差分記録は、問題のある文を指摘するだけでは不十分です。「入力上の事実」「問題のある出力」「人が使える修正文」「次に確かめる条件」を対にします。修正文は模範的な美文ではなく、業務状態を元へ戻した完成文にします。

以下は、工務店例091の条件を使った架空の出力例です。実在するモデルの性能を示すものではありません。

C-03の問題は敬語ではなく、見積前という状態を費用発生済みに変えたことです。指示文へ「未確定、検討中、見積前、承認前という状態語を変更しない」と追加する余地はあります。ただし、一件が直っただけでは採用しません。同じ施主連絡に属するC-01からC-03までを再実行し、強い制約によって必要な説明まで落ちていないかも確認します。

M-03では、資料の日付が新しいことと、記載内容が正しいことを分けます。後の資料が誤記である可能性もあるため、AIに正しい予定日を選ばせるのではなく、不一致を検出させて担当者へ戻します。ここでの合格は正解を当てることではなく、根拠不足の状態で決めないことです。

S-02のような計算では、式だけでなく前提を確認します。税別2,000,000円と税込2,100,000円が並んでいても、単純に100,000円差とは判断できません。税区分、対象工事、諸費用、値引き、比較時点がそろっているか分からないからです。固定テストには「計算する条件」だけでなく「比較不能として止まる条件」も含めます。

Q-03は、一般知識がかえって危険になる例です。一般的な会社で部門長が代理承認することがあっても、工務店例091の規程に書かれていなければ社内ルールとして回答できません。回答量が多いモデルより、資料の境界で止まれるモデルが適します。

一方、改行、見出し、丁寧語だけが変わり、事実、状態、利用判断が維持されているなら、モデル変更を止めるほどではない場合があります。ただし、その形式が自動取込や顧客向けテンプレートの必須条件なら、見た目の問題ではなく後工程の不適合です。同じ差分でも利用先によって「中」と「重大」が変わり得るため、影響先まで記録します。

修正文を蓄積すると、「予定」「候補」「目安」「原則」「別途」「要確認」「見積前」「承認後」など、モデル変更で失われやすい語が分かります。個別の文章を毎回直すのではなく、凍結した指示文と確認票へ「状態語保持」を加え、関連する固定テストで再確認します。

07.不合格の原因は、一度に一条件ずつ切り分ける

変更後の出力が悪化しても、直ちに「新モデルの性能が低い」と断定できません。ファイルの読込失敗、検索対象の変更、長い入力の途中切れ、会話履歴、出力上限、標準設定、表示側の整形、指示文との組合せなどが原因になり得ます。原因を誤れば、旧モデルへ戻しても同じ問題が残ります。

切り分けでは、最初に不合格時の一式を保存します。そのうえで同じ条件でもう一度実行し、再発するかを確認します。次に入力・添付・履歴が一致しているかを見ます。その後、検索や添付などの機能を一つずつ外し、最後に指示文だけを修正します。複数条件を同時に変えると、改善理由を特定できません。

再実行で問題が消えても、最初の重大な誤りは消しません。「同条件2回中1回で状態改変」として残します。施主送信前に必ず元資料と照合する下書き業務なら、確認工程で吸収できる可能性があります。しかし、無人送信、自動転記、自動承認など、人が確認しない工程では、一度の重大差分でも利用条件を満たしません。

例えば、添付した仕様書を参照しない問題が、同じ内容を本文へ貼ると解消した場合、「モデルが仕様書を読めない」とは断定しません。「添付経由では2回中2回参照されず、本文貼付では2回中2回参照された」と記録します。提供会社へ問い合わせる場合も、評価語ではなく再現条件を渡します。

指示文の修正で改善した場合、元の指示を上書きしません。「第1版はM-01で状態改変、第2版は状態語保持の文を追加して再試験」と履歴を残します。後から理由の分からない制約文が増えると、指示同士が矛盾し、新しい欠落を生むためです。

現行モデルでも同じ不合格が起きた場合は、モデル変更による後退ではなく、以前から存在した運用上の弱点です。それでも候補モデルを無条件で採用する理由にはなりません。指示文、参照資料、確認工程のいずれかを直し、両モデルがゲートを通るかを再確認します。

原因を確認している間も、重大な誤りを含む出力を本番へ流してはいけません。まず利用範囲を止め、次に記録を保全し、その後で原因を調べます。原因究明より拡大防止を先にします。

08.再現性を確保しながら、顧客情報を増やさない

固定テストには再現性が必要ですが、そのために実在する顧客情報、未公開図面、見積書、従業員情報を複製し続けるのは避けます。試験の目的は特定顧客の案件を再現することではなく、業務上の条件と失敗の構造を再現することです。

打合せメモで必要なのが「第一候補と決定の区別」であれば、施主名や実在商品名は不要です。「面材Xを第一候補とし、サンプル確認後に決定」と置き換えられます。価格比較でも、実案件の金額を使わず、税区分、単位、対象範囲の違いが残る架空金額にできます。

架空化では、単に氏名を消すだけでなく、住所、電話番号、メールアドレス、建築地、地番、家族構成、固有の要望、図面番号、取引先管理番号などを組み合わせて個人や案件を特定できないか確認します。一方、判断に必要な「未確定」「税込」「第4版」「担当者未定」といった業務状態は残します。状態まで消すと試験になりません。

図面読取や自社独自仕様の検索など、架空化すると試験の意味が失われる業務では、利用前に次の事項を確認します。

• 業務利用が認められた契約とアカウントか
• 入力データの保存先と保存期間を確認できるか
• 提供者による学習利用や二次利用の条件を確認できるか
• アクセス権限と退職・異動時の停止手順があるか
• 入力、出力、会話履歴を削除する方法を確認できるか
• 外部連携や検索機能へ情報が渡る範囲を確認できるか
• 自社の情報管理責任者が試験範囲を承認したか

確認できない条件を「おそらく保存されない」「有名なサービスだから問題ない」と推定して進めません。必要な条件が確認できなければ、架空データだけで試すか、その機能の試験を延期します。

AIの利用者を含む事業者向けのガバナンス原則については、総務省・経済産業省「AI事業者ガイドライン」の掲載ページを参照できます。ただし、固定テストの件数、工務店の承認様式、本稿のゲート条件を定めた資料ではありません。本稿の手順は、公的資料の趣旨を工務店のモデル変更管理へ落とし込んだ独自の運用案です。既公開記事では「第1.2版、2026年3月31日公表」と表記していますが、版、公表日、掲載URLは公開前にリンク先の原典で最終確認してください。

また、IPAのページに掲載されている「テキスト生成AIの導入・運用ガイドライン」は、リスクを整理する際の参考にできますが、卒業プロジェクトの成果物であり、IPAの公式見解ではありません。特定サービス、モデル、工務店の運用が安全であることを保証する資料としては扱いません。

モデル変更記録には入力全文を毎回複製せず、版管理したテスト原本を権限管理された場所へ置き、実行記録にはテストIDと版番号を記します。スクリーンショットには会話一覧、アカウント名、他案件のファイル名が映ることがあるため、必要範囲だけを保存します。保管先、閲覧者、保持期間、廃棄方法も社内で決めます。

試験を担当者の個人アカウントで行うと、契約条件、履歴、設定、削除、退職時の引継ぎを統一できません。業務利用を承認したアカウントと環境を使い、記録を担当者個人の会話履歴だけに残さないようにします。

09.採用、限定利用、延期、停止を業務ごとに決める

試験後の判断は、モデル単位の「良い・悪い」ではありません。業務ごとに全面採用、限定採用、条件付き採用、再試験、移行延期、利用停止を選びます。仕様比較が不通過でも、施主連絡の下書きが全ゲートを通過していれば、環境と権限を分けられることを条件に、後者だけを移行できます。

条件付き採用で「人が確認する」とだけ書いてはいけません。工務店例091のM-01なら、「営業担当が社内転記前に元メモと照合し、決定事項、保留事項、担当者、期限の4項目へ確認印を付ける」と定めます。確認者、照合資料、確認単位、実施時点が分からなければ、ゲートを補う工程にはなりません。

修正負担も採用判断へ含めます。ただし、重大・中・軽微の区分とは別に、「確認のみ」「部分修正」「全面再作成」で記録します。候補モデルの文章が滑らかでも、毎回すべての数値を再入力する必要があるなら、業務改善とはいえません。反対に、見出し名だけの部分修正で済み、重要状態を安定して保持できるなら、限定的に採用できる場合があります。

旧モデルの終了期限が迫っていても、未試験の候補を重要業務へ一斉投入しません。施主連絡は文案作成まで、仕様比較は表計算と人の照合へ戻すなど、業務別に代替手順を選びます。「期限が来たから合格」と品質基準を変更してはいけません。

採用承認には、AIの技術担当だけでなく、出力を受け取る業務責任者を含めます。打合せ記録なら営業・設計、仕様比較なら積算・設計、社内照会なら規程の所管者です。技術担当が再現条件と差分を説明し、業務責任者が利用範囲、確認工程、切戻し条件を決めます。

10.本番移行を限定し、事故対応までつなげる

固定テストに合格しても、実案件には試験で扱っていない言い回しや資料構成があります。全面展開の前に、対象業務、利用者、期間を限定します。工務店例091なら、18人全員へ同時展開せず、ゲートを通過した業務を担当者2人で2週間使う、といった範囲を設定します。この人数と期間は説明用であり、処理件数、担当者の経験、業務への影響に応じて自社で決めます。

限定運用中は、固定テストで重大となった状態保持、数値・条件保持、根拠外補完を重点的に見ます。軽微な言い換えをすべて大量に記録すると、重大な後退が埋もれます。新しい失敗が見つかった場合は、実案件をそのまま保存せず、情報を架空化して固定テストへ追加します。

切戻しは問題発生後に考えるのではなく、移行前に準備します。

本番で重大な誤りを見つけたら、最初に該当業務の利用を止めます。次に、不合格時の入力・出力・実行条件を保存します。その後、同じ出力が社内転記、顧客送信、Web掲載、見積、契約説明に使われていないかを確認します。原因分析は拡大防止と影響確認の後です。

誤送信、誤掲載、顧客への誤説明など、すでに外部への影響が生じている場合は、モデル変更試験の記録修正だけでは終えません。工務店のAI利用ミスへの対応｜誤送信・誤掲載の連絡と修正へ引き継ぎ、公開・送信の停止、証拠保全、影響範囲の確認、責任者への引上げ、連絡・訂正の判断という順で事故対応へ切り替えます。

事故に至っていない不合格は、AIの誤回答について原因と再発条件を記録する記事の様式へつなぎます。ただし、「AIが幻覚を起こした」と先に決めず、添付失敗、検索範囲、履歴、入力不足、出力形式、人の確認漏れを分けて記録します。

モデル変更記録には、変更の起点、対象業務、固定テストの版、凍結条件、現行・候補の識別情報、重大・中・軽微の件数、ゲートの通過状況、指示修正、最終判断、承認者、切戻し条件を残します。サービス側の内部版が分からない場合は、画面表示名、実行日、更新通知の件名など、確認できる範囲だけを書き、「内部版は確認不可」と明記します。

工務店例091の完成記録は、次のようにまとめられます。

主要機能の変更として、C・M・S・Qの12件を固定テスト第3版で実行した。候補モデルはS-02の2回中1回で税区分を保持せず、税込・税別が混在した差額を記載したため、数値・条件保持ゲートを不通過とした。仕様比較は移行延期とし、施主連絡、打合せ整理、社内照会は各ゲート通過後に限定採用する。施主連絡は営業担当が送信前に日付、金額、確定状態を元資料と照合する。限定運用は担当者2人、2週間とし、重大差分が1件でも発生した場合は該当業務を停止する。旧モデルへ戻せない場合は、従来テンプレートと手作業へ切り替える。

これは架空の判断例であり、特定モデルの実際の性能を示すものではありません。

明日から始める場合は、まずAIを継続利用している業務を一つ選びます。外部送信、金額、日付、決定状態、社内承認に関係する業務を優先します。その業務で過去に人が直した理由を三つ集め、典型例、境界例、回答不能例に分けます。

次に、各テストへ保持条件とゲート条件を書きます。「正確にまとめる」「分かりやすく書く」では判定できません。「決定と保留を分ける」「保留を決定へ変えたら状態保持ゲート不通過」のように、入力と出力を照合できる文にします。

その後、指示文、架空入力、参照資料、会話履歴、利用機能、出力形式を凍結し、現行モデルと候補モデルを新規会話で実行します。識別情報を外して差分を確認し、重大・中・軽微とゲート条件で記録します。重大な差分があれば総合点で相殺せず、利用を止めて原因切り分けへ進みます。

指示文の修正で改善した場合は、問題が出た1件だけでなく、同じ業務の関連テストを再実行します。採用時は業務、利用者、期間を限定し、旧モデル、旧指示文、従来テンプレート、停止連絡先を残します。新しい失敗は架空化して固定テストへ追加します。

工務店が管理すべきなのは、AIの内部構造を完全に理解することではありません。自社が渡した入力、守るべき業務状態、越えてはいけない資料の境界、確認者、利用範囲、戻し方を管理することです。

同じ指示で品質を確認するとは、文章の好みを比べる作業ではありません。入力と実行条件を凍結し、モデル名を伏せて差分を見て、重大・中・軽微とゲート条件で判定し、不合格の原因を一条件ずつ切り分ける作業です。モデルが更新されるたびに固定テスト、限定移行、切戻しを同じ様式で繰り返せれば、名称や宣伝文句ではなく、「自社の仕事に使い続けられるか」という基準で判断できます。