社内承認フロー用のウェブアプリをノーコードで作る方法

社内承認ウェブアプリがやるべきこと

社内承認ウェブアプリは「誰かが何かを必要としている」状態から「決定が下され、後で証明できる」までリクエストを動かす仕組みです。優れたシステムは、プロセスがチームごとに異なっても、いくつかのコア機能を一貫して実行します。

サポートすべきコアフロー

ほとんどの社内承認フローは次を含みます：

• リクエスト提出：最初に適切な詳細（と添付）をキャプチャするフォーム
• レビュー：1人以上が情報を確認し、質問したり修正を求めたりする
• 承認／拒否：オプションの理由や次のステップを伴う明確な決定
• 記録保管：リクエスト、決定、タイムスタンプ、コメントを一箇所に保存

現実のよくある例

多くのプロセスで同じパターンが見られます：

• 購買依頼（予算責任者 → 財務 → マネージャー）
• コンテンツ承認（草案 → 法務 → ブランド → 公開）
• アクセス申請（社員 → マネージャー → IT）
• ポリシー例外（申請者 → コンプライアンス → 経営）

なぜノーコードで十分なことが多いか

ノーコードツールは、チームが素早くリリースし、週単位で反復し、プロセスを運用する人たちに所有権を残すことができるため適しています。フォーム、ルーティングルール、通知、ダッシュボードを開発チームの順番を待たずに構築できます。

それでもエンジニアが必要な場合

高度に条件分岐するルーティング（分岐が多い）、厳格なデータレジデンシー要件、カスタムSSO制約、ミドルウェア必須の複雑な連携などがある場合はエンジニアの支援を検討してください。多くの組織では、UIはノーコードで対応し、エンジニアがギャップを埋める形になります。

完全なカスタム開発に踏み切らずにもう少し自由度が欲しい場合、Koder.ai のようなvibe-codingプラットフォームは中間の選択肢になります：チャットでワークフローを記述するとアプリ（一般的にフロントはReact、バックはGo＋PostgreSQL）を生成し、ソースコードのエクスポート、デプロイ／ホスティング、スナップショット、ロールバックなどのオプションを提供します。承認プロセスがシンプルから堅牢化する過程で有用です。

プロセスを選び、成果を定義する

ビルダーを開く前に、まず最初に手掛ける社内承認ワークフローを1つ選んでください。目的は価値を素早く証明し、同じパターンを他の承認フローに再利用することです。

「高痛み・低複雑さ」のフローから始める

最初の候補として適しているのは通常：

• メールやチャットで多くのやり取りがある
• 最終的に明確な「はい／いいえ」の決定がある
• 承認者が少数（1～3名）で手順が繰り返し可能

例：閾値以下の購買、休暇承認、特定テンプレートのコンテンツ／法務レビュー、基本的なベンダーオンボーディング。

トリガー（何がプロセスを開始するか）を定義する

フォームから承認に至るプロセスで「提出」が何を意味するかを具体的にします：

• 誰が提出するか：申請者、マネージャー、共有チーム受信箱？
• 必須データ：意思決定に必要な必須項目（金額、コストセンター、ベンダー名、期日、正当化）は？
• 添付：期待されるファイル（見積書、契約案、スクリーンショット）は？

承認者が同じ不足情報を繰り返し要求するなら、それをv1で必須にしてください。

ステークホルダーと意思決定ポイントを列挙する

関与するすべての人（またはロール）と、どこで決定が行われるかを書き出します：レビュアー、承認者、財務、法務、休暇時の代理者など。さらに「差し戻し」や「追加情報要求」といった“エッジ”な決定も記載してください。これらがフォローアップの多くを生みます。

成功基準を設定する（うまくいったと判断する方法）

2～3つの測定可能な成果を選びます：

• サイクルタイムの短縮（例：5日→2日）
• フォローアップの減少（「これどこ？」のメッセージが減る）
• ステータスの可視性向上（申請者が最新状況をセルフサービスで確認できる）

開始・終了・成功指標を定めれば、残りのワークフロー自動化の選択が簡単になります。

作る前に承認パスをマップする

ビルダーに触る前に、承認パスを1ページにマップしてください。これによりリクエストが詰まったり、間違った人に回ったり、終わりが見えないまま振り回される“ほとんど動く”ワークフローを防げます。

平易なステップとして書く

読み上げられるシンプルな骨子から始めます：

Submit → Review → Approve/Reject → Close

各ステップに対して、誰が（ロールまたはチーム）、何を見る必要があり、何を決定できるかを名前で示します。1文で説明できないステップは、通常複数のアクションを隠しているため分割すべきです。

直列レビューか並列レビューかを決める

レビューがどのように行われるかを明確にします：

• 直列：順番に（申請者 → マネージャー → 財務）。順序が重要なときに最適。
• 並列：複数が同時（セキュリティ＋法務）。速度重視のときに最適。

並列フローには「完了」のルールが必要：全員承認、誰か1人でOK、過半数 のどれかを今決めてください。後で変えると再構築が必要になることが多いです。

拒否時の動作を定義する

拒否は以下の意味を持ち得ます：

• 編集して再提出：申請者へ差し戻し、履歴を残す
• 停止：リクエストを拒否として終了し、新しい試みは新規申請として開始

コンプライアンスと報告の要件に合った方法を選んでください。一般的には「編集して再提出」が多いですが、元の決定は記録しておくべきです。

実際に発生する例外を追加する

非ハッピー・パスを事前にマップします：

• 緊急パス：可視性やステップを簡略化したファストレーン
• 不在時：代理承認者や委任ルール
• タイムアウト：リマインダー、エスカレーション、X日後の自動再割当

紙に書いておけば、構築は設定作業になり、推測で作るより確実です。

キャプチャして保存するデータを設計する

ノーコードの承認アプリは、データモデルがシンプルで一貫していて後でレポートしやすいときに最も効果的です。画面を作る前に、どのレコードを保存し、それらがどう関連するかを決めてください。

小さなコアデータモデルから始める

多くの社内承認ワークフローは少数のテーブル（またはコレクション）で90%をカバーできます：

• Request：承認対象のメイン項目（購買、ポリシー例外、出張、採用など）
• Person：申請者と承認者（ディレクトリから引くことが多い）
• Department：ルーティング、予算、レポート用
• Approval decision：各ステップの結果（誰が、何を、いつ）
• Comments：リクエストに紐づく議論メモ（場合によっては特定の決定に紐づく）

Requestを単一の真実の源として保持し、他はすべてそれに紐づけてください。

必須フィールドと任意フィールド（v1では最小限）

ルーティングや意思決定に必要な必須フィールドを定義します。典型的な必須項目：

• リクエストタイトル／要約
• 申請者（Person）
• 部署
• 金額／影響（該当する場合）
• 必要日
• 理由／正当化

その他は最初は任意にしておき、承認者が実際に何を求めるかを見てから追加してください。

添付と保持の期待値

どのドキュメントを保存すべきか（見積書、契約、スクリーンショット）と保持期間を事前に決めます。

• 添付が決定の証拠なら、Requestと一緒に保存する
• 保持ルールを設定（例：運用リクエストは12–24ヶ月、財務／法務は長め）
• 提出後にユーザーが添付を削除／差し替えできるかを明確にする

ステータスを標準化する

少数かつ明確なステータスセットを使って、進捗解釈のズレをなくします：

Draft → Submitted → In Review → Approved / Rejected → Completed

初期段階で多くのカスタムステータスを作りすぎないでください。統一されたステータスはフィルタ、リマインダー、レポートを容易にします。

ユーザーフレンドリーなフォームとページを作る

承認アプリの成否は使いやすさにかかっています。申請が面倒だったり次に何が起こるかわからなければ、人々はメールに戻ります。

実際に必要なコア画面

多くの承認ワークフローは以下の少数のページで対応できます：

• リクエストフォーム：新しいリクエストを提出する場所
• リクエスト詳細：リクエストを読み、ステータスを確認し、アクションを取る一箇所
• 承認者インボックス：自分に割り当てられた項目のキュー
• 管理設定：カテゴリ、閾値、テンプレート、ルーティング入力を管理

ナビゲーションは簡単に："新規申請"、"自分の申請"、"承認が必要"、管理者向けに"設定"。

少ない入力でより良いデータを集めるフォーム

最小必須項目から始め、条件付きフィールドを使ってフォームを短く保ちます。例："Purchase type = 新規ベンダー" のときだけ "ベンダー詳細" を表示、あるいはポリシーのチェックが外れているときだけ "例外理由" を表示。

ノーコードツールは、ドロップダウンや金額、部署に基づきセクションを表示／非表示にできる点で優位です。

ステータスと次のアクションを明確にする

各リクエストには以下を表示します：

• 現在のステータス（例：Draft → Submitted → Manager review → Finance review → Approved/Rejected）
• 現在誰が保持しているか
• 次に何が起こるか（閾値で追加承認が必要になるなど）

シンプルな進捗インジケーターと「Waiting on: <名前/役割>」の一行があれば、多くの「進捗どうなってる？」が消えます。

ガイダンスと検証で往復を減らす

難しい項目の下に短いヘルパーテキストや例を直接入れます（"署名済み見積書を添付（PDF）"、"コストセンターは 4102-Operations のように"）。検証で再作業を防ぎます：特定のリクエストタイプに必須の添付、金額の許容範囲、明確なエラーメッセージなど。

目標は、明確な質問の減少、意思決定の高速化、レポート用のクリーンな記録です。

ロール、権限、ルーティングルールを設定する

承認アプリを建物に例えるなら、ロールと権限は鍵で、ルーティングルールは廊下の案内標識です。正しい人のデスクに自動で届くように設計します。

コアロールを定義し（そして一貫して使う）

ワークフローで再利用するために少数のロールから始めます：

• 申請者：リクエストを作成・提出（購買、例外、休暇など）
• レビュアー：内容と文脈を確認。差し戻し可能
• 承認者：ステップの決定を下す（マネージャー、部署責任者、予算オーナー）
• Finance / HR：コストやコンプライアンス、人物関連の専門承認者
• 管理者：ワークフロー、項目、アクセスを維持。通常承認者ではない

各ロールが何をできるかをプレーンな言葉で書き出してからビルダーに入ってください。

ステップごとの権限を追加（閲覧、コメント、編集、承認）

誰でも全てを見たり編集できると承認は壊れます。各ステージでの権限を定義します：

• 誰が閲覧できるか（添付も含む）？
• 誰がコメントできるか（申請者に見えるかどうか）？
• 誰が編集できるか（通常は提出前の申請者のみ）？
• 誰が承認／拒否できるか、そして差し戻しは可能か？

実用的なデフォルト：提出後は主要フィールドをロックし（例：金額、ベンダー、日付）、編集は「差し戻し」アクション経由のみ許可する。

組織図に沿ったチームベースのルーティングを使う

個人名を固定すると拡張性が低いです。以下のようなルールを優先してください：

• 申請者のマネージャーが最初に承認
• 金額が閾値を超えたら部署の予算オーナーへルーティング
• GLコードや支出種別で財務を追加
• 人に関するリクエストはHRを追加

こうすると人が増減や移動してもワークフローは正しく動きます。

ストールを防ぐための委任とバックアップを計画する

休暇や受信箱過負荷で承認が止まりがちです。以下を追加します：

• 委任（承認者が期間指定で代理を設定）
• バックアップ承認者（X日でアクションがない場合に代替へルーティング）
• エスカレーションルール（タイムアウト後に承認者の上長へ通知）

これらのルールは管理を犠牲にせずスループットを守ります。

タスク、通知、リマインダーを自動化する

自動化により単なるフォームが信頼できる承認ワークフローになります。目的はシンプル：ステータスが変われば次の担当者へ自動でタスクが届くことです。

ステータス変更でルーティングを自動化する

Draft → Submitted → Manager Review → Finance Review → Approved/Rejected のようなルールを設定します。各ステータス変更で自動的に：

• 次の承認者（またはチーム受信箱）に割り当てる
• 所有権を更新する（誰が“ボールを持っているか”）
• フィールドをロック／アンロックする（例：提出後は申請者が金額を編集できない）

ルーティングルールは読みやすく保ってください。例外が必要なら（"金額 > $5,000 の場合 CFO 承認を追加"）データフィールドに紐づく明確な条件として定義します。

人が気づく通知を送る

最低限、2種類のメッセージを送るべきです：

• 「レビューが必要です」：リクエストタイトル、金額／タイプ、期日、承認ページへの直接リンクを含む
• 「決定が出ました」：申請者とウォッチャーに決定、承認者名、コメントを通知

社内で普段使っているチャネル（メール＋Slack/Teams等）を活用し、短く一貫したメッセージにしてノイズ化を避けます。

期日後のリマインダーとエスカレーション

承認が滞ると責任が曖昧になるため、以下を設定します：

• 期日前X時間／日でのリマインダー
• 期日後の2回目のリマインダー
• N日で未処理ならバックアップ承認者やエスカレーション先へ通知

エスカレーションは予測可能（かつ可視化）であるべきです。

重複や不足承認を防ぐガードレール

自動化は典型的な失敗モードも防ぎます：

• キー項目（例：ベンダー＋請求書番号）で重複をブロック
• 提出前の必須項目チェック
• Approve／Reject のボタンでのみステータス変更を許可し、自由編集を防ぐ

これらにより再作業が減り、すべてのリクエストが同じ道筋を通ることが保証されます。

可視化のためのダッシュボードと追跡を追加する

承認アプリは、誰もが何が待っているか、何が詰まっているか、何が完了したかを尋ねずに見られるときに初めて機能します。ダッシュボードは「このリクエストどこ？」をセルフサービスで答えます。

承認インボックスから始める

レビュアーが日々信頼して使える単一の場所を作ります。インボックスビューには：

• 自分に割り当てられた項目（優先度、現在のステップ付き）
• 期日間近（SLAや必要日ベース）
• 期限切れ（ハイライト、エスカレーションは別処理）

各行をアクション可能に：申請者、部署、金額／タイプ、提出日、期日、ワンクリック承認／拒否など。

実際の質問に合う検索とフィルターを追加する

多くの問い合わせは予測可能です：「今月のSalesからの保留リクエストを見せて」「先週火曜に提出したPOを探して」など。以下のフィルターを作ります：

• 申請者（または申請者チーム）
• 部署／コストセンター
• ステータス（draft, submitted, in review, approved, rejected, cancelled）
• 日付範囲（提出日、更新日、期日）

ツールがサポートすれば、"自分のチームの保留" や "財務キュー" のような保存済みビューを追加してください。

サイクルタイムとボトルネックを追う（機密情報を露出せずに）

ダッシュボードはすべてのフィールドを見せる必要はありません。運用指標に集中します：

• 平均最初の応答時間
• 平均総サイクルタイム
• ステップごとの滞留数（例："マネージャー承認"で詰まっている数）
• ボリュームの傾向（週次／月次）

集計数値や期間を使えば、機密内容を見せずに遅いステップを特定できます。

エクスポートとレポートを早めに計画する

まだBIツールを使っていなくても、レポーティングを簡単にしておきます：

• フィルタ済みリストのCSVエクスポート（例："前四半期に承認されたもの"）
• 財務やコンプライアンス用のシンプルな“レポーティング”テーブル／ビュー
• 可能なら定期レポートの送信を共有メールボックスへ設定

これにより突発的なレポート依頼が減り、ワークフローの改善が証明しやすくなります。

初日から監査ログとガバナンスを含める

承認が支出やリスク、顧客約束に影響するなら、"承認済み"という状態だけでなく証拠が必要です。ガバナンスは人々が既に依存し始める前に設計段階で追加するのが最も簡単で安価です。

実際の質問に答えられる監査ログを作る

アプリは「誰が、いつ、何をしたか」の明確な履歴を記録するべきです。最低限ログに残す項目：

• ステータス変更（Submitted → Approved/Rejected → Cancelled）
• 承認者が追加したコメント
• フィールド編集（何が変わったか、旧値／新値）
• 再割当や委任（誰が誰の代わりに承認したか）

監査ログは管理者とレビュアーが見られるようにし、全員にデフォルトで公開する必要はありません。

承認／拒否に意味のあるノートを必須にする

文脈のない承認は後で混乱を招きます。承認時はオプションコメント、拒否時は拒否理由の必須入力を追加します。これにより曖昧な"Rejected"が減り、再提出が速くなります。

実用的なパターン：

• 拒否には理由を必須（ドロップダウン＋自由記述）
• 理由は通知に含まれ、レコードに保存される
• 再提出は新しいバージョンを作り、履歴を保持する

データアクセス制御：最小権限で設計する

人が必要なものだけ見られるようにします：

• 申請者は自分の申請のみ閲覧
• 承認者は自分に割り当てられた申請（場合によってはチーム）を閲覧
• Finance/Legalは特定カテゴリを閲覧
• 管理者は設定変更とフル履歴の閲覧

ツールが行レベルの権限をサポートするなら使ってください。できないなら機密ワークフローは別アプリに分けます。

基本的なコンプライアンス：保持、削除、アクセスレビュー

レコードをどれくらい保持するか（例：1〜7年）、削除の扱い（ソフトデリートが安全）や誰が四半期ごとにアクセスをレビューするかを早めに決め、短い内部ページにドキュメントしてアプリからリンクしてください（例：/policies/approvals）。

既存ツールとの接続（重いエンジニアリングなしで）

承認フローは単独で動くことは稀です。ログイン、HRデータ、財務記録、チケッティング、メッセージングなど、人々が既に使っているシステムに繋ぐと採用が早まります。

アイデンティティから始める（SSOまたはユーザーディレクトリ）

Google Workspace、Microsoft Entra ID（Azure AD）、Okta等を使っている場合はSSOを有効にし、従業員に新しいパスワードを作らせないようにします。

利便性だけでなく、SSOはアクセス制御にも役立ちます：グループ（例："Finance","People Ops","IT"）をアプリ内ロールにマップし、手動管理を減らし誤った人が機密にアクセスするリスクを下げます。

参照データを既存システムから引く（HR、財務、チケット、CRM）

多くの承認リクエストは参照データを必要とします：

• HR：従業員名、マネージャー、部署、コストセンター
• 財務／ERP：ベンダー詳細、予算コード、発注番号
• チケッティング：リクエスト種別、優先度、既存のインシデント／変更
• CRM：アカウントオーナー、商談サイズ、契約段階

利用可能なネイティブコネクタを使えばフォームを自動入力でき、ルーティングも賢くなります（例：部署や支出閾値で振り分け）。

コネクタがない場合はWebhook／APIを使う

ツールに組み込み連携がなくても、完全なカスタムアプリを作らずに接続できます。多くのプラットフォームは：

• リクエストが提出／承認／拒否されたときにwebhookを送る
• 外部APIを呼んでレコードを作成／更新する（例：チケット作成、CRM更新）

ペイロードはシンプルに保つ：リクエストID、申請者、決定、タイムスタンプ、ターゲットシステムが必要とする主要フィールド。

エラー対策：リトライ、アラート、手動フォールバックを計画する

連携は失敗します—トークンの有効期限切れ、APIのレート制限、フィールド変更など。次を組み込みます：

• 自動リトライと明確な"失敗"ステータス
• 管理者チャネル（メール／Slack）へのアラート
• 手動フォールバック（同期を再実行するボタン、管理者が処理できるキュー）

これにより「承認されたが実行されていない」状況を防ぎ、信頼を損なわないようにします。

ワークフローのテスト、ローンチ、改善

承認ワークフローのテストは単に「ボタンが動くか」ではありません。本当に人が混乱せずにリクエストを開始から終了まで動かせるかが重要です。

実際のシナリオ（ハッピーパスだけでなく）でテストする

現実的なリクエストをいくつか作り、フルプロセスで回します：

• 承認と拒否（"変更を伴う拒否"を含む）
• 提出後の編集（何が許可され、誰ができるか）
• 添付ファイル（サイズ制限、命名、必須ドキュメント）
• 委任と不在対応（承認者が不在のとき何が起こるか）

ボトルネックを観察します：不明瞭な項目、承認者にとって文脈が不足している箇所、メールやチャットに戻らないと進められないステップなど。

パイロットを実行し、毎週フィードバックを集める

小さなグループ（1チームや1リクエスト種別）で始め、エッジケースに当たるまで十分な期間（通常2–4週）続けます。短い週次チェックインを設定し、フィードバックを1箇所で管理（フォームや共有ドキュメント）。優先度は往復を減らす修正：項目の明確化、ルーティング、通知タイミング。

人が実際に読むような短いガイダンスを書く

ドキュメントは短く実用的に：

• 提出に使う画面とレビューに使う画面
• "良い"リクエストの例（強い説明と添付の例）
• 期待される応答（いつコメントするか、いつ拒否するか）

ユーザーが既に見る場所に公開してください（例：/help/approvals）。

段階的に展開し、データで改善する

グループ単位で拡大します。早期の指標—サイクルタイム、拒否理由、各ステップでの滞留時間—を使ってルールやフォーム項目を改善します。小さな反復（週次／隔週）が信頼を維持し、ワークフローが回避策にならないようにします。

よくある失敗とその回避法

ノーコードツールでもいくつかのガードレールがないと承認フローは混乱します。以下は一般的な失敗モードと実用的な回避策です。

1) 最初から大きく始めすぎる（多すぎるステップや項目）

あらゆる詳細を"念のため"キャプチャしようとすると、誰も記入したくないフォームと維持が難しい承認パスになります。最小限の必須項目と、ポリシーを満たす最短の承認経路で始め、運用で詰まる箇所だけ追加してください。

2) ルールとアクセスのオーナーが不明確

ルーティングルールや承認者リスト、ロールベースアクセスに責任者がいないと例外が溜まり、アクセスが古くなり、役割変更で承認が止まります。

プロセスオーナー（およびバックアップ）を名指しで割り当て、変更は軽量なチェックリスト経由にし、承認者グループと権限を月次でレビューしてください。

3) 申請者の可視性不足

申請者がステータスや次の承認者を見られないと、手動で追いかけ始めます。現在のステージ、最終更新時刻、次の承認者（またはチーム）、推定SLAを含むステータスページを設けてください。マネージャー向けの簡易ダッシュボードも追加すると滞留が見えやすくなります。

4) 例外や緊急対応のための逃げ道がない

現実のワークフローには緊急リクエスト、不在承認者、ポリシー例外があります。

安全な例外処理を構築してください：定義されたファストパスをトリガーする"緊急"フラグ、委任ルール、理由記録付きのコントロール付きオーバーライド。

ワークフロー論理の変更（閾値、追加承認者、新しいリクエスト種別）が頻繁に予想されるなら、ガバナンスを失わずに反復しやすいアプローチを検討します。例えば、Koder.ai を使うとチャットベースの仕様から内部ワークフローアプリを素早く生成・進化させられ、必要に応じてソースコードをエクスポートしてより厳密な管理に移行できます。