プロンプトより先に作る「コンテキストパック」:AIの回答品質を安定させる実務テンプレート
Karpathy氏のcontext engineeringやLLM knowledge base、swyx氏のAI品質評価に関するX投稿をもとに、AI回答のばらつきを減らすコンテキストパックの作り方、プロンプト、7日間手順を解説します。
この記事で解決する悩みは、「AIに聞くたびに回答がばらつく」「資料を渡しているのに欲しい出力にならない」「AIの下書きがそのまま使えず、結局チェックに時間がかかる」という問題です。
結論から言うと、AI活用で差がつくのは、きれいな一文のプロンプトではなく、AIに渡す情報を設計するコンテキストパックです。つまり、目的、前提資料、禁止事項、判断基準、出力形式、検証方法を1つにまとめた作業セットを作ります。
今回は、Karpathy氏の「context engineering」やLLM knowledge baseに関する投稿、swyx氏が紹介している評価・品質に関する投稿を参考に、会社員・個人事業主・小規模事業者が実務で使える形に再構成します。
参考にしたX投稿:プロンプトではなくコンテキストを設計する
Karpathy氏は、短い指示文としての「prompt engineering」より、次のステップに必要な情報を文脈へ入れる「context engineering」の重要性に触れています。
+1 for “context engineering” over “prompt engineering”.
People associate prompts with short task descriptions you’d give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window… https://t.co/Ne65F6vFcf
— Andrej Karpathy (@karpathy) 2025年6月25日
これは、日々の資料作成、顧客対応、記事作成、営業企画でもそのまま使えます。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活用の対象が「その場の回答」から「あとで再利用できる知識の整備」に移っていることです。
LLM Knowledge Bases
Something I’m finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating…
— Andrej Karpathy (@karpathy) 2026年4月2日
知識ベース化すると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氏が紹介している投稿では、ベンチマーク上の結果でも実際にはマージできない品質のものがある、という問題が示されています。
It’s finally out!!! @METR_Evals found that more than half of SWEBench results is unmergeable slop. FrontierCode represents over 1000+ hours of maintainer validated software engineering work most frontier models cannot yet solve, much less solve with high quality.
Cog had IOI… https://t.co/1yXCeGxFe9 pic.twitter.com/l8mgYiqYuE
— swyx (@swyx) 2026年6月8日
これはソフトウェア開発に限りません。記事、資料、メール、マニュアルでも、「読める」ことと「採用できる」ことは違います。
プロンプト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の価値は単体チャットではなく、知識、権限、ワークフロー、チームの文脈と結びついたときに大きくなることが読み取れます。
finally: @simonlast + @sarahmsachs on Latent Space!
Notion has rebuilt Notion AI 5 times. This is the first time Simon has told the entire story.
I’ve been trying to do this interview for ~3 years. We run @latentspacepod on Notion since inception, as does every other top tech… https://t.co/wjXulmgFKR
— swyx (@swyx) 2026年4月15日
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投稿
- Karpathy氏のcontext engineering投稿: https://x.com/karpathy/status/1937902205765607626
- Karpathy氏のLLM knowledge base投稿: https://x.com/karpathy/status/2039805659525644595
- swyx氏のAI出力品質・評価に関する投稿: https://x.com/swyx/status/2064081945567580323
- swyx氏のNotion AI / Custom Agentsに関する投稿: https://x.com/swyx/status/2044220922387984408