1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • Flint は、データフィールドの意味に基づいてパース・軸・書式・色を自動決定し、低レベル設定なしでチャートを作成・修正できる可視化言語
  • Rank, YearMonth, Delta, Temperature のような 意味タイプ(semantic type) により、視覚エンコーディングに必要な詳細構成を推論
  • 弾力的レイアウトモデル とバンキング原則でサイズ・間隔・配置を調整し、チャートが増えるとキャンバスを拡張し、バンド幅を縮めて高密度な構成に対応
  • Vega-Lite、ECharts、Chart.js、Plotly で 50種類のチャート をサポートし、Office.js を通じて編集可能なネイティブ Excel チャートも生成
  • 単一のインターフェースでバックエンドを切り替えながら、ECharts の階層型サンバースト、Plotly の統計・分析トレース、Excel のブック内編集機能など 各ツールの強み を活用可能

意味ベースの仕様と自動最適化

  • Flint は、Rank, YearMonth, Delta, Temperature のようにデータフィールドの意味を表す 意味タイプ によって、パース、スケール、軸、書式、色の体系を推論
    • ゲーム別・月別の純新規ユーザー増減を示すヒートマップでは、gameCategoryperiodYearMonthnewUsersProfit に指定
    • 指定された意味に応じて、時間値パーサーと軸書式、発散型の色体系、中間点を自動決定
  • 自動レイアウト最適化 には弾力的レイアウトモデルとバンキング原則を適用し、キャンバスに合わせてサイズ・間隔・配置を動的に管理
    • グループ化棒グラフが疎な 5 × 3 構成から高密度な 22 × 3 構成へ増えると、キャンバスを拡張し、バンド幅を縮小
    • ばねが伸縮可能なコンテナ内で位置を決めるのに似た方式
  • 脆弱な低レベルパラメータを直接扱うことなく、チャート種類の切り替え と視覚エンコーディングの再接続だけでデザインを変更可能
    • 2000年の米国国勢調査における性別・年齢別人口分布を示したファセット棒グラフは、チャート種類だけを変えればピラミッドチャートに切り替わり、残りの低レベル設定はコンパイラが処理

バックエンド対応と最近のリリース

  • Vega-Lite、ECharts、Chart.js、Plotly 全体で 50種類のチャート をサポートし、ギャラリーにはバックエンド別のサンプル 121 件を掲載
    • 統合インターフェースが、バックエンドごとに異なる API とプログラミングモデルを隠蔽
    • ECharts は階層型サンバースト、Plotly は統計・分析トレースに活用可能
    • Office.js を通じて、ブックに挿入して編集できる ネイティブ Excel チャート を出力
  • v0.4.0 は 2026年7月24日に Plotly チャート種類 38 件 と、編集可能なネイティブ Excel チャートテンプレート 18 件を追加
  • v0.3.0 は 2026年7月19日に、チャート種類を切り替え、属性をその場で修正する 動的チャートウィジェット を追加
  • v0.2.2 は 2026年7月15日に compact dodge モードとグループ化 violin レイアウトを追加

1件のコメント

 
GN⁺ 3 시간 전
Hacker Newsのコメント
  • AI時代でも、ggplotのAPIは最高のチャートAPIだと思う。"Grammar of Graphics" は単なるマーケティング文句ではなく、あり得るあらゆる定性的グラフィックを表現できる文法を本当に作ろうとした試みだった
    その過程は https://link.springer.com/book/10.1007/0-387-28695-0 にまとめられている。紙とペンで描いていた昔のグラフを調べていてこの本を見つけたが、オーストラリア準備銀行の1960〜1980年代の年次報告書のチャートには個性があった一方、2000年代初頭には味気ないExcelチャートに変わっていた
    ggplotは昔のチャートの魅力を完全に再現してはいないものの、情報の伝え方はかなり参考にしているようだ。20.1節ではナポレオンのロシア遠征を表現した Minardグラフ を再現しており、似た例は https://www.andrewheiss.com/blog/2017/08/10/exploring-minard... で見られる
    pyplotやその上に構築されたAPIより見た目の良い結果が出るし、pyplotはラスターベースのレンダリングやテキスト処理に制約が大きいように思う。ggplotはRエコシステムにあるのでソフトウェアエンジニアにはあまり知られていないが、Node.jsやPythonのエコシステムでもこのAPIをもっと参考にしてほしい

    • Wilkinsonの Grammar of Graphics がggplotに着想を与えたのであって、その教科書にはggplot自体はまったく出てこない
      同じ哲学に着想を得て作ったDSLのAlgrafも公開している: https://williamcotton.github.io/algraf/demos. デモにはMinardグラフも含まれている
    • Python向けの plotnine も見てみる価値がある: https://raw.githubusercontent.com/rstudio/cheatsheets/main/p...
      ggplotを作ったHadley Wickhamが勤めていたRStudio系で開発され、現在は彼が勤めるPositの支援を受けている
    • Vega-LiteバックエンドのJSON仕様もおおむねGrammar of Graphicsの発想に従っている。最近HNで紹介されていた ggsql のほうがより気に入っている: https://ggsql.org/
    • Grammar of Graphicsの意味体系は人間にもエージェントにもすでに理想的だ。ggsqlはこれをSQLユーザー定義関数として実装していてエージェントがより扱いやすいので、Flintが何をさらに提供するのか分からない
    • 手描き風の魅力が欲しくて METAPOST を使う気があるならfizikoがある: https://github.com/jemmybutton/fiziko
  • Flintと、AIにVega-Lite仕様を直接生成させる方法の両方を使ってみたが、Flintのほうが優れた解決策というわけではなかった
    Flintはあらかじめ定義されたチャートタイプを低レベルでカスタマイズするときには悪くないが、エージェントやサブエージェントにVega仕様を直接作らせると、時系列の最小値・最大値の表示や特定の出来事の日付の注釈マーカーのような、はるかに柔軟で高品質な可視化が可能になる
    ただしVega-Liteには 仕様の検証と具体的な指示 が必要で、バグや癖のある挙動にも継続的に対処しなければならない。チャート生成を別個の技術として構築せず素早く始めるなら、Flintのほうが安定している

  • 複数のチャートバックエンドをひとつのインターフェースで扱おうとしているようだが、AIがFlintを書けるなら最初からバックエンドコードを書かせればいいのではと思う。バックエンドを差し替え可能にする理由は不明確だ
    ただ、LLM向けの シンプルなAPI であればトークン効率を高められるという利点はある

    • チャートバックエンドごとに対応するタイプが異なる。プロジェクト例のように EChartsのサンバースト とVega-Liteのファセット棒グラフの間を簡単に切り替えられるなら、とても有用だ
  • Microsoft/Flint-Chartは2026年7月2日にも紹介されていた: https://github.com/microsoft/flint-chart, https://news.ycombinator.com/item?id=48756577
    7月8日には「Show HN: Microsoft releases Flint, a visualization language for AI agents」として再び投稿されていた: https://microsoft.github.io/flint-chart/#/, https://news.ycombinator.com/item?id=48834924

  • 単に「plotlyでXYZグラフを作ってほしい」と言えば何が問題なのか?

    • 自動化されたデータ可視化では、その方法だと生成されたJavaScriptやPythonコードを実行する サンドボックス が必要になる。Flintのような仕様なら検証してすぐ描画できるし、LLMがVega-LiteよりFlintをうまく生成できるなら有用かもしれない
  • 22日前にももっと大きな議論があった: https://news.ycombinator.com/item?id=48834924

  • AI向けDSL はあまり妥当ではない。モデルは既存のグラフィックライブラリで学習されており、すでにかなりうまく扱える
    長期的には、Flintを公開したあと研究所がこのDSLに過学習するような「グラフィックベンチマーク」を作ることはできるかもしれないが、必要な作業が多すぎるように見える

  • どの水準から抽象化が過剰になるのか分からない。PlotlyやPlotly Expressでは不十分なのか、そしてもうひとつの JSON仕様 がどうやって新時代を開くのか疑問だ

  • 興味深いが、本当に必要かは分からない。Apache EChartsをはじめ成熟したチャートライブラリはすでに多くあり、結局は既存の車輪を作り直しているように見える
    新しいツールが登場し、機能が次々に追加されたあと、少し違う設計や文法を採用した別のツールが元のツールを置き換える、ということが繰り返される
    階層型サンバーストにはECharts、統計・分析のトレース線にはPlotly、ブック内で編集するチャートにはExcel、というように バックエンド固有の強み を活かすこともできる。あるいは、気に入ったチャートライブラリをひとつ選んで機能をしっかり習得するほうが、複数ライブラリのプリセットだけを混ぜて細かな調整をしないより良い