導入：いまの時代の“ズレ”を最初に言い切る
世の中は「誰でも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で勝ちます。