Amazon Web Services ブログ

AWS AppSync と GraphQL で Amazon Bedrock をデータに接続する

本記事では、AWS AppSync と GraphQL API を活用して、Amazon Bedrock の基盤モデル (FM) とエージェントをパブリック API とプライベート API およびデータベースの両方にシームレスに接続する方法について説明します。Amazon Bedrock は生成系 AI サービスであり、基盤モデル (FM) で生成系 AI アプリケーションを構築し拡張する最も簡単な方法です。Amazon Bedrock の包括的な機能により、様々なトップクラスの FM を簡単に試すことができ、ファインチューニングや検索拡張生成 (RAG) などのテクニックを使用して、お客様のデータで FM を個別にカスタマイズし、コードを書くことなく複雑なビジネスタスクを実行するマネージドエージェントを作成することができます。AWS AppSync は、複数のマイクロサービス API とデータベースを単一の、自己文書化され、イントロスペクション可能な API エンドポイントに統合する API を構築する最も簡単な方法です。

データを生成系 AI に公開することが新たな課題をもたらす

FM に自身のプライベートデータへの管理されたアクセスを提供することで生成系 AI と FM の能力を活用して構築できる新しいアプリケーションの種類は、広がります。しかし、FM にプライベートデータへのアクセスを許可することで、以下のような新たな課題が生じます。

  • FM に提供される API は自然言語で記述される必要があり、FM は実行可能なアクション、呼び出し方法、返すデータを理解しなければならない。
  • FM がプライベート API にアクセスする際には、API が詳細なエラーメッセージと、有効な入力の定義を提供する必要がある。
  • プライベート API への FM のアクセスは、FM が意図しない、破壊的な、または悪意のある行動をとらないように、厳密に制御されるべきである。
  • FM とそのエージェントによって行われるアクションは、多様なシステムとデータストアに渡って監視され、ログに記録される必要がある。

FM を企業データに接続する方法は様々あります。例えば、Amazon Bedrock エージェント は、FM を文書化された REST API に接続する簡単な方法を提供します。しかし本記事では、カスタム FM エージェントと GraphQL API を使用して FM をプライベートデータに接続するメリットを探ります。AWS AppSync と GraphQL を使用することで、単一の、自己文書化された、そして機械が挿入可能な API を介して、すべてのプライベートデータへのアクセスを FM に提供することができます。これにより、FM は利用可能な企業データに簡単にアクセスし、理解し、対話することができます。また、単一の GraphQL API エンドポイントを通じてプライベートデータへの FM アクセスをルーティングすることで、FM のアクションを保護、管理、観察するシンプルな方法を提供します。本記事では、GraphQL と AWS AppSync に支えられた、FM とデータ間の接続レイヤーとして機能するアーキテクチャについて説明します。しかしその前に、FM が外部データとどのように連携するかを見てみます。

FM が外部データを利用する方法

ここ数ヶ月、そしてここ数年の人工知能の進歩の速さには目を見張るものがあります。モデルはより強力になり続け、できることを新たな高みへと押し上げています。モデルにどのように質問するか (プロンプトエンジニアリング ) を探求した結果、reAct の論文にあるような斬新なテクニックが生まれました。このプロンプトアプローチでは、FM は現在の会話とどのような行動をとることができるかについてのデータを提供され、その後、FM は理由 (Reason)、行動 (Action)、観察 (Observation) のステップのプロセスを通じて、抽象的な問題を解決するためのステップを踏むよう求められます。

このプロンプトを視覚化した例を見てみます。下の図では、オレンジ色のハイライトが FM によって生成されます。

  1. まず、すべてのプロンプトアプローチの鍵となるのは、FM が何をするよう求められているのか、どのように行動すべきなのかを説明することです。また、FM はどのような行動をとることができるかも説明されます。簡潔にするために、問題のアクションの完全な説明は含まれていませんが、FM はどのような操作にアクセスでき、それぞれをどのように呼び出すことができるのかについての詳細な説明が必要です。後述する作業例では、queryDatastore オペレーションが何をするのか、どのような形式でデータが欲しいのか、どのようなタイプが利用可能なのかについてより詳細に説明します。
  2. FM は現在の状態についてどう考え、次のステップとして何を考慮すべきかを自然言語で記述したものである Reason (理由) を提供するように要求されます。
  3. 次に FM は取りたい具体的な行動 (Action) を求められます。
  4. FM 生成はこのステップで一時停止し、FM が要求した所定のアクションを呼び出します。このアクションは、データベースクエリであったり、ワークフローの実行であったり、ベクターストアとのインターフェイスであったり、FM が必要とするものであれば何でもかまいません。その出力は、アクションの観察 (Observation) として会話履歴に返されます。
  5. その後、FM は再び応答することができます。上の例では、FM は答えを知っていることを示しますが、もし観察の結果が予期せぬものであったり、全体像が摑めなかった場合は、他にどのようなデータが必要なのかを推論する機会となります。
  6. 答えにたどり着いた FM は、”submit answer” ツールの起動を要求するため、プロセスを停止し、これを答えとして記録します。

GraphQL と AWS AppSync で FM をプライベートデータに接続する方法

AWS AppSync は、開発者が安全でタイプセーフかつ柔軟な GraphQL API を作成することを可能にし、構築されたデータグラフに対してデータを読み取り、操作するために入力されるリクエストを解析、型チェック、認証、解決するスキーマを提供します。このように、AWS AppSync はデータの上にセキュアでタイプセーフなレイヤーとして配置されます。認可は、どのデータストアにデータが保存されているかに関わらず、定義したデータタイプの各フィールドに対して設定することができる。型はオプションとしてマークすることができ、サブ型や再帰参照を含むことができます。このような構成により、使いやすく説明的なクエリ言語を備えた柔軟性の高いデータグラフを作成することができます。

アクション定義としてのスキーマ定義

AWS AppSync は、明確に定義された構造で API が何を行うかを定義する GraphQL Schema 上でネイティブに動作します。説明のために、この例では自動車ディーラーの API について説明します。AWS AppSync におけるそのような API の部分的なスキーマは次のようになります。

type Car {
  id: ID!
  model: String!
  make: String!
  year: Int!
  color: String!
  price: Int!
}

type Query {
  # Gets all the cars for sale in your dealership
  listCars: [Car!]!
}

プロダクションスキーマはより多くの型を提供し、mutation 操作を含み、フィールド呼び出しに期待されるパラメータを持つことができる。上記のGraphQLスキーマでは、定義によって、車の色、年式、価格をすべて取得するクエリーリクエストは次のように記述できることが明確になっています。

query {
    listCars {
        color
        year
        price
    }
}

コメントはスキーマ定義自体の一部でさえあり、各フィールドの存在理由や各フィールドの用途について FM にガイダンスを提供することができます。最も優れている点は、GraphQL には特別なイントロスペクション操作があり、FM が必要に応じてスキーマ定義を問い合わせることができることです。

簡単に言うと、GraphQL API は人間が読めるように設計されているため、FM も読むことができます。FMがプライベート API を理解し、それらに対して query や mutation を構築するには、単純なイントロスペクションクエリーで十分です。

組み込みタイプセーフと自然言語エラー

AWS AppSync は、リクエスト受信時にスキーマに対して query を安全に解析します。フィールドを整数として定義した場合、AWS AppSync はそれが他のものであれば呼び出すことを許可せず、FM のクエリを特別に解析する必要性を取り除きます。

これはまた、不正なフォームや不正な型付けのリクエストは、何が間違っていたのかを説明する明確なエラーメッセージを返すことを意味します。存在しない値を要求した場合、AWS AppSync は FM が読めるエラーメッセージを返します。

query {
  listCars {
    colors
    id
  }
}

Validation error of type FieldUndefined: 
Field 'colors' in type 'Car' is undefined

このような自然言語によるエラーメッセージは、FM を正しい query に導き、ミスを犯したときに FM が自ら誤りを取り消すことを可能にします。

デフォルトで認証

AWS AppSync はフィールド単位で認証を提供し、AWS Identity and Access Management (IAM), Amazon Cognito, OIDC, API Keys, そして AWS Lambda によるカスタム認証ロジックもサポートしています。FM がフィールドを呼び出したり、特定のデータを閲覧したりすることを防止または制限したい場合、他のユーザーが通常通り API を使用できるようにしながら、それを暗黙的に実現するために必要なすべてのオプションが用意されています。

特定の操作が呼び出されないようにしたい場合は、AWS AppSync が提供する認証モードのいずれかを使って権限を拒否できます。これは、バックエンドのデータグラフ全体に公開することなく、どのようなアクションが実行されるかを FM に洞察させることができます。

mutation {
  sendEmail(
    title: "Sample Email", 
    to: "joe.schmo@amazon.com"
    body: "Hey this is a test of an AppSync send-email resolver!"
  )
}

Not Authorized to access sendEmail on type Mutation

AWS AppSync GraphQL API は 1 つまたは複数のデータストアを組み合わせることができるため、FM がプライベートデータに対してどのような操作を行うことができ、どのような操作を行うことができないかを 1 か所で設定し、制御することができます。FM は、このようなエラーメッセージをアプリケーションユーザーに伝えたり、エラーの原因にならない別のアプローチを試したりすることができます。また、FM が実行できるアクションを定義、制限するために、呼び出すユーザーの権限を使用することもできます。このようにすることで、FM は起動ユーザーの権限以上の昇格権限を持たないので、混乱した代理攻撃への露出を制限することができる。

設定可能なログソリューション

AWS AppSync には、メトリクス、API からのログストリーム、リゾルバロジックに書き込まれたカスタムロギングオプションを含む、カスタマイズ可能な詳細なロギングレベルも付属しています。これにより、FM がどのクエリ、フィールド、リゾルバ、データにアクセスできたか、またはアクセスを拒否されたかを明確に可視化できます。これにより、開発者は FM のアクションを完全に可視化し、監査することができます。

AWS AppSync と GraphQL によるデータフローの例

以下の図は、FM がバックエンド API に対して抽象的な問題を解決するように要求されたときに、サンプルリクエストが取る経路です。

順を追って説明すると、以下のようになります。

  1. 上の例では、Lambda 関数の LangChain を使って reAct ソルバーを実装していますが、このアーキテクチャはどんなコンピューティングサービスにも使えます。今回はシンプルにするために Lambda を選択しました。
  2. AWS AppSync はイントロスペクションクエリを通してユーザにスキーマをネイティブに公開しているので、このスキーマを FM プロンプトのアクションスペース定義として使うことができます。プロンプトのエンジニアリングは必要ありませんが、スキーマの GraphQL フィールドに説明を追加することで、API の直感的でないルートをスムーズに処理することができます。
  3. FM モデルの最初の呼び出しです。FM は理由 (Reason) とアクション (Action) 出力ステップの両方を提供するよう促されます。ストップワードを使用することで、この結果以外で応答しないようにすることができます。
  4. AWS AppSync リアルタイム subcription を使用すると、呼び出しの理由とアクションがエンドユーザーアプリケーションですぐに利用できるようになり、FM エージェントの中間アクションを実行しながらリアルタイムでユーザーが対話できるようになります。この機能がなければ、ユーザはフィードバックもなく、何分も結果を待つことになるかもしれません。
  5. 生成されたアクションで、AWS AppSync API が呼び出され、FM によって要求された結果を取得します。これはタイプセーフで、IAM セキュリティによってバックアップされ、可観測性のために Amazon CloudWatch ロギングを含みます。
  6. データは最終的に接続された AWS AppSync データソースから引き出されます。AWS AppSync は、Amazon DynamoDB、Amazon Relational Database Service (Amazon RDS)、AWS Lambda、その他多くの AWS サービスとの接続をネイティブにサポートしてます。これらのデータ接続は JavaScript リゾルバを通して行われ、追加の認証やデータ変換のニーズに対して追加のロジックを提供することができます。
  7. FM モデルは query の結果を持っており、2 回目のプロンプトが表示されます。FM は “最終的な答え” を出力することができ、その結果はユーザーに公開されるか、”理由＋アクション” の結果を出力することができます。

まとめ

本記事では、AWS AppSync とGraphQLが、FM とプライベートデータ間の接続レイヤーとしてどのように自然にフィットするかを説明しました。このように、AppSync を活用することで、FM に必要なデータを提供し、ネイティブの機能を超えて拡張することができます。

本記事は、「Connect Amazon Bedrock to your data with AWS AppSync and GraphQL」を翻訳したものです。

翻訳者について

稲田 大陸

AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログなどを執筆しています。