社内AIをクラウドに置くときの構成と費用 — AWSで作る場合の考え方

「社内の文書をAIに検索させたい」「問い合わせ対応をAIに任せたい」という相談は増えていますが、構成の話になった途端に難しく見えるのがこの領域です。

実際には、決めるべきことはそれほど多くありません。この記事では、AWSを例に小さく始めて必要になったら増やす現実的な進め方を整理します。

AIそのものの仕組みについてはRAG（社内文書検索AI）とは、既存システムへの組み込みは既存システムにAIを追加するをご覧ください。

なお「AWSの構築・運用そのものをAIに任せる」話は、AWSの構築・運用にAIを使うで別途まとめています。

決めることは3つだけ

このうち③のアクセス権限が最も見落とされます。 「人事部しか見られない文書」をAIに読ませたのに、AIには全社員が質問できる——という状態になると、権限設定を迂回して情報が漏れることになります。設計の最初に決めてください。

最小構成の考え方

いきなり本格的な基盤を作る必要はありません。多くの場合、次の4つの部品で足ります。

1. 入口（画面） — 社員が質問を入力する画面。既存の社内ポータルやチャットツールに組み込む形でも構いません
2. 処理する場所 — 質問を受け取り、必要な文書を探して、AIに渡す部分。常時起動のサーバーでも、リクエストが来たときだけ動く仕組み（サーバーレス）でも実現できます
3. 文書の保管場所 — 元の文書を置くストレージと、検索用に加工したデータを入れるデータベース
4. AIの呼び出し口 — AI提供会社のAPI、またはクラウド事業者経由の窓口

ポイント: 利用者が社内の数十人で、24時間フル稼働でもないなら、常時起動のサーバーを立てる必要はないことが多いです。使ったぶんだけ課金される構成にすると、待機時間のコストがかかりません。

「まずは1部署・1用途」で始める

全社導入を前提に設計すると、権限設計もデータ整備も一気に重くなります。特定の1部署・特定の1種類の文書に絞って始めると、次のことが早く分かります。

• そもそも社員が使うのか
• 回答の精度が実用に足りるのか
• 元の文書がAIに読める状態か（ここでつまずくケースが非常に多い）

3つ目は軽視されがちです。紙をスキャンしただけのPDF、罫線だらけのExcel、画像として貼られた表などは、そのままではAIが正しく読めません。AIの性能ではなく、元データの整備が課題だったというのはよくある結末です。

社内AIをAWSで動かす費用の内訳

費用は「AIの利用料」と「クラウドの利用料」に分かれます。金額はサービスや構成で大きく変わるため、ここではどこにお金がかかるかの内訳として整理します。

費目	課金のされ方	コストを左右する要素
AIの利用料	送受信した文章量に応じた従量課金	質問数、渡す文書の量、使うモデルの種類
処理する場所	実行時間・回数、または稼働時間	常時起動か、都度起動か
ストレージ	保存容量	文書の総量。通常はごく小さい
検索用データベース	容量、または稼働時間	文書数。専用サービスを使うと高くなりやすい
通信・その他	転送量など	通常は小さい
監視・ログ	ログ量	保存期間の設定次第

具体的な料金は変動します。 AI各社もクラウド各社も料金体系を随時見直しているため、金額を判断材料にする場合は導入検討の時点で必ず各社の公式ページで最新の料金を確認してください。

費用で一番効くのは「毎回どれだけ文章を渡すか」

AIの利用料は、やり取りする文章の量に応じて課金されるのが一般的です。つまり、質問のたびに社内文書を大量に渡す作りにすると、そのぶん料金が伸びます。

コストを抑える定番の手は次のとおりです。

• 関連する部分だけ渡す — 文書全体ではなく、質問に関係する箇所だけを検索して渡す（これがRAGの基本的な考え方です）
• 用途に見合うモデルを選ぶ — 定型的な問い合わせ対応に、最も高価なモデルを使う必要はありません
• 同じ質問の結果を再利用する — よくある質問は結果を保存しておけば、毎回AIを呼ばずに済みます

コストが暴走しないための上限設定

従量課金のサービスで最も怖いのは、想定外の使われ方で請求が跳ねることです。設計段階で次を必ず入れてください。

1. 1回あたりの上限 — 1回の応答で生成する文章量に上限を設ける。無制限にしない
2. 利用者ごとの回数制限 — 1人あたり1日◯回まで、といった制限をかける。誤操作や自動化ツールによる連打を防げます
3. 処理の繰り返し回数の上限 — AIが自動で手順を繰り返す仕組み（エージェント）を使う場合、繰り返し回数に必ず上限を設ける。条件次第で永久に呼び続ける作りにしない
4. 請求アラート — 予算のしきい値を設定し、超えたら通知が飛ぶようにする。クラウド各社に標準機能があります
5. 利用ログを残す — 誰がいつ何回使ったかを記録する。異常な使われ方に気づけます

これは机上の話ではありません。 上限のない作りは、バグ1つ・設定ミス1つで請求が跳ねます。「動くこと」より先に「暴走しないこと」を設計に入れてください。

データはどこまで外に出るのか

最も多い懸念がこれです。正確に整理します。

論点	実際のところ
送ったデータの保管場所	クラウド事業者経由で呼ぶ場合、リージョン（データセンターの所在地）を指定できるサービスがあります。国内で完結させたい場合の選択肢になります
送ったデータがAIの学習に使われるか	法人向けのAPIサービスでは、既定では学習に使わないと明示しているものが一般的です。ただし規約は変わりうるため、導入時点で各社の最新の規約を確認してください
社外に一切出したくない場合	自社環境内でモデルを動かす選択肢もありますが、機材と運用の負担が大きく、中小規模では現実的でないことが多いです
社内の閲覧権限との関係	ここは自分たちで設計する範囲です。クラウドやAIの機能では守られません

判断のしかた: 「AIだから危ない」ではなく、「その文書を、契約したクラウド事業者のサーバーに置いてよいか」という、従来のクラウド利用と同じ基準で判断するのが実務的です。すでに業務でクラウドのメールやストレージを使っているなら、判断の基準はそれと揃えられます。

よくある失敗

進める順番

1. 用途を1つに絞る — 「社内規程の問い合わせ対応」など、対象文書と質問者を限定します
2. 元データを確認する — その文書がAIに読める形式かを先に見ます。ここで課題が見つかることが多いです
3. 小さく作って触ってもらう — 数十人規模なら、簡素な構成で十分に評価できます
4. 精度と使われ方を見る — 回答の質と、実際の利用回数を記録します
5. 必要なぶんだけ広げる — 対象文書を増やす、部署を広げる、構成を強化する。必要になってから増やします

まとめ

• 決めることは「データの置き場所」「AIの呼び方」「アクセス権限」の3つ
• 権限設計はクラウドやAIが守ってくれない。自分たちで設計する範囲
• 費用は「毎回どれだけ文章を渡すか」で大きく変わる。関連部分だけ渡す作りにする
• 上限設定と請求アラートは、動かす前に入れる。従量課金は設定ミス1つで請求が跳ねる
• データが学習に使われるかは、法人向けAPI（外部サービスと自動でデータをやり取りするための接続口）では既定で使わないと明示しているものが一般的。ただし導入時点で最新の規約を必ず確認する
• 最初から作り込まず、1部署・1用途で試してから広げる
• つまずくのはAIの性能ではなく、元データの整備であることが多い