Amazon Web Services ブログ

株式会社アテナが Claude Code on Amazon Bedrock で実現した、非エンジニア向け生成 AI 全社展開

本ブログは 株式会社アテナ 様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。

はじめに

みなさんこんにちは。AWS の大松と倪 (ニオ) 、アテナ デジタル戦略部の河野拓矢です。

みなさんは普段、生成 AI を何に使っていますか？ 個人で趣味や効率化、あるいは新しい挑戦をするために使ってる人もきっと多いでしょう。いろんなことに使えて楽しいですよね。。。ところが、会社全体で使うとなると話は別です。

業務で生成 AI を活用している方も多いと思います。しかし、生成 AI を全社に広げようとすると、席数で契約したライセンスのうち、ほとんど使わない社員の分まで毎月費用がかかったり、その一方で、よく使う社員ほど利用上限に達してしまう状況が発生し効率的に利用できていなかったりしてませんか？ また、ID 管理やデータの機密情報の扱いなど、さまざまな面で苦慮していませんか？

本記事では、アテナ様が非エンジニアの社員を中心とした生成 AI の全社利用基盤を Amazon Bedrock を利用して構築した事例を紹介します。

特徴は、社員が普段使っている Microsoft Entra ID のアカウントと連携することで、 ID 管理の運用負担を増やすことなく、ユーザーおよび管理者に負担の少ないアクセス環境を実現した点です。また、AI クライアントの振る舞いも端末管理の仕組みから一括で統制しています。

本ブログでは、どのように設計して課題を解決したのか、そして PoC（概念実証）で実測したコストから何が見えたのかを共有します。

席数契約で生成 AI を全社展開する難しさ

アテナ様は、企業とその顧客とのコミュニケーションを支える BPO サービスを提供している企業です。
DM の企画から印刷・封入・発送までを一括で担うメーリングサービスでは年間 1 億 5,000 万通、東京・大阪・名古屋の物流センターを使うロジスティクスサービスでは年間 500 万個を取り扱っています。
書類受付から電話対応までを引き受けるカスタマーサポートサービス、全世界 220 ヵ国以上の国旗を扱うナショナルフラッグサービスも展開し、延べ 1,500 社以上の業務を受託してきました。

同社は 2025 年頃から、生成 AI を日常業務のサポートとして全社で活用してきました。利用者の大半はエンジニアではなく、現場の業務担当者です。Claude の Team プラン（Standard シート、1 席あたり月額 25 ドル）も 100 名弱で契約し、業務に取り入れていました。

転機は 2026 年 6 月頃です。デジタル戦略部の河野様は、Claude Code をデジタル戦略部だけでなく全社で使ってもらいたいと考えました。しかし、Claude と Amazon Bedrock を組み合わせて全社展開するための情報が少なく、パッケージとして提供している企業もほとんどありませんでした。そこで河野様は自ら構築することを決め、コストとセキュリティを含めた提案を経営層に行い、了承を得て開発に着手しました。

全社展開を検討する中で、課題は 4 つに整理されました。

課題 1: 席数契約の固定費と利用の偏り

席数契約では、実際に使っているかどうかにかかわらず契約人数分の費用が毎月確定します。使わない社員の分まで費用がかかる一方で、よく使う社員はトークンの利用上限に達して作業が止まることがありました。Enterprise プランも検討しましたが、1 席あたり月額 20 ドルに加えてトークンの従量課金となるため、使わない社員の固定費が残る構造は変わりません。

課題 2: ID 運用のコスト

利用者の大半が非エンジニアであり、入社・異動・退職のたびに棚卸しも必要になります。そのため本システムのために新たなユーザー管理基盤を用意することは、現実的ではありませんでした。

課題 3: 認証情報の扱い

静的な API キーを配布すれば手軽に動作しますが、キーが端末に長期間残ります。BPO 事業者として顧客の機密情報を扱う立場から、静的な API キーを端末に長期保存させる運用は避けたいと考えていました。

課題 4: 機密情報とデータレジデンシー

業務で機密情報を扱うため、Web 検索や Web ページ取得の機能を経由して情報が外部に出ることは避けたいと考えていました。
入力内容がモデルの学習に使われないこと、そしてデータの処理を日本国内に限定することも要件でした。

一方で、同社には活かせる資産がありました。

Microsoft Entra ID を全社の ID 基盤として運用しており、その管理はインフラ部が担っています。端末管理も、MDM（モバイルデバイス管理）とレジストリ配布によって一元化する運用が確立していました。全社展開を実現するには、「コストを実際の利用に連動させる」「ID と端末の統制を既存の運用にそのまま載せる」「機密情報を外に出さず、処理を日本国内に閉じる」の 3 点を同時に満たす必要がありました。

選択肢を比べて見えた、Amazon Bedrock を選ぶ決め手

アテナ様は Amazon Bedrock に決める前に、複数の選択肢を比較しています。
いずれも技術的には実現できる方法ですが、同社の環境や利用者像と照らし合わせると、それぞれに見送る理由がありました。

検討した選択肢 見送った理由
Claude の Team / Enterprise プランを継続・拡大する 使用量の少ない社員の分も固定費用が発生し、コストの最適化にならない
Amazon Elastic Compute Cloud (Amazon EC2) 上に Claude Code を導入し、リモートデスクトップで接続して使う 同社の環境に合わず、コストと運用負担の面で断念
利用者ごとに IAM ユーザーを発行して権限を整理する 同社の環境に合わず、コストと運用負担の面で断念
API を直接呼び出す、または AWS Cloud Development Kit (AWS CDK) などで独自に開発する 利用者は技術者ではないため、操作画面をゼロから作る必要がある
ローカル LLM を自社で運用する 求める用途を満たすにはサーバースペックが大きくなりすぎ、現実的でない
IAM Identity Center や Organizations と連携した ID・権限管理 個別の ID 管理基盤の運用負担の面で断念

その上で Amazon Bedrock を選んだ理由は 4 つあります。

理由 1 : データの処理を日本国内に閉じられる

Amazon Bedrock の日本国内クロスリージョン推論を使うと、推論リクエストは東京リージョンと大阪リージョンにのみルーティングされます（日本国内クロスリージョン推論のご紹介）。呼び出しログは自社の AWS アカウント内に保管でき、モデルプロバイダーが利用者のプロンプトや出力にアクセスすることもありません（Amazon Bedrock のデータ保護）。

同社が検討した範囲では、既存のアプリケーションを使いながら日本国内に閉じた形で生成 AI を活用できる環境は Amazon Bedrock だけでした。データの処理が国内にとどまることは、BPO 事業者として顧客と契約を結ぶうえでも強みになります。

理由 2: 既存のアプリケーションをそのまま使える

Claude Desktop の接続先を Amazon Bedrock に向けるだけで、利用者は使い慣れた画面のまま業務を続けられます。非エンジニアが使う前提では、独自の画面を開発・保守しなくてよい点は大きな利点でした。

理由 3: 既存の ID 基盤をそのまま使える

Entra ID と連携できるため、入社・異動・退職といった社員のライフサイクルの管理を既存の ID 運用に一元化できます。

理由 4: 使った分だけの従量課金である

使わない社員の費用は発生しません。よく使う社員にどこまで使ってもらうかは、自社で上限やモデルの選び方を設計して決められます。

設計の参考にしたのは、AWS のブログ記事「Claude Code on Amazon Bedrock のデプロイパターンとベストプラクティス」です。同記事では認証方式を比較したうえで、本番環境向けには ID プロバイダー (IdP) と IAM を直接連携させる方式が推奨されています。

アテナ様はこの比較をもとに自社の IdP を直接連携させるパターンを選択しました。実装には、同記事で紹介されている Guidance for Claude Code with Amazon Bedrock を参考にしています。

Claude Desktop × Amazon Bedrock の全体像

アテナ様が構築したのは、Claude Desktop のバックエンドを Amazon Bedrock に向け、認証を Entra ID の OIDC フェデレーションで通す構成です。利用者から見れば普段どおりアプリケーションを起動して Entra ID にサインインするだけですが、その裏側では毎回、有効期限付きの一時的な認証情報が発行されています。

図: Claude Desktop × Amazon Bedrock の構成

認証とモデル呼び出しの流れは次のとおりです。

  1. Claude Desktop が、MDM で配布されたレジストリ設定に従ってプロファイルを読み込み、credential_process のヘルパーを実行する
  2. ヘルパーが Entra ID に対して OIDC でサインインする
  3. 取得した ID トークンを AWS Security Token Service (AWS STS) に渡す
  4. AssumeRoleWithWebIdentity によって、フェデレーション用の IAM ロール（例: FederatedRole）の一時的な認証情報（有効期限 12 時間）を取得する
  5. その認証情報で、日本国内クロスリージョン推論のプロファイルを経由して Claude のモデルを呼び出す
  6. 呼び出しログを Amazon CloudWatch Logs と Amazon Simple Storage Service (Amazon S3) に保存し、AWS Key Management Service (AWS KMS) のキーで暗号化する

この構成のポイントは、端末に静的な API キーも、長期間有効な認証情報も置かない点にあります。端末側にあるのは「どこにサインインしに行くか」という設定情報だけです。

IAM ロールの権限は、日本国内の推論プロファイルを経由したモデル呼び出しに絞り込んでいます。IAM ロールの有効期限は 12 時間で、Entra ID 側のセッション保持時間（12〜24 時間程度）と整合するように設定しています。退職者の Entra ID アカウントを無効化すれば、発行済みの認証情報が有効期限を迎えた時点で Amazon Bedrock への到達経路が閉じ、AWS 側で個別の後処理をする必要もありません。

利用させる機能も絞り込んでいます。許可しているのはチャットとコーディング支援（Claude Code）で、それ以外の機能は意図的に無効化しています。Web 検索と Web ページ取得は禁止し、特定業務の自動化に必要な Playwright MCP だけを許可リスト方式で使えるようにしました。Claude Code は作業の途中で Web 検索を使うことがあるため、機密情報が外部に持ち出される経路をあらかじめ塞いでいます。

統制の「置き場所」を決めるまでの 2 週間

河野様は 2026 年 6 月の本格着手から 2～3 か月で構成を完成させました。設計と開発は河野様が担当し、社内のセキュリティ管理者が設計内容をレビューして抜けの有無を確認する体制で進めました。その中で最も時間を要したのは、実装そのものではなく、「どの設定を、どこで統制するか」の見極めと、その検証の繰り返しでした。

生成 AI の全社展開では、統制できる場所が複数に分かれます。ID 基盤である Entra ID、AWS、端末のレジストリ、そしてアプリケーション自体の設定です。しかも、Amazon Bedrock 側では制御できても Claude 側では制御できない、あるいはその逆といった違いがあり、それらを横並びで比較した資料は見当たりませんでした。

そのため、設計した統制内容をセキュリティ管理者がレビューし、指摘事項に基づいて河野様がレジストリや設定ファイルを調整し、モックを作って挙動を 1 つずつ確かめ、再度レビューに回す、というサイクルを繰り返しました。利用者の作業を妨げない可用性と、情報を外に出さない機密性の両立点を細かく詰めていく作業であり、この設計に 2 週間程度を費やしています。前述のガイダンスに同梱されているものを利用することで、一から認証の仕組みを作らずに済み、多くの時間をこの統制の検討に充てることができました。

最終的に、次のように整理しました。

統制したいこと 統制した場所 アテナ様での設定
誰が使えるか(入社・異動・退職) Entra ID 既存の ID 運用をそのまま利用(管理はインフラ部)
AWS 上で何ができるか IAM ロールと AWS STS 有効期限 12 時間の一時的な認証情報。日本国内の推論プロファイル経由の呼び出しのみ許可
端末の接続先と使える機能 端末のレジストリ(MDM で配布) 接続先(Amazon Bedrock、東京リージョン)の固定、許可するモデル、トークン使用量の上限、Web 検索・Web ページ取得の禁止、Playwright MCP の許可
操作時の確認表示などの細かな挙動 アプリケーションの管理設定ファイル 操作の許可・拒否を確認する表示の出方を調整
記録・監視・コスト AWS の各サービス 呼び出しログの保管と暗号化、予算超過の通知、脅威検知、セキュリティ状況の可視化

端末側の統制を MDM に寄せた理由について、河野様はこう説明しています。

「手作業で設定すると運用負担がかかり、分かる人にしかできない。MDM ならこのレジストリキーを入れればいいと明確なので、管理を一元化できてシンプルで綺麗な構成になった」。(参考: Configuration reference – Anthropic )

ID 基盤・端末管理・AWS 権限という 3 つのレイヤーを、それぞれが得意な場所で統制するという役割分担です。AWS 側をどれだけ堅牢に作っても、アクセス元の端末が統制されていなければリスクは残ります。端末側の統制まで踏み込んでいる点が、この構成の特徴です。

全社への配布方法も、企業ごとの事情に合わせて組み合わせられるようにしました。ディレクトリの権限を厳格に管理している企業であれば、MDM でそのまま配布できます。一方、アテナ様の環境では MDM による配布に時間がかかるため、初回のセットアップは実行ファイルやバッチにまとめ、各自に実行してもらう方法も用意しました。

初回セットアップ後のモデルの更新などは、レジストリキー 1 行程度の変更を MDM で配布するだけで済みます。この組み合わせにより、利用者の作業を最小限に抑えたまま、4 名のスモールスタートから 28 名の PoC、そして全社へと段階的に広げられる仕組みになっています。

ユーザー別のコスト把握では、途中で方針転換がありました。当初は Amazon Bedrock 全体にコスト配分タグを付ければユーザー別の内訳が取れると考えていましたが、実際には取得できず、モデル別の設定が必要だと分かりました。IAM プリンシパル単位のコスト配分も検討しましたが、同社の環境の構成上、利用できませんでした。

そこで、Amazon S3 に保存した呼び出しログを集計し、利用者別・モデル別の費用を算出する方法を取っています。後述する PoC のコスト実測も、この方法で行いました。

セキュリティとコストの統制も組み込んでいます。呼び出しログは CloudWatch Logs と Amazon S3 の両方で 90 日間保持し、いずれも AWS KMS のカスタマーマネージドキーで暗号化しています（キーの自動ローテーションは 365 日）。

AWS Budgets では、全体の利用金額があらかじめ決めたしきい値を超えるとメールで通知されるようにしました。IAM ロール、OIDC プロバイダー、ログ配信、KMS キー、Budgets の設定は AWS CloudFormation のスタックとして管理しており、構成をコードから再現できます。脅威検知には、既存のワークロード向けに有効化していた Amazon GuardDuty を流用しました。さらに、AWS 環境全体のセキュリティ状況を見通すために AWS Security Hub を追加しています。

実測で見えた「使う人に投資する」という考え方

アテナ様は 2026 年 9 月 7 日に 28 台へ配布し、PoC を開始しました。コストについては当初の見込みとは異なる、しかし全社展開の判断に役立つデータが得られました。業務面と利用者の意識面では、想定を超える変化も起きています。

総額よりも「利用の偏り」が見えた

2026 年 9 月 7 日から 9 月 17 日までの 9 営業日、社内の有志 22 名に Amazon Bedrock 経由の Claude Desktop を使ってもらい、費用を実測しました。費用は、自社アカウントの Amazon S3 に保存された呼び出しログを全件集計して算出しています。 比較対象は Claude の Team プランの席単価（月額 25 ドル）です。

※ 月額換算は「実績 ÷ 9 営業日 × 20 営業日」で算出した推定値です。 実作業の回数は利用者の操作に伴う呼び出しの数で、クライアントが自動で発行する接続確認などの呼び出しは除外しています。

結果は、「従量課金にすればコストが下がる」という当初の見込みとは異なるものでした。22 名の月額換算の合計は Team プラン 22 席分の約 3.9 倍となり、22 名のうち 12 名は席単価を上回っています。参加者の中央値でも、席単価の約 1.7 倍でした。

ただし、今回の参加者は利用意欲の高い有志が中心です。また、Team プランには利用上限がある一方、今回の PoC では 1 人あたり 300 万トークンの上限の範囲内で自由に使ってもらっており、単純な比較はできません。従来のプランでは、よく使う社員ほど利用上限に達して作業が止まることがありました。

むしろ、はっきり見えたのは利用の偏りです。1 稼働日あたりの費用は、最も多い利用者と最も少ない利用者で約 51 倍の開きがありました。上位 2 名だけで、全体の費用の約半分を占めています。


費用を分けた要因は、利用回数だけではありません。上位モデル（Claude Opus）の利用割合が 99% の利用者は 1 回あたり約 0.25 ドルだったのに対し、実作業の回数が最も多かった利用者（1,609 回）は Claude Opus の利用割合が 2% で、1 回あたり約 0.07 ドルにとどまりました。モデルの選び方によって、1 回あたりの費用に 3 倍以上の差が出ています。

アテナ様はこの結果を、総額の削減よりも、利用実態に応じたコスト配分を判断する材料として捉えています。Amazon Bedrock では利用者別・モデル別の費用を実測できるため、誰にどのモデルとどの上限を割り当てるかを、データに基づいて決められます。

河野様は、従量課金になったことで使う人に正しく投資できるようになった点を強みに挙げています。

全社約 200 名に展開すれば利用の少ない社員の割合が増えるため、全体の平均では Team プランの席単価を下回る可能性もあると同社は見ています。ただし、これは PoC から直接導いた結果ではなく、利用の少ない社員が多数を占めるという前提に基づく仮説です。

なお、日本国内クロスリージョン推論は、グローバルのクロスリージョン推論と比べて単価が 10% 高く設定されています（日本国内クロスリージョン推論の料金）。同社はこの差額を、データの処理を国内に閉じるための対価と位置づけています。

業務時間の半分程度を削減し、提案の作り方も変わった

業務面の効果も表れています。河野様の体感では、業務時間の半分程度を削減でき、生まれた時間をレガシーシステムの刷新に充てられるようになりました。

提案や見積もりのスピードも上がっています。社内資料の約 9 割は AI を使って作成されるようになり、提案資料や社内説明資料、分析に活用されています。

今では顧客ごとに分析したうえで、より最適な提案内容を組み立てられるようになりました。

使い心地はほぼそのまま、顧客への説明はむしろ簡単になった

利用者の使い心地は、従来のブラウザ版の Claude.ai とほとんど変わりませんでした。導入当初は、操作の許可・拒否を確認する表示が従来より多いと感じる声がありましたが、アプリケーションの管理設定ファイルを調整して解消しています。

自分でフォルダを作成して AI に読み込ませられる点は便利だと好評で、より快適に使えるようになったという声も上がっています。ブラウザ版で使っていたプロジェクト機能の役割は社内のファイルサーバーがほぼ置き換え、従来の業務の流れに近い形で使えるため、利用者は戸惑わずに移行できました。

また、利用するリージョンを日本国内に限定しているため、同社の顧客に対して AI の利用を説明しやすくなったという声もあります。

非エンジニアが自ら AI の振る舞いを設計し始めた

予想外だったのは、ブラウザ版 から Claude Desktop に変更することで、カスタマイズの余地が増え、利用者が Claude について自ら学ぶようになったことです。

これまで、AI への指示や前提をまとめておく CLAUDE.md のような設定ファイルを使っていたのは開発者だけで、説明してもなかなか響きませんでした。ところがチャットとコーディング支援の機能を公開すると、4 名のスモールスタートの段階から、非エンジニアの社員が自分のファイルサーバーに CLAUDE.md を置き、フォルダ構成を工夫しながら AI の振る舞いを自ら作り始めました。「毎回同じ出力をさせるにはどうすればよいか」といった相談も増え、AI の仕組みを理解しようとするやり取りが社内で活発になっています。Playwright MCP を公開した際も、ブラウザ自動化の意味が分からなかった社員が各自で使い方を工夫し始め、AI リテラシーを積み上げるきっかけになりました。

組織の文化にも変化が表れています。以前は知っている人に聞いて作業を進めていましたが、ナレッジを AI に蓄積し、まず AI に確認してから作業を進める文化が生まれつつあります。特に営業部門は中間層が少なく若手が多いため、業務を回すために AI を活用する場面が増えています。以前全社に公開していた SaaS 型の AI サービスでは、利用者から要望が上がっても「自社で作っているものではないので対応できない」で終わっていました。

今回の構成はカスタマイズの自由度が高く、利用者の意見をデジタル戦略部が反映できるため、利用者との一体感や、受け入れられているという安心感にもつながっています。

推進責任者と経営層の声

推進責任者の河野様は、次のように振り返ります。

本環境の設計・開発は私が担当しましたが、社内調整や PoC にご協力いただいた方々がいなければ、形にすることはできなかったと思います。 おかげさまで、社員が安心して AI を活用できる環境を整えることができ、心より嬉しく思っております。 AWS 大松様、倪 (ニオ) 様をはじめ、ご協力いただいたすべての方に感謝申し上げます。

経営層からは、次のコメントが寄せられています。

人材の確保が難しい昨今、業務での AI 活用は必須だと考えています。 一方で、BPO 企業である当社にとって、セキュリティは何よりも優先すべきものです。 その両立を可能にするのが、この Amazon Bedrock の環境です。 今後は AI を組み込んだ業務設計を進め、セキュリティを最優先に構築したこの環境を基盤として、お客様へのサービス展開を広げていきます。

(左から、AWS 大松、アテナ河野様、倪 (ニオ))

今後の展開、全社へ 向けた利用ルールの整備

全社への配布に向けて、PoC の結果をもとに 2 つの対策を進めています。

1 つ目は、費用が高くなる利用の抑制です。 費用の要因がモデルの選び方と利用回数の両方にあることから、トークン使用量の上限に加えて、既定のモデルを Claude Sonnet とし、Claude Opus は必要なときだけ許可するといった利用ルールを検討しています。

2 つ目は、PoC 期間中に一度も利用しなかった社員へのフォローです。 使い方やインストール方法が分からないことが原因と推測されるため、ハンズオン形式で操作を体験し、実際の業務での使い方をイメージできる機会を設ける予定です。

長期的には、この環境を基盤に AI を組み込んだ業務設計を進め、顧客向けのサービス展開を広げていく方針です。

まとめ

本記事では、アテナ様が Amazon Bedrock と Microsoft Entra ID を組み合わせ、非エンジニアの社員を中心とした生成 AI の全社利用基盤を構築した事例を紹介しました。

ポイントは 3 つです。

  1. OIDC ID プロバイダーと AWS STS を使えば、端末に静的な API キーを置かないフェデレーション構成を組めます。
  2. 統制できる場所は ID 基盤、AWS、端末のレジストリ、アプリケーションの設定に分かれるため、「何をどこで統制するか」を先に整理することが設計の鍵になります。AWS 側をどれだけ堅牢に作っても、端末が統制されていなければリスクは残ります。
  3. 従量課金の価値は総額の削減だけではありません。利用者別・モデル別の費用が見えることで、使う人に正しく投資する判断ができるようになります。

河野様は、この構成は多くの企業にとって参考になると考えており、その条件として 3 点を挙げています。ID 基盤をすでに使っていること、MDM で端末を一括管理していること、そして生成 AI を使う人に正しく投資する方針を持つことです。また、機密情報を扱う企業にとっては、この水準の構成でなければ全社展開そのものが難しいとも指摘しています。

生成 AI の全社展開というと、「どのサービスを使うか」から検討を始めがちです。しかし河野様は、本当に問われるのは「既存の ID 運用と端末管理にどう載せ、どう統制していくか」だと話します。同じ課題を抱える企業にとって、本記事がその検討の一助となれば幸いです。

より詳しく知りたい方は、以下のリンクもご参照ください。

著者

大松 宏之
テクニカルソリューションアーキテクトとして、業種業態を問わず様々なお客様を支援させて頂いています。好きなサービスは、AWS Direct Connect と AWS Client VPN です。
倪 木強 (ニオ　ミッチェル)
アカウントマネージャーとして、日本の中堅企業のお客様の IT 活用をビジネスの成果につなげるご支援をしています。好きなサービスは Amazon Simple Storage Service (Amazon S3) で、データをどこに置くかを決めることがそのまま活用の設計になる点に惹かれています。
アテナ デジタル戦略部 河野拓矢
社内外のシステムについて提案、開発から保守まで担当させて頂いております。 好きな動物はあざらしです。 好きなサービスはAWS CloudFormationです。