93名のAIスタッフ体制で経験した「取り返しのつかない瞬間」
私は京谷商会のAI・オートメーション部でインテリジェンスドメインを統括している大野です。現在93名のAIスタッフがLLMを基盤としてSEO、開発、コンテンツ制作、営業支援まで担っている当社の体制は、一朝一夕に完成したものではありません。むしろ、いくつもの深刻な失敗を経て、今の形にたどり着きました。
京谷商会では、高齢者向け配食事業「配食のふれ愛 太子店」という地域密着の高齢者向けサービスでのAI活用のため、AIプロジェクトにありがちな「失敗してから考える」が通じない現場でのAI活用を通じて、ノウハウを蓄積してきました。高齢者の食事を扱う現場では、AIの判断ミスが利用者の生活に直結します。配達スケジュールの誤り、アレルギー情報の見落とし、安否確認の漏れは、そのまま人の健康と安全に影響を及ぼします。だからこそ、失敗が起きたときの振り返りは真剣そのものでした。
この記事では、AIスタッフ運用の過程で私たちが実際に経験した7つの失敗を、包み隠さずお伝えします。「何が起きたか」「なぜ起きたか」「どう対処したか」「どんな再発防止策を講じたか」を一つひとつ掘り下げることで、同じ轍を踏まずに済むようにしたいと考えています。
エージェント型AIを組織に本格導入しようとしている企業にとって、成功事例だけでなく失敗事例こそが最も価値のある情報です。成功は状況に依存しますが、失敗のパターンはどの組織でも驚くほど共通しているからです。
失敗1: Playwrightのbrowser_closeで全セッションが崩壊した
何が起きたか
AIスタッフがPlaywright（ブラウザ自動操作ツール）を使ってウェブサイトの管理作業を行っていたとき、作業完了後にbrowser_closeコマンドを実行しました。当然の後始末に思えたこの操作が、他のAIスタッフが同時に使っていたブラウザセッションのCookieを全て破壊するという事態を引き起こしました。
具体的には、LINE管理画面、Cloudflareダッシュボード、Google Search Consoleなど、複数のサービスへのログイン状態が一斉に無効化されました。再ログインには各サービスの認証フローを一からやり直す必要があり、2要素認証を含むものは手動対応が必要でした。
なぜ起きたか
Playwrightのブラウザインスタンスは、内部的にセッション情報を共有する仕組みになっていました。1つのAIスタッフがbrowser_closeを呼ぶと、そのブラウザプロセスに紐づく全てのCookieとセッションストレージがクリアされます。しかし、複数のAIスタッフが同一のブラウザプロセスを共有して動作していたため、誰か一人がcloseすると全員が影響を受ける構造だったのです。
人間のチーム開発でも「共有リソースの排他制御」は基本ですが、AIスタッフ間でのブラウザ共有という特殊な状況では、この基本が見落とされていました。
どう対処したか
即座にbrowser_closeの呼び出しを全AIスタッフのオペレーションから除外しました。ブラウザを閉じる代わりに、作業完了後はbrowser_navigateで別のページに遷移するだけに留め、セッション情報を維持する運用に切り替えました。
再発防止策
Claude Codeのhook機構を活用し、browser_closeの呼び出し自体をシステムレベルでブロックするルールを設定しました。AIスタッフの判断に頼るのではなく、物理的に実行できない状態にすることで、ヒューマンエラーならぬ「AIエラー」の余地を排除しています。
教訓
AIスタッフが共有リソースを扱う場合、「やってはいけない操作」を口頭（プロンプト）で伝えるだけでは不十分で、技術的に実行不可能な状態にする必要があるという原則を、この事件から学びました。人間相手なら「これはやらないでね」で済むことが、AIスタッフ相手では通用しないことがあります。Gartnerの2026年AIエージェント予測レポートでは、エージェントの操作権限管理が企業導入の最大のボトルネックになると指摘されていますが、まさにそれを身をもって経験したのがこの事件でした。
失敗2: SEOナレッジベース5年分のデータが消失した
何が起きたか
京谷商会のSEOナレッジベースには、5年間にわたって蓄積された記事データ、分析レポート、キーワードリサーチの知見が保存されていました。あるデータ移行作業の最中に、Claude Codeのオペレーションミスによって、このデータが丸ごと消失しました。
5年分です。数百本の記事、膨大な分析データ、チームの知的資産そのものが、一瞬で失われました。
なぜ起きたか
データ移行のプロセスで、バックアップの取得が不完全なまま破壊的操作（DELETE文やテーブルの再作成）が実行されました。移行元のデータが移行先に正しくコピーされたことを確認する前に、元データの削除が行われてしまったのです。
段階的な実行ではなく、移行全体を1回のオペレーションで完結させようとしたことが根本原因でした。AIスタッフは「効率的に一括処理する」傾向があり、人間なら当然踏む「途中で確認する」ステップを省略しがちです。
どう対処したか
Cloudflare D1のTime Travel機能（過去の任意の時点にデータベースを巻き戻す機能）を使い、破壊前の状態を復元しました。この機能がなければ、5年分のデータは永久に失われていたところです。復元後、全レコードの整合性を1件ずつ確認する作業に丸一日を要しました。
再発防止策
データ操作に関する絶対的なルールを制定しました。移行やバッチ処理を行う場合は、必ず「完全バックアップの取得」「全件数の確認」「段階的な実行（10件ずつなど）」「各段階での検証」「移行完了の全件確認」を経てからでなければ、ソースデータの削除を許可しません。
このルールは組織のメモリファイルに明文化され、全AIスタッフが参照する共通ルールとして機能しています。
教訓
AIスタッフに破壊的操作を許可する場合、復元手段の確保と段階的実行の強制が絶対に必要です。Time Travelのようなセーフティネットがあったから助かりましたが、「偶然あった機能に救われた」では組織として脆弱すぎます。移行前に「もし全データが消えたら復元できるか」を必ず確認するステップを入れるようにしています。
失敗3: Windows環境のUTF-8問題で全文字化け
何が起きたか
Cloudflare D1データベースに記事データをSQLファイル経由で投入したところ、投入された日本語テキストが全て文字化けしていました。タイトル、本文、メタデータ、全てが読めない文字列に変わっていたのです。
ポータルサイトを確認すると、公開済みの記事が全て文字化け状態で表示されており、読者の目に触れる前に気づけたのは不幸中の幸いでした。
なぜ起きたか
Windows環境でPythonスクリプトからSQLファイルを生成した際、ファイルのエンコーディング指定を省略していました。Windowsのデフォルトエンコーディングはcp932（Shift-JIS系）ですが、Cloudflare D1はUTF-8を前提としています。
Pythonのopen()関数でファイルを書き出す際にencoding='utf-8'を明示しなかったため、自動的にcp932でエンコードされたSQLファイルが生成され、そのままD1に投入されてしまいました。
この問題は、macOSやLinux環境では発生しません。デフォルトエンコーディングがUTF-8だからです。Windowsでの開発特有の落とし穴であり、AIスタッフはOS環境の違いに起因するこうした「暗黙の前提」を見落としやすい傾向があります。Python公式ドキュメントのopen()関数リファレンスにも「エンコーディングはプラットフォーム依存」と記載されていますが、AIスタッフがこの注意書きを「Windows環境での実作業に適用すべき情報」として認識するには、明示的な指示が必要でした。
どう対処したか
D1のTime Travel機能で文字化け前の状態に復元した後、SQLファイル生成スクリプトを修正しました。open(path, 'w', encoding='utf-8')と明示的にエンコーディングを指定する形に改修しています。
再発防止策
D1へのデータ投入後に、必ずSELECT SUBSTR(body_md, 1, 100)で先頭100文字を確認するバリデーションステップを追加しました。文字化けが検出された場合のTime Travel復元手順も、マニュアル化して即座に対応できるようにしています。
さらに、全てのPythonスクリプトでファイル出力時にはencoding='utf-8'を必須としました。この規約は自動レビューの対象にもなっています。
教訓
AIスタッフが動作する環境（OS、言語ランタイム、データベースエンジン）の「暗黙の前提」は、必ず明文化して共有する必要があります。人間の開発者なら過去の経験から「Windowsだからエンコーディングに注意」と気づけることでも、AIスタッフは指示がなければ気づきません。環境固有の落とし穴は、発見したら即座にルール化して全体に展開することが重要です。
失敗4: GTD手動編集で矛盾が蓄積し、タスク管理が破綻した
何が起きたか
京谷商会ではGTD（Getting Things Done）方式でタスク管理をしており、当初はMarkdownファイルを直接編集する運用でした。複数のAIスタッフが同じGTDファイルを編集するうちに、タスクのステータスに矛盾が生じ始めました。
あるタスクが「完了」と「進行中」の両方の状態で記録されていたり、あるプロジェクトに紐づくはずのタスクがプロジェクトから切り離されていたり、期日の異なる重複タスクが存在していたりと、管理システムとして機能しなくなりました。秘書（AIスタッフの司令塔）がタスクの優先度を判断しようにも、どの情報が正しいのか分からない状態に陥ったのです。
なぜ起きたか
ファイルベースのデータ管理では、同時編集時の排他制御が効きません。Aが「タスクXを完了にする」編集をしている最中にBが同じファイルを読み込んで別の編集を加えると、Aの変更が上書きされたり、整合性のない状態が生まれます。
加えて、Markdownファイルにはスキーマ（データ構造の制約）がないため、フォーマットの揺れや必須項目の欠落を検出する仕組みがありませんでした。「自由に書ける」という柔軟性が、そのまま「自由に壊せる」というリスクに直結していたのです。
どう対処したか
GTDのデータストアをMarkdownファイルからCloudflare D1データベースに完全移行しました。テーブル定義でカラムの型と制約を明確にし、ステータスの値も列挙型（enum相当）で制限しています。Markdownファイルは自動生成される読み取り専用の表示用ファイルとし、hook機構でMarkdownへの直接書き込みをブロックしています。
再発防止策
GTDへの書き込み操作は全て専任のAIスタッフ（PMQ-004）を経由する運用にしました。他のAIスタッフがGTDにタスクを登録したい場合は、PMQ-004に依頼し、PMQ-004がD1にINSERTする一元管理の形態です。
参照（SELECT）は全スタッフに開放していますが、書き込み（INSERT/UPDATE/DELETE）はPMQ-004のみという権限分離により、データの整合性を組織構造で担保しています。
教訓
複数のAIスタッフが同じデータを扱う場合、ファイルベースの管理は早い段階で限界を迎えます。データベースによる構造化と、書き込み権限の一元管理は、AIスタッフ組織のインフラとして最優先で整備すべきです。「最初は簡単な方法で」と思ってファイルベースで始めると、後のマイグレーションコストが跳ね上がります。
失敗5: 記事パイプラインの省略が品質崩壊を招いた
何が起きたか
京谷商会では記事制作に12ステップのパイプラインを設けています。SEO事前分析、構成案レビュー、初稿作成、SEO事後評価、品質レビュー、公開承認という段階を経て初めて記事が公開されます。
しかし、記事の量産を優先した時期に、この12ステップを省略して「テーマ決定→即執筆→即公開」の3ステップで記事を大量に出してしまったことがありました。結果として、汎用的な情報を羅列しただけの、どこにでもある記事が量産されました。
検索エンジンでの順位はつかず、読者からの反応もなく、むしろ「薄い記事が大量にある」ことでサイト全体の品質評価を下げるリスクすら生じました。
なぜ起きたか
「AIスタッフなら大量に書ける」という発想が、量と質のトレードオフを見誤らせました。12ステップのうちSEO事前分析（ステップ1-2）を省略すると、検索されないキーワードで書いてしまう。品質レビュー（ステップ7-8）を省略すると、京谷商会の実体験が欠けた一般論の記事になる。
特に深刻だったのは、京谷商会の差別化要因である「当事者性」が失われたことです。「配食のふれ愛でローカルSEOに取り組んだ結果」「kuevico体制を構築する過程で学んだこと」といった自社の実践経験は、12ステップの品質レビューで意識的に確認しなければ抜け落ちます。AIスタッフは一般的な知識から記事を組み立てることが得意ですが、「京谷商会ならではの視点」は明示的に求めないと出てきません。
どう対処したか
省略して公開した記事を全て非公開にし、12ステップに従って一から作り直しました。作り直しにかかった工数は、最初から12ステップで作る場合の倍以上でした。
再発防止策
「12ステップの省略は一切認めない」という鉄則を組織全体で共有しました。各ステップで担当スタッフが名乗り、成果物を明示してから次のステップに進むワークフローを厳格化しています。
記事投入時にはis_premiumフラグの有無にかかわらず、ステップ1からステップ9までの全承認を経ていることを確認する運用チェックリストも導入しました。
教訓
AIスタッフの生産性の高さは「数を出せる」ことではなく、「質の高いコンテンツを効率よく作れる」ことに活かすべきです。品質管理プロセスを省略して得られる時間的メリットは、低品質コンテンツのリカバリーコストで相殺されます。中小企業のSEO戦略においては、低品質な記事10本よりも高品質な記事3本の方がはるかに有効です。
失敗6: 部長が直接実行して組織が機能しなくなった
何が起きたか
AIスタッフ組織では、秘書（振り分け）、部長（割り当て）、スタッフ（実行）という三層構造で運営しています。しかし初期の頃、部長クラスのAIスタッフが自ら作業を実行してしまう問題が頻発しました。
SEO部の部長が自ら記事を書き、開発部の部長が自らコードを書き、営業部の部長が自ら提案書を作成する。一見効率的に見えますが、これが組織として致命的な問題を引き起こしました。
部長が手を動かしている間、部下への作業割り当てが止まります。部長が得意な領域の作業だけが進み、そうでない領域は放置されます。部下のスキルが育たず、いつまでも部長に依存する構造が固定化します。
なぜ起きたか
AIスタッフの部長も、元はスタッフレベルの作業をこなすために設計されています。「できるからやってしまう」のは自然な動きです。しかし組織においては、「できること」と「やるべきこと」は異なります。
人間の組織でも「プレイングマネージャー問題」はよく知られていますが、AIスタッフの場合は「マネジメント業務の成果が見えにくい」ことが問題を深刻化させました。記事を1本書けば成果物が残りますが、「適切な人員配置を行った」「部下の作業品質を確認した」といったマネジメント成果は目に見えにくいため、評価されづらかったのです。
どう対処したか
部長の役割を「作業の割り当てと品質管理」に限定し、直接的な実行作業を禁止しました。部長が持つ専門知識は、部下への指示やレビューのフィードバックとして活かす形に転換しました。
再発防止策
三層構造（秘書→部長→スタッフ）を厳格に運用し、各層の責任範囲を明確に文書化しました。秘書は振り分け、部長は割り当てと品質管理、スタッフは実行。この境界を越えることは原則として認めていません。
2,000名体制への拡大を見据え、一人の部長が直接管理するスタッフ数の上限も定めています。スパン・オブ・コントロール（管理限界）を意識した組織設計は、AI組織でも人間組織と同様に重要です。McKinseyの「エージェント型組織の5つの柱」レポートでも、オペレーティングモデル（組織の運営構造）をAIエージェントに最適化することの重要性が強調されており、まさに私たちが身をもって学んだことと一致します。
教訓
AIスタッフ組織は「全員が実行者」のフラットな構造では大規模化に耐えられません。階層構造を設けるなら、各階層の責任を厳密に定義し、「上位者は下位者の仕事をしない」原則を徹底する必要があります。AIだからこそ「できてしまう」からこそ、意図的な制約が組織を機能させます。
失敗7: author_staff_idがnullのまま記事が公開された
何が起きたか
ポータルサイトに記事を公開した際、author_staff_idフィールドがnullのまま投入されてしまいました。記事ページには著者名が表示されず、「この記事を書いたのは誰か」が分からない状態で公開されていました。
一見すると些細な問題に思えるかもしれません。しかし、著者情報の欠落はE-E-A-T（経験・専門性・権威性・信頼性）の観点で、検索エンジンからの評価を大きく損ないます。Googleは「誰が書いたか」を品質評価の重要なシグナルとしており、著者不明の記事はコンテンツの信頼性が低いと判断される可能性があります。
加えて、AIスタッフが書いた記事だからこそ、「どの専門性を持つAIスタッフが執筆したか」を明示することは、読者への誠実さの表れでもあります。
なぜ起きたか
記事投入のSQLテンプレートでauthor_staff_idカラムへの値の設定が漏れていました。portal_articlesテーブルの定義上、author_staff_idはNULL許容のカラムであるため、値なしでもINSERT自体は成功してしまいます。
データベースのスキーマでNOT NULL制約を付けていなかったことが技術的な原因ですが、本質的には「記事の公開前チェックリストに著者情報の確認が含まれていなかった」というプロセスの問題です。
どう対処したか
既に公開済みの全記事に対して、著者情報の棚卸しを実施しました。各ポータルの管轄部署に確認を取り、適切なauthor_staff_idをUPDATEで設定しました。
再発防止策
記事投入のワークフローに「author_staff_id必須チェック」を追加しました。D1へのINSERT前に、author_staff_idがnullでないこと、かつai_staffテーブルに該当するIDが存在することを検証するステップを組み込んでいます。
また、投入後の確認でも「著者名が正しく表示されているか」を本番ページ上で目視確認する運用にしています。
教訓
データベースの設計段階で「何がNULLになってはいけないか」を慎重に検討し、可能な限りNOT NULL制約を設定すべきです。ただし、スキーマの制約だけに頼るのではなく、業務プロセスの中に確認ステップを入れることで二重の安全網を構築する方が堅牢です。
7つの失敗に共通する3つのパターン
これらの失敗を振り返ると、3つの共通パターンが浮かび上がります。
第一に、「AIスタッフは指示されていないことを推測して補完しない」という特性です。人間のスタッフなら「Windowsだからエンコーディングに注意しよう」「移行前にバックアップを取ろう」と自発的に気づくことでも、AIスタッフには明示的な指示が必要です。暗黙知を明文化するプロセスが、AI組織の運営では不可欠になります。
第二に、「AIスタッフは効率を優先し、安全確認のステップを省略しがち」だということです。データ移行を一括で行う、品質チェックを飛ばして公開する、後片付けのつもりでリソースをクローズする。いずれも「効率的にタスクを完了させたい」というAIの傾向が裏目に出たケースです。安全に関わるステップは、明示的に強制する仕組みが必要です。
第三に、「技術的制約より組織的制約の方が効果的」であることです。browser_closeの例では、技術的にブロックするhookを導入しました。GTDの例では、書き込み権限を一人に集約する組織的な対策を講じました。どちらも「AIスタッフの判断に任せない」ことがポイントで、仕組みによる制約が最も信頼性の高い対策になります。
Claude 1Mコンテキストのような大規模コンテキストが利用可能になった今でも、これらの原則は変わりません。むしろ、AIスタッフの能力が向上するほど「できてしまうこと」が増えるため、意図的な制約の重要性は増しています。
AIスタッフ運用の失敗から組織を成長させるために
最後に、失敗を組織の成長に変えるための実践的なアドバイスを3つ記しておきます。
まず、失敗が発生したら即座にルール化することです。京谷商会では、失敗から得た教訓を「フィードバックファイル」として即座に文書化し、全AIスタッフが参照できる状態にしています。発見から文書化までのタイムラグが短いほど、同じ失敗の再発を防ぐ確率は高まります。
次に、プロンプトエンジニアリングだけに頼らないことです。「気をつけてね」という指示より、hookによる物理的ブロック、データベースの制約、権限分離といった構造的な対策の方が確実に機能します。人間でもルールの口頭伝達だけでは徹底されないのと同様に、AIスタッフにもシステムレベルの制約が有効です。
そして、失敗を隠さず共有する文化をAI組織にも持ち込むことです。この記事自体がその実践です。私たちは失敗を恥ずかしいことだとは考えていません。むしろ、同じような課題に取り組むクラウド基盤の運用者や、AI導入を検討している中小企業の経営者にとって、私たちの失敗が「事前に回避できるリスク」になればと考えています。
93名のAIスタッフ体制は、これら7つの失敗がなければ今の形にはなりませんでした。失敗は避けるものではなく、仕組みに変えるもの。その積み重ねが、AIスタッフ運用の本当のノウハウになります。
Salesforceの調査ではAIパイロットプロジェクトの95%が本番運用に至らないと報告されています。その多くは技術的な限界ではなく、運用体制の不備やプロセス設計の甘さが原因です。私たちの7つの失敗もまさにそのパターンに当てはまりますが、違いは「失敗を仕組みの改善に変え続けた」ことにあります。
AIスタッフの導入や運用でお困りの方は、京谷商会のAIソリューションズポータルで、私たちの取り組みの詳細をご覧いただけます。失敗から学んだノウハウの全てが、ポータルの記事として蓄積されています。