こんにちは、最近やっと家にプールをリリースした志水です。夏x子供の全てを解決するのは筋肉ではなくプールです。プールこそ正義です。
今日はプールとは全く関係のないStrands Agentsについての話をしたいと思います。
はじめに
生成AI技術の進歩により、インフラ構築の手法も大きく変化しつつあります。従来のコードベースでの構築から、自然言語による意図伝達による構築へと進化が続いています。
IaP（Infrastructure as Prompt）とは
IaP（Infrastructure as Prompt）は、インフラ構築の新しいパラダイムです。従来のIaC（Infrastructure as Code）では、CDKやTerraformでコードを書いてインフラを定義していましたが、IaPでは「API GatewayとDynamoDBを連携したい」「S3で静的サイトを公開したい」といった"やりたいこと"を自然言語で伝えるだけで、AIエージェントが自動的にインフラを構築してくれます。
この概念は、Infrastructure as Promptというサイトで詳しく紹介されており、従来のIaCツールを超えた新しいアプローチとして注目されています。私自身は、IaPを「意図を自然言語で伝えるだけで、AIが自動的にインフラを構築・管理してくれる手法」として捉えています。本記事では、この考えに基づいてAIエージェントによるIaP体験を紹介します。
本記事では、AIエージェント構築のためのSDKであるStrands Agentsを、あえてCLI（コマンドラインインターフェース）から体験してみた内容を紹介します。Strands Agentsは本来、Pythonコードを書いて独自のAIエージェントやツールを開発するためのものですが、CLIからは手軽にエージェントの能力を体験できます。特に、AWSリソースの操作を自然言語で指示できるuse_awsツールを使ったIaP体験を通じて、AIエージェントの可能性と、その過程で得られた知見について詳しく解説します。
Strands Agentsとは何か？
Strands Agentsは、AWSが公開しているモデル主体（Model-First）のAIエージェント構築SDKです。LLMを「脳」として、必要に応じてコード化されたツールを自在に呼び出しながら、自律的に判断・実行できる仕組みを提供します。
実際にAWSの複数チーム（Amazon Q Developer、AWS Glue、VPC Reachability Analyzerなど）が本番環境でStrands Agentsを利用しており、安心感ありますね。
エージェント = モデル + ツール + プロンプト
Strands Agentsは以下の3つの要素で構成されています。
- モデル（LLM）: Anthropic Claude、Amazon Nova、Meta Llamaなど多様な選択肢に対応
- ツール: HTTP、ファイル操作、Python実行、そしてAWSサービス呼び出しなど20種類以上の内蔵ツールに加え、外部MCPツールも利用可能
- プロンプト: ユーザーの要望などを自然言語で与え、エージェントが各ツールを呼び出しながらタスクを遂行
この設計により、Strands Agentsは「何をすべきか（モデル判断） → ツールを呼び出す（実行） → 戻り値を基に再推論 → 最終的に応答」という自己完結型の思考ループ（エージェント・ループ）をスムーズに実現できます。
なぜStrands Agentsが注目されるのか？
コード数行で高機能エージェントが構築可能 Python3行程度でツール統合+LLMループを実装できる手軽さが魅力
マルチモデル／マルチツール対応 ベンダーに依存せず、必要に応じて外部ツールや知識ベースも連携可能
実用性に直結した設計思想 AWS Lambda、Fargate、EC2などを含む本格的な本番環境デプロイに対応
CLIとSDK：Strands Agentsの2つの利用方法
Strands Agentsには、SDKとCLIの2つの利用方法があります。
SDK：AIエージェント開発のための本格的な利用方法
Strands Agentsは本来、Pythonコードを書いて独自のAIエージェントやツールを開発するためのSDKです。これにより、特定の業務に特化したAIエージェントや、独自のツールを組み込んだエージェントを構築できます。
CLI：エージェント能力を手軽に体験する方法
一方、CLIは手軽にStrands Agentsの能力を体験できる方法です。事前に構築されたエージェントとチャット形式で対話し、内蔵ツールの能力を試すことができます。
CLIからStrands Agentsを利用する場合、以下の流れでチャットが起動されます。
pip install strands-agents strands-agents-tools strands-agents-builder strands
Strands Agentsについて解説してもらいましょう。
~ Strands Agentsについて解説して The user is asking for an explanation about "Strands Agents" in Japanese. Based on the welcome text and the tools available, I can see that this is a platform/SDK for building AI agents with tools. Let me provide a comprehensive explanation in Japanese about what Strands Agents is, its features, and how it works. # 🚀 Strands Agents について Strands Agentsは、**自己拡張型AIツール構築SDK**です。AI エージェントが自分自身でツールを作成し、拡張していくことができる革新的なプラットフォームです。 ## 🎯 主な特徴 ### 1. **セルフエクステンディング（自己拡張）** - AIエージェントが必要に応じて新しいツールを自動作成 - 実行時にツールを動的に読み込み - 再起動不要でツールの追加・修正が可能 ### 2. **ホットリロード機能** - `cwd()/tools/` ディレクトリのPythonファイルを自動監視 - ファイル変更時に即座にツールを再読込 - 開発サイクルが高速化 ### 3. **豊富な内蔵ツール** 以下のような多様なツールが標準搭載： - **計算機能**: calculator - **ファイル操作**: file_read, file_write, editor - **システム操作**: shell, python_repl - **Web・API**: http_request - **AI機能**: generate_image, use_llm, think - **クラウド**: use_aws, retrieve - **その他**: current_time, journal, environment ...
このように、まず質問について思考をして、今回であれば日本語で質問したので日本語で返信する必要があると推察して、Strands Agentsの特徴を説明しました。今回は長かったので途中で切っていますが、コードの書き方なども説明してくれていました。
Strands Agentsで利用できるツール
Strands Agentsには多彩なツールが組み込まれています。ここでは、代表的なものを簡単にご紹介します。
- RAG・メモリ系
- retrieve: 知識ベースから情報検索やRAG用途
- memory: エージェントの記憶保持
- ファイル操作
- file_read / file_write: ファイルの読み書き
- editor: ファイル編集や検索
- システム・シェル操作
- shell: シェルコマンド実行
- environment: 環境変数の管理
- cron: 定期実行のスケジューリング
- コード実行
- python_repl: Pythonコードの実行
- Web・API連携
- http_request: APIコールやWebデータ取得
- slack: Slack連携
- マルチモーダル
- image_reader: 画像解析
- generate_image: 画像生成
- speak: 音声合成
- AWS連携
- use_aws: AWSサービス操作
- ユーティリティ・その他
- calculator: 計算
- current_time: 現在時刻取得
- workflow: ワークフローの自動化
- agent_graph / swarm: 複数エージェントの連携
CLIからでも、これらのツールを活用して実用的な作業や自動化を手軽に体験できるのがStrands Agentsの魅力です。なお、AWS CLIと同様に、IAMロールやIAMユーザーなどの権限設定により、操作可能なAWSリソースを制限することも可能です。
今回検証したuse_awsツール
今回の検証では、Strands Agentsに含まれるuse_awsというツールを使用しました。このツールは、AWSリソースの操作・確認を自然言語で行えるようにするものです。
use_awsツールの特徴
- AWSリソースの直接操作: S3、DynamoDB、API Gateway、CloudFrontなどのAWSサービスを直接操作
- AWS APIとの統合: boto3ライブラリを使用してAWS APIを適切に呼び出し
- AWS認証情報の自動利用: 設定済みのAWS認証情報（IAMロール、アクセスキー等）を自動で利用
- AWSリソースの状態確認: 既存リソースの確認や、作成後の動作検証を自動実行
- AWSベストプラクティスの適用: セキュリティ設定や権限設定を自動で最適化
このツールにより、AWSの詳細な知識がなくても、自然言語での指示だけでインフラを構築できるようになります。
use_awsツールの簡単な体験例
たとえば、use_awsを使って「y3-shimizu」という名前を含むS3バケットを作成してみました。
~ y3-shimizuと名前に入る適当な名前のS3バケットを作成して
ユーザーは「y3-shimizu」が名前に含まれる適当な名前のS3バケットを作成したいとのことです。S3バケット名は全世界でユ
ニークである必要があり、また以下の制約があります：
1. 3-63文字の長さ
2. 小文字、数字、ハイフンのみ使用可能
3. 文字または数字で開始する必要がある
4. ハイフンで終わってはいけない
5. 連続するハイフンは使用できない
6. IPアドレス形式は使用できない
既存のバケットを見ると「y3-shimizu-hoge」「y3-shimizu-fuga」があるので、それらと重複しない適当な
名前を考える必要があります。
適当な名前として、現在の日時を含めたり、「test」や「temp」などの用途を示す文字を含めるのが良いでしょう。
例：
- y3-shimizu-test-bucket
- y3-shimizu-temp-2025
- y3-shimizu-workspace
- y3-shimizu-sandbox
タイムスタンプを含めてユニークにするのが安全かもしれません。
「y3-shimizu」が含まれる適当な名前のS3バケットを作成しますね。タイムスタンプを含めてユニークな名前にします。現在の時刻を取得しました。これを使ってユニークなバケット名を作成します。日付形式を使って「y3-shimizu-hogehoge」のような名前にしましょう。
ℹ 🔧 Starting use_aws...
╭─────────────── y3-shimizuが含まれるS3バケットの作成 ───────────────╮
│ Service: s3 │
│ Operation: create_bucket │
│ Parameters: │
│ - Bucket: y3-shimizu-hogehoge │
│ - CreateBucketConfiguration: {'LocationConstraint': 'us-west-2'} │
│ │
╰────────────────────────────────────────────────────────────────────╯
The operation 'create_bucket' is potentially mutative. Do you want to proceed? [y/*] y
✔ use_aws completed in 30.37s
S3バケットの作成が成功しました。レスポンスに200 HTTPステータスコードとLocationが含まれているので、正常に作成されています。
バケット名: y3-shimizu-hogehoge
リージョン: us-west-2
作成時刻: 2025年7月1日
これで「y3-shimizu」が含まれる新しいS3バケットが作成されました。✅ **S3バケットの作成が完了しました！**
## 📦 作成されたバケット情報
- **バケット名**: `y3-shimizu-hogehoge`
- **リージョン**: `us-west-2`
- **作成日時**: 2025年7月1日 01:00 UTC
- **URL**: http://y3-shimizu-hogehoge.s3.amazonaws.com/
今日の日付（20250701）を含めた適当な名前で、テスト用途を示す「test」という文字も含めました。このバケットは正常に作成され、すぐに使用可能な状態です。
何かファイルをアップロードしたり、バケットの設定を変更する必要があれば、お知らせください！
この指示だけで、y3-shimizu-hogehoge という新しいS3バケットがオレゴンリージョンに作成されました。バケット一覧にもすぐ反映され、CLIから自然言語でAWSリソースを操作でき、非常に便利でした。
なお、リソースの作成・更新・削除を行う場合は、実行前に確認プロンプトが表示されるため、誤操作防止にも配慮されています。
一方、情報取得や一覧表示などの参照操作では確認は入らず、すぐに結果が返ってきます。
use_awsで3つのIaP実践体験
ここからは、use_awsツールを使って実際に3つのIaP体験（API GatewayとDynamoDBの連携、CloudFrontとS3による静的サイト配信、QuickSight連携）を作成・検証してみた内容を順にご紹介します。
実践検証：API GatewayとDynamoDBの連携
use_awsツールを使い、API GatewayとDynamoDBを連携したREST APIを構築してみました。以下の自然言語での指示だけで、完全に動作するAPIが構築されました。
- 適当にDynamoDBのテーブル作って。
- 適当にデータを追加して。
- このテーブルをAPIで見れるようにしたい。
まず「適当にDynamoDBのテーブル作って」と自然言語で指示すると、パーティションキーがuser_idの「Users」テーブルが自動で作成されました。次に「適当にデータを追加して」と依頼すると、3人分のサンプルユーザー（田中太郎、佐藤花子、鈴木一郎）が追加され、scanで全件取得できることも確認できました。
さらに「このテーブルをAPIで見れるようにしたい」と伝えると、API GatewayのREST APIが自動で作成され、/usersリソースとGETメソッドが追加されました。DynamoDBのscan結果を通常のJSON形式に整形するレスポンステンプレートも自動生成され、prodステージにデプロイしてくれました。
実際にcurlコマンドでAPIエンドポイントを叩いてみると、Usersテーブルの全データがJSON形式で返ってきました。
$ curl https://xxxxxxxx.execute-api.us-west-2.amazonaws.com/prod/users
{
"users": [
{
"user_id": "user002",
"name": "佐藤花子",
"email": "sato@example.com",
"age": 30,
"is_active": true,
"created_at": "2025-06-13T10:30:00Z"
}, {
"user_id": "user001",
"name": "田中太郎",
"email": "tanaka@example.com",
"age": 25,
"is_active": true,
"created_at": "2025-06-14T00:01:00Z"
}, {
"user_id": "user003",
"name": "鈴木一郎",
"email": "suzuki@example.com",
"age": 28,
"is_active": false,
"created_at": "2025-06-12T14:15:00Z"
} ],
"count": 3
}
今回の検証では、APIリクエストの失敗も一度もなく、驚くほどスムーズにAPIが作成できたのが印象的でした。たった3回の依頼（テーブル作成・データ作成・API作成）だけで、実用的なAPIが完成してしまう手軽さには本当にビックリでした。
実践検証：CloudFrontとS3による静的サイト配信
次はS3に静的ファイルを配置し、CloudFrontで配信する構成を試してみました。以下の自然言語での指示で、セキュアな静的サイト配信環境を構築しました。
- S3バケットを作成して。ただし公開しないでほしい。
- 適当なindex.htmlを作ってアップロードして。
- このファイルを公開したいので、CloudFrontを作成してS3と接続して。
まず「S3バケットを作成して。ただし公開しないでほしい」と依頼すると、パブリックアクセスがすべてブロックされたプライベートなS3バケットが作成されました。
次に「適当なindex.htmlを作ってアップロードして」と指示すると、日本語対応のindex.htmlがS3にアップロードされました。
さらに「このファイルを公開したいので、CloudFrontを作成してS3と接続して」と伝えると、CloudFrontディストリビューションが作成され、OAC（Origin Access Control）も適用されました。
最初はCloudFront作成直後にすぐアクセステストしてエラーとなり、バケットポリシーやアクセス設定を色々変更してしまいましたが、実はCloudFrontのデプロイ完了（Status: Deployed）まで待つ必要がありました。
最終的には、正しい手順でデプロイ完了を待ってからアクセスすることで、index.htmlが無事に配信されることを確認できました。
OACの設定に失敗した際に、他の方法（バケットポリシーの調整など）で何とか公開しようとチャレンジするエージェントの動きは、まるで若手エンジニアが試行錯誤しながら成長していくような人間味を感じた点も印象的でした。use_awsなら、こうした一連の流れも自然言語で指示でき、セキュリティと利便性を両立した構成が簡単に実現できると実感しました。
実践検証：QuickSightによるコスト分析ダッシュボード構築
最後に、use_awsツールを使ってAWSコストデータの可視化基盤を構築する体験を試してみました。以下の自然言語での指示で、コスト分析ダッシュボードの構築に挑戦しました。
- AWSコストデータをS3に出力して。
- このデータをQuickSightで分析したい。
まず「AWSコストデータをS3に出力して」と依頼すると、AWS Cost Explorer APIを利用して過去30日分のサービス別コストデータが取得され、その内容がCSVファイルとして自動生成され、指定したS3バケットにアップロードされました。
続いて「このデータをQuickSightで分析したい」と指示しました。最初はS3のCSVファイルをそのままQuickSightのデータソースにしようとしましたが、マニフェストファイルが必要であることが分かり、一度失敗しました。そこで、QuickSight用のマニフェストファイルを生成し、S3にアップロードした上で、改めてQuickSightのS3データソースを作成しました。
データソースを元にデータセットを作成しようとしたところ、最初は数値カラム（Daily_Totalや各サービス名）をDECIMAL型で指定しようとしましたが、エラーとなってしまいました。S3経由では全カラムがSTRING型になるため、全カラムSTRING型で再作成したところ、無事にデータセット作成に成功しました。
その後、日別コスト推移やサービス別コストのグラフを含むQuickSight分析（Analysis）を作成し、さらにダッシュボード作成にも挑戦しました。最初はデータ型（STRING/DECIMAL）の不一致でダッシュボード作成に失敗しましたが、ダッシュボード定義を直接指定して再試行したところ、作成自体は成功しました。
しかし、ダッシュボードのグラフが正しく表示されないという問題が発生しました。これは、データセットの数値カラムがすべてSTRING型のままになっていたためで、API経由での型変換や更新にはAlias指定が必要だったり、QuickSightのAPI自体が非常に複雑だったため、Strands Agentsが自動化による完全なグラフ表示は諦めざるを得ないと判断しました。
最終的には、Strands Agentsが「ダッシュボードの枠組みは作成済みですが、グラフを正しく表示するにはQuickSightコンソールで手動対応が必要です」と私に報告し、作成されたリソース一覧や手動での最終調整手順（データセット編集→カラム型をDecimalに変換→ビジュアル修正）も案内する形になりました。
今回の詰まりの本質的な原因は、設計を十分に行わず、いきなり構築に着手してしまったことにあります。本来であれば、事前に要件やデータフロー、データ型の扱いを整理してから手を動かすべきでした。特に、S3を直接QuickSightに連携するのではなく、AthenaやGlueを経由してスキーマを明示的に定義する設計にしていれば、型の問題も回避できたはずです。設計を省略したことで途中で問題に直面し、手戻りや手動対応が発生してしまいました。
ただし、Strands Agentsが諦めた理由を明確に説明し、その後の対応方法まで具体的に提案してくれた点は、まるで経験豊富なチームメンバーが「ここまでは自動化できたけど、残りは手動で対応する必要があるね。でも、こうすれば完成するよ」と教えてくれるような、非常に人間味のある終わり方でした。技術的な限界を正直に伝えつつ、次のステップまで案内してくれる姿勢は、AIエージェントとは思えない自然なコミュニケーションだと感じました。
この体験を通じて、Strands Agentsを活用する場合も、まず設計でゴールや要件を明確にしてから構築に進むことが、スムーズなプロジェクト推進につながると実感しました。
検証を通じて見えてきた課題と対策
今回の3つの検証を通じて、Strands Agentsの活用における共通の課題と対策が見えてきました。
設計の重要性
QuickSightの検証で直面した問題の本質的な原因は、設計を十分に行わず、いきなり構築に着手してしまったことにあります。本来であれば、事前に要件やデータフロー、データ型の扱いを整理してから手を動かすべきでした。特に、S3を直接QuickSightに連携するのではなく、AthenaやGlueを経由してスキーマを明示的に定義する設計にしていれば、型の問題も回避できたはずです。設計を省略したことで途中で問題に直面し、手戻りや手動対応が発生してしまいました。
デプロイ完了の待機
CloudFront＋S3の構成では、CloudFront作成直後にすぐアクセステストしてエラーとなり、バケットポリシーやアクセス設定を色々変更してしまいましたが、実はCloudFrontのデプロイ完了（Status: Deployed）まで待つ必要がありました。このように、AWSリソースの作成後は適切な待機時間を設けることが重要です。
セキュリティ設定の維持
CloudFrontの検証では、OACの設定に失敗した際に、他の方法（バケットポリシーの調整など）で何とか公開しようとチャレンジしましたが、セキュリティ設定を安易に緩和することは避けるべきです。適切なセキュリティ設定を維持しながら、正しい手順で設定を行うことが重要です。
エージェントの成長とルール化
エージェントも完璧ではないので、失敗した時に何が失敗だったかを人間側が判断し、それをテキストでルールとして出力させて今後はそれを基に進めていけば、エージェントが成長していくと感じました。そしてCLIで試行錯誤して得られたルールを基に、SDKでエージェントを作成するという流れがCLIとしての正しい使い方なのだと実感しました。
AIエージェントとしてのStrands Agentsの利点
Strands Agentsの利点として、AWSの詳細な知識がなくても基本的な構成が可能な点が挙げられます。たとえば、IAMやバケットポリシーなどの権限設定、API GatewayとDynamoDBの連携方法、CloudFrontとS3の安全な接続やOACの設定、QuickSightのデータソースやデータセット作成手順といった、通常はドキュメントを読み込んだり試行錯誤が必要な部分も、自然言語で指示するだけで自動的に構築できました。これにより、学習コストを大幅に削減できるだけでなく、プロトタイピングや検証環境の構築も迅速に行えるようになりました。また、ベストプラクティスに沿った設定が自動的に適用されるため、初心者が陥りがちなエラーを未然に防ぐことができます。
CLIとSDKの使い分け
今回の検証ではCLIからStrands Agentsを体験しましたが、CLIとSDKの使い分けについても学びがありました。CLIは手軽に体験や試行錯誤ができる反面、失敗した時の原因分析やルール化が重要になります。一方、SDKでは事前にルールやプロンプトを設計してからエージェントを構築するため、より安定した運用が可能です。CLIで試行錯誤して得られた知見を基に、SDKで本格的なエージェントを構築するという流れが、Strands Agentsの正しい活用方法だと実感しました。
課題と注意点
一方で、課題も存在します。一部の高度な設定やサービス連携には制限があり、細かい設定の調整が難しい場合があります。また、自動化により技術的な理解が浅くなってしまう可能性も懸念されます。このため、本番環境での利用にはルール化の厳重な整備を行うなど慎重な検討が必要でしょう。
今後の展望
今回の検証を通じて、インフラ構築の世界が「IaC（Infrastructure as Code）」から「IaP（Infrastructure as Prompt）」へと進化しつつあることを実感しました。
4年前に執筆した記事「Architecture as Codeってなぁに？ 〜Infrastructure as Codeを超えて〜」では、IaCを超えた「AaC（Architecture as Code）」の概念について説明しました。AaCは個々のリソースではなく、アーキテクチャパターン全体をコード化する手法で、AWS CopilotやAWS Amplifyがその代表例です。そして今回の体験を通じて、次は「IaP（Infrastructure as Prompt）」の時代が到来しつつあると感じています。
IaCからAaC、そしてIaPへの進化
インフラ構築の手法は以下のように進化してきました。
- IaC（Infrastructure as Code）: CDKやTerraformで個々のリソース構成を書く時代
- AaC（Architecture as Code）: AWS CopilotやAmplifyでアーキテクチャパターン全体をコード化する時代
- IaP（Infrastructure as Prompt）: 「API GatewayとDynamoDBを連携したい」「S3で静的サイトを公開したい」といった"やりたいこと"を自然言語で伝える時代
Strands AgentsのようなIaP実現ツールは、複数の分野での活用が期待されます。プロトタイピングではアイデアの迅速な検証が可能になり、学習支援ではAWS初心者の学習ツールとして活用できます。また、開発効率化では標準的な構成の自動化を実現し、技術的負債の軽減では複雑な設定の自動最適化が期待できます。
ただし、IaPの本格的な運用には、対応範囲の拡大やカスタマイズ性の向上、テストやガードレールの整備など様々な方面での整備が必要と感じています。
まとめ
Strands AgentsによるIaP体験を通じて、生成AI技術がインフラ構築にもたらす可能性を実感できました。特に、技術的な知識が少ない方でも直感的にAWSリソースを操作できる点は、大きな価値があると評価できます。
今回の体験は、まさに「CDKやTerraformで構成を書いていた時代から、"○○したい"と意図を書く時代へ」という変化を体感するものでした。完璧なツールではありませんが、適切な用途で使用することで、開発効率の向上や学習支援に大きく貢献できるツールであることが確認できました。
また、各AWS構成の自動化体験を通じて、Strands Agentsがまるで若手エンジニアが試行錯誤しながら成長していくような人間味や奮闘ぶりを見せてくれた点も印象的でした。こうした「AIエージェントの人間味」を感じられるのは、自然言語によるインタラクションならではの面白さだと感じます。
今回の検証ではCLIからStrands Agentsを体験しましたが、CLIとSDKの使い分けについても学びがありました。CLIは手軽に体験や試行錯誤ができる反面、失敗した時の原因分析やルール化が重要になります。一方、SDKでは事前にルールやプロンプトを設計してからエージェントを構築するため、より安定した運用が可能です。CLIで試行錯誤して得られた知見を基に、SDKで本格的なエージェントを構築するという流れが、Strands Agentsの正しい活用方法だと実感しました。
今後の技術進歩により、さらに実用的なAIエージェントへと進化し、IaPがインフラ構築の標準的な手法となる日が来ることを期待しています。
