/note/tech

外資系IT、日本人は35歳以上採用はかなり警戒する理由

外資系IT、日本人は35歳以上採用はかなり警戒する理由

語弊があるタイトルだけど、外資系どころか海外でIT企業で働く場合でもそう、俺大学出てからずっとITエンジニア一本でジョブホッパーやってるけど。

ここ３～４年でどこも外資系ITで「日本人のエンジニアで35才以上って時点でちょっと難色を示すね」っていう通念みたいなものがどの会社でもあって、一種「あるあるネタ」になっててちょっと興味深かったので、

この辺の事情、何故かXやはてなで書いてるやつごく少数しかいなかったので、今後若い日本人ITエンジニアとかの参考になるんじゃないかなと思って書き残しておきたい。

先に言っておくとだけど必ずしも35歳以上は絶対取らん、というわけではない。実際俺も35歳以上なわけだし。外資系で活躍してる日本人エンジニアは海千山千のツワモノが多いから35以上～50代当たり前ではあるし

ただある種の偏見(まあ一面真実なわけなんだが)というか、法則の様なものがやっぱり体感的に俺も、外資系で通用してる日本人エンジニア達や外人や経営層にもみんなあるみたいで、一種の「マーフィーの法則」みたいになってる。

■ ① 海外から見た日本の35歳以上のエンジニアを採用しづらい理由「技術的バックボーンの文化からして他責思想が染みついてるから」

これが一番の理由で、一番面白かったところ。

俺は口にはしないくらいの分別はあるとはいえ、気持ちの理解はできるけども、欧米中はもちろん、イスラエル、韓国、インド、東南アジアのIT新興国のエンジニアも皆本気で不思議がっている

「彼らはなんで、いつまでも金子勇とTRONは無理解な政府と、外国に潰されたって言い続けてるんですか？」って、確かにね、Winnyなんか出てた頃なんかまだブラウン管のPC残ってたような時代の事だから、今の若いエンジニアからすればもう理解不能の領域だよね、あの他責思想は。

前の外資ITにいたとき、そこの上司がアメリカの人だったんだけど、「TRONって世界中で使われて普及国産OSだから、端的に言って成功してると思うし、潰されたとか全然そんなことないのに、何であんなに他責思想なんだろうね、日本人エンジニアって」と酒の席で不思議がってたのをよく覚えてる。

「Winnyって、もう20年前の技術でしょ？20年前のパソコンなんて、僕は"シュタインズゲート"でしか見たことないよ」、「そんな昔の事いつまでも引きずってるから世界観からして技術のキャッチアップが偏っちゃってるところあるよね」って後輩の中国人・韓国人エンジニアが突っ込んでたのとも、ちょっと苦笑してしまった。

上司だったアメリカ人も「例えば、イギリス人のITエンジニアがアラン・チューリングは政府に潰されたせいでIT技術はアメリカに奪われたのだ！なんて言ってる人、いる？いないでしょ？いたら頭がおかしい人としか思われないよ」と滅茶苦茶辛辣なツッコミをしていた。

言われてみれば確かにそうだな、と思う。外資で働いてる日本人エンジニアって、俺含めてそういう部分は内心思うところはあるんだけど、口に出したりいつまでも気にしてる人全くいないんだよね。俺お金が稼げるからって理由で特に愛着とかないし。

でも、そういう「こだわりが強い(他責思想の)日本人エンジニア」は外資に挑戦してくることは腐るほど見て来たけど、みんな物にならずに去っていってるから(後述すると一部はハマって活躍できる人たちもいる)、採用コストも含めてその時点で難色を示すっていう「マーフィーの法則の亜種」みたいなのができちゃってて、

しかもこれ、例に挙げたのが前の会社ってだけで、ここ３～４年でどこもみんな似たような認識の話が出てるっていう話。

■ ② 特定のアニメ・サブカル分野が好きな奴は要注意

これも採用・人事考査に響くほどの謎の法則性があるんだよね。具体的な作品名は上げないけど、まぁ所謂「異世界で転生してやり直すとか、悪い女貴族に生まれ変わって…みたいなのがいっぱい書かれてるジャンルの某web小説系」が好きって日本人エンジニア、伏字にすると「●●●系」って奴。

コミュニケーション取ってる中でこの話題が出た時点で、周りの空気がピキって緊張感で凍り付く程割とみんな「あっ…(察し」ってなってしまうくらい、「使えない」というよりコンプライアンス・コミュニケーション的に問題ある「問題児」的な日本人エンジニアは圧倒的にこれが多かった。圧倒的というより、100％そうだった。

というか①に該当しなくとも「②」が発覚した段階で、空を見上げて「Oh…my god…」とみんななってしまうくらいのレベルだった。

正直「①」で上げた様な他責思想気味の人たちでも、もうテック大好き！ってくらいな人たちはこだわりが強いだけで、スキルセットがハマったらかなりうまく外資でも活躍できる可能性があるし、実際そういう人も結構いるんだよね、特にAI系とビッグデータ操れる人材は重宝されてるし。

でもこの「某アニメ分野が好きな」エンジニアって時点で、今までそんな奴一人もいなかった。マジで鍛えれば使えるとかマネジメントでどうこうなるって領域超えたレベルの、酷い奴は対人トラブルまで起こすレベルで、まぁ言葉悪いが「外れガチャ」しかいない。

これ、前の会社どころか、前々、今の会社でも同じような法則性で見てる外人や経営層が多くて、ちょっと笑っちゃった。外資で働いてる人らはてな含めて多いはずなのに、この辺のあるあるネタ出ないの割と不思議だと常々思う。

①と②がそろってるやつの率が圧倒的に35才から上で比率が異常に高かったから、なんか外資系でもそういう法則性みたいなのが流れちゃってるんだろうな、と個人的には思ってる。

まぁ逆に言えば、①と②の傾向がないエンジニアがそれだけ日本でも若手では増えてるから、「日本人のエンジニアだから」って取らないなんてことは全くないんだけども、

これから外資で働いてみたいっていう日本人エンジニアがいたら、①と②には注意してマインドセット変えた方がいいと思うよね、っていう老婆心ながら言いたいかな。

個人的な観測範囲でと前提するが特に②はヤバい、酒でべろんべろんになってたって絶対口が裂けてもいっちゃいけないレベル

しかしまぁどうしてもアニメ以外にコミュニケーションが取れないなら、外人ウケする奴がいい、結構外資は経験値高いんで外人も日本人も上司は40～50代プレイヤー多いから、鉄板は80～90年代のOVA系とか(攻殻とか銀英伝とか、あとGIジョーとかG1トランスフォーマーとか)はまぁ無難かな、って感じ。

MEMO:

そんな「あるあるネタ」は聞いたことないし、面接でそんな話題で雑談するほど暇ではないと思うのだが
アイスブレークの雑談ですらそんなピンポイントな話題は出さないと思われる
増田やはてブで頻出のネタを適当に入れた創作なんやろなという感じを受ける

(2026/02/01)

React開発者Dan Abramov氏の「あらゆるバグを修正するための汎用的な手法」

React開発者Dan Abramov氏の「あらゆるバグを修正するための汎用的な手法」

(2026/02/01)

ユーザベースエンジニアが組織のボトルネックを解消

ユーザベースエンジニアが組織のボトルネックを解消 - Agile Journey

要約:

■ 1. 背景と課題

組織拡大に伴う意思決定のボトルネック:

開発タスクは回るが予算や採用などの経営判断はCTOに集中

承認待ちの発生により組織運営の停滞が発生

2019年頃のプロダクトチーム拡大期に課題が顕在化

■ 2. 経営チームという解決策

仕組みの概要:

CTOが担っていた責務を複数チームに分割

各チームへ意思決定に必要な裁量を委譲

特定個人の承認待ちを回避し素早い意思決定を実現

リーダー職と経営タスクの分離:

リーダーにならずとも経営タスクへの参加を可能に

柔軟な参加と離脱を実現

個人の状況に応じた関わり方を許容

■ 3. 権限委譲の方法

全権委譲の方針:

段階的ではなく担当領域全てを委譲

採用チームなら採用領域全て、コンピテンシーチームなら評価基準全てを担当

サポート体制:

初期は領域を知る人物が伴走

一定期間後にチームへ完全移行

迷った際の相談体制を維持

全権委譲の意図:

部分的委譲では全体感の把握が困難

ボトルネック解消の実効性確保

■ 4. 経営チームの構成と運営

経営と運営の分離:

経営チームは「何をやるか」の設計と意思決定を担当

日々の実務オペレーションは担当外

本業である開発への影響を最小化

チーム構成:

現在13チームが存在（承認、採用、新卒採用、ブランディング、コンピテンシー、kickoff-techforum、メンタルヘルス、360FB & 個人OKR、オンボーディング、構造化面接、原則、ブルー、戦略担当）

各チーム2〜4人のメンバーで構成

状況に応じて新設や統廃合を実施

メンバーの流動性:

6〜12カ月に平均1〜2回のシャッフル

別チームへの移動や開発集中のための離脱が可能

掛け持ちやスカウトも許容

経営チーム活動は週2時間までを目安に設定

■ 5. エンジニアが兼任する理由

組織文化との整合性:

ユーザベースの「34の約束」における「自己規律」の重視

自分たちで考え判断し行動する文化

XPの価値観:

現場に近い人間による意思決定

小さく試してフィードバックを素早く回す考え方

実態に即した判断:

開発現場のコンテキストを深く理解した上での判断が可能

エンジニアの実情に即した無理のない意思決定を実現

■ 6. エンジニア個人へのメリット

小さく始めるトレーニング:

正解不明な状況での意思決定力を養成

フィードバックサイクルを速く回す考え方は開発と共通

より高い不確実性下での判断訓練の機会

視座と意識の変化:

組織全体を考える時間の確保

違和感への対処意識の向上

チームや組織全体にプラスとなる振る舞いへの意識醸成

■ 7. 事例1: 採用チーム

課題:

指名受託率の低下

採用基準のメンバー間でのブレ

解決策としてのドラフトコーチ導入:

組織理解が深く経験豊富なメンバーがコーチ役を担当

指名判断前の必須相談プロセスを追加

成果:

判断基準の学習機会の提供

言語化プロセスによる情報整理と判断の明確化

メンバーの心理的負担軽減と質の向上

当事者としての関与:

課題発見から改善実施までを自ら担当

仕組みとしての課題解決によるやりがい

■ 8. 事例2: 構造化面接チーム

目的:

面接評価のブレ軽減

構造化面接アプローチの導入

段階的導入戦略:

正社員面接への導入決定

一次面接のみでの実施

ひとつの設問に限定

スピード重視の意思決定:

小さくリリースして早期フィードバック取得

定例ミーティングでの背景説明と質疑応答

意思決定の透明性確保:

背景共有による納得感の醸成

建設的な提案を引き出す効果

■ 9. カオスCTOによる実証

取り組み内容:

2025年1〜3月の3カ月間CTOが経営業務から離脱

CTO業務は原則として他メンバーへ委譲

必須業務のみCTOが対応

結果:

メンバーの反応は落ち着いており大きな問題なく進行

採用活動や評価基準改定などが自律的に実施

組織のボトルネック可視化の負荷テストとして機能

組織強度の実証:

経営チームによる自律的な経営タスク遂行を確認

■ 10. 自己組織化の追求

自由と責任の考え方:

技術選定やプロジェクト進め方への大きな裁量（自由）の付与

成果創出と組織健全性維持という責任とセット

経営チーム参加の位置付け:

やらされる仕事ではなく自由を守るための活動

エンジニアとしての責任を果たす重要な取り組み

自己組織化の定義:

自らの手で組織ボトルネックを解消

最高のパフォーマンスを発揮できる環境の自律的構築

(2026/01/31)

PostgreSQL を拡張して8億人の ChatGPT ユーザーに対応

PostgreSQL を拡張して8億人の ChatGPT ユーザーに対応 | OpenAI

要約:

■ 1. 背景と概要

PostgreSQLはChatGPTやOpenAIのAPIなどの中核製品を支える最も重要な基盤データシステムの一つである

ユーザーベースが急速に拡大するにつれてデータベースへの要求も指数関数的に増加している

この1年でPostgreSQLの負荷は10倍以上増加しており現在も急速に増え続けている

PostgreSQLはこれまで考えられていたよりもはるかに大きな読み取り中心のワークロードを確実にサポートできるように拡張できる

単一のプライマリAzure PostgreSQLフレキシブルサーバーインスタンスと世界中の複数のリージョンに分散された約50のリードレプリカを使用して大規模なグローバルトラフィックをサポートしている

厳密な最適化と確固たるエンジニアリングを通じて8億人のユーザー向けに毎秒数百万件のクエリをサポートするに至った

■ 2. 当初の設計の欠陥と課題

ChatGPTの公開後トラフィックはこれまでにない速度で増加した

アプリケーション層とPostgreSQLデータベース層の両方で広範な最適化を迅速に実装した

インスタンスサイズを増やしてスケールアップしさらにリードレプリカを追加してスケールアウトした

単一のプライマリアーキテクチャがOpenAIの規模の要求を満たすことができるというのは驚くべきことである

実際にこれを実現するのは簡単ではない

Postgresの過負荷によるSEVを複数確認しておりその多くは同じパターンに従っている:

上流の問題がデータベース負荷の急激な増加を引き起こす

キャッシュ層の障害による広範なキャッシュミス

CPUを飽和させる高コストなマルチウェイ結合の急増

新機能リリースに伴う書き込み集中

リソース使用率が上昇するとクエリの遅延が増加しリクエストがタイムアウトし始める

再試行によって負荷がさらに増大し悪循環を引き起こす

ChatGPTとAPIサービス全体の性能を低下させる可能性がある

PostgreSQLは読み込みが多いワークロードに対してはスケーラビリティが高い

書き込みトラフィックが多い時期には依然として課題がある:

PostgreSQLのマルチバージョン同時実行制御（MVCC）の実装によるもので書き込みが多いワークロードに対しては効率が低下する

クエリがタプルや単一のフィールドを更新する際には新しいバージョンを作成するために行全体がコピーされる

書き込み負荷が高い状況下では深刻な書き込み増幅を引き起こす

クエリが最新のデータを取得するために複数のタプルバージョンをスキャンしなければならないため読み取り増幅も増大する

MVCCはさらにテーブルやインデックスの肥大化インデックスメンテナンスのオーバーヘッド増加複雑なautovacuumのチューニングといった課題をもたらす

■ 3. 全体的な戦略

書き込み負荷を軽減するためシャード化可能な書き込み集約型ワークロードをAzure Cosmos DBなどのシャード化システムへ移行し続けている

アプリケーションロジックを最適化し不要な書き込みを最小限に抑えている

現行のPostgreSQLデプロイメントへの新規テーブル追加は許可していない

新しいワークロードはデフォルトでシャードシステムに設定される

インフラが進化してきたにもかかわらずPostgreSQLはシャーディングされず単一のプライマリインスタンスがすべての書き込みを処理している

主な理由:

既存のアプリケーションのワークロードをシャーディングすることは非常に複雑で時間がかかる

数百のアプリケーションエンドポイントの変更が必要となる

数か月場合によっては数年かかる可能性がある

ワークロードは主に読み取り中心であり広範な最適化を実装している

現在のアーキテクチャでも継続的なトラフィック増加を支えるのに十分な余力がある

将来的にPostgreSQLのシャーディングを行う可能性を排除しているわけではない

現在および今後の成長に対して十分な余裕があるため短期的な優先事項ではない

■ 4. プライマリの負荷軽減

課題:

ライターが1つのみのため単一プライマリ構成では書き込みを拡張できない

書き込みの急増が発生するとプライマリノードが瞬時に過負荷状態となる

ChatGPTやAPIなどのサービスに影響を及ぼす

解決策:

書き込みの急増に対応できる十分な容量を確保するためプライマリノードへの負荷を可能な限り最小化する

読み取りトラフィックは可能な限りレプリカにオフロードする

一部の読み取りクエリは書き込みトランザクションの一部であるためプライマリに残す必要がある

それらについては効率性を確保し低速のクエリを回避することに注力する

書き込みトラフィックに関してはシャード化可能で書き込み負荷の高いワークロードをAzure CosmosDBなどのシャード化されたシステムに移行した

シャーディングが難しいのに書き込み量が多いワークロードは移行に時間がかかりそのプロセスは現在も進行中である

書き込み負荷を減らすためにアプリケーションを積極的に最適化した

冗長な書き込みを引き起こしていたアプリケーションのバグを修正した

適切な場合には遅延書き込みを導入してトラフィックの急増を緩和した

テーブルフィールドをバックフィルする際には過剰な書き込み負荷を防ぐために厳格なレート制限を設けている

■ 5. クエリの最適化

課題:

PostgreSQLでコストのかかるクエリをいくつか特定した

過去にはこれらのクエリの処理量が急増すると大量のCPUリソースを消費した

ChatGPTとAPIリクエストの両方の速度が低下していた

解決策:

多くのテーブルを結合するような高コストなクエリが少数存在するだけでサービス全体のパフォーマンスが著しく低下したり最悪の場合は停止することがある

PostgreSQLクエリを継続的に最適化し効率を確保して一般的なオンライントランザクション処理（OLTP）のアンチパターンを回避する必要がある

12個のテーブルを結合する非常にコストのかかるクエリを特定した

このクエリの急増が過去に重大度の高いSEVの原因となっていた

可能な限り複雑なマルチテーブル結合は避けるべきである

結合が必要な場合はクエリを分解することを検討し複雑な結合ロジックは代わりにアプリケーション層へ移すようにした

これらの問題のあるクエリの多くはオブジェクトリレーショナルマッピング（ORM）フレームワークによって生成される

生成されたSQLを注意深く確認し期待通りに動作することを確認することが重要である

PostgreSQLでは長時間アイドル状態のクエリが見つかることも一般的である

idle_in_transaction_session_timeoutのようなタイムアウトを設定することはautovacuumのブロックを防ぐために不可欠である

■ 6. 単一障害点の軽減

課題:

読み取りレプリカがダウンした場合でもトラフィックは他のレプリカにルーティングされる

単一のライターに依存するということは単一障害点が存在することを意味する

そのライターがダウンするとサービス全体が影響を受ける

解決策:

最も重要なリクエストには読み取りクエリのみが関係する

プライマリにおける単一障害点を軽減するためにこれらの読み取りをライターからレプリカにオフロードした

プライマリがダウンした場合でもこれらのリクエストが引き続き処理されるようにした

書き込み操作は引き続き失敗するが影響は軽減されている

読み取りは利用可能なままのためSEV0ではなくなる

プライマリの障害を軽減するためにプライマリは高可用性（HA）モードでホットスタンバイと共に運用している

ホットスタンバイは常に同期されているレプリカでいつでもトラフィックの処理を引き継ぐ準備ができている

プライマリがダウンしたりメンテナンスのためにオフラインにする必要がある場合はスタンバイをすぐに昇格させてダウンタイムを最小限に抑えることができる

Azure PostgreSQLチームは非常に高い負荷がかかってもこれらのフェイルオーバーの安全性と信頼性を確保するために多大な努力を払ってきた

リードレプリカの障害に対処するため各リージョンに十分な余裕を持たせて複数のレプリカを配置している

単一のレプリカ障害がリージョン全体の障害につながらないようにしている

■ 7. ワークロードの分離

課題:

PostgreSQLインスタンスにおいて特定のリクエストがリソースを過剰に消費する状況が頻繁に発生する

同じインスタンス上で実行されている他のワークロードのパフォーマンスが低下する可能性がある

新しい機能の導入によりPostgreSQLのCPUを多く消費する非効率なクエリが発生し他の重要な機能のリクエストが遅くなることがある

解決策:

ノイジーネイバー問題を緩和するためワークロードを専有インスタンスに分離する

リソース集約的なリクエストの急増が他のトラフィックに影響しないようにする

リクエストを低優先度と高優先度の層に分けそれぞれを別のインスタンスに振り分ける

優先度の低いワークロードがリソースを大量に消費する状態になっても優先度の高いリクエストのパフォーマンスが低下することはない

異なる製品やサービス間でも同様の戦略を適用する

ある製品での活動が別の製品のパフォーマンスや信頼性に影響を与えないようにしている

■ 8. 接続プール

課題:

各インスタンスには最大接続数制限（Azure PostgreSQLでは5000）がある

接続が不足したりアイドル状態の接続が過剰に蓄積したりしやすい状況である

過去には接続ストームにより利用可能な接続が全て枯渇する事象が発生した

解決策:

データベース接続をプールするためにプロキシレイヤーとしてPgBouncerを導入した

ステートメントまたはトランザクションプールモードで実行することで接続を効率的に再利用できアクティブなクライアント接続数を大幅に削減できる

接続設定の遅延も短縮されベンチマークでは平均接続時間が50ミリ秒から5ミリ秒に低下した

リージョン間の接続やリクエストはコストがかかるためプロキシクライアントレプリカを同一リージョンに配置している

ネットワークオーバーヘッドと接続使用時間を最小限に抑えている

PgBouncerは慎重に設定する必要がある

アイドルタイムアウトのような設定は接続の枯渇を防ぐために非常に重要である

各リードレプリカは複数のPgBouncerポッドを実行する独自のKubernetesデプロイメントを保持している

同じKubernetesサービスの背後で複数のKubernetesデプロイメントを実行しポッド間でトラフィックの負荷を分散する

■ 9. キャッシュ

課題:

キャッシュミスの急増によりPostgreSQLデータベースの読み取りが急増しCPUが飽和状態になりユーザーリクエストが遅くなる可能性がある

解決策:

PostgreSQLへの読み込み負荷を軽減するためにキャッシュ層を使用して大部分の読み込みトラフィックを処理する

キャッシュヒット率が予期せず低下した場合キャッシュミスが急増することで大量のリクエストがPostgreSQLに直接押し寄せることがある

データベースの読み取りが急増するとかなりのリソースを消費しサービスの速度が低下する

キャッシュミス集中時の過負荷を防ぐため特定のキーでミスした読み取りプロセスがPostgreSQLからデータを取得するのは1つだけとなるようキャッシュロック（およびリース）機構を実装している

複数のリクエストが同一キャッシュキーでミスした場合1つのリクエストのみがロックを取得しデータ取得とキャッシュ再構築を実行する

他のすべてのリクエストはPostgreSQLに一斉にアクセスするのではなくキャッシュが更新されるのを待つ

これにより冗長なデータベースの読み取りが大幅に減少し連鎖的な負荷の急増からシステムを保護する

■ 10. リードレプリカの拡張

課題:

プライマリはすべてのリードレプリカにログ先行書き込み（WAL）データを書き込む

レプリカ数が増加するにつれてプライマリはより多くのインスタンスにWALを送信する必要がある

ネットワーク帯域幅とCPUの両方に負荷がかかる

これによりレプリカの遅延がより高く不安定になりシステムを信頼性高く拡張することが難しくなる

解決策:

遅延を最小限に抑えるため複数の地理的リージョンにわたり約50のリードレプリカを運用している

現在のアーキテクチャではプライマリはすべてのレプリカにWALをストリーミングする必要がある

現時点では非常に大規模なインスタンスタイプと高ネットワーク帯域幅で適切に拡張できる

プライマリに過負荷をかけずにレプリカを無期限に追加し続けることはできない

この問題を解決するためにAzure PostgreSQLチームと協力して中間レプリカがWALを下流レプリカに中継するカスケードレプリケーションを導入している

このアプローチによりプライマリに負担をかけずに潜在的に100以上のレプリカに拡張できる

しかしこれにより運用上の複雑さが増し特にフェイルオーバー管理において顕著になる

この機能はまだテスト中である

本番環境に展開する前に堅牢性と安全なフェイルオーバーが可能であることを確認予定である

■ 11. レート制限

課題:

特定のエンドポイントでの突然のトラフィック急増高コストなクエリの急増またはリトライストームにより重要なリソースが急速に枯渇する

CPU、I/O、接続などのリソースが枯渇し広範囲にわたるサービスの劣化を引き起こすことがある

解決策:

突然のトラフィックの急増によってデータベースインスタンスが過負荷になり連鎖的な障害が発生するのを防ぐためアプリケーションコネクションプーラープロキシクエリの複数のレイヤーにわたってレート制限を実装した

リトライ間隔が短すぎるとリトライストームを引き起こす可能性があるためこれを避けることも極めて重要である

レート制限をサポートし必要に応じて特定のクエリダイジェストを完全にブロックできるようORMレイヤーを強化した

この的を絞った負荷遮断により高コストなクエリの急増から迅速に復旧することができる

■ 12. スキーマ管理

課題:

列の型変更といった小さなスキーマ変更でもテーブル全体の書き換えを引き起こす可能性がある

スキーマ変更は慎重に適用し軽量な操作に限定するとともにテーブル全体を書き換える変更は避ける必要がある

解決策:

特定の列の追加や削除などテーブル全体の書き換えを引き起こさない軽量なスキーマ変更のみを許可する

スキーマ変更には厳格に5秒のタイムアウトを設けている

インデックスの作成と削除は同時に行うことができる

スキーマの変更は既存のテーブルに限定されている

新機能に追加のテーブルが必要な場合それらはPostgreSQLではなくAzure CosmosDBなどの代替シャーディングシステムに配置する必要がある

テーブルフィールドをバックフィルする際には書き込みの急増を防ぐために厳格なレート制限を適用する

このプロセスは時には1週間以上かかることがあるが安定性を確保し本番環境への影響を避けることができる

■ 13. 結果と今後の道筋

達成した成果:

適切な設計と最適化によりAzure PostgreSQLが最大規模の本番ワークロードに対応できるよう拡張できることを実証した

PostgreSQLは読み込み中心のワークロードで数百万QPSを処理している

ChatGPTやAPIプラットフォームなどOpenAIの最も重要な製品を支えている

レプリケーション遅延をほぼゼロに保ちながら約50のリードレプリカを追加した

地理的に分散したリージョン間で低遅延の読み取りを維持している

将来の成長を支える十分なキャパシティの余裕を確保した

遅延を最小限に抑えながら信頼性を向上させる形で機能している

本番環境ではクライアント側のレイテンシの99パーセンタイルを常に2桁ミリ秒台前半で維持している

99.999%の可用性を実現している

過去12か月間で発生したPostgreSQLの重大障害（SEV-0）は1件のみであった（ChatGPT ImageGenのバイラルローンチ時に発生し1週間で1億人以上の新規ユーザーが登録し書き込みトラフィックが10倍以上に急増した）

今後の取り組み:

PostgreSQLがこれまで当社を支えてくれたことには満足している

将来の成長に向けて十分な運営余力を確保できるよう引き続きその限界に挑戦していく

既にシャード可能な書き込み集約型ワークロードはCosmosDBなどのシャード化されたシステムへ移行済みである

残っている書き込み負荷の高いワークロードはシャーディングがより難しいためPostgreSQLのプライマリからの書き込みをさらに軽減すべくそれらについても積極的に移行を進めている

Azureと協力してカスケードレプリケーションを有効化しより多くのリードレプリカを安全に拡張できるようにしている

インフラストラクチャの需要が拡大し続けるにつれてシャード化されたPostgreSQLや代替の分散システムなどさらなる拡張のための追加のアプローチを模索し続けていく

8億人が使うChatGPTを支えるPostgreSQLのスケーリング戦略

8億人が使うChatGPTを支えるPostgreSQLのスケーリング戦略

MEMO:

RDBで扱うデータを限定（厳選）するのは大事
Cache Lockingはどうやって実現しているのだろうか？
アプリケーション側で制御しているのだろうか

(2026/01/30)

ディベート「現代開発にオブジェクト指向はまだ必要か」

ディベート「現代開発にオブジェクト指向はまだ必要か」 #プログラミング - Qiita

MEMO:

これは流石に議論の質が低いような

(2026/01/30)

型で保証する Go のバリデーション：go-validated で「検証済み」を型に刻む

型で保証する Go のバリデーション：go-validated で「検証済み」を型に刻む

MEMO:

Always-Valid Domain Modelを作るライブラリという感じか

(2026/01/30)

「OpenSSL」にリモートコード実行などの恐れ～修正版がリリース

「OpenSSL」にリモートコード実行などの恐れ～修正版がリリース - 窓の杜

SSL/TLSプロトコルを実装したオープンソースライブラリ「OpenSSL」が、1月27日にアップデートされた。複数の脆弱性が修正されているので注意が必要だ。

今回のリリースで修正された脆弱性は、以下の12件（括弧内は深刻度の評価）。

CVE-2025-11187：PBMAC1パラメーターの不適切な検証が原因でコードが実行される。v3.6 / v3.5 / v3.4系統のみに影響（Moderate）

CVE-2025-15467：CMS AuthEnvelopedDataメッセージの解析でスタックバッファオーバーフローが発生し、DoSやリモートコード実行が引き起こされる。v3.6 / v3.5 / v3.4 / v3.3 / v3.0系統のみに影響（High）

CVE-2025-15468：不明な暗号スイートを受信するとDoSが発生する。v3.6 / v3.5 / v3.4 / v3.3系統のみに影響（Low）

CVE-2025-15469：ワンショット署名アルゴリズムを使用する際の整合性ギャップ。v3.6系統のみに影響。v3.6 / v3.5系統のみに影響（Low）

CVE-2025-66199：証明書の圧縮を使用するTLS 1.3接続でサービスの低下やリソース枯渇（DoS）が引き起こされる。v3.6 / v3.5 / v3.4 / v3.3系統のみに影響（Low）

CVE-2025-68160：BIO_f_linebufferの範囲外書き込みによるDoS（Low）

CVE-2025-69418：低レベルの OCB 関数呼び出しによるデータの読み取りや改竄。v3.6 / v3.5 / v3.4 / v3.3 / v3.0 / v1.1系統のみに影響（Low）

CVE-2025-69419：PKCS12_get_friendlyname()におけるUTF-8変換の範囲外書き込みによりDoSなどが発生する。v3.6 / v3.5 / v3.4 / v3.3 / v3.0 / v1.1系統のみに影響（Low）

CVE-2025-69420：TimeStamp Response検証コードの型混乱によるDoS。v3.6 / v3.5 / v3.4 / v3.3 / v3.0 / v1.1系統のみに影響（Low）

CVE-2025-69421：PKCS12_item_decrypt_d2i_ex関数におけるNULLポインター参照によるDoS（Low）

CVE-2026-22795：PKCS#12ファイルの処理で発生するNULLポインター参照によるDoS。v3.6 / v3.5 / v3.4 / v3.3 / v3.0 / v1.1系統のみに影響（Low）

CVE-2026-22796：PKCS7_digest_from_attributes()関数における型混乱によるDoS（Low）

開発チームは、以下のバージョンへのアップデートを推奨している。

3.6.1

3.5.5

3.4.4

3.3.6

3.0.19

MEMO:

最近のOpenSSLの評判を考えると不安感あるな

シンプルを極める。アンチパターンなDB設計の本質

シンプルを極める。アンチパターンなDB設計の本質 - Speaker Deck

(2026/01/30)

Facilo（ファシロ）の設計思想｜シングルDB・削除フラグなし・Devin導入

Facilo（ファシロ）の設計思想｜シングルDB・削除フラグなし・Devin導入 - はてなニュース

要約:

■ 1. Faciloの事業とプロダクトの現状

Faciloは不動産仲介における煩雑な業務や顧客とのコミュニケーションを一元化可視化するSaaSを提供している

不動産仲介というマーケットは非常に複雑である:

複数の関係者が絡む

取引が同時並行で進む

営業担当者は物件情報をPDF化してメールやLINEで送り内見調整の電話をする

プロダクト導入により業務が改善され仲介営業としての自信がついたという声がある

毎朝仕事を始めるときにOutlookと一緒にFaciloを立ち上げる光景が当たり前になりつつある

業務に深く根付いてきている手応えを感じている

■ 2. マルチプロダクト戦略への転換

資金調達の際に思い描いていたプロダクトは二つのみであった:

Facilo物件購入クラウド（祖業で一番最初に作ったプロダクト）

Facilo物件売却クラウド（購入と表裏一体の売却を支援）

当初は長らく一点突破型で走ってきた

現在はFacilo賃貸仲介クラウドとFacilo事業用クラウドが加わり4つのプロダクトを擁するマルチプロダクトなプラットフォームビジネスになっている

マルチプロダクト戦略を最初から戦略として目的化したことは一度もない

スタートアップとしてはやるべきことを絞るべきだという考え方がありマルチプロダクトに対してはアンチパターンという捉え方であった

現在はマルチプロダクト化に振り切っている:

物件購入クラウドの導入が進み顧客との接点が増えた

このペインも解けるかもしれないという課題の解像度が一気に上がってきた

顧客課題の詳細:

不動産仲介の会社は売買と賃貸の両方を手がけているケースが多い

売買の二つのプロダクトのコンセプトや技術力を評価されながらもドメインがずれている賃貸には対応できなかった

賃貸でも使いたいという声をたくさんいただき賃貸仲介クラウドをリリースした

店舗やビルやオフィスといった事業用の不動産でもプロダクトを使いたいという声をいただき事業用クラウドが生まれた

現場の声に対応していった結果である

フェーズの推移:

フェーズ1:物件購入クラウドに集中する一点突破の期間

フェーズ2:顧客の声に沿ってマルチプロダクト化していった期間

フェーズ3:より戦略的にプロダクト間をつなげて複合的な課題を解決していく構想

段階を経てマルチプロダクト戦略になっていったがそれはあくまでも手段である

■ 3. マルチプロダクト化を支える技術的準備

CTOの梅林はいつかはマルチプロダクトになっていくんだろうなという思いが創業時からあった:

バーティカルSaaSにとってマルチプロダクト戦略でいろいろなプロダクトを作っていくことはベストプラクティスである

プロダクトが増えるタイミングで人構成運用が一気に複雑化しがちである

そこに耐えられる共通の型を先につくっておく必要がある

もしそうなったときに開発スピードが落ちる構成だけは絶対に避けたいとずっと考えてきた

Ruby on Railsというフレームワークを選んだ理由:

誰が触っても同じ構造ですぐに次を作れることを重視した

創業時としては最適な技術選定であった

Railsのメリット:

普通の会社ではオンボーディングした新しいエンジニアが最初にリリースをするまでには早くても1週間程度かかる

Faciloではライトなチケットであればオンボーディング初日にリリースができるくらい手軽である

ローカル開発環境のセットアップが非常に単純化されている

インフラもシンプルに保たれている

■ 4. シングルデータベース設計

教科書的な設計であればプロダクトごとにデータベースを構築するのが当たり前である

Faciloではデータベースは一つである:

物理的にはシングルデータベースクラスタで複数のプロダクトを運用している

論理的にネームスペースをプロダクトごとに分けている

スケーリング戦略:

データベースはまず縦にスケールさせる戦略を取っている

10年前20年前のインフラであれば一つのサイズを大きくするにも一定の限界があったため横にスケールさせる戦略しか取れなかった

現在のデータベースの性能は昔に比べてはるかにアップしている

サイズ自体を限界まで大きくしたいと考えている

BtoBのサービスがメインで数千万ユーザーを相手にするような大規模なBtoCサービスとは前提が異なる

保守運用体制:

この人じゃないと管理できないというような属人化しやすい専門の人を作らないようにしたい

FaciloにはSREもいない

エンジニア全員にインフラやCI/CDパイプラインの流れを理解してほしいと考えている

ソフトウェア開発とSREというように組織を分けてインフラ側がバックエンドエンジニアがインフラのことを何も気にせずに触れるような環境を作ったよとやってしまうとブラックボックス化してしまう

バックエンドエンジニアがインフラのことを常に理解しその上でいかに監視コストを減らしていくかを考えるべきである

■ 5. 外部キー制約と削除フラグを設けない設計

Faciloでは外部キー制約を設けていない

重視しているのは認知コストを下げることとスケールしにくい書き込み処理をできるだけ早くすることである

銀行のシステムのように整合性が非常に大切なドメインであればトランザクションをしっかり組みデータベースの整合性を厳密に管理すべきである

削除フラグの問題:

とりあえず入れてしまうとこのテーブルには削除フラグがあるかこのクエリでは考慮が必要かといった判断があらゆる場所で発生する

開発時の認知コストがどんどん上がってしまう

Faciloの場合はそもそもなぜ削除フラグが必要なのかから考える:

誤操作から復元したいのであればまず誤操作が起きにくいUXにする

それでも誤操作が起きるとしたら年に何件なのかその確率と設計の複雑さのトレードオフで考える

実は削除フラグではなく更新履歴として違うものをつくるべきかもしれない

問題の本質を常に考えながら設計が開発効率に与える影響を吟味している

復元が必要なケースについても今のAI時代はCloudWatchのログをAIエージェントにgrepさせることで人力でも十分対応できる

■ 6. ベストプラクティスを前提にしない設計思想

組織設計にしろデータベース設計にしろ教科書的にはアンチパターンとされる手法を選択している

ベストプラクティス自体は過去の経験や教科書を通して一通り学んできた

Faciloのビジネスや規模を前提に考えると本当にそこまで必要なのかを毎回問い直している

教科書的には正しいとされる構成でも運用や組織まで含めて見るとかえって複雑さを招くこともある

過去の大きな組織での経験:

インフラが強く抽象化され過ぎていて裏側で何が起きているのか分からないことに強い違和感を持った

本来は開発しやすくなるはずの仕組みなのに実際にはインフラエンジニアへの問い合わせが増え承認フローもどんどん複雑になっていく

開発側も運用側も幸せになっていないのではないかと思った

インフラとアプリケーションは密接に結びついている:

バックエンドエンジニア自身がインフラを理解し自分の操作とシステムの挙動が結びつく手触り感を持った方が自然である

技術選定の判断:

一見すると何も知らないエンジニアが作った構成に見えるかもしれない

ベストプラクティスとしてある分散構成やハイパフォーマンスなシステム構築をすぐに候補から外したわけではない

Redisを使えばキャッシュやセッション管理やキューなどを高い性能で処理できる

その性能がオーバーエンジニアリングではないのかと期待されるスループット量から逆算しどの程度ちゃんと作るべきなのかを常に見極めている

そうした判断の積み重ねがシステムと組織のスケーラビリティを支えるシンプルさにつながっている

組織設計への適用:

エンジニア職種が20人程度という今の規模であれば横断組織を作るよりもチームを小さく保ち全員が同じ設計思想を共有している方がスピードを落とさずに済む

エンジニアだけで100人200人を超えたり世界中で分散して開発を進めているような組織であれば縦割りにしたり横断組織を作ったりする必要がある

組織構造のベストプラクティスも理解しているがそれがどんな規模の企業での前提で語られているのかを見た上で現在のFaciloにとって本当に必要かどうかを見ている

■ 7. カルチャーとしての手触り感

会社として大事にしていることとエンジニア組織の考え方がきれいにリンクしている

二つの重要な要素:

手段と目的を逆転させないこと:

目的はクライアント企業の課題解決や事業成長である

そのためにプロダクトがあり技術がある

この順番を組織全体で共有している

モノ作りが好きでそのプロダクトを通してお客さまやその接点となるカスタマーサクセスやセールスにありがとうと言ってもらえる手触り感が好きというカルチャーが会社全体に共通している

定石を理解した上であえて型を外すという姿勢:

一見するとセオリーから外れているように見える部分も基礎を押さえた上で事業や組織にとって最適だと考えて選んでいる

エンジニアに限らずセールスやカスタマーサクセスなど全職種に共通する考え方である

型を破る判断基準:

常に型を破ることが目的ではない

アプリケーションのコード自体はRailsのレールに乗って定石通りに作る

インフラやDB設計はビジネスの速度を優先してあえて定石を外す

どこは定石通りに作りどこであえて外すかを常に見極めている

Railsの良さを生かせる場面ではあえてサーバサイドレンダリングを採用しフレームワークの王道から外れない使い方をしている

よりインタラクティブな体験が求められる部分ではReactを使ったSPA構成を選ぶこともある

全てを最新技術で固めるのではなく標準的な作りで十分なところはシンプルにという方針で敬遠されがちなStimulusも普通に使っている

型から外れること自体を目的にしてしまうとそれもまた手段の目的化になる

急成長を支える開発スピード:

セールスやCSが現場接点の中でいただいた要望やフィードバックは1営業日以内にSlackのフォームから投稿するルールにしている

プロダクトマネージャーがチケット化してエンジニアにつなぐサイクルを通して週に10件から20件の機能をリリースしてきた

お客さまから見たことのないスピードで対応してもらえていると高く評価されている

■ 8. 全社的なAI活用の展開

2024年12月にChatGPT Proを全エンジニアに配布した:

当時シリコンバレーに住んでいた梅林が生成AIに対応しないといけないと危機感を抱いた

梅林がコードを書いたら負けと宣言し生成AIだけで開発する期間を2カ月ほど設けた

エンジニアにAIはまだ微妙でしょという意識があるとAIの能力を過小評価したままコードを書き続けてしまいAIフレンドリーになれない

AIをしっかり信頼し一度エディタを捨ててみようと提案して開発してもらった

AI自体の進化もあるがみんながAIをどう活用すべきかを真剣に考えるようになり開発組織においてはAIが相棒のようになってきた

2025年2月に標準ツールとして全エンジニアにDevinアカウントを作成し段階的に全社員へ活用範囲を広げた

最初は試行錯誤であったがこの数カ月で実運用に耐えるレベルまで安定してきた

組織としてのAI活用の3段階:

第1段階:エンジニアの開発での活用:

各自が最適な使い方を見出した

開発生産性は体感で3倍ほどに向上した

第2段階:PdM業務への展開:

エンジニアがPdMでも自然言語で安全に開発できる環境を整えた

PdM自身が自分でできるかどうかを判断し軽微な修正であれば自ら実装からデプロイまで行うようになっている

第3段階:セールスやCSへの展開:

仕様確認や簡単な分析をSlack上で自然言語で尋ねると即座に返ってくる仕組みを整えた

エンジニアへの問い合わせが減り現場のスピードが大きく向上している

単なる効率化ではなく業務の進め方や役割そのものが変わる変革レベルの変化を感じている

■ 9. AI時代のエンジニアの価値

ゼロからこういうものを作りたいという程度ならばDevinに依頼すれば作れる

要求を満たす複数の解法の中からそれぞれの善し悪しについても何度も尋ねて往復を重ねればたどり着けるがこうしたプロセス自体が大きなロスになる

エンジニア相手であれば往復の回数は絶対に減る

今までの技術の蓄積や知識を使っていかに最少のラリーで最適なものを導けるかがエンジニアに求められていく

CEO市川自身もDevinを使ってハンズオンで開発するようになっている:

エンジニアがどれだけ複雑で高度なことをさまざまなプレッシャーの中でやってくれているのかよく分かるようになった

広い視野を持って依存関係なども意識しながら課題を解いてくれている

PdMがハンズオンで開発できるようになってエンジニア不要論者になっているかというとむしろ逆でエンジニアの価値を再認識した感覚がある

■ 10. Faciloのエンジニアにとっての魅力

不動産仲介という分野が扱う住まいはあらゆる人の人生の根幹である

人口減少で多くの市場が縮小する中でも中古不動産流通など成長分野があり、なおかつデジタル化の余地が大きい希有なマーケットである

そんな市場に向かい合いながらプロダクトを通してやりがいや手触り感を得られるのはエンジニアにとっても大きな魅力である

CTOとしていかにエンジニアが快適にプロダクトの開発にコミットできるかということだけを常に考えている

その考え方は無駄なコミュニケーションを省き必要なコミュニケーションをしっかり取るという組織のあり方やインフラの思想にも表れている

AI時代になり技術選定そのものの重要性は相対的に下がってきている

Faciloではその前提に立った上でAIの活用にフルベットしている

他社と比べても非常に高い割合で活用しており今後はエンジニアの人材戦略においてもAIを使いこなせるかどうかが重要な指標になると考えている

Faciloではより先進的なAIの活用方法を学べる

(2026/01/30)

Beautiful Mermaid

Beautiful Mermaid — Mermaid Rendering, Made Beautiful

Mermaid Rendering, made beautiful.

An open source library for rendering diagrams, designed for the age of AI: beautiful-mermaid. Ultra-fast, fully themeable, and outputs to both SVG and ASCII.

Built by the team at Craft — because diagrams deserve great design too.

翻訳:

マーメイドレンダリングを美しく。

AI時代のために設計された、図表レンダリング用のオープンソースライブラリ、beautiful-mermaid。超高速で、テーマ設定も自由自在、SVGとASCIIの両方で出力できます。

Craftチームによって開発されました。図表にも素晴らしいデザインがふさわしいからです。

MEMO:

mermaidをより綺麗に出力できるってことか

(2026/01/30)

RDRAで価値を可視化する

RDRAで価値を可視化する - Speaker Deck

(2026/01/29)

RDRAモデルからFP・工数・金額につなぐ定量見積り

RDRAモデルからFP・工数・金額につなぐ定量見積り - Speaker Deck

(2026/01/29)

天才数学者「私たちの『知能』に対する考えは正確ではない。」テレンス・タオは、「LLMは...

天才数学者「私たちの『知能』に対する考えは正確ではない。」テレンス・タオは、「LLMは次の単語を予測してるだけで知的ではない」に対して、「実は人間もほぼ同じことをしているだけでは」と言う。数学を極めたタオ氏の口からこの言葉が出てくると重みがある。我々が「トリックにすぎない」と思っていたものが、実は我々自身の知能の本体で、「本物の知能」などないのかもしれない。

例えば、AIにとって完全に初見の推理小説があって、物語が進行した上で最後に探偵が「犯人の名前は...」と言う。もしAIがその次の名前を正しく言い当てられたら、それでもそれは単なるトリックだろうか。これはイリヤ・サツケバーの投げかけた問いだが、単なる「統計的オウム」としてのAIには、いささか振る舞いが知的すぎる。

現実はそれよりも奇妙なことが起きていて、「次単語予測」マシーンであるはずのAIが、推理小説どころか数学の未解決問題を解けてしまったりしている。「パターンマッチ」の極致がここまできたら、「パターンマッチだから知能ではない」ではなく、もはや我々人間の考える「知能」も結局パターンマッチと同じようなものと考える方が良いのではないか。

@K_Ishi_AI

この部分の全訳「AI全体の領域が教えてくれているのは、私たちの「知能」についての考えが実は正確ではないということです。

AIの歴史は「これは人間にしかできないタスクだ」というものでした。自然言語を読む、チェスに勝つ、数学の問題を解く、など。そして一つずつ、AIアルゴリズムがそれを達成していきました。顔認識も、音声理解もできるようになった。

でも、その仕組みを見ると「知能」には感じない。「トリックだ」と思う。ニューラルネットワークを組み合わせてアルゴリズムを動かしただけ、と。私たちは何か「本物の知的な思考」を探しているのに、実際に目標を達成するツールにはそれが見えない。

でも、それは「知能」が私たちの思っているものと違うからかもしれない。

LLM（大規模言語モデル）は特に成功していますが、やっていることの多くは「次のトークン（単語）を予測する」だけ。これは知的に聞こえない。誰かに準備なしでスピーチを即興でさせて、毎瞬間ただ頭に浮かぶ次の言葉を言うだけ、意識の流れのまま...これがうまくいくとは思えない。

でもLLMではうまくいく。そして、実は人間もかなりそうしているのかもしれない。」

@K_Ishi_AI

MEMO:

人間のヒューリスティックなふるまいや認知バイアスを考えてみれば、人間とてLLMのように連想と確率によって物事を考えていると言って差し支えないのではないか？
単にそれを「知能」と認めることを恐怖しているように感じる
「LLMには知性がない」論は「知能」に霊的で崇高な何かがあると信じたいという信仰告白に過ぎないのではないかという疑いが拭えない

(2026/01/28)

エンジニア誰もWordPress 運用したくなくて、Web系の会社なのに WordPress の運用は外注みたいな状態結構見る

エンジニア誰もWordPress 運用したくなくて、Web系の会社なのに WordPress の運用は外注みたいな状態結構見る

@mizchi

MEMO:

これはある
エンジニアがいるならWordPressはファーストチョイスにはならず、スタティックサイトジェネレータでいいじゃんに落ち着くので逆にWordPressの知見がさっぱりという状況が生まれがち
サービス/システム開発が生業の場合、WordPress案件のような単価安い仕事を請ける理由が無いので知見も無い
謎の低品質プラグインの世話もしたくないので敬遠しがち

(2026/01/28)

アーキテクチャモダナイゼーション組織とビジネスの未来を設計する

アーキテクチャモダナイゼーション組織とビジネスの未来を設計する｜ SEshop｜翔泳社の本・電子書籍通販サイト

Manning刊『Architecture Modernization』の邦訳版。

本書は、技術・組織・戦略を統合し、システムの価値を最大化する実践ガイドです。

長年運用され中身がブラックボックス化したシステムや、ドキュメントが機能せず改修のたびにリスクが伴う設計。こうした技術的負債は、現代のビジネスにおいて成長を阻む大きな壁となっています。

本書は単なるコードのリファクタリング手法ではなく、ドメイン駆動設計（DDD）やチームトポロジー、ワードレイマッピングといった定評ある手法を組み合わせ、技術・組織・戦略という3つの視点からシステムを現代的な姿へと刷新するための包括的なアプローチを解説します。

MEMO:

2/24発売

(2026/01/28)

データモデルのイベントの期間の設計のコツ

データモデルのイベントの期間の設計のコツ - そーだいなるらくがき帳

要約:

■ 1. 一般的なイベント期間のテーブル設計

アプリケーション開発で期間を表すデータを扱うことは珍しくない

イベントの開催時間やタスクの予定時間などが該当する

一般的なテーブル設計は開始時間と終了時間をそれぞれstart_atとend_atカラムで保存する

この設計はAIが一発で提案するほど一般的である

■ 2. 一つのテーブルに期間を持つ場合の適用範囲

一つのテーブルに開始時間と終了時間の両方を持つ設計は期間が明確に定義されている場合には有効である

開始時間と終了時間がともに必ず存在し必ず終了することが保証されている場合に適している

イベントの開催時間は必ず開始時間と終了時間が存在しイベントが終了することが保証されている

イベントの属性として期間を持つことは自然である

■ 3. 終了時間が不明確な場合の問題

終了時間が開始時に決まっていない場合や終了しない場合もある:

タスクの予定時間はタスクが完了するまでの時間が開始時に決まっていないことが多い

有効期間のようなもので終了時間を決めずに無期限にする場合もある

このような場合はend_atをNULLとして登録する設計になる:

taskにデータを登録するタイミングではend_atにはNULLが登録される

終了時間が確定したタイミングでend_atにUPDATEで値を設定する

無期限の場合はNULLをそのまま設定する

この設計は一見問題なさそうに見えるが実際にはいくつかの問題がある

■ 4. キャンセル仕様追加時の設計問題

タスクのキャンセルを表現させたい場合の課題:

end_atにキャンセル日時を設定すると理由がわからない

キャンセルを表現するためにstatusカラムを追加することが考えられる

status='canceled'のときはキャンセルでありstatus='closed'のときは正常終了である

最もやってはいけない設計:

canceled_atカラムを追加すること

end_atとcanceled_atの両方に値が入る可能性がある

逆にどちらかにしかデータが無い場合が発生する

集計クエリが破綻しどちらが正しい終了時間なのかがわからなくなる

■ 5. statusカラムの制限事項

statusカラムは最新のデータしか持てない

失敗から学ぶRDBの正しい歩き方の「失われた事実」で説明されている

キャンセル後の再オープンの問題:

キャンセルしたがリオープンしたい場合はステータスをcanceledからopenにUPDATEしend_atをNULLに戻す

過去にキャンセルされた事実が失われてしまう

statusカラムがなくても一回クローズしたタスクを再度オープンする場合も同様である

このユースケースはGithubのIssueやPull Requestでもよくあり想定する必要がある

解決策:

ステータスのhistoryテーブルを別に持つ必要がある

statusカラムは履歴の最新の状態を非正規化で持っていることと同義になる

更新漏れや不整合が起きるリスクを常に抱える

historyテーブルの最新行を現在のステータスとして参照する設計に変えることもできる

status_historyテーブルにステータス変更の日時をもたせた方が良い

■ 6. イベントテーブル分割による設計改善

start_atとend_atを持たせて期間として扱うという前提自体を疑う必要がある

テーブルのステータスに依存関係がある場合:

下書き→承認→公開のようなワークフローがある場合

ステータスの順番に制約を持たせたい場合もある

イベントごとのテーブル分割設計:

tasksテーブル（基本情報）

task_draft_eventsテーブル（下書きイベント）

task_approve_eventsテーブル（承認イベント。draft_event_idを参照しtask_idで必ずユニークになるように制約）

task_close_eventsテーブル（クローズイベント。statusでclosedまたはcanceledを区別）

この設計の利点:

特定のステータスの順番に制約を持たせることができる

taskテーブルにstart_atとend_atを持たせる設計だとステータスの順番に制約を持たせることが出来ない

データの整合性が保てなくなる

■ 7. 設計の推奨アプローチ

期間を表すデータをテーブルに持たせる場合の注意点:

開始時間と終了時間の両方を持たせる設計は一般的である

終了時間が不明確な場合や状態遷移がある場合には注意が必要である

終了時間カラムや範囲をもたせるときにNULLを許容する場合:

まず一度立ち止まる

そもそも期間として設計することが適切かどうかを検討する

多くの場合の最適解:

深ぼるとテーブルを分割した方が良いケースが多い

結果としてデータの整合性が保たれる

クエリもシンプルになることが多い

テーブル分割の検討方法:

期間の対象となるイベントやリソースに対してどのような状態があるのかを洗い出す

状態ごとにイベントテーブルを分割することを検討する

まずは細かく分けて設計する

その後に必要に応じて物理設計の際にパフォーマンスなどと比較しながら統合を検討する

■ 8. 時間枠の集計の難しさ

テーブルを分割してもしなくても時間枠の集計は難しい

ある期間に重複しないタスクを登録したい場合の課題:

時間枠の扱いはSQLに限らずプログラミングの題材として難易度が高い

特に重複と含有が複数のパターンの場合ロジックが複雑になりバグの温床になりやすい

リーダブルコードでも「8.5 例:複雑なロジックと格闘する」でこの問題が取り上げられている

end_atにNULLがある場合の処理:

NULLは無期限のタスクとして扱う

NULLは比較演算子で扱えないためWHEREの範囲で絞ることはできない

NULLを特定の未来日時に変換する必要がある（例:9999-12-31 23:59:59）

MySQLではIFNULL関数を使用しPostgreSQLではCOALESCE関数を使用する

実務での複雑性:

アサインされた担当別やプロジェクト別やステータス別など条件が増える

より難易度が高くなる

PostgreSQLの範囲型:

この問題を解決してくれるため強力な選択肢である

全てのDBMSでサポートされているわけではない

別の考え方が必要になる

■ 9. start/endの命名に関する考察

ClaudeもChatGPTも全てstart_atとend_atで設計することを提案する

本来の適切な命名:

期間を表す場合はfromとtoの方が適切である

beginとendの方が自然である

startならstopの方が対になる

期間を表すならfrom-toやbegin-endの方が意味が通りやすい

著者は毎回レビューなどで指摘しがちである

あまりにもstartとendが浸透している

本来は誤用だったが慣用化したと言えるかもしれない

(2026/01/28)

ソフトウェアがいずれ「使い捨てすら可能になる」は自分も賛成だけど、ここで反対論を出してる人の...

ソフトウェアがいずれ「使い捨てすら可能になる」は自分も賛成だけど、ここで反対論を出してる人の多くは例によって「今の性能の生成AIが続いたら」という仮定で話してるので議論として噛み合っていない。

この話いっつも同じパターンになるんですよね。横軸が時間で縦軸が性能だとして（ざっくり近似）、遠くない内に使い捨て可能なソフトウェアが作れるくらいAIの性能が上がるんじゃないの、てのが元の問題提起であって、それに反論するなら「そこまで生成AIの性能は到底上がりそうにない」を持ってこないといけないわけだ。

もっとざっくり言えば「そのうち～なる」という主張に対して「今は～でない」は反論になってないって話。時相論理的な主張なんだけど、反論者がそこを読み取れていない。この話なら元の話題は数年～10年スパンくらいの話に見えるので、反論として性能がサチりそうな気配とかそういうの出せばいいんじゃないかな。

@kmizu

MEMO:

ネットの議論ですぐ頭に血を上らせて全否定してくる人は基本的に文章読めてないので仕方がない

(2026/01/27)

糸井重里さん「今全国のSEが、食品のみ消費税0％が現実になったらという問題について涙目になりながら...

糸井重里さん「今全国のSEが、食品のみ消費税0％が現実になったらという問題について涙目になりながら考えていると思う」→本職の方々「8を0に変えるでよくて」 - Togetter

MEMO:

素人がわかったような事を言うな案件

(2026/01/27)

Is There a WordPress Replacement in 2026? I Went Looking

Is There a WordPress Replacement in 2026? I Went Looking | Jean Galea

要約:

■ 1. 調査の背景と動機

WordPressエコシステムで20年以上活動してきた著者が代替案を探索した

7歳の息子がウェブサイトを作りたいという要望がきっかけとなった

2025年のAutomatticとWP Engine間のガバナンス問題が緊急性を高めた:

Matt MullenwegがAutomatticとWordPress.org基盤の両方をコントロールしている

WP Engineのプラグインアップデートアクセスをブロックした

WordPressエコシステムには単一障害点が存在することが明らかになった

一人の決定が数百万のサイトが依存するプラグインアップデートメカニズムを混乱させ得る

WordPressは全ウェブサイトの約43%を占める

■ 2. 静的サイトジェネレーター（Astro、Hugo、Eleventy）

開発者コミュニティで人気がある

Astroは特に勢いがありCloudflareが2026年1月にチームを買収した

MarkdownまたはHTMLでコンテンツを作成し静的ファイルを生成する

Cloudflare Pages、Netlify、Vercelに無料でデプロイ可能である

利点:

出力が非常に高速である

データベース不要である

PHP不要である

セキュリティパッチ不要である

問題点:

管理パネルがない

ビジュアルエディタがない

コードエディタでファイルを編集しGitにプッシュする必要がある

クライアントがコンテンツを更新する場合は不適切である

トレーニング時間がサイト構築時間を超える

WordPress代替ではなくウェブサイトを生成する開発者ツールである

■ 3. モダンPHP CMS（Statamic、Craft、October）

Statamic:

Laravelで構築されている

クリーンなコードベースである

美しいコントロールパネルを持つ

フラットファイルストレージオプションでGitでバージョン管理可能である

ソロおよびホビープロジェクトは無料である

商用利用にはライセンスが必要である（サイトあたり275ドル以上）

モダンなアーキテクチャでWordPressを再構築したものである

商業的に売り込みが難しい

Craft CMS:

優れた開発者体験を持つ

優れたコンテンツモデリング機能を持つ

エコシステムが小さい

October CMS:

Laravel-WordPressハイブリッドを目指したが牽引力を得られなかった

ClassicPress:

Gutenbergを削除したWordPressのフォークである

より伝統的で安定したWordPress体験の維持を目指す

ブロックエディタの方向性が主な不満である場合に対処する

より小さなエコシステムという同じ根本的な制限を持つ

Gutenberg専用に構築されたプラグインは動作しない

開発者コミュニティはWordPressのごく一部である

いずれもニッチを超えて成長しない

ネットワーク効果が存在せず今後も存在しない可能性が高い

LaravelはAI駆動のルネサンスを経験している:

AIアシスタンスでプラグインや拡張機能を構築することが容易になっている

Laravel ベースのCMS代替案が増加すると予想される

マーケットプレイスが急速に充実すると予想される

堀が1年前の予測よりも早く崩壊する可能性がある

■ 4. ヘッドレスCMSオプション（Strapi、Directus、Sanity、Contentful）

コンテンツ管理とフロントエンドを分離するアプローチである

CMSにAPIでコンテンツを保存しフロントエンドを自由に構築する（React、Vue、静的HTMLなど）

エンタープライズおよび複雑なアプリケーション構築開発者に人気がある

典型的なウェブサイトやブログには過剰設計である

2つのものを構築および維持する必要がある

使用量ベースの価格設定（ContentfulやSanity）またはセルフホスティングに大きな技術的オーバーヘッド（StrapiやDirectus）が必要である

WordPress代替ではなく異なる問題のための異なるツールである

■ 5. ホスティングウェブサイトビルダー（Squarespace、Wix、Webflow）

シンプルなウェブサイトを求める層をWordPressから奪った

WordPressで苦労したであろう人々にとっては良い選択肢である

サブスクリプションサービスであり柔軟性が制限されている

所有ではなくレンタルである

プラットフォームがサポートしないことを実行したい場合に行き詰まる

月額料金を永久に支払う必要がある

異なる市場であり代替ではない

■ 6. 唯一の例外:Shopify

WordPressから大きな領域を奪った唯一の例である

特にWooCommerceから領域を奪った

主張的でホスティングされているという特徴で成功した

サーバー、アップデート、セキュリティ、プラグインの競合について考える必要がない

単に商品を販売できる

テクノロジースタックよりも製品に集中したい商人にとって利便性プレミアムが価値があることが判明した

開発者でない場合はeコマースサイトにShopifyが正しい答えであることが多い

10年前は真実ではなかった

■ 7. WordPressが勝つ理由

WordPressの堀はテクノロジーではない

テクノロジーは最も弱い点である:

レガシーコードベース

時として不器用なプラグインアーキテクチャ

コミュニティを分断したGutenbergの方向性

堀はエコシステムでありその中心はプラグインディレクトリである

公式WordPressリポジトリには60000以上のプラグインがある

商業的に販売されているプラグインが数千追加で存在する

SEOツール、eコマース（WooCommerceとその数百の拡張機能）、Instagram表示（Spotlight）、RSSフィード集約（WP RSS Aggregator）、メンバーシップ機能、予約システム、フォームビルダー、多言語サポート、バックアップソリューション、セキュリティ強化、パフォーマンス最適化、アフィリエイト管理、メールマーケティング統合などあらゆる機能のプラグインが存在する

この部分は新しいプラットフォームが近道できない

技術的に優れたCMSは1〜2年で構築できるが20年以上かけて開発された数万のプラグインのエコシステムは構築できない

WordPressの代替案を評価する際に必要な機能が新しいプラットフォームに存在しないかカスタム開発が必要になる瞬間が訪れる

その瞬間に戻ってくる

プラグイン以外の要素:

WordPressを知っている数百万の開発者

ワンクリックインストールを提供するホスティング会社

20年分のStack Overflowの回答

非技術者が実際に理解できるメンタルモデル

教育エコシステム（WP Mayor、WPBeginnerなどの数百のブログ、YouTubeチャンネル、コミュニティが無料でWordPressを教えている）

チュートリアル、レビュー、ガイドの深さが代替案には存在しない

午前2時にサイトが壊れた理由を解明しようとする時ほぼ確実にどこかに答えが既に書かれている

プラグインエコシステムがキラー機能である

非開発者がコードを書かずに真に複雑なサイトを構築できる

WordPressを置き換えるにはすべてを複製する必要がある

より良いCMSを構築するだけでなくその周りに完全なエコシステムを構築する必要がある

それには10年と多くの運が必要である

■ 8. AIの影響

プラグインエコシステムの利点はカスタム開発が高価で遅いために部分的に存在する

プラグインとして存在しない機能が必要な場合は開発者に支払うか自分でコーディングを学ぶ必要がある

その摩擦が既存のソリューションを持つプラットフォームに人々を押しやる

AIがカスタム開発をより速くより安価にしている

ClaudeやCursorのようなツールで開発者は数日かかっていた機能を数時間で構築できる

非開発者がAIアシスタンスで簡単なツールを自分で構築し始めている

この傾向が続けば「プラグインを使うだけ」という利点は侵食される可能性がある

WordPressが負けるとは限らない:

WordPressのオープンで拡張可能なアーキテクチャはAIがオンデマンドでカスタムプラグインを生成できる時にさらに価値が高まる可能性がある

より新しくクリーンなプラットフォームが不足機能を構築するコストが劇的に低下するためより実行可能になる可能性がある

境界線はすでに曖昧になっている

確立されたWordPressプラグイン（WP RSS Aggregatorなど）は既存の製品にAI機能を大幅に実装している

問題は「WordPressか他のものか」だけでなく「AIを備えたWordPress、カスタムAI駆動アプリ、またはまだ完全に定義されていないハイブリッド」になっている

著者はAgentVaniaを通じて中小企業のAIソリューション実装を積極的に支援している:

最終的にスタンドアロンアプリになる可能性のあるカスタム統合

AIをコアに持つWordPressプラグイン

その他完全に異なるもの

今後10年間の技術選択を考える際に完全に予測できない方法で計算が変わる可能性があることを考慮する価値がある

WordPressとAIの両方に近い位置にいることは合理的なヘッジである

■ 9. 用途別の推奨

SaaSマーケティングサイト（ランディングページ、価格設定、ドキュメント）:

WordPressは機能するが過剰である

AstroまたはHugo等の静的ジェネレーターが理想的である（高速、安全、ホスティングが安価、開発チームが製品コードと一緒にGitで管理可能）

多くのSaaS企業がこの方向に移行している

非技術的なマーケティング担当者が定期的にコンテンツを編集する必要がある場合はWordPressまたはWebflowが適切である

SaaSアプリケーション自体（顧客がログインする実際の製品）:

カスタムアプリケーション領域である

WordPressでもCMSでもない

Laravel、Next.js、Railsなどチームに合うもので構築する

ダッシュボード、ユーザー管理、コア機能はすべてカスタムコードである

ブログ（個人または企業）:

WordPressが合理的なデフォルトである

使いやすい

SEOプラグインエコシステム（Yoast、Rank Mathなど）が他の場所で複製するには大きな努力が必要な機能を提供する

技術的でミニマルなものが必要な場合はAstroが適している

メンバーシップとニュースレターが組み込まれている場合はGhostが検討に値する（ただしホスティングはサブスクリプション価格に戻る）

パンフレットサイト（5〜10ページの典型的な中小企業）:

クライアントが自分で編集する必要がある場合はWordPress

真に静的でクライアントが触れない場合はCloudflare PagesまたはNetlifyにデプロイされた静的ジェネレーターがシンプルでホスティングコストがかからない

継続的なメンテナンス責任を負いたくない場合はSquarespaceも良い

アグリゲーターサイト（ディレクトリ、リスティング、求人掲示板、コンテンツキュレーション）:

WordPressのプラグインエコシステムが真に輝く場所である

カスタム投稿タイプ、Advanced Custom Fields、WP RSS Aggregatorのようなプラグインでゼロから構築せずに複雑なコンテンツ関係をモデル化し外部フィードを取り込むことができる

新しいプラットフォームでそれを行おうとするとカスタムコードを書くか機能が単に存在しないことを発見する

プラグインが提供する以上の重いカスタム機能が必要な場合はLaravelがより良い基盤になるがすべてを自分で構築および維持することにコミットする

ダッシュボードまたは内部管理パネル:

決してWordPressではない

カスタムアプリケーション領域である

FilamentまたはLivewireを使用したLaravelが適している

APIと通信するReact/Vueフロントエンドも適している

ローコードアプローチが必要な場合はRetoolまたはBudibaseのようなツールが存在する

eコマース:

特定の理由（複雑なカスタマイズ要件、月額料金回避、Shopifyのモデルに合わないB2B使用例）がない限りShopify

WooCommerceは完全な制御が必要で継続的なメンテナンス負担を処理できる場合に実行可能である

WooCommerce拡張エコシステムは巨大である

これが他のWordPressベースのソリューションよりもShopifyに対して優位性を保っている理由の一部である

メンバーシップまたはオンラインコースサイト:

LearnDash、MemberPress、Restrict Content ProなどのプラグインとWordPressが確立されたルートである

代替案（Teachable、Kajabi、Thinkific）は適しているがサブスクリプションベースでプラットフォームにロックインされる

所有権、柔軟性、他のプラグインで機能を拡張する能力が必要な場合はWordPressが勝つ

メンバーシッププラグインとWordPressエコシステムの残りの部分との統合によりすべてがサイロ化されることなくコースをWooCommerce、メールマーケティングプラグイン、アフィリエイト追跡などと組み合わせることができる

フォーラムまたはコミュニティサイト:

BuddyPressまたはbbPressとWordPressは機能するが専用ソリューションと比較して不器用に感じる可能性がある

Discourseは伝統的なフォーラムに真に優れているが別のホスティングと管理が必要である

CircleやBBPressおよび同様のプラットフォームはサブスクリプションベースである

ほとんどの使用例ではプライベートSlack、Discord、TelegramグループがWPでの伝統的なフォーラムの必要性に取って代わった

フォーマットが流行遅れになった

ポートフォリオサイト（写真家、デザイナー、作品を紹介するクリエイティブ）:

WordPressまたはSquarespaceの両方が適している

Squarespaceテンプレートはビジュアルポートフォリオ用に箱から出してより良くデザインされていることが多い

ポイント全体が美学である場合に重要である

技術的な人の場合は優れたギャラリー設定を持つ静的サイトがよりクリーンで高速である

Instagram中心のポートフォリオの場合はSpotlightのようなプラグインで手動更新なしにフィードを美しく表示することが容易である

ニュースまたはメディアサイト:

WordPressが支配的であり僅差ではない

公開ワークフロー、編集役割、リビジョン履歴、スケジューリング、広告、分析、ペイウォール、ニュースレター統合用のプラグインエコシステムは一致させるのが難しい

ほとんどの主要なオンライン出版物はWordPressまたははるかに大きな予算で構築されたカスタムのものを実行している

今日メディア会社を始める場合はWordPressを使用しない説得力のある理由が必要である

多言語サイト:

WPMLまたはPolylangとWordPress

プラグインエコシステムが明確な利点を持つ分野の1つである

多言語コンテンツ管理は真に複雑である

これらの専用プラグインは予想もしないエッジケースを解決するために何年も費やしてきた

カスタムサイトに多言語サポートを構築するか成熟した多言語プラグインのないプラットフォームを使用することはこれらすべてのエッジケースを自分で再発見することを意味する

ランディングページまたは単一キャンペーンページ:

CMSがまったく必要ない場合がある

Cloudflare PagesまたはNetlifyにデプロイされた単一のHTMLファイルまたはWebflowやCarrdで迅速に構築されたものが正しい答えであることが多い

AIツールが今や数分で完全なランディングページを生成できる

結果は真に良好である

3か月間実行されてからアーカイブされるワンページキャンペーンにはWordPressは過剰である

パターンの出現:

非技術者が編集するコンテンツ管理ウェブサイトが必要な場合特に基本的なコンテンツ管理を超える機能が必要な場合にWordPressが勝つ

プラグインエコシステムによりゼロから始めることはほとんどない

独自の要件を持つアプリケーションを構築する場合はカスタムコードが勝つ

開発者が管理しパフォーマンスが最重要である場合は静的ジェネレーターが勝つ

消費者にオンラインで製品を販売する場合はShopifyが勝つ

■ 10. 著者の息子への選択

純粋主義者としては静的サイトジェネレーターを検討した:

最初から本物のHTML、CSS、JavaScriptを教える

抽象化なし管理パネルなしコードとテキストエディタだけ

他のすべての基礎となる基礎を学ぶ

しかしサッカーについて書いたり旅行の写真を共有したりしたい子供には現実的ではない

アイデアからインターネット上での公開までの摩擦をできるだけ小さくする必要がある

そうでなければ最初の投稿を公開する前に興奮が死ぬ

ホスティングビルダー（Squarespace、Wixなど）も検討した:

真に簡単である

しかしサブスクリプションサービスであり移転可能なものを何も教えない

それらを超えて成長した場合は最初からやり直す

初日からコンテンツを所有してほしい

より技術的なアプローチも検討に値する:

Localを使用してWordPressをローカルで実行し静的HTMLに変換しGitHub経由でCloudflare Pagesに公開する

利点は年間10ドルのドメイン更新料を支払い続ける限り数十年後もブログが存在する

継続的なホスティング料金なしサーバーメンテナンスなしセキュリティ更新なし

AI生成も現在最速の方法である:

Claudeのアーティファクトのようなツールが数分で完全で洗練されたウェブサイトを生成できる

GitHubに保存しCloudflare PagesまたはNetlifyで公開して完了

結果は正直素晴らしい

両方のアプローチへの躊躇:

あまり学ばない

Local-to-staticワークフローはエレガントだが不透明である

何が起こっているか理解せずにボタンを押すことになる

AI生成サイトは自分で何かを構築するプロセス全体をスキップする

正直な答えが「AIがこれを作り私はデプロイをクリックした」である場合「私がこれを作った」という魔法が失われる

著者はWordPressを選択した:

完璧だからではなく若い初心者に適切なバランスを取っているから

すぐに書いて公開できる

何か言いたいことがあることと公に言うことの間のギャップはわずか数クリックである

その即座の満足感は7歳の時に非常に重要である

準備ができたら深さがある

投稿を書くことから始めてテーマに興味を持ちその下のコードを覗くことができる

天井は何年も超えないほど十分に高い

スキルが移転可能である

WordPressの仕組みを理解することはどこでも適用される概念（コンテンツ管理、データベース、ホスティング、ドメイン）を教える

最終的に何か他のものに移行してもメンタルモデルは引き継がれる

著者がそれを知っている

行き詰まったときに助けることができトリックを見せることができなぜ物事がそのように機能するかを説明できる

親が教えることができるものを学ぶことには技術的知識を超えた価値がある

20年後著者が学んだのと同じプラットフォームを教えている

それはWordPressの持続力または代替案の欠如またはその両方について何かを語っている

■ 11. 結論と提言

開発者またはエージェンシーが移行を検討している場合の正直な答えは移行先がまだ存在しないということである

WordPressガバナンスについて不安がある場合（合理的である）の実用的な対応はスキルを移植可能に保つことである:

モダンなPHPとJavaScriptを学ぶ

WordPress固有の実装だけでなく原則を理解する

何かが最終的に出現した場合に準備ができている

今日新しいサイトを構築し非技術者が使用できる管理パネルを持つCMSが必要な場合はWordPressが依然として答えである

もっとエキサイティングなことを伝えたいができない

市場のギャップは現実である

WordPressレベルの使いやすさと成長するエコシステムを持つモダンなオープンソースCMSは真に価値がある

しかし誰もまだそれを構築していない

それが機会かもしれない

MEMO:

7歳の息子が初めてWEBサイトを作りたい → よし、WPだ！はちょっと意味がわからない
素直にHTML + CSSを手書きで書かせてアップロードだけ手伝ってやればいいような
子供は時間なんて幾らでもあるんだし、ローカルで弄り回せた方がいいだろうに
AIに手伝ってもらうなら尚更ローカルで触れた方がよいような
クライアントワークでサクッと納品したいとかならまだ理解できるのだが

(2026/01/26)

AIエージェントにお金を払えば、誰でもゲームを作れてしまうという衝撃の事実　開発者の仕事はどうなる？

ASCII.jp：AIエージェントにお金を払えば、誰でもゲームを作れてしまうという衝撃の事実　開発者の仕事はどうなる？ (1/5)

(2026/01/26)

まつもとゆきひろが危惧する、ジュニア不要論の先に広がるIT業界「焼け野原」：「コードを書かない」未来...

まつもとゆきひろが危惧する、ジュニア不要論の先に広がるIT業界「焼け野原」：「コードを書かない」未来、エンジニアは何者になるのか（1/2 ページ） - ＠IT

(2026/01/26)

ソフトウェア開発で「なぜなぜ分析」はアンチパターン

ソフトウェア開発で「なぜなぜ分析」はアンチパターン - 勘と経験と読経

要約:

■ 1. なぜなぜ分析がソフトウェア開発に不適切な理由

なぜなぜ分析（根本原因分析・RCA・5 Why手法）はソフトウェア開発においてアンチパターンである

ソフトウェアは平均的に複雑系である

複雑系は複雑な方法で故障する

インシデントや問題に対する単一の因果関係を持つ単一の根本原因はそもそも存在しない

なぜなぜ分析は単一な根本原因に焦点を当てるために過度または誤った抽象化を行いやすい

適用すべきではないというより有害である

なぜなぜ分析はその特性上人的ミスに帰結しやすい点も問題である

超シンプルで小さなソフトウェアには有効かもしれないが現代ではそのようなソフトウェアは存在しない

■ 2. なぜなぜ分析がなくならない理由

会社のルールだから:

古い会社のルールを見直さず放置している

偉い人が言うから:

偉い人が学習を怠り過去の自分の成功体験を繰り返している

他の方法を勉強していない

なぜなぜ分析の結果は対外的に説明しやすい:

シンプルな因果関係やストーリーはわかりやすい

しかし選択したシンプルな因果関係やストーリーはすぐに破綻する

また別の理由で次のインシデントが発生する

再発防止策がさらに増える

チェックリストが拡充される

無駄な作業ばかりが増え生産性は落ちていく

■ 3. なぜなぜ分析のダメな例（SREをはじめようより）

システムダウンの事例:

システムがダウンした

→サーバーが停止した

→ディスクがいっぱいになった

→ログが肥大した

→ログローテしてなかった

→設定ファイルが漏れていた（根本原因）→すべての設定ファイルにログローテーションの設定があることを確認という分析

問題点:

観察した1つの事柄を深く掘り下げる際に他の要因を無視している

なぜを繰り返す前に何が起こったのかの質問にすべて答える必要がある

単一の根本原因に焦点を当てることが失敗から学ぶ上で不利になる

明確な因果の連鎖を1つ特定できたと思った時点でインシデントを深く観察することをやめてしまう

■ 4. 根本原因という正解の不在

インシデントの原因は無数にある

複合要因をちゃんと分析すべきである

根本原因という用語はすべての背後に1つの真の原因があるように見えてしまう点でダメである

現代は唯一解のない正解がいくつもある時代である

問題を分析しその問題の正解を外から持ってくるという思考法だけでは通用しない

少し前の教育を受けていた世代は優等生主義や正解主義のきらいがある

MEMO:

なぜなぜ分析は線形な分析になるので本質的な問題が抜け落ちがちという話はある
なのでシステム思考でシステム（系）全体の把握をするのだという事になるのだが、システム思考はかなり面倒
システム思考までやっている時間・気力は無いので、とりあえずなぜなぜ分析でお茶を濁すという場面のあるのではなかろうか

(2026/01/25)

複雑な要件を1クエリで完結させる、PostgreSQL活用術

複雑な要件を1クエリで完結させる、PostgreSQL活用術 - SmartHR Tech Blog

要約:

■ 1. 記事の概要

SmartHRのプロダクトエンジニアが実装した巨大なSQLにおいて活用したPostgreSQLの機能を紹介

一般的な構文の影に隠れがちだが非常に助けになった機能をピックアップ

ORMだけでは解決できない課題やパフォーマンスチューニングをする際の一助となることを目的とする

■ 2. 複雑なクエリを保守しやすくするための基本

WITH句とウィンドウ関数の知識:

CTEとウィンドウ関数は現代的なSQLを書く上で必須

SQLの自由度は理解度で劇的に変わる

WITH句CTE:

SQL内で一時的なテーブルに名前をつけて定義できる機能

古いスタイルのSQLではサブクエリをネストして書くことが一般的だったがネストが深くなると内側から外側へ読み解く必要があり脳のメモリを消費する

WITH句を使うと処理を上から下へ流れるように記述できる

アプリケーションコードでいう変数や関数に切り出して名前をつける感覚に近い

ロジックをステップごとに分解して記述できる

ウィンドウ関数:

SUMやRANKなどの関数にOVER句を組み合わせることで実現する機能の総称

通常のGROUP BYとともに集約関数を使うと行がグループごとに1行に圧縮される

個別の明細行は残したいが全体の集計値も横に添えたい場合にウィンドウ関数を使用

OVER句が出てきたらその手前にある関数がウィンドウ関数というグループに属していると理解すればよい

明細行を残したまま集計結果をすべての行に持たせることができる

SUMは通常は集約関数だがOVERをつけるとウィンドウ関数として振る舞う

DENSE_RANKなどウィンドウ関数としてのみ振る舞う関数も存在

行を集約しない特性がアプリケーションが必要とする複雑なデータ構造を1回のクエリで作る上で非常に重要

■ 3. 任意のIDリスト順にソートする方法

unnest関数とARRAYとWITH ORDINALITYとCTEのWITH句を組み合わせて使用

WITH ORDINALITYのWITHはCTEのWITH句とは全く別物

すでにあるIDのリスト順の通りに検索結果を返したい要件が発生することがある

WHERE id INのように検索すると返却されるレコードの順序はバラバラになる

リストが並び替えでしか使われていない場合はarray_position関数を使う選択肢がある:

array_positionは並び替え済みの値の配列と今の行の値という形式でその値が配列の何番目にあるかを返す関数

ORDER BYを書くことが可能

シンプルだがクエリの複数箇所でそのIDリストを使いたい場合は共通化した方が良い

IDリストが数百から数千件と長大な場合:

配列リテラルをクエリのあちこちに埋め込むとSQL全体のサイズが肥大化

人間にとって読みにくいだけでなくDBのパーサーに無駄な負荷をかけ通信量も増大

パフォーマンスの観点でも好ましくない

unnest関数とARRAYとWITH ORDINALITYを使うとCTEのWITHと組み合わせて記述可能:

長大なリストの登場は一回だけで済む

長いリストはCTEで一度だけ定義しテーブルとして使い回す

WITH ORDINALITYを使うと元のデータの横に連番が自動的に付与される

AS t関数とカラム名でテーブルの別名とカラムの別名を同時に定義する構文を使用

■ 4. JOINで増えた行へマークするDENSE_RANK

ランキング関数は売上ランキングのような用途が真っ先に思い浮かぶが実務特に履歴管理を含む複雑なデータを扱う場面では違った用途で活躍

1対多の1:NのJOINを含む履歴データから最新の1件N行すべてを取得したいケースで使用

DENSE_RANKは同率順位があった場合番号を飛ばさずに詰めて採番

評価完了日が同じであればJOINによって行が増えていてもそれらは全て同率1位として扱われる

自分で名付けたrank_numで絞り込みをすれば各社員の最新のプロジェクトを取得可能

絞り込みはウィンドウ関数と同じ階層ではWHEREに書けず別のCTEなどで書かなくてはいけない

DENSE_RANKに類似した関数としてROW_NUMBERやRANKがあるがいずれも採番のルールが違うため今回のケースでは適さない

■ 5. BOOL_ORウィンドウ関数

グループ内のデータ全体を見渡してどれか一つでも条件を満たせばフラグを立てたい場合やどれか一つでも条件を満たしているグループのみ絞り込みたいケースでよく使用

PostgreSQLならBOOL_ORをウィンドウ関数として使うことで自然言語に近い形で記述可能

BOOL_OR論理和という名前の通りパーティション内のどれか一つでもtrueであれば結果はtrueになる

グループ内のすべてがtrueのときだけtrueを返したい場合はBOOL_AND標準SQLだとEVERYが使用可能

■ 6. ウィンドウ関数に空のOVER関数を使って全体集計

通常ウィンドウ関数といえばPARTITION BYで区切って使うものだが何も指定しないことで実現できる便利な挙動がある

空のOVER関数とその使い道:

Webアプリケーションで一覧画面を作る際に必ずと言っていいほど実装するのがページネーション

現在のページの20件と全ヒット件数1530件などの両方が必要

通常これを実装するには2回のクエリを発行するのが定石

ウィンドウ関数を使えば1回のクエリで完結可能

OVERの中にPARTITION BYを書かずに空っぽにすると検索結果全体を一つの大きなグループとして扱える

パフォーマンス上の注意点:

クエリの回数を減らせるというメリットがあるが常に最適解とは限らず最適解となることは少ない

単純なCOUNTであればインデックススキャンのみで高速に完了するケースでもウィンドウ関数COUNT OVERを使うとテーブル本体へのアクセスが必要になりパフォーマンスが落ちる可能性

インデックスが効く単純な検索の場合はクエリを2回に分けたほうが速い場合が多い

複雑な検索でフルスキャンが避けられない場合は1回で済ませるこのテクニックが有効なことがある

COUNT OVERはJOINで膨れ上がった重複レコードもすべてカウントしてしまう

JOINで生まれた重複を除いた純粋な母数が知りたい場合には次に紹介する方法が有効

ページネーション用にDENSE_RANKの値を使っていたときついでにJOINで膨れる前の件数を出す応用:

ページネーションの判断基準を作るために既にDENSE_RANKの数値を利用していた場合その数値から全体の件数も出す

1人のユーザーが複数の行履歴を持っているデータにおいて全行数ではなく全ユーザー数をベースに1ページあたり10ユーザーのページネーションを実装したい場合

単にCOUNT OVERをすると行数分が返ってきてしまう

LIMIT 10をかけると10行おそらくユーザーが重複し10ユーザー未満の数しか含まれないしか取れない

DENSE_RANKで振った番号を活用しMAXを使うことでJOIN済みの結果セットが返ってくる状態でも実質のページネーションとともにその母数がいくつかを導出可能

COUNT DISTINCT user_id OVERでも全ユーザー数は出せるがページネーションの絞り込み用として既にDENSE_RANKを計算していたためその計算結果を再利用するほうがクエリとして無駄がないと判断

■ 7. JOIN済みの結果をJSONにするjsonb_agg

やむをえずアプリケーション層でほぼ生SQLを書く時にあるあるなのが1対多のテーブルをJOINしてデータを取得した結果行の増幅が発生してアプリ側での再整形が必要になること

アプリケーション層で必要になる処理:

DBから大量の行を取得

forやeachでループを回す

1つ前のIDと今のIDをチェックし値が違ったら新しいユーザーオブジェクトを作る

値が同じならタグ配列に値をpushする

IDが変わったかチェックして何かしらを行う処理はコードが複雑になりがち

素朴な一対多が一つだけあるならまだ大丈夫だが二重三重に一対多の関係がありJOINされたレコードを頭に入れて再構築するのは大変

アプリケーションサーバーよりもDBサーバーの方がスケールしにくいためこの手法を嫌う人もいるがDB側でJSONに集約してから値を返してもらうのも一つの手

json型とjsonb型:

PostgreSQLにはJSONを扱うためのデータ型としてjson型とjsonb型の2種類が存在

json型は入力されたテキストをそのまま文字列として扱う型で書き込みは速いが検索や加工のたびに構文解析が必要なため参照は遅い

jsonb型は入力されたテキストをバイナリ形式に分解変換した型でjsonbのbはbinaryのb

jsonb型は書き込みは少し遅いが参照や検索が非常に高速でカラムとして追加する場合はインデックスGINを貼ることも可能

json型を使うのはレアなケースで基本的にはjsonb型を使うと覚えておけば大丈夫

jsonb_agg集約関数で行を配列に畳み込む:

増幅された行を畳み込むのにはjsonb_aggを利用

GROUP BYで集約された複数の行を一つのjsonb型の配列の値に変換する集約関数

集約関数内のORDER BYが重要なテクニック

これを書かないと生成されるjsonb型の配列の値の中身の順序はランダムになる

配列内の順序を保証したい場合関数の中でソート指定を行う必要がある

アプリケーション側でIDが変わったかどうかを判定するループ処理を書く必要はなくなる

DBから返ってきたJSONをそのまま利用するだけになりロジックが劇的にシンプルになる

jsonb_aggは集約結果をすべてメモリ上で構築してから返却するため数万から数十万行といった大量データを1つの値にまとめようとするとDBサーバーのメモリを急激に圧迫する恐れがある

jsonb_build_arrayでjsonbの配列を作る:

jsonb_aggが複数行をまとめてjsonb型の配列の値にするのに対しjsonb_build_arrayは指定したカラムや値をその場でjsonb型の配列の値にする関数

型合わせのために利用

ある配列jsonb型と別のID単一の数値をUNION ALLで結合したかったが型が違うとエラーになる

単一のIDもjsonb_build_arrayで配列に変換することで強引に型を揃えてUNION ALLした

データの形式を揃えたい時などに利用可能

生成したjsonb型の値に対する検索:

生成したjsonb型の値に対して後から検索をかけることも可能

PostgreSQLのjsonb型は非常に優秀で包含演算子などを使用することで生成後の値に対しても検索可能

パフォーマンスには注意が必要

UNIONされた結果やCTEで動的に生成されたJSONデータに対してはインデックスを効かせることができない

すでに対象件数が十分絞り込まれているコンテキストだったため許容したが大量データに対して無邪気にインデックスの効かない検索処理を行うと事故につながるリスクがある

■ 8. おわりに

紹介したテクニックはすべて実際のプロダクト開発におけるとある1つの巨大クエリに詰め込まれたエッセンス

無闇に複雑で巨大なSQLを書くことが正義ではない

ミッションクリティカルな機能や多くの人が頻繁に触れる箇所であれば要件の再検討テーブルの非正規化アプリ側での処理分割などを選んでいた

プロダクトの開発背景パフォーマンス要件開発速度それらを天秤にかけあえてDB側で完結させることが最適解となる瞬間は存在

PostgreSQLには強力な機能が備わっていることを知っていただければ幸い

最終的に9つのCTEが連なることとなった

(2026/01/24)

Stop using MySQL in 2026, it is not true open source

Stop using MySQL in 2026, it is not true open source

要約:

■ 1. MySQLのオープンソース性の問題

2026年においてMySQLを使用している場合はMariaDBへの移行を検討すべき

github.com/mysql/mysql-serverへのgitコミット数が2025年に大幅に減少

MySQLはライセンス上はオープンソースだがプロジェクトとしてはオープンソースではない

■ 2. Oracleによる管理の問題点

2009年にOracleがSun MicrosystemsとともにMySQLを買収

欧州委員会は競争を抑制する目的があると懸念し買収を阻止しようとした

OracleはMySQLを維持する約束をしたが良いオープンソースプロジェクトの管理者ではなかった

コミュニティは長年にわたり衰退

開発の問題点:

すべての開発は非公開で行われる

公開されているバグトラッカーはOracle担当者が実際にMySQL開発に使用している本物ではない

MySQLへの貢献を試みる人々のプルリクエストやパッチ提出は受領としてマークされるがフィードバックはほとんどない

変更が次のMySQLリリースに含まれるかどうかは不明で多くの場合書き直される

gitのauthor/committerフィールドにはOracle担当者のみが記載される

実際の著者はブログ投稿で小さく言及されるのみ

Amazon Web ServicesのRDS MySQLとRDS MariaDBのコアチームのエンジニアリングマネージャーだった際にエンジニアの両方への貢献を監督したがOracleによる貢献の受け入れが悪いためMySQL側への提出を嫌がった

■ 3. MariaDBとの比較

MariaDBはMySQLの元の作者Michael Wideniusによるフォーク

すべての開発がgithub.com/mariadb/serverでリアルタイムに行われる

誰でもプルリクエストを提出しレビューを受けることができる

すべてのバグがjira.mariadb.orgで公開討論される

真のオープンソースプロジェクトに期待される通りの運営

■ 4. MySQLの技術的衰退

Oracleは買収後10年以上にわたりMySQL組織を存続させ比較的独立して新バージョンを開発リリースすることを許可した

MySQL事業は財務的に有用だったと推測されるが少なくともOracleの主要データベース事業を脅かすほど多くの機能を獲得しない限り

2022年以降技術的観点から明らかに劣化し始めた

MySQL 8.0.29の問題:

デフォルトのALTER TABLEメソッドがin-placeに切り替えられた

多くのコーナーケースが機能せずデータベースがクラッシュしデータが破損

問題は1年後のMySQL 8.0.32まで完全には修正されなかった

Oracleが8.0シリーズをevergreenと発表しマイナーリリースで機能と変更を導入した

ユーザーは歴史的にx.y.Zメンテナンスリリースからバグ修正とセキュリティ修正のみを期待していたため不満

新しいメジャーバージョンのリリースが6年間なかった:

2018年のMySQL 8.0の後2023年にMySQL 8.1がリリースされたが短期プレビューリリースのみ

最初の実際の新しいメジャーリリースMySQL 8.4 LTSは2024年にリリース

新しいメジャーリリースにもかかわらずほとんど新機能がなく多くのユーザーが失望

パフォーマンスの低下:

新しいMySQLバージョンでパフォーマンスが低下したという報告が多数

MySQL性能専門家Mark Callaghanのベンチマークによると書き込み重視のワークロードでMySQL 9.5のスループットは通常8.0より15%少ない

アップグレードの問題:

新しいMySQLバージョンが多くの機能を非推奨にしたため多くのユーザーがMySQL 5.7から8.0および8.0から8.4へのアップグレードで大きな苦労を報告

新機能がほとんどなくコードベースのクリーンアップと機能の非推奨に重点が置かれたためOracleがMySQLをかろうじて生かしておくだけと決定したことが明らかになった

すべての新しい関連機能はOracleのクローズドソースでクラウド専用のMySQL顧客向けサービスHeatwaveに投入

OracleがMySQLに投資していないことが明らかになりPerconaのPeter Zaitsevが2024年6月にIs Oracle Finally Killing MySQLと執筆

DB-Enginesによるランク付けでMySQLの人気が急落し始め2026年にはその傾向が加速する可能性

2025年9月にOracleが労働力を削減しMySQL担当者が大幅に削減されたとニュースで報道

MySQLの将来に良い兆候ではなくPeter Zaitsevが11月に最新のMySQLメンテナンスリリースに含まれるバグ修正が以前より少ないことを示す統計を投稿

■ 5. オープンソースの重要性

オープンソースはイデオロギー以上のものでありソフトウェアのセキュリティと主権に実際の影響を与える

MySQLが真にオープンソースであるかどうか気にしない人や今後数年間の将来があるかどうか気にしない人がいるが大きなリスクを取っている

データベースはソフトウェアアプリケーションスタックの最も重要な部分であり運用上の欠陥や問題特にセキュリティ問題は即座に結果をもたらす

オープンソースでは問題が公開討論され問題が大きいほど多くの人々や企業が修正に貢献する

オープンソース開発手法は科学的方法に似ており自由なアイデアの流れが常に争われ最も説得力のある証拠を持つものだけが勝つ

オープンではないことはより多くの不透明性より多くのリスクより多くの信頼してくれという態度を意味する

■ 6. セキュリティ問題の取り扱い

2025年だけでMySQLは123件のセキュリティ問題に関するCVEを公開しMariaDBは8件

2025年にMySQLのみに影響しMariaDBには影響しなかったCVEは117件

CVEにはほとんど実際の詳細が含まれていない

最新のCVE-2025-53067の例:

容易に悪用可能な脆弱性により高権限の攻撃者が複数のプロトコルを介したネットワークアクセスでMySQL Serverを侵害できると記載

セキュリティ研究者や監査人が元の問題が実際に存在したか修正されたか修正が十分で問題を完全に軽減したかどうかを検証するために使用できる情報がない

MySQLユーザーはOracleの言葉を信じるしかない

このようなセキュリティ問題の取り扱いは他のオープンソースプロジェクトとは対照的

他のオープンソースプロジェクトでは最初のエンバーゴが終了しCVEが公開された後すべてのセキュリティ問題とそのコード修正が完全な精査のために公開される

■ 7. エンシッティフィケーション

真のオープンソースプロジェクトでは見られない様々な形態のエンシッティフィケーションが進行中

MySQLのソフトウェアドキュメントウェブサイトのすべてがユーザーにオープンソース版の使用を停止しクローズドMySQLバージョン特にHeatwaveへの移行を促している

Heatwaveはクローズドソースであるだけでなく顧客のデータベースコンテンツをOracleが完全に管理する結果となる

Redditなどでの話によるとOracleは残りのMySQL顧客から搾り取っており顧客はますます少ないものに対してますます多く支払うことを余儀なくされている

■ 8. 移行の選択肢

MySQLユーザーの大部分は2010年代半ばに既にMariaDBに切り替えた

データベースソフトウェアが真にオープンソースであり続けることを深く気にかけた人々が含まれる

大規模インストールの例:

Wikipedia

FedoraやDebianなどのLinuxディストリビューション

オープンソースであり統計を収集する中央集権的な機械がないため正確な市場シェアは不明

アプリケーション固有の統計:

世界中のWordPressサイトの57%がMariaDBを実行

MySQLのシェアは42%

■ 9. 移行方法

WordPressDrupalMediawikiNextcloudMagentoなどの古典的なLAMPスタックアプリケーションを実行している場合:

古いMySQLデータベースをMariaDBに切り替えるのは簡単

MariaDBはMySQLのフォークでありほとんど後方互換性がある

MySQLをMariaDBに交換しても既存のコネクタやデータベースクライアントを変更する必要がない

それらはMariaDBがMySQLであるかのように動作し続ける

カスタムアプリケーションを実行しデータベースの使用方法と内容を変更する自由がある場合:

成熟した十分に機能するオープンソースデータベースが数十ある

PostgreSQLが最も人気のある一般的なデータベース

アプリケーションが最初からMySQL用に構築されている場合PostgreSQLへの切り替えには多くの作業が必要な可能性

MySQL/MariaDBアーキテクチャとストレージエンジンInnoDBは高性能スケーラビリティ堅実なレプリケーション機能が最優先であるオンラインサービスなどで優位性を提供する可能性

迅速で簡単な移行にはMariaDBがおそらく最良の選択肢

Percona Serverへの切り替えも非常に簡単:

MySQLのすべての変更を密接に追跡しPerconaによる少数の改善によってのみ逸脱

基本的にMySQLサーバーのカスタマイズバージョンであるためOracleへの依存を完全に捨てようとする人々にとっては長期的に実行可能なソリューションではない

MySQLと共通の祖先を持たないがMySQL互換を目指すオープンソースデータベースも複数存在:

MySQL用に構築されたほとんどのアプリはSQL文を書き直す必要なく単純に切り替え可能

TiDBの例:

非常にスケーラブルで大規模なシステム専用にゼロから設計

Amazonの最新データベースソリューションDSQLはTiDBから多くのアイデアを借りて構築されるほど優れている

TiDBは大規模な分散セットアップで真価を発揮するため現在MySQLを使用している大多数の通常の小中規模アプリケーションにとって最も実用的なソリューションはMariaDBへの切り替え

ほとんどのLinuxディストリビューションでapt/dnf/brew install mariadb-serverを実行するだけでインストール可能

Oracle以外を選択すれば何を選んでもより良い状況になる

(2026/01/23)

Node.js作者の発言「人間がコードを書く時代は終わった」について思うこと

Node.js作者の発言「人間がコードを書く時代は終わった」について思うこと | maguro.dev

要約:

■ 1. Ryan Dahlの発言と背景

2026年1月20日にNode.js作者Ryan Dahlが「人間がコードを書く時代は終わった」とXに投稿

ソフトウェアエンジニアの仕事がなくなるという意味ではなくプログラムのシンタックスを直接書くことがエンジニアの仕事ではなくなったという主張

Ryan DahlはDeno Land Inc.の共同創業者でありNode.jsに代わる新しいJavaScript/TypeScriptランタイムDenoを開発中

投稿は24時間で約300万ビュー2300以上のリポスト11000以上のいいねを獲得

■ 2. 筆者の働き方の変化

数ヶ月前まで:

自分がコードを書きAIはたまに相談する相手

現在:

AIが運転席に座り自分は助手席でナビゲーションする感覚

AIは「分身」に近い存在として機能

適切な頼み方で十分なコンテキストを与えることで疲労知らずで作業を実行

時間をかけてもたどり着けなさそうなバグの原因を一撃で発見することもある

Opus 4.5の登場が転機となり頼れる相棒分身となった

■ 3. プログラミングのシンタックスを書く必要性の減少

AIがコードを書くため自分でコードを打ち込む機会が明らかに減少

実装プロセス:

実装したい機能や修正したいバグについてプランを練らせる

レビューする

実装する

レビューする

同僚の書いたコードをレビューする程度の感覚で信頼できるレベルに到達

■ 4. ソフトウェアエンジニアの役割の変化

比重が下がった要素:

コードを書く部分

比重が強まった要素:

あるべきアーキテクチャの指針を決める

コードベースからは読み取れないコンテキストを整理し与える

期待する挙動を自動的継続的に検証できる枠組みを整える

■ 5. 現在のプログラミングスタイル

ある機能を実装したい場合の初手で自分からコードを書くことはほぼなくなった

作業フロー:

まずAIにやってもらう

自分で手直ししたほうが速いと思ったらエディタを開いて自分で直す

変更量が多そうだったらAIにまたお願いして直してもらう

エディタを開いて自分で直す作業もAIにお願いすることに置き換え可能

置き換えた場合人間はもはやコードを書いていないことになる

■ 6. 筆者の認識の変化

半年前なら反発したかもしれない発言だが現在の働き方を照らし合わせるとその通りだと認識

頭の中にある漠然としたアイデアを信頼できて疲れ知らずの相棒と相談して形にできる状況を楽しんでいる

本記事もAIに書いてもらったドラフトを修正加筆して完成

(2026/01/23)

Microsoft CEO warns that we must 'do something useful' with AI or they'll lose...

Microsoft CEO warns that we must 'do something useful' with AI or they'll lose 'social permission' to burn electricity on it | PC Gamer

要約:

■ 1. Nadella CEOの基本的主張

世界経済フォーラムでMicrosoft CEOサティア・ナデラがAIの社会的許可について警告

AIが人々やコミュニティや国や産業の成果を変える有用なことに使われなければ公共の支持を失うと発言

エネルギーは希少資源であり健康や教育や公共部門の効率や民間部門の競争力を改善しなければトークン生成にエネルギーを使う社会的許可を失うと指摘

■ 2. 供給側と需要側の課題

供給側の課題:

AI企業と政策立案者はエネルギーとトークンの遍在的グリッドを構築する必要がある

この作業が現在RAM価格の高騰を引き起こしている

需要側の課題:

全ての企業がAIを使い始める必要がある

ナデラはAIを「認知増幅器」や「無限の知性へのアクセス」と表現

求職者はExcelのスキル習得と同様にAIスキルを習得する必要がある

人々がAIスキルを習得することで実体経済における製品やサービスの提供者として向上すべき

■ 3. 具体例と医療分野での応用

医師が患者との時間を増やせる例:

AIが文字起こしを実行

電子医療記録システムへの記録入力を担当

適切な請求コードを入力し医療業界全体（支払者と提供者と患者）により良いサービスを提供

医療専門家による研究ではAIスクライブ使用で「多大な利益」が報告されているがさらなる研究が必要

■ 4. 懸念と批判的視点

AIによる盗聴の懸念:

予防的ケア訪問をより高価な診断訪問に再分類する理由を探すAI盗聴者の存在

米国医療システムの再設計の必要性

LLMの限定的な応用:

汎用LLMがパソコンやインターネットと同程度に革命的であると期待する場合多くのアプリケーションが音声文字起こしやテキスト要約やコードスニペット取得に集約されることは懸念材料

LLMのエラー傾向:

英国警察署長がMicrosoft Copilotのエラーで辞任

これらの機能を中心に社会を再編成するという考えに懐疑的な理由が存在

MIT Media Lab研究者による報告:

数十億ドルの投資にもかかわらず組織の95%がAI採用からゼロリターンを得ている

■ 5. バブル論への反論と将来展望

ナデラのバブル論への見解:

テクノロジー企業のパートナーシップとインフラ支出だけならバブル

AIが生産性曲線を曲げ資本支出だけでなく世界中で経済成長をもたらすと確信

筆者の皮肉的コメント:

RAM価格が正常化する時期を知りたいという指摘

(2026/01/22)

I Made Zig Compute 33 Million Satellite Positions in 3 Seconds. No GPU Required.

I Made Zig Compute 33 Million Satellite Positions in 3 Seconds. No GPU Required. | Anthony T's Blog

要約:

■ 1. プロジェクト概要

astroz は最速の汎用SGP4実装でネイティブZigで1秒あたり1100万〜1300万回の伝播計算を実現

Python経由では約700万回毎秒でpip install astrozのみで利用可能

GPUを使用せずCPUのSIMD命令のみで高速化を達成

汎用実装の定義:

heyoka.pyは複数衛星の同時バッチ処理で高速だが一般的なODE積分器でLLVMのJITコンパイルとC++依存関係が必要

astrozは時間バッチ伝播で2倍高速で単一衛星の複数時刻計算に特化

GPU加速SGP4実装は大規模バッチワークロードで高速だがCUDA/OpenCLセットアップが必要で汎用的ではない

■ 2. SGP4最適化の動機

SGP4は1980年代からTLEデータから衛星位置を予測する標準アルゴリズム

既存実装は元のリファレンスコードの移植版で機能するが高密度時間解像度では遅い

実用的な課題:

1ヶ月のエフェメリスデータを1秒間隔で生成すると衛星1個あたり260万回の伝播計算が必要

地上局ネットワークでの通過予測は数週間にわたりサブ秒精度が必要

接近スクリーニングの軌道解析は近接アプローチを捕捉するため細かい時間ステップが必要

典型的な良い実装で200万〜300万回毎秒だと衛星1個あたり数秒かかり反復解析やインタラクティブツール構築では遅い

■ 3. 初期最適化とスカラー実装

SIMD導入前のスカラー実装で既にRust sgp4クレート（最速のオープンソース実装）と同等以上の性能

主要な設計選択:

分岐のないホットパス:

SGP4アルゴリズムには多数の条件分岐が存在

深宇宙対近地球や異なる摂動モデルやケプラーソルバーの収束チェックなど

可能な限り分岐なし表現として記述

当初はパフォーマンス目的ではなくコードの理解しやすさのため

偶然にも現代CPUが予測可能な命令ストリームを好むため高速化

コンパイル時事前計算:

Zigのcomptimeで任意のコードをコンパイル時に実行可能

SGP4のセットアップ作業の多く（重力定数や多項式係数や派生パラメータ）を一度計算してバイナリに焼き込む

ランタイム初期化や繰り返し計算が不要

constでマークした変数は自動的にcomptimeとして扱われる

スカラー実装で520万回毎秒を達成しRustの500万回毎秒を若干上回る

■ 4. SIMD実装の発見と基礎

SGP4は状態に依存せず各衛星と各時点が独立しているためSIMDに適している

ZigがSIMDを第一級市民として扱う設計:

シンプルな型宣言のみで開始可能

const Vec4 = @Vector(4, f64)で4つの64ビット浮動小数点数のベクトルを定義

イントリンシクスやプラットフォーム検出や条件付きコンパイルが不要

LLVMバックエンドがコード実行環境に適した命令セットを自動的にターゲット

組み込み演算:

スカラーを全レーンにブロードキャストする@splat

LLVMイントリンシクスを通じた自動ベクトル化された超越関数

@sinと@cosはLinux x86_64でのlibmvecなどプラットフォーム最適実装を使用

レーン単位の思考への転換:

スカラーコードではif文で一方のパスを実行

SIMDでは全4レーンが同時に実行されるため両方の結果を計算してレーン毎に選択

両方のパスを計算することは無駄に見えるが分岐予測ミスより高速な場合が多い

SGP4では大半の衛星が同じパスを取るため無駄な計算は少ない

収束ループの処理:

SGP4のケプラーソルバーは各結果が収束するまで反復

スカラーでは許容誤差以下になるまでループ

SIMDでは異なるレーンが異なる速度で収束

解決策はレーン毎に収束をマスクで追跡し@reduceで全員完了を確認

パターン理解後はスカラー実装を一行ずつ変換し元のコードをテストスイートで比較できるよう保持

■ 5. 3つの伝播モード

時間バッチ propagateV4:

最も一般的なワークロードに対応

単一衛星の複数時点を同時に4時点処理

エフェメリスデータ生成や通過予測や軌道解析や接近スクリーニングに使用

衛星の軌道要素がレジスタに留まり4つの出力を計算するため最もキャッシュフレンドリー

最大の初期高速化を実現

衛星バッチ propagateSatellitesV4:

多数の衛星を1つの特定時点で処理

衝突スクリーニングスナップショットやカタログ全体の可視性チェックに使用

4つの異なる衛星を同一時点で同時処理

ElementsV4という異なるデータレイアウトが必要

各フィールドがVec4で4つの異なる衛星の値を保持

コンステレーションモード propagateConstellationV4:

多数の衛星を多数の時点で伝播

ライブデモでは13000個の衛星を1440時点で処理

キャッシュを意識したタイリング戦略:

各衛星の全時点を計算する素朴なアプローチはキャッシュをスラッシング

64時点を全衛星で処理してから次の64時点を処理

時間値がL1キャッシュにホットな状態で衛星バッチをスイープ

タイルサイズ64はL1サイズを作業データサイズで割りSIMDフレンドリーな数に丸めたもの

大規模カタログでは素朴なループより15〜20%高速

■ 6. atan2問題と解決策

SGP4のケプラーソルバーはatan2を必要とするがLLVMはベクトル化されたビルトインを提供していない

スカラー関数を呼び出すとSIMD実装が壊れる

多項式近似による解決:

SGP4の精度要件（モデルに固有の制限がある）では完全な精度は不要

引数を[0,1]の範囲に保ち多項式精度を向上

ホーナー法で計算

@selectを使用した分岐なしの象限補正

多項式近似は約1e-7ラジアンの精度でLEO距離で約10mmの位置誤差に相当

これはSGP4の固有精度限界内で数日間の伝播では数キロメートルの不確実性がある

この数学は複雑でAIの支援を受けて実装

■ 7. Struct of Arraysデータ構造

複数衛星処理のためStruct of Arraysレイアウトを使用

ElementsV4構造体:

各フィールドがVec4で4つの衛星の値を保持

重力モデルや離心率や傾斜角や昇交点赤経などの軌道要素

事前スプラット済み定数をinit時に一度計算

事前スプラット最適化:

ホットパスでの繰り返し@splat呼び出しを排除

毎秒数百万回実行されるコードでは小さな最適化も重要

■ 8. ベンチマーク結果

ネイティブ実装比較（Zig vs Rust）:

1日（分間隔）でastroz 0.27ms対Rust 0.31msで1.16倍高速

1週間（分間隔）でastroz 1.99ms対Rust 2.04msで1.03倍高速

2週間（分間隔）でastroz 3.87ms対Rust 4.03msで1.04倍高速

2週間（秒間隔）でastroz 222ms対Rust 234msで1.05倍高速

1ヶ月（分間隔）でastroz 8.37ms対Rust 8.94msで1.07倍高速

両実装ともスカラー処理で約500万回毎秒を達成

Zig実装がRustを若干上回るのはホットパス最適化とcomptimeの積極的な事前計算による

ネイティブSIMDスループット:

astroz Zig SIMD実装で1200万回毎秒

astroz Zigスカラー実装で520万回毎秒

Rust sgp4で510万回毎秒

@Vector(4, f64)を使用した複数衛星または時点の並列処理でスループットがスカラー実装の2倍以上に向上

Pythonバインディング性能:

2週間（秒間隔）でastroz 160ms対python-sgp4 464msで2.9倍高速

1ヶ月（分間隔）でastroz 5.9ms対python-sgp4 16.1msで2.7倍高速

Pythonバインディングスループット:

astroz Python 700万回毎秒

satkit（Rust）370万回毎秒

python-sgp4 220万回毎秒

heyoka.pyとの比較:

8衛星×1440時点でheyoka.py 1620万回毎秒対astroz 750万回毎秒

1衛星×1440時点でheyoka.py 380万回毎秒対astroz 850万回毎秒

100衛星×100時点でheyoka.py 1550万回毎秒対astroz 840万回毎秒

heyoka.pyは複数衛星バッチで勝利しastrozは時間バッチワークロードで勝利

ユースケースによる選択:

数百の衛星を同時に同一時点で伝播する場合はheyoka.pyが有利

個別衛星のエフェメリス生成や通過予測や軌道解析の場合はastrozが2倍高速

簡単なデプロイメントが必要な場合はastrozがpip installのみでNumPyのみ依存しheyoka.pyはLLVMとC++スタックが必要

■ 9. 実用的なデモ

インタラクティブCesiumビジュアライゼーション:

CelesTrakの全アクティブカタログ約13000個の衛星を処理

1440時点（1日を分解像度）で約1900万回の伝播計算

Pythonバインディング経由で約2.7秒で完了（約700万回毎秒）

TEME→ECEF座標変換に約0.6秒追加で合計約3.3秒

ネイティブZigでは1100万〜1300万回毎秒に到達

高速化により計算のバッチ処理やスケジューリングを考える必要がなくなり必要な時に必要な計算を実行可能

■ 10. 今後の展望と利用方法

今後の開発:

SDP4実装で深宇宙天体に対応（現在は軌道周期225分未満の近地球衛星のみ）

マルチスレッド化でコア全体にスケール

SIMD作業は単一スレッドで実行されており別の倍率が待機中

利用方法:

PyPIで利用可能でpip install astroz

Zigプロジェクトへの追加はzig fetch --save

GitHubでオープンソースとして公開

examplesを参照して統合可能

ライブデモで動作確認可能

(2026/01/22)

プログラマの抱いている「住所」についての誤謬

プログラマの抱いている「住所」についての誤謬

(2026/01/21)

フリーランスは社員みたいにチャンスをもらえない？

フリーランスは社員みたいにチャンスをもらえない？

要約:

■ 1. 結論と前提

フリーランスは社員ほどではないが取り組み方次第で今後生き残るためのスキルを獲得するチャンスはある

早いうちにフリーランスとして色んな現場に参画することは長期的な視点でメリットがある

筆者の報酬は年齢と過去の経歴を加味すると同年代より高くエージェント紹介の単価水準でも高単価の部類

9年ほどフリーランスエンジニアとして培った案件選びや面談のスタンスやチームコミュニケーション改善のナレッジを共有

■ 2. チャンスをもらえない構造の否定

チャンスをもらえないのは選んだ現場とあなたの評価の問題

筆者は技術力が高いわけではなく30代に入ってアルゴリズムを勉強し直している最中

独立当時はウォーターフォール開発で詳細設計から実装を半年ほどのベビーエンジニアステータス

しかし現在や前の会社で多数のチャレンジ機会を獲得:

ゼロイチのプロダクトの初期メンバーに抜擢

未経験言語の実装を任される

エンジニアの採用面談に同席し合否に関わる立場

完全未経験なrustの開発に単価を下げず参画

プロダクトの要になるデータパイプラインの新規構築

顧客管理システムリプレイスの技術選定からリリース前までの実装をリードエンジニアとして推進

「経験が積みづらくなる構造的な力学」があるなら9年間業務委託のエンジニアOnlyな筆者はもっと厳しいスキルで今を迎えているはず

フリーランスなら先に鍛えるべき力が不足していたために「チャンスを与えてくれる現場に出会う能力や見せ方ができなかった」

「フリーランスとして魅力的なマインドを持っていたわけではない」

■ 3. エージェントの存在が将来を不安にさせる

ITエージェントという存在のせいでその力を培わずともなんちゃってフリーランスになれてしまう

「あなたの年齢とスキルで紹介できる案件がない」と言われた瞬間に自分で案件を開拓することをしなかったエンジニアは窮地に追い込まれる

動物園で飼育員がご飯を挙げなかったらどんなに屈強なライオンだって餓死する

Findy関係者の意見:

売り手市場ではなくなってきている状況

エンジニアが企業のニーズを汲み取りアピールできるかが鍵

エージェント視点でも売り手市場の陰りとエンジニアが受け身で居続けることの懸念

■ 4. 正社員とフリーランスの比較

正社員は待ってても来る可能性があるが望んでなくても来る

フリーランスは手を上げ続けなきゃ来ないが望んでないなら来ない

フリーランスが正社員より優れているという主張ではない

100%の責任を追う経験や意思決定の場に参列するのは多くは正社員

賃貸やローン等の社会的信用は企業のエンジニアには到底叶わない

生存戦略的視点で言えば正社員の70から80%程度の役割や権限ならフリーランスにもチャンスはある

案件探しや業務への向き合い方次第

正社員だろうともあっさり辞める時代

チームメンバーだし業務委託だろうともっと良いコード書けるようになってほしいなとコストをかけてもいいと思わせる当時のパーソナリティと案件の目利き力がなかっただけ

業務委託だって強くなって良いコードが書ければそれがコードとして資産になる

ノウハウがそのままプロダクションコードとして残るのがエンジニアという職業の良いところ

■ 5. フリーランスにおける成長の定義

成長の3要素:

案件レベルに直結する技術的成長

案件の獲得率につながる営業的成長

案件の継続に関わるコミュニケーション的成長

営業的なコミュニケーション力とチーム開発で必要とされるコミュニケーション力は別

ロースキルでまず一番先に身につけるべき優先順位:

1: 営業的成長

2: コミュニケーション的成長

3: 技術的成長

営業力の定義:

お客さんに押し売るゴリゴリなパワーではない

日常生活においても役立つコミュニケーションのテクニック的な部分

繰り返し実践することで徐々に自分の身体に染み付く

■ 6. 営業力が大事な理由

理由1:質の高い案件に入り込めれば他の成長は付随する

営業力が上がると高単価の案件に参画できる

期待値と能力があっていないので自己研鑽せざるを得ない

シニアエンジニアの端的なコミュニケーションを理解するために言葉の言い回しや質問の質を上げざるを得ない

質の高い案件獲得を目指すことが一番連動して効率よく成長できる環境を手に入れられる

理由2:面談が「加点評価の場」になるか「減点評価の場」になるかは営業力次第

面談は文字列でわからない人格や雰囲気やコミュニケーションスタイルを把握する大事な場

正社員だろうがフリーランスだろうが対面の会話は最も重視すべき

技術力が突出していないエンジニアが1時間の面談の中でまず探るべきはセールスでいうところの潜在的ニーズ

自分の経歴を語る前にこれを引き出せるかが特に大事

採用の目的(求人票)だけでなくブラインドされたチームの課題を引き出せるかで「相手の事を考える回数」がかなり増える

限られた数十分のあなたのターンで引き出す必要がある

面談が面倒な見極めの場ではなく相手の欠けたピース探しと気持ちよくそのパズルをはめるゲーム感覚で臨める

■ 7. スキルの切り売り問題への反論

スキルの切り売りになる原因:

自分がある意味一番技術力あるチームにいる

新しい知識を入れるチーム文化がない

背伸びして入った現場じゃない

営業行為とは「付加価値」をつける行為

営業力がない人は自分を時給4000円で案件を探し実力に見合う仕事しか紹介されず出会えない

営業に自信があれば時給5000円や6000円で案件を探すまたは決裁前に値上げ交渉をする

今の実力に見合わない仕事を手に入れるチャンスが出てくる

上振れであなたに見合わない仕事はつまり伸びしろを与えてくれる仕事

ダイナミックなスキルチェンジに関わる案件以外は最低時給500円以上は単価アップするような案件を選び続ければ単価が成長の具体値として示してくれる

■ 8. 権限とマネジメント

権限について:

一部の企業は与えないが意欲のある人でも絶対与えられないなんて事はない

高い単価をもらっているとやれるかは別として依頼される確率は高い

高い金払ってるんだからやってよ的な思想

マネジメントについて:

別に関われるし人次第

まとめるのが上手な人なら業務委託がサブリーダー的に使えない正社員の代わりにマネジメントすることはよくある

相性悪い人のマネジメントをしたくない

「マネジメント経験しました」と語れる実績より優秀な人と働ければその人をマネジメントする必要がない

最も良いマネジメントはマネジメントしないこと

いかに仲間を上手に指揮して動かすかではなくいかにマネジメントしなくていい環境を作るかに注力すべき

■ 9. 意思決定と契約継続

意思決定について:

関わりにくく社員の人ほど重要な人が集まるMTGには突っ込まれない

心血注ぎたいプロダクトに出会ったときに社員になればいい

意思決定に関わりたいなら個人開発すればいい

個人開発をした経験は案件で関わったプロダクトより自身を持って技術選定やこだわりポイントを語れる

ある種の営業力強化になる

契約継続について:

すぐ切られるかは人による

6年以上同じ現場にいる人もいれば1ヶ月持たず即契約終了される人もいる

雇用形態的に切りやすいのは事実だが働きやすくチームにプラスになるメンバーを予算の都合がない限り簡単には切らない

切られてしまうならそれはあなたの目利きが悪かった

この世は等価交換でギブとテイクがマッチする会社を探すべき

■ 10. フリーランスの推奨と戦略

20代から30代前半にこそフリーランスを一度くらいは経験するべき

早期に複数社の現場経験ができることで多種多様な現場のコードを見ることができる

コードリーディングがエンジニアにとって一番大事で自分のコードや設計の多様性を広げることに繋がる

「3年で1社」と「3社を1年ずつ」では後者の方がエンジニアとしての成長を実感するという経験則

労働基準法に守られない立場で数年ワーカホリックに働くという経験をしたからこそ同年代よりは少しいい生活ができている

スキルフルになってからでないとフリーランスになるのは怖いでは既に今のAIトレンドの時代では遅いこともある

雇用形態にかかわらず自分のやりたいプロダクト単位で仕事を選べる力をつければ雇用形態は二の次

フリーランスになったらできればエージェントを使わずに直契約できる会社を探すという経験もしたほうがいい

エージェントの問題点:

企業の手数料が35%からと高額

フロントの営業マンの技術理解力はエンジニアほど高くない

要望を言ってもマッチする案件が来る可能性は自分で探すより低い

エージェントガチャもある

エージェントのフォローがなくても案件を獲得できるという成功体験はAIによるジュニアからミドルエンジニア供給過多問題を乗り越えるために必要かもしれない

中間マージンも減ってお互いWin-Win

■ 11. まとめ

チャンスはあり参画する案件とあなたの能力次第

フリーランスは本来先行して身につけるべき能力は営業力

あなたの単価は任されるチャンスの範囲

雇用形態関係なく「人としての相性」がまず大事

エージェント使わずに直契約取れるかチャレンジ

MEMO:

個人事業主が受け身でいちゃダメよねという話である

(2026/01/21)

なぜ、IT業界"にわか"層は「Web系がSIerに比べて技術的に優位」という幻想を抱くのか？

なぜ、IT業界"にわか"層は「Web系がSIerに比べて技術的に優位」という幻想を抱くのか？

要約:

■ 1. 議論の構造

IT業界においてWeb系とSIerを比較する議論は長年繰り返されている

多くは技術的優劣という形で語られている

議論の中心は技術そのものではなく認知の歪み

ITのにわか層においてWeb系は技術的に優位でSIerは劣位であるという単純化された幻想が強固に信じられている

議論の対象は技術文化ではなく人事文化とマネジメント構造そしてそれを誤認する人間側の認知メカニズム

■ 2. 技術は個人にしか宿らないという前提の欠落

技術は組織や業界に自動的に蓄積されるものではない

個人の思考と試行錯誤の結果として身につくもの

この前提が抜け落ちた瞬間「場所に行けば技術が身につく」という誤解が発生

Web系というラベルがあたかも技術力を付与する魔法の環境であるかのように語られる

実際には考え続けた人だけが技術を獲得し考えない人はどこにいても何も残らない

技術は人に宿る

環境は確率を変えるだけ

自動付与は存在しない

この三点を無視した議論はすべて幻想

■ 3. 人事文化やマネジメント文化との混同

Web系とSIerの違いは技術文化ではなく人事評価の軸とマネジメントの設計思想

Web系の特徴:

アウトプットが短い周期で可視化される

個人の成果が評価に直結しやすい構造

SIerの特徴:

分業と調整が前提

説明責任や役割遂行が評価の中心

にわか層の誤認:

評価軸の違いをそのまま技術力の差と誤認

評価構造、役割設計、責任分散というマネジメント上の差異が技術文化の差として誤変換されている

■ 4. 可視性バイアスと生存バイアス

Web系の可視性:

成果物が外部に公開されやすい

GitHubや技術ブログなどを通じて技術的アウトプットが目に入りやすい環境

可視性の高さが「Web系には優秀な技術者が多い」という印象を強化

実態との乖離:

単なる観測可能性の問題であり実態の分布とは一致しない

技術的に尖った人が目立ちやすくそうでない人が視界から消えやすいという偏り

認知バイアスの構造:

可視性、選択的観測、生存者偏重という認知バイアスが幻想を補強

■ 5. 経済合理性と人材分布の現実

人材分布の決定要因:

人材の分布は理想論ではなく経済条件によって決定

高い給与、安定した雇用、大規模な採用母集団を維持できるのは大企業

日本の現実:

大企業の多くがSIer側に存在

優秀な人材の絶対数はSIerに多く集まる

Web系の限界:

密度では優れて見えても人数と資金力の差を覆すことはできない

現実要因:

給料水準、会社規模、知名度、母集団サイズが最終的な人材分布を規定

■ 6. SIerが人をだめにする構造とその誤解

SIerの構造的問題:

SIerという組織が多くの人をだめにしてしまうのは事実

技術文化が劣っているからではない

技術を深く考えなくても生存できるレーンを大量に用意しているから

構造の特徴:

人を選別しない代わりに人を鍛えもしない

成長しない人が大量に残る

外部からは「技術的に弱い集団」に見える

誤解の構造:

構造的温存、非選別性、成長不要ルートという特徴が文化論として誤って語られている

■ 7. にわか層が幻想を欲しがる心理

心理的動機:

裏技への期待と自己正当化の欲求

努力や思考を積み重ねるよりも正しい場所に行けば解決するという物語は非常に魅力的

自身の立場を誇るあるいは嘆くためのポジショントークとして文化論は便利

議論の性質:

真偽は重要ではなく感情の整合性が優先される

幻想を必要とする動機:

裏技願望、責任転嫁、自己物語化

■ 8. 「技術文化」という幻想上の言葉

本来の意味:

技術文化という言葉は本来思考の深さや問題解決姿勢を指すはず

現実の使われ方:

単なる業界ラベルや雰囲気の話に矮小化されている

Web系という言葉に付与される先進性のイメージが技術文化と短絡的に結びつけられる

問題点:

概念の乱用であり議論の精度を著しく下げる

概念混同、ラベル依存、定義不在が誤った理解を固定化させている

■ 9. まとめ

ITのにわか者がWeb系をSIerより技術的に優位だと信じる理由は技術の問題ではない

原因の構造:

個人要因を無視

評価構造を誤認

認知バイアスに流される

経済合理性を見落とした結果

SIerの実態:

多くの人をだめにする構造を持っている

それは所属する人間の技術の低さを意味しない

Web系の実態:

強く見えるのは密度と可視性の問題

分布全体を見ればどっこいどっこいに収束

根本的な真実:

技術は個人に宿る

人は金と規模に集まる

この二点を直視しない限りこの幻想は繰り返され続ける

論評:

■ 1. 根本的な自己矛盾

セクション2では「技術は個人にしか宿らない」「環境は確率を変えるだけ」と主張

セクション6では「SIerという組織が多くの人をだめにしてしまうのは事実」と主張

環境が人をだめにするほどの決定的影響力を持つなら技術は個人に宿るという主張は崩壊する

著者は自分で設定した前提を自分で否定している

■ 2. 証拠の完全な欠如

記事全体が著者の印象と推測のみで構成されている

証拠が欠如している要素:

にわか層が実在するという証拠

その幻想が広く存在するという調査データ

Web系とSIerの技術力分布に関する実証的データ

すべてが断定形で書かれているが根拠は示されていない

■ 3. 藁人形論法

にわか層という架空の敵を設定しその愚かさを論じる構造

問題点:

誰が実際にそのような主張をしているのか不明

その主張がどの程度広まっているのか不明

批判対象が具体性を欠き著者の想像上の存在である可能性が高い

■ 4. 論理的飛躍

セクション5の論理は大企業はSIer側に多いため優秀な人材の絶対数はSIerに多いというもの

成立しない理由:

GoogleやMetaやAmazonなどの巨大Web系企業の存在を無視

給与だけで人材分布が決まるという単純化

優秀の定義が不明確

大企業の数と採用規模の関係が検証されていない

■ 5. 定義の曖昧さ

批判的検討に耐える定義が一切存在しない

曖昧な用語:

にわか層とは誰か

Web系とSIerの境界はどこか

技術力をどう測定するのか

優秀な人材の基準は何か

■ 6. 可視性バイアスの誤用

著者自身が可視性バイアスを指摘しながら自分の主張も可視性バイアスに基づいている

SIerが人をだめにするという認識自体が問題のある事例が目立ちやすいという可視性バイアスの産物である可能性

自分が批判する認知の歪みを自分自身が犯している

■ 7. 結論の不在

タイトルはなぜ幻想を抱くのかだが記事は以下に答えていない:

その幻想が本当に存在するのか

存在するとしてそれが問題なのか

著者の主張であるどっこいどっこいが正しいという根拠

技術は個人に宿るや人は金と規模に集まるという結論は最初の問いとは無関係

■ 8. 総評

記事は議論の体をなしていない

著者はにわか層を批判しているが自身の主張こそが根拠のない思い込み論理的矛盾藁人形論法に満ちている

真剣に論じるために必要な要素:

実証的データの提示

用語の厳密な定義

論理的一貫性の確保

自己矛盾の解消

現状では主張したいことを先に決めてそれらしい理屈を後付けした印象論に過ぎない

(2026/01/21)

I/Oの負荷分散の話。書き込み側の負荷分散。DB1台のノードで書き込みがサチるなら、2台→4台→8台...

I/Oの負荷分散の話。

書き込み側の負荷分散。

DB1台のノードで書き込みがサチるなら、2台→4台→8台とノードを増やしてデータを書き分ける（シャーディング）。

読み込み側の負荷分散。

同じデータを読みたいクライアントが多いなら、そのデータを別のDBノードにコピーして配って読ませる（リプリケーション）。

RDBでやるなら、Writer : Read Replica = 1 : N のクラスタを複数台用意する構成になる。ただし、データのヒントに基づいてどの Writer を選ぶかは開発者の責任。当然、クラスタをまたいだ SELECT JOIN もできない。ソシャゲは基本これ。

クラスタが増えたときのリハッシュも「気合いで頑張れ」になる。運用負荷はかなり高い。体制があれば別にこれでもいいけどね。

まぁ、これはスタートアップではマジで無理っす、って話になることが多いので…… 書き込みも読み込みもそれなりあるなら、前段に DynamoDBなどを置いてCDCを介して、後段の DB クラスタにゆっくり書く構成にすることが多い。

そう、これはほぼ CQRS / Event Sourcing のことなんだよな。書き込みのシャーディングは DynamoDB が自動でやってくれるし、めちゃくちゃ安定的に捌ける。

@j5ik2o

(2026/01/21)

jQuery 4.0正式版が公開。10年振りのメジャーバージョンアップ。IE10以前がサポート外、XSS防止など

jQuery 4.0正式版が公開。10年振りのメジャーバージョンアップ。IE10以前がサポート外、XSS防止など－ Publickey

jQuery開発チームは、10年振りのメジャーバージョンアップとなる「JQuery 4.0」正式版のリリースを発表しました。

ちなみに2026年1月は、最初のバージョンのjQueryが2006年1月にはじめて公開されてからちょうど20周年に当たります。

MEMO:

長生きだ

(2026/01/20)

OOP はくそ，DDD はムズい，GoF は古い，Next.js はでかい，React は難しい，仮想 DOM はクソ...

OOP はくそ，DDD はムズい，GoF は古い，Next.js はでかい，React は難しい，仮想 DOM はクソ，静的型付けじゃない言語はクソ，TS の型は弱い，SPA が良い，every/some の単位元，IEEE 754 の不可解な計算に驚き，OSS は儲からない，ならお前がやれは意味無い，はてブコメントはクソ，休日に勉強は必要か，などずっと同じ話しかしてない

@ubugeeei

MEMO:

人間は年を取ると同じ話題を延々ループさせる生き物

(2026/01/20)

AIネイティブ時代のプロダクト設計──なぜ「完璧な仕様」は機能しなくなったのか

AIネイティブ時代のプロダクト設計──なぜ「完璧な仕様」は機能しなくなったのか - Nothing ventured, nothing gained.

要約:

■ 1. AIがプロダクトに与える変化の認識

AIがプロダクトを大きく変えると感じ従来と何が違うのかが気になってきた

投資家として海外を含むスタートアップやプロダクトを見る機会が増える中でAIを前提に設計されたプロダクトには従来とは明らかに異なる成功パターンがあるように感じている

AIが中心となるプロダクトの設計には完璧な仕様を追い求める従来の手法とは異なる新しい姿勢が求められている

プロダクトを完成させるのではなく変化し続ける前提で設計するという姿勢が必要である

■ 2. Cursorの事例とAIネイティブ設計

AIコードエディタとして登場したCursorはVS Codeという巨大な既存プロダクトが存在する市場においてまたたく間に支持を集めた

VS CodeにもGitHub CopilotをはじめとするAIサービスのアドオンを追加することはできAI機能そのものは利用可能だったにもかかわらずである

Cursor以前のアプローチ:

既存のエディタにAIアシスタントを追加するというものだった

これは従来のプロダクト開発の延長線上にある発想である

すでに完成されたプロダクトが存在しそこに新しい機能を付け加えるという考え方である

Cursorのアプローチ:

AIがコアにあることを前提としてゼロからエディタを再設計した

AIは追加された機能ではなくプロダクトの中心的な存在である

リポジトリ全体をセマンティックにインデックス化し複数ファイルにまたがる変更を生成し開発者の意図を理解して自律的に行動する

これはAIが完璧に機能するという前提に立ちワークフロー全体を再構築した結果である

このCursorのアプローチが有効であることはその後GoogleがAntigravityという形で追従したことからも明らかである

■ 3. 決定論から確率論への転換

AIネイティブプロダクトでは従来の仕様設計が限界を迎える理由の整理が必要である

AIを機能として追加するのではなくプロダクトの中心に据えるという設計への転換が起きている

この変化を一言で言えば設計対象が変わったということである

ソフトウェアが決定論的な存在から確率論的な存在へと変わったことによって起きている

従来のプロダクト設計:

振る舞いを固定した完成物を設計する仕事だった

入力と出力の関係を定義し想定される状態やユーザーフローを網羅し意図した通りに動作することを保証する

その前提にあるのはソフトウェアは設計者の意図通りに振る舞うべきだという考え方である

生成AIを中核に据えたプロダクト:

設計する対象は完成物ではなく学習し続ける存在になる

プロダクトはリリースされた時点で完成するのではなく利用される中で振る舞いを変え進化し続けることが前提となる

学習し続ける存在とはどのデータを集めどの文脈でAIに渡しどのフィードバックを次の振る舞いに反映させるかという一連の仕組みを指す

設計対象の変化は単なる機能や実装の差ではない

Cursorが示したのはプロダクト設計における根本的なパラダイムシフトである

従来のプロダクトは完成させて出荷するものだった

生成AIを組み込んだプロダクトはリリース後に学習し続ける生態系として設計される

■ 4. 変わる人間の役割

テックリードやプロダクトマネージャーが何をすればよいのかという問いがある

答えは完璧な仕様を書くことではない

良い方向に学習する構造を設計することそしてプロダクトを進化させる仕組みを整えることである

プロダクトはもはや完成させて出荷するものではない

プロダクトはリリース後に学習し続ける存在である

人間の仕事はこの生態系が健全に進化するための構造を設計することである

プロダクトマネージャーの役割の変化:

従来のプロダクトマネージャーは機能の門番だった

どの機能を作るかどの順番で作るかどのように作るかを決める存在だった

AIネイティブプロダクトを担当するプロダクトマネージャーは学習システムの設計運用責任者である

具体的にはAIモデルそのものを鍛えるのではなくどのデータや文脈を与えるかどのフィードバックを取り込みどの振る舞いを強化抑制するかといった学習が回る構造そのものを設計運用する役割を担う

ここでの学習はモデルの再学習を意味しない

多くのAIネイティブプロダクトは自らモデルを開発していない

モデルを持っている場合でも有料プランの利用ユーザーデータを直接モデル学習に使わないことがほとんどである

それでもプロダクトは使われるほどに振る舞いを変えていく

その違いを生むのはモデルの外側に設計されたデータ文脈履歴フィードバックの構造である

つまりプロンプトなどのAIへの指示方法でありAIに参照させるデータとしてのコンテキストである

技術的にはRAGであったりMCPであったりする

AIネイティブプロダクトでは前提条件が変わる

振る舞いを完全に制御できない以上問われるのは個々の機能ではなく学習がどう回りどう修正されるかという構造そのものである

人間に求められるのは何を作るかを細かく決めることではない

AIがどのように振る舞いを変えていくのかその前提となる構造を設計し方向を調整し続けることである

■ 5. AIネイティブプロダクトにおける学習

人間が設計すべき構造が実際のプロダクトの中でどのように形になっているのかを見る必要がある

AIネイティブなプロダクトにおいて人間がどこに介在し何を設計しているのかという問いがある

AIネイティブエディタの例:

リポジトリ全体がセマンティックにインデックス化されコードは単なるテキストの集合ではなく意味を持つ構造として扱われる

開発者がどのような編集を行ったかどの提案を受け入れどの提案を拒否したかといった利用の痕跡が継続的に蓄積される

重要なのはこれらが単なるログではなく次にAIを使う際の入力文脈として再利用される点である

どの情報を参照させるかどの履歴を重ねるかといった判断は人間が設計した前提に基づいて行われる

ここで起きているのはAIの中身が変わることではない

固定されたモデルはそのままにどの情報を参照させどの履歴を重ねどのフィードバックを次に活かすか

その積み重ねによってプロダクト全体の振る舞いが変わっていく

AIネイティブプロダクトは学習し続ける存在として設計されている

利用のたびに得られるデータが次の振る舞いに影響を与える

モデルを自ら開発しないプロダクトであっても学習する構造を内包することは可能である

この構造をどう設計しどう運用するかこそが人間に委ねられた最も重要な仕事である

超ざっくりとした設計イメージの例:

AIが出した修正提案に対して開発者が採用したか拒否したかをログとして残す

そのログを用いて次回以降の提案時に採用されやすい修正パターンを優先的に提示する

繰り返し拒否される提案パターンについてはルールやプロンプトを調整し出力されにくくする

重要なのは精度の高いアルゴリズムではない

提案から選択から次の提案に反映という学習のループが意図した方向に回るよう設計されているかどうかである

■ 6. データ設計における蓄積から循環への転換

学習し続ける存在をどのように作り上げていけばよいのかという問いがある

鍵となるのはデータである

ただし生成AI時代において問われているのはデータの量ではない

従来のデータの価値:

蓄積にあった

どれだけ多くのデータを集めたかどれだけ詳細な情報を記録したか

データウェアハウスに大量のデータを保存し分析ツールで可視化する

これがいわゆるデータ駆動型の意思決定だった

生成AI時代におけるデータの価値:

循環にある

データは集めただけでは価値を生まない

利用され学習に回されAIの振る舞いを変えその結果として新たなデータが生まれる

この循環が回って初めてデータは資産になる

フィードバックループの設計こそがAIネイティブプロダクトの成否を分ける

AIを導入してもフィードバックを回収せず学習に活かさなければプロダクトは賢くならない

その結果プロダクトは学習する生態系ではなく固定されたツールのままにとどまる

この循環が回り始めたときそれは強力な競争優位性となる

他社が容易に模倣できない独自のデータと学習ループがいわばデータモートとして機能する

生成AI時代においてはソフトウェアそのものの差別化は急速に難しくなっている

AIがコードを書き機能実装の大部分を肩代わりしてくれるようになったことでソフトウェア開発の再現性は飛躍的に高まった

オープンソースモデルや汎用APIの普及も相まって技術的な障壁は大きく下がっている

誰でも一定水準のAI機能を備えたプロダクトを作ることができるようになった

だからこそ差別化の源泉はデータに移る

ただし重要なのは独自のデータを持っているかではない

そのデータを学習に回し改善のループを回し続けられているかどうかである

多くの企業はすでに独自のドメイン知識とデータを持っている

日本企業も例外ではない

問題はそれらが十分に循環していないことである

生成AIを既存業務に部分的に導入するだけではこの循環は生まれない

プロダクトそのものをAIネイティブな前提で再設計する必要がある

新興企業の戦略:

フィードバックループをできるだけ早く回すことである

データの量が少なくても利用と改善の循環を高速に回すことができればAIは急速に賢くなる

AIが賢くなればユーザー体験が向上しユーザーが増える

ユーザーが増えればデータが増える

この好循環がやがてデータモートを形成する

Cursorの成長はそのことを端的に示している

独自データをすでに持っている企業にとってもフィードバックループを早く回すという考え方は同様に重要である

派手な先行事例が出そろうのを待っていては競争優位性は築けない

自社の事業にAIを組み込みAIネイティブなプロダクトへと転換していく

そのための第一歩がデータを蓄積ではなく循環として設計し直すことである

重要なのはフィードバックの量ではなく向きである

誤ったシグナルを回せばプロダクトは高速に劣化する

人間は学習が向かう方向に最低限のガードレールを引く必要がある

フィードバック設計の例:

どの提案を評価対象とするのかどの操作を良いシグナルと見なすのかを最初からすべて自動化しようとしない

初期段階では人間が明示的にこれは良いこれは悪いと判断するポイントを絞り込む

学習が誤った方向に進まないよう制御する

フィードバック設計とはそのための最小限の安全装置である

■ 7. AIネイティブプロダクトはAIネイティブな組織でしか作れない

この話は技術の話だけではない

学習システムは個人の工夫や一部のチームの努力だけでは成立しない

AIネイティブなプロダクトはAIネイティブな人と組織でなければ作れない

見た聞いた調べた範囲ではプロダクトに関わる人間がAIを理解していない組織でAIネイティブなプロダクトがうまくいった例はない

AIネイティブ組織の特徴:

会議の中でこの挙動はモデルの限界なのかそれともコンテキストやデータ設計の問題なのかを議論できるかどうか

KPIについても機能が予定通り完成したかではなく学習のループが回り振る舞いが改善したかを問う指標に置き換えられているか

こうした具体的な問いが日常的に交わされているかどうかがAIネイティブ組織かどうかの分かれ目になる

論文を読めという話ではない

実際に使い自分の手で試し失敗し挙動の癖を体感しているかどうかが重要である

AIをブラックボックスとして扱ったままでは学習する構造を設計することはできない

作る経験も欠かせない

モデルを自作する必要はないがプロンプトやコンテキストデータの与え方ひとつで振る舞いが大きく変わることを身体感覚として理解している必要がある

AIネイティブプロダクトとはAIを前提に思考し設計し試行錯誤できる人間によってのみ生み出される

意思決定の速さが何より重要である:

生成AIの進化は極めて速い

半年待てば状況は一変する

このスピードに追いつくためには完璧な検討や合意形成を待っている余裕はない

試し学び修正するそのサイクルを回し続けられるアジリティの高い人と組織でなければAIネイティブな競争には参加できない

これは組織の規模の問題ではない

大企業であろうとスタートアップであろうと条件は同じである

AIネイティブプロダクトを作れるかどうかはAIネイティブな人と組織になれているかどうかで決まる

■ 8. 結論

プロダクト設計とはもはや機能や画面を設計する仕事ではない

変化し続ける前提に立ち学習が回り続ける構造とそれを回し続けられる人と組織を設計する仕事である

あなたのチームはどこまで機能の設計から学習する構造と組織の設計へと軸足を移せているだろうかという問いかけがある

(2026/01/20)

誰も思い出さないが、東大入試を解くAIの研究開発に失敗した挙げ句、適当に哲学的にでっちあげた...

誰も思い出さないが、東大入試を解くAIの研究開発に失敗した挙げ句、適当に哲学的にでっちあげた人間の教育論を振りかざして研究失敗を煙に巻いて、「私は研究に失敗しないんですよ」とうそぶいていた例のあの研究者、元気かな。

しかし、Geminiが共テを制覇するレベルになると、果たしてこの共テとかいう「茶番」はいつまで続けられるのか。生徒側の方がモチベがなくなるだろうに

@alfredplpl

@EzoeRyou

MEMO:

新井紀子先生、未だに読解力が云々みたいな商売しているそうで哀しくなってくるな

世界のすごいプログラマは個人ホームページでロングテールに発信をしていることが多い。これは...

世界のすごいプログラマは個人ホームページでロングテールに発信をしていることが多い。これはユーザー投稿タイプのサービスの寿命よりも自分のキャリアの方が確実に長くなるためです。（世界的にdevtoやmediamの没落が例）

個人的にはこのトレンドをめちゃくちゃ支持しています。

うほうほ！（鳴き声）

@labelmake

MEMO:

WEBサービスの寿命は然程長くなく、運営が稼げなくなるとサクッとサ終されてしまう
それ自体は仕方ないことだが、そんなところに自分のデータを預けるのは流石に不安なので最初からセルフホストでいくのが合理的な判断

(2026/01/19)

とりあえずApproveはもうやめよう

とりあえずApproveはもうやめよう #GitHub - Qiita

要約:

■ 1. 問題提起と背景

コードレビューにおいて素通しでApproveしてしまう状況が多く発生している

思考停止でのApprove実施はレビュープロセスの形骸化を招く

主な要因として理解不足・権威への盲従・時間不足の3つが存在する

■ 2. ケース別対処法

正直理解できない場合:

スキルセット不足による理解不能:

素直に質問コメントを残す

勉強不足を恥じる必要はない

質問により自身の知識増加と実装者の見直し機会創出という2つのメリットが得られる

シニアエンジニアのコメントを観察し新たな視点を取り入れる

PRの目的理解不能:

実装者の説明不足である可能性が高い

チケットリンクや背景説明の追記を依頼し差し戻す

変更量過多による本質的変更の理解不能:

PR分割を指摘することで適切なレビューを実現する

無理に全部読まずPR粒度の改善を求める

自分より知識がある人が実装している場合:

権威バイアスは即座に捨てるべきである

凄腕エンジニアでもタイポや削除漏れは発生する

高度すぎる複雑さは運用負債となる可能性がある

難しいと感じた場合は可読性向上を提案する

レビュー時間を取ることができない場合:

コードレビューは品質担保のための正式な業務である

コンテキストスイッチコスト削減のためレビュー時間を固定化する

急ぎでなければ朝一番での実施が効果的である

■ 3. レビュー依頼側の心がけ

タスク・実装の細分化:

PR変更行数の最小化がレビュアーの心理的ハードル低下につながる

小さなPR複数回の方がトータルマージ時間は短縮される

機能追加とリファクタリングの分離など工夫が重要である

自己レビューの徹底:

Files changedタブでの変更内容確認によりデバッグコード残存等を発見できる

実装時の判断理由をコメントとして事前記載する

レビュアーの納得感向上と前提勘違いの早期発見につながる

Descriptionに背景・目的・テスト結果等の証跡を明記する

実装者としての責任意識:

一番理解しているのは実装している自分であるという矜持を持つ

レビュアー頼みではなく自信を持ってPRを出す

実装の端々に責任感の有無が現れる

■ 4. 現代のレビュー環境

ツール活用による負担軽減:

LinterのCI実行による文法チェック自動化

PolicyAgentによる組織ルール遵守の自動化

AIレビュー導入によるコスト削減

ツールでコスト低減可能だが人間レビューで担保できる品質は必ず存在する

AI進歩に伴う課題:

大規模PR増加による確認負荷上昇

意図不明のままPR提出されるケース発生

AI盲信による品質低下リスク

人間レビュー対象と自動チェック対象の分離が必要

実装前の設計・方針レビューの重要性増大

思考履歴の言語化と記録が重要

■ 5. 結論

わからないことを質問するのは恥ではない

間違いを指摘するのは失礼ではない

思考停止Approveを止め一言でもコメントを入れることから開始する

小さな一歩が自身とチームの成長につながる

(2026/01/19)

AIとDB設計を考えてみた(後編) : トランザクションの整合性はDynamoDBに任せたい

AIとDB設計を考えてみた(後編) : トランザクションの整合性はDynamoDBに任せたい

要約:

■ 1. マスタ管理の拡張性

疑問の提起:

シングルテーブル設計はスケールが容易なDynamoDBなどのNoSQLで定番な方法でRDBであるPostgreSQLで耐えられるのだろうか

マスタが巨大化すると詰むのではという疑問

結論:

特に問題はない

理由:

RDBはスケールしないと言っても数十万件くらいなら余裕で捌ける

前編で説明した全マスタをまとめて取得するのはどこかで限界が来るけど取得時にMetadataによるフィルタリングをすれば適切に絞り込みが可能

運用が続いて規模が大きくなったら無理が出るのは仕方がない問題が出たときにリファクタすれば良い

そもそも肥大化するデータはもはやマスタとして扱うのは正しくなくトランザクションとして扱うべき

大抵なんとかなるしなんとかならなかったらトランザクションに寄せればいいよね

■ 2. 普通のリレーションの問題点

通常のアプローチ:

トランザクション用のテーブルを作る

マスタのcodeを外部キーに持たせる

JOINしてトランザクションと紐づくマスタをセットで取得する

問題点:

マスタがトランザクションに拘束されることになる

前編で実現した柔軟なマスタの変更が封印されてしまう

考え直す必要がある

■ 3. トランザクションをマスタから自律させる

問題の本質:

マスタが変更されると古いマスタ情報が消えてしまうのが問題

解決策:

トランザクションの中に必要なマスタの情報をコピーしてまとめて保存する

この単純で分かりやすい力技はとても効果的

マスタがどれだけ破壊的に変更や削除されてもトランザクションデータは当時の姿のままで生き残り続ける

手法の名称:

こういった手法は一般的にスナップショット・パターンと呼ばれている

■ 4. DynamoDBの採用理由

PostgreSQLでの限界:

PoCなどの大きくスケールしないケースであればトランザクションもマスタと同じようにJSONBでPostgreSQLの1つのテーブルに保存しても問題ないかもしれない

仮にもトランザクションなので一般的なアプリであれば使っているうちにデータは増え続ける

しかもマスタのデータをトランザクションにコピーするのでデータ量も増える

スケールできるように考えるべき

DynamoDB採用の利点:

スケーラビリティ: トランザクションデータは増え続けPostgreSQLでも数十万件程度なら問題ないが数百万件や数千万件となるとシンプルに扱うことが困難でDynamoDBなら自動的にスケールするためこの心配がない

書き込みパフォーマンス: トランザクションは頻繁に書き込まれDynamoDBであればキーバリューストアとして高速な書き込みに最適化されている

アクセスパターンが明確: トランザクションは通常特定のキーで検索されDynamoDBはアクセスパターンが事前に定義できる場合に最高のパフォーマンスを発揮しマスタのような自由な検索は不要

使い分け:

検索性が必要なマスタ管理ではPostgreSQLを採用

スケーラビリティが重要なトランザクションではDynamoDBがよさそう

■ 5. ルーズなSQLと厳格なNoSQL

PostgreSQLでのマスタ:

スキーマレスなJSONBで何でも受け入れる

構造の変更が自由

整合性チェックはアプリ側に任せる

ルーズで柔軟

DynamoDBでのトランザクション:

スナップショット・パターンで当時の状態を厳格に保存

一度書き込んだら変更しないでイミュータブル

データの整合性は書き込み時点で確定

厳格で不変

設計思想:

マスタは変わるものだから変更に強い柔軟な設計にする

トランザクションは変わらないものだから厳格に保存して整合性を保つ

一見しただけだとRDBとNoSQLに求めるものが逆転しているように見えるかもしれないがデータの性質に合わせてDBの使い方を考えればこの設計も自然に見えてくる

■ 6. 正規化についての考察

正規化を避けてきた理由:

正規化や非正規化に囚われずにゼロベースで考えデータをありのままに扱いたかった為

正規化の目的の歴史:

正規化理論が確立された50年前の状況を振り返る

ストレージが高価だったためコストの観点からデータの冗長性排除が必須だった

更新処理が重かったため更新回数を最小限にする設計が必須だった

トランザクション処理が複雑だったため更新箇所を1箇所に集約する必要があった

つまり正規化の目的はデータの冗長性排除や不整合の防止というよりも限られたリソースの中で更新処理を効率的に行うことにあった

現代の環境:

ストレージコストが劇的に低下したためコスト観点では冗長性はある程度許容できる

読み取り速度が物理的に向上したためJOINによる複雑な結合よりも冗長でもシンプルな構造の方が速い

クラウドを活用すればスケールアウトも容易になったため正規化による更新箇所の集約よりもスケーラビリティで対応できる

ビジネスのスピードが加速したため厳密性よりも柔軟性が重要

制約の変化:

2026年現在のDB設計は50年前と比べて制約の性質が根本的に変わった

正規化が前提としていた1970年代の制約から解放され新たな制約である開発スピードが支配的になった現代ではデータの性質に応じて正規化しない選択肢も合理的

重要な考え方:

新規システム開発では正規化しないほうがいいという単純な話ではない

RDBだから正規化でもモダンだから正規しないでもなくデータの性質や規模や更新頻度や一貫性の要件や変更速度の要求やチームの状況を考えたとき何が最適かを考えることがモダンな設計の本質

■ 7. まとめ

エクセルでマスタ管理をできる程度のアプリのDB設計のポイント:

マスタ管理はPostgreSQLとシングルテーブルとJSONBで小規模で変更が多いデータで検索の柔軟性が必要でスキーマレスで構造の変更に強い

トランザクションはDynamoDBとスナップショット・パターンで大規模で書き込みが多いデータでアクセスパターンが明確でマスタのデータを含めることで整合性を保証

設計の特徴:

DBが原因でアプリの拡張性が損なわれるということを避けるDB設計をGeminiくんに考えてもらった

その結果マスタは柔軟に作る為にPostgreSQLを使いトランザクションは整合性を確保する為にDynamoDBを使うという直感とは異なる考え方でありながらマスタはPostgresqlでトランザクションはDynamoDBというとても普通なDB使い分けというちょっと面白い設計になった

(2026/01/19)

AIとDB設計を考えてみた(前編) : マスタ管理はシングルテーブル設計+PostgreSQLがいいかもしれない

AIとDB設計を考えてみた(前編) : マスタ管理はシングルテーブル設計+PostgreSQLがいいかもしれない

要約:

■ 1. はじめにと背景

DB設計への姿勢:

個人的にDBというものに対してあまり興味がない

基本的にDB設計は詳しい人に任せたいと思っている

PoCやスモールスタートでの課題:

ある程度以上の大きめのシステムならそれで良いがPoCやスモールスタートの場合だとDBだけを切り離せるほど人的リソースを割けないことも多い

外部にDBを丸投げしたことにより知見がなくなりDB起因でアプリの機能追加や変更が困難になるといった事態も避けたい

記事の目的:

なるべくアプリ開発の邪魔にならないDB設計を考えておきたいとGeminiくん相手に壁打ちしてみた

硬い設計をするのが一般的なマスタ管理に柔軟性の高いシングルテーブル設計を採用しNoSQLの定石であるシングルテーブル設計をPostgreSQLのJSONB機能で実現するアプローチが登場した

■ 2. モダンなアプリ開発に求められるDB設計

対象システムの特徴:

柔軟でモダンなシステムで規模は大きくないがモダンなシステムをなるべく柔軟に作ることを考える

取り敢えずマスタを対象に考えDB設計ではよくマスタとトランザクションに分けて考えるのでまずはマスタについて考える

シンプルな構造を扱うユーザーの意見を素早く取り入れたいのでエクセルで作ったマスタ管理台帳を簡単に取り込めることを前提にする

人間が全体を管理できる程度にシンプルなマスタということ

自由度は高く項目の増減や変更の自由度は高くしたいモダンなアプリは変更に強いことが求められる

従来のDB設計との違い:

従来は多くのシステムのデータベースには巨大なデータを扱える堅牢な設計を求められること多かった

今は誰にでも気軽にアプリを開発してデプロイして公開できる時代

モダンな開発では規模は小さいけど柔軟性が求められる事が多く従来のDB設計では上手くいかない事もある

アプローチ:

従来のDB設計は一旦横においてエクセルで実施したマスタ定義をなるべくそのままシステム化することを考えた

■ 3. GeminiくんのDB設計提案

設計の概要:

マスタの定義をすべて一つのテーブルに集約する

1つのテーブルに全ての項目を放り込むという大胆な設計を提案してきた

よく考えると実際にこれが理にかなっている

テーブル構成:

master_type: カテゴリやステータスなどの区分でエクセルのシート名に相当

code: 一意のキー

name: 表示名で実質的なValue

category_path: 文字列による階層表現で例は/家電/冷蔵庫

metadata: エクセルの残りの列をすべてここに放り込む

■ 4. シンプル構成の利点

従来設計の問題点:

PoCやスモールスタートにおいて従来の1エンティティ＝1テーブルという硬い設計は柔軟な開発の足枷になる

エクセルの管理台帳に1つ列を足したいだけなのにDBのマイグレーションに怯え影響調査に時間を費やすことになる

シングルテーブル設計の利点:

テーブルを細かく分けずあらゆるマスタを一つの大きな器に放り込むシングルテーブル設計を選択肢に加える

これにより構造を固定せずビジネスの変化をそのまま受け止める構成を考えることが出来る

比喩:

正規化重視の設計は川の流れをガチガチに固める堤防を作るのに対してシングルテーブル設計は広い遊水地を用意するといったところ

■ 5. PostgreSQLでの実装

NoSQLとの比較:

シングルテーブルと聞くとDynamoDBのようなNoSQLを連想する方が多い

実際クエリの効率化のためにデータを1つのテーブルに集約する手法はNoSQLの定石

DynamoDBではパーティションキーやソートキーを抽象的に定義することで後からアプリ側でデータを解釈する柔軟性を持たせることが一般的

DynamoDBの課題:

直面するのは検索の壁

DynamoDBは一部の項目にしかインデックスを作れないしそれを補うGSIなどの機能はとても複雑

今回は対象がマスタ管理なので検索の柔軟性はとても重要

PostgreSQL採用の理由:

シングルテーブル設計によるマスタ管理を検索能力が高いPostgreSQLで実施することを考える

PostgreSQLの優位性:

アドホックな検索への対応力: NoSQLは事前に定義したアクセスパターンには強いが想定外の条件での検索や集計は苦手でPostgreSQLはSQLの強力な表現力でいつでも自由な切り口でデータを抽出できる

JSONBと高度なインデックス: PostgreSQLのJSONB型はスキーマレスな柔軟性を提供し内部フィールドに対してGINやB-Treeインデックスを後から自由に追加可能

複雑な階層やパス検索: /食品/生鮮/野菜のようなパスに基づく検索はPostgreSQLのLIKE検索やltree型を使えばインデックスを効かせつつ爆速実行可能でNoSQLのキー設計で解決するよりも遥かに直感的で強力

PostgreSQLの位置づけ:

PostgreSQLをただのRDBではなく強力な検索エンジンを備えたドキュメント・ストアとして使うことでスマートなマスタ定義の管理が実現できる

■ 6. マスタのデータ取得方法

懸念への対応:

テーブルが1つでリレーションもないならアプリ側で扱うときに不便じゃないかという懸念がある

実はそんなことはない

アプローチ:

DB側でJOINして整えるのではなくDB側で構造化して1発で返すというアプローチを取る

PostgreSQLの関数活用:

PostgreSQLにはjson_aggやjsonb_build_objectといった抽出結果をまるごと構造化する強力な関数がある

これらを使えば複数テーブルを何度も叩く代わりに必要なマスタを1つのJSONオブジェクトとしてアプリに返すことができる

アプリ側はそれを受け取り起動時や定期的なリフレッシュのタイミングでメモリ上に展開してしまえばいい

メリット:

アプリ起動時に全ロード

メモリ上で高速検索

DB通信のオーバーヘッドなし

データ量への懸念の解消:

マスターのデータを全て渡すのは無駄じゃないのかという懸念がある

しかし今回はあくまでエクセルで人間が管理できるマスタであることが前提

今時のコンピューターやネットワークなら数千件や数万件程度のデータは一瞬で処理出来る

むしろ通信が1回で完結するので効率よくデータを処理することが可能

設計思想:

DBに知能を持たせるのをやめアプリが使いやすい塊としてデータを扱う

こうすることでリレーションに頼らないスマートなマスタ取得が実現できる

■ 7. モダン開発との関係

従来のアプリ開発の問題:

特にマスタに関しては整合性を徹底するためにDBの型や制約をガチガチに固めることが多い

しかし素早い開発や柔軟な仕様変更を求められるモダンな開発ではこの設計が足枷になってしまうことが多々ある

DBの位置づけの変更:

DBは器であってフィルターではない

JSONBで何でも受け入れる柔軟な土台に徹しデータの解釈や不整合の吸収は変更が容易なアプリ側で対応することも考えるべき

健全な関係性:

アプリが賢く立ち回ることで土台であるDBを自由にする

この関係性こそがモダンな開発における健全なアプリとDBの関係

■ 8. おわりと次回予告

提案の効果:

PostgreSQLを使ってマスタ定義を自由にすることで柔軟なアプリ開発を爆速で実現出来る

残された課題:

そんなルーズなマスタではトランザクションの整合性が取れないのではという疑問が出るのは当然

小規模アプリと言っているけど将来的にマスタが巨大化すると詰むよねという懸念がある

次回予告:

後編ではこのルーズなPostgresqlを支える整合性を担保するDynamoDBについて語る

(2026/01/19)

Dockhand

Dockhand は、リアルタイムコンテナ管理、Docker Compose スタックのオーケストレーション、そしてマルチ環境サポートを提供する、最新の効率的な Docker 管理アプリケーションです。これらすべてを軽量で安全、そしてプライバシーを重視したパッケージにまとめています。

機能:

コンテナ管理：コンテナをリアルタイムで起動、停止、再起動、監視

Compose スタック：Docker Compose デプロイメント用のビジュアルエディター

Git 統合：Webhook と自動同期を使用して、Git リポジトリからスタックをデプロイ

マルチ環境：ローカルおよびリモートの Docker ホストを管理

ターミナルとログ：インタラクティブなシェルアクセスとリアルタイムのログストリーミング

ファイルブラウザ：コンテナからのファイルの参照、アップロード、ダウンロード

認証：OIDC 経由の SSO、ローカルユーザー、およびオプションの RBAC（エンタープライズ）

MEMO:

VPSでコンテナ管理するのに便利そう

(2026/01/18)

プログラミングが好きな人は、もうIT業界に来るな。

プログラミングが好きな人は、もうIT業界に来るな。｜いぐぞー@書籍執筆中 ✈️ 旅するプログラマー

要約:

■ 1. IT業界における生成AI登場前の状況

コミュニケーションが苦手な人材にとっての楽園的環境:

論理的に仕様を詰め正確なコードを書けば多少無愛想でも職人として尊重された

饒舌さや気の利いたお世辞は不要であった

技術力だけで周囲を驚かせることが可能であった

プログラミング愛好家のアイデンティティ:

自分の指先から生まれるロジックで問題を解決することが誇りであった

得意なことで収入を得られる環境が存在していた

■ 2. 生成AIによる業務内容の変化

コーディング作業の減少:

エディタに向かってコードを書く時間が激減した

AIが生成した80点のコードの検品係が主な役割となった

創造する喜びが失われた

プログラミング能力の価値暴落:

プログラミング未経験の業務担当者がChatGPTを使い簡単なツールを自作できるようになった

現場のドメイン知識を持つ人材がAIを手足として使えるようになった

プログラマーという通訳の役割が不要となった

■ 3. 求められるスキルの変化

コーディングからコミュニケーションへの転換:

要件定義や業務整理やステークホルダーとの調整が増加した

何を作るべきかやなぜ作るのかを言語化し整理する能力が求められるようになった

評価軸の変化:

美しいコードを書く能力から生成AIを使いこなし素早くアウトプットを出す能力へ変化した

技術力一本での評価という爽快感が消失した

■ 4. IT業界を目指す人へのメッセージ

推奨しない動機:

プログラミングが好きで人と話すのが苦手という理由だけでは生き残れない

プログラミングそのものはAIがより上手に実行するようになる

推奨する動機:

作りたいサービスがある人材

解決したい社会課題がある人材

アイデアで世界を良くしたい人材

技術の民主化:

高度なコーディングスキルという壁が消失した

情熱とアイデアとAIへの指示力があれば誰でもクリエイターになれる

静寂とコードの職人芸の世界から誰もがアイデアを形にできる創造的な世界への移行

MEMO:

偏屈な職人肌プログラマというロールモデルは消滅して久しい
技術オタクであることがマイナスになることはないが、技術オタクだけでは生き残れなくなる
2000年頃はDBやWEBサーバの設定を暗記していることが価値に繋がったりもしたが、今ではそんなものAIに聞けばよいので価値としては認められなくなった
人間DBとしてのオタクには価値が無くなってしまったと言うべきか

(2026/01/18)

集約にこだわりすぎないDDD：Laravelで実践するアクション単位設計

集約にこだわりすぎないDDD：Laravelで実践するアクション単位設計

要約:

■ 1. DDDにおける集約とファットリポジトリ化の問題

集約の重要性:

関連するエンティティと値オブジェクトを1つの単位として扱う概念

ビジネスルールの整合性を保つための境界を定義する

データの一貫性を保証する役割を果たす

ファットリポジトリ化の問題:

1つのリポジトリに多くのメソッドが集約される

変更影響範囲の拡大により他メソッドへの影響考慮が必要になる

テストの複雑化が発生する

責務の曖昧化が生じる

チーム開発での競合が増加する

アクション単位設計の設計思想:

各アクションに対して専用のプレゼンターとユースケースとリポジトリを用意する

各アクションが独立し変更影響が局所化される

DDDの層構造とADRパターンを組み合わせる

■ 2. ADRパターンの概要

ADRパターンの定義:

Paul M. Jonesによって提唱されたMVCパターンの代替アーキテクチャ

HTTPリクエストの処理を3つの明確なコンポーネントに分離する

3つのコンポーネント:

Action: HTTPリクエストを処理するエントリーポイント

Domain: ビジネスロジックとドメインモデル

Responder: レスポンスデータの構築とHTTPレスポンスの生成

MVCパターンとの違い:

MVCではControllerがModelとViewの両方に依存し責務が曖昧になる

ADRではActionとDomainとResponderの役割が明確に分離される

メリット:

各コンポーネントの責務が明確になる

各コンポーネントを独立してテストできる

ビジネスロジックがフレームワークから独立する

Domain層がプレゼンテーション層に依存しない

DDDとの組み合わせ:

ActionをPresentation層のControllerにマッピングする

DomainをDomain層にマッピングする

ResponderをPresentation層のPresenterにマッピングする

■ 3. 従来の設計パターンの問題点

集約にこだわった設計の特徴:

1つのリポジトリに複数の操作を集約する

OrderRepositoryにcreateやupdateやcancelなど多数のメソッドが存在する

問題点の詳細:

変更影響範囲の拡大: 1つのメソッド変更時に他メソッドへの影響考慮が必要

テストの複雑化: 各メソッドのテスト時に他メソッドとの相互作用を考慮する必要がある

責務の曖昧化: データアクセスだけでなくビジネスロジックも含まれる可能性がある

チーム開発での競合: Gitのマージコンフリクトが発生しやすくなる

■ 4. 提案する設計パターン

アクション単位設計の構成:

1プレゼンター: 各アクション専用のプレゼンター

1ユースケース: 各アクション専用のユースケース

1リポジトリ: 各アクション専用のリポジトリ

各アクションをパーティションで区切るイメージ

依存性逆転の法則:

Application層にインターフェース定義を配置する

Presentation層とInfrastructure層はApplication層のインターフェースに依存する

Application層が外部層に依存しない構造を実現する

ADRパターンとの対応:

Action: OrderControllerとしてHTTPリクエストの受付とルーティングを担当

Domain: Domain/Entities/Orderとしてビジネスルールとエンティティを担当

Responder: CreateOrderPresenterとしてレスポンスデータの構築を担当

ARC パターン:

DDDの構造設計とADRパターンを融合させた設計

Action-Responder Cleanパターンと呼称する

■ 5. Laravel実装例

ディレクトリ構造:

Application層: インターフェース定義とユースケース

Domain層: エンティティ

Infrastructure層: リポジトリ実装

Presentation層: プレゼンターとリクエストとレスポンス

Http層: コントローラー

各レイヤーの役割:

リクエストDTO: リクエストデータを保持する

レスポンスDTO: レスポンスデータを保持する

プレゼンターインターフェース: アクション単位で独立したインターフェースを定義

プレゼンター実装: リクエストとレスポンスの保持と取得

リポジトリインターフェース: データアクセスの抽象化

リポジトリ実装: Eloquentを使用したデータアクセス

ユースケース: ビジネスロジックの実装

コントローラー: HTTPリクエストの受付とバリデーション

依存性逆転の法則のメリット:

ビジネスロジックの独立性により外部の実装詳細に依存しない

実装の交換が容易でインターフェースが変わらない限り影響がない

モックやスタブを使ったテストが可能

フレームワークからの独立性により移行時もビジネスロジックを再利用可能

Responderの責務に関する設計選択:

現在のアプローチ: PresenterがCreateOrderResponseを返しコントローラーがJsonResponseを構築する

代替アプローチ: Presenterが直接JsonResponseを返す

現在のアプローチはフレームワークからの独立性を重視する

代替アプローチはADRパターンの徹底を重視する

■ 6. アクション単位設計のメリット

独立性:

各アクションが独立し変更影響が局所化される

注文作成のロジック変更時に注文キャンセルのロジックに影響を与えない

テスタビリティ:

モックが容易で単体テストが書きやすい

各コンポーネントを独立してテストできる

保守性:

機能追加や変更時の影響範囲が明確になる

新機能追加時に既存コードへの影響を最小限に抑える

可読性:

各クラスの責務が明確でコードの理解が容易

1クラスのステップ数が200から300程度に収まる

新しいメンバーのプロジェクト理解が速やかに進む

スケーラビリティ:

チーム開発での競合が減り並行開発が容易になる

複数の開発者が異なるアクションを並行して開発できる

依存性の明確化:

依存関係が明確で変更に強い設計になる

インターフェースを変更しない限り実装変更が他層に影響を与えない

ADRパターンの利点:

ActionとDomainとResponderの分離により責務が明確になる

ビジネスロジックがフレームワークから独立しフレームワーク変更への耐性が向上する

■ 7. 実践的なTips

Laravelサービスコンテナ活用のベストプラクティス:

各機能ごとにサービスプロバイダーを作成し依存関係を明確に管理する

インターフェースに依存することでモック化が容易になる

プレゼンターは都度生成しリポジトリはシングルトンなど適切なライフサイクルを選択する

テストコードの書き方:

依存関係が明確で必要なモックを特定しやすい

1つのアクションに焦点を当てたテストが書きやすい

インターフェースに依存しているためモックの作成が簡単

データベースや外部APIに依存せず単体テストが高速に実行できる

ユースケースのテスト例:

リポジトリをモック化してテストする

在庫不足時の例外スローを確認する

コントローラーのテスト例:

プレゼンターとユースケースをモック化する

レスポンスのステータスコードとデータを確認する

リポジトリのユニットテスト:

DBファサードとEloquentモデルをモック化する

データベースに依存せずテストが高速に実行される

エッジケースのテストが容易になる

拡張時の注意点:

新しいアクションには新しいコンポーネントを作成する

既存コンポーネントの変更を避け影響範囲を最小化する

共通処理はドメインサービスやアプリケーションサービスとして抽出する

共通処理の抽出例:

ドメインサービス: 価格計算や配送料計算などビジネスロジック

アプリケーションサービス: 在庫チェックなど複数アクションで共通する処理

パフォーマンス対策:

リポジトリの最適化により必要なデータのみを取得する

頻繁にアクセスされるデータはキャッシュを実装する

Eloquentのwithメソッドを活用しN+1問題を回避する

ADRパターンとDDDの組み合わせガイドライン:

Action層の薄さを保ちビジネスロジックを含めない

Domain層の純粋性を保ち外部層に依存しない

Responder層の独立性を保ちビジネスロジックを含めない

■ 8. まとめ

設計の重要性:

集約にこだわりすぎることでファットリポジトリ化し保守性が低下する

アクション単位設計により各アクションが独立し変更影響が局所化される

DDDとADRパターンの組み合わせによりクリーンアーキテクチャの原則を実現する

依存性逆転の法則により外部層がApplication層に依存する構造を実現する

長期的なサービスへの適用:

数年から数十年と長く運用し続けるサービスにこそ価値がある

機能の追加や変更が頻繁に発生する環境に適している

チームメンバーの入れ替わりに対応しやすい

技術スタックの進化に柔軟に対応できる

複数の開発者の並行作業で競合が発生しにくい

長期運用における優位性:

機能追加時の影響範囲が明確で既存コードへの影響が最小限

コードの理解が容易で新メンバーも特定機能に焦点を当てて理解できる

フレームワークからの独立性により技術スタック変更に柔軟に対応できる

並行開発の促進により複数開発者が同時開発しても競合が発生しにくい

実践的な設計指針:

アクション単位設計に従い各アクションに専用コンポーネントを作成する

依存性逆転の法則に従いApplication層にインターフェースを配置する

ADRパターンとDDDの層構造を組み合わせる

テスト容易性と保守性を重視する

MEMO:

ちょっと違和感があるが

(2026/01/18)

巨大SQLに対する解読術

巨大SQLに対する解読術

(2026/01/18)

Kiroみたいな「仕様書駆動開発」をClaude Code・Opus 4でやるまでの手順を整理した！！！

Kiroみたいな「仕様書駆動開発」をClaude Code・Opus 4でやるまでの手順を整理した！！！ #LLM - Qiita

(2026/01/18)

僕の観測範囲で喋ってしまうけど、AI コーディングエージェントが登場してきて、プログラマが...

僕の観測範囲で喋ってしまうけど、AI コーディングエージェントが登場してきて、プログラマがやってた事を AI が肩代わりするだろう、そして人間に時間の余裕ができるだろう、と思われていたにも関わらず、多くのプログラマはそれどころか 2 倍や3倍の作業量になってしまっており「おいおい君ら倒れるで」という状況をチラホラ目にしている。

@mattn_jp

MEMO:

実装というかコード出力はすぐ完了するので、出力されたコードをレビューする → 意図通りに修正 or 再出力を指示みたいなサイクルが早すぎて人間側が疲弊している
単位時間あたりの労働負荷が大変なことになっている上、AI前提の生産性が求められるのでサボることもできないという

(2026/01/18)

Raspberry Pi AI HAT+ 2

Buy a Raspberry Pi AI HAT+ 2 – Raspberry Pi

要約:

■ 1. Raspberry Pi AI HAT+ 2の概要

Hailo-10H AIアクセラレータを搭載

8GBのオンボードRAMを搭載

Raspberry Pi 5に生成AI機能を追加するHAT

価格は130ドル

現在販売中

■ 2. オンボードRAMの利点

8GBの専用オンボードRAMを搭載

大規模言語モデル(LLM)やビジョン言語モデル(VLM)をローカルかつセキュアに実行可能

ホストのRaspberry Pi 5を他のタスク処理に解放できる

AIモデルのスムーズな動作を保証

■ 3. プライバシーとセキュリティ

エッジでの信頼性が高く低遅延なAI処理を実現

ネットワーク接続なしで動作可能

データセキュリティを簡素化

インフラ要件を最小化

クラウドAPIコストを削減

■ 4. モデルの提供

Hailoがサンプルモデルを提供

ユーザーによるカスタマイズ:

カスタムビジョンモデルのトレーニング

生成AIモデルのファインチューニング

対応アプリケーションの例:

音声からテキストへの変換

翻訳

視覚シーン分析

互換性のある生成AIモデル用ソフトウェアはHailoのGitHubリポジトリで入手可能

■ 5. 主な仕様

Hailo-10H AIアクセラレータ搭載

40 TOPS(INT4)の推論性能

コンピュータビジョンモデルの性能はRaspberry Pi AI HAT+(26 TOPS)と同等

8GBオンボードRAMにより生成AIモデルを効率的に実行

Raspberry Piのカメラソフトウェアスタックに完全統合

Raspberry Pi HAT+仕様に準拠

■ 6. 付属品

オプションのヒートシンク付属

16mmスタッキングヘッダー付属

スペーサーとネジ付属

Raspberry Pi Active Cooler装着済みのRaspberry Pi 5への取り付けが可能

MEMO:

40TOPSというと最近発表されたASUSのAIアクセラレータと同等のスペックなのか
ASUS、最大40TOPSのAI性能を持つ外付けAIアクセラレータ - PC Watch

(2026/01/18)

loss32: let's build a Win32/Linux

loss32: let's build a Win32/Linux

要約:

■ 1. loss32プロジェクトの概要

コンセプト:

デスクトップ環境全体がWINE上で動作するWin32ソフトウェアで構成されるLinuxディストリビューション

完全にフリーかつオープンソースのOS

exeファイルをダウンロードしてそのまま実行できる

想定ユーザー:

必ずしもUnix愛好家ではないパワーユーザー

このコンセプトを面白いと思う人

■ 2. ReactOSとの違い

ReactOSの問題点:

Windows NTカーネルの再実装を試みている

これがアキレス腱となりハードウェア互換性と安定性の面で足を引っ張っている

loss32のアプローチ:

ReactOSと似た最終結果を目指す

より使いやすい基盤の上に構築

動作実績のあるコンポーネントを使用:

Linuxカーネル

WINE

それらを結合する各種ツール

ReactOSユーザーランドの便利な機能

loss32の利点:

技術的にはLinuxディストリビューションのため必要に応じてLinuxソフトウェアも実行可能

ReactOSではLinuxソフトウェアを実行できない

■ 3. プロジェクトの目標

ユーザーランド全体を可能な限りWINEで置き換える

■ 4. プロジェクトを構築する理由

90年代後半から2010年代初頭のPCデスクトップ体験はパワーユーザー特にクリエイティブユーザーにとって素晴らしかった

その夢を維持したい

WINEには残念な荒削りな部分が多くユーザーは最後の手段としてのみWINEを使用するため許容している

全てがWINE上で動作するデスクトップ環境はWINEの改善を促進する

このプロジェクトを使うかどうかに関わらず全員にとって有益

Win32は安定したLinux ABIである

技術的に可能だから

■ 5. Win32が安定したLinux ABIである理由

exeファイルをダウンロードしてWINEで実行できることで何度も助けられた経験がある

クリエイティブプロジェクトでは以下のようなソフトウェアが必要になることが多い:

自分で再ビルドするのが不可能または非現実的

LinuxやmacOS版が動作しないまたは存在しない

Win32ソフトウェアには30年以上の歴史がある

WINEまたはWindows上で実行可能

他のABIにはこれほどの互換性実績がない

WINEはWin16のソフトウェアも実行可能

Win32は世界の安定したABIでもある:

GNU/LinuxやPOSIX系の選択肢が限られており品質が低い分野が多い

例としてクリエイティブソフトウェアやゲーム

Win32により人類の文化遺産のより大きな部分にアクセス可能

■ 6. 現在の状態

スクリーンショットは実際のもの

Debian 13上で安定版WINEを実行している状態

スクリーンショットには映らない多くの荒削りな部分があり現時点では使用が快適ではない

プロジェクトの目標:

多くの荒削りな部分を修正

この環境を簡単にインストールできる形でパッケージ化

■ 7. 協力者の募集

特に求めている知識や協力:

デスクトップ環境を強制しないWaylandコンポジター

現在はスタンドアロン版のmutterを使用

WINEとの連携改善

WINE関連:

explorer.exe

shell32.dll関連

HiDPIスケーリング

パッケージング

ReactOS関連:

explorer.exe

shell32.dll関連

ReactOSユーザーランドとWINEの非互換性

GNU/Linuxデスクトップスタックの複雑な詳細全般

■ 8. リリース予定

ビジョンの完全な実現時期:

不明

2026年1月中に初期の概念実証版をリリース予定:

/etc/apt/sources.listに追加してsudo apt installで導入可能

欠落や不具合の長いリストが付属

そこから反復的に改善していく

(2026/01/17)

無茶なスケジュール案件でも燃えにくくする「開発環境」と内部工程計画の考え方

無茶なスケジュール案件でも燃えにくくする「開発環境」と内部工程計画の考え方 #アジャイル - Qiita

要約:

■ 1. フリーランス・小規模ソフトハウスが直面する構図

元請けが穴だらけの立派な工程表を出してくる

大半の人はその穴を見抜けるレベルのレビュー実戦経験がない

プライムにケチを付けられない立場のため従うしかない

末端側はウォーターフォール型工程に従い各工程のみを担当する

作るものの全体像が曖昧なまま設計が進む

実際に環境を組み上げたタイミングでようやく現実が見える

結果として発生する問題:

仕様漏れ

追加作業と追加料金交渉

納期ギリギリ

ユーザー満足度の低下

■ 2. プロジェクト計画の理想と現実

理想:

プロジェクト計画書がパートナーにも展開される

双方でコンセンサスを取りながら進める

リスク想定とヘッジ案の説明や議論がある

現実:

小さな会社の社長やフリーランスはプロジェクトキックオフの儀式としてしか見ていない

様々な事情からリスク議論が実践できない

■ 3. 元請けの工程表の実態

PMの願望が強く出たドキュメントと認識すべき

通常書かれていないもの:

商用環境の構成が固まるタイミング

試験環境でどこまで再現するか

どの段階で何を試すか

現場の安全マージンやリスクヘッジ

極端な工程表の例:

要件定義工程がない

各工程での成果物が決まっていない

設計工程なしにいきなりパラメータ設計書

PoCでやったから設計なしでいけるという幻想でいきなり環境構築

ステージングをそのまま本番にするノリで商用後の保守イメージがない

実装期間が妙に短く3週間に環境構築から報告書作成まで全部入り

セキュリティ設計やセキュアコーディングガイドラインがなく脆弱性試験で炎上

このまま乗ると後半で燃える

外向け工程表とは別に内部で裏プロジェクト計画を持つ発想が重要

■ 4. 技①:基本設計段階でプロト環境を先に作る

基本設計フェーズの早い段階で本番と同じ構成イメージの影のプロト環境を自分たち側でこっそり作る

プロト環境の内容:

土台となるOS

想定しているミドルウェア(アプリケーションサーバやレポーティング基盤など)

知る限り本番構成に近い形で一度組んでみる箱

あらかじめ作っておくべきもの:

GitLabなどのソースコード管理とCI/CD基盤

メリット:

早い段階でリバースプロキシ不足や追加DB必要などの設計上の大穴に気づける

元請けの基本設計がふわっとしていても動くものの全体像を先に掴める

構築メモや設定手順と要件定義があれば基本設計書は後から2〜3日で一気に書ける

体裁や細かい部分はLLMを使えば2〜3日で形にできる

ポイント:

工程表通りにドキュメントだけ書くのではなく基本設計の最初にプロト環境をこっそり動かす

内部工程を勝手に入れ替える

外には言わず自分たちが燃えないための保険として自社努力で行う

コスト面:

自社で新たに大きなコストを捻出する必要はない

プロジェクト開始早々は要件定義未提出や基本方針未確定などの待ち時間が多い

自分に関係ない打ち合わせ中にこっそり進める

待ち時間を活用して動くものの断片でも作っておく

勝手アジャイルを回す勢い

■ 5. 技②:バージョン釘打ちミーティングをねじ込む

プロト環境を先に作る際の落とし穴:

バージョンが後から変わって全部作り直しになる

対策として基本設計の初期にバージョン釘打ちミーティングをねじ込む

最低限合意しておくべき項目:

土台となるOSのバージョン(メジャーとマイナーまで決まれば上出来)

主要なミドルウェアとそのバージョン(アプリケーションサーバやレポーティングやバッチ基盤など)

それぞれのサポート状況(EoL時期やメーカーサポート有無やOSSコミュニティ活動状況)

釘打ちは完璧でなくてよい:

一生変えないという固定ではない

ひとまずこの前提で設計見積もりを進めるレベルの合意

後から変更が出ても柔軟に対応できるようにしておく

■ 6. 技③:プロト環境の存在は言わず経験値として出す

影のプロト環境で性能やリソースを見ておくと後のフェーズで楽になる

聞かれる質問の例:

この構成でCPU何コアぐらい必要か

何ユーザーぐらいまで余裕があるか

どのくらいのマシンサイズを見込めばいいか

裏ではプロト環境でちゃんと数字を取っているが自前環境で負荷かけたとストレートに言う必要はない

期待値コントロールの領域

外向きの言い方サンプル:

同等規模の構成での過去案件の経験値ではこのくらいのアクセス数ならCPU使用率は何%前後

近い構成のプロジェクト実績をベースにすると初期はこのマシンサイズから始めるのが妥当

似たような業務負荷の案件で取った数値を参考にするとこのくらいのスペックで当面余裕がある

実際にはその過去案件の1つが今回の影のプロト環境だが外から見れば経験値として扱える

バランス感覚のポイント:

裏側ではしっかり測っている

過度に全部やってあげてますと期待値を上げすぎない

過去の知見として妥当な範囲を出していますというトーンを守る

■ 7. 技④:LLMに食わせる前提で手順書だけちゃんと残す

影のプロト環境を作るときは基本設計書そのものより手順書とメモの残し方をちゃんとしておく

理由:

LLMに食わせるとかなり精度の高い基本設計書ドラフトが一瞬で出てくる

流れ:

影のプロト環境を作る

その過程でインストール手順やミドルウェア設定や詰まったポイントと解決策をざっくりテキストで残す

LLMに渡して基本設計書の構成案出しや顧客向け表現整理や試験項目洗い出しやパラメータシートたたき作成を依頼

2〜3日かけて書くレベルの文書が数時間で形になる

この組み合わせの効果:

実装リスクを下げる

ドキュメント工数も削る

かなり相性の良い戦略

■ 8. ウォーターフォールを表で守りつつ裏でアジャイルを回す

表向きの対応:

元請けが出してきた大きな工程表(ウォーターフォール)に従っているように見せる

マイルストーンや成果物の名称も基本設計や機能設計や結合テストを崩さない

裏側での対応:

基本設計フェーズのうちにプロト環境を作って動かす

バージョンを釘打ちする

実際に動かしながらこれで行ける構成を先に固めてしまう

そこで得た知見をもとに性能見積もりやリソース見積もりやリスク洗い出しをスッと出せるようにしておく

効果:

表面上はウォーターフォールでも内側では小さなアジャイルサイクルをぐるぐる回して後続工程をどんどん楽にできる

大線表の納期を遅らせるという話ではない

最初に影のプロト環境を作っておくことで大線表を遅らせずに済む確率がかなり上がる

その構成で実際に動いている環境がすでにあるため

■ 9. 環境をプロジェクトごとに準備する効率化

ネック:

案件ごとにOSやミドルウェアや認証まわりやテスト用クライアントを毎回ゼロから用意するのはフリーランスや小規模ソフトハウスにはheavy

対策:

案件ごとの箱庭環境を簡単に量産できるテンプレートやツールを少しずつ自分の側に用意しておく

具体例:

手元のマシン1台に仮想化環境と案件ごとの箱庭を自動で作るスクリプトを置いておく

新しい案件が始まったらまず影のプロト環境を30分くらいで立ち上げてから設計に入る

使うツールや技術スタックは何でも構わない

大事な発想:

毎回手作業で環境を組むのではなく案件ごとの箱庭をほぼテンプレートから起こす

リモートからVPN経由で簡単に入れるようにしてパートナーがすぐに参加できる環境を作っておく

となりの案件のVMが見えてしまわないようなセキュリティに十分配慮した分離開発環境を構築する

パブリッククラウドで回してもよいが採算度外視で使うのはかなり危険

■ 10. まとめ

元請けの工程表だけを信じて燃えないための要点:

外向け工程表とは別に自分たちの内部工程計画を持つ

基本設計の初期にプロト環境をこっそり作ってしまう

OSとミドルウェアのバージョンを早めに釘打ちしておく

プロト環境で得た数字は自前ラボで測りましたではなく他プロジェクトでの経験値ですとして出す

手順書をちゃんと残しておけばLLMに食わせて基本設計書を一気に仕上げることもできる

表向きはウォーターフォールでも裏で小さなアジャイルを回して先回りしておくといろんな工程が楽になる

正論のセキュリティ記事というより現場で生き残るためのテクニック集

これらの工夫が積み上がると変わること:

プロジェクトの燃え具合

ユーザーの満足度

自分たちの消耗度合い

(2026/01/17)

Redundancy vs dependencies

Redundancy vs dependencies: which is worse?

要約:

■ 1. プログラミングにおける2つの本質的な力

冗長性の最小化:

全ての知識を一度だけ定義することが理想

依存関係の最小化:

AがBに依存するのは絶対に必要な場合のみに限定すべき

優れたプログラマの特徴:

冗長性と依存関係を嫌悪する

劣ったプログラマはこれらを気にしない

■ 2. 冗長性と依存関係の衝突

モジュール境界を越えたコード再利用の問題:

モジュールAとBが共通モジュールCを使うか各自で実装するかの選択

モジュール内部での再利用:

議論の余地なく再利用すべき

モジュール間での再利用:

第三のモジュールを作成するか「ユーティリティ」モジュールに追加する必要がある

ユーティリティモジュールの問題点:

外部ライブラリへの依存

設定の誤り

初期化タイミングの問題

■ 3. 経験がもたらすもの

経験は知識の蓄積より性格の形成または破壊に寄与する

若いプログラマ:

インフラ構築に積極的

第三のモジュール作成を喜ぶ

ベテランプログラマ:

インフラ活動に対して否定的反応を示す傾向

■ 4. コマンドライン解析の例

機能拡張の誘惑:

オプション構文の統一

値の型対応(文字列/真偽値/整数/16進数/ユーザー定義型)

ヘルプ文字列

ヘルプ画面の自動生成

GUIプロパティページ

設定ファイルからの読み込み

フラグの妥当性チェック

過剰設計の実例:

XParam: 1万行以上のコードと独自シリアライゼーションフレームワーク

ホストプロジェクトでは機能の5%未満しか使用されない

著者自身もXLogという1万行以上のログライブラリを作成し機能の0%しか使用されなかった経験を持つ

著者の現在のアプローチ:

5行のCコードで単純に解析

ヘルプ画面やバリデーションは不要と割り切る

1万行のパッケージへの依存を回避

■ 5. モジュールの定義と要件

コンパクトで安定したインターフェース:

OOの訓練がコンパクトさの軽視を招いている

数十のクラスや複雑なデータ構造を公開することが許容されている

ドキュメント:

セマンティクスの記述

サンプルコードの提供が理想

テスト:

各クラスや関数の単体テストではなく公式インターフェースのテストが重要

適切なサイズ:

1K〜30K LOC(C++換算)が目安

大きすぎても小さすぎても泥の塊になる

オーナー:

変更はオーナーを説得して行う

一貫したメンタルモデルを維持できる人数は1人

ライフサイクル:

変更はバージョンにまとめて頻繁すぎないリリース

■ 6. 他者のモジュールへの依存の問題

オーナーシップの問題:

作成者が継続的なサポートを認識していない

他者による不適切な変更が発生

循環依存の発生

コマンドラインパーサーの潜在的依存先:

シリアライゼーションパッケージ

パースパッケージ

カラーターミナルI/Oパッケージ

プラットフォーム固有パッケージ

シングルトン初期化管理パッケージ

ライフサイクルの問題:

バージョン互換性の確認

テストのコンパイルに他者のコードが必要

新バージョンが追加の依存関係を引き込む

インターフェース安定性の問題:

破壊的変更によるテストスクリプトの破損

予期しない動作変更

■ 7. 生物学的アナロジー

生物における冗長性の例:

人間とタコは盲目の祖先から独立して類似の眼を進化させた

眼全体という複雑な器官が独立して開発される

冗長性は進化において機能している:

全員の努力を調整するより効果的

■ 8. 結論

冗長性の欠点:

努力の重複

相互運用性の問題

依存関係はより深刻:

依存すべきは本格的なモジュールのみ

無定形なコードの塊には依存すべきでない

モジュール化の成功可能性の評価基準:

実際のオーナーの存在

安定したインターフェース

全ユーザーを満足させる見込み

著者の主張:

成功の見込みが低ければ冗長性を選択すべき

見積もりは保守的に行うべき

冗長性は悪だが依存関係は麻痺を引き起こす

依存関係を先に排除すべき

MEMO:

つまり、外部ライブラリへの依存は最小限にせよという話
外部ライブラリに依存すると、外部ライブラリのアップデートやセキュリティホール対応に追従する必要が生じる
特にビジネスロジックと外部ライブラリが強く結合していると外部ライブラリの不安定さがコアロジックの不安定さにつながる
古来より外部ライブラリは直接使うのでなく、ラップして使うことが推奨されていたように思うのだが
近年は本当に些細な処理ですらライブラリ化されていて、脳死で外部ライブラリを使うことが多いが、その結果サプライチェーン攻撃を喰らうことも増えた
npmのleft-padやcolors.js/faker.jsなどがそうだったか

(2026/01/16)

ドワンゴを退職した江添亮さんがハロワに登録→連絡してきた企業の面接に行ってみたら、殺風景な雑居...

ドワンゴを退職した江添亮さんがハロワに登録→連絡してきた企業の面接に行ってみたら、殺風景な雑居ビルの一室でわけのわからない経験をした話 - Togetter

MEMO:

クソカス虚無企業の面接冷やかしやってみたいけど、シンプルに時間の無駄な上に個人情報を握られるリスクを考えると迂闊にできないんだよな
転職サイトならギリギリまで公的な身分証明出さなくてもいいから案外いけるのだろうか

(2026/01/16)

生成から工程へ――RLM(再帰的言語モデル)が非構造化データを武器に変える

生成から工程へ――RLM(再帰的言語モデル)が非構造化データを武器に変える – WirelessWire & Schrödinger's

要約:

■ 1. RLMの定義と本質

再帰的言語モデルの位置づけ:

最も注目を集めている大規模言語モデルエージェント・アルゴリズム

実際のモデルはOpenAIのChatGPTやgpt-ossやDeepSeekなど既存のLLMを使用する

再帰とはLLMの呼び出し方を指す

RLMの本質:

LLMを一発回答の生成器として使うのではなく複数の推論ステップを持つ手続きとして編成する

自己修正しながら目的の成果物へ収束させる

重要なのは再帰という言葉の響きよりも実装上の設計原則

■ 2. RLMの3つの構成要素

オーケストレーターLLMとワーカーLLMの役割分担:

オーケストレーター: 大局的な戦略を立てる役割でどの資料を読むべきかや抽出すべきスキーマは何かや矛盾が出たらどの観点で再検証するかを担う

ワーカー: 局所的な作業を担当しこの段落から顧客要望を候補抽出するやこの候補の根拠となる引用箇所を特定するなど粒度の小さいタスクを大量に捌く

同じLLMで役割を分担することが可能でgpt-ossは非常によく働く

分業が効く理由:

LLMの失敗が往々にして大局と細部の混線で起きる

戦略を考えながら同時に細部を埋めるともっともらしい整合を優先し検証が甘くなる

戦略と実務を分けることで作業の責務が明確になり失敗の検知と修正がしやすくなる

非自然言語的な中間表現:

Pythonコードなど機械的に検査可能な表現を途中に置く

抽出結果をJSONにしPythonでスキーマ検証を行う

重複や欠落や型不一致や相互参照の矛盾をコードで弾く

候補の根拠引用が本当に原文に存在するかを文字列一致や範囲照合で検証する

中間表現の効果:

モデルが賢くなったから精度が上がるのではない

LLMが苦手な厳密さをコードと型と制約で肩代わりしLLMには意味の解釈を担当させる

LLMを推論エンジンとして使いつつ検証と制約は計算機の得意技に寄せるアーキテクチャ

検証から差分修正から再実行のループ:

最初の抽出はあくまで暫定解にすぎない

Pythonで検査してエラーが出たらそのエラーを次の入力条件としてオーケストレーターに返し再度ワーカーにタスクを割り当てる

やり直しを精神論ではなくプロトコルとして設計する

プロトコル設計の例:

フィールドが埋まらない場合は未確定を許す

未確定のまま残した理由を分類して残す

矛盾が出たら根拠引用を必須にして再抽出する

モデルがそれっぽい完成品を捏造する余地が減りシステム全体として信頼性が上がる

■ 3. RLMの全体像と従来手法との比較

RLMの定義:

戦略立案担当と局所作業担当に分解する

Python等で検証可能な中間表現を挟む

誤りを差分として回収し再帰ループで収束させる方式

従来手法の問題点:

LLMに抽出させて人間が目視で直す運用がスケールしなかった

失敗が最後に露呈し修正が属人的だった

RLMの優位性:

失敗を途中で機械的に検出し修正を自動で次工程に流す

非構造化から構造化のような業務で予想以上に効く

コアの考え方:

賢い一発回答ではなく検証可能な中間表現と再実行プロトコルによって正しさへ収束する工程を作る

■ 4. KnowledgeSTATIONでの実装例

実装結果:

RLMによる非構造化データから構造化されたデータを取り出す機能を追加した

予想外にうまくいった

機能の詳細:

過去の著作や議事録や講義録など雑多な情報を貯めた知識ベースに注目するデータと出力して欲しいデータを渡す

技術的な話題に注目し技術と発明者とその効果と関連する技術を指定すると自動的にデータを検索して構造化する

RLMがどのように動作して情報をかき集めまとめているのかという過程も可視化されている

間違ったデータが出てきてもどこで間違ったのか理解しやすいメリットがある

出力例:

GPUやELIZAやAlexNetやニューラル機械翻訳やChatGPTなど技術に関する構造化データが抽出された

トークン上限8000など純粋に技術そのものとは言えないものも出てくるが索引などに引用する場合は納得できる

構造化されたデータはExcel形式でダウンロードできる

■ 5. RLMの特徴的なメリット

非構造化データのノイズの活用:

RLMがうまく回り始めると非構造化データのノイズがむしろ追加情報源になる

議事録の脱線や雑談や言い淀みや感情的な言葉が優先度の根拠やリスクシグナルとして意味を持つ

それ今日中にやらないとまずいという一言が期限の強制力を示す

顧客が同じ要望を三度言うならそれは単なる繰り返しではなく強い痛みの表現

RLMは再帰の過程でこうした文脈特徴を拾い上げ構造化スキーマに落とし込める

■ 6. 課題

計算コストの増加:

再帰はループを回すほどトークンも増え遅延も増える

検証関数の設計依存:

再帰の品質は何を矛盾とみなすかや根拠は十分かやスキーマ制約を満たすかの設計に依存する

情報の欠落:

ドメインによってはそもそも根拠がテキストに存在しないことがある

会議で決まったはずなのに議事録に書かれていない場合などが該当する

未確定を無理に埋めず追加の情報取得フローに接続する必要がある

エージェントは万能の魔法使いではなく情報の欠落を検知して次の行動へつなげる工程管理でもある

■ 7. 今後の展望

LLM活用の主戦場の変化:

文章生成ではなく非構造化データを意思決定可能な構造へ変換することになる

人間の組織が抱えるボトルネックは情報の不足ではなく情報の形式

見つけられないや比較できないや集計できないや追跡できないという問題がある

RLMはここに正面から切り込むための基本部品になり得る

ローカル動作の利点:

完全にローカルで動作するという点も見逃せない

クラウドAIのAPI利用料金や制限に悩まされることなく黙々とデータを構造化していく

エージェンティックAIの新局面:

RLMによってエージェンティックAIは新しい局面に到達できる可能性がある

(2026/01/16)

現場PMの力学 - 第1章：プロジェクトは「正しさ」では動かない

現場PMの力学 - 第1章：プロジェクトは「正しさ」では動かない

(2026/01/16)

OpenSSLプロジェクトの品質問題や組織構造の変遷について

■ 1. OpenSSLの品質問題

OpenSSLの品質や状況に懸念があるという指摘は専門家やエンジニアの間で事実として存在

特にOpenSSL 3.0(2021年リリース)以降パフォーマンスの低下やアーキテクチャの複雑化をめぐって厳しい批判

主な指摘内容:

パフォーマンスの大幅な劣化:

新しい「プロバイダー・アーキテクチャ」が原因で特定の処理が旧バージョン(1.1.1系)より著しく遅くなった

マルチスレッド環境でのロック競合によりスループットが劇的に低下

APIのオーバーヘッドにより証明書の検証や鍵の生成といった基本的な操作のステップ数が増加

コードの複雑化とテストの不備:

テストを通過していないコードがマージされる事象が2025年時点でも指摘

修正によって別のバグ(デグレード)が発生

メモリ安全性の欠如(C言語で書かれているためバッファオーバーフローなどの脆弱性が継続的に発見)

QUICへの対応遅延:

次世代通信規格QUIC(HTTP/3)への対応が非常に遅れた

多くのプロジェクトがBoringSSLやquictlsなどの別ライブラリへ流出

業界の反応(OpenSSL離れの加速):

BoringSSL: GoogleがOpenSSLをフォーク/不要な機能を削ぎ落としセキュリティとパフォーマンスに特化

rustls: Rust言語で書かれたTLSライブラリ/メモリ安全性が保証されパフォーマンスも高い

Goの標準ライブラリ: 独自実装を選択しOpenSSLの混乱の影響を受けない

■ 2. OpenSSLの資金面と組織面の変遷

Heartbleed以前(2014年以前):

世界中のインフラを支えていながら正社員はほぼゼロ

寄付金は年間わずか2,000ドル程度という極めて劣悪な環境

Heartbleed後:

Linux Foundationの「Core Infrastructure Initiative」などを通じて数億円規模の資金援助

組織は急拡大

資金拡大の副作用:

「商用化」へのシフト: 安定した運営のためサポート契約を販売する法人化を推進/大口顧客が求める「FIPS認証」などの要件が優先

官僚化と構造の複雑化: 少数の凄腕エンジニアによる属人的な開発から委員会による合議制へ移行/意思決定の鈍化

OpenSSL 3.0の問題:

過度な抽象化: 将来的な拡張性を求めて内部構造をゼロから作り直す「プロバイダー・アーキテクチャ」を導入/極めて複雑で旧バージョンの数百倍遅い処理が発生

QUIC対応の失敗: 内部の設計方針が二転三転した結果開発が大幅に遅れた

「レガシー」と「新設計」の板挟み:

世界中で動いているという責任があるため古いC言語のコード(30年前のものも含む)を維持しながら最新の安全な設計を取り入れる必要

テストの不足: 膨大なコードベースをカバーする自動テスト体制が追いついていない

技術的負債: Rustなどのメモリ安全な言語への移行を求める声もあるがC言語に固執せざるを得ない現状

■ 3. OpenSSLの組織改革(2024年〜)

二頭体制への分離(2024年3月〜):

OpenSSL Corporation(事業会社): 商用ユーザーや大口顧客を対象/サポート契約の販売/FIPS 140認証の取得など

OpenSSL Foundation(財団): 非営利コミュニティや個人開発者を対象/オープンソースとしての理念を守る

旧体制(OMC/OTC)の解散:

OMC(管理委員会)の解散(2024年3月): 代わりに10名の取締役会が意思決定

OTC(技術委員会)の解散(2025年4月予定): 代わりにTAC(技術諮問委員会)が新設され技術ロードマップの決定に透明性

リリースサイクルの「予測可能性」の重視:

タイムベースのリリース(毎年4月と10月)に移行

組織改革の背景にある反省点:

「身内感」の払拭: 閉鎖的な構造が外部からの批判を招いていた/新体制では選挙制を導入

「商用優先」への批判回避: 組織を分けることでバランスを取る

■ 4. OpenSSL 4.0の野心的変更(2026年4月リリース予定)

過去10年以上の負債を一掃するための「大掃除」のリリース

ENGINE APIの完全削除:

ハードウェアアクセラレータや独自の暗号モジュールを利用するための仕組み

設計が古くメンテナンスの大きな負担

「Provider(プロバイダー)」アーキテクチャに一本化

独自のハードウェア支援を利用している古いシステムはProvider形式に書き換えない限り4.0に移行不可

SSLv3のサポート完全終了:

2015年に脆弱性(POODLE)によって完全に否定されたがコードとしては残されていた

4.0ではSSLv3に関連するコードがライブラリから物理的に削除

C99標準への移行とツールチェーンの刷新:

非常に古いC言語規格(ANSI C/C89)をベースに書かれてきた

4.0からはC99以降のコンパイラが必須

コンパイラの最適化が効きやすくなりパフォーマンス劣化を解消するためのコード整理が進めやすくなる

スケジュール:

2026年2月: コードフリーズ

2026年3月: ベータ版リリース

2026年4月7日: 正式リリース(予定)

4.0でのリセットはOpenSSLが「枯れたが重いライブラリ」から「現代的で筋肉質なライブラリ」へと再生できるかどうかの分水嶺

The State of OpenSSL for pyca/cryptography

The State of OpenSSL for pyca/cryptography — Cryptography 47.0.0.dev1 documentation

要約:

■ 1. 記事の概要

pyca/cryptography(Pythonの暗号化ライブラリ)のメンテナーであるPaul KehrerとAlex Gaynorによる2026年1月14日の記事

12年間OpenSSLに依存してきたが成長する問題について2025年10月のOpenSSL Conferenceで発表

OpenSSLの開発における過ちが重大になったため実質的な変更が必要(OpenSSLに対して、または依存関係に対して)

■ 2. OpenSSLの軌跡(3幕構成)

第1幕: Heartbleed以前(2014年以前):

OpenSSLはメンテナンスが不十分で停滞していた

期待を大幅に下回っていた

第2幕: Heartbleed直後:

OpenSSLのメンテナンスが再活性化され大幅な進歩と改善

実際のコードレビュープロセスの導入

CIでのテスト実行開始

ファジングテストの採用

リリースプロセスの成熟

第3幕: 2021年のOpenSSL 3リリース:

新しいAPIを導入し大規模な内部リファクタリング

パフォーマンス/複雑性/APIの使いやすさにおいて大幅な後退

テスト/検証/メモリ安全性の面で必要な改善がなかった

同時期にOpenSSLのフォーク(LibreSSL/BoringSSL/AWS-LC)はこれらの分野で進歩

■ 3. パフォーマンスの問題

OpenSSL 1.1.1と比較してOpenSSL 3はパース処理やキー読み込みなどで大幅なパフォーマンス後退

楕円曲線公開鍵の読み込みがOpenSSL 1.1.1と3.0.7の間で5〜8倍遅くなった

改善後も以前より3倍遅い

OpenSSLの対応は「OpenSSL 3では後退が予想されており最適化の余地はあるが1.1.1レベルに戻ることは期待すべきではない」

pyca/cryptographyがX.509証明書パースをOpenSSLから独自のRustコードに移行した結果OpenSSL 3と比較して10倍のパフォーマンス向上

公開鍵パースを独自のRustコードに移行したことでエンドツーエンドのX.509パス検証が60%高速化

独自パースでより良いパフォーマンスを達成できることは実践的に可能であることを示している

彼らのパフォーマンスは巧妙なSIMDマイクロ最適化の結果ではなくコピー/アロケーション/ハッシュテーブル/間接呼び出し/ロックを避けるというシンプルな方法の結果

■ 4. 複雑性とAPIの問題

OpenSSL 3はAPIを大幅に変更し始めた

OSSL_PARAMを導入しすべての新しいAPIサーフェスに使用(ポスト量子暗号アルゴリズムを含む)

OSSL_PARAMは通常の引数渡しの代わりにキー値ペアの配列を関数に渡す

OSSL_PARAMの問題点:

パフォーマンス低下

コンパイル時検証の減少

冗長性の増加

コードの可読性低下

具体的な比較:

OpenSSLでML-KEMカプセル化を行うには37行と6つのフェイラブル関数呼び出しが必要

BoringSSLでは19行と3つのフェイラブル関数呼び出し

OpenSSL内部も複雑化:

OSSL_PARAMの配列管理を容易にするために多くのソースファイルがCファイルではなくCコード用のカスタムPerlプリプロセッサを持つ

OpenSSL 3は「providers」の概念を導入:

アルゴリズムの外部実装を許可

プログラム実行の任意の時点で任意のアルゴリズムを置き換えることを許可

ほぼすべての操作に無数のアロケーションとロックを追加する必要があった

パフォーマンス後退の原因

悪い決定の連鎖:

providersAPIの設計ミス → パフォーマンス後退 → キャッシングとRCUによる追加の複雑性 → さらなるバグ → それでもパフォーマンスは最初より悪い

OpenSSLのソースコードを読むことが苦痛になった:

間接呼び出し/オプションパス/#ifdef/その他の理解への障害の数が驚くべきもの

以前はそうではなかったしLibreSSL/BoringSSL/AWS-LCでもそうではない

■ 5. テストと検証の問題

OpenSSLプロジェクトはテストを十分に優先していない

OpenSSL 3.0開発サイクル中にテストカバレッジのギャップが顕著に見えた:

16ヶ月にわたる19のプレリリースの拡張アルファ/ベータ期間中にコミュニティからの後退報告に大きく依存

自社テストでは意図しない実世界の破損をキャッチするには不十分だった

バグ修正が付随する回帰テストなしでランドされることがまだ一般的

OpenSSLのCIは非常にフレーキー(不安定)でプロジェクトはこのフレーキーさを許容するようになった

OpenSSL 3.0.4の重大なバグの例:

AVX-512対応CPUでのRSA実装に重大なバッファオーバーフロー

CIで実際にキャッチされていたがCIランナーがたまたまAVX-512 CPUを持っている場合にのみクラッシュが発生したため障害はフレーキーさとして却下された

3年後もテストが失敗するコードをマージ:

カンファレンススライド準備日には最近の10コミット中5つがCIチェック失敗

トーク前日にはすべてのコミットがクロスコンパイルビルド失敗

Intel SDEなどのツール採用の価値:

x86-64拡張命令の異なるサブセットを持つCPUに対する制御されたテストが可能

AVX-512の有無での専用テストジョブを持つことで障害の性質がすぐに読みやすく再現可能になる

OpenSSLは形式検証の最先端に追いついていない:

形式的手法は学術的な新奇さから暗号コードの意味のある部分に対する実用的な現実になった

BoringSSLとAWS-LCは形式的に検証された実装を組み込み自動推論を使用して保証を高めている

■ 6. メモリ安全性の問題

OpenSSL作成時にはパフォーマンス/埋め込み可能性/メモリ安全性を意味のある形で提供するプログラミング言語はなかった

世界は変わった:

約5年前にpyca/cryptographyはRustコードを組み込んだ最初のリリースを発行

それ以来ほぼすべての機能をRustに移行

純粋なRustですべてのパースとX.509操作を行い暗号アルゴリズムにはOpenSSLを使用

パフォーマンス向上と複数のOpenSSL CVEの回避を達成

これらの移行が可能であることを彼らは知っている

セキュリティにコミットしたライブラリはメモリ安全なプログラミング言語への長期的な移行にコミットする必要がある

OpenSSLはこの問題に全くイニシアチブを示していない

■ 7. 原因の考察

これは資金不足やコモンズの悲劇の問題ではない

Heartbleed以降の10年間でOpenSSLはかなりの資金を受け取っている

現時点でOpenSSL CorporationとFoundationはBoringSSLまたはLibreSSLでフルタイムで働く人数より多くのソフトウェアエンジニアを雇用

他のOpenSSLフォークがこれらの同じ設計選択をしていないという事実は「これが必要だったか」という質問に対して有益な情報

■ 8. 今後の方向性

ポリシー変更1:

新機能にOpenSSL実装を要求しない

LibreSSL/BoringSSL/AWS-LCでのみ利用可能な新しいAPIを追加

具体的にはML-KEMとML-DSA APIをLibreSSL/BoringSSL/AWS-LCでのみ利用可能にしOpenSSLでは利用不可

ポリシー変更2:

現在wheelsにOpenSSLのコピーを静的リンクしている

wheelsをOpenSSLフォークの1つにリンクするために何が必要かを調査開始

ポリシー変更3:

バイナリwheelsをOpenSSLフォークの1つに切り替えることに成功した場合OpenSSLのサポートを完全に廃止する状況の検討を開始

長期的方向性:

GraviolaなどのOpenSSL派生でない暗号ライブラリを潜在的な代替として積極的に追跡

暗号実装を提供するために使用するライブラリの変更はユーザー(特に再配布者)に大きな影響を与えることを認識

これらのステップを軽々しく考えておらず急いで行うことも予想していない

懸念の重大さから行動せざるを得ない

pyca/cryptographyのOpenSSLサポートに依存している場合はOpenSSLプロジェクトに関与しこれらの軸での改善に貢献することが最も抜本的なステップを避ける最良の方法

(2026/01/16)

Why Be Reactive?

Crank.js | Why Be Reactive?

要約:

■ 1. 記事の概要

Crank.jsの開発者Brian Kim氏による2025年8月20日の記事

リアクティブフレームワークは自動的なUI更新を約束するが微妙なバグやパフォーマンスの罠を生み出す

Crankの明示的なrefresh()呼び出しは制限ではなく野心的なWebアプリケーションを構築するためのスーパーパワー

リアクティブ抽象化の一般的な落とし穴を検証しCrankがリアクティブ抽象化を持たない哲学的根拠を提供

■ 2. Crank.jsの特徴

「非リアクティブ」フレームワーク

コンポーネントは関数(async関数やジェネレータ関数を含む)

Promiseを直接コンポーネント内でawaitできる

状態をローカル変数として定義できる

状態が変更されたときにrefresh()を明示的に呼び出してビューを更新する

refresh()コールバックAPIの導入:

状態変更をrefresh()コールバック内に置くことでrefresh()の呼び忘れが不可能になる

コールバック内のコードが再レンダリングを意図していることを宣言的に特定できる

■ 3. バグの重大度分析

バグのクラスの「重大度」を評価する2つの質問:

これらのバグは見つけやすいか?

これらのバグは修正しやすいか?

Crankの場合:

refresh()の呼び忘れバグはアプリが更新されていないことにすぐ気づくため見つけやすい

refresh()呼び出しを追加するだけで修正しやすい

リアクティブ抽象化は古いレンダリングを排除すると主張するが独自の落とし穴を生む

■ 4. Solid.jsの問題: リアクティビティの喪失

Solid.jsではpropsはリアクティブストア

propsをデストラクチャリングしたり派生値をJSX式の外で計算しようとすると失敗する

壊れたコンポーネントはpropsが変更されても更新されない(値を抽出してpropsからJSXへのリアクティブ接続を壊すため)

バグの重大度:

単純なケースはリンタールールで見つけやすいが複雑なアプリケーションにはリンターの隙間をすり抜けるエッジケースがある

修正が難しい(フレームワークのリアクティブルールを理解する必要がある)

SolidはsplitPropsやmergePropsなどのユーティリティを提供する必要がある

Crankの明示的なrefreshモデルではこのクラスのバグは存在しない

■ 5. Vue.jsの問題: ディープリアクティビティのパフォーマンストラップ

Vueはプロキシを使用してリアクティブオブジェクトのプロパティと子を再帰的にリアクティブ抽象化でラップする

深くネストされた状態が変更されたときにDOM更新を実行するのに便利

問題点:

プロキシはプライベートクラスメンバーでは機能しない

プロキシはプリミティブには使用できない(VueがreactiveとrefのAPIを両方提供する理由)

大きなオブジェクトや配列を深くプロキシするとパフォーマンスのボトルネックになる

Vueはパフォーマンス問題を回避するためにshallowRef()やmarkRaw()などのエスケープハッチを提供

深くネストされた更新が再レンダリングを引き起こす便利さから追跡が必要な状態に移行

VueはisReactive()などのユーティリティを提供して開発者にデータのどの部分がリアクティブかを伝える必要がある

バグの重大度:

リアクティビティはデータ構造に不可視に追加されパフォーマンスのために選択的に削除されるため見つけにくい

修正が難しい(状態が作成された場所まで遡ってなぜリアクティブかどうかを把握する必要がある)

■ 6. Svelteの問題: エフェクトと無限ループ

Svelte v4以前は代入がコンパイラによって計装されて再レンダリングをトリガー

Svelte v5では「runes」という特別な構文を導入($state()/$derived()/$effect()など)

エフェクトを使用するリアクティブ抽象化は無限ループに陥りやすい:

同じ$state()ルーンを$effect()ルーンコールバック内で読み書きするとコールバックが発火し続ける

リアクティビティ支持者は「スプレッドシートのようなプログラミング」と称えるが多くの計算セルを持つスプレッドシートは遅い読み込みや開けない問題を抱える

解決策はSvelteのuntrack()関数でルーンの読み取りを非リアクティブとしてマーク

バグの重大度:

通常はすぐにスタックを吹き飛ばすが複雑なコンポーネントでは無限ループがすぐにトリガーされないエッジケースがある

$effect()ルーンはその中で実行されるすべてのコードを着色するためエフェクトコールバック内のコードだけでなくすべてのネストされた関数呼び出しもルーンに書き込まないようにする必要がある

修正が困難(デバッグ時に状態をログに記録するだけで無限ループがトリガーされる可能性がある)

CrankにはエフェクトAPIがないため無限ループを引き起こさない

■ 7. 各フレームワークのエスケープハッチ

リアクティブ抽象化は手動更新管理を排除すると約束するがそれぞれ独自のエスケープハッチと回避策が必要:

Solid: splitPropsとmergeProps(propsを安全に操作するため)

Vue: shallowRefとmarkRaw(パフォーマンスの崖を避けるため)

Svelte: untrack()(無限ループを防ぐため)

これらのAPIはリアクティビティが更新の懸念から完全に隔離してくれないことを示している

■ 8. 実行透明性(Executional Transparency)

参照透明性(Referential Transparency)はデータがどのように変換されるかを「見る」ことを容易にする

実行透明性はコードがいつ実行されるかを「見る」ことに関する

Crankコードは明示性により実行透明性が高い:

コンポーネントは親によって更新されるかrefresh()が呼び出された場合にのみ実行される

Reactは最もリアクティブ抽象化が少ないにもかかわらず最も実行不透明:

開発時にコンポーネントを二重レンダリング

useEffect()/useSyncExternalStore()/useTransition()などの混乱するAPI

コールバックがコールバックを返し任意のスケジューリングアルゴリズムの気まぐれで呼び出される

Reactエコシステムには「Why Did You Render」などのツールや過剰レンダリングのデバッグに関する無数の誤解とブログ記事がある

■ 9. 非リアクティビティはスーパーパワー

Webの最前線はTODOアプリではない

難しいもの:

アニメーション

仮想リスト

スクロールテリング

コンテンツ編集可能なコードエディタ

WebGLレンダラー

ゲーム

WebSocketストリームを使用したリアルタイムアプリケーション

大規模データビジュアライゼーション

オーディオ/ビデオエディタ

地図

リアクティブ抽象化はこれらの難しい問題に役立たない

コンポーネントがいつレンダリングされるかを明示的に制御することはスーパーパワー:

コードが実行される理由のコンテキストを維持できる

必要なときに正確にレンダリングできる

これらの重要な決定を仲介するリーキーなリアクティブ抽象化がない

(2026/01/15)

Constela - Compiler-First UI言語

要約:

■ 1. Constelaの概要

江口優一(yuu1ch13)氏によって開発されているオープンソースのUI言語およびフレームワーク

「UIをJavaScriptではなくJSON(DSL)で記述する」という非常にユニークなコンセプトを持つ

2026年1月時点で活発にアップデートが行われている(直近ではv0.8.0など)

■ 2. コンセプト: Compiler-First UI言語

従来のWeb開発(ReactやVueなど)ではJavaScriptのコードとしてUIを記述し実行時にそのロジックを動かす

ConstelaはUIを「プログラム(命令)」ではなく「検証可能なデータ(JSON)」として扱うことを重視

コンパイル時検証:

未定義の状態(state)の参照や不正なアクション/構造の不整合などを実行前に検出できる

静的解析の容易さ:

任意のJavaScript実行を排除し制約されたJSON形式にすることでUIの振る舞いが決定論的(予測可能)になる

■ 3. AIとの高い親和性

開発者が明示している大きな目的の一つが「AIによるUI生成・修正」への最適化

自然言語で書かれたコード(JSXなど)はAIにとって自由度が高すぎバグを含みやすいという課題がある

Constelaは構造化されたJSONであるためAIが「どのボタンがどの状態を更新するか」を正確に把握しやすい

機械的な自動生成や修正のワークフローに適している

■ 4. 主な機能と技術的特徴

State & Action:

UIの状態管理や副作用もJSON内で宣言的に定義

Style System:

Tailwind CSSのようなクラスベースのスタイリングが可能

CVA(Class Variance Authority)ライクなバリアント管理が可能(v0.8.0以降)

Builder API:

AIツールなどがプログラムからUIを構築するためのTypeScript APIを提供

コンポーネント化:

PropsやSlotといった概念も備えており再利用可能なUIパーツを定義できる

■ 5. 役立つ場面

AI生成UI:

ユーザーの指示からAIが即座に管理画面やダッシュボードを生成するようなアプリケーション

UIの安全な自動更新:

人間がコードを書かずにシステムのメタデータからUIを動的に構成したい場合

ノーコード/ローコードツールの基盤:

構造化データとしてUIを保持する必要があるサービスのバックエンド

■ 6. まとめ

単なる新しいUIライブラリではない

「人間が手でコードを書く時代から機械(AI)がUIを構成・検証する時代」を見据えた次世代のフロントエンド基盤を目指しているプロジェクト

特にAIとの連携機能や開発体験の向上が図られている

MEMO:

UIをJSONで定義し、そのJSONをコンパイルしていい感じのJavaScriptを生成する的なプロダクトぽい
筋は良さそうな印象だけど既存のUIコンポーネントは流用できるのだろうか？
また1から実装する必要があったりエコシステムが育つまで待つ必要があると厳しいものがあるが
Tailwind CSSとの統合はできるようだが
新しい言語として実装するのではなく、カスタマイズされたLinterとしての実装ではダメだったのだろうか？

(2026/01/15)

サラリーマンソフトウェアエンジニアのキャリア

サラリーマンソフトウェアエンジニアのキャリア - Speaker Deck

(2026/01/14)

【Crank.js】リアクティブという欠陥を完全解決したJavaScriptフレームワーク、Crank.jsの思想と信条

【Crank.js】リアクティブという欠陥を完全解決したJavaScriptフレームワーク、Crank.jsの思想と信条 #React - Qiita

MEMO:

聞き覚えがあると思ったら2020年頃に一度認知していた
作者が感動して涙を流したみたいな記事があった気がする

UseCaseレイヤーって要るの？

UseCaseレイヤーって要るの？

要約:

■ 1. 問題提起と背景

レイヤリングへの疑問:

Controller -> UseCase -> Domainsというドメイン駆動なレイヤリングに対して本当にUseCaseは必要なのかという問いに向き合う

どちらもロジックを持ち得るレイヤーでどう棲み分けするのが良いのか

以前のアーキテクチャ:

MVCというレイヤー分けをしてそれ以外にレイヤーを増やさないという誤ったRails Wayへの則り方だった

前任者の当時の判断は環境や状況にあったものだったかもしれないので悪いことだとは思っていない

アーキテクチャの修正:

CQRSの考え方を導入しレイヤーを一枚増やした

controllerがdomainsに依存する構成に修正した

■ 2. 新たな課題の発生

domainsの依存問題:

domainsがdomainsに依存してしまう状況が発生した

複雑なロジックを共通化するにあたりdomainsがdomainsを呼び出す箇所が生まれた

ロジックを書く場所がdomainsもしくはmodelsしか現状無いため

依存させたくないdomainsが依存を持ってしまうことになりアーキテクチャの破綻になってしまう

UseCaseの必要性への疑問:

UseCaseはやはり必要なのではないかという考えが生まれた

しかしUseCaseを挟んだところで今Controller -> Domainsでうまくいっている箇所においてはただdomainsを呼ぶだけのUseCaseができる

あまりにそういうのが増えて冗長なのではないかという疑問が生まれた

■ 3. DomainsとUseCaseの役割

Domainsの役割:

主な役割はビジネスロジックの実装

操作するものはDomainsオブジェクト

ビジネスルールはドメイン固有のルールを実装する

UseCaseの役割:

主な役割はユースケースの実装

操作するものはDomainsクラス

ビジネスルールはユースケースに沿った手順を実装する

本質的な違い:

DomainsとUseCaseは全く異なるもの

Domainsはサービスを展開するビジネス上におけるドメイン知識を含む

Domainsがアプリケーションの知識を持つ必要は全く無い

Domainsのコードそのものがドメイン知識を持つドキュメントとしても在るべき

UseCaseはドメイン知識を纏ったDomainsをユーザーストーリーにあったユースケースの手順に合わせて実装されるもの

UseCaseがドメイン知識を知る必要はなくユースケースにあったDomainsを利用するだけで良い

だいぶ抽象化されたドメインという概念を扱うだけの裏の苦労を知らないお客さん的なイメージ

■ 4. UseCaseの必要性の検討

現状の構成:

ControllerがDomainsに直接依存しているアプリケーションという状況

UseCaseの導入による弊害もある

UseCaseの弊害:

Controller -> Domainsでうまくいっている箇所においてはただdomainsを呼ぶだけのUseCaseができてしまう

呼ばれたらdomainsを呼び出すだけという冗長なクラスが増えていってしまう

段階的導入の困難さ:

全体にUseCaseを挟むというルールにするにはエンドポイント数的にも不可能なので段階的にはなる

そもそもUseCaseはoptionでいいんじゃないかという疑問が生まれた

相談結果:

冗長なUseCaseは増やさずとも良い

Controllerから直接Domainsに依存したところで問題はない気がする

もし他の手続きが必要になったならUseCaseを挟むのはそこまで大変な作業ではない

■ 5. まとめ

UseCaseの必要性:

UseCaseがなくても問題はない

役割の明確化の重要性:

Domainsにはドメインとなるロジックを抽出する

UseCaseはユースケースを実現するためのドメインを利用した手続きを書く

それぞれの役割を明確に意識することが重要

これはもちろんアプリケーションの実装ルール次第

それぞれの役割を明確に意識することでUseCaseにドメインロジックが生まれるなどの破綻を回避することができる

MEMO:

必要無いなら省略してもいいと思うけど、構造の一貫性という意味ではあってはいいかもの精神

(2026/01/14)

僕がフリーランスを続けなかった構造的な理由

僕がフリーランスを続けなかった構造的な理由｜すてぃお

要約:

■ 1. 記事の概要

2018年から2019年夏頃までの1年半フリーランスエンジニアとして活動した経験に基づく

フリーランスになってどこかの会社で業務委託として働くスタイルは長期的にはオススメできない

フリーランスとして業務委託で働く形態には経験が積みづらくなる構造的な力学が働いている

個人の努力や能力とは関係なくその構造の中にいると自然とそういう方向に引っ張られる

■ 2. フリーランス時代の振り返り

「経験を切り売りしていた」という感覚が強い

お金は得られたが新しい経験はほとんど積めなかった

社会的な価値も全然つかなかった

市場価値としてはほとんど上がっていなかった

危機感を覚えたのでフリーランスを辞めCTOになった

■ 3. 構造的な問題1: 挑戦させてもらいづらい

業務委託に入ると基本的に「成功しそうなことしか任せてもらえない」状況になる

クライアントからすれば外部の人間に失敗のリスクがある仕事を任せるのは怖い

正社員なら失敗しても一緒に成長していける

業務委託は失敗したら契約を切れば良いので確実にできることしか任せない

正社員は育成投資の対象になれるが業務委託はならない

得られにくい機会:

新しい技術に挑戦する機会

難易度の高いプロジェクトをリードする機会

事業の意思決定に関わる機会

フリーランスエンジニアが「得意なことをやり続ける」状態に陥る

効率は良いが成長はない

■ 4. 構造的な問題2: 社会的な評価が蓄積されにくい

「業務委託として開発」と書いても何をどこまで任されていたのかが見えない

「リードエンジニアとして事業を推進」と書けばオーナーシップを持って取り組んでいたことが伝わる

実際にやっていた仕事の内容が同じでも肩書きと立場で見え方が変わる

フリーランスとして働いている間その経験がどんどん「消費」されていく

正社員として働くとその会社での実績が積み上がり次第により大きな責任を持つポジションに就く

フリーランスの場合いくら長く働いても「外部の人」のまま

■ 5. 構造的な問題3: マネジメントや組織の意思決定に関われない

エンジニアとして成長するには技術力だけでは足りない

ある程度のキャリアを積んだ後は技術以外の能力が重要となる場合が多い

組織としての意思決定/マネジメント経験は組織の中で責任あるポジションに就かないと身につかない

外部の人間に組織のコアな部分を任せることはほとんどの会社がしない

採用の判断/チーム編成/評価制度/組織文化の形成は全て「中の人」だけで行われる

■ 6. この構造が生まれる根本的な原因

企業が「企業内人的資本の最大化」を目指すから

企業内人的資本 = 社員のスキル・知識・経験・ノウハウの総和

企業内人的資本が企業の競争力の源泉になる

正社員に投資すればその成長は企業内に蓄積される

業務委託に投資しても契約が終われば企業外に流出してしまう

正社員を雇う場合は長期的な視点で投資する

業務委託を使う場合は短期的な視点で考える

「投資対象かどうか」の違いが全ての構造的な問題の根源

■ 7. 例外: 労働市場の需給で変わるケース

「需要が供給を大きく上回るスキル」を持っている場合は状況が変わる

希少人材の例:

特定の領域で日本に数人しかいない専門家

世界的に見ても希少な技術スタックの経験者

業界で名前が知られているレベルの実績がある人

オープンソースのメインコミッターなど代替不可能な立場の人

こういった人はフリーランスであっても立場が強い

これは例外中の例外

ほとんどのエンジニアは「できる人が他にもいる」領域で仕事をしている

「自分は希少人材だ」と思い込んでフリーランスになるが実際にはそこまで希少ではなかったケースをよく見る

希少人材で居続けることができるかについてもよく考えるべき

■ 8. 「即戦力」という罠

フリーランスが求められるのは即戦力

即戦力として評価されるのは「今持っているスキル」

新しいスキルを身につける機会ではなく既存のスキルを使う機会を与えられる

最初は問題ないが数年経つと技術は進化する

フリーランスは「今持っているスキル」で契約しているから新しいことを学ぶ機会が少ない

正社員なら会社が新しい技術の研修を受けさせてくれることもある

業務委託は新しいことに挑戦するコストは自分で負担するしかない

「即戦力」として求められ続けることで皮肉にも「戦力としての価値」が下がっていく

■ 9. 社会資本という見えない資産

社会資本とは人間関係や信頼関係を通じて得られる価値

人脈/信用/評判/実績

正社員として働くと社会資本は自然と蓄積される:

同僚との信頼関係

上司からの評価

社内での実績

業界内での評判

昇進による肩書き

フリーランスの場合社会資本が蓄積されにくい

業務委託として入った会社の人との関係は契約が終われば薄れていく

毎回ゼロから信頼を築き直さないといけない

■ 10. 「自由」の代償

フリーランスになる理由として多くの人が「自由」を挙げる

働く時間を自分で決められる/嫌な仕事を断れる/場所を選ばずに働ける

しかしその自由には代償がある:

挑戦の機会を得る自由は失われる

成長する機会を得る自由も失われる

責任あるポジションに就く自由も失われる

表面的な自由と引き換えにキャリアの自由度を失っている

■ 11. 構造から抜け出す選択肢

選択肢1: 正社員に戻る

組織の中で責任あるポジションに就き挑戦の機会を得て社会資本を蓄積する

フリーランスの構造的な問題を根本的に解決する方法

選択肢2: 自分で事業を作る

業務委託ではなく自分のプロダクトを持つ

自分が意思決定者になりリスクも責任も自分が負う

構造的な問題を「逆転」させる方法

選択肢3: 戦略的にフリーランスを使う

長期間続けるのではなく特定の目的のために一時的に使う

キャリアの転換期に複数の会社を経験するため/特定のスキルを集中的に使って実績を作るため/正社員のオファーを見極めるため

強い意志が必要

■ 12. キャリア早期にフリーランスになる人に向けて

20代から30代前半はキャリアの中で最も成長が期待できる時期

この時期に「確実にできることしか任せてもらえない」環境に身を置くのはもったいない

経験の価値は「複利」で効く

20代で得た経験は30代のキャリアに効き30代で得た経験は40代のキャリアに効く

フリーランスで「経験の切り売り」を続けるとこの複利が効かなくなる

10年後/20年後のキャリアを考えた時今どんな経験を積むかは決定的に重要

■ 13. まとめ

フリーランスエンジニアが経験を積みづらくなるのは個人の問題ではなく構造の問題

この構造は「投資対象かどうか」という違いから生まれている

フリーランスになること自体が悪いわけではなく目的を持って期間を区切って戦略的に使うなら問題ない

問題はこの構造を理解せずにフリーランスを続けること

フリーランスを選ぶならこの構造を理解した上で選ぶこと

定期的に「今の自分は成長できているか」「社会資本は蓄積されているか」を問い直すこと

表面的な自由や短期的な収入より長期的な成長とキャリアの自由度の方が結局は大きな価値を生み出す

MEMO:

そもそもフリーランスというのは十分な経験を積んだベテランが選択するものであって、新卒や若手が選択するものではない
成長余地がある＝未熟者がやったところで単純な労働力を提供することしかできない
ベテランは経験則や知見の提供という目に見えない資産を持っていて、それらを提供することが市場価値になる
組織に何かしてもらう、挑戦する機会を与えてもらうと考えている時点でそもそもフリーランスを選択するべきではない
フリーランスに向いているのは「やっぱ組織で仕事するの向いてないな...」となった30代後半から40代の社会不適合者
同じ理由で新卒でSES企業に就職するのも悪手
こちらもフリーランスと同じく役割が固定されがちで経験を積むことが難しい構造なので、若手が選ぶべきではない
そもそもSES企業は案件に人間を放り込めば勝利なところがあるので育成を軽視している企業が大半
要領が悪い者は一生テスターみたいなケースが本当に発生し得る界隈である

AIはなぜTypeScriptのような型付き言語の普及を促進するのか、GitHubが理由を説明

AIはなぜTypeScriptのような型付き言語の普及を促進するのか、GitHubが理由を説明－ Publickey

(2026/01/13)

ChatGPTの登場でサービスがほぼ死んだのに、なぜか収益が2倍になったサービスがある...

ChatGPTの登場でサービスがほぼ死んだのに、なぜか収益が2倍になったサービスがある。

Stack Overflow。開発者なら誰もが世話になったQ&Aサイトだ。

2024年12月、このサイトに投稿された質問はたった6,866件。

16年前のサービス開始直後と同じ水準まで落ちた。Elon Muskが2023年に「death by LLM」と言った通り、みんなChatGPTやCopilotに聞くようになってフォーラムは瀕死状態。

でも面白いのはここから。

フォーラムは死にかけてるのに、会社としてのStack Overflowはむしろ元気になってる。

年間売上は約1.15億ドルで以前の2倍。赤字も8,400万ドルから2,200万ドルまで圧縮された。

何が起きたのか。

彼らは広告モデルを捨てて、全く別のビジネスに転換していた。

1つ目は「Stack Internal」という企業向け生成AIツール。16年分・数百万件のQ&Aデータを活用したもので、すでに25,000社が導入。

2つ目はRedditと同じデータライセンスモデル。AI企業に学習用データを売っている。

CEOのPrashanth Chandrasekarは去年12月にこう語った。

「減ったのは簡単な質問だけ。複雑な問題は今もStackで聞かれる。他に場所がないから。そしてLLMの品質は結局、人間がキュレーションしたデータ次第。うちはその最高峰だ」

つまりこういうことだ。LLMがStack Overflowのトラフィックを奪った。

でもLLMは学習データがないと動かない。Stack Overflowは最高品質のコーディングデータの宝庫。

結果、AIに殺されかけた会社が、AIにデータを売って生き延びてる。

テック業界の皮肉な循環経済。面白い事例。

@masahirochaen

ヒット作連発ゲーム開発者による4つのアドバイス。「チームは最小限に」「価格の決め方」など...

ヒット作連発ゲーム開発者による4つのアドバイス。「チームは最小限に」「価格の決め方」など“持続可能なゲーム開発”の経験則 - AUTOMATON

要約:

■ 1. 記事の概要

インディーゲーム開発者として15年の経験を持つTom Francis氏が4つのアドバイスを公開

Tom Francis氏はインディー開発スタジオSuspicious Developmentsの代表

過去作品:

ステルスパズル『Gunpoint』

宇宙船潜入アクション『Heat Signature』

ターン制戦略パズル『Tactical Breach Wizards』

『Gunpoint』と『Tactical Breach Wizards』はSteamで約1万件のユーザーレビューを得て98%という高い好評率で「圧倒的に好評」を獲得

ゲーム開発における成功の定義:

売上や賞賛の数ではない

快適なペースで次のゲームを開発できるという確信が持てるかどうか

持続可能な形で長期にわたって開発を続けるためのテクニックを紹介

■ 2. アドバイス1: できる限り小規模であり続けること

規模拡大のデメリット:

チームの規模を拡大すれば開発が速く進み成功確率も上がるように思えるが現実は逆になりがち

人員が倍になれば必要な売上も倍になるため単純に成功確率がどんどん減っていく

実体験:

2013年の『Gunpoint』がヒットした後に開発規模を大きく上げていたら次作は駄作となりその後はリリースできなかっただろう

2017年リリースの『Heat Signature』は開発が難航

開発期間が短ければひどい状態でリリースせざるを得なかった

ゲームが良い状態になるまでテストと開発を続けられるだけの規模を保ったからこそ変わらずにヒット作をリリースし続けられた

昨今のゲーム業界におけるレイオフについて:

人員増加によってレイオフやスタジオの閉鎖が起こるのであれば本当の意味の雇用創出にはなっていない

情勢に左右されにくいという面でも小規模な開発を続けることは効果的

■ 3. アドバイス2: 短期間で試作品を作れる企画を選ぶこと

プロトタイプの定義:

単なる技術検証に限らず「ゲームの良さが伝わる最低限の形」を指す

最終的なビジュアルのクオリティを想定したアート重視のプロトタイプ

ストーリーの冒頭を構築したナラティブのプロトタイプなども含まれる

プロトタイプのメリット:

結果によって残りの時間の使い方が明確になる

ゲームがどこに向かっているのかチームで確認できる

プロトタイプの重要な条件:

プロトタイプを作るだけで何年もかかるのであればプロトタイプの役割を果たさない

ゲームのアイデアが機能するかを方針を変える時間があるうちに確かめることが目的

失ってもいい時間の中で作れるかどうかが重要

どんなに素晴らしいアイデアでもプロトタイプ化できないならばインディーゲーム向きではない可能性がある

プロトタイプを作ってあらかじめ「安全確認」をおこなうことはリスクを避けるための鍵

■ 4. アドバイス3: テストの重要性(特効薬)

テストは時間も手間もかかるがテスト不足のまま発売することほど高くつくものはない

「ゲームを良くする」段階に時間を取れない場合には大きな問題になる

テストの進め方:

まずは社内向けのプロトタイプをほかの人が遊べる形にする

最初は少人数のテストでも構わない

少人数テストで得られるフィードバックは真に受け過ぎず深刻な問題などを修正するために利用する

コンテンツが揃っていなくとも大規模なテストを実施することを推奨

目安は100人以上/多ければ2000人規模

フィードバックの集め方:

Googleフォームを用いてフィードバックを集める

10点満点でゲームを評価してもらう

ゲームを本気で嫌っていた人の文句なのか解決しやすそうな小さな不満なのかをフィルタリングできる

人々がプレイしている様子を直接見るテストも重要:

『Heat Signature』では物理法則に基づく宇宙船の動きの制御に苦戦するプレイヤーが多いことを知り便利な機能の追加に繋げることができた

奇抜なゲームを作りたい人ほどテストをするべき:

テストはプレイヤーに何を変更するべきか訊いて仕方なくそれに従うものではない

最終的に決定を下すのはゲームデザイナーである自分自身

テストの質問も自分で決められるため達成したい目標に合わせて質問を調整することも大事

■ 5. アドバイス4: 価格設定について

売上を決める3要素:

ストアページを訪れる人数

購入したくなるかどうか

価格

価格だけは時間をかけずに簡単に変更でき一回のテストによって適正値を探れる

価格決定の方法:

テスターに「いくらなら妥当だと思うか」を尋ねる

一番多くの人が選んだ値で価格を決める

この方法でいずれの作品も高い評価と売上を得られた

「これだけ苦労したのだからもっと高く売りたい」という考え方には否定的:

開発者が売るゲームのコピーには原価がかからない

販売ターゲットになるユーザーは実質無限

価格を上げてもその分販売本数が減れば収益は変わらない

レビューの好評率や口コミの盛り上がりが削がれる可能性もある

重要なのはプレイヤーが納得して払うことのできるゲームの「適正価格」を見極めること

「底辺への競争」への懸念について:

PCのインディーゲームの価格を注視してきた22年間を通して一度も価格が下がったことはない

近年ではどの価格帯でも成功や失敗が起こる

開発者の増加とともに競争やノイズも増加

価格を決める際には周囲の傾向に左右されるべきでない

■ 6. 総括

Francis氏のアドバイスは限られた資金と時間の中で「ゲームを作り続けるための現実的な考え方」

良いゲームを作っても必ずヒットするわけではないが出来の悪いゲームを作れば確実にヒットから遠ざかる

大規模なヒットの可能性を上げるためにはマーケティングなどが噛み合うかどうかも関係してくる

プロジェクトが小規模であるほど利益を出すために求められる売上も少なくなり「成功」を掴みやすくなる

近年では市場に膨大なインディー作品があふれており「Indiepocalypse(インディーポカリプス)」という言葉も登場

競争は年々激化しインディーゲーム開発者を取り巻く環境が厳しさを増す中で長年スタジオを存続させてきた開発者の経験談は道標になる

(2026/01/13)

50代ベテランゲームデザイナーが傍若無人を行い、若い芽を摘みまくる現場で行った戦いをプロデューサー...

50代ベテランゲームデザイナーが傍若無人を行い、若い芽を摘みまくる現場で行った戦いをプロデューサー視点で書く（ゲーム in the ノンフィクション）｜うきょう|フリーゲームプロデューサー兼マーケッター（株スタジオデルタ代表）

要約:

■ 1. ゲームデザイナーとは

ゲーム全体をデザインする職種

「ゲーム」という媒体を通して作り手側がイメージするユーザー体験までを作り上げる非常にテクニカルかつアーティスティックな業務を担う

業界の熟達者であり知識が豊富で年齢を重ねていることが一般的

日本では「ゲームデザイナー」という職種がある会社はあまり存在しない

ゲームデザイナーを自称する人の特徴:

他の技術や知見に対しても優れていることが多い

非常にプライドが高い傾向

自己愛が強すぎる

他人に対して攻撃的な人が多く権威者に弱い

若手の企画者を極端に小馬鹿にしている姿勢が強い

■ 2. 問題のベテランゲームデザイナーの事例

50代のベテランで「リードプログラマ兼ゲームデザイナー」を名乗る人物

40名のチームで社員プログラマが3名しかおらず業務委託プログラマが5名という異常な構成

会議での問題行動:

「この企画ダメじゃね?」「この仕様って何の意味があるの?」「それオレはやらない」「この本読んだ?これぐらい読んどけ」などの発言

会議の場が凍る

正論だが利用可能なリソースと技術力が無視されたコメントが多い

ゲームデザインセンスがないやつは企画をするべきではないという話になる

役員が参加すると一切発言しない

会議で何も言わなかった項目について後から「オレはこの仕様がいいと思っていない」と言い始める

■ 3. ベテランの問題行動の特徴

他人の仕事を全否定する

自分で責任をとらないポジションだけを選び続け管理しない

無用なものは切り捨てるのでチーム内で下についた者で無用と思われた者は放置される

業務委託のプログラマの仕事も監修すると言い出しアウトプットが減る

自分の美学を貫き通すがチームのスケジュールや目標には配慮しない

■ 4. チームへの影響

チームの空気が悪くなり遅刻/欠席が多くなる

傍若無人に振る舞う人ほど長居するし健康体(ストレスが少ないため)

若いデザイナー/若い企画者がそのベテランと関わると次々と体調不良で休む

仲介役を挟んでも仲介者が退職する

役員レベルも「8年前から入社してずっとあんな感じ」「みんなダメだった」と放置状態

■ 5. 耐えられる人のパターン

ほぼ干渉せずに業務範囲を明確に区分している人

悟りを開いている人

自分自身の業務責任を責務として請け負えるタイプで自分から提案はしない人

配属されるプログラマは皆辞めるか他部署への異動依頼を出す

■ 6. プロジェクトの結末

形だけリリースしたがうまくいかなかった

機能が足りなすぎてゲームとして成り立っていない

ベテランは「オレならもっと良くできた」と発言

部署を2つに分けベテランチームと既存サービス運営チームに分離

ベテランがいないチームは士気と活気が戻りプロジェクトの業績が上がり始めた

ベテランが在籍するチームは何も新しいものが生まれないまま2年経過し解散

ベテランは最後まで退職をしぶったが会社と交渉して退職

■ 7. 反省点と教訓

部下が育たない事例や自分の価値観とそぐわない人と協調がうまくできずにパワーでねじ伏せるタイプの人は非常に多い

ベテランの知識や知恵をわかりやすい形で共有できる工夫ができれば良いクリエイティブの方向にできたかもしれない

ベテランは「当人が努力すること。それぐらい知ってて当然」というスタンスだったため真のゲームデザインが誰にも伝わらなかった

責任を回避する行動が多く意見だけを言う姿勢はチーム開発においてマイナス

理不尽な人の側で働き続けて業界を引退した人は数知れない

■ 8. グラフィック部門での類似事例

ベテランのグラフィックリーダーがいるチームでその下のグラフィックメンバーがことごとく退職

言語化が極めて苦手で部下に対する指示がめちゃくちゃかつ訳がわからない箇条書きだけ

他人の仕事を取り上げて自分で修正または作り直しを繰り返した結果チームメンバーは自分の存在価値に自信を失い休職/離職が多発

グラフィックリーダーを別の部署へ異動させた

■ 9. デザインするとは何か

「ヒト/モノ/情報/サービスを何かの媒体で体験できる形に作り上げ利用した人が特定の感情/体験/経験までを得られるようにすること」

作り手側がある程度狙って創造していることを具現化/体現化/提供するまでの品質を担保すること

■ 10. ゲーム開発の現場への提言

大切にしたいのはいい人と付き合うこと

人生をすり減らす人と付き合ってはいけない

有益な知識や経験が手に入るかもしれないが短命で終わる意味はない

できる限り長く創作活動ができること

評価してくれる環境に身を置くこと

自分の環境を良くするための努力を惜しまないこと

決して泣き寝入りだけはしないでほしい

(2026/01/12)

React 19でつくる「気持ちいいUI」- 楽観的UIのすすめ

React 19でつくる「気持ちいいUI」- 楽観的UIのすすめ - Speaker Deck

(2026/01/12)

MSXは範囲を広げすぎに対しての理由説明　時系列で　30年前のアーキテクチャを甦らせるなんて無理と...

MSXは範囲を広げすぎに対しての理由説明

時系列で

30年前のアーキテクチャを甦らせるなんて無理と10年前まで思っていました

でもIoTになら使えるとMSX0を大学で始めました

同時に次世代MSX3も始めました

オープンソフトウェアのlinux系にCPUは当初ArmでしたがオープンCPUのRiscVに変更しました

そして気が付きました

今までの未完成なMSXを完成させなければならないと

それがMSX2++とMSX#です

あとMSXboosterというMSX1とMSX2,2+に対してハードウエアとソフトウェアのアップグレードを研究中です

そしてMSXのAi

1.Aiを使って他からの移植や新しいソフトウェアを簡単に創るということと

2.Aiそのモノを勉強するという切り口

ならAiをMSXでやることの意味もあると思いました　安ければ

あとはエミュレータとWeb

沢山の人にMSXに出会って貰い

試しに使ってもらえるようにしたいということで、やりますタダです

以上再確認させて頂きました

@nishikazuhiko

(2026/01/12)

AIのせいでAIの学習データがなくなってきている

AIのせいでAIの学習データがなくなってきている - きしだのHatena

ニューヨーク市長就任式、ラズパイとFlipper Zeroを名指しで持ち込み禁止――武器や爆発物と同列に

ニューヨーク市長就任式、ラズパイとFlipper Zeroを名指しで持ち込み禁止――武器や爆発物と同列に - FabScene（ファブシーン）

ニューヨーク市長就任式、ラズパイとFlipper Zeroを名指しで持ち込み禁止――武器や爆発物と同列に

2026年1月1日に開催されたニューヨーク市長Zohran Mamdani氏の就任式で、Raspberry PiとFlipper Zeroが持ち込み禁止品に指定された。公式サイトに掲載された禁止リストでは、武器、花火、爆発物、ドローンなどと並んで、2つのデバイスがブランド名で明記されている。

Flipper Zeroは、RFID、NFC、赤外線、Bluetooth、無線信号などの通信プロトコルを学習・テストするためのハンドウェアデバイスだ。セキュリティ研究者や開発者に利用されている一方、車両盗難やネットワーク侵入への悪用が懸念され、各国政府から規制の対象として議論されてきた。Amazonも過去にカードスキミングへの懸念から販売を禁止した経緯がある。

一方、Raspberry Piは教育用途から産業用途まで幅広く使われる汎用のシングルボードコンピューターで、教室、報道機関、アート作品、アクセシビリティ機器など多様な場面で採用されている。

禁止リストが公開されると、技術コミュニティから疑問の声が上がった。ノートパソコンやスマートフォンは禁止されていないにもかかわらず、これらはRaspberry PiやFlipper Zeroよりも高機能で、同等以上のことが可能だからだ。セキュリティ専門家のStefan Klatt氏はX（旧Twitter）で、銃器やドローン、ガラス瓶といった危険物と並んで、IT機器2種が名指しされている点を指摘した。

Adafruitの創業者Phillip Torrone氏は、カテゴリーや機能ではなくブランド名で特定のデバイスを禁止するのは異例だと述べ、市長チームに禁止理由を問い合わせた。AIがリスト作成に関与したかどうかも質問したが、回答は得られていないと同社のブログで述べている。

Torrone氏は、今回Raspberry PiとFlipper Zeroが禁止されるなら、次はBeagleBone、Arduino、ESP32開発ボード、SDRドングル、さらにはマイコンを内蔵した腕時計まで禁止対象になりかねないと懸念を示した。

就任式はシティホールでの宣誓式に続き、ブロードウェイで4万人規模のブロックパーティーとして開催された。Bernie Sanders上院議員やAlexandria Ocasio-Cortez下院議員らが登壇している。

MEMO:

警備チームの中で情報が錯綜して「よく分からんけど禁止！」みたいな雑ルールになった可能性ありそう

(2026/01/11)

「Googleでの14年間で学んだ21の教訓」を個人的な解釈でまとめてみた

「Googleでの14年間で学んだ21の教訓」を個人的な解釈でまとめてみた #初心者 - Qiita

要約:

■ 1. 記事の概要

Googleで14年間Chromeに携わり現在はGoogle Cloud AIでディレクターを務めるAddy Osmani氏が経験から学んだ教訓をまとめたブログの解説

技術的なTipsではなくエンジニアとして無理せず長く続けていくための実践的な知恵が詰まっている

原文は「21 Lessons From 14 Years at Google」

■ 2. 21の教訓

教訓1: 技術ではなく「ユーザーの困りごと」から始める

「この技術どこで使おう?」ではなく「ユーザーは何に困ってる?」から考える

問題を本当に理解しているエンジニアは解決策が予想よりシンプルであることに気づく

教訓2: 正論で勝っても意味がない

議論に勝ってもチームの協力が得られなければプロジェクトは進まない

「強い意見を弱く持つ」— 不確実な状況での決定を自分のアイデンティティにすべきではない

教訓3: 考えすぎる前に手を動かす

完璧な設計を考え続けて何も作らないより雑でもいいからまず作る

「まず作る→直す→良くする」の順番

教訓4: 「賢いコード」より「読みやすいコード」

深夜の障害対応で読むのは未来の誰か

明快さはスタイルの好みではなく運用リスクの低減

教訓5: 新技術の導入は「借金」と同じ

導入するたびに「学習コスト」「採用難」「トラブル時の情報不足」という借金を背負う

独自に報酬を得ている場所でだけイノベーションしそれ以外は退屈でいい

教訓6: 良い仕事も伝わらなければ存在しないのと同じ

自分がいない場で誰もあなたの成果を説明できないならその成果は実質オプション

自己宣伝ではなく価値の連鎖を「読める」ようにしておくこと

教訓7: 最高のコードは「書かなかったコード」

書いたコードは全部将来のバグ/保守/説明の対象になる

問題は書くのが上手すぎて書くべきかどうかを問うのを忘れること

教訓8: 大規模になるとバグにもユーザーがつく

ユーザーが増えるとバグや癖を前提にした使い方をする人が出てくる

互換性作業を「メンテナンス」新機能を「本当の仕事」として扱うことはできない

教訓9: 遅いチームは実は「ズレてる」チーム

本当の原因は方向性や優先順位がチーム内で揃っていないこと

シニアの仕事は「速く書く」より「認識を揃える」こと

教訓10: 変えられないことは気にしない

自分がコントロールできることだけに集中する

受動的な受容ではなく戦略的なフォーカス

教訓11: 抽象化は複雑さを「後回し」にしているだけ

便利なライブラリやフレームワークは「中身を知らなくていい」という賭け

シニアエンジニアはスタックが高くなっても「低レベル」のことを学び続ける

教訓12: 教えると自分の理解が深まる

人に説明しようとすると自分が曖昧に理解していた部分が見つかる

アウトプットは最高のインプット

教訓13: 「縁の下の仕事」は大事だが見えないと評価されない

ドキュメント整備/新人教育/チーム間の調整は不可欠だがただの「お人好し」で終わりやすい

性格特性ではなくインパクトとして可視化する

教訓14: 議論で全勝してるなら裏で反感を買っている

相手は納得したのではなく諦めただけかもしれない

正しいという短期的な感覚は意欲的な協力者とものを作る長期的な現実よりはるかに価値が低い

教訓15: 指標は「目標」にした瞬間意味を失う

人は測定されるものを最適化する

スピードと品質両方の指標をセットで見ることが大事

教訓16: 「わからない」と言えることがチームを安全にする

シニアが知ったかぶりをすると若手は質問できなくなる

最もシニアな人が混乱を認めないチームでは質問は出ない

教訓17: 人脈はどの仕事よりも長く続く

関係を築いた人は何年後かに機会を運んでくれる

打算ではなく好奇心と誠実さで人と繋がる

教訓18: 速くするには「やらないこと」を増やす

一番効くのは「そもそもこの処理いる?」と削ること

最適化する前にその仕事がそもそも存在すべきかを問う

教訓19: プロセスは「安心のため」ではなく「不確実性を減らすため」

目的を説明できないプロセスは見直す

最悪のプロセスは助けるためではなくうまくいかないときに責任を割り当てるために存在する

教訓20: いつか「時間＞お金」になる

何を差し出しているか自覚して選ぶ

時間は再生不可能な資源

教訓21: 近道はない。でも「複利」はある

一発逆転を狙うより毎日少しずつ学んで積み上げる方が強い

学習は単なる新しい雑学ではなく新しい選択肢を生み出すときに複利になる

■ 3. まとめ

21の教訓は3つに集約される:

好奇心を持ち続ける — 学ぶことをやめない

謙虚であり続ける — 「わからない」と言える/一緒に答えを探す

人を忘れない — ユーザーのために作りチームと一緒に作る

尊敬すべきエンジニアは常に正解を出した人ではなく失敗から学び気づきを周りと分かち合い諦めずに現場に立ち続けたエンジニア

最終的には「どうすれば自分をすり減らさずにこの仕事を長く続けられるか」を教えてくれるもの

(2026/01/11)

APG Patterns Examples

パターン | APG Patterns Examples

WAI-ARIA APG パターンを React、Vue、Svelte、Astro で実装したアクセシブルな UI コンポーネントとテストを提供します。簡潔な実装例と検証可能なテストで、アクセシブルなインターフェース構築を支援します。ダークモード、ハイコントラスト、強制カラーモードにも対応しています。✨

(2026/01/11)

経営者が知るべき、なぜエンジニアの「合理的な判断」が事業を圧迫するのか

経営者が知るべき、なぜエンジニアの「合理的な判断」が事業を圧迫するのか｜すてぃお

要約:

■ 1. 問題の概要

個人としては合理的な判断が組織として見た場合に非合理な判断となり事業を圧迫する

よくある相談内容:

開発に時間がかかりすぎる

サーバーコストが高いのではないか

新機能追加のたびに想定以上の工数がかかり見通しが立たない

月間数百/数千ユーザー程度のサービスに対して規模に明らかに過剰な状態となっていることが多い:

複雑な運用が必要な大規模向けの構成

最新技術が多数導入され全体の見通しが悪い

ほとんど負荷がないのにキャッシュ層が導入されている

データベースは大きめのサーバーで複数拠点での冗長構成

エンジニアの能力不足ではなく個人として合理的に行動した結果意図してこのような状態にしている可能性がある

個人の問題ではなく構造的な問題

■ 2. 原因1: 転職市場が生む「キャリア最適化」のインセンティブ

転職市場での評価:

3年間安定したシステムを堅実に運用しパフォーマンスを最適化した経験より1年で最新技術を使った新しいシステム構築をリードした経験の方が年収が上がりやすい

「事業に必要かどうか」より「履歴書に書けるかどうか」が優先される構造

評価されるのは「ポータブルなスキル」:

最新技術の導入経験

有名な技術スタックでのシステム構築実績

業界標準とされる開発手法の経験

評価されにくいもの:

自社サービス固有の知見

チーム独自のノウハウ

結果として生まれる構造:

月間利用者数が少ないサービスでも大規模構成

小規模チームで複雑なシステム分割

シンプルな構成で十分な規模で最先端技術を導入

■ 3. 原因2: 成功企業の事例を真似する罠

技術カンファレンスやブログで目にするのはメルカリ/freee/エムスリーのような成功企業の事例

「最新技術で組織をスケールさせた」「マイクロサービス化で開発速度を向上させた」という事例は極めて特殊な前提条件の上に成り立っている

彼らにとっての「複雑なシステム」は組織のスケールに対する解決策であって技術的な理想形ではない

「成功企業のやり方=正解」という空気が規模に合わない設計を正当化してしまう

■ 4. 原因3: "絶対に落とさない"に対してのコスト

「システムが止まったら困るから念のため」という思考が過剰な構成を生む:

複数拠点での冗長構成を初期から導入

サーバーは「大きめ」で確保

全システムを最高レベルの安定性で設計

将来の負荷に備えて先行投資

月間数千ユーザーのサービスに月間数百万ユーザーに対応できる構成

「念のため」という言葉で正当化されるが経営的には大きな機会損失

余剰コストで本来は新機能開発や顧客獲得に投資できたはず

■ 5. 対策1: 「キャリア最適化」のインセンティブに対して

「シンプルに保つこと」を評価項目に追加:

新技術導入だけでなく技術的負債の削減も評価

「コスト削減に成功した」を実績として認める文化

長期的な運用/改善を正当に評価

技術選定の意思決定プロセスを明文化:

「なぜこの技術を選ぶのか」を意思決定プロセスに組み込みドキュメント化

事業的な必要性を説明できることを前提とする

外部の目を入れる:

技術顧問やアドバイザーによる定期的なレビュー

「今の規模に本当に必要か」を客観的に判断

■ 6. 対策2: 成功企業の事例を真似する罠に対して

小さく始めて段階的に拡張する原則とする:

初期フェーズはシンプルな構成でスタート(1つのアプリケーション/基本的なデータベース構成/最低限の監視/目標レベル99.5〜99.9%)

成長に応じた3段階の拡張ステップを想定:

ステップ1: まず最適化(クエリ最適化/インデックス追加/キャッシュ導入/N+1問題の解消)

ステップ2: サーバー性能アップ(CPU/メモリの増強/スケールアウト)

ステップ3: システム分割(マイクロサービス化/専門チームの配置)

多くの場合ステップ1〜2のみで十分対応できる

「今の規模」に最適化する文化を作る:

「最初から完璧」ではなく「必要になったら拡張」を原則とする

各段階のコスト対効果を明確にし拡張のタイミングを事前に合意

「早すぎる最適化」を避ける文化を醸成

成功企業の規模と自社の規模の違いを認識

■ 7. 対策3: "絶対に落とさない"に対してのコストに対して

「どれだけ止まっていいか」を経営判断として決める:

「止めない」ではなく「どこまで止まっていいかを最初に決めること」が重要

99.9%稼働率ということは月43分程度は止まる可能性があるということ

止まってはいけないということはリスクを取りづらくなるコストが存在する

システム内で優先順位をつける:

ユーザーが見る画面やクライアントが常に使っている機能については落ちづらくしておく

社内で使用する管理画面などは落ちても問題ないとする

ユーザーやクライアントに直接影響する機能と社内でしか使わない管理機能を同じレベルで守る必要はない

■ 8. 結論

エンジニアが個人として合理的に動いた結果事業が後退してしまうのは構造的なインセンティブの帰結

「うちのエンジニアは大丈夫」と慢心せずに対策していくことを推奨

最高なのは個人の合理性と組織の合理性を一致させること

それを思わせるのが経営者の役割

エンジニアと経営者が同じ方向を向いて判断できる組織は強い組織

MEMO:

スタートアップでは技術が福利厚生みたいなところはあるけど、後先考えないエンジニアもかなり多い

(2026/01/11)

stoolap - Rustで実装された組み込みRDB

GitHub - stoolap/stoolap: A Modern Embedded SQL Database written in Rust

Why Stoolap?

Stoolap is a feature-rich embedded SQL database with capabilities that rival established databases like PostgreSQL and DuckDB - all in a single dependency with zero external requirements.

なぜスツールアップなのか?

Stolapは、PostgreSQLやDuckDBといった既存のデータベースと競合する機能を備えた、機能豊富な組み込みSQLデータベースであり、すべて外部要件がゼロの単一の依存関係にあります。

(2026/01/11)

Linus、「AIツールはただのツール」とあらためて強調

Linus、「AIツールはただのツール」とあらためて強調 | gihyo.jp

要約:

■ 1. 背景

AIツールによるコーディング支援が広く普及

LinuxカーネルコミュニティでもAIツールが生成したコードの扱いについて議論が継続

Linus Torvaldsは一貫して「AIツールも単なるツールのひとつ」という態度を維持

■ 2. カーネルガイドラインの策定

x86アーキテクチャメンテナーのDave Hansen(Intel所属)が中心となりガイドライン作成が進行

正式名称は「ツール生成コンテンツに関するカーネルガイドライン(Kernel Guidelines for Tool-Generated Content)」

2025年1月6日に第3版を公開

ガイドラインの目的:

カーネル貢献者は長年ツールを使用して貢献を生み出してきた

ツールは貢献の量を増やすがレビュー担当者とメンテナーのリソースは限られている

貢献のどの部分が人間によるものでどの部分がツールによるものかを理解することが重要

ツールに関するコミュニティの期待を明確にすることがゴール

ガイドラインには「AIツール」「LLM」といった用語は含まれていない

■ 3. メンテナー間の意見対立

Lorenzo Stoakes(Oracle所属/メモリマネジメント分野メンテナー)の主張:

LLMは単なるツールではなくまったく新しいツール

LLMによるAIスロップ(低品質な生成AIコンテンツ)がエンドツーエンドで大量に送信されることはこれまでできなかった

AIスロップがパッチとして送られてきた場合に議論なく却下できることをドキュメントで明確に表明すべき

LLMを「単なるツール」とすることはカーネルがLLMの問題にまったく影響を受けないと言っているようなもので愚かなポジションに見える

■ 4. Linus Torvaldsの反論

AIスロップについて議論することにはまったく意味がない

AIスロップを作って送ってくる連中は自分のパッチをドキュメント化しようとは思わない

ドキュメント作成は善良な人々のためのものでありそれ以外を対象にするのは無意味

カーネル開発に関連するいかなるドキュメントもAIに関する声明のようなものになることを望まない

AIに関しては「空が落ちてくる」という主張と「ソフトウェアエンジニアリングに革命を起こす」という主張がありそれぞれに賛同者がいる

カーネル開発ドキュメントがそのいずれの立場もとることを望まない

AIツールを「単なるツール(just a tool)」という表現に留めておきたい

AIスロップの問題はドキュメント化によって解決するはずもない

それを信じる人は世間知らずか自分の意見を主張したいだけの人

■ 5. 現状の見通し

生成AI/LLMはこれまでの開発ツールと異なりパッチにAIスロップが増えることに危機感を持つメンテナーも存在

当面はカーネル開発におけるAIツールは「単なるツール以上でも以下でもないもの」として位置づけられる見込み

(2026/01/10)

『Balatro』も採用したシンプルな2Dゲームフレームワーク「LÖVE」とは。エンジニア目線で魅力を解説

『Balatro』も採用したシンプルな2Dゲームフレームワーク「LÖVE」とは。エンジニア目線で魅力を解説｜ゲームメーカーズ

要約:

■ 1. Love2dの概要

Luaで記述する2Dゲームフレームワーク

zlib Licenseで配布されており商用利用含め完全無料

対応OSはWindows/macOS/Linux

オープンソースのためエンジン運営状況に左右されない

提供機能:

画像/音声の読み込みと再生

キーボード/マウス/ゲームパッドの入力処理

図形やテキストの描画

シーン管理やUIなど高レイヤー機能は含まれない

必要な機能は自作またはコミュニティのライブラリを使用

■ 2. Love2dの魅力

コードだけで完結する開発体験:

IDEが不要

好きなテキストエディタとターミナルだけで開発可能

開発環境を自分好みにカスタマイズ可能

Lua言語の特徴:

構文がシンプルで学習しやすい

プログラミング経験があれば数時間で基本習得可能

配列が1から始まる/endでブロックを閉じるなど独特な部分あり

LuaJIT採用により動的言語でありながら高い実行速度を実現

C/C++ライブラリとの連携が容易

採用実績:

2024年発売の『Balatro』は1か月で100万本以上を売り上げ

開発者は複雑なIDEを備えたゲームエンジンを避けたかったと発言

■ 3. 他の2Dゲームフレームワークとの比較

静的型付け言語のフレームワーク:

Raylib(C言語)/MonoGame(C#)/Ebitengine(Go)/DXライブラリ(C++)

型安全性のメリットあり

スピード重視のプロトタイピングには動的型付け言語が有利

JavaScriptライブラリ:

Phaser.jsなど

Webブラウザ実行に特化

インストール不要でスマートフォンでもすぐに遊べる

デスクトップアプリケーション配布には不向き

Love2dの立ち位置:

デスクトップ向け2Dゲームを素早くプロトタイピングしながら開発したい場合に適合

■ 4. Love2dのデメリット

3D機能の制限:

2D専用設計のため3Dゲーム開発は基本的に不可能

将来的に3D要素を追加する可能性があるプロジェクトには不向き

日本語情報の少なさ:

公式ドキュメントは英語中心

日本語チュートリアルや解説記事は限定的

公式Wikiは充実しているため英語に抵抗がなければ問題なし

エコシステムの規模:

UnityやUnreal Engineと比べて小さい

アセットストアやプラグインは期待できない

多くの機能を自前で実装する必要あり

UIライブラリがないためボタンやスライダーなどを自作する必要あり

大規模プロジェクトの構造化:

Luaは柔軟性が高い反面設計規約やアーキテクチャの統一が重要

適切な設計なしでは保守性が低下するおそれあり

■ 5. 総括

Love2dは2Dゲーム開発に必要な基本機能だけを提供するフレームワーク

UnityやUnreal Engineとは対極の設計思想

コードベース開発を好む開発者や使い慣れたテキストエディタで開発したい開発者に魅力的

『Balatro』の成功が示すようにツールの機能の豊富さではなくアイデアと実行力がゲーム開発の本質

Love2dの軽快な開発体験はこの本質に集中することを可能にする

(2026/01/10)

Tailwind CSSの騒動から考える、生成AIがOSSビジネスを壊す瞬間

Tailwind CSSの騒動から考える、生成AIがOSSビジネスを壊す瞬間 - Sweet Escape

要約:

■ 1. Tailwind CSSの騒動の概要

Tailwind CSSはオープンソースで提供される人気のCSSフレームワーク

公式ドキュメントをLLMフレンドリーにするためのPRが作成された

Tailwind LabsのAdam氏が深刻な現状を公表:

生成AIの普及により公式ドキュメントへのトラフィックが激減

従業員の75%をレイオフ

トラフィックは40%減

売上は80%減

■ 2. Tailwindのビジネスモデル

Tailwind CSS自体はOSSで無料

収益源は公式が提供する有料UI資産(現在はTailwind Plus)

Tailwindを使ったUIコンポーネントやテンプレートをワンタイム課金で提供

ビジネス構造:

OSSで利用者を増やす

公式ドキュメントや設計思想への理解を通じて信頼を獲得

その延長線上で有料の公式プロダクトを購入してもらう

■ 3. 問題の本質

「OSS → ドキュメント → 有料プロダクト」という売上ファネルの入り口が死んだこと

従来の行動パターン:

何かを調べる

公式ドキュメントを読む

公式サイトにアクセスする

生成AI普及後の行動パターン:

AIに聞いてその場で完結する

ドキュメントやサイトへのアクセス流入を前提に成立していたビジネスモデルにとって致命的

■ 4. OSSビジネス全般への影響

一般的なOSSを軸にした企業のビジネスモデル:

OSS本体は無料

有料SaaS版/有料サポート/マネージド版などで収益化

ドキュメントや公式サイトでユーザーを獲得

多くのOSSビジネスは「OSS × 情報提供(ドキュメント)」を起点にしたファネルに依存

生成AIは「情報提供」の部分を根こそぎ代替してしまう可能性が高い

有料サポートや実装支援も生成AIに代替されるケースがある

■ 5. /llms.txtが突きつけるジレンマ

LLMにドキュメントを読みやすく提供する行為:

OSSプロダクトの認知を広げるための生存戦略である一方

自分たちのサイトに人を呼ばない施策にもなる皮肉な構造

AIに最適化すればするほど人間のユーザーが公式サイトに来なくなる

最適化しなければAI経由の情報流通から取り残される可能性がある

「OSS × コンテンツ × 集客」で成り立っていた企業すべてが直面しうるジレンマ

■ 6. OSSを使う側としての対応

無料で使えるOSSが持続可能であるという前提は生成AIによって静かに壊れ始めている可能性

対応策:

仕事で使っているOSSやその周辺エコシステムには意識的にお金を払う

有料プロダクトやスポンサー制度があるなら「必要になってから」ではなく「支えるため」に選択肢に入れる

Tailwind CSSに関してはVercel社がスポンサーシップに名乗りをあげるなど複数社が支援を表明

■ 7. 今後の展望

今回の件はTailwind Labsのビジネスモデルで顕在化した問題

生成AIが「知識へのアクセス」「学習の導線」「公式情報の価値」そのものを変えた

同じ構造のOSSビジネスが今後も無事でいられる保証はない

悲観論ではなく前提条件が変わったという認識が必要

OSSを作る側も使う側もこの変化を正面から考える段階に来ている

MEMO:

これはプロダクトの運営や維持が更に少人数で可能になったという話なのでは？

(2026/01/10)

Remix v3とReactのトレードオフを徹底考察：AI時代に再評価される「Web標準」への回帰

Remix v3とReactのトレードオフを徹底考察：AI時代に再評価される「Web標準」への回帰 | レバテックラボ（レバテックLAB）

要約:

■ 1. 記事の問題提起

Webアプリケーションの開発を続けていると「いつの間にかフレームワークの学習ばかりしている」と感じたことはないか

ReactであればuseEffectの依存配列を正しく書くために時間を費やし状態管理ライブラリの選定で悩みサーバーサイドレンダリングの設定ファイルと格闘する

本来はユーザーに価値を届けるためのアプリケーション開発に集中したいはずなのにフレームワーク固有の知識やベストプラクティスの習得に多くの時間を取られてしまう

この課題はフレームワークが「厚く」なることで生まれる

多機能で便利な反面学習コストが高くWeb標準から遠ざかった独自の概念が増えていく

その結果フレームワークの外で培った知識が活かしにくくなりフレームワークのバージョンアップのたびに学び直しを強いられることになる

■ 2. AI時代における課題の深刻化

AIツールが普及した現代ではこの問題はより深刻である

ChatGPTやGitHub Copilotといったツールはシンプルで標準的なコードほど正確に理解し適切な提案をしてくれる

しかしフレームワーク固有の複雑な概念や暗黙の前提が多いコードではAIの支援が十分に機能しないことがある

■ 3. Remix v3による解決策

こうした課題に対して2025年5月28日のブログ記事「Wake up, Remix!」で予告されたRemix v3はまったく異なるアプローチを提示した

それが「薄いフレームワーク」という選択である

Remix v3はかつてReact Routerに吸収されて姿を消したRemixというブランドを復活させWeb標準へ回帰する新しいフレームワークとして生まれ変わった

■ 4. Remix v3の設計原則

Remix v3の設計はいくつかの原則に基づいている

その中核となるのが「Web標準の上に構築する(Build on Web APIs)」という原則である

バンドラーやコンパイラへの依存を避け依存関係を最小化し単一目的で置き換え可能な抽象化を提供する

これらの原則により独自の概念を増やすのではなくWeb標準のAPIを最大限活用することで学習コストを下げ長期的な保守性を高める設計が実現されている

本稿ではRemix v3の特徴を理解するためにランタイム非依存・React非依存・手動リアクティビティという3つの側面に着目する

■ 5. 薄いフレームワークの意味

Remix v3が目指す「薄いフレームワーク」とは単に機能が少ないという意味ではない

むしろフレームワーク自身が提供する独自APIを最小限に抑えWeb標準のAPIを積極的に活用することで開発者が既に持っている知識を最大限活かせる設計を指す

これはRemix v1から一貫して受け継がれてきた哲学でもある

Remix v1は「Web標準を活かす」というメッセージを掲げformタグやHTTP標準を尊重した設計で注目を集めた

しかしv1/v2はReactへの深い依存など特定の技術スタックへの結びつきが強い面もあった

Remix v3はこの哲学をさらに推し進める

■ 6. 薄いことの重要性

なぜ「薄い」ことが重要なのか

第一に学習コストが大幅に下がる

Remix v3を学ぶことはWeb標準を学ぶことと同義である

新しいフレームワーク固有の概念を覚える必要はなく既にHTMLやJavaScriptの知識があればすぐに理解できる設計になっている

第二に長期的な保守性が向上する

Web標準はW3CやWHATWGといった標準化団体によって管理され後方互換性が重視される

フレームワーク固有のAPIはバージョンアップで破壊的変更が起きるリスクがあるがWeb標準ベースの設計ならそのリスクを大幅に減らせる

第三にAIツールとの相性が良くなる

AIは標準的で明示的なコードを得意とする

フレームワーク固有の暗黙のルールや複雑な抽象化が少ないほどAIの支援が効果的になる

■ 7. 特徴1:ランタイム非依存

Remix v3の最も重要な特徴の一つが特定のJavaScriptランタイムに依存しない設計である

従来の多くのフレームワークはNode.jsを前提として設計されていたがRemix v3はWeb標準APIのみに依存することでNode.js・Deno・Bun・Cloudflare Workersなどあらゆる環境で動作する

この設計を実現する鍵がアダプターパターンの活用である

フレームワークのコアはWeb標準のRequestとResponseオブジェクトのみを扱い各ランタイム固有の処理はアダプターが担当する

この設計により開発者はランタイムの移行を容易に行える

プロジェクトの初期はNode.jsで開発し後にパフォーマンスやコストの観点からBunやCloudflare Workersに移行するといったことがコアロジックを変更せずに実現できる

■ 8. 特徴2:React非依存

Remix v1はReactに深く依存していたがv3では独自のJSXランタイム@remix-run/domを導入しReact非依存を実現した

これは単にReactを置き換えたというより「本当に必要な機能だけを残した」という選択である

React非依存によって開発者はuseStateやuseEffectといったフック機構から解放される

フックは強力だが学習コストが高く誤った使い方をするとバグの温床になる

Remix v3ではクロージャーを活用したシンプルな状態管理に置き換えられている

React非依存の利点はバンドルサイズの削減だけではない

より重要なのは「Reactのエコシステムに縛られない」という自由度である

Reactのバージョンアップによる破壊的変更やサードパーティライブラリの互換性問題から解放されフレームワーク自身が進化のペースをコントロールできるようになる

■ 9. 特徴3:手動リアクティビティ

Remix v3の最も特徴的な設計が手動リアクティビティである

ReactやVueといった現代のフレームワークは状態が変わると自動的に画面が再描画される「自動リアクティビティ」を採用している

Remix v3ではコンポーネント自身がthis.update()を呼び出すことで明示的に再描画をトリガーする

この設計にはいくつかの重要な利点がある

第一にパフォーマンスの予測可能性が向上する

自動リアクティビティでは「いつどのコンポーネントが再描画されるか」がフレームワークの内部実装に依存するが手動リアクティビティでは開発者が完全にコントロールできる

第二にデバッグがしやすくなる

画面が期待通りに更新されない場合this.update()の呼び出しを確認すればよくフレームワークの複雑な依存関係解析を理解する必要がない

第三にフック機構が不要になる

ReactのuseStateやuseEffectは自動リアクティビティを実現するための仕組みだが手動リアクティビティではクロージャーを使った素朴な状態管理で十分である

■ 10. React開発との比較

最も大きな違いは「フレームワークの学習」と「Web標準の学習」のバランスである

Reactを使った開発ではコンポーネントライフサイクル・フックのルール・状態管理のパターンなどReact固有の知識が求められる

一方Remix v3ではこれらの知識の多くが不要になり代わりにHTMLフォーム・Web標準のイベント・クロージャーといったより普遍的な知識が活きてくる

この違いは学習のハードルにも影響する

Reactを初めて学ぶ開発者にとって「なぜuseEffectの依存配列が必要なのか」「なぜ状態の更新は非同期なのか」といった疑問は理解の壁になる

しかしRemix v3なら「ボタンをクリックしたら変数を更新して画面を再描画する」という直感的な理解で十分である

■ 11. Remix v3が最適解となるケース

Web標準を重視し長期的な保守性を優先するプロジェクト

複雑な状態管理が不要でシンプルなUIを持つアプリケーション

AIツールを積極的に活用しコード生成やリファクタリングの支援を受けたいチーム

ランタイムの移行可能性を保ちたいプロジェクト

逆にReactの豊富なエコシステムを活用したい場合や既存のReactコンポーネントライブラリを使いたい場合は従来のReact開発の方が適している

Remix v3は「Reactの代替」ではなく「異なる価値観を持つ選択肢」として位置づけるべきである

重要なのは技術選定においてトレードオフを理解することである

Remix v3はフレームワークの薄さと学習コストの低さを重視する代わりにReactエコシステムの広さを手放している

■ 12. まとめと次回予告

Remix v3は独自のAPIを増やすのではなくWeb標準を最大限活用することで学習コストを下げ長期的な保守性を高める

この思想はAIツールが普及した現代においてますます重要性を増していく

次回は実際に手を動かしながらRemix v3の特徴を体験する

手動リアクティビティによる状態管理・型安全なルーティング・そしてフォーム送信の仕組みを実装を通じて理解していく

(2026/01/09)

「そもそも生成AIでやるべきでない問い」に、企業が挑んでしまう問題

「そもそも生成AIでやるべきでない問い」に、企業が挑んでしまう問題｜深津貴之 (fladdict)

要約:

■ 1. 問題提起

わりと複数の企業のお悩みが「そもそも生成AIでやるべきでない問い」にチャレンジして疲弊している

大企業が生成AIを導入してうまくいかないケースの多くはツールの性能不足というより業務設計がズレている印象がある

もう少し正確に言うと「AIが苦手な問い」をそのまま投げている

当然苦戦している

■ 2. AIが苦手な仕事の特徴1:完璧性を要求する仕事

生成AIは確率分布で未来を予測したり答えを予測するマシーンである

つまり「確率的に間違えが発生する」ことは仕様の一部である

そもそも100%の正しさを前提とする業務は苦手である

正解が一意で厳密な業務(数式の厳密計算・機械語や厳密仕様のコード生成など1文字違いで壊れる領域)

誤りのコストが致命的な業務(医療・法務・安全領域の最終判断・断定的なファクトチェック)

見た目の細部が品質を決める業務(複雑な手指・ポーズなど局所の破綻がそのまま品質事故になる制作)

この場合AIがイケてないのではなく我々がAIにあたえる業務設計が間違っている

「細部の品質が100%でなくてもいいから成果がでる」や「成功率100%を要求されない」をみつけてAIに与えることが大事である

■ 3. AIが苦手な仕事の特徴2:長く連鎖する仕事

もうひとつの落とし穴がこれである

例えば精度90%の仕事を10回連続成功する確率は34%である

つまり操作ステップが長すぎて全てのステップで成功しないといけない問題も相性が悪い

要は各ステップの成功確率が高くても鎖の長さが増えれば落ちる

「単発なら正確」なのに「沢山連結すると精度がでない」という問題である

なのでAIに仕事を渡すなら「短い単位の仕事」で「途中で人間が介入できる」構造にしておく

冷蔵庫をあけ食材をとりだしカットして火をいれて調味料で味をととのえるようなロボットは非推奨である

レトルト食品をレンチンしてくれるロボを作りましょう

■ 4. AIが得意な仕事:全体感が正しければうまくいく仕事

逆に生成AIが得意なのは「全体感が正しければ成果になる仕事」である

適切な情報が渡されているならば多くの場合うまくいく

例えばイベントの進行案(台本たたき台・タイムテーブル案・想定Q&A・盛り上げポイント・リスク分岐など)

企画提案書へのフィードバック(論点漏れ・反論想定・構成・比較軸・刺さる言い回しの案出)

金融商品のポートフォリオの運用原則の策定

共通点は「厳密さ」より「筋の良さ」「網羅性」「比較軸」「言い回し」「観点」が価値になるところである

つまり確率的なブレを下流のエクスキューションで吸収できる領域である

■ 5. AIで正確性を出せる分野:大数の法則が効く仕事

ここまで「AIは完璧性が苦手」と書いたが逆にAI単体でも運用しだいで正確性を出せる分野もある

ポイントはシンプルで「大数の法則」や「平均回帰」が効くタイプの仕事である

つまり一発勝負じゃなくて試行回数を増やすほどブレが相殺されて平均が安定していく領域である

「1回の正解」ではなく「1000回の平均」が正解になる仕事である

たとえばマトを鉄砲で撃つ作業をイメージする

1発だけだと確率的に外れることがあるが1000発撃ったらどうか

1000発の平均の着弾点を測定したら1000発撃った平均値は実質的にマトの中心に寄っていく

これがAIで正確性を作れるパターンである

具体例として要約の精度を「集合知」で上げる・文章の改善(推敲)を反復で収束させる・分類タグ付け優先順位付けみたいな集計系・A/Bテストや広告文案など統計で勝ちが決まる領域がある

■ 6. AIに精度を持たせる方法:治具(ジグ)の活用

それでもどうしてもAIで精度がほしいなら人間がまっすぐの直線を引くときに定規をつかったり円を完璧にかくときにコンパスが必要である

こういった道具を治具(ジグ)という

どうしてもAIに精度100%を目指す仕事をさせたい場合は同様にAIのための定規・分度器となるようなツールをつくりそれをAIに操作させる

計算が苦手ならPythonや計算機をコールさせるようにする

完璧な時系列情報の列挙なら資料から引っ張ってくる

このように厳密でなければならないこと(数字計算やファクト)はAIから100%正確さが保証できる機械にアウトソースする

AIが担当するのは「ここで計算が必要かどうか」というより曖昧性の高い問にシフトさせることで問題を解決できる

AIに正確に答えさせるのではなくAIに正確な道具を使わせるこれが現実的な解法である

■ 7. AIと人間の役割分担

「AIが考えて人間が完璧に執行する」のほうがたいていうまくいく

イラストでいうならば「AIがテーマを決め必要な構成要素の素案を出しプロがしっかり描く」ほうが「プロがテーマを決め必要な構成要素の素案を出しAIがしっかり描く」よりも品質がよくなる

そういうことを考えると「経営者が考えてAIが完璧に執行する」よりも「AIが経営を考えて人間が道具を使って完璧に執行する」ほうが多くの場合うまくいく

経営判断は「全体感」が求められ執行は「細部の完璧性」が求められるからである

あるいは経営は「確率論」が大事な処理であり執行は「決定論」が要求されるからである

■ 8. 皮肉な結論

つまり生成AIの特性を考えると皮肉にも「数字だけを見て現場をコストカットしようとする経営者」が「最もAIで代替しやすい人材」で「最も費用対効果がよい」DX施策となる

我々マネジメント層のほうがあとがない

AIに最初にリプレイスされないためにも経営者もマネージャーも現場やユーザーともっとふれあって業務ドメインの解像度を高めていく

手を動かす人は思ってるより重要である

リストラとかを考えてる場合じゃない

■ 9. まとめ

まずは業務フローをできる限りシンプルに

正確性が必要なところには正規表現やプログラムなど生成AIでない仕組みを

そもそも正確性に依存しない業務で自社をドライブするにはという問いにコミットする

わりと今の現場で起きている「AI導入したけどつかえない」系の議論の大半はこれで説明できるのではないか

過渡期の生みの苦しみだと思うがみんながぶつかる課題なのでナレッジシェアできるといい

(2026/01/09)

Next.jsを採用するのをやめた理由・背景

Next.jsを採用するのをやめた理由・背景

要約:

■ 1. 記事の背景と概要

anatooによる2026年1月8日公開の記事である

少し前にReact2ShellというReactのRCEの脆弱性によってNext.jsを使っているアプリケーションが影響を受けた

実はそれ以前から自分は何かウェブアプリケーションを開発するときにNext.jsを採用するのをやめている

Next.jsを採用するのをやめたのにはちょっと微妙な理由がいくつかあったので特に何か書く事はしなかった

興味ある人もいるかもしれないので書いておこうと思う

簡単に書くと以下の三つの事柄があってNext.jsを採用するのをやめた

■ 2. 理由1:ViteやVite系のフレームワークの方がDXがよかった

技術的な理由では一番これが大きかった

ViteやVite系のフレームワークとNext.jsを比べるとViteの方がDXが明らかに優れているなという印象があった

Viteの場合は開発時はネイティブESMを使って高速に開発サーバを立ち上げられるのに対してNext.jsはコード変更するたびにバンドルしなおしている

プロジェクトのコードの量が多くなるとVite系のフレームワークを使った方が明らかにDXが良いし開発効率も良いと結論づけた

Viteは既存のプロジェクト内で間接的に導入している事も多い

テストライブラリに関してもJestだとESMサポートが薄いので代わりにテスト系のライブラリは内部でViteを使っているVitestをすでに導入している事が多かった

Viteにはすでに親近感があった

当時はRemixがViteをサポートし始めたのでもしかしてNext.jsも将来的にViteに乗っかるという可能性もあるんではないかと思った

調べた所どうやらそれは無さそうだというのもある

■ 3. 理由2:Guillermo Rauchの倫理観が心配になった

Next.jsのオリジナルの作者はVercelのCEOでもあるGuillermo Rauchである

ある時この方のXの発言を見て自分がそれに引いてしまったというのがある

このツイートは普通に批判されまくっている

興味ある方は調べてみてください

■ 4. 理由3:RSCのコトがよく理解できなかったし好みから外れていた

これは言うのが微妙に憚られる消極的な事柄になる

Next.jsがReactのRSC(React Server Component)やServer Actionを非常に早い時期にサポートしはじめたころに詳細を理解しようと思って調べていたりした

概念レベルの話はわかったんだが技術的な詳細はあまりよくわからなかった

React2Shellが発覚した後になってRSC Explorerというどういうペイロードがサーバに飛ぶのかを細かく教えてくれるツールが公開されたりもした

しかしNext.jsがRSCをサポートし始めた頃はなかった

ReactチームはRSCで使われるFlightプロトコルに関する技術的な詳細をドキュメントにあまり公開していなかったように思う

またRSCやServer Actionsを導入するときに使われるバンドラ周りの処理が魔術的に見えて自分の好みから外れていたので「なんかやだな〜」ぐらいの感覚があったという背景もある

ただこれは採用するのをやめた理由というよりかはRSCやServer Actionsにあまり魅力を感じなかったのでそれをサポートしているNext.jsを採用しなくても別にいいやという気分になった背景になる

■ 5. 結論と代替案

Next.jsを採用するのをやめた背景は以上になる

じゃあNext.jsの代わりに何を使うのかというととりあえず今のところは普通のSPAならVite+Reactを使う

SSRが必要な場合はReact Routerを使うことにしている

これ以外にも2026年はReactを捨てたRemix3も出るのでその辺りの動きも気になる

MEMO:

要するに親イスラエルであることを隠しもしないからドン引きだったと

(2026/01/09)

IT開発者向けの質疑応答（QA）サイト「Stack Overflow」で投稿数が激減、ユーザー戦慄

IT開発者向けの質疑応答（QA）サイト「Stack Overflow」で投稿数が激減、ユーザー戦慄 - やじうまの杜 - 窓の杜

IT開発者向けの質疑応答（QA）サイトとして有名な「Stack Overflow」で、投稿数が激減しているとのこと。

「X」（Twitter）に投稿されたグラフによると、最盛期に20万件を超えていた月間投稿数が、最近では5,000件以下にまで落ち込んでいます（グラフは運営元のStack Exchangeが提供しているデータエクスプローラーで出力できます）。

「X」のこのスレッドでは多くのユーザーがAIの影響を指摘しており、実際その通りでしょう。「Stack Overflow」に聞くよりも「GitHub Copilot」に聞いた方がずっと早く答えが得られるだけでなく、具体的なコードまで示してくれます。

しかし、それだけでは2014年をピークに「Stack Overflow」の勢いが少しずつ衰えている理由の説明にはなりません。

当該スレッドには、初心者に厳しい、重複する質問が多すぎる、うかつなことを言うと叱責や罵倒が飛んでくる（いわゆる「マサカリ」）といった「Stack Overflow」コミュニティの文化を批判する声も多く寄せられており、それも一因ではないでしょうか（AIはそんなことしませんしね！）。

また、「GitHub」の普及を指摘する声もあります。「GitHub」でホストされているアプリやライブラリに関する疑問であれば、そのリポジトリのイシューで議論した方が有用な答えが得られるでしょう。

でも、AIが「Stack Overflow」などのQAサイトを出典として引用することだって少なくありません。「Stack Overflow」が滅びたあと、AIはどこから知識を仕入れるのでしょうか。ちょっと心配になってしまいました。

MEMO:

まぁ、そうなるやろという予測はされてた

(2026/01/09)

「とほほのWWW入門」作者・杜甫々さん “10年先を見据えた”プロジェクト管理術を語る

「とほほのWWW入門」作者・杜甫々さん “10年先を見据えた”プロジェクト管理術を語る (1/2)

要約:

■ 1. 登壇者の背景

Webに関する技術サイト「とほほのWWW入門」を30年間ひとりで運営してきた杜甫々さんによるセッションである

同サイトは個人活動だが本職であるソフトウェア開発でも複数の長期プロジェクトに携わってきた

Backlogのユーザーグループ・JBUGは2025年11月29日にプロジェクトマネジメントの祭典「Backlog World 2025」を開催した

杜甫々さんの招待セッションでは彼がソフトウェア会社で実践してきたプロジェクト管理における数々の工夫が披露された

■ 2. とほほのWWW入門と杜甫々さんの経歴

1996年に開設された「とほほのWWW入門」はプログラミング言語やフレームワークなどWeb技術の入門情報を網羅的に発信し続けている

最近では陶磁器や洋楽・中国語・韓国語・タイ料理にまでコンテンツを広げている

2025年は尻を叩かれてAIの記事も載せている

インターネット黎明期には同サイトでHTMLコーディングやCGIプログラミングを学んだ古参の読者も多い

杜甫々さんもインターネット歴38年でありインターネット老人会の会長を目指している

杜甫々はハンドルネームで本名ではない

大学卒業後1988年にメーカー系ソフトウェア会社に入社した

入社後はさっそくUNIXにTCP/IPを移植するプロジェクトに参加した

その後ネットワーク管理システム(1990年から現在)・セキュリティ管理システム(2002年から現在)・クラウド管理システム(2013年から現在)と今なお続く長期プロジェクトの数々に携わってきた

会社自体は2025年10月に定年退職を迎えたばかりである

■ 3. 長期プロジェクトの課題

プロジェクトが長期化すると仕様書だけでも1000枚を越えメンバーの入れ替わりで知識の断絶も発生する

杜甫々さんは「得意分野ではない」「細かで古い話」との前置きの上でプロジェクト管理で実践してきた工夫を披露した

■ 4. フォルダ構成の工夫:10年フォルダ

まずは「フォルダ構成」における工夫である

長期プロジェクトではファイルのバージョンアップ(v1.1・v1.2)やバグフィックス(v1.1.1・v1.1.2)を重ねるうちに「どこに何があるかわからなくなる」問題が発生する

そこで杜甫々さんが推進してきたのが10年経っても乱れない「10年フォルダ」と呼ぶフォルダ構成である

具体的には「バージョンに依存するファイル群」と「依存しないファイル群」を完全に分離させるのがポイントである

例えば「v3.2」に関連する仕様書はバージョン依存ファイルを管理するフォルダにあるv3.2フォルダ直下にのみ保存する

そして最新の仕様書はバージョンに依存しないファイルとして別フォルダで管理する

これを徹底することで新メンバーでも目当てのファイルにすぐに辿り着ける

ただしこの運用ではバージョン依存と非依存の両方の仕様書を書く必要がある

それに対し「v3.2の仕様書では2行ほどしか記載せず詳細は最新仕様書にリンクで飛ばし同じことを複数の仕様書で書かないようにしていた」

さらに「リリースが終わればバージョン依存のフォルダは捨てるくらいの気持ち」で運用するのがよい

結局のところ重要なのは「最新の仕様」であり10年後に保守しているメンバーは古いバージョンの仕様など読まないからである

細かな工夫としては大本のフォルダ名に2桁の固有数字を付与している

マウス嫌い派である杜甫々さんはこの数字を利用してキーボードのみでエクスプローラーを移動していた

■ 5. 仕様書作成の工夫

続いては「仕様書作成」における工夫である

長期プロジェクトでありがちなのが仕様書間の不整合である

開発途中で仕様変更があった場合詳細仕様書から基本仕様書・概要仕様書へと遡り影響範囲に応じて変更内容を反映する必要がある

ただみんなめんどくさがったり忘れたりして結局は不整合が生じていた

そこで概要・基本・詳細のフェーズごとの仕様書をひとつのファイルにまとめた

一続きの仕様書にして修正の手間を減らすと不整合はなくなった

また文書番号体系(名づけ)もプロジェクト+文書の種類(設計仕様書はS・テスト仕様書はT・手順書はMなど)+連番というシンプルなルールで統一して検索やリンクをしやすくしたのもポイントである

年度やモジュールなどは採番台帳で把握できる

■ 6. Excel方眼紙による進捗管理

一部のプロジェクトで運用していたExcel方眼紙製の仕様書も紹介された

冒頭の列(A~F)で「作成」「査閲」「承認」「開発」「実装」「評価」のどこまで済んでいるかをチェックして行単位で進捗を把握できる仕組みである

加えてコメントはExcelに直接記入し★をつけることで残課題を集計する

こうした運用で仕様変更が漏れなく開発メンバーに伝わり仕様書の一行一行で管理できる

■ 7. テストファーストな記述

もうひとつ意識していたのが「設計仕様書は評価仕様書でもある」という考え方である

文章の末尾に「~か」をつけると評価仕様書になるようなテストファーストな記述を徹底した

例えば「タイムゾーンはアルファベット昇順でソートして表示する」という仕様はそのまま「タイムゾーンはアルファベット昇順でソートして表示するか」というテスト項目になる

そして設計仕様書のシート半分は実際に評価仕様書として運用し各行がテストされているかを把握しやすくしている

なお杜甫々さんがプロジェクト立ち上げ時に最初に行っていたのが「型定義」である

改行や制御文字・負数・サロゲートペア領域などを許容するかを予め定義して画面からAPI・デザイン設計に至るまで統一していた

■ 8. 開発ガイドラインによるナレッジ伝承

最後に触れられたのが「開発ガイドライン」である

この開発ガイドラインとはプロジェクトをまたがり蓄積してきたナレッジをひとつのファイルに集約したものである

「障害があって解決してなぜ3分析(なぜを繰り返す問題解決手法)をする喉元を過ぎれば忘れてしまうので開発ガイドラインに追加して10年先のメンバーにもノウハウを伝える」

その項目数は500を超え「管理」「設計」「開発」「評価」「出荷」などのフェーズごとに整理されている

さらに新規追加の項目にはメンバー向けのチェック欄を設け理解されているかを確認できるよう工夫している

■ 9. プログラミングスキルの見える化

プログラミングスキルの見える化にも取り組んでいた

それは「Linuxのcatコマンドの互換コマンドmycatをC言語で作成してください」と投げかけるという内容である

これだけのお題だが完璧に作れる人は少ない

異常時の終了ステータスが0以外になっているか・close()のエラーを確認しているかなど色々なチェック項目を設けていた

こうしたチェックリストを基に新メンバーのコーディングスキルを客観的に数値化する

チェックリストはそのまま教育にも用いる

ただしこの見える化を含む施策は「今では生成AIでも出来てしまう」と振り返った

■ 10. 結論

ここまで紹介された工夫はあくまで一部にすぎない

年間で60個ほどの改善策を手掛けた時期もあった

杜甫々さんは「大事なのはこうした改善策を整理して他のプロジェクトと共有していくこと」と述べた

「そして次のメンバー・次の次のメンバーへと伝承させていくことだこれはAIでもできない人間が担っていくべきもの」と締めくくった

(2026/01/08)

レビューしてもらう/する場合に意識すること、やり方を考える

レビューしてもらう/する場合に意識すること、やり方を考える｜Koshi Kagawa

(2026/01/07)

ドキュメントレビューをする際の10のポイント

ドキュメントレビューをする際の10のポイント | Ryuzee.com

1. 体裁をレビューするのではなく、中身をレビューする

2. 標準化ではなく、顧客や案件ごとに最適化できるような自由度をチームに与える

3. レビューの目的を明確にする

4. 大がかりなレビューを少ない回数実施するのではなく、こまめな小規模レビューを繰り返す

5. レビューでの指摘事項をすべて対応しなければならないとは限らない。チームにとって労力をかけるだけのメリットがあるものから優先順位付けをして実施する

6. レビューで人格を非難しない

7. レビューの順番もレビュー効果が高いものから実施すること

8. 機械的に検証可能なドキュメントのレビューは自動化すること

9. レビューワーも技術もしくは顧客の業務をしっていること

10. レビュー結果はチーム内外含めて共有すること

(2026/01/07)

育てるほど楽になる AI 開発体制を作っている話

育てるほど楽になる AI 開発体制を作っている話 | BLOG - DeNA Engineering

(2026/01/07)

ただNext.jsを使う

ただNext.jsを使う - カミナシエンジニアブログ

要約:

■ 1. 記事の背景と目的

カミナシエンジニアのosuzuによる技術記事である

職能柄Webフロントエンド技術の選定に関わる機会が多くReact Server ComponentやNext.jsに関する発信を過去にしていた

2025年12月のReactやNext.jsのセキュリティ問題に対し心痛めている

現在もプロダクションでNext.jsを運用しているが選定した事を後悔しているかというとそう単純な話でもない

あらためてNext.jsをプロダクションで採用するポイントや何を意識した構成にしているか記載する

以降ReactはRSC(React Server Components)を含むものとしNext.jsは記載のない限りApp Routerを指した話となる

■ 2. BFFとしての使用方針

プロダクション運用するプロダクトに対してフルスタックフレームワークやバックエンドを兼ねる形でNext.jsを採用する事はない

必ずBFFとして使う

主にSaaSのような認証認可が必要かつマルチプロダクト展開や他SaaS連携などで複数のAPIに依存しやすい構成を例に説明する

■ 3. BFFの構成設計

推奨する「Next.jsをBFFとして使う」構成は物理的にも論理的にもバックエンドAPIと明確に分離された状態を指す

Next.jsはデータベースへの接続情報を一切持たずビジネスロジックも記述しない

あくまで「UIのためのデータ整形」「APIアグリゲーション」「API認可プロキシ」に徹する

■ 4. セキュリティ設計思想

Next.jsサーバー(Node.js/Edge Runtime)を「信頼できるサーバー(Trusted)」とは見なさず「ブラウザが少し権限を持った延長線上の環境(Untrusted)」として扱う

「ブラウザのDevToolsで見えて困るロジックや変数はNext.jsのサーバーサイドにも置かない」という極端な意識で設計する

DBのパスワードやAWSのシークレットキーを環境変数として渡すことはない

万が一RSCの境界設定ミスでコードが流出したりインジェクション攻撃を受けたとしても攻撃者が手に入れられるのは「画面構築のためのロジック」だけであり系統全体を掌握されるリスクを構造的に低減する

■ 5. インフラ権限の最小化

BFFが実行されるコンテナや関数自体の権限(IAM Role等)は最小限に絞る

AWS上で運用する場合Next.jsの実行ロールに対してdynamodb:FullAccessは与えずにdynamodb:GetItemやdynamodb:PutItemなど権限を最小限にする

認証認可のフローにおいてもNext.jsはあくまでトークンの「運搬役」に徹する

Next.js上でJWTを発行するといった構成は取らない

■ 6. 認証認可の責務分離

カミナシが運用するプロダクトではバックエンドAPIはOAuthのクライアントでトークンイントロスペクションのリクエストするだけという構成を取っている

Next.jsはCookieからトークンを取り出しAPIへ転送するだけでありバックエンドAPI側がそのトークンを検証するリクエスト結果を元に認可する

この徹底した責務の分離によりBFF層がセキュリティに対して権限やリスク集中することを防いでいる

すべてのバックエンドAPIが同じセッションストアを共有する構成などではBFFでトークンを取得せずcookieをproxyするだけで扱って良いかもしれない

■ 7. BFFの必要性の議論

「そこまで制約を課すならSPA + APIで良いのではないか」という議論がある

SaaSやtoBのプロダクトではSPA(Client Side Rendering)にすべきという意見もよく目にする

「SSRからSPAにしたとしてSaaSのようなプロダクトではボトルネックは移動しない」「静的なファイルとして配信した方がインフラコストが安いまたバンドルしたファイルもユーザーのブラウザでキャッシュ可能」など

上記にも賛同するし前職でそう構築した経験もある

残念ながら何事にもトレードオフがあるため主にBFFを置くこと自体のメリットを記載する

■ 8. BFFを置くメリット

メリットは「認可の橋渡し(Token Handler)」と「APIアクセスの集約」にある

現代のバックエンド(特にマイクロサービス構成)はステートレスなBearer Tokenを要求することが一般的である

SPA単体でこれを実現しようとするとJSでトークンを扱う(XSSリスク)かバックエンド側すべてにCookie認証を対応させる(実装コスト増・CORS問題)必要がある

BFFを挟むことで「ブラウザとはCookie(セッション)で通信しバックエンドとはTokenで通信する」という構成が素直に取りやすい

Token Handlerのためにサイドカーや軽量プロキシを扱うことも可能ではある

APIアクセスの集約(APIアグリゲーション)に関してはコード的な問題だけでなくAPIが同一VPCのinternalなリクエストで通信出来たりAPIとBFFを同じリージョンにまとめたりとネットワークの効率が優れている

Reactチームはブラウザから大量の遅いリクエストが飛んでしまう問題をBoomer Fetchingとして問題視している

■ 9. RSCのBFFとしての優位性

BFFの中であえてNext.jsを選ぶ理由はRSCがもたらす開発体験とBFFとしての適性にある

RSCを「宣言的なBFF」として捉えると非常に優秀である

従来BFF層でAPIを叩くためにはExpressを使ったりGraphQLを使うなどの詰め替え業が必要だった

RSCであればコンポーネントツリーの中で直接非同期データを取得しそれをPropsとして流し込むだけで済む

データの取得とUIの構造がコロケーション(同居)されかつ型安全にバックエンドAPIのレスポンスをクライアントコンポーネントへ渡せる

RSCによってReactを同期的に書くことができて非同期で発生する難しさをいくつも解消してくれる

■ 10. Next.jsの課題点

発明を捨てフルスタックフレームワークとしての道を失った

Next.jsはApp Router以降フルスタックフレームワークとしての道を失ったと思っている

Page RouterまではServerからClientへのPropsの境界が明確で(いわゆるgetServerSidePropsで境界が分かれてた)貧者の選択としてNext.jsでサーバーを実装する選択も取り得た

今回のCVE以降は特にそうした構成を取る事は明確に難しくなる

■ 11. 代替フレームワークの出現

Tanstack Startというフレームワークが対抗として出現している

UIライブラリがReactに依存していなかったり(これはTanstack系は共通の思想)Reactに非依存な層を増やしたい人には嬉しい

サーバー/クライアントの境界を明確に区別しようという思想もありこうしたコンセプトもNext.jsより共感する人が多いと思う

紹介したTanstack Routerも他に有力なReact Routerも将来的にRSCを取り入れていく方針である

今の上記フレームワークのシンプルさはRSCに対応してないゆえでもあり今後どの程度混乱が生じるかは分からない

それならいっそReact以外という道を考える人もいるかもしれない

採用市場やフレームワーク自体の完成度を見るに難しい選択にはなると思う

■ 12. 技術選定に対する考え方

今フロントエンドでフレームワークやライブラリを選定することは考慮すべきポイントが多くて難しい時代だと思う

きっと色んな言葉が気になってしまうエンジニアも多いと思う

近年大切にしてるテーマの一つに「どうでもいいことは流行に従い重大なことは標準に従いドメインのことは自ら設計する」という言葉がある

カミナシという組織でSaaSを開発しているがカミナシには「現場ドリブン」というドメインに時間を使おうという概念そのままのバリューが存在する

2025年だけでCS活動やプロダクトディスカバリや商談同席など現場に10件以上訪問して課題に向き合ってきた

エンジニアとしての時間をドメインを考えることに対して使っていきたいという想いが年々強まっている

技術選定の正解探しに時間を溶かすのではなく選んだ技術を正解にするためのオーナーシップと何よりユーザーへの価値提供を大切にしていきたい

(2026/01/07)

Z世代に多い「褒められると伸びるタイプです」と自分で言ってしまう人には、マネジメント上かなり...

Z世代に多い「褒められると伸びるタイプです」と自分で言ってしまう人には、マネジメント上かなり注意したほうがいい。もちろん、承認が動機づけになる人は多いし、褒めること自体は悪じゃない。問題は、その言葉が単なる自己理解ではなく、責任の所在のすり替えとして使われること。本人は無邪気に言っているようで、実はその一言の中に「成長にとって致命的な壁」がある。

自分が成長できるかどうかは相手がどう接するかで決まる。言い換えると、自分は変わらずに環境や他人を変えようとしている。これは成長の方向とは真逆のマインドセット。成長のアクセルを他人の手に渡している状態。

厄介なのは、このタイプは褒めを「免罪符」や「取引条件」として使うことがある点。「褒めてくれないなら、成長できなくても仕方ない」という責任回避。承認がなくなった瞬間にエンジンが止まる。もっと悪いと、承認がない状態を「不当な扱い」と感じて不満や被害者意識へと変換する。

この構造の裏側には、心理的な防衛がある。過剰なプライド、あるいは自尊心の脆さ。自尊心が不安定な人ほど外部からの承認に依存しやすい。褒められると嬉しいのではなく、褒められないと崩れる。ここが根っこだと、指摘を受け入れる器が小さくなる。なぜなら指摘は、本人の中では改善提案ではなく自分の価値への攻撃として処理するから。自己評価が脅かされると人は合理性より防衛に走る。反論する、言い訳する、話を逸らす、黙る、落ち込む、拗ねる。表面的には反省して見せるけど内面では反省していない。この現象は珍しくない。

ここで重要なのは「反省の言葉」と「反省の中身」は別物だということ。とりあえず謝る、とりあえず「すみません」と言う、とりあえず「気をつけます」と言う。これを繰り返すと、本人の中で反省っぽいことを言えばその場を切り抜けられるという学習が成立し、負の成功体験が生まれる。反省の言葉を言うことで、叱責や不快から逃げられる。それが報酬になってしまう。結果、行動は変わらない。本人が悪意を持っているわけではなく、学習の結果として「反省の言葉」だけが巧妙になる。言葉は良いのに成長がない。謝るのに同じミスを繰り返す。こういう人を放置してはいけない。

では、どうマネジメントするべきか。このタイプの人を伸ばすには、まず「褒められると伸びる」という自己定義が、成長とは逆向きになることを本人に理解させないといけない。そのうえで「すごい」「偉い」みたいな人格承認ではなく「何をどうやったか」という行動承認に寄せる。努力やプロセスを承認すると成長マインドセットが育ちやすい。再現性のある行動を承認することで「気分の報酬」ではなく「行動の強化」につなげる。

次に、成長とはフィードバックによって行動の引き出しを増やすことだと繰り返し教え、認知の再構成をさせる。本人の中で「指摘＝攻撃」から「指摘＝武器が増える」に変換できたら受け取り方が変わる。

そして、反省の言葉ではなく次の行動でしか評価しないこと。「すみませんでした」では終わらせず「次に何を変える？」「明日から何をやめる？」「同じ状況で、次はどう動く？」まで必ず言語化させる。さらに「いつ確認するか」まで決める。曖昧な反省は変化を生まない。具体の行動だけが変化を生む。この運用を続けると「反省っぽいことを言って逃げる」学習が崩れていく。本人は最初しんどい。なぜならこれまでの防衛が通用しないから。でも、ここで初めて本当の成長が始まる。

「褒められると伸びるタイプ」という自己申告が危険なのは、褒めが必要だからではなく、成長の責任を外に置いてしまいやすいから。成長する人は褒められなくても伸びる。褒められたら加速する、くらいの位置づけにしている。伸びない人は、褒められないと止まる。そして止まった理由を環境のせいにする。この差は能力の差ではなくマインドセットの差。マネージャーの仕事は、そのマインドセットを本人に与え、成長の責任を本人に戻し、承認を依存ではなく強化として使い、反省を言葉ではなく行動に変える設計を作ること。

このプロセスを踏めるようになると、外部承認に依存する人、自尊心が脆い人、プライドが高い人、反省の言葉が上手い人など、マネジメント難易度が比較的高い部下をマネジメントできるようになる。

@masanydayo

(2026/01/06)

プログラミングみたいに音楽を作れる「Strudel」

(2026/01/06)

新卒エンジニアで「1日3~4時間だけ集中してコードを書いて、残り時間は Slack を徘徊する」みたいな...

新卒エンジニアで「1日3~4時間だけ集中してコードを書いて、残り時間は Slack を徘徊する」みたいなゆるい働き方を覚えてしまってからそこから抜け出すのにかなり苦労したし、抜け出せない人は一定数いる

@uiu______

MEMO:

それが定年まで続くならそれでもいいんだろうけどね

(2026/01/06)

Claude Codeで記憶領域を持つための独自のAgent Skillsを使っている

Claude Codeで記憶領域を持つための独自のAgent Skillsを使っている

MEMO:

自分の場合は設計や実装方針は原則Markdownのファイルに出力させていて、コンテキストをあまり使わないようにしている
ファイルに出力すれば確認・修正も楽だし、コンテキストをクリアしてClaude Code自身にレビューさせることもできる

(2026/01/05)

PublickeyのIT業界予想2026。メモリ高騰による消極的なクラウド選択、AIエージェントを前提とした開発...

PublickeyのIT業界予想2026。メモリ高騰による消極的なクラウド選択、AIエージェントを前提とした開発方法論、Rust採用の広がりなど－ Publickey

要約:

■ 1. 記事の概要と2025年の振り返り

2026年1月5日に公開されたPublickeyによるIT業界予想である

2025年を振り返ると生成AIに始まり生成AIに終わると言っても良いほど話題の中心のほとんどに生成AIがあった年だった

2026年も生成AIが注目されることは間違いないがその位置づけは2025年とはまた少し違ったものになる

生成AI以外にもIT業界には注目すべき動向がいくつも存在する

■ 2. 国際情勢とIT業界への影響

2025年1月に米国大統領にドナルド・トランプ氏が就任したことはこの1年で最も大きな影響を世界の政治や経済に与えた出来事だった

トランプ大統領が就任直後から強引に推進した相互関税はこれまで進展してきた国際自由貿易の停滞や逆転を引き起こした

コンピュータ関連の製造業を含む多数のグローバルな製造業のサプライチェーンに見直しを迫るものとなった

ロシアによるウクライナへの侵略における和平交渉での米国の姿勢がロシア寄りであるとして欧州は米国への不信感を募らせつつある

日本で高市早苗氏が首相に選ばれたことは国内の伝統的な価値感を重視するとされるいわゆる保守的な志向の高まりを反映したものと推察される

1年前のIT業界予測で「高くなる国境続く円安と人手不足」として国際的な緊張の高まりとインフレが続くだろうという認識を示したがこれは1年が経過した現在も継続している

■ 3. ITと政治の関係の可視化

トランプ大統領の就任式にはGoogleのスンダー・ピチャイCEO・Appleのティム・クックCEO・メタのマーク・ザッカーバーグCEO・Amazon.com創業者のジェフ・ベゾス氏らが巨額の寄付を行うとともに出席することが年初に大きく報道された

新たに設立されたDOGE(政府効率化省)はテスラやX/Twitterのオーナーであるイーロン・マスク氏が主導している

オラクル創業者のラリー・エリソン氏は影の大統領と呼ばれるほどトランプ大統領と近しい関係にあると報道されている

ITと政治との距離がかつてないほど近いことが可視化された一年だった

米国のみならず世界中でITは各国の安全保障に関わる重要事項となりつつあることなどからもITと政治の距離はさらに近づいていくことになりそうである

■ 4. AIへの大規模投資

2025年のAIの進化と普及そしてその将来性はIT業界のみならず株式市場などからも大きな注目を集めた

NVIDIAの時価総額は2025年7月に世界初の4兆ドル(1ドル155円換算で620兆円)を突破しアップルやマイクロソフトを抜いて時価総額世界一となった

日本企業の時価総額1位はトヨタ自動車で約53兆円日本の国家予算(一般会計)は約117兆円である

AIブームの勝者になるべくGoogleやマイクロソフト・Amazon.com・Facebook・OpenAI・オラクル・ソフトバンクなどをはじめとする多くの企業が驚くような額の資金調達やAIデータセンターへの積極投資などを発表している

2025年後半にはこれらの大規模投資は本当に将来の利益となって回収できるものなのかという疑念も一部でささやかれるようになっている

その疑念への答えがはっきりするのは数年後のことだと思われるがすでにオラクルの株価が急落するなどの動きが見え始めている

2026年の株式市場はもしかしたらそうした予測を早くも織り込むようになるのかもしれない

■ 5. メモリ価格の高騰

年末に突如始まったメモリ価格の高騰がAIデータセンターへの大規模投資が引き起こした事象として表面化した

2025年12月3日に半導体メモリの製造販売大手であるマイクロンテクノロジーがコンシューマ向けブランド「Crucial」でのメモリとSSDの販売終了を発表した

AIデータセンター向けのメモリ需要の高まりからコンシューマ向けのメモリ不足が起きそれによってメモリ価格が高騰しているとされている

価格高騰はSSDやHDDなどメモリ以外の部品にも波及している

多くの日本企業が2026年4月から始まる新年度の予算を作成している時期であり来年度のPCやサーバ・ストレージの調達計画を立てているところである

メモリだけでなくSSDやHDDもどこまで値上がりが続くのか見通しが難しい現在この価格の不透明さはいずれ企業向けのサーバなどの調達にも影響を及ぼしそうである

■ 6. 予想1:サーバ調達価格高騰による消極的なクラウド化

2025年12月末に国内の多くのBTOベンダ(マウスコンピュータ・ツクモ・ドスパラ・サイコムなど)が相次いで受注停止や値上げなどを発表した

メモリ価格の高騰が続くことを見越して早めにPCを調達しておこうと考えた消費者の増加によりBTOベンダの想定を大幅に上回る受注が発生した

メモリ価格の急上昇によるBTOベンダの仕入れ価格の急上昇などが重なったことが理由である

メモリ価格の高騰はこれから企業が従業員用のPCやオンプレミス用のサーバの調達にも影響するであろうことは十分に予想される

特に多くのメモリを搭載するサーバの調達価格の見通しは非常に不透明にならざるを得ない

予算計画を立てたとしても実際に発注してみたら予算に対して十分なサーバの台数が調達できなかったという可能性もある

一方で長期で大量のサーバ調達契約をしていると思われる大手クラウドベンダの利用料金が急に上昇する可能性は低い

新たにオンプレミス用のサーバを調達する際の価格の不透明さを嫌って安定的に調達できるであろうクラウドを選択する合理性が高まりそうである

2026年は通常のクラウド移行に加えてこうした不透明なサーバ調達価格を理由にある意味で消極的にクラウドを選択するというシステムが増加するのではないか

■ 7. 予想2:AIエージェントを前提とした開発方法論の勃興

開発チームに指示したことを文句も言わず何でも実行してくれて昼も夜も24時間365日文句も言わずにずっと働き続けることができてしかも通常の人件費よりずっと安価なメンバーを何人も採用できるとしたらそのメンバーにいつどんな作業を依頼するか

それによって既存のメンバーの役割や働き方はどう変わっていくべきか

既存の開発手法や方法論はそのままでよいのか

人間とは異なる能力と働き方とコストを備えたメンバー=AIエージェントが開発チームに迎え入れられようとしている現在これまで人間だけで構成されていることが前提であった開発方法論・メンバーの役割・働き方・コラボレーションツールなどを人間とAIエージェントの混成チームを前提としたものに最適化するべく多くの組織で試行錯誤が始まっている

それは以前GoogleがSRE(Site Reliability Engineering)として新しい運用エンジニアのあり方を提唱したりあるいはアジャイル開発のコミュニティからアジャイル開発宣言が発表されたりするようにどこかのベンダからあるいはどこかのコミュニティから提案されるのかもしれない

2026年のAIエージェントはそれ単体や連携による能力進化だけでなくAIエージェントを前提とした新たな開発方法論や手法・コラボレーションツールなどAIエージェントを取り巻く環境との組み合わせによって進化していくものになるのではないか

■ 8. 予想3:企業などへのサイバー攻撃が続く

2025年は社会的に大きな被害をもたらしたサイバー攻撃が目立つ年だった

1月には警察庁が中国の関与が疑われる日本国内へのサイバー攻撃に注意喚起を公開しおもに日本の安全保障や先端技術に係る情報窃取を目的としていると説明しサイバー攻撃は国家の安全保障と深く関わっていることを広く印象づけた

2月にはサンリオが不正アクセスを受けてサンリオピューロランドの新規の来場予約ができない事態を引き起こした

3月には楽天証券やSBI証券を始めとした複数のネット証券においてフィッシング詐欺やマルウェアなどによると見られる証券口座の乗っ取りが多数発生したことが明らかとなって数千億円規模の被害が発生した

その後多くのネット証券がこの被害を補償することを発表している

9月にはアサヒグループホールディングス10月にはアスクルが相次いでランサムウェアによるサイバー攻撃を受け製品出荷が停止する大きな被害を受けた

こうしたサイバー攻撃はAIの進化によって以前よりさらに巧妙かつ洗練されてきている一方で攻撃を受ける側の多くの組織の防御体制が十分ではないのが現状である

2026年も残念ながら国家間の緊張が高まるなかで国家が関与するサイバー攻撃が減ることは考えにくくネットにつながれたシステムの上で金銭的価値の高い情報のやり取りがますます増加する中でそれら金銭的価値の取得を目的とした攻撃も減ることはない

多くの人にとって身近な企業がサイバー攻撃を受け被害額の補償や長期の出荷停止など多額の被害を受けたことがテレビや新聞・雑誌などで広く報道された結果これをきっかけに以前より多くの企業や組織でセキュリティの議論が高まったとの声も聞く

2026年は多くの企業にとってセキュリティ体制を見直し強化する年になってほしいと願っている

■ 9. 予想4:Rustの採用が本格的に広がる

Rust言語は以前から多くのITエンジニアに注目されているプログラミング言語だった

C言語のように低レイヤのシステムの記述を得意とし不正なメモリ領域を指すポインターなどを許容しない安全なメモリ管理やマルチスレッド実行においてデータ競合を排除した高い並列性を実現している点などの特長を備えている

コンパイル型の言語として安全かつ高速なネイティブバイナリを生成してくれる

米政府は2024年に「将来のソフトウェアはメモリ安全になるべき」との声明を発表しそのためのプログラミング言語の1つとしてRustを挙げている

Rust言語はその高い注目度に対して実際の開発プロジェクトでの採用例は十分ではなかった

これはそもそもRust言語の得意分野が低レイヤのシステム開発という比較的ニッチでありしかもプログラミング言語の変更に保守的な領域であるという背景もある

2025年にRust言語の利用は広がりを見せていた

これまでLinuxのカーネル開発におけるRust言語の使用は実験的な位置付けとされていたが2025年12月に東京で行われたMaintainers SummitにおいてRustの使用はもはや実験的ではないとされ正式な採用が決定された

マイクロソフトも2030年までに自社の主要コードベースからC/C++を全面的に排除しRustへ移行する方針を明らかにしたと報道されている

AWSが2025年11月にAWS LambdaがRust言語を正式にサポートしたと発表した

RustはこれまでAWS Lambdaでよく利用されてきたNode.js/JavaScriptやJava・.NET・Pythonなどのプログラミング言語と異なりネイティブバイナリを生成するコンパイル型言語である

これによりインタプリタやJITコンパイラを用いたプログラミング言語と比較して高速な起動と実行そして実行時に必要なメモリ容量が小さくて済むなどの利点がある

サーバレスコンピューティングにおいてこれは高速な起動および省メモリなどの効率的なコンピューティングリソースの面で非常に大きなアドバンテージである

AWS Lambdaという広く使われているアプリケーションプラットフォームでRust言語を用いてアプリケーションが書けるようになったということがRust言語の活用範囲を大きく広げる

2026年はRust言語の高い注目度が採用事例へと積極的に移行していくことになるのではないかと期待を込めて予想する

(2026/01/05)

IT業界に蔓延する『ナンニデモPM』それ、本当にプロジェクトマネジメント？

IT業界に蔓延する『ナンニデモPM』それ、本当にプロジェクトマネジメント？ #プロジェクト管理 - Qiita

要約:

■ 1. 問題提起と記事の目的

IT業界におけるプロジェクトマネージャー(PM)に技術力は必要かという議論が存在する

PMには技術的判断力(技術リテラシー)が必要だが実装スキルとは異なる

現場ではPMに過度な業務範囲が求められる「ナンニデモPM」案件が存在する

本記事ではPMの役割定義、必要な技術力のレベル、ナンニデモPMの危険性、不適切な求人について建設プロジェクトの例えを用いて整理する

■ 2. ITプロジェクトと住宅建築の類似性

ITシステム構築は家づくりのプロセスに例えることができる

住宅建築における役割分担:

施主(クライアント)は要望を出し対価を払う

設計(アーキテクト)は要望を構造的に可能な形に設計し設計責任を持つ

施工管理(PM)は予算・工期・品質を管理し現場調整を行う

職人(エンジニア)は設計図に基づき実際に家を形にする

各役割が明確に分かれているのが本来の姿である

■ 3. ケーススタディ:メンバー欠員時の対応の違い

住宅建築で大工が1名欠員になった場合の施工管理の対応:

追加要員(職人)の手配

工程の組み替え(優先順位変更・段取り替え)

必要に応じて施主に事情説明し納期調整

施工管理が自ら大工作業を代行することはまず無い

IT業界でアプリエンジニアが1名欠員になった場合:

本来は追加要員調整・影響範囲見極め・スコープ優先順位納期交渉を行うべき

しかし実際はPMがエンジニアを兼務して穴埋めすることが多発する

PMが自らコーディングしてカバーすることが美徳として語られる

一度発生すると常態化し最終的に全部盛り何でも屋さんPM(ナンニデモPM)が誕生する

ナンニデモPMの状態:

本来の管理業務を捨て設計(アーキテクト)や構築(エンジニア)の穴をPMが自らの技術力と稼働時間で埋め続ける

若手のOJTまで背負い込みPMのリソースが完全にパンクする末期的状態

■ 4. PMの正しい役割定義

IPA(情報処理技術者試験のシラバス)によるPM人物像:

プロジェクトマネージャはレベル4(高度)で実装ではなくプロジェクトを成立させるためのマネジメントを扱う

立ち上げ段階では目的・成功条件・体制・制約の定義を行う

計画段階ではスコープ・スケジュール・コスト・品質・リスク・調達・コミュニケーション・ステークホルダーを扱う

実行監視段階では進捗把握・課題変更管理・意思決定・合意形成・是正を行う

終結段階では受入れ・引き継ぎ・振り返り(ナレッジ化)を実施する

PMが設計実装に深く入りすぎると論文試験の評価が落ちる

PMBOK(第8版)によるPM人物像:

プロジェクトマネジメントの標準知識体系を広い文脈で整理している

価値提供(Value Delivery)を重視する

状況に応じたテーラリング(Tailor)を行う

予測型もアジャイルも含めた複数のやり方の取捨選択を行う

PMCDフレームワークでPMの専門性を知識(ITSS相当)・実行力(成果を出す能力)・パーソナル(リーダーシップ倫理)の3次元で定義している

実作業の代行は明記されていない

■ 5. PMに求められる技術力の定義

判断できる技術力の要素:

専門家や技術者の発言を理解できる(共通言語の理解)

トレードオフを比較できる(コスト期間品質リスク拡張性など)

赤信号を検知できる(やってはいけないことがわかる)

質問ができる(何を誰に聞けば不確かさが減るかプロジェクトが前に進むかがわかる)

意思決定の前提条件を揃えられる(論点選択肢根拠影響範囲)

PMが必ずしも持つ必要がないもの:

特定言語の実装力(Javaで高速に書ける等)

特定クラウドの深い構築スキル(AWSの各種サービスの設計運用を一人で回せる等)

特定プロダクト特定領域の属人的な運用ノウハウ(細かなチューニングや手順の暗黙知までを一人で抱える等)

PMが目指すべきは「スペシャリスト」ではなく「指揮官」のような立ち位置である

■ 6. 判断できる技術力の具体的目安

IPAのITSS Level3(応用情報)の守備範囲が判断できる技術力のベースとなる

応用情報の範囲はテクノロジだけでなくマネジメントストラテジまで含むためPMが判断するための最低限の共通言語共通理解になる

テクノロジ系基礎理論コンピュータシステム分野:

アーキテクチャ概念・仮想化クラウド・OSSの基本を理解する

アーキテクト提案の実現可能性・コスト運用負荷・拡張性をトレードオフ評価できる

テクノロジ系技術要素分野:

セキュリティ・データベース・ネットワークを理解する

インシデント時の初動判断・変更時のリスク特定・非機能(性能可用性)議論の前提を揃える

テクノロジ系開発技術分野:

要件定義からテストの流れ・品質・DevOps・CI/CDを理解する

予測型アジャイルの向き不向き・品質確保の打ち手・リリース設計(ゲート自動化)の判断ができる

マネジメント系プロジェクトマネジメント分野:

工程・コスト・品質・リスク・資源・調達・変更管理を理解する

気合ではなく数値と根拠で意思決定できる(見積りバッファクリティカルパスリスク対応)

マネジメント系サービスマネジメント監査分野:

運用設計・ITILの考え方・監査内部統制の観点を理解する

作って終わりにしないためSLA運用負荷保守体制を踏まえて意思決定できる

ストラテジ系システム戦略企画分野:

目的・ROI・要求の優先順位・調達の考え方を理解する

やる理由とやらない理由を整理し投資として説明できる(優先順位スコープ調整ができる)

ストラテジ系企業活動法務分野:

契約・個人情報・知財・下請取引・コンプラを理解する

契約リスク・情報漏えいリスク・体制責任分界の事故りやすい点を早期に潰せる

■ 7. ナンニデモPMが危険な理由

PMがPMできなくなることがシンプルな危険性である

全部盛りPMが発生しやすい要因:

そもそもアーキテクトテックリード不在(または役割が曖昧)

人手不足で追加要員がすぐ手配できない

予算制約が強く「できる人がやるしかない」状態になる

兼務の前提でスケジュールが組まれている(最初から無理)

技術課題が表面化して火消しが常態化している

変更管理が弱く後半に仕様追加が雪だるま式に増える

ベンダ委託先の責任分界が曖昧で結局PMが吸収する

ドキュメント標準化が弱く属人化して引き継げない

管理が事務作業と誤解され軽視される

PMが実装側に寄った場合の弊害:

ステークホルダー調整が遅れる(意思決定が詰まる)

進捗の見える化が遅れる(気づいたら手遅れ)

リスクの早期潰しができない(後半で大爆発)

品質ゲートが機能しない(テストレビューが薄くなる)

メンバーのモチベーションが低下する可能性がある(全部PMで良くなり自分達の存在意義が不明になる)

結果としてQCDが落ち炎上しやすくなる

炎上すると社内外のエグゼクティブ層の関与が増え更に報告が増える(悪循環)

最終的にデスマーチと化する

■ 8. 小規模案件における兼務の妥当性

小さい規模の仕事なら1人が複数ロールを兼ねるのは自然である

住宅で言えばDIYでありITでも同様である

兼務が妥当なケース:

チーム内の業務効率化の小ツール(ローコードスクリプト)

小規模なRPA自動化(定型作業の削減)

既存SaaSの設定変更や軽微な連携(影響範囲が限定的)

PoC(失敗前提で学びが目的でスコープが小さい)

高いレベルの品質や厳格なスケジュールを求めない案件

このレベルならそもそもPMは不要でありリーダー担当者くらいの呼び方で充分である

DIYレベルなら兼務は問題ないが本当にDIYレベルに限られる

■ 9. 不適切なPM求人の特徴

求人票でPM募集と書かれているのに内容はPM兼テックリード兼アーキテクト兼エンジニアのような案件が存在する

求めていることを全て書くこと自体は悪くないが役割名がズレていることが問題である

ナンニデモPMの求人例の特徴:

仕事内容にQCD管理・交渉折衝に加えてアーキテクチャ策定・クラウド基盤構築・チューニング・バグ修正・コードレビュー・技術指導が含まれる

必須スキルにPMの資格経験に加えてクラウド構築経験5年以上・開発経験5年以上・IaC実装経験・大規模DB設計運用経験・育成経験が要求される

求める人物像に「自分が最後の砦である自負」「スピード感を持って自ら手を動かして解決できる」「様々な難問に立ち向かい自分事で成し遂げる」が記載される

マネジメントのプロと実装のプロを両方求めている状態は両方をプロレベルで同時進行できる人が市場にほぼ存在せず数千万円の年収が必要である

「他人に頼らず自分の稼働時間で問題を力技解決しろ」というのはマネジメントの否定でありプロジェクトだけでなくメンバーの心身も危険にさらす

健全なPM求人の特徴:

仕事内容はQCD管理・変更管理・期待値調整合意形成・技術的リスクの早期検知と意思決定・WBS策定進捗管理・課題解決に向けたリソース再配置・収益利益率管理と予算コントロールに限定される

必須スキルはプロジェクト管理手法の体系的理解と実践経験・高度専門資格保持・大規模プロジェクト完遂経験・技術的課題をビジネス的リスクやコストに翻訳できる能力・複雑な利害関係を紐解き着地点を見出すファシリテーション能力・技術の専門家を信頼し適切に仕事を任せるデリゲーションスキルが記載される

求める人物像は「個人の技術力ではなくチームの成果を最大化することに喜びを感じる」「不確実な状況下でも冷静に情報を収集し論理的な意思決定を下せる」「技術者への敬意を持ちつつ客観的な視点でプロジェクトの健全性を評価できる」が記載される

PMに求められるのは自分が手を動かして解決する力よりもチームが解決できる状態をつくる力である

メンバーを信用し適切に任せ必要な情報と判断材料を揃え合意形成と障害除去を通じて前に進める

プロジェクトは個人戦ではなくチーム戦として勝つためにPMは自分でやるよりもチームでやるを選ぶべきである

「自ら手を動かして解決できる方」という表現はPMの人物像としてミスマッチを生みやすい

自ら手を動かすことが必要な場面はあるがそこを前面に出すほどPMが本来担うべきマネジメント(QCDリスク合意形成)が後回しになり結果としてプロジェクトが不健全になる

■ 10. まとめ

PMに技術力は必要である

PMに必要な技術力は実装できる力ではなく判断できるための技術力である

目安としてIPAレベル3(応用情報)相当の知識を持つことは有効でわかりやすい指標である

役割が全部盛りになるとPMがPMできずプロジェクトが壊れやすい

兼務が必要なケースはあるがその場合は役割名と期待値を揃えた方がよい(少なくともPMだけでは違和感がある)

(2026/01/05)

2026年AIコードレビューの旅～そしてボトルネックは要件定義へ…

2026年AIコードレビューの旅～そしてボトルネックは要件定義へ…

要約:

■ 1. AIのコード生成能力の向上と人間のコードレビューの限界

現状のAIコード生成:

現状まだ酷いコードを生成することが多い

ここ1年を振り返るとAIが生成したコードからクラスを切り出してることが多かった

2026年の予測:

おそらく2026年にはだいぶ洗練されるのではないかと予想している

画像生成AIが気づいたら指6本画像を生成しなくなったように

コードレビューの物理的限界:

いよいよボトルネックになるのは人間のコードレビュー

現状でも既にコードレビュー結構しんどい

今後仮に毎日100万行のコードが生成される世界になるとすると1日8時間稼働として1時間で約12万行読まないといけなくなる

1時間に12万行って単にニュース記事を読むのでも無理

8時間ひたすらコードレビューするの自体無理

土日もコード生成され続け月曜朝には200万行のレビューが待っている

■ 2. 2026年のAIコードレビューの台頭

既存の自動化状況:

現状既に静的解析やセキュリティチェックや脆弱性診断は一定Botで可能になっている

AIのコードが洗練されるのであればそもそも設計不備や既存コードとの不整合などのコードレビューは不要になる

必要になるのは今後の拡張性やそもそもの品質チェック

参考となる既存事例:

量が多すぎて全部は見られない会計監査や製造業の品質管理が参考になる

AIコードレビューはかなりの確率でこれらの手法を輸入した形になると予想している

全数検査の放棄:

会計監査も工場検査もまず全数検査を諦めている

会計監査ではリスクが高い領域を重点監査する

工場では抜取検査やSQCが一般的

未来のコードレビュー手法:

現状のコードレビューは全行チェックが当たり前だが今後はこれら手法に収斂していく

基本的にはAIはSQC的にバグや品質を傾向分析する

リスクが高い領域のごく一部を時々人間にレビューするように指示する

そのサンプリングレビュー情報をSQCに反映する形になる

■ 3. 次のボトルネックとしての要件定義

コードレビュー後のボトルネック:

コードレビューがAIに置き換わってもボトルネックはなくならず次に移る

次に詰まるのは要件定義

要件定義の速度変化:

人間が精緻に要件定義して3ヶ月かかるところを人間が雑にAIに振ってAIが3分で要件定義するようになる

人間が要件定義に3ヶ月かけていたら市場競争に勝てないようになる

特に懸念している問題:

牛乳を1つ買ってきて卵があったら6つお願い問題

■ 4. 牛乳を1つ買ってきて卵があったら6つお願い問題

ジョークの内容:

プログラマの夫に買い物を頼む妻が牛乳を1つ買ってきて卵があったら6つお願いと頼む

すると夫が牛乳を6パック買ってきた

妻がなんで6パックも買ってきたのと聞くと夫はだって卵があったからと答える

AIの対応:

この質問を生成AIにするとちゃんと牛乳を1つと卵を6個買ってくれる

ところがこれが逆に困ったことになる

■ 5. スクラッチ開発の目的

パッケージとスクラッチの違い:

ちゃんと牛乳を1つと卵を6個買ってくれるようなシステムが欲しいのであれば業務システムであれば正直ERPなどをそのまま使えばいい

なぜわざわざスクラッチ開発をしたりあるいは原形をとどめないほどのカスタマイズをするかというと俺の考える最強のシステムや牛乳を6パック買わせるシステムを作りたいから

AIエージェントの出力傾向:

AIエージェントに雑に振ると要件は最大公約数的なや平均的なものを出力する

変な要件やこだわりの要件を盛り込もうとすると細かく書いてやるしかない

牛乳を6パック買わせようとすると牛乳を1つ買ってきてもし卵が売っていた場合は卵は買わずに牛乳を6本買ってきてと要件を伝える必要がある

詳細な要件定義の負担:

これくらいであればそこまでの負担ではないし正直本来の要件定義とはこういうものだろう

しかし今後の未来はこれを書いてる脇で雑に要件を振って爆速で堅牢なシステムが生まれるものたちとの競争が待っている

1つのこだわりが要件定義を遅らせコーディングやレビューを遅らせる

特殊要件のためAIが十分整合性を取れずバグの温床になる可能性も増す

生産性競争の帰結:

今後はこのようなこだわりや俺の考える最強のシステムを作ろうとすると生産性で負ける世界になる

要件は平準化や一般化されていく

■ 6. パッケージソフトウェアへの回帰

スクラッチ開発の必要性の喪失:

要件が平準化や一般化されていくとそもそもスクラッチ開発の必要性がなくなっていく

SAPをノンカスタマイズで使うやSalesforceをそのまま使えばいい

AIに要件定義や開発させても出てくるものは同じなのだから

ERPへの回帰:

まさかの1周回ってERPに業務を合わせるが合理的な世界になる

■ 7. ベンチャー・スタートアップの開発の行方

残る可能性の検討:

標準化された業務はERPでいいかもしれないがまだシステム化されていないベンチャーやスタートアップ領域のシステム開発は残る

そもそも要件も一般化されていないので人間が要件定義しなければならない領域はベンチャーやスタートアップに残る

実際の予測:

残念ながら以下のような流れになると予想している

ERPや既存SaaSの生産性が異常に高くなる

AI前提で最適化される

スクラッチで作るコストが相対的に高騰し経済合理性がなくなる

ベンチャー・キャピタルがベンチャーやスタートアップに投資する経済合理性がなくなる

誰も投資しなくなり結果誰もやらなくなる

結論:

だいたいの業務が既存SaaSやパッケージで足りるようになる

結果ベンチャーやスタートアップがやる意味や意義とはという問いがnode_modules級に重くなる

■ 8. まとめ

提言:

もうみんなSAPやSalesforceで働こう

(2026/01/04)