NEC、12万人対応のClaude基盤を2週間で構築──全社AI導入で「最初に決めるべきこと」

• NECは最大12万人対応のClaude基盤を2週間で本番構築しました
• 国内推論・Entra ID認証・監査・コスト管理を稼働初日から整えています
• MCP接続のOAuth差は認可中継サーバーで吸収し段階的に広げています

NECは、最大12万人が利用できる「Claude Cowork on Amazon Bedrock」の全社基盤を、要件定義からわずか2週間で構築しました。6月1日に稼働し、8月18日時点の利用者は1万1,000人に達しています。

驚くべきは、単にClaudeを全社員へ配ったことではありません。プロンプトと応答の推論を国内に閉じ、認証・監査・コスト管理まで「使い始める初日」に間に合わせたことです。

全社AI導入の難所は、モデル選定より前にあります。

2週間で最大12万人対応の基盤を構築

NECが本番環境の設計に着手したのは5月18日。全社利用を始めたのは6月1日です。

通常なら数カ月かかるセキュリティ設計、社内認証との連携、動作確認、性能テストを2週間に凝縮しました。最大12万人に対応する設計で、8月18日時点では1万1,000人が利用しています。

ここは分けて見る必要があります。12万人は実利用者数ではなく、基盤が対応できる最大規模です。また、公開されたのは安定稼働と利用拡大まで。時間削減や生産性向上といった業務効果の定量測定は、今後の課題とされています。

それでも、大規模な全社環境を短期間で立ち上げた意味は大きいでしょう。まず証明されたのは、安全に使い始められることです。

▶︎ 一次情報：NEC、Claude Cowork on Amazon Bedrockを12万人規模で2週間構築

Claude EnterpriseではなくBedrockを選んだ理由

NECには、大きく2つの選択肢がありました。AnthropicのClaude Enterpriseを契約する方法と、Claude Desktopの推論先をAmazon Bedrockにする方法です。

Claude EnterpriseにはWeb管理画面、UI上のユーザー管理、Analytics API、RBACなどがあります。一方、NECが最優先したのは、プロンプトと応答を含む推論を日本国内に閉じることでした。

そこでNECは、日本国内のAWSリージョン間だけで処理を分散する推論構成を採用しました。利用者IDはMicrosoft Entra IDと連携し、AWS Identity and Access Management（IAM）で利用権限を管理します。会話履歴は端末内に保存されます。

Claude Enterpriseで先に提供される機能や、Bedrock接続では提供されない機能もあります。それでもNECは、国内での推論と自社のガバナンス要件を優先しました。

▶︎ 参考：Claude Desktopのサードパーティープラットフォーム構成

「後から変えにくい」が初日の設計を決めた

NECが急いだ理由は、利用開始日が迫っていたからだけではありません。一度使い始めると、後から利用方式を変更するコストが大きくなるからです。

NECが方式を決めた2026年5月時点では、Claude EnterpriseとAmazon Bedrock接続の間で、会話履歴、メモリ、プロジェクト設定を引き継ぐ仕組みがありませんでした。スキルも、ファイルとして移せる一方、一括抽出や有効状態の移行には対応していませんでした。

その後、Anthropicは8月11日にサードパーティープラットフォーム向けの履歴インポートを追加しています。現在は会話、プロジェクト、メモリを一括コピーできますが、管理者の許可が必要で、継続同期ではありません。添付ファイルやプロジェクトの知識ファイルも、通常のメンバー向けエクスポートには含まれません。

つまり、移行手段は改善しても、完全に同じ環境をそのまま移せるわけではありません。数万人が使い始めた後に方式を変更する難しさは残ります。

だからNECは、使い始める日に、使い続けられる環境を用意しました。

▶︎ 参考：Claude Desktopへの履歴インポート仕様

最も工数がかかったのはMCP接続

今回、技術面で最も工数を要したのは、外部SaaSと接続するMCP（Model Context Protocol）の部分でした。MCPは、AIから社内システムやSaaSへ接続するための共通規格です。

規格が共通でも、接続先ごとにOAuthの実装は異なります。OAuthは、パスワードをClaudeへ渡さず、利用者が許可した範囲だけ外部サービスへアクセスさせる認可の仕組みです。

実際には、OAuthクライアントを自動登録できるサービスと、事前登録が必要なサービスがあり、クライアント認証の方式にも差がありました。「接続できる」と「企業として安定運用できる」の間には、想像以上に深い溝があります。

NECは、この差を吸収する独自の認可中継サーバーを構築しました。ただし、このサーバーが社内公開されたのは7月18日です。MCP接続まで全部を2週間で完成させたわけではありません。

▶︎ あわせて読みたい：MCPは道具、A2Aは同僚——接続と委任の違い

MCPは管理者配布と段階展開

公開情報で確認できるのは、管理者がMCPサーバーの設定を端末へ配布し、利用者がClaudeの画面から用意されたコネクタを追加する運用です。

NECは、接続先ごとに「認証が成立するか」と「期待どおりに動作するか」を検証しています。認可中継サーバーの公開後も、接続可能なサービスを順次広げています。少なくとも公開された範囲では、管理者主導の事前検証と段階的な展開です。

一方、未承認のローカルMCPを禁止しているか、現在許可しているSaaS名、読み取りと更新の範囲、実行時に人間の承認を求めるかといった具体的な権限ポリシーは公開されていません。ここを推測で埋めてはいけません。

分かっているのは、「MCPで何でもつなぐ」ことを先にしなかった点です。接続数より、会社が動作と認可を管理できることを優先しています。

▶︎ あわせて読みたい：Claudeforceが埋める「接続」と「仕事」の溝

全社AI導入で最初に決めるべきこと

今回の事例から見えてくるのは、全社AI導入の初期設計で優先すべきものです。

モデルの性能比較はもちろん重要です。ただ、会話履歴や設定が蓄積し、認証・権限・外部接続が組織全体へ広がった後では、利用方式の変更は難しくなります。

最初に決めるべきなのは、データをどこで処理・保存するのか、誰が利用できるのか、操作をどう追跡するのか、利用量とコストをどう管理するのか。そしてMCPについて、誰がどの接続を承認し、どの順番で展開するのかです。

NECは中核基盤を6月1日に稼働させ、MCPの認可中継は7月18日に追加しました。この順番も示唆的です。認証・監査など後から変えにくい土台は初日から、外部接続は検証しながら広げる。

これから企業へAIエージェントを導入する場合、最初の質問は「どのモデルを使いますか」ではありません。「使い始めた後に変えにくいものは何ですか」から始めるべきだと思います。

よくある質問（FAQ）

Q1. NECはなぜClaude EnterpriseではなくAmazon Bedrock経由を選んだのですか？

国内リージョンのみで推論を完結させたかったためです。プロンプトと応答を含む推論を日本国内に閉じ、利用者IDをMicrosoft Entra IDと連携させ、AWS IAMで権限管理する構成を優先しました。Claude Enterpriseにある一部機能より、国内推論とガバナンス要件を上位に置いた判断です。

Q2. 12万人という数字は実際の利用者数ですか？

いいえ、基盤が対応できる最大規模です。8月18日時点の実利用者は1万1,000人で、公開されているのは安定稼働と利用拡大までにとどまり、時間削減や生産性向上の定量効果測定は今後の課題とされています。

Q3. 導入で最も工数がかかった部分は何ですか？

外部SaaSと接続するMCP（Model Context Protocol）です。接続先ごとにOAuthの実装や認証方式が異なるため、NECはその差を吸収する独自の認可中継サーバーを構築しました。ただしこのサーバーが社内公開されたのは7月18日で、MCP接続まで含めた全部を2週間で終えたわけではありません。

企業でのAI活用や最新事例を継続して追いたい方は、YouTubeでも詳しく解説しています：https://www.youtube.com/@iketomoch

ClaudeやAIエージェントを実務へ落とし込む方法は、『Claude 最強のAI自動化術』で体系的にまとめています：https://amzn.to/4eTUVG1

読むだけでなく実際に手を動かし、自分専用のAIツールや仕組みを作りたい方は、いけともハンズオンのアーカイブもご覧ください：https://handson.workstyle-evolution.co.jp/

■合わせて読みたい

■関連記事