Slack 上から PR を立てるワークフローを Dify で構築してみた
こんにちは。株式会社キカガクの tetsuro_b です。
弊社では Dify をセルフホスティングしており、社員であれば誰でも AI アプリケーションを構築できる環境が整っています。
今回はその Dify を活用し Slack 上から GitHub に PR を立てられるワークフローを構築してみたので紹介します。
ワークフロー作成の背景
弊社では Cloud Logging でアプリケーションログを管理しています。
注視するべきログについては Cloud Pub/Sub で Slack へ転送しすぐに確認ができるようにしています。
また、全てのエラーログが Slack へ転送されてきては困りますので Cloud Pub/Sub の実装内で Slack へ転送しないログを除外する処理を組み込んでいます。
ただ、現在のこの運用では「Slack で除外したいログ発見 → ローカルでブランチ切って除外ログを記載 → commit & push → PR 立てる」
という作業を都度行う必要があり少々手間でした。
今回は Dify を活用し、この一連の作業を自動化していきたいと思います。
ワークフローの概要
完成イメージ
Slack に転送されてきたログにスタンプをつけることで、PR のリンクがスレッドへ投稿されます。
PR へアクセスすると、該当のログが新しく追記されていることが確認できます。
フロー図
まずは今回作成したワークフロー図の概要です。
スクリーンショットだとかなり細かくなってしまうため、要約すると以下のとおりです。
※ Dify は Webhook を受け取ることができないため、その部分のみ Dify ではなく別でサーバーを立てて Dify にリクエストを送るようにしています。
ワークフローの詳細
ワークフロー内の具体的な実装内容を記載します。
すべてのステップを記載するととても長くなってしまうため重要なステップのみ解説をしていきます。
また、ワークフローでは Slack API と GitHub API を利用しています。
各 API の仕様については公式ドキュメントの参照をおすすめします。
Dify ワークフローの作成
まずは Dify を立ち上げ「ワークフロー」でアプリを作成します。
Slack Webhook の情報を Dify で受信
Slack の Webhook から送信された情報を Dify で受信します。
今回は Chanel ID (channel) と Thread ID (ts) を設定しました。
Slack からメッセージを取得
Slack API を使い、Slack でスタンプが押されたメッセージを取得します。
※ Slack の Webhook にはメッセージが直接含まれないためこの処理が必要です。
※ メッセージ = Slack に転送されてきた Cloud Logging のログを指します。
API レスポンスを整形
API レスポンスをその後のフローで利用するためには一度変数として定義する必要があるため API レスポンスを変数に格納します。
- usename: Slack 上でスタンプを押しワークフローを実行したユーザー
- message: Slack に転送されてきた Cloud Logging のログ
- location: ログをフォーマットするために必要な弊社独自の情報です。
ログ情報をフォーマット
格納された変数をもとに、ログ情報をフォーマットします。
コードでゴリゴリやれば LLM を使うまで無いですが、せっかく LLM を使えるのでココは LLM に任せましょう。
ログ情報をファイルに記載
GitHub API を使い、対象のリポジトリからコードを記載したいファイルを取得します。
取得したファイルに対して LLM を使いフォーマットされたコードを挿入します。
ブランチ作成 ~ PR 作成
GitHub API を使い「ブランチの作成 / commit / PR 作成」まで行います。
まずはブランチを新規に作成します。
作成されたブランチに対して前段で生成したファイルの内容を commit します。
PR を立てます。
Slack へ PR の URL を投稿
Slack API を使い、該当の Slack のスレッドへメッセージを投稿します。
細かい部分は省略しましたが以上で、ワークフローの構築が完了です。
Dify でワークフロー作成してみて感じた課題
ほぼほぼコードを書かずに、GUI をポチポチするだけで LLM や HTTP リクエストを組み込みワークフローが構築できる点では Dify に非常に可能性を感じました。
ただその一方で、自分がコードをかける人間でかつ、コードで実装できるような要件であれば Dify を使わず素直にコードで実装したほうが良いケースも多そうです。
※ 構築はエンジニアがやってその後の運用を非エンジニアがやるとかであれば、コードで実装できる要件でも Dify が有効かもしれません。
以下に理由を3点まとめました。
デバッグの難しさ
Dify は実行の都度ログが出力されるため、どのステップで処理が失敗しているのか確認は容易です。
ただエラーログの直前に自分でログを仕込むなど、コードでの実装と比べるともちろん自由さは無いです。
エラー内容によっては吐き出されるログだけでは原因の特定が難しく、解消に時間がかかってしまうケースも出てきそうだなと感じました。
エラーハンドリング
ワークフローの各工程では API リクエスト等行っている都合上、様々な要因でエラーが発生する可能性があります。
Dify ではそのようなケースに対してエラーハンドリングが可能ですが、各ステップに対して細かく調整をし始めると少し大変です。
その点ではやはり自由にエラーハンドリングの設計ができるコードでの実装に分があるかと思いました。
保守 / 運用
Dify はノーコードで AI アプリケーションを構築できる点が魅力です。
ただ今回のように複雑な要件をワークフローに落とし込んでしまうと全体の見通しが悪くなってしまったり、同様の処理を別のワークフローで使いたい場合にも共通化が難しかったりなど、保守運用を見据えてワークフローをしっかり設計する必要があると感じました。
今回作ったワークフローの応用
ローカル環境を経由せずとも、Slack から PR を立てることができるのはとても快適な体験でした。
複数のファイルを編集する必要があるような要件ではこの方法では難しいものの、単一のファイルの編集であれば LLM のプロンプトを工夫するだけでいろんなケースで応用の可能性があると感じました。
- Terraform の PR を Slack から自然言語で立てる
- テキストメインのページ(利用規約など)の微修正を Slack から自然言語で指示
- Slack のスレッドを要約して、RADME.md(開発ルールなど)を更新する
感想とまとめ
今回は Dify を活用して身近な業務効率改善に取り組みました。
株式会社キカガクでは Dify がセルフホスティングされており社員であれば誰でも Dify を使って AI アプリケーションの構築が可能なので今後も業務効率化の1手段として活用していきたいと思います。
宣伝
株式会社キカガクではエンジニアを募集しています!!
少しでも興味がある方がいれば、まずはカジュアル面談でお話しましょう。
Discussion