AWS を活用した公共部門向け大規模言語モデルの構築

本記事は 2025 年 10 月 27 日に AWS Public Sector Blog で公開された Building large language models for the public sector on AWS を翻訳したものです。翻訳はソリューションアーキテクトの川戸渉が担当しました。

大規模言語モデル (Large Language Model, LLM) は、公共機関によるサービス提供、市民とのエンゲージメント、データに基づく意思決定の方法を根本から変えています。高度な多言語対応と複雑なタスクの自動化により、LLM は応答時間を短縮し、ドメイン固有の情報を大規模に処理することが可能になります。

既製のモデルは確かに強力ですが、公共機関特有の規制要件、文化的背景、業務上の条件を十分に満たすことができないケースが少なくありません。多くの商用 LLM は、インターネット全体から収集された幅広いデータセットで学習しているため、特定の国や分野における言葉のニュアンス、文化的文脈、法規制の枠組みを適切に反映していないことがあります。また、これらのモデルは学習データに含まれるバイアスを引き継いだり、専門用語の知識が不足していたり、データ主権やプライバシー保護の要件を満たせない環境で動作したりする課題があります。正確さ、コンプライアンス、信頼性が極めて重要な公共機関にとって、これらの制約は市販モデルをミッションクリティカルな用途で使用する上での限界となっています。カスタム LLM 開発はこれらの課題に対処します。ゼロからのモデル学習、既存モデルの継続事前学習、事前学習済みモデルのファインチューニングによって、言語やドメイン固有の知識を取り込み、地域の法規制に準拠し、文脈に応じた微妙なニュアンスにも対応できるようになります。

公共部門のミッションに特に関連する 2 種類のカスタム LLM があります :

ナショナル LLM は、特定の国や地域の言葉の使い方、文化的背景、法規制の枠組みを反映するように構築されたモデルです。地域言語の保全、文化に適した回答の生成、国のデータ主権要件への準拠を可能にします。顕著な例として、ギリシャの取り組みがあります。これは商用モデルにおけるギリシャ語の過小表現に対処し、現代および古典ギリシャ語の言語遺産を保全するオープンウェイト LLM (モデルの重みパラメータが公開された LLM) の開発を進めている事例です。
ドメイン特化型 LLM は、医療、教育、金融、法務などの高度に専門化された分野向けに最適化されたモデルです。専門性の高い業務においてより高い精度と、分野固有の専門用語もしっかりと理解できます。これらのモデルは、品質と適切性を保ちながら、ドメインに特化することで専門的なコア業務をどれだけ向上させられるかを示しています。

このブログ記事では、公共部門での活用を想定したカスタム LLM の開発について、科学的アプローチと定量的な成果評価を軸に、そのライフサイクル全体を解説します。開発プロセスは 6 つの重要なステージで構成されています。各ステージは、セキュリティ、コンプライアンス、パフォーマンスの厳格な基準を満たしながら、モデルが本来の目的を確実に果たせるように設計されています。

コスト分析フレームワーク

カスタム LLM 開発に着手する前に、2 つのレベルでコストを評価する必要があります。マネージド API のトークン単価と、セルフホスティングの総保有コスト (Total Cost of Ownership, TCO) です。

マネージド API は迅速な導入に適していますが、トークン課金とデータ転送コストにより、規模が大きくなると高額になる可能性があります。一方、セルフホスティングでは、初期投資（GPU 調達や予約容量、エンジニアリングリソース）に費用がかかりますが、時間の経過とともにトークンあたりの運用コストは下がります。

モデルサイズはコストに大きく影響します。一般的に、パラメータ数が多いほど、一定レベルまで品質が向上しますが、応答時間、メモリ使用量、学習・推論コストも増加します。継続事前学習や目的特化型のファインチューニングによってモデルサイズを調整することで、コストを抑えながら同じレベルの性能を実現できます。

適切なデプロイ方法を決定するには、まず 1 日あたりのトラフィック (トークン / 日)、季節変動、目標応答速度、システムの可用性要件を把握する必要があります。その上で、API 利用料の累計がセルフホスティングの TCO (機器の減価償却費、電気代、運用費を含む) を超えるポイントを計算することで、データに基づいた選択ができるようになります。多くの公共機関では、自組織のクラウド環境で運用する中規模の調整済みオープンソースモデルが最も適した選択肢となります。これにより、データレジデンシー (データが保存される地理的な場所) 要件を満たしながら、より少ない GPU で目標の応答速度を実現し、初期投資の後は長期的な運用コストを抑えることができます。

カスタム LLM 開発のプロセス

カスタム LLM の開発ステージは以下の通りです：

ユースケースと要件の定義
評価フレームワークの確立
モデル選択と学習アプローチ
データ収集と準備
インフラストラクチャ構築と学習アプローチ
本番環境へのデプロイと性能テスト

各ステージは、公共部門が求めるセキュリティ、コンプライアンス、性能基準を満たしながら、モデルが意図された目的を効果的に果たすための基盤となります。

ステージ 1: ユースケースと要件の定義

カスタム LLM 開発は、厳密な要件定義から始まります。これは、組織のハイレベルな目標を具体的で測定可能な仕様に落とし込む作業です。このステージでは、カスタムアプローチが必要なのか、それともプロンプトエンジニアリングのみで目標を達成できるのかを決定します。

カスタムアプローチは通常、プロンプトエンジニアリングを複数回試行しても一貫して許容できる結果が得られない場合、既存のモデルでは特定の言語要件を満たせない場合、または標準的なプロンプト技術では確実に活用できない深い専門知識を必要なユースケースがある場合に必要となります。

要件定義プロセスは、カスタム LLM が明確な価値を提供する具体的なユースケースを特定することから始まります。政府機関では実用的な活用方法を検討する必要があります。例えば、市民参加型プラットフォーム、政策分析システム、専門的な研究ツール、行政業務の自動化などです。最近の事例からも、このステージの重要性がよくわかります。ギリシャのナショナル LLM プロジェクトでは、現代ギリシャ語と古代ギリシャ語の両方を処理しながら、英語でも高い性能を維持するという明確な要件を定義し、公共部門のさまざまな分野での活用を可能にしました。

組織は、明確な成功指標を設定する必要があります。具体的には、サービス提供時間の定量的な改善、専門タスクの精度、市民満足度スコアなどが挙げられます。技術要件については、目標応答時間、想定されるクエリ量、既存の行政システムとの統合ニーズに対応する必要があります。

また、包括的なデータ処理プロトコル、アクセス制御、監査要件の定義も不可欠です。ナショナル LLM の場合、データ主権に関する要件やローカルホスティングの要件が含まれることが一般的です。ドメイン特化型モデルでは、医療、金融、その他の機密性の高い分野における専門的な規制への準拠が求められる場合があります。

これらの要件を文書化することで、ステークホルダーに対してビジネス価値を効果的に伝えられるだけでなく、技術チームには明確な開発ガイドラインを提供できます。この文書化は、複数の政府部門や機関間での調整を行う際に特に重要であり、技術的能力と組織ニーズの整合性を確保する上で欠かせません。

ステージ 2: 評価フレームワークの確立

モデル選択前にしっかりとした評価フレームワークを確立することで、開発プロセス全体を通して科学的な厳密さと測定可能な成果を確保できます。このフレームワークは、その後のすべての意識決定の基盤となり、主観的な選択によってプロジェクトが失敗するリスクを防ぎます。

ベースライン性能と適応率の指標

モデル選定と学習の決定を左右する 2 つの重要な指標があります :

ベースライン性能 (b): 候補モデルをカスタマイズする前の、タスクおよびドメイン固有の評価スコアです。固定プロンプトと別途用意した開発 / テスト用データセットを使用します。これにより、異なるベースモデルを客観的に比較する基準が得られます。
適応率 (ra): カスタマイズ中にモデルが評価指標をどれだけ速く効率的に改善できるかを示す指標で、学習の進捗 (ステップ数、トークン数、時間、コスト) で正規化されます。この指標により、限られた予算内で継続学習に最も適したモデルを予測できます。

評価ツールと実装

Language Model Evaluation Harness (LM Harness) は、LLM 評価の業界標準ツールです。60 以上の学術的ベンチマークと数百のサブタスクおよびバリアントでモデルをテストできる統一フレームワークを提供してます。LM Harness は、Hugging Face transformers、高速推論用の vLLM、商用 API など、さまざまなモデル環境に対応しており、異なる実装でも同じ条件で比較できます。

AWS を中心としたワークフローでは、LM Harness を AWS が提供する評価ツールで補完しながら、業界標準との互換性も保てます。LM Harness を基盤とする Hugging Face Open LLM Leaderboard では、さまざまなタスクと言語での標準化された性能比較が提供されており、ナショナル LLM 評価の優れた参考資料として活用できます。

Q&A データセット生成と検証プロセス

高品質な評価データセットを作るには、自動生成と人間による検証を組み合わせた体系的なアプローチが必要です :

スコープとコーパスの定義 : 優先度の高いユースケース、ドメイン、言語をリストアップします。文書、政策、FAQ、ナレッジベースから代表的で高品質なコーパスを収集し、適切なクリーニング、重複除去、個人識別情報 (personally identifiable information, PII) の除去を確実に行います。
ベースライン生成器の確立 : 候補モデル間で簡単な評価を実行し、対象言語とドメインに最適な生成器を選択し、自己評価バイアスを回避します。
プロンプトテンプレートの作成 : スタイル、難易度、回答形式、根拠要件を決めます。事実に基づく Q&A、多段階推論、政策準拠、多言語シナリオのバリエーションを作成します。
パイロット生成 (100-300 項目) : ベースラインモデルを使用してコーパスから Q&A ペアを生成し、すべてのドメイン、難易度、言語を比例的にカバーします。各項目に来歴メタデータをタグ付けします。
人間による検証ループ : 正確性、根拠、明確性、安全性について項目をサンプリングしてラベル付けします。問題を修正し、エラーパターンを文書化します。受入基準を計算します (目標は 90% 以上の正確性、根拠) 。
品質と安全フィルター : NVIDIA NeMo Curator などのツールを使用して、重複排除、定型文の削除、パープレキシティフィルタリング、PII チェックの自動パスを適用します。
生成のスケール化 : 固定されたテンプレートとモデルで完全な Q&A データセットを生成し、学習 / 開発 / テストの分割全体で厳密なメタデータとバージョン管理を維持します。
検証の強化 : 層別サンプルに対する人間による監査を実施し、敵対的ケースと安全性シナリオを追加します。

性能測定フレームワーク

評価は複数の側面から検証する必要があります：

言語習熟度と文化的正確性
政府のユースケースにおけるタスク固有の性能
規制および倫理ガイドラインへの準拠
応答の適切性と安全性
計算効率とリソース使用率

モデルが性能目標を満たし、コンプライアンス要件を満足するまで、最適化フェーズに結果をフィードバックする反復的な評価プロセスを実装する必要があります。

ステージ 3: モデル選択と学習アプローチ

評価フレームワークを確立した後、モデルアーキテクチャと学習戦略について重要な決定を行う必要があります。これらの決定は、問題のスコープ、現在のモデル性能、セキュリティ要件、必要なカスタマイズレベルによって左右されます。

学習アプローチの決定基準

主に3つの選択肢があり、それぞれ異なるメリットとリソース要件があります。

ファインチューニングは最もリソース効率の良いアプローチで、事前学習済みモデルをドメイン固有のデータで追加学習させます。この手法は、対象ドメインが事前学習データと類似している場合や、リソースが限られている場合に適しています。ファインチューニングでは、特定の指示に対してモデルがどう応答すべきかの例を使うインストラクションファインチューニングや、人間のフィードバックを活用した強化学習 (Reinforcement Learning from Human Feedback, RLHF) などの技術により、モデルを人間の好みにより合わせることができます。
継続事前学習 (Continued pretraining, CPT) は、一般的な能力を保ちながら、既存のベースモデルを追加データで学習させる方法です。このアプローチは、基本的な理解力と推論能力を維持しながら、モデルを新しい言語やドメインに効果的に適応させます。ゼロから学習するよりも少ないデータで済みますが、ファインチューニングよりは多くのデータが必要で、高品質なデータによる 2 段階の学習により、未知の質問に対してもより良い対応力を提供します。具体的には、CPT はまずベース知識を保ちながらモデルを新しいドメインや言語に適応させ、次に特定能力の向上に集中することで、より安定して汎用性の高い性能を実現します。
ゼロからの学習は、モデルアーキテクチャと機能を完全にコントロールできますが、既存のベースモデルをカスタマイズするよりもはるかに多くの計算リソースと高品質データが必要です。このアプローチは、既存モデルが対象言語を適切に扱えない場合や、特定のコンプライアンス要件を満たせない場合に必要となります。

予想されるアクセス量、応答速度の要件、ハードウェアコストを考慮して、API 利用料がセルフホスティングの TCO を上回るポイントを計算する必要があります。TCO 分析では、初期費用と運用費の両方を慎重に評価する必要があります。運用費は主にモデルのホスティング要件によって決まり、パラメータ数が多く GPU 計算需要の大きなモデルは、一定のユーザーアクセスと帯域幅を前提として、時間の経過とともに比例的に高い運用コストにつながります。意思決定では、サービス提供の制約内で主要性能指標を達成する最小のモデルを優先すべきです。これは、初期学習でのコスト削減とホスティング費用およびリソース要件の削減により、長期的な運用持続可能性に直接影響するためです。

ベースモデルがプロンプトにより目標性能の約 80 %を達成し、ラベル付きタスクデータが利用可能な場合はファインチューニングを選択してください。ドメインや言語のカバー範囲が不十分だが、大規模なラベルなしドメイン内コーパス (10-1000B トークン) が存在する場合は継続事前学習 (CPT) を選択してください。適切なベースモデルが存在せず、組織が兆単位のトークン学習インフラをサポートできる場合のみ、ゼロからの学習を検討してください。

主要な要因には、コストと時間の制約 (API 対 GPU 時間) 、サービング要件 (応答速度 / メモリ) 、データレジデンシーの要件、リスク許容度 (破滅的忘却 : 新しい学習によって以前の学習内容が上書きされてしまう現象) が含まれます。CPT またはファインチューニング後に主要性能指標を満たす最小のベースモデルを選ぶべきで、その決定はベースライン性能 (b) と適応率 (ra) 曲線によりを検証する必要があります。

モデルアーキテクチャの検討事項

ファインチューニングや CPT を検討している組織には、出発点として使えるオープンソースモデルがいくつかあります。モデルの選択は、希望するモデルサイズと必要な計算能力、対応したい言語、モデルの初期性能などの技術的な要素によって決まります。

さらに、モデルのアーキテクチャ (例 : Transformer ベースの設計や Expert Parallelism)、対応する情報の種類 (テキストのみか、マルチモーダルか)、パラメータ数、そしてこれらの選択が学習に必要なリソースと本番環境での推論性能にどう影響するかを考慮する必要があります。

ステージ 4: データ収集と準備

データ収集と準備は、カスタム LLM 開発において最も重要なステージです。特に、データの品質、関連性、セキュリティが重要な公共部門での利用では、なおさら重要になります。このアプローチは、選択したモデルアーキテクチャと学習戦略によって大きく変わります。

NeMo Curator による包括的データパイプライン

NVIDIA NeMo Curator は、大規模な事前学習とファインチューニング用コーパス向けに設計された、データ整理の統合ツールキットです。このモジュール式パイプラインシステムは、Spark、Ray、Dask を使った分散処理に対応し、データのダウンロードから抽出、クリーニング、フィルタリング、重複除去、分類まですべてを処理します。

NeMo Curatorの主要機能は以下の通りです :

データ取り込み : Web クローリング、Common Crawl 処理、データレイク連携、文書解析 (レイアウトヒューリスティクスを使用した PDF からテキストへの変換)
データ正規化 : Unicode / NFKC 処理、空白と句読点の標準化、定型文とテンプレートの削除
安全性と PII 処理 : 設定可能な編集 / 削除ポリシーと国 / 分野別のコンプライアンス設定を持つ正規表現と機械学習ベースの検出器
高度な重複除去 : 文書・段落レベルでの完全一致ハッシュマッチング (MinHash/SimHash) とファジー近似重複検出 (LSH)
品質フィルタリング : 言語識別、長さ / パープレキシティ境界値、n-gram / ストップワード比率、有害性 / 安全性スコアリング
分類とタグ付け : ドメイン / トピックのラベル付け、文書構造分析、管轄 / 言語タグ付け

重要なデータ処理要素

重複除去は複数のレベルで動作します。正規化されたテキストでの完全一致ハッシュ (SHA256) により同一文書とセグメントを削除し、近似重複検出では文書・段落レベルで LSH クラスタリングを使った MinHash/SimHash を使用します。このプロセスは、正規のコピーを保持し、保持根拠とともにハッシュクラスターを記録することで来歴を維持します。
PII 除去は複数の検出方法を使います。メール、電話番号、ID の正規表現パターン、名前と場所の辞書、人物 / 組織 / 場所エンティティの機械学習による認識、支払いと健康情報に対する特殊なパターンです。データの種類と管轄区域ごとにコンテンツを編集または削除のポリシーを設定でき、コンプライアンス検証のための包括的な監査ログを取得できます。
合成データ生成は、データが少ないドメインに対して体系的なプロセスで対処します。シード選択、スタイルと根拠制約を持つ LLM プロンプト、出力スキーマの強制 (JSON)、正規表現 / スキーマ / 有害性 / 根拠チェックによる検証、人間によるレビューサンプリング、適切な制御 (temperature / top-p 制限、長さの制限、ソース引用を含む) によるスケーリングを行います。
品質フィルタリングとパープレキシティスコアリングは複数の指標を組み合わせます。言語識別、長さ制御、ヒューリスティック測定 (ストップワード比率、記号 / 絵文字の割合)、有害性 / 安全性スコア、ドメイン適合性分類、参照言語モデルを使ったパープレキシティスコアリングにより、希少だが有効なコンテンツにバイアスをかけることなく、情報量の少ない、または劣化したテキストを特定します。

データ処理を以下の順序で実行する必要があります :

データ正規化
PII 除去
重複除去
品質フィルター
パープレキシティによるトリミング
保持率などのメトリクスを追跡しながらの分類 / 分割
重複率
PII ヒット率
パープレキシティの分布
言語 / ドメインごとのカバレッジ

データセット構成戦略

ナショナル LLM の場合、対象言語の素材、関連する言語や方言、一般知識を混合した多様なコンテンツを含める必要があります。対象言語と共に英語データを含めることには、2 つの目的があります。一般的な能力の破滅的忘却を防ぐことと、実用的なバイリンガル機能を維持することです。並列データ (両言語でのペアテキスト) は、スムーズな言語切り替えのために言語間の関係を理解するのに役立ちます。重要なのはバランスの取れた構成です。英語のデータが多すぎると対象言語の能力が低下する可能性があり、英語のコンテンツが不足すると一般知識と推論能力が損なわれる可能性があります。特定の用途に必要な場合、コードや数学テキストなどの専門コンテンツを含めることもできます。
ドメイン特化型モデルの場合、ドメイン固有のコンテンツと一般知識のバランスを保つことが重要です。ドメインデータに重点を置きすぎると、モデルが幅広い推論と言語スキルを失う可能性があり、一般データが多すぎると専門知識が希薄化してしまいます。並列データセットは、同一言語内で技術的テキストとわかりやすいテキストをペアリングすることで解決策を提供します。例えば、医療ガイドラインと患者向けの分かりやすい説明をマッチングさせて、専門用語と理解しやすい説明を結び付けることができます。

技術実装の考慮事項

トークン化手法の選択は、特に異なる文字体系やアルファベットを使用する言語において、モデル性能に重要な影響を与えます。ラテン文字の言語向けに開発された標準トークン化手法は、単語の区切りがない言語や基本トークナイザーの語彙に含まれていない文字を含む言語には効果的でない可能性があります。多言語モデルの場合、複数の言語を適切に表現する共有語彙を作成することは特に困難で、非効率なテキスト表現と性能低下を招く可能性があります。

ステージ 5: インフラストラクチャ構築と学習アプローチ

インフラストラクチャの選択は、学習効率、コスト、運用の複雑さに大きく影響します。AWS では、組織の要件と技術レベルに合わせて、さまざまな選択肢を用意しています。

コンピューティング環境の選択肢

機械学習用のキャパシティブロックを備えた Amazon Elastic Compute Cloud (Amazon EC2) は、柔軟性が高く、細かい制御ができます。これは、特定のカスタマイズが必要な組織に向いていますが、コンピューティング環境の管理における深い専門知識が必要です。Amazon EC2 は、強力な GPU を搭載したさまざまな機械学習向けのインスタンスタイプが用意されており、特定のプロジェクト要件に合わせたコスト効率のよいリソースを選べます。

トレーニングプランを備えた Amazon SageMaker HyperPod は、大規模深層学習ワークロード向けに最適化されたマネージドサービスです。自動ヘルスモニタリングやインスタンス交換などの機能により、分散学習インフラストラクチャの構築と管理を簡単にします。SageMaker HyperPod のクラスターエージェントは、障害が発生したノードを自動検出して、そのノードを交換し、ユーザーの介入なしに最後の正常なチェックポイントから学習を再開します。これは、信頼性が極めて重要な長時間実行 LLM 学習ジョブにとって特に有効です。

ネットワークとストレージの最適化

Elastic Fabric Adapter (EFA) は、マルチノード GPU 学習に最適な、低遅延、高速通信により、分散 LLM 学習の効率を大幅に向上させる高性能コンピューティングネットワークです。EFA は、カスタムビルドされたオペレーティングシステムをバイパスするハードウェアインターフェースをより、ノード間で頻繁に通信するアプリケーションを AWS 上でスケーラブルに実行できます。これにより、アプリケーションはオペレーティングシステムカーネルを経由せずネットワークハードウェアと直接通信できるため、遅延と CPU 負荷を大幅に削減します。このハードウェアへの直接アクセスは、勾配同期時の頻繁なノード間通信がボトルネックとなりがちな分散機械学習ワークロードにとって特に効果を発揮します。

データストレージとアクセス方法も、学習効率に大きく影響します。大規模学習では、AWS は長期保存用の Amazon Simple Storage Service (Amazon S3) と高性能ファイルシステムの Amazon FSx for Lustre を組み合わせるのが最適です。学習ノード間での効率的なデータアクセスを可能にします。Amazon FSx for Lustre は分散ファイルストレージ (ストライピング) を使い、ファイルメタデータと実データを物理的に分離することで高速な読み書きを実現します。Amazon S3 と Amazon FSx for Lustre 間の接続は、データリポジトリの関連付けで管理できます。

オーケストレーションとジョブ管理

選択したインフラストラクチャとチームの技術力に応じて、さまざまなオーケストレーションツールから最適なものを選べます。

SLURM 統合は、オンプレミスからの移行とクラウドネイティブなデプロイの両方に対応しています。AWS Parallel Computing Service (AWS PCS) は、SLURM をデフォルトのジョブスケジューラーとして使用し、HPC チームに馴染みのあるワークフロー管理を提供します。SLURM 設定には、GPU リソース管理 (gres.conf)、NCCL/IB 最適化、異なるタイプのジョブのサポート、共有ファイルシステムへのチェックポイントが必要です。

Amazon EKS 統合は、Kubernetes の専門知識を持つ組織に柔軟性を提供します。Amazon Elastic Kubernetes Service (EKS) のセットアップには、GPU 対応ノードグループ (p4d/p5、L4/L40S)、NVIDIA GPU Operator のインストール、ノードセレクターとテイントによる適切なスケジューリング、スケールアウト用の Karpenter、学習・推論ワークロード用のポッド優先度 / プリエンプションが必要です。

移行に関する考慮事項として、SLURM と EKS の間で移行する際は、ネットワーク性能の検証 (同等のインターコネクト性能の実現) 、スケジューラー設定の適切な対応付け (Slurm パーティション / QoS と K8s 名前空間 / ResourceQuotas のマッピング) 、チェックポイントの互換性検証、セキュリティ制御のマッピング (サービスアカウント用の IAM ロール) 、コストモデリングと段階的なロールアウト計画の策定が必要です。

学習プロセスの実装

学習プロセスは通常、PyTorch や TensorFlow などのフレームワークを使用し、複数の GPU またはノード間で分散処理を行います。このプロセスは、データの分散、結果の収集、学習結果に基づく反復サイクルのパターンに従います。

学習は、モデルが定義された性能目標を満たすまで、学習、テスト、改良を繰り返すプロセスです。これには、学習率、バッチサイズ、モデルアーキテクチャなどのパラメータを最適な性能のために調整するハイパーパラメータチューニングなどの手法が含まれます。

学習ジョブの規模、組織内の技術力、特定の性能要件、運用の複雑さと柔軟性のバランスを考慮してインフラストラクチャを選ぶ必要があります。

ステージ 6: 本番環境へのデプロイと性能テスト

LLM が性能とコンプライアンスの基準を満たしたら、本番環境への包括的なデプロイに向けて、体系的な性能テスト、インフラストラクチャの最適化、監視を行います。

本番環境の性能テストフレームワーク

さまざまな条件下でモデルの性能を検証するために、体系的な性能テストを実施する必要があります。これには、GenAI-Perf や vLLM などの業界標準ツールを使用したベンチマークフレームワークが含まれ、異なる構成間で一貫した性能測定と比較が可能になります。テストでは、再現性を確保するためにカナリアデータセットを使用し、ステップロードテストやスパイクテストを通じて定常状態とバースト時の両方の動作を把握する必要があります。k6、Locust、またはカスタム Python ハーネスなどのツールを使ってテストを自動化できます。GPU サービスの場合、複数のレプリカを実行することで、オートスケーリングのしきい値を効果的にテストできます。検証では、同時実行レベルごとに 10 〜 30 分間の安定性を確認し、本番環境への準備のために 1 〜 2 時間の耐久テストまで拡張する必要があります。

モデルのデプロイオプションとデータ主権

ナショナル LLM のモデルホスティングを選択する際、3 つの主要なデプロイ方法を区別する必要があります。それぞれのアプローチはデータ主権に対して異なる意味を持ちます :

サードパーティクラウド上のクローズドソースモデル : データフローとログは、自組織のアカウント外で管理されるため、厳格なデータレジデンシー要件がある管轄区域ではコンプライアンス上の課題が生じる可能性があります。
マネージドサービス (Amazon Bedrock など) 経由のオープンソースモデル : マネージドサービス環境で動作しながら、アクセスとガバナンスを簡素化し、制御のしやすさと運用の手軽さのバランスを実現します。
自組織の AWS アカウント内で完全にホストするオープンソースモデル : データの流れ、テレメトリ、監査証跡を最も強力に管理でき、厳格な主権要件を満たすために必要となることが多い方法です。

GDPR 準拠や国内処理義務などのデータレジデンシー要件と主権要件が、この選択を左右します。一部の管轄区域では、学習と推論の両方を国内で行うことを義務付けており、国境を越えたエンドポイントは使用できません。保存場所だけでなく、プロンプト、出力、モデルログの処理される場所もコンプライアンスの対象となります。一時的な推論トラフィックであっても、必要な境界を越えると規制違反になる可能性があります。

多くの公共部門では、自組織のアカウント内でオープンソースモデルをセルフホストすることが、データレジデンシー、プライバシー、監査義務を満たす最も確実な方法です。一方、機密性の低いワークロードや初期評価段階では、マネージド API も有効な選択肢となります。

Amazon SageMaker AI は、モデルデプロイのためのマネージド環境を提供し、基盤となるインフラストラクチャの複雑さの多くを処理しながら、スケーラブルな推論と他の AWS サービスとのシームレスな連携を実現します。より詳細な制御や特定の構成が必要な場合には、Amazon EC2 で完全なカスタマイズ可能な直接デプロイが可能です。Kubernetes の専門知識がある組織なら、Amazon EKS を選んでコンテナ化されたデプロイを行うことで、環境間の柔軟性と移植性が得られます。

デプロイを成功させるには、コスト管理、性能監視、セキュリティコンプライアンスへの細心の注意が必要です。モデルが既存システムとシームレスに連携し、公共部門のセキュリティとコンプライアンス要件を満たすよう、適切な最適化戦略を実装する必要があります。

セキュリティとコンプライアンスのフレームワーク

公共部門の LLM デプロイには、データ主権、プライバシー、監査要件に対応する包括的なセキュリティとコンプライアンス対策が必要です。

承認されたリージョンと VPC (Virtual Private Cloud) に学習と推論を限定し、カスタマーマネージドキー、プライベートサブネット、VPC エンドポイントを使用してデータレジデンシーを確保します。PII 検出と除去は、監査された拒否バケットと不変の変換ログを備えたキュレーションパイプラインに実装する必要があります。

ドキュメントには、一時的なログも含め、プロンプト、出力、テレメトリがどこで処理されるかを明記します。モデルホスティングについては、主権義務がデータの流れとログの制御を求める場合、アカウント内のエンドポイント (Amazon EC2 / Amazon EKS / Amazon SageMaker) を優先すべきです。その際、アクセス制御 (IAM / IRSA) 、転送中と保管時の暗号化、監査証跡 (CloudTrail) 、定期的なコンプライアンスレビューを維持する必要があります。

まとめ

公共部門向けのカスタム LLM の開発とデプロイには、イノベーションとセキュリティ、コンプライアンス、信頼性の要件のバランスを取る体系的なアプローチが必要です。測定可能な成果と再現可能なプロセスを重視する科学的手法により、複雑な課題を乗り越えながらミッションクリティカルな目標を達成できます。

AWS の包括的なサービス群は、初期評価フレームワークから本番環境へのデプロイと監視まで、各開発ステージに必要なツールとインフラストラクチャを提供します。ナショナル LLM を通じて文化遺産を保護する場合でも、ドメイン特化型 LLM で公共サービスを強化する場合でも、カスタム LLM は政府や公共機関がコミュニティにサービスを提供する方法を大きく改善する可能性を秘めています。

成功には、初期デプロイ後も継続的な取り組みが必要です。進化する運用環境において LLM の有効性を維持するため、継続的な監視、改良、適応を行います。

カスタム LLM 開発を開始する準備ができている場合、以下を実施する必要があります :

評価フレームワークの確立 : LM HarnessとAWSネイティブツールを使用
コスト分析の実施 : 予測されるワークロードに対する API 利用とセルフホスティングの TCO を比較
AWS インフラストラクチャオプションの検討 : SageMaker HyperPod、AWS PCS、Amazon EC2 Capacity Blocksを検討
データキュレーションパイプラインの実装 : Nemo Curatorなどのツールで大規模処理に対応
セキュリティとコンプライアンスフレームワークの設計 : 特定の管轄要件を満たす設計

詳細な技術ガイダンスについては、包括的なリソースライブラリをご覧ください :

組織のナショナル LLM 取り組みに対する具体的な要件やカスタマイズされた実装ロードマップの作成については、AWS アカウントチームにお問い合わせください。

Amazon Web Services ブログ