kintoneからエクスポートしたCSVデータの変換ライブラリを作ってみた

kintoneとは

Web DB SaaS ですね。

• フォームビルダー
• 一覧の機能
• 入力画面

がある。いつからか急にノーコード、ローコード言い始めたけど、当初はそんな言い方じゃなかったように思う。

加えて

• ワークフロー機能（プロセス管理）
• 通知機能

もあるのだが、この辺から「ノーコードとは？」という気持ちになってくるので、あんまり鵜呑みにしない方がいいと思う。長大な if 文を GUI で作れてしまうので危険があぶないし、ワークフロー部分はデータベース部分と違ってまとめて「管理」機能の中に収まってしまっていてロールバックもできない。

「誰でも業務アプリが作れる」というフレコミに 2025 年現在はなっている。思うところはいろいろあるが、まぁ作れなくはない。

少なくとも Excel や Google Sheets と違って、複数人で利用することが前提になっていて、データそのものとビューが分離していて、ユーザーごとにビューが独立している点は評価できるし¹、AppSheet と違って「動くものを作る」ところまでのハードルは本当に低いと思う²。Google Forms + Spreadsheets 連携を扱える人なら、それっぽいものを作ることはできる。

だからこそ、運用に入ってから苦しみが生まれるシーンも増えているとは思うが、それはまぁ「作れる」ことの評価とは別軸の話である。

kintoneのデータを扱うえでの注意点

誰でも作るというフレコミではあるが、実際に活用しようと思うとそれぞれの領域でペインポイントはある。

• フォームビルダー
• 入力画面
• 分析周りとデータの扱い

ここではペインポイントを網羅することは目的ではないので、分析周りとデータの扱いだけ軽く触れていく。

データ構造が独特で変更に弱い

これはアプリそのものの設計にも関わるのだが、データモデリングできる人が普通に正規化して作ろうと思うとテーブルに相当する「アプリ」を分割、連携する格好になる。もちろん「社員マスタ」みたいな「いかにも独立しているべき」なアプリもあるが、「ちょっとした選択肢」のために全部のアプリが分かれているとそれはそれで扱いにくい。（複数のテーブルをまとめて一つのアプリとして動作させるという使い方はできない。）そこで「正規化崩し」みたいな話になるのだが、それをすると一つのアプリの中の構造は複雑になり、変更しにくくなっていく。この辺の塩梅は実際のところ意外と難しい。

kintone アプリのデータベース視点での設計については R3 institute さんが詳しい資料を公開しているので参考になると思う。

cf. kintoneでのデータベース設計の基礎 - アールスリーインスティテュート ｜R3 Institute

意外なほど分析系が弱い

kintone はサイボウズ自身が「高度な集計処理には向いていない」と言っている³んだけど、この「高度」の閾値は自分の感覚で言うとだいぶ低いと感じる。

どちらかというと「構造化ドキュメントデータベースをローコストに構築、維持できる」くらいの使い方に強く、データの素朴なグラフ化もできるものの、集約、分析になると力不足は否めない。ピボットテーブルとかも作れるんだけど、設定できる項目数が少なすぎて結果的にとても微妙な感じになったりする。上に書いたようにアプリの中身の複雑さを上げる使い方は簡単にできるのに対して、集約、分析系の機能が追いついていない感じだ⁴。

API連携はいろいろ制限がある

• プランが2025年5月現在、スタンダードコース以上じゃないと使えない
• 連携ツールが対応できないデータ構造もある
• 連携ツールは案外簡単に limit に達してしまう

kintone と Google Spreadsheet を API 連携させるようなツールもあるが、万能ではない。対応できない構造もある。また機能が細かく気が利いていればいるほど 1万req/日/アプリ の制限⁵が意外と重い。カスタマイズ JS で ActiveRecord の callback みたいなこともやらせていたりすると雪だるま式につらくなる。

※ これもアプリの構造次第ではある

そして当然だが

• API 連携を自前でやるのはさすがに非エンジニアには厳しい

CSVエクスポートという選択肢

※ ここではインポートは考えていない。あくまで分析系の弱さを補う使い方が前提なので。

kintone 自前の分析機能にも頼らず、API にも頼らない方法となると、

エクスポートして外部のツールで分析する

になってくる。これは

• 全プランで対応できる（はず）
• API に対する知識もスキルも不要、制限にも掛からない

と、おいしいのだが、一方で

• エクスポートしたデータの構造が独特
• 当然容量に制限がある
• 権限管理が通常のアプリの利用とは異なるので、誰にでもは許可できない

という、最初の課題は残りつつ、新たな課題も加わってくるので注意は必要になる。とりあえず一部の人だけ許可するのがよいと思う。

エクスポートしたCSVのデータ構造

これは公式に説明がある。

出力されたファイルに関する補足事項 | kintone ヘルプ

以下のような点が特徴的だ。

• 1レコード1行が基本なのだが「レコード」の中に「テーブル」構造のデータがある場合、この「テーブルのレコード」分、行数が増える
  • 「テーブル」以外のデータはコピーして増えている状態なので、RDBMS で言う別テーブルのデータを join したような格好になる
  • しかも「テーブルのレコード」にはサロゲートキーがない
• 複数選択可能なフィールドは選択肢の分だけフィールドが増える
  • フィールド名に選択肢名が含まれてしまう
  • 選択されているフィールドの値に 1 が入る

前段は分からなくもないが後段はだいぶ面倒。選択肢を変更したらエクスポートされるデータの形式が変わるので、特に Excel / Spreadsheet で扱おうとしている人にとっては列が変化すると関数で参照する先が変わってしまうので、kintone の選択肢一つを気軽に変えるとあっちもこっちも全部変える必要が出てくる。

本題 - 変換ライブラリ作ったよ

ということで上の解決策の一つとしてライブラリを作った。

wtnabe/kintone-tabulax: A utility for kintone’s CSV, now it normalize and unpivot table

ねらい

とにかく SQL-friendly になること

• Excel / Spreadsheet function に依存するとメンテナンス性がよくない
• なんだかんだ SQL のスキルは寿命長いのでみんな幸せ
• 実質容量無制限の DWH は選択肢がある

例えば以下のような構成を実現できる。

Google Apps Script でも動くので以下のような感じも可。のはず。

BigQyery のソースになる Sheets が安定するオペレーションを組めれば、あとは CSV をダウンロードして当てはめ直すだけで最終の Sheets の生成はほぼ自動と言ってよい。

できること

• CSV ファイルから取得できる key-value の Array を対象に処理する
• 言語設定によってアプリのサロゲートキーが変わってしまうが、これを外部から指定できる
• 「テーブル」のデータをレコード内から分離し、foreign key として元の Record number を加える（normalize）
• 複数選択のフィールドを一つにまとめ、選択されている値の分だけレコードを伸ばす形に転回する（unpivot）
• I/O を持たないので様々なプラットフォームで動く（Google Apps Script でも）

制限

• ツールとして完成していない
  • CSV そのものを与えることはできない。ファイルをそのまま処理できない。これは Google Apps Script や他言語を含む様々な利用シーンを想定して I/O の部分を完全に分離しているため
  • まぁいろんなアダプタ作ろうと思えば作れるけど、…はい。
• 全部インメモリで処理するので大容量だとたぶん死にます

作ってみて

今回も最近の流れで生成 AI と一緒にやってみたんだけど、

• Cline + Gemini 2.0 flash はもう全然言うこと聞いてくれなくてすごくイライラした
• Claude Code はだいぶイケてる
• 伝統的な TDD は発見のプロセスとして優秀だが AI とは相容れない
• 今回みたいなものは変換で実現したいことを以下のような言葉で明確に分解できないと期待したコードにならない。アルゴリズムの問題だから AI の方が詳しいだろうと思っていたが、動かしながら「あ、こういうことをやりたいんだ」って気づくやり方とは相性が悪い⁶
  • 直積
  • unpivot
• TypeScript を起点に npm ( ESM ), Google Apps Script で利用しやすいコードをパッケージにしたかったんだけど、その手法の提案もツールの名前ばかりたくさん出てきて重厚なプロセスになりがち

何回か、何ヶ月かやってみているけど、生成 AI の出力するコードやタスクの起こし方は小粒でピリリ系のライブラリとは相性がよくない感じがする。UI 周りとか似たコードが大量に出てくる、フレームワーク全振りで比較的作業に近いコードの方が向いているのかもしれない。