Slide 1

Slide 1 text

メンバー育成支援のためのデータ前処理とAIエージェント TohokuTech #8 / 2026.03.19 クラスメソッドオペレーションズ株式会社 金子 拓矢

Slide 2

Slide 2 text

リモートワーク中心の環境で、メンバーの育成状況が見えにくいとい う課題がありました 散在するデータを Amazon Bedrock で収集・構造化し、業務固有の コンテキストを添えて分析することで、育成状況の見える化に取り組 みました 生成 AI に渡すコンテキストを丁寧に整備することの大切さを、試行 錯誤も含めて共有します メンバー育成支援のためのデータ前処理とAIエージェント 2

Slide 3

Slide 3 text

名前: 金子 拓矢 出身・在住: 埼玉県出身・山形県在住 組織: 「クラスメソッドメンバーズ」ご契約のお客様からの、AWS利用 に関する技術的なお問い合わせ(仕様確認、障害復旧等)に対応 経歴/現在: アプリ開発→AWSテクサポ→育成チームリーダー・AI活用推進 資格: AIP取りました 自己紹介 しらこばとのポーズ モコ 10歳 3

Slide 4

Slide 4 text

新卒・中途メンバーの初期配属先。OJTを通じて育成し、各 専門チームへ配属するまでを支援 メンバー: 問い合わせ対応を実践で学ぶ トレーナー(育成担当者): 回答案をSlack上でレビュー し、フィードバックで業務理解を支援 リーダー(自身): 週次1on1で目標と課題の伴走 リモートワーク中心で勤務 Generalチーム:育成の3層構造 4

Slide 5

Slide 5 text

背景と課題 フルリモート × 育成で感じていた壁

Slide 6

Slide 6 text

成果物の散在: 育成状況に関する情報が Slack・Google Docs・Sheets・Meet 等に分散。横断 的に把握するには認知負荷が高い 状況把握の属人化: 1on1 準備にメンバー 1 人あたり 15〜30 分。トレーナーも自分が対応した レビュー以外は把握しにくい 増員に対するスケーラビリティ: メンバー・トレーナー双方の増員が見込まれる中、リーダーがボ トルネックになり一人ひとりに十分な時間を確保できなくなる危機感 フルリモート × 育成における3つの壁 6

Slide 7

Slide 7 text

チャット AI に都度聞くだけでは横断的なデータの蓄積・分析はでき ず、BI ツールでは自然言語の意味理解が難しい。そこでデータパイプラ インを自作するアプローチを選んだ Claude Code の登場で、開発が本務でなくても手を動かせる敷居に なっていた 散在するデータを自動収集し、業務固有のコンテキストを整備して生 成 AI に渡す仕組みを構築 まずコードを書く前に、組織情報や育成モデルを整理し、生成 AI と 壁打ちしながら要件定義するところから始めた どう解決しようとしたか 7

Slide 8

Slide 8 text

データパイプライン 散在するデータを収集・構造化・分析する仕組み

Slide 9

Slide 9 text

複数データソースからデータを取得、LLMで構造化・分析し、S3に蓄積 AIパイプライン構成図 9

Slide 10

Slide 10 text

LLMを使わない 表形式データや機械的な突合が 可能なデータ Google Sheets 等の表形式 データ 計算・集約・突合などの機械 的処理 → 確実・低コスト LLMに任せる (Claude Haiku) 構造が不定な自然言語テキスト トレーナーとのやり取り 振り返り資料 会議メモ → 柔軟・意味理解 使い分けのポイント 全てをLLMに任せない 表形式で構造化できるものは プログラムで確実に処理 LLMは構造が不定なテキスト だけに使う → コストと精度の両立に効いて くる 前処理の工夫:LLMに頼る部分と頼らない部分 10

Slide 11

Slide 11 text

コンテキストの整備 生成 AI に渡す「前提」が分析精度を左右した

Slide 12

Slide 12 text

同じ「今週の対応件数が少なかった」でも、難 易度の高い問い合わせにじっくり取り組んでい たのか、次に何を着手するか決めきれずに時間 が過ぎたのかでは意味が全く違う しかし件数だけを渡しても、その背景までは読 み取ってもらえない 最初はデータをそのまま渡したが、出てくる分 析は表面的で「うちのチームはそうじゃないん だよな⋯」というものだった → 業務固有のコンテキストを丁寧に整備する取 り組みに注力するようになった コンテキストが必要だった理由 12

Slide 13

Slide 13 text

メンバー情報のコンテキスト: 在籍期間に応じ たステージ判定(ステージごとに評価の目線を 調整) 、新卒/中途の種別、配属目標日 業務のコンテキスト: 問い合わせの定型/非定型 分類、対応サービスの多様性、レビューのやり 取りの密度、フィードバックの方針面/形式面 の区分 育成のコンテキスト: 習熟度チェックリストの 進捗、過去のフィードバック傾向、前週の分析 結果、ローリングサマリー(長期コンテキスト の圧縮) AIに渡す3層のコンテキスト 13

Slide 14

Slide 14 text

コンテキストなし(素のLLM) 「あるメンバーの対応に時間がかかっている。  アドバイスの例を提示して」と質問 汎用的な確認ポイントを列挙(技術知識?調査 方法?文章作成?) アドバイスは一般論(ハンズオン、テンプレー ト整備) 「特定の状況があれば具体的に…」→ コンテ キスト不足を生成 AI 自身が示唆 コンテキストあり(本システム) 同じ質問 対応実績から定量的に現状を把握 振り返りデータから行動面の課題を特定 過去の好調だった週と比較し具体的な改善アプ ローチを提案 複数のデータソースを横断して課題の構造を読 み解いた助言 コンテキストの有無による出力の違い(※サンプル) 14

Slide 15

Slide 15 text

分析と可視化 スコアリング・ダッシュボード・AIエージェント

Slide 16

Slide 16 text

コンテキストを整備してデータの意味が伝わるようになっても、評価の軸がなければ生成の度に結 果がブレる。そこで、リーダーやトレーナーが育成判断の際に重視していた観点を言語化し、5 つ の軸としてプロンプトに組み込んだ 軸 観点 技術領域の広がり 慣れた対応にとどまらず、未知の領域にも踏み出せているか 対応の安定性 ステージに見合ったペースで安定的に対応できているか 自律性 トレーナーの指導なしに方針を立案・実行できているか 課題認識 自身の課題を認識し、改善行動に移せているか レビュー依頼の質 レビュー依頼時の情報整理度・顧客課題の理解度 「自律性」の例: レビューのやり取りの密度 × フィードバック内容が方針面か形式面かで判定 5軸スコアリングと「自律性」の数値化 16

Slide 17

Slide 17 text

工夫 1〜5点の判定基準を評価基準表としてプロンプト内に明記 全スコアにデータ根拠の明記を必須化 在籍期間や成長段階に応じて評価の目線を調整 JSON Schema(Structured Outputs)で出力を厳密に定義 課題 同一入力でもLLMの判定にはブレがある(Temperature 0.0等で抑制するが完全ではない) データが少ない週はスコアの確度が下がるため、判定を控えめにする処理を追加 改善サイクル: 毎週の分析結果を自分で確認し、ズレを感じたらプロンプトにフィードバック。 Bedrock Prompt Management で再デプロイなしに更新 プロンプト設計の工夫と試行錯誤 17

Slide 18

Slide 18 text

分析したデータを可視化しつつ、AgentCore製エージェントで対話型のUIを実装 ロギングやモニタリング、CI/CD 関連のリソースは省略 AIダッシュボード構成図 18

Slide 19

Slide 19 text

ダッシュボード: 状況サマリー、レーダーチャート、スコ ア推移グラフ等で分析結果を可視化。元データページから ワンクリックで根拠に遡れる設計 AIエージェント: パイプラインの成果を対話形式で引き出 す。 「〇〇さんの1on1ブリーフィングをお願い」で統合報 告を生成 向き合い方: あくまで判断支援の補助ツール。スコアはメ ンバーの評価に直結せず、最終判断は人間が行う ダッシュボードとAIエージェント ダッシュボード AIエージェント 19

Slide 20

Slide 20 text

Claude Code(Maxプラン / Opus)を活用して実装。開発期間は約1 ヶ月 コンポーネント 期間 項目 月額コスト パイプライン 約2週間 Bedrock推論 ~$40 ダッシュボード 約1週間 インフラ(Lambda, EC2等) ~$5 AIエージェント 約1週間 Claude Max(開発用) $100 ← 一番重い 開発工数とランニングコスト 20

Slide 21

Slide 21 text

定量 指標 Before After 1on1 準備時間 15-30分/人 5-10分/人 (約60%短縮) メンバー状況の把握 週次 1on1 時点 日次〜週次で随時 情報参照 各ツールを個別に確認 ダッシュボード 1 画面 トレーナー間の共有 週次定例で口頭共有 ダッシュボードで随時 定性 件数だけでなく、対応の質や挑戦の幅まで追跡できるようになった 感覚ベースからデータを見ながらの議論に変わった 分析結果と根拠がセットで表示されるため、安心感を持って参照できるとトレーナーから好評 効果 21

Slide 22

Slide 22 text

1. まず材料を揃える LLMに頼る部分と頼らない部分を見極める。全てを LLM に任せず、表形式データはプログラム で確実に処理 2. 生成 AI にはコンテキストを丁寧に渡す 生データだけでは表面的な分析にしかならなかった。業務固有のコンテキストの整備が分析精度 を大きく左右した 3. 生成 AI は育成を代替しない、育成を支援する 生成 AI がデータの収集・整理・分析を担い、人間は判断・対話・関係構築に集中する 散在する情報を集め、ドメイン固有のコンテキストを添えて生成 AI に渡すという進め方は、育成に 限らず参考になるかもしれません ブログ記事もご覧ください! 「生成AIでメンバー育成を『見える化』してみた」 https://dev.classmethod.jp/articles/visualization-of-member-training-process-using-genai/ まとめ 22

Slide 23

Slide 23 text

ありがとうございました