- ホーム
- kintone
タグ「kintone」
こんにちは、ジムリンです!
前回、工場全体の課題を整理した結果、工場長にタスクが集中していることが判明しました。
そこで改善を促すために、会議で「工場長がボトルネックです!」と発表したところ、工場長から激怒されてしまったんです(T-T)
ボクは、コーさんにヒントをもらいながら、ボトルネックを特定したあとに「どう改善すればいいのか」について考えました。
今回は、TOC理論における「ボトルネックの本領を発揮させる」という考え方と、ボクが工場長のために何ができるか考えたプロセスをご紹介します!
工場長にタスクが集中!どうすれば改善できる?
工場長がボトルネックになっているのは、営業からの進捗確認、現場からの判断依頼、購買からの在庫確認、社長からの納期調整の相談……などのタスクが集中しているからです。 あらゆる問い合わせや依頼が工場長に集中しており、その負担は明らかに限界を超えていました。 ボクは「工場長がボトルネックです」と伝えて改善策を話し合おうとしましたが、工場長は顔を真っ赤にして激怒(T-T) 「俺がボトルネックだと!?ふざけるな!」 その怒号が今も耳に残っています。 正直、悔しかったです。 工場をよくするために頑張ったのに、なぜ怒られなきゃいけないんだろうって。 でも同時に、ボクは強く思いました。 「工場長の負担を軽くしないと、工場全体が回らない!」 この状況を、なんとかしなければ……。改善の第一歩は「ボトルネックの本領を発揮させる」こと!
悩んでいるボクに、コーさんが声をかけてくれました。ジムリン、落ち込んでいても仕方ないよ。
次の一手を考えよう!
でも、コーさん……。
ボク、どうしたらいいのかわかりません。
工場長もすごく怒ってるし、何もしないほうがいいのかも……(T-T)
ボトルネックを見つけたら「本領を発揮させる」のが次の一手だよ!
工場長に本来の力を出してもらうってことですか?
そうそう、問題は工場長自身じゃなくて、工場長にタスクが集中していることだよね?
工場長は本来集中すべきタスクに集中できていない、つまり本領が発揮できていないってことだよね。
なるほど……。
よく「ボトルネックを解消しよう!」なんていうんだけど、それって「ボトルネックを排除しよう」ってニュアンスに聞こえない?
だから、本領を発揮させるっていう言い方にしてみたよ。
た、たしかに。
もしかして工場長はそれで怒ったのかな。
そうかもしれないね! 前に工場のボトルネックは人や設備がほとんどって言ったけど、これを排除するのは違うよね。
はい……、だから負担を軽くしたいと思って……。
仕事が集まる工場長は希少リソースで、なくてはならない存在なんだ。
工場長を責めるのではなく、工場長が本来やるべき仕事に集中できるよう環境を整えることが大事だよね。
コーさんの言葉に、ボクは気づきました。 ボクは工場長を責めてしまったんだ。 本当は、工場長に寄り添って本領を発揮できるようにサポートすることがボクの役割なのに。 みんなの前で「工場長がボトルネックです!」なんて……。 ボク、長年工場を支えてきた工場長になんて失礼なことを言ってしまったんだろう。 すごく申し訳ないし、そんなことに気づかずはしゃいじゃって恥ずかしい気持ちだし、泣きそうです(T-T)工場のスループットはボトルネックに左右される
ジムリン、ここでTOC理論をベースにおさらいしてみよう。
工場のスループットはボトルネックで決まる
まず「スループット」の意味を押さえておこうか!
スループットとは、「工場がお金を生み出す速度」のこと。
だから「どれだけ製品を出荷できたか」でスループットが決まるんだよ。
工場はお金を生み出さないと意味ないですもんね。
だから、スループットに注目して改善を図るべきってことですか?
うん。そして、工場の一番流れが悪いところ、つまりボトルネックがスループットを決めてしまうんだ。
以前砂時計の話をしたのを覚えているかな?
砂時計を工場に見立てると、一番細くなっているところがボトルネックですよね。
そうそう。その細い部分でスループットが決まるってことだね。
たしかに、この部分の細さが全体のスループットに影響を与えていますね!
ジムリンの工場の場合はどうかな?
たとえば、工場長への問い合わせが集中して判断が遅れると、全体の流れが滞るよね。
その結果、スループットはどうなる?
なるほど……。
工場長にタスクが集まるほどスループットに影響が出るってことなんですね。
ボトルネックは「弱点」ではなく「貴重なリソース」
さっきも言ったように、ボトルネックは弱点じゃない。
むしろ希少なリソースなんだ!
工場になくてはならない存在ですね!
だから「排除する」のではなく、「本領を発揮させる」ために工場の仕組みや業務への取り組み方を改善するのが重要なんだよ!
ボクは自分の言葉を振り返って、また反省しました。 「工場長がボトルネックです」という言い方は、まるで工場長が悪いみたいに聞こえます(T-T) 工場長は「工場にとって一番大切な存在」だから、タスクが集まっている。 そのことをまず伝えるべきでした……。ボトルネックの本領を発揮させれば全体が効率よく改善する
ほかの工程をどれだけ改善しても、ボトルネックが変わらなければスループットは変わらないよね。
それだと意味がないわけ。
逆に言えば、ボトルネックが本領を発揮できるようになれば、工場全体の流れが一気に改善するってこと!
今回でいうと、工場長が本来やるべき仕事に集中できるようにするってことですよね?
だから、ほかの人ができることを工場長にやらせない仕組みが必要なのかも……。
いいね!ジムリン、わかってきているね!
コーさんに褒められて、少し元気が出てきました(T-T) よし、もう一度、工場長のために何ができるか考えてみよう!工場長に集中するタスクを仕組み化して流れを改善しよう
ボクは気をとりなおして、コーさんに手伝ってもらいながら、工場長に集中するタスクを整理するところから始めました。工場長に集中するタスクを可視化してみる
ジムリン、まず「工場長がどんな仕事に追われているか」を洗い出してみよう。
はい!
とはいえ、「工場長がボトルネックだ」と伝えて怒られてしまったボク。 正直、工場長に直接話しかける勇気が出ません……(T-T) 気まずさを抱えたまま現場に顔を出すと、作業員の方から声をかけられました。 「ジムリンさん、昨日、工場長に何か言ったの?」 ボクは正直にすべてを話しました。 すると、作業員の方は苦笑しながら話し始めたんです。 「ああ、それは……。 前にシステムを入れたとき、工場長が全部入力作業を背負わされて大変だったんだよ。 社長の鶴の一声でね。システムを入れたら工場長の仕事も減るだろう!って。 でも、現場のことがわかってる人じゃないと扱えないからって、浸透するまでは工場長が管理することになって。 ほら、うちってITに強い人いないからさ。 で、結局工場長の仕事が増えただけで、そんなに効率化されてないんだよね……。 うちらも何かできないかな?と思ったんだけど、今の工場長って話しかけるだけでも負担そうじゃない? 会議の時間すら惜しいんだと思うよ。 仕事が減るといいながら結局負担が増えちゃったから、工場長からするとまた余計な提案をするのかと思ったのかもしれないね。」 それを聞いて、ボクはハッとしました。 工場長にタスクが集中していることなんて、みんなわかっていたんだ。 そしてきっと、これまでも社長から何とかしろって言われてきている。 そのたびに工場長が振り回されて、負担が増えてきた。 そういう経緯があったんです。 それなのにボクは……(T-T) ボクはもっと工場長が感じている負担を知るため、あらためて工場長の1日の仕事を追いかけることにしました。 朝から観察していると、工場長のもとには次々と人が訪れます。- 営業からの進捗確認電話
- 作業員からの判断依頼
- 購買からの在庫確認
- 社長からの納期調整の相談
情報を可視化すれば、工場長を通さなくて済む
観察を終えて気づいたのですが、工場長が対応していた問い合わせの多くは単なる「情報の伝達」だったんです。 「工場長を経由しなくても全員が必要な情報にアクセスできれば、工場長は本来の仕事に集中できるはず……!」 進捗や納期をシステムで共有すれば、営業も現場も直接確認できます。 ただ、このシステムに対して抵抗があるみたいなので、導入時のサポートが必要そうです。 「工場長が持っている情報を、みんなが見られるようにすればいいんだ!」必要なのは情報の伝達をスムーズにする仕組み
ボクは確信しました。 「結局、工場長の負担は「情報を抱えていること」から生まれているんだ。」 だからこそ「進捗や納期をだれでも見られる仕組み」が必要です。 これまでもシステム化には挑戦しようとしていたけれど、すでにタスクが溢れている工場長が中心だから逆に負担になっていたはずです。 そこで、ボクの出番です! ボクが、システムを作る中心に立てば工場長に新たな負担を与えず、現場の仕組みを少しずつ変えられるはず……! そうコーさんに報告すると、ニコニコしながら言ってくれました。よく気づいたね、ジムリン。
やってごらん!
はい!ボク、挑戦します!
こうして、最初のアプリづくりに挑むことになりました。【教訓】ボトルネックの本領を発揮させるとは「本来の業務に集中できる環境を整える」こと
今回、ボクが学んだことをまとめます。・工場のスループットはボトルネックに左右される ・ボトルネックは弱点ではなく、工場を支える貴重なリソース ・改善の第一歩は、ボトルネックが本来の業務に集中できるよう仕組みや環境を整えること
ボトルネックというと、「ボトルネックになっている人や機械が悪い」「排除しよう!」と思われがちです。 でも、ボトルネックになっている部分こそ、工場にとって重要なリソースなんです。 だから、その人や機械が本領を発揮できる仕組みを作ることこそが、工場の流れをよくすることにつながるんですね。 工場長が本領を発揮できるように、のびのび働けるようにするんだ! その想いを胸に、ボクは初めての仕組み作りに挑戦します!(^^)! " ["post_title"]=> string(99) "工場のボトルネックを特定したら「本領を発揮させる方法」を考えよう!" ["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(18) "bottleneck-release" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2025-12-26 15:57:57" ["post_modified_gmt"]=> string(19) "2025-12-26 06:57:57" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(45) "https://adiem.jp/?post_type=blog&p=15542" ["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)#4314 (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で受注データを管理するようになりました。 関連レコード一覧で、受注履歴を表示できるようにしたんです。 こちらが受注履歴の関連レコード一覧です。
受注データがズラッと並んで、一覧で見られるようになりました。
でも、月次報告のときに困ることがありまして(;'∀')
データを分析したいのに、条件で絞り込んで集計できない...…!
ボクは月次報告のために、各担当者の営業成績を分析しなくちゃいけないんです。 「斉田さん担当の売上はいくらかな?」 「山下さんの売上は?」 関連レコード一覧を見れば、全体の受注データは見えます。 でも、現状だと「斉田さん担当だけ」「山下さん担当だけ」で絞り込んだ合計がわからないんです。 仕方なく、別のアプリ(受注管理アプリ)を開いて、フィルタで「営業担当=斉田文子」に絞り込んで、レポート機能で集計して...…という流れでやっています。 これを担当者分、全部やるわけです。 関連レコード一覧にはデータが全部あるんだから、条件を指定して集計できたらいいのに...…(-_-;) なんとかならへんかな、これ。 (あ、またテンパって関西弁が出ちゃった)関連レコード集計プラグインの「条件付き集計(SUMIF)」なら、複数の切り口で集計・分析できる!
ジムリン、また困ってるね。
関連レコード一覧を条件で絞り込んで集計したいんでしょ?
コーさん!そうなんです。
全部じゃなくて、「斉田さん担当だけ」とか「山下さん担当だけ」とか、条件を指定して集計したいんです。
何かいい方法ないですか?
それなら、関連レコード集計プラグインの「条件付き集計」機能を使ってみたらどうかな?
条件付き集計……?
ExcelでいうSUMIF関数みたいなもので、条件を指定して集計できる機能だよ。
ジムリンがいうように、「斉田さん担当だけ」とか「山下さん担当だけ」といった条件を絞り込んで集計できるんだ!
ドンピシャの機能じゃないですか!
しかも、複数の切り口で同時に集計できるから、多角的な分析も可能だよ。
集計結果は自動的にフィールドに保存されるから、画面を開くだけですぐに確認できるね。
それはすごい!さっそく使ってみたいです!
関連レコード集計プラグインの条件付き集計機能を使ってみた【製造業の場合】
コーさんのレクチャーを受けて、ボクは実際に関連レコード集計プラグインの条件付き集計機能を使ってみることにしました。 ここからは、実際にどう設定して、どう変わったのかをご紹介します!条件で絞り込んだ集計も、別アプリを開かずに確認できる
まず、一番知りたかった「営業担当別の売上」を設定しました。 設定はこんな感じです。1.工数実績管理アプリに「営業斉藤_売上」フィールドを作成 2.プラグインの設定で条件を指定(例:営業担当=斉田文子) 3.集計対象:受注額 4.集計方法:合計
すると、このように自動で集計されるようになりました!
もう別アプリを開いてフィルタ→集計する必要はありません!
画面を開くだけで、斉田さんと山下さんの売上実績を確認できるようになりました(^^)
コーさん、すごいです!
集計のために、もう別アプリを開かなくていいんですね!
これでジムリンの課題はクリアだね!
複数の条件を同時に設定できるから、比較がしやすい
実は、関連レコード集計プラグインは、1つの関連レコード一覧に対して、何個でも条件付き集計を設定できるみたいなんです。 今回は「営業担当別」で2つ設定しましたが、ほかにもいろんな切り口で設定できます。 たとえば、受注履歴に対して- 営業担当別(斉田、山下、佐藤...)
- 案件カテゴリ別(案件A、案件B、案件C...)
- 取引先別(特定の重要顧客ごと)
- 受注日別(今月、先月、今期...)
- 受注額別(100万円以上、50万円以上...)
つまり、1つの画面でいろんな切り口の集計が一度に見られるってことですか?
そう!営業成績も案件傾向も顧客別売上も、全部まとめて確認できるんだ。
月次報告で「あれも見たい、これも見たい」ってときに、いちいち別アプリを開いてフィルタをかける必要がなくなるよ。
それはすっごく助かります!
分析の幅もぐっと広がりそうですね。
集計結果は自動保存されるから、いつでも確認できる
プラグインで設定した条件付き集計は、レコードを開くたびに自動的に計算されて保存されます。 つまり、受注データが追加されたり更新されたりしても、常に最新の集計結果が表示されるんです。これなら、いつでも最新の営業成績が確認できますね!
しかも、集計結果はフィールドに保存されるから、レポート機能やグラフ機能でさらに可視化することもできるよ。
あらゆる業種で活躍!関連レコード集計プラグインの条件付き集計ユースケース
関連レコード集計プラグインの条件付き集計機能を使ってみて、ボクはふと思いました。これって、製造業だけじゃなくてほかの業種でも応用できますよね?
もちろん!いくつかユースケースを紹介するね。
ということで、コーさんが業界別のユースケースを紹介してくれました。小売業:顧客別の「今月の購入金額」を即座に確認
・顧客管理アプリに購入履歴を関連レコードで表示 ・「購入日が今月」という条件で合計購入金額を自動集計 ・接客中に「今月は既に〇〇円ご購入いただいてます」と即答できる
条件を「購入日が今月」にするだけで、今月分だけの集計ができるんだ。
不動産業:物件別の「成約済み」案件の合計契約金額
・物件管理アプリに商談履歴を関連レコードで表示 ・「ステータスが成約」という条件で契約金額を集計 ・物件ごとの収益性を即座に把握
成約済み案件だけを集計できるから、実績管理がしやすくなるね。
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" } [4]=> object(WP_Post)#4318 (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) "そうだね! 各要素には優先度があるよ。 以下はなるべくマストで書き出してみて! ・誰が(Who) ・いつ(When) ・何を(What) ・なぜ(Why)
本当ですね! いきなりアプリを作り始めていたら、あとで「このフローも必要だった!」とやり直しになっていたかもしれません。
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"
}
[6]=>
object(WP_Post)#4322 (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" } [7]=> object(WP_Post)#4323 (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) "
こんにちは、東京の旅行代理店から地元の製造業に総務担当として転職したジムリンです!
製造業未経験で上司からいきなり「kintoneで生産管理・工程管理システムを作ってみて!」なんていわれたら、みなさんは何から手をつけますか?
ボクの場合、製造業向けのサンプルアプリを探してつなぎ合わせようとしたんですけど、ある問題が、……。
今回は、ボクの前に立ちはだかった「最初の壁」と、ある方に教えてもらった「システム設計で最初にやるべきこと」をお話しします。
生産管理・工程管理システムに必要なアプリって何!?
「とりあえず何か形にしないと!」と思ったボクは、「kintone 製造業 サンプルアプリ」で調べました。 すると、無料で使えるアプリがいっぱいあるじゃないですか!
引用:kintone公式サイト
ウチの工場に必要なアプリをこのなかから見繕って、つなぎ合わせれば生産管理システムができると思ったんです。
ところが、いっぱいありすぎて、どれを使ったらいいかわからへん!
ウチの工場に必要なアプリってどれやねん!
という状況に陥りまして……。
そもそもうちの生産工程ってどうなってるの?
サンプルアプリを見ていくと、工程ごとにアプリを入れるのが良さそうだと思いましたが、ここでも壁に衝突します。 そもそも、ウチの工場の工程ってどうなっているのかがわからなかったんです! 工程がわからなければ、必要なアプリも決められないと思いませんか? そこで、工場に行ってみたんですが、どういう名前の工程がどのようにつながっているのかって、見てもわからないんです。 工場で働くみんなは忙しそうで声を掛けることもできず、ボクはいったん事務所に戻りました。 入社半年も経つのに「ウチの工場ってどういう工程があるんですか?」なんて聞いたら、「こいつ半年間何してたんだ?」って思われそうじゃないですか。 実際、そんなこと言う人はいないんですけど。 いろいろ考えた結果、自力で何とかしなくては!と思い、再び机に向かったんです。まずは工場全体の業務フロー図を描こう!
ボクが目を閉じてしばらく悩んでいると、どこからともなく声が聞こえてきました……。 「サンプルアプリをつなぎ合わせてもうまくいかないよ!」って。 考えすぎるあまり、寝ちゃったんだ、これは夢だって思いました。 「いけない、起きなきゃ」と思って目を開けると目の前にいたんです。あの方が。 そして言いました。 「わたしは古くからこの工場に住み着いている妖精、コー・ジョー。 工場のことならなんでも知っているよ!」 工場に妖精っているんですね。 もうボクは、本当にどうしたらいいのかわからなかったので、藁にもすがる思いでコーさんに助けを求めました。 「ボクはジムリンっていいます!コーさんは先輩ですよね? ボク、工場のことなにもわかっていないのに、生産管理システムを作らなくちゃいけなくて……。」 結論、ボクはコーさんから大きなヒントをもらいました。 ここからは、コーさんとボクのやりとりを忠実に再現しますね。 ボク 「サンプルアプリをつなぎ合わせる方法はダメなんですか? イチからアプリを作ると時間がかかりそうだし、あるモノを使ったほうが効率的だと思うんですが。」 コー・ジョー 「サンプルアプリをつなぎ合わせるやり方では、自社に最適化された生産管理システムは作れないよ。 たしかに、生産管理システムっぽい形にはなるけれど、自社のフローや業務に合っていなければすぐに使えなくなるね。 だから、まずは工場全体の業務フロー図を描いて、自社の課題から本当に必要な機能を見つけないと!」 あまり理解できていないボクに、コーさんは詳しく説明を始めました。システム設計は「全体最適」で考えよう
コー・ジョー 「ジムリンの考え方は部分最適というよ。 最初に小さなアプリに注目すると、たしかに目の前の工程は改善されるかもしれないけれど、工場全体の流れの改善につながらないことがあるんだ。」 ボク 「工場全体の流れってどういうことですか?生産管理システムとどう関係があるんですか?」 コー・ジョー 「材料を仕入れるところからお客さまに届けるまでの一連の流れが「工場全体の流れ」だとしよう。 例えば、製造の工程が機械の不具合で止まってしまうと、どうなると思う?」 ボク 「あ、納期どおりに納品できなくなるかも……。」 コー・ジョー 「そう、だからそういったトラブルが起こらないように、また起こったときすぐに解決できるように、仕入情報や生産スケジュールなんかを管理するのが生産管理システムの役割になるよね。」 ボク 「なるほど、生産管理システムの役割って考えてなかったです。 話を戻しますが、なぜ部分最適で考えるとダメなんでしょうか?」 コー・ジョー 「工場全体を川に置き換えて考えてみよう。 必要そうなアプリを1つずつ作ると、それぞれが島のように点在する。 島のなかだけは便利になるかもしれないけれど、川の流れはどう?スピードは?」 ボク 「変わりませんね……。」 コー・ジョー 「そう!つまり工場全体の流れはちっとも変わらない。 これが部分最適なんだ。 例えば、受注管理や在庫管理など全部の工程をいっぺんに最適化しようとしたらどうなるかな? 各工程で要件を洗い出して、担当ごとにアプリを作って、細かい仕様を決めて......とやっているうちに、膨大な時間と労力がかかってしまう。 しかも、工場全体の流れは変わらない。 結局、全体の流れを意識せずにバラバラにアプリを作っても、結局は遠回りになるんだよ。 サンプルアプリを使ったとしても同じことだよね? だからこそ全体最適で考える必要があるんだ!」大事なのは工場全体の「流れ」を見ること
ボク 「全体最適ってどういうことですか?さっきの話だと、川を見るってことですか? コー・ジョー 「そう、川に注目するんだ。 島を増やすことでも橋でつなぐことでもなく、川の流れそのものを良くする。 これはTOC理論と呼ばれる考え方に基づいていてね。 工場全体の流れを見たあとで、その流れをせき止めている部分(ボトルネック)を見つけ、そこを改善していくことがポイントなんだ。」 ボク 「TOC理論っていうのがあるんですね……。全然知らなかったです。 つまり、 流れを止めている場所を見極めて、集中的に改善するためのシステムを作ることで工場全体の流れが変わるってことですね!?」 コー・ジョー 「そう、全体を俯瞰して流れを意識する。 そうやって全体最適の視点で生産管理システムを設計すると、結果につながるんだ!」工場全体の業務フローを描いてみよう!
ボク 「納得できました! TOC理論なるものがあるということは、製造業の人たちは部分最適で業務改善を図ろうとしてきて失敗をしてきたんでしょうね。 それで、全体最適でシステム設計をするには、何から始めるんでしょうか?」 コー・ジョー 「まずは、工場全体の流れを把握するために、業務フロー図を描いてみよう!」業務フローは工場の入口から出口までを「ざっくり」描こう
ボク 「工場全体の業務って、どこからどこまで描けばいいんですか? 。」 コー・ジョー 「いい質問だね。生産管理に焦点をあてるなら、まずは工場の入口から出口までくらいで大丈夫! 受注から出荷までを一枚に描いてみれば十分だよ。 描いたあとで『ここは順番が違うよ』『この工程が抜けているよ』と周りにフィードバックをもらって修正すればいいので、まずはざっくり描いてみよう。」 ボク 「なるほど...。上流から下流までの川を描くイメージですね。 魚や石まで細かく描く必要はないと。」 コー・ジョー「そのとおり!」業務フローを描くときは付箋・Excel・ITツールを使おう
コー・ジョー 「業務フロー図を描くときはツールを使おうね。大きく分けると3つあるよ。- 付箋と模造紙を使う
- 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" } [8]=> object(WP_Post)#4324 (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 Base URL:例
- 新規チャットを作成し、ツールに kintone が見えればOK
- 「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-recordskintone-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アプリに対する操作が行える
残業で日報を読む日々を「kintone AIラボ」で解決しよう
毎日kintoneに送られてくる日報や業務報告を、すべて読み込むだけで多くの時間を奪われていないでしょうか?数値データはグラフで一目で把握できます。しかし、現場の「コメント」に埋もれているトラブルの予兆や不満は見落としがちです。 このようなデータを「全部詳しく読もう」とすると、他の仕事が回りません。かといって「ざっと目を通すだけ」では、重要な情報を見逃すリスクも… そんな悩みを解決してくれるのが、kintoneの標準機能「レコード一覧分析AI」です。本記事では、「レコード一覧分析AI」の設定手順から現場ですぐに役立つ具体的な活用法までを解説します。
設定1分の「レコード一覧分析AI」でデータを読む作業を効率化できる
レコード一覧分析AIとは、一覧画面に表示されている複数のレコード情報を読み込み、要約・分析してくれる機能です。「AI導入」と聞くと大掛かりに感じるかもしれませんが、追加費用は不要であり、今ある環境ですぐに使えます。
ただし、「AIが高度な経営コンサルティングをしてくれる」と期待すると失敗します。このAIの本質は「優秀な書記係」です。大量のテキストデータを高速で読み込み、指定された通りにまとめる能力に長けています。高度な分析や提案を求めるのではなく、「大量の文字を読む苦行」を代行させる道具として活用することが成功の鍵です。
検索したいことを入れるだけでAIがデータを要約
レコード一覧分析AIは、生成AI技術を活用してkintoneのレコードデータを読み込み、要約や分析を行います。
従来のkintoneの集計機能は、数値データをグラフ化することには優れていました。しかし、日報やコメント欄といったテキストデータは、人が一つ一つ目を通すしかありませんでした。
生成AIは、自然言語処理(NLP)技術によって大量のテキストを瞬時に読み込み、文脈を理解した上でユーザーの質問に回答する能力を持ちます。従来のキーワード検索では拾えなかった「意味的に関連する情報」も、AIが文章の意図を解釈して抽出できます。
具体的には、AIが各レコードのテキストを意味のまとまり(トークン)に分解し、単語間の関係性をベクトル化して分析します。この処理により、100件の日報から例えば「安全管理上の懸念」に該当する記述を、表現の違いを超えて網羅的に抽出できます。また、月間の報告から「頻出する問題」を統計的に分析し、ランキング化することも可能です。人間が数時間かかる分析を、AIは数秒で実行できます。
本来の目的は「データを読むこと」ではなく、「データから得られた傾向をもとに対策を議論すること」です。AIが「読む作業」を代行することで、本来注力すべき「考える時間」を確保できます。
【手順】設定は「スマホの通知変更」くらい簡単
レコード一覧分析AIの設定は、拍子抜けするほど簡単です。以下の手順で完了します。 まず、kintoneシステム管理画面を開きます。次に、「kintone AI管理」の設定項目を探してください。
ここから各種AIの有効化を設定できるので、「レコード一覧分析AI」にチェックを付けます。そして直下にある「設定」を押します。
設定画面でAIを利用できるアプリとユーザーを指定します。
設定にかかる時間は1~2分程度です。スマホの通知設定を変えるくらいの感覚で、誰でもすぐに使い始められます。
より詳しい手順はkintoneの公式ページをご覧ください。
【実践】「なんだ、使えない」と諦めないための指示出しのコツ
これで分析AIが使えるようになり、データを読む手間が省ける…と思ったことでしょう。しかし、AI初心者がハマりがちな落とし穴が「指示の出し方」です。分析AIには言葉で指示を出す必要がありますが、このとき多くの初心者が「要約して」「傾向を教えて」とだけ指示してしまいがちです。 「全体的に順調です」「報告が○件あります」といった当たり障りのない回答や、平均値しか返ってこないため、「やっぱりAIなんてこんなものか」と諦めてしまうケースが多く見られます。
しかし、これは明確に原因があります。それはAIに「丸投げ」をしているから。丸投げをやめて「どこを(フィールド名)」「どういう視点で(観点)」「どう出力するか(構造)」を明確に指示することで、AIは適切な回答をしてくれるようになるのです。
効果的なプロンプト指定(フィールド・観点・構造)
AIに「いい感じにまとめて」は通用しません。「優秀な書記係」に指示を出すつもりで、具体的にオーダーする必要があります。 効果的なプロンプトには、3つの要素が必要です。
1つ目は「フィールド」です。どの項目を見てほしいかを明示します。例えば、「『特記事項』と『懸念点』を見て」のように指定します。
2つ目は「観点」です。どういう視点で分析するかを指定します。例えば、「『安全管理』の観点で」のように視座を与えます。
3つ目は「構造」です。どう出力するかを指定します。例えば、「ポジティブ要素とネガティブ要素に分けて箇条書きで」のように出力形式を明確にします。
この3要素を組み合わせることで、AIは期待通りの回答を返してくれます。
【コピペOK】製造現場ですぐ使えるプロンプト例
実際の製造現場で使えるプロンプト例を3つ紹介します。そのままコピーして使えます。 1つ目は、日報要約です。「本日の『作業内容』と『備考』から、進捗の遅れにつながる要因を3つ箇条書きで挙げて」と指示します。これにより、複数の日報から遅延リスクを素早く抽出できます。対象レコードの「作業内容」と「備考」を読み取り、 進捗の遅れにつながる要因を抽出してください。 ・要因は最大3つまでとする ・各要因は簡潔な名詞句で表現する ・同じ内容は統合する ・推測ではなく、記載内容に基づいて整理する 出力は箇条書きで示してください。2つ目は、トラブル分析です。「今月の『不適合報告』を読み込み、発生原因として最も多い要素をランキング形式で表示して」と指示します。傾向が一目で把握でき、再発防止策の優先順位が明確になります。
今月分のレコードに含まれる「不適合報告」を分析し、 発生原因として多い要素を整理してください。 ・原因は内容の近いものをまとめる ・出現頻度が多い順に並べる ・上位からランキング形式で表示する ・各順位には簡潔な原因名のみを記載する 出力はランキング形式で示してください。3つ目は、ヒヤリハット分析です。「『ヒヤリハット内容』から、重大事故につながる恐れのある記述をピックアップして」と指示します。埋もれていた危険な予兆を見逃さず、事前対策につなげられます。
各レコードの「ヒヤリハット内容」を確認し、 重大事故につながる恐れがある記述を抽出してください。 ・人身事故や設備損傷につながる可能性を重視する ・注意喚起として有用な内容を優先する ・原文の表現をできるだけ保ったまま抜き出す 出力は箇条書きで示してください。これらのプロンプトを参考に、自社のルールやフィールドに合わせてカスタマイズしてみてください。
kintoneを「記録置き場」から「意思決定ツール」へ
レコード一覧分析AIは、設定1分で使える「優秀な書記係」です。まずは機能をONにし、溜まっている日報データで「集計」ボタンを押してみてください。具体的なプロンプトを入力すれば、今まで見えていなかった現場の予兆が浮かび上がってきます。 AIに「要約」を任せることで、空いた時間を現場との「未来の対策」を話す時間に使えます。kintoneを単なる記録置き場から、意思決定を支援するツールへと変えていきましょう。
最後に
株式会社アディエムでは、kintone × 生成AIで日々の業務改善に取り組んでいます。
今回ご紹介したようなワークフローの他にも、お客様の業務に合った改善をご提案させて頂きます。
無料相談も実施しておりますので、お気軽にお問い合わせ頂ければ幸いです。
お問い合わせはこちら
"
["post_title"]=>
string(107) "kintone「レコード一覧分析AI」の効果的な使い方!AIでデータ整理を効率化しよう"
["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(17) "kintone-record-ai"
["to_ping"]=>
string(0) ""
["pinged"]=>
string(0) ""
["post_modified"]=>
string(19) "2026-01-11 17:38:11"
["post_modified_gmt"]=>
string(19) "2026-01-11 08:38:11"
["post_content_filtered"]=>
string(0) ""
["post_parent"]=>
int(0)
["guid"]=>
string(45) "https://adiem.jp/?post_type=blog&p=15559"
["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(21)
["max_num_pages"]=>
int(3)
["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(true)
["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) "df2cc64bd9035f454fa8d823e6cb9837"
["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:5ea7bec04691155d38c398a527278549:0.43533500 17701821660.51794000 1770182166"
}
-->
他のタグから探す
- 全てのタグ
- データ保護
- 生産スケジューラ
- Box連携プラグイン
- MCPサーバー
- GROW工程管理
- ボトルネック改善
- Claude Desktop
- CybozuDays
- セキュリティ
- 生成AI
- 工程管理システム
- Box
- draw.io
- ボトルネック
- プラグイン
- ダイアグラム図
- TOC理論
- ファイル管理
- 添付ファイル
- TOC研修
- ファイル共有
- OCR
- ジムリン
- 自動化
- 関連レコード集計プラグイン
- 会社情報調査
- 関連レコード一覧
- kintone
- kintoneプラグイン
- 関連レコード一覧集計
- もしもシリーズ
- 独自ルックアップ
- アプリ設計
- 生産管理システム
- ルックアップ
- ユースケース図
- kintoneアプリ
- セミオーダー型アプリ
- TOC
- バックアップ
- 製造業
- DBR
- n8n
- 展示会
- バッファ

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











