生成AIの8割がガバナンス不全。それは「設計」の欠如だ

生成AIを導入した企業の実に8割が「ガバナンス不足」に陥っている――そんな調査結果が報じられました。多くの組織がAIを「魔法のツール」として導入しながら、それを事業にどう組み込むかという「設計」を怠っている。この数字は、そのことをはっきりと示しています。

ガバナンスとは、ルールを作って監視することだけではありません。自社の「やりたい事業」を実現するために、AIという新しい技術をどう「翻訳」し、どう「配置」するか。そうした上位の経営設計そのものです。8割の不足は、この設計のプロセスが抜け落ちている証拠なのです。

AIは「管理対象」ではなく「設計対象」

多くの企業、とりわけスピードを重んじる中小企業は、AIガバナンスを「リスク管理」や「コンプライアンス遵守」の問題と捉えがちです。「社外秘情報を入力しないように」「出力は必ず人間が確認する」といったルール作りに終始してしまう。それも必要ですが、十分ではありません。JBpressの記事が指摘するように、AI同士の相互作用で予想外の振る舞いが生じたり、AIが「仲間」を守るために嘘をついたりといった不穏な挙動は、単純な運用ルールでは防ぎきれない複雑さを持っています。

問われているのは、AIを「管理すべき危険な対象」と見るか、「事業目的を達成するための設計対象」と見るかです。後者に立てば、ガバナンスの課題はがらりと変わります。目的は「違反をゼロにすること」ではなく、「許容できるリスクの範囲で、AIから最大の事業価値を引き出すこと」になるのです。KDDIのグループガバナンス不全の報道が「聖域」の存在を指摘したように、技術――この場合はAI――が「よくわからないから触れない聖域」になった瞬間、ガバナンスは機能しなくなります。

「安全なAI活用の4要素」を目的から逆算する

ITmediaの記事は、安全なAI活用の要素として「方針」「責任体制」「教育」「技術的対策」の4つを挙げています。優れた枠組みですが、中小企業がこれをそのままマニュアルとして取り入れても、形骸化するでしょう。大切なのは、自社の「事業目的」から逆算して設計することです。

たとえば「顧客問い合わせの対応時間を3割短縮したい」という事業目的があるとします。AI導入の設計は、ここから始まります。

• 方針：「問い合わせ対応の効率化を目的とし、AIは一次応答と情報抽出に限って活用する。最終判断と顧客情報の確認は人間が行う」というように、目的と役割をはっきりさせます。
• 責任体制：AIの出力ミスによる顧客クレームは、導入を推進した営業部長が最終責任を負い、日常の出力チェックはカスタマーサポートチームが担う。このように、責任と権限をセットで設計します。
• 教育：「AIをどう使うか」ではなく、「AIを使ってどう事業目的を達成するか」をチームで話し合う場を設けます。AIの誤りを見つけたときの報告ルートも、ここで決めておきます。
• 技術的対策：機密性の高い顧客データをAIに流さないシステム設計と、応答文のトーンが自社のブランド価値に合っているかを簡易チェックするツールの導入を検討します。

つまり4要素は、目的から派生する「実装装置」にすぎません。装置から設計を始めると、ルールはあるのに誰も使わないAIが出来上がります。

中小企業が今日から始める「AIガバナンス設計」

東大のように、専任の「最高リスク責任者（CRO）」を民間から招へいすることは、中小企業には現実的ではありません。それでも、機動性を生かした、より本質的な設計はできます。

まず目的を言葉にし、「許容リスク」を定める

まず、AIで「何を達成したいのか」を一文で書き出してください。「売上を上げたい」では曖昧すぎます。「既存顧客へのクロスセルメールの文案作成の負荷を減らし、営業が新規開拓に充てる時間を週5時間増やす」くらいの具体性が必要です。

次に、その目的のために「どこまでならリスクを許容できるか」を議論します。たとえば「AIが作成したメール文案の1割は人間がチェックせずに送っても問題ないが、新製品の情報は必ず全件チェックする」といった判断です。リスクは0か100かではなく、1から99までの連続量です。0リスクを求めれば、コストが膨らみ、使い物にならないシステムが出来上がります。

次に、複数の案を並べて「撤退できる道」を織り込む

AI導入は一つの大きな選択に見えますが、実際には無数の小さな選択の積み重ねです。主な案を、常に3つ以上並べて考えましょう。

• 案A：汎用AI（ChatGPT等）をサブスクリプションで導入し、社内教育を徹底する。
• 案B：特定業務（例：技術文書の要約）に特化した専用ツールをライセンス購入する。
• 案C：まずは3ヶ月のパイロットプロジェクトとして、一つのチームで案Aを試し、評価基準を設けて検証する。

多くの企業は案AかBかの二択で考え、うまくいかないと「AIは使えない」と結論づけます。ここで効くのが、案Cのような「可逆性の高い選択肢」です。パイロットプロジェクトでは、「文案作成の時間が20%短縮され、かつ顧客の誤解を招く表現が月1件以下」といった成功基準を事前に決めておきます。満たせなければ、潔く中止する。この「撤退可能性」を最初から設計に織り込むことこそ、最も堅実なリスク設計です。

そして、専門家を「翻訳者」として使う

法務やITの専門家に「AIを導入しても大丈夫ですか？」と聞いてはいけません。彼らは「決定者」ではなく「翻訳者」です。聞くべきなのは、「『顧客問い合わせの一次応答にAIを使いたい』という目的を達成するには、法律上・技術上、どのような成立条件がありますか？」という問いです。

専門家の役割は、あなたの事業目的を法律や技術の言葉に翻訳し、実現できる形を示すことです。「ダメ」という結論ではなく、「〇〇という条件を満たせば成り立つ」という情報こそが、設計に必要な材料になります。

「聖域」を作らず、全体最適を考える

KDDIの事例や東大病院の改革が示すように、ガバナンス不全は、「よくわからないから」と手を付けない「聖域」が生まれたときに起こります。いま多くの企業で、AIがその「聖域」になりつつあります。技術が複雑なほど、経営陣は「お任せ」にしがちです。しかしそれでは、目的と手段が断絶してしまいます。

生成AIの8割がガバナンス不足という調査結果は、警鐘であると同時にチャンスでもあります。大企業が硬直したルール作りに悩むあいだに、中小企業は機動力を生かし、「事業目的起点のAI設計」という、より本質的で強いガバナンスをいち早く実装できるからです。

それは、AIを「飼いならす」ことではありません。自社の事業という「車」をよりよく走らせる「新しいエンジン」として、AIをどう設計し、どう制御するかを考えることです。その第一歩は、壮大な計画書ではありません。一つの小さな事業目的を言葉にし、そこへ向けてAIという技術を「翻訳」することから始まります。