---

title: "AISPA User-Centric System Prompt Auditing for: LLMアプリ実装で見る設計論点"

description: "システムプロンプトの監査フレームワーク「AISPA」が提示する設計論点を整理します。LLMアプリ開発における透明性・セキュリティ・運用設計の実装判断材料として解説します。"

meta description: "AISPAはLLMアプリのシステムプロンプトを監査するフレームワークです。実装・運用上の論点、既存手法との差分、PoCで確認すべき点をエンジニア視点で解説します。"

date: 2026-08-02

category: LLM開発

tags: [LLM開発, RAG, LLMアプリ開発, プロンプトエンジニアリング]

---

AISPA User-Centric System Prompt Auditing for: LLMアプリ実装で見る設計論点

何が出たのか

2026年8月初旬、「AISPA（AI System Prompt Auditing）」と呼ばれる研究フレームワークが公開され、Hacker NewsやRedditのr/MachineLearningで取り上げられています。AISPAはLLMアプリケーション（大規模言語モデルを組み込んだソフトウェア）において、開発者がモデルの挙動を制御するために設定する「システムプロンプト」を、ユーザー中心の観点から監査・評価するための枠組みです。

システムプロンプトとは、チャットUIや業務システムの裏側でモデルに渡される指示文のことです。「あなたはカスタマーサポート担当者です。丁寧な日本語で回答してください」といった記述がその典型で、ユーザーには通常見えません。商用AIプロダクトの大半がこの仕組みを使っていますが、その内容は公開されることがほとんどなく、規制当局にも開示されていないのが現状です。

AISPAが問題提起しているのは、この「不透明性」です。具体的には、システムプロンプトがユーザーの利益に反する形で設計されていないか、あるいは意図せずそうなっていないかを評価する軸を提供しています。論文では商用LLMアプリのシステムプロンプトを収集・分析し、ユーザーへの影響度を分類するスキームを提案しています。

2026-08-02時点では、論文本体とともにGitHubリポジトリが公開されており、評価スキームの定義ファイルとサンプルデータセットが確認できます。実装ライブラリとしての成熟度はまだ低く、研究プロトタイプの段階です。

---

技術的に面白い点

AISPAの技術的な核心は、システムプロンプトを「ユーザーへの影響」という軸で分類するタクソノミー（分類体系）にあります。

論文が提示する分類は大きく3層に分かれています。第一層は「情報の非対称性」、第二層は「行動制約」、第三層は「利益相反」です。それぞれのカテゴリに対して、プロンプト内のテキストパターンを照合するルールセットが定義されており、LLMを使った自動分類パイプラインと組み合わせて使う設計になっています。

注目すべき点は、分類器自体にもLLMを使っている点です。つまり「LLMのプロンプトをLLMで評価する」という構造になっており、評価精度の担保にメタプロンプト（評価用の指示文）の設計が直接影響します。論文ではこの評価LLMとしてGPT-4系モデルを使った実験結果が示されており、人手アノテーションとのCohen's κ（評価者間一致度の指標）が0.7前後と報告されています。実用上は「まずまず使える」水準ですが、エッジケースでの誤分類は残ります。

もう一つ面白いのは、データ収集の方法論です。AISPAはプロンプトインジェクション（悪意ある入力でシステムプロンプトを漏洩させる手法）を研究目的で体系化し、実際の商用アプリから収集したシステムプロンプトのデータセットを構築しています。これは倫理的な議論を呼んでいる部分でもあり、Hacker Newsのスレッドでは「研究目的でも無断収集は問題では」という指摘と「公開サービスの挙動を調べることは正当」という反論が並んでいます。

実装観点では、AISPAのパイプラインは以下の流れを想定しています。

1. 1.システムプロンプトのテキストを入力として受け取る
2. 2.ルールベースの前処理でカテゴリ候補を絞り込む
3. 3.LLMによる分類・スコアリングを実行する
4. 4.結果をJSONスキーマで出力し、レポートを生成する

この流れ自体は既存のLLM評価パイプラインと大きく変わりませんが、「何を評価するか」の定義（タクソノミー）が整備されている点が差別化要素です。

---

既存の流れとの違い

LLMアプリのプロンプト管理・評価に関しては、すでにいくつかのアプローチが存在します。代表的なものとしてはPromptLayer、LangSmith、Heliconeといったプロンプト管理・ログ基盤があり、プロンプトのバージョン管理やA/Bテスト、レイテンシ計測などを担います。また、セキュリティ観点ではNVIDIAのNeMo Guardrailsや、OWASPが整理するLLMトップ10リスクへの対応ツールが使われています。

これらの既存ツールとAISPAの違いは「評価の主体をユーザーに置いているか否か」です。

既存のプロンプト管理ツールは基本的に「開発者がプロンプトを意図通りに動かすこと」を目的としています。評価軸は精度・コスト・レイテンシが中心で、「そのプロンプトがユーザーにとって公正か」は問いません。NeMo Guardrailsのようなセーフガード系ツールも、主眼は「有害出力の防止」であり、プロンプト設計の透明性や利益相反の検出には踏み込んでいません。

AISPAはこのギャップを埋めようとしています。規制対応（EU AI Actなど）や社内コンプライアンス審査の文脈で「このシステムプロンプトは問題ないか」を確認したい場面に対して、評価の語彙と手順を提供するものです。

ただし、現時点では既存ツールとの統合インターフェースは整備されていません。LangChainやLlamaIndexのエコシステムへのプラグインは存在せず、スタンドアロンのスクリプト群として動作します。実運用に組み込むには相応のラッパー実装が必要です。

RAGシステム（検索結果を組み合わせてLLMに回答させる構成）との関係では、RAGのシステムプロンプトは検索結果の使い方や引用ルールを含むことが多く、AISPAのタクソノミーで「情報の非対称性」に分類されるパターンが出やすいという指摘が論文内にあります。RAGを使っているプロダクトでは特に参照しておく価値があります。

---

実装・運用で気になる点

実際にAISPAをプロダクトや業務システムに適用しようとした場合、いくつかの論点が浮かびます。

評価LLMのコストとレイテンシ: 分類にGPT-4系を使う設計のため、大量のプロンプトを定期監査する場合のAPIコストが無視できません。プロンプト1件あたりの評価トークン数は設定次第ですが、数百〜数千トークンのシステムプロンプトを評価する場合、1件あたり数円〜数十円のコストが発生します。バッチ処理で非同期実行する設計にするか、軽量モデルで一次スクリーニングしてから精密評価に回す二段構えが現実的です。

評価結果のログと監査証跡: AISPAの出力はJSONですが、これをどこに保存し、誰がレビューするかの運用フローは定義されていません。コンプライアンス目的で使う場合、評価結果の改ざん防止や保存期間の設計が別途必要です。既存のログ基盤（CloudWatch Logs、BigQueryなど）への書き出しパイプラインを自前で用意することになります。

プロンプトの秘匿性とのトレードオフ: システムプロンプトは多くの場合、ビジネスロジックや競合優位性を含む機密情報です。AISPAによる評価のためにプロンプトを外部APIに送信することは、情報漏洩リスクになり得ます。評価をオンプレミスまたはVPC内のローカルLLMで完結させる構成が求められる場面では、評価精度とのトレードオフを検討する必要があります。

タクソノミーのカスタマイズ: 論文が提示するタクソノミーは汎用的に設計されていますが、業種・業務によって「問題のある設計」の定義は異なります。金融系アプリと医療系アプリではリスクの重みが違います。タクソノミーのカスタマイズ手順はドキュメント化されておらず、現状はコードを直接編集する必要があります。

フォールバック設計: 評価パイプラインが失敗した場合（評価LLMのAPIエラー、タイムアウトなど）の挙動が未定義です。本番システムの監査フローに組み込む場合、評価失敗時に「未評価」として記録するのか、デプロイをブロックするのかを明示的に設計する必要があります。

---

Spectralの見解

1. 技術的な読み

AISPAは「LLMアプリの品質保証」に新しい評価軸を持ち込んだ点で注目に値します。これまでのLLM評価は精度・安全性・コストが中心でしたが、「プロンプト設計がユーザーに対して公正か」という軸は、規制対応や社内ガバナンスの文脈で今後重要度が増すと見ています。EU AI Actの施行が進む中で、AIシステムの透明性要件への対応ツールとして位置づけられる可能性があります。ただし、2026-08-02時点では研究プロトタイプであり、プロダクション投入には相応の実装コストがかかります。

2. PoCで確認すべき点

• 評価精度の実測論文報告のCohen's κ 0.7は汎用データでの数値です。自社プロダクトのシステムプロンプトに対して同水準が出るかを、手動アノテーションと比較して確認する必要があります。
• ローカルLLMでの代替可能性秘匿性の高いプロンプトを扱う場合、LLaMA 3系やMistral系のローカルモデルで評価精度がどこまで落ちるかを計測することが先決です。
• タクソノミーの業務適合性自社の業務・業種に対してデフォルトのタクソノミーが適切かを、ドメイン知識を持つメンバーと一緒にレビューするステップが必要です。

3. 業務・プロダクト実装に移す時のリスク

最大のリスクは「評価結果の過信」です。AISPAのスコアが良好でも、それはタクソノミーの定義範囲内での評価に過ぎません。法的なコンプライアンス判断の代替にはなりません。また、評価パイプライン自体がシステムプロンプトを外部に送信するアーキテクチャになりやすいため、情報セキュリティポリシーとの整合確認が必須です。導入判断の前に、法務・セキュリティ部門との合意形成を先行させることを推奨します。

---

まとめ

AISPAは、LLMアプリのシステムプロンプトを「ユーザー中心」の観点で監査するフレームワークとして公開されました。タクソノミーによる分類とLLMを使った自動評価パイプラインが技術的な核心であり、既存のプロンプト管理ツールやセーフガード系ツールが扱っていなかった「設計の公正性」という評価軸を提供しています。

実装上は、評価LLMのコスト・秘匿性・フォールバック設計・タクソノミーのカスタマイズが主な論点です。現時点では研究プロトタイプであり、プロダクションへの直接投入よりも、まず自社プロンプトの棚卸しと評価精度の検証から始めるのが現実的な進め方です。

規制対応やガバナンス強化の文脈でLLMアプリの監査フローを整備したいチームにとって、設計の語彙と評価の枠組みを得るための参照先として価値があります。

関連論点として How are tools passed to llm? (final prompt sent: LLMアプリ実装で見る設計論点 もあわせて読むと、この技術動向の背景を追いやすくなります。

Spectralでは、技術調査からPoC設計、プロダクト実装まで支援しています。実現性の確認や事業活用の相談は サービス詳細 と お問い合わせ をご覧ください。