0. 問いの設定

なぜ国産のDevOps SaaSはスマッシュヒットしないのか？

（GitHub / GCP / Zendesk のようなポジションが生まれない理由）

この問いを前提に、

• それは構造的制約なのか？
• それとも解ける問題なのか？

を整理しつつ、

👉 中期的にどのポジションを取りに行くべきか

👉 どんなプロダクト / 組織能力が必要か

を検討する

1. DevOps SaaSが当たらない構造

1.1 開発文化の差分

日本

• SI / 受託 / ウォーターフォールが主流
• 継続改善の主体が弱い

海外

• 内製・プロダクト志向
• DevOps前提

👉 DevOpsの前提である

「自分たちで改善し続ける主体」 が少ない

1.2 意思決定構造の違い

海外

• 開発者がツール選定（PLG成立）

日本

• 情シス / 上位承認

👉

• Bottom-up導入が起きにくい
• PLGが効きにくい

1.3 信頼・標準レイヤー

• GitHub / GCP → デファクト標準
• 品質・安定性・復旧力が高い

👉 エンジニア視点：

• 障害時に巻き込まれたくない
• 信頼できるものを使う

👉

「みんな使ってる + 壊れない」 = 最大の価値

1.4 結論（構造）

👉

DevOps SaaSは“文化・意思決定・信頼”の三層で阻害されている

2. それは制約か？チャンスか？

重要な転換点：

👉

PLGが効かない市場が残っている

• グローバル → PLGで侵食
• 日本 → PLGが通らない領域が残存

👉

「非PLG前提のDevOpsポジション」が空いている

3. 成功パターンの本質

GitHub / GCP / Zendeskの共通点：

3.1 実務への常用性

• 毎日使う
• ないと業務が止まる

3.2 ワークフロー中核

• チーム横断で使われる
• 置き換えコストが高い

3.3 データ蓄積

• 使うほど価値が増す

👉

「不可欠な日常」を取っている

4. ポジションの方向性（従来）

4.1 DevOps未満を取る

• Excel / Slack / Backlog的運用
• 属人管理

👉

“擬似DevOpsレイヤー”

4.2 組織制約吸収型

• 承認 / 監査 / セキュリティ

👉

“Enterprise DevOps”

4.3 運用領域

• サポート / 障害対応

👉

“運用DevOps”

5. AIによる環境変化

5.1 何が起きているか

• 誰でも開発可能（Supabase等）
• AIが自律的に処理を生成
• フローがブラックボックス化

👉

開発の民主化ではなく

“運用の崩壊”が起きている

5.2 新しい問題

• 何が動いているか分からない
• どのAIが何をしたか不明
• 失敗に気づけない
• 修復できない

👉

“制御不能な自動化”

6. DevOpsの再定義

従来：

• CI/CD
• デプロイ

これから：

👉

「何が動いているかを把握し続ける能力」

7. 新しいポジション仮説

7.1 AI運用OS

👉

「AI時代の運用OS」

機能

• AIの挙動の可視化
• 出力の評価
• 実行の制御
• 事故後の修復

7.2 コックピットモデル

本質

• 観測
• 判断
• 介入
• 修復

👉

“責任を持って操作できる場所”

7.3 Difyの示唆

「人に聞く」機構：

• 人間の承認ポイントを挿入

👉

責任のアンカーを作る

8. 日本市場との適合性

8.1 日本の特性

• ネガティブチェック文化
• 説明責任
• 承認プロセス

👉

制御できないAIは導入されない

8.2 必須要件

1. 気づける
2. 止められる
3. リカバリーできる

👉

海外：①でOK

日本：③まで必要

9. コア価値：リカバリー

9.1 なぜ重要か

現在：

• AI失敗 → 導入NG

未来：

• AI失敗 → 修復可能 → 導入OK

👉

“失敗コストを下げる” = 制約破壊

9.2 具体例

• 誤送信メールの回収 / 修正
• DBの巻き戻し
• 修正メッセージの自動送信

👉

「AIの失敗をなかったことに近づける」

10. プロダクト構造

10.1 イベントストリーム

• 全AIアクション記録

10.2 チェックポイント

• 人間承認挿入

10.3 リカバリー機構（コア）

• 巻き戻し
• 修正
• 再実行

10.4 コックピットUI

• 時系列可視化
• 状態把握
• 操作可能

👉

「Git + Zapier + Zendesk」的統合

11. 思想（最重要）

👉

AIを信用させるのではなく

人間が責任を持てる状態を作る

12. 制約破壊の定義

従来：

• AI = 不安
• 管理不能

After：

👉

「AIを安全に常用できる」

13. 初期プロダクト戦略

Phase1

• 状態可視化
• アラート
• 手動停止

Phase2

• リカバリー機構

Phase3

• 自動制御 / ポリシー

14. GTM（Go-to-Market）

初期ターゲット

• CS（カスタマーサポート）
• セールスオペ
• バックオフィス

👉

顧客影響のあるAIを使う部署

特徴

• PLG単体は難しい
• 組織横断プロダクト

15. 最終的なポジション定義

👉

「AIの自由を許す代わりに

人間が後から責任を取れる世界を作る」

16. 重要論点（未確定）

16.1 エントリーポイント

• メール / CS
• 社内業務
• 開発

16.2 初期能力の焦点

• 観測
• 評価
• 制御
• 修復

👉

どこから入るかでプロダクト形状が決まる

17. 一言まとめ

👉

「AIが増えすぎた世界のガバナンスレイヤーを取る」