【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話［転］と合わせてお読みいただけると、より深く理解できます。↓
