権限と承認 〜ユーザー信頼性に繋がる管理画⾯の根幹について〜 2025年10⽉23⽇ @ CRE Camp #3 株式会社ベースマキナ ⾼橋 誠⼆（@__timakin__） 

”管理画⾯開発時に、権限や承認フローを どんな軸‧粒度で整理すると無理なくメンテできるか？” 今⽇のテーマ 

目次
 ✔ 権限管理・承認は信頼獲得の屋台骨 
 ✔ 権限管理・承認の開発で生じる課題 
 ✔ ”無理がない”権限・承認のあり方とは 

髙橋誠⼆（たかはしせいじ） 株式会社ベースマキナ 代表取締役社⻑ 略歴 株式会社ディー‧エヌ‧エー、株式会社Gunosy等で ソフトウェアエンジニアとして勤務。開発業務に加えて プロジェクトマネジメント‧新規事業‧中途採⽤など幅広い業務に従事。 Go⾔語を中⼼とした技術カンファレンスへの登壇やOSS活動等も⾏う。 2020年に株式会社ベースマキナを創業。代表として経営に従事。 社内管理画⾯‧内製ERPをノーコード‧ローコードで 開発できるサービス「ベースマキナ」の運営に責任を負う。 @__timakin__ ハイライト ソフトウェアエンジニア 起業 好きなこと 写真：よく撮ります。    東京‧パリ‧ブダペストなどの国際コンペで賞を頂きました。 作家ものの⾷器集め：よく割ります。 

ヒューマンエラーを減らせる管理画⾯を 数分で⽴ち上げるローコードSaaS 「BaseMachina（ベースマキナ）」は 情報漏洩や誤操作など、 社内システムのヒューマンエラーを減らせる 安全な管理画⾯を、数分で⽴ち上げるローコードSaaSです。 5 

6 管理画⾯に必要な機能群をまるっとご提供 

カスタマーサポート‧サクセスのUIでご利⽤いただくこと多数。 

承認フロー
 権限管理
 権限管理‧承認フローは⽬⽟機能。今回はこちらのお話。 

権限管理‧承認は信頼獲得の屋台⾻ セクション１ 

そもそもなんで権限管理や承認が必要なのか？ その１：お客様に情報の取扱い⽅法についてご安⼼いただくため お客様の信頼獲得には、情報の取扱いを丁寧にしていることが不可⽋。 という性悪説に基づく疑念が⽣じる隙間をなくすことでご安⼼頂き、 サービスのご利⽤やご質問‧フィードバックの共有に集中してもらうことが重要。 社内の誰でも機密情報が⾒れてしまってるんじゃないの？ 「押し間違いでアカウントが消えたりするんじゃないの？」 「都合が悪い場合、 履歴情報を改ざんしたりするんじゃないの？」 

そもそもなんで権限管理や承認が必要なのか？ その２：お客様への対応ができる⼈数を増やすため 基本的にお客様のデータの管理責任はソフトウェアエンジニアにある。 そのため、お客様への対応時に機微情報の閲覧‧変更を⾏う場合、 CREならまだしも、ノンエンジニアの担当者の⽅が素通りで対応を⾏うのは 不整合発⽣時にリカバリーできない危険をはらんだある種の越権⾏為になってしまう。 

そもそもなんで権限管理や承認が必要なのか？ その２：お客様への対応ができる⼈数を増やすため 基本的にお客様のデータの管理責任はソフトウェアエンジニアにある。 そのため、お客様への対応時に機微情報の閲覧‧変更を⾏う場合、 CREならまだしも、ノンエンジニアの担当者の⽅が素通りで対応を⾏うのは 不整合発⽣時にリカバリーできない危険をはらんだある種の越権⾏為になってしまう。 ‧権限の管理が⾏き届いていて、必要最低限の操作だけができる ‧承認フローを経た”⼀時的な権限付与”を通じて、イレギュラー業務でも対応ができる  ※余談：承認 = ⼀時的な権限付与とも⾔えるため、権限管理と⼀緒に機能設計を考えたほうが良いです という仕組み化によって、エンジニアの⼿から業務を引き剥がすことができる。 結果、多様な職種のメンバーがお客様に向き合える。 

そもそもなんで権限管理や承認が必要なのか？ その３：機能以外でお客様に最⾼の体験を届けるため 気を遣う操作をスピーディに完結できるように業務を分担するには、細かな権限管理や承認フローが整備されている必要がある。 サービス上での⽀払い⼿続きが失敗したのですが... 「お問い合わせを承りました。 原因を調査しますのでお待ち下さい」 「⼀時的な不具合により⼿続きが 失敗したようで、誠に申し訳ございません。  引き落とし後の後続の処理が失敗したようです。  ⼀次対応として払い戻しを実施いたしました。 お⽀払い⾦の⾯はご安⼼いただければと存じます」 というお客様からの問い合わせに、どう応えるか？ 

特にいつ屋台⾻（MUST要件）化するか？ 権限管理や承認フローは⼀定規模以上のチームのカスタマー対応でMUST要件化する WANT要件で済ませてしまうフェーズ 
 ‧サービスに機微情報があまり乗っていない ‧エンジニアがデータ変更も含めて対応しないと会社が回らない といったタイミングはMUST要件に上がりにくい（そもそも他の開発をしないと死ぬので）。 

特にいつ屋台⾻（MUST要件）化するか？ ‧CSチームが3⼈以上で組織化されている ‧CS以外にも管理画⾯を触るとして、組織規模が10名を超えている くらいから、権限管理がMUSTに。 ‧お⾦（請求‧決済）にまつわるデータ変更 ‧エンプラ向けデータ出⼒の対応 などが必要になる事業タイミングで承認フローがMUSTに。 権限管理や承認フローは⼀定規模以上のチームのカスタマー対応でMUST要件化する WANT要件で済ませてしまうフェーズ 
 MUST要件になるフェーズ
 ‧サービスに機微情報があまり乗っていない ‧エンジニアがデータ変更も含めて対応しないと会社が回らない といったタイミングはMUST要件に上がりにくい（そもそも他の開発をしないと死ぬので）。 フェーズに⾒合った振る舞いをするために、権限管理や承認フローがMUSTに昇格される。 

「権限管理‧承認は信頼獲得の屋台⾻」のまとめ １：お客様に情報の取扱い⽅法についてご安⼼いただくため ２：お客様への対応ができる⼈数を増やすため ３：機能以外でお客様に最⾼の体験を届けるため の３つの理由で、権限管理‧承認が信頼獲得に効く。 これは事業フェーズが進むとMUST要件になる。 

理想はさておき... 実際に権限管理や承認フローが細かく組まれている 管理画⾯をお使いの⽅、どれくらいいらっしゃいますか？ 

権限管理‧承認の開発で⽣じる課題 セクション２ 

実際問題、権限管理や承認は仕組み化‧機能実装されてますか？ そんなに余裕なくないですか？実際こういう感じでは？ ケース１：忙殺
 CREとしてプロダクトの技術的な改善を通じてサポート負荷を下げたいが、 そもそも管理画⾯開発やワークフロー整備の前にサポートに忙殺されている。よって未整備。 ケース２：巨大な権限を行使しつつ承認なし 
 対応内容がスクリプト化はされているが、痺れるような管理者権限でデータアクセス。 なにかをブロックする承認フローはなく、⼀応Slackで声掛けして報告する。 ケース３：理想かと言われる微妙だが、前に勢いで作った管理体系がワークしている 
 権限は３、４種類くらい。危ない画⾯遷移導線やボタンを ユーザーの権限に応じて隠す。サーバー側でバリデーションをかけられてはいない。 承認フローは作業前にSlackで声かけして、OKが出たら作業する。 作業完了後にAPI経由でSlackの特定チャンネルに通知が送られる。 

なぜかくも開発に課題が⽣じるのか？ 

「社内改善のための⼯数がない」 

なぜかくも開発に課題が⽣じるのか？ 「社内改善のための⼯数がない」👈世の常ですし、もう少し分解しましょう ‧暗黙的な権限の区分けや業務フローの整理をヒアリングしながら後追いで⾏う必要がある。 ‧権限管理や承認のようなガバナンス要件は、細部を気にし始めると⼯数が指数関数的に増える。 ‧事業ドメインや業務内容によって権限体系、承認フローが異なる（ように感じる）ため、共通のナレッジがない。 ‧権限管理は特に、RBAC、ABAC、ReBACなどの、どのモデルを利⽤すべきかで検討に時間がかかる。 要件定義の課題 
 

なぜかくも開発に課題が⽣じるのか？ 「社内改善のための⼯数がない」👈世の常ですし、もう少し分解しましょう ‧暗黙的な権限の区分けや業務フローの整理をヒアリングしながら後追いで⾏う必要がある。 ‧権限管理や承認のようなガバナンス要件は、細部を気にし始めると⼯数が指数関数的に増える。 ‧事業ドメインや業務内容によって権限体系、承認フローが異なる（ように感じる）ため、共通のナレッジがない。 ‧権限管理は特に、RBAC、ABAC、ReBACなどの、どのモデルを利⽤すべきかで検討に時間がかかる。 要件定義の課題 
 ‧何やら重厚なライブラリやIDaaS付随の機能でしか実装ができず、キャッチアップ‧経済的なコストがかかる。 ‧ベストプラクティスに沿っているか不安で、ドキュメントを読み進めながら暗中模索する ‧ガバナンスを管掌するSREチームとの共同作業になるか、だれが⾳頭を取ればいいのかわからなくて空中分解する。 実装の課題 
 

なぜかくも開発に課題が⽣じるのか？ 「社内改善のための⼯数がない」👈世の常ですし、もう少し分解しましょう ‧暗黙的な権限の区分けや業務フローの整理をヒアリングしながら後追いで⾏う必要がある。 ‧権限管理や承認のようなガバナンス要件は、細部を気にし始めると⼯数が指数関数的に増える。 ‧事業ドメインや業務内容によって権限体系、承認フローが異なる（ように感じる）ため、共通のナレッジがない。 ‧権限管理は特に、RBAC、ABAC、ReBACなどの、どのモデルを利⽤すべきかで検討に時間がかかる。 要件定義の課題 
 ‧何やら重厚なライブラリやIDaaS付随の機能でしか実装ができず、キャッチアップ‧経済的なコストがかかる。 ‧ベストプラクティスに沿っているか不安で、ドキュメントを読み進めながら暗中模索する ‧ガバナンスを管掌するSREチームとの共同作業になるか、だれが⾳頭を取ればいいのかわからなくて空中分解する。 実装の課題 
 これらすべてのリスクを飲み込んで進める⼯数がない 

「権限管理‧承認の開発で⽣じる課題」のまとめ ‧現実問題、整った権限管理や承認フローを整備する余裕はない ‧その理由は「社内改善のための⼯数がない」と⽚付けられがち  →しかし、分解すると仕様検討が難しいという「要件定義の課題」と、   ベスプラがわからない、旗振り役が曖昧で空中分解する、という「実装の課題」に帰着する 

これなら無理ないんじゃないか？という 妥協案を考えたので、共有です 

”無理がない”権限‧承認のあり⽅とは セクション３ 

ベースマキナが考える、運⽤に無理がない権限管理‧承認 操作内容を システム管理と それ以外に分ける 基本は権限も承認も RBACやグループを ベースに考える 作業環境と 作業者のグループのか け合わせで 体系化する 

こちらはポイント２，３で説明 運⽤に無理がない権限管理‧承認の案 ポイント１：操作内容をシステム管理とそれ以外に分ける システム管理 
 それ以外
 ‧管理画⾯にアカウントを追加する ‧ログを閲覧‧出⼒する ‧権限設定をする ‧お客様の情報を閲覧する ‧アプリ内通知やバナーを⼊稿する ‧法⼈事業者の審査状況を更新する ☝ まずここに境界線を引く 業務と社内調整の権限は別なので、分離する こちらは管理者か否かの２種類、 もしくはアカウント管理権限だけ分離して３種類にする 

‧ユーザー情報管理、閲覧 ‧決済情報管理 ‧お知らせ管理 運⽤に無理がない権限管理‧承認の案 ポイント２：基本は権限も承認もRBACやグループをベースに考える ロール例
 経験則に過ぎませんが、⼤体の管理画⾯においては ロールと、それらを持つグループの２階層を作り、複数グループをユーザーに紐づけ可能にすることで事⾜ります。 組織階層をグループに反映（マネージャーとそれ以外を分けるなど）するのがおすすめです。 これには承認と権限管理に使うデータ構造を共通化させられるというメリットがあります。 ‧カスタマーサポート ‧カスタマーサポート（マネージャー） ‧エンジニア ‧セールス ‧財務担当 ロールを持つグループ例 
 

運⽤に無理がない権限管理‧承認の案 ポイント３：作業環境と作業者のグループのかけ合わせで体系化する 管理画⾯開発でよくあるのが、「開発‧ステージング‧本番などの複数環境があることの想定漏れ」です。 本番環境 > ステージング環境 > 開発環境と、扱われるデータの内容や担保したい品質に応じて、 権限管理や承認フローの要不要が変わります。 ポイント２のロールとグループのどれで認可‧承認扱いとするかを作業環境ごとに切り替えると、 動作検証から本番稼働までをスムーズに⾏き来できる管理画⾯が出来上がります。 

運⽤に無理がない権限管理‧承認の案 ポイント３：作業環境と作業者のグループのかけ合わせで体系化する 管理画⾯開発でよくあるのが、「開発‧ステージング‧本番などの複数環境があることの想定漏れ」です。 本番環境 > ステージング環境 > 開発環境と、扱われるデータの内容や担保したい品質に応じて、 権限管理や承認フローの要不要が変わります。 ポイント２のロールとグループのどれで認可‧承認扱いとするかを作業環境ごとに切り替えると、 動作検証から本番稼働までをスムーズに⾏き来できる管理画⾯が出来上がります。 例）払い戻し業務の権限‧承認。誰でも動作検証はして良いが、本番での作業はCSマネージャーのみ。 本番
 ステージング 
 開発
 エンジニア 
 サポート
 サポート（マネージャー） 
 権限なし 権限あり‧承認不要 権限あり‧承認不要 権限なし 権限あり‧承認不要 権限あり‧承認不要 権限あり‧承認必須 権限あり‧承認不要 権限あり‧承認不要 

「”無理がない”権限‧承認のあり⽅とは」のまとめ ‧業務と社内調整の権限は別物として分離する ‧ロールとそれを使ったグルーピング表現でシンプルにRBACベースで権限や承認フローを設計する ‧上記にプラスして、作業環境とのかけ合わせで対照表を作る というのが現実的な権限‧承認のあり⽅。 

34