はじめに
業務開発でAIを使う場面は増えています。
コードのたたき台を作る。
エラーの原因を調べる。
設計案を整理する。
ドキュメントを要約する。
テスト観点を洗い出す。
こうした用途では、AIはかなり便利です。
一方で、業務開発で使う場合は、個人学習や個人開発とは違う注意点があります。
- 出力されたコードが正しいとは限らない
- もっともらしい誤情報（ハルシネーション）が混ざることがある
- 詳しくない分野ほど、間違いに気づきにくい
- 機密情報や契約上の制約がある
- クラウド環境では、試行錯誤がそのまま料金につながることがある
- レビューできる人がいないと、妥当性の判断が難しい
この記事では、業務開発でAIを使う前に整理しておきたいチェック観点をまとめます。
前提：これは「毎回すべて実施するチェックリスト」ではない
最初に前提を書いておきます。
本記事の内容は、AIを使うたびに全項目を機械的に確認するためのものではありません。
実際の業務開発で、すべてのAI出力に対して毎回、
- 公式ドキュメント確認
- セキュリティ確認
- ライセンス確認
- OSSとの酷似確認
- コスト影響確認
をフルで行うのは、現実的ではありません。
大事なのは、すべてを毎回確認することではなく、リスクに応じて確認レベルを変えることです。
そのため、この記事ではチェック観点を次の3つに分けます。
- 基本的に毎回意識したいこと
- 実装内容に応じて確認したいこと
- チーム・会社として決めておきたいこと
AIを安全に使うには、「全部チェックする」よりも、どの場面でどこまで確認するかを決めておく方が現実的だと思います。
1. 基本的に毎回意識したいこと
入力してよい情報か
まず確認したいのは、AIに入力する情報です。
業務開発では、以下のような情報をそのまま入力しない方が安全です。
- 顧客名
- 契約情報
- APIキー
- アクセストークン
- パスワード
- 個人情報
- 非公開の仕様書
- 社内限定の資料
- 未公開の障害情報
- マスキングしていない本番環境のログ全文
AIツールによって、入力データの扱いは異なります。
また、同じサービス名でも、個人契約・法人契約・API利用・組織設定によって扱いが変わることがあります。
そのため、まずは以下を確認します。
- そのAIツールを業務で使ってよいか
- 入力してよい情報の範囲はどこまでか
- ソースコードを入力してよいか
- ログを入力してよいか
- 顧客情報や案件情報を匿名化すべきか
迷う場合は、具体名を伏せたり、構造だけを抽象化したりして相談する方が安全です。
NG例：
株式会社〇〇向けの△△システムで、以下の本番ログが出ています。
OK例：
顧客名や識別子を伏せたうえで、以下のような認証エラーが出ています。
失敗しやすい例
たとえば、エラー調査のために本番ログをそのまま貼り付けた結果、メールアドレスや内部URL、顧客識別子が混ざっていた、というのは起こりやすいです。
ログは一見ただの文字列に見えても、実際には個人情報や機密情報を含んでいることがあります。
迷ったときの基準
「そのまま社外に送って問題ない情報か」で判断すると分かりやすいです。迷うなら入力しない、が基本です。
出力内容を自分が説明できるか
AIが出したコードや設計案は便利ですが、そのまま業務成果物にするには危険があります。
最低限、以下は確認したいです。
- 何をしているコードか説明できるか
- 既存の設計と矛盾していないか
- エラー時の挙動を理解しているか
- 副作用がどこにあるか把握しているか
- 削除・更新・課金・権限変更などの影響がないか
特に、自分が詳しくない分野では注意が必要です。
AIの回答は、言い切り口調で返ってくることがあります。
しかし、言い切っているから正しいとは限りません。
「よくわからないけど動いた」状態で業務コードに入れるのではなく、少なくとも自分がレビューで説明できる状態にしておく必要があります。
失敗しやすい例
認証まわりのコードをAIに生成させたところ、ログイン自体はできたが、認可チェックが抜けていて、権限のないユーザーでも操作できてしまった、というのは十分ありえます。
「動く」ことと「要件を満たす」ことは別です。
迷ったときの基準
レビューで口頭説明できないコードは、そのまま入れないのが安全です。
ビルド・テスト・動作確認を通したか
AIが出したコードは、実行前提で確認します。
最低限、以下は確認したいです。
- ビルドが通るか
- lintが通るか
- 型エラーがないか
- 既存テストが落ちていないか
- 追加した処理の動作確認をしたか
- 異常系も確認したか
AIに聞いて終わりではなく、実際に動かして確認します。
特に、バージョン違いによるエラーには注意が必要です。
AIが古いAPIや古いライブラリ仕様を前提に回答することもあります。
その場合、コードとしてはそれっぽく見えても、現在の環境では動かないことがあります。
迷ったときの基準
ビルド・テスト・動作確認を通していないものは、サンプル扱いに留めるのが無難です。
変更範囲を把握しているか
AIに修正を依頼すると、想定より広い範囲が変わることがあります。
特にエディタ連携型のAIツールでは、複数ファイルをまとめて変更することがあります。
確認したい観点は以下です。
- 変更されたファイルを把握しているか
- 不要な変更が入っていないか
- 既存仕様を壊していないか
- コメントや命名が既存方針と合っているか
- 生成されたコードが過剰に複雑になっていないか
AIに任せる範囲が広いほど、差分レビューは重要になります。
迷ったときの基準
差分を追い切れない変更は、そのまま取り込まない方が安全です。
2. 実装内容に応じて確認したいこと
ここからは、毎回ではなく、実装内容に応じて確認したい観点です。
公式ドキュメントとの整合性
ライブラリ、クラウドサービス、フレームワークに関する内容は、必要に応じて公式ドキュメントで確認します。
特に確認したいのは以下です。
- API名
- オプション名
- 非推奨になっていないか
- バージョン差分
- 料金に関わる仕様
- セキュリティ設定
- 権限設定
- 制限事項
AIは、古い情報や別バージョンの情報を混ぜて回答することがあります。
たとえば、AWS、Next.js、React、Android、Matter など、仕様の変化や前提条件が重要な領域では、公式ドキュメント確認の優先度は高いです。
迷ったときの基準
API名・設定値・制限事項が絡む話は、公式ドキュメントを一度見るのがおすすめです。
セキュリティ影響
以下のような処理では、セキュリティ観点を強めに確認します。
- 認証
- 認可
- セッション管理
- API公開
- CORS
- ファイルアップロード
- 署名付きURL
- SQL
- 外部API連携
- ログ出力
- 権限設定
- クラウドリソース作成
AIが出したコードは、一見動作しそうに見えても、セキュリティ要件まで満たしているとは限りません。
たとえば、以下のようなコードは注意が必要です。
- 認可チェックがない
- 管理者権限を広く付けている
- CORSを
*にしている - 秘密情報をログ出力している
- SQLインジェクション対策がない
- S3バケットを公開している
- IAM権限が広すぎる
「動く」ことと「安全に動く」ことは別です。
迷ったときの基準
認証・認可・権限・公開設定が関わる変更は、可能であれば有識者レビューを入れ、難しい場合でも公式ドキュメントや既存実装との照合を強めに行う方がよいです。
クラウド料金への影響
AWSなどのクラウド環境では、AIに聞きながら試すこと自体が料金につながることがあります。
特に注意したいのは以下です。
- NAT Gateway：存在しているだけで時間課金が発生しやすく、通信量にも注意が必要
- RDS：DBインスタンス、ストレージ、バックアップ、マルチAZ構成などで料金が発生する
- OpenSearch：検索基盤として強力だが、ノード構成やストレージによって料金が大きくなりやすい
- ElastiCache：Redis等を常時起動するため、検証用途では本当に必要か確認したい
- CloudWatch Logs：ログ量や保持期間によって料金が増える。過剰なログ出力に注意
- データ転送量：画像・動画・大きなログなどを扱う場合、通信量に応じた料金が発生する
- ストレージ：S3、EBS、バックアップ、ログ、古いファイルが残り続けると増えていく
- 高頻度実行されるLambda：イベント設定やリトライ設定によって想定以上に実行されることがある
- 定期実行されるEventBridge：実行間隔が短いと、呼び出し先のLambdaやAPIの回数も増える
- AI/API系の従量課金サービス：トークン量、画像生成回数、リトライ、バッチ処理件数で料金が増えやすい
AIが「この構成で作れます」と回答しても、それが低コストとは限りません。
検証用なら、以下を確認しておきたいです。
- 無料枠または低コストで収まるか
- 不要になったら削除できるか
- 削除漏れしやすいリソースはないか
- ログが増え続けないか
- アラートやBudgetsを設定しているか
特に、インフラ構成をAIに作らせる場合は、料金影響の確認を強めにした方がよいです。
迷ったときの基準
「とりあえず作ってみる」で課金される構成かどうかは先に見ておいた方が安全です。
ライセンス・OSSとの酷似
AIが出したコードについて、OSSとの酷似確認を毎回すべて行うのは現実的ではありません。
ただし、以下のような場合は注意した方がよいです。
- 長いコードを一括生成した
- 特徴的なアルゴリズムが含まれる
- どこかの実装例に似ている
- ライブラリ内部の実装に近い
- ライセンス制約が強い領域に関係する
- そのまま製品のコア機能に入れる
現実的には、リスクが高い箇所で重点的に確認する形になると思います。
確認方法の例です。
- コード中の特徴的な関数名やコメントで検索する
- AIに出典や参考元を確認する
- 公式サンプル由来か確認する
- Copilot等の公開コード一致検出機能を利用する
- 必要に応じて自社ルールに従う
一般的なCRUD処理、バリデーション、UI処理など、よくある定型コードまで毎回厳密に調べるのは、現場運用としては重すぎる可能性があります。
重要なのは、リスクが高いコードを見分けることです。
補足
ここは技術判断だけで閉じないことも大事です。
契約条件や顧客との取り決め、社内ルールによっては、法務やセキュリティ担当への確認が必要になることがあります。
迷ったときの基準
製品の中核・差別化要素・長い生成コードは、一段慎重に扱う方が安心です。
設計判断をAI任せにしていないか
AIは設計案を出すのも得意です。
しかし、業務システムの設計では、コードだけでは判断できない情報があります。
- チームのスキル
- 運用体制
- 既存システムとの整合性
- 予算
- セキュリティ要件
- 保守期間
- 障害時の対応
- 顧客との契約条件
AIは、こうした前提を知らないまま、一般論として回答します。
そのため、設計判断をAIだけで確定するのは危険です。
AIは選択肢を出す役として使い、最終判断は人間側で行う必要があります。
迷ったときの基準
要件・運用・責任分界に関わる話は、AI案をそのまま採用しない方がよいです。
3. チーム・会社として決めておきたいこと
使ってよいAIツール
まず、業務で使ってよいAIツールを決めておく必要があります。
- ChatGPT
- GitHub Copilot
- Claude
- Gemini
- Cursor
- 社内AIチャット
- Microsoft 365 Copilot
など、AIツールにはいろいろあります。
ただし、ツールごとにデータの扱い、契約条件、管理機能が異なります。
使用するAIの契約形態、ソースコードを入力してよいのかなどは、個人判断にするのはリスクがあります。
AIに入力してよい情報の範囲
チームまたは会社として、入力可能な情報を分類しておくと運用しやすくなります。
例：
| 情報 | AI入力 |
|---|---|
| 公開ドキュメント | OK |
| 一般的なエラーメッセージ | OK |
| 匿名化したログ | 条件付きOK |
| ソースコード | ルール次第 |
| 顧客名 | NG |
| 個人情報 | NG |
| APIキー・トークン | NG |
| 本番DBの中身 | NG |
ポイントは、現場メンバーが迷わない粒度にすることです。
「機密情報は入れない」だけだと、人によって判断が分かれる可能性があります。
AI生成コードの責任者
AIが出したコードでも、業務コードに入れた時点で、そのコードには責任が発生します。
決めておきたいことは以下です。
- AI生成コードを誰がレビューするか
- どのレベルならレビュー必須か
- AI利用をPRに書くか
- AI生成部分を明記するか
- バグが出た場合の責任範囲をどう考えるか
AIを使ったかどうかに関係なく、最終的には人間がレビューし、理解し、保守する必要があります。
レビュー必須にする条件
すべてのAI利用を厳密にレビューするのは重いです。
そのため、レビュー必須条件を決める方が現実的です。
例：
- 認証・認可に関わる
- 個人情報を扱う
- 課金・決済に関わる
- DB更新を行う
- クラウドリソースを作成する
- IAM権限を変更する
- 外部公開APIを追加する
- セキュリティ設定を変更する
- 大量データ処理を行う
- 生成コードが長い、または理解できない
このように条件を決めておくと、「AIを使ったから全部危険」ではなく、「リスクの高い変更を重点的に見る」運用にできます。
実務で使うなら、このくらいの運用が現実的
個人的には、以下のような運用が現実的だと思います。
低リスク
例：
- 小さなUI修正
- コメントの整理
- テストデータ作成
- READMEのたたき台
- 簡単な型定義
- 一般的なバリデーション
確認内容：
- 差分確認
- ビルド確認
- 動作確認
- 既存ルールとの整合性確認
中リスク
例：
- API処理
- DBアクセス
- 状態管理
- エラーハンドリング
- ライブラリ導入
- 非同期処理
- 外部サービス連携
確認内容：
- 公式ドキュメント確認
- テスト追加
- 異常系確認
- レビュー依頼
- 既存設計との整合性確認
高リスク
例：
- 認証・認可
- 権限設定
- 個人情報
- 決済
- 本番データ更新
- インフラ構築
- クラウド料金に影響する構成
- セキュリティ設定
- ライセンス影響があるコード
確認内容：
- 有識者レビュー
- 公式ドキュメント確認
- セキュリティ観点の確認
- コスト確認
- ライセンス確認
- ロールバック手順確認
AIを使うときのプロンプト例
業務開発では、AIに丸投げするより、前提と制約を明示した方が安全です。
コード生成を依頼する例
以下の条件で実装案を出してください。
- TypeScriptで実装
- anyは使わない
- 既存コードに影響が少ない構成にする
- セキュリティ上の注意点も併記する
- 実装後に確認すべきテスト観点も出す
- 不明点がある場合は、推測した前提を明記する
調査を依頼する例
以下について調査したいです。
- 公式ドキュメントを優先して確認したい
- バージョン差分があれば注意点を出す
- 古い情報の可能性がある場合は、その旨を明記する
- 実装例だけでなく、制限事項や非推奨情報も知りたい
- 確信が持てない場合は断定しないでほしい
レビュー観点を出させる例
以下のコードについて、レビュー観点を洗い出してください。
- セキュリティ
- 保守性
- テストしやすさ
- パフォーマンス
- 既存設計との整合性
問題がありそうな点は、理由つきで挙げてください。
AIに対しても、「何をしてほしいか」だけでなく、「どういう前提で」「どこに注意して」出してほしいかを書く方が、使いやすい回答になりやすいです。
AI導入で危ない勘違い
個人的に危ないと思うのは、AIがあれば、詳しくない分野でもそのまま進められると思ってしまうことです。
実際には逆で、詳しくない分野ほどAIの出力をうのみにしやすくなります。
- セキュリティ設計
- 認証・認可
- クラウド構成
- 契約やライセンスが絡む判断
- 障害対応の切り分け
このあたりは、もっともらしい説明が返ってきても、その正しさを判断するのが難しい領域です。
AIは、有識者の代わりではなく、有識者の作業を速くする道具として使う方が安全だと思います。
まとめ
業務開発でAIを使ううえで重要なのは、AIを禁止することではなく、どこまで任せて、どこから人間が責任を持つかを明確にすることです。
迷ったときに毎回ゼロから判断するのではなく、リスクに応じた確認観点をチームで共有しておくと、AIは便利な近道ではなく、管理可能な開発支援ツールとして使いやすくなります。
最低限、次の3つを整理しておくと運用しやすいです。
- 毎回確認したいこと
- 実装内容に応じて確認したいこと
- チーム・会社として決めておきたいこと
AIは便利ですが、責任までは引き受けてくれません。
だからこそ、使い方の前提を決めてから使うのが大事だと思います。
参考
-
OpenAI Business data privacy, security, and compliance
https://openai.com/business-data/ -
OpenAI Help: How your data is used to improve model performance
https://help.openai.com/en/articles/5722486-how-your-data-is-used-to-improve-model-performance -
GitHub Copilot Best practices
https://docs.github.com/en/copilot/get-started/best-practices -
GitHub Copilot code referencing
https://docs.github.com/en/copilot/concepts/completions/code-referencing -
GitHub Copilot policies
https://docs.github.com/copilot/how-tos/manage-your-account/managing-copilot-policies-as-an-individual-subscriber -
OWASP Top 10 for LLMs and GenAI Apps
https://genai.owasp.org/llm-top-10/