UNIT 00LAB NOTES FIG.00 · EYECATCH

2026年AI技術地図｜生成AI・Agent・RAG・Physical AIを評価・安全・コストで体系化する

2026年のAI技術をFoundation Model、Reasoning、Multimodal、Agent、RAG、AI Coding、AI for Science、Physical AIまで体系化。MermaidによるAI技術地図を示し、ベンチマーク、ハルシネーション、セキュリティ、コスト、遅延、規制、実務導入の評価方法を解説します。

DOC NO.EKP-00-1039

DATE2026-10-14

REVB

READ約 12 分

今日の到達点

生成AIを「モデル」「知識・接続」「アプリケーション」「実行基盤」「横断的な統制」に分け、12回の学習内容を一枚の技術地図へ統合できる。
ベンチマーク、実務評価、レッドチーミング、システムカードの役割を区別できる。
ハルシネーション、プロンプトインジェクション、情報漏えい、エージェントの権限逸脱に対策を割り当てられる。
品質・費用・遅延・安全性を同じ試験条件で比較し、導入可否を判断できる。
技術地図を継続更新するための観測指標と学習課題を設定できる。

AIの進歩を「モデル名」ではなく「システム」で理解する

2026年のAIを理解するには、単一の大規模言語モデル（LLM）の性能だけを追っていては足りない。実務で使われるAIは、モデルに加えて、検索、外部ツール、データベース、権限管理、評価、監視などから構成されるシステムだからだ。

たとえば「仕様書から設計チェックリストを生成する」処理では、文章生成が正しくても、古い規格を参照したり、アクセス権のない資料を取得したり、承認前に設計データを更新したりすれば失敗である。モデルが高性能であることと、システムが安全に仕事を完了できることは別の評価対象となる。

本稿は「AI Landscape 2026」最終回として、これまでの技術を構造化し、評価・安全・コストという横断軸を重ねる。

2026年AI技術地図：五つの層と横断統制

次の図は製品一覧ではなく、機能と責任の関係を示す概念図である。上下は厳密な依存順序を意味しない。各層は複数の経路で結合し、科学AIやロボティクスでは専用モデルや制御系が追加される。

flowchart TB
  subgraph Apps["利用・応用レイヤ"]
    Coding["AI Coding"]
    Science["AI for Science"]
    Robotics["Physical AI / Robotics"]
    Business["業務アプリケーション"]
  end
  subgraph Orchestration["知識・接続・実行レイヤ"]
    Agents["Agents / Workflows"]
    Knowledge["Context / RAG / Memory"]
    Protocols["API / MCP / A2A"]
  end
  subgraph Models["モデル能力レイヤ"]
    Foundation["Foundation Models"]
    Reasoning["Reasoning"]
    Multi["Multimodal / Generative"]
  end
  Infra["実行基盤：Cloud / Local / Edge / Compute"]
  Governance["横断統制：Evaluation / Safety / Security / Cost / Privacy"]
  Foundation --> Reasoning
  Foundation --> Multi
  Models --> Orchestration
  Orchestration --> Apps
  Infra --> Models
  Infra --> Orchestration
  Governance -.-> Models
  Governance -.-> Orchestration
  Governance -.-> Apps

モデル能力レイヤ

Day 1〜4では、事前学習されたFoundation Modelを起点に、指示追従、推論時の計算、テキスト・画像・音声・動画を扱うMultimodal AIへ展開した。Reasoningは必ずしも独立したモデル群だけを指さず、推論手順や検証方法を含む能力・運用上の分類でもある。

ここで評価するのは、与えられた入力に対する出力の妥当性、再現性、必要な計算量などだ。画像認識の成功率を、そのまま設計判断の正確性とみなしてはいけない。

知識・接続・実行レイヤ

Day 6〜8で扱ったAgent、MCP・A2A、Context・RAG・Memoryが該当する。RAGは必要な根拠を検索してモデルに与え、Agentはツールの実行結果を受けて次の操作を選ぶ。APIやプロトコルは接続の約束事であり、取得データの正しさや操作の安全性まで保証しない。

「長いコンテキストがあるから検索は不要」「MCPを導入すれば安全」といった結論は成立しない。検索の鮮度、権限、ツールの許可範囲は個別に設計する。

利用・応用レイヤ

Day 5、10、11のAI Coding、AI for Science、Physical AIは、いずれもモデル出力を現実の成果へ結びつける領域だ。ただし検証対象は異なる。コードならテスト、科学なら再現実験、ロボットなら物理的安全性と制御安定性が重要になる。

実行基盤と横断統制

Day 9のCloud・Local・Edgeは「どこで推論するか」という配置の問題である。ネットワーク、GPU・メモリ、電力、運用要員が選定条件になる。一方、評価・安全・費用・個人情報保護は、特定の一層に閉じず全体を横断する。

評価は四段階に分ける

Benchmark：共通条件で能力を測る

Benchmarkは、一定の問題集合と採点基準で能力を比較する仕組みだ。ただし結果には、問題の公開範囲、採点器、ツール使用の有無、推論予算、試行回数、言語、データ汚染の可能性が影響する。

異なる設定で得られた数値を横並びにして「AがBより優秀」と結論づけるのは危険である。安全性評価の例として、MLCommonsのAILuminateは危害カテゴリに基づく評価枠組みを公開している。ただし対象は定義されたテスト条件に限られ、長期稼働する業務Agentの安全性を全面的に保証するものではない。

Task Evaluation：実際の業務で完了を測る

導入前には、自社業務を模した代表タスクを固定する。たとえば「図面注記から単位・公差・材料指定を抽出する」なら、正解データと照合し、未記載を推測して補っていないかを確認する。

成功率は次のように定義できる。

$$ S = \frac{N_{\mathrm{pass}}}{N_{\mathrm{total}}} $$

ここで $N_{\mathrm{pass}}$ は定義済みの合格条件を満たした件数、$N_{\mathrm{total}}$ は試験件数である。合格条件を後から変えず、試験集合・モデル版・プロンプト版を保存することが比較の前提となる。

Red Teaming：壊し方を探す

通常の評価が「できるか」を調べるのに対し、レッドチーミングは悪意ある入力や想定外の状態で「どのように失敗するか」を探る。検索文書に埋め込まれた偽の命令、過大なツール権限、データ持ち出し、繰り返し試行による回避などが対象だ。

System Card：評価の範囲と限界を読む

System Cardはモデル提供者が評価方法、既知のリスク、緩和策などを説明する資料である。たとえばOpenAIのo3・o4-mini System Cardは能力と安全性評価の枠組みを記載し、Google DeepMindのFrontier Safety Frameworkは危険能力の監視と対策の考え方を公開している。

これらは重要な一次情報だが、提供者の評価資料は利用者の現場検証を代替しない。公開日・対象モデル・評価条件を必ず確認する。

失敗モードを技術レイヤへ対応させる

失敗モード	発生しやすい場所	主な対策	確認方法
Hallucination（根拠のない生成）	モデル・知識	出典提示、根拠照合、未確認の明示	根拠付き回答の正答率
Prompt Injection	検索・ツール入力	外部文章を命令扱いしない、権限分離	攻撃文書を使った侵入試験
Data Leakage	接続・保存・ログ	最小権限、機密区分、ログの秘匿化	権限外データの取得試験
Tool Misuse	Agent・実行環境	操作の許可リスト、承認ゲート	誤操作・二重実行の試験
Stale Knowledge	RAG・Memory	更新時刻、版管理、失効処理	古い資料の混入率
Physical Failure	制御・機構	インターロック、独立保護、実機検証	異常停止・安全試験

OWASPのLLMアプリケーション向けTop 10（2025年版）は、Prompt Injectionや機密情報の漏えいなどを体系的に整理している。とくにAgentでは「誤った文章が出る」だけでなく「誤った操作が実行される」ことが問題になる。

権限はモデルではなく実行側で強制する

設計用Agentに「ファイルは削除しないで」とプロンプトで指示しても、それは安全境界にならない。削除APIを実行環境から与えない、承認済みディレクトリ以外を操作できなくする、変更前後の差分を残す、といった技術的制御が必要だ。

特に設備操作では、生成AIが作った提案をPLCやアクチュエータへ直接送る構成を避ける。制御系の許容範囲、非常停止、インターロック、フェイルセーフを独立させる。

費用・遅延・信頼性を同時に評価する

トークン単価だけでは総費用は決まらない

クラウドAPIでは、入力・出力・キャッシュ済み入力、検索やツール呼び出しなどで課金条件が異なる場合がある。一般化した費用の概算は次のように表せる。

$$ C_{\mathrm{total}} = C_{\mathrm{input}} + C_{\mathrm{output}} + C_{\mathrm{tools}} + C_{\mathrm{infra}} + C_{\mathrm{review}} $$

$C_{\mathrm{review}}$ は人間による確認・修正の人件費である。これはAPI料金表には載らないが、実務の総費用を左右する。モデル単価が安くても、再試行やレビューが多ければ逆転し得る。料金は改定されるため、数値を固定せず利用時点の公式料金表を参照する。

遅延は平均値より分布を見る

ユーザーが待つ時間は、モデル応答だけでなく、検索、ネットワーク、外部API、再試行、承認待ちを含む。平均時間だけでは遅いケースを見落とすため、中央値に加えてp95（95パーセンタイル）などを測る。p95は、測定した応答時間の約95%がその値以下となる境界を意味する。

品質・遅延・費用を比較するときは、同じタスク集合、同じ入力条件、同じ成功判定を使う。失敗した呼び出しを除外して「成功時だけの単価」を報告すると、実際のコストを過小評価する。

Cloud・Local・Edgeの選定は総所有費用で

LocalやEdgeはデータ移送を抑えられる一方、ハードウェア、保守、モデル更新、障害復旧を自ら担う。Cloudは初期導入を軽くできる場合があるが、通信・データ所在地・外部依存が課題となる。いずれも利用量と機密性、可用性の要求で判断する。

プライバシー・規制・著作権は地域と用途で変わる

AI利用では、入力資料の利用許諾、個人情報の取り扱い、生成物の権利確認、ログ保存期間、第三者への送信条件を区別する。モデルが技術的に処理できることと、法的に利用できることは同義ではない。

欧州AI法（AI Act）は段階的な適用日を定めている。2026年7月27日付の統合条文を反映した公式Article 113では、一般的な適用開始を2026年8月2日としつつ、規定によって別日程を設けている。高リスクAI関連規定の一部は2027年・2028年の適用日が示される。規制対象かどうかは、提供地域、システムの用途、事業者の役割、最新条文で個別に確認する必要がある。

米国NISTのAI RMFと生成AIプロファイルは、リスクをGovern・Map・Measure・Manageの観点で管理するための任意の枠組みを提供する。規制の適合判定そのものではなく、評価・記録・改善の設計に利用できる。

工学業務への接続：小さな検証システムを作る

例として「機械仕様書から設計条件を抽出し、チェック表を作る」AIを考える。ここでは設計の最終判断を自動化しない。まず検証可能な中間成果物を作る。

入力・処理・出力を固定する

入力は、公開可能な模擬仕様書、適用版が明記された規格抜粋、既知の正解表とする。処理は文書検索、条件抽出、単位正規化、根拠行の添付、未確定事項の列挙に分ける。出力は人間が確認できる構造化データとチェックリストだ。

{
  "requirement": "最高使用圧力",
  "value": 21,
  "unit": "MPa",
  "source": "模擬仕様書 p.3",
  "status": "needs_review"
}

上記の21 MPaはデータ形式を示す架空の例示値であり、設計推奨値ではない。根拠のない数値は推測して埋めず、status を未確認にする。単位変換や許容範囲判定は、可能ならテスト済みの通常コードに委ねる。

最小構成の合格基準

最初は模擬資料20件程度から始め、正解データと比較する。抽出漏れ、誤った単位、根拠の取り違え、権限外参照を別々に記録する。危険度の高い項目では「正答率が高いから採用」ではなく、重大な誤判定を許容しない承認プロセスを設ける。

同じ評価セットをモデル変更・プロンプト変更の前後で実行すれば、改善が実務上の効果を持つか検証できる。入力・出力・ルール・判定ログを分離して保存すれば、別モデルや別CADへ移行しても知識資産を再利用しやすい。

今後3年で追跡する九つの指標

技術地図は固定した予測図ではない。次の指標を定点観測するための分類表として使う。

指標	観測する内容	更新時の注意
実務タスク成功率	同じ業務セットでの合格率	試験データと合格基準を固定
重大失敗率	安全・権限・機密上の重大事故	軽微な誤答と区別
検証可能性	根拠・ログ・再実行手順の有無	引用の存在と正しさは別
p95遅延	利用者が待つ上位側の時間	再試行・ツール時間を含める
完了タスク当たり費用	API・インフラ・レビューの合計	失敗・再実行を含める
Agentの操作範囲	自律実行できる操作と承認境界	権限変更履歴を記録
RAGの鮮度	更新から検索可能になるまで	文書版・アクセス権も確認
配置自由度	Cloud・Local・Edgeでの選択肢	ライセンスと必要資源を確認
安全・規制対応	評価報告、仕様変更、適用日	地域・用途・文書版を記録