AIとペアプロする実践パターン：コンテキスト設計と引き継ぎの技術

TL;DR

• AIペアプロで生産性が落ちる根本原因は「コンテキスト設計の不在」にある
• セッション引き継ぎはAGENTS.md/CLAUDE.mdによる構造化が最も効果的
• 「AIに任せる部分」と「人間がレビューする部分」の線引きを事前に決めておく
• 本記事の3パターン（コンテキスト階層化・引き継ぎドキュメント・介入判断フレームワーク）は翌日から適用可能

本記事はシリーズ「AI駆動開発のプロジェクト計画術」の第2回です。計画フェーズの活用方法は親記事をご覧ください。

はじめに：「AIと作業している」から「AIとペアプロしている」へ

Claude CodeやGitHub Copilotが普及した今、多くのエンジニアが「AIと一緒にコードを書く」状態になっています。しかし「AIと作業している」と「AIとペアプロしている」の間には大きな差があります。

前者は指示を出して結果を受け取るだけのループ。後者はお互いの役割と文脈を共有しながら、継続的な協働ができている状態です。

この差を生み出すのが「コンテキスト設計」です。

よくある失敗パターンを見てみましょう。

• セッションを新しく始めるたびに「このプロジェクトは…」から説明し直す
• 会話が長くなると、AIが「最初の前提」を忘れて矛盾した提案をしてくる
• 「どこまで任せていいか分からない」で結局手書きが多い
• コードは生成できるが、アーキテクチャの意図が伝わらない

これらはすべて、コンテキスト設計が体系化されていないことで起きます。本記事では3つの実践パターンを通じて、この問題を解消する方法を整理します。

コンテキストとは何か：AIとの協働における定義

まずAIペアプロにおける「コンテキスト」を定義しておきます。

コンテキストとは、AIが適切な判断・提案をするために必要な全情報のことです。大きく3層に分かれます。

Claude Codeのコンテキストウィンドウは有限です（経験則：長いセッションでは初期の指示が「薄まる」現象が起きます）。そのため、どの情報をどの層に置くかを意識的に設計する必要があります。

パターン1：コンテキスト階層化パターン

適用場面: 長期・大規模プロジェクトでの継続的AI協働 効果: セッションをまたいでも一貫した提案を受け取れる

問題

AIへの指示が毎回アドホックだと、プロジェクトのコンテキストが引き継がれません。「いつも同じ前提から説明し直す」状態は生産性の大きなロスです。

解決策：3層コンテキスト構造

プロジェクトルート/
├── AGENTS.md          # プロジェクト層（全AIエージェントへの恒久的指示）
├── CLAUDE.md          # プロジェクト層（Claude固有の設定・差分）
├── .claude/
│   └── MEMORY.md      # セッション層（長期記憶・学習済み事項）
└── docs/
    └── working/
        └── TASK-xxx/
            └── `TODO.md`  # タスク層（現在のタスク固有の文脈）

AGENTS.mdに書くべき内容

# Project: [プロジェクト名]

## 技術スタック
- Runtime: Node.js 22 / TypeScript 5.x
- Framework: Next.js 15 (App Router)
- Package Manager: pnpm（npmは使わない）

## アーキテクチャ原則
- コンポーネントはSRPを徹底（1コンポーネント1責務）
- Serverコンポーネントを優先、Clientは状態管理が必要な場合のみ
- ファイル名はkebab-case

## コーディング規約
- 型安全を最優先。anyは原則禁止
- エラーはResult型またはthrowで統一

## セキュリティ制約
- .env / secrets/ には触れない
- 外部APIへの接触はモックを先に作る

このファイルをリポジトリのルートに置くと、Claude Codeは自動的に読み込んで参照します（公式値）。「毎回説明する」から「一度定義して使い回す」に変わります。

パターンの効果

AGENTS.mdを整備する前後でセッション開始時の指示量が体感で70〜80%削減されます（経験則）。重要なのは「AIへの恒久的指示」と「タスク固有の指示」を混ぜないことです。

パターン2：セッション引き継ぎドキュメントパターン

適用場面: 複数セッションにまたがる実装・長時間のデバッグ 効果: 「AIへの説明し直し」をゼロにする

問題

Claude Codeのセッションは有限です。長い作業を途中で切って再開するとき、「どこまでやったか」「なぜその実装を選んだか」の経緯が失われます。

解決策：構造化された引き継ぎドキュメント

タスクディレクトリ（docs/working/TASK-xxx/）に以下の形式でTODO.mdを作成します。

# タスク: [機能名] 引き継ぎドキュメント

## 完了条件
- [ ] ○○APIがレスポンス200を返す
- [ ] エラー時はErrorBoundaryで捕捉される
- [ ] e2eテストがgreen

## 現在の状態（セッション終了時に更新）
- 実装済み: UserAuthService.ts のgetUser()メソッド
- 作業中: セッショントークンのリフレッシュロジック
- 未着手: ログアウト処理

## 設計決定ログ
- JWTの有効期限: 15分（要件書参照、短めに設定）
- リフレッシュトークン: HttpOnly cookieに格納（XSS対策）

## 試したが却下した実装
- ローカルストレージでのトークン管理 → XSSリスクで却下

## 次のセッション開始時の指示テンプレート
このドキュメントを読んで現在の状態を把握してください。
続きは「○○の実装」から始めます。
前提: [重要な制約をここに書く]

引き継ぎを効果的にする3つのポイント

1. 「なぜ」を必ず残す: 「何をしたか」だけでなく「なぜその選択をしたか」を書く。AIはコードは読めても意図は推測できない
2. 却下した選択肢を書く: AIは「未試行のアプローチ」を再提案してくることがある。却下理由を明示することで同じ議論を繰り返さない
3. セッション末に更新する: 引き継ぎドキュメントはセッション終了時に必ず更新する。作業中は忘れても、終わる前に「このセッションでやったことをTODO.mdに反映して」とAIに指示するだけでよい

詳しいセッション記憶の設計についてはClaude Codeセッション記憶のデザインパターンでさらに詳しく解説しています。

パターン3：人間介入判断フレームワークパターン

適用場面: AIに作業を委譲する前の判断、レビュー設計 効果: 「どこまで任せるか」の迷いを解消する

問題

「AIに任せすぎてコードが複雑になった」「逆に細かく指示しすぎて自分でやるのと変わらない」という両極端が起きがちです。

解決策：DAIR（Delegate / Assist / Inspect / Reject）フレームワーク

D - Delegate（完全委譲）: AIに全体を任せる
A - Assist（補助）: AIの提案を人間が加工して使う
I - Inspect（検証必須）: AIが生成するが人間が必ずレビュー
R - Reject（人間実装）: AIに任せない

「Inspect」をどう運用するか

Inspectカテゴリの作業では、AIに生成させた後に以下のチェックリストを回します。

## AI生成コードの Inspect チェックリスト
- [ ] 想定した責務の範囲に収まっているか？
- [ ] エラーハンドリングは適切か？
- [ ] セキュリティ上の懸念（injection・認可バイパス）はないか？
- [ ] 既存コードとの命名・スタイルは一致しているか？
- [ ] テストで網羅できているか？

DAIRフレームワークをAGENTS.mdに記載しておくと、AIへの指示が簡潔になります。「これはAに分類した作業です」とだけ伝えれば、どこまで自律してよいかをAIが把握できます。

AIコーディングにおけるセキュリティ設計の詳細はAIコーディング導入のセキュリティ設計も参照してください。

3パターンの組み合わせ方

3つのパターンは独立していますが、組み合わせることで効果が増幅します。

新規プロジェクト開始
  └→ パターン1: AGENTS.mdを作成（プロジェクト層の確立）

作業開始時
  └→ パターン3: この作業はD/A/I/Rのどれか判断

作業中
  └→ パターン2: 決定ログを`TODO.md`に追記

セッション終了時
  └→ パターン2: 「次のセッション」欄を更新してAIに指示

翌日の作業開始
  └→ 「このドキュメントを読んで続きをお願いします」の一言で再開

この流れを定着させると、AIへの「説明コスト」が限りなくゼロに近づきます。

実践例：このサイトのAGENTS.md設計

参考として、本記事を生成したリポジトリのAGENTS.md（抜粋）の設計思想を紹介します。

• Iron Laws: 「CONDUCTORは記事を直接書かない」「ブリーフ承認なしに執筆を開始しない」などの絶対制約を先頭に置く
• 役割定義: Conductor・Writer・Reviewerなど各エージェントの責務を明確化
• 品質ゲート: D-1からD-12まで段階的な品質チェックを定義

このような設計により、複数のAIエージェントが並列で動いても一貫した品質と方針で動作します。詳細はMCPプロトコル実装ガイドで、エージェント間の通信設計についても解説しています。

よくある質問

Q1. AIとのペアプロでコンテキストが長くなってきたらどうすればいい？

コンテキストが長大化したら、それはパターン2の「引き継ぎタイミング」のサインです。「このセッションでの決定事項をTODO.mdにまとめて」とAIに指示し、新しいセッションで TODO.mdを渡して再開します。ダラダラと同一セッションを続けるよりも、区切りよく引き継いだ方が精度が上がります（経験則）。

Q2. AGENTS.mdは何文字くらいが適切ですか？

明確な上限はありませんが、1,000〜2,000字を目安にするのが実用的です（経験則）。重要なのは「毎回説明することになる内容」だけを書くことです。書きすぎると読み込みコストが増え、かえって重要な制約が埋もれます。

Q3. AIが間違った提案をしてきたとき、どう対処すればいい？

まずAGENTS.mdかTODO.mdに「なぜその提案が間違いか」を追記します。次のセッション以降は同じ誤りが繰り返されにくくなります。繰り返す場合は、AGENTS.mdに「禁止事項」セクションを設けて明示的に制約します。

Q4. Claude Codeのメモリ機能とAGENTS.mdはどう使い分ければいい？

Claude Codeのメモリ機能（公式値）はユーザー横断の個人設定向けです。プロジェクト固有の設計・制約はAGENTS.mdに書き、チームで共有します。個人の好みやワークスタイル（「コードブロックを省略しない」など）はメモリ機能に書くという使い分けが効果的です。

Q5. AIペアプロで生産性を上げる最初の一歩は何ですか？

本記事でいえばパターン1のAGENTS.md作成が最初の一歩です。既存プロジェクトでも「技術スタック」「命名規則」「やってはいけないこと」の3項目を書くだけで効果が出ます。パターン2・3はAGENTS.mdが機能してきてから順次追加するのが現実的なロードマップです。

まとめ

AIペアプロで長期的に生産性を上げるには、3つの設計が必要です。

1. コンテキスト階層化パターン: AGENTS.md・CLAUDE.md・TODO.mdの3層で情報を分離し、毎回の説明コストをゼロにする
2. セッション引き継ぎドキュメントパターン: タスクの「なぜ」「状態」「却下した選択肢」を構造化して記録し、シームレスに再開できる
3. DAIRフレームワークパターン: Delegate / Assist / Inspect / Rejectの4分類で「任せる・任せない」の判断を標準化する

まず今日できることは、自分のプロジェクトのAGENTS.mdを作ることです。「技術スタック」「禁止事項」「コーディング規約」の3セクションから始めましょう。

AIペアプロをさらに深掘りしたい場合は、AIツール比較2026年版でClaude Code・GitHub Copilot・Codexの使い分け戦略も参照してください。また、AIの成熟度モデルについてはAIエージェント三層成熟モデルで詳しく解説しています。

本記事はシリーズ「AI駆動開発のプロジェクト計画術」の一部です。

References

• Claude Code 公式ドキュメント（Anthropic公式）
• Claude Code メモリ機能（Anthropic公式）
• Claude コンテキストウィンドウの仕様（Anthropic公式）
• GitHub Copilot ベストプラクティス（GitHub公式）
• OpenAI Codex（OpenAI公式）
• GitHub Copilot 機能概要（GitHub公式）