プロジェクトの炎上を、人より早く検知する内製AIツールの話

開発会社にとって「プロジェクトの炎上」は、起きた後に取り返すのが極端に難しい問題です。深夜の議論が増え、誰かが体調を崩し、顧客との関係がぎくしゃくし始めるころには、もう既に手遅れであることが多い。何を予兆と見て、誰がどう判断するか。私たちはここに AI を入れた仕組み（Lighthouse）を作り、約半年運用してきました。出来上がったものと、運用して分かったことを書きます。

きっかけは「もっと早く言ってよ」だった

ある案件で、開発側の負荷が予想以上に上がっていたことが、マネジメント層に共有されたのは、状況がかなり進んでからでした。現場としては「相談するタイミングを逃した」、マネジメント側としては「もっと早く言ってほしかった」、というすれ違いが残りました。

似たことは過去にも何度かあって、原因はいつも一つでした。事象が起きた時に「これはエスカレーションすべき」と判断する基準が、各人の経験に依存していたこと。だから、AIに毎朝代わりに見させて、危険な兆候があれば届ける仕組みを作ることにしました。

3つの解析エージェントが毎朝走る

全プロジェクトを対象に、毎朝バッチが走ります。解析を担当するのは、用途別に分けた3つのAIエージェント。それぞれが違う観点でプロジェクトの状態を読み、最終的にマネジメント宛のサマリーを一通生成します。

1つ目は「アラート担当」。勤怠データを読んで、特定メンバーへの偏り、長時間労働、急な稼働増を検知します。2つ目は「採算担当」。案件の進捗率と消化工数を見て、予実差を出します。3つ目は「全体担当」。複数のシグナルを統合して、上位の優先順位を決めます。

設計でいちばん悩んだのは倫理面

技術的な実装より、人の扱い方の方が時間がかかりました。AIに「このプロジェクトは危ない」と言わせると、出力の中に必ずプロジェクトマネージャーの名前が出てきます。そのまま流すと「あの人のせい」で読まれる結果になり、組織にとって良くない方向に進みます。

結局、プロンプトレベルで「PM名はマスクしてLLMに渡す」「メンバー名は事実として扱う」ルールを徹底することで解決しました。原因はチーム構成や設計判断にあることが多く、犯人探しではなく構造で読む設計にしています。これは技術的にはちょっとした処理ですが、組織での受け入れられ方は大きく変わりました。

運用して分かったこと

半年運用して気づいたのは、「アラートを鳴らす」より「アラートを鳴らさない」を上手くすることのほうが大事だということでした。最初の数週間は、しきい値を低めに設定して大量のアラートを出しましたが、すぐに「狼少年」化してマネジメントが見なくなりました。今は、burn rateの考え方を借りて、「2週間続いたら鳴らす」「複数シグナルが同時に出たら鳴らす」設計にしています。

もう一つは、AI が万能ではないという当然のことです。Lighthouse が拾えない種類の問題（特に顧客との関係性の機微）は当然あります。だから、ツールが出すリストは「マネジメントが見るべき優先順位」として扱い、最終判断は人に残します。これも導入時に組織内で何度も確認した点です。

これから外に出したいと思っている理由

同じ困りごとは、おそらく日本中の開発会社が抱えています。PMが頑張って情報を集めて回って、その情報がマネジメントに上がるまでに時間がかかり、上がった時には事態が進んでいる。この構造は、業界共通の問題だと思います。

外販を視野に入れて、ベータテストを募集しています。データ連携・組織への馴染ませ方は会社ごとに違うので、共同検証の形で進めたい段階です。サービスページに詳細を載せています。