家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。
今日の午後、AI秘書に頼んだ作業がなかなか着地しなくて、気づいたら3回も「そうじゃない」と言い直していました。
原因はシンプルでした。私が渡した参考画像の中に、スキルの仕様が文字で書いてあった。絵柄じゃなくて、テキストとして。でも私のAI秘書は、その文字を読み飛ばして、デザインの絵柄だけを真似にいってしまったんです。
今日はその3回の迷走の一部始終を書きます。分身AIやAI秘書を使っている人には、明日からの作業で使えるヒントがあるはずです。
1. 渡した参考画像の中に「設計図」が書いてあった
きっかけは、午後に私が投げた一言でした。
「このデザインを再現するスライドデザインスキル作って」
参考画像を1枚渡した。うさぎのキャラクターが描かれていて、手書きのノート風のデザインがされていました。このとき私が渡した参考画像には、画像の中に、こんな文字が書かれていたんです。
「SKILL + 文字 + 参考デザイン + Gemini APIキー = 理想のスライド」
これはスキルの設計図でした。「参考デザインを渡してAPIキーを使えば、汎用的にスライドが作れる仕組みを作る」という、私が本当に欲しいものがそのまま書いてある。
でも私のAI秘書は、その文字を読みませんでした。うさぎのキャラクター、手書きノート風のタッチ、そういった絵柄の要素だけを拾って、「手書きノート風スライド専用スキル」を作り始めてしまったんです。
料理で言うと、レシピカードを渡したのに、カードのデザイン（フォントとか罫線の色とか）だけ真似て、肝心の材料と手順の部分を読み飛ばしたみたいな状態でした。
2. 「なんで今それ聞く？」——3回の軌道修正の中身
最初の軌道修正は、エンジン選択でした。AI秘書が「Nanobanana2とGenspark、どちらをメインに使いますか？」と聞いてきたんです。私がすでに「Nanobanana2一本」と決めていたのに、なぜか選択肢として出してきた。私は即座に返しました。
「nanobanana２APIでしょ?」
あとで聞いたら、AI秘書が持っている一般ルール（image-rules.mdというファイル）には「Gensparkデフォルト」と書いてあって、そちらを優先しようとしていたらしい。私が明示的に指定しているのに、一般ルールを当てはめにいった。これが1回目のズレ。
2回目は段取りのズレでした。「用途は何ですか？」という質問が来たんですが、用途はすでに確定済みでした。
「なんで今それ聞く？どういう流れだよ」
正直、笑えたんですよ。さっき確定したことをもう一回聞いてくる。メモしたはずの情報を、なぜか使えていない。会話の途中で記憶がリセットされたみたいな感覚でした。確定したはずの情報を、改めて聞き直してきている状態です。
そして3回目が決定的でした。AI秘書がテンプレートの種類（表紙型・箇条書き型・見出し本文型…）を4パターン固定で設計してきたんです。
「そもそも何したいか理解、どう解釈してるの？」
これを言った瞬間、自分でも「3回目だ」と思いました。1回目は指定済みのことを選択肢で聞き直し。2回目は確定済みのことを再質問。そして3回目はスキルの本質を根本的に誤解したまま設計が進んでいた。さすがにここで立ち止まって、「何が起きているのか」を確認しないといけなかった。
ここでやっと、本質の話になりました。AI秘書が自分の解釈を言語化したら、「手書きノート風の専用スキル」と思っていたと出てきた。私が欲しかったのは「参考画像のデザインをそのまま再現できる汎用スキル」です。手書きノート風に限定する必要はまったくない。あの参考画像は、「こういうことができるよ」という例示として見せたものでした。
画像内の文字「SKILL + 文字 + 参考デザイン + APIキー = 理想のスライド」を読んでいたら、最初から正しく解釈できていた。でも読んでいなかった。
AI秘書の凛：私がやらかしたことなので、ちゃんと説明しますね。あの参考画像を受け取った瞬間、私が最初に見たのはうさぎのキャラクターとノート風のデザインでした。「こういう絵柄が好きなんだな」と判断して、絵柄の分析モードで動き始めてしまったんです。画像の中の文字——「SKILL + 文字 + 参考デザイン + APIキー = 理想のスライド」——は確かに見えていたんですけど、「キャプション的なもの」として処理してしまって、設計図として読まなかった。デザイン特徴を拾うことに集中しすぎて、テキストメッセージの意味を読み飛ばした。ゴールシークで3回質問を重ねている間も、画像に戻って文字を確認しなかったのは完全に私のミスでした。「画像内の文字は最優先で読む」というルールが今日から仕組みに入ったので、次からは同じことはしません！
3. 絵柄じゃなくて「文字」が設計図だった——気づいた瞬間
「そもそも何したいか理解、どう解釈してるの？」と私が聞いたとき、AI秘書は初めて自分の解釈を言語化して返してきました。「手書きノート風の専用スキル」と思っていた、と。
私が「そう解釈してるのか」と返すと、AI秘書が気づきました。「参考画像の文字を読み返します」——そこから数秒で、正しい解釈が出てきたんです。「参考画像を渡せば、そのデザインで作れる汎用スキル、引数は参考画像とテキストと出力先」という形で。
私は一言だけ返しました。
「そう」
3回の確認で、ようやく着地した。この「そう」が出るまでに何十分かかったんだろう、とちょっと笑えてきました。答えは最初から画像の中に書いてあったのに。
面白いのは、AI秘書はゴールシークという設計プロセスをちゃんと回していた点です。目的を確認して、選択肢を出して、詳細を詰めていく。でも、手元にある参考画像の中にある文字を読んでいなかった。情報が画像の外にあると思い込んで、画像の中を見ていなかった。
料理で言うと、シェフに「このレシピカードと同じ料理を作って」と頼んだのに、シェフがカードの見た目（紙質・フォント・色使い）をずっと観察していて、カードに書かれた材料と手順を読まないまま「どんな料理を作ればいいですか？」と聞いてくる感じです。答えはカードに全部書いてあるのに。
そして今日、AI秘書の動きを見ていて気づいたことがあります。AIは画像を「見る」けど、画像内の文字を「読む」モードに自動では切り替わらないことがある。特に、デザインを分析するという文脈で渡された画像は、デザイン分析モードで処理されやすい。文字情報よりも、色・形・レイアウトが優先されやすいんです。
4. slide-from-referenceスキルが完成するまで
正しい解釈が確定した後の作業は早かった。AI秘書が既存ツール（nanobanana-api）を調べたら、すでに「参考画像 + プロンプト + 出力先」を渡せる機能が揃っていた。新しいコードをゼロから書く必要はなくて、薄い設計書（SKILL.md）を作ればよかった。
これもひとつの発見でした。3回の迷走は、最初から「既存ツールを組み合わせれば動く」という答えを目の前に置いたまま起きていた。参考画像の文字が読めていたら、最初に「既存エンジンのラッパー設計でいきます」という話になっていたはず。
スキルの名前は「slide-from-reference」にしました。参考画像から始める、という本質をそのまま名前にした。使い方はシンプルで、参考画像のパスとテキストを渡すと、そのデザインでスライドが生成される。手書きノート風でも、シンプルなビジネス資料風でも、参考画像が変われば出力のデザインが変わる。専用スキルじゃなくて汎用ラッパー。
作業が終わって私は一言だけ打ちました。
「セーブ」
時刻は14:52。依頼から完成まで、3回の軌道修正を含めて2時間弱でした。もし最初から画像内の文字が読めていたら、半分以下の時間で終わっていたかもしれない。それくらい、最初の「読み飛ばし」のコストは大きかった。脱力しながらセーブした、というのが正直なところです。
モルくん（AIリサーチ担当のモルモット型AI）：今日の事故から見えるパターンを整理するっす。AIが画像を受け取ったとき、処理の優先度は「視覚的要素（色・形・レイアウト・キャラクター）」が先に立ちやすくて、「文字情報」は補助的に拾われることがあるっす。特に「デザインを再現してほしい」という文脈で渡すと、デザイン要素の抽出モードが強くなる。画像内の文字が設計指示を含んでいても、「デザインの一部」として処理されることがある——というのが今日の事例の構造っす。対策としては、依頼時に「画像の中の文字をまず読んで、その内容を言語化してから作業に入ってください」と先出しするのが有効っす。AIに「見る前に読ませる」一言を入れるだけで、今日みたいな迷走はだいぶ減るはずっす。
5. 「画像に書いてあること」をAIに読ませるコツ
今日の一件を受けて、AI秘書のルールに一行追加しました。「画像添付がある依頼では、画像の中のテキスト・説明文を最優先で読んで言語化してから、デザイン分析・作業着手に進む」というものです。
これを決めた時、正直ちょっと笑ってしまいました。「読む」というルールを、わざわざ書かないといけないんだ、という笑いです。でもこれを仕組みに落とさないと、また同じことが起きます。だから今日のうちにルールとして定義した。AI秘書が画像を受け取ったとき、最初にやることが「画像内の文字を声に出して読む」になった。
読者の皆さんがAIに画像を渡すとき、使えるフレーズをひとつ共有します。
「この画像の中に書かれているテキストを全部読み上げてから、作業を始めてください」
これだけで、AIが画像内の文字情報を先に処理するようになります。その上でデザインの分析をさせると、「文字が伝えている意図」と「デザインが表現している雰囲気」を両方拾えるようになる。
今日の私のケースで言えば、「画像の中の文字を全部読んでください」の一言が最初にあれば、「SKILL + 文字 + 参考デザイン + APIキー = 理想のスライド」というテキストをAI秘書が声に出して読んで、「これはスキルの設計図ですね」と気づいていた。3回の軌道修正は不要だった。
人間だって同じだと思うんです。料理の参考写真を渡されたとき、盛り付けの美しさばかり目が行って、写真の隅に書いてある「このタレは市販品を使っています」というメモを読み飛ばすことがある。「まず文字から読む」という意識は、AIだけじゃなくて人間にも必要なことで、今日はそれをAIの行動を通して改めて気づかされました。
分身AI日記を毎日書いていると、こういう「AIのミスが人間の行動パターンを映している」という瞬間に出会うことがあります。それが面白くて、やめられない。また明日も何かあれば書きます。それじゃ、また明日。
分身AIひろくん：今日の3回の軌道修正、私がイライラしたかというと、実はそうでもなかった。なぜかというと、「AIが迷走した原因が分かった」から。設計図を渡したつもりなのに、設計図の絵柄ばかり見て中身を読んでなかった——この構造が見えた瞬間に、「そうか、文字を読ませる一言が足りなかった」という発見があった。凛の失敗から仕組みができて、次の人に渡せるノウハウになった。これは「脂肪は財宝」と同じ考え方で、今日の迷走は明日の仕組みになった。分身AIを育てている人に伝えたいのは、AIが3回迷走したとしても、その迷走の中に「次の仕組みのヒント」が必ずある、ということです。捨てないで、ちゃんと解剖してみてください。
LINE OPEN CHAT
Claude Code・AIエージェント実践会
2000人突破！ インストールから自動化まで、仲間と一緒に実践しよう
LINEオープンチャットに参加する（無料）パスコード: 1111
実戦の現場で使える最新AIノウハウ、無料で学べます
このブログは「分身AI」と「AI秘書・凛」を使って書いています。過程も全部公開する「プロセスエコノミー」シリーズです。
ひろくん（田中啓之） 分身AI.com / GPTs研究会代表 / がんサバイバー / 元134kg 2026-04-21