awesome-devops-aiとは｜AI×DevOpsツール474選のカテゴリ地図とリンク健全性を実測

「AI×DevOpsのツールを一通り見渡したい」と思っても、対象はコーディングエージェントからMCPサーバー、インシデント対応SaaSまで散らばっていて、全体像を掴む手がかりが少ない。awesome-devops-ai は、その領域を19のカテゴリに整理して474件を1枚のREADMEに集めたキュレーションリストである。本記事では、この「474選」という表記が本当に474件なのかを機械カウントで数え直し、収録リンクの生死・スター分布までGitHub APIで実測して、AIがインフラ運用のどこに入り込んでいるかを地図として読み解く。

AI前提の自動化ツール全般をノーコードからコードまで俯瞰したい場合は、AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 を先に読むと、本記事のカテゴリ地図が置かれている座標が掴みやすい。

awesome-devops-aiとは——AI×DevOpsの道具を19カテゴリに束ねたCC0のリスト

awesome-devops-ai は、Hammad Haqqani 氏が2026年2月16日に公開したキュレーションリストである。「awesome list」と呼ばれる形式で、リポジトリにソフトウェアは含まれず、README.md というMarkdownファイル1枚が成果物そのものになっている。

2026-08-04時点でGitHub APIから取得した実体は次のとおりだった。

まず規模について正直に書いておくと、★22は「定番リスト」と呼べる水準ではない。同種のリストであれば数千から数万スターに達するものも珍しくない。この記事の価値はリストの知名度ではなく、474件を実際に数え・叩いて得られた測定結果のほうにある。

特徴的なのはforkがスターを上回っている点（fork 23 > ★22）だ。awesome list はプルリクエストで項目を追加してもらう運用のため、「自分のツールを載せたい人がforkする」動きがスターより先行することがある。実際、オープンissueが9件あり、外部コントリビューター7名の多くは自作ツールの追加PRを出している。

ライセンスは CC0-1.0。これはパブリックドメインに近い扱いで、リストの構造や分類をそのまま引き写して別の資料を作ることも制約なく認められる。awesome list はMITやCC-BY-4.0を選ぶものが多いなかで、CC0はより緩い部類にあたる。

リポジトリに含まれるファイル

README.md 以外には、運用のための小さなファイルが並ぶだけである。

・GUIDE.md（4,459バイト）——役割別（SRE志望・プラットフォームエンジニア等）の読み始め案内
・CONTRIBUTING.md（4,469バイト）——項目追加のルール
・CODE_OF_CONDUCT.md / SECURITY.md / LICENSE
・.github/——CI設定（awesome-lint とリンク切れ検査）

コミット履歴を見ると、Fix 4 broken links found by link checker Fix awesome-lint: proper punctuation, no duplicate links, spelling fix といったメッセージが繰り返し現れる。リンク検査と書式検査をCIで回す運用は実際に機能している——後述するとおり404は474件中1件に抑えられており、これは手作業で維持されたリストとしては良好な数字だ。

「474選」を数え直す——実測した件数と、その数え方

キュレーションリストが名乗る件数は、数え方が書かれていないことが多く、そのまま引用すると危うい。そこでREADME全780行を機械的にカウントした。

数え方は次のとおりである。コードブロックの中を除外したうえで、- [名前](URL) の形をした行だけを、H2見出しごとに集計した。

結果、道具を掲載している19個のH2セクションの合計はちょうど474件となり、READMEが名乗る「474 tools」と完全に一致した。さらに、

・名前の重複は0件（474件すべて異なる表記）
・URL文字列の重複も0件（474件すべて異なるURL）

つまり、少なくとも「単純な重複による水増し」は無い。キュレーションリストとしては誠実な数字である。

「20カテゴリ」の数え方だけは一致しない

READMEは「474 tools across 20 categories」と書いているが、道具を載せているH2は実測で19個だった。20に合わせるには、書籍・資格・ポッドキャストを収めた Learning Resources（44件）を1カテゴリとして加える必要がある。この解釈なら19＋1で20となり辻褄が合うが、READMEに明示はないためここは推定であることを断っておく。

なお、道具以外のセクションまで含めた総リンク数は次のようになる。

「474」は最も狭い数え方の値であり、リンク総数で言えば538件ある。リストを引用するときは、この差を意識しておくと数字がぶれない。

過去の総数表記は、実測と約27件ずれていた

READMEには What's New という更新履歴があり、更新のたびに総数を名乗っている。この履歴を過去のコミットまで遡って検証すると、興味深い構造が見えた。

まず、公称値そのものが 前回の公称値＋追加数 という足し算で更新され続けていたことが確認できる。

2026年3月から5月までは、公称値が1件の狂いもなく足し算で繋がっている。ところが2026年7月の更新だけは、502＋56＝558にならず 474 が掲載された。

一方、実測値（同じ数え方を各コミットに適用）はこうだった。

差が5か月にわたって約27件で固定している。これは数え漏れが徐々に蓄積した「ドリフト」ではなく、起点の数え方が違ったまま、その差を保って足し算が続いたことを示している。そして2026年7月の更新で数え直しが行われ、以降は実測と一致した。

したがって「502から474へ28件減った」のは項目が削除されたのではなく、数え直しの結果と読むのが自然だ。実際この更新では56件が新規追加されており、追加前の実測417件に56を足すと473件、その後の微修正を経て現在の474件になる——追加数の内訳もカテゴリ別に列挙されており（MCPサーバー15件、インシデント対応8件、セキュリティ6件……）、その合計はちょうど56件で計算が合う。

カテゴリ地図：AIはインフラ運用のどこに入り込んでいるか

件数が信用できると分かったので、本題であるカテゴリの分布を見ていく。19カテゴリの内訳を、件数の多い順に実測値で並べたものが次の表である。「GitHub」列は、リンク先が https://github.com/ で始まるものの数を示す。

この表からは、単なる件数以上のことが読み取れる。

MCPサーバーが最大勢力である意味

87件という数字は全体の18.4%にあたり、2位のセキュリティ走査（47件）に倍近い差をつけている。MCP（Model Context Protocol）はAIモデルと外部システムを繋ぐ規格で、「既存の運用基盤をAIから触れるようにする」層にあたる。

収録されているMCPサーバーの顔ぶれを見ると、その性格がはっきりする。クラウド事業者（GCP・DigitalOcean・Oracle・Linode・Vultr・Hetzner・Alibaba Cloud）、監視SaaS（New Relic・Splunk・Elastic・Dynatrace・Honeycomb・Chronosphere・Better Stack）、CI/CD（CircleCI・Buildkite・Harness）、データベース（MongoDB・Redis・Neon・Supabase・Snowflake・ClickHouse）、インシデント管理（Rootly・FireHydrant・incident.io）——つまり既存のDevOpsスタックのほぼ全レイヤーに、AI接続用の入口が生えている状態だ。

この層が最大になっているのは、AIがインフラ運用に入り込む経路として「既存ツールを置き換える」より「既存ツールに接続する」ほうが先行していることを示している。可観測性の基盤そのものをAI前提で選び直したい場合は OpenObserve 解説｜140倍低コストなDatadog代替オブザーバビリティ基盤 のような基盤側の選択肢と、この接続層を分けて考えると整理しやすい。

GitHub比率が示す「自前で動かせるか」の差

GitHub列の比率には、カテゴリごとにはっきりした傾向がある。

・高い（自前で動かせるものが中心）：GitOps 100%、ネットワーク 88%、エージェント基盤 85%、Kubernetes運用 79%、ログ解析 79%、MCPサーバー 78%
・低い（商用SaaSが中心）：インシデント対応 16%、セキュリティ走査 17%、クラウド移行 17%、コスト最適化 20%、プラットフォーム基盤 22%

この分かれ方には理屈がある。GitOpsやKubernetes運用は「クラスタの中で動かす」性質のためOSSが自然であり、逆にインシデント対応やコスト最適化は「組織の課金データやオンコール体制と結びつく」ためSaaSに寄る。セキュリティ走査47件のうちGitHubリンクが8件しかないのは、この領域の新規参入がほぼ商用ベンダーであることの現れだ。

クラウド資産の棚卸しをSQLで自前でやる方向に寄せたい場合は Steampipe入門：SQLでAWSリソースをリアルタイム検索できるクラウド監査ツール、稼働監視を自前ホストで完結させたい場合は Checkmateとは：稼働監視OSSをDockerでセルフホスト｜Uptime Kuma比較と実測 が、それぞれSaaS偏重カテゴリに対するOSS側の対抗馬になる。

運用ループのどこに何が置かれているか

19カテゴリを、実際の運用ループ（コードを書く→出す→動かす→壊れる→直す）に対応づけると、リストの構造がより見やすくなる。

こう並べると、ループの各段にはおおむね20〜40件の選択肢があるのに対し、それらを横断して繋ぐMCPサーバー層だけが87件と突出していることが分かる。AIがインフラ運用に入る入口は、いまのところ「各工程を置き換える」より「各工程を横断して触れるようにする」方向に厚みがある。

リンクの健全性を実測する——404は1件、ただし6.5%は転送頼み

キュレーションリストの実用性は、載っている件数よりもリンクが今も生きているかで決まる。474件のうちGitHubを指す248件（リポジトリ形式のURL）について、GitHub APIで全件を解決した。

結果は次のとおりである。

404は474件中わずか1件で、これはCIでリンク検査を回している効果が出ている。ただしその1件、salesforce/logai は現在404を返しており、検査をすり抜けている。

16件は「GitHubの転送」に支えられている

より注意が必要なのは、リンク先が改名・移管されているのに旧パスのまま残っている16件（248件中6.5%）である。GitHubはリポジトリ名やオーナーが変わっても301リダイレクトを維持するため、これらのリンクはクリックすれば正しく着地する。つまりリンク検査CIでは検出できない。

この一覧は、リストの鮮度そのものより「この1年でAI関連プロジェクトの持ち主がどれだけ動いたか」を映しているとも読める。meta-llama/llama-stack が ogx-ai/ogx になっているように、オーナーごと移管された例も含まれる。

改名によって生じた重複が1組

URL文字列としては474件すべて異なると先に書いたが、改名を解決すると同一リポジトリを指す組が1つ現れる。

・nowork-studio/toprank（掲載名: toprank）
・nowork-studio/NotFair（掲載名: NotFair）

前者は後者へ301転送されるため、同じリポジトリが同じカテゴリ（コーディングエージェント）に2回載っている状態になる。説明文もそれぞれ「9つのSEO・Google Adsスキル」「SEO・GEO・Google Ads・Meta Adsのスキル」と別物のように書かれており、改名前後の記述が両方残ったものと読める。

なお、KubeStellar Console も2箇所（Kubernetes運用とMCPサーバー）に登場するが、こちらは片方がリポジトリ直下、もう片方が /tree/main/cmd/kc-agent というサブディレクトリを指しており、同一リポジトリ内の別コンポーネントを別カテゴリに載せた正当な相互掲載である。重複とは区別しておきたい。

アーカイブ済み7件と、1年以上更新の無い9件

リンクが200を返すことと、プロジェクトが生きていることは別である。解決できた246件のうち、7件はアーカイブ済み（作者が更新停止を宣言した状態）だった。

さらに、アーカイブ宣言こそ無いものの1年以上pushが無いものが9件ある。最長は komodorio/validkube の918日で、以下 robusta-dev/kubernetes-chatgpt-bot（621日）、feiskyer/kube-agent（536日）、superfly/flymcp（483日）と続く。MCPサーバー系の個人実装がここに多く含まれる。

説明文の数字が実体と噛み合わない例

もう1つ、実測して気づいた点を挙げておく。OpenCode の項目には次のように書かれている——「Go-based terminal AI coding agent with 140k+ GitHub stars」。

しかしリンク先の opencode-ai/opencode を実測すると、スターは13,609、しかも2025-09-18を最後にアーカイブ済みである。言語がGoである点は説明文と一致する。一方、同名で広く使われている sst/opencode は TypeScript製・192,857スター・更新継続中で、こちらはリストに収録されていない。

つまり説明文は、リンク先リポジトリの属性（Go製）と、それとは別のリポジトリのスター規模（14万超）が混ざった記述になっている。どちらの意図だったかは公開情報からは判断できないため断定は避けるが、キュレーションリストの説明文に書かれたスター数は、リンク先を開いて確かめるべき情報である実例として押さえておきたい。

収録リポジトリのスター分布と、「Most Starred」表のズレ

リストに載る246リポジトリのスターを実測すると、規模の分布が見えてくる。

中央値は5,001スター。1万スター未満が155件（63.0%）を占める一方で、10万超の巨大プロジェクトも9件含まれる。これは「実績あるものだけを厳選したリスト」ではなく、規模を問わず横並びに載せる方針であることを意味する。100スター未満の36件は、その多くが個人が書いたMCPサーバー実装である。

この方針は良し悪しの問題ではなく、使い方の問題だ。採用候補を探す用途なら規模と更新日で自分でふるいをかける必要があり、逆に「どんなアプローチが試されているか」を眺める用途なら小規模実装が多いことはむしろ利点になる。

「Most Starred Projects」表は、スター順に並んでいない

READMEには Most Starred Projects（スター数が多いプロジェクト）という16行の表があり、「The most popular open-source projects in this list by GitHub stars」と説明されている。この表の並び順を実測値と突き合わせた。

16行のうち位置が一致したのは2行だけである。最も極端なのは、実測1位のOpenClaw（385,047スター）が4番目に置かれ、その上にFlowise（55,122スター）が来ている点だ。

ここで押さえておきたいのは、この表のスター数自体は間違っていないことである。表はshields.ioのバッジ画像でスター数を表示しており、数字は閲覧時点で常に最新に更新される。古くなるのは並び順だけだ。結果として、読者は「385,047」と表示された行の上に「55,122」の行が並んでいる状態を見ることになる。

これは、動的に更新されるバッジと静的な並び順を混在させたときに起きる典型的なズレである。順位を主張する表を作るなら、並び替えも定期的に回す必要がある——という運用上の教訓として読める。

awesome-devops-aiの読み方——どこから手をつけるか

ここまでの実測を踏まえて、このリストを実際に使う場合の勘所をまとめる。

目的別の入口

・既存の運用基盤にAIを繋ぎたい→ MCPサーバー（87件）。自社で使っている監視・CI/CD・DBの名前で検索すると、対応するサーバーが見つかる可能性が高い。カテゴリ内のGitHub比率が78%と高く、自前で動かせるものが中心
・インフラコードの記述を任せたい→ コーディングエージェント（42件）とTerraform・IaC（23件）。ただしこの2カテゴリは商用ツールの比率が高め（GitHub比率45%・39%）
・障害対応を効率化したい→ インシデント対応（31件）。ただしGitHub比率16%で、ほぼ商用SaaS。自前運用を前提にするなら選択肢は5件程度まで絞られる
・まだ層が薄い領域を知りたい→ クラウド移行（6件）・GitOps（7件）・ネットワーク（8件）・カオス工学（8件）。件数が少ない領域は、単純に選択肢が乏しいことを意味する

エージェント基盤（39件）に踏み込む場合は、フレームワーク側の比較を先に押さえたほうが選定が早い。AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 が実コードベースの比較にあたる。

使うときに自分で確かめること

実測結果から言えば、このリストはカテゴリ分けと網羅性は信頼できるが、個々の項目の鮮度は自分で確認する必要がある。具体的には次の3点である。

・最終push日とアーカイブ表示——7件はアーカイブ済み、9件は1年以上更新なし。リンクが開くことは生存を意味しない
・説明文中のスター数・ベンチマーク値——OpenCodeの「140k+」のように、リンク先の実体と噛み合わない記述がある
・リンク先が実際に何か——GitHubリンクの一部は製品ページやサブディレクトリを指す。リポジトリ直下とは限らない

CC0であることの実務的な意味

ライセンスがCC0-1.0である点は、実務上わりに大きい。カテゴリ構成をそのまま社内の技術選定資料に転記しても、ライセンス上の制約がほぼ無い。19カテゴリという分類軸自体が、AI×DevOpsの検討範囲を漏れなく並べるチェックリストとして流用できる。

一方で、内容の正確性はCC0とは無関係である。転記するなら、少なくとも自社で採用候補に挙げる項目については、本記事で行ったような最終push日・アーカイブ状態・実際のスター数の確認を通してからにしたい。

まとめ

awesome-devops-ai を2026-08-04時点で全件実測した結果を整理する。

・「474選」は正確だった。道具を載せる19カテゴリの合計はちょうど474件で、READMEの表記と一致。名前・URLとも重複0件
・「20カテゴリ」だけは数え方が不明。道具を載せるH2は実測19個で、Learning Resourcesを含めれば20になるが明示はない
・過去の総数表記は約27件ずれていた。公称値は「前回値＋追加数」で更新され続けており、2026年7月の数え直しで実測と一致した。502→474は削除ではなく訂正
・最大勢力はMCPサーバーの87件（18.4%）。AIは各工程を置き換えるより、横断して繋ぐ方向に厚みがある
・OSS一覧ではない。GitHubリンクは52.7%で、残り47.3%は商用製品ページ。インシデント対応・セキュリティ走査はSaaS偏重
・リンクは概ね健全だが鮮度は別。404は1件のみだが、16件が改名後の旧パス、7件がアーカイブ済み、9件が1年以上更新なし
・規模は★22と小さい。リストの知名度ではなく、19カテゴリという分類軸とCC0ライセンスに実務的な価値がある

AI×DevOpsの全体像を掴む地図としては十分に機能する。ただし地図に描かれた個々の地点が今も存在するかは、行く前に自分で確かめる——というのが、実測して得られた最も実務的な結論である。

参照ソース

・hammadhaqqani/awesome-devops-ai（GitHubリポジトリ・README） — 本記事の全カウントおよびカテゴリ分類の対象。2026-08-04時点のmainブランチ（最終push 2026-07-08）を取得して計測
・GitHub REST API - Repositories — スター数・fork数・ライセンス・アーカイブ状態・最終push日時・改名後の正規リポジトリ名の取得に使用。リポジトリ改名時もAPIは現行の full_name を返すため、旧パス掲載の検出に利用した
・コミット ff1037cd「Add 56 new AI DevOps tools and MCP servers (2026 refresh)」 — 2026年7月の数え直しが行われた更新。本記事の「502→474は削除ではなく訂正」の根拠として、このコミット前後のREADMEを取得して件数を比較した
・Creative Commons CC0 1.0 Universal（ライセンス全文） — 本リポジトリが採用するライセンス条項