「AI にコードを書かせる」。Claude Code の紹介でまず語られるのはこの能力です。自律的にファイルを読み、テストを書き、ビルドを通す。しかし1ヶ月使い続けて気づいたのは、コード生成は Claude Code の本質ではないということでした。
本質はコンテキストの自律操作にあります。
コードを1行も書かなかったセッション
先日、下書きのまま放置していた記事を公開しました。やったことはこれだけです。
- auto memory から「origin 記事が draft のまま」という状態を検出
-
schedule.jsonからクロスポスト先の URL 体系を把握 - 他のショート記事を読んでトーン・構成を揃える
- 記事を修正して lint を通す
- Qiita に投稿、英訳を生成、Dev.to と Hashnode にクロスポスト
-
schedule.jsonを更新してコミット・プッシュ
書いたコードは0行です。既存の publish.py を呼び、既存の lint 設定でチェックし、既存の schedule.json フォーマットに従って更新した。Claude Code がやったのは、散らばったコンテキストを読み取り、正しい順序で正しいツールを呼ぶことでした。
コード生成 AI とコンテキスト操作 AI の違い
この気づきは、冒頭のクロスポストセッションで確信に変わりました。最初は「コードを速く書いてくれるツール」として使っていた。しかし使い込むほど、Claude Code が本当に時間を使っているのはコードを書く行為ではなく、何をすべきかを判断する過程だと分かってきたのです。
コード生成 AI は「入力→出力」の変換器です。「ソート関数を書いて」と言えばソート関数が出てくる。入力はプロンプト、出力はコードです。
コンテキスト操作 AI は違います。「続きからやりたい」という曖昧な指示から、以下を自律的に行います。
- 何が「続き」なのかを特定する — memory、設定ファイル、Git 履歴から現在地を復元する
- 何が必要かを判断する — 既存ツール、テンプレート、スタイルガイドを参照する
- 必要に応じてリサーチする — ファイルを読み、パターンを照合し、不足情報を補う
- 正しい手順を組み立てる — 依存関係を考慮して実行順序を決める
つまり、コンテキストへのアクセス・解釈・判断の連鎖です。コードを書くのはその結果のごく一部に過ぎない。
5層のコンテキストが支える自律性
この自律操作を可能にしているのは、蓄積されたコンテキスト層です。
Layer 1: ~/.claude/rules/ ← グローバルルール（21ファイル）
Layer 2: ~/.claude/skills/ ← グローバルスキル（33個）
Layer 3: ~/.claude/agents/ ← 専門エージェント（14個）
Layer 4: MyAI_Lab/CLAUDE.md ← ワークスペース設定
Layer 5: {project}/ ← プロジェクト固有
├── CLAUDE.md ← プロジェクト設定
├── .claude/skills/ ← プロジェクトスキル
├── .claude/agents/ ← プロジェクトエージェント
└── auto memory ← セッション間記憶
セッション開始時に Layer 1〜5 が自動ロードされ、Claude Code は「このプロジェクトでは何をどうすべきか」を初手から把握します。
ポイントは各層の役割が異なることです。
| 層 | 何を提供するか | 実際に効いた場面 |
|---|---|---|
| rules | 判断基準・制約 | コミット前に毎回「セキュリティチェックして」と言わなくなった |
| skills | 手順・ノウハウ | クロスポストの手順を毎回教える必要がなくなった |
| agents | 専門的な視点 | 辛口エディターが記事の AI スロップを検出してくれた |
| CLAUDE.md | プロジェクト固有の文脈 | Tech Stack を聞かれずにビルドが通った |
| auto memory | セッション間の継続性 |
:::message の textlint 誤検出を2回目以降は即回避できた |
コード生成に必要なのは skills だけです。しかし正しい判断には rules、agents、CLAUDE.md、memory のすべてが要る。
「覚えている」ことの価値
従来の AI アシスタントでは、毎回セッションがリセットされます。
セッション1: 「Zenn の textlint で :::message が誤検出される」→ 回避策を発見
セッション2: 同じ問題に再遭遇 → また調査からやり直し
auto memory があると、こうなります。
セッション1: 回避策を発見 → memory に記録
セッション2: memory から回避策を読み取り → 即座に適用
これは単なる「便利さ」ではありません。作業の再現性と一貫性に関わります。ゴッチャの回避、命名規則の統一、ツールの使い方 — セッションをまたいでも同じ品質を保てるかどうかは、memory の有無で決まる。
memory はセッション間の記憶でした。では、プロジェクトの壁はどうか。
プロジェクトを越えるコンテキスト転送
コンテキストはプロジェクトの壁も越えます。別プロジェクトで作業中に得たインサイトを、その場で記事の下書きに変換するという使い方です。
先日、AI リサーチパイプラインのデバッグで2日間格闘しました。Mem0 MCP のハング、gtimeout と claude -p の TTY 競合、自動アップデートによる symlink 消失 — 原因が次々と変わる障害対応です。
バグの回収がひと段落するたびに、こう指示しました。
ユーザー: 今の障害対応の経緯をコンテキストごと集めて、
zenn-content に下書きで入れて。
Claude Code は daily-research プロジェクトのセッション内でコンテキストを収集しました。エラーログ、試した仮説、リバートした diff、修正の判断理由。それを Zenn のフロントマター付きで zenn-content/articles/ に published: false で保存しました。
これを3ラウンド繰り返した結果、下書きには以下が残っていました。
- Mem0 MCP が対話セッションでは動くのに
claude -pではハングした事実とその切り分け過程 - Claude Code が「直近の自分の修正に原因がある」と思い込んだ認知バイアスの具体例
- 人間が「前日のログはノイズ、今日の成功ログだけ見ろ」と焦点を絞った3つの介入
後日、この素材をベースにポストモーテム記事を書きました。
「あのエラーメッセージ何だっけ」と思い出す作業は一切なかった。エラーの正確な文面も、試行錯誤の順序も、却下した仮説の理由も、すべてコンテキストとして残っていたからです。実装中にしか存在しないコンテキストがあります。数時間後には文脈が薄れ、翌日には「なぜその判断をしたか」が再現できない。この鮮度を構造化された状態で保存できることが、コンテキスト操作の実用的な価値です。
コンテキストが育つとセッションが短くなる
逆説的ですが、コンテキストを充実させるほど、1セッションあたりの作業時間は短くなります。
初期のセッション（コンテキストなし）の例です。
ユーザー: 記事を Qiita にクロスポストして
Claude: Qiita の API 仕様を調べます... トークンはどこにありますか？
フロントマターの変換ロジックを書きます...
→ 30分以上
現在のセッション（コンテキストあり）の例です。
ユーザー: y
Claude: publish.py → Qiita → 英訳 → Dev.to → Hashnode → schedule.json 更新
→ 2分
コンテキストが「毎回説明するコスト」を吸収しているのです。rules にコーディング規約を書けば毎回指示しなくていい。skills に手順を書けば毎回教えなくていい。memory にゴッチャを記録すれば毎回踏まなくていい。
コンテキスト整備は「プロンプトエンジニアリング」ではない
「それはプロンプトを工夫しているだけでは？」という反論があり得ます。
違います。プロンプトエンジニアリングは1回の入出力を最適化する技術です。コンテキスト整備はセッション横断の知識基盤を構築する行為です。
| プロンプトエンジニアリング | コンテキスト整備 | |
|---|---|---|
| スコープ | 1回のリクエスト | 全セッション |
| 保存場所 | プロンプト内 | ファイルシステム |
| 蓄積 | しない | する（memory, learned skills） |
| 自動化 | 手動 | 一部自動（continuous-learning） |
continuous-learning スキルはセッション中に発見したパターンを自動抽出し、learned/ に保存します。次のセッションではそれが skills として読み込まれる。コンテキストが自己増殖するフィードバックループです。
実践的な始め方
コンテキスト層を一度に全部作る必要はありません。効果の高い順に積み上げます。
1. CLAUDE.md を書く（5分）
プロジェクトの Tech Stack、ビルドコマンド、主要な規約を書くだけで、毎セッションの説明コストが消えます。
2. auto memory を意識する（0分）
プロジェクトディレクトリ内で Claude Code を起動する。それだけで memory がプロジェクトに紐づきます。ワークスペースルートで起動すると memory が分散するので注意（詳細はこちら）。
3. 繰り返す手順を skills にする（15分/個）
3回以上繰り返した手順は .claude/skills/ に SKILL.md として書く。Claude Code が自動で参照します。
4. 判断基準を rules にする（10分/個）
「テストは必ず書く」「コミット前にセキュリティチェック」など、毎回言い直している指示は ~/.claude/rules/ に移す。
まとめ
1ヶ月間の試行錯誤を振り返ると、自分がやっていたのは「プロンプトを上手く書く」ことではなく、Claude Code が自律的に判断できる知識基盤を積み上げることでした。
- rules に判断基準を書いたら、毎回の指示が消えた
- skills に手順を書いたら、クロスポストが
y一文字で完了した - memory にゴッチャを記録したら、同じ罠を二度踏まなくなった
- 別プロジェクトのデバッグ中に下書きを指示したら、鮮度の高い素材が記事になった
コンテキスト層が厚くなるほど、1セッションでやれることが増え、説明のコストが減り、品質が安定する。この蓄積はプロンプトの工夫とは質が違います。セッションが終わっても消えない、プロジェクトを越えても使える、時間が経つほど効いてくる。
「AI にコードを書かせる」から「AI が自分のコンテキストを読み、判断し、動く」へ。この視点が変わったとき、Claude Code の使い方が根本から変わりました。