【AIコンサル実務研究｜第09回】AIモデル・アーキテクチャ・クラウド基盤の技術選定――産業機械メーカーM社で、要件から設計判断と選定根拠を組み立てる
はじめに：モデル名から選び始めない
AIシステムの技術選定でよくある混乱は、「性能が高そうなLLM」「使い慣れたクラウド」「流行のSDK」を先に決め、要件を後付けすることだ。しかし、問い合わせが同じでも必要な構成は異なる。最新の在庫数を正確に答えるなら、業務APIの確定値が中心となる。技術仕様書の記述を示すなら、文書管理と検索・引用が中心となる。複数システムを横断して調査するなら、LLMによる判断やツールの実行制御が追加候補になる。
AIコンサルタントは製品の人気で選ばない。「要件→評価軸→選択肢→検証→リスク→決裁」の道筋を示すことだ。本記事では、M社の未実装プロジェクトを用い、モデル、アプリケーション方式、データ基盤、クラウドを別々に評価し、最後に整合したアーキテクチャへまとめる。技術担当者と設計レビューできる粒度まで踏み込む。
第8回から引き継ぐ制約と選定の出発点
M社は、搬送装置・自動組立装置・検査装置を受注設計・製造する架空企業である。第7回ではUC-05「品目番号・検査状態の標準化」を先行条件とし、UC-01「案件別部品状況照会」とUC-02「承認済み仕様書検索」を初期対象に選んだ。UC-03「遅延リスク報告ドラフト」は拡張候補、UC-04「ERPへの無承認発注登録」は保留である。第8回はこの区分を機能要件FR-001〜FR-010と受入基準へ落とした。
重要なのは、AIモデルを変えてもこの業務上の責任境界が消えないことだ。案件IDと利用者権限の確認、正式BOM版の選択、検査保留ロットの除外、文書の承認版・閲覧権限の管理は、LLMの自然言語的な判断に任せない。業務システムと確定ルールで保証する。LLMが回答文を作っても、正本は在庫＝ERP、BOM版＝PLM、検査状態＝品質DBである。
【技術選定の入力資料／架空】A：業務要件と対象外、B：機能・非機能要件一覧、C：データ辞書と正本・改訂責任、D：API・文書検索の接続条件、E：認可・監査・情報区分、F：受入テストと未決事項台帳。ISS-01「ERPと品質DBで数量の意味が異なる」、ISS-02「BOM改訂履歴の扱い」、ISS-03「権限失効の索引反映」、ISS-04「応答時間の基準値未取得」は未解決として扱う。選定はこの空白を隠してはならない。
技術選定は四層に分ける
第一層は「AIを使う範囲」。完全一致検索や演算は従来型システム、曖昧な質問解釈・文章要約はLLM、文書根拠の抽出は検索とLLMの組合せ、と用途を切り分ける。第二層は「モデル」。指示遵守、ツール利用、長文処理、言語、応答速度、費用、提供契約を比べる。第三層は「アプリケーション方式」。単純なAPI呼出し、RAG、段階的ツール実行、ワークフロー、複数エージェントのどれが必要か判断する。第四層は「クラウド・運用基盤」。実行環境、データ接続、認証、ネットワーク、ログ、鍵管理、障害対応、サービス継続性を決める。
四層は独立ではない。モデル側のツール仕様はアプリ実装に、検索基盤の所在地はクラウド選定に影響する。ただし一括で採点すると、特定モデルが優秀という理由だけで、権限や保守に問題のある基盤まで採用されかねない。評価表と意思決定責任者を分け、各層の前提が他の層で満たされるか再照合する。
AIモデルの比較軸：ベンチマークではなく業務タスク
OpenAI、Anthropic、Googleなどのモデル群は、API体系、対応入力、ツール利用、出力制御、コンテキスト上限、課金体系が異なる。モデルのラインアップや提供終了日は頻繁に更新されるため、特定製品名の固定順位よりも、モデルID・バージョン・評価日を記録し直せる仕組みを優先したい。OpenAIのモデル一覧、Anthropicのモデル・廃止情報、GoogleのGeminiモデル一覧は更新確認の一次情報となる［1］［2］［3］。
評価項目は少なくとも次の八つとする。①仕様書に対する根拠付き回答の正確性、②構造化出力の妥当性、③ツール呼出し引数の適切性、④回答不能時に保留できるか、⑤日本語の技術用語と単位の扱い、⑥遅延分布と同時処理、⑦入力・出力・キャッシュ等を含む想定費用、⑧データ取扱い・契約・利用可能な地域。画像や図面も取り込むなら、そのモダリティも別項目にする。
単一の公開ベンチマーク点数で採用を決めるのは危険だ。M社に必要なのは「BOM改訂を区別」「品質保留を除外」「権限外の仕様書を出さない」ことである。専門データの小規模な評価セットを作り、候補モデルを同じプロンプト・同じデータ・同じ許容時間で評価する。結果を実測するのは将来の案件担当者であり、本記事には実測比較結果を記載しない。
【モデル評価票の設計例】ケースID／対象業務／入力／正本データ／期待挙動／禁止挙動／モデルID／プロンプト版／RAG索引版／正誤判定者／評価結果／再現条件を列にする。例えば「検査中のロットを在庫ありと回答しない」が期待挙動だ。根拠のない「99％正答」でなく、分母・対象・実施日・失敗分類を残す。評価セットには正常系・境界値・権限外・古い文書・矛盾する情報・API障害を含める。
モデルのAPI選択とクラウド基盤は別の決定
「OpenAIを主軸に学ぶ」と「AWSを主軸に設計する」は両立するが、同じ契約・同じ通信経路を意味しない。例えばAWS上のアプリから外部のOpenAI APIを利用する方式と、Amazon Bedrock経由の方式では、利用モデル、認証、料金、監査、データ経路が異なる。特定モデルをBedrockから利用できると断定せず、対象モデルとリージョンの対応を公式モデル一覧で必ず確認する［4］。
M社では少なくとも「AWS内で管理しやすい推論経路」と「AWS上の業務アプリから外部モデルAPIへ接続する経路」を比較候補とする。判断条件は、利用許可されるデータ区分、契約上の管理策、通信先、障害時の代替手段、モデル切替コスト、請求の可視性。モデル選択にはデータガバナンスが欠かせない。
また、AIエージェント開発のOpenAI Agents SDKと、クラウドのエージェント実行基盤は別の階層だ。SDKは主にアプリケーション側の実行制御を扱い、クラウド基盤は実行場所・認証・スケーリング・観測等を担う。両者の適合性は公式サポートや実装要件で確認する。SDK名だけでクラウドの機能が使えると判断しない。
アーキテクチャ候補A・B・Cを比較する
候補A：質問を汎用チャットに渡し、LLMに在庫数を推測させる。初期の見た目は簡単だが、正本・権限・版数・監査が欠けるためM社のFR群を満たせない。検証せず不採用とする。候補B：サーバー側で利用者を認証し、読み取り専用業務APIで部品状況を取得、承認済み文書を権限フィルタ付きで検索し、確定値と根拠をLLMへ渡して回答案を作る。UC-01・UC-02の第一段階候補となる。候補C：Bを基盤とし、複数のツール呼出しや状態管理・承認を備えたAIエージェントへ拡張する。UC-03等を扱う段階で必要性を再評価する。
候補Bを選ぶ根拠は「モデルの自律性が低いから」ではない。現行要件では、照会手順と利用するAPIが比較的決まっており、LLMの自由な計画能力より、権限・根拠・失敗時の停止が重要だからだ。業務データの突合を決定論的な処理に任せれば、故障解析と受入試験がしやすい。
RAGは承認済み文書の参照候補を検索し、LLMに文書断片を渡す仕組みとする。取得した文書に「このルールを無視せよ」と書いてあっても、それはデータであり上位指示ではない。検索結果・ツール応答・ユーザー入力の信頼境界を分ける必要がある。OWASPはプロンプトインジェクションをLLMアプリケーションの重要なリスクとして扱っている［5］。RAGで根拠を付けても、誤版参照や不正アクセスが解消するわけではない。
M社のAWS中心アーキテクチャ案
本連載でAWSを主軸にするのは学習上の方針であって、実在企業への普遍的な最適解を意味しない。M社の仮構成では、①社内Web画面、②認証・認可、③API入口、④Python業務オーケストレーター、⑤読み取り専用ERP・PLM・品質DB接続、⑥文書取り込み・権限付き検索、⑦モデル推論、⑧監査・監視、の境界を定義する。データ正本を一か所に複製するのではなく、参照時点と権限を制御する。
AWSの具体例としてAmazon API Gateway、AWS Lambdaまたはコンテナ実行、IAM、Secrets Manager、CloudWatch、Amazon S3、Amazon Bedrockを検討できる。エージェントの運用にはAmazon Bedrock AgentCoreのRuntime、Gateway、Identity、Memoryなどのモジュールが存在する［6］。ただしM社の第一段階では、そのすべてが必要と決まったわけではない。長期記憶や自律的なツール実行が不要なら採用しない。サービスごとに、可用性・最小権限・ネットワーク・費用を検討する。
外部システムのERP・PLM・品質DBは架空の既存資産として表現する。AWSのVPC内にあると仮定してはならない。オンプレミスや別ネットワークにある場合、接続方式、通信許可、可用性責任、API中継、遅延を追加確認する。文書をS3へ保存するか既存文書管理システムに残すかも、文書の承認版と権限失効の反映方法で決める。基盤図に置いたサービス名は機能候補であり、実装済みの設備一覧ではない。
Azure・Google Cloudも「同じ要件」で比較する
Azure側ではMicrosoft Foundry Agent Serviceが、設定中心のエージェントとコードを持ち込むHosted agentsなどの実行形態を提供する。Hosted agentsではフレームワークを持ち込み、Microsoft EntraのID、スケーリング、監視などと組み合わせられる［7］。ただし利用できる機能は構成と提供状態に依存する。M社のERP接続については、オンプレミスとの接続、ネットワーク分離、文書検索権限、監査基盤との統合を別途設計する。
Google Cloud側はGemini Enterprise Agent Platformを中心に、Agent RuntimeやModel Garden等でモデル利用・エージェント展開を検討できる［8］。またCloud Runは自作のAIエージェントやAPIのホスティング候補となり、Cloud SQLやFirestore等と組み合わせる方法もある［9］。AzureやGoogle Cloudを「AWSのサービス名の置換」だけで評価しない。マネージド機能に含まれる範囲、利用者IDの伝播、検索結果への権限適用、既存システムとの接続、障害責任の分界を確認する。
比較票には「推論・モデル提供」「エージェント実行」「外部ツール接続」「検索・データ」「認証・認可」「監視・評価」「データ所在地」「費用・契約」「移行容易性」の行を設ける。表に書くのは製品名だけではなく、導入時に確認する質問と必要証拠である。たとえば「認証・認可」なら、エンドユーザー、エージェント、ツール、下流ERPの各境界でどのIDと権限が使われるか。Foundryの公式資料も、管理者・呼出者・ツール接続の認証境界を分けて説明している［10］。
技術評価表の作り方：加点だけで決めない
M社向けの評価票では、まず足切り条件（Gate）を定める。G1＝業務データの取り扱いが企業ポリシー・契約に適合、G2＝ユーザー単位の権限を下流で強制できる、G3＝監査・ログの機密保護と保存設計が可能、G4＝障害時に安全に停止できる、G5＝正式版BOM・品質保留を正しく扱える。いずれか未確認なら「条件付き／保留」とし、点数が高くても自動採用しない。G1等の適否は架空M社で未検証である。
Gateを通過した候補について重み付き評価を行う。教材用の重み例は、セキュリティ・統制25点、業務正確性25点、根拠追跡15点、運用性15点、総所有コスト10点、移行柔軟性10点。各項目を1〜5で仮採点し、加重点＝Σ（重み×評点÷5）で100点満点に換算する。
【評価表の記入例／すべて仮の点数】候補B「確定API＋権限付きRAG＋LLM」は順に［4,4,5,4,3,4］と置く。この場合20＋20＋15＋12＋6＋8＝81点となる。候補C「初期から複雑な自律エージェント」は［3,4,4,3,2,3］と置き、15＋20＋12＋9＋4＋6＝66点となる。この点差は実測性能差でもクラウド固有の優劣でもない。要件を重視したときに設計方式の複雑さをどう評価するかを示す教育用計算である。評点の根拠、評価者、未検証条件、変更した場合の感度分析を添える。
実務では費用だけを「API単価」で比較してはいけない。トークン、検索、埋め込み、コンピュート、ログ、保存、ネットワーク転送、開発・運用人件費、再評価、障害復旧を含むTCOとして見る。出力トークンやツール実行回数が増える構成は、実利用パターン次第で費用と遅延が変わる。現時点の単価を記事に固定して比較順位を作ることはせず、最新料金表と実測量を掛け合わせる見積方法を第10回で扱う。
セキュリティ・データガバナンスを選定条件へ組み込む
「データを学習に使わないか」だけでは不十分だ。入力内容、保持期間、ログ・診断、契約形態、リージョン、外部連携、人的アクセス、削除や監査に対する条件を分解する。特定のデータ保護設定が有効かどうかは契約・サービス・API機能ごとに確認する。機密図面、取引先情報、製造条件を含むM社では、データ分類と許容送信先の承認が先になる。
LLMのシステムメッセージに「権限外の情報を出すな」と書くだけでは、情報漏えいを防げない。正本APIと文書検索の実行前に認可し、取得結果をユーザー権限に絞り、ログへ機密データを過剰に保存しない。監査には利用者・対象・モデル版・プロンプト版・参照文書版・ツール呼出し結果・権限判断の識別情報を残し、実データの保存は必要最小限とする。API資格情報は専用の秘密情報管理に預け、エージェントが持つ権限を用途別に制限する。
NIST AI RMFはGovern・Map・Measure・Manageの四機能を示し、リスクをライフサイクル全体で管理する考え方を提示している［11］。選定時に「見つかったリスク」「許容できる範囲」「残余リスクの決裁者」を書き、実運用後の再評価を含める。ベンダーが機能を提供していることと、導入企業の責任がなくなることは別問題である。
技術選定からPoC計画へ：何を証明すべきか
第9回の成果は、最終契約書でも最適宣言でもない。業務要件に整合する構成仮説と、残る不確実性を検証する計画である。M社では最初にUC-05の標準化の完了証拠を集め、次にUC-01の在庫・検査状態の突合、UC-02の承認文書検索と権限チェックを検証対象にする。モデルの文章品質はその後に評価する。数字の一致を確定させずに応答の自然さを評価しても、本番判断に必要な証拠にならない。
【PoC検証票の例／未実施】P01：正式BOM版とロット状態の突合に誤りがないか。P02：旧版・未承認文書の検索結果表示を防ぐか。P03：権限変更後の文書検索で露出がないか。P04：業務APIが停止したら保留と手動経路へ切り替わるか。P05：必要な回答の根拠・版数・時点を示せるか。P06：応答時間・費用が想定負荷の下で許容範囲に入るか。P07：構成・モデル変更時に回帰評価を実施できるか。各ケースに責任者、前提、入力データ版、合否基準、証拠、停止条件を設定する。受入基準の数値は業務部門と合意してから確定させる。
モデル比較が不十分なら「暫定選定」と明記する。安全上の重大な不適合、権限越え、契約上のデータ送信不適合が見つかった場合は、点数に関係なく中止または再設計する。将来のエージェント拡張では、人間の承認、ツール単位の権限、実行回数上限、再試行、状態復旧を追加評価する。第13〜20回ではこれらの内部構造と設計を詳しく扱う。
成果物：技術選定評価表と意思決定記録
【成果物A：技術選定評価表／架空の記入例】案件=M-AI-01、対象=UC-01／UC-02、前提=UC-05標準化完了待ち、候補=B（読み取り専用API＋権限付き文書検索＋LLM回答案）、対抗=C（初期から自由な複数ツール実行）、除外=A（LLM単独で在庫数生成）。暫定推奨=B、理由=確定データと生成処理の責任分離、権限・障害時動作を検査しやすい。留保=ISS-01〜04、モデル性能未比較、クラウド契約条件未評価。
【成果物B：アーキテクチャ意思決定記録（ADR）／架空】ADR-009。決定対象=初期段階の処理方式。状態=提案中。背景=UC-01・02の正式値と承認済み文書を根拠とした回答が必要。選択=B。却下理由=Aは正本・権限を満たさない、Cは現時点の業務フローに比して実行自由度とテスト負荷が過剰。影響=業務API契約、検索索引の版管理、監査方式を事前に定義。再検討条件=UC-03の業務調査、API制約変更、権限要件変更、PoC評価失敗。決裁=未実施。
【成果物C：クラウド比較レビュー項目】①モデル・機能の提供リージョン、②機密情報の送信先と保持条件、③社内IdPと下流APIの権限連動、④プライベート接続、⑤監視・証跡の横断追跡、⑥サービス別請求とコスト上限、⑦リリース・撤退・移行時のデータ移送、⑧長期サポートと運用責任。AWS・Azure・Google Cloudについて、各項目を「公式資料で確認／設計で対応／未確認」に分類する。未確認を適合扱いにしない。
選定会議での合意形成と典型的な失敗
会議の進行例は、①守るべき業務要件、②採点前に満たすGate、③比較した設計方式、④暫定推奨と反対意見、⑤検証しなければ決裁できない条件、⑥PoC責任者・判定日、の順。AIコンサルタントは技術選択の根拠を説明するが、企業のセキュリティ・業務・予算の正式承認を代行しない。選定表は投票用の表ではなく、意思決定を再現するための文書である。
失敗①「ベンダーのモデル一覧だけで最適とする」。対策はM社固有の質問と正本に基づく評価。失敗②「RAGで回答が正確になると保証する」。対策は承認版検索と根拠照合、失敗時保留。失敗③「AWSを使えば他サービスもAWS内に閉じると誤認する」。対策は実際のモデル呼出先とデータ経路を図示。失敗④「エージェントを使えばシステム連携が簡単になる」。対策はAPI契約、権限、例外、監査の費用を見積もる。失敗⑤「クラウド比較をサービス名対応で終える」。対策は責任分界と顧客の既存運用条件を比較。失敗⑥「PoCで良ければ本番も問題ない」。対策は負荷、障害、継続運用、セキュリティを別に判定する。
まとめ：選ぶのは「一番強いAI」ではなく「要件を満たす構成」
M社の初期ユースケースには、確定した業務数値をAPIで照会し、権限・版数を制御したRAGを用い、LLMは質問解釈と回答案作成に限定する方式が暫定候補となった。これは実測に基づく採用決定ではない。モデル評価、データ接続、契約、ネットワーク、コスト、受入テストの未確認事項が残る。AWSを学習の主軸に据えつつ、Azure・Google Cloudも同じ要件と判断基準で比較する。
AIコンサルタントの技術選定は、選択肢を幅広く知ること以上に、「なぜ採るのか」「何が未確認か」「どこで失敗したら止めるのか」を説明できることが重要だ。次の第10回では、ROI・TCO、PoC計画、投資判断を扱い、この構成仮説が経済性と実現可能性を備えるかを検討する。
参考資料（一次情報を優先／確認日：2026年11月4日）
［1］OpenAI, Models. https://platform.openai.com/docs/models
［2］Anthropic, Model deprecations. https://docs.anthropic.com/en/docs/about-claude/model-deprecations
［3］Google AI for Developers, Gemini API Models. https://ai.google.dev/gemini-api/docs/models
［4］AWS, Amazon Bedrock Models at a glance. https://docs.aws.amazon.com/bedrock/latest/userguide/model-cards.html
［5］OWASP, Prompt Injection. https://genai.owasp.org/glossary/prompt-injection/
［6］AWS, Amazon Bedrock AgentCore Developer Guide. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/
［7］Microsoft Learn, Foundry Agent Service. https://learn.microsoft.com/en-us/azure/foundry/agents/overview
［8］Google Cloud, Gemini Enterprise Agent Platform overview. https://docs.cloud.google.com/gemini-enterprise-agent-platform/overview
［9］Google Cloud, Host AI agents on Cloud Run. https://docs.cloud.google.com/run/docs/ai-agents
［10］Microsoft Learn, Identity and access for Foundry Agent Service. https://learn.microsoft.com/en-gb/azure/foundry/agents/concepts/identity-access-overview
［11］NIST, AI RMF Core. https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
note投稿用ハッシュタグ
#AIコンサルタント #AI導入 #技術選定 #システムアーキテクチャ #LLM #RAG #AIエージェント #AWS #Azure #GoogleCloud #生成AI #製造業DX
