LegalOn Technologies Engineering Blog

LegalOn Technologies 開発チームによるブログです。

CAIO Reflections - Evaluation, Benchmark and Product Metrics

はじめに

Hi, I’m Joe, Chief AI Officer at LegalOn Technologies. Since joining the company in 2023, I’ve been leading our AI initiatives.

Internally, I’ve been sharing a series called “CAIO Reflections”, where I regularly write about my thoughts and observations on AI. After receiving requests from colleagues who wanted to see these published more widely, I’ve decided to start sharing them here on our tech blog as well.

I hope these reflections offer some useful perspectives—and maybe even spark a few new ideas.

 

こんにちは、Chief AI Officer(CAIO)のJoeです。2023年にLegalOn Technologiesに入社し、AIに関連するすべての開発プロジェクトの責任者を担当しております。

社内では「CAIO Reflections」というシリーズを通じて、AIに関する考えや気づきを定期的に発信してきました。これらの内容をぜひ社外にも発信してほしいという声をもらい、この度エンジニアリングブログで公開することにしました。皆さんにとって少しでも有益な視点や、新しい発想のきっかけになればうれしいです。

How was your Golden Week? During the break, I traveled to Okinawa to attend a friend’s wedding and spent some relaxing time with my family. Though it wasn’t quite summer-hot yet, my kid still had a blast playing in the cool ocean water.

We also visited a few cultural and educational spots on this trip, including the Okinawa Churaumi Aquarium and Shurijo Castle. Throughout the journey, I frequently used ChatGPT to learn more about the background and historical details of these places. At first glance, these interactions seemed like simple information retrieval, but the way the AI demonstrated reasoning and understanding gave me fresh perspectives on the boundaries of AI.

 

皆さんのゴールデンウィークはいかがでしたか?私は沖縄に行き、友人の結婚式に参加しつつ、家族とのんびり過ごすことができました。まだ夏本番の暑さではなかったものの、子どもは少し冷たい海で思いきり遊んでいました。

この旅では、沖縄美ら海水族館や首里城といった、文化的かつ学びのあるスポットも訪れました。観光中、私はChatGPTを頻繁に使い、それぞれの場所の背景や歴史について調べてみました。一見ただの情報検索のようでいて、その裏にはAIの理解力や推論力が感じられるやり取りもあり、AIの「限界」について新たな視点を得る機会となりました。

 

The First Attempt: I took a picture of the city wall at Shurijo Castle and asked ChatGPT to guess the location. Based on the porous nature of the stones, their unique cutting patterns, moss distribution, and signs of weathering, it inferred that it might be a historical site in a humid southern region of Japan—eventually suggesting either Shurijo Castle or Edo Castle.

1つ目の試み:私は首里城の城壁を撮影し、その写真をChatGPTに送って「ここがどこか当ててみて」と依頼してみました。すると、石の多孔質な質感や独特なカット、苔の付き方、風化の様子から「日本南部の湿潤地域にある歴史的建造物ではないか」と推論し、最終的には「首里城か江戸城」と回答しました。

 

The Second Attempt: I stood atop the wall and snapped a photo of the cityscape. ChatGPT looked at the coastline, building density and style, and the faint stone structures in the frame, then answered: “...this view strongly resembles Naha, the capital city of Okinawa Prefecture in Japan, and the vantage point could very likely be Shurijo Castle (Shuri Castle)...”

2つ目の試み:城壁の上から街並みを撮った写真を見せたところ、ChatGPTは海岸線、建物の密度やスタイル、かすかに映る石垣の構造などから「...この景色は日本の沖縄県の県庁所在地である那覇市によく似ており、撮影された場所は首里城である可能性が非常に高いです...」と回答してくれました。

 

I thought I had a decent grasp of AI’s capabilities, but these experiences still surprised and amazed me. Honestly, I’m not sure whether the model reasoned based on image analysis or simply drew from abundant training data in social networks, given how well-known these sites are online. But the accuracy and style of its response made me realize that the boundary between "reasoning" and "recall" is far blurrier than we often assume.

私自身、AIの能力についてある程度の理解があると思っていましたが、今回の体験には驚かされました。正直に言えば、これは画像分析による推論なのか、それとも有名な観光地ゆえにSNSから得た大量のトレーニングデータに基づくものなのか判断がつきません。しかし、その回答の精度とスタイルから、「推論」と「記憶」の境界線は思っているより曖昧なのだと感じました。

 

AIの「後半戦」が始まった

I recently came across a thought-provoking article by OpenAI researcher Shunyu Yao titled "The Second Half." One idea that stood out was that the focus of AI development is shifting—from Training / Modeling / Methods to Evaluation / Benchmark / Environment.

In other words, the question is no longer just how to train better models, but how to define better problems. It actually reflects a shift: we're moving away from chasing higher scores and toward asking what we should be measuring to reflect the real-world complexity we aim to solve.

This feels quite relevant. We often see models performing impressively on public benchmarks, reaching "PhD-level" scores. The following diagram shows that even if we are spending effort in creating new benchmarks, harder benchmarks will just get solved increasingly soon, without requiring much more new ideas.

 

最近、OpenAIの研究者であるShunyu Yao氏の "The Second Half" という記事を読み、とても印象的な指摘がありました。それは、AI開発の重心が Training / Modeling / Methods から Evaluation / Benchmark / Environment へと移ってきているということです。

つまり、「どうやってより良いモデルを作るか」ではなく、「どうやってより良い問題を定義するか」が重要になってきたのです。これは単なる技術的なプロセスの変化ではなく、パラダイムの転換です。つまり、単にスコアを上げるのではなく、「何を測るべきか」を問い直すことが、複雑な現実世界に近づく鍵になるのです。

これは今の状況に非常によく当てはまると感じます。私たちは日々、公開ベンチマークで高得点を叩き出すモデルを目にします。「PhDレベル」と評価されるような成績も見かけます。ただ、記事に出ていた図にもあったように、私たちが新たなベンチマークを用意しても、それがすぐに解かれてしまい、根本的なアイデアの進化にはつながらないこともあります。

引用元:https://ysymyth.github.io/The-Second-Half/

But does that kind of progress actually make our lives better? At least for now, not quite. AI is still making mistakes in real applications that even undergrads wouldn’t.

I’ve been reflecting on this disconnect, especially in the context of how we think about benchmarks, evaluations, and product metrics. Here are a few thoughts I’d like to share.

 

では、こうした進歩は実際に私たちの生活を良くしているのでしょうか?今のところ、そうとは言い切れません。実際のアプリケーションでは、AIが学部生でもしないようなミスを繰り返しています。

このギャップについて、特にベンチマーク、評価指標、プロダクトメトリクスの観点から考えることが最近多くなっています。ここでいくつか共有させてください。

 

Measuring Value Means Understanding Meaningful Change

「価値のある変化」を測るとは何か

Let’s clarify two often-confused concepts:

  • Benchmark: An offline dataset used to assess the foundational capabilities of an AI model - whether it can solve a problem.
  • Product Metrics: Online feedback signals used to assess whether a product actually improves the user experience - whether that ability translates into real value.

While these are often lumped together, they measure very different things. One tests whether the model can ace a lab test; the other checks if it’s actually helpful in the real world.

 

まず、混同されがちな2つの概念を整理しましょう。

  • ベンチマーク:AIモデルの基礎能力を評価するためのオフラインデータセット。「この問題が解けるかどうか」を測ります。
  • プロダクトメトリクス:プロダクトが本当にユーザー体験を改善しているかどうかを示すオンラインのフィードバック信号。「その能力が実際に価値に変換されたかどうか」を見ます。

この2つは混同されがちですが、実際は異なるものです。一方は「模擬試験に強いか」、もう一方は「実際の業務に役立つか」を問うものです。

 

Here’s why benchmark design matters. Suppose you’re building a cat-vs-dog image classifier and create a benchmark with 99 dog photos and 1 cat. A model that always predicts “dog” will score 99% accuracy! But clearly, that’s not what we want.

Another real world example is evaluating a search engine. We can build the dataset by using the top 500 most frequent queries. It misses the nuance: noisy inputs, long-tail use cases, edge conditions - stuff that product managers must carefully handle. In the real world, product managers often spend a large amount of effort in curating the benchmark. In the AI era, a well-designed benchmark dataset can become a company’s most valuable asset, differentiating against competitors. Some companies even keep their benchmarks confidential to avoid having AI engineers unknowingly "hack" them.

 

なぜベンチマーク設計が重要か。たとえば、猫と犬を判別するAIを作るとして、99枚の犬の写真と1枚の猫の写真を用意したとしましょう。常に「犬」と予測するモデルは99%の精度を達成できます!しかし、この予測結果と精度は、本来求めているものとは明らかに違いますよね。

もう1つの現実的な例として、検索エンジンの評価があります。よく使われる上位500件のクエリを使ってデータセットを作ることは可能ですが、これでは本質的な部分が抜け落ちてしまいます。たとえば、ノイズの多い入力、ニッチなユースケース、境界条件など、本来プロダクトマネージャーが丁寧に取り扱うべき要素が含まれません。現実のプロダクト開発では、こうしたベンチマークを丁寧に作り込むことに多くの時間と労力がかかっています。AI時代においては、こうした設計されたベンチマークデータセット自体が、企業にとって最大の資産のひとつとなり得ます。それが競合との差別化要因にもなりますし、中にはAIエンジニアが無意識のうちに“ハック”してしまうのを防ぐために、ベンチマークを社内でも非公開にしている企業もあるほどです。

 

This leads to another question: how do we design product metrics?

Benchmarks are offline, but we also need real-time feedback to validate performance. The two are linked. For example, in our contract review feature, MAU (monthly active users) is a good success metric. But if someone proposes adding a mini-game to the homepage to boost MAU — I believe a good mini-game can indeed improve user engagement but would that make the product more valuable? Of course not.

What matters is whether users can review contracts faster, with more confidence:

  • Is the average time to review a contract decreasing?
  • Are users relying less on legal for confirmation?
  • Are they willing to keep paying for the tool?

A robust evaluation system comes from deep user understanding. We start from user pain points, propose hypotheses, design solutions, iterate through offline benchmarks evaluation, and validate through online metrics. This "hypothesis  → design  → validation" loop is core to iterating better AI products.

 

では、プロダクトメトリクスはどう設計すべきでしょうか?

ベンチマークはオフライン評価ですが、それだけでは不十分で、リアルタイムのフィードバックが必要です。両者は連携しています。たとえば、契約書レビュー機能において、MAU(月間アクティブユーザー数)は成功指標のひとつです。ただし、仮に「MAUを増やすためにホームページにミニゲームを追加しよう」という提案があったとしたらどうでしょう。確かに、良いミニゲームはエンゲージメントを高める効果があるかもしれませんが、それでプロダクトとしての価値が上がるかといえば、答えは明らかにノーです。

本当に重要なのは、ユーザーがより早く、安心して契約書をレビューできるかどうかです。

  • レビュー時間は短縮されているか?
  • 法務の確認に依存する頻度は減っているか?
  • ユーザーは継続的にこのツールに対してお金を払おうとしているか?

良い評価設計は、ユーザー課題への深い理解から生まれます。ユーザーのペインポイントを起点に仮説を立て、プロダクトを設計し、オフラインのベンチマークで高速に評価し、オンラインの指標で検証する。この「仮説 → 設計 → 検証」のループこそが、AIプロダクトをより良くする鍵です。

 

What’s Different About Building Products in the AI Era?

AI時代のプロダクトづくりは何が違うのか?

Based on my observation, good classic product managers and AI product managers share some common traits:

  1. Deep user understanding is still the foundation.
  2. Abstraction is still key - though it’s shifting. It used to be about UI and workflow abstraction; now it's about abstracting business goals and evaluation standards.
  3. A keen sense of interaction design still matters. The ability to intuitively design interfaces determines whether you can generate measurable, observable signals to guide iteration.

What is different?

  1. The importance of data quality is dramatically higher. As this article discussed, benchmark and product metrics have become much more important.
  2. An acute sense of AI capability boundaries is important. Each person may find their own way to develop this, but one thing is certain—you must use AI products regularly. Try out external tools, or apply AI to real work tasks like writing PRDs or creating designs. The barriers to doing so are now incredibly low.

 

私の観察ベースですが、古典的なプロダクトマネージャーとAI時代のプロダクトマネージャーには、いくつか共通した特徴があると感じています。

  • ユーザー理解の深さは、今もなお土台です。
  • 抽象化の力も引き続き重要ですが、その焦点は変わりつつあります。以前はUIやワークフローの抽象化が中心でしたが、今はビジネス目標や評価基準の抽象化が求められています。
    • 以前は、プロダクトマネージャーが製品を設計する際に、ユーザーの業務フローやビジネスフローを抽象化して、UIに実装することが求められていました。しかし、昨今のAIは、活用できるユーザーや範囲が拡大していることから、ペルソナやユースケースを具体的に固定するのではなく、あらゆるユーザーのビジネス目標やどういう基準で業務が適切に進むのかのシグナルを、確実に想起できるような製品設計が必要になります。よって、各ユーザーのゴールはそれぞれ異なるので、製品設計するときはビジネス目標や評価基準を抽象化する必要があります。
  • インタラクションデザインへの感度も依然として大切です。直感的に使いやすいインターフェースを設計できるかどうかが、観測可能なフィードバックを得てプロダクトを改善していけるかどうかに直結します。

では、何が変わったのでしょうか?

  • データ品質の重要性が格段に高まりました。この記事でも述べたとおり、ベンチマークやプロダクトメトリクスの重みがこれまで以上に大きくなっています。
  • AIの能力の限界を肌感覚で捉えることも不可欠になっています。方法は人それぞれかもしれませんが、確かなのは「AIプロダクトを日常的に使っていること」です。外部ツールを試してみたり、PRD (Product Requirements Document) の作成やデザインといった実務タスクにAIを使ってみてください。もはやそのハードルは非常に低くなっています。

 

Closing

There’s one more thing I’ve been reflecting on lately: whether we should gradually move away from the traditional “modular collaboration” mindset often seen in large organizations.

For example, we often hear: “This is the product manager’s responsibility,” “This is the designer’s role,” or “This part belongs to the AI engineer.” The product manager coordinates across functions and assigns tasks accordingly. In mature industries, this kind of clear division of labor is effective and often essential for operating complex systems efficiently.

But in the AI era—where technologies are advancing rapidly and tools are continuously lowering the skill barriers—this model may no longer be optimal.

Today, a non-professional designer can use tools like Claude to quickly prototype UI designs via natural language; Someone with a bit of technical background can use agent-based tools like Devin or Cursor to generate working prototype code. The boundaries between roles are quickly blurring, and our approach to collaboration needs to evolve accordingly.

What we truly need is for every functional lead to be hands-on, capable of working fluidly across roles, and co-creating at speed.

Speed and a spirit of co-creation are becoming the true core competencies of our time.

 

最近、もう1つ感じていることがあります。

それは、これまで大企業で一般的だった「モジュール型の分業スタイル」について、今後は少し見直していく必要があるのではないか、ということです。

たとえば、「ここはPdMの領域」「ここはデザイナーの役割」「この部分はAIエンジニアの担当」といったように、それぞれの専門領域が明確に分かれ、PdMが各部門を調整しながら業務を割り振っていく――このようなスタイルは、成熟した産業領域においては非常に有効であり、複雑なシステムを安定的に運用するためには不可欠な考え方でもあります。

ただし、AI分野の進化が非常に速く、かつツールの発展によって専門スキルのハードルが下がり続けている今の状況では、こうした分業の在り方が必ずしも最適とは限らないかもしれません。

例えば、デザインの専門でない方でも、Claudeのようなツールを使えば自然言語で素早くUIのプロトタイプを作ることができますし、ある程度の技術的な知識があれば、DevinやCursorのエージェントモードを使って PoC 的なコードを書き起こすことも可能です。

職能ごとの境界が急速に曖昧になっている今、私たちの協働の仕方も、柔軟にアップデートしていくことが求められているのではないでしょうか。

今後ますます重要になってくるのは、それぞれの領域のメンバーが自ら手を動かし、役割の垣根を越えて連携しながら、スピード感を持ってプロダクトを共創していく姿勢だと感じています。

スピード共創の精神。この2つこそが、これからの時代において私たちが大切にすべきコアコンピタンスになっていくのではないかと思います。

 

仲間募集

一緒に働く仲間を募集しています。 ご興味がある方は、以下のサイトからぜひご応募ください。 皆様のご応募をお待ちしております。