主要LLMの「内部指示書」を集めたGitHubリポジトリ asgeirtj/system_prompts_leaks が39,944スターを突破した。ChatGPT、Claude、Gemini、Grokなどの system prompt が一覧で読める。「AIの脳内が丸見え」と話題だが、本当にそこに競争優位の核心があったのか。むしろこの熱狂は、業界が prompt engineering を過大評価してきたことの裏返しでもある。

何が起きたか

GitHubで公開されている system_prompts_leaks は、ChatGPT (GPT-5.5 Thinking)、Claude (Opus 4.7、Opus 4.6、Sonnet 4.6、Claude Code)、Gemini など、主要LLMの内部 system prompt を抽出してまとめたアーカイブだ。スター数は約4万。GitHub Trending の常連と化しており、AIをプロダクトに組み込むエンジニアや、社内チャットボットの設計を担当する企業が「お手本」として参照している。

抽出方法は俗に言う prompt leak — モデルに巧妙な質問を投げて内部指示を吐かせる手法で、各社が公式に承認したものではない。だが OpenAI も Anthropic も「system prompt は秘密ではない」と従来から表明しており、法的にグレーというより、企業側が黙認しているのが実情だ。

なぜこのニュースが重要か

このリポジトリの本当の価値は「秘密の暴露」ではなく、各社の設計思想を横並びで比較できる教材になったことにある。Anthropic が Claude にどれだけ「正直さ」と「害の回避」を冗長に書き込んでいるか、OpenAI がツール呼び出しの優先順位をどう構造化しているか、Google が Gemini にどんな安全フィルタを積層しているか — これらが diff で読める。

ここから見えるのは、各社の prompt が想像以上に泥臭く、長く、ad hocであるという現実だ。Claude の system prompt は数千トークンに膨れ上がり、エッジケースを潰すための「もし〜なら」が積み重なっている。これは美しい工学ではなく、運用で発覚した問題に応急処置を当て続けた結果である。

つまり、フロンティアラボの prompt も、皆さんの会社のレガシーコードと大差ない。

過剰評価への反論

このニュースに対する反応で最も気になるのは「prompt が企業の資産になる時代」という言説だ。これは半分正しく、半分は2023年頃から繰り返されてきた幻想の再演である。

第一に、prompt そのものに持続的な競争優位はない。2023年に「ChatGPTの神プロンプト集」を有料note で売っていた人たちはどこへ行ったか。モデルが世代交代するたびに、前世代向けに最適化された prompt は陳腐化した。GPT-4向けの Chain-of-Thought 誘導は GPT-5世代ではほぼ不要になり、Claude Opus 4.7では同じ指示が逆効果になることすらある。Prompt はモデル依存の揮発性資産であり、特許でも商標でもない。

第二に、「自社プロンプトの流出対策が急務」という論調も、優先順位を見誤らせる危険がある。流出して困るのは prompt ではなく、そこに埋め込まれた業務ロジック、データソース、顧客固有情報のほうだ。prompt を金庫にしまっても、API ログ、ベクトルDB、RAG のソース文書のガバナンスが甘ければ意味がない。過去にも「アルゴリズムを秘密にすれば勝てる」と信じた企業が、結局はデータと運用品質で負けた事例は数えきれない。

第三に、4万スターという数字自体を割り引いて見る必要がある。GitHub のスターは「あとで読む」のブックマーク代わりに使われており、実際にこれを業務に活かしている人は一桁少ないだろう。awesome-list 系リポジトリが10万スターを超えても、産業を変えなかったのと同じ構造だ。

経営者・実務者が取るべき動き

では無視していいのかというと、そうではない。使い方を間違えなければ、これは安価な benchmark になる。

  1. 自社の prompt を「Claude や ChatGPT の system prompt と比べて何が足りないか」で監査する。 特に安全性、refusal の設計、ツール呼び出しの優先順位など、自前で考えても抜け漏れが出やすい領域は参考になる。

  2. prompt をコードと同じく version 管理し、モデル更新ごとに回帰テストする運用を作る。 資産化すべきはテキストそのものではなく、評価データセットと CI パイプラインのほうだ。

  3. 「prompt が漏れたら終わり」のアーキテクチャを設計しない。 Prompt は公開されても困らない前提で、認証、データアクセス、監査ログで守る。これはセキュリティの基本に立ち返るだけの話である。

  4. prompt engineering を専門職として固定化しすぎない。 モデルが賢くなるほど、長大な prompt は不要になっていく。長期的にはむしろ評価 (eval) を設計できる人材のほうが希少価値を持つ。

AIの「中身」が読める時代になったのは確かだ。しかし読めるようになった瞬間に、その中身は競争優位の中心ではなくなる。本当に守るべきものは、もっと地味な場所にある。


動画でも詳しく

動画は記事冒頭の埋め込みからフル尺で視聴できます。

主な出典