はじめに こんにちは。メルカリのAI Securityエンジニアの @hi120ki です。 メルカリでは、AI Agentサービス Devin を社内の複数チームに展開しています。Devinは自律的にコードの調査・作成・PR提出までをこなせるサービスですが、組織として運用するうえでは管理上の課題がいくつかあります。 本記事では AI Securityチーム がAI Agent Platformチームと協力し、Devin Enterprise APIを活用したカスタムTerraformプロバイダーと自動管理ツール群を自作しました。これにより、メンバーと権限の管理・シークレットローテーション・APIキーのライフサイクル管理・監査の仕組みを構築した取り組みについて紹介します。 Enterprise運用の課題 メルカリではDevinのEnterpriseプランを採用しています。Remote環境で動作するAI Agentを組織的に運用するためにOktaによるSSO、監査ログ、権限の管理、チームごとの環境分離が必須要件であり、これらを満たすために選定しました。 Devin EnterpriseではCoreプランやTeamプランのように1つのOrganizationを共有するのではなく、Enterpriseという管理基盤から複数のOrganizationを一元管理します。メルカリには複数のビジネス領域にまたがる多数のチームがあり、各チームが扱う情報を分離して保護する必要があります。そのためチームや目的に応じてOrganizationを割り当てています。 ただし、10以上のOrganizationと多数の利用者を抱える環境では、次の課題が生じます。 権限管理の課題 メンバーのOrganizationへのアサインが手動操作に依存 「誰がどのOrganizationに所属しているか」の状態管理が困難 シークレット管理の課題 各Organizationにサードパーティサービスごとの認証情報を個別に設定する必要 シークレットを手動で一斉ローテーションする手間 アクセス権の課題 Devin APIキーの有効期限管理が標準機能として提供されておらず、各Organization内に長期間未ローテーションのAPIキーが残存するリスク Devinの活用が広がるほど管理するOrganizationも増え、これらの課題の負担は拡大します。以前はWeb UIでの手作業に頼っていましたが、2025年末以降DevinがEnterprise向けAPIを v2 から v3 へ拡充したことで、ほとんどの管理操作をAPI経由で自動化できるようになりました。これを受け、Go言語とGitHub Actionsを用いた管理基盤を内製しています。 Devin APIの概要 Devinは v3 として 最新のEnterprise管理向けAPI を提供しています。Enterprise・Organization単位のMember・Role管理や、各OrganizationのSecret・Knowledgeを操作できます。v3 APIで以下の自動管理機能を実現しました。 カスタムTerraformプロバイダー シークレットの一斉ローテーション Google Cloudサービスアカウントキーのローテーション セキュリティ管理基盤との連携 APIキー管理のみ v2 API を使用しています。v2 APIでは複数OrganizationにまたがるAPIキーの作成・取得・削除が可能で、以下を実施しています。 利用者が発行したAPIキーの定期無効化 社内AgentのDevin Wiki利用向けAPIキー管理 これらのAPI仕様はREST形式のAPIとしてDevinの公式ドキュメントにリクエストおよびレスポンスの詳細な仕様とともにドキュメント化されており、一般的なREST APIクライアントを実装することでそれぞれの機能を呼び出すことができます。今回これらのREST APIクライアントは、メルカリ社内で広く用いられているGo言語を用いてそれぞれのAPIが関数に対応するように実装し再利用しやすいように整備しました。 以下の章からそれぞれの管理機能の詳細を紹介します。 1. カスタムTerraformプロバイダー 管理基盤の中核は、 Terraform Plugin Framework で構築したカスタムTerraformプロバイダーによるOrganizationおよびメンバー管理です。 メルカリではGoogle Cloudをはじめリソース管理にTerraformを広く利用しており、エンジニアが日常的に扱っている点から採用しました。DevinをInfrastructure as Codeで管理すると、メンバー追加や権限変更にPRレビューを挟める・Organizationやメンバーの状態をコードで把握できるようになります。公式のTerraformプロバイダーは現時点で提供されていないため自作しました。 利用者や管理者は各チーム用のOrganizationをTerraformで定義します。ACU(Agent Compute Unit)上限もここで設定し、チームごとの利用量を制御します。 max_cycle_acu_limit はOrganization全体のACU上限、 max_session_acu_limit は1セッションあたりの上限で、想定外のコスト超過を防ぎます。 resource "devin_organization" "mercari_example_team" { name = "mercari-example-team" max_cycle_acu_limit = 500 max_session_acu_limit = 250 } またメンバーのOrganizationへのアサインもTerraformで宣言的に管理します。 # メンバー定義（メールアドレスで参照） data "devin_member" "mercari_example_team" { for_each = toset([ "user-1@example.com", "user-2@example.com", "user-3@example.com", ]) email = each.value } # Organizationへのアサイン resource "devin_organization_member" "mercari_example_team" { for_each = data.devin_member.mercari_example_team user_id = each.value.user_id org_id = devin_organization.mercari_example_team.org_id org_role_id = "mercari_org_member" } Organizationの追加やACU上限の変更、メンバーの追加・削除は、Terraformコードの変更→PRレビュー→マージという通常の開発フローで行います。 terraform plan の出力で「誰がどのOrganizationに追加/削除されるか」が明確にわかり、意図しない権限変更を防げます。 このTerraformプロバイダーではDevin Knowledgeも管理できます。KnowledgeはDevinにおけるAgent Skillのような存在です。メルカリのDevin環境では各チームが別々のOrganizationに分かれており、互いの利用状況を閲覧できません。セキュリティ面では望ましい分離ですが、活用ノウハウの共有が難しくなります。Knowledgeをプロバイダーで管理できるようにし、チーム間での活用ノウハウの配布を可能にしました。 2. シークレットの一斉ローテーション DevinはSessionごとに独立した仮想マシンを起動するため、初期状態ではGitHub等ソースコード管理サービスへの権限しか持ちません。クラウド環境やチケット管理サービスなどへ接続するには、APIキー等の認証情報を個別に設定する必要があります。 一方、DevinはAI Agentとして与えられたAPIキーを自由に扱えるうえ、Organization内のメンバーはSession内部のファイルシステムやシェルにアクセスできるため認証情報の取り扱いには注意が必要です。そこでメルカリでは、Devinに設定するAPIキー群を管理者が一元管理し、短い間隔で定期ローテーションすることで、長期間有効な認証情報がDevin上に残らないようにしています。 ただし手動でのローテーションは負担が大きく、以前は多数のOrganizationの複数Secretをローテーションするだけでかなりの時間を要していました。しかしDevinが 2026年1月にSecret管理機能をv3 APIへ追加 したことで、これらの操作を自動化できるようになりました。現在のローテーション手順は以下のとおりです。 Devin管理者がそれぞれのサービスで認証情報をローテーションする 新しい認証情報を事前に作成済みのGoogle Cloud Secret Managerに追加する 自動化をGitHub Actions経由で起動する ローテーションが実行され、Secret Managerから各Organizationに配布される これにより、最小限の作業で10以上のOrganizationのシークレットを一斉ローテーションできるようになりました。 3. Google Cloudサービスアカウントキーのローテーション メルカリでは主にGoogle Cloudを利用しておりライブラリの取得やテスト環境との接続にはGoogle Cloudの権限をDevinに付与する必要があります。しかしDevinは現在 Workload Identity Federation に対応できるようなOIDCトークン発行機能がないため、サービスアカウントキーを用いる必要があります。 しかし前提として、メルカリでは Google Cloud公式のベストプラクティス に従い、Organization Policyでサービスアカウントキーの発行を一律禁止しています。このためDevin専用のGoogle Cloud Projectを設け、さらに iam.serviceAccountKeyExpiryHours を追加のOrganization Policyとして設定しました。これにより、自動化が停止した場合でもサービスアカウントキーは一定期間で無効化されます。 この仕組みのうえで、Organizationごとに個別のサービスアカウントキーを定期ローテーションしながら付与しています。 4. セキュリティ管理基盤との連携 Devin Enterprise採用の要件の一つに監査ログがあります。メルカリではAI Security および Threat Detection and Response チームのAnnaがDevin v3 APIを通じて 内製セキュリティ監視プラットフォーム との連携を構築しました。 この連携では、Admin権限を持つEnterprise Service Userと Enterprise Audit Logs エンドポイントを利用しています。これはv2 APIにおけるエンドポイントとは異なりページネーションがあるため、すべての監査ログを正確に取得することができます。これによりGoogle CloudのCloud Run Job を使って5分おきにAPIを取得し、前回取り込んだ最後の監査ログのタイムスタンプ以降の新規監査ログをすべて取得したうえでGoogle CloudのPubSubトピックへと転送しています。そして転送された監査ログはセキュリティ調査のためのBigQueryに保存されます。 5. 利用者が発行したAPIキーの定期無効化 Enterprise全体のAPIキーを全件取得し、作成から一定期間が経過したキーを自動で無効化します。Devinの標準機能にはないセキュリティポリシーを、APIで独自に実装しました。 これらのAPIキーは主に Devin MCP の接続に用いられます。APIキー経由で間接的にソースコードを取得できるため、厳格な管理が求められます。AI Agentを複数利用する開発環境では、使わなくなったAgentの設定ファイルに認証情報が残る・個人のAPIキーを複数人が利用する自作Agentに設定して社内公開してしまう、といった事態が起こりえます。 一定期間経過したAPIキーを自動無効化することで、利用中のAgentだけがAPIキーを保持する状態を維持し、複数人で共有するAgentには、次章で紹介するGoogle Cloud Secret Manager経由のAPIキーを利用させることで、Agentが持つ権限の可視化も実現しました。 6. 社内AgentのDevin Wiki利用向けAPIキー管理 メルカリでは各チームの開発用Organizationとは別に、Devin Wiki用のOrganizationを運用しています。Devin Wikiは Devin MCP 経由でリポジトリの内容を取得したり、自然言語で検索したりできます。 ソースコードの探索をAI Agentが直接行うとコンテキストを大量に消費します。ソースコード調査が必要な場面ではDevinに処理を委託することで、コンテキスト消費を抑えられます。 ただし Devin MCP の利用にはAPIキーが必要で、前章のとおり一定期間で自動無効化されます。例外となるAPIキーを設けることもできますが、目的外利用を完全には防げません。そこでAPIキーを短い間隔で定期的に再作成し、Google Cloud Secret Managerに保存する自動化を構築しました。 これにより、Devin MCPを利用するAI AgentのサービスアカウントをTerraform上で一元管理し利用状況を可視化するとともに、APIキーの定期再作成による目的外利用の防止も実現しました。 resource "google_secret_manager_secret" "shared_wiki_api_key" { secret_id = "shared-wiki-api-key" } resource "google_secret_manager_secret_iam_member" "shared_wiki_api_key" { for_each = toset(local.accessor_service_accounts_shared_wiki_api_key) secret_id = google_secret_manager_secret.shared_wiki_api_key.secret_id role = "roles/secretmanager.secretAccessor" member = "serviceAccount:${each.value}" } locals { accessor_service_accounts_shared_wiki_api_key = [ "agent-1@---.iam.gserviceaccount.com", "agent-2@---.iam.gserviceaccount.com", ] } 管理操作を動かすCIパイプライン これらの管理操作はすべてGitHub Actionsで自動化しています。SaaS管理向けに独自管理ツールを作る場合、長期的なメンテナンスが避けられません。組織変更時の引き継ぎも考慮すると、依存関係を小さく保ち、メンテナンスしやすい技術・プラットフォームを選ぶ必要があります。 Secret ManagerやサービスアカウントはGoogle Cloud上に置きつつも、処理の実行にはGitHub Actionsを選びました。リポジトリ内の自動化がデプロイなしで直接動作するためメンテナンスの手間が減り、不要なクラウドリソースを持たないことでコストと管理・引き継ぎ時の認知負荷も抑えられます。また定期実行に加え手動トリガー（ workflow_dispatch ）にも対応しており、緊急時のシークレットローテーションを即座に実行できます。 一方、GitHub Actionsは自由に実行できてしまうため、権限管理や ブランチ保護の設定 を厳格に行っています。認証情報の取得には Google Cloud Workload Identity Federation を使用し、GitHub ActionsからサービスアカウントやSecret Managerへ 安全にアクセス しています。 まとめ Devin Enterpriseを大規模に運用するにあたり、標準機能だけではカバーできない管理要件を、v2およびv3 APIを活用した自作ツールで補いました。これにより、これまで手作業に依存していた管理上の課題を克服し、多数のOrganizationを同時に提供しつつ適切に管理できるようになりました。 現在提供されているDevin v3 APIには、Enterprise管理に必要なエンドポイントが揃っています。今後は、Devinの機能拡張に合わせて、さまざまなリソースの管理を安全性を維持したまま自動化していく計画です。 また、この記事が、同様の課題を抱えている方の参考になれば幸いです。 メルカリでのAI/LLM活用やセキュリティに関する取り組みに興味がある方は、ぜひ メルカリの採用ページ をご覧ください。

はじめに Architecture Design Grp で エンジニア をしている大塚です。 New Relic Advance: Tokyoというイベントに参加してきました。 New Relicのこれからについて、さまざまな発表がありましたので、簡単にまとめさせていただきました。 今回はCEOなどの登壇もあり、見応えのあるイベントでした！ TL;DR New Relicが日本リージョン（国内データセンター）を追加予定で、データ保管要件とレイテンシ面でメリット 生成AI（Analyzer + MCPなど）でアラート調査の初動を短縮し、運用定着を加速する事例が紹介された New Relic Lensで外部DBやDWHなどにクエリし、NRQLで既存データと結合して分析できる イベント概要 日程：2026/03/12 16:00 ~ 18:00 会場：八芳園 全体の所感 New RelicのCEOなどが登壇するようなイベントで、今まで参加したイベントとは雰囲気がだいぶ違いました。 生成AI時代なので、AIの活用を加速させる内容が多かったです。 AI for New RelicとしてAIアシスタントやSRE Agentなどの紹介があり、インシデントなどの対応フローの自動化などが大きなトピックでした。 New Relic for AIとしてMCPの紹介や、ほかプラットフォームとの統合についての紹介もありました。 基調講演でもAIとNew Relicのデータを用いてインシデントやアラート対応を効率化させるという話があったので、BASEでも取り込んでいこうと感じました。 セッション / トピック 1) 日本リージョン追加！ newrelic.com 日本にNew RelicのDCを設立するというお話です。 セキュリティやプライバシー要件的にNew Relicに保存できなかった（海外リージョンのため）データも日本国内にデータが保存されるようになることで、より幅広いデータを集約することが可能になります。 レイテンシなどのパフォーマンスにも寄与するような大きなトピックでした。 2) 生成AIで加速させるNew RelicのEnabling speakerdeck.com blog.kinto-technologies.com New Relicを組織に浸透させるための取り組みにAIを組み合わせて、活用を加速させるというお話でした。 勉強会やドキュメントなどのコンテンツをいくら揃えても、それぞれのエンジニアにはそれぞれのタスクがあるので、時間を使って活用してもらうのは難しいという課題が挙げられていました。 New Relicを用いて、計装→検知→調査→解消までのサイクルは回せるようになるが、結局は人の目や手で対応をする必要があるので非効率という課題が残ってしまっていました。 その課題に対してNew Relic Analyzerという仕組み（AIによる分析）を導入することで、初期調査の時間が大幅に短縮され、MCPを用いた対話型にすることで日常業務への定着も進んだとのことでした。 BASEではアラートはSentryで調査はNewRelicという構造になっているので、現状を維持しても良いがNew Relicを活用できていない部分も大きいと感じました。 インシデントやアラートの対応サイクルを改めて見直し、AIを導入した新しい仕組みづくりをしてみても良いかもしれない。。。 3) New Relic Lens docs.newrelic.com New Relic外のデータソースに対してクエリを実行することが可能になりました。 クエリ結果に対してNRQLでNRDBのデータとjoinして分析・可視化できるようです。 現状対応しているのは以下 クラウド データ ウェアハウス : Snowflake 、 Redshift 、 ClickHouse リレーショナルデータベース : PostgreSQL 、 MySQL 、 SQL Server ドキュメントデータベース : MongoDB 、 Elasticsearch スプレッドシート : Google Sheets データレイク : Iceberg メトリクスと監視 : Prometheus 、 AWS CloudWatch BASEでの活用の今後の展望 アラート対応やインシデント対応の実態調査 New Relic Analyzer的な機能の実装が可能かどうか New Relic Lensを利用してNew RelicからMySQLのデータをクエリできるようにする（可能か？の調査から） 最後に 生成AIの活用が進む中で、アプリケーション監視についてもこれらの技術を用いる必要性を感じました。 今回のイベントの内容はBASEでも活用できる内容が多かったので、積極的に取り入れることで社内のAI Observabilityを向上させていきたいと思います。 こうした生成AIを活用した取り組みは各社行っていると思いますが、BASEでも積極的に開発やサービスに取り入れています。 binc.jp

1. はじめに こんにちは！NTTデータ ソリューション事業本部の@hua_wei_hanagiです。 近年、生成AIを活用したデータ分析の自動化ニーズが高まっています。 このニーズに応えるべく、ユーザーの追加指示を待たずに自ら考え、納得いくまで分析を繰り返してくれる「自律的に深掘りするデータ分析エージェント（以降、Deep Analysis型と呼ぶ）」の構想を設計しました。 しかし、これを実運用に乗せようとした際、「タスクの量が増えることに伴い、最終結果が出るまでの待ち時間が長大化してしまう」 というシステム上の大きな壁にぶつかりました。 そこで本記事では、 「Deep Analy