はじめに：生成 AI にコードを書かせる前に決めるべきこと
AI にコードを書かせる開発ツールが一般化し、中小企業でも「社内の業務システムの改修を AI に手伝わせたい」という相談が増えています。ここで最初につまずくのが、AI にどこまで社内の情報を見せるかという判断です。
AI は渡された情報の範囲でしか考えられません。情報を絞りすぎれば見当違いのコードが出てきますし、逆に「とりあえず全部見せる」と、本来外に出してはいけないデータまで一緒に送信されます。AI 活用でのトラブルの多くは、AI の性能ではなく情報と権限の線引きを決めないまま使い始めたことに起因します。
この記事では、受注開発の現場で実際に設計判断が必要になるポイントを、権限と範囲という切り口で整理します。
AI に「何が渡っているか」を把握する
まず前提として、AI コーディングツールが読み取る情報（これをコンテキスト＝AI が回答を作るために参照する入力情報、と呼びます）には、おおむね次のものが含まれます。
- 開いているファイル、または指定したディレクトリ配下のソースコード
- 設定ファイル（.env、config.yml など）
- データベースのスキーマ定義、SQL ファイル
- エラーログ、スタックトレース
- 利用者がチャット欄に貼り付けた文章やデータ
問題は、このうち後ろの 3 つに意図せず本番データが混ざりやすいことです。たとえば次のような場面です。障害調査のためにエラーログをそのまま AI に貼り付けたところ、ログの中に顧客の氏名とメールアドレスが出力されていた——これは設計上まったく珍しくない構成で、ログ出力の方針を見直していない現場では十分起こりえます。
「どのファイルを渡すか」を人間が毎回判断する運用は現実的に続きません。渡してよい範囲をあらかじめ構造で決めておくのが基本方針になります。
情報を 4 つに分類して扱いを決める
すべての情報を一律に扱うと、厳しすぎて使えないか、緩すぎて危ないかのどちらかになります。社内の情報を次の 4 段階に分けて、扱いを事前に決めておくと判断が速くなります。
| 区分 | 具体例 | AI への渡し方 |
|---|---|---|
| 公開可 | OSS ライブラリ、公開 API 仕様、一般的な技術情報 | 制限なし |
| 社内限定 | 自社の業務ロジック、画面仕様、テーブル定義 | 契約で学習利用されない構成を確認のうえ可 |
| 要配慮 | 顧客名簿、取引条件、価格表、人事データ | 原則渡さない。構造だけ抽象化して渡す |
| 禁止 | 認証情報、API キー、秘密鍵、本番 DB 接続文字列 | いかなる場合も渡さない |
実務で効くのは「要配慮」の行です。顧客データを使ったバグ修正では、データそのものではなくデータの形だけを渡せば足りることがほとんどです。「氏名カラムに全角スペースが混在している場合に検索が外れる」という情報があれば、AI は正しい修正案を出せます。実データは不要です。
なお、個人データを外部サービスに入力する場合の取り扱いについては、個人情報保護委員会が 2023 年に生成 AI サービスの利用に関する注意喚起を公表しています。利用目的の範囲や第三者提供の該当性は、サービスの契約形態によって判断が分かれるため、個別に確認が必要です。
権限は「読む・書く・実行する」で分けて考える
情報の範囲と並んで重要なのが、AI にどこまで操作させるかです。コードを書くツールの多くは、ファイルの編集やコマンドの実行まで行えます。ここを「全部許可」にすると、意図しない変更が本番環境に届く経路ができてしまいます。
| 権限 | 内容 | 推奨する初期設定 |
|---|---|---|
| 読み取り | ソースコードや設定を参照する | 対象ディレクトリを限定して許可 |
| 書き込み | ファイルを新規作成・編集する | 作業用ブランチ内でのみ許可 |
| コマンド実行 | ビルド、テスト、スクリプト実行 | テスト・静的解析など安全なものだけ都度承認 |
| 外部通信 | API 呼び出し、パッケージ取得 | 原則禁止、必要時のみ個別許可 |
| 本番接続 | 本番 DB・本番サーバーへのアクセス | 禁止 |
特に注意したいのが「コマンド実行」です。テストを走らせる程度なら安全ですが、削除系コマンドやマイグレーション実行が含まれると、取り返しがつきません。承認なしで実行できるコマンドをホワイトリスト（許可するものだけを列挙する方式）で管理するのが安全です。禁止リスト方式は、書き方を少し変えるだけで迂回できるため推奨しません。
実装で詰まりやすい 4 つの箇所
1. 秘匿情報がリポジトリに残っている
AI に読み取り権限を与えると、過去のコミットに残った API キーや、コメントアウトされた接続情報まで拾われます。AI 導入のタイミングで、秘匿情報スキャンツールをかけて棚卸しするのが現実的です。.env ファイルを除外設定に入れるだけでは不十分で、テストコードや Markdown のサンプルに書かれた値が残っているケースが多くあります。
2. リポジトリが大きすぎて的外れな回答になる
AI が一度に扱える情報量には上限があります。10 年もののシステム全体を渡しても、関係のないコードに引っ張られて精度が落ちます。機能単位でディレクトリを切り、関連する範囲だけを渡すほうが、結果として品質が上がります。範囲を絞ることはセキュリティ対策であると同時に、精度対策でもあります。
3. 設計意図が伝わらず、既存ルールを無視したコードが出る
AI はコードは読めますが、「この項目は税務上の理由で削除せず論理削除にしている」といった背景は読み取れません。リポジトリ内に設計方針や命名規則をまとめたドキュメントを置き、AI に最初に読ませる運用にすると、手戻りが目に見えて減ります。
4. レビューの責任があいまいになる
AI が書いたコードでも、動かす責任は自社にあります。生成されたコードは必ず人間がレビューしてからマージするという手順を、例外なく維持してください。経済産業省・総務省が 2024 年に公表した「AI 事業者ガイドライン」でも、AI の判断を人間が確認する体制の重要性が示されています。
社内で最低限決めておくルール
難しい規程は不要です。次の 5 項目を A4 一枚にまとめるところから始められます。
- 使ってよい AI ツールと契約プランを明示する（入力データが学習に使われない条件かを確認する）
- 前述の 4 分類のうち、どこまで入力してよいかを定める
- 本番環境への接続と、承認なしのコマンド実行を禁止する
- 生成コードは人がレビューしてからマージする手順を定める
- 運用開始後に起きた「ヒヤリハット」を記録し、月次で見直す
特に 5 番目が効きます。AI ツールの機能は更新が速く、一度決めたルールはすぐに現実とずれます。定期的に見直す前提で、最初から完璧を目指さないほうが続きます。
まとめ
AI にコードを書かせる取り組みで失敗する多くは、ツール選定ではなく情報と権限の線引きを決めていないことが原因です。整理すると次の 3 点になります。
- 情報は 4 分類で扱いを決め、顧客データは「形だけ」渡す
- 権限は読む・書く・実行するで分け、実行系はホワイトリストで管理する
- 人によるレビューを省かない。責任の所在は自社に残る
範囲を絞ることは、安全対策であると同時に AI の回答精度を上げる手段でもあります。「全部見せたほうが賢く答えてくれる」というのは、実は逆です。小さく区切って、確実に動く範囲から広げていく進め方をおすすめします。
既存システムに AI 支援を組み込む場合、どこまでの範囲なら安全に任せられるかは、システムの構造とデータの持ち方によって変わります。判断に迷う場合は、現行の構成を前提にした個別の設計相談をご検討ください。