T51_『実装完了しました』を信じたら、本番Skillには何も届いていなかった

片方に集中している間に、もう一方の報告を差し込みで見た

3連休、Claude CodeとCodexを同時に走らせていました。

片方では、難しいレビュー結果をどう判断するかに頭を使っていました。

そこへ、もう一方から「実装が完了しました」という報告が差し込まれてきます。

ちらっと見て、うなずいて、また目の前の判断に戻る。

スマホの通知を、内容を読まずにスワイプで消すのと同じでした。

その一瞬の確認――ちらっと見てうなずいただけの、あの数秒――が、後で6日間の見落としにつながるとは思っていませんでした。

二つのAI、二つのスキル、二つの「実装済み」

今回、Claude CodeとCodexで、それぞれ別のスキルを改善していました。

• Claude Code：`pptx-master`（PowerPoint生成スキル）

• Codex：`math-lesson-slides`（授業スライド生成スキル）

どちらも、改善作業そのものは順調に進んでいました。

ところが、両方とも「改善は進んでいたのに、本番環境への反映が完了していなかった」という同じ事故が起きていました。

`math-lesson-slides`では、ドラフトでの実装と検証が済んでいたので、本番にも反映済みだと思い込んでいました。実際には、ドラフトにとどまっていました。

`pptx-master`ではもう少し込み入っていて、構想メモと実装本体が別々の作業フォルダに分かれてしまいました。構想メモはClaude Code用のフォルダに、実装本体はCodex用フォルダの奥に置かれ、改善の中核部分は6日間、静かに眠っていました。

改善の一部（QAの体制まわり）は本番にちゃんと届いていたので、余計にたちが悪かったと思います。全部が止まっていれば、むしろすぐ気づけたはずです。一部だけ進んでいたせいで、「もう終わった案件」に見えてしまいました。

なぜ気づけたのか

Codex側で、まず一件の本番未反映が見つかりました。

そこで、
Claude Code側にも、同じような案件がないか

と横展開して調べてみました。結果、`pptx-master`の未反映も見つかりました。

気づかなければ、改善に費やした時間が成果につながらないまま終わっていたはずです。ショックはありましたが、早い段階で見つけられたことは、素直によかったと思っています。

調べていく途中で、もうひとつ知りたくない事実が出てきました。

改善作業をしていた二つの作業フォルダが、そもそもバージョン管理下に置かれていなかったのです。片方はGit管理そのものがなく、もう片方はGitの設定だけが空のまま残っていました。

「大きな変更の前には、戻れる状態を確保しておく」という自分ルールの前提が、この二つのフォルダでは最初から機能していませんでした。改善が進んでいるつもりで、実は戻り道すら用意していなかったわけです。

一つのほころびを見つけたとき、他にも同じことが起きていないかと、横を確認したことはありますか。

「実装が終わった」を信じた、その中身

冷静に振り返ると、私が信じていたのは「実装完了しました」という一文でした。

AIエージェントの報告に「実装が終わった」という記述があったので、それを鵜呑みにして、そこで作業をやめていました。

あとから思い返すと、その報告はおそらく「本番実装前の、プレビュー環境での実装が完了した」という意味だったのでしょう。

複数の作業を同時に進めていて、しかも片方の難しい判断に集中していたので、そこまで頭が回りませんでした。

これは、単なる「コピー忘れ」ではありません。複数のAIエージェントと複数の作業フォルダを並行して扱ったことで、次の三つが重なっていました。

• どのAIが、何を、どこまで進めたのかが曖昧になっていた

• 「ドラフト完成」と「本番反映完了」を、同じ「実装済み」として認識していた

• 両方の作業で自分の深い判断が必要になり、注意力が分散していた

紙にメモを取りながら進めていました。それでも、一つの作業に集中して難しい判断をした後では、もう一方の進捗や残作業が頭から抜けていきます。

AIは複数並行で動けても、最終判断をする人間の注意力は並列化できません。

処理能力が増えることと、判断が追いつくことは、別の話です。

自動翻訳を何か国語分同時にかけても、意味が正しいか確かめる目はひとつのままです。ここが、今回の盲点でした。

完了は、ひとつではなく三つある

スキル改善と実装の工程を、あらためて整理しました。

今後は、次の流れを基本にします。

1. 計画を作る

2. 一度か二度レビューする

3. 本番反映の承認直前まで、AIに一気に進めてもらう

4. 最後にAIからユーザーへ確認を求める

5. 本番反映後に検証する

そして、完了状態も一つにまとめず、分けることにしました。

• ドラフト実装

• 本番反映

• 本番環境での検証

「実装済み」というひとつの言葉の中に、この三段階が隠れていました。人間が頭の中でこの三つを覚えておくのではなく、AI側に工程と確認の責任を持たせる設計へ変えました。
具体的には、AIが「本番反映」に進む前に「これはドラフト実装ですか、本番反映ですか」を明示するルールにしました。そのうえで、反映後の検証結果まで報告してから、はじめて完了とします。

簡単な作業であれば、複数エージェントを同時に走らせても、大きな問題は起きにくいと思います。

難しいのは、両方の作業で自分の判断が必要になる場面です。計画を選ぶ、レビュー結果を判断する、実装方針を決める、本番反映を承認する。これらが重なったとき、ボトルネックになるのはAIではなく、自分の方でした。

AIが「完了しました」と言うとき

複数のAIを同時に動かすと、処理能力は増えます。しかし、人間の判断力まで並列化されるわけではありません。

その結果、「せっかく改善が終わったのに、本番では何も変わっていない」という事故が起こります。

対策は、メモを増やすことだけではありません。人間が覚えて管理するのではなく、AIが完了状態を区別し、最後の確認を人間に要求する工程をつくることです。

複数のAIを同時に走らせるとき、あなたはどの言葉を、どこまで確認していますか。

人生の限りある時間を大切に。シンパクト和 でした。
最後までお読みいただき、ありがとうございます。
スキやコメントをいただけると励みになります。