こんにちは。セキュリティ本部のsohです。
近年、多くの企業でAIサービスの導入が急速に進んでいるかと思いますが、STORES でも様々なツールの活用を推進しています。 しかし、その一方で、セキュリティやコンプライアンスの観点から、導入には慎重な検討が求められます。
本記事では、AIサービス（特にコーディングに関わるサービス/ツール）の導入を担当する方が、まず基本的な事項としてどのような観点をチェックすべきか、そのポイントを私自身の経験も踏まえながら整理してみたいと思います。
なお、当記事は先日当社でオンライン開催した「Cursor 使ってますか？STORES での活用事例」における「AIコーディングツール導入時に担当者がチェックすべきポイント」をベースとしています
なぜAIツールを推進するのか
本題に入る前に、私たちがなぜAIツールの利用を推進しているのかについて記載します。
STORES では現在、GitHub Copilot Enterprise、Cursor、Devinといったツールを導入しており、これらは基本的に申請すれば使えるようになっています。 また、コーディングという文脈に限らず、ClaudeやOpenAI API、Notion AI、Geminiなども用途に応じて柔軟に活用しています。
私たちがこれらのAIを用いたサービスおよびツールに投資し、活用を強く推進する最大の理由は、人々の作業効率化や創造性向上に寄与することで、結果としてお客様である事業者様へより早く、より質の高い価値を届けられるようになると信じているからです。
STORES において、AIを用いたコーディングツールに関して、実際に社内で既に職種を問わず様々な効果が表れています。
- エンジニア: 実装スピードが向上し、機能改善やお客様の要望に応えるサイクルが早くなる。
- ビジネス: 適切なレビュープロセスや安全な開発環境のもとで、プロダクトに関する軽微な修正やプロトタイピングを自ら行えるようになり、開発への貢献の幅が広がる。
- 全社員: 仕様理解がスムーズになり、より早く正確な事業判断に繋げることができる。また、スクリプト作成による業務効率化に寄与することに繋がる。
なお、セキュリティエンジニアである私自身も恩恵を受けており、例えばコードやインフラ構成の理解、リスクの洗い出しにかかる時間が削減され、より本質的な脆弱性の判断や対策に集中できるようになりました。また修正PRを出す際にも同様に役立っています。
このように、単なる個人の作業効率化に留まらず、組織全体の生産性やアウトプットの質を向上させるポテンシャルを強く感じており、これが私たちのAI導入推進の理由となっています。
導入における懸念とレビューの必要性
とはいえ、これだけのメリットがあるからといって、何も考えずにツールを導入するわけにはいきません。AIを用いたコーディングツールの利用には、場合によって下記のようなリスクが伴います。
- 個人情報の入力と法令違反: 顧客の個人情報などを誤って入力してしまい、個人情報保護法上の問題に発展する。
- 機密情報の漏えい: 入力したソースコードがAIモデルの学習に利用され、意図せず外部に漏えいしてしまう。
- 意図しない改変: AgenticなAIが、保護されていない（e.g., Branch Protection がない）環境を操作し、意図せずコードを改変したり、不可逆な処理を実行してしまったりする。
- 権利侵害: 生成されたコードをそのまま利用した結果、第三者の著作権などを侵害してしまう。
- 信頼できないサービスからの情報漏えい: セキュリティ対策が不十分なサービスを利用した結果、より直接的な情報漏えいに繋がる。
これらはほんの一例で、実際にはTool Poisoning Attackのような攻撃や、悪意のあるMCPを介した情報窃取など、考慮すべき事項は広範かつ膨大です。
このあたりは技術の進展も早く、仕様が定まっていない部分も多いため、継続的な情報収集が欠かせません。
こうしたリスクに対応するため、AIサービスの導入にあたっては、法務・セキュリティ部門によるレビューや、社内ルールの策定、そして安全に使うためのガードレール設置が不可欠になります。
今回は、こうしたプロセスの中でも特に「導入時」に担当者が確認すべき基本的な観点に絞って記載します。なお、これらはチェック観点のすべてを網羅するものではなく、サービス特性などを考慮したうえで他観点によるチェックも実施しています。
導入時にチェックすべき3つのポイント
1. 提供している会社の信頼性
まず最初に確認すべきなのは、提供元が信頼できる企業であるか、という点です。 私たちは、主に以下の観点などから総合的にチェックを行っています。
| 観点 | 確認内容の例 |
|---|---|
| 会社情報 | ・代表者名、所在地、連絡先などが明記されているか |
| 利用規約 (ToS) | ・生成物の知的財産権の帰属先はどこか ・サービスの利用制限や禁止事項は何か ・準拠法や裁判管轄はどこか ・万が一損害が発生した場合の、免責事項の範囲は妥当か |
| プライバシーポリシー / DPA | ・個人情報や入力データをどのように扱うかが明記されているか（詳細は次節で解説） |
| 外部認証など | ・SOC2 や ISO 27001 (ISMS) などの第三者認証を取得しているか・ GDPR や CBPR といったプライバシー規制に準拠しているか |
これらの項目は法務部門も当然チェックしますが、導入を推進する担当者自身が内容を理解しておくことが、スムーズな導入と適切な判断に繋がると感じています。特に利用規約などは、法務任せにせず、「自分たちのビジネスにどう影響するか」「どのようなリスクが考えられるか」という視点で読み解くことで、より踏み込んだ事業判断が可能になるのかなと思います。
また外部認証に関しては、当然ですが、特定の認証を取得しているからといって安全というわけではありません。しかし、これらの認証は、その企業が情報セキュリティに対して一定の投資を行い、客観的な基準で体制を整備しているかどうかの信頼性を測る一つの判断材料にはなるかと思います。
最近では、GitHubやCursorなどTrust Centerといったページを公開している場合が多くあり、セキュリティに関する取り組みや各種レポートを閲覧できる場合も多いので、そういった情報もあわせて確認すると良いでしょう。
2. 情報の扱い（プライバシーポリシー / DPA）
注意 ここで記載する内容は、あくまで一般的な確認事項であり、法律に関する具体的なアドバイスを行うものではありません。実際の導入に際しては、必ず自社の法務部門や専門家にご相談ください。
次に、入力した情報がどのように扱われるかを確認します。 特にAIを用いたコーディングツールの場合、ソースコードや個人情報といった機密性の高い情報を扱う可能性があるため、この点は最も慎重に評価すべきポイントの一つです。
情報の扱いについては、主にプライバシーポリシーとDPA (Data Processing Addendum / データ処理契約) などを読み解くことになります。 プライバシーポリシーは「ユーザーに対して、情報の扱い方を宣言する文書」、DPAは「データの処理を委託する際に、委託元と委託先で結ぶ契約」と理解しておくと読みやすいかもしれません。
確認すべき主な観点は以下の通りです。
- ユーザー入力をもとに学習を行うか
- 最も重要なポイントです。入力したコードがAIモデルの学習に利用されると、自社の機密情報が他のユーザーへの生成結果に含まれてしまうリスクがあります。オプトアウトできるか、デフォルトで学習しない設定（Zero Retention）になっているかなどを確認します。
- ユーザー入力を（学習以外の目的で）利用したり保持するか
- 学習には利用しないと明記されていても、機能提供やサービスの品質改善、バグ修正、利用状況の分析などの目的でデータを保持・利用する場合があります。また、一部サービスのプレリリース版などでは、製品の改善目的でデータが利用される旨が規約に記載されていることもあります。どのような目的で、どの範囲まで、どのくらいの期間利用または保持されるのかを確認しておくことが望ましいです。
- Sub Processorは信頼できるか
- 利用サービスのサブプロセッサー（再委託先）が信頼できるか、同様にチェックします
- 個人情報を入力する場合の考慮点をケアできているか
- 「提供」にあたるか: サービス提供元がデータの取扱を行うか
- 「委託」にあたるか: 「提供」にあたる場合、サービス提供元が個人データを独自利用するかなど
- 「越境移転」にあたるか: 「委託」にあたるかを考慮したうえで、基準適合体制に依拠しているかや本人同意が取得できるかなど
- など...
なお、「個人情報を入力する場合の考慮点」については法的な解釈が複雑に絡む部分です。 そのため、担当者だけで判断せず、個人情報保護委員会が公開しているガイドラインなども参考にしながら、必ず法務部門と連携して進めることが重要です。
3. ポリシー管理機能の有無
最後に、企業としてツールを統制するために、管理者向けのポリシー管理機能が提供されているかを確認します。 利用ルールを定めることは非常に重要ですが、一方で組織として一貫したセキュリティポリシーを技術的に適用できる機能はリスクを低減するうえで非常に有効です。 そのため、可能であればポリシー管理機能を備えたツールであることが望ましいと思います。
確認すべき機能の例としては、以下のようなものが挙げられます。
- ユーザー管理
- SSO (シングルサインオン):
OktaやGoogle Workspaceなど、社内で利用しているIDプロバイダ経由での認証を強制できるか。認証をIdPに集約することで、多要素認証（MFA）の強制など、組織のセキュリティポリシーを一元的に適用できる。 - SCIMプロビジョニング: IdPとアカウント情報を同期し、入退社に伴うアカウントの作成・削除を自動化できるか。これにより、退職者アカウントの削除漏れといったセキュリティリスクを防ぐことができる。
- SSO (シングルサインオン):
- 権限・設定管理
- Privacy Modeの強制: 例えば
Cursorには、入力情報を保持しない「Privacy Mode (Legacy)」があり、管理者がこのモードの利用をチーム全体に強制できます。これにより、意図せず機密情報が送信されるリスクを組織的に低減できる。 - Public Code Matchingの可否: 公開されているコードとマッチするか判別・ブロックできる機能がある場合、生成物による権利侵害リスクを軽減できるか
- 設定の統一的な管理: チーム全体で特定のセキュリティ設定を統一し、個々のユーザーが変更できないように制御できるか。また、何らか強制できない（レビューできない）ような機能やオプションは存在しないか
- Privacy Modeの強制: 例えば
- コスト管理
- 少し観点はズレますが、
GitHub CopilotやCursorではユーザー数および使用量をベースとした課金プランが提供されています。チーム全体やユーザーごとの利用上限額を設定できるかなど、意図しない高額請求を防ぐための予算管理機能も、実運用においては重要な確認ポイントです。
- 少し観点はズレますが、
これらの管理機能が充実しているほど、企業としても安心してツールを導入し、スケールさせやすくなるかと思います。
導入を判断する総合的な視点
ここまで3つのチェックポイントを記載しましたが、最終的に導入を判断するうえでは、「リスクとベネフィットのバランス」と「自社にとって許容できるか」という視点が重要になります。
技術的なセキュリティリスク、情報漏えいリスク、法務・コンプライアンスリスクなど、様々なリスクが存在します。一方で、生産性向上やイノベーションの促進といった、大きなベネフィットも期待できます。
ここで大切なのは、あるリスクが、自社にとって本当に「許容できない」ものなのかを評価することです。
例えば、入力情報がサービス改善のために一時的に収集されるというリスクがあったとします。このリスクは、ある組織にとっては許容できないかもしれませんが、別の組織にとっては（および入力する情報によっては）得られるメリットの方が大きいと判断できるかもしれません。
担当者や法務・セキュリティ部門でレビューを行い、判断材料が揃ったときに、「これらのリスクを許容してでも、このツールを利用する価値があるか？」を総合的に判断するプロセスの整備が導入担当者の重要な役割なのかなと考えています。 ただし、法的な問題（個人情報保護法違反など）については、法的義務やコンプライアンスの観点から特に厳しく評価し、専門家と連携して対処すべきかと思います。
おわりに
今回は、AIを用いたコーディングツールを導入する際に担当者がチェックすべきポイントについてまとめました。
上記ではかなり基本的な事項の記載にとどめていますが、実際に考慮すべきことは広範囲にわたります。
AI関連はまだ過渡期であり、サービスの仕様変更は頻繁に起こりますし、私たちがまだ認識できていない新たなリスクが出現する可能性もあります。 また、今回は詳細に記載しませんでしたが、例えばMCPサーバーを利用したときの認証に関するリスクや、情報が他サービスにわたってしまうことのリスクも存在するかと思います。
一度導入して終わりではなく、継続的に情報をキャッチアップし、社内のルールや運用を柔軟に見直していく姿勢が不可欠です。当社ではAIを用いたコーディングツール全体や個別ツールに関する注意点や利用方法をまとめたページを作成し、適宜アップデートを行うなど、安全な利用に努めています。 上記のようなリスクと向き合い、適切に管理しながら、その恩恵を最大限に活用していくことが事業成長を促すとともに、今後の業務では必要不可欠になると考えています。
この記事が、皆さんの組織でAIを用いたコーディングツールの導入を検討する際の一助となれば幸いです。 もし内容にご意見などありましたら、ぜひフィードバックをいただけると嬉しいです。
