ソフトウェア開発へのAIの使い方と注意：品質・権利・情報の扱いを確かめる

自社の「ユースケースと効果」の準備度は？10問・約3分で確かめる（無料・登録不要）

コードの補完・作成・説明、テストの作成などを助けるAIが、開発の進め方を変えつつあります。指示を受けて複数のファイルを書き換え、テストの実行まで進めるAI（コーディングエージェント）も使われています。速さが上がる一方で、品質・権利・情報の扱いの注意点も生まれています。システムを開発・運用する会社や開発を委託する会社に向けて整理します。

ソフトウェア開発のどこに、AIが役立ちますか？

古いシステムの中身の説明や、別の言語への書き換えの下書きは、属人化しているシステムの保守でも役立ちます。

一方で、AIはもっともらしいが誤っているコードを書くことがあります。動くかだけでなく、意図どおりか、安全か、保守しやすいかを人が確かめる前提で使います。

AIが書いたコードは、どう確かめればよいですか？

人が書いたコードと同じか、それ以上の確かめ方をします。

① 書いた人が内容を説明できる状態にする：AIの出力を、理解しないまま取り込まない決まりにします。レビューの際に「なぜこう書いたか」を説明できることを目安にします。

② レビューとテストを通す：自動のテストと、人のレビューを通してから取り込みます。AIにテストも書かせる場合は、テストが確かめるべきことを確かめているかも見ます。

③ 安全でない書き方を探す：入力の値の確かめ漏れ、権限の確かめ漏れ、秘密の情報の書き込みなどがないかを確かめます。脆弱性を探す道具（静的解析など）を組み合わせると、見落としを減らせます（脆弱性の管理）。

④ 取り込む部品を確かめる：AIが提案した外部のライブラリ（部品）が、実在し、信頼できる提供元のものか、ライセンスの条件と脆弱性の情報はどうかを確かめます。

部品の管理にSBOMを使う

経済産業省の「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver2.0」は、SBOMを、ソフトウェアの部品とその依存関係の情報を含む、機械で処理できる一覧と説明しています。日本語では「ソフトウェア部品表」とも呼ばれます。

手引は、ソフトウェアが直接使う部品だけでなく、その部品がさらに使っている部品まで把握しないと、脆弱性への対応が不十分になるおそれがあることを指摘しています。SBOMを使うと、部品に脆弱性が見つかったときに、影響があるかどうかを特定するまでの時間を短くできるとしています。また、オープンソースソフトウェア（OSS）のライセンスに違反した場合、販売の停止や回収、罰金の支払い、企業のブランドイメージの低下などの影響を受けるおそれがあり、すべてのOSSのライセンスを確かめて、それぞれに従う必要があるとしています。

AIを使うと、取り込む部品が増えやすくなります。部品の一覧を保ち、ライセンスと脆弱性を確かめ続ける仕組みを、AIの利用とあわせて整えておくと安心です。

AIが書いたコードの権利は、どう考えればよいですか？

著作権法は、著作物の例として「プログラムの著作物」を挙げています（第10条第1項第9号）。あわせて、プログラムの著作物の保護は、プログラムを書くための言語、規約、解法（コンピュータへの指令の組み合わせの方法）には及ばないとしています（同条第3項）。

文化審議会著作権分科会法制度小委員会の「AIと著作権に関する考え方について」は、生成AIで生成物を出力し、それを利用する段階での著作権の侵害は、AIを使わずに人が創作する場合と同様に考える必要があるとしています。既存の著作物との類似性と依拠性の両方が認められれば、著作権の侵害になり得るという整理です。

開発の現場では、次の点を確かめておくと安心です。

• AIの出力に、既存のコードとよく似た長い部分が含まれていないか
• 似た部分が見つかった場合、元のコードのライセンスの条件を満たせるか
• 使うAIのサービスの利用規約で、出力の扱いや権利についてどう定めているか

この考え方の文書は、法的な拘束力を持つものではなく、特定の技術について確定的な評価をするものではないとされています。判断に迷う場合は専門家に確かめてください。考え方の全体は「生成AIと著作権」で整理しています。

ソースコードや秘密の情報は、どう扱えばよいですか？

ソースコードには、業務の仕組みや取引先との連携の方法など外に出したくない情報が含まれるため、AIに読ませる前に次の点を決めます。

• 使うツールを決める：会社として認めたツールに限り、入力したコードの扱い（学習への利用、保存の期間、保存する場所など）を契約や設定で確かめます（ツールの選び方）。
• 秘密の情報を書かない：パスワードやAPIキー（外部のサービスを使うための鍵）を、コードやAIへの指示に直接書かない運用にします。総務省の「AIのセキュリティ確保のための技術的対策に係るガイドライン」も、AIに設定する指示（システムプロンプト）にAPIキーなどの機密の情報を直接書かないことを対策に挙げています。
• 営業秘密としての管理を保つ：営業秘密として守りたい情報は、AIを使う場面でも管理の仕方を決めておきます（営業秘密とAI）。

開発を外部に委託している場合は、委託先がAIをどう使っているか、ソースコードをどのツールに入力しているかも確かめておくと安心です。

AIに任せる範囲は、どう決めればよいですか？

AIが自分でファイルを書き換えたり命令を実行したりする使い方では、AIに何をさせてよいかを決めておくことが大切です。

• 権限を必要な分に絞る：AIが触れてよいフォルダやリポジトリ、実行してよい命令を限ります。本番の環境や本番のデータベースには、直接触れさせない設計から始めます。
• 隔てた環境で動かす：試す環境を分け、問題が起きても影響が広がらないようにします。
• 変更は人が確かめてから取り込む：AIの変更は、レビューを通してから取り込む手順にします。
• 記録を残す：AIがどんな操作をしたかを後から確かめられるようにします。

総務省のガイドラインは、AIエージェントそのものは対象外としていますが、開発環境での開発者の権限の管理や、記録（監査ログ）の保存を、基本の対策として挙げています。権限の決め方は「AIエージェントの安全な使い方」と「権限設計シート」、コードを書かない人がAIでツールを作る使い方の注意は「バイブコーディング」をご覧ください。

チェックリスト

• 使ってよいツールを決め、入力したコードの扱いを契約や設定で確かめている
• AIの出力を理解しないまま取り込まない決まりにしている
• AIのコードも、レビューとテストを通してから取り込んでいる
• 安全でない書き方を探す道具やレビューの観点を用意している
• AIが提案した部品が実在し、信頼できる提供元のものかを確かめている
• 部品の一覧（SBOMなど）を保ち、ライセンスと脆弱性を確かめ続けている
• パスワードやAPIキーを、コードやAIへの指示に直接書いていない
• コーディングエージェントの権限を絞り、本番の環境に触れさせていない
• AIの操作と変更の記録を残している
• 開発の委託先のAIの使い方を確かめている