はじめに こんにちは。クラウドエース株式会社 第一開発部の猪野です。 データ活用が当たり前になった昨今、Google Cloud が提供するエンタープライズ向け BI プラットフォーム「Looker（ルッカー）」はご存知でしょうか？ 「Looker って名前は聞くけど、なんだか難しそう……」 そんな Looker 初学者の方 に向けたチュートリアルです。 データポータルとの決定的な違いは「LookML」による一元管理 機能が似ている「データポータル (旧 Looker Studio)」は直感的にグラフを作れる反面、各レポート内に計算ロジックを持たせるため、「A さんと B さんの

株式会社 G-gen の菊池です。Looker では LookML （Looker Modeling Language）を用いてデータモデルを定義しますが、これらのコードはすべて Git リポジトリで管理されます。当記事では、Git 連携の仕組みや品質管理設定について解説します。 Looker におけるバージョン管理の概要 LookML プロジェクトと Git リポジトリの連携 開発モードと本番環境の分離 IDE 内での Git 操作 Git リポジトリとの接続方法 概要 HTTPS を使用した接続 SSH を使用した接続 ベア Git リポジトリ デフォルトのワークフロー 概要 開発ブランチへの変更のコミット 開発ブランチを本番環境ブランチにマージする Looker 本番環境への本番環境ブランチのデプロイ 品質と安全性を高める設定 概要 LookML バリデーションの必須化 データテストの必須化 プルリクエスト（PR）の統合 高度なデプロイモード Looker におけるバージョン管理の概要 LookML プロジェクトと Git リポジトリの連携 Looker の LookML プロジェクトは、 Git リポジトリと 1 対 1 に紐づけることでバージョン管理を構成します。バージョン管理構成にすることで、複数人での共同開発や変更履歴の追跡、安全な本番環境へのデプロイができます。 リモートリポジトリが準備できていない場合や素早く開発を始めたい場合は、Looker サーバー上にローカルの Git リポジトリを作成して単独でバージョン管理を開始することも可能です。 参考 : Git 接続の設定とテスト 開発モードと本番環境の分離 Looker には Development Mode （開発モード）と Production Mode （本番環境モード）という 2 つの環境が分離して存在します。 Development Mode は開発者が LookML を安全に編集、テストできる個人のサンドボックス環境であり、各ユーザーには他のデベロッパーに影響を与えない独自の開発ブランチ（dev- で始まりデベロッパー名を含むブランチ）が割り当てられます。 対して Production Mode はすべての一般ユーザーがアクセスする共有環境であり、ユーザーはこの環境でデータモデルを探索しダッシュボードを構築します。デフォルトの構成では、本番ブランチ（通常は master または main）の最新コードが本番環境で実行されますが、高度な設定を用いることで、特定のリリースバージョン（コミットやタグ）のコードを実行するよう厳密に管理することも可能です。 開発モードの場合、画面上部に「現在は Development Mode です。」というテキストが表示されたバナーが配置されます。右上にある「Exit Development Mode（Development Mode を終了）」という部分をクリックすると、本番環境モードへ切り替わり、このバナーは消えます。 開発モードから本番環境モードへの切替 本番環境モードから開発モードへ切り替える場合は、画面左上にあるメインメニューをクリックして開き、メニューの下部にある「Development Mode」をオンにします。開発モードと本番環境モードのオン・オフは、キーボードショートカット Mac : Control + Shift + D / Windows : Ctrl + Shift + D でもすばやく切り替えることが可能です。 本番環境モードから開発モードへの切替 LookML を変更する場合は、開発モードで作業する必要があります。LookML のコードを修正すると、「Save Changes」というボタンが表示されます。 LookMLの修正（例：列名の修正） このボタンをクリックすると変更内容が保存され、作業している個人の開発環境に変更が反映されます。 開発モードのダッシュボード 一方で、すべてのユーザーが共有する本番環境モードには、まだこの変更内容は反映されません。 本番環境モードのダッシュボード 個人の開発環境での変更を本番環境モードのユーザーにも見えるようにするためには、保存した変更を Git に「コミット」し、本番ブランチへ「デプロイ」するバージョン管理のステップを踏む必要があります。 参考 : Development Mode and Production Mode（開発モードと本稼働モード） IDE 内での Git 操作 Looker の統合開発環境（IDE）には、Git コマンドを操作するための GUI ボタン（IDE 右上、またはメインナビゲーションメニューの「Git Actions」パネル）が備わっています。開発者は複雑な Git コマンドを直接入力することなく、ボタン操作のみでコミットやリモートからのプル、本番環境へのデプロイといった一連のワークフローを実行できます。 特に便利なのは、この Git ボタンが現在の開発ステータス（ファイルの変更有無や他の開発者による更新状況など）に応じて、次に必要なアクションのみを動的に表示する点です。これにより、開発者は手順に迷うことなく、安全かつスムーズにバージョン管理を行うことができます。 参考 : Using version control and deploying（バージョン管理機能の使用とデプロイ） 参考 : Git コマンドのリファレンス Git リポジトリとの接続方法 概要 新規にプロジェクトを作成する際、まず Git リポジトリの構成設定を行います。 Git リポジトリは、外部の Git プロバイダと連携する「HTTPS を使用した接続」、「SSH を使用した接続」、または外部連携を行わずに Looker サーバー上にローカルリポジトリを作成する「ベア Git リポジトリ」の 3 つの構成オプションのいずれかを選択できます。 HTTPS を使用した接続 HTTPS 接続では、ユーザー名と 個人用アクセストークン（Personal Access Token） を使用して認証を行います。 運用方法として、プロジェクト全体で 1 つの Git アカウントを共有する設定と、Looker の「ユーザー属性」機能を用いてデベロッパーごとに個別の Git アカウントを使用する設定が選択可能です。 なお、単一の Git アカウントを共有する場合でも、Looker は各デベロッパーの Looker ユーザー名を使用してコミットを行うため、誰が変更を加えたかの履歴は正しく追跡されます。 ただし、注意点として Looker は現在、GitHub の きめ細かい個人用アクセス トークン（Fine-grained personal access tokens） をサポートしていません。そのため、GitHub を利用する場合は、必ず 「Tokens (classic)」 のオプションを使用してトークンを作成してください。 参考 : HTTPS を使用した Git への接続 参考 : GitHub - Managing your personal access tokens SSH を使用した接続 SSH 接続では、 Looker が生成する公開鍵を Git プロバイダー側に登録することで認証を行います。手順としては、 Looker 側で SSH 公開鍵を生成してコピーし、 Git プロバイダーのリポジトリ設定画面で「Deploy Key」として登録します。この際、 Looker からリポジトリへ変更をプッシュできるよう、書き込みアクセスを許可（Allow write access）を有効にする必要があります。 参考 : SSH を使用した Git への接続 ベア Git リポジトリ リモートの Git プロバイダーを準備していない場合や、すぐに開発を開始したい場合、 Looker サーバー上にローカルリポジトリを作成する ベア Git リポジトリ 構成も選択できます。 ただし、ベア Git リポジトリではプルリクエストの作成など一部の機能が使用できないため、あくまで一時的な利用にとどめることが推奨されます。最初はベアリポジトリで開始し、後からリモートの Git プロバイダーへ接続し直すことも可能ですが、その場合は「まだ Git 履歴を持たない空のリポジトリ」に接続する必要がある点に注意してください。 参考 : ベア Git リポジトリの構成 デフォルトのワークフロー 概要 Looker の標準的なデプロイフローは、開発モード（個人の開発ブランチ）での作業から、共通のリモートリポジトリを経由して、本番環境へと反映される一連のステップで進行します。 開発ブランチへの変更のコミット 開発モードで LookML の修正が完了したら、LookML の検証（Validate LookML）ボタンをクリックします。 LookML にエラーが見つからなければ、ボタンは「Commit Changes & Push」に変わります。 エラーがあった場合は、LookML の検証欄にエラー内容が表示されます。 LookMLの検証 「Commit Changes & Push」ボタンをクリックすることで、コミットのメッセージを入力する画面が表示されます。 コミットの内容をメッセージ欄に入力して、「Commit」ボタンをクリックすることで、変更を開発ブランチに保存（コミット）します。 この操作により、作業内容に名前を付けて保存し、後から履歴を追えるようになります。 メッセージを入力してコミット プロジェクトの設定によっては、変更をコミットする前に LookML Validator によるエラー修正や、データテストへの合格が必須となる場合があります。 開発ブランチを本番環境ブランチにマージする コミットされた変更は、共有のリモートリポジトリへプッシュされます。デフォルト設定の Looker では、IDE 上の「本番環境にデプロイ（Deploy to Production）」ボタンをクリックすることで、開発ブランチの内容が本番ブランチ（通常は master または main ）へマージされます。 本番環境にデプロイ Looker 本番環境への本番環境ブランチのデプロイ IDE での「本番環境にデプロイ」操作を行うと、マージに続いて Looker の本番環境（Production Mode）が自動的に本番ブランチの最新コミットを参照するように更新されます。これにより、エンドユーザーが参照するダッシュボードや Explore に最新の定義が即座に反映されます。 本番モード環境のダッシュボード 品質と安全性を高める設定 概要 「プロジェクト構成（Project Configuration）」ページの設定を変更することで、より厳格なリリース管理を実現できます。これらは、複数人での大規模開発においてコードの品質と環境の安定性を維持するために重要です。 参考 : Configuring project version control settings（プロジェクトのバージョン管理の設定） LookML バリデーションの必須化 LookML Validator によるエラーチェックを、変更をローカルブランチに コミットする前の必須条件 として設定できます。設定により「エラーと警告の両方を修正」または「エラーのみを修正」を必須にすることが可能です。これにより、構文エラーを含んだ不正なコードがプロジェクトの履歴に混入することを未然に防ぐことができます。 データテストの必須化 LookML 内に test パラメータを定義してモデルのロジックを検証するデータテストを作成している場合、本番環境へデプロイする前にこれらのテストに合格することを必須条件に設定できます。なお、新しく作成された LookML プロジェクトでは、このオプションがデフォルトで有効になっています。 プルリクエスト（PR）の統合 Pull Request Required 設定を有効にすると、デベロッパーは Looker IDE 内で直接本番ブランチへマージすることができなくなります。変更を本番環境に反映させるためには、必ず GitHub 等の外部サービス上でプルリクエストを作成し、第三者によるコードレビューを経てマージする必要があります。これにより、開発ガバナンスを大幅に高めることができます。 Looker は「マージコミット」方式のみをサポートしているため、この機能を利用する場合は、Git プロバイダ側で「スカッシュマージ」や「リベースマージ」のオプションを使用不可にしておくことが推奨されます。 参考 : プロジェクトの pull リクエストを統合する 高度なデプロイモード Advanced Deploy Mode（高度なデプロイモード） を有効にすると、常に本番ブランチの最新状態を自動デプロイするデフォルトの動作が解除されます。代わりに、デプロイ権限を持つ担当者が特定のコミット SHA や Git タグ（リリースバージョンなど）を明示的に指定して本番環境へ反映させることが可能です。 この機能により、Git 上でのマージと Looker へのリリース反映タイミングを完全に切り離し、Webhook や API を利用した複雑なリリースパイプラインを構築できます。ただし、このモードを有効にした場合、本番環境への「最初の1回目」のデプロイは、必ず Looker IDE 内の Deployment Manager から手動で実行する必要がある点に注意してください。 参考 : 高度なデプロイモード 菊池 健太 (記事一覧) 事業開発部クラウドサポート課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、Google Cloudは未経験なので現在勉強中。

はじめに こんにちは。ファインディでデータエンジニアをしている開（ @hiracky16 ）です。 今回はLookerに搭載されている会話分析機能を使って、ユーザーがより自律的にデータ抽出や分析ができるようにした話をします。セマンティックレイヤー（Explore）を会話分析に使用する設計や開発・テスト・評価までの運用のノウハウを紹介します。 会話分析（Conversational Analytics）は、Lookerに搭載されている機能で、自然言語で質問を投げるとエージェントが裏でクエリを組み立てて実行し、表やグラフを添えて答えてくれます。たとえば「1月から5月までのXXX数をUUベースで集計できますか？」と聞くと、次のように月別の集計結果とグラフが返ってきます。 はじめに 会話分析にセマンティックレイヤーを使う理由 セマンティックレイヤーを会話分析の入口にするメリット 参照先のデータを意味ある単位に限定できる コンテキストの肥大化を避けられる デメリット 運用 エージェント定義をGitで管理する 回答品質の評価 評価ケースを定義する 軸1: 回答テキストの品質をLLMで採点する 軸2: 発行されたクエリを決定論的に検証する フィードバックサイクルを回す 成果 まとめ 会話分析にセマンティックレイヤーを使う理由 以前公開したブログでは、Lookerを導入した背景や、登録ユーザーの7割がダッシュボードの作成・閲覧のために日々訪れていることを紹介しました。 tech.findy.co.jp tech.findy.co.jp これらの記事で触れたとおり、重要な指標や共通のディメンションは、セマンティックレイヤーへの集約を進めてきました。 集約した指標やディメンションを使ってダッシュボードを作り社内に展開していますが、「別の切り口で見たい」「集計ロジックを変えたい」といった要望に都度対応する運用となり、その工数が無視できなくなってきました。 一方で、会話ベースでデータ抽出・集計・分析ができるエージェントが世の中に広がってきました。私たちもGoogle製のADKを使って自作してみましたが、こちらもメンテナンスコストがかかります。さらに、全テーブルを対象にするため、SSoT（Single Source of Truth）が整っていない領域や、コンテキストが薄い領域では精度が出ず実用には届きませんでした。 ここで着目したのが、すでに集約を進めてきたセマンティックレイヤー（LookerのExplore）です。これを会話分析エージェントの入口に据えることで、ダッシュボード運用の工数と、自作エージェントのコンテキスト不足という両方の課題を解決できると考えました。全体像は次のとおりです。 flowchart LR subgraph DWH["データウェアハウス"] direction TB NOTE1[/"会社マスタが複数あり<br/>テーブル単位ではSSoTが曖昧"/] T1[fct_scouts<br/>送信済みスカウト] T2[fct_scout_replies<br/>スカウトへの返信] T3[fct_matches<br/>成立したマッチング] T4[dim_users<br/>ユーザー情報] C1[dim_companies_raw<br/>会社情報（raw）] C2[dim_company_master<br/>会社情報（master）] end subgraph SL["セマンティックレイヤー"] direction TB NOTE2[/"業務単位で集約し<br/>使う会社マスタもExploreで判断"/] E1["スカウトExplore<br/>送信数・返信率を定義"] E2["マッチングExplore<br/>成立件数・成立率を定義"] end T1 & T2 & T4 --> E1 T3 & T4 --> E2 C1 -->|スカウトはrawを使う| E1 C2 -->|マッチングはmasterを使う| E2 E1 --> A1[スカウト分析エージェント] E2 --> A2[マッチング分析エージェント] A1 & A2 --> U([利用者の質問]) 左側のデータウェアハウスには大量のテーブルが並び、どれを使えばよいか、指標をどう計算すればよいかはテーブル単位では自明ではありません。たとえば会社マスタが dim_companies_raw と dim_company_master のように複数存在し、用途によってどちらを使うべきかが曖昧、といったこともあります。これをそのままエージェントに渡しても、うまく答えられないのは当然です。 そこで、Explore側で「スカウト」「マッチング」といった業務の単位にテーブルを集約し、送信数や成立率といった指標の定義まで含めて整えておきます。会社マスタのように複数の候補があるものも、Explore側でどちらを参照すべきかを判断します。たとえばスカウトExploreでは dim_companies_raw を、マッチングExploreでは dim_company_master を使う、といった使い分けをExploreの定義として固定しておくわけです。エージェントは生のテーブルではなくこのExploreだけを見るので、何をどう集計すべきかが定まった状態で質問に答えられます。 セマンティックレイヤーを会話分析の入口にするメリット セマンティックレイヤーを入口に据えると、大きく2つのメリットがあります。 参照先のデータを意味ある単位に限定できる 1つのエージェントは1〜5個のExploreに紐づきます。エージェントが触れられるデータがExploreの範囲に限定されるためエージェントの役割がはっきりします。 また、SSoTが担保できていないテーブルであっても、Lookerから参照する形にすればExplore上でSSoTを表現できます。生のテーブルをそのまま渡すのではなく、Lookerというフィルタを通すことで、エージェントが扱うデータの意味を整えられます。ダッシュボードと会話分析で使用するExploreは同じなので、両者で数値が食い違うという事態も避けられます。 コンテキストの肥大化を避けられる 全テーブルをエージェントに渡そうとすると、コンテキストが膨れ上がり、かえって精度が落ちます。Exploreを入口にすれば、LookMLのdescriptionや指標定義がそのまま「正しい意味」のソースになり、必要な範囲のコンテキストだけを渡せます。 LookerはKnowledge Catalog(旧Dataplex)との連携も進んでおり、メタデータをカタログ側で一元管理できるようになってきています。 docs.cloud.google.com 今はLookMLのdescriptionにコンテキストを持たせていますが、今後はKnowledge Catalog側にも用語や定義を蓄積し、それをエージェントのコンテキストとして活かせるようになることを期待しています。 デメリット 一方で、当然ながら弱点もあります。複数のExploreをまたぐ横断分析やファネル分析は苦手です。たとえば、ファインディが主催するイベントへの参加やメディア閲覧といったイベントを起点に、実際に企業とのマッチングに至るまでの流れを追う、といった分析は守備範囲の外でした。それぞれのイベントが別々のExploreに分かれていると、エージェントはどちらか一方しか見られず、つながりを追えません。 そこで、ユーザーという意味のある単位でフェーズをまたいだデータを1行にまとめた累積ファクトを作り、Exploreとして用意することで対処しました。次のように、1行=1ユーザーで各フェーズの日付を横並びに持たせておきます。 user_key イベント参加日 メディア閲覧日 マッチング日 u_001 2026-04-01 2026-04-03 2026-04-20 u_002 2026-04-05 （なし） （なし） u_003 2026-04-10 2026-04-12 （なし） こうしておけば、1つのExploreの中で「イベント参加からマッチングまで到達した割合は？」といったファネルをたどれます。横断的な問いに答える必要があるものは、あらかじめこの形に整形しておき、エージェントからも参照できるようにしています。 運用 LookMLの開発方法は前述のブログで紹介しているので割愛し、今回はLooker会話分析に使うエージェントの開発・運用について説明します。 エージェント定義をGitで管理する 会話分析のエージェントは、Lookerの画面上からでも作成・編集できます。ただ、画面で直接編集すると、誰がいつ何を変えたのかが追えず、システムプロンプト（instructions）の変更履歴も残りません。 そこで、エージェントに必要な項目をYAMLファイルとして定義し、Gitで管理することにしました。1ファイルにエージェントのID、名前、参照するExplore（sources）、システムプロンプト（instructions）、そして後述する評価ケース（cases）をまとめています。 id : hogefugapiyo # 既存エージェントの更新用。新規作成時は省略 name : マッチング分析エージェント description : 企業と求職者のマッチング状況を分析するエージェントです。 code_interpreter : false # このエージェントが参照するExplore sources : - model : sample_recruiting explore : fct_matchings - model : sample_recruiting explore : fct_daily_snapshot_matchings # システムプロンプト instructions : | あなたはマッチング分析の専門アシスタントです。 LookerのExploreを使って、マッチングの成立件数・成立率・ セグメント別トレンドに関する質問に回答します。 ## 用語集 - マッチング : 企業と求職者の間で選考が始まった状態 - 成立率 : マッチング成立件数 ÷ いいね件数 ... # 評価ケース（評価の章で後述） cases : - prompt : "今月のセグメント別のマッチング成立率は？" reference : "セグメントでグループ化し、成立件数をいいね件数で割った値を回答する" ExploreやYAMLが編集されると、GitHub ActionsでLookerのエージェントに反映されます。 回答品質の評価 エージェントを運用に乗せると、「ちゃんと正しく答えられているか」が気になります。システムプロンプトやExploreを変更するたびに、回答の質が上がったのか下がったのかを判断したくなります。 そこで、エージェント定義に評価ケースを書いておき、CIで自動評価する仕組みを用意しました。 評価ケースを定義する 評価ケースは、前述したエージェント定義のYAMLに質問（prompt）と期待する答え方（reference）の組として書いておきます。たとえば次のように、想定される質問のバリエーションを並べておきます。 cases : - prompt : "今月のマッチング成立件数は？" reference : "当月のマッチング成立件数の合計を回答する" - prompt : "セグメント別のマッチング成立率を高い順に教えて" reference : "セグメントでグループ化し、成立件数をいいね件数で割った成立率を降順で回答する" - prompt : "先月と今月でマッチング成立件数はどう変わった？" reference : "先月と当月の成立件数を比較し、増減と差分を回答する" referenceには「完全一致の正解テキスト」ではなく、答えの作り方の説明を書いています。会話分析の回答は表現に幅があるため、文章の一致ではなく方向性で評価したいからです。 この評価ケースを使って、次の2軸で品質を測ります。 軸1: 回答テキストの品質をLLMで採点する 1つ目は、エージェントが返した回答テキストそのものの質です。これは Agent Platform（Vertex AI）の評価サービス を使い、LLM-as-a-Judge、つまり別のLLMに採点役をやってもらう形で測っています。 採点は4つの観点で行われます。 質問の指示どおりに答えているか（Instruction following） 与えられたコンテキストに基づいているか（Groundedness） 十分な情報量で答えているか（Completeness） 読みやすく整理されているか（Fluent） これらをまとめたスコアを段階評価で受け取り、品質が落ちていないかを確認します。 軸2: 発行されたクエリを決定論的に検証する LLMによる採点は揺れるため、それだけに頼るのは不安が残ります。そこでエージェントが実際に発行したクエリの中身を機械的に検証しています。 会話分析エージェントは、質問を受けると裏でLookerのクエリを組み立てて実行します。このクエリが「どのExploreを使い、どのフィールドを選び、どんなフィルタをかけたか」を期待値と照合して判定します。回答テキストの良し悪しではなく、構造として正しいクエリを組めているかを、ぶれのない形で担保します。 期待値は、評価ケースに assertions として書き足しておきます。 cases : - prompt : "今月のセグメント別のマッチング成立率は？" reference : "セグメントでグループ化し、成立件数をいいね件数で割った成立率を回答する" assertions : explore : fct_matchings # このExploreを使っているか fields_include : # これらのフィールドが含まれているか - segment - matching_rate filters_include : # このフィルタがかかっているか - field : matched_month value : this month これらの評価はGitHub Actionsで自動実行され、結果はPRにコメントされます。QA Qualityの平均スコアやケースごとの内訳、アサーションの判定がひと目で分かるので、変更が品質に与えた影響をレビュー時に確認できます。 フィードバックサイクルを回す 評価ケースは社内メンバーから寄せられるフィードバックをもとに育てています。「この聞き方だと答えてくれない」「この数字が期待とずれている」といった、実際に使う人がぶつかった声ほど価値のあるテストケースになります。 寄せられた声は評価ケースに加えるだけでなく、エージェントに足りないコンテキストの手がかりとして、内容に応じてシステムプロンプト・LookML・BigQueryテーブルのどこに手を入れるかを判断します。こうしてフィードバックを起点にしたサイクルが回っています。 flowchart LR FB([社内メンバーのFB]) --> C[評価ケースに追加] C --> FIX{どこを直す？} FIX -->|答え方| P[システムプロンプト調整] FIX -->|定義不足| D[LookML description補強] FIX -->|データ構造の問題| M[dbtデータモデリング見直し] P & D & M --> EVAL[評価を実行] EVAL --> SCORE[スコアを比較] SCORE -.改善を確認.-> FB 成果 前回のブログで、Lookerの登録ユーザーの7割が週次でログインしていることをお伝えしました。いまではそのうちの半分が、会話分析を通じて自律的にデータ抽出や分析を行っています。 データチームへの影響も大きく、月に十数件あったデータ抽出の依頼はほぼなくなりました。代わりに届くのは、会話分析だけでは解けないより高度な分析を要する相談が中心です。単純な抽出作業から解放されて本来注力すべき仕事に時間を割けるようになりました。 利用者からのフィードバックも増えてきました。「便利になった」という好印象の声もあれば、期待した結果が得られなかったという指摘もあります。後者はチームにとって学びの多い情報で、どこにコンテキストが足りていないのかが明確になります。 このフィードバックサイクルが回り始めたことで、エージェントのinstructionsやLookMLの修正、データモデリングの見直しがこれまで以上に進むようになりました。前述したSSoTについても、Exploreで吸収するだけでなく、テーブルレベルで担保できるよう改善を進めています。 まとめ 本記事では、セマンティックレイヤー（LookerのExplore）を会話分析の入口に据える設計と、Git管理・2軸評価・改善サイクルまでの運用を紹介しました。この設計が効くのは、すでにLookMLで指標やディメンションの定義が進んでいる組織です。土台があるからこそすぐに始められ、成果につなげることができたと思います。 運用で意識しているのは、クイックウィンの積み重ねです。Lookerや生成AIは安価ではないため、小さな成功体験を積み上げ、利用者に定着してもらうことが重要です。そのためにはフィードバックを集める仕組みが重要で、社内勉強会で使い方を共有したり、要望を気軽に投げてもらえるチャンネルを用意したりしています。会話分析を実現させるためには技術的な仕組みと、声が集まる仕組みの両輪が必要だと感じています。 ファインディでは、データ基盤やデータ活用の仕組みづくりに一緒に取り組んでくれる仲間を募集しています。少しでも興味を持っていただけたら、まずはカジュアルにお話ししましょう。 herp.careers