kintone業務設計研究所 > kintoneグラフの設計方法|見える化で終わらせない指標・一覧・権限設計
2026年6月11日
•約18分で読めます
kintoneでグラフを作るときに、棒グラフ、折れ線グラフ、円グラフ、クロス集計表、一覧条件、集計方法、閲覧権限、定期レポート、ポータル配置、外部BIの使い分けを業務設計の観点で整理します。
kintoneでグラフを作りたいです。棒グラフや円グラフを作れば十分でしょうか。
グラフは最後の表示方法だ。先に決めるべきなのは、誰が、どの数字を見て、どのレコードを確認し、次に何をするかだ。
kintoneでは、アプリに登録されたレコードをもとに、グラフや表を作れます。
月別売上を折れ線で見る。
担当者別の案件金額を棒グラフで見る。
問い合わせ種別の構成比を円グラフで見る。
ステータス別の件数をグラフで見る。
部門別・月別の数字をクロス集計表で見る。
こうしたグラフは、kintoneを業務システムとして使ううえで自然に必要になります。
ただし、実務で問題になるのは、グラフの作り方そのものではありません。
次のような状態が起きます。
これらは、グラフ機能の不足ではありません。
指標、元データ、集計条件、一覧、閲覧権限、更新頻度が決まっていないことが原因です。
kintoneグラフで最初に決めるべきなのは、グラフの種類ではなく、「誰が何を判断するための数字か」と「その数字に含めるレコードはどれか」です。
この記事では、kintoneでグラフを作るときの、指標設計、棒グラフ・折れ線・円・クロス集計の使い分け、元データと一覧条件、グラフからレコードへ戻る運用、ポータル・ダッシュボード配置、閲覧権限、定期レポート、外部BIへ分ける判断を整理します。
kintone集計全体の設計方法はこちら
kintoneクロス集計の設計方法はこちら
kintone公式ヘルプでは、アプリに登録されたレコードの内容、レコード数、日付データを集計し、集計結果をグラフや表として作成できると説明されています。
また、グラフを保存すると、アプリのトップページから最新のグラフを表示できます。
ここまでは機能の話です。
業務設計として重要なのは、グラフを見た人が次に何を判断するかです。
| グラフ | 見る人 | 判断すること |
|---|---|---|
| 月別売上推移 | 経営者、営業責任者 | 売上計画とのずれ、次月の見込み |
| 担当者別案件数 | 営業責任者 | 偏り、フォロー対象、担当再配置 |
| 問い合わせ種別比率 | サポート責任者 | 増えている問い合わせ種別、改善対象 |
| 未対応件数 | 現場責任者 | 今日対応すべきレコード |
| 予実差額 | 経営者、部門責任者 | 予算超過、追加確認、支出見直し |
グラフは、眺めるものではありません。
判断の入口です。
たとえば、未対応件数のグラフを見て、該当レコードを開き、担当者と期限を確認し、対応順を決める。
月別売上のグラフを見て、急に下がった月の案件一覧へ戻り、失注理由や請求漏れを確認する。
問い合わせ種別のグラフを見て、特定カテゴリの問い合わせを一覧化し、ナレッジやフォーム項目を見直す。
ここまでつながって、グラフは業務に使えます。
kintoneグラフは、数字を見るためだけではなく、原因になっているレコードへ戻り、次の対応を決めるために設計します。
グラフを作る前に、次の5つを決めます。
| 決めること | 例 |
|---|---|
| 利用者 | 経営者、部門責任者、担当者、経理、サポート責任者 |
| 判断 | 売上見込み確認、未対応確認、進捗確認、異常値確認 |
| 指標 | 件数、合計金額、平均時間、遅延件数、予実差額 |
| 対象レコード | 今年、今月、未完了、受注済み、請求対象 |
| 次の動き | レコード確認、担当変更、催促、会議資料、外部連携 |
同じ「売上グラフ」でも、利用者によって作るべきグラフは変わります。
| 利用者 | 見たい売上 | グラフ例 |
|---|---|---|
| 経営者 | 月次売上、予算との差 | 月別売上推移、予実差額 |
| 営業責任者 | 担当者別の見込み | 担当者別案件金額、確度別金額 |
| 経理 | 請求済み、入金済み | 請求月別金額、未入金件数 |
| 現場 | 今日対応する案件 | 未対応、期限超過、ステータス別件数 |
ここを決めずに、月別・担当者別・商品別のグラフを大量に作ると、画面はにぎやかになります。
しかし、どのグラフを見ればよいか分からなくなります。
最初に作るべきなのは、毎週または毎月の会議で必ず見るグラフです。
次に、現場が日次で見るグラフです。
最後に、必要なときだけ確認する分析用グラフです。
| 種類 | 例 | 配置 |
|---|---|---|
| 会議用 | 月別売上、予実差額、案件進捗 | ポータル、会議用アプリ |
| 日次確認用 | 未対応、期限超過、担当者別件数 | 対象アプリのトップ |
| 分析用 | 商品別、流入元別、種別別 | 必要な人だけが見る |
グラフは増やすより、使う順に並べる方が重要です。
kintoneヘルプでは、グラフの種類と使い分けが整理されています。
実務では、次のように考えます。
| グラフ種類 | 向いている用途 | 注意点 |
|---|---|---|
| 棒グラフ | 担当者別、商品別、部門別などの比較 | 項目が多いと読みにくい |
| 積み上げ棒 | 全体量と内訳を同時に見る | 内訳が多いと色が増えすぎる |
| 100%積み上げ | 構成比を比較する | 絶対値の大きさは見えにくい |
| 折れ線 | 月別、週別、日別の推移 | 日付の基準を決める必要がある |
| 面グラフ | 推移と内訳の量感を見る | 細かい比較には向きにくい |
| 円グラフ | 少数カテゴリの構成比を見る | 項目が多い場合は棒グラフの方がよい |
| クロス集計表 | 2つ以上の軸で件数や金額を見る | 行軸・列軸・値の設計が必要 |
「どのグラフがきれいか」ではなく、「どの判断に向くか」で選びます。
担当者別の案件数を比較したいなら、棒グラフ。
月別の問い合わせ件数を追いたいなら、折れ線。
問い合わせ種別が3〜5種類程度なら、円グラフ。
月別×担当者別の案件金額を見たいなら、クロス集計表。
部門別の構成比を月ごとに見たいなら、100%積み上げ。
このように、判断から逆算します。
円グラフは特に注意が必要です。
10項目、20項目と増えると、色と凡例を見比べるだけで時間がかかります。
項目数が多い場合は、棒グラフで上位順に並べる方が読みやすいです。
クロス集計表は、別記事で詳しく整理しています。
グラフの正しさは、元データで決まります。
kintoneのグラフ作成では、分類する項目、集計方法、条件、ソートを設定します。
公式ヘルプでは、分類する項目は大項目・中項目・小項目まで設定でき、集計方法はレコード数、合計、平均、最大値、最小値から選べると説明されています。
この設定を正しくするには、元データ側で次の点を整えます。
| 確認項目 | 失敗例 | 設計の方向 |
|---|---|---|
| 正本アプリ | 売上が案件、請求、入金に分散 | 指標ごとに正本を決める |
| レコード粒度 | 1レコードに複数明細が入っている | 明細集計が必要なら別アプリ化 |
| 日付 | 予定日、実績日、請求日が混ざる | グラフごとに基準日を決める |
| 分類項目 | 自由入力で表記ゆれする | 選択肢、ユーザー選択、マスタ参照 |
| 条件 | 失注やテストが混ざる | 除外条件を明示する |
| 金額 | 税込、税抜、見込、確定が混ざる | 指標名とフィールドを分ける |
たとえば、案件アプリで「月別売上見込み」を見る場合、受注予定月、案件ステータス、確度、担当者、予定金額が必要です。
見込みと受注済みを同じフィールドで扱うなら、条件を明確にします。
請求売上を見るなら、案件アプリではなく請求アプリを正本にする方がよいことがあります。
テーブル内の明細を商品別や月別に集計したい場合も注意が必要です。
親レコードの合計フィールドをグラフ化するだけなら扱いやすいですが、明細行を横断して集計したいなら、明細アプリ化や外部集計を検討します。
グラフが合わないときは、グラフ種類を変える前に、正本アプリ、レコード粒度、日付、分類項目、除外条件を確認します。
kintoneグラフの強みは、集計結果から元レコードへ戻れることです。
公式ヘルプでは、グラフ上の集計結果をクリックすると、その集計結果に含まれるレコードだけを一覧表示できると説明されています。
これは、グラフを業務で使ううえで重要です。
グラフは「結果」を見せます。
一覧は「原因になっているレコード」を確認します。
この2つをつなげる必要があります。
| グラフ | クリック後に確認したい一覧項目 |
|---|---|
| 未対応件数 | 顧客名、担当者、期限、優先度、最終更新日 |
| 月別売上 | 顧客名、案件名、金額、ステータス、請求予定日 |
| 期限超過件数 | タスク名、担当者、期限、遅延理由、次回対応 |
| 失注件数 | 顧客名、失注理由、競合、金額、担当者 |
| 問い合わせ種別 | 問い合わせ内容、種別、対応状態、担当者 |
ここで重要なのは、デフォルト一覧です。
グラフから絞り込んだ後に表示される一覧に、次の対応に必要な項目がなければ、ユーザーはまた別画面を開くことになります。
そのため、グラフ設計では、グラフだけでなく一覧もセットで設計します。
たとえば、未対応件数のグラフを作るなら、クリック後の一覧には、顧客名、問い合わせ内容、担当者、期限、優先度、対応状態を入れます。
売上見込みのグラフを作るなら、クリック後の一覧には、案件名、顧客名、営業担当、金額、受注予定日、確度、次回アクションを入れます。
グラフを見て終わりにしないためには、一覧でレコードへ戻れる導線が必要です。
グラフをどこに置くかも設計対象です。
すべてのグラフを各アプリに置くだけでは、全体の状況を見にくくなります。
一方で、ポータルにすべてのグラフを並べると、画面が読みにくくなります。
| 配置場所 | 向いているグラフ |
|---|---|
| アプリトップ | そのアプリの担当者が日常的に見るもの |
| ポータル | 全社・部門で共通して見るもの |
| スペース | プロジェクトや部門単位で見るもの |
| 定期レポート | 時系列で残したいもの |
| 外部BI | 複数アプリ横断、複雑なダッシュボード |
kintoneヘルプでは、保存したグラフのみ埋め込み用タグを取得でき、外部サイトにグラフや表を埋め込めると説明されています。
ただし、埋め込めるからといって、どこにでも置けばよいわけではありません。
ポータルに置くグラフは、全員が見るべきものに絞ります。
営業部だけが見るグラフは営業スペース。
案件担当者が見るグラフは案件アプリ。
経営会議で見るグラフは会議用ポータルやレポート。
このように分けます。
複数アプリをまたぐダッシュボードが必要な場合は、kintone標準グラフだけで完結させず、外部BIやダッシュボード系プラグインを検討します。
ただし、その前に、正本アプリ、キー、更新頻度、権限を決める必要があります。
グラフは、権限設計とセットで考えます。
公式ヘルプでは、集計対象になるのは、グラフを表示するユーザーが閲覧権限を持つレコードやフィールドだと説明されています。
同じグラフ名でも、ユーザーによって見えるレコードやフィールドが違えば、集計結果も変わることがあります。
これは、特に会議用グラフで問題になります。
| 状況 | 起きること |
|---|---|
| 営業担当者は自分の案件だけ閲覧できる | 担当者ごとに売上グラフの数字が違う |
| 原価フィールドを一部ユーザーに隠している | 粗利や原価系グラフが見えない、または集計されない |
| 部門ごとにレコード権限が違う | 部門横断のグラフが人によって変わる |
| 定期レポートを特定ユーザーが設定した | そのユーザーの閲覧範囲が集計対象になる |
グラフを全社共通の数字として使うなら、次を決めます。
| 決めること | 例 |
|---|---|
| 誰が見るか | 経営、部門長、担当者、経理 |
| どの粒度で見せるか | 全社、部門別、担当者別、個人別 |
| どの項目を隠すか | 原価、粗利、個人情報、契約情報 |
| 会議用の数字を誰が確認するか | 管理者、部門責任者、経理 |
| エクスポートを許可するか | CSV、Excel、外部BI |
特に原価、粗利、人件費、評価、個人情報を含むグラフは慎重に扱います。
レコード詳細画面では見せていなくても、グラフや集計表で合計値が見える場合があります。
逆に、必要な人に必要な数字が見えないこともあります。
グラフを公開する前に、ユーザー権限ごとに表示確認します。
kintoneグラフは、見る人の閲覧権限によって数字が変わることがあります。会議用の共通指標にするなら、権限と集計範囲を先に固定します。
グラフには、最新値を見るものと、過去時点を残すものがあります。
最新値でよいものは、通常のグラフで十分です。
過去時点を残したいものは、定期レポートや集計結果アプリを検討します。
kintoneヘルプでは、定期レポートはアプリデータを一定間隔で集計し、結果を記録する機能だと説明されています。
ただし、定期レポートには注意があります。
公式ヘルプでは、過去30回分まで保持されること、定期レポートを設定するとグラフの編集や複製ができなくなること、グラフを削除すると過去レポートも削除されること、クロス集計表には設定できないことが説明されています。
そのため、月次会議や経営管理で長期保存が必要なら、定期レポートだけに頼らず、集計結果アプリや外部BI側の履歴保存も検討します。
| 用途 | 保存方法 |
|---|---|
| 毎日の未対応確認 | 保存せず最新値を見る |
| 週次の案件進捗 | 定期レポート、または会議前に記録 |
| 月次売上報告 | 集計結果アプリ、外部BI、会議資料 |
| 予実管理 | 確定値として保存する |
| 監査や説明責任 | 集計条件と集計日時を残す |
保存する場合は、集計日時、対象期間、対象条件、元データ件数、確認者を残します。
グラフは最新値に強い一方、過去時点の説明には弱いことがあります。
ここを理解して、見るだけのグラフと、記録する数字を分けます。
kintone標準グラフで足りるのは、1アプリ内のレコードを、比較・推移・構成比・クロス集計で確認する場合です。
次のような場合は、外部BI、DataCollect、ダッシュボード系プラグイン、集計結果アプリを検討します。
| 状況 | 標準グラフだけで苦しくなる理由 |
|---|---|
| 複数アプリを横断したい | アプリ間のキーと集計処理が必要 |
| 複雑な計算指標が必要 | 集計値どうしの計算が必要 |
| 複数グラフを自由に配置したい | レイアウト要件が強い |
| 外部ユーザーにも見せたい | kintoneログインや権限の設計が必要 |
| 長期履歴を残したい | 定期レポートだけでは足りないことがある |
| 明細行を横断集計したい | テーブルや親レコードの粒度が合わない |
ただし、外部BIに出せば解決するわけではありません。
外部BIは、グラフをきれいにする場所ではなく、複数データを結び、分析し、共有する場所です。
その前に、kintone側で正本データ、キー、集計条件、更新頻度、権限を決めます。
| 決めること | 例 |
|---|---|
| 正本アプリ | 案件、請求、作業実績、問い合わせ |
| キー | 顧客コード、案件番号、商品コード、部門コード |
| 更新頻度 | 日次、週次、月次、会議前 |
| 除外条件 | テスト、キャンセル、下書き、失注 |
| 権限 | 誰がどの粒度まで見られるか |
ここが曖昧なまま外部BIに出すと、kintoneのグラフと外部BIの数字が合わなくなります。
まずは標準グラフで、指標と対象レコードを固定します。
その後、標準グラフで表現できないものを外に分けます。
kintoneグラフでよくある失敗を整理します。
| 失敗 | 原因 | 対策 |
|---|---|---|
| グラフが多すぎる | 誰が見るか決めていない | 会議用、日次確認用、分析用に分ける |
| 数字の意味が説明できない | 指標名と対象条件が曖昧 | 正本アプリ、日付、状態を定義する |
| 円グラフが読みにくい | 項目数が多い | 棒グラフや一覧に変える |
| クリック後に行動できない | 一覧項目が足りない | グラフ後の一覧を設計する |
| 人によって数字が違う | 閲覧権限が違う | 会議用の閲覧範囲を確認する |
| 月次の数字が再現できない | 最新値だけを見ている | 定期レポートや集計結果保存を使う |
| 外部BIと数字が合わない | キー、条件、更新頻度が違う | 出力前に定義を揃える |
特に多いのは、グラフを作ることが目的化することです。
グラフがあると、管理できているように見えます。
しかし、どの数字を見て、誰が、何を決めるのかが曖昧なら、会議で眺めるだけになります。
グラフは、一覧、レコード、通知、会議、改善アクションにつながって初めて意味があります。
Bitlightでは、kintoneグラフを、単なる表示設定ではなく業務判断のための設計として整理できます。
たとえば、次のような支援ができます。
kintoneグラフは、作るだけならすぐに始められます。
しかし、業務で使うには、指標、元データ、一覧、権限、更新頻度を揃える必要があります。
標準グラフで足りるものは標準で作る。
複数アプリ横断、長期履歴、複雑な計算、外部共有が必要なものは、集計結果アプリや外部BIに分ける。
この境界を決めることで、kintoneのグラフは見た目の資料ではなく、会議と現場判断に使える画面になります。
千葉県出身。10歳の頃からプログラミングを始め、ゲーム、Webサイト、ロボット、スマホアプリなどを制作。大阪大学基礎工学部情報科学科で情報工学と統計学を学び、大学時代はAIを研究。大学在学中にWeb広告代理店でのインターンや人材系Webサービスの立ち上げを経験し、卒業後はフリーランスエンジニアとしてGISシステム、データ基盤構築、Webシステムの開発に従事。10年以上のWebアプリ開発・データ分析経験を基に、2023年9月に株式会社ビットライトを設立し、現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援。