kintone アプリを kSQL で結合して、Claude Desktop にグラフ表示してみます。
概要
kSQL を使ってアプリを結合・集計して、グラフを表示する例です。
プロンプトで要件を指示すると、SQLを組み立てて実行し、グラフ表示してくれます。
- 縦棒
- 縦棒と折れ線
関連情報
プロンプト１(縦棒)
APP89 と APP88 を結合して、顧客ランク別の金額を集計してグラフ表示して
kintone のアプリ ID 88 と 89 を結合して集計・可視化するということですね。kSQL MCP が使えそうなので、まずアプリの構造を確認します。両アプリの構造を並行して確認します。構造を把握しました。APP89 (顧客マスタ) の 顧客ランク と APP88 (案件) の 合計費用 を、顧客管理レコード番号_関連レコード紐付け用 で結合して集計します。データが取れたのでグラフを表示します。
APP89 の 顧客ランク と APP88 の 合計費用 を 顧客管理レコード番号_関連レコード紐付け用 で結合して集計しました。
意外にも ランク B が最大 (¥8,500,000) で、A ランクは案件数こそ多い (4件) ものの金額は最少 (¥4,400,000) という結果になっています。A ランク顧客あたりの単価が低い (110万円/件) のに対し、B ランクは 283万円/件、C ランクは 300万円/件 と高単価です。顧客ランクの定義と商談単価が逆相関になっていないか、確認の余地がありそうです。
このあと深掘りするとしたら、こんな方向が考えられます:
- 確度別 (受注見込み) でフィルタした金額にする
- 受注予定日でランク別の推移を見る
- ランク A の案件を一覧化して、なぜ単価が低いのか中身を確認する
どれかやりますか？
プロンプト２(縦棒と折れ線)
グラフを縦棒と折れ線グラフにして
合計金額を縦棒、案件数を折れ線に変えます。こんな感じです。合計金額が棒、案件数が折れ線になり、二軸の対比が見やすくなったと思います。
棒と線が交差するランク A の部分が視覚的に効いていて、「案件数は多いのに金額は少ない」状況が一目で分かるようになりました。
SQL
利用したSQLの解説を
実行した SQL はこれです:
SELECT c.顧客ランク AS 顧客ランク,
SUM(d.合計費用) AS 合計金額,
COUNT(*) AS 案件数
FROM APP88 d
JOIN APP89 c ON d.顧客管理レコード番号_関連レコード紐付け用 = c.レコード番号
GROUP BY c.顧客ランク
ORDER BY 合計金額 DESC
各部分の役割
FROM APP88 d / JOIN APP89 c
kSQL では APP{アプリID} がテーブル名になります。d (deal=案件) と c (customer=顧客) はエイリアスで、後続でフィールドがどちらのアプリ由来かを明示するために付けています。kintone は標準では他アプリのフィールドを直接集計できませんが、kSQL が裏で結合処理を行ってくれます。
ON d.顧客管理レコード番号_関連レコード紐付け用 = c.レコード番号
今回の結合のキモです。APP88 (案件) には 顧客管理レコード番号_関連レコード紐付け用 という NUMBER フィールドがあり、ここに APP89 (顧客マスタ) の レコード番号 が入っている設計でした。これでルックアップ的に顧客情報を引っ張れます。
ちなみに JOIN は INNER JOIN なので、紐付けが空の案件や、対応する顧客レコードが見つからない案件は集計から外れます。もし「未紐付けの案件も含めて集計」したい場合は LEFT JOIN にして、c.顧客ランク IS NULL を「未分類」として扱う書き方になります。
SELECT c.顧客ランク, SUM(d.合計費用), COUNT(*)
-
c.顧客ランク— APP89 側のドロップダウン値 (A/B/C) -
SUM(d.合計費用)— APP88 の CALC フィールド (プラン費用 + オプション費用) をランク単位で合算 -
COUNT(*)— 該当する案件レコード数
CALC フィールドも数値として SUM できるのが地味に便利なところです。
GROUP BY c.顧客ランク
ランクごとに行をまとめます。SELECT に書いた非集計列 (c.顧客ランク) は GROUP BY にも含める必要があります。
ORDER BY 合計金額 DESC
金額の多い順に並べ替え。kSQL は SELECT で付けたエイリアス (合計金額) をそのまま ORDER BY で使えるので、SUM(d.合計費用) DESC と書かなくて済んでいます。
注意点
- フィールドコードは日本語のまま使える — kintone のフィールドコードがそのままカラム名になります。空白や特殊文字を含む場合はバッククォートで囲む必要がありますが、今回はアンダースコア区切りなので素のままで OK でした。
-
JOIN は kintone 標準では不可 — kSQL を使わず JavaScript で書くなら、APP88 と APP89 をそれぞれ
kintone.apiで取得し、JS 側でMapを作って突き合わせる実装になります。kSQL はそれを 1 クエリにまとめてくれている、というイメージです。 -
アプリの紐付け設計に依存 — 今回 APP88 側に
顧客管理レコード番号_関連レコード紐付け用という専用フィールドが用意されていたのでシンプルに JOIN できましたが、ルックアップフィールドのコピー値 (例:顧客名) で結合すると同名顧客の取り違えが起きるので避けるのが定石です。