マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20250922
内容紹介
Server Less Code Moreキーノートレポート【ServerlessDays 2025】、AI エージェントのための Agent Payments Protocol (AP2) を試してみた、If you are good at code review, you will be good at using AI agents、航空管制のシステム開発してるときに、「手なりで作っちゃいそうになるけど、ダミー便でJAL123だけは作るなよ」と口酸っぱく言われた新卒時代の思い出→「実際にJALがやらかして怒られてる」「123とかつい作りそうになる」
出演者
関連リンク
この記事は、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つが特に重要だと強調されています。
- 関数単位での設計: アプリケーションの各機能を独立した「関数」として設計し、どんな環境でも動かせるようにしておくこと。
- ステートレス: 処理が実行されるコンピューター自体にデータ（状態）を保存せず、データはデータベースなどの外部に保存すること。これにより、処理をスケールしやすくなります。
- イベントドリブン: 何か特定の「イベント」（例えば、ファイルがアップロードされた、ユーザーがボタンを押したなど）をきっかけに処理が自動的に始まるようにすること。 これらの原則は、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エージェントがどんどん普及していますね。例えば、旅行の計画を立てたり、カレンダーの空き時間を確認してスケジュールを調整したりと、とても便利です。しかし、宿泊施設の予約やフライトの購入といった、お金のやり取りを伴う「決済」に関しては、セキュリティや信頼性の問題から、まだ人間自身が行うのが一般的です。もしAIエージェントが勝手に決済をしてしまったら、不正な請求や詐欺のリスクが心配になりますよね。
このような課題を解決するため、Googleが「Agent Payments Protocol (AP2)」という新しい技術のルールを提案しました。これは、AIエージェントが私たちに代わって安全に決済を行うことを可能にするためのプロトコル（通信規約）です。AP2は、既存のAIエージェント間の通信プロトコル（Model Context ProtocolやA2Aなど）を拡張して利用できます。
AP2の核となる仕組みは「Mandates（マンデート）」と呼ばれる、改ざん防止機能付きの暗号化されたデジタル契約です。これにより、エージェントがユーザーに代わって信頼性高く支払いを行えるようになります。Mandatesには主に2つの利用シーンがあります。
- リアルタイム購入（人間が指示を出している場合）: ユーザーが「新しいランニングシューズを探して」のように直接エージェントに指示を出すケースです。ユーザーの購入意図を記録した「Intent Mandate」が生成され、エージェントが商品を見つけてカートに入れたら、ユーザーが確認・承認することで「Cart Mandate」に署名されます。
- 委任タスク（人間が直接見ていない場合）: ユーザーが「コンサートチケットが発売されたらすぐに買って」のように、事前にタスクをエージェントに任せるケースです。この場合、ユーザーは事前に詳細な条件を記述したIntent Mandateに署名しておきます。エージェントは、その条件が満たされたときに自動でCart Mandateを生成し、購入を進めます。これにより、人間がその場にいなくても、設定されたルールに基づいて安全な決済が可能です。
AP2はまだ提案段階で、これから広く使われるようになることが期待されています。記事では、AP2の仕組みを実際に体験できるサンプルコードが紹介されていました。このサンプルでは、ショッピングエージェントがユーザーの指示を受けて商品を探し、販売者エージェントと連携してカートを作成し、ユーザーが支払い方法を選んで最終的に購入を確定するまでの流れが示されていました。これにより、AIエージェントが様々な専門エージェントと協力し、安全かつスムーズに決済プロセスを完結できる未来が見えてきます。
新人エンジニアの皆さんにとって、AIエージェントが単なる情報検索だけでなく、実社会の「お金のやり取り」にまで踏み込むための重要な技術基盤として、AP2がどのように信頼とセキュリティを確保しようとしているのかを知る良い機会になるでしょう。将来的に皆さんが開発するAIサービスにも、このような安全な決済機能が必要になるかもしれませんね。
引用元: https://azukiazusa.dev/blog/trying-agent-payments-protocol-ap2
AIエージェントを効果的に活用するには、コードレビューのスキルが非常に重要である、という主題について解説しています。特に、新人エンジニアの方にとって、AIとどう向き合うべきか、そのヒントになるでしょう。
記事では、AI（大規模言語モデル）は大量のコードを素早く生成する能力は高いものの、ソフトウェアエンジニアのような深い判断力はまだ持っていないと指摘しています。そのため、AIに任せっぱなしにすると、効率が悪かったり、後で手戻りが発生したりするような「良くない設計」に固執してしまうことがあるそうです。
具体的な例として、オフラインで使える植物図鑑アプリ開発の際、AIがデータの取得方法で遠回りをしようとしたケースや、シンプルな並行処理タスクなのに、AIが過剰に複雑なバックグラウンドジョブの仕組みを提案したケースが挙げられています。このように、AIは「熱心だけど、まだ経験の浅いジュニアエンジニア」のように振る舞うため、人間が定期的に軌道修正してあげる必要があるのです。
では、どんなコードレビューのスキルが役立つのでしょうか？ 記事では、「書かれたコード」だけを見るのではなく、「もっと良い設計や実装はなかったか」という「構造的な視点」を持つことが重要だと述べています。これは、コードの細かな修正点を探すだけでなく、そもそもその機能がどこに、どう実装されるべきかを考える、より大きな視点でのレビューを指します。例えば、既存のシステムを再利用できないか、もっとシンプルな方法はないか、といった問いかけが、AIを正しい方向に導く鍵となります。
反対に、コードの表記揺れや命名規則といった細部にこだわりすぎる「あら探し型」のレビューや、AIが作ったものをそのまま鵜呑みにしてしまう「何でも承認型」のレビューは、AIエージェントとの協業には向いていません。前者はAIの大きな設計ミスを見逃しがちで、後者はAIの誤った判断をそのままコードベースに取り込んでしまうリスクがあるからです。
結論として、AIエージェントの利用は、人間とコンピュータが協力する「セントール・チェス」に似ていると述べられています。つまり、AIが生成したコードや設計案が適切かどうかを評価する、人間の「コードレビュー力」、特に「構造的な思考力」が、AIツールを最大限に活かすために不可欠だということです。AIを単なる道具として使うのではなく、パートナーとして上手に導くことが、今後のエンジニアには求められるでしょう。
引用元: https://www.seangoedecke.com/ai-agents-and-code-review/
航空管制システム開発現場では、1985年の日航機墜落事故の教訓から「JAL123」をダミー便に使わないよう徹底されます。これは連番として選びがちですが、実際にJAL社がテストで「JAL123」を使い問題になった事例も。新人エンジニアの皆さんは、テストデータを選ぶ際、安易な連番が歴史的背景や社会に配慮を欠くことがあると心に留めましょう。過去の教訓から学び、影響を意識した開発が重要です。
引用元: https://posfie.com/@petaritape/p/s5Kj5VU
VOICEVOX:春日部つむぎ