添付アイコンとサムネイルは表示されるのに、モデルが画像を見ていません。
今週は、画像の表示ではなく「モデル宣言」「MCP・ACP転送」「永続化」「入れ子転送」「復旧」の5項目を別々に確認し、1つでも証拠が欠けたら本番投入を止めるのが最短です。
本記事は、スクリーンショットからUI不具合を調べるAgent開発者、MCPやACPでエディター・外部ツールを接続する基盤担当者、遠隔Macで視覚タスクの証跡を保存して引き継ぐテスト・運用チーム向けです。
最終更新:2026年8月18日。確認対象は同日現在の公式Release、モデル設定と画像入力の記載、関連コードです。公式のrc.7 Releaseでは、MCP・ACPの永続化画像添付とPTC Modeでの入れ子画像転送が案内されています。一方、実際に画像を受け付けるかはモデル能力の宣言と上流エンドポイントに依存します。公式APIのChat Completions仕様は、現在もメッセージ本文をテキストとして記載しています。(公式Release、公式リポジトリ、公式API仕様) (github.com)
表示される添付と、読める画像は別物です
検収で最初に切り分けるべき問題は、画面に画像が存在することと、推論リクエストに画像が含まれることが同じではない点です。UIのキャッシュ、会話ログの参照、実ファイルの保存は別の層です。
DeepSeek Harnessの画像添付を確認する場合、モデル名だけで画像対応と判断してはいけません。自動補完されたモデル設定、自作Providerの宣言、実際の上流レスポンスを並べて確認します。自作Providerが画像対応を宣言していても、上流APIが画像を処理する保証にはなりません。
DeepSeek Harnessが画像の送信を拒否する場合、最初に何を確認するか
まず、モデル設定に画像入力能力が明示されているかを確認します。次に、送信直前のリクエストで画像が本文または添付参照として残っているかを確認します。最後に、拒否した責任ノードを、UI、Provider、MCP・ACP、上流エンドポイントのいずれかに固定します。
注意:アップロードボタン、プレビュー画像、成功表示だけでは合格にしません。モデルが画像内の固有情報を返した記録が必要です。
第一段階:能力宣言を先に固定する
テスト画像には、文章だけでは推測しにくい識別情報を入れます。例えば、画面内に「検収用 A-17」「青い四角」「右下の赤線」のような複数の特徴を配置します。実際の顧客画面、秘密鍵、リポジトリ内容は使いません。
| 確認層 | 実施する操作 | 残す証拠 | 判定 |
|---|---|---|---|
| モデル設定 | 画像入力能力の宣言を確認 | 設定ファイルの該当行 | 宣言あり・なし |
| 送信前 | 添付名、順序、タスク文を記録 | 送信ログまたは画面記録 | 欠落なし |
| 上流応答 | 固有情報を質問 | 応答本文とエラー | 認識・拒否・無関係 |
| 責任ノード | 失敗地点を特定 | Providerまたは経路ログ | 修正担当を確定 |
公式API仕様では、モデル識別子、メッセージ、ツール呼び出し、トークン使用量などが定義されていますが、モデル設定に画像入力があることだけで画像理解まで証明できません。(Chat Completions APIのフィールド定義) (api-docs.deepseek.com)
同じ画像を送る経路と、失われる経路を比較する
MCPとACPでは、添付の受け渡しがUIの中だけで完結するとは限りません。送信順、タスク説明との結び付き、子タスクへの参照方法を確認します。画像1と画像2を用意し、「画像1の左上の文字」と「画像2の右下の色」を別々に質問すると、順序の入れ替わりを検出しやすくなります。
| 経路 | 検査内容 | 合格の条件 | 失敗時の見方 |
|---|---|---|---|
| 直接モデル | 画像と質問を同じ要求で送信 | 固有情報を正しく返す | モデルまたはProvider |
| MCP | ツール境界を越えて添付を送信 | 添付参照とタスク文が一致 | MCP変換・保存処理 |
| ACP | 接続先エディターや外部ツールへ転送 | 受信側で同じ画像を再読込 | ACP経路・権限 |
| 混在経路 | MCPからACPへ連続転送 | 順序と参照先が保持される | 中継ノードを分割確認 |
MCPとACPの画像添付は永続化できるか
rc.7の機能確認だけで「どの環境でも残る」とは判定しません。MCP・ACPが保存するのは、画像本体、添付ID、会話内参照のどれかを分けて記録します。画面更新後にサムネイルが残っていても、実ファイルを再読込できなければ、永続化は不合格です。(rc.7 Release一覧)
永続化はキャッシュと会話記録を分けて判定する
次の順序で状態を壊します。ページを更新する。クライアントを切断して再接続する。プロセスを再起動する。そのたびに、同じ画像への参照と、画像本体の再読込を確認します。
| 状態 | 確認操作 | 合格条件 | 不合格の例 |
|---|---|---|---|
| 画面キャッシュ | ページを更新 | 表示だけでなく再読込可能 | サムネイルだけ残る |
| 会話記録 | 旧会話を開く | 添付IDと本文が一致 | 名前だけ残る |
| 実ファイル | 画像を再取得 | 同一内容を読める | 参照切れ・権限拒否 |
| 再起動後 | プロセスを再起動 | 同じ質問に再回答できる | 新規送信だけ成功 |
遠隔実行時に画像が失われていないことをどう確認するか
遠隔Macでは、添付資産の保存場所、会話ファイル、所有者とアクセス権、交接後の再現性を記録します。遠隔で動いていること自体は、永続化でもデータ分離でもありません。担当者を替えた後に同じ会話を開き、画像を読み直せるかまで確認します。
遠隔Macの交付検収ガイドでは、環境の引き渡し時に確認すべき接続情報や運用項目を整理しています。画像資産の検収では、そこに「添付ファイルの再読込」と「会話復旧」を追加します。
入れ子タスクでは、親子で別の証拠を要求する
PTC Modeや子タスク連鎖では、親タスクと子タスクに同じ質問を投げません。親には画像Aの全体構成、子には画像Bの細部を読ませます。子タスクが画像Aを誤って参照していないか、または画像そのものを受け取らず親の説明文だけを受けていないかを確認します。
PTC Modeの入れ子タスクは元画像を受け取れるか
受け取れるかどうかは、親タスクの成功表示では決まりません。タスク軌跡、子タスクの受信内容、画像固有情報への回答を3点セットで保存します。失敗時は、親から子への転送、子タスクのProvider、上流モデルのどこで止まったかを記録します。(公式コードと変更履歴)
復旧時の再送と、停止すべき再試行を分ける
画像を含む旧会話を復旧するとき、上流が画像を拒否した要求を同じ形で再生し続けるケースがあります。これは「復旧成功」ではなく、失敗要求のループです。
第二段階:安全な回退を先に用意する
次の順序を固定します。
- 旧会話を複製し、原本を変更しない。
- 添付ID、ファイル参照、送信回数を記録する。
- 画像を外したテキストのみの要求を送る。
- 画像対応を明示した別モデルまたはProviderへ切り替える。
- それでも失敗する場合は新規会話を作る。
- 再送回数と拒否理由を検収記録に残す。
経験則:画像拒否が同じ要求で繰り返されるなら、再試行回数を増やす前に添付を除去します。復旧機能の検査と、上流の画像能力の検査を混ぜないことが重要です。
合格・制限付き・拒否を一枚で決める
検収結果は「使えた」ではなく、作業単位で分類します。画像を必須とするUI診断、画像を補助証拠として使うコード確認、画像を保存して後日再現するテストでは、必要な合格条件が異なります。
| 判定 | 条件 | 利用可能な業務 | 次の対応 |
|---|---|---|---|
| 合格 | 5指標すべてで証拠あり | 本番の視覚タスク | 監視項目を登録 |
| 制限付き | 画像理解または復旧に制限あり | 試用・低リスク確認 | 対応モデルと範囲を明記 |
| 拒否 | 転送、保存、復旧の証拠が欠落 | 画像必須業務は不可 | テキスト証拠へ回退または構成変更 |
そのまま使える検収チェック
- [ ] モデル設定に画像入力能力の宣言がある
- [ ] 自作Providerの宣言と上流の実挙動を分けて記録した
- [ ] 識別可能なテスト画像を使った
- [ ] 添付順、タスク文、実際の応答が一致した
- [ ] MCP経由で画像参照が保持された
- [ ] ACP経由で受信側が画像を再読込できた
- [ ] 更新、再接続、プロセス再起動後に再利用できた
- [ ] PTC Modeの子タスクが指定画像の細部を読めた
- [ ] 旧会話の復旧で同じ要求が無限再送されなかった
- [ ] 遠隔Macの保存場所、権限、交接後の再現性を確認した
- [ ] 本番投入、試用、拒否のいずれかを明記した
- [ ] 敏感なスクリーンショット、秘密鍵、顧客データを記録から除外した
画像添付の問題をMCP接続全体の問題と誤認しないため、接続手順はDeepSeek HarnessのMCP接続ガイドと分けて管理します。自作モデルサービスを使う場合も、カスタムモデル設定の確認項目だけで画像対応を確定せず、今回の識別画像テストを追加してください。
現在のローカル環境や単純なテキスト中心のクラウド構成では、画像ファイルの保管場所が担当者ごとに違う、再起動後の参照が切れる、MCP・ACPのログと会話記録が分散する、といった欠点が残りやすいです。画像を含むAgentをチームで検証するなら、独立した遠隔Mac環境で添付、会話、権限、交接後の再現性をまとめて確認できる方が、原因切り分けをやり直しにくくなります。
一時的な視覚タスク、外部ツール連携の検証、チーム引き継ぎ用の検収環境が必要なら、MESHLAUNCHのMacレンタルを候補にできます。ただし、長期の安定した高負荷運用や物理インターフェースが必須の案件では、自前Macや専用環境の方が適する場合があります。まずは空の検収表で画像タスクを一巡させ、保存と復旧まで必要だと分かった段階で、遠隔Mac環境を比較するのが安全です。