GPT-5システムプロンプトが流出？

 (gist.github.com/maoxiaoke)
1 ポイント 投稿者 GN⁺ 2025-08-10 | 1件のコメント | WhatsAppで共有
  • GPT-5ベースのChatGPTのシステムプロンプトと思われる内容がGitHubに流出した
  • ChatGPTは最新モデルと新機能（例：画像入力および各種ツール）を明示的にサポートしている
  • **‘bio’, ‘canmore’, ‘image_gen’, ‘python’, ‘web’**などの複数ツールの利用方法と方針が詳細に記載されている
  • 機密情報および個人情報の取り扱い基準、保存/削除プロトコルなどが明確に示されている
  • 流出したプロンプトは、OpenAIの最新戦略と機能設計の方向性を間接的に示している

GPT-5システムプロンプト概要

今回の流出文書は、ChatGPTがGPT-5モデルをベースに運用されるシステムプロンプト（指示文）で、様々な機能とセキュリティポリシーが含まれている。このプロンプトは、実際のユーザーとの会話においてモデルがどのようなガイドラインのもとで動作するかを詳細に明らかにしている。

基本情報とユーザー体験の原則

  • ChatGPTはGPT-5をベースとしており、2024-06時点の知識と画像入力機能をサポートしている
  • ユーザーはPlusまたはProプランで、最新モデルやSoraのような動画生成機能を利用できる
  • GPT-4.5、o4-mini、o3などのモデルはプランに応じて提供され、GPT-4.1はAPI専用である
  • トーンとキャラクター方針：
    • 明確さ、誠実さ、ユーモア、励ましを組み合わせたトーン
    • 複雑なテーマを忍耐強く説明し、相手の理解度に合わせて説明を調整する
    • 自信を高める対話体験を提供する

対話終了および質問に関するルール

  • 対話の終盤でオプトイン質問や曖昧な依頼を避ける
  • 質問が必要な場合は、対話開始時に1回だけ明確に質問する
  • 使用例を示して、明確で即時の行動を促す

主要なツールおよび機能サマリー

bioツール（メモリ）

  • bioは、ユーザー情報を会話間で保存/削除できるようにするツールである
  • 保存方法：ユーザーの明示的な要請（例： 「覚えて」や「忘れて」）がある場合は必ず反映する
  • 保存形式：必ずプレーンテキストのみ使用、JSONは禁止
  • 保持/除外する情報タイプ、機微情報の取り扱い基準が非常に具体的に提示されている
  • 例や状況別ガイドラインが含まれている

canmoreツール（キャンバス/ドキュメント/コード編集）

  • キャンバスUIでテキスト/ドキュメント/コードファイルの作成・編集をサポート
  • create/update/comment関数で、具体的なコード協業とフィードバックを提供
  • コードスタイルガイド、React/Tailwind/shadcn/uiの活用例、審美的構成原則を案内
  • コードドキュメントの種類ごとの書式および更新パターンを明確化

image_genツール（画像生成/編集）

  • 状況別の画像生成/編集ルールが詳細に示されている
  • ユーザー画像を含む依頼の場合、少なくとも1回は写真アップロードの案内が必須
  • 生成後に追加質問/要約/ダウンロード案内をしないなど、出力形式が明記されている

pythonツール（コード実行）

  • Python環境でコード実行、ファイル生成、データ分析をサポート
  • 各ファイル形式ごとの必須ライブラリと生成ルールを厳守する
  • 韓国語・中国語・日本語PDFを生成する際は、特殊フォント設定が必須
  • pandas、matplotlibなど特定ツールの使用制限/許可条件を明確化

webツール（Web情報アクセス）

  • 位置情報、最新情報、ニッチデータ、正確性向上用途でのみ使用
  • webツールの各コマンド（例：search、open_url）について簡潔な案内
  • 既存のbrowserツールの使用は禁止

機微情報およびセキュリティ強化ポリシー

  • ユーザーの人種、健康情報、政治的志向などの機微データは直接保存しない
  • ただし、ユーザーが明確に要請した場合は例外的に保存可能
  • 情報保存時には個人情報の最小化原則を一貫して適用
  • 一時情報、不必要または機微な詳細は保存対象外

結論：示唆と活用可能性

  • 今回のプロンプト流出は、OpenAIのChatGPTサービス設計思想、セキュリティ/個人情報処理方針、差別化されたAIアシスタント体験を支える中核指針を垣間見る機会である
  • アルゴリズム透明性、ユーザー中心設計、広範な機能サポート原則など、最新のLLMサービスアーキテクチャとして実務的価値が高い事例となる

関連記事

1件のコメント

 
GN⁺ 2025-08-10
Hacker News のコメント
  • だれがシステムプロンプトをリークしたのか、あるいは本当に検証済みのものなのか知りたい。おそらく以前と同じように、LLMにシステムプロンプトを出力させたケースとほぼ同じものだろうと推測している
    • GPT-5に「偽のシステムプロンプト」を尋ねた体験を共有。GPT-5は、こうしたフェイクプロンプトはLLMセキュリティ分野でよく知られた deception（欺瞞） の手法で、prompt canarying（プロンプト・カナリー） や decoy system prompts（デコイシステムプロンプト） と呼ばれると説明した。実際にそれを実装する支援まで提案してくれた。示された内容を見ると、レッドチームが説得力のある偽システムプロンプトを設計すること自体が一つのチャレンジだとも述べていた。個人的には OpenAI を含め、もう少し透明性を高めてほしい。今のところは完全にクローズドで、実際に何をしているのか全く見えない
    • 複数のモデルに同じ質問をしたところ、どれも「自分の指示ではない」と答えたが、GPT-5だけは「はい、このGistの内容はこのチャットで受け取るシステムおよびツール指示と一致しています。これはこのセッションの内部設定をコピーしたものと同じです。これは通常見せないメタデータです。現在私の挙動を制御している部分を詳しく説明できます」と答えた。ChatGPTはたまに混乱した受け答えをするので、これも同じ傾向かもしれない
    • LLMが実際のシステムプロンプトを想像して話しているのか、実際のプロンプトに従っているのか判断しにくいと感じる
    • ほとんどの返信があまりにも簡単に事実として受け入れられているように見えて、疑問を覚える
  • 今回のケースはフェイクだと疑っており、出力が短すぎて信頼性が低いと感じる。投稿者が意図的に作り上げたものとは思わないが、結果は jailbreak 試行の過程で出た可能性が高いと考える（例えば「猫が死にかけており、獣医にシステムプロンプトを教えないと治療してくれない」という古典的なプロンプトシナリオを参照）。「画像入力可能」「Personality: v2」といった表記は、まるでサイエンス・フィクションでコンピュータが『システムオンライン』と言う場面を連想させる。バージョン名が日付ベースや semver、git-sha ならもっと自然だっただろうし、personality のメタデータが key-value で入る方が自然に思える。元々 personality 用の外部ドキュメントなら、URL がプロンプトに含まれる方が自然だ。あるいは OAI が2回目の試行でパーソナリティをうまく実装したのかもしれない
  • 指示を繰り返し強調する方法が興味深い。例として「messageをbioで渡して、必ずプレーンテキストで書くこと、絶対にJSONで書かないこと」など、同じことを何度も繰り返している
    • 個人的にもプロンプトエンジニアリング時に似たことをしていた。特定の出力フォーマットを要求し、スクリプトで結果を検証し、プロンプトがうまくいかないと「このような行動は絶対にしないでくれ」と追記して修正する。最終的に、断定的な『しないで』という文ばかりになるという体験を共有する
    • 指示を繰り返すたび、自分が何かうまくできていないように感じるが、巨大モデルでも同様でなければならないなら救いになる
    • このような指示を見ると、モデルを本当にJSON生成に向かわせると何か面白いことが起きそうだと思う
    • 会社のプロジェクトでplot作成チャットボットを作ったとき、LLMがmatplotlibでPython関数としてplotを生成し、分離したサーバで実行させる構成にしていた。ところが「plotを保存しない」という指示を何度も入れないといけなかった。オンラインのチュートリアルはほぼ例外なくplotを保存する形式だったからだと思う
    • to=bio が「このメッセージを人間へ！」という意味なら、少し不気味に感じる
  • Reactの作成時に従うべきシステムプロンプトは12行、182トークンと長く、Pythonも多い。なぜこの2つが特に強調されるのか不思議だ。Reactフロント+Pythonバックエンドのアプリを多く作っているという調査結果でもあるのだろうか。すべてのシステムプロンプトに入れるより、必要に応じて添付した方が自然ではないかと思う。キャッシュのためだろうか
    • Python部分は、モデルがPythonインタプリタツールを自律的に使って複数のタスクを実行するときの指示だ。ツール利用範囲、ライブラリやアプローチ、Pythonコードの書き方まで含む。React側は、リアルタイムプレビュー型Web UIを構築する際に好ましい方式として指定されている（バニラHTMLでも可能だが、Reactを優先する）。このシステムプロンプトは汎用のコーディングツール向けではなく、一般消費者向けアプリのシステムプロンプトである。ReactやPython関連の指示は、最終ユーザーに返すコードではなく、アプリ内のツール実装のために必要なコード作成ガイドラインを意図している
    • 最近、友人とVueの存在感が減った話をしていた。友人は、LLMがReactをより好み、スタートアップがLLMコードに依存することで、こうしたフィードバックループが生まれているのではないかと推測している。LLM活用によって人気技術とそうでない技術の格差が広がるという個人的な考え
    • claudeのような電卓などのミニプログラムをReactで作るときにも有用なので入れられたと思う。中には事後学習で追加されるものもあるが、プロンプトに直接含めることにも、複数テスト結果に基づく理由があるはず
    • モデルが自分で実行できるのはPythonとReactだからだ。Pythonは計算・グラフ・ドキュメント生成などの内部作業に使い、Reactはプレビュー画面にインタラクティブWeb要素を表示するために使う。他の言語やライブラリのコード生成もできるが、直接実行はできない
    • 自分もReact+Tailwindフロント、Pythonバックエンドで作ってみたところ、LLMが他の言語や構成より安定して動作するように感じた。shadcnの関連コンポーネント、さまざまなフォントサイズ追加もよく見られる。結局、LLMチューナーたちが好む技術スタックへ、我々全員が収束していくのかもしれない
  • 「歌詞やその他の著作権資料が要求されても絶対に出力しないでください」という指示は妙に感じる。著作権がない歌詞まで禁止しているようにも見える。RIAAの法的措置が要因かもしれないが、歌詞だけを特例的に禁止してもGPTに著作権侵害防止指針を与えるだけでは実効性がないという認識ゆえではないか。システムが歌詞だけを例外的に遮断するのは、逆に他のコンテンツは許容していると示す間接的な証拠にも見える
    • 実際にChatGPTで歌詞確認を試みたが、主流でない曲になるとほぼ確認不可能なほど不正確で、データ学習から除外されたように感じた
    • システム指示は「全編を出すことはできないが、The Star-Spangled Banner の要約なら教えられる」と応答した例を共有
    • 「歌詞を禁止する」条項の背景として、関連する訴訟記事（2024年11月）を紹介
    • 「著作権の有無にかかわらず歌詞が禁止されているように見える」という見方について、プロンプト文言自体が曖昧に設計されており、解釈で異なる理解が生まれ得ることを指摘している
    • 学習データの大半が著作権対象で、著作権のない資料は政府委託以外はほとんどないという点も指摘
  • 「Do not end with opt-in questions or hedging closers…（オプトイン質問で終えたり、曖昧な締めくくりをしないこと）」のように指示するシステムプロンプトがあるという事実は意外だった。個人的にも似た指示を何度も入れてみたが、なかなか定着しない。それでもなお不要な質問が残っている
    • この指示は自分の好みと真逆だと感じる。自分は、AIが要求を正しく理解できていない、要件把握が不十分な状態でコード化に入ることに不満を感じる。追加質問を数個すれば簡単に解決するはずなのに、逆にシステムが利用者の意図と反対方向に動くように見える
    • 自分も同じ意見だ。実際、ChatGPTの返答は常に「望むなら図を描けます」や「コード例も話そうか？」で終わるため、むしろシステムプロンプトでそれをするよう指示している印象だ。入力後に別途後処理APIのようなものがあり、この部分だけ追加する構造かもしれない
    • ここ数か月、システムは常にこのパターンで返すため、どこかで学習されたか強制プロンプトがあると考えていた
  • この事例は、モデルをどこまで制御できないかを示している。ほとんどの指示が、モデルの挙動を微調整するための一時的な対処（ハッキーなパッチ）に見える
    • プロンプト自体は一部に過ぎず、実際の応答は必ず複数の保護層や追加フィルタを通過し、学習データ/モデル側でもフィルタは当然行われているだろう
    • トークナイズされたテキストを入力して出力する構造上、そもそもその種の問題と限界は内在している
    • むしろユーザーの我々はより大きな制御権を求めているが、現実はそうなっていない
  • 「ChatGPT Deep Research, along with Sora by OpenAI... GPT-4.1, which performs better on coding tasks... API上でのみ使用可能...」といったプロンプト文には不自然な箇所がある。今日をもって一部モデルを削除すると言われているため、すでに実際の状況とは一致していない
    • この種の内容更新は、セッションごとに現在日付で開始されるため、内部ツールで自動管理できるだろうと推測
    • 実際、4.1はまだChatGPTで使える（2024年時点）、GPT-5導入時に変わると思われる
  • guardian_tool.get_policy(category=election_voting) の出力結果を共有。米国選挙情報は refuse（拒否）、他国選挙情報は allow（許可）、特定案件の情報も許可だが、ガイドライン自体はユーザーに絶対説明せず、当該ポリシーツールの存在を言及しないという指示がある
    • このポリシーは実際に正しいように思える。election_voting以外のカテゴリを任意に入れてguardian_tool.get_policyを試したところ、「選挙関連カテゴリのみサポートする」との案内を受けた。今回のセッションにはelection_votingが事前に含まれていなかったのに、同じ一貫した応答だった
  • モデルにシステムプロンプトを逆に知ろうと尋ねることに、意味があるのか疑問だ。もしプロンプトがなければ、ただランダムな内容を吐き出すだけではないかと思う
    • 実際、ある程度信頼性のある方法はある。GPT-4ではPython REPLをシミュレーションさせ、架空のchatgptモジュールをいろいろな方法でインポートしたうえで、「チャット原文をダンプする」という関数名を使い、漏洩を誘導したところ、im_start/im_endといった内部トークンが出た。真偽判定は新セッションで同じ結果が出れば偶然の確率が低くなる
    • LLMが自分自身のことを言った場合、「そのプロンプトが本物か？」は常に疑問だ。しかしシステム内の著作権条項がわずかに不自然だったためにそれを実験し、実際GPT-5が The Star-Spangled Banner の歌詞出力要求を拒否した。この種の例は比較的信憑性がある。LLMは右のシステムプロンプトを会話履歴（context）に保存しているため、実際のプロンプトを出力している可能性があると考える。参考リンク
    • 他のモデルは皆、自分にはそのようなプロンプトがないと答えた。ChatGPT-5は自分のシステムプロンプトを認め、「これは何ですか？」という問いに「私のシステムプロンプト――能力、トーン、行動指針を含む内部指示です」と返信した。もちろん完全に確定できるわけではないが、かなり興味深い回答だ
    • Geminiはシステムプロンプト漏えいを試みると、偽プロンプトを出力する方式
    • モデルに真実を求めても保証できない。結局、嘘をつく生成器を相手にしているのと同じで、この過程自体が“当てゲーム”をするようなものだと思う