Devinによって変化したエンジニアリングの現場
はじめに 本記事では、Devinがdelyの開発現場にもたらした変化を実例を元に紹介します。 Devin 導入の背景 AI 活用で dely 全体の生産性を底上げしたい 人がやること／AI に任せることを切り分け、ムダな工数を削減 Devin で解決したかった課題 権限変更リクエスト急増によるエンジニア工数の肥大 ドキュメント陳腐化で最新情報が追いづらい 機能仕様の質問がエンジニアに集中しボトルネック化 以降のセクションで、Devin がこれらの課題をどう解決したかを説明していきます。 1. 非エンジニアからの依頼対応の工数削減 delyではTerraformを用いてGitHub、AWS、GCPの権限管理をIaC（Infrastructure as Code）として運用しています。従来、権限変更のリクエストはエンジニアがPRを作成して都度対応していました。しかし、非エンジニアからのリクエス
構成図 as Code - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 内容 draw.ioを使用してネットワーク構成図を書いていますが、構成管理が結構手間になります。IaCを導入して、gitベースでインフラの構成管理が出来ても構成図だけは手動で管理となってしまうため、IaCの様に構成図もコードで管理出来ればと思っています。今回は特別何かのツールを入れるわけではなく、drow.ioにインポート用のXMLファイルを作成するプログラムを作成します。構成変更が発生した際はプログラム修正を行うと、新しいXMLファイルが作成されるため、こちらをインポートすることで構成図に反映する流れとなります。 構成 オンプレミスで
Devin的な自律型開発エージェントをAWS上に作ってみた！ - maybe daily dev notes
協働的AIチームメイトを謳うソフトウェア開発エージェント、Devin が注目を集めています。日本コミュニティでの勉強会は参加者が1000人を超えるほどです(！) 今回はDevin的な動きを実現するセルフホスト型のソリューションを開発してみたので、その紹介です。 TL;DR; こちら↓にソースコード (IaC + Agent + Bolt app) を公開しています。 github.com 主な機能は以下です: クラウド上で並列して動作できるソフトウェア開発エージェント サーバーレス構成のため、料金の前払いは不要で固定費もほぼゼロ MCPサーバーとの統合が可能 プロンプトキャッシュやコンテキスト長制御によるコスト効率化 OSSのレポジトリもフォークして開発可能 .clinerules や CLAUDE.md などからリポジトリ固有の知識を自動読み込み AWSアカウントとGitHubアカウント
こんにちは。TIGの伊藤です。 Terraform連載2025の6日目の記事です。 2025年始から、社員の有志でTerraform設計ガイドラインを編集し、先日公開したので公開までの経緯などについて触れていきます。 公開までの経緯Future Enterprise Arch Guidelinesとして、これまでにもWebAPI設計ガイドライン、Slack利用ガイドラインなどを公開してきましたが、これらは社内に知見が溜まってきていることをきっかけに、ガイドラインとして整理して公開しています。 Terraformについても、社内の複数プロジェクトで利用されており、それぞれで工夫したこと、ケアしたポイントなどが知見として出てきていることから、社員がリファレンスとすることも含めて編集、公開することになりました。 チームにおけるガイドラインを設けることの難しさ各プロジェクト、チームでは一定のコーデ
SAFe(Scaled Agile Framework)が、再び「採用を控えるべき技術」に選定される - arclamp
日本でもSAFe™（Scaled Agile Framework®）は、大企業がアジャイル導入を進める際に使われるフレームワークとして知られています。しかし、有名コンサル企業Thoughtworksは2021年と2025年の2回に渡り、SAFeを「Hold（採用を控えるべき）」として評価しました。 ThoughtworksとTechnology Radarについて Thoughtworksは、テクノロジーを活用した組織変革やアジャイル開発の分野でグローバルに活躍するコンサルティング企業です。マーチン・ファウラーが所属し、CI（継続的インテグレーション）、IaC（Infrastructure as Code）、マイクロサービスなど、様々な技術トレンドを名付けたり、紹介したりしています。 Technology Radarは、彼らが年に2回発行しているレポートで、様々な技術についての評価がされま
こんにちは。SEQ (Software Engineering in Quality)のzakiです。 これまで、freeeのE2Eテストは、Selenium、RSpec、Capybara、およびSitePrismを基盤とするRubyのテストを、Jenkinsを用いて実行していました。この構成にはいくつか課題があったため、現在は PlaywrightをベースにしたTypeScriptのテストを、GitHub Actionsで実行する新構成への移行を進めています。今回はその内、JenkinsからGitHub Actionsへの実行基盤の移行について紹介します。 従来のE2E実行基盤の構成とその課題 現在のE2E実行基盤図 (Jenkins) これまでのE2E実行基盤はEC2上にJenkinsを構築し、その中でE2Eテストを実行していました。しかし、この構成には以下の課題がありました。 テスト
AWS、AIエージェントとの統合を支援する9つのMCPサーバを「AWS MCP Servers」として公開 オープンソースで提供開始
Amazon Web Services（AWS）は2025年4月1日（米国時間、以下同）、AI（人工知能）エージェント（MCPクライアント）との統合を支援する9つのMCP（Model Context Protocol）サーバを「AWS MCP Servers」としてオープンソースで公開した。 AWS MCP Serversは、複数のMCPサーバで構築されており、互いに連携してAWSに関する包括的な知識や機能をAIエージェントに提供する。 AWSは、AWS MCP Serversで公開されている各種MCPサーバの利用方法やユースケースを開発者向けに解説するブログエントリを同日公開した。 「AWSの経験が豊富な開発者でも、クラウド初心者でも、AIコーディングアシスタントを活用することで、複雑なサービス構成、Infrastructure as Code（IaC）の実装、ナレッジベース統合といった
Amazon RDSの監査ログを保全する信頼性の高いソフトウェアの設計と実装について - Pepabo Tech Portal
はじめに 背景 信頼性 監査プロセス コスト 要件 機能要件 非機能要件 設計 システムの構成要素 なぜECSを選んだのか 監査ログ保全における適切なリソース管理 私達のユースケースに合わせたオブジェクトキー 実装と検証を繰り返しフィードバックループをまわす ログが途中で途切れる 並行運用 転送量のコスト増加 ECS Fargateのキャパシティ不足 ログの整合性をチェック ログローテーションサイズの変更 オンコールドキュメントを作成 成果 Future Works まとめ harukin drumato はじめに こんにちは。技術部技術基盤グループのharukin,drumatoです。 カラーミーでは従来Data Firehose（旧Kinesis Data Firehose）を用いて、Amazon RDSの監査ログをS3に保存する仕組みを運用していました。 しかし、運用していく中で継続
Development Division/Platform Team/Sys-Infra Unit では、よりセキュアな状態を維持できるように様々なことに取り組んでいます。 背景 Repro ではメインとなる AWS アカウントに以下の環境で利用するリソースを全て作成していました。1 production 所謂本番環境 staging 本番リリース前に QA を行うための環境 dev_staging 開発者の動作確認用 test アプリケーションの CI で利用する internal 内部利用のためのウェブアプリケーション AWS Well-Architected Tool を使って既存環境をチェックしたところ、まずは AWS アカウントを分離し、各環境のワークロードを分離した方がよいとの結果でした。 SEC01-BP01 アカウントを使用してワークロードを分ける: - AWS Well-
こんにちは、アルダグラムでSREを担当している okenak です。 今回は、2024年末に実施した KANNA の AWS インフラ基盤の全面リプレースについてご紹介します。 このプロジェクトは、昨年下期に実施した大規模な基盤移行であり、構成の見直しから段階的な切り替え、本番移行に至るまで、多くの検討と労力が求められました。 本記事では、移行に至った背景、当時直面していた課題、具体的な取り組み内容、そして移行を通じて得られた学びについてまとめています。どこか一部でもご参考になれば幸いです。 ▶️ KANNAのサービス紹介ページはこちら 🏗️ なぜ今、インフラ基盤のリプレースが必要だったのか？ 急速に成長を続けるSaaSサービスに対し、初期に構築したインフラでは、柔軟性・拡張性・運用効率の面で徐々に限界が見え始めていました。 さらに、弊社自身もグロース期に差し掛かり、将来的なスケーラビリ
TL;DR 東京リージョンを利用する際に2AZの冗長化で良い場合のAZ選定 「apne1-az1, apne1-az2」の組み合わせで利用するのが、レイテンシ観点からは良い。 レイテンシ: 500μs程度 大阪リージョンを利用する際に2AZの冗長化で良い場合のAZ選定 「apne3-az1, apne3-az2」の組み合わせで利用するのが、レイテンシ観点からは良い。 レイテンシ: 200μs程度 東京リージョン/大阪リージョンを利用する際にAZの冗長化不要時のAZ選定 どのAZを選定しても、レイテンシの観点からは良い。 レイテンシ: 50μs程度 東京リージョンの方がAZ間レイテンシが平均的に高い(大阪リージョンと比較して) 大阪リージョンの方がAZ間レイテンシが平均的に低い(東京リージョンと比較して) 2024年測定時と比較した際の変化 参考: 2024年に測定した際の記事リンク(Zen
生成AIプラットフォーム導入のための「テクニカルプロジェクト・マネジメント」 - LayerX エンジニアブログ
こんにちは。LayerX AI・LLM事業部でSREを担当している@shinyorke（しんよーく）と申します。 「企業と共に成長するAIプラットフォーム」であるAi WorkforceのSREとして、 Ai Workforceのサイト信頼性エンジニアリング（Site Reliability Engineering） SREチーム立ち上げ（SREメンバー大絶賛募集中です！&詳しくはこちら） Ai Workforceをお客様に導入する際のテクニカルプロジェクト・マネージャーとしてデリバリーの最前線で勤務 以上のミッションを日々行っています。 サイト信頼性エンジニアリングとチームの立ち上げについては以前のエントリー でもご紹介させてもらいましたが、 テクニカルプロジェクト・マネージャーとしてデリバリーの最前線で勤務 という業務は初見かと思います。 open.talentio.com （SREと
Terraform実行ユーザー用の最小権限の原則を支援するPike触ってみた | フューチャー技術ブログ
はじめにTIG 真野です。Terraform連載2025の2日目です。 Pikeを触ってみた記事です。 PikeとはPike は James Woolfendenさんによって開発されたTerraformのコードを静的解析し、その terraform apply に必要な最小権限の原則に則ったIAMポリシーを生成するツールです。直接 .tf のコードをスキャンするというところが、良さそうと思ったポイントです。 Terraformを用いてインフラ構築する際には、強めの権限（本来は不要であるサービスの作成権限など）を付与して行うことが多いと思います。そのため、万が一のセキュリティ事故や誤操作で思いがけない結果に繋がる懸念がありました。しかし、最小権限の原則を忠実に守ろうとすると難易度・対応コストが高くなるため、ある程度割り切った運用を採用することが多いように思えます（もちろん、開発時は大きめを許
Introducing AWS MCP Servers for code assistants (Part 1) | Amazon Web Services
AWS Machine Learning Blog Introducing AWS MCP Servers for code assistants (Part 1) We’re excited to announce the open source release of AWS MCP Servers for code assistants — a suite of specialized Model Context Protocol (MCP) servers that bring Amazon Web Services (AWS) best practices directly to your development workflow. Our specialized AWS MCP servers combine deep AWS knowledge with agentic AI
「AWS」と「Terraform」で学ぶクラウドインフラ自動化 非効率な管理／属人化から脱却するノウハウが分かる無料の電子書籍
多くの企業でパブリッククラウドの活用が進む一方、クラウドインフラの管理において、手作業での環境構築や設定変更は、属人化はもとより作業ミスによるエラーなどのリスクも大きいです。そうした課題を解決し、より効率的で再現性の高いクラウドインフラ管理を実現するため、IaC（インフラのコード化）の活用が広まっています。中でもIaCツールとして広まっているツールの一つが、「Terraform」です。 本eBookでは、連載『「AWS」×「Terraform」で学ぶクラウド時代のインフラ管理入門』全9回を収録。Terraformの基本的な概念や特徴だけでなく、Amazon EC2（Amazon Elastic Compute Cloud）を例に、TerraformからEC2インスタンスを作成したり削除したりする方法や、他のAWS（Amazon Web Services）リソースと連携させる方法、複数のリソ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに こちらの記事で執筆した通り、2024/01からAWSの設計構築案件に参画し、現在で1年3ヶ月が経過しました。 こちらの記事ではAWS案件に参画するまでにやってきたことをまとめていますが、本記事はAWS設計構築でやったきたことのまとめとなります。 経験してきたフェーズとしては以下の通りです。 各フェーズにおいてどのようなことを経験してきたのかをまとめていきたいと思います。 途中プロジェクト内で別案件の依頼があり、コンテナイメージで使用しているAmazon Linux2 -> 2023へのVersionUp対応、およびLambda
本文の内容は、2025年4月16日に Sysdig Team が投稿したブログ(https://sysdig.com/blog/kubernetes-1-33-whats-new/)を元に日本語に翻訳・再構成した内容となっております。 Kubernetes 1.33 の紹介: 開発チームとセキュリティチーム向けのクラウドネイティブな改善 Kubernetes 1.33リリースは、クラウドネイティブ・インフラストラクチャーにスケーラブルで安全、そして開発者フレンドリーな機能強化を提供するというプロジェクトの勢いを継続しています。Kubernetesの進化に伴い、重要なワークロードを正確かつ制御された状態で実行するためにKubernetesを利用するエンジニアリングチームとセキュリティチームの期待も高まります。 Kubernetes 1.33の機能強化には、ワークロード管理の簡素化、ID管理の
Amazon Web Services（AWS）では、企業のITシステムの開発や構築、運用に必要な数多くのサービスが提供されています。このため、たとえ同じITシステムであっても、選択可能なサービスが複数あったり、組み合わせるパターンも多数あったりします。 書籍『最適なサービスを選定して組み合わせる AWSクラウド設計完全ガイド』（日経BP）では、アクセンチュアのコンサルタントが実務で培ったサービス選定のノウハウを解説しています。本特集では書籍から抜粋し、インフラストラクチャー選定時の基本的な考え方を解説します。第2回では「ベストプラクティス」となる活用の要点を紹介します。 AWSでは、AWS上で適切なアーキテクチャーを設計するための「設計原則」をまとめた「ベストプラクティス」を提供しています。ベストプラクティスは、AWSや業界全体で蓄積された知見に基づいています。これらの原則を採用すること
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Terraform設計ガイドラインを公開しました | フューチャー技術ブログ
高速でスケーラブルなE2E実行基盤を目指して - freee Developers Hub
Repro における AWS アカウント分離の取り組み - Repro Tech Blog
KANNAのAWSインフラ基盤リプレースの舞台裏
AWSのAZ間レイテンシを測定してみた(2025年東京/大阪)
AWS実務未経験からAWSエンジニアになって1年で学んだ実践的なこと - Qiita
Kubernetes 1.33 – 新機能
AWS設計のベストプラクティス、「最低限知っておくべき10（＋1）のこと」を学ぼう