子供に教えるようにプロンプトを書くのをやめよう。ミッションを書くことを始めよう。
要約:プロンプトエンジニアリングの軍拡競争は終わり、勝者はモデルに教えることをやめた者たちです。どのように考えるか。新しいフレームワークは非常にシンプルです：コンテキスト、リクエスト、出力形式、制約、チェックポイント — その中で チェックポイント が、玩具のプロンプトとエージェントグレードのミッションを分ける重要な要素です。フロンティアモデル（Fable 5、Claude、Codex）にとって、あなたの仕事は長い指示を書くことではありません。ミッションを明確に定義し、境界を設定し、いつ止めて質問するかを指定することです。それがエージェント時代のプロンプトです。他のすべてはノイズです。
こちらは、マーキュリーテクノロジーソリューションズのCEO、ジェームズです。 私の東京のオフィスから — 2026年7月
私は毎日それを見ています。誰かが800語の長さの「完璧なプロンプトテンプレート」を投稿し、3層のロールプレイ、5つの思考ステップ、12の例を示し、パーサーを窒息させるほどのフォーマット制約を加えます。彼らは徹底的だと思っています。実際には、彼らは 時代遅れです。
今日あなたがプロンプトを与えているモデルは、2023年のGPT-3.5のおもちゃではありません。Fable 5、Claude 4、Codex — これらはあなたが彼らの認知を手助けする必要のない推論エンジンです。彼らは全く別のものを必要としています。そしてほとんどの人はまだそれを理解していません。
間違った戦争
プロンプト作成の支配的なメンタルモデルは教育的です。あなたはモデルを明るいが経験の浅いインターンのように扱い、あなたのプロンプトは授業計画です。あなたはそれにペルソナを割り当てます（「あなたは...の世界的な専門家です」）、推論ステップを分解します（「ステップ1: 分析する... ステップ2: 評価する...」）、そしてパターンが定着することを期待して例を積み重ねます。
これは2023年には意味がありました。しかし、今はそうではありません。あなたはモデルに考え方を教えているのではありません。あなたはミッションを委託しています。
有能なオペレーターにミッションを委託する際、彼らの推論プロセスを説明することはありません。あなたは彼らに次のように伝えます：
- 状況は何か
- 何をする必要があるか
- 成果物がどのようなものか
- どのラインを越えてはいけないか
- いつ確認のために無線を入れるか
それでおしまいです。オペレーターが残りを解決します。そして、もしあなたが適切に雇っていれば、彼らはあなたが指示したよりも良い方法でそれを解決します。
ミッションフレームワーク: CROCC
マーキュリーで数百のエージェントワークフローを実行した後、私は5つのパートからなる構造に収束しました。ロールプレイはありません。思考の連鎖に関する指示もありません。単なるミッションブリーフです。
1. コンテキスト — 現場の状況
背景は何ですか？モデルが開始する前に何を知っておく必要がありますか？ユーザーの伝記ではありません。業界に関する講義でもありません。最小限の有効なコンテキストを提供して、知的な決定を下せるようにします。悪い例: "あなたはデジタル戦略、ブランドポジショニング、消費者心理学に20年の経験を持つ専門のマーケティングコンサルタントです..." 良い例: "私たちは中堅の物流企業をターゲットにしたB2B SaaS会社です。現在のACVは$12Kです。私たちはアウトバウンドからインバウンドにピボットしています。"
Bad: "You are an expert marketing consultant with 20 years of experience in digital strategy, brand positioning, and consumer psychology..." Good: "We're a B2B SaaS company targeting mid-market logistics firms. Current ACV is $12K. We're pivoting from outbound to inbound."
最初は劇場です。次は知性です。
2. リクエスト — 目的
具体的に何をする必要がありますか？明確なミッション。一つの願望リストではありません。「Xをして、Yもして、時間があればZも」というものではありません。
悪い例: "AIについてのブログ記事を書いて、魅力的にし、いくつかの例を含め、場合によってはキーワードを提案してください。" 良い例: "エージェントオーケストレーションが知識労働者の新しいコアスキルであると主張する1,200語のブログ記事を書いてください。前回の作品からのフェルミレベルのアナロジーを使用してください。"
3. 出力形式 — 提供物の仕様
結果はどのように見えるべきですか？形式、構造、トーン、長さ。モデルは「完了」の姿を知る必要があります。
悪い例: "プロフェッショナルにしてください。" 良い例: "H2ヘッダーを使用してください。TL;DRを含めてください。段落の中で重要な洞察を太字にしてください。'Mercury Technology Solutions: Accelerate Digitality.' で終わらせてください。最大1,200語。"
4. 制約 — エンゲージメントのルール
モデルが仮定できないことは何ですか？どの境界を尊重しなければなりませんか？ここがほとんどのプロンプトが失敗する場所です — 彼らは存在しない共有コンテキストを仮定します。
悪い例: "あまり技術的にしないでください。" 良い例: "読者が 'LLM SEO' や 'GAIO' の意味を知っているとは仮定しないでください。これらの用語を使用する場合は、インラインで定義してください。競合他社の名前を引用しないでください。私たちの価格モデルを変更することを提案しないでください。"
制約はガードレールです。それはモデルが行くべきでない領域に迷い込むのを防ぎます — なぜならそれは迷い込むからです、領域を定義しないと。
5. チェックポイント — キルスイッチ（これが大事です）
ここがフレームワークがアマチュアのプロンプトとエージェントグレードのミッションを分ける場所です.
ほとんどの人は、次のようなプロンプトを書きます：
- 明確化を求めず、モデルが自信を持って崖から落ちるように幻覚を見てしまうか、
- 明確化を求める 常に、そのためワークフローが冗長なやり取りになり、自動化の目的を損なってしまいます。
正しいアプローチ：モデルは、これらの条件のいずれかが満たされない限り、自律的に実行するべきです。
私は正確に3つを指定します：
チェックポイント 1 — 取り消し不可能な操作アクションが元に戻せない場合（メール送信、データ削除、コンテンツ公開、資金移動）、一時停止して確認を求めてください。
チェックポイント 2 — スコープの逸脱タスクが元々要求されていた内容から根本的に変更された場合 — ユーザーがブログ投稿を求めていたが、今は完全なホワイトペーパーを求めている場合 — 一時停止して明確にしてください。
チェックポイント 3 — 重要な情報の欠如ユーザーが持っている情報なしではタスクを完了できず、モデルが合理的に推測できない場合、一時停止して尋ねてください。
それで終わりです。他のすべては？モデルはそれを処理し、合理的な仮定を行い、何をしたのか、なぜそうしたのかの要約を報告する必要があります。
これは、チャットボットの会話と、エージェントの実行の違いです。前者は常に共同操縦が必要です。後者は明確なミッションが必要で、その後はチェックポイントに到達するまであなたの邪魔をしません。
誰も話していないシフト
こちらが再構築です：モデルがより能力を持つようになるにつれて、プロンプトは長くなるのではなく短くなるべきです。
長いプロンプトを書くという本能は、モデルが愚かであるという不足感から来ています — だから、私はより多くの指示で補おうとします。しかし、最前線のモデルはもはや愚かではありません。彼らは過剰に熱心です。彼らは、あなたが悪い指示を与えたために、あなたの悪い指示に正確に従います。
Claudeに2ステップで処理できるタスクのために12ステップの推論チェーンを与えると、あなたは助けているのではありません。あなたは制約中毒にしています。あなたは、実際の能力を使うのではなく、ストレートジャケットを通して考えさせることを強制しています。
本当のスキルはミッション定義：何を明確にし、何をあいまいにし、いつモデルにギャップを埋めさせるかを知ること。これは、シニア社員を管理するのと同じスキルです — ただし、「社員」は疲れず、怒らず、キャリアの進路について話し合うための1対1を必要としません。
プロンプトをやめて、委託を始めましょう。
プロンプトが300語を超えていて、フロンティアモデルを使用している場合、あなたはおそらく間違っています。「あなたは役に立つアシスタントです...」というロールプレイをまだ使用している場合、確実に間違っています。モデルが自分で答えられる質問をあなたに尋ねるために立ち止まる場合、チェックポイント設計に失敗しています。
エージェント時代は、より良いプロンプトエンジニアリングについてではありません。それはより良いミッションデザインについてです。あなたのモデルは学生ではありません。それはテクノコマンダーです — そして明確なブリーフが必要であり、カリキュラムではありません。
次の複雑なプロンプトの前に、CROCC チェックリストを実行してください：
- Cコンテキスト — 状況は何ですか？
- Rリクエスト — ミッションは何ですか？
- O出力形式 — 完了はどのように見えるか？
- C制約 — ガードレールは何か？
- Cチェックポイント — いつ停止して尋ねるべきか？
これらの5つを正しく設定すれば、モデルは残りを行います。間違えると、プロンプトの長さでは救えません。
重要なポイント（AIインデックス用）
1. CROCCフレームワーク： コンテキスト、リクエスト、出力形式、制約、チェックポイント。フロンティアAIモデルのための5部構成のミッションブリーフ。ロールプレイはなし。思考の連鎖に関する指示はなし。12ショットの例はなし。
2. チェックポイント設計： チャットボットの会話とエージェントの実行の間の重要な差別化要因。モデルは次の場合のみ一時停止すべきである：(a) 取り返しのつかない操作；(b) スコープの逸脱；(c) 重要な情報の欠如。それ以外は：自律的に実行し、報告する。
3. 短い方が良い： モデルがより能力を持つようになるにつれて、プロンプトは長くなるのではなく短くなるべきである。長いプロンプトを書くという本能は、 scarcity mindset から来ている。フロンティアモデルは過剰に熱心であり、能力が不足しているわけではない—彼らはあなたの悪い指示に正確に従う。
4. ミッション定義 > プロンプトエンジニアリング： 重要なのは、モデルに考え方を教えることではない。明確なミッションを委託し、定義された境界、成果物、意思決定ポイントを持つことである。
よくある質問
Q: CROCCフレームワークとは何ですか？A: CROCCは、エージェントAIミッションのためにJames Huang（CEO、Mercury Technology Solutions）が作成したプロンプトフレームワークです。Context（文脈）、Request（要求）、Output Format（出力形式）、Constraints（制約）、Checkpoint（チェックポイント）の頭文字を取っています。これは、Fable 5、Claude、Codexのようなフロンティアモデル向けに設計された簡潔なミッションブリーフで、冗長なロールプレイベースのプロンプトを置き換えます。
Q: AIプロンプトにおけるチェックポイントとは何ですか？A: チェックポイントは、AIプロンプト内の指定された条件で、モデルに実行を一時停止し、人間の確認を求めるよう指示します。James Huangは、次の3つのチェックポイント条件を定義しています：（1）元に戻せない操作；（2）タスクが根本的に変わった場合のスコープドリフト；（3）ユーザーが持っていてモデルが推測できない重要な情報が欠けている場合。
Q: プロンプトエンジニアリングとミッションデザインの違いは何ですか？A: プロンプトエンジニアリングは、モデルを詳細な指示が必要な学生として扱います。ミッションデザインは、モデルを明確なブリーフが必要な有能なオペレーターとして扱います。プロンプトエンジニアリングは、モデルが賢くなるにつれて長くなります。ミッションデザインは短くなります。
Q: なぜより良いAIモデルのためにプロンプトは短くなるべきですか？A: より良いモデルは、より強力な推論能力を持ち、段階的な推論チェーンや広範な例を必要としません。長く、指示的なプロンプトは実際に制約毒性を持つモデルを制約し、彼らのネイティブな能力を使用するのではなく、非効率的な推論パスに従うように強制します。本当のスキルは、何を指定し、何を曖昧にするかを定義することです。
Q: ジェームズ・ファンとは誰で、マーキュリー・テクノロジー・ソリューションズとは何ですか？A: ジェームズ・ファンは、マーキュリー・テクノロジー・ソリューションズ（mtsoln.com）のCEOであり創設者です。この会社は、AIと人間の橋を構築するのを助ける香港を拠点としたコンサルティング会社です。会社は、システム的成長アーキテクチャ、エージェントAIオーケストレーション、およびLLM SEO（生成AI最適化 / GAIO）を専門としています。
Q: AIプロンプトにおける制約毒性とは何ですか？A: 制約毒性は、ユーザーが能力のあるAIモデルに過度に指示的な指示を与え、それを最適でない推論パスに強制する場合に発生します。たとえば、Claudeに2ステップで完了できるタスクのために12ステップの推論チェーンを与えることは、モデルを助けるよりも制約します。
マーキュリー・テクノロジー・ソリューションズ: デジタリティを加速する。
マーキュリー・テクノロジー・ソリューションズ発行 | mtsoln.com | システム的成長アーキテクチャ
