Claude Code × kintone｜アプリ設計のたたき台とフィールド命名のレビュー
目次 クリックで開く
ビジネス現場のノーコードツールとして圧倒的なシェアを誇る kintone。しかし、その「作りやすさ」ゆえに、現場ごとにバラバラな命名規則や、場当たり的なアプリ設計が横行し、後のデータ連携やメンテナンスで「負債」となるケースが絶えません。
この課題を劇的に解決するのが、Anthropic がリリースしたコーディングエージェント Claude Code です。本記事では、kintone のアプリ設計を「GUI 上の孤独な作業」から、「Claude Code を活用したリポジトリ駆動の設計・レビュー運用」へと昇華させる具体的な手法を解説します。
Claude Code × kintone：なぜリポジトリで設計を管理すべきか
通常、kintone のアプリ設計はブラウザ上の設定画面で行われます。しかし、この運用には「変更履歴が追えない」「命名規則の強制力が弱い」「設計意図が残らない」という欠点があります。
Claude Code を導入し、ローカルのリポジトリ上で設計ドキュメント（Markdown）やスキーマ（JSON）を管理することで、以下のようなエンジニアリングのベストプラクティスを kintone に持ち込むことができます。
- 設計の自動生成: 要件を伝えるだけで、適切なフィールドコードと型が定義された設計書を Claude Code が書き上げる。
- 静的解析的レビュー: 「フィールドコードが日本語になっている」「命名規則に反している」といった問題を、アプリを作る前に Claude Code が指摘する。
- CLAUDE.md による指針の固定: プロジェクト固有の設計ルールを
CLAUDE.mdに記述しておくことで、エージェントが常にルールに沿った提案を行う。
kintone だけでなく、他の SaaS との連携を最適化する視点は、以下の記事で解説しているアーキテクチャ設計の考え方とも共通しています。
【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』
1. Claude Code の初期設定と kintone 設計用リポジトリの構成
まずは、Claude Code が動きやすい環境を整えます。kintone の設計情報を管理するための専用リポジトリを作成し、以下のようなファイル構成にします。
. ├── CLAUDE.md # プロジェクト全体の設計・命名ルールを記述 ├── AGENTS.md # レビュー専用のサブエージェント指示書 ├── apps/ # アプリごとの設計ファイルを格納 │ └── sales_order/ │ ├── schema.md # フィールド一覧・設計書 │ └── mapping.json # 外部システム連携用定義 └── scripts/ # kintone API を叩くための補助スクリプト
CLAUDE.md への設計指針の記述
Claude Code は、カレントディレクトリにある CLAUDE.md を最優先で読み込みます。ここに kintone 特有の命名規則を定義します。
CLAUDE.md の記述例:
– フィールドコードは必ず半角英数字（snake_case）とする。日本語は禁止。
– ルックアップフィールドのコードは ref_ で始める。
– 計算式フィールドは calc_ で始める。
– 日付フィールドは _at または _date で終わる命名とする。
これにより、claude コマンドを実行した際、エージェントは常にこのルールを遵守した設計案を出力するようになります。
2. 実践：Claude Code による「アプリ設計のたたき台」生成
例えば、「請求管理アプリを作りたい」という要件に対し、Claude Code に次のように指示します。
コマンド実行例:
claude "新規アプリ 'invoice_management' の設計案を apps/ に作成して。取引先名、請求金額、支払期限、ステータスが必要。命名規則は CLAUDE.md に従って。"
Claude Code は、リポジトリ内の既存の設計ファイルを読み取った上で、以下のような Markdown 形式の設計書（たたき台）を生成します。
生成される設計書のイメージ（schema.md）
| フィールド名 | フィールドコード | 型 | 備考 |
|---|---|---|---|
| 取引先（ルックアップ） | ref_customer_id | ルックアップ | 顧客マスタから取得 |
| 請求金額 | total_amount | 数値 | カンマ区切り |
| 支払期限 | due_date | 日付 | |
| ステータス | status | ドロップダウン | 未請求, 請求済, 入金確認済 |
GUI で一つずつフィールドを作成する前に、この段階で Claude Code と対話し、「源泉徴収のフラグも必要」「合計金額は計算式にしよう」といった調整を CLI 上で完結させます。
3. 命名規則レビューと AGENTS.md の活用
既存の kintone アプリが「負債」化している場合、その設定を JSON 形式でエクスポートし、Claude Code にレビューさせることが可能です。
ここで AGENTS.md を活用します。AGENTS.md に「kintone 命名レビュー専門エージェント」の定義を書き込んでおくことで、特定のタスクに特化した思考プロセスを Claude Code に与えられます。
AGENTS.md の設定例
KintoneReviewer あなたは kintone アプリ設計のスペシャリストです。 入力された JSON スキーマを読み取り、以下の観点で修正案をプルリクエスト形式で提示してください。 フィールドコードが日本語になっていないか 重複した意味を持つフィールドがないか データ型（数値・文字列）の選択が適切か
このエージェントを呼び出し、claude "KintoneReviewer として apps/sales_order/current_schema.json をレビューして" と指示することで、人間が見落としがちな命名の不備を即座に摘出できます。これは、大規模なデータ移行（例えば会計ソフトの移行など）におけるデータマッピングの整合性チェックにも応用できる手法です。
【完全版】勘定奉行からfreee会計への移行ガイド：機能・費用比較とデータ移行手順の実務
4. ツール選定の基準：kintone をどこまで使うか
Claude Code を使って設計を高度化しても、kintone 自体の限界（複雑なリレーションや大量データ処理の重さ）は存在します。実務担当者は、kintone を「入力インターフェース」として使うのか、「データウェアハウス」として使うのかを見極める必要があります。
| ツール | 得意なこと | Claude Code との相性 | 設計上の注意点 |
|---|---|---|---|
| kintone | 現場の入力、簡易ワークフロー | ◎ (スキーマ管理に最適) | フィールドコードの共通化が鍵 |
| AppSheet | モバイル操作、オフライン利用 | ○ (定義ファイルの自動生成) | Spreadsheetの構造に依存 |
| BigQuery | 大量データの分析、集計 | ◎ (SQL生成、DML管理) | kintoneからのETL設計が必要 |
特に、Excel からの脱却を目指す際には、kintone だけでなく Google Workspace との組み合わせも検討すべきです。詳細は以下のガイドが参考になります。
Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド
5. 非エンジニアとの役割分担：プルリクエスト運用の導入
Claude Code を使う最大の利点は、非エンジニア（現場担当者）とエンジニアの橋渡しができる点にあります。
運用のステップ
- 現場担当者: Claude Code に「こんなアプリが欲しい」と自然言語で伝える。
- Claude Code: 設計 Markdown を生成し、Git のブランチを作成、プルリクエスト（PR）を投げる。
- エンジニア: PR 上で設計（命名規則やデータ構造）を確認。不備があれば Claude Code に修正を指示するか、直接コメントする。
- 承認・反映: レビューが完了した設計をもとに、kintone アプリを作成（または設定変更）する。
この「承認フロー」を挟むことで、kintone が野良アプリの温床になるのを防ぎつつ、開発スピードを維持できます。Claude Code は /compact モードを使って、トークン消費を抑えながら長期間のコンテキストを維持した対話ができるため、複雑な要件定義の壁打ち相手としても非常に優秀です。
kintoneアプリ設計フェーズ別 × Claude Codeへの指示パターン × CLAUDE.mdに定義すべき項目 早見表
前のセクションで非エンジニアとのプルリクエスト運用を説明しましたが、kintoneアプリの設計はフェーズ（要件定義→フィールド設計→一覧・フォーム設計→自動化設計→権限設計）によってClaude Codeへの指示の粒度と、CLAUDE.mdに事前定義しておくべき情報の種類が異なります。フェーズごとに「Claude Codeに何を任せて何を人間がレビューするか」を整理することで、kintoneアプリの設計品質が上がります。
| kintoneアプリ設計フェーズ | Claude Codeへの効果的な指示パターン | CLAUDE.mdに定義しておくべき項目 | 人間がレビュー・判断すべき設計ポイント |
|---|---|---|---|
| 要件定義フェーズ （業務課題の整理・アプリ設計方針の確定） |
業務担当者からのヒアリング内容（自由記述・箇条書き）をClaude Codeに渡して「kintoneアプリとして実装可能な要件のリスト」と「kintoneでは対応困難な要件（→外部連携が必要）」の仕分けを生成させる。kintoneの標準機能範囲（ルックアップ・計算式・プロセス管理・Webhook）の説明をCLAUDE.mdに記載してClaude Codeが現実的な実装可否を判断できる状態にする | CLAUDE.mdへの記載：「kintoneの標準機能一覧と制約（1アプリあたりのフィールド数上限・計算式の制約・ルックアップの件数上限）」「自社で使用中のkintoneのプラン（スタンダード/プレミアム）と利用可能な機能」「外部連携済みのツール（kintone APIで接続しているシステム名・用途）」 | ①ステークホルダーの要件の優先度判断（すべて実装するか段階的に実装するかはビジネス判断）②「kintoneの制約のために要件を妥協するか、外部システムで補完するか」のコスト・工数判断③既存の他kintoneアプリとの連携方針（ルックアップで参照するか、kintoneピンポイントで連携するか）の設計判断 |
| フィールド設計フェーズ （フィールド種別・名称・計算式の定義） |
要件定義書または業務フローをインプットとして「kintoneのフィールド設計書（フィールド名・フィールドタイプ・計算式・バリデーション）」の下書きをClaude Codeに生成させる。既存のExcelやAccessのデータ構造をインプットとして「kintoneに適したフィールド設計への変換案」を生成させる使い方も有効で、DBエンジニア不在でのアプリ設計の品質を高める | CLAUDE.mdへの記載：「命名規則（フィールドコードの命名パターン：snake_case必須、日本語フィールド名との対応ルール）」「必須フィールドの定義基準（どの条件を満たすフィールドを必須にするか）」「計算式フィールドで使用禁止の関数（パフォーマンス問題が出る関数等）」「文字列フィールドの文字数上限の設計ポリシー」 | ①個人情報・機密情報を含むフィールドの特定と暗号化・アクセス制限の要否判断②フィールドの削除・名称変更が後から発生した場合の影響範囲（他アプリのルックアップ・外部API連携が壊れるリスク）の評価③フィールドの計算ロジックが業務ルールと一致しているかの確認（特に税計算・期間計算の端数処理） |
| 一覧・フォーム設計フェーズ （ビュー設計・フォームレイアウト・通知設定） |
「このアプリを使う担当者の業務フロー」の説明をインプットとして、Claude Codeに「一覧ビューの条件・並び順」「フォームのフィールド配置順序」「通知・リマインダーの設定方針」の設計案を生成させる。kintoneのカスタマイズ（JavaScriptカスタマイズ）が必要な要件が出た場合は「標準機能の範囲内で代替できないか」を最初にClaude Codeに問い直す設計判断フローを設ける | CLAUDE.mdへの記載：「主要なユーザーロール（管理者・一般担当者・閲覧専用）とそれぞれのビューアクセス権限の方針」「モバイル利用者がいる場合のフォームデザイン上の制約（入力フィールド数を最小化する等）」「通知先の組織構造（部門・グループ）とkintoneのグループ設定との対応」 | ①ビューのフィルタ条件が業務上の「見るべき情報」と「見せてはいけない情報」を正しく分離できているかの確認②フォームのレイアウトが業務上の入力順序（画面の上から下に向かって業務の流れ通りに入力できるか）と一致しているかの検証③通知設定の「通知頻度」が現場担当者にとって過剰でないかの確認 |
| 自動化・権限設計フェーズ （プロセス管理・Webhook・アクセス権限） |
「このアプリのプロセス管理（承認フロー）の設計書」または「kintone Webhookで連携したい外部システムの仕様」をインプットとして、Claude Codeにプロセス管理の設定方針とWebhookのエンドポイント設計の下書きを生成させる。権限設計については「ロール別のアプリ・レコード・フィールドの閲覧・編集可否マトリクス」の生成をClaude Codeに依頼することで、権限設計の漏れを防ぐ | CLAUDE.mdへの記載：「プロセス管理の承認ルール（誰が承認者か・条件分岐の基準）」「Webhook連携先のシステム名とエンドポイントURL（変数で管理）」「権限設計の基本方針（最小権限原則・部門間の情報遮断ルール）」「APIトークンの管理方針（誰が発行・更新するか・有効期限ルール）」 | ①プロセス管理の承認者設定が実際の決裁権限（組織規程）と一致しているかの確認（Claude Codeは組織の決裁ルールを知らない）②権限設計で「漏れている権限（アクセスできるべきなのにできない設定）」と「過剰権限（見せたくないのに見えてしまう設定）」の両方を実際のkintone環境でテストして確認③Webhookの送信先が外部システムの場合のセキュリティ（送信先のURL・認証方式の妥当性確認） |
この表でkintone×Claude Codeによるアプリ設計において最重要の設計判断が「各フェーズの設計結果をClaude Codeが生成した『たたき台』として扱い、ビジネスルール・組織権限・セキュリティの観点から人間が必ずレビューして最終承認する責任を明確に持つこと」です。Claude Codeは命名規則・フィールド設計・プロセス管理の構造化には優れていますが、「自社の業務ルール」「組織の決裁権限」「コンプライアンス要件」はCLAUDE.mdに記載しない限り参照できません。Claude Codeを「設計の下書き生成ツール」として位置づけて、最終設計の品質責任を人間が持つ役割分担を明確にすることが、kintoneアプリ開発の持続的な品質保証の条件です。
6. 注意点：セキュリティと API の制約
Claude Code を実務で活用する際、以下の 2 点には特に注意してください。
1. API 認証情報の取り扱い
Claude Code に kintone への自動反映（API 経由のアプリ作成）をさせる場合、API トークンが必要です。これらは .env ファイルに記述し、.gitignore で確実に除外してください。Claude Code が誤ってトークンをプロンプトに含めたり、外部に送信したりしないよう、CLAUDE.md に「認証情報を出力しないこと」と明記しておくのが安全です。
2. 承認（Approval）プロセスの設定
デフォルトでは、Claude Code はファイルの読み書きやコマンド実行のたびにユーザーの許可を求めます。これを --auto-approve で無効化しすぎると、予期せぬ設計の書き換えが発生する恐れがあります。特に設計の根幹に関わる CLAUDE.md の変更については、必ず手動で確認する運用を徹底してください。
まとめ：Claude Code で「進化し続ける」kintone アプリを
kintone アプリは作って終わりではありません。業務の変化に合わせて常にフィールドは増減し、設計は形骸化していきます。Claude Code をリポジトリの伴走者として迎えることで、「常にドキュメントが最新であり、命名規則が守られ、誰でもメンテナンス可能な kintone 環境」が手に入ります。
まずは小さなアプリの設計レビューから、Claude Code の CLI を叩いてみてください。GUI だけでは見えなかった、整然としたデータ構造の美しさに気づくはずです。
参考リンク:
Claude Code 公式ドキュメント（Anthropic）
料金プラン：Claude Code は現在ベータ版（利用には Claude Pro 以上のプランおよび API クレジットが必要な場合があります。詳細は公式ページをご確認ください）。
kintoneのアプリ設計にClaude Codeを活用する際は、APIトークンや顧客マスタへの最小権限アクセス・シークレット管理・承認操作の監査ログを運用ルールとして固めておくことが長期保守の安定につながります。kintone環境に合わせたClaude Code導入設計や段階的なPoC支援は、Claude Code 導入支援にご相談ください。
kintone業務アプリ・プラグイン活用のご相談
kintoneでの業務アプリ設計や、帳票・連携・自動化を補うプラグインの活用を支援します。現場の運用に合わせたアプリ構成や他システムとの連携まで、具体的な形でご提案します。
CRM・営業支援
Salesforce・HubSpot・kintoneの選定から導入・カスタマイズ・定着まで一貫対応。営業生産性を高め、商談化率を改善します。