生成AI利用ポリシーを開発会社と作るコツ｜禁止リストより「許可と手順」中心に

生成AIの急速な普及に伴い、企業が「AI利用ポリシー」を策定する動きが加速しています。しかし、多くの現場で陥りがちなのが「○○は禁止」「機密情報は入力不可」といった禁止事項の羅列に終始してしまうパターンです。これでは現場の利便性が損なわれ、結果として管理の目が届かないところでAIが使われる「シャドーAI」を助長しかねません。

本記事では、IT実務者の視点から、開発会社や外部パートナーと協力して「どのようにAIを安全に使い倒すか」という許可と手順にフォーカスしたポリシー作成のコツを解説します。単なる法務的な文書ではなく、明日からの開発・業務フローに組み込める実戦的なガイドラインを目指します。

1. 生成AI利用ポリシーを「許可と手順」中心で作成すべき理由

なぜ「禁止リスト」よりも「許可基準」が重要なのでしょうか。それは、生成AIの技術革新スピードが速く、一律の禁止では事業競争力を損なうからです。

1.1 「禁止」だけではシャドーAIを招くリスク

「ChatGPT利用禁止」というルールを掲げても、個人のスマートフォンや自宅のPCで業務の相談をAIに投げる従業員を完全に防ぐことは不可能です。一度シャドーAI化すると、どのような情報が流出したかのログすら追えなくなります。「この条件を満たせば使って良い」という明確なルートを示すことが、最大のセキュリティ対策となります。

1.2 開発会社と共同で策定するメリット

システム開発を外部に委託している場合、開発会社側でもGitHub Copilotなどのコード生成AIを利用しているケースがほとんどです。発注側と受注側で認識を合わせておかなければ、納品物の著作権やライセンス、セキュリティ脆弱性の責任所在が曖昧になります。初期段階で「開発プロセスにおけるAI利用の許可範囲」を合意することは、プロジェクトのリスク管理そのものです。

1.3 攻めのガバナンス：生産性と安全性の両立

適切なポリシーは、従業員に「安心感」を与えます。「この手順なら会社が認めてくれている」という自信が、プロンプトの工夫や業務改善のアイデアを促します。守りのガバナンスから、生産性を最大化するための「攻めのガバナンス」への転換が必要です。

2. 利用ポリシーに含めるべき「5つの許可基準」

ポリシーの核となる「許可基準」を作成する際は、以下の5つの観点で整理します。

2.1 ツール別の利用可否ランク（S/A/B/C）

すべてのAIを一律に扱うのではなく、セキュリティレベルに応じてランク分けを行います。

• ランクS（推奨）: Azure OpenAI Serviceなど、入力データが学習に利用されないことが契約で保証され、社内認証（SSO）が連携されている環境。
• ランクA（条件付き許可）: ChatGPT Team/Enterpriseプランなど、設定で学習をオフにできる法人契約ツール。
• ランクB（慎重に検討）: 無料版のAIツール。個人情報や機密情報を含まない場合に限り、ブラウザ閲覧のみ許可。
• ランクC（原則禁止）: 運営元が不明瞭なアプリや、データ処理の規約が確認できないサービス。

2.2 学習データ利用のオプトアウト確認手順

AIツールを利用する絶対条件は「入力したデータがモデルの学習に再利用されないこと」です。
例えば、OpenAIのAPIを利用する場合、デフォルトでデータは学習に使用されません。一方、Web版のChatGPT（無料版・Plus版）では、設定から「Chat History & Training」をオフにする必要があります。この「設定の証跡」をいつ、誰が確認するかを手順に組み込みます。

2.3 入力可能な情報の定義（機密情報の格付け）

「機密情報はダメ」という表現は曖昧です。社内の情報資産定義に基づき具体例を挙げます。
例えば、以下のような切り分けです。

こうした情報の取り扱いは、AIツールに限らず、既存のクラウドサービス利用基準と整合性を取る必要があります。詳細はSaaSアカウント管理の自動化アーキテクチャに関する記事も参考にしてください。

2.4 API利用とブラウザ版の明確な使い分け

実務担当者には「ブラウザでのチャット利用」と「API経由の利用」の違いを徹底周知します。API利用はデータ保護の観点で安全性が高い一方、ブラウザ版は利便性が高い反面、アカウント管理が漏れやすいという特性があります。

2.5 外部公開用コンテンツ生成のルール

ブログ記事や広告コピーを生成する場合、「AI生成であることの明示が必要か」「権利侵害がないかを確認する最終確認者は誰か」を定義します。生成された内容をそのまま公開せず、必ず人間がファクトチェックを行う工程を義務付けます。

3. 実務に直結する「AI利用申請・承認フロー」の構築

ポリシーが決まっても、申請が面倒であれば形骸化します。自動化を意識したフローを構築しましょう。

3.1 申請フォームに含めるべき必須項目

Google フォームやMicrosoft Forms、またはAppSheetなどを活用して、以下の項目を収集します。

• 利用するAIサービス名とURL
• 利用目的（例：コードのリファクタリング、議事録作成）
• 扱うデータの種類（個人情報が含まれるか否か）
• オプトアウト設定（学習オフ）が完了していることを示すスクリーンショットの添付

こうした業務DXの基盤作りについては、Google Workspace × AppSheet 業務DX完全ガイドが非常に役立ちます。

3.2 承認権限の移譲：現場とシステム部門の役割

すべての申請をIT部門が精査するとボトルネックになります。低リスクな案件は「部門長承認」で完結させ、未知のツールや大量のデータを扱う案件のみ「IT・法務審査」に回すといった、リスクに応じたルーティングを設計してください。

3.3 定期的な監査と利用ログの保存方法

法人向けプランであれば、管理画面から誰がいつアクセスしたかのログが取得可能です。半期に一度、利用状況を見直し、退職者のアカウントが残っていないか、ポリシーに反する使い方がされていないかを点検します。

4. 開発会社との契約・責任分界点（SLAと瑕疵担保）

開発会社とAI利用ポリシーを作る際、最も重要なのは契約面での合意です。

4.1 コード生成AIの利用に関する合意

開発会社がGitHub Copilot等の支援ツールを使うことを認める代わりに、以下の遵守を求めます。

• オープンソースライセンス（GPL等）に抵触するコードが混入しないよう、フィルター機能を有効にすること。
• 生成されたコードに対しても、従来通り人間によるコードレビューとユニットテストを必須とすること。

4.2 生成物の権利帰属と侵害保証の範囲

万が一、AIが生成したコードが第三者の著作権を侵害していた場合、誰が責任を負うのか。基本的には「開発会社が納品物の責任を持つ」という原則を維持しつつ、AI特有の不可抗力的な側面をどう免責するか（あるいはしないか）を個別に議論します。

4.3 秘密保持契約（NDA）へのAI特約の追加

「提供された情報を第三者のAI学習に利用させてはならない」という一文をNDAや基本契約に追加することを推奨します。これにより、開発会社が善意で（あるいは無知により）AIツールに顧客データを投入することを法的に抑制できます。

5. 【比較表】主要AIサービスのセキュリティ・学習仕様

ポリシー策定時に参照すべき、主要ツールの仕様比較表です（2024年時点の公表情報に基づく）。

※料金や仕様は頻繁にアップデートされるため、最終判断は必ず各社の公式Trust Centerまたは料金ページを確認してください。

6. ポリシー浸透のための「禁止リスト」ではない「推奨プロンプト」

「あれダメ、これダメ」と言う代わりに、「こう書けば安全に使える」というテンプレートを社内に配布するのがIT実務者の腕の見せ所です。

6.1 リスクを回避する「匿名化プロンプト」の作法

例えば、顧客からの問い合わせメールに返信案を作らせたい場合、以下のような指示を出します。

推奨プロンプト例：

「以下のメールに対する返信案を作成してください。ただし、文中の[人名][会社名][電話番号]は伏せたままで構成案を作ってください。実際の情報は後で私が手動で埋めます。」

6.2 出力結果のファクトチェック（人間による検証）手順

AIは堂々と嘘をつく（ハルシネーション）ことがあります。特に計算業務や会計、税務に関する内容は危険です。
例えば、会計ソフトとの連携コードを書かせる場合は、必ず実際のデータで検証を行うプロセスが必要です。freee会計のAPI連携術など、複雑なシステムを扱う際は、AIを「ヒント」として使い、最終的なロジック検証は実務担当者が担保するという姿勢を徹底します。

7. まとめ：アップデートし続けるポリシー運用のコツ

生成AIの利用ポリシーは、一度作って終わりではありません。3ヶ月に一度は「新機能が追加されていないか」「より安全なツールが出ていないか」を見直す必要があります。

成功のポイント：

• 「禁止」よりも「安全な手順」を明示する。
• 開発会社とは契約レベルでAI利用のルールを握る。
• 申請フローを簡略化し、シャドーAIを防ぐ。
• 最新の公式ドキュメントを常に参照し、ランク付けを更新する。

テクノロジーを遠ざけるのではなく、適切なガードレールを設けて並走すること。それが、これからのIT実務担当者に求められる「守りながら攻める」姿勢です。