はじめに
最近Devinを機能実装だけでなく、問い合わせ調査にも活用しています。
コードベースを参照させると仕様調査はかなり速くなりましたが、一方でコードだけでは解決できない問い合わせは依然として時間がかかっていました。
- ユーザー環境に依存する挙動
- 特定のバージョンに起因する差分挙動
- 過去事例の文脈を知っていないと判断できない事象
こうした「コードを読むだけでは分からないノウハウ」をDevinが使える形で蓄積し、問い合わせ対応を改善する取り組みを始めました。本記事では、その設計・運用・所感をまとめます。
※ 記事中の機能名・リポジトリ名はすべて架空です。
やったこと
取り組み全体の構成は以下の通りです。
1. ナレッジ専用リポジトリを作成
アプリ本体（例: app-core）とは別に、ナレッジ専用リポジトリ（例: app-support-knowledge）を作成しました。
app-support-knowledge/
├── knowledge/
│ ├── TEMPLATE.md
│ ├── feature-a/
│ │ └── 20260101_some_issue.md
│ └── feature-b/
│ └── 20260210_another_issue.md
├── WORKFLOW.md # Devinへの依頼手順・参照リポジトリの指定方法
└── README.md
knowledge以下のMarkdownには、原因・再現条件・一次対応・恒久対応・注意点を共通テンプレートで記録し、担当者が問い合わせ対応のたびに必要に応じて追記します。WORKFLOW.md には、類似事例の検索、コード調査、一次回答作成、ナレッジ追加PR作成までの実行手順と、保存先・命名規則・フォーマットなどのルールを記載しています。
まずは小さく始めたかったため、コードリポジトリとは別に立てています。アプリ本体には既存のCIがあり、ナレッジ追加のPRをテンポよくマージしにくいという事情もあります。
2. 問い合わせ対応時にコードとナレッジを同時参照
Devinへの依頼時に、コードベースに加えてナレッジリポジトリも参照対象に含めます。
これにより、単なるコード読解ではなく、過去事例を踏まえた回答が出るようになりました。
※ 当然、Devinに渡す情報はマスキングしています。
3. Devinが知らない知識はPRで追加
Devinが未知の事象に当たったとき、対応後にナレッジ追加PRを作成します。
PRは基本的にDevinが作成し、人は内容レビューとマージ判断に集中する運用にしています。
この流れを迷わず回せるよう、PR作成指示まで含んだ定型プロンプトをリポジトリ内に用意しています。
- DevinがPRを作成
- 人がレビューしてマージ
- 次回からはその知見を前提として回答
この分業と定型プロンプトのおかげで、対応のたびにナレッジが積み上がり、同種の問い合わせでは初動が速くなってきました。
4. Scheduleでナレッジを自動メンテナンス
コードが変わったのにナレッジが古いまま、という状況を防ぐため、2種類のScheduled Sessionを運用しています。
具体的な実行手順はPlaybookとして登録し、ScheduleにアタッチすることでDevinが定期的に自動実行します。
Schedule A: コード変更との整合チェック
アプリ側の最新差分とナレッジを照合し、内容が古くなっていれば更新Draft PRを自動作成します。
Schedule B: 問い合わせ削減のための分析
蓄積したナレッジをもとに「そもそも問い合わせを発生させないためには何が必要か」を提案させます。
- マニュアルを改善することで防げるか
- 仕様変更や機能改修が必要か
ナレッジを「対応履歴」で終わらせず、問い合わせを未然に防ぐための検討材料としても活用する狙いです。
回答例
以下は、実際に「担当者がDevinへ依頼したとき」のやり取りを簡略化した、架空の問い合わせ対応例です。
1. 担当者がDevinに渡した依頼文
以下の問い合わせが来ました。WORKFLOW.md を確認し回答してください。
【問い合わせ内容】
- 管理者がユーザーに新しい権限を付与したが「画面に反映されない」と言われた
- 対象ユーザーは普段、複数ブラウザを使い分けている
Devinの回答
過去のナレッジに類似する事例が見つかりました。
該当ナレッジ: knowledge/access-control/20260520_permission_not_reflected_with_multi_browser_sessions.md
## 原因
権限自体は正しく更新されていますが、ブラウザごとに保持している
セッション情報・ローカル状態が異なるため、片方のブラウザだけ
古い権限状態のまま表示されている可能性があります。
コード上の権限判定ロジックが正しくても、利用ブラウザの状態差分で
「反映されていないように見える」事象が発生します。
## 確認手順
1. 問題が出るブラウザと正常なブラウザで、ログイン時刻と操作手順を比較
2. 問題ブラウザでログアウト・再ログインし、権限表示が更新されるか確認
3. 必要に応じて、当該ブラウザのサイトデータ（Cookie / LocalStorage）を削除して再検証
## 対応方法
問題が発生しているブラウザのセッションを再作成（再ログイン）し、
古い状態を保持している場合はサイトデータをクリアしてください。
## 再発防止
権限変更時は「複数ブラウザを利用している場合、利用中の全ブラウザで再ログインが必要」
という注意事項を、管理者向けマニュアルとユーザー向けヘルプに明記してください。
このように、担当者は問い合わせ内容をDevinに入力し、Devinはコードとナレッジを参照したうえで、原因・確認手順・対応方法・再発防止までをまとめて返します。
ナレッジがなければ、権限判定ロジックやAPIの不具合を疑ってコードを追いかけることになっていたと思います。過去事例があったことで、複数ブラウザ利用時のセッション差分という切り口にすぐ絞り込めました。
運用してみた所感
良かった点
- 既知ナレッジに該当する問い合わせは、初動が明確に速くなった
- 担当者依存だった調査観点が、チームの共通資産になってきた
- 「前に誰がどう解いたか」を探す時間が減ってきた
課題
- 立ち上げ初期はナレッジ量が少なく、即効性は限定的
- ナレッジ追加を習慣づけることが最大のハードル
これまで各担当者は、自分が過去に対応した機能について独自にメモや資料を持っていました。そのため、自分の担当機能の問い合わせであれば、これまでのやり方と工数はさほど変わりません。
本当に効果が出るのは、担当外の機能の問い合わせを対応するケースです。 チーム全員がナレッジを蓄積してはじめて、「自分が知らない領域でも、過去事例をもとに調査できる」という状態が生まれます。個人が持っていた調査観点をチーム共有の資産にしていく、という意識が運用継続のカギだと思っています。
まとめ
この取り組みのポイントは、AIの導入そのものより、AIが参照できる形で知見を蓄積し続ける仕組みを作ることでした。
- ナレッジが増えるほど、問い合わせ対応の工数削減効果は大きくなる
- 蓄積したナレッジを分析することで、問い合わせの未然防止にもつながる
運用開始から約2か月で、「コード + ナレッジ」を前提にした回答作成が徐々に定着してきました。
より効果的な運用フローを模索しながら、続けていく予定です。