AIに同じことを聞かないための仕組み化

はじめに

私はこれまで、インフラの運用保守、官公庁、コンサル、医療DXと、立場を変えながら10年ほどITの仕事に関わってきました。そうした経験を活かして、現在はJ.B.Goode株式会社で開発に携わり、日々の作業ではClaude Codeも活用しています。

使っていく中で気づいたのが、「同じことを何度も聞いている」ということでした。月曜に「顧客名の列はどこ？」と調べてもらったのに、水曜にまた同じことを聞いている。Claude Codeを使っている方なら、一度は経験があるのではないでしょうか。

Claude Codeは、会話を閉じるとその会話でわかったことを覚えていません。水曜に聞けば、また一から調べ直します。同じ調査に、同じトークンを2回払うことになります。

これを防ぐには、わかったことをmdに残して、次の会話で読ませるのが手軽です。ただし書き方を間違えると、かえって毎回のトークンが増えます。

本記事では、CLAUDE.mdと参照用のmdをどう書き分ければトークンを抑えられるのかをご紹介します。後半では、mdのほかに日々の作業で効果があった工夫もあわせてまとめました。

前提：CLAUDE.md は「固定費」、参照用の md は「従量課金」

• CLAUDE.md（プロジェクトのフォルダ直下）
  → 会話の開始時に 毎回すべて 読み込まれる
• @path で取り込んだファイル（CLAUDE.md の中に @ファイル名 と書くと、そのファイルを取り込める）
  → 取り込み元の CLAUDE.md と一緒に 毎回 読み込まれる
• 参照用の md（docs/data-map.md など、ただのファイル）
  → Claude が必要だと判断して開いたときだけ読み込まれる

CLAUDE.md に書いたものは、関係ない作業の会話でも毎回読まれます。詳しい内容は参照用の md に置き、CLAUDE.md からは場所だけを示すのが基本です。

ここでは、CLAUDE.md をプロジェクトのフォルダ直下に置いた場合の話をしています。CLAUDE.md は置く場所によって効く範囲を変えられます。たとえばホームフォルダ（~/.claude/CLAUDE.md）に置けば自分のすべてのプロジェクトに効き、サブフォルダに置けば、そのフォルダのファイルを触ったときだけ読み込まれます。

例えば下記のような感じです。

良い例：CLAUDE.md には場所だけを書き、中身は参照用の md に置く

CLAUDE.md

## 調べる前に見るもの
- データの中身・計算式・既知の問題 → docs/data-map.md（先に目次を見て、必要な節だけ読む）

docs/data-map.md

## 目次
1. 売上　2. 在庫　3. 得意先　4. 経常利益の計算

## 1. 売上
- sales テーブル。金額は amount 列（税抜き）……

おまけ：2週間使ってみて他にも気づいたこと

md の書き方のほかにも、AI利用で「これは先に知っておきたかった」と思ったことがあります。

1. 答えは表や図で出してもらう

文章で長く返ってくると、読むだけで疲れてしまい、結局「つまりどういうこと？」と聞き直していました。最初から「表にして」「図にして」と頼むと、一目で比べられるので、聞き直しが減りました。

たとえば Git を使い始めたころ、「main はどこにあるのか」がずっとあいまいでした。図にしてもらうと、GitHub 上の main と自分の PC の main が別々にあり、自動では同期されないことがひと目でわかり、やっと腹落ちしました。ちなみに、Gitは下記の流れさえ把握しておけばとりあえず何とかなるなと感じました。

GitHub ──clone/pull──▶ 手元のmain ──switch -c──▶ 作業ブランチ
作業フォルダ ──add──▶ ステージ ──commit──▶ ローカルの履歴 ──push──▶ GitHub

2. 同じ手順を何度も頼むなら、スキルにする

md が「わかった事実」を残す場所だとすれば、スキルは「決まった手順」を残す場所です。Claude Code のスキルは、作業の手順をファイルに書いて置いておくと、関係する頼み方をしたときに Claude がそれを読み込み、その手順どおりに作業してくれる仕組みです。

私は「あるデータがあるかを確かめる」「タスクの進み具合を表にまとめる」といった、毎回同じ説明をして頼んでいた作業をスキルにしました。毎回手順を説明しなくてよくなり、答えの形もそろうようになりました。最初から完璧なスキルを作ろうとしないのもコツだと感じました。

3. AI は自信満々に間違える

運用保守の仕事では、手順書やメーカーのドキュメントに書いてあることが正解でした。AI の答えも同じくらい自信ありげに見えます。でも、実際に確かめた事実なのか推測なのかは、見た目では区別がつきません。

今は「それは確認した？推定？何を見てそう判断した？」と必ず聞くようにしています。CLAUDE.md に「推定と確認済みの事実は分けて書く」と書いておくと、聞かなくても最初から分けて答えてくれます。

4. 一度にたくさん聞かない

聞きたいことが5つあるなら、1つずつ聞いたほうが、結局は早く正確に終わりました。1つの答えを見てから次の質問を考えられるのも利点です。あまり多くを聞くと当然かえってくる答えも長くなるので、理解するのもかなり疲れます。

まとめ

また、上記はほんの一例ですが、エンジニアとして働くにあたって、最初の環境の設定がものすごく大事だなと感じました。上記のことを知らないとずっと無駄にトークンを消費し続けることになります。今の自分のやり方でもっといい方法がないか（ショートカットキーがないか、いまVS Code使っているけどもっとみやすいエディターないかなど）とにかく自分の作業の無駄に疑問を持ち続ける姿勢が大事です。