プロンプトエンジニアリング例：Least-to-Most

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

入力プロンプト

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

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

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

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

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

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

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

【指示】
この要件を満たすシステム構成を、Least-to-Mostの考え方を用いて段階的に検討してください。

1. システム構成を検討するために必要な課題を、小さな問題に分解してください。
2. 分解した問題を、依存関係を考慮して簡単なものから順番に並べてください。
3. 業務要件、機能要件、非機能要件を整理し、確定している事項と不足している事項を明確にしてください。
4. 前の段階で得られた結果を利用しながら、各課題を順番に解決してください。
5. 最後に、各段階の検討結果を統合し、システム構成案を提示してください。

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

AIの回答全文

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

1. 概要

1.1 背景・目的

社内問い合わせへの対応工数を削減するため、社内マニュアルやFAQを参照して回答するAIチャットシステムを新規構築する。

社内従業員約500名が利用することを想定し、AWS環境での実現方法を検討する。

1.2 検討方法

本検討では、Least-to-Mostの考え方を採用する。

Least-to-Mostとは、複雑な問題を小さな課題に分解し、比較的簡単な課題から順番に解決することで、最終的な問題の解決につなげる手法である。

以下の順番で検討する。

1. 課題の分解と依存関係の整理
2. 要件の整理
3. 回答方式の検討
4. 文書の保存・検索方式の検討
5. システム構成とAWSサービスの検討
6. セキュリティ方式の検討
7. 性能・可用性・運用方式の検討
8. コストと構築方式の比較
9. 検討結果の統合

各段階では、以下を明確にする。

• 入力：前段階で確定した情報
• 検討内容：解決すべき課題
• 結論：現時点で導ける判断
• 未決定事項：追加確認が必要な情報

なお、確定していない情報については、事実と仮定を区別し、根拠のない数値を確定要件として扱わない。

2. 第1段階：課題の分解と依存関係の整理

2.1 検討内容

「AWS上に社内向けAIチャットシステムを構築する」という問題を、小さな課題に分解する。

2.2 課題の分解

※この順序は検討を進めるための基本順序であり、セキュリティや予算などの重要な制約は初期段階から並行して確認する。

2.3 結論

最初からAWSサービスを決定するのではなく、要件、回答方式、データ管理方式を整理した後にサービスを選定する。

特に、以下の項目が構成に大きく影響する。

• 文書量と文書形式
• 文書ごとの閲覧権限
• 社外アクセス禁止の具体的な定義
• 利用者の認証方式
• 同時利用者数
• 予算

3. 第2段階：要件の整理

3.1 入力

ユーザーから提示された業務要件、機能要件、非機能要件、制約条件。

3.2 確定している要件

3.3 不足している要件

3.4 仮定

構成検討を進めるため、以下を暫定的に仮定する。

これらは設計を進めるための仮定であり、確定要件ではない。

3.5 結論

現時点で機能面の方向性は明確であるが、性能、セキュリティ、費用に関する詳細は不足している。

そのため、以降は暫定構成を検討し、最終的なサービス選定は追加確認とPoCの結果を踏まえて行う。

4. 第3段階：回答方式の検討

4.1 入力

第2段階で整理した機能要件。

• 社内マニュアルやFAQを参照する
• 自然言語で回答する
• 根拠となった文書を表示する

4.2 検討内容

社内文書を参照して回答するための方式を比較する。

4.3 方式の比較

4.4 評価

今回の要件では、回答の根拠となる文書を表示する必要がある。

LLM単体では、最新の社内文書に基づく回答や、正確な出典表示を保証できない。

ファインチューニングも、文書検索や根拠表示を直接実現する方式ではない。

一方、RAGは質問に関連する文書を検索し、その検索結果をAIモデルに渡して回答を生成する。

ただし、RAGでも誤回答や不適切な引用は発生し得るため、回答品質の評価が必要となる。

4.5 結論

RAG（Retrieval-Augmented Generation：検索拡張生成）を第一候補とする。

基本処理は以下のとおり。

ユーザーが質問
    ↓
質問に関連する文書を検索
    ↓
検索結果をAIモデルへ渡す
    ↓
AIモデルが回答を生成
    ↓
回答と参照文書を表示

次の段階では、このRAGを実現するための文書管理方式を検討する。

5. 第4段階：文書保存・検索方式の検討

5.1 入力

第3段階でRAGを第一候補とした。

5.2 検討内容

RAGで利用する社内文書について、以下を検討する。

1. 元文書の保存方法
2. 文書の取り込み方法
3. 検索方式
4. 文書更新時の反映方法
5. 根拠文書の表示方法

5.3 元文書の保存

候補：Amazon S3

S3はAWSのオブジェクトストレージであり、PDF、Word、テキストなどのファイルを保存できる。

今回のような文書管理用途では、元文書の保存先として利用しやすい。

ただし、既存の社内文書管理システムがある場合は、そこから直接連携する方式も比較する。

5.4 文書の検索方式

ベクトル検索では、文書を分割し、Embeddingモデルによって数値ベクトルへ変換する。

質問も同様にベクトル化し、意味的に近い文書を検索する。

一方、製品名、エラーコード、社内固有の略語などはキーワード検索が有効な場合もある。

5.5 文書取り込みの流れ

社内マニュアル・FAQ
    ↓
文書保存
    ↓
テキスト抽出
    ↓
文書分割（チャンク化）
    ↓
Embedding処理
    ↓
検索用データとして登録

検索用データには、少なくとも以下の情報を保持する。

• 文書ID
• 文書名
• 文書の保存先
• 文書のバージョン
• ページ番号や該当箇所
• アクセス権限情報
• 更新日時

これにより、回答の根拠となる文書を特定できる。

5.6 AWSサービス候補

S3 Vectors、OpenSearch Serverless、Aurora PostgreSQLにはそれぞれ特徴がある。

• S3 Vectors：ベクトル検索を中心とした構成で候補となる
• OpenSearch Serverless：高度な検索機能やハイブリッド検索が必要な場合に候補となる
• Aurora PostgreSQL：既存のリレーショナルデータやSQLによる管理との統合が必要な場合に候補となる

実際の対応機能、リージョン、料金、Knowledge Basesとの連携条件を確認する必要がある。

5.7 結論

元文書の保存先はS3を第一候補とする。

検索方式はベクトル検索を基本候補とし、キーワード検索との比較をPoCで行う。

検索基盤については、S3 Vectors、OpenSearch Serverless、Aurora PostgreSQLを比較対象として残す。

現段階では特定の検索基盤に確定しない。

6. 第5段階：システム構成とAWSサービスの検討

6.1 入力

これまでの検討結果は以下のとおり。

• 回答方式：RAGを第一候補
• 元文書：S3を第一候補
• 文書検索：ベクトル検索を基本候補
• 検索基盤：複数候補を比較
• 利用者：約500名
• 社外アクセス禁止が必須

6.2 必要なシステム機能

システム全体を以下の機能に分解する。

6.3 AWSサービス候補

6.4 構築方式の比較

案A：マネージドサービス中心

Amazon Bedrock Knowledge Basesを利用し、文書取り込み・検索・回答生成をAWSのマネージドサービス中心に構成する。

メリット：

• 検索基盤の独自実装を減らせる可能性がある
• インフラ管理の負担を軽減しやすい
• 初期検証を進めやすい

デメリット：

• サービスの仕様や制約に依存する
• 高度な検索制御や権限制御に追加実装が必要となる場合がある

案B：RAG処理を独自実装

LambdaまたはECS上にRAG処理を実装し、検索基盤とBedrockを個別に呼び出す。

メリット：

• 検索ロジックを細かく制御できる
• 独自の文書権限や業務ロジックを組み込みやすい
• 検索結果の加工や再ランキングを調整しやすい

デメリット：

• 開発・保守対象が増える
• 検索品質や障害対応を自社で管理する範囲が広い

6.5 結論

初期検証では、案Aのマネージドサービス中心構成を優先候補とする。

理由は、現時点では高度な独自検索機能が必須とされておらず、まず文書検索と回答生成の品質を検証することが重要だからである。

ただし、文書ごとの権限制御や複雑な検索条件が必要な場合は、案Bへの変更を検討する。

7. 第6段階：セキュリティ方式の検討

7.1 入力

確定要件：

• 社外からアクセスできない
• AWSを利用する
• 社内マニュアルやFAQを扱う

7.2 検討内容

「社外からアクセスできない」という要件を技術的な制御へ分解する。

7.3 社外アクセス禁止の定義

以下の方式が考えられる。

今回の要件を厳密に満たすためには、認証に加えてネットワークレベルのアクセス制限が必要となる。

7.4 暫定的なセキュリティ方針

社内ネットワークからAWS VPCへVPNまたはDirect Connectなどで接続する構成を候補とする。

アプリケーションの入口には内部向けALB等を配置し、社内からのプライベートなアクセス経路を設ける。

社内端末
   ↓
社内ネットワーク
   ↓
VPN / Direct Connect等
   ↓
AWS VPC
   ↓
内部向けALB
   ↓
アプリケーション

※この構成は、社内ネットワークとAWS間の接続経路が確保できることを前提とする。

7.5 その他のセキュリティ対策

特に重要なのは、検索段階で利用者に閲覧権限のない文書を除外することである。

回答生成後に表示内容だけを隠す方式では、情報漏えいを防止できない。

また、BedrockなどのAWSサービスへの通信についても、必要に応じてVPCエンドポイントを使用する。

利用する各サービスについて、プライベート接続の対応状況を確認する。

7.6 結論

社内ネットワークからの限定アクセスと、利用者認証を組み合わせる方式を第一候補とする。

ただし、VPN利用の可否、既存IdP、文書単位の権限管理については確認が必要である。

8. 第7段階：性能・可用性・運用方式の検討

8.1 入力

• 利用対象は約500名
• 利用時間は平日日中
• RAG方式を第一候補とする
• AWSのマネージドサービスを優先する

8.2 性能要件

利用者数500名という情報だけでは、必要な処理能力を決定できない。

以下の情報が必要となる。

例えば、リクエスト数は以下の式で概算できる。

1日の質問数
  = 日次利用者数 × 1人あたりの質問数

ただし、平均質問数だけではピーク時の同時実行数を推定できない。

同時実行数については、利用が集中する時間帯や回答生成時間も考慮する。

8.3 性能評価

PoCでは以下を計測する。

• 平均応答時間
• P95応答時間
• 同時実行時の応答時間
• エラー率
• 検索の適合率
• 回答の正確性
• 根拠文書の妥当性
• モデルのトークン消費量

具体的な合格基準は、業務担当者との確認後に設定する。

8.4 可用性

平日日中の利用を想定しているが、停止可能な時間帯や復旧目標は未定である。

以下を確認する。

• 許容停止時間
• 障害時の復旧目標時間（RTO）
• 許容データ損失時間（RPO）
• バックアップの必要性
• 文書検索が失敗した場合の動作
• AIモデルが利用できない場合の動作

8.5 運用方式

8.6 結論

現時点では、具体的な性能値や可用性目標を確定できない。

そのため、PoCで処理時間、検索品質、トークン消費量などを計測し、実測結果に基づいて要件を確定する。

9. 第8段階：コストと構築方式の比較

9.1 入力

• RAG方式を第一候補
• マネージドサービスを優先
• 検索基盤は未確定
• 利用者は約500名
• 同時実行数と文書量は未確定

9.2 主なコスト要素

9.3 コストの考え方

月額費用は、概念的には以下のように整理できる。

月額費用
 = AIモデル利用料
 + Embedding利用料
 + 検索基盤利用料
 + 文書保存費用
 + アプリ実行費用
 + ネットワーク費用
 + 監視・ログ費用
 + その他関連費用

AIモデルの費用は、質問数だけでなく、入力文書量、回答長、モデルの料金体系に依存する。

検索基盤の費用も、サービスによってストレージ容量、検索回数、稼働リソースなどの課金方式が異なる。

9.4 構築方式の比較

9.5 評価基準

最終的な方式選定では、以下の評価基準を使用する。

1. 必須機能を実現できるか
2. セキュリティ要件を満たせるか
3. 検索・回答品質が業務上十分か
4. 性能要件を満たせるか
5. 予算内に収まるか
6. 社内で継続運用できるか

まず必須要件を満たさない構成を除外し、その後、コストや運用負荷を比較する。

各評価項目の重み付けは、業務担当者と合意して決定する。

9.6 結論

現時点では、必要な利用量や予算が不明であるため、定量的な費用比較はできない。

ただし、初期検証の実装量を抑える観点から、マネージドサービス中心の案Aを優先してPoCを実施することが妥当と考える。

10. 第9段階：検討結果の統合

10.1 各段階の結論

10.2 暫定推奨システム構成

以下は、社内ネットワークとAWS VPC間にプライベート接続を用意できることを仮定した構成案である。

【社内ネットワーク】

  社内従業員（約500名）
           |
           v
      社内ネットワーク
           |
           v
   VPN / Direct Connect等
           |
           v
==================================
             AWS
==================================

【VPC内】

      内部向けALB
           |
           v
    Webアプリケーション
       (ECS等)
           |
           +----> 社内認証基盤と連携
           |
           v
       RAG処理
           |
           +---------------------+
           |                     |
           v                     v
   文書検索処理              回答生成処理
           |                     |
           v                     v
   Bedrock Knowledge Bases   Amazon Bedrock
           |                  (生成AIモデル)
           v                     ^
     ベクトル検索基盤             |
           |                     |
           +---- 検索結果 --------+
                                 |
                                 v
                         回答＋根拠文書
                                 |
                                 v
                         Webアプリケーション
                                 |
                                 v
                             社内従業員


【文書取り込み系】

    社内マニュアル・FAQ
             |
             v
         Amazon S3
             |
             v
    Bedrock Knowledge Bases
             |
             v
       Embeddingモデル
             |
             v
        ベクトル検索基盤


【運用・監視系】

    Amazon CloudWatch
    AWS IAM
    AWS KMS
    AWS Budgets

※上記は論理構成であり、ネットワーク構成を完全に表したものではない。

※Bedrock Knowledge Bases、モデル、検索基盤などへの接続には、サービスごとのネットワーク要件を満たす必要がある。

※検索基盤は未確定であり、S3 Vectors、OpenSearch Serverless、Aurora PostgreSQL等から選定する。

※WebアプリケーションとRAG処理は、初期段階では同一アプリケーションとして実装することも可能である。

10.3 想定処理フロー

質問・回答

1. 従業員が社内ネットワークからチャット画面へアクセスする
2. 認証済みの利用者であることを確認する
3. ユーザーが質問を入力する
4. アプリケーションが質問を受け付ける
5. 利用者の閲覧権限を考慮して関連文書を検索する
6. 検索結果をAIモデルへ渡す
7. AIモデルが回答を生成する
8. 回答と根拠文書を画面に表示する
9. 必要な利用状況やエラー情報を記録する

文書更新

1. 管理者がマニュアルやFAQを追加・更新する
2. 文書をS3に保存する
3. 文書取り込み処理を実行する
4. テキスト抽出とEmbedding処理を行う
5. 検索用データを更新する
6. 更新した文書が検索対象となることを確認する

削除済み文書や旧バージョンが検索対象に残らないようにする必要がある。

10.4 現時点の推奨サービス

この構成は現時点の要件から導いた暫定案であり、正式な設計確定を意味するものではない。

11. PoCの進め方

11.1 PoCの目的

本番構成を確定する前に、技術的な実現性と回答品質を検証する。

11.2 検証ステップ

11.3 品質評価

回答品質は、実際の社内問い合わせを参考にした評価用質問セットを作成して検証する。

評価項目：

• 正しい回答が得られるか
• 適切な文書を検索できるか
• 根拠文書が回答内容を支持しているか
• 文書にない内容を事実として回答しないか
• 回答不能な質問を適切に扱えるか
• 権限のない文書を参照しないか

合格基準は、業務担当者と合意して決定する。

12. 最終的に確認が必要な事項

優先順位を付けて確認する。

13. 最終結論

今回の要件に対しては、Amazon Bedrockを利用したRAG構成が有力な候補である。

特に、Amazon Bedrock Knowledge Basesを活用したマネージドサービス中心の構成は、初期検証の実装負担を抑える観点から優先して検討する価値がある。

ただし、現時点では文書量、認証方式、アクセス制限、性能、予算などの重要事項が未確定である。

そのため、最終的な判断は以下とする。

現段階の結論

• RAGを回答方式の第一候補とする
• Amazon BedrockをAI基盤の第一候補とする
• Amazon S3を文書保存先の第一候補とする
• 検索基盤は複数候補をPoCで比較する
• 社内ネットワーク限定アクセスと利用者認証を組み合わせる
• 性能・コストは実測値を基に確定する

次のアクション

1. 不足している要件を業務担当者へ確認する
2. サンプル文書と評価用質問を準備する
3. Bedrock Knowledge Basesを用いた小規模PoCを実施する
4. 回答品質、権限制御、性能、費用を検証する
5. 検証結果に基づいて本番構成を決定する

Least-to-Mostによる段階的な検討の結果、現時点で必要なのは特定のAWSサービスを確定することではなく、RAG方式の実現性を確認し、未決定要件を明確にすることである。