連載「業務SEのための仕様駆動開発」第4回
会社でAIを使いたい。でも、何に気をつければいいのか
会社の仕事でAIを使いたい。でも、何に気をつければいいのかが整理できていない。お客様の資料を渡してよいのか、費用はどこまでかかるのか、出てきたものをどこまで信じてよいのか。気になることはいくつもあるのに、どこから考えればいいのか分からない。そんな状態の方は多いと思います。
社内にルールがあれば、それに従えば済みます。ただ、中小企業の案件では、AIの使い方についてのルールがないことがほとんどです。その場合、判断するのは現場の私たちです。
結論：6つを、使う前に確認する
業務でAIを使う前に、私は次の6つを確認しています。
情報・置き場・コスト・根拠・最終判断・出所
どれも、エンジニアなら普段から気にしていることです。新しい知識は要りません。ただ、相手がAIになると、いつもの確認が抜けやすくなります。だから、使う前に一覧で見直します。
型：業務でAIを使う前のチェックリスト
各項目に、自分に問う質問を1つずつ付けています。コピーして使ってください。
# 業務でAIを使う前のチェックリスト
- [ ] 1. 情報：渡すものの中に、個人情報・業務の中身・秘匿事項が入っていないか。入っているなら、許可を取ったか
- [ ] 2. 置き場：AIに渡したものと、AIと作ったものは、どこに残るか
- [ ] 3. コスト：費用は誰が払い、どこまで使うと止まるか（または請求が増えるか）
- [ ] 4. 根拠：AIの出力が正しいかを、自分で判断できるか。できないなら、何で確かめるか
- [ ] 5. 最終判断：元に戻せない操作（本番データの更新など）を、最後に実行するのは誰か
- [ ] 6. 出所：AIに組み込む拡張機能・設定・プロンプトの中身を、自分で読んで確かめたか
答えが「分からない」になった項目は、AIを使い始める前に調べるか、関係する人に聞きます。6つすべてに答えが出てから始めます。
見直すのは、案件の始めと、AIに任せる作業の範囲が変わったときです。たとえば、コードの相談だけに使っていたAIに、データの加工も任せることにしたとき。渡すものが変わるので、1つ目の答えも変わります。
この6つは、目的確定メモの「制約」になる
チェックリストの答えは、確認して終わりにはしません。文書に書いておきます。
第1回で、AIに要件定義を書かせる前に、人が「目的」「合格ライン」「制約」の3つを決めると書きました。6つの答えの多くは、この「制約」に入ります。たとえば「お客様の顧客名はAIに渡さない」「本番データの更新は人が実行する」といった形です。さらに、第3回で紹介した「やってはいけないこと一覧」に入れておけば、テスト仕様書にも反映されます。
ウォーターフォールでも、セキュリティや運用の決め事は、作り始める前の要件定義で決めます。仕様駆動開発（SDD）でも同じです。作るのがAIに変わっても、先に決めておく順番は変わりません。
1つだけ深掘り：「渡してよいか」は、種類ではなく中身で決める
6つのうち、ここでは1つ目の「情報」だけを深掘りします。お客様の仕事でAIを使うとき、最初に判断が要るのがここだからです。
「ソースコードなら渡してよい」「顧客データはだめ」のように、データの種類で線を引きたくなります。でも私は、種類よりも、中に何が入っているかで判断しています。
私の場合、ソースコードは、AIサービスの設定で入力を学習に使わない状態にしたうえで、基本的に渡してよいと考えています。ソースコードもお客様の持ち物であることが多いのですが、それが私の立場です。
ただし、ソースコードでもエラーログでも、中に次のものが入っていれば、許可を得るまで渡しません。
- 個人名・顧客名・連絡先といった個人情報
- 業務の内容に関わるもの
- 秘匿事項
逆に言えば、情報によっては、お客様に許可を得たうえで渡すこともあります。許可の取り方は、相手によって違います。大きな会社には社内ルールがあることもあり、その場合はそれに従います。中小企業ではルールがないことがほとんどなので、担当者と話し合ったり、責任者や経営者に確認を取ってもらったりしています。
チェックリストの1つ目の問いが「中に何が入っているか」と「許可を取ったか」の2段になっているのは、このためです。
私の場合：会社名を渡してよいか、考えた
個人情報を多く扱う業種のお客様の仕事をしたときのことです。お客様の顧客の個人情報は、私はいただいていませんでした。それでも、その会社の名前や業務内容をAIに渡してよいのかは、少し考えました。
決め手になったのは、そもそも自分が何を預かっているかでした。具体的な個人情報も、業務の具体的な中身（どんなお客さんに、どんなことをしたか）も、私は預かっていません。預かっていないものは、渡しようがありません。そこで、会社名と業務内容までなら問題ないだろうと、私は判断しました。
別のお客様では、商品登録の手伝いをAIでやりました。お客様のオリジナル商品の情報をAIに渡して、登録用のデータを作らせる作業です。こちらは、お客様の持ち物そのものを渡すことになります。そこで、作業を進める前にお客様に確認して、許可を得ました。
自分が預かっている範囲なら、自分で判断する。お客様のものを渡すときは、持ち主に聞く。2つの場面で、私はこう分けて判断しました。
まとめ
- 業務でAIを使う前に、情報・置き場・コスト・根拠・最終判断・出所の6つを確認する
- 各項目に問いを1つずつ。答えが「分からない」なら、始める前に調べるか聞く
- 答えは、目的確定メモの「制約」と、やってはいけないこと一覧に書いておく
- 情報を渡してよいかは、データの種類ではなく、中に何が入っているかで決める
- 入っているなら、許可を得るまで渡さない。社内ルールがなければ、相手の責任者に確認してもらう
次回は、AIに設計書を書かせたあと、人がどこを見てダメ出しをするのか、その観点を紹介します。
連載「業務SEのための仕様駆動開発」
一覧はこちら → https://qiita.com/sha44444/stocks/3c9167054a4a82837bb3
この連載では、仕様駆動開発の「型」を1回に1つずつ紹介しています。
5つの工程を実案件でどう回しているか（各工程でAIに渡す依頼文、変更が入ったときの回し方、通しの実例）は、1冊の本にまとめました。第1章は無料で読めます。
→ https://zenn.dev/shin4/books/31499dd20de8ac