こんにちは！サイボウズでプロダクトエンジニアをしている @daikimkw です。
この記事では、kintone のフロントエンド開発で AI をどのように活用しているか、そして kintone 開発全体として生産性を向上させるために今後どのような取り組みをしていくかについて紹介します。
kintone 開発での AI 活用については、以下の記事でも紹介しています。
- サイボウズで利用可能な AI コーディングツールの紹介
- kintone AI 開発の効率化！Claude Code に Renovate PR レビューをお任せした話
- チーム専用の Claude Code Plugin マーケットプレイスを作った話
また、本記事の取り組みの一部は JS ConfJP 2025 で発表しているので、そちらの動画や資料も参考にしてください。
AI 活用の取り組み
kintone は顧客領域ごとに複数チームで開発されており、コードベースの規模も大きく、AI をうまく機能させるにはいくつかの工夫が必要でした。
ドメイン知識をマークダウンで管理する
kintone は歴史的経緯や最適化のための工夫により、コードを読んだだけでは意図が伝わりにくい設計が多くあります。これらを AI に都度伝える必要がないよう、ドメイン知識をマークダウンファイルとしてリポジトリに配置し、AI が参照できるようにしています。具体的には、JS API・プラグイン機構・グラフなどの複雑な実装の設計背景や、kintone 固有の用語集などです。
kintone のフロントエンドはチーム単位でディレクトリが分かれており、その中で pnpm の monorepo として構成されています。この構成を活かし、ドメイン知識のマークダウンもチームごとに配置しています。こうすることで、AI が参照するコードとコンテキストの範囲がチームの担当領域に絞られます。グラフなどの複雑な実装や設計背景も、グラフを管理しているチームに閉じられるため、他チームのコンテキスト消費を抑えられます。
frontend/ ├── teamA │ ├── ai-guide # ドメイン知識をチームごとに管理 │ │ ├── js-api.md # JS API の設計 │ │ └── glossary.md # 用語集 │ ├── app1 │ ├── app2 │ ├── pnpm-workspace.yaml ├── teamB │ ├── ai-guide │ ├── app1 │ ├── app2 │ └── pnpm-workspace.yaml └── ...
Agent Skills をチーム横断でリポジトリ管理する
kintone 開発では、もともと各チームで Agent Skills を整備していました。
kintone リポジトリのルートに共通の Agent Skills もいくつかありましたが、チームによっては不要な Agent Skills が混ざっていると不要なコンテキスト消費につながってしまいます。一方で、チームの中だけに閉じていると知見がサイロ化してしまいます。
そこで、お互いの Agent Skills を参考にしつつ、チームごとに必要なものだけを選んで導入できるように、kintone 開発全体で共有する共通リポジトリを用意しています。
kintone-skills/
├── kintone-development/
│ └── skills/ # 汎用 Agent Skills
├── teamA/
│ └── skills/ # チーム固有の Agent Skills
└── teamB/
└── skills/
Claude のプラグインマーケットプレイスの構造に準拠させているため、 /plugin から追加でき、Cursor など他のツールでも vercel-labs/skills 経由で利用できるようになっています。ルールは設けず自由に追加できる運用にすることで、他チームがどんな Agent Skills を作っているか見える化し、知見がサイロ化しないようにしています。
具体的な Agent Skills の紹介
実際に使っている Agent Skills をいくつか紹介します。
文言の検討
kintone は多言語対応しており、新しい機能を実装するときには複数言語の文言を用意する必要があります。ただし、デザインシステムのライティングガイドラインや既存の文言パターンとの一貫性を保つのは手間のかかる作業です。この文言作成・レビューのワークフローも Agent Skills 化し、効率よく文言の検討を進められるようにしています。
以下は、「input:type=file にホバーしたときに相当する文言を検討して。」と入力した時の結果です
セッション情報をファイル出力する
AI とのやりとりはセッションが途切れたり、サマリー化（Compact）されるとコンテキストが失われます。そこで、AI とのやりとりや、実装計画を全てファイルに出力して残すようにしています。
実装開始時に、次のようなディレクトリを作成します。
0123_feature-name/ ├── plan.md # 実装計画 └── prompt.md # やりとり履歴
plan.md には、実装計画、タスクの分解、進捗を記録します。prompt.md には、生のプロンプト内容と、それに対してどう実装したかを記録します。どういう指示を出して、AI がどう判断したかが残るため、コンテキストの復元に役立ちます。
この 2 つのファイルにより、セッションが途切れても作業を再開でき、計画と実装を別のエージェントに任せるなど、柔軟にエージェントを切り替えることもできます。
エージェントによっては、実装計画専用のプランモードがありますが、プランモードを抜けるタイミングでファイル出力等のコンテキストを忘れてしまうため、今はプランモード相当のサブエージェントを使用しています。プランモードを抜けるタイミングで Hook させ、思い出させることができればもっと良いのですが、今のところはこのようになっています。
ドメイン知識を継続的に育てる
ドメイン知識を管理するマークダウンファイルは実装が進むにつれて内容が実態と乖離していきます。そのため、定期的に実装とドキュメント内容に乖離がないかチェックするための Agent Skills も用意しています。
MCP の活用
Agent Skills だけでなく、MCP も AI の作業範囲を広げるのに役立っています。
kintone には kintone Design System チームが管理するデザインシステムがあり、デザイントークンやコンポーネントの仕様が Figma や npm パッケージとして管理されています。
Figma で構築されたデザインの反映には Figma MCP や Chrome Devtools MCP 等を活用し、デザイントークンの取得から動作確認まで AI に任せています。
また、kintone Design System チームでは、コンポーネントの情報や仕様を取得できる MCP サーバーも開発しています。これにより、AI がデザインシステムの仕様を直接参照しながらコードを生成できるようになっています。
これからの課題
AI 活用が進む一方で、まだ解決できていない課題もあります。開発工程での AI 活用が進んでも、全体のリードタイムを短縮するには、デザインや品質保証のプロセスも一緒に変えていく必要があります。現状は、各チームが試行錯誤しながら、うまくいった取り組みを横展開していくという形になっています。この動きを加速させるために、組織横断での AI 活用推進の取り組みもやっています。こちらについては、また 1 〜 2 ヶ月後に誰かが書く記事を参考にしてください。
おわりに
kintone 開発における AI 活用は、個人の生産性向上から始まり、開発チーム横断でのナレッジの共有、そして他職能を跨いだ活用推進へと広がりつつあります。開発速度以外も AI を使って加速させていきたいですね！
