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