一般

前置きなしで行く。 俺の環境はこうだ。MacBook Pro M3、メインはVSCode派だったけど最近はIDEを行き来してる。本業はFastAPI + PostgreSQL + Reactのマイクロサービス構成で、4人チームで開発してる。去年からAIコーディングツールをいくつか試してきたが、正直なところ「本

TypeScript 5.0が出たのは2023年3月だった。それから3年近く、5.8まで追いかけてきた。毎回リリースノートを読んで「へえ、おもしろい」と思うんだけど、正直大半の機能はそこで終わる。試してみて、コードを書き換えるほどでもないな、と判断して次のスプリントに戻る。 でも一部は違った。実際に仕事のやり

2025年後半、僕のチームは3ヶ月かけてバックエンドアーキテクチャをゼロから再設計した。理由は単純で、サーバーレスで組んだシステムのAWS請求書が毎月更新されるたびに心臓に悪かったから。でも再設計の結論は、最初に予想していたのと全然違う方向に転んだ。 コールドスタートは2026年でも死んでいない 「コールドス

2024年3月、チームのSlackに「RedisがBSDライセンス廃止するらしい」という一言が流れてきた。最初は「また誇張された記事か」と思って無視した。でも翌朝、GitHubのリリースページを確認して本当だと分かった瞬間、「あ、これは面倒なことになった」と思った記憶がある。 うちのチームは4人のバックエンド

3つ全部作った。2週間、同じRAGパイプラインを各フレームワークで実装した。 うちのチームは僕を含めて4人で、社内ドキュメント検索システムを本番に載せようとしていた。Confluenceのページが約8,000枚、日本語と英語が混在してるやつ。フレームワーク選定で「LangChainが一番メジャーだから」という

去年の9月、チームで「そろそろKubernetes移行するか」という話が出た。3人のエンジニアで動かしているB2B SaaSで、当時はDocker Compose + EC2で全然普通に動いていたんだが、競合他社がブログで「うちはGKEで動いてます」と書いていて、なんとなく焦った感じになったのがきっかけだ。完

移行前のNode.jsスタック、そして正直うんざりしていた理由 3人チームで管理してる社内APIがある。データパイプラインの管理UI向けのバックエンドで、Express + TypeScript、エンドポイントが30ちょっと、PrismaでPostgreSQLに繋いでた。コードベース自体は大きくない。 でも設

まず背景から話す。うちは6人のフロントエンドチームで、去年の秋から15個のパッケージを持つモノレポを運用している。 apps/ に3つのNext.jsアプリ、 packages/ にUIコンポーネント、共有ユーティリティ、型定義の束。規模としては中規模 — 小さくもなく、Googleみたいに巨大でもない。 L

うちのチームは4人で、BtoBのSaaSプロダクトを運営している。バックエンドのAPIはずっとNode.js 20 LTSで動かしていて、Bunの存在は2年以上前から知っていたけど「まだ本番には早い」という印象が拭えなくて様子見してた。 転機になったのは去年末。マイクロサービス化を少しずつ進めていて、コンテナ

Pineconeの請求書を開いたのは去年の9月で、金額は$283だった。 3人チームで社内向けのドキュメント検索ツールを作っていて、RAGのベクトルストアとしてPineconeのStarter → Standardと乗り継いできた。ベクトル数は当時約40万件。リクエスト数は1日せいぜい500回。それで$280

去年の11月、うちのチームで画像フィルター機能を実装していたとき、TypeScriptで書いた処理が4K画像（3840×2160）で400msくらいかかっていて困った。ユーザーがスライダーを動かすたびにUIが固まる。これは直さないといけない。 そのタイミングで「WASMにしたら速くなるんじゃないか」という話が

去年の夏、私が担当しているSaaSプロダクトのPostgreSQLデータベースが10TBを超えた。それ自体は想定内だったんだけど、そのタイミングで突然いくつかのクエリが10秒以上かかるようになって、ユーザーからのクレームが一気に増えた。チームは私を含めて4人のバックエンドエンジニア。専任のDBAはいない。「と

去年の秋、チームの新しいAPIプロジェクトでエッジランタイムの選定をすることになった。メンバーは5人、ユーザーは日本と東南アジアに分散している。「とりあえずLambdaでいいんじゃない？」という声もあったけど、前のプロジェクトでコールドスタートに何度も泣かされていたので、今回はCloudflare Worke

去年の秋、3人チームで開発しているFastAPIアプリのCIをCircleCIからGitHub Actionsに移行した。理由はシンプルで、CircleCIの月額が3人規模のチームには重くなってきたこと、あとコードもPRもGitHub上で管理しているのに、CIだけ別サービスを使う意味を感じなくなってきたから。

ウチのチームは5人で、去年からマイクロサービスへの移行を進めていた。それまではEC2にDockerを直接並べる構成で回していたんだけど、サービス数が15を超えたあたりでデプロイ管理が本格的に辛くなってきた。「どのコンテナがどのホストで動いているか」を把握するためだけにSlackで確認が走る、みたいな状況。 オ

うちのチームは2024年末まで、8つのマイクロサービスをRESTで繋いでいた。5人チーム、1日あたり約30万リクエスト。規模としては「まあ中小規模」という感じで、当時はこれで十分だと思っていた。 思っていた、が正しかった。しばらくは。 金曜の午後4時、4段のREST呼び出しチェーンが94秒で崩壊した 金曜の午

去年の11月、僕が担当しているNext.js + Prismaのプロジェクトで大規模リファクタリングが走った。コードベースは45,000行くらい、バックエンドAPIが80本以上、チームは5人。そのタイミングで「どのAIアシスタントを全員に統一するか」という話が出て、それなら自分でちゃんと試してみようと思った。

去年の10月、金曜日の夕方にデプロイを走らせた。小さな変更のつもりだった——プロンプトの一部を最適化して、コスト削減を狙った修正。翌朝起きたら、Slackに30件のアラートが来ていた。 5人チームで作っているドキュメント分類パイプラインが、夜中の2時頃から静かに壊れていた。エラーレートが通常の0.3%から18

なぜ今さらイベント駆動の話をするのか 正直に言う。3年前、僕はイベント駆動アーキテクチャについてのブログ記事を読むたびに「理論はわかるけど、うちのシステムには大げさすぎる」と思っていた。 それが間違いだったと気づいたのは、昨年の夏、本番環境のマイクロサービスが連鎖的にタイムアウトし始めたときだ。注文サービスが

去年の秋、小規模なSaaSプロジェクト（FastAPIバックエンド、PostgreSQL、チームは自分含めて3人）のCI/CDをCircleCIからGitHub Actionsへ移行することになった。理由は単純で、コストだ。CircleCIの請求書が月々じわじわ増えていて、ある時「GitHubにすでに払ってる

去年の11月、3人チームで運用していたFastAPIのサービスが金曜の夕方に壊れた。原因はPythonのバージョン非互換。ローカルは3.11、本番は3.10で、特定のf-string構文が3.10では動かなかった。「次から気をつけよう」で終わらせようとしたら、2週間後にまったく同じ理由で別のサービスが落ちた。

去年の11月、チームのインフラを刷新しようとして、約2週間かけてこの3つを真剣に比較した。結果から言うと、最初に「当然Kubernetesでしょ」と思っていた自分の判断は、かなりズレていた。 うちのチームは3人。フロントエンド、バックエンド、インフラ（つまり自分）という構成で、月次アクティブユーザーが3万人程

半年前、うちのチーム（4人）で社内ナレッジベースのRAGシステムを作っていた。対象はConfluenceのドキュメント数千件とGitHubのREADME群。最初の実装は2日で動いた。精度は悲惨だった。 「チャンク1000トークン、オーバーラップ200、Chromaでいいでしょ」というノリで進めたら、ユーザーか

去年の11月、僕が担当しているNext.js + Prismaのプロジェクトで大規模リファクタリングが走った。コードベースは45,000行くらい、バックエンドAPIが80本以上、チームは5人。そのタイミングで「どのAIアシスタントを全員に統一するか」という話が出て、それなら自分でちゃんと試してみようと思った。

去年の12月、チームのSlackに「Copilot Businessの月次請求が先月比で跳ね上がった」というメッセージが届いた。チームが7人から11人に増えたせいで、それをきっかけに「そもそも代替ツールってどうなの？」という話になった。私が自ら手を挙げて2週間かけて4つのツールを試した。 これはその記録。 G

去年の10月、金曜日の夕方に デプロイ を走らせた。小さな変更のつもりだった——プロンプトの一部を最適化して、コスト削減を狙った修正。翌朝起きたら、Slackに30件のアラートが来ていた。 5人チームで作っているドキュメント分類パイプラインが、夜中の2時頃から静かに壊れていた。エラーレートが通常の0.3%から

去年の10月、社内のMLパイプラインにAPIレイヤーを追加することになった。チームは自分含めて4人、全員がバックエンド寄りのエンジニアで、Pythonには慣れている。「どのフレームワーク使う？」という話になって、30分の議論が2時間に延びた。FastAPIを推す声、Djangoの安定性を挙げる声、「Flask

金曜の午後4時に本番への デプロイ を手動で実行して、翌週月曜の朝にSlackで「ステージングと本番でAPIのレスポンスが違う」というメッセージが飛んできた。 確認してみたら、Helmのvaluesファイルをステージングにしかapplyしていなかった。本番は2週間前の設定のまま動いていた。チームは当時4人で、

去年の10月、 本番環境 でアラートが鳴り続けた。東南アジアのユーザーから「APIが遅すぎて使えない」というクレームが相次ぎ、Slackが荒れていた。 チームは4人。BtoB向けのSaaSダッシュボードを作っていて、 サーバー はus-east-1に置いていた。東京でのテストでは問題ない。でも、バンコクやジャ

去年の11月、Slackに通知が飛んできた。「ドキュメント要約パイプラインが2時間止まってる」。確認してみると、ログはほぼ空。エラーも出ていない。ただ静かに、何も処理されていなかった。 原因を追うのに3時間かかった。OpenAIのレート制限に静かに引っかかっていて、リトライロジックが事実上の無限ループに近い状

去年の11月、社内の技術ドキュメント検索システムを作っていたときのこと。上司から「このAIが古い情報を平気で返してくるんだけど、ファインチューニングすれば直るんじゃないか？」と言われた。当時の自分は「まあ、そうかもしれないですね」と曖昧に答えてしまった。 正直に言うと、その時点でRAGとファインチューニングの

先月、チームのツール予算レビューがあって、「AIコーディングツールへの投資を一本化したい」という話になった。自分はCursorをメインに使いながら、たまにCopilotも触っていたんだけど、正直どれが本当に生産性を上げているのか、感覚でしか分かっていなかった。 それで2週間、意識的に3つのツール——GitHu

6ヶ月前、チームでカスタマーサポートbotを本番リリースした。そのbotは自信満々に「返品期間は60日です」とユーザーに答え続けた。実際は30日だった。2023年の製品ドキュメントでファインチューニングしたモデルで、ポリシーが変更されていたことを誰も——自分も含めて——確認していなかった。300件のサポートチ

3週間前、自分でも「ちょっと無茶だな」と思いながら、GitHub Copilot・Cursor・Codeiumを実際のクライアント仕事で交互に切り替えながら試してみた。おもちゃのプロジェクトじゃなくて、本番で動いているやつ — Next.js 15フロントエンド、FastAPIバックエンド、それとRustで書

去年の11月、深夜2時にSlackの通知で目が覚めた。コンテンツ分類パイプラインが6時間動き続けて、OpenAI APIの費用を$340溶かしていた。結果物の約70%はゴミだった。原因はリトライロジックのバグ——なぜリクエストが失敗しているかを区別できていなかった。 context_length_exceed

先月、社内のデータレポート生成フローを自動化するタスクを引き受けた。毎週月曜日に複数のデータソースを集約して、SlackにKPIサマリーを投稿するやつだ。手動でやると毎週1〜2時間かかっていて、チーム全員が嫌がっていた。 この手の仕事はAIエージェントにうってつけに見える。でも実装に入る前に「どのフレームワー

先月、うちのチーム（5人のフルスタックチーム）のAIツール統合を任された。毎月のAPIコストが$800を超えていて、「本当にこれだけの価値があるのか」という話になったのがきっかけだ。それでClaude、GPT-4o、Gemini 2.0を2週間ガチで比較することにした。 フェアに言う。3つとも2年前の水準から