「リスクだから使わせない」は正しいか——機密データをAIの精度に変える設計

「工場のPCが破られると中に入られる」——機密データとAIが並んだときの本音

同じ化学メーカーの担当者は、別の場面で技術対策への評価を口にしていました。ただ、工場のPCが破られれば結局は内部に入られてしまう。ヒューマンエラーのリスクは技術だけでは拭えないのではないか、とも付け加えました。技術的な対策を積み重ねても、最後に残るのは人の不安です。これは特殊な会社の話ではありません。私たちが製造業・製薬業のR&D部門と接する中で、繰り返し聞く声です。

機密性の高いデータを扱う現場ほど、生成AIの検討は「まず止める」から始まります。治験データ、実験データ、仕様書、原価表——外に出せば取り返しがつかない情報が多いからです。この判断は間違っていません。ただし、そこで検討が終わってしまうと、機密データはAIにとって「触れない対象」のままで固定されます。

なぜ「触らせない」だけでは、AIの精度は上がらないのか

生成AIの機密データ活用について検索すると、上位に出てくるのはほぼ全て「リスクと対策」の記事です。情報漏えいの事例、利用ガイドラインの整備、アクセス管理、AIガバナンス——どれも必要な対策です。ただ共通しているのは、「どう漏らさないか」という守りの発想だけで終わっている点です。

正直に言えば、この発想には限界があります。守りだけを固めても、AIが出す答えの精度は1ミリも上がりません。AIの回答精度を決めるのは、どれだけ良質な機密データを「正しく」渡せるかという設計の側にあります。機密データを遠ざけるほど、AIは一般論しか答えられなくなるからです。

私たちが顧客と話す中でも、この構図は何度も出てきました。データはある程度揃っているのに、そのデータを基に人がどう考え、どう動くかを定義しきれていない、という声を大手化学メーカーのAI推進担当から聞いたことがあります。マニュアルだけでは足りず、行間を読むような判断が現場に残っているという話でした。データがあっても使い方が定義されていなければ、AIに渡す前の段階で止まってしまいます。守りのルールだけを整備しても、この行間の部分は一向に埋まりません。

正答率50%から90%へ——塩野義製薬が機密データを「材料」に変えた設計

この発想を実務で裏づけている事例が、塩野義製薬です。同社は生成AIの正答率を50%から90%まで引き上げました。長年スタッフが管理してきたMicrosoft Excelの管理台帳には、複雑な実験データや仕様書が蓄積されています。この機密データの塊に対し、AIエージェントに3つの手段を持たせました。「OpenSearch検索ツール」「ファイル読み込みツール」「Excelツール」です。状況に応じてこれらを動的に切り替えさせたといいます(キーマンズネット)。

この仕組みが興味深いのは、AIに全てを丸投げしていない点です。ユーザーの意図を「読み取り」、最適な手段を「判断」し、データを「実行」で収集し、最後に回答を「確認」する。この4ステップを自律的にループさせています。1つのツールで答えが出なければ、検索キーワードを変えて別のツールに切り替える。機密データという「重い材料」を、AIが扱いやすい形に分解して渡す工程そのものが、精度向上の正体でした。

「AIに学ばせるのは解き方だけ」——私たちの匿名化ガードレール

私たちAI-Pathが顧客の現場に入るときも、同じ考え方を実装しています。「他社に情報が漏れないか」という懸念を受けたことがありますが、その際は情報をマスキングし、誰のものか分からない状態にしてから学習させると答えています。AIが学ぶのは、こういうトラブルにどの回答で解決したかというアルゴリズムだけです。金額情報には一切答えない、固有名詞や企業名は学習対象外にする、といったガードレールを設定し、最終判断はユーザー自身が行う設計にしています。

私たちの現場経験では、この「何を渡し、何を渡さないか」の線引きこそが設計の本質です。機密データを丸ごと渡すのではなく、AIが判断に使える「解き方」だけを取り出す。塩野義製薬の3ツール構成も、実験データという機密の塊を、検索・読み込み・構造化という別々の作業に分解している点で、発想は同じです。

この線引きは、社内の権限設計とも直結します。私たちが顧客のシステムを構築する際は、資料の閲覧制限だけでなく機能単位でアクセス権を振り分け、取引先ごとに権限設定セットを細かく運用しています。財務や人事に関わる情報は、AIが扱う領域そのものから分離しています。「何を見せるか」ではなく「どの機能に、どの権限で触れさせるか」まで踏み込むことで、機密データを渡しても事故が起きない構造を先に作っています。

精度をもう一段上げる工夫——生成AIの正答率向上とAIによる「審判」

機密データを正しく渡せても、AIが返す答えが常に正確とは限りません。生成AIには、もっともらしい誤答をそれらしく返す「ハルシネーション」という弱点があります。ある産業機械メーカーの推進課マネージャーが、AI回答100問を比較評価したところ、畑違いの回答や誤った回答がいくつも混ざっていたと率直に振り返っていたのを覚えています。機密データを扱う場面では、この誤答リスクは看過できません。

私たちが実務で使っている工夫の1つが、複数のモデルに役割を分ける方法です。1つのモデルが出した回答を、別のより高性能なモデルに採点させます。コストは一時的に増えますが、より正しい回答を出すモードを追加できます。また、根拠の出所を混ぜないことも欠かせません。社内に蓄積した一次情報でまず答えさせ、それで足りない場合にだけWeb検索の情報を追加で確認する、という順序を固定しています。一次情報と外部情報が混在すると、どちらを根拠に回答したのかが追えなくなり、機密データを渡した意味が薄れてしまうからです。生成AIの正答率向上は、渡すデータの質だけでなく、この採点・確認の工程セットで決まります。

自社で先に実装し、数字で示す——AI-Pathの「守れる設計」

思想だけを語っても、読者には伝わりません。私たちは「守れる設計」を、自社のプロダクトで数値として示すことにこだわっています。単体テスト(Vitest)とシナリオテスト(Playwright)を自動化し、自社の議事録AIは自動テスト2,000件超を全て通過させています。資料生成ツールでは、出力の忠実度(元のPowerPointとのピクセル一致度)をSSIM 0.73から0.89まで改善しました。自社の経理システムのテストカバレッジは、実測で99%台に達しています。

ただし、テストだけでは足りません。AIが苦手とするUX観点は、ユーザーが実際に触ってダメ出しをする受け入れテスト(UAT)を人が担う工程として組み込んでいます。VibeCodingで起こりがちな「謎の項目が勝手に増える」といった事故は、このUATで止めています。顧客の自社環境へ移行する前には攻撃テスト(レッドチーム)を実施し、本番にはIP制限を入れる。秘密情報の管理では、平文のまま展開せずメモリ内で処理する仕組みに移行し、889件のシークレットを扱いました。

正直に言えば、ここまでやってもAIツールのミスに起因するセキュリティリスクが消えるわけではありません。今後多くの企業が直面する課題だと捉えているからこそ、私たちは自社で先に厳格化して知見を貯め、その知見を顧客環境へ展開するという順番を守っています。機密データを扱う設計は、外部のベンダーに丸投げして安心できるものではなく、自社が先に痛みを引き受けて初めて言葉に説得力が出るものだと考えています。

硬いデータと柔らかいデータを分ける、という発想

私たちは顧客のデータを、基幹システムに入っている「硬いデータ」と、AIが活用する「柔らかいデータ」に分けて整理します。基幹システムの横にデータ空間を設け、バッチでコピーする「仮想のブロックエリア」という方式です。この設計であれば、AIはインフラを選ばず、オンプレでもクラウドでも、閉域環境でも動きます。RAG(社内のドキュメントをAIに読み込ませて回答精度を上げる技術)で社内ナレッジの機密情報を扱う際も、この分離が土台になります。

基幹システムを直接AIに触らせないことは、セキュリティの話であると同時に、精度の話でもあります。硬いデータをそのまま渡すと、AIは構造化されていない情報の中から答えを探す作業を、毎回一から背負うことになります。あらかじめ柔らかいデータ空間に整理してから渡すことで、AIは「探す」作業から解放され、「判断する」作業に集中できます。実際に基幹システムの刷新を検討する企業では、既存データベースへ直接手を入れることへの警戒感が強い。この分離設計への関心は高いと感じています(関連記事: 「触れない基幹システム」をAIエージェントで刷新する)。

業界で先を行く製薬各社にも、共通する型がある

塩野義製薬だけが特別というわけではありません。小野薬品工業はAzure OpenAI Serviceを自社環境に閉じ込め、RAGを使った40のビジネスケースを本番運用しています。住友ファーマは情報が二次利用されない独自環境を開発し、機密性の高い業務データを扱える設計にしました。中外製薬もRAGを用いた文書検索システムを構築し、SOP検索やメディカルライティング支援に活用しています(DXC Technology)。

3社に共通しているのは、パブリックな生成AIサービスにそのままデータを渡していない点です。自社環境に閉じた構成を作り、その中でRAGやAIエージェントを動かしています。「クラウドAIに預けるか、諦めるか」の二択ではなく、「自社の管理下でどう精度を上げるか」という第三の道を選んでいる。私たちがソブリン環境でのローカルLLM(自社のサーバー内で動かす大規模言語モデル)活用に注力しているのも、同じ理由からです。顧客のR&D部門ではデータの機密性が極めて高く、クラウドAIでは対応できない案件が増えています。

製薬業界に限った話ではありません。ある特注プラントメーカーでは、全部をAIに任せるのではなくノウハウを共有しながら二人三脚で作りたいという声があり、自社サーバーでローカルLLMを動かす検証にすでに着手していました。機密性の高いデータを扱う現場ほど、自社の管理下に閉じた環境を持ちたいという発想に自然と行き着くようです。私たちの現場経験でも、こうした要望は製造業・製薬業を問わず増えています。

それでも、機密データをAIに渡してはいけない場面もある

誤解のないように言えば、あらゆる機密データをAIに渡すべきだとは考えていません。取引条件に関わる金額情報や個人の識別情報のように、渡した瞬間に取り返しがつかない情報は、そもそもAIの入力対象から外すべきです。私たちが顧客に提案する際も、金額情報には一切答えないというガードレールを最初に設定します。

また、この手法は導入初期のフェーズには向きません。データの整理や権限設計ができていない段階でAIに機密データを渡すと、精度どころか事故のリスクが先に立ちます。私たちの現場では、まずデータベースをいじらない範囲から内製を始め、PRベースでAIにレビューさせながら少しずつ触れる領域を広げるという順番を徹底しています。1つのブランチをどれだけ試行錯誤で汚しても、データベースさえ直接いじらなければ大きな事故には至りません。

本番への反映も一段飛びにはしません。先にステージング環境で直し、回帰テストが通ってから本番に出す二段階を徹底しています。AIが作った基盤側の穴は自社運用の中で先に潰してから、顧客環境に展開する。機密データを扱う設計は、1回作って終わりではなく、この確認の繰り返しの中で精度と安全性の両方が育っていくものだと私たちは考えています。

もう1つ、避けるべきなのが「バラバラに作る」ことです。ある大手建材メーカーの情報システム部長は、複数システムを別々に作る方針について、最適なやり方とセキュリティ要件を見定めないと一時の投資で終わってしまう、と警戒していました。機密データを扱う仕組みを部署ごとに個別発注してしまうと、権限設計もログの取り方も揃わず、あとから統合するコストの方が高くなります。最初にどこまでを共通基盤にするかを決めておくことが、結果的に精度と安全性の両方を守ります。

よくある質問

Q. 機密データをAIに渡すと、学習データとして外部に流出しませんか。 A. パブリックな生成AIサービスにそのまま入力すれば、そのリスクはあります。自社環境に閉じたRAG構成や、マスキングした上での学習に限定するといった設計で、この懸念は回避できます。

Q. どこまでのデータならAIに渡してよいのでしょうか。 A. 金額情報や個人識別情報のように取り返しがつかない情報は対象外にします。実験データや仕様書のような「解き方の材料」になる情報から始めるのが現実的です。

Q. 小規模な会社でも、この設計は導入できますか。 A. できます。まずは基幹システムに触れない範囲でデータ空間を分け、1つの業務から検証を始めるアプローチが、規模を問わず有効です。

Q. 情報システム部門だけでは対応が難しい場合、何から手を付けるべきですか。 A. 全社展開の前に、まず1つの部署・1つの業務に絞って、渡す情報と渡さない情報を線引きする棚卸しから始めるのが現実的です。範囲を絞ることで、権限設計やテストの負荷も現実的な規模に収まります。

まず試すなら

1. 社内で「触らせていないデータ」を一覧化する。 機密だからという理由だけで検討すら止めているデータがどれだけあるか、まず棚卸しします。
2. 1つの機密データセットで、渡す情報と渡さない情報を線引きする。 金額情報や個人名は除外し、判断材料だけを抽出できるか試します。
3. AIエージェントに複数の検索手段を持たせてみる。 1つの検索方法に固定せず、状況に応じて手段を切り替える設計が、正答率向上の第一歩になります。

自社のどのデータが「精度の材料」になり得るか、社内だけでは見えにくいものです。私たちは無償の業務プロセス診断(BPR)を実施しており、データの棚卸しからAI活用の設計まで一緒に整理しています。まずは無償の業務診断で、機密データをどう扱うべきか明らかにしませんか。

参考リンク

• 塩野義製薬、生成AIの正答率を50→90％に 膨大な機密データをどう最適化した？（キーマンズネット）
• 生成AIで進化する製薬R&D業務～LLMとRAGを活用した効率化と安全性の両立（DXC Technology）
• 中外製薬: RAGを用いた文書検索や人財育成に生成AIを活用（Google Cloud 公式ブログ）