継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

AWS Chatbot から Amazon Bedrock エージェント を呼び出してみた

AWS Bedrock Chatbot Slack

タダです.

年末に学んだ Amazon Bedrock のアップデート振り返りで Chatbot から Amazon Bedrock エージェントの呼び出しが可能になったので,それを試した備忘録です.

aws.amazon.com

Chatbot の設定

Chatbot から Berdock を呼び出す権限を付与して呼び出す Slack チャンネルを設定します.

Bedrock エージェントの追加

次回の記事でエージェントの設定について記載しますが,エージェントの作成します.その際にエージェントの ARN とエイリアス ID を控えておきます.

docs.aws.amazon.com

Slack から Bedrock エージェントを呼び出してみる

@aws connector add [コネクター名] [Bedrock エージェントの ARN] [Bedrock エージェントのエイリアス ID] のコマンドを Chatbot を設定したチャンネルで実行します.設定が適切であれば,コネクション作成が成功します.

そして,エージェントを呼び出してみます.エージェントが呼び出されて回答を返してくれました.

まとめ

Chatbot から Bedrock エージェントの呼び出しを試してみました.これまでは Slack App を作ったりする必要があったと思いますが,簡単に Slack からエージェントを呼び出せるようになりました.

Amazon Bedrock の Web Crawler を使ってみた

AWS Bedrock

タダです.

去年の年末は Bedrock を手動かして勉強をしていました.この記事はプレビューの Web クローラーをデータソースにナレッジデータベースを作った時の備忘録です.

aws.amazon.com

Bedrock Web Crawler とは

Web Crawler では Bedrock のナレッジベースで使用するために選択した URL にアクセスしウェブサイトのページをクロールすることができます.

docs.aws.amazon.com

ドキュメントに沿って試しにこのブログをソースに指定し,同期範囲は Default にしています.

なお同期範囲の種類は Default/Host only/Subdomainsがありますが,それぞれの使い分けは次のとおりです.

  • Default: 指定した URL がhttps://aws.amazon.com/bedrock/の場合,このパスとhttps://aws.amazon.com/bedrock/agents/のようなパスは検索されますが,https://aws.amazon.com/ec2/ というパスは対象になりません.
  • Host only: 指定した URL が https://aws.amazon.com/bedrock/の場合, https://docs.aws.amazon.com ã‚„https://aws.amazon.com/ec2/もクロールされます.
  • Subdomains: 指定した URL が https://aws.amazon.com/bedrock/の場合,amazon.comを含む任意のWebページ(ex.https://www.amazon.com )がクロールされます.

ナレッジデータベース作成後のテスト

試しに1つ前の2025年の目標が何かを問い合わせて意図通りに返ってきました.もう1つ Bytebase API 実行に関する記事を問い合わせてみてもいい感じに返ってきました.

制約

Web Crawler の制約も最後にまとめます.

  • Web Crawler の対象は最大9サイトまで
  • クローリング速度は 1～300 URL/分の範囲
  • ソースURLからクロールするウェブページは1～25,000の間
  • URLの正規表現パターンは最大25パターンまで

まとめ

非常に簡単にナレッジデータベース化ができました.

2025年に注力することを決める(た)

ポエム

タダです.

あけましておめでとうございます.前回の2024年の振り返りの続きで2025年の目標を書いていきます.昨年を振り返ってやることは大きく変わりませんが,数値目標は変更しています.

2025年の注力したいこと

基本的には2024年からの持ち越しですが,具体の数値を見直しました.ペースを見つつ具体の数値は上方修正したり,下方修正したりします.

No. 目標概要 アクション 結果
1 自分でWebサービスを開発・運用する Webサービスの開発して運用を1つ行う -
2 読み手を意識するアウトプット 月間のPV数を平均6,500超えを目指す -
3 本を年間30冊以上読む 月当たり2冊以上読まないと達成できないが年間で30冊を読んでインプット/何等かアウトプットする -
4 外部登壇を1回以上行う 昨年2回やったけどコンスタントに1回は発表したい -

それ以外の目標

引き続き技術的なトピック以外の個人的な目標だったりやるべきことは my-release-note のリポジトリで進捗管理していきます.業務経験の棚卸しも3ヶ月に一回はして,更新していくように今年もやっていきます.

まとめ

2025年もよろしくお願いします!

関連記事

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

2024年の振り返り

ポエム

タダです.

2024年も終わりなので,今年の振り返りを行ってきます.

目標の振り返り

本業が忙しすぎてというのは言い訳にしたくなかったのですが,すべて未達でした...来年に持ち越します.

No. 目標概要 アクション 結果
1 自分でWebサービスを開発・運用する Webサービスの開発して運用を1つ以上行う x
2 読み手を意識するアウトプット 月間のPV数を平均7,000超えを目指す x
3 本を年間50冊以上読む 月当たり4冊以上読まないと達成できないが年間で50冊を読んでインプットする x

sadayoshi-tada.hatenablog.com

アウトプットの振り返り

ブログ

今年も PV 数は7000以上を目標にして続けてきていたのですが未達でした.来年も引き続き月平均7000 PV以上を目標にさらに多くの人に見てもらえるようなブログにしていけたらと思います.今年も51記事を書きました.

月 PV 数
1 5678 pv
2 6322 pv
3 6275 pv
4 6250 pv
5 5618 pv
6 5727 pv
7 6648 pv
8 5517 pv
9 6730 pv
10 6498 pv
11 4791 pv
12 4412 pv(12/29時点)

読者数と Twitter のフォロワー数

読者数と Twitter のフォロワー数の推移も増えているのでいい傾向かと思います.来年も自分を知ってもらって興味持ってもらえる方を増やすようにアウトプットをやっていきます.

読者数 Twitter フォロワー 数
119(6人増) 889(89人増)

登壇

2回登壇ができました.そのうち一回は人生初の自主企画イベントもできたのは貴重な経験をさせてもらいました.

まとめ

2024年の一年の振り返りました.今年関わってくれた皆さん本当にありがとうございました！来年もよろしくお願いします！！

過去の振り返り

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

DuckDB で ALB のアクセスログにクエリしてみる

AWS DuckDB ALB

タダです.

前回 DuckDB で CloudTrail ログを分析してみました.今回は ALB のアクセスログを分析してみます.

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

ALB アクセスログのテーブルを作る

こちらの記事を参照させていただいてテーブルを作ってみました.

CREATE TABLE alb_log AS
SELECT *
FROM read_csv(
    '[ログファイルパス]',
    columns={
        'type': 'VARCHAR',
        'timestamp': 'TIMESTAMP',
        'elb': 'VARCHAR',
        'client_ip_port': 'VARCHAR',
        'target_ip_port': 'VARCHAR',
        'request_processing_time': 'DOUBLE',
        'target_processing_time': 'DOUBLE',
        'response_processing_time': 'DOUBLE',
        'elb_status_code': 'INTEGER',
        'target_status_code': 'VARCHAR',
        'received_bytes': 'BIGINT',
        'sent_bytes': 'BIGINT',
        'request': 'VARCHAR',
        'user_agent': 'VARCHAR',
        'ssl_cipher': 'VARCHAR',
        'ssl_protocol': 'VARCHAR',
        'target_group_arn': 'VARCHAR',
        'trace_id': 'VARCHAR',
        'domain_name': 'VARCHAR',
        'chosen_cert_arn': 'VARCHAR',
        'matched_rule_priority': 'VARCHAR',
        'request_creation_time': 'TIMESTAMP',
        'actions_executed': 'VARCHAR',
        'redirect_url': 'VARCHAR',
        'error_reason': 'VARCHAR',
        'target_port_list': 'VARCHAR',
        'target_status_code_list': 'VARCHAR',
        'classification': 'VARCHAR',
        'classification_reason': 'VARCHAR',
        'conn_trace_id': 'VARCHAR'
    },
    delim=' ',
    quote='"',
    escape='"',
    header=False,
    auto_detect=False
);
D show tables;
┌─────────┐
│  name   │
│ varchar │
├─────────┤
│ alb_log │
└─────────┘

参考記事

swfz.hatenablog.com

ALB アクセスログの分析クエリを実行する

AWS のドキュメントを参考にクエリをいくつか実行してみます.

クライアント IP アドレス別にグループ分けした HTTP リクエストの数を集計

D SELECT COUNT(request) AS
   count,
   request,
   SPLIT_PART(client_ip_port, ':', 1) as client_ip
  FROM alb_log
  GROUP BY request, client_ip
  ;
┌───────┬──────────────────────────────────────────┬───────────────┐
│ count │                 request                  │   client_ip   │
│ int64 │                 varchar                  │    varchar    │
├───────┼──────────────────────────────────────────┼───────────────┤
│     2 │ GET https://12.34.56.78:443/ HTTP/1.1     │ 123.45.657.89 │
│     1 │ GET https://12.34.56.78:443/xxx HTTP/1.1 │ 45.657.89.110 │
└───────┴──────────────────────────────────────────┴───────────────┘

ELB ステータスコードの値が200以外のリクエストを抽出

SELECT
      type,
      timestamp,
      client_ip_port,
      elb_status_code,
      target_status_code,
      request,
      error_reason
  FROM
      alb_log
  WHERE
      elb_status_code != 200;
┌─────────┬────────────────────────────┬─────────────────────┬─────────────────┬────────────────────┬──────────────────────────────────────────┬──────────────┐
│  type   │         timestamp          │   client_ip_port    │ elb_status_code │ target_status_code │                 request                  │ error_reason │
│ varchar │         timestamp          │       varchar       │      int32      │      varchar       │                 varchar                  │   varchar    │
├─────────┼────────────────────────────┼─────────────────────┼─────────────────┼────────────────────┼──────────────────────────────────────────┼──────────────┤
│ https   │ 2024-12-22 00:35:22.50771  │ 123.45.657.89:12345 │             403 │ -                  │ GET https://12.34.56.78:443/ HTTP/1.1     │ -            │
│ https   │ 2024-12-22 00:35:33.942067 │ 123.45.657.89:53456 │             403 │ -                  │ GET https://12.34.56.78:443/ HTTP/1.1     │ -            │
│ https   │ 2024-12-22 00:36:08.717268 │ 45.657.89.110:32134 │             403 │ -                  │ GET https://12.34.56.78:443/xxx HTTP/1.1 │ -            │
└─────────┴────────────────────────────┴─────────────────────┴─────────────────┴────────────────────┴──────────────────────────────────────────┴──────────────┘

まとめ

DuckDB で ALB のアクセスログを分析するのを試してみました.