Sun* YOSUKA(ヨスカ)|経営企画・事業管理のためのAIデータ活用基盤

数字と現場の声を、AIが
「次の一手」に変える。

数字の変化を、現場の記録までたどる。
売上・コストと日報・商談ログをつなぎ、
判断の根拠をそろえるAIデータ活用基盤。

指標の整理からデータ連携、活用まで。Sun*が伴走します。

DATA → CONTEXT → ACTION01 / CONCEPT
散在する数値と現場の記録を、判断の根拠へ 売上・コストと日報・商談ログがYOSUKAでつながり、変化の理由と次の一手を検討するための根拠になります。 BUSINESS DATA 売上・コスト FIELD CONTEXT 日報・商談ログ YOSUKA 数値 × 文脈 会社の言葉でデータをつなぐ EVIDENCE FOR YOUR NEXT MOVE 「なぜ」から「次の一手」へ。 根拠をたどり、人が判断する。
散在する情報を、判断の根拠へ。Sun* YOSUKA
01

調べる作業から、判断へ

数値と現場の記録をまとめて確認。調査より、対策を考える時間へ。

02

信頼できる数字で判断

集計には定義済みの指標とデータベースの結果を使います。回答に使った問い合わせと参照元を確認できます。

03

今のDB・BIはそのまま

既存のデータベースやBIツールを壊さず、足りない層だけを追加して導入します。

The Cost of Looking Only

数字は見える。理由が見えない。

ダッシュボードで変化に気づいても、その背景を探す作業が残っています。

こんなお悩みはありませんか?

理由を聞き回る

数字が悪化しても、ダッシュボードには理由がない。各部門に確認して回り、報告が遅れます。

会議のたびに数字が食い違う

部門やツールごとに集計条件が違い、議論の前に「どの数字が正しいか」の確認から始まります。

対策を考えられる人が限られる

背景を知るベテランの勘に頼り、担当者が変わると判断が止まる。汎用AIに聞いても業務の前提を知りません。

How Your Work Changes

ある月、粗利率が下がった。
YOSUKAなら、こう追える。

経営企画の担当者が、月次の数字の変化から対策の検討に進むまで。調べる作業が、判断の時間に変わります。

THE EXPERIENCE01 / 04
月次レビューの朝

気づく

ダッシュボードで粗利率の低下を確認。「どの事業部で、なぜ」をYOSUKAに質問します。

数値の変化、参照した記録、次の行動を並べたYOSUKAの画面イメージ 数値の変化、参照した記録、次の行動を並べたYOSUKAの白系画面イメージ
CONCEPT IMAGE 01 — 04

※架空の例です。実際の画面と流れはデモでご覧いただけます。

実際の画面:質問から回答まで (架空データのデモ映像)

Sun*自身が、毎日使っています

経営層・管理職が日次でYOSUKAに質問し、売上・稼働・人員に関する判断に活用しています。

18データソースを接続スプレッドシート・基幹API・社内システム
約3か月で自社データを接続完了その後、約5か月間 日次で利用
約1,350万行のデータを単一ノードで運用人員 約5,100名分・案件 約2,200件

※2026年9月時点のSun*社内実績。デモでは実際に運用中の画面をご覧いただけます。

How YOSUKA Works

散在するデータを一本の流れにし、
AIが「会社の言葉」で答える。

上の流れを支えるのが、指標と業務ルールの一元管理です。データソースからアウトプットまでを4ステップでつなぎ、中核のセマンティックレイヤーが「会社の言葉」でデータを定義します。 指標・ルール・用語を共通の辞書で定義することで、部門をまたぐ議論でも同じ数字を基に判断できます。

01

データソース

スプレッドシート、基幹システムのAPI、社内システム、日報などのテキストを取り込みます。SaaSや外部DBは対象データごとに接続を設計します。

02

パイプライン

夜間バッチで日次更新。欠損・重複・鮮度を自動検知し、dbtでリネージを管理します。

03

セマンティックレイヤー

指標定義・ビジネスルール・用語辞書・権限を「マスター辞書」として一箇所に集約します。

04

アウトプット

ペルソナ別ダッシュボードと、根拠付きQ&Aや予兆通知に対応するAIエージェントで活用します。

接続実績
15Google スプレッドシート 3REST API 基幹システム連携 社内システム MCP連携 Slack Metabase

kintone・Salesforce・Snowflakeなどは、API接続を前提にDiscoveryで対象データごとに設計・実装します(個別開発)。

セマンティックレイヤーとは

会社の数字の定義を一箇所に書いておく「辞書」です。「売上」は受注額か請求額か、「粗利率」の計算式は何か、「A事業部」にはどの部門が含まれるか。部署や人によって違いがちな定義を、データベースと人の言葉の間に置いて統一します。

YOSUKAはこの辞書を見て集計するため、計算式を定義に沿って扱い、集計結果の根拠をたどれます。誰がどのデータを見てよいかの権限も、ここで管理します。

技術構成の詳細を見る(情報システム部門の方向け)

YOSUKAは4つの層を積み重ねた構成です。L1が土台のデータベース、L2がデータを整える層、L3が指標とルールの辞書、L4が利用者やAIとの接点です。上の4ステップを、技術要素で言い換えたものになります。

L1高速集計DBClickHouse L2データ変換・履歴管理dbt L3指標・ルール定義Semantic Layer L4AI対話・連携AI Interface/MCP
動作確認済みクライアント
Claude Desktop/Code GitHub Copilot VS Code OpenAI Codex ChatGPT Desktop/CLI

MCP標準に準拠しているため、他のMCP対応クライアントも接続可能です(導入時に個別検証)。

利用結果を振り返り、指標・ルール・回答品質を改善

01使う
02判断ログが貯まる
03根拠の質が上がる
04活用範囲が広がる
Use Cases(想定シナリオ)

「次の一手」を考える材料を、データから。

部署ごとに異なる問いにも、数字と現場の記録をつないで考える。4つの想定シナリオです。

USE CASE / 01
営業

提案先を、根拠から見つける

現状

商談フェーズや担当者の経験だけでは、次の提案先を絞り込みにくい。

YOSUKAで

売上・商談メモ・日報をつなぎ、顧客ごとの提案候補と判断材料を整理します。

想定する担当者 営業企画・営業マネージャー

USE CASE / 02
プロジェクト管理

遅れの兆しを、早くつかむ

現状

月次の原価率や工数だけでは、問題が表面化するまで気づきにくい。

YOSUKAで

工数・進捗と日報・チャットを重ね、確認すべき変化と対応の選択肢を示します。

想定する担当者 PM・PMO

USE CASE / 03
多拠点店舗

店舗の違いを、次の施策へ

現状

数字だけでは不振の背景が見えず、成功店舗の工夫も共有されにくい。

YOSUKAで

POSと臨店レポート・店長日報をつなぎ、要因候補と横展開できる施策を整理します。

想定する担当者 SV・店舗運営本部

USE CASE / 04
調達・購買

値上げの理由を、見積もりの先まで

現状

価格の変化を、過去の交渉や仕様変更と照らし合わせるのに時間がかかる。

YOSUKAで

コスト・見積書・交渉履歴を横断し、値上げ要因と次の交渉で確かめる点を整理します。

想定する担当者 調達・購買担当者

※4つの活用例は想定シナリオです。

実際の画面で見る

デモを申し込む →
Deployment Patterns

既存投資はそのまま。
足りない層だけを足す。

DWHがあってもなくても、今の状態から最短ルートを描きます。 既存のDWHやBIを活かし、足りない層から追加する導入方法を設計します。

PATTERN A

DWHが整っている

既存DWHに接続し、セマンティック層+AI層だけ追加します。

データソース(既存活用) パイプライン(既存活用) DWH(既存活用) セマンティック層(追加) AI層(追加)
PATTERN B

DWHはあるが散在

追加パイプラインでExcel・SaaSを合流させ、横断分析へつなげます。

データソース(既存活用) パイプライン(追加:散在データを合流) DWH(既存活用) セマンティック層(追加) AI層(追加)
PATTERN C

DWHがまだない

YOSUKA標準構成をそのまま導入。パイプライン+DWHを新規構築します。

データソース接続(新規構築) パイプライン(新規構築) DWH(新規構築) セマンティック層(新規構築) AI層(新規構築)

約10週間でのPoC開始を想定(データソース5件程度・業務質問20〜50問が目安)

既存活用 Sun*構築
Security & Governance

業務で使うデータを、
管理できる形で。

データの配置場所、アクセス範囲、利用記録を導入時に設計します。 専用環境への配置や閲覧権限、問い合わせの記録を組み合わせ、社内の情報管理方針に合わせて運用を設計します。

専用インフラ

YOSUKAのサーバーとデータベースは、お客様の環境内(オンプレミス/専用クラウド)に配置できます。AIはMCP対応クライアントから利用します。

環境に合わせた設計

データの配置場所やAIの利用範囲を、お客様の情報管理方針に合わせて設計します。

コンプライアンス&監査

AIはデータベース全体にはアクセスしません。受け取るのは、権限内で検証済みの問い合わせが返した結果のみ。すべての問い合わせを監査ログに記録します(結果の中身は保存しません)。

権限と標準化

利用者ごとの許可リストと管理者権限で利用範囲を制御。AIが参照できるデータ層・項目は、導入時にお客様のポリシーに合わせて設計します。

AIモデル側でのデータ保持・学習利用の有無は、ご利用のLLM提供者との法人契約、またはオンプレミス配置により制御します。

Process

問いを定め、データをつなぎ、
PoCで確かめる。

改善したいKPIと業務上の問いを起点に、データ連携・指標の定義・受入テストを進めます。PoC後の改善もエンジニアが伴走します。 問いの定義からデータ連携、受入テストまでSun*のエンジニアが伴走します。標準構成では、約10週間でPoCを始める計画です。

01

現状把握と環境準備

第1〜2週

業務フローと問い(20〜50件)を定義し、専用環境にデプロイします。

02

データ連携と指標・ルールの定義

第3〜6週

データマートを構築し、ビジネスルール・辞書を定義します。

03

受入テストとPoC稼働開始

第7〜10週

受入テストと精度の調整を行い、PoCを稼働開始します。

04

改善と他部門への展開

PoC後・継続

FDE伴走支援として、現場アクションに基づき精度を更新し、他部門へ横展開します。

約10週間は、標準構成をそのまま導入するパターンC(データソース5件程度・業務質問20〜50問)の目安です。既存基盤を活かすパターンA・Bは、現状把握(1〜2週間)を経て個別にご提示します。

Comparison

既存BIのAI機能や、汎用AIと
何が違うのか。

「指標を定義して自然言語で聞く」仕組み自体は、BI製品のAIアシスタントにもあります。YOSUKAの違いは、複数システムの数値と業務記録をつなぐ範囲と、指標・例外・権限の整備と更新をSun*が伴走して担う点にあります。

評価軸 既存BI+AIアシスタントBI製品付属のCopilot等 汎用AI+社内文書チャット型AI・一般的なRAG YOSUKASun* AI DataOps
扱えるデータ BIに取り込んだ数値が中心 文書・テキストが中心。数値集計は不得手 複数システムの数値と、日報・商談ログ等の業務記録を結合
数字の再現性 セマンティックモデルがあれば定義は揃う AIがその場で計算・解釈するため、同じ質問でも答えが変わりうる 定義に沿った集計。数字は定義済みの問い合わせ結果を参照。同じ定義とデータの状態で集計
指標・例外・権限を
誰が整備するか
自社のBI担当が設計・保守 プロンプトや文書の整備を利用者が担う Sun*が業務ヒアリングから定義し、専用環境に構築
導入後の定義変更・
品質改善
自社運用 属人的になりやすい Sun*のFDE(Forward Deployed Engineer)が伴走して更新。基盤はオープンソースで、内製運用への移行も可能
既存BIとの関係 ― 別系統 既存BIは残し、足りない層だけ追加

※比較は一般的な使い方を整理したものです。導入環境や製品の構成により異なります。

FAQ

よくあるご質問

既存のBIツール(Tableau/Looker等)は捨てる必要がありますか?

併用できます。YOSUKAは指標定義を反映したデータマートをClickHouse上に保持し、Tableau・Power BI・LookerはClickHouse公式コネクタ経由で同じマートを参照できます。AIに聞いた数字とBIの数字が揃う状態をつくれます。※当社での接続実績はMetabaseです。他ツールはPoC時に接続検証を行います。

どんなデータが必要ですか?Excelや日報だけでも始められますか?

Excelや日報テキストのみからでも着手できます。データの整備状況に応じて、導入パターンA〜Cのいずれかをご提案します。

使うLLMは選べますか?自社契約のモデルを使えますか?

選べます。動作確認済みはClaude(Desktop/Code)、GitHub Copilot(VS Code)、OpenAI Codex(ChatGPT Desktop/CLI)です。MCP標準に準拠しているため、他のMCP対応クライアントや、お客様のクラウド契約内で動くLLM(AWS Bedrock、Google Vertex AI等)、お客様サーバー内のローカルLLMも設計上は接続できます。これらは導入時に個別に検証します。

PoC後に止めることはできますか?成果物は残りますか?

PoC終了時点でパイプライン・指標定義などの成果物は残り、継続するかは受入テストの結果を踏まえてご判断いただけます。本番運用へ移行する場合は、ユースケースの拡張、指標定義の精度改善、他部門への横展開を、Sun*のエンジニアが現場に入って伴走するFDE伴走支援(FDE=Forward Deployed Engineer)でご支援します。基盤はClickHouse・dbtなどのオープンソースで構成されており、お客様側での内製運用への移行も可能です。

YOSUKAという名前の由来は?

日本語の古語「よすか」から取りました。よりどころ・手がかり、という意味です。AIが答えを決めるのではなく、人が判断するための信頼できる根拠になる。このサービスで実現したい価値をそのまま名前にしています。

セキュリティ・情報管理の詳細を知りたい

YOSUKAのサーバーとデータベースはお客様環境内(オンプレミス/専用クラウド)に配置でき、AIはデータベース全体にはアクセスしません。AIが受け取るのは、権限内で検証済みの問い合わせが返した結果のみです。すべての問い合わせは監査ログに記録されます。AIモデル側でのデータ保持・学習利用の有無は、ご利用のLLM提供者との法人契約またはオンプレミス配置により制御します。詳細は商談でご説明します。

Next Step

まずは、YOSUKAの画面で確かめてください。

YOSUKAはSun*自社の売上・稼働・人員データで日次運用中です。デモでは、運用中の実物の画面をご覧いただけます。

  • デモは30〜45分。オンライン・対面どちらでも
  • 営業と、実際に開発しているエンジニアが同席。技術的な質問にもその場で答えます
  • デモ後は、貴社の業務でAIに答えさせたい「問い」を一緒に洗い出し、導入に向けた具体的なご相談を開始します

このサイトはreCAPTCHAによって保護されており、Googleのプライバシーポリシーと利用規約が適用されます。

※概要資料はデモ実施時にお渡しします。

デモを申し込む