イベント
コスト高騰、電力・熱の壁、AIハーネス――「CODT 2026」で見えたAI時代のインフラ運用の現在地
2026年9月15日 06:15
クラウドインフラ運用技術者のための年次カンファレンスイベント 「Cloud Operator Days Tokyo 2026（CODT2026）」の基調講演を含むクロージングイベントが、9月11日にオフラインで開催された。会場は、東京・お台場の「docomo R＆D OPEN LAB ODAIBA」。
イベントは7月23日から各セッションをオンデマンドで配信してきた。そしてクロージングイベントでは、その中から選ばれたものがリアルセッションとして実施された。
今年のCODTのテーマは「運用者に光を！ ～AIとどう向き合うか～」。このテーマのとおり、システム運用にAIを取り入れるAIOpsや、AI利用の環境整備、AI開発のプラットフォームなどについてのセッションが多く登場した。
クロージングイベントでは、午前中にオフライン版セッションを実施し、午後には基調講演やパネルディスカッションが行われた。また、オンラインで配信された中から優れたセッションを選考し表彰する「輝け！クラウドオペレーターアワード2026」の発表と授賞式も行われた。
「輝け！クラウドオペレーターアワード2026」発表
「輝け！クラウドオペレーターアワード2026」は、全セッションの中から優れたセッションを表彰するものだ。このアワードは、発表して終わりにせず、イベントのテーマのように「運用者に光を」あてることを意図している。
授賞式では、審査委員会が選んだ「最優秀オペレーター賞」「審査員特別賞（変革編）」「審査員特別賞（挑戦編）」と、実行委員会が選んだ「実行委員会特別賞」、視聴者の人気（再生数）から選んだ「オーディエンス賞」、若手発表者を表彰する「ヤングオペレーター賞」が発表された。
なお、審査委員会に筆者も参加していることをお断りしておく。
最優秀オペレーター賞
最優秀オペレーター賞には、株式会社NTTドコモの安藤寛史氏と宇田川雄貴氏による「コアネットワーク仮想化導入開始から10年。完全仮想化完了までの歩み。」が選ばれた。
NTTドコモのモバイル網のコアネットワークを支えるOpenStackインフラについて、設計と運用のギャップにより発生した運用の苦労を「運用苦労話（しくじり、トラシュー）」カテゴリーで語った発表だ。
講評では、国内有数の大規模でミッションクリティカルなOpenStackインフラについて、運用面でのしくじりや苦労話をリアルに紹介していた点が、Cloud Operator Days Tokyoならではの発表だとして評価された。
受賞コメントとしては、今回はAIなどの先進的な発表も並ぶ中で、地道なインフラ運用の内容が評価されたことに喜びが語られた。
審査員特別賞（挑戦編）
審査員特別賞（挑戦編）には、KDDI株式会社の木場仁美氏による「インフラ運用の「かゆいところ」と向き合う ― 作るLLMと任せるLLMの話」が選ばれた。
自社で使う大規模プライベートクラウドを運用する中で「かゆいところ」を解決するために用意している運用APIについて、AIを使って新機能開発という作る面と、AIに運用を支援させるという任せる面の両方が紹介された。
講評では、イベントのテーマ「AIとどう向き合うか」に合わせ、AIで誰でもプログラミングで課題を解決できるようになった現在、それを運用でも活用している現場のリアルな事例として評価された。
受賞コメントとしては、CODTは自分の身の丈にあった苦労話ができるぴったりのイベントであるとして、そこで受賞したことの喜びが語られた。
審査員特別賞（変革編）
審査員特別賞（変革編）には、株式会社デンソーの八神祥司氏による「AI駆動開発のラストワンマイル ― 非エンジニア研修と社内ハッカソンが残した運用課題」が選ばれた。
社内の研修やハッカソンで、AIを使って誰でもソフトウェアを作れるようにしたものの、ソフトウェアの数ができても本番運用までに壁があるという課題から、「人がルールを守るのではなく仕組みで守る」という考えで、セキュリティや認証などを備えたアプリ公開基盤を整備したことが紹介された。
講評としては、誰でも作れるようになった時代に、そのガバナンスとして、ルールをテクノロジーで変革している点が評価された。
受賞コメントとしては、「実は今回が初めての社外登壇でとても緊張したが、受賞してうれしい」と語られ、会場を驚かせた。
オーディエンス賞
オーディエンス賞には、PagerDuty株式会社の草間一人氏による「AIでシステム運用は楽になるのか？」が選ばれた。
システム運用をAIが支援するようになって運用が楽になるかという命題を否定し、障害対応だけでなくインシデント対応において適切なコミュニケーションが重要であることが、PagerDutyのプロダクトをからめて語られた。
講評としては、運用における豊富な経験を持ち、業界でも著名な立場から経験が語られたこと、そして、その内容を視聴者が知りたかっただろうことが再生数に反映されたのだろうとコメントされた。
受賞コメントとしては、あらためて「運用がAIで楽になるという考えは甘い」として、AIの支援は現在の運用のいいところも悪いところも増幅すると語られた。
実行委員会特別賞
実行委員会特別賞には、レッドハット株式会社の山下祐生氏による「生成AIとシステムの境界線を見極める」が選ばれた。
PoCで実行時の動作をAIに任せたのをプロダクションに持ち込んで失敗する例を紹介し、判断や改善を担う人間、定型タスクの得意なシステム、非定型タスクを高速にこなすAIという3者について、役割の境界線と、そのフェーズについて論じられた。
講評では、人とシステムとAIのどれに何を任せるかの境界を定めた考察と、そこにエンタープライズの知見が生かされていた点が評価された。
受賞コメントでは、人やシステムのこともできる点がAIの利便性でもあり難しさでもあり、それに対するプラクティスを紹介できたと語られた。
ヤングオペレーター賞
ヤングオペレーター賞には、楽天モバイルの若松奏汰氏、KDDI株式会社の笹谷晃斗氏と松本健太郎氏、株式会社サイバーエージェントの近藤智文氏が選ばれた。
若松氏は、新人が障害の一次対応の切り分けやレポート作成などについて、それぞれAIエージェントを作成して作業を経験したことを紹介した。
笹谷氏と松本氏は、新入社員のOJTにおける、事業に貢献しつつ安全に挑戦できるタスクとして、社内勉強用AWS環境の自動削除の仕組みの開発などに取り組んだことを紹介した。
近藤氏は、同社のプライベートクラウドの新リージョンで用いられた技術や手法について、多数のセッションで紹介した。
サーバーの外側が障害要因に？ AI時代のインフラ構築や運用の苦労話
基調講演「AIを支えるインフラ構築の現場から」では、プラナスソリューションズ株式会社の中村友昭氏が登壇した。
さくらインターネットグループでHPCを中心とするソリューションを提供する会社から見た、AI時代にインフラの構築や運用がどう変わってどう苦労しているかについて語られた。
講演は、「サーバーの価格は、どこまで変わったか」と「HPCクラスターとGPUクラスターを構築して経験したこと」の2パートから構成される。
「サーバーの価格は、どこまで変わったか」のパートでは、2019年と2026年のサーバーを比較し、価格も性能もまったく違っていることを示した。
1ラックあたりのサーバーの値段を見ると、2019年ごろの標準的な仮想化基盤では2000万円前後だったのが、2026年のGPUサーバー（GB200 NL72）では円安も重なって4.7億円と約22倍になった。購入単位もサーバーからラックに変わり、設備も電力も冷却もラックごとに設計する必要がある。
プラナスソリューションズで実際に構築して運用したGPUクラスターの推移を見ると、2019年のV100サーバーから2026年のB200サーバーで、価格は7.9倍になった。ただし性能は18倍になったため、性能あたりの価格は約56％減となった。とはいえ請求額は7.9倍なので、2019年の120台の金額で2026年には15台しか買えず、「予算は性能では割り切れない」と中村氏はこぼした。
サーバーの構成要素ごとに価格の変化を見ると、CPUはほぼ横ばいで、メモリが約3倍、GPUが約3～6倍というのは実感のとおり。さらに、SSDが1年で約6.5倍、ハードディスクも1年で約2.4倍となっており、「AIを使う人が、AIを使わない人の調達コストまで押し上げている」と中村氏は分析した。
「HPCクラスターとGPUクラスターを構築して経験したこと」のパートでは、最近のHPCクラスターやGPUクラスターならではの実際のトラブル事例が紹介された。
まずはイーサネットで物理リンクが上がらないトラブル。25GbE×4本でLAG（リンクアグリゲーション）を組んだところ、4本ともリンクが上がらなかったという事例だ。ケーブルや、ポート、LAGの設定、MTUを変えても解決しなかった。そして最後にFEC（前方誤り訂正）のモードを変更したところ、あっさりリンクが上がった。トランシーバーと機器のFECの設定が一致していなかったのが原因だった。25GbE以上ではFECが標準的に使われたことにより、設定が合っていないと物理リンクすら上がらないことがわかった事例だった。
次は、部屋の電力が足りないトラブル。HPCクラスターでもGPUクラスターでも、部屋の電力供給が足りないため、一時的に処理能力に制限がかかることが、ベンチマークでわかった。「一般的な業務システムでは発生しなかったので見落としていた。買った性能がそのまま出ず、部屋の電力が性能の上限になった。サイジングの段階から電力を逆算しておく必要があった」と中村氏は語った。
次も電力のトラブルで、GPUクラスターで分電盤のブレーカーが落ちる現象が、7週間で6回発生したというものだ。これは、接続ブレーカーを変更し、6個のPSU（電源ユニット）の電力消費に偏りがあるのでPSUを交換し、ブレーカーの冷却対策をし、最後には電源を増強することで解消した。「サーバー側は何も壊れておらず、建物側が問題だった」と中村氏はまとめた。
その次は、熱のトラブルで、熱だまりができたことによりDACケーブル（光と同じコネクターを使った銅ネットワークケーブル）の被膜が変形したというもの。原因は、高密度な配線が排気の通り道をふさいでいたことと、DACの束が厚くなることと、空きユニットなどに風の当たらない領域ができることだった。対策としては、配線の束をほぐし、空きユニットにブランクパネルを入れ、エアフローを見直した。「ケーブルは、通信の経路であると同時に、風の障害物でもある。配線設計をネットワークだけの問題として考えると見落とす」と中村氏は教訓を語った。
最後の事例は、GPUの動作不全の多さのトラブルだ。GPUはCPUより負荷や発熱が多くてよく壊れ、さらにGPUの動作がおかしいのにGPUの故障ではなかったことも多いという。そして学習ノードが複数ノードにまたがって動くため、1台の障害でクラスター全体が止まることになる。
こうした各トラブル事例をまとめると、10カ月で51件の障害のうち、サーバーの中だけではなく、分電盤やブレーカーといった建物側で12件起きていることから「GPUのクラスター障害というとGPUの話になりがちだが、実際にはサーバーの外側が4分の1を占めている」（中村氏）という。
また時系列で見ると、立ち上げの2カ月に全体の約半分が集中しており、「この2カ月を乗り切る体制を最初から組んでおく必要がある。納品して終わりではない」と中村氏は語った。
最後に中村氏は、かつての常識だったことが、今の現場では違ってきているとして、「カタログは現場の言い訳にはならない」とまとめた。
AIはインシデントの初動対応を助ける、では新人をその先のベテランに育てるには？
2つ目の基調講演「AIは新人をベテランに変えるのか ～インシデント対応最前線で見えた、人とAIエージェントの現在地～」では、PagerDuty株式会社の草間一人氏が登壇。運用において、AIが助けてくれる部分と助けてくれない部分について論じた。
まず草間氏は、「輝け！クラウドオペレーターアワード2026」のオーディエンス賞に選ばれたセッション「AIでシステム運用は楽になるのか？」の内容を引いて、「運用もAIに任せよう、という考えは甘い」と話した。
とはいえPagerDuty社では、「PagerDuty SREエージェント」など、運用を支援するAIエージェントをいろいろ出している。草間氏はSREエージェントの評価事例として、未知の事態に対する解決時間が、ベテランが平均8分、若手が平均20分のところ、新人＋SREエージェントでは平均9分だったという結果を紹介した。
では、AIエージェントがあれば新人でもベテラン並になれるのか。「もちろんそんな単純な話ではない」と草間氏は答えた。
論点は、実務面と個人の能力は分けて考えるということだ。「実務面で解決時間が短縮されたのは事実だが、新人がベテラン並の能力になったかというと、もちろんそんなことはない」と草間氏は言う。
草間氏は実務面におけるAIの恩恵を掘り下げ、インシデントの検知から解決、予防までのライフサイクルを取り上げた。これまでは初動対応から予防までの広い範囲でベテランが関わっていて、結局ベテランの負荷が高くなる。そこを初動対応において、若手や新人をAIが支援して対応できれば、ベテランの領域が右にシフトして、負荷を減らせるというわけだ。
さらに草間氏はベテランの能力を分解し、AIは探すことや実行はほぼ補完できるが、判断や決断はAIにはまだ難しいと分析した。
そしてゲーム「マインスイーパー」を例にとり、情報が足りずにロジカルには解けない領域があると説明。そこを、ビジネスの状況や、組織間の力学、過去の経緯などから判断して、さらに最後は「俺が責任を取るからこうしよう」と決断して決めるのは人間だと語った。これで100％解決できるかどうかわからないが、その判断の打率を上げるのが知識と経験というわけだ。
ではそうした知識や経験を新人が積むにはどうするか。ここでAIエージェントが補助装置になるのではないかと草間氏。新人は何もわからない、何がわからないかもわからない状態のため、結局何もできないことになる。そこで、AIエージェントが支援することで、何が起きているか、自分が何をすべきかがわかり、経験を積んでいけるという。
ただし、AIを使って解くことで学びが促進されるかどうかは、専門家の論文でも意見が分かれている。学ぶためには、AIの支援を受けて対応したあと、事後のポストインシデントレビューが大事だというのが草間氏の結論だ。
「障害内容と、それをAIがどこを調べてどう解決したかを自分たちが学んで、次のアクションに生かしていく取り組みをきちんとをやるのが大事だと思う」と草間氏はまとめ、そのためには新人や若手の学びのために、ポストインシデントレビューを重大インシデントのときだけでなくしきい値を下げて実施するのもよいのではないかと提案した。
AI時代の負荷に追いつくインフラを支えるLinux FoundationのOSS
3つ目の基調講演「Open Source for the AI Era: What We’re Learning from the Next Generation of AI Infrastructure」では、The Linux FoundationでOpenInfra FoundationとCloud Native Computing Foundation（CNCF）を率いるJonathan Bryce氏が登壇する予定だった。しかし、飛行機の欠航により出席が間に合わなかったため、同氏の資料を基にCODT2026実行委員長の長谷川章博氏（AXLBIT株式会社）が代理で講演した。
AI時代にシステムにかかる負荷に対して、いかにインフラが追いついていくかが語られた。
まず、GitHubがダウンしAIのコミットによる負荷が原因とされていることや、WikipediaなどWikimediaのコアトラフィックの65％がAIのクローラーによるものという数字を引き、AIのトラフィックによる高負荷が紹介された。
一方でオンラインバンクのKlarnaは、カスタマーサービスの3分の2をAIが処理しているという事例を紹介し、AI活用は止められないと語った。
AIワークロードのシフトもある。AIワークロードは、トレーニング（モデル作成）中心から、推論（モデル利用）の割合が中心になっている。トレーニングは負荷を計画できるが、推論は使いたいときに使うので負荷が読みにくい。さらにAIエージェントになると、絶え間なく負荷が発生する。
こうしたAI時代のシステムの変化として、GPUやNPUなどさまざまなAIアクセラレーター、推論のスケーラビリティ、エージェントの運用の3つが挙げられた。
こうした変化に対して、個々で対応しても追いつかないため、対応するソフトウェアをオープンソースのコミュニティで適切に育てていくことが求められているという。
Linux Foundation（OpenInfra FoundationやCNCF）では、こうしたAI時代のソフトウェアスタックの各レイヤで、OSSプロジェクトをホストしている。一番下のインフラのレイヤでは、OpenStackやKata Containersなどがある。その上のAIワークロードの運用では、Kubernetesなどがある。さらにAIワークロードの開発やサービングでは、PyTorchやvLLM、Rayなどがある。そしてAIエージェントの層では、MCP標準もLinux Foundation傘下にある。
「こうした複数レイヤでプロジェクトを回し、各レイヤにLinux Foundationにソリューションがある。これをうまく活用することが、AI時代に必要だ」（Bryce氏／長谷川氏）。
活用事例も紹介された。ベトナムの通信会社のViettelでは、AIインフラに必要な技術を自国や自社で賄うのは現実的ではないとして、KubernetesからPyTorch、Envoy AI Gatewayなど各レイヤのOSSを活用して構築しているという。
またAlibaba Cloudでは、同社の開発するAIモデルQwenを使った推論インフラの構築に、マルチクラスター管理のKarmada（Kubernetes Armada）を利用してスケールさせていると説明した。
ECのShopifyでは、質問に答えるAIエージェントを動かし、その解答の質を追跡して自動的に判断し、その結果を基にAIモデルをファインチューニングするといった自動サイクルを、vLLMやPyTorchで構築しているという。
最後にまとめとして、エージェントのスケールにインフラは追いつけるかという課題に対し、さまざまな困難がある中で、OSSを活用してヘテロジニアスな環境に対応できるスタックがLinux Foundationにはあるとあらためて紹介。そして、OSSは1社による独占ではなく、コミュニティに参加する各社が紡ぎあう民主的なプラットフォームであると、Bryce氏／長谷川氏はまとめた。
AIエージェントに仕事をさせる環境を整備するハーネスエンニアリングについて議論
パネルディスカッション「AIハーネスエンジニアリング最前線 ～生成AI時代のサービス開発・運用はここまで変わった～」も開かれた。
NTTコンピューティングテクノロジーセンタの水野伸太郎氏がモデレーターとなって、株式会社NTTドコモの三井力氏、株式会社ぐるなびの岩本俊明氏、株式会社タイミーの橋本和宏氏が、AIエージェントの企業利用とAIハーネスについて議論した。
1つ目のお題は「AIハーネスエンニアリングとは何か」。ハーネスエンジニアリングの「ハーネス」という言葉は、一般的な定義では、AIエージェントがモデルとハーネスで構成されている中において、モデル以外がハーネスとされる。ただし実際の使われ方としては、スキルやガードレールの整備など、指すものに幅がある。このお題では、その意味や実践内容について尋ねた。
これについて橋本氏はまず、モデルが進化して賢くなると、ハーネスで必要なことが少なくなっていくのではないかと指摘。そこで必要なこととして、モデル選択やコストなどの人間的な部分もハーネスに入るのではないかと語った。
岩本氏も、AIエージェントの出力が“AIスロップ”にならないように制御するものの意味で自社では使われていると紹介し、橋本氏の言うようにモデルの精度が上がると必要性が下がってくる可能性があると語った。
三井氏は、ハーネスは「AIが信頼できる仕事ができる環境を作ること」だと指摘。手戻りを少なくし、“AIガチャ”を抑制して、品質を含めた生産性を上げる取り組みだと語った。
では、そのハーネスを整備するハーネスエンジニアリングをどうするかという点については、AI駆動開発の現場で2回以上間違えたことをスキルでルール化するという話や、会社のセキュリティルールをスキル化して配る話、環境を整えるプラットフォームエンジニアがスキルも整備する話などが出た。
また、事務や営業などの部門の人もAIでソフトウェアを開発するようになったため、セキュリティや認証などの部分をハーネスとして用意しているという話もなされた。
2つ目のお題は「開発・運用スタイルはどう変わった？」。これについて橋本氏は「アウトプットとアウトカムのギャップを意識するようになった」と回答。AI開発によりコードやドキュメントの作られる量（アウトプット）は増えたが、それによる成果（アウトカム）との間にギャップがあると指摘した。
ちなみにその対策としては、AIの利用料が完全従量制になったことから、むやみにAIを動かすことに歯止めがかかったことも紹介された。
岩本氏もそれを受け、開発のスピードが上がっても事業に貢献しないとAI時代では生きていけないとして、実際に開発部門も事業部門に入るよう組織構造を変えたと紹介した。例えば、キャンペーンの案を考える会議に開発者も参加し、その場でサイトのプロトタイプを作って議論するといったことがなされているという。一方、例えば営業担当の作る資料もMarkdownにしてもらうことで、AIエージェントに与えやすくしたとのことだった。
三井氏は、AWSの提唱するAI-DLCワークフローを採用して、人間がレビューをしながらAIが開発する形をとっていると紹介。同じ品質のものを作るのに、以前より短い期間でできていると語った。ただし、AI-DLCを採用して最初のころは、逆に遅くなったり、品質に問題があるものができたりといった問題があったが、それをハーネス整備やフォーマット決め、情報共有などによってうまくいくようになったと紹介した。
3つ目のお題は「実際のツールセット」、つまりどのようなツールや環境を使っているかなどについてだ。
これについては、Claude CodeやCursor、Devin、Codexなどのコーディングエージェントの名前が挙げられた。また、複数のモデルを使って、1つのモデルで作ったものを別のモデルでレビューするクロスモデルレビューや、計画と実装を高性能モデルと安価なモデルで分ける方法を実施しているコスト最適化の話も出た。
そこから派生したのが、トークン管理、つまり利用量の管理の話だ。一律で制限して必要な人はWebで追加を申請できるようにする話や、ログやテレメトリー情報から各自の利用量を可視化するツールを開発した話なども出た。一方、無駄使いは避けたいが、気にしすぎるとエンジニアの生産性が下がるのが難しく、監視結果もあくまでチームビルディングの範囲で使っているという声もあった。
4つ目のお題は「失敗談・苦労話」だ。
橋本氏は苦労している点として、やはりトークン管理を挙げた。利用に制限をかけることで、モデルの使い分けや、サブエージェント、コンテキストウィンドウを意識するようになり、AIの出力の質に関する感度も上がったという。ただし、それを考えながら開発したいかということについては、悩むとのことだった。
岩本氏はまず前提として「AIに全部任せて大丈夫なわけない」として、人間側のハーネスのようなものがないと使えないし苦労しかないと説明。そのうえで苦労する話として、コードでも文章でも、AIだけで作って人が何もわかっていない状態のものはつらいと答えた。そして、エンジニアリングとして重要なのは経験やスキルだとしつつ、ただしそれは現時点でこの先変わってくるかもしれないと語った。
三井氏も、橋本氏と同様に、トークン管理などのために、コンテキストウィンドウなどを理解することが大事だと回答した。また、自社システムにフロンティアAIによる脆弱性検査を実施して脆弱性が発見され、その修正案に対して人間が受け身になってしまってレビューが足りず、動作上のバグを発生させてしまった失敗事例も紹介した。
最後に「明日から始めるAIハーネスエンジニアリング」として、一言ずつメッセージが語られた。
三井氏は、AWSのAI-DLCワークフローは、初心者向けにいろいろ提案してくれるので、そうした既存のワークフローで一度試してみるとよいのではないかと答えた。
岩本氏は、Claude Codeなどのコーディングエージェントを、まだ一度も使ったことがなければ、まずは遊びとしてでも一度触ってみると、先が見えるのではないかと答えた。
橋本氏はさらに、そうしたコーディングエージェントを使って、家庭などのちょっとした課題を解決するツールを作ってみて、継続的にメンテナンスするフルサイクルを体験してみるのがいいのではないかと答えた。
各自が使っているグッズや作業環境を紹介
少し変わったセッションとしては、「ワークハックセッション」として、自宅などの作業環境で各自が使っているグッズを紹介するパネルディスカッションも開かれた。前年からの2回目の開催だ。
レッドハット株式会社の山下祐生氏、AXLBIT株式会社の奥村優斗氏、GMOインターネット株式会社の竹本裕宣氏、株式会社デンソーの島津直道氏が、会場を交えて、最近買ってよかったガジェットや、自分のデスク環境、自作キーボード、生成AIツールなどについて話し合った。
