導入：いまの時代の“ズレ”を最初に言い切る

世の中は「誰でもAIエージェントを作れる」と言う。
これは 技術的可能性（Capability） としては事実です。

でも、現場で成果が出るかは別問題。必要なのは 実現性（Viability：運用・設計・ガバナンス込み）。

「作れる」＝すごい
「成果が出て回り続ける」＝価値

この差が、導入が失敗する最大要因です。
AIは“起動”より“定着”が難しい。ここを最初にズバッと言い切っておくと、以降の議論がブレません。

結論：段階モデルは「一本道」ではなく“ゲート（通過条件）”として使え

従来の成熟度モデルは、ありがちです。

見える化 → 自動化 → アプリ → AI

でも2026年の現場では、これがズレます。
なぜなら **「いきなりAIいける時代」**になったから。

そこで段階モデルの位置づけを変えます。

どこから始めてもいい（AIからでもOK）
ただし各レベルには “通過条件（ゲート）” がある
ゲートを満たさず飛ぶと、だいたい事故る

つまり段階分けは 順番の強制ではなく、飛び級したい人の安全装置／弱点診断として使うのが正しい。

解決策：4つのゲートで「業務改善→市民開発→AIエージェント化」を安全に進める

ここからが実装の話です。
“ゲート式”にすると、現場でそのままチェック表として運用できます。

全体像（どこからでも入れる版）

Gate 1：課題の特定（Problem Fit）

通過条件

その改善で「何の成果」を出すのかが言語化されている
KPIが測れる（例：時間削減／ミス削減／リードタイム短縮）

満たさないと起こること

AI導入したけど使われない
効果が説明できない（評価・継続ができない）

実務的Tips

KPIが決まらない時は「最初は Time でいい」
→ 1件あたり処理時間 / 週の処理件数 なら測りやすい
“気持ちいい”ではなく“減った”を取る（例：残業、手戻り、問い合わせ）

Gate 2：業務の構造化（Process Fit）

通過条件

入力・判断・出力が整理されている
例外パターンが把握されている
「誰がいつ何をするか」が決まっている

満たさないと起こること

AIが毎回違う
結局人が手で直す
運用が破綻する

実装手順（最小でOK）

入力（Input）を列挙する
判断（Decision）を「ルール」「裁量」に分ける
出力（Output）を“フォーマット固定”で定義する
例外（Exception）を3パターンだけ先に書く（全部は不要）

コード例：業務の構造化テンプレ（YAML）

process:
  name: "稟議一次チェック"
  input:
    - name: "申請書"
      source: "SharePoint"
      required: true
    - name: "添付（見積）"
      source: "SharePoint"
      required: false
  decision:
    rules:
      - if: "金額 <= 100000"
        then: "自動承認候補"
      - if: "添付なし AND 金額 > 100000"
        then: "差戻し"
    discretionary:
      - "例外承認の判断（理由の妥当性）"
  output:
    format: "チェック結果JSON"
    fields:
      - "status"      # approve/reject/need_more_info
      - "reason"      # 判定理由（監査ログ）
      - "next_action" # 次の担当とタスク
  exceptions:
    - "添付の形式が規定外"
    - "申請者の権限不足"
    - "取引先がマスタ未登録"

Gate 3：データと権限（Data & Security Fit）

通過条件

参照データの所在・鮮度が明確
権限・監査・情報区分が守れる
“このAIに責任を持つ人”が決まっている

満たさないと起こること

便利だけど危なくて止まる
ガバナンスで詰む（後から差し戻される）

実務的Tips

最初に決めるべきは「責任者」
→ データの持ち主 と 運用の持ち主 がズレると必ず揉める
“参照できる”と“回答に使っていい”は別
→ 情報区分（社外秘/部門限定など）を明文化しておく

コード例：アクセス前提の宣言（疑似ポリシー）

data_policy:
  knowledge_sources:
    - name: "SharePoint_業務手順"
      freshness: "weekly"
      permission: "部門メンバー以上"
    - name: "Dataverse_取引先マスタ"
      freshness: "real-time"
      permission: "経理ロールのみ"
  logging:
    audit_log: true
    store_prompt: false
  owner:
    business_owner: "業務責任者（役割名）"
    system_owner: "運用管理者（役割名）"

Gate 4：運用と改善（Ops Fit）

通過条件

更新担当・問い合わせ対応・改善サイクルがある
影響範囲（止まると困る業務）が把握されている
モニタリングがある（利用・成果・品質）

満たさないと起こること

最初だけ盛り上がって放置
属人化して終わる

実務的Tips

“問い合わせ窓口がないAI”は、運用上は存在しないのと同じ
改善サイクルは週次で良い。月次は遅い（熱が冷める）

コード例：運用の最小セット（チェックリストJSON）

{
  "ops": {
    "owner": "運用責任者（役割名）",
    "support": {
      "contact": "Teamsチャネル or フォーム",
      "sla": "2営業日以内に一次回答"
    },
    "improvement_cycle": "weekly",
    "monitoring": {
      "usage": ["DAU", "利用者数", "再利用率"],
      "impact": ["削減時間(推定)", "手戻り件数"],
      "quality": ["回答の修正率", "差戻し率"]
    },
    "blast_radius": "停止したら困る業務か（Yes/No）"
  }
}

結果/効果：ゲート式にすると「いきなりAI」を肯定しつつ事故だけ潰せる

このフレームの強みは、現実の会話に刺さることです。

「AIから始めたい」→ OK。じゃあGate2〜4どこが弱い？
「PoCは動いた」→ Ops Fitを満たしてる？（運用できる？）
「便利だけど止められた」→ Data & Security Fitが未通過

つまり、

いきなりAIを否定しない
でも「動くけど使われない」「便利だけど危ない」を構造的に説明できる
さらに、次に何を整えればいいかが具体的になる

段階モデルが“思想”から“現場の診断表”に変わります。

ハマりやすいポイントと回避方法

1) 「Gate1が曖昧」問題（成果が語れない）

症状：デモは盛り上がるが、次の予算が出ない
回避：KPIを1つに絞る（まずは時間）

2) 「Gate2を飛ばしてプロンプトで殴る」問題（毎回ブレる）

症状：回答が安定しない → 結局人が修正
回避：出力フォーマット固定（JSON/表/テンプレ）＋例外3つ先出し

3) 「Gate3が後回し」問題（止められる）

症状：便利なのに“監査/権限”で中止
回避：責任者・情報区分・監査ログ方針を先に宣言

4) 「Gate4がない」問題（放置）

症状：最初だけ盛り上がり、半年後に誰も触ってない
回避：問い合わせ窓口＋週次改善＋最低限のモニタリング

学び・まとめ：成熟度は“順番”じゃない。飛び級の安全装置だ

いきなりAIエージェントから始めてもいい。
ただし、**Gate2〜4（構造化／データ・権限／運用）**が欠けると

「動くけど使われない」
「便利だけど危ない」

になりやすい。

だから段階分けは「順番の強制」ではなく、
飛び級したい人の安全装置／弱点診断フレームとして使うのが正しい。

次のステップ：読んだ直後にやること（15分でOK）

まず対象業務を1つ選ぶ（“止まっても致命傷じゃない”業務が良い）
Gate1〜4を Yes/No で埋める（迷ったらNo）
Noが付いたゲートだけ、上のテンプレ（YAML/JSON）で最小定義する
定義が揃ったら、初めて「自動化」「アプリ」「AIエージェント」を選ぶ
- 迷ったら：Ops Fit（Gate4）が作れる手段を優先する

“作る”は一瞬。
“回す”を設計できたチームだけが、AIで勝ちます。