AIエンジニア Devin と歩む、自律型運用プロセスの構築

Transcript

1. AIエンジニア Devin と歩む 自律型運用プロセスの構築 e-dash株式会社　伊藤 明彦 2026年2月27日 @a2-ito @piyohiko110
2. 2 自己紹介 伊藤　明彦 Ito Akihiko 所属： e-dash株式会社 役割： SRE 出身： 山口県 趣味： DIY・ジム @a2-ito / @piyohiko110
3. 3 会社について 企業のCO2排出量可視化・削減の SaaSを開発 三井物産出資のスタートアップ 2022年設立・本社は東京赤坂 ソフトウェアエンジニア絶賛募集中です
4. 4 本日の内容 話すこと e-dash での Devin 活用事例 検証中の新しい取り組み：パフォーマンス分析 検証中の新しい取り組み： Linear Triage 自動化 話さないこと Devin 自体の機能詳細
5. 5 小ネタ：ほめたらたまに ACU くれます
6. 6 e-dash における Devin 活用事例 チケット駆動 AI 開発 Linear チケットのラベル付与をトリガーに、コード修正・PR作成まで実施 Slackワークフローを起点にしたアカウント・権限管理 Slack ワークフローをトリガに、アカウントやグループのメンテナンスを実行 PR レビュー 最近公式機能としてリリースされたPRレビュー機能を活用 DeepWiki への集約 会議議事録を自動で DeepWiki（社内ナレッジ）へ構造化して集約
7. 7 活用事例：アカウント・権限管理 Slack ワークフローをトリガに、アカウントやグループのメンテナンスを実行
8. 検証中の新しい取り組み 定期的なパフォーマンス分析 SLO/ダッシュボードからボトルネックを分析 Linear Triage の自動化 issue の自動トリアージ & 対応
9. 9 定期的なパフォーマンス分析 Playbook + MCP で Datadog ダッシュボードを定期的に分析しチケットを起票 1 ダッシュボード 確認 → 2 ボトルネック 分析 → 3 対策を まとめる → 4 レポート 作成 → 5 チケット 起票
10. 15 パフォーマンス分析： Playbook 3ステップでダッシュボードを分析 Step 1: 状況把握 指定プロダクトの Datadog SLOダッシュボードから「正常」「 SLO違反」「データ未取得」の 3 カテゴリに分類 　　　　 Step 2: 原因調査 違反SLOについて、RUM/APMのエラーイベント・トレース・ログを深掘りし、根本原因の 仮 説をConfidenceレベル（High/Medium/Low）付きで整理する Step 3: Linear 起票 親issue（全SLOのサマリレポート）＋ sub-issue（各違反SLOごとの原因・対策）の親子構造 でLinearに起票し、結果をユーザーに報告する
11. 10 パフォーマンス分析：結果と所感 人間が作るよりも高い精度、細かく記載 記載が細かすぎて認知負荷高め。チューニングの 余地あり 実行開始からチケット作成まで約 15分 1回につき約2 ACU（≈ 624円）。人間に比べると大 分安い
12. 11 Linear Triage の運用課題 issue が溜まる → 誰かが見る → 判断する → 振り分ける 課題 詳細 Triage が溜まりがち 新しい issue が毎日入ってくるが、確認・振り分けが追いつかない 手動作業が多い ラベル付与 → アサイン → 調査依頼の繰り返しに時間を取られる → この繰り返し作業、 Devin にやらせたら？
13. 12 最近リリースされた 新しい Devin × Linear 連携 ネイティブ統合で自動起動・ラベル分岐が可能に 機能 内容 ネイティブ統合 Linear から直接 Devin を起動。MCP の別途インストールが不要に ラベルトリガー ラベルに応じて異なる Playbook を自動起動できる ステータストリガー Todo / Backlog などステータス変更でも起動可能 docs.devin.ai/ja/integrations/linear
14. 14 自動化フローの全体像 Triage → 判定 → auto-fix / needs-review に分岐 → 自動対応 新規 Issue (Triage) → Playbook① Devin完結可否を判定 → ラベル付与 auto-fix / needs-review 判定ロジック（ 2ステップ） ① 外部原因チェック 外部サービス起因 → 即 needs-review ② Devin での対応可否を判断 影響範囲 + 作業量 + 依存 → auto-fix/needs-review ラベル分岐 auto-fix → 実装 → PR 作成 Devin が実装まで完結 needs-review → 調査 → 報告 調査結果をコメントで報告
15. 15 Playbook①：自動対応可否の判定 二段階の判定ロジックで Devin が完結できるかを分類 判定ロジック（ 2ステップ） Step 1: 外部原因チェック 外部ツールやサードパーティ起因 → 即 needs-review Step 2: 三軸スコアリング 影響範囲 / 作業量 / 依存関係（各 0-2点） 低スコア = auto-fix / 高スコア = needs-review 閾値は Playbook 内で調整可能 スコアリング例 軸 auto-fix 例 needs-review 例 影響範囲 0 2 作業量 1 2 依存関係 0 1 合計 1 5
16. 16 Playbook②：ラベルに応じた自動対応 auto-fix / needs-review をトリガーに、対応内容を自動で切り替え auto-fix → Devin が実装まで完結 Devin にアサインし自動着手： 1. issue の要件を分析 2. コード修正・テスト実行 3. PR を作成して提出 needs-review → 調査報告で人間を支援 コード調査してコメントで報告： 1. issue の要件を詳細に分析 2. 影響範囲をコードベースから調査 3. 変更方針・リスクを整理 4. issue コメントで調査結果を報告 → レビュー依頼まで完全自動！ → 人間が判断すべき部分だけ残す
17. 17 まとめ • Devin くんも1エンジニアとして日々働いてもらっています https://zenn.dev/edash_tech_blog/articles/3b89ba528c9eec • 今回検証した内容は早速横展開していく予定です ◦ パフォーマンス分析 ◦ 自動トリアージ • Devin 最高！
18. THANK YOU! e-dash株式会社　伊藤 明彦 2026年2月27日 @a2-ito / @piyohiko110