少人数チームのためのAI利用ポリシー1ページ：使ってよい、先に相談、禁止

チームリーダー、フリーランス、小さな会社の経営者、数人のチームで仕事にAIを使う人なら誰でも、初心者の方でも読めます。法務やセキュリティの知識は不要です。用語にはどれも身近なたとえを添えています。計算の部分は印をつけてあるので、不要なら読み飛ばせます。

これは法的助言ではありません。 数字は公開情報から取っており、末尾に一覧があります。一部は報道を通じてしか読んでいません。「例」と書いたものは作った例で、実在の人物や会社には触れていません。AIの内部はまだ誰にも完全には分かっていないので、たとえは覚えやすくするための補助です。ひな形は私の実務上の提案で、義務的な基準ではありません。

---

まず要点#

• 少人数チームでは、AIについての決まりがないことがよくあります。Stack Overflow 2026年調査を伝える報道によると、AI利用を個人任せにしている回答者は約29.7%、承認済みツールや正式な方針があると答えた人は約24%でした。報道を通じて読んだ数字です。
• 最大のリスクは、AIが間違えることより、入れてはいけないデータを誰かが貼り付けてしまうことであることが多いです。2023年にBloombergの報道とそれを伝える報道によると、Samsungの従業員が社内のソースコードをChatGPTに入力したと伝えられ、同社は生成AIツールを制限しました。
• 始めるには1ページで足ります。3列（使ってよい、先に相談、禁止）、やさしい言葉で書くデータの4段階、承認済みツールの一覧、AIが書いた変更ごとの責任者1人、事故の手順、見直し日です。
• ポリシーの試し方：先週の実際の作業を20件選び、3列に振り分けます。「先に相談」に入る数が多すぎるなら、厳しすぎるか曖昧すぎます。
• 厳しすぎると抜け道を探され、曖昧だと誰も何をすればよいか分からず、誰も読まなければ無いのと同じです。それぞれの見分け方を示します。
• ポリシーは安全の保証ではありません。やるべきことを明確にし、責任を持つ人を決めるだけです。

---

むずかしい言葉をやさしく#

---

1. まずイメージ：共用キッチンの貼り紙#

6人で使う共用キッチンを思い浮かべてください。分厚い規則集を読みたい人はいません。でも何もなければ、生ものと加熱済みの食べ物に同じまな板を使う人や、期限切れの食品を冷蔵庫に置きっぱなしにする人が出てきます。冷蔵庫の扉に貼った紙1枚で十分です。これは自由に使ってよい、これは先に聞く（たとえば大家さんの圧力鍋）、これは絶対にしない（外出時にガスをつけたままにする）。短い紙は読まれます。見直し日があれば古くなりません。担当者の名前があれば、聞く相手がいます。

少人数チームのAI利用ポリシーも同じです。目的はあらゆる場面を網羅することではなく、よく出る質問に、全員が同じ答えを持てるようにすることです。これをここに貼ってよいか、AIが書いたものを誰が読み直すか、うっかりしたらどうするか。

ここから分かること： 少人数チームにとってよいポリシーは、引き出しの中のバインダーではなく、冷蔵庫の扉の貼り紙です。

---

2. なぜ必要か：データで見る2つのこと#

2.1 ほとんどのチームにはまだ決まりがない（Stack Overflow 2026年調査、報道経由）#

Stack Overflow Developer Survey 2026を伝える報道（IT Brief）によると、職場でのAI利用は任意で個人に任されていると答えた人が約29.7%、雇用主が承認済みツールや正式な方針、ガイダンスを持つと答えた人は約24%にとどまります。この数字は報道を通じて読んだだけで、調査ページの表とは照合していません。標本は回答した人たちで、すべての少人数チームを代表するわけではありません。正確な数字ではなく「ないところがかなりある」と読んでください。

ここから分かること： あなたのチームにポリシーがなくても珍しくはなく、この空白はあなたのところだけの問題ではありません。

2.2 報じられた事例：ソースコードがチャットボットへ（Samsung、2023年）#

2023年5月初めのBloombergの第一報と、それを伝える報道（Forbes、TechRadar）によると、Samsungのエンジニアはソースコードの問題を扱うのにChatGPTを使い、4月ごろに社内のソースコードを入力したと伝えられました。同社はその後、社内のパソコン、スマートフォン、ネットワークでの生成AIツールの利用を制限する通知を出し、会社の知的財産が危険にさらされない限り個人端末では使えるとし、違反は処分の対象になりうると述べました。これらの報道によると、通知は漏れたコードの中身には触れていません。制限が一時的か長期的かについても情報源の間で食い違いがあり、私はBloombergの原文を開けていないので、「報道によると」の範囲にとどめてください。

大事なのは大企業の名前ではありません。腕のよいエンジニアがいる場所で起きたということです。ごく普通の作業（バグをチャットボットに見てもらう）と、ごく普通の習慣（コードを貼る）が重なるだけで起こります。

ここから分かること： リスクはデータを貼るという行為にあり、どのデータを貼ってはいけないかを言い切るルールが要ります。

---

3. 1枚の紙：3列と7つの項目#

冷蔵庫の扉に貼った紙を思い浮かべてください。緑、黄、赤の3列に分け、各列に数行ずつ書きます。

3.1 3列#

• 使ってよい（聞かなくてよい）：承認済みツールを、公開データと社内データで使い、説明、下書き、テスト作成、名前の変更、文書作成などをする。
• 先に相談： 一覧にないツールを使う、顧客データをどのツールにも入れる、エージェントにインストール、削除、デプロイのコマンドを実行させる、顧客がAIを使わないでほしいと言った作業でAIを使う。
• 禁止： キー、パスワード、トークン、実際の個人データを貼る、顧客のデータに個人の無料アカウントを使う、第二の人が読んでおらずチェックも走らせていないAI作成コードをマージする。

3.2 やさしい言葉で書くデータの4段階#

4つの置き場所がある家を思い浮かべてください。

3.3 残りの7項目#

1. 承認済みツール： 名前、アカウントの種類、承認者、日付、データに関する規約を読んだか。
2. 誰が結果を確認するか： AIが書いた変更は、すべて第二の人が読みます。AIの結果に証拠を添えさせる5つの方法の「証拠の求め方」を使うと、読む人が速くなります。
3. 誰が責任を負うか： マージする、または顧客に送る人が答えます。AIが間違えたら、誰が責任を取るかも参照してください。
4. 顧客への伝え方： いつ、何を、契約に沿って伝えるか。
5. 記録： 新しいAI利用は1行だけ。ツール、目的、データの段階。
6. 事故のとき： 第6章の短い手順。
7. 見直し日： 多くの場合90日後ごろ。担当者の名前つき。

3.4 貼って直せるひな形#

チーム[チーム名]のAI利用ポリシー
担当：[名前]    施行日：[日付]    見直し：[日付 + 90日]

使ってよい（聞かなくてよい）
- 下の一覧のツールを、公開データと社内データで使う。
- AIに説明、下書き、テスト作成、名前の変更、文書作成を頼む。

先に相談
- 一覧にないツールを使う。
- 顧客データをどのAIツールにも入れる。
- エージェントにインストール、削除、デプロイを実行させる。
- 顧客がAI不使用を求めた作業でAIを使う。

禁止
- キー、パスワード、トークン、実際の個人データを貼る。
- 顧客のデータに個人の無料AIアカウントを使う。
- 第二の人が読み、チェックを走らせる前にAI作成コードをマージする。

データ：公開 / 社内 / 顧客 / 機密（例は3.2）
承認済みツール：[名前、アカウントの種類、承認者、日付]
責任者：マージする、または顧客に送る人
顧客への伝え方：[いつ、どのように]
記録：新しいAI利用を1行（ツール、目的、データの段階）
事故：止める、1時間以内に報告、したことを書き留める、漏れたらキーを交換、必要なら顧客に伝える

---

4. 6人チームの例（想定）#

これは作った例で、実在の会社には触れていません。契約でソフトウェアを作る6人のチームを思い浮かべてください。数社の顧客を持っています。彼らはひな形を次のように埋めます。

• 承認済みツール： チームの有料サービス1つ。アカウントはリーダーが作成し、承認者がチームのデータを学習に使うかどうかの規約を読んでいます（選んだサービスの実際の規約を読む必要があります）。個人の無料アカウントは一覧に入りません。
• 先に相談： 顧客データに触れる作業すべてと、エージェントにインストールやデプロイを許すたび。
• 顧客への伝え方： 見積書に、チームはコード作成の補助にAIを使うこと、変更はすべて人が読むこと、顧客のデータは同意なしにはツールに入れないことを書きます。
• 見直し： 90日ごと。リーダーが担当。

4.1 試し方：実際の作業20件を3列に振り分ける（想定、読み飛ばし可）#

ポリシーを試す方法：各自が先週AIを使った実際の作業を挙げ、チームで3列に振り分けます。以下の数字は計算しやすいように作ったもので、実測ではありません。

tasks, people, minutes_per_ask = 20, 6, 3
allowed, ask, banned = 12, 6, 2
print(allowed / tasks, ask / tasks, banned / tasks)
# 0.6 0.3 0.1
weekly = tasks * people            # チーム全体で週120件
asks = weekly * ask / tasks        # 相談が36回
minutes = asks * minutes_per_ask   # 108分
print(weekly, asks, minutes, minutes / 60)
# 120 36.0 108.0 1.8

結果の読み方：20件のうち12件（60%）はそのまま進め、6件（30%）は相談が要り、2件（10%）は禁止です。6人が1週間に20件ずつなら、相談は約36回、約108分、チーム全体で週およそ1.8時間です。もし20件中12件（60%）が「先に相談」に入ると、同じ計算で相談は72回、週3.6時間になり、人は聞かなくなります。

はっきり言っておくと、1回3分と12、6、2の内訳は仮定です。「先に相談は作業の約3分の1を超えないほうがよい」という目安は私の経験則で、どの研究の実測でもありません。自分のチームの実際の作業で試して、調整してください。

---

5. ポリシーが失敗する場所#

決まり書きを思い浮かべてください。長すぎれば誰も読まず、厳しすぎれば人はこっそり料理し、曖昧すぎれば各自が好きに解釈します。

5.1 例：ポリシーがある朝とない朝#

これは想定の場面で、実在の人物や製品には触れていません。

• 10:00。 開発者が、顧客向けに出力したレポートのバグを探す必要があります。エラーログには顧客のエンドユーザーのメールアドレスと名前が含まれています。
• 10:05。 誰も駄目と言っていなかったので、開発者はログをそのまま、個人の無料アカウントで公開チャットボットに貼ります。
• 10:30。 貼った部分に実際のメールアドレスがあると気づきます。手順がないので、開発者は黙っています。
• 翌週。 顧客が、自分たちのデータがどこへ行ったのか尋ねます。誰も答えを持っていません。

ポリシーがある場合： 10:05に「顧客データは先に相談」の一行があるので、開発者はリーダーにメッセージを送ります。二人でログからメールアドレスを取り除き、承認済みのツールを使い、1行だけ記録します。それでも貼ってしまった場合は、「1時間以内に報告」の手順のおかげで早く対処できます。何を貼ったかを書き留め、キーがあれば交換し、必要なら顧客に伝えます。

やること：事故の項目は、事故が起きる前に書いておきます。慌てているときに手順を思いつく人はあまりいません。

この例は証拠ではありません。上で述べたSamsungの件は同じ種類の行動の実例で、Stack Overflow 2026年調査（報道経由）はポリシーの空白がよくあることを示唆します。技術的なリスクはAIアプリのOWASP Top 10も参照してください。

---

6. 事故が起きたとき：短い5つの手順#

1. 止める： そのツールでの作業をやめる。
2. 1時間以内に報告： 責任者に。事故かどうか確信がなくても。
3. 書き留める： 何を、どのツールに、いつ入れたか。
4. 対処する： キーが漏れたなら交換し、ツールが許せば会話を削除し、データの保持について提供元に尋ねる。
5. 契約や法律が求めるなら顧客に伝え、学んだことをポリシーに戻す。

「ひやっとした」だけの場合の報告も認めます。報告したら罰せられるなら、人は黙ります。

---

7. 数字、標準、法律：どう読むか#

法律面について： 私が見つけた情報源によると、この法律は2025年12月10日に国会で可決され、2026年3月1日に施行されます。導入者とは、職業、商業、サービス提供の活動でAIシステムを使う組織または個人と定義され、個人的で非商業的な目的の利用はこの範囲に入りません。各当事者の具体的な義務、施行細則、経過期間は確認していません。AIを使った製品やサービスを顧客に提供するチームは、法律の全文を読み、法務の専門家に相談してください。この記事は、何を聞くべきかを知る助けになるだけです。

公平に読むと： 上の情報源は、明確な決まりと責任者の存在を支持しています。1ページのポリシーが事故をどれだけ減らすかを測った研究は見つかりませんでした。ここでのひな形は実務の総合です。

---

8. 明日から使える習慣#

8.1 ポリシーを貼る前の8つの質問#

1. ポリシーは1ページに収まっていますか？
2. 3列に、概念だけでなく具体例がありますか？
3. データの4段階に、チームになじみのある例がありますか？
4. 日付と承認者つきの承認済みツールの一覧がありますか？
5. AIが書いた変更はすべて、第二の人が読んでいますか？
6. 責任者の名前とポリシーの担当者の名前がありますか？
7. 事故の手順が書かれていて、ひやっとした場合の報告も認められていますか？
8. 見直し日が決まっていますか？

8.2 今すぐやる3つのこと#

1. 30分かけて3.4のひな形を埋め、チームに不要なものは削る。
2. 4.1の20件の試しを、先週の実際の作業で行う。
3. 90日後ごろに見直し日を置き、担当者の名前を書く。

---

9. バランスよく見る：ポリシーにできること、できないこと#

できること： 繰り返し出る質問に全員が同じ答えを持てるようにし、新人に何をすればよいかを伝え、うっかりしたときに報告できる場を作り、顧客に聞かれたときの記録を残します。

できないこと：

• ポリシーは安全の保証ではありません。人は間違えて貼ることがあり、ツールは規約を変えることがあります。
• 1ページのポリシーの効果を測った研究は見ていません。相談の回数とひやっとした件数を自分で記録してください。
• 紙1枚は、教育、チェックのツール、間違いを報告できる文化の代わりにはなりません。
• 顧客にサービスを提供するチームや個人データを扱うチームにとって、1ページは出発点であり、法的義務のすべてではありません。

誇張しない： すべてのチームに合うひな形はありません。軽く見ない： ポリシーの空白は顧客に聞かれたときに表に出ますが、そのときはもう書くのに遅すぎます。

---

10. まとめ#

少人数チームに分厚い規則集は要りません。冷蔵庫の扉の貼り紙1枚で足ります。使ってよい、先に相談、禁止、データの4段階、責任者1人、問題が起きたときの5つの手順、見直し日。30分で下書きし、実際の作業20件で試し、90日後に直してください。

---

参考資料#

数字は2026年10月時点の公開情報によります。一部は報道や二次的な要約を通じてしか読んでいないので、引用する前に原典を開いて確認してください。法的助言ではありません。

• Stack Overflow、2026 Developer Surveyと調査についてのIT Brief報道（29.7%と24%の数字の出どころ）
• Samsungの生成AI制限の報道（2023年5月）：Forbes AustraliaとTechRadar（Bloombergの報道を伝えるもの）
• NIST、AI Risk Management Framework（AI RMF 1.0、2023年1月）
• ISO、ISO/IEC 42001:2023
• 人工知能法（法律番号134/2025/QH15）（Thu Vien Phap Luat）とBaker McKenzieの概説（頼る前に全文を読んでください）