プロンプトはプロセスである
このページが解決しようとしている課題
私たちは、組織の誰もが AI で役に立つ何かを作れる地点に立っています。気の利いたプロンプトがメモに保存される。同じプロンプトが、あなたが使っているプラットフォーム上のスキルになる。そのスキルがエージェントにラップされる。エージェントが同僚と共有される。同僚はこう尋ねます。「これをチーム全体に展開できる？ ファンクション全体は？ 全社は？」
そのリクエストはシンプルに聞こえます。実はそうではありません。そして、そうではない理由こそ、このページの存在意義そのものです。
このページは意図的にツール非依存です。毎回個人ドキュメントから貼り付けるプロンプトであれ、Glean で作ったスキルであれ、Claude で作ったスキルであれ、上記のいくつかを縫い合わせた完全に自律的なエージェントであれ、同じロジックが当てはまります。論点は 指示そのもの であって、それがどこに置かれているかではありません。
これらのいずれかを広範な展開のために承認するよう依頼された方、あるいは依頼している側の方は、会話をさらに進める前にこのページを読んでください。
まずはプロンプトとは実際に何かから始める
プロンプトは、AI に従わせる一連の指示です。AI は、そうでなければ人間が行ったはずの仕事を実行します。
では一歩引いてみましょう。一貫した成果を生み出すために、人間が繰り返し従う一連の指示のことを私たちは何と呼んでいるでしょうか？
プロセスです。
個人ドキュメントからコピペするプロンプトはプロセスです。どんなプラットフォーム上のスキルもプロセスです。スキルをラップするプラグインもプロセスです。複数を繋ぎ合わせるエージェントもプロセスです。私たちがこの領域で構築しているものはすべてプロセスであり、ハンドブックページや Confluence ドキュメントの代わりに、自然言語で表現されているだけなのです。
それが見えれば、あとはすべて自然に続きます。
プロセスはサイロ化したり場当たり的に作ったりできない
プロンプトがプロセスなのであれば、成熟した組織が他のあらゆるプロセスを扱うように扱うべきです。
- 共有されている、サイロ化していない。 同じロールに就いている人は皆、同じ指示で動作すべきです。私たちは CSM ごとに 1 つの顧客オンボーディングプレイブックを書きません。CSM ごとに 1 つのプロンプトを書くべきでもありません。
- バージョン管理されている、場当たり的でない。 プロセスは、各個人がこっそり自分のコピーを微修正することではなく、望ましい状態に向かってイテレーションを重ねて進化すべきです。変更が見え、議論し、合意し、展開する必要があります。
- オーナーがいる、孤児化していない。 誰かが、プロセスが正しく、最新で、私たちが期待する働き方に沿っていることに対して説明責任を負う必要があります。
ある個人のメモアプリの中に存在する素晴らしいプロンプトや、どこかの AI プラットフォームのプライベートワークスペースに存在する素晴らしいスキルは、会社にとっての勝利ではありません。それはシャドープロセスです。「本物の」セールスプレイブックを個人の Google ドキュメントに置いているのと同じ、プロンプト版です。
プロセスの集合体は戦略である
さらにズームアウトしてみましょう。ファンクションがその仕事をするために使うあらゆるプロセスを集めると、何が得られるでしょうか？
そのファンクションがどのように運営されているかが得られます。運用レベルで表現された戦略が得られます。
戦略はファンクションのリーダーが決定します。VP of Marketing が Marketing の戦略を決めます。CIO が IT と ETA 組織の運営方法を決めます。CEO が会社戦略を決めます。
もし私たちのプロセス（プロンプト、スキル、プラグイン）がファンクションの運営方法を定義するのであれば、それはそのリーダーの戦略を実行する道具となります。
ここから有用なテストが得られます。リーダーがプロセスを変えることで自分のファンクションの運営方法を変えられないのであれば、そのリーダーは自分の戦略をコントロールできていないということです。
プロンプトがサイロ化したときに起きること
セールスの動きを変えたい VP of Sales を想像してください。新しい資格化アプローチ、新しいディスカバリーのフレーミング、新しいディスカバリーの質問。
オーナー不在のプロンプト世界では、AE 全員が自分の「コール準備」プロンプトを持っています。古くなっているものもあります。古い資格化フレームワークを埋め込んでいるものもあります。素晴らしいものもあれば、ひどいものもあります。VP が「動きを変えろ」と言っても何も起きません。変えるべき単一のものが存在しないからです。
オーナーありのプロセス世界では、正典となる Sales のコール準備スキルがあります。VP は Sales の ATO と協力して、新しい振る舞いに合意します。ATO がスキルを更新し、ブランチを切り、レビューを受け、マージします。スキルを使っているすべての AE は、次に実行するときに自動的に新しい振る舞いを取り込みます。
その 2 つ目の世界が、私たちが向かおうとしている世界です。1 つ目の世界は、オーナー不在でエージェントをローンチしたときに、私たちがうっかり作り出し続けている世界です。
オーナーシップが置かれる 3 つの場所
プロセスのオーナーシップは、すべてのケースで同じ形をしている必要はありません。3 つの正当な置き場所があり、適切な場所はプロセス自体の形によって決まります。
- ファンクションスコープ。 プロセスは単一のファンクションの仕事（Marketing、Sales、CX など）に役立つ。オーナー: ファンクションのエグゼクティブ。AI Transformation Owner (ATO) が正典バージョンを維持する。
- リポジトリスコープ。 プロセスは特定のリポジトリの使用または修正に直接関連する。オーナー: リポジトリのメンテナー / CODEOWNERS。git が重い仕事のほとんどを担う。
- 全社規模。 プロセスは横断的であり、会社全体に利益をもたらす。オーナー: 適切な中央ファンクション（People、Ops、Comms、ETA など）。本来のオーナーがまだ明白でない場合は、ETA が暫定的な置き場所となる。
次の 3 つのセクションで、それぞれを詳しく見ていきます。
ファンクションスコープ: ATO の登場
AI Transformation Owner (ATO) は、ファンクションに組み込まれ、そのファンクションの AI で表現されたプロセスのオーナーシップを持つ人です。
ATO は次の 2 者の橋渡しをします。
- 戦略のオーナーであるエグゼクティブ、と
- AI を使って仕事をしている人々。
具体的には、ATO は次のことを行います。
- ファンクションで使われる正典のスキル、プロンプト、エージェントを維持する。
- エグゼクティブからの戦略変更を、スキル内のプロセス変更に翻訳する。
- 有用な何かを構築して、より広く採用してほしいと考えている個人からの提案をレビューする。
- ファンクションの AI 利用面が、リーダーが望むファンクションの運営方法に沿うようにする。
あなたのファンクションにまだ ATO がいない場合、それはギャップです。真空の中にエージェントを構築して、その後に全社規模の展開を依頼することは、そのギャップが埋まるまで何度もこの壁にぶつかり続けます。
リポジトリスコープのスキル
スキルの 2 つ目の有効な置き場所があります。特定のリポジトリ内、そのリポジトリのコンテンツの残りと一緒にバージョン管理される場所です。
これは Claude Code が採用しているパターンです。.claude/skills/ フォルダがコードベースに同梱されます。リポジトリをクローンした人全員がスキルを手に入れます。スキルはコードそのものと同じプルリクエストプロセスを通じて進化します。中央マーケットプレイスの関与はありませんが、スキルは依然として次の通りです。
- オーナーがいる: リポジトリのメンテナー / CODEOWNERS。
- バージョン管理されている: 文字通り git で。
- 共有されている、サイロ化していない: リポジトリへのすべてのコントリビューターが同じスキルを手にするため。
このパターンは明示的に推奨されます。スキルが本当にリポジトリ固有であるとき、リポジトリスコープ化はこのページのすべての原則を最もクリーンに表現する方法です。オーナーシップは文字通り CODEOWNERS、バージョン管理は文字通り git、レビュー可能性は文字通りマージリクエスト、展開は文字通り git pull です。このドキュメントの残りで使う比喩は、このケースでは実際のメカニズムそのものです。
GitLab の非コードリポジトリにも同じパターンが当てはまりますが、スキルが特定のリポジトリの使用または修正に直接関連する場合に限ります。ハンドブックリポジトリへのコントリビューターが GitLab のボイスとスタイルを適用するのに役立つスキルは、そこに属します。特定の Ops ランブックリポジトリで役立つスキルは、そこに属します。基準は そのリポジトリの目的との緊密な結合 であり、「たまたま git で管理している」ではありません。
鍵となるテスト
スキルがリポジトリに属するのは、それが その特定のリポジトリ の使用または修正に直接関連するときです。スキルがリポジトリの服を着ているけれども実際には別の場所に属していることを示すシグナルは次のとおりです。
- このリポジトリを一度も触らない人にも役立つだろう。
- 複数のリポジトリ間で一貫して適用されるべきプロセスをエンコードしている。
- それを使うチームが複数のコードベースやアセットにまたがって分散している。
いずれかが真であれば、そのスキルは汎用的または再利用可能であり、ファンクションスコープまたは全社規模の置き場所に属します。
全社規模のプロセス
ある種のプロセスは、特定のファンクションやリポジトリには属しません。たとえば、社内アップデートの書き方を標準化する、ミーティングを一貫してサマリーする、チームをまたいだ重複作業を防ぐ、社内の略語をデコードする、といったものです。これら単体で動く特定のエグゼクティブの戦略はありませんが、それらが存在し一貫していると、すべてのチームが恩恵を受けます。
原則は変わりません。オーナーシップは依然として必要です。変わるのは どこに オーナーシップを置くかです。全社規模のプロセスにとって正しい置き場所は、最も適切な中央ファンクションです。働き方の規範は People。社内コミュニケーション標準は Ops または Comms。AI パターンそのものは ETA。などなど。本当に不明な場合は、本来のオーナーが現れるまで ETA が暫定的な置き場所として動きます。
全社規模のプロセスについて重要な点がいくつかあります。
- 完璧なオーナーを待たない。 ここではコミットしてイテレートするのが正しいアプローチです。最初のバージョンを出し、広くフィードバックを集め、磨いていきます。遅いイテレーションのコストは、不完全な最初のカットのコストよりも高いです。
- 構築者がコントリビュートを止められることはない。 リワーク防止プロセスの素晴らしいバージョンを構築した CX の誰かは、ぜひ最初のコミットを行うべきです。彼らは今後の正典バージョンのオーナーではないだけで、また、いったん世に出たそれを唯一微修正できる人物であるべきではないというだけのことです。
- 広範なフィードバックは、単一のエグゼクティブのサインオフの代わりになる。 ファンクション固有のプロセスは、ファンクションのエグゼクティブによって検証されます。全社規模のプロセスは、広く共有され、入力を集め、中央オーナーのもとで素早くイテレートされることによって検証されます。
「明白なファンクションオーナーがいない」場合の答えは、「構築者にデフォルトで委ねる」ではありません。「正しい中央の置き場所を見つけ、構築者に最初のコミットをさせ、そこから素早く動く」です。
これは個人の創造性に対する制約ではない
ATO モデルは人々の実験を止めません。CSM、AE、マーケターが自分の仕事に役立つ個人的なプロンプトを作ることを止めません。それは、まさに私たちが望む草の根の実験です。
それが止めるのは、「これは自分にとって役立つ」から「これはファンクションや会社全体で動くべきだ」への飛躍を、オーナーシップとアラインメントに関する会話を経ずに行うことです。
素晴らしい何かを構築したのであれば、正しい次のステップは、ATO（まだいない場合は、その作業領域のオーナーであるエグゼクティブ）を見つけて提案することです。その会話の結果は次のいずれかです。
- あなたの作業を、そのファンクションの正典スキルの基礎として採用し、ATO が今後のオーナーシップを持つ。
- リーダーが望むファンクションの運営方法と矛盾するため、または進行中のより優先度の高い変更があるため、今は採用しない。
両方の結果が正当です。両方とも、オーナー不在のエージェントを展開し、6 ヶ月後にそれがリーダーが合意したことのない何かを 100 人にこっそり訓練していたと気づくよりも、ずっと良いです。
人間の判断は保たれる
プロセスのオーナーシップを持つことは、判断を取り除くことと同じではありません。スキルの出力は、最終回答ではなく、出発点です。
正典スキルから生成されたコール準備ブリーフは、コール前に AE が依然として微修正します。顧客サマリーは、共有される前に CSM が依然としてレビューします。下書きメールは、送信される前に依然として編集されます。
プロセスは私たちに一貫した基礎を提供します。人間がその上に文脈と判断を補います。
これが正しい分業です。AI は繰り返しの部分を一貫して行い、人間はテイストと判断を必要とする部分を上手に行います。これは、私たちの第一の指導原則 人間の貢献を増幅し、自動化で置き換えない の実践的な表現です。
では、あなたが構築したものを共有したい場合、これは何を意味するか？
これは、再利用可能なプロセスをカプセル化するあらゆるものに当てはまります。メモから貼り付けるプロンプト、任意の AI プラットフォームのスキル、プラグイン、完全に組み上がったエージェント。それを自分自身や小さなパイロットグループを超えて動かしたいと思った瞬間に、以下の質問を順に進めてください。
- これは誰のプロセスをエンコードしているか？ 答えが「自分のもの」であれば、より広い展開の準備はできていません。まず誰かの正典プロセスになる必要があります。
- 正しいスコープは何か？ 3 つの選択肢があります。
- リポジトリスコープ: 特定のリポジトリの使用または修正に直接関連する場合。オーナー: リポジトリのメンテナー / CODEOWNERS。
- ファンクションスコープ: 単一のファンクションの仕事に役立つ場合。オーナー: ファンクションのエグゼクティブ。ATO が正典バージョンを維持。
- 全社規模: 会社全体に横断的に適用される場合。オーナー: 正しい中央の置き場所（People、Ops、Comms、ETA など）。ETA がこれを整理する手助けができます。
- オーナーは特定され、準備ができているか？ リポジトリメンテナー、ファンクションエグゼクティブ + ATO、または中央オーナー。もしそうなら、それが最初の会話です。そうでなければ、それが誰であるべきかについて、説明責任を負う人との会話になります。
- プロセスはバージョン管理され、レビュー可能か？ リポジトリスコープの場合は自動的です（git です）。ファンクションスコープと全社規模の場合は、個人のメモアプリやプライベートワークスペースではなく、レビュー、ブランチ、マージ、展開が可能な場所に置く必要があります。
- オーナーは、本当にこれを自分のドメインの運営方法にしたいと思っているか？ これに答えられないのであれば、まだより広く共有する準備はできていません。
5 つすべてに答えられれば、本物の提案があります。答えられなければ、プロトタイプがあるということで、次のステップは展開ではなく会話です。
採用を提案する方法
短いバージョンです。あなたが構築したものがプロンプト、スキル、プラグイン、フルエージェントのいずれであっても同じです。
- スコープを特定する: リポジトリ、ファンクション、または全社規模。
- オーナーを特定する: リポジトリメンテナー / CODEOWNERS、ファンクションエグゼクティブ + ATO、または中央の置き場所。
- プロトタイプ、ユースケース、提案する採用パスを彼らに持ち込む。
- オーナーに今後の正典バージョンの責任を取ってもらう。
正しいオーナーが誰か分からない場合は、ETA チームが見つける手助けをします。
FAQ
「でも、今日これをやっているエージェントはいません。何もないよりは何かある方がマシでは？」
そうかもしれません。しかし「何か」は依然として、リーダーが望むファンクションの運営方法に沿っている必要があります。さもなければ、私たちは偶発的な戦略をエンコードすることになります。修正は通常素早いです。適切なエグゼクティブとの短い会話、ATO のオーナーシップ取得、そこから素早く動けます。修正が「とにかくオンにしろ」であることは稀です。
「これは速く動く領域の上に乗せる官僚主義のように感じます。」
その逆です。オーナーシップがなければ、私たちの働き方へのすべての変更は、100 個の調整されない個別のプロンプト編集を通じて起きます。オーナーシップがあれば、ソースでの単一の変更がすべてのユーザーを即座に更新します。オーナーありのモデルは、いったん存在すれば、より遅いのではなく、より速いです。
「これは自分の時間で構築しました。なぜ今、誰か他の人がオーナーになるのですか？」
個人バージョンは依然としてあなたのものです。変わるのは、ファンクション全体の正典バージョンで、これはファンクションがオーナーシップを持たなければなりません。実際には、元の構築者がコントリビュートを続けるのに非常に多くの場合適切な人物であり、ATO のオーナーシップは作者性ではなく、説明責任とレビューに関するものです。
「ATO はどこに所属しますか？」
ファンクションの中に組み込まれます。ETA チームではありません。ATO は Marketing、Sales、CX、あるいは仕事が行われている場所の一部です。ETA はツール、パターン、プラットフォームでそれらをサポートします。
「これは中央マーケットプレイスのスキルにのみ適用されますか？ リポジトリに住んでいるスキルはどうですか？」
リポジトリスコープのスキルは、スキルが本当にそのリポジトリの使用または修正に結びついている場合、明示的に推奨されます。リポジトリメンテナーがオーナーであり、git がバージョン管理メカニズムであり、マージリクエストがレビューメカニズムです。このページの原則は、単一の正典のマーケットプレイスについてではなく、オーナーシップについてです。スキルが実際にリポジトリに属しているのか、属しているように見えるだけなのかを判断するテストについては、上記の「リポジトリスコープのスキル」セクションを参照してください。
1 段落でのまとめ
プロンプトはプロセスです。プロセスの集合体は戦略です。戦略にはオーナーが必要です。したがって、個人を超えて動作するすべてのプロンプト、スキル、プラグイン、エージェントにはオーナーが必要です。そのオーナーシップは 3 つの場所に置けます。プロセスがそのファンクションの仕事に役立つときはファンクションのエグゼクティブと ATO。プロセスがその特定のリポジトリに緊密にスコープされているときはリポジトリのメンテナー / CODEOWNERS。プロセスが会社全体で横断的なときは正しい中央の置き場所（本来のオーナーがまだ明白でない場合は ETA が暫定的な置き場所として、コミットしてイテレートするのが正しいペース）。適切な場所にそのオーナーシップが存在するまで、あなたが構築したものはより広い展開の準備ができていません。これはボトルネックではなく、戦略自体が変わったときにシステムを変更可能にしているものなのです。
bfd74782)