実装と統合26% · 5項目

Q1. ReAct 型のエージェントの動き方の説明として、最も適切なものはどれか。

1. 質問に関係なく、すべてのツールを決まった順番で必ず 1 回ずつ呼び、結果をつなげて返す
2. 最初に 1 回だけ回答を生成し、ツールは使わずにそのまま利用者に返す
3. 利用者に毎回どのツールを使うかを選んでもらい、その指示どおりに動く
4. 考える→ツールを使う→結果を観察する、を繰り返し、目的を達したら回答する

Q2. エージェントのツールを定義している。モデルが正しくツールを選べるようにするために最も重要なことはどれか。

1. できるだけ多くの似た名前と機能のツールを用意し、モデルにその中から選ばせるようにする
2. ツールの入力の形式は決めずに、どんな文字列でも受け付けるようにしておく
3. ツールの名前と説明を明確にし、入力の JSON スキーマで引数の意味と型を示す
4. ツールの名前を短い番号だけにして、説明は書かずにモデルに推測させる

Q1. Bedrock のプロビジョンドスループットの説明として誤っているものはどれか。

1. 使った分のトークンだけが課金され、使わない時間の料金はかからない
2. モデルユニットを購入して、決まった処理の量を確保する
3. 1 か月や 6 か月など契約の期間を長くすると、時間あたりの料金が割り引かれる
4. カスタムモデルの推論に使える場合がある

Q2. ピークの時間にオンデマンドの Bedrock でスロットリングが増え、プロビジョンドスループットの購入を検討している。次に行うべきこととして最も適切なものはどれか。

1. スロットリングの原因を調べずに、アプリのリトライの回数だけを大きく増やしておく
2. 必要な量を測らずに、できるだけ多くのモデルユニットを最も長い期間で購入しておく
3. ピークの時間の利用を全面的に禁止して、利用者には混雑しない深夜や早朝に使ってもらうように案内することにする
4. CloudWatch でピークの時の 1 分あたりのトークンの量を測り、必要なモデルユニットの数を見積もる

Q1. 手順の大部分は決まっているが、一部の段階で FM の判断（要約や分類）を使いたい。全体の流れを確実に制御したい。最も適切な構成はどれか。

1. Bedrock のエージェントに手順を指示し、ツールの呼び出しの順序を任せる
2. Lambda の関数を順に呼び、各関数の中で次の関数を呼ぶようにつなぐ
3. Step Functions で流れを定義し、必要な段階で Bedrock の呼び出しの統合を使う
4. Bedrock のプロンプトフローで、すべての段階を FM のノードで処理する

Q2. オンプレミスのワークフローのシステムから、インターネットに出さずにアシスタントの API を呼びたい。最も適切な構成はどれか。

1. API Gateway のプライベート API と VPC エンドポイントを、Direct Connect や VPN 経由で呼ぶ
2. API Gateway のリージョンの API に、IP アドレスの制限のリソースポリシーを付ける
3. CloudFront の配信の前に API を置き、AWS WAF でアクセスを制限する
4. Lambda の関数 URL を作り、IAM の認証で呼べる相手を限る

Q1. エージェントのツールが外部の API を呼ぶ。API が遅かったり失敗したりしても、エージェントが安定して動くようにしたい。最も適切な実装はどれか。

1. タイムアウトとリトライを設け、失敗は構造化されたエラーとしてモデルに返し、次の行動を判断させる
2. API が成功するまで、待ち時間もタイムアウトもなしで同じ呼び出しを何度でも繰り返すようにしておく
3. API が失敗したら、エラーを隠して「成功しました」という結果をモデルに返しておく
4. API の失敗はすべて無視して、エージェントの処理全体をすぐに終了させることにする

Q2. 会社のすべての AWS アカウントで、承認された特定のモデルだけを使わせたい。最も適切な方法はどれか。

1. IAM Identity Center の許可セットで、各チームのロールに許可を付ける
2. 各アカウントの Bedrock のモデルのアクセスで、承認されたモデルだけを有効にする
3. Organizations の SCP で、承認されたモデルの ARN 以外への InvokeModel を拒否する
4. AWS Config のルールで、承認されていないモデルの利用を検出して通知する

Q1. Bedrock のエージェントのアクションを、Lambda ではなく自社のアプリの中で実行したい（社内のネットワークの中のシステムを呼ぶため）。最も適切な方法はどれか。

1. 社内のシステムをインターネットに公開して、エージェントから自由に呼べるようにする
2. 制御の返却（return of control）を使い、エージェントが決めた操作と引数をアプリに返して実行させる
3. アクションを使うのをやめて、エージェントには社内のシステムの情報を推測させる
4. アクションの処理をすべてプロンプトに書いて、モデルに社内のシステムを権限の制限なしで直接操作させる

Q2. 既存の受注のアプリに「受注のメモの要約」の機能を加えたい。アプリの応答の速さは変えたくない。最も適切な統合の方法はどれか。

1. 要約の機能は別のアプリにして、担当者に受注の内容を毎回手でコピーして貼り付けてもらうことにする
2. 受注の保存のイベントで非同期に要約の処理（Lambda など）を動かし、できた要約を後から画面に表示する
3. 受注の保存の処理の中で同期的に FM を呼び、要約ができるまで保存の完了を待たせる
4. 受注のメモを保存しないで、毎回 FM にメモの内容を想像して要約してもらうことにする