１．はじめに Geniee Carpetチームの木下です。量子コンピューティング技術のアドテクへの応用可能性を調べている中で、Axel Ciceri氏らによる論文 Enhanced Fill Probability Estimates in Institutional Algorithmic Bond Trading Using Statistical Learning Algorithms with Quantum Computers に興味を持ちました。 本論文は、金融市場における社債取引の約定確率（Fill Probability）の推定に、量子コンピュータで生成した特徴量

こんにちは、LIFULL HOME'Sのネイティブアプリケーション開発チームでエンジニアリングマネージャーをしている佐々木です。 前々回の記事 ではチームの業務知識をAIに構造化して渡すことで調査工数を削減した話を、 前回の記事 ではその技術設計（コンテキストレイヤ5層）について書きました。今回は マーケター9人で構成されるデジタルマーケティング（以下、デジマ）チーム に、AI業務基盤を導入したお話をしていきたいと思います。 課題：属人化60%、ツール散在、新人が自走できない デジマチーム（9人）は以下の課題を抱えていました。 属人化 : 全業務の60%が「個々のやり方に終始している」状態。見込み算出の方法も、KPIの計算式も、人の頭にしかない ツール散在 : BigQuery、Looker Studio、スプレッドシート、GAS、Gemini Gem、各媒体管理画面と、作業のたびに別のツールを開きます 引き継ぎコスト : 「売上」の定義がマーケットごとに7種類違う。新人が独力で正しい数字を出せるようになるまでに時間がかかる チームからの依頼は明確でした。「 属人化している数字管理・施策準備・報告業務を標準化して、担当者が判断と意思決定に集中できる状態を作りたい 」。 課題：属人化60%、ツール散在、新人が自走できない アプリケーションパッケージとの設計の違い 2ヵ月の開発ストーリー 初日：1日で骨格を作る（4/22） 最大の壁：KPI定義が7マーケットで全部違う BigQueryスキーマ97,000行問題（4/24） フィードバック→改善のサイクル（5月〜6月） AIが間違える問題との戦い 現在の構成：53スキル・4エージェント・7MCP 53スキルの「選び間違い」をどう防ぐか 具体例：「マーケットAの定例資料を作って」 セットアップ：スクリプトファイルをダブルクリックするだけ BigQueryにないデータの扱い ツール一本化：1つのチャット画面で全部やる 成果 学んだこと 1. 暗黙知の構造化が9割 2. 最初から完璧を目指さない 3. 出力品質はスキル設計で制御する 4. 利用者の要望は進化する まとめ アプリケーションパッケージとの設計の違い 前回の記事で紹介したネイティブアプリケーション（以下、アプリケーション）向けパッケージは「ソースコードを読んで仕様を答える」ものでした。今回はまったく違います。 観点 アプリケーションパッケージ デジマパッケージ 入力 ソースコード BigQuery・CSV・媒体データ 出力 調査結果の回答 レポート文書・Confluence投稿・TSVデータ 核 画面→コード対応マッピング KPI計算式の完全定義 利用者 PdM・デザイナー マーケター コードベース型は「読み取り専用」で答えを返すだけです。一方デジマパッケージは BigQueryからデータを取得し、計算し、レポートを整形し、Confluenceに投稿する ところまで一気通貫で行います。 2ヵ月の開発ストーリー 初日：1日で骨格を作る（4/22） チームから受け取った業務棚卸しシート（18業務・週42時間分）を分析し、「AI化可能な業務」を仕分けました。 ✅ 完全吸収可能: 6業務（週14時間） 🔶 部分的に吸収: 8業務（週20時間） ❌ 対面・判断系で不可: 4業務（週8時間） この分析をもとに、初日で39スキル・3エージェントの骨格を構築。 ただし、この時点のKPI定義はまだ「たたき版」でした。 最大の壁：KPI定義が7マーケットで全部違う 最初にぶつかった壁は、 「売上」の定義がマーケットごとに違う ことでした。 パターン 「売上」の計算方法 マーケットA〜D 実績テーブルの特定カラムを参照 マーケットE 固定単価 × 反響数 マーケットF 月次変動単価 × 件数（単価は毎月BigQueryから自動算出） マーケットG そもそもKPIの定義自体がほかと異なる 「今月の売上を教えて」と聞かれても、マーケットによって見るべきカラムや計算式が全然違います。これを知っているのはチーム内の特定のベテランだけでした。 ヒアリングを重ね、最終的に21,000字超のKPI定義ファイルに全マーケットの計算式・区分構造・按分ロジック・異常値判定基準を一元化しました。 これがこのパッケージの心臓部になっています。 BigQueryスキーマ97,000行問題（4/24） BigQueryのテーブル定義を自動生成したら97,000行になりました。うっかりこれをsteeringディレクトリ（AIが起動時に必ず読み込むファイル群）に配置したところ、 Kiro IDE が起動直後にコンテキストウィンドウの上限に達して動かなくなりました。コンテキストウィンドウが上限に達するとこういう挙動になるのか、という良い検証にはなりました。 解決策は 配置の分離 。スキーマ本体は参照用ディレクトリに移し、steeringにはテーブル名とデータソースの対応マッピングだけを置く。さらに月別に重複していたテーブル定義を統合し、全1,439カラムに日本語説明を追加して97,000行→約1,800行に圧縮。「全部steeringに入れる」のではなく「必要なときに必要な分だけ参照する」設計にしました。 フィードバック→改善のサイクル（5月〜6月） パッケージをチームに配布してからが本番でした。改善要望がスプレッドシートで管理され、2ヵ月で33件。チームメンバーが各自記載してくれています。 初期（5月下旬）: 「金額をK表記にしないで」「課金率を追加して」— 出力の体裁 中期（6月上旬）: 「定例資料を自動生成したい」「検収フローをガイドして」— 業務プロセスの自動化 最近（6月中旬）: 「ワークフローを自動化したい」「時間トリガで自動実行したい」— パワーユーザー化 「使い方を覚える」段階から「もっとこうしたい」段階に変化していったのが印象的でした。 AIが間違える問題との戦い 特に印象的だったのは、プロジェクトリーダーからの指摘です。 媒体分析時にKPI定義ファイルで「反響＝カラムA」と定義されているのに、別のカラムで出される事象が何度か発生。確認したところ「定義は読み込まれていたが、出力整形時に照合するステップを飛ばした」とのこと。 AIは定義を「知って」いても、出力時に「確認」しないことがある。これに対して、スキル内に「出力前に必ずKPI定義と照合するチェックステップ」を追加して解決しました。 AIの出力品質は、スキル設計で制御する 。 現在の構成：53スキル・4エージェント・7MCP 2ヵ月の改善を経た現時点でのパッケージ構成（まだ進化中）です。 カテゴリ スキル数 代表例 レポート・報告 9 着地見込報告書、週次定例資料、施策結果報告書 データ分析・異常検知 8 媒体別パフォーマンス、変動要因分析、異常値検出 予算・配分 8 予算消化ペース監視、配分提案、来期予算策定 クリエイティブ 6 疲弊検知、勝ちパターン抽出、コピー提案 施策・計画 8 施策概要書ドラフト、シミュレーション、開発依頼書 運用・ナレッジ 6 検収フロー案内、プライバシーポリシー対応フロー、重複チェック ストア改善（広告・最適化） 5 キーワード分析、入札調整提案、週次レポート Amplitude連携 1 ファネル分析、CVR深掘り 7つのMCPサーバ （BigQuery・Jira・Confluence・Google Ads・Amplitude・AFAD・ASA）を接続し、1つのチャット画面からすべて操作できます。 53スキルの「選び間違い」をどう防ぐか スキルが53個もあると、別の問題が出てきます。 ユーザーの質問に対して、間違ったスキルが選ばれる 問題です。 たとえば「レポート作って」と言われたとき、候補になるスキルが5つあります。 マーケット別定例資料 全体エグゼクティブサマリー 施策別進捗管理表 着地見込報告書 施策結果報告書 AIはdescription（スキルの説明文）だけでは適切なスキルを選べません。実際に定例資料を作りたかったのに着地見込報告書が生成されるケースがありました。 学術的にも、スキルが重複する環境ではルーティング精度が31〜44ポイント低下すると報告されています（ SkillRouter ）。 対策として、ルール定義ファイルに ルーティング優先度ルール を追加しました。 ### 週次レポート系 - 「定例」「定例資料」「マーケット別」→ マーケット別定例資料スキル - 「全体サマリー」「概況」→ 全体サマリースキル - 「施策の進捗」「ステータス」→ 施策進捗管理スキル - 「レポート作って」（曖昧）→ 用途を確認する質問を返す さらに各スキルのdescriptionに「Use when（このとき使う）/ Do NOT use when（このときは別のスキル）」を明記しています。あいまいな指示に対しては「どのレポートですか？」と確認を返すフォールバックルールも設けています。 スキルを増やすだけでは足りない。「選ばれ方」も設計する。 これはスキル数が30を超えたあたりから意識すべきポイントです。 具体例：「マーケットAの定例資料を作って」 最もインパクトが大きかった業務変革の1つが、週次定例資料の自動生成です。 Before 1. 月次レポート（自動生成）の数値を確認（5分） 2. そこから各自の着地見込を手動で作成（30分） 3. 内容を読み取り、週次の進捗比較・変動分析を行う（20分） 4. 定例資料としてコメントを成型（15分） 5. Confluenceの定例ページにコピー&ペースト＆整形（10分） → 合計80〜90分、7マーケット分で週10時間超 After 「マーケットAの定例資料を作って」と入力。 AIがBigQueryからデータを取得し、KPI定義ファイルに従って按分計算を行います。先週差分を算出し、変動要因を分析し、所定のフォーマットで定例資料を出力します。所要時間は数分です。 セットアップ：スクリプトファイルをダブルクリックするだけ 非エンジニアのチームに配るにあたり、最もこだわったのはセットアップの簡易化です。 セットアップスクリプトをダブルクリック ブラウザが開いてGoogle認証（クリック1回） Jira/Confluenceのトークンを入力（コピー&ペースト2回） 完了。所要時間5分 内部では、BigQuery MCPの認証設定、MCP Toolboxのダウンロード、mcp.jsonの自動構成をすべて処理しています。「ターミナルを開いてください」は一度も言いません。 BigQueryにないデータの扱い すべてのデータがBigQueryにあるわけではありません。オークションインサイト（Google Ads管理画面からCSV出力）やASOキーワードデータなど、BigQuery外のデータも業務には必要です。 これらは専用のインポートディレクトリに「ダウンロードしたファイルをそのまま置く」だけで使えるようにしました。ファイル名の変更不要、フォーマット変換不要。 ツール一本化：1つのチャット画面で全部やる 以前は業務ごとに別のツールを行き来していました。 業務 Before After データ取得 BigQuery管理画面 or Looker Studio 「今月のCPAを教えて」 レポート作成 スプレッドシート + 手動計算 「定例資料作って」 報告書投稿 Confluenceを手動編集 「Confluenceに投稿して」 チケット起票 Jiraを手動操作 「開発依頼チケットを起票して」 競合分析 管理画面CSV + スプレッドシート 「オークション分析して」 広告データ確認 Google Ads管理画面 「アクティブなキャンペーン一覧を教えて」 すべて同じKiro IDEのチャット画面で完結します。 成果 チームのプロジェクトリーダーが効果試算を行ってくれました。結果、大幅な削減効果が見込まれています。 特に効果が大きかった業務は以下です。 業務 Before→After 月間削減 BigQueryデータ問い合わせ・SQL抽出 1.5h→0.25h（月10回） 12.5h クリエイティブ分析 2.0h→0.5h 6.0h Confluence/Jira投稿・整形 4.0h→1.0h 6.0h オークション分析 2.0h→0.5h 6.0h 定性的にも変化が起きています。 - SQLが書けないメンバーでもデータ確認が自走できるようになった - 新人のオンボーディングが早まった（KPI定義・業務フローを自習できる） - 単純作業から解放されて、判断・意思決定に時間を使えるようになった 学んだこと 1. 暗黙知の構造化が9割 技術的に一番難しかったのはAI実装ではなく、 チームの暗黙知をMarkdownに書き出すこと でした。特にKPI定義は、ベテランメンバーに何度もヒアリングして初めて正確に書けるものです。ここが不正確だとAIの出す数字が全部間違います。 2. 最初から完璧を目指さない 初日に39スキルの骨格を作りましたが、定義やルール、スキルのすべてがたたき版でした。利用者のフィードバックを元に磨き上げる前提で「60点で配布→改善→配布」を繰り返し、2ヵ月半で22回リリースしました。 3. 出力品質はスキル設計で制御する AIは定義を「知って」いても出力時に従わないことがある。スキル内にチェックステップを入れ、ルール定義ファイルに「⚠️ よくあるミス」を太字で書く。 AIの行動を信頼するのではなく、しくみで保証する。 4. 利用者の要望は進化する 「表記直して」から「時間トリガで自動実行したい」まで、使い込むほど要望が高度化する。これはツールが浸透している証拠であり、同時にパッケージが追い続けるべき目標を示してくれます。 まとめ 非エンジニアのチームにAI業務基盤を導入するために必要だったのは以下でした。 KPI定義の構造化 （21,000字のMarkdown。これが心臓部） BigQueryスキーマの配置設計 （steeringに入れたらコンテキスト爆発→参照用ディレクトリへ分離し、steeringにはテーブルマッピングだけ配置） セットアップスクリプトの自動化 （ダブルクリック1回で完了） フィードバックサイクル （2ヵ月半で22回リリースし、33件の要望に対応） 前回の記事ではコードベースパッケージの技術設計を紹介しましたが、今回は 「ビジネス知識をAIに教えて、チームの働き方を変える」 話でした。技術的な難易度よりも、人間のドメイン知識を正確に構造化することの方がはるかに難しく、そして効果が大きかったと感じています。 最後に、LIFULLではともに挑戦していける仲間を募集しています。ご興味をお持ちいただけましたら、ぜひ以下のページもご覧ください。 hrmos.co hrmos.co

こんにちは、デジタルマーケティング事業に携わっている神崎です。 本記事では、Google Cloud の BigQuery の UI 上で作成したデータエージェントを、Gemini Enterprise App に追加する方法について、解説します。 BigQuery のデータエージェントについては、以下の記事を参照してください。 tech.nri-net.com 今回紹介する内容は、東京ビッグサイトで開催される Google 社主催のイベント「Google Cloud Next Tokyo 26」で、2026年7月30日（木）に私が講演する内容と関連するものとなります。 よろしければ、以下のリ…