アプリを変更する前に、どこでつながっているかを確認。顧客・案件・請求の例で、関係の種類と向き、調査の5手順、引き継ぎに使える記録ひな形を紹介します。

無料ツールで設定の確認を始める まず1つのアプリ内でフィールドの参照先を調べたい場合は、無料のフィールド使用状況チェッカーから始められます。フィールド使用箇所の確認手順と検出対象で、導入から結果の読み方まで確認してください。「未検出」は削除して安全という意味ではなく、外部連携や実際の業務での使用は別途確認します。 対象フィールドが承認フローで使われている場合は、プロセス管理の実行条件と作業者の確認ガイドも役立ちます。変更前の条件を記録してから、変更後の操作をテストしましょう。 「この項目、最近は誰も入力していないし、消してもよさそう。」 ​ kintoneのアプリを整理するとき、使われていないように見えるフィールドが気になることがあります。ただ、画面で目立たない項目でも、月末の集計や外部サービスへの連携に使われているかもしれません。 ​ 変更前に確かめたいのは、入力されているかだけでなく、どこから参照され、何の業務を支えているかです。今回は、フィールドの削除や変更を検討するときの確認ポイントを整理します。 ​ 1．まず「何を変えるのか」を分ける.

「アプリの一覧と操作マニュアルは渡した。でも、後任からの質問が止まらない。」 ​ kintoneの引き継ぎを考えるとき、こんな場面を想像してみてください。入力方法は分かっても、「この項目は変更してよいのか」「エラーが出たら誰に相談するのか」が分からなければ、日々の運用で手が止まってしまいます。 ​ 引き継ぎで残したいのは、操作手順に加えて、業務の目的、設定の理由、困ったときの確認先です。この記事では、後任が運用を続けるために整理しておきたい情報を6つにまとめます。 ​ 1．何のために、誰が使うアプリなのか ​ ​ まずは、アプリの名前とURLに「業務の説明」を添えましょう。アプリ名だけでは、使われ方や重要度までは伝わりません。 ​ アプリ名・URL・アプリID 目的と対象業務 利用する部署・担当者、業務上の責任者 使うタイミングと、止まると困る業務 設定を管理する人と問い合わせ先 例えば「案件管理」だけでなく、「営業担当が商談後に更新し、営業責任者が毎週月曜の会議で受注見込みを確認する」と書くと、利用場面が具体的になります。 ​...

はじめに kintoneのプロセス管理で「計算実行」や「請求書作成」などのアクションを起点に、 ExcelテンプレートからExcel/PDFを出力し 添付としてレコードに反映し 添付Excelを解析して計算結果をkintoneへ書き戻し 最後にステータスを更新して完了通知 までを一連で自動化したいケースがあります。 この記事では、実運用で採用したフロー（①〜⑩）を、チーム共有／再現可能な形で整理します。 対象：サービス請求書（例） 数量・単価などはkintoneの入力値 金額・税額・合計などの計算はExcel側 顧客提示はPDF kintoneは計算結果と成果物（Excel/PDF）を保持する kintoneフィールド構成 請求書テンプレート（Excel） 実運用フロー（①〜⑩） ① プロセス管理のアクションを実行 ユーザーはkintone上でプロセス管理アクション（例：計算実行）を押す。 ここが自動処理の起点。 ② Excelテンプレートを取得 レコードの「テンプレート」ファイル（FILE）を参照し、出力の元となるExcelテンプレートを取得す

kintoneのアプリが増えると、「誰が管理しているのか」「今も業務で使っているのか」が分からないアプリが残ることがあります。この記事では、管理責任者や用途を確認できないアプリを「野良アプリ」と呼びます。 ​ AppInsightのアプリ一覧や更新情報、ER図を手がかりに、確認が必要なアプリを絞り込む方法を紹介します。目的は、担当者・用途・依存関係を確認し、継続利用や引き継ぎ、整理の方針を決めることです。 ​ ① アプリ一覧を取得 まずはAppInsightで取得できるアプリの一覧を確認します。棚卸しの対象範囲と取得日を記録し、対象に含まれていないアプリがないか、権限や取得条件も確認しましょう。 ​ ② 作成者情報から管理担当者を確認する アプリ作成者の情報が空欄の場合は、現在の管理担当者を確認するきっかけにします。 ​ 「アプリ作成者」フィールドだけで、管理者不在と断定しないようにしましょう。空欄の理由や情報の取得条件も確認します。 ​ 作成者が退職・異動していても、後任が管理を引き継いでいる場合があります。 ​ 現在の業務責任者と設定管理者が

はじめに Mermaid はとても便利な記法です。テキストで図が書けて、構造も分かりやすい。 一方で、業務で使っているとこんな場面に出会います。 図は描けたけど、会議で拡大すると文字が潰れる 全体を俯瞰したいのに、スクロールと拡大を繰り返すことになる 「ちょっとここ見せて」と言われた瞬間に詰まる 「描画できる」ことと「会議で使える」ことは別なんだな、というのを痛感しました。 背景：Notion での運用が限界だった 当初は、Mermaid コードを Notion で管理していました。 コード管理はしやすい 図も表示できる ただし、会議で使うと問題が顕在化します。 拡大すると文字・線が潰れる 全体像を見せたいのに解像度が足りない 「どこを見ているか」が共有しづらい 拡大・移動自体は可能でも、解像度と操作感が会議用途に耐えないと、結果的に使われなくなるという点が一番の課題でした。 mermaid.js 本来の思想に立ち返る mermaid.js 自体は、 SVG ベース 拡大縮小前提 劣化しないことが前提の設計 という思想を持っています。 つまり、

kintoneは誰でもアプリを作れるのが魅力ですが、その「アプリの単位」は企業ごとに大きく異なります。 ある会社では「契約管理」のように業務全体をカバーするアプリ、別の会社では「製本依頼」のように作業に特化したアプリ、といった具合です。 業務フォーカス型（基幹型） 契約管理、案件管理、請求管理など、業務全体を担うアプリ。 台帳としての役割を持ち、会社の資産データを集約する。 強み：全体を俯瞰できる、一元管理しやすい 弱み：スコープが広くなり、複雑化しやすい 作業フォーカス型（タスク型） 製本依頼、承認申請、検収など、個別の作業に特化したアプリ。 業務の一部の動きを切り出すイメージ。 強み：シンプルで運用しやすい、分業に向く 弱み：点在しやすく、全体像を把握しづらい 混在するのが現実 多くの企業では業務型と作業型が混在しています。 ただし「業務型アプリを綺麗に回す」のは難易度が高く、例外対応や権限分岐が増えて複雑になりがち。 そのため、台帳（業務型）はシンプルに保ち、作業は別アプリに切り出して連携させると運用しやすくなります。 ベンダーごとのアプリ

「テーブル定義書がない」から始まった ある日、古い販売管理システムを kintone にリプレイス案件をすることになりました。 ところが開発元はすでに存在せず、残っていたのはデータベースのテーブルだけ。 KOKNM, DENNO, URIKIN, ZEIKN01 …。 見るからに何かの略語ではありますが、設計書もコメントもないため、何を意味するのか確信が持てない。 唯一の手がかりは「命名のクセ」だけでした。 なんとなく分かる。でも“全部調べる”のは非効率… たとえば: KOKNM → 顧客名（KOK＝顧客？） ZEIKIN → 税金？ DENNO → 伝票No. CRTDT → 作成日（Create Date？） こうやって一つずつ推測していけば意味は分かる。でもテーブルが十数個、項目が数百もあるとなると、画面と見比べながら一人で手作業で調べるのは現実的じゃない。 しかも略語は統一されているようで、微妙に揺れています。 ZEIKIN と ZEIKN の両方がある UPDDT と UPDTDT が混在 KOKNM が2回出てくる（カナ名と漢字名？

こんにちは、こん太ぱぱです。 不動産会社でのkintone開発事例をご紹介します。 営業の現場はずっと「Excel＋声掛け＋紙の回覧」という“紙リレー”で動いていて、申込→承認→準備→契約のどこかで情報が散らばり、手戻りが起きがちでした。 しかも不動産は多筆・別紙・特約など情報量が多く、フォームを欲張ると入力UIが重くなる ——ここが最大のネックでした。 そこで僕は、Excelを捨てずに役割を変えるというやり方を取りました。 運用の“母艦”はkintoneに集約して、依頼で動き（アクション）／状態で迷わない（ステータス）。 そして帳票はExcelのまま出力専用にして、ドラフト先行＋kintoneからの自動差し込みで最終化。 結果、現場のスピードは落とさずに“紙リレー”から卒業できました。 設計原則：依頼をすると、業務が次の状態になる 僕の設計は、「依頼」が発火点になって業務の“状態”が進むという考え方です。だからこそ、ボールを渡す瞬間を「アクション＝依頼」と「ステータス＝状態」のセットで明示しました。 だれが → だれに → なにを依頼するか 完

kintoneで別アプリのサブテーブル明細を確認したいときは、明細をリッチエディタに要約して表示する方法があります。一方、履歴を別アプリのレコードとして管理しているなら、関連レコード ネスト表示で親子関係を展開する方法が使えます。 この2つはデータの持ち方が異なります。この記事では選び方と注意点を整理し、後半で撮影用の架空データによる実機例を紹介します。 サブテーブルの明細を要約して見せる方法 標準の関連レコード一覧にサブテーブルの行をそのまま並べる代わりに、元アプリへリッチエディタの「明細サマリー」を設けます。レコード保存時のJavaScriptで明細をHTML表へ整形し、関連レコード一覧の表示項目にサマリーを追加する考え方です。 表示しているのはサブテーブル本体ではなく、明細から作成した要約です。実装にはフィールドコードに合わせたJavaScriptのカスタマイズが必要で、フィールドを置くだけでは自動生成されません。 設定の流れと確認ポイント 元アプリに、明細を入力するサブテーブルと、要約を保存するリッチエディタを用意します。...

この記事は2025年8月時点の開発記録です 本文の「AI+」や開発予定は、当時の試作内容を紹介したものです。現在提供しているAppInsight AI Reviewの機能・導入方法は、AppInsightの製品紹介ページをご確認ください。 こんにちは、こん太ぱぱです。今日は「AppInsight」のAI+の開発進捗を少しご紹介します。 AI＋とは？ AppInsightは、kintoneアプリの設計データを収集・整理するプラグインです。 AI＋では、その設計情報をもとに「AIが具体的な提案やコード生成を行う」機能を追加しています。単なるAIチャットではなく、アプリ設計情報を渡しながら相談できるのが最大の特徴です。 実装中の機能 現在、以下の機能を開発中です。 アプリ分析レポート アプリ全体をAIが分析し、良い点・悪い点・改善アクションを提示。 セクション別AI評価 A〜Eの観点（入力設計、レイアウト、関連設定など）で自動評価。 改善アクションプラン生成 分析結果をもとに、すぐ実行できる改善アクションを提案。 JavaScriptコード生成 例：「

この記事は2025年7月時点の開発記録です AIによるアプリ分析を試していた当時の考え方と検証内容を紹介しています。現在の提供機能や通常版・AI Review版の違いは、AppInsightの製品紹介ページでご確認いただけます。 kintoneのアプリ構成を見える化する「AppInsight for kintone」。 現在、試しにAppInsightでAIでアプリを分析する機能を実験しています。 そうしたら、思っていた以上に“良い相棒”になりそうな気配がありまして── 今日はそんな開発の途中経過を、ゆるっと紹介してみます。 設定の「その先」が気になっていた AppInsightでは、以下のような情報を自動で取得できます。 アプリにあるフィールドの種類や数 通知やアクセス権の設定 プロセス管理やグラフの有無 他アプリとの関連（LOOKUPやアクションなど） これだけでも十分便利ではあるんですが、ときどき、ふと思うことがありました。 「で、これって、どうしたら良いんだっけ？」 設定の抜け漏れやムダがあるかもしれない。他のアプリと比べて偏りがあるかも

この記事で扱う範囲：JavaScriptによる画面操作の基本と、業務改善への活用イメージを紹介します。ブラウザで動くすべてのサービスが自由なカスタマイズに対応しているわけではありません。実際の業務に組み込む際は、利用するサービスの公式なカスタマイズ方法に沿って進めてください。 「業務改善にJavaScript」ってどういうこと？ 業務改善にJavaScript？ プログラミングって、ちょっと難しそう…──そう思う方にこそ、伝えたいことがあります。 実は、あなたが毎日使っている業務ツール、そのほとんどは「ブラウザの中で動くSaaS」なんです。 勤怠管理や経費精算のシステム 顧客管理（CRM）ツール そして kintoneのような業務アプリ作成プラットフォーム こうしたSaaSは、基本的に ブラウザ上で動いていて、JavaScriptでカスタマイズできる構造になっています。 だからこそ、JavaScriptを少しでも理解しておくと── 自分でちょっとした業務改善ができる kintoneのカスタマイズにも応用できる 外部の開発者に依頼するときも「何をど

「これ、kintoneでできませんか？」 そんな相談をよく受けます。僕自身、これまでいくつものプラグインを開発してきました。 関連レコードをネスト表示するプラグイン ルックアップでコピーされた項目を色で可視化するプラグイン 入力フォームにヒントやツールチップを表示するプラグイン でも、僕がプラグイン開発で一番意識しているのは、「それ、本当に業務で使える？」という視点です。 kintoneには、“得意なこと”と“不得意なこと”がある kintoneは、リレーショナルデータベースとは違う、“カード型”のデータベース。 つまり、1件1件の業務レコードが主役になる構造です。 そのため、 一覧表示・分析・検索の柔軟性 → 弱め 人から人へ業務をつなぐプロセス管理 → 強い という“向き・不向き”がハッキリしています。 だからこそ、僕が開発するプラグインは、「kintoneに足りないものを補う」のではなく、「kintoneの得意分野を、もっと活かす」方向を大切にしています。 仕様上の限界を、どう“味方”につけるか たとえば、kintoneでは「関連レコード一