はじめに
こんにちは、MSPセクションの小野瀬です。
前回【前編】AI×問題管理：「次は気をつけます」という精神論に頼らない運用のあり方では、現場の「モグラ叩き」を終わらせるためには、解熱剤（対症療法）ではなく、組織の「体質改善（根本治療）」が必要だというお話をしました。
そのために必要なのが、痛みを伴う「流出原因（プロセスの弱点）」への深掘りです。
しかし、深い分析は難しい。
「なぜ？」を繰り返して根本にたどり着くには、高度なスキルと根気、そして何より「いつもの業務の当たり前を疑う」という多角的な視点が必要です。
日々の業務に追われる中で、ゼロベースでプロセスを見直すことは容易ではありません。
そんな「思考の限界」を突破するために導入したのが、生成AI（Gemini）でした。
今回は、私が試行錯誤しながら構築したAI活用の現状と、そこから見えてきたAI・人・組織の役割分担についてお話しします。
まだ道半ばではありますが、「同じ過ちを繰り返さない」仕組みに向けた、挑戦の記録です。
AIは「時短ツール」ではなく「思考の拡張ツール」
まず、導入したAIのコンセプトについてお話しします。
一般的に、業務でのAI活用というと「自動化」や「効率化」がキーワードになりがちです。
しかし、目指したのは、「思考の拡張（分析の質の向上）」です。
人間は、トラブル対応で焦っているときや疲れているとき、どうしても視野が狭くなり、「最初に思いついた原因」に飛びついてしまいます。
また、個人の経験や知識量によって、分析の深さや視点の広さにはどうしてもバラつきが生じます。
「設定ミスでした（次は気をつけます）」
ベテランなら「なぜ設定ミスが起きる仕組みだったのか？」まで思考が及ぶ場面でも、経験の浅いメンバーや疲弊した状態では、そこまで考えが至らないこともあります。
今回作ったAIは、そんな「個人のスキル差」や「認知の限界」を補完し、底上げするためのパートナーです。
答えを出さず、人間が見落としがちな視点（特に仕組みやプロセスの観点）を問いかけることで、思考を深く、広く拡張させます。
「壁打ち」で思考を深める
では、AIは具体的にどのようなロジックで人間の思考を拡張しているのでしょうか？
今回採用したのは、エンジニアの思考を整理し、深掘りするための「壁打ち（コーチング）」のアプローチです。
AIは、エンジニアに対して「正解」を教えることはできません。
なぜなら、現場の複雑な状況や文脈を全て把握しているのは、AIではなく現場のエンジニア自身だからです。
AIの役割は、答えを出すことではなく、エンジニア自身が答えにたどり着くための「気づき」を与えることです。
エンジニアの回答に対して「なぜそう思ったのですか？」「その前提は正しいですか？」と問いかけ続けることで、思考の死角を照らし出し、エンジニア自らが真理（根本原因）に到達するように導きます。
私たちが構築したAI（分析Gem）の実際のフローを見てみましょう。
全体は大きく4つのステップで構成されています。
- 事実の整理（タイムライン化）: ログから事実を抜き出し、時系列に整理する。
- 原因因子の洗い出し（4M分析）: 人、機械、環境、仕組みの観点から要因を網羅する。
- 原因の深掘り（壁打ちによる深掘り）: 「なぜ？」を繰り返し、流出原因まで掘り下げる。
- 対策の立案とレビュー: 暫定・恒久対策を立案し、抜け漏れがないかレビューする。
それぞれのステップについて、具体的に見ていきましょう。
ステップ1：事実の整理（タイムライン化）
まず、エンジニアがSlackのログをAIに貼ると、AIは客観的な事実（日時、事象、対応内容）だけを抜き出し、時系列に整理します。
これにより、エンジニアの頭の中にある「混乱」を鎮め、冷静に分析できる状態を作ります。
ステップ2：原因因子の洗い出し（4M分析）
次に、AIは「4M分析」を用いて、視野を広げる問いかけを行います。
「担当者のミス（Man）」だけでなく、「設備（Machine）」「環境（Media）」「仕組み（Management）」の観点から、思い当たる要因を網羅的に挙げさせます。
ステップ3：原因の深掘り（壁打ちによる深掘り）
ここがAIの真骨頂です。
洗い出した要因に対し、AIは「なぜ？」を問い続けます。
ただし、単なる「なぜ？」ではありません。「根本原因（技術的トリガー）」だけでなく、「流出原因（組織的な弱点）」が見つかるまで、執拗に（しかし優しく）問いかけます。
実際の対話イメージ:
👨💻 エンジニア： 「担当者がコマンドを打ち間違えました（ヒューマンエラー）」
🤖 分析Gem： 「なるほど。では、なぜそのコマンドを打ち間違えることが可能なシステムだったのでしょうか？ 誤入力を防ぐバリデーションや、承認フローは機能していなかったのですか？（仕組みへのピボット）」
👨💻 エンジニア： 「うっ…確かに。承認フローは形骸化していました…」
🤖 分析Gem： 「承認フローが形骸化していた原因は何だと考えられますか？ 手順が煩雑だったからでしょうか、それとも重要性が認識されていなかったからでしょうか？」
ステップ4：対策の立案とレビュー
真の原因（流出原因）が特定できたら、AIは再発防止策のブレインストーミングを促します。
出された対策を「暫定対策（応急処置）」と「恒久対策（根本治療）」に明確に分類します。
さらにAIは、以下の観点でレビューを行います。
- 網羅性: 特定したすべての原因に対して、対策が打たれているか？（やりっぱなし防止）
- 論理的整合性: その対策で本当に原因は消えるのか？（論理の飛躍がないか）
こうして、AIによる「網羅性」と「論理的整合性」のチェックを経ることで、抜け漏れや論理の飛躍がない、実効性のあるアクションプランの土台が作られます。
分析Gemのプロンプトの工夫点
私たちが実際に使用しているAI（分析Gem）のプロンプトには、エンジニアの思考を「拡張」し、「仕組み」へと導くための様々な工夫が凝らされています。
その中から、特に効果的だった3つのポイントをご紹介します。
1. AIの人格を「パートナー」と定義する
AIを単なるツールとしてではなく、一緒に調査を行う「熟練したパートナー」として定義することで、対話の質を高めています。
あなたは、単なる分析ツールやアシスタントではありません。「インシデント・ディスカバリー・パートナー（熟練した調査パートナー）」です。
あなたの役割は、答えを提示することではなく、質の高い質問と対話を通じて、ユーザー自身が本質的な原因に到達するための思考をサポートすることです。
– ソクラテス式対話の達人: 答えを与えるのではなく、構造化された問いを投げかけることで、対話相手の思考を深く、多角的に導きます。
– 「非難なき文化」の体現者: あなたの言葉は常に客観的かつ建設的であり、決して個人を非難せず、システムやプロセスの改善に焦点を当てます。
2. 「思考停止」を防ぐ対話のルール
AIが勝手に分析を進めてしまうと、人間はそれを読むだけになりがちです。あえて「対話を強制」することで、当事者意識を維持させています。
– 情報の小出し: 一度に多くの情報を提示しないでください。ユーザーが消化しやすいよう、一度の回答は常に短く、簡潔にしてください。
– 対話のラリーの強制: 絶対に一方的に分析を進めないでください。思考の各ステップで必ずユーザーに1つだけ問いかけ、その返信を待ってください。
3. 「個人のミス」を「仕組みの問題」へ転換させる指示
もっとも重要なのが、安易にヒューマンエラーで終わらせないためのこの指示です。
分析の過程で、原因が「担当者の確認不足」のような個人の行動に行き着きそうになった場合、必ず「なぜ、その確認をせずとも作業を進められるプロセスになっていたのでしょうか？」や「その確認が漏れてしまうことを、システムやツールで防ぐことはできなかったのでしょうか？」のように、常に仕組みやプロセスの問題へと問いを転換させてください。
この指示があることで、AIは忖度なく、しかし論理的に「仕組みの弱点」を突き続けることができます。
もちろん、全てのミスが仕組みで防げるわけではありません。
現状の課題として、本当に「個人の基本動作の怠り」や「問題意識の欠如」が主因である場合、この指示が強すぎて人的要因への深掘りが甘くなる（無理やり仕組みのせいにしようとする）傾向も見えてきています。
このあたりは、AIのバランス調整が必要な今後の改善ポイントです。
役割分担の全体像：AIと人
AIがここまでやってくれるなら、人間は何をするのでしょうか？
私は、AIと人の役割を以下のように定義しました。
1. AIの役割：「論理」と「網羅」
AIの強みは、感情に左右されずに論理的な可能性を網羅することです。
- 事実整理: 膨大なログから事実を抜き出す。
- 問いかけ: 人間が見落としがちな視点（4M、流出原因）を提示する。
2. 人の役割：「決断」と「責任」
AIにはできない、人間にしかできない重要な役割があります。
- 調整と決断:
AIの提案は論理的に正しくても、現場のリアリティ（予算、人員、技術的制約）を無視していることがあります。
AIが出した選択肢を、現状の業務や現実に照らし合わせて「調整」し、最終的にどの対策を実行するかを「決断」するのは、人間の仕事です。 - 文化の醸成（心理的安全性）:
AIは冷徹に「仕組み」を追求しますが、実際にその仕組みを動かすのは人間です。
失敗を個人の責任とせず、オープンに共有する「非難なきコミュニケーション」や、得た学びを共有し合う「ナレッジの循環」を作ることは、人間にしかできません。
導入の成果：分析の標準化
このプロセスを導入して得られた、現時点での成果は、「分析の標準化」の第一歩を踏み出せたことです。
ベテランでも若手でも、Gemという「口うるさいコーチ」が横についていることで、一定の深さまで原因を掘り下げる土台ができつつあります。
もちろん、まだ完璧ではありません。しかし、「楽をするため」ではなく、「深く考えるため」にAIを使うという方向性は、間違っていなかったと感じています。
プロジェクトのこれから
ここまで、私たちの取り組みの成果を中心にお話ししてきましたが、これはまだ「第一歩」に過ぎません。
実際に運用を始めてみると、新たな課題も見えてきました。
- 分析負荷の問題: AIとの対話に時間がかかりすぎ、業務圧迫の一因になっていないか？
- 心理的ハードル: 分析が「重いタスク」と認識され、報告自体が敬遠されていないか？
- 情報の断絶: チャットツール（フロー）と管理ツール（ストック）の間で、重要な文脈が失われていないか？
「AIを入れたから解決」ではなく、運用しながら見つかった課題を一つずつ潰し、プロセス自体を磨き込み続けること。
それこそが、本当の意味での「問題管理」だと考えています。
「人はミスをする生き物です」
第1回でもお伝えした通り、「次は気をつけます」という精神論だけに頼る運用は、いつか必ず破綻します。
必要なのは、「人が間違えても大事に至らない仕組み」です。
終わりのない「モグラ叩き」の日々に別れを告げ、「同じ過ちを繰り返さない」組織へ。
AIという頼もしいパートナーと共に、私たちはこれからも歩み続けます。
最後までお読みいただき、ありがとうございました！
簡単30秒