ダッシュボードの作成 Malloyyo は、数字が正しいことを確認します。

クロードは、ダッシュボードの構築に本当に良いです。 データ(MCP経由)にアクセスし、数分で美しいClaude Dashboardをビルドします。 その部分は解決します。

欠落した部分は、セマンティックス、アクセス制御、ダッシュボードの共有ホーム、および同じデータ上に構築するすべての人々を管理するためのワークフローです。

そこで構築しました。 Malloyyoは、ClaudeまたはWeb上で「Claudeダッシュボード」を提供しています。 マロイのセマンティックモデルでお客様のデータの意味を管理します。 役割ベースのセキュリティで何が見えるかを制御します。 ダッシュボードとモデルを GitHub リポジトリに保存しますので、すべて検証して維持できます。

デモサーバーをお試しください。 任意のGoogleアカウントでサインインします。

データ混乱、今10x

Lookerでは、data chaos と呼びます。 会議に2人ずつ歩いて、それぞれに独自の分析があります。 数字は一致しません。 引数が始まります。

AIを追加し、問題は10回悪化します。 分析は今安いです。 会議に10人の人が集まり、それぞれにバイブ・コードされたダッシュボードがあり、数字のマッチを一切使用しません。

2つ目の暗い問題があります:access control.

Malloyyo

Claude builds the dashboards. Malloyyo makes sure the numbers are right.

Claude is really good at building dashboards. Give it access to your data (via MCP) and it will build you a beautiful Claude Dashboard in a few minutes. That part is solved.

The missing parts are everything else: semantics, access control, a shared home for the dashboards, and a workflow to manage it all as more and more people build on the same data.

So we built it. Malloyyo serves your “Claude Dashboards” in Claude or on the web. It manages the meaning of your data in a Malloy semantic model. It controls who can see what using role based security. And it keeps your dashboards and your model in a GitHub repo, so all of it can be verified and maintained.

Try the demo server. Sign in with any Google account.

Data chaos, now 10x

At Looker we called it data chaos. Two people walk into a meeting, each with their own analysis. The numbers don’t match. An argument starts.

Add AI and the problem gets ten times worse. Analysis is cheap now. Ten people walk into the meeting, each with a vibe-coded dashboard, and none of the numbers match.

There’s a second, darker problem: access control. The database is the wrong layer for deciding what people can see. A table lands in the wrong place. A permission is missing. Queries draw from lots of places, and it’s very hard to know exactly what any one person can reach. The same goes for an AI.

A semantic layer solves both.

• Numbers match ✓ The model defines the calculations and the join relationships once, Anything built on those calculations is correct.
• Access control ✓ You grant access to a semantic model, which is a much bigger and more meaningful unit than a table. The AI can only query what the model exposes.

“Do we really need a semantic layer with AI?”

People want a yes-or-no answer. Ours is “Yes, and…”

I think the real reason people say “no” is the end-state problem. A traditional semantic layer describes calculations and joins, which is great, but a query against it is just a set of parameters. When the calculation you need isn’t in the model, you’re stuck. You download the data and finish the job somewhere else. A business user opens a spreadsheet. An AI opens Python.

Either way you’ve left the governed system, and the numbers start to drift.

When we designed Malloy, we decided the semantic layer and the query language had to be one system. Malloy describes the semantics, and it’s also a complete query language. Any question you can answer in SQL, you can answer in Malloy, scoped to the model. You get consistent definitions and bounded access, and you never hit the end state.