タービン設計、CFD、強度・振動、実験データ解析を社内LLMとOSSで循環させるミニAIファクトリー構想のハードウエア構想
エグゼクティブサマリー
結論
タービン設計・CFD・強度・振動・実験データを、社内に閉じた生成AI、解析コード、社内知識、評価系で循環させ、24時間継続的に設計知を生み出す「小型AIファクトリー」の最小実用基盤を構築することである。
大手製薬企業では、長年蓄積した専有データとAI計算基盤を結び、仮説生成、実験、学習を高速循環させる専用AIファクトリーへの投資が始まっている。Eli Lillyは1,000基超のB300 GPUによるAIファクトリーを発表し、Rocheはオンプレミスとクラウドを組み合わせた3,500基超のBlackwell GPU基盤を公表した。[1][2] 製造・設計分野でもSiemensとNVIDIAは、設計、シミュレーション、製造、運用をつなぐIndustrial AI Operating Systemと自律的デジタルツインを志向している。[3]
| 推奨判断
初期フェーズは「H200クラス4基相当」を有力基準とする。ただし、調達仕様は単純なGPU枚数ではなく、(1) 141 GB/GPU級のメモリ、(2) 4基同時利用、(3) 70B級モデルの単一GPU推論、(4) 部門間ジョブ分離、(5) 3～5年保守、を要求性能として記述する。4×H200 NVL/PCIe案と、拡張性に優れる8×H200 SXM/HGX案を正式見積で比較する。 |
|---|
| 評価軸 | 判断 |
|---|---|
| 機密性 | オンプレミスは設計データを社外サービスへ送らないアーキテクチャを選べる。クラウドにも強い契約・技術保護はあるため、「クラウドは危険」ではなく「外部処理点を減らし自社統制を最大化」と説明する。 |
| コスト | 24時間・高稼働率の反復推論ではオンプレミスが有利になりやすい。AWSのH200 Capacity Block公表値は1 GPUあたり5.97ドル/時であり、4基を常時5年間使う単純換算は約161百万円（1ドル154円、ストレージ等除外）。[4] |
| 技術適合 | H200は141 GB HBM3e、4.8 TB/sで、70B級モデルを単一GPUに載せやすい。H100 80 GBよりエージェント推論のメモリ余裕が大きい。[5] |
| 導入リスク | いきなり全面自動設計にしない。人による承認、サンドボックス、評価ゲート、監査ログを設け、提案→解析→検証→採用を段階化する。 |
現段階の価格は予算化用レンジであり、正式見積ではない。サーバー構成、保守、受電・空調工事、ソフトウェアライセンス、為替によって大きく変動するため、最終稟議では国内ベンダー2～3社の同一仕様見積が必須である。
提案の主要メッセージ
- 会社固有のタービン設計知を、外部APIへ常時送信せずに活用できる。
- 人が一回ずつ解析する方式から、複数のAIハーネスが24時間、設計案・解析条件・評価結果を循環生成する方式へ移行できる。
- APIトークン単価ではなく、設計探索一件当たり・検証済み設計案一件当たりのコストを下げる。
- タービン部門だけでなく、CFD、強度、振動、実験、材料、制御などの共通設備にすることで稼働率と投資効果を高める。
- H200×4は目的ではなく、最小実用規模を検証する初期仮説である。実ワークロードによるPoCと正式見積で確定する。
1. 背景と目的
1.1 産業は「AIを使う」段階から「知を生産する基盤を持つ」段階へ
生成AIの競争軸は、汎用チャットの利用人数から、企業固有データ、専門モデル、シミュレーション、実験を継続的に回す計算基盤へ移りつつある。NVIDIAはこの種の基盤をAI factoryと呼び、データ取り込み、学習・調整、大量推論までを一体運用する考え方を示している。Lillyの発表でもAI factoryはAIライフサイクル全体を管理する専用計算基盤として説明されている。[1]
| 事例 | 規模・構成 | 狙い | 本提案への示唆 |
|---|---|---|---|
| Eli Lilly | 1,000基超のNVIDIA B300、DGX SuperPOD | 数百万件の実験を使ったモデル学習、分子の同定・最適化・検証、製造・画像・AIエージェント | 企業固有の長期データを計算基盤と結び、科学者の仮説探索量を拡大 |
| Roche | オンプレミス2,176基を追加、ハイブリッド合計3,500基超のBlackwell GPU | 創薬、臨床、製造デジタルツイン、診断、病理、会話AI | 機密データを持つ企業でもオンプレミスとクラウドを用途別に組み合わせる |
| Siemens × NVIDIA | Industrial AI Operating System、AI-native simulation、自律デジタルツイン | 設計から製造・運用までの連続最適化、シミュレーションのGPU化 | タービンでも設計・解析・実験をデジタルスレッドで接続する価値がある |
これらは本提案より桁違いに大規模であり、そのまま比較するものではない。重要なのは規模ではなく、専有データと専門計算を社内AI基盤へ接続し、知識生産サイクルを短縮する戦略である。本提案は、その考え方をH200クラス4基相当から検証する「ミニAIファクトリー」である。
1.2 タービン開発で解くべき構造的課題
| 現状の課題 | 従来方式の制約 | AIファクトリーで目指す状態 |
|---|---|---|
| 専門作業が分断 | 一次元設計、CFD、強度、振動、実験が別ツール・別担当 | 共通の設計ID、条件、結果、根拠で連携 |
| 反復回数が人に依存 | 入力作成、投入、監視、集計、報告を人が繰り返す | ハーネスが夜間・休日も候補生成と解析を継続 |
| 知識が散在 | 報告書、メール、個人フォルダ、暗黙知に分散 | 検索可能な根拠付き知識として蓄積 |
| 設計探索が限定 | 時間制約から少数ケースに限定 | 自動化により候補数を増やし、人は判断と検証に集中 |
| 再利用性が低い | 案件ごとに似た前処理・後処理を再作成 | ワークフロー、評価器、データセットを共通資産化 |
1.3 目的
目的は、社内機密を保持したまま、複数部門が生成AIとOSSを高頻度に利用し、設計・解析・評価を自動循環できる最小実用基盤を構築・検証することである。初期設備は単なるLLMサーバーではなく、将来のタービン設計OSに必要な計算、データ、評価、統制の基盤と位置付ける。
2. 提案コンセプト：タービン開発ミニAIファクトリー
2.1 全体像
| 層 | 構成要素 | 役割 |
|---|---|---|
| 利用層 | 設計者、CFD、強度、振動、実験、材料、制御 | 課題設定、承認、専門判断、最終責任 |
| ハーネス層 | 設計、解析、検索、コード生成、レポート、評価エージェント | LLMにツール、状態、手順、制約、評価を与え、反復作業を遂行 |
| モデル層 | OSS LLM、埋め込み、コードモデル、画像・時系列モデル | 推論、計画、生成、分類、検索 |
| ツール層 | 一次元コード、CFD、FEM、NASTRAN、最適化、Python、可視化 | 物理計算と決定論的処理を担当 |
| データ層 | PLM、解析DB、過去設計、試験データ、規格、報告書 | 会社固有の設計知を供給 |
| 基盤層 | GPU、CPU、NVMe、共有ストレージ、ジョブ管理、監視 | 安全・安定・高稼働の計算資源 |
2.2 想定する専門ハーネス
| ハーネス | 入力 | 自動処理 | 成果物・評価 |
|---|---|---|---|
| 一次元設計 | 出力、流量、回転数、制約 | 候補生成、速度三角形、損失・性能評価 | 設計候補、制約違反、比較表 |
| CFD | 形状、境界条件、メッシュ規則 | ケース作成、投入、収束監視、後処理 | 性能、損失、流動構造、異常検知 |
| 強度・寿命 | 荷重、温度、材料 | モデル作成補助、結果抽出、規準照合 | 応力、寿命、余裕、根拠 |
| 振動・フラッタ | モード、空力、運転範囲 | 解析連携、安定性整理、危険域抽出 | 減衰、共振、リスクマップ |
| 実験データ | 計測信号、試験条件 | 品質確認、特徴抽出、異常点検出 | 再現性、相関、モデル更新用データ |
| 知識検索 | 設計質問、部品、現象 | 権限付きRAG、類似事例検索 | 引用元付き回答、設計根拠 |
| 報告書 | 解析結果、判断履歴 | 図表生成、差分整理、根拠集約 | レビュー可能なドラフト |
2.3 データファクトリーの循環
LLM単体は物理的正しさを保証しない。価値は、LLMが候補を作り、決定論的解析コードが計算し、評価器が合否を判定し、結果を次の提案へ戻す閉ループにある。採用前には必ず人の承認を置く。
- 要求・制約を構造化し、設計IDと評価指標を定義する。
- ハーネスが複数の設計案または解析条件を生成する。
- 既存の検証済みコードで計算し、結果とログを保存する。
- 物理則、設計規準、既知解、専門家レビューで自動・手動評価する。
- 不合格理由を次の探索へ戻し、再計算する。
- 検証済みデータ、失敗例、判断根拠を再利用可能なデータセットとして蓄積する。
3. 導入価値の中心（1）：機密性と技術主権
3.1 正確な主張
| 重要
「OSSだから情報が漏れない」は正確ではない。正しくは、「ライセンスを確認したOSSモデルを、自社管理の閉域・オンプレミス環境で運用し、外部APIへ設計データを送信しない構成にすることで、外部処理点と第三者依存を減らせる」である。 |
|---|
Azure OpenAIおよびOpenAI APIの企業向けサービスは、顧客データを既定でモデル学習に使わない旨を公式に示している。[6][7] したがって、クラウドを一律に機密漏洩リスクが高いと表現するのは適切でない。一方、オンプレミスでは、データ処理場所、ログ、モデル、ネットワーク、保持期間、管理者権限を自社統制下に置きやすく、輸出管理・顧客契約・設計秘密などの個別要件へ合わせやすい。
| 観点 | オンプレミスOSS | 企業向けクラウドLLM/API | 評価 |
|---|---|---|---|
| 入力データの処理場所 | 社内設備に限定可能 | 契約したクラウド環境・リージョン | 最重要設計データはオンプレミスが説明しやすい |
| 学習への利用 | 自社運用のため自社方針で管理 | 主要企業向けサービスは原則不使用を明示 | 両者とも適切な契約・設定が前提 |
| ネットワーク露出 | 完全閉域・出口制御が可能 | 外部接続とID・鍵管理が必要 | 攻撃面はオンプレミスで削減可能 |
| 運用責任 | パッチ、脆弱性、アクセス管理を自社負担 | 基盤運用の多くを事業者が担当 | オンプレミスは責任も増える |
| 監査・ログ | 保存範囲と期間を細かく設計可能 | 提供機能・契約条件に依存 | 社内規程への適合性で判断 |
| モデル性能 | OSSの能力と更新速度に依存 | 最先端商用モデルを利用しやすい | ハイブリッドが現実的 |
| ベンダーロックイン | モデル・推論基盤を交換可能 | API・サービス仕様への依存 | オンプレミスは交渉力と継続性を高める |
3.2 推奨する情報分類と利用境界
| 情報区分 | 例 | 利用先 | 追加統制 |
|---|---|---|---|
| 極秘・輸出管理対象 | 未公開翼形状、顧客性能、事故・不具合、製造公差 | 閉域オンプレミスのみ | 持出禁止、個別権限、監査、暗号化 |
| 社外秘 | 解析手順、社内報告、設計ルール | 原則オンプレミス | RAG権限継承、保存期間 |
| 公開情報 | 論文、公開特許、規格の公開範囲 | オンプレミス／承認済クラウド | 出典管理、著作権確認 |
| 非機密・一般作業 | 一般コード例、文章校正 | クラウド併用可 | 機密混入防止フィルタ |
3.3 オンプレミスでも必要な安全対策
- モデル取得元、ハッシュ、ライセンス、脆弱性、SBOMを管理する。
- エージェントに本番設備・ファイル削除・権限変更を直接許可しない。
- 解析実行はコンテナ／サンドボックスに分離し、CPU、GPU、時間、保存量を制限する。
- ツール呼出し、入力、出力、モデル版、コード版、承認者を監査ログへ残す。
- RAGは元文書のアクセス権を継承し、検索結果による権限迂回を防ぐ。
- プロンプトインジェクション、誤情報、機密抽出、過剰権限を定期評価する。NIST AI RMFのGovern・Map・Measure・Manageに沿って統制する。[8]
4. 導入価値の中心（2）：コストエフェクティブな24時間運用
4.1 コスト比較の考え方
低頻度・短期・需要変動が大きい用途ではクラウドが有利である。一方、複数のハーネスが毎日長時間稼働し、入力・出力トークン、再試行、候補数が増える用途では、従量料金が研究者の探索行動を抑制しやすい。オンプレミスの価値は料金ゼロではなく、購入後の限界費用を電力・運用中心に下げ、探索回数を増やせることである。
| 費用項目 | オンプレミス | クラウドGPU | 商用LLM API |
|---|---|---|---|
| 初期費用 | 大：サーバー、電源、空調、設置 | 小 | 小 |
| 利用量連動費 | 小：主に電力 | 大：GPU時間、保存、通信 | 大：入力・出力・キャッシュ等のトークン |
| 低稼働時 | 資産が遊休 | 停止すれば抑制可能 | 呼び出さなければ抑制可能 |
| 高稼働時 | 平均単価が低下 | 時間に比例 | トークンに比例 |
| 性能更新 | 設備更新が必要 | 新GPUへ切替しやすい | 新モデルへ切替しやすい |
| 機密統制 | 自社設計可能 | 契約・クラウド設計に依存 | 契約・API設計に依存 |
4.2 5年TCOの予算化シナリオ
下表は正式見積前の概算モデルである。H200 4-GPUサーバーの公開価格例は約172,643ドルから、単体H200 NVLの公開販売例は37,000ドルであり、1ドル154円換算では、それぞれ約26.6百万円、約5.7百万円/GPUとなる。[9][10] 国内保守、CPU・RAM・NVMe、冗長電源、輸送、税、設置を含め、稟議用には幅を持たせる必要がある。
| 費用項目 | 低位 | 基準 | 高位 | 前提・注意 |
|---|---|---|---|---|
| 4×H200級サーバー | 30百万円 | 40百万円 | 55百万円 | 国内3～5年保守・周辺構成で変動 |
| 共有ストレージ・ネットワーク | 3 | 6 | 12 | 100/200GbE、バックアップ容量による |
| 受電・ラック・空調工事 | 2 | 6 | 15 | 既存設備流用可否が最大変動要因 |
| 5年電力・冷却 | 6 | 9 | 15 | 設備5.5～7.5kW、PUE 1.2～1.5、20～30円/kWh |
| 5年保守・予備費 | 3 | 6 | 10 | 本体保守条件により重複調整 |
| 5年運用人件費 | 8 | 15 | 25 | 0.1～0.3人相当。AI基盤運用を共通化 |
| 5年TCO概算 | 52百万円 | 82百万円 | 132百万円 | ソフト商用ライセンス・大規模改修は別 |
4.3 クラウドH200との単純比較
AWS Capacity Blocks for MLのP5e公表価格は、8×H200で47.76ドル/時、1 GPU当たり5.97ドル/時である。[4] 4 GPUを同単価で確保できると仮定した単純換算を示す。実際のサービスは8 GPU単位、予約条件、リージョン、保存・通信費、割引により異なる。
| 4 GPU相当の平均稼働率 | 5年間GPU料金（USD） | 円換算（154円/USD） | 解釈 |
|---|---|---|---|
| 25% | 約261千ドル | 約40百万円 | 短時間・断続利用ではクラウドが有力 |
| 50% | 約523千ドル | 約81百万円 | オンプレ基準TCOと同水準。機密性と柔軟性が判断軸 |
| 75% | 約784千ドル | 約121百万円 | オンプレ優位が強まりやすい |
| 100% | 約1,046千ドル | 約161百万円 | 24時間ハーネス運用ではオンプレが有力 |
| 損益分岐の読み方
基準TCO 82百万円とAWS公表単価の単純比較では、約51%稼働が5年損益分岐の目安となる。ただしオンプレ側には残存価値、クラウド側にはストレージ・通信・管理費、両側にはソフトウェア費がある。正式判断は実測GPU時間と国内見積で再計算する。 |
|---|
4.4 API比較で注意すべき点
商用LLM APIは高性能で導入が速いが、モデルごとにトークン価格と能力が異なり、将来価格も変わる。ハーネスが長いコンテキスト、複数候補、自己評価、再試行を行うと、単純なチャット利用よりトークン消費が数倍から数十倍に増え得る。したがって、提案では架空の固定トークン量を置くより、PoCで「1設計タスク当たりの入力・出力・再試行・所要GPU秒」を計測し、実績から5年費用へ外挿する。
5. GPU候補比較
5.1 仕様比較
| 候補 | メモリ/GPU | 帯域/GPU | 典型構成 | 主な強み | 主な制約 |
|---|---|---|---|---|---|
| RTX PRO 6000 Blackwell Server | 96 GB GDDR7 ECC | 最大1.6 TB/s | 1～8 GPU PCIe | 低い導入費、推論・可視化・CAEの混載、600W | HBM系より帯域が低く、大規模GPU間連携は構成確認が必要 |
| H100 SXM | 80 GB HBM3 | 約3.35 TB/s | 8 GPU HGX | 成熟したHopper、学習・HPC実績 | 80 GBでは70B級の高精度量子化や長文KVキャッシュに余裕が少ない |
| H200 SXM/NVL | 141 GB HBM3e | 4.8 TB/s | 8 GPU HGXまたはNVL/PCIe | 70B級単一GPU推論、容量・帯域・成熟度のバランス | Blackwellより新世代演算性能は低い |
| B200 SXM | 180 GB HBM3e | 最大8 TB/s | 8 GPU HGX | 大規模学習・推論、H200より高性能・大容量 | 高価格、高電力、高密度設備。4基だけの調達自由度は要確認 |
| B300 SXM | 288 GB HBM3e | 最大8 TB/s | 8 GPU HGX | 非常に大きなモデル、長文、将来余裕 | 初期ミニ基盤には過剰となる可能性、設備・供給・価格リスク |
出典：NVIDIA公式製品・リファレンスアーキテクチャ。[5][11][12] 仕様は搭載形態・冷却・製品版により異なるため、RFPでは型番とTDPを固定する。
5.2 本用途への定性評価
| 評価項目 | RTX PRO 6000 | H100 | H200 | B200 | B300 |
|---|---|---|---|---|---|
| 70B級単一GPU推論 | ○（量子化前提） | △ | ◎ | ◎ | ◎ |
| 同時4部門利用 | ◎ | ○ | ◎ | ◎ | ◎ |
| 大規模学習・高速GPU間連携 | △ | ○～◎ | ○～◎ | ◎ | ◎ |
| 既存CAE/可視化混載 | ◎ | ○ | ○ | ○ | ○ |
| 初期導入費 | ◎ | ○ | ○ | △ | × |
| 電源・冷却容易性 | ○ | ○ | ○ | △ | × |
| 将来余裕 | ○ | △ | ○ | ◎ | ◎ |
| 初期ミニAIファクトリー適合 | ○ | △ | ◎ | ○ | △ |
5.3 H200を有力とする論理
- 141 GBのHBM3eにより、70B級モデルを1 GPUへ載せ、GPU間通信を使わずに部門別並列運用しやすい。
- 4.8 TB/sの帯域は、LLM推論で重要な重み読出しとKVキャッシュ処理に有利である。
- H100よりメモリ余裕が大きく、B200/B300より導入コストと設備要求を抑えやすい。
- Hopper世代のソフトウェア、運用知見、推論最適化が成熟している。
- B200/B300の最高性能よりも、4つの専門領域が安定して同時利用できる実用性を優先できる。
5.4 ただし「H200×4」の構成を明確化する
| 構成案 | 向く用途 | 利点 | 注意点 |
|---|---|---|---|
| 4×H200 NVL/PCIeサーバー | 4部門の独立推論、70B級モデル、LoRA、小～中規模解析AI | 初期規模に近い。約564 GBの総GPUメモリ | GPU間接続が2枚ペア等の場合、4枚一体の大規模学習性能はHGXと異なる |
| 8×H200 SXM HGX | 大規模学習、1ジョブで多数GPU、将来ユーザー増 | NVSwitchで高帯域の全GPU連携、1.128 TB HBM3e | 初期費・電力・設備が増え、最小構成を超える |
| 4～8×RTX PRO 6000 | 部門別推論、CAE、画像、可視化、費用優先 | 96 GB/GPU、幅広いワークロード、比較的導入しやすい | 大規模モデルの分散学習・帯域ではH200/HGXに劣る |
| クラウド併用 | ピーク、短期学習、B200/B300検証 | 設備を増やさず最新GPUを利用 | 極秘データの境界、従量費、調達・接続審査 |
6. 必要容量の逆算
6.1 モデルメモリの概算
モデル重みだけの概算は、パラメータ数×量子化ビット数÷8で求められる。実運用ではKVキャッシュ、ランタイム、バッチ、長文コンテキスト、並列化の余裕が必要である。
| モデル規模 | FP16/BF16重み | 8-bit重み | 4-bit重み | 実務上の示唆 |
|---|---|---|---|---|
| 30～35B | 約60～70 GB | 約30～35 GB | 約15～18 GB | 96 GB級で余裕を持って運用可能 |
| 70～72B | 約140～144 GB | 約70～72 GB | 約35～36 GB | H200 141 GBは8-bit＋KV余裕、FP16は追加余裕が必要 |
| 100～120B | 約200～240 GB | 約100～120 GB | 約50～60 GB | H200単体は量子化前提。複数GPUまたはB300が有利 |
| MoE大型 | 総パラメータに依存 | 総重みは依然大きい | 量子化で縮小 | 活性パラメータが少なくても重み格納量を確認 |
このため、4基構成の考え方は「1部門1GPU固定」ではなく、通常は30B～70Bを1 GPUで複数リクエスト処理し、必要時のみ2～4 GPUを束ねるジョブ管理が望ましい。
6.2 初期ワークロード仮説
| 領域 | 主要処理 | GPU需要仮説 | 優先度 |
|---|---|---|---|
| タービン設計 | コード生成、最適化計画、設計DB検索、報告 | 70B級1 GPU常駐＋解析CPU | 最優先 |
| CFD | ケース作成、後処理、サロゲート、Physics AI | 1 GPU常駐／学習時2 GPU | 最優先 |
| 強度・振動 | 結果抽出、モデル補助、異常検知、サロゲート | 1 GPU共有 | 高 |
| 実験・材料・検査 | 時系列、画像、報告、モデル更新 | 1 GPU共有、ピーク時増加 | 高 |
| 全社コード支援 | 複数ユーザーの短い推論 | 空きGPU/MIG/時分割 | 中 |
6.3 初期サイジング結論
| 初期基準
H200クラス141 GB × 4基相当（総GPUメモリ約564 GB）を最小実用規模の基準とする。部門別の同時利用を成立させ、70B級モデルを単一GPUへ配置でき、夜間に2～4 GPUを設計探索・追加学習へ再配分できる。 |
|---|
ただし、PoCで70B級より30B級モデルが十分であり、GPU間学習が少ないと判明した場合はRTX PRO 6000複数基が高い費用対効果を示す可能性がある。逆に、Physics AIや大規模モデル学習を主要目的にする場合、4×H200 NVLではなく8×H200 HGXまたはB200系を検討する。
7. 推奨システム構成
7.1 ハードウェア要求仕様（案）
| 項目 | 最小要求 | 推奨 | 理由 |
|---|---|---|---|
| GPU | H200級141 GB ×4相当 | 4×H200 NVL/PCIeを基本見積、8×H200 HGXを代替見積 | 部門同時利用と70B級単一GPU |
| CPU | 合計64コア級 | 96～128コア級 | 前後処理、データ変換、複数ジョブ |
| RAM | 512 GB | 1 TB以上 | モデルロード、RAG、CAE前後処理 |
| ローカルNVMe | 15 TB | 30 TB以上、冗長 | モデル、キャッシュ、解析一時領域 |
| 共有ストレージ | 既存接続 | 100 TB級から段階増設 | 解析結果、データセット、バックアップ |
| ネットワーク | 25/100GbE | 100GbE以上、拡張時200/400GbE | データ投入と将来ノード追加 |
| 電源 | 冗長、実測容量確保 | N+1、計測可能PDU | 24時間運用と監視 |
| 冷却 | 熱設計確認 | ラック実効6～10kWを安全に排熱 | GPU TDP以外にCPU・電源損失がある |
| 保守 | 3年 | 5年オンサイト、代替部品条件明記 | 停止損失を抑制 |
7.2 ソフトウェア構成
| 機能 | 候補 | 方針 |
|---|---|---|
| OS・コンテナ | Linux、Docker/Podman、必要に応じKubernetes | 最初は複雑化を避け、再現性を確保 |
| GPUジョブ管理 | Slurm、Kubernetes系、MIG/時分割 | GPU固定割当ではなく優先度と予約を管理 |
| 推論 | vLLM、TensorRT-LLM、NVIDIA NIM等 | モデルごとに実測し、API互換層で交換可能にする |
| モデル管理 | 社内レジストリ、承認済モデルカタログ | 出所、ライセンス、ハッシュ、評価結果を記録 |
| RAG | ベクトルDB＋文書DB＋権限連携 | 検索精度より先にアクセス制御を設計 |
| ワークフロー | 社内ハーネス、Python、既存設計ツール連携 | 各工程に承認ゲート、再試行上限、監査ログ |
| 観測・課金 | GPU使用率、token/s、待ち時間、ジョブ原価 | 部門別利用実績と増設判断に使用 |
7.3 ハイブリッド方針
オンプレミスを中心にしながら、公開情報の一般推論、最新商用モデルによる非機密ベンチマーク、短期ピーク、大規模学習の一時利用はクラウドへ逃がす。これにより、機密性を守りながら技術陳腐化とピーク設備過剰を抑制できる。
8. 導入ロードマップとゲート
| 段階 | 期間目安 | 実施内容 | 完了条件 |
|---|---|---|---|
| 0. 要件・計測 | 1～2か月 | 代表20タスク、情報区分、GPU時間、APIトークン、現行工数を計測 | ベースラインとRFP要求性能を承認 |
| 1. PoC | 2～3か月 | クラウド／レンタルH200で4分野を試験、H200・RTX PROを比較 | 品質、速度、費用、機密運用の合格基準達成 |
| 2. 調達・設置 | 3～6か月 | 2～3社見積、電源・冷却確認、受入試験 | 性能・安全・保守・復旧試験合格 |
| 3. 初期運用 | 3か月 | 設計、CFD、強度/振動、実験の4ハーネス | 月間稼働率、再利用率、工数削減を確認 |
| 4. 24時間化 | 6～12か月 | 夜間探索、評価ゲート、データ再投入 | 無人処理の安全性と成果品質を実証 |
| 5. 横展開 | 以降 | 他製品・部門へ展開、増設判断 | GPU待ち時間と価値指標で投資判断 |
8.1 最初の90日で作るもの
- 代表タスク一覧と、現行工数・成功条件・機密区分のベースライン。
- 承認済みOSSモデル2～3種のベンチマーク環境。
- タービン設計ハーネスの最小版：要求入力、既存コード実行、結果比較、ログ保存。
- CFD後処理またはケース生成ハーネスの最小版。
- モデル評価セット：正答、禁止事項、物理制約、社内規準。
- 利用ダッシュボード：GPU使用率、待ち時間、成功タスク数、再試行、消費電力。
8.2 調達ゲート
| ゲート | 判断基準 | 不合格時 |
|---|---|---|
| G1：用途成立 | 4分野中3分野以上で品質・工数効果を確認 | モデル・ハーネスを改善し設備購入を延期 |
| G2：H200必要性 | 96 GB級では不足、141 GBまたは帯域が価値へ直結 | RTX PRO構成へ縮小 |
| G3：高稼働性 | 予測平均稼働率40～50%以上、または機密要件で常設必須 | クラウド・レンタル継続 |
| G4：設備適合 | 電源、冷却、騒音、保守、設置場所を確認 | 外部DC／ハウジングを比較 |
| G5：運用体制 | 所有者、管理者、セキュリティ、予算を明確化 | 共通基盤部門へ移管・共同運営 |
9. 投資効果とKPI
9.1 効果を「人員削減」だけで測らない
研究開発設備では、単純な人員削減よりも、探索量、検証速度、再利用性、品質、知識継承が本質的な価値である。自動化で生まれた時間を、要求設定、物理判断、レビュー、創造的設計へ再配分する。
| KPI区分 | 指標例 | 計測方法 |
|---|---|---|
| 速度 | 要求受領から最初の比較結果までの時間 | 導入前後の中央値 |
| 探索量 | 月間の有効設計案数、解析ケース数 | 重複・失敗を除いた完了ジョブ |
| 品質 | 既知解一致率、物理制約違反率、専門家採用率 | 固定評価セット＋レビュー |
| 再利用 | 共通ハーネス利用件数、再利用データ率 | リポジトリ・データカタログ |
| 稼働 | GPU利用率、待ち時間、部門別GPU時間 | 監視基盤 |
| 費用 | 成功タスク当たりTCO、設計候補当たり費用 | 設備費＋運用費を成果数で除算 |
| 機密統制 | 外部送信件数、権限違反、監査ログ欠損 | 定期監査 |
| 知識資産 | 根拠付き設計判断、評価済み失敗例、更新データセット | 月次棚卸し |
9.2 投資効果の計算式
| 効果 | 計算の基本式 |
|---|---|
| 工数価値 | 削減・再配分時間 × 標準時間単価 |
| 外注削減 | 削減できた外注解析・データ処理・ソフト開発費 |
| クラウド回避 | 回避GPU時間 × 実契約単価 ＋ 回避トークン × API単価 |
| 開発期間価値 | 短縮月数 × 案件の月間期待価値（経営側定義） |
| 設計品質価値 | 手戻り・試験追加・不具合回避の期待額 |
| 総便益 | 工数価値＋外注削減＋クラウド回避＋期間価値＋品質価値 |
| ROI | （5年総便益－5年TCO）÷5年TCO |
初期提案では、期間価値や不具合回避を過大に見積もらず、現行工数、実GPU時間、外注費、クラウド費など検証可能な項目を基本ケースにする。設計探索増加と期間短縮は上振れケースとして別表示する。
10. リスクと対策
| リスク | 影響 | 対策 | 残余判断 |
|---|---|---|---|
| OSSモデルの精度不足 | 誤設計、誤説明、手戻り | 固定評価セット、物理コードで検証、人の承認、用途別モデル選択 | LLMを決裁者にしない |
| 自律エージェントの暴走 | 計算資源浪費、ファイル破損 | サンドボックス、権限最小化、予算・回数上限、停止機構 | 無人実行は読取・一時領域から開始 |
| 機密漏洩 | 競争力・契約・法務影響 | 閉域、DLP、権限連携、暗号化、ログ、外部通信遮断 | ゼロリスクではなく統制可能性を高める |
| GPU遊休 | 投資効果低下 | 複数部門共用、ジョブ管理、KPI、段階調達 | 40～50%未満ならクラウド再評価 |
| 電源・冷却不足 | 停止、性能低下、設備事故 | 事前実測、熱設計、冗長、監視、受入負荷試験 | 既存機械室適合を調達条件化 |
| 技術陳腐化 | 新GPU・新モデルに劣後 | API互換、コンテナ、モデル交換、ハイブリッド | 3年時点で更新判断 |
| 属人運用 | 担当退職で停止 | IaC、手順、監視、複数管理者、保守契約 | 運用を研究テーマと分離 |
| ライセンス違反 | 利用停止・法務問題 | モデル・OSS・学習データの台帳と法務確認 | 『open』と商用自由を同一視しない |
NISTの生成AIプロファイルは、生成AI固有リスクを組織のAIライフサイクル全体で管理する考え方を示す。[8] 本提案でも、モデル精度だけでなく、権限、データ来歴、評価、監査、インシデント対応を設備要件に含める。
11. 意思決定案
| 承認を求める内容
直ちにH200×4を確定購入するのではなく、(1) 代表ワークロード計測、(2) H200級レンタルPoC、(3) 4×H200 NVL/PCIe・8×H200 HGX・RTX PRO 6000案の同一条件見積、(4) 設置設備調査、までを先行承認する。その結果を基に本設備投資を最終決裁する。 |
|---|
| 選択肢 | 推奨度 | 採用条件 |
|---|---|---|
| A：4×H200 NVL/PCIe | 第一候補 | 推論・部門並列中心、70B級、5年高稼働、4-GPU連携要件が限定的 |
| B：8×H200 SXM/HGX | 条件付き | 大規模学習・Physics AI・1ジョブ多GPUが事業上必須 |
| C：4～8×RTX PRO 6000 | 費用対効果候補 | 30B～70B量子化で品質十分、CAE/可視化混載、帯域要求が低い |
| D：クラウド継続 | 低稼働時候補 | 稼働率が低い、機密データを送らない、短期・変動需要 |
| E：ハイブリッド | 併用推奨 | オンプレを機密・定常、クラウドを非機密・ピーク・最新比較に使用 |
11.1 最終提言
タービン開発の競争力は、単発の高性能モデル利用ではなく、会社固有の設計知、解析コード、実験データを安全に循環させる能力によって決まる。本提案はその能力を社内資産として構築する第一歩である。機密性と24時間高稼働を主要根拠に、H200クラス4基相当を初期基準としてPoCと見積を行う。
最終調達では、H200という製品名だけで決めず、実タスクの成功率、1 GPU当たり処理量、メモリ余裕、4 GPU連携、設置TCO、保守、稼働率を採点する。これにより、先端GPU購入の稟議ではなく、継続的な設計知生産基盤への投資として説明できる。
付録A. PowerPointへの落とし込み案
| 枚 | タイトル | 一枚で伝えること |
|---|---|---|
| 1 | 提案要旨 | 機密性とコストを軸にタービン開発ミニAIファクトリーを構築 |
| 2 | 産業の転換 | 製薬・製造業は専有データ×専用AI基盤で知識生産へ移行 |
| 3 | 現在の課題 | 設計・解析・実験が分断され、反復と知識再利用に限界 |
| 4 | 将来像 | 複数ハーネスが24時間、提案→解析→評価→学習を循環 |
| 5 | 機密性 | 外部処理点を減らし、自社統制を最大化。クラウドとの正確な比較 |
| 6 | コスト構造 | 高稼働ではオンプレの平均単価が低下。5年TCOで判断 |
| 7 | 利用部門 | 設計、CFD、強度・振動、実験が共用し稼働率を確保 |
| 8 | GPU比較 | RTX PRO 6000、H100、H200、B200、B300の表 |
| 9 | H200の理由 | 141 GB、4.8 TB/s、成熟度、コストのバランス |
| 10 | 構成上の注意 | 4×H200 NVL/PCIeと8×H200 HGXは別物 |
| 11 | 推奨構成 | H200クラス4基相当＋CPU/RAM/NVMe/共有ストレージ |
| 12 | 導入ロードマップ | 計測→PoC→調達→初期運用→24時間化→横展開 |
| 13 | 投資効果KPI | 工数ではなく探索量、成功タスク、期間、再利用、原価 |
| 14 | リスク統制 | 人の承認、評価、サンドボックス、監査、停止機構 |
| 15 | 意思決定 | PoC・設備調査・3構成見積の先行承認を求める |
付録B. ベンダーRFP確認項目
| 区分 | 確認項目 |
|---|---|
| GPU | 正確な型番、メモリ、TDP、搭載枚数、GPU間接続図、NVLink/NVSwitch帯域、MIG対応 |
| 性能 | 対象モデルのtokens/s、同時実行、TTFT、長文、量子化、LoRA、MLPerfまたは再現可能試験 |
| サーバー | CPU、RAM、NVMe、RAID、NIC、冗長電源、BMC、セキュアブート、騒音、寸法・重量 |
| 設備 | 最大・典型消費電力、突入、電源系統、発熱量、吸排気、液冷要否、推奨室温 |
| ソフト | ドライバ、CUDA、仮想化、コンテナ、OS、商用ライセンス、更新権 |
| 保守 | 期間、オンサイト、応答時間、GPU交換SLA、代替機、部品保有、障害切分け |
| 受入試験 | 全GPU負荷、ECC、温度、電力、通信、ストレージ、モデル推論、72時間連続運転 |
| 価格 | 本体、保守、設置、教育、送料、税、ライセンス、電源・冷却工事を分離表示 |
| 納期・供給 | 確定納期、代替型番、EOL、将来GPU増設、ラック・ネットワーク拡張 |
付録C. 前提・限界
- 本報告書の価格は2026年9月時点で確認できる公開情報と計画仮定に基づく。正式な購入価格ではない。
- 為替換算は概算として1米ドル154円を使用した。輸入費、税、国内保守、値引きで変動する。
- H200クラウド費はAWS Capacity Blocksの公表値を用いた。実際の契約単位、リージョン、予約、割引、最低利用期間を確認する。
- オンプレミス電力費は設備全体の平均5.5～7.5kW、PUE 1.2～1.5、電力20～30円/kWhの計画レンジ。設置場所の実単価で更新する。
- 性能比較はGPU仕様だけでは確定しない。対象OSSモデル、量子化、コンテキスト長、バッチ、推論エンジンで実測する。
- B200/B300や製品構成は供給・仕様変更があり得る。正式見積時に型番と世代を固定する。
- 企業向けクラウドには強いデータ保護がある。オンプレミスの優位は、漏洩可能性ゼロではなく、自社統制と外部処理点削減にある。
参考文献
1. Eli Lilly and Company. 「Lilly partners with NVIDIA to build the industry’s most powerful AI supercomputer, supercharging medicine discovery and delivery for patients」 2025-10-28.
https://lilly.gcs-web.com/news-releases/news-release-details/lilly-partners-nvidia-build-industrys-most-powerful-ai
2. Roche. 「Roche launches NVIDIA AI factory to accelerate the development of new therapeutics and diagnostics solutions」 2026-03-16.
https://www.roche.com/media/releases/med-cor-2026-03-16
3. Siemens. 「Siemens and NVIDIA Expand Partnership to Build the Industrial AI Operating System」 2026-01-06.
https://press.siemens.com/global/en/pressrelease/siemens-and-nvidia-expand-partnership-build-industrial-ai-operating-system
4. Amazon Web Services. 「Amazon EC2 Capacity Blocks for ML Pricing — P5e」 参照 2026-09.
https://aws.amazon.com/ec2/capacityblocks/pricing/
5. NVIDIA. 「NVIDIA H200 Tensor Core GPU / H200 inference technical information」 参照 2026-09.
https://www.nvidia.com/en-us/data-center/h200/
6. Microsoft. 「Data, privacy, and security for Foundry Models sold by Azure」 更新 2026-05-18.
https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy
7. OpenAI. 「Enterprise privacy at OpenAI」 参照 2026-09.
https://openai.com/enterprise-privacy/
8. NIST. 「Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1」 2024-07-26; updated 2026-04-08.
https://doi.org/10.6028/NIST.AI.600-1
9. BIZON. 「NVIDIA HGX H200 SXM AI GPU Server — public starting-price example」 参照 2026-09.
https://bizon-tech.com/nvidia-hgx-h200-sxm-ai-server
10. Network Outlet. 「NVIDIA H200 NVL 141GB — public unit-price example」 参照 2026-09.
https://networkoutlet.com/products/nvidia-h200-nvl-pcie-141gb
11. NVIDIA. 「NVIDIA RTX PRO 6000 Blackwell Server Edition」 参照 2026-09.
https://www.nvidia.com/en-us/data-center/rtx-pro-6000-blackwell-server-edition/
12. NVIDIA. 「HGX AI Factory Reference Architecture — H200, B200 and B300 specifications」 更新 2026.
https://docs.nvidia.com/enterprise-reference-architectures/hgx-ai-factory/latest/components.html
13. NVIDIA. 「H200 and TensorRT-LLM MLPerf LLM Inference Records」 2024-03-27.
https://developer.nvidia.com/blog/nvidia-h200-tensor-core-gpus-and-nvidia-tensorrt-llm-set-mlperf-llm-inference-records/
14. Amazon Web Services. 「Amazon EC2 P5 Instances — H100 and H200 platform details」 参照 2026-09.
https://aws.amazon.com/ec2/instance-types/p5/
15. 経済産業省 資源エネルギー庁. 「デジタル・AI技術による省エネ・生産性向上に向けた手引き」 2026-03-03.
https://www.meti.go.jp/press/2025/03/20260303002/20260303002.html
コメント