1行もコードを書かずにkintoneプラグインを作れるか？Claude Codeで試してみた

「在庫数が閾値を下回ったら一覧画面で赤字表示したい。」
「承認待ちのレコードを色分けして、ひと目で状況を把握したい。」

こういった要件は、よくある小さな悩みですが、kintoneの標準機能では実現できません。
プラグインがあれば解決できるのに——

「でも、誰が作るの？」という壁にぶつかります。

社内にエンジニアはいないし、開発会社に頼むと数十万円・数ヶ月かかります。
「この程度の要件に外注コストはかけられない」と諦めた経験がある担当者も多いのではないでしょうか。

そこで試してみました。
自分では1行もコードを書かずに、Claude Codeだけでkintoneプラグインをゼロから開発できるのか。
設計書の作成から、実装・ビルド・デバッグまで——
一連の全工程を実験した記録を、包み隠さず公開します。

結論：作れた。ただしClaude Codeへの「任せ方」が全てを決める

先に結論を言うと、希望の要件を満たすプラグインは完成しました。
今回作ったものは、フィールドの値に応じて文字色・背景色・フォントスタイルを変えるプラグインです。

まずは筆者のスペックを共有しておきます。

項目 状況
kintone経験 日常的に設定できる程度
JavaScript 書いたことはあるが、今回の開発で自分が書いたコードは1行もない
プラグイン開発 今回が初めて

Claude Codeに「プラグインを作って」と丸投げすれば済む話ではありませんでした。
「設計書から始める」「planモードで根本原因を特定してから修正する」——

この2つを押さえてからが、本当のスタートです。

なぜkintoneプラグインは「作れない」と思われるのか

標準機能では届かない場面が必ずある

kintoneはノーコードで業務アプリを作れるツールですが、標準機能にはどうしても限界があります。

  • フィールドの値によって表示色を変えたい
  • 特定の条件を満たしたときだけ警告を出したい
  • 一覧画面でステータスを色分けして視覚的に整理したい

これらはプラグインを使えば実現できます。
しかしプラグインはJavaScript・HTML・CSSで書かれたプログラムです。
非エンジニアの担当者には、そもそも手が届かないと思われてきました。

外注するには「小さすぎる」要件がある

開発会社に依頼すると、小さな機能改善でも数十万円・数ヶ月のリードタイムがかかることが多いです。
「在庫数が閾値を下回ったら文字色を赤くしたい」という要件に、それだけのコストと時間を投じるのは現実的ではありません。

結果として、「kintoneでできたらいいのに」が積み重なったまま放置される——
製造現場のkintone担当者にとって、よくある状況です。

Claude Codeとは何か

Claude Codeは、Anthropicが提供するCLIベースのAIコーディングアシスタントです。
ターミナルで動き、ファイルの読み書きやコマンドの実行まで行えます。

通常の生成AIとの違いをまとめると次のとおりです。

比較軸 通常のAIチャット Claude Code
できること コードを提案する コードを書いてファイルに保存する
コマンド実行 できない できる（ビルド・テスト実行など）
ファイル操作 できない できる（複数ファイルを横断して編集）
指示の方法 自然言語でチャット 自然言語でチャット（同じ）

「書いてもらったコードを自分でコピペして貼る」作業がなくなります。
Claude Codeに依頼すれば、ファイルを作り、コードを書き、ビルド・アップロード・テストまで自動実行してくれます。

なお、Claude Codeを使い始める前に確認しておきたいセキュリティ設定については、Claude Codeを使う上で最低限知っておきたいセキュリティ対策にまとめています。

実際にやってみた——正直なレポート

今回作ったプラグインの概要

機能は「kintoneのフィールド値に応じて文字色・背景色・フォントスタイルを変更する」です。
製造現場での使いどころとしては、在庫数が閾値を下回ったら赤字表示、承認待ちレコードを色分けして一覧で即認識できるようにするといった場面で活用できます。

構成は、条件と色を定義する設定画面と、フィールドへ書式を適用する本体画面のMVC設計です。

進め方：Claude Codeへの「任せ方」

開発フローはこの順番で進めました。

graph LR
    A["①要件を日本語で定義"] --> B["②設計書・クラス構成を作らせる"]
    B --> C["③TDDで実装を依頼\n（テスト→実装の順）"]
    C --> D["④ビルド→実機確認\n（Playwright活用）"]
    D --> E{"バグあり？"}
    E -->|"Yes"| F["⑤planモードで\n根本原因を特定"]
    F --> C
    E -->|"No"| G["完成"]

最初に「プラグインを作って」と言わないことが重要でした。
まずは「こういう動きをするkintoneプラグインを作りたい。まず設計書とクラス構成を作って」と依頼します。
Claude Codeが出力した設計書を確認・修正してから、はじめて実装に進みます。

ビルド→アップロード→kintoneでの動作確認というサイクルも、Claude Codeにまとめて回してもらいました。
3つのコマンドを毎回手打ちする手間がなくなり、確認サイクルが大幅に速くなりました。

Claude Codeにこうした繰り返し作業を自走させるための許可設計については、Claude Codeを長時間自走させる方法——許可設計で「止まらないAI開発」を実現するで詳しく解説しています。

うまくいったこと

設計書・実装・ビルドを一貫して依頼できました。
今回のプラグインは設定画面と本体画面で構成されるMVC設計です。
クラス構成・シーケンス図・データモデルまで、Claude Codeが設計書として出力してくれました。
コードの品質も想定以上で、テストコードも含めて一貫して整合性が取れていました。

Playwrightでの実機デバッグが機能しました。
kintoneのプラグイン設定画面はiframeが絡む特殊な構造を持ちます。
通常のブラウザ開発ツールでは取得しにくい情報も多く、PlaywrightのデバッグスクリプトをClaude Codeに書かせて対応しました。

特に有効だったのが「DOMにログを書き出す」手法です。
コンソールログはiframeのコンテキストの違いで取得できないことがあります。
そこでClaude Codeが提案したのが、デバッグ用のDOM要素を作ってログを書き込み、Playwrightで読み出す方法でした。

// ソースコード内に仕込む（デバッグ後は削除）
const dbgEl = document.getElementById('__cf_dbg') || (() => {
  const d = document.createElement('div');
  d.id = '__cf_dbg';
  d.style.display = 'none';
  document.body.appendChild(d);
  return d;
})();
dbgEl.setAttribute('data-log', JSON.stringify(logs));

こういった「環境特有の問題への対処」をClaude Codeが自分で考えて提案してくれたのは想定外でした。

Claude Codeとブラウザ操作を組み合わせてさらに高度な自動化ループを作る方法は、Claude Code × browser-useで「止まらない自動開発ループ」を構築するも参考になります。

ハマったこと（失敗も包み隠さず）

最大の時間ロスはビルドコマンドの混同でした。

kintoneプラグイン開発では、DEV（動作確認用）と本番用でビルドコマンドが異なります。

用途 コマンド 出力先
DEV（動作確認用） npx webpack --config webpack.dev.config.js plugin_dev/js/
本番 npm run build plugin/js/

DEVプラグインで動作確認をしていたにもかかわらず、npm run build（本番用）しか実行していませんでした。
ソースを修正しても plugin_dev/js/ は更新されません。
「直したはずなのに動作が変わらない」という状況が延々と続きました。

Claude Codeに「直して」と指示し続け、Claude Codeも次々と別のアプローチを試みます。
しかしそもそも、DEV用のビルドが実行されていなかっただけでした。

この問題はClaude Codeが解決したのではなく、自分がビルド手順を見直して気づいたことです。
どれだけAIが優秀でも、前提となる環境の確認は人間がやる必要があります。

場当たり的な修正指示が泥沼を作ります。

うまくいかない場面で「とにかく直して」と指示すると、Claude Codeは次々と別のアプローチを試み始めます。
修正→確認→また別の修正——このサイクルで問題が複雑化していきました。

転換点になったのは「planモードで根本原因を特定してから修正して」という指示の仕方です。
planモードでは、Claude Codeが実装の前に「なぜこうなっているのか」「何を直すべきか」の分析を先に出力します。
分析内容を確認してから実装に進む流れにしたことで、的外れな修正が激減しました。

かかったもの（正直な開示）

  • 必要だったITリテラシー：kintone設定が日常的にできる程度（JavaScriptの読み書き能力は不要でした）
  • セットアップ：Node.js環境・kintone Plugin Packer・Claude Codeのインストールが必要（ここはエンジニアに手伝ってもらいました）
  • 工数：設計から動作確認まで合計で数日（DEV/本番ビルドの混同で費やした時間が一番大きかったです）

まとめ：非エンジニアのkintone担当者こそClaude Codeを使うべき理由

向いているケース・向いていないケース

ケース 向き/不向き 理由
要件が明確でkintone API範囲内の機能 向いている 構造が決まっているのでAIが得意
設定画面＋本体画面程度の規模 向いている コンテキスト量が管理しやすい
既存の複雑なプラグインの改修 やや難しい コードの文脈把握に限界がある
外部API連携が複雑なもの 向いていない 仕様の読み込み・認証まわりが煩雑

今日から始める3ステップ

Step 1：Claude Codeをインストールする
npmでインストールし、Anthropicのアカウントと課金設定をします。
初期セットアップはエンジニアに手伝ってもらうのが確実です。

Step 2：作りたい機能を日本語で定義書にまとめる
「どんなときに」「何をしたいか」「どう動いてほしいか」を箇条書きで書きます。
ここが曖昧なままだと、Claude Codeも迷走します。

Step 3：「設計書から作って」と依頼する
「プラグインを作って」ではなく「まず設計書とクラス構成を作って」から始めます。
設計書を確認・修正してから実装へ進む——この順番を守るだけで完成度が大きく変わります。

担当者に求められるものが変わった

コードが書けないことは、もはや障壁ではありません。
Claude Codeがコーディングを担ってくれます。

kintone担当者に求められるのは「何を作りたいか」を定義する力と、「ちゃんと動いているか」を確認する力です。
この2つがあれば、外注せずに小さなカスタマイズを積み重ねていけます。

「もっと複雑な要件で試したい」「自社kintoneへの適用を相談したい」という方は、ぜひアディエムまでご相談ください。

参照元

関連記事