Grabがアナリストの単純作業を44%→30%に削減 — AIエージェントに「どこまで任せるか」を5段階で設計する

8月17日、Leela Kumiliが「Grab Cuts Mechanical Analytics Work From 44% to 30% with AI Agents」と題した記事を公開した。Grabは東南アジア全域でライドシェア・フード・決済などを展開するスーパーアプリであり、数億人規模のユーザーデータを日常的に処理するアナリティクス組織を抱える。そうした規模の企業がAIエージェントによる業務自動化で具体的な成果を数値で示した点は、データ民主化を模索する多くの企業にとって示唆に富む事例だ。本記事では、Grabがアナリティクス業務にAIエージェントを導入し、アナリストが担う機械的作業の比率を大幅に削減した取り組みを紹介する。

機械的作業の比率が44%から30%へ

Grabは、自然言語でのアナリティクスリクエストを処理するAIエージェントシステム「Spartan」を中心に、分析業務の自動化を進めている。その結果、アナリストが処理する機械的なチケット（データ準備・アラート・レポーティングなど）の割合が、**2月の44%から6月には30%**まで下がった。

同時に、人手を介さずに回答できるセルフサービスアナリティクスの比率も改善している。3月から5月にかけて、

メトリクスリクエスト：53% → 67%
データ抽出：63% → 90%
SQLリクエスト：50% → 81%

へと伸びた。スレッド全体の約75%はアナリティクスチーム外から発生しており、85%は1分以内に初回レスポンスが返っている。

単純作業の削減は、アナリスト自身がより付加価値の高い業務——因果推論やビジネス意思決定の支援——に集中するための余白を生む。この点は、MetaやAirbnbが推進してきたデータ民主化の思想とも共鳴するが、Grabの取り組みが際立つのは「エージェントへの委任度合い」を段階的に定義し、設計として明文化した点にある。

5段階の自律性モデルで人間の関与を設計する

Grabのアプローチの核心は、「エージェントにどこまで任せるか」を明確に定義した5段階の自律性モデルだ。元記事ではLevel 3〜5が中心的に解説されており、以下がその内容となる。

Level 3：人間が問いを立て、結果をレビュー。エージェントがデータ探索・クエリ実行・バリデーション・分析ドラフトを担う
Level 4：エージェントがワークフローの計画とオーケストレーションを担い、人間は定義済みのゲートをレビュー
Level 5：エンドツーエンドの自律処理。人間は目標・品質閾値・エスカレーションルールの設定のみ

Grabは現在も、メトリクスの定義・因果解釈・ビジネス上の前提・最終意思決定については人間が責任を持つ設計を維持している。

この設計の優れた点は、自律性の拡張を「技術的に可能か」ではなく「人間の関与をどの粒度で残すか」という観点で整理していることだ。LLMエージェントが誤った推論を行うリスクを踏まえると、委任範囲を業務の性質ごとに段階的に管理するこのアプローチは、Text-to-SQLやLLMエージェントのオーケストレーションを本番導入する際の実践的な指針として機能する。

Grabでアナリティクスを統括するMaanas Prabhakarは、LinkedInの投稿でこう述べている。

エージェントがデータ準備・分析・その他すべてを処理するようになったとき、アナリストは何をするのか。それが本質的な問いだ。

Spartanシステムの設計：50以上のスキルと120の分析フレームワーク

SpartanはSlack経由で送られた自然言語の質問を受け付け、50以上のスキルと120の分析フレームワークを使って専門ワークフローにルーティングする。

たとえば根本原因を問う質問であれば、認定済みメトリクスと関連ディメンションをまたいだ分析を実行する。実験に関する質問であれば、データレイクへのクエリを発行せず既存のスコアカードを取得する、といった最適化も行われている。

ナレッジベース全体のインデックスアーキテクチャ（出典: Grab Engineering Blog）

信頼性を支えるデータ基盤：5,000の認定テーブルとContextIQ

エージェントが信頼できる結果を出すには、データそのものの品質管理が不可欠だ。Grabは5,000以上の認定済みテーブル・メトリクス、4,000のコンテキストドキュメント、2,000のゴールデンレコードを整備している。

「ContextIQ」と呼ばれるシステムがこのコンテキスト情報をライフサイクルとして管理し、インストルメンテーションの変更に合わせてコンテキストを更新するほか、本番環境でのエージェント障害から得られた修正内容も反映する設計になっている。

この仕組みは、エージェントの精度がデータ基盤の整備水準に直結することを示している。どれだけ高性能なLLMを使っても、参照するコンテキストが古かったり不整合であれば回答品質は下がる。ContextIQが障害から学習してコンテキストを更新し続ける点は、運用フェーズにおけるエージェントの維持管理コストを下げる上で重要な設計判断といえる。

パイプライン障害の自動対応：Scarletエージェント

アナリティクス運用面では、「Scarlet」というエージェントがパイプライン障害に対応する。Scarletは根本原因分析を実行し、事前定義されたゲートやランブックで対処できる場合は自動修復を、そうでない場合はエスカレーションを行う。

Slack上でScarletが動作している様子（出典: Grab Engineering Blog）

定期的なアナリティクスでは、メトリクスやOKRの所感を自動生成するエージェントも稼働しており、国別・セグメント別の動向把握や、運用上の変化・実験との相関分析をこなす。

アナリティクスワークフローの開発基盤「BriX」については、元記事において「9月以降で利用が10倍以上に伸びた」と記述されているが、比較基準となる時点の詳細は元記事中で明示されていない。上半期だけで本番デプロイ31件・マージリクエスト283件・機能追加60件を記録したとされており、開発活動の活発さは数字からも読み取れる。

詳細はGrab Cuts Mechanical Analytics Work From 44% to 30% with AI Agentsを参照していただきたい。