0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@softbase(FullStack ITエンジニア)

【2025年のAI発展・重要マイルストーン総まとめ】設計・運用・セキュリティ・インフラの転換点と2026年予測

Posted at

2025年は、生成AIが「便利な文章生成ツール」から **“システムの実行主体（Agent）”**へと進化し、ソフトウェア設計・運用・セキュリティ・インフラの前提が変わった1年でした。

モデルの性能比較よりも重要になったのは、次のような システム的な論点です。

  • AIを本番運用する設計（SLO、フォールバック、コスト）
  • AIに権限を与える（または制限する）設計（Permission）
  • AgentがWeb/業務システムを操作する時代のセキュリティ（Prompt Injection含む）
  • 推論コストとレイテンシを含めた運用最適化（Caching / Routing）

この記事では 2025年をQ1〜Q4の流れで整理しながら、重要マイルストーンと実務への落とし込みをまとめます。
さらに、すぐ使える 図解＋テンプレ実装（安全なツール実行・監査ログ・Evals CI）も付けています。

TL;DR（結論）

  • 2025年は「モデルが強くなった」だけでなく、AIが “実行する存在（Agent）”としてプロダクトに組み込まれた年
  • 主戦場は「プロンプト」ではなく ルーティング／評価（Evals）／権限管理／監査ログ／ガードレール
  • Webは「人間UI」だけでなく、**AIが操作するユーザー（Agent）**も前提にする必要が出てきた
  • セキュリティは「Prompt Injection」など新しい脅威モデルへの対応が必須に
  • 2026年は Agent標準化・長期記憶・安全な実行・推論最適化・電力制約が主戦場になる

1. 2025年を理解するための4つの軸

軸A：モデル → 統合システムへ

  • 単一モデルの性能よりも 高速／深い推論／ツール連携／ルーティングを統合する方向へ
  • “モデル選定”より “運用設計” が価値になる

軸B：エージェント化（Agentic AI）

  • AIが “答える”から“実行する”へ
  • Web操作・業務システム操作・タスク遂行が現実化

軸C：推論コスト＆インフラ

  • GPU世代更新・推論最適化が進み
  • コストとレイテンシがプロダクト差別化の中心へ

軸D：安全・規制・ガバナンス

  • 企業導入が進み
  • 法制度・監査・事故対応が 実装要件になる

2. 2025年全年タイムライン：重要マイルストーン（Q1〜Q4）

Q1（1〜3月）：AIは“便利ツール”から“開発・運用プロセス”へ入り込んだ

Milestone 1：AIコーディングが「補助」から「工程」へ

  • コード生成だけでなく、レビュー、テスト生成、修正案、PR説明、設計補助へ
  • 品質保証に Evals（評価） が必要になる

整備すべきもの

  • ✅ AI生成コードのレビュー基準（静的解析、規約、セキュリティ観点）
  • ✅ テスト戦略（生成テストの信頼性）
  • ✅ 仕様・設計の“正”を置く場所（PRD / ADR）

Milestone 2：RAGが“検索”から“運用設計”の領域へ

  • chunk設計／embedding更新／キャッシュ／検索結果の検証／根拠提示が本番要件化
  • RAGは「ライブラリ」ではなく データ基盤として扱う必要が出た

Milestone 3：LLMアプリの“観測可能性（Observability）”が必須に

  • promptのバージョニング
  • 回答品質のメトリクス化
  • レイテンシ・失敗率・コスト監視
  • 会話ログ（個人情報・規約）管理

Q2（4〜6月）：マルチモーダル標準化／モデル競争が「品質×コスト」に移行

Milestone 4：マルチモーダルが標準化（テキストだけのアプリが古くなる）

  • 画像＋説明／スクショで質問が一般化
  • 入出力の スキーマ設計 が重要になる

Milestone 5：推論コスト競争が本格化（“高性能=高コスト”が崩れる）

  • 1リクエストあたりの推論単価がPLに直結
  • “使うほど赤字”になるAI機能が発生し始めた

整備すべきもの

  • ✅ キャッシュ（セマンティック含む）
  • ✅ ルーティング（高速・思考・安価）
  • ✅ AI機能もSLO対象にする

Milestone 6：長大コンテキスト競争で「設計」が変わる

  • 仕様書・ソースコード・ログをそのまま投入する設計が増加
  • ただし長文入力はコストが重く 最適化が必須

Q3（7〜9月）：統合型モデルで「モデル選定」→「運用設計」が決定的に

Milestone 7：統合型LLM（高速×推論×ルーティング）が主流へ

  • 速度／思考／ツール連携の統合が進み
  • “モデル選定”より “設計・運用” が価値になる

Milestone 8：企業導入拡大で「社内統制」が要件化

  • 情報漏洩、幻覚、誤操作、責任問題が表面化
  • “AIを入れる”＝“統制を整備する” に近づいた

整備すべきもの

  • ✅ DLP（持ち出し制御）
  • ✅ 監査ログ
  • ✅ Human-in-the-loop（重要操作前確認）

Milestone 9：オープンウェイトが本命化し「ハイブリッド戦略」へ

  • SaaSモデル＋セルフホスト＋用途別の使い分けが現実的に
  • ただし運用負荷（GPU/監視/更新）が増える

Q4（10〜12月）：AIブラウザ／AgentがWebを操作し、セキュリティが最重要テーマへ

Milestone 10：AIがWebを操作する時代へ

  • クリック・入力・予約・購入・社内ツール操作まで “実行するAI” が現実に
  • UIはセマンティック・安定構造が重要になる
  • Bot対策だけでなく Agent対策 が必要になる

Milestone 11：Indirect Prompt Injectionが“構造的脅威”として確定

外部コンテンツ（Webページ等）に埋め込まれた指示でAIが乗っ取られる問題が顕在化。
これは入力値検証の延長ではなく、権限設計の問題です。

対策（必須）

  • ✅ Read / Dry-run / Write の分離
  • ✅ 重要操作はHuman Confirm
  • ✅ ツール権限は最小化（Least Privilege）
  • ✅ 実行入力は構造化（schema validation）
  • ✅ 監査ログ＋再現性（Replay）

Milestone 12：モデル更新が加速し「モデル更新耐性」が品質になる

  • モデル挙動が変わる前提で、評価・フォールバック・ロールバック設計が必要に
  • AIは “固定依存ライブラリ” ではなく “変化する外部API” になった

3. 2025年の総括：勝ち筋は“モデル知識”ではなく“設計と運用”

  • AIは本番システムの一部
  • 必要なのは 運用設計（Routing / Evals / SLO / Audit / Safety）
  • エージェント化で 権限設計（Permission Design）が最重要
  • UI中心ではなく、人間UI＋Agent APIの二層構造が安全で堅牢

4. 2026年の予測：備えるべき5つの未来

  1. Agent標準化で“接続は簡単”、でも“統制が差別化”
  2. 安全な実行環境（AIサンドボックス）が必須化
  3. 長期記憶が当たり前になり、データ設計が主戦場
  4. 推論コスト最適化が “性能チューニング” スキルになる
  5. 電力・冷却・GPU供給がインフラボトルネック化

5. 図解：推奨アーキテクチャ（Mermaid）

5-1. 全体像：Router + Tool Execution + Permission + Audit + Safety

5-2. Read / Dry-run / Write 分離（Prompt Injection対策の基本）

6. 実装テンプレ①：安全な「ツール実行」(TypeScript + Zod)

6-1. ポイント（最重要）

  • AIが返す文字列をそのまま実行しない
  • 実行入力は 必ず構造化し、Schemaで検証する
  • 危険アクションは Human Confirm を必須にする
  • 全アクションを 監査ログに残す

6-2. Code：Tool入力をZodで厳格検証 → 権限チェック → 実行 → 監査ログ

import { z } from "zod";

// 1) AIが呼び出すツールをスキーマ化する（入力の構造化）
const ToolInputSchema = z.object({
  action: z.enum(["create_user", "update_plan", "refund_payment"]),
  payload: z.record(z.any()),
  reason: z.string().min(1),
  requestId: z.string().uuid(),
});

type ToolInput = z.infer<typeof ToolInputSchema>;

// 2) 権限設計（最小権限）
type Actor = {
  id: string;
  roles: string[];
  scopes: string[]; // OAuth scope / permission scope
};

function requireScope(actor: Actor, required: string) {
  if (!actor.scopes.includes(required)) {
    throw new Error(`Permission denied: missing scope ${required}`);
  }
}

// 3) 重要操作はHuman Confirmを挟む（例）
function requireHumanConfirm(input: ToolInput) {
  const dangerous = ["refund_payment", "create_user"];
  if (dangerous.includes(input.action)) {
    // 実運用ではUI/Slack/Emailなどで承認フロー
    throw new Error("Human confirmation required");
  }
}

// 4) 監査ログ（replay可能な形式が望ましい）
async function auditLog(record: any) {
  // DBやログ基盤へ
  console.log("AUDIT_LOG", JSON.stringify(record));
}

// 5) 実行（ここでは例としてダミー）
async function executeAction(input: ToolInput) {
  switch (input.action) {
    case "update_plan":
      return { ok: true, updated: input.payload };
    case "create_user":
      return { ok: true, userId: "u_123" };
    case "refund_payment":
      return { ok: true, refundId: "r_456" };
  }
}

// 6) 統合：検証 → 権限 → 承認 → 実行 → 監査
export async function handleToolCall(rawInput: unknown, actor: Actor) {
  // (a) 入力検証（AI出力は信頼しない）
  const input = ToolInputSchema.parse(rawInput);

  // (b) 権限チェック
  const scopeMap: Record<ToolInput["action"], string> = {
    update_plan: "plan:write",
    create_user: "user:write",
    refund_payment: "payment:write",
  };
  requireScope(actor, scopeMap[input.action]);

  // (c) 重要操作の承認
  requireHumanConfirm(input);

  // (d) 実行
  const result = await executeAction(input);

  // (e) 監査ログ（入力も結果も必ず残す）
  await auditLog({
    at: new Date().toISOString(),
    actorId: actor.id,
    input,
    result,
  });

  return result;
}

✅ この形を守るだけで、Agent実装の事故率は大きく下がります。
「AIに権限を渡す」とは「権限を設計する」ことです。

7. 実装テンプレ②：AI Gateway / Router（簡易版）

モデル更新が頻繁になるほど「用途別に切り替える仕組み」が重要になります。
最初は単純なルールベースでも良いです。

type Task = "chat" | "summarize" | "code_review" | "critical_decision";

function routeModel(task: Task) {
  switch (task) {
    case "chat":
    case "summarize":
      return "fast";         // 速度優先
    case "code_review":
      return "thinking";     // 品質優先
    case "critical_decision":
      return "thinking";     // 重要判断は推論モデル＋Human Confirm
  }
}
  • 実運用では 実績（Evals） を見てルーティングを最適化する
  • 「ルーティング」＝推論コストとUXの主戦場

8. 実装テンプレ③：Python（FastAPI）で監査ログ＋Dry-run／Write分離

AIが操作する場合、Read / Dry-run / Write の分離が本当に効きます。

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from typing import Literal, Dict, Any
import uuid
import datetime

app = FastAPI()

class Action(BaseModel):
    action: Literal["update_plan", "create_user", "refund_payment"]
    payload: Dict[str, Any]
    reason: str
    request_id: str

def audit(record: dict):
    print("AUDIT", record)

@app.post("/dry-run")
def dry_run(act: Action):
    # side effectなしで差分を返す
    audit({
        "mode": "dry-run",
        "at": datetime.datetime.utcnow().isoformat(),
        "request_id": act.request_id,
        "input": act.dict(),
    })
    # 実際は差分計算する
    return {"ok": True, "diff": {"before": "...", "after": act.payload}}

@app.post("/execute")
def execute(act: Action):
    # 重要操作は事前に承認済みであることを要求（例）
    if act.action in ["refund_payment", "create_user"]:
        raise HTTPException(403, "Human confirmation required")

    result = {"ok": True, "id": str(uuid.uuid4())}

    audit({
        "mode": "execute",
        "at": datetime.datetime.utcnow().isoformat(),
        "request_id": act.request_id,
        "input": act.dict(),
        "result": result,
    })
    return result

9. Evalsテンプレ：GitHub Actionsで「モデル更新耐性」を作る

2025年後半の一番の落とし穴は「モデルが変わって挙動が変わる」ことです。
ここを防ぐには EvalsをCIに入れるのが最強です。

9-1. evals/testcases.json（期待値の定義）

[
  {
    "name": "refund_should_require_human_confirm",
    "input": { "action": "refund_payment", "payload": { "amount": 1000 }, "reason": "user request" },
    "expected": { "error_contains": "Human confirmation required" }
  },
  {
    "name": "update_plan_should_pass_schema",
    "input": { "action": "update_plan", "payload": { "plan": "pro" }, "reason": "upgrade" },
    "expected": { "ok": true }
  }
]

9-2. evals/run_evals.ts（例：ツール層のE2E検証）

import fs from "fs";
import { handleToolCall } from "../src/tools";

const cases = JSON.parse(fs.readFileSync("evals/testcases.json", "utf8"));

const actor = { id: "ai_agent", roles: ["agent"], scopes: ["plan:write", "user:write", "payment:write"] };

(async () => {
  let failed = 0;

  for (const c of cases) {
    try {
      const input = { ...c.input, requestId: crypto.randomUUID() };
      const res = await handleToolCall(input, actor);

      if (c.expected.ok && !res.ok) throw new Error("Expected ok");
      console.log("PASS", c.name);
    } catch (e: any) {
      const msg = String(e.message || e);

      if (c.expected.error_contains && msg.includes(c.expected.error_contains)) {
        console.log("PASS", c.name);
      } else {
        console.error("FAIL", c.name, msg);
        failed++;
      }
    }
  }

  if (failed > 0) process.exit(1);
})();

9-3. .github/workflows/evals.yml（CIで自動評価）

name: AI Evals

on:
  pull_request:
  push:
    branches: [ main ]

jobs:
  evals:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "20"
      - run: npm ci
      - run: npm run build
      - run: node evals/run_evals.ts

✅ これを入れるだけで、
モデル更新／プロンプト変更／ルーティング変更による事故を早期に検知できます。

10. まとめ：2025年は“Agent元年”、2026年は“標準化と統制の年”

2025年はAIが「答えるツール」から「実行する主体」へ進化し、
仕事は AIを安全に運用できるシステムにすることへシフトしました。

2026年はさらに

  • Agentの標準化
  • 長期記憶
  • 安全な実行（サンドボックス）
  • 推論コスト最適化
  • インフラ制約（電力・GPU・冷却）

が同時に進みます。

モデルの知識よりも、設計・運用・セキュリティ・SREが勝負になる年です。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?