工務店・ハウスメーカーの業務マニュアルをAIで作る 現場手順を検証する方法

重要なのは、AIが書いた文章の自然さではなく、現場で再現できるかどうかです。対象業務を一つに絞り、根拠資料をそろえ、AIの出力を「確認済みの事実」「暫定案」「未確認」に分けます。そのうえで、通常案件と例外案件の双方について、机上再現と限定した実地試行を行います。担当者によって結果が変わる箇所、参照資料へ戻れない箇所、異常時に止まれない箇所が残るなら、文章が整っていても公開してはいけません。

マニュアル全体の章立て、文体、利用者別の形式、旧版切替などの共通設計は「工務店の業務マニュアル｜読まれる手順書の作り方」の担当範囲です。また、複数業務に共通するAI出力の採点方法は「工務店のAI出力評価表｜業務ごとの正確さを測る方法」で扱っています。本記事では重複を避け、AIで作った一つの現場手順を、根拠照合、案件再現、例外テスト、試行運用によって正式版へ直す仕事に絞ります。

01.AIに任せるのは執筆ではなく、検証可能な下書きへの変換

AIでマニュアルを作ると聞くと、白紙から完成文を生成する作業を想像しがちです。しかし、工務店の現場手順には、社内の役割分担、採用している申請様式、取引先との連絡方法、案件ごとの承認条件など、その会社でしか確定できない情報が含まれます。AIは、それらが入力されていなければ、一般的に見える文章で空白を埋めることがあります。

そこで、AIの役割を「完成版を書く人」ではなく、「散在した情報を検証しやすい形へ仮編集する補助者」と定義します。AIに求める成果物は美文ではありません。根拠の所在、判断条件、実行者、記録先、未確認事項が分離され、現場担当者が誤りを具体的に指摘できる下書きです。

たとえば「現場監督は着工前に必要書類を確認する」という文は、読みやすくても手順としては不十分です。必要書類が何を指すのか、どの版を確認するのか、不足時に誰へ戻すのか、確認済みであることをどこに残すのかが分からないからです。AIには、曖昧な一文を次の八要素へ分解させます。

• 実行者：誰が行うか
• 開始条件：何がそろったら始めるか
• 入力：どの資料、画面、現物を使うか
• 操作：どの順序で何を行うか
• 判断：何を見て合格、不足、保留に分けるか
• 例外：通常どおり進められない場合にどうするか
• 記録：結果をどこへ、どの単位で残すか
• 完了条件：次工程へ渡せる状態は何か

八要素が下書きに現れていれば、担当者は「参照する一覧が違う」「その判断は監督ではできない」「記録欄が存在しない」と具体的に指摘できます。反対に、「適切に確認する」「必要に応じて共有する」「速やかに対応する」といった表現のままでは、実行者ごとの解釈差を検証できません。

本記事では、架空例である「工務店例027」を一貫して使用します。工務店例027は注文住宅を年間18棟施工する社員12人の工務店で、社員のうち現場監督3人、設計担当2人、営業担当3人、工務事務1人が着工前業務に関わるという設定です。検証対象は「着工前の現場引継ぎ」とし、営業、設計、積算から現場監督へ情報を渡し、監督が着工可能かを記録するまでを範囲とします。ここで示す人数や棟数は検証方法を説明するための仮定であり、一般的な工務店の標準値や実績を示すものではありません。

最初に決めるべきことは、利用するAIサービスではなく、どの段階から人が責任を引き取るかです。工務店例027では、AI出力を「未承認の編集案」と表示し、担当者による根拠照合を終えるまで正式版の保管場所へ入れないと定めます。これにより、読みやすい下書きが事実確認前に既存ルールとして扱われる事故を防ぎます。

02.対象業務の入口と出口を一枚で固定する

マニュアル作成が長引く原因の一つは、作業中に対象範囲が広がることです。「着工前の引継ぎ」を整理していたはずが、営業契約、設計変更、発注、工程管理まで入り込み、どこから検証すればよいか分からなくなります。AIは入力された話題を自然につなげられるため、人が境界を決めなければ隣接業務まで一つの手順へ混ぜてしまいます。

着手時には、対象業務の入口、出口、対象外、責任者を一枚の範囲票にします。文章を書く前に作ることが重要です。検証中に新しい論点が出ても、この範囲票と照合し、今回直す事項か、隣接する手順へ送る事項かを判断できます。

この範囲票は、完成文の目次ではなく検証の境界線として使います。たとえば試行中に「地盤改良工事の発注時期が分からない」という問題が出た場合、着工可否に必要な確認項目なら今回の手順へ入れます。一方、発注操作の詳細は資材・外注発注の手順へ送り、今回の本文には正式な参照先だけを残します。

入口と出口は、日付ではなく状態で定義します。「契約後」「着工前」のような時期表現だけでは、案件が止まったときに誰の手元にあるか判定できません。「設計担当が準備を開始した状態」「監督が三つの判定のいずれかを記録した状態」とすれば、案件管理画面から未完了案件を拾いやすくなります。

対象外を明記することも品質管理の一部です。対象外の情報を無視するという意味ではありません。発見した問題を別の課題として受け止め、今回の手順へ無制限に混ぜないために分けます。課題票には、発見日、対象工程、関連案件、隣接業務、現在の暫定対応、引受責任者を記録します。

03.AIへ渡す前に、根拠資料を強さで分ける

現場手順の検証では、情報量よりも根拠の優先順位が重要です。古いチェックリスト、担当者の記憶、案件管理システムの項目、会議で決まった運用が食い違うことは珍しくありません。これらを区別せずAIへ渡すと、AIは複数の記述を滑らかな一つの手順へ統合し、食い違いそのものを見えにくくします。

資料を集める段階で、採用できる根拠、運用の証拠、担当者の説明、外部の参考情報、出所不明資料に分けます。ここでいう根拠の強さは、法律上の証明力ではなく、工務店例027が社内手順を確定するための管理区分です。社内承認済みの資料でも、最新版か、今回の対象業務へ適用できるかを確認します。

資料同士が矛盾したら、AIに多数決をさせません。現行様式では「設計担当が登録」、完了案件では「工務事務が登録」、聞き取りでは「監督が登録」となっている場合は、三つの記載と根拠IDを併記して責任者へ返します。誰が行うべきかを決めるのは組織の仕事であり、AIの文章生成によって決定済みにしてはいけません。

入力資料には、顧客名、住所、連絡先、契約金額、図面、写真などが含まれる可能性があります。AIサービスへ何を入力できるかは、利用契約、組織の情報管理方針、サービス設定、データの保存条件や二次利用条件によって変わります。まず実データを入力する必要があるかを検討し、不要なら空欄の様式、匿名化した項目名、個人を識別できない条件票を使います。匿名化したつもりでも、住所、日付、担当者、特殊な仕様の組合せから案件を推測できる場合があるため、項目を一つずつ消すだけでなく組合せも確認します。

組織としてのAI利用方針を検討する際は、AIに関わる主体の役割やリスクへの対応を扱う総務省・経済産業省「AI事業者ガイドライン（第1.2版、2026年3月31日公表）」を確認先にできます。参照するのはAIガバナンスやリスク管理に関する一般的な考え方の範囲です。同ガイドラインが、工務店例027における個別データの入力可否、法的判断、利用サービスの安全性、社内承認手順を個別に決定するものではありません。具体的な入力範囲と権限は、利用規約や自社の情報管理方針を確認したうえで、情報管理責任者が定めます。

04.入力資料を「事実・差分・質問」の三つに整える

資料を集めただけでAIへ入力すると、どの記述を確定事項として扱うべきかが伝わりません。入力時点で、確認済みの事実、資料間の差分、現場へ確認する質問を分けます。AIへ「推測しないでください」と指示するだけでなく、推測せずに処理できる入力構造を作ることが大切です。

工務店例027では、全資料を一度に読み込ませず、対象工程ごとに入力パックを作ります。一つの入力パックは、一つの開始条件から一つの完了条件までを扱います。着工前引継ぎなら、「設計担当による資料準備」「監督による受領確認」「不足時の差戻し」「着工可否の記録」に分けます。

入力パックを作るのは人です。AIは、資料名や根拠IDを所定の欄へ並べる形式整理を補助できますが、どれが確定事実か、どの差分が未解決かを認定できません。

AIへの依頼文は、たとえば次のようにします。

以下の入力パックだけを根拠に、現場担当者が実行できる仮手順へ整理してください。各手順に、実行者、開始条件、入力、操作、判断条件、記録先、完了条件、根拠IDを付けてください。資料にない内容は補完せず、〈未確認〉と表示してください。根拠同士が矛盾する場合は本文へ統合せず、差分一覧へ出してください。「適切に」「必要に応じて」「速やかに」を使う場合は、判定可能な条件へ置き換えるための確認質問を作ってください。一般知識からの提案は〈改善候補〉として本文と分離してください。

「一般的な工務店の手順を教えてください」という依頼とは目的が異なります。一般例は論点発見には使えても、工務店例027の正式手順の根拠にはなりません。AIが一般知識から追加した提案は「改善候補」として本文から分離します。採用する場合は、責任者が業務変更として判断し、決定記録へ根拠IDを付けてから本文へ移します。

AIの出力後は、文章を推敲する前に根拠IDがない文を抽出します。根拠なしの文が、単なる接続表現なのか、一般的な改善提案なのか、判断条件の創作なのかを分けます。実行者、期限、承認条件、停止条件、記録先に関わるなら、責任者の確認なしに残せません。

また、「資料に書いてあること」と「現場で実行できること」は別です。正式資料に曖昧な記述がある場合、AIが忠実に再現しても手順としては不十分です。その箇所はAIの誤出力だけでなく、元の業務ルールの未整備として課題票へ送ります。

05.AIの下書きを一文ずつ検証可能な命令へ直す

AIの初稿には、意味は通るものの行動に移せない文が残りやすくなります。検証担当者は文章の好みではなく、同じ条件で同じ動作と判断に到達できるかを見ます。主語、対象、参照先、期限、判定条件、記録先のいずれかが欠けていれば、文を分割します。

たとえば、AIが次のように出力したとします。

現場監督は、着工前に関係者から必要資料を受け取り、内容に問題がないか確認する。問題があれば速やかに共有し、必要に応じて修正を依頼する。

これでは、関係者、必要資料、期限、問題の定義、共有先、修正依頼の記録方法が不明です。工務店例027では、根拠を確認したうえで次のように直します。

設計担当は、確認依頼を登録する前に、現行の「着工前引継ぎ一覧」に記載された資料の登録状態を確認する。すべて登録済みの場合は、案件管理システムの「着工前確認」欄で担当現場監督を指定し、確認依頼日を記録する。未登録の資料が一つでもある場合は確認依頼を登録せず、不足資料名と準備担当を同欄へ記録する。

現場監督は、確認依頼を開き、「着工前引継ぎ一覧」と登録資料を照合する。一覧にある資料がすべて登録され、各資料の版表示が一覧と一致する場合は内容確認へ進む。不足または版の不一致がある場合は確認を停止し、差戻し欄へ対象資料名、表示されている版、差戻し理由を記録して設計担当へ戻す。

確認期限を「翌営業日まで」としたい場合でも、その期限が正式根拠にないなら採用しません。AIが追加した可能性があるため、「確認期限を設定するか」という改善候補へ戻します。責任者が実行可能な期限を決定し、その決定記録へ根拠IDを付けた後で本文へ入れます。

「関係者へ確認する」とあれば、誰が誰へ、何を提示し、どこへ回答を残すかへ直します。「問題がなければ進める」とあれば、問題なしの判定項目を列挙するか、現行チェック票を参照させます。「随時更新する」とあれば、更新を起動する出来事と更新責任者を決めます。

一方で、操作を過剰に細分化する必要はありません。ログイン、クリック、スクロールといった説明は、対象者が迷う箇所だけにします。画面が頻繁に変わるシステムでは、ボタン位置を逐一書くと保守負担が増えます。手順本文には目的、入力欄、選択条件、保存後の状態を残し、画面操作が難しい箇所だけ補助資料へ分けます。

06.根拠照合で「正しい文章」ではなく「正しい手順」を確かめる

文章を具体化した後は、各手順を根拠へ戻して照合します。AIが資料中の語句を正確に引用していても、順序や適用対象を取り違えていることがあります。また、一つの段落に複数資料の内容が混ざると、どの部分がどの根拠に支えられているか追えません。

工務店例027では、仮手順の各行に手順IDを付け、根拠ID、検証結果、影響区分、修正内容を差分記録へ残します。文章全体の平均点ではなく、業務結果を変える欠陥が残っていないかを確認します。

影響区分は「合格」「要修正」「重大」「公開停止」の四つに統一します。

• 合格：根拠と一致し、担当者がそのまま実行できる
• 要修正：説明不足はあるが、既存の根拠を変えずに書き直せる
• 重大：担当、順序、判断、記録先が誤っており、使うと業務結果が変わる
• 公開停止：承認条件、停止方法、権限などが未決定で、文章修正だけでは解決できない

S-05のように、システム上の選択肢が存在しても選択条件が決まっていない場合、マニュアルの表現だけでは解決できません。工務責任者が、条件付きで残せる事項、解除責任者、解除期限、未解除時の扱いを決める必要があります。

根拠照合は作成者一人で終わらせません。工務店例027では、設計担当を作成者、現場監督を実行者、工務事務を記録確認者、工務責任者を承認者とします。同じ人が複数の役割を兼ねる場合でも、作成直後に自分だけで承認せず、完了案件の記録との照合、時間を空けた再確認、別担当者による試行など、作成と承認の行為を分けます。

AI利用時のリスク整理では、IPAの中核人材育成プログラムにおける2024年度卒業プロジェクト成果物として掲載された「テキスト生成AIの導入・運用ガイドライン」も参考にできます。ただし、これはIPAの公式見解を示す公式ガイドラインとして扱うものではありません。また、特定のAIサービスの安全性や、AIが作成した手順の正確性を保証する資料でもありません。工務店例027では、入力情報の種類、誤出力が生じた場合の影響、閲覧権限、検証責任を自社の利用場面ごとに判断します。

07.実案件三経路と模擬三経路で手順を再現する

根拠照合を終えても、手順の順番が現実の案件に合うとは限りません。次に、完了済み案件の記録と、過去記録を編集して作る模擬条件を使い、入口から出口まで机上で再現します。過去案件をAIへ直接入力することが目的ではありません。検証担当者が必要な記録を確認し、匿名化した条件票を作り、その条件で手順をたどります。

工務店例027では、完了案件から次の三件を選びます。

• 全資料がそろい、通常どおり着工可となった案件
• 指定資料の不足によって差戻しが発生した案件
• 未決事項があり、責任者の決定した条件を付けて保留または条件付き可を検討した案件

この三件だけでは、版の不一致、着工予定日の変更、担当監督の不在という経路を検証できません。そこで、匿名化した過去記録の複製を使い、一つの条件だけを編集した模擬条件を三件作ります。模擬条件は実際に起きた事実や実績として扱わず、ファイル名、条件票、結果記録へ「模擬」と明記します。

たとえば版不一致のテストでは、通常案件の条件票を複製し、一つの図面だけ版表示を変更します。着工日変更のテストでは、承認後に着工予定日が変更された状態を追記します。監督不在のテストでは、担当監督が所定期間不在で代理者候補だけが登録されている状態にします。一度に複数条件を変えると停止原因を判定しにくいため、初回は一条件ずつ編集します。

実案件三経路は、現実の記録と手順のつながりを確かめるために使います。模擬三経路は、過去案件だけでは存在しない条件でも停止と復帰が機能するかを確かめるために使います。模擬条件が通ったとしても、その事象が実案件で十分に検証されたことにはなりません。公開後に同じ事象が実際に発生したら、実記録を使って再確認します。

机上再現では、各手順について「実行できた」「追加確認が必要だった」「実行不能だった」を記録します。追加確認が必要だった場合は、何を誰に聞いたかも残します。経験者の補足説明がなければ進めないなら、マニュアル単独では再現できていません。

T-01だけを通して公開すると、通常時には使えても、問題が起きた瞬間に経験者の口頭判断へ戻ります。差戻し、版不一致、条件付き判断、再確認、代行という分岐も初期検証へ含める必要があります。

過去案件の結果と現在の手順が食い違ったときは、「過去の担当者が間違っていた」「現在のマニュアルが間違っている」と即断しません。まず、その案件当時の正式ルール、現在のルール、一時的な例外承認を分けます。過去には正しかったものの現在は使わない運用なら、現行手順へ混ぜず、変更履歴に理由を残します。

再試行では、前回の経験を記憶している担当者だけでなく、可能なら別の対象者にも読んでもらいます。別の担当者が同じ箇所で止まるなら説明不足の可能性が高く、異なる箇所で止まるなら用語や前提知識の差を調べます。

08.例外は網羅せず、停止・連絡・記録・再開の順序を決める

建築案件ですべての例外を事前に列挙することは困難です。例外を網羅しようとするとマニュアルが長くなり、通常手順が見つけにくくなります。必要なのは、頻度や影響の大きい分岐を具体化し、それ以外の異常を発見したときに勝手な判断で進めない仕組みです。

工務店例027では、例外を次の四種類に分けます。

• 不足：必要な資料、入力、承認がそろっていない
• 不一致：資料同士、版、担当者の説明が一致しない
• 変更：承認後に条件、日程、仕様、担当が変わった
• 実行不能：システム障害、不在、権限不足などで所定の操作ができない

「想定外」「特殊」「その他」とだけ書くと、記録を集計して改善できません。担当者は、まず四種類のいずれかを選び、対象、発見時点、現在の案件状態を記録します。分類できない場合だけ「分類外」とし、責任者が後から分類体系の追加要否を判断します。

安全への影響や緊急性が疑われる場合は、通常の差戻しより先に次の順序で行動します。

1. その作業と関連する進行を止める 2. 人への危険が差し迫っている場合は、人を危険箇所から離し、立入りを防ぐ 3. 自社が定めた緊急連絡網に従って現場責任者へ連絡し、状況に応じて消防・救急などの緊急機関へ通報する 4. 安全を確保できた後、発見時刻、場所、対象、停止した作業、実施した連絡を記録する 5. 所定の責任者が再開条件を示し、必要な確認が記録されるまで作業を再開しない

マニュアルだけで、法令への適合、設計内容の適否、契約上の責任、製品の施工条件を一般化して断定してはいけません。対象事項に応じて、社内の責任者や有資格者、設計者、メーカーの公式資料、関係機関、必要に応じた専門家へ確認します。誰へ確認すべきかが未決定なら、それ自体を公開停止事項として扱います。

緊急性がなく、書類や情報の異常として処理できる場合も、順序を固定します。

1. 該当手順を止める 2. 不足、不一致、変更、実行不能のいずれかを選ぶ 3. 対象資料、版、発見した状態を正式な記録欄へ残す 4. 手順で指定された役割へ渡す 5. 再開判断者と再開条件を確認する 6. 再開後に、停止記録と解決記録が対応していることを確認する

版不一致を発見した監督は、正しい版を推測して作業を続けません。確認を停止し、該当資料名と二つの版表示を記録して設計担当へ差し戻します。設計担当が採用版を正式な記録先で確定し、監督が再確認するまで完了にしません。

連絡先は個人名ではなく、「設計担当」「工務責任者」のような役割で記載します。そのうえで、案件管理システムから現在の担当者を特定できるようにします。代行可能な判断と、指定された責任者でなければできない判断も分けます。

所定のシステムが使えない場合も、記録を省略してよいことにはしません。承認済みの代替記録方法、保存先、復旧後に正式記録へ転記する担当、転記確認者を決めます。代替手段が未定なら、責任者が決めるまで当該手順を正式公開しません。

09.現場試行では正解率より「迷い方」を記録する

机上再現を通過したら、限定した実案件で試行します。いきなり全案件へ適用せず、対象期間、対象案件、参加者、試行を止める条件、現行手順へ戻す条件を決めます。工務店例027では、次に引継ぎを行う新築注文住宅二件を対象に、設計担当一人と現場監督二人が試行する想定です。この件数は品質保証の一般基準ではなく、手順上の欠陥を見つけるための初回試行条件です。

試行中に測るのは所要時間だけではありません。時間が短くても、経験者が記憶で補っていれば再現性はありません。次の事実を手順IDと結び付けて記録します。

• 手順どおりに進めなかった箇所
• 用語の意味を他者へ質問した箇所
• 参照先を探すために別資料を開いた箇所
• 判断条件が重なり、選択に迷った箇所
• 記録欄がなく、自由記述や口頭連絡で代用した箇所
• 手順外の行動を取った理由
• 例外から通常経路へ戻れなかった箇所
• 危険や重大な不一致を発見した際に、停止できなかった箇所

担当者には、マニュアルを守れなかった人を責めるための記録ではないと説明します。現場が手順から外れた理由には、教育不足だけでなく、手順の誤り、システムの制約、役割分担の矛盾、案件条件の見落としがあります。個人の注意力だけに原因を置くと、同じ問題が別案件で再発します。

試行後の聞き取りでは、「使いやすかったですか」とだけ尋ねません。「最初に止まったのはどこか」「何を見れば判断できると思ったか」「手順がなければ普段どうしたか」「記録を残さなかった箇所はどこか」と質問します。具体的な行動を聞くことで、遠慮による「問題ありません」を避けやすくなります。

所要時間を記録する場合は計測区間を固定します。工務店例027では、監督が確認依頼を開いてから判定を記録するまでとし、資料不足による待ち時間は別にします。合計時間だけでは、手順の読解に時間がかかったのか、入力資料が不足していたのかを区別できないからです。

AIを修正作業に使う場合は、観察記録をそのまま要約させて終わらせません。「S-04では二人とも版の識別方法を質問した」「T-03では差戻し後の再開箇所が分からなかった」のように事実を入力し、修正文案と確認質問を作らせます。採用判断は、根拠資料と業務責任者の決定に戻します。

10.公開判定は実案件三経路と模擬三経路を分けて行う

試行が終わると、「概ね使えたから公開しよう」という判断が起こりやすくなります。しかし、一つでも重大な未解決事項があれば、その工程は正式公開できません。公開判定では、軽微な表現修正と、業務結果を変える欠陥を分けます。

工務店例027では、次の条件をすべて満たしたときだけ正式版にします。

1. すべての手順に実行者、開始条件、操作、判断、記録先、完了条件がある 2. 業務上の事実と判断条件に根拠IDが付いている 3. 根拠のないAI補完が本文から除かれている 4. 不足、不一致、変更、実行不能について停止先と戻し先がある 5. 実案件を使ったT-01、T-02、T-04で、担当者が手順だけを見て期待する終了状態へ到達できる 6. 過去記録を編集した模擬条件によるT-03、T-05、T-06で、停止、連絡、記録、再開の経路を通過できる 7. 限定した実案件で、重大な新規欠陥が発生していない 8. 「重大」と「公開停止」の差分がゼロになっている 9. 正式版の保管場所、版番号、施行日、承認者が記録されている 10. 旧版を参照し続けないための切替方法が決まっている

T-03、T-05、T-06は模擬条件による初期検証です。正式公開後に版不一致、着工日変更、監督不在が実際に発生した場合は、その実記録で同じ経路を再確認します。模擬テストを実案件の実績として数えたり、実際の発生頻度を示す資料として使ったりしてはいけません。

軽微な誤字やレイアウトの問題は、意味と実行結果が変わらないことを確認したうえで、公開後の修正予定にできる場合があります。一方、担当者、承認条件、採用版、記録先、異常時の停止方法に未解決事項があるなら公開しません。文章全体を平均点で評価すると、重大な一箇所が他の整った箇所に埋もれるためです。

再試行の範囲は修正の影響で決めます。誤字修正なら全経路をやり直す必要はありません。判断条件を変更したなら、その条件を通る通常経路と例外経路を再実行します。担当者や記録先を変えた場合は、入口から出口までの引渡し全体へ影響するため、関連する経路を広く確認します。

承認記録には「AIを使って作成した」とだけ残すのではなく、どの資料を根拠にし、誰がどのテストを行い、実案件と模擬条件をどう区別し、何が未解決として残ったかを記載します。後日問題が起きたとき、使用したAIサービスの名称だけでは原因を追えません。

正式公開時には旧版の扱いも決めます。監査や変更経緯の確認に必要なら、閲覧専用の旧版保管場所へ移し、「使用禁止」「失効日」「後継版」を表示します。現場の通常検索で旧版が新しい版と並んで表示される状態なら、最新版を公開しただけでは切替完了とはいえません。

11.公開後は案件の異常を改訂要求へ変える

マニュアルは公開した時点で完成するのではなく、現場で使われた結果から維持します。ただし、気付くたびに本文を書き換えると、承認されていない手順が増えます。変更要求、緊急時の暫定対応、正式改訂を分ける必要があります。

変更要求を起こすきっかけには、次のようなものがあります。

• 同じ手順IDで迷いが複数回発生した
• 例外分類の「分類外」が続いた
• システムや様式の項目名が変わった
• 組織変更により担当役割が変わった
• 承認後の変更で再確認漏れが起きた
• 正式根拠と実際の運用が再び食い違った
• 参照先のリンク切れやアクセス権限不足が発生した
• 模擬条件でしか確認していなかった分岐が実案件で発生した

変更要求には改善案だけでなく、発生事実を残します。「分かりにくいので直したい」ではなく、「S-04で二案件連続して旧版図面を開いた」「参照先の名称が本文とシステムで異なる」と記録します。事実が明確なら、文章修正で済むのか、システム設定や役割分担の変更が必要かを判断できます。

小さな修正でも、意味が変わるなら再承認します。「設計担当」を「工務事務」へ変える修正は一語でも責任分担の変更です。「確認する」を「承認する」へ変える場合も権限の意味が変わり得ます。文字数ではなく、実行者、判断、記録、完了状態への影響で改訂区分を決めます。

AIは改訂時にも使えます。旧版、新しい根拠、変更要求を分けて入力し、「変更が必要な手順ID」「影響する分岐」「再試行すべき条件」の候補を抽出させます。ただし、差分がないとAIが判断した箇所も、人が根拠へ照合します。長い文章の比較を補助させることと、変更承認を委ねることは別です。

改訂履歴には、版番号、施行日、変更対象、変更理由、影響範囲、再試行した条件、承認者を残します。「表現を修正」のような記録では、後任者が変更の意図を判断できません。「S-04の版識別条件を、ファイル名から案件管理システムの版表示へ変更。模擬条件T-03と次の実案件で再試行済み」のように、手順と検証を結び付けます。

定期見直しを行う場合も、年一回と決めるだけでは不十分です。工務店例027では四半期ごとに差分記録を集計し、役割、システム、様式、利用権限が変更された場合にも見直しを起動します。変更が多い工程は見直し間隔を短くし、安定した工程は異常記録を監視する方法もあります。

12.工務店が最初の一冊を完成させる実行順序

最初から全社マニュアルをAIで作り直そうとすると、根拠整理と検証が追い付きません。まず一つの業務を選び、入口から出口まで検証する型を作ります。候補は、担当間の引渡しがあり、正式な記録先があり、通常経路と例外経路を確認できる業務です。

工務店例027の着工前引継ぎでは、次の順序で進めます。

1. 工務責任者が対象業務、入口、出口、対象外、承認者を決める 2. 現行規程、様式、システム項目、完了案件記録、担当者説明を集める 3. 人が資料をR1、R2、R3、R4、Uへ分類し、正式根拠へIDを付ける 4. 人が工程ごとの入力パックを作り、事実、差分、未確認事項を分離する 5. AIに実行者、入力、操作、判断、例外、記録、完了条件を構造化させる 6. AIの補助も使い、根拠のない文、矛盾を統合した文、一般知識から補完した文を抽出する 7. 人が各手順へ手順IDを付け、根拠照合と影響区分を確定する 8. 実案件でT-01、T-02、T-04を再現し、模擬条件でT-03、T-05、T-06を再現する 9. AIの文案整理も使い、不足、不一致、変更、実行不能の停止と復帰を修正する 10. 限定した実案件で試行し、迷い、質問、代用行動、停止行動を記録する 11. 重大・公開停止がゼロになったことを承認者が確認する 12. 版番号、施行日、改訂履歴を付け、旧版を使用場所から退避する

この順序のうち、AIが主に支援するのは5、6、9の文案整理です。4の入力パックは人が作成し、AIは根拠区分を変えない範囲で形式整理だけを補助します。1の範囲決定、3の根拠認定、7の影響判断、8と10の実行検証、11の承認は人が担います。

初回は、マニュアルのページ数や生成時間を成果指標にしない方が実態を捉えやすくなります。見るべきなのは、根拠へ戻れる手順の割合、未解決の重大事項、手順だけでは進めなかった箇所、例外から戻れなかった箇所です。ただし、数値を高く見せるために手順を大きな単位へまとめてはいけません。担当者の行動、判断、記録先が変わる単位で手順IDを付けます。

AIで下書きを速く作れても、現場検証の時間まで自動的に短くなるとは限りません。むしろ、これまで暗黙だった役割や判断条件が表面化し、責任者の決定が必要になることがあります。それは作成の失敗ではなく、業務上の未決事項を公開前に発見できた状態です。

目指すのは、誰が読んでも同じ文章に感心するマニュアルではありません。対象となる担当者が、同じ入口から始め、同じ根拠を見て、許された範囲で同じ判断をし、異常時には所定の順序で止まり、結果を同じ場所へ残せるマニュアルです。AIはその形へ整える補助として使い、正しさは根拠照合、実案件三経路、模擬三経路、限定した現場試行によって確定します。