Amazon Web Services ブログ
CODAS によるデータ秘匿性を考慮した産業特化型 AI 基盤の研究開発と実装検証に関する取り組み
はじめに
生成 AI は、いまやあらゆる産業に新たな価値創出の機会をもたらす基盤技術になりつつあります。文章の作成や要約、コードの生成、問い合わせ対応、専門的な調査の補助など、これまで人手に頼っていた多くの業務を支援できるようになり、生産性向上とイノベーション創出のカギとして大きな期待が寄せられています。
その一方で、機密情報や個人情報を外部の生成 AI サービスに入力することへの懸念から、本格的な活用に踏み切れない企業も少なくありません。総務省の調査によれば、約 7 割の企業が AI 活用における「セキュリティリスク」を懸念しており、産業データの活用が十分に進んでいないことが課題として指摘されています(出典:総務省「令和 6 年版 情報通信白書」)。つまり、生成 AI の可能性は広く認識されている一方で、「安心して自社のデータを預けられるのか」という信頼の問題が、活用の大きな壁になっています。
一般社団法人 AI データ主権共創機構( CODAS : Co-creation Organization for Data Sovereignty & AI)はこの課題の解決策として日本発の「信頼できる AI」の構築を目指しています。 CODAS は「秘匿性を基盤とした産業特化型 AI 基盤の研究開発・実装・実証」に取り組む共創組織であり、企業・研究機関・行政が対等に参画しながら、日本の産業競争力の強化とデータ主権の確保を目的としています。AWS は、その研究開発を支える大規模言語モデル(LLM)の学習・推論基盤の構築をご支援しています。
この取り組みは、国立研究開発法人 新エネルギー・産業技術総合開発機構(NEDO)の「ポスト 5G 情報通信システム基盤強化研究開発事業/データの秘匿性を考慮した効率的な AI 学習手法の開発」の一環として進められています。同事業では、生成 AI の性能向上を支えてきたウェブ上の公開データが学習し尽くされつつあるなか、今後の AI 開発においては企業や組織が保有する実データを安全に活用することが不可欠になる、という認識が背景にあります。しかし、実データの多くは個人情報や機密情報を含むため、データの秘匿性を考慮した学習手法の確立が重要な課題として掲げられています。
本ブログでは、 CODAS が目指す世界と、そのビジネス的な意義、そして、その実現に向けた第一歩として現在取り組まれている産業特化型 LLM の構築と、それを支える AWS 上の学習・推論基盤についてご紹介します。なお、本記事でご紹介するのは、 CODAS の活動のあくまで初期段階における取り組みのみです。 CODAS の構想はこの先、秘匿性技術の研究開発から社会実装、さらにはグローバルなエコシステム形成へと大きな広がりを見せていく予定であり、本記事はその出発点をお伝えするものとご理解いただければ幸いです。
CODAS が目指す、データ秘匿性を考慮した産業特化型大規模言語モデルの構築
なぜ「秘匿性」なのか
現在広く使われている汎用的な生成 AI は素晴らしい技術である一方、機密情報や個人情報の取り扱いという観点では、企業に大きな懸念を残しています。 CODAS は、この課題を大きく 3 つのリスクとして整理しています。
第一に、機密情報・データの流出リスクです。企業が外部の AI サービスに機密データを入力する場合、サービスの利用条件や設定に応じて、入力データの保存場所、保持期間、学習への利用有無などを十分に確認する必要があります。企業にとって、顧客データ、取引情報、技術情報といった競争力の源泉が、意図せず外部に流出するリスクは看過できません。
第二に、プライバシー侵害とデータ主権の喪失リスクです。学習データからの個人特定(メンバーシップ推論攻撃や学習データの再構成など)や、自社データが管理の及ばない環境で処理・保存されることへの懸念があります。加えて、各国でデータ保護規制が強化されるなか、データを国内で管理し、規制に準拠しながら活用することの重要性が高まっており、規制対応の負担も増しています。データがどこにあり、誰がアクセスでき、有事にも継続的に利用できるのかという「データ主権」は、経営レベルの論点になりつつあります。
第三に、こうした懸念が日本企業を AI 活用に踏み切れなくさせている、という現実です。一般社団法人 日本情報システム・ユーザー協会(JUAS)の調査では、企業が AI 活用で懸念するリスクとして、データ漏洩リスク(70.3%)、AI の誤回答リスク(65.2%)、プライバシー侵害リスク(65.0%)、法令違反リスク(50.5%)が挙げられています(出典:JUAS「企業 IT 動向調査 2025」 )。懸念が先に立つことで、本来であれば大きな価値を生むはずのデータ活用が後回しになってしまう。この「もったいない」状況こそ、 CODAS が解こうとしている課題です。 CODAS は、この状況に対して「データは動かさない、モデルが動く」(Privacy-First AI)という発想の転換を掲げています。データを外部に送り出すのではなく、データが自社の管理下に留まったままで AI を活用できる世界を目指すものです。この発想は、単に情報漏洩を防ぐという守りの意味にとどまりません。これまで秘匿性への懸念から活用が進まなかった高価値なデータを、安心して AI に活かせるようにすることで、日本企業のデータ活用そのものを前に進める攻めの一手でもあります。守りと攻めを同時に成立させる。ここに、秘匿性を基盤とする AI のビジネス的な意義があります。
ロードマップと現在のフェーズ
CODAS の最終目標は、データ漏洩防止、プライバシー侵害耐性、データ主権の確保といった秘匿性を担保しながら、産業の実務に耐えうる高性能な AI を実現することです。差分プライバシーや秘密計算などの秘匿性技術と、産業に特化したモデルを組み合わせることで、汎用モデルにはない「信頼性」と「専門性」の両立を目指しています。秘匿性を高めるほど性能とのトレードオフが生じやすいため、この両立には継続的な研究開発と強固な計算基盤が欠かせません。
秘匿性技術は、適用先となる高性能なベースモデルがあって初めて実証・評価できます。そのため CODAS は、まず秘匿性研究の土台となる産業特化型大規模言語モデルを構築し、その上で秘匿性技術の研究開発を積み上げるアプローチを取っています。
このベースモデルは領域特化の高度な処理を担い、各企業のユースケースに特化した個社モデルと連携する 2 層構造を想定しています。特に、情報漏洩リスクへの懸念から慎重な判断が求められる金融・保険領域を最優先の実装領域と位置づけ、社会実装の標準を確立することを目指しています。また、特定のモデルに依存しない開発手法を採用し、今後さらに高性能なモデルが登場しても柔軟に取り入れられるようにしています。 CODAS では、大学や専門企業が秘匿性技術に関する複数の研究テーマを分担しています。ベースとなる LLM の開発は ABEJA 様が担い、AWS は大規模なモデル学習を支える計算基盤の構築を支援しています。各研究テーマ、ベースモデル、計算基盤を組み合わせる体制が、 CODAS の挑戦を支えています。
産業特化型大規模言語モデルの学習と評価に関する取り組み
産業特化型大規模言語モデル開発の第一段階として、 CODAS では、パブリックデータをベースとした大規模コーパスの構築、教師付きファインチューニング用データセットの合成、継続的事前学習と事後学習(教師付きファインチューニングおよび強化学習)、学習済みモデルの評価に取り組んでいます。本節では、こうした学習・評価の考え方と主な検証内容を紹介します。
(1) 学習済みモデルの評価
モデルの性能は、日本語・英語それぞれにおける汎用的な能力と、金融分野に特化したタスクを遂行する能力の両面から評価します。このため、複数のパブリックデータセットを選定し、必要に応じて対象タスクに合わせた改修を行いました。
評価には、正解との一致を確認する機械採点に加え、自由記述など単純な正誤判定が難しいタスクに対応するため、LLM-as-a-Judge を用いています。これにより、モデルが金融領域の知識を獲得しているかだけでなく、汎用的な言語能力を維持できているかを継続的に確認します。
(2) 大規模コーパスの作成と事前学習
継続的事前学習に向けて、対象領域の知識を取り込むための大規模コーパスを準備しています。コーパスの品質や構成は、その後のモデル性能に大きく影響するため、データの収集・整形・選別を行ったうえで学習に用います。
また、学習の実施を通じて、データ構成や学習条件がモデルの汎用能力および金融関連タスクの性能に与える影響を検証しています。
(3) 学習用データセットの合成と教師付きファインチューニング
事後学習では、教師付きファインチューニング(Supervised Fine-Tuning、SFT)に用いる学習データセットを、生成 AI モデルを活用して合成しています。金融関連タスクの性能を高めながら汎用的な能力も維持・向上させるため、金融特化型データセットと汎用データセットを組み合わせます。
検証では、学習対象モデルの系統を考慮し、SFT 用データの生成に用いるモデルの違いが、SFT 後の性能に与える影響を分析しています。あわせて、金融特化型データと汎用データの配合を変え、汎用能力と金融関連タスクの遂行能力をバランス良く最適化する方法を検討しています。
(4) 強化学習による論理的能力の強化と指示追従能力の回復
SFT に加えて、論理的能力の向上を目的とした強化学習(Reinforcement Learning、RL)にも取り組んでいます。強化学習では数理的能力の向上に加え、SFT 後に生じ得る指示追従能力の低下、特に指示に含まれる出力制約を守る能力の低下を改善することを目指します。
評価の結果、SFT 後に実施する強化学習が、こうした指示追従能力の回復に寄与することを確認しました。モデルの能力を単一の指標で評価するのではなく、論理性、指示追従性、専門領域のタスク性能を総合的に捉えながら、学習方法を改善しています。
データセットの構成、実験条件、評価方法、詳細な結果については、今後 ABEJA 様の技術ブログにて公開予定です。
合成データの作成、産業特化型大規模言語モデルの学習、および、学習済みモデルの評価を実行するためには、GPU を含む大規模計算機リソースが必要となります。また、多くの GPU を用いて効率的に分散学習を行うには、ストレージ・ネットワーク通信の観点でも検討すべき事項があります。さらに、安全に開発を進めるうえでは権限周りの管理・運用も不可欠です。 CODAS では、産業特化型大規模言語モデル構築のための学習・推論基盤として、72 台の p5en.48xlarge EC2 インスタンスをコンピュートノードとして利用する、AWS ParallelCluster を用いた大規模 GPU クラスターを AWS 上に構築しています。次章では、AWS 上でのモデル学習・推論基盤の構築について紹介します。
AWS 上で実現する大規模言語モデル学習・推論基盤
大規模学習基盤の設計方針
大規模言語モデルの学習・推論基盤を構築するには、GPU の計算性能だけでなく、ノード間通信、共有ストレージ、ジョブ管理、監視を一体として設計する必要があります。そのために CODAS が初期構築の出発点としたのが、AWS Labs のオープンソースである awsome-distributed-ai(旧称 awsome-distributed-training)です。同リポジトリでは、大規模モデル学習向けのリファレンスアーキテクチャ、学習用サンプル、検証・オブザーバビリティ用ツールをまとめたものをオープンソースで提供しています。
学習・推論基盤の実装時には、awsome-distributed-ai リポジトリに含まれるリファレンスアーキテクチャを VPC、共有ストレージ、Elastic Fabric Adapter(EFA)、Slurm といった分散学習基盤の主要な構成要素を構築するための出発点としました。これにより、一からすべて自分たちで組み立てるのではなく、複数のチームで GPU クラスターを共同利用する際のロールや権限、接続方法、安定運用のための設計を含む、独自の要件に関する議論と実装に注力しやすくなりました。リファレンスアーキテクチャはあくまで汎用的なものです。そのため、そのまま採用するのではなく、実際の用途と運用体制に合わせて、不要な要素の削除や、安全性向上などを目的として必要な仕組みを追加実装することが重要です。
学習・推論基盤の全体像
クラスターの構築と管理には AWS ParallelCluster を利用し、ジョブスケジューラーとして Slurm を採用しています。ヘッドノードは Slurm のスケジューリングとクラスター制御を担っています。ユーザーは別途立ち上げたログインノード上で通常のコーディング作業やジョブ投入、コンテナの準備などを実施することが可能です。学習ジョブは EFA を備えた GPU コンピュートノード上で実行し、Enroot と Pyxis を組み合わせて、Slurm からコンテナ化した学習環境を起動しています。現在は NVIDIA H200 を 8 基搭載した p5en.48xlarge GPU インスタンス 72 台をワーカーノードとする規模までスケールしています。
ストレージは役割に応じて使い分けを行っており、学習データやチェックポイントを扱うための高性能な共有領域には Amazon FSx for Lustre、ホーム領域には Amazon FSx for OpenZFS を採用しています。また、Amazon S3 と FSx for Lustre は Data Repository Association(DRA)で連携しています。主要コンポーネントとデータの流れを 図 4 のアーキテクチャ図に示します。
図 4: AWS ParallelCluster と Amazon EC2 GPU インスタンスを用いて構築した大規模言語モデル用学習・推論基盤のアーキテクチャ図
組織独自の要件を仕組みに落とし込む
大規模 GPU クラスターを複数のチームで継続的に利用するには、GPU やネットワークの性能だけでなく、誰が、どのように、安全に利用できるかをあらかじめ設計しておくことが重要です。そこで、本環境ではクラスターへのユーザーアクセスを AWS Systems Manager Session Manager に一本化し、SSH キーペアを前提としない構成を採用しています。さらに、SSH キーペアが設定された場合にはクラスターのデプロイを失敗させることで、意図せずアクセス方針から逸脱した構成になることを防ぎます。IAM 権限についても、構築・運用に必要な権限を整理し、最小権限の原則に沿って設定しています。
ノードごとに役割を明確に分離している点も、この基盤の特徴です。ヘッドノードは Slurm のスケジューリングとクラスター制御に専念させ、日常的なコーディング、コンテナの準備、ジョブ投入はログインノードで行います。これにより、ユーザーの作業がクラスター制御に影響することを抑え、安定した運用につなげます。複数のチームが利用する環境では、チームごとにログインノードのプールを用意しつつ、全ノードのユーザー ID(UID)とグループ ID(GID)を統一的に管理します。共有ファイルシステム上の所有権と Slurm が認識する利用者を整合させることで、チームをまたぐデータセットやモデルの共同利用も可能にしています。
また、コンテナのビルドは一時的に大きなディスク負荷を発生させるため、ログインノードのルートボリュームに負荷が集中しない設計としています。ルート EBS ボリュームの容量を確保するとともに、成果物は FSx の共有ストレージに配置します。ローカル NVMe を利用する処理については、Slurm デーモンの起動前に NVMe の準備とマウント元の検証を完了させます。想定したストレージを利用できない場合には処理を停止することで、不完全な状態でノードが起動することを防ぎます。
異常の早期顕在化と計測に基づく運用
大規模分散学習では、単一ノードの異常やストレージ容量の不足、ネットワーク通信の不調が、学習ジョブ全体の性能や成否に影響します。そのため、Amazon CloudWatch、Amazon Simple Notification Service(Amazon SNS)、AWS Lambda、Slack を組み合わせ、FSx for Lustre の容量しきい値超過や GPU の故障を自動的に通知する仕組みを設けています。クラスターの利用者と管理者は必要な状況を速やかに把握し、ストレージの拡張やノードの切り離しといった対応を判断できます。
ノード間通信では、コンピュートノードの構成時に EFA デバイスの存在だけでなく、EFA プロバイダーを実際に利用できることまで確認します。検証に失敗した場合は、診断に必要なログを残してデプロイを停止します。こうした事前検証により、ジョブは実行できても通信性能が十分に出ないという発見しにくい問題を、学習開始前に検出できます。
ストレージについても、推測ではなく実測したメトリクスに基づいてボトルネックを切り分け、必要に応じて容量をスケールさせる運用としています。ノード障害、通信、ストレージのいずれも例外として扱うのではなく、発生を前提に検知・判断・対応できるようにしておくことが、大規模 GPU クラスターの継続的な利用には不可欠です。
ここまで紹介した工夫に共通するのは、運用上のルールや障害時の対応を手順書にとどめず、クラスターのデプロイや起動の過程で自動的に確認できる仕組みとして実装している点です。リファレンスアーキテクチャを出発点にしながら、組織の利用形態や実運用で得られる知見を構成へ反映し続けることで、複数チームが大規模言語モデルの学習・推論基盤を安定して共同利用できる環境を目指しています。
おわりに
本ブログでは CODAS によるデータの秘匿性を考慮した AI 学習手法の開発に関する大規模言語モデル学習・推論基盤の構築に向けた取り組みについて紹介しました。上述の通り、本ブログで紹介した内容は CODAS による初期段階の取り組みの一部に関するもののみであり、 CODAS の活動は今後さらに大きく広がりを見せていく予定です。AWS では CODAS 担当アカウントチーム、コンピュート・生成 AI スペシャリストチーム、生成 AI イノベーションセンターなど、複数のチームが一丸となって、 CODAS の本活動に対する支援を行っています。









