General AI × Real Work

汎用AIを、
現実の仕事につなぐ。

モデルそのものを用途ごとに作り込むことより、現実の状態を意味として渡し、必要な道具を使わせ、結果を確かめることが重要になる仕事が増えています。M&Tでは、この接続と検証をCAD/CAE、Web、IT運用で実際に試しています。

The idea came first

先に考えていたのは、「AIそのもの」ではなく、AIと現実をつなぐ方法です。

生成AIがCADやCAE、Web、IT運用などを自然言語で扱う時代が来る。そのとき必要になるのは、用途ごとに新しいAIを作ることではなく、汎用AIに、現実の状態を理解できる形で渡し、道具を使わせ、結果を確かめる仕組みだと考えていました。

現在、汎用AI、RPC、MCP、CLI、APIなどが急速に実用化され、その考え方を実際の仕事で試せるようになっています。

A simple structure

基本は、とても単純です。

難しい専用AIを毎回作るのではなく、AIが仕事を進められる環境を整えます。

1. 意味で見る

名前、属性、関係、座標、状態、ログ、数値などを、AIが理解しやすい形で渡します。

2. 必要なら画像で補う

形状、コンター、GUIなど、言葉や数値だけでは足りない部分を画像で確認します。

3. 道具を使う

CLI、API、RPC、MCPなどを通して、AIが実際のソフトウェアや計算環境を操作します。

4. 結果を確かめる

実行できたかだけでなく、意図した状態になったかを再観測して確認します。

Why language matters

画像を毎回「見る」より、世界を意味として渡す。

画像認識は有効です。ただし、すべてを画面キャプチャから読み取らせる必要はありません。構造化できる情報は、最初から言語・属性・関係・数値として渡した方が、速く、追跡しやすく、再確認もしやすくなります。

主経路：言語・意味情報

対象の名前、階層、属性、接続関係、位置、履歴、現在状態などを外に出し、AIが直接扱えるようにします。

「何を指しているか」「変化した後も同じ対象か」「意図した状態になったか」を、できるだけ意味情報として確認します。

補助経路：画像

形状の違和感、解析コンター、GUI上の状態など、言語化しにくい情報は画像で補います。

画像は重要ですが、AIに世界を理解させる唯一の入口ではありません。

The loop

観測 → 判断 → 操作 → 再観測。

多くの仕事は、この反復で進められます。これは特別な魔法ではなく、ReAct型のエージェントにも通じる基本的な考え方です。

状態を知る → 次の操作を考える → 道具を使う → 結果を見る → 必要なら修正する

重要なのは、モデルそのものにすべてを抱え込ませることではありません。高性能な汎用AIが、現実の対象を観測し、適切な道具を使い、結果を確かめられるようにすることです。

What we are testing

同じ考え方を、違う仕事で試しています。

用途ごとに別のAIを開発しているわけではありません。同じ汎用AIに、違う道具と状態情報を渡しています。

CAD / CAE

Cubitを操作し、形状・メッシュ・解析条件を扱い、OpenFOAM、CalculiX、SPECFEM3Dなどの解析へつなげます。

CAE × 生成AIを見る

Web制作・運用

ページ作成、翻訳、リンク確認、ブラウザ確認、修正、配備までを同じ反復で進めます。

AIによるサイト運用を見る

Linux / IT運用

状態を確認し、コマンドを実行し、結果を読み、必要なら修正する。GUI操作と本質は同じです。

技術調査・検証

資料を読むだけでなく、実際にソフトウェアを動かし、結果と条件を照合して確かめます。

What changed

変わったのは、汎用AIが「道具を使って仕事を進める」範囲が広がったこと。

以前は、業務ごとにルール、検索、画像認識、コード生成、ワークフローなどを個別に作る必要がありました。現在は、少なくともM&Tが試している業務では、検索、コード生成、操作、確認を一つの汎用AIから横断して進められる場面が増えています。

だから最初に問うべきことは、「どんな専用AIを開発するか」ではなく、「今ある汎用AIに、何を見せ、どんな道具を渡せば、この仕事を進められるか」だと考えています。

これは、専用AIや専門モデルが不要という意味ではありません。高速な予測、低コストな反復、厳密なドメイン制約、組織標準の再現などでは、専用モデルや専用エージェントが有効です。まず汎用AI＋状態＋道具＋検証でどこまで進められるかを見極め、その上で必要な専門化を足す、という順序を取ります。

Open source × AI

「枯れた技術」が、AIで再び熱くなる。

ここでいう「枯れた技術」は、価値がない古い技術という意味ではありません。長く使われ、ソースコード、資料、事例、入出力形式、失敗例まで蓄積した成熟した技術です。これまでは「自分の用途にあと少し足りない」部分を埋める人手が高くつき、採用を諦めることがありました。AIは、その最後の差分を埋める手段になりつつあります。

Residual-driven adaptation

OSSを作り直すのではなく、必要な状態との差を小さくする。

欲しい状態 → 今あるOSS → 残差を観測 → AIで補う → 再実行・再観測

まず、既存のオープンソースをそのまま動かします。次に「欲しい機能・結果・操作」と「現在できていること」の差を、残差として具体化します。AIには全部を書き直させるのではなく、残差を小さくするための設定、スクリプト、変換処理、アダプター、補助コード、テストを作らせます。実行後にもう一度観測し、残差が残れば次の小さな修正へ進みます。

既存資産を捨てない

成熟したソルバー、ライブラリ、コマンドライン、ファイル形式をそのまま使い、足りない接続部分だけを補います。ゼロから専用品を作る前に、すでにある資産を再評価できます。

自分に必要な機能へ近づける

「製品にその機能がない」で終わらず、前処理、変換、実行、後処理、検証のどこに残差があるかを分けます。AIは、その小さな差分を反復して埋める役になります。

改造後も検証する

AIがコードを書けたことは成功条件ではありません。入力条件、物理量、収束、出力、再現性など、用途ごとの判定基準で結果を再確認します。

M&Tで試している例

M&Tでは、OpenFOAM、CalculiX、SPECFEM3DなどのオープンソースCAEを、Cubitや生成AIからつなぎ、入力生成、実行、結果抽出、再計算、検証までの残差を一つずつ減らす形で試しています。目的はOSSそのものを別製品へ作り替えることではなく、必要な用途に対して、使える状態まで近づけることです。

OpenFOAMの実例を見る CAE × 生成AIの実証を見る既存コードベースへのAI適用例

Human + AI + Browser

同じCAE画面を見ながら、人とAIが協業する。

M&Tでは、Debian上のCubit GUIをXvfb / Mesa / noVNCでブラウザーに公開し、人とAIが同じ作業画面を見ながら開発・確認できる環境も試しています。AIはRPCやコマンド、スクリーンショット、GUI操作を使い、人はnoVNCの画面から進行を監督し、必要なときにその場で介入します。

これにより、AIだけが見ている自動化ではなく、人とAIが同じActual（現在状態）を共有して残差を確認する協業になります。GUI中心の成熟したツールでも、CLI / RPC / APIと画面共有を組み合わせることで、AIと人が同じ対象を扱える作業環境へ拡張できます。

AI / Work Design

能力を隠していたボトルネック

生成AIが小さくするのは、専門性そのものではなく、専門性を仕事へ出すまでにあった「翻訳・表現・操作」の壁です。

長くならないよう、ここからは3つの短い記事に分けました。左右の矢印、またはスマートフォンのスワイプで次の記事へ進めます。

01 / INPUT → OUTPUT

入力と出力が決まりやすい仕事

入力と出力の対応が明確な仕事ほど自動化しやすい。専門業務との違いを整理します。

読む

02 / SUPERVISE

作業者から、監督・指揮する側へ

AIに作業を任せ、人間は目標・進行・結果を監督する。そこで必要になる基礎力を考えます。

読む

03 / HOLD

保留（HOLD）— 分からないまま進めない

分からないときは無理に完了にしない。あとから再開できる状態として残す考え方です。

読む

A broader movement

これは、M&Tだけの考え方ではありません。

2026年の公開情報を見ると、この方向はM&T固有ではありません。OpenAIは、同じ基盤モデルを使っていても、コンテキストとツールを与えて業務を実行させる運用に差が生まれていると報告しています。Anthropicは、ツールが意味のある文脈を返す設計を重視し、Microsoft Researchは、エージェントの途中の手順と最終結果を分けて検証する必要性を示しています。CAE・EDAでも、AIが実際のソフトウェアを操作し、物理計算や検証へつなぐ実装が広がっています。