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 モードを使って、トークン消費を抑えながら長期間のコンテキストを維持した対話ができるため、複雑な要件定義の壁打ち相手としても非常に優秀です。
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運用で「負債」を生まないための実践チェックリスト
Claude Codeで設計を自動化・管理する際、エンジニアがkintone特有の制約を失念していると、後からAPI連携でエラーを頻発させることになります。設計レビュー時にAGENTS.mdへ組み込むべき、最低限のチェックリストをまとめました。
API連携とデータ集計を見据えた設計上の「落とし穴」
- フィールドコードの重複不可: 同一アプリ内でフィールドコードは一意である必要がありますが、テーブル（Subtable）内のフィールドコード管理は特にClaude Codeに見落とされやすいため注意が必要です。
- システム優先の予約語:
$id,$revision,作成日時などのシステム予約語はフィールドコードとして指定できません。 - 型変更の不可: 一度kintoneに作成したフィールドは、後から型（数値から文字列など）を変更できません。Claude Codeに生成させた
schema.mdの型定義が、将来の拡張性に耐えうるか要確認です。
外部システム連携におけるフィールドコードの重要性
kintoneを単体で完結させず、他のSaaSやデータベースと連携させる場合、フィールドコードの設計が開発コストに直結します。特に広告データや会計データの統合を行う際、以下の設計思想を推奨します。
| 連携ターゲット | 推奨される設計アプローチ | Claude Codeへの指示例 |
|---|---|---|
| BigQuery / BIツール | 物理名と論理名の完全一致。snake_caseを採用し、型を厳格に指定。 | 「BigQueryのスキーマと互換性のあるフィールドコードを設定して」 |
| 会計ソフト（freee等） | 勘定科目や部門コードを「文字列」として保持。自動計算による誤差を排除。 | 「freeeの仕訳インポート形式に準拠した列定義を作成して」 |
| LINE / CRM | ユーザー識別子（UID）をルックアップのキーとして設計。 | 「LINEログインのID連携を想定し、uidフィールドをインデックス対象にして」 |
公式ドキュメントと推奨リソース
Claude Codeに最新の仕様を学習・反映させるため、以下の公式リファレンスをコンテキストに含める、または参照させることを推奨します。
また、kintoneと他のSaaSを高度に連携させ、データ基盤として活用するアーキテクチャについては、以下の記事も非常に参考になります。ツール単体の設計を超えた「データの流れ」を理解することで、Claude Codeへの指示精度はさらに高まるはずです。
ご相談・お問い合わせ
本記事の内容を自社の状況に当てはめたい場合や、導入・運用の設計を一緒に整理したい場合は、当社までお気軽にご相談ください。担当より折り返しご連絡いたします。