【SREチーム ブログリレー 2日目】 こんにちは、SREチームの青木です。 エムスリーには、アクセスログや社内レポートを配信する仕組みがあります。レポートには部署や案件ごとに見てよい人・見てはいけない人がいるため、アクセス制御を行う認可システムを内製し運用しています。 この認可システムはこれまでブラウザでの SSO ログインを前提としていましたが、「Claude CodeのようなAIエージェントにレポートを読ませて集計や調査をさせたい」という要望に応えるため、OAuth 2.0 の Device Authorization Grant（RFC 8628、いわゆる Device Flow）を実装しました。本記事では認可システムへCLIでのアクセスのニーズとのDevice Flowの実装について紹介します。 浅草寺の宝蔵門(仁王門) 社内レポートの認可システムとは システム構成は次のような役
AI 利用の開示：この記事を書くにあたっての調査やブレインストーミング、校正には AI を用いましたが、本文の執筆やコードの実装、および出典の確認はすべて人間が行いました。 AI は好きだが AI 企業は嫌いだ こんにちは。みなさんは AI を使いこなしていますか？ 私は正直、あまり乗れていません。もちろん AI は非常に便利な道具だと思うし、使わない日はありません。しかし、その非決定論的な性質を考えると、いささか過大評価されているように感じます。 AI 企業の倫理的な問題も気になります。 Anthropic の CEO であるダリオ・アモディ氏はわざと恐怖心を煽るような宣伝をしていると批判されています[1]。アメリカによるイランへの攻撃には xAI の Grok が使われています[2]。データセンターの建設による環境破壊の懸念もあります。 かれらの煽動に乗せられて「AI を使いこなせるよ
はじめに この記事は SRE 連載です。 前月の記事ははてなブログに Amazon CloudFront SaaS Manager を導入した話でした。 前月に引き続き id:hagihala です。 はてなのとある Perl で実装された大規模サービス (以下「対象サービス」) は、Amazon ECS Fargate 上で運用しています。コスト最適化を検討するにあたり「Graviton (arm64) に移行すればコストが下がるのでは」という仮説のもと検討を始めたのですが、対象サービスのワークロードで実際に速くなるのか、信頼できるデータが必要でした。また昨年9月に Amazon ECS Managed Instances が登場し、「Fargate のまま行くか、ECS on EC2 にするか」の中間の選択肢も増えていました。 ECS Managed Instances は、プロビジョ
Fedora42など、Kernelが新しいLinuxではVMware Workstationのカーネルモジュールがコンパイルできず使えません。古いカーネルを使えばコンパイルできるのですが、新しいカーネルでも使いたいので調べました。 Fedora42からはSecure Boot用にカーネルモジュールへのサインも必須になっています。（無効にもできますが、サインするのは簡単） (さらに…) Dockerfileの中で永続化が必要なディレクトリ（ボリューム）としてVOLUMEを指定すると、-vまたはvolume:で明示的にマウントしないと匿名ボリューム（名前なしのボリューム）が作られます。匿名ボリュームが起動する度に新しく作成されるので放っておくとどんどん溜まります。 どのコンテナが匿名ボリュームを作っているのかはdocker inspectで判別出来るのですが、何度も、何度も、手動でやっているの
こんにちは、hatsu です。 先日、GitHub Actions で同じ job の中にある複数のステップを並列に実行できる parallel / background が 2026-06-25 に GA になりましたね。 これまで job の並列化はできましたが、step の並列化はできませんでした。 今回この parallel を実際のワークフローに入れてみて、ちゃんと速くなった例と、そこまででもなかった例があったので、そのあたりを書いていきます。 TL;DR 2026-06-25 に steps 並列（parallel: / background: + wait:）が GA。同じ job、同じランナーの中で独立したステップを並列化できる 効き方は大きく2種類あった 直列だった処理を並列にして、終わるまでの時間を縮める（本番デプロイが8分→3分） 別ランナーに分かれていた job を
📋 この記事の前提 Superpowers導入記事、ponytail調査記事、共存記事のいずれかを読んだ GitHub Copilot CLIやClaude Codeなど、コーディングエージェントを日常的に使っている 「ループエンジニアリング」という言葉を見聞きしたが、ハーネスエンジニアリングとの違いがはっきりしない この記事は2026年6月〜7月上旬時点の情報を元にしている。生まれたばかりの概念なので、ベストプラクティスやツールの対応状況は今後大きく動く可能性がある 結論: ループエンジニアリングは「ハーネスをいつ・どれだけ動かすか」を設計すること 先に結論を書く。ループエンジニアリング(Loop Engineering)とは、AIコーディングエージェントに人間が毎回プロンプトを打つのをやめ、エージェントにプロンプトを出し続けるシステムそのものを設計するという考え方だ。2026年6月、
JavaScriptランタイムのBun、Claude Fable 5を11日間稼働させてZigからRustへの移植を実現。Claudeをどう使ったのか？ JavaScriptランタイム「Bun」の作者であるJarred Sumner氏は、7月8日付けで公開したBun公式ブログの記事「Rewriting Bun in Rust | Bun Blog」で、約53万5000行のZig言語のコードをClaude Fable 5を活用して約11日間でRust言語へ移植。次バージョンのBun 1.4（Canary）はこのRust移植版になることを明らかにしました。 移植した結果、メモリリークを根絶し、バイナリサイズも約20％小さくなり、パフォーマンスも2％から5％程度向上するという改善が得られたとのことです。 Rewriting Bun in Rusthttps://t.co/Rl8bcaxBFc —
こんにちは！AIエージェント開発課です。 近年、生成AIの進化スピードは凄まじく、単なるテキストの要約やドラフト生成の枠を超え、自律的に判断してタスクを実行する「AIエージェント」が大きなトレンドとなっています。 このような技術的な潮流の中、私たちのチームは2025年5月に「AIエージェント開発課」として産声を上げました。累計導入社数 約20,000社以上の顧客基盤と、16年以上にわたって蓄積された膨大な業務データ（ドメイン知識）というラクスの強みを活かし、バックオフィス業務の「完全自動化」という未来へ向けて、日々泥臭く開発を続けています。 私たちがメインで取り組んでいるのは、主力プロダクトである「楽楽精算」へのAIエージェント機能の実装です。 この記事では、私たちが直面した「3つの壁」とそれを突破した設計原則、そしてそこで得られた知見を社内の他プロダクトへ共通LLM基盤として還元していく
Ask ten frontend developers where to store a login token, and you'll get four answers and an argument. And because each approach addresses different concerns, the debates continue without resolution. So let's clarify once and for all: What are the options to store a token, which are the most secure and what are the use cases. I go much deeper on XSS and CSRF in my FREE frontend security course, bu
2,3年前にUdemyさんで、変革プロジェクトをリードする方法論について合計24時間のシリーズ講座を発表した。 いま講座の一つを見たら受講生が2万人を超えていたので、それなりの人気コンテンツの様だ。 基本的にこれまで書いた4冊ほどの教科書を整理し直したもの（書いた順番により、複数の教科書をまたがった説明もあるので）。ただ、もちろんこれを機に新しく追加したテーマもある。今日はそれを一つ紹介しよう。 事業会社であれ、SIerなどの外部サービス提供者であれ、システム開発の経験は豊富で、ある程度ノウハウも整理されている。一方で僕らが上流と呼んでいる工程（一般的に上流と呼ばれる要件定義よりも更に前にやる、ゴール策定や現状分析、将来構想など）には慣れていない。というか、全くやったことがない人がほとんど。 そんな状況で、大規模プロジェクトの上流工程をやる際に頻繁に起こるのが「上流工程のプロジェクト管理を
技術を追うのが、いつの間にかしんどくなった。 IT業界に飛びこんだ頃は、新しい知識を覚えるのがとにかく楽しかった。 文系から未経験での採用だったこともあり、コンピュータやネットワークの基礎、フロントエンドからデータベースまでのアプリケーション構造、当時の技術トレンドなど、学ぶことすべてが喜びだった。 しかし、いつからだろう？ 「まだこんなに勉強しなきゃいけないのか」と思い始めたのは。 AWSが流行りだしたころ、公式ドキュメントやチュートリアルを読んでみて、「これはダメだ。ついていけない。そもそもこの技術の何が面白いのかわからない」と頭を抱えたのを覚えている。 勉強することがたくさんあるのが面白いと思ってこの業界に入ったのに、勉強するのが苦痛になってしまった。あの時期は精神的にかなり落ち込んだ。 テクノロジーを追い続けるだけが正解ではないここ数年は、技術すなわち「テクノロジー」を追い続けるだ
ソフトウェアの工数見積もりは40年以上にわたって研究されてきた古いテーマで、入門書も実践書も数多い。だが現場で広く流布する「常識」の多くは、一次資料まで遡ると実証根拠が確認できない。確率分布が書ける前提で精度を磨いてきた見積もり研究は、確率分布が原理的に書けない領域から来る大幅超過には対応していない。見積もりが大幅に外れる事例の多くは、見積もり研究が前提としてきた範囲の外側で起きている。
はじめに 「チケット作っておいて」「このチケットのステータス更新して」——開発中、こんなやり取りは日常茶飯事ですよね。 コードを書いている最中にブラウザへ切り替え、Redmineを開き、チケットを作成・更新する。このコンテキストスイッチが、開発の集中力を削いでいると感じたことはありませんか？ そこで、AIエージェント（Claude Codeなど）から直接Redmineを操作できるMCPサーバーを作りました。 🤔 MCPとは？ MCP（Model Context Protocol） は、AIエージェントが外部ツールやデータソースと連携するための標準プロトコルです。MCPサーバーを用意することで、AIエージェントがRedmineのようなサービスをツールとして利用できるようになります。 ✨ mcp-redmineでできること このMCPサーバーは16個のツールを提供し、Redmineの主要な操
はじめに Claude Fable 5、今までのモデルと比べても頭ひとつ飛び出るぐらい賢いですよね。 以前出た時にすぐメインモデルに設定して、実装からデバッグから雑務まで全部やらせた結果、トークンが凄い勢いで食われていくので対策しました。 Fable 5 の賢さは活かしつつトークンは食わせないようにオーケストレーターに徹させる運用に切り替えた結果、Fable の消費がはっきり減り、しかも長時間セッションでの判断のブレが減りました。その構成と、それを1コマンドで組む方法を共有します。 なぜオーケストレーション設定が必要なのか Claude Codeはもちろんオーケストレーション設定なしでも動きます。ただオーケストレーション設定なしでメインモデルにFable 5を設定するとかなり勿体無いです。 例えば、以下のようなタスクを送ったとします。 このタスク自体はシンプルですが、Claude Code
読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第91回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。 今回とりあげるのは「エンジニアリング戦略の作り方 ―エンジニアリングの難局を打破する意思決定」だ。エンジニアリングマネジメントの領域で良書を多数発表しているWill Larsonさんの新しい訳書であり期待値が高い。しかも前著でもトピックとして興味深かった「戦略」に関する深掘りである。 エンジニアリング戦略の作り方 ―エンジニアリングの難局を打破する意思決定 作者:Will Larsonオーム社Amazon Will Larsonさんの過去の本についての私の感想はこちら（エレガントパズルも読んだけど感想書いてなかった） 「スタッフエンジニア マネジメントを超えるリーダーシップ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![[AWS Summit Japan 2026] Amazon ECS 最新デプロイパターン Deep Dive](https://cdn-ak-scissors.b.st-hatena.com/image/square/68290f956d8e5f5f398e5db48a244ecdcf6a9b65/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Ffiles.speakerdeck.com%2Fpresentations%2F5167f6ebc8664a47aabd1f158fff177b%2Fslide_0.jpg%3F39977034)
