l セールス、サポート、オペレーションなどビジネス領域 l コーポレート (HR, Legal, Finance, PR, CorpIT, etc) l プロダクトのための活⽤ l バクラクは様々な AI エージェントサービスを提供 l Fintech 事業ではプロダクトを⽀える領域で AI エージェントを徹底活⽤ l Ai Workforce はプロダクトのコアに AI を据えた AI プラットフォーム l AgenticSec は AI エージェントによるペネトレーションテストを提供 LayerX と「AI 利活⽤」
l トレンドもどんどん変わる l ⾃由形すぎるとナレッジ共有も進まない l コストマネジメントが難しい l 使い込もうとすると従量課⾦の壁にぶちあたる l セキュリティ l 何をどう守るのか l プロダクト設計 l 課題をどう設定し、設計と実装に落とし込んでいくのか l 話題が多いので今回はお話しません🤭 推進する上での悩み
l トレンドもどんどん変わる l ⾃由形すぎるとナレッジ共有も進まない l コストマネジメントが難しい l 使い込もうとすると従量課⾦の壁にぶちあたる l セキュリティ l 何をどう守るのか l プロダクト設計 l 課題をどう設定し、設計と実装に落とし込んでいくのか l 話題が多いので今回はお話しません🤭 推進する上での悩み
AI エージェントと呼べるのか？ l AI エージェント開発に必要な要素は何なのか？ l 実際に開発するためにすべきことは何なのか？ l ⽇常的な開発‧仕事からは「とっかかり」を得ることが難しい l 議論や実装を加速するには全員の認識を揃えることが重要と考えた l 全員が AI エージェントに対するベースラインの理解を持つ状態を⽬指す l どう進めようか… l そんな時にリリースされた Amazon Bedrock AgentCore (のプレビュー) l 議論の早い海外のユースケースも取り込みながら作られている l これやん!!! 「AI エージェントづくり」の感覚を全員でつかむ
l 座学‧ハンズオン形式の講義 l AI エージェントに必要な要素 (定義, Tool/ReAct など) l AI エージェントと通常の Web アプリケーションの違い l アーキテクチャ上の違いはそこまで⼤きくない (⼤事) l AI エージェントの作り⽅ l Agent Framework, MCP, Memory, Eval などの要素 l デプロイや認証認可、セキュリティ l 社内ハッカソン l 社内ツールへの接続⽤ tool は運営側であらかじめ開発 AI エージェント祭の開催
l デプロイ需要も増加 l 外部発信の増加 l AI Agent ブログリレーを開始 l 55⽇続いた l 気になる⽅は https://tech.layerx.co.jp/ へ！ l AWS のみなさまに全⾯協⼒いただきました l 本当にありがとうございました！！！！ l 初速がついたので次のフェーズへ AI エージェント祭の効果
l トレンドもどんどん変わる l ⾃由形すぎるとナレッジ共有も進まない l コストマネジメントが難しい l 使い込むにつれて顕在化する l セキュリティ l 何をどう守るのか l 「⾃由すぎる」環境での推進と統制の両⽴は⾮常に困難 l プロダクト設計 l 課題をどう設定し、設計と実装に落とし込んでいくのか l 話題が多いので今回はお話しません🤭 推進する上での悩み
l 「まず使う」ことから始める。コストコントロールは次の段階 l 「絶対にまずい場所」を重点的に守り、他領域は⼀定のリスクを (段階的に) 受容する l お客様からお預かりしている情報は「絶対にまずい場所」の⼀つなので、 最⼤限コントロールできる場所のみで扱う l 例: 環境や規約がきちんと定められた API を、制御されたアカウントで l ソースコードなど「漏れても我々だけが泣く場所」は、⼀定のラインを設けて受容 l 会社⽅針として掲げた “Bet AI” に賭け (Bet) ることにした l 進化に対して、もたついていることが最⼤のリスク 考え⽅を決める
l アプリケーション全体を SSO 基盤を利⽤した認証プロキシで保護 l モデル利⽤も API に集約できる l 「まず使われる」スタイルを構築したうえで⾦銭投資を判断することができる l ⾃由さと統制の両⽴ l ガードレールを作り、その中で⾃由に組み⽴てられるようにする 「すぐ使えるもの」をつくる - プラットフォームの展開と開発
(開発) は2名 l アプリケーションの管理運⽤にかかる⼿間を可能な限り減らす l デプロイ先は Amazon ECS, AWS Fargate, AWS Lambda, Amazon Bedrock AgentCore l データベースが必要なものは Amazon Aurora Serverless l 検索基盤としての Amazon OpenSearch Serverless, Amazon S3 Vectors l ファイルストレージが必要なものは Amazon EFS l いわゆる「インフラ障害」に悩まされることは運⽤実績上ほぼなし l プロダクトにおける技術選定を社内基盤にも持ち込んでいる l プロダクトエンジニアとコーポレートエンジニアによる協働がしやすい ベース設計: サーバレスサービスの活⽤
CorpEn、プロダクトインフラは各事業の SRE がコードオーナー l 管理対象で分離せず、多くのものを monorepo に集めている l Terraform による AWS などのクラウド構成 l 社内アプリケーション、エージェント l IdP における権限管理 l monorepo によるメリット l シンプルに AI Coding における恩恵を受けやすい (コンテクスト集約) l 「他のアプリを読んで、同じ設計で、デプロイするアプリケーションは違うものを…」 l リポジトリにおけるポリシーの統⼀がしやすい l ⼈間の注意を集約できる l 地味に重要 集約された monorepo における管理
l 通信が AWS 内で完結する l プロダクト、社内システムが AWS に展開されており有利 l AWS IAM が使える l プロダクトごと、ユーザごとの制御が容易 l 多様なモデルがシームレスに使える l 代表的な FM に⽐べ安価なもの、性能で優位なものもある l Kimi, Gemma, Cohere などを⽤途に応じて利⽤ Amazon Bedrock の活⽤
セキュリティの⾯でも必要なガードレールを標準で付加 l 全社全職種で利⽤されている l エンジニア以外の職種のほうが利⽤頻度が⾼い l 実際の利⽤例 l 毎⽇、⾃分が参加した Slack Thread を巡回して⾃動でタスク登録 l 分析業務の事前作業などをあらかじめ実⾏しておく l GAS などのアプリ開発 l 繰り返し、共有したいものなどはアプリ化されることが増えている l 複数データソース (Slack, Notion, Google Drive など) を横断した情報収集 Shepherd のインパクト
l LLM 利⽤時の統⼀ゲートウェイとして LiteLLM を導⼊ l エンドポイントに対するプロキシとして振る舞う l バーチャルキーの概念を持ち、⼀つの認証で複数のプロバイダに対応 l Amazon Bedrock, OpenAI Platform など l コスト計算と上限 (Budget) の設定が可能 l 複数エンドポイントを合算できる LLM ゲートウェイ (LiteLLM)
による処理 l ツールを実⾏し、結果を待つ l ⼈間による判断を待つ l etc… l 処理が中断されたり、再開されるようなことも多い l 従来のように「プログラムを実⾏したまま」待つにはコストが⾼い l エージェントの動きをワークフローのように捉え、確実に完了するための基盤が必要 エージェントを動かす環境の課題
これまで AWS Step Functions + AWS Lambda などが必要だった部分 l AI エージェントを開発するうえでも、フルセットが必要なく、ワークフローに落とし込みやすいケ ースが多く存在する l Amazon Bedrock AgentCore を内部的に呼び出すといった形でも使える l HITL を含む Agentic な処理を実装するために利⽤ l AWS ビルトインであり、インフラ管理不要かつ Lambda Function の開発ノウハウが使えることも 良いポイント l 主に社内システム向けに利⽤ AWS Lambda Durable Functions
コントロールプレーンはマネージド l AWS Lambda Durable Functions に近いが、ワーカーのセルフホストやリトライ時の挙動、 デバッグに必要な機能などに差異がある l Vercel AI SDK と統合されており TypeScript で書ける l バクラクに統合するような機能で利⽤ Temporal Workflow
1つの記⼊のために30分〜多いもので数時間かかる l 各社独⾃フォーマットが存在 l 主に Excel を使った多様なフォーマット l 統⼀のためのサービスやシートも存在するが、リスク評価のための 着眼点が各社異なるため、簡単な統⼀は困難 l セキュリティ担当が記⼊を⾏う l プロダクト仕様に関するものなど広いカバレッジが求められる l より広く多くのお客様にサービスをお使いいただくためにも、素早い対応が必要 セキュリティチェックシートエージェント
l 技術的に⾒たときに、AI エージェントそのものの技術要素は、突拍⼦もないものではない l 実⾏環境、ワークフロー、フィードバックと評価、etc… l まず⼿を動かしてみて作り、ユースケースを設計に変換する感覚を養うことが重要 l エージェントネイティブな業務プロセスへの再設計をしていく l つまり、実際にやるべきことはこれまでに培ってきたプロダクト開発に近い l 課題を知り、定義し、ものをつくり、届け、フィードバックを得て、改善する l AWS にはだいたい必要なものは揃っており、あとは選択の問題 振り返ってみての学び
kanny
nwiizo
ks91
sugupoko
nealle
fullkaiten
murabayashi
eller86
freshdaz
appleboy
odan611
iotcomjpadmin
nari_ex
tenderlove
aleyda
3n
letsgokoyo
wjessup
axbom
addyosmani
jcasabona
vanstee
mayatellez
rasagy
matthewcrist
