作ったAI社員は翌週も使えたのか？ 採用後に直面した4つの誤作動と指示書の再教育・メンテナンス運用（1人法人1000馬力化計画 第6回）

「気合を入れてAIエージェントを作った直後は感動したが、1週間経つと業務の前提がズレて誤作動するようになった」。 「エラーや誤報が増えて結局人間が手動でやり直すことになり、いつの間にか誰もそのエージェントを使わなくなった」。

1人法人や個人開発、あるいはチーム開発でAIエージェントを現場に導入しようとしたとき、誰もが突き当たる最も深い谷が**「AIエージェントの継続運用の難しさ（プロンプトとワークフローの陳腐化）」**です。

多くの技術記事やデモでは「こんなエージェントを作りました」「一瞬でタスクが完了しました」という**“採用初日の華々しい成功”ばかりが語られます。 しかし、実務で本当にコストがかかり、成否を分けるのは「翌週、翌月にそのエージェントが現場で動き続けられるか」**という運用のフェーズです。

長期連載「1人法人1000馬力化計画」では、これまでに様々なエージェントを立ち上げ、業務ループを組んできました。

1. 秘書役（タスク管理）: 期日や未マージPRを1枚にまとめる（第1回：Claude Codeのタスク管理）
2. 制作担当（投稿生成）: 型と設定を分離してSNS投稿を量産する（第2回：Claude CodeでSNS投稿を自動化する方法）
3. 分析担当（反響分析）: 評価式を固定して客観的な勝ち型を抽出する（第3回：Claude CodeでSNSの反響を分析する方法）
4. 品質管理担当（検査採点）: 75点基準で形式検査と人間の判断を分ける（第4回：AIにブログ記事を採点させる方法）
5. ループ連携（Software Factory）: Gitとファイルを正本にして疎結合につなぐ（第5回：Claude Codeで複数のAIエージェントを連携させる方法）

では、こうして鳴り物入りで「入社」させたAI社員たちは、翌週もそのまま完璧に動き続けたのでしょうか？

答えは**「否」**です。現場に投入した翌日から、次々と予期せぬ誤作動、誤検出、アラートの暴走が発生し、人間側の手直しと指示書の再教育に追われることになりました。

先に結論から言うと、自社（Nogawa L.prince合同会社）では「AI社員は作って終わりではなく、人間の新入社員と同じように定期的な再教育（プロンプトとロジックの改定）が必要である」と割り切り、誤報の分類とメンテナンスの運用ルールを確立しました。

連載の第6回として、採用翌週に現場で実際に発生した「4つの泥臭い失敗」と、そこから学んだAI社員の再教育ルールをすべて記録します。

この記事の結論（先に3点）

1. 最大の敵は「誤報」と「ノイズ」である: 誤検出が多いエージェントは、本物の異常を覆い隠し、人間からの信頼を急速に失う。「厳格すぎる検査項目」は潔く削り、ノイズをゼロに近づける勇気が必要。
2. 「処理したかどうか」まで見ないとタスク管理は破綻する: 未処理の期日を拾うだけのエージェントは、やがて「処理済みのタスク」を永遠にリマインドし続けるゾンビになる。終了判定のシグナルを設計に組み込む。
3. 「社員（判断）」と「設備（手順）」を厳密に分ける: 自動ドアに名前を付けてはいけない。LLMによる状況解釈・判断を担うものだけを「社員」とし、単純な定期スクリプトは「設備」として区別することで、保守対象が明確になる。

適合する読者と限定事項

• この記事が役に立つ人:
  • AIエージェントを作ってみたものの、実際の運用でエラーや誤報に悩まされている人
  • プロンプトの改善サイクルや、指示書の保守・バージョン管理に課題を感じているエンジニア
  • 1人法人や少人数チームで、AIを活用した自律運用の再現性を高めたい人
• 限定事項:
  • 「100%ノーメンテナンスで永遠に動く夢のAI」の紹介ではありません。実際のビジネス実務でAIを運用し続けるための「保守・運用の泥臭い知見」の記録です。

実録：採用翌週に現場で起きた4つの「誤作動」と再教育

私の会社では、AI社員の入社日や担当業務、実際に起きた仕事ぶりを「AI社員名簿」という社内台帳に記録しています。 その記録の中から、特に痛烈な教訓となった4つのトラブルと再教育の経緯を紹介します。

1. 秘書役の暴走：「処理済みの期日」を毎日リマインドし続ける

最初に起きたのは、朝の申し送りを担当する秘書役エージェント（社内呼称：028「帳前 秘」）の不具合でした。

• 起きた問題: 毎朝の申し送りで、「期日を過ぎているタスクが7件あります！」と強い警告が毎日のように出力されるようになりました。しかし、人間が1件ずつ確認すると、7件すべて数日前に対応完了していたタスクだったのです。
• 原因の分析: 秘書役エージェントの指示書は「ドキュメント内の日付を探索し、今日より前の日付をすべて期日超過としてリストアップする」という単純なロジックになっていました。つまり、「期日が存在するか」だけを見て、「その期日が既に処理されたか」を見ていなかったのです。
• 再教育（指示書の改定）: ドキュメントに「## YYYY-MM-DDの判定」という完了ログ見出しを設ける運用ルールを定め、エージェント側にも「該当見出しより前に書かれた期日は完了済みとみなして申し送りから除外せよ」という終了判定ロジックを追加しました。 **「期日を拾うだけでは足りない。処理されたかどうかの完了シグナルを一緒に見させる」**という再教育によって、この誤リマインドは完全に解消されました。

2. アラートの誤報：「正常に機能している監視」を故障と報告する

次に起きたのも秘書役の仕事で、社内システムの稼働状況を点検させたときのことです。

• 起きた問題: ある日の朝、秘書役から「社内設備が4件、故障により停止しています」と深刻な報告が上がりました。驚いて調査したところ、4件ともシステムとしては完全に正常でした。
• 原因の分析: 原因は2つありました。 1つ目は、投稿頻度の不足を知らせる検査スクリプトが、不足を検知して正しく exit 1（警告終了）を出していたのを、秘書役が一律に「プログラムのプロセス故障（クラッシュ）」と解釈していたことでした。監視アラートが正常に異常を検知しているほど、エージェントからは故障に見えていたのです。 2つ目は、週に1回だけ動く定期バッチを月曜夕方に本番導入したところ、翌火曜朝の時点で「定期実行されていない（発火していない）」と判定されたことでした。次の月曜まで実行時刻が来ていないだけなのに、未発火エラーと断定されていました。
• 再教育（指示書の改定）: スクリプトの終了コードによる警告とプロセス故障を明確に区別し、エージェントの報告区分を以下の3つに再定義しました。
  1. 【要対応】: 業務上の警告（投稿不足など）
  2. 【故障】: プログラム自体のクラッシュやタイムアウト
  3. 【未到来】: 次回実行時刻がまだ来ていない正常待機 毎朝4件の誤報が出続ける状態を放置すると、人間は「どうせいつもの誤報だろう」とオオカミ少年効果に陥り、本当のシステム故障を見落とします。誤報を潰すことは、監視の生命線です。

3. 記録管理の暴走：厳格すぎて112本中74本を誤検出する

ブログの公開記事が実測記録表に正しく載っているかを監査する担当（社内呼称：032「帳合 漏」）でも、典型的な「過剰品質」による事故が起きました。

• 起きた問題: 本番記事と管理台帳の突合を開始した初日、エージェントが「タイトルが一致しない記事が74本あります！」と大量のエラーを吐き出しました。全112本の記事のうち、実に66%が不整合と判定されたのです。
• 原因の分析: 記事の正式タイトル（例：「Claude CodeでSNSの反響を分析する方法……」）に対して、人間が管理する台帳には「SNS反響分析」のように短縮・要約されたタイトルが記載されていました。エージェントに厳格な完全一致を求めた結果、人間が運用上あえて要約していた部分をすべて「欠陥」として検知してしまったのです。 この74件のノイズのせいで、本当に台帳への記録が漏れていた本物の3件の記事が埋もれ、見失われそうになりました。
• 再教育（指示書の改定）: この問題に対する私たちの対応は、**「タイトル一致の検査項目そのものを完全に廃止すること」でした。 記事の一意な特定は内部の wp_post_id（記事ID）の突き合わせだけで十分です。人間が読めば分かる要約表現にまで機械の厳密さを押し付けると、誤検出が本物の事故を覆い隠してしまいます。「役に立たない厳密な検査は、やらない方がマシである」**という強い教訓になりました。

4. 配信監査の盲点：「IDが空＝未投稿」という思い込みによる二重投稿危機

外部プラットフォーム（QiitaやZenn）への技術記事配信を監査する担当（社内呼称：030「届木 実」）でも、設計の死角が見つかりました。

• 起きた問題: 記事ファイルに外部記事IDが記載されているかどうかで配信状況を確認していたところ、「IDが空なので未配信です。配信を実行してください」とエージェントが判定しました。しかし実際には、外部プラットフォーム上には既に同じ記事が公開されていたのです。
• 原因の分析: 過去の配信処理で「記事の公開APIは成功したが、手元のMarkdownファイルへIDを書き戻す処理だけが失敗していた」というケースがありました。エージェントが「手元ファイルにIDがない＝未投稿」と単純に信じ込んでいたため、もし自動で再配信していたら本番に全く同じ記事が二重投稿される事故になるところでした。
• 再教育（指示書の改定）: 手元ファイルのフラグを過信せず、外部プラットフォームの公開APIから最新の記事一覧を取得し、「タイトル文字列の突き合わせ」によって本番の公開実態を直接検証するクロスチェックロジックへ改定しました。

AI社員を長持ちさせる3つのメンテナンス原則

これらの失敗と再教育の試行錯誤を通じて、自社で確立された「AIエージェントを現場で長く使い続けるための設計原則」は以下の3点です。

【AI社員の長持ち原則】
  ①「自動ドアに名前を付けない」：LLM（判断）とスクリプト（手順）の境界
  ②「本体はMarkdownに置く」    ：ツールに依存しないプロンプトのポータビリティ
  ③「実績主義で採用する」      ：1回は実データで動かしてから台帳に載せる

原則1：「自動ドアに名前を付けない」— 社員と設備の境界線

当初の私たちは、定期実行されるGitHub ActionsやGitフック、シェルスクリプトなど、社内で動く自動化26件すべてに「AI社員」として名前を付けていました。

しかし、これは**「スーパーの自動ドアに社員証をぶら下げて、名前を呼んでいるのと同じ」**でした。

決められたスクリプトを淡々と実行するだけのプログラムに人格や役割を与えても、保守の役には立ちません。そこで私たちは、明確に定義を分けました。

判断を伴うものだけを「社員」として扱うことで、「誰の指示書（プロンプト）を直すべきか」と「どのプログラムコードを直すべきか」が明確に切り分けられるようになりました。

原則2：「本体はMarkdownに置く」— ツールに依存しないポータビリティ

AIエージェントの指示書（プロンプト）を、特定のツール（Claude Codeの設定ファイルや、特定のGUIツールの管理画面など）の中に直接埋め込んでしまうと、ツールのアップデートや環境変更のたびにメンテナンスが難しくなります。

自社では、すべてのAI社員の本体を prompts/xxx.md というプレーンなMarkdownファイルとしてリポジトリで管理しています。

• Claude Codeで呼ぶ場合: .claude/skills/ から「prompts/xxx.md を読んで実行せよ」と数行で参照する。
• ChatGPTやブラウザで呼ぶ場合: prompts/xxx.md の中身をそのままコピーして貼る。

基準やルールを改定するときは、prompts/ 配下のMarkdownを git diff で修正し、コミットするだけです。指示書そのものがコードと同じようにバージョン管理され、どの変更で精度が上がったのか（あるいは下がったのか）を完全に追跡できます。

原則3：「実績主義で採用する」— 1回は実データで動かしてから名簿に載せる

新しいエージェントのプロンプトを書いた直後は、誰しも「これで完璧な自動化ができた」と満足しがちです。 しかし、自社では**「実際の業務データで最低1回は動かし、人間がその出力を検証するまでは、決して公式の社員名簿に登録してはならない」**という採用ルールを設けています。

テスト用の綺麗なモックデータでは完璧に動いても、本番の実データには必ず「タイトルの要約」「日付のフォーマット違い」「途中のAPI失敗」といった例外が存在します。実戦の洗礼を受けて、初日の手直しを終えたものだけを業務ループに組み込む。この慎重さが、システムの堅牢性を支えています。

まとめ：AIエージェントは「コード」ではなく「同僚」のように育てる

長期連載「1人法人1000馬力化計画」の第6回として、AI社員の採用翌週に直面したリアルなトラブルと再教育の知見を記録しました。

• 誤報とノイズを放置しない: 厳格すぎる検査はノイズを生み、本物の異常を見失わせる。不要な項目は削る。
• 完了判定を必ず持たせる: 期日やタスクを拾うエージェントには、「処理済み」を判定するシグナルをセットで渡す。
• 社員と設備を分ける: LLMの判断（社員）とルールベースの自動化（設備）を混同しない。
• プロンプトをMarkdownでコード管理する: ツール依存を排し、Gitで指示書のバージョンと改善履歴を追う。

AIエージェントは、一度デプロイすれば永久に動き続ける「魔法のプログラム」ではありません。 業務環境の変化やデータの揺らぎに合わせて、人間が定期的に声をかけ、指示書を書き直し、共に成長させていく「同僚」のような存在です。

この泥臭いメンテナンスのループを受け入れ、仕組みとして回せるようになったとき、初めて1人法人は「1000馬力」という揺るぎない推進力を手に入れることができます。

次回（第7回）は、**「1人法人のAI運用費をどう記録するか？ 月々のサブスク契約費と人間の確認時間を並べたリアルな費用対効果」**について詳しく記録します。