こんにちは。Mackerelチームでサブディレクターを務め、プロダクトマネジメントを担当している id:RyuGoo です。 MackerelはOpenTelemetry形式のメトリックやトレースを取り扱うことができます。さらにオブザーバビリティを強化すべく、これらに加えてログを扱える新機能の開発を、2026年夏〜秋頃の公開を目指して現在進めています。 この記事では現在開発中の「Mackerelログ機能」について、その背景にある思いをお伝えしたいと思います。 どのような人のためのログ機能なのか チームのためのログ チームで使える、チームで再現できる 最初に提供しようと考えている体験と機能 サービス単位でログが見える 保存された過去のフィルタ条件を参考にして、フィルタできる これからの道のり 【Mackerelに登録すると、最新情報をメールで受け取れます】 どのような人のためのログ機能なのか

2026年3月19日、Aqua Security が提供するOSSセキュリティスキャナ Trivy のエコシステムが、3週間以内に2度目のサプライチェーン攻撃を受けました。攻撃者は aquasecurity/setup-trivy および aquasecurity/trivy-action の2つのGitHub Actionsに悪意あるコードを注入し、これらを利用するCI/CDパイプラインからクレデンシャルを大規模に窃取するペイロードを配布しました。 本記事では、GitHub Events APIおよびGitHub上に残存するcommitデータから取得したエビデンスをもとに、何が起こっているかを記録します。その上で、取りうる対応指針を示します。 免責 本記事の目的は事態の把握と対応の促進であり、違法行為への加担・助長を意図するものではありません。ペイロードの動作は手法の理解に必要な範囲で要

株式会社ヘンリーでソフトウェアエンジニアをしているwarabiです。 ヘンリーでは以前から開発にClaude Codeを用いていましたが、最近はSkillの活用などでClaude Codeの性能をもっと引き出そうとする動きが活発になっており、ブログでの発信も増えてきています。 Claude Code を活用した電子カルテの外部連携仕様書メンテナンス自動化の取り組み - 株式会社ヘンリー エンジニアブログ 今回は私が以前に作成したSkillをチームの共有物として管理・展開する際に気付いたSkill管理の課題と対策について話そうと思います。 以前作ったSkillの紹介 起票されたIssueの中身を確認・追加調査をしたうえで実装からPR作成までを全自動で行うOrchestrator型のSkillです。（以降 dev Skillと表現） dev.henry.jp このdev Skill作成は元々チ

Today we're introducing Code Review, which dispatches a team of agents on every PR to catch the bugs that skims miss, built for depth, not speed. It's the system we run on nearly every PR at Anthropic. Now in research preview for Team and Enterprise. Managing the review bottleneckCode output per Anthropic engineer has grown 200% in the last year. Code review has become a bottleneck, and we hear th

ターン数とは、1 回のプロンプト実行中に Claude が何回 API ラウンドトリップ（ツール呼び出し → 結果受け取り → 次の応答）を繰り返したかの回数です。 v1（新規作成）の所要時間 v1 では言語間の差が大きく出ています。Python（32.9 秒）と Ruby（33.2 秒）が僅差でトップ、JavaScript（36.0 秒）が続きます。一方、Ruby/Steep は 105.0 秒と Ruby の約 3.2 倍。Lua（96.4 秒）や OCaml（80.9 秒）も遅め。 v1 は空のディレクトリからスタートするので、Cargo.toml や package.json などのプロジェクト設定ファイルを生成するコストが含まれます。Python/Ruby/JavaScript などは minigit ファイル 1 つを生成するだけで済むので、差が大きくなっている可能性があります

こんな感じで、おおまかに数十件アカウントを登録したリストを作って日々眺めていれば、その方々のリポストで違う方の投稿が流れてきたりもするので、良いなと思ったらそこでリストにも追加したり、楽しくリストを育てています。 加えて、自分と同じ分野でAIを活用されている方々を追加するのも刺激になります。私は日本でWebアプリケーションの開発をしているので @mizchi さん @t_wada さん @laiso さん @azukiazusa9 さんなどの開発者の方々のポストも見ています。 最近はローカルLLMにも興味があるので @ollama や @Alibaba_Qwen も入れてみようかなと思っています。 ポストが英語なんだけど！ AI関連の情報はだいたい英語です。 私は英語弱いですが、XはポストごとにGrok翻訳UIがついているおかげで快適に読めます。ありがとうイーロンマスク…（AIリストにアカ

あの日のおかしくなりはじめた僕へ。良くなる見込みはない。 はじめに uiuさんの記事を読んだ。「AIのやりすぎで頭がおかしくなっている」。とても良い文章と内省だと思った。でも現在進行形ということは、まだ途中にいるということだ。まだ引き返せる場所にいるということだ。 uiuret.hatenablog.com 私はもう引き返せない場所にいる気がするので書く。 去年の7月、『AI時代の新たな疲労：なぜ私(たち)は「説明のつかないしんどさ」を抱えているのか』という記事を書いた。あの時の私はまだ「しんどい」と言えていた。しんどさを分析し、名前をつけ、構造を示して本を引用し、他人と共有できる形にまとめることができていた。あれは変容する前の人間の仕事だった。今の私が書く文章は、あれとは違うものになる。 このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。

エキスパートは突然生まれない。 やるべき仕事で結果を出し続けた人だけが、周囲からエキスパートと呼ばれるようになる。 プロフェッショナルな振る舞いについては、以前の記事で書いたことがある。 soudai.hatenablog.com 今回は、新卒から2〜4年目の若手エンジニアがエキスパートになるために何をすればよいのかについて説明する。 エキスパートとは何か エキスパートとは、ある分野において専門的な知識や技能を持ち、その分野で高い成果を出せる人のことを指す。 つまり、エキスパートとして認められるには、評価者が求める水準を超える成果を出し、認められる必要がある。 そのためには何が必要なのか。 重要なのは、 特定の分野に詳しい人では足りない ということだ。 例えば下記のような例だけではエキスパートとは呼ばれない。 本を読んでいる 資料をよく知っている SNSで発信している 実際の現場で問題を解

こういった、昨今のLLM事情を憂いる記事は親の顔より見ているが、やはり書かずにはいられなかった。 一点言い訳をしておくと、私は普段からLLMを使いまくっている。LLMを使っている人を批判したい意図は無い。 この記事を読んで、今一度LLMの使い方を俯瞰して見てもらえたら嬉しい。 LLM とわたし これでいいんだっけ？ もともと自分はコーディングが好きだった。面倒なことも多かったが、目的達成のために試行錯誤しながらプログラムを書き進め、ついに動いたときの感動がよかった。 だが、自分が手を動かして真心こめた手作りのソースコードを生成している間に、LLMはその10倍、いや100倍ものソースコードを生成できる。 世界が加速しているので、自分も同じだけ加速しなくては、相対的に遅れていく。 なので、LLMを活用できる人材とそうでない人材の格差はどんどん広がっていくだろう。 自分も理性でそう判断し、LLM

徹夜した翌日だったり、夜にうまく眠れない日が続いたり、二日酔いだったりすると、昼間に眠くなってウトウトしてしまうことがあります。 そういうときは横になって少し休んだ方が間違いなくいい。けれどもそういう判断ができないのも眠さによるものなのか「これは今やらなければならないんだ」なんて言いながら頑張ってしまったりします。 そして、パソコンで作業をしながら、あるときガクッと、完全に眠りに落ちてしまう一瞬があります。 頭がまさにガクッと落ちるかのように動き、その衝撃でハッと目を覚まします。すると目の前には、眠いなりに頑張ろうとしていた形跡が残っています。 ガクッと眠りに落ちたせいなのか、さっきまでよりもしっかり目が醒めています。 しかし、眠い中で作業した、最後の3分くらいの記憶がかなり曖昧です。 目の前には、眠りに落ちる前に最後にやっていた作業の画面が表示されています。 ユーザーは集中できないかもし

最近AIをやりすぎている。自分でもわかるくらい頭がおかしくなっている。 まともな状態ではないから、本来は人に見える場所に文章を書いたりするべきではない。ただ、自分の状態を精神状態を記録するために書いておきたい。 初めに書いておくが、この文章では一切AIを使っていない。というのもAI使うと、さらにおかしくなりそうだからだ。調査にも構成にも使っていない。100%生身、ピュアで粗雑な状態で僕が言葉を選んで書いている。 これまでもテクノロジー全般は好きで、これまでもChatGPTなどを使って仕事の調査をしたり引っ越しをしたり英語学習に活用したりしてきた。今年のAIは、昨年までとは一味違う人間の気を狂わせる何かがあると感じている。 仕事でのソフトウェア開発の話を最初にする。多少技術的になってしまうけど、これが入り口で僕はおかしくなったし、最も急激に変化している部分なので話さないといけない。 AIコー

エージェンティックエンジニアリング（Agentic Engineering）とは、AIにコード生成を任せきるのではなく、人間が設計や評価といった上位工程を担い、その下で複数のAIエージェントを統制する開発スタイルである。 この考え方に呼応するように整理を行った一人が、Google Cloud AIのディレクターであるアディ・オスマニ（Addy Osmani）氏だ。同氏は、バイブコーディングの手軽さを評価しつつも、それだけでは保守性や品質を担保できないと指摘し、設計・レビュー・反復といった“プロの工程”をAI時代に再構成する必要性を説いている。 ――ここからは『Deep Insider Brief』恒例の“ひと言コメント”として、今回の動きが示す技術の“今”をもう少し掘り下げていく。オスマニ氏の整理を軸に、エージェンティックエンジニアリングの全体像と、その開発の進め方を見ていこう。 Deep

転職・求人情報サイトのtype エンジニアtype ITニュース 年収2500万でも貧困層？ 米マイクロソフトに18年勤務した日本人エンジニアが「日本は健全」と語るワケ NEW! 2026.02.19 ITニュース マイクロソフトお金グローバルAI 「GAFAやMicrosoftに入れば、一生安泰の勝ち組になれる」――。 ビッグテックによる大規模レイオフに驚かなくなってきた昨今、そんな甘い考えでいる人は少ないだろう。しかし、一方でこうも思うはずだ。 「とはいえ、GAFAMに入社できるほどのエンジニアなら相当に優秀。レイオフされたところで、引く手あまたで職に困ることはない」と。 しかし、現実は違うようだ。 2006年に米国マイクロソフト（以下、MS）に入社し、プリンシパル・ソフトウェア・エンジニアという職位にまでのぼり詰めた太田一郎さん。だが、18年の献身が幕を閉じるのに要した時間は、わずか

大学で扱われるような高度な数学を、趣味として知りたい人向けの読み物を提供するサイトです。 受験勉強のように、与えられた問題を解くことだけが数学ではありません。 趣味として学びたいという好奇心と「なぜ？」という懐疑心を大切にして、一緒に大学数学の世界に入っていきましょう。 Twitter（@kimu3_slime）でも情報発信してます。

350万ページの機密文書を、誰もが読める形に変えた人々がいる。しかもたったの5時間で。その試みは今、YouTube、Amazon、Wikipediaへと拡張し続けている。 司法省が「技術的に不可能」と言い切った検索を、個人が実現した2026年1月30日、米司法省（DOJ）はジェフリー・エプスタイン事件に関する捜査資料を公開した。エプスタイン・ファイル透明化法（EFTA）に基づく措置で、その量は約350万ページ、2000本超の動画、18万枚の画像に及ぶ。米国の司法史上、最大級の文書公開だ。 だが問題は、その「量」そのものにある。公開されたファイルはPDFの山。スキャン品質は劣悪で、検索もままならない。DOJは議会に対し、文書の横断検索は「技術的な制約により実用的ではない」と説明していた。 その主張を、サンフランシスコの若い開発者2人がひっくり返した。 5時間で作られたGmailクローン「Jm

カケハシでの社内講演に、さくらインターネット株式会社の藤原俊一郎氏（@fujiwara）をお招きしました。「パフォーマンスチューニングのために普段からできること」というタイトルで、具体的な失敗談や現場の思考プロセス、そしてチューニングの本質についてお話しいただきました。 社内向けの場ではありましたが、貴重なお話をお伺いできたため、ご本人の許可を得て外部向けにまとめました。 当日は、前半を講演編、後半を対談編として構成し、対談パートにはカケハシのテックリードである松山も参加しました。 講演編：「パフォーマンスチューニングのために普段からできること」 なぜパフォーマンス問題は突然「死」を呼ぶのか グラフが改善したりISUCONで勝ったりする瞬間は「ものすごく楽しい」ものですが、一方で現在進行形でサービスが死んでいる状況は「めっちゃ楽しくない」ものです。長年育てたサービスが落ちることは、「自分の

さくらインターネット さくらインターネットで「プロダクトアウトとマーケットインのベストミックス」を目指す。Rubyコミッター成瀬インタビュー # 編集部おすすめ# エンジニア# 社員インタビュー Welcome Talk「ようこそ、さくらへ！」 2026年1月28日 社会を支えるパブリッククラウドを一緒に作りませんか？ >>さくらインターネットの経験者採用情報を見る 社員インタビュー記事や求人情報をお届け！ >>さくマガのメールマガジンに登録する さくらインターネットに新たに加わった仲間を紹介する『Welcome Talk「ようこそ、さくらへ！」』。今回は2025年、クラウド事業本部 プロダクト室にプロダクトマネージャーとして参加した田中隆裕（ハンドルネーム：成瀬）に、同じクラウド事業本部の卜部昌平がインタビューしました。歴戦のRubyコミッター二人が語り合います。 田中 隆裕（たなか た

概要 本書は、PostgreSQLの基本概念から安定稼働・パフォーマンスチューニング、そして現場で役立つ機能までを網羅した、実践的な解説書です。基礎的な解説からはじめ、PostgreSQLの内部構造、テーブル設計、レプリケーション、認証、バックアップ、リストア、モニタリングなどPostgreSQLを現場で利用するための知識を体系的に網羅しています。PostgreSQLの研究開発に従事し、PostgreSQL自身や周辺ツールの開発に携わるメンバーによる執筆で、機能を正しく理解して現場で活用できるノウハウが満載です。 目次 はじめに 読んでいただく際の留意事項 謝辞 目次 第1章：PostgreSQLの概要 リレーショナルデータベースとは データベースとは データモデル リレーショナルデータベースの役割 トランザクション管理 原子性（Atomicity） 一貫性（Consistency） 分離