# 端末調達ガバナンスのチェックリスト｜証拠・担当・期限まで記録する監査可能な台帳

チェックリストに「見積確認済み」「セキュリティ確認済み」とだけ記録しても、何を基準に、誰が、どの資料で判断したかを後から説明できません。端末調達では、台数の根拠、既存在庫、必須仕様、販売者、供給網、中古品質、契約、受入、請求、資産登録が連動します。一項目の見落としが、過剰購入、ロック端末の納品、サポート切れ、二重支払、不正な振込先変更につながります。

本記事は、購買、総務、情報システム、セキュリティ、経理、内部監査の担当者向けに、端末調達を案件単位で検証するチェックリストと記録項目を示します。単なる確認欄ではなく、判定、根拠、証拠、担当、期限、不一致処置を残し、新品・中古・リース、通常・緊急、全納・分納のいずれにも使える形にします。

チェック欄より先にデータ定義を決める

自由記述だけの台帳では担当者ごとに意味が変わります。各項目にデータ型、必須条件、選択肢、証拠、更新権限を定義します。

共通列

  • •案件ID：全資料を結ぶ変更不可の識別子
  • •工程：受付、審査、評価、承認、発注、受入、支払、完了
  • •項目ID：同じ統制を継続集計する識別子
  • •判定：適合、不適合、条件付適合、対象外、未確認
  • •判定基準：数値、期限、許容範囲、必要文書
  • •入力値：数量、金額、日付、文字列、選択値
  • •根拠：判断理由と比較対象
  • •証拠：原本の保存場所、版、取得日
  • •実施者・確認者：氏名ではなくアカウントIDも保持
  • •実施日時・確認日時：後から上書きせず履歴化
  • •期限：回答、承認、返品、交換、補完の期限
  • •処置：停止、差戻し、再見積、返品、例外承認
  • •例外ID：通常基準を外れた理由と期限への参照

「対象外」は空欄と区別し、対象外理由と承認者を必須にします。証拠ファイルを差し替えた場合は旧版を残し、どの版で承認したか追跡できるようにします。

案件受付と需要根拠を確認する

需要チェック

  • •[ ] 利用者、部門、利用目的、利用場所が特定されている
  • •[ ] 利用開始日と終了・更新予定日がある
  • •[ ] 必要数量を新規、更新、故障交換、予備、短期案件に分けた
  • •[ ] 採用・退職・異動・案件計画との数量根拠がある
  • •[ ] 既存在庫、回収予定、修理復帰、再配布を差し引いた
  • •[ ] 予備台数を故障率、交換時間、停止影響から算定した
  • •[ ] 過去の余剰、未使用、紛失、故障実績を参照した
  • •[ ] 希望納期が必要日と調達リードタイムに整合する
  • •[ ] 予算、費用部門、購入・リース等の許容方式がある
  • •[ ] 申請者と承認者が同一でない

証拠には人員計画、更新対象一覧、在庫・回収一覧、故障実績、案件計画を紐付けます。「前回と同じ台数」は根拠にせず、前提が変わっていないか確認します。

業務要件・標準仕様・例外を確認する

モデル名の指定だけでは、代替可能性と受入条件を判断できません。

仕様チェック

  • •[ ] 必須アプリ、性能、容量、画面、重量の要件がある
  • •[ ] OS、更新、サポート終了までの必要期間を定めた
  • •[ ] MDM、EDR、IdP、証明書、暗号化との互換性を確認した
  • •[ ] 通信、SIM、Wi-Fi、周辺機器、ポートの条件がある
  • •[ ] 持出し、海外利用、共有、キオスク等の利用形態を反映した
  • •[ ] 標準機・標準構成との一致を確認した
  • •[ ] 後継機、色、容量、地域仕様の許容範囲を定めた
  • •[ ] 付属品、キッティング、資産ラベル、梱包を定めた
  • •[ ] 受入時の確認方法と不適合処置を仕様ごとに定めた
  • •[ ] 標準外の場合、業務根拠、追加費用、終了日、承認者がある

必須条件と加点条件を分け、必須不適合を価格点で補わないよう評価表を保護します。仕様変更は旧版を削除せず、変更理由、影響、再承認を記録します。

セキュリティ・プライバシー要件を確認する

製品・運用チェック

  • •[ ] 保存・処理する情報と業務影響を分類した
  • •[ ] セキュアブート、暗号化、鍵保護、認証要件がある
  • •[ ] 初期資格情報、不要サービス、遠隔管理の設定を定めた
  • •[ ] OS・ファームウェア更新方針と終了予定を確認した
  • •[ ] 脆弱性の受付、通知、修正、緊急連絡を確認した
  • •[ ] MDM・EDR登録と解除の責任者・期限を定めた
  • •[ ] クラウド連携、外部送信、保存場所、再委託を確認した
  • •[ ] 修理・交換時の端末、媒体、データの扱いを契約化した
  • •[ ] 回収・返却・売却時の消去方式と個体証跡を定めた
  • •[ ] サポート終了・製品終了時の移行計画がある

IPAのIT製品の調達におけるセキュリティ要件リストを参照するときは、製品分野と利用リスクへ対応付け、採用・非採用理由を残します。ひな型の全項目へ一律にチェックを入れる運用は避けます。

販売者・供給網・所有権を確認する

適格性チェック

  • •[ ] 法人名、所在地、代表・契約責任者を公的情報と照合した
  • •[ ] 振込先名義と変更連絡を独立した経路で確認した
  • •[ ] 許認可、正規流通、仕入経路、所有権の確認方法がある
  • •[ ] 在庫、供給量、納期、分納、代替供給能力を確認した
  • •[ ] 品質検査、個体管理、消去、返品・保証体制を確認した
  • •[ ] 物流、修理、消去、処分等の再委託先を把握した
  • •[ ] 情報セキュリティ、事故、脆弱性、リコール対応を確認した
  • •[ ] 財務、事業継続、単一供給元、製品終了リスクを評価した
  • •[ ] 過去の納期、不良、誤納、請求、是正実績を確認した
  • •[ ] 新規・高額・異常価格の案件を追加審査した

NISTのSP 800-161 Rev.1が示すように、供給網リスクは販売者だけではなく、製造、流通、更新、修理、クラウド、終了までを対象にします。依存先、代替手段、事故通知、契約終了時の回収を記録します。

中古端末の個体・ロット品質を確認する

中古はグレード名だけで判断せず、個体ごとの必須条件とロットの許容差を分けます。

中古品質チェック

  • •[ ] メーカー、モデル、容量、色、地域・通信仕様が明確である
  • •[ ] OS更新可否と必要なサポート残期間を満たす
  • •[ ] 外観ランクの写真付き定義と許容傷がある
  • •[ ] 画面、カメラ、通信、端子、センサー等の検査項目がある
  • •[ ] バッテリー指標、測定方法、交換・返品基準がある
  • •[ ] アクティベーション、ネットワーク、盗難ロックがない
  • •[ ] MDM・自動登録・企業アカウントの残存がない
  • •[ ] シリアル・IMEI、所有権、仕入経路を個体別に確認できる
  • •[ ] 修理、非純正部品、改造、液体侵入の扱いを定めた
  • •[ ] データ消去方式、結果、担当、個体番号の証跡がある
  • •[ ] MIX・現状渡し・ランク混在の内訳と責任範囲がある
  • •[ ] 不合格、交換、返品、減額、再検査の期限がある

全数確認する項目と抜取可能な項目を明記します。ロック、個体番号、所有権、消去証跡のように個体固有の必須条件は平均値や抜取結果で代替しません。

見積条件とTCO比較を確認する

見積チェック

  • •[ ] 全候補へ同じ仕様、数量、納期、場所を提示した
  • •[ ] 質疑回答と重要な仕様変更を全候補へ共有した
  • •[ ] 本体、付属品、送料、税、関税を分離した
  • •[ ] 設定、資産登録、MDM・EDR、ライセンスを含めた
  • •[ ] 保証、修理、代替機、返品、取消条件を含めた
  • •[ ] 分納、価格有効期限、為替、価格改定条件を確認した
  • •[ ] 回収、消去、返却、売却、違約金を含めた
  • •[ ] 同じ利用期間とサービス水準でTCOを算定した
  • •[ ] 故障、停止、利用年数、残存価値の感度分析を行った
  • •[ ] 候補除外と推奨の根拠を保存した

単価の列だけを比較せず、数量、期間、保証、送料、設定範囲を正規化します。残存価値は表示価格をそのまま使わず、実際の状態、時点、検品・消去・物流・手数料を反映します。

評価・利益相反・承認を確認する

意思決定チェック

  • •[ ] 必須適合を先に判定し、加点評価と分けた
  • •[ ] 重み、採点尺度、証拠、評価者を事前に決めた
  • •[ ] 評価者が販売者との関係、贈答、兼業を申告した
  • •[ ] 申請、評価、承認、発注、受入、支払を可能な範囲で分離した
  • •[ ] 分割発注を同一目的・期間・販売者で確認した
  • •[ ] 随意契約、単一供給元、新規販売者の理由を記録した
  • •[ ] 需要、在庫、TCO、リスク、予算差を承認者へ示した
  • •[ ] 残存リスクとその受容責任者を記録した
  • •[ ] 承認日時と承認対象の資料版を固定した
  • •[ ] 重要変更を差分承認へ戻す閾値を定めた

金額が閾値未満でも、販売者変更、セキュリティ不適合、所有権不明、振込先変更は追加承認の対象にします。承認コメントだけでなく、承認時点の評価表・見積・仕様を保存します。

契約・注文・変更管理を確認する

発注チェック

  • •[ ] 契約先、振込先、品目、数量、単価が承認と一致する
  • •[ ] 仕様、品質、個体情報、付属品を注文書へ反映した
  • •[ ] 納期、分納、納品場所、送料、危険負担を定めた
  • •[ ] 所有権、盗難・偽造・権利侵害への責任を定めた
  • •[ ] 受入、保留、返品、交換、減額、再検査を定めた
  • •[ ] 保証、修理SLA、代替機、リコール対応を定めた
  • •[ ] セキュリティ事故・脆弱性・製品終了通知を定めた
  • •[ ] 再委託、監査、秘密、データ消去、記録を定めた
  • •[ ] 注文番号を納品書・請求書へ記載させた
  • •[ ] 変更注文に理由、差額、影響、承認、発効日がある

代替品は「同等以上」という文言だけで受け入れず、必須仕様、管理互換性、周辺機器、保証、TCOを再評価します。

納品・受入・不一致処置を確認する

受入チェック

  • •[ ] 注文・納品書・現物の数量と品目を照合した
  • •[ ] モデル、容量、地域仕様、付属品を確認した
  • •[ ] シリアル・IMEIを読み取り、一覧・重複を確認した
  • •[ ] ロック、MDM、起動、主要機能、バッテリーを確認した
  • •[ ] 外観、修理、消去、保証の証跡を個体へ紐付けた
  • •[ ] 合格、保留、不合格を個体別に記録した
  • •[ ] 不合格品を利用可能在庫から隔離した
  • •[ ] 分納ごとの受入数量と未納残を管理した
  • •[ ] 返品・交換・販売者回答・再検査の期限を登録した
  • •[ ] 受入担当と支払承認担当を分けた

受入日、確認者、使用した基準版、測定器・手順、写真・ログを残します。検査後に仕様変更を遡及適用せず、変更承認前の不一致を正しく処理します。

請求・支払・資産登録を確認する

三点照合チェック

  • •[ ] 注文、受入、請求の販売者・品目・数量・単価が一致する
  • •[ ] 未納、保留、不合格、返品分を請求対象から除いた
  • •[ ] 税、送料、設定費、値引き、前払、分納を確認した
  • •[ ] 請求書番号の重複と支払済み状態を確認した
  • •[ ] 振込先変更を登録済み連絡先から再確認した
  • •[ ] 承認済み変更注文との一致を確認した
  • •[ ] 支払承認者が受入証拠を参照した
  • •[ ] 資産ID、個体番号、取得日、価額、利用者を登録した
  • •[ ] MDM、保証、場所、費用部門、更新日を登録した
  • •[ ] 返却・再配布・売却・消去の予定を登録した

請求額の一致だけでなく、受入済みの個体と台帳登録がつながることを確認します。前払が必要な場合は、上限、履行保証、未納時の回収手段、精算期限を追加管理します。

緊急・少額・例外調達を確認する

例外チェック

  • •[ ] 緊急性、業務停止影響、通常工程を省略する理由がある
  • •[ ] 対象、数量、仕様、販売者、金額、期限を記録した
  • •[ ] 所有権、振込先、最低限のセキュリティを確認した
  • •[ ] 省略工程ごとの代替統制を実施した
  • •[ ] 期限付き承認と失効日がある
  • •[ ] 通常と同じ受入・個体確認を行った
  • •[ ] 証拠、販売者審査、契約を補完する期限がある
  • •[ ] 価格、分割発注、品質、再発防止を事後レビューした

少額・緊急の件数、金額、部門、販売者、理由を定期集計します。同じ理由が繰り返される場合は例外ではなく、標準機、安全在庫、承認SLA、供給契約の問題として扱います。

完了・保存・事後評価を確認する

完了チェック

  • •[ ] 全数量が合格、返品、取消のいずれかで確定した
  • •[ ] 未納、不合格、交換、減額、返金が解決した
  • •[ ] 支払総額が受入・契約・変更注文と一致した
  • •[ ] 全個体が資産台帳・MDM・利用者へ紐付いた
  • •[ ] 原本と履歴が保存期間・アクセス権に従い保管された
  • •[ ] 納期、不良、修理、問合せ、実績TCOを記録した
  • •[ ] 販売者の評価と是正措置を更新した
  • •[ ] 余剰、再配布、利用年数、回収予定を更新した
  • •[ ] 例外と監査指摘に責任者・期限・完了証拠がある
  • •[ ] 次回の標準仕様、数量、契約条件へ学びを反映した

完了状態は担当者の宣言だけでなく、未解決項目ゼロ、証拠あり、台帳一致という条件で自動判定できるようにします。

月次レビュー用の例外一覧を作る

全案件を同じ深さで読むより、リスクの高い例外を抽出します。

  • •未確認・条件付適合が期限超過した案件
  • •標準外、随意契約、単一供給元、緊急調達
  • •見積から注文・請求が一定率以上変動した案件
  • •分納遅延、代替品、過納、数量不足
  • •初期不良・返品・ロック・個体重複が多い販売者
  • •受入前支払、注文番号なし、請求重複
  • •振込先・法人名・再委託先の変更
  • •資産台帳・MDM未登録、利用者不明、保管滞留
  • •例外期限切れ、是正未完了、証拠欠落

件数だけでなく金額、台数、業務影響、経過日数を併記し、責任者と解消期限を決めます。

証拠の保存とアクセス権を統制する

チェック項目が正しくても、証拠を誰でも削除・差替えできたり、保存期限前に失われたりすれば監査可能性は残りません。見積原本、質疑、評価表、承認、契約・注文、納品、個体一覧、検査ログ、請求、支払、例外、是正記録について、文書種別ごとの保存責任者と保存期間を定めます。

証拠管理チェック

  • •[ ] 原本、作業用コピー、承認済み版を区別している
  • •[ ] ファイル名だけでなく案件ID、版、作成元、取得日時を保持する
  • •[ ] 承認後の変更履歴と変更者を追跡できる
  • •[ ] 評価者は入力できても最終承認を改変できない
  • •[ ] 販売者提出資料の受領経路と真正性を記録する
  • •[ ] 個体番号や利用者情報へのアクセスを必要最小限にする
  • •[ ] 保存期限、訴訟・監査時の保全、廃棄手順を定める
  • •[ ] バックアップから案件単位で復元できるか確認する

個人情報や認証情報を証拠へ無制限に貼り付けず、必要な識別情報だけを保持します。スクリーンショットだけに依存すると検索・照合・真正性確認が難しいため、可能なら元データ、出力条件、ハッシュやシステム監査ログも保存します。アクセス権レビューでは、退職・異動者、販売者アカウント、臨時担当者の権限が残っていないか確認します。

まとめ：チェックリストを意思決定の証拠にする

有効な調達チェックリストは、項目に印を付けるものではなく、基準、入力値、根拠、証拠、実施者、確認者、期限、不一致処置を結び付ける案件台帳です。需要から完了まで同じ案件IDでつなぎ、対象外と未確認を区別し、重要変更を履歴化すれば、引継ぎ・監査・改善に使える情報になります。

端末の残存価値を見積評価へ入れる場合は、同じモデル・容量・状態・時点で[中古端末の買取相場を確認する](/kaitori-search)と実売却実績を確認し、消去、検品、物流、手数料を差し引いた純回収額を記録してください。まず直近一件をこのチェックリストで再点検し、「確認済み」なのに根拠・証拠・期限がない項目を洗い出すと、優先的に直す統制が見えます。