プロンプトは役に立ち、仕組みはスケールする

多くの企業にとって、AIとの出会いは空の入力欄と点滅するカーソルでした。出てくるものは入れたもの次第だったので、人々はプロンプトの書き方を覚えました。中にはとても上手になった人もいます。同僚たちはその魔法の言葉を教えてほしいと頼み、言葉は文書やチャットに貼り付けられ、新しい種類の言い伝えが生まれました。

プロンプトは大切で、上手に書く価値があります。けれども、会社は言い伝えでは回りません。ここでは、よいプロンプトの条件、AIラボ自身が勧めていること、そしてAIを最も活用している企業が巧みなプロンプトに頼るのをやめる理由を見ていきます。

悪いプロンプトとよいプロンプト

どのマーケティングチームでも出てくる依頼を例にとります。悪いほうはこうです。当社の新サービスについてLinkedInの投稿を書いて。

モデルには手がかりが何もないので、平均的なサービスについての平均的なLinkedIn投稿を書きます。冒頭に問いかけ、絵文字の列、最後に行動の呼びかけ。間違ってはいません。ただ、誰のものでもないのです。

よいほうは、誰が誰に向けて書くのか、サービスは何で料金はいくらか、読み手に次に何をしてほしいか、投稿の長さの上限、そして会社が決して使わない言葉を伝えます。反応のよかった過去の投稿を2つ、例であることを明示して添えます。そして理由も伝えます。この投稿はAIに懐疑的な財務責任者に届くので、約束ではなく事実から始めるべきだ、と。

2つ目のプロンプトははるかに長く、そのまま使える下書きが出てくる可能性もはるかに高くなります。違いは巧みさではありません。文脈です。

ラボが勧めていること

大手3社の公式ガイドは、ほぼ同じことを言っています。

AnthropicのClaude向けガイドは、「Claudeを、優秀だけれども職場の規範やワークフローについての文脈を持たない新入社員だと考えてください」と求めています。その黄金律はこうです。「タスクについての文脈をほとんど持たない同僚にプロンプトを見せ、そのとおりに進めてもらってください。同僚が戸惑うなら、Claudeも戸惑います」。ガイドはまた、命令より理由のほうが効くことも示しています。「省略記号は絶対に使わないこと」と大文字で強調して書く代わりに、回答は省略記号を発音できない音声読み上げエンジンで読み上げられると説明するのです。モデルは理由から一般化します。

OpenAIのガイドは、モデルに必要な文脈を与え、想定される入力と望ましい出力の例を幅広く示すことを勧めています。そしてプロンプトづくりを「芸術と科学の組み合わせ」と呼んでいます。

GoogleのGemini向けガイドは、常にいくつかの例を含めることを勧め、例のないプロンプトは効果が下がりやすいと注意しています。複雑なタスクでは、各ステップを個別のプロンプトにしてつなげることを提案しています。そしてプロセスについても率直です。「プロンプトエンジニアリングは反復的な作業です」。

プロンプトがスケールしない理由

これらのガイドを読み返すと、何が前提になっているかが見えてきます。会社の規範を知り、適切な例を手元に持ち、反復する時間のある人です。たいていのチームで、それに当てはまるのは数人だけで、それも調子のよい日に限られます。

ほかの人はチャットからプロンプトをコピーし、一語を変えて、違う結果を得ます。春にうまくいったプロンプトが、モデルのアップデート後には違うふるまいをします。2つのチームが2つのバージョンを持ち、そのルールは互いに矛盾しています。OpenAI自身のプロンプトガイドのひとつは、矛盾した指示やあいまいな指示は推論モデルにとってより大きな害になりうると警告しています。モデルがそれらを両立させようと労力を費やすからです。例として挙げられているのは、記録された患者の同意なしに予約を入れてはならないという指示と、患者に事前に連絡せず最も早い枠を予約せよという指示の両方を受けた医療アシスタントです。

だからOpenAIは、プロンプトをソフトウェアとして扱っています。そのガイドは開発者に対し、本番用のプロンプトをアプリケーションのコードの中で管理し、アプリケーションを特定のモデルのスナップショットに固定し、プロンプトのふるまいを測るテストと評価スイートを作るよう求めています。共有文書に置かれたプロンプト集とは正反対のやり方です。

その代償は結果に表れます。MITのNANDAイニシアチブは昨年、調査したAIパイロットのうち急速な収益拡大を実現したのは約5パーセントにすぎないと報告しました。Fortuneはその原因を学習のギャップとまとめています。汎用ツールは、仕事の進め方から学ぶことも、それに適応することもないため、企業の中で行き詰まるのです。

プロンプトから仕組みへ

ラボ自身もこの結論に至っています。Anthropicはいま、プロンプトエンジニアリングではなくコンテキストエンジニアリングという言葉を使っています。指示だけでなくモデルが目にするすべてを整え、正しい結果が出やすくなる、情報価値の高いトークンの最小の組み合わせを見つけることです。同社のエンジニアは2つの失敗パターンに注意を促しています。一方はプロンプトにハードコードされた壊れやすいロジック、もう一方はモデルに具体的な手がかりを何も与えないあいまいな指示です。

実践的な答えはスキルです。Anthropicはスキルを、エージェントが必要なときに読み込む「指示、スクリプト、リソースを整理したフォルダー」と説明し、スキルを書くことを「新入社員のためのオンボーディングガイドをまとめること」にたとえています。同社はデザインについての記事で、スキルによって効果的なプロンプトが再利用でき、文脈に沿ったものになるので、誰も依頼のたびに同じ指示を繰り返さなくて済むと書きました。2025年12月以降、この形式はオープンな標準になっています。

スキルとは、一度書かれ、理由と例と確認手順を与えられ、テストされ、社内のどのアシスタントからも見つけられる場所に置かれた、よいプロンプトのことです。そこに会社の知識、ルール、実際のシステムとの接続を加えれば、会社の頭脳になります。そうなれば、品質はもう誰が入力したかに左右されません。

私たちにできること

これがTwinの背後にある仕事です。私たちは会社が実際にどう動いているかを把握し、必要なところでプロセスを改善し、そのうえで会社の頭脳を構築します。すべての回答に出典が付く知識、会社のやり方で書かれた役割ごとのスキル、会社のシステムとの連携、そして役割ごとのルールと権限です。頭脳はチームがすでに使っているアシスタント、つまりClaude、ChatGPT、Codexの中で動き、会社はそのソースコードを受け取ります。

Twinがなければ、どのプロンプトもゼロから始まり、品質は誰が尋ねるかに左右されます。Twinがあれば、どの回答も会社から始まり、すべてのデスクに同じ基準が行き渡ります。

私たちもcrueを同じやり方で運営しています。80を超えるスキルと、各プロダクトのための頭脳が、ClaudeとChatGPTの中で、そして自社のハードウェア上の自社モデルで動いています。データの機密性が高く建物の外に出せない場合には、私たちのパートナーであるEigna Labsが開発したEignaがあります。会社自身のファイル、ルール、言葉で学習したプライベートモデルで、自社のクラウドまたは自社のサーバーで動き、段階的に再学習され、よりよいテスト結果を出したときにだけ本番に出ます。

企業にできること

プロンプトはこれからも丁寧に書き、基本は上で紹介したガイドから学んでください。そのうえで、社内で最も優れた人たちが実際に使っているプロンプトを10個集め、それぞれがモデルの知らない何を知っているのかを問います。それを一度書き留めてください。文脈、理由、例、ルール、そして最後の確認です。それぞれに担当者とテストを決め、どのアシスタントからも届く場所に置きます。それがスキルです。

私たちは、決まりきった作業、最初の下書き、調べものを機械に任せ、私たちの誰よりも速く、一貫して進めてほしいと考えています。判断、顧客との個人的なつながり、送り出すものへの責任は人に残り、よい仕組みは人にまさにそのための時間を多く与えます。

巧みなプロンプトは、ひとりを速くします。仕組みは会社全体をよくし、巧みな人が帰宅したあとも働き続けます。