はじめに
DevinのSlack連携では、メンションで指示を出すだけでなく、
エラー通知や監視アラートをトリガーにDevinを自動起動させることができます。
これにより、人手を介さない24時間体制での初動対応が実現できます。
本記事では、基本的なSlack連携の設定方法から、Webhookやワークフローを活用した
自動化パターンまで、実際の運用で使える形で解説します。
夜間や休日のエラー対応負荷を軽減したい方の参考になれば幸いです。
Slack連携の設定方法
DevinのSlack連携は思っているよりもシンプルに設定できます。
公式ドキュメントに詳細な手順がありますが、ここでは実際に設定する際のポイントをまとめました。
設定手順
-
Devin管理ページからSlack連携を設定
- Devinの設定画面からIntegrationsへ移動し、Slackを選択
- Slackにログインし、ワークスペースを選択（チャンネルは特に指定しない）
-
ワークスペースにSlack用のDevinアプリをインストール
-
DevinメンバーとSlackユーザの関連付け
-
Devinアプリをチャンネルに招待
※SlackからDevin操作したい人はそれぞれDevinコンソールから同様の操作をする必要があります。
※Slackのメールアドレスとdevinのメールアドレスが同一でないと連携がうまくいかないことがあります。
SlackでのDevinの基本的なメンション操作
Slackで@Devinのメンションに続けて指示を出すことで、Devinが起動して指示を実行します。
@Devin
フロントエンドのエラーを修正してください。
Devinの挙動を制御するキーワードがいくつかあります。
| キーワード関数 | 説明 |
|---|---|
!ask |
エージェントを起動せずに、コードベースの回答を素早く得るには、メッセージを !ask で始めてください。 |
!deep |
高度な検索を使用して、より深い研究の答えを得る。（公式）GPT-5やSonnet4.5を使用する？ |
mute |
Devinがスレッド内のSlackメッセージに反応しないようにします |
unmute |
上記muteの解除 |
(aside)、!aside
|
Devinがメッセージを無視するようにします(スレッド内で直接Devinの実行にコメントするのに便利です) |
sleep |
Devinを眠らせます。再びDevinを起こすには、スレッドにメッセージを送信するだけでOK。 |
archive |
Devinを眠らせてセッションをアーカイブする |
EXIT |
セッションを終了する |
playbook:<playbook-name> |
実行時に特定のプレイブックを使用する |
Devinの名前設定
SlackのDevinアプリ名は変更可能です。
設定は以下から行えます。
Slack管理画面 → Configure apps → Installed Apps → Devin → App Details → Configuration → Bot User
それっぽい名前を設定することで、あたかも同僚のエンジニアにお願いするような雰囲気でDevinを操作することも可能です。
お蔵入りさせましたが、Devinのドキュメントをベースに作成したペルソナをここで公開しておきます。
Devinペルソナ
Devinのペルソナモデル
-
ペルソナ概要
-
名前：高橋 蓮（たかはし れん、24歳、入社1年目、バックエンドエンジニア研修中）
あだ名はDevin（デビィン） - 技術スタック：Java／Spring Boot基礎、Git、Linux、JUnit、GitHub Actions
- 勤務環境：フルリモート＋週1オフィス出社
- 性格・特長：真面目で几帳面、向上心が強く、フィードバックを素早く吸収
-
名前：高橋 蓮（たかはし れん、24歳、入社1年目、バックエンドエンジニア研修中）
-
生活習慣
-
平日
- 5:50 起床 → ストレッチ＆瞑想10分 → コーヒーを淹れながら前日の振り返り
- 6:30〜7:00 オンラインでチーム朝会参加
- 9:00〜12:00 コーディング（30分タイムボックスで小タスク）
- 12:00〜13:00 昼食＆散歩（近所のカフェでブレイク）
- 13:00〜18:00 午後業務（レビュー待ちタスクのフィードバック、CI検証）
- 18:30 退勤後にジムで筋トレ or ランニング（週3回ペース）
- 20:00〜22:00 プログラミング学習（Udemy講座、技術ブログ閲覧）
- 24:00 就寝
-
休日
- 土曜：オンライン／オフラインのハッカソンや勉強会に参加
- 日曜：友人とボルダリング or カフェ巡り → 夕方からFPSゲーム
-
平日
-
趣味・人間味
- OSSコントリビュート：週1回GitHubで小さなバグ修正を提出
- コーヒー探訪：自宅でハンドドリップ練習＋週末に新豆購入
- 読書：技術書（『リファクタリング』など）と小説（村上春樹作品）を並行
- 動画視聴：YouTubeのペパボTechチャンネルやTech系ポッドキャスト
- 社交：月1回、同僚とオンライン飲み会で情報交換
-
ペインポイント
- 抽象度が高いと迷走→「成功基準・手順・参照コード」が必須
- 長時間連続作業で集中力低下→30分単位のタイムボックスが効果的
- 資料不足で試行錯誤増大→FAQ／コードスニペット集でカバー
-
改善策／次に試すアクションステップ
- タスク定義テンプレート作成：目的／手順／成功条件／参照リンクを統一
- 30分タイムボックスの徹底：ポモドーロタイマーをチーム共有
- FAQ＆スニペット集の整備：Wikiに「よくあるミス例」と「コード例」を掲載
- 週次レビュー会定例化：成功例・失敗例のスクリーンショット付き共有
※Devinのドキュメントページをベースに生成
メンション指定でのDevinの特徴
基本動作
-
スレッドでの追加指示：最初の指示でDevinをメンションした場合、スレッド内の返信では自動的にDevinが反応
-
並行作業：別スレッドで新しい会話を開始することで、独立したセッションとして並列作業が可能
-
途中参加：Devinメンション始まりでないスレッドでも、途中からメンション付きで作業指示が可能
セッション管理の注意点
- Slackで
@Devinメンション付きで始めた会話のスレッドがDevinの1つのセッション（一連のやり取り）です。 - スレッドの途中から
@Devinメンション付きでメッセージを送った場合もDevinのセッションを開始します。 - 一度
@Devinメンションを付けてDevinの応答があったスレッドでは、再度@Devinメンション付けても新しいセッションではなく、同じセッションでのやり取りとなります。 - 初回メンション後は、同一スレッド内でメンション不要です。
その他の仕様
- Slackにファイルを添付して指示することで、ファイルを使用した指示が可能です。
-
@hereや@channelのメンションではDevinは反応しません。 - Devinのメンバーではないユーザーが
＠Devinのメンションをつけても反応しません。 - Devinメンションで開始した会話では、スレッド内のすべてのコメントがDevinへの指示として認識されます。（muteやasideキーワード等による回避策あり）
Slackでの制約事項
Devinコンソールとは異なり、以下の点に注意が必要です。
- リポジトリの選択、エージェントの選択は不可
- リポジトリの指定は以下のようなプロンプトで可能。
「You only need to look in the following repo: {リポジトリ名}」 - エージェントの選択は、事前にDevinコンソールで使用したいエージェントに星をつけておくと、そのエージェントで起動します。
自動化フローの実践パターン
Slackへの通知をトリガーにDevinを自動起動させることで、人手を介さないエラー対応フローが構築できます。
以下では、監視システムやアラートサービスと連携した具体的な実装パターンを紹介します。
パターン1: Webhookからの直接起動
SlackのWebhookで送信するメッセージにDevinのメンションを付けて送信
🚨 Production Alert 🚨
エラー内容
<@メンバーID> エラーを調査してください。
ログを確認し、必要に応じてCloud SQLのデータも確認してください。
※WebフックからDevinのメンションを指定する場合は、@DevinではなくSlackのDevinアプリのメンバーIDを指定します。
メンバーIDは、以下のアプリ詳細にあるUで始まるメンバーIDです。
※エラー内容はスタックトレース情報など詳細なものがあると原因特定がしやすくなります。
パターン2: ワークフロー経由での自動起動
監視サービスなどからSlackに対してアラート通知される場合、通知内容から判断してSlackのワークフローを起動し、ワークフローのメッセージ内にDevinのメンション付きで指示を出すことでDevinを起動させます。
- 任意のSlackチャンネルでワークフローを追加
チャンネルの上にある「+」ボタンから「ワークフロー」選択 - 「ワークフローを作成する」をクリック
- イベントで「メッセージが投稿された時」を選択
- アラート通知されるチャンネルを選択し、Devinの応答する対象となるキーワードを設定
- ステップを追加し、「チャンネルへメッセージを送信する」を選択
- 送信先のチャンネルと、送るメッセージを設定し、保存
ワークフローの新規作成
イベントの選択
チャンネル指定、キーワード設定
フィルターに「アプリとワークフローからのメッセージ」を追加しておくとユーザのメッセージから不必要にワークフローが実行されることを防げます。
ステップを追加
チャンネルへメッセージを送信する
メッセージ内容
@Devin
アラートの内容をもとにログのサーバのリソースを調査してください。
パターン3: メール通知からの自動起動
Slackのインテグレーション機能として、メールアドレスにメールを送ることでSlackチャンネルにメッセージを投稿できます。
- Slackのチャンネル詳細からメールアドレスを取得
- 取得したメールアドレスにエラー情報を通知
- Slackワークフローでチャンネルおよびキーワードを設定（ワークフローの設定は、キーワードやチャンネルは違いますが、1つ前の設定と同じなので割愛）
※フィルター条件はなしにしないとワークフローが反応しないため、その点だけ注意 - Slackチャンネルにワークフローを追加
Slackチャンネル投稿用メールアドレス取得
メール受信によるSlackメッセージ
ワークフローのキーワードが反応するのは、メールの本文のみです。
件名にキーワードが含まれていてもワークフローは実行されません。
自動化に必要な事前設定
自動化フローを機能させるには、Devin側での認証情報の設定が必須です。
認証情報の設定
Devin側ではエラー状況を確認するため、リソースへアクセス可能な認証情報を設定しておきます。
GCP：必要最低限の権限を付与したサービスアカウントを作成し、その鍵情報をDevinのシークレットに保存しておきます。
AWS：IAMユーザとロールやポリシーを作成し、IAMユーザのアクセスキーを保存しておきます。
エラーやアラート時のDevinへの指示で該当のシークレット情報を用いることで対象のリソースやログの調査を自動的に実施することが可能となります。
複数環境を扱う場合の注意点
- 発生するエラーメッセージやアラートに接続先を特定する情報を付与（誤った環境を調査し、的外れな調査結果を防ぐため）
- 上記が不可の場合、通知対象のサービス、環境毎にチャンネルを分けて、それぞれにSlackワークフローを用意し、ワークフローのメッセージで調査対象を指定
- 複数の接続先に対して、対象となる認証情報をマッピングできるようにナレッジやシークレットを整理
ナレッジとシークレットの設定例
以下は実際に運用している設定例です。環境に応じて調整してください。
ナレッジ
Devinに対して、エラー調査時の基本的な動作ルールを教えておきます:
- エラーのアラートを添えて指示された場合は該当環境へログの確認を実施する
- アラートに含まれる情報から調査に必要なサーバへのアクセスキーを参照して調査を実施する
- "credential/"で始まるシークレットキー
## GCPの場合：
- Devinのシークレットの以下命名規則のキーが対象サーバへアクセスするためのキー
'credential/gcp/{プロジェクトID}/{サービス名}-prd'
- 対象リソース
- Cloud Logging
- Cloud Run
- Cloud SQL
- Cloud Function
## AWSの場合：
- Devinのシークレットの以下命名規則のキーが対象サーバへアクセスするためのキー
'credential/aws/{アカウントID}/{サービス名}-prd'
- 対象リソース
- CloudWatch LogGroup
- RDS
- Lambda
- ECS
- S3
Devinシークレットはjson形式であるため、それぞれの値をアクセスするための環境変数に設定
以下形式：
```json
{
"AccessKey": {
"UserName": "ユーザ名",
"AccessKeyId": "アクセスキー",
"Status": "Active",
"SecretAccessKey": "シークレットキー",
"CreateDate": "2025-09-18T10:30:09+00:00"
},
"Region": "リージョン"
}
export AWS_ACCESS_KEY_ID=$(jq -r '.AccessKey.AccessKeyId' {Devinシークレット})
export AWS_SECRET_ACCESS_KEY=$(jq -r '.AccessKey.SecretAccessKey' {Devinシークレット})
export AWS_DEFAULT_REGION=$(jq -r '.AccessKey.SessionToken' {Devinシークレット})
# 疎通確認
aws sts get-caller-identity
# STSの接続情報取得
aws sts assume-role \
--role-arn {調査用の権限を持ったロールを指定} \
--role-session-name devin-observer \
> /tmp/assume.json
# キーをSTSの情報で上書き
export AWS_ACCESS_KEY_ID=$(jq -r '.Credentials.AccessKeyId' /tmp/assume.json)
export AWS_SECRET_ACCESS_KEY=$(jq -r '.Credentials.SecretAccessKey' /tmp/assume.json)
export AWS_SESSION_TOKEN=$(jq -r '.Credentials.SessionToken' /tmp/assume.json)
# STSで疎通確認
aws sts get-caller-identity
シークレット
GCP
credential/gcp/{プロジェクトID}/{サービス名}-prd の形式でキーを設定
ハイフンやアンダーバーはプロジェクト名やサービス名に含まれており、/が使えたのでよかったです。
シークレットの中身は、サービスアカウントの鍵情報をそのまま登録
AWS
credential/aws/{アカウントID}/{サービス名}-prd の形式でキーを設定
シークレットの中身は、対象のアカウントにアクセス可能なユーザのアクセスキーの情報にリージョンを加えたjson。
{
"AccessKey": {
"UserName": "ユーザ名",
"AccessKeyId": "アクセスキー",
"Status": "Active",
"SecretAccessKey": "シークレットキー",
"CreateDate": "2025-09-18T10:30:09+00:00"
},
"Region": "リージョン"
}
AWSでは、AssumeRoleだけつけているユーザを作成し、実際の接続では調査用の権限を付与したロールを指定したSTSで接続します。
GCPでもimpersonate-service-account使えばAWSのような期限付きトークンでアクセスできそうなので、その辺もトライしたいところです。
自動化フローの課題
実際に検証してみて見えてきた課題をまとめます。
自動修正・デプロイまでは任せられない
現状は検証段階ですが、本格運用まで持っていったとしても、エラー発生時の調査および状況確認まで、もしくはドラフトでPR作成までが現実的なラインかと思います。
仕組み的にはデプロイまで可能ですが、別なブログでも書いたように品質面の不安は拭えないためです。
複数接続環境がある場合の鍵情報管理
クラウド側の仕組みをうまく活用しセキュアかつ適切な権限のみを許可しつつも管理が楽な方法について検討が必要です。
認証トークンが期限切れ
エラー発生〜初動の調査では問題にならないですが、時間をおいて追加で調査依頼する場合、期限切れで接続できずに諦めてしまう場合もありました。
再認証を自動化する部分は工夫の余地がありそうです。
逆のアプローチで新しいセッションで始めるために、初動の調査で追加調査のためのテンプレートを出力させるのもアリかもしれません。
同じエラーが頻発した場合にDevinが起動しまくる
致し方ない部分ではありますが、同じエラーに対して同じような調査を別々に実施してしまう無駄が発生します。一連のフローの中でデバウンスのような仕組みを取り入れる必要があります。
まとめ
DevinのSlack連携により、エラー通知をトリガーとした自動調査フローが構築できます。
メンション機能を活用した基本的な使い方から、Webhookやワークフローを組み合わせた
自動エラー調査まで、実際の運用で活用できる設定方法を解説しました。
まだ課題はありますが、Devinの特性を理解して適切な指示出しを行うことで、
24時間体制での初動対応を担える強力なチームメンバーとなるでしょう。
Discussion