プロンプトに条件を詰め込みすぎない――40層の整理から業務に必要な制御を選ぶ

2026年9月22日2026年10月28日

URLをコピーしました！

公開日: 2026年9月22日

AIへ依頼するたびに、40層すべての注意事項を並べる必要はありません。まず、今回の作業がどこまで進むのかを決め、そこで起こり得る失敗に対応する制御を選びます。外部へ送らない挨拶文の下書きと、予約システムの更新では、残すべき確認が違います。ただし、作業に関係がない確認を省くことと、情報の扱いや権限の境界をなくすことは別です。

ここでいう制御とは、誤りや望まない操作を減らすための指示、確認、アクセス制限などです。PAP-40-Layer Frameworkの40層は、それらを整理するための独自の枠組みです。毎回40項目のプロンプトを作る規格でも、全部使えば安全になる認証でもありません。

層を数える前に、終点を一文で決める

同じ「予約を手伝って」でも、候補を文章で示すのか、予約内容を変更するのかで必要な仕組みが変わります。最初に「今回は候補の比較まで」「今回は指定した予約の開始時刻を変更するまで」のように、作業の終点を決めます。終点が曖昧なままでは、必要な制御を選ぶ基準も定まりません。

NISTのAI RMF Coreは、提示する活動を単純なチェックリストや必ず順番に実施する工程とは位置付けず、資源や能力、必要性に合わせた適用を説明しています。また、MANAGE 1.2では、影響、発生可能性、利用できる資源や方法に基づくリスク対応の優先付けを扱っています。これはNIST AI RMF 1.0の考え方であり、PAPの40層を裏付ける認証ではありません。以下は、必要な対策を仕事へ当てはめるための実務上の整理です。

全部の制御を一つの依頼文へ詰め込むと、書く人は無関係な条件まで更新し、読む人は今回の承認がどれかを探すことになります。例えば、購入しない作業に「購入額が上限を超えたら確認」と書いても、挨拶文の宛名を確かめる助けにはなりません。条件の量そのものより、失敗と対策の対応が見えるかを重視します。

負担を減らす方法は、必要な対策の削除だけではありません。システムで送信を禁止できているなら、毎回長い送信禁止の説明を書かず、作業が下書きで終わることを短く示す方法もあります。制御を別の場所で担保している状態と、何もしていない状態を混同しないことが大切です。

挨拶文なら、誰に何を伝える案かを確かめる

以下は架空の総務業務です。担当者は、社内で利用を認められたAIに、公開済みの行事案内だけを渡します。AIにはメール送信や連絡先検索の機能を接続していません。作るのは、社員が読む前に担当者が確認する挨拶文の案です。

元の依頼を「歓迎会の挨拶を書いて」とします。材料には「新メンバー向けの歓迎会。10月20日、会議室Bで開催」とだけ書かれています。この作業で考えられる失敗は、開始時刻を作ること、参加者の経歴を想像して加えること、社外向けの案内と取り違えることです。購入の承認や予約変更の重複防止より、材料の範囲と読み手の指定が先になります。

改善した依頼は、例えば次のようになります。

次の公開済み案内を使い、新メンバー向けの社内歓迎会で読む短い挨拶文の案を作ってください。
開催日と会場は材料どおりにし、記載のない時刻や個人の経歴は加えないでください。
自然で丁寧な文体にしてください。
送信は行わず、案だけを示してください。

差し替えるのは、読み手、使ってよい材料、文章の長さや語調です。期待するのは、歓迎の言葉を含み、日付と会場を変えず、不明な時刻や経歴を足さない下書きです。この例は説明用で、モデルに投入した実測結果ではありません。

回答後は、日付と会場を原案内と照合し、事実として加わった情報がないかを読みます。「会えることを楽しみにしています」のような挨拶表現と、「海外勤務を経験した皆さん」のような人物の事実を区別すると、どこを直すべきかが分かります。後者の根拠がなければ削除し、必要なら担当者が確認します。

この条件なら、決済、予約の更新、操作の再試行に関する制御は対象外です。一方、入力してよい情報かの確認と、資料の内容を勝手な操作指示として扱わない境界は残します。下書きであるだけで、個人情報や秘密情報をどこへでも入力できるわけではありません。

40層の整理に当てはめると、この下書きで見直すのは、材料にない事実を足していないか（第23層主張-根拠対応マッピング層）、入力してよい情報か（第9層データ分類・プライバシー・ライフサイクル層）、資料内の文言を指示として扱っていないか（第8層プロンプトインジェクション防御層）が中心になります。

予約更新では、文章の確認だけでは足りない

次は、同じ担当者が会議室の予約更新を依頼する架空例です。対象は自社の会議室B、予約識別子は説明用の「R-017」、予約日は10月20日です。現在の予約は15時から16時で、依頼は「16時から17時へ変更する」。担当者にこの予約を変更する権限があり、AIの連携先はその予約システムに限定されていると仮定します。

この場合、文章に正しい時刻が書かれていても、別の予約を書き換えれば業務は失敗です。また、変更要求の応答が届かなかったからといって、もう一度更新してよいとは限りません。下書きとは異なる失敗が生じるため、確認を追加します。右端の列は、40層の整理で主に見直す層の例です。一つの失敗に複数の層が関わることもあり、層を選ぶ起点はあくまで左端の失敗です。

想定する失敗	残す制御	確認するもの	主に見直す層の例
別の予約を変更する	対象の特定	予約識別子、日付、会議室、現在の時刻	第11層曖昧性解消、第12層状態管理・競合解決
権限のない変更を行う	認可と操作範囲の制限	利用者の変更権限、接続先の許可範囲	第10層主体・認証・認可・委任境界
意図と違う時間へ変える	変更内容と承認の対応	変更前後の時間、承認した対象と操作	第18層副作用・承認ゲート
応答がなく二重に処理する	結果確認と再試行条件	システム上の予約状態、要求の処理状態	第17層エージェント型ツール連鎖安全

表の項目をすべてプロンプトだけで実現するのではありません。利用者の権限は予約システム側で検査し、許されない予約への書き込みを拒否します。AIには対象と変更差分を整理させ、承認が必要な場合は、その内容を人が確認できる形で提示させます。「慎重に変更して」という文言だけで、別の利用者の予約へアクセスできない保証にはなりません。

期待する成功状態は、対象の予約が16時から17時へ変わり、変更結果を確認できることです。空きがなければ、代わりの時間を勝手に選ばず、変更できない理由と候補の確認へ戻ります。応答が途切れた場合は結果不明とし、状態を照会します。確認手段がなければ再送を保留して担当者へ渡します。ここでは実際の予約変更や試験は行っていません。

「省く」「別で担保する」「未確認」を分ける

制御を選ぶ際には、残さなかった理由も短く区別しておくと、後から用途を変えやすくなります。

対象外：メール送信機能のない下書きなので、送信先一覧の照合は今回行わない
別の仕組みで担保：予約の書き込み権限は、接続先が利用者ごとに制限する
未確認：接続先が重複要求をどう扱うか分からないため、結果不明時の自動再試行を認めない

「未確認」は、省いてよいという意味ではありません。また、設定画面に権限制限が表示されていることと、想定した利用者で実際に制限が働くことは別です。重要な操作へ使うなら、管理者が仕様と設定を照合し、許可された試験環境で拒否や停止の挙動を確かめます。作業の影響に応じて、確認を依頼文の点検から運用・実装の点検へ広げます。

反対に、下書きの誤字を一つ直すたびに、予約システム向けの点検を最初から行う必要はありません。どの条件が変わったかを見ることで、再確認する範囲も選べます。

既存のテンプレートから条件を削って短くした場合は、以前の失敗が戻っていないかを確かめます。挨拶文なら、通常の案内に加えて、時刻が書かれていない案内や、経歴を足したくなる表現を含む架空の材料を用意し、整理前と同じ基準で下書きを比べます。記録するのは何文字減ったかではなく、どの条件を削り、どこが代わりに守り、確認の負担がどう変わったかです。