AIコーディングを社員に使わせる前に：最初に教えるべきセキュリティリテラシー

AIコーディングツールは、使える人にとっては大きな武器です。

仕様を整理し、コードを書き、テストを動かし、エラーを読み、修正案を出す。慣れた人が使えば、これまで数時間かかっていた作業がかなり短くなる場面があります。

ただし、会社で使うときに見落としやすい点があります。

それは、AIコーディングツールは単なるチャットではない、ということです。

チャットAIなら、画面に文章を入力して回答を読むだけで済むことが多いでしょう。しかしAIコーディングツールは、ファイルを読み、コードを書き換え、コマンドを提案し、外部サービスやリポジトリと接続することがあります。つまり、使い方を間違えると、情報漏えい、誤変更、コスト増、レビュー不備が同時に起きます。

この記事では、Claude CodeやCodexのようなAIコーディングツールを中小企業で社員に使わせる前に、最初に教えておきたいセキュリティリテラシーを整理します。

まず教えるのはプロンプトではなく権限

AI研修というと、すぐにプロンプトの書き方を教えたくなります。

もちろん、依頼文の書き方は大切です。しかしAIコーディングでは、プロンプトより先に権限を教えるべきです。

AnthropicのClaude Code公式ドキュメントでは、Claude Codeは初期状態で読み取り専用の権限を使い、ファイル編集、テスト実行、コマンド実行など追加の操作が必要な場合には明示的な許可を求める設計だと説明されています。さらに、システムを変更し得るBashコマンドは承認が必要で、読み取り系の一部コマンドだけがプロンプトなしで実行されるとされています。

これは重要な前提です。

社員に教えるべきなのは、「AIが聞いてきたら便利そうだから許可する」ではありません。

読み取りだけなら何を見ているか確認する
編集ならどのファイルが変わるか確認する
コマンドなら何を実行するか確認する
外部通信ならどこへ接続するか確認する
削除や移動なら必ず止めて人間が確認する

AIコーディングの教育は、きれいな依頼文よりも、承認ボタンを押す前の判断を教えるところから始まります。

入れてよい情報と入れてはいけない情報を分ける

次に必要なのは、入力情報の線引きです。

AIに何でも入れてよいと思っている社員と、何も入れてはいけないと思っている社員が混在すると、運用は不安定になります。前者は機密情報を入れすぎ、後者は便利な場面でも使えません。

最初に分けるべきなのは、次の3つです。

入力してよい情報:
  公開済みの仕様、社内で共有済みの一般資料、サンプルデータ

確認してから使う情報:
  顧客名、案件名、未公開の価格、社内だけの業務手順

入力しない情報:
  APIキー、パスワード、個人情報、契約書原本、未公開の顧客データ

OWASPのLLMアプリケーション向けTop 10では、プロンプトインジェクション、過剰な自律性、機密情報の開示、出力への過信などがリスクとして整理されています。AIコーディングでは、これらがより現実的になります。なぜなら、AIの回答がコードやコマンドとして実行され得るからです。

社員教育では、「情報を守りましょう」と抽象的に言うだけでは足りません。

実際に使う業務を1つ選び、「この資料は入れてよい」「これは匿名化する」「これは入力しない」と例で決める必要があります。

コストは経理ではなく利用者にも見せる

高性能AIモデルは、性能が上がるほど費用も重くなりがちです。

社員が自分の作業時間だけを見てAIを使うと、会社全体の費用感が見えなくなります。たとえば、長いファイルを何度も読み込ませる、同じ処理を繰り返す、失敗したまま再実行を続ける、といった使い方は、作業者には便利でも、会社には負担になります。

ここで必要なのは、細かな課金単価を全員に覚えさせることではありません。

最低限、次のような感覚を持ってもらうことです。

長い資料を入れるほど費用が増える
同じ依頼を何度もやるほど費用が増える
高性能モデルは全作業に使うものではない
下書き、調査、レビュー、最終判断で使うモデルを分ける
月次上限と責任者を決める

「使える人だけが高性能モデルを使える」という話にすると、社内の空気が悪くなります。

そうではなく、「高性能モデルを使う業務を先に決める」と考えます。重要度が低い作業、失敗しても戻せる作業、短い下書きで済む作業は軽いモデルや通常のチャットでよい。重要な設計、複雑なレビュー、長い文脈の整理は高性能モデルを使う。

人で差をつける前に、業務で差をつける。これが中小企業には現実的です。

AIの出力をレビューする責任を消さない

AIコーディングツールを使うと、コードや設定が一気に進みます。

ただし、速くなったことと、正しいことは別です。

Claude Codeの公式ドキュメントでも、利用者には提案されたコードやコマンドを安全性の観点で確認する責任があるとされています。NISTのAIリスクマネジメントフレームワークも、AIシステムの設計、開発、利用、評価に信頼性の考慮を取り入れることを目的にしています。

社員教育で必ず入れたいのは、次の一文です。

AIが書いたものでも、業務で使うなら人間がレビューした成果物です。

「AIがそう言ったので」は、社内の説明になりません。

レビューで見るべき項目は、最初は多くなくて構いません。

変更されたファイルは想定どおりか
秘密情報が混ざっていないか
不要な外部通信がないか
削除や上書きが含まれていないか
エラー時に元に戻せるか
顧客や外部に出す前に人間が読んだか

この確認ができない作業は、社員に自由利用させる段階ではありません。まずは責任者同席、検証環境限定、読み取り専用、下書き用途に戻す方が安全です。

事故時の戻し先を先に決める

最後に、事故時の戻し先です。

AIコーディングで怖いのは、失敗そのものよりも、失敗したときに誰も止め方を知らないことです。

たとえば、AIが不要なファイルを変更した。外部パッケージを入れようとした。想定外のコマンドを提案した。公開前の情報を含むファイルを読ませようとした。こうした場面で、社員が一人で判断し続ける設計は危険です。

最初に、停止条件を決めておきます。

APIキー、パスワード、個人情報が出てきたら停止
削除、移動、一括置換が出てきたら停止
外部通信やインストールが出てきたら確認
本番環境、顧客データ、契約書に触れるなら責任者へ戻す
費用が読めない長時間処理は実行しない

これは社員を縛るためではありません。

むしろ、安心して使ってもらうためです。どこまで自分で進めてよいか、どこから戻せばよいかが決まっていれば、社員は使いやすくなります。

最初の研修は30分でよい

AIコーディング研修を大げさに始める必要はありません。

最初は30分で十分です。

5分:
  AIコーディングはファイルとコマンドに触れる道具だと説明する

10分:
  入れてよい情報、確認が必要な情報、入れない情報を例で分ける

10分:
  承認してよい操作、止める操作、責任者に戻す操作を分ける

5分:
  事故時の連絡先と記録方法を確認する

この30分をやるだけで、プロンプト講座だけを受けた状態よりかなり安全になります。

慣れてきたら、次に業務別のルールを作ります。営業資料の下書き、社内ツールの修正、Webサイト更新、データ整理、問い合わせ分類など、業務ごとに入力情報、使う環境、承認範囲、レビュー担当を分けます。

AIコーディングの導入は、技術の話であると同時に、教育の話です。

Optiensの見方

Optiensでは、AI導入を「社員に新しいツールを配ること」ではなく、「業務ごとに入力情報、権限、費用、レビュー責任を設計すること」と捉えています。

無料のAI活用診断簡易版では、フォーム入力をもとに、AI化しやすい業務と慎重に扱うべき業務を整理します。詳細版AI活用診断では、導入可否、優先順位、構成案、費用前提を整理します。個別の実装や継続支援が必要な場合は、診断とは別の導入支援や個別見積の領域です。

AIコーディングツールは、これからさらに強くなります。だからこそ、社員教育も「便利な使い方」だけでは足りません。

誰が、何を、どこまで、どの責任でAIに任せるのか。

この線引きを先に作る会社ほど、高性能AIを安全に使えるようになります。