Upgrade to Pro — share decks privately, control downloads, hide ads and more …

探偵のように調査するAI 〜可観測性×AIの実践と展望〜

探偵のように調査するAI 〜可観測性×AIの実践と展望〜

障害発生時、複数ツールを手動で調査していませんか?AIエージェントが探偵のように証拠を集め、原因を推理する「AIOps」の実践事例を紹介。自社でのAI × Platform Engineeringの取り組みも交えて解説します。

https://members05.live.itmedia.co.jp/library/OTcxOTY%253D?group=2602_OPELIVE#keynote2-1

Avatar for Kazuhiro Hashimoto

Kazuhiro Hashimoto

February 16, 2026
Tweet

More Decks by Kazuhiro Hashimoto

Other Decks in Technology

Transcript

  1. Copyright © Timee All Rights Reserved 3 自己紹介 
 2002〜2014:SIer

    x 2社 ネットワークエンジニア 2015〜2024:ゲーム会社 x 2社 サーバインフラ / SREリード 2024/07〜:株式会社タイミー Platform Engineering 1G にICとしてJOIN 2024/11〜:同、株式会社タイミー 同チームにてGroup Manager SRE / Platform Engineering AWS / GCP IaC / GitHub Actions プロダクトセキュリティ
  2. ⼈が集まる 稼働率:86% ※1 競合優位性① 働きぶりが良い ワーカーの リピートワーカー率:65%※2 無断⽋勤率:約0.4%※3 競合優位性② ⼿厚いサポート

    営業による 営業⼈数:757⼈※4 競合優位性③ ※7 求⼈掲載数 ※6 サービス利⽤率 タイミー A社 B社 ※8 マーケットシェア推計 ⽇本におけるパイオニアとしてのNo.1のポジショ ン ※5 新規参⼊企業の増加の中でも圧倒的な業界プレゼンスを確⽴ 新規参⼊増加により競争環境に変化が⽣じるものの、先⾏者優位性や⾼い業界知名度により、サービスの地位は不変。 ※1:FY25/10 4Qの稼働⼈数を募集⼈数で除して算出 ※2:2025年10⽉末時点における、サービス開始以降、レビュー済ワーカーのうち同⼀の職場で2回以上勤務経験のあるワーカーの割合 ※3:無断⽋勤は申告なしの⽋勤を指す。分⼦は2025年8⽉から2025年10⽉の無断⽋勤数。分⺟は同期間に充⾜された求⼈数 ※4:2025年10⽉時点の営業⼈数 ※5:ワーカーの観点ではサービス利⽤率※6、クライアントの観点では求⼈掲載数※7に基づく ※6:調査委託先 マクロミル  調査⽅法 インターネット調査  調査時期 2025年1⽉31⽇から2025年2⽉4⽇  調査対象 直近1年以内にスキマバイトを経験したことのある18から69歳の男⼥1,033⼈ ※7:調査機関 ⽇本マーケティングリサーチ機構  調査期間 2025年5⽉13⽇から2025年6⽉12⽇  調査概要 2025年6⽉期_スキマバイトにおける市場調査 ※8: スポットワーク市場規模の推計レポート(スポットワーク研究所)( https://spotwork.timee.co.jp/entry/report/marketsize-2024 ) 6
  3. Copyright © Timee All Rights Reserved 開発体制・ PFE1Gの位置づけ 
 共通基盤チームの一つ

    (インフラ+SREの職能チーム) 開発者組織(複数チーム)
  4. Copyright © Timee All Rights Reserved 11 チームミッションと主要な技術要素 
 SRE・インフラエンジニアな職能。開発チームの認知負荷を軽減し、

    スケーラブルなプラットフォームを提供する。 AWS クラウドインフラの 設計・運用 Terraform IaC Infrastructure as Code によるインフラ管理 Datadog モニタリング 可観測性 GitHub Actions CI/CDパイプラインの 構築・運用 主なスキルセット チーム・ミッション ※AWS、Terraform、Datadog、GitHub Actions の名称・ロゴは各社の商標です。 一部の画像は AI画像生成サービスにより作成しています。
  5. Copyright © Timee All Rights Reserved 13 その他の取り組み - AIにPFEのドメイン知識を持たせる取り組み(

    WIP)
 ※この構成は開発中のものであり実際の仕組みと異なる場合があります。 ※AWS及び各リソース、 GitHub、Devinの名称・ロゴは各社の商標です。
  6. Copyright © Timee All Rights Reserved 15 障害調査 = 職人芸


    ※画像はAI画像生成サービスにより作成しています。
  7. Copyright © Timee All Rights Reserved 職人芸? 
 1. 複数ツールの横断

    2. 手動での相関分析 3. 属人的な「勘」 1. ツール横断 — 監視ツール、インフラ、コード、チャット … 情報が散在していて、どこを見るかの判断自体が経験頼み 2. 相関分析 — メトリクスの異常 → 該当ログの特定 → コード変更の確認 → インフラ構成の把握… を頭の中でつなぐ 3. 「勘」 — 「このパターンはあのサービスっぽい」「前にも似たことがあった」暗黙知で初動の方向が決まる
  8. Copyright © Timee All Rights Reserved 21 でも全部渡せばいい? - コンテキストマネジメント

    
 AIの推論精度を最大化するために、膨大な情報の中 から 『今、解決すべきタスク』に最適な情報 だけを動的に選別・構成し、 AIの『認知環境』を整える 技術 と、考えています (2026年初頭現在 AIと壁打ちして整理 ) → 全部渡せばいいわけではない。「何を、どの順で」を 制御した方が精度が増す(※いま2026年初頭段階では) → 「探偵」としてAIに活躍させるためには、ある程度の”職人芸”がまだ必要でエンジニア介在価値 である 質: プロンプトの与え方 量: コンテキストサイズ 質: モデルの進化 量: 大きなコンテキスト 何を?どの順? さらなる進化で また違う課題・意味合いへ 少し前 今 これから
  9. Copyright © Timee All Rights Reserved /api/v1/matching/workers/xxxxxx/shifts で5xxエラーが発生 ① まずパスとエラーメッセージを与える

    【何がおきたのか】 ② 当該パスがどのようなサービスか? 【コードや仕様書を与えて理解】 ③ 処理が特定のインフラ/SaaSに関連 【より周辺情報を与えて深堀り】 22 例: 5xxエラー調査の場合 
 全部一度に渡すのではなく、必要な順で必要な情報に ”AIの注意”を向けさせること 現時点は「Attentionの管理」 = コンテキストマネジメントの大きな要素 と捉えています
  10. Copyright © Timee All Rights Reserved 25 実践例: 2つのアプローチ 


    勝手な命名ですが以下2つのアプローチができつつあると見ています 💪 DIY型 • 操作者がAttention管理を行う • Coding AgentやMCP等の選定・構築、情報の取捨選択で自由度あり ☁ マネージド型 • 動作制御はプラットフォーム側に委ねられる • Integration設定でコンテキストを与える形に? → まず普段実践するようになってきたDIY型からご紹介します
  11. Copyright © Timee All Rights Reserved 26 DIY型: Claude Code

    + コード + インフラ構成 + メトリクス /ログ

  12. Copyright © Timee All Rights Reserved 28 Claude Codeでの動作例( datadog

    mcp 調査結果) 
 実際のスクショを貼ります
  13. • 🚧 課題 🚧 ◦ 情報の順番・範囲を自分で設計する必要がある ◦ AIに何をどこまで見せるか・セキュリティ ◦ AI

    Coding Agentのツール整備・ガバナンス・コスト ◦ コンテキストマネジメントなどAIツールの使いこなし • 🎯 メリット 🎯 ◦ AIへの知識転写 (AI向けルールの整備)による属人性排除 が可能 ◦ 専任者を立てられない組織の自走性を上げられる(xCoEと相性良し) DIY型の課題 /懸念と得られるメリット 
 発展途上であるが故の 投資対効果見極め 踏み切りの難しさ
  14. Copyright © Timee All Rights Reserved 30 マネージド型 : ※一例※

    AWS DevOps Agent
 AWS re:Invent 2025で発表(Preview) • AWSリソースのトポロジーを自動把握(AWSインフラのコンテキストを標準で保持) • GitHub、Datadogなど外部連携(MCP等)をして調査対象に加えることができる
  15. Copyright © Timee All Rights Reserved 32 AWS DevOps Agentだと良さそうなところ(

    DIY型と比較して) 
 この部分は 試せていません この部分は 試せていません ※注 2026/2月現在Preview中
  16. Copyright © Timee All Rights Reserved DIY型とマネージド型の棲み分け(現時点での個人的な見解です) 
 DIY型 💪

    良さそう - 用途の柔軟性は高い - 実用レベルに達しており始めやすい 🥺 課題感 - 使いこなしの慣れや学習コスト必要 - コストやセキュリティの統制観点 マネージド型 💪 良さそう - コスト・セキュリティの制御(相対的に) - 学習コストや慣れやすさ(相対的に) 🥺 課題感 - DIY型ほど用途に柔軟性がない(かも) - まだまだ発展途上 中長期的にはマネージドに収斂 DIY型は今だけかもしれません。 でも、今、運用支援に取り入れるの はアリだと思います
  17. Copyright © Timee All Rights Reserved 35 まとめ
 • 障害調査の「職人芸」は

    AIに移転できる ◦ ツール横断・相関分析・暗黙知、これらをAIが肩代わりする時代が来ている • 鍵は「コンテキストマネジメント」 ◦ AIの注意をある程度コントロール。全部渡すよりも精度や速度が上がることも • まずは手元の情報を AIに食わせて みる ◦ コード(直接)、インフラ(CLI)、監視(MCP)。始めるハードルは下がってきた • AI x 可観測性 / AIOps界隈の進化 に弾みがついてきた ◦ まずはDIY型でお試しから。今後はマネージド型 / AIOpsサービスも加速しそう