AIが書いたコードを社内で使う前に。出所・秘密・レビュー

動きそうな短いコードも、何を読み、どこへ書き、何を送るかを確認する。

依頼した仕事と、コードの操作を比べる

GitHubの公式資料は、Copilotによる変更も取り込む前に十分確認するよう説明しています。SONAEは、社内の小さな自動化でも、目的と実際の操作を照合する方法を提案します。資料の形式を変えるだけのはずが、外部の接続先や不要なファイル操作を含んでいないかを確認します。コードの説明をAIに書かせることは補助になりますが、その説明だけで実際の動作を確認できたと判断しないようにします。

本番の資料や秘密を、最初から渡さない

確認前のコードへ顧客情報、本番の接続情報、広い権限を与えない計画にします。入力と出力の場所、接続する相手、必要な権限を明確にし、架空データだけの隔離した検証を準備します。APIキーなどをコードやAIへの質問へ貼らない運用も必要です。GitHubが示す秘密の検出機能は参考になりますが、検出されないから秘密がないと保証するものではありません。利用できる機能と対象範囲は契約や設定で確認します。

追加する部品と、利用の条件を確かめる

AIが示したパッケージやコードの参照先が実在するか、公式の配布元か、必要な機能かを調べます。依存関係、更新の状態、利用許諾の条件は別の確認事項です。出典が書かれた場合も実物を確認し、法的な判断が必要なら適切な担当へ相談します。この記事は特定のライセンスへ適合したとの判断を示すものではありません。不要な依存を減らし、追加する理由をレビューする人へ説明できるようにしましょう。

成功する例と、失敗する例を用意する

架空のCSVを変換する例なら、通常の行、空のデータ、想定外の項目、文字化けしそうな入力などを用意します。元の資料を上書きしないことや、失敗した時に途中の出力をどう扱うかも確かめます。テストをAIに生成させても、実際に知りたいことを確認しているかは人が見ます。すべての動作を証明する試験ではなく、合意した用途の受入条件を確かめる計画として範囲と限界を残します。

実行する仕組みの変更にも目を向ける

コードだけでなく、自動で動く設定、接続権限、配布の方法も確認します。GitHubの案内は、ワークフローが秘密や強い権限へアクセスできる点にも注意を示しています。自社の構成では、誰が実行を認め、どこまで操作でき、何を記録するかを確認しましょう。AIが作った変更をそのまま自動承認する設定へ、理由を確認せず切り替えないようにします。実行環境の変更は、コードの見た目とは別の判断です。

業務へ入れた後の、持ち主を決める

作った人しか使い方や止め方が分からないと、異動後に困ります。対象の業務、入力と出力、必要な環境、確認した版、残る制約、管理担当、停止と戻し方を記録します。完了条件は、目的に合う動作を架空データで確認し、コードと権限をレビューした上で、管理する人が引き受けたことです。検証した範囲と未確認の作業も明記し、担当変更後に判断を追える形にします。

相談前の確認表

• 目的とコードの操作を照合した
• 本番データや秘密を使わず検証を計画した
• 依存関係と利用条件を確認した
• レビューと運用担当の承認を分けて残した

参考資料（確認日：2026年10月23日）：GitHub Docs：Review output from Copilot ↗ ／ GitHub Docs：Secret scanning ↗

一般的な説明とSONAEの運用提案です。製品の公式条件と自社の管理責任者の判断を確認してください。