!本稿は2026/09/02時点のAnthropic Claudeのプロンプトキャッシング機能仕様を前提に記載しています。 はじめにさて、なるべく早く、なるべく安く、AIの実力を引き出すことがエンジニアの仕事になりつつある今日この頃。そんな私たちに必要なもの、それは「プロンプトキャッシング戦略」ではないでしょうか？本稿では、特にマルチテナント環境で提供される生成AIプロダクトにおける、プロンプトキャッシング戦略について記述します。 プロンプトキャッシングとは生成AIプロダクトの多くは、LLMと継続的に対話を重ねる形で構成されます。もちろん、LLMには過去のやり取りを...

Low-Level Networking in Go: Forging Packets, Decoding Bytes, and Building Custom ProtocolsGithub repoGo's net package covers 95% of what most programs need — TCP, UDP, TLS, DNS. But sometimes you need to go lower: build your own wire format, read raw Ethernet frames, or hand-craft an IP packe...

こんにちは！GVA TECH株式会社でエンジニアをしているsakochiと申します。先日、好きなK-POPアイドルのソウル公演チケットを取るために、いわゆる「チケッティング」に挑戦しました。日本のライブチケットは抽選販売が中心ですが、韓国では先着販売が一般的で、販売開始と同時にアクセスが集中します。実際に販売開始時刻ぴったりにアクセスしたところ、画面にはすでに約23,000人待ちの表示。さらにその後ろにも数万人規模の待機列が伸びており、アクセス集中の規模に圧倒されました。待ち人数は数秒単位で更新され、順番が来るまでリアルタイムに進んでいきます。また、入室後は購入完了までの制限...

想定読了時間: 20分対象読者: プロダクト開発とプロダクト組織に日々向き合うすべての方。エンジニア・PdM・デザイナー・マネージャーを問わず、「なぜ正確に書いたのに伝わらないのか」「なぜちゃんと聞いたのに分かっていなかったのか」を、精神論ではなく機構として理解したい人。!読了ガイド: 先に全体像だけ掴みたい場合は、TL;DR → 第2章 → 第6章の対応表 → まとめのチェックリストだけ読めば十分です（約5分）。役割別には、ドキュメントやSlackの誤読に悩む方は第3〜4章を、プレゼンやオンボーディングを設計する方は第5章を、インタビュー・1on1の質を上げたい方は第6章をどうぞ...

Building HTTP/3 Services in GoGithub repoHTTP/3 is the first major HTTP version to drop TCP entirely in favor of QUIC, a UDP-based transport that bakes in encryption, multiplexing, and fast connection setup. For Go developers, the standard library doesn't yet ship native HTTP/3 support, but t...

はじめに新規サービスや新規機能を公開するとき負荷テストをしたいシーンはあると思います。「ユーザー多くないし負荷かかることないから・・・」という方もいるかとは思いますが、サーバーのオートスケールなどの設定はされてると思うので、実際に上手く働くかの確認にも使えると思います。今回は負荷テストで比較的シンプルで使いやすいツールであるLocustの使い方を紹介したいと思います。 Locustとはhttps://locust.io/pythonでシナリオを書く負荷テストツールです。わかりやすいシンプルな記述で書けてサッとテストできるのが特徴です。また、dockerで動作するので複...

背景現在自分が所属しているチームではAI開発のワークフローとして、Orchestrator が計画フェーズ（Planner ⇄ Evaluator）と実装フェーズ（Generator ⇄ Evaluator）を制御する仕組みを構築(この仕組み自体は別のエンジニアさんが実装)しており、実装フェーズでは Generator がコード実装後に以下で作成したコードレビュースキルを実行して指摘箇所から重要なものを自己修正するようにしています。https://zenn.dev/gvatech_blog/articles/8f0be815036eaaただ、コードレビュースキルの中で多くの観点...

プライベートでAnthropic Claude Fable 5を利用しての成果物の品質にうっとりしている中、どうかこの精度のようなAIモデルを使い続けられないかと願った結果、Fable 5を利用してこのスキルをオリジナルで作成するに至りました。https://github.com/gvakosaka/fablify以下のnpx skillsによりインストールできるようにしております。npx skills add gvakosaka/fablifyしばらく利用してみましたが、モデルにgpt-5.4を使用していたとしても、体感的に既存仕様把握や、push前のセルフレビューの品質が格段...

!この記事は 1日54本のPRをマージした「並列agent codingコックピット」の作り方（ハコ編）、受付と作業部屋の対話をイベント駆動にする（通信編）の続編です。今回は「記憶編」—— セッションが終わるたびに消えていく学びを、どこへどう還流させるかの話。登場する事故・PR番号・ノートはすべて実物です。 コックピットの次のボトルネックは「記憶」だったコックピット（ハコ）ができて、通信（プロトコル）ができて、1日に何十本もPRが流れるようになりました。すると次の問題が見えてきます。翌朝、全部消えている。worktreeは供養され、作業者エージェントのセッションは破棄され、...

!この記事は 1日54本のPRをマージした「並列agent codingコックピット」の作り方 の続編（通信編）です。前回がコックピットの「ハコ」の話なら、今回は受付と作業部屋の「通信プロトコル」の話。本編に出てくる出来事・ログ・エラーメッセージは、すべて1日の実運用でそのまま起きたものです（末尾の「後日談」だけ、その後の10日間）。 コックピットの次のボトルネックは「通信」だったコックピット（1 worktree = 1 workspace = 1 エージェント）が回り出すと、次のボトルネックは受付と作業部屋の通信に移りました。ディスパッチ（下り）は/wtで1行になった。で...

はじめに謝罪 — ターミナルマナー入門の続きじゃなくてすみません「ターミナルマナー入門じゃないのかよ」—— はい、そのツッコミ、ごもっともです。本当にすみません。前回、「このシリーズでは、そんなターミナルの『お化粧の仕方』を紹介していきます」と大見得を切って第1回を出しておきながら、第2回を出さないまま半年が経ちました。その間に何をしていたかというと、この記事です。しかも1本で終わる気配がなく、連載として量産する気満々です。言い訳をさせてください。お化粧の話を書き溜めている間に、ターミナルの主役が人間からAIエージェントに代わってしまったんです。プロンプトをどう飾るかより先に、...

Using C Libraries in GoGithub repoGo was designed to avoid needing C, but the C ecosystem is enormous — codecs, image libraries, cryptography, hardware drivers, scientific computing. Rather than reinvent all of it, Go ships with cgo, a built-in bridge that lets Go code call C functions and vi...

By using LDFlags (Linker Flags), it ispossible to inject metadata at compile-time without changing a single line of code. This makes the binaries self-documenting and easier to debug in production. Pre-requisitesAny go version >= 1.0 will work on all OSes supported. Why Inject Metadata?...

はじめにもう一日中AIに質問を投げ込みまくってる私です。なにぶん我儘なもので、遠慮もなしに質問攻めをしておきながら、不意にAIから逆質問を受けた時「えっ回答するの面倒くさいな！」と思ってしまうものです。皆様もAIからの質問に対して、テキストエリアに回答をタイピングすることに苦心した経験があるのではないでしょうか？本稿では、この回答の摩擦をどう減らせるのかという観点から、AI Agent Chatの質問UIを掘り下げます。 様々なAI Agent Chatにおける質問UI Claude CodeClaude Codeでは、下記画像のように複数の選択肢の提示と合わせて、...

想定読了時間: 40分（detailsを展開する場合 55分）対象読者: プロダクト開発組織の変革を試みているリーダー（EM・VPoE・CPO・CTOなど）および B2B SaaSの開発チームで活動するPdM・エンジニア・デザイナー・EM。前作2本の内容を知っていると理解が深まるが、未読でも本記事単独で読み進められる。!読了ガイド: 先に全体像だけ掴みたい場合は、TL;DR → 「三部作の全体像」 → 「次アクション」だけ読めば十分です（約5分）。役割別には、EMの方は問い3と次アクション5を、PdMの方は問い2を、エンジニアの方は問い1を中心にどうぞ。前作:「要望」「...

はじめにCopilot Studioのエージェントフローにおいて、コネクタの実行が失敗すると、処理がその場で停止し後続のステップが実行されません。しかし、実際の運用では「エラー内容をクライアントへ通知したい」「エラーの原因に応じてリトライを行いたい」といったケースが多く、処理の停止が課題となります。そこで本記事では、コネクタにおけるエラーハンドリングの実装方法と、エラーを適切にキャッチするための手順について解説します。 手順トリガーは「エージェントがフローを呼び出したとき」を選択します。その次に値が正常に分岐を通ったか確認出来るように変数を初期化します。「アクションを...

想定読了時間: 25分（detailsを展開する場合 35分）対象読者: B2B SaaSの要件定義に関わるエンジニア・PM。前作の8ステップを知っていると理解が深まるが、未読でも本記事単独で読み進められる。先に全体像だけ掴みたい場合は、TL;DR → 「3つの新概念」 → 「チェックリスト」 → 「次アクション」だけ読めば十分です。前作: 「要望」「要求」「要件」は別物――役割別観測点を同じ座標系に変換するSaaS要件定義8ステップ地図 TL;DRAIでコードが書ける時代だからこそ、「何を作るか」を定義するプロセスの重要性は上がっている。抽象化の歴史に照らせば、要件定...

はじめに仕事をしているいろんな場面で大小様々な意思決定を迫られると思います。技術選定どうしよう、どのアーキテクチャにしよう、どのライブラリを使おう、テーブル設計どうしよう、などなど。ただ、決めることによる影響が大きければ大きいほど、決めるのに勇気がいると思います。失敗したらどうしよう、責任を追及されたら嫌だな、など決断を阻害する感情や要因は様々あります。また、AI時代においても「意思決定」は人間の役割として残る、とも言われています。そこで、自分が普段意思決定する際に意識していることや、良い意思決定をするために取り組んでいることなどを改めて整理してみました。個人レベルでの...

想定読了時間: 30分（detailsを展開する場合 40分）先に全体像だけ掴みたい場合は、TL;DR → 「変換の全体像」 → 「実務チェックリスト」 → 「次アクション」だけ読めば十分です。必要なStepだけ後から参照してください。 TL;DRPdM・デザイナー・エンジニア・QA・EMは、それぞれ「自分の観測点から見た真実」を言っている。議論が迷子になるのは誰かが間違っているからではなく、各観測点の声を同じ座標系に変換するプロセスが無い可能性がある。「要望」「要求」「要件」は別物。要望（生の声）→要求（need+制約+条件）→要件（検証可能な粒度）という変換の段階として扱...

はじめにここ１年くらい自分のチームでAI活用を推進してきました。カスタム命令の実装から入り、AI活用PJの立ち上げ、プロンプトファイルの導入、並列開発の仕組みの導入、AI知見共有会の開催、MCPサーバーの導入、コードレビューエージェントの実装などなど、色んな取り組みをしてきました。これらのAI活用に関する知識・経験は直近は役に立ちますが、こういった仕組みはどの組織も充実させていっており、いずれ陳腐化すると思っています。組織レベルでの仕組みがどんどん整ってくると、AI活用に関する知識は早いうちにエンジニアとしての差別化要因にはならなくなると思っています。今僕らがAI活用を推進...