タグ「kintone」

" ["post_title"]=> string(122) "関連レコード一覧を条件で絞り込んで集計したい！SUMIF機能を実現するプラグインの活用術" ["post_excerpt"]=> string(0) "" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(6) "closed" ["ping_status"]=> string(6) "closed" ["post_password"]=> string(0) "" ["post_name"]=> string(36) "related-record-list-filter-aggregate" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2025-12-11 11:17:44" ["post_modified_gmt"]=> string(19) "2025-12-11 02:17:44" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(45) "https://adiem.jp/?post_type=blog&p=15520" ["menu_order"]=> int(0) ["post_type"]=> string(4) "blog" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" } [1]=> object(WP_Post)#1060 (24) { ["ID"]=> int(15469) ["post_author"]=> string(2) "14" ["post_date"]=> string(19) "2025-12-12 12:00:22" ["post_date_gmt"]=> string(19) "2025-12-12 03:00:22" ["post_content"]=> string(37609) "

こんにちは、ジムリンです！実は、読者の方からいただいた質問をいただきました。ボクもまだまだ経験が浅いのでわからないことも多いですが、一緒に考えてみたいと思います！

備品購入申請システムを作りたい！

こちらが今回いただいた質問です！

📩 読者からの質問 ジムリンさん、はじめまして。製造業で総務を担当している者です。 kintoneを使い始めて数ヶ月経ちますが、まだまだ勉強中です。最近、各部署から備品の購入申請が増えてきて対応に追われています。現在は申請書を印刷して手書きで提出してもらっているのですが、申請内容の確認や承認フローが煩雑で困っています。申請する側も毎回備品名や単価を書くのが大変そうなので、よく使う備品を備品マスタに登録しておいて、そこから選択するだけで申請できるようにしたいと考えています。やりたいことをまとめると、こんな感じです。

よく申請される備品を備品マスタに登録

備品マスタから選択すると申請フォームに情報が自動入力される仕組み

マスタに未登録の備品にも対応したい

金額に応じて承認者を変えたい（1万円未満は課長、それ以上は部長承認など）

今困っているのは、備品マスタから申請アプリを立ち上げる具体的な方法がわからないことです。どのような手順で作れば良いでしょうか？

ボクがやるとしたら、まずある程度データを入れた備品マスタを作って、備品購入申請アプリを作ります。そして、アプリアクションを使って備品マスタから備品購入申請アプリを立ち上げられるようにします。

これで一件落着じゃないかな！？

ジムリン、ちょっと待って！

アプリを作る前に「想定される使い方」を整理しよう！

ジムリンが考えたアプリ、実際に使ってみたらどうなると思う？

え！備品マスタを眺めながら、欲しいものをクリックして購入申請ができると思います……

欲しい備品が複数あったらどうするの？

むむ……。それは、マスタから1つずつ探して、申請してもらう形かな？

本当にそれで現場の負担は軽くなるの？「紙のほうが楽でいいや！」ってならない？

う……、たしかに……。紙に書いたほうが早いかも(ﾟДﾟ;)

ね。 kintoneでありがちなのが、アプリにフォーカスした結果、使い始めてから「もっとこんな機能が必要だな」と気づくこと。そうならないように、まずは要件を整理したいよね。だから、まずはユースケース図を描いてみよう！

ユースケース図で「想定外」を減らせる！

コーさん、ユースケース図ってなんですか？

ユースケース図は、ユーザーの目線から「このシステムで何ができるのか」を明確にする図だよ。アプリの機能を考える前にこの図を描くことで、現場運用での「想定外」を減らせるんだ。ユースケース図を描くことで、こんなメリットがあるよ。

【ユースケース図を描くメリット】・ユーザー視点でシステムを設計できる・必要な機能が見えてくる・複数のパターンや分岐が明確になる

なるほど！さっそく描いてみます！

ユースケース図の描き方｜押さえておきたい4つのポイント

描いてみました！こんな感じでどうですか？

うーん、惜しい！がんばって描いたのはわかるけど、いくつか直したほうがいいポイントがあるよ。

1.体言止めはNG！動詞を使おう

「備品検索」「購入申請」って書いてあるけど、これは体言止めだね。ユースケースは動詞で終えるのが基本だよ。動詞を使うことで、システムを使う人たち（アクター）の具体的なアクションが明確になるよ。

なるほど……。「備品検索」は「備品を検索する」「購入申請」は「備品の購入を申請する」というようになるんですね！

2.具体性を持たせよう

今回は「備品」と言っているからある程度想像できるけど、「何を購入するのか」「何を検索するのか」によってやることが変わるよね。ジムリンが考えている備品っていうのは、具体的には何のことなの？

コピー用紙や安全ヘルメットなどの消耗品を考えていました！

うんうん。ここに「工場で使う材料」などが入ってくると、購入フローが変わってくるはずなんだ。今回は事務所や工場で使う「備品」にフォーカスする。それは、たとえばコピー用紙や安全ヘルメットなどの消耗品のこと。ここまで具体化することで、より実態に即したユースケース図を描けるはずだよ。

3.アクターを見直そう

ここに描いてくれている「現場の作業員」や「総務」といった登場人物のことを、ユースケース図では「アクター」と呼ぶよ。今回のアクターは、本当にこの2種類でいいの？たとえば、コピー用紙の購入を申請する人は現場の作業員だけじゃないんじゃないかな？

たしかに(ﾟДﾟ;) あんまり考えていませんでした……。事務所のみんなのほうが申請しますよね。

そうだよね！今「現場の作業員」となっているアクターは、もっと広く捉えたほうがいいね。

4.5W1Hで考えよう

ユースケースは、利用シーンをはっきりとイメージできるようにすることが大切なんだ。だから、できるだけ5W1Hを明確に書くことをおすすめするよ

・誰が（Who）・どこで（Where）・いつ（When）・何を（What）・なぜ（Why）・どのように（How）

ってことですよね？

そうそう。ユースケースを具体化すると、本当に必要な要件が見えてくるからね。

ただし、ユースケースで明確にしたいのは「そのシステムで何がやりたいのか」であって、目的なんだ。要は、システムでできることを整理したいので、5W1Hすべてを書き出す必要のないときもあるよ。たとえば、How（どのように）はユースケースというよりは、システム設計寄りの要素だよね。また、今回はWhere（どこで）に大きな変化がないので、なくても大丈夫そうだよ。

つまり、利用シーンを具体化するときは5W1Hで整理するのが基本。ただし、すべての要素を丁寧に洗い出すというよりは、そのシステムの目的がわかるように、必要な要素を書き出すってことですか？

そうだね！各要素には優先度があるよ。以下はなるべくマストで書き出してみて！・誰が（Who）・いつ（When）・何を（What）・なぜ（Why）

正しいユースケース図を描いてみよう

コーさんの指摘をもとに、基本的なユースケース図を描いてみました！

どうですか？すべて動詞で終わって、「備品」と具体化して、アクターも見直しました！ただ「いつ」「どこで」のように、5W1Hを明確にするところまではできていません……(ﾟДﾟ;)

うんうん、とてもよくなったよ！たしかに、5W1Hを明確にすると、もう少し具体的なシーンが見えてきそうだね。そんなときは、表を使ってみよう！

表を使ってより具体的なユースケースを探ろう

こんな感じでしょうか？

No.	誰が（Who）	いつ（When）	何を（What）	なぜ（Why）
1	申請者（従業員）	備品を探すとき	備品を検索する	購入したい備品を見つけるため
2	申請者（従業員）	マスタに備品がある場合	マスタから備品を選んで申請する	登録済み備品を簡単に申請するため
3	申請者（従業員）	マスタに備品がない場合	マスタにない備品を手入力で申請する	新しい備品も購入できるようにするため
4	申請者（従業員）	申請が差し戻されたとき	申請内容を修正する	指摘された内容を訂正するため
5	申請者（従業員）	修正が完了したとき	申請を再提出する	再度承認を得るため
6	承認者（総務担当者）	申請が提出されたとき	申請内容を確認する	購入の可否を判断するため
7	承認者（総務担当者）	申請内容が適切なとき	申請を承認する	購入を許可するため
8	承認者（総務担当者）	申請内容に問題があるとき	申請を差し戻す	修正や追加情報を求めるため
9	承認者（総務担当者）	よく使う備品を登録するとき	備品マスタに未登録備品を登録する	申請時の入力を簡単にするため
10	承認者（総務担当者）	申請が承認されたとき	承認済み備品を発注する	実際に備品を購入するため

いいね！今回、Whereはすべて備品購入申請アプリになるから、不要という判断だね。情報量が多くなってかえってわかりにくくなるからHowも不要。この表を見て、何か気づくことはある？

いろいろありますね！たとえば、備品を検索したあと「マスタに備品がある場合」と「マスタに備品がない場合」で分岐があります。そういえば最初にコーさんに指摘されたことですよね。

また、申請が差し戻されたあとに「申請内容の修正」と「申請の再提出」が必要そうです。最初のシンプルな図だけでは、これらのパターンが見えていませんでした！

表を作る前よりも具体的なシーンが見えてきたでしょ？特に「いつ（When）」のところで分岐が明確になったね。

今回みたいな流れもいいけれど、先に表で整理してからユースケース図に落とし込むという方法もあるよ。この内容を反映した詳細なユースケース図を描いてみよう。

具体化したユースケースを図に落とし込もう

表をもとに、詳細なユースケース図を描いてみました！

ピンク色の部分が、今回増えたところです。「備品の購入を申請する」だけだったアクションが2つに分かれて、より具体的になりました。また、「申請を再提出する」という独立したアクションが追加されています。

素晴らしい！ユースケース図を段階的に掘り下げることで、必要な要件が見えてきたね。たとえば最初は考えていなかった「マスタにない場合の対応」や「差し戻しフロー」が見えてきたでしょ？

本当ですね！いきなりアプリを作り始めていたら、あとで「このフローも必要だった！」とやり直しになっていたかもしれません。

ちなみに、ユースケースを出すのってすごく難しいんだよ。何十年も開発をやっている人でも「ユースケースって大事だよね」って言うくらい、奥深いものなんだ。

ジムリンが作ったものも完璧だとは言えないけれど、最初よりもずっとよくなったよ。

ユースケース図から見えたこと

ボクは、最初に以下のような回答を考えていました。

・備品マスタを作る・備品購入申請アプリを作る・備品マスタからアプリアクションで備品購入申請アプリを立ち上げる

これで、「よく使う備品を備品マスタに登録しておいて、そこから選択するだけで申請できるようにしたい」という部分は解決できます。 しかし、実際にユースケース図を描いてみると、それだけでは利用者のニーズを満たせないことがわかりました。 たとえば、備品マスタに未登録の備品の購入を申請したい場合、申請者か承認者のどちらかがマスタに登録する必要があります。現場の負担を軽くしたいというのであれば、登録は承認者側で行うのが無難でしょう。そうなると、マスタから備品を選んで購入を申請するパターンと、マスタにない備品を自由記述で申請するパターンに対応する必要がありそうです。だから、ボクが言ったアプリアクションだけでは根本的な解決になっていないということですね……。

具体的なアプリ構成や必要な機能は、あらためて質問者さんにも考えてもらおうよ。まずは自分自身でユースケース図を描くことが大切。そうすると、これまでは見えなかったことが見えるからね。

具体的なアプリ設計は、環境や運用によって変わるんだ。だから、ジムリンが考えた設計が必ずしも質問者さんの環境にフィットするとは限らないよ。

なるほど！だったら、今回はユースケース図を描くというヒントをもとに、質問者さんにもう一度アプリ設計を考える段階に立ち返ってもらったほうがよさそうですね。

今回、ボクが教えてもらったユースケース図の描き方を参考に、質問者さんもユースケース図を描いてみてください。そうすると、足りない部分が見えてきて、全体的に必要な要件がはっきりするはずです!(^^)!

まとめ：ユースケース図は描いた？kintoneのアプリ設計で悩んだらユースケース図に立ち返ろう

アプリ設計で悩んだときは、まずユースケース図に立ち返ることが大切です。

もし、ユースケース図を描かずにアプリを作り始めていたなら、一度手を止めて要件整理からやり直してみましょう。

すると、今やっていること、考えているがそもそも間違っていることに気づく場合があります。

ボクも、ユースケース図を描いてみて、最初の考えだけだと利用者のニーズを満たせないことに気づけました(;ﾟロﾟ)

今回いただいた質問に対して、こんな方法もあるよ！というアドバイスがあれば、ぜひボクに教えてください！

また、こんなアプリを作りたいんだけどジムリンならどうする？という質問も募集しています。

まだまだ経験の浅いボクですが、みなさんと一緒に考えながらレベルアップしていきたいので、気軽にメッセージをくださいね！

" ["post_title"]=> string(127) "kintoneでマスタから申請アプリを立ち上げたい！まずはユースケース図で要件を整理してみよう" ["post_excerpt"]=> string(0) "" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(6) "closed" ["ping_status"]=> string(6) "closed" ["post_password"]=> string(0) "" ["post_name"]=> string(38) "how-to-draw-a-kintone-use-case-diagram" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2025-12-05 15:34:31" ["post_modified_gmt"]=> string(19) "2025-12-05 06:34:31" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(45) "https://adiem.jp/?post_type=blog&p=15469" ["menu_order"]=> int(0) ["post_type"]=> string(4) "blog" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" } [2]=> object(WP_Post)#1068 (24) { ["ID"]=> int(15356) ["post_author"]=> string(2) "13" ["post_date"]=> string(19) "2025-12-02 08:07:44" ["post_date_gmt"]=> string(19) "2025-12-01 23:07:44" ["post_content"]=> string(20920) "

kintoneがあるのに「検索係」が必要な状態は、Difyで改善できる

データの確認で仕事が止まる！「Dify」で解決したいが、自分にできるのか？

kintoneにデータが蓄積されているのに、結局PCを使える自分が検索して答えていませんか？現場や他部署からデータの問い合わせがあるたびに手が止まり、ただの「検索係」になっているのが現状です。

最近になって「Dify」「n8n」などの自動化ツールが登場しており、聞いたことがある方もいるでしょう。しかし「AIチャットボットを作れば解決する」と聞いても、「API」や「JSON」といった専門用語の壁を感じるのではないでしょうか。

非エンジニアにとってプログラミングの学習コストは高く、「失敗して時間を無駄にしたくない」「自分には無理だ」と二の足を踏むのは当然です。しかし、その悩みは技術の進歩によって過去のものになりつつあります。

Difyにサイボウズ公式の「kintoneプラグイン」が登場！

実は最近、Difyに「kintone連携プラグイン」が標準搭載されました。これを使えば、難解なプログラミングコードを書くことなく、ブロックを並べるだけで連携できます。これまでエンジニアに依頼していた設定が、直感的な操作だけで完結するようになりました。

本記事では、実際に作成した「レコード集計・分析チャットボット」を例に、プラグインの設定手順と活用例、初心者がつまずきやすいポイントを丁寧に解説します。まずはプラグインを活用し、業務効率化の第一歩を踏み出しましょう。

プラグインで「HTTPリクエスト」のハードルが消滅。非エンジニアでも設定しやすい仕様に

最大の挫折ポイント「ヘッダー・パラメータ」からの解放

Difyはノーコードで設定できる手軽さが特徴のツールですが、kintoneとの連携では「HTTPリクエストブロック」という機能を使う必要がありました。この機能を使う際は「API」や「webhook」などの設定が必要になります。そこで「ヘッダー設定」や「JSONパラメータ」といった専門用語を理解する必要がありました。

しかも場合に応じて入力欄にデータを入れたり入れなかったりするため、「そもそもここに何を入れるべきなのか？」「入れるべき情報は分かったが、どこで確認できるのか？」という事態が頻繁に発生します。このハードルが多くの非エンジニアを惑わせ、挫折させてきました。

「難しいAPI連携」は過去の話。今は「穴埋め問題」レベル

しかしプラグインではこれらの設定に必要な項目があらかじめ入力欄として用意されているため、どの情報が必要なのかすぐに理解できます。また、その情報をkintoneからどう取得すれば良いか、簡単な例と一緒に記載されています。そのため設定は必要な情報をガイドに従って入力するだけの「穴埋め」感覚で完了し、本来の目的である「どう連携させるか」という業務設計に集中できるのです。

【利用手順】簡単インストール後、すぐにブロックとして実行できる！

プラグインの導入はDifyの「プラグインストア」から検索して「インストール」ボタンを押すだけでOK。

インストール後は以下の手順でkintoneのデータにアクセスできます。

kintoneブロックの操作手順

Difyでkintoneブロックを設置
- レコードの取得・追加・編集ができるので、機能を選択する
使用しているkintoneのドメインを入力する
- (例)kintoneのURLが"https://XXX.cybozu.com"であれば、ドメインは「XXX」
kintoneアプリの設定画面からAPIトークンを生成し、Difyに入力する
- APIトークンの生成方法はこちら(kintone公式サイト)
適用したいアプリのIDをブロックに入力する
- (例)アプリのURLが"https://XXX.cybozu.com/k/4329/"であれば、アプリIDは「4329」
用途に合わせてレコードを操作する
- レコード取得→レコードの検索条件を入力
- レコード追加→追加したいレコードのデータを入力
- レコード編集→編集したいレコードのIDとフィールド、および更新データを入力

詳しくはサイボウズ公式ページをご覧ください。

【活用例】Difyチャットボットで検索業務を効率化。標準機能にはできない「アプリまたぎ」の参照も

例としてkintoneのレコードを集計・分析するチャットボットを作ってみたので、どのように活用されるか見てみましょう。

実践シナリオ：チャットで「データ分析」を完結させる

今回作成するボットは、案件管理アプリの画面上に設置して使用します。ユーザーが質問すると、裏側でDifyがkintoneレコードを集計・分析し、結果を表示します。わざわざフィルターをかけて検索する必要がなく、「データ集計」のためだけに画面を移動する無駄な手間が解消されます。

システム構成

kintoneアプリ：今回はサンプルとして「案件管理」のアプリを利用します。案件単位で[会社名、案件名、金額、提案商品]などの情報が記録されています。

Difyワークフロー：今回は「チャットフロー」の仕組みを利用します。

活用例

kintoneのアプリ上にデータ分析チャットボットのボタンを設置しました。起動すると裏側でDifyが自動的にレコードを取得する仕組みになっています。

レコードについて分析したい内容を指示してみましょう。今回は会社ごとに売上を集計するように指示してみます。

すると、集計結果と簡単なレポートが出力されました。

このようなチャットを構築することで、画面を切り替えることなくkintoneアプリの内容を把握し、報告書作成や問い合わせ対応に活用することができます。また、Difyの連携機能をもっと活用すると、生成AIの回答内容を自動でドキュメント(Google docsなど)に出力させて、レポート資料を作成することもできます。

【落とし穴と対策】API権限とJSONの壁はこう乗り越える

このようなチャットボットの設定時には、初心者が陥りやすい2つの落とし穴に注意しましょう。 API権限の設定

kintoneブロックの設定時に、データを取得したいアプリのAPI権限が必要です。
参照先アプリでの「APIトークン権限」の設定漏れが起きやすいので注意しましょう。

JSON形式のデータの取り扱い

kintoneブロックから取得したデータはJSON形式になっていますが、そのままではDifyのLLMブロックに入力できません。
コードブロックによるデータ変換が必要となるので、以下のコードテンプレートを使用します。

【テンプレート】JSON形式のデータを表形式に変換するPythonコード

下記のコードはkintoneのレコードから[会社名、案件名、金額、提案商品]のデータを抽出できます。
適用したいアプリに合わせてフィールド名を変更してください。

import json
from typing import List, Dict, Any

def main(kintone_records: List[Dict[str, Any]]) -> Dict[str, str]:
    """
    Processes Kintone records to generate a Markdown table.

    Args:
        kintone_records: A list containing Kintone record data.

    Returns:
        A dictionary with the key 'result' containing the Markdown table string.
    """
    # Difyの入力変数からKintoneのJSONデータを取得
    try:
        kintone_data_list = kintone_records
        if not kintone_data_list:
            # 入力データが空の場合のエラーメッセージを返す
            return {"result": "エラー: 入力変数 'kintone_records' が空です。"}
    except Exception:
        # 入力変数にアクセスできない場合のエラーメッセージを返す
        return {"result": "エラー: 入力変数 'kintone_records' の取得に失敗しました。"}

    # KintoneのJSON構造（[{"records": [...]}]）からレコード配列を取得
    if not isinstance(kintone_data_list, list) or not kintone_data_list or "records" not in kintone_data_list[0]:
        # JSON構造が想定外の場合、エラーメッセージを返す
        return {"result": "エラー: Kintoneデータ構造が予期された形式ではありません。"}

    records = kintone_data_list[0]["records"]

    # ----------------------------------------------------
    # 1. データ抽出と整形
    # ----------------------------------------------------

    table_rows = []

    for record in records:
        try:
            sales_str = record.get("売上", {}).get("value")
            sales_value = float(sales_str) if sales_str else 0
            formatted_sales = f"¥{sales_value:,.0f}"
        except (ValueError, TypeError):
            formatted_sales = "N/A"

        item = {
            "案件名": record.get("案件名", {}).get("value") or "",
            "会社名": record.get("会社名", {}).get("value") or "",
            "提案商品": record.get("提案商品", {}).get("value") or "",
            "売上": formatted_sales
        }
        table_rows.append(item)

    # ----------------------------------------------------
    # 2. Markdownテーブルの構築
    # ----------------------------------------------------

    headers = ["案件名", "会社名", "提案商品", "売上"]
    markdown_table = "| " + " | ".join(headers) + " |\\n"
    alignment = [":---:"] * (len(headers) - 1) + ["---:"]
    markdown_table += "| " + " | ".join(alignment) + " |\\n"

    for row in table_rows:
        values = [str(row.get(h, "")) for h in headers]
        markdown_table += "| " + " | ".join(values) + " |\\n"

    # ----------------------------------------------------
    # 3. 結果の出力
    # ----------------------------------------------------

    return {"result": markdown_table}

【補足】コード調整用プロンプト

もし「コードの書き換えも面倒くさい…」と思う場合は、LLMに任せてしまいましょう。
フィールド名を書き換えて、上記のコードをコピペして貼り付けると、調整したコードが出力されます。

## 前提
以下の「サンプルコード」は、kintoneから取得したjsonデータをmarkdown形式の表に変換するためのコードである。
このコードでは、取得するkintoneデータのフィールドは[案件名,会社名,提案商品,売上]の4種類を指定している。

## 指示
取得するkintoneデータのフィールドを変更したい。
後述する「取得したいフィールド名」のデータを取得し、markdown形式の表を出力するように、コードを修正せよ。

## 取得したいフィールド名
- {フィールド名1}
- {フィールド名2}
- {フィールド名3}

## サンプルコード
//上記のPythonコードをそのまま貼り付ける//

このようにテンプレートとLLMをうまく活用することで、プログラミングの壁を突破できます。

「レコード一覧分析AI」との決定的な違いは「アプリの壁」

このような活用方法を見ると、kintoneの一機能である「レコード一覧分析AI」と変わらないと思う方もいるかもしれません。

しかし「レコード一覧分析AI」には制約があります。それは基本的に「今開いているアプリ」のデータしか扱えないという点です。たとえば案件管理アプリを開いている最中に、取引先の担当者の情報を確認したいケースを考えます。このデータは「顧客管理アプリ」という別のアプリで管理されているため、レコード一覧分析AIで質問しても回答が得られません。これではデータの確認のために別画面を開く手間が生じてしまいます。

対してDifyは、kintoneブロックをワークフローに追加することでデータの参照先を増やすことができます。つまりチャットの中で「今開いていないアプリのデータ」にもアクセスできるのです。このアプリを横断して連携できる「自由度の高さ」が、Difyを使うメリットの1つといえます。

まずはプラグインで簡単な連携から。データ活用で現場を自走させよう

小さく始めて大きく育てる。次はもう一段先の活用へ

このような自動化を成功させるコツは「最初はシンプルな機能で確実に稼働させること」です。操作に慣れてきたら、日報の要約や不良品データの傾向分析などの複雑な連携に挑戦すると良いでしょう。

「検索」ではなく「仕組み作り」に注力しよう

kintoneとDifyを連携させる目的は、単に楽をすることだけではありません。「検索係」という受動的な業務から卒業し、データを現場が活用できる「仕組み」を作ることこそ、生産管理で目指すべきステップといえます。まずは無料版やトライアルを利用し、プラグインの便利さを体感してみてください。

最後に

株式会社アディエムでは、kintone × 生成AIで日々の業務改善に取り組んでいます。今回ご紹介したようなワークフローの他にも、お客様の業務に合った改善をご提案させて頂きます。 無料相談も実施しておりますので、お気軽にお問い合わせ頂ければ幸いです。お問い合わせはこちら" ["post_title"]=> string(141) "【脱・検索係】非エンジニアでもkintoneとDifyを簡単に連携！kintoneプラグインでデータ処理を自動化しよう" ["post_excerpt"]=> string(0) "" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(6) "closed" ["ping_status"]=> string(6) "closed" ["post_password"]=> string(0) "" ["post_name"]=> string(19) "kintone-dify-plugin" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2025-12-02 09:55:12" ["post_modified_gmt"]=> string(19) "2025-12-02 00:55:12" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(45) "https://adiem.jp/?post_type=blog&p=15356" ["menu_order"]=> int(0) ["post_type"]=> string(4) "blog" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" } [3]=> object(WP_Post)#1065 (24) { ["ID"]=> int(15270) ["post_author"]=> string(2) "14" ["post_date"]=> string(19) "2025-11-21 07:00:40" ["post_date_gmt"]=> string(19) "2025-11-20 22:00:40" ["post_content"]=> string(10754) "

前回、生産管理システムの設計する前に、全体最適の考え方が大切だと学んだボク。工場全体のフロー図を描くことで、全体像を把握できました。その後、ボクはさっそく工程ごとのアプリを作ろうとしました。ところが……。今回は、全体のフロー図を描いたあとにボトルネック工程を見つける意義についてお話しします。

▼もしもシリーズとは？地元の小さな製造工場に総務として転職したボク、ジムリン。入社から半年経ったある日、上司から突然「kintoneで生産管理システムを作ってほしい！」と指令を受けることに。本シリーズでは、kintoneのことも製造業のこともわからないボクが、困惑しながらも、ひとつずつ課題をクリアしながら成長する姿を描きます。

業務フローの全体像を描いたらアプリを作る！で、合ってる？

こちらが、前回ボクが描いた工場のフロー図。

ざっくりと工場の全体像が把握できたところで、「よし！ この工程ごとにアプリを作っていけば、生産管理システムになるはず！」と意気込み、受注管理アプリに手をつけようとします。すると、背後から声が飛んできました。

ちょっと待って。そのやり方ではうまくいかないよ！

業務フローの全体像からボトルネック工程を見つけよう！

コー・ジョーは、前回ボクが困っているところを助けてくれた工場に住み着く妖精です。「システム設計では全体最適の考え方が重要」と教えてくれました。ボクは驚きながらも尋ねました。だって、うまくいくと思うじゃないですか？

どうしてうまくいかないんですか？全部の工程に対して効率化するアプリをつくってつなげれば、生産管理システムが出来上がるかと思ったんですけど･･････。

たしかに、最終的にはつくったアプリをつなぎ合わせることで、より効率化できるかもしれないね。でも、最初にやるべきはボトルネック工程を見つけて、 そこを改善するアプリを作ることなんだ！

ちょっとまって、ボトルネック工程ってなに(ﾟДﾟ;)？？

ボトルネック工程とは「タスクが溜まっている工程」のこと

コー・ジョー「ボトルネック工程とは、タスクが溜まっているしている工程のことだよ。工場でいうと、仕掛品が山積みになっていたり、特定の人に仕事が集中している場所だね。ここを改善すると、工場全体の流れが良くなるはずなんだ。」ボク「なるほど･･････。つまり、いつも人が追われている場所ということですか。」

全体の成果はもっとも流れが悪い工程＝ボトルネックで決まる

ボク「でも、なぜボトルネックから着手しないといけないんですか？」コー・ジョー「それを理解するためには、まずTOC理論という考え方を知る必要があるね。 TOC（Theory of Constraints：制約理論）は、1980年代にゴールドラット博士が提唱したマネジメント理論で、制約（ボトルネック）に注目して改善することを重視しているんだよ。 TOC理論によると、全体の成果は一番流れが悪い工程、つまりボトルネックで決まるといわれているんだ。」

ボトルネック工程を解消すれば効率的に生産効率を改善できる

コー・ジョー「川に置き換えて考えてみよう。川には大小さまざまな大きさの岩があって、ところどころ流るスピードが変わっている。川全体の流れを良くしたいとき、小さな岩をいくつ取り除いてもあまり変わらないよね。一気に水の流れを改善したいとき、どうしたらいいと思う？」

ボク「この絵だと、一番大きな岩を削ったり、大きな岩がある部分の川幅を広くしたりですかね？」コー・ジョー「そう！一番大きな岩に注目したのが正解だよ。この大きな岩こそがボトルネック工程なんだ。工場でも同じで、「大きな岩＝ボトルネック工程」に注目して改善すれば、納期遅れが解消して一日の生産量が増えることも期待できる。逆に、小さな岩を手当たり次第に取り除こうとすると、時間ばかりかかって非効率なんだ。」ボク「なるほど…、流れが良くなるポイントを見極めて改善する。だから効率的で、効果も大きいってことなんですね。」コー・ジョー「そういうこと！ TOC理論に沿って考えると、業務フロー図を描いたあとは、まずボトルネック工程を探すことになるね。」

人や機械などリソースに目を向けて、ボトルネック工程を見つけよう！

ボク「では、どうやってボトルネック工程を探せばいいんですか？」

タスクが集まる人や機械を見つけよう！

コー・ジョー「まずは誰の目から見ても明らかにタスクが溜まっているポイントを探してみよう。 仕掛品が積み上がっている工程や、納期遅れが目立つ作業がサインだよ。 TOC理論では、工程そのものだったり、予算や人員などの条件だったりがボトルネックといわれるんだけど、実際の現場では、人や機械といったリソースがボトルネックになっていることが多いんだ。たとえば、中小企業ではベテラン社員や社長自身が業務を抱え込み、流れの滞留点になっていることがあるよ。」ボク「その場合、ベテラン社員や社長を仕事から外すのがいいんですか？」コー・ジョー「それは、違うよ。たしかに、ボトルネックと聞くと悪い印象を持たれがちだけれど、仕事が集まるのはその人たちが重要なリソースだからこそだよね？要は、いろいろな人から頼られる存在ってこと。だから「本当にその人しかできない仕事なのか？」という視点で、業務を見直すことが重要なってくるんだ。」ボク「なるほど……。ボトルネックは貴重なリソースで、排除するものではないんですね。ぼく、現状だと工場のどこにタスクが溜まっているか知らないんです。実は、入社して半年経つけど、みんなの仕事もよくわかってなくて……。ただパソコンに向かっているだけじゃダメですよね、まずは現場を知らないと！現場の人たちが何に困っているのか、聞いてみます。」

現場に仕事の進みが遅いポイントをヒアリングしてみると……

ボクはフロー図を片手に現場を歩き、担当者に話を聞きました。営業からは「進捗が分からず、納期を聞かれるたびに工場長に確認している」という声。工場からは「営業の電話が多い上に飛び込み案件も多く、現場の負担になっている」という不満。聞けば聞くほど、さまざまな困りごとや不満があふれ出てくるので、コレ大丈夫？と不安になるボク。

課題が山積みでどれがボトルネックなのかわからない……！

今回はとくに、製造の人たちの不満が多かったような気がします。いろいろ言ってくれたし･･････。ということは、製造のところがボトルネックなのかもしれないですよね。でも、社長が納期遅れをなんとかしてほしいって言ってたいたのも気になっていて。やっぱり偉い人の言うことを聞くべきな気がしませんか？そんなこんなで、ボクは山積みの課題を前に、頭を抱えてしまいました。

【教訓】ボトルネック工程を見つけるには人や機械に注目しよう！

今回の学びをまとめると……

・全体最適の視点でシステムを設計するには、まずボトルネック工程を見つけること！・工場では人や機械がボトルネックになっていることが多い・ボトルネックとは「悪」ではなく、現場にとって貴重なリソース・「本当のその人（機械）でなければできない仕事か？」という視点で貴重リソースの負担を分散することが大切

ただ、現場にヒアリングしてみたら、課題が山積みでボトルネックを特定できず、煮詰まってしまいました。ここからどうやってボトルネックを特定すればいいんだろう！？次回へ続く･･････。 " ["post_title"]=> string(111) "工場のボトルネック工程はどこ？人や機械に注目してタスクの滞留点を見つけよう" ["post_excerpt"]=> string(0) "" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(6) "closed" ["ping_status"]=> string(6) "closed" ["post_password"]=> string(0) "" ["post_name"]=> string(36) "factory-bottlenecks-how-to-find-them" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2025-12-14 10:56:42" ["post_modified_gmt"]=> string(19) "2025-12-14 01:56:42" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(45) "https://adiem.jp/?post_type=blog&p=15270" ["menu_order"]=> int(0) ["post_type"]=> string(4) "blog" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" } [4]=> object(WP_Post)#1062 (24) { ["ID"]=> int(15197) ["post_author"]=> string(2) "14" ["post_date"]=> string(19) "2025-11-07 15:07:39" ["post_date_gmt"]=> string(19) "2025-11-07 06:07:39" ["post_content"]=> string(13637) "

Production management system - kintone-Process management system - Overall optimization

こんにちは、東京の旅行代理店から地元の製造業に総務担当として転職したジムリンです！製造業未経験で上司からいきなり「kintoneで生産管理・工程管理システムを作ってみて！」なんていわれたら、みなさんは何から手をつけますか？ボクの場合、製造業向けのサンプルアプリを探してつなぎ合わせようとしたんですけど、ある問題が、……。今回は、ボクの前に立ちはだかった「最初の壁」と、ある方に教えてもらった「システム設計で最初にやるべきこと」をお話しします。

生産管理・工程管理システムに必要なアプリって何！？

「とりあえず何か形にしないと！」と思ったボクは、「kintone 製造業サンプルアプリ」で調べました。すると、無料で使えるアプリがいっぱいあるじゃないですか！

引用：kintone公式サイトウチの工場に必要なアプリをこのなかから見繕って、つなぎ合わせれば生産管理システムができると思ったんです。ところが、いっぱいありすぎて、どれを使ったらいいかわからへん！ ウチの工場に必要なアプリってどれやねん！ という状況に陥りまして……。

そもそもうちの生産工程ってどうなってるの？

サンプルアプリを見ていくと、工程ごとにアプリを入れるのが良さそうだと思いましたが、ここでも壁に衝突します。そもそも、ウチの工場の工程ってどうなっているのかがわからなかったんです！工程がわからなければ、必要なアプリも決められないと思いませんか？そこで、工場に行ってみたんですが、どういう名前の工程がどのようにつながっているのかって、見てもわからないんです。工場で働くみんなは忙しそうで声を掛けることもできず、ボクはいったん事務所に戻りました。入社半年も経つのに「ウチの工場ってどういう工程があるんですか？」なんて聞いたら、「こいつ半年間何してたんだ？」って思われそうじゃないですか。実際、そんなこと言う人はいないんですけど。いろいろ考えた結果、自力で何とかしなくては！と思い、再び机に向かったんです。

まずは工場全体の業務フロー図を描こう！

ボクが目を閉じてしばらく悩んでいると、どこからともなく声が聞こえてきました……。「サンプルアプリをつなぎ合わせてもうまくいかないよ！」って。考えすぎるあまり、寝ちゃったんだ、これは夢だって思いました。「いけない、起きなきゃ」と思って目を開けると目の前にいたんです。あの方が。そして言いました。「わたしは古くからこの工場に住み着いている妖精、コー・ジョー。工場のことならなんでも知っているよ！」工場に妖精っているんですね。もうボクは、本当にどうしたらいいのかわからなかったので、藁にもすがる思いでコーさんに助けを求めました。「ボクはジムリンっていいます！コーさんは先輩ですよね？ボク、工場のことなにもわかっていないのに、生産管理システムを作らなくちゃいけなくて……。」結論、ボクはコーさんから大きなヒントをもらいました。ここからは、コーさんとボクのやりとりを忠実に再現しますね。ボク「サンプルアプリをつなぎ合わせる方法はダメなんですか？イチからアプリを作ると時間がかかりそうだし、あるモノを使ったほうが効率的だと思うんですが。」コー・ジョー「サンプルアプリをつなぎ合わせるやり方では、自社に最適化された生産管理システムは作れないよ。たしかに、生産管理システムっぽい形にはなるけれど、自社のフローや業務に合っていなければすぐに使えなくなるね。だから、まずは工場全体の業務フロー図を描いて、自社の課題から本当に必要な機能を見つけないと！」あまり理解できていないボクに、コーさんは詳しく説明を始めました。

システム設計は「全体最適」で考えよう

コー・ジョー「ジムリンの考え方は部分最適というよ。最初に小さなアプリに注目すると、たしかに目の前の工程は改善されるかもしれないけれど、工場全体の流れの改善につながらないことがあるんだ。」ボク「工場全体の流れってどういうことですか？生産管理システムとどう関係があるんですか？」コー・ジョー「材料を仕入れるところからお客さまに届けるまでの一連の流れが「工場全体の流れ」だとしよう。例えば、製造の工程が機械の不具合で止まってしまうと、どうなると思う？」ボク「あ、納期どおりに納品できなくなるかも……。」コー・ジョー「そう、だからそういったトラブルが起こらないように、また起こったときすぐに解決できるように、仕入情報や生産スケジュールなんかを管理するのが生産管理システムの役割になるよね。」ボク「なるほど、生産管理システムの役割って考えてなかったです。話を戻しますが、なぜ部分最適で考えるとダメなんでしょうか？」コー・ジョー「工場全体を川に置き換えて考えてみよう。必要そうなアプリを1つずつ作ると、それぞれが島のように点在する。島のなかだけは便利になるかもしれないけれど、川の流れはどう？スピードは？」ボク「変わりませんね……。」コー・ジョー「そう！つまり工場全体の流れはちっとも変わらない。これが部分最適なんだ。例えば、受注管理や在庫管理など全部の工程をいっぺんに最適化しようとしたらどうなるかな？各工程で要件を洗い出して、担当ごとにアプリを作って、細かい仕様を決めて......とやっているうちに、膨大な時間と労力がかかってしまう。しかも、工場全体の流れは変わらない。結局、全体の流れを意識せずにバラバラにアプリを作っても、結局は遠回りになるんだよ。サンプルアプリを使ったとしても同じことだよね？だからこそ全体最適で考える必要があるんだ！」

大事なのは工場全体の「流れ」を見ること

ボク「全体最適ってどういうことですか？さっきの話だと、川を見るってことですか？コー・ジョー「そう、川に注目するんだ。島を増やすことでも橋でつなぐことでもなく、川の流れそのものを良くする。これはTOC理論と呼ばれる考え方に基づいていてね。 工場全体の流れを見たあとで、その流れをせき止めている部分（ボトルネック）を見つけ、そこを改善していくことがポイントなんだ。」ボク「TOC理論っていうのがあるんですね……。全然知らなかったです。つまり、流れを止めている場所を見極めて、集中的に改善するためのシステムを作ることで工場全体の流れが変わるってことですね！？」コー・ジョー「そう、全体を俯瞰して流れを意識する。そうやって全体最適の視点で生産管理システムを設計すると、結果につながるんだ！」

工場全体の業務フローを描いてみよう！

ボク「納得できました！ TOC理論なるものがあるということは、製造業の人たちは部分最適で業務改善を図ろうとしてきて失敗をしてきたんでしょうね。それで、全体最適でシステム設計をするには、何から始めるんでしょうか？」コー・ジョー「まずは、工場全体の流れを把握するために、業務フロー図を描いてみよう！」

業務フローは工場の入口から出口までを「ざっくり」描こう

ボク「工場全体の業務って、どこからどこまで描けばいいんですか？。」コー・ジョー「いい質問だね。生産管理に焦点をあてるなら、まずは工場の入口から出口までくらいで大丈夫！受注から出荷までを一枚に描いてみれば十分だよ。描いたあとで『ここは順番が違うよ』『この工程が抜けているよ』と周りにフィードバックをもらって修正すればいいので、まずはざっくり描いてみよう。」ボク「なるほど...。上流から下流までの川を描くイメージですね。魚や石まで細かく描く必要はないと。」コー・ジョー「そのとおり！」

業務フローを描くときは付箋・Excel・ITツールを使おう

コー・ジョー「業務フロー図を描くときはツールを使おうね。大きく分けると3つあるよ。

付箋と模造紙を使う
Excelを使う
ITツールを使う

手書きでも十分だけど、共有や修正を考えるとExcelやITツールのほうが便利な場面も多いよ。」

draw.ioを使って業務フロー図を描いてみよう

ボク「今回は、draw.ioを使ってみました！」コー・ジョー「draw.ioは、無料で使えるオンラインの図解ツールだね。フローチャートや業務フロー図を簡単に作れるから、工場の流れを整理するのにぴったり！」ボク「はい。直感的に使えて、初心者のぼくでもすぐにフロー図を描けました！これです。

実際に描いてみると、工程ごとのつながりや順番がイメージしやすくなりました。見にくいので整理したものもご覧ください。

今まで工場の全体像ってわかっていませんでしたが、一枚の図に起こすとなんとなくわかってきますね。」コー・ジョー「そう、それが大事なんだ。これでシステム設計の第一歩は完了だよ。」

【教訓】システム設計は工場全体の業務フローを描くところから！「全体最適」の考え方が重要

妖精のコーさんのアドバイスがなければ、危うく部分最適の生産管理システムを使って、現場の人たちに「これは使えないね！」って言われちゃうところでした。それだと作る意味がないし、時間の無駄ですもんね(;'∀') そもそも、何のために生産管理システムを作るのか、そのために何から考えるのかという視点が足りていなかったです。今回、コーさんからボクが学んだことをまとめてみました。

・アプリを並べても、使える生産管理システムにはならない・部分最適で進めると、手間や時間ばかりかかって遠回りになる・大事なのは、工場全体の流れを意識して全体最適で考えること・そのためには、まず工場全体の業務フローをざっくり描いて全体像をつかむこと

ボクと同じようにいきなりkintoneで生産管理システムを作れといわれた人がいたら、ぜひ参考にしてみてください。次回は、今回作った業務フロー図をもとに生産管理システムを作ります！ " ["post_title"]=> string(130) "kintoneで生産管理・工程管理システムを作るには何から始めるの？小さなアプリから作らない理由" ["post_excerpt"]=> string(0) "" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(6) "closed" ["ping_status"]=> string(6) "closed" ["post_password"]=> string(0) "" ["post_name"]=> string(36) "kintone-production-management-system" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2025-12-14 10:56:36" ["post_modified_gmt"]=> string(19) "2025-12-14 01:56:36" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(45) "https://adiem.jp/?post_type=blog&p=15197" ["menu_order"]=> int(0) ["post_type"]=> string(4) "blog" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" } [5]=> object(WP_Post)#1059 (24) { ["ID"]=> int(15032) ["post_author"]=> string(2) "12" ["post_date"]=> string(19) "2025-09-26 11:02:26" ["post_date_gmt"]=> string(19) "2025-09-26 02:02:26" ["post_content"]=> string(7335) "この記事は Claude Desktop → kintone 公式MCPサーバー をつなぐ最短手順をまとめたものです。 AIを駆使したkintoneの活用法や、AIを使った業務効率化に興味がある方は是非ご覧ください。 3通りのやり方（DXT／Docker／npm）を紹介し、どれを選んでも5分で接続できます。

前提（準備するもの）

kintone 環境（例：https://<subdomain>.cybozu.com）
Claude Desktop（mac/Win/Linux） ※他のAI（GeminiやChatGPT）での利用は確認しておりません。
認証情報：ユーザー名＋パスワード もしくは APIトークン（必要最小権限でOK）
（Docker方式を使う場合）Docker が動く環境
（npm方式を使う場合）Node.js v18+（推奨 v20+）

やり方A：DXT（いちばんカンタン）

Claude Desktop の「拡張機能」に .dxt をドラッグ＆ドロップするだけ。

GitHubのリリースから kintone-mcp-server.dxt をダウンロード
Claude Desktop を開き、設定 → デスクトップアプリ → 拡張機能 を表示
ダウンロードした .dxt をウィンドウにドラッグ＆ドロップ → インストール
表示される設定ダイアログで以下を入力して保存
- Kintone Base URL：例 https://example.cybozu.com
- Kintone Username / Password または API Token
新規チャットを作成し、ツールに kintone が見えればOK

※kintone公式ページはこちら 動作確認の例

「kintone のアプリ一覧を取得して」
「アプリID=○○ の最新5件を表示して」

やり方B：Docker（設定ファイルで管理したい人向け）

Claudeが stdio でコンテナを起動する構成。資格情報は環境変数として渡す。

画像を起動

docker run -i --rm \
  -e KINTONE_BASE_URL=https://example.cybozu.com \
  -e KINTONE_USERNAME=<username> \
  -e KINTONE_PASSWORD=<password> \
  ghcr.io/kintone/mcp-server:latest

Claudeの設定ファイルを編集（mac：~/Library/Application Support/Claude/claude_desktop_config.json）

{
  "mcpServers": {
    "kintone": {
      "type": "stdio",
      "command": "docker",
      "args": [
        "run","-i","--rm",
        "-e","KINTONE_BASE_URL",
        "-e","KINTONE_USERNAME",
        "-e","KINTONE_PASSWORD",
        "ghcr.io/kintone/mcp-server:latest"
      ],
      "env": {
        "KINTONE_BASE_URL": "https://example.cybozu.com",
        "KINTONE_USERNAME": "<username>",
        "KINTONE_PASSWORD": "<password>"
      }
    }
  }
}

Claude を再起動→新規チャットで kintone ツールを選ぶ

APIトークン認証も可：KINTONE_API_TOKEN を設定（カンマ区切りで最大9個）。ユーザー名/パスワードと同時指定時はパスワード認証が優先。

やり方C：npm（グローバル導入して使う）

インストール

npm install -g @kintone/mcp-server

手動起動（デバッグ向け）

kintone-mcp-server \
  --base-url https://example.cybozu.com \
  --username <username> \
  --password <password>

Claudeの設定に command と args で同等指定（Docker例を command: "kintone-mcp-server" に置き換え）

認証・ネットワークのオプション

Basic認証：KINTONE_BASIC_AUTH_USERNAME / KINTONE_BASIC_AUTH_PASSWORD
プロキシ：HTTPS_PROXY=http://proxy.example.com:8080
クライアント証明書（PFX）：KINTONE_PFX_FILE_PATH / KINTONE_PFX_FILE_PASSWORD
添付ダウンロード先：KINTONE_ATTACHMENTS_DIR（kintone-download-file を使う際は必須）

代表ツール（できること）

kintone-get-apps／kintone-get-app：アプリ情報の取得
kintone-get-form-fields／kintone-get-form-layout：フィールド・レイアウト取得
kintone-get-records／kintone-add-records／kintone-update-records／kintone-delete-records
kintone-update-statuses：レコードのプロセス管理ステータス更新
kintone-download-file：添付ファイル保存（保存先ディレクトリの指定が必要）

トラブルシューティング

ツールが出てこない：JSONの末尾カンマやクォートを確認 → Claudeを完全再起動
認証で失敗：Base URL のスペル（https://<subdomain>.cybozu.com）と認証方式（ユーザー/パス or APIトークン）を見直し
ゲストスペース非対応：ゲストスペースのアプリにはアクセス不可（制限仕様）
添付の保存エラー：kintone-download-file は KINTONE_ATTACHMENTS_DIR の指定が必須

セキュリティと権限

本番ではAPIトークン認証＋最小権限を推奨（読み取り専用→書き込み系は別トークン）
監査のため、kintone側に**実行ログ（日時／実行ID／操作内容）**を残す設計にすると安全

まとめ

DXTならドラッグ＆ドロップで最短接続、Docker/npmなら構成管理しやすい
主要操作（取得・追加・更新・削除・ステータス更新・添付DL）は標準ツールでカバー
認証はユーザー/パス or APIトークン。プロキシや証明書にも対応
AIを通して自然言語でkintoneアプリに対する操作が行える

" ["post_title"]=> string(69) "【AI活用】kintoneが正式にMCP対応したので使ってみた" ["post_excerpt"]=> string(0) "" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(6) "closed" ["ping_status"]=> string(6) "closed" ["post_password"]=> string(0) "" ["post_name"]=> string(21) "kintone-officeial-mcp" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2025-11-25 12:13:59" ["post_modified_gmt"]=> string(19) "2025-11-25 03:13:59" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(45) "https://adiem.jp/?post_type=blog&p=15032" ["menu_order"]=> int(0) ["post_type"]=> string(4) "blog" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" } [6]=> object(WP_Post)#1058 (24) { ["ID"]=> int(14897) ["post_author"]=> string(2) "12" ["post_date"]=> string(19) "2025-07-15 11:16:23" ["post_date_gmt"]=> string(19) "2025-07-15 02:16:23" ["post_content"]=> string(0) "" ["post_title"]=> string(133) "最近話題の「kintoneセミオーダー型アプリケーション」って？メリットをまるっと解説【製造業編】" ["post_excerpt"]=> string(0) "" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(6) "closed" ["ping_status"]=> string(6) "closed" ["post_password"]=> string(0) "" ["post_name"]=> string(27) "kintone-semiorder-app-merit" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2025-11-25 11:34:54" ["post_modified_gmt"]=> string(19) "2025-11-25 02:34:54" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(45) "https://adiem.jp/?post_type=blog&p=14897" ["menu_order"]=> int(0) ["post_type"]=> string(4) "blog" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" } [7]=> object(WP_Post)#4308 (24) { ["ID"]=> int(14003) ["post_author"]=> string(2) "12" ["post_date"]=> string(19) "2023-11-22 11:33:37" ["post_date_gmt"]=> string(19) "2023-11-22 02:33:37" ["post_content"]=> string(0) "" ["post_title"]=> string(69) "展示会ご来場の御礼＆オンライン体験開始日決定！" ["post_excerpt"]=> string(0) "" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(6) "closed" ["ping_status"]=> string(6) "closed" ["post_password"]=> string(0) "" ["post_name"]=> string(16) "grow-online-demo" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2025-10-31 10:10:58" ["post_modified_gmt"]=> string(19) "2025-10-31 01:10:58" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(45) "https://adiem.jp/?post_type=blog&p=14003" ["menu_order"]=> int(0) ["post_type"]=> string(4) "blog" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" } } ["post_count"]=> int(8) ["current_post"]=> int(-1) ["before_loop"]=> bool(true) ["in_the_loop"]=> bool(false) ["post"]=> object(WP_Post)#1064 (24) { ["ID"]=> int(15520) ["post_author"]=> string(2) "14" ["post_date"]=> string(19) "2025-12-16 12:00:07" ["post_date_gmt"]=> string(19) "2025-12-16 03:00:07" ["post_content"]=> string(15335) "

こんにちは、ジムリンです！製造業の総務に転職して半年、なぜかkintoneまわりの業務も任されるようになりました。最近、工数実績管理アプリで色々なデータを分析する機会が増えたんですが、ある問題に直面していて……。今回は、「関連レコード一覧を特定の条件で絞り込んで集計したい」という悩みと、それを解決するプラグインをご紹介します。

あらゆる業種で活躍！関連レコード集計プラグインの条件付き集計ユースケース

関連レコード集計プラグインの条件付き集計機能を使ってみて、ボクはふと思いました。

これって、製造業だけじゃなくてほかの業種でも応用できますよね？

もちろん！いくつかユースケースを紹介するね。

ということで、コーさんが業界別のユースケースを紹介してくれました。

小売業：顧客別の「今月の購入金額」を即座に確認

・顧客管理アプリに購入履歴を関連レコードで表示・「購入日が今月」という条件で合計購入金額を自動集計・接客中に「今月は既に〇〇円ご購入いただいてます」と即答できる

条件を「購入日が今月」にするだけで、今月分だけの集計ができるんだ。

不動産業：物件別の「成約済み」案件の合計契約金額

・物件管理アプリに商談履歴を関連レコードで表示・「ステータスが成約」という条件で契約金額を集計・物件ごとの収益性を即座に把握

成約済み案件だけを集計できるから、実績管理がしやすくなるね。

IT業：プロジェクト別の「特定メンバー」の作業時間

・プロジェクト管理アプリに作業実績を関連レコードで表示・「担当者=田中」という条件で作業時間を集計・メンバーごとの稼働状況を即座に確認

メンバー別の工数がすぐわかるから、リソース配分の判断もしやすいね。

人材派遣業：派遣先別の「稼働中スタッフ数」

・派遣先管理アプリに派遣実績を関連レコードで表示・「ステータスが稼働中」という条件で人数を集計・派遣先からの問い合わせに即答

稼働中のスタッフだけをカウントできるから、現在の状況がすぐわかるよ。

本当にいろんな業種で使えるんですね！

関連レコードをもっと便利に活用したい人におすすめしたいです。

条件付き集計（SUMIF）ができるのは、アディエムの関連レコード集計プラグインならでは！

コーさんのおかげで、ボクの悩みは解決しました！関連レコード一覧を条件で絞り込んで集計する問題を、こんなに簡単に解決できるなんて思ってもみませんでした。ここで、関連レコード集計プラグインの条件付き集計機能のポイントをまとめておきますね。

【関連レコード集計プラグインの条件付き集計（SUMIF）機能のポイント】・ExcelのSUMIF関数のように、条件を指定して集計できる・「営業担当=〇〇」「案件カテゴリ=△△」「ステータス=□□」など、業務に必要な条件で絞り込み可能・複数の条件付き集計を同時に設定でき、多角的な分析が可能・集計結果は自動的にフィールドに保存されるため、画面を開くだけで確認できる

条件付き集計機能、本当に便利ですね！

アディエムの関連レコード集計プラグインならではの機能なんだ。

合計や平均を出せるプラグインはたくさんあるけれど、条件付き集計はなかなかないんだよね。

ちなみに、このプラグインは買い切り制で35万円/ドメインだから導入もしやすいよ。

買い切りなら予算も立てやすいですし、上司にも提案しやすいです！

アップデートとかはどうなってるんですか？

一度導入すれば、アップデートも無料。常に新しい状態で使えるよ！

まとめ：関連レコード集計プラグインの条件付き集計（SUMIF）で業務効率アップ

関連レコード一覧を使っているけど、特定の条件に絞ってで集計したい……。そんな悩みを抱えている人は、ぜひ関連レコード集計プラグインの条件付き集計（SUMIF）機能を試してみてください。ボクみたいに、毎回別アプリを開いてフィルタ→集計していた手間がゼロになりますよ!(^^)! しかも、複数の条件を同時に設定できるから、多角的な分析も可能です。 買い切り制だから、月額費用もかからず、長く安心して使えるのもポイントです。

まずは無料体験版で試してみるといいよ。

さっそく、無料体験版を入れてみます！

30日間無料！体験版に申し込む " ["post_title"]=> string(122) "関連レコード一覧を条件で絞り込んで集計したい！SUMIF機能を実現するプラグインの活用術" ["post_excerpt"]=> string(0) "" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(6) "closed" ["ping_status"]=> string(6) "closed" ["post_password"]=> string(0) "" ["post_name"]=> string(36) "related-record-list-filter-aggregate" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2025-12-11 11:17:44" ["post_modified_gmt"]=> string(19) "2025-12-11 02:17:44" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(45) "https://adiem.jp/?post_type=blog&p=15520" ["menu_order"]=> int(0) ["post_type"]=> string(4) "blog" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" } ["comment_count"]=> int(0) ["current_comment"]=> int(-1) ["found_posts"]=> int(8) ["max_num_pages"]=> int(1) ["max_num_comment_pages"]=> int(0) ["is_single"]=> bool(false) ["is_preview"]=> bool(false) ["is_page"]=> bool(false) ["is_archive"]=> bool(true) ["is_date"]=> bool(false) ["is_year"]=> bool(false) ["is_month"]=> bool(false) ["is_day"]=> bool(false) ["is_time"]=> bool(false) ["is_author"]=> bool(false) ["is_category"]=> bool(false) ["is_tag"]=> bool(true) ["is_tax"]=> bool(false) ["is_search"]=> bool(false) ["is_feed"]=> bool(false) ["is_comment_feed"]=> bool(false) ["is_trackback"]=> bool(false) ["is_home"]=> bool(false) ["is_privacy_policy"]=> bool(false) ["is_404"]=> bool(false) ["is_embed"]=> bool(false) ["is_paged"]=> bool(false) ["is_admin"]=> bool(false) ["is_attachment"]=> bool(false) ["is_singular"]=> bool(false) ["is_robots"]=> bool(false) ["is_favicon"]=> bool(false) ["is_posts_page"]=> bool(false) ["is_post_type_archive"]=> bool(false) ["query_vars_hash":"WP_Query":private]=> string(32) "ee16ea99092ab1b90e8f425422a26cc2" ["query_vars_changed":"WP_Query":private]=> bool(true) ["thumbnails_cached"]=> bool(false) ["allow_query_attachment_by_filename":protected]=> bool(false) ["stopwords":"WP_Query":private]=> NULL ["compat_fields":"WP_Query":private]=> array(2) { [0]=> string(15) "query_vars_hash" [1]=> string(18) "query_vars_changed" } ["compat_methods":"WP_Query":private]=> array(2) { [0]=> string(16) "init_query_flags" [1]=> string(15) "parse_tax_query" } ["query_cache_key":"WP_Query":private]=> string(84) "wp_query:f0d65757b42a424ff898c422f86e9cf6:0.80451400 17660169270.86438200 1766016927" } -->