はてなブックマーク

はじめに 株式会社ログラスでSRE / Engineering Managerをしている勝丸（@shin1988）です。 2026年7月10日・11日に開催されたSRE NEXT 2026に、2日間現地で参加してきました。今年のテーマは「Inclusive SRE」。SREsというロールにとらわれず、Site Reliability Engineeringに関わるすべてのエンジニアが学べる場にしたい、という思いが込められたテーマです。 私は昨年に続き2年連続でスピーカーとして登壇する機会をいただいたので、登壇の振り返りと、イベント全体の感想を書きたいと思います。 登壇について そして私は今年、「依頼文化をやめる日——EM視点で語るPlatform EngineeringとInclusive SRE」というタイトルで登壇させていただきました。 内容は、PlatformチームのEMとして、メン

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の152週目の記事です！ 3年間連続達成まで残り7週となりました！ こんにちは、ログラスの松岡(@little_hand_s)です。 3行まとめ 「レビューして」でも指摘は返ってくる。「敵対的検証して」は課題がある前提で反証を試み、判定と根拠まで返してくるのが違い 敵対的検証はClaude Code公式も推奨するパターン。筆者のClaude Code環境では、一言でサブエージェントによる多視点検証が走った 指摘は鵜呑みにしない。採否を決めるのは人間。この記事自身も敵対的検証を通して書いています 先に謝っておきますが、多少キャッチーすぎるタイトルになっております。すみません！！🙇‍♂️ 「レビューして」は今も有効で、使いどころのあるプロンプトです。この記事で紹介するのは、具体的な根拠を持ってもう一段

この記事は毎週必ず記事が出るテックブログ Loglass Tech Blog Sprint の 149 週目の記事です！ 3 年間連続達成まで残り 10 週となりました！ 🌱 はじめに こんにちは、ログラスでバックエンドの数値計算まわりの開発をしている wamomo です。 AI にコードを書いてもらう機会が増えたこの 1 年で、E2E テストの扱い方がチーム内で少しずつ変わってきました。この記事では、その変化のひとつとして、E2E テストの内容を Markdown のカタログとして書き出して運用している話を共有したいと思います。 💡 AI と一緒に書く時代に、人間が守るべきは振る舞い コードを全部追うのが難しくなってきた 最近、AI にコードを書いてもらう機会がぐっと増えました。テストコードの生成を AI にサポートしてもらうことも珍しくなくなってきています。AI と一緒に書く量が増

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の148週目の記事です！ 3年間連続達成まで残り11週となりました！ はじめに こんにちは。株式会社ログラスでSREをしている中井(elmo)です。 ログラスでは現在、Platform Engineeringの取り組みを進めています。 以前、SREチームの見形(mekka)がなぜPlatform Engineeringに取り組むことになったのか、そして1年間で何が変わったのかについて紹介しました。 この記事では、SREの民主化、開発者の認知負荷、リクエストベース運用の限界、そしてそれらに対する解としてのPlatform Engineeringについて書いています。 本記事では、その続きとして「では実際にどう進めてきたのか」に焦点を当てます。 Platform Engineeringは、技術を選んで導

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の143週目の記事です！ 3年間連続達成まで残り16週となりました！ こんにちは、株式会社ログラス（以下、ログラス）技術基盤本部の大野です。 現在、私は26卒のエンジニア研修の設計・運営担当を担っています。数ヶ月前から準備を始め、今まさに研修の真っ最中です。研修設計を担う中で私が考えてきたことを整理します。 本記事では、具体的な研修については言及せず、研修設計の思想についてお話します。 対象読者 社員の育成・若手エンジニア育成を担うマネージャー・メンター エンジニアに限らず、新卒や若手の研修設計を担う人事担当者 前提：AI過渡期におけるエンジニアリングに必要な「知識」の賞味期限 2026年現在、ソフトウェア開発の現場は劇的な過渡期を迎えています。 Claude CodeをはじめとするAIエージェント

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の142週目の記事です！3年間連続達成まで残り17週となりました！ ログラス プロダクト基盤チームの小林です。 昨今、AI コーディングエージェントによりサービスの成長やチーム分割が加速していく中で、新しいリポジトリが次々と生まれる状況かもしれません。一方、「マルチリポジトリ環境」（以下、マルチレポと略）に特化した運用プラクティスとなると意外と事例が少ないように見えます。 私たちは役割柄、複数のプロダクトや基盤をまたいで開発・運用を行う機会が多くあります。日常的に触れるリポジトリの数は、両手で数えきれない規模になっています。 そういったマルチレポ環境は、以下のような問題にぶつかりがちです。 自チームの開発であっても、他リポジトリの理解がないと正確なコードが書けない 他チーム所有のリポジトリの改修が必

この記事でわかること AI が存在しないパッケージ名を生成する構造的リスク（Slopsquatting）と対策 npm パッケージ経由で AI ツールのツールチェーンが乗っ取られる（Tool Poisoning）仕組み AI コーディングツールの自動承認設定をどう管理すべきか .npmrc、pre-commit hook、GitHub Actions の防御設定 2026 年 3 月に npm パッケージ Axios（週間 1 億ダウンロード）が侵害された [1]。npm install しただけで RAT (Remote Access Trojan) が自動実行される攻撃で、事件の解説や防御ガイドは既に出ている [2] [3]。 本記事が扱うのは Axios 事件そのものではなく、 AI と対話しながらコードを書く Vibe Coding 時代における、AI コーディングエージェント特有

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の139週目の記事です！ 3年間連続達成まで残り20週となりました！ 株式会社ログラスでSREをしている見形（mekka）です。 約1年前、ログラスにおけるSREの現状と未来という記事を書きました。当時はクラウド基盤チームとしてSREチームへの移行を検討し始めた段階で、「SREの民主化」を掲げ、組織全体で信頼性に取り組む未来像を描いていました。 あれから1年。実際にどこまで進み、何が変わり、何が変わらなかったのか。そして、その過程でPlatform Engineeringという取り組みに至った経緯をお伝えします。 1年前に掲げたこと 前回の記事では、大きく3つの方針を示していました。 アラートの整理 — 創業時から残る設定を見直し、開発者が自分たちで管理できる状態にする CI/CDパイプラインの再整

3. SaaSビジネスの開発チームがビルド＆フィックスに迷い込む5つの要因 昨今の一般的なSaaSビジネスにおいて、ビルド＆フィックスは意図的に選ばれるものではありません。 アジャイルを選択した後、チーム内で何かが欠けた場合に、いつの間にか迷い込んでしまっている状態を指すと私は考えました。 そして、欠けてしまう内容は、主に次の5つであると考えました。（どれか1つでも当てはまると、ビルド＆フィックスになっている可能性があります） ① ユーザー視点の解像度不足 実際の業務イメージが固まらないまま実装が先行してしまいます。 将来のプロダクトビジョンがなく、ユーザーの要望に応える選択肢が複数ある場合に場当たり的な選択をしてしまいます。 その結果、後になって既存機能と新たな要望がぶつかり、身動きが取れなくなります。 ② 価値のミスマッチ とりあえず作ること（アウトプット）が目的化してしまいます。 そ

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の137週目の記事です！3年間連続達成まで残り22週となりました！ データベースの主キーはもう UUIDv7 一択――というのが最近の流れかもしれません。特に今は AI が「核心です！本質です！UUIDv7 です！」と自信満々に採用してくる時代です。だからこそ、人間の側もその背景をしっかり理解しておきたいものです。 ログラス プロダクト基盤部の小林です。ID体系を根本から考え直す機会はなかなかありませんが、ログラスにおいていくつかの新規事業や大規模なプロダクト改修が進む中で刺激を受け、この記事を書きました。 本稿では、 「デジタルシステムのID（DBの主キー）」 に焦点を当て、その変遷と現代のベストプラクティスを紐解きます。 TL;DR: ID技術の比較と選び方 現代のシステム構築において候補に挙が

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の134週目の記事です！ 3年間連続達成まで残り25週となりました！ はじめに: 機能開発の初期フェーズ、毎回つらくないですか？ 新しい機能の開発を始めるとき、こんな作業が毎回発生します。 既存コードの調査 - 関連するドメインモデル、API定義、フロントエンドの実装を読む PRD（Product Requirements Document）の作成 - 設計方針、詳細設計、影響範囲をまとめる技術実装PRD タスク分割 - PRをどう分けるか、依存関係はどうか、レビュー可能な粒度か これらは地味に時間がかかる上に、人によってばらつきが出やすい部分です。調査が浅いと実装フェーズで手戻りが発生し、タスク分割が雑だと巨大PRが生まれてレビュー負荷が跳ね上がります。 また数人以上で分担するような大きなエピック

3行まとめ：この記事で書いていること 実行の順序制御はJavaScriptエンジンではなく、ホスト環境（ブラウザ/Node.js） 処理順序は、Task1個 → Microtaskを全部一掃 → 次のTask setTimeout(0)で登録したコールバックより、Promise.then()で登録したコールバック（Microtask）が先に実行される この記事を読むことで下記の処理の流れが理解できるようになります。 1. はじめに こんにちは、組織とチームを賦活させたいエンジニアの福土（ryoya_cre8or）です。 JavaScriptを書いて少ししてくるとイベントループという言葉を聞くことがあるかと思います。 イベントループはJavaScriptを実行する環境が提供する仕組みという説明を見かけますが、裏側の実態について正確に把握されていない方は多いのではないでしょうか？ 例えばset

この記事は 株式会社ログラス Product チーム Advent Calendar 2025 のシリーズ 2、23 日目 の記事です。 はじめに こんにちは、今年は真空ジェシカとエバース推しでしたが、気づけばたくろうのファンになっていたログラスの @Yuiiitoto です。東京都の納税者でもあります。 みなさん今年もお疲れ様でした。振り返ると今年は AI エージェント元年でしたね。 私も例に漏れず去年の夏頃から本格的に触り始めて、今年に入ってからは社内で Cursor/Claude Codeの布教活動、ルール（コード規約）の整備などをたくさんしてきました。 コード規約含む AI エージェントに渡すルールについての考え方もスライドにまとめたりもしました。 1 年間色々 AI エージェントと格闘し、「絶対」という言葉を使ったら言うこと聞いてくれる！とか、Claude Code サブエージェ

ログラスのよしだです。入社して3年の月日がたち、プライベートでも変化がありまして名前が変わり、氏名変更手続きの大変さを語れるようになりました。業務においては別の記事で書いているようにエンジニアからEMにそしてEMとしては兼務で複数のチームをマネジメントしていたりしました。 改めてこの3年で新たに初めて今も続いてることは何かなと振り返ると、会社の福利厚生で補助が出ることで始めたパーソナルコーチング（以下コーチング）は2023年2月からはじめて今も継続して月次で受けていました。 そのコーチングのメモを見返してみると、自分自身の業務内容の変化と共に人に頼るのが苦手という弱みの克服方法について示唆があったので筆を取ってみようと思います。 この記事では、業務に忙殺され、人に頼るのが苦手なマネージャーが、パーソナルコーチングを利用することで、以下の2点にどう対処できたのか、私の実体験を基にお話します。

はじめに：組織の「対話疲れ」を打破する、ラップバトルという奇策 組織の対話や心理的安全性について、ミーティングやアンケートを行っているのになかなか意見が出ない一方で、チームや組織の雰囲気はなんとなく良くないということはないでしょうか？ 私のチームも、スタートアップ特有の急激な組織変更や権限の移り変わりによって、「仕事のやりやすさ」に対するネガティブな回答が増加している状況に直面していました。 さらに問題だったのは、このネガティブな状況に対して、組織に率直に「提言をする人」が減ってしまったことです。 「言っても変わらない」「角が立つのは避けたい」という感覚が広がり、提言を促し、健全なコンフリクトを生み出すための場づくりが喫緊の課題でした。 そこでこの硬直した状態を打破するため、「仕事のやりやすさ」をテーマにしたラップバトルを行ってみました。 ラップバトルは、DJのビートに乗せて相手をディスり

14年前の講演が、いま必要になる理由。生成AIがコードを量産できてしまう2025年、圧倒されてしまっていないでしょうか。コードレビューや品質確保に追われているかもしれません。 この"複雑性の増大"に対して鋭い洞察を与えるのが、Rich Hickey（リッチ・ヒッキー）による Simple Made Easy (2011) です。ソフトウェア設計の本質を突く名講演でありながら、最近はあまり話題に登らないようです。 この記事では、原義に沿って Simple Made Easy を整理しつつ、後半は AI 時代にどのように読み替えられるのかを紹介していきます。今あらためて心に刻みたい内容です。 1. Rich Hickey —— 稀有な思想家が見ていたもの Simple Made Easy を理解するためには、Rich Hickey（リッチ・ヒッキー）という人物にも触れておく価値があります。彼は

※ 凡例: ✓ = 明示的に言及、(言及) = 関連概念として触れられている、- = 言及なし ※ Reflection/Critic の Anthropic 列については、記事内で「自己批評的なループ」として触れられている Evaluator-Optimizer の概念を対応付けたもの。 ※ LangGraph 列については、引用ページ [2:1] だけでなく、ReAct エージェントや Plan-and-Execute チュートリアルなど LangGraph ドキュメント全体を含めて対応付けている。 ※ Evaluator-Optimizer は Reflection の一種とも捉えられるが、Anthropic が重視しているため独立して記載した。両者の違いは以下の通り： Reflection/Critic: 同一の LLM が自らの出力を批評し、定性的に改善する（自己批評） Eval

こんにちは、ログラスの松岡(@little_hand_s)です。 3行まとめ AIに 「レビューと改善を3回繰り返して」 と指示するだけで、アウトプットの品質が向上する 本記事では、この手法を 「セルフレビュー反復」 と呼び、ドキュメント生成でもコーディングでも活用できる シンプルな指示から始めても効果が出る。レビュー基準を育てていくことで、さらに品質が向上する はじめに AIの生成物、なかなか思った通りの品質にならないという感覚、ありませんか？ 記事を生成させたら、論理が飛躍していたり、表現が分かりにくかったり、冗長だったり...。 コードを生成したら設計に問題があったり要件を満たしていなかったり…。 結局、かなりの割合を自分で修正して結構な時間がかかってしまった、ということ、ありますよね。 そこで効果的なのが、AIに 「レビューと改善を繰り返させる」 という手法です。 本記事では、これ

こんにちは、ログラスの松岡(@little_hand_s)です 3行まとめ 「先にテストをまとめて書かせる」はTDDではない（サイクルと目的が違う） 従来のTDDでは非推奨だったが、AI時代では有効な手法に 違いを理解して使い分けることで、AI時代の開発がより効果的になる AI時代のTDDと、混乱しやすい実現方法 最近、AI開発の文脈で「TDD（Test-Driven Development：テスト駆動設計）が有効」という話をよく聞くようになりました。 ClaudeCode公式のベストプラクティスでも「TDDはエージェンティックコーディングによってさらに強力になる」と述べられており、TDDの生みの親Kent Beckも「TDDはAIエージェントと働く際のスーパーパワー」と語っています。 実際にClaudeCodeなどのAIエージェントに実装を任せると、必要なテストコードを先にまとめて生成し

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の118週目の記事です！ 3年間連続達成まで残り41週となりました！ はじめに 今年の4月に新卒でログラスにエンジニアとして入社したカワサキです。 ログラスに入社して3ヶ月目から共通基盤プロジェクトの立ち上げの開発に携わり、エンジニアとしてアプリケーション部分の開発全般を行いました。入社してすぐにコードをたくさん書くことが出来るプロダクト開発に携わる機会をいただき、その中で学んだことをまとめました。 取り組んだこと この記事では具体的な技術スタックの細かい説明には踏み込みませんが、前提となるプロジェクトの背景と、自分が担当した範囲について簡単に紹介します。 背景：マルチプロダクト戦略と共通基盤の必要性 ログラスはマルチプロダクト戦略を掲げており、その実現に向けて共通基盤の構築を進めています。 既存事

こんにちは、ログラスの松岡(@little_hand_s)です 3行まとめ バッファを適切に積まないと、計画が遅延する可能性が高まる。 バッファを積みにくくする心理的バイアス(計画錯誤、過度に守備的と思われる不安)が存在する。 バイアスを打ち破るために、内訳を分解して過去の実績データに基づいて算出する「分解・ファクトベースバッファ」を使うとよい ※この記事ではアジャイル開発を例に説明しますが、考え方はウォーターフォールなど他の開発手法でも使えます。 リリース計画、遅れてない？ リリース計画を立てても、計画通りに進まないことが多いですよね。こんな経験、ありませんか？ リリース計画を立てたのに、予定より大幅に遅れる 「あと少しで終わります」が何度も繰り返される 見積もりを伝えた相手からの信頼が失われていく 原因は、見積もりに問題があることが結構あります。では、問題のある見積もりとはどんなもので

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の117週目の記事です！ 3年間連続達成まで残り42週となりました！ はじめに みなさんは、良いプロダクトを作っていくために、良い組織を作りたいと考えたことはありますか？私は常にこのことについて頭を悩ませていますが、うまくいかないことだらけでいつも心が折れてしまいそうになります。 困り果てていた私は偶然「問題解決のジレンマ」と「5000の事例から導き出した 日本企業最後の伸びしろ 人的資本経営大全」という書籍を手に取りました。そして、その書籍から得た知見をこの組織を良くしていくことに使えるのではないかと考えました。組織をよくしたいと悩んでいるそこのあなた！この記事を読むことで、新たな武器を1つ手に入れられるかもしれません。 こちらがその書籍になります。この記事を読んで興味を持った方はぜひ手にとってみ

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

はじめに：もしもAIが、あなたの会社の在庫を「-400個」にしたら？ 想像してみてください。あなたが導入した最新のLLM（大規模言語モデル）ベースの需要予測システムが、稼働数日後に暴走を始めたら...。 在庫管理システムを見ると、異常な発注が実行され、DB上の在庫が「-400個」というあり得ない数値になっています。慌てて原因を調査すると、LLMが提案した発注数を、検証なしにそのままデータベースに書き込んでいたことが判明しました。 実在庫は100個しかないのに、AIは「500個発注すべき」と提案します。この提案が検証をすり抜けて実行され、在庫がマイナスを突き破ってしまいました。 さらに事態をややこしくしたのは、その「再現性のなさ」でした。 障害対応チームが原因究明のため、AIに同じデータで再実行をかけると、今度は「300個」という、最初とは異なる提案が返ってきました。さらに翌週、利用していた

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の113週目の記事です！ 3年間連続達成まで残り46週となりました！ はじめに AI Agentシステムを開発したいと考えたとき、「何から手をつければいいのか？」「どのツールをどの段階で使うべきか？」と悩むことはないでしょうか。 私たちのチームでは、超初期のアイデア検証から実運用に向けた精度向上の検証に至るまで、プロジェクトの成熟度に合わせてツールを使い分けることで、開発をスムーズに進めてきました。 この記事では、ありもの（Cursor）から始め、Bedrock Agentを経て、最終的にLangChainへと移行した経験を基に、AIエージェントのPoCを段階的に育てていくための3つのステップを共有します。これは、同種のライブラリ（例: LangChain vs LlamaIndex）を比較する技術

この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の111週目の記事です！ 3年間連続達成まで残り48週となりました！ はじめに こんにちは、世界。 ログラスでQAエンジニアを担当している大平です。 今回は、生成AIを使って、既存機能の仕様書を作成する話になります。 コンテキストと悩みごと 現在、社内で生成AIの活用が盛り上がっており、テストに関しても、試行錯誤をしております。 試行錯誤の結果、人間がテスト分析、設計を行い、AIでテスト実装（テストケースの作成）を任せるということまでは実践レベルで利用しています。 ただ、生成AIでテスト分析、設計を実践するためには、コンテキストとして、既存機能の詳細な仕様書の情報が必要になります。仕様書の代わりにソースコードという方法もありますが、toBのプロダクトでは、複雑なビジネスコンテキストが絡み合うため

はじめに 皆さん、こんにちは。 ログラスでエンジニアをしている西代です。 今回は spec-kit を使ってみたことで見えた壁と今後の展望について話したいと思います。 背景 私は新規事業チームでエンジニアをしています。 新規事業での開発で一番求められるのは何でしょうか？ そう、スピードです。 お客様への価値提供サイクルを極限まで早め、高速で仮説検証を回す必要がある新規事業におけるプロダクト開発においてスピードは命といっても過言ではありません。 生成AIの進化により、開発スピードは格段に上がりました。 しかし、単に AI でコードを生成するだけでは、本質的なスピード向上には限界があります。 新規事業のプロダクト開発として一歩先へ進むためにはエージェンティックな開発の可能性を模索する必要がありました。 そこで私が試してみたのが 「仕様駆動開発」と Github が提供する仕様駆動開発のためのツ

こんにちは、ログラスでCTOをしております、いとひろ（@itohiro73）です。去年までは半年に1回まわってきたTech Blog Sprintが、今回はもう前回書いた記事から10ヶ月も経つということで、チーム規模の成長ぶりに驚く毎日です。 さて、ログラスは先日「Loglass AI Agents」構想を発表しました。ログラス代表布川の動画にもあるように、私たちは今、SaaSの価値を従来の形から変容させていく必要性を感じています。これまでの定量的なデータに基づいた決定論的な従来型のSaaSシステムにとどまらず、非定型なデータや不確実性の高い情報に基づいた非決定論的なタスクをAI Agentを通じて実現し、より良い意思決定に貢献するようなビジネスモデルをいかに構築していくか。私たちは今、その激動の時代の真っ只中にいます。 AIエージェントは銀の弾丸か？ この記事を読んでいるエンジニアの皆さ