Bedrock Action Group に詳しくなりたい

🛠️ Bedrock Action Group とは

AWS公式のAIエージェントサービス（Agents for Amazon Bedrock）で使う、
「AIに手渡す『特製・道具セット（アタッチメント）』」のこと。

AWSには、画面をポチポチする（またはCloudFormationなどのインフラコードを書く）だけでAIエージェントが作れるAmazon Bedrockっていう公式サービスがあるんや。

そのエージェント（AI大将）に、

「お前、この仕事するときは、この道具のセットをカバンに入れて持っていきいや！」

って手渡す道具のまとまりのことを、AWSの世界では「Action Group」って呼ぶんや。

💡 1つの道具箱（Action Group）の中身
「道具をたくさん持たせるってことは、処理（関数）の数だけ別々のAWS Lambdaを大量に立てなあかんの？」って思うかも知らんけど、そんな必要は一切ナシ！

Action Groupの正体は、以下の2つがセットになったものなんや。

① 関数の説明リスト（FunctionSchema）
AIに「うちにはこんな関数があるで。名前は calculate_price で、引数には個数が必要やで」と教えるためのシンプルなリスト。

② 道具の本体（1つのAWS Lambda）
AIの指示を受けて、実際に裏で泥臭いプログラム（Python）を動かすための「共通の厨房」。

つまり、「1つのAction Group ＝ 1枚の関数リスト ＋ 1つのLambda」。

AIがリストを見て「今は金額計算の関数を動かしたいな」と選定したら、AWSのインフラがその共通のLambdaに「AIが calculate_price って言うとるで！」とデータを投げる。受け取ったLambda側で、Pythonのif文を使って実際の処理に分岐させる仕様になっとるんや。

💡 フードコートで例えると一発でわかる！

エージェント（Bedrock）を「フードコートの注文カウンター」やと思ってや。

• Action Group 1 ➔ 『うどん専門店』
  カウンターには「きつねうどん」「天ぷらうどん」って書かれたメニュー表（OpenAPI）が置いてある。
  その奥には、1つの厨房（Lambda）があって、そこでうどん職人が全部のうどんを作ってる。

• Action Group 2 ➔ 『ラーメン専門店』
  カウンターには「醤油ラーメン」「塩ラーメン」のメニュー表（OpenAPI）がある。
  その奥には、別の1つの厨房（Lambda）があって、ラーメン職人が作ってる。

注文カウンター（Bedrock）はお客さんから「天ぷらうどん頂戴！」って言われたら、うどん専門店のメニュー表を見て「あ、これはうどん屋の厨房（Lambda）に発注やな！」って判断して、うどん屋の厨房（Lambda）だけに注文を通すんや。

これなら、うどんのメニューが10個に増えようが、厨房（Lambda）はうどん屋の1個だけで済むやろ？

💻 実際のコードで見る Action Group の最小構成

これらを実際に構築する際の、最新の「CloudFormation（cfn）」と、裏で受ける「Pythonコード」のミニマルな例がこれや！

1. インフラ側：CloudFormation（cfn）

昔みたいにややこしいOpenAPI（Swagger）のコードを書く必要はもうナシ。

FunctionSchema を使って、関数の名前と説明を箇条書きにするだけでOKや！

AWSTemplateFormatVersion: '2010-09-09'
Description: 'OpenAPI不要！最新の Bedrock Action Group 構成'

Resources:
  # ========================================================
  # 🏢 ① AWS Lambda（厨房）の定義
  # ========================================================
  TakoyakiKitchenLambda:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: takoyaki-kitchen-lambda
      Runtime: python3.11
      Handler: index.lambda_handler
      Role: !GetAtt LambdaExecutionRole.Arn
      Code:
        ZipFile: |
          # 💡 ここに下のPythonコードが丸ごと入るイメージや！

  # ========================================================
  # 🤖 ② Bedrock Agent と Action Group（道具箱）の定義
  # ========================================================
  TakoyakiAgent:
    Type: AWS::Bedrock::Agent
    Properties:
      AgentName: takoyaki-ai-agent
      FoundationModel: anthropic.claude-3-5-sonnet-20241022-v2:0
      Instruction: "あなたはたこ焼き屋のAI店長です。関西弁で元気よく対応してください。"
      
      ActionGroups:
        - ActionGroupName: TakoyakiToolGroup
          ActionGroupExecutor:
            Lambda: !GetAtt TakoyakiKitchenLambda.Arn # 💡上のLambdaを紐付け
          
          # 📄 これが最新の「関数定義リスト」や！OpenAPIは一切不要！
          FunctionSchema:
            Functions:
              - Name: calculate_price # 👈 道具その1の名前
                Description: "たこ焼きの個数から合計金額を計算します。" # 👈 AIが読む説明
                Parameters:
                  count:
                    Type: Integer
                    Description: "注文するたこ焼きの個数"
                    Required: true
              - Name: check_holiday # 👈 道具その2の名前
                Description: "お店が今日定休日かどうかを調べます。"

  # ========================================================
  # 🔐 ③ BedrockからLambdaを叩いていいよという許可設定
  # ========================================================
  LambdaPermissionForBedrock:
    Type: AWS::Lambda::Permission
    Properties:
      FunctionName: !GetAtt TakoyakiKitchenLambda.Arn
      Action: lambda:InvokeFunction
      Principal: bedrock.amazonaws.com
      SourceArn: !Sub "arn:aws:bedrock:${AWS::Region}:${AWS::AccountId}:agent/*"

2. 厨房側：Pythonコード（Lambda）

AIが関数を選んだら、AWSから event['function'] という場所に関数名が入って届く。

あとはあなたが言った通り、「この関数名ならこの処理をしてくれよな」 というif文を書くだけや！

def lambda_handler(event, context):
    # ① AIが「どの関数」を選んだかを取得
    function_name = event.get('function')
    action_group = event.get('actionGroup')
    
    response_text = ""
    
    # 💡 届いた関数名を見て、if文で実際の処理（動作）に分岐させる！
    if function_name == 'calculate_price':
        parameters = event.get('parameters', [])
        count = 1
        for p in parameters:
            if p['name'] == 'count':
                count = int(p['value'])
        
        price = count * 80
        response_text = f"たこ焼き{count}個の合計金額は {price} 円やで！"
        
    elif function_name == 'check_holiday':
        response_text = "木曜日はバッチリ営業中やで！大将ノリノリやわ！"
        
    else:
        response_text = "すまん、その道具の使い方は分からんわ…"

    # ② Bedrock Agent（Function形式）のお決まりのレスポンスに整形して返す
    return {
        'messageVersion': '1.0',
        'response': {
            'actionGroup': action_group,
            'function': function_name,
            'functionResponse': {
                'responseBody': {
                    'TEXT': {
                        'body': response_text
                    }
                }
            }
        }
    }

🔄 Strands AgentsとConverse APIとの違いについて

Strands AgentsとConverse APIについても自分なりに記事としてまとめてあるから、まだ概要を掴めてない人は先にこっちに目を通してな！

【超重要】やってることは同じでも「名前」が変わるだけ！

これまで調べてきたStrands Agents, Converse API, Bedrock Agent (Action Group)やねんけどやってることは全部「AIに道具を持たせる機能」で1ミリも変わらへんのよ。

使ってるサービス・道具	道具を持たせる機能の「呼び名」	コードや設定での見え方
Agents for Bedrock	Action Group	cfnで AWS::Bedrock::Agent の中に ActionGroup として書くやつ。
Strands Agents	tools	Agent(tools=[calculate_takoyaki_price]) ってコードで書くやつ。
Converse API	toolConfig	APIを呼び出すときに「使える道具の一覧はこれやで」ってパラメーターで渡すやつ。

な？ 全部「AIに持たせる道具箱」のことなんやけど、AWS公式機能やとAction Groupって呼ぶし、Strandsやとtoolsって呼ぶ。

言うたら、同じ「マクドの裏メニュー」のことを、関東の人が「マックの裏メニュー」って呼んで、関西の人が「マクドの裏メニュー」って呼んでるようなもんや！中身は全く同じハンバーガーやろ？

🧠 3つの機能をもう少し踏み込んで整理

なんか自分で調べておきながら頭がぐちゃぐちゃになってしもたから、改めて整理するな。

これら3つを一発でスッキリさせるための決定的な違いは、エージェントの本体（脳みそとループ処理）を、自分のプログラムの中に置くか、AWSのインフラに丸投げするかという主導権の場所なんや。

3つの正体を「主導権（どこで動くか）」で並べる

① Converse API ➔ 【完全自作の生エンジン】

• 脳みそがある場所
  • あなたのPythonコードの中

• 仕組み
  • あなたの書いたプログラムの中にAIを呼び出す。AIは「この道具使いたい」って文字で言うてくるだけ。それを聞いて、実際の関数を動かすためのif文や、もう一回AIに結果を送り返すループ（while文など）は全部あなたが1行ずつ手書きする。

• 例え
  • パーツ（エンジンとタイヤ）だけ渡されて、「1から自分で車を組み立ててな！」というスタイル。

② Strands Agents ➔ 【Python完結の自動キット】

• 脳みそがある場所
  • あなたのPythonコードの中

• 仕組み
  • あなたのコードの中にStrandsのライブラリ（Python）を呼び出す。関数に @tool とマークをつけて渡しておけば、AIが「道具使いたい」と言った瞬間に、Strandsが代わりに裏で関数を動かしてAIに送り返す往復ループを全自動でやってくれる。

• 例え
  • 「1から組むのめんどいから、最初から組み立ててある市販のカスタムカーを持ってきたで！」というスタイル。

③ Bedrock Agents（Action Group） ➔ 【AWSにお任せの巨大要塞】

• 脳みそがある場所
  • あなたのコードの「外」（AWSのインフラ側）

• 仕組み
  • ここが決定的に違う！あなたのPythonコードの中に、エージェントを動かすループ処理は1行も存在せえへん。
  • AWSのインフラ側にエージェントの脳みそを丸投げして配置する。
  • あなたのLambda（Python）は、AWSから「おい、今この道具動かせ！」って呼び出されるためだけの純粋な「道具（Action Group）」として存在するんや。

• 例え
  • 「自分の車（プログラム）なんていらん。AWSが用意してくれた自動運転の路面電車（インフラ）に乗っかるわ！」というスタイル。

🤔なんかAction GroupじゃなくてStrands Agentsでよくね？

確かに「自分のPythonコード（Lambdaなど）の中でエージェントを完結させたい」なら、Action Groupはいらん！Strands Agentsで100%事足りる。

じゃあ、なんでわざわざ「Bedrock Action Group（＋cfn）」なんていう大げさなインフラ機能が存在するのか？

それは、「エンタープライズ（大企業）のガチのシステム開発」になると、Strands Agentsのようなアプリ側のフレームワークでは太刀打ちできない、以下のような強力なメリットがあるからなんや。

1. セキュリティ（IAM）がガチガチに強固になる

大企業のシステムでは「AIに喋らせる権限」と「ドローンを飛ばす（Lambdaを動かす）権限」を完全に切り離してガードしたい。

Action Groupを使うと、「AWSのインフラ側で、このAIエージェントだけがこのLambdaを叩いていい」という最強のセキュリティの壁（IAMポリシー）をcfnとかでカチッと構築できるんや。

2. 「AIの思考ログ（足跡）」を全自動で永久保存できる

金融や公的機関のシステムでは、法律で「AIがどんな思考ステップで、いつ、何のツールを動かしたか」の証拠（ログ）を保存せなあかん。

Action Group（Bedrock Agents）を使うと、AWSのインフラ側（Amazon CloudWatch）にAIの思考プロセスが全自動で綺麗に記録されるから、デバッグや監査がめちゃくちゃ楽になる。

3. 他のAWS最強機能（Knowledge Basesなど）と「ノーコード合体」できる

AWSには、何万枚もの社内PDFを一瞬で検索できるKnowledge Bases for Amazon Bedrockっていうバケモノ機能がある。

Action Groupを使うと、インフラの設定（cfnなど）だけで、「この社内検索機能」と「あなたのLambda（道具）」をAIの脳みそに一瞬でガチャンとノーコードで埋め込めるんや。

Strandsでこれをやろうとすると、検索APIを呼び出すめんどくさいPythonコードを自力で大量に書く羽目になる。

💡 結論、どう使い分ける？

• Pythonファースト（手軽さ重視）
  • 1つのLambdaの中で、サクッと爆速で賢い自律エージェントを完結させたい時は Strands Agents が最強。

• インフラファースト（大規模・堅牢性重視）
  • AWSの巨大なシステムの一部として、セキュリティや他サービス連携（RAGなど）をcfnでガチガチに構築したい時は、Bedrock Agents（Action Group）の黄金コンボが最強！

Bedrock Action Group の超・爆速まとめ

• Action Groupとは？
  AWS公式のAIエージェント機能（Agents for Bedrock）で使う、AIに持たせる「特製・道具箱（ツールセット）」のこと。

• 中身の真実
  道具が10個あろうが100個あろうが、Lambdaを大量に立てる必要は一切ナシ！ 「1枚の関数リスト（FunctionSchema）」と「1つの共通Lambda（厨房）」をガチャンと合体させるのがプロの設計。

• 動く仕組み（インフラ派）
  AIエージェントの脳みそやループ処理は、全部「AWSのインフラ側」に丸投げ。あなたの作ったLambdaは、AWSから「おい、今この関数動かせ！」って指名された瞬間だけ起動して、仕事が終わったら即座に寝る（終了する）完全な「部品」になる。