- ホーム
- 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" } [2]=> object(WP_Post)#1061 (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" } [3]=> object(WP_Post)#4314 (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つのポイント
描いてみました！ こんな感じでどうですか？
そうだね！ 各要素には優先度があるよ。 以下はなるべくマストで書き出してみて！ ・誰が（Who） ・いつ（When） ・何を（What） ・なぜ（Why）
本当ですね！ いきなりアプリを作り始めていたら、あとで「このフローも必要だった！」とやり直しになっていたかもしれません。
はじめに：バックアップの"手作業"を卒業しよう
製造業では品質記録、検査データ、製造履歴、図面など、失ってはならないデータがkintoneに日々蓄積されます。 ISO認証や監査対応では「データの保管体制」を問われますが、手動バックアップは抜け漏れの温床です。
「毎日バックアップを取らないと…」と分かっていても、日々の業務に追われて後回しになる。 これは製造業に限らず、多くのkintoneユーザーが抱える課題です。
本記事では、n8nを使ってkintoneの全データ（添付ファイル含む）を毎朝3時に自動バックアップ→Google Driveへアップロード→結果をkintoneに記録までを一気通貫で実行する仕組みを解説します。
全体アーキテクチャ（概要）
これで解決できること
- 手作業ゼロ：一度設定すれば、毎朝勝手に動き続ける
- 抜け漏れゼロ：対象アプリを登録するだけで、全アプリを自動処理
- 添付ファイルも完全保存：図面やPDFも漏れなくバックアップ
- 監査対応：実行履歴がkintoneに残り、「いつ・何を・どうした」が証明可能
- 迅速な復旧：Google Drive上で世代管理でき、任意の日付に戻せる
使う道具と役割
kintone：データのハブと実行履歴の保管場所
今回のワークフローでは、バックアップ対象管理アプリ、結果保存アプリを作成し利用しています。n8n：ワークフローを配線
定時実行トリガー、kintone REST APIの実行、ループ処理による一括処理、サーバーコマンドの実行、GoogleDriveへの連携をしています。cli-kintone：kintoneの公式コマンドラインツール
アプリのデータをCSV出力、添付ファイルの保存など、バックアップに必要な作業を行う際に利用しています。Google Drive：クラウドストレージ
今回の例では、バックアップの保存先にGoogle Driveを使用しています。実装
1) 定期実行と初期設定
Triggerノードを「Schedule Trigger」にし、毎朝3時に実行するよう設定。
- Trigger interval：Days
- Days Between Triggers：1
- Trigger at Hour：3am
- Trigger at Minute：0
2)定数の登録
後続のノードで利用する値をここで定義している。
以下の内容はサンプルです。
- バックアップ先ディレクトリ：
./kintone_backup （./kintone_backup/[App_ID]/となるように設計） ログディレクトリ：./logGoogle DriveフォルダID- タイムゾーンとタイムスタンプ（
Asia/Tokyoタイムゾーンでyyyy-LL-dd形式）
3) バックアップ対象の取得と分岐
n8nの「HTTP Request」ノードを使い、バックアップ対象管理アプリから対象リストを取得します。
取得件数が0件の場合は、その旨をエラーとしてログに記載し終了。
4) ループ処理（各アプリごとに実行）
取得したアプリを、1件ずつループ処理します。
行っている処理の内容は以下の通り。
- バックアップの一時保存ディレクトリの存在チェック （./kintone-backup/[APP_ID]/が無ければ作成）
- レコードデータ（CSV）をエクスポート
- バックアップ結果をログ出力
- 添付ファイルをダウンロード
5) ログのまとめと圧縮
ループの完了後、それぞれのバックアップ結果ログを取りまとめ、後ほどログ保存時に適した形に整形する。
また、サーバーコマンドを実行し（tar圧縮）、バックアップディレクトリを一括圧縮する。
6) Google Driveへアップロード
「readFile」ノードを使い、ファイルをバイナリとして読み込む。
「Uploade File」ノードを使い、Google Driveへアップロード。
※Google Driveのノードは標準で搭載されているが、認証情報の設定が必要。
7) 結果ログを保存
アップロード結果のログと、アプリバックアップのログを統合し、文章として整形する。
最後に「HTTP Requestノード」を使ってkintoneへ結果を保存する。
運用設計のヒント
ログと監査のための記録
- n8nの実行IDをkintoneに残すと、失敗時の再実行や調査が容易
- 処理ログに各アプリの成功/失敗を記録し、どこで止まったか可視化
- バックアップ実施の証跡として監査時に提示可能
保存先の世代管理
- 日次でファイル名が変わるため、自然に世代管理される
- 古いファイルを削除する方法を検討する
容量とコストの試算
- アプリ量、レコード数、添付ファイルの種類によって容量が変わる
- Google Workspace Business Standard契約で２TBまで拡張可能
よくある質問
Q. cli-kintone のインストール方法は？
kintoneの公式サイトからダウンロード可能です。 n8nが動作するサーバーにインストールし、PATHを通しておく必要があります。Q. ゲストスペース内のアプリもバックアップできる？
できます。--guest-space-id オプションにスペースIDを指定してください。
ワークフローでは、対象アプリ管理にスペースIDを登録しておけば自動で対応します。
Q. 複数ドメインのkintoneをバックアップしたい
A. ドメインごとにワークフローを分けるか、Define ノードでドメインリストを定義し、外側でループさせる設計にします。Q. バックアップからの復旧方法は？
kintoneの公式サイトからダウンロード可能です。 n8nが動作するサーバーにインストールし、PATHを通しておく必要がありますA. tar.gzを展開し、cli-kintone record import コマンドで各アプリにインポートします。
添付ファイルも --attachments-dir で指定して復元可能です。
まとめ
- Schedule Trigger → 対象取得 → ループ処理 → 圧縮 → Google Drive → 結果記録 の一筆書きでバックアップを自動化
- エラー時は結果をkintoneに記録し、失敗箇所を可視化
- まずは対象アプリを5～10個に絞り、実行ログの確認と復旧テストを行ってから本番運用へ
最後に
株式会社アディエムでは、kintone × 生成AIで日々の業務改善に取り組んでいます。
今回ご紹介したようなワークフローの他にも、お客様の業務に合った改善をご提案させて頂きます。
無料相談も行なっておりますので、お気軽にお問い合わせ頂ければ幸いです。
お問い合わせはこちら"
["post_title"]=>
string(88) "kintoneのアプリバックアップを自動化｜n8nで製造業向けデータ保護"
["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(23) "kintone-n8n-auto-backup"
["to_ping"]=>
string(0) ""
["pinged"]=>
string(0) ""
["post_modified"]=>
string(19) "2025-12-21 09:28:14"
["post_modified_gmt"]=>
string(19) "2025-12-21 00:28:14"
["post_content_filtered"]=>
string(0) ""
["post_parent"]=>
int(0)
["guid"]=>
string(45) "https://adiem.jp/?post_type=blog&p=15077"
["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)#4439 (24) {
["ID"]=>
int(15606)
["post_author"]=>
string(2) "14"
["post_date"]=>
string(19) "2025-01-06 12:00:25"
["post_date_gmt"]=>
string(19) "2025-01-06 03:00:25"
["post_content"]=>
string(11010) "
こんにちは、ジムリンです！
前回、コーさんから「ボトルネックの本領を発揮させる」という考え方を教わりました。
工場長が本来の仕事に集中できるよう、情報共有の仕組みを作ろうと決意したボク。
夜遅くまで試行錯誤して、ついに試作アプリが完成しました！
「これで工場長を助けられる！」と期待を胸に、みんなに見せて回ったのですが……。
今回は、ボクが直面した「システム開発の壁」についてお話しします。
「工場長を助けるアプリを作る！」ボクの決意
前回、「ボトルネックの本領を発揮させる」という考え方を教わった結果、工場長が本来の仕事に集中できるように、環境を整えることが大切なんだとわかりました。そうだ、工場長への問い合わせを減らせば、工場長の負担が軽くなる！
進捗や納期をだれでも見られるようにすれば、工場長への電話が減るはず！
進捗・納期共有アプリを作ろう！
ボクは決意を固めました。 それから毎晩、会社に残って試行錯誤を繰り返しました。 kintoneでアプリを作るのは初めてじゃないけど、「工場長を助けるため」と思うと、いつも以上に気合が入ります。 営業が進捗を確認できるフィールド、納期が一目で分かる一覧画面、検索機能……。 「工場長に電話しなくても、ここを見ればわかる！」 そんなアプリを目指して、何度も画面を作り直しました。 そして数日後、ついに試作品が完成！ 「これで工場長を助けられる！」 期待と自信に満ち溢れたボクは、さっそくみんなに見せて回ることにしました。自信作を見せて回ったら……予想外の反応の連続
自信のあったボクは、きっとみんな喜んでくれると思っていたんです。 でも、みんなの反応は思っていたものとは違いました。同僚の反応「Excelの方が速いよね？」
まずは身近な営業の同僚に見てもらおうと思い、ボクは試作品の画面を開いて声をかけました。ねえねえ、進捗確認アプリ作ってみたんだけど、見てくれる？
「へー、こんなの作ったんだ」 同僚は興味を示してくれました。これで工場長に電話しなくても、進捗が確認できるんだよ！
ボクは自信満々に説明します。 でも、同僚は画面を見ながら首を傾げてこう言ったんです。 「うーん、でもExcelの方が速くない？」 固まるボク。 「いちいちkintone開いて、検索して……って、手間じゃない？」 「今はExcelで管理してるから、それ見た方が早い気がする。」 「それに、この入力項目、面倒くさそうだし。」 ボクは少し戸惑いました。ま、まだ試作品だから。これから改善していくよ！
思わず言い訳してしまいます。 「まあ、頑張ってね」 同僚はそう言って、自分の仕事に戻っていきました。 （あれ…？思ったよりも反応が良くないな…） ボクの頭に不安がよぎります。上司からの追加要望「もっと機能を増やせない？」
ボクは気を取り直して、上司に試作品を見せに行きました。進捗確認アプリができたので見ていただけますか？
「おお、頑張ったね、ジムリン！」 上司は画面を見て、うれしそうに言ってくれました。これで工場長への問い合わせが減りますよね！
ボクも嬉しくなって説明します。 「うんうん、いいね。でもさ……」 上司が言葉を続けます。 「在庫数も見られたら便利じゃない？」 「あとね、作業指示も出せたら一石二鳥だよね！」 「それと、グラフで可視化できると社長も喜ぶと思うよ。」 「ダッシュボードみたいな画面あると、かっこいいしね！」 次々と追加要望が飛び出してきました。 ボクは慌ててメモ帳に書き留めていきます。 在庫数、作業指示、グラフ、ダッシュボード……。 これ、全部やらないとダメなのかな。 メモ帳がどんどん埋まっていき、不安が募ります。 「うん、じゃあよろしくね！期待してるよ！」 上司は満足そうに言って、会議室へ向かっていきました。 褒められたのは嬉しいけど、こんなにたくさん機能を追加できるかな。 またまたボクの頭を不安がよぎります。購買担当からの厳しい指摘「これ、だれが入力するの？」
次は購買担当の人にも意見を聞いてみようと思い、担当者の席へ向かいました。すみません、進捗確認アプリを作ったんですが、意見を聞かせていただけますか？
「ああ、いいよ。どれどれ……」 購買担当の方は画面を見て、すぐに質問してきました。 「これ、だれが入力するの？」それは、工場の現場の方が…
「現場の人たち？」 購買担当の方の表情が曇ります。 「進捗を入力するのは現場？それとも事務？」 「ただでさえ忙しいのに、入力作業が増えるのは困るんだけど。」あ……それは……。
ボクは言葉に詰まります。 「前のシステム導入のときもさ、結局現場に負担が増えただけだったんだよね。」 「現場の人たちは作業で手一杯なのに、パソコン開いて入力しろって言われても無理だよ！」 厳しい指摘が続きます。 ボクは「はい、考えます……。」としか言えませんでした。 過去のシステム導入失敗の影が、またチラついてきます。 入力の負担なんて、全然考えてなかった。 もしかして、これって失敗？ 不安は大きくなるばかりです。一番聞きたかった声が、聞こえなかった
いろいろな人から意見をもらったけど、どれも厳しい反応ばかり。 でも、一番大切なのは工場長の意見です。工場長に見てもらおう。工場長のために作ったアプリなんだから、きっと喜んでくれるはず！
ボクは工場長のところへ向かいました。工場長、少しお時間いいですか？
進捗確認アプリを作ったんです。
これで社内の工場長への問い合わせが減ると思うんです！
ボクは画面を見せながら説明しました。営業の方が進捗を確認したいときは、このアプリを見れば一目で分かります！
工場長に電話しなくても、必要な情報にアクセスできるんです！
でも、工場長は画面を見つめたまま、何も言いません。 長い沈黙が続きます。 ボクの心臓がドキドキと高鳴ります。 「……そうか。」 やっと返ってきたのは、その一言だけ。 工場長の表情は、どこか不安そうで、ボクが期待していた反応とはまるで違いました。あ、ありがとうございました……。
ボクは力なく工場長の部屋を出ました。 工場長を失望させてしまったかも。不安だけではなく、焦りも出てきました。「ボク、何やってるんだろう…」見失った自分の役割
デスクに戻ったボクは、メモ帳を開きました。 そこには、さっきまでに集まった意見がびっしりと書かれています。 「Excelの方が速い」 「在庫数も見られたら便利」 「作業指示も出せたら」 「グラフで可視化して」 「誰が入力するの？」 「入力負担が増える」 そして、工場長の「……そうか。」という、あの沈黙。 「みんなの期待に応えようとしたのに、うまくいかなかったのかな。」 ボクは頭を抱えました。 第5話で、ボクは「現場の気持ちに寄り添う」という自分のスタイルを見つけたはずでした。 でも今、その自信はどこにもありません。 工場長を助けたかったのに、逆に失望させてしまったかもしれない。 同僚たちも、だれも満足していない。 ボクには無理だったのかな……。 メモ帳を閉じて、ボクは机に突っ伏しました。 完全に自信をなくし、絶望の淵に立つボク。この先、一体どうすればいいんだろう……。
" ["post_title"]=> string(89) "良かれと思って作ったアプリ。「Excelのほうが速い」と言われた日" ["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(20) "kintone-app-vs-excel" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2026-01-05 11:08:58" ["post_modified_gmt"]=> string(19) "2026-01-05 02:08:58" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(45) "https://adiem.jp/?post_type=blog&p=15606" ["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(6) ["current_post"]=> int(-1) ["before_loop"]=> bool(true) ["in_the_loop"]=> bool(false) ["post"]=> object(WP_Post)#4316 (24) { ["ID"]=> int(15550) ["post_author"]=> string(2) "14" ["post_date"]=> string(19) "2025-12-26 12:00:55" ["post_date_gmt"]=> string(19) "2025-12-26 03:00:55" ["post_content"]=> string(5037) "
こんにちは、ジムリンです！
もしも製造業に入社半年の総務担当が「kintoneで生産管理システムを作って！」とお願いされたら、みなさんならどうしますか？
システムも製造業も未経験のボクは、妖精コーさんの助けを借りながらなんとか頑張っています！
本シリーズでは、そんなボクの物語を全9話でお届けします。
業務フロー分析からボトルネック特定、アプリ構築、運用改善まで、ボクと一緒に学んでいきましょう！
第1話「kintoneで生産管理システムを構築せよ！」――総務のジムリンが受けた衝撃の指令
東京の旅行代理店に勤めていたボクは、コロナ禍をきっかけに地元へ帰り、未経験ですが製造業の総務へ転職しました。 入社半年たったある日、上司から「kintoneで生産管理システムを作って！」との指令が下されて……。 システムも製造業も全く未経験のボクは一体どうしたら……？ [clink url="https://adiem.jp/blog/column-series-ep0/"]第2話 kintoneで生産管理・工程管理システムを作るには何から始めるの？小さなアプリから作らない理由
「サンプルアプリをつなぎ合わせればなんとかなるはず！」と思ったボク。 でも突然、妖精コーさんが現れて「それでは部分最適になるよ」と止められてしまいました。 コーさんが教えてくれた「全体最適」って一体なに？ボクにできるのかな……？ [clink url="https://adiem.jp/blog/kintone-production-management-system/"]第3話 工場のボトルネック工程はどこ？人や機械に注目してタスクの滞留点を見つけよう
コーさんに教わって業務フロー図を描いたボク。「よし、工程ごとにアプリを作ろう！」と意気込みました。 でもまたコーさんに「まずボトルネック工程を見つけないと」と言われて……。 ボトルネックって一体どうやって見つけるの？その理論と方法に迫ります。 [clink url="https://adiem.jp/blog/factory-bottlenecks-how-to-find-them/"]第4話 課題が多すぎるときはどうする？ 全体最適の視点で工場の「真のボトルネック」を導き出そう
現場ヒアリングをしたら、不満が次々と出てきて頭を抱えてしまったボク。
課題が山積みのとき、一体どうやって優先順位をつければいいの？
コーさんが教えてくれた「スループットの視点」とは？真のボトルネックを見極める方法に迫ります。
