生成AIの社内ガイドラインをAIエージェントの段階に合わせるには、入力と出力のルールを残したまま、任せてよい操作・承認が要る操作・残す記録の三つの条項を足します。これがAIエージェントの権限の定めになり、改定の担当と時期まで書いておけば、生成AIの利用ルールが実態から遅れません。

社員の多くがチャット型の生成AIを日々の業務で使い、社内規程は「顧客の個人情報を入力しない」「出力は自分で確かめてから使う」という禁止と注意で一通り整っている。そこへ営業部門から、日報を読んで顧客管理システムを更新するAIエージェントを試したいという申請が上がってきたら、どの条文で可否を判断するでしょうか。

入力と出力の注意だけで組まれた規程なら、AIが自分で社内システムに書き込む場面を判断する条文は見当たりません。

規程に最終の判を押すのは経営です。その席で問われているのは「AIを使ってよいか」ではなく「AIに何をさせてよいか」であり、前者を前提に書いた規程の中に、後者への答えはありません。

今の生成AIの利用ルールは、どんな場面を前提に書かれているのか？

人がAIに質問や指示を入力し、返ってきた答えを人が確かめてから使う場面です。条文の柱が「入力」と「出力」の二本で組まれているのは、この前提から来ています。

一般社団法人日本ディープラーニング協会（JDLA）が公開している「生成AIの利用ガイドライン」のひな形は、この前提を構成の理由として明記した文書です。第1.1版（2023年10月公開）の第4項は、どのサービスも、ユーザがデータを入力し、処理を経てその結果（生成物）を得る構造だと説明しています。

そのうえで本文を「データ入力に際して注意すべき事項」と「生成物を利用するに際して注意すべき事項」の二部に分けました。対象とする生成AIを書く第2項の記入例も、チャット型のサービスの名前です。

入力の側に並ぶのは、第三者の著作物、登録商標や意匠、著名人の顔写真や氏名、個人情報、他社から秘密保持義務を課されて開示された秘密情報、自社の機密情報の六類型です。出力の側には、虚偽が含まれる可能性、他者の権利の侵害、著作権が発生しない可能性、商用利用の可否、サービスのポリシー上の制限が並びます。

国の文書も、立っている場面は同じです。個人情報保護委員会は2023年6月2日の注意喚起で、生成AIサービスを「質問・作業指示（プロンプト入力）等に応えて文章・画像等を生成するAIを利用したサービス」と定義し、事業者向けの注意点を、個人情報を含むプロンプトを入力する場面について示しました。

出力の側では、文化審議会著作権分科会法制度小委員会が2024年3月15日にまとめた「AIと著作権に関する考え方について」が、AI開発・学習段階と生成・利用段階を分け、生成物を使う場面の侵害を類似性と依拠性で判断する整理を示しました。

どの文書にも欠けがある、という話ではありません。三つが出たのは2023年5月から2024年3月にかけてで、想定された使い方は人がAIに尋ねる形でした。JDLAのひな形は、各組織の既存のデータポリシー等と整合を取り、加筆修正して使う前提で作られています。

2026年10月7日に同協会のページで確かめた時点で、掲載されているひな形は第1.1版と、2024年2月公開の画像編第1版でした。AIが操作する場面の章を書き足すのは、ひな形を使う側の仕事です。

AIエージェントが社内システムを操作すると、規程のどこが追いつかなくなるのか？

条文が義務を向けている相手（名宛人）である「入力する社員」と「出力を確かめる社員」が、操作の場面から外れます。エージェントは自分でデータを取りにいき、人が確かめる前にシステムへ書き込むからです。

総務省・経済産業省の「AI事業者ガイドライン（第1.2版）」（2026年3月31日）は、AIエージェントを「特定の目標を達成するために、環境を感知し自律的に行動するAIシステム」と定義しました。鍵は「行動する」の一語でしょう。答えを返すだけのAIなら、行動するのは答えを受け取った社員でした。

ずれは三か所に出ます。一つ目は入力の名宛人です。「社員は個人情報を入力しない」と書いても、受信メールや共有フォルダをエージェントが自分で読むなら、何を読ませるかを決めたのは入力した社員ではなく、エージェントを設定した人になります。

二つ目は確認の時点。出力の条項は使う前に確かめることを求めますが、エージェントの出力は顧客管理システムの更新やメールの送信といった操作として、確かめる前に効力を持ちます。

三つ目は記録の主語です。社員のIDで動かしたエージェントが商談情報を書き換えると、システムにはその社員の操作として残ります。後から、本人が手を動かしたのか、エージェントが動いたのかを見分けられません。

人の監視をどの地点に置くかは、国の指針と合わせて決める設計の論点で、AI事業者ガイドラインとAIエージェントの監視点の整理で掘り下げました。規程で先に決めるのは、その手前にある、AIに何をどこまで任せるかの線です。

生成AIの社内ガイドラインには、どんな条項を足せばよいのか？

既存の利用ルールは全社員向けにそのまま残し、その後ろに「AIエージェントの運用」の章を一つ足します。章に置く項目は七つで、条文には原則と判断の基準を書き、エージェントごとの具体的な値は別表に回します。

定義の条項は、製品名ではなく振る舞いで書きます。同じサービスでも、設定次第で答えを返すだけの使い方にも、システムへ書き込む使い方にもなるからです。書き込み・送信・ツールの呼び出しのどれかを行った時点で運用の章の対象になる、と定めておけば、新しいサービスが出るたびに定義を改めずに済みます。

読む人も分かれます。入力と出力の章は全社員が読む条文ですが、運用の章の名宛人は、エージェントを申請する部門、別表を承認する責任者、権限を設定する担当です。条文の主語も「社員は」の一本ではなく、「申請する者は」「承認する者は」と書き分けます。

数字は運用の章に新しく書かず、社内にある規程から引きます。決裁の線は職務権限規程、アカウントの扱いは情報セキュリティの規程、記録の保存期間は文書管理規程というように参照先を示せば、AIのためだけの基準が社内に増えません。

本則と別表を分けるのは、統制の重さと改定の速さというトレードオフを、層を分けて解くためです。エージェントを一つ足すたびに本則を経営会議にかけていては、改定が実態に追いつきません。変わりにくい原則は手続きの重い本則に、対象業務・接続先・許す操作・上限値のように動く値は手続きの軽い別表に置く。職務権限規程で決裁の金額基準を別表に切り出すのと同じ考え方です。

AIエージェントの権限は、何を物差しに決めるのか？

物差しは新しく作らず、社内で合意済みの職務権限規程から借ります。社員が決裁なしにできる操作はエージェントに任せる候補、決裁が要る操作はエージェントが行う場合も人の承認を通す、という読み替えです。

外の基準も、向きは同じです。セキュリティの国際的な非営利団体OWASPは、LLM（大規模言語モデル）を使うアプリケーションの主要リスク10項目を公開しています。その2026年版は、AIに持たせた機能・権限・自律性が過剰なことによる危険を「Excessive Agency」と呼び、2025年版の6位から3位に上げました。

挙げられた対策には、ツールと権限を必要最小限に絞ること、利用者に代わる操作はその利用者の権限の範囲で実行すること、影響の大きい操作の前に人の承認を挟むことが含まれます。

規程に写すと、エージェントは依頼した社員の権限の範囲でだけ動かす、という原則になります。全員のファイルを読める管理者のIDで動かせば、営業部長の依頼で動いたエージェントが、経理や人事のファイルまで読める状態になる。規程で求めておかなければ、依頼者に合わせたアカウントを用意する手間は後回しにされがちです。

依頼者のいない動き方にも決まりが要ります。毎朝決まった時刻に動くエージェントのように、その都度の依頼者がいない場合は、別表を承認した責任者を依頼者とみなし、その人の権限の範囲を上限にします。

同じ文書は、操作を許すかどうかの判定をLLMに委ねず、システム側の仕組みで行うことも求めています。社内規程の言葉にすれば、プロンプト（AIへの指示文）に「削除しないこと」と書いても、遵守の手段には数えない、という一文です。守らせる手段はアカウントの権限設定であり、AIへのお願いではありません。

接続の棚卸しも条文に入れます。OWASPの文書が過剰な機能の例に引くのは、開発の途中で試して使わなくなったツールが、そのままエージェントから呼べる状態で残っている場面です。試験導入で一時的に足した接続を、本番の別表に載せる前に外すという手順を本則に置けば、この取り残しを防げます。

任せる操作と承認が要る操作は、別表でどう分けるのか？

「任せる」「任せて知らせる」「止めて承認」「任せない」の四段に分け、操作を一つずつどれかに置きます。取り消しやすい操作ほど上の段に、取り消せない操作や社外に届く操作ほど下の段に寄せるのが基本の並びです。

この並べ方は、OWASPの同じ文書にある段階的な執行（記録・警告・上申・遮断）を、社内規程の言葉に置き換えたものです。仮に、営業担当の日報を読んで顧客管理システム（CRM）を更新するエージェントを想定すると、別表の区分は次のように置けます。

最も重いのは最下段です。エージェントが自分の権限を広げる操作を「任せない」に置いておかなければ、上の三段はいつでも書き換えられる約束になってしまいます。

区分と並べて、止め方も別表に書きます。止める権限は広く、再開の権限は狭く置く。異変に気づいた担当者が承認を待たずに止められ、再開は別表を承認した責任者が記録を確かめてから行う形です。OWASPの文書でも、呼び出しの回数や、金額のような入力値の累計にしきい値を設け、超えたら止めるか人の確認に回す仕組みが対策の一つです。

記録の条項に何を書いておけば、後から説明がつくのか？

条文に置くのは記録の細目ではなく、保存先・保存期間・閲覧できる人・記録の使い道の四点です。細目は業務ごとに変わりますが、この四点が決まっていなければ、誰も読まない記録が積み上がるだけです。

中身の最低線は、誰の依頼で、どの操作を、誰の承認で行ったかの三つ。記録の主語のずれは、エージェント専用のアカウントを用意し、その名義で操作を残すことで解けます。OWASPの同じ項目でも、ツールの利用とつながった先のシステムの動きの記録と監視は、防ぐ手段ではなく被害を限定する手段という扱いです。

閲覧できる人は、申請した部門の外にも置きます。申請した部門だけが読む記録では、承認が形だけになっても気づく人がいません。内部監査や規程の事務局が読めるようにし、置き場所はエージェント自身が書き換えられない場所に限ります。

保存期間は、エージェントが触れる業務の文書と同じ長さにそろえます。受注や請求に関わる操作の記録だけが先に消えれば、文書は残っているのに、誰の依頼で作られたのかを示せません。使い道の欄には、改定の材料に使うことまで書いておきます。

記録には、顧客の氏名や問い合わせの中身が残ることもあります。その保存先は個人データの持ち出しと同じ目で見る対象で、データが社外に出る地点の見分け方はAI業務自動化と個人情報保護法の整理にまとめました。

規程は誰が、どんなきっかけで改定するのか？

本則は年に一度の定期見直しと、あらかじめ決めたきっかけで開く臨時見直しで回し、別表はエージェントを足したり変えたりするたびに業務の責任者が更新します。改定の担当を「情報システム部門」とだけ書くと、業務の変化を知る人が改定から抜け落ちます。

定期見直しは、予算を組む時期の直前に置くと回しやすくなります。翌年度に足したいエージェントと、そのための権限やアカウントの手当てを、規程と予算で同時に決められるからです。見直しの場には、規程の事務局、情報システムの担当、エージェントを使う部門の責任者、記録を読む監査の役が並びます。

きっかけは本則に列挙しておきます。

• 新しいエージェントを業務に入れるとき、接続先のシステムが増えるとき（別表の更新）
• エージェントが使うAIモデルを替えたとき（別表の更新）
• 承認の差し戻しや自動停止が続いたとき（別表の見直し）
• 国の指針や業界の基準が改訂されたとき（本則の見直し）
• 想定していない操作が起きたとき（本則と別表の臨時見直し）

モデルの変更をきっかけに入れた理由は、替える作業の軽さにあります。ハマダラボ（HAMADA LABS）のWindyFloも、数回のクリック作業によるAIモデルの変更を公開ページで利点に掲げる道具です。替えやすい道具ほど、承認したときと違う構成で動き続ける余地が生まれるため、規程の側で「替えたら別表を更新する」と決めておきます。

外の基準も止まりません。AI事業者ガイドラインは2026年3月に第1.2版となり、自らをLiving Document（状況に応じて更新し続ける文書）と位置づけて、定義を含めた更新を続ける立場です。OWASPの順位の入れ替わりも2025年版と2026年版のあいだの出来事で、JDLAがひな形の公開時に掲げたのも、技術の進展や業界動向に合わせて更新する方針でした。

想定していない操作が起きたときは、該当するエージェントを止めてから別表を直す、という順番も本則に書きます。動かしたまま直すと、直している間の操作がどの版の別表に従ったのか、記録の上で切り分けられなくなります。

別表を日々書き換える担当と承認する責任者の分け方は、非エンジニアがAIエージェントを運用する体制で役割ごとに整理しています。

エージェントを組む基盤の側では、規程の何と突き合わせるのか？

別表に書いた「任せる操作」と、エージェントが実際にたどる処理の並びです。規程が紙の上で正しくても、組まれた処理の流れが別表と違えば、承認した内容とは別のものが動きます。

WindyFloは、処理の部品にあたる「ノード」をドラッグ＆ドロップでつなぎ、AIパイプライン（処理の流れ）を組むノーコードの基盤です。公開ページには「ビジュアル化されたAIパイプラインで、チーム内共有もスムーズに」とあります。別表を承認する場で、表と処理の図を並べて見比べられる形です。

見比べるときは、社外や基幹システムにつながる部品を先に探し、その手前で人の承認を待つ手順があるかを確かめます。別表で「止めて承認」に置いた操作の前に承認の段がなければ、それが表と実物の食い違いです。

どこで動かすかも、記録の条文と無関係ではありません。会社資料では、WindyFloの配備形態としてSaaS（クラウドのサービスとして使う形）・顧客のクラウド・オンプレミス（自社の設備に置く形）・ハイブリッド（両者の組み合わせ）を挙げており、選ぶ形によって記録の保存先の書き方が変わります。

答える道具には利用の作法を定めれば足りても、働く道具には職務権限と業務記録に当たる条文が要ります。規程に足す章の正体はこの条文で、ハマダラボが「ChatGPTは答えます。WindyFloは働きます。」と掲げるときの「働く」側のためのものです。別表の一行目に載せる業務が決まったら、WindyFloの概要とあわせて、その業務の処理の並びを書き出してみてください。

よくある質問

出典

• ［1次］一般社団法人日本ディープラーニング協会（JDLA）「生成AIの利用ガイドライン」第1.1版（2023年10月公開）【条項のみ】【簡易解説付】、および「生成AIの利用ガイドラインの作成にあたって」（2023年5月1日）— 第4項の構成説明と入力・生成物利用の二部構成、第2項の対象AIの記入例、入力の六類型、生成物を利用する際の注意事項、前文（既存のデータポリシー等との整合と加筆修正）、第2項解説のホワイトリスト方式、技術の進展・業界動向に合わせた更新の表明、掲載中のひな形の版（第1.1版・画像編第1版［2024年2月公開］）: https://www.jdla.org/document/#ai-guideline （確認日 2026-10-07）
• ［公式］個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（2023年6月2日）別添1 — 生成AIサービスの定義、個人情報取扱事業者における注意点（個人情報を含むプロンプトの入力時に確かめる事項）: https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/ （確認日 2026-10-07）
• ［公式］文化審議会著作権分科会法制度小委員会「AIと著作権に関する考え方について」（2024年3月15日）および同概要 — AI開発・学習段階と生成・利用段階の区別、生成・利用段階における類似性と依拠性: https://www.bunka.go.jp/seisaku/chosakuken/aiandcopyright.html （確認日 2026-10-07）
• ［公式］総務省・経済産業省「AI事業者ガイドライン（第1.2版）」（2026年3月31日）本編 — AIエージェントの定義、Living Documentとして定義を含め適宜更新する位置づけ: https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/pdf/20260331_1.pdf （確認日 2026-10-07）
• ［1次］OWASP GenAI Security Project「OWASP Top 10 for LLM Applications 2026」（2026年8月3日公開）LLM03:2026 Excessive Agency — 根本原因（過剰な機能・権限・自律性）、試験で使わなくなったツールが呼べる状態で残る例、対策（ツール・機能・権限の最小化、利用者に代わる操作をその利用者の権限の範囲で実行、影響の大きい操作の人による承認、LLMに許可判定を委ねないcomplete mediationと記録・警告・上申・遮断の段階的な執行（原文の列挙順は記録・警告・遮断・上申）、ツール利用の記録と監視、呼び出し回数や累計値のしきい値による停止）、2025年版（2024年11月公表、LLM06:2025）からの順位の上昇: https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/ ／ 2025年版: https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ ／ 団体の性格（Open Worldwide Application Security Project、非営利財団）: https://owasp.org/about/ （確認日 2026-10-07）
• ［1次］ハマダラボ（HAMADA LABS）WindyFlo 日本語ページ — 「ノード」のドラッグ＆ドロップ接続によるAIパイプライン構築、ビジュアル化されたAIパイプラインのチーム内共有、数回のクリック作業でのAIモデル変更: https://www.windyflo.com/jp （確認日 2026-10-07）
• ［自社資料］ハマダラボ 会社資料（2026年9月）— WindyFloの配備形態（SaaS・顧客クラウド・オンプレミス・ハイブリッド）
• 本文の区分表（日報から顧客管理システムを更新するエージェント）は説明のための想定例で、特定企業の事例ではありません。条文の書き方は、各社の職務権限規程や文書管理規程との整合を確かめたうえで決めてください（個別事案についての法的助言ではありません）。