使えば使うほどcodeがかしこくなる。
chatはもういらない？

AIエージェントに仕事をどんどんさせていると、ある問題が出てきます。

Code側だけが、会社のことをどんどん詳しく知っていく。

Claude CodeやCodexは、実際のファイルを見て、プログラムを修正し、ログを確認し、毎日現場で仕事をしています。

そのため、使えば使うほど、

• どんなシステムが動いているか
• どこに何があるか
• 過去にどんな修正をしたか
• どの仕組みがどことつながっているか

という知識が増えていきます。

一方で、普通のChatはそこまで細かいことを知りません。

すると、

「この仕組み、どうしたらいい？」

とChatに相談しても、前提を把握していないため、ズレた提案になることがあります。

さらに、そのChatに

「Claude Codeへの指示文を書いて」

と頼むと、知らない部分を具体的に補完してしまい、現場と合わない指示になることもあります。

その差を埋めるために、Codeの知識をChatにも共有する

そこで、私は会社の現状をまとめた共通ブリーフをGoogleドライブに置き、Chatも必要に応じてそれを読む仕組みにしました。

これでChatとCodeの認識差を減らすことができます。

ただし、ドライブに置いただけでは読まれません。

設定の一般のClaudeへの指示に、ドライブを参照することと明記します。

下記はルールの例です。

会社の現状を知る（設計や指示文の前に必ず）

新しい仕組みの相談を受けたときと、Claude Code への指示文を書くときは、先に
Google ドライブの「◯◯グループ 現状ブリーフ（チャット側AI用）」を読む。
会社ごとのフォルダの決まり・稼働中のシステム・進行中のプロジェクト一覧が入っている
（Claude Code 側が自動で作り直しているので、常に最新）。

そのうえで、指示文では次を守る。私は F: ドライブを見られないので、
知らないことを具体的に書くと必ずズレる。

- フォルダのパス・ファイル名・関数名を書かない。 ブリーフの台帳にある
  日本語名かフォルダ名で指す。実際のパスの確定は Claude Code 側の仕事。
- 実装手順やコマンドを書かない。 書くのは目的・制約・完了条件（何が起きたら完成か）。
- 新しく作る前に台帳を見る。 似たものがあれば「新規に作る」ではなく
  「既存の◯◯を直す／に足す」と書く。
- ブリーフ先頭の「版」が今日より2週間以上古ければ、その旨をボスに伝える。

つまり、Codeが毎日の仕事で増やした知識が、そのままChatにも渡ります。

Codeの知識をChatが共有できる。
そうすることで、お互いの強みが活きます。

Chatの役割は、Codeより詳しくなることではない

ここも重要です。

ChatとCodeの知識差を埋めるために共通ブリーフを作りましたが、

ChatをCodeと同じくらい詳しくする必要はありません。

それは無理です。

Codeは実際のファイル、コード、ログを日々見ています。

情報量ではどうしてもCodeの方が多くなります。

では、共通ブリーフは何のためにあるのか。

目的は、

Chatが間違った前提で判断しないためです。

つまり、すべてを覚えさせるのではなく、

• 会社ごとの役割
• 稼働中のシステム
• 進行中のプロジェクト
• 既存の自動化
• 主要なルール
• 似た仕組みがすでに存在するか

といった「地図」だけ共有すれば十分です。

細かい実装はCodeが調べればいい。

この分担の方が合理的です。

これからは、長い実装指示書を書かせなくていい

以前は、

という流れをよく使っていました。

しかし、今はここも変えた方がいいと思っています。

Chatが知らないファイル名や関数名まで書くと、ズレる可能性があります。

なので、Chatが書くのは、

• 目的
• 制約
• 完了条件

だけで十分です。

たとえば、

これくらいでいい。

あとはCodeが現場を見て、自分で実装方法を考えます。

この方がズレも少なく、指示も短くなります。

ただ、ここで一つ疑問が出ました。

そこまでしてChatに相談する意味はあるのか？
もう全部Codeに相談すればいいのでは？

結論からいうと、

実装の相談はCodeでいい。
でも、経営判断や設計判断まで全部Codeに寄せるのは違う。

この使い分けが重要です。

Chatは「上流」、Codeは「現場」

一番わかりやすい考え方はこれです。

WHAT・WHYはChat。
HOWはCode。

Chatに向いているのは、

• そもそもやるべきか
• 何を作るべきか
• どの案が良いか
• 費用対効果は合うか
• リスクは何か
• 別のやり方はないか
• 今の方向性そのものが正しいか

といった、上流の判断です。

一方でCodeに向いているのは、

• 現状のファイルを確認する
• 既存システムを調べる
• 影響範囲を確認する
• どこを修正すべきか判断する
• 実際に実装する
• テストする
• バグを直す

といった、現場の仕事です。

Codeだけに相談すると、現状に引っ張られやすい

Codeは現場をよく知っています。

これは大きな強みです。

ただし、逆にいうと、

今ある仕組みをどう直すか

という発想に寄りやすい面もあります。

たとえば、

「Claudeが止まったときにCodexへ切り替えたい」

と相談した場合、

Codeは今ある構成を見て、

「ここに切替処理を追加しましょう」

という方向で考えます。

もちろん、それで正しい場合もあります。

しかし一段上から見ると、

• 「そもそもAIを切り替える必要があるのか？」
• 「AIを使わなくても動く部分は、普通のプログラムにした方がいいのでは？」
• 「AIが必要な工程だけClaudeとCodexを切り替える方がいいのでは？」

という別の設計が見えてくることがあります。

これは、現場から少し離れて考えるChatの方が得意です。

理想の使い方は3段階

今後は、次の使い方が一番良いと思っています。

1Chatで方向性を決める

「これをやる意味はあるか？」

「もっと良いやり方はないか？」

「どの設計がいいか？」

ここで大枠を決める。

2Codeに現場を任せる

「現状を確認して、最適な方法で実装して」

と渡す。

Codeは実際のファイルを見て作業する。

3大きな変更はChatでもう一度レビューする

Codeが大きな設計変更を提案した場合、

「Codeはこう言っているけど、この方針どう思う？」

とChatに戻す。

これで、現場担当と第三者レビューの両方を使えます。