規程を機能させる要点は、禁止事項を増やすことではなく、社員が「何を入力できるか」「何を根拠資料と照合するか」「誰の承認を得て公開するか」を案件ごとに判断できる状態をつくることです。本稿では、工務店がそのまま社内案に転記できるよう、入力区分、出力の修正例、確認記録、公開承認、事故対応、月次評価までを一つの運用として組み立てます。どの用途から使い始め、試行の結果で継続するかを決める手順は、工務店のAI導入方針の記事で扱います。
ハウスメーカーで公開承認を本部と支店で分ける場合
支店のSNSやチラシと本部のサイトで公開先が分かれる会社では、07章の承認レベルを公開先ごとに決め、支店長が承認できる範囲と本部へ上げる範囲を規程案に書きます。
09章の権限の分散は、承認者が不在の拠点にも代理者がいるかを拠点ごとに確かめます。
最初に決めるのは、生成AIを使う目的と適用範囲
生成AIの利用規程を作るとき、最初から入力禁止情報を列挙すると、規程が「禁止事項集」になりがちです。その前に、会社として何のために利用を認めるのかを一文で定めます。目的が定まれば、必要な入力、許容できる誤り、確認方法を用途ごとに設計できます。
例えば、社内規程の目的は次のように記載できます。
当社は、文章の整理、検討案の作成、社内知識の検索補助その他の承認された業務に生成AIを利用する。利用に当たっては、顧客、取引先、従業員および当社の情報を適切に管理し、生成物を人が確認し、契約、設計、施工、申請および対外発信に関する最終判断を生成AIに委ねない。
この目的文で重要なのは、「AIを使うこと」ではなく「承認された業務に使うこと」を主語にする点です。生成AIは用途によって影響が異なります。社内会議の論点整理と、顧客へ渡す見積説明文では、誤りが生じたときの影響も必要な確認水準も同じではありません。
経済産業省のAI事業者ガイドラインは、AIに関わる主体を開発者、提供者、利用者などに分け、それぞれの立場に応じた取組を示しています。工務店は多くの場合、外部の生成AIサービスを業務で使う「利用者」に当たります。ただし、以下の用途区分や承認手順は同ガイドラインの条文を転載したものではなく、工務店の実務に合わせた本記事独自の運用提案です。
まずは、想定用途を三つに分けます。
横にスワイプして、右側の列を確認できます
| 利用区分 | 工務店での用途例 | 原則 | 必要な確認 |
|---|---|---|---|
| 補助利用 | 誤字修正、会議論点の整理、一般的な言い換え | 承認済みサービスで利用可 | 入力情報と文章の意味を利用者が確認 |
| 原案利用 | ブログ草案、顧客説明文、採用原稿、手順書案 | 担当者確認後に責任者承認 | 根拠照合、表現修正、公開承認 |
| 高影響利用 | 見積判断、契約解釈、設計条件、施工指示、法令適合の判断 | AI単独での判断は禁止 | 有資格者・所管責任者が原資料から判断 |
| 対象外利用 | 私的な質問、会社が承認していない業務 | 会社業務として扱わない | 会社情報を入力しない |
この表から読み取るべきなのは、生成AIの使用を一律に許可または禁止するのではなく、出力が業務判断に与える影響で扱いを変えることです。高影響利用でも、論点を洗い出す補助として使える場合はありますが、AIの回答を根拠に最終判断してはいけません。
適用対象も明文化します。正社員だけでなく、役員、パート、派遣社員、業務委託先、インターンなど、会社の情報へ触れる人をどこまで含めるかを決めます。外部の制作会社へ顧客事例記事を依頼し、その制作会社が生成AIを使うなら、社内規程だけでは情報管理が途切れます。委託条件にも、入力禁止情報、再委託、事故報告、成果物確認を反映させる必要があります。
一方、経営全体のどの領域でAIを使うかという検討は、この規程とは分けます。営業、設計、施工、採用などの導入候補を整理したい場合は、基幹記事の工務店のAI活用機会マップで候補を洗い出し、本稿では候補ごとの利用条件を規程へ落とし込んでください。
利用サービスを会社承認制にする
情報管理は、入力内容だけでなく、どのサービスへ入力するかによって変わります。社員が各自の判断で無料サービスや個人アカウントを使える状態では、管理者が利用状況を把握できず、退職時の履歴管理や事故発生時の調査も困難になります。
そこで、業務利用は会社が承認したサービスとアカウントに限定します。「有名なサービスだから安全」「有料版だから問題ない」と名称だけで判断せず、利用時点の契約条件、データの取扱い、管理機能、保存設定などを確認し、確認日を残します。仕様や規約は変更される可能性があるため、導入時だけでなく定期的な再確認も必要です。
承認台帳には、少なくとも次の項目を記入します。
横にスワイプして、右側の列を確認できます
| 台帳項目 | 記入内容 | 判断できない場合 |
|---|---|---|
| サービス名・契約プラン | 正式名称と業務で使うプラン | 利用を開始しない |
| 契約主体 | 法人契約、部署契約など | 個人契約を業務利用しない |
| 管理責任者 | アカウント追加・停止を行う人 | 経営者または管理担当を指定 |
| 入力データの取扱い | 保存、学習利用、管理者設定の確認結果 | 提供元へ確認し、未確認なら機密情報を扱わない |
| 利用できる部署・用途 | 営業文章、社内要約など | 小さな用途に限定して試行 |
| 禁止用途 | 顧客原本の投入、契約判断など | 利用区分表と対応させる |
| 確認日・次回確認日 | 規約や設定を確認した日 | 半期など社内で周期を設定 |
| 停止方法 | アカウント停止、履歴確認、周知手段 | 導入前に管理者が試す |
この台帳は、サービスの安全性を会社が保証する書類ではありません。「会社が何を確認し、どの条件で利用を認めたか」を残す判断記録です。確認できない事項があれば、推測で「安全」と埋めず、入力できる情報と用途を狭めます。
利用開始までの順序は次のようにします。
- 利用申請
- 契約条件と設定の確認
- 用途・入力範囲の決定
- 管理者承認
- 対象者への教育
- 利用開始
この流れで重要なのは、アカウントを配ってからルールを考えないことです。用途と入力範囲を先に決めれば、教育内容も具体的になり、社員は「使ってよいが何も入れられない」という混乱を避けられます。
新しいサービスを試したい社員には、申請経路を用意します。申請書には、解決したい業務、入力予定の情報、出力の利用先、現在の代替手段、試行期間、確認担当者を記載させます。申請を面倒にしすぎると無断利用が起きやすいため、通常の補助利用なら一枚で判断できる分量にします。
試行では、実在顧客の情報を使わず、架空データまたは公開済み情報を使います。試行結果は「便利だった」という感想ではなく、誤りの種類、確認に要した作業、従来手順との違い、継続利用する条件を記録します。利用価値とリスクを同じ台帳上で見られる形が望ましいでしょう。
入力情報を四段階に分類する
社員に「機密情報を入力しないでください」と伝えても、何が機密情報なのかは部署や場面で解釈が分かれます。工務店では、顧客名を消しても、住所、敷地形状、家族構成、予算、間取り、写真などの組み合わせから案件を推測できる場合があります。名前だけを伏せればよいというルールでは足りません。
入力前に情報を四段階へ分類すると、判断をそろえやすくなります。次表は法的な分類を示すものではなく、生成AIへの入力可否を決めるための社内運用区分です。法令上の評価が必要な場合は、社内だけで断定せず、担当する専門家へ確認します。
横にスワイプして、右側の列を確認できます
| 社内区分 | 情報の例 | 原則的な扱い | 入力するための条件 |
|---|---|---|---|
| 公開情報 | 自社サイト掲載文、公開済みイベント情報、一般公開された商品説明 | 入力可 | 公開後に変更された情報がないか確認 |
| 社内一般 | 会議の一般議題、個人を含まない作業手順、公開前の一般原稿 | 承認済み環境で入力可 | 部署外秘や案件固有情報を除く |
| 要管理情報 | 顧客要望、未公開価格、原価、取引条件、社員評価、現場写真 | 原則入力しない | 用途、契約環境、必要性を責任者が個別承認 |
| 入力禁止情報 | 認証情報、秘密鍵、個人番号(マイナンバー)、本人確認書類の画像、病歴などの要配慮個人情報 | 入力禁止 | 例外を現場判断で設けない |
この表から分かるのは、「個人情報か否か」だけでは判断できないことです。未公開の原価表は顧客の個人情報ではありませんが、会社にとって重要な情報です。反対に、すでに会社が公開している文章でも、古い仕様や終了したキャンペーンが混ざっていれば、出力の根拠にはそのまま使えません。
本記事の四区分は「生成AIへ入力できるか」を判定するための区分です。データ管理の記事で示す社内分類とは、次のように対応させます。用途の優先順位や試行の評価はAI導入の記事で扱います。
横にスワイプして、右側の列を確認できます
| データ管理の区分 | 本記事での初期区分 | 判定時の注意 |
|---|---|---|
| 公開可 | 公開情報 | 承認済みの媒体・用途かを再確認する |
| 社内 | 社内一般 | 社外サービスへの入力は利用環境の承認が必要 |
| 限定 | 要管理情報 | 顧客・契約・原価などを個別判定する |
| どの区分にも含まれ得る禁止対象 | 入力禁止情報 | 個人番号、秘密鍵などはデータ管理上の区分より入力禁止を優先する |
個人情報保護委員会が2023年6月に公表した「生成AIサービスの利用に関する注意喚起等」も一次資料として参照し、個人データを扱う前に利用目的、サービス提供者による利用の有無、契約・設定を確認します。この表の「入力禁止」は本記事が提案する社内ルールであり、法令がすべての生成AIサービスへの入力を一律に禁じるという意味ではありません。
入力判断は、情報を一項目ずつではなく、組み合わせでも行います。例えば「市名」「敷地面積」「着工月」「家族構成」「特徴的な要望」を同時に入力すれば、地域の関係者には案件が推測される可能性があります。このため、匿名化は氏名の削除だけで完了したとみなしません。
実務では、次の五問を入力画面の近くに掲示します。
1. この情報はすでに会社が公開しているか。 2. 顧客、取引先、従業員または特定案件を識別できないか。 3. 原価、見積、設計、施工、契約に関する未公開情報を含まないか。 4. この情報を入力しなければ業務目的を達成できないか。 5. 誤送信したと仮定して、直ちに管理者へ報告できる内容か。
五問のうち一つでも判断できなければ、入力を止めて責任者へ確認します。「忙しいので後で確認する」は認めず、入力前に分岐させることが重要です。送信後に元へ戻しても、入力という事実まで取り消せるとは限りません。
入力内容を減らす方法には、削除、置換、要約、分割があります。氏名や住所は削除し、固有名詞は「施主A」「協力会社B」に置換します。家族の詳細は、文章作成に必要な「子育て世帯」程度へ要約します。原価表全体を入力せず、文章表現の確認に必要な一項目だけを分割して入力します。
ただし、加工すれば必ず入力できるわけではありません。案件の特異性が高いと、固有名詞を消しても推測可能性が残ります。また、入力を細かく分けても、同じ会話履歴に蓄積すれば全体像が再構成されることがあります。加工後の情報を改めて四段階へ分類し、目的に対して過剰な情報が残っていないかを見直します。
工務店の業務別に入力可否を判断する
規程を現場で使えるものにするには、「顧客情報は禁止」という抽象表現から、日常業務の入力例へ落とす必要があります。営業、設計、工務、広報、経営管理では、扱う情報も出力の使い道も異なるからです。
以下は社内教育で使える判断例です。実在案件を基にしたものではありません。
横にスワイプして、右側の列を確認できます
| 業務場面 | 入力しようとしている内容 | 判断 | 修正方法 |
|---|---|---|---|
| 営業メール | 顧客名、相談内容、次回打合せ日時 | そのまま入力しない | 氏名と日時を除き、一般的な案内文だけ作る |
| ヒアリング整理 | 家族構成、資金状況、健康上の事情、土地情報 | 入力しない | 社内様式で人が整理し、AIには見出し構成だけ尋ねる |
| 見積説明 | 実際の数量、単価、値引き条件、協力会社名 | 個別承認なしでは入力しない | 架空数値で説明文の型を作り、実値は人が記入 |
| 設計検討 | 顧客の間取り図、住所、敷地条件 | 高影響かつ案件情報を含む | 承認された設計手順を優先し、一般論の論点整理に限定 |
| 現場報告 | 現場写真、事故情報、施主名、位置情報 | そのまま入力しない | 既存の報告経路を使い、AI利用は管理者判断 |
| 広報原稿 | すでに公開済みの会社情報 | 入力可 | 最新情報との一致と転載権限を確認 |
| 採用原稿 | 募集要項と会社が公開した理念 | 入力可 | 労働条件を原資料と照合し、責任者が公開承認 |
| 会議整理 | 個人名を除いた一般的な論点 | 条件付きで入力可 | 人事評価、顧客案件、未公表数値を除く |
この表から読み取るべき点は、同じ文章作成でも、入力素材と公開先によって判断が変わることです。営業メールの敬語を整える作業自体は低影響でも、顧客の相談内容を全文貼り付ければ情報管理上の負担が増します。
入力可否を迷いやすいのが、メールや議事録の要約です。長文をそのまま投入できるため便利に見えますが、元データには、本人が生成AIへ入力されることを想定していない記述、署名欄、電話番号、別案件の引用、添付ファイル名などが含まれます。要約したい部分だけを抽出し、不要情報を除いたうえで扱います。
図面や写真にも注意が必要です。画像内には、住所表示、車両番号、顔、表札、近隣住宅、端末の通知、撮影位置に関する情報などが映り込むことがあります。画像を入力できるサービスであっても、「機能があること」と「業務入力を認めること」は別です。画像入力は文章入力とは別の申請区分にしてもよいでしょう。
架空例として、「穂高工務店」という従業員18人の地域工務店が、完成見学会後のお礼メールを作る場面を考えます。穂高工務店は本記事だけで使う架空の会社であり、以下の人数、体制、案件は説明のために固定した条件です。実在企業の成果や運用実績ではありません。
担当者が「○○様、9月20日の見学会で、○○市の土地と二世帯住宅の資金計画について相談。親世帯の健康上の事情もあり、寝室は……」と全文入力するのは不適切です。目的はお礼メールの構成作成であり、相談の詳細は不要だからです。
入力は次のように減らせます。
地域工務店の完成見学会へ来場した顧客に送るお礼メールの原案を作成してください。次回は土地探しと二世帯住宅の進め方を説明する予定です。断定的な営業表現を避け、日程と担当者名は空欄にしてください。
この入力でも、出力をそのまま送信しません。担当者は顧客台帳を見ながら宛名、相談内容、約束した資料、次回日程を追記し、営業責任者が内容を確認します。生成AIには文章の型だけを作らせ、案件固有情報は管理された顧客対応手順の中で人が記入する設計です。
出力は「正しいか」ではなく項目別に確認する
生成AIの文章は、読みやすく整っているほど誤りを見逃しやすくなります。そのため、「一読して問題がなければ使用可」という確認方法は採用しません。事実、数値、条件、権利、表現、抜け漏れを分けて確認します。
IPAサイト掲載のテキスト生成AIの導入・運用ガイドラインは、中核人材育成プログラムの卒業プロジェクトによる資料で、IPAや同センターの公式見解を代表しません。組織のセキュリティ担当者向けにリスクマトリクスを用いた管理を説明していますが、特定サービスの品質や時短効果を保証する資料ではありません。本稿ではその考え方を参考にしつつ、工務店の出力確認を次の評価表へ具体化します。
横にスワイプして、右側の列を確認できます
| 確認項目 | 照合する原資料 | 不一致があった場合 | 確認者 |
|---|---|---|---|
| 固有名詞 | 顧客台帳、会社案内、商品資料 | AI文を修正し、類似箇所も検索 | 作成担当者 |
| 日付・時間 | 予約表、工程表、正式な案内 | 原資料を正として修正 | 作成担当者 |
| 金額・数量 | 承認済み見積、積算資料、契約書 | 公開・送信を停止して所管確認 | 営業・積算責任者 |
| 仕様・性能表現 | 承認済み仕様書、提供元資料 | 根拠のない表現を削除 | 設計・商品責任者 |
| 法令・制度の説明 | 行政等の一次資料、専門家確認 | AI回答だけで断定しない | 所管責任者 |
| 契約上の約束 | 契約書、打合せ記録、承認履歴 | 新しい約束を文章に追加しない | 営業責任者 |
| 写真・文章の権利 | 自社の許諾記録、利用条件 | 確認できなければ使用しない | 広報責任者 |
| 読者への誤解 | 前提条件、対象外条件、例外 | 条件を追記し、断定を弱める | 公開承認者 |
この表で大切なのは、「AIが合っているか」をAI自身に再質問して終わらせないことです。照合先は、顧客台帳、契約書、承認済み見積、仕様書、行政等の一次資料など、会社が正式な根拠として扱うものにします。
確認の順序も固定すると、見落としが減ります。
- 出力を保存
- 用途外の記述を削除
- 固有名詞・数値を原資料と照合
- 条件・例外を補う
- 所管責任者が承認
- 送信・公開
この模式図から分かるのは、文章を整える作業と、根拠を確認する作業を分ける必要があることです。先に美しい文章へ仕上げると、後から誤りが見つかったときに修正範囲が広がります。まず不要部分を削り、事実を照合してから表現を整えます。
確認担当者は、文章力が高い人ではなく、その内容を業務上判断できる人にします。構造計算、法令適合、補助制度、税務、契約解釈などを含む場合、広報担当者が表現だけを確認しても足りません。所管者が判断できない領域は、通常業務と同じく外部専門家や行政等へ確認し、生成AIを確認先にしないことが原則です。
また、「AIがそう回答した」という記録は根拠資料になりません。AI出力は確認対象であり、確認の証拠ではないからです。何を根拠に採用・修正したかを、確認記録へ残します。
修正前後を残して、文章品質を再現する
生成AIの出力を人が修正したとしても、修正理由が共有されなければ、別の担当者が同じ誤りを繰り返します。修正前後を短く記録し、「何が危険だったか」「どの原資料で直したか」を社内の判断材料にします。
穂高工務店が、完成見学会の告知文を作成した架空例を続けます。AIが次の原案を出したとします。
穂高工務店の住宅は、夏も冬も必ず快適で、光熱費を大幅に削減できます。最新の補助金も利用できるため、お得に高性能住宅を建てられます。9月30日までにお申し込みください。
読みやすい文章ですが、確認すべき問題が複数あります。「必ず快適」は個別条件を無視した保証的な表現です。「大幅に削減」は比較条件と根拠がありません。「最新の補助金」は制度名、対象条件、申請時期が不明です。「9月30日まで」が正式な申込期限かも確認できません。
修正記録は次のように残します。
横にスワイプして、右側の列を確認できます
| 修正対象 | 修正前 | 修正後 | 修正理由・根拠 |
|---|---|---|---|
| 快適性 | 夏も冬も必ず快適 | 断熱計画や空調計画について、会場で考え方をご説明します | 個別条件によるため保証表現を削除 |
| 光熱費 | 大幅に削減できます | 削除 | 比較対象、試算条件、根拠資料がない |
| 補助制度 | 最新の補助金も利用できる | 利用可能性のある制度は、対象条件と申請時期を個別に確認します | 一律に利用できるとは限らない |
| 期限 | 9月30日までにお申し込みください | 見学予約は各開催日の前日まで受け付けます | 社内の正式な予約要項と照合 |
| 対象者 | 記載なし | 家づくりを検討中の方を対象とした予約制見学会です | 対象と参加方法を明示 |
この表からは、生成文を「少し柔らかくする」だけでは品質確認にならないことが分かります。根拠のない効果を削除し、制度の条件を補い、正式な運用へ合わせる必要があります。
修正後の告知文は、例えば次のようになります。
穂高工務店では、家づくりを検討中の方を対象に、予約制の完成見学会を開催します。会場では、断熱計画や空調計画について、今回の住宅で採用した考え方をご説明します。利用可能性のある支援制度については、対象条件や申請時期が異なるため、個別相談時に確認します。見学予約は各開催日の前日まで受け付けます。
この文章でも、実際に公開する際は、開催場所、日時、予約方法、見学時の注意事項を正式な企画書と照合します。架空例は文章の安全性を保証するひな型ではなく、修正の考え方を示すものです。
修正履歴には全文を毎回保存する必要はありません。問題になった部分、修正後、根拠、再発防止の指示を残せば、教育材料になります。頻出する修正が見つかったら、プロンプトだけで対処せず、入力様式や確認表も更新します。
例えば、毎回「補助金が使える」と断定する出力が生じるなら、プロンプトに注意書きを加えるだけでは不十分です。補助制度を含む文章は所管責任者の承認対象とし、制度名、対象、基準日、確認元を記入しなければ公開できない様式に変えます。個人の注意力を、工程上の必須項目へ置き換えるわけです。
公開先に応じて承認レベルを変える
生成AI出力の確認水準は、公開範囲で変えます。自分だけが見るメモと、全顧客へ送るメール、契約前の説明資料、採用ページでは、誤りが生じたときの影響が異なります。
公開範囲は、少なくとも「本人限定」「部署内」「社内全体」「特定顧客・取引先」「一般公開」に分けます。一般公開だけを対外発信と考えず、顧客一人へのメールも社外利用として扱います。
横にスワイプして、右側の列を確認できます
| 公開レベル | 例 | 最低限の承認 | 記録 |
|---|---|---|---|
| 本人限定 | 論点メモ、文章の言い換え候補 | 利用者本人が確認 | 高影響情報を扱わない限り簡易記録 |
| 部署内 | 会議たたき台、一般的な業務手順案 | 作成者と業務責任者 | 更新日と確認者 |
| 社内全体 | 社内通知、教育資料 | 所管責任者 | 原資料、修正履歴、承認日 |
| 特定顧客・取引先 | メール、提案説明、案内文 | 案件担当者と責任者 | 送信版、宛先、承認者 |
| 一般公開 | Web記事、SNS、広告、採用ページ | 所管責任者と公開管理者 | 公開版、根拠、公開日、訂正履歴 |
| 高影響文書 | 見積、契約、設計・施工指示、申請関係 | 既存の正式な決裁者 | AI利用の有無にかかわらず正式記録 |
ここで読み取るべきなのは、生成AIを使った文書だけ別系統にしないことです。顧客メールなら既存の顧客対応責任者、設計情報なら設計責任者、採用情報なら採用責任者というように、元の業務責任へ接続します。
公開承認では、生成AIを使ったかどうかだけでなく、公開版が承認版と同じかを確認します。承認後に担当者が日付や数値を変更した場合、その変更部分は再承認の対象です。CMSやSNSへ転記するときの誤りもあるため、公開画面で最終表示を確認します。
承認記録は、次の七項目があれば実務で追跡しやすくなります。
- 文書名または案件名
- 利用目的
- 使用した承認済みサービス
- 入力情報の社内区分
- 照合した原資料
- 修正者と承認者
- 公開日、送信日または利用日
AIとの全会話を無条件に保存する運用は、会話内に不要情報を残す可能性もあります。何をどの期間保存するかは、会社の文書管理方針、契約条件、サービス設定と合わせて決めます。少なくとも対外発信では、承認された最終版と根拠資料を追跡できる状態にします。
急ぎの投稿でも承認を省略しません。承認者が不在なら、代理承認者を事前に決めるか、公開を延期します。イベント中止や災害時の案内など緊急性が高い情報は、通常の広報原稿とは別に、緊急連絡の既存手順を優先します。
SNSでは、本文だけでなく、画像内文字、ハッシュタグ、代替テキスト、リンク先、コメント返信まで公開物に含めます。AIが作った投稿文に問題がなくても、添付写真に表札や近隣住宅が映っていれば別の問題が残ります。文章確認と素材確認を一枚の公開票で行うと、担当の分断を防げます。
規程違反や誤出力を発見したときの手順
規程は、違反を完全になくすためだけでなく、問題が起きたときに被害の拡大を止めるためにあります。「違反者を処分する」とだけ書くと、社員が報告をためらい、初動が遅れるおそれがあります。まず報告と停止を優先し、原因確認と人事上の判断を分けます。
報告対象には、少なくとも次を含めます。
- 入力禁止情報または未承認情報を送信した
- 未承認サービスや個人アカウントを業務利用した
- AI出力の誤りを含む文書を顧客へ送った
- 承認前の原稿をWebやSNSへ公開した
- 根拠のない金額、仕様、制度、期限を案内した
- 第三者の文章や画像に関する疑義が生じた
- アカウントの不審な利用や共有を発見した
発見後の順序を固定します。
- 利用・公開を停止
- 管理責任者へ報告
- 入力・出力・公開範囲を保全
- 影響範囲を確認
- 訂正・連絡を判断
- 原因分析
- 規程と教育を更新
この順序から読み取れるのは、担当者が自己判断で履歴を消したり、訂正文をすぐ送ったりしないことです。状況確認に必要な記録まで消すと、何が入力され、誰に公開されたかを追えなくなります。訂正連絡も、事実関係と対象範囲を確認してから責任者が判断します。
初動報告票には、発見日時、報告者、使用サービス、アカウント区分、入力した情報、生成された内容、利用先、閲覧可能だった範囲、現在の公開状態、実施済みの停止措置を記入します。分からない項目は「不明」とし、推測で埋めません。
横にスワイプして、右側の列を確認できます
| 初動項目 | 記入例 | 注意点 |
|---|---|---|
| 発見日時 | 2026年9月25日 10時20分 | 入力日時と発見日時を分ける |
| 発生行為 | 顧客メールを未承認サービスで要約 | 事実だけを記載する |
| 入力情報 | 氏名、メール本文、相談内容 | 「個人情報」だけで済ませない |
| 出力の利用先 | 営業担当者のみ閲覧 | 転送・共有・公開の有無を確認 |
| 現在の状態 | 利用停止、管理者へ連絡済み | 削除操作は管理者判断に従う |
| 不明事項 | サービス側の保存状態 | 不明を安全と解釈しない |
| 次の判断者 | 情報管理責任者 | 連絡先と代理者を平時に決める |
この表は、責任追及のためではなく、初動で必要な情報を欠かさないために使います。報告者の推測や弁明を長く書かせるより、対象情報と公開範囲を早く特定する方が先です。
顧客や取引先への連絡、外部機関への相談、法令上の対応が必要かどうかは、事案ごとに判断します。生成AIに事故対応の要否を決めさせず、社内責任者が契約、既存の危機管理手順、必要に応じた専門家の助言に基づいて判断します。
原因分析では、「担当者が不注意だった」で終わらせません。申請経路が分かりにくかった、承認サービスが業務に合っていなかった、納期設定が無理だった、入力例がなかった、代理承認者が不在だったなど、工程上の原因を探します。
再発防止は原因に対応させます。入力判断が難しかったなら具体例を追加し、未承認サービスを使ったなら申請と調達を見直し、確認漏れなら公開画面に承認番号を必須化します。教育を一回追加するだけでは、同じ状況が再現されたときの抑止にならない場合があります。
権限と責任を一人に集中させない
小規模な工務店では、経営者がサービス選定、アカウント管理、原稿承認、事故対応をすべて抱えがちです。しかし、承認待ちが増えると、現場は規程を迂回するようになります。人数が少なくても、役割を分けて代理者を決めることが重要です。
最低限、経営責任者、AI利用管理者、業務責任者、利用者、公開管理者の役割を定義します。同じ人が複数役を兼ねても構いませんが、一つの対外原稿について作成者と最終承認者を同一にしないなど、重要な場面では相互確認を設けます。
横にスワイプして、右側の列を確認できます
| 役割 | 主な責任 | 兼務時の制約 |
|---|---|---|
| 経営責任者 | 利用方針、許容範囲、重大事案の判断 | 自ら作成した高影響文書は別の所管者が確認 |
| AI利用管理者 | サービス台帳、アカウント、規程更新、教育 | 業務内容の正しさまで単独承認しない |
| 業務責任者 | 営業・設計・工務・広報等の内容確認 | 判断できない専門領域は外部確認 |
| 利用者 | 入力前判断、出力確認、利用記録、問題報告 | 承認権限を自己判断で拡張しない |
| 公開管理者 | 承認済み版の掲載、公開後確認、訂正対応 | 内容変更をしたら再承認へ戻す |
| 代理者 | 不在時の承認・初動 | 代理できる範囲を事前に指定 |
この表で確認したいのは、AI利用管理者がすべての内容に詳しい必要はないことです。管理者は利用環境と記録を管理し、業務内容は営業、設計、工務などの責任者が確認します。
穂高工務店の架空例では、代表取締役を経営責任者、総務主任をAI利用管理者、営業部長を顧客向け文章の業務責任者、広報担当者を公開管理者とします。広報担当者が原稿を作った場合、営業内容は営業部長、会社方針は代表、公開操作は広報担当者が担います。
ただし、すべてのSNS投稿を代表が確認する設計では滞留します。公開済み情報だけを使う定型投稿は営業部長の承認でよい、価格、性能、保証、制度、顧客事例を含む投稿は代表または所管責任者の追加承認が必要、と条件を分けます。
承認期限も決めます。通常原稿は二営業日前、緊急連絡は代理承認者へ即時連絡など、業務の速度に合わせます。規程が実際の締切を無視していると、現場は「守れない規程」と判断します。
生成AIの導入目的が経営計画と結び付いていない場合、利用件数だけが目標になりやすくなります。活用テーマを売上、粗利、人員、業務負荷とどう結び付けるかは、工務店の経営計画の立て方も参照し、利用規程とは別の経営判断として整理してください。
教育は操作方法より判断演習を中心にする
生成AI研修というと、質問文の書き方や便利な機能の紹介に偏りがちです。しかし、利用規程を守るために必要なのは、入力直前に情報を分類し、出力後に原資料を照合し、公開前に承認へ回す判断です。
初回教育では、規程を読み上げるだけでなく、工務店の実務例を使います。「顧客名を消した相談記録」「現場写真」「公開済みの会社紹介」「未公開の標準原価」「補助制度を含むブログ案」などを提示し、入力可否と修正方法を各自に判断させます。
教育の標準構成は、次の五つで十分です。
1. 会社が利用を認める目的と対象業務 2. 承認済みサービスとアカウントの使い方 3. 四段階の入力情報分類 4. 原資料による出力確認と公開承認 5. 誤入力、誤公開、アカウント異常の報告方法
研修後の確認テストは、用語の暗記ではなく分岐問題にします。例えば「顧客名をA様に置換したが、住所、家族構成、予算、着工予定月が残っている。入力できるか」と問い、理由と修正案まで記入させます。
模範回答は、「氏名の置換だけでは案件を推測できる情報が残るため、そのまま入力しない。文章作成に必要な一般条件だけへ要約し、住所、予算、時期、家族の詳細を除く。なお、用途が顧客対応なら責任者の承認経路も確認する」となります。
別の問題として、「AIが作った採用原稿に、年間休日数と手当額が記載された。社内の募集要項と数値が一致しているので公開してよいか」と問います。一致だけでは足りません。募集要項が最新版か、公開権限があるか、他の労働条件と矛盾しないか、承認者が確認したかを確かめます。
教育履歴には、受講日、対象規程の版、演習結果、再教育の要否を残します。規程を改定したら、全員に同じ研修を繰り返すのではなく、変更箇所と影響する業務を中心に追加教育します。
新入社員や業務委託先には、アカウント付与前の教育を必須にします。退職、契約終了、異動時には、アカウント停止と共有先の見直しを行います。利用開始だけでなく、利用終了も管理工程に含める必要があります。
相談窓口では、質問した人が不利益を受けるような運用を避けます。「この情報を入れてよいか」と事前に尋ねた社員を責めると、次から無断利用が増えます。一方、明確な禁止事項を故意に繰り返す場合などの人事上の扱いは、就業規則や既存の手続に沿って別途判断します。
月次評価では利用件数より危険な工程を探す
規程の運用状況を測るとき、「月に何回使ったか」だけを集計しても、安全性や品質は分かりません。利用回数が増えること自体を成功指標にすると、本来使う必要のない業務までAI利用が広がるおそれがあります。
評価するのは、承認外利用、入力判断の相談、出力修正、差戻し、公開後訂正、事故報告など、工程の状態です。件数だけで良否を決めず、母数と内容を併記します。
横にスワイプして、右側の列を確認できます
| 評価項目 | 算出・記録方法 | 読み方 |
|---|---|---|
| 承認済み利用数 | 月間の利用記録件数 | 単独では成果とみなさない |
| 入力前相談率 | 入力前相談件数 ÷ 利用記録件数 × 100 | 高いことを直ちに悪いとしない。規程が曖昧な可能性を確認 |
| 差戻し率 | 承認者の差戻し件数 ÷ 対外利用申請件数 × 100 | 差戻し理由を分類し、様式改善に使う |
| 根拠不明の発見数 | 原資料を示せず削除・修正した箇所数 | 頻出分野を高影響用途として見直す |
| 公開後訂正率 | 公開後訂正件数 ÷ AI利用を含む公開件数 × 100 | 訂正内容と影響範囲を併記 |
| 未承認利用件数 | 発見した未承認サービス・アカウント利用 | ゼロ報告が未発見を意味しない点に注意 |
| 教育完了率 | 期限内受講者数 ÷ 受講対象者数 × 100 | 異動者・委託先を分母に含める |
| 確認作業時間 | 対象文書の確認に要した時間 | 作成時間だけで効果を判断しない |
この表から読み取るべきなのは、数値の上下だけで結論を出さないことです。入力前相談が増えたのは、規程が分かりにくい可能性もあれば、社員が早めに相談できる文化になった可能性もあります。相談内容を分類して初めて、規程改定の必要性が分かります。
架空の穂高工務店で、ある月の対外利用申請が20件、そのうち差戻しが5件なら、差戻し率は「5件 ÷ 20件 × 100=25%」です。ここで25%を他社水準と比較するのではなく、5件の理由を見ます。
仮に5件の内訳が、日付の不一致2件、根拠のない性能表現2件、承認前画像の使用1件だったとします。この数字は架空の計算例であり、実在の成果値ではありません。日付は申請様式へ原資料欄を追加し、性能表現は商品責任者の確認対象にし、画像は許諾記録とひも付ける、と原因別に修正します。
月次会議で見る資料は、一枚に絞れます。上段に利用区分別の件数、中段に差戻しと問題報告、下段に翌月の変更点を記載します。個々のプロンプトを大量に共有するより、会社として変更する判断基準を明確にします。
四半期または半期には、承認サービス台帳を再確認します。利用されていないアカウント、退職者の権限、契約条件、管理者設定、保存方針、連携機能、追加された用途を確認します。新機能が自動的に業務利用可能になったとはみなしません。
利用価値も、作成時間だけで評価しないことが重要です。「下書きが20分短縮されたが、確認に30分増えた」なら、全体では時間が増えています。さらに、修正難度、差戻し、公開後対応まで含めて判断します。
一方で、時間が短くならなくても、論点漏れが減った、文章の型が統一された、若手が確認事項を学べたなどの価値はあり得ます。その場合も感想だけで結論を出さず、どの工程で何が変わったかを記録します。
そのまま社内案にできる利用規程と導入手順
ここまでの判断を、規程本文へまとめます。以下は工務店向けのたたき台であり、法的適合性を保証するひな型ではありません。自社の契約、就業規則、情報管理規程、文書保存ルール、利用サービスの条件と照合し、必要に応じて専門家へ確認してください。
生成AI利用規程案
第1条 目的 当社は、承認された業務における文章整理、検討案作成その他の補助を目的として生成AIを利用する。利用者は、顧客、取引先、従業員および当社の情報を適切に扱い、生成AIの出力を人による確認なしに業務判断または対外発信へ使用してはならない。
第2条 適用対象 本規程は、役員、従業員、派遣社員、業務委託先その他当社の業務として生成AIを利用する者に適用する。業務委託先への適用範囲は、委託内容と契約条件に応じて明示する。
第3条 承認済みサービス 業務利用できる生成AIは、会社が承認し、サービス台帳へ登録したものに限る。利用者は、個人アカウント、未承認サービスまたは承認されていない外部連携を業務に使用してはならない。
第4条 利用申請 新しいサービスまたは新しい用途を希望する者は、利用目的、入力予定情報、出力の利用先、確認担当者および試行期間を管理者へ申請する。承認前の試行では、実在する顧客、取引先、従業員または案件に関する情報を使用しない。
第5条 入力情報の分類 入力情報は、公開情報、社内一般情報、要管理情報、入力禁止情報に分類する。分類できない情報は入力せず、業務責任者またはAI利用管理者へ確認する。
第6条 入力禁止 利用者は、認証情報、秘密鍵、個人番号、要配慮個人情報、本人確認書類の画像その他会社が入力禁止と定める情報を生成AIへ入力してはならない。顧客名等を削除した場合でも、他の情報との組み合わせによって個人または案件を推測できるときは入力しない。
第7条 必要最小限の入力 利用者は、業務目的に必要な範囲を超えて情報を入力してはならない。削除、置換、要約または分割によって目的を達成できる場合は、入力内容を減らす。
第8条 高影響用途 契約、見積、設計、施工、法令適合、申請、保証、採用条件その他会社が高影響と定める事項について、生成AIの出力だけを根拠として最終判断してはならない。所管責任者は、正式な原資料および既存の承認手続に基づいて判断する。
第9条 出力確認 利用者は、生成AIの出力に含まれる固有名詞、日付、金額、数量、仕様、制度、契約条件、権利関係その他の事実を原資料と照合する。生成AIへの再質問のみを確認の根拠としてはならない。
第10条 対外利用 顧客、取引先または一般向けに出力を利用するときは、用途に応じた業務責任者の承認を得る。公開管理者は、承認済みの最終版と実際の送信・公開内容が一致することを確認する。
第11条 記録 対外利用または会社が指定する用途では、文書名、利用目的、使用サービス、入力情報区分、照合した原資料、修正者、承認者および利用日を記録する。保存期間と保存場所は、会社の文書管理方針に従う。
第12条 問題発生時の報告 誤入力、未承認利用、誤出力の公開、アカウント異常その他の問題を発見した者は、利用または公開を停止し、社内手順書に定めた期限と連絡先に従って管理責任者へ報告する。報告期限は「発見から1時間以内」のように具体的に定め、業務時間外の代替連絡先も記載する。報告者は、管理者の指示なく必要な記録を削除しない。
第13条 アカウント管理 AI利用管理者は、アカウントの付与、変更、停止および定期確認を行う。異動、退職、委託終了その他利用資格が変わった場合は、必要な権限変更を行う。
第14条 教育 会社は、利用開始前および規程の重要な変更時に、対象者へ教育を行う。教育には、入力情報の分類、出力確認、公開承認および問題報告の演習を含める。
第15条 定期見直し 経営責任者およびAI利用管理者は、利用状況、差戻し、問題報告、サービス条件の変更および業務上の必要性を確認し、本規程、台帳、入力例および確認票を見直す。
規程本文だけでは、現場は動けません。規程と同時に、次の四点を配布します。
- 承認サービス台帳
- 入力前五問チェック
- 出力確認・公開承認票
- 問題発生時の初動報告票
出力確認・公開承認票は、次の一枚にまとめられます。
横にスワイプして、右側の列を確認できます
| 記入欄 | 記入内容 |
|---|---|
| 文書・案件名 | 公開物を識別できる名称 |
| 利用目的 | 要約、原案作成、言い換えなど |
| サービス | 台帳上の正式名称 |
| 入力区分 | 公開、社内一般、要管理の別 |
| 入力時の加工 | 削除、置換、要約、分割の内容 |
| 原資料 | 顧客台帳、正式見積、仕様書、公開資料など |
| 要修正箇所 | 数値、断定、条件不足、権利など |
| 作成者 | 氏名と確認日 |
| 業務責任者 | 氏名、承認・差戻し、日付 |
| 公開管理者 | 掲載先、公開日、最終表示確認 |
| 公開後の変更 | 変更箇所、再承認者、変更日 |
この票から読み取れるのは、プロンプトの上手さではなく、入力、根拠照合、修正、承認、公開後変更を一続きで管理することです。欄が埋まらない場合は、その工程が未完了だと判断できます。
導入は一度に全社へ広げず、一つの低影響用途から始めます。例えば、公開済み情報を使った社内向け文章の整形を対象にし、二週間から一か月程度の試行期間を置きます。期間の長さは業務量に合わせて決め、十分な利用記録が集まらなければ延長します。
最終的な導入順序は次の通りです。
- 対象業務を一つ選ぶ
- 情報区分と承認者を決める
- 台帳・確認票を用意する
- 架空データで演習する
- 限定運用する
- 差戻し理由を集計する
- 規程を修正する
- 対象業務を追加する
この流れの要点は、規程を完成品として配布しないことです。限定運用で発生した判断の迷いを入力例、確認欄、承認条件へ反映し、次の用途を追加します。
最初の一か月で経営者が確認する成果物は、利用回数のグラフではありません。「承認サービス台帳」「業務別の入力可否表」「出力確認・公開承認票」「初動報告票」の四点が実際に記入され、社員が迷った事例を翌版へ反映できたかです。
生成AI利用規程の完成とは、立派な禁止条文ができることではありません。顧客情報を入力する前に止まれること、もっともらしい誤出力を原資料で直せること、承認版だけを公開できること、問題発生時に隠さず報告できることです。この四つが同じ工程で動けば、工務店は生成AIを過信せず、必要な範囲で業務へ組み込めます。
参考にした公式資料
- AI事業者ガイドライン確認日:
- テキスト生成AIの導入・運用ガイドライン確認日:
記入例・計算例は編集上の例です。制度の受付状況や仕様は変わるため、実行前にリンク先の最新情報をご確認ください。