生成AI利用規程2026｜タイ拠点で本社版が効かない4つの穴

日本本社が作った生成AI利用規程が、タイの拠点に降りてきた。開くと禁止事項が並んでいる。ところが現地で最初に出る質問は「では何をしてよいのか」である。本記事は、規程が守るのはツールの可否ではなく、データが社外へ出る経路とAI出力の検収責任の2つだという立場で、本社版に開く4つの穴を塞いでいく。

生成AI利用規程が「配って終わり」になる理由

規程を配ったのに現場が変わらない、という相談が増えている。原因は文章の巧拙ではなく、何を守る文書なのかが決まらないまま禁止事項の一覧として書き出されてしまうことにある。禁止事項の一覧は、書いた側には網羅的に見えるが、読む側には「自分の作業がどれに当たるか」を判断できない文書である。判断できない文書は、読まれた瞬間に運用から外れる。

課題の順位が示している逆転

帝国データバンクが2026年3月17日から3月31日に実施した「生成AIに関する企業の動向調査」では、全国23,349社に調査票を送り、10,312社から有効回答を得ている（回答率44.2%）。生成AIを「活用している」と答えた企業は34.5%で、内訳は「非常に活用している」4.4%、「やや活用している」30.2%。規模別では大企業46.5%、中小企業32.4%、小規模企業28.0%だった。

注目したいのは活用率そのものではなく、企業が挙げた課題の順位である。

情報漏洩のリスクを課題に挙げた企業が33.5%あるのに対し、トラブル時の責任所在などのルール整備を挙げた企業は25.5%にとどまる。順番が逆になっている、というのが本記事の出発点である。情報漏洩は技術的な統制でかなりの部分を塞げるが、責任の所在は技術では一切塞げないからだ。学習利用をオフにする設定も、テナントを分ける構成も、「入力したデータがどこへ行くか」には効く。しかし「AIが出した数字を誰が確かめて業務に採用したのか」は設定画面のどこにも存在しない。ここを決めるのは規程だけである。

方針だけが先に進んでいる

総務省「令和7年版 情報通信白書」に掲載された「最新の情報通信技術の進展に関する調査」（2025年実施）では、生成AIの利用方針を「積極的に活用する方針」とした日本企業は2024年度で49.7%だった。2023年度の42.7%から1年で7ポイント上がっている。半数近くが積極活用を掲げているというのは、裏を返せば方針の宣言が運用の設計より先に走っているということでもある。

問題は、方針と運用の間を埋める文書が禁止事項の一覧として書かれることだ。積極的に活用すると宣言した会社が、現場に配る文書では「これをするな」だけを並べる。海外拠点では、この落差が言語の壁を挟んでさらに拡大する。

規程が本当に守るもの

規程が守るべき対象は2つに絞れる。ひとつは、データが社外へ出る経路。どの分類のデータが、どの経路を通って、どこまで出てよいのか。入口の設計であり、事故の前に効く。もうひとつは、AIの出力が業務に採用されるときの責任の所在。誰が確認し、誰の名前で外に出て、間違っていたときにどの記録を辿るのか。出口の設計であり、事故の後に効く。

ツールの可否は、この2つから導かれる結果にすぎない。ところが多くの規程はツールの可否を主語にして書かれている。主語が結果になっているので、新しいツールが出るたびに改訂が必要になり、改訂が追いつかない期間はすべて空白になる。導入そのものの進め方は生成AI導入の進め方をまとめた記事で扱っているので、本記事は導入した後に何が会社を守るのかに絞る。

本社版の規程がタイ拠点で効かない4つの穴

日本本社の規程は、日本の法令を前提に、日本語で読む社員に向けて、日本本社が管理するIT環境の上で書かれている。この3つの前提が、タイ拠点では3つとも崩れる。

崩れた結果として開く穴を先に一覧で示す。以降の章はこの4つを順に扱う。

この4つは独立した欠陥ではない。規程が「本社の環境で、本社の言語で、本社の法令の下で、本社が知っているツールを使う人」を読者に想定している、という共通の原因から派生している。海外拠点はこの想定すべてから外れるので、4か所同時に穴が開く。

穴は「守っても足りない規程」を作る

誤解されやすいので先に書く。4つの穴は、現地スタッフが規程を破るという話ではない。規程を完全に守っていても会社が守られない、という話である。

本社版に「無料版の生成AIの業務利用を禁止する」とあり、現地スタッフが忠実に守ったとする。その人は代わりにブラウザの翻訳拡張機能で社内の見積書を訳すかもしれない。規程に翻訳拡張機能のことは書かれていないので違反ではない。しかしデータは社外へ出ている。これが③経路の穴である。

同じことが④でも起きる。「出力をそのまま使用しないこと」を守り、担当者が自分で読んで直してから顧客へ送ったとする。だが「読んで直した」記録はどこにも無い。半年後に指摘が入ったとき、会社が示せるのは条文だけである。規程は守られたが、責任の所在は空白のままだ。

現地法人は本社の規程を「改訂できない」

多くの日系現地法人には、本社が定めたグループ規程を書き換える権限が無い。だから穴に気づいても、現地でできるのは補完文書を作ることだけである。だがこれは現実的な設計方針でもある。本社版の全面改訂を待たず、上位規程として残したまま、拠点側で「本社版が触れていない4項目」を定めた実施要領を1枚足せばよい。

この4章は、後述するタイのAI法案がdeployerに課そうとしている義務にそのまま対応する。だから法案が成立しても書き直しにならない。逆に、条文の雛形をどこかから持ってきて並べた規程は、法案の中身が確定した時点で作り直しになりやすい。規程の前に決めるべきなのは条文ではなく、この4章の中身である。

穴① 法域 ― タイのAI法案は「使う側」に義務を課す

最初に事実関係をはっきりさせておく。タイのAI法（Draft Act on Artificial Intelligence）は、本記事の執筆時点である2026年8月7日において、まだ成立していない。 施行済みだと記載する解説記事が散見されるが、複数の法律事務所による解説はいずれも草案（draft）として扱っている。後述するベトナムのAI法の施行日と混同されたものと考えられる。タイについては「草案が公開され、意見公募を終えた段階」というのが正確である。

所管はETDA（Electronic Transactions Development Agency、電子取引開発機構）で、2026年7月2日に新版のドラフトを公開し、約30日間のパブリックヒアリングを実施した。意見公募の窓は2026年8月上旬に閉じたとみられる。

ただし未成立は、規程づくりを先送りしてよい理由にならない。草案が示す義務の構造は日本の規程がそもそも持っていない種類のもので、成立後の猶予も短く、求めていることの大半は法律が無くても社内統制として妥当だからである。

草案が置いているリスク3分類

草案はAIシステムを3つの区分に分けている。

Designated AIという区分は実務上とくに重い。今は対象外でも、勅令ひとつで届出や登録の対象に入りうるからだ。「対象になったら何を出せるか」を用意しておかないと、指定された時点で慌てて記録を作ることになる。

なお草案には域外適用の規定もある。タイ国内の人に影響を及ぼすAIの開発・提供・利用は、行為が国外で行われていても対象になる。日本本社のサーバで動かしているシステムがタイの従業員や顧客に影響を与えるなら、日本にあるという理由だけでは対象外にならない。タイの制度環境や地域ハブとしての位置づけはタイのAI活用と制度環境を整理した記事でも扱っている。

deployerの義務 ― ここが日本の規程に無い

事業会社に直接効いてくるのはdeployer（AIを使う側）の義務である。AIを開発する会社ではなく、買ってきて使う一般の会社が名指しで義務を負う点が重要だ。

本社の規程を開いて、この5項目に対応する条文があるか確認してほしい。多くの場合、あるのは「提供者の利用規約を遵守すること」に近い一文だけである。監督責任者の指名も、ログの保持期間も、当局への通知窓口も書かれていない。理由は単純で、日本の現行法がそれを求めていないからだ。法令に無いことは規程にも書かれない。これが法域の穴である。

運用ログ6か月という要求の重さ

5項目のうち最も準備に時間がかかるのは運用ログの6か月保持である。ログが「後から遡って作れない」唯一の項目だからだ。監督責任者は明日決められるしリスク評価は今週書けるが、ログは取り始めた日より前には存在しない。

そして無償の生成AIを個人アカウントで使っている限り、会社がログを保持することは原理的にできない。誰がいつ何を入力したかの記録が会社の管理下に無いからだ。この一点だけで、「無償サービスの黙認」はdeployer義務を満たせない構成だと分かる。

制裁と施行の段取り

草案は行政制裁金として1,000,000〜5,000,000バーツ／違反を置き、サービス停止命令やISPによるブロッキング命令の可能性も規定している。金額の絶対値より「1違反あたり」という単位に注意したい。同種の不備が複数の用途で見つかれば、それぞれが違反として数えられうる。

施行は2段階で、中核となる規定は官報公示で即時に、リスク管理・監督に関する規定は180日後に効力を持つ。180日は長く見えるが、ログを6か月保持する義務と組み合わせると意味が変わる。効力発生の時点で6か月分のログを持つには、その6か月前から取り始めていなければならない。つまり180日は「猶予期間の初日にログ取得を始めてちょうど間に合う」長さで、成立してから設計を始めると間に合わない。

なお草案はETDA配下にAI Governance Centerを設置する規定を置き、PDPA（個人情報保護法）との関係も明記している。生成AIの規程をPDPA対応と切り離すと二重管理になって続かないため、既存のPDPA運用の上に載せる設計にしておきたい。

穴①の続き ― ベトナムのAI法は既に施行済みである

タイが未成立であるのに対し、ベトナムのAI法（Law on Artificial Intelligence）は既に成立し、施行されている。この2つを取り違えると、規程の適用範囲を丸ごと間違える。

ベトナムのAI法は法番号No.134/2025/QH15として2025年12月10日に成立し、2026年3月1日に施行された。国内主体だけでなく外国主体にも適用される。既存システムには猶予期間が置かれている。

日本の親会社から見ると、ベトナム拠点で既に動いているチャットボットや文書生成の仕組みは、2027年3月1日までに法の要求へ合わせておく必要がある、という読み方になる。医療・教育・金融に関わる用途であれば2027年9月1日まで。いずれにせよ残りは長くない。

provider と deployer で透明性義務が違う

実務上まず効いてくるのは透明性義務である。提供する側と使う側で内容が異なる。

事業会社は通常deployerに当たる。「機械可読な標識を自分で埋め込め」ではなく「誤認させる恐れがあるなら明示せよ」という義務なので、ツールの設定ではなく社内の判断基準として書かなければ運用できない。何をもって「混同を生じさせる恐れ」とみなすかを、拠点の業務に即して例示しておく必要がある。製品写真の生成、社内報の人物画像、顧客向け説明動画のナレーション音声。このあたりが判断を求められる場面になる。なお同法はサンドボックス制度や国家AIインフラへの優先アクセスも規定している。

2か国を並べると規程の設計方針が決まる

タイは未成立、ベトナムは施行済み。この非対称は、規程をどう書くかに直接効く。法域ごとに条文を分けて書くと、片方が動くたびに全体を改訂することになるからだ。

そうではなく、共通部分と法域固有部分を分離する。共通部分に置くのは、データ分類、経路の許可設計、出力の検収責任、ログと監督体制の4章。法域固有部分に置くのは、保持期間の下限、通知先の当局名、明示が必要な表示の文言といった、数値と固有名詞だけである。この分け方なら、タイのAI法が成立したときに書き換えるのは数行で済む。海外拠点を持つ会社の規程は、改訂しやすさそのものを設計要件に入れておくべきである。

穴② 言語 ― 「訳す」のではなく「判断できる形」に作り替える

本社版をタイ語に翻訳すれば現地展開は終わり、と考えている会社は多い。だが翻訳しても運用に落ちない。理由は翻訳の品質ではなく、原文の書き方にある。

日本語の規程は「〜してはならない」という文末で書かれることが多い。忠実に訳せば、タイ語でも禁止事項の一覧になる。読んだ現地スタッフの手元に残るのは、禁止された行為のリストだけである。現場が必要としているのは逆で、「この作業をするとき、どのツールに、どこまでのデータを入れてよいか」だ。だから翻訳の前に、原文の主語を行為から「扱うデータの分類」へ書き換える必要がある。主語がデータになっていれば、ツールが変わっても業務が変わっても判断の仕方は変わらない。

訳したときに壊れる箇所

実際に日本語の規程をタイ語やベトナム語にしたとき、意味が保たれない表現には傾向がある。

この5つは、日本語で読んでいるうちは曖昧さが目立たない。読み手が文脈で補ってくれるからだ。翻訳するとその余地が消え、曖昧さがそのまま残った文書ができあがる。

何語で運用するかを先に決める

タイ拠点では、規程が3つの言語を行き来する。本社が日本語で書き、駐在員が英語で読み、現地スタッフがタイ語で運用する。決めておくべきは、どの版が正本かである。日本語版を正本のままにするとタイ語版は参考訳になるが、現地スタッフの多くは日本語を読まないので、実質的な判断はタイ語版で行われる。

現実的な落とし所は、上位の方針文書は本社の日本語版を正本とし、拠点の実施要領はタイ語版を正本とする二層構造である。実施要領に入れるのは、データ分類、経路の許可、検収の手順、記録の残し方の4つだけでよい。これがタイ語で読めれば運用は回る。

タイ語で扱えるモデルが増えているという前提の変化

規程が「英語で使うこと」を暗黙の前提にしているケースがあるが、その前提も崩れつつある。

タイでは、国家科学技術開発庁（NSTDA）と高等教育科学研究イノベーション省、NECTECが中心となり、タイ語の基盤モデルを開発するThaiLLMという取り組みが進んでいる。予算は8,000万バーツ。モデルサイズは80億パラメータと300億パラメータの2種で、1,000億トークンを超える規模のデータで学習されている。サブモデルとしてOpenThaiGPT（AIEAT）、Pathumma（NECTEC）、Typhoon-S（SCB 10X）、THaLLE（KBTG）の4つが位置づけられ、KBTG、SCB 10X、VISTECが導入に着手している。用途もチャットボットにとどまらず、自動化、意思決定支援、社内システム連携、対顧客サービスといったエージェント型の使い方が想定されている。

規程にとっての意味は明快だ。タイ語のまま業務で生成AIを使う選択肢が現実になる。従来は「英語に訳してから入力する」という一手間があり、それが結果的にデータの持ち出しを抑えていた。タイ語でそのまま入力できるようになれば、その抑制は消える。英語利用を前提にした規程では、タイ語での利用が規程の外側で起きることになる。

言語の穴を塞ぐとは、翻訳の精度を上げることではない。誰がどの言語で判断するかを決め、その言語で判断できるだけの情報を規程に入れることである。

穴③ 経路 ― ツール列挙型からデータ経路型へ

生成AI利用規程で最も多い書き方は、許可ツールと禁止ツールを一覧にする方式である。管理する側には分かりやすい。だがこの書き方は、データが社外へ出る経路を捕まえられない。

ツール名で書くと何が抜けるのかを、拠点で実際に起きている経路と並べて見ていく。

6つのうち、ツール名の許可・禁止リストで扱えるものは事実上ゼロである。理由は共通していて、いずれも「生成AIサービスを使う」という意識が伴わないからだ。翻訳サイトに貼り付けている人は、自分が生成AIを使っているとは思っていない。意識されていない行為は、意識を前提にしたルールでは止まらない。さらに、禁止ツールを列挙するほどシャドーAIは増える。禁止された名前を避けて別の名前のサービスへ移るだけであり、列挙は「一覧に載っていなければよい」という読み方を教えてしまう。

経路で書くと、何が変わるか

ツール名ではなく、データが社外へ出る経路そのものを主語にする。規程に書くのは3点。第一に、許可された経路の定義。会社が管理するアカウントで、会社が管理する端末から、契約で学習利用を除外したサービスへ送る、という条件の組み合わせで定義する。第二に、許可された経路以外へデータを出さないという原則。第三に、経路を追加したいときの申請先と判断基準。

この書き方なら、新しいサービスが出ても規程を改訂しなくてよい。「まだ許可された経路に含まれていない」というだけで扱いが決まるからだ。改訂が要るのは経路を1本増やすときだけである。

経路を塞ぐのは規程ではなく設定である

経路の穴は、規程の文章だけでは塞がらない。塞ぐのは技術的な設定であり、規程はその設定に根拠を与える文書である。具体的には、会社が管理するアカウントの発行、業務端末での拡張機能のインストール制御、会議ツールの録音・文字起こし機能の既定値の設定、契約時に学習利用を除外する条項の確認。この4つを実施したうえで、規程に「許可された経路とはこの構成を指す」と書く。規程を先に配って設定を後回しにする会社が多いが、それでは規程だけが宙に浮く。権限とアカウントの棚卸しの手順はMicrosoft Copilot導入と権限の棚卸しを扱った記事で整理している。生成AIが社内データを参照する構成では既存のアクセス権限がそのまま出力範囲になるため、経路の設計と権限の棚卸しは同じ作業として扱ったほうがよい。

穴④ 責任 ― AI出力の検収責任を条文で決める

4つの穴のうち最も書かれていないのがこれである。前述のとおり、トラブル時の責任所在などのルール整備を課題に挙げた企業は25.5%にとどまり、情報漏洩のリスクを挙げた33.5%より少ない。にもかかわらず、実際に会社が説明を求められるのは、出力が誤って外へ出たときである。

多くの規程には「生成AIの出力は参考にとどめ、最終的な判断は人が行うこと」という一文がある。方向性は正しいが、条文としては機能しない。誰が、どの時点で、何をもって判断したことになるのかが決まっていないからだ。機能させるには次の4つを埋める必要がある。

現場が最も嫌がるのは4つ目の記録である。だが記録が無いと、事後に会社が示せるものが条文しか無くなる。前章のログと同じで、記録は後から作れない。

記録を軽くする書き方

記録を続けるコツは、粒度を成果物の種類で変えることである。すべてを同じ重さで記録しようとすると続かない。

この4段階なら記録の対象は一部に絞られ、現場の負荷は「顧客へ出すものだけ1行足す」に収まる。

「AIに任せた度合い」で段階を分けない

条文を書くときに避けたい発想がある。「全文をAIが生成した場合は上長承認、一部なら不要」といった、AIの寄与度で責任を段階分けする発想だ。これは運用できない。文章は書き直され、数字は転記され、どこまでがAIの出力かの境界は事後に消えるからである。切り分けられない基準を条文に置くと、判断が個人の申告に委ねられ、結局は無いのと同じになる。

代わりに、出力の使われ方で段階を分ける。社内にとどまるのか、外へ出るのか、契約上の効果を持つのか。使われ方は事後にも判別できる。判別できる基準だけを条文に置く、というのが検収条項の原則である。

なおベトナムではdeployerに対し、真正性について混同を生じさせる恐れがある場合にAI生成であることを明示する義務が課されている。ベトナム拠点で顧客向けの画像や動画を作るなら、社内では検収の記録を残し、社外へは明示を行う二重の対応になる。検収は社内の責任の所在を決めるもの、明示は社外の受け手を保護するもので目的が違うため、別条として書き分けておきたい。

検収の項目を列挙すると副次的な効果もある。教育で何を教えるかが決まることだ。数値、固有名詞、日付、引用元、法令名を一次資料と突き合わせる作業を教えるのが社内教育の中身になる。プロンプトが上手くなると出力はもっともらしくなるが、もっともらしさは正しさではない。

規程の前に決めるデータ4分類

ここまでの3つの穴は、いずれも同じ前提を必要としている。扱うデータをどう分けるか、である。分類が無いまま条文を書くと、「機密情報」「重要な情報」といった定義されない語が散らばり、翻訳した瞬間に運用が止まる。

分類は4つで足りる。増やすと覚えられず、減らすと判断が粗くなる。

この表を作ることが、規程づくりの最初の作業である。条文はこの後で書く。順序を逆にすると、条文の中で分類を定義しようとして長くなり、しかも曖昧になる。

線引きで迷ったときの原則

原則を2つ置いておくと議論が収束しやすい。第一に、迷ったら上位に置く。分類は後から緩められるが、一度出てしまったデータは戻せない。第二に、「その情報が競合他社の手元にあったら困るか」で判断する。困るならL3以上である。抽象的な機密性の議論より判断の再現性が高い。

もうひとつ、実務でよく問題になるのが「組み合わせると機微になる」ケースである。取引先名だけならL3、数量だけならL2でも、両方が揃うと事業の内容が読める。分類表には「同一の入力に複数の分類が混ざる場合は、最も高い分類として扱う」という一文を必ず入れておきたい。

L4については、匿名化しても入力しないという線を推奨する。匿名化の妥当性を誰が判断するのかが決まらないからだ。氏名を消しても、部署と役職と入社年が残れば個人は特定できる。判断を個人に委ねると、そのばらつきがそのまま漏洩リスクになる。線は単純なほど守られる。なおタイのAI法案では高リスクAIの義務にPDPAに沿ったデータガバナンスが含まれるとされており、個人情報を含むデータは生成AIの規程だけで完結させず、既存のPDPA運用と同じ台帳の上で管理するのが現実的である。

社内データを参照させる構成では、分類が権限になる

分類表が本当に効いてくるのは、社内文書を生成AIに参照させる構成を始めたときである。この構成では、利用者が何を入力するかに関係なく、システムの側が社内文書を読み込んで回答を作る。つまり入力の制御だけでは足りず、参照させる文書の範囲を分類で制御することになる。L4を格納フォルダごと対象外にする、L3は閲覧権限を持つ部署のみが検索できるようにする、といった設計だ。具体的な進め方は社内データ連携の実装を扱った記事で整理している。

注意したいのは、既存の共有フォルダの権限設定がそのまま出力範囲になる点である。長年運用してきた共有フォルダには、たいてい「本来は見えてはいけない人に見えている」箇所がある。人間が見に行かないから顕在化していなかっただけで、検索する仕組みを載せた瞬間に露出する。分類表を作る作業は、実質的に権限の棚卸しと同じ作業になる。なお分類表は必ずA4で1枚に収める。複数ページの基準は参照されず、参照されない基準は無いのと同じだからだ。

セキュアな生成AI環境の3案と、費用を検算できる形にする

規程の4章が固まると、次に決まるのは環境である。ここでは3案を比較する。金額は本記事が置いた前提での試算であり、一般的な価格を示すものではない。前提はすべて開示するので、自社の数字に置き換えて検算してほしい。

案A「無償サービスの黙認」は現状維持で、従業員が個人アカウントで無償の生成AIを使い、会社は禁止も許可もしていない。案B「法人向けSaaS」は会社が契約したアカウントを配り、学習利用を除外し、管理画面でログを取得できる構成。案C「自社テナント＋API」はクラウド上に自社テナントを用意してAPIで呼び出す仕組みを自前で作る構成で、記録設計を自由に組める代わりに構築と運用の工数が乗る。

試算の前提

まず前提を全部出す。ここを隠した試算は検算できない。

人時単価の50バーツ/時は現場作業1時間の換算値で、管理部門やIT担当の実単価はこれより高い。低い単価を使うと社内工数が過小評価され、自社構築が有利に見える偏りが生じるため、後段で感度分析を行う。

案A ― 無償サービスの黙認

数量の列は自社の実績に置き換える前提の仮置きである。金額だけを見ると案Aが圧倒的に安い。この表は費用比較の限界を示す表でもある。案Aには金額に載らない欠落、すなわち会社が運用ログを保持できないという欠落があるからだ。タイのAI法案はdeployerに運用ログの最低6か月保持を求めており、個人アカウント利用ではこれを満たす手段がない。行政制裁金1,000,000〜5,000,000バーツ／違反が置かれている草案の下で、この欠落を費用表の外に置いて比較するのは誠実ではない。

案B ― 法人向けSaaS

案Bは費用の大半が席課金で社内工数が小さい。人数に比例して増える一方、担当者の負荷はほとんど変わらないため、人数が少ないうちは割高に見え、増えるほど自社構築との差が縮む。

案C ― 自社テナント＋API

API従量費を数値で埋めていないのは、根拠を置けないからである。単価はモデルと契約形態で変わり、消費量は用途で変わる。仮の数字を入れると、その1マスだけで結論が反転してしまう。埋められないマスは埋めない、というのが検算できる試算の条件である。

案Bと案Cを比べると、案Bの年間合計は304,400バーツ、案Cは25,600バーツにXを足したものだから、X = 278,800バーツのときに両者が並ぶ。月あたりに直すと23,233バーツ、対象50人で割ると1人あたり月およそ465バーツである。つまり「1人が月465バーツ相当以上のAPIを消費するなら案Bが安く、下回るなら案Cが安い」という読み方になる。この値は前提から機械的に出るので、自社の人数と工数を入れ替えれば計算し直せる。

感度分析 ― 人時単価を動かす

人時単価は前提の中で最も動きやすい変数である。ここを動かすときは、費用側に入れた社内工数の金額換算もすべて同時に動かす。片側だけ動かすと結論が歪む。

読み取れるのは1点だけだ。人時単価が上がるほど分岐点Xは下がる。工数が支配的な案Cのほうが単価上昇の影響を強く受けるため、人件費が高い組織ほど自社構築が有利になる条件は厳しくなる。IT担当の実単価が現場作業の換算値より高い会社では、案Cが安く見えていても単価を実勢に直した瞬間に逆転しうる。

便益と回収年数を書かない理由

この試算では時間削減を金額に換算していない。実測値を持っていないからである。持っていない数字を便益に積むと、費用側の精度が高くても結論は仮置きの値で決まる。同じ理由で回収年数も書かない。便益に根拠が無ければ回収年数にも根拠が無く、根拠の無い回収年数は意思決定の材料ではなく、意思決定を止めないための飾りになる。

案の選択は費用の大小ではなく「規程で決めた要件を満たせるか」で行う。ログを6か月保持できるか、学習利用を除外できるか、分類L3を扱える契約か。この3点を満たす案の中で費用が小さいものを選ぶ。案Aは最も安いが1点目を満たせないので候補から外れ、案Bと案Cに絞られた後で初めて分岐点の計算が意味を持つ。機能面の比較は法人向け生成AIツールの比較記事で扱っている。

規程を運用に落とす90日の順序

規程は書き上げた日ではなく、運用が回り始めた日に完成する。拠点側の実施要領を作って動かすまでの順序を90日で示す。順序に意味があるので並べ替えないこと。

この30日で条文は1行も書かない。決めるだけである。条文を先に書き始めると、決めていないことを曖昧な語で埋めることになり、翻訳した時点で崩れる。洗い出しでは現地スタッフへの聞き取りを必ず入れたい。管理部門が把握しているツールと、現場が実際に使っているツールは一致しないからだ。

31〜60日 ― 塞ぐ

決めたことを技術的な設定に落とす期間である。ここが最も抜けやすい。

このうちログの取得開始は最優先である。ログは遡って作れないので、他の設定が終わっていなくても先に取り始めたほうがよい。同じ期間に実施要領の条文を書く。決めたことを写すだけなので作業は軽い。書く言語は拠点で判断する言語にする。日本語で書いて訳すのではなく、判断する言語で書いて日本語に訳し本社へ説明する順序のほうが崩れない。

61〜90日 ― 動かす

説明会では禁止事項の読み上げをしない。覚えられないからだ。代わりに拠点の実際の業務を3件持ち出し、「この作業はどの分類か、どの経路なら使えるか」を参加者に答えてもらう。答えが割れた箇所は分類表か経路の定義に不足があるということなので、その場で持ち帰る。規程の完成度はここで測れる。

監督責任者の指名もこの期間に行う。タイのAI法案が成立した場合にdeployerへ求められる項目であり、成立を待つ必要はない。職位で決め、氏名を記載し、交代時の引き継ぎ手順を1行添える。兼務でかまわないが空席にはしない。なお定着の段階で効くのは、規程そのものより使ってよい範囲が現場に伝わっているかどうかで、禁止だけが伝わると利用は止まる。実利用率を上げる取り組みは生成AIの定着と実利用率を扱った記事で整理している。

見直しの周期も規程本文に書き込んでおく。推奨は、分類表が年1回、経路の一覧が半年に1回、法域固有部分が随時である。法域固有部分を随時としているのは、タイのAI法案が未成立だからだ。成立した時点で保持期間の下限や通知先の当局名を確認し、該当箇所だけを差し替える。ベトナム拠点を持つ会社は、既存システムの猶予期限が2027年3月1日、医療・教育・金融分野であれば2027年9月1日であることを、見直し計画上の固定日として先に押さえておきたい。

よくある質問

規程づくりの相談でとくに多い質問を5つ挙げる。

生成AI利用規程は何から書き始めればよいですか？

条文からは書き始めない。最初に作るのはデータ4分類の1枚である。分類が決まっていないと、条文の中で「機密情報」といった定義されない語を使うことになり、翻訳や監査のたびに解釈のばらつきを生む。分類の次は、社外へデータが出る経路の洗い出し、検収の対象と記録の粒度、ログと監督体制の順である。この4つが決まれば条文は写すだけになる。逆に言えば、雛形を先に入手してもこの4つは埋められない。雛形には、その会社が扱うデータも拠点が使っている経路も書かれていないからだ。

無料の生成AIを全面禁止すべきですか？

全面禁止は勧めない。ひとつは、禁止しても止まらないからだ。社外へデータが出る経路は生成AIの画面だけではなく、翻訳サイト、チャットアプリのAI機能、ブラウザ拡張、議事録アプリが残る。もうひとつは、守れない範囲まで禁止すると規程全体の信頼が落ちるからだ。分類L1の公開情報の要約まで一律に止めると、現場は規程を現実離れした文書とみなし、他の条項も守らなくなる。禁止すべきなのはツールではなく、分類L3以上のデータを許可されていない経路へ出す行為である。

本社の生成AIガイドラインをタイ語に翻訳すれば社内展開は足りますか？

足りない。翻訳の品質ではなく原文の書き方の問題である。禁止事項の一覧として書かれた文書をそのまま訳せば、タイ語でも禁止事項の一覧になる。読んだ側に残るのは「してはならないこと」だけで、「この作業では何をしてよいか」は分からない。加えて「必要に応じて」「適切に」といった曖昧表現は、訳すと判断できない文になる。実務上の解は、方針文書は日本語版を正本のまま残し、拠点の実施要領はタイ語版を正本とする二層構造である。

生成AIの情報漏洩対策として、まず何を止めればよいですか？

止める順序は、リスクの大きさではなく止めやすさと効き方で決める。第一に、モデルの学習利用設定。設定ひとつで入力したすべてのデータの扱いが変わる。第二に、個人アカウントでの業務利用。会社が管理するアカウントに切り替えないとログが手元に残らない。第三に、業務端末のブラウザ拡張機能。閲覧中の画面がそのまま外部へ送られる構成があり、利用者に自覚が無い。第四に、会議ツールの録音・文字起こしの既定値。この4つはいずれも規程の文章ではなく設定で止まる。

セキュアな生成AI環境は、どの基準でツールを選べばよいですか？

費用から入らないことである。先に要件を決め、満たす候補の中で費用を比べる。要件は3つでよい。運用ログを最低6か月保持できるか。学習利用を契約上除外できるか。分類L3のデータを扱える契約条件か。この3点を満たさない構成は、費用がいくら安くても候補から外す。無償サービスの黙認が最初に落ちるのは、費用が高いからではなく1点目を満たす手段が無いからだ。

まとめ ― 規程が守るのは、経路と検収責任である

本記事の主張は2つだけである。ひとつ、生成AI利用規程が守るのはツールの使用可否ではなく、データが社外へ出る経路と、AIの出力が業務に採用されるときの検収責任である。ふたつ、日本本社が作った規程をタイ拠点にそのまま持ち込むと、法域・言語・経路・責任の4つの穴が開く。

塞ぎ方も4つに対応する。データ4分類を先に決め、社外へ出る経路を許可制で設計し、AI出力の検収と記録の粒度を決め、ログの保持と監督責任者を置く。この4章はタイのAI法案がdeployerに課そうとしている義務にそのまま対応するので、法案が成立しても書き直しにならない。タイのAI法は2026年8月7日時点で未成立だが、ベトナムのAI法は既に施行済みで、既存システムの猶予期限は2027年3月1日、医療・教育・金融分野では2027年9月1日である。法域ごとに状況が違うという前提を、規程の構造の側に持たせておきたい。

条文の雛形を配らなかったのは、雛形では埋められない部分が結論を決めるからである。どのデータを分類L4に置くか、どの経路を許可するか、誰が検収するか。この3つは会社ごとに違う。そこが決まっていれば条文は写すだけの作業になり、決まっていなければどんな雛形も曖昧な語で埋まる。費用の判断も同じで、金額の大小ではなく3つの要件で決める。順序を逆にすると、最も安く見える構成が最も義務を満たせない構成だった、ということが起きる。

なお本記事は、帝国データバンク「生成AIに関する企業の動向調査」（2026年3月）、総務省「令和7年版 情報通信白書」、タイETDAが2026年7月2日に公開したAI法案に関する法律事務所の解説、ベトナムのAI法（No.134/2025/QH15）に関する解説に基づいている。法案の内容は成立までに変わりうるため、規程改訂にあたっては最新の条文を確認してほしい。

規程づくりは、条文を書き始める前の整理でほとんど決まる。データ分類の草案がまだ1枚も無い段階でも、拠点の業務を並べながら分類の線を引くところから相談に応じている。タイ拠点での運用を前提にした実施要領の組み立てや、環境3案の要件確認について具体的に話を進めたい場合は、お問い合わせから連絡してほしい。現状の規程があれば、4つの穴のどこが空いているかの確認から始められる。