分身AIを並列化したら、別の分身AIに地雷を教えてもらった話｜分身AI日記 DAY48

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。

今日は、分身AIの作業をもう一段速くしようとしたら、別の分身AIに「それ、落とし穴あるよ」って指摘された話を書こうと思う。

ぶっちゃけね、私は前から分身AIの並列化はやってた。DAY33で16セッション同時に走らせた話も書いた。だから「もう十分速い」と思ってたんだよね。でも今回、もう一段深い層を覗いたら、そこは全然手つかずだった。1人で直して満足しかけたんだけど、別の分身AIに「ちょっと見てくれる？」って頼んだ瞬間、自分じゃ一生気づけなかったかもしれない穴が見つかった。今日はその全記録。

3口コンロの厨房に、1口コンロの鍋が隠れてた話

まず、何が問題だったかを話すね。

私は普段、分身AIにいろんな作業を任せてる。ブログの下書き、画像の生成、動画のナレーション、SNS投稿の下ごしらえ……そういうのを「作業手順書（私たちはこれをスキル定義って呼んでる）」にまとめておいて、指示を出せば自動で動く仕組みにしてるんだよ。

セッション全体の並列化は、前からやってた。DAY33で書いた「16セッション同時稼働」がまさにそれ。料理に例えると、厨房全体としてはすでに3口コンロをフル活用してたんだよね。

でも今回、各コンロの上で何が起きてるか覗いてみたら、びっくりした。

1つ1つのコンロの上で、小さな鍋が「1個ずつ順番待ち」してた。音声ナレーションが3つ必要なら、1つ目を作って、できたら2つ目、終わったら3つ目……って、ひたすら順番待ち。画像が5枚いる時も、1枚ずつ生成して、完成を待って、次、また次。

厨房全体は3口コンロなのに、各コンロの上は1口コンロだった。もう一段深い層にボトルネックが隠れてたわけ。

計算してみたら、作業手順書10件分を「各コンロの中でも同時並行」に書き換えるだけで、月4時間ぐらい時間が浮きそうだった。4時間あれば、ブログ4本書ける。家族と食卓を囲める。それだけの時間を、私は「順番待ち」でドブに捨ててた。

10件のレシピを「同時並行」に書き換えてみた

気づいた以上、止まってる場合じゃない。その日のうちに10件の作業手順書を書き換えた。

たとえばラジオ番組を作る手順書。元々は「ナレーション1を作る → 完成を待つ → ナレーション2を作る → 完成を待つ → ナレーション3を作る」という1列の流れだった。これを「ナレーション1・2・3を同時に投げる → 3つとも完成したら次へ」という流れに変えた。料理で言うと、煮物・焼き物・揚げ物を3口コンロで同時にかける感じ。

朝のブリーフィングを作る手順書もそう。予定・タスク・天気・健康データ・ニュース……7つの情報源から「順番に」取りに行ってたのを、「7つ同時に」取りに行くように変えた。これだけで、1〜2分かかってた待ち時間が20秒ぐらいに縮む想定。

他にも、動画編集・画像の一括生成・週間まとめ記事の画像アップロード・学びを記事にする仕組み・会議議事録・秘書日記……合計10件。どれも「順番に走ってた作業」を「同時並行」に組み替えた。

書き換えが終わった時点で、私はわりと満足してた。「よし、これで月4時間浮く。明日からの分身AI、一段速くなるぞ」って。

……でも、ここで一瞬、手が止まった。

「これ、本当に全部並行で走らせて大丈夫か？」という、嫌な予感。

AI秘書の凛：え、待って。厨房全体は3口コンロフル回転なのに、各コンロの上ではカセットコンロ状態だったの？料理で言うとさ、業務用のでかいガス台3つあるのに、その上に小さいカセットコンロ置いて1品ずつ作ってたような話だよね。これすぎん？（笑）でもさ、「もう一段深い層」って視点は大事。惣菜屋でもそう、盛り付けラインの手前で揚げ物が渋滞してるとか、見えにくいところにボトルネックって隠れるんだよね。気づいて止まれたの、えらいよ！

怖くなって、別の分身AIに「ちょっと見てくれる？」と頼んだ

ここで、私は自分の判断を信用しなかった。信用しなかったのが、今日の話のいちばん大事なポイントかもしれない。（前日書いた『分身AIのSEO失敗談——上流設計ゼロで6サイト走った末路』で、勢いで走った結果の痛みを書いたばかりだった。だから今回は、最初からブレーキを踏む心の準備ができてた。）

私が普段使ってる分身AIは、実は1種類だけじゃない。ブログの文章を書くのが得意な子、リサーチが得意な子、そして「コードレビューが得意な子」がいる。最後のコードレビュー担当は、プログラムの依存関係とかバグのニオイを嗅ぎつけるのが得意なんだよね。

私は10件の書き換えが終わったあと、その「コードレビュー担当の分身AI」にこう頼んだ。

「10件の作業手順書を並行実行に書き換えたから、問題ないか見てくれる？観点は5つ。①安全性 ②サービスの使用上限（同時に走らせすぎてブロックされないか） ③作業同士の依存関係 ④書き換えの明確さ ⑤矛盾がないか」

依頼して、しばらく待った。コードレビュー担当の分身AIは、10件のファイルを全部読んでくれて、さらに内部で呼ばれてるプログラムのソースまで追いかけて、依存関係を検証してくれた。

数分後、返ってきたレポートはこうだった。

「8件は問題なし。1件は記述が曖昧だから明確化が必要。そしてもう1件——ここ、並行で走らせちゃダメなやつです」

ドキッとした。自信満々で書き換えたのに、1件まるごと「並行にしちゃダメ」って言われた。どういうこと？って、詳細を読み込んだ。

見えない依存——後ろの料理が、前の料理の出汁を使ってた

「並行で走らせちゃダメ」と指摘されたのは、ブックマーク整理の仕組みだった。

この仕組みは、毎日「自分がX（旧Twitter）でブックマークした投稿」を集めて、そこから「今日のブログネタ」を見つけてくれる便利な仕組み。手順は2つに分かれてた。

手順A：Xからブックマーク一覧を取りに行く
手順B：取ってきた一覧を整理して、自分のメモ帳に保存する

私は「AもBも別の作業だから、同時に走らせればいいじゃん」と思ってた。見た目は独立した2つの作業に見えたからね。

でも、コードレビュー担当の分身AIはプログラムの中身まで読んでくれて、こう指摘してきた。

「手順Bは、手順Aが出力したファイルを入力として使ってます。AとBを同時に走らせると、Bは『昨日のAが残したファイル』を読んじゃうので、毎回1日遅れのデータで動くことになります」

あ、やられた、と思った。

料理で言うとこれ、煮物と天ぷらの話なんだよね。「煮物の出汁」を使って天ぷら用のつゆを作るタイプの定食。煮物と天ぷらは別のコンロで作るから一見独立してるように見えるけど、じつは天ぷらのつゆが「煮物から引いた出汁」を待ってる。これを「同時並行！」って勢いで始めたら、天ぷらのつゆは昨日の出汁を使うことになる。そりゃ味が落ちるわけよ。

しかも怖いのは、この依存って「見た目」じゃ全然わからなかったってこと。手順Aと手順Bの名前だけ見てたら、完全に独立してるように見えたんだよね。プログラムの中の「ファイルの受け渡し」を追いかけないと、気づけなかった。

結局、この1件は「並行にしない」に戻した。依存関係があるから、手順Aが終わってから手順Bを動かす順番待ちのままにする。該当ファイルには「並列化不可。理由：手順Aの出力を手順Bが入力として使用しているため」とコメントを残した。次の自分（あるいは別の分身AI）が同じ間違いをしないように。

モルくん（AIリサーチ担当のモルモット型AI）：ちょっとここ、データを掘ってたら面白いことに気づいたです。手順Aと手順Bが「独立してるように見える」のは、名前と説明だけ読んでる時なんですよね。でも、プログラムの中で誰が誰にファイルを渡してるかって「データフロー」を描くと、一発で矢印が見える。今回コードレビュー担当が見つけたのは、その「矢印」です。人間の計画段階では、見た目の独立性で判断しがち。でも実行の真実は、いつだってデータの流れの中にあるです。矢印を描かずに並列化するのは、真っ暗なキッチンで3口コンロを全開にするのと同じくらい危ないんですよ。

並列化の3条件と、私が得た本当の学び

今回の事件で、私は「並列化していいかどうか」を判断する3つの条件をハッキリ言葉にできた。

条件1：出力ファイルが別であること

同じファイルに同時に書き込むと、どっちかが消える。料理で言うと、煮物と天ぷらを「同じお皿」に同時に盛ろうとするようなもの。そりゃぶつかるよね。

条件2：入力データが独立していること

今回やらかした条件。手順Bが手順Aの出力を使うなら、AとBは並列にできない。必ず「Aが終わってからBを始める」順番を守らないと、Bは古いデータで動く。

条件3：サービスの使用上限に余裕があること

分身AIが使ってる外部サービスには「1分間に何回まで」みたいな上限がある。10個同時に投げたら、逆にブロックされて全部止まる。今回、音声生成は「3つずつ同時」が安全圏だった。料理で言うと、3口コンロを全部強火にすると換気扇が追いつかなくて煙警報が鳴るようなもの。

この3条件を全部満たして、初めて「並列化OK」って言える。どれか1つでも怪しかったら、順番待ちのままでいい。待ち時間より「壊れないこと」のほうがずっと価値がある。

そして、もっと大事な学びがあった。

それは、「分身AIを育てるって、1人で抱え込むことじゃない」ってこと。

私、今回10件の書き換えを全部1人で決めようと思えば決められた。自分でレビューして「よし完璧」って言って、そのまま走らせて、1週間後ぐらいに「ブックマークのデータが1日遅れてる気がする……なんで？」って首をかしげる未来が普通にあり得た。気づかないまま何週間も間違ったデータで動いてた可能性すらある。

でも、コードレビュー担当の分身AIに「ちょっと見てくれる？」って声をかけただけで、数分後にはバグが見つかって、原因も分かって、対策も決まってた。料金もほとんどかからない。

人間は縦に掘る。AIは横に広げる。これ、私がよく言うフレーズだけど、今回の出来事はその逆もあるって思わせてくれた。AIにもAIの「縦に掘る」担当がいる。計画を横に広げた自分に対して、「その中の1本、もう少し縦に掘らないと崩れるよ」って教えてくれる担当が。

分身AIひろくん：この話、私が一番好きなのは「1人で決めなかった」ところなんだよね。効率化とか並列化って、たぶんこの先もずっと話題になる。でも本当に価値があるのは「月4時間短縮できた」って結果じゃなくて、「短縮する前にもう一人の分身AIに聞いた」っていう動きそのものだと思ってる。「抱え込みOS」を書き換えるって、人間相手だけじゃなくてAI相手にも起こるんだよ。自分のAIチームに「助けて」って言えるようになること。それって、凸凹のまま夢中に生きるための、いちばん地味で、いちばん強い技術なんじゃないかな。

まとめ——分身AIは「1人で育てる」から「チームで育てる」へ

今日の話を短くまとめると、こんな感じ。

・分身AIの作業10件を「同時並行」に組み替えて、月4時間の短縮を狙った。
・不安だったから、コードレビュー担当の別の分身AIに「見てくれる？」と頼んだ。
・結果、1件が「見た目は独立してるけど、実は前の工程のデータを使ってた」ことが発覚。
・その1件は並列化を撤回して、依存関係をコメントで明記した。
・8件は並列化、1件は書き方を明確化、1件は順番待ち維持。結果的にゼロミスで着地。

ここからの持ち帰りはシンプルだよ。

もしあなたが分身AIを育ててるなら、あるいはこれから育てようとしてるなら、1つだけ覚えといてほしい。「1人のAI」で全部決めようとしないで。得意分野の違う分身AIを2人3人と組ませて、お互いにレビューさせる仕組みを作ってほしい。私は今回、それで月4時間の節約と、見えないバグの回避を両方手に入れた。

分身AIを育てる＝自分が育つ。これは変わらない。ただ、育て方が変わった。「1人で全部育てる」から「チームで育てる」へ。1人で完璧を目指すより、チームで抜けを埋めたほうが、分身AIも自分もずっと遠くまで行ける。これ、人間のチームづくりと全く同じなんだよね。

明日からは、新しく作業手順書を書き換える時、必ずデータの流れを先に描いてから並列化するかどうか決める。そして必ずもう一人の分身AIに「見てくれる？」と声をかける。これを仕組みにしてしまう。気をつける、じゃなくて、仕組みに落とす。そこまでやって初めて、同じミスを2回しないで済むから。

今日もAIチームに助けてもらった1日だった。明日も、また助けてもらいながら前に進もうと思う。

実戦の現場で使える最新AIノウハウ、無料で学べます

---

このブログは「分身AI」と「AI秘書の凛」を使って書いています。過程も全部公開する「プロセスエコノミー」シリーズです。

ひろくん（田中啓之） 分身AI.com / GPTs研究会代表 / がんサバイバー / 元134kg 2026年4月13日