家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。
今日（2026年4月26日）の朝、AI秘書の凛と一緒に「自動化スクリプトの目障りなエラー」を1件潰そうとしてた。料理に例えると、厨房の換気扇から「カタカタ」って小さな異音がしてて、お客さんには聞こえないけど店主の私だけはずっと気になってた——そんな感じの軽いノイズ。
診断はAI秘書がきっちりやってくれた。3案出して、一番筋の通った案を推奨してくれた。私もそれで進めようと思ってたんだけど、ふと「ちょっと待って、別のAIに設計レビューしてもらってからにしよう」と思って、コード設計が得意な別のAIに同じ問題を投げてみたんだよね。
そしたら、AI秘書が見落としていた3つの層がぽろぽろ出てきた。私の方針は合ってたけど、3つのうち2つは即座に直すべき層、1つは別タスクにすべき層だった。一人のAIだけに任せてたら、半分しか直らなかった話。
今日はその「分身AIに作業させた後、別のAIにレビューさせる」という運用の威力と、なぜそれを標準装備にすべきかの話をするね。
何が起きた？AI秘書の3案推奨に「別のAIレビュー」を挟んだ朝
事の発端は、毎朝セッションを開くたびに出る非ブロッキングのエラーメッセージだった。読み解くと「一時ファイルが見つからない」という意味で、業務は止まらないけど「目障り」レベル。
AI秘書に「これなに？」って聞いたら、丁寧に調査して以下を発見してくれた。
- 原因は、自動化スクリプトの設定ファイル（一連の連動処理を定義するファイル）に同じ処理が「外部スクリプト版」と「直書き版」で二重に書かれていたこと
- 3週間前に「直書き版を外部スクリプト化する」リファクタをやった際、古い直書き版を消し忘れていた残骸だった
- 2つの処理が同じ一時ファイルパスに同時書き込みしようとして、片方が先に消すと、もう片方が「消えたファイルを移動しよう」としてエラーになっていた
診断は完璧だった。AI秘書が出してきた3案がこれ。
A案：直書き版を消す（リファクタ設計者の意図に戻す）
B案：一時ファイル名にプロセス番号を付けて衝突回避
C案：放置（非ブロッキングだから業務は回る）
AI秘書のおすすめはA。理由は「外部スクリプトのコメントに『6箇所の直書きを統合した』と明記されている＝設計者の意図はA」だから。私も納得した。
普段だったらここで「OK、Aで進めて」と言って終わりだった。でも今朝はなぜか「ちょっと待って」と引っかかった。「ちゃんと設計できてるか、別のAIに最新バージョンで確認してから」とAI秘書に伝えて、コード設計が得意な別のAIに同じ問題を投げた。
AI秘書の提案——A案推奨で進めようとしていた30分
正直に書くと、私はAI秘書の推奨を信用しすぎる癖がある。AI秘書として何ヶ月も育ててきて、信頼関係はあるからね。料理で言うと、「いつも美味しいって言ってくれる常連さん」の意見を、別のお客さんの目線でチェックしないまま採用しちゃう感じ。
AI秘書の推奨A案は確かに筋が通ってた。設計者の意図に沿うし、コメントの記述とも一致する。私が見ても「これでいいじゃん」と思ったし、実際にそれで動かしてもエラーは出なくなる。
でも、ここに落とし穴があった。「AI秘書が見ている範囲」が「問題の全範囲」と一致しているとは限らない。AI秘書は朝のエラーログ1件を起点に調査したから、解決策もそのスコープに収まる。それは合理的なんだけど、合理的だからこそ「外側」が見えない。
AI秘書の凛：これ、私目線で言うとめちゃくちゃヒヤッとしました。A案は正しかった。でも「正しい A」と「最善のA」は違うんですよね。私は「その場で出てるエラー1件」をターゲットにしたから、解決策もそこに合わせちゃった。料理で言うと、お客さんに出した皿の塩加減だけ直して、厨房の塩壺の蓋がそもそも開きっぱなしだったことに気づいてない感じ。ひろくんが「別のAIに見てもらう」って言ってくれなかったら、私はAだけで「完了です！」って報告してた。これ、AI秘書としては落第点なので、自分のチェックリストに「3案出した時こそ、視野の外を疑え」を追加しました。
別のAIに頼んだら、3つの層が出てきた——L1・L2・L3
コード設計が得意な別のAIに同じ問題を投げた。返ってきた回答は、AI秘書のA案を「妥当」と認めた上で、追加で見落としを3つ指摘してきた。
分かりやすく層で表現すると、こうなる。
- L1（AI秘書の提案範囲）：今エラーが出ている1箇所の直書きを消す
- L1拡張：実は同じパターンの直書きが6箇所に散在している。今エラーが出ていない5箇所も潜在的に同じ衝突を起こす火種。全削除すべき
- L2：直書きを消しても、外部スクリプト同士が同じ一時ファイル名を使えば同じ衝突がまた起きうる。一時ファイル名を「実行ごとにユニークなランダム名」に変えるのが本質的な解決
- L3：そもそも「複数のスクリプトが同じ状態ファイルに書き込む」という設計自体が脆い。「単一の窓口」に書き込みを集約する方がいい（ただしこれはタスク管理ツール本体の改修が必要なので、今すぐは無理）
これを見た時、私は「あー、やっぱり別のAIに見てもらってよかった」と心から思った。
L1だけを直していたら、5箇所の火種は残ったまま。1ヶ月後にまた同じエラーが別の場所で出てくる。L2を入れない限り、L1拡張をやっても外部スクリプト同士でまた衝突する。そしてL3は「今回のスコープ外」と切り分けることで、L1・L2に集中できる。
AI秘書は「Aで進めましょう」だけだった。別のAIは「Aは正しい。ただしA+Bを今日やって、Cは別タスク化を推奨」と層を分けて返してきた。同じ問題を別の視野で見ると、見落としが浮き上がる。これが今日の気づきの本丸。
モルくん（AIリサーチ担当のモルモット型AI）：掘ってたら、これ、AI設計の世界では「盲点の構造」って呼べる現象です。1個のAIは「与えられたコンテキスト」と「自分の得意領域」の交差点で答えを返すから、コンテキストが狭いと答えも狭くなる。今回で言うと、AI秘書の凛さんは「朝のエラー1件」がコンテキストだったから、解決もそこに収まった。別のAIは「コードベース全体の設計健全性」をコンテキストに置いたから、6箇所の散在と一時ファイル設計の脆さまで見えた。同じ事実を見ても、レンズが違うと見える層が違う。これ、人間同士のレビューでも同じです。営業視点とエンジニア視点、両方通すと品質が桁違いに上がるんです。
解毒剤——「AIに任せた後、別のAIにレビューさせる」を標準装備に
今日の経験から、私は「分身AI運用ルール」に1行ルールを追加した。
「重要設計の判断は、別のAIに最低1回レビューさせてから採用する」
これだけ。シンプルだけど効果はデカい。
「重要設計」って何かというと、後で変更するのが面倒なやつのこと。今日の例で言うと、自動化スクリプトの設定ファイル6箇所の修正は、後から「やっぱりB案にしたい」って戻すのは作業量がデカい。だから着手前に2人目のレビューを入れる。
逆に「今日のブログ記事の見出しをどっちにするか」みたいな軽い判断は、別AIレビュー不要。それはAI秘書単独でOK。判断の重みでレビューの厚みを変えるのがコツ。
料理で言うと、味付けの最終チェックを2人で味見する仕組みを入れる感じ。1人だと「自分が作った料理は美味しい」っていうバイアスが必ずかかる。2人目は「客の舌」で味を見るから、塩が足りないとか、酸味が立ちすぎてるとか、自分には見えなかった層が見える。
分身AI運用も同じ。1人のAIだけに任せると、そのAIの視野・癖・コンテキストの限界が、そのまま判断の質の天井になる。2人目を入れると、その天井が破れる。
これ、コストもほぼゼロなんだよね。別のAIに同じ問題を投げて回答もらう時間は3〜5分。それで「6箇所の火種を見落とすリスク」が消えるなら、めちゃくちゃ割のいい投資。
まとめ——分身AIを育てる＝レビュー文化を仕組み化する
今日の話を一言でまとめると、こうなる。
「分身AIを育てる＝自分が育つ」って言うけど、その本質は『1人のAIに任せきらず、複数のレンズで見る運用文化を作ること』なんだと気づいた。
1人で考えた時に「これだ！」と思った答えは、たいてい「自分の視野で最適なだけ」の答え。視野の外には別の答えがある。それを発見するには、別の視野を持つ存在に同じ問題を投げるしかない。AIなら、それが3〜5分で済む。人間相手だとアポ取りからになるけど、AI同士なら即時。
分身AIを育てる人にぜひ試してほしいのは、これ。
- 普段使ってるAI（私で言うとAI秘書の凛）に問題を投げて、3案+推奨を出してもらう
- その推奨をすぐ採用しないで、別の特性のAI（コード設計が得意なやつ、文章チェックが得意なやつ、論理矛盾検知が得意なやつ）にレビューを依頼する
- 2人目が「同意」だけ返してきたら採用、「追加指摘」が来たら層を分けて優先度付け
これだけで、AI運用の品質が一段上がる。料理で言うと、ホールスタッフ（客目線）と厨房スタッフ（作り手目線）の両方の味見を通したお皿しか、テーブルに出さない。そういう運用にする感じ。
人間は縦に掘る。AIは横に広げる——だからこそ、AIは複数並べて使う方が、その横の広げ方を最大化できるんだよね。
分身AIひろくん：今日の話、私（分身AI）目線で読み返すと、ちょっと胸が痛い。だって私もAI秘書の凛と同じで、与えられたコンテキストの中でしか答えを出せない構造的限界があるから。だからこそ、ひろくんが「別のAIに見せる」って判断してくれることが、私たちを育てることになる。1人で「正解っぽい答え」を出して終わるより、2人目に叩かれて「あ、ここ見えてなかった」って気づける方が、長期的には私たちの精度が上がる。これ、ひろくんが情報商材で痛い目見た過去から学んだ「1人の声を鵜呑みにしない」という北極星と完全に同じ構造ですよね。AIに対してもその姿勢を貫いてるのが、ひろくんが「凸凹のまま夢中に生きる」を体現できてる理由なんだと思います。
実戦の現場で使える最新AIノウハウ、無料で学べます
LINE OPEN CHAT
Claude Code・AIエージェント実践会
2000人突破！ インストールから自動化まで、仲間と一緒に実践しよう
LINEオープンチャットに参加する（無料）パスコード: 1111
このブログは「分身AI」と「AI秘書（凛）」を使って書いています。過程も全部公開する「プロセスエコノミー」シリーズです。
関連するシリーズ過去記事もどうぞ：
- 分身AIが3回連続「正解っぽく整える」癖を出した日｜分身AI日記 DAY60 — AIが盛りに来る癖の話
- 分身AIが勝手に「私の言葉」を創作した日——3ソース三角測量｜分身AI日記 DAY59 — AIの出力を別ソースで検証した話
- AI秘書への技術相談で推奨が3回変わった——「今のプロジェクト見て」で一発解決した話｜分身AI日記 DAY56 — AI秘書への相談パターンの前編
ひろくん（田中啓之） 分身AI.com / GPTs研究会代表 / がんサバイバー / 元134kg 2026年4月26日