技術文書・図面のAI活用　機電②

当日お答えしたとおり、まずはそのままの拡張子で渡してみてください。読めない形式のときは、Gemini 側が読み込めない旨を返してきます。そうなったら、PDF に書き出すか、画面をスクリーンショットで撮って渡す、という順で進めていただくのがよいと思います。

見分け方は「自分のパソコンで開けるか」ではなく「Gemini が中身を読める形式か」です。専用ツールの独自形式は、たいてい中身が読めません。

書き出し方で精度が変わります。PDF に書き出せるなら、スクリーンショットより PDF のほうが線も文字も鮮明です。画像で渡すときは、画面全体ではなく見せたい範囲だけを切り出したほうが、細い線や小さい文字を拾ってくれます。

おおむねそのとおりだと思います。当日お答えしたとおり、CSV と画像に切り分けて渡すのがおすすめです。

Excel のファイルは、AI 側で中身を読むときに表の構造をたどり直しています。セルに貼った画像は、そのときに位置の情報が失われたり、読み飛ばされたりしやすいです。結合セルや複数シートも苦手です。

• 表の部分は CSV に書き出す。1行目を見出しにして、結合セルをほどいておくと、そのまま読めます。
• 画像は1枚ずつ別のファイルとして渡し、「この画像は〇〇の写真です」と一言添える。

「単一の形式のほうがよい」というより、AI にとって解釈の余地が少ない形にほどいてから渡す、と考えていただくのがよいと思います。表は表として、画像は画像として渡す。人が読むために作ったレイアウトは、いったん崩すのが近道です。

本文の並びだけに任せるのは、いまのところ避けたほうがよいと考えています。明示したほうが安定します。

Markdown の中に ![図1 配置図](図1.png) のように書いてあっても、AI に届くのは「本文のテキスト」と「添付された画像ファイル」で、その2つの結び付きは、渡し方によっては失われます。人が見るときの位置関係は、AI にはそのまま伝わらないことがあります。

手当ては2つあると思います。

• 渡すときに一言添える。「添付の1枚目が本文の図1、2枚目が図2です」と書くだけで、取り違えはかなり減ります。
• 本文側に、画像の中身を文章で書いておく。図の下に「図1は、コンベアの下流に検査装置を置いた配置を示す」と2行足しておくと、画像が読まれなくても、本文だけで意味が通ります。

ご指摘のとおり、説明用の画像を入れておくと人の可読性は上がります。そのうえで、その画像の要点を文章でも書いておく形が、人にも AI にも効く作り方だと思います。配布した仕様書の図1と、その下の一文が、まさにその形になっています。

画像を1枚渡して、そのまま動作を計算させるのは、いまの精度では難しいと考えています。線をたどって結線を取り違えると、その先の計算がすべて崩れるからです。二段構えにするのが現実的だと思います。

• まず、読み取りだけをさせて、人が直す。「この回路図から、部品の記号、型番、定数、接続されているノードの一覧を表にしてください。読み取れない箇所は記載なしとしてください」と頼み、表を自分で直します。本日の演習2で、主回路と操作回路を言葉で説明させたのと同じ段です。
• 直した表をもとに、ネットリスト（SPICE 形式など）をテキストで出させます。それを回路シミュレータに読ませれば、計算はシミュレータ側の仕事になります。AI に数値を計算させるより確かです。

記号の読み取りを安定させるには、図の中で使っている記号の凡例を一緒に渡すのが効きます。社内で使っている記号や略号の一覧があるなら、それを先に読ませてから図を渡してください。配布した回路図に記号の説明を書き添えてあるのは、この考え方によります。

回路図が手元の専用ツールで作られているなら、ツール側からネットリストを書き出せることが多いです。書き出せるなら、画像を読ませるより、そのテキストを渡すほうが確実です。

当日、その場で2つの直し方が出ていました。どちらも有効です。

• ソースを削除して、もう一度アップロードする。取り込みの途中で表の一部しか読めていないことがあり、入れ直すと6種類とも答えるようになります。
• 聞き方を変える。「異常コードの一覧を教えてください」と全体を聞くと、6つとも返ってきます。最初の質問が A-102 のような個別の話だと、関係する行だけを拾ってくることがあります。

原因は、PDF の読み取りが毎回同じ結果にならないことにあります。表は特に崩れやすく、行の途中で切れると後半が落ちます。ご指摘のとおり、PDF の読み取りは安定しないときがある、というのは現場の感覚として正しいと思います。

大事な資料を入れるときは、入れた直後に「この資料の見出しを全部挙げてください」と聞いて、抜けがないかを確かめるのがおすすめです。表が多い資料は、Markdown やテキストに書き出してから入れると安定します。

当日、Flash では話が進まず、Pro に切り替えたら誤りを認めた、とご報告をいただきました。とても良い観察だと思います。

一度出した答えを AI が守ろうとするのは、それまでのやり取りが前提として残り続けるためです。同じチャットで「違います」と伝えるほど、前の答えを補強する説明が返ってくることがあります。手当ては3つあると思います。

• 新しいチャットで、言い方を変えて聞き直す。前の答えを引きずらないので、いちばん早いです。
• 図の一部だけを切り出して渡す。今回なら、操作回路の PB1 のまわりだけを拡大した画像です。読み取りの失敗と、説明の失敗を切り分けられます。
• 賢いモデルに替える。今回の Pro のように、線のつながりを追う仕事は、上位のモデルのほうが確実です。

そのうえで、図で確かめられるのは図だけです。AI と押し問答をするより、自分の読みが正しいかを図に戻って確認して、そこで打ち切るのがよいと思います。

当日お答えしたとおり、いまのローカルLLMは現場で十分に効果を出せる水準まで来ていると考えています。エージェントとして動かすこと、画像を読ませること、テキスト以外のファイルを作らせることも、すべて実現できます。

問題はコストと技術です。導入の費用も、動かし続ける費用も高く、社内に知見が要ります。会社の規模にもよりますが、数千万円かけるのが一般的な水準です。そのため「それなら最初から Enterprise のプランを配ったほうが安い」と判断される企業のほうが多い、という印象です。

ただ、Enterprise でも機密情報の入力は禁止、という運用も実際にあります。そういう現場ではローカルLLMが必要になります。構築支援と毎月の保守を専門にしている会社もあり、特定の業界では需要が増えている認識です。モデルは、重みが公開されている中国系のものを使うことが多いようです。

始め方としては、1台の作業用パソコンに小さいモデルを入れて、社内文書の要約など1つの用途で試し、どのくらいの品質で足りるかを測るところからだと思います。そのうえで、必要なメモリ量とサーバー費用を見積もると、社内の説明がしやすくなります。

当日お答えした内容を、あらためて書きます。

生成AIの資格は、あくまで名目に近いものだと考えています。いちばん大きいのは、学ぶ過程で得た知識と、学ぶという行為を通してその分野に深く入っていく姿勢が身につくことだと思います。講師自身も「ないよりはあったほうが安心できる」という、わりと漠然とした理由で取り始めたところがあります。

具体的な効果は実感しづらいのですが、わかる人が見れば、その資格の価値と、裏にある努力が伝わります。生成AIは、活用の経験もリテラシーも外からは見えにくいので、それを示す手段としては役に立つのではないかと思います。

どれほど重視されているか、というご質問については、採用や評価の場面で資格そのものが決め手になることは少ない、というのが正直なところです。それよりも「自分の仕事でこう使って、これだけ時間が減った」と1つ語れるほうが強いです。資格の勉強で土台を作り、実際の活用を1つ作る。この2つがそろうと、説得力がまったく違ってくると思います。

そう進んでいくと考えています。Jev は本当にすごい技術で、講師も本気で研究しているところです。似たものを以前から自分でも作っていたので、ようやく出てきた、という気持ちもあります。いま運用している6つほどのサービスのうち、いくつかの基幹を Jev に差し替えられないか検証しています。

文章を組み立てて返すモデルは、どうしても考える時間がかかります。現場の制御のように、決まった判断をすぐ返してほしい場面では、その用途に絞った軽い仕組みのほうが向きます。用途で使い分けが進む、という見方でよいと思います。

当日チャットでご紹介した記事です。

そこまでは発表されていなかったと思います。当日お答えしたとおり、予想になりますが、最低限の情報は事前に学習させていたのではないかと考えています。コースの配置、人間のドライバーの記録、マシンの仕様などです。

走行中のカメラやセンサーの情報をその場で処理して操作を決める部分と、事前に学ばせておく部分は、普通は分けて作ります。ゼロから走りながら覚えるのは、実車では危険すぎるためです。

記事の詳細が見つかったら、あらためてお伝えします。

お試しいただいてうれしいです。「〇〇、いや〇〇じゃなくて××」と話すと ×× だけが残る、という挙動ですね。精度がとても上がっています。Gemini は特にマルチモーダル、つまり文字と音声と画像をまとめて扱えることを前面に出しているので、ここは他に負けないでほしい気持ちもあります。

ただ、各社の差は小さくなってきている印象です。裏で使われている技術や仕組みが似たものになりがちだからです。Google は自社のモデルを使っている点が少し違います。

本日の演習でも、図面や回路図をそのまま渡せたのは、この「文字以外も同じ頭で読む」性質によるものです。

相談相手として使いたい、という用途なら、開発者向けの道具を経由するより、対話のサービスを直接契約するほうが素直だと思います。Claude であれば個人向けの下位プランでも同じモデルに相談できて、上位プランとの違いは主に使える量です。

Cursor のような開発者向けの道具は、複数のモデルを1つの契約から呼べるのが強みです。コードを書く作業が多いなら、そちらのほうが一度に済みます。逆に、相談が中心で開発をしないなら、機能の大半を使わないことになります。

プランの名前と、どのモデルがどのプランで使えるかは、数か月で変わります。契約の前に、公式の価格ページで現在の条件を確かめてください。

もう一つの選び方として、使った分だけ払う API の従量課金もあります。相談の頻度が月に数回なら、定額より安く収まることがあります。