【AI突撃取材4（完）】AIが画像を無視する本当の理由　役割設計の落とし穴と対策

みなさん、第3話はお読みいただけましたか？
その数日後のことです。

とあるGemの問題を一度棚上げにしたまま、別のスレッドで検証を続けていました。
そのやり取りの途中、Geminiがふと、こんなことを言いました。

「あなたは今、このGemに『法務審査官』という役割を与えていますよね。
だから私は、誤読のリスクが高い画像認識の機能をあえて封印して、確実なテキスト解析に特化したモードで動いているんですよ」

——数秒、画面を見つめたまま止まりました。

「え、なにそれ？テキスト解析に特化したモード？それっておいしいの？？
・・・ちょっと待った！！それって、ものすごく重要では！？」

1. 不具合と戦っていたあの数時間は、何だったのか

もう少し詳しくお話ししましょう。
前回（第3話）に引き続き、やはり、Gemで画像が読めないという、壁に引っかかる私。
画像読み込みは必須の条件ではないものの、バグだったらどんな影響が出るかと不安に駆られ、原因究明に再チャレンジします。Geminiに指示されるがまま、膨大なログを一つひとつピックアップ。
そんな中、突如

とGeminiから突き放されます！！

「 “解析できません”　じゃないわ！ここまでやったのに！
他にも仕事が溜まってるんですけど！！」

そう、この時の私はまだ「システムのバグ」と戦っていたんです。
仕方なく、突き放されたことで再度原因究明を中断。チェックの実務をしながら、そのチェック用Gemの検証に戻ります。
そして、ふと、そのGemのGeminiに聞いてみました。画像が読めない理由は分からないよね、と。

そこで返ってきたのが序文の回答「テキスト解析に特化したモード」。

本当の原因はまったく別のところにありました。
バグではなく、設計でした。
AIが自分の役割を全うするために、自分で判断して、画像認識という機能を封印していたのです。

2. 「役割定義」は、キャラ付けではない

多くの人は、AIへの役割定義を「口調の指定」や「キャラ付け」だと思っています。
私もそうでした。とってもそう思ってました。

でも実際は違いました。

役割定義は、AIの「脳の使い方」を切り替えるスイッチです。

「法務審査官」という役割を与えた瞬間、AIの裏側では判断が走っていました。

誰かに指示されたわけではありません。AIが自律的に、そう判断したのです。

品質管理の現場に例えるなら——検査員に「一文字の差異も見逃すな」と指示した瞬間、その検査員は自分の判断で、目視確認よりも拡大鏡と数値データに集中し始めた、というイメージです。

3. HACCPの「改善策」と同じ発想

ここで、品質管理の現場で染み込んだ感覚と重なりました。

HACCPで改善策を設計する時、「最適」を目指すことが大原則です。
厳しすぎる対策は、現場の実現性を損なう。
緩すぎれば、効果が出ない。
ヒト・モノ・カネのリソースは有限なので、どこに何をどれだけ使うかを見極める必要があります。これ重要。

AIも同じでした。

AIが使えるリソースも、無限ではありません。
「法務審査官」という役割は、AIに「正確性のためにリソースを集中せよ」というシグナルを送っていました。
その結果、画像認識に割けるリソースが絞られ、機能が封印された。

過剰な役割定義が、AIの「現場での実現性」を損なっていたのです。
「完璧な審査官」を作ろうとした結果、「画像を見ない審査官」が生まれていました。

「いや、そんなことあるって知らんがな。」
オフィスで声に出ていたらしく、周りから視線を感じました・・・。
みなさんはそんなことがないよう、ご注意くださいね。

4. では、どうすればよいのか

解決策は、シンプルでした。

画像読み込みは捨てて、引き続き、テキスト解析に特化したモードで動かせばいい。
ひと手間かかるけど、画像ファイルもPDFに変換すれば良いのですから。

反対に解析精度を落としても画像を読ませたい場合。
役割定義の中に、一文加えるだけでよいのです。

この一文があれば、AIは「テキスト解析の精度を保ちながら、画像からも情報を拾う」という動き方を選択できます。

どちらが正解ではなく、目的に合わせて設計する、という発想です。

5. 実務への応用ヒント

今回の体験から、Gem作成の指針として整理できたことが3つあります。

① 「読めない」は、高性能の証でもある
特定の形式が読み込めない時、それはそのGemが特定の業務に特化した結果かもしれません。まず役割定義を疑ってみてください。

② 役割の「責任の重さ」がモードを決める
「審査官」「校閲者」などの厳格な役割は、AIをテキスト特化モードに誘導します。「デザイナー」「添削者」などの視覚的な役割は、画像認識を優先させます。

③ プロンプトに「How（どうやって処理するか）」を加える
役割（Who）と目的（What）だけでなく、処理方法（How）を明示することで、意図した動きに近づけられます。

AIに「不具合だ」と言われながら、ログの山と格闘していたあの数日間。
正直、かなり消耗しました。

でも今は、あの体験があってよかったと思っています。

役割定義がAIの動き方を変える、という感覚は、実際に「ハマって」みないと掴めないものでした。

AIは魔法の道具でも、万能の部下でもありません。
こちらがどんな役割を与えるかによって、その能力の使い道が変わる道具です。

使い手の「設計力」が、そのままAIの出力に返ってくる——
それが、今回一番身に染みたことかもしれません。
今回の私の体験が、少しでもみなさんのAI活用時の気づきになれば、幸いです。

✅ 今回の体験から得たAIの教訓

教訓①　「読めない」はバグより先に役割定義を疑え

AIが特定のファイルや形式を無視する時、システム障害より先に「この役割がそうさせていないか」を確認する。

教訓②　役割定義は「何をするか」だけでなく「どう処理するか」まで書く

役割（Who）と目的（What）だけでは、AIはリソースの使い方を自分で決める。処理方法（How）を一文添えることで、意図した動きに近づく。

教訓③　AIのリソースは有限。最適な役割設計が、最大の出力を引き出す

厳格すぎる役割は、AIの柔軟性を削る。緩すぎれば、専門性が失われる。「現場で実現できる改善策」を設計するのと同じ発想で、役割定義の「最適解」を探すことが、AIを使いこなす鍵になる。

※本シリーズは、食品品質管理の現場でAIを使い倒している私の実体験をもとにしています。第1話［起］～第3話［転］と合わせてお読みいただけると、より深く理解できます。↓