AIエージェントはこの流れを根本的に変える。最新のエージェントは自然言語の意図を受け取り、APIスキーマについてリーズニング（推論を含む）を行い、IaCを生成、検証した上で、ガードレールや承認フローを維持しながら、プロバイダーAPIを通じてクラウドに変更を直接適用できる。 その結果、複雑なインタラクションスタックは1つのインテリジェントな層に集約される。インタラクション層は依然として存在するが、エージェントがAPI仕様やプロバイダースキーマ、組織の制御を利用して、動的に構築するようになる。 現在のIaCの位置付けと将来像 IaCは現在、エンタープライズプラットフォームにおける「システムオブレコード」（SoR）であり続けている。以下を提供するからだ。 決定論的な望ましい状態モデル バージョン管理された変更履歴 レビュー可能な計画 ドリフト（逸脱）に対する調整メカニズム エージェントが支援する

The Production Incident Simulator for On-Call EngineersHands-on production incident simulations for SREs, DevOps engineers, and technical founders. Drop into a realistic terminal with a ticking clock and a system on fire. Run commands, find the root cause, and fix it before time runs out. No setup required.

SRE Kaigi 2026の発表資料です https://2026.srekaigi.net/#timetable?session-hall-1035

本記事では、2026年2月26日に開催されたオンラインイベント「技術選定を突き詰める Online Conference ――逆境を乗り越える意思決定プロセス」内のセッション「ソフトウェアアーキテクトのための意思決定術」の内容をお届けします。 同セッションでは、株式会社えにしテックの島田浩二さんより、設計や技術選定のような影響範囲の大きい意思決定をどのように扱うべきか。また、「絶対的な正解がない状況」において、何を根拠にどのように判断すべきかを整理し、最も現実的な意思決定を導くための具体的な指針をご紹介いただきました。 島田：島田浩二です、インターネットではsnoozer05というIDで活動しています。 普段は札幌を拠点に、株式会社えにしテックの代表をしています。個人としては技術書籍の執筆や翻訳に携わっていて、3月6日に『ソフトウェアアーキテクチャの基礎 第2版』が刊行になります。第1版以

先日、たまたま、Microsoft のキャンパスで大学生の皆さんと話す機会があって、こんなことを聞かれました。 私は大学生で１年ぐらい前からエンジニアになったのですが、世の中は AI の世界ですけど、どうやって学んでいけばよいのですか？AI コーディングとかやったほうが良いのですか？ たしか、こんな質問だったような私なりの回答をシェアしておきたいと思います。たまたま、最近、これからは、AI が来るまでに、実際にプログラミングをゴリゴリやってきた層、つまり、シニアエンジニア以上の天下という話もきいて、まぁそらそうだなぁと思う一方、個人的にはこれからやる人もやりようによっては全然ええ感じにしかも早くなれるのではと思っています。 コーディングエージェントとやった方がいいか？そらそうよ。もうごりごりにやった方が良いでしょう。だって、もう我々はそれでプログラミングをするのだから。でも、安心していいけ

JAWS DAYS 2026 でクラウドネイティブなソフトウェア設計についてお話した際の資料です。 イベントドリブンアーキテクチャなどについて語っています。 TAKT： https://github.com/nrslib/takt ユーザーコミュニティ： https://discord.gg/…

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 残業60時間でも年間200時間の学習を確保する技術【エンジニアの時間戦略】 はじめに 「勉強したいけど、時間がない...」 残業が続くと、つい口にしてしまうこの言葉。私も以前は同じでした。月60〜80時間の残業に追われ、帰宅すれば疲れ果てて寝るだけの日々。「時間がない」を言い訳に、1年間ほとんど成長しない自分に焦りを感じていました。 はじめまして、ハンズオンラボ運営メンバーのわたると申します。インフラエンジニア歴10年、監視オペレーターから始まり、運用・保守、そして設計・構築まで経験してきました。 この記事では、激務の中でも年間200時

来週、学生たちに向けて『AI時代に学ぶ意味』というテーマで講演を行う予定で、その要点をここにまとめておく。 AI時代に学ぶ意味 概ね、理由は以下のとおり。 良い質問をするために知識が必要 AIの出力を評価する 抽象的なアドバイスを活用する これらを実行するためには、一定の知識とスキルが必要である。 スキルを身につけるためには基礎知識があるうえで経験が必要であり、そのサイクルがまさに学びなのである。 そのため、AIが普及したとしても、人が学ぶことの重要性は変わらない。 その前提を踏まえたうえで、各ポイントについて説明する。 良い質問をするために知識が必要 AIに質問する際には、質問の意味を理解している必要がある。 そして質問するにはまず、自分の無知の状態を認識しなければならない。 無知には5段階のレベルがあって、自分がどの状態にあるのか理解する必要がある。 これをFive Orders of

あけましておめでとうございます！本年もよろしくお願いします！ 正月に書く2026年1発目の記事は「Gemini」×「NotebookLM」で出来るDX（業務フロー改善）！つまりAIでの業務フロー改善についてです。 AIの登場で生産性向上が叫ばれる中、業務フロー改善はより重要になってきていると思います。 なぜGeminiとNotebookLMでやるのが良いと思ったかでいうと、それぞれの得意領域である 1.NotebookLMで情報の要約、抽出を正確かつ高速に行う。 2.Geminiでその情報から、新たな創作をおこなう。 を組み合わせることで、点在するさまざまな業務フロー改善の「タネ」から自動で最適な業務フロー改善の提案をAIにさせることができるのでは？と思ったためです。 それでは、架空のWebサイト制作の業務フローをベースに、やり方を詳しく解説していきます！ 1.NotebookLMに業務フ

はじめに RecustomerでエンジニアをしているRyoheiです。 私は今年の4月に新卒として入社し、それから2週間に1冊のペースで技術書を読んできました。 最初は弊社CTOとの日常会話からこの試みをはじめ、12月まで走り切りました。 ただ、最初の頃は技術書なんてまともに読んだことがなく、正直かなり苦戦していました。 読み終えること自体が難しい 分厚い本は手に取る気にもならない 「覚えよう」「メモしよう」と意気込むと時間がかかりすぎる 読んだ気がするけど、しばらくするとどこで読んだかも思い出せない 同じような悩みを持っている方も多いのではないでしょうか。 この記事では、私が今年学んだ技術書との向き合い方を3つ紹介します。 1. 脳にインデックスを貼る CTOに「技術書ってどう読めばいいですか？」と相談したとき、返ってきた答えがこれでした。 「脳にインデックスを貼るんだよ」 例えばEff

この記事は hacomono Advent Calendar 2025 の12日目の記事です。 基盤本部で今後のhacomonoのアーキテクチャ設計をしている @bootjp と申します。 今年はマイクロサービス化に向けての社内共通のイベントバスの設計や基盤周りの設計/実装を行っていました。 以前にはこのような記事を書き、分散システムや分散データベース、分散ストレージなどが大好きです。 「Goで作って理解するRaftベースRedis互換KVS」という同人誌も書いています。 もし興味のある方はお手にとってみてください。 はじめに 今回は「クラウドネイティブデータベース」と言われる、昨今のデータベースにおけるコンピューティングとストレージの分離について、どのような動機でこの構成になったのか、利用者としてどのようなメリットがあるのか、そしてトレードオフは何かということについて記事を書かせていただ

※ 本記事は一部 AI を用いて執筆しております。 内容に関しましては基本的に筆者が慎重にレビューや動作確認、ファクトチェックを行なっておりますが、万が一問題と思われる点ございましたら、コメント欄にてご指摘くださいませ。 1. イントロダクション：なぜ今更、自前で環境を構築するのか 1.1 プライベートクラウド回帰の潮流とセキュリティの課題 1.2 本記事の目的 2. アーキテクチャ設計論：防御と可用性の融合 2.1 全体像 環境 2.2 コンポーネント選定の技術的根拠 Proxmox VE：インフラの基盤 Keepalived：シンプルかつ堅牢なHA HAProxy：高性能ロードバランサ Suricata：マルチスレッドIPS 3. インフラストラクチャ構築 3.0 物理サーバー確保 3.1 Proxmoxネットワーク構成 3.1.1 Linux Bridgeの確認・設定 3.2 VMの

Rails Tokyo Meetup 02 登壇資料。

こんにちは。Backend Enablement Team のエンジニアの @goccy です。 この記事は、Merpay & Mercoin Advent Calendar 2025 の7日目の記事です。 時は今から4ヶ月ほど前の8月下旬、とても暑い日でした。珍しくチームの On Caller の PagerDuty がアラートを上げました。内容は Gateway からあるマイクロサービスへの呼び出しが突然 Timeout するようになり、gRPC の Deadline Exceeded が急増しているというものでした。対象のマイクロサービスは gRPC Federation を利用した BFF ( Backend for Frontend ) で、基本的にはさらに後ろのマイクロサービスにプロキシするだけの単純なサービスです。少し調査すると、該当の gRPC メソッドには Timeout

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? （Linux）大規模基盤のLinux運用で得た知見まとめ （障害対応／テンプレ化／OS更改） はじめに 私はフリーランスインフラエンジニアとして 10年以上、大規模Linux基盤の構築・運用・保守 に携わってきました。 RHEL / CentOS(RedHat系ディストリビューション)を中心に、 OS更改（RHEL6→7→8） テンプレート化・標準化（KVM/VMware） 障害対応（切り分け〜再発防止） 運用改善・自動化 といった領域を一貫して担当してきました。 長く現場を経験する中で強く感じたのは： （あくまで個人的に感じたことです

要約 時限爆弾的なテストとは、テスト内で扱う日時（レコードのregistered_atなどの属性値やスタブの値）にハードコードされた日時文字列（ '2024-07-15' など）を使うことで、時間経過により失敗するようになるテストのこと。 基本原則: ❌ '2024-07-15' のようなハードコードされた日時文字列を書かない（エッジケース除く） ✅ 通常のテスト: Time.current、1.week.ago など テスト実行時を基準とした相対日時 を使う ✅ 日時依存ロジック: travel_to で テスト実行時の「今日」を特定の日付に固定 し、テストデータの日時もTime.zone.parseで 具体的な日時を指定 する ✅ エッジケース（閏年・年跨ぎ・月末）: travel_toを使い、境界条件を示す具体的な日時 を指定する よくある例: # ❌ Bad - 時間が経つと壊れる

YAPC::Fukuoka 2025 ゲストトーク

A method for separating policy definition and behavior control by an intermediate language to achieve optimal server configuration management according to the situation

こんにちは、ログラスの松岡(@little_hand_s)です 3行まとめ AIに質問させるときに選択肢を提示させると、回答が楽で早くなる さらに、推奨度とその理由を出力させると、その根拠を元にAIと議論できるし、納得感を持って進められる 結果、意思決定が速くなり、質も上がる AIと対話しながら開発してますか？ Claude CodeやCursorなどのAI開発ツールを使ってる人、増えてますよね。 AIが暴走しないように、不明な点を質問させてる人も多いと思います。 でも、毎回自然言語で答えるの、面倒じゃないですか？ たとえば： AI: 「バリデーション、フロントエンドとバックエンドどっちでやりますか？」 あなた: 「うーん、両方かな。セキュリティ的にバックエンドは必須で、UX的にフロントエンドも欲しいし...」（と、入力すると長い） もしどちらでバリデーションするかを決めていなかった場合、

#WIP レガシーシステムを再構築しようとしても、期待していた開発スピードや品質の向上が得られないのはなぜか? そこに潜むアンチパターンを書き出してみます。 画面駆動設計 画面を切り口にアプリケーションの設計を考える。これ単体ではアンチパターンではない。 コンテキスト 現行システムの画面操作に慣れたユーザが多い 問題 同じ扱いをすべきデータが複数の画面に分散していても、それに気づきにくい 表示条件に見えるものが実はビジネスルールの制約である 項目間の関係性や構造が見えにくい テーブル駆動設計 データベースのテーブルを切り口にアプリケーションの設計を考える。これ単体ではアンチパターンではない。 コンテキスト 現行システムのデータベーススキーマが既に存在し、それを前提とした開発が求められる