こんにちは。ファインディ株式会社のプロダクトマネジメント室GenAI Enablementチームで、社内のデータ・AI活用を推進している山家です。 2026年10月5日（月）に、CTO室データソリューションチームとプロダクトマネジメント室GenAI Enablementチームの共催で、採用イベント 「ファインディにおけるデータ活用とAIがもたらす現場変革のリアル」 を、ファインディ本社でオフライン開催しました。 findy-inc.connpass.com この記事では、イベントを企画した背景と当日の4本のセッションを、参加できなかった方にもイメージが伝わるようにまとめます。あわせて、それぞれのチームが抱える課題と今後についても紹介します。 イベント開催の背景 データソリューションチーム セッション1: AIエージェントのためのデータ品質Ops セッション2: 2025年に事業部化したプラットフォーム事業部でのデータ活用 現在とこれから データソリューションチームの今後 GenAI Enablementチーム セッション3: データ問い合わせエージェントと求人推薦システムから見る、当社のデータ活用事例 セッション4: 領収書OCRを作ったら、OCR以外の仕事が本体だった GenAI Enablementチームの今後 まとめ イベント開催の背景 ファインディでは事業の広がりとともに、データ基盤やデータモデリングを整える仕事と、生成AIで現場の業務そのものを変える仕事の両方が進んでいます。データソリューションチームは全社の共通データ基盤とその品質を、GenAI Enablementチームは現場の業務にAIを届けることを担っています。 2つのチームは所属組織は違えど、密接に関係しています。AIが適切に動作するにはデータの品質が欠かせず、AIやデータを現場で使ってもらうには業務への埋め込みの設計が欠かせません。今回のイベントを、両チームがどのような課題に向き合い、どのように取り組んでいるかをお話しする機会にしました。 セッションは4本立てで、データソリューションチームとGenAI Enablementチームが2本ずつお話ししました。 データソリューションチーム データソリューションチームからは、AIエージェントに向けたデータ品質の運用と、新設事業部でのデータ活用の立ち上げについてお話ししました。 セッション1: AIエージェントのためのデータ品質Ops 登壇者: 田頭 speakerdeck.com AIエージェントにデータを使わせるために、dbtモデルの品質をどう運用しているかを紹介しました。データの使われ方は、人がLookerやSQLで集計する形から、AIエージェントに質問する形へ変わってきています。そのなかで、利用者側ではどのモデルを使えばよいかをエージェントに伝えられないという課題がありました。運用側でも、重要なモデルと検証用のモデルが同列に扱われ、ビルドが失敗したときにすぐ対応すべきか判断できませんでした。 そこで、dbtモデルを、算出する数値の用途で4段階のTierに分けました。テストやdescriptionといった品質要件は、工数のかかるものほど上位のTierに限定して求め、Tier 4だけはAIエージェントに使わせません。各Tierの用途と品質要件は次のとおりです。 Tier 用途 テスト description テスト失敗時の対応 AIエージェントの利用 Tier 1 外部公表数値・KPIの決定 主キー・外部キー・整合性 全カラムと計算ロジック 当日対応 可 Tier 2 部門の意思決定・定常レポート 主キー・主要な外部キー キー・指標カラム 週次で確認 可 Tier 3 部門オペレーション・データ抽出 主キー（推奨） モデルのみ ベストエフォート 可 Tier 4 アドホック・個人検証 要件なし 要件なし 要件なし 不可 Tier 1の起点の選び方では、AIと人の役割を分けています。LookerとBigQueryのクエリ履歴からClaude Codeのスキルが候補を出し、KPIに実際に使われているかはデータエンジニアが事業部に確認して決めます。確定した起点から dbt ls --select +<起点> で上流のモデルを列挙し、Tier 1を確定します。 現状、Tierはデータエンジニアの運用ルールとして使われている段階で、AIエージェントがTierを参照する仕組みはまだありません。今後は計算ロジックや用語集をKnowledge Catalogに集め、AIエージェントがTierの高いモデルと必要なコンテキストを取得して分析できる形を目指しています。 セッション2: 2025年に事業部化したプラットフォーム事業部でのデータ活用 現在とこれから 登壇者: 出相 speakerdeck.com 2025年に発足したプラットフォーム事業部で、データ活用をゼロから立ち上げている取り組みを紹介しました。発足当初は事業部付きのアナリストがおらず、事業部向けにデータを見る基盤もない状態でした。 最初に取り組んだのは、身近でデータに困っていると話していたカンファレンス集客の担当者の作業です。開催のたびに、業務に必要な対象リストを手作業で抽出し（1回約15分）、重複を関数で確認する（約30分）作業がありました。今後も開催数の増加が見込まれる中、これらの作業負荷がさらに高まることが課題でした。そこで、ヒアリングで必要なデータを把握し、BigQueryの共通基盤に集約、dbtでモデル化、Lookerで可視化するまでを一気通貫で整備しました。担当者へのヒアリングによると、リスト抽出にかかる時間は2〜3分に短縮され、重複率はダッシュボードで一目で分かるようになりました。 この1人との定例を起点に、困りごとを聞き、データを揃え、効果を見せ、その担当者の紹介で次の担当者へつなぐという循環を回して、事業部全体へ広げています。基盤の全体設計から入るのではなく、1つの業務を解いて次の相談を引き出す進め方です。 一方で、整えたデータが使われないという課題や、社内でNotionの活用が進みはじめるという状況の変化も出てきました。今後はNotionを入口に、Lookerのセマンティックレイヤーや共通データ基盤へたどれる状態を目指し、メタデータ・導線・定義の整備に取り組んでいきます。 データソリューションチームの今後 データソリューションチームが目指すのは、経営から現場まで、同じ正しい数字で意思決定できる状態です。共通データ基盤を作るだけで終わらせず、その数字が何を意味し、どこから来たのかを説明できるところまでを自分たちの仕事と考えています。 そのためにまず、指標を説明できる状態にします。KPIが何を表し、どのように計算されているのかを誰でも確かめられるようにします。そのうえで、数字が正しいことを前提に、予算と実績のズレを早く見つけられるようにします。ズレに気づいた人やAIが、すぐ次のアクションに移れる状態を目指しています。 Tierは運用ルールとして使われ始めた段階です。定期的な見直しや、計算ロジック・用語集をKnowledge Catalogへ集める取り組みはこれからです。AIエージェントが正しいデータを参照できるかを実際の問いで確かめながら、メタデータを育てていきます。 並行して、GenAI Enablementチームと協力しながら、AX（AIが業務を進め、人が要所で判断する形への業務の作り直し）と、データ基盤のセルフサービス化を進めています。AIや人が自分の手で課題を解決できるようなデータ基盤を目指していきます。 少数精鋭のチームなので、単発の作業で終わらせず、自動化や型化で横に広げられる仕組みにすることを大切にしています。経営と事業の意思決定に直結するデータ基盤を一緒に育てていけるデータエンジニアを募集しています。 GenAI Enablementチーム GenAI Enablementチームからは、社内向けの求人推薦と経費処理を例に、現場の業務にAIを組み込む取り組みをお話ししました。 セッション3: データ問い合わせエージェントと求人推薦システムから見る、当社のデータ活用事例 登壇者: 山家 speakerdeck.com 社内向けの求人推薦システムを例に、作った仕組みが現場で使われるための置き方を紹介しました。当日は時間の都合でお話しできませんでしたが、社内のデータ問い合わせに答えるエージェントを作った事例も登壇資料に載せているので、あわせてご覧ください。 転職事業では、ユーザーサクセス（US）が面談後に求人を紹介しています。担当者は紹介する求人を記憶と経験をたどって探しており、掲載求人が増えるほど追いつかなくなっていました。そこで、候補者ごとの推薦求人リストを出す仕組みを作りました。仕組みは次の図のとおりです。 求人票とUS面談メモをEmbeddingでベクトル化し、類似度で求人を並べたうえでフィルタをかけています。全体をBigQuery上のバッチで回しており、手法自体はシンプルなものにしています。 業務への導入方法はかなり意識をしました。以前作った検索系機能は現場の業務フローの外にあり、使われませんでした。そこで推薦では、面談メモを書いた後、紹介する求人を選ぶタイミングで、USが普段使うSalesforce上に観点ごとに分けて求人を出しました。推薦が引き受けるのは探す手間だけで、選んで紹介するのはUSのままです。その結果、USへのアンケートでは求人探索の工数が40%弱削減され、推薦経由の紹介も毎日生まれています。 ただし、使われることは成功と同じではありません。紹介求人の多くはカスタマーサクセス（CS）経由で、推薦が速くしたのはUSが自分で探す部分だけでした。現在は事業部全体にヒアリングし、事業のあるべき姿から逆算して、どのように業務を自動化していくかを計画しています。 セッション4: 領収書OCRを作ったら、OCR以外の仕事が本体だった 登壇者: 奥田 speakerdeck.com 秘書チームの経費処理を、生成AIでどう改善したかを紹介しました。月約160枚の領収書について、日付から予定を探し、参加者とその属性を確認し、経費区分を考えてSaaSへ転記する作業がありました。OCRで日付や金額を読み取れても、判断材料はカレンダー・組織図・人事情報に分かれたままです。 そこで、処理ごとに担い手を分けました。GASがSlackに投稿された領収書を取得し、Geminiが画像の読み取りと予定候補の選択を担います。参加者はGoogleカレンダーから、部門・役職・入社日は社員情報APIから取得し、決まった条件はコードで適用します。兼務は複数部門として扱い、入社日が取れなければその情報が必要な判定はしません。最後は秘書チームが判定理由と予算の利用状況を確認して区分を確定します。秘書チームの概算では、確認作業が月160分削減されました。 エラーの扱いも見直しました。判定できた、判断材料が足りない、取得処理に失敗した、の3つを分けて残し、情報不足なら人への確認、取得失敗なら再実行や調査へ進めるようにしています。 GenAI Enablementチームの今後 GenAI Enablementチームは、現場へのヒアリングから、社内データの接続、人が確認できる運用づくりまでを一気通貫で担います。 今は事業部全体の業務フローを、AIが主体で進め、人が要所で判断する形へ再設計しています。まずは担当者がAIの提案を確認・修正して使います。その記録で徐々にAIの精度を上げながら、AIに任せる範囲を広げていきます。 そのために欠かせないのが、データPdMとデータサイエンティストです。データPdMは、業務の中でどんなデータを生み、売上につなげるかを事業部と決めます。データサイエンティストは、今のやり方とAIを比べて効果を測り、任せる範囲を広げる根拠をつくります。事業責任者やPdMと会話しながら、データと実装を行き来して価値を届けたい方を募集しています。 まとめ 今回のイベントでは、データ品質の運用から、新設事業部でのデータ活用の立ち上げ、現場業務へのAIの組み込みまで、4名の視点からお話ししました。どのセッションにも共通していたのは、技術そのものよりも、データやAIを業務のどこにどうつなぐかを軸に進めてきたことです。仕組みは作るだけでは使われず、品質の優先度付けや業務フローへの埋め込み、人が確認できる運用まで設計して初めて現場が変わると考えています。 セッション後の懇親会でも、登壇では話しきれなかった失敗談を含め、参加者の皆さんと実務の話で盛り上がりました。こうした話ができるのは、オフライン開催ならではだと感じています。 参加してくださった皆さん、ありがとうございました！ ファインディでは、データとAIの力で現場を変えていく仲間を募集しています。今回のイベント内容に少しでも興味を持っていただけた方は、ぜひお気軽にカジュアル面談などでお話ししましょう。 データソリューションチームの求人はこちら。 herp.careers GenAI Enablementチームの求人はこちら。 herp.careers herp.careers

①管理者アカウントを日常業務と分けているか まず、最初に確認したいのは、管理者アカウントです。特権管理者は、組織全体の設定やユーザー管理に関わる強い権限を持ちます。そのため、一般の利用者以上に慎重な保護が必要です。

Weekly Google Cloud アップデート情報 - 2026年10月13日 ~ Gemini Enterprise: Antigravity 機能へのアクセス制御 ~ 皆さま、こんにちは。先週 (2026/10/02 - 2026/10/08) の主な Google Cloud（旧GCP）のアップデート情報を紹介します。 ※本記事の引用元:Google Cloud リリースノート 注目のアップデート Gemini Enterprise: Antigravity 機能へのアクセス制御 管理者は、組織内のユーザーが以下の Google Antigravity 機能へアク