https://tech.classi.jp/entry/2025/12/22/070000

この記事は ADK Advent Calendar 2025 の 22日目の記事です。

こんにちは、データプラットフォームチームの白瀧です。

突然ですが、皆さんの会社の営業チームから、こんな悲鳴を聞いたことはありませんか？

「明日の訪問準備、データを見る時間が全然足りない……！」

Classiでは、学校現場へ訪問して先生方を支援する営業活動が日々行われています。しかし、1日に何校も訪問するスケジュールの中で、学校ごとの詳細なデータ分析を行い、それを資料に落とし込むのはかなり困難です。

今回は、そんな営業の課題を解決するために、「学校訪問時にそのままでも出せる活用レポートを生成するAI Agent」 をAgent Development Kit(以下、ADK)をベースに構築した話をします。

データはあるのに活用できないジレンマ

これまで営業向けのダッシュボードを用意し、営業チームと議論し拡充もしてきました。

しかし、現場としては以下のような状況でした。

訪問の合間の移動時間や、限られた準備時間の中で、ダッシュボードを深掘りしてインサイトを見つけ出し、営業資料にまとめる時間がなかなか作れない
新たなダッシュボードを提供しても、結局は使い慣れた「いつものダッシュボード」だけを確認して終わってしまう

結果として、本来提供できるはずの深いデータインサイトや、多角的な視点が学校に届かず、情報の幅が属人化・固定化してしまいます。これはプロダクトとしても、顧客である学校にとっても大きな機会損失になります。

そこでデータを見て、解釈をして、資料に落とし込むところまでAIを使って自動化してしまえば、営業の効率化と同時にデータを活用した営業による品質向上に貢献できるんじゃないかということから本プロジェクトが始まりました。

開発までの流れ

1. 良い営業資料を集め、品質を再現するための情報整理

まず最初に行ったのは「営業資料の理解」です。
社内で共有される良い営業資料を収集し、営業がどのような話の流れ・資料のフォーマット・文章の書きぶりをしているのかを理解するところから始めました。

全く新しい構成のレポートをAIが出力しても、営業担当者からすれば「見慣れない資料」となり、内容を理解して自分の言葉で話すためのコスト（認知負荷）が高くなってしまいます。そのため、既存の営業資料をフォーマットや構成を踏襲することで、営業担当者がスムーズに受け入れられる設計をベースにおきました。

2. 深掘り観点の策定

既存の再現だけでは、単なる省力化に留まります。そこで、「AIだからこそ出せる価値」を付加するために、レポートに含める独自の深掘り観点を検討しました。

これまで営業が「活用しきれていないデータ」、「解釈しきれていないデータ」は何か？
その中で、営業トークとして使いやすい（話しやすい）データはどれか？

この点については営業メンバーと議論を重ね、「このデータがあれば、先生ともっと深い会話ができる」というポイントを絞り込みました。

絞った観点に対して単にデータを羅列するだけでは意味がありません。

この機能でこのような活用ができています
この数字が上がっているのは良い傾向です
特に⚪︎年生でこの機能がしっかり使えています

といった、伝えたいメッセージやデータの解釈までを出力させることが営業現場で活用するハードルを下げ、価値につながると考えました。

3. フォーマット・図の確定と開発

ここまできたら、具体的な出力フォーマットや掲載するグラフ（図）の形式を固め、AI Agentの開発フェーズへと移行しました。

AI Agentの構成

システム全体の構成は以下で、

Agentの構成は以下のようにしました。

Root Agent
- 全体の進行管理役です。必要なSub Agentを呼び出し、Sub Agentの出力をまとめてレポート形式に整形することのみを行います。
Sub Agent (= Agent as a Tool)
- サマリー生成Agent: 必要なデータを取得し、指定されたフォーマットに従って文章を生成します。
- グラフ・表生成Agent: データの可視化グラフや表など、指定された画像を生成します。

この設計からもわかるようにレポートの構成を固定し、さらに各セクションの出力フォーマットも固定しています。

学校ごとにサービスの利用目的や利用傾向からAgentにレポートの構成から考えさせるという選択肢もありました。
今回は以下の利点から、フォーマットに固定して出力させることにしました。

Sub Agentを独立に実行できるようになり、容易にWorkflow化 & 並列処理による高速化が可能
どの学校で出力をしても同じフォーマットであることによる認知負荷の低減

AIにSQLを生成させない選択

今回の活用ユースケースとして、レポートをそのまま学校に持っていくことを想定しています。そのため、「他校のデータが混ざる」ということは強く避けるような設計が求められました。

生成させるレポートのフォーマットを確定させたことで幅広くデータを取得する重要性が高くないことから「AIにSQLを書かせない」という選択を取りました。

具体的にはSub AgentがFunction Toolでデータを取得する際、SQL自体を生成させるのではなく、事前に人間が検証した安全なSQLテンプレートを用意し、「学校ID」の部分のみを可変にする実装にしています。これにより、ハルシネーションによる誤ったデータ抽出のリスクを排除しました。

また、データの正確性だけでなく、レポートとしての品質や文脈の適切さを担保するために、生成されたレポートは必ず営業担当者が内容を確認・微調整した上で学校へ提出する運用としています。

実際のコードイメージは以下の通りです。

def get_wau(
    start_date: str,
    end_date: str,
    school_id: str,
) -> dict:
    """特定の学校について、所定の期間内の週次アクティブユーザ数（WAU）を取得します。

    結果はdictionary形式で返され、各キーの説明は field_definitions に含まれます。
    Args:
        start_date (str): The start date in YYYY-MM-DD format.
        end_date (str): The end date in YYYY-MM-DD format.
        school_id (str): The school identifier.
    Returns:
        dict: A dictionary containing WAU data and metadata.
    """
    if not start_date or not end_date or not school_id:
        raise ValueError("start_date, end_date, and school_id must be provided.")

    client, project_id = get_client()
    query = f"""
    select
        format_date("%Y-%m-%d", target_week) as target_week,
        user_type_name,
        grade_name,
        function_name,
        wau,
        wau_rate
    from `{project_id}.<dataset_id>.wau`
    where
        target_week >= "{start_date}"
        and target_week <= "{end_date}"
        and school_id = {school_id}
    order by
        target_week,
        user_type_id,
        grade_code,
        function_name
    """
    data = execute_query(client, project_id, query)
    meta = {
        "target_week": {
            "type": "string",
            "description": "対象週の開始日（YYYY-MM-DD形式）",
        },
        "user_type_name": {
            "type": "string",
            "description": "ユーザ種別名（例: 先生、生徒、保護者）",
        },
        "grade_code": {
            "type": "string",
            "description": "学年名",
        },
        "function_name": {
            "type": "string",
            "description": "機能名",
        },
        "wau": {"type": "integer", "description": "週あたりのアクティブユーザ数"},
        "wau_rate": {
            "type": "float",
            "description": "週あたりのアクティブユーザ率（登録ユーザ数に対する割合）。0から1の範囲で表現される",
        },
    }
    result = {"wau": {"data": data, "field_definitions": meta}}
    return result

成果と気づき

これまでのダッシュボード提供とは一線を画し、営業担当者から素早い活用と非常にポジティブな反応を得ることができました。

特に顕著な成果として、リリースからわずか1ヶ月という短期間で、契約校全体のうち約21%にあたる学校に対して、活用状況レポートが生成されました。これは、ツールの導入・活用を促す上での高いニーズと、AI Agentが提供する価値が即座に受け入れられたと感じています。

営業担当者からは以下のような具体的な声が寄せられました。

またレポートが使われた結果、以下のような学校での動きもありました。

活用レポートを受けて、学年通信に「学習トレーニング機能に取り組んで伸びた」という記載を載せていただいた
活用計画を先生と一緒に立て、活用後に再度レポートを出力して、振り返りをするサイクルの確立

上記の成果から本施策は、営業活動の効率化だけでなく、その先の学校への影響・変化をもたらした事例を作ることができたことが、最も大きな成果だったと思います。

レポート形式が持つ付加価値

今回の開発を通じて、ダッシュボードでは伝えきれない、より詳細で深い情報をレポートというテキストベースでは提供できるという気づきを得ました。

ダッシュボードは、情報を一目で理解しやすくするために、データのビジュアライズが不可欠です。しかし、このビジュアライズの過程で、意図的に情報量を絞り込んだり、データの背後にある文脈や詳細なニュアンスを省略したりすることがあります。これは、解釈の容易さを優先する上でのトレードオフです。

それに対し、テキスト形式を用いることで、単なるデータや結果だけでなく、そのデータが何を意味するのか、どのような解釈が導き出されるのかという点まで踏み込んで記述できます。これにより、ユーザーは情報を受け取るだけでなく、その情報の価値や次に取るべきアクションの示唆までをダイレクトに、かつ明確に受け取ることが可能になります。
この「解釈を与える」機能こそが、テキストがダッシュボードを補完し、時にはそれを超える価値を提供できると認識しました。

おわりに

今回は、活用状況のレポート生成により営業の資料作成を効率化するAI Agentについてご紹介しました。

営業との密な連携こそが今回の成果につながったと思っています。現場の営業担当者が必要としている情報が何であるかを深く掘り下げ、継続的にフィードバックの収集と改修を繰り返しました。

その結果、多忙な営業担当者が迅速かつ的確にアクションを起こすために有効なツールとなり、これまで「お決まりのダッシュボード」しか見ていなかった状態から、AIが自動的かつ親切に多角的な視点を提供することで、データ活用の水準が底上げされたと考えています。

現状のAI Agentはまだまだ開発初期段階だと思っています。生成したレポートをベースにした「対話的な修正機能」や、より高度な「学校ごとのパーソナライズされたレポートの生成」などにも挑戦し、営業担当者がより本質的な課題解決に時間を使えるようサポートしていきたいと思います。