「全問い合わせの1%」への対応が組織の限界を決める：AIで挑む「プロセスのデバッグ」
こんにちは、えっぐです。ココナラのサーバーサイドエンジニアとして、施策開発や技術施策から障害対応、システム運用まで幅広く取り組んでいます。
この記事は 株式会社ココナラ Advent Calendar 2025 10日目の記事です。
「全問い合わせの1%」への対応が組織の限界を決める：AIで挑む「プロセスのデバッグ」
はじめに：開発の手を止める「1%の問い合わせ」とどう向き合うか
エンジニアの皆さん、日々の「割り込み」に脳のメモリを食いつぶされていませんか？
私たちエンジニアの元に届く問い合わせは、件数だけで見れば全体の1%程度かもしれません。
しかし、この「1%」こそが厄介なのです。
CS（カスタマーサポート）や一次対応をすり抜けてエンジニアまで辿り着いた問い合わせは、「エッジケース」「データ不整合」「環境依存」といった、一筋縄ではいかない問題ばかり。件数は少ないが、内容は重い——それが「1%」の正体です。
この「1%」への対応コストは、単なる時間の浪費ではありません。それは、開発チームが抱える 「認知負荷の負債」 であり、私たちのシステムと開発プロセスにある「未解決の欠陥」を浮き彫りにします。
私たちのようなスキルマーケット（毎日多くのトランザクションが処理される環境）では、こうした問題がより顕在化しやすいからです。
私は、この課題に対して、 Claude Code を活用し、調査プロセスそのものをデバッグする仕組みを作ってみました。
本記事では、個人の調査を組織全体の学習へ変えるための実践記録を共有します。
TL;DR
- 課題：障害調査は「入口の着手点難」と「出口のナレッジ揮発」という悪循環に陥っている
- 解決策：Claude Codeを活用して、AIに「思考の型」を実装。調査プロセスそのものをデバッグする
- 実装：約1ヶ月の検証を経て、現在も改善を続けている段階
- 効果：個人の知見を組織で活用できる環境を実現。ナレッジの再利用で同じ調査の繰り返しを防止
- ポイント：AIは確信を持って論点を示すことで、新しい視点をもたらす。正確性とは別に、思考の方向を変える価値がある
課題：調査の入口と出口に潜む悪循環
システムが複雑化するにつれ、障害調査のコストは肥大化しています。私が現場で感じていたのは、調査プロセスの入口と出口が連結し、組織の疲弊を生む 「負のフィードバックループ」 を形成していることでした。
-
入口の罠（着手点の模索）
ログ、DB、コード、複数のリポジトリ……散らばった情報から「何から見ればいいんだっけ？」とあたりをつけるまでの初動コストが高い。ここで多くのワーキングメモリが消費され、調査の着手が遅れます。 -
出口の罠（ナレッジの揮発）
苦労して原因を突き止めても、チャットで報告して終わり。「なぜそのバグが生まれたか」「どこを見れば早かったか」という教訓が蓄積されず、知見が揮発します。
この2つが組み合わさることで、 「毎回ゼロから高い認知負荷を払って調査し、得られた知見を捨てて、またゼロから調査する」 という徒労のサイクルが回っているように思われました。
私が欲しかったのは、単に答えを教えてくれるチャットボットではなく、 入口のハードルを下げ、出口を確実に資産に変えるためのワークフロー でした。
実践：AIに「熟練者の思考」を実装する
解決策として、Claude Code を活用したAIエージェントを構築し、現在検証を進めています。
実装構成
- モデル：Claude Sonnet 4.5
- 実行環境：ローカル環境（Claude Code）
- 検証期間：約1ヶ月（検証→調整）
-
外部データアクセス：ログ、データ、コード検索をAIが安全に利用可能に
※ ログはマスキング処理済み。DBの個人情報データには、AIも社員もアクセスできない構成です。また、AIの学習対象からオプトアウトされています。
重要なのは、ツールを繋ぐことではありません。AIに 「エンジニアが頭の中で行っている調査手順」を明文化し、ルールとして守らせること です。
新人エンジニアにメンタリングするように、AIに対しても「思考のガードレール」を設置しています。
1. プロンプトによる「思考のコード化」（例1: エラー調査）
具体的に、私は以下のような構成でシステムプロンプトを記述して、思考のプロセス自体を定義しています。
# ログ調査エージェントの役割定義
## ⚖️ 調査原則（Constitutions）
あなたは熟練したSREエンジニアです。以下の原則に従い調査を遂行してください。
1. **事実優先**: 「たぶんこうだろう」という推測を厳格に禁止します。ログやDBに証拠がない限り、断定してはいけません。
2. **証拠主義**: 全ての結論には、必ずログIDやタイムスタンプなどの「一次情報の証拠」を併記してください。
3. **段階的実行**: 以下のPhase順序を遵守し、Phase 4（データ検証）を経ずに結論を出すことを禁止します。
## 📋 調査プロセス（Investigation Phases）
### Phase 1: 基本情報収集
- エラー発生時刻の特定（JST/UTC変換を必ず行うこと）
- 影響範囲の特定（特定のユーザーIDか、全体か？）
### Phase 2: 仮説設定と検証
- 複数の仮説を立て、可能性の高い順にログを検索する
...
このように「推測を禁止」し「データとの整合性チェック」を強制することで、AIはハルシネーション（もっともらしい嘘）を極力自制し、より信頼性のある調査結果を導きます。
2. パフォーマンス分析での判断基準（例2: スロークエリ調査）
エラー調査だけでなく、スロークエリ調査などのパフォーマンス分析においても、エンジニアの暗黙知を注入できます。
単に「遅いクエリ」をリストアップさせるのではなく、 「変化」に着目させる よう指示を与えています。
# スロークエリ分析の判断基準
## 1. 🚨 新規検出 (New Issues)
- **定義**: 先月（ベースライン期間）には存在せず、直近24時間で初めて発生したクエリ
- **アクション**: 最優先で報告。直近のリリースや環境変化の影響である可能性が高い。
## 2. ⚠️ 顕著な変化 (Significant Changes)
- **定義**: 以前から存在したが、実行回数が「先週比 200%以上」または実行時間が「先週比 150%以上」に悪化したもの
これにより、AIは「いつも遅いクエリ（定常ノイズ）」を無視し、「昨日から急に遅くなったクエリ（異常）」だけをアラートとして上げてくれるようになります。つまり、ノイズが減り、本当に着手すべき問題だけが浮かび認知負荷を下げることができました。
考察：AIの「バイアス」と人間による「補完」
実際の障害調査で活用してみたところ、AI活用のリアルな縮図と言える体験でした。私がAIを用いて導き出した仮説の方向性は正解でした。しかし、エンジニアからの指摘により、AIがエラーメッセージの実装箇所をリポジトリA側だと推測し、実際のリポジトリB の処理を見落としていたことが判明しました。
ここから得られた教訓は、AIは万能ではなく、文脈によっては特定の領域に調査が偏る「バイアス」を持つということです。だからといってAIが役に立たないわけではありません。AIが提示した「8割の正解」に対し、人間が専門知識を持って検証を行い、残りの「2割」を埋める。このプロセスを経ることで、ゼロから調査するよりも遥かに速く真因にたどり着くことができました。
AIに「完全な答え」を求めるのではなく、思考の初速を上げるための「入口」として活用し、人間がそれを補正・検証する。この「相互補完」の関係性こそが、組織としての問題解決能力を最大化する鍵になることを示唆しているのかもしれません。
出口のハック：調査結果を組織の資産にする
さらに、この取り組みを個人の効率化で終わらせないために、 「出口」の設計 も行いました。
調査結果を知見として蓄積するには自分が調査報告書を一から書く必要があります。この作業をAIに構造化レポートを生成させることで、レビューするだけで報告が完成できます。これにより認知負荷が大幅に低減され、同時にナレッジが半自動的に蓄積されます。
- Before: 調査に1時間、報告書作成に30分。知見の言語化コストが高い。新人のオンボーディングに時間がかかり、知見の伝承機会が少ない。
- After: AIがレポート生成。エンジニアはレビュー・修正するだけ。報告と同時にナレッジが記録される。新人がAIレポートをレビューする過程で「良い調査とは何か」を学べる環境が実現。
構造化レポートの例
AIは以下のような構造化レポートを生成します。
⚠️ 下記は説明用の架空例です。実際の調査で生成されるレポートはこのような構造を持ちます。
【概要】
特定のユーザーで検索機能の実行が遅延し、タイムアウトエラーが発生する事象について調査
【5W1H整理】
- When: 2025年11月20日に報告
- Where: 検索API（/api/v1/search）
- Who: プレミアムプランのユーザー
- What: 検索リクエストがタイムアウト（30秒以上応答がない）
- Why: キャッシュレイヤーが特定条件で機能していない
- How: 新しいフィルター条件の組み合わせが キャッシュキーに反映されず、毎回フルスキャンが発生
【根本原因】
- キャッシュキー生成時に「ユーザー権限レベル」が含まれていない仕様
- プレミアムユーザーの専有データセットがキャッシュされず、毎回フルスキャン実行
- フルスキャン時の集計処理が非効率化（O(n²)の計算量）
【詳細ログ】
- 実行クエリのログ、実行時間の推移、キャッシュヒット率の分析
このレポートにより、「原因は〇〇」という結論だけでなく、「どのプロセスで何を確認したか」という調査の思考過程が記録されます。この記録は、将来の同様の問題に遭遇した時の参考資料となり、プロンプトの改善にも活用できます。
重要な副次効果として、このレポートレビュープロセス自体が新人エンジニアにとって「良い調査とは何か」を学ぶ最高の教材になります。 従来なら、新人が調査スキルを身につけるには先輩からの直接指導が必要でした。しかし、AIが生成した報告書を先輩エンジニアと一緒にレビューすることで、新人は：
- 実践的な調査ステップの論理を目の当たりにできる
- 「なぜこの順序で確認するのか」という思考の根拠を学べる
- 間違いやすいポイント（ハルシネーション）が修正される過程を見ることで、数学の証明問題をレビューするように「正しい推論」を身体化できる
つまり、AIがメンターの代わりになり、「個人の調査が組織全体の教育リソースに変わる」 という新しいナレッジマネジメントの形が実現するのです。
さらに、将来的には Notion と AI を連携（MCP）させることで、過去の調査事例を AI に参照させ、より精度の高い調査を実行できる環境を目指しています。つまり、個々の調査結果が組織全体の「調査能力」を高めるフィードバックループを形成するわけです。
変化：負のループから正のループへ
実際に実装すると、この悪循環はどう変わるのか。以下は「思考の型」を組み込んだ後の調査フローです。
まとめ：Operation as Code
この取り組みの終着点は、単なる調査ツールの導入ではありません。
個人の頭の中にしかなかったプロセスを「コード（テキスト）」として書き出し、再現可能にすることです。
現在、私の手元には investigation_prompt.md という一つのテキストファイルがあります。
これは単なるメモ書きに見えるかもしれません。しかし、ここには私が数々の障害対応で培ってきた「思考の型」が記述されています。
これをAIに入力することで、毎回同じ手順・観点で調査を開始できます。
チーム内で共有することで、誰が担当しても同じアプローチで調査するためのガイドラインとして機能するのではないかと考えています。
- 暗黙知の言語化: 自分のための「カンペ」として、調査手順をプロンプトに書き出す。
- 知見のポータビリティ: それがテキストファイルになっているからこそ、AIに渡したり、同僚に渡したりできる。
ドキュメントはすぐに陳腐化しますが、 「自分が楽をするためのプロンプト」 なら、日々使いながら磨き上げられます。
Gitで管理し、手順書を実行可能なコードとして扱う。
これはまさに「Operation as Code」のアプローチです。
とはいえ、最初から体系化できていたわけではありません。始まりは、単に「手元のメモを形にする」という小さな試みでした。
まずは手元のメモ帳から。
AIに雑務を任せるのではなく、AIに「思考の型」を教え込み、一緒にデバッグする。
そんな小さな実験を、始めてみてはいかがでしょうか。
明日は入社同期のいっちーさんによる記事です。
ココナラでは積極的にエンジニアを採用しています。
採用情報はこちら。
カジュアル面談希望の方はこちら。
Discussion