AI Governance for Small Teams：中小企業向けスケーラブルなAIガバナンス

AIガバナンスとは、組織が AI システムを安全・公正・透明に運用するための方針・プロセス・統制の総体です。生成 AI ツールの普及により、中小企業やスモールチームでも業務自動化や意思決定支援に AI を活用する機会が急速に広がっています。

しかし、専任の AI 担当者やコンプライアンス部門を持たない組織では、シャドー AI の横行やデータ漏洩リスク、規制違反といった問題が顕在化しやすい傾向があります。EU AI Act（EU 人工知能規則）や PDPA（タイ個人情報保護法）など、AI に関連する規制への対応は、大企業だけの課題ではありません。

本記事では、リソースが限られた中小企業・スモールチームを対象に、最低限のガバナンス体制を構築するための軽量チェックリストと実装手順を解説します。

結論: リソースが限られる中小企業こそ、シャドーAIや規制違反による打撃が致命的になりやすく、早期のガバナンス整備が不可欠です。

AIの業務活用が広がる一方、中小企業では野放しの利用が内部統制の空白を生みやすいです。規制対応・リスク管理・信頼維持の観点から、最低限の体制づくりが求められます。

「承認されていないツールなんて使っていない」と最初は思いがちですが、実際には現場の担当者が業務効率化のために無断で生成AIサービスを使い始めるケースが多くの組織で報告されています。これがシャドーAI（Shadow AI）と呼ばれる現象です。

シャドーAIが危険な理由は、組織が把握できないところでデータが外部に送信されることにあります。主なリスクは以下の通りです。

• 機密情報漏洩: 顧客データや社内ノウハウを含むプロンプトが、利用規約次第でモデルの学習に使われる可能性があります
• コンプライアンス違反: 個人情報を含むデータを無断で外部サービスに送ると、PDPA（タイ個人情報保護法）や個人情報保護法に抵触するリスクがあります
• 品質・信頼性の低下: ガードレールのないツールが不正確な出力（ハルシネーション）を業務に混入させ、意思決定の質を損ないます

中小企業では「専任のIT担当がいないから管理が難しい」と感じることも多いです。しかし内部統制の第一歩は、複雑なシステム構築ではなく、どのAIツールを誰がどの目的で使ってよいかを明文化したAI利用規程の整備です。

最低限、以下の3点を規程に含めることで、シャドーAIの温床を断ち切ることができます。

• 承認済みツールのホワイトリストと禁止ツールの明示
• 入力してはならないデータ種別（個人情報・営業秘密等）の定義
• 違反時の報告ルートと対応フローの明確化

シャドーAIは「禁止すれば解決」ではなく、使いやすい公式手段を提供することで自然と減少する傾向があります。

規制対応は「大企業だけの問題」と思われがちですが、中小企業もすでに規制の射程に入っています。

EU AI Act（Regulation (EU) 2024/1689）は 2024 年 8 月 1 日に施行され、大部分の規定は 2026 年 8 月 2 日に完全適用されます。EU 域内のユーザーに AI を提供・利用する場合は、企業規模を問わず対象になり得るため、越境 EC やグローバル SaaS を手がける中小企業は早期の確認が必要です。

タイの個人情報保護法（PDPA）も同様で、タイ在住者の個人データを扱う事業者であれば国内外を問わず適用されます。AI チャットボットや需要予測 AI が顧客データを処理する場合は、同意取得・利用目的の明示・データ保持期限の設定が求められます。詳細はタイのPDPA対応とAI活用を両立させるコンプライアンスチェックリストも参照してください。

規制対応の優先度は、次の条件で判断するのが現実的です。

「大企業向けのガバナンスフレームワークをそのまま導入しようとしたら、ドキュメント作成だけで数ヶ月かかってしまった」——そうした声は、中小企業の現場でしばしば聞かれます。

大企業と中小企業では、ガバナンスに求められる粒度と優先順位が根本的に異なります。主な違いを整理すると、以下の通りです。

• 専任体制の有無: 大企業は AI 倫理委員会や Chief AI Officer を設置できますが、中小企業では既存メンバーが兼任するのが現実です
• リスクの種類と規模: 大企業は社会的影響範囲が広く、EU AI Act のような規制への対応が優先課題になります。中小企業は個人情報の取り扱いミスや、シャドーAI（Shadow AI）による情報漏洩リスクが相対的に大きくなります
• ドキュメント化の深度: 大企業では監査対応のために詳細な記録が必要ですが、中小企業では「誰が何のために使うか」を 1 ページで示せる簡潔なポリシーのほうが実際に機能します

NIST AI RMF 1.0（2023年1月公表）や ISO/IEC 42001:2023 は、組織規模を問わず適用できるよう設計されています。ただし、これらはあくまで参照基準であり、中小企業が全項目を網羅する必要はありません。自社の AI 利用範囲とリスクレベルに応じて、適用するコントロールを絞り込むことが現実的なアプローチです。

結論: 中小企業のAIガバナンスは「ポリシー」「データ管理」「ツール選定」の3領域を最低限押さえることで機能する。

以下では、スモールチームが優先的に確認すべきチェック項目を3つのカテゴリに分けて整理します。各項目の詳細は続くH3セクションで解説します。

「まずは詳細なポリシー文書を作ってから使い始めよう」と考えがちだが、実際は 1 ページ程度の簡潔な AI 利用規程を先に公開し、運用しながら改訂していくほうが定着しやすい。

ポリシー策定チェックでは、以下の項目を最低限確認してください。

• 利用可能ツールの明示: 社内で承認された AI ツール・サービスの一覧を明記し、未承認ツールの業務利用を禁止する。シャドーAI の温床を断つ最初の一手になります
• 禁止事項の具体化: 「機密情報・個人情報を外部 AI サービスに入力しない」「生成結果をそのまま社外に送付しない」など、行動レベルで記述する
• 用途別の可否区分: 社内文書作成・コード補助・顧客対応など用途ごとに「許可 / 条件付き許可 / 禁止」を表形式で整理すると、判断コストが下がります
• 責任の所在: AI が生成したアウトプットの最終確認者（担当者）を明確にし、ヒューマン・イン・ザ・ループ（HITL）の原則を規程に組み込む
• 改訂サイクル: 半年に 1 回など定期レビュー時期を規程内に明記し、形骸化を防ぐ

規程の形式は PDF より社内 Wiki や Notion などの編集可能なツールが推奨されます。更新のたびに全員へ周知できる運用フローとセットで整備してください。

チェック完了の目安は「新入社員が 10 分で読んで判断できるか」です。複雑すぎる規程は誰も読まず、シャドーAI を黙認する文化を生む原因になります。

AIをビジネスに組み込む際、データの品質と追跡可能性が不十分だと、モデルの出力精度が低下するだけでなく、規制対応の証跡も残せません。データ管理チェックは、ガバナンス体制の根幹を支える工程です。

確認すべき主なチェック項目は以下のとおりです。

• データの所在と分類: 個人情報・機密情報・公開情報を区別し、どのデータがAIシステムに入力されているかを一覧化する
• データリネージの記録: 学習データや推論時の入力データがどこから来て、どう加工されたかを追跡できる状態にする
• 保持期間と削除ルール: AIが参照するデータに対し、保持期間と廃棄手順を明文化する
• アクセス制御の確認: AIツールがアクセスできるデータ範囲を最小権限の原則に基づいて制限する

データリネージの整備レベルは、チームの状況によって判断を分けることが現実的です。社内に専任のデータエンジニアがいる場合はデータカタログツールの導入を検討する価値がありますが、数名規模のスモールチームであれば、スプレッドシートによる入力データの一覧管理から始めるだけでも、最低限の追跡可能性を確保できます。

また、外部のAI SaaSツールを利用している場合は、自社データがそのサービスの学習に使われるかどうかをサービス利用規約で必ず確認してください。利用規約に同意する前にデータ処理の範囲を把握しておくことが、後のトラブル防止につながります。

「このAIツール、本当に業務データを外部送信していないか？」——導入後にこの疑問が湧いても、手遅れになるケースがあります。モデル・ツール選定の段階でガードレールとモデルカードを確認する習慣が、後工程のリスクを大きく減らします。

確認すべき主なチェック項目

• モデルカードの存在確認: 提供元がモデルカードを公開しているか確認する。学習データの概要・用途制限・既知の偏りが明記されているものを優先的に選定する
• AIガードレールの有無: 有害出力のフィルタリングや、プロンプトインジェクション対策が組み込まれているかを確認する。NeMo Guardrails のような外部ガードレール層を追加できるか検討する
• データ送信先とプライバシーポリシー: API 経由でモデルを呼び出す場合、入力データが学習に利用されるかどうかを利用規約で確認する。個人情報や営業機密を含むプロンプトを送信する前に必ずチェックする
• ライセンスと商用利用条件: オープンウェイトモデルを社内利用する場合も、商用ライセンスの可否を確認する。ライセンス違反は法的リスクに直結する
• ベンダーのセキュリティ認証: SOC 2 Type II や ISO/IEC 27001 などの第三者認証を取得しているか確認する

スモールチーム向けの運用ポイント

専任担当者がいない場合は、ツール選定時に上記チェックリストを 1 枚のスプレッドシートにまとめ、導入申請の添付書類として運用するのが現実的です。

結論: ポリシーと役割分担は、専任担当者がいなくても「誰が・何を・どう判断するか」を文書化するだけで機能する。

チェックリストを実際の運用に落とし込むには、AI 利用規程の中身と担当者の役割設計が鍵になります。次の H3 では、規程に盛り込むべき要素・兼任担当者の設計・HITL の判断基準を順に解説します。

AI 利用規程を作る際、最初は「禁止事項を網羅したルールブックを作ろう」と考えがちです。しかし実際は、シンプルな 5 要素に絞った一枚紙のほうが現場への浸透率が高く、運用が継続しやすい傾向があります。

以下の 5 要素を最低限盛り込むことで、専任担当者がいないスモールチームでも機能する規程を作れます。

① 利用目的と適用範囲 どの業務でどの AI ツールを使ってよいかを明示します。「業務効率化目的に限る」「社外秘データの入力禁止」など、スコープを文字で確定させることがスタート地点です。

② 禁止事項と要注意行為の列挙 個人情報・機密情報の無断入力、シャドーAI（Shadow AI）の業務利用、出力結果の無検証での外部共有などを明記します。「何をしてはいけないか」が曖昧なまま運用すると、インシデント発生後の責任所在が不明確になります。

③ データ取り扱いルール AI ツールに入力できるデータの分類基準（公開可・社内限・機密）を定め、各分類に対応する AI ツールの利用可否を対応表で示します。データガバナンス（Data Governance）の観点から、入力データのデータリネージ（Data Lineage）を記録する運用も推奨されます。

④ ヒューマン・イン・ザ・ループ（HITL）の適用基準 AI 出力をそのまま使ってよい業務と、必ず人間が確認・承認すべき業務を区別します。顧客への回答・契約書の文案・財務データに関わる出力は、原則として人間によるレビューを必須とするのが一般的です。

専任の AI ガバナンス担当者を置ける中小企業はほとんどありません。現実的な解は「兼任」を前提とした役割設計です。

兼任体制を機能させるには、役割を「責任者」と「実務担当」に分けて明確に定義することが重要です。

責任者（AI ガバナンスオーナー）の主な役割

• AI 利用規程の承認・改定の最終判断
• 重大インシデント発生時の対外対応
• ガバナンス体制の定期レビュー（四半期に 1 回程度）

実務担当（AI ガバナンス担当者）の主な役割

• AI ツール・モデルの新規導入申請の一次審査
• チェックリストの更新と社内周知
• インシデントログの記録・集約

従業員数が 20 名以下の場合は責任者と実務担当を 1 名が兼務しても構いませんが、50 名を超える規模であれば部門ごとに実務担当を 1 名ずつ配置し、責任者が横断的に管理する体制が望ましいです。

兼任担当者が最も陥りやすい失敗は「本来業務との優先度の競合」です。これを防ぐには、AI ガバナンス業務の工数をあらかじめ業務計画に明示し、月次の定例ミーティング（30 分程度）をカレンダーに固定することが効果的です。

また、担当者が異動・退職した際のナレッジトランスファーを想定し、役割定義書とチェックリストをドキュメントとして整備しておくことが不可欠です。属人化を防ぐことが、スモールチームにおけるガバナンスの継続性を支える最大の鍵となります。

「AIが出した結果をそのまま使っていいのか、それとも人間が確認すべきか」——この判断基準が曖昧なまま運用を始めると、後から取り返しのつかないミスが生じやすくなります。

HITL（ヒューマン・イン・ザ・ループ）を設計するうえで重要なのは、すべての出力を人間がチェックするのではなく、リスクの高い判断だけに人間の関与を絞り込むことです。確認コストが高すぎると、現場は形骸化した承認作業を繰り返すだけになってしまいます。

判断基準の目安：HITL が必要なケース

• 顧客への直接通知・契約・与信判断など、取り消しが困難なアクションを伴う場合
• 個人情報・機密データを含む出力を外部に送信する場合
• ハルシネーションが発生した際の影響範囲が広い業務（法務文書、医療情報など）
• AI の信頼スコアや確信度が閾値を下回った場合

逆に、社内向けの要約生成や定型レポートの下書き作成など、影響範囲が限定的で修正コストが低い用途は、ヒューマン・イン・ザ・ループ(HITL)とは？AIで業務自動化を定着させる「人間参加型」設計の基礎で解説しているように、承認ステップを省略して自動化を進めても差し支えないケースが多いです。

運用フローの実装ポイント

1. トリガー定義: 上記の基準をドキュメント化し、ツール設定やシステムプロンプトに反映する

結論: リスク評価とAIオブザーバビリティは、中小企業でも最低限の仕組みを整えることで、ハルシネーションやプロンプトインジェクションといった実害を早期に検知・抑制できる。

AIの運用リスクは、導入後に初めて顕在化するケースが多いです。本セクションでは、ハルシネーション対策・AIオブザーバビリティ・インシデント対応フローの3点を順に解説します。

ハルシネーションとプロンプトインジェクションは、AIガバナンスの現場で最も頻繁に遭遇するリスクの双璧です。最初は「精度の高いモデルを選べば解決する」と考えがちですが、実際はモデルの品質だけでなく、運用設計側の対処が決め手になります。

ハルシネーション対策の基本

ハルシネーション（Hallucination）とは、LLM が事実と異なる情報を自信を持って出力する現象です。中小企業での典型的な被害は、顧客向け文書への誤情報混入や、社内ナレッジベースへの誤った回答です。対処の要点は以下の3点です。

• グラウンディング（Grounding）の徹底: RAG（Retrieval-Augmented Generation）を活用し、回答を社内ドキュメントや確認済みデータソースに紐付ける
• HITL（Human-in-the-Loop）の設置: 顧客接点や意思決定に関わる出力は必ず人間が最終確認するフローを設ける
• グラウンディングチェック（Grounding Check）の自動化: 出力が参照ソースと整合しているかをスクリプトで定期検証する

プロンプトインジェクション対策の基本

プロンプトインジェクション（Prompt Injection）は、悪意ある入力によってシステムプロンプト（System Prompt）を上書きし、AIに意図しない動作をさせる攻撃です。

AIオブザーバビリティ（AI Observability）ツールを選ぶ際、まず問うべきは「何を監視したいか」です。ログの収集だけで十分なケースもあれば、ハルシネーション検知やレイテンシ追跡まで必要なケースもあり、目的によって適切なツールの粒度は大きく変わります。

ツール選定の判断軸

• API 連携型の生成 AI を使う場合: LLM の入出力ログを記録・可視化できる軽量ツール（例: オープンソースの LangSmith や Helicone 相当の機能）が費用対効果に優れます。
• 自社サーバーや社内ネットワークで運用する場合: データを外部送信できないため、セルフホスト可能なオブザーバビリティ基盤を選ぶ必要があります。

最低限押さえるべき監視項目

1. 入出力ログ: プロンプトと応答の記録。インシデント調査の起点になります
2. レイテンシとエラー率: 異常な遅延やエラー急増はモデル劣化や攻撃の兆候です
3. ハルシネーション検知: グラウンディングチェックを組み込み、事実と乖離した出力にフラグを立てます
4. コスト追跡: トークン消費量を可視化し、予算超過を早期に検知します

スモールチームでの導入ステップ

まず既存のログ基盤（CloudWatch や Datadog など）に LLM の入出力を流し込む最小構成から始めるのが現実的です。ダッシュボードは「異常を検知したら通知する」アラート設定を最優先とし、レポート整備は後回しにします。

「AIが誤回答を返したとき、誰に報告すれば良いのか分からない」という声は、スモールチームの現場でしばしば聞かれます。エスカレーションフローが不在だと、インシデントが放置されたまま被害が拡大するリスクがあります。

エスカレーションフローは、次の3段階で設計すると機能しやすくなります。

• 第1段階（検知・記録）: AIの出力異常やデータ漏洩の疑いに気づいた担当者が、インシデントログに日時・内容・影響範囲を記録する。専用フォームや共有スプレッドシートで十分です
• 第2段階（初期判定）: AIガバナンス兼任担当者が24時間以内に重大度を「軽微／中程度／重大」の3段階で判定する。重大に該当する場合は、経営層への即時報告と該当AIツールの一時停止を検討します
• 第3段階（対外対応）: 個人情報が含まれるインシデントは、PDPA（タイ個人情報保護法）や国内の個人情報保護法に基づき、規定の期限内に監督機関へ通知する義務が生じる場合があります。法務・外部顧問への連絡先をフローに明記しておくことが重要です

フロー設計時のポイントは以下のとおりです。

• 連絡先リスト（担当者・外部顧問・ツールベンダー）をフローと同じ場所に保管する
• 判定基準を事前に文書化し、誰でも同じ判断ができる状態にする
• 四半期に一度、ロールプレイ形式で訓練を実施し、フローの実効性を確認する

大企業のような専任 SOC（セキュリティ運用センター）がなくても、3段階の判定基準と連絡先リストを整備するだけで、初動の遅れを大幅に減らすことができます。

結論: 善意の「とりあえず導入」が、後から取り返しのつかないリスクを生む。

中小企業のAIガバナンス失敗には、いくつかの典型パターンがあります。「使いながら考える」姿勢が、シャドーAIの温床や形骸化したドキュメントを生み出しがちです。

「まず使ってみて、問題が出たら考えよう」という姿勢は、スモールチームでは珍しくありません。しかしその軽い一歩が、シャドーAI（Shadow AI）の温床になりやすいです。

シャドーAIとは、IT部門や経営層の承認を経ずに現場が独自に導入・利用するAIツールの総称です。典型的なのは、個人アカウントで登録した生成AI（Generative AI）ツールに顧客データや社内資料をそのまま貼り付けて業務効率化を図るケースです。あるいは無料プランのAIサービスを複数の担当者が各自で契約し、データの取り扱いポリシーを誰も確認していない状態や、ノーコード・ローコード開発（No-Code/Low-Code Development）ツールで構築したAI連携フローがIT資産台帳に記録されないまま本番運用されるケースも珍しくありません。

最初は「個人の工夫」として見過ごされがちですが、実際には組織として管理すべきリスクが静かに積み上がっています。問題が起きてから対処するより、利用申請の入口を一本化しておくほうが、長期的なコストと信頼リスクを大幅に抑えられます。

対策の出発点は、シンプルなAIツール利用申請フローの整備です。

「きちんと整備しよう」という善意が、逆にガバナンスを形骸化させるケースがあります。

ドキュメントの量が多すぎると、担当者が更新を諦め、実態と乖離した「飾りの規程集」が生まれます。特にスモールチームでは、以下のパターンが報告されています。

• 承認フローが複雑すぎて、現場が非公式ツールに逃げる（これ自体がシャドーAIの温床になる）
• AI利用規程が 30 ページ超になり、誰も読まないまま形骸化する
• 変更のたびに全文レビューが必要な構造になっており、半年以上更新が止まる

ドキュメントの目的は「整備した事実の証明」ではなく、「現場が迷わず動けること」です。

チームが 10 名未満の場合は 1〜2 ページの簡潔な AI 利用規程で十分であり、50 名規模で複数部門がある場合は部門別の補足ガイドを薄く追加する形が機能しやすいです。規模に応じてドキュメントの粒度を変えることが、継続運用の鍵になります。

実務的な対処としては、次の 3 点が有効です。

• 「禁止事項」と「推奨手順」だけを 1 枚に絞ったクイックリファレンスを作成する
• 規程本体は変えず、ユースケース別の FAQ を別ファイルで運用する（本体の更新頻度を下げられる）
• 四半期に一度、15 分のレビューで済む構造を設計段階から意識する

ガバナンス文書は「薄くて使われる」ほうが、「厚くて読まれない」より組織を守ります。まず現場が参照できる最小構成から始め、必要に応じて段階的に拡充する姿勢が、中小企業には最も適しています。

結論: ポリシーと運用フローが整った後も、外部ツールの調達経路と人材育成という2つの盲点が残りやすい。

社内ルールを整備しても、サードパーティ製 AI ツールや従業員のリテラシー不足という死角は見落とされがちです。次の H3 では、これら2点を具体的に掘り下げます。

サードパーティの AI ツールは、自社が直接開発していないにもかかわらず、業務データに深くアクセスする「見えない扉」のような存在です。サプライチェーン攻撃（Supply Chain Attack）とは、信頼済みのツールやライブラリを経由して悪意あるコードやデータ汚染を持ち込む手法であり、中小企業ほど検証リソースが乏しく被害に気づきにくい傾向があります。

リスクが高まる典型的なケースを整理すると、次のとおりです。

• 無審査のプラグイン・拡張機能の導入: ノーコード・ローコード開発プラットフォームのマーケットプレイスで公開されているプラグインは、提供元の信頼性が均一ではありません
• RAG パイプラインへの外部データソース接続: 外部 API やクローラーを通じてベクトルデータベースに取り込むデータが汚染されると、RAGポイズニング（RAG Poisoning）につながるリスクがあります
• AI SaaS のデータ処理委託: 入力したプロンプトや業務データがモデル学習に利用される契約条項を見落とすケースが報告されています

対処の基本は「使う前に問う」姿勢です。具体的には以下を確認してください。

AIリテラシー教育は「一度やれば終わり」の研修ではなく、ガバナンス体制に継続的に組み込む仕組みとして設計する必要があります。

最初は「ツールの使い方を教えれば十分」と考えがちですが、実際にはリスク判断の基準を共有しないと、社員が悪意なくシャドーAIを使い始めたり、機密情報をプロンプトに貼り付けたりするケースが後を絶ちません。技術習得と倫理・リスク感覚の両輪を育てることが、ガバナンスの実効性を高めます。

スモールチームで体制に組み込む際は、以下の 3 段階を意識すると継続しやすくなります。

• 基礎理解（全員対象）: ハルシネーション、プロンプトインジェクション、個人情報の取り扱いなど、最低限知っておくべきリスクを 30 分程度のオンボーディング資料でカバーする
• 役割別の深掘り（担当者対象）: AIガバナンス担当者や開発メンバーには、NIST AI RMF や ISO/IEC 42001 の概念、インシデント対応フローまで踏み込んだ内容を提供する
• 定期アップデート（全員対象）: 生成 AI の進化は速いため、四半期ごとに新しいリスク事例や社内ルールの変更点を共有する場を設ける

教育内容は既存の業務フローに埋め込むことが定着の鍵です。たとえば、新しい AI ツールを導入する際のチェックリストに「担当者が AI リテラシー研修を修了済みか」という確認項目を加えるだけで、教育が形骸化しにくくなります。

Q1. 中小企業でもAIガバナンスは本当に必要ですか？

規模に関わらず、AIを業務に使う組織にはガバナンスが必要です。シャドーAI（Shadow AI）の横行や、意図しない個人情報の漏洩は中小企業でも起きています。EU AI Act（EU人工知能規則）は2026年8月2日に大部分が完全適用となり、EU市場に関わる企業は規模を問わず対応が求められます。最低限の利用規程とリスク評価だけでも整備しておくことで、信頼失墜や制裁リスクを大幅に下げられます。

Q2. 専任担当者がいない場合、誰がAIガバナンスを担えばよいですか？

専任を置くことが難しい場合は、既存の情報システム担当や総務・法務担当が兼任する形が現実的です。重要なのは「誰が決裁するか」を明文化することで、役割が曖昧なまま運用すると、インシデント発生時に対応が遅れます。NIST AI RMF 1.0（2023年1月26日公表）が示すGOVERN機能を参考に、意思決定フローだけでも文書化しておくと、兼任体制でも機能しやすくなります。

Q3. AIガバナンスの整備にはどれくらいのコストがかかりますか？

ツール導入費よりも、方針策定・教育・レビューにかかる人的コストが主体です。AIリテラシー（AI Literacy）研修や利用規程の作成は、既存の社内文書を流用しながら段階的に整備することでコストを抑えられます。ISO/IEC 42001:2023（2023年12月18日発行）の認証取得は任意ですが、同規格の要求事項を参考にしながら自社規模に合った軽量版を作ることが、費用対効果の高いアプローチといえます。

Q4. ハルシネーション（Hallucination）が発生した場合、どう対処すればよいですか？

まずヒューマン・イン・ザ・ループ（HITL）の仕組みで、AIの出力を人間が最終確認するフローを設けることが基本対策です。発生後は、どのプロンプトや入力データが原因だったかをログで追跡し、再発防止策をシステムプロンプト（System Prompt）やガードレール（AI Guardrails）に反映します。インシデント記録を蓄積することで、ガバナンスの継続的改善にもつながります。

Q5. AIガバナンスとデータガバナンスはどう違いますか？

データガバナンス（Data Governance）はデータの品質・管理・アクセス権を整備する取り組みであり、AIガバナンスはAIシステムの開発・運用・監視全体を対象とします。両者は密接に関連しており、データリネージ（Data Lineage）が整っていないと、AIモデルの判断根拠を追跡できず、AIガバナンスの実効性が下がります。中小企業では両者を一体で整備することが効率的で、まずデータの所在と利用目的を明確にすることが出発点となります。詳細はAIガバナンスとは？EU AI Act対応から社内ルール整備まで実務ガイドも参照してください。