はじめに
「リスクアペタイト」という言葉を聞くと、少し金融っぽく、難しく感じるかもしれません。
ただ、考え方そのものはかなりシンプルです。
会社や組織が、目的を達成するために、どの種類のリスクを、どの程度まで受け入れるかを決めること。
NISTの用語集では、リスクアペタイトを「価値を追求するうえで、組織が広いレベルで受け入れる意思のあるリスクの種類と量」と説明しています。1
金融庁も、リスクアペタイト枠組み（RAF）を経営管理に関わる重要テーマとして整理しています。2 関連するガイドライン類では、形式的な遵守だけを重視した態勢にならないよう留意し、事業環境や経営戦略、リスクの許容度を踏まえた実質的な対応が求められています。3 リスクアペタイトの文脈では、形式的な導入そのものではなく、経営陣がどの分野でどの程度のリスクを取るかを議論し、見える化して、経営戦略や経営管理に活かすことが重要です。
つまり、リスクアペタイトは「危ないことを避けるための言葉」ではありません。
むしろ、「何を守り、何に挑戦し、どこで止めるか」を決めるための、経営・IT・セキュリティの共通言語です。
本稿の要点は次のとおりです。
- リスクアペタイトは「組織が目的達成のために受け入れるリスクの種類と量」
- 「リスクをゼロにする」考え方ではない
- ITでは、セキュリティ、可用性、コスト、スピード、利便性のバランスを決める軸になる
- リスク許容度は、より具体的な上限・下限として扱うと理解しやすい
- 現場任せにせず、経営・業務・ITが同じ言葉で判断するために使う
1. リスクアペタイトは「危険を好きになること」ではない
まず、言葉を分解します。
| 用語 | 意味 |
|---|---|
| リスク | 不確実性。うまくいかない可能性だけでなく、期待通りに進まない揺れ幅 |
| アペタイト | appetite。食欲、欲求、選好 |
| リスクアペタイト | 目的達成のために、どのリスクをどこまで受け入れるか |
ここで大事なのは、リスクアペタイトは「リスクが好き」という意味ではないことです。
たとえば、次のような判断があります。
| 判断対象 | リスクを避ける考え方 | リスクアペタイトを持つ考え方 |
|---|---|---|
| 新しいSaaSの導入 | 情報漏えいが怖いので使わない | データ分類を決め、低機密情報から使う |
| 生成AIの利用 | 誤回答が怖いので禁止する | 社外秘は禁止、文章案作成は許可する |
| システム変更 | 障害が怖いので変更しない | 影響範囲を限定し、段階的にリリースする |
| クラウド移行 | 外部サービスは不安なので避ける | 可用性・監査・契約条件を確認して採用する |
リスクアペタイトの考え方では、リスクを全部避けるのではなく、目的に照らして取るべきリスクと取ってはいけないリスクを分けることが重要になります。
NIST SP 800-39は、情報セキュリティリスクを、組織の業務、資産、個人、他組織などへの影響を含めて管理するための統合的なプログラムとして位置づけています。つまり、情報セキュリティは単なる技術設定ではなく、組織全体のリスク管理の一部です。4
2. リスクアペタイトとリスク許容度の違い
混同しやすい言葉に「リスク許容度」があります。
ざっくり言うと、次のように分けると理解しやすいです。
| 用語 | 役割 | 例 |
|---|---|---|
| リスクアペタイト | どの種類のリスクを、どの程度受け入れるかという方針 | 顧客情報漏えいリスクは極小化する。一方で、新サービス検証の失敗リスクは一定程度受け入れる |
| リスク許容度 | 実務上、どこまでなら許容できるかという具体的な範囲 | 月間停止時間は最大30分まで。重大脆弱性は7日以内に対応する |
| リスク限度 | 超えてはいけない境界線 | 個人情報を未承認SaaSへ投入してはいけない |
リスクアペタイトは、経営レベルの意思です。
一方で、リスク許容度やリスク限度は、現場が判断できるように落とし込んだ基準です。
たとえば、経営が「スピードを重視して新規サービスを試す」と言っても、何でも許されるわけではありません。
方針：
新規サービス開発では、一定の失敗リスクを受け入れる
ただし：
- 個人情報を本番相当データとして使わない
- 決済機能はテスト環境でのみ検証する
- 重大なセキュリティ指摘がある場合は本番公開しない
このように、挑戦する範囲と止める条件をセットで決めるのが、リスクアペタイトを実務で使うコツです。
FSBは、リスクアペタイトフレームワークの主要要素として、有効なフレームワーク、リスクアペタイトステートメント、リスク限度、取締役会・経営陣の役割と責任を挙げています。5
3. IT初心者向けに考える「リスクアペタイト」の例
ITの現場では、リスクアペタイトは次のような場面で使えます。
例1：生成AIを業務で使う
生成AIを完全禁止にすると、情報漏えいリスクや誤回答リスクは下がります。
しかし、業務効率化の機会も失います。
そこで、リスクアペタイトを次のように定めます。
| 項目 | 方針 |
|---|---|
| 受け入れるリスク | 一般情報を使った文章作成で、軽微な誤りが出るリスク |
| 受け入れないリスク | 個人情報、機密情報、未公開情報を入力するリスク |
| 対策 | 入力禁止情報の明文化、レビュー必須化、ログ確認 |
| 判断基準 | 社外秘以上の情報は投入禁止 |
この場合、リスクアペタイトは「AIを使うか使わないか」ではありません。
どの業務なら使ってよいか、どこから先は止めるかを決める考え方です。
例2：クラウドサービスを導入する
クラウドサービスには、便利さがあります。
一方で、次のようなリスクもあります。
- 障害時に自社だけでは復旧できない
- データの保管場所が外部になる
- 契約終了時のデータ移行が必要になる
- アカウント管理を誤ると情報漏えいにつながる
ここでリスクアペタイトを使うと、次のように整理できます。
| リスク領域 | 方針 |
|---|---|
| 可用性 | 業務停止の影響が小さい領域ではクラウド利用を進める |
| 機密性 | 顧客情報を扱う場合は認証・監査・契約条件を確認する |
| コスト | 初期費用削減は評価するが、長期利用料も確認する |
| 運用 | 管理者権限、退職者アカウント、ログ確認を必須にする |
クラウド導入で重要なのは、「クラウドは危険か安全か」という二択ではありません。
どのデータを、どのサービスに、どの条件で預けるかです。
例3：セキュリティ対策をどこまで厳しくするか
セキュリティ対策は、厳しくすればするほど安全になるように見えます。
しかし、現実にはトレードオフがあります。
| 対策 | メリット | デメリット |
|---|---|---|
| 多要素認証 | 不正ログインに強い | 利用者の手間が増える |
| 端末制限 | 未管理端末からのアクセスを防げる | 外出先や委託先の作業が難しくなる |
| メール添付禁止 | 誤送信リスクを下げられる | 業務フロー変更が必要になる |
| 厳格な承認フロー | 不正変更を防ぎやすい | リリース速度が落ちる |
リスクアペタイトがないと、現場ではこうなりがちです。
営業部門：
使いにくい。もっと自由にしてほしい。
情報システム部門：
危険なので許可できない。
経営層：
結局、何が問題で、どこまでなら許容できるのか分からない。
リスクアペタイトがあると、議論の軸が変わります。
顧客情報に関わるシステム：
利便性よりも機密性を優先する
社内ナレッジ共有：
一定の利便性を優先し、権限管理とログで補う
新規事業の検証環境：
スピードを優先するが、本番データ利用は禁止する
つまり、リスクアペタイトは、セキュリティ部門が止めるための言葉ではなく、組織として判断するための言葉です。
4. リスクアペタイトを決めるときの基本ステップ
初心者向けに、実務で使いやすい順番にすると次のようになります。
ステップ1：目的を決める
最初に決めるべきなのは、リスクではなく目的です。
何を達成したいのか。
何を守りたいのか。
何を早く進めたいのか。
たとえば、目的が「新規サービスを早く市場投入する」なら、一定の失敗リスクは受け入れる必要があります。
一方で、目的が「顧客情報を守る」なら、利便性よりも安全性を優先する場面が増えます。
JIS Q 31000（ISO 31000に対応する日本工業規格）は、リスク管理を、リスクの特定、分析、評価、対応、監視、コミュニケーションを含む包括的なアプローチとして説明しています。6
ステップ2：リスクの種類を分ける
次に、リスクをひとまとめにしないことが重要です。
| リスクの種類 | 例 |
|---|---|
| 情報漏えいリスク | 顧客情報、個人情報、機密情報の流出 |
| 可用性リスク | システム停止、サービス停止 |
| 品質リスク | バグ、誤回答、誤処理 |
| 法令・契約リスク | 規約違反、委託契約違反、監査不備 |
| レピュテーションリスク | 信頼低下、炎上、顧客離れ |
| コストリスク | 想定以上の利用料、運用負荷 |
「リスクがあるからダメ」ではなく、どのリスクが、どの程度あるのかを分けて考えます。
ステップ3：受け入れる／減らす／避ける／移転する
リスクへの対応は、大きく分けると次の4つです。
| 対応 | 意味 | 例 |
|---|---|---|
| 受容 | そのリスクを受け入れる | 軽微な社内FAQの誤記はレビューで対応する |
| 低減 | 対策してリスクを下げる | 多要素認証、権限管理、ログ監視を入れる |
| 回避 | その行為をしない | 機密情報を外部AIに入力しない |
| 移転 | 契約や保険で他者に一部移す | SLA、損害賠償条項、サイバー保険 |
リスクアペタイトは、この判断を場当たり的にしないための基準です。
ステップ4：現場が使える言葉にする
リスクアペタイトは、経営会議の資料に書いて終わりでは意味がありません。
現場で使えるように、具体的な判断基準へ落とし込みます。
悪い例：
セキュリティリスクを適切に管理する。
良い例：
個人情報を含むデータは、会社承認済みサービス以外に入力しない。
生成AIは、公開情報・一般情報・文章案作成に限定して利用する。
本番環境への変更は、レビューと切り戻し手順を必須とする。
ポイントは、読んだ人が同じ判断をできる粒度にすることです。
5. リスクアペタイトをITで使うと何が良いのか
リスクアペタイトを決めると、IT現場にはいくつかの効果があります。
| 効果 | 内容 |
|---|---|
| 判断が速くなる | 毎回ゼロから議論しなくてよくなる |
| 部門間の対立が減る | 営業、情シス、経営が同じ基準で話せる |
| セキュリティが説明しやすくなる | 「危険だから」ではなく「この基準を超えるから」と説明できる |
| 新しい技術を使いやすくなる | 禁止ではなく、条件付き利用にできる |
| 監査・説明責任に強くなる | なぜ許可したか、なぜ止めたかを説明できる |
特にIT初心者にとって重要なのは、リスクアペタイトを知ることで、セキュリティやガバナンスを「ブレーキ」ではなく「判断の補助線」として見られるようになることです。
たとえば、生成AI、クラウド、SaaS、API連携、リモートワークなどは、すべて便利さとリスクがセットです。
リスクアペタイトがない組織では、次のどちらかに振れやすくなります。
全部禁止する
または
現場判断で何でも使う
しかし、どちらも危険です。
全部禁止すれば競争力を落とします。
何でも使えば事故の可能性が高まります。
だからこそ、何を許し、何を止め、何を条件付きにするかを決める必要があります。
おわりに
リスクアペタイトは、難しい金融用語に見えます。
しかし、ITの現場に置き換えると、かなり実用的な考え方です。
一言でいえば、次のようになります。
リスクアペタイトとは、目的を達成するために、組織として「どこまでリスクを取るか」を決めること。
大事なのは、リスクをゼロにすることではありません。
リスクを見える化し、取るべきリスクと取ってはいけないリスクを分けることです。
IT初心者ほど、「危険だから禁止」か「便利だから使う」の二択になりがちです。
しかし、実務ではその間に多くの選択肢があります。
- 低機密情報なら使う
- 本番データは使わない
- 承認済みサービスだけ使う
- ログを残す
- 重大リスクは経営判断に上げる
- 小さく試して、問題があれば止める
リスクアペタイトは、その判断を属人化させないためのものです。
IT、セキュリティ、経営、現場部門が同じ言葉で話すために、まずは小さくてもよいので、自社・自チームの「どこまでなら許容できるか」を言語化するところから始めるのがよいです。
-
NIST CSRC「Risk Appetite - Glossary」 ↩
-
金融庁「金融安定理事会による「再建・処理計画の策定に関するガイダンス」及び「リスクアペタイト枠組みに係る原則（市中協議文書）」の公表について」 ↩
-
NIST「SP 800-39, Managing Information Security Risk: Organization, Mission, and Information System View」 ↩
-
Financial Stability Board「Principles for an Effective Risk Appetite Framework」 ↩
-
ISO「ISO 31000:2018 - Risk management — Guidelines」（日本ではJIS Q 31000:2019として規格化） ↩