決裁権限表と職務権限規程をClaudeで整備し、稟議実績との食い違いを洗う

職務権限規程と決裁権限表は、作った時点では噛み合っていても、組織変更や金額基準の改定を重ねるうちに少しずつずれます。規程の本文、権限表、実際に回った稟議の3つをClaudeのProjectsに置けば、「300万円ちょうどの承認者が決まっていない」「規程にない人が承認している」といった食い違いを、条番号や稟議番号つきで一覧にできます。

この記事では、権限表の列の決め方、Projectsへの資料の置き方、規程内の矛盾を洗う指示、稟議実績との突き合わせ、結果の読み方の順に進めます。起案書そのものの形式はClaudeで稟議と決裁の違いを整理し起案書の形式を判断するに、稟議書の雛形づくりはClaudeで稟議書をテンプレート化し過去の稟議を参照させる方法にあります。ここでは、承認の基準そのものが規程どおりに運用されているかを扱います。

食い違いは3つの方向で起きる

点検の対象を「規程」と「実績」の2つに絞ると、取りこぼしが出ます。食い違いは次の3方向で起きます。

1つ目と2つ目は規程の文書だけで見つかります。3つ目は稟議の記録を並べないと見えません。Claudeに3つを一度に見比べさせるのがこの手順の狙いです。

権限表の列を先に決める

権限表がまだ整っていない会社は、表の形を決めてから規程を表に起こします。列が揃っていないと、あとで実績と突き合わせるときに比較の軸がなくなります。

次の6列にしておくと、実績との照合がしやすくなります。

金額区分は「以上」「未満」を必ず書きます。「以下」と「以上」が混ざった表は、境界の金額で承認者が二重に決まるか、誰も決まらないかのどちらかになります。

会社法が取締役会に残す事項を前提に入れる

金額の大小にかかわらず、取締役会を置く会社では、取締役会が取締役に任せられない事項があります。会社法第362条第4項は、次の事項その他の重要な業務執行の決定を、取締役に委任できないと定めています。

• 重要な財産の処分及び譲受け
• 多額の借財
• 支配人その他の重要な使用人の選任及び解任
• 支店その他の重要な組織の設置、変更及び廃止
• 社債を引き受ける者の募集に関する重要な事項として法務省令で定める事項
• 取締役の職務の執行が法令及び定款に適合することを確保するための体制などの整備
• 定款の定めに基づく責任の免除

条文は「重要な」「多額の」と書くだけで、金額の基準は示していません。何が重要で何が多額かは、会社ごとの規程や実態で決める部分です。権限表で「この金額以上は取締役会」と線を引いている場合、その線が上の項目の受け皿として足りているかを点検する価値があります。法令メモとしてこの条文をナレッジに置いておくと、Claudeが「取締役会に付議する基準の記載がない」と指摘できるようになります。

自社が取締役会を置く会社かどうかは、登記事項証明書や定款で決まります。設置していない会社には、この条文の枠組みはそのまま当てはまりません。

Projectsに資料を置いて指示文を保存する

Projectsは、チャット履歴とナレッジベースを持つ独立した作業スペースです。無料アカウントを含む全ユーザーが使えますが、無料では作れるプロジェクトは最大5つです。

作成は、サイドバーのProjectsから「+ New Project」を押し、名前と説明を付けます。この名前と説明はClaudeには渡りません。判断の前提にしたい内容は、名前や説明ではなくナレッジか指示文に書く必要があります。

ナレッジに置く4つの資料

稟議の実績は、件数が多いのでナレッジとは別に扱います。次の節で触れます。

有料プランでは、ナレッジが上限に近づくとRAGモードが自動で有効になり、容量が最大10倍まで広がります。ただし、RAGでは質問に関係しそうな部分が選ばれて読まれます。規程全体の整合を一度に見るような質問は、読まれなかった条文が出るかもしれません。点検を「第8条から第12条の金額基準」のように範囲を区切って回すほうが安定します。

指示文を保存する

指示文は「Set project instructions」から保存します。保存した内容は、そのプロジェクトのすべてのチャットに使われます。

あなたは職務権限規程と決裁権限表の整合を点検する補助です。
- 指摘は「規程内の矛盾」「規程と権限表のずれ」「規程と実績のずれ」の
  3種類に分けて書く
- 指摘ごとに、根拠の条番号または稟議番号を必ず挙げる
- 金額の境界は「以上」「未満」「以下」の別まで引用して比べる
- 条文や表にない内容を、一般的な慣行で補わない。
  該当がなければ「記載なし」と書く
- 結論は出さず、人が判断すべき点を最後に列挙する

「記載なし」と書かせる行が要になります。これがないと、規程にない代決のルールを「一般的にはこうです」と補った回答が混ざりやすくなります。

規程の中の矛盾を洗う

まず、実績を使わずに規程と権限表だけで点検します。範囲を区切って、次のように依頼します。

第8条から第12条の金額基準と、権限表の物品購入・契約締結の行を
突き合わせてください。次の観点で表にしてください。
1. 同じ金額が、条文と表で「以下」「未満」で違う書き方になっていないか
2. 金額区分に、どの承認者にも当たらない隙間や、重なりがないか
3. 起案者と承認者が同じ役職になる区分がないか
4. 承認者欄の役職が、組織図に存在するか

例えば次のような形の結果が返ってきます。ここで示すのは出力の型を示す例で、数字は仮のものです。

代決と不在時の定めも見る

承認者が不在のときの代決は、規程の中で見落とされがちな場所です。次のような点を依頼に加えます。

• 代決できる範囲に、金額の上限が付いているか
• 代決者が、起案者本人や合議先の部署を兼ねていないか
• 代決した後に、本来の承認者へ報告する手続きが書かれているか

どれも、条文があるかどうかを見る作業です。条文がなければ「記載なし」と返させ、運用で穴を埋めているのか、そもそも決めていないのかを人が確かめます。

稟議の実績と突き合わせる

規程の中が整ったら、実績と照らします。稟議システムやExcelの一覧から、次の列を抜き出します。

氏名は入れず、役職だけにします。点検に必要なのは「誰が」ではなく「どの役職が」です。取引先名や個人名が入る件名の列も、分析に使わないなら外します。

件数が多いときは、期間か決裁事項で分けて貼ります。1回に貼るのは数十件から百件程度を目安に、四半期ごとなど区切りを決めるとよいでしょう。この件数は仕様ではなく、確認しやすさを基準にした例です。チャット同士の文脈は共有されないため、前のチャットの指摘は次のチャットに自動では引き継がれません。残したい結論はナレッジに書き足します。

次の稟議一覧を、ナレッジの決裁権限表と照合してください。
稟議ごとに、金額と決裁事項から権限表で求められる最終承認者を出し、
実際の最終承認者と違う件だけを表にしてください。
列は 稟議番号、金額、権限表上の承認者、実際の承認者、根拠条 です。
金額の境界上の件は、別の表にまとめてください。
 
(ここにCSVを貼る)

境界上の件を別表にさせるのは、規程の書き方に原因があることが多いためです。同じ金額でも、規程が曖昧なら、起案者の側がどちらにも読めてしまいます。

税込と税抜も食い違いの原因になる

権限表の金額が税込か税抜かで決まっていない会社があります。稟議の一覧が税抜で、規程が税込の想定だと、境界近くの案件が実際には上位の承認を要していたのに、下位で処理されたように見えます。実績の金額列にどちらを入れたかを、依頼文に書いておきます。規程に書かれていなければ、Claudeに「記載なし」と返させ、人が決める部分として残します。

出てきた指摘をどう読むか

Claudeが出すのは「規程と実績が合っていない」という事実の一覧までです。それが違反なのか、規程が実態に追いついていないだけなのかは、人が見分けます。

指摘の一覧を持って関係者に確認する場面では、プロジェクトを共有しておくと便利です。共有はTeamとEnterpriseのプランで使えます。「Can view」の人は内容を見てチャットできますが編集はできません。「Can edit」の人は指示文やナレッジも変更できます。点検を依頼する経理や法務には「Can view」を付け、資料を更新する担当にだけ「Can edit」を渡す分け方が考えられます。管理者が共有を止めている組織では、共有自体ができません。

稟議の中身に個人情報が混ざるとき

稟議の一覧には、人事や取引の機密が入りやすいものです。ナレッジに置いた内容はプロジェクト内のすべてのチャットで使われ、共有すればメンバーにも見えます。権限の点検に不要な列は、置く前に外しておきます。人事案件など、閲覧者を絞りたいものは、別のプロジェクトを非公開のまま使う運用もあります。

権限表の改定案をまとめさせる

指摘が整理できたら、改定案の叩き台を作らせます。

指摘された食い違いのうち、規程と権限表の側を直す案を出してください。
- 修正前と修正後を並べた表にする
- 修正の根拠にした指摘の番号を付ける
- 金額の境界は「以上」「未満」の形に統一する
- 取締役会の決議事項に関わる箇所は、人が確認する旨を明記する

出てきた案は、規程を改定する権限のある人が検討します。改定後の規程をナレッジに差し替え、旧版は別名で残すか削除します。差し替えを忘れると、次の点検で旧版と新版が混ざります。

規程と社内の別資料を対応づける作業の型は、ISMSの適用宣言書(SoA)をClaudeで下書きするの対応表の作り方と共通します。判断ぶれを事例で点検する流れは、Claudeで返品・返金の規程と対応事例を突き合わせ、判断ぶれを点検するにあります。契約や規程まわりの法務の任せどころはClaude Cowork法務活用で整理しています。

対象のプロジェクトの種類について

ここまでの手順は、claude.aiのチャットで使う現行のProjectsを想定しています。Projectsの新しい版がベータとして、まず一部のPro・MaxでClaude Codeを使う人向けに段階的に展開されています。既存のチャットとCoworkのプロジェクトは、これまでどおり動きます。新しい版では、プロジェクトが1つの会話になり、Claudeが作業を並列のスレッドに分けて進めます。この記事の画面や用語は、従来のプロジェクトのものです。