プロンプトを運用で育てる

AI機能をリリースすると、必ず「ここをこう直したい」という要望が出ます。もう少し短く、もう少し丁寧に、この種類の入力では別の答え方を。指示文への手入れは、AI機能の運用の中心的な作業になります。

この作業は、やり方を決めておかないと急速に散らかります。誰が何を変えたか分からない、直したら別のところが悪くなった、元の文面に戻せない。本記事では、指示文を手入れし続けるための運用を整理します。基盤や道具を作る話ではなく、変更をどう記録し、影響をどう確かめるかという運用の話です。

まず置き場所を一つにする

最初にやることは、現在使われている指示文がどこにあるかを全員が分かる状態にすることです。当たり前に聞こえますが、これが崩れている現場は珍しくありません。

散らかる典型は次のようなものです。

• コードの中に文字列として埋め込まれ、何か所にも似た文面がある
• 試行錯誤の途中の文面が、コメントアウトされて残っている
• 設定画面から変更できるが、変更の履歴は残っていない
• 誰かの手元のメモに「本当はこう直したい文面」がある

対処は単純で、指示文をソースコードと同じ場所に置き、通常の変更管理に乗せることです。特別な仕組みは要りません。コードと一緒に版が残り、誰がいつなぜ変えたかがコミットの記録に残り、問題があれば戻せます。この時点で、管理上の要求はほぼ満たされます。

業務側の人が文面を直接編集したい、という要望が出たときに初めて、管理画面や外部のサービスを検討します。ただしその場合も、変更の履歴が残ることと、元に戻せることは譲らないでください。

変更の理由を残す

履歴が残っても、なぜ変えたかが残っていなければ、数か月後に判断できません。よくあるのは、後任者が「この一文は何のためにあるのか分からないが、消すのが怖いので残す」という状態です。こうして指示文はひたすら長くなっていきます。

変更のたびに、次の三点を短く書き残してください。

1. どんな入力で、どんな出力になって困っていたか
2. どう変えたか
3. 変えた後、その入力でどうなったか

一行ずつで構いません。この記録があると、後から似た問題が起きたときに「以前これを試したが駄目だった」と分かります。また、指示文が長くなりすぎたときに、どの一文を消してよいかの判断材料になります。

変える前に、確かめる入力を用意する

指示文の変更で最も起きやすい事故は、直した箇所は良くなったが、別の箇所が悪くなることです。ある入力への対応を足したら、それまでうまくいっていた別の種類の入力で挙動が変わる。これは頻繁に起きます。

防ぐ方法は単純です。確かめるための入力を数十件、手元に用意しておくこと。

• 代表的な入力：日常的に来る典型例
• 困った入力：過去に問題になった実例
• 端の入力：極端に短い、極端に長い、想定外の内容

これらを一つのファイルにまとめ、指示文を変えたら全部に対して出力を出し、変更前と並べて読みます。件数が多ければ機械的に比較する仕組みも作れますが、まずは人が読む形で十分です。数十件なら一時間かかりません。

この入力の組は、実データから作ります。ただし、個人情報や機密情報が含まれる場合は、伏せるか置き換えた上で保管してください。

直す前に原因を切り分ける

「出力が良くない」という報告を受けたとき、すぐに指示文を直しにいくのは早計です。原因が別のところにあることが多いためです。

切り分けの順番は次の通りです。

実際の入力を読む。報告された事例の、実際にAIへ渡された内容を確認します。ここで「必要な情報がそもそも渡っていなかった」と分かることがかなりあります。この場合、指示文をどう直しても改善しません。

参照している情報を確認する。社内の文書や商品情報を渡している場合、その情報が古い、あるいは該当する部分が渡っていない可能性があります。

似た入力で再現するか試す。一件だけの事象か、種類として起きているのかで、対処の優先度が変わります。

そこまで確認して指示文の問題だと分かったら、直す。この順番を守ると、無駄な変更が減ります。

想定例：ある企業で、AIによる要約が「いつも当たり障りのない内容になる」という報告がありました。指示文を何度も書き換えても改善しなかったのですが、実際の入力を確認すると、要約対象の本文が文字数の上限で途中で切れていました。原因は指示文ではなく、渡す処理の側にありました。

長くする以外の手を持つ

指示文の改善というと、条件や注意書きを足す方向に進みがちです。しかし、長い指示文には次の問題があります。

• 相反する指示が混ざり、どちらが効いているか分からなくなる
• 後から読んで何が意図されているか分からなくなる
• 入力のたびの処理量が増え、費用と時間に影響する

長くする前に、次の手を検討してください。

特に三つ目は重要です。確実な規則で判定できることは、指示文ではなくプログラムで書く。この線引きを守ると、指示文は本来の役割に集中でき、短く保てます。

誰が変えてよいかを決める

運用として決めておくべき最後の点です。

現実的な分担は、文面の案は業務を知っている人が出し、反映と確認は開発の担当者が行う形です。業務側の人は何が良い出力かを判断できますが、変更の影響範囲までは見えません。開発側は影響を確かめられますが、業務上の良し悪しは判断できません。

避けたいのは、誰でも本番の指示文を直接変えられる状態です。急いで直したい場面でこそ事故が起きます。変更が記録に残り、確かめる工程を通り、戻せる。この三つを保った上で、変更の速さを求めてください。

指示文の管理や変更の運用が散らかってきた、という状況の整理から、AI活用開発・Webシステム開発としてご相談を承ります。お問い合わせよりご連絡ください。ご相談・お見積りは無料です。

本記事は一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。