kubell Creator's Note

株式会社kubellのエンジニアのブログです。

ビジネスチャット「Chatwork」のエンジニアのブログです。

読者になる

分析エージェントの設計:なぜ「職種別」にエージェントを分けるのか?Snowflake Intelligenceでの実践事例

こんにちは。
プロダクトDivでデータアナリスト・アナリティクスエンジニアをしているタダケンです。

前回の記事では、Snowflake Intelligence(以下、SI)における「コンテキスト(Semantic View)の育て方」についてお話ししました。

今回は、そのコンテキストを利用する側である「分析エージェント自体の設計」について、kubellでの実践事例を交えて紹介します。

「全社員向けの万能エージェント」を作るべきか、それとも「特定用途のエージェント」を作るべきか。現在進行系で検証を進めている私たちの解は、「エンドユーザーの職種(ユースケース)ごとにエージェントを立てる」というアプローチです。

続きを読む

データ活用AIエージェントの構築で見えた、Snowflake Intelligenceの可能性

こんにちは。
プロダクトDivでデータアナリスト・アナリティクスエンジニアをしているタダケンです。

データ活用技術の進化は目覚ましいですが、最近特に注目しているのが Snowflake Intelligence(以下、SI)です。

kubellでも、プロダクト・事業戦略目標の達成に向けて、この新しい技術のポテンシャルをいち早く検証すべく、PoC的に実証実験を行っています。

今回は、Snowflake Intelligenceの技術的な概要と、実際にPoCを通じて見えてきた「分析用AIエージェントを実用化するためのコンテキストの育て方」について、具体的な知見を紹介したいと思います。

  • Snowflake Intelligenceの概要
  • 実は大事な分析基盤の整備
  • Semantic Viewの重要性:AIに「文脈」を教える
  • 分析用AIエージェントにおけるセマンティックとコンテキストの育て方
    • 1. Descriptionを詳細に記述する
    • 2. カラム単位での丁寧な補足
    • 3. Verified Queriesによるサンプルクエリの拡充
    • 4. 利用と育成のサイクルを回す
  • まとめ

Snowflake Intelligenceの概要

Snowflake Intelligenceは、自然言語を用いてデータと対話し、インサイトの抽出からアクションの実行までを包括的に支援するインターフェースです。実態としては、複数のコンポーネントで構成されています。

Cortex Analyst(構造化データ分析)、Cortex Search(非構造データ検索)、Cortex Agents(自動タスク実行)を通じて、対話形式で洞察を得られれます。

弊社で主に活用しているのが、以下2点になります。

  1. Cortex Agents: ユーザーからの自然言語の問いかけを受け取り、ツール選択やタスク実行を行うオーケストレーター。
  2. Cortex Analyst (Semantic View): データの意味(セマンティック)、文脈(コンテキスト)を定義し、自然言語を精度の高いSQLに変換するセマンティックレイヤー。

これらとdbtで構築したデータモデルを組み合わせて、AIエージェントを構成しています。

続きを読む

CQRS+ES Conference 2026 に参加してきました

こんにちは! ファサード開発チームの中川です。
2026/01/10 に開催された CQRS+ES Conference 2026 に、チームの開発メンバーとともに参加してきました。

会場となった福岡工業大学

私の所属するファサード開発チームでは、Chatworkのファサード層(API Gateway層)を開発・運用しています。 既存の仕組みと新しいアーキテクチャをつなぎつつ、クライアントに安定したインターフェースを届ける役割を担っています。(詳しくは、Chatworkの技術的展望について - kubell Creator's Noteの記事に詳細がありますので、気になる方はぜひご覧ください!)
こうしたつなぎ目のレイヤーで開発をしていると、可用性や拡張性を落とさずに連携していく設計が重要だと感じる場面が多いです。 今回のカンファレンスは、まさにその周辺(イベント・ドメイン・分離・運用)をまとめて吸収できそうだと思い、チームで参加しました。

なお、私自身は新卒1年目で、技術カンファレンスへの参加も今回が初めてです。
本記事では、当日印象に残ったことと、複数のセッションを通して共通して学んだことを中心に初学者の目線で振り返ります。

続きを読む

スポットインスタンスの可用性をSpot Placement Scoreで事前評価する

1. はじめに

SREグループの山下(@task2021)です。

ARM スポットインスタンスは本当に十分に確保できるのか?

AWSにはSpot Placement Scoreという、「特定の条件においてスポットインスタンスをどれくらい確保しやすいか」を事前に評価できる仕組みがあります。

スポットインスタンスは、オンデマンドインスタンスと比較して大幅なコスト削減が期待できる一方で、中断される可能性があるという特性を持っています。

そのため、ワークロードの要件に適合する場合には、コスト効率の高い選択肢として非常に有効です。

「Chatwork」のEKSクラスターでは、一部のアプリケーションサーバーを除き、基本的にスポットインスタンス上でアプリケーションを動作させています。

これまで私はSpot Placement Scoreという機能を全く知らなかったのですが、「EKSノードをGraviton(ARM)に統一する」検討を進める中で、スポットインスタンスの可用性を事前に判断する材料として非常に参考になったため、本記事で紹介します。

続きを読む

kubell プロダクトユニット AI 推進委員会のふりかえり

こんにちは。株式会社 kubell コミュニケーションプラットフォームディビジョン プロダクトユニットの須田です。

今年の途中から、プロダクトマネージャー・エンジニア・デザイナー・SRE・QA・カスタマーサポートなどなどの業種を束ねる「プロダクトユニット」という組織で、AI 推進委員会なる委員会に所属して活動してきました。年末のこの機会に、特に下半期の活動をふりかえってみたいと思います。

この記事は kubell Advent Calendar の12月24日分の記事です。その他の記事はこちらから。

qiita.com

続きを読む