# 購買申請と承認の社内ルール｜必要性・競争性・権限・例外を統制する

購買申請を「金額と販売者を書いて上司が承認する」だけにすると、必要性や既存在庫が確認されず、申請者が選んだ一社の見積だけで発注され、承認後の仕様変更が見逃されます。反対に、すべての案件へ同じ数の承認を課すと、時間がかかり、担当者は緊急・少額の例外経路へ逃げます。

本記事は、購買、総務、情報システム、セキュリティ、経理、利用部門、内部監査の担当者向けに、端末・IT製品の購買申請と承認をリスクに応じて設計します。必要性、予算、仕様、販売者、競争性、利益相反、職務分離、承認閾値、例外・緊急調達、変更承認、受入・支払、監査証跡までを一つのルールとして整理します。

承認の目的を「上司の許可」からリスク受容へ変える

承認者の役割は、申請内容を読みましたと示すことではありません。組織の資金・情報・業務継続・評判に関するリスクを理解し、権限の範囲で受容することです。

承認で答える質問

  • •業務上の必要性と数量根拠は妥当か
  • •既存在庫・修理・再利用等の代替を確認したか
  • •仕様は過剰・不足ではなく、標準に沿うか
  • •セキュリティ・法務・税務・会計要件を満たすか
  • •候補と価格の比較条件は公平か
  • •販売者・供給網・所有権に許容できないリスクはないか
  • •予算・TCO・支払条件を負担できるか
  • •例外と残存リスクを誰がいつまで管理するか

承認画面には結論だけでなく、判断に必要な要約と原資料への参照を表示します。

リスクベースで承認経路を分ける

金額は重要ですが、少額でも管理者権限を持つ端末、個人情報を扱う機器、新規海外販売者、前払は高リスクです。

リスク判定軸

  • •金額、台数、契約期間、予算影響
  • •標準・非標準、業務停止影響
  • •保存・処理する情報と権限
  • •新品・中古・現状渡し、品質・所有権
  • •新規・既存販売者、供給網、海外・再委託
  • •前払、外貨、残価保証、自動更新
  • •単一供給元、随意契約、緊急性
  • •関連当事者、利益相反、異常価格

低・中・高などの区分ごとに、必要な資料、審査部門、承認階層、SLAを定めます。高リスク案件を金額分割で低い経路へ送れないよう、同一目的・期間・販売者で集約判定します。

申請前にカタログ・標準・予算を整備する

申請の品質は入力フォームより、選択肢の設計で決まります。

申請前の基盤

  • •用途別の標準端末・標準構成
  • •承認済み販売者・契約・価格条件
  • •既存在庫・回収予定・修理可能在庫
  • •部門別の予算残・利用可能期間
  • •セキュリティ・品質・受入の必須要件
  • •金額・リスク別の承認経路
  • •禁止品・制限品・例外申請
  • •調達リードタイムと締切

標準品・既存契約・予算内であれば申請を簡素化し、標準外・新規販売者・高リスクへ審査を集中します。

申請に必要性・数量・利用終了まで含める

必須申請項目

  • •申請者、利用責任者、利用部門、費用部門
  • •利用目的、対象者、利用場所、開始・終了予定
  • •必要数量と新規・更新・交換・予備の内訳
  • •既存在庫・回収・修理を使えない理由
  • •必須仕様と標準機との差
  • •取扱情報、持出し、管理・認証方式
  • •希望納期と遅延時の業務影響
  • •取得・導入・運用・終了の概算費用
  • •返却、再配布、売却・廃棄の予定

モデル名とURLだけの申請を受け付けず、業務能力へ変換します。利用終了予定を入れることで、短期ならレンタルや再利用を比較できます。

仕様承認と予算承認を分ける

上司が予算を承認しても、技術・セキュリティ適合を判断できるとは限りません。

独立した審査

  • •利用部門：業務要件・数量・優先度
  • •情報システム：標準、互換性、運用、サポート
  • •セキュリティ：暗号化、管理、更新、データ、供給網
  • •購買：競争性、販売者、契約、価格、納期
  • •経理・財務：予算、会計、税、支払、契約期間
  • •法務：責任、保証、再委託、データ、契約終了

各部門は自分の専門領域を承認し、最終承認者は全審査の結果と残存リスクを確認します。承認者不在時の代理権限と上限も定めます。

セキュリティ要件を見積前に承認する

価格決定後にセキュリティ要件を追加すると、再見積や候補変更が生じます。IPAのIT製品の調達におけるセキュリティ要件リストは2026年2月に第2.1版へ更新され、製品分野ごとの脅威と要件、活用ガイドを提供しています。

セキュリティ審査

  • •OS・ファームウェア更新とサポート終了
  • •セキュアブート、暗号化、鍵保護、認証
  • •MDM・EDR・IdP・証明書との互換性
  • •初期設定、不要サービス、遠隔管理、ログ
  • •クラウド接続、外部送信、データ保存場所
  • •脆弱性・事故・リコールの通知と対応
  • •修理・交換・返却・売却時のデータ処理
  • •販売者・再委託・供給網への要求

資料の全項目を一律に適用せず、利用環境・情報リスクへ対応付け、非適用理由を記録します。

見積・競争性のルールを条件差まで定める

相見積もりの社数だけを条件にすると、比較不能な見積を集める、形だけの候補を加える、といった運用になります。

競争性の確認

  • •全候補へ同じ仕様、数量、納期、場所を提示する
  • •質疑と重要な回答を公平に共有する
  • •税、送料、設定、保証、返品、支払条件をそろえる
  • •必須条件と加点条件を事前に分ける
  • •見積有効期限と変更条件を確認する
  • •候補選定・除外理由を記録する
  • •単一供給元・随意契約の根拠を検証する
  • •交渉と最終条件を履歴化する

価格だけでなくTCO、品質、納期、セキュリティ、販売者、供給網を同じ評価表で比較します。必須条件の不適合を安さで補いません。

販売者承認を購買案件と独立して行う

申請者が推薦する販売者をそのまま登録せず、法人・所有権・品質・継続性を審査します。

販売者承認

  • •法人情報、所在地、代表・契約責任者
  • •振込先名義と変更時の独立確認
  • •許認可、仕入経路、正規流通、所有権
  • •品質検査、個体管理、消去、返品・保証
  • •情報セキュリティ、事故・脆弱性対応
  • •物流、修理、消去等の再委託先
  • •財務、供給能力、事業継続、代替可能性
  • •納期、不良、請求、是正の過去実績

販売者承認には有効期限を設け、法人・振込先・再委託・事故等の変更時に再審査します。

職務分離とシステム権限を設計する

金融庁の財務報告に係る内部統制の評価及び監査の基準は、内部統制を業務の有効性・効率性、財務報告の信頼性、法令等遵守、資産保全を達成するためのプロセスとして整理しています。購買でも一人の善意に依存せず、権限と証跡を設計します。

分離する役割

  • •必要性を申請する
  • •仕様・評価基準を作る
  • •販売者を登録・変更する
  • •見積を受領・評価する
  • •予算・リスクを承認する
  • •契約・注文を発行する
  • •現物を受入・検査する
  • •請求と支払を承認する

小規模組織で完全分離できない場合、上位者の事後レビュー、全件ログ、金額上限、振込先の別経路確認など代替統制を設けます。

承認権限表を金額とリスクの二軸で作る

権限表に含める項目

  • •案件・累計金額の上限
  • •対象会社・部門・費用センター
  • •標準・非標準、新規・既存販売者
  • •情報・セキュリティリスク区分
  • •契約期間、前払、外貨、残価保証
  • •随意・単一供給元・緊急の追加承認
  • •代理・兼任・休暇時の権限
  • •承認の有効期限と再承認条件

組織変更時に権限表とシステム権限を同時更新します。役職を失った利用者、退職者、臨時代理の権限を定期レビューします。

利益相反・贈答・関連当事者を申告する

利益相反統制

  • •申請者・評価者・承認者の販売者との関係を申告する
  • •贈答、接待、紹介料、兼業、投資関係を社内基準で扱う
  • •関係者は評価・承認から外す
  • •関連当事者取引は追加審査・開示へ回す
  • •異常に安い・高い条件の根拠を確認する
  • •私用連絡先・個人口座への変更を禁止する
  • •通報、調査、取引停止、証拠保全の手順を設ける

関係があること自体だけで不正と断定せず、申告・回避・独立評価の手順を明確にします。

分割申請・重複申請・予算迂回を検知する

検知条件

  • •同一申請者・部門・目的・販売者・期間
  • •類似品目・仕様・納品場所
  • •承認閾値直下の金額が連続する
  • •同じ見積・請求書・注文番号の再利用
  • •一つの案件を複数費用センターへ不自然に分ける
  • •取消後に同条件で再申請する

機械的にすべてを不正扱いせず、正当な分納・部門配賦を説明できるよう案件親IDを設けます。集約後の金額・リスクで承認経路を再判定します。

緊急・少額・随意調達に期限付き例外を設ける

例外は統制をなくす仕組みではなく、時間制約下で最低限を守り、後から補完する仕組みです。

例外申請

  • •緊急性と業務・安全への影響
  • •通常工程を省略する理由
  • •対象、数量、仕様、販売者、金額
  • •所有権、振込先、セキュリティの最低確認
  • •代替案と選定理由
  • •期限付き承認者と失効日
  • •補完する審査・契約・証拠と期限
  • •事後レビュー・再発防止の責任者

「少額」「前回と同じ」「時間がない」だけを理由にしません。同じ例外が反復する場合、標準品、在庫、承認SLA、契約の問題として改善します。

承認後の変更を差分で再審査する

再承認トリガー

  • •数量・総額・単価が設定幅を超えて変わる
  • •モデル、容量、品質、地域仕様が変わる
  • •販売者、振込先、再委託先が変わる
  • •納期・分納・支払・前払条件が変わる
  • •保証、返品、所有権、データ条件が弱くなる
  • •契約期間、更新、解約、残価保証が変わる
  • •標準・セキュリティ必須条件へ影響する

変更後の最終値だけでなく、承認時との差、理由、予算・リスク・受入への影響を表示します。重要条件の変更は金額が下がっても再審査します。

例えば、標準スマートフォン100台を一台5万円で承認した後、販売者が同価格の海外仕様へ変更を提案した場合、総額は変わりません。しかし対応バンド、技適、保証、ゼロタッチ登録、OS更新、修理拠点が変わり得るため、仕様・セキュリティ・法務・受入基準を再確認します。「同価格」「上位機種」という理由だけで購買担当が承認しません。

別の例として、50台を一括申請すると部長承認が必要なため、同じ部門が25台ずつ二週間に分けた場合、利用目的、販売者、納品場所、予算を集約して元の承認階層へ戻します。一方、異なる拠点が独立した利用計画と費用責任で購入する場合は、親案件IDで関連を示しながら、正当な分割である根拠を残します。

緊急障害で10台を当日購入する場合は、通常の相見積もりを省略しても、必要性、数量、標準適合、販売者法人・振込先、所有権、最低限のセキュリティ、価格の概算妥当性を確認します。承認は24時間など期限付きとし、契約・販売者審査・価格レビューを所定日までに補完します。翌月も同じ緊急購入が起きれば、安全在庫や保守契約の不足として扱います。

承認ルールには、否認・差戻し・保留の違いも定義します。否認は案件を終了し、再申請には新しい案件IDと変更理由を求めます。差戻しは不足資料を指定して同じ版の審査を再開します。保留は外部回答や予算決定を待つ状態で、責任者と期限を持たせます。状態が曖昧だと、古い承認を後から流用する原因になります。

承認の有効期限を過ぎた案件は、価格だけでなく需要、数量、仕様、販売者、予算を再確認します。市場価格が変動する端末では、三か月前の見積と承認をそのまま実行せず、価格有効期限と在庫を更新します。年度をまたいだ場合は、予算・会計・税務の適用時点も再確認します。

システムでは、承認者が申請内容を編集してから承認できないようにします。修正は申請者または所定担当へ差し戻し、新しい版を作り、再審査対象を明示します。承認時のスナップショットに、明細、添付、評価、例外、コメントを固定し、後日の上書きから守ります。

一括承認機能を設ける場合も、案件ごとの販売者、金額、リスク、例外を一覧で確認できるようにし、異常案件を個別審査へ外せるようにします。承認者が内容を開かず大量処理する状況を、処理件数・閲覧時間だけで断定せず、サンプルレビューや差戻し品質と合わせて監視します。自動承認は標準品、既存契約、予算内、低リスクなど明示した条件をすべて満たす場合に限定し、ルール変更と結果を監査可能にします。

受入・支払を承認内容へ結び付ける

承認済みでも、注文・現物・請求が一致しなければ支払いません。

実行統制

  • •承認済み案件からのみ注文を作成する
  • •注文番号を納品書・請求書へ記載させる
  • •数量・モデル・個体・品質を受入で確認する
  • •保留・不合格・返品を利用可能在庫から隔離する
  • •注文・合格受入・請求を三点照合する
  • •振込先変更は登録済み連絡先へ再確認する
  • •受入担当と支払承認担当を分ける
  • •取消・未使用予算を速やかに解放する

承認は将来の上限であり、未納・不合格分まで支払う許可ではありません。

証拠・通知・保存を設計する

監査証跡

  • •申請原文と添付、必要性、数量根拠
  • •仕様・セキュリティ審査と使用版
  • •見積原本、質疑、評価、交渉
  • •利益相反申告、販売者審査
  • •各承認の対象版、日時、コメント
  • •契約、注文、変更注文、受入、請求、支払
  • •例外、事後レビュー、是正措置
  • •システム権限・代理承認・変更ログ

承認依頼・期限超過・差戻しの通知は、責任者と次の行動を示します。証拠をメールボックスだけに残さず案件IDへ集約し、保存期間とアクセス権を定めます。

社内ルールのチェックリスト

  • •[ ] 承認をリスク受容として定義した
  • •[ ] 金額と質的リスクで承認経路を分けた
  • •[ ] 標準品・既存契約・在庫を申請前に整備した
  • •[ ] 必要性・数量・利用終了まで申請させる
  • •[ ] 仕様・セキュリティ・予算の審査を分けた
  • •[ ] 同一条件の見積と評価根拠を保存する
  • •[ ] 販売者を案件と独立して審査する
  • •[ ] 申請・承認・発注・受入・支払を分離する
  • •[ ] 権限表に代理・有効期限・再承認条件がある
  • •[ ] 利益相反・贈答・関連当事者を申告する
  • •[ ] 分割・重複・予算迂回を集約判定する
  • •[ ] 例外に最低統制・失効日・事後レビューがある
  • •[ ] 重要変更を差分再承認する
  • •[ ] 注文・受入・請求を承認内容と照合する
  • •[ ] 対象版・判断・変更を監査証跡として保存する
  • •[ ] 期限・差戻し・例外を定期レビューする

まとめ：速さと統制をリスクに応じて両立させる

購買申請と承認の目的は、承認者を増やすことではありません。標準・低リスク案件は速く処理し、標準外・新規販売者・重要情報・前払などへ専門審査を集中させます。必要性、仕様、競争性、販売者、予算、利益相反を明示し、承認後の変更・受入・支払までつなげれば、承認が形骸化しません。

端末の価格妥当性を確認するときは、同じモデル・容量・品質・数量・時点で[中古端末の販売相場を確認する](/market-search)と有効な見積・成約実績を比較し、税、送料、保証、設定、返品条件を補正します。まず直近十件を見直し、承認前に決まっていた販売者、説明できない分割、承認後変更、受入前支払を抽出してください。