AIが提案したコードで画面が動いた。テストも通った。けれど、このまま仕事の成果物として提出してよいのか迷うことがあります。
判断するときは「動くか」だけでなく、利用が許可されているか、扱った情報に問題がないか、仕様に合っているか、人が確認して採用できるかを分けて考えます。コードの形を少し変えれば確認不要になる、という話でもありません。
この記事では架空の問い合わせ管理を例に、提出前に確認した事実と未確認事項を残す方法を紹介します。特定の製品の性能や契約条件を比較する記事ではありません。利用できる範囲は、所属先の規程と採用する製品・契約・設定を確認してください。
まず利用許可を確かめる
会社でAIを使ってよいという話があっても、どのアカウントで、何の作業に、どの機能を使えるかまで同じとは限りません。個人契約で使える範囲と、業務契約で認められる範囲を混ぜないようにします。
確認するのは「このサービスを使えるか」だけではありません。コードの提案を受けること、リポジトリを参照させること、ファイルを書き換えること、コマンドを実行させることも、それぞれ作業範囲が異なります。
たとえば「架空の入力検証について相談する」は認められていても、顧客のリポジトリへ接続するには別の手続きが必要かもしれません。判断がつかない場合は、担当する管理者に利用目的と渡す情報を示して確認します。
許可はコードが正しいことを保証しません。ここで確認するのは、その作業を始めてよい条件です。
情報管理は、入力欄だけを見て終わらせない
次に、何をAIへ渡すかを確認します。顧客の問い合わせ本文、氏名や連絡先、認証情報、内部の接続先などを、そのまま例題へ使わないようにします。
自分で貼り付ける文章のほか、参照対象のファイル、ログ、添付資料、ツールが取得する情報も対象です。見えている質問文だけを架空の名前に置き換えても、添付したログに元の値が残っていれば同じ確認は済んでいません。
この例なら、入力チェックの相談に実際の顧客データは必要ありません。「件名は必須で1〜100文字。状態は下書き・受付済み・対応中・完了。投稿者と担当者がいる」という架空の条件で考えられます。
匿名化したつもりでも利用許可の確認は残ります。保存期間、学習への利用、共有先、ログの扱いは製品や契約・設定によって確認箇所が変わるため、「業務用だから何を渡してもよい」とは決められません。
もし入力してはいけない情報を渡した可能性に気づいたら、操作を止め、所属先の報告手順に従います。履歴を消しただけで対応が済んだと判断しないことが大切です。
仕様適合は、許可されない操作からも確かめる
説明用に作った、次の疑似コードを考えます。実際にAIから得た出力ではありません。
もし件名の長さが1〜100なら、件名を更新する
短く分かりやすく見えても、「誰の問い合わせを」「どの状態で」変更できるかがありません。今回の架空仕様を「投稿者が自分の下書きだけ編集できる」と決めたなら、他人の下書きや受付済みの問い合わせは拒否する必要があります。長さが正しい件名で保存できた、という確認だけでは足りません。
仕様との照合では、次のように許可・拒否の両側を置きます。
| 確認する条件 | この例で期待する動き |
|---|---|
| 自分の下書き、件名1文字と100文字 | 更新できる |
| 空の件名、101文字の件名 | 更新できない |
| 他人の下書き | 更新できない |
| 自分の受付済み・対応中・完了 | この編集操作では更新できない |
| 保存先への処理が失敗した | 成功したと表示しない |
これは最低限の例であり、すべてのテストを列挙したものではありません。空白だけの件名、文字数の数え方、同時更新、エラー時に見せる情報などは実際の仕様に合わせて確認します。
権限は画面のボタンを隠すだけで済ませず、処理を受け付ける側でも検証する必要があります。OWASPは権限の確認をすべてのリクエストで行う考え方を示しています。OWASPの認可チェック指針
知らないAPIが出てきたら、使っているバージョンの公式資料で存在、引数、戻り値、失敗時の動作を確認します。提案された説明とコードが同じことをしているかも読みます。単体テストの具体例はServiceをJUnit・Mockitoでテストする方法で補えます。
採用判断は「確認済み」と「未確認」を分けて残す
利用許可、情報管理、仕様適合を一つの「チェック済み」でまとめると、何を確認したのか分からなくなります。下の表は、途中段階の採用判定票の例です。
| 領域 | 状態 | 記録する内容 |
|---|---|---|
| 利用許可 | 確認済み | 承認済みの契約・用途・作業範囲を利用 |
| 情報管理 | 確認済み | 架空データだけを使用、参照対象を確認 |
| 仕様適合 | 未確認 | 件名の境界は確認したが、権限拒否の試験が未実施 |
| 採用判断 | 要相談 | 権限部分の確認後にレビュー担当と判断する |
未確認欄が残っているこの例では、採用可にはしません。一方で、相談用の途中成果として共有することまで禁じる必要はありません。「採用前の確認を依頼している」と状態を明確にします。
提出時には、目的と関係のない変更が混じっていないか、依存先が増えていないか、テストが期待する動きを確認しているかを差分で読みます。コードを直した後は、前に通ったテストが現在の差分に対する結果なのかも確認します。
変更の一部だけを提出したつもりでも、別の編集が混ざることがあります。差分の見方はstagedとunstagedの違いを参照してください。
レビューを依頼するときの記入例
確認結果は長いAIとの会話をそのまま渡すより、判断材料を短くまとめます。社内のAI利用報告ルールがあれば、その形式に合わせます。
件名の入力検証案の作成に、許可されたAIを利用しました。顧客情報は使わず、架空条件を入力しています。件名の下限・上限と必須違反、他の利用者からの編集拒否を確認しました。保存失敗時の表示は未確認です。この点を確認後に採用を判断したいので、処理の失敗時の扱いをレビューしてください。
「AIがそう言っていた」は仕様や安全性の根拠にはなりません。根拠にするのは、合意した仕様、公式資料、現在の差分、確認結果です。SQLを組み立てる処理など、自分だけで判断しにくい部分はSQLインジェクションと対策のような個別の論点も確認し、必要に応じて詳しい人へ依頼します。
個人の学習でも、仕様と結果を確かめる考え方は使えます。ただし会社の採用判断や情報管理手続きを、そのまま個人の実験へすべて持ち込む必要はありません。作業の影響とルールに合う確認を選びます。
次にコードを提出するときは、四つの領域に「確認済み・未確認・要相談」のどれかを書いてみてください。全部を自信ありにすることより、採用を止めている未確認事項を一つ具体化することが、次の作業を決める助けになります。
