AIに仕事をうまく任せる方法: 良いプロンプトより良い作業チケットが先

1. 概要: モデルだけを替えても仕事は良くならない

曖昧な依頼は曖昧な成果を生みます。「提案書を書いて」だけでは、AIは顧客、トーン、価格ロジック、法的な境界、形式を推測します。そのあと人間が、AIの推測違いを修正することになります。問題はモデル性能ではなく、仕事が最初から十分に定義されていないことかもしれません。

OpenAIとAnthropicのプロンプトガイドは、共通して同じ方向を示しています。明確に指示し、必要な文脈を渡し、例を示し、望む出力形式を指定することです。OpenAIのStructured Outputsはさらに、許容される出力の形を構造で定義します。運用者の言葉に直すと、良い一文を書くより、仕事をパッケージ化して渡すべきだということです。

今回の調査では、ローカルXインボックスにも同じ現場シグナルがありました。毎回チャットでトーンや禁止事項を繰り返すのではなく再利用できるAI設定を作る話、ブラウザ上でUIの問題を直接指摘する流れ、初期PRDと実際のソースコードを照合する使い方、公開前の安全チェックリストが目立ちました。X投稿は最終的な事実根拠ではなく、現場の摩擦を示すシグナルとして扱っています。

2. 用語をやさしく整理: プロンプト、作業チケット、SOP、MCP、完了基準

プロンプトは、AIに送る質問や指示です。作業チケットは、その指示を含む仕事の依頼書です。何を達成するのか、どの根拠を見るのか、何をしてはいけないのか、どの形式で出すのか、どう検証するのかをまとめます。

SOPはStandard Operating Procedureの略です。簡単に言えば、会社で繰り返す仕事のレシピです。CLAUDE.mdやAGENTS.mdのようなファイルは、AI向けの業務ブリーフィングです。プロジェクトの安定したルール、実行コマンド、文体、避けるべきリスク、重要ファイルをAIに伝えます。

MCP、つまりModel Context Protocolは、AIが外部ツールやデータソースにつながるための標準化された通路です。ただしMCPがあっても、仕事が自動で定義されるわけではありません。何をすべきか、どこまで許されるか、何をもって完了とするかは作業チケットで決める必要があります。受け入れ条件は成果物が満たすべきチェック項目で、Definition of Doneは仕事を完了と呼ぶための証拠です。

• プロンプト: AIへの直接の指示。
• 作業チケット: 指示を含む仕事全体の依頼書。
• SOP: 繰り返し業務の会社レシピ。
• AIブリーフィングファイル: AIが覚えるべきプロジェクトルール。
• MCP: AIが外部ツールやデータにつながる通路。
• 受け入れ条件: 成果物が満たすべきチェック項目。
• 完了基準: 完了と呼ぶ前に必要な証拠。

3. なぜ曖昧なプロンプトはコストになるのか

一つ目のコストは、推測の修正です。人間が「営業メールを書いて」とだけ言うと、AIは対象顧客、価格条件、禁止表現、トーン、長さを推測します。見た目は良くても、実務には合わないかもしれません。そのあと人間は「これは外して、このトーンで、この条件を入れて」を繰り返します。

二つ目のコストは、文脈の欠落です。重要な根拠がNotion、リポジトリ、ポリシーPDF、過去の意思決定にあるのにモデルが見ていない場合、答えは自信ありげでも会社の実際の判断基準から外れます。Anthropicがエージェントのcontext engineeringを強調する理由もここにあります。長い会話より、必要な情報を必要な瞬間に渡すことが重要です。

三つ目のコストは、完了が見えないことです。「よさそう」は完了基準ではありません。コードならlint、build、ルート確認、コミット証拠が必要かもしれません。ブログなら根拠、画像、多言語ルート、sitemap、ライブURL確認が必要です。顧客対応ならポリシー遵守と人間の承認境界が必要です。

4. 7項目のAI作業チケット

良い作業チケットは一画面に収まります。官僚的にしたいわけではありません。AIが作業を始める前に、隠れていた判断基準を見えるようにするためです。同じ依頼が二回以上繰り返されるなら、テンプレートにする価値があります。

一つ目は目的です。どのユーザー成果、または事業成果を変えたいのかを書きます。二つ目は背景文脈です。AIが行動する前に知るべき状況です。三つ目は根拠パックです。リンク、ファイル、ノート、例、スクリーンショット、ログなど、回答を制約する材料です。

四つ目は制約と禁止事項です。根拠のない主張は禁止、法的約束は禁止、価格変更は禁止、特定フォルダ外の編集は禁止、承認なしのライブサービス呼び出しは禁止、という形で書きます。五つ目は出力形式。六つ目は検証方法。七つ目は完了証拠とエスカレーション条件です。何を報告すれば終わりか、いつ止めて人間に聞くかを決めます。

• 目的: どの成果を変えるのか。
• 背景: 仕事を理解するための文脈は何か。
• 根拠パック: AIが読む、または引用する材料は何か。
• 制約: 絶対にしてはいけないことは何か。
• 出力形式: どんな形で結果を出すのか。
• 検証方法: 何で結果を確認するのか。
• 完了証拠: 何を示せば終わりか、いつ人間に渡すか。

5. 運用者がすぐ使える四つの例

ブログ記事なら、チケットにはテーマ、読者、必要な根拠の種類、引用が必要な主張、画像要件、多言語反映、SEO確認、ライブ確認が入ります。これで「記事を書いて」が、公開可能なワークフローになります。

顧客返信なら、顧客履歴、ポリシー根拠、トーンの境界、返金や契約ルール、絶対に約束してはいけない内容、送信前の人間承認が入ります。これにより、温かいけれど危険な文章を減らせます。

コード変更なら、対象ファイル範囲、期待動作、受け入れ条件、実行する検証コマンド、ルートやスクリーンショットの証拠、コミット方針、ロールバックメモが入ります。Codexのようなコーディングエージェントは、ファイルを変更し、検証を実行し、証拠を残すときに強みを発揮します。

• 調査要約: 根拠優先、矛盾記録、信頼度ラベル、未検証主張の削除。
• ブログ記事: 根拠ログ、画像、多言語ルート、SEO、sitemap、ライブ確認。
• 顧客返信: ポリシー根拠、トーン、禁止約束、承認境界。
• コード変更: ファイル範囲、テスト、build、diff、コミット、デプロイ証拠。

6. 習慣ではなく仕事の種類でツールを選ぶ

作業チケットは、どのツールに任せるべきかも整理します。根拠に縛られる質問は検索やRAGから始めるのが自然です。戦略、判断、ナラティブのように曖昧な仕事はプレミアム推論モデルが向いています。ファイル修正、テスト、ルート確認はCodexのようなコーディングエージェントに向いています。取り返しのつかない決定は、今でも人間が承認すべきです。

この区別が重要なのは、チームがお金と注意力を同時に浪費しうるからです。強いモデルは弱い文脈からでも美しい答えを書けます。しかし美しい答えが業務上安全とは限りません。小さなモデルは整形を速くできますが、契約リスクを承認してはいけません。作業チケットは、この配置を見えるようにします。

GUILDEX式に言えば、根拠パックが先、作業チケットが二番目、モデル選択が三番目、検証が最後です。最初の二つを飛ばすと、チームは委任の問題をモデルの問題だと誤解します。

7. 人も一緒に成長すべき理由: 委任リテラシー

AIはこれからも強くなります。それでも人間の成長が不要になるわけではありません。重要な能力の位置が変わります。これから価値が高い人は、自分で書く、調べる、コードを書く、要約する人だけではありません。仕事を定義し、真の根拠を選び、境界を決め、ツールを配置し、結果を評価し、次回のためにテンプレートを改善できる人です。

だから作業チケットは単なる文書作業ではありません。委任リテラシーです。暗黙の判断を明示し、繰り返し説明を減らし、個人のプロンプト感覚をチームの運用資産に変えます。

今週できる最初の行動はシンプルです。よく使うAI依頼を一つ選び、7項目のチケットとして書き直してください。そして結果、検証証拠、修正点を残してください。二回目は安くなるべきです。三回目はテンプレートになるべきです。