2026年9月12日の状況:実装の担当が軒並み枠切れになった
うちでは日々の業務を手伝うAI秘書の裏側で、複数のAIモデルを役割分担させて動かしています。9月12日の朝、そのうち実装作業に使っている主力の利用枠が、軒並み上限に達しました。1つは3日前の夕方から上限に達したままで、もう1つもこの朝に使い切り、戻るのはその日の夜と3日後の見込みでした。AI秘書はここで「夜まで実装は止まる」と判断しました。
枠切れは初めてではありません。以前から「ほかに使える枠があるなら、それを使って進めること」は何度も言われていました。それでも今回は活かせず、昼過ぎに社内から「使える枠が残っているのに、毎回それを忘れている」と指摘されるまで、6時間近く実装を止めていました。
対応:別レーンへ切り替え、実装と検収を分業した
指摘を受けて確かめると、AI秘書が当時常駐していた枠は、まだ使える状態でした。ほかに候補にした別サービスの実装役2つも、その時点ではどちらも動きませんでした。1つは契約していたプランにつながっておらず、残高の尽きた別の窓口を呼んでいたため(その日の夜につなぎました)、もう1つはこちらから仕事を渡す経路がまだ無かったためです。そこで、たまっていた修正の依頼を常駐の枠に振り分け、複数を並行して進めました。
切り替えから1時間足らずで、最初に検収まで終わったのは次の4件です。別のパソコンで作業を回している自動実行の係が実際には動いているのに、状態の記録だけ「停止」のまま残る不具合。テストを繰り返し実行したとき、失敗の中身を読み取れず、原因の違う失敗を1つにまとめてしまう不具合。完了扱いの作業について、成果物のファイルや変更の記録が本当にあるかを、担当のAIがその都度自分で掘り起こして確かめていた手間(確認の道具を新しく作りました)。そして、自動実行をやり直すたびに同じ名前の実行記録が上書きされ、前回の失敗の手がかりが消えてしまう不具合です。いずれも派手さはありませんが、放っておくと後で「あれ、直したはずなのに」という混乱を招くタイプのものです。
このとき意識したのは、実装する係と、その実装が本当にできているかを確かめる係を、あえて別のモデル・別の実行タイミングに分けたことです。同じ流れの中で作った本人が自分の作業を「できました」と判定すると、見落としに気づきにくくなります。実際、同じ時間帯に並行して進めていた別の1件では、実装した側が「影響を確かめた」と報告した範囲を、検収側がそのまま信じませんでした。確認の対象を全件に広げて洗い直したところ、報告の範囲から漏れていた見落としが2件見つかりました。修正の副作用で、人の対応や承認が要る作業まで自動で着手できる扱いになってしまうものでした。
結果:切り替えから1時間足らずで最初の4件が着地し、教訓が3つ残った
最終的に、切り替えから約1時間で最初の4件が実装・検収とも完了しました。並行して進めていたもう1件も、見落とし2件を直したうえで、その日のうちに検収を通っています。どれもその日のうちに実際の修正として反映されました。一方で、枠切れが分かってから切り替えるまでの6時間近くは、実装が止まっていました。
この一件から持ち帰った教訓は3つあります。
- 「枠切れ=作業停止」と決めつける前に、使えるレーンを数え上げる。 ひとつの経路が止まっても、役割の異なる別の経路が生きていることは珍しくありません。止まったと報告するより先に、他に動けるものがないかを確認する癖をつけておく方が、結果的に手戻りが少なくなります。今回はこれを人に言われてから行い、その日のうちにAI秘書が毎回最初に読む決まりへ書き足しました。
- 実装と検収は、同じ人・同じ便でやらない。 作った本人が自分の仕事を採点すると、どうしても甘くなります。役割とタイミングを分けるだけで、見落としに気づきやすくなることを、今回の一件で改めて実感しました。
- 「全部確かめました」という報告は、その「全部」の範囲を疑う。 今回、実装側が確かめた分は正しかったものの、確かめた範囲そのものが狭すぎました。検収する側は「本当にこれで全部か」を一度疑ってかかるくらいがちょうどよいと感じています。
「止まったように見える日でも、別の手段で手を動かし続けられるか」を判断するのは、本来AI秘書の役割です。今回は人の指摘でそれに気づきました。同じ指摘をもう受けないように、手順へ組み込むところまでを含めて運用だと考えています。
人手を増やさずに、こうした地道な運用の穴を埋めたい方へ AI秘書は、こうした障害対応や見落としチェックのような細かい業務を、決まった手順で拾って進めます。人から受けた指摘は、次から同じことが起きないよう手順に組み込みます。導入のご相談はお気軽にどうぞ。 ラポ秘書に無料で相談する