社内で生成AIを使おうとしたとき、話が止まるのはたいてい機能の議論ではありません。「入れた情報はどこを通るのか」と「作ったあと、誰が面倒を見るのか」。この2つです。人や組織に関わる情報を扱うなら、なおさら先に決めておきたいところでしょう。
ディーネットでは、組織づくりの判断を支える社内向けAI環境を、お客様ごとの専用環境としてAWS上に構築しています。本記事で紹介するのは、専任のインフラ担当を置かない体制のお客様に向けて実際に構築した構成です。構成図とあわせて、なぜその形にしたのかを1つずつ説明します。
相談の前提：専任のインフラ担当を置かない体制で、社内AIをどう持つか
まず、どういう体制のお客様に向けた構成なのかを共有します。ここを飛ばすと、あとの説明が「一般的にはこうする」という話になってしまうためです。環境の前提、抱えていた課題、SaaSをそのまま使う選択を採らなかった理由の順に並べます。
お客様の環境
- 日本国内で事業を展開する従業員約40名規模のIT企業
- 受託開発とシステム運用が主体で、自社プロダクトは持たない
- 専任のインフラ担当を置かない体制（開発担当が社内システムを兼務）
お客様が抱えていた課題
相談の時点で、お客様が課題として挙げていたのは次の4点です。以降で説明する構成は、この4点にそれぞれ対応する形で決めました。
- 社外に出せない情報を扱う — 1on1の記録、配置や育成の検討材料など、社外に出したくない情報が入力の中心になる。どこを通り、どこに保管されるのかを把握できないまま使い始めることはできない
- 組織の課題を相談する相手がいない — 経営層が一人で抱えており、判断材料を整理する相手がいない
- 運用を担う人がいない — 専用環境は持ちたいが、その運用が兼務担当者に丸ごと乗ると続かない
- 社内に説明できる根拠がない — 「何をどこで守っているか」を社内に示せる状態になっていない
SaaSをそのまま使う選択を採らなかった理由
市販のAIチャットサービスを契約するほうが、着手は早くなります。それでも専用環境を選んだのは、扱う情報が人や組織に関わるもので、入力した内容の経路と保管場所を自社の管理下に置きたい、という前提が先にあったためです。
一方で「専用環境を作る」ことは「インフラの運用を新しく抱える」ことと同義になりがちです。そこで構成の検討では、機能をどう作るかより先に、次の3つの前提を置きました。
構成を決めるときに置いた3つの前提——経路・運用範囲・作り直せること
ここからは、サービスを選ぶ前に置いた判断の軸です。情報の経路、自分たちで手を入れる範囲、環境を作り直せるかどうかの3つを先に決めました。以降で出てくるサービスの選び方は、いずれもこの3つから導いています。
入れた情報がどこを通るかを先に決める
画面の配信、利用者の認証、データの保管、生成AIの実行の4つについて、それぞれ通信がどこへ向かうのかを先に決めました。「安全な構成にする」という抽象的な目標ではなく、経路の一覧を作ってから各要素を当てはめる順序にしています。
手を入れなくていい範囲をできるだけ広げる
専任のインフラ担当がいない体制では、日常的に手を入れる箇所が増えるほど環境が使われなくなります。そのため、AWSのマネージドサービスで置き換えられる部分はできるだけ置き換え、自分たちで面倒を見る対象を意図的に絞りました。
環境をコードで作り直せる状態にしておく
設定を手作業で積み上げた環境は、変更が怖くなって誰も触らなくなります。構成をコードとして持ち、同じ環境を作り直せる状態を最初から前提にしました。
全体構成：マネージドサービスと、VPC内で動かす部分の組み合わせ
構成図は次のとおりです。
図に置いた各サービスを、何のために置いたかとあわせて整理します。
| 役割 | サービス | 何のために置いたか |
|---|---|---|
| 画面の配信 | Amazon CloudFront ／ Amazon S3 | HTML・JS・CSSを配信し、利用者に配信元（S3）を直接見せない |
| 認証 | Amazon Cognito（ユーザープール） | 利用者ごとのログインを管理し、APIの手前で本人確認を済ませる |
| APIの入口 | Amazon API Gateway | 認証済みのリクエストだけをバックエンドへ通す |
| 処理 | AWS Lambda | サーバーを持たずにバックエンド処理を実行する |
| データ | Amazon DynamoDB | 利用者ごとのデータを保持する |
| 生成AIの実行 | VPC内のプライベートサブネットに置いたDify | 生成AIの処理を、外部から直接到達できない場所で動かす |
| 外部への出口 | NAT Gateway（パブリックサブネット） | 外部の生成AI APIへの通信をこの経路に集約する |
| 管理用の入口 | Application Load Balancer（パブリックサブネット） | 管理者のアクセス先を1か所に限定する |
静的ファイルの配信をS3とCloudFrontに寄せる考え方そのものは、WordPress静的化とS3＋CloudFront構成でも扱っています。
画面の配信と認証：Webサーバーを1台も立てない
まずは利用者から見える部分、画面の配信と認証です。この2つはどちらもAWSのマネージドサービスに寄せ、Webサーバーを立てずに成り立たせています。配信がどの経路を通るのか、認証がどこで完結するのかを順に見ていきます。
CloudFront ＋ S3 で画面を配信する
画面を構成する静的ファイル（HTML・JavaScript・CSS）はAmazon S3に置き、Amazon CloudFrontから配信しています。利用者がアクセスする先はCloudFrontだけで、S3に直接触れることはありません。
ここでWebサーバーを1台も立てていないのがポイントです。OSやミドルウェアの更新作業が、構成の段階でまるごと消えます。
Cognito で利用者を認証し、API Gateway へ渡す
利用者の認証はAmazon Cognitoのユーザープールが担当します。ログインしていない利用者は、そもそもアプリケーションのAPIに到達しません。認証はAmazon API Gatewayの手前で完結する形です。
パスワードの保管やトークンの発行は、間違えたときの影響がとくに大きい部分でしょう。そこを自前で実装せず、マネージドサービスに寄せています。
処理とデータ：常時起動するサーバーを持たない
続いてバックエンド側、処理とデータの持ち方です。ここもサーバーを用意せず、マネージドサービスの組み合わせで構成しました。常時起動するサーバーがないと日常の作業から何が外れるのか、という観点であわせて整理します。
Lambda で処理する
バックエンドの処理はAWS Lambdaで実行しています。常時起動するサーバーがないので、「利用のない時間帯もサーバーは動いている」という前提の運用——OS更新、プロセス監視、ディスク使用量の確認——が構成から外れました。
DynamoDB にデータを持つ
データはAmazon DynamoDBに保持しています。マネージドのデータベースなので、バックアップの取得やバージョン管理にかかる手間は、サーバー上でデータベースを自前運用する場合よりも小さくなります。
生成AIの実行はVPCの中に閉じる
ここまでの部分と違い、生成AIを動かすところは自分たちで見る範囲として残ります。だからこそ、置き場所と通信の経路を先にはっきり決めておきたいところでした。VPCの分け方、生成AI基盤の配置、外部の生成AI APIへの出口、管理用の入口の4つに分けて説明します。
2つのアベイラビリティゾーンにまたがるVPC
生成AIの処理を動かす部分は、Amazon VPCの中に置いています。VPCは2つのアベイラビリティゾーンにまたがる構成で、パブリックサブネットとプライベートサブネットに分けています。
プライベートサブネットに生成AI基盤を置く
生成AIの処理をまとめるDifyは、プライベートサブネットに配置しました。プライベートサブネットにはインターネットから直接到達できません。つまり、生成AIを動かしている箇所そのものが外部に露出しない形です。アプリケーション側からの呼び出しは、VPC内の通信として行われます。
外部の生成AI APIへは NAT Gateway 経由で出る
生成AIの応答生成では、外部のOpenAI APIを使います。この通信が通るのは、パブリックサブネットに置いたNAT Gatewayです。外へ出る経路を1か所に集約しておくと、「この情報は外に出るのか」という質問に、構成図の線を指して答えられます。
管理用のアクセスは ALB に限定する
Difyの管理画面へ入る経路は、Internet Gateway経由でApplication Load Balancerを通る1本だけに絞りました。管理者の入口が1か所であれば、アクセス元の制御もそこで完結します。なお、利用者向けの通信はこの経路を通りません。
稼働したあとに残る仕事から、先に決めた
構成の相談は、どうしても「作るところ」に時間が偏ります。権限やログの話が最後の1行で終わってしまう、という経験をされた方もいるでしょう。この環境では順番を逆にして、稼働後に残る作業のほうから決めました。
権限（IAM）
AWSの操作権限はAWS IAMで管理します。誰が何を操作できるかを、人の記憶ではなく権限の定義として持っておく、という考え方です。
記録（CloudTrail・Config・S3）
AWSに対するAPI操作の記録はAWS CloudTrailで取得し、リソースの設定変更の履歴はAWS Configで追跡します。各種ログはAmazon S3に集約しています。「いつ、何が変わったか」を後から追える状態を、稼働の前提にしています。
検知と復旧（GuardDuty・AWS Backup）
脅威の検知はAmazon GuardDutyで行い、バックアップはAWS Backupで管理しています。どちらもAWSのマネージドサービスなので、検知の仕組みやバックアップの取得処理を自分たちで作り込む必要がありません。
サーバーへの入り方（Systems Manager）
サーバーへの接続には、SSHではなくAWS Systems Managerを使う運用を前提にしました。SSH用のポートを開けたままにする必要がなく、鍵の配布と管理も構成から外れます。
環境そのものをコードで持つ（CloudFormation）
環境の構成はAWS CloudFormationで定義しています。同じ構成を作り直せるため、設定変更の検証を本番と別の環境で行えます。手作業で積み上げた環境で起きがちな「変更が怖くて誰も触らない」状態を避けるための選択です。
どこがマネージドで、どこに手が要るか
| 領域 | AWSのマネージドサービスに寄せた部分 | 引き続き人が判断する部分 |
|---|---|---|
| 配信 | CloudFront・S3（Webサーバーなし） | キャッシュの扱いを決める |
| 認証 | Cognito（認証処理の実装なし） | 誰にアカウントを配るかを決める |
| 処理・データ | Lambda・DynamoDB（サーバー運用なし） | データの持ち方の設計 |
| 生成AIの実行 | ― （VPC内で稼働。ここは自分たちで見る範囲） | バージョン更新の判断とその影響確認 |
| 記録・検知 | CloudTrail・Config・GuardDuty・AWS Backup | 通知を誰が見るかを決める |
| 環境の再現 | CloudFormation | 変更をコードに反映する運用 |
この表のとおり、マネージドサービスに寄せても「人が判断する部分」は残ります。専任のインフラ担当を置かない体制では、この残る範囲がどこまでかを構築前に確認しておくことが実際の運用のしやすさにつながります。構成の検討や構築後の運用については、AI環境の構築・運用支援でもご相談いただけます。
お客様にとっての成果
冒頭で挙げた4つの課題が、この構成で稼働したあとにどうなったかを、同じ順番で並べます。いずれも、ここまで説明してきた構成から導ける範囲にとどめています。
入力した情報の通り道を、図で説明できる
社外に出せない情報を扱うという前提に対して、通信がどこへ向かうかは構成として決まっています。画面の配信、利用者の認証、処理、データ、生成AIの実行のすべてが対象です。外部の生成AI APIへ出る経路はNAT Gateway1か所に集約しており、外に出る箇所を構成上で特定できます。
組織の判断材料を整理する場を、社内の環境として持てた
経営層が一人で抱えていた組織の課題について、社外に出したくない内容も含めて入力し、整理に使える場が社内にできました。利用できるのはCognitoで認証された利用者に限られ、環境そのものはお客様専用です。
運用の担い手を、新しく置かずに済んだ
Webサーバーを立てず、常時起動するサーバーも持ちません。そのため、サーバー起因の日常作業が構成の段階で外れています。残る作業がどこまでかは、前の章の表のとおりで、構築前に共有しています。専用環境を持ちながら、そのためのインフラ担当を新たに置く形にはなっていません。
「何をどこで守っているか」を社内に示せる
操作の権限はIAMの定義として、API操作と設定変更の履歴はCloudTrailとAWS Configの記録として残ります。脅威の検知とバックアップもマネージドサービスが受け持ちます。「誰が何を操作できるのか」「いつ何が変わったか」を、人の記憶ではなく仕組みの説明として社内に示せる形です。環境の構成はCloudFormationで定義しているため、変更を別環境で試してから本番に反映する進め方も選べます。
この構成を組んでみて、分かったこと
- 経路を先に決めると、あとの議論が短くなる。 「この情報は外に出るのか」に対して、構成図の線を指して答えられる状態になるためです
- 手を入れる範囲を絞る判断は、構築時ではなく運用時に効いてくる。 サーバーを持たない部分が増えるほど、日常的に発生する作業は減っていきます
- 生成AIを動かす部分だけは、マネージドサービスに寄せきれない。 バージョン更新の判断と、その影響確認が残ります。ここを「残る仕事」として構築前に共有できているかどうかで、稼働後の印象は変わるでしょう
- コードで環境を持っておくと、変更の相談ができる。 別環境で試してから本番に入れる、という進め方を選べるからです
社内向けAIをどこから始めるか、どの構成が自社に合うかの整理は、AI導入の進め方の相談でも承っています。
関連するFAQ
Q. 専任のインフラ担当がいなくても、この構成を運用できますか。
A. 日常的に手を入れる箇所は、マネージドサービスに寄せた分だけ少なくなります。ただし記事内の表のとおり、アカウントの配布や通知の確認、生成AI部分のバージョン更新の判断は残ります。運用の一部または全部をお引き受けする形での構築も可能です。
Q. 入力した情報が外部に送信されることはありますか。
A. 生成AIの応答生成では外部のAPIを利用するため、その処理に必要な内容は外部へ送信されます。本構成では、その通信をVPC内のプライベートサブネットからNAT Gateway経由の1経路に集約し、どこから外部へ出るかを構成上で特定できるようにしています。
Q. なぜ生成AIの処理をVPCの中に置いているのですか。
A. 生成AIの処理をまとめる基盤をインターネットから直接到達できない場所に置くためです。あわせて、管理画面へのアクセス経路をロードバランサー1か所に限定しています。
Q. サーバーレス構成にすると運用は完全になくなりますか。
A. なくなりません。OSやミドルウェアの更新のようなサーバー起因の作業は構成から外れますが、権限の棚卸し、ログの確認、データ設計の見直しといった判断は残ります。
Q. 検証用の環境を別に作れますか。
A. 作れます。環境の構成をAWS CloudFormationで定義しているため、同じ構成を別に用意して設定変更の検証を行えます。
Q. すでにAWSアカウントを持っている場合はどうなりますか。
A. 既存アカウント上に構築する形と、新規に用意する形のどちらも可能です。権限とログの分離をどう設計するかは、既存の運用体制を確認したうえで決めています。
Q. 同じ構成を他の用途にも使えますか。
A. 画面の配信・認証・処理・データ・外部APIの呼び出しという組み合わせは、社内向けの業務アプリケーション全般で使える形です。生成AIを使わない場合は、VPC内で動かす部分がそのまま不要になります。
まとめ
専任のインフラ担当を置かない体制で社内向けAI環境を持つ場合、決め手になるのは機能の多さではなく、情報が通る経路と稼働後に残る作業の範囲です。
今回の構成では、画面の配信・認証・処理・データをAWSのマネージドサービスに寄せ、生成AIの実行だけをVPC内のプライベートサブネットに閉じました。運用とセキュリティの土台はIAM・CloudTrail・Config・GuardDuty・AWS Backup・Systems Managerで組み、環境全体をCloudFormationで再現できる状態にしています。
社内でAIを使う環境をどう持つか検討されている場合は、扱う情報の性質と、運用を誰が見るかの2点から整理を始めると、構成の判断がしやすくなります。
構成の一部だけ、運用の一部だけ、というご相談も承っています。