<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>AIガイドライン | 週末起業ラボ</title>
	<atom:link href="https://shumatsu-lab.com/tag/ai%E3%82%AC%E3%82%A4%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3/feed/" rel="self" type="application/rss+xml" />
	<link>https://shumatsu-lab.com</link>
	<description>本業の隣で、もう一つのキャリアを</description>
	<lastBuildDate>Wed, 03 Jun 2026 23:16:23 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.0</generator>

<image>
	<url>https://shumatsu-lab.com/wp-content/uploads/2026/02/cropped-IMG_2742-32x32.jpeg</url>
	<title>AIガイドライン | 週末起業ラボ</title>
	<link>https://shumatsu-lab.com</link>
	<width>32</width>
	<height>32</height>
</image> 
<site xmlns="com-wordpress:feed-additions:1">252581404</site>	<item>
		<title>社内AIガイドライン作成前に決めること｜SE視点の5論点</title>
		<link>https://shumatsu-lab.com/ai-guideline-prep-checklist/</link>
		
		<dc:creator><![CDATA[ムラサキ]]></dc:creator>
		<pubDate>Sun, 17 May 2026 01:24:46 +0000</pubDate>
				<category><![CDATA[AI]]></category>
		<category><![CDATA[AIガイドライン]]></category>
		<category><![CDATA[SE]]></category>
		<category><![CDATA[情報セキュリティ]]></category>
		<category><![CDATA[生成AI]]></category>
		<guid isPermaLink="false">https://shumatsu-lab.com/?p=1594</guid>

					<description><![CDATA[「これAIに入れていい？」とメンバーから聞かれた瞬間に、その場で答えられないと現場は止まる。SEマネージャーとして20年現場を見てきた筆者の実感だ。逆に「ダメだと思ってました」で、許可されているはずのAI活用が止まってい [&#8230;]]]></description>
										<content:encoded><![CDATA[<div class="slb slb-tldr">
  <div class="slb-tldr__head">
    <span class="slb-mono slb-tldr__label">TL;DR / 三行要約</span>
          <span class="slb-mono slb-tldr__meta">8分 MIN READ · UPDATED 2026-05-13</span>
      </div>
  <ol>
          <li>社内AIガイドラインを作る前に決めるべき5論点を、SEマネージャー視点で整理。</li>
          <li>ツール選定・入力データ分類・外部連携・運用・教育までを一気通貫で押さえる。</li>
          <li>経産省AI事業者ガイドライン第1.2版（2026年3月）とJDLAひな形を踏まえた判断軸つき。</li>
      </ol>
    <div class="slb-tldr__badges">
          <span class="slb-badge slb-badge--hi">
        RESULT — 提案準備      </span>
          <span class="slb-badge">
        TOOL — 公的資料＋企業事例      </span>
          <span class="slb-badge">
        COST — 0円      </span>
      </div>
  </div>
    



<p class="wp-block-paragraph">「これAIに入れていい？」とメンバーから聞かれた瞬間に、その場で答えられないと現場は止まる。SEマネージャーとして20年現場を見てきた筆者の実感だ。逆に「ダメだと思ってました」で、許可されているはずのAI活用が止まっていることも珍しくない。組織を底上げするなら、禁止と推奨の両方を明文化したガイドラインが必要になる。</p>



<p class="wp-block-paragraph">この記事は、社内AIガイドラインを「これから作る／提案する」担当者向けの事前整理メモだ。経産省・総務省の<a rel="noopener" href="https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html" target="_blank">AI事業者ガイドライン第1.2版</a>（2026年3月31日公表）と、<a rel="noopener" href="https://www.jdla.org/document/" target="_blank">JDLAの生成AI利用ガイドラインひな形</a>、それに公開事例を踏まえて、書き始める前に決めておきたい論点を5つに絞った。</p>



<div class="wp-block-cocoon-blocks-balloon-ex-box-1 speech-wrap sb-id-1 sbs-stn sbp-l sbis-cb cf block-box not-nested-style cocoon-block-balloon"><div class="speech-person"><figure class="speech-icon"><img decoding="async" src="https://shumatsu-lab.com/wp-content/uploads/2026/03/murasaki_icon.png" alt="ムラサキ" class="speech-icon-image"/></figure><div class="speech-name">ムラサキ</div></div><div class="speech-balloon">
<p class="wp-block-paragraph">SE歴20年・現役SEマネージャーの筆者も、まさに今ガイドライン整備を提案しようとしている当事者。良いところだけ知って情報漏洩リスクを知らないまま使う層と、推奨環境なのに「ダメだと思って」止まる層の両方を見てきた感覚で書いた。</p>
</div></div>




  <div id="toc" class="toc tnt-number toc-center tnt-number border-element"><input type="checkbox" class="toc-checkbox" id="toc-checkbox-2" checked><label class="toc-title" for="toc-checkbox-2">目次</label>
    <div class="toc-content">
    <ol class="toc-list open"><li><a href="#toc1" tabindex="0">なぜ今、社内AIガイドラインが必要なのか</a><ol><li><a href="#toc2" tabindex="0">生成AI活用拡大で顕在化したリスク</a></li><li><a href="#toc3" tabindex="0">ガイドライン未整備で起こる情報漏洩・著作権トラブル</a></li><li><a href="#toc4" tabindex="0">中小企業・個人事業主にも他人事ではない理由</a></li></ol></li><li><a href="#toc5" tabindex="0">ガイドライン作成前に決めるべき5つの基本方針</a><ol><li><a href="#toc6" tabindex="0">AI利用の目的と適用範囲の明確化</a></li><li><a href="#toc7" tabindex="0">利用を許可するAIツールの選定基準</a></li><li><a href="#toc8" tabindex="0">禁止行為と機密情報の取り扱いルール</a></li></ol></li><li><a href="#toc9" tabindex="0">実務で押さえるべきリスク管理項目</a><ol><li><a href="#toc10" tabindex="0">入力してはいけないデータの線引き</a></li><li><a href="#toc11" tabindex="0">生成物の著作権・商用利用の判断基準</a></li><li><a href="#toc12" tabindex="0">ハルシネーション対策とファクトチェック体制</a></li></ol></li><li><a href="#toc13" tabindex="0">現場が守れるガイドラインにする工夫</a><ol><li><a href="#toc14" tabindex="0">禁止だらけにしない「推奨利用」の設計</a></li><li><a href="#toc15" tabindex="0">部署別・業務別のユースケース整理</a></li><li><a href="#toc16" tabindex="0">違反時の対応フローと相談窓口</a></li></ol></li><li><a href="#toc17" tabindex="0">運用を続けるための仕組みづくり</a><ol><li><a href="#toc18" tabindex="0">定期的な見直しサイクルの設定</a></li><li><a href="#toc19" tabindex="0">従業員教育と社内勉強会の進め方</a></li><li><a href="#toc20" tabindex="0">AI活用事例の社内共有とアップデート</a></li></ol></li><li><a href="#toc21" tabindex="0">明日から動ける具体的なアクションプラン</a><ol><li><a href="#toc22" tabindex="0">ガイドライン草案テンプレートの活用</a></li><li><a href="#toc23" tabindex="0">経営層と現場の合意形成ステップ</a></li><li><a href="#toc24" tabindex="0">スモールスタートで運用を始めるコツ</a></li></ol></li><li><a href="#toc25" tabindex="0">よくある質問</a></li><li><a href="#toc26" tabindex="0">まとめ</a></li></ol>
    </div>
  </div>

<h2 class="wp-block-heading"><span id="toc1">なぜ今、社内AIガイドラインが必要なのか</span></h2>



<p class="wp-block-paragraph">ChatGPT・Claude・Geminiが業務に入り込む速度は、社内ルール整備のスピードを追い越している。エンジニアだけでなく営業・人事・経理まで使い始めた段階で、「明文化されたルールがない」状態は事故待ちに近い。</p>



<h3 class="wp-block-heading"><span id="toc2">生成AI活用拡大で顕在化したリスク</span></h3>



<p class="wp-block-paragraph">リスクは大きく3つに整理できる。情報漏洩（機密データの学習利用・サーバー残留）、著作権・契約違反（顧客情報の入力・生成物の権利関係）、誤情報による業務判断ミス（ハルシネーション）。経産省の<a rel="noopener" href="https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html" target="_blank">AI事業者ガイドライン第1.2版</a>では、AIエージェントやマルチモーダル生成AIの普及で入力経路と外部連携が増え、データ汚染や悪意あるプロンプト攻撃の対象範囲が広がると整理されている。</p>



<p class="wp-block-paragraph">特に2026年3月版でフォーカスが移ったのは「AIエージェントが自律的に外部システムへアクションする場合」のリスクだ。読み取りだけでなく、書き込み・実行までAIに任せる構成が一般化しつつある今、従来の「入力データを気をつける」だけのルールでは不十分になる。</p>



<h3 class="wp-block-heading"><span id="toc3">ガイドライン未整備で起こる情報漏洩・著作権トラブル</span></h3>



<p class="wp-block-paragraph">ルールが曖昧なまま運用されると、典型的にはこういう事故が起きる。社員が顧客データをそのまま個人アカウントのChatGPTに貼り付ける。AIにGoogle Driveを連携したら、見せるつもりのなかったファイルまで読まれる。業務利用の可否を確認しないまま、新しいAIツールを使い始める。</p>



<p class="wp-block-paragraph"><a rel="noopener" href="https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/" target="_blank">個人情報保護委員会の生成AI注意喚起</a>は、個人情報を含むプロンプト入力が利用目的の範囲に収まっているか、入力データが機械学習に使われない設定になっているかを事業者に確認するよう求めている。個人情報の入力自体がただちに違法というわけではないが、確認なしの入力は規約・法令の両面でグレーになりやすい。</p>



<h3 class="wp-block-heading"><span id="toc4">中小企業・個人事業主にも他人事ではない理由</span></h3>



<p class="wp-block-paragraph">「うちは小さいから関係ない」とは言えない。クライアントワークがある会社なら、顧客のAI利用規定が自社の利用範囲を縛る。受託案件で「生成AIへの入力禁止」と契約に書かれているのに、社員が知らずに使ってしまえば契約違反だ。副業・週末起業のフリーランスも、自分用のミニガイドラインを持っておくと取引先からの問い合わせに即答できる。</p>



<h2 class="wp-block-heading"><span id="toc5">ガイドライン作成前に決めるべき5つの基本方針</span></h2>



<p class="wp-block-paragraph">ガイドライン本文を書き始める前に、社内で合意しておくべき土台が5つある。ここを飛ばすと、書いている途中で「そもそもの方針が違う」となって戻り作業が発生する。</p>



<figure class="wp-block-table"><table><thead><tr><th>論点</th><th>決めること</th><th>参照すべき先</th></tr></thead><tbody><tr><td>① 目的・適用範囲</td><td>誰が、どの業務で、何のために使うか</td><td>経営層・法務</td></tr><tr><td>② ツール選定基準</td><td>利用可・申請制・禁止の分類軸</td><td>情シス・セキュリティ</td></tr><tr><td>③ 入力データの線引き</td><td>入れていい情報・だめな情報</td><td>法務・各事業部</td></tr><tr><td>④ 外部連携の扱い</td><td>読み取り／書き込み／実行の権限</td><td>情シス・OWASP参考</td></tr><tr><td>⑤ 運用体制</td><td>見直しサイクル・教育・相談窓口</td><td>人事・情シス</td></tr></tbody></table></figure>



<h3 class="wp-block-heading"><span id="toc6">AI利用の目的と適用範囲の明確化</span></h3>



<p class="wp-block-paragraph">「業務効率化のため」だけでは粒度が粗すぎる。①議事録要約、②コード生成、③営業文書ドラフト、④顧客対応の下書き──のように、想定ユースケースを先に列挙しておくと、後段の「入れていい情報」と接続しやすい。適用範囲も「全社員」か「特定部署」か「業務委託まで含むか」を最初に決める。</p>



<h3 class="wp-block-heading"><span id="toc7">利用を許可するAIツールの選定基準</span></h3>



<p class="wp-block-paragraph">ツールは「使ってよい／だめ」の2分類だと現場が詰む。3分類が標準だ。</p>



<ul class="wp-block-list">
<li>全社標準：会社契約アカウント＋オプトアウト設定済み（入力データがAIの学習に使われない設定。例：ChatGPT Enterprise、Claude Team）- 個別利用：目的を明確化した申請ベースで承認（例：特定業務に必要な専門AI）</li>



<li>利用禁止：セキュリティ要件未達・オプトアウト不可など理由を明示</li>
</ul>



<p class="wp-block-paragraph">X-Tech5の<a rel="noopener" href="https://x-tech5.co.jp/generative_ai_guideline/" target="_blank">生成AI利用ガイドライン</a>はこの3分類が具体的で参考になる。DeepSeekはセキュリティ理由で禁止、Genspark Speaklyはオプトアウト不可で禁止、と「なぜ禁止か」まで書かれている点も実務で効く。理由が書かれていないと、現場は「次に出てきた新ツールはどう判断するか」を毎回上申することになる。</p>



<h3 class="wp-block-heading"><span id="toc8">禁止行為と機密情報の取り扱いルール</span></h3>



<p class="wp-block-paragraph">禁止だけを並べたガイドラインは形骸化する。後段の「現場が守れるガイドラインにする工夫」で詳述するが、禁止リストと同じ分量で「推奨される使い方」を書くのが現実解だ。機密情報の扱いは次のセクションで深掘りする。</p>



<h2 class="wp-block-heading"><span id="toc9">実務で押さえるべきリスク管理項目</span></h2>



<h3 class="wp-block-heading"><span id="toc10">入力してはいけないデータの線引き</span></h3>



<p class="wp-block-paragraph"><a rel="noopener" href="https://tech.smarthr.jp/entry/2023/04/14/161428" target="_blank">SmartHRのAIサービス利用方針</a>が分かりやすい分類を公開している。情報の種類ごとに、利用可否・申請要否・許容サービスを分ける考え方だ。</p>



<figure class="wp-block-table"><table><thead><tr><th>情報の種類</th><th>申請なし利用</th><th>申請ありで利用</th><th>利用不可</th></tr></thead><tbody><tr><td>公開情報</td><td>○</td><td>─</td><td>─</td></tr><tr><td>業務情報・秘密情報</td><td>×</td><td>学習利用されないサービスのみ ○</td><td>─</td></tr><tr><td>個人情報</td><td>×</td><td>学習利用されないサービスのみ ○</td><td>─</td></tr><tr><td>重要な秘密情報</td><td>×</td><td>×</td><td>○</td></tr><tr><td>特定個人情報（マイナンバー等）</td><td>×</td><td>×</td><td>○</td></tr></tbody></table></figure>



<p class="wp-block-paragraph">ポイントは「機密情報は一律禁止」にしないこと。一律禁止にすると、現場は「結局何も入れられない」となり、AI活用そのものが止まる。学習に使われない設定のサービスに限定したうえで、申請ベースで利用可とする設計にすると、現場の判断コストが下がる。</p>



<p class="wp-block-paragraph">入力時の運用ルールとして、個人情報・機密情報はマスキング（匿名化・抽象化）を原則にする会社もある。マスキングで精度が落ちすぎる場合に限り、学習利用されないサービス＋必要最小限の入力＋承認、という条件付きで非マスキング利用を認める二段構えだ。</p>



<h3 class="wp-block-heading"><span id="toc11">生成物の著作権・商用利用の判断基準</span></h3>



<p class="wp-block-paragraph">生成物は「著作権が誰に帰属するか」「商用利用してよいか」が利用規約で決まる。OpenAI・Anthropic・Googleは商用利用を許容しているが、画像生成系（特に学習データに既存作品を含むモデル）は別判断が必要だ。JDLAは2024年に<a rel="noopener" href="https://www.jdla.org/news/20240213001/" target="_blank">生成AIの利用ガイドライン（画像編）</a>を別途公開している。画像生成を業務で使う予定があるなら、最初から画像編も併せて参照しておくと後で揉めない。</p>



<h3 class="wp-block-heading"><span id="toc12">ハルシネーション対策とファクトチェック体制</span></h3>



<p class="wp-block-paragraph">AIの誤情報を業務判断に持ち込まないための仕組みも明文化する。「AI生成のドラフトは必ず人間がレビュー」「数値・固有名詞・URLは元ソースで再確認」「最終アウトプットの責任は利用者」の3つを最低ラインにしておくと、後から問題が起きたときの責任所在が明確になる。</p>



<p class="wp-block-paragraph">筆者の実感として、AI出力の検証スキルは座学では身につかない。実際にAIに何かを書かせて、それをレビューする訓練を繰り返すのが近道で、組織全体の底上げにはAI禁止ではなく<a href="https://shumatsu-lab.com/ai-skills-youth-education/">AI出力レビュー訓練</a>のような実践型の教育が効く。</p>



<h2 class="wp-block-heading"><span id="toc13">現場が守れるガイドラインにする工夫</span></h2>



<p class="wp-block-paragraph">ここが本記事で一番伝えたい論点だ。禁止だらけのガイドラインは、現場で守られないし、AI活用そのものを萎縮させる。</p>



<h3 class="wp-block-heading"><span id="toc14">禁止だらけにしない「推奨利用」の設計</span></h3>



<p class="wp-block-paragraph">筆者が現場で何度も見たパターンに、「セキュアで推奨されている環境なのに、ダメだと思ってました」で止まっている社員がいる。良い機能だけ知って使ってしまう層も問題だが、ルールが分からず使わない層も同じくらい組織の足かせになる。</p>



<p class="wp-block-paragraph">ガイドラインは「禁止リスト」と「推奨ユースケース集」をセットで持つのが現実解だ。「議事録要約は推奨ツールAで○」「コード生成は推奨ツールBで○・ただし機密ロジックは要マスキング」のように、具体的なユースケース単位で「このやり方ならOK」を書く。現場は禁止ラインを覚えるより、推奨パターンを真似する方が早い。</p>



<h3 class="wp-block-heading"><span id="toc15">部署別・業務別のユースケース整理</span></h3>



<p class="wp-block-paragraph">全社一律のルールだけでは粒度が粗すぎる。営業の議事録、エンジニアのコード、人事の応募者情報、経理の請求書、それぞれリスクの種類も最適なAIツールも違う。部署別のユースケース一覧を1ページで持っておくと、新人配属時の説明コストも下がる。</p>


<div data-slb-context="weekend"><br />
全部のユースケースを最初から網羅しようとすると、ガイドライン公開が永遠に終わらない。まずは利用頻度の高い3〜5パターンから書き始め、運用しながら追加するのが現実的だ。<br />
</div>



<h3 class="wp-block-heading"><span id="toc16">違反時の対応フローと相談窓口</span></h3>



<p class="wp-block-paragraph">「これってやっていい？」と迷ったときに聞ける場所を1つ決めるだけで、ガイドラインの実効性は大きく変わる。情シス窓口・Slackの専用チャンネル・週1の質問会、どれでもいい。重要なのは「迷ったら聞いていい」「聞いた人は責められない」の文化を作ることだ。</p>



<p class="wp-block-paragraph">違反が起きた場合の対応も、いきなり懲戒ではなく「①事象確認→②原因分析→③再発防止策→④必要に応じて教育」の段階的フローを明文化しておく。「最初から罰則」のスタンスだと、隠蔽が起きてかえってリスクが上がる。</p>



<h2 class="wp-block-heading"><span id="toc17">運用を続けるための仕組みづくり</span></h2>



<p class="wp-block-paragraph">ガイドラインは作って終わりではない。むしろ作ってからが本番だ。</p>



<h3 class="wp-block-heading"><span id="toc18">定期的な見直しサイクルの設定</span></h3>



<p class="wp-block-paragraph">DeNAは半期に一度の改訂を運用している（<a rel="noopener" href="https://engineering.dena.com/blog/2025/08/ai_journey_2/" target="_blank">engineering.dena.com</a>）。生成AIはモデルもツールも数か月で変わるので、年1回では追いつかない。「半期ごと＋大きな変化があれば臨時改訂」をベースにし、改版履歴を残しておけば、過去にどのルールで判断したかが後から追える。</p>



<h3 class="wp-block-heading"><span id="toc19">従業員教育と社内勉強会の進め方</span></h3>



<p class="wp-block-paragraph">LINEヤフーは全従業員にChatGPT Enterpriseを配布したうえで、必須eラーニングと試験合格を利用開始の条件にしている（<a rel="noopener" href="https://www.lycorp.co.jp/ja/news/release/018121/" target="_blank">lycorp.co.jp</a>）。サイバーエージェントの画像生成AIガイドラインも、理解度テスト合格を利用申請の前提にする運用だ（<a rel="noopener" href="https://www.cyberagent.co.jp/way/list/detail/id%3D30017" target="_blank">cyberagent.co.jp</a>）。ここまでやらなくても、利用申請時に「ガイドラインを確認しました」のチェックを必須にするだけで意識づけにはなる。</p>



<p class="wp-block-paragraph">筆者の経験上、座学だけの研修は1か月で忘れられる。月1の社内事例共有会で「先月こんな使い方が上手くいった／こんなNGがあった」を共有する方が定着率が高い。</p>



<h3 class="wp-block-heading"><span id="toc20">AI活用事例の社内共有とアップデート</span></h3>



<p class="wp-block-paragraph">成功事例の横展開もガイドラインの一部だ。「営業部のAさんが商談議事録をこのプロンプトで要約している」「開発部のBさんがコードレビュー前にAIに観点出しさせている」といった事例が共有されると、推奨ユースケース集が現場発で育つ。</p>



<h2 class="wp-block-heading"><span id="toc21">明日から動ける具体的なアクションプラン</span></h2>



<h3 class="wp-block-heading"><span id="toc22">ガイドライン草案テンプレートの活用</span></h3>



<p class="wp-block-paragraph">ゼロから書く必要はない。<a rel="noopener" href="https://www.jdla.org/document/" target="_blank">JDLAの生成AI利用ガイドライン</a>はひな形として公開されており、自社用に追記・修正して使う前提で作られている。条項のみ版と簡易解説付き版があるので、まずは解説付き版を読み、ひな形をベースに自社の業務に合わせて削る／足す方針が早い。</p>



<p class="wp-block-paragraph">経産省<a rel="noopener" href="https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html" target="_blank">AI事業者ガイドライン第1.2版</a>の別添7には、チェックリストとワークシートが付属している。社内ルールの抜け漏れ確認に使いやすいので、ひな形でドラフトを書いたあとの最終チェック用に組み合わせると網羅性が上がる。</p>



<h3 class="wp-block-heading"><span id="toc23">経営層と現場の合意形成ステップ</span></h3>



<p class="wp-block-paragraph">ガイドラインは情シス単独で作ると、経営層に「現場が回らない」と差し戻され、現場主導で作ると、経営層に「リスク対応が甘い」と差し戻される。最初から両方の代表を入れたワーキンググループで作るのが定石だ。</p>



<div class="wp-block-cocoon-blocks-timeline timeline-box cf block-box not-nested-style cocoon-block-timeline"><div class="timeline-title">ガイドライン整備の進め方</div><ul class="timeline">
<li class="wp-block-cocoon-blocks-timeline-item timeline-item cf"><div class="timeline-item-label">ラベル</div><div class="timeline-item-content cf"><div class="timeline-item-title">タイトル</div><div class="timeline-item-snippet"></div></div></li>
</ul></div>



<h3 class="wp-block-heading"><span id="toc24">スモールスタートで運用を始めるコツ</span></h3>



<p class="wp-block-paragraph">完璧なガイドラインを作ろうとすると公開が永遠に遅れる。最初は「使ってよいツール3つ」「入れてはいけない情報3種類」「迷ったらこの窓口」の3点だけ書いた1ページ版から始めるのが現実的だ。運用しながら抜け穴と追加論点が見えてくるので、半年後に正式版へ拡張する。</p>



<div class="wp-block-cocoon-blocks-balloon-ex-box-1 speech-wrap sb-id-1 sbs-stn sbp-l sbis-cb cf block-box not-nested-style cocoon-block-balloon"><div class="speech-person"><figure class="speech-icon"><img decoding="async" src="https://shumatsu-lab.com/wp-content/uploads/2026/03/murasaki_icon.png" alt="ムラサキ" class="speech-icon-image"/></figure><div class="speech-name">ムラサキ</div></div><div class="speech-balloon">
<p class="wp-block-paragraph">完璧主義は活用機会の損失と同義になる。ルールゼロの状態を放置するより、80点の暫定ルールを早く出して動きながら直す方が、組織全体のAIリテラシーは上がる。</p>
</div></div>



<p class="wp-block-paragraph">外注先や副業エンジニアと組む場合は、自社のガイドラインに加えて先方のルールも確認したい。実際に<a href="https://shumatsu-lab.com/make-automation-side-job-guide/">Make経由でAI連携を組む副業フロー</a>のような自動化を組むときも、入力データの線引きを最初に共有しておくと事故が減る。</p>



<h2 class="wp-block-heading"><span id="toc25">よくある質問</span></h2>



<div class="wp-block-cocoon-blocks-faq faq-wrap blank-box block-box cocoon-block-faq"><dl class="faq"><dt class="faq-question faq-item"><div class="faq-question-label faq-item-label">Q</div><div class="faq-question-content faq-item-content">中小企業や個人事業主でも社内AIガイドラインは必要ですか？</div></dt><dd class="faq-answer faq-item"><div class="faq-answer-label faq-item-label">A</div><div class="faq-answer-content faq-item-content">
<p class="wp-block-paragraph">規模に関わらず必要だ。クライアントワークがあるなら、顧客のAI利用規定が自社の利用範囲を縛る。受託契約に「生成AI入力禁止」と書かれているのに知らずに使えば契約違反になる。フリーランスでも1ページのミニガイドラインを持っておくと、取引先からの問い合わせに即答できる。</p>
</div></dd></dl></div>



<div class="wp-block-cocoon-blocks-faq faq-wrap blank-box block-box cocoon-block-faq"><dl class="faq"><dt class="faq-question faq-item"><div class="faq-question-label faq-item-label">Q</div><div class="faq-question-content faq-item-content">ガイドラインのひな形はどこから入手できますか？</div></dt><dd class="faq-answer faq-item"><div class="faq-answer-label faq-item-label">A</div><div class="faq-answer-content faq-item-content">
<p class="wp-block-paragraph">JDLA（日本ディープラーニング協会）が<a rel="noopener" href="https://www.jdla.org/document/" target="_blank">生成AIの利用ガイドライン</a>を無償公開している。条項のみ版と簡易解説付き版があり、自社用に追記・修正して使う前提だ。経産省・総務省の<a rel="noopener" href="https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html" target="_blank">AI事業者ガイドライン第1.2版</a>別添7にはチェックリストとワークシートが付属しており、ひな形を補完する形で使える。</p>
</div></dd></dl></div>



<div class="wp-block-cocoon-blocks-faq faq-wrap blank-box block-box cocoon-block-faq"><dl class="faq"><dt class="faq-question faq-item"><div class="faq-question-label faq-item-label">Q</div><div class="faq-question-content faq-item-content">個人情報をAIに入力するのは違法ですか？</div></dt><dd class="faq-answer faq-item"><div class="faq-answer-label faq-item-label">A</div><div class="faq-answer-content faq-item-content">
<p class="wp-block-paragraph">入力自体がただちに違法というわけではない。<a rel="noopener" href="https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/" target="_blank">個人情報保護委員会の注意喚起</a>では、入力が利用目的の範囲に収まっているか、入力データが機械学習に使われない設定になっているかを確認するよう求めている。確認なしの入力は規約・法令の両面でグレーになりやすいので、社内ルールで明文化しておくのが安全だ。</p>
</div></dd></dl></div>



<div class="wp-block-cocoon-blocks-faq faq-wrap blank-box block-box cocoon-block-faq"><dl class="faq"><dt class="faq-question faq-item"><div class="faq-question-label faq-item-label">Q</div><div class="faq-question-content faq-item-content">AIエージェントを業務に入れる場合、追加で考えることは？</div></dt><dd class="faq-answer faq-item"><div class="faq-answer-label faq-item-label">A</div><div class="faq-answer-content faq-item-content">
<p class="wp-block-paragraph">AIが外部システムへ自律的にアクションを取る場合、読み取り・書き込み・実行のどこまで権限を渡すかを連携単位で判断する必要がある。<a rel="noopener" href="https://genai.owasp.org/llmrisk/llm062025-excessive-agency/" target="_blank">OWASPのExcessive Agency</a>が整理する「過剰な機能・過剰な権限・過剰な自律性」のリスクを参考に、必要最小限の権限から始めるのが安全だ。経産省AI事業者ガイドライン第1.2版でも、AIエージェントの外部アクション時の責任所在と監視要件が明示されている。</p>
</div></dd></dl></div>



<div class="wp-block-cocoon-blocks-faq faq-wrap blank-box block-box cocoon-block-faq"><dl class="faq"><dt class="faq-question faq-item"><div class="faq-question-label faq-item-label">Q</div><div class="faq-question-content faq-item-content">ガイドラインはどのくらいの頻度で見直すべきですか？</div></dt><dd class="faq-answer faq-item"><div class="faq-answer-label faq-item-label">A</div><div class="faq-answer-content faq-item-content">
<p class="wp-block-paragraph">半期に一度が目安だ。DeNAをはじめ複数の企業事例で半期改訂の運用が確認できる。生成AIはモデルもツールも数か月で変わるので、年1回では追いつかない。「半期ごとの定期改訂＋大きな変化があれば臨時改訂」をベースにし、改版履歴を残しておくと過去判断の追跡もできる。</p>
</div></dd></dl></div>



<h2 class="wp-block-heading"><span id="toc26">まとめ</span></h2>



<p class="wp-block-paragraph">社内AIガイドラインを作る前に決めるべきことは、①目的・適用範囲、②ツール選定基準、③入力データの線引き、④外部連携の扱い、⑤運用体制、の5論点に集約できる。禁止と推奨の両方を書き、ひな形ベースでスモールスタートし、半期改訂で育てる。これが現場で機能するガイドラインの最短経路だ。</p>



<p class="wp-block-paragraph">良いところだけ知って情報漏洩リスクを知らないまま使う層と、推奨環境なのに「ダメだと思って」止まる層は、どちらも組織のリテラシー底上げ対象になる。組織全体で底上げするなら、禁止ラインと推奨ユースケースの両輪で設計するのが効く。AI禁止だけでは育たない若手の<a href="https://shumatsu-lab.com/ai-skills-youth-education/">AI出力レビュー力</a>のような観点も、ガイドライン運用のなかで継続的に鍛える設計が必要になる。</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p class="wp-block-paragraph">参考：「これAIに入れていい？」と聞かれる前に、社内AIガイドラインで決めておきたいこと（Misugi Takeru氏／株式会社L&amp;E Group、Zenn）。本記事はこの公開記事の論点整理を出発点に、SEマネージャー視点と公的1次ソース（経産省・総務省・JDLA・個人情報保護委員会・OWASP）の参照で再構成した。<br>元記事URL：https://zenn.dev/linkedge/articles/1ebe85f104726c</p>
</blockquote>
]]></content:encoded>
					
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">1594</post-id>	</item>
	</channel>
</rss>
