物流企業DSVがKubernetes環境の拡大に伴い、federated Prometheus構成のメモリ・CPU限界とアラート信頼性・運用負荷の課題に直面し、VictoriaMetricsへ移行した事例。vminsert/vmselect/vmstorageの最適化とHA構成、vmagentのストリーミング取り込みにより、約80万datapoints/秒の取り込みと約7200万のアクティブ時系列を安定運用できるようになった。
GitLab CI/CDの解説書。パイプライン設定の基礎から、サンプルのJavaアプリケーションを題材にしたビルド・テスト・パッケージングの自動化、マージリクエストを使ったレビュー環境や本番環境への継続的デリバリーまでを実践的に解説する書籍の紹介。
HashiCorpがValidated Designs (HVD)を刷新。従来の成熟度モデルではなく「Installation」「Administration」「User」の3ガイドに再編し、developer.hashicorp.comのナビゲーションから直接アクセス可能に。サイト内検索やGoogle等の外部検索エンジンでもインデックスされるようになり、製品ドキュメントからのリンクも改善され、目的の情報に到達しやすくなった。
30人規模スタートアップがGitHub Enterpriseを新規契約し、Base permissionsをNo permissionに変更してTeamベースの最小権限アクセス管理へ移行した実践記録。Team↔リポジトリ割り当て、All Employees Teamでの全社共通リポジトリ管理、業務委託メンバーのOrganization Member/Outside Collaborator使い分け、CI/BotなどNHIの棚卸し、会社ドメインアカウントへの統一と2FA必須化、Owner権限の最小人数運用、gh CLIを使った権限棚卸しコマンド例、切り替え手順とロールバック手順までを網羅している。
Microsoft は AKS の Node Auto-Provisioning (NAP) について、ノード disruption を予測可能にするための新ガイダンスを公開した。アプリ層の Pod Disruption Budget とインフラ層の NAP disruption 制御（consolidation policy・disruption budget・node expiration・drift management）を併用することを推奨し、過度に厳格な PDB（maxUnavailable: 0 等）が consolidation やアップグレードを止めてしまう問題を指摘。voluntary disruption と involuntary disruption（ハードウェア障害や Spot VM eviction）の違いも整理し、Kubernetes 全体の自動ノードプロビジョニングの流れの中で「安全なオートスケーリング」の設計が今後の課題になると論じている。
AWS DevOps AgentのDirected Actions（エージェントアクション）機能を検証した記事。アクションロール登録とエージェントアクション有効化の2ステップで設定し、ロール権限は「天井」に過ぎず実行時はセッションポリシーとオペレーター承認により操作範囲が絞られる仕組みを解説。サポート対象外の`authorize_security_group_ingress`はブロックされたが、NAT Gatewayのルート修正シナリオでは承認フローを経て緩和計画の実行完了まで確認できた。
複数サーバを行き来する環境で本番とローカルを誤認する事故を防ぐための対策集。プロンプトへの色付け、サーバごとのメモ記録、apt-mark showmanualやapt履歴での導入済みパッケージ調査、SSH config整理、rm前のfind確認やバックアップ・構文チェックなど、現在地の可視化と危険操作の防護を具体的な手順で紹介している。
AWS DevOps AgentにDirected actions（エージェントアクション）機能が追加され、読み取り専用だったエージェントがリソース変更を実行できるようになった。有効化にはエージェントスペースでのトグルON、アカウントごとのIAMアクションロール登録、操作ごとの承認という3層のオプトインが必要。IAMロールで許可されていても、リソース削除・パーミッションバウンダリー変更・iam:PassRoleを伴う操作はエージェント側のガードレールで拒否される仕組み。筆者は実際にLambda関数へのタグ付けを依頼し、承認パネルで実際のAPI呼び出し内容やリスク評価（影響範囲・可逆性）を確認した上でApproveし、正常に実行されることを確認した。
NeMo Switchyard によるLLMリクエストの自動ルーティングで、事後学習済みjudgeモデルをタスク難易度判定役に採用した事例。素のLightningモデルを判定役にした際は依頼文の切り捨てや判定語彙の欠如、フォールバック設計の甘さから92.4%がstrongモデルに流れる偏りが発生。Capability Cardとp_solve確率に基づく専用judgeへ切り替え、pip版Switchyardとのスキーマ差異を吸収するshimを実装した結果、weak/strongの配分がほぼ均等（62.2%/37.8%）に改善した。vLLMのメモリ設定、NemoHermesとの接続、sandboxの設定変更に伴うクラッシュループなど多数の実装上のハマりどころも詳述している。
本番DB障害調査を「探索SQL→原因特定→修正SQL」の反復ループとしてAIエージェントに任せる方法論。probe/fix/impact/timelineの4種類にクエリを役割分担し、probeは読み取り専用で多段に重ねて仮説検証する。fix/restoreの実行は必ず人間が承認する境界を設け、破壊的操作には影響行数カウントやトランザクション巻き戻しを組み込む。調査の再現性・影響見積もりの精度・スループットの向上が得られる一方、本番でSELECT以外を自動実行させない安全設計を最重要事項として強調している。
環境変数は本来デプロイ環境ごとに値が異なるもの（DB接続先や認証情報など）に限定すべきで、環境間で変わらないAPIパスやパラメータなどはコードに書くべきだと主張する記事。何でも環境変数にすると変更漏れによる障害リスクが増えるほか、AIエージェントが機微情報保護のため.envを読めない設計になっている現状とも相性が悪いと指摘している。
ガートナーの横山龍児氏は、企業のソフトウェア開発内製化戦略について講演。内製化のゴールは単にソースコードを保有することではなく、ビジネスの変化にシンクロして進化し続ける組織への変革だと指摘。内製化には「人材」「知見」「スキル」の3つの壁があり、特に現行アーキテクチャの妥当性を判断する「決める力」の欠如が日本企業最大の弱点とした。対策としてスキルマップによる現状把握や、業務知識を持つドメインエキスパートを開発の担い手として活用する発想転換を提案している。
SaaS型アプリケーション開発のためのベストプラクティス集「The Twelve-Factor App」。コードベース管理、依存関係の明示、環境変数による設定、バッキングサービスの疎結合化、ビルド/リリース/実行の分離、ステートレスなプロセス実行、ポートバインディング、並行性によるスケール、高速起動と安全な終了、開発と本番の一致、ログのイベントストリーム化、管理タスクの一回限りプロセス化という12の原則を解説している。
OOPカンファレンスでJochen Joswig氏が持続可能なテスト戦略を提案。不要なテストを排除し、fail-fastで早期に停止、モノレポではコード変更箇所に関連するテストのみ実行することを推奨。テストごとのエネルギー消費量を計測しオブザーバビリティに組み込む方法や、SonarQubeプラグインCreedengoなど静的解析ツールでのコード非効率検出も紹介。開発ライフサイクル初期に低忠実度プロトタイプでテストし無駄な機能開発を避けることや、古いハードウェアのサポート継続によるデバイス寿命延長にも言及している。
Lambda MicroVMs上にGitHub Actionsのセルフホステッドランナーを構築するCDK構成（cdk-github-microvm-runners）を検証した記事。GitHub App連携からワークフロー実行までの手順を紹介し、ジョブ実行までの待ち時間が約25秒、Docker利用も可能なことを確認。料金面ではGitHub-hosted runnersの方が単純比較で安いが秒単位課金がメリットで、MicroVMの一時停止・再開機能を活用すればステート保持による処理時間短縮も見込めると考察している。
DeNAのIT戦略部会計システムチームに配属されたAI社員Berryが、配属3か月間の実務事例を紹介。問い合わせのチケット化、エラーメール監視からの自動起票、J-SOX内部統制の証憑取得（約30%を担当）、カレンダー突合による日程調整などを担い、ある週には約41.9時間分の作業時間を削減。今後は指示待ちから自律的に業務を提案・巻き取る同僚へと進化を目指すとしている。
HashiCorp Cloud Platform（HCP）がSCIMプロビジョニングに対応し、Entra ID・Okta等のIdPからユーザー/グループのライフサイクル管理を自動同期できるようになった。手動管理を排除し、アクセス権限をIdP側の状態と一致させることでセキュリティとコンプライアンスを向上させる。
AWSアクセスキーは有効期限がなく漏洩時の被害が大きいため、開発者はaws login、AWSリソースはIAMロール、CI/CDはOIDC、外部サーバーはIAM Roles Anywhereといった一時クレデンシャルへの移行を提案。移行できない場合の対策として、gitleaksやPush Protectionによる予防、最小権限やローテーションによる防御、GuardDutyによる検知という3段構えの防御策と、漏洩時は即座に無効化すべきことを解説している。
Kubernetes環境における監視とオブザーバビリティの違いを整理し、メトリクス・ログ・トレースの3要素、データ肥大化やコスト増などの課題、Prometheus/Grafana/Loki/Jaeger等の代表的OSSソリューションを紹介。導入初期はPrometheus Operatorから始め、必要に応じて機能を拡張することを推奨している。
Kubernetes 1.37 のセキュリティ関連変更19件を解説する記事。SELinuxMount のStable昇格やnftables既定化などの破壊的変更、gRPCプローブTLS対応・Pod単位のcheckpoint/restore・volumeマウントへのnoexec等のオプション追加といった新機能、kubelet rootless化やAPIサーバーのwebhook認証既定有効化などデフォルトで有効になるセキュリティ機能、ClusterTrustBundleやPod証明書のStable昇格までを網羅している。
DatadogがAIコスト管理の実践例を公開。AIコストをベンダー・モデル・チーム単位で可視化するダッシュボードを構築し、Claude CodeのデフォルトモデルをOpusからSonnetへ移行（性能低下8%でコスト36.7%削減、月$687,000節約）、実行effortを高から中へ変更（月$288,000節約）。さらに高額利用者への自動アラート通知（週$150,000節約）と、Headroomによるコンテキスト最適化（トークン使用量を大幅削減しコスト27%減）を組み合わせ、月合計100万ドル超のAI利用コストを削減した。
Percona Server for MongoDBがバージョン7.0.39-21、8.0.28-12、8.3.7-1以降でSBOM（CycloneDX形式）とVEXドキュメントを提供開始。SBOMをGrypeやOWASP Dependency Trackでスキャンすると多数の脆弱性が検出されるが、Go実装限定の脆弱性やビルド時無効化された機能、独自パッチ適用済みコードなど誤検知が多く含まれる。PerconaはVEXドキュメントを公式提供し誤検知を除外可能にした。ランタイムでリンクされる共有ライブラリ（libc, OpenSSL等）は別途SBOMスキャンが必要と注意喚起している。
キャディの小林明斗氏がクラウドネイティブ会議で、生成AIによるコード生成量増加で人手レビューが限界を迎える中、Production Readiness ChecklistをPolicy as Code化した取り組みを紹介。ConftestとRegoでTerraform、KyvernoでKubernetesを検証し、Google Cloud Organization Policyで実環境も統制する多層防御を構築。既存負債の1684件の違反を警告→トリアージ→段階的強制→エラーブロックの順で移行し、レビュー負荷削減とSREへの信頼構築を実現した。
MinIOは2026年2月にアップストリームでアーカイブされ、新規リリースやセキュリティパッチの提供が終了した。Docker HardenedイメージのExtended Lifecycle Support（ELS）は、MinIOを含むEOLソフトウェアを最大5年間ビルド・パッチ提供し、SBOMやVEX、SLSA Build Level 3のプロビナンスなど監査証跡を維持することで、移行を急がせず監査対応を可能にする有償アドオン。
Herokuが全顧客向けにFine-Grained Access Control（FGAC）を提供開始。従来の固定ロール（admin/member/collaborator）に代わり、デプロイ・スケーリング・ログ閲覧・設定変更・課金管理などの権限を組織/チーム/アプリ単位で個別に付与できる。ダッシュボード・CLI・Platform API経由で管理可能で、既存の権限は自動移行されるため既存ユーザーの操作は変わらない。
KubernetesのポリシーエンジンKyvernoについて、Namespace作成をトリガーにResourceQuota等を自動生成・自動復元する仕組みと、導入時に最も失敗しやすい「Audit→Enforce」の段階的移行手順を整理した記事。Audit状態で違反を記録しつつ開発を止めずに始め、PolicyReportで違反状況を把握してから徐々にEnforceへ昇格し、例外はPolicyExceptionとして期限付きでGit管理する流れを紹介。CIへのシフトレフトやPolicyReportを監査証跡として活用する視点にも触れている。