Windows Updateの情報を公式・コミュニティで横串検索してAIが調べてくれる「様子見KB」

最初に: 何を作ったか

ポートフォリオとして、Windows Updateの適用判断支援サービス「様子見KB」を開発しました。
目的はシンプルで、情シス担当者が毎月ぶつかるこの問いに早く答えることです。

「このKB、今当てて大丈夫？」

私が担当したのは、企画・設計・実装・運用改善まで一通りです。

• プロダクト設計（課題整理、判断フロー設計）

• フロントエンド実装（検索・一覧・詳細）

• バックエンド実装（データ集約、再評価）

• AI判定実装（要約、verdict、理由生成）

• 運用改善（cronと単発再評価の整合、品質修正）

課題: 何がつらかったのか

Windows Update運用の現場には、次の痛みがありました。

1. 情報が散らばっている
   公式Known Issues、コミュニティ報告、検索結果を行き来する必要がある。

2. 判断が難しい
   セキュリティ的には早く当てたいが、不具合リスクもある。

3. 説明コストが高い
   「なぜ待つのか」「なぜ進めるのか」を社内説明するのに時間がかかる。

解決方針: どう設計したか

様子見KBは、次の3点を軸に設計しました。

1. 情報をKB単位で一画面に集約する

2. 判定ラベルと理由を同時に出す

3. 例外文脈（OOB・統合KB）まで判断ロジックに入れる

つまり、「情報を見せるサイト」ではなく、
意思決定を前に進める道具を目指しました。

各機能の紹介（利用フロー順）

1. KB番号検索

KB番号を入力すると、該当情報へ最短到達できます。
最初の“迷い”をなくす入口機能です。

2. KB詳細ページ

1ページで以下を横断表示します。

• 公式Known Issues

• コミュニティ不具合報告

• AI要約

• 判定（ok / caution / wait / pending）と理由

3. 判定ラベル（verdict）生成

情報を並べるだけでなく、最終判断を支援するためにラベル化。
理由文もセットで出すので、社内共有に使いやすい形にしています。

4. OOB・修正関係を踏まえた判定

fixes_kb / merged_in_kb などの関係を考慮し、
「問題を起こしたKB」と「それを修正するKB」の混同を減らします。

5. 直近KB一覧（Patch Tuesday向け）

月次運用の初動確認を早めるため、直近配信KBを判定付きで一覧化しました。

6. 症状から探す導線

KB番号が分からないケース向けに、症状カテゴリやキーワードから逆引きできます。

7. OSビルドツリー表示

Windows 11のバージョン軸でKBを追えるので、影響範囲の把握がしやすくなります。

8. ウォッチリストと判定変化通知

気になるKBを監視し、判定の変化を検知。
「あとで気づく」を防ぎます。

通知機能に状態変化をお知らせします。

9. ゲスト/ログインの閲覧範囲制御

初回体験と継続利用の両立を意識し、閲覧範囲を段階設計しています。

10. 定期再評価 + 単発再評価

運用では「今すぐ再評価したい」が必ず起こるため、
cronだけでなく単発実行経路も用意しました。

技術的に頑張ったところ

1. AIの「もっともらしい誤読」を減らした

AIは自然な文章を作るのは得意ですが、文脈の取り違えが起きます。
特に「この更新で問題が起きた」のか「この更新で別の問題を直した」のかは、読み違えると結論が逆になります。
そこで、判定ルールを明文化して、AIが迷いにくい入力に整えました。

2. 「自動再判定」と「手動再判定」で結果がズレないようにした

以前は、

• 定期的に自動で回る再判定

• 管理者が1件だけ手動で再判定
  で、内部の判定手順が違っていました。
  その結果、「自動だとA判定、手動だとB判定」が起きる状態でした。
  今は判定処理を共通化して、どちらで実行しても同じ結果になるようにしています。

3. 数値データはAI任せにしない方針にした

「注目度（upvote最大値）」のような数値をAIに推測させると、見た目は自然でも事実とズレます。
そのため、数値は必ずデータベースの実測値を使う設計に変更しました。
文章はAI、数値は実データ、という役割分担です。

4. 一部データが取れなくても画面全体は落とさないようにした

詳細ページでは複数の情報をまとめて表示しています。
以前は補足情報の取得に失敗すると、ページ全体が表示できなくなるリスクがありました。
今は「補足がなくても本体は表示する」作りにして、使える状態を優先しています。

5. 再判定の順番を工夫して、反映を速くした

毎回すべてを再判定すると遅くなります。
そこで「未処理」「新しい不具合報告が増えた」「公式情報が更新された」ものから優先して処理するようにしました。
限られた時間で、必要な更新を先に反映できます。

6. 通知を“必要なときだけ”出すようにした

判定を毎回通知すると、通知疲れで読まれなくなります。
判定が実際に変わったときだけ通知する仕組みにして、重要な変化を見逃しにくくしました。

7. 連続処理で落ちにくいように運用設計した

外部AIを連続で呼ぶと、混雑や制限で失敗することがあります。
呼び出し間隔やエラー時の扱いを調整して、まとめ処理でも止まりにくい運用にしています。

8. 実運用で見つかる問題を前提に、改善を回し続けた

このプロジェクトは「作って終わり」ではなく、運用しながら改善するタイプです。
実データで見つかった例外やレビュー指摘を継続的に反映し、判定の信頼性と安定性を上げ続けています。

使った技術

• Frontend: Next.js (App Router), TypeScript, Tailwind CSS

• Backend: Supabase (PostgreSQL, Auth)

• AI: Anthropic API

• Ops: crawler + scheduled jobs + manual re-run endpoint

まとめ

様子見KBは、
情報収集 → 判断 → 社内説明を短縮するための実運用志向プロダクトです。

この開発で一番大きかった学びは、
「AIを使うこと」より「AIを運用で壊れない形にすること」の難しさでした。
今後は、通知体験と履歴比較をさらに強化し、Patch Tuesday運用で本当に頼れる道具に育てていきます。