2026.10.03 DX

ワークフローシステムの承認段階別の入力制御機能：項目権限・公開範囲・申請修正の設計

経費申請で経理担当だけが勘定科目を入れ、部長は金額を見るだけで書き換えられない。ワークフローシステムの承認段階別の入力制御機能は、こうした「誰が、どの段階で、どの項目を触れるか」を申請書式ごとに決める機能です。この記事では、編集可・閲覧のみ・非表示の3状態の使い分け、人事や給与の情報を見せないための項目単位の参照権限と申請の公開範囲設定、承認途中の申請修正と差し戻し時の版管理を整理します。あわせて、権限設計を誤ったときに起きる統制事故と、要件定義の段階で作っておく項目×承認段階の権限表、パッケージの設定で足りずに追加開発へ進む条件も示します。

まとめ：承認段階別の入力制御は項目×段階の権限表と差し戻し時の版の扱いで決まる

入力制御の設計は、申請書式の項目を縦に、申請者と承認段階を横に並べた表を1枚作るところから始めます。各マスに編集可・閲覧のみ・非表示のどれかを入れ、後工程が追記する項目だけを該当段階で編集可にする設計です。承認者が金額や支払先を直接書き換えられる設定は外し、直したい場合は差し戻しで申請者に戻します。

参照権限は、項目単位の設定と申請一覧の公開範囲が別々に効く点に注意が要ります。製品によっては、公開用の一覧画面では項目のアクセス権が適用されないためです。人事・給与・健康情報を含む書式は、公開範囲を関係者に絞ってから項目の非表示を重ねます。

画面上の入力不可だけで守る制御は、APIやCSV取込で迂回されます。製品の権限設定で表現できない条件、たとえばステータスと金額の組み合わせで編集可否を変えたい場合は、サーバー側の検証を含めた追加開発の対象です。

承認段階別の入力制御機能の仕組み：申請者と経路ステップごとの閲覧・編集の権限

編集可・閲覧のみ・非表示の3状態で段階ごとに入力欄を開け閉めする設計

承認段階別の入力制御は、申請書式の項目ごとに、申請者と承認経路の各段階に対して3つの状態のどれかを割り当てる仕組みです。編集可は値を入力・変更できる状態、閲覧のみは値が見えるが変えられない状態、非表示はその段階の処理者には項目そのものが見えない状態を指します。

既定値は製品によって違い、何も設定しなければ全段階で全項目が編集可になる製品もあります。導入直後にそのまま運用を始めると、承認者が申請者の入力した金額を上書きできる状態になっています。最初に確かめるべきは「設定しなかった項目がどの状態になるか」です。

実務では、申請者が入れる項目は申請者だけ編集可、承認者は全員閲覧のみ、という形が基本の権限設定です。そのうえで例外として、後工程が書き足す項目と、特定の段階に見せたくない項目だけを個別に設定すると、設定のマス目が少なく済みます。承認経路や通知など入力制御以外の機能の全体像はワークフローシステムとは何かを機能と選び方から整理した解説で確認できます。

経理段階だけ勘定科目と振込日を入力させるなど後工程が追記する項目の例

入力制御が効くのは、申請者が知らない情報を後工程が書き足す書式です。経費申請なら、申請者は日付・金額・用途を入れ、経理担当の段階で勘定科目と振込日を入れます。勘定科目を申請者に選ばせると、科目の選び間違いを経理が毎回直すことになり、修正の手間が承認の流れの外に漏れます。

サイボウズのGaroonのヘルプ「項目のアクセス権の設定」でも、上長が内容を追記する、経費申請で経理担当者が振込日を入力する、入社手続きで受け入れ担当者がExcelファイルを添付する、という3つの使い方が例に挙がっています（2026年10月時点の記載）。

ほかにも、購買申請で購買部門が発注番号を入れる、稟議で法務が契約書の確認結果を記入する、といった使い方があります。いずれも「その段階の担当者しか値を知らない項目」に絞って編集可を付けるのが原則です。

製品の設定画面で決められる範囲：対象の項目タイプと経路分岐項目の例外

入力制御はどの項目にも掛けられるわけではありません。Garoonの同じヘルプでは、アクセス権を設定できる項目タイプを文字列（1行）・文字列（複数行）・日付・数値・ファイル添付に限っています。さらに、数値項目が経路分岐の項目に指定されている場合と、その数値を使った自動計算項目が経路分岐に使われている場合は、アクセス権を設定できないと書かれています。

この制約には理由があります。金額で承認経路を分ける書式で、途中の段階が金額を変えられると、経路の前提が承認の途中で崩れるためです。経路の判定に使う項目は、申請時点で確定させて以後は誰も変えない、という扱いが製品の設計にも表れています。

選択肢を選ぶ項目やチェックボックスに入力制御が掛からない製品では、その項目を文字列に置き換えるか、権限を掛けられる項目で同じ情報を持たせる工夫が要ります。選定の段階で、自社の書式に出てくる項目タイプすべてに入力制御が掛かるかを試してください。比較の段階で何を試すかはワークフローシステム比較の判断軸とタイプ別の選び分けで扱っています。

項目単位の参照権限と申請の公開範囲設定：人事・給与情報を見せない設計

申請者・承認者・閲覧者で見える項目を分ける判断と個人情報保護法のアクセス制御

非表示の設定が要るのは、承認の判断に使わない個人情報を含む書式です。慶弔見舞金の申請に書かれた家族の病名、休職申請に添付する診断書、給与振込口座の変更届などは、直属の上長が承認しても、上長の上の役員や後工程の総務全員が中身を見る必要はありません。

個人情報保護委員会の個人情報保護法ガイドライン（通則編）は、10-6の技術的安全管理措置の最初に「アクセス制御」を置き、担当者と取り扱う個人情報データベース等の範囲を限定するよう求めています。ワークフローに当てはめると、承認の段ごとに「その人が判断に使う項目だけを見せる」設計がこれに当たります。

判断の基準は、その段階の承認者が値を見ないと承認か却下かを決められるかどうかです。見ないと決められない項目は閲覧のみ、見なくても決められる項目は非表示にします。役職や部署で権限をまとめて付ける考え方はRBAC（ロールベースアクセス制御）の仕組みと導入判断、金額や書式の属性で権限を変える考え方はABAC（属性ベースアクセス制御）とRBACの使い分けで解説しています。

公開用の一覧や管理者権限で項目の参照権限が素通りになる落とし穴

項目を非表示にしても、別の画面から見えてしまう経路が残ることがあります。Garoonのヘルプには一覧画面ごとに適用されるアクセス権の表があり、公開一覧には項目のアクセス権が適用されないと明記されています。申請を公開設定にした時点で、非表示にしたはずの項目も公開先の全員に見える、ということです。

同じ表では、同じ人が複数の経路ステップに入っている場合、受信一覧・未処理一覧・承認予定一覧のどれから開くかで適用される権限が変わることも示されています。課長と経理担当を兼ねる人のように、1人が2つの段に入る組織では、画面によって見える項目が違う、という状態が起きます。

もう1つの抜け道は、システム管理者の全件閲覧です。管理者権限で全申請を検索・出力できる製品では、項目の非表示は一般利用者の画面にしか効きません。管理者を情報システム部門の担当1人に固定している会社では、その人が人事情報を見られる状態になっていないかを確かめます。

部署公開・関係者公開・非公開の3段階で書式ごとに公開範囲を決める手順

申請の公開範囲設定は、承認の済んだ申請を誰が後から読めるかを決める設定です。全社公開にすると過去の稟議を検索して前例を探せる利点があり、閉じすぎると同じ稟議が部署ごとに何度も起票されます。

決め方は、書式を3つに分けると迷いません。備品購入や出張申請のように個人情報を含まず前例が役に立つ書式は部署公開、稟議や契約審査のように判断の経緯を関係部署で共有したい書式は経路上の関係者と指定部署への公開、人事・給与・健康に関わる書式は非公開です。非公開の書式は、承認者と人事担当以外が検索結果にも出ないことを確かめます。

公開範囲を広げた書式には、前の見出しで述べたとおり項目の非表示が効かない製品があります。公開する書式からは、個人情報を入れる項目そのものを外すほうが確実です。稟議の前例共有の考え方は稟議システムの機能と紙・メール稟議の課題でも触れています。

承認途中の申請修正と差し戻し時の版管理：誰がどこまで書き換えてよいかの線引き

承認者による直接修正と差し戻し再申請の使い分け：金額と相手先は戻す

承認途中で申請内容に誤りが見つかったとき、承認者が直接直すか、差し戻して申請者に直させるかは、項目の性質で分けます。誤字や部署名の表記ゆれ、備考欄の補足のように承認の判断を変えない項目なら、承認者が直接直しても統制上の問題は小さく済みます。

金額・数量・支払先・契約相手・納期のように、承認の判断そのものに関わる項目は、申請者への差し戻しの対象です。承認者がこれらを直接書き換えると、申請者が出した内容と承認された内容が別物になり、誰の判断でその金額になったのかが曖昧になります。部長が申請額を減額して承認したつもりでも、申請者は減額を知らないまま発注を進める、という食い違いも起きます。

差し戻しの通知の届け方と期限はワークフローシステムの通知機能の設計で扱っているので、ここでは修正できる範囲の線引きに絞ります。

再申請で変わった項目を前の版と並べて見せる版管理と承認のやり直し範囲

差し戻しのあとで申請者が出し直した申請を、承認者は「前回と何が変わったか」を見て判断します。変わった項目に印が付かない製品では、承認者が申請書全体を読み直すか、変更点を見落として承認するかのどちらかになります。

版管理で確かめる点は2つです。1つは、再申請の画面で前の版の値と今の値を並べて表示できるか。もう1つは、再申請のあとで承認をどこからやり直すかを決められるかです。金額が変わったなら最初の承認者から、添付書類の差し替えだけなら差し戻した段から、というように、変わった項目によって戻る段を変えられると、承認者の重複作業が減ります。

合議の段がある稟議で、差し戻しのたびに全段をやり直す設計の影響は大企業のワークフローシステム選定で整理した合議と差し戻し先の指定で扱っています。変更前後の値を承認履歴として残す方法はワークフローシステムの操作ログ取得を参照してください。

承認済みの申請を取り消して出し直す運用と修正申請の書式を別に持つ判断

最終承認のあとで誤りが見つかった申請は、承認済みのデータを書き換えずに、取消と再申請で扱います。承認済みの申請を管理者がそのまま直せる運用は、承認の記録と実際の内容がずれる原因になり、監査で説明がつきません。

取消のたびに一から申請を作り直す手間が大きい書式では、元の申請を参照して差分だけを書く「修正申請」の書式を別に用意します。元の申請番号を必須項目にし、変更前と変更後の値を並べて書かせると、承認者は差分だけを見て判断できます。発注金額の変更や契約期間の延長のように、承認後の変更が月に何件も出る書式で効果のある方法です。

権限設計を誤ったときの統制事故：承認者の書き換え・画面だけの制御・設定変更

承認者が金額を書き換えられる設定が職務分掌を崩す構造と防ぎ方

入力制御の設定漏れで最も多い事故は、承認者が申請者の入力項目を書き換えられる状態のまま運用されることです。申請と承認を別の人が行う、という職務分掌の前提は、承認者が申請内容を変えられる時点で崩れます。承認者が金額を書き換えて自分で承認すれば、実質的に1人で申請と承認を済ませたのと同じです。

防ぎ方は、申請者の入力項目を承認段階ではすべて閲覧のみにすることです。そのうえで、運用開始前に承認者のアカウントで実際に申請を開き、編集できる項目が想定どおりかを確かめます。設定画面の表を見るだけでは、既定値で編集可になっている項目を見落としがちです。購買や支払の承認権限と職務分掌の決め方は購買管理規程と内部統制：承認権限と職務分掌の設計で整理しています。

画面の入力不可だけで守る制御がAPIやCSV取込で迂回される失敗

パッケージの権限設定で表現できない条件を、画面のカスタマイズで補う方法があります。kintoneのフィールドのアクセス権は、フィールドのアクセス権の設定を変更するAPIの仕様で、権限の種類が閲覧と編集（WRITE）・閲覧のみ（READ）・不可（NONE）の3つ、権限を与える相手がユーザー・グループ・組織・フォーム上のフィールドの4種類と定められており、プロセス管理のステータスを相手に指定する項目はありません。そこで、編集画面を開いたときにステータスを見て入力欄を無効にするJavaScriptを足す、という方法がよく取られます。

kintone.events.on(['app.record.edit.show'], (event) => {
  const record = event.record;
  // 経理確認の段階だけ勘定科目を入力できるようにする
  const isAccounting = record['ステータス'].value === '経理確認中';
  record['勘定科目'].disabled = !isAccounting;
  // 申請者が入れた金額は承認段階では変えさせない
  record['金額'].disabled = true;
  return event;
});

入力欄のdisabledを切り替える書き方は、cybozu developer networkのチュートリアル「フィールドの編集可／編集不可を切り替えてみよう」で示されています。ステータス名とフィールドコードはアプリの設定に合わせて読み替えてください。

この方法の弱点は、制御が編集画面の上でしか効かないことです。REST APIでの更新、CSVファイルの読み込み、一覧画面からの編集のように編集画面を通らない経路では、入力欄の無効化は働きません。金額のように統制に関わる項目は、画面の制御に加えて、フィールドのアクセス権かサーバー側の検証で守る設計にします。画面の制御は入力の手間を減らすための補助と位置づけてください。

入力制御の設定変更を誰でもできる状態にしておく書式管理の運用の危うさ

入力制御の設定そのものを変えられる人が多いと、設定は少しずつ緩みます。現場から「承認者でも直せるようにしてほしい」と頼まれた書式管理者が、その場で編集可に切り替え、元に戻さないまま半年が過ぎる、という形です。

書式と権限の設定を変えられる人は、情報システム部門と内部統制の担当の2〜3人に絞り、変更は申請と承認を経て行います。ワークフローの設定変更をワークフローで承認する運用です。設定変更を誰がいつ行ったかを記録に残す方法は、前の章で挙げた操作ログの記事で扱っています。

要件定義チェックリストと追加開発の判断：項目×承認段階の権限表から始める設計

要件定義の前に作る項目×承認段階の権限表と経費申請での記入例

入力制御の要件は、文章で書くより表で書くほうが漏れません。申請書式の項目を縦に、申請者と各承認段階を横に並べ、各マスに編集可・閲覧のみ・非表示を入れます。経費申請の記入例は次のとおりです。

項目	申請者	上長	経理担当	部長
日付・用途・金額	編集可	閲覧のみ	閲覧のみ	閲覧のみ
領収書の添付	編集可	閲覧のみ	閲覧のみ	閲覧のみ
上長コメント	閲覧のみ	編集可	閲覧のみ	閲覧のみ
勘定科目・振込日	非表示	非表示	編集可	閲覧のみ
振込口座	編集可	非表示	閲覧のみ	非表示

表を作ると、編集可が1列に2つ以上ある行がすぐ分かります。同じ項目を2つの段階で編集できる設計は、どちらの値が正しいかで揉める原因になるため、原則として1行に編集可は1つにします。この表は、製品を選ぶときの試験項目にも、開発会社へ渡す要件にもそのまま使える資料です。要件定義書のどこにこの表を置くかは業務要件定義の記載項目と業務要件定義書の作り方を参考にしてください。

表と一緒に、次の3点を書式ごとに決めておきます。差し戻しで申請者が直せる項目の範囲、再申請のあとで承認をやり直す段、公開範囲（部署公開・関係者公開・非公開のどれか）です。

承認段階別の入力制御でパッケージ設定が足りる範囲と追加開発に進む4つの条件

入力制御の要望の多くは、製品の設定で実現できます。申請者と承認段階ごとの編集可・閲覧のみ・非表示、書式ごとの公開範囲、差し戻し時の修正可否は、主要なワークフロー製品の多くが標準で持つ機能です。設定で試さないまま開発を依頼するのは、費用の使い方として過剰です。

追加開発に進むのは、次のように製品の設定項目の外にある条件が絡む場合です。

金額や取引先の区分など、入力値の組み合わせで段階ごとの編集可否を変えたい
画面の制御だけでなく、APIやCSV取込を含めたすべての更新経路で同じ制御を効かせたい
人事システムの所属や役職から、閲覧できる項目を自動で切り替えたい
自社の業務システムの画面の中で、申請・承認と入力制御を一体で動かしたい

最初の2つは、権限の判定をサーバー側に持たせる開発です。一創のワークフローシステム開発では、項目×段階の権限表をもとに、承認経路と入力制御を既存の業務システムに組み込む開発を扱っています。開発費の相場と内訳はワークフローシステムの費用相場と自社開発との5年総額で確認できます。

反対に、書式が10種類未満で、権限の分け方が申請者と承認者の2通りで足りる会社は、開発を見送ってパッケージの設定で運用するほうが合理的です。

ワークフローシステムの承認段階別の入力制御でよく寄せられる質問と答え

入力制御・公開範囲・申請修正について、導入の前後によく出る質問をまとめました。

承認段階別の入力制御機能が無い製品ではどう運用すればよいですか？

後工程が書き足す項目を申請書式から外し、別の書式や別の帳票に分ける方法があります。たとえば経費申請では、申請者の入力と承認だけをワークフローで回し、勘定科目と振込日は経理が会計システム側で入れる形です。申請書式に後工程用の項目を残したまま全員が編集できる状態にすると、承認後に誰が値を変えたか分からなくなります。項目を分けられない書式が多いなら、入力制御を持つ製品への切り替えを検討してください。

承認者が申請内容を修正した場合、記録はどのように残りますか？

製品によって残り方が違います。修正した人・日時・変更前後の値まで承認履歴に残る製品もあれば、最後の値しか残らない製品もあります。後者では、承認者がいつ何を変えたかを後から確かめられません。選定時に、承認者のアカウントで項目を書き換えたあと、履歴の画面に変更前の値が出るかを試してください。承認者が直接直すのは、判断に関わらない誤字や備考の補足に限るのが安全です。

申請の公開範囲はどこまで広げてよいですか？

個人情報を含まず、前例の検索が役に立つ書式に限って広げます。備品購入や出張申請は部署公開、稟議は関係部署まで、人事・給与・健康に関わる書式は非公開が目安です。公開用の一覧では項目の非表示が効かない製品があるため、公開する書式には個人情報を入れる項目を置かないでください。公開範囲を変えるときは、変更前に承認済みだった申請にも新しい範囲が適用されるかを確かめておきます。

kintoneで承認段階ごとに入力できる項目を変えられますか？

フィールドのアクセス権はユーザー・グループ・組織・フォーム上のフィールドに対して設定する仕組みで、プロセス管理のステータスを条件にする設定はありません。ステータスごとに入力欄を変えたい場合は、編集画面を開いたときにステータスを見て入力欄を無効にするJavaScriptやプラグインを使います。ただし編集画面を通らないAPIやCSV読み込みには効かないため、統制に関わる項目はアクセス権やサーバー側の検証と併用してください。

入力制御の設定を見直すタイミングはいつですか？

組織改編、職務権限規程の改定、書式の項目追加の3つが見直しの契機です。項目を追加すると、その項目は既定値の権限で作られるため、全段階で編集可になっていることがあります。項目を足したら、権限表の行も同時に足して設定を確かめる運用にしてください。年に1回は、承認者のアカウントで主要な書式を開き、編集できる項目が表のとおりかを点検すると、設定の緩みに気づけます。