DevelopersIO 2025 Osaka #devio2025

DevelopersIO 2025 Osaka #devio2025 - connpass

NetApp様からのドリンク提供！

午後休んできましたが、まだ昼なのでビールは我慢してレッドブル。

セッション

Session-B-5 システムの運用監視の効率をAIを使って上げる

やまとさん

AIを調査に活用している
現場の課題：24/365運用監視のリアル
- 原因特定までの時間、並行作業の危険性
AIによる解決策
- AWS CLIで調査可能ならAIエージェントであたりをつけられるのでは？
- 調査の初動をAIにまかせて作業時間の効率化
具体的な工夫
- プロンプトに「いつのリソースのどの設定がどんなふうに異常で原因が何か様々なアプローチで調査してください」と5W1Hで基地の情報を詳細に記載
- Claude Codeでルールファイル指定
  - CLAUDE.mdに禁止の方針、要件など記載
- AIの勝手な実行を防ぐための「安全性」にこだわる
  - ReadOnlyロール、一部のアクション（Describe,Get,List）などのみ許可
  - 実行ログは取得して記録してトレース可能に
- 調査結果を次のアクションにつなげて更に効率化
大事なこと
- AIは補助的なツール、最終的な判断と責任は人にある
導入効果
- 調査時間が２時間から1時間ぐらいに
- 属人化解消と標準化、初動を任せれる
  - 根本改善に注力する時間が作れた

今後AIでの調査はめっちゃ増えそう。これはいいエージェント活用だしやってみたい。

Session-A-04 Snowflakeの生成AI機能を活用したデータ分析アプリの作成〜Cortex AnalystとCortex Searchの活用とStreamlitアプリでの利用〜

鈴木那由太さん

まとめ
- 生成AIでエンジニアへ分析を依頼するリードタイムが減る
- Snowflakeの生成AI分析はStreamlitでインターフェイス提供できる
- SQL生成は複雑なためDBも分析しやすい形にしておくことが重要
  - データカタログも重要で、いままでの仕組みの延長にある
生成AIで変わるデータ分析
- 自然言語から、SQL生成、可視化、分析レポートを作ってくれる
- AWSなら Amazon Q generative SQL など
嬉しいこと
- SQL考える負荷（正しいクエリの作成の調査）
- エンジニアへ依頼するオーバーヘッドが減るのが特にいい
  - アナリストからエンジニアへの依頼は数日待たせてしまうことが多々あるが、生成AIつかえばざっくり分析がすぐにできたりする
自然言語による分析の深堀り
- 動的にSQL作る場合はDDLをプロンプトに含める
  - メタデータやリレーションも含めて精度をあげる
- Cortex Analystの仕組みを参考にする
  - テーブル10個、カラムは50個まで

Snowflake にStreamlitのUI被せて、エンジニアに依頼しなくてもアナリストが直接自然言語でSQLを取り出すなど
Streamlitはほんと手軽でウェブUI作れるのが良い#devio2025 pic.twitter.com/rG0BzYhvtV
— おむろん (@omuron) 2025年9月3日

Session-B-7 IoT x エッジAI：リアルタイムAI活用のPoCを今すぐ始める方法

新澤忠士さん

製造業でのエッジAIの現状
- 機械学習によるパターン認識が主流
エッジAIの今後
- LLMでのリアルタイム故障診断
- VLMによる視覚的判断と説明
  - 事前学習なしの少数サンプルでの実装
エッジLLM/VLMの課題
- ドメイン特化で小さい高品質モデル
- ROIの算出が困難
- AI人材が製造現場に少ないため導入障壁がある

「メーカーを早期定年退職後、セカンドキャリアでCMで働いてます」
定年退職後にさらにクラスメソッドで働くってモチベ高くてすごい#devio2025
— おむろん (@omuron) 2025年9月3日

専用のモデルじゃなくて汎用のモデルを使ってある程度できるようになるというのが生成AIの強いところか

Session-A-06 AWSで始める実践Dagster入門

北川然平さん

タスク指向からアセット思考へ
- どうやって作るから何を作るかへパラダイムシフト
Dagster+dbt
- dbtの変換ロジックをDagsterのアセットグラフに統合

Dagsterを全然知らなかったけど「モダンなデータエンジニアリング向けのワークフローオーケストレーションツールです。」らしい。
データエンジニアリングの現場では注目度が高まっているツールなのかな。

Session-B-7 AIで進化するプロジェクトマネジメント　〜不確実性との対話を、AIが加速する〜

渡部比佐志さん

なぜプロジェクトは予定通りにすすまないのか？
- よくあるケース
  - 簡単だと思っていたら実装が始まったら依存関係が複雑だったことが発覚
  - 合意したはずが本番直前に「そんな話じゃなかった」
  - 伝えたつもりが相手の理解が違っていた
- 「見えてる範囲」がみんな違うからこれらが発生する
  - 立場の違いを強みに変える
  - 違いを前提に共通認識を作る
- プロジェクトマネジメントの本質は「不確実性との対話」
  - 完璧な計画はできない、認識ギャップは生まれる、対話で解決していく
AIが変えるプロジェクトマネジメント
- AIと人間は補完関係にある
  - 単独作業はAIと壁打ち
    - AIで視野を広げる「改善点10個出して」「経営層視点でレビューして」「過去の失敗事例と比較して」
  - 定期報告は常時モニタリング
    - 日報をAI分析「機能と比べて懸念される変化は？」「このペースだと期限に間に合う？」
  - 事後分析は予測的アクション
    - AIでの未来のリスク予想「２週間後に予測されるリスクは？」
- AIで変わること
  - 対話の頻度：週一から毎日へ
  - 対話の質：表面的から本質的へ
明日からの実践ガイド
- 注意点
  - AIの力は過信しない
    - セキュリティ、丸投げせずチェックしてから使う、記録を残す
  - 超優秀な新人として扱う
    - 作業が早いが責任は上の人（人間）がとる
    - 優秀だが知らないことは知らない
    - プロジェクト固有な文脈を与えないと一般論になる
- 実践できること
  - 議事録の構造化
    - 音声の文字起こしをAIで構造化「この会議のメモを以下の形式で保存して」
  - リスクの網羅的洗い出し
    - 「プロジェクト計画から以下のリスクを各５個出して：技術、体制...」
  - 報告書の自動生成
    - 同じデータから役職別に最適化、報告書作成の効率化
    - 「この進捗情報を以下の３つのパターンに変換して：経営層、開発、顧客」

「プロジェクトマネジメントは不確実性との対話」なので対話を重ねていくと。
「AIによってプロジェクトマネジメントは進化していく」とのことでした。
自分はPMではないけど、とても参考になりました！

Session-A-08 GrafanaのGit Sync機能を使って生成AIと共にダッシュボードを開発してみた

与那嶺創さん

Grafanaの課題
- データソースごとにクエリ言語違う、オプション多い、ダッシュボード構築削減したい
AI使ってGrafanaを操作
- ダッシュボードをコード化
- リモートとローカルのコードを受け渡し、リモートのコードをダッシュボードへ反映
- JSONで定義されているのでAIとの相性は良い
問題点
- リモートコードの他の人の変更によるローカルとの差分
- コード編集によるダッシュボードの変更点がわかりづらい
GrafanaのV12にてGit Sync機能追加
- GrafanaのダッシュボードJSONをGitHubと同期できるようになった
- リポジトリをCloneしてClaude Codeにお任せ
  - 丸投げだといいのは出来ない
  - ラフ図を(Figmaなどで)作って渡すといい感じになりやすい
  - 「画像をベースにAWSのコストを分析するダッシュボードを作ってpushしてPRして」
    - PRでの差分プレビュー機能がGrafanaにはある

ダッシュボードのラフ図を言葉で説明難しいからFigmaで作ってわたすと
なるほど、これは良いやり方 #devio2025 pic.twitter.com/UudOYXKXjn
— おむろん (@omuron) 2025年9月3日

これ、QuickSightもJSONで管理されてるし、CloudWatchダッシュボードもJSONだから、そのあたりでも同じアプローチ取れないかな？

Session-B-11 生成AIと物体検知（YOLO）の活用例について

大野育海さん

YOLO：You Only Look Once
- 物体検知アルゴリズムの一つでどの場所に何があるか見つける技術
- 高速でリアルタイム処理に適している
- 生成AIではなく認識するAI
デモ：鳥の画像をアップして鳥を切り抜いて説明するアプリをKiroでタスク計画をしてもらってClaude Codeで作った
- YOLO：物体検出
  - 単体だと鳥は見つけれるけど説明はできない
- OpenCV：画像処理
  - リサイズで消費トークン量も削減
- Gemini 2.5 Pro：回答生成、
  - 単体だとノイズが多くて鳥を見つけれないので、YOLOと組み合わせて精度をあげる
- React + Electron：フロントエンド
- SQL Lite：データソース

グロムでレースしてる！
グロム面白いよね #devio2025 pic.twitter.com/zzgJwhbZbQ
— おむろん (@omuron) 2025年9月3日

AIのPoC考えるときにいつも困るのがアプリのアイデアなんですが、趣味の延長でPoC考えるのはいいアプローチ。鳥さんかわいい。
生成AIの進化でYOLOをかまさないほうが精度が上がるケースも出てきているとのこと。

Session-A-10 Amazon Bedrock AgentCoreを使ってみよう！〜各種機能のポイントを解説〜

神野雄太さん

AgentCore：AIエージェントを展開・運用するために最適なマネージドサービス
- Runtime：ホスティング機能
  - Strands AgentsやMastraなど複数のフレームワークをサポート
  - デプロイも対話型で簡単、 agentcore launch で実行
    - 実際にはコンテナビルドなど複数の作業をシンプルにしてくれる
  - Invokeで呼べる、Streamingもサポート
- Identity：認証
  - Inbound Auth：AI自体の認証機能、CognitoなどのIdPを通して認証
  - Outbound Auth：AIエージェントが外部サービスを呼ぶための認証機能、Sercrets ManagerにAPIキーを保存してそれを利用して外部APIを呼んだりする
    - M2M認証もできる、OAuth+APIキー
- Gateway：外部処理のTool化機能
  - API,Lambda、各種サービスをMCP互換として呼び出せるサービス
    - Lambdaが返すJSONを定義してマッピングしてMCP化
  - Semantic Search機能
- Memory：記憶機能
  - 会話履歴を保存
  - Short-term：短期記憶、最大365日保存、セッションIDがあるので簡単にユーザーごとの履歴を保存できる
  - Long-term：長期記憶、Short-termの記憶から自動的に重要な情報を抽出・統合できる機能
    - 戦略として3つのパターンを準備
      - 質問のやり取りから知識や概念を保存
      - ユーザーの好み
      - サマリー
- Observability：各種メトリクスを可視化
  - 設定を有効化する必要とOpenTelemetryの依存関係をデプロイ時に含む必要あり
  - CloudWatchダッシュボードの新機能で表示できる
- Built in tools：
  - Code Interpreter：生成AIが作ったコードを安全なサンドボックスで実行
  - Browser：生成AIがブラウザを操作するための実行環境を提供

めっちゃ参考になった！
ちゃんと試していかないと。

Session-B-13 継続的なサービス開発のための技術的意思決定のポイント

太田拓也さん

サービス開発にありがちなこと
- いびつな設計だけど理由がわからず修正できない
- ライブラリやフレームワークが廃れた
- 想定と異なる使われ方でパフォーマンスでなくなった
- → ビジネスは不確実性の塊なので過去の意思決定には経緯を払う
クネビンフレームワーク：不確実性がある状況下での効果的な意思決定アプローチの決定を支援するモデル
複雑系への対処方法
- 探索、把握、対応
- ループをして意思決定を繰り返して練習していく
コンテキストを大事に
- コンテキストはすぐに失われる
  - コンテキストが残されていたら？
  - 判断の結果（コードや設計）は残るが判断の理由のコンテキストは残らない
コンテキストを残す
- ADR(Architecture Decision Record)
- 意思決定、背景、決定に至った考慮事項をADRという形で把握する
- コンテキストと共に意思決定を残す
- マークダウンでGitHubで管理
  - ビジネス的な制約を残す
  - スケジュールの制約は消えがち
すべての決定は透過ではない
- One-Way Door, Two-Way Door
- One-Way Doorは立ち止まり深く議論し分析、こちらに投資
  - 開発におけるOne-Way Door：APIのIF設計、DBスキーマ、言語/フレームワーク、セキュリティなどが後戻り難しいのでADRに残す
- Two-Way Doorは素早く試して学ぶことで意思決定コストを削減
  - 開発におけるTwo-Way Door：内部APIのIF設計、静的解析やLintツール、実装ルールの定義
意思決定の質を改善
- 「〜べきか否か」という意思決定に注意
  - 視野狭窄になっていないか？
  - 選択肢を広げることを考える

確かに技術選定のコンテキストについては毎回口頭で説明をしている状況。
Gitにあわせて残すのはよさそうだ。

Session-A-12 Aurora DSQLはサーバーレスアーキテクチャの常識を変えるのか？

岩田智哉さん

サーバーレスアーキテクチャ（Lambda）におけるデータストアの選定
- DynamoDB
  - サーバーレスでのファーストチョイス
  - VPCいらない、オンデマンドで自動スケール
  - クエリできることが限定的、必要に応じてCQRSの検討
- Aurora
  - RDS Data API, RDS Roxy, Serverless, Limit less...考えること多い
  - データストアの汎用性は抜群
  - VPC必須
  - ステートレスなLambdaとの相性問題
  - 接続管理やスケールアウトは課題
Aurora DSQL
- PostgreSQL互換のサーバーレス分散SQL
- Lambdaユーザーの要望に答えるDBとしてDSQLを開発
- 従来のAuroraを置き換えれるのか？
  - PostgreSQLのワイヤプロトコルが使えるぐらいと考える
  - PostgreSQLのExtgension利用不可、外部キーやシーケンス、トランザクションなど制限たくさん
  - パスワードではなく一時トークン利用
接続の考慮事項
- 100接続/秒でバーストキャパシティ1,000接続、最大10,000接続、最大接続時間60分
  - Lambdaを7000までスパイクさせて接続させたら56%でエラー、3分で収束
- コネクションプールを活用するのがいい、接続が切れるか50分で再接続させる
トランザクションの考慮事項
- ロックが無い、COMMITのタイミングで競合がわかってエラーになる
- 楽観的同時実行制御を意識した実装が必要
料金
- DPUの課金が試算できないので試して予測するしか無い

DSQLとても気になってたので概要がわかって勉強になりました。
モノリスなシステムなら今までのRDSで十分で、Lambdaメインで使うときにDynamoDBだと検索が辛いときの選択肢になると。

Session-A-13 AI駆動開発に向けた新しいエンジニアマインドセット

かずえさん

生成AIはSE/PGに取って「手作業が機械化革命した」
「若手が成長できない」わけではない
- GitHub Copilotはジュニア層に強い効果
「仕事奪われる」わけではない
- 全てをAIで完結するのは難しい、7割までは早いけど
- 高次な上流工程は人が担当
- そもそも人材不足
しんどい仕事が人へ
- キャッチアップしんどい
- 判断がしんどい
「労力は外注できるが能力は外注できない」
スキルアップにAI使う

「AIと競争せずに共創する。変化を受け入れる。とりあえず触れる。」などが大事と。

Guest-Session-04 AWS のシリコンイノベーションと AWS Neuron のコストパフォーマンス

ゆっきーさん

インフラをチップからAWSが設計することで、性能、コスト、電力効率を最適化
- AIモデルを作成しトレーニングするためのインフラを提供：AWWS Trainium, AWS Inferentia
Neuronを使ったEC2にLLMモデルをいれて動かすデモ
- 1時間動かすのにBedrockよりコスト半額で動かせている

AWSのやることが幅広すぎ。
Anthropicの学習にも使われてるとのこと。

Guest-Session-05 まだ間に合う！StrandsとBedrock AgentCoreでAIエージェント構築に入門しよう

みのるんさん

speakerdeck.com

2025年はAIエージェント元年らしい
AIエージェント：AIをつかった「なんか賢いアプリケーション」全般がAIエージェント
- コーディングAIエージェントが流行ってるけどそれ以外にたくさんある
- 他の例：KDDIの"本部長AI"「A-BOSS」
LLM時代の「AIエージェント」の特徴
- プロファイリング、長期記憶など
Bedrockを使ってAIエージェントを作るには？
- 初心者向け：Bedrock
  - Bedrockエージェント使えばマネコンでポチポチ作れる
    - Lambdaはツールとして必要
    - マルチエージェント対応、複数エージェントコラボできる
  - つらいところ
    - デプロイ辛い、IaC一応対応しているけどハードル高い...
    - 最新LLMへの対応が少し時間かかる、Bedrockクォータに抵触して即エラー
    - MCP未対応、マルチエージェントの構成に制限あり
- 本格入門：Bedrock AgentCore, Strands Agents
  - Strands Agents：シンプルで開発しやすいフレームワーク
    - Qの裏側に使われたりしている
    - LLMのモデルとシステムプロンプト指定だけで動かせる
    - デフォルトでストリーミング出力対応
    - Bedrockのレートリミットの429吐いても自動リトライ
    - tools に組み込みツールを指定するだけで利用可能
      - @tool でデコってPython関数書いても追加できる
    - AWS以外のモデルも呼びやすい
    - MCPサーバーからツール取得可能
      - MCPローカル/リモート両方に対応している
      - MCPクライアントが簡単に実装できる、MCPホストになれる
    - Agent as Tools、いわゆるSupervisorパターンの実装が容易
  - Bedrock AgentCore
    - 目玉機能は「ランタイム」、AIエージェント専用のコンテナLambdaみたいなもの
      - Strands Agentsのコードを簡単にデプロイできる

オオトリみのるんさん！ #devio2025 pic.twitter.com/w5u2Xn8Dui
— おむろん (@omuron) 2025年9月3日

生みのるんさんのオオトリの講演！
Strands Agent使って早くエージェント作らないと...