結論：生成AIが全社に広がらない本当の原因は「モデルの性能」ではなく「データの利用可否を即答できないこと」
先に結論を述べる。PoCは動いたのに全社展開に進めない会社と、着実に使う場面を増やしていける会社の差は、使っているAIモデルの優劣ではない。「このデータをAIに入れていいか」を、会議を開かずに即答できる状態が社内にあるかどうか――ただそれだけである。
2026年6月10日、EYストラテジー・アンド・コンサルティング（EYSC）は、味の素のAI活用を支えるデータマネジメントおよびAIガバナンスの整備を支援したと公表した（共同通信PRワイヤー、EY Japan公式ケーススタディ）。支援期間は2026年1月から3月、実質的なルール作成は約2カ月。注目すべきは、この取り組みの中身にモデル開発やツール選定の話がほとんど出てこないことだ。論点として挙がっているのは、データ品質、アクセス権限管理、非構造化データの取り扱い、個人情報の利用判断――つまり全部「データ側」の話である。そして成果は「案件ごとに個別判断していた運用の標準化が進んでいる」と説明されている。
この事例は、日本企業の生成AIがPoC止まりになる構造の急所を、大手の実名で言い当てている。生成AIの申請が来るたびに法務・情シス・現場が集まって個別審査し、1件ごとに数週間が溶ける。判断者が変われば結論も変わる。やがて現場は「聞くだけ無駄」と学習し、無断利用（シャドーAI）に流れる。原因はモデルでもツールでもない。利用基準が決まっていないから、判断が都度発生するのだ。RAGがなぜ社内で広がらないのかという構造はRAGが「関心はあれど普及せず」に終わる失敗構造で分析したが、本記事はその処方箋――データ側をどう整えるかに絞り、しかも大手の予算がない中小企業が自社でどこまで再現できるかまで踏み込む。
この記事の要点：生成AIの全社展開とは「AIを増やすこと」ではなく、**「データの利用可否を即答できる状態を作ること」**である。味の素の事例は、それを「攻め」と「守り」を同じ部署に同居させることで実現した。中小企業は同じ体制を組めなくても、判断の型（分類→基準→技術強制）は同じ順番で再現できる。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。
事例の要点（一次ソース：EY公表リリース／EY公式ケーススタディ準拠）
まず事実関係を、二次情報と一次情報を切り分けて整理する。以下は共同通信PRワイヤー掲載のEYリリース、およびEY Japan公式のケーススタディページで確認できた範囲である。案件の金額・工数・成功率といった内部数値は公表されておらず、本記事でも一切推測しない。
横にスクロールして確認できます
| 項目 | 内容（公表情報に基づく） |
|---|---|
| 発表 | EYストラテジー・アンド・コンサルティング（2026年6月10日公表） |
| 支援先 | 味の素株式会社 |
| 期間 | 2026年1月〜3月（実質のルール作成は約2カ月） |
| 支援内容 | AIの実務活用を支えるデータマネジメント／AIガバナンス体制の整備 |
| 具体策 | 利用場面ごとに必要となるデータの取り扱い・判断の考え方を明確化し、ルールと手引書に落とし込み。非構造化データを含む多様なデータの品質・利用範囲・権限の考え方を見直し |
| 体制の特徴 | 味の素側はDX推進部内に「攻め（AI活用拡大）」と「守り（ガバナンス構築）」を同居させ、両者が対立せず共通目標のもと協働 |
| 扱った論点 | データ品質、アクセス権限管理、非構造化データの取り扱い、個人情報の利用判断 |
| 成果 | AI利用時のデータ取り扱いの判断基準が明確になり、案件ごとの個別判断から標準化された運用へ移行が進む |
| 今後 | 整備したルールと手引書は「更新可能な文書」として、AIの進展・規制変化に応じて見直す前提 |
EY公式ケーススタディで、EYの川勝健司リスク・コンサルティングパートナーは、生成AIについて**「権限範囲を網羅的に探索し、これまで表に出ていなかったファイルまで回答に含める可能性がある」**と指摘している（EY公式ページより引用）。これは後述する「権限素通り」問題の核心であり、AI導入がそのまま内部統制の穴になりうることを、支援した当事者が明言している点で重い。
裏を返せば、「全データを一律に許可／禁止」する雑な基準は機能しないということでもある。味の素の整備が「利用場面ごと」の基準づくりだったのは、利用目的×データ種別のマトリクスでしか現実の判断は割り切れないからだ。ここが実務の要諦になる。
大手事例の「本質」を3つに要約する
味の素の事例は大手の話だが、中小企業が学ぶべき本質は規模に依存しない。公表情報から抽出できる要点は次の3つだ。
本質1：整備の起点は「机上の理論」ではなく「実際のユースケース」だった。 EY公式ケーススタディによれば、味の素は社内に存在する数十のAI活用事例から代表例を抜き出し、「現場が判断に迷いやすいポイント」に焦点を当ててルールを作った。全社のデータを一斉に棚卸ししてから基準を書いたのではない。使う場面から逆算したのである。これは中小企業にとって最大の朗報だ。全社整備を待つ必要はなく、最初のユースケースで使うデータだけを対象にできる。
本質2：ルールは「遵守事項」と「推奨事項」の二層で設計された。 すべてを一律の禁止規定にすると現場は動けず、逆にすべてを推奨止まりにすると守られない。守るべき最低ライン（遵守事項）と、望ましい運用（推奨事項）を分けることで、「攻め」と「守り」を両立させた。この二層構造は、専任のガバナンス部門を持たない中小企業ほど効く。判断に迷ったときの拠り所が2段階あるだけで、都度会議がなくなる。
本質3：「What」で終わらせず「How」まで落とした。 ルールを定義しただけでは現場は動かない。だからこそ味の素の整備では「手引書」まで作り、実装方法を示した。これは中小企業が最も失敗しやすい点でもある。「データを分類しましょう」という方針（What）だけ作って、「誰が・どのツールで・どう付与するか」（How）を決めないから、紙のルールで終わる。
なお、この3点はいずれも使うAIモデルに依存しない。モデルはClaude Fable 5の一般提供でAI開発コストの前提が変わったように数カ月単位で入れ替わるが、データ分類と利用基準は一度作れば全モデル・全ユースケースで使い回せる資産になる。投資対効果が最も高いのはデータ側なのだ。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
なぜ「データ側」で生成AIが止まるのか：4つの典型症状
GXOがAI導入の相談を受けるとき、PoCが本番化しない会社にはほぼ共通の症状が出る。自社に当てはまるものがないか確認してほしい。
症状1：「入れていいデータ」が決まっておらず、案件ごとに会議が発生する。 申請のたびに法務・情シス・データオーナーが集まって個別審査する。判断者によって結論が割れ、現場は「聞くだけ無駄」と学習してシャドーAIに流れる。味の素が解いたのはまさにこの「都度判断」で、標準化された運用への移行が成果として挙げられている。
症状2：非構造化データが「誰のものか」分からない。 生成AIの本領は議事録・報告書・メール・図面・コールログ・画像・音声といった非構造化データの活用にある。ところがこれらは構造化データと違い、オーナーも機密区分も品質基準も未定義のまま放置されていることが多い。RAGの検索対象に入れた瞬間、古い規程や廃止済みの手順書まで「正解」として回答に混ざる。EY公式ケーススタディでも、テキスト・画像・音声・動画の非構造化データについて「AIがどう使うか」を前提とした権限設計が課題として挙げられていた。
症状3：アクセス権限がAI経由で"素通り"する。 人がアクセスできない文書でも、AIが学習・検索対象にしていれば回答経由で漏れる。前述の川勝パートナーの言葉どおり、生成AIは権限範囲を網羅的に探索する。元データの権限がAIの回答にまで引き継がれる設計（権限フィルタリング）がなければ、AI導入がそのまま情報漏えい経路になる。エージェントがデータを能動的に動かす時代の権限と系譜の備えはSnowflake Summit 2026に学ぶエージェント時代のデータガバナンスでも扱った。
症状4：AIが生成したデータと人が作ったデータが混ざり、出自が追えない。 これは新しい症状だ。EY公式ケーススタディはIPAのレポートに触れ、2026年から2032年にかけて高品質な学習データが枯渇する可能性、そしてAI生成データと人間作成データを区別する「出自管理」の重要性を指摘している。社内でも、AIが下書きした資料がそのまま次のRAGの参照元になる連鎖が起きると、誤りが誤りを増幅する。どのデータがAI由来かを記録できる仕組みは、これからのデータ品質基準の一部になる。
整備の順番：AI-Ready基盤を作る「3レイヤ」
味の素の「利用場面ごとの基準の具体化」を一般化すると、整備すべきものは次の3レイヤに分解できる。順番を間違えると必ず手戻りする。
横にスクロールして確認できます
| レイヤ | 決めること | 具体例 |
|---|---|---|
| ① データ分類 | データを機密度・種別で区分し、ラベルを付ける | 公開情報／社内一般／部門限定／個人情報を含む／営業秘密 |
| ② 利用基準（マトリクス） | 分類×利用目的ごとに「可／条件付き可／不可」を事前定義。さらに遵守事項と推奨事項に二層化 | 社内一般×社内チャットボット＝可、個人情報×外部API＝匿名化を条件に条件付き可、営業秘密×外部SaaS＝不可 |
| ③ 技術的強制 | 基準を人の注意ではなくシステムで強制する | アクセス権限連動の検索フィルタ、マスキング、監査ログ、DLP、AI由来データのタグ付け |
①の分類なしに②の基準は書けず、②の基準なしに③のシステム要件は定義できない。逆に③を飛ばして①②だけ作ると「紙のルール」で終わり、現場の判断ばらつきは消えない。味の素の整備で「ルールと手引書を更新可能な文書として実装」とされているのは、基準を運用とシステムに落とし込むところまでがガバナンスという認識の表れと読める。中小企業がつまずくのは、たいてい②で止まって③に予算を割かないパターンだ。
AI-Ready診断：自社は「何問」即答できるか
次の設問に、会議を開かずに即答できるか。YESの数で自社のAI-Ready度を判定できる。紙に印刷して情シス・法務・現場のそれぞれに答えてもらうと、認識のズレが可視化される。
- Q1.「この文書を社内チャットボットの参照対象にしていいか」を、会議なしで判断できる基準があるか？
- Q2. 非構造化データ（議事録・報告書・マニュアル・画像等）に、オーナーと機密区分が定義されているか？
- Q3. 個人情報を含むデータをAIで使う場合の判断手順（匿名化基準・法的根拠の確認）が文書化されているか？
- Q4. 元データのアクセス権限が、AIの検索・回答にも引き継がれる仕組み（権限フィルタリング）があるか？
- Q5. 誰がどのデータをAI経由で参照したかのログが取れているか？
- Q6. AIが生成したデータと人が作ったデータを区別できる仕組み（出自タグ等）があるか？
横にスクロールして確認できます
| YESの数 | 判定 | 次の一手 |
|---|---|---|
| 5〜6問 | AI-Ready | ユースケース拡大に集中してよい。基準の運用改善に軸足を移す |
| 3〜4問 | 基準はあるが技術的強制が弱い典型 | ③レイヤ（権限フィルタ・ログ・マスキング）を基盤側に実装する |
| 0〜2問 | PoC止まり予備軍 | AIツール選定より先に①②を作る。最初の1ユースケースに範囲を絞る |
0〜2問の企業がやりがちな失敗は、「とりあえずAIツールを入れて、ルールは走りながら考える」だ。利用基準がないままツールだけ入ると、症状1（都度会議）か症状3（権限素通り）に直行する。チャットボットの具体的な利用ルール設計はAI事業者ガイドライン第1.2版の実務手引きも参照してほしい。
中小企業はどこから手を付けるか：大手のやり方をそのまま真似てはいけない
ここが本記事の中心だ。味の素はDX推進部に「攻め」と「守り」を同居させ、コンサルティングファームと全社整備を進められた。だが年商1〜10億円規模で、社内のIT担当が一人情シス・兼任情シス、あるいは実質不在という会社が、同じ進め方をする必要はないし、してはいけない。全社データの棚卸しから始めれば、確実に頓挫する。現実的な手順は次の通りだ。
手順1：最初のAIユースケースを1つだけ決める。 「社内規程チャットボット」「見積書作成の下書き」「問い合わせ一次対応」など、効果が見えやすく、機密度の低いところから選ぶ。全社ではなく1業務に絞る。
手順2：そのユースケースで使うデータ群だけを分類する。 全社のデータではなく、そのチャットボットが参照する文書だけを、公開／社内一般／部門限定／個人情報あり／営業秘密の5区分でラベリングする。数十ファイルからで十分だ。
手順3：利用基準マトリクスを1枚作る。 分類×利用目的で「可／条件付き可／不可」を埋める。案件が増えるたびに行を足していく。この「前例の蓄積」がやがて全社基準になる。味の素の二層構造にならい、最低ラインの遵守事項（例：個人情報を外部APIに素で渡さない）と推奨事項（例：出典を回答に添える）を分けておく。
手順4：「攻めと守り」を一人二役でも意識的に分ける。 大手はDX推進部で役割分担できるが、中小企業は同じ担当者が両方を担うことになる。だからこそ、「今はAIを広げる帽子（攻め）」「今はリスクを止める帽子（守り）」と、判断のたびにどちらの立場で考えているかを明示する運用が効く。攻めと守りが同じ頭の中で混ざると、たいてい守りが勝って何も進まないか、攻めが勝って事故る。
手順5：技術的強制は個別アプリではなく基盤側に寄せる。 アプリごとに権限制御を作り込むと、ユースケースが増えるたびに作り直しになる。権限・マスキング・ログはデータ基盤側で一元化する。ここがAI時代のデータ活用基盤の要件定義の設計論点であり、AI時代のデータ基盤は「分析・可視化用」ではなく「AI利用の可否を即答できる基盤」として要件を書き直すべきだ。
手順6：現在地に自信がなければ第三者の棚卸しを挟む。 どのユースケースから始めるべきか、自社のデータがどこまでAI-Readyかを客観評価したい場合、AI導入可否のアセスメント・第三者診断のような外部の棚卸しを挟むと、整備の優先順位が明確になる。社内だけで議論すると「できない理由」ばかり集まりがちだが、第三者が入ると「まず何をやるか」に会話が変わる。
発注前チェックリスト：ベンダーに何を聞き、見積もりの何を見るか
データ基盤やAI導入をベンダーに発注する前に、次を確認してほしい。ここを詰めずに発注すると、「AIは動くがガバナンスは別料金」で追加費用が膨らむ典型に陥る。
横にスクロールして確認できます
| 確認項目 | 発注前に必ず聞くこと | これが抜けていると起きること |
|---|---|---|
| 権限フィルタリング | 元データのアクセス権限をAIの回答にも引き継げるか。実装方法は | 権限素通り。人が見られない文書がAI回答経由で漏れる |
| 非構造化データ対応 | 議事録・画像・音声等にオーナー・機密区分・鮮度をどう付与するか | 古い規程が「正解」として回答に混ざる |
| マスキング／匿名化 | 個人情報を含むデータの匿名化・マスキングを基盤側で強制できるか | 現場の手作業頼みになり、いつか漏れる |
| 監査ログ | 誰がどのデータをAI経由で参照したかのログが取れるか。保管期間は | 事故発生時に追跡不能。内部統制上の説明責任を果たせない |
| 出自管理 | AI生成データと人作成データを区別・記録できるか | 誤りが誤りを増幅する連鎖に気づけない |
| 運用の移管 | ルール・手引書は誰が更新し続けるのか。自社で運用できる形か | ベンダー依存が続き、更新が止まって陳腐化する |
| 見積もりの範囲 | 「AI構築」の見積もりに、権限・ログ・マスキングの実装が含まれているか | 別見積もりで追加請求。当初予算の想定が崩れる |
とくに最後の一行は重要だ。多くのAI導入見積もりは「モデル・アプリ・PoC」の費用は詳しく書くのに、ガバナンスの技術的強制（③レイヤ）が範囲外になっていることが多い。相見積もりを取るときは、③レイヤが含まれているか、含まれていないなら概算いくらかを必ず横並びで比較してほしい。ここを可視化すると、安く見えた見積もりが実は高い、という逆転がよく起きる。要件整理そのものに不安があるなら、AI開発の要件定義・見積もりの壁打ちから入るのが安全だ。
よくある失敗パターン（発注前に潰しておく）
- 全社棚卸しから始めて頓挫する。 完璧なデータカタログを作ろうとして半年溶かし、AI活用は一歩も進まない。→ ユースケース1つに絞る。
- 紙のルールで終わる（②止まり）。 基準は作ったが技術的強制がなく、現場の判断ばらつきが消えない。→ ③レイヤを基盤側に実装する。
- 守りが勝ちすぎて何も進まない。 リスクを恐れて全面禁止にし、現場がシャドーAIに逃げる。→ 遵守事項と推奨事項の二層化で「使える範囲」を明示する。
- 攻めが勝ちすぎて事故る。 スピード優先で権限設計を後回しにし、権限素通りで漏えい。→ 最初のユースケースから権限フィルタを設計に入れる。
- ツールを先に買う。 利用基準がないままSaaSを契約し、都度会議に逆戻り。→ ①②を先に、最小限でよいから作る。
- ベンダー任せで運用が止まる。 手引書の更新者を決めず、半年で陳腐化。→ 更新責任者と見直しサイクルを契約時に決める。
この記事を読むべき人
- 生成AIのPoCは動いたが、「このデータを使っていいか」の判断が毎回止まり、全社展開に進めない経営者・事業責任者
- 社内にIT専任がおらず（一人情シス・兼任情シス・実質不在）、どこから手を付ければいいか分からない中小企業の決裁者
- 議事録・マニュアル・図面等の非構造化データを活用したいが、オーナー・機密区分・品質が未整備の会社
- AIツールを入れたのに、権限素通りや情報漏えいが不安で本番展開に踏み切れない情シス・法務担当
- ベンダーに発注する前に、何を聞き、見積もりの何を確認すべきかを知っておきたい人
GXOに相談すべきタイミング
次のいずれかに当てはまるなら、AIツールの選定より先にデータ側の詰まりを解消したほうが早い。
- PoCは動いたが、「このデータを使っていいか」の判断が毎回止まり、全社展開に進めない
- 非構造化データを活用したいが、オーナー・機密区分・品質が未整備のまま放置されている
- アクセス権限・マスキング・監査ログをデータ基盤側で一元的に効かせる設計がしたい
- AIエージェントに社内データを能動的に扱わせたいが、権限と監査の設計に不安がある
GXOは、データ分類と利用基準の設計から、権限フィルタリング・監査ログ・マスキングを技術的に強制するデータ活用基盤の構築、現在地を客観評価するAI導入可否の第三者アセスメント、さらにAIエージェント導入の要件整理・相談まで、「AI-Ready」なデータ環境づくりを一気通貫で支援する。AIツールを増やす前に、データ側の詰まりを解消したい企業はぜひ相談してほしい。
よくある質問（FAQ）
Q. データガバナンスの整備は、AI導入の前と後のどちらでやるべきか？ A. 並行が正解。最初のユースケースで使うデータ群に限定して分類・基準を作り、AI導入と同時に運用を始める。全社整備の完了を待つとAI活用が数年止まり、逆にガバナンスなしで進めるとシャドーAIと権限素通りが発生する。味の素も約2カ月で最初のルールを作り、更新前提で走らせている。
Q. 非構造化データの整備はどこまでやれば「AI-Ready」と言えるか？ A. 最低限は「オーナー」「機密区分」「鮮度（最新版か）」の3点が定義されていること。完璧なメタデータ整備は不要で、AIの参照対象に入れるデータから順に付与していけばよい。全ファイルを一度に整える必要はない。
Q. 中小企業でも味の素のような整備は必要か？ A. 規模相応に必要。判断基準がないことによる都度会議のコストと、権限素通りによる情報漏えいリスクは企業規模に関係なく発生する。ただし範囲は「最初のユースケースで使うデータ」からで十分だ。大手のように全社一斉・専門部署設置を真似る必要はない。
Q.「攻め」と「守り」を分ける専門部署が作れない。どうすればいいか？ A. 部署を分ける必要はない。同じ担当者が、判断のたびに「今はAIを広げる立場（攻め）／今はリスクを止める立場（守り）」のどちらで考えているかを明示するだけでも効果がある。混ざると守りが勝って停滞するか、攻めが勝って事故る。二層ルール（遵守事項／推奨事項）があると、この切り替えが機械的にできる。
Q. ベンダーの見積もりが安く見えるが、何を疑うべきか？ A.「AI構築」の見積もりに、権限フィルタリング・監査ログ・マスキングという③レイヤの実装が含まれているかを確認する。ここが範囲外だと、後から別見積もりで請求され、当初予算が崩れる。相見積もりは③レイヤ込みで横並び比較すること。
参考資料（一次・公式ソース）
- EY Japan（EYストラテジー・アンド・コンサルティング）公式ケーススタディ「味の素株式会社が挑む『攻め』と『守り』のAIガバナンス――『AI-Readyなデータ整備』の実践とは」 https://www.ey.com/ja_jp/insights/consulting/practical-case-studies-of-ai-ready-data-preparation
- 共同通信PRワイヤー（EY Japanプレスリリース）「EYストラテジー・アンド・コンサルティング、味の素社のデータマネジメントとAIガバナンス整備を支援」（2026年6月10日） https://kyodonewsprwire.jp/release/202606100647
本記事は2026年7月16日時点の公開情報をもとに作成。事例の事実関係はEY Japan公式ケーススタディおよびEYの公表リリースに基づく（味の素側担当者名・EY側担当者名・コメントは同公式情報からの引用）。IPAの学習データ枯渇に関する言及はEY公式ケーススタディ内での紹介に基づく二次的引用である。個人情報の利用判断など法的論点を含む実務対応にあたっては、弁護士等の専門家にも相談すること。
