- 公開日
AIに「専門家として説明して」と頼むと、注目する論点や説明の組み立てを誘導できます。ただし、その指定は専門資格の取得でも、契約の承認権限の付与でもありません。役割を使うときは、どの観点で考えてほしいかを示し、判断に必要な資料と、実行してよい操作を別に定めます。
契約の文章を読みやすく整理してもらうだけなら、求める観点と出力を短く指定できます。一方、契約条件の採否を決める、取引先へ回答する、契約管理システムを更新するといった仕事では、人の判断とシステム上の権限制限を追加する必要があります。役割名が同じでも、任せる仕事の影響は同じではありません。
役割は説明の方向を示す
ここでいうロールは、AIへ与える「校正担当」「契約内容の整理担当」などの役割です。ペルソナは、丁寧さ、説明の詳しさ、話し方といった人物像に近い指定を指します。両者は重なることがありますが、業務では人物らしさより、何に注目し、何を出力するかを明確にする方が管理しやすくなります。
Anthropicの公式ガイドは、システムプロンプトで役割を指定する方法を、用途に応じて振る舞いと語調の焦点を合わせる手段として紹介しています。これは同社のモデル向けの案内であり、あらゆるモデルで正答率が上がるという保証ではありません。Prompting best practices
例えば「編集者として読む」なら、文章の重複や読者がつまずく箇所に注意を向ける意図があります。「購買担当者の観点で読む」なら、納品条件や費用の確定状況を整理する意図があります。役割名だけでは観点が曖昧なので、「納品物、支払条件、未確定事項を分ける」のように作業へ落とすと、回答後に満たしたかを確かめられます。
注意したいのは、説明の変化と知識の正しさが別だという点です。専門用語が増えたり、断言が強くなったりしても、新たな資料を確認した証拠にはなりません。役割によって既に学習した内容の引き出し方が変わる可能性はありますが、その指示だけで新しい法律、社内ルール、当事者の事情が供給されるわけではありません。
契約の説明と、契約を判断する仕事を分ける
架空の例として、社内研修用に作った契約条項をAIへ説明させます。実在の契約や取引先情報は使わず、次の二行だけが与えられた材料とします。
- 納品物の受領後、発注者は十営業日以内に確認結果を通知する
- 契約変更は当事者間の書面による合意で行う
最初の依頼が「あなたは経験豊富な弁護士です。この契約に問題がないか判断してください」だけなら、何をもって問題とするのかが不明です。二行の説明で足りるのか、契約全体を審査するのか、どの法域で扱うのかも分かりません。経験や資格を持つ存在として自己紹介する回答が出ても、その文章は資格確認には使えません。
この場面では、役割を次のように狭められます。
「契約内容の整理を支援する担当として、提示した二行を説明してください。各条項について、書かれている義務、文面だけでは分からない条件、担当者に確かめる事項を分けてください。契約全体の適否は結論せず、資格や実務経験を持つと名乗らないでください。」
この依頼で期待するのは、第一の条項について「受領後に確認結果を通知する」「営業日の定義と受領日の扱いは、この抜粋では未確認」と整理する出力です。第二の条項では「変更に書面合意を求めている」と説明しつつ、どの方法を当事者が書面として扱うかは、関連する定義や契約全体を確認する事項として残します。法的効力や具体的な期限日を、この材料から確定する例ではありません。
この例の「十営業日」は架空の文面にある条件で、一般的な契約に必要な期限を示していません。AIが七日や二週間に言い換えていないか、通知と承認を同じ意味にしていないかを原文と照合します。役割による説明が整っていても、この照合を省く理由にはなりません。
専門家役から得られないもの
専門家という役割名には、知識、資格、責任、権限が一緒に見えやすい問題があります。しかし、AIへの依頼では一つずつ分ける必要があります。資格は該当する制度や登録などによって確認するもので、生成した自己紹介では確認できません。社内で誰が契約条件を受け入れられるかも、職務上の権限や承認手続によって決まります。
AIが出した「承認します」という文章も、社内の承認者が内容を確認した記録の代わりにはなりません。特に、画面上で「法務担当AI」などと表示する場合は、何を支援し、誰が判断を引き受けるのかを同じ画面や業務手順で分かるようにします。人に似せた肩書を付けるほど、利用者に任せてよい範囲を誤解させない説明が必要です。
NISTのAI RMF（任意利用の枠組みで、1.0は現在改訂中と案内されています）は、GOVERN 3.2で、人とAIの組合せや監督について役割と責任を定義し区別する方針・手順を挙げています。これは役割名を作れば監督が成立するという意味ではなく、人がどこで関与するかを定めるための管理上の観点です。AI RMF Core
実務では、出力に「確認済みの条文」「解釈が必要な点」「判断者へ渡す質問」を分けておくと、人が判断材料を受け取りやすくなります。回答全体へ一度だけ「参考です」と付けても、個々の断定が強いままなら誤解は残ります。不明な適用条件は、その結論の近くへ残すことが大切です。
説明だけなら簡潔に、操作を任せるなら設定も変える
同じ契約説明でも、研修用の架空条項を読むだけなら、外部送信や契約更新の機能は要りません。説明の対象を限定し、出力と原文を照合する手順を置けば、実行承認の工程を文章整形にまで持ち込まずに済みます。ただし、実在資料を入力する場合は、そのサービスへ送ってよい情報かという確認が別に必要です。
次に、整理した内容を契約管理システムへ登録する仕事へ変えるとします。役割指定が同じ「契約内容の整理担当」でも、今度は記録を書き換える副作用があります。下書きの作成、登録内容の確認、承認、登録実行を分け、AIが役割を理由に登録範囲を増やせないようにします。
NISTの用語集は、最小権限を、割り当てられた仕事に必要な最小限の資源や権限にアクセスを絞る考え方として説明しています。AIのツールにもこの考え方を適用し、閲覧だけの仕事には更新権限を渡さない設計が考えられます。least privilege
ここで、プロンプトに「勝手に変更しない」と書くことと、更新できない設定にすることは別の対策です。前者は振る舞いへの指示、後者は実行可能な操作の制限です。人による承認を置く場合も、承認対象の契約、変更内容、判断者を確認できるようにし、単なる会話上の同意を無制限な操作許可へ広げません。
役割を短い作業条件へ書き換える
使っている依頼文に大きな肩書が並んでいたら、まずその役割に期待する仕事を一文で書きます。「専門家として完璧に答える」なら、「提示資料の条件と未確認事項を分けて説明する」へ直します。専門家を模倣する表現を減らしても、必要な観点は残せます。単純な日付の抜き出しのように観点がはっきりしている作業なら、役割を書くより、資料と抽出する欄を示す方が直接的です。
役割を重ねるほど良くなるわけでもありません。「厳格な監査人」「親切な相談員」「最終決裁者」を同時に指定すると、文章の調子と判断権限の話が一つの依頼に混ざります。役割には読者、観点、出力形式のうち必要なものだけを持たせ、資格や権限は別の根拠で確かめます。
次に、出力を誰が何に使うかを添えます。研修の理解補助なら、用語の説明と確認問題が役立ちます。契約担当者へ引き継ぐ資料なら、原文の場所と確認すべき条件が必要です。用途が変われば出力も変えますが、資格や権限まで自動的に変えません。
最後に、実際の回答で、原文にない確約や判断が加わっていないかを見ます。役割名を変えるだけで修正できなければ、資料の不足、依頼の曖昧さ、ツール権限の広さをそれぞれ見直します。役割は説明の焦点を合わせる入口として使い、事実の確認と行動の許可は、それぞれ確かめられる根拠で支える設計にします。
ロール指定の効果を同じ条件で比べて確かめる方法は「ロール指定で変わる口調・観点・正確さを分けて確かめる」で解説しています。
ロールプレイで制約を外そうとする入力への備えは「ロールプレイによる制約突破に備えて役割と権限を分ける」で解説しています。
