INSIGHT
AIで作った試作品、次に何を直す？——使い続けるための改善の進め方
試作品の価値を残しながら、使い続けるための仕事をどの順で確かめるか。
AIと一緒に作った営業メモの画面を、同僚に使ってもらった。「入力が楽になった」と言われるとうれしい。検索や通知も足したくなる。一方で、担当外の案件を開けないか、入力を間違えたら直せるか、作った自分が休んだらどうするかは、まだ確かめていない。
ここで「全部作り直すしかない」と考える必要はありません。ただ、機能を足す前に、今の試作品で役立ったことと、まだ結果のない確認を分けてみます。この記事では営業メモを説明用の例に、自分の成果を残しながら次の改善へ進む道筋を考えます。
作った試作品で、誰のどの仕事が楽になったか
まず、機能名ではなく、使う人の仕事で書きます。「営業担当が訪問後のメモを入力し、翌朝には確認する人が案件の状況を追える」。誰が何を入れ、誰がいつ結果を使うかが見える文です。
使ってもらった際の入力例や、直してほしいと言われた箇所も残します。現場の言葉で作った画面、期待する出力、操作で迷ったところは、次の確認に使える材料です。試作品だからと捨てるものではありません。
そのうえで、次に変えたい利用条件を書き添えます。三人から別部署へ広げるのか。架空の案件から顧客情報へ替えるのか。見るだけだった結果を、承認や外部送信に使うのか。画面が同じでも、確かめる範囲は変わります。
できたことと、まだ確かめていないことを分ける
棚卸しは、次の三列から始められます。
| 分けるもの | 営業メモの例 | 残す材料 |
|---|---|---|
| 確認できたこと | 試験用の案件を登録し、検索できた | 入力例、結果、確認した人 |
| まだ確かめていないこと | 別の担当者の案件を変更できないか | 試す条件と、確認を頼む先 |
| まだ用意していないこと | 作成者が不在のときの問い合わせ先 | 必要な仕事と引受け先 |
「未確認」と「欠陥」は違います。確かめる前から失敗と決める必要はありませんが、成功した扱いにもできません。未確認を一つの作業として書けば、漠然とした不安を、次に試す条件へ変えられます。
NISTのSecure Software Development Framework は、ソフトウェア開発の過程へ安全な開発実務を組み込み、脆弱性やその影響を減らすための枠組みです。試作品の品質を認定するものではありません。画面ができた後にも確認や対応の仕事が続く、と捉える参考にします。
困っている一件から、次に直すところを選ぶ
一覧の上から順に、全部を同じ深さで直す必要はありません。顧客情報が見える、外へ送られる、取り消しにくい処理がある、止まると仕事が続かない。そうした影響と、今の困りごとを合わせて一件を選びます。
たとえば「案件を確定するボタンがあるが、誰が押してよいかを分けていない」。この場合はボタンの見た目より、確定できる人の条件を先に考えます。「安全にする」では広すぎるので、「一般利用者は下書きを保存できるが、案件の確定は承認者だけが行う」と、試せる文にします。
業務上、誰を承認者にするかは作成者だけで決める話ではありません。利用する人へ仕事の条件を聞き、権限の設定方法は開発・管理の担当へ確かめます。自分に分からない部分を、AIの説明だけで埋めなくてよいのです。
AIが外部の操作まで担う場合には、AISIのAIセーフティに関する評価観点ガイド第1.20版の公表説明 が示す「観測と制御」も参考になります。評価観点があることと、自分の仕組みが安全と確認できたことは別です。
直したら、通常の操作と外れた場合を試す
条件が決まったら、修正後の結果を確かめます。先ほどの例なら、承認者が確定できることだけでなく、一般利用者が確定できないことも見る必要があります。
使うのは、許可された試験環境と架空の案件です。試験用の権限をどう用意すればよいか分からなければ、開発担当へ「この二つの結果を確かめたい」と渡します。本番の利用者設定を勝手に変えたり、実際の顧客案件を確定したりして試すことはしません。
「AIは直したと言っています」ではなく、対象の版、使った入力、操作した人、期待した結果、実際の結果を残します。期待と違えば、その違いが次の修正材料になります。原因まで説明できなくても、観察した結果は渡せます。
自分で分からない確認と、使い続ける仕事を担当へつなぐ
試験が通っても、それだけで利用を広げる判断までは済みません。どの版を公開するか、戻す必要が出たら誰が対応するか、問い合わせをどこで受けるかを、担当へつなぎます。
渡す資料は、AIとの会話の全量でなくても構いません。目的、扱う情報、外部接続、変更したところ、試験結果、未確認、設定の保管先、連絡先。次の人が同じ状態を確認できる材料を選びます。認証情報そのものを共有メモへ貼るのではなく、管理された保管先とアクセス方法を確認します。
DORAの2025年レポートの公式紹介 は、AIが組織に既にある強みと弱みを増幅するという見方を示しています。ここから自社の工数や品質の改善率は分かりません。道具だけでなく、仕事を受け渡す仕組みにも目を向ける材料です。
作った本人が全部を保証する必要はありません。自分が確かめたことと、別の人へ頼む確認を分け、宙に浮かせないことが大切です。
一つの改善を、確認と運用への引継ぎまで通してみる
まず、試作品で役立った仕事を一つ書き、その隣に次の改善を一つ置いてみてください。「案件の確定を承認者だけにする」なら、業務の条件、試験、公開、問い合わせの受け手までつなぎます。
一件を通すと、次も同じ手順で進められるところと、別の支援が必要なところが分かります。機能を増やす速さに、確かめて引き継ぐ道筋を足す。それが、試作品を使い続けるための次の一歩です。