AIはあなたのプロダクトを想像で補っている

なぜ出力がこれほど変わるのか

同じプロンプトを同じモデルに、60秒間隔で送ってみる。

プロンプト：「チケットの受け入れ基準を書いてほしい：ユーザーはAIプロバイダーの設定を構成できる。」

最初の試み——コンテキストなし：出力は汎用的なリストだ。「ユーザーはドロップダウンからAIプロバイダーを選択できる。ユーザーは設定を保存できる。ユーザーは確認メッセージを見る。」どのプロダクト、どのプラットフォーム、どの時代にもあてはまる。間違ってはいない。役に立つかというと、そうでもない。

2回目の試み——プロダクトコンテキストあり：出力はJira Cloud管理ページ、Forge resolverのパーミッション、プロバイダーごとのAPIキー検証（OpenAI、Anthropic、Google、Mistral、xAI）、組織レベルとプロジェクトレベルのデータスコープの挙動、ライセンスに紐づいた書き込みアクションに言及する。設定は@forge/sqlで永続化され、UIはxcssトークンを使ったAtlaskitコンポーネントで実装されると明記する。このコードベースで実際に作業したことがある人が書いたように読める。

モデルは変わっていない。温度も変わっていない。変わったのは入力だ。この差——汎用と具体の間——がこの記事のすべてのテーマだ。

AIの出力が安定しないと感じると、モデルを責めたくなる：プロバイダーを変える、ティアを上げる、温度を調整する。ほとんどの場合、それは違う。

すべてのプロンプトはゼロから始まる。モデルはあなたのプロダクト、ユーザー、制約、前の会話を一切覚えていない——明示的に情報を渡さない限り。「受け入れ基準を書いて」は、10人から100人のエンジニアチームを対象にしたJiraネイティブのForgeアプリと、消費者向けモバイルフィットネストラッカーとでは、まったく異なる意味を持つ。

モデルはあなたが描写する世界に応答する。何も描写しなければ、モデルは自分で世界を作る——そしてそれはほぼ確実にあなたのものではない。

同じチームの2人が同じモデルを使ってまったく異なる結果を得られる理由はここにある。スキルの問題ではない。プロンプトの構造でもない。モデルに十分なプロダクトの現実を与えたかどうかだ。

これがJiraでなぜこれほど高くつくミスを引き起こすかの大きな枠組みについては、こちらから：AIは連携不足のチームを直さない。隠すだけだ。

解決策はプロンプトのテクニックを磨くことではない。再利用可能なコンテキスト層を構築することだ——プロダクトの世界を簡潔かつ正直に描写したもの——を毎回のプロンプトの前に付加する。一度書く。どこでも再利用する。モデルは推測をやめ、チームと同じ制約の中で動き始める。

4つのレイヤー

プロダクトコンテキストは1つの塊のテキストではない。それぞれ異なる役割を持つ4つのレイヤーに自然に分かれる。

• プロダクト概要は何をするプロダクトか、誰のためか、どんな結果が重要かを説明する——運営上の真実であり、マーケティングコピーではない。この違いは重要だ。「チームのためのプロジェクト管理ツール」はあらゆるものを表し得る。「JustはJira Cloud上のプロダクトチームとエンジニアリングチームのためのJiraネイティブAIコパイロットだ。コアミッション：曖昧なJira issueを構造化された実行計画に変換する——確認質問、ステップバイステップのプラン、Jiraフィールドへの書き戻し——issueパネルを離れることなく。チャットボットではない。スタンドアロンツールではない。Atlassian Forge上に構築されている。」は、ちょうど1つのプロダクトを説明する。
• オーディエンスはユーザーが誰か、何を必要としているか、何を期待するか、何を知らないかを説明する。
• デザイン言語はビジュアルパターン、コンポーネントライブラリ、インタラクションの習慣、決してしないことを説明する。
• スタックと制約は実際のフレームワーク、ランタイムの限界、インテグレーション、明示的に禁止された選択肢を説明する。

各フィールドの悪い版は何千ものプロダクトに当てはまる。良い版はちょうど1つに当てはまる。それがテストだ。

オーディエンスは汎用コンテキストが壊れる場所

オーディエンスは通常、チームが最初に単純化しすぎるフィールドだ。「プロダクトマネージャーと開発者」は妥当に聞こえる。モデルがより良い判断を下す助けにするには、あまりにも曖昧でもある。

有用なオーディエンスフィールドは、チーム構成、AIへの習熟度、信頼の期待値、そしてユーザーが望まないことについて具体的だ。Justの場合、それは10〜100人のJira Cloudチームに所属するPMとシニアエンジニアを意味し、AIへの習熟度は中程度、自分でAPIキーを管理し、派手な出力よりも信頼できる出力を重視している。

「対象外」の一行は同じくらい重要だ。Jira Cloud以外のチームや、完全に自律したエージェントを求めるユーザーには向かないと明記することで、誤った前提のカテゴリー全体を事前に除外できる。

これがコンテキストを装飾的ではなく根拠のあるものにする理由だ。モデルはユーザーが誰かを教えられるだけでなく、そのユーザーがどんな世界で動いているか、どんなワークフローが不自然に感じられるかも同時に説明される。

すでにあるものを引き出す

ほとんどのチームはすでに4つのコンテキストレイヤーを持っている——ただコードベース、デザインファイル、ドキュメント、チームの記憶に散らばっており、AIが使える形になっていないだけだ。

**リポジトリから：**コーディングエージェント——Claude Code、Codexなど——をコードベースに向けて、プロダクトの目的、スタック、実装の境界、既知の制約を含むMarkdownサマリーを求める。よく構造化されたリポジトリは数分で使えるファーストドラフトを出せる。

**デザインファイルから：**コンポーネントライブラリの名前、プロダクトが頼りにしている3〜5つの主要インタラクションパターン、UIが決してしない3つのことを特定する。アンチパターンはパターンと同様に重要だ。

**既存のドキュメントから：**オンボーディングノート、READMEファイル、社内ブリーフ、マーケティングコンテキストはいずれもプロダクトサマリーとオーディエンス定義の断片を提供できる。完璧でなくても有用だ。

**自分の頭から：**上記のものがまだ何も存在しない場合は、今すぐ空のドキュメントを開き、各フィールドに1段落を書く。不完全になる。不完全なコンテキストはコンテキストなしを大きく上回る。

完璧なドキュメントは必要ない。プロダクトが生きている世界の、簡潔で正直な描写が必要だ。

一度保存して、どこでも再利用する

コンテキストは再利用可能なときにのみ効果を発揮する。一度書いて1つのセッションに貼り付けるのはそのセッションの助けになる。永続化させることはすべてのセッションの助けになる。

• **Justでは、**管理パネルにこれら4つのコンテキストフィールドそれぞれの専用セクションがある——プロダクト概要、オーディエンス、デザイン言語、スタック。各フィールドにコンテンツをプロジェクトごとに一度貼り付けるだけで、そのプロジェクトの今後のすべてのインサイト、確認質問、プラン、実行ステップが自動的にこのコンテキストに根ざして動く。
• **Justを使っていない場合は、**リポジトリのルートまたは共有ドキュメントにcontext.mdファイルを1つ作成する。同じ4つのセクションで構成する。AIセッションの開始時に貼り付ける——コーディングアシスタント、チャットツール、ドキュメント生成ツール。フォーマットよりも習慣が重要だ：まずコンテキスト、それからプロンプト。

コンテキスト層はリリース日のアーティファクトではなく、生きたドキュメントとして扱う。プロダクトが大きく変わったとき——新しいインテグレーション、主要なオーディエンスシフト、デザインシステムの移行——に見直す。毎スプリント見直す必要はない。プロダクト概要が2週間ごとに変わるなら、それはプロダクト概要ではなく会議メモだ。

コンテキストはプロンプトエンジニアリングではない

プロダクトコンテキストはプロンプトエンジニアリングではない。トリックでも、テンプレートでも、巧みなハックでもない。モデルに初日の新しい外部委託者に渡すのと同じブリーフィングを与えることだ：これが私たちが作っているもの、誰のため、どう見えるべきか、何で動くか。

これを一度行い——そして一貫して再利用する——チームは、プロダクトを本当に理解している人間が書いたように感じられる出力を得る。なぜなら、すべての機能的な意味においてそれが真実だからだ。モデルは賢くなったわけではない。ただ推測させるのをやめたのだ。