2026-05-30の技術動向：AIへの不信感とインフラの自動化

Why Linux creator Linus Torvalds gets angry hearing “99% of code is AI”

コンパイラが吐き出す機械語に対して、「100%コンパイラが書いている」と誰も文句を言わないのになぜAIだけが問題なのか。私もGitHub CopilotやClaudeを業務で使いまくっているが、生成されたコードをそのまま提出するわけにはいかない。バグ混入リスクや、意図しない挙動を把握するためには、やはり人間が深く理解してレビューしないといけない。これはアセンブリ言語からC言語、GoやTypeScriptに移行した時と同じ流れだ。

「システムの複雑さを理解していない人が、AIに指示を出すと失敗する」という指摘も鋭い。私のKubernetes環境やTerraformのインフラコードを書く際も、AIに頼りきりはできない。ツールは効率を上げてくれるが、それをコントロールする知識がないと、バグだらけのシステムが出来上がるだけだ。AIが見つけたバグの修正PRが大量に来ることや、企業が「見つけたけど直さない」ネタでPRを送ってくるのも、マーケティングにしか見えない。ツールの恩恵を享受しつつ、その負荷をどう減らすかが、これからの課題になりそうだ。

Vendor neutrality isn’t magic: A hard look at the OpenTelemetry ecosystem

記事を読むと、OTelはあくまでデータ形式や転送メカニズムの標準であって、それだけで完結するわけではないと指摘されています。以前は各ベンダーが独自のSDKを押し付けられ、ツール間の移行が難しい「ロックイン」状態だったのが、OTelによって標準化されました。

マイクロサービス時代の分散トレースとして生まれたこの標準は、GoやPythonなどの言語間でコンテキストをやり取りする際に役立っています。でも、データフォーマットが標準化されても、パイプライン全体の設計をどうするかは自分で決める必要があります。

独自のSDKに縛られないのは大きなメリットですが、「中立だから簡単」とは限らない。自分のワークフローの中で、どこまでが標準で、どこからがエコシステムの依存なのかをちゃんと見極める必要がありそうです。

The fix for soaring AI cloud bills exists — so why won’t we trust it?

CloudBoltのレポートによると、GPU重いワークロードのせいで、89%の組織がKubernetesのリソース最適化（right-sizing）を優先事項に上げている。でも、現場のエンジニアの反応は違うらしい。71%が人間によるレビューを求めているし、CPUやメモリの自動変更を許可しているのはたったの27%だ。

この信頼のギャップ、すごく分かる。自分の仕事でも、CI/CDでコードをデプロイする分には自動化にガンガン信頼を置くけど、リソースの調整を機械に任せるとなると躊躇する。なぜかというと、もし機械が間違ってリソースを削りすぎて、AIの学習ジョブが止まったら困るからだ。

「一度の生産インシデントで、信頼は一瞬で崩れる」という言葉が印象的だった。自分のチームだと、もし自動化ツールがミスってPodを殺したら、絶対に「自分のアプリには絶対にやらせない」ってなるだろうな。やっぱり、自動化への信頼構築は簡単じゃない。

AI is shipping code faster than security was built to handle

個人的にはかなり興味深い。

従来のペンテストだと年間15日しかカバーできなくて、実質350日間、攻撃者がアプリをいじり放題になっているらしい。このギャップ、業務でKubernetes管理してると痛感する部分だ。

なぜ今かというと、AIがコードを書く速度がセキュリティのレビュー速度を圧倒しているからだ。生成AIエージェントがコードを書く一方で、セキュリティチームは追いつけない状況が続いている。

Evo COSは、従来のSASTやDASTの結果をAIが読み込んで、文脈を理解して攻撃をシミュレーションする。これまでスキャナでは見つからなかった「論理的なバグ」や「権限昇格」をAIが見つけ出すっていう。

しかもAI特有の攻撃（プロンプトインジェクションとか）まで考慮してくれるらしい。

これからは単に脆弱性を列挙するだけでなく、「攻撃の連鎖」を可視化する必要がある。自分のワークフローにも取り入れてみたい。

AI-Assisted Migration Tool Helps Teams Move from ingress-nginx to Higress in Minutes

Cloud Native Computing Foundation（CNCF）が注目している話題がある。ingress-nginxからHigressへの移行を、AIアシストツールが30分で完了させたという実験結果だ。

60個のリソースを移行。通常なら数日かかる手作業を、AIが自動変換と検証を担当したらしい。このスピード感は、Kubernetesのゲートウェイインフラを現代化する際の障壁が、実は「設定の書き方」そのものにあることを示している。

私は普段、Kubernetes環境でingress-nginxを使っている。安定はしているが、設定ファイルが肥大化し、アプリの挙動と絡み合うとメンテナンスが地獄になる。ネットワークルール、トラフィックポリシー、認証レイヤーが深く結びついてしまい、少しの変更でルーティングがおかしくなるリスクがある。

この記事で紹介されたのは、EnvoyをベースにしたAPIゲートウェイ「Higress」。AIツールが既存のIngress定義を読み取り、Higress向けのマニフェストを生成してくれる仕組みだ。検証と微調整だけを人間が行うことで、移行の複雑性と運用リスクを下げている。

具体的には、OpenClawのようなツールを使って、Ingressリソース、アノテーション、ルーティング設定、ポリシー定義を自動的に変換する。これは「翻訳」の問題に近い。AIがインフラの意図を解釈し、互換性をマッピングして定義を生成してくれるのだ。

私のワークフローだと、TerraformやCI/CDパイプラインを書いているが、移行作業のたびにYAMLを書き直すのは精神的に消耗する。AIが翻訳してくれるなら、人間はそこで何をすべきか考える時間が増える。インフラエコシステム全体で、AIアシストツールが定義の生成、インフラの発見、移行ツールを取り込む動きは加速している。

ただし、セキュリティポリシーやトラフィック管理の細かい調整は人間の目が必要だ。AIは素早く変換するが、エッジケースを網羅するのはまだ難しいかもしれない。30分で移行できるのは「変換」の部分だろう。その後の検証フェーズで、私たちが責任を持って確認する必要がある。

参照記事

記録日: 2026-05-30