プロンプトエンジニアリング例：Tree-of-Thought（ToT）

本記事は、プロンプトエンジニアリングの記事で比較した「Tree-of-Thought（ToT）」による、説明用のサンプル記事です。
以下はAIの回答結果です。構成案の妥当性を保証するものではありません。

入力プロンプト

【作業依頼】
社内の問い合わせ対応を効率化するため、社内マニュアルやFAQを参照して回答するAIチャットシステムを新規構築したい。実現方法を検討してほしい。

【現時点で分かっている要件】
■ 業務目的
社内問い合わせへの対応工数を削減したい

■ 利用者
社内従業員約500名

■ 機能要件
・チャット形式で質問できる
・社内マニュアルやFAQを参照して回答する
・回答の根拠となった文書を表示する

■ 非機能要件
・社外からアクセスできないようにする
・平日日中の利用を想定する

■ 制約条件
・AWS環境を利用する

■ 未決定事項
・システム構成
・使用サービス
・データ保存方式
・性能要件
・詳細なセキュリティ方式
・予算など

【指示】
この要件を満たすシステム構成を、Tree-of-Thought（ToT）の考え方を用いて検討してください。

1. 異なる方針のシステム構成案を3つ作成してください。
2. 各構成案について、コスト・性能・セキュリティ・運用負荷の観点で評価してください。
3. 評価結果をもとに有望な構成案を2つ選択してください。
4. 選択した2つの構成案について、それぞれの弱点を改善する方法を検討してください。
5. 改善後の構成案を再評価し、最も適切な構成案とその理由を提示してください。

各段階の検討結果が分かるように整理してください。
未決定事項については、仮定と確認が必要な事項を区別してください。

AIの回答全文

社内問い合わせ対応AIチャットシステムの構成検討

1. 検討の概要

1.1 目的

社内従業員約500名を対象に、社内マニュアルやFAQを参照して問い合わせに回答するAIチャットシステムをAWS上に構築する。

本検討では、Tree-of-Thought（ToT）の考え方を用いて、異なる3つの構成案を比較し、有望な2案を改善したうえで、最終的な推奨構成を選定する。

なお、未確定の要件を勝手に数値化したり、特定のAWSサービスを最初から採用前提にしたりしない。

1.2 確定している要件

1.3 未決定事項と検討上の仮定

重要： 500名という従業員数だけでは、必要なサーバー性能や月額費用を算出できない。そのため、現段階では定性的な比較を行い、実測が必要な項目を明示する。

2. ToTによる検討方針

ToTは、最初に1つの答えを決めるのではなく、複数の候補を分岐させ、それぞれを評価し、有望な候補を改善しながら選択する考え方である。

今回の検討は次の5段階で進める。

1. Step 1： 異なる構成案を3つ作成
2. Step 2： コスト・性能・セキュリティ・運用負荷で評価
3. Step 3： 有望な構成案を2つ選択
4. Step 4： 選択した2案の弱点を改善
5. Step 5： 改善後の構成案を再評価し、最終推奨を決定

評価は次の4軸で行う。

なお、比較結果は現時点の要件に対する暫定評価であり、実測や見積もりによって変わる可能性がある。

3. Step 1：異なる方針の構成案を3つ作成

3つの構成案は、単にAWSサービスを入れ替えるのではなく、構築・運用の責任範囲が異なる方式として設定する。

案A：Amazon Q Business中心のマネージド構成

方式：既製サービス活用型

AWSが提供する企業向けAIアシスタントを活用する方式。

構成イメージ

社内従業員
    |
    v
社内ネットワーク
    |
    v
認証・アクセス制御
(IAM Identity Center / 既存IdP)
    |
    v
Amazon Q Business
    |
    +-- チャットUI
    +-- 文書検索
    +-- AI回答生成
    +-- 出典表示
    |
    v
社内マニュアル・FAQ
(S3 / 対応する文書管理システム)

評価

注意点：

Amazon Q Businessのデータソース接続をVPC内に配置できることと、従業員向けチャット画面を社内ネットワーク限定にできることは別の話である。

標準Web画面をそのまま採用できるかは未確定とする。

案B：EC2中心の独自RAG構成

方式：自由度重視型

EC2上にチャットアプリケーションと検索処理を構築する方式。生成AIはAmazon Bedrockを利用する。

構成イメージ

社内従業員
    |
    v
VPN / Direct Connect
    |
    v
内部ALB
    |
    v
EC2
    |
    +-- Webアプリ
    |     |
    |     +-- チャット画面
    |
    +-- RAG処理
          |
          +-- 文書検索
          +-- 回答制御
          +-- 出典情報の整形
    |
    +--------------------+
    |                    |
    v                    v
Amazon Bedrock       検索DB
(LLM / Embedding)    (OpenSearch等)
                         |
                         v
                      Amazon S3
                    (マニュアル・FAQ)

評価

EC2上でLLMそのものを稼働させるのではなく、Bedrockのマネージドモデルを呼び出す設計とする。

GPUサーバーの管理を避けるためである。

案C：AWSサーバーレス＋Bedrock Knowledge Bases構成

方式：AWSネイティブ型

チャット画面とAPIを独自に実装し、アプリケーション処理をLambda、文書検索をBedrock Knowledge Basesに委ねる方式。

構成イメージ

社内従業員
    |
    v
社内ネットワーク
    |
    v
認証・プライベートAPI
    |
    v
AWS Lambda
    |
    +-- 問い合わせ受付
    +-- 権限チェック
    +-- 回答整形
    |
    v
Amazon Bedrock Knowledge Bases
    |
    +-- 文書検索
    +-- 回答生成
    +-- 出典情報の取得
    |
    +-------------------+
    |                   |
    v                   v
Amazon S3          ベクトルストア
(文書原本)          (S3 Vectors等)

評価

Bedrock Knowledge Basesは、文書の取り込み、Embedding生成、ベクトル検索、出典付き回答を支援する。

S3 Vectorsは利用可能な保存先の一つだが、検索要件に応じた選定が必要である。

4. Step 2：3案を評価

4.1 評価基準

5段階評価を採用する。5が最も望ましい評価とする。

スコアは実測値ではなく、設計段階の暫定評価である。

特にコストは見積もりではない。

4.2 初回評価

4.3 評価理由

案A：Amazon Q Business

チャットUIやRAGの独自実装が少ないため、運用負荷は最も低い。

一方、ユーザー課金や検索基盤の費用があり、500名の利用条件では料金確認が必要。

特に社内ネットワーク限定という条件を標準Web画面で満たせるかが課題となる。

案B：EC2

ネットワークやアプリケーションを細かく制御できるため、社内限定アクセスの設計はしやすい。

ただし、EC2の稼働管理や障害対策が必要であり、500名規模で必要なインスタンス構成も未確定である。

案C：サーバーレス

サーバーの常時管理を避けながら、チャットUIや認証・認可を独自に設計できる。

Lambdaは利用量に応じた拡張が可能。

ただし、検索基盤の費用とLLMのスループットは別途評価する必要がある。

4.4 初回評価の限界

単純な合計点だけで採用を決めることは適切ではない。

今回の「社外からアクセスできない」という条件は、他の評価軸で補えるものではなく、必須の合格条件とする。

また、文書ごとの閲覧権限が必要な場合も、権限を持たない利用者に検索結果や引用が表示されないことを必須条件とする。

5. Step 3：有望な2案を選択

初回評価の結果、以下の2案を選択する。

選択1：案C（サーバーレス＋Bedrock Knowledge Bases）

選択理由：

• 社内限定の独自UI・APIを設計できる
• EC2方式より運用負荷を減らせる
• 利用量に応じた拡張が可能
• コストと拡張性の両面で有望

選択2：案B（EC2中心の独自RAG）

選択理由：

• 社内ネットワークへの閉域配置を設計しやすい
• 検索・権限制御の自由度が高い
• 複雑な業務要件に対応できる可能性がある

案Aを除外する理由

案Aは運用負荷の点では優秀だが、現時点では社内限定アクセスを標準UIで確実に実現できると判断できないため、今回は改善対象の2案から除外する。

ただし、後からAmazon Q Businessのアクセス方式が要件を満たすと確認できた場合は、再び比較対象に加える価値がある。

6. Step 4：選択した2案の弱点を改善

6.1 案Bの改善：EC2の運用負荷を削減

初回の案Bは、EC2単体にWebアプリとRAG処理を集約していた。

これを、障害対策と運用負荷の観点から改善する。

改善後の構成

社内ネットワーク
    |
    v
VPN / Direct Connect
    |
    v
内部ALB + 認証
    |
    v
EC2 Auto Scaling Group
    |
    +-- AZ-1
    |     +-- EC2
    |
    +-- AZ-2
          +-- EC2
    |
    +-------------------+
    |         |         |
    v         v         v
 Bedrock   検索DB      S3

改善によるトレードオフ：

運用負荷と単一障害点は軽減されるが、複数AZのEC2やALBなどにより固定費が増える可能性がある。

また、OSとアプリケーションの保守責任は残る。

6.2 案Cの改善：検索精度・セキュリティ・コストを最適化

初回の案Cでは、サーバーレス構成を採用したものの、具体的な検索方式と権限制御が未確定だった。

検索ストアの比較

S3 VectorsはBedrock Knowledge Basesと連携できるが、同連携ではハイブリッド検索に対応しないという制約がある。

マニュアルの製品名・エラーコード・設定値を正確に検索する必要がある場合は、特に比較が重要となる。

6.3 案Cの改善後構成

社内従業員（約500名）
    |
    v
社内ネットワーク
    |
    v
VPN / Direct Connect
    |
    v
プライベートWeb画面・認証
    |
    v
Private API Gateway
    |
    v
AWS Lambda
    |
    +-- 問い合わせ受付
    +-- 認可
    +-- 回答整形
    |
    v
Amazon Bedrock
    |
    +-- Knowledge Bases
    |     |
    |     +-- 権限フィルタ付き文書検索
    |     +-- 出典情報の取得
    |
    +-- LLM
          |
          +-- 検索結果を基に回答生成
    |
    +----------------------+
    |                      |
    v                      v
Amazon S3            ベクトルストア
(原本文書)           (方式は未決定)


横断的な管理
    |
    +-- CloudWatch：監視
    +-- IAM：権限制御
    +-- KMS：暗号化

※概念構成図。Web画面の配信方法、認証連携、VPCエンドポイントの対応範囲は詳細設計で確定する。

セキュリティ上の注意

VPC内に配置するだけで社外アクセス禁止が完成するわけではない。

以下を含めて確認する必要がある。

• Web画面の配信経路
• DNS設定
• 認証・認可
• APIの公開設定
• セキュリティグループ
• VPCエンドポイント
• IAMポリシー
• 文書ごとの閲覧権限

7. Step 5：改善後の構成案を再評価

7.1 再評価結果

初回と同じ基準で、改善後の案B・案Cを比較する。

改善前後の比較

案Cの点数が改善前後で変わらないのは、初回評価ですでに比較的高く、改善によって主に設計の具体性とリスク対応が向上したためである。

検証前に5点へ引き上げることはしない。

7.2 比較結果の解釈

改善後の案B

可用性と運用性が向上する。

ただし、複数EC2、ALB、検索DBの継続費用があり、運用者による保守も必要になる。

改善後の案C

サーバー運用を減らしながら、社内限定アクセスとRAGの構築を目指せる。

検索基盤やLLM利用量を調整する余地があり、利用量が未確定な段階で検証を進めやすい。

ただし、サーバーレスが必ず安価とは限らない。

常時稼働するネットワーク設備、検索基盤、PrivateLink、認証基盤などの費用を含めた見積もりが必要である。

8. 最終推奨構成

推奨：案C（AWSサーバーレス＋Amazon Bedrock Knowledge Bases）

最終的には、案Cを第一候補として推奨する。

8.1 推奨理由

1. 運用負荷を抑えられる

EC2のOS保守やサーバーの台数管理を減らし、問い合わせ機能の改善に注力できる。

2. AWS環境内でRAGを構築できる

Bedrock Knowledge Basesを利用することで、文書取り込み・検索・回答生成の一部をマネージド化できる。

3. 社内限定アクセスを設計できる

プライベートなWeb/API構成と閉域接続を組み合わせることで、要件への適合を目指せる。

4. 利用量が未確定でも検証しやすい

小規模なPoCで実際の利用量、回答速度、検索精度を測定してから本番構成を決定できる。

5. 機能拡張に対応しやすい

将来的な問い合わせ履歴、利用状況分析、部署別FAQなどを独自実装できる。

8.2 採用条件

案Cの採用は条件付きとする。

以下の要件をPoCで検証し、満たすことを採用条件とする。

• 社内限定アクセスを実現できること
• 文書単位の権限制御ができること
• 必要な検索精度を満たすこと
• 必要な応答性能を満たすこと
• 月額費用が予算内に収まること

9. データ保存方式の検討

データの種類ごとに保存方式を分けることを推奨する。

チャット履歴の永続保存は現時点の必須要件ではない。

保存する場合は、個人情報・機密情報の取り扱い、保存期間、削除方法を決めてから導入する。

また、引用元の文書については、単なるファイル名だけでなく、以下の情報を扱えるように設計する。

• 文書ID
• 文書のバージョン
• 参照箇所
• 閲覧権限
• 更新日時

10. 本番構築前に確認すべき事項

確認チェックリスト

• ピーク時の同時利用者数を確認
• 1日当たりの問い合わせ件数を確認
• 許容応答時間を確認
• マニュアル・FAQの文書数と容量を確認
• 文書形式と更新頻度を確認
• 部署別・ユーザー別の閲覧権限を確認
• VPN / Direct Connectの有無を確認
• 既存SSO・IdPの利用可否を確認
• 初期構築費の予算を確認
• 月額運用費の予算を確認
• 運用担当者と保守体制を確認

11. 推奨する次の進め方

本番構築に入る前に、次の3段階で検証する。

PoCの最初から500名分の本番構成を構築する必要はない。

まずRAG単体の動作と回答品質を確認し、その後にアクセス制御・性能を検証することで、構成選定の失敗リスクを抑えられる。

12. 結論

最終判断

Amazon Bedrock Knowledge Basesを利用したサーバーレスRAG構成を第一候補とする。

ただし、以下の項目は未確定のまま維持し、PoC結果に基づいて確定する。

• 検索ストア
• 認証方式
• ネットワーク構成
• 性能要件
• 予算

今回のToT検討で重要なのは、最初からBedrockやEC2を正解と決めるのではなく、複数の選択肢を比較し、弱点を改善したうえで、現時点の要件に最も適合する構成を選ぶことである。