ワークフローは「手続きの記録」であり、制度の根幹である
ワークフローシステムは、単なる申請・承認の電子化ツールではありません。
業務プロセス上の判断を記録し、組織として「誰が、何を、どのように判断したか」を証明するための制度インフラです。そして、会社の機密情報や従業員の個人情報など、重要度の高い情報を扱う仕組みです。
しかしその記録が、たとえば次のような構造だった場合はどうでしょうか？
- 承認済みの文書が後から編集できる
- 誰がいつ操作したかのログが残らない
- 文書が勝手に削除されても記録が残らない
- 見てはいけない人が申請書を閲覧できる
こうした仕組みでは、ワークフローが“形だけの制度”になってしまいます。
制度とは、判断の記録が正確に・改ざんされず・証明可能な形で残されている状態を指します。
この「制度としての信頼性」を担保するために、ワークフローにもセキュリティと統制の仕組みが欠かせないのです。
ガバナンスを支える“制度としてのセキュリティ”とは？
現代の企業活動においては、情報漏えいや外部不正といった外的リスクだけでなく、内部統制の不備や制度逸脱といった組織内部からのリスクが深刻な問題となっています。
ワークフローの場面で起こり得るリスクは、たとえば次のようなものです。
| ねつ造 | 無かったはずの事実を後から都合よく偽造されてしまう |
| 改ざん | 承認済みの稟議書の金額や文言を、後から書き換えられてしまう |
| 隠ぺい | 文書が削除されても、誰が・いつ・なぜ削除したかが確認できない |
| 情報漏えい | 部署外の人が他部署の申請書類を自由に閲覧・ダウンロードできてしまう |
制度を守るとは、こうしたリスクが“起きないように設計されている”ことを意味します。
セキュリティは「守ること」ではなく「壊されない構造を作ること」
制度を支える記録は、「守ってください」と呼びかけるだけでは守られません。
重要なのは、制度的に壊せない・書き換えられない・消されない・見られない構造を設計段階から持っていることです。
これを実現するには、以下のような仕組みがワークフローシステムにあらかじめ備わっている必要があります。
制度的セキュリティを担保する4つの仕組み
① 操作ログの保存と検索機能
- 誰が、いつ、どの文書を作成・閲覧・承認・出力・削除したかを自動で記録
- ログは管理者が検索・確認でき、操作の正当性・追跡性を担保
② 承認後のロック／改ざん防止
- 承認完了後の書類は、PDF化・ファイルロックされ、編集不可に
- 修正が必要な場合は、再申請／取消申請などの別プロセスを経る構造に
③ 削除操作の制限と廃棄ログ
- 承認済み文書の削除は、保存期間内は不可／保存期間満了後も申請→承認→実行の廃棄フローを経る
- 廃棄された書類についても、「誰が・なぜ・いつ削除したか」を記録
④ アクセス制御と最小権限設計
- 文書の閲覧・出力・編集は、部署・役職・ロールごとに制限
- 「見てはいけない人が見られる」「誰でも設定が変更できる」といった制度破壊を防止
これからのワークフローには、「制度を壊させない設計」が必要
制度とは、「ルールが守られていることを証明できる状態」でなければ意味がありません。
ワークフローシステムには、制度を“守らせる”のではなく、“破れないようにする”構造が求められています。
これは単なるセキュリティ対策ではなく、制度ガバナンスそのものをシステムとして体現する設計思想であり、それを持っているかどうかが、これからのシステム選定では大きな差になります。
まとめ
- ワークフローが通っただけでは制度にならない。「記録が正しく残る構造」こそが制度の信頼性を支える
- 操作ログ、文書ロック、削除制限、アクセス制御など、制度を“壊せない仕組み”を最初から持っていることが重要
- ワークフローシステムは、制度ガバナンスのインフラであるという認識のもと、設計段階からセキュリティと統制が組み込まれていることが求められる
よくある制度リスク①：承認後も文書が編集できる・差し替えられる～「記録されている」は、「正しく残っている」とは限らない～
承認完了後も「編集できてしまう」仕組みが危うい理由
ワークフローシステムでは、申請が承認され、処理が完了した時点で文書のライフサイクルは一区切りを迎えます。
しかし、承認された文書がその後も自由に編集・差し替えできる状態であれば、その記録は制度的には不完全です。
たとえば、以下のようなケースは非常に危険です。
| ケース | リスク |
| 金額を変更して再保存できる | 不正・過剰請求の隠蔽や、事後的な内容改ざんの温床になる |
| 添付ファイルを差し替えても記録が残らない | 証拠資料の信頼性が損なわれ、監査や調査時に説明がつかない |
| 承認完了後でも「編集」ボタンが表示されている | 操作ミスによる破損や、制度外の改変が発生する |
承認が通っても、「中身が後から変えられる」状態では、その記録は“信頼に足る証拠”にはなりません。
「変更可能な記録」は、制度としての証拠力を失う
制度設計において重要なのは、「いつ・誰が・どのような判断をしたか」が固定された状態で保存されることです。
これにより、その文書が将来的に監査・説明・法的証拠として活用できる土台になります。
しかし、承認済み文書が「自由に編集できる状態」で残っていると、以下のような問題が発生します。
- 過去の判断内容が確定しておらず、説明責任が果たせない
- 関係者の合意内容が保証されない
- 誤って改変された場合の復旧ができない
制度としての信頼性を維持するには、「承認されたら、その記録は“動かない”」構造が必要です。
「承認後は編集できない」構造が制度を支える
制度の信頼性を守るには、承認済みの文書が「確定文書」として保存されることが必要です。
これをシステム上で担保するには、以下のような機能が求められます。
1. 文書のロック機能
- 承認が完了した時点で、その文書を「編集不可」にする
- フォームの入力内容・ファイル添付・承認履歴など、すべてが固定された状態で保持される
ジュガールでは、フォーム内容・承認履歴・ファイル添付を自動ロックし、編集・削除不可に。
2. PDFへの自動変換・保管
- ロックされた文書をPDF形式で保存し、改ざんが困難な形式でアーカイブ
- 元の入力画面を再表示しても、編集操作は不可／表示のみの状態に
ジュガールでは、完了文書は自動でPDF化され、文書台帳に記録。ファイル名・文書IDで検索可能。
3. 修正が必要な場合は“再申請”で対応
- 承認後に変更が必要な場合は、「取消申請」「再申請」のフローを経るように制度設計
- 変更の理由・日時・申請者を記録し、過去の記録と新しい記録が履歴として併存する構造に
ジュガールでは、修正が必要な場合は、「取消」→「再申請」として手続きが再スタート。前履歴は残したまま新規記録が追加される。
「編集できない」ことが、制度の信頼性をつくる
ワークフローシステムにとって大切なのは、「柔軟に動かせること」だけではありません。
「制度として確定させ、動かさない記録を残せること」が、内部統制・監査対応・証拠性において不可欠です。
この観点に立てば、編集の自由度ではなく、「どの段階で記録を確定させ、変更にはどう再ルール化するか」が制度設計上の本質です。
まとめ
- 決裁後も編集・差し替えが可能な状態では、記録の信頼性が成立せず、制度として不完全
- ロック／PDF化／再申請フローの仕組みを組み込み、「確定文書」として保存できる構造が必要
- ジュガールは、文書の信頼性を制度設計の一部として支え、“改ざんできない仕組み”で制度ガバナンスを強化している
よくある制度リスク②：「誰が何をしたか」が証明できない～証跡がなければ、制度は“存在していない”のと同じ～
「誰が何をしたかが分からない」は、制度上の重大な欠陥
ワークフローシステムを運用していても、次のような声が監査時に上がることがあります。
- 「誰が承認したのかは分かります。でも、いつかは分かりません」
- 「このファイル、誰が見たかは記録していません」
- 「誰かが削除したようですが、履歴は残っていません」
このような状態では、承認や保存といった“制度行為”の信頼性そのものが崩れます。
制度の中核は、「記録が改ざんされていないこと」だけでなく、
「記録が、誰によって、いつ、どう処理されたかを後から証明できること」にあります。
ログがなければ、すべての操作は“なかったこと”にされかねない
操作ログや履歴がなければ、制度運用上は次のような深刻なリスクが生じます。
| 操作 | ログがない場合に起きること |
| 承認 | 本当に承認されたのか？ なりすましではないか？ の検証ができない |
| 閲覧 | 機密文書が誰に見られたか分からず、漏えい時に追跡できない |
| 出力 | 情報を持ち出された場合に、証拠が残らない |
| 削除 | 「なぜ消えたのか」「誰が削除したのか」が説明不能になる |
制度を守るには、「承認フローが通っていること」ではなく、すべての処理に対して“証明可能な履歴”があることが必要なのです。
ログの記録・検索・証明までを「制度として組み込む」
証跡管理は、単に「ログを残している」だけでは不十分です。
本当に求められるのは、以下のような制度設計と運用の仕組みです。
① 自動でログが記録される
- ユーザーによる操作（申請／承認／閲覧／出力／削除 など）をすべて自動的に記録
- 手動操作や一部操作のみではなく、あらゆるプロセスを漏れなく取得
ジュガールでは、申請・承認・差し戻し・取消・閲覧・出力・削除など全操作を、ユーザーID、日時、操作対象文書、IPアドレス、操作区分などとともに自動記録。
② 管理者がログを検索・出力できる
- 日時・ユーザー・操作種類などでフィルタ検索できる仕組み
- ログをCSVやPDF形式で出力し、監査・調査・内部統制レポートとして活用可能
ジュガールでは、管理画面より操作ログの検索・抽出・ダウンロードが実行可能。
③ ユーザーにはログの改変権限がない
- 操作ログの編集・削除ができないように設計
- ログそのものが制度の一部として「不可侵な記録」であることを前提とする
ジュガールでは、ログは編集・削除不可。制度的に「改ざんできない証跡」を保証。
ジュガールにおける操作履歴管理の仕組み
ジュガールでは、「制度として証跡を残せる」ことを前提とし、以下のようなログ管理機能が標準で組み込まれています。
操作記録は“確認のための参考情報”ではなく、
「制度として記録が成立していること」を証明するための必須要素です。
まとめ
- 「誰が、いつ、何をしたか」が残らなければ、ワークフロー制度は“存在していない”のと同じ
- 操作ログの網羅的記録・改変不可性・検索性・監査出力対応が揃って、はじめて“制度としての証跡管理”が成立する
- ジュガールは、制度運用における操作の信頼性をログ構造そのものから支える設計となっており、監査や内部統制においても“証明できる制度”を実現している
よくある制度リスク③：閲覧・出力の制御が曖昧で、情報漏えいが起きやすい～「見えてはいけない人に見えている」構造が制度を壊す～
閲覧制限が曖昧なままでは、制度の信用が崩れる
ワークフローシステムで申請・承認を行っていても、「承認済みの文書が誰にでも見られる」「制限なくダウンロード・印刷できる」という構造になっているケースは少なくありません。
その結果、以下のような制度上のリスクが生まれます。
| ケース | リスク |
| 他部署の社員が、関係のない稟議書を閲覧できてしまう | 組織の権限階層を無視した構造 → 内部統制の欠如 |
| 社員が全社の申請データをCSVで出力できる | 個人情報・取引情報が漏えいするリスク 悪用可能性 |
| 課長権限でも役員向けの承認文書を閲覧・編集できる | 誤操作・誤認・意図的な改変による制度崩壊 |
「閲覧できてしまう」は、“操作できてしまう”よりも見落とされやすいリスクです。
制度として守られるべき情報が、見るべきではない人に見られている構造では、たとえ正しい運用をしていても「制度として信頼できる」とは見なされません。
なぜ“最小権限原則”が必要なのか？
最小権限原則（Least Privilege Principle）とは、
「業務遂行に必要な最小限のアクセス権限のみを付与する」
という考え方で、情報セキュリティと制度設計の両面で不可欠な原則です。
この原則が守られていないと、次のような問題が起こります。
- 不要な情報へのアクセスが常態化し、内部不正・なりすましの温床となる
- 社員異動・退職後も権限が放置され、アクセス権限の管理が破綻
- 実際の業務責任と情報アクセス範囲が一致せず、制度運用が形骸化
制度を守るためのアクセス制御・出力制限の設計ポイント
閲覧・出力の自由度を高く設定しすぎると、制度の信用性が損なわれ、監査や内部統制の観点から不備と判断される恐れがあります。
これを防ぐには、以下のような「見るべき人だけが見られる」構造を制度設計とともにワークフローに組み込む必要があります。
① アクセス権限のロール設計
- 部署・役職・ロール単位でアクセス可能な文書を制限
- 例：人事関連書類 → 人事部のみ閲覧可、経理関係 → 経理部・上長のみ閲覧可
- 閲覧可能範囲は“職務と連動”して変化するように設計
ジュガールでは、文書ごとに部門・役職・ロール別に閲覧可否を設定。閲覧履歴も記録。
② 出力・ダウンロードの制限設定
- 閲覧は可能でも、出力やファイル保存を禁止するオプションを設計段階で設定
- 一部文書はPDF化や印刷出力に対してパスワード保護や操作ログを必須とする
- ダウンロード実行者・日時をログで保存し、追跡可能にしておく
ジュガールでは、管理者のみ出力可能、またはロール単位で出力可否を制限。出力操作はログに残る。
③ 異動・退職時の自動制御
- ログインIDのロール変更に伴い、自動的にアクセス権限を切り替える構造
- 旧所属の書類にアクセスできないよう、リアルタイムでアクセス制御を反映
ジュガールでは、保存期間内は削除不可。閲覧可能期間の設定も可能（例：30日間のみ開示）。
制度を壊すのは、機能の不備ではなく、「誰でも見られてしまう」設計の曖昧さです。
まとめ
- 制度文書は、見るべき人にしか見せない構造がなければ、情報漏えい・誤操作・制度崩壊のリスクを招く
- アクセス制御・出力制限・ロール管理を「制度設計の一部」として取り込み、システム設計で担保すべき
- ジュガールでは、こうした“見えるべき人にだけ見える”構造を制度運用と一体化させることで、
セキュリティと統制を同時に成立させる制度運用基盤を実現している
通知・リマインドも制度設計の一部である～「気づかなかった」では制度が回らない～
制度が守られない理由は、「忘れていた」「通知を見ていない」
どれだけ制度が正しく設計されていても、申請や承認が滞る原因の多くは、意図的なルール違反ではありません。
むしろ、「通知に気づかなかった」「申請期限を知らなかった」「メールが埋もれていた」といった見落としや習慣化の不備によって制度が止まってしまうケースが多く存在します。
制度を制度として成立させるには、「気づける仕組み」が前提条件です。
「通知されるだけ」では不十分。“届き方”と“気づき方”が問われている
単に「メールで通知した」「画面にアラートを表示した」だけでは、制度運用の観点では不十分です。
実際の制度設計では、次のような問題が頻発します。
| 問題 | 典型的な現象 |
| 通知が埋もれる | 日々の業務メールに紛れて見逃される 未読のまま処理されない |
| タイミングがずれる | 出張から戻った翌日に気づく ]申請の締切が過ぎている |
| ルートの途中で滞留する | 承認者が見逃し 気づかないまま1週間放置される |
| リマインドが機能していない | 一度通知されて終わり。再通知されず放置されるケースが多発する |
これらを防ぐには、通知の頻度や内容だけでなく、「誰に・いつ・どんな経路で届くか」を含めた制度設計が必要です。
制度が動く通知設計とは？──4つの基本構造
通知・リマインドは、「流すこと」が目的ではありません。
申請・承認・処理の行動を“引き出す”ことが目的であり、そのためには次のような設計が制度運用に不可欠です。
① 提出依頼：動いてもらうための“指名された通知”
- 対象者に対して「あなたがこの申請を提出してください」と個別に通知
- 提出状況（提出済・未提出）を管理画面で一覧化／進捗管理と制度遵守の支援に
- 定期依頼にも対応 → 例：「月末までに全員が日報を提出」など
ジュガールでは、申請を“任意”にしない。対象者・締切・提出状況を制度として管理。
② チャット通知連携：見逃されない経路で届ける
- LINE WORKS／Microsoft Teamsなど、業務で日常的に使われているチャットツールと連携
- 承認依頼・提出依頼がチャットに届き、通知から直接処理画面へ遷移できる
- 業務メールよりも“リアルタイムで気づきやすい”経路を確保
ジュガールでは、チャット連携により現場の行動を引き出す“見逃させない”通知経路を確保。
③ 既読管理：読まれたかどうかを制度的に証明する
- 通知や通達に対して、「誰が・いつ・読んだか」を記録する仕組みを持つ
- 「周知済です」と言える状態をログで担保／未読者への自動フォローも可能に
- 通知履歴が「通達された証拠」として制度の一部になる
ジュガールでは、「通達済み」の証跡が制度ログとして残る。監査・社内統制に対応。
④ リマインド制御：何度でも、適切に促す
- 一度通知して終わりではなく、「処理されていない申請」「期限が迫った申請」に対して自動で再通知
- 日時・条件に応じたカスタムリマインドも設定可能
- “忘れていた”が制度上のリスクにならないよう、通知設計で先回りする
ジュガールでは、処理漏れ・承認滞留を防ぐ制度的担保機能・自動再通知設計を搭載。
まとめ
- 通知・リマインドは「お知らせ」ではなく、「制度を動かすためのインフラ」
- 「届いていた」は証明にならず、「読んだ」「動いた」まで制度構造として担保すべき
- ジュガールでは、提出依頼・チャット通知・既読ログ・リマインド制御などを通じて、
制度が“使われる・守られる”状態を通知設計から実現している
ジュガールが提供する「制度セキュリティ」の標準構造～“記録を守る”のではなく、“記録が守られる構造”を最初から持っている～
ワークフローに必要なのは、「制度を壊せない構造」
ここまで紹介してきたように、制度を支えるワークフローには、次のようなセキュリティ要件が不可欠です。
- 承認済みの文書を編集できないこと（改ざん防止）
- 誰が・いつ・何を操作したかが記録されていること（証跡保持）
- 文書の削除・出力・閲覧が制限されていること（漏えい防止）
- 誤操作やなりすましが制度を破壊しないこと（ガバナンス担保）
- 通知・リマインドが行動を促す制度として機能していること（運用支援）
これらは“あとから追加する機能”ではなく、制度そのものを運用できる構造として最初から持っていることが求められます。
ジュガールが提供する「制度セキュリティ」の設計一覧
ジュガールでは、制度ガバナンスを支えるために、次のような仕組みがシステムに標準搭載されています。
| セキュリティ項目 | ジュガールの対応 |
| 文書の改ざん防止 | 承認後の自動ロック PDF変換 編集不可状態で保存 再申請フローあり |
| 操作ログ・証跡管理 | 申請・承認・閲覧・出力・削除など、すべての操作を自動記録 ]検索・出力に対応 |
| アクセス制御 | 部門・役職・ロールごとに閲覧・出力・削除の可否を設定可能 異動時も自動反映 |
| 出力・削除制限 | 出力は権限管理下に 削除は保存期間経過後、廃棄フローを経て実行 廃棄ログ付き |
| 通知・既読管理 | チャット通知（Teams／LINE WORKS）、提出依頼、リマインド、既読確認を制度設計と一体化 |
セキュリティ対策ではなく、“制度構造”としての設計思想
ジュガールの強みは、セキュリティ機能が「制度の土台」として一体化している点にあります。
- 「守るべきものが守られているか？」ではなく、
- 「そもそも壊されない仕組みになっているか？」を出発点とする設計
これは、単なるITセキュリティ対策ではなく、制度運用を“壊れない仕組み”として定義する設計思想です。
まとめ
- 制度を守るには、「守る努力」ではなく、「守らざるを得ない構造」が必要
- ジュガールは、ログ保存・ロック・権限制御・通知設計などを、制度ガバナンスの標準構造として提供
- 監査・内部統制・電子帳簿保存法対応まで、“記録として信頼される制度”を支える基盤となっている
