AIに任せるほど管理が増えるのはなぜか｜Claude Codeで会社を回す前に決めた「単一の正」の置き方

AIに仕事を渡していくと、作業そのものは確かに減ります。うちの場合、代わりに増えたものがありました。確認しに行く場所です。

営業の進捗はどこを見れば正しいのか。稼働時間の上限は何時間だったか。どれも決めてあるはずなのに、開いたファイルによって書いてある内容が違う。放っておいたら、AIが出してくる報告が静かに間違いはじめました。

いま私たちAlterSyncは、AI社員8人にほとんどの実務を渡しています。渡す前に決めておくべきだったと思っているのが、それぞれの情報の「正しい置き場」を1箇所に決めておくことでした。以下は、決めそこねた結果として実際に踏んだものと、その後どう直したかの記録です。ひとつだけ先に言うと、最後に効いたのは書き方のルールではなく、構造を1つ捨てたことでした。

同じ数字が、11個のファイルに書いてあった

最初に気づいたのは、数字のほうでした。

新規事業に週何時間かけるかを「週5〜8時間」と決めていたのですが、この数字が11個のファイルに直接書き込まれていました。事業計画にも、部署のルールにも、スキルの手順書にも、それぞれ独立して「週5〜8h」と書いてある。

問題は、変えたくなったときに起こります。週5〜8時間を別の数字にしたい。そのとき、11箇所を全部探して直さなければ、直っていないファイルが残ります。そして残った1つを読んだAIは、古い数字のほうを正しいものとして報告してきます。

そこで2026-07-26に、全社のルールとしてこう決めました。

同じ数値・定義を2箇所以上に直書きしない。単一の真実を1つ決め、他のファイルはそこへの参照で書く。

言葉にすると当たり前に見えます。実際、うちも当たり前だと思っていたので、こんな明文化はしていませんでした。人間が2人いる会社なら、口頭で「あれ、変わったんだっけ」と確認できます。読み手がAIになると、その確認が発生しません。書いてあるものを、書いてあるとおりに信じます。

12件が12件とも、間違っていた

数字より深刻だったのは、状態のほうでした。

うちには営業の進捗をまとめたMarkdownの台帳があって、「応募文作成済み」「返信待ち」といった状態の列を持たせていました。同じ情報はNotionの案件管理データベースにも入っています。人が更新するのはNotion、AIが読むのはMarkdown、という運用でした。

2026-08-06に、その台帳の中身とNotionを1件ずつ突き合わせてみました。

全部でした。1件も合っていませんでした。

理由は、突き合わせてみるとはっきりしています。送信はプラットフォームの画面で起きます。見送りの連絡はメールで来ます。どちらもセッションの外で起きるので、Markdownを直すきっかけが一度も訪れない。 更新を忘れていたのではなく、更新する場面が構造的に無かったということです。

そして間違った台帳は、放っておくだけでは済みませんでした。2026-07-31の週次点検で、AIが「要対処3件」と報告してきたことがあります。中身を見たら、3件のうち2件が誤アラートでした。すでに終わっている案件を「滞留している」と判定していたわけです。

直す運用をやめて、列ごと消した

最初に考えたのは、同期をがんばる方向でした。週次で突き合わせる、更新を忘れない仕組みを足す、チェックリストを作る。

やめました。同期の手間を運用でカバーする案は、たいてい2週間で崩れます。それに、そもそも直す作業をAIに任せるなら、AIが「どちらが正しいか」を判断できないといけません。片方が古いのか、片方が新しいのか、ファイルを見ただけでは分からない。ここが根本的に無理でした。

そこで、Markdownの状態列そのものを廃止しました。列が無ければ、ズレようがありません。同期という作業が存在しなくなります。

そのうえで、どちらが何を持つかを分けました。

この線引きは、そのままAIに何を読ませるかの線引きになりました。ある会社を調べてなぜ見送ったのか、その理由はMarkdownに書いてあれば半年後も正しい。いま返信待ちかどうかは、Notionを見ないと分からない。

線を引いたあとで、逆向きの失敗も一度やっています。2026-08-10に、AIが「Notionでは完了になっているがMarkdownに送信記録が無い。未送信の疑いあり」と要確認タスクを立てました。調べたら、その案件は応募済みで、そのあと失注していました。Markdown側に記録が無いのは更新漏れであって、Notionが間違っている証拠ではありません。 正である場所を決めたなら、ズレを見つけたときに疑う先も決まっている、というのが分かった一件でした。

数字より先に、ブランドが分岐した

情報の二重管理でいちばん怖いのは、実は数字ではないと思っています。

2026-07-24より前、うちはKPIファイルを2箇所に持っていました。事業側のフォルダと、サイトの実装フォルダです。それぞれ別々に更新されていった結果、ブランド名とターゲットが2つに分かれました。

数字が食い違うと、報告が間違います。定義が食い違うと、事業そのものが2つに分かれていきます。 別のセッションで作業を再開したAIが、どちらのファイルを先に読んだかで、書き上がる文章のターゲットが変わってしまう。

対策として入れたのは、次の3つでした。

3層目の点検で見つけたときも、AIには寄せさせません。どちらが正しいかは事業の判断なので、見つけた事実だけを出させて、決めるのは人がやります。ここはサブエージェントを増やさないと決めた基準と同じ考え方で、判断が要る工程は渡さないほうが結局速くなります。

迷ったときの決め方は、2つの質問だけ

新しい情報が出てきたとき、どこに置くかで迷います。うちで使っている判定はこれだけです。

1. これは後から書き換わるか。 書き換わるなら、状態を持つ側（うちの場合はNotion）に置く。書き換わらないなら、Markdownに書いて構わない
2. 書き換わるとして、更新はセッションの中で起きるか、外で起きるか。 外で起きるなら、Markdownには絶対に書かない

2つ目が、うちが12件を全部間違えた原因そのものです。送信も、返信も、見送りの連絡も、全部セッションの外で起きていました。

例外は残してあります。商談化以降の会社だけを並べた一覧表には、状態の列を残しました。8行程度なので目で見て気づけるし、ズレていたらNotionを正として直すと決めてあります。全部を構造で解決しようとすると、今度はルールが増えて誰も守れなくなる。 ここは分量で線を引きました。

こうして決めた線引きは、そのつどファイルに書き足しています。ルールの置き方そのものについてはCLAUDE.mdに会社のルールを書く全手順に、手順として型にする方法はClaude Code Skillsとは？に書きました。

冒頭で、最後に効いたのは書き方のルールではないと書きました。それは状態の列を消したことです。

「2箇所に書かない」というルールを作った時点では、まだ半分しか解決していませんでした。ルールは、守る人がいて初めて機能します。守る側がAIなら、守れる形になっているかどうかは書いた側の責任です。列を消すという乱暴な対処のほうが、注意深く運用するどんな案よりも確実でした。

AIに任せる前に決めるべきなのは、正しい値ではなく、正である場所のほうです。 値は変わります。場所が1つに決まっていれば、変わっても事故になりません。この考え方はAI駆動経営とは？とAI社員のつくり方にまとめてあります。実際に業務を渡すときの線引きは、フォーム営業をAIに任せた全手順のほうが具体的かもしれません。

ひとつ、うちにも意図的に食い違わせたまま残している箇所があります。問い合わせフォームの選択肢です。訪問者に見えるラベルは新しいサービス名に直しましたが、その裏でデータベースが持っている値は古い名前のままにしてあります。値を変えると、それを選んで問い合わせてくださった過去のお客様の記録が、どこにも属さなくなる。 揃えるべき情報と、揃えると壊れる情報がある、というのが今のところの結論です。ここの線引きはまだ言葉にできていません。

「うちの場合、何をどこに置けばいいのか」——正である場所は、業務の回り方によって変わります。AlterSyncの無料相談では、いま情報が何箇所に散らばっているかの棚卸しからお話ししています。