「ここが変だよカスタマイン！11選」に贈るアンサーブログ - アールスリーインスティテュート

公開日：2025-12-20

こんにちは、金春です。

このブログは、カスタマインアドベントカレンダーの12月20日分として掲載しています。

何書こうかな？？？

さて、今年は何書こうか悩んだんですが、12月9日の村元さんの記事がとってもよかったので、その記事に対するアンサーとして記事を書くことにしました。我々が何を考えてカスタマインの機能を取捨選択しているかを少しだけお伝えできれば幸いです。

では、1つずつみていきましょう！

アンサー

①「他のアクションの実行が完了したとき」でなんでアクション複数選択できるの？

はい、これ複数選択可能です。

元記事では複数選択するとエラーになったとありますが、それはたぶん何か前提条件を満たせていないです。不明な点あればチャットサポートで聞いてください。

で、なぜ複数選択可能なのか？ですが、端的に言うと「そうしたくなるシチュエーションがあるから」です。

ほとんどのケースで、アクションは直列につないだほうが流れもわかりやすくなりますしオススメです。

ただ、場合によっては直列に繋がずに並列に実行して、最後に合流させる方がよいことがあります。

やってみた

少し乱暴かつねつ造感のある例ですが、このような売上データのあるアプリがあるとします。このアプリには関東30店舗、関西30店舗の1年間の毎日の売上データが入っています。

これを地域別（この場合関東と関西）に1年間の売上として合計値を出したいとします。

やる処理としては関東、関西のデータをそれぞれ取ってきて合計値を出すという処理になります。

ここで、この2つの集計処理を直列で行うか、並列で行うかで処理時間が変わります。

ボタンを押すと処理を開始し、計算結果と処理開始・終了時間をテーブルに入れるアプリを作成しました。

当然ですが、計算結果は毎回同じです（これが違ったら一大事です）

実行するたびに処理時間はバラつくので3回ずつ実行した結果です。

直列の場合は、9秒、11秒、10秒

並列の場合は、6秒、5秒、5秒

という結果でした。明らかに並列が早いですよね。

で、この並列の時のアクショングラフをみてみましょう。

アクション30番で、27番と29番の完了を待っています。

こういうケースで使うんですよね。

とはいえ、多用するものではないと思います。

② JobRunnerからJobRunnerを呼び出したい

なるほど、Ｘでは「次のジョブをトリガーするためのkintoneアプリ作れば？」という意見がでていましたが、我々もそれを想定しています。

ジョブからジョブを呼び出せるようにすること（ジョブのチェイン）は技術的には可能なのですが、あえて避けています。

なぜかというと、安易にジョブのチェインを行うと、膨大なデータを処理したくなるからです。

Job Runnerでは、まとまった数のレコードの集計処理などができますが、実行時間15分制限があるように、実は膨大な数のレコードを処理することを想定していません。それは、kintoneに大きな負荷をかけてしまうということと、そもそもkintoneがそういうことに向いていないという点があります。

膨大なデータを処理するニーズ以外であれば、「次のジョブをトリガーするためのkintoneアプリ」で事足りると思っています。その方がどこまでジョブが進んでいるかもkintoneでわかるので便利じゃないですか？？？

そんなん言われても大量のデータを処理したい場合はどうすればいいんだよ？？？と思われた方は、弊社のキミノマホロにご相談ください。

必要なものを、必要なだけ。
業務改善の新しいカタチ。

kintoneを活用した業務改善・システム開発サービス

キミノマホロ for kintone

③ 変数を持たせたい

わかりますよ、わかります。これめっちゃ要望いただいています。

でも、作りません！

カスタマインは、ITが専門でない方でも（多少の勉強はしていただきつつ）使えることを目指しています。実際も非IT専門の利用者が多数派です。

変数があれば便利なのはわかります。ただ変数は、表に見えないので、デバッグを困難にすると考えています。コンソールみて追跡できる人は少数派なのです。元記事では数値をフォーマットするで代用しているとありましたが、どうしても必要であればそれ用のフィールドを作って非表示にすることをオススメしています。開発中はそのフィールドを表示するようにすれば値も簡単に見られますしね。

④ ダブルクリックでなにもしないを選択できるようにしてほしい

「なにもしない」を駆使できる人って実はカスタマイン上級者なんです。上級者がよく使うのは把握しているのですが、ダブルクリックで入れるほどかと言われると・・・初心者の方が意図せずダブルクリックして「なにもしない」が入ってしまうとパニックだろうな・・・と。

あと、やることを切り替えてしまうとパラメーターが飛ぶので、そういう事故も起こりそうだな・・・と。

UNDOできるので戻しはできるんですけどね。

ということで、これは入れる予定がありません。

⑤ ログの設定時、デフォルトで「直前動作のアクション」を定型文で出力されるようにしてほしい

このご要望には実は落とし穴がありまして、この「ログにメッセージを出力する」の上に置いてあるアクションが、必ずしもこのログ出力の前のアクションとは限らないのです。

厳密には「他のアクションの実行が完了したとき」などで繋いであるアクションが前のアクションにあたります。ですので、条件が揃わないとデフォルトで入れるべきアクションが確定しないという悩ましい問題があります。

「やること」と「条件」のどちらを先に設定するか次第ではありますが、カスタマインは「やること」を先に設定することを前提に考えています。条件まで確定した時点でやること側のパラメーターを入れることはできなくはないですが、先にやることに設定を入れていると設定が飛ぶのでそれはそれで悩ましいです。

メッセージが未設定ならデフォルトでその前に実行されたアクションの内容を出力するというのは考えられる手段ではありますが、これも前のアクションが1つとは限らない（①のケースです）ことや、前のアクションが何かによるところもあって、ただ結果を文字にして出せばいいかと言われると悩ましいところではあります。

⑥ 全アクションの一括選択ができるようにしたい

書かれているような処理がうまく動かない時に原因を特定したいということであれば、「コンソールにメッセージを出力する」を適宜挟んでいただくほうが早いと思います。

というのも、ちょっと難しい話なのですが、kintoneのカスタマイズでいうと、カスタマインでのカスタマイズはイベントドリブンな処理の仕方をしていまして、「他のアクションの実行が完了したとき」でつないでいると一連の処理の流れのように見えていますが、実際は「アクションを実行する」「アクションが終わったというイベントが発生する」「繋がっている次のアクションを実行する」という流れになっています。

やることの中には非同期で動くものもあったりするので、一連の流れを流しながら出力させるほうが正確に状況を把握できることが多いです。

あと、もうチェックボックスつける場所がないという元も子もない話もありますw 一番上のアクションの上にチェックボックスつけるとなんかダサいので嫌ですwww

⑦ 複数アクションをコピーして別ページに複製もできるようにしてほしい

複数アクションを別ページに移動したいという要望が大量に来ていたのですが、実はこれ実現が難しくてスルーしていました。

なぜ難しいかというと、ページをまたいでアクションの参照はできないので、移動する場合繋がっているアクションはまるごと道連れにする必要があるからです。部分的に移動したつもりがページまるごと移動しただけなんてことも起こる可能性があります。

そうなると、移動した結果処理の流れがわけがわからない状態になる懸念があったのです。

ですが、コピーなら元のものも残るのでいいか？？？というのは少し前から検討していまして、その結果12月18日(木）のアップデートで入りました＼(^o^)／

ただし、アクションの整合性を考慮せずにコピーしますので、コピーした先でちゃんと動くように設定するのはユーザーさんの責任です。

⑧ 要素からリストを取り出すがJobRunnerでも欲しい

なんか変だな？？？と思ったら「リストから要素を取り出す」です！

というのは置いておいて、

「リストから要素を取り出す」を作るとすると、そのリストはすでにメモリ上に存在している必要があります。つまり「レコード全行が準備できた時」と同じ状態になり、処理するレコード数が多い場合メモリエラーを起こす可能性があります。

Job Runnerは基本的にそれなりの数のkintoneのレコード操作をすることを主たる利用用途としているわけですが、多くのレコードをメモリ効率よく使えるように「レコードが1行準備できたとき」があります。

そのため「リストから要素を取り出す」は作れるっちゃ作れるんだけど躊躇するという感じです。

後処理も悩ましい

また、Job Runnerが想定している基本的な処理の流れですが、

レコードを取ってくる
なんかする
Job Runnerがいい感じのタイミングでkintoneに書き込む
終わったら通知などする

という単純なステップを作ることを想定しています。長大な処理を作ることは想定していません。

「メインの処理が完了した時」ですが、これは上の「いい感じのタイミングでkintoneに書き込む」と関連していて、Job Runnerは処理中に更新がかかったレコードをすぐにkintoneに書き込みにはいきません。一連の処理が終わったあとにまとめて書き込みに行くようになっています。

「メインの処理が完了した時」は主にこの書き込みが終わったときに発生します。

そのため、このあとにレコードを編集するような処理をしても、もう書き込み待ちを管理する仕組みが動かないので書き込みが起きないんです。

そんなこんなで「メインの処理が完了した時」は通知くらいの用途を想定しています。

⑨ 前回のジョブ「開始時刻」のほうが欲しい

これはたしかに一理ありますね。検討します。

ただ、実現した際には「べき等性」を意識してくださいね。

開始時刻を基準に処理を作った場合、同じレコードに対して2回以上処理をする可能性がでてきます。

その場合、結果がいつも同じになるように作る必要があります。

（何回やっても同じ結果になることを「べき等性」といいます）

⑩ できるだけマッピングをリセットしないで！

お気持ちはわかります。でも、これ危険なんです。上級者の方は問題ないのですが、不用意にマッピングを残してそれが意図していないものだった場合、実行するとレコードを破壊する可能性があります。

カスタマインはレコードの削除を意図的に入れていないように、迂闊にレコードを破壊してしまうような挙動をできるだけ起こさないように考えています。

ということで「ちゃんと設計してね！」

⑪ カスタマイズをフォルダ管理したい！

フォルダって難しくないですか？特にカスタマインは複数アカウントを発行し、チームで利用することができます。フォルダ分けってその人の個性や好みがとっても色濃く反映されやすいので、人によってどこのフォルダに入れるかの判断がブレる気がしています。

弊社は社内でのファイル共有にGoogle Driveを多用していますが、この共有ドライブのフォルダの切り方も人によって個性があるので毎回「あのファイルどこだ〜〜〜？？？」ってなります。

結局検索して見つけるということが多く「整理することは諦めて、検索することを前提にすればいいんじゃね？」と思っています。

フォルダよりもタグづけの方がまだ可能性あるかもしれません。未検討ですが。

まとめ

たくさんのご意見ありがとうございました。

カスタマインをよくご利用いただいているユーザーさんならではのご要望も多くてうれしいです。

カスタマインはこのように日々みなさんからのご意見をいただくことで成長しているサービスです。しかし、サービス提供側として製品のコンセプトを維持するために守らないといけないポイントもあり、すべてを実現することも難しいことはご理解ください。

アドベントカレンダーはまだ続きます。明日はどんな記事が上がると楽しみです。

来年もカスタマイン（と、エブリサイト）をよろしくお願いします。

画面のカスタマイズ、自動処理(バッチ)、帳票出力といった「kintoneの”できない”を”できる”に」
gusuku Customineがあればkintoneらしさをそのままにkintoneをカスタマイズできます

投稿者プロフィール

金春利幸: "gusukuシリーズプロダクトマネージャー
ノーコード(No-Code)の有効性に着目し、kintoneとgusukuシリーズの普及のため全国を飛び回っています。"