「型破り」ではなく「形無し」な私が Claude Code で型を形成する
ウィスキー、シガー、パイプをこよなく愛する大栗です。
十八代目 中村勘三郎さんの「型があるから型破り、型がなければ形無し」という言葉があります。私はテクニカルアカウントアドバイザーとして複数のお客様にクラウドの技術支援を行っていますが、開発業務ではなく、技術調査や資料作成が中心の業務です。そのため、以前は生成 AI の活用といえばチャットベースで相談する程度でした。
3ヶ月ほど前から Claude Code を使い始め、調査や資料作成など様々な業務で活用するようになりました。しかし、使い込むほどに見えてきたのは、自分自身が「型破り」どころか「形無し」だったという事実です。
本記事では、Claude Code に組み込んだ「振り返りの仕組み」と「パターン蓄積の仕組み」によって、どのように「形無し」から「型がある」状態へ変化していったかをご紹介します。
「型破り」と「形無し」
「型破り」と「形無し」は似ているようで全く違います。「型破り」は型を十分に身につけた上で、あえてそこから外れること。一方「形無し」は、そもそも型がない状態です。
私の業務は、定例会の資料作成、技術調査、提案書の作成、ブログ執筆など多岐にわたります。問題は、振り返りが苦手だということです。検査をしたことはありませんが、脳に何らかの特性があるのかもしれないと感じています。うまくいった手順を見つけても、次に同じ作業をするときには忘れている。毎回同じようなことを一から考え直している。経験が「型」として定着しませんでした。
そして「型」がないまま生成 AI を使っても、生産性は思うように上がりませんでした。たとえばスライドを生成しても、作成された資料の細かいところが気になって延々と修正指示を出してしまう。何を良しとするかの基準、つまり「型」がないから、どこで手を止めればいいか分からないのです。
多岐にわたる業務だからこそ「型」が必要でした。そして、自分の特性を考えると、頭の中に「型」を保持するのではなく、外部に書き出して仕組みで回す必要がありました。
Claude Code に「形無し」を相談してみた
悩んだ末に、Claude Code 自身に相談してみました。「行き当たりばったりで仕事の『型』を持っていないので、生成 AI を使っても生産性が上がらない」と率直に伝えました。
対話を重ねていくと、いくつかのアイデアが出てきました。暗黙知を形式知にすること、今やっていることを一歩一歩形にしていくこと。方向性としては納得できるものでしたが、問題はそこではありません。**それを自分でできないから困っています。**振り返って言語化する、整理して書き出す、それが苦手だから「形無し」なのです。
そこで「自分では型にできないから、自動でやれないか？」と聞いてみました。すると Claude Code は、CLAUDE.md に振り返りルールを組み込み、作業のたびに自動でパターンを抽出・蓄積する仕組みを提案してきました。
たとえば、それまでの私の業務はこんな状態でした。
- メモ用ドキュメントとプレゼン用スライドが食い違う。 片方だけ更新してもう片方を忘れ、定例会の直前に慌てて修正していた
- 新しいお客様を担当するとき、Claude Code に何を伝えれば良いか分からない。 毎回同じ背景説明をする羽目になっていた
経験を蓄積する仕組みがなかったということです。うまくいった手順もつまずいた箇所も、その時に頭の中にあるだけですぐに揮発していきました。Claude Code が提案した仕組みは、まさにこの問題を解決するものでした。
Claude Code で「型」を形成する仕組み
この「形無し」状態を解決するために、CLAUDE.md に以下の「振り返りルール」を追加しました。
# 作業後の振り返りルール
タスクが一区切りついたら、必ず以下を行うこと：
1. 今回の作業を振り返り、うまくいった進め方・手順をパターンとして言語化する
2. .claude/patterns.md に追記する（重複があれば統合・更新する）
3. 追記した内容を私に簡潔に報告する
## パターン抽出の観点
- 作業の手順（どういう順番で進めたら上手くいったか）
- 判断基準（何を根拠にどう判断したか）
- つまずきと解決策（何でハマって、どう解決したか）
- 品質チェックの観点（何を確認すべきだったか）
仕組みはシンプルです。作業が終わるたびに Claude Code が自動的に振り返りを行い、うまくいったやり方を .claude/patterns.md にパターンとして記録します。次に同じような作業をするときには、CLAUDE.md にある「作業前のルール」によって patterns.md を参照してから作業に入ります。
# 作業前のルール
タスク開始時に .claude/patterns.md を確認し、
今回の作業に関連するパターンがあれば、それに沿って進めること。
該当するパターンがなければ、自分なりの手順で進めてよい。
つまり「使う → 作業する → 振り返る → パターンを蓄積する → 次に使う」というサイクルが自動で行われる設計です。重要なのは、パターンの抽出を4つの観点（手順、判断基準、つまずきと解決策、品質チェック）に分解していることです。「うまくいった」だけでなく「何でハマったか」も記録することで、同じ問題を繰り返さなくなります。
蓄積された「型」の実例
この仕組みを運用して、いくつかのパターンが蓄積されました。以下はその一部です。
| パターン名 | 概要 |
|---|---|
| Word 文書の生成パイプライン | 構造変換と書式調整の2段階で生成 |
| メモ用ドキュメントとプレゼン用スライドの同時管理 | 両方を同時に更新するルール |
| ドキュメント修正の進め方 | 誤読防止のための記述パターン |
| タスク一覧の整理 | 作業と質問を分離する構成 |
| 手順書間の未確定事項の集約 | 未確定項目を設計要件に逆流させる |
| Claude Code へのコンテキスト情報の拡充 | 業務全体像をコンテキストとして追加 |
| 調査ドキュメントへの手順追記 | 調査→戦略→具体手順の3層構造 |
| マルチアカウント環境の一括調査 | 共通モジュール + コントロール別スクリプト |
これらは意図的に設計したものではなく、日々の作業の振り返りから自然に蓄積されたものです。この中から、代表的な2つのパターンを詳しく紹介します。
パターン例 1: メモ用ドキュメントとプレゼン用スライドの同時管理
先ほどの「形無し」エピソードで挙げた、ドキュメントとスライドの食い違いについてです。この問題は以下のパターンとして蓄積しました。
## ドキュメント + スライドの同時管理
### パターン: 1つの内容をメモ用ドキュメントとプレゼン用スライドで並行管理
内容の変更時は**両方のファイルを同時に更新**する。
片方だけ更新すると不整合が生じる。
手順:
1. メモ用ドキュメントを修正
2. プレゼン用スライドを同じ内容で修正
3. スライドを再生成
4. 必要に応じて配布用ドキュメントも再生成
### 判断基準: スライドの情報量
- スライドにはドキュメントの全文を載せない
- 表は列を減らし、要点のみ残す
- 補足情報は別スライドに分離するか、簡潔に
このパターンのポイントは、手順だけでなく「判断基準」が含まれていることです。スライドにどこまで載せるかは毎回迷うところですが、「全文を載せない」「表は列を減らす」といった基準が明文化されているため、迷わず判断できるようになりました。以前は片方だけ更新して不整合を起こしていましたが、「両方同時に更新する」という手順がパターンとして定着したことで、この問題はほぼ起きなくなっています。
パターン例 2: CLAUDE.md のコンテキスト拡充
もう1つは、「型が型自身を改善する」というメタ的な例です。
## CLAUDE.md のコンテキスト拡充
### パターン: 既存構造を維持しつつコンテキスト情報を前方に追加
お客様の CLAUDE.md がワークフロー特化（スライド作成手順等）になっている場合、
業務の全体像が Claude Code に伝わらない。
手順:
1. Plan Mode で定例資料・提案書・分析レポートなど既存成果物を横断的に調査し、
事実情報を収集
2. 冒頭にコンテキスト情報（概要、キーパーソン、利用サービス、進行中プロジェクト）
を追加
3. 既存のワークフロー・スタイルガイドは後半にそのまま維持
4. フォルダ構成は実態に合わせて軽微に更新
### 判断基準: 何を載せるか
- **載せる**: お客様の環境概要、進行中プロジェクトの現状、キーパーソン、
利用サービス、EOS期限
- **載せない**: 個別アカウントID一覧（量が多く CLAUDE.md が肥大化する）、
一時的な調査メモ
- コンテキスト情報は定期的に（定例会の度に）見直して更新する
冒頭の「形無し」の話で、CLAUDE.md に何を書けば良いか分からなかったと述べました。このパターンはその問題を解決したものです。あるお客様の CLAUDE.md を拡充する作業を通じて「何を載せて何を載せないか」の判断基準が明確になり、パターンとして蓄積されました。それ以降、新しいお客様を担当する際にこのパターンに沿って CLAUDE.md を構成できるようになっています。
CLAUDE.md の書き方を改善するパターンが、CLAUDE.md の仕組みの中で蓄積されている、という再帰的な構造のルールになっています。
「型」を支える全体像
パターン蓄積の仕組みは、Claude Code の作業環境全体の一部として機能しています。以下の DevelopersIO の記事を参考に、GTD や Zettelkasten のワークフローを自分の業務に合わせて構築しました。正直まだまだ活用できていません。
プロジェクト全体のディレクトリ構成は以下の通りです。
All_Management/ # プロジェクトルート
├── CLAUDE.md # Claude Code への指示と振り返りルール
├── .claude/
│ ├── patterns.md # 作業パターンの蓄積（本記事の主題）
│ ├── commands/ # 各種カスタムコマンド群
│ └── skills/ # GTD・Zettelkasten 等の業務スキル
├── customers/ # お客様別のワークスペース
│ └── <customer>/ # 各々のお客様
│ └── <projects>/ # 関連している案件
├── gtd/ # GTD（タスク管理）
│ ├── inbox/ # 未処理アイテム
│ ├── next-actions/ # 実行可能タスク
│ ├── projects/ # 複数タスクのプロジェクト
│ ├── waiting/ # 対応待ち
│ └── someday/ # いつかやる
├── zettelkasten/ # Zettelkasten（知識管理）
│ ├── permanent/ # 永続ノート
│ ├── literature/ # 文献ノート
│ └── fleeting/ # 一時メモ
├── blog/ # 技術ブログの原稿
└── internal/ # 社内業務など
│ └── <projects>/ # 関連している案件
patterns.md は .claude/ の中にありますが、CLAUDE.md の中でタスク開始時に patterns.md を確認すると指示を書いているのでプロジェクト全体で効果があります。お客様向けの資料作成（customers/）で得たパターンがブログ執筆（blog/）でも活用されたり、GTD の運用（gtd/）で気づいた整理のコツが調査ドキュメントに反映されたりと、ワークフローを横断してパターンが蓄積・再利用されます。
「形無し」から「型がある」状態への変化
振り返りルールを導入してから、いくつかの変化がありました。
同じ作業で迷わなくなりました。 メモ用ドキュメントを修正したら、プレゼン用スライドも同時に更新する。スライドには全文を載せず、表は列を減らして要点のみ残す。以前は「前回どうやったっけ」と思い出すところから始まっていた作業が、パターンに沿ってスムーズに進むようになりました。
つまずきの再発が減りました。 新しいお客様を担当するとき、以前は何を Claude Code に伝えればいいかわからず手探りでした。今は「コンテキスト拡充」のパターンに沿って、環境概要・キーパーソン・利用サービスといった情報を最初から整理して伝えられます。「何を載せて何を載せないか」の判断基準がパターンとして残っているため、迷う時間が大幅に減りました。
Claude Code の文脈理解が深まりました。 Claude Code は作業開始時にパターンを確認してから取り掛かります。「このお客様にはコンテキスト情報を追加するパターンを適用しましょう」のように、蓄積されたパターンを能動的に使ってくれるようになりました。
ただし、正直に言えば、まだ「型破り」には至っていません。蓄積されたパターンを忠実に適用している段階です。パターンの限界を見極めて、あえて違うアプローチを取るような判断はこれからの課題です。まずは「型がある」状態を安定させることが先だと思っています。
さいごに
中村勘三郎さんの言葉に立ち返ると、私がやったことは「型を作る仕組みを作った」ということになります。CLAUDE.md に振り返りルールを追加しただけですが、それによって日々の作業から自動的にパターンが抽出・蓄積される仕組みが動き始めました。
もし Claude Code を使っていて毎回同じ指示を繰り返していると感じたら、まずは CLAUDE.md に振り返りルールを加えてみてください。最初は小さなパターンかもしれませんが、作業を重ねるうちに自分だけの「型」が形成されていくのではないでしょうか。
