これを読むとなにが変わる？
Claude Codeを「速いけどなんか違う」と感じている人が、Claude Codeの振る舞いそのものにフィードバックするという発想を持てるようになります。
CLAUDE.md・メモリ・Skillsという仕組みで、Claude Codeの判断力をセッションを跨いで育てていく方法論が手に入ります。
この記事の3行まとめ
- AIは速いが、ビジネスドメインの文脈を持たないまま使うと根拠のない判断をする
- 「出力の質」ではなく「判断プロセスの質」にフィードバックすると変わる
- 学びを永続化する仕組み（CLAUDE.md・メモリ・Skills）を作ると、育てたAIが資産になる
はじめに
こんにちは。テレシーでデータサイエンスエンジニア兼PdMをしている ohyan です。
テレシーで新しいプロダクトを作っています。私はPdMとして情報設計から参画しており、Claude Codeと一緒に仕様を詰めています。作業スコープとしては、用語集から、情報設計、画面プロトタイプ、システム仕様まで。
今回の記事は「AIにコードを書かせる」という話ではありません。もっと泥臭い、「AIを仕事ができる仲間に育てる」話です。
試行錯誤の結果、以下の指示をCLAUDE.mdに書き込んだだけで、Claude Codeの振る舞いが大きく変わりました。
自分がまとめた内容はすべて自分の言葉で説明できる状態にすること。説明できない場合はユーザーに確認し、回答を自分の言葉で整理し直して再確認する。 理解が浅い概念を調査結果のまま転記しない。次の議題に急がず、現在の議題を深く理解してから進む。
この記事では、この指示に至るまでの経緯を紹介します。
- AIに仕様策定を任せたときに直面した問題
- その問題に対する2つのアプローチ
- 学びを永続化する仕組みとその結果
「速いけどなんか違う」の正体は、判断に根拠がないことではないか
Claude Codeを使い始めたとき、多くの人がこう感じるのではないでしょうか。
- 指示すればすぐ動く。でも方向がズレている
- 指摘すればすぐ直す。でも「なぜ直したか」を理解していない
- 聞けばそれっぽく答える。でも深掘りすると薄い
私は、Claude Codeと一緒にサービスの情報設計をする際に、Claude Codeは上流のデータの依存関係を無視したまま、ある機能を間違った階層に置いてしまうことが多かったです。
実際には、Claude Codeにミスを指摘するとすぐ修正してくれましたが、なぜ修正したかの説明もありませんでした。
> 「なぜすぐ受け止めた？自分の設計意図を説明してほしい」
と指摘することもありました。
なので、私はこれらをコンテキスト不足の問題ではなく、判断プロセスの問題だと判断しました。
コンテキストの欠如はすでに多くのエンジニアに議論されているLLMの課題だと思いますが、私は更にその先にある、「根拠なく提案し、根拠なく撤回する」 のほうが問題の本質ではないかと考えました。
そして、出力を直すのではなく、Claude Codeの判断プロセスそのものにフィードバックするという取り組みで、Claude Codeを最強の仲間として育てられるのではないかと考えました。
アプローチ：判断プロセスへのフィードバック
今回は具体的には以下の2つのアプローチで取り組みました。
1. 根拠のある判断をさせる
根拠のある判断をさせるために、3つのことをしました。ドメイン知識を叩き込むこと、根拠のない提案をさせないルールを作ること、自分の言葉で説明させることです。
ドメイン知識を叩き込む
まず大事なのは「必要な業務知識を渡す」ことです。
ある機能の仕様を策定しようとして、Claude Codeは表面的な回答をして次の議題に進もうとしました。「なんですぐ次の議題を進めようとしているの？」と私は止めました。
ドメイン知識が浅いまま先に進むと、後で必ず手戻りが起きます。「まずこの領域をキャッチアップしてきてもらえますか」と何度も差し戻しました。
今回新しく作るプロダクトのビジネス背景、データサイエンスの前提知識、競合他社の公開情報を全部取り込みました。コードベースでは、プロダクトに関連する実装、案件用の分析ノートブック、ライブラリのソースコードを全部読ませました。
これも人間と同じです。新しいメンバーが入ったとき、業務の背景を理解する前に成果物を出させても、的外れなものが出てきます。Claude Codeは圧倒的な情報の読み込み能力を持っているゆえに、コーチングはかなり楽でした。
判断の根拠を明確にして渡す
次に大事なのは「判断の根拠を明確にして渡す」ことです。
プロダクトの設計段階において、本当に価値のあるものを見極めたうえで設計をする必要があります。そしてPdMとして、設計に関する意思決定の説明責任を果たす必要があります。Claude Codeの提案に根拠がなければ、私自身もその設計を説明できません。
ただし、私も最初から解像度高く設計できるわけでもなく、一緒に情報を整理しながら、要件を詰めるように進めました。
なので、Claude Codeを開発パートナーとして「言われたから直しました」ではなく「自分はこう考えたが、指摘の方が正しいので修正します」と言える状態を作りたいです。お互い根拠がある判断は守るようにしたいと考えました。
その都度の指摘は直接書くのではなく、Claude Codeの設定ファイルに書き込んでいきます。判断軸にフィードバックを加えることでに対処療法ではなく、判断軸自体に変更を加える根治になります。これは人間のチームメンバーに対するプロセスとも近いでしょう。都度の判断のフィードバックだけでなく、1on1などで考え方や判断軸自体に影響を与えていくプロセスに近いです。
これは実際に効果がありました。用語選定の議論では、Claude Codeは複数の候補を出しつつ、それぞれのニュアンスの違いを説明するようになりました。
自分の言葉で説明させる
最後に大事なのは「自分の言葉で説明させる」ことです。
誰向けに、何を伝えたいかを明文化しておきたかったので、ルール的なものを先にClaude Codeと作ることにしました。
用語集を作ったとき、技術的な専門用語をそのまま説明文に書いてきました。
このプロダクトのユーザーはその専門用語を知りません。問題はそれだけではなく、Claude Code自身がその用語を自分の言葉で説明できない状態で、調査結果をそのまま転記していました。
「自分がまとめた内容はすべて自分の言葉で説明できる状態にすること。説明できないならユーザーに確認し、確認結果を自分の言葉で整理し直して再確認すること。」これもCLAUDE.mdに書き込みました。以降、機能の概要を書くときには1つずつ「この理解で合っていますか？」と確認してくるようになりました。
2. 失敗の原因を言語化させて、パーソナライズド自律的エージェントを目指す
汎用的なAIはどこにでもあります。でも私が目指していたのは、自分のプロジェクトの文脈を知り、自分の判断基準を理解し、自分の失敗パターンを覚えている、自分専用のエージェントです。
そのために、AIを強化・育てるにはAI自身に振り返ってもらうのが一番効率的だと思っています。AIの持っているコンテキストウィンドウは私が持っているものより長いですし、私より論理的に情報整理ができます。振り返りまでAI自身に任せることで、私がいちいち「ここが悪かった」と指摘しなくても、自ら学ぶサイクルが回り始めます。
具体例を上げましょう。画面のプロトタイプを作成する段階で、Claude Codeがツリー構造のインデントを提案しました。要素が増えたら破綻することを指摘したら、すぐ別の案に切り替えました。
その後は「意思決定に関する振り返りをしてもらえますか？」と聞きました。
Claude Codeは4つの反省点を挙げました。
- 不要な要素を追加したこと
- スケーラビリティを考慮しなかったこと
- セルフレビューが甘かったこと
- 実装前に情報設計を整理しなかったこと
この振り返りをメモリに保存してもらい、次回以降のセッションで参照できるようにしました。こうして失敗パターンが蓄積されていくと、Claude Codeは汎用的なAIから、私のプロジェクト専用のパートナーに変わっていきます。
仕組み：学びの永続化
Claude Codeとのセッションは毎回リセットされるので、前回の学びが消えます。だから学びを永続化する仕組みが必要になりました。
アプローチの中ですでに触れていた部分もありますが、学びの永続化方法を改めてまとめます。
CLAUDE.md — AIが毎回のセッション開始時に読み込む設定ファイル。プロジェクト固有のルールと、振る舞いルールを書いている。「説明できない提案はしない」「自分の言葉で説明できる状態にすること」はここに書いた。
メモリ — セッション横断で蓄積されるフィードバック。「ドキュメントに実装状況を書かない」「用語集に専門用語を使わない」「情報設計のレビュー時は他の画面群と比較する」など、過去の失敗と学びが記録されている。
Skills — カスタムコマンドとして再利用可能なチェックリスト。情報設計のレビュー、セルフレビューなどをコマンド1つで実行できる。
この3つの仕組みは、育てたClaude Codeを「個人の経験」ではなく「チームの資産」にします。チームの他のメンバーがClaude Codeと作業するときの出発点にもなります。
結果：何が変わったか
最初のClaude Codeと比べて有能になりました。プロダクトの設計において深く考えることができるようになったし、自分なりの説明能力を持つようになりました。そしてSkillsによる明文化で再現性も持つようになりました。
用語選定でエンジニアにしか通じない用語を候補として出してきましたが、自ら「エンジニア技術寄りの言葉なので、エンジニアリングに詳しくないエンドユーザーには調整の方が通じる」と判断を変えました。ドメイン知識を叩き込んだ結果、ユーザー像を意識した判断ができるようになっていました。
情報設計のレビューでは、「この中間ノードは配下に1つしかない。冗長ではないか」と自分から指摘するようになりました。設計の弱点を自ら検証する習慣がついていました。
一番大きな変化は、「次に進みましょう」と言わなくなったことです。代わりに「この理解で合っていますか？」と確認してくるようになりました。
おわりに
みんなにも自分のパーソナライズドエージェントを育ててみてもらいたいです。
私からすると、AIをうまく活用できれば、自分の考え方を凝縮して渡せば、時間効率が10倍以上になるのではないかと思います。
速くコードを書けるAIは世の中にたくさんありますが、「なぜその構造にしたのか」を説明でき、間違いを認めて学び、次回に活かせるAIは、育てないと生まれません。
CLAUDE.mdとメモリに書けば行動基準がすぐ変わります。 人間よりフィードバックの反映が速いので、まずはCLAUDE.mdに「説明できない提案はしない」と1行書くところから始めてみてはいかがでしょうか。
