Bitrise の MCP を接続したエージェントを導入し、非エンジニアによるビルドエラーの自己解決を支援

弊社では 900 以上のアプリをひとつのコードベースから作成しており、それらのアプリは Bitrise を用いてビルドしています。
ビルドの実行を支援する Slack App を利用して専門の申請チームがアプリのビルド作業を担当してくださっています。
ビルドに必要なアプリ固有の情報は管理画面から取得していますが、事前の情報登録が漏れていたり、App Store Connect API の変更や App Store Connect の障害によって予期せぬビルドエラーが発生することがあり、その度に iOS エンジニアにエスカレーションをいただくフローとなっていました。

意図していないビルドエラーを申請チームが自己解決できる状態を作ることはできないかと考え、非エンジニアでも利用しやすい Slack App として Bitrise MCP に接続した AI エージェントを導入しようと思ったのが背景です。

ビルドエラー時には JIRA のチケットと Slack にエラーログとビルド URL が自動でコメントされます。その URL をそのまま AI エージェントにメンションすることで、Bitrise MCP を通してエラーログを取得し、解決手段を回答してくれるようになりました。

より詳細については、Bitrise MCP と Atlassian MCP を接続した自律型の AI エージェントを実装して、非エンジニアによるビルドエラーの自己解決を支援する｜Yappli Tech Blog をご覧ください。

非エンジニアの利用を想定していたということもあり、ネクストアクションが分からない回答を返さず、的確かつ要求を満たすような回答を得られる体験を実現するために、LangGraph における StateGraph の構築とプロンプトエンジニアリングは少し苦労しました。
　
自律性を持たせるための「推論 → 計画 → 実行 → 評価」のループを取り入れつつ、各プロンプトを調整しながら検証を繰り返して改良しました。 また、それらの各ノード間で共有する State はグラフの規模が大きくなるにつれて複雑化するため、State の設計も重要で、周辺知識の理解も難しかったです。

モバイルで CI/CD を導入する場合は、まず候補に挙がるツールだと思います。 GUI で視覚的にワークフローを構築しやすかったり、他のツール同様に yml 形式でバージョン管理も行えます。
　
また、記事で紹介した AI エージェントについては、当初はフレームワークもそこまで種類はなかったこともあり、LangGraph を利用した実装を行いました。しかし今現在では ADK など GCP や Gemini との連携がしやすいフレームワークがリリースされていたり選択肢にも幅があるため、実現したい複雑度や周辺ツールとの相性を見ながら選択するのがいいと思います。

弊社の複雑なビルドに関わる各ジョブを分解し、Bitrise 含め AI による自律的なオーケストレーションが可能な環境を目指していきたいです。