記事

プロンプトより先に作る「コンテキストパック」:AIの回答品質を安定させる実務テンプレート

この記事の要点

Karpathy氏のcontext engineeringやLLM knowledge base、swyx氏のAI品質評価に関するX投稿をもとに、AI回答のばらつきを減らすコンテキストパックの作り方、プロンプト、7日間手順を解説します。

プロンプトより先に作る「コンテキストパック」:AIの回答品質を安定させる実務テンプレート

この記事で解決する悩みは、「AIに聞くたびに回答がばらつく」「資料を渡しているのに欲しい出力にならない」「AIの下書きがそのまま使えず、結局チェックに時間がかかる」という問題です。

結論から言うと、AI活用で差がつくのは、きれいな一文のプロンプトではなく、AIに渡す情報を設計するコンテキストパックです。つまり、目的、前提資料、禁止事項、判断基準、出力形式、検証方法を1つにまとめた作業セットを作ります。

今回は、Karpathy氏の「context engineering」やLLM knowledge baseに関する投稿、swyx氏が紹介している評価・品質に関する投稿を参考に、会社員・個人事業主・小規模事業者が実務で使える形に再構成します。

参考にしたX投稿:プロンプトではなくコンテキストを設計する

Karpathy氏は、短い指示文としての「prompt engineering」より、次のステップに必要な情報を文脈へ入れる「context engineering」の重要性に触れています。

これは、日々の資料作成、顧客対応、記事作成、営業企画でもそのまま使えます。AIに「いい感じにまとめて」と頼むのではなく、AIが判断に使う材料を先に揃える発想です。

コンテキストパックとは何か

コンテキストパックとは、AIに仕事を頼む前に渡す「作業に必要な情報一式」です。単なる添付資料ではなく、AIが迷わず判断できるように整理したものです。

入れるもの目的
目的何のための作業かを固定する
読者・利用者誰に向けた出力かを明確にする
元資料根拠にする情報を限定する
禁止事項推測、断定、機密利用、転載を防ぐ
出力形式そのまま使える形にする
検証基準AI出力を採用できるか判断する

まず使うテンプレート:コンテキストパック基本形

# Context Pack: {作業名}

## 1. 今回解決したい悩み
{例: 提案資料を作るたびに構成で迷う}

## 2. 最終成果物
{例: A4 1枚の提案資料 / ブログ記事 / 週報 / 顧客返信文}

## 3. 読者・利用者
{例: 上司、顧客、社内メンバー、見込み客}

## 4. AIに渡す資料
- {URLやメモ}
- {過去資料}
- {社内ルール}

## 5. 使ってよい情報
{根拠として使ってよい資料の範囲}

## 6. 使ってはいけない情報
{個人情報、未公開情報、推測、古い料金情報など}

## 7. 出力形式
{見出し、表、箇条書き、HTML、メール文など}

## 8. 品質チェック
- 事実と推測が分かれているか
- 出典があるか
- 読者の悩みに答えているか
- そのまま使える具体性があるか

プロンプト1:資料をコンテキストパックに整理する

あなたは業務設計アシスタントです。
以下の資料を、AIに作業を依頼するためのコンテキストパックに整理してください。

# 元資料
{会議メモ、URL、商品情報、過去資料など}

# 作りたい成果物
{ブログ記事 / 提案資料 / 顧客返信 / 週報 / マニュアル}

# 出力形式
1. 今回解決したい悩み
2. 最終成果物
3. 読者・利用者
4. AIに渡すべき資料
5. 使ってよい情報
6. 使ってはいけない情報
7. 出力形式
8. 品質チェック項目
9. 不足している情報

# 注意
- 不明な点は「要確認」と書く
- 元資料にない事実を追加しない
- 読者の悩みから逆算する

参考にしたX投稿:LLMで知識ベースを作る

Karpathy氏は、LLMを使って個人用の知識ベースを作ることにも触れています。ここから分かるのは、AI活用の対象が「その場の回答」から「あとで再利用できる知識の整備」に移っていることです。

知識ベース化するとAIの回答が安定する

毎回チャットに長文を貼るのではなく、よく使う情報をMarkdownや表で保存しておくと、AIに渡す文脈が安定します。

/context-packs
  /company
    service-overview.md
    tone-and-style.md
    forbidden-claims.md
  /customers
    common-questions.md
    case-notes.md
  /articles
    source-policy.md
    article-template.md
    review-checklist.md

会社員なら部門内の共有資料、個人事業主ならサービス説明、よくある質問、実績、禁止表現を整理しておくと、提案文や記事作成が安定します。

プロンプト2:知識ベースを更新する

以下の新しい情報を、既存の知識ベースに追加すべきか判断してください。

# 既存の知識ベース
{既存メモ}

# 新しい情報
{新しいメモ、顧客質問、記事URL、社内決定}

# 判断基準
1. 今後も再利用するか
2. 事実として確認済みか
3. 古い情報と矛盾しないか
4. AIに渡してよい情報か
5. どのファイルに入れるべきか

# 出力形式
- 追加すべき情報
- 追加しない情報
- 矛盾している情報
- 要確認の情報
- 更新後のMarkdown案

出力品質は「採用できるか」で見る

AIの出力は、見た目が整っていても実務で使えるとは限りません。swyx氏が紹介している投稿では、ベンチマーク上の結果でも実際にはマージできない品質のものがある、という問題が示されています。

これはソフトウェア開発に限りません。記事、資料、メール、マニュアルでも、「読める」ことと「採用できる」ことは違います。

プロンプト3:AI出力を採用判定する

以下のAI出力を、実務で採用できるか判定してください。

# 元の依頼
{最初にAIへ依頼した内容}

# コンテキストパック
{目的、資料、禁止事項、品質基準}

# AI出力
{ここに出力を貼る}

# 判定基準
1. 目的に答えているか
2. 根拠があるか
3. 推測が混ざっていないか
4. 読者・利用者に合っているか
5. そのまま使える具体性があるか
6. 修正すれば使えるか
7. 採用不可なら理由は何か

# 出力形式
- 採用可 / 修正すれば可 / 採用不可
- 理由
- 修正すべき箇所
- 追加で必要な情報
- 修正版プロンプト

プロンプト4:批判役にレビューさせる

あなたは批判的レビュー担当です。
以下の成果物を、採用前提ではなく「落とすため」に確認してください。

# 成果物
{AIが作った記事、資料、メール、マニュアル}

# チェック項目
- 事実誤認
- 出典不足
- 読者の悩みとのズレ
- 抽象的すぎる説明
- 実行できない手順
- 法務・料金・効果の断定
- 機密情報や個人情報の混入

# 出力形式
1. 最も危険な問題
2. 採用前に必ず直す点
3. 直せば使える点
4. 捨てるべき部分
5. 追加すべき具体例

Notionのような知識ワークツールでも文脈設計が重要になる

swyx氏は、Notion AIやCustom Agentsに関する投稿もしています。ここからも、AIの価値は単体チャットではなく、知識、権限、ワークフロー、チームの文脈と結びついたときに大きくなることが読み取れます。

7日間でコンテキストパックを導入する

Day 1:よく発生する作業を1つ選ぶ

会議メモ整理、記事作成、顧客返信、営業資料、週報など、繰り返し発生する作業を1つ選びます。

Day 2:過去資料を集める

過去の成功例、よくある質問、禁止表現、参考URLを集めます。

Day 3:基本テンプレートに埋める

目的、成果物、読者、使ってよい情報、使ってはいけない情報を書きます。

Day 4:AIに初稿を作らせる

コンテキストパックを渡して、成果物の初稿を作ります。

Day 5:採用判定する

プロンプト3を使い、出力が実務で使えるか判定します。

Day 6:批判役にレビューさせる

プロンプト4で、あえて厳しくチェックします。

Day 7:テンプレートとして保存する

うまくいったコンテキストパックを保存し、次回以降の標準手順にします。

最終チェックリスト

  • 解決する悩みが最初に書かれている
  • AIに渡す資料が整理されている
  • 使ってよい情報と禁止情報が分かれている
  • 出力形式が明確になっている
  • 採用判定の基準がある
  • 批判役レビューを通している
  • 次回も使えるテンプレートとして保存している

今日すぐ試すなら

まず、直近でAIに頼んだが微妙だった仕事を1つ選び、コンテキストパック基本形に埋め直してください。プロンプトを磨くより先に、AIに渡す材料と採用基準を整えるだけで、出力の安定度が変わります。

参考にしたX投稿