re:Invent 2025: Strands Agents SDK for TypeScriptによる本番環境AIエージェント構築
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Build production AI agents with the Strands Agents SDK for TypeScript (AIM3331)
この動画では、AmazonのRyanとNickがStrandsのTypeScriptリリースとエージェント構築のアプローチについて解説しています。Strandsは数行のコードでエージェントループを実行できるフレームワークで、モデル駆動型アプローチを採用し、開発者がワークフローを詳細に定義する代わりにLLMに推論させます。TypeScript SDKは0.1プレビュー版としてリリースされ、Bedrock、OpenAIなどのモデルプロバイダー、MCP、A2A、OTELといったオープンスタンダードをサポートします。Agent SOPsという標準作業手順書を用いたプロンプティング技術や、Steering機能によるモジュラープロンプティング、評価ライブラリなど新機能も紹介されました。特筆すべきは、TypeScript SDKの開発自体にStrandsエージェントを活用し、GitHubワークフローと統合したRefinerとImplementerエージェントにより、開発効率を4倍に向上させた実例です。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
Strands TypeScriptリリースの発表：数行のコードでエージェントを構築
皆さん、おはようございます。私が皆さんとランチの間の最後の障害になると思います。私はRyanと申しまして、AmazonのPrincipal Product Managerをしております。私の同僚のNickも一緒でして、彼は途中で登壇する予定です。今週ずっと皆さんにお話しするのを本当に楽しみにしていました。ただ、昨日声を失ってしまいまして、もし私の声が途切れたり、水を飲むために止まったりしても、どうかご容赦ください。
Nickと私は両方ともStrands Agentsチームの出身です。このカンファレンスで皆さんにStrandsについてお話しするのを本当に楽しみにしていました。多くの方が私たちのブースをご覧になったかもしれませんが、今日は私たちの最新リリースであるTypeScript、そしてそれに関連する他のリリースについてお話しします。私はエージェントを構築するためのこのシンプルなインターフェースについてお話しする時間を取りますし、その背後にあるものについてもお話しします。数行のコードでエージェントを構築するとはどういう意味なのか、ということです。
このコードサンプルは、実際にPyPIからStrandsとStrands Toolsパッケージをインストールしていれば動作します。デフォルトのモデルプロバイダーとしてBedrockを使用していれば、これを実行してエージェントループを動かすことができます。ですので、これがどのように動作するのか、なぜ動作するのかを説明していきます。そしてもちろん、TypeScriptリリースについても少しお話しします。
Nickが登壇して、私たちがどのように構築したかについてお話しします。それでは、ここから進めていきます。Strands、TypeScriptリリース、エージェントループへのモデル駆動型アプローチ、などについてです。まず、多くの方が私たちがTypeScriptにリリースすることを受けて、今ここに参加されていると思いますので、これを先に済ませておきたいと思います。
これについて非常に興奮しています。昨日の時点でプレビューリリースとなっており、GitHubとNPMで0.1という意味です。ただし、同じスタイルのStrandsです。私たちは5月にPython SDKをリリースして以来持っていたすべてのものをTypeScriptに持ち込むために本当に一生懸命取り組んできました。それは同じシンプルなインターフェース、数行のコード、エージェントループの実行です。ただし、Pythonと同等の1.0に到達するまでのこのプレビューリリースにはいくつかの制限があります。ですので、注意していただきたいのですが、これは今日の時点ではシングルエージェントシステムの構築についてです。マルチエージェントパターンはまだ追加していません。他のいくつかの機能も欠けているかもしれません。OpenTelemetryのようなものについては、数週間後に迅速にフォローアップする予定ですが、今日はBedrockやOpenAIモデルのような基本機能を使用できます。
asyncと非asyncをストリーミングと一緒に使うことができます。マルチターンエージェントのための完全なエージェント状態と会話管理ができますし、もちろん、Strandsを触り始めた方であれば、そのライフサイクルを検査したり変更したりするためのフックも使えます。フックは、ライフサイクルの異なるポイントで動作を観察したり変更したりするための強力な機能です。
モデル駆動型エージェントとは：ゴール解決のためのツール実行ループ
では、少し話を戻して、PythonとTypeScript、この両方の言語において、モデル駆動型エージェントを持つということがどういう意味なのかについてお話ししましょう。皆さんの中には、今まさにエージェントを構築している方もいらっしゃると思います。そういう方にとっては今更な話かもしれませんが、まだこの領域に入っていない方のために、ここで一度立ち止まる価値があると思います。というのも、多くの方がエージェントについて、LLMの呼び出しがあって、MCPのような内部・外部ツールを与えたらどうなるか、というように考えているからです。それは完全にエージェント的とは言えません。非常に広い用語ですし、業界はまだその定義を固めている最中だと思います。
ここでの私たちの定義は、エージェントはゴールを解決するためにツールをループで実行するというものです。これからお話ししていくStrandsの背後にある設計は、すべてそのループを可能にすることに関するものです。つまり、Strandsは上部にあるそのエージェントループを管理していると考えることができます。そのループに与える入力がプロンプトです。それはシステムプロンプトであり、もちろんユーザーがアプリケーションに対してプロンプトする内容でもあります。そして戻ってくるのが最終結果です。
ループの中には、ツールを装備した強力な推論モデルがあり、システムプロンプトを通じて割り当てられたゴールがあります。それは、それらのツールをどのように使うか、取得した情報がそのゴールを解決するのに十分かどうかを判断するために、独自の推論を行っています。必要であればさらにツールを実行するかもしれませんし、ユーザーに満足のいく応答を返すために必要な回数だけそのサイクルを完了します。このライフサイクル全体を通じて、どのようにそれを制御できるか、モデルを誘導する方法、モデルを制約する方法をどのように追加できるかについてお話ししていきます。しかし、要するにそういうことです。モデルに独自のワークフローを考え出させるこのアーキテクチャを受け入れるだけで、本当に早く、遠くまで到達できます。これについてはさらに詳しくお話しします。
エージェントループの構成要素：推論モデル、ツール、そしてモジュラー設計
しかし、まずそのエージェントループの中に何があるのかをもう少し文脈化するために。まず第一に、それはモデルです。それが必要な一番のものであり、具体的にはツールを使える推論モデルです。最近では、それは非常に多くの選択肢があります。常にそうだったわけではありません。もちろん、大手AIラボのことを考えてみてください。Gemini、OpenAI、Anthropicのモデルを使うことができます。Novaの最新の推論モデルを使うこともできます。これらのモデルの多くはBedrock上で利用可能です。しかし、Strandsはどのモデルプロバイダーとも動作するように設計されています。例えば、OpenAIやAnthropicのファーストパーティAPIに直接アクセスすることもできます。さらに多くのプロバイダーが同じインターフェースを持っています。
また、独自のカスタムゲートウェイを持ち込むこともできます。例えば、LiteLLMのサポートが今日のPythonライブラリでStrandsに統合されています。これは今後、TypeScriptインターフェースにも追加していく予定です。多くのお客様は独自のゲートウェイを持ち込まれることもあります。LiteLLMである必要はありません。カスタムモデルプロバイダーと呼ばれる抽象化の仕組み全体があり、PythonまたはTypeScriptで、そのゲートウェイ製品や市場に登場する別のモデルプロバイダーとどのようにやり取りするかを定義できます。Strandsへのオープンソースコントリビューションの多くは、それらのモデルのユーザーやベンダー自身によるモデルプロバイダーで、Strandsをそれらのモデルで使用できるようにサポートを追加しています。
最後に、その最上位レイヤーを推論モデルの選択として考えることができますが、推論モデルだけである必要はありません。例えば、非常に一般的なパターンとして、エージェントループの推論モデルとしてClaude 3.5 Sonnetを選んだとしましょう。ツールとして、例えばStabilityの画像生成モデルを割り当てることができます。これは、Stabilityチームによって提供されたコミュニティパッケージで利用可能なツールの1つです。その推論モデルは、推論モデルではないが画像生成のような他の目的のために設計された他のモデルを使用できます。このように、同じエージェント内で組み合わせて使うことができます。エージェント内で多くのモデルを呼び出すことができます。
エージェントを外部から装備する場合、私たちはオープンスタンダードを採用しています。デザイン原則については、もう少し詳しくお話しします。しかし、要するに、任意のMCPサーバーを持ち込むことができ、エージェント通信にはA2Aを使用できます。すべてのトレースとトラジェクトリーは、OTELを通じてお気に入りのOpen Telemetryプロバイダーに送ることができます。ツールはエージェントループにとって非常に重要なので、どのような選択肢があるのか、ここで少し立ち止まってお話ししたいと思います。
明らかにMCPがあります。MCPクライアントとしてStrandsで任意のMCPサーバーを使用でき、すべての異なる認証タイプに対応しています。MCPの仕様が進化するにつれて、私たちのクライアント実装も進化させ続けています。PythonとTypeScriptの両方で、独自の関数を持ち込んで、それをツールとして使用できます。すでにソフトウェアをお持ちの場合や、使いたいライブラリを取り込んでエージェントにツールとして公開したい場合、本当に簡単にそれができます。
Pythonパッケージでは、多数の組み込みツールを提供しています。TypeScriptにはそのうちのいくつかしかありませんが、今後それらも拡張していく予定です。しかし、それらも同様の仕組みです。まるで独自のツールを関数として構築したかのように、パッケージ経由でインストールしてインポートできます。エージェントをツールとして使うパターンについて立ち止まってお話しするのは、これがエージェントを構築する方法として見過ごされがちだと思うからです。オーケストレーションの文脈で、これをスーパーバイザーパターンとして聞いたことがあるかもしれません。
これを、この強力な推論モデルでStrandsを構築していると考えてください。そして、例えば、バックエンドシステムとのやり取りに本当に優れたエージェントを構築したいと思うかもしれません。例えば、私が対応したお客様で、AtlassianのJira用MCPサーバーを使用している方がいました。彼らは、自分たちのJiraシステムとのやり取り方法を理解することに特化したエージェント全体を作りたいと考えていて、Strandsのフックのような機能を使ってツールコールをパースしていました。なぜなら、Jiraストーリーが非常に大きくてコンテキストウィンドウを圧迫してしまう可能性があるからです。そのエージェントの仕事全体は、このストーリーについて返したい興味深い内容が何かを理解することです。彼らはそれをすべてこのサブエージェントとしてカプセル化しました。そして、それを上位レベルのオーケストレーター、つまりスーパーバイザーエージェントにツールとして公開したのです。このアプローチでモジュール性が得られますし、常に決定論的なツールを使う必要はないというのが私の言いたいことです。エージェント自体がツールになり得るのです。
Strandsの設計原則：シンプルさ、拡張性、そしてオープンスタンダード
これから、なぜ私たちがStrandsを構築したのか、そしてその背景にあるストーリーを少しお話ししていきますが、その前提として、これは私たちのリポジトリで見つけることができるコントリビューションガイドラインのスナップショットです。特にStrandsへのコントリビュート方法に関連する原則です。ここでスライドにまとめていますが、すべてGitHubリポジトリで入手可能です。Amazonのプロセスに馴染みがない方のために説明すると、私たちは原則をとても重視しています。これらは意思決定の方法を定義するものです。これらは互いに緊張関係を持つように意図されていて、私たちがチームとして、あるいはStrandsにコントリビュートするオープンソースコミュニティとして意思決定を行う際に、トレードオフについて決定する際のガイドとして使用できます。また、これらは私たちがどのようにこのソフトウェアを皆さんのために構築しようとしたかの物語を語っていると思います。
一つはシンプルであること、そして本当に重要なのは、ラップトップでのプロトタイピングから本番環境での実行まで、同じ抽象化でシンプルであることです。言い換えれば、シンプルなエージェントループを動かすことは非常にシンプルであるべきです。後でテレメトリーやロギングを統合することも、同じようにシンプルであるべきです。拡張性についてはすでに少し話しましたね。モデルプロバイダーは拡張性の良い例ですし、ツールも拡張性の別の良い例ですが、これはすべてに適用されます。フックは基本的に、ライフサイクルの特定のポイント、ツールコールの前後、モデルコールの前後といったところで制御を引き継ぐメカニズムです。
そして、独自のフックをプラグインできます。私たちもいくつか提供しています。例えば、一時的な障害に対するBedrockモデルからのリトライをキャプチャするのに役立つ組み込みフックがあります。このような拡張性を取り入れて、できる限りあらゆる場所に適用しています。そしてもちろん、これらはすべて連携して動作するように意図されています。すべてが正しい道へと導くように意図されています。より多くの機能を重ねていくにつれて、私たちの抽象化に組み込まれたデフォルトは、良い体験を提供するように意図されていて、これらの多くをカスタマイズできます。
そして、人間とエージェントの両方にアクセス可能であることは、ある意味新しく出てきたものです。これの具体的な例として、StrandsAgents.comにアクセスすると、実際に末尾にslash latest slash llms.txtを追加して、このマークダウン形式の目次を取得できます。基本的にこのllms.txtまたはllmstxt.org、これが確かこの標準のURLだと思いますが、これはコーディングアシスタンスやモデルトレーニングのドキュメントに、HTMLからマークダウンへの双子のようなものを公開する方法です。つまり、人間としてはウェブサイト上でHTMLドキュメントを読んでいますが、私たちはモデル向けにマークダウンを公開していて、それをモデルが知っている、あるいはモデル周辺のシステムが見つけ方を知っている標準プロトコルで利用可能にしています。共通の標準についてはすでに話しましたね。新しいものが出てくれば、それらを追加していきます。今日、私たちはすでに主要なものをサポートしています。
Amazon Qチームでの経験：コンセプトから本番環境まで数週間で実現
では、ストーリーテリングに戻りましょう。私が述べたように、Nickと私はStrandsチームの出身です。その前は、AmazonのQチーム、そして現在Quiroとして知られているチームの一員でした。具体的には、他のAmazonチームがQを拡張できるようにするプロジェクトに取り組んでいました。Amazonでこれらのスーパーエージェントを構築しているのは、1つのチームだけではないことは想像できると思います。多くのチームが協力し合い、それぞれの専門知識を共有しているのです。そしてこれは、Nickどうだっけ、今から1年以上前、ほぼ2年前になりますね。かなり前のことで、私たちがこれをやっていたのは、エージェンティックの非常に初期の頃でした。
そして私たちは、多くのチームがConverse APIや他のAPIを使って独自のソリューションを構築しているのを観察していました。彼らは構築したワークフローの周りでループ状にLLM呼び出しを行っているだけだったり、あるいはそれよりもシンプルな既製のフレームワークを使っていましたが、それでも本当にエージェンティックとは言えませんでした。今日お話ししているようなエージェンティックループは確実に持っていませんでした。決定論的なワークフローに多くの時間を費やす必要がありました。つまり、良いアイデアを持っているエンジニアや、何かを構築したいプロダクトチームは、何かを立ち上げるのに数ヶ月かかっていたのです。アイデアからプロトタイプまで、そしてプロダクションに入れるにはさらに長い時間がかかっていました。
そこで私たちが注力したのは、もちろん、私たちの要求が数十のチームをオンボーディングして、エージェンティック機能を1つの顧客体験に統合することだったので、別の方法に取り組み始めました。そしてそれが、例えばQuiroチームのこれらの結果につながったのです。彼らはコンセプトからプロダクションまで数週間で進めることができました。それが私たちの推進目標でした。私たちはこの内部フレームワークを繰り返し改善し、これらの目標を達成するために、適切な機能を追加し、適切な開発者体験を見つけ出し、その結果、これらのチームやAmazon全体の他のチームが本当に、本当に速く動けるようになりました。
今年の5月に、私たちはそれを公開しました。それがStrandsの最初のプレビューリリースでした。著名な方々からソーシャルメディアで非常に寛大な言及をいただきました。昨日Swamiが言及したように、PyPIでPython SDKが500万ダウンロードを超えるという幸運に恵まれました。明らかに、TypeScriptではまだ始まったばかりですが、皆さんのお役にも立てることを願っています。そして私は皆さんの多くとお会いしてきました。Strandsと皆さんが構築しているエージェントについて話しすぎて、声を失った理由の一部です。そして、5月の最初のリリースから現在まで、皆さん全員が、私たちがStrandsを利用可能にしたことで、はるかに速く構築できているというシグナルを見始めていることに、とても興奮しています。そして、私たちが社内の顧客のために構築できた成果を、皆さんも得られているのを見ています。
ワークフロー駆動型からモデル駆動型へ：開発者の作業をLLMにシフト
それでは、このアーキテクチャにおけるモデル駆動型アプローチに話を戻しましょう。要約すると、ここでのポイントは、開発者として考えるべきことが非常に少ないということです。エージェントに実行させたいゴール、システムプロンプトについて考えます。そして、より細かく制御するためのテクニックについては後ほどお話しします。そのエージェントに装備させるツールについて考えます。これらのツール自体がエージェントになることもでき、このようにしてモジュール性が得られ、複雑さを分解することができます。そして、これをアプリケーションに組み込み、プロンプトを送り、結果を得る。これがエージェントループです。
そして、これを区別したかったのです今日の市場における非常に幅広い選択肢、つまり自分で構築するか、オープンソースプロバイダーから入手できるフレームワークを使うかという選択肢からです。これは、ワークフロー駆動型とモデル駆動型の間のシフトです、私はそう名付けました。
ここでの違いは、そのゴールをプランに分解し、ツール呼び出しを行い、それらのツール呼び出しの結果を分析し、さらに必要かどうかを判断し、顧客に結果が返されるまでそのループを反復するために必要なステップを定義するのは誰か、ということです。誰がその作業を行うのか?私たちがQチームで経験してきたのは、すべての開発チームがその作業を行い、これらのオープンソースフレームワークによって提供される抽象化を使用して、または自分たちで構築した独自システムとして、これらのワークフローを記述していました。彼らがすべての作業を行っていたのですが、それが導くのは、構築にも多くの時間がかかる、かなり脆弱なシステムです。開発者は新しいシナリオを予測しなければなりませんでした。例えば、チャット体験における新しいカテゴリーの顧客の質問などです。そのユースケースに対応するために、より多くのワークフローを作成し、メンテナンスする必要があり、もし壊れたら、これらの異なるステップをトラブルシューティングしなければなりませんでした。
モデル駆動型アプローチは、公平に言えばStrandsだけのアプローチではありません。今年はStrandsと並んで、このアプローチを支援する多くのフレームワークが登場しました。このアプローチは、すべての作業をLLMに押し込み、そしてそのLLMを異なる機能に誘導することにエネルギーを費やす場所をシフトさせます。では、これがピンと来ない場合に備えて、実践的な例を見ていきましょう。初期のChatGPTを考えてみてください。チャット体験に入ると、かなり強力なものがありました。もし私がこのシナリオにいたとして、例えばEC2のリモートインスタンスに接続できない理由をデバッグしようとしているとします。ChatGPTに入ってこれをどうやるかについて質問すると、かなり良い体験が得られました。そして、自然言語での一連の質問、基本的にはチュートリアルを得ました。異なるドキュメントを読んだり、異なるブログを読んだりするよりも良かったかもしれません。はるかに良い応答を得ましたが、まったくパーソナライズされていませんでした。これはすべて古い話だと思います、皆さんもう理解していますよね。これはエージェント以前の時代でした。質問をして、ステップが返ってきて、それが役に立ったかもしれないし、役に立たなかったかもしれません。
それで、エージェント的になったとき、ここでエージェント的というのはエージェントでツールを使用することと定義していますが、エージェントに自分の作業を考え出させる場合、例えばPythonフレームワークで、LLM呼び出しのステップを記述し、エージェントを特定の呼び出しに分解するという道を進むこともできます。そして、最初のステップとして、ネットワーク接続をチェックしましょう、と予測し、VPC APIやセキュリティグループなどを処理するツールへの直接呼び出しを行い、応答が得られるまでそのワークフローを反復していきます。これはうまく機能します。このように動作するエージェントがあっても何の問題もありません。課題は、それらのステップを記述するために多くの事前作業を行わなければならなかったということです。そして、ツールの結果を解析して、次に進む必要があるかどうかを判断しなければなりません。おそらく、次に進むかどうかをモデルに判断させるハイブリッドモードにいることに気づくかもしれませんが、それでも次のステップが何であるかを記述しているのです。
もしあなたが、ああ、ここで構築しているこのエクスペリエンスでコンテナ接続をサポートしたい、あるいはオンプレミスのコンピュートソリューションをサポートしたいと決めた場合、簡単にはできません。新しいツールを追加するだけでなく、新しいワークフローステップを追加し、それを構築したフローに組み込む必要があります。これがワークフロー駆動型エージェントの要点です。概念的には、モデル駆動型エージェントははるかにシンプルです。ゴールを与え、ツールを与える。それだけです。国際宇宙ステーションの最初の例で見ましたね。ラスベガスの天気の例もありました。これらは非常にシンプルなエージェントの例ですが、うまく機能します。そしてうまく機能するのは、Strandsのようなオーケストレーションフレームワークを使ってこれをセットアップするだけだからです。
さて、これは簡単すぎて本当とは思えないように聞こえますし、ある程度はその通りです。プロトタイプは本当に速く動かせますが、お客様とのミーティングで私が受ける一番の質問は、わかりました、でももっと良い指示を与えたいんです、ということです。ワークフローからもっと予測可能性が欲しい。もっと速くしたい、トークン使用量の面でもっとコスト効率を良くしたい。モデルが取る可能性のある危険な結果があるかもしれない。そういった危険な結果を絶対に作れないようにしたい。どうやって誘導するのか？どうやって制約するのか？
ですから、私がここで言いたいのは、これをスペクトラムとして考え、作業をどこにシフトしているか、その作業の塊がどれくらい大きいかを考えてください。ワークフロー駆動型エージェントで考えている場合、ワークフローを定義するために前もって多くの作業を行い、そのワークフローを反復し、制御はワークフローと絡み合っています。ガイダンスやステアリング、プロンプティング、ツールの使用、ツール結果の解析、これらすべてが絡み合っていて、すべてがモノリシックです。モデル駆動型アプローチは、それらすべてを忘れて、モデルに独自のワークフローを考え出す自由な裁量を与えることから始め、状況が必要とする場合に他の制御を重ねていくというものです。特定の状況に対してより細かい粒度でそれを行うことができます。では、それを分解してみましょう。
エージェント制御のスペクトラム：自律性からステアリング、制約まで
スペクトラムの左側は純粋な自律性です。モデルにゴールを与え、ツールを与えれば、それが仕事をします。この状況でのツールは実際にはシステムプロンプトです。本当に良いものにするよう努めてください。私のアドバイスは常に、ゴール指向にすることです。モデルはゴールを達成するのが大好きです。成功がどのようなものかを伝えれば、おそらくかなり良い仕事をして成功を見つけてくれるでしょう。
リサーチアシスタントはこれの良い例ですよね？モデルは必要なすべての知識を持っています。外部ソースを与えることができ、どんなフォーマットが欲しいかを伝えれば、かなり良い仕事をしてくれます。そして、Strandsの構造化出力のようなものを重ねることができます。これは、例えば欲しいマークダウンフォーマットを強制したい、あるいはフロントエンドアプリケーションに組み込めるようにJSONを出力したい、と言える仕組みです。これはワークフローやその出力がどこから来るかを考える必要なく、スペクトラムの左端で重ねることができるものです。最後に、私の抽象化フレームワークであるStrandsが構造化出力を強制し、私のスキーマに一致するまでモデルと協力して再生成しているだけです。それはすべて私のために処理され、今では欲しい出力を返すモデル駆動型アプローチができました。
さて、でももう少しガイダンスが必要な場合はどうでしょうか？ステアリングとSOPについて話すとき、先週私たちがStrandsにSOPsという新しいリポジトリをローンチしたのをご覧になったかもしれません。まだの方は、ぜひチェックしてみてください。セッションの最後にリンクを載せておきます。これは本当に、特にシステムプロンプティングのためのプロンプティング技術で、Amazon内部で開発したものです。Strandsチーム以外にも、この技術に取り組んできた非常に大きなコミュニティがあり、それを私たちはStrandsを通じて提供することにしました。このユースケースで非常に役立ちます。Nickが詳しく説明しますが、これは基本的に、プロンプトをより構造化して、エージェントに実行させたい特定のステップをプロンプトの中で提示するというアプローチです。そして、「これは必ずやらなければならない」「これはやるべきだ」といったキーワードを使うことができ、モデルはあなたのガイダンスに従いながら適応することの両方を素晴らしくこなします、よね？
そしてそれが大きなポイントなんです。なぜなら、また再びワークフロー駆動のアプローチに戻ったように聞こえるかもしれませんが、もしリモートAPIが失敗したらどうでしょう？単にLLM呼び出しをしているだけなら、ワークフローがそれに対処しなければなりませんが、モデルはリトライの方法や、プロンプトで記述したステップを達成しながら呼び出せる別のデータソースを見つけ出すことができます。それから反対側では、モデルに制約を適用する方法を考えることになります。そこでは本当に機密性の高い結果を保護しようとしています。Hooksはこれの一例で、Strands自体に含まれています。つまり、ツール呼び出しの後に検査して、結果が例えばPIIガードレールを通過したことを確認したり、特定の情報を解析したりできます。これらはすべてStrands hooksの一部として実行でき、基本的にエージェントループから抜け出して、何か作業を行い、エージェントループに戻すことができます。
これの別の例として、Strands外部のものですが、AgentCoreのgateway製品の一部として提供されているpolicy engine機能があります。これはホストされたMCPサーバーのような状況で、リモートターゲット用のMCPエンドポイントを持つことができます。これらのターゲットはAPIでもLambda関数でも構いません。これらのゲートウェイに決定論的なポリシーをアサートできるようになりました。言い換えれば、ツールが呼び出される前にデータソースを保護し、そのロジックをエージェントから外部化することで、エージェントを信頼できないものとして扱うことができます。そしてゲートウェイが決定論的なコントロールを提供します。例えば、顧客が適格と判断される前に、エージェントが返金のための特定のAPIを呼び出すことができるか、そして適格であることを示すトークンを持っているか、といったことです、よね？モデルにシステムを攻略する方法を考えさせないでください。実際に、必要な証明を提供するまで、モデルがツール呼び出しを行うことをブロックできます。
ですから、このスペクトラムに沿って考えてください。これが要するに長い話の要点です。途中にコントロールがあります。StrandsAgents.comでエージェントを構築し始めれば、私たちのウェブサイトでそれをご案内します。そして、過去数週間でローンチしたいくつかの例をお話しすることに移ります。SOPsについて言及しましたね。Nickがこれらについて詳しく説明しますが、念のため繰り返すと、これは自然言語の指示です。これらは、この場合はPythonインポート経由でも、今日TypeScriptで使えるMCPサーバー経由でも組み込むことができます。そしてフォーマットはこのようになります。上半分、これは1つのファイルではありませんが、上半分がSOPの例で、下半分がPython SDKでSOPをロードする方法の例です。
特にこれらのステップに注目してください。明らかに省略されていますが、ステップ1はセットアップステップ、ステップ2はこれ、というような見出しを付けることができ、その中にこれらのキーワード、これらのRFC 2119キーワードがあります。これらは単に標準的なキーワードで、もちろんモデルはトレーニングデータでこれらに触れています。SOPメカニズムは本当に、モデルが持っているその知識を活用しているようなもので、モデルはこれらのキーワードに非常によく従います。
これはAmazon内部で長い間実験してきたものですが、本当にこれに従うだけでいいんです。ステップを与えて、そのステップ内に制約キーワードを与えれば、モデルは良い仕事をしてくれます。
また、私たちが考えているのは、それがうまくいけば良い道に進めるわけですが、結果的に大きなプロンプトになってしまうということです。そこで私たちが実験を始めているのが、今週Python SDKの実験的機能としてリリースされたもので、私がモジュラープロンプティングと考えているものです。これをSteeringと呼んでいて、これが機能の名前です。これは重要な指示のビットを分解して、私が話し続けているライフサイクルフックにそれらを注入する方法です。このメカニズムは本当にStrandsの拡張可能なエンジンの一つで、LLMをジャッジとして使うか、決定論的なPythonライブラリを使うかを選べます。必要であればCedarを持ち込んで、エージェントの外部でそれらを使ってエージェントが取っている軌道を判断することもできます。
つまり、トレースを見て、基本的にエージェントの状態全体を渡すことができます。例えば、LLMをジャッジとするプロンプトに対して、モデルからのこのレスポンスのトーンと声がこれらのブランドガイドラインに適切かどうかを検証します。そして、イエス、ノー、そしてフィードバックのようなレスポンスを与えます。するとStrandsは基本的にエージェントループで一時停止し、それらの指示を解釈し、エージェントがそれらの指示に準拠していれば、エージェントの制御を返すだけです。そして準拠していない場合は、制御を返す際にフィードバックをエージェントに返し、エージェントはそのフィードバックを吸収し、再試行して、フックを通って戻ります。
これがSteeringの考え方で、私たちにとってかなり興味深い方向性になると思います。うまくいけば、モデルに事前に与える指示が少なくなるので、より大きなコンテキストウィンドウで作業でき、モデルが事前に過剰なステアリングデータを受け取る可能性が減り、時間の経過とともにトークン効率が向上します。そして、これをエピソード記憶システムに接続する実験も行っており、そのフィードバックループが特定のエージェントのライフサイクルで一度だけ発生し、外部フックを必要とせずに時間の経過とともにそれらの指示に従うことが上手になっていきます。
今週行ったもう一つのローンチは評価ライブラリで、これは私のエージェントの制御についての話の流れとは少し接線的に関連していますが、プロトタイピング段階を過ぎた後のライフサイクルのある時点でエージェントを評価する必要があるので、有用だと思います。そして、Strandsにはしばらくこのギャップがあり、エージェントを素早く取り出して評価器を構築するために必要なライブラリを提供していませんでした。また、Strandsベースのエージェントを使って、ユースケースに関連する合成データセットを生成し、そのデータセットを中心に評価器を構築するのに役立つ機能も追加しています。
カスタムevaluatorを使うこともできます。いくつかビルトインのものがありますし、これはお好みのオンライン評価システムと連携できるように設計されています。今週ローンチされたAgentCoreの評価システムや、皆さんが使っている他のシステムも含まれます。そして、ラップトップ上でのビルド時のストーリー、つまりSDK体験にネイティブなものと、大規模な評価を行うオンラインシステムを組み合わせることができます。
TypeScript SDK構築の挑戦：Agent SOPsでより良いコードを書く
さて、私の話はこれで終わりです。次はStrands TypeScriptについてお話しします。今週ローンチしてプレビュー版として利用可能になりましたが、いくつかの点で少し非伝統的なアプローチを取りました。Nickにその点についてお話ししてもらうのが楽しみです。まず、Strandsを使って構築しましたが、vibe codingではありませんでした。実際にはかなり繊細なアプローチで、Strandsチームとagentsチームのコラボレーション体験でもありました。それでは、Nickに登壇してもらい、どのように構築したのか、そしてこれらの機能がどのように役立ったのかについて話してもらいたいと思います。
ありがとう、Ryan。皆さん、こんにちは。今日はお越しいただきありがとうございます。私の名前はNickです。AWSのSenior Software Engineerで、TypeScript SDKの構築と開発のテクニカルリードを務めました。Ryanが言ったように、このプレゼンテーションの一環として、この新機能、Strandsのこの新しい言語を実際にどのように構築していったのかについてお話ししたいと思います。Strandsで新しい言語をサポートすることを決めたとき、私たちはその言語の構築方法について意図的に取り組みたいと考えました。Python SDKを構築した経験を振り返り、特にRyanが説明したような、数行のコードでagentを書けるという簡単な開発者体験だけに焦点を当てるのではなく、そのコードを書く開発者の体験に本当に焦点を当てたかったのです。私たちはPython用のコードを開発し書くことに多くの時間を費やしたので、その経験を振り返り、どのように改善できるかを見たかったのです。
Strands for Pythonは元々、Amazonの献身的なエンジニアグループによって書かれました。彼らは最初にプロトタイプとしてPython SDKを構築しました。彼らは開発をブートストラップし、コードをより速く書いて立ち上げ、動作するagentループを作るために、これらの初期のGen AIツールを多く使用しました。
私たちは、これらの初期のAI生成コーディングツールを使って、すべてのコードを書いてもらうために多くの時間を費やしましたが、問題は、その多くがvibe codingだったということです。これらのツールを使って出てきたコードは、あまり高品質なものではありませんでした。私は多くの時間を、私たちはエンジニアとして多くの時間を、これらのagentをレビューし、理解し、ガイドし、そして誘導して、私たちが安心して出荷でき、本番環境に持ち込んで皆さんに使っていただけるコードを書いてもらうことに費やしました。私は最近、Strands for Pythonの初期リリースを振り返って分析しましたが、約15,000行のコードでした。
TypeScriptに移行するにあたって、私たちは同様の規模のコードベースを構築することになっていました。そこで、開発者がこれらすべてのコードを書くのをどのように実際に支援できるか、意図的に考えたいと思いました。具体的には、エージェントを使ってより良く、より速くコードを書く方法を見つけ出したかったのです。そして、これを2つの部分に分けています。なぜなら、それぞれをどのように実現するかについて、興味深い解決策を思いついたからです。
より良いコードを書くために、私たちはAgent SOPsに注目しました。Ryanが先ほどこれを紹介しましたが、高レベルの概要を説明すると、これはエージェントの指示を書くための仕様です。文字通り、エージェントがいくつかのタスクを達成するために従う標準作業手順書です。Agent SOPsを使用して私たちが発見した素晴らしい点は、ある程度繰り返し可能な動作のためにエージェントを誘導するのに優れているということです。
SOPsは、私たちのプリンシパルエンジニアの一人であるJames Hoodによって最初に考案されました。彼も同様に、これらの初期のAI生成コーディングツールに不満を感じていました。彼はそれらから良いコードを書き出すために多くの時間を費やし、デバッグして良い結果を得るために多くの時間を費やしていました。その不満から、彼はこのAgent SOPsのアイデアを思いつき、それをAmazon社内のビルダーコミュニティと共有しました。それは非常に、非常に成功しました。最後に確認したときには、社内で5,000以上が作成され、あらゆる場所で使用されていました。Amazon社内の人々はこのアイデアを大変気に入っています。Ryanが言ったように、私たちはこれをStrandsの一部としてリリースしたいと考えました。なぜなら、それを共有したかったからです。エンジニアがエージェントをガイドし誘導するのを支援するために、非常に成功してきました。
これがSOPの例です。先ほどRyanと一緒に見ましたが、その仕組みについてもう少し深く掘り下げたいと思います。概要があり、パラメータがあり、そしてエージェントがタスクを完了するために従うステップのリストがあります。先ほど言ったように、これがエージェントに繰り返し可能な動作を与える理由は本当に理解しやすいです。エージェントが何らかの目標を達成するためにこれらのステップに従っているとき、エージェントが何をしているのかが本当に明白です。
これらのタスクを達成するためにエージェントを書こうとしている開発者として、このSOPは私にとってデバッグ可能であることを意味します。エージェントがこれらのステップを進んでいて、ステップ3で予期しない何かをした場合、開発者として、私はステップ3に入ってより多くの指示を与える必要があることがわかります。私たちはAmazonのいくつかのチームで、これらのエージェントのシステムプロンプトを書いていましたが、開発者たちは、システムプロンプトの作成や書き方、言葉遣いをいじると、エージェントが予期しないことをするのではないかと心配したり恐れたりしていました。
しかしSOPを使うことで、それが明確でわかりやすくなります。開発者がこれを更新しに行って、自分の変更がシステムを壊さないという確信を持つことが、はるかに簡単になるんです。後ほど、私たちがTypeScript用のエージェントの開発で実際にこれを行った様子を示すビデオをお見せします。
先ほど申し上げたように、このAgent SOPsというアイデアは、Amazon社内のビルダーコミュニティで非常に成功しました。私たちがリリースしたものの中には、prompt-driven developmentとcodesistがあります。これらは最も人気のあるSOPの2つでした。なぜなら、本当に印象的な方法でエージェントをガイドする方法を見つけ出したからです。Prompt-driven developmentは、アイデアを実装可能な状態に洗練するための質疑応答プロセスを通じて、エージェントがあなたをガイドするSOPです。
エージェントは問題を明確にするための質問をしてきます。もしあなたが尋ねていることのある側面を理解できない場合、ツールを使って調査を行いますし、もしコードベースの中にいる場合は、コードベースを探索します。そして進捗状況を記録していくので、エージェントが何を考え、何を行ったかがわかるようになっています。これの本当に良い点は、初期のGen AIコーディングツールで私たちが発見したことなんですが、エージェントは問題を解決するために可能な限り最短経路を取りたがるということです。
可能な限り最短経路というのは、必ずしも私が取ってほしい経路とは限りません。時には、私のチームが慣れている方法でコードを書くようにガイドしたいですし、エージェントが気づいていないかもしれない、私が書いた関数を使ってほしいこともあります。ですから、エージェントとのこの双方向の質疑応答プロセスを持つことで、問題を明確にすることができるんです。
これによって、エージェントが何をする必要があるかが非常に明確になり、私がやってほしいことと一致するようになります。このSOPの出力は実装可能なタスクです。コードベースに機能を実装する方法についてのマークダウンファイルなんです。
私たちはもう一つのエージェントSOPを開発しました。それがCode Assistです。これはこのタスクを受け取って実際に実装します。コードを書く際にはテスト駆動開発の手法に従っていて、まず最初にユニットテストを書いて、その後にアプリケーションコードを書きます。エージェントにこのようにコードを書かせることで、はるかに良いコードが書けることがわかりました。機能を書き終えた後、私が入って、書かれたすべてのコードを確認して、それから私が望むものとより良く合致するように更新や修正の方法についてフィードバックを与えることができます。何回か繰り返した後、私が完了したと言えば、エージェントはこのコードをコミットすることができます。
GitHubをチームメンバーに：RefinerとImplementerエージェントの実践
つまり、これら二つのエージェントSOPを一緒に使うことで、エージェントにより良いコードを書かせる方法という問題を本質的に解決したわけです。問題の二つ目の部分、つまりエージェントにより速くコードを書かせる方法については、別の興味深い方法で解決しました。私のチームの開発者は通常このような方法でソフトウェアを開発してコードを書いています。片側には開発者のチームがいて、彼らはGitHubを通じて個々の開発者とコミュニケーションを取っています。そして個々の開発者は、書いているコードの進捗を追跡するためにプルリクエストやissueを作成しているかもしれません。彼らはプルリクエストを作成して更新し、チームから得たフィードバックをローカルのIDEに調整します。おそらくCursorやCLI、Claude Codeを実行していて、そのコミュニケーションを行っています。
彼らはこのプロセスにおいて仲介者となっていて、チームによって承認されてこの変更を取り込むために、どのようなフィードバックを行う必要があるかをエージェントに伝えています。しかし、私たちはそれに多くの時間を費やしています。ローカルリポジトリをステージングしたり、ローカルのコードベースをステージングしたり、フィードバックを理解して反映して応答したり、コードのためのすべてのテストケースを書いたりしています。そこで代わりに、これをシフトしてGitHubをチームのメンバーにしたいと考えました。
私たちはGitHubのアクション機能、GitHubワークフローを活用しました。これはプルリクエストやissueの特定のイベントによってトリガーされ、Strandsエージェントをトリガーします。Ryanが言ったように、私たちはStrandsでStrandsのコードを書いています。GitHubワークフローがPythonのStrandsエージェントをトリガーして、TypeScriptリポジトリにコードをコントリビュートしています。Pythonコードが今、私たちのためにTypeScriptのコードを書いているんです。このシステムを使うことで、本質的にGitHubを通じて私たちのチームに新しいメンバーを追加しているわけです。
エージェントは私たちのチームの別のコントリビューターとして機能していて、もはや私が仲介者になる必要はありません。チームのフィードバックを理解してエージェントに渡す必要がないんです。代わりに、エージェント自身がそれを行っています。GitHubのissueやGitHubのプルリクエストを読んで、その調整を行っているので、私がする必要がありません。そしてこれが、より速くコードを書くという問題を解決した方法です。もう私は仲介者ではありません。エージェントが私のためにそれをやってくれているんです。
そこで、GitHubにおけるエージェントというこの新しいパラダイムを使って、先ほど述べたSOPであるPrompt-Driven DevelopmentとCode Assistを作り直す必要がありました。 私たちが考え出したのは、RefinerとImplementerと呼んでいるこれら2つのエージェントです。これらはPrompt-Driven DevelopmentとCode AssistのSOPをGitHub向けに調整した、わずかなバリエーションです。Refinerの動作方法は、コードベースに実装したい一般的な機能を記載したissueが与えられると、そのissueを読み、リポジトリをチェックアウトして、そのリポジトリを探索し、コードベースにその機能を実装することの影響を理解します。
そして質問のリストを作成し、それをissueにコメントとして投稿するので、私がそれを確認し、更新し、次に何をすべきか指示を与えます。このissueのコメントを通じた質問と回答のプロセスを、エージェントが実装の準備ができたと判断するまで繰り返し、そしてそのissueをImplementerエージェントに渡すことができます。ImplementerエージェントはCode Assistと同じように、実装可能なタスク、つまりissueを受け取り、GitHubにブランチを作成します。コードベースをチェックアウトし、テスト駆動開発を使ってそのコード、その機能を実装し、ブランチにコミットしてプルリクエストを作成します。
そのプルリクエストに対して、チームの他のメンバーと同じように、私はプルリクエストにフィードバックを残すことができ、エージェントはそれを読んで、コードを更新してくれます。そして今度は私が反復するだけです。ここでの本当に素晴らしい効率性は、私が座ってコードを書いてデバッグするのに30分かける必要がないということです。エージェントにそれをやらせて、私はエージェントにはできない何か他のことをすることができます。そしてこれこそが、エージェントを使ってコードをより速く書くという本当の効率性を得ているところなのです。
では、実際にこれを使ってTypeScriptリポジトリでコードを書いた例をいくつか見ていきたいと思います。 ここでは、TypeScriptコードベースに実装したいタスクの概要のissueが見えます。開発者として、私はこれをどのように進めたいか分かっています。しかし、これをエージェントに渡すと、この機能を実装するための最短経路を取ることになり、それが本質的に私たちがvibe codingと呼んでいるものです。
これを避けるために、私はslash strandsコマンドを入力してGitHub actionを起動し、refinerエージェントをトリガーします。すぐにissueにラベルが追加されて、このエージェントが実行中であることを示すのが見えるでしょう。そしてエージェントはこのissueを指示として、コードベースに配置され、 そのissueをどのように実装すべきかを探索し理解します。ここにコメントを残して、その機能をどのように実装すべきかについての明確化のための質問をします。
さて、これが実行されている間に、私は別の作業をしていて、後で戻ってきて明確化のための質問に答えることができます。では、1、2、3、4、5と、すべての質問に答えていきます。そして完了したら、再度スラッシュstrandsと入力してrefinerエージェントをトリガーすることができます。そして、タスクが実装可能になるまでこれを繰り返します。これには数分かかります。そして完了すると、再びエージェントがトリガーされます。そしてエージェントは再びコードベースに投入されます。更新された私のコメントを読むことができ、最終的にこの機能が実装可能であると判断します。そしてそのためのコメントを残します。これはすぐに表示されます。ほら、できました。
エージェントがプルリクエストにコメントで応答し、そして実装可能なタスクのためにissueの説明も更新しました。ページを更新すると、エージェントが実際にここの説明を編集したことがわかります。このrefinerエージェントを使用することで、私は本質的にエージェントが実装を開始できるようにタスクを明確化したわけです。さて、この次のビデオでは、実装エージェントをトリガーしていきます。とても簡単です。スラッシュstrands implementと入力すると、再びGitHub actionを使用して新しいエージェント、つまりimplementerをトリガーし、実装プロセスを開始します。
再度、ラベルを追加し、ブランチを作成し、そこにエージェントを投入します。そしてこのtest-driven developmentの方法論に従って私たちのコードベースでコードを書き始めます。これは約30分かかると思います。そして繰り返しになりますが、ここで効率性が発揮されます。エージェントがそれを行っている間、私は別の作業をすることができます。そこに座ってコーディングやデバッグをする必要はありません。私はただ、コードベースに入ってくるコードのレビューと品質向上を行うだけです。
ここでissueが作成されましたが、興味深い点を指摘したいと思います。これはエージェントのSOPのステアリングと改良に関することですが、実際にはエージェントはプルリクエストを作成することができませんでした。これらのエージェントを設計する際に、場合によってはエージェントがそれを行う権限を持っておらず、開発者のGitHubトークンが必要であることがわかりました。そこで、私の代わりにできるようにリンクを提供するようにという追加の指示をSOPに加えました。そしてこれが、私たちがこれらのSOPをデバッグしてきた方法です。ここで私はissue、つまりプルリクエストをクリックしました。そしてこれが、エージェントが私の代わりに作成したコードです。私はこれを一切やっていません。
では、ここで少し先に進みます。今、私はエージェントに説明を更新するよう指示しました。繰り返しますが、私はこれを一切やっていません。エージェントにやるように指示しているのです。すぐ下にコメントが表示されます。そして私は少し時間をかけて、プルリクエストにいくつかのフィードバックを残しました。エージェントにコードをどのように更新してほしいかについてです。いくつか気に入らない点がありました。discriminated unionの命名を変更したかったのです。そして再度、エージェントをトリガーします。
そして数分後には、コードを書いて、プルリクエストを更新し、コメントを残します。私たちはこのSOPを少し改良して単にコメントを残すだけでなく、私が出したプルリクエストのコメントに対して応答し、どのように実装すべきかについて洞察に富んだ回答を提供するようにしました。もし機能の実装方法について混乱している場合は、実際に実行する前に私に明確化を求めてきます。これもまた、アイデアの洗練化ですね。そしてここで見ていただけるように、私が出したコメントに対して応答し、完了しました、この機能を実装しました、完了しました、あれも実装しました、と言っています。そして上にスクロールして、実際にこの機能が実装されていることを示すためにコードも見ていきます。このシステムを使うことで、チームは本当に興奮し、コードを書くモチベーションが高まっており、多くの効率化を見出しています。これを使っているのは私だけではなく、チーム全体で使っており、多くのメンバーが本当に良い結果を得ています。
エージェントとの協働で得られた効率：最大のコード貢献者となったエージェント
このシステムをチームのプリンシパルエンジニアであるAaronに見せたところ、彼からこのようなフィードバックをもらいました。私は合計3回の短い20分のセッションで1時間を費やしただけで、コードを書くのに半日かかるところを済ませました。別の言い方をすれば、私はプリンシパルエンジニアの約4時間の時間を節約し、代わりに彼は約1時間でその機能を実装することができました。そして私は本質的にプリンシパルエンジニアの効率を4倍にしたのです。常にこれほど効率的で時間を節約できるわけではありませんが、このシステムの使い方についてますます多くの効率化を見出しています。
先ほど言ったように、ここでの本当のメリットは非同期性です。私はエージェントを起動したり、複数のエージェントを起動して複数の機能を実装させたりしながら、その間に別のことをすることができます。エージェントがまだできないようなことをです。そして通常、低から中程度の複雑さのタスクが、エージェントが取り組むのに最適なものであることがわかっています。開発者として、私は高い複雑さのものに集中し、それらを中程度および低い複雑さのタスクに分解して、エージェントに委任できるようにします。
私が本当に気に入っているグラフが次のものです。私たちは実際にエージェントがコードベースに行った貢献を追跡してきました。そしてエージェントが最大のコード貢献者であることがわかります。
私のユーザー名は右上にあります。私は約14,000行で43コミットしています。エージェントは私より少し上で、最大の貢献者です。私たちのエンジニア全員がこのシステムを使ってコードを貢献しています。しかし、エンジニアとして、私たちはまだコードを書いているということも強調したいと思います。エージェントがすべてを書いているわけではありません。なぜなら、エージェントが必ずしもできない複雑なタスクがまだあるからです。しかし、私たちはこれらのエージェントを活用する効率的で本当に良い方法を見つけており、TypeScriptの開発をスピードアップするのに役立っています。
ここで最後にいくつかお伝えしたいことがあります。私たちはエンジニアとしてコードを書く時間を減らし、それをエージェントにオフロードすることを学びました。もし私がコードベースの機能を担当するとしたら、リポジトリをチェックアウトして、実装する必要がある機能を理解するためにコンテキストスイッチングを行い、コードベースを確認して、コードを書いて、デバッグする必要があります。デバッグが終わったら、そのためのテストを書かなければなりません。そういったことに時間を費やす代わりに、それをエージェントにオフロードできるんです。
私の時間は、そのコードをレビューし、洗練させ、品質を高めることに使う方がはるかに価値があります。そして、これらのエージェントがコードを実装すべき方向性や設計について、高レベルのガイダンスを与えることです。私たちは時間を並列化する方法を見つけ出しています。コーディングとデバッグのプロセスをエージェントにオフロードして、私はエージェントができないことをやりに行けるんです。このシステムを使うことで、私たちは本質的にこれらのエージェントをチームのメンバーとして扱う方法を学びました。
以前お見せしたGitHubのフローの図を覚えていますか、私たちがGitHubにコントリビュートする図です。エージェントはチームのもう一人のメンバーなんです。TypeScriptに関しては、現在私たちのチームで最も多くのコードをコントリビュートしているのがこのエージェントで、これは本当にエキサイティングだと思います。私たちはこのシステムの開発を続けていきますので、TypeScript SDKのリポジトリで進捗を追跡できます。これが私たちがTypeScriptを構築した方法です。どのように構築したかを説明できて本当に嬉しいですし、皆さん全員に試していただけることを本当に楽しみにしています。それではRyanに戻して、締めの言葉をお願いします。
まとめ：Strandsの柔軟性と今後の展開
ありがとう、Nick。ええ、今日私たちからStrandsとは何か、そしてそれがどのように皆さんのお役に立てるかについて、たくさん学んでいただけたことを願っています。 明らかに私たちのチームはコードベースエージェントで効率を得るためにそれを使ってきました。私たちはチャット体験、データ処理パイプライン、リサーチアシスタンスを構築している顧客と協力してきました。Strandsはこれらすべてのユースケースに対して非常に柔軟で、TypeScriptでは、ブラウザやクライアントアプリケーションで実行されるアプリケーションにさらに近づくことができます。
今日触れなかったことの一つは、今週私たちはCopilot Kitの素晴らしい方々と協力したということです。彼らはStrandsのためのAGIインテグレーションを実装してくれて、それは私たちのウェブサイトでも利用可能です。QRコードはStrandsAgents.comに飛びます。また、今日お話ししたすべてのリポジトリ、SOPs、evals、そしてもちろんPythonとTypeScriptのSDKは、GitHub.com/Strands-Agentsで見つけることができます。
私はNickです。あと10分ほどここにいますので、もし質問があればお気軽にどうぞ。それから、Strandsのステッカーもいくつかご用意しています。もし今日Venetian Expo Hallに戻られる方がいらっしゃいましたら、Strandsのブースがあります。エキスポホールの中央にある大きなAWSのスクエアの中に見つけられると思います。鮮やかな赤オレンジ色のエクスカベーターが動いていて、そこにエージェントが搭載されています。つまり、Strandsがローカルコンピュート上で動作してセンサーを管理し、それがクラウドベースの環境に接続されて、産業製造のユースケースと掘削作業を行っているんです。
もしお近くにいらっしゃったら、ぜひブースを見に来てください。そこでもっとステッカーやグッズを手に入れることができますし、私たちの素晴らしいスタッフと、必要なことについて何でもお話しできます。それ以外の場合は、そうですね、NickとIのところに来てください。そして今日、私たちと一緒に時間を過ごしていただきありがとうございました。本当にありがとうございました。素晴らしかったです。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion