照会回答パッケージプラグイン（無料）
自治体などで頻発する部署間の「照会(調査依頼)」と「回答」の業務を、「依頼アプリ」「回答アプリ」の わずか2つのアプリだけで実現するノーコードパッケージプラグインです。依頼アプリで質問項目・表示幅・ 必須/任意をテーブルで設計すると、回答アプリ側にその内容に応じた仮想フォーム・集計リスト・分析 ダッシュボードが自動生成されます。照会のたびに使い捨てのアプリを作ってしまう「アプリの野良化」や kintoneのアプリ数上限への到達を防ぎます。
こんな方におすすめ
- kintoneで部署間の照会・回答業務をノーコードで作りたい
- 依頼内容によって回答フォームの項目を動的に変えたい
- 「kintone 照会 回答」を探している
- 自治体の庁内照会業務をkintoneで運用したい
ユースケース
依頼アプリのレコードとして、質問項目(文字列・数値・日付・日時・時刻・ラジオボタン・ドロップダウン・チェックボックス)と詳細説明・表示幅・必須/任意をテーブルで設計するだけで、回答アプリ側に専用アプリがあるかのようなフォームが動的に生成されます。照会のたびに新しいアプリを作成する必要がありません。依頼アプリの追加・編集画面にもプレビューが表示されるため、保存前に質問項目を組み立てながらその場で見た目を確認できます。
回答アプリの一覧画面には、依頼された照会ごとに必要な列だけを動的に抽出して表示する「集計リスト」が描画されます。回答状況(未着手/対応中/回答済)や回答部署で絞り込みながら、期限管理・催促に活用できます。
依頼アプリのレコード詳細から「集計・分析」ボタン(レコードの編集権限があるユーザーにのみ表示)を押すと、回答アプリの分析ビューへその照会の回答に絞り込んで遷移します。横棒・縦棒・ドーナツ・折れ線グラフやKPI(合計/平均切替)、CSV/JSON/PDF出力で回答結果を可視化できます。
セットアップ手順
- 依頼アプリ用・回答アプリ用に、それぞれ別のアプリを1つずつ用意し、両方に本プラグインを追加する。
- 依頼アプリの設定画面で「このアプリの役割」を「依頼アプリ」に、回答アプリの設定画面で「回答アプリ」に設定し、それぞれ相手アプリのアプリIDを入力して保存する。
- 依頼アプリの設定画面で「必要な項目・一覧を自動作成」を実行し、「アプリを更新」する。
- 回答アプリの設定画面で同じボタンを実行し、「アプリを更新」する。
- 回答アプリでもう一度同じボタンを実行する(依頼アプリへ関連レコード一覧「回答一覧」が自動追加されます)。依頼アプリ側でも「アプリを更新」する。
- 依頼アプリのプロセス管理で、ステータス遷移時のアクションとして回答アプリへレコードを追加する設定を行う(本プラグインはこのアクション設定自体は自動生成しません。回答担当部署がアクションボタンから回答アプリのレコードを追加する運用を想定しています)。
- 回答アプリのレコードのアクセス権で、「回答部署」「依頼元部署」の組織に閲覧・編集権限を付与する設定を行う(本プラグインはアクセス権自体の設定は行いません。関係のない部署から回答が見えないようにするため、アプリ管理者が別途設定してください)。
依頼アプリの「依頼元部署」、回答アプリの「依頼元部署(自動コピー)」「回答部署」は必須項目です。回答アプリの「フォーム定義JSON」フィールドは、保存時に自動生成される内部データのためレコード画面には表示されません。
アプリ設定でしていいこと・悪いこと
本プラグインは、依頼アプリ・回答アプリ双方に固定のフィールドコード(予備フィールドを含む)を前提に 動作します。「必要な項目・一覧を自動作成」で作られたフィールド・一覧まわりを扱う際の注意点です。
していいこと
- 依頼アプリ・回答アプリのどちらにも、固定のフィールドコードと重複しない新しいコードで、社内管理用のフィールド(担当者・優先度・内部メモなど)を追加すること。
- フォーム上のフィールドの並び順やグループ化など、表示上のレイアウトを整理すること(ただしプレビュー用スペース・回答フォーム用スペースは削除しない)。
json・condition_json・related_rich_textなど内部用フィールドに、フィールドのアクセス権で「編集不可」「管理者以外は閲覧不可」を設定すること。- 依頼アプリの「回答期限」フィールドに通知条件(リマインダー)を追加すること。
- 集計リスト・分析以外に、独自の一覧(絞り込み・並び替え済みのビューなど)を追加すること。
- 回答アプリにプロセス管理を導入し、ステータスに応じたアクセス権制御と組み合わせて使うこと(次項「おすすめ設定」参照)。
してはいけないこと
- 固定のフィールドコード(依頼アプリ:
title/description/requester/recipients/deadline/attachment/questions/condition_json/json/related_links/related_rich_text/related、回答アプリ:title/description/requester/deadline/json/answer_department/answer_status/attachment/lookup/予備フィールドtext_*等)のフィールドタイプ変更・削除・コードのリネームをすること。JavaScriptカスタマイズがこれらのコードを直接参照しているため、動作しなくなります。 - 予備フィールド(
text_1〜text_30等)を、質問項目テーブル経由ではなく直接編集して別用途に転用すること。依頼アプリ側の質問項目テーブルのinsert_column(タイプ+番号から自動計算)が動的にこれらを割り当てるため、直接値を入れると仮想フォームの表示内容と食い違います。 json・condition_json・related_rich_textの値を手動で書き換えること。いずれも保存時にプラグインが自動生成する値で、手で編集すると仮想フォーム・関連リンクの描画が壊れます。- プレビュー用スペース(
previewSpaceId)・回答フォーム用スペース(formSpaceId)の要素IDを、プラグイン設定と食い違う値に変更すること。仮想フォームが描画されなくなります。 - 集計リスト・分析一覧の名前や、カスタマイズ形式一覧のHTML(
<div id="virtual-table-div"></div>)を変更すること。集計リストが描画されなくなります。 - 回答が集まり始めたあとに、依頼アプリの質問項目テーブルの
field_type(タイプ)・column_number(番号)を変更すること。insert_column(格納フィールドコード)が計算し直され、既存の回答データと新しいフォーム定義の対応がずれます(質問の追加は可能ですが、既存行の変更・削除は避けてください)。 - 予備フィールドの上限(文字列30/複数行30/数値10/日付10/日時10/時刻5)を超える
column_numberを1件の照会に設定すること。計算結果のフィールドコードが存在せず、依頼アプリの保存時にエラーになります。
おすすめ設定
運用を始めるとよく課題になる点への対応例です。特に1点目は、回答済みデータの改ざん・誤操作を防ぐうえで強く推奨します。
- 回答状況が「回答済」になったら編集をロックする。回答アプリの「アプリの設定」→「レコードのアクセス権」で、条件に「回答状況(
answer_status)が 回答済」を追加し、回答部署の編集権限を外して閲覧のみにします。回答状況はプラグイン固定の通常フィールド(ラジオボタン)なので、標準のレコードのアクセス権の「フィールドの値」条件でそのまま指定できます。 - 回答アプリのレコードのアクセス権は、回答部署・依頼元部署の組織に閲覧・編集を付与し、それ以外は非公開にする。関係のない部署から他部署の回答が見えてしまう事故を防げます(セットアップ手順にも記載の前提です)。
- 回答の追加はプロセス管理のアクションボタン経由に統一する。依頼アプリのレコード一覧から回答担当者が自由に回答アプリのレコードを新規作成できる状態にすると、
lookupの選択漏れや、依頼内容(タイトル・期限等)の転記漏れが起きやすくなります。 - 依頼アプリの質問項目(
questions)のcolumn_number(格納先の番号)は、自動作成される予備フィールドの残数(文字列30/複数行30/数値10/日付10/日時10/時刻5)を意識して設計し、一度回答が始まったらfield_type・column_numberを変更しない。insert_column(格納フィールドコード)はこの2項目から自動計算される文字列フィールドのため、選択肢を後から減らす場合も既存回答の値が選択肢から外れて表示が崩れないか確認してください。 - 内部用フィールド(
json/condition_json/related_rich_text)は、フィールドのアクセス権で管理者以外を閲覧不可にする。通常ユーザーの目に触れないようにし、誤って値を書き換えられる事故を防げます。 - 依頼アプリの「回答期限」に通知条件を設定し、期限前のリマインダーを自動化する。集計リストで回答状況を横断的に見つつ、未回答の部署にだけ個別に催促する運用と組み合わせると効果的です。
セキュリティレビュー結果サマリ
kintoneセキュアコーディングガイドラインに沿って実装時にチェックしています。特に重要な点は次のとおりです。
- 仮想フォーム・仮想一覧・分析ダッシュボードのユーザー由来データはすべて
textContent・createTextNode・new Option()経由で挿入しており、innerHTMLに変数を埋め込む箇所はありません。 - 関連リンクのリッチテキスト生成は、URLを
http(s)スキームのみ許可し、URL・表示ラベルともHTMLエスケープ、rel="noopener noreferrer"を付与しています(旧カスタマイズにあった未エスケープのHTML連結は廃止し、ユニットテストで担保)。 - 旧カスタマイズにあった外部CDN(Chart.js)の読み込みを廃止し、グラフはSVGで自前描画しているため、プラグインの実行コードからkintone以外への通信は一切行いません。
- kintoneへのAPI呼び出しはすべて
kintone.api()(kintone自身への呼び出し専用の内部ラッパー)経由で、生のfetch/XMLHttpRequestでURLを直接組み立てる箇所はありません。 - 設定画面の「必要な項目・一覧を自動作成」は動作テスト環境(preview API)のみを変更し、既存フィールド・一覧の設定を変更・削除しません(不足分のみを追加する冪等な実装)。運用環境への反映(デプロイ)はユーザー自身の「アプリを更新」操作に委ねており、プラグインが勝手に反映することはありません。
- プラグイン設定(
kintone.plugin.app.setConfig())に保存するのは役割・アプリID・スペース要素ID・一覧名のみで、認証情報は一切扱いません。
詳細な確認項目・確認日は下記GitHubのチェックリストに全項目を掲載しています。
画面イメージ
設定画面(役割の選択と必要な項目・一覧の自動作成)、回答アプリの集計リスト(仮想一覧)、分析ダッシュボードの3画面です。
API実行数について
設定画面の「必要な項目・一覧を自動作成」ボタンを押すたびに、動作テスト環境のフィールド取得・追加
(preview系API)を実行します(ボタンを押した回数だけ実行され、自動では実行されません)。依頼アプリの
レコード保存時に、質問項目の格納先フィールドコードが回答アプリに実在するかを確認するため、回答アプリの
フィールド一覧を1回取得します。回答アプリの「集計リスト」「分析」一覧を開くたびに、一覧の絞り込み条件を
引き継いだカーソルAPI(records/cursor、500件/回)で該当レコードを全件取得します。