はてなブックマーク

はじめに IT業界においてWeb系とSIerを比較する議論は長年繰り返されてきましたが、その多くは技術的優劣という形で語られています。 しかしこの議論をよく観察すると、技術そのものではなく認知の歪みが話題の中心に据えられていることが分かります。 とりわけITのにわか層においては、Web系は技術的に優位でSIerは劣位であるという単純化された幻想が強固に信じられています。 本稿では、この幻想がどのような構造によって生まれ、なぜ再生産され続けるのかを論理的に整理します。 議論の対象は技術文化ではなく、人事文化とマネジメント構造、そしてそれを誤認する人間側の認知メカニズムです。 技術は個人にしか宿らないという前提の欠落 技術は組織や業界に自動的に蓄積されるものではなく、あくまで個人の思考と試行錯誤の結果として身につくものです。 この当たり前の前提が抜け落ちた瞬間、「場所に行けば技術が身につく」と

下記ブログを読んだのでやってみる。 ターミナルエミュレータ ghosttyを利用しています。 軽量で必要最低限のことは設定できるし満足しています。 ターミナルマルチプレクサ tmuxを利用しています。 fizzy finderのskimを利用してghqやgit worktreeとつないで検索するときにtmuxのペインが生まれるようにしています。 シェル zshを利用しています。macOS標準がbashからzshになったあたりで乗り換えました。 AIコーディングエージェントを利用するようになって一般的なシェルのほうがつまずきにくいと感じています。 エディタ Neovimを利用しています。 最初は「憧れているエンジニアが使っていたから」という理由でしたが、かれこれ7-8年使っており、手に馴染んでいるので他に乗り換えを検討することもなくなりました。 一日のほとんどをターミナルで過ごしているのでタ

はじめに Rust でエンタープライズアプリケーションを構築する際、トランザクション管理の設計と実装が壁となります。 所有権システムの制約により、他言語では当たり前のパターンが適用できず、多くの開発者が実装に悩むポイントとなっています。 本記事では、実際のプロダクション環境で使用できる実装パターンを、具体的なコード例とともに解説します。 Rust におけるスタンダードな DB アクセスライブラリーである SeaORM と sqlx の両方での実装を通じて、実践的なアプローチを提示します。 本記事では、PostgreSQL や MySQL のようなトランザクション機能を持つ RDBMS を対象としています。 なぜRustでトランザクション管理は困難なのか 理想的なトランザクション管理とは トランザクション管理において、理想的な設計とはどのようなものでしょうか？ 筆者の考えでは以下のような要件

はじめに 生成AIによる開発は、すでに実用段階に入っている。 いまや、プログラミング経験が浅くても、 それなりに複雑な構造を持つコードを手に入れることができる。 この変化自体は、歓迎すべきものだ。 参入のハードルが下がり、 試し、学び、作る機会が広がったことに疑いはない。 一方で、ふと立ち止まって考えてみたくなる場面も増えてきた。 「本当に、それでよいのだろうか」と。 初心者が初心者である理由は、能力の不足ではない。 多くの場合、経験がまだ足りないだけだ。 試行錯誤し、失敗し、考え直す過程そのものが、 開発者を育ててきた。 ところが、GAIがあまりにも至れり尽くせりになると、 その過程が短絡されているように感じることがある。 便利さと引き換えに、 成長の速度や質が変わってきてはいないだろうか。 本稿は、GAI開発を否定するものではない。 むしろ、その進化を素直に肯定する立場に立つ。 そのう

1. 背景 ある商品の KPI (Key Performance Index) を達成するために行ったビジネスアクションを介入（施策）という。介入の効果を正しく評価するためには、施策を行った母集団のセレクションバイアスに気を付けて、RCT (Randomized Controlled Trial) を満たした手法で検証を行う必要がある。しかし、RCT を満たした手法で検証を行うのは、要求されるデータ量の大きさなどの観点から現実的には困難である。限られたデータの中で有意な検証を行う方法はいくつか存在する。そこで本記事では、その 1 つの手法である CausalImpact の概要と Python による実装について記す。実装は https://github.com/mae-commits/causal_impact_try を参照。 2. 概要 CausalImpact は DID という検

はじめに Claude Code（Anthropic公式のCLIツール）を使って日々の作業をしていると、有益な会話がセッション終了とともに消えてしまうのがもったいないと感じていました。 そこで、Claude Codeとの会話を自動的にObsidianに記録する仕組みを作りました。本記事ではその実装方法を紹介します。 やりたいこと Claude Codeでの会話を自動的にMarkdownファイルとして保存 Obsidianで管理しているナレッジベースに統合 手動操作なしで、会話のたびにリアルタイム同期 ノイズ（システムメッセージなど）を除去してクリーンな記録を残す 仕組みの概要 Claude Code セッション ↓ (jsonlファイルに記録) ~/.claude/projects/*/session.jsonl ↓ (5秒ごとに監視) watch-and-save.sh (LaunchA

ChatGPTの会話履歴（公式エクスポートのconversations.json）をPythonでMarkdownに一括変換し、ローカルで全文検索できる知識資産にします。月単位/会話単位で出力できます。 ChatGPTの履歴を知識資産に変える ChatGPTで調べ物や学習をしていると、数週間後にこうなりがちです。 「あの結論、どのチャットだっけ？」 「確か手順を書いたはず…」 「会話に散らばった知識を横断検索したい」 この記事では、ChatGPTの公式データエクスポートで取得できる conversations.json を、UTF-8のMarkdownに一括変換して、自分のローカルにmdファイルで保存するスクリプトを作ったので紹介します。 （外部API不要・追加ライブラリ不要・ローカル完結） Quick Start（最短3ステップ） 0) 前提 Python 3.x が動くこと（Windo

はじめに WSLでDockerの環境構築しようとしたらハマるポイントをまとめました。どんなエラー文が出て、どうやって問題を切り分けて解決するかも記載したので、これからWSLでDockerの環境構築しようとする方は必読です。 tl;dv クソでかい問題としてRancher DesktopのkubeconfigとWSLのdockerのとで競合していた。（自分の場合） 環境 Windows 11 WSL2 上の Ubuntu 24.04 Rancher Desktop コンテナエンジンは dockerd (moby) を利用 その１：パーミッションの問題 ワイ「なんやこのエラー」 ワイ「/var/run/docker.sockにパーミッションの問題でアクセスできてない、、、？」 docker compose up -d unable to get image 'postgres:15.0-alp

こんにちは。PIVOTでソフトウェアエンジニアをしている@tawachanです。 AIの進化により、私たちの開発プロセスは根本から変わりつつあります。AIは部分的に導入するのではなく、プロジェクト全体を見直す必要があるのは当然の流れです。実際PIVOTでもスクラムからカンバンへの移行を行うなど、私たちもいろいろ考えてやってみています。その流れの一例として以前の記事「スクラムからカンバンへの移行——ソフトウェアエンジニアがマネージャーになる時代に」でも書いています。 しかし今回は、あえてその大きな話から視点を移し、コードレビューという日々の細かいプラクティスに焦点を当てたいと思います。今年1年、AIを使い倒す中で「レビューで見るべきものが明確に変わったな」という個人的な感覚があり、その変化を言語化してみたいと考えたからです。 この記事では、AIが前提となった開発フローにおいて、コードレビュー

こんにちは、株式会社 PKSHA Technology ソフトウェアエンジニアの中西です。 1. はじめに Go 言語で MySQL を利用する場合、標準ライブラリの database/sql と、ドライバである go-sql-driver/mysql を組み合わせるのが一般的です。この構成は、事実上のデファクトスタンダードとして定着しています。[1] また、セキュリティ対策も重要です。特に SQL インジェクションを防ぐため、プレースホルダ ? を用いた Prepared Statement の利用はベストプラクティスと言えます。[2] しかし、この標準的で安全な構成でも、パフォーマンスが著しく劣化するケースはあります。本稿では Prepared Statement の 2 方式を整理し、Go のデフォルト設定で性能が落ちる原因をベンチマーク結果と合わせて示します。解決策と採用時のトレー

はじめに 本稿では、変数と定数を二項対立としてではなく、変更頻度や時間軸に沿ったグラデーショナルな存在として捉える視点が、なぜ多くのプログラマーに共有されていないのかを論じます。結論を先取りすれば、これは個々人の能力不足や理解力の問題ではなく、教育構造、評価制度、実務経験の質、そしてソフトウェア開発という営みそのものが持つ時間的特性に深く根ざした問題です。プログラミング教育や新人研修では、即効性と説明容易性が優先される一方で、時間を跨いで効いてくる設計感覚は切り落とされがちです。その結果として、多くのプログラマーは長年コードを書いていても、変数と定数を固定か可変かという二値でしか捉えられない状態に留まります。本稿ではその背景を段階的に整理し、なぜこの気付きが遅れて訪れるのかを、構造的な観点から説明します。 二値思考として教えられるプログラミングの出発点 初学者向けのプログラミング教育では、

PKSHA Technology ソフトウェアエンジニアの矢嶋です。 2025年も終わりということで、色々な人と「1年前ってどういう世界だっけ？」「Claude Code なかったね」「嘘だろ...」なんて話をしています。激動の AI 周辺では何かを標準と定めても半年後には別世界になっているかもしれませんが...サンクコストなんて言わずに探索し続けるのが正解かなと個人的には思っており、慌ただしくも楽しい1年でした。 この記事では、チームのナレッジを Claude Code のプラグインとエージェントスキルとして実装し、再利用可能な手段として活用する方法を紹介します。 背景 私たちのチームは、執筆時点で約20名のソフトウェアエンジニアが少人数のプロジェクトチームに分かれて開発しています。新規開発中のものと運用中のものを合わせると50件以上のシステムが動いています。基本的な技術スタックや設計思

Railsをアップグレードして一息ついていた頃のこと とあるアプリケーションのRailsバージョンを7.0.8.7 → 7.1.5.2にアップグレードし、リリースしました。 リリース後しばらく目立った問題も出ていなかったのですが、一部のリクエストに対してのみレスポンスが返せなくなっているらしいことが数日後に発覚しました。 原因調査 当初はエラーになるリクエストの条件が判然としなかったのですが、どうやらクエリパラメータが大量に付与されるリクエストに対してのみレスポンスが返せていないらしいということが見えてきました。 ということで実際に問題のリクエストを再現してみると、サーバ側で以下のログが出力されていました。RequestURITooLargeとのことなので、推測は当たっていたようです。 WEBrick is 何 WEBrick is an HTTP server toolkit that

読んだ本 ソフトウェアアーキテクチャの基礎 読む以前のアーキテクチャへの認識 ソフトウェアアーキテクチャって何？ アーキテクトの仕事ってなに？ インフラ的なあれですよね、違う？ 読むことで得られたこと 様々な種類のアーキテクチャの知識 マイクロサービスアーキテクチャの名前を知っているくらいのことしか知らなかった アーキテクトの仕事内容 アーキテクトに必要な知識などを紹介するため、そこからアーキテクトの思考様式や仕事内容が読み取れた アーキテクトって技術だけ知ってればいい訳じゃないんですね 深さよりは、広さの方が大事なんですね 必要な前提知識 ある程度の開発者としての開発経験 経験が少ない人が読むと、理解できない記述が多いと感じた 読むことのメリットが多い人 アーキテクチャへの知識が薄い人 マイクロサービスアーキテクチャってなに？ それ以外とかあるの？ アーキテクトの仕事内容を理解したい人

こんにちは！Software Engineer の @putcho01 です。 普段の業務では新規サービスの開発をしており、Go や GCP をよく触っています。 最近、業務の中で非同期処理が必要な機能を設計する機会がありました。新規サービスということもあり、非同期処理の技術選定や設計を一から行う必要がありました。ただ、非同期処理や GCP の各サービスの特徴をなんとなくでしか理解できていませんでした。 そこで、「非同期処理の設計指針」「GCPで非同期処理を実現する上での各サービスの特徴やアーキテクチャ」といった疑問を解消するため、一から調べ直してみました。この記事はその学びをまとめたものです。 この記事でわかること 非同期処理の設計原則（冪等性、パラメータ設計、並行性など） GCP 各サービスの特徴・違い Cloud Tasks Cloud Pub/Sub Cloud Eventarc

はじめに ソフトウェア産業は、見かけ上ハードウェア産業と似た構造を持つように見えます。どちらも工学的な手法を用い、製品を量産し、利用者に提供するという点では共通しています。しかし本質的にはまったく異なる原理で動いており、ハードウェアの世界で成功してきた「マスプロダクションの原理」は、ソフトウェア業界ではほとんど機能しません。なぜなら、ソフトウェアは「作る」ことが生産ではなく、「複製」そのものが供給行為になるからです。つまり、ソフトウェアには「製造」という工程が存在せず、工業社会が築いてきた品質向上のメカニズムが入り込む余地がありません。本稿では、量産という原理が持つ意味を整理し、ソフトウェアにおいてそれがなぜ働かないのかを論理的に明らかにします。 ハードウェア産業におけるマスプロダクションの構造 ハードウェアの品質は、統計的工程管理によって支えられています。つまり、同じ製品を大量に作ること

“守り”のコントリビュート Deno が提供している API は多くが JavaScript で実装されています。もしプロトタイプ汚染に耐性のない JavaScript コードで API を実装してしまっていた場合、ネイティブのプロトタイプメソッドが変更されてしまったときに影響を受けてしまいます。 私はプロトタイプ汚染などによって想定外の動作を起こさせないように、Deno の内部コードに対して“守り”のコントリビュートをしてきました。 前回記事の RegExp を受け取る String のメソッドに進展があったのでアドベントカレンダーの記事として報告しようと思います。 文字列のメソッド仕様に Normative Change を出した 文字列のメソッドには String.prototype.split のように引数に文字列もしくは RegExp オブジェクトのいずれかを受け取るものがありま

JS/TSを長く触れていると、無意識に受け入れてしまっている不便さがあります。その一つが、TypeScriptにおける非同期処理のエラーハンドリングです。 async/await の登場で非同期処理は劇的に書きやすくなりましたが、その裏で私たちは try-catch ブロックのネストと、型安全性の喪失という新たな問題と戦い続けてきました。 今回は、そんなモヤモヤと向き合った結果、 最終的に try-ok という小さなライブラリを作った話です。 私たちが抱える「try-catch」のモヤモヤ TypeScriptで非同期処理を書くとき、誰もが一度は以下のようなコードを書いたことがあるはずです。 async function getUser(id: string) { try { const user = await api.fetchUser(id); return user; } catc

プロダクトチームのエンジニアリングマネージャーをしている @_kehondaです。この記事は、ポート株式会社 サービス開発部 Advent Calendar 2025の内容になります。 概要 コードレビューが社内で採用されてもう10年以上経つ。 コードレビューがなかなかされなくて困っているとか、コードレビューが大変だという話をきっかけに、レビュイーやレビュワーの責任について考えることがあったので、社内で話していることや、私の考えるコードレビューを言語化してみる。 前提 取り扱っているプロダクトやチーム体制 自社での開発プロダクト アジャイルな開発プロセスで開発 エンジニアの相互レビューを行っている QAチームは存在せず、チーム内や依頼者で品質の担保を実施 私が考えるコードレビューとは コードレビューは｢品質高く・早く価値を届けること｣だと定義している。 コードレビューは関所ではない 一般的

この記事はPREVENTアドベントカレンダーの15日目の記事です。 はじめに 株式会社PREVENTの永田です。 Github Copilotを社内に導入してどのような形で活用しているかを紹介します。 レビュー 開発効率化するうえで、レビュー負荷が高く、レビュー待ちがネックになるという課題を抱えていました。そこで、以下の２つの解決策を実施しました。 レビュー依頼する前に、Copilotレビューを行う プルリクエストの粒度を小さくする ここでは前者についてお話します。 Copilotが一次レビューでtypoや単純なロジックミスを事前に指摘してくれることで、人間のレビューでは「仕様として正しいか」に集中できるようになりました。結果として、レビューの質を落とさずに負荷を下げられています。 簡単にやり方を説明します。 プルリクエストをOPENしたら、ReviewersにCopilotをアサインしま

概要 JiT (Just image Transformer) は VAE を使わず、ピクセル空間上で flow-matching を行う モデルは速度 (velocity) v を予測するよりも実画像 x を予測した方が性能が良い (x-pred) ただしロスは、実画像 x とノイズ画像 z から作れる速度 v でロスを計算すると良い (v-loss) はじめに 拡散による画像生成モデルは Stable Diffusion を筆頭として、U-Net ベースのモデルが主流でした。 派生の SDXL は、その取り回しの良さから 2025 年 12 月現在でもいまだに使われるベースモデルだと思います。 最近ではそれらに加えて、DiT から始まった Transformer をメインに用いた拡散モデルである、 Flux.1 や Qwen-Image、 Z-Image がその生成画像の品質の高さから

はじめに こんにちは、PKSHA Technology で EM をしている木村です。 私は PKSHA グループのトライアンフと協業し、面接官のトレーニング（ロールプレイ）のためのプロダクト「面トレAI powered by PKSHA AI Coach（以下、面トレAI）」の開発をおよそ 1 年前から担当しています。 （EM ですがメインの実装者です！） この面トレAI では Next.js App Router を採用し、 React Server Component(RSC)、Server Functions といった機能を活用しています。 最近大きな脆弱性が見つかり話題となったこれらの技術スタックですが、何が嬉しいのか。いつ使うべきなのか。API Route とどう使い分けるのか。こういった疑問も多く見受けられます。 今回は、面トレAI の開発を進める中で実感した恩恵の 1 つで

はじめに BtoB SaaS の開発において、「認可（Authorization）」 は複雑でセキュリティリスクの高い領域です。 ただし、認可ロジックとビジネスロジックが絡み合うと、アプリは複雑化してしまいます。 そのため、認可ロジックを如何に疎結合に独立して保てるかが重要と考えています。 UI では、権限がないボタンを「見せない」 API では、権限がないリソース操作を「させない」 DB では、権限がないデータを「引かない」 これらがバラバラに実装されると、セキュリティホールやバグの温床になります。 本記事では、フロントエンド/バックエンドで TypeScript を採用している PeopleX AI 面接を題材に、CASL を中心に据えた認可アーキテクチャの実践を紹介します。 ※ こちらの記事は TSKaigi Hokuriku 2025 のトークセッションにて発表した内容をより詳細に

はじめに プログデンスの圓佛です。CVEスコアが最大の「10」であるReactの脆弱性が報告されています。 CVE-2025-55182 CVE-2025-55182(facebook) Critical Security Vulnerability in React Server Components DifyもReactを利用している為、影響を受けますが早速、問題修正したv1.10.1-fix.1がリリースされています。リリースノートには以下の記載があります。 Security/deps: backend bumps pyarrow 17.0.0, werkzeug 3.1.4, urllib3 2.5.0 in api/uv.lock; frontend bumps React 19.2.1 (addresses CVE-2025-55182) and Next.js 15.5.7

この記事は、ひとりで作るSaaS - 設計・実装・運用の記録 Advent Calendar 2025 の5日目の記事です。 昨日の記事では「個人開発のドキュメント戦略」について書きました。今日は、個人開発におけるGitブランチ戦略について書きます。 🎯 個人開発のGit運用で考えるべきこと チーム開発では、Git-flowやGitHub Flowなど確立されたブランチ戦略があります。しかし、個人開発では状況が異なります。 個人開発の特徴: 開発者は自分一人（コンフリクトが起きにくい） レビュアーがいない（セルフレビューが基本） 素早く改善サイクルを回したい（手続きは最小限にしたい） 一方で、以下の課題もあります。 本番環境を壊したくない 変更履歴を追いやすくしたい AIエージェント（Claude Code）と協働する際のルールが必要 これらを踏まえて、私が個人開発しているMemorer

序文 プログラミングを始めたばかりの頃、私たちはこう教わりました。 「プログラムは、上から下へ動くものである」 これはCPUの仕組みから考えても正しく、直感的です。 しかし、現在、私が取り組む「基幹システム移行」 そこで苦しんでいる原因もまた「上から下への一本道」にあります。 本記事では、 なぜ私たちが直感的な「一本道」を捨てて、 一見すると複雑な「アーキテクチャ（関心事の分離）」を選ぶのか。 その理由を、「人間の脳のスペック（認知の限界）」から紐解きます。 ※どちらが優れているかという話ではありません。 「なぜ、そうなったのか」という、エンジニアが歩んできた歴史と選択のお話です。 スライド版もあります。 誰もが通る「一本道」の快感 最初のコードを「上から下への一本道」で書かれたコードにすることは、現代においても正義です。 （全くの新規で機能を開発する際、必ずそうします。） これは、いわゆ

私は長い間、毎日Web上に日記を書いています（紙の日記から含めると30年以上は書いています）。 npakaさんが「そらみ と へにへに のゆるふわAI研究所」という漫画連載をしているのを見て、AIに絵日記風のマンガを生成できるとふだんの日記と違う表現ができるかも？と思って、CLIツールenikkiを作りました。 enikkiとは enikkiは、テキストで入力したストーリーから絵日記風のマンガを自動生成するCLIツールです。GoogleのGemini 3を使って、脚本生成から画像生成までを一気通貫で行います。 主な特徴は以下の通りです： 対話型UI: ストーリー、スタイル、コマ数などを対話形式で入力できます 19種類のスタイルプリセット: 4コマ漫画、少年漫画、少女漫画、Webtoon、アメコミなど ステップごとの確認: 脚本・画像それぞれで確認・再生成が可能です キャラクター画像の参照: