会議で決まったはずの方針が、部署によって違う解釈で運用されている。担当者が異動すると、決定の根拠が分からなくなる。以前の決定を変更したのに、古い議事録を見た人が元の手順で仕事を進めてしまう。
こうした問題は、議事録を保存するだけでは解消しません。決定事項を取り出し、適用範囲や有効期間、承認者、新旧の関係まで管理する仕組みが必要です。
その基盤となるのが「意思決定台帳」です。会議で生まれた決定を、組織が継続して参照できる情報として管理します。生成AIで活用する場合にも、どの決定を現在の方針として扱えるかを判別できる構造が欠かせません。
意思決定台帳は、決定を探して使うための基盤
議事録は会議の経過を残し、判断ログは判断の背景や比較した選択肢を記録します。議案書は、これから決める内容を検討するための資料です。
意思決定台帳は、それらを決定単位で結び、組織全体から参照できるようにする役割を担います。
たとえば「外部AIへの入力方針」を確認するとき、会議日を覚えていなくても、対象業務や部署から現在有効な決定を探せる状態を目指します。詳しい議論は関連する判断ログや議事録へたどれるようにします。
設計上の参考になるのが、システム開発で使われるADR、つまりアーキテクチャ上の意思決定記録です。Microsoftの公式ガイドでは、背景、選択肢、決定内容、影響、状態を記録し、決定が変わった場合は新しい記録を作って旧記録と関連付ける方法を示しています。Microsoft公式ガイド
この考え方を業務方針や経営判断に応用する際は、適用部署や有効期間も加えます。ただし、意思決定台帳を作っただけで、既存の決裁手続きや正式な会議記録を置き換えられるわけではありません。どの記録を正式な根拠とするかは、組織のルールに合わせて定めます。
データモデルは「一つの決定」を基本単位にする
台帳を会議単位で作ると、一つの記録に複数の決定が混在します。そのうち一件だけを変更したとき、どの部分が有効なのか分かりにくくなります。
基本は「一つの決定に一つのID」です。同じ会議で決めた事項でも、別々に変更・廃止できるものは分けて登録します。
初期導入では、次の項目をそろえると運用しやすくなります。
| 項目 | 記録する内容 |
|---|---|
| 決定ID・件名 | 決定を一意に識別する番号と、結論が分かる名称 |
| 決定内容・適用範囲 | 実施する方針、対象部署・業務、対象外となる条件 |
| 背景・選択理由 | 判断時の前提、比較した案、採用・不採用の理由 |
| 受け入れた不利益 | 費用、制約、運用負担、残るリスク |
| 承認情報 | 承認者、承認日時、正式な承認記録へのリンク |
| 有効性 | 適用開始日、終了日、見直し条件、現在の状態 |
| 関連情報 | 議事録、判断ログ、根拠資料、実行タスク、新旧の決定ID |
| 管理情報 | 管理責任者、機密区分、閲覧範囲、登録・変更履歴 |
件名を「AI導入について」とするより、「問い合わせ返信の下書きに生成AIを利用する」とした方が、決定内容を把握できます。さらに「対象は一般的な商品案内」「個別の契約条件は対象外」と書けば、適用範囲も明確になります。
台帳をシステム化する場合は、決定本体、承認・変更イベント、根拠資料、実行タスクを別々のデータとして関連付けます。一つの決定に複数の資料やタスクを結べるため、担当者や進捗が変わるたびに決定本文を書き換える必要がなくなります。
「承認済み」と「現在有効」を分けて管理する
承認された決定が、いつでも現在の方針として使えるとは限りません。適用開始前の場合もあれば、期限切れや新方針への置き換えによって役割を終えている場合もあります。
そこで、承認の状態と適用の状態を分けて管理します。
承認の状態は「下書き・審査中・承認済み・却下」などで表し、適用の状態は「開始前・有効・停止中・終了・置換済み」などで表します。見直し期限は、これらとは別の項目として持たせます。
たとえば、10月1日から新しい返品対応方針を適用する場合、9月中に承認されていても適用状態は「開始前」です。現行方針の終了日と新方針の開始日を対応させれば、切り替え時点を判断できます。
また、「見直し期限を過ぎたら自動的に無効になる」のか、「確認が終わるまで従来方針を継続する」のかも決めておきます。担当者ごとに解釈が分かれる運用は避けましょう。
決定本文を保全し、変更は履歴として追加する
過去の決定を現在の内容で上書きすると、当時の行動が何を根拠にしていたのか確認できなくなります。
決定内容を変更するときは、新しい決定を登録し、旧決定との関係を残します。AWSもADRの運用で、旧記録を置換済みにし、変更履歴とともに台帳へ残す方法を推奨しています。AWS公式ガイド
ここで区別したいのが、確定した本文と、その後に発生する管理情報です。承認後の本文は保全し、置き換え、停止、訂正などは変更イベントとして追加します。現在の一覧表示は、その履歴から更新できます。
誤記の訂正でも、訂正前後の内容、理由、実施者、日時を残します。方針の変更を「誤記修正」として処理しないため、修正の種類も分類しておくとよいでしょう。
実装時には、単に編集履歴があるだけなのか、管理者を含めて過去記録の削除・改変を制限できるのかも確認します。Gitなどのバージョン管理を使っても、権限や運用設定によっては履歴を書き換えられるため、ツール名だけで改ざん耐性を判断しないことが大切です。
承認・管理・実行の責任を明確にする
意思決定台帳の運用では、起案者、承認者、台帳管理者、実行責任者の役割を決めます。小規模組織では兼務できますが、誰が何を確定するかは明示します。
起案者は背景と選択肢を整理し、承認者は内容と適用範囲を確定します。台帳管理者は必須項目や関連リンク、見直し期限を点検し、実行責任者は決定に基づく業務を進めます。
特に、決定の有効性とタスクの完了は別管理にします。「利用方針は有効だが、全員への研修は未完了」という状態を表せるようにするためです。
閲覧権限も一律に全社公開するのではなく、決定内容に合わせます。人事、価格交渉、未公表の事業計画などを含む記録は、台帳本文だけでなく、添付資料や通知先にも同じ配慮が必要です。
管理基盤は、既存の業務環境から選びます。スプレッドシートでも開始できますが、承認記録、編集権限、履歴保全が不足する場合は、文書管理やワークフローを組み合わせます。製品比較より先に、必要な統制を整理すると選定がぶれにくくなります。
AIは根拠付きの下書きを作り、人が決定を確定する
AIを使う場合は、会議記録から決定候補を抽出し、台帳の下書きを作るところから始めます。
抽出項目には、決定内容だけでなく、適用条件、保留事項、却下案、受け入れた不利益も含めます。各項目に元の発言や資料の位置を添えれば、確認者が根拠へ戻れます。
ただし、「検討します」「条件が整えば進めます」といった発言を、承認済みの決定に変換してはいけません。承認の証拠が確認できない場合は、決定候補や未確認として残します。
NISTの生成AIリスク管理資料では、誤った内容をもっともらしく生成する「confabulation」がリスクとして整理されています。台帳作成でも、AIが補った説明を会議の事実と混同しない運用が必要です。NIST生成AIリスク管理資料
また、会議で言及されなかった制約を、AIが推測して埋めることは避けます。起案者が補足する場合は「会議後に追加確認した情報」として、根拠と確認者を記録します。
ローカルAIも選択肢ですが、端末内で動くことだけで安全性を判断できません。保存場所、外部通信、バックアップ、アクセス権限を確認したうえで、扱える情報を定めます。
AI参照では、権限・期間・適用範囲を先に確認する
台帳をAI検索へ接続する場合、文章の類似度だけで決定を選ぶと、古い方針や対象外の決定を回答に使うおそれがあります。
「現在の方針」を答える処理では、利用者の閲覧権限、承認状態、有効期間、適用範囲を確認してから、参照する記録を絞り込みます。AIへの指示文だけに頼らず、検索側の処理で制御する設計にします。
一方、「昨年の対応が何を根拠にしていたか」という質問では、当時有効だった決定を参照します。現在の方針と過去の根拠を調べる処理を分けることで、履歴も活用できます。
同じ対象に矛盾する有効な決定が見つかった場合、単純に登録日時が新しい方を採用してはいけません。新旧の関係や承認権限を確認し、解消できなければ管理責任者へ確認を回します。
回答には決定ID、参照時点、根拠リンクを添えます。利用者が回答を検証できる状態にすることが、台帳を組織資産として使う前提です。
一つの会議体から始め、参照できるかを評価する
初期導入では、部門横断の方針変更や継続的な支出を伴う判断など、後から参照する価値の高い決定を対象にします。日常的な調整まで全件登録すると、確認負担が大きくなります。
まず一つの会議体で、登録対象、必須項目、承認方法、見直し条件を決めます。過去の記録を移す場合は、確認できた事実だけを登録し、不明な承認者や理由を推測で埋めないようにします。
評価するのは記録件数より、「現在の方針を探せるか」「根拠までたどれるか」「置換済みの決定を誤って使わないか」です。AIを導入した場合は、決定の誤抽出、適用範囲の取り違え、人による修正時間も測ります。
まとめ
意思決定台帳の価値は、決定の根拠と現在の有効性を結び付け、組織が必要なときに参照できることにあります。
一つの決定に一つのIDを付け、適用範囲、承認情報、有効期間、新旧の関係を管理する。そのうえで、AIによる下書き作成と参照を組み込む順序が実務的です。
まずは一つの会議体で、担当者が変わっても「今、何を根拠に仕事を進めるべきか」が分かる状態をつくりましょう。
コメント