組織でAIを運用するルールを作る

社内ガイドラインで、目的・情報・道具の条件を結ぶ

社内ガイドラインは、組織がAIをどのように仕事へ使うかを示すルールです。利用目的は、何の仕事のために使うかということです。承認済みツールは、組織が定めた用途や条件で使うことを認めた道具で、入力可能な情報は、その条件で渡してよい情報の範囲です。サービス名だけでなく、使うアカウント、情報、出力の渡し先などを結んで記します。

情報区分は、公開済み、社内に限る、機密性が高いなど、取扱いに応じて情報を分けることです。ツールのレベル分けは、各組織が用途や危険に応じて利用条件を整理する方法です。例えば「公開資料の下書きに使える道具」と「別の確認が必要な道具」を区別します。共通の色や数字にすればどの会社でも同じ許可になるのではなく、情報区分と目的に合う条件を具体化します。個々の利用可否の基本はGA402でも確認します。

確認・承認・日々の運用の役割を分けて結ぶ

業務側は解決したい目的や扱う情報、人への影響を示し、情報システムやセキュリティの担当は仕組みや接続、操作の権限などを確かめます。必要な法務・個人情報等の担当への相談も結びます。アクセス管理は、誰が何を見たり変更・送信したりできるかを管理することです。最終的に誰が条件を受け入れ、承認するかも組織で定め、確認を頼んだ相手と決定する役割を混ぜません。

申請・承認のフローは、新しい道具や使い方について、必要な情報を誰へ出し、何を確認して決めるかの流れです。申請には、目的、情報区分、データの流れ、費用、出力の使い方などを含めます。契約・料金だけを確認する担当や、試した一人だけに全てを任せず、現場と管理側が必要な条件を共有します。承認した後の利用担当、変更の確認先、相談先へも引き継ぎます。

使い始めた後の確認も、最初の設計へ含める

運用では、必要な利用記録の項目・保存期間・見られる人、費用を確かめる担当、事故や疑いを知らせる窓口、出力を使うときの確認などを定めます。記録を残すこと、費用を支払うこと、利用上の問題へ対応することは、別々の仕事です。担当が分かれていても、何を共有し、どこへ相談するかを結びます。

出力を保存するときは、どの版を、誰が見られる場所へ、いつまで残すかを決めます。一度確認した出力でも、用途や渡す相手を変えるなら、その変更を確認する担当と、改めて見る条件を決めておきます。例えば社内の問い合わせをまとめた文を取引先への資料に使うなら、業務の担当が内容・出典・版を照らし、情報管理の担当が外へ出せる範囲を確かめます。承認の範囲が社内用までなら配布を保留し、必要な確認を終え、組織で承認する役割の人が社外利用を認めてから使います。

教育や同意の記録は、ルールを知る機会や約束を確かめる材料になります。しかし受講したことだけで、業務目的や情報区分の条件を決めたことにはなりません。ルール、利用できる道具、権限、日々の確認、相談、見直しをつないで、実際に使える形にします。規則を書くだけで全ての誤りや事故を防げると考えず、利用状況や変化から改善します。

SLA、ISMS、SOC 2は、違うことを示す資料

SLAは、Service Level Agreementの略で、提供者と利用側の間で、サービスの水準や責任、対応などを取り決めるものです。稼働率は、対象の時間のうちサービスが動いている割合を示す指標で、対象や除外の条件は取決めで違います。応答までの時間や障害時の対応も、何をどの条件で約束するかを読みます。稼働率の約束を、AI出力の全ての正確さや、自社側の管理まで確認した証拠にはしません。

ISMSは、情報セキュリティを組織として管理する仕組みです。ISO/IEC 27001は、その仕組みへの要求事項を定める国際規格です。認証取得を確認する場合は、対象の組織・業務・サービスなどの範囲も見ます。ここでの認証は、管理の仕組みが基準に適合するかという確認で、利用者本人のログイン確認とは別の意味です。個々のAI出力が正しいことや、あらゆる事故が起きないことを保証する印ではありません。

SOC 2は、サービス組織の統制について、独立した監査人が検証・報告する枠組みです。統制は、目的に沿って活動を管理する仕組みや手続のことです。独立したCPA、つまり公認会計士の事務所による報告で、製品そのものの認証と同じには扱いません。対象システム、扱う領域、時点や期間、例外などを読みます。Type 1はある時点、Type 2は一定期間という違いにも注意します。

報告書には、利用組織が自ら行う管理を前提にする記載もあります。例えば、利用側のアカウント管理などが前提なら、実際に誰が手順を実施しているかを自社で確かめます。対象のシステムや期間が合っていても、その前提が自社で満たされた証拠にはなりません。SLA、提供元の認証、監査報告、自社側の実施を別の材料として結びます。

SSO・MFAと、操作してよい範囲を分ける

SSOはシングルサインオンの略で、一つのアカウントとその認証の仕組みで、複数のアプリを利用できるようにする方法です。本人認証は、利用しようとする人が本人かを確かめることです。MFA、多要素認証は、知っているもの、持っているもの、本人の特徴など、異なる種類の要素を組み合わせます。SSOは認証を連携する仕組み、MFAは認証要素の組合せで、同じ意味ではありません。

本人だと確認できたことと、その人が何をしてよいかは別です。閲覧、変更、削除、外部への送信などの操作権限は、業務の役割に合わせて管理します。異動や退職、契約の終了などで役割が変わったら、必要な権限も見直します。SSOやMFAがあることだけで、各アプリの操作権限が目的に合ったものになるわけではありません。

閉域・オンプレミス・ローカルは、配置や接続の条件

閉域網は、特定の拠点や限られた利用者などに接続を絞ったネットワークです。オンプレミスは、組織の設備でハードウェアやソフトウェアなどを配置し管理する形です。閉域網は接続範囲、オンプレミスは設備の配置・管理に着目する語です。どちらも、その名前だけで利用者の権限や運用、出力の正確さまで決めるものではありません。

ローカルLLMは、大規模言語モデルを手元の機器などで動かす使い方です。モデルの推論を手元で行うことと、そのアプリや周辺の仕組みが一切外部通信しないことは分けます。外部検索、追加機能、記録の送信、更新やバックアップなど、構成と設定を実際に確認します。機器やモデル、データの更新・保護も管理する必要があります。

例えば、保存は自社の機器でも、外部のAPIへ推論を頼む構成があります。反対に、推論は手元で行い、結果を社外の保存先へ置く構成も考えられます。何を社内で行う条件なのかを先に決め、必要な文書や設定の説明で、各工程を照合します。配置や認証の一つの条件で、法令・契約・情報管理などの別の条件まで済ませません。

レート制限は、一定時間の利用量を抑えるもの

レート制限は、一定の時間内に許す要求の回数や量などを制限することです。何を数え、どの時間枠や利用者に制限を掛けるかはサービスによって違います。例えば毎分の呼出し回数の制限は、呼出しの速さを抑える条件です。1時間や1か月の累積利用量、使った金額の上限とは、そのまま同じになりません。

従量料金は、利用した回数や量などに応じて生じる料金です。コスト管理では、単価、数える量、再試行や継続実行、累積の期間を確認します。AIエージェントのように繰り返し道具を呼ぶ仕組みなら、1件の依頼から複数回の利用が生じる場合もあります。予算の警告と実際の停止は区別し、停止する条件や担当、反映のタイミングも確認します。レート制限や予算という名前だけで、支出の上限を保証しません。

利用ログとモニタリングは、目的に必要な範囲で行う

利用ログは、誰やどの仕組みが、いつ、何を利用したかなどの記録です。モニタリングは、利用や不具合、費用、ルールの実施状況などを継続して観察することです。調査や見直しの目的に必要な項目を選び、利用者・道具・版、処理の識別、失敗や利用量、確認した結果などを結びます。個々の出力を評価する作業と、組織の運用状況を観察する仕事を分けてつなぎます。

記録には個人情報や秘密、認証情報が混ざる危険もあります。全入力原文やAPIキーを無差別に残したり、全員へ公開したりする方法を前提にしません。記録する内容、保存期間、閲覧・変更できる担当、削除や保全の扱いを決めます。元情報を管理番号でたどる方法や、必要な部分だけを残す方法も検討します。後から検証できることと、情報を広く公開することは同じではありません。

インシデントの連絡と対応を、役割へ結ぶ

インシデントは、運用や安全に影響する事故や、そのおそれのある出来事です。組織は、疑いを知らせる窓口、影響を調べる担当、共有制限やキーの停止などを実施できる担当、提供者や関係者へ連絡する担当を、手順と権限に結びます。対応のために必要な記録も、安全に使えるよう準備します。発見した人が気づいても、担当へ届かなければ対応が遅れることがあります。

例えば、不要な旧キーが残ったときは、誰がどの処理への影響を確認し、切替や失効を行い、何を記録するかを決めておきます。単に「何かあれば止める」と書くのでなく、範囲と担当を具体化します。情報の事故での個人の初動や法定報告条件の詳細はGA404へ戻し、ここでは組織の連絡・対応を用意する役割を押さえます。

新版を示し、旧版が残る経路も整理する

ルールの改定では、使う版、適用する範囲や時期、何が変わったか、問い合わせ先を示します。共有場所の最新版だけでなく、印刷物や手順書、よく参照する案内にも旧い説明が残っていないかを確かめます。記録として旧版を保つことと、今使う手順として案内することは分けます。

変更点を伝えた後は、短い事例で使い分けを確認したり、現場の質問を受けたりします。迷いが多い項目には説明を足す、参照先を分かりやすくするなど、教育と運用の両方を直します。担当者が好きな版を選ぶ状態や、受講時間だけを理解の証拠にする状態を、そのまま定着したとはしません。

定期点検に加え、条件の変化を見直しの契機にする

運用中には、道具の機能、処理の委託先、データの保存条件、利用目的や規模などが変わります。定期点検の予定は役立ちますが、重要な変化が分かったときは、次の予定日を待つだけでなく、関係する担当が影響を評価します。事故がまだ報告されていないことだけでは、新しい条件がこれまでの利用に合うと確認したことにはなりません。

変更通知を受けたら、自社の目的・情報・契約・権限・記録などとの関係を調べ、必要に応じて条件の再確認、利用範囲の調整、ルールや教育の更新へ結びます。提供元が変更したことを、自社の利用目的や情報区分が自動的に広がった意味にはしません。利用を決める側と運用を確認する側が、同じ変更情報を共有します。

アジャイル・ガバナンスで、評価と改善を繰り返す

アジャイル・ガバナンスは、環境やリスクの変化を捉え、目標や管理の仕組みを柔軟・継続的に見直す考え方です。アジャイルは、変化へ柔軟に対応するという意味です。目的とリスクを考える、仕組みを作る、運用する、実際の利用や失敗・質問を観察する、評価して改善する、という循環をつなぎます。確認せず頻繁にルールを変えることではありません。

例えば、同じ問い合わせが繰り返されるなら、利用者の注意不足と決める前に、ルールの表現や相談の経路、道具の設定、教育の内容も見直します。個々の出力の点検はGA410で扱い、その結果も運用を改善する材料へ結びます。組織の目的、担当、利用する人に戻りながら、ルールを実際に使い続けられるものへ整えます。