Claudeを増やしたら壊れたもの｜処理能力ではなく時計と数え方

Claudeを2つ以上動かすと、何が同時に走るのか

その前に、いまどのあたりにいるかを確認しておきます。帝国データバンクの調査では、生成AIを「活用している」中小企業は32.4%でした（小規模企業28.0%／大企業46.5%）。3社に1社が、すでに1つは使っています。この記事は、その次の段階の話です。

出典：帝国データバンク「生成AIに関する企業の動向調査（2026年3月）」（調査期間2026年3月17日〜31日・有効回答1万312社・回答率44.2%）調査結果ページ（2026年9月6日に原典で確認）

2026年9月5日、当社では次のような形でClaudeが動いていました。人は私1人です。

まん中に管理役のClaudeが1本だけあります。この管理役は自分では作業をしません。実行役から上がってきた報告を読み、良い・悪い・待てを返すだけです。その周りに実行役のClaudeが7本あり、それぞれ別の仕事をしていました。記事の書き直し、大きなページの作り替え、月次のレポート、サイトの保守、画像の説明文の整備、内部リンクの整理、といった具合です。

⚠この記事の数字は、すべてClaudeを何本も動かした実測です。ChatGPTやGeminiを並行させたときに同じことが起きるかは、当社では測っていません。ただし、あとで出てくる「AIは時計を持っていない」のように、Claudeに限らない話も混じります。そこは「AI」と書き分けています。

7本と数えているのは、その日に管理役へ報告を出した実行役のことです。保守の担当はこの日に1度交代しているので、前の担当と後の担当を別に数えています。起動していないもの、別のプロジェクトのものは含めていません。

ここで1つだけ線を引いておきます。役割の分け方そのものは、別の記事で書きました。8つに分けたClaudeの役割と、実際に起きたことがそれです。この記事はその続きで、「分けたあと、本数を増やして1日回したら何が壊れたか」の記録です。役割の決め方から知りたい方は、先にそちらをお読みください。もう1つ、あとの章と関わる線引きを先に書いておきます。時刻を付けて記録を残すという設計はそちらの記事のもので、この記事が扱うのは、その時刻自体が狂っていた事故のほうです。

先に証拠：10時間半で、49回・476行

まず量から出します。下の数字は当社の連絡板の記録を私が数え直したものです。管理役自身が申し送りに書いた概算（「裁定およそ80件」「およそ250行」）とは合いませんでした。概算をそのまま記事に写さず、元の記録から数え直しています。

※ 横にスクロールできます

出典：当社の連絡板の記録（2026年9月5日分）を筆者が集計。

この476行という数字は、2通りの数え方で突き合わせています。1回目は「宛先＋行数」をまとめて抜き出す方法、2回目は区切り記号で分けてから照合する方法です。1回目は全角の空白で区切られた1件を取りこぼし、2回目は別の2件を取りこぼしました。両方の取りこぼしを足し戻して、はじめて同じ数字になりました。1通りしか試さなければ、どちらの数字を出しても間違っていたことになります。

読んでいただきたいのはここです。13分に1回、10行。この量なら人間1人でも読めます。実際、管理役の処理能力は最後まで足りていました。それでも、次の章から見ていくとおり7件の誤りが出ました。

では、その1日でサイトは何ページ動いたのか

連絡板の量は「やりとり」の量です。実際にサイトのページが何枚動いたかも測りました。

※ 横にスクロールできます

出典：当社サイトの管理データを2026年9月6日に集計（最終更新日が2026年9月5日のページを、投稿と固定ページで別々に数えた）。

ここでも数え方の断り書きが2つ要ります。1つ目は、326のうち247は1回の一括処理だということです。「1日で326ページ直した」と書くと、人が1枚ずつ見た枚数のように読めてしまいます。中身を見て直したのは約79ページです。

2つ目は、この326は下限だということです。サイトが記録しているのは「最後にいつ直したか」だけなので、9月6日にもう一度触ったページは、9月5日の数から抜け落ちます。実際にはもう少し多かったはずですが、いま測れるのはここまでです。

この図が示しているのは、並行運用の実感と実測はずれるということです。体感では「一日中ずっと何かが動いていた」ですが、ページの動きで見ると山は1か所だけで、それは機械がまとめて処理した時間でした。人とClaudeが中身を見て直した仕事は、数で見ると小さく散らばっています。

管理役のClaudeが誤った7件と、止めた側

※ 横にスクロールできます

出典：当社の引き継ぎ記録および連絡板（2026年9月5日〜6日）。件数と型は筆者が1件ずつ照合。

もう1つ、性格の違う出来事がありました。実行役の1本が、管理役がいったん承認した自分の設計を、あとから自分で取り下げたことが2回あります。見出しを1つ消す判断と、2つの事実を対比させる書き方の2件です。これは「管理役の誤りを止めた」のではなく、実行役が自分の設計の誤りに自分で気づいたケースです。数え方を混ぜると件数がぶれるので、この記事では分けて数えています。

実際、管理役が申し送りに書いた「実行役が止めた回数」は6回でしたが、私が定義をそろえて数え直すと5回でした。差の正体は、この自己撤回2件を混ぜていたことです。

壊れたもの その1｜時計

最初に、都合の悪いことを正直に書きます。「実測には時刻を付ける」というルールは、この日より前から当社にありました。管理役自身がそれを守れていませんでした。仕組みが無かったのではなく、あった仕組みを使っていなかったのです。

そのうえで、なぜそうなるのかを書きます。AIは時計を持っていません。「いま何時ですか」と聞かれても、AIは会話の流れから推測するだけです。だから、放っておくと自信満々に間違った時刻を書きます。

証拠になる数字が1つあります。この日の記録49件のうち、時刻に「実測した」と明記があるのは25件、無いのは24件でした。約半分が推測の時刻です。さらに、記録の並び順も途中で崩れていました。最初のかたまり15件は「古い順」と宣言されていてそのとおり並んでいましたが、後の2つのかたまり（18件ずつ）は宣言が無く、それぞれ3か所で順序が入れ替わっていました。

時刻がずれると、効果を測る28日間の起点がずれます。1日ずれれば判定日が1日ずれる。それが複数の記事で同時に起きます。この日以降、当社は時刻を必ずコンピュータのコマンドで取得して書くように変えました。ルールを足したのではなく、すでにあったルールを、機械で強制する形に変えただけです。

壊れたもの その2｜所在

この日、実行役の1本が「送った報告10行が消えた」と判断して、まるごと送り直しました。調べると消えていませんでした。管理役はすでに読んで処理し、台帳も更新していました。読んだ印を書いた場所が、直前の整理でファイルへ移されていたために見えなかっただけです。

この実行役は、自分でこう報告しています。「読んだ印が連絡板の末尾にあるのを確認せずに、消えたと断定しました」。当社には「見つからない」は「存在しない」ではない、という決め事があります。それを自分で破ったという報告です。

逆方向の事故もありました。整理してファイルへ移したはずの記録が、別の担当が連絡板を丸ごと書き戻したせいで復活していました。実際、私が数え直したときにも、同じ文が2件そのまま二重に残っていました。表1で「51件のうち2件を除いた」と書いたのは、これのことです。

打ち手は簡単でした。読んだ印に、宛先と行数を必ず書く。「◯◯からの3行を読みました」と書いてあれば、送った側は自分の3行が届いたと分かります。これだけで「消えた／送り直す」の往復がなくなりました。

壊れたもの その3｜数え方

この日、サイトの裏側に古い記述が残っているページを一括で直す作業がありました。その1件について、記録の中に5つの数字がありました。

※ 横にスクロールできます

出典：当社の完了報告（2026年9月5日）および引き継ぎ記録。数字は筆者が出典行まで確認。

いちばん危なかったのは最後の244です。全部の処理を終えてから確認したところ、「245件直したのに244件残っている」と出ました。そのまま報告していれば「作業がまったく効いていない」という重大な誤報になっていました。

原因は、確認に使った取得方法が保存前の内容を返していたことでした。取得の仕方を変えて4通りで測り直すと、すべて0件でした。担当は報告にこう書いています。「1通りで測って断定していたら、正常な作業を異常として報告していました」。

そして、この記事を書くときにも同じ壁に当たりました。管理役から「その数字は246件のはずだ」と指摘され、調べたところ247が正しく、246も間違いではなく、複製だった数を答えていたと分かりました。どちらも正しい答えでしたが、問いが違っていたのです。並行運用で数字が食い違ったときは、まず「その数字は何を分母にしているか」を聞くのが早道です。

ブラウザは1本しかない

ここまでは記録の話でした。後半は、もっと物理的な話から始めます。

AIを何本立てても、ブラウザは1本しかありません。当社の実行役はブラウザを共有しているため、A が調べ物のためにページを開いている最中に、B が別のページを開くと、A の画面が奪われます。

この日、表記の統一と内部リンクの整理を進めていた担当の作業が、他の担当と重なって12回中断しました（2026年9月5日・担当自身の完了報告より）。原因は3種類で、画面を他の担当に奪われたもの、ログインが切れたもの、まとめて処理しようとして安全確認で止まったものです。

この「12回」にも数え方の話が付きます。管理役の要約には「10回」という別の数字が残っていました。この記事では、担当自身が書いた完了報告のほうを採っています。要約より、作業した本人の一次記録のほうが強いからです。⚠なお、その一次記録の内訳（6・5・2）を足すと13になり、書かれた合計12と合いません。合わない以上、内訳の数字は使わず、総数の12回と原因の種類だけを書いています。

同じ日、別の担当が画像の説明文を確認するための走査を、3つの担当が同時にブラウザを使ったせいで1回まるごと破棄しています。こちらは中断ではなく、やり直しです。

この事故は、能力とはまったく関係がありません。1人で1つ使っているうちは絶対に起きず、2つ目を立てた日から必ず起きます。当社の対処は、ルールを1つ足しただけです。

人が決めた19件

並行運用の相談でいちばん多い誤解が「AIを増やせば社長の仕事が減る」です。当社の記録では、そうなりませんでした。作業は減りますが、判断は減りません。むしろ、判断が1か所に集まります。

この日の連絡板には、私あての判断待ちが通し番号で1番から49番まで並んでいました（数日ぶんの累計です）。そしてこの1日だけで19件に答えが付きました。中身は、サーバーの設定を触ってよいか、この写真に写っている人の名前を書いてよいか、この外部リンクは生きているか、といったものです。どれも、AIが自分で決めてはいけない種類のものでした。

当社で人にしかできない仕事は3つに整理されています。①サーバーの防御設定の開け閉め ②公開ページへの本文の貼り付け ③最終判断です。この3つを人が持っている限り、AIが何本走っていても、間違いは公開の手前で止まります。表3の実害0件は、この3つのおかげです。

それでも、1日でこれだけ進みました

公平のために成果も書きます。2026年9月5日の1日で、次のことが終わりました。

出典：当社の各担当の完了報告（2026年9月5日〜6日）。

この量を1人でやろうとすると、私の場合は数週間かかります。だから並行運用はやめません。やめずに、壊れる場所だけを補強するというのが、この記事の結論です。

翌日から変えた5つの仕組み

※ 横にスクロールできます

この5つに共通しているのは、AIを賢くする話が1つも無いことです。モデルを上位のものに変えても、時計は付きません。所在も分かりません。数え方の分母もそろいません。そこは、人が仕組みで決める領域です。

なお、以前の記事で「管理役のClaudeを新しいモデルにしたら、何日で誤りが何件になるか」を続けて書くとお伝えしていました。Claude Fable 5.1とは｜社長が知っておくことと、消えない誤りで予告した宿題です。この記事がその答えにあたります。誤りは7件出ました。モデルを上げても、型は変わりませんでした。変わったのは、止められる仕組みがあったかどうかだけです。

よくある質問（FAQ）

まとめ