こんにちは。タイミーでAI・データサイエンス部に所属している栁です。 タイミーでは、募集内容やレビューなどの投稿コンテンツを審査するContent Moderationの仕組みにLLMを導入しています。この領域で品質を継続的に高めるには、プロンプトやモデルの改善だけでなく、評価データ、本番ログ、そして審査に関するドメイン知識を接続する仕組みが欠かせません。 本記事では、その評価・改善ループと、ドメインエキスパートの専門知識をループに組み込むプロセスの設計について、取り組みを紹介します。 Content Moderationの二つの課題：誤判定を減らし、正解を定義する Content Moderationとは、ユーザーの投稿が規約や法令、プラットフォームの安全性基準に違反していないかを確認し、必要な対処を行うプロセスです。タイミーでは、審査の品質向上を目的として、審査フローにLLMを導入しています。 Content ModerationでLLMを活用するうえでは、二つの難しさがあります。 一つは、求められる判定品質の高さです。一般的に、Content Moderationでは二種類の誤判定がそれぞれ異なるリスクにつながります。 見逃し（False Negative） ：違反コンテンツを通してしまい、プラットフォームの健全性・安全性を損なう 空振り（False Positive） ：正常なコンテンツを差し戻し、掲載遅延やユーザーの機会損失を生む 「それなりに判定できる」だけでは十分ではありません。それぞれのリスクを踏まえ、バランスを考えながら適切な品質を目指す必要があります。 もう一つは、正解を定義する難しさです。違反かどうかの判断には深いドメイン知識が必要であり、何を正解とするかは自明ではありません。運用の中では、既存の審査ルールだけでは判断できない事例も出てきます。そのため、LLMの判定を改善するだけでなく、判断の基準そのものを明確にしていく必要があります。 つまり、Content Moderationでは、 「LLMの誤判定をどう減らすか」 と 「何を正解とするかをどう定義するか」 の二つが課題になります。継続的に品質を高めるには、この両方を改善対象として捉えることが重要です。 1. 比較できる土台を作り「雰囲気評価」から脱却する プロンプトやロジックを変更した際、いくつかの出力を見て「なんとなくよくなった」と判断するだけでは、評価が属人的になり、変更の妥当性を再現可能な形で検証できません。 再現性のある評価の出発点になるのが、信頼できる ゴールデンデータセット です。入力と期待する出力のペアを用意し、同じデータセットに対して現行のロジックと改善案を比較することで、変更の妥当性を客観的に評価します。 正解ラベルに加え、分析に必要な情報を残す データセットでは、ラベルの正確性と事例の網羅性を重視します。また、単に正解ラベルだけではなく、適切なメタデータを付与しておくと、評価・分析の切り口として役立ちます。 以下は、管理するメタデータの一例です（スキーマを説明するための例で、実際の投稿や審査基準を示すものではありません）。 reason ：判定に至った理由や根拠を残す taxonomy ：ケースを分類し、事例の網羅性を把握する difficulty ：典型例と判断の難しいエッジケースを区別する { " input ": " 〜な方は応募をご遠慮ください... ", " expected_output ": " REJECTED ", " metadata ": { " reason ": " 募集を不当に限定するためNG ", " taxonomy ": " 不当な募集条件 ", " difficulty ": " easy " } } 一方で、管理項目を増やすほどメンテナンスコストも上がります。最初から完璧なスキーマを目指すのではなく、小さく始め、評価・分析に必要になった項目を段階的に拡充します。 ゴールデンデータのスコアは本番性能そのものではない また、ゴールデンデータで評価する際は、データセットの用途を明確にしておくことも必要です。 ゴールデンデータはさまざまなケースを収集した事例集として、ロジック間の相対比較や、個別ケースに対する振る舞いの確認に役立ちます。一方、事例の網羅性を重視して集めたデータは、一般に本番環境の分布を代表しません。そのため、スコアをそのまま本番環境における性能とみなすことはできません。 改善案を比較するための評価と、本番品質を把握するための評価は、役割が異なります。この区別が、次の改善ループの設計につながります。 2. 改善ループの全体像：Inner LoopとOuter Loop 開発と本番を接続しデータセットを育てる ゴールデンデータを一度作って終わりにすると、リリース後に本番環境で明らかになった問題が、評価やその後の改善に反映されません。そこで、開発時と運用時の二つのフィードバックループを接続します。 Inner LoopとOuter Loopによる評価・改善ループの全体像 Inner Loopは、ゴールデンデータに対して審査ロジックを評価し、その結果をもとに改善するループです。対象には、プロンプトやモデルを含むLLM Workflowはもちろん、「何を違反とするか」を定めた審査ポリシーも含まれます。評価で見つかった問題に対して、推論の仕組みと判断基準の両方から改善を検討します。 Outer Loopでは、本番環境の入出力を監視して品質を把握するとともに、誤判定が疑われる事例を収集します。収集した事例の正解と根拠を確認し、正解ラベルを付けてゴールデンデータに追加することで、開発時の評価に還元します。 Inner LoopとOuter Loopを接続した全体の改善プロセスは以下のとおりです。 本番環境で入出力を記録・監視する 誤判定が疑われる事例を収集する 事例の正解と根拠を確認し、データセットに追加する 拡充したデータセットで審査ロジックを評価・改善する 改善をリリースし、再び本番で監視する 二つのループの接続によって、運用で得た知見が次の評価に活用されます。改善するのはロジックだけではなく、改善を判断するためのデータセット自体でもあります。 最初から完全を目指さない 最初から完璧な改善ループを構築することは困難です。そこで、以下のようなステップを踏みつつ、段階的に改善ループを発展させていくことを考えます。 Level 状態 Level 1. 主観による評価 品質を担保したデータセットがなく、属人的に判断している Level 2. Inner Loopの確立 ゴールデンデータに基づく評価・改善が開発環境で回っている Level 3. Outer Loopとの接続 本番のエラーケースが継続的に収集され、改善に使われている Level 4. 評価とリリースの接続 明確なリリース基準に基づき、自動デプロイまでつながっている タイミーの現在地としては、本番のエラーケースを改善につなぐ段階（Level 3相当）にあります。最初から評価もリリースも完全自動化するのではなく、少数の事例から評価を始め、運用の中でプロセスやリリース基準をブラッシュアップしながら、ループ自体を育てていくことが重要です。 ツールの活用によりループを素早く回す LLMOpsツールは、評価や監視に必要な機能を通じて、改善ループを円滑に回すために役立ちます。多くのLLMOpsツールは、改善ループ構築のための以下のような機能をサポートしています。 Dataset & Experiment ：データセットの管理・バージョニング、オフライン評価・実験管理 Tracing ：本番ワークフローの追跡、トレースからデータセットへの事例追加 Online Evaluation ：LLM-as-a-Judgeなどによる本番環境での継続的な品質評価、品質劣化の検知 Langfuse、MLflow、Datadog Agent Observabilityなどは、こうした機能を提供する代表的なツールです。ただし、重要なのはツールの導入自体ではなく、本番ログ、評価データ、実験結果がつながる状態を作ることです。 また、個々の作業を効率化するには、AI Skillの活用も有効です。エラー候補の抽出、傾向ごとのグルーピング、データセットへの追加提案など、人手で行うとボトルネックになりがちな作業をAI Skillとして定型化することで、改善ループをより素早く回せます。 3. 誤判定の原因を切り分ける：LLM Workflowと審査ポリシー 改善ループの中でエラー分析を進めると、プロンプトやロジックの調整だけでは解決できないケースにぶつかります。どれほどLLM Workflowの品質を高めても、審査ポリシーに事例の扱いが明文化されていなければ、「何を正解とすべきか」を確定できないためです。 Content Moderationにおける審査ロジックは、「どう判定するか」を担うLLM Workflowと、「何を判定するか」を定める審査ポリシーの二つから成り立ちます。エラーケースごとに、判定の仕組みに問題があるのか、判断基準に曖昧さがあるのかを切り分け、それに応じた改善を進めることが大切です。 審査ロジックはLLM Workflowと審査ポリシーから成り立つ この切り分けは、改善における役割と責務を考える上でも欠かせません。エンジニアやデータサイエンティストは、判定システムの設計・実装を通じて「どう判定するか」に責任を持ちます。一方、ドメインエキスパートは、審査基準の定義や個々の事例に対する最終判断を通じて「何を判定するか」に責任を持ちます。 改善には双方の関与が欠かせません。判定の仕組みと判断基準のどちらか一方しか見直せなければ、改善は行き詰まります。 私たちも、実際にLLMの評価・改善を進める中で、次のような難しさに直面しました。 エンジニアだけでは判断が難しい事例があった ：当初は、改善と評価をエンジニア中心に進めようとしました。しかし、専門知識が必要な事例では、期待する判定やロジックの妥当性の判断が難しく、ドメインエキスパートの知見を取り込む必要があると気づきました。 知見を審査ポリシーに還元する仕組みに改善の余地があった ：誤判定の分析を進める中で、現場の知見や例外的な事例の扱いを、判断基準に取り込む必要があると分かりました。個別の事例への対応にとどまらず、得られた知見を次の評価・改善につなげる仕組みを強化する必要がありました。 こうした経験から、必要なときにドメインエキスパートへ相談するだけでなく、その専門知識を審査ポリシーやデータセットに継続的に還元できるプロセス自体を適切に設計することが重要だと気づきました。 4. 専門知識を改善ループに組み込む ポリシー更新とアノテーションに介入ポイントを設ける こうした学びを踏まえ、私たちはドメインエキスパートが関与するタイミングと役割を整理し、専門知識を継続的に取り込めるプロセスを整えてきました。 一つ目の介入ポイントは、審査ポリシーの更新です。その前提として、ポリシーを継続的に更新・管理できる形に整えます。例えば、違反種別ごとに以下の情報を関連づけて管理します。 判定基準 ：抽象化したルール OK／NG例 ：ルールを補う具体例 個別事例 ：エッジケース 加えて、Draft → Review → Active → Archiveというライフサイクルと、バージョニングのルールを定義します。エラー分析で見つかった論点をもとに、エンジニアが改定案を起票し、ドメインエキスパートがレビューして内容を決定したうえで有効化します。基準を定義する責任はドメインエキスパートにあり、エンジニアは論点を整理し、議論を前に進める役割を担います。 現場の知識をプロンプトへの追記だけで済ませず、判定基準や具体例として構造化することで、審査ポリシーそのものを継続的に改善できます。 二つ目の介入ポイントは、本番から収集した事例に正解ラベルを付けるアノテーションのプロセスです。私たちは、以下の流れでアノテーションを行っています。 誤判定が疑われる事例を収集する： 本番ログから事例を抽出します。AI Skillなどによる自動化も活用します 既存ポリシーに基づいて一次判定する： 既存の基準で判断が明確なケースはエンジニアが一次判定し、複数人によるダブルチェックで正確性を担保します 判断できないケースをエスカレーションする： ドメインエキスパートに判断を依頼し、必要に応じて、その判断を審査ポリシーに反映します このプロセスでは、既存の基準で判断できる事例と、基準そのものの検討が必要な事例を分けています。個別の正解ラベルを得るだけでなく、判断できなかった事例を審査ポリシーの改善にもつなげることが重要です。 タスクの性質に応じて適切な協業体制を選ぶ ここまで紹介したプロセスは協業の一例です。タスクの性質に応じて、エンジニアとドメインエキスパートの役割分担を適切に選択することも大切です。 LLMの1回の呼び出しで完結する軽量なタスクであれば、エンジニアが評価基盤を提供し、ドメインエキスパートが自力で評価・改善・リリース判断を進めるスタイルが考えられます（エキスパート自律型）。この方式には、エンジニアの負荷を抑えながら、専門知識を持つドメインエキスパートが主体となって素早く改善を進められるという利点があります。 一方、複雑なLLM WorkflowやAgentの設計が必要なタスクでは、エンジニアが改善を牽引し、ドメインエキスパートが専門知識と意思決定を提供するスタイルが適しています（エンジニア主導型）。綿密な連携が必要ですが、LLM Workflowと審査ポリシーの両方を一体的に改善できます。 このように、責務を固定的に分断するのではなく、タスクと双方の体制に合わせて、改善が滞らない役割分担を選ぶことが大切です。 まとめ：円滑なプロセスを設計し、愚直に改善を回す LLMの評価・改善に、銀の弾丸はありません。実際のエラーケースに一つずつ向き合い、その結果を次の評価・改善に活かすという地道な取り組みが必要です。 この泥臭さの中で、継続的な改善を進めていくために重要なのは、次の三点です。 信頼できるゴールデンデータを用意する ：感覚ではなく、同じ土台で変更を比較できるようにする 開発と本番を接続して改善を回す ：本番のエラーを評価データに還元し、ロジックとデータセットをともに育てる 専門知識を取り込む仕組みを設計する ：正解ラベルの判断と審査ポリシーの更新を、改善ループに組み込む プロンプトを変更するだけでは、評価の信頼性や判断基準の曖昧さは解消できません。モデルの出力を改善することと同じくらい、正解を定義し、評価し、運用から学び続けられるプロセスを作ることが重要です。 We’re Hiring! タイミーでは、データサイエンスやエンジニアリングの領域で、共に成長し、革新を推し進めてくれる新たなメンバーを積極的に探しています！ 現在募集中のポジションはこちらです。カジュアル面談も行っておりますので、興味のある方はぜひお気軽にお申し込みください！

はじめに こんにちは、株式会社タイミーでデータサイエンティストをしている藤井です。 普段は推薦エンジンの改善を担当しています。 最近は推薦エンジンそのものの改善に加えて、LLM を使って推薦エンジンの改善サイクル（仮説→実験→評価）をいかに速く回すかにも取り組んでいます。 5か月前の前回記事 では、Claude の Skill を使って半自動で推薦システムを改善する取り組みを紹介しました。 現在はそこから一歩進んで、推薦エンジンの自動改善の運用を開始しており、以下のような構成をとっています。 エージェントは Claude Agent SDK で実装しています。 図1. 推薦エンジン自動改善システムの全体像 図2. AI Agent Block同士の組み合わせについて 1回の改善サイクルは、次の順に進みます。 仮説構築 → 実装 → レビュー → 評価 → 長期記憶への書き込み → 仮説構築に戻る ただ、実際に回してみると課題も見えてきました。 たとえば、体感で研究案の半分ほどが損失関数の微調整になります。 また、GPU コストに見合わない小さな改善案も出てきます。 さらに、長期記憶のステップを外して回した場合は、以前試した案をそのままもう一度出してきたり、過去に失敗した案と似た案を出してきたりしました。 これらは推薦に固有の問題ではありません。 「似た案ばかり出る」「コストの高い実験を無駄打ちする」「結果を次に活かせない」 は、AI に研究を自動で進めさせる自動研究（AI が自分で仮説を立て、実験し、次を決めるループ）では、分野を問わず起きる問題です。 最近の自動研究の論文は、数学・化学・機械学習など題材は違いますが、これらの問題に取り組んでおり、その解き方の多くは推薦にも応用できます。 本記事では、自動研究の最近の論文をもとに、上のループのどこを改善するかを次の3つの問いで考えます。 何を試すか （仮説構築）：似た案ばかりにならないようにする 実験予算をどこに使うか （仮説構築と実装の間）：実装・評価に進める案を、実行コストに見合うものだけに絞る 今の結果をどう次に活かすか （長期記憶 → 仮説構築に戻る）：途中の結果や教訓を、次の案出しで使える形で残す なお、この後紹介する仕組みの多くは、タイミーでまだ実装していない 「これから試したい設計の候補」 です。実際に運用しているのは上の図の範囲です。 論文に入る前に、まず OpenAI のエージェント群が数学の難問（Navier–Stokes 方程式の問題）を解いた事例を見ておきます。 多数のエージェントを協調させて未解決問題を解いた事例で、その動かし方に、本記事の3つの問いに対応する工夫が含まれているからです。 前置き：エージェント群が数学の難問を解いた仕組み（Navier–Stokes） 2026年9月、OpenAI は、流体の動きを表す Navier–Stokes 方程式に関するミレニアム懸賞問題（数学の代表的な未解決問題に懸けられた懸賞）を、内部モデルで動くエージェント群が解いたと発表しました。 約88時間で解に到達し、その後 Lean（証明が正しいかを機械でチェックする言語）で検証されています [1] 。 数学の中身は本記事では扱わず、エージェントの動かし方に絞って紹介します。 ⚠️ 注意：実装の詳細は非公開です。 OpenAI はハーネス（エージェントを動かす周辺の仕組み）の実装（群の数と大きさ、通信の宛先の決め方、集約の頻度と形式、実行環境、人間の介入の範囲など）を公開していません。ここでは OpenAI の公式記事 [1] と、OpenAI の研究者 Noam Brown が Dwarkesh Podcast（AI 研究者などへのインタビュー番組）で語った内容 [2] に書かれている範囲だけを紹介します。 OpenAI の公式記事に書かれていること [1] エージェントを複数の群に分け、通信を同じ群の中に限定した。Navier–Stokes の解に到達した群では、約1万のエージェントが同時に稼働していた 群ごとに異なる問題設定を割り当てた。Navier–Stokes では、証明を目指す問題と反証を目指す問題を別々の群に担当させた 一定時間が経過した後、Codex（OpenAI のコーディングエージェント）が各群の有用な中間成果を集約し、追加のプロンプトとして各群に共有した より易しい関連問題（外力なしの Euler 方程式。粘性を無視した流体の方程式）が先に解けたことを受け、他のミレニアム懸賞問題に割り当てていたエージェントを Navier–Stokes に移し、Euler 方程式の解をプロンプトに加えた 実行中に、より訓練の進んだモデルへエージェントを切り替えた Noam Brown が語っていること [2] タスクを割り振る役割を頂点に置く固定的な階層構造は採用せず、他のエージェントへメッセージを送るための単純な通信手段だけを与えた。エージェント同士がどのように協調するかは、エージェント自身に委ねた 特別な工夫をしなければ、各エージェントが互いに連携せず、それぞれ独立して問題に取り組んでしまう。そのため、協調する能力をモデルの訓練によって身につけさせた 約1万のエージェントを動かしたことが結果にどの程度寄与したかは検証していない。成果の主因はモデル自体の能力であり、マルチエージェントの寄与は限定的だと述べている この事例から読み取れること 公開情報は断片的ですが、特に次の点に注目しています（以下は筆者の解釈です）。 最初の3点は、この後の問い1〜3にそれぞれ対応します。 1. 群ごとに異なる問題設定を割り当てている 約1万のエージェントがいても、全員が同じ情報を見ていれば似たアプローチに偏ります。 そこで通信を群の中に限り、証明と反証という対立する問題設定を別々の群に割り当てて、群ごとに違うアプローチを試させています。 2. 易しい関連問題が解けてから、Navier–Stokes に資源を移している Euler 方程式の問題は、Navier–Stokes にどれだけ資源を配分するかを、少ないコストで決めるための予備実験だったと考えられます。 3. 途中の成果を集めて、各群に戻している Codex が各群の有用な中間成果を集約し、追加プロンプトとして群に戻しています。 Euler 方程式の解も、Navier–Stokes のプロンプトに入れています。 ある群で得た結果を、他の群でも使っています。 集約を「ときどき」にしているのは、共有しすぎて群ごとの多様性を潰さないためだと考えられます。 補足：外側の仕組みは最小限にし、協調は訓練で身につけさせている 固定の階層は置かず、単純な通信手段だけを渡して、協調の仕方は訓練でモデルに身につけさせています。 API 経由でモデルを使う私たちは、モデルの外側の仕組みで工夫することになります。 以降の章では、論文がこうした外側の仕組みをどう作り込んでいるかを見ていきます。 ※公式記事によると、問題設定の割り当て、Navier–Stokes への資源の集中、中間成果の集約といった方針は、研究チームが決めています。それ以外の判断に人間がどこまで関与したかは公開されていないため、ここでは「人間＋エージェント群の仕組み」として扱います。 自動研究の論文を3つの問いで読む ここからは、自動研究の最近の論文を、冒頭の3つの問いに沿って見ていきます。 研究 誰の研究か 一言で言うと 対応する問い Co-Scientist Google 仮説を対戦させて順位を付ける。似た案どうしを優先して戦わせ、未探索の領域の仮説も出させる 1. 多様性 EvoDiverse Georgia Tech ほか 「既存の延長の枠」と「別系統の枠」を並べ、ときどき案を交換する 1. 多様性 Arbor 中国人民大学 / Microsoft Research 仮説を木で管理し、捨てた理由を次の案出しの制約にする 1. 多様性 RPM Meta まだ実行していない改良案を、2案ずつ比べて1つに絞る 2. 予算配分 EEM 中国科学院 計算技術研究所 / Baidu 過去の経験から改善しないと分かる案は実験せずに見送り、経験が足りなければ予備実験で補う 2. 予算配分 PrimeScientist カリフォルニア大学サンディエゴ校 / ジョンズ・ホプキンス大学 残り予算に応じて、手広く試すか絞るかを切り替える 2. 予算配分 MARS Google Cloud AI Research 新しい案をその時点のベストと比べて教訓にし、他の枝の案でも使う 3. 結果の活用 MLEvolve Shanghai AI Lab ほか 行き詰まったら、自分の枝の履歴や他の枝の良い解を次の案に渡す 3. 結果の活用 AgentX-Model 快手（Kuaishou） 推薦の本番で、最良ラウンドのコードと評価条件を次の実験に引き継ぐ 3. 結果の活用 問い1：何を試すか —— 多様性を設計する 筆者の仕組みでも、体感で研究案の半分ほどが損失関数の微調整でした。 エージェントに自由に案を出させると似た案に偏りがちで、推薦だと損失関数の微調整や、モデルの小さな変更ばかりが並びます。 前置きの Navier–Stokes の事例では、通信を群の中に限り、証明を目指す群と反証を目指す群を分けることで、多様性を保っていました。 以下の3本の論文も、「多様な案を出して」と頼むだけでなく、案の選び方や枠の分け方といった構造で多様性を保とうとしています。 ① 似た案どうしを戦わせ、まだ探っていない領域の仮説も出させる（Co-Scientist） Google の Co-Scientist [3] は、研究者が研究の目標を自然言語で渡すと、仮説を提案してくれるシステムです。 中では、仮説を出す役、批判する役、順位を付ける役、改良版を作る役、似た仮説同士を見分ける役など、役割の違うエージェントが並行して動いています。 土台にあるのはトーナメントです。 仮説に「何点」と付けるのではなく、2つの仮説を討論させて「どちらが良いか」を判定し、その勝敗の積み重ねから順位を付けます。 仕組みはチェスや将棋のオンライン対戦のレーティング（Elo レーティング）と同じで、各仮説が持ち点を持ち、強い相手に勝てば大きく上がり、弱い相手に負ければ大きく下がります。 この持ち点の高い順が仮説の順位になり、研究者はこの順位の上位から、実験で確かめる仮説を選びます。 ただ、上位の案を改良するだけだと、候補は似た案ばかりになります。 Co-Scientist は、このトーナメントに、候補の幅を保つ工夫を3つ加えています。 似た案どうしを優先して対戦させる ：専用のエージェントが仮説どうしの似ている度合いを測り、似た案をまとめたり、重複を除いたりします。対戦の組み合わせもこの似ている度合いを使って決め、似た案どうしが当たりやすくなっています。論文は、この仕組みで重複を除き、目標に関わる幅広い案を示せると説明しています。筆者は、似た案どうしで優劣が付くため、似た案が上位を独占しにくくなると考えています。 まだ探っていない領域の仮説を出させる ：新しい仮説を出すときは、既存の仮説と、トーナメント全体を振り返った講評を読ませ、まだ探っていない領域を見つけさせます。改良版を作る役にも、上位の案を改善したり組み合わせたりする指示のほかに、一部の既存の案とは異なる発想で新しい案を作る指示があります。 改良版は元の案を上書きしない ：改良版も改良前の案も残し、どちらも同じトーナメントで競わせます。候補が「最新版だけ」に絞られず、改良が失敗しても元の案は失われません。 ② 「既存の延長の枠」と「別系統の枠」を並行して持つ（EvoDiverse） Georgia Tech などの EvoDiverse [4] （ICML 2026）は、「スコア上位の案だけを残して改良を続けると、候補が似た案ばかりになる」という問題を扱った研究です。 EvoDiverse が改善の対象とするのは、次のような探索です。 LLM に案を出させて採点し、スコアの良かった案を複数選んで、それらを元に新しい案を作らせます。 新しい案も採点し、この手順を繰り返します。 論文では、この手法を「進化的な探索」、新しい案の元にする案を「親」と呼びます。 毎回スコア上位の案だけを元にすると、次の案はそれを少し変えたものになり、それがまた上位に残って次の元にする案になります。 これを繰り返すと、数回のうちに候補のほとんどが同じ案を少し変えただけのものになります。 最初はスコアが低くても改良すれば伸びたかもしれない別系統の案は、一度も元にする案に選ばれないまま消えていきます。 そこで EvoDiverse は、候補を入れておく枠を2つ用意し、枠ごとに「次に元にする案をどう選ぶか」を変えます。 既存の延長の枠 ：元にする案はほぼスコア順に選びます。今いちばん良い案を、少しずつさらに良くしていきます 別系統の枠 ：元にする案はスコアの差をあまり反映せずに選びます。たとえば1位の案と5位の案が、同じくらいの確率で選ばれます。スコアがまだ低い別系統の案にも元にする案に選ばれる機会があるので、改良される前に消えずに済みます さらに工夫が2つあります。 枠ごとに LLM への指示を変える ：別系統の枠では「構造が大きく異なる案を出して」、既存の延長の枠では「良いとわかっている案を改良して」と指示します 有望な案だけを既存の延長の枠に移す ：数回ごとに、「別系統の枠」にある案を「既存の延長の枠」に移します。ただし移すのは、「既存の延長の枠」にある案とスコアを比べて勝負になりそうなものだけです。無条件に移すと2つの枠の中身が似てしまい、枠を分けた意味がなくなります 結果として、分子設計・数式の発見・アルゴリズムの発見のいずれでも、 同じ評価回数で案の質と多様性がともに上がっています 。 ③ 改善しなかった研究の方向を禁止し、別の研究の方向の仮説を出させる（Arbor） 中国人民大学と Microsoft Research の Arbor [5] は、これまでに試した案を木構造で管理するシステムです。 たとえば「モデルの精度を上げる」という目標なら、「データを増やす」「モデルを大きくする」のような研究の方向を木の1段目に、「データを2倍にする」「外部データを足す」のような具体案をその下の段に置きます。 具体案を1つ試すたびに、結果と「なぜそうなったか」をその案のところに書き込みます。 この木を使って、同じ研究の方向の探索を続けないようにしています。 研究の方向ごとに結果を教訓にまとめ、否定された研究の方向は次の案出しの制約にする ：具体案の結果がたまると、上の研究の方向に「データを増やしても、ノイズが増えるだけで精度は上がらない」のような結論をまとめます。見込みがなければその研究の方向を打ち切り、理由を次の案出しに破ってはいけない制約として渡します。打ち切った研究の方向には戻れないので、次の案は別の研究の方向から出すしかありません 同じ研究の方向で現ベストを超えなければ、新しい研究の方向を加えさせる ：ある研究の方向の最近の具体案がどれも現ベストを超えなければ、失敗のパターンをまとめさせたうえで、1段目に新しい研究の方向を足すよう促します 全体が伸び悩んだら、発想の転換を促す ：改善しない実験が続くと、回数に応じて「警告」→「発想を大きく変えろ」→「停止」の信号を段階的に出します Arbor の要点は、木で履歴を管理すること自体よりも、 研究の方向ごとに結果を教訓にまとめ、否定された研究の方向を次の案出しの制約にすることで、同じ研究の方向の案を出し続けるのを防ぐ 点にあります。 問い2：実験予算をどこに使うか —— 実行の前に選ぶ 実際に改善サイクルを回してみると、GPU コストに見合わない小さな改善案も出てきます。 エージェントは改良案を一瞬で何十個も書けますが、学習と評価には数時間かかり、推薦ならその先に本番 A/B テストの枠という強い制約もあります。 どの案に実行予算を使うかは、研究の進み具合を左右する重要な要因です。 Navier–Stokes の事例でも、易しい Euler 方程式の問題が解けてから、Navier–Stokes に資源を移していました。 以下の研究では、実行する価値があるかを改良案ごとに事前に判断します。 ① 学習・評価の前に、過去の実験結果を根拠に LLM に案を選ばせる（RPM） Meta の RPM（Research Preference Models） [6] は、エージェントが書いた改良案の中から「実際に学習・評価するのはどれか」を、事前に LLM に選ばせる仕組みです。 たとえば15個の改良案から1個を選び、その1個だけを学習・評価します。 選び方の工夫は3つです。 2案ずつ比べて勝ち残りを決める ：「この案は何点か」ではなく「A と B のどちらが伸びそうか」を判定させ、勝った方を次の比較に進めます（Co-Scientist と同じ考え方） 判断材料として過去の実験結果を渡す ：これまでに学習・評価した案のコードとスコアを一緒に見せます。論文の分析では、過去の実験結果を根拠にした判断は正解率が高く、「構造的に良さそう」といった印象だけの判断は正解率が低くなっていました 小さく試してから選ぶ ：短時間の予備実験をしてから選ぶ版も用意しており、こちらの方が成績が良くなりました 選別なしで24時間かけて届いた成績に、 約15時間（実行予算の3分の2以下） で到達しています。 ② 過去の経験から改善しないと分かる案は、実験せずに見送る（EEM） 中国科学院 計算技術研究所と Baidu の EEM（Experimental Experience Modeling） [7] は、案を試す前に「そもそも実験する必要があるか」を判断する仕組みです。 過去の実験から「この条件では、この変更をしても精度は上がらなかった」のような経験をまとめてためておき、新しい案が来たら関連する経験を探して判断材料にします。 改善しないと分かる案は、実験せずに見送る ：似た案で改善しなかったと分かっていれば、実験せずに見送ります 経験だけで判断できなければ、判断に必要な点だけを小さな予備実験で調べる ：たとえば「データが少ない条件でも効くか」だけが分からなければ、その条件だけを小さく試します 結果を経験に追加する ：失敗した実験や途中で止めた実験も含めて経験に加え、次の判断に使います 既存の自動研究システムより成績が高く、LLM とのやり取りも少なくて済んでいます。 ③ 残り予算に応じて、手広く試すか絞るかを切り替える（PrimeScientist） カリフォルニア大学サンディエゴ校とジョンズ・ホプキンス大学の PrimeScientist [8] は、次に予算を使う案を評価に応じた確率で選び、残り予算が減るほど評価の高い案が選ばれやすくなるようにする仕組みです。 Arbor と同じように、試している案を木の形で持ち、それぞれの結果を書き込んでおきます。 序盤は評価の低い枝も選ばれるようにし、終盤は評価の高い枝を選びやすくする ：序盤は評価の低い枝にも予算を回し、残り予算が減るほど評価の高い枝に集中させます。 採用しなかった案も木に残す ：評価の低い案とその結果も消さずに残し、後から戻れるようにします 評価済みの案を発展させるときは、本当に違う案だけを出させる ：ハイパーパラメータだけを変えた案は禁止し、別の仮説を最大3つまで出させます 12の AI 研究タスクで、同じ予算のもと既存システム（AutoResearch）より 平均スコアが10.3%高く、試行回数は約半分 でした。 問い3：今の結果をどう次に活かすか 改善サイクルを回すと、案ごとの結果が積み上がっていきます。 ただ、結果を記録しておくだけでは次の案は良くなりません。 筆者の仕組みでも、長期記憶のステップを外すと、同じ案を繰り返したり、過去の失敗と似た案が出てきたりしました。 問題は、結果を どんな形にまとめ、次のどの判断に渡すか です。 Navier–Stokes の事例では、Codex が各群の有用な中間成果を集約し、追加プロンプトとして群に戻していました。 以下の3本も、結果のまとめ方と渡し先を工夫しています。 ① ベストとの比較で、結果を教訓にまとめる（MARS） Google Cloud AI Research の MARS [9] （ICML 2026）は、試した案の結果を教訓にまとめてため、次の案づくりに使う仕組みです。 結果を単独で見ても何が改善につながったのかは分かりにくいため、新しい案をその時点で一番良い案と比べ、違いに絞って次の3点を書き残します。 何を変えたか ：例）ベストとの違いは、学習率を下げたことだけです 結果とその理由 ：例）損失の振れが収まり、検証スコアが0.81から0.83に上がりました。学習時間は変わっていません 今後も使えるルール ：例）この種のデータでは、学習率を下げると改善します 渡し方にも工夫があります。 教訓は全体で共有し、使ったら引用させる ：次の案を作るときに教訓を参照させ、どの教訓を使ったかを明示させます 重複を除き、直近の教訓だけを渡す ：既存の教訓と内容が同じ教訓は捨て、渡すのは直近30件までにします 教訓がたまるほど案を高度にする ：教訓がないうちは軽いモデルから始め、たまるにつれて教訓を取り込んだ高度な案に進みます 案の約66%が既存の教訓を使っており、 使われた教訓の63%は別の枝（探索の系統）で得られたもの でした。 MLE-bench（機械学習コンペのベンチマーク）では、同じ条件で比べたオープンソースの仕組みの中で最も高い成績を出しています。 ② 伸び悩んだら、同じ系統の過去の試行や他の系統の良い解を、次の案づくりに渡す（MLEvolve） Shanghai AI Lab などの MLEvolve [10] は、前処理から学習・予測までのパイプライン一式を、木探索で少しずつ改良していく仕組みです。 従来の木探索では枝（改良の系統）が互いに孤立していて、ある枝で効いた工夫が別の枝に伝わりませんでした。 MLEvolve は、行き詰まりの度合いに応じて、次の案を作るときに渡す過去の結果を切り替えます。 同じ枝で3回続けてスコアが更新されない ：同じ枝の直近の試行を振り返らせ、何が改善につながり何が失敗したかを踏まえて次の案を出させます。例）正則化をいくつ試しても頭打ちだった枝で、エージェントが「ボトルネックはモデル構造だ」と判断し、構造を変える案を出しました 探索の後半で、他の枝にスコアの高い解がある ：他の枝の上位の解を参考として渡します。例）Focal Loss で頭打ちの枝に、別の枝で改善につながっていた Asymmetric Loss を取り込みました 全体のベストスコアが6ステップ更新されない ：複数の枝の良い部品を組み合わせ、新しい枝の出発点にします 部品を1つずつ外す実験では、「同じ枝の振り返り」を外したときの落ち込みが最も大きく、 メダル獲得率が66.7%から33.3%に半減 しました（9タスクでの比較）。 著者は、直近の履歴を使うことが同じ失敗の繰り返しを防いでいると解釈しています。 他の枝の結果を渡すのは、行き詰まったときだけです。 筆者は、これが Navier–Stokes で集約を「ときどき」にしていたのと同じく、枝ごとの多様性を保つ効果もあると考えています。 全体では、MLE-bench において12時間の予算（標準の半分）で平均メダル獲得率65.3%と、比較した中で最高の成績です。 ③ 最後ではなく一番良かったラウンドから次の実験を始め、進み具合を3つの基準で測る（AgentX-Model） 快手（Kuaishou）の AgentX-Model [11] は、産業用の推薦モデルの改善研究を、LLM エージェントに何週間も続けさせた本番運用の報告です。 次の実験を計画するエージェントと、実装・学習・評価をするエージェントを分け、実験が終わるたびに次の4つを引き継ぎます。 引き継ぐもの 次の実験で何を決めるのに使うか どのラウンドのコードと、その基準モデル どの実装から再開するか 比較対象・評価条件・測定値 どの結果どうしを比べてよいか 診断での観察と、未検証の仮説 原因を見分けるテストの設計 組み合わせる各実験の変更全体 重複の解消と、組み合わせ方の設計 特に参考になるのは次の2点です。 最後ではなく、一番良かったラウンドのコードを残す ：複数ラウンドにわたる189件の実験のうち、 48%で最後のラウンドが途中のベストを下回っていました 。最新版を上書きで引き継ぐと、良い出発点を失います 進み具合を3つの基準で別々に測る ：「本番モデルより良いか」「元にした実験（親）より良いか」「それ以前のどの祖先よりも良いか」。最も長く運用したシナリオで改良した実験を見ると、親と比較できる91件のうち、46件が親を上回りました。一方、祖先すべてと比較できる77件のうち、祖先すべてを上回ったのは7件にとどまりました。親との比較だけでは、一度下がったスコアが戻っただけなのか、新記録なのかを区別できません 4つのシナリオすべてで本番モデルの AUC を上回り（最大 +0.0237）、直近5件の本番 A/B テストでも改善を報告しています。 研究を踏まえて、改善ループをどう変えるか 前置きで見たとおり、既存のモデルを使う私たちが工夫できるのは、モデルの外側の仕組みです。 ここまでの研究を踏まえて、冒頭の改善ループの変え方を2つ考えます。 現状 仮説構築 → 実装 → レビュー → 評価 → 長期記憶への書き込み → 仮説構築に戻る 案1：仮説を2つの枠に分け、トーナメントで実装する案を選ぶ 仮説構築（ 既存の延長の改善策 / 別系統の改善策 ） → 長期記憶による足切り → 仮説プールから枠ごとのトーナメント → 実装 → レビュー → 評価 → 講評の作成 → 長期記憶への書き込み（ 結果＋講評 ） → 仮説構築に戻る 仮説構築 ：既存のモデルを改良する「既存の延長の改善策」と、構造が大きく異なる「別系統の改善策」を、別々の指示で出させます（EvoDiverse） 長期記憶による足切り（新） ：長期記憶に、同じ条件で同じ変更をして改善しなかった記録があれば、実験せずに見送ります。残った案には関連する過去の実験結果を判定材料として添え、見送った案も理由とともに記録します（EEM、RPM） 仮説プールから枠ごとのトーナメント（新） ：既存の延長の改善策どうし、別系統の改善策どうしで2案ずつ討論させ、得点を付けます。似た案どうしを優先して対戦させ、各枠の上位案を実装に回します。実装しなかった案や改良前の案もプールに残し、次のサイクル以降も対戦させます（Co-Scientist） 講評の作成（新） ：評価結果を見て、トーナメントで勝った案が実際に改善したか、どんな案が勝ちやすかったか、どんな案がまだ試されていないかをまとめさせ、長期記憶に残します。次の仮説構築では、この講評をもとに、まだ試していない種類の別系統の改善策を出させます（Co-Scientist） 案2：仮説方向ごとに実験を積み上げ、集約（リリース）は別の実験として行う 案2では、「特徴量」「モデル構造」といった仮説方向を決め、案1のループを仮説方向ごとに独立して回します。 それぞれの成果を組み合わせて本番に載せる集約（リリース）は、別の実験として行います。 仮説方向ごとの実験 〔仮説方向ごとに〕 仮説構築（ 既存の延長の改善策 / 仮説方向内での新規の改善策 ） → 長期記憶による足切り → 仮説プールから枠ごとのトーナメント → 実装 → レビュー → 評価 → 講評の作成（トーナメントの講評＋進み具合の判定） → 長期記憶への書き込み → 仮説構築に戻る 仮説構築 ：その仮説方向で過去最高だったモデルを改良する「既存の延長の改善策」と、同じ仮説方向の中でこれまでと異なる手法を使う「仮説方向内での新規の改善策」を、別々の指示で出させます（EvoDiverse） 仮説プールから枠ごとのトーナメント（新） ：同じ仮説方向・同じ枠の案どうしで対戦させます。次の実験は、最後のラウンドではなく、一番良かったラウンドのモデルから始めます（Co-Scientist、AgentX-Model） 講評の作成（新） ：トーナメントの講評に加えて、「本番モデルより良いか」「直前の親実験より良いか」「その仮説方向の過去最高を更新したか」の3つの基準で進み具合を判定し、次の仮説構築に渡します（AgentX-Model） 仮説方向どうしは結果を直接見せ合わない ：探索の多様性を保つためです（Navier–Stokes の群の分け方） 集約（リリース）実験 各仮説方向の過去最高を集める → 組み合わせ仮説の作成 → 仮説プールからトーナメント → 実装 → レビュー → 評価（ 本番モデルと比較 ） → リリース判断 → 教訓を長期記憶に戻す 各仮説方向の過去最高を集める（新） ：それぞれで一番良かったラウンドのモデルについて、変更内容と評価結果を集めます 組み合わせ仮説の作成（新） ：集めた変更全体を見て、「どの変更をどう組み合わせるか」の仮説を複数出させます。重複する変更は、仮説の段階で解消します（AgentX-Model、MLEvolve） 仮説プールからトーナメント（新） ：組み合わせ仮説どうしを2案ずつ討論させ、上位の仮説を実装に回します。判定材料として元の実験結果を添え、実装しなかった仮説もプールに残します（Co-Scientist、RPM） 本番モデルと比較・リリース判断（新） ：仮説方向ごとの実験とは別の実験として、比較対象と評価条件を揃えて評価します。本番モデルを上回った組み合わせだけを、リリース候補にします 教訓を長期記憶に戻す（新） ：組み合わせても改善した変更と、組み合わせると改善しなくなった変更を、教訓として戻します。コードは仮説方向ごとに分けたまま、教訓を共有して他で得た結果を活かせます（MARS、Navier–Stokes の集約） まずは既存のループに組み込みやすい案1から試し、改善が積み上がってきた段階で、案2のように仮説方向ごとの実験と集約（リリース）を分けることを検討したいと考えています。 まとめ 本記事では、自動研究の論文を紹介しながら、その仕組みを推薦システムの改善ループにどう取り入れられるかを考えました。 改善ループをどう組むかによって、推薦エンジンの最終的な精度も変わるはずです。 また、 dots や grok bot などの登場も踏まえ、エージェントにどのような役割やツールを与え、どう協調させるかにも注目しています。 たとえば、仮説方向を選ぶ役と具体的な仮説を作る役を分けるように、役割の切り方にも工夫の余地があります。 自動研究の動向を追いながら、推薦システムの改善に活かせる設計を引き続き探っていきます。 We’re Hiring! 現在、タイミーでは、データサイエンスやエンジニアリングの分野で、共に成長し、革新を推し進めてくれる新たなチームメンバーを積極的に探しています！ 現在募集中のポジションは こちら です。 また、気軽な雰囲気での カジュアル面談 も随時行っています。 「話を聞きたい」と思われた方は、ぜひお気軽にエントリーしてください。 参考文献 [1] OpenAI, “ On the Navier–Stokes Millennium Prize Problem ” (2026) [2] Noam Brown, Dwarkesh Podcast (2026) [3] Gottweis et al., “ Accelerating scientific discovery with Co-Scientist ,” Nature (2026) [4] “ EvoDiverse ,” arXiv:2606.10587, ICML 2026 [5] “ Arbor ,” arXiv:2606.11926 [6] “ AI Research Preference Models ,” arXiv:2608.13940 [7] “ Experimental Experience Modeling (EEM) ,” arXiv:2609.39392 [8] “ PrimeScientist ,” arXiv:2609.17846 [9] “ MARS ,” arXiv:2602.02660, ICML 2026 [10] “ MLEvolve ,” arXiv:2606.06473 [11] “ Advancing Model Research in AgentX ,” arXiv:2609.30001

はじめに 想定読者：データサイエンティストなど、日常的にデータを扱っていて、コネクティッドデータは初めての方。 この記事で分かること：コネクティッドデータの中身、一般的な分析の流れ、それが何に使われるか、扱うときに詰まる点。 こんにちは。KINTOテクノロジーズのデータサイエンスGに所属するfalsenineです。 コネクティッドデータとは、通信機能を持つクルマが、クラウドに送るデータのことです。車速や位置情報などが含まれ、運転者ごとの安全運転スコアを保険料の割引に反映する保険や、交通情報の生成などに活用されています。 なお本記事は、各社が公開している資料をもとに、モビリティデータ全般の一般的な扱いを整理したものです。特定のサービスの実装や、当社の運用そのものを説明したものではありません。 コネクティッドデータの中身 コネクティッドデータは、生成源で3層に分けると整理しやすいです。トヨタの公開資料は、車載通信機（DCM）経由で取得する車両データを「走行状況に関するデータ」と「車両状態に関するデータ」に大別しています。これに車載カメラからのデータを加えた3層で、本記事では主要なデータを整理します。 層 代表的な項目 取得のトリガ 走行状況 車速、エンジン回転数、加速度、アクセル／ブレーキ操作、シフトポジション、走行距離、位置情報 走行中に継続。位置情報や車速は定期送信 車両状態 警告灯の表示情報、ダイアグ（故障診断）情報 状態変化・異常検知 車外画像 車外の動画（前後数秒〜約2分） 衝突相当、悪路、新規開通道路などの条件成立時 層で分ける理由は、粒度と扱いが違うためです。走行状況は連続的な時系列、車両状態はイベントログ、車外画像は条件付きのスナップショットに近いデータとなり、同じ車両データでも、前処理が異なります。[^toyota-data][^toyota-policy][^toyota-camera] どう分析するのか 走行状況を例に挙げましょう。生の信号は、そのままでは何の指標にもなりません。モビリティのデータ分析は、単位を揃え、関心のあるイベントを定義し、用途に合わせて集約するという加工を重ねて、生の信号を意味のある指標に変えていく作業です。以下の4階層は、各社の公開資料に共通して現れる中間成果物を本記事で整理したもので、業界共通の呼び方ではありません。 階層 やること 出てくるもの 信号 車速・加速度・位置を時系列で受け取る 生の時系列 トリップ 一般的には、エンジンのON／OFFや一定時間以上の停車を境界に区切る（定義は事業者により異なる） 1回の移動 イベント 閾値を超えた挙動を抜き出す 発生回数と発生地点 集約 ドライバー・道路リンク・メッシュのどれかに寄せる スコア、旅行時間、混雑度 位置情報は道路に紐づけます。この処理はマップマッチングと呼ばれますが、正しく紐づくとは限りません。トンネルで測位できない、高速道路と一般道が並走する、都市部で誤差が大きい、道路形状が複雑、といった条件では別の道路に当たります。地図に載っていない細い道を走った場合も、載っている道のどれかに寄せられます。 イベントが設計のポイントです。急ブレーキ判定の閾値は、事業者ごとに異なります。プローブデータの提供事業者の説明では、閾値0.3Gなら3秒間に約30km/h、0.25Gなら約25km/hの減速を検出するとされます。0.05Gの違いで拾う挙動が変わり、同じ生データから別の結論が出ます。[^sei-faq][^kddi-probe] 何に使われているのか 集約でどの単位に寄せるかが、用途を決めます。トヨタは車両データの利活用を「コネクティッドサービス」「いいクルマづくり」「いい町・いい社会づくり」に分類しています。 集約単位 用途区分 例 ドライバー・車両 コネクティッドサービス 運転特性による保険料割引 車両（車種横断） いいクルマづくり 品質改善、開発へのフィードバック 道路リンク・メッシュ いい町・いい社会づくり 通れた道マップ、交通情報、道路保守点検 道路単位に寄せた例が、高速道路の渋滞末尾検知です。車速の低い車両が集まる区間を特定し、その下流を渋滞末尾と定義しました。クラスタリングとカルマンフィルタで推定し、路側レーダーによる既存ソリューションと重なる精度を確認しています。センサーを設置する代わりに、走っているクルマをセンサーとして使う発想です。[^toyota-data][^toyota-insurance][^techplay] 扱うときに詰まる4点 ここまでの変換は分析者が設計できます。一方で入力の条件は決められません。クルマ1台には100台以上のECU（電子制御ユニット）が載っていますが、クラウドに届くのは、そこから必要な項目だけを選んで圧縮したものです。ログの設計権が車両側にあるということです。 Webのアクセスログ 車両データ ログ項目の決定 分析する立場の人。あとからタグを追加し、計測内容を変更できる。 車両の開発時点。車種・グレードで違う 母集団 対象ユーザーの全数 同意した車両のみ データの到着順 ほぼ生成順 通信が切れると車内に滞留し、後からまとめて届く ここから4つのズレが生じ、そのまま技術課題になっています。 母集団のズレ：同意した車両しか観測できません。全数ではない標本から全体を推定するため、選択バイアスが影響します。 スキーマのズレ：項目は車種・グレードで異なり、今後も変わります。スキーマ進化を前提にした設計が必要です。 時刻のズレ：生成時刻と到着時刻が乖離します。集計ウィンドウの締め方と再計算の設計が論点になります。 位置のズレ：測位誤差や並走道路のせいで、別の道路に当たることがあります。マップマッチングの精度が、下流の集計すべてを左右します。 また、位置情報や走行履歴は、個人の行動が表れるデータです。扱う際は、匿名化や利用目的の適切性が重要になります。[^toyota-data][^techplay][^apc][^mobility-night] 活かせる経験と、新しく覚えること 活用できるスキルは、SQL、分散処理、時系列の前処理、因果推論や機械学習の設計力です。4階層の変換自体は、扱ったことのある処理の組み合わせに見えるはずです。新しく覚えるのは、クルマの信号の意味と、閾値や集約単位をどう決めるかのビジネス感覚です。 個人的に面白いと感じるのは、この分野では「何を測るか」の設計がまだ固まっていないことです。急ブレーキの判定基準ひとつ取っても事業者ごとに異なり、その設計が分析の結論やサービスのあり方に影響します。整備されたログを渡されて分析するのではなく、測り方から考える余地が残っている。だからこそ、分析する人の設計しだいで、より安全な運転を促し、より快適なサービスを生み出せる可能性があります。ここが一番の醍醐味だと思っています。 位置情報の扱いについては、KINTOテクノロジーズの勉強会「 Mobility Night #1 - GPS・位置情報 」の内容をテックブログで公開しています。GPSの精度をどう扱うかといった、実務寄りの論点が並んでいます。 [^toyota-data]: トヨタ自動車「お客様のクルマからの車両データの取得と利用について」 https://global.toyota/jp/sustainability/privacy/data-utilizing-initiatives/index.html [^toyota-policy]: トヨタ自動車「コネクティッドカーから取得するデータの利活用・保護の取組みについて」（2019） https://toyota.jp/pages/contents/tconnectservice/contents/pdf/toyota_datapolicy.pdf [^toyota-camera]: トヨタ自動車「車載カメラによる走行環境画像の取得と利用について」 https://global.toyota/jp/sustainability/privacy/on-board-cameras-initiatives/ [^toyota-insurance]: トヨタ自動車「トヨタのコネクティッドカー向けに国内初の運転挙動反映型テレマティクス自動車保険を開発」（運転特性の評価項目） https://global.toyota/jp/detail/19575777 [^sei-faq]: 住友電工システムソリューション「Traffic Vision プローブデータ＆サービス よくある質問」（Hondaカープローブデータの仕様。急ブレーキ閾値 0.3G／0.25G の検出範囲） https://www.seiss.co.jp/products/tv_probe/faq.html [^kddi-probe]: KDDI「商用車のプローブデータ」（矢崎エナジーシステム製デジタルタコグラフによる商用車プローブの仕様。トリップ判定はエンジンON/OFFまたは滞在時間15〜120分の指定。マップマッチングが正しく判定されない条件、DRM基本道路に未定義の道路の扱い） https://biz.kddi.com/service/iot-cloud-data/data/probe/ [^techplay]: TECH PLAY「【TOYOTA✕ビッグデータ】車両データの活用事例」（トヨタ主催イベント講演録。ECU構成・渋滞末尾検知） https://techplay.jp/column/1977 [^apc]: APC技術ブログ（Data + AI Summit 2025 トヨタ登壇セッションの二次報告。遅延データの記述に使用） https://techblog.ap-com.co.jp/entry/2025/06/26/154309 [^mobility-night]: KINTO Tech Blog「Mobility Night #1 - GPS・位置情報」 https://blog.kinto-technologies.com/posts/2024-12-10-Mobility-Night-1-GPS-%E4%BD%8D%E7%BD%AE%E6%83%85%E5%A0%B1/