マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20250922

関連リンク

• Server Less Code Moreキーノートレポート【ServerlessDays 2025】

この記事は、ServerlessDays 2025のキーノート「Server Less Code More」のレポートで、AIエージェントをサーバーレス環境で開発する際の重要な考え方を、新人エンジニアにも分かりやすく解説しています。

まず、大規模言語モデル（LLM）が大きく進化した転換点として、Claude 3.5 Sonnetと「ToolUse」の登場が挙げられます。ToolUseのおかげで、AIがファイルを読み書きするなど外部のツールと連携できるようになり、これによりAIが自律的にコードを書く「コーディングエージェント」の原型が生まれました。この進化が、AIエージェント開発の可能性を大きく広げたのです。

次に、サーバーレスとAIの組み合わせについてです。Amazon BedrockのようなAIサービスと、スマートフォンのアプリのようなネイティブアプリケーションを直接組み合わせることで、「これこそサーバーレス」と言えるような非常にシンプルな構成が実現できると示されました。従来の、API GatewayとLambdaを必ず使うという固定概念にとらわれず、よりシンプルにサービスを構築できる選択肢があることを示唆しています。 また、サーバーレス開発における普遍的なデザイン原則として、以下の3つが特に重要だと強調されています。

1. 関数単位での設計: アプリケーションの各機能を独立した「関数」として設計し、どんな環境でも動かせるようにしておくこと。
2. ステートレス: 処理が実行されるコンピューター自体にデータ（状態）を保存せず、データはデータベースなどの外部に保存すること。これにより、処理をスケールしやすくなります。
3. イベントドリブン: 何か特定の「イベント」（例えば、ファイルがアップロードされた、ユーザーがボタンを押したなど）をきっかけに処理が自動的に始まるようにすること。 これらの原則は、AIエージェントの開発においても非常に重要だと述べられています。

LLM単体には、「最新の情報に詳しくない（ナレッジカットオフ）」「外部のシステムを直接操作できない」「以前の会話内容を覚えていない（ステートレス）」といった制約があります。これらの弱点を克服するためには、アプリケーション側で「コンテキストの注入」が必要です。具体的には、AIに目的や役割を指示する「システムプロンプト」、過去の会話履歴を管理して渡す仕組み、そして外部のデータベースやドキュメントを参照してAIの知識を補う「RAG（Retrieval Augmented Generation）」といった技術が活用されます。 しかし、これらの工夫だけではAIの自律的な行動には限界があり、そこで「AIエージェント」が必要になります。

キーノートの重要なメッセージの一つは、「AIエージェントはアプリケーションである」ということです。これは、AIエージェントが全く新しい特別なものではなく、これまでのソフトウェア開発の延長線上にあるものとして捉えるべきだという意味です。AIエージェントは、LLMが「次に何をすべきか思考」し、その思考に基づいて適切な「ツールを実行」し、その実行結果を受けて再び「思考」するというループを繰り返して動作します。 大規模なAIエージェントを開発する際には、シンプルなエージェントでは気にしなかったような、認証・認可（誰が何を使えるか）、メモリ管理（会話履歴などの情報の効率的な管理）、監視（オブザーバビリティ）、エラーハンドリングといった、従来のアプリケーション開発で複雑になる要素も考慮する必要があります。

これらの大規模エージェント開発の課題に対し、AWS上でのStrands Agents SDKを活用した解決策も提示されています。例えば、ステートレスなLambda環境で会話履歴を継続的に保持するためには、DynamoDBなどの外部ストレージに状態を保存することが必須です。また、エージェントの主要なロジックや、LLMが使う各ツールは、再利用しやすいように独立した関数として設計することが推奨されます。最終的なAIエージェントのアーキテクチャは、従来のサーバーレス構成にBedrockなどのLLMサービスが加わる形となり、ここでもサーバーレスの3原則である「関数単位」「ステートレス」「イベントドリブン」が、設計の本質的な指針となります。

このレポートは、生成AIが当たり前になった時代においても、普遍的なサーバーレスのデザイン原則が引き続き重要であり、業務上の課題をAIエージェントの機能として具体的に落とし込む力と、それを実現するソフトウェアを構築する力が、これからのエンジニアに求められることを強調しています。

引用元: https://qiita.com/har1101/items/49745c0a15b0b1f8d6ea

• AI エージェントのための Agent Payments Protocol (AP2) を試してみた

最近、私たちの代わりに様々な作業を行ってくれるAIエージェントがどんどん普及していますね。例えば、旅行の計画を立てたり、カレンダーの空き時間を確認してスケジュールを調整したりと、とても便利です。しかし、宿泊施設の予約やフライトの購入といった、お金のやり取りを伴う「決済」に関しては、セキュリティや信頼性の問題から、まだ人間自身が行うのが一般的です。もしAIエージェントが勝手に決済をしてしまったら、不正な請求や詐欺のリスクが心配になりますよね。

このような課題を解決するため、Googleが「Agent Payments Protocol (AP2)」という新しい技術のルールを提案しました。これは、AIエージェントが私たちに代わって安全に決済を行うことを可能にするためのプロトコル（通信規約）です。AP2は、既存のAIエージェント間の通信プロトコル（Model Context ProtocolやA2Aなど）を拡張して利用できます。

AP2の核となる仕組みは「Mandates（マンデート）」と呼ばれる、改ざん防止機能付きの暗号化されたデジタル契約です。これにより、エージェントがユーザーに代わって信頼性高く支払いを行えるようになります。Mandatesには主に2つの利用シーンがあります。

1. リアルタイム購入（人間が指示を出している場合）: ユーザーが「新しいランニングシューズを探して」のように直接エージェントに指示を出すケースです。ユーザーの購入意図を記録した「Intent Mandate」が生成され、エージェントが商品を見つけてカートに入れたら、ユーザーが確認・承認することで「Cart Mandate」に署名されます。
2. 委任タスク（人間が直接見ていない場合）: ユーザーが「コンサートチケットが発売されたらすぐに買って」のように、事前にタスクをエージェントに任せるケースです。この場合、ユーザーは事前に詳細な条件を記述したIntent Mandateに署名しておきます。エージェントは、その条件が満たされたときに自動でCart Mandateを生成し、購入を進めます。これにより、人間がその場にいなくても、設定されたルールに基づいて安全な決済が可能です。

AP2はまだ提案段階で、これから広く使われるようになることが期待されています。記事では、AP2の仕組みを実際に体験できるサンプルコードが紹介されていました。このサンプルでは、ショッピングエージェントがユーザーの指示を受けて商品を探し、販売者エージェントと連携してカートを作成し、ユーザーが支払い方法を選んで最終的に購入を確定するまでの流れが示されていました。これにより、AIエージェントが様々な専門エージェントと協力し、安全かつスムーズに決済プロセスを完結できる未来が見えてきます。

新人エンジニアの皆さんにとって、AIエージェントが単なる情報検索だけでなく、実社会の「お金のやり取り」にまで踏み込むための重要な技術基盤として、AP2がどのように信頼とセキュリティを確保しようとしているのかを知る良い機会になるでしょう。将来的に皆さんが開発するAIサービスにも、このような安全な決済機能が必要になるかもしれませんね。

引用元: https://azukiazusa.dev/blog/trying-agent-payments-protocol-ap2

• If you are good at code review, you will be good at using AI agents

AI