Slide 1

Slide 1 text

⽣成 AI‧AI Agent 最新動向 3つの Frontier Agents を紹介 2025/12/17 佐藤智樹

Slide 2

Slide 2 text

⾃⼰紹介 3 ● 2016年 某SIerにて基幹システム開発従事 ● 2020年 ⼊社 バックエンドエンジニア ○ IoT宅配ボックス、⼯場IoTなどIoTシステムの バックエンド、インフラ構築に従事 ● 2023年 マネージャー ○ 部署内全体技術⼒向上のため施策実施 ● 2025年 テクニカルマネージャー ○ AI駆動開発など⽣成AIを活⽤した⽣産性向上を ⽬的として活動 ● 部署 ○ 製造ビジネステクノロジー部 ● 名前 ○ 佐藤智樹 ● 役割 ○ テクニカルマネージャー @tmk2154 @tomoki10 @tomoki10

Slide 3

Slide 3 text

re:Inventで発表された以下のサービスを紹介します! ● DevOps Agent ● Security Agent ● Kiro Autonomous Agent 最後に簡単な宣伝 ⽬次 4

Slide 4

Slide 4 text

Frontier Agents とは 5 https://aws.amazon.com/jp/ai/frontier-agents/

Slide 5

Slide 5 text

アラームやチケットシステムと統合することで、インシデント発⽣時に ⾃律的に障害原因の調査や障害への対処⽅法を提案する運⽤サポートAIエージェント DevOps Agent とは 6

Slide 6

Slide 6 text

⼈間かアラートやチケットをトリガーとして、⾃動でAWS環境や接続先の外部環境を 調査し、修正内容を提案、コマンドやIaCの修正も提案 具体的なフロー 1. ⼈間かアラートやチケットなどインシデントを契機にDevOps Agentが実⾏ 2. DevOps Agent が AWS環境を調査 GitHubやMCPを繋ぐことで外部の変更(IaCなど)も調査可能 3. 調査結果からインシデントの原因を報告 4. インシデントへの対応策を提案 基本はCLIベースでの修正、ほかにIaCの修正も提案可能※ DevOps Agent の具体的な機能 7 ※https://dev.classmethod.jp/articles/awsreinvent-devops-agent-cdk-miss-config/

Slide 7

Slide 7 text

ここからは現地のワークショップで試した例を紹介 例:DynamoDB の Write Capacity Units が 250→2に突然変更された場合 DevOps Agent の画⾯(TOP) 8

Slide 8

Slide 8 text

DevOps Agent の画⾯(アラートの発⽣) 9

Slide 9

Slide 9 text

DevOps Agent の画⾯(TOPから調査を依頼) 10 ※Webhookで⾃動トリガーも可能 https://dev.classmethod.jp/articles/aws-devops-agent-cloudwatch-automated-incident-investigation/

Slide 10

Slide 10 text

DevOps Agent の画⾯(設計情報の把握) 11

Slide 11

Slide 11 text

DevOps Agent の画⾯(調査報告) 12

Slide 12

Slide 12 text

DevOps Agent の画⾯(調査報告) 13

Slide 13

Slide 13 text

DevOps Agent の画⾯(解決策への移動) 14

Slide 14

Slide 14 text

DevOps Agent の画⾯(Step by Stepで解決策を提案) 15

Slide 15

Slide 15 text

DevOps Agent の画⾯(Step by Stepで解決策を提案) 16

Slide 16

Slide 16 text

DevOps Agent の画⾯(Rollbackプランも提案) 17

Slide 17

Slide 17 text

利点 ● インシデント発⽣時に、問題の原因特定が容易になる ○ インシデント発⽣して、⼈間がアラートを⾒る頃には既に根本原因が特定され ているかも !? ● AWSアカウントに閉じず、GitHubやMCPなど接続先を追加することで外部環境の 情報も活かしたインシデント調査が可能 ● 段階的なインシデント調査に加えて、Rollback プランも提案可能 ○ シニアとジュニアの間にある障害対応に必要な知識を埋めやすくなる !? 注意点 ● 障害対応まで完全⾃動化すると2次被害が発⽣する可能性もあるので注意 DevOps Agent のまとめ 18

Slide 18

Slide 18 text

設計、実装、テストなど開発ライフサイクル全体を通じてアプリケーションを 積極的に保護するセキュリティ特化型AIエージェント Security Agent とは 19

Slide 19

Slide 19 text

設計からデプロイまでソフトウェア開発の全体でセキュリティチェックを⾏う エージェント機能を展開 以下の機能を管理側と利⽤側に別れて設定し使⽤ ● 実装前に設計書をレビュー ○ 事前に定義したセキュリティ要件に応じて設計書をレビュー ● プルリクエストのコードを分析 ○ ⼀般的な脆弱性を含むかプルリクエストを⾃動的にレビュー 事前定義したセキュリティ要件への準拠も確認 ● アプリケーションのペネトレーションテスト ○ アプリのエンドポイントにエージェントが⾃動アクセスし、脆弱性を確認 Security Agent とは 20

Slide 20

Slide 20 text

事前定義したセキュリティ要件に応じて設計書をレビュー 事前定義には2種類ある ● マネージドセキュリティ要件 ○ 以下10種類の観点で設計書に問題がないかレビュー(ON/OFF可能) ■ 監査ログ、認証/認可、情報保護、ログ保全、特権アクセス シークレット保護、デフォルトセキュア、テナント分離、暗号化 ● カスタムセキュリティ要件 ○ 上記のマネージドセキュリティ要件をカスタマイズ、あるいは完全に新規で 独⾃のシステム要件に合わせたセキュリティ要件を作成し適⽤ Security Agent:設計書レビュー 21

Slide 21

Slide 21 text

Audit Logging Best Practicesの場合 - 適⽤対象 機密データを閲覧したり、重要なアクションを実⾏できるユーザーがいるシステムに適⽤されます。 - 説明 システムがセキュリティ監視をサポートすることを確保します。 - コンプライアンス要件 準拠したシステムは、セキュリティ監視とインシデント調査のために、適切な詳細レベルでシステムの変 更、アクセス試⾏、ユーザーアクティビティを記録するログを⽣成する必要があります。 コンプライアンスの評価を⽀援するために、どのイベントがログに記録されるか、各イベントでどのような 情報が取得されるか、ログの完全性がどのように維持されるかを説明する⽂書を⽤意する必要があります。 セキュリティ上重要なイベントのログ記録に失敗した場合、ログエントリから必須の詳細情報が⽋落してい る場合、または調査を妨げるようなログカバレッジの⽋落がある場合、システムは明らかに⾮準拠です。 マネージドセキュリティの例(⽇本語訳) 22

Slide 22

Slide 22 text

Security Agent 設計書レビューの使⽤イメージ 23 ※現状は次の拡張子のみ( DOC, DOCX, JPEG, MD, PDF, PNG and TXT) Security Agent セキュリティ 管理者 マネージドセキュリティ 要件 カスタムセキュリティ 要件 設計書※ 有効/無効化 追加設定 設定 管理側 開発側 Security Agent (WebApp) 開発者 準備 アップ ロード 検査結果

Slide 23

Slide 23 text

エージェント スペースA 取得 Security Agent コードレビューの使⽤イメージ 24 Security Agent セキュリティ 管理者 実装 接続設定と 対象リポジトリの設定 管理側 開発側 開発者 作成 Push & Pull Request 作成 GitHub App App作成 GitHub Security Agent レビュー結果 コメント リポジトリ紐付け エージェント スペースA

Slide 24

Slide 24 text

以下を設定(‧はオプション)  ○URLエンドポイント  ‧攻撃⽅法の詳細  ‧修正PRの作成許可  ‧認証情報の設定  ‧アプリ詳細情報の追加 以下を設定(‧はオプション)  ○対象ドメイン  ‧VPC  ‧シークレット  ‧Lambda  ‧S3バケット  ‧AWSサービスアクセス⽤ロール Security Agent ペネトレーションテストの使⽤イメージ 25 Security Agent セキュリティ 管理者 管理側 開発側 開発者 Security Agent (WebApp) ALB API Gateway Endpoint ⾃動 リクエスト エージェント スペースA 設定 エージェント スペースA

Slide 25

Slide 25 text

実⾏画⾯(ペネトレーションテスト設定) 26

Slide 26

Slide 26 text

● Arbitrary File Upload(任意ファイルアップロード) ● Code Injection(コードインジェクション) ● Command Injection(コマンドインジェクション) ● Cross-Site Scripting (XSS)(クロスサイトスクリプティング) ● Insecure Direct Object Reference(安全でない直接オブジェクト参照) ● JSON Web Token Vulnerabilities(JSON Webトークンの脆弱性) ● Local File Inclusion(ローカルファイルインクルージョン) ● Path Traversal(パストラバーサル) ● Privilege Escalation(権限昇格) ● Server-Side Request Forgery (SSRF) (サーバーサイドリクエストフォージェリ) ● Server-Side Template Injection (サーバーサイドテンプレートインジェクション) ● SQL Injection(SQLインジェクション) ● XML External Entity(XML外部エンティティ) 実⾏画⾯(開発側:ペネトレーションテスト設定) 27

Slide 27

Slide 27 text

詳細はこちら 28 https://dev.classmethod.jp/articles/introducing-aws-security-agent/

Slide 28

Slide 28 text

利点 ● 設計レビュー、コードレビュー、ペネトレーションテストが⾃動となり セキュリティのシフトレフトが加速!より早い段階でセキュリティ問題に対処可能 ● 外部依頼していたペネトレーションテストが⾃社内の⼈員で解決できる !? ○ 精度に関してはまだこれからなので未来の話 ○ 本格的なペネトレーションテストの前に、バグを減らせる ● CI上から実⾏できれば、開発のライフサイクルの途中に 毎回ペネトレーションテストも可能になってくる !?(値段によりけり…) 注意点 ● 探索的なエージェントの振る舞いをどこまで信⽤するかはまだ注視が必要 ● ペネトレテストには攻撃的なリクエストもあり、検証環境での実施が推奨 Security Agent のまとめ 29

Slide 29

Slide 29 text

開発タスクをローカル環境から独⽴された環境で実⾏。コンテキストを維持して タスクの中から学習するソフトウェアエンジニアのAIエージェント Kiro Autonomous Agent とは 30

Slide 30

Slide 30 text

従来との⽐較(実⾏環境) 31 従来のエージェント型 IDE/CLI Kiro Autonomous Agent ローカル端末 ローカル端末上で指示し ローカル端末上でタスク実行 ローカル端末 実⾏環境 実⾏環境 ローカル端末上で指示し 外部のサンドボックス上でタスク実行

Slide 31

Slide 31 text

従来との⽐較(ツールとのコラボレーション) 32 従来のエージェント型 IDE/CLI Kiro Autonomous Agent ローカル端末 IDE/CLI上でタスクを指示 AI向けに仕様の入力が必要 ローカル端末 実⾏環境 実⾏環境 SlackやJiraなどからもタスク指示が可能 コミュニケーションツールが活用可能

Slide 32

Slide 32 text

Kiro Autonomous Agent が実装する際の流れ(例) 33 ①指示 ローカル端末 実⾏環境 実⾏環境 Pull Request Pull Request ユーザー ユーザー ②実装 ③レビュー

Slide 33

Slide 33 text

● ローカルPCのリソースに依存せず⾮同期で並列実⾏が可能 ○ 複数作業を並列実⾏することでより作業の効率化が可能 ※並列依頼可能な作業の⾒極めには注意 ● 独⾃のメモリにリポジトリやコードレビューから学習した内容を保持し、セッ ションが変わってもPJに関連する情報を維持 ● タスクボードやSlackから指⽰が可能で、同僚と仕事する時のタスク管理の仕組 みをそのまま使える ● 複数リポジトリにまたがる処理(Pythonのランタイムバージョンアップデート など)を⼀気に依頼可能 Kiro Autonomous Agent の期待される効果 34

Slide 34

Slide 34 text

おさらい:AIコーディングエージェントの構造 35 基本以下の4つで構成される ● Profile … 役割など ● Memory … 保持する情報 ● Planning … 実⾏の計画 ● Action … 作業の実⾏ KiroはMemoryの部分で ユーザーからの指⽰やリポジトリ特 有の情報を維持する仕組みを構築

Slide 35

Slide 35 text

● パターン1 ○ Kiro Pro、Pro+、Powerをサブスクライブ ○ プレビュー版がリリースされるまで待つ(登壇者もまだ来てない…) ● パターン2 ○ チーム利⽤のためのWaiting Listに登録 ■ https://pages.awscloud.com/Kiro-autonomous-agent-contact.html ○ 連絡を待つ ○ IAM Identity Center経由でPro、Pro+、Powerをサブスクライブ Kiro Autonomous Agent を使い始めるには 36 詳細は以下! https://kiro.dev/blog/introducing-kiro-autonomous-agent/

Slide 36

Slide 36 text

Kiro Autonomous Agent に個⼈的に期待する部分 主にエンタープライズ向けには今後以下が期待 ● ネットワークアクセス制御機能で、三段階の設定が可能 ほかにもドメインをホワイトリストに追加可能 ● サンドボックス: (接続したGitHubリポジトリとの接続のみ) ● ライブラリ/パッケージの依存関係のあるもののみ許可: (npm、PyPI、Mavenなどのパッケージレジストリへのアクセス) ● すべてのインターネットアクセスを許可   → 環境分離がAWS内部の仕組みで簡単に可能 ‼ ● 請求を「AWSの請求」に紐づけて管理可能 ‼ 37

Slide 37

Slide 37 text

● Frontier Agentsの3つを紹介 ○ DevOps Agent ■ インシデントの⾃動調査や修正⽅法を提案 ■ GitHubやMCPによって外部に接続して追加調査も可能 ○ Security Agent ■ 設計レビュー、開発レビュー、ペネトレーションテストを実⾏ ■ 開発のライフサイクル全体で脆弱性検査が可能 ○ Kiro Autonomous Agent ■ Kiroからローカルと別の環境でコーディングタスクを実⾏ ■ コメントやリポジトリから⾃律的に学習し、知識を拡張 Frontier Agents まとめ 38

Slide 38

Slide 38 text

現在はソフトウェアエンジニアの役割を補助するAIエージェントが複数登場してい る。これは開発者がソフトウェアエンジニアというドメインをよく理解しているの で、補助する機能がうまく実装できている ● DevOps Agent:運⽤改善⽀援 ● Security Agent:セキュリティ対応⽀援 ● Kiro Autonomous Agent:実装⽀援 今後は個別のドメインに特化したエージェントも登場していく !? ● 品質管理‧異常検知Agent !? ● 予知保全‧メンテナンスAgent !? → 各業界の専⾨家が⾃らのドメインに特化したAIエージェントを構築する時代に 個⼈的な考察 39

Slide 39

Slide 39 text

宣伝:企業でのAI駆動開発のご⽀援もやってます! 40 https://classmethod.jp/news/20250725-anthropic/ https://classmethod.jp/services/aidd/

Slide 40

Slide 40 text

個⼈的な宣伝:AI駆動開発の書籍がでます 41 https://www.amazon.co.jp/dp/4296071319