AIエージェントに役立つ仕事をさせるブリーフの書き方：ゴール、入力、制約、完了の定義、レビュー

ブリーフのないエージェントが悪い成果物を出す理由

エージェントはループです。タスクを読み、ツールを選び、行動し、結果を読み、完了したと判断するまで繰り返します。その判断のひとつひとつが、あなたが渡したテキストを基準に行われます。テキストが「完了」の姿を示していなければ、エージェントは自分で決めます。しかも早めに決めます。続けるより止まるほうが安いからです。テキストが触ってはいけないものを示していなければ、一番近くにあるものを触ります。

2026年半ばまでに、実務者の共通認識はいくつかの方向から同じ点に収束しました。エージェントから価値を得ているチームは、外部委託先に対するようにブリーフを書き、プルリクエストのように成果物をレビューしています。チャット欄に1文打ち込んで返ってきたものを受け入れるチームは、もっともらしいがやり直しの必要な仕事の流れを受け取っています。ツールは良くなりましたが、ブリーフの必要性は消えていません。むしろ増えました。エージェントは今、より長く動き、より多くのものに触れるからです。

ブリーフはプロンプトの小技ではありません。初日にそのタスクをやる新入社員のために書く文書と同じもので、エージェントには社会的な文脈が不要なぶん短くなっているだけです。

ブリーフの5つの要素

ゴール：活動ではなく成果を1文で

「予約リマインダーの要件書を書く」は活動です。「木曜の計画会議でエンジニアリングが見積もれるように、予約リマインダーの要件を作る」は読者と期限のある成果です。後者はエージェントに、どれだけの詳細が重要で、誰が判断するのかを伝えます。

入力：情報源を名指しし、どれが優先か言う

エージェントが使ってよい文書、issue、ページ、データを、それぞれの場所と、食い違ったときの扱いとともに列挙します。「/pages/booking-reminders のPRDがベースライン。Slackのスレッドは背景情報のみ。矛盾する場合はPRDが優先で、矛盾を報告すること」。これがないと、エージェントは情報源を混ぜて筋を見失います。

制約：触らないもの、仮定しないもの

重要なのは3種類です。範囲：「カレンダー同期への変更は提案しない」。事実：「顧客名、価格、日付をでっち上げない。代わりに『不明』と書く」。行動：「読み取りのみ。issueを作成したり更新を投稿したりしない」。最後のものはエージェントに付与するスコープと直結するので、ブリーフと権限は一緒に書くべきです。

完了の定義：エージェントが自分で実行できるチェックリスト

「良い文書」ではなく、「ゴール、ユーザーストーリー、非ゴール、未解決の質問のセクションがある文書。各ユーザーストーリーに受け入れ基準がある。空のセクションがない。1,200語以内」。エージェントは止まる前にこれを確認し、レビュー担当者も同じリストを確認するので、2人が同じものを見ることになります。

レビュー：名前のある人と、名前のある成果物

「issueが作られる前に、Moeidが要件ページをレビューする」。名前ではなく役職（「PM」）で書かれたレビューは飛ばされます。成果物のないレビュー（「作業をレビューする」）はちらっと見るだけになります。

コピーして使えるブリーフのテンプレート

ゴール: <成果、読者、期限>

入力:
- <情報源1、場所、役割: ベースライン | 背景>
- <情報源2 ...>
情報源が矛盾する場合: <どれが優先か。矛盾を報告する>

制約:
- 範囲: <対象外のもの>
- 事実: <名前、数値、日付>をでっち上げない。「不明」と書く
- 行動: <読み取りのみ | Xを作成してよい | Yをしてはならない>

完了の定義:
- [ ] <セクションまたは成果物1がある>
- [ ] <各項目に...がある>
- [ ] <長さまたは形式の上限>
- [ ] 未解決の質問を列挙し、推測で解決しない

レビュー: <人>が<次の行動>の前に<成果物>をレビューする。

200語以内に収めてください。長いブリーフは、タスクが実は2つであるサインです。

実例：AtrixでのDevelop実行

私たちのAIエージェントはブリーフを受け取り、Develop実行から3つのものを返します。要件書、アーキテクチャ文書、計画済みissueの一式で、どれも実際の作業になる前に人が承認します。実行1回でプランのAI実行を1つ消費し（Builderは月100回、Studioは月500回）、エージェントとのチャットは消費しません。先週渡したブリーフを少し編集したものがこれです。

ゴール: 金曜に次のサイクルを計画できるよう、「予約リマインダー」の
要件、アーキテクチャ、計画済みissueを作る。

入力:
- ページ「予約リマインダー: メモ」（ベースライン）
- Calendarプロダクトで「reminders」ラベルの付いたissue（背景）
矛盾する場合はページが優先。矛盾は未解決の質問に列挙する。

制約:
- 範囲: メールとアプリ内のみ。今サイクルはSMSなし。
- 事実: 配信率や顧客の発言をでっち上げない。
- 行動: これは計画の実行。計画済みissueのみ作成し、既存issueの
  ステータスは変えない。

完了の定義:
- [ ] ユーザーストーリーと受け入れ基準を含む要件
- [ ] 触るコンポーネントと触らないコンポーネントを明記したアーキテクチャ
- [ ] 1人が1サイクルで終えられる大きさの計画済みissue。それぞれが
      実装する要件に紐づいている
- [ ] 未解決の質問の一覧

レビュー: Moeidが要件ページを承認し、次に計画済みissueを承認してから
バックログに入れる。

返ってきたのは11件の計画済みissue、2つの未解決の質問（うち1つはメモページと古いissueの間の実際の矛盾）、そして同期レイヤーに正しく手を付けなかったアーキテクチャ文書でした。要件監査は後に、納品されたissueをその凍結されたベースラインと比較してカバレッジを報告しました。監査が確認するのは計画に対する要件であってコードではないので、「アーキテクチャ文書が正直か」の部分は依然として私たちが検証する仕事でした。

エージェントが足りなかった点：2件のissueを大きく見積もりすぎ、制約があるにもかかわらず未解決の質問を1つ推測で解決しました。どちらもレビューで捕まえました。レビューを置く意味はそこにあります。

悪い成果物を生む失敗

• ゴールを活動として書く。 エージェントは活動をして止まります。
• ベースラインを名指ししない。 3つの情報源を混ぜ、結果はどれとも一致しません。
• 事実について「判断に任せる」。 数値をでっち上げます。「不明」でよいと言ってください。
• 完了の定義がレビュー担当者の頭の中にある。 言われていないことをエージェントは確認できません。
• 役職でレビューを指定する。 誰も責任を持たず、そのまま出ていきます。
• 2つのタスクに1つのブリーフ。 分割してください。短い実行2回は長い実行1回に勝ります。
• 実行後にブリーフを書く（成果物を正当化するために）。ブリーフは契約で、先に来るものです。

よくある質問

AIエージェントへのブリーフには何を含めるべきですか？

5つです。成果と読者を含む1文のゴール、使ってよい入力とその優先順位、範囲・事実・行動に関する制約、エージェントが自分で確認できる完了の定義、名前付きの成果物を持つ名前付きのレビュー担当者。200語以内で。

エージェントへのブリーフはチャットボットへのプロンプトとどう違いますか？

チャットボットは1回答えて、あなたが読みます。エージェントはあなたが何かを見る前に何度も行動するので、ブリーフは何を言うかだけでなく、何に触れてよいか、いつ止まるかを扱う必要があります。言い回しより制約と完了の定義が重要です。

完了の定義はどれくらい詳しくすべきですか？

エージェントがあなたに聞かずに各項目にチェックを入れられる程度に詳しく、レビュー担当者が実際に確認する程度に短く。チェックリスト5〜8行が典型です。

エージェントに未解決の質問を解決させてよいですか？

いいえ。列挙させてください。曖昧さを推測で解決するエージェントは、完成して見えるが最も重要な細部で間違っている成果物を出します。

エージェント実行とは何ですか？

ブリーフに対するエージェントの1回の実行で、開始と終了、レビューすべき成果物があります。AtrixではDevelop実行が要件、アーキテクチャ、計画済みissueを返します。エージェント実行の用語集の項目とAIエージェントの定義を参照してください。

良いブリーフがあればレビューは不要になりますか？

いいえ。良いブリーフはレビューを速くします。レビュー担当者がすべてを一から読む代わりに完了の定義を確認すればよいからです。それでもエージェントが間違えた2〜3点を捕まえるのがレビューの役割です。

次のステップ

次にエージェントに渡そうとしているタスクを取り、始める前に5つの要素を書いてください。完了の定義が書きにくいなら、そのタスクはまだエージェント向きではありません。ブリーフ付きの実行が実際に何を返すかは、AIエージェントのページにDevelop実行が生成する要件、アーキテクチャ、計画済みissueが載っています。