生成AIの社内ルールの作り方|何を決め、誰が確かめ、誰が責任を持つか

生成AIの社内ルールに書く項目を、IPAや総務省・経産省などの公的資料をもとに整理。入力してはいけない情報、出力の確かめ方、責任者の決め方、ひな形の入手先まで、CTO代行の視点でやさしく解説します。

執筆者
執筆者執筆者

運営者・AIエンジニア / IT歴36年以上

生成AIの社内ルールの作り方|何を決め、誰が確かめ、誰が責任を持つか

要約

  • 社内ルールは、「使ってよい範囲」「入力しない情報」「出力の確かめ方」の3つを決めるところから始める
  • AIの答えは間違うことがある。誰が確かめ、誰が最終判断をするかを、あらかじめ名前で決めておく
  • ゼロから作らなくてよい。IPAの手引きとJDLAのひな形を土台にして、自社の仕事に合わせて直す

なぜ、生成AIの社内ルールが必要なのか

ChatGPTのような生成AI(文章や画像などを、指示に応じて作るAI)を、社員が自分の判断で使い始める会社が増えています。便利な道具ですが、ルールがないまま広がると、困ったことが起きやすくなります。

IPA(情報処理推進機構)の「テキスト生成AIの導入・運用ガイドライン」は、ガイドラインがないと、使い方を各自が自己判断するしかなくなると指摘しています。その結果、個人情報を入力して漏らしてしまったり、使い方が分からずに使うのをやめてしまったりするおそれがあります。

しかも、決めていない会社は少なくありません。同じ資料で紹介されているJIPDEC「企業IT利活用動向調査2024」(2024年1月実施)では、利用規定やガイドラインを作った企業の割合は次のとおりでした。

  • 会社で作った、または契約した生成AIを使う企業:68.6%
  • 社員が自分で契約・登録した生成AIを使う企業:9.0%

社員が自分で登録して使っているケースほど、ルールが整っていません。会社が把握していないところで使われるので、なおさら先に決めておく必要があります。

私はCTO代行・技術顧問として、社内に技術の責任者がいない会社の相談を受けています。生成AIの相談でも、最初に決めるべきことは同じです。「何を入れてよいか」と「出てきた答えを誰が確かめるか」です。

社内ルールに書く項目は4つ

IPAのガイドライン(第4章 4.1.2「利活用ガイドラインに記載すべき項目」)をもとに、最低限書いておきたい項目を整理します。

1. 使ってはいけない使い方(利用制限)

まず、次のような使い方は禁止と書きます。

  • 法律に反する行為を助ける使い方
  • 他の人の権利を侵すもの
  • うその情報、なりすまし、詐欺を目的とした使い方

そのうえで、次の仕事では使ってよいかどうかを、会社として決めるように勧められています。

  • お客様の情報や機密情報を扱う仕事
  • まだ外に出していない情報を扱う仕事
  • 仕事とは関係のない目的での使用

2. 入力しない情報(入力制限)

AIに入れた文章は、サービスによっては「学習データ」に使われます。学習データとは、AIが賢くなるために読み込むデータのことです。IPAの資料は、入力した指示(プロンプト)が学習に使われると、他の人が作った答えの中にその情報が出てくるおそれがある、と説明しています。

入力しないほうがよい情報として、IPAは次の3つを挙げています。

  • 著作権で守られている情報
  • 個人情報(名前、住所、電話番号など)
  • 組織の機密情報(社内文書や、秘密保持契約を結んだ相手から受け取った情報)

なお、個人情報保護委員会の説明では、入力した情報をAIの精度向上に使うサービスがあります。そこへ個人データを入力すると、利用者からサービス提供者へ個人データを渡したことになります。

個人データを第三者に渡すときは、原則として、あらかじめ本人の同意が必要です。根拠は個人情報保護法の第27条と第28条です。使う前に、そのサービスの利用規約を読んで確かめるよう、ルールに書いておきましょう。

3. 出力(AIの答え)の扱い方

ルールの中で、いちばん大切なのがここです。IPAは、AIが作ったものについて次の点を確かめるよう求めています。

  • 誤りがないか:AIは、事実と違うことや存在しない情報を、もっともらしく答えることがあります。これを「ハルシネーション」といいます。常に正しいかどうかを確かめます
  • 偏りがないか:特定の見方に寄っていないか、人を傷つける表現がないかを見ます
  • 出どころを示したか:生成AIで作ったことを明らかにし、情報の出どころを示します
  • 他人の権利を侵していないか:著作権、商標権、意匠権を侵していないか、うその個人情報や名誉を傷つける内容がないかを確かめます
  • 商売に使ってよいか:サービスの利用規約で、商用利用が制限されている場合があります

著作権については、文化庁の資料が参考になります。AIの作ったものが他人の著作権の侵害になるかは、既存の作品と「似ているか」と、「もとにしたといえるか」の両方で判断されます。使う人が既存の作品を知っていて、その表現を含むものを作らせたときは、使う人の侵害になると考えられています。

たとえば、作品そのものや作品名を入力する場合です。使う人がその作品を知らなくても、AIの学習データに含まれていて似たものが出たときは、侵害になりうると考えられています。ただし、この資料は法的な拘束力のない「考え方」を示したものです。個別の判断は、弁護士などの専門家に相談してください。

4. 使い方の伝え方(例と教育)

ルールは、書くだけでは使われません。IPAは、指示文(プロンプト)の書き方の見本をガイドラインにのせること、そして定期的な周知を勧めています。周知の方法は、eラーニング、効果的な指示文の共有、有志のチームづくりなどです。

「誰が確かめ、誰が責任を持つか」を決める

ルールの項目より、ここで迷う会社が多いと感じます。AIの答えが間違っていたとき、誰の責任なのでしょうか。

総務省・経済産業省の「AI事業者ガイドライン(第1.1版)」は、AIを使う側(AI利用者)に次のことを求めています。法的な拘束力はありませんが、考え方の土台になります。

  • AIの答えの正確さと、リスクの大きさを理解したうえで使う
  • 指示文に含まれる偏りに気をつけ、責任を持って、答えを仕事に使うかどうかを判断する
  • 個人情報や機密情報を、うっかり入力しない
  • AIの答えを事業の判断に使ったときは、関係する人に、無理のない範囲で情報を伝える
  • AIの答えを、特定の人や集団の評価の参考にするときは、AIを使っていることをその人に知らせる。人間が合理的に判断し、求められたら説明する

つまり、最終判断は、AIではなく人間がするという考え方です。自社のルールにも、次の3つを名前つきで書きましょう。

  1. 確かめる人:AIの答えを、仕事に使う前に確認する人(多くは、その仕事を担当する本人)
  2. 判断する人:確認したうえで、使うかどうかを決める人(上司や、その分野の責任者)
  3. 問い合わせを受ける人:お客様や取引先から質問が来たときに、説明する窓口

IPAは、会社の中の役割を「導入担当」「運用担当」「セキュリティ担当」の3つに分けています。導入を進める人、ガイドラインを決めて広める人、リスクを調べて対策する人です。小さな会社では、一人が兼ねても構いません。大切なのは、名前が決まっていることです。

確かめ方の具体例:私が実際にやっている手順

「確かめる」と言っても、何をすればよいか分からない、という声をよく聞きます。私が普段やっている手順を紹介します。

AIが書いたプログラムは、必ず自動のチェック(型のチェックなど)を通し、実際のデータで結果を突き合わせます。文章や情報は、AIが示した内容の根拠を、もとの資料までさかのぼって確認します。とくに、数字と固有名詞は、AIの答えをそのまま信じません。

以前、AIが作ったプログラムを、そのまま本番に反映しかけたことがあります。例外的なケースの考慮が抜けていたのですが、本番に近いデータで試したところ、想定外のエラーが出て気づけました。「動いているように見える」ことと、「正しい」ことは別です。この経験から、実データで試してから反映するようにしています。

法律や制度の分野では、もっと慎重になります。税理士事務所や行政書士事務所のお手伝いをしていると、AIが古くなった法律やルールをもとに、誤った答えを返す場面に出会います。だからこそ、最後は税理士や行政書士の先生が確認する必要があります。ある支援先の税理士事務所では、AIには決まった形の帳簿入力と、ルールに沿った計算だけを任せています。制度が変わったときの対応や、お客様ごとの事情の判断は、必ず人間が行うようにしましょう。

自社のルールでも、「AIに任せてよい仕事」と「必ず人が判断する仕事」を分けて書くと、迷いがなくなります。

ひな形を使えば、ゼロから作らなくてよい

ルールの文章を一から作る必要はありません。日本ディープラーニング協会(JDLA)が、生成AIの利用ガイドラインのひな形を公開しています。第1版は2023年5月、第1.1版は2023年10月、画像編は2024年2月に公開されました。

形式は、「作成にあたって」の資料、「条項のみ」の版、「簡易解説付き」の版の3種類です。修正して自社用にできます。

進め方の目安は、次のとおりです。

  1. ひな形を読み、自社の仕事に合わない条文に印をつける
  2. 上で説明した4項目と照らし合わせ、足りない部分を足す
  3. 「確かめる人・判断する人・窓口」に、実際の名前を入れる
  4. 社員に説明し、うまい指示文の例も一緒に配る

就業規則との関係や、契約にかかわる個別の判断は、社会保険労務士や弁護士に相談してください。

よくある質問

Q: 社員が個人のアカウントで使っている場合も、ルールは必要ですか?

必要です。むしろ優先度が高いです。先ほどの調査では、社員が自分で登録した生成AIを使う企業でルールを作っていたのは9.0%でした。会社が使い方を把握できないので、入力してはいけない情報と、使う前に利用規約を確認することを、最初に決めてください。

Q: AIが間違った答えを出して、それを使ってしまったら、責任は誰にありますか?

AI事業者ガイドラインは、AIを使う側が、責任を持って答えを仕事に使うかどうかを判断するよう求めています。「AIがそう言ったから」は、理由になりにくいと考えてください。ただし、個別の法的な責任は状況によって変わります。トラブルが起きたときは、弁護士に相談してください。

Q: ルールは最初から完璧に作る必要がありますか?

いいえ、その必要はありません。まず、使ってよい範囲、入力しない情報、答えを確かめる人の3つを決めれば、始められます。AIのサービスも法律の考え方も変わっていくので、定期的に見直す前提で作るほうが実用的です。

まとめ

生成AIの社内ルールで決めることは、次の3つに整理できます。

  • 何に使ってよいか、何を入力してはいけないか
  • AIの答えを、誰が、どうやって確かめるか
  • 最終判断と、お客様への説明を、誰が担うか

ひな形や公的な手引きが公開されているので、ゼロから悩む必要はありません。それでも、「自社の場合はどこまで決めればよいか」「確かめる仕組みをどう作るか」で手が止まることは多いものです。

PH Tech AIでは、社内に技術の責任者がいない会社のために、CTO代行・技術顧問として、AIの使い方のルールづくりと確認の仕組みづくりを支援しています。CTO代行が何をしてくれる仕事なのかは、CTOがいない会社の技術判断は、CTO代行という選択肢で変わるで説明しています。まずは無料相談で、現在の使われ方と、決めるべきことを一緒に整理しましょう。

参考・出典

この記事を書いた人

執筆者
執筆者

運営者 / AIエンジニア(IT歴36年以上)

  • ●IT歴36年以上
  • ●IBM認定 生成AIエンジニア
  • ●神田昌典氏 認定ライセンシー
  • ●中小企業・スタートアップのCTO代行・技術顧問

IT歴36年以上の運営者です。長年の実務経験と最新の生成AIを掛け合わせ、中小企業・スタートアップが技術の意思決定に自信を持てるよう、現場目線で記事を書いています。

ライバルはAIで進化中!

あなたのビジネスは大丈夫?

関連記事

他社システムの引継ぎで失敗しない進め方|資料がない状態からの手順
システム設計・技術選定

他社システムの引継ぎで失敗しない進め方|資料がない状態からの手順

前任者や委託先が抜け、資料がほとんど残っていない他社システムの引継ぎを任された方へ。属人化のリスクと、最初に何をすべきかを、CTO代行としての実体験を交えて解説します。

2026/9/27

システム開発の見積もりは妥当か、工数の内訳から確かめる方法
CTO代行・技術顧問

システム開発の見積もりは妥当か、工数の内訳から確かめる方法

システム開発を発注した会社から出てきた見積もりは妥当でしょうか。設計・実装・テスト・保守運用という工数の内訳を、公開されている統計データの目安と照らし合わせれば確かめられます。中小企業・スタートアップの技術判断を支援する立場から、その方法を解説します。

2026/9/23

CTOがいない会社の技術判断は、CTO代行という選択肢で変わる
CTO代行・技術顧問

CTOがいない会社の技術判断は、CTO代行という選択肢で変わる

開発会社の見積もりが妥当か、エンジニアの採用で何を見ればよいか、AI導入は何を確認すべきか。中小企業・スタートアップの経営者が一人で抱えがちなこうした判断を相談できるCTO代行という選択肢と、選ぶときの失敗例を、中小企業・スタートアップの技術の判断を支援する立場から解説します。

2026/9/22

Webスクレイピングが「違法」になりかけた、建築業のAI入札システム
実務ケース

Webスクレイピングが「違法」になりかけた、建築業のAI入札システム

2026年7月ごろ、建築業のお客様から、入札情報をAIで解析し判断・自動化・データベース化するシステムの相談を受けました。データの取得方法がWebスクレイピングだったため法的リスクを指摘し、提供元のAPIへの切り替えと、Supabaseでの構造化データ・ベクトルデータのハイブリッド検索への再設計を提案しました。

2026/9/22

技術者がいない会社には、あえてNext.jsを勧めなかった話
実務ケース

技術者がいない会社には、あえてNext.jsを勧めなかった話

技術者が社内にいない会社に対して、あえて高度な技術ではなく、複数人でも扱いやすいWordPressでの作り直しを提案した経験です。

2026/9/20

「WordPressはSEOに強い」という思い込みを正した話
実務ケース

「WordPressはSEOに強い」という思い込みを正した話

「WordPressを使っていればSEOに強い」と信じ込んでいた知人の起業家に、実際には表示速度がSEOに不利に働くことがあると説明し、2つの改善策を提案した経験です。

2026/9/20