[LangGenius 社内事例] IDE からプロダクションを直接見に行く：LangGenius 社内で作った Ops Smart Assistant
はじめに
まず用語について。プロダクト名 Ops Smart Assistant の “Ops” は Operations の略で、日本語で言えば 運用――本番環境・サーバー・監視・ログといったインフラを担当する役割を指す。以下、本文ではこの役割を「運用（Ops）」と表記し、プロダクト名そのものは英語のままで扱う。
本番で何かが起きると、1 分ごとに損失が積み上がる。一方で、実際にコードを書いているエンジニアは Grafana / Sentry / Kubernetes の閲覧権限も PromQL の知識も持っていないことが多い。結果として毎回同じ脚本が再生される：チケットを切る → 運用チャンネルで誰かをメンションする → 待つ。同時に、運用側は 1 日の大半を同じ類いの質問に答えることに費やし、本来やるべきインフラ仕事が押し出されていく。
LangGenius 社内でも同じ穴にハマった。そこで Dify を使って、社内エンジニア向けの「Ops Smart Assistant」を組んだ。ユーザーは自然言語で 1 行問うだけ。アシスタントが問いを正しいバックエンドツールへ自動ルーティングし、ダッシュボードのスクリーンショットと AI による解釈をまとめて、ユーザーが普段使っている入口（Cursor / VS Code / Web）に返す。
本稿は LangGenius 自身が走らせ、今も使い続けている use case として、使い方と設計上のトレードオフをそのまま書き起こしたものである。
背景と課題
「待ち時間税」は実在する
| 役割 | 具体的な痛み |
|---|---|
| 開発者 | ちょっとしたサービス指標を確認するだけで、チケット起票、複数ダッシュボードの切替が発生し、半日潰れる |
| 運用（Ops）エンジニア | 毎日数十件の同じ質問に帯域を食われ、インフラ改善の進捗が希釈され続ける |
| チーム全体 | 障害 1 分目の反応速度が「権限 + 熟練度」の二重壁で縛られている |
従来の ChatOps では足りない理由
従来の ChatOps ボットは典型的に「命令型」だ：/metrics billing cpu 24h のような固定構文。本番をたまにしか触らない開発者にとっては、コマンドを覚えること自体がハードルになる。より本質的には、返ってくるのは大抵グラフか JSON の塊で、解釈が付いてこない。結局開発者はまた誰かに聞きに行く。
私たちが欲しかったのは「人間の言葉が通じる／正しい場所へルーティングできる／結果を説明できる」フロントエンドだった。開発者が Slack で口にするのと同じ粒度で、そのまま問えるもの。
なぜ Dify がこの用途に合うのか
この場面で Dify と噛み合うポイントは明確にある：
- 自然言語フロントエンド + ツール・オーケストレーション・バックエンド：開発者は単一の自然言語入口に向き合うだけ。ルーティング、データ取得、合成はバックエンドが引き受ける。
- 権限境界を一本化できる：ツール呼び出しが Dify 側に集まり、バックエンドの認証情報がクライアントに漏れない。監査しやすく、爆発半径を絞りやすい。
- 入口を使い回せる：同じ Dify アプリで Cursor プラグイン、VS Code 拡張、Web ページを同時に支えられる。入口ごとにロジックを書き直す必要がない。
- 結果を組み合わせられる：「ダッシュボードのスクリーンショット + AI による解釈」のような複合的な回答を、ユーザー側で二次加工させずに一発で返せる。
使い手から見た動き方
- 自然言語で聞く。 IDE 内で 「ここ 24 時間の billing サービスの CPU 使用率どう？」 と書くだけ。コマンドも覚えなくていいし、ウィンドウも切り替えない。
- システムが自動でルーティングする。 アシスタントは「これは指標系の問い」と判断し、ログではなくメトリクス系ツールを呼ぶ。
- 図と文が一緒に返ってくる。 Grafana ダッシュボードのスクリーンショットと、AI が生成した解釈が数秒で戻る。
- 普段の場所で答えを受け取る。 開発者にツールを切り替えさせない。Cursor / VS Code / Web の 3 面で同じバックエンドを共有する。
開発者側の体感の変化は 「本番を見に行く」ことが、スケジュールを要する作業から、息をするようにできる作業に変わった、に尽きる。
運用した結果
| 観点 | Before | After |
|---|---|---|
| クエリ所要時間 | 数時間オーダー（返信待ち + ダッシュボード切替） | 30 秒オーダー |
| 運用側の反復質問対応 | 毎日数十件 | 明確に減少、帯域がより価値の高い仕事に戻る |
| 開発者体験 | IDE を離れ、ツールを渡り歩き、人を待つ | IDE を離れず、自分で完結 |
効果そのものは派手でもないし、Dify だけが実現できるものでもない。本当に削れているのは、「日常の小さな問い合わせ」にかかる組織全体の協調コストだ。普段は見えないコストだが、一度消えるとそこに戻りたくなくなる。
自分たちが溜めてきた教訓
今日まで走らせてみて、書き残す価値があると思っている教訓がいくつかある：
- まずリードオンリーから始める。 クエリを磨き切ってから、書き込み系操作（Pod の再起動、設定変更）を考える。権限境界は一度緩めると戻しにくい。
- 権限はオーケストレーション層で効かせる。Prompt 層ではなく。 モデルが「危ないツールを呼ばない」と信じるのではなく、そもそも危ないツールをユーザー入口から見えない形で外しておく。
- 「わからない」にも明確な逃げ道を。 幻覚でもっともらしい答えを作るよりは、「この問いは自信がない、oncall に相談してほしい」と言えるほうがずっといい。
- 最初からダッシュボード網羅を狙わない。 頻度上位 3〜5 種の問いをまず撃ち抜き、安定させる。ロングテールは後から足す。
- 入口を、開発者が既にいる場所に貼る。 Cursor プラグイン / VS Code 拡張 / Web――開発者のデフォルト環境に入口を置く。新しいツールを 1 つ覚えさせた時点で、たぶん使われなくなる。
まとめ
Ops Smart Assistant の本質は「新しいツール」ではない。自然言語入口・ツールオーケストレーション・結果合成という 3 つを Dify で束ね、「本番を見に行く」という小さな行為が社内で人をまたがずに済むようにしただけだ。それが削っているのは、開発者と運用のあいだに普段は見えずに溜まっている暗黙のコストである。まずクエリを磨く。閉ループは後回し。まず開発者に効かせる。組織レベルの話はその後――これが、私たちが走らせてきた中で一番残しておきたい 1 行だ。