kintoneプラグイン開発環境をNode.js製CLIで仕組み化｜Vite・TypeScript・AI同期まで

この記事では、kintoneプラグイン開発環境をNode.js / TypeScript製CLIで仕組み化した方法を紹介します。

森田ユウゴ

#kintone100日チャレンジの99日目の成果物です。

約100回の試作を重ねる中で作り上げてきた、AI開発時代における私のkintoneプラグイン開発環境の公開です。

kintoneのプラグイン開発は、主に6つの工程があります。

1. プラグインの要件定義・設計
2. リポジトリ（プロジェクト）を初期化
3. プログラミング
4. テスト
5. 秘密鍵を作る / プラグインのパッケージング
6. kintoneへアップロード

報酬をいただいて、もしくは費用対効果を見込む業務として継続的にカスタマイズやプラグインを開発する場合は、プロジェクトルール、kintone独自のノウハウ、成果物の構成、リリース条件をプロジェクト間で一貫させる必要があります。

AIバイブコーディング時代は、これらをAIが再現性高く実現できるようにするため、ルールやスキルとして定義し、開発を始めるたびに同じ状態で読ませる必要があります。

森田ユウゴ

そのスキルのバージョン管理は？プロジェクト間の管理は？

そこで、私のローカル環境では、kintoneプラグイン開発の初期化、AI向け知識の同期、Vite / TypeScriptビルド、packまでを一つのワークフローとして固定するNode.js / TypeScript製のグローバルCLIを作りました。

この記事では、この仕組みを「kintoneプラグイン開発ワークフローCLI」と呼び、実コマンド名kin-devplugintoolはコマンド例の中でだけ扱います。

この記事で紹介するのは、kintoneプラグインの一般的な作り方ではありません。

あくまで、試作を含めると100個以上毎日バイブコーディングを続ける中で見えてきた「開発環境とAI向けルールを、次のプロジェクトへどう引き継ぐか」という課題に対して、私がどのようにワークフローを組んだのかのご紹介です。

森田ユウゴ

台湾で「面倒解決エンジニア」として活動している森田ユウゴです！

「面倒くさい！」を原動力に、kintoneカスタマイズやChrome拡張機能開発などを通して、日常や業務の課題をテクノロジーで解決することに注力しています。

• 2025年12月 kintone認定 アプリデザインスペシャリスト取得
• 2026年01月 kintone認定 カスタマイズスペシャリスト取得

ココナラやクラウドワークスなどでご相談いただけます！
下記のお問い合わせフォームからお気軽にご相談ください▼

森田ユウゴへお問い合わせ(Google Formに移動します)

kintoneプラグインを量産して見えた、毎回の判断と移植の課題

私は「100個近くのkintoneプラグインを毎日バイブコーディングする」という特殊な状況下にありました。

1つ1つは小さな作業、小さなAIへの指示ですが毎日繰り返すと下記の点が気になるようになってきました。

中でも一番大きかったのが、AIエージェント向けの知識移植です。

• 例1. alert()へ逃げず、用途に応じてkintone JavaScript APIのkintone.showNotification()やkintone.createDialog()を使う
• 例2. 1秒以上かかる非同期処理ではkintone.showLoading()を使う
• 例3. プラグイン設定画面には、設定保存とキャンセルの処理を最初から用意する

これは何も前提を渡していないAIが失敗しがちな実装例です。このようなアンチパターン以外にも、新しく得たノウハウを、すでに作った約100個のプロジェクトへ手作業で反映するのは現実的ではありません。

ユーザープロファイル領域（そのPCの利用者ごとの設定置き場で、全プロジェクトに影響します）に全体スキルとして置く方法もありますが、kintone以外でもAIエージェントを活用している私にとって、関係のない情報は全体スキルとして残したくありません。

さらに、Claude CodeやCodexどちらか単一のAIエージェントだけでなら話は早いですが、私はさらにCursorやAntigravityも使うので、それぞれ所定の形式で配置が必要です。

そこで、共通のルールとスキルは一つの正本でバージョン管理し、各プロジェクトへプログラム経由で配布する形にしました。

Node.js製CLIで固定したkintoneプラグイン開発フロー

この課題に対して作ったのが、Node.js上で動くTypeScript製のグローバルCLIです。

任意の空フォルダから開発を始められるようにし、Vite、TypeScript、cli-kintoneなど、ビルドに必要な依存関係はCLI側に持たせています。

各プラグインのフォルダへ毎回node_modulesを置くのではなく、開発ワークフローそのものをグローバルCLIへ寄せる設計です。

開発は次の4ステップで進める

実際に下記の動画では簡単な操作イメージをご紹介しています。

以降では、このCLIツールの中身やこだわりをもう少し解説します。

公式cli-kintoneとの役割分担

このNode.js製CLIは、公式の開発ツールであるcli-kintoneの代わりになるものではありません。むしろ、プラグインの初期化やpack、uploadといった基礎部分ではcli-kintoneに依存しています。

サイボウズの公式情報では、2026年2月8日からcli-kintoneにプラグイン関連コマンドが統合され、plugin info、plugin init、plugin keygen、plugin pack、plugin uploadなどが提供されています。

公式cli-kintone plugin initでは、JavaScriptとTypeScriptのテンプレートを選べます。

公式CLIがプラグイン開発に必要な基本操作を担当し、その前後にあるVite / TypeScriptのビルド、AI向け資産の管理、開発環境と本番環境の工程分離を自作CLIで束ねる関係です。

空のフォルダを同じ開発環境へ初期化する

新しいプラグイン開発を始めるときは、空のフォルダで次のコマンドを実行します。

cd <任意の空フォルダ>
kin-devplugintool init codex

init codexでは、プラグインの雛形、設定ファイル、署名用の秘密鍵に加え、Codex向けのルール、スキル、エージェント定義をまとめて配置します。

ここで重要なのは「ファイルをたくさん作ること」ではなく、どのプラグインも同じ開始地点に立てることです。初期化が終わったら、プロジェクト固有の接続情報を.envへ設定し、要件定義・設計・実装へ進みます。

秘密情報を除いて、生成後の構成を簡略化すると次のようになります。

<project>/
├─ plugin/
├─ src/
│  ├─ config.ts
│  ├─ desktop.ts
│  ├─ i18n/
│  └─ types/
├─ .agents/
├─ .codex/
└─ AGENTS.md

src/desktop.tsには、型付きでkintoneイベント処理を書き始めるための雛形も生成されます。例外処理を省略して抜粋すると、次のような形です。

interface DetailShowEvent {
  record: kintone.types.SavedFields;
}

kintone.events.on('app.record.detail.show', (event: DetailShowEvent) => {
  // TODO: レコード詳細画面の処理を実装する。
  return event;
});

これはCLI本体のソースコードではなく、init codexで新しいプロジェクトへ配置される生成物です。型定義、設定画面、多言語メッセージの置き場所までそろえ、AIが毎回ゼロから構成を決めないようにしています。

同様にinit claudeやinit cursor、そして全てまとめるinit allなども用意しています。

Codex・Claude Code・Cursorの知識を一つの正本から同期する

冒頭の「スキルのバージョン管理はどうするのか」という問いに対する私の答えは、共通資産とプロジェクト固有資産を分けることです。

kintoneプラグインに共通する注意点、開発手順、AIエージェントの役割は、CLI側の正本で管理します。新しいプロジェクトにはinit codexやinit claudeなどで配置し、正本を改善したあとは次のコマンドで既存プロジェクトへ反映します。

kin-devplugintool update

一方で、すべてを上書きすると、各プラグインで積み上げた要件やローカル設定まで消してしまいます。そのため、今回の実測では共通資産87ファイルを更新しながら、プロジェクト側で保持すべきproject-localスキル（プロジェクト固有のスキルを登録する置き場）、AGENTS.md、CLAUDE.md、settings.local.jsonは残しています。

共通ルールを正本から配り、個別の要件はプロジェクト側に残す。この境界を決めたことで、Codexだけ更新されてClaude Codeの注意事項が古い、といったAI間のずれを減らせるようになりました。

これはAIに全部任せるための仕組みではありません。AIがコードを書く前に、人間が決めた前提、禁止事項、確認手順を同じ状態で読ませるための仕組みです。

initからbuild・packまでの実測結果

今回、単一のWindows環境で、初期化からpackまでを実測しました。対象はローカルの検証用フォルダ配下だけで、親フォルダや兄弟フォルダは調査対象にしていません。

処理時間そのものは、主にファイルコピーやコンパイルの結果なので、実行環境によって変わります。

AIエージェントにその都度判断させながら初期化する場合との比較は計測していませんが、体感としてはCLIで固定した初期化のほうがはるかに速く終わります。むしろ、AIエージェントにpackやdevdeployまで実行してもらうように私はスキルに定義しています。

dev・devdeploy・deployを分けて本番反映を雑にしない

先ほど出てきた「devdeploy」は、開発環境向けのデプロイコマンドです。

#kintone100日チャレンジは私個人のプロジェクトであり、顧客納品物は含みませんが、今後の本格的な開発に向けて開発・本番を分けられるようにしました。

# Viteのwatchビルド。ローカルで実装を続けるための入口
kin-devplugintool dev

# 型チェック、build、pack、uploadをまとめた開発環境向けの反映
kin-devplugintool devdeploy

# 難読化を含む本番リリース用の反映
kin-devplugintool deploy

AIエージェントにコマンドを実行させる場合でも、実行前に人が対象環境、権限、差分、戻し方を確認します。コマンドを分けた目的は判断をなくすことではなく、影響範囲の違う操作を同じ名前で実行しないためです。

CLIで固定できる工程と、人が判断する工程

ここまで紹介したCLIで固定できるのは、毎回同じ手順で再現したい工程です。一方、業務上の判断までCLIへ任せることはできません。

CLIで反復作業を固定しても、プラグインが本当に必要か、業務で安全に使えるかという判断は残ります。だからこそ、試作へ進む前に業務課題と正式運用の条件を整理します。

試作前に業務課題と正式運用条件を整理する

kintoneプラグインは、小さな不便を解決する試作から始められます。ただし、実際の業務で使うなら、コードを書く前に対象アプリ、利用者の権限、例外時の動き、運用担当者、障害時の戻し方まで整理する必要があります。

私が提供しているプラグイン試作サービスは、「標準機能で解決できるか」「プラグインにするべきか」から整理し、正式運用へ進む前に必要な範囲だけを小さく試したい方を対象にしています。対象アプリ、利用者の権限、例外時の動き、保守方法まで確認して試作範囲を決めます。

AIを使った開発でも、この順番は変わりません。今回紹介したCLIも、判断を省略する道具ではなく、判断した内容を次のプロジェクトでも守りやすくするための開発環境です。

すでにあるkintone環境の確認、小さな修正、JavaScriptやプラグインの調査、運用相談を依頼したい方には、時間単位のkintoneサポートを用意しています。

kintone APIを画面遷移なしで試すために作ったChrome拡張機能については、KinDevSTの開発記事で紹介しています。私の経歴や対応領域はプロフィールをご確認ください。

あわせて、#kintone100日チャレンジ「100 Days of kintone Hacks」の始動記事と、ココナラでのkintone導入・運用相談サービスの紹介記事もご覧ください。

参考情報

• サイボウズ: 2026年2月8日 開発者向けコマンドラインツールの統合と移行のお知らせ
  https://cybozu.dev/ja/kintone/news/api-updates/2026-02-cli-kintone/
• cli-kintone: plugin init
  https://cli.kintone.dev/ja/guide/commands/plugin-init/

森田ユウゴ(Yugo Morita)

面倒解決エンジニア

XYouTubeContact

専門学校卒業後、新卒で大手ITベンダーに入社して約10年勤務、フルタイムで働きながら通信制大学を卒業。その後1年XR/メタバース関連企業で挑戦後、台湾のIT企業でプリセールスエンジニア(產品專員)として2年勤務。現在はフリーランスエンジニアとして、日本のお客様を中心にフルリモート(台湾から時差-1時間)でサービス提供。 kintone認定 アプリデザインスペシャリスト(2025), kintone認定 カスタマイズスペシャリスト(2026)を保持し、kintone開発に携わっています。プロダクトの価値を伸ばすカスタマイズの提案と実装が得意領域。AnkiカスタマイズやChromeアドオン開発にも熱中しています。尽きない好奇心とインフラ経験、AIであなたの「不便」を解決へ導きます。