AI社員の育て方
AI社員の育て方 / 第11章: 放っておいても動く仕組みを作る

第11章: 放っておいても動く仕組みを作る

同じ問題が、4回起きました。

CC Company（シーシーカンパニー）では毎日、文字起こしデータの整理やアクセス解析データの収集といった繰り返し作業をAI社員に任せています。これらの定期タスクには「最後に実行した日時」を記録するファイルがあり、次の起動時に「前回からどれくらい経っているか」をチェックする仕組みにしていました。

問題は、タスクを実行した後に「完了した」という記録を更新し忘れることでした。AI社員がタスクを実行する。成果物はちゃんとできている。しかし「実行しました」という状態ファイルの更新を忘れる。翌朝起動すると「このタスク、24時間超過しています」と警告が出る。実際には終わっているのに。

1回目は「あ、忘れてた」で済みました。2回目は「また忘れた。次は気をつけよう」と思いました。3回目、同じ警告が出たとき、ようやく気づきました。これは「気をつける」で解決する問題ではない。

第3章で学んだContext Rot（コンテキストロット：文脈の腐食。長い会話の途中でAI社員が初期の指示を忘れてしまう現象）が、まさにここで起きていたのです。タスクの実行手順は覚えている。しかし「実行後に状態ファイルを更新する」という付随作業が、会話が長くなるにつれて抜け落ちる。AI社員の記憶に頼っている限り、この問題は何度でも再発します。

4回目の再発を機に、状態ファイルの更新を専用のスクリプトに組み込みました。タスク名を渡すと、対応する状態ファイルのパスを自動で特定して更新する。AI社員が覚えている必要はなくなり、「このコマンドを実行すれば完了」という1アクションに集約されました。

3回再発したら、それは仕組みがない証拠です。 「気をつけよう」は対策ではありません。記憶に頼ることをやめ、仕組みで回す。この原則は、本章で扱う「自動化」のすべてに通じる考え方です。

あなたの現在地を確認する

3つ以上チェックが付いた方: 自動化の土台ができています。この章で「壊れたときに戻す」仕組みを確認しましょう。

1〜2個の方: 繰り返し作業は認識しているが、自動化はまだ。この章で「何から自動化するか」の優先順位が明確になります。

チェックがゼロの方: すべてが手動の状態です。この章を読めば、「自動化すべき作業」と「人間がやるべき作業」の線引きができるようになります。

毎日やることを、人間が覚えている限界

ある週のことです。水曜と木曜の2日連続でアクセス解析データの収集を忘れました。金曜にデータ分析をしようとして気づいたときには、水曜・木曜のデータが穴あきになっていました。「今週のどの記事が伸びたか」が正確に分からず、その週の分析は使い物にならなかった。

恥ずかしいことに、忘れた理由は「忙しかったから」ではなく、「やったつもりになっていたから」でした。毎日やることが増えると、頭の中で完了マークを付けてしまう。実際にはやっていないのに。

川島さんにも似たような経験がありました。毎朝手動でやっていた「前日の問い合わせメール件数の集計」が悩みの種だったそうです。3日連続で集計を忘れた週があり、上司から「先週の問い合わせ件数が分からないと会議で報告できない」と指摘された。忘れないようにとモニターに付箋を貼ったものの、付箋自体が風景になってしまい、また忘れる。

この「やったつもり」問題は、マッキンゼー（McKinsey）の調査（2023年）でも指摘されています。定型的な反復業務は、自動化によって人的ミス（作業忘れ、入力間違い、手順の飛ばし）を平均で60〜70%削減できるとされています。つまり、人間が毎日同じことを繰り返す限り、忘れや間違いは避けられない。これは意志の問題ではなく、人間の認知の限界です。

AI社員の育成が進むと、次に直面するのがまさにこの「毎日の繰り返し作業」の問題です。毎朝の文字起こしデータ整理、毎日の記事インデックス更新、毎晩のアクセス解析データ収集。どれも重要ですが、人間がトリガーになっている限り、仕組みは人間の体調やスケジュールに依存します。

「自動化」と聞くと、プログラミングが必要だと思うかもしれません。川島さんも最初は「私には無理です」と言っていました。しかし実際にやったことは、「毎朝9時にこの作業をやって」とAI社員にスケジュールを設定しただけです。設定に10分。効果は毎朝5分の節約と「やり忘れゼロ」。技術的な知識はほぼ不要でした。

「完璧な自動化」を目指して、止まった

CC Companyの初期に、文字起こしデータの自動整理パイプライン（データを自動的に加工・転送する一連の処理の流れ）をローカルPC上に構築しました。指定した時刻に自動でプログラムを動かす仕組み（cron（クロン）と呼ばれます）を使い、「毎朝9時に実行」と設定しました。

数日間は快調でした。ある晩、PCをシャットダウンして帰宅。翌朝、パイプラインが止まっている。当然です。PCの電源が入っていなければ、時刻指定の自動実行は動きません。さらにGoogle Workspace（グーグルワークスペース）の認証が期限切れ。再認証したら、今度はライブラリの自動更新でエラー。「電源を入れ直すだけ」では復旧せず、原因調査と対策で数十分を持っていかれました。

自動化の仕組みが止まったとき、一番困るのは「止まっていることに気づかない」ことです。ここが家電のタイマーと決定的に違う。炊飯器のタイマーは、電源を抜けば炊けていないことが一目で分かります。しかしデータ処理のパイプラインは、止まっていても画面に何も表示されない。データが「ない」ことに気づくのは、そのデータを使おうとした時です。冒頭のアクセス解析2日忘れと同じ構造です。

この経験から、2つのことを学びました。

1つ目は、「理想の環境が整うまで手動で頑張る」は本末転倒だということ。理想はクラウド上で決まった時刻に自動実行する仕組みです。しかし、クラウド環境の構築にも時間がかかります。「完璧な自動化」を待つより、今の環境でできる現実的な方法で始める方が、結果的に早くゴールにたどり着きます。

2つ目は、「実行する仕組み」と「止まったことを検知する仕組み」は別物だということ。cronは「実行する」仕組みですが、「止まったことを教えてくれる」仕組みではありません。この気づきが、次のセクションで紹介する「起動ルーティン」のきっかけになりました。

「おはよう」で全部チェックする

cronをやめた後、CC Companyでは「起動ルーティン」方式に切り替えました。AI社員との対話を始めるたびに、定時ジョブの実行漏れチェック、タスク一覧の更新、メールの確認、投稿スケジュールの確認がまとめて走る仕組みです。

AI社員に「おはよう」と声をかけると、こんな報告が返ってきます。

定期タスクチェック: email-to-task（44時間超過）、supervisor-check（56時間超過）
投稿カレンダー: 今日は投稿日です（#23「文体設計3ステップ」）
ストック水位: 7本（目標達成）

PCの電源が入っていなかった時間は関係ありません。次に起動したときに「何時間分の遅れがあるか」を検知し、まとめて補完する。完璧な時刻指定よりも、「漏れたら気づく」仕組みの方が、実際の運用では堅牢でした。

当初、起動ルーティンには7つのステップがありました。定期タスクのチェック、メールの確認、タスクリストの棚卸し、投稿カレンダーの確認、コスト削減レポート、成長戦略の確認、未完了タスクの督促。全部実行すると起動に数分かかる。毎朝数分の待ち時間は、意外とストレスになります。

そこで「チェックだけして、実行は後回し」に設計を変えました。起動時にやるのは「何が遅れているか」の確認だけ。遅れているタスクはTODOリストに登録し、実行するタイミングはオーナーが決める。この最適化で起動ルーティンは3ステップに集約され、1秒以内で完了するようになりました。

「毎朝のルーティンが重すぎて省略したくなる」のは、人間の組織でもよくある話です。朝礼が長い会社では、そのうち誰も聞かなくなります。自動化も同じで、軽くて速いからこそ毎回実行される。自動化は「やる」だけでなく「続けられる」設計が必要です。

AI社員がファイルを壊した日

ある朝、記事の品質チェックが通らなくなりました。昨日まで合格していた記事が、同じ基準で不合格になる。AI社員に聞いても「基準通りにチェックしています」と答えるだけ。

原因を探ると、品質チェックのルールが書かれたファイルが変わっていました。AI社員がマニュアルを編集した際に、既存のルールの一部を上書きしてしまっていたのです。品質チェックの項目が丸ごと消えていたのですが、気づいたのは翌日です。

もしファイルの変更履歴を記録していなかったら、「何が消えたか」すら分からなかったでしょう。しかしCC Companyではすべてのファイルの変更をバージョン管理ツール（Git（ギット）と呼ばれます）で記録していました。変更箇所の差分を表示し、消えた箇所を特定し、1つのコマンドで復旧できました。

バージョン管理は、ノートの各ページに日付と変更内容を記録していくようなものです。1ページ目に「3月20日: チェック項目を10個に設定」、2ページ目に「3月22日: 項目3を修正」、3ページ目に「3月23日: 項目5〜7が消えた」。どのページに戻せばいいか、履歴を見れば一目瞭然です。

「失敗しても元に戻せる」と分かっているからこそ、新しい指示書を試したり、自動化の範囲を広げたりといった挑戦ができます。AI社員はファイルを壊す可能性がある存在です。だからこそ、バージョン管理は「あると便利」ではなく「なければ危険」な仕組みです。

もう一つ、変更のたびに記録する一行の説明文（コミットメッセージと呼ばれます）が、思わぬ形で役立ちます。ある週、記事の品質スコアが突然下がりました。コミット履歴をさかのぼると、3日前に手順書の合格基準を変更していたことが分かった。変更の意図は正しかったのですが、副作用で別のチェック項目が機能しなくなっていたのです。履歴がなければ、原因の特定に何時間もかかっていたはずです。

川島さんの場合も、AI社員が自動集計した月末レポートの数字が前月と合わないことがありました。変更履歴を遡ると、月の途中で集計の条件式をAI社員が「最適化」していたことが分かりました。悪意があったわけではなく、AI社員なりに改善を試みた結果です。しかし、その変更が意図通りかどうかを判断するのは人間の仕事です。履歴があったからこそ、「いつから数字がズレたか」を特定し、正しい状態に戻せました。

「終わったはず」が終わっていない問題

自動化が進むと、AI社員が扱うタスクの数が増えます。すると次に起きるのが、「タスクが終わったはずなのに、終わっていない」問題です。

CC Companyでは、Google Tasks（グーグルタスクス）を使ってTODO管理を一元化しています。AI社員がタスクの作成・更新・完了を行い、人間はタスクリストを確認するだけで状況を把握できる。そういう設計でした。

しかし、実際に運用を始めると、AI社員が作業を完了してもタスク管理ツール側のステータスが更新されないまま残ることがありました。チェックリスト上は完了しているのに、Google Tasksでは「未完了」のまま。翌朝の起動ルーティンで「このタスク、まだ終わっていませんよ」と報告される。確認すると、もう終わっている。

この「嘘の未完了報告」が毎朝のように起きると、そのうち報告自体を信用しなくなります。 これが一番怖い。「どうせまた嘘でしょ」と思い始めたら、本当に未完了のタスクも見落とすようになる。火災報知器が誤作動ばかりしていると、本当の火事のときに誰も避難しなくなるのと同じです。

原因を調べると、構造的な問題でした。AI社員の作業手順の中に「Google Tasksのステータスを更新する」というステップが含まれていなかったのです。成果物を保存し、レビューログを書き、品質チェックを通す。そこまでは手順書に書いてある。しかし「タスク管理ツールを更新する」は書かれていなかった。

対策として、タスクの完了処理をワークフローの中に組み込みました。「成果物を保存する」「レビューログを書く」「タスク管理ツールを更新する」をひとつの完了手順としてセットにし、どれか1つでも欠けていれば完了とみなさないルールにしたのです。この修正を9つの業務手順書に一括で適用しました。個別に「ここも直して、あそこも直して」ではなく、全手順書の完了処理を構造的に統一したのです。

道具が増えると、道具同士の整合性を取る仕組みも必要になる。これは人間の組織でも同じことです。 営業部が案件を受注しても、経理部に請求書発行の連絡が行かなければ、売上は立ちません。AI社員の世界でも、「作業が終わった」と「管理上も終わった」は別のこと。この2つを連動させる仕組みが、道具同士を繋ぐ橋になります。

もう一つ、タスクリストは放っておくと「腐る」ことも学びました。完了済みのタスクが何十件も残っていると、本当に対応が必要なタスクが埋もれます。ある棚卸しでは、5つのリストに37件の未完了タスクが溜まっていました。確認すると、そのうち17件はすでに作業完了済みで、ステータスが更新されていないだけでした。CC Companyでは完了済みタスクの定期削除と、期限切れタスクの自動検出を起動ルーティンに組み込んでいます。タスク管理ツールも、AI社員と同じく「放っておくと劣化する」対象です。

直したはずが、また壊れる

自動化の仕組みが整ってきた頃、もう一つの壁にぶつかりました。冒頭で紹介した「状態ファイル更新忘れ4回再発」の話に戻ります。

自動化とは「実行を自動にする」だけではありません。「壊れたときに元に戻す」ことも自動化する必要があります。

CC Companyでは、毎回のセッション開始時に「監督チェック」を実行しています。定時ジョブの実行漏れだけでなく、以下のような不整合も自動で検出します。

ある日の監督チェックで、全34件のタスクを点検したところ、7件が「品質チェックは合格しているのに、タスクが完了になっていない」状態でした。成果物はある。レビューログもある。しかし「完了」のハンコが押されていない。原因は、完了報告と完了受理のステップが抜けていたことでした。「あの案件どうなった？」と確認しなくても、監督チェックが自動的に宙に浮いたタスクを検出してくれる。

不整合が見つかれば自動修復を試み、自動修復できない問題はオーナーに報告する。自動化を設計するとき、「正常に動くケース」だけでなく「壊れたケース」も想定しておく。 この発想の転換が、「たまに止まる自動化」と「放っておいても回り続ける自動化」の違いを生みます。

コラム: 492,918時間超過と表示された日

ある朝、起動ルーティンを実行したら、こんな表示が出ました。

email-to-task: 492,918時間超過

492,918時間。計算すると約56年分です。CC Companyが56年間メールチェックをサボっていたことになります。

もちろんそんなわけはありません。原因は、定期タスクの「最後に実行した日時」を記録する状態ファイルが初期化されていなかったことでした。ファイルが存在しない場合、チェックスクリプトは「1970年1月1日（コンピュータの時刻の起点）」を基準に経過時間を計算します。その結果が56年分の超過表示です。

笑い話のようですが、ここに自動化の重要な教訓があります。自動化の信頼性は「正常系」だけでなく「初期状態」と「異常系」でも試される。 状態ファイルが存在しないケース、パスが間違っているケース、フォーマットが想定と違うケース。これらを想定しておかないと、56年分の超過表示のような「意味不明なエラー」に振り回されることになります。

実はこの問題にはもう一つ根深い原因がありました。状態ファイルの保存場所が2箇所に分散していたのです。フォルダの引っ越しをした際に参照パスの更新を忘れ、スクリプトが古いパスを見続けていた。ファイルは存在する。しかしスクリプトが見ている場所にはない。だから「ない」と判断されて56年分の超過になる。ファイルの引っ越しのような些細な作業が、自動化の信頼性を根底から壊すことがある。こういう地味な罠が、自動化の本当の難しさです。

LLM（Large Language Model：大規模言語モデル）知識: 自動化のアイロニー

1983年、認知科学者のベインブリッジ（Bainbridge）は「Ironies of Automation」（自動化の皮肉）という論文を発表しました。この論文が指摘した問題は、40年以上経った今も、AI社員の自動化を考える上で重要な示唆を与えてくれます。

ベインブリッジの主張はこうです。自動化を進めるほど、人間の監視能力は低下する。 普段は機械が完璧にやってくれるので、人間は注意を払わなくなる。ところが機械が故障したとき、その異常に気づくべき人間は、もう「正常な状態」を覚えていない。これが「自動化の皮肉」です。

CC Companyでも同じことが起きました。定時ジョブが順調に動いている間は、誰もデータの中身を確認しなくなりました。ある日、アクセス解析のデータが1週間分まるごと空だったことに、週次レビューの段階まで気づかなかった。パイプラインは動いていたのですが、データソース側の仕様変更で空のデータを取得し続けていたのです。

ベインブリッジの提言は、「だから自動化するな」ではありません。「自動化するなら、異常に気づく仕組みも一緒に自動化しろ」です。CC Companyの起動ルーティンや監督チェックは、まさにこの提言の実装です。自動化された仕組みを監視する仕組みを作る。これは過剰な設計ではなく、自動化を成立させるための必要条件です。

この論文は、自動車の自動運転やAI診断支援など、現代のAI活用の議論でも頻繁に引用されています。あなたの会社でAI社員の自動化を進めるとき、「うまく動いているときほど、壊れたときのことを考える」という姿勢を忘れないでください。

（参考文献: Bainbridge, L. (1983). Ironies of Automation. Automatica, 19(6), 775-779.）

規模に応じた実践

自動化の範囲は、組織の規模によって変わります。

個人で始める場合: まずは「毎日やっている作業」を1つだけ自動化してみてください。川島さんがやったように、「毎朝の集計をAI社員に任せる」だけでも効果があります。起動ルーティンも、最初は「昨日のタスクが終わっているかチェック」の1項目だけでOKです。バージョン管理は、「AI社員が触るファイルだけ履歴を取る」から始めましょう。完璧な仕組みを最初から作ろうとすると、CC Companyの初期のように「パイプラインが止まった」で挫折します。

チームで導入する場合: タスク管理ツールとの連携が重要になります。チームメンバーが「このタスクどうなった？」と聞かなくても、タスクリストを見れば分かる状態を作る。ここで本章の「嘘の未完了報告」問題を思い出してください。AI社員がタスクを完了しても管理ツールが更新されない問題は、チーム運用では個人以上に深刻です。必ず完了処理をワークフローに組み込んでください。

組織として展開する場合: 監督チェックの仕組みが必須です。CC Companyでは34件のタスクを自動点検して7件の不整合を検出しました。組織規模でタスク数が増えると、人間の目視確認では見落としが確実に発生します。「正常に動いているか」を自動チェックする仕組みがなければ、自動化の恩恵は規模とともに薄れていきます。

まとめ

自動化の仕組みが動き始めました。しかし、ここで一つ問いかけたいことがあります。AI社員に「何でもかんでも自動化すればいい」わけではありません。次の章では、AI社員に何ができて何ができないのか、その本質的な限界について考えます。