ChatGPT・Gemini・Claudeの共通プロンプト原則を試した

ChatGPT、Gemini、Claudeのどれを使うかは、人によって違います。
有料で契約しているサービスも、普段いちばん手になじむAIも、人それぞれでしょう。

一方で、世の中のプロンプト論には「ChatGPTならこう」「Claudeではこの書き方」といった話が多くあります。
モデルが更新されるたびに、昨日までの定番が効かなくなるという話も聞きます。

それなら特定のモデルだけに効くテクニックとは別に、AIや世代が変わっても残る根幹があるか確かめよう！！
ということで、3社の公式プロンプトガイドを読み比べ、共通項だけで作った依頼文を同じ条件で試してみます。

結果として、3社が揃って推奨する設計原則は8つありました。
その共通項だけで組んだ依頼文を、3つのWebチャットで同じ課題・同じ文面のまま27回試したところ、書いた条件は3サービスとも毎回守られ、書かなかった条件はほぼ守られませんでした。
「万能の書き方」があるわけではありません。件数を縛れば何かが落ち、自由に書かせれば余計な親切が混ざりました。

この記事は、ChatGPT・Gemini・Claudeを仕事や日常で使っていて、モデルを乗り換えても使える基本形と、毎回のやり直しを減らす方法を知りたい人向けです。

この問いを具体的にしたFable 5のガイド

この問いを実際に調べてみようと思わせたのは、Anthropicの「Prompting Claude Fable 5」という公式ドキュメントでした。
新モデル向けの調整方法を並べたページかと思いきや、「旧モデル向けに細かく書き込んだ指示やスキルは、新しいモデルではむしろ品質を下げることがあるので見直せ」という趣旨のことが書かれています。
プロンプトの「定番テクニック」は、モデルの世代が変わると負債になり得る——公式がそう述べているのです。

だからこそ、世代やベンダーが変わっても持ち運べる部分を、OpenAI・Google・Anthropicの公式資料から探し、実際に試すことにしました。

3社の公式ガイドは三層構造になっている

調べてみると、3社とも公式のプロンプト資料は用途別に層が分かれていました。
今回は2026年7月13日時点で取得できた16本を、次の三層に分類して読みました。

見落としやすいのは、どの層の話かでガイドの推奨が変わることです。
ネットで見かける「プロンプトのコツ」は、層を区別せずに混ざっていることが多くあります。
今回は通常のWebチャットで検証するため、一般利用者向けの層を主資料に、API向けは補助として使いました。
なおOpenAIのヘルプには「一部はAPI向け資料だが、推奨内容自体はChatGPTにも当てはまる」という一文があり、層をまたいだ流用にも一応の公式根拠があります。

3社に共通していた8つの原則

3社の資料に共通して登場した原則は、次の8つでした。

いくつか注記があります。
5の「区切り」は3社ともAPI向け資料にしか登場しません
また、記法は各社バラバラで、「XMLタグ」はAnthropicの例示にすぎません。
共通するのは「指示とデータを区別できるようにする」という考え方です。
8の「自然な言葉で」は逆に一般向け資料だけの共通項で、呪文めいた定型文の対極にあります。
OpenAI Academyには「プロンプトの書き方に唯一の『完璧な』正解はない」という文言まであります。

共通ではなかったもの

横断して初めて分かるのは、共通「しない」推奨の存在です。

役割・ペルソナの設定を一般向け資料で明確に推すのは、Googleだけでした（Gemの指示は「Persona・Task・Context・Format」の4要素で書けと明記）。
OpenAI・Anthropicの一般向け資料には登場しません。「あなたはプロの編集者です」から書き始める型は、3社共通の作法ではありません。

「ステップ・バイ・ステップで考えて」は、世代依存の代表です。
OpenAIのReasoning best practicesは、推論モデルに対してこの種の指示は「不要で、むしろ害になり得る」と明記しています。
GeminiもClaudeも現行世代は思考処理を内蔵しており、外から考え方の手順を指定する必要性は薄れています。

prefill（応答の書き出しを与えるテクニック）は、Anthropicが公式に廃止しました。
Claude 4.6以降のAPIではエラーになります。かつての定番が公式から消える実例です。

temperatureなどのパラメータ調整はAPI限定のうえ、Geminiの現行ガイドは「既定値のままを強く推奨」に転じています。
Webチャット利用者が気にする必要はありません。

共通項だけで最小テンプレートを作る

以上から、Webチャットで使える要素だけを組むと次の形になります。各項目が8原則のどれに由来するかも添えました。

## 目的         ← 原則1・2（何のためかまで書く）
## 背景         ← 原則2（自分の立場・状況）
## 依頼         ← 原則1（してほしいことを1文で）
## 条件         ← 原則4（制約を肯定形の箇条書きで）
## 出力形式     ← 原則3（形式・分量・見出し）
## 入力文書     ← 原則5（「ここから/ここまで」で区切る）

例示（原則6）は毎回mustではないため任意枠、反復（原則7）はテンプレートではなく使い方の話です。
文体はすべて自然な文（原則8）で書きます。ラベルはMarkdown見出しでも番号でも構いません。読み手（モデル）が構造を取り違えない区切りがあれば十分です。

実プロンプトと生ログについて

実際に送った文面と、条件A・B・Cの代表出力を本文内に残します。
長い資料なので、普段は閉じておき、必要なときだけ開ける形にしました。

以下の文章を分かりやすくまとめてください。

技術に詳しくない部長が、入力文書の内容を1分で把握し、部署として何をすべきか判断できるようにしたいです。私は情報システム部の担当者で、社内で使っているファイル同期ツールのリリースノートを部長に報告します。入力文書から重要な事実をちょうど5件選んでください。各項目は80字以内にしてください。専門用語を使う場合は、その直後に丸括弧で15字以内の説明を付けてください。入力文書に書かれている情報だけを使ってください。出力には「## 重要ポイント」というMarkdownの見出しを付けて、1.から5.の番号付きリストで書いてください。出力は見出しと番号付きリストだけにしてください。入力文書は以下です。

## 目的
技術に詳しくない部長が、入力文書の内容を1分で把握し、部署として何をすべきか判断できるようにしたいです。

## 背景
私は情報システム部の担当者で、社内で使っているファイル同期ツールのリリースノートを部長に報告します。

## 依頼
入力文書から重要な事実をちょうど5件選んでください。

## 条件
- 各項目は80字以内にしてください。
- 専門用語を使う場合は、その直後に丸括弧で15字以内の説明を付けてください。
- 入力文書に書かれている情報だけを使ってください。

## 出力形式
出力には「## 重要ポイント」というMarkdownの見出しを付けて、1.から5.の番号付きリストで書いてください。出力は見出しと番号付きリストだけにしてください。

## 入力文書
「入力ここから」と「入力ここまで」の間だけを入力文書として扱ってください。

SyncMaple 3.0 リリースノート（社内向け・2026年7月10日）

SyncMaple開発チームより、バージョン3.0の提供開始をお知らせします。

■提供開始日
SyncMaple 3.0は2026年8月1日より、全社のライセンスに部署単位で順次配信されます。全部署への配信完了は8月15日を予定しています。

■同期エンジンの刷新と移行作業（重要）
3.0では同期エンジンを従来の「全量コピー方式」から「差分同期」（変更があった部分だけを転送する方式）に刷新しました。これにより大容量フォルダの同期時間が短縮されます。この変更に伴い、2.x系からの設定の自動引き継ぎは行われません。各部署のシステム管理者が移行ツール「maple-migrate」を実行し、同期フォルダを再設定する必要があります。

■新機能: オフライン編集
ネットワークに接続していない状態でもファイルを編集できるようになりました。再接続時に自動で同期され、他のメンバーの編集と衝突した場合は、両方の版を保存して利用者に選択を求める「競合解決」の画面が表示されます。

■セキュリティ修正
2.8以前のバージョンには、共有リンクの権限確認に関する脆弱性が確認されています。2.x系を当面継続利用する部署は、修正済みの2.9へ速やかに更新してください。なお、この脆弱性が実際に悪用された報告は現時点でありません。

■旧バージョンのサポート終了
2.x系のサポートは2026年12月31日で終了します。終了後は不具合修正・セキュリティ修正の提供はありません。

■その他の変更
・設定画面のデザインを刷新し、同期状態を一覧で確認できるようになりました。
・API（他のシステムからSyncMapleを操作する仕組み）連携は、3.0でも従来どおり利用できます。
・モバイル版の対応時期は追って告知します。

■問い合わせ
不明点は情報システム部ヘルプデスクまでお問い合わせください。

### SyncMaple 3.0の要点

SyncMaple 3.0は、**2026年8月1日から部署ごとに順次配信**され、**8月15日までに全部署へ配信完了予定**です。

主な変更点は、同期方式が「全量コピー」から、変更部分だけを転送する**差分同期**に変わることです。同期時間の短縮が期待できますが、**2.xの設定は自動では引き継がれません**。各部署のシステム管理者が移行ツール「maple-migrate」を実行し、同期フォルダを再設定する必要があります。

また、ネットワークに接続していない状態でもファイルを編集できる**オフライン編集機能**が追加されます。編集内容が競合した場合は両方の版が保存され、利用者が選択します。

## 重要ポイント

1. 3.0は8月1日から部署単位で配信され、全社完了は8月15日予定。
2. 各部署で「maple-migrate」を実行し、同期フォルダの再設定が必要。
3. 差分同期（変更部分だけ転送）により、大容量フォルダの同期時間が短縮。
4. 2.8以前には脆弱性（安全上の弱点）があり、継続利用部署は2.9へ更新。
5. 2.x系は12月31日でサポート終了し、以後は修正が提供されない。

## 重要ポイント

1. 3.0は8月1日から部署単位で順次配信され、全部署への完了は8月15日予定です。
2. 差分同期（変更部分だけ転送）へ刷新されますが、2.x設定は自動移行されず、各部署で再設定が必要です。
3. オフライン編集が可能になり、再接続時に自動同期します。編集衝突時は両版を保存して選択します。
4. 2.8以前に共有リンクの脆弱性（安全上の弱点）があります。継続利用部署は2.9へ速やかに更新が必要です。
5. 2.x系のサポートは2026年12月31日終了。以後、不具合修正とセキュリティ修正は提供されません。

同じ課題を27回試す——検証の設計

このテンプレートが「公式が言うとおり」機能するのか、同一条件で試しました。
27回は、3サービス×3条件×各3回です。
1回だけでは出力のばらつきなのか、条件による傾向なのかを切り分けにくいため、同じ条件を3回ずつ繰り返しました。
統計的な証明をするには足りない回数ですが、「たまたま1回うまくいった／失敗した」だけで結論を出さないための最低限として設定しました。

• 課題: 架空の社内ツールのリリースノート（約860字・筆者作）から「重要な事実をちょうど5件」抽出。各80字以内、専門用語には15字以内の説明、原文にない情報は使わない、指定のMarkdown形式で——という条件付き要約です。
• 3条件: A=「以下の文章を分かりやすくまとめてください。」だけ／B=必要な要件をすべて一続きの文章で書く／C=Bと同じ文をテンプレートで構造化しただけ（情報量・語句・順序は同一。差は構造化と入力の区切りのみ）です。
• 回数: 3サービス×3条件×各3回=27チャット。実施順はA→B→C、B→C→A、C→A→Bと巡回しました。
• 環境: 3サービスとも一時チャット機能（ChatGPT: Temporary Chat／Gemini: Temporary chat／Claude: Incognito chat）を使用しました。なおChatGPTのTemporary Chatはカスタム指示が有効なら適用されたままになると公式FAQにあるため、カスタム指示欄が空であることを別途確認しました。
• 評価: 判定基準と「重点事実5つ」「意図的に書かなかった情報」は出力を見る前に固定し、形式・件数・字数などはスクリプトで機械判定しました。「プロンプト改善の前に成功基準と測定方法を決めよ」という3社の評価ガイドの推奨に従った形です。

AとBの差が「情報を書く効果」、BとCの差が「同じ情報を構造で整理する効果」を示す設計です。
実施は2026年7月14日。モデルはChatGPT=GPT-5.6 Sol、Gemini=3.5 Flash、Claude=Fable 5です（使用量の都合でeffort「中」に固定。消費量鬼）。

結果：書けば守られる。書かなければ守られない

機械判定（形式・件数・字数・用語説明・前置きなし）の結果は、拍子抜けするほど明快でした。

条件を明示した18回では、3サービスとも1回の例外もなく守りました。
書かなければ守られないというのは当然に見えますが、「モデルが空気を読んでくれる」ことに期待しない根拠として、数字で持っておく価値があります。

内容面（事前に固定した重点事実5つをどれだけ拾ったか、原文にない情報を足していないか）は、機械判定より面白い結果になりました。

条件の違いが出た実例

Geminiでは、条件Bの2回目に「2.9へ更新」が必要な対象――「2.x系を当面継続利用する部署」という条件が落ちました。

同じGeminiで、条件Cの2回目では対象条件が残りました。
Bで2回起きた条件落ちは、Cでは3回とも起きませんでした。
試行3回では因果関係を断定できません。ただ、条件を独立した箇条書きにすると取りこぼしにくくなるかもしれない、という具体例にはなります。
実際に送ったプロンプトと代表出力は、前の折りたたみ内に載せています。

網羅性は自由要約（A）が最高でした。
分量制限がないため全部を書けますが、そのぶん3サービスとも長く、形式はバラバラで、1分で読める体裁にはなりません。
逆に「ちょうど5件」と縛ったB・Cでは、3サービスとも同じ挙動を見せました——「同期エンジンの刷新」と「移行作業が必要」を別項目に分けて枠を使い切り、新機能のオフライン編集を頻繁に落としました（18本中12本）。
件数の制約は取捨選択を強制し、何を落とすかはモデル任せになります。

原文にない情報の追加は、条件Aでだけ、3サービスとも1回ずつ起きました。
ChatGPTは「全部署は12月31日までに移行を完了すること」という原文にない行動指示を足し、Claudeも「年内に移行が必要」と期限をまとめ、Geminiは「順次自動配信」と提供方法を足しました。
いずれも悪意のない「親切な補完」で、それらしく読めます。
制約のない依頼ほどこの種の混入が起きやすいなら、要約を人に渡す用途では「書かれている情報だけを使って」の一文に実利があります。

構造化（B→C）の差は小さいものの、ゼロではありませんでした。
網羅性はChatGPTとGeminiでCがわずかに上、Claudeは同点です。
はっきり差が出たのは誤読でした。Geminiは文章のみのB条件で「2.9への更新が必要」の対象条件（旧バージョンを使い続ける部署だけ）を2回落とし、全部署必須のように書きました。
一方、同じ情報を構造化したC条件では3回とも条件を保持しました。
試行3回の観察であり断定はできませんが、「同じ情報でも、条件を箇条書きで独立させると取りこぼしにくい」という方向のシグナルにはなっています。

この検証から守るルール

今回の結果から、Webチャットで要約や文章作成を頼むときに守るルールを、次のように整理できます。特定のAIにだけ効く「呪文」ではなく、依頼を人に渡すときにも役立つチェックリストです。

1. 守ってほしい条件は、書かなくても伝わると期待しない。件数、字数、見出し、前置きの有無など、出力に必要な条件は明記します。今回の範囲では、書かなかった条件は3サービスとも守られませんでした。
2. 条件が複数あるなら、文章に詰め込まず見出しと箇条書きに分ける。BとCの比較だけで因果を断定はできませんが、同じ条件でもCではGeminiの条件落ちが起きませんでした。
3. 入力文書と依頼を区切る。今回のCでは入力ここからと入力ここまでを使いました。入力文書にないことを足してほしくないときは、「入力文書に書かれている情報だけを使う」も条件として書きます。
4. 件数を絞るなら、優先順位も渡す。「5件だけ」と指定すると、何を残して何を落とすかをモデルが決めます。今回も、重要なオフライン編集機能が18本中12本で落ちました。
5. 最初の出力を完成品と決めない。これは27回の比較そのものではなく、3社の公式ガイドに共通する勧めです。下書きを見て、足りない条件や優先順位を追加して出し直します。
6. 前提が曖昧なら、回答の前に質問させる。これは今回の27回では直接比較していませんが、目的・対象範囲・判断基準を明確にできない場合は、「不足している前提があれば、作業を始める前に質問してください」と頼むほうが安全です。AIに推測で埋めさせるより、手戻りや見当違いの回答を減らせます。

この6つを守っても、出力が常に正しいとは限りません。ただ、「何となく頼んで、何となく読みにくい結果が返る」回数は減らせます。

万能ではない——この検証の限界

限界も正直に書いておきます。
各条件3回では統計的な一般化はできません。課題は条件付き要約の1種類だけで、プロンプトも日本語だけです。
結果は2026年7月14日時点のWeb版のスナップショットであり、各サービスのモデルや内部設定は予告なく変わります。
一時チャットも完全な隔離ではありません（各社とも安全目的の例外を明記しています）。
「重要な事実5件」の選定には筆者の判断が入っており、唯一の正解ではありません。
そしてこの記事は、調査・集計・執筆の広い範囲でClaude（Anthropic製）の支援を受けて作っています。
判定を機械化し、基準を出力前に固定したのは、そのバイアスを減らすためでもあります。

それでも、docx-cliの検証のときと同じで、「公式がそう言っている」と「自分の環境でそうなった」を分けて確かめる価値はありました。
公式ガイドの共通原則は、少なくともこの課題では宣伝どおりに機能しました。

まとめ：持ち運べるのは「原則」で、「呪文」ではない

• どの生成AIにも必ず効く万能プロンプトはありません。OpenAI自身が「唯一の完璧な正解はない」と書いています。
• 一方、目的・背景・依頼・条件・出力形式・入力の区切りという基本設計は3社の公式資料に共通し、実測でも3サービスで同じように機能しました。モデルを乗り換えても持ち運べるのは、この層です。
• 条件は肯定形で明示します。書かなかった条件は守られず、書けば（今回の範囲では）毎回守られました。
• 件数や分量を縛ると、何かが落ちます。何を落とすかを任せたくなければ、優先順位まで書きます。
• 役割設定・ステップバイステップ・prefillなどはベンダーや世代に依存します。使うなら「そのモデルの今のガイド」を確認します。
• 公式ガイドはどれも反復を前提にしています。1回目の出力は下書きとして扱い、直して出し直します。

検証に使ったプロンプト全文・入力文書・判定基準・27回分の生ログは手元に保存しています。再現や反証は歓迎します。