アサンプションレジストリビルダー は何をしますか？
使用するタイミング
モデルが完成し、引き継ぎ、承認、または定期的な使用のために文書化する必要がある場合にこのスキルを使用します。クライアントやレビュー担当者が「この前提はどこから来たのか？」と尋ねたとき、資本配分の決定前にモデルを正式に承認する必要があるとき、モデルを複数の人が時間をかけて更新する場合、またはビジネスケースに正式な前提承認ログが必要な場合にトリガーします。作業モデルを完全に文書化された監査可能なアセットに変換します。
機能
構造化されたアサンプションレジストリを生成します。モデル内のすべての重要な前提をリストアップした専用の「前提条件」タブで、以下の列を含みます：前提名、カテゴリ、基準値、出典と根拠、強気値と弱気値、感応度順位（主要アウトプットへの影響）、および担当者。データテーブル出力を使用して感応度順位を計算するための数式と、アクティブな監視が必要な前提のためのフラグシステムも含まれます。
方法
-
「重要な前提」を定義します。 モデル内のすべての入力がアサンプションレジストリに含まれる必要はありません。重要な前提とは、(a) 感応度が高い（トルネードチャートの上位50％）入力、(b) 真に不確かな（契約上または規制上の確実性に基づかない）入力、(c) 間違っていた場合に推奨事項や決定を変更する入力です。確実性が高い前提（法定税率や既知の契約価格など）もレジストリに含めるべきですが、「低」の感応度順位と「規制/契約」の出典を付けます。
-
アサンプションレジストリの構造を構築します。 「前提条件」タブには以下の列レイアウトを使用します：
列A: 前提ID（A001、A002、... 簡単な相互参照用）。 列B: 前提名（明確なラベル。「入力」タブのラベルと一致）。 列C: カテゴリ（収益、コスト、資本、マクロ/市場、運用、戦略）。 列D: 基準値（「入力」タブのセルを参照。ハードコードされた繰り返しは避ける）。 列E: 単位（%、$M、x、#、日数など）。 列F: 出典/根拠（テキスト：この数値はどこから来たのか？経営陣のガイダンス、業界レポート、過去平均、アナリストコンセンサス、ベンチマーキング）。 列G: 強気値（強気シナリオにおける有利な前提値）。 列H: 弱気値（弱気シナリオにおける保守的な前提値）。 列I: 感応度順位（主要アウトプットへの影響に基づく高/中/低または1-10の数値順位）。 列J: 主要アウトプットへの影響（この前提が弱気から強気に変わったときの主要アウトプットの変化 — トルネード分析から計算）。 列K: 監視フラグ（アクティブ/パッシブ — アクティブは、この前提をモデル更新のたびに再確認する必要があることを意味します）。 列L: 担当者（この前提の検証と更新を担当する人）。 列M: 最終確認日（この前提が最後に現実に対して確認された日付）。 列N: 備考（追加のコンテキスト、計画された変更、不確実性フラグなど）。
-
「入力」タブからアサンプションレジストリにデータを投入します。 「入力」タブを体系的に確認します。青色の塗りつぶし入力セルごとに、「前提条件」タブに対応する行を作成します。基準値列（D）は、「入力」タブへのセル参照にします：='Inputs'!$D$5。これにより、レジストリは常に現在のモデル値を表示し、静的なコピーにはなりません。
-
意味のある出典/根拠エントリを記述します。 これは監査と承認プロセスで最も重要な列です。許容される出典：「経営陣のガイダンス、FY2024予算プレゼンテーション」、「監査済み財務諸表（FY2021-FY2023）からの3年平均」、「業界ベンチマーク：[セクター]中央値、[データタイプ]から」、「比較可能な上場企業からのアナリストコンセンサス」、「契約：[日付]のサプライヤー契約」、「比較可能な取引データに基づく推定」。許容されないもの：「想定」、「推定」、または空白。
-
強気値と弱気値を定義します。 3シナリオモデルが構築されている場合、強気値と弱気値を「シナリオ入力」タブから直接取得します：='Scenario Inputs'!$E$5（強気）および='Scenario Inputs'!$F$5（弱気）。シナリオモデルが存在しない場合は、トルネード分析からのプラス/マイナス範囲に基づいて強気値と弱気値を設定します。範囲の根拠は備考列に文書化します。
-
データテーブル出力を使用して感応度順位を計算します。 各前提の感応度順位は、前提が弱気値から強気値に変化したときの主要モデル出力への影響を測定します。
トルネードチャートのデータテーブルが構築されている場合（sensitivity-tornadoスキルを使用）、そのデータテーブルから影響値を直接参照します。
主要アウトプットへの影響の数式：='Tornado - Data Table'!F_row - 'Tornado - Data Table'!E_row（この変数の高影響値から低影響値を引いたもの）。
感応度順位（1-10、1が最も影響大）：影響列にRANK関数を使用：=RANK(J5, $J$5:$J$50, 0) ここでJ5はこの前提の影響列のセルです。順位1は、これが最も影響力のある前提であることを意味します。
感応度カテゴリ（高/中/低）：=IF(I5<=3,"High",IF(I5<=7,"Medium","Low")) ここでI5は数値順位です。
-
レジストリをソートして整理します。 感応度順位（昇順）でソートし、最も影響力のある前提を上部に配置します。各順位層内ではカテゴリでソートします。固定されたヘッダー行を追加して、スクロール時も列名が表示されるようにします。Excelのオートフィルターを追加して、ユーザーがカテゴリ、担当者、または感応度順位でフィルタリングできるようにします。
-
上部にサマリーセクションを追加します。 レジストリ本体の上に、サマリーブロックを追加します：
レジストリ内の総前提数：=COUNTA(A_range)-header rows。 高感応度の前提数：=COUNTIF(SensitivityCategoryRange,"High")。 アクティブ監視の前提数：=COUNTIF(MonitoringFlagRange,"Active")。 出典がない前提数：=COUNTBLANK(SourceRange)。 最終レビュー日：[手動入力の日付セル]。 レビュー担当者：[手動入力の名前セル]。
-
読みやすさを向上させるために書式設定を適用します。 行のバンディング（薄いグレーと白の交互行）を適用します。感応度カテゴリ列に条件付き書式を適用：高 = オレンジ色、中 = 黄色、低 = 塗りつぶしなし。監視フラグ列に条件付き書式を適用：アクティブ = 青色塗りつぶし。最終確認日列に条件付き書式を適用：日付が90日以上前の場合、赤色塗りつぶし（=TODAY()-M_cell>90）。
-
監視プロトコルを定義します。 「アクティブ」監視の前提ごとに、以下を文書化します：誰が更新を担当するか、どのくらいの頻度でレビューする必要があるか、どの外部データソースを確認すべきか。これにより、レジストリは生きた文書に変わります。スケジュールされたレビュー日付列を追加します：この前提を次に確認すべき日付。
-
レジストリをモデル承認プロセスにリンクします。 「承認者」列と「承認日」列を追加します。正式な承認プロセスの場合、各前提の担当者はモデルを提示する前に自分の前提に署名する必要があります。上部のサマリーブロックは、未承認の前提をフラグする必要があります：=COUNTBLANK(SignOffRange)。このカウントが0より大きい場合、モデルを取締役会や投資委員会に提示してはなりません。
-
レジストリのバージョン履歴を維持します。 モデルが更新されたら、アサンプションレジストリも更新します。「以前の基準値」列と「前バージョンからの変更」列を追加します。これにより、モデルバージョン間で前提がどのように変化したかを示す監査証跡が作成されます。「ドキュメント」タブに各バージョンの変更サマリーを記録する必要があります。
入力
- 「入力」タブからのすべてのモデル入力のリスト（名前、値、単位）
- 各前提の出典または根拠（経営陣のガイダンス、履歴データ、ベンチマーク）
- 各前提の強気値と弱気値（シナリオモデルまたはトルネード分析から）
- 各前提の主要アウトプットへの影響（