kintoneプラグイン開発とは｜manifest構成から配布・内製外注の判断まで

kintoneプラグインの開発は、JavaScript・CSS・アイコン・manifest.jsonという少数のファイルを用意し、専用ツールでzipにパッケージングして環境へ読み込む、という定型の工程で進みます。手順自体は1日で一巡できる一方、2026年2月の定期メンテナンスでパッケージングの推奨ツールがplugin-packerからcli-kintoneへ移り、従来ツールは2026年8月の定期メンテナンスで保守終了という案内です。この記事では、開発環境の準備からmanifest.jsonの必須キー、パッケージングと秘密鍵の管理、配布・更新の運用、そして内製と外注をどこで切り替えるかの判断基準までを、cybozu developer networkの一次情報をもとに実装者向けに整理します。

まとめ｜kintoneプラグイン開発の工程と内製・外注を分ける判断の軸

kintoneプラグイン開発の全体像は「必要ファイルの準備 → manifest.json作成 → パッケージング → 環境への読み込み」の4工程に集約されます。必須ファイルはアイコンとmanifest.jsonだけで、PC用・モバイル用のJavaScriptやCSSは目的に応じて足していく構成です。パッケージング時に生成される秘密鍵ファイル（.ppk）がプラグインIDの源になるため、この鍵の管理が更新運用の生命線になります。

ツール選定は時期の見極めが要ります。plugin-packerとcreate-pluginは2026年8月の定期メンテナンスで保守終了と案内されており、これから始めるならcli-kintoneのプラグイン機能を軸に据えるのが安全です。内製か外注かは、単一アプリ向けの軽い拡張なら内製、複数アプリへの横展開・設定画面付きの汎用化・基幹システム連携が絡むなら外注が目安です。以降の章で、各工程の中身と判断条件を具体的に見ていきます。

kintoneプラグイン開発の基本とJavaScriptカスタマイズとの使い分け

kintoneの拡張には、プラグインを組み込む方法とJavaScriptファイルを直接読み込ませるカスタマイズの2系統があります。どちらもコードで機能を足す点は同じですが、配布のしやすさと管理のされ方が別物です。kintone自体の機能や料金体系から検討したい段階なら、親ガイドのkintoneでできること・料金・ノーコードで内製する判断の解説を先に読むと、本記事の実装手順を位置づけやすくなります。

プラグインとJavaScriptカスタマイズの仕組みの違いと選び方の目安

JavaScriptカスタマイズは、アプリの設定画面にJS・CSSファイルを直接アップロードして動かす方式です。手早く動く反面、どのアプリに何を入れたかが属人化しやすく、同じ処理を別アプリで使うにはファイルを都度入れ直すことになります。

プラグインは、同じコードをzipにまとめてkintoneのシステム管理へ登録し、各アプリでは「追加して設定するだけ」で使い回す方式です。APIキーや対象フィールドといった可変値を設定画面に切り出せるため、コードを触れない管理者でも展開できます。両者の違いは次の通りです。

選び方の目安は適用範囲です。2アプリ以上で同じ処理を使う見込みがあるならプラグイン、1アプリ限りならJSカスタマイズで足ります。

プラグイン化の利点が生きる場面と単発カスタマイズで済ませる場面

プラグイン化の利点が生きるのは、部署ごとに似たアプリが増殖している環境です。案件管理・問い合わせ管理・申請管理のように構造が似たアプリへ同じ入力チェックを配るケースでは、設定画面で対象フィールドを選ばせる作りにしておけば、展開のたびにコードを書き換えずに済みます。

逆に、特定アプリの一覧画面にボタンを1つ足すだけ、といった使い捨ての要件までプラグイン化するのは過剰です。設定画面のHTML・保存処理・多言語対応の分だけ実装量が膨らみ、単発要件では回収できません。ここは割り切ってJSカスタマイズで済ませ、2つ目のアプリで同じ要望が出た時点でプラグインへ昇格させる、という二段構えが実務では現実的です。

kintoneプラグイン開発の始め方｜開発環境の準備と必須ファイルの構成

実装に入る前に、検証用のkintone環境とローカルの開発ツールを整えます。本番環境でプラグインの動作検証を行うと、エラー時に業務データへ影響しかねないため、環境の分離を先に済ませるのが定石です。

開発者ライセンスの取得と検証用kintone環境をまず分離する準備手順

検証環境は、cybozu developer networkに登録すると無償で使える開発者ライセンスで用意できます。本番とは別ドメインの環境が発行されるため、書きかけのプラグインを安心して壊せる場所になります。取得から着手までの流れは次の通りです。

1. cybozu developer networkにアカウントを登録する
2. 開発者ライセンスを申請し、検証用のkintone環境を発行する
3. ローカルにNode.jsを導入する（create-pluginの動作要件は14系以上・2026年7月時点）
4. 後述のテンプレート生成ツールで雛形プロジェクトを作る

本番しか環境がない状態で開発を始めると、テスト用アプリやレコードが本番に散らばり、後片付けの手間が検証そのものより大きくなります。環境分離は最初の10分で終わる作業なので、省略しない方が結果的に速く進みます。

create-pluginで生成するテンプレートと必須ファイルの構成

雛形の生成には公式のCLIツールcreate-pluginが使えます。npm install -g @kintone/create-pluginで導入し、create-kintone-pluginコマンドにプロジェクト名を渡すと、対話形式でプラグイン名・モバイル対応の有無などを聞かれ、ひな形一式が生成される流れです。生成物にはsrc配下のJavaScript（desktop用・設定画面用）、設定画面HTML、CSS、アイコン画像、manifest.jsonに加え、秘密鍵のprivate.ppkが含まれます。

ファイルのうち必須はアイコンとmanifest.jsonです。アイコンはPNG・JPG・GIF・BMPのいずれかで用意します。テンプレート生成後はnpm startを打つとファイル変更を検知して自動で再パッケージングされるため、修正→動作確認のループを短く回せます。なおcreate-plugin自体も2026年8月に保守終了と案内されているため、新規案件ではcli-kintoneでの代替を前提に、テンプレート構成の考え方だけを引き継ぐのが無難です。

manifest.jsonの記述とパッケージングからkintoneへの読み込みまで

プラグインの本体は、実装コードそのものより「manifest.jsonに何をどう束ねるか」で決まります。ここを押さえると、パッケージングと読み込みは機械的な作業になります。

manifest.jsonの必須キーとdesktop・mobile・configの指定

manifest.jsonは、プラグインを構成するファイル情報を1つにまとめる設定ファイルです。必須キーは次の5つです。

• manifest_version：1を指定する
• type：APPを指定する
• version：整数またはセマンティック形式（1.0.0など）
• name：言語別オブジェクトで指定し、enが必須
• icon：アイコンファイルのパス

PC画面に読み込むJS・CSSはdesktop、モバイルはmobile、設定画面はconfigキーの配下に配列で列挙します。JS・CSSは各キーにつき30ファイルまで、1ファイルの上限は20MB、設定画面HTMLは64KBまでという制限があるため、外部ライブラリを多数抱き合わせる設計は早めに見直した方が安全です。

plugin-packerとcli-kintoneのパッケージングと秘密鍵の管理

従来のパッケージングはkintone-plugin-packerコマンドにソースディレクトリを渡す方式で、実行するとplugin.zipと、ランダムな文字列名の秘密鍵ファイル（.ppk）が生成されます。2回目以降は既存の.ppkをオプションで指定して同じ鍵で署名し続ける運用です。2026年2月の定期メンテナンスで同等機能がcli-kintoneに追加され、plugin-packerは2026年8月の定期メンテナンスで保守終了と案内されているため、これから組むビルド環境はcli-kintoneのplugin packコマンド系に寄せておくと移行作業を省けます。

この.ppkがプラグインIDの実体です。同じ鍵でパッケージングしたzipは同一プラグインとして認識され、アップロード時に上書き更新できます。逆に鍵を失うと同一プラグインとしての更新経路が絶たれ、別プラグインとして配布し直すほかありません。.ppkはGit管理外の鍵置き場で保管し、ビルドをCIに載せる場合もシークレットとして注入する構成にします。

生成したplugin.zipをkintone環境へ読み込む2つの方法

出来上がったplugin.zipの読み込み口は2つあります。手動なら、kintoneのシステム管理からプラグインの画面を開き、「読み込む」でzipファイルを選択するだけです。読み込んだプラグインは、各アプリの設定画面から追加して有効化します。

開発中はアップロードの回数が多くなるため、コマンドラインからのアップロード（plugin uploadコマンド系）で自動化する方が効率が上がります。ファイル監視の自動パッケージングと組み合わせると、保存のたびに検証環境へ反映されるループが作れます。プラグインファイル全体の上限は100MBで、同じプラグインIDのzipを読み込むと自動で上書きされる仕様のため、検証環境での試行錯誤が本番の登録内容を汚すことはありません。

開発したプラグインの配布・更新と複数プラグイン併用時の運用の注意点

作って終わりではなく、配って更新し続ける段階に運用の落とし穴が集中しています。配布形態と更新経路は、開発着手前に決めておく方が手戻りが少なくなります。

同一プラグインIDによる上書き更新とバージョン番号の付け方の実務

プラグインの更新は「同じ.ppkでパッケージングし直したzipを再アップロードする」だけで完了し、各アプリ側の再設定は原則不要です。この手軽さの裏返しとして、versionキーの運用が雑になりがちです。versionは整数のほかセマンティック形式（1.0.0）が使えるので、設定画面の互換性が壊れる変更でメジャーを上げる、という取り決めを最初に固定しておくと、利用側への告知判断が機械的にできます。

配布先が自社環境だけなら、リポジトリのタグとversionキーを一致させる程度の軽い規約で回ります。他社環境へ配る場合は、どの環境にどの版が入っているかの台帳が要るため、リリースノートを添えて配布する運用まで含めて設計します。

複数プラグイン併用時の競合検証とスタンダードコース以上という前提

公式ドキュメントは、複数のプラグインを同じアプリで使う場合に相互の競合検証を行うよう求めています。プラグイン同士は互いの存在を知らずにDOMやイベントへ介入するため、一覧画面のボタン位置がずれる、片方のイベントハンドラが先勝ちするといった干渉が起こり得ます。既製プラグインと自作を混在させるアプリでは、本番投入前に組み合わせテストを1周挟むのが安全です。

前提条件も見落とされがちです。プラグインとAPI連携が使えるのはスタンダードコース以上で、ライトコースの環境では動かせません。社外配布を視野に入れる場合は、利用ドメインを制限するライセンス管理の仕組みも用意されているため、有償配布や顧客ごとの提供範囲の制御はそちらで設計します。

kintoneプラグイン開発を内製で進める場面と外注へ切り替える場面の判断

ここが本記事の核です。手順自体は公開情報で完結する一方、体制の選択を誤ると保守で行き詰まります。条件付きで言い切ります。

内製で進めてよい条件と社内に残しておく開発ノウハウの範囲の見極め

内製で進めてよいのは、(1)JavaScriptを日常的に書けるメンバーが社内に1人以上いて、(2)対象が自社環境の少数アプリに閉じ、(3)要件が入力チェックや表示調整など画面まわりで完結する場合です。この3条件が揃うなら、テンプレート生成から読み込みまで公式ドキュメントだけで到達でき、外注はコストの面で過剰です。

内製する場合でも、社内に必ず残すべきものが2つあります。.ppkと、manifest.jsonを含むソース一式のリポジトリです。担当者の退職でこの2つが行方不明になると、動いているプラグインはあるのに誰も更新できない、という凍結状態に陥ります。属人化対策は実装スキルの引き継ぎより、この2点の保管場所の明文化が先です。

外注へ切り替える判断基準と委託先に必ず確認する開発・保守の体制

外注へ切り替える基準は明確で、(1)基幹システムや外部SaaSとの連携が絡む、(2)設定画面付きの汎用プラグインとして複数部署・複数環境へ配る、(3)kintone更新への追従を継続的に担保したい、のいずれかに該当する場合です。この領域は設計の失敗が全アプリへ波及するため、片手間の内製で抱えるとかえって高くつきます。要件定義から保守までを引き受けるkintoneプラグイン開発の受託サービスのような専門窓口に、業務要件の整理段階から入ってもらう方が総コストは下がります。

委託時に必ず確認するのは、納品物に.ppkとソースコード一式が含まれるか、そしてkintoneの定期メンテナンス（年数回の仕様変更を含む）への追従が保守契約の範囲かの2点です。zipだけ納品される契約だと、委託先が撤退した時点で更新手段を失います。ここを曖昧にした発注が、プラグイン外注の典型的な失敗パターンです。

よくある質問

kintoneプラグイン開発の着手前に現場で挙がりやすい疑問へ簡潔に答えます。

kintoneプラグイン開発にはどのプログラミング言語が必要ですか？

JavaScriptが中心です。画面の制御はkintoneのJavaScript APIをブラウザ上のJavaScriptから呼び出す形で実装し、見た目の調整にCSS、設定画面にHTMLを使います。サーバーサイドの言語は必須ではありません。TypeScriptで書いてビルド時にJavaScriptへ変換する構成も選べます。

プラグイン開発は無料で試せますか？

試せます。cybozu developer networkに登録すると無償の開発者ライセンスで検証用kintone環境を用意でき、create-pluginやcli-kintoneといった公式ツールも無料で使えます。費用が発生するのは、本番環境の契約と、外注する場合の開発委託費です。

plugin-packerはいつまで使えますか？

2026年8月の定期メンテナンスで保守終了と案内されています（2026年7月時点）。2026年2月の定期メンテナンスで同等のパッケージング機能がcli-kintoneに追加済みのため、新規のビルド環境はcli-kintoneで構築し、既存プロジェクトも移行を予定に入れておくことを推奨します。

開発したプラグインは他のkintone環境にも配布できますか？

配布できます。plugin.zipを渡せば他環境のシステム管理から読み込めます。有償配布や提供範囲の制御が要る場合は、利用ドメインを制限するライセンス管理の仕組みで環境単位の利用可否を設計する形です。配布後の更新は同一の秘密鍵（.ppk）でパッケージングしたzipの差し替えで行います。

ライトコースでもプラグインは使えますか？

使えません。プラグインの追加とAPI連携はスタンダードコース以上の契約が前提です。ライトコースの環境で拡張要件が出てきた場合は、プラグイン開発の前にコース変更の費用対効果から検討する順番になります。

関連記事

• kintoneとは？できること・料金・プラグインからノーコードで内製する判断まで解説：本記事の実装手順の前段として、kintone自体の選定・料金・内製判断を扱う親ガイド
• ノーコードとは？ローコードとの違い・できること・限界を実務目線で解説：コードを書かない拡張の限界と、プラグイン開発のようなコード拡張が要る境界を整理できる