ENECHANGE株式会社は2026年1月29日に、オンラインイベント「【Sansan × LayerX × ENECHANGE】運用と開発を進化させるAIの実践事例」を開催いたしました。
開発や運用の現場では、プロダクトの価値に直結する作業とは別に、環境構築やオンボーディング、アラート対応、初期調査といった「避けられないが、付加価値を生みにくい作業」が日々発生します。本イベントでは、AIエージェントをこうした作業の“担い手”として組み込み、業務を再設計するためのノウハウを各社のエンジニアが紹介しました。
本記事では、イベントの内容をレポートします。
「使いにくい」の壁を突破する — 社内開発基盤のオンボーディングを対話で完結させるAIエージェント
Sansan株式会社 技術本部 Platform Engineering Unit Application Platformグループ 辻田美咲氏
Sansan株式会社の辻田氏が、社内基盤「Orbit」の利用促進事例について解説しました。「Orbit」は、社内の開発者がプロダクト開発に専念できる時間を最大化することを目的に構築された、コンテナアプリケーションの実行基盤です。GKE Autopilotを中核技術として採用しており、CI/CD、監視、セキュリティ、ネットワーク設定などの機能を統合的に提供します。
「Orbit」ではこれまで開発者の負担軽減に向けて工夫を凝らしてきましたが、すべての作業を自動化できているわけではなく、依然として多くの手作業が残っていました。複数リポジトリを横断する作業が必要なため、リポジトリ間のコンテキストスイッチと手作業の組み合わせが、使いづらさの要因となっていました。
特に課題となっていたのが、初期構築などのオンボーディング工程です。「Orbit」の機能開発・提供だけでは解消できない「使いにくさの壁」に直面していました。
その壁を突破するために、辻田氏のグループが開発したのが「Orbit AI Agent」です。開発者が本来の業務にDay 1から集中できる環境を構築すること、そして複数リポジトリにまたがる作業の入り口を一本化することを目指しています。
特徴は2点あります。1つ目は、自然言語で指示するだけで、AIが煩雑な作業を一括で代行すること。2つ目は、開発者が好きなタイミングで必要な情報にたどり着き、スムーズにキャッチアップできるよう、ドキュメントに基づく対話型のQ&Aを提供していることです。
続いて、技術的な構成について解説がありました。エージェントの開発には、GoogleのAgent Development Kit（ADK）を使用しています。辻田氏のグループではインフラにGoogle Cloudを採用しているため、親和性の高いADKを選定しました。
モデルはGemini 3 Flash Previewを使用。フロントエンドにはエージェント機能をアプリケーションへ容易に組み込めるフレームワークCopilotKitを採用し、エージェントとの通信にはAG-UIプロトコルを用いています。
Vertex AI Agent Engineでエージェントのセッション管理を行い、Vertex AI Searchによるグラウンディングで、ドキュメントに基づいた正確な回答ができるよう設計されています。
基盤に関するドキュメントはGitHubで管理しており、更新タイミングでGoogle Cloud Storage（GCS）へアップロードし、Vertex AI Searchのデータストアと同期するパイプラインを構築しました。エージェントはマルチエージェント形式を採用しており、親エージェントがユーザーの意図を判断し、適切な子エージェントへタスクを振り分ける仕組みです。
「Orbit AI Agent」の導入効果として、開発者からは「心理的ストレスが低減した」という声が上がっています。今後はオンボーディング完了までの平均時間や、プラットフォームチームへの問い合わせ件数など、定量的な指標の計測も進めていく予定だといいます。
最後に、辻田氏は「AIエージェントはすべてを解決する銀の弾丸ではありませんが、従来のCLIやドキュメントだけでは実現できなかった『体験』を変える力があると感じています。開発者が覚える必要のない手順を対話によって隠蔽し、本質的な価値創造に集中できる環境をこれからも目指していきます」と結びました。
システムのアラート調査をサポートするAI Agentの紹介
株式会社LayerX バクラク事業部 Platform Engineering部 SREグループ 多田貞剛氏
株式会社LayerXの多田氏は、同社が展開するAI-SaaS「バクラク」の運用における、生成AIエージェントを活用したアラート対応の調査支援について発表しました。
多田氏はまず、取り組みの背景にあるアーキテクチャの複雑性に言及しました。現在「バクラク」では、100を超えるマイクロサービスがAmazon ECS on Fargate上で稼働しており、フロントエンドからのリクエストはGraphQL Gatewayを経由して各サービスと通信する、API Gatewayパターンを採用しています。
プロダクト間連携が多岐にわたるため、異常発生時には複数サービスの依存関係を紐解きながら、バックエンドとフロントエンド双方のログやメトリクスを追う必要があります。習熟したエンジニアであれば既存の知識を動員して対応できますが、新しくチームに加わったメンバーにとっては、システム構成の把握に対する学習コストが高いものとなっています。
SREとして、こうした学習コストを低減し、プロダクトチームが自律的に調査・修正を行える支援体制を構築していきたいと考えていました。そこで検討されたのが、アラート調査における定型的なアクションを自動化するAIエージェントの導入です。
開発の大きな転換点となったのは、社内で開催された「AIエージェント祭」というハッカソンでした。多田氏は、AIエージェントSDKであるStrands AgentsやAmazon Bedrock AgentCoreを使い、Amazon CloudWatchからメトリクスの推移を調査するプロトタイプを制作しました。この成果をベースに改良を重ね、現在のシステム調査エージェントへと進化させたといいます。
技術スタックにはPythonとパッケージ管理ツールのuvを採用し、メインモデルにはClaude Sonnet 4.5を使用しています。特筆すべきはModel Context Protocol（MCP）を導入し、Datadog、Amazon CloudWatch、そしてAWSのトラブルシューティング情報を集約したドキュメントサーバーという、3つの異なるデータソースを統合した点です。この構成により、エージェントが複数の専門的なソースから情報を引き出し、人間のように思考して回答を導き出す仕組みを構築しました。
実装で考慮した点として、多田氏は3つ挙げました。
1つ目は、エージェントの責務を明確にするための役割分割です。調査計画を策定し最終レポートをまとめる「統括エージェント」を司令塔とし、そこから各MCPサーバーへ専門的な調査依頼を投げる構造にすることで、将来的なエージェントの追加を容易にしました。
2つ目は、トークン管理の最適化です。複雑な調査ほど入力トークン数が増大し、Amazon Bedrockの制限値に抵触する恐れがあるため、コード側での最大トークン制限とプロンプトによる効率化を徹底しました。
3つ目は、調査レポートにおけるタイムウィンドウの統一です。開発初期は、エージェントに対して時刻に関するコンテキストを与えておらず調査対象期間にばらつきが生じていたため、プロンプトによる指示に加え、Strands Agentsのtoolsを用いて時刻を取得・指定する仕組みを取り入れました。
発表時点の動作イメージとして、ユーザーがSlackから調査依頼を行うと、エージェントは状況を読み取って調査計画を立て、各種MCPサーバーを通じて情報を収集・分析し、その結果を要約してSlackに投稿します。現在はPoC（概念実証）の段階ですが、今後はこのツールをプロダクトチーム全体が利用できる状態にすることを目指しています。
さらに将来的には、現状の「調査と提案」から一歩踏み込み、実際のコード修正やデプロイといったアクションまでを自律的に実行できるエージェントへと進化させたいという構想を語り、発表を締めくくりました。
Claude Code GitHub Actionsを活用したアラート初期分析の自動化を目指す！
ENECHANGE株式会社 プロダクト開発統括部 システム開発部 EV Devチーム 片田優太
ENECHANGE株式会社の片田は、Claude CodeとGitHub Actionsを組み合わせ、モバイルアプリの開発・運用におけるアラート対応を自動化した事例について解説しました。
当社では従来、モバイルアプリのエラー検知にSentryを活用し、アラート発生時にSlackへ通知が届く仕組みを運用していました。通知を確認したメンバーが手動で調査を開始し、結果を報告して必要に応じて修正を行うという、一般的なフローでした。
片田はまず、この初期分析の効率化と属人化の排除に着手しました。第一段階として導入したのは、全エンジニアに配布されているClaude Codeを使い、ローカル環境でエラー解析用のスラッシュコマンドを実行する運用です。このコマンドにはSentry MCPが組み込まれており、エンジニアが手元で素早く調査結果を得られる環境を整えました。
しかし、運用を続ける中で新たな課題に直面しました。特に大きかったのは「共有の壁」です。調査結果は実行者のローカル環境にしか残らないため、知見をチーム全体に還元できるかどうかは個人の裁量に依存していました。
また、生成AIのハルシネーションに気づきにくいリスクや、URL・調査結果のコピー＆ペースト、解析を待つ時間なども、現場のストレスとなっていました。これらの課題を解決するため、片田は「分析プロセスの完全自動化」へと舵を切りました。
解決の鍵となったのが、Claude Codeの新機能であるGitHub Actionsとの連携です。これはGitHub上のプルリクエストやIssueでAIと対話できるだけでなく、ワークフローの一部としてAIを自律的に動作させることができる機能です。公式リポジトリのサンプルから着想を得て、アラート調査の完全自動化を構想しました。
新しく構築したアーキテクチャでは、Sentryでアラートが発生するとWebhookが送信され、それをAWS Lambdaが受けてGitHub Actionsを起動する構成を採用しました。GitHub Actions内ではClaude Codeが呼び出され、Sentry MCPを介してエラーの詳細を直接取得・分析します。
モデルには高い解析能力を持つClaude Sonnet 4.5を採用し、分析レポートをSlackへ直接投稿する仕組みを整えました。これにより、エンジニアが介在することなく、アラート通知の直後にAIによる詳細な分析結果が届く環境を実現しました。
実装における技術的な工夫として、片田は「制御」の重要性を強調しました。GitHub Actions上のYAMLファイルでは、トークンの過剰消費を防ぐために「max_turns」設定を用いてAIとのやり取りを制限。また、Sentry MCPの多機能さが調査の迷いを生む原因となったため、「allowed_tools」オプションでAIが実行可能なツールを明示的に制限し、回答精度の向上を図りました。
さらに、Webhookからは直接取得できないURLなどの情報については、組織名やイベントIDといった限られた情報から、MCPサーバーを介してAIが自律的にコンテキストを補完するプロンプトを構築しました。
この自動化の導入により、調査結果の即時共有が可能となり、属人化の問題は劇的に解消されました。アラートから次のアクションへの移行がスムーズになっただけでなく、GitHub Actions上で実行することで、特定のリリースブランチやリポジトリ内のコード情報を参照した深い分析が可能になったことも大きな成果です。最後に今後の展望を語り、発表を締めくくりました。
おわりに
3社の発表を通じて、AIエージェントが開発者体験を向上させ、業務を劇的に改善する可能性が示されました。ENECHANGEは今後も、開発組織の方々を対象としたイベントを積極的に開催してまいります。次回のイベントも、ぜひお楽しみに。
