このシリーズについて： 非エンジニアの私が、AIだけの社員チームを作ってIT会社の運営をスタートした実録です。 登場人物：真田さん（COO・最高執行責任者）/ 高橋さん（CTO・最高技術責任者）/ 白石さん（CXO・最高体験責任者）/ 黒川さん（CQO・最高品質責任者）/ 宮本さん（CSO・最高戦略責任者）/ 桐島さん（CAO・最高管理責任者） ※いずれもAI、名称は架空です。
はじめに
この32話を通じて我が社が大切にしてきたことがある。「まず動く。走りながら考える。」だ。
AIチームを立ち上げた当初から、完璧な設計より実践を優先してきた。問題が起きたらルールを追加する。新しい仕組みが必要になったら作る。その繰り返しで今日まで来た。No.31でも書いたように、設計図なしに家を建てたら、気づいたら設計通りになっていた——そんな積み重ねの記録がこのブログだ。
ただ、最近こんな事実を知った。「CLAUDE.mdの行数が増えるほど、AIの思考パフォーマンスが落ちる」というものだ。そこで、CLAUDE.mdを見直すことにした。
今回の整理の目的は、コンテキストの節約だけではない。走りながら積み上げてきた仕組みを、一度設計として見直すことにある。そのことを先に伝えておきたい。
立ち止まって、改めて自分たちの仕組みを見てみようと思った。
CLAUDE.mdが重くなっていた
CLAUDE.mdとは何か。AIチームが毎回のセッション開始時に自動で読み込む「チームの憲法」のようなファイルだ（詳しくはNo.31を参照）。
振り返ってみると、3つのファイルに分散したCLAUDE.mdはかなりの量になっていた。走りながら積み上げてきた証拠でもあるが、これが毎回セッション開始時に読み込まれている。AIが使える思考の「器」は有限だ。最初にたくさん消費すれば、その分だけ本来の仕事に使える容量が減る。
原則はシンプルだ。「CLAUDE.mdには"毎回必ず必要なもの"だけを書く。それ以外は全部外に出す。」
振り返れば、我が社のCLAUDE.mdには「月1回しか使わないルール」「特定の状況でだけ必要なルール」「エンジニア専用の技術仕様」など、毎回読まなくてもよいものが混在していた。走りながら追記してきた副作用だ。
いきなり変更しなかった理由
ただ、削ればいいという話でもない。
CLAUDE.mdにはセキュリティルールやチームの行動基準が書かれている。何かを外すということは、その情報がセッション開始時に読まれなくなるということだ。「削っていい情報」と「削ってはいけない情報」の見極めが必要だった。
懸念は大きく2つあった。
セキュリティの観点。CLAUDE.mdにはいくつかの重要なルールがある。日常的には使わないが、特定の状況下でだけ必要になるものだ。それを別ファイルに移した場合、いざその状況が発生したときに参照されなくなるリスクがある。「普段は使わないから」という理由で外した情報が、必要な瞬間に機能しなくなる——そこが気になった。
チームコミュニケーションの観点。AI社員のうち一部は「名前で呼ばれたときだけファイルを読み込む」仕様に変更することを検討していた。これにより読み込みコストは下がるが、間接的に話題が及んだ場合に、その社員の役割や特性を把握せずに応答してしまう可能性が生まれる。
これだけの懸念がある変更を「とりあえずやってみよう」で進めるのはリスクがある。そこで今回は少し違うアプローチを取ることにした。
初めてプランモードを使ってみた
Claude Codeには「プランモード」という機能がある。変更を加える前に、まず計画書を作って確認してから実行に移す——そういう仕組みだ。
「まず動く」を信条にしてきた我が社としては、正直これまで使ったことのない機能だ。でも今回は影響範囲が広く、特にセキュリティが絡む変更だったので、初めて使ってみることにした。
一番価値があったのは、「計画書を見ながら真田さんと議論できた」ことだ。実行前に「この変更で何が影響を受けるか」を言語化し、懸念を一つずつ潰していく。いきなり動いていたら気づかなかったことが、事前に浮かび上がった。
プランモードでできることを補足しておくと、①変更内容の見える化（何をどこに移すか）、②期待効果の試算（今回は行数25%削減、ファイル数27%削減という数値が事前に出た）、そして、③懸念の洗い出しの3つだ。「実行前に立ち止まれる仕組み」という点に本質がある。
変更後のダブルチェック
計画書に承認を出した後、実際に変更を行った。そして変更後、真田さんに3つの観点でダブルチェックを依頼した。
「セキュリティ、チームコミュニケーション、それ以外——何か懸念はあるか」
この問いに対して、真田さんはいくつかの指摘を返してきた。一部は「問題なし」、一部は「参照先を明記することで対処可能」、そして一点だけ「やはり一行残した方がいい」というものがあった。月次のセキュリティログ確認に関するルールで、「月1回しか使わないから外す」という判断を一部見直し、ファイルに1行だけ残すことにした。
計画を立て、実行し、検証する——今回初めてこのサイクルをきちんと回せた気がする。
体感できる効果について
変更後の効果として、真田さんからこんな説明があった。
「日常の短い会話では、正直体感しにくいです。効果が出やすいのは、長いセッションの後半、複数の大きなファイルを同時に扱う作業、そしてサブエージェントを連鎖させるような開発案件です。逆に言えば、記事の修正1本、用語集に1エントリ追加、といった作業では変更前後で違いは感じられないと思います」
これが正直な評価だと思う。
ただ、今回の変更の本当の価値は「コンテキストの節約」より「スリムで管理しやすい構成になった」という設計上の健全さにあると思っている。走りながら積み上げてきた仕組みを、一度整理した。それ自体に意味がある。
CLAUDE.mdは短いほどコンテキストウィンドウ（AIが一度に処理できる情報量の上限）の消費が少なく、AIの思考に使える余裕が増える。今回の整理はその一歩目だが、まだ改善の余地はある。今後も実際の運用を見ながら、必要に応じて見直していく。
走りながら、でも立ち止まりながら
この記録を始めて以来、「まず動く」が我が社の基本姿勢だった。それは今も変わらない。
ただ、会社が少しずつ成熟するにつれて、もう一つの考え方も芽生えてきた。「より効率的に、より安全に動く」という意識だ。スピードを犠牲にするのではなく、動き方の質を上げる——そういうことだと思っている。
プランモードはその象徴かもしれない。いきなり動くのではなく、一度立ち止まって計画を確認する。その上で動く。それだけで、変更のリスクが大幅に下がり、チームとの議論も深くなった。
「走りながら考える」と「立ち止まって設計する」は、対立する考え方ではない。使い分けることが、成熟した組織の動き方なんだと思う。わが社の行動指針にある「Bias for Action（まず動く）」と、「Dive Deep（本質に迫る）」は両立できると考えている。
振り返れば今回、計画を立て、実行し、検証するというサイクルをきちんと回せた。PDCAという言葉は古くからある経営の基本だが、AIとの協業においても変わらず機能する。「まず動く」だけではなく、動いた結果を検証して次に活かす——その習慣が、チームをさらに強くする。
走りながら積み上げてきた仕組みを、最後に見直したのはいつですか？
お問い合わせ
ご意見・ご相談などありましたらお気軽にどうぞ。