ミツモア Tech blog

「ミツモア」を運営する株式会社ミツモアの技術ブログです

Slackからの依頼でPR作成まで自律的に行うデータエンジニアリングAIエージェント「でんじろう」の設計

ミツモアでAI関連の開発を担当している増田（@xmasudahiroto）です。

社内でデータエンジニアリング業務を支援するAIエージェント「でんじろう」を開発・運用しています。今回は、Slackからの依頼やエラー通知をトリガーに、自律的にコード修正からPR作成まで行うエージェントの設計思想と実装のポイントを共有します。

「でんじろう」とは

「でんじろう」は、ミツモアのデータエンジニアリングチームで運用しているAIエージェントです。主な役割は、dbtを使ったデータパイプラインの保守・修正作業の自動化です。Slackでの依頼やエラー通知を受けて、コードの修正からPull Request作成、Slackへの結果報告までを自律的に行います。

でんじろうが実際に Slack の通知からPR作成まで行ったところ。これは dbt の schema.yaml の編集。

ちなみに名前の由来は、「でん」がData ENgineerの略、「じろう」が「二番目」を意味し、社内で2人目のデータエンジニア（1人目は人間）として位置づけています。

背景と課題

データエンジニアリング業務では、以下のような「定型的だが手間のかかる作業」が頻繁に発生していました。

スキーマ変更への対応

連携元テーブルのスキーマが変更されると、dbtモデルの更新が失敗します。例えば、sourceとなるDBにカラムが追加された場合、そのカラムをbaseテーブル、中間テーブルやmartテーブルに追加していく必要があります。ミツモアではプロダクションDBにMongoDBを使用しているため、ネストされたカラム内のフィールドが増えるケースも頻繁に発生します。これらは単純な作業ですが、影響範囲を確認しながら複数ファイルを修正するため、地味に時間がかかります。

カラム追加の連鎖対応

「martテーブルに新しいカラムを追加したい」という依頼は日常的に発生します。baseテーブルから必要なカラムを引っ張り、中間テーブルを経由してmartテーブルまで追加していく作業です。やることは明確ですが、dbtのモデル構造を理解した上で複数ファイルを正確に修正する必要があります。

予期せぬデータによるエラー

APIやスプレッドシートから連携しているデータは、想定外の値が入ってくることがあります。NULL値、型の不一致、フォーマットの違いなど、原因を特定して適切にハンドリングする修正が必要です。

これらの作業は定型的なパターンに従うことが多く、「AIエージェントで自動化できるのでは」と考えたのが開発のきっかけです。

目指したユーザー体験

データチームがボトルネックにならない体制

ミツモアでは、ビジネスメンバーやデータチーム外のエンジニアが施策を推進する際、データ関連の修正が必要になることがあります。従来は以下のようなフローでした。

  1. ビジネスメンバーが施策に必要なカラム追加を依頼
  2. データチームが施策の詳細をヒアリング
  3. データチームが修正を実施
  4. レビュー・マージ

ミツモアでは少人数でデータチームを運営しているため、このフローではデータチームの対応待ちが発生し、施策の推進においてボトルネックになりがちでした。

目指した姿

「でんじろう」を導入することで、以下のような体験を目指しました。

  1. ビジネスメンバーがSlackで「○○カラムをマートに追加して」と依頼
  2. エージェントがコードを修正し、PRを作成
  3. データチームはレビューのみ実施
  4. マージして完了

データチームは「作業」から「レビュー」に役割がシフトし、施策の推進速度が向上します。

具体的なユースケース

エラー通知への自動対応

Digdagワークフローのエラー通知がSlackに届くと、エージェントが自動的にエラー内容を分析し、修正可能な場合はPRを作成してSlackに結果を報告します。

カラム追加依頼への対応

「このカラムをマートに追加して」という依頼に対し、エージェントがdbtモデルの構造を理解した上で、必要なファイルを修正してPRを作成します。

※なお、データ分析やスキーマ確認といったタスクは、別途開発しているText-to-SQLエージェントが担当しています。「でんじろう」はあくまでコード修正とPR作成に特化しています。

Text-to-SQLの記事: https://engineering.meetsmore.com/entry/2025/10/20/182746

アーキテクチャ概要

全体構成

エージェントは以下のコンポーネントで構成されています。

  • Slack Bot: Socket Modeでメッセージを受信し、エージェントにリクエストを送信
  • Backend Server: エージェントの実行を管理するFastAPIサーバー
  • Data Engineering Agent: Google Agent Development Kit（ADK）ベースのエージェント本体
  • ツール群: ファイル操作、Git操作、GitHub API、BigQuery、dbt操作などの各種ツール

技術スタック

コンポーネント 技術
LLM OpenAI GPT-5（LiteLLM経由）
エージェントフレームワーク Google Agent Development Kit (ADK)
データウェアハウス連携 BigQuery Toolset（ADK組み込み）
Git/GitHub操作 GitPython + PyGithub
データ変換 dbt
Slack連携 Slack Bolt（Socket Mode）
バックエンド FastAPI（Python）
インフラ Google Cloud Run

Google ADKを採用した理由

特別な理由があったわけではありませんが、ミツモアの分析環境がGCPベースであるため、BigQueryとの連携が容易な点が決め手でした。ADKにはBigQuery用のToolsetが標準で用意されており、認証周りの実装を省略できます。

ツール設計の方針

エージェントに「何をさせるか」を決めるにあたり、以下の方針でツールを設計しました。

ツールの分類

エージェントには20以上のツールを提供していますが、大きく以下のカテゴリに分類されます。

ファイル操作系

  • ファイルの読み書き、編集、削除
  • ディレクトリ一覧の取得

コード検索系

  • ripgrepを使った高速なコード検索
  • マッチ数のカウント、ファイル一覧取得

Git操作系

  • ステータス確認、差分表示
  • ブランチ作成、コミット、プッシュ

GitHub操作系

  • Pull Requestの作成・取得
  • Issue/PRへのコメント
  • GitHub Actionsのワークフロー実行状況・ログ取得

BigQuery連携

  • テーブルスキーマの確認
  • クエリの実行（読み取り専用）

dbt操作系

  • dbtコマンドの実行（run, compile, test等）
  • dbtソース定義の検索
  • dbtモデルの使用箇所検索

ツールの組み合わせで複雑なタスクを達成

個々のツールはシンプルな機能に絞っていますが、エージェントがこれらを組み合わせることで複雑なタスクを達成できます。

例えば「dbtモデルにカラムを追加する」タスクでは、以下のようなツール呼び出しが連鎖します。

  1. search_dbt_sources でソーステーブルの定義を確認
  2. search_dbt_model_usage で影響を受けるモデルを特定
  3. read_file で対象ファイルの内容を確認
  4. edit_file でファイルを修正
  5. dbt_operation("compile") でコンパイルエラーがないか確認
  6. git_add → git_commit → git_push で変更をプッシュ
  7. create_pull_request でPRを作成

セキュリティ設計

AIエージェントにGit操作やファイル書き込みの権限を与えることは、セキュリティ上のリスクを伴います。「何でもできるエージェント」は便利ですが、危険でもあります。

また、BigQuery経由でデータにアクセスするため、プロンプトインジェクションのリスクも考慮する必要があります。悪意のあるデータがテーブルに含まれていた場合、エージェントが意図しない挙動に誘導される可能性があります。

これらのリスクに対応するため、以下の制限を設けています。

ファイルアクセス制限

重要なディレクトリ・ファイルへのアクセスをブロックしています。例えば、以下のようなファイルが対象となります。

  • バージョン管理: .git, .github, .circleci
  • 認証情報: .env*, *secret*, *credential*, *.pem, *.key
  • インフラ設定: .terraform, .kube, *.tfstate
  • dbt設定: profiles.yml, dbt_project.yml

Git操作の制限

ブランチ命名規則

エージェントが作成するブランチは ai/* プレフィックスを必須としています。これにより、エージェントが作成したブランチであることが明確になり、レビュー時に注意を払ったり、専用のCIを設けたり、逆に特定のCIから除外したりすることができます。

保護されたファイル

.github/workflows/** へのステージング・コミットを禁止しています。CI/CDパイプラインの改ざんを防ぐためです。GitHub Actionsのワークフローファイルを変更できてしまうと、任意のコードを実行される可能性があります。

BigQueryの制限

読み取り専用モード

BigQuery Toolsetは WriteMode.BLOCKED で初期化し、データの書き込み・変更を禁止しています。

クエリスキャン量の上限

dbt実行時のBigQueryスキャン量に上限（10GB）を設けています。意図しない大規模スキャンによるコスト増加を防ぎます。

dbt実行の制限

対象データセットの制限

dbtの実行はサンドボックス用データセットのみに制限しています。本番データセットへの直接的な変更を防ぎます。

実行モデル数の上限

1回の実行で10モデルまでに制限しています。意図しない大量実行を防ぎます。

GitHub Actions関連のセキュリティ

GitHub Actionsのワークフロー実行状況やログを取得するツールは提供していますが、ワークフローの実行や設定変更はできないようにしています。エージェントはあくまでログを確認してエラー原因を分析する用途に限定しています。

ログ記録

AIエージェントが行ったツール実行や、送信したプロンプトは、すべてログで記録しています

システムプロンプトの概要

システムプロンプトでは、エージェントの役割と振る舞いを定義しています。

役割の定義

エージェントは「ミツモアのデータエンジニア」として振る舞うよう指示しています。データパイプラインの設計・保守、データ品質の保証、スキーマ設計などが主な責務です。

社内ルールの埋め込み

dbtのコーディング規約やデータモデリングのルールをシステムプロンプトに埋め込んでいます。具体的には以下のルールファイルを自動的に読み込んでいます。

  • スキーマ定義のルール
  • データセット命名規則
  • テーブル命名規則
  • 標準カラムの定義
  • 頻出マクロの使い方
  • モデルディレクトリ構成
  • マテリアライゼーション戦略

これにより、エージェントが生成するコードが社内の規約に沿ったものになります。

エラー対応の指針

どのようなエラーに対してコード修正が必要で、どのようなエラーには修正が不要かの指針も含めています。例えば、HTTP 503エラーは一時的なインフラ障害なのでコード修正は不要、一方でBigQueryのスキーマ不一致エラーはコード修正が必要、といった判断基準を明示しています。

Git操作のルール

ブランチは ai/* プレフィックスで作成すること、作業開始時は必ず master ブランチに戻って最新を取得することなど、Git操作のルールも含めています。

まとめ

「でんじろう」は、データエンジニアリング業務における定型的な作業をAIエージェントで自動化する取り組みです。

ポイントのまとめ

  • スキーマ変更対応やカラム追加など、定型的だが手間のかかる作業をターゲットに
  • データチームがボトルネックにならない体制を目指す
  • セキュリティと利便性のバランスが重要
    • ファイルアクセス、Git操作、BigQuery、dbt実行それぞれに適切な制限を設定
    • 特にGitHub Actionsワークフローへのアクセスは厳格に制限
  • システムプロンプトに社内ルールを埋め込み、規約に沿ったコード生成を実現

AIエージェントにデータパイプラインのコード修正やPR作成を任せるのは一見リスクが高そうですが、適切な制限を設けることで安全に運用できます。データエンジニアリング業務の作業効率化に興味のある方の参考になれば幸いです。

ミツモアで一緒に働きませんか？

ミツモアでは、生成AIを活用して圧倒的な生産性を生み出し、日本のGDPを向上させるという目標に向けて、一緒に働く仲間を募集しています。

今回ご紹介したように、AIエージェントを活用した業務自動化や、プロダクトへのAI組み込みなど、様々な領域で生成AIの活用が進んでいます。

一緒にスタートアップでデータ活用や生成AIアプリケーションの開発をしてみませんか？少しでも興味をお持ちの方は、カジュアル面談からでも大歓迎です。ぜひお気軽にご応募ください！

ミツモア採用ページをチェックする！