オープン・ソース型モデルの浸透－どのようにモデル統治を進めるべきか?　|ニッセイ基礎研究所

1――はじめに

保険会社は、商品の価格設定や、準備金の積立・評価、必要資本の算定などのために、システム上にモデルを構築して、シミュレートすることが一般的だ。モデルを通じて、将来収支を計算したり、リスクの発生や影響度を見積もったりすることで、経営の意思決定やリスク管理に役立てている。

モデルの活用は、世界中の保険会社で行なわれている。従来は、保険会社内で最初から最後まですべてを作り込む、自社完結型のクローズド・ソース型のモデル構築が一般的であった。近年、さまざまな業界で見られるオープン・イノベーションの一環として、モデル構築においても、社外からの知見を取り入れるべく、オープン化を模索する動きが出ている。

本稿では、2018年にアメリカのアクチュアリー会冊子に掲載された記事をベースに、オープン・ソース型モデルや、その統治について検討していくこととしたい¹。

¹ “An Open Source” Rohan N.Alahakone, Dorothy L. Andrews(The Actuary, Jun. Jul.2018, SOA)を参考にしている。

2――オープン・ソース型モデル

まず、オープン・ソース型モデルとはどういうものか、クローズド・ソース型モデルと比較しながら見ていくこととしよう。

1｜オープンソースは、誰でも自由に扱ってよいコンピュータープログラム
人間が理解しやすいプログラミング言語で書かれたコンピュータープログラムは、「ソースコード」と呼ばれる。コンピューターは、機械語で書かれたプログラムをもとに動いている。機械語のプログラムは、人間にとって理解が困難で、まるで暗号のようであることから、暗号を意味する「コード」という言葉を使ってプログラムのことを言い表すようになったといわれている。そして、人間がプログラミング言語で書いたコンピュータープログラムは、コードのもと(ソース)となるものであるため、ソースコードと呼ばれるようになった²。

「オープン・ソース」とは、そのソースコードを広く一般に公開して、誰でも自由に扱ってよいとする考え方を指す。また、そうした考え方により公開されるソフトウェアのことを指す場合もある。

オープン・ソースは、アメリカのオープン・ソース・イニシアティブ³が、ソースコード形態での配布、ソースコードの改変・再頒布の自由、特定の人・集団・用途の差別禁止などの定義を置いている⁴。

² ソースコードを機械語のプログラムに翻訳することをコンパイルと呼ぶ。
³ オープンソース思想の啓蒙で有名なエリック・レイモンド氏らを中心に1998年に設立された非営利団体。
⁴ オープンソースの定義は、10ヵ条からなる。その項目は、再頒布の自由、ソースコード、派生ソフトウェア、作者のソースコードの完全性、個人または集団に対する差別の禁止、用途分野に対する差別の禁止、ライセンスの分配、特定製品でのみ有効なライセンスの禁止、他のソフトウェアを制限するライセンスの禁止、ライセンスの技術中立性。

2｜オープン・ソース型とクローズド・ソース型には、一長一短がある
多くの保険会社が、商品の価格設定をしたり、将来収支を計算したり、必要資本を算定したりする際のモデル構築において、オープン・ソース型とするか、クローズド・ソース型とするか、検討を始めているといわれる。モデルは、経営の意思決定や収支予測にとどまらず、財務や決算報告などでも、重要な役割を担う。もしモデルやその処理にエラーがあれば、多額の損失発生、法的制裁(罰金)、風評の失墜、はては財務破綻にまでつながる恐れがある。

オープン・ソース型とクローズド・ソース型には、一長一短がある。たとえば、ソースコードの管理という点では、クローズド型のほうが優れている。一方、ソースコードの透明性を確保する点では、オープン型のほうが上をいく。こうした長所や短所は、つぎのようにまとめることができる。

3｜モデルリスクを減らすことがモデル構築の大きな課題
モデルを構築して活用する上で、考慮しなくてはならないリスクとして、「モデルリスク」が挙げられる。モデルリスクの定義にはいくつかのものあるが、現在、比較的多くの人が有効と考えている定義は、1996年にゴールドマン・サックスの定量戦略調査ノートで示されたものだ。そこでは、モデルリスクは「財務の意思決定を行なうためにモデルを利用することで、損失が生じるリスク」と定義されている。そしてこのノートでは、つぎのように、モデルリスクの種類が示されている。

モデルリスクを減少させるためには、「モデル統治」が必要となる。モデル統治とは、モデルの要素へのアクセス権限を特定の人に限定することや、要素変更の際に、社内の所定の手続きをとって、経営の了承を得ることなどを指す。

3――モデル統治のあり方

通常、オープン・ソース型モデルの場合、ソースコードが広く公開されていて、プログラム開発の柔軟性が高い。一方で、クローズド・ソース型モデルよりもモデルリスクが高まるという難点もある。そこで、「どのようにモデルを統治するか」がカギとなる。以下、モデル統治について、みていこう。

1｜まず、環境の設定、対象範囲の定義、担当者の職務設定が必要
モデル統治には、「モデル統治フレームワーク(Model Governance Framework, MGF)」を設けることが重要とされている。MGFは、環境の設定、対象範囲の定義、担当者の職務設定からなる。

(1) 環境の設定
統治を効果的に行なうには、全社の一貫した関与と、リスク管理のカルチャーの浸透が必要となる。一般に、新たなインフラを導入する時には、変化への抵抗を示す人々が出てくる。このため、MGFの目的や重要性について、すべての関係者を啓蒙することが重要となる。その際、関係者を開発に巻き込むことも有益となる。自らが開発したり、実行したりしたものには、支援する意識が働くためだ。このようにして、リスク管理のカルチャーが各部門や会社全体に自然に織り込まれていく必要がある。

(2) 対象範囲の定義
モデル統治の対象範囲には、会社機能に影響を及ぼすすべてのモデルが含まれる。しかし、モデル統治の初期段階では、MGFの対象となる重要なモデルをいくつか選ぶことが賢明となろう。MGFでは、一定の手順で処理が行なわれる。この手順には、モデルの妥当性確認、経営の承認などが含まれる⁵。

⁵ MGF対象の手順として、仮定の設定、データの移動、モデルの高度化、モデルの妥当性確認、モデルの修正、モデルの保存記録、モデルの結果の利用、経営の承認、ソフトのアップデートと統合、ピア・レビューが挙げられる。

(3) 管理者の職務設定
モデル管理者の基本的な職務は、組織的に、MGFやその管理が遵守されていることの確認である。当初は、モデル管理者は、モデル開発者や利用者から良い評価が得られないことが多い。たとえば、

「規約があるせいで、プログラム実行中の変更ができない」

「モデル管理者がいることで、経営者が開発者や利用者を信用していないかのような印象を与える」

「モデルのプログラム変更よりも、打ち合わせや、細かい記述・分析作業ばかりが増加してしまう」

「文書化に多くの時間が必要となる」

といった声だ。しかし時を経て、モデル管理者の支援により統治手順が徐々に改良されてくると、開発者や利用者は、この枠組みがモデルリスクの軽減に効果があることに気づくようになる。

2｜モデルの関係者がそれぞれの役割を果たすことが重要
MGFを活用するには、モデルの関係者がそれぞれの役割を果たすことが重要となる。関係者には、モデル承認者、モデル開発者、モデル利用者、監視者、モデル管理者、保証人がいる。順次みていく。

(1) モデル承認者
モデル承認者は、プログラムや仮定の変更を承認する任務を負う。通常は、その管理を行うのは、上級経営管理者である。モデルの変更はすべて、承認される前に正当性を確認され、ピア・レビューを受け、文書化され、分析される。専門性や変更内容によっては、複数のモデル承認者グループが必要となる場合もある。たとえば、モデルの仮定を承認するグループとは別に、プログラムの変更を承認するグループが必要となることがある。

(2) モデル開発者
モデル開発者は、プログラムと仮定を変更する権限を付与されている。その専門性は、ソースプログラムと開発の知識に基づいている。プログラムの変更はすべて、一定のプログラミング基準にしたがって行われる。そして、モデル結果への影響が、計量され、確認され、分析され、独立して検証され、ピア・レビューされ、文書化される。モデル開発者は、保証人(後述)の要求にしたがってモデル変更に取り組み、承認を受けるために、モデル承認者に変更内容を提示する。

(3) モデル利用者
モデル利用者は、報告や分析の目的でモデル結果を利用する。具体的には、準備金評価、価格設定、GAAP財務報告、エンベディッド・バリュー報告、将来予測などに責任を負っている。モデル利用者は、モデル開発者と緊密に連携して、モデルの変更に関するさまざまな要求を提出する。また、開発の前には、モデル機能のピア・レビューに深く関与することが多い。

(4) 監視者(ゲートキーパー)
監視者は、開発モデルの管理人である。監視者は、開発領域に、承認されたモデル変更だけが導入されることを確認するために、モデル管理者と緊密に連携する。その特徴的な役割は、モデルを最新のバージョンに置き換えるにあたって、それまで使用していた古い開発のバージョンを保管することにある。そして、新しいバージョンが所期したとおりに稼動することを確認する。監視者は、開発環境に正当なモデルが導入されることを確保する任務を負っている。

(5) モデル管理者
モデル管理者は、モデル統治の中心的な役割を演じる。すべての人がモデル統治の枠組みに沿って機能することを確認する。モデル管理者の責任には、モデル変更の過程がスムーズに進行することの確認が含まれる。これは、承認者との打ち合わせを進めたり、すべてのモデル変更要請のリストを作成してスケジュールを立案・管理したり、モデル変更要請の優先順位付けをしたり、あらゆる集団と一緒に要請に対する最適解が得られることを確保したりすることなどによって行われる。モデル管理者は、適切に評価を行ない、オープン・ソース型のソフトウェアをよく理解しておくことが期待されている。プロジェクト管理のスキルは、その役割に不可欠のものとなる。

(6) 保証人(スポンサー)
モデル変更の保証人は、通常、諸準備金評価、GAAP等の財務報告領域、もしくは価格設定について権限と責任をもつ上級管理職が務める。保証人は、モデル管理者とともにモデルの変更要請のスケジュールを立てる。保証人は、モデル変更要請が予定通りに実施されることを確認する職務を負う。