はじめに Go のコンパイラにはスライスや配列へのアクセス時に、インデックスが範囲内にあるかを実行時にチェックする仕組みがあります。いわゆる境界チェック (Bounds Check) です。この境界チェックは安全性の為に必要な物ですが、ループの中で何万回も実行されると無視できないオーバーヘッドになります。 Go のコンパイラは SSA (Static Single Assignment) の最適化パスの中で、境界チェックが不要と証明できたアクセスについてはチェックを除去します。これを BCE (Bounds Check Elimination) と呼びます。つまり、コンパイラが「このアクセスは絶対に範囲内だ」と証明できる様にコードを書けば、余分な境界チェックが消えて速くなるという訳です。 encoding/hex パッケージに対して、まさにこの BCE を活かした高速化の PR が提出され

こんにちは！ブロックチェーンエンジニアの山口夏生です。 ブロックチェーン×AI Agentで自律経済圏を創る開発組織Komlock labでCTOをしています。 GSD（GET SHIT DONE）とは何か 「How We Built The World's Most Powerful Coding Agent」というXの投稿が114K Viewsを記録して話題になっている。 AIコーディングエージェントの信頼性が落ちる原因は、モデルのコード生成能力ではない。状態管理、コンテキスト汚染、連続性の喪失、Git操作のミス、検証プロセスの欠如。問題は「コードを書く」以外の全てにあると言われていて、GSD（Get Shit Done）は、この問題を正面から解決するOSSです。 GitHub Stars: 25,900+ (2026/3/9時点) ライセンス: MIT 対応ランタイム: Claude

はじめに 2026年1月、X のレコメンドアルゴリズムが公開されました。 以前にも、（Twitter と呼ばれていた頃の）レコメンドアルゴリズム[1]が公開されていましたが、今回は現時点での最新版のロジックとなっています。 この記事では、公開されたコードを読んで以下の点について理解を深めようと思います。 X のレコメンドシステム全体のアーキテクチャ 候補生成とランキングの2段階構成の実装 Two-Tower モデルによる高速な候補検索の仕組み Grok-based Transformer を用いたランキングモデルの詳細 リアルタイム推論を実現するための工夫 概観 2-stage レコメンドシステムの構成をとっており、次のようになっています。 1st stage: 候補生成 以下の2つの経路からユーザが興味を持ちそうな候補アイテムを高速に絞り込む フォロー中のアカウントの投稿 (In-Net

はじめに こんにちは。Nstockのtouyuです。 Nstockに入社し、初めて本格的にJavaでコードを書くようになりました。 Javaの書き味は思っていたよりモダンで、他言語からの類推でもある程度書くことができました。加えてCoding Agentの発展も著しく、正直にいうと言語仕様を深く理解せずに書くことも増えていました。 そんなある日、あるジェネリクスを含んだコードが期待していたものとは異なる挙動をすることに気づきました。 期待と異なる挙動 同じ型の2つの引数を取り、何らかの処理をさせるメソッドを用意したいと考え、以下のようなコードを生成してもらいました。

概要 どうも、どすこいです！ 先日投稿した 「そのDockerfile、卒業しよう」実務で通用するベストプラクティス が多くの方に読んでいただき、本当にうれしく思っています。 今回取り上げるテーマは、AWSにおけるアンチパターンです。 「AWSは触れているけれど、正直ベストプラクティスが分からないまま何となく動かしている」 「インフラは後から直せばいいと思っていたら、思った以上に深刻な状態になっていた」 そんな経験がある方はきっと共感できる内容だと思います。 この記事では、私自身が実務で遭遇した失敗や、普段のよく目にするやってしまいがちな構成を中心に紹介します。 単なる失敗談ではなく、なぜそれが危険なのか、どう改善すべきなのかまで具体的に解説しています。 この記事で伝えたいこと 開発の現場では 「すでにこの構成で動いているから」 という理由で、負債を積み重ねてしまうケースが後を絶ちません。

自己紹介 名前: uji 神戸市在住 NOT A HOTEL のソフトウェアエンジニア Gopher 7年生、TinyGo は 3年くらい前に初めて触りました KOBE.go, Kyoto.go 運営 KOBE.go TinyGo Keebイベントの様子 作ったもの 得られること TinyGo がどのように "Tiny" しているのかをざっくりと理解できる TinyGo が生まれた背景、設計思想に触れ、GoやTinyGoのコンパイラやランタイムの仕組みに興味が持てる！ そもそも TinyGo とは？ TinyGoは、Go言語をマイコン（マイクロコントローラ）やWebAssembly（WASM）のようなリソースが限られた小規模な環境で実行するために設計された、Go言語の代替コンパイラです。 TinyGoという言語がGoとは別にあるわけではありません。 なので、TinyGoでのプログラミングで

MapはO(1)、SwitchはO(N)？ Goのmapは、なにか深遠なるアルゴリズムによって取得時O(1)が成立していると聞いています。 switchは単純に一つ一つの節にマッチするか検証しているからO(N)ですよね？ だから、switchよりもmapを使ったほうがいいと思います switchで十分実現できる処理がmapで書かれていたのでレビューで変えるように指摘すると、このようなことを言われました。 確かにmapは取得時O(1)の時間計算量が掲げられていますし、対してswitchは一つ一つ検証していそうです。 ここで、O(N)程度の時間計算量なんか気にするのはcaseが1万とかになってからにしろ、「推測するより計測せよ」「早すぎる最適化」だと、どっちもどっち論で話を終わらせてもいいのですが、Goのような恵まれた環境ではちょっとでもopが増えたりnsレベルでも速度が遅くなるのは気になるの

最近、ふとした気づきがありました。 それは、「同じものを見ていても、過去と現在の自分では見えている世界がまったく違っている」ということです。 みなさんには、このコードからどんな世界が見えますか？ async function getUserName(userId) { const response = await fetch(`https://api.example.com/users/${userId}`); const user = await response.json(); return user.name; } はじめに こんにちは、株式会社ココナラ在籍のKです。 本記事では、冒頭の5行のコードを通して、私たちが学ぶ理由について考えてみたいと思います。 TL;DR 同じコードを見ても、人によって見えるものが違っている 学習を重ねることで、それまで見えなかった世界が見えてくる 学習

こんにちは、SODAのSREチームのDucと申します。 GitHub Actionsのコストを削減しながらCIワークフローを高速化したの工夫をご紹介します。 背景 私たちのチームは、snkrdunk.comサイトとSNKRDUNKモバイルアプリの可用性とパフォーマンスの維持に注力しています。 それに加えて、クラウドインフラストラクチャやその他の監視・開発ツールのコスト管理も担当しています。 毎月、AWSやGitHubなどのインフラストラクチャとツールの請求書をチェックしています。 GitHubの請求額が非常に高いことに気づきました。特にGitHub Actionsの部分です。 参考までに、GitHub Actionの使用量とサーバーの本番ワークロード費用の比較をご紹介します。 Fargate: Savings Plan適用で月額約$7,000。私たちのサービスは平均約5000リクエスト/秒

カウシェ Tech Blog の Firestore → Cloud SpannerでDBコスト93%削減！無停止でやり切った 1 年間の全記録 という記事が公開されました。 ある程度利用量が増えたら Spanner よりも Firestore の方が高くなるというのは Firestore の前身である Datastore 含め使ったことがあると経験するものですが、データベース移行は大変なので移行できていないユーザは多いでしょう。 無停止での Firestore から Spanner への移行という大変な仕事をやり切ったことは素晴らしいことですね。 ところで、この記事への反応を見ていると特定のポストの引用はしませんが Firestore から Spanner に移行したことで安くなることそのものへの驚きの反応をいくつか観測しました。 実際には Firestore のように Google C

Claude Codeにサンドボックス機構が導入されました(Macだと、内部的にはsandbox-execが使われるようです)。 /sandboxコマンドで有効化可能で、Bashツールをサンドボックス内で実行してくれます。通常はこの機能だけで十分でしょう。 新しいサンドボックス機構の解説を書きました: 以下、Claude Codeの機能に頼らず自力でサンドボックスを設定する方法についての記事です: Claude Codeくんは便利ですが、ちょっとドジなところもあるので目を離すのはちょっとこわいですね。 このようなときはVMやコンテナで開発環境を完全に隔離すれば安全安心が手に入るわけですが、プロジェクトごとに設定するのは面倒くさい。 悪意のないAIのうっかりミスを防げる程度の軽量なサンドボックスがあると嬉しいのですが、Macには意外と手頃なものがないんですね。 普段dev container

株式会社ナレッジセンスは、生成AIやRAGを使ったプロダクトを、エンタープライズ向けに開発提供しているスタートアップです。本記事では、RAGシステムがより正直に、知らないことには「分からない」と言えるようにするための手法「DTA（Divide-Then-Align）」について、ざっくり理解します。 この記事は何 この記事は、RAGの新手法である「DTA」の論文[1]について、日本語で簡単にまとめたものです。 今回も「そもそもRAGとは？」については、知っている前提で進みます。確認する場合は、こちらの記事もご参考下さい。 本題 ざっくりサマリー DTAは、RAGの精度を上げるための新しい手法です。USTCやCASIAなどの研究者らによって2025年5月に提案されました。 通常のRAGでは、外部ソースから検索して得た情報を直接利用して、最終的な回答を生成します。ただ、これだけだとLLMの元から

LLMでコードレビューといえばCodeRabbitのようなサービスがすでに存在していたり、 自前でコードレビュー用のGitHub Actionsを作成している事例なども散見されるようになった。 さらに最近はGitHub Copilotのbotがレビュアーとして参加してくれる機能もリリースされておりLLMによるコードレビュー環境は検証〜実践段階手前くらいまで進んでいるように感じる。 一方でこれらのLLMのコードレビューに対してはコードレビューの観点が求めるレベルに達していないという感覚もある。PR単位でのレビューなので言語やフレームワーク一般の観点でのレビューかせいぜい単一プロダクトに閉じた観点しかないことが多い。静的解析よりはもちろん柔軟とはいえ、本来プロダクションレベルの人間のレビューでは業務知識や関連プロダクト全体を通じたシステムの観点からの良し悪しといったことを考慮してレビューをする

こんにちは！ゲンシュンです。 新卒研修の時期ですね〜！この時期とか先輩から様々な本をオススメされますよね〜、自分も新卒数年目の頃は技術書籍だけでなくビジネス書籍、自己啓発本など色々薦められました。自分は本が本当に読めなくて、人生で完読できた本は「ハリー・ポッター」「7つの封印」「涼宮ハルヒの憂鬱」という小説シリーズだけです...笑 そんな自分が、断腸の思いで読めた(もしくは目を通した)書籍を紹介します。今回は技術書ではなく、社会人生活を送るうえでソフトスキルの形成に役に立った自己啓発チックな本10選、内容と感想をまとめました〜！ カエルを食べてしまえ！ 残業3時間を朝30分で片づける仕事術 本の中身が頭に入ってこない人のための読書のルール 次の会議までに読んでおくように! ~モダンミーティング7つの原則 時間をかけずに成功する人 コツコツやっても伸びない人 SMARTCUTS 成功する人は

先日起きた tj-actions や reviewdog のセキュリティインシデントのレポートを読みました。 その内容を個人的な検証結果や感想を挟みつつかいつまんで書きたいと思います。 詳細は原文を読んでください。 なお、侵害された repository 及び tag は全て修正され、盗まれた Personal Access Token (PAT) も revoke されているはずです。 攻撃の流れ tj-actions/changed-files が侵害されるまでに複数の PAT の流出及びリポジトリの侵害が連鎖的に起こっています。 つまり tj-actions/changed-files が直接的にいきなり侵害されたというより、複数のリポジトリをいわば踏み台のようにして侵害したという感じでしょうか。 攻撃者は PAT が盗まれたりした GitHub Account とは別に複数の Gi

これはなに ども、LT開発部のもりたです。 今回はMySQLのスキーマ変更（DDL）について調べました。 DDLってなんとなく使うことは可能なんですが、データ量が増えていくにつれて障害の要因になったりもしますよね。もりたも障害が起きてDDLを調べたクチなんですが、調べれば調べるほどDDLに関する断片知識が絡まり合い、整理をつけるのが大変でした。今回はその断片を撚り合わせ、綺麗に縫合することで、この１記事だけで大体全てがわかるようにしました。もしDDLでお困りの方がいらっしゃいましたら、この記事（と、そこから辿れる諸記事）を足がかりに基礎と応用を身につけていただければと思います。 また、有識者の方々は是非まさかりを構えながら読んでください。技術的な間違いや現場的にはこうだよという事項がありましたら、コメント欄に記載いただけると幸いです。 構成 構成 まず構成ですが、以下の通り進めます。 前提

はじめに 最近GitHubでプルリクのレビューアーにCopilotくんをアサインすると、AIがレビューしてくれるようになりました。 アサインしてしばらく待つとレビューを付けてくれます。 今回はCopilotくんの指摘はなかったようです。 さて、この機能は非常に便利なのですが、毎回アサインするの面倒くさいですしプルリクを出す人によってはアサインしなかったり忘れたりするのはイマイチなので、勝手にアサインして毎回レビューしてもらう設定にしちゃいましょう。という記事です。 GitHub Copilotは定額なのでなるべく使いまくったほうが得ですよね！ 結論を簡単に書くと ルールセットで [Request pull request review from Copilot]を有効化 すればOK これで完全に理解した方は以降は読まなくてもよいかと思います。 まずはCopilotくんにレビューしてもらおう

本記事では、RAGの性能を高めるための「DeepRAG」という手法について、ざっくり理解します。株式会社ナレッジセンスは、エンタープライズ企業向けにRAGを提供しているスタートアップです。 この記事は何 OpenAIがリリースした「Deep Research」[1]という機能が話題です。 この記事は、RAGでも「Deepな検索」ができるようにする手法「DeepRAG」の論文[2]について、日本語で簡単にまとめたものです。 今回も「そもそもRAGとは？」については、知っている前提で進みます。確認する場合はこちらの記事もご参考下さい。 本題 ざっくりサマリー DeepRAGは、RAGの新しい手法です。DeepRAGを使うことで、データベースを深く・網羅的に検索した上で回答するRAGを、構築することができます。中国科学院ソフトウェア研究所とWeChat AIの研究者らによって2025年2月に提案

はじめに 2024-12-08 に開催された ISUCON 14 にチーム最上川(@kawaemon, @shun-shobon, @re-taro)で参加しました。今回が ISUCON 初参加でした。本番では悔しくもデータ保持違反[1]で失格でしたが、スコア順位としては 37,127 点で全体 8 / 834 位、学生 2 / 99 位 でした。 また、その後 1 ヶ月程度に渡って開催された感想戦[2]においては、850,573 点で全体 2 位、学生 1 位でした。 この点数は、感想戦ベンチマーカー（インスタンス）のほぼ測定限界となっています。 筆者ローカルでは約 180 万点まで、後述するベンチマーカーの最適化を行うことで約 400 万点まで確認しています。 この記事では、どうやってそこまで点数を出したかやその経緯について書きます。 本戦の話はこちら: 経緯 本戦において、 トップが

ソフトウェア開発の現場では、AIを活用した開発支援ツールへの注目が年々高まっています。 （たぶん）1年ほど前はCursorを使っているエンジニアも今ほどは少なく、OpenAI DevDayでデモを行なったOpenAIのエンジニアがCursorをエディタとして利用していたことが話題になったのを覚えています。 そして、2024年12月についにリリースされた「Devin」は、AIチームメイトの名の通り、まるでチームの一員として自律的に動く点が特徴とされています。 https://devin.ai/ 弊社も検証のためにDevinをトライアルしていますが、新人エンジニアを育成するように少しずつタスクを与え、フィードバックを繰り返していくうちに、Devinがどんどん機能してくれるようになる――そんな“育成ゲーム”のような手応えを感じています。 本記事では、月500ドルという導入コストを見合う形で活用す