DEVELOPER’s BLOG
技術ブログ
- トップ
- 技術ブログ
1. はじめに 2. Zapier MCPサーバーを使ってみよう 2-1. 準備フェーズ ①Zapierでアカウントを作成 ②ZapierでMCPサーバーを構築 ③VS CodeにMCPサーバー情報を設定 2-2. 実行フェーズ ①Agentを実行しよう ②Zapierの実行履歴(History)を確認しよう 3. まとめ 1. はじめに ブログをご覧の皆さまこんにちは。エ
はじめに シナリオ:ネットワーク制御要件を満たすための設計 適材適所の判断をする コスト最適化の視点 まとめ はじめに AWSでは、あらゆるユースケースを支える豊富なサービス群が提供されています。 しかし、その選択肢の多さゆえに「本当に必要な要件以上のサービスを導入してしまう」ケースも少なくありません。 特に、非機能要件に対して、必要以上に複雑な構成を採用してしまうと、以下のようなデメリットにつながることがあります。 AWSコ
1. はじめに 2. 公式GitHub MCPサーバーを使ってみよう 2-1. 準備フェーズ ①GitHubでPersonal Access Tokenを作成 ②VS CodeにMCPサーバ情報を設定 ③作業対象のサンプルプロジェクトを作成 2-2. 実行フェーズ 3. まとめ 1. はじめに ブログをご覧の皆さまこんにちは。エンジニアの小川です。 前回の記事ではMCPサーバーの概要と導入時の注意
はじめに 1. EC2 × ALB × CloudFront でインフラコストを削減 2. API Gateway × Lambda × CloudFront で動的コンテンツでもコスト最適化 3. 単一リージョン × CloudFront でグローバル配信をシンプルに まとめ:CloudFrontは単なる「CDN」ではない! はじめに AWSでシステムを構築する時、「とりあえずEC2インスタンスを建てて終わり」としていませんか?もし
はじめに SSM統合コンソールによる一元管理 OSなど構成情報の可視化 Patch Managerによるパッチ運用の標準化 証明書有効期限の集中監視と自動通知 導入効果と業務改善イメージ 導入時の設計上の留意点 継続的改善を支える「運用の仕組み化」 1.はじめに クラウド活用が拡大し、AWS環境が複数アカウントで利用されたり、複数システムにまたがって利用されることは、システム運用における構成の一貫性を維持することの難易度を
1. はじめに 2. MCPとは(一般論) 3. 実際に触ってわかったこと: よくある誤解 3-1. MCPサーバーの誤解 3-2. MCPクライアントの存在 4. MCPを導入する前に知っておくべきこと 4-1. 実現できること 4-2. リスクと注意点 5. まとめ 6. おまけ:現状と今後の展望についての極めて個人的な考察 7. 参考資料 1.
はじめに 可用性設計の基礎:リージョンとAZの仕組みを理解する 止まらない設計を妨げる単一点障害:単一AZ構成の限界 マルチAZ構成:同一リージョン内での止まらない仕組み マルチリージョン構成:事業継続(BCP)のための冗長化 まとめ:設計段階で「どこまで止めないか」を決めよう 1. はじめに AWSは、数クリックで仮想サーバー(EC2)を立ち上げられるなど、手軽にサービスを構築できるクラウドです。システム企画や開発の初期段階では
目次 はじめに 環境構築 AI に実装を依頼する 所感 まとめ 1. はじめに こんにちは。エンジニアの齋藤です。 昨今のSNSでは、ChatGPTやClaudeを使ってアプリを作ったという報告を目にすることがあります。一方で、「どんな手順で進めればいいのか」「どこまでAIに任せて、どこから自分で考えるべきか」 といった具体的なプロセスについては、まだ体系的な情報が少ないように感じます。 本記事では、Apple が Xcod
はじめに スティッキーセッション(Sticky Session)とは Railsのセッション管理とCSRFトークン スティッキーセッションを無効化し、redisにセッションを保持させる場合 負荷分散とスティッキーセッションの設定 × セッションの保存場所 1. はじめに AWS ECS上でRails on Railsで開発したWebアプリケーション(以下Railsアプリ)を運用する際、ユーザーごとのセッション管理は重要なポイントです。 負荷分散を行いた
はじめに 責任共有モデルにおける責任範囲 EC2・S3・IAMにおける共通の設定ミスとリスク IAM権限エスカレーション攻撃の典型的な流れ 複合的なクラウド侵害シナリオ事例 SREによる包括的なクラウドセキュリティ改善 1. はじめに AWSなどクラウドは、提供事業者と構築ベンダーや利用者による責任共有モデルに基づいています。責任共有モデルがセキュリティなど、双方の守るべき範囲を示してくれています。しかし、このモデルを正しく理解し
はじめに よくある課題:分断された監視が生む見えないリスク 解決アプローチ:監視体制の一元化が"判断力"を取り戻す鍵に 成果:監視体制の一元化がもたらす3つの効果 導入のポイント:まずは"全体を見える化"することから まとめ:監視体制の一元化は、全社IT戦略の起点となる 1. はじめに AWS環境を活用する企業が増える一方で、意外と見落とされがちなのが「監視体制の分散化」によるリスクです。部門ごと、あるいは複数の外部ベンダーごとに
はじめに SRE文化が根付かない典型的な失敗パターン "失敗から学ぶ成功への実践的ステップ 文化定着を支えるアプローチ まとめ 1. はじめに SRE(Site Reliability Engineering)は、可用性やスケーラビリティを技術的に高めるだけでなく、組織全体の文化にも大きな変革をもたらすアプローチです。しかし、理論やツールが理解されていても、いざ現場に導入しようとすると「思ったよりうまくいかない」と感じるケースは少な
動いてはいるけど、本当に大丈夫? クラウド運用に潜む「よくある違和感」 "健康診断"は現状把握のための第一歩 今すぐ始められる「クラウド最適化チェックシート」とは? 放置せず、今から変えられること まとめ:安心の第一歩は"自分の現状を知る"ことから 1.動いてはいるけど、本当に大丈夫? システムは動いている。アラートも出ていないし、大きな障害も起きていない。 でも、「このままで、本当に大丈夫なのだろうか?」そう感
はじめに よくあるツールチェーンの失敗例 なぜツールが機能しないのか?本質的な原因を探る ツールを活かすための設計と運用のポイント 技術的アプローチ:閾値設計・連携基盤・OSSと商用の使い分け まとめ 1.はじめに SREの実践を支える基盤として、モニタリング、アラート、CI/CD、自動化といったツールチェーンの整備は欠かせません。しかし、「最新の監視ツールを導入した」「CIパイプラインを構築した」といった形式的な整備を終えても、
はじめに:なぜクラウド移行後に運用が不安定になるのか? 静的設計のままではスケーラビリティが活かせない 自動化なき運用は信頼性を損なう 見えないものは守れない:可観測性の再設計 金融業界におけるSRE導入の典型例:運用課題からの脱却 セキュリティとコスト最適化:持続可能なクラウド運用のために まとめ:SREによる運用再設計がクラウド成功の鍵 1.はじめに:なぜクラウド移行後に運用が不安定になるのか? 多くの企業がクラウド化を進
はじめに:マルチクラウドの「分断」がもたらす課題 背景:なぜマルチクラウドは難しいのか 解決策:SREによる統合戦略とは 技術戦略:統合運用を支える実装ポイント まとめ 1.はじめに:マルチクラウドの「分断」がもたらす課題 近年、企業のクラウド活用は高度化し、AWS・Azure・Google Cloudといった複数のクラウドサービスを同時に利用する「マルチクラウド戦略」が一般化しています。「いっそ1つのクラウドに統一した方が効率的では
はじめに SREにかかる費用の内訳 なぜ「高い」と感じるのか? "投資対効果"の視点で見るSRE コストを最小化しながら始めるには? まとめ:SREは「高い」ではなく「将来を守る投資」 1.はじめに SRE(Site Reliability Engineering)を導入したい──そう考える企業が増える一方で、「費用が高すぎるのでは?」と導入に躊躇する声も聞かれます。しかし、SREにかかるコストは単なる"費用"ではなく、"将来的な
SRE導入後のよくある課題と本記事の目的 盲点①:ポストモーテムの形骸化 盲点②:モニタリングのカバレッジ不足 盲点③:自動復旧の未整備 盲点④:改善サイクルの不在 盲点⑤:カオスエンジニアリングの未導入 まとめ 1.SRE導入後のよくある課題と本記事の目的 Site Reliability Engineering(SRE)の導入は、サービスの可用性や信頼性を高めるための有効な手段として多くの企業に取り入れられています。しかし
はじめに:運用現場の"人材不足"が引き起こすリスクとは? なぜSREが"人手に依存しない運用"を可能にするのか? 自動化・可観測性がもたらす省力化と再現性 従来の限界を超えた次世代の運用支援〜生成AI×SREの事例〜 今すぐ始めるためのSRE導入チェックリスト まとめ:人が足りない今こそ、SREという選択を 1.はじめに:運用現場の"人材不足"が引き起こすリスクとは? クラウド化やマイクロサービスの導入が進む中、IT運用の現場では
はじめに 小さな仕様変更のつもりが、大きな追加費用の話に発展してしまった。思い描いていたイメージと違う画面ができあがってきた。そんなすれ違いに、もどかしさを感じたことはありませんか? 私たちも、「もっと柔軟に、一緒に考えられる開発のかたち」を模索してきました。 本記事では、変化に寄り添う開発パートナーでありたいという私たちの想いと、準委任契約に込めた想いをご紹介します。 一緒に考えるパートナーであるためには? 請負契約の現場でよく交わされる言葉 例1)
はじめに:受託開発はつらい? 「いつかは自社サービスで自由に開発がしたい」 「受託開発って納期に追われてしんどそう」 「裁量もやりがいもなさそう...」 そんなふうに思っていませんか? 最近は、SNSやイベントでも"自社サービス開発の魅力"が語られる場面が多く、「エンジニアとしてカッコいいキャリア=自社サービスに関わること」といったイメージが強まっているように感じます。 でも、実は受託開発にもさまざまなスタイルがあり、その中には"やりたいこと"を
企業のシステム選びにおける選択肢 パッケージとオーダーメイド開発の比較 オーダーメイド開発で競争力を強化する最新アプローチ オーダーメイド開発が向いている企業とは? まとめ 1.企業のシステム選びにおける選択肢 近年、企業のデジタル変革が加速する中で、自社に最適なシステムを選定することが、競争力を左右する重要な要素となっています。企業がシステムを導入する際の選択肢として、大きく分けて「パッケージ※1」と「オーダーメイド開発」の2
はじめに 「ゼロトラスト」の考え方を取り入れる 設定ミスを防ぐ!インフラのコード化(IaC)を活用 「監視」と「インシデント対応」の自動化を強化 セキュリティパッチの適用を自動化する 社員のセキュリティ意識を高める まとめ 1.はじめに 最近、「クラウドを導入したものの、セキュリティ運用が複雑になって管理が大変...」といったお悩みを耳にすることが増えました。クラウドの柔軟性や拡張性を活かしつつ、どうすればセキュリティリスクを
はじめに VPNに潜む"突破される前提"のリスク ゼロトラストとは? 「信用せず、常に検証する」 ゼロトラスト実現の3つの技術要素 専用製品がなくても始められるゼロトラスト ゼロトラストがもたらす運用の最適化 まとめ:ゼロトラストは「思想」であり、今すぐ始められる改革 1.はじめに 近年、リモートワークやクラウド活用が急速に進んだことで、企業のセキュリティモデルも大きな転換期を迎えています。従来の「社内ネットワーク=安全」とい
お問い合わせはこちらから