こんにちは。新規事業開発部からMLチームに戻ってきた上村です。最近は主に推薦システムのアルゴリズム開発に携わっています。
こちらの記事は Gunosy Tech Blog Festa の 8 日目の記事です。 昨日の記事はUTさんの「CLI First 検証による開発の高速化」でした。
今日は12月24日、クリスマスイブですね。 今回は、サンタクロース...ではなく生成AI（GeminiやCopilot）を強力なパートナーにして、推薦システムの実験サイクルを高速化した話を紹介します。
はじめに：推薦システム開発における「定性評価」の壁
私は現在、ニュースアプリに向けた記事推薦システムのアルゴリズム改善に取り組んでいます。 その開発プロセスにおいて、常に頭を悩ませてきたのが「評価の難しさ」と「実装の手間」です。
特に今回は、従来のDeepLearningモデルが苦手とする「新規・マイナーなトピックの救済」を改善のテーマとしていました。しかし、こうした「推薦の質」や「多様性」に関わる改善は、CTRなどの定量的指標やログデータだけでは良し悪しを即座に判断することが困難です。
「数値は上がっているが、本当にユーザーの興味を捉えた良い推薦ができているのか？」という定性的な納得感を検証するには、実際の推薦リストを一つひとつ目視で確認する必要があり、その工数が肥大化するという課題がありました。
この課題に対して、複数のLLMを得意領域で使い分ける方法（このブログでは以後 コンテキスト・リレー と呼びます）」を取り入れたところ、実験サイクルを効率化することができました。 本記事では、この「コンテキスト・リレー」を取り入れた実験サイクルの効率化について紹介します。
本記事で紹介するワークフロー（コンテキスト・リレー）
最初に、今回構築した連携フローの全体像を示します。
戦略策定（Gemini）から、実装（Copilot/Claude）、自動評価（Gemini）、そして評価環境の共有（Gemini）に至るまで、適材適所の連携フローを構築することで、実験の質とスピードがどのように変化したのかを共有します。
戦略フェーズ：Gemini による「リサーチと構造化」
Deep Research による課題の再定義
プロジェクトの草案作成フェーズでは、Geminiの Deep Research 機能を活用し、ドメイン知識のリサーチを行いました。 「理想的なニュース推薦システムとは何か」という抽象的な問いからスタートしましたが、リサーチ結果からは「短期的なCTR最適化の弊害」や「プロファイリングによるRe-rankingの重要性」など、アルゴリズム選定の指針となる重要な知見が得られました。
アプリ固有のドメイン知識をコンテキストとして与えながら壁打ちを行うことで、単なるロジックの列挙にとどまらず、「検証すべき仮説」と「そのロジックが苦手とするエッジケース（重点検証項目）」を実験前に洗い出すことができました。
Canvas で「文脈」を仕様書化する
チャットでの議論は流動的であるため、Geminiの Canvas機能 を用いて、議論の結果をMarkdownドキュメントとして構造化しました。
Deep Researchで得られた知見や方針を、単なるチャットログではなく、体系だった「実験の設計図」としてドキュメントに落とし込んでおくことが、この後のリレーを成功させる鍵となります。
実装フェーズ：Copilot/Claude への「コンテキスト・リレー」
仕様書を「プロンプト」として活用する
ここからが「コンテキスト・リレー」の核心部分です。 Geminiで作成した戦略ドキュメント（CanvasのMarkdown）とデータ定義書を、実装能力に長けた Copilot（またはClaude） に入力として渡しました。
ここで効果を発揮するのが、戦略フェーズで 「具体的な数式」までドキュメント内に定義させておいたこと です。
自然言語で「ユーザーの好みを重み付けする」と記述するだけでは、実装時にLLM側の解釈に揺れが生じます。しかし、Canvas上で Score = w1 * click_rate + w2 * semantic_similarity のように数式レベルで定義された仕様書をプロンプトとして渡すことで、LLMは即座に実験の意図を正確に理解します。
「この設計図に基づいて実験用のNotebookを作成して」という指示だけで、意図に沿った実装コードが高い精度で生成されました。従来であれば、ロジックの詳細をプロンプトで長々と説明する必要がありましたが、 「生成したドキュメントを渡す」 という行為のみで文脈が共有されるため、実装着手までのリードタイムが大幅に短縮されました。
また、より実装の質を高めるためのテクニックとして、戦略ドキュメントに加えて 「データ仕様書」と「出力フォーマット定義」もセットで渡すことが非常に有効です。 具体的には、入力データのカラム定義や前処理の方法、最終的に算出したい評価Metricsの一覧、そして後工程（スプレッドシートやGASツール）での利用を見越して「再加工しやすいCSV形式」の出力例 を事前に提示します。これらをコンテキストとして注入することで、LLMは「データの扱い方」や「ゴールの形式」を正確に把握し、手戻りの少ない実装が可能になります。
品質のガードレール：モジュール化とテスト
生成AIによるコーディングは強力ですが、Null値の処理や前処理の不備といった細かなバグや意図していない処理は避けられません。 そのため、一度にすべてを実装させるのではなく、 「機能単位でのモジュール化」と「テストコードの実装」 をセットで行うプロセスを採用しました。
「データセットAを入力した場合の期待値B」を定義し、テスト実行までを含めて実装を依頼することで、手戻りを最小限に抑え、実験コードの品質を担保しています。
評価フェーズ：Gemini による「定性評価のスケール」
評価基準のコンテキスト注入
実装が完了し推薦リストが出力されましたが、これらを全て目視で確認するのは現実的ではありません。そこで、Geminiに 「LLM as a Judge」 の役割を担わせ、一次評価を自動化しました。
ちなみに、推薦リストの定性評価にCopilotを使うとPremium Requestが一瞬で消える（1敗） のでご注意ください。大量のデータとコンテキストを扱う評価タスクにおいては、コストパフォーマンスや制限の緩さが重要になります。
評価の精度を高める工夫として、単にリストを比較させるだけでなく、「ユーザーのプロファイリング情報」や「過去の閲覧ログ」をコンテキストとして注入しました。これにより、「このユーザーは技術記事を選好する傾向があるため、こちらのリストが適切である」といった、根拠のある評価コメントが得られるようになりました。
人間による最終レビューの効率化
LLMによる評価は強力ですが、ハルシネーションのリスクはゼロではありません。そのため、最終的なレビューは必ず人間が行うようにしています。
しかし、全てのデータをゼロから確認する必要はなく、「LLMが指摘したポイントを中心に確認する」というフローに変えることで、評価にかかる精神的負荷と時間は大幅に削減されました。
おまけ: 評価環境の拡張：Gemini による「チームで使える可視化ツール」
コンテキスト・リレーとは少し趣旨が異なるのですが、評価結果をチーム内で共有するためのツールもGeminiを活用して短時間で構築したので、参考までに紹介します。
Notebookの外へ：ステークホルダーと共有できるツールへ
LLMによる一次評価と、Notebook上のインタラクティブな可視化（ipywidgetsやitablesを活用）から、実験結果に対してある程度の確証を得られます。もちろん、最終的な意思決定のためには実験結果をまとめた資料を作成しますが、その補足資料として、実際のロジック比較をユーザーのクリック履歴と併せて確認できる環境を用意しておくと、資料の納得感を大きく高めることができます。
そこで、ロジックによる記事リストの違いをURL一つで誰でも確認できる形にするため、Geminiを活用して Google Apps Script (GAS) による比較WebApp を作成しました。
「仕様を伝えるだけ」でツールが完成する
「出力された新旧データとLLMの評価コメントを読み込み、左右に対比させてスクロール同期させたい」といった要件をGeminiに伝えるだけで、ベースとなるコードが生成されました。
Notebookの拡張版として、詳しく見たい人がそれぞれの視点で定性評価を行える環境を短時間で構築することで、エンジニアはフロントエンドの実装に時間を取られることなく、 「誰でも気軽に評価に参加できる環境」 を最小コストで実現できたと言えます。
この程度の規模であればGeminiへの指示一発でほぼ完成形まで持っていけます。WebAppへのデプロイ手順も含めてGeminiが丁寧に教えてくれるので、GASに詳しくない方でもぜひ気軽に作成してみてください。
まとめ：コンテキストを繋ぐ設計が開発を変える
今回の実験を通じて、重要なのは個々のLLMモデルの性能比較ではなく、 「複数のモデル間でどうコンテキスト（文脈）を繋いでいくか」 という設計にあると実感しました。
- Gemini (Deep Research/Canvas)：広範なリサーチと構造化
- Copilot / Claude：文脈を理解した上での実装
- Gemini (Judge/WebApp)：大量評価と結果の可視化
このリレーを構築することで、エンジニアは「コーディング」や「データ集計」といった作業から解放され、本来注力すべき 「仮説検証のデザイン」や「意思決定」 により多くの時間を割くことが可能になります。
生成AIを活用した開発プロセスの一例として、参考になれば幸いです。
