「Claude Code 会社を作る」と検索してここへ来られた方へ、先に正直なところをお話しします。AIの社員がいる会社をClaude Codeの上に作るのは、びっくりするくらい簡単です。ぼくも作りました。毎日ちょっとした社長気分で、これがもう、楽しいんですよ！ でも、本当に難しいのはそこから先でした。ぼくの会社は、回し始めてしばらくしたら、なぜかうまく回らなくなったんです。
この記事は、Claude Codeの上で「AIの相棒たちとの会社ごっこ」を回してきたぼくが、行き詰まって、記録を調べて原因を突き止めて、ルールを機械の仕組みに作り直すところまでの実録です。先に正直に言うと、作り直した仕組みが本当に効くのかは、まだ分かりません。いままさに確かめている最中です。それでも、「作り方」の記事にはまず書かれていない「作ったあとに起きること」は、これから作る方にこそ役に立つはずですよ。
「Claude Code 会社を作る」のやり方は、実はシンプルです
まずは、これから作る方のために、やり方の要点から。ぼくのやり方は特別なことを何もしていなくて、突き詰めると3つだけなんです。
ぼくの「会社ごっこ」はこんな形です
1つ目は、ルールファイルです。Claude Codeには、作業フォルダに置いた「CLAUDE.md」というファイルを毎回自動で読み込む機能があります。ここに「何のためにやるのか」「やっていいこと・いけないこと」を書いておくと、AIは毎回それを前提に動いてくれます。いわば会社の社則ですね。
2つ目は、役割分担です。Claude Codeは仕事ごとに担当のAIを分けられます。ぼくの会社ごっこの場合、やり取りをまとめる秘書（調整役）がいて、その下に記事を作る制作部、調べ物をする分析部、道具を作る開発部、それからわざと反対意見をぶつけてくる係までいます。各部の中でも、作る実行者と検査する部長は必ず別にしています。1人（1体？）に全部やらせるより、そのほうが間違いに気づきやすくなるんです。
この「記事を作る制作部」が、実際にネタ出しから画像生成、WordPressへの下書き投入まで自動でこなしている具体的な流れは、別の記事にまとめました。
3つ目は、最後の決定権を渡さないことです。公開する・削除する・お金が動く、みたいに取り返しのつかない操作は、必ずぼくの確認を通す設定にしてあります。AIがどれだけ優秀でも、ボタンを押すのはぼくです。
ちなみに、こういうAIエージェントの動かし方は、最近は本でも体系的に学べるようになってきました。気になる方はこちらもどうぞ。
このあたりの「そもそもClaude Codeで何ができるのか」は、前編にあたるこちらの記事に書きました。まだの方は先にどうぞ。
作るだけなら1日でできます。問題はそのあとでした
で、ここからが本題です。この形を作ること自体は、正直、拍子抜けするほど簡単です。ルールを書いて、役割を決めて、頼んでみる。その日のうちに「会社っぽいもの」は動き始めます。作り方を解説した記事が世の中にたくさんあるのもうなずけます。
ただ、ぼくが今回書きたいのは、そのどの記事にも書かれていなかったことです。作った会社は、放っておくと崩れます。しかも、崩れていることに気づけない形で崩れるんです。
Claude Codeでの会社運営が、なぜか回らなくなってきました
最初の数週間は順調でした。頼めば動くし、報告も上がってくる。ところがある時期から、説明しづらい違和感が積もり始めました。症状は大きく2つです。
症状1：終わらせたはずのことが、終わっていない扱いになる
前に片づけたはずの作業が、しばらく経ってから「まだ終わっていません」という顔でもう一度出てくるんです。ぼくの感覚をそのまま言葉にすると、「終わらせたのに、終わっていない扱いになる」。やったよね？と聞けば、記録を調べて「やってあります」と返ってくることもあれば、本当に残っていないこともある。この「どっちなのか分からない」状態が、じわじわ効いてきます。
症状2：頼んだことが、気づかないところで宙に浮く
もう1つの症状は、指示したはずの改善が、いつの間にか反映されないまま消えていることでした。その場のやり取りでは、AIはちゃんと「やりました」と報告してくれます。報告に嘘があるわけでもない。なのに、あとから確認すると抜けている。
気味が悪いですよね。サボりでも嘘でもないのに、結果だけが無い。この時点のぼくは、原因がまったく分かっていませんでした。
記録を調べて分かった原因は「ルールは、書いただけでは守られ続けない」でした
そこで、会社の記録を最初から全部たどり直してみました。Claude Codeとのやり取りは会話（セッション）ごとにリセットされるので、決まったことは会話の外のファイルに記録して引き継ぐのが基本です。「AIとの作業は記録がぜんぶ」という話は、ClaudeとGeminiの無料版をくらべた記事でも書きました。ぼくの会社もその原則どおり、決めたことはファイルに残していました。だから、たどれば原因は出てくるはずなんです。実際、出てきました。3つあります。
原因1：決めた改善が、22日間も置き去りになっていました
7月なかばに決めた改善が3点、作業用の控えの場所（Gitでいうブランチ）に置かれたまま、正式な記録に合流しないまま残っていたんです。見つけた時点で、22日間が経っていました。
AIは次の会話ではそのことを覚えていません。正式な記録に入っていないものは、次の会話では「無かったこと」になります。ぼくは「決めたからやってくれているはず」と思い、AIは「記録に無いので知らない」と動く。誰も嘘をついていないのに、改善だけが宙に浮いていました。症状2の正体はこれでした。
原因2：同じ型の「終わったつもり」が、ぜんぶで4件見つかりました
数え直したら、この「決めた・やったつもりの作業が、正式な記録に入らないまま無かったことになる」という取り残しは、ぜんぶで4件ありました。中には、公開まで終わった記事の制作記録が、正式な置き場に1文字も残っていなかったものまであります。症状1の「終わらせたのに終わっていない扱いになる」の正体は、これです。
ここで大事なのは、4件とも同じ型だったことです。1回きりのうっかりなら人間にもあります。でも同じ間違いが4回続くなら、それは誰かのミスではなく、仕組みの穴ですよね。
原因3：ルールの文章は13日間で3.1倍に増えて、それでも守られませんでした
じゃあそれまでのぼくが何もしていなかったかというと、逆なんです。問題が起きるたびに、ルールファイルに文章を書き足していました。その結果、運用ルールを書いたファイルは、ある13日間だけで11,748字から36,465字へ、3.1倍に膨らんでいました。
それでどうなったか。たとえば「記事を書く前に、過去の記事を読んで口調を確かめる」という決まりがありました。ある記事の作業記録331,799字をぜんぶ検索しても、この決まりが実行された痕跡は1件もありませんでした。ルールとして立派に書いてあるのに、一度も動いていなかったんです。
ルールが守られなくなるのは、忘れられたときだけじゃありませんでした。ルールが増えるほど1つあたりの重みは下がるし、「それっぽい別の作業」で済ませても誰も気づけなくなる。書いた本人のぼくが言うのもなんですが、文章のルールって、書いた瞬間がいちばん強くて、あとは弱っていく一方なんですよ。
対策：ルールを文書から「機械の縛り」へ移しました
原因がここまで見えると、やることは決まりました。「守ってね」と文章でお願いするのをやめて、守るしかない仕組みに変える。ぼくはこれを「機械の縛り」と呼んでいます。
使うのはフックと許可設定。どちらもClaude Codeの標準機能です
1つ目の道具はフック（hooks）です。「決まったタイミングで、決めたプログラムを必ず走らせる」仕組みで、たとえば会話を始めるたび・道具を使う直前、といった節目に自動で実行されます。思い出してもらう必要がないのがポイントです。詳しくはClaude Code公式のフック解説（※英語サイト・自動翻訳推奨）にまとまっています。
2つ目の道具は許可設定です。設定ファイルに「この形の操作は拒否する」と書いておくと、AIがそのコマンドを実行しようとした瞬間に止まります。こちらはClaude Code公式の設定ドキュメント（※英語サイト・自動翻訳推奨）が正本です。
ちなみに、ぼくの会社にはもともとフックが2本だけありました。会話を始めるたびに記録を最新の状態にそろえる1本と、返信のたびに大事な前提を思い出させる1本です。この2本が普通に働いてくれていたので、「文章のお願いはすり抜けられるけど、フックはすり抜けられない」という手応えは、感覚としてすでにあったんです。今回はこれを本格的に増やしにいった、というわけです。
この「返信のたびに大事な前提を思い出させるフック」は、その後さらに育っていて、話し方のルールを毎回強制的に読み込ませる仕組みに変えました。YouTube動画で紹介されていたスキルとの答え合わせも兼ねて、詳しくは別の記事に書いています。
フックの使い道を、もう1つ挙げておきます。Claude Codeには、「これが終わりだ」と言える条件を1つ書いておくと、満たすまで止まらずに作業を続ける「/goal」というコマンドがあります。中身は、その会話の間だけ有効になる停止フックで、1ターン終わるたびに別のAIが「条件を満たしましたか」と判定する作りです。「最後までやってね」と文章でお願いするかわりに、終わったかどうかの判定を機械のほうに持たせる形なので、ここで書いた作り直しと同じ方向の仕組みだと思っています。実際に走らせて測った数字も載せました。
文書のルールから「必ずやる・絶対やらない」を38件拾い出して、仕分けました
作り直しは、いきなり設定をいじるのではなく、棚卸しから始めました。膨らんだルール文書を全部読み直して、「必ずやる」「絶対やらない」と書いてあるものを38件拾い出し、機械で強制できるかどうかで仕分けたんです。結果はこうなりました。
すでに機械で止まっていたものが10件。文章で書かれていたけれど機械の縛りに移せるものが14件。機械では縛れないものが11件。残りは保留です。
最初に移した14件の代表が、「会話を始めるたびに、終わったのに残っている項目が無いかを自動で点検するフック」です。まさに22日間の置き去りを生んだ形を、毎回、機械が見に行くようにしました。ぼくが思い出す必要も、AIが覚えている必要もありません。
もう1つの代表が、案件を終わらせるときの点検の道具化です。取り残し4件はどれも「終わらせる手順が最後の一歩の手前で止まっていた」形だったので、「記録の整理は済んだか」「正式な記録に合流したか」を機械が調べて、残っていれば残っていると言い切る道具を作りました。「終わったつもり」かどうかを、ぼくの記憶ではなく機械が判定してくれます。
AIに仕事を任せる仕組みづくりをもっと深掘りしたい方は、こちらも参考にどうぞ。
「機械では縛れない11件」を機械任せにしない、とも決めました
意外に大事だと思ったのが、こっちです。文章の良し悪しや、事実の捏造が無いか、といったことは、機械では判定できません。ここを無理に機械のチェックへ置き換えると、「チェックを通ったからOK」という新しい油断が生まれます。実は、ぼくの行き詰まりの一因もこれでした。「過去記事を読んで口調を確かめる」という決まりが、いつの間にか「それっぽい数え上げ」で済まされて、実行されたことになっていたんです。
機械で縛れるものは機械へ。縛れないものは「縛れない」とはっきりさせて、目で見る。ぼくの会社ごっこでは、この「目で見る」は機械にやらせず、作った実行者とは別の部長役のAIが頭から通しで読み、最後にぼくが見る、という分担にしました。この線引きそのものが、今回の作り直しでいちばん効いてほしい部分です。
実測して分かったこと。「設定は書けば効く」も思い込みでした
縛りを足すにあたって、1つだけ決めごとをしました。「設定は、書いただけでは効いているか分からない。効くことを実測で確かめてから入れる」です。半信半疑で始めたんですが、これが大正解でした。
新しい縛り9件を試したら、7件は効いて、2件は素通りしました
試し方は単純です。縛りに引っかかるはずの無害なコマンドをわざと実行してみて、ちゃんと止まるかを見る。新しく足した縛り9件を1件ずつ試した結果がこちらです。
9件中7件は、狙いどおり実行前に止まりました。ところが2件は素通りして、止めたかったはずのファイル書き込みが普通に実行されてしまったんです。書いた設定の2割が、書いただけでは働いていなかったことになります。
素通りした2件には共通点がありました。どちらも、コマンドの出力を記号ひとつでファイルへ流し込む形（リダイレクト）の書き込みだったんです。実測から見えた範囲では、この形の書き込み先は設定の照合の対象に入っていないようでした。正確な理由はまだ言い切れません。なのでこの2件は、許可設定ではなく「実行直前にコマンドの中身を読んで判定するフック」で塞ぐ予定です。ここもまだ、確かめながら進めている途中です。
前からあった縛り30件にも、効いていないものが1件ありました
ついでに、前からあった縛りも疑ってみました。前から設定してあった縛りは全部で30件。そのうち、同じファイルを守っている数件を同じ方法で試したら、1件、実は効いていないものが見つかりました。10日間「塞いだつもり」でいた設定が、実測してみたら素通りだったわけです。
これも中身は同じ話でした。守りたいファイルは1つなのに、コピーのコマンドで書き込もうとすると止まる、書き込み用の別コマンドを経由しても止まる、なのにリダイレクトの形だけが素通りする。同じ「ファイルに書き込む」操作でも、コマンドの形が違うと照合に引っかからないことがある。これは設定を書いた本人が読み返しても、まず気づけません。実行してみて初めて分かりました。
「書いてある」と「効いている」は別物。文章のルールで学んだはずのことを、機械の設定でももう一度学びました。もし皆さんがClaude Codeで危ない操作を設定でブロックするなら、無害なコマンドで一度わざと引っかかってみることを、ぼくは強くおすすめします。
縛りを作ったAI自身も、縛りに引っかかって止まりました
最後に、ちょっと面白かった話を。動作テストの最中、縛りの設計をしたAI自身が打ったコマンドが「拒否されました」と止められる場面が何度もありました。これは狙いどおりの動きなんですが、自分で作った柵に自分で引っかかるAIというのは、なんだか健気で笑ってしまいました。
もう1つ。縛りの設計図を書いたAIは、その設定ファイルを自分では書き換えられませんでした。Claude Codeでは、この手の設定変更はAIの一存では通らず、ぼくの確認を通す作りになっているからです。AIが自分で自分の縛りをゆるめられない。この構造を実際に目で見られたのは、安心材料でした。
まとめ：Claude Code 会社を作るなら、「作ったあと」に備えてください
長くなったので、ぼくの実録をまとめますね。
- 作るのは簡単です。ルールファイル（CLAUDE.md）・役割分担・最後の決定権は人間、の3点で「会社っぽいもの」はその日に動きます
- ただし作りっぱなしだと崩れます。ぼくの場合は「終わらせたはずが終わっていない扱いになる」形で現れ、調べたら22日間の置き去りや、同じ型の取り残し4件が出てきました
- ルールの文章を増やしても守られ続けません。13日間で3.1倍に増やしても、痕跡ゼロの決まりがありました
- 「必ずやる・絶対やらない」は、フックと許可設定で機械の縛りに移せます。ぼくの場合、文書のルール38件のうち14件が移せました
- ただし設定は書いただけでは信用しないでください。ぼくの実測では9件中2件が素通りでした。効くことを確かめてから入れる、が鉄則です
- 機械で縛れないものは最後まで残ります。そこを機械任せにしないことも、仕組みのうちです
それで、肝心の「作り直した会社はちゃんと回るようになったのか」ですが、これはまだ分かりません。実はこの記事自体が、作り直した仕組みの上で書いている最初の記事なんです。新しい縛りが効いたのか、空回りしたのか、それとも思いもしない場所でまた崩れるのか。1か月くらい回してみて、結果がどっちに転んでも、また正直に書きますね。
それでも最後に1つだけ言い切れるのは、「Claude Code 会社を作る」こと自体は本当におすすめだ、ということです。うまく回っても、行き詰まっても、AIと働くというのがどういうことか、体で分かります。ぼくの失敗が、これから作るあなたの近道になればうれしいです！
ちなみに、この記事と同じ「Claude CodeでAIのチームをつくる」というテーマの本も出ています。文系・非エンジニア向けをうたう1冊です。気になる方はこちらからどうぞ。
追記：この記事のあと、AIエージェントにドキュメント・知識・ルールの管理を任せる方法をさらに掘り下げて、Claude Codeでブログ運営を自動化する3つの方法。実際に試してみましたという記事も書きました。あわせて読むと、自動化の中身がもう少し具体的にわかると思います。
コメント