源内PoCの始め方——最小構成で2週間・月$10から試す方法

「商用利用できるのは分かった。コスト感も掴めた。でも、結局何から始めればいいの？」

源内（GENAI）についての情報収集はひと通り終えたのに、実際に手を動かす最初の一歩で止まってしまう。そういう声をよく聞きます。「いきなり本番導入」はハードルが高く、かといって何を確認すればPoC（概念実証）として十分なのかも分かりにくいからです。

この記事では、実際にAWS上で源内相当の構成を触っている立場から、最小構成・2週間・月$10〜40で回せるPoCの具体的な進め方を整理します。

この記事でわかること

• なぜ「最小構成・2週間」が現実的なPoCの単位なのか
• 2週間のPoCスケジュール（事前準備・デプロイ・社内試用の3段階）
• PoCの段階であえてやらないこと（スコープを絞る理由）
• PoC終了後に何を基準に次のステップを判断すべきか

前提知識

• 源内AIとは何か で源内の概要・ライセンス・技術構成を先に押さえておくと理解しやすくなります
• 源内をAWSで動かすといくらかかるか のコスト試算を前提にしています

なぜ「最小構成・2週間」なのか

源内のPoCというと、RAG（社内文書検索）やSAML認証まで含めたフル構成をイメージしがちですが、それは最初の一歩としては重すぎます。まず確認すべきは「genai-webのポータルとしての基本機能が、自社の用途に耐えるかどうか」であり、RAGや認証のカスタマイズはその後の話だからです。

最小構成（RAGなし）であれば、cdk deploy の実行自体は20分程度で完了します。月額コストも$10〜40程度に収まります（詳しくはコスト試算記事を参照してください）。この軽さを活かして、2週間という短いサイクルで「使えるかどうか」を判断するのが現実的です。

組織タイプによる違い

ここまでの2週間スケジュールは、AWSアカウントの用意も含めて技術チームがすぐに着手できる組織を想定した、技術検証だけの所要期間です。実際には組織のタイプによって、①着手までの期間と②必要なセキュリティ要件の2つが変わってきます。

①着手までの期間は組織によって大きく異なります。数人規模のスタートアップや中小企業であれば、技術チームの判断だけで着手できることが多く、この2週間はほぼそのまま当てはまります。一方、自治体や大企業では「PoCを始める許可を得る」こと自体が最初のハードルになりがちです。情報システム部門による新規クラウド利用の審査、調達手続き、セキュリティ委員会の承認などが必要になるケースが多く、この承認プロセスは数週間〜数ヶ月と組織によって幅があるため、技術検証の2週間とは別枠で見込んでおく必要があります。

②セキュリティ要件も組織によって異なります。後述する「PoCでやらないこと」は、あくまで一般的な民間企業を想定した優先順位です。個人情報や機密情報を扱う組織、自治体のように調達段階からアクセス制限が求められる組織では、PoCの段階からWAF（IPアドレス制限）を組み込む必要が出てきます。自社の要件に照らして、省略してよい項目かどうかを判断してください。

規模感が見えたところで、2週間のスケジュールを順番に見ていきます。

PoCの全体スケジュール

2週間を「事前準備」「デプロイ・動作確認」「社内試用・評価」の3段階に分けて進めます。

【Day 1-2】事前準備（AWSアカウント・Bedrockモデルアクセス・CDK bootstrap）

最初の2日は、デプロイ前の準備に充てます。

1. AWSアカウントの用意として、本番環境と分離した検証用アカウントを用意します。既存の組織のAWS Organizationsにメンバーアカウントとして追加する形で問題ありません
2. Bedrockのモデルアクセスは、初めて呼び出す前にリクエスト・有効化しておく必要があります。特にAnthropicのモデルは初回利用時に利用目的の入力（First Time Use フォーム）が必要なため、Bedrockのコンソールから先に済ませておきます（ここを忘れて2日目に慌てるパターンをよく見ます）
3. CDK bootstrapは、genai-webのCDKスタックをデプロイする前に実行しておく必要があります。WAF（IP制限・地理的制限）を使う予定がある場合、CloudFront用WAFはus-east-1固定のため、東京リージョン（ap-northeast-1）とus-east-1の両方で実行しておきます
4. 予算アラートは、AWS Budgetsで月$50程度のしきい値を設定しておくと、想定外の課金を早期に検知できます。PoC規模なら発動することはまずありませんが、保険として設定しておくと安心です

# 東京リージョン
cdk bootstrap aws://<AWSアカウントID>/ap-northeast-1

# us-east-1（WAFを使う予定がある場合のみ）
cdk bootstrap aws://<AWSアカウントID>/us-east-1

準備が整ったら、実際にデプロイして動作確認に進みます。

【Day 3-5】デプロイと動作確認

genai-webリポジトリをクローンし、cdk deploy を実行します。デプロイ自体はコマンド一発ですが、実際に確認すべきことがいくつかあります。

• CloudFront経由でポータルにアクセスできるか
• Cognitoでのユーザー作成・ログインができるか
• チャット機能でBedrockのモデルに実際に応答が返ってくるか
• チーム管理機能で、想定する部署・グループの単位が作れるか

この3日間で確認するのはあくまで「動くかどうか」です。UIの細かい調整やカスタマイズはこの段階では後回しにして構いません。

関連記事 源内AIのコードをGitHubから読む——genai-webとgenai-ai-apiのAWS構成 デプロイで何が立ち上がるかの全体像はこちらで解説しています。

動作確認が済んだら、実際に社内のユーザーに触ってもらう段階に入ります。

【Week 2】社内試用と評価

2週目は、実際に数人〜十数人規模で使ってもらい、評価を行います。評価メンバーはIT部門だけでなく、実際に想定業務を担う実務部門を含めて選ぶことが重要です。IT部門だけで試用すると技術的な動作確認に偏り、業務適合性を判断する材料が集まりません。

• 想定する業務（社内問い合わせ・文書要約・議事録整理など）で実用に足る回答品質か
• チーム管理機能による権限分離が、実際の組織構造に合っているか
• 応答速度・UIの使い勝手に致命的な問題がないか

この段階でBedrockの利用量に応じたコストが発生し始めます。PoC規模（数人・月間数千リクエスト程度）であれば、前述の通り月$10〜40程度に収まるケースが多いです。

評価の視点が見えたところで、PoCの段階でやらなくてよいことも明確にしておきます。

PoCでやらないこと（スコープを絞る）

PoCの目的は「使えるかどうかの判断」であり、本番向けの作り込みではありません。次の3つは、PoCの段階では意図的に後回しでよいでしょう。

1. RAG（社内文書検索）の実装は、Bedrock Knowledge Baseの構築にそれ自体別の検証項目があり、PoCの期間を圧迫するため後回しにします。まずはRAGなしでポータルとしての基本価値を確認します
2. SAML認証への対応は不要です。genai-webはデフォルトで政府向けのSAML複数IdP認証を想定した作りになっていますが、民間企業のPoCではCognito標準の認証で十分です
3. WAFによるアクセス制限は、検証用アカウント・限定ユーザーでの試用であれば、この段階で作り込む必要はありません（ただし自治体など、セキュリティ要件でPoC段階からアクセス制限が求められる組織は例外です。前述の「組織タイプによる違い」を参照してください）

これらは「PoCで不要」というだけで「将来不要」という意味ではありません。本番導入が決まった段階で、必要な範囲だけ追加を検討します。

スコープを絞ったPoCが終わったら、次に進むかどうかの判断基準を整理します。

PoC終了後の判断基準

2週間の試用が終わったら、次の3つの観点で判断します。

• 回答品質: 業務で使える水準の回答が返ってきたか。不足していれば、RAGでの社内文書連携が必要という判断材料になります
• コスト感: 実際にかかった月額コストが、想定していた予算感と合っているか
• 組織への適合性: チーム管理機能による権限分離が、実際の部署・プロジェクト構成と噛み合っているか

いずれも問題なければ、次は本番構築に向けたAWS環境の構築に進みます。CDKデプロイで実際に詰まりやすいポイントについては、別記事でまとめる予定です。

なお、これらの基準に照らして「今は導入を見送る」という判断も、PoCとして十分に意味のある結果です。無理に本番展開に進めるより、時期尚早と判断して仕切り直す方が、結果的にコストを抑えられるケースは少なくありません。

まとめ

源内のPoCは、RAGやSAML認証まで含めたフル構成である必要はありません。最小構成であればcdk deployは20分程度、月額コストも$10〜40程度に収まるため、2週間という短いサイクルで「業務に使えるかどうか」を判断できます。

事前準備でBedrockのモデルアクセスとCDK bootstrapを済ませ、デプロイ後の3日間で基本機能を確認し、2週目に実際のユーザーで試用する。この流れであれば、大きな投資をせずに導入判断ができます。まずはAWSコンソールからBedrockのモデルアクセスをリクエストするところから始めてみてください。実際のデプロイ記録・コスト実測・構成カスタマイズの知見は源内AIシリーズで随時公開しています。

参考文献

• Request access to models - Amazon Bedrock — Bedrockのモデルアクセスリクエストの手順
• GitHub: digital-go-jp/genai-web — 源内Web公式リポジトリ
• 源内AIとは何か——インフラエンジニアがデジタル庁OSSでサービスを作ることにした理由 — 源内の概要・技術構成
• 源内AIのコードをGitHubから読む——genai-webとgenai-ai-apiのAWS構成 — デプロイで立ち上がるAWSリソースの詳細
• 源内をAWSで動かすといくらかかるか——構成別コスト試算 — 構成別の月額コスト試算