この記事で分かること
- AIコーディングエージェントを「使う」と「育てる」では何が違うのか
- なぜ同じツールでも成果に大きな差が生まれるのか
- 「育てる」ための具体的な3つの段階と実践方法
- 実際に効果があった文脈設計のパターン
はじめに
「ChatGPTやClaude Codeを使っているのに、なぜか期待どおりの結果が出ない」
こんな経験はありませんか。実は、同じAIコーディングエージェントを使っていても、人によって生産性に大きな差が生まれています。その差は プロンプトの書き方ではなく、AIに渡す「文脈の厚み」 にあります。
たとえ話で説明しましょう。IQが極めて高い天才を新しくチームに迎えたとします。しかしその天才は、あなたのプロジェクトの背景も、コーディング規約も、過去に踏んだ地雷も、何も知りません。そんな状態では、どんなに頭が良くても一般論しか返せないのです。
逆に、プロジェクトのルール・設計思想・過去の失敗を深く理解したパートナーなら、「あうんの呼吸」で期待以上の成果を出せます。
この「文脈の共有」を意図的に設計できているかどうかが、「使う人」と「育てる人」の決定的な違いです。
前提知識
この記事では主にClaude Codeを例に説明しますが、考え方はCursor、GitHub Copilot、Clineなど他のAIコーディングエージェントにも応用できます。
- AIコーディングエージェント: コードの生成・修正・レビューなどを自律的に行うAIツールの総称です
- コンテキスト（文脈）: AIが判断の材料にする情報のことです。会話履歴、プロジェクト設定、コードベースの構造などが含まれます
- CLAUDE.md: Claude Codeにおいて、プロジェクト固有のルールや指示をAIに伝えるための設定ファイルです（CursorではCursorrules、他ツールでも類似の仕組みがあります）
「使う」と「育てる」— 2つのアプローチ
「使う」アプローチ
毎回ゼロからAIに指示を出すスタイルです。
あなた: 「このバグを直して」
AI: （プロジェクトの背景を知らないまま）一般的な修正案を提示
あなた: 「いや、うちではこのパターンは使わないんだけど...」
AI: 「すみません、では別の方法で...」
このやりとり、心当たりはありませんか？ 毎回AIに「うちのルール」を説明し直す時間が積み重なり、生産性の壁になります。
「育てる」アプローチ
AIに渡す文脈を事前に設計・蓄積するスタイルです。
# CLAUDE.md（事前に設定済み）
## コーディング規約
- 関数は30行以内。超える場合は分割理由をコメントに残す
- エラーハンドリングはResult型を使用（例外は使わない）
- テストは必ずArrange-Act-Assertパターンで書く
## 過去の教訓
- 2026-01: Redis接続プールを共有した際にデッドロック発生 → 接続はリクエスト単位で管理
こうしておけば、AIは最初から「このプロジェクトではどう書くべきか」を理解した状態で作業を始められます。
育てるための3段階
「育てる」は一気にやるものではありません。段階的に文脈の厚みを増していくのが現実的です。
段階1: 基礎 — CLAUDE.mdにルールを書く
最初にやるべきことはシンプルです。プロジェクトのルートに設定ファイルを置き、チームの「暗黙知」を明文化します。
# CLAUDE.md
## プロジェクト概要
ECサイトのバックエンドAPI。Go + PostgreSQL構成。
## コーディング規約
- パッケージ名はすべて小文字の単一語
- インターフェースは呼び出し側パッケージで定義
- DBアクセスはリポジトリパターンを使用
## テストルール
- カバレッジ80%以上を維持
- テーブル駆動テスト（table-driven tests）を優先
ポイントは 「新しいメンバーへの引き継ぎ書」を書くイメージで書くことです。「良いコードを書いてね」ではなく「関数は30行以内、超える場合は分割理由をコメントに残す」のように具体的に書きます。
段階2: 発展 — 記憶を構造化する
AIとのセッションは終わると消えてしまいます。しかし「育てる」アプローチでは、重要な判断・学習・教訓をセッション外に保存し、次回以降も活用できるようにします。
ある実践者は、以下の3ファイル分離設計で記憶喪失問題を解決しています。
| ファイル | 作成者 | 役割 |
|---|---|---|
| AGENTS.md | 人間 | 不変のルール・ガイドライン |
| MEMORY.md | AI | セッションをまたいだ経験知 |
| HANDOFF.md | 人間がキュレーション | セッション間の引き継ぎ情報 |
この設計のポイントは、人間が書くべきもの（方針・判断基準）とAIが蓄積すべきもの（経験・パターン）を分離していることです。
段階3: 理想 — AIとの対話で文脈を継続的に更新する
最終段階では、AIとの日常的なやりとりの中で文脈が自動的に更新・精緻化されていきます。
実際にGitリポジトリとClaude Codeで「第二の脳」を構築し、段階的に自律運用へ移行した事例があります。
| フェーズ | やったこと | 人間の関与 |
|---|---|---|
| 第二の脳を作る | Gitリポジトリ + フォルダ設計 + CLAUDE.md | 設計は人間 |
| 運用をコマンド化 | カスタムコマンド × 専門エージェント | コマンドを叩く |
| 判断を委ねる | オーケストレータ + スコアリング + ガードレール | 承認のみ |
最大の学びは、AIの自律性は「全か無か」ではなく、レイヤーごとに段階的に委譲するのが現実的だということです。
よくある落とし穴
落とし穴1: 丸投げしてしまう
AIに設計を丸投げしていたエンジニアが、上司から「自分の軸はあるのか？」と指摘された事例があります。自分で一度も設計をやったことがなければ、AIの出力の良し悪しを判断する基準を持てません。
対策: まず自分で考え、設計してからAIにレビューしてもらう。この順番が判断軸を育てます。
落とし穴2: 文脈を入れすぎる
CLAUDE.mdに何でもかんでも書き込むと、コンテキストウィンドウ（AIが一度に処理できる情報量の上限）を圧迫します。
対策: CLAUDE.mdには最重要ルールのみ書き、詳細は別ファイルに分離してパスで参照する形にしましょう。
# CLAUDE.md（シンプルに保つ）
## 開発標準ルール
詳細は `/docs/coding-standards.md` を参照
## アーキテクチャ
詳細は `/docs/architecture.md` を参照
落とし穴3: 一度作って放置する
「育てる」は継続的なプロセスです。プロジェクトが進むにつれ、新しい判断基準や教訓が生まれます。それを反映しなければ、文脈は古くなり、AIの出力精度が下がります。
対策: コードレビューやバグ修正のたびに「この教訓はCLAUDE.mdに追記すべきか？」と自問する習慣をつけましょう。
まとめ
| 段階 | 取り組み | 投資時間 |
|---|---|---|
| 基礎（まずここから） | CLAUDE.mdにルール・構造を記述 | 30分〜1時間 |
| 発展 | 判断基準・嗜好・過去の経緯を外部記憶として構造化 | 数時間（段階的に） |
| 理想 | AIとの対話を通じて文脈を継続的に更新・精緻化 | 日常の一部として |
AIコーディングエージェントは「使う」だけでも便利です。しかし「育てる」ことで、一般的なツールからあなたのプロジェクト専属のパートナーへと変わります。
まずは今日、プロジェクトのルートにCLAUDE.md（または相当する設定ファイル）を作って、チームの「暗黙知」を3つ書き出すことから始めてみてください。それだけでも、AIの出力が目に見えて変わるはずです。