プロンプトは「魔法の呪文」ではない
生成AIが登場した頃、プロンプトには神秘的な雰囲気がありました。「うまく書けばすごいものが出てくる」「書き方のコツがある」といった文脈で語られ、プロンプトエンジニアリングという言葉まで生まれました。
この時期のイメージを引きずっているチームがまだ多い、と私は感じています。でもAIの性能が上がった今、プロンプトに求められるのは「明快で、誤解のない、指示そのもの」です。神秘性は消えて、代わりに「ビジネス文書としての品質」が問われるようになりました。
任せるのではなく、指揮するという発想
多くの現場で見かけるのは、AIに「任せる」感覚での使い方です。「いい感じにやっておいて」と投げて、出てきたものを受け取る。
私が提案したいのは、「指揮する」という発想への切り替えです。指揮者はオーケストラで、演奏自体は奏者に委ねます。でも全体のテンポ、強弱、入りのタイミング、全体の設計は指揮者の仕事です。
AIと人間の関係も、これに近づいていくべきだと考えています。演奏はAIに委ね、設計は人間が握る。これが、プロンプトを組織で運用するときの基本姿勢です。
指揮するプロンプトに含まれる4つの要素
要素1：コンテキスト（前提情報）——AIは背景を知らなければ文脈に沿った判断ができません。「既存システムは10年もので、SOAPを使っている」といった前提を先に渡します。
要素2：制約条件——「これは使える、これは使えない」を明示。技術スタック、禁止事項、品質要件など。制約がないとAIは無限の可能性から適当に選びます。
要素3：期待するアウトプット形式——コードのみか解説付きか、配置場所、コメントの言語など。「察してくれるはず」はAIには通じません。
要素4：評価基準——「どういう結果なら合格か」を最初に明示。テストが通る、スタイルガイドに従う、セキュリティベストプラクティスが守られる、など。事後のレビューで修正するより、ずっと効率的です。
これら4要素は、人間のプロジェクトマネジメントで言えばスコープ、制約、成果物、完成基準にあたります。
「考えさせる」のか「作らせる」のか、の使い分け
プロンプト設計でもうひとつ重要な観点があります。AIに何を期待するか、という軸です。
考えさせる使い方：「この設計でいいか、問題点を洗い出して」「このバグの原因を仮説として挙げて」——AIの発散的な思考を借りる使い方。
作らせる使い方：「この仕様に従ってこの関数を実装して」——決められた成果物を出させる使い方。
この2つは、求めるプロンプトの書き方が違います。考えさせるときはやや抽象的な問いのほうが視野が広がります。作らせるときは制約と評価基準をガチガチに固めたほうが精度が上がります。
要件定義とテストが、プロンプトの精度を上げる
ここで、第4話と第5話の内容が戻ってきます。要件定義書と、Given-When-Then形式の受け入れ条件が整っていれば、プロンプトの4要素のうち3つまでが既に揃っているのです。
- コンテキスト → 要件定義書の「前提・背景」
- 制約条件 → 要件定義書の「非機能要件」「やらないこと」
- 評価基準 → 受け入れ条件（テストとして実行可能）
残るはアウトプット形式の指定だけ。つまり仕様駆動開発とテスト駆動を回している組織なら、プロンプトはほぼ自動的に精度が上がるのです。4つの象限は独立ではなく連動している——プロンプトの話をしていても、結局は要件定義とテストの話に戻ってきます。
属人プロンプトからチームプロンプトへ
多くの現場で起きているのが、プロンプトの「属人化」です。特定個人のプロンプトは精度が高いが、その人がいないと品質が落ちる。しかも書かれたプロンプトはチャット履歴の中に埋もれて再利用もレビューもされない。
これは組織としては危うい状態です。個人の暗黙知に依存した品質は再現性を持ちません。プロンプトをチームで共有し、レビューし、バージョン管理する。ドキュメントやコードと同じ扱いにする——具体的な仕組みは次回、第8話で踏み込みます。
もし、AIがジャズセッションのように動いたらどうなるか
指揮者のいるオーケストラは楽譜に沿って演奏します。一方、ジャズセッションには指揮者も楽譜もありません。奏者たちはお互いの音を聴きながら即興で演奏を作ります。
「AIにはジャズセッションのように動いてほしい」と感じる場面、ありますよね。これが次回第8話で扱うAIオーケストレーションの典型イメージです。
ただ、立ち止まって考えてみてください。ジャズセッションはなぜあの自由度で成立するのか。奏者が全員プロで、互いのスタイルを理解し、暗黙のルール（コード進行、リズム、スタンダード）を共有しているからです。初心者が集まれば、自由ではなく不協和音になります。
AIのオーケストレーションも同じ構造。自由な運用にはそれにふさわしい前提が要ります。要件定義、受け入れ条件、制約——これらが明示されて初めて、AIの自律が価値を生むのです。
まとめ — 指揮者のいるオーケストラは、美しい音を出す
指揮者のいないオーケストラを想像してみてください。各奏者は優秀です。でも全体のテンポがバラバラ、入りのタイミングが合わない。技術的には間違っていないのに、音楽としてはどこか崩れている。
AIに「任せる」だけの組織は、これに似ています。個々の成果物は悪くない。でも全体としての設計思想が見えない。長く続けるほど音がズレていく。
そこに指揮者が立つ。同じ奏者、同じ楽譜なのに、全体がひとつの音楽に変わる。これがプロンプトを「指揮する」ということです。指揮者の仕事は、演奏することではありません。全体の設計を持ち、一人ひとりに伝える。AIの時代に私たち人間に残された役割は、この指揮者の立ち位置にあるのではないかと感じています。
著者プロフィール
町島 和徳（ギャラクティックブレーン合同会社 代表社員）
電気通信大学在学中からコンテンツ制作の現場でキャリアをスタート。エンタメ業界での経営実務を経て、現在はコンサルタント兼フルスタックエンジニアとして活躍。経営・マーケティング・技術の複眼的視点と、部門や階層を超えたファシリテーション力を強みに、スタートアップから大手企業まで幅広いDX支援を手がける。生成AI・RPAの実務活用を精力的に展開。成功・失敗双方の実践知を惜しまず発信する現場主義のプロフェッショナル。
