契約締結権限が曖昧だと何が起こるか

権限の線引きが整備されていない会社では、次のような問題が繰り返される。

まず、越権による契約の有効性リスクだ。代理権のない者が会社を代理して契約した場合、原則として会社に効力は及ばない。ただし、相手方が「この人には権限がある」と信じる正当な理由があれば、表見代理（民法109条・110条・112条）が成立し、会社が責任を負う。このとき問題になりやすいのが、「あの担当者は以前も同じ手順で契約していた」という継続的な取引実態や、「部長代理」「契約担当責任者」のように権限を連想させる肩書きを名刺に使っていた事実だ。代理権の外形を会社側が作り出していた場合、その責任は会社に帰ってくる。

次に、承認者不在のまま案件が進むという問題がある。事業部が商談を進め、担当者が草案を作り、部長が「いいんじゃないか」と言い、法務が条項を確認し、なぜか総務が押印手続きを進める。誰も「この契約を会社として最終決定した」という意識を持たないまま、契約が締結される。

さらに、例外対応の常態化がある。「急ぎだから稟議は後で」「社長に電話で確認した」という処理が積み重なると、権限表・決裁基準が形骸化し、誰も規程を参照しなくなる。

以下は、権限が曖昧な場合によく起きる混乱のパターンをまとめたものだ。

これらはどれも、「誰が何をどこまで決めてよいか」が明文化されていないことに起因する。

代表権・代理権・決裁権限の違い

契約締結に関わる3つの権限概念は、それぞれ根拠・範囲・効力が異なる。混同したまま運用すると、「法的には有効だが社内承認がない契約」や「社内で承認されたが法的に無効な契約」が生じる。

この3つのうち最も重要なのは、「法的に締結できること（代表権・代理権の問題）」と「社内で承認されていること（決裁権限の問題）」は別の話だという点だ。代表取締役がサインすれば対外的には有効な契約になるが、それは社内の承認プロセスを経たことを意味しない。逆に、稟議が全役員の承認を得ていても、サインした担当者に代理権がなければ法的に問題が生じる。

どう線引きするか

権限の線引きには、金額・リスク・契約類型の3軸を組み合わせるのが基本だ。それぞれ単独では不十分であり、特に金額だけで切ると重大なリスクを見落とす。

金額基準の設計

最もわかりやすい基準は金額だ。「100万円未満は部長承認、1000万円以上は取締役承認」のような設計は多くの会社で採用されている。ただし、金額基準だけでは次のケースに対応できない。

• 少額だが排他条項・競業禁止・長期拘束を含む契約
• 1件ずつは基準以下でも合計が高額になるシリーズ発注
• 解除条件・違約金・損害賠償上限撤廃など、金額より条項リスクが高い契約

リスク基準・契約類型基準の設計

金額の補完として、契約が持つリスクの性質と類型で基準を設ける。下表は、金額・類型・リスクを組み合わせた整理例だ。会社の規模や業種に応じて数字・閾値は調整する。

この表はあくまで設計例だ。重要なのは、「金額が小さくても高レベルの承認が必要な契約類型」を明示的に定義することだ。たとえば競業禁止条項を含む契約は金額に関わらず役員承認とする、といったルールを類型基準として設けると、金額基準の抜け穴を防げる。

誰が何を判断するのか

契約締結に至るまでの過程では、複数の部門・役職が関与する。それぞれの役割を整理せずにいると、「誰かがやると思っていた」空白が生まれる。

ここで重要なのは「法務審査」と「承認」は別物だという点だ。法務が条項を確認してOKを出しても、それは「締結を承認した」ことではない。法的なリスク水準を評価しただけだ。最終的な事業上の判断と承認は、規程が定める承認権限者が行う。

現場でよく起きるのは、「法務がリスクありと言っているが、事業部はやりたい。部長は法務のNGサインを見て承認を躊躇している」というデッドロックだ。この構図は、「法務の役割＝リスクの提示」「承認権限者の役割＝そのリスクをテイクするかどうかの判断」という切り分けが曖昧なまま運用されているときに生じる。法務が「リスクがある」と言った場合、それはその契約を締結してはいけないという意味ではなく、「このリスクを承知のうえで判断してください」というメッセージだ。最終的に承認するかどうかは承認権限者の責任だ、という役割定義を社内に共有しておくことで、このデッドロックはかなり解消できる。

例外案件をどう扱うか

どれだけ精緻な権限表を作っても、現場は例外案件を持ち込んでくる。「急ぎで通常フローが間に合わない」「金額は小さいが戦略的に重要」「本来なら取締役承認が必要だが担当役員が出張中」。例外をゼロにはできないが、例外の扱いそのものをルール化することはできる。

例外案件のルールで最低限定めておくべきことは、「誰がいつまでに事後承認するか」と「何を記録として残すか」の2点だ。緊急処理をしたこと自体は問題ではない。問題は、緊急対応後に記録が何も残らず、その案件が「承認済み」なのか「承認なし」なのか不明のまま契約管理台帳に入ることだ。

権限表・決裁基準表をどう作るか

実務で機能する権限表は、網羅性よりも現場での参照のしやすさが優先される。100項目の精緻な表より、「この契約は誰が承認するか」を30秒で確認できる1枚の表のほうが定着する。

設計の基本方針

まず縦軸に「契約の区分（類型・金額帯）」、横軸に「承認者（担当者/部長/役員/取締役会）」を置く構造が標準的だ。各セルには「承認」「稟議不要」「上申」「取締役会付議」などのアクションを記入する。細分化しすぎると使われなくなるため、区分は5〜8程度に留める。

押印ルールとの接続

第5話で扱った押印業務との接続ポイントは明確にしておく。具体的には、「押印依頼書に承認記録（稟議番号等）の添付を必須とする」という設計だ。これにより、総務・押印管理者が「承認が完了しているか」を形式的にチェックできるようになり、「承認なき押印」を防ぐ仕組みになる。

見直しタイミング

権限表は一度作って終わりではない。以下のタイミングで見直しを行う。

• 組織改編・役員人事の際（承認者の役職が変わる）
• 新規事業・新取引類型が生じた際（既存分類に当てはまらない案件が出たとき）
• コンプライアンス事故・監査指摘の後
• 少なくとも年1回の定期確認

現場に定着させるための運用ポイント

権限表を作成しても、運用に落とさなければ意味がない。以下は、権限設計を現場定着させるための具体的な仕組みだ。

相談窓口と判断基準の明示

「この契約はどの区分か」「誰に相談すればよいか」を担当者が自分で判断できるよう、法務への相談フローと、よくある類型の判断例を社内に開示する。第4話で設計した承認フローに紐づける形が最も定着しやすい。

稟議テンプレへの埋め込み

稟議書のテンプレートに「契約区分欄」「適用する承認レベル欄」を設けると、起案者が権限表を参照せざるを得ない設計になる。法務審査が必要な案件では「法務審査完了」チェックボックスを必須項目にする。

押印依頼時の承認確認

総務・押印管理者が押印依頼を受けた際、「承認完了を示す記録（稟議番号または承認者の署名/メール等）」の確認を必須にする。この確認を習慣化することで、承認なき押印を組織的に防ぐ。

電子署名における権限管理

クラウドサインやDocuSign等の電子契約サービスを使う場合、「誰が署名リクエストを送信・承認できるか」というアカウント権限の設定が、物理的な押印権限と同等の意味を持つ。管理者権限を持つ担当者が決裁基準を超えた契約を送信できてしまう設計になっていれば、押印フローに承認確認を組み込んでも意味がない。電子契約を導入している場合は、プラットフォーム上のロール設定（署名権限者・管理者の範囲）が決裁権限表と整合しているかを確認する。

契約管理台帳との接続

締結後は、契約管理台帳に「承認者・承認日・承認区分」を記録するフィールドを設ける。これにより、後から「この契約はどのレベルで承認されたか」を追跡できる証跡設計になる。台帳の設計については第4話（社内決裁と法務審査をどうつなぐか）の証跡設計も参照してほしい。

よくある失敗パターン

権限設計の整備が不十分な組織で繰り返されやすい失敗を整理する。自社の状況と照らし合わせてほしい。

最低限、どこまで整えれば回るのか

完璧な職務権限規程がなくても、次の5点を整えるだけで、多くの混乱は防げる。ひとり法務・少人数法務の会社では、まずここから始めることを勧める。

これ5点が揃えば、「誰が何を承認したか」「承認なしに押印されていないか」という基本的な統制ラインは確保できる。全社的な職務権限規程の整備は、この実績を積みながら段階的に進めるのが現実的だ。

まとめ

契約締結権限の整理は、「誰がサインできるか」の話ではなく、「誰が会社として判断するか」という意思決定の設計だ。代表権・代理権・決裁権限は性質がそれぞれ異なり、混同すると法的リスクと内部統制の問題が同時に発生する。

実務上は、金額基準だけでは不十分であり、契約類型・リスク条項の性質による上位承認基準を組み合わせることが必要だ。そして押印できる人と承認権限者を切り離し、押印フローに承認確認を組み込むことで、承認なき契約締結を構造的に防ぐ。

完璧な権限規程がなくても、5つの最低限ポイントを整えれば現場の混乱はかなり減らせる。まずシンプルな権限表を作り、実態の中で磨いていく。それがひとり法務・少人数法務でも継続できる現実的な整備の進め方だ。

次回の第7話では、「反社チェックはどこまで必要か」を扱う。契約相手の属性確認は、締結権限の設計と並ぶ契約前審査の柱であり、権限フローのどの段階でチェックを組み込むかも論点になる。