The open-source Git project just released Git 2.54 with features and bug fixes from over 137 contributors, 66 of them new. We last caught up with you on the latest in Git back when 2.52 was released. To celebrate this most recent release, here is GitHub’s look at some of the most interesting features and changes introduced since last time. 💡 Since the last Git release we wrote about was Git 2.52,

1830年頃、わずかな夜の明かりを得るためには、約3時間の労働が必要でした。しかし1992年ごろにはそれが1秒にも満たない労働ですむようになったと言われています。ロウソクから白熱電球、蛍光灯へという技術的発展が、光を劇的に安くしたのです。 そうして光が安くなったとき、人は同じ量の光を単に安く買って終わり――ということにはなりませんでした。 人々は、かつて置こうとも思わなかった場所にまで光を置き、街路、工場、看板といった、社会のあらゆる場所に安くなった光を敷き詰めていきました。そうして、工場は曇りや雨の日にも稼働することができるようになったり、深夜営業や夜の読書といった新しい活動が可能になったのです。 そこで儲けたのは、光を提供した会社だけではなく、それをうまく使った会社でした。 では、ソフトウェアや知能が安くなったとき、私たちはそれをどのように使うのでしょうか。 生成AIによる大きな変化は

ソフトウェアエンジニアの仕事を、「コードを書く人」ではなく「何を守るかを決める人」の部分を紹介した発表です。非機能要件、分散システム、トレードオフを題材に、速さ、正しさ、止まりにくさが引っ張り合うなかで、日々どう判断しているのかをできるだけ身近な例で話しました。技術の基礎を知るための資料でありながら、こ…

最近少しキャリアについて考えていたので自分用に整理したもの

弊社ウェビナー ( https://flatt.tech/takumi/event/github-actions-compromise-202603 ) におけるCTO米内の講演資料です。 動画はこちら ( https://www.youtube.com/watch?v=ms8MkNmiejA )

1. はじめに なぜログは重要なのか？ ログは現代のソフトウェアシステムにおいて欠かせない要素です。適切に設計されたログシステムは以下を可能にします。 システムの稼働状態をリアルタイムで監視する バグや障害を素早く発見・修正する パフォーマンスのボトルネックを特定し最適化する ビジネス指標を継続的に把握する しかし、ログ設計が不適切な場合、次のような問題が発生します。 オーバーロギング：不要なログが大量に生成され、重要な情報が埋もれる 情報不足：障害発生時にデバッグに必要なデータが記録されていない 非一貫性：プラットフォームやサービスによってログ形式がバラバラで分析が困難 この記事の目的 本記事では、レストランの販売管理システム（注文受付・決済・在庫管理・デリバリー管理など）を題材にログ設計の方法を、実際のサンプルコードと具体例を交えながら解説します。 2. ログ設計の4つのコア原則 一貫

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

はじめに グループIT推進本部 CyberAgent group Infrastructure Unit（以下、CIU）所属・Next Expertsの平井（@did0es）です。 CIUのサービスのWebフロントエンド開発に携わる傍ら、TypeScriptのNext Expertsとして情報発信や社内向けの技術支援を中心に活動しています。 本記事では、pnpm や bun への移行を検討する前に、まず npm のままで実現可能なセキュリティ対策を実施したい人を対象に、 .npmrc に入れるべき最小限の設定を紹介します。 ここで紹介する設定は、最小構成でありつつ、CIUのWebフロントエンドでも共通して採用している内容です。 背景として、npmまわりでは直近で大きなサプライチェーン攻撃が続いています。 Shai-Hulud（2025年9月〜11月） axiosパッケージ改ざん（2026年

『Software Design 2026年3月号』の第1特集「再考・ログ設計」から第3章「実運用を見据えたログ設計の観点」を公開します。第1特集のほかの章では、構造化ログの基本やAWS環境でのログ設計の指針などについても解説しています。ぜひ本誌にてご確認ください。 効果的なログ設計は、信頼性が高いアプリケーションの開発・運用に不可欠です。本章では主要な設計原則を整理し、実効性を重視した具体的な指針と実装の勘所を提示します。クラウドネイティブな運用とオブザーバビリティの観点から、従来の設計を見直してみましょう。 はじめに アプリケーションログは、システムの動作状況を外部から把握し、意図したとおりに処理が行われているかを確認するための重要な情報源です。本章では、まずはOWASP（Open Web Application Security Project）やクラウドプロバイダー、オブザーバビリ

git alias を使ってコミットメッセージをAIに書かせる 最近はこれを git alias に入れて、コミットメッセージをゼロから書くことがほぼなくなりました。 aicommit = "!f() { COMMITMSG=$(claude --no-session-persistence --print 'Generate ONLY a one-line Git commit message in English using imperative mood. The message should summarize what was changed and why, based strictly on the contents of `git diff --cached`. DO NOT add an explanation or a body. Output ONLY the com

3つのエージェントがそれぞれの観点でコードを読み、問題を見つけたら自動で修正してくれます。 実験セットアップ Next.js（App Router + TypeScript + Tailwind CSS）でタスク管理ダッシュボードを作成。以下の「あるある」な問題を意図的に仕込みました。 simplify-demo/ ├── src/ │ ├── app/ │ │ ├── page.tsx # タスク一覧ページ │ │ └── dashboard/ │ │ └── page.tsx # ダッシュボード（統計のインライン計算、重複formatDate） │ ├── components/ │ │ ├── TaskCard.tsx # タスクカード（ローカルにformatDate等を重複定義） │ │ ├── TaskList.tsx # タスクリスト（メモ化なし、手動forループ） │ │ └

TL;DR CLAUDE.mdはSystem Promptではなく、User Messageとして注入される セッション後半になると影響力が薄れるため、セッションを通して守らせたいルールの置き場所には向かない CLAUDE.mdにはセッション開始時の作業を助ける情報だけを書き、ルールは .claude/rules/ に置く はじめに Claude Codeを使っている人なら、CLAUDE.mdに何を書くかで一度は悩んだことがあるのではないでしょうか。 コーディングルール、命名規則、テストの方針、コミットメッセージのフォーマット。色々なことを書いている人が多いと思います。自分もそうでした。 ただ、CLAUDE.mdの内部的な扱われ方を知ると、そこに書くべきものの考え方が結構変わります。結論から言うと、CLAUDE.mdにはセッション開始時の作業を助ける情報だけを書いて、ルールは .claud

TypeScriptコンパイラが「Go」で書き直された衝撃 150万行のコードを持つVS Codeプロジェクト。そのTypeScriptビルドが、77.8秒から7.5秒に短縮されました。 10.4倍の高速化です。 2025年3月11日、TypeScriptの生みの親であるAnders Hejlsbergが公式ブログで発表した内容は、フロントエンド開発の常識を覆すものでした。TypeScript 7では、コンパイラの実装言語がTypeScript（JavaScript）からGoに完全移行します。これにより、ビルド速度の10倍高速化、エディタ起動の8倍高速化、メモリ使用量の50%削減が実現されます。 この記事では、3つの軸からこの変化を読み解いていきます。 なぜGoが選ばれたのか — RustでもC++でもない理由 どう速くなるのか — 10倍高速化の技術的な仕組み 開発現場への影響 — 今す

1. はじめに：本記事の目的 本記事は、Don’t Build a General Purpose API (4 Years Later) という記事を元に、自社サービスなどのフロントエンド向けに 「汎用目的のAPI（General Purpose API）」 を構築せず、画面（ページ）に特化したAPIを構築するアプローチについての理解を深めるためのものです。 元の記事 このアプローチは、メンテナンスの簡素化、バグの削減、そしてパフォーマンスの向上に大きく寄与することが実証されています。ただ、この概念はしばしば誤解を招くため、よくある懸念や疑問を通じて、正しいアーキテクチャの考え方を学んでいこうという内容です。 2. コアにあるコンセプト：汎用APIとページ専用APIの違い まず、「私たちが開発すべきなのは、外部の顧客が様々な用途で利用するための汎用APIではなく、自社のフロントエンドチー

普段業務で色々なデータベースを触っていると、こいつの中身はどうなっているんだろうと気になることがあります。そんなわけでDatabase Design and Implementation: Second Editionという書籍をもとに、Go言語でRDBMSを自作しました。本書はJavaで書かれていますが、そのまま写経するのは面白くないのでGoでリライトしています。 出来上がったもの: github.com CREATE TABLE / INDEX / VIEW、SELECT、INSERT、UPDATE、DELETEといった基本的なSQLが実行できます。書籍では終盤GROUP BYやクエリ最適化をする章がありますが、まだ手を付けておらずインデックスまでの実装となっています。 なおAIコーディングエージェント全盛期ですが、この実装は学習目的なのでAIの利用は控えめにしました（テストとかでは使

本記事は、1時間で読み終わるエンジニアリングマネジメント本を書き始めてみるで挙げたトピックの1つです。 はじめに この記事では、定例ミーティングが増える理由と、その定例ミーティングを減らす方法について書いていきます。 まず個人的な定例ミーティングの捉え方として、「定例ミーティングは必要悪」だと思っています。同期的に人の予定を抑えることから、コストが非常に高いのです。ただし、意思決定や腹落ち感の醸成などの効果も大きいためゼロにはできません。参加者の役割にももちろん依存しますが、基本的にはパフォーマンスを出すためには少なければ少ないほどいい。 マネージャーという立場で考えると、ミーティングはどうしても多くなりがちです。外部調整や部門横断の相談も多く、カレンダーはすぐに埋まっていきます。そうなると、予定調整そのものがだんだんパズル化してきます。この状況が、定例ミーティングを増やす方向に自然と働き

Claude CodeのAgent Teamsおもしろいなーって思っている せっかく使うならtmuxで使うとAgent同士が会話している様子も見えて面白いよなぁって思うんだけど、僕は以前にtmuxをやめてiTerm2だけを使っていくことにしたんだよなー またtmuxをメインにする？？？いやーでもちょっと手間だなぁ・・・ってぼーっと考えてて、あ、そういえばiTerm2ってtmuxインテグレーションの機能があるんだったなって触ってみたら、これでいいじゃん！！！ってなった iTerm2のtmux integration tmux Integration - Documentation - iTerm2 - macOS Terminal Replacement iTerm2上で tmux -CC を実行するとtmuxが起動するんだけど、見た目はiTerm2なのだ。えっと、何を言ってるか意味がわから

CLAUDE.md は、Claude Code の性能を最大限に引き出すための最も重要な設定ファイルです。しかし、「とりあえず全部書いておけばよい」というものではありません。本記事では、内部メカニズムを踏まえた効果的な書き方を解説します。 CLAUDE.mdとは何か CLAUDE.md は、プロジェクトルートに配置する Markdown ファイルです。Claude Code はセッション開始時にこのファイルを自動的に読み込み、記述された内容を会話のコンテキストに含めます。LLM はセッション間の記憶を持たないため、CLAUDE.md にコーディング規約やビルドコマンドを記述しておくことで、毎回「プロジェクトを理解した状態」から作業を開始できます。 CLAUDE.mdの内部メカニズム 「短く書くべき」「普遍的な内容だけを書くべき」と言われる理由は、技術的な制約によるものです。 コンテキストウ

この記事では、複数のAIエージェントを組み合わせた開発フローと、それを支える環境構築のTipsを紹介します。 私はClaude CodeやCodexといったAIエージェントを毎日使っています。ただ単体で使っているとどうしても「このAIの判断、本当に正しいのかな？」と不安になることがあります。 そんな課題を解決するために試している「Claude CodeからCodexを呼び出してクロスチェックする」というフローを紹介します。 Claude Codeは非常に優秀で、実装からレビューまでこなしてくれます。ただ同じセッションで繰り返し確認を求めても、同じ視点からの回答になることはありませんか。 ここに課題があります。 毎回、何回聞いても同じ視点からの回答になる 局所解に落ちても気づけない 違う視点が欲しくなる 人間の開発でも、自分で書いたコードを自分でレビューするより、別の人にレビューしてもらった