源内 vs GenU vs 自前RAG vs 汎用LLM——民間企業はどれを選ぶべきか

「源内が話題になってるけど、結局ウチはGenUを使えばいいの？ それとも普通にChatGPTやClaudeを契約すればいいの？」

社内向けの生成AI活用環境を検討していると、こういう疑問にぶつかります。源内・GenU・自前RAG・汎用LLMサービス、選択肢が並んでいるのに、そもそも源内とGenUが何の関係にあるのかすら分かりにくい。「源内はGenUベース」と聞いても、じゃあ源内を選ぶ理由がどこにあるのか判断がつかない、という状態です。

この記事では、実際にAWS上でGenUベースの構成を触っている立場から、4つの選択肢を整理します。「源内かGenUか」という二択ではなく、「GenUをどこまで自社拡張するか」が本当の判断軸であることを説明します。

この記事でわかること

• 源内とGenUの関係（「源内 vs GenU」という比較がそもそも成立しない理由）
• 汎用LLM・GenUそのまま・源内相当の自社拡張・自前RAGフルスクラッチ、4つの選択肢の実態
• GenUに何を足すと源内相当になるのか（具体的な3つの拡張ポイント）
• 自社がどれを選ぶべきか判断するためのフローチャート

前提知識

• 源内（GENAI）がAWSのOSS「GenU」をベースにしていることをご存知の方向けです。前提を先に押さえたい場合は 源内AIとは何か を先にどうぞ

「源内 vs GenU」で比較している時点で、実は問いが間違っている

まず整理しておきたい前提があります。源内（genai-web）は、AWSが公開しているOSS「Generative AI Use Cases（GenU）」をベースに開発されています。つまり源内はGenUの派生であり、両者は競合する別製品ではありません。

GenU自体はAWSのサンプル実装で、React + CloudFront + S3のフロントエンド、API Gateway + Lambdaのバックエンド、Cognito認証、Bedrock連携という標準構成を持つオープンソースです（MIT-0ライセンス）。さらに「Use Case Builder」というノーコード機能があり、プロンプトテンプレートを書くだけでGenU本体のコード変更なしにユースケースを追加できます。

デジタル庁はこのGenUをベースに、政府向けの要件を満たすための拡張を加えました。それが源内です。つまり「源内かGenUか」という二択で悩むのは、実は「素材のままのGenUを使うか、素材に手を加えるか」という話に置き換わります。前回の記事では源内・自前RAG・汎用LLMの3択で比較しました（源内AIとは何か 参照）。今回はその間に本来あるべき「GenUそのまま」という選択肢を挟み、4択で整理し直します。

GenUに何を足すと「源内相当」になるのか

源内がGenUに追加した機能は、実装を読むと大きく3つに整理できます（詳細は 源内AIのコードをGitHubから読む で解説済みです）。

1. チーム管理機能は、組織単位でアクセス制御し、チームごとに利用できるAIアプリや会話履歴を分離する仕組みです
2. ExApp（外部AIアプリ連携）は、inputs/outputs 形式のJSON APIを定義するだけで、外部の生成AIアプリをポータルから呼び出せる仕組みです
3. SAML複数IdP認証は、組織・グループごとに異なるIdPを、アクセスするURLパスで切り替えてログインさせる政府向けの認証フローです

つまり「源内を使う」の実態は、「GenUに、この3種類の拡張のうちどれが自社に必要かを判断して足す」ということです。政府はこの3つ全部が必要だったから足しましたが、民間企業が同じ3つ全部を必要とするとは限りません。

たとえば数人規模のチームで使うだけなら、チーム管理機能もSAML複数IdP認証も過剰です。逆に複数部門・複数子会社で使い分けたい場合や、既存の社内システムと連携させたい場合は、この拡張がそのまま効いてきます。

必要な拡張が見えてきたところで、4つの選択肢を並べて比較します。

4つの選択肢を並べて比較する

汎用LLM・GenUそのまま・源内相当の自社拡張・自前RAGフルスクラッチを、構築コストとカスタマイズ性の軸で比較します。

	汎用LLM	GenUそのまま	源内相当（自社拡張）	自前RAGフルスクラッチ
初期構築	契約のみ	デプロイのみ	拡張実装が必要	設計から実装
カスタマイズ性	低（設定のみ）	中（Use Case Builderで拡張可）	高（チーム管理・ExApp・認証を自社仕様に）	最大
運用負荷	ほぼ無し	自社でAWS運用が必要	同左＋拡張部分の保守	全て自社責任
データの置き場所	ベンダー次第	自社AWSアカウント内	自社AWSアカウント内	自社AWSアカウント内
向いている組織	まず試したい・少人数	内製エンジニアがいる中小企業	部門管理・監査・既存システム連携が必要な組織	生成AIが事業のコアな企業

表からも分かる通り、GenUそのままと自前RAGフルスクラッチの間には大きな距離があります。源内相当（自社拡張）は、この距離を「必要な機能だけ足す」形で埋める選択肢です。

自前RAGフルスクラッチが正当化されるのはどんな場合か

Bedrock Knowledge BaseやOpenSearch Serverlessを直接組んでRAGをフルスクラッチで作る場合、自由度は最大になります。UIも認証もデータ連携も、全て要件通りに作れます。

ただし、その分すべてが自社の設計・実装・保守の責任になります。マルチユーザー管理やアクセス制御を含め、GenUや源内がすでに解決している問題を一から解き直すことになるからです。生成AIそのものが自社プロダクトの差別化要因であり、既存OSSの構造に縛られたくない場合を除いて、フルスクラッチを選ぶ理由は薄いと考えています。

汎用LLMだけで十分なケース

社内データとの連携が不要で、少人数での利用にとどまるなら、ChatGPT EnterpriseやClaude EnterpriseのようなSaaSをそのまま契約するのが現実的です。この場合はGenUも源内も過剰投資になります。

判断が変わるのは「社内文書を参照させたい」「部門ごとに利用状況を分けたい」という要件が出てきた時点です。ここから先が、GenUベースの構成を検討する領域に入ります。

もう一つ、ネットワーク分離が契約・規制で必須の組織（金融・医療・行政系など）では、通信をVPC内に閉じられるかどうかも判断材料になります。汎用LLMのSaaSは外部ベンダーのインフラを経由しますが、GenUベースであれば自社AWSアカウント内でVPCエンドポイント経由のプライベート通信が組めます。この設計の具体的な組み方は、源内AIシリーズの別記事で扱う予定です。

判断軸が見えてきたところで、実際の判断フローを整理します。

結論（どれを選ぶかのフローチャート）

社内データ連携が不要なら汎用LLM、必要でも内製エンジニアがいなければ汎用LLMが現実的です。内製エンジニアがいて社内データ連携が必要なら、まずGenUそのままのデプロイを検討してください。そこに部門管理・監査・既存システム連携といった要件が加わったときに初めて、源内相当の自社拡張を検討する段階に入ります。フルスクラッチは、生成AIそのものが事業の核になる場合の選択肢です。

まとめ

源内とGenUは競合する別製品ではなく、源内はGenUに政府向け拡張を加えたものです。民間企業が本当に比較すべきは「源内かGenUか」ではなく、「GenUに、チーム管理・ExApp・SAML認証のうちどれを、どこまで自社拡張するか」です。

汎用LLMで足りるか、GenUそのままで十分か、それとも自社拡張が要るかは、社内データ連携の要否と組織の複雑さで決まります。判断に迷う場合は、まずGenUを自社のAWSアカウントにデプロイしてみて、実際に足りない機能から拡張範囲を見積もる進め方が現実的です。まずは GenUのGitHubリポジトリ を確認するところから始めてみてください。実際のデプロイ記録・コスト実測・構成カスタマイズの知見は源内AIシリーズで随時公開しています。

参考文献

• GitHub: aws-samples/generative-ai-use-cases — GenU公式リポジトリ（技術構成・ライセンスを確認）
• Generative AI Use Cases (GenU) 公式ドキュメント — GenUのQuick Start・機能一覧
• 生成AIアプリをノーコードで作成・社内配布できる GenU ユースケースビルダー（AWS公式ブログ） — Use Case Builder機能の詳細
• GitHub: digital-go-jp/genai-web — 源内Web公式リポジトリ（GenUからの拡張内容を確認）
• 源内AIとは何か——インフラエンジニアがデジタル庁OSSでサービスを作ることにした理由 — 源内・自前RAG・汎用LLMの3択比較（本記事の前提）
• 源内AIのコードをGitHubから読む——genai-webとgenai-ai-apiのAWS構成 — チーム管理・ExApp・SAML複数IdP認証の実装詳細