UN AIガバナンス議論から考える、AI利用規程は社内文書ではなく取引先説明資料になる

先に結論：AI利用規程は「社内向けの禁止事項集」から「取引先に見せる説明資料」へ性質が変わった

これまでAI利用規程は、社員に「機密情報を入れるな」「勝手に使うな」と伝える社内文書でした。しかし2026年に入ってから、大企業や海外取引先が発注先・委託先に対して「どのAIを、何の業務に、どのデータで使っているか」を書面で確認するようになり、規程は取引を続けるために外部へ提示する資料へと役割を変えています。

そしてこの変化には裏側があります。あなたが取引先へ「当社は問題なくAIを使っています」と胸を張って答えるには、まず自社が使っているAIベンダーから同じ水準の開示を取っておかなければなりません。取引先の質問は、元をたどればあなたのベンダーの挙動を問うているからです。この記事は、その両方向、つまり「取引先に説明できる状態」を作ることと、「ベンダーに開示させ契約に書く」ことを、中小企業の調達実務に落として解説します。

この記事は、経営者・管理部門・法務・情シス、そして海外取引や大企業取引がある中小企業の担当者が、自社のAI利用規程を「聞かれたときに出せる状態」まで整えるための実務ガイドです。UNのAIガバナンス議論そのものを解説するのが目的ではなく、その議論が調達現場のチェックシートに降りてくる前に、何を棚卸しし、どこまで自社で決め、どこから外部に相談すべきかを判断できるようにします。まず現状の業務・データ・権限・運用責任・費用感を1枚に並べたいという段階であれば、AIベンダーへの開示要求と契約条項を発注前に確認するから着手できます。

この記事が役に立つ会社

• 大企業や上場企業を取引先に持ち、セキュリティチェックシートや調達アンケートへの回答を求められる中小企業
• 海外取引があり、取引先から英文のデータ取り扱い確認やAI利用状況の説明を求められる会社
• 生成AIツールやAIを組み込んだシステムをベンダーから導入しようとしているが、何を開示させればよいか分からない会社
• 生成AIを現場が使い始めているが、社内規程が「禁止」だけで運用実態と合っていない会社
• 情シスが1人または兼任で、規程・台帳・FAQ・ベンダー確認まで手が回っていない会社

この記事の根拠と最新性

次の公的資料・一次情報を2026年7月10日時点で確認しました。国際議論は各国の合意状況や表現が変わりやすいため、法制度・価格・罰則・攻撃成立条件は公開前に再確認する前提で扱います。

• ITU（国際電気通信連合、UN専門機関）AI for Good Global Commission発足（2026年7月2日発表・一次情報）: https://www.itu.int/en/mediacentre/Pages/PR-2026-07-02-AI-for-Good-Global-Commission.aspx
• Axios UN AI commission 報道（二次報道）: https://www.axios.com/2026/07/01/un-ai-commission-ceos-world-leaders
• NIST AI RMF（2023年1月公開・Govern/Map/Measure/Manage）: https://www.nist.gov/itl/ai-risk-management-framework
• OWASP GenAI Security Project（Top 10 for LLM Applications）: https://genai.owasp.org/
• 経済産業省・総務省 AI事業者ガイドライン（第1.2版・2026年3月31日）: https://www.meti.go.jp/policy/it_policy/ai_guideline/
• 個人情報保護委員会: https://www.ppc.go.jp/personalinfo/

AI for Good Global Commissionは2026年7月にITU・ルワンダ・Salesforceの共同座長のもとで発足し、各国首脳やAI企業経営者が参加する国際的な議論の場として動き出しました。ただし、国際機関やコミッションの提言は、それ自体が日本国内の法的義務を直ちに生むものではありません。義務の根拠は個人情報保護法や各種業法、契約条項にあり、国際議論はあくまで「取引先や監査が何を気にし始めるか」を先読みするための材料として扱うのが安全です。

国際議論を、中小企業が答えるべき「調達の問い」に翻訳する

UNのAI for Good Global Commissionのような場での議論は、抽象的な原則（透明性・説明責任・人間による監督・データ保護）が中心です。これを法的義務として断定するのは危険ですが、原則は必ず調達側の質問文へと具体化されて降りてきます。中小企業にとって重要なのは、原則の是非を論じることではなく、原則が「取引先からの質問」に変換されたとき自社が答えられるかどうかです。

たとえば「透明性」という原則は、調達現場では「あなたの会社が当社の業務で使っているAIツール名と用途を列挙してください」という質問になります。「データ保護」は「当社から預かったデータを生成AIの入力に使っていないことを証明できますか」になります。「人間による監督」は「AIの出力をそのまま顧客へ送っていませんか、確認者は誰ですか」になります。この変換を先に想定しておくと、規程を作る目的が「社員を縛る」から「外部の問いに一枚で答える」へと明確になります。

原則を実務の問いへ変換する際に、次の観点を自社で埋められるか確認してください。

• 対象業務と、そのAIを実際に触る担当・部署を具体化しているか
• AIが扱うデータを、公開情報・社内情報・顧客情報・個人情報・営業秘密に分類しているか
• 読み取り・書き込み・送信・削除・外部共有の権限を業務ごとに分けているか
• 人間が承認してから実行すべき操作（顧客への送信、DB更新、外部システム操作）を決めているか
• ログ・判断根拠・確認者・例外処理の記録を残せる仕組みがあるか
• 費用上限・利用停止条件・復旧手順を定義しているか
• 取引先へ提出する回答と、社内規程・AI台帳が同じ内容を指しているか

取引先・調達から実際に聞かれる7つの質問

セキュリティチェックシートや調達アンケートの設問は会社ごとに違いますが、生成AIに関して問われる論点は概ね次の7つに収束します。回答テンプレートを事前に用意しておくと、案件ごとに一から作る手間がなくなり、部署によって回答がぶれる事故も防げます。

1. どの生成AI・AIサービスを、どの業務で使っているか（サービス名・提供元・用途）
2. 当社（取引先）から預かったデータを、AIの入力・学習に使っていないか
3. 個人情報・機密情報をAIに入力する際のマスキング・匿名化の運用はあるか
4. AIの利用に再委託先・クラウド事業者が関与するか、その所在国はどこか
5. AIの出力を人間が確認する工程はあるか、確認者と承認フローはどうなっているか
6. 利用ログ・監査証跡を保存しているか、保存期間はどれくらいか
7. 社員へのAI利用教育・規程周知を行っているか、違反時の対応はどうか

これらに「わかりません」「担当に確認します」と返している間に、より整備された競合へ発注が流れることがあります。逆に、7項目に即答できる会社は、それ自体が発注先としての信頼材料になります。規程・台帳・FAQを一体で整えておく実務上の理由はここにあります。

立場が逆になる：あなたがベンダーに開示を求める側

ここまでは「取引先から自社が開示を求められる」側の話でした。しかし同じ開示の論理は、あなたが生成AIツールやAIを組み込んだシステムをベンダーから調達するとき、そっくり裏返しで効いてきます。

上の7つの質問のうち、2番（預かったデータを学習に使っていないか）に「使っていません」と答えるためには、あなたが使うAIベンダーが実際にデータを学習に使わない設定になっている必要があります。4番（再委託先・所在国）に答えるには、ベンダーの再委託構造を知っている必要があります。つまり取引先への回答の正しさは、あなたがベンダーから取った開示の質にそのまま依存しています。自社が説明責任を負う一方で、実際の挙動を握っているのはベンダーだからです。ここから先は、あなたが発注者・調達側に立ったとき、ベンダーに何を開示させ、何を契約に書くかを具体化します。

AIベンダーが聞かれないと言わない6つのこと

AIベンダーやSaaS提供元の多くは、聞かれない限り自分から不利な条件を説明しません。悪意があるからではなく、営業資料は導入メリットを伝えるために作られており、データの扱いや停止条件は規約や別紙に小さく書かれているのが普通だからです。次の6点は、提案書や商談では出てこないのに、後で取引先対応や事故対応の分かれ目になります。

• 入力データの学習利用：あなたが入力したデータを、モデルの学習・改善に使うのか。使わない設定があるのか、それは契約プランに含まれるのか、既定でオンになっていないか。
• 保管場所と保管期間：入力・出力・ログがどの国のどのクラウドに、どれだけの期間保存されるのか。削除依頼に応じるのか、応じるとして何日で消えるのか。
• 再委託先：ベンダーがさらに別のAI基盤（海外のモデル提供元やクラウド）に処理を委託していないか。その一覧と所在国は開示されるのか。
• モデルの変更：使われるモデルのバージョンが予告なく差し替わらないか。品質や挙動が変わったとき通知はあるのか。
• 停止・終了の告知期間：サービス終了や機能廃止のとき、何日前に告知されるのか。移行やデータ持ち出しの猶予はあるのか。
• 事故時の通知：情報漏えいやモデルの誤作動が起きたとき、誰に・何時間以内に・どの範囲まで通知されるのか。

なぜ聞かないと出てこないのか。これらはベンダーにとって「約束すると自社が縛られる」項目だからです。曖昧にしておけば運用の自由度が上がります。だから発注側が明示的に質問し、答えを書面に残さない限り、実質「何も約束されていない」状態のまま本番に入ってしまいます。OWASPのGenAI向けリスク整理（Top 10 for LLM Applications）でも、データ漏えいやサプライチェーン（再委託・基盤依存）はアプリケーション側で管理すべき論点として挙がっており、ベンダー任せにできない領域だと分かります。

そのまま送れる開示質問文と、返答の読み方

以下は、ベンダーへメールやチェックシートでそのまま送れる質問文の例です。「できますか」ではなく「どの条件で、どの書面に書かれているか」まで踏み込むのがコツです。

1. 当社が入力したデータおよびその出力を、貴社または第三者のモデルの学習・改善に利用しますか。利用しない設定がある場合、その設定名と、当社の契約プランで有効かどうかをご教示ください。
2. 入力データ・出力・ログの保存先（国・クラウド事業者名）と保存期間、および当社からの削除依頼に応じる場合の完了までの日数を教えてください。
3. 本サービスの処理に関与する再委託先・外部AI基盤の一覧と、その所在国を開示いただけますか。
4. 提供モデルのバージョン変更や機能廃止の際、事前告知の有無と告知日数を教えてください。
5. 情報漏えい・重大な誤作動が発生した場合、当社への通知の時限（何時間以内か）と、通知に含まれる情報の範囲を教えてください。
6. 上記の各項目は、利用規約・DPA（データ処理契約）・SLAのいずれの書面に記載されていますか。該当箇所をご提示ください。

返ってきた答えは、言葉そのものより「書面のどこに書いてあるか」で読みます。

• 「善処します」「柔軟に対応します」：契約上の義務ではなく、担当者の心づもりです。書面に条項がなければ、担当が代わった時点で消えます。
• 「検討中です」「ロードマップにあります」：現時点では提供されていない、と読むのが安全です。導入時期を契約条件にできない機能は、無いものとして設計します。
• 「規約に記載の通りです」：規約の該当条項番号を必ず出させます。番号を出せない場合、その項目は実在しない可能性があります。
• 即座に条項番号・DPA・SLAを提示してくる：これは良い兆候です。開示に慣れているベンダーは、取引先監査を通した実績があることが多いです。

ベンダーからの回答や提案書を発注前に第三者の目で読み解きたい場合は、他社見積・提案書レビューのように、契約前に前提条件・責任分界を洗い出す方法もあります。

開示を契約条項に落とす（中小企業が現実に飲ませられる範囲）

開示を口頭やメールで得ても、契約に書かなければ取引先への説明材料にはなりません。とはいえ中小企業が大手AIベンダーの標準規約を全面的に書き換えさせるのは現実的ではありません。飲ませられる条項と、標準規約や第三者認証の確認で足りる条項を分けて考えます。

すべてを勝ち取ろうとすると交渉が止まります。取引継続に直結する「データ利用（学習に使わない）」と「解約時の返却／削除」を最優先で書面化し、監査権のように取りにくい項目は第三者認証の提示で代替する、という優先順位づけが実務的です。どの条項が自社の契約に抜けているかを事前に洗い出しておくと、ベンダーとの交渉が金額の話に流れず、責任範囲の話に戻せます。

開示が得られないベンダーをどう評価するか

開示を求めても十分な回答が返ってこないベンダーを、その場で失格にする必要はありません。特に小規模なベンダーや新しいサービスでは、書面が整っていないだけで、実態は誠実なこともあります。判断のポイントは「開示できないのか、開示の仕組みがまだ無いだけなのか」を切り分けることです。

• 開示できない兆候：質問をはぐらかす、規約以外の確認を拒む、条項番号を出せない。取引先対応でも同じ壁に当たるため慎重に扱います。
• 仕組みが無いだけの兆候：正直に「まだ書面化していないが確認して回答する」と応じ、期限内に埋めてくる。この場合は継続検討の余地があります。

即失格にしない代わりに、次を確認します。

• 第三者認証（ISMS/SOC2）や、親会社・基盤提供元（利用しているモデル提供元やクラウド）のセキュリティ方針
• 既存顧客での取引先監査対応の実績があるか
• 非機密データやPoCの狭い範囲から始め、開示が書面で揃うまで機密データを渡さない段階導入ができるか

開示が弱いベンダーを使う場合は、渡すデータを非機密に限定し、機密データは開示が揃ってから、という順序で自社側のリスクを下げられます。ベンダーの「誠実さ」は主観になりがちですが、「書面を出せるか」「段階導入に応じるか」は客観的に測れます。

調達の順番は「要件→開示→金額」

調達でよくある失敗は、最初に相見積もりで金額を並べてしまうことです。金額から入ると、安いベンダーに要件と開示を後付けで合わせにいくことになり、開示の甘さを「安いから仕方ない」と飲み込みやすくなります。順番を「要件→開示→金額」にすると、この歪みを避けられます。

1. 要件：何の業務を、どのデータで、どの権限でAIに任せるかを自社で先に固める（後述の棚卸し）。
2. 開示：固めた要件を各ベンダーに同じ質問文で投げ、開示の質で候補を絞る。
3. 金額：開示水準がそろった候補同士で、初期・従量・保守・解約費用を比較する。

金額を最後に回すと、「開示できるが少し高いベンダー」と「安いが開示が曖昧なベンダー」を同じ土俵で比べずに済みます。取引先対応のリスクを負うのは発注したあなたであって、ベンダーではありません。金額差の数十万円と、取引先を失う損失を並べれば、どちらを優先すべきかは明確です。生成AIの社内利用そのものの統制設計は生成AI社内ガバナンスの整備、導入可否そのものの見極めはAI導入可否アセスメントのように、外部の型を使って要件を先に固める方法もあります。

経営者が見るべき判断軸

AI利用規程やAI台帳の整備、そしてベンダー開示の取り付けを、単なるIT投資や情シスの雑務として見ると優先順位が上がりません。経営判断としては、次の4つの軸で「どの業務のAI利用から先に整えるか」を決めると投資対効果が読みやすくなります。同じAI導入でも、営業提案の下書き支援と、顧客データを扱う自動応答と、社内ナレッジ検索と、外部システムの自動操作では、事故が起きたときの損失の大きさがまったく違うためです。

売上を守るための整備なのか、事故を避けるための整備なのかを言語化すると、規程の粒度も、かける費用も、社内説明の文脈も変わってきます。

現場責任者が最初に棚卸しするもの

現場責任者は、製品名を先に決めず、対象業務を1つずつ洗い出して棚卸しします。ここで最も重要なのは、そのAIが「読むだけ」なのか、「書く」のか、「送る」のか、「削除する」のか、「外部システムを操作する」のかを分けることです。読むだけの検索補助AIと、顧客へメールを送信するAIと、基幹DBを更新するAIを同じリスク階層で扱うと、規制が過剰になって現場が使えなくなるか、逆に統制が甘くなって事故が起きます。

• 対象業務を、調査・要約・作成・確認・送信・更新・削除・外部連携に分ける
• 扱う情報を、顧客情報・個人情報・営業秘密・契約情報・資格情報・ソースコードに分類する
• AIに渡してよい情報、マスキングが必要な情報、絶対に渡してはいけない情報を線引きする
• 失敗した時に、誰が止め、誰が復旧し、誰が取引先へ説明するかを事前に決める
• 1カ月後に見る指標を、工数・品質・事故未遂・費用・問い合わせ件数で決めておく

この棚卸しの結果がそのままAI台帳になり、取引先へ提出する説明資料の裏付けになります。台帳と規程と回答テンプレートが同じ棚卸しから生成されていれば、内容が矛盾せず、更新も一度で済みます。棚卸しの分類軸はNIST AI RMFのGovern/Map/Measure/Manage（統治・把握・測定・管理）とも整合し、「まず自社のAI利用を把握する（Map）」段階を飛ばさないことが後段の統制を軽くします。

発注者がRFP・見積依頼に入れるべき質問

AI利用規程の整備や、AIを組み込んだシステム開発を外部に依頼する場合、ベンダーへの質問は「できますか」では不十分です。「どの前提ならできるのか」「どのデータは扱えないのか」「どの操作を人間承認にするのか」「どのログを残すのか」「費用が増えたときにどう止めるのか」まで聞くと、見積金額の差ではなく、責任範囲と運用思想の差が見えてきます。

見栄えのよい提案書よりも、前提条件・制約条件・監査証跡・運用体制の記述量を重視してください。制約を正直に書くベンダーほど、本番運用で信頼できることが多いです。

よくある誤解

最後に、調達の現場で繰り返し見かける誤解を挙げます。どれも一見もっともらしいだけに、開示を省く言い訳になりがちです。

• 「大手なら安心」：大手ほど標準規約が発注側に不利なこともあり、規模と開示の丁寧さは別問題です。大手でも既定で学習利用がオンのサービスはあります。確認すべきは会社の大きさではなく、プランの設定と書面です。
• 「規約に書いてあるから読まなくていい」：書いてあることと、あなたに有利であることは別です。規約はベンダーを守るために書かれています。読まずに同意した条項が、そのままあなたの取引先への説明責任になります。
• 「無料版と有料版は同じ扱い」：無料・試用版は学習利用や保存の条件が有料版と異なることが多く、現場が無料版に機密データを入れる事故が典型です。プランごとに条件が違う前提で確認します。
• 「開示を求めると嫌われて発注できない」：逆です。開示にきちんと答えるベンダーは取引先監査に慣れており、質問を歓迎します。質問を嫌がるベンダーこそ、本番で問題が起きたときに困る相手です。

よくある失敗パターンと回避策

AI利用規程やベンダー調達まわりの失敗の多くは、技術力ではなく「導入前の問いの浅さ」から起きます。代表的なパターンは3つです。

第一に、現場が便利な使い方を先に見つけ、管理部門が後から禁止事項を積み増し、結果として「申請すると遅いから黙って使う」隠れ利用が増えるパターンです。禁止から入ると必ずこうなります。用途を分類し、リスクの低い業務は承認を軽く、高い業務だけ厳格にする設計にしないと守られません。

第二に、ベンダー提案をそのまま受け入れ、社内の責任者・データ分類・運用ログを決めないまま本番化するパターンです。動くものは早くできますが、取引先から質問が来た瞬間に答えられず、信用を失います。

第三に、初期費用だけで判断し、API従量費用・レビュー工数・保守費用・教育費用・事故対応・契約更新のコストを見ないパターンです。導入後半年で費用が想定の数倍になり、止めるに止められなくなります。

回避策は次の通りです。

• PoCを始める前に、使うAIの学習利用・保管先・停止条件をベンダーに書面で開示させ、成功条件を「動いたか」だけでなく「開示内容を取引先へ説明できる水準か」まで含めて判定する
• 本番化の前に、利用規程・AI台帳・承認フロー・ログ・教育・問い合わせ窓口をそろえる
• 契約書に、前述の6条項（データ利用・成果物責任・脆弱性対応・保守・解約時の返却/削除・監査協力）のうち自社で取れる範囲を落とし、口頭の「善処します」は条項化しない限り無いものとして扱う
• 導入後30日で、使われた業務・使われなかった業務・事故未遂・費用・改善要望を棚卸しする
• 90日後に、継続・縮小・拡張・別方式への切り替えを判断する

90日で「聞かれても答えられる状態」に持っていく運用計画

規程は作って終わりではなく、運用と更新が続いてはじめて取引先への説明に耐えます。いきなり全社導入や大規模開発から始めるのではなく、次の90日に区切ると、費用感と進め方を見通しながら整備できます。

月次更新を仕組みにしておくことが特に重要です。使うAIサービスも、取引先の質問も、法制度も、ベンダーの規約も変わります。「最終更新日」が古い規程は、それだけで取引先の不信を招きます。

発注前チェックリスト

外部にAI利用規程の整備やAIシステム開発を相談する前に、次を自社で埋められるか確認してください。埋められない項目が、そのまま要件定義とベンダー開示要求で詰めるべき論点になります。

• 対象業務と、それを実際に触る担当・部署を具体化しているか
• AI・システムが扱うデータの種類を分類しているか
• 読み取り・書き込み・送信・削除・外部共有の権限を分けているか
• 人間が承認すべき操作を決めているか
• ログ・判断根拠・確認者・例外処理を残せるか
• 費用が想定を超えたときの上限額・課金を止める連絡先・障害時の復旧責任を、契約書のどの条項で誰が負うか確認しているか
• 使うベンダーへ、学習利用・保管先・再委託先・解約時削除を書面で確認しているか
• 候補会社へ同じ形式で回答させるRFPになっているか
• 規程・AI台帳・取引先向け回答が、同じ内容を指しているか

これらに答えられる会社は導入可否の判断が速くなります。答えられない会社は、ツール選定の前に要件定義とベンダー開示要求から着手したほうが、結果的に手戻りが減ります。

よくある質問（FAQ）

Q. 国際機関の議論は日本の中小企業に法的義務を課すのですか。 A. 直ちに義務を課すものではありません。国内での義務の根拠は個人情報保護法・各種業法・取引契約にあります。国際議論は「取引先や監査が近い将来何を確認し始めるか」を先読みする材料として扱うのが安全です。

Q. 生成AIを使っていなければ規程は不要ですか。 A. 現場が個人アカウントで無断利用しているケースが多く、「使っていないつもり」が最も危険です。まず利用実態の棚卸しから始め、使っていないなら「使わない・使う場合の申請ルート」を明記しておくことが、取引先への回答としても有効です。

Q. 規程・台帳・FAQは何から作ればよいですか。 A. 順番はAI台帳（利用実態の棚卸し）が先です。台帳がないまま規程を書くと現場と乖離します。台帳→規程→取引先向けFAQ・回答テンプレートの順で作ると、内容が矛盾しません。

Q. ベンダーが「学習には使いません」と口頭で言えば十分ですか。 A. 不十分です。口頭やメールの約束は担当交代で消えます。学習利用の可否は、契約書・発注書・DPAのいずれかに条項番号付きで残してください。取引先から証明を求められたとき、示せるのは書面だけです。

Q. 大手のAIサービスなら開示確認は不要ですか。 A. 規模と開示条件は無関係です。大手でも既定で入力データを学習に使う設定のサービスがあり、無料・試用版では条件がさらに緩いことがあります。会社の大きさではなく、プランごとの設定と書面を確認してください。

Q. 開示を求めたらベンダーに嫌がられませんか。 A. 取引先監査に慣れたベンダーはむしろ歓迎し、条項番号やDPAを即座に示します。質問をはぐらかすベンダーの方が、本番で事故が起きたときに困る相手です。開示要求は関係を悪くするのではなく、相手の成熟度を測る材料になります。

Q. どこまで契約に書かせれば十分ですか。 A. すべてを勝ち取る必要はありません。取引継続に直結する「学習に使わない」と「解約時の削除」を最優先で書面化し、現地監査権のように取りにくい項目は第三者認証（ISMS/SOC2）の提示で代替する、という優先順位が現実的です。

Q. 情シスが兼任で1人しかいません。 A. 完璧な文書を一度に作ろうとせず、リスクの高い業務（顧客データを扱う・外部へ送信する・DBを更新する）から統制するのが現実的です。低リスク業務まで同じ厳格さで縛ると運用が破綻します。整備の設計だけ外部に依頼し、運用は社内で回す分担も選べます。

まとめ：規程は「導入を遅らせる書類」ではなく「取引を続けるための説明資料」

AI利用規程を社内向けの禁止事項集のままにしておくと、大企業・海外取引先からの確認に答えられず、整備された競合に発注が流れます。逆に、利用実態を棚卸しし、台帳・規程・回答テンプレートを一体で整え、さらに使っているベンダーから同じ水準の開示を書面で取っておけば、チェックシートへの即答そのものが受注の信頼材料になります。

自社で整理を始めるなら、まず業務・データ・権限・費用・承認・ログ・契約条件を1枚に並べ、そこに「各ベンダーの開示状況」の列を足してください。その表が作れない場合は、AI導入そのものより先に、要件定義・規程整備・ベンダー開示要求の設計を受ける価値があります。

あわせて読みたい記事

• 情報漏えい社内ルールを見積依頼する前に整理する要件・費用・運用条件
• 情報漏えい社内ルール作成RFPに入れるべき要件・評価軸・契約条件
• 生成AIの社内導入ガバナンス｜利用ルール・規程の作り方
• 生成AI社内ガバナンスの整備
• AI導入可否アセスメント
• 他社見積・提案書レビュー

AIベンダーへの開示要求と契約条項を発注前に確認する

参考・出典（確認日：2026年7月10日）

• ITU（国際電気通信連合）: Global leaders launch AI for Good Global Commission（2026年7月2日・一次情報） https://www.itu.int/en/mediacentre/Pages/PR-2026-07-02-AI-for-Good-Global-Commission.aspx
• Axios: UN launches AI commission with AI CEOs, world leaders（二次報道） https://www.axios.com/2026/07/01/un-ai-commission-ceos-world-leaders
• NIST: AI Risk Management Framework（2023年1月公開） https://www.nist.gov/itl/ai-risk-management-framework
• OWASP GenAI Security Project（Top 10 for LLM Applications） https://genai.owasp.org/
• 経済産業省・総務省: AI事業者ガイドライン（第1.2版・2026年3月31日） https://www.meti.go.jp/policy/it_policy/ai_guideline/
• 個人情報保護委員会: 個人情報保護法・ガイドライン https://www.ppc.go.jp/personalinfo/