公開日：
（更新日：）
こんにちはっ。システム開発グループの わだっち です。
みなさんは、「デプロイット」という弊社サービスをご存知でしょうか？ご利用いただいてますか？
お客さまからご依頼を受け、kintoneや「カスタマイン」を主としたシステム構築支援をする
「システム開発グループ」にとって、無くてはならないこのサービスなのですが、
kintoneやカスタマインと違って、その取り扱いには少し難しい点があったりします。
今回は、お客さまのシステム構築支援をさせていただくなかで、平常運転ではあるのですが
カスタマインもデプロイットも両方使っていて、ある時急に「あれれ？なんでだ？？」となった場面を
切り取って少し書いてみようかなと思いました。
デプロイットとは
既にほかの記事などをご覧いただいてご存知の方も多いとは思いますが、
「よく知らないよ」という方のために、あらためて簡単にサービスについて説明します。
サービスサイトで「kintoneアプリのバージョン管理＆配布」「データのバックアップ」を
基本機能として紹介していますが、
kintoneのみを使っていると、本番として運用しているアプリに改修を行いたいとなった場合に、
「直接設定変更して、変更に伴うエラーが出てアプリが使えなくなったらどうしよう」という
困りごとに直面したりします。
それを避けるべく、本番とは別に同じ構造の開発用アプリを用意して、
そこで改修を行い、テストして本番化としたいのですが、テストOKとなっても、
開発用アプリで実施した変更を、本番アプリで同じように実施する必要が出てきて
結局「本番化の際に間違ったりしてエラーでアプリが使えなくなったらどうしよう」という
同じような悩みに直面することになります。
そんなとき頼りになるのがデプロイットで、開発↔本番でアプリを紐づけすることで、
それぞれのアプリにおける設定内容を簡単にもう一方に反映させたり、
設定内容をバージョン管理して、以前の状態に戻したりできるようになるんです。
「開発と本番で同じ作業を」だったり「エラーが起こってしまったら」という
お困りごとを解決してくれますねっ。
デプロイットを使ってお客さまの環境を管理する
開発スペースでアプリを構築します（アプリはイメージ：ストアのアプリを利用）
デプロイットで「プロジェクト」>「環境」と作成して、アプリを環境に追加するとこうなります。
※詳細な手順はここでは省略します（サービスにサインインして「操作マニュアル」をご確認ください）
kintoneで「本番環境」のスペースを用意して、ほかのアプリを再利用／テンプレートから作成するなどして
デプロイットで「本番環境」の「環境」を追加して、本番用のアプリを環境に追加するとこうなります。
※作業手順で「kintoneアプリ紐付け設定」をすることで、ID：238と245のアプリは同じアプリとしてデプロイットで扱われます
本番運用していて、改修したいとなったアプリがあれば、
開発環境のアプリで改修→動作確認のうえ、デプロイットで「アプリ取り込み」をすることで
バージョンを上げ、「指定バージョンの配布」をクリックする流れで、
kintoneの本番反映用アプリを直接触ることなく、ボタンクリックで設定の反映に加え
配布対象である本番アプリのバージョンも上がってバージョン管理もできるようになっています。
カスタマインによるカスタマイズ設定については省略していますが、
ここまでの流れは「システム構築支援」でよくやるリリースまでの手順です。
本番リリース後に、管理の主体がお客さまに。しばらくして…
「開発環境でのアプリ構築／カスタマイズ設定／動作確認」を経て
「本番環境のリリース、デプロイットでの環境設定／アプリ追加」などが終わった状態です。
リリース以降については、カスタマイズ含め管理をお客さま主で実施されることになったので、
デプロイットで「環境」を作成する際に環境毎に登録する「kintoneシステム管理者のアカウント情報」と
カスタマインの「接続ユーザ」を、R3のアカウントからお客さまのそれに変更して貰う事にしました。
順調にお客さま主体での管理が進んでいたのですが、ある日突然問合せをいただきます。
「カスタマイン（JobRunner）を設定しているんですが、あるアプリでエラーが出ちゃうんです。」
エラーの内容的に、まっさきに「カスタマインの接続ユーザ」が、カスタマイズを設定しようとしているアプリの
管理権限が無いのかな？と思い確認しましたが、問題ありません。
「gusukuプロジェクト」ではデプロイットのプロジェクトを選択してカスタマイズを設定しようとされていたので、
「デプロイットの各環境で登録されたkintoneシステム管理者」のアカウントが、
エラーが出るアプリの管理権限が無いのかな？と思い確認しましたが、
結果的にこれも問題ありませんでした。
表にして整理するとこんな感じで、デプロイットの環境毎に登録されているアカウントが違ったり、
カスタマインの接続ユーザはまた違ったりでごちゃごちゃはしていましたが、
開発／本番のスペースにもそれぞれのアカウントは参加した状態でしたし、
この状態そのものがエラーの原因ではありませんでした。
エラーの原因がわからない。。。
困った私は、自力での解決は難しいと判断し、こういう時にはと 沖さん に相談しました。
それまで確認した事を伝えると、それほど時間もかからずサラッとこんな事を言われます。
「gusukuプロジェクトの選択がデプロイットのプロジェクトなら、疑うべきは開発環境のアプリだと思う」
「開発環境にあるエラーが出ているアプリの、設計情報をダウンロードして、ルックアップや関連レコードを確認してみては？」
なるほど！？
カスタマインで新規のカスタマイズを作成しようとする際に
「gusukuプロジェクト」を「デプロイットのプロジェクト」で選択すると、
フィールドの参照はデプロイットのプロジェクトにおける一番左側の環境が基本になります。
今回のエラーの原因も、環境としての対象は「開発環境」であり、
エラーが出ているアプリ自体の権限に問題が無いのであれば、そのアプリで参照しようとしている
別アプリの権限に問題があるのではないか？という指摘でした。
設計情報をダウンロードして確認してみると…
いました。認識してない関連レコード。。。
対象のアプリは、お客さまがテスト的に作ったもので、そのアプリを参照する関連レコードも
開発環境のアプリでのみ設定してみたが、テストで作っただけで終わった類のものだったみたいです。
権限が無く普通には見えないので、「kintoneシステム管理>アプリ管理」で設定画面に遷移して
アプリのアクセス権を確認すると
こんな感じで、デプロイットの開発環境に登録された「R3」のアカウントには権限付与されていません。
お客さまに、当該アプリにR3の権限付与or関連レコードやアプリの削除 をお願いし、
対応いただいた事で、カスタマイン設定時のエラーは発生しなくなり、解決しました。
※その後、カスタマインの接続ユーザと、デプロイットの登録アカウントについては、
関連するすべてのアプリについて運用上必ず「管理者」になるだろうアカウントに
可能な限り統一して欲しい旨を、説明とともにお願いしました
教訓というかまとめというか
今回の話は、なかなかイレギュラーというか、同じような事が皆さんにそれなりの回数発生する
という類のものではないと思います。
「権限が絡んでそうなエラー」が出た際に、どのような点を確認するかの参考になれば
という感じで読んでいただけるとありがたいです。
- カスタマインの接続ユーザ、デプロイットで環境に登録するアカウントは なるべく統一しましょう
- カスタマインのカスタマイズ作成時に、デプロイットのプロジェクトを選択していてエラーが発生した場合は、その原因が開発環境のアプリにある可能性があるので注意しましょう（本番環境だけを確認しても解決しないかも）
- カスタマインでもデプロイットでも「設計情報」のダウンロードが可能なので、原因を探る際などに活用しましょう
- エラーが出ている場合「正しいはず」という思いこみは捨てて、少しずつ着実に確認していくようにしましょう
あと、今回はカスタマインとデプロイットとが絡んだお話でしたが、
デプロイット単体の利用でもまあまあ「ん？？」ってなる事もあります。
今回、解決に導いてくれた 沖さん がそのあたりわかりやすく解説してくれてたりしますので、
是非ご確認いただければ幸いです。
それでは～
投稿者プロフィール
-
"kintone「かかりつけ医」「伴走者」「よろず屋」 kintoneに関する提案、構築、相談など幅広く色々やっています。
元ユーザという事もあり、お客様に近い距離でのやり取りを主な生業としています。"
最新の投稿
gusuku2025年6月18日kintoneと、カスタマインと、デプロイット- gusuku2025年5月9日あなたの「・・・」はどこですか？
- gusuku2020年11月4日Customineカスタマイズ時に使う人の操作や思考を想像してみる
- kintone2020年8月31日イメージ（想像）してみよう
