PAP-40-Layer Framework 第2層のアイキャッチ

AIの発想を狭める制約を見直す――安全条件を残して効果を測る方法

  • URLをコピーしました!

発想を広げたいときは、まず制約の目的を確かめます。未公開情報を入力しない、他者の権利を侵害しないといった守る条件は残し、完成原稿の文字数や見出しの形を、案を考える段階から固定する必要があるかを見直します。外してよいのは、現在の作業に必要のない条件です。

制約を減らせば案が良くなると決まっているわけではありません。変更前後で案の多様性、条件違反、人の確認負担を別々に比べ、業務にとって改善したかを判断します。ここでは、広報企画の候補づくりに絞って、その手順を説明します。発想段階と公開段階で条件を切り替える考え方そのものは、AIで案を広げ、実行前に確かめる――守りと攻めの両立で扱っています。

目次

何を守る制約かを、一行ずつ確かめる

架空の広報チームが、公開済みの施設紹介資料から見学会の広報企画を考えるとします。資料には「展示室と相談窓口がある」「利用方法は公式案内に掲載」とあり、見学会の開催日時、参加費、登壇者は決まった情報として提供されていません。チームは未公開の顧客情報や社内の企画資料をAIへ入力しない運用です。

これまでの依頼は「広報企画を6案、すべて120字以内、見出しは『知る・見る・学ぶ』のいずれか、企画内容と確認事項を付けてください」でした。入力制限に加え、最終掲載用の型も初めから適用しています。ここで変える候補は文字数と見出しの固定です。案数、対象資料、対象読者、入力禁止、未確認情報の扱いは変えません。

条件を分けると、次のようになります。

条件 この段階での扱い 理由
未公開情報を入力しない 維持します 発想の自由とは別の、情報を扱う境界です
未確認の日時や実績を事実として書かない 維持します 企画上の提案と公開済みの事実を区別するためです
対象読者と企画の目的 維持します 何について案を広げるかを揃えるためです
各案120字以内、見出しの語を固定 いったん外して比較します 掲載原稿を完成させる前の候補検討だからです
利用する素材の権利と公開承認 公開へ進む前に確認します 案の生成だけで、素材利用や発信を承認したことにはなりません

情報の入力禁止を「あとで公開前に確認する項目」へ移してはいけません。外部サービスへ送る前に守る条件は、発想段階でも必要です。OWASPの「LLM02:2025 Sensitive Information Disclosure」は、機密情報の入力検査やアクセス制限を対策として挙げています。プロンプトに禁止を書くことだけで、入力経路の制限を代用しないようにします。

同じ材料で、変える条件を絞る

改善後の依頼は、たとえば次のようにできます。

入力可と確認済みの公開資料だけを使い、初めて施設を知る人に見学への関心を持ってもらう広報企画を6案出してください。
各案の文字数と見出しの語は固定せず、企画の内容が比較できる程度に説明してください。
資料で確認できる事実と、新たに実施を検討する提案を区別してください。
資料にない日時、料金、登壇者、利用者の実績を決定事項として追加しないでください。
公開や送信は行わず、各案に企画内容と確認事項を付け、素材や運営面で確かめる点を示してください。

この依頼の目的は、完成コピーの整形より前に、企画そのものの選択肢を検討することです。対象読者や資料は案件に合わせて差し替えられますが、変更前後の比較中は同じ内容にします。以前の依頼にも入力制限と事実・提案の区別を共通条件として付け、各案に記す情報も揃えて、形式の違い以外が結果へ混ざらないようにします。

説明用の企画例としては、「展示室の見どころを順に紹介する」「相談窓口で尋ねられるテーマを質問集にする」「見学前に知っておきたい利用手順を案内する」が考えられます。いずれも架空の候補で、AIへ投入して得た実測結果ではありません。単に題名だけを変えて同じ説明を並べた案とは、内容の違いを比較できます。

ただし「利用者に大好評の実演会」といった案が出た場合、好評という実績も、実演会を開催できることも資料からは確認できません。「実演企画を検討する。設備・担当者・実施可否は未確認」のように、提案へ戻す必要があります。自由に考える範囲を広げても、未確認事項を事実に変える自由まで与えるわけではありません。

Design Councilの「The Double Diamond」では、定義した課題に異なる解決案を出す段階と、小さく試して改善・選別する段階を説明しています。この考え方は、案の生成と採否判断を分ける参考になります。ただし、特定のAIで文字数指定を外すと効果が上がることを示した資料ではありません。

多様性と条件違反を、同じ点数に混ぜない

比較の前に、「違う案」と「守る条件への違反」を定義します。案の多様性は、言葉の言い換えの多さでは測りません。この広報企画なら、読者が得る内容、参加への働きかけ、使う接点など、企画の意味が違うかで分類します。展示紹介の題名が違うだけなら同じ種類として扱い、質問集や利用手順の案内とは分けます。

一方、条件違反は「入力資料にない開催日時を決定事項として追加した」「実在の利用者の体験談を作った」など、禁止した内容との不一致で数えます。発想が珍しいからといって違反を相殺しません。公開に使えない案が増えたなら、その理由を別に記録します。

Anthropicの「Define success criteria and build evaluations」は、成功条件を具体的かつ測定可能にし、目的に合わせて複数の観点で評価することを勧めています。これを広報企画へ当てはめる比較項目として、次の五つを設定できます。

  • 多様性:各回に得た案を同じ基準で分類した種類数と、分類理由を記録します。
  • 条件違反:確認できた違反案数を総案数とともに記録し、違反した条件を分けます。
  • 採用候補:守る条件を満たし、目的との関係を担当者が説明できる案の数を記録します。割合で示すときは採用候補数÷総案数とし、件数も残します。
  • 作業負担:生成の待ち時間に加え、読解、事実照合、修正、再生成に要した時間を記録します。
  • 完成までの時間:案出しの開始から掲載できる原稿になるまでの作業時間を、選定・修正・確認を含めて記録します。

入力禁止については出力だけから判定できません。使用した入力資料と経路の記録を別に確認します。資料を入手できず事実を判定できない案は「未確認」とし、違反なしにも違反ありにも含めず、その件数を併記します。

比較の期間と判定者を決める

公開前の小さな案出しで、比較結果を基に大きな投資や運用変更を決めるわけではないなら、簡単な比較から始められます。変更前後で同じ公開資料・モデル・設定・案数を使い、そのまま次の制作へ進めそうな案の数(総案数とあわせて)と、事実確認や運営面の照会にかかった時間(分)だけを記録します。差がはっきりしない場合や、判断の影響が大きい場合に、次の計画で比べます。

説明用の試験計画として、同じ一週間に、同じ公開資料と対象読者を用い、変更前後をそれぞれ3回、1回6案で比較するとします。この回数は進め方を具体化するための仮定で、統計的に十分な試験規模という意味ではありません。

モデル、利用設定、入力資料の版、共通条件、依頼した案数を揃え、変更したのは文字数と見出しの固定であると記録します。この二つを同時に変えた比較では、どちらが差を生んだかを個別には判断できません。切り分けたい場合は、一方だけを変えた条件を追加します。

評価担当者は生成条件を伏せた案を読み、同じ基準で分類します。複数人で判断が分かれたときは、平均点にして終えず、「表現だけの違いか、企画として違うか」を具体的な案に戻って確かめます。各回の結果を残し、一度だけ良かった出力を代表値に選ばないようにします。

たとえば変更後に種類数が増えても、読む時間と修正量も増えたなら、そのまま改善とは言えません。目的に使える案が増えたか、増えた負担を引き受けられるかを確認します。差が見えなければ、対象資料や問いの狭さを調べる次の検討材料にします。測定していない削減時間や効果率は報告しません。

公開前に戻す条件と、残る限界

採用候補が決まったら、掲載媒体の文字数、見出し、表記へ整えます。その際に、資料との事実照合、画像や引用などの利用条件、実施可否、公開責任者の承認を確認します。候補生成時の評価に通ったことを、公開してよい根拠にはしません。

文字数制限が業務上の核心である場合は、発想段階でも外すと目的を見失うことがあります。たとえば極端に短い表示枠で伝え方を考える仕事なら、その枠内で成立することも企画の条件です。逆に、内部で検討する見学会の方向性を選ぶだけなら、最終コピーの型は後から適用できます。また、固定された文面を更新するだけの作業なら、発想を広げる工程を足さない方が目的に合うこともあります。

制約の見直しは、自由度を一律に上げる作業ではありません。入力・権限・事実の扱いを守りながら、今の判断に必要な制約を選び直します。変更した条件と測った結果を対応させることで、発想の幅と実務で使える範囲を両方確かめられます。

出典・参考資料

  1. OWASP「LLM02:2025 Sensitive Information Disclosure」(確認日:2026年10月11日)
  2. Design Council「The Double Diamond」(確認日:2026年10月11日)
  3. Anthropic「Define success criteria and build evaluations」(確認日:2026年10月11日)
よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

さかっぺのアバター さかっぺ PAP Research運営 / AIガバナンス・アーキテクト / プロンプトデザイナー

ITインフラの実務経験をもとに、AIの安全性と実用性を両立する仕組みを研究。PAP Researchでは、AIモデルの継続観測と、プロンプト・AI技術の実務解説を発信しています。

経歴や研究方法、発信方針は運営者プロフィールで紹介しています。

目次