Saidotの既製リスク一覧を規程に写す方法｜借りる範囲と承認者

「AIの利用規程を作れと言われたが、どんなリスクを並べ、どんな統制を書けば足りるのか見当がつかない」「海外の基盤には既製のリスク一覧が入っていると聞くが、それをそのまま社内規程にしてよいのか分からない」——AIガバナンスの担当を任された情報システム部門や法務、AI推進の担当者から、最近増えている相談です。Saidot は、AIの台帳と、リスク・統制・規制の既製のライブラリを一体にしたフィンランドのガバナンス基盤です。既製の一覧は出発点としては強力ですが、そのまま写せば自社の規程になるわけではありません。この記事では、Saidot が何を持っている基盤かを確かめたうえで、既製のリスク一覧を借りて社内規程に写す手順と、借りる範囲、承認者の決め方を整理します。

Saidot は、AIの台帳とリスク・統制の既製ライブラリを持つガバナンス基盤

Saidot は、社内で使うAIのシステム、モデル、データ、エージェントを一つの台帳にまとめ、それぞれに関係するリスク・統制・方針を結びつけて管理する基盤です。公式サイトは、これらを知識のつながりの図として持ち、部品が変わると関係する管理情報も更新される仕組みだと説明しています。たとえば台帳に登録したシステムが外部のモデルを使っていれば、そのモデルに結びついたリスクが自動で引き継がれます。

特徴は、既製のライブラリです。公式サイトでは、260を超えるリスク、620を超える統制、110を超える方針、170を超える外部のAIモデルと製品の情報を、提供元のガバナンスの専門家が整えて維持していると説明しています。料金の案内ページでは統制を600超、モデルと製品を100超と書いている箇所もあり、数字は時期やページで揺れがあります。いずれにせよ、白紙から一覧を作るのではなく、整えられた棚から選べることが売りです。

対応する枠組みとして、公式サイトはEUのAI法、ISO の42001、米国NIST のリスク管理の枠組みなどを挙げています。もう一つの特徴が、エージェントの扱いです。エージェントを目的・来歴・自律の度合いとともに目録に登録し、エージェントが使うモデルではなく、触れられる道具ごとにリスクを分類すると公式サイトは説明しています。Azure と Amazon Bedrock の開発基盤とは連携が組み込まれ、ほかの仕組みとは機能の大半を外部の接続口から操作できるとしています。

作っている会社と、2024〜2026年の動き

Saidot はフィンランドのヘルシンキに本社を置く会社です。公式サイトによれば、自社の情報セキュリティの管理の仕組みは ISO の27001の2022年版の認証を受けています。2024年11月にはマイクロソフトとの協業を発表し、公式サイトにはマイクロソフトの責任あるAIの担当幹部の推薦の言葉が載っています。Azure のマーケットプレイスからも調達できる形になっており、Azure を使っている会社では購買の経路の一つになります。

2026年2月24日には、北欧のIT企業ヴィヴィクタ（旧社名はティエトエヴリーのテックサービス部門）との戦略的な提携が発表されました。ヴィヴィクタの発表文によれば、ヴィヴィクタの助言と導入の支援に Saidot の基盤を組み合わせ、設計・構築・運用の三段階で、目的と体制づくり、AIの登録と監査、継続的な監視までを支えるとしています。2026年の春には両社で、AIガバナンスを実務に落とす講演の配信も行っています。

公式サイトでは、2026年の時点で、エージェント自身が管理の作業を担う考え方を前面に出しています。公式ブログでは、評価が古くなっている高リスクのシステムの確認、新しい道具の登録、リスク評価の下書きといった作業を、データの上で動くエージェントとの対話で行い、人は判断に集中するという構想を示しています。利用者が自分のAIの道具を MCP で Saidot につなげる口も用意されています。終了や新規受付の停止の告知はなく、更新が続いている製品です。

• ライブラリの件数や機能の範囲は公式サイトの説明で、ページによって数字が異なる箇所があります。契約の際に、どの版のライブラリが使えるかを書面で確かめてください
• 日本での販売代理店や、日本語での提供は、今回確認した公式の公開情報からは見つかりませんでした

既製のライブラリを借りるか、自社で一から作るか

最初の判断は、既製のライブラリを借りるかどうかです。借りる利点ははっきりしています。自社では思いつかないリスクの候補が並んでいること、海外の規制や規格との対応づけが付いていること、外部のモデルのリスク情報を自分で調べなくて済むことです。AIの台帳の項目や持ち主の決め方は別の記事で扱っているので、ここでは借りた一覧をどう自社の規程にするかに絞ります。

一方で、既製の一覧には借りるときの落とし穴があります。よく起きるのは次のような失敗です。どれも、一覧を候補ではなく完成品として扱ったことから起きます。

• 既製の統制を全部有効にした結果、一つのAIの登録に数十項目の確認が付き、現場が登録そのものを避けるようになる
• 海外の規制の条文番号に結びついた統制を、国内の部署が読んでも意味が分からないまま規程に貼り付ける
• 自社が使っていない種類のAIのリスクまで並び、本当に危ない使い方が一覧の中に埋もれる
• 提供元がライブラリを更新したとき、どの統制が変わったかを誰も見ておらず、規程と台帳がずれていく
• エージェントを一つの項目として登録し、触れられる道具の違いをリスクに反映していない

判断の目安は、自社のAIの使い方の数です。社内で使うAIが数件で、使い方も文章の下書き程度なら、既製の基盤を入れずに、公的な指針をもとに一覧を作るほうが早い場合があります。部署ごとにAIの利用が増え、エージェントが業務の道具につながり始めた段階で、既製の一覧と台帳を一体で持つ価値が出てきます。以下は、借りると決めた場合の手順です。

手順1：自社のAIの使い方を、ライブラリに当てる前に洗い出す

最初の手順は、ライブラリを開く前にやることです。既製の一覧を先に眺めると、一覧にあるリスクを順に検討する作業になり、自社の使い方から出発する視点が失われます。まず、社内でどの部署が、どのAIを、どの業務に、どのデータを使って使っているかを洗い出します。この段階では網羅より、実際に使われているものを確実に拾うことを優先します。

洗い出す単位は、道具の名前ではなく使い方です。同じ生成AIでも、記事の下書きに使う場合と、顧客からの問い合わせに答える場合では、リスクがまったく違います。エージェントの場合は、どの業務の道具に接続され、何を読み、何を書き込めるかまで書き出します。顧客管理の仕組みを読むだけなのか、メールを送れるのか、広告の予算を変えられるのかで、後の手順の重さが変わります。

洗い出しの結果は、Saidot の台帳に入れる前の下書きとして、表計算の一覧で十分です。ここで大事なのは、使い方ごとに持ち主の部署を一つ決めておくことです。持ち主の決まっていない使い方は、ライブラリからリスクを選んでも、誰も統制を守らない項目になります。Saidot の台帳はシステムや外部モデルとの結びつきから自動でリスクを引き継ぎますが、使い方の洗い出しは人が行う作業です。

手順2：既製のリスク一覧から、自社に当てはまるものを選ぶ

洗い出した使い方ごとに、既製のリスク一覧から当てはまるものを選びます。Saidot では、台帳に登録したシステムやモデルに結びついたリスクが自動で引き継がれるため、選ぶ作業の出発点は、自動で付いたリスクを見直すことになります。自動で付いたリスクには、自社の使い方では起きないものも含まれます。逆に、自社固有の使い方に由来するリスクは、自動では付きません。

見直しの基準は三つです。その使い方で実際に起こり得るか。起きたときに誰が困るか。すでに別の社内の決まりで手当てされているか。起こり得ない、または既存の決まりで手当て済みのリスクは、外した理由を書いて外すようにします。理由を書かずに外すと、監査や次の担当者の見直しで、なぜ外したのかが分からなくなります。

自動で付かないリスクを足すのも、この段階です。たとえばマーケ部門では、生成AIで作った広告の文言が景品表示法の表示の規制に触れる、他社の素材に似た画像が作られるといった、国内の法令や業界の慣行に由来するリスクがあります。こうしたリスクは、既製の一覧に近いものがあればそれを使い、なければ自社のリスクとして新しく足すと決めておきます。既製の一覧にないことは、リスクがないことを意味しません。

手順3：統制を、国内の法令と社内規程の言葉に写す

選んだリスクには、既製の統制が結びついています。ここが最も手間のかかる手順です。既製の統制は、EUのAI法や ISO の規格、米国の枠組みの言葉で書かれていることが多く、そのまま社内規程に貼ると、国内の部署には何をすればよいかが伝わりません。統制の中身を、国内の法令と自社の規程の言葉に写し直す必要があります。EUのAI法そのものの適用範囲や時期は別の記事で扱っているので、ここでは写し方の型だけを示します。

写し方の基本は、統制ごとに、国内で根拠となる法令や指針と、自社の規程の条項を一つずつ結びつけることです。国内では、2025年に公布されたAI推進法、総務省と経済産業省のAI事業者ガイドライン、個人情報保護法の委託と越境移転の決まりなどが、写し先の候補になります。次の表は、写し方の例です。

既製の統制の趣旨	国内で根拠にするもの	社内規程での書き方の例	持ち主
学習や入力に使うデータの出どころを記録する	個人情報保護法（利用目的・委託・越境移転）	AIに入力してよい情報の区分と、外部事業者への提供の手続き	法務・個人情報の担当
人による監督と介入の手段を用意する	AI事業者ガイドライン（人間の判断の介在）	AIの出力を使う前に人が確認する範囲と、停止できる人	使い方の持ち主の部署
利用者にAIの利用を知らせる	AI事業者ガイドライン（透明性）、景品表示法	顧客に見せる文書や応答でAIを使うときの表示の決まり	広報・マーケ
外部モデルの提供元を評価する	取引先管理の社内規程、AI事業者ガイドライン	外部のAIサービスを新しく使うときの審査の手順	情報システム部門・購買
事故の記録と報告の手順を持つ	社内の事故対応の規程	AIの誤りや情報の流出が起きたときの報告先と期限	情報システム部門

表の右端の持ち主を空けたまま写すと、統制は規程の文章として残るだけになります。Saidot では、有効にした枠組みだけがシステムの持ち主に届く仕組みが案内されていますが、どの枠組みを有効にするかを決めるのは、規程の責任者です。海外の枠組みを有効にする場合も、国内の言葉に写した統制と並べて、どちらを社内の正本にするかを決めておきます。

手順4：エージェントは、触れられる道具ごとにリスクを分ける

Saidot の特徴の一つが、エージェントのリスクを、使うモデルではなく触れられる道具ごとに分類する考え方です。公式サイトは、エージェントを追加すると、アクセスできる道具にもとづいて自動で分類すると説明しています。同じモデルを使うエージェントでも、顧客管理の仕組みを読むだけのものと、顧客にメールを送れるものでは、起こり得る事故の大きさが違うからです。

社内規程に写すときも、この考え方は使えます。エージェントの審査を、エージェント全体に対して一回で行うのではなく、接続する道具ごとに審査し、道具を一つ足すたびに、その道具の分だけ審査をやり直すと決めます。これにより、最初は読み取りだけで承認したエージェントに、後から書き込みや送信の道具が足されて、審査を経ずに権限が広がる事態を防げます。

段階の付け方は、自社で決めます。たとえば、社内の情報を読むだけの道具は低、社内の記録を書き換えられる道具は中、顧客や社外に何かを送れる道具や、お金や契約にかかわる道具は高、といった分け方です。自動の分類は出発点として使い、自社の業務で何が起きたら困るかに照らして、人が段階を確定させます。自動の分類をそのまま確定にすると、自社固有の重さが反映されません。

手順5：承認者を、リスクの段階ごとに決める

リスクの段階が決まったら、段階ごとに承認者を決めます。承認者を一人に集めると、その人が詰まりになり、現場は登録を避けるようになります。おすすめは、段階が低いものは使い方の持ち主の部署の責任者、中は情報システム部門、高は横断の委員会や規程の責任者というように、段階に応じて承認の重さを変えることです。

承認には、登録の承認だけでなく、停止の権限も含めます。エージェントが想定外の動きをしたとき、誰が止められるかが決まっていなければ、承認の仕組みは事故の場面で役に立ちません。停止できる人は、承認した人より現場に近い人を含めておくのが実務的です。夜間や休日に止められる人がいるかも確かめておきます。

Saidot の公式サイトは、人が管理の主導権を持ち、エージェントは見つけて下書きを作り、チームが判断して承認すると説明しています。管理の作業をエージェントに手伝わせる場合も、承認の行為そのものは人の名前で記録することを規程に書いておきます。誰が何を根拠に承認したかが残らなければ、後から承認の妥当性を検証できません。

手順6：外部のAIモデルの情報を借りるときの確かめ方

Saidot のライブラリには、外部のAIモデルや製品のリスク情報も含まれており、台帳に登録したシステムが使うモデルのリスクを自動で引き継げます。自社で一つずつ調べる手間が省けるのは大きな利点ですが、借りた情報は、提供元の公開情報をもとに整えた二次情報です。自社が実際に結んでいる契約の条件とは一致しない場合があります。

たとえば、同じモデルでも、個人向けの契約と法人向けの契約では、入力したデータが学習に使われるかどうか、どの地域で処理されるかが違います。ライブラリのリスク情報が一般的な条件を前提にしていれば、自社の契約ではすでに手当てされているリスクが残っていたり、その逆が起きたりします。借りた情報は、自社の契約書と提供元のデータの扱いの文書で確かめてから確定させます。

確かめる担当も決めておきます。外部のモデルの契約は、情報システム部門や購買が持っていることが多い一方、使い方の持ち主は業務の部署です。契約の条件を確かめる人と、使い方のリスクを確定する人が別であることを前提に、両者の確認を経てからリスクを確定させる流れにします。

AIに下書きさせる範囲と、人が判定する範囲

Saidot は、リスク評価の下書きや、評価が古くなっているシステムの洗い出しを、エージェントに担わせる方向を打ち出しています。こうした下ごしらえをAIに任せるのは、台帳を回し続けるうえで有効です。ただし、AIにリスクの有無や段階を判断させてはいけません。判定は、自社の業務と契約を知っている人が持つべきものです。

線の引き方の目安は次のとおりです。AIに任せてよいのは、一覧からの候補の抽出、評価の下書き、期限切れの評価の洗い出し、変更があった統制の差分の提示です。人が持つのは、リスクを外すか足すかの判断、段階の確定、承認と停止の判断です。AIに下書きを作らせるときは、どのリスクや統制、どの文書を根拠にしたかを必ず書かせると決め、根拠のない下書きは採用しません。

管理の作業をエージェントで行うと、管理の基盤そのものが新しいエージェントの接続先になります。利用者のAIの道具を MCP で Saidot につなぐ場合は、そのつなぎ方自体を、手順4の道具ごとの審査の対象に含めることを忘れないでください。台帳を書き換えられる道具は、台帳の信頼性にかかわる道具です。

マーケ部門のAIとエージェントを載せるときの具体例

マーケ部門は、社内で最も多くのAIを使う部署の一つです。記事や広告の文言の下書き、画像の生成、問い合わせへの応答、顧客管理の仕組みからの抽出、広告の運用の補助など、使い方が多く、部署の中で誰がどのAIを使っているかを把握しきれていないことも珍しくありません。台帳に載せるときは、手順1の洗い出しをマーケ部門で一度丁寧に行う価値があります。

たとえば、顧客管理の仕組みからリードを抜き出してメールの文面を作り、配信の仕組みに予約するエージェントを考えます。手順4に沿って道具ごとに分けると、顧客管理の読み取りは個人データに触れるので中、配信の予約は社外に送る道具なので高になります。承認は、読み取りはマーケの責任者と情報システム部門、送信の道具は規程の責任者というように分け、送信の道具を外した状態で試すことから始めます。

広告の文言や画像の生成は、景品表示法や著作権の観点のリスクを、既製の一覧に足すことが多い領域です。既製の一覧は海外の規制を前提にしているため、国内の表示の規制や業界団体の自主基準は、自社で足す前提で考えます。マーケの担当者が台帳を見て、自分の使い方の統制が何かを自分の言葉で読める状態を目標にします。

社内に入れてよいか：データの流れ・権限・やめ方

Saidot に載せる情報は、社内のAIの使い方、接続している業務の道具、リスクの評価、事故の記録など、社内の弱点の一覧とも言える情報です。提供元は ISO の27001の認証を受けていると公表していますが、データをどの地域に保管するか、管理の作業を担うエージェントがどの外部のAIを使っているか、提供元の担当者がどこまで閲覧できるかは、今回確認した公開情報からは読み取れませんでした。導入前に書面で確かめる項目です。

権限の面では、Azure や Amazon Bedrock の開発基盤との連携で、エージェントの目録を自動で埋められると説明されています。自動の連携は便利ですが、連携に使う資格情報が、開発基盤のどこまでを読めるかを確かめておきます。台帳を埋めるための連携に、開発基盤の書き込みの権限を渡さないのが基本です。

やめ方も先に決めます。料金の案内ページでは、次回の支払いの前に解約できると案内されています。解約したときに困るのは、借りたライブラリの統制と、自社で写した規程の対応づけが基盤の中にしか残っていない状態です。写し直した統制と規程の条項の対応表は、基盤の外の自社の文書として持っておくと、基盤を替えても規程は残ります。台帳と評価の記録を書き出せる形式も、契約前に確かめておきます。

費用と、国内での調達の現実

費用については、今回確認した公式の料金の案内ページで、具体的な金額を確かめることはできませんでした。契約の段階はいつでも変更でき、付加価値税は所在地にもとづいて加算されると案内されています。見積は提供元への問い合わせが前提になり、比較の際は、台帳に載せるシステムやエージェントの数、利用者の数、使えるライブラリの範囲、連携の範囲が金額にどう効くかを確かめます。

国内での調達の経路は、現時点では限られます。国内の販売代理店や日本語での提供は今回の調査では見つからず、北欧の提携先も北欧の企業向けの支援をうたっています。Azure を使っている会社では、マーケットプレイス経由の調達が選択肢になります。画面と支援が英語であること、規程の写し直しは自社で行うことを前提に費用を見積もる必要があります。

費用に見合うかの判断材料は、規程と台帳を自社で作り、維持する人の時間です。既製の一覧から候補を選べることで、最初の一覧づくりの時間は減ります。一方で、手順3の写し直しと、提供元のライブラリの更新を追う作業は残ります。削れるのは候補を集める時間で、判断する時間は削れないと理解したうえで、比較します。

導入前に確かめる項目一覧

ここまでの論点を、導入の判断の前に確かめる項目としてまとめます。提供元に聞く項目と、社内で決める項目を分けて担当を割り振ってください。

• 社内のAIの使い方と、エージェントが触れる道具を、ライブラリを開く前に洗い出したか（社内）
• 使い方ごとに持ち主の部署を一つ決めたか（社内）
• 有効にする枠組みと、社内の正本にする規程を決めたか（規程の責任者）
• 既製の統制を国内の法令と社内規程の条項に写す担当と期限を決めたか（法務・情報システム部門）
• 道具ごとのリスクの段階と、段階ごとの承認者・停止できる人を決めたか（社内）
• データの保管地域、管理の作業を担うAIの外部事業者、提供元の閲覧範囲を書面で確かめたか（提供元）
• 開発基盤との連携に渡す権限が読み取りに限られているか（情報システム部門）
• ライブラリの更新をどう知らせ、変わった統制を誰が見直すか（提供元と社内）
• 解約時に台帳・評価・対応表を書き出せる形式を確かめたか（提供元）

このうち社内で決める項目は、Saidot を入れるかどうかにかかわらず必要です。先に社内の項目を決めておけば、基盤の比較は、その決まりをどれだけ楽に回せるかという一つの物差しで行えます。

ミニ用語解説

この記事で使った言葉のうち、社内で意味がずれやすいものを短く整理します。規程を作るときは、社内の用語集にもこの意味で載せておくと、部署ごとの解釈のずれを防げます。

• リスクのライブラリ：AIの利用で起こり得る問題を、種類ごとに整理した既製の一覧。候補の棚であり、自社のリスクの確定版ではない
• 統制：リスクを抑えるために行う決まりや手続き。規程の条項、確認の手順、技術的な制限などを含む
• 枠組み：規制や規格、指針のまとまり。どの枠組みを有効にするかで、持ち主に届く統制が変わる
• エージェントの目録：社内のエージェントを、目的・来歴・自律の度合い・触れられる道具とともに登録した一覧
• 道具ごとの審査：エージェント全体ではなく、接続する業務の道具ごとにリスクを判定し、承認する考え方

用語をそろえる作業は地味ですが、既製の一覧を借りるときほど効いてきます。海外の枠組みの言葉と社内の言葉の対応を一度決めておけば、ライブラリが更新されたときにも、どの社内の規程に影響するかをすぐに追えます。

まとめ

Saidot は、260を超えるリスクと600を超える統制の既製ライブラリ、AIの台帳、道具ごとにリスクを分けるエージェントの目録を一体で持つガバナンス基盤で、2026年も北欧での提携やエージェントによる管理の構想など更新が続いています。既製の一覧は候補の棚として強力ですが、自社の使い方を先に洗い出し、当てはまるリスクを選び、統制を国内法と社内規程の言葉に写し、エージェントは道具ごとに段階を付けて、段階ごとに承認者と停止できる人を決める作業は自社に残ります。AIには下書きと根拠を出させ、判定と承認は人の名前で残すこと、写し直した対応表を基盤の外に持つこと、データの扱いを書面で確かめることを前提に、導入を判断してください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。