AI開発は「コンテキストパケット」で速くなる: 調査からレビューまで任せる前に渡す設計書

結論: AI開発は「プロンプト」より先に、渡す文脈で決まる

AIに実装を頼んだら、なんか違うものが返ってきた。

AIに調査を頼んだら、情報は多いけど結局どれを信じたらいいかわからない。

AIにレビューを頼んだら、細かい指摘は出るけど、プロダクトとして本当に大事なところを見てくれない。

これ、AIが弱いというより、渡している文脈が薄い ことが多いんですよね。

最近のAI開発ツールは、もう「コードを1ファイル生成する道具」ではなくなってきています。Codexは開発ライフサイクル全体、PRレビュー、複数ファイル、ターミナル、ブラウザ、メモリ、スケジュール実行のような方向に広がっています。GitHub Copilot cloud agentも、GitHub、IDE、CLI、MCP、Slack、Jiraなど複数の入口から作業を開始できるようになっています。MCPはAIアプリを外部ツールやデータソースにつなぐ標準として広がっています。

つまり、AIにできることが増えた。

でも、できることが増えるほど、雑に任せた時のズレも大きくなる。

そこで大事になるのが、この記事でいう コンテキストパケット です。

コンテキストパケットは、AIに作業を任せる前に渡す「小さな設計書」です。Issue本文、PR説明、AIへの依頼文、運用ログ、どこに置いてもいいんですが、最低限この7つを入れます。

1. 目的
2. 背景
3. 制約
4. 利用できるツール
5. 権限境界
6. 合否条件
7. レビュー観点

正直、これだけです。

でも、不思議なことに、これだけでAIの仕事の安定感がかなり変わります。

プロンプトの言い回しを磨くのも大事です。けど、もっと手前にあるのは 「AIが判断するための材料を、どれだけ丁寧に渡せるか」 なんです。

まず用語を整理します

いきなり Context Engineering とか MCP とか Memory とか言われると、ちょっと身構えますよね。

なので、先にかなり噛み砕きます。

Context Engineering は、AIに渡す文脈を設計することです。プロンプトエンジニアリングが「どう言うか」だとしたら、Context Engineeringは「何を渡すか」「どの順番で渡すか」「何を渡さないか」まで含みます。

MCP は、AIが外部ツールやデータに接続するための共通規格です。ざっくり言うと、AIにとってのUSB-Cみたいなものです。ファイル、DB、検索、社内ツール、デザインツールなどに、同じような考え方でつなぎやすくするための仕組みです。

Memory は、AIが前回までの好み、判断、プロジェクト知識を覚えて次に活かす仕組みです。ただし、何でも覚えさせればいいわけではありません。古い情報や間違った情報を覚えると、むしろ判断が濁ります。

Browser Automation は、AIがブラウザを見て、クリックして、入力して、確認するような自動操作です。フロントエンドの確認や管理画面の操作では便利ですが、ログイン、権限、公開、削除のような操作が絡むと、一気に慎重さが必要になります。

ここで重要なのは、AIが強くなるほど、人間の仕事が減るというより、人間が設計するものが変わる ということです。

昔は「実装手順」を人間が全部考えていました。

これからは、AIが動けるように、

• 何がゴールか
• 何を触っていいか
• 何を触ってはいけないか
• どうなったら成功か
• どこを人間が確認するか

を設計する比重が増えていきます。

実装者から、文脈設計者へ。

なんか大げさに聞こえるかもしれませんが、日々のIssueやPRに落とすと、かなり現実的な話です。

コンテキストパケットの基本形

まずはテンプレを置きます。

## Context Packet

### 1. 目的
何を達成したいか。

### 2. 背景
なぜ今やるのか。関連する仕様、過去の判断、ユーザー課題。

### 3. 制約
守るべき技術制約、期限、既存設計、非対応範囲。

### 4. 利用できるツール
参照してよいファイル、API、MCP、ブラウザ操作、テストコマンド。

### 5. 権限境界
AIが実行してよいこと、必ず人間承認が必要なこと、禁止事項。

### 6. 合否条件
何を満たせば完了か。テスト、表示、ログ、レビュー条件。

### 7. レビュー観点
人間が最後に見るべき観点。品質、セキュリティ、UX、運用。

これを毎回ゼロから完璧に書く必要はありません。

最初は3分でいいです。

たとえば、AIに「検索機能を直して」と言う代わりに、こう渡します。

## Context Packet

### 1. 目的
商品一覧画面の検索で、キーワード入力後に結果が0件になる不具合を修正する。

### 2. 背景
検索APIは `/api/products?keyword=` を使う。直近のUI改修後から、空白を含むキーワードで再現している。

### 3. 制約
API仕様は変更しない。UIコンポーネントの見た目も大きく変えない。

### 4. 利用できるツール
`npm test`、`npm run lint`、関連ファイルの読み取り、ローカルでの再現確認。

### 5. 権限境界
DBの削除、外部APIへの本番リクエスト、認証情報の表示は禁止。

### 6. 合否条件
空白を含むキーワードで検索できる。既存テストが通る。検索なし状態の表示が壊れない。

### 7. レビュー観点
URLエンコード、空文字処理、既存UIとの整合性、テスト追加の有無。

この粒度なら、AIはかなり動きやすくなります。

「検索直して」だと、AIはどこまで変えていいのか分かりません。APIを変えていいのか、UIを変えていいのか、テストを追加していいのか、本番データに触っていいのかも曖昧です。

曖昧さは、AIにとって自由ではなくノイズです。

人間でも同じですよね。背景も制約もないまま「いい感じに直しといて」と言われたら、まあ困ります。

AIも同じです。

人間が設計すること、AIに任せること

ここを分けておくと、AI活用がかなり安定します。

領域	人間がやること	AIに任せやすいこと
調査	何を知りたいか、信頼する情報源、採用基準を決める	複数資料の要約、比較表作成、論点抽出
要件整理	ユーザー価値、非対応範囲、優先順位を決める	仕様案、質問リスト、エッジケース洗い出し
設計	アーキテクチャ方針、責務分割、リスク許容度を決める	設計案の比較、代替案、影響範囲調査
実装	最終判断、権限境界、レビュー基準を持つ	コード変更、テスト追加、リファクタ案
レビュー	何を重視するか、リリース可否を判断する	差分説明、バグ候補、セキュリティ観点の列挙
運用	障害時の優先順位、顧客影響、再発防止方針を決める	ログ要約、仮説出し、手順書ドラフト

AIに任せるほど、人間は楽になる。

これは半分正しいです。

でも、もう半分は「人間の判断がより上流に移る」です。

AIが実装を速くするなら、人間は 何を実装すべきか を丁寧に決める必要があります。

AIがレビューを速くするなら、人間は 何を品質と呼ぶか を決める必要があります。

AIがブラウザやMCPで外部ツールを操作できるなら、人間は どこまで触らせるか を決める必要があります。

ここを雑にすると、AIの速度がそのまま事故の速度になります。

プロンプト例1: 調査を任せる

まず調査です。

調査は「調べて」だけだと、情報が広がりすぎます。最初に、何を意思決定したいのかを渡すのがコツです。

あなたは開発チームの技術調査担当です。

次のContext Packetを前提に、採用判断に必要な情報だけを整理してください。

## 目的
社内管理画面にAI検索機能を追加するか判断したい。

## 背景
現在はSQL検索とフィルタで対応しているが、問い合わせ対応チームから「自然文で探したい」という要望がある。

## 制約
個人情報を外部に送信しない。初期リリースは社内利用のみ。運用担当がログを確認できること。

## 調査してほしいこと
1. RAG、全文検索、SQL生成AIの違い
2. 小さく始める場合の構成案
3. セキュリティ上の注意点
4. 今回は採用しない方がよいケース

## 出力形式
- 結論
- 比較表
- 推奨構成
- 採用前に確認すべき質問10個

ポイントは「情報を集めて」ではなく、判断材料に変換して と依頼しているところです。

AIに調査を任せる時、人間が設計するのは検索キーワードではなく、意思決定の形です。

プロンプト例2: 実装を任せる

次に実装です。

ここでは、作業範囲と禁止事項を明確にします。

あなたはこのリポジトリの実装担当です。

## 目的
ユーザー一覧APIに `status` フィルタを追加してください。

## 背景
管理画面で active / suspended / deleted のユーザーを絞り込みたい。
既存の `keyword` フィルタは残します。

## 制約
- DBスキーマは変更しない
- 既存レスポンス形式は変更しない
- `deleted` は管理者だけが指定できる
- 認証まわりの既存設計は壊さない

## 利用できるコマンド
- `npm test`
- `npm run lint`

## 権限境界
- マイグレーション作成は禁止
- 本番環境へのアクセスは禁止
- 秘密情報をログに出さない

## 合否条件
- `status=active` でactiveユーザーのみ返る
- 未指定時は既存挙動と同じ
- 権限のないユーザーが `deleted` を指定した場合は403
- 関連テストが追加されている

まず変更方針を短く説明してから実装してください。

ここまで書くと、AIは「どこまで触っていいのか」をかなり判断しやすくなります。

逆に、ここを書かないと、AIは良かれと思ってDBスキーマを変えたり、レスポンス形式を整理したり、認証処理までリファクタしたりします。

悪気はないんです。

でも、現場では困る。

だから、コンテキストパケットで 良い変更の範囲 を先に決めるわけです。

プロンプト例3: レビューを任せる

AIレビューは便利ですが、ただ「レビューして」だと浅くなりがちです。

レビューにもコンテキストが必要です。

あなたはシニアエンジニアとして、このPRをレビューしてください。

## このPRの目的
CSVインポート時のバリデーションを強化し、エラー行をUIで確認できるようにする。

## 重点レビュー観点
1. 不正CSVでサーバーが落ちないか
2. エラーメッセージがユーザーに理解できるか
3. 大量行のCSVでメモリを使いすぎないか
4. 個人情報をログに出していないか
5. 既存の正常系を壊していないか

## 見なくてよい観点
デザインの細かい余白調整は今回のスコープ外。

## 出力形式
- Blocker
- Should Fix
- Nit
- 追加テスト提案
- リリース前確認

レビューで大事なのは、AIに「何を重大とみなすか」を渡すことです。

同じ差分でも、セキュリティ重視のレビューと、UX重視のレビューと、パフォーマンス重視のレビューでは、見る場所が変わります。

人間のレビューでもそうですよね。

AIレビューも同じです。

コード例1: コンテキストパケットの最低項目を検査する

チームで使うなら、IssueやMarkdownに最低項目が入っているかを機械的にチェックすると便利です。

たとえば、context-packet.md を検査する小さなNode.jsスクリプトです。

// validate-context-packet.js
import fs from "node:fs";

const file = process.argv[2];
if (!file) {
  console.error("Usage: node validate-context-packet.js <markdown-file>");
  process.exit(1);
}

const text = fs.readFileSync(file, "utf8");

const requiredHeadings = [
  "### 1. 目的",
  "### 2. 背景",
  "### 3. 制約",
  "### 4. 利用できるツール",
  "### 5. 権限境界",
  "### 6. 合否条件",
  "### 7. レビュー観点",
];

const missing = requiredHeadings.filter((heading) => !text.includes(heading));

if (missing.length > 0) {
  console.error("Missing context packet headings:");
  for (const heading of missing) {
    console.error(`- ${heading}`);
  }
  process.exit(1);
}

console.log("Context packet looks good.");

使い方はこうです。

node validate-context-packet.js context-packet.md

これだけでも、チームのAI依頼がかなり揃います。

もちろん、見出しがあるだけで中身が良いとは限りません。でも、最低限の型がない依頼を減らすだけでも効果はあります。

人間のレビュー前に、AIへ渡す文脈のレビューをする。

この発想、けっこう大事です。

コード例2: 秘密情報と文字化けっぽい断片を検査する

AIに渡す文脈には、秘密情報や個人情報を入れないのが基本です。

もうひとつ地味に大事なのが、文字化けチェックです。特に自動投稿やブラウザ貼り付けを絡める場合、日本語が壊れていると信用が一瞬で落ちます。

これは簡易チェック例です。

// safety-check-markdown.js
import fs from "node:fs";

const file = process.argv[2];
if (!file) {
  console.error("Usage: node safety-check-markdown.js <markdown-file>");
  process.exit(1);
}

const text = fs.readFileSync(file, "utf8");

const privateKeyMarker = ["-----BEGIN", "PRIVATE KEY-----"].join(" ");
const mojibakeMarkers = [0x00e3, 0x00ef, 0x00e2, 0x00e6, 0x00e7]
  .map((codePoint) => String.fromCharCode(codePoint))
  .join("|");

const suspiciousPatterns = [
  /api[_-]?key\s*[:=]/i,
  /secret\s*[:=]/i,
  /password\s*[:=]/i,
  /token\s*[:=]/i,
  new RegExp(privateKeyMarker),
  new RegExp(mojibakeMarkers),
];

const found = suspiciousPatterns.filter((pattern) => pattern.test(text));

if (found.length > 0) {
  console.error("Potential safety issue found. Please review before sharing.");
  process.exit(1);
}

console.log("No obvious secret or mojibake pattern found.");

使い方です。

node safety-check-markdown.js context-packet.md

これは完璧なセキュリティツールではありません。

でも、何もないよりはかなりいいです。

AI活用は「速くする」方向に意識が寄りがちですが、実務では 速くする前に、漏らさない、壊さない、公開しない が必要です。

特にMCPやブラウザ操作で外部ツールとつなぐ場合、AIが触れる範囲は広がります。だからこそ、コンテキストパケットには権限境界を入れておく。

任せる前に、閉じ込める。

この順番が大事かなと。

MCPやブラウザ自動化を使う時の権限境界

AIエージェントがローカルファイル、GitHub、Slack、Jira、Notion、ブラウザ、DBに触れるようになると、便利さは一気に上がります。

ただ、便利さと危険さはだいたい同じ方向に伸びます。

なので、権限境界を表にしておくと良いです。

操作	AIだけでOK	人間承認が必要	禁止
ローカルの関連ファイルを読む	○
テストを実行する	○
新しいブランチに小さな修正を作る	○
PR本文の草案を書く	○
本番DBを見る		○
外部サービスへ投稿する		○
課金設定を変更する		○
秘密情報を表示・送信する			○
本番データを削除する			○

この表は、会社やプロダクトによって変えてください。

大事なのは、AIに「常識で判断して」と言わないことです。

常識は人によって違います。AIにとっても曖昧です。

だから、先に表にする。

これが、チームでAIを使う時の最低限のガードレールになります。

運用ログまで含めると、AI活用は強くなる

コンテキストパケットは、1回の依頼で終わりではありません。

作業後に、運用ログとして残すと強くなります。

## AI Work Log

### 依頼内容
ユーザー一覧APIにstatusフィルタを追加。

### AIに渡したContext Packet
リンクまたは本文。

### 実行したこと
- 関連ファイル調査
- 実装
- テスト追加
- lint/test実行

### 人間が判断したこと
- deleted指定は管理者だけ許可
- 既存レスポンス形式は変更しない

### 検証結果
- npm test: pass
- npm run lint: pass

### 次回改善
- 権限まわりの共通テストヘルパーを作る

このログがあると、次のAI依頼が楽になります。

なぜなら、過去の判断を毎回説明しなくてよくなるからです。

Memoryに入れるにしても、ドキュメントに残すにしても、重要なのは「判断の理由」を残すことです。

コードは見ればわかることもあります。

でも、なぜその設計にしたのか、なぜ今回はやらなかったのか、どのリスクを許容したのかは、コードだけでは分かりにくい。

AIに引き継ぐべきなのは、コードそのものだけではなく、判断の履歴 なんです。

最初の一歩は、Issueテンプレに入れるだけでいい

ここまで読むと、ちゃんと運用しなきゃと思って少し重く感じるかもしれません。

でも、最初はIssueテンプレにこれを入れるだけで十分です。

## Context Packet

### 目的

### 背景

### 制約

### 利用できるツール

### 権限境界

### 合否条件

### レビュー観点

全部を毎回埋められなくてもいいです。

空欄が見えるだけで、「あ、ここ曖昧やな」と気づけます。

この気づきが大きい。

AIに渡す前に、人間側の曖昧さが見えるからです。

AI活用がうまい人は、魔法のプロンプトを知っている人ではない気がします。

むしろ、AIに渡す前に、

• 目的を言語化する
• 制約を見つける
• 禁止事項を決める
• 合否条件を書く
• 最後に人間が判断する場所を残す

この地味な作業をできる人です。

地味なんですけど、効きます。

まとめ

AI開発の主戦場は、少しずつ変わってきています。

コードを書く速さだけではなく、AIが安全に、正確に、チームの意図に沿って動けるようにする力が重要になっています。

そのための小さな型が、この記事で紹介したコンテキストパケットです。

もう一度、7項目を置いておきます。

1. 目的
2. 背景
3. 制約
4. 利用できるツール
5. 権限境界
6. 合否条件
7. レビュー観点

AIに何を任せるかを考える前に、AIに何を渡すかを考える。

AIにどこまでやらせるかを考える前に、AIに何をやらせないかを決める。

この順番を守るだけで、AI開発はかなり現実的になります。

人間の仕事は、なくなるというより、少し上流に移ります。

実装だけを抱える人から、文脈を設計し、判断し、評価する人へ。

なんかこれって、AI時代のエンジニアにとって、かなり大事な変化なんじゃないかなと思います。

明日の自分やチームが「あの時ちゃんと書いてくれて助かった」と思えるContext Packetを、まず1つだけIssueに貼ってみる。

それくらいの小さな一歩からで十分です。

参考

• Codex for (almost) everything | OpenAI
• Starting GitHub Copilot sessions | GitHub Docs
• GitHub Copilot CLI is now generally available | GitHub Blog
• What is the Model Context Protocol?
• How we contain Claude across products | Anthropic