/note/tech

オープンソース・プロジェクトのたたみ方

オープンソース・プロジェクトのたたみ方

要約:

■ 1. Embulkの「メンテナンス・モード」発表

発表の経緯:

2025年10月15日、GitHubのembulk organizationに入っていたメンバーにメールを送付

Embulkというオープンソースプロジェクトの「メンテナンス・モード」への移行を提案

背景となった問題意識:

RubyGems周辺で発生したセキュリティ事件から教訓を得た

「複数の利害関係者が交わるオープンソース・プロジェクトでは、問題が起こる前にコミュニティで平和的に民主的に話し合えるうちにプロジェクトのガバナンスを実態に即して整えて形にして明示しておくべき」

特にセキュリティが重要な課題となりえて、かつ営利企業や金銭が関わる場合には重要

Embulkの現状:

著者がメンテナーとして非アクティブとなり「アクティブなメンテナーはいない」状態になって既に半年が経過

本体に近いところでは著者と佐藤さんのみが見ている状態

ときどきJDBC関係で@hito4_tさんにお声をかけて見てもらっている

embulk-output-bigqueryについては独立したメンテナーが何人かいる

■ 2. メンテナンス・モードの具体的内容

対応内容:

GitHub orgのメンバーやCore Teamを「今後もそれなりには関わり続ける気がある人」の最小限に絞る

「もう積極的にメンテナンスを続けられる状態ではない」ことを残るメンバー間で合意する

管理する対象自体（Zulipチャットなど）を減らす

Embulkそのものについて引き継ぎたいと手が挙がったときは残るメンバーで検討する

以上をもって「メンテナンス・モード」とし外部に見える形で宣言する

今後の見通し:

Embulkがアクティブにメンテナンスされることを期待しないでほしい

pull requestなどを送っていただいてもレビューもマージもされないかもしれない

Embulkはもともと無保証のApache License 2.0でライセンスされている

■ 3. organizationに残るメンバー

最終結果:

18人にメールを送付し、10人から期日内に返信があった

最終的に4人のみがGitHubのembulk organizationに残ることになった

@frsyuki（原作者）、@hito4t、@hiroyuki-sato、@dmikurube（アナウンスの書き手）

■ 4. 更新の見込み

今後の更新について:

「二度と」更新しないというつもりはない

気が向いたときには更新するかもしれないが期待はしないでほしい

ちょっとした改善や整理は入れるかもしれない

もっと先のJavaへの追随や非互換ライブラリの更新（Jackson 2から3など）のような大きな更新を入れるのは現実的ではない

引き継ぎの可能性:

引き継ぎたいという人から手が挙がれば残るメンバーで議論する

ただし実現しないだろうと個人的には思っている

昨年にはアナウンスを出していたが積極的な提案や反応はなかった

引き継ぎの難しさ:

「引き継いでくれるのなら誰でも、私たちが知らない人でも引き継ぐ」という態度は必ずしもユーザーのためにはならない

機密データの転送にもEmbulkを使っている組織がある

悪意を持つ誰かにEmbulkを引き渡してしまったら問題が起きる

悪意を持った引き継ぎの提案は拒否して単純にプロジェクトを継続しないほうがユーザーにとっても良い選択肢かもしれない

■ 5. ミドルウェアの定義と特性

ミドルウェアの特徴:

ミドルウェアを直接「使う」のは人間よりも主に誰か他の人が書いたソフトウェア・プログラム

「複数のソフトウェア・プログラムから同時に使われる・依存される」ソフトウェアという整理ができる

ライブラリとの違い:

ライブラリなら非互換を少し入れてしまっても「アプリケーション・コードのほうを直してね」で済む

ミドルウェアではそうはいかない

典型的なミドルウェアであるRDBMSがいきなりSQL文法や接続プロトコルを変えてしまったら依存関係を考慮した複雑な対応が必要になる

ミドルウェアの宿命:

依存関係グラフが深く複雑になるほど対応も複雑になる

GuavaやJacksonのような「いろいろなJavaライブラリやミドルウェアから推移的に依存され互換性問題で悲鳴が上がるようになってしまったライブラリ」はミドルウェア的な宿命を背負わされて「ミドルウェア化」してしまった哀しきライブラリと見ることもできる

多様なプラグインから依存され、そのプラグインとEmbulkを組み合わせて使う多様なユーザーがいたEmbulkは正しく「ミドルウェア」だった

■ 6. オープンソースとメンテナンス

メンテナンスの長期性:

あるソフトウェアがミドルウェアであることと「長期間メンテナンスされ続けてきた」ことはほぼ不可分

あるソフトウェアが他のソフトウェアから依存され互換性を気にされることはそのソフトウェアがそれなりに長期間メンテナンスされ信頼されてきた証

オープンソースの現状:

近年では使われるミドルウェアの多くをオープンソースが占めるようになった

この十年強の間に新しく生まれたミドルウェアは企業のsource-availableソフトウェアを除けば大部分がオープンソース

大規模なミドルウェアをメンテナンスする苦悩にはオープンソース・プロジェクト運営の苦悩も同時につきまとうようになった

Honoの例:

YAPC::Fukuoka 2025でHonoのYusuke Wadaさんが「OSS開発者の憂鬱」というトークをされた

「クリエイターからメンテナーへ」「作っていればよかったのが保守しなくてはいけなくなる」「Noを言うには体力がいる」「政治に巻き込まれる」

■ 7. Linux開発者の見解

Linus TorvaldsとDirk Hohndel氏の発言:

「メンテナーの疲労と、その仕事がいかに消耗させられる、ストレスが強いものか」という問題

Linuxカーネルのメンテナーはその必要不可欠で大変な仕事に以前よりも強い緊張を感じるようになっている

「オープンソースの世界はプログラミングがすべてだと思っている人も多いが、実はコミュニケーションが占める割合も大きい」

「メンテナーの仕事は翻訳であり、それは必ずしも言葉を翻訳するということではない。文脈、つまりそのコードであるべき理由を説明するということであり、それは大変な仕事だ」

■ 8. 悪意の存在

サプライチェーン攻撃の現実:

オープンソース・プロジェクトがソフトウェア・サプライチェーンの重要な位置を占めるようになった

悪意を持つ攻撃者にとってオープンソース・プロジェクトは格好の攻撃対象になっている

サプライチェーンの根っこのほうを乗っ取れれば攻撃者にとって得るものが大きい

XZ Utilsの事例:

XZ Utilsに悪意のあるコードが挿入された問題（CVE-2024-3094）が確認されたのが2024年3月

これは偶然にも氷山の一角が見つかった幸運な事例

おそらくいくつかの攻撃は既に成功していて私たちのソフトウェア・サプライチェーンには悪意のあるコードがとっくに入り込んでいると認識しておくべき

Embulkでの経験:

確実な証拠や確信こそ無いものの「これは攻撃だったんだろうな」という事例があった

■ 9. 個人によるメンテナンスの限界

現状の問題:

多くのオープンソース・ミドルウェアや「ミドルウェア化」したオープンソース・ライブラリが「個人」の手になるメンテナンスに依存

多くのメンテナーが「疲弊」している

この数ヶ月の間だけでもcurlやlibxml2の話題が挙がっている

エコシステムの持続性への疑問:

個人で続けられるか疑問

私たちのソフトウェア・エコシステムがいつまで保つか

2025年の日本各地で問題のクマ対応とも相似形の問題を感じる

■ 10. Embulkの場合の詳細

著者の状況:

半年ほど前にTreasure Data（TD）を退職

Embulkの「アクティブ」なメンテナーから「降りて」いる状態

この時点でEmbulkには「個人」のメンテナーしか残っていない状態だった

新しい職場でEmbulkを使う見込みはなかった

以前からの活動:

「オープンソースとしてのEmbulkのメンテナーを他にも割り当ててちゃんと引き継げる状態にしませんか」という活動を社内で数年前からしていた

社外でもEmbulkを使っていると対外的にも知られた企業さんなどに「一緒にメンテナーやりませんか」と言ってきた

Core Teamのような形を作って少しずつでも関わってもらおうという取り組みもしていた

■ 11. プロジェクトをたたむ決断

決断の背景:

引き継ぐ意志を明示的に示す人や組織が現れない限り既定路線だった

当時の勤務先から積極的なサポートも見込めなかった

自分はオリジナルの作者でもない

個人として続けても安定した収入に結びつくわけでもない

メンテナンスを続けるしんどさだけがそこにある

「これは攻撃だったんだろうな」の件も最後の追い打ちになった

たたみ方の方針:

「メンテナンスを静かに止めて言及も止めてアナウンスもせず、いつの間にかフェードアウト」のような態度を取るべきでないと考えた

企業などで重要データを運ぶこともあるEmbulkのユースケースを考えれば盛大に事故る前に落ち着いて切り替えができるうちに公式なアナウンスをしておくことがメンテナーの責務

悪意を持った人や組織にプロジェクトを引き継いでしまうくらいなら、プロジェクトをちゃんとたたむほうが結果的にユーザーにとっても良い

■ 12. 軟着陸のための方針

取り組み内容:

「このままだと続かないよ」という広報を陰に陽に続け、引き継ぐという人や組織が現れれば歓迎し、引き継ぐために労力を割く意志も示す

引き継ぎやすくするために今のEmbulkの設計について「なぜそうしたのか」を記録したドキュメント（Architectural Decision Record的なもの）をなるべく書き残す

「メンテナンス・モード」になっても即座に「使えなく」はならない程度に「塩漬け」の準備をする

評価:

100%狙いどおりにいったとは言えないが、たたみ方として悪くない着地になった

Embulkのコア機能やSPI（Service Provider Interface）の設計はよくできている

もうしばらくはこのままでもいちおうは「使える」

ただし無保証のオープンソース・ソフトウェアなので保証はない

「いちおうは使える」うちに落ち着いて移行や社内forkなどを進めることをおすすめする

■ 13. 引き継ぎの困難さ

現在の引き継ぎの可能性:

いまからでも引き継ぐ道筋はいちおう残している

ただし当時ほど現実的な選択肢ではもうない

困難な理由:

「引き継ぎのために著者が割けるのは100%プライベートの時間のみになった」こと

「引き継ぎを申し出た人や組織に『悪意がない』ことを確認するのが難しい」こと

それらを乗り越えてでも引き継ぐ意志のある組織の方がいれば連絡してほしい

■ 14. メンテナーの仕事と責任

メンテナンスの困難さ:

オープンソース・プロジェクトを、中でも「ミドルウェア」的な立ち位置になったソフトウェアのメンテナンスを「個人」の手のみによって続けるのは無理

これは一つのオープンソース・プロジェクトのメンテナーを十年近く続けてみることで得た当事者としての結論

開発とメンテナンスの違い:

新規のオープンソース・ソフトウェアを開発するとか定期的に「コントリビューションする」とかはけっこう「個人」でできる

しかし「メンテナー」の役務はこうした「開発」とはまったく異なる

オープンソース・ミドルウェアのメンテナーが担うのは聞き取り、コミュニケーション、判断、意思決定、その意思決定の末にやってくる結果に責任を負うこと

責任の本質:

オープンソースは「無保証」でありユーザーが損害を被ってもメンテナーはその損害に責任を負うものではない

しかし「俺は俺が公開したいコードを好きに公開してるだけだし、ユーザーのことなんか知らね」と考える開発者なら最初からオープンソース・ミドルウェアの開発やメンテナンスなんかやっていない

「あのときの自分の判断と意思決定の結果、どれだけのユーザー開発者がどのような影響を受けたのか」に向き合い続けるのがオープンソース・ミドルウェアのメンテナー

Linuxからの教訓:

メンテナーは異なる意見を持つ開発者間の調停役を務めたりベンダーやユーザーとやり取りをする必要もある

「開発者を見つける方はずっと簡単だ。開発者はたくさんいる」

「メンテナーになるためには、他人のコードの善し悪しを判断できるだけのセンスを持っていなければならない」

「それは通常、単に十分な経験があるかどうかの問題だ」

■ 15. 企業・組織の貢献と責任

企業ユーザーの困難:

「企業ユーザー」が依存し始めた「ミドルウェア」のメンテナンスを「個人」の手のみによって続けるのは無理

しかし「企業ユーザー」は無理では困ってしまう

コントリビューションの誤解:

「もっと積極的に『コントリビューション』します」と考えるなら記事を読み返すべき

徒に「コントリビューション」（pull requestなど）ばかりを増やすのはむしろメンテナーの負担を増やすだけの結果になるかもしれない

■ 16. オープンソース・プロジェクトの現在地とポリシーを知る

把握すべきこと:

依存しているそのオープンソース・プロジェクトはどこの誰がどう開発やメンテナンスをしているか把握しているか

様々なケース:

一個人が趣味で開発・公開しただけのまだ「メンテナンス」という段階ですらないもの

開発者自身がオーナーシップを握って互換性など気にせず変えながら外部からのコントリビューションも入れず好きなように開発したいと思っているもの

個人や数人レベルで開発しつつそろそろライブラリやミドルウェアとして安定してきていろんな人に使ってもらいたいと思っている段階のもの

企業発のオープンソース・プロジェクトだが社内で作ったコンポーネントをせっかくだからと公開しただけで広く使ってもらおうという気は特になく社外の互換性都合など気にするつもりもなく外部からのコントリビューションを受け付ける気もないもの

企業からオープンソース・プロジェクトとして公開しているが外部からのコントリビューションを受ける気はなく自社プロダクトを購入してもらうための導線として公開しているだけのもの

企業発の門戸を開いたオープンソース・プロジェクトとして主導権は持ちながらエコシステムとともに発展させたいと考えているもの

個人や企業から始まったオープンソース・プロジェクトだが大規模化して複数の個人や企業関係者が意思決定に参加するはっきりしたガバナンスを持つプロジェクトになっているもの

個人発でも企業発でも今後のメンテナンス継続に限界を感じている状態のもの

これらのケースの間のグラデーションのどこかに位置するあいまいな状態のもの

判断の必要性:

一口に「オープンソース・プロジェクト」といってもいろいろ

「オープンソース」はただのライセンスでしかない

あなたの企業はそのオープンソース・プロジェクトに依存しても大丈夫か

■ 17. オープンソース・プロジェクトが求める貢献の形

pull requestの誤解:

プロジェクトをGitHubに公開すると問答無用でpull requestを受け入れる状態にさせられてしまう

「オープンソース・プロジェクトにはpull requestという名の『コントリビューション』を送るものなんだ」という「誤解」がすっかり広まってしまった

オープンソースであってもすべてのプロジェクトが外部からのpull requestを実際に受け入れているとは限らないし受け入れていても喜ばれるとは限らない

求められる貢献の形:

ただ応援してほしいだけかもしれない

スターがつくと嬉しいプロジェクトもあるかもしれない

いろんな人からのpull requestが嬉しいプロジェクトかもしれない

バグ報告は欲しいがpull requestは求めていないかもしれない

スポンサーのほうがpull requestよりも嬉しいかもしれない

最終的には自社プロダクトを購入してほしいかもしれない

メンテナーとして共に持続的に役務を負ってくれる人を求めているかもしれない

■ 18. お金をとおしてメンテナンスに貢献する

スポンサーの方法:

GitHub SponsorsやOpen Collectiveをとおしてスポンサーするのが話が早い

このような形でスポンサーを求めていないプロジェクトにスポンサーするのはややこしいが求めているプロジェクトには遠慮なく支払える

企業としての検討:

企業としてスポンサー支出に正当性を持たせるのが難しいのはわかる

すべての依存プロジェクトをスポンサーするのは不可能

ただし「もしこのプロジェクトのメンテナンスが途絶えたらビジネスの継続にも支障が出る」というオープンソース・プロジェクトはないか

そういう単一障害点すら特定できていないのであればまずその特定をしたほうがいい

オープンソース・プロジェクトなんていつ止まってしまうかわからない

その単一障害点にあるプロジェクトくらいスポンサーを検討してもいいのではないか

製品購入:

そのオープンソース・プロジェクトがあくまで製品への導線で企業ユーザーとしてそのプロジェクトに依存するレベルで使おうとしているならちゃんと製品を購入すべき

■ 19. スポンサーの限界

スポンサーの現実:

お金をとおして貢献できるプロジェクトばかりではない

そのメンテナーが人生をかけて個人でやっているのならスポンサーによってメンテナーの命と生活が助かるかもしれないがそんなプロジェクトはごく少数

個人メンテナーにとってスポンサーはお小遣いくらいにはなるかもしれないが安定した収入として生活を支えられるようなものにはそうそうならない

Embulkの場合:

企業発という出自もあってスポンサーを募ったりはしていなかった

仮にTreasure Dataとは独立にスポンサーを募って個人としてメンテナーを続けたとしても自分や家族の生活を支えられるとは思えない

本質的な問題:

多くのオープンソース・プロジェクトにとってスポンサーは継続そのものの助けにはならない

多くのオープンソース・プロジェクトには結局本来そもそも持続に必要なだけのメンテナーが「いない」

多くのメンテナーが手弁当でメンテナンスを続けている（そして続けられていない）

Linuxにおいてすらそうである

■ 20. 雇用をとおしてメンテナンスに貢献する

課題の本質:

私たちの「足元」があとどれだけ保つか

そこにある課題は「持続とメンテナーの安定」

「持続と安定」に対して企業に期待される最もわかりやすい貢献は結局「雇用」

現実的な提案:

ほとんどの企業にとって「オープンソース・ソフトウェアのメンテナーをフルタイムで雇用する」なんていうのは難しい

しかし強く依存する途絶えては困るオープンソース・ソフトウェアが今後も持続するために雇用コストのごく一部でも正式に割くことはそんなに難しいか

ほとんどのオープンソース・ソフトウェアはかならずしもフルタイムでメンテナンスに従事するほどのメンテナーを必要としてはいない

一方で個人の業務時間外の時間のみで持続できるものでもない

具体的な提案:

自社が依存するオープンソース・プロジェクトとその現状を把握する

その維持が苦境にあれば会社としてその「メンテナンス」に貢献する意志を示す

従業員がメンテナーとして継続的にそのプロジェクトに関与することを推奨する

その従業員の勤務時間のn割はメンテナンス活動に使うことを認知する

それを正式に評価する

フルタイムではなくこれだけでもメンテナーの状況はかなり改善する

危機感:

世のbig techな企業はそれとはむしろ逆の方向に舵をきっていそう

「たたむ」オープンソース・プロジェクトはこれからおそらく増えていく

その「足元」であなたの会社のビジネスは継続できそうか

MEMO:

OSSの利用は自己責任が原則なのでしゃーない

(2025/11/26)

Rust is a disappointment

Blog - Rust is a disappointment

要約:

■ 1. Rustに対する著者の立場

著者の姿勢:

かつて自分をRustヘイターと呼んでいた

しかしそれはStack Overflowの調査で最も愛されている言語としてRustがトップになるようなファンボーイ的傾向を相殺するためだった

C++を嫌う理由は多くあり、著者もC++を嫌っている

多くの人がより良いプログラミング言語を待っていたが、代わりにRustを得た

■ 2. Rustの4つの核心的問題

コンパイルが遅い:

単に遅いのではなく非常に遅い

C++より遅い

年々Rustは数倍速くなったが、客観的には2倍ではなく2桁（100倍）速くなる必要がある

複雑である:

C++と同程度に複雑

しかしC++にはレガシーがあったがRustにはなかった

Arc<Mutex<Box<T>>>のジャングルを毎回通り抜けなければならない複雑さが、実装されるロジックの品質に直接影響する

木を見て森を見ずの状態になる

C++も同じ問題を抱えているなら、結局言語を切り替える意味は何なのか

メモリ安全性はそれほど神聖ではない:

実際、多くのアプリケーションではクラッシュするよりも誤動作する方が良い

特にRustが存在したがっている組み込みの世界ではそうである

Rustでは99.999%の信頼性を得ることはできない

常にクラッシュする

可変共有状態の処理において:

GUI、データベース、ステートフルサービス、OS/ハードウェアなど多くの可変共有状態を扱う場合

ネイティブのRustメモリモデルのパフォーマンスは劣る

非ネイティブのunsafeを使うとコンパイルが遅く、複雑性が高く、結局メモリ安全性もなくなる

重い可変状態の仕事に対してRustは実質的に無意味になる

■ 3. C++の問題点

未定義動作の遍在:

未定義動作（UB）は言語の基本的な側面

単にUBに遭遇するのではなく、言語全体がUBの上に構築されている

配列のインデックスアクセスで即座にUBに遭遇する

言語が範囲外アクセスをチェックしないため

多くのUBはパフォーマンスの理由でさえ正当化されない

Cから引き継がれC++で増幅された完全にずさんな設計

C++の具体的な問題:

暗黙の型変換、暗黙のコピー、暗黙のコンストラクタ、暗黙のオブジェクトスライシング、ほぼすべてが暗黙的

関数オーバーロード（暗黙的）、特にSTLでの遍在性を考慮すると

例外を後付けとした非統一なエラーハンドリング

Cから40年経っても#includeでテキストファイルを取り込んでおり、One Definition Ruleはコンパイラによるチェックがほとんどない

パラダイムの不健全な組み合わせ（子孫クラスでジェネリック関数をオーバーライドする幸運を祈る）

ジェネリックプログラミングの中核メカニズムとしてのSFINAEの厄介さ

T、T&、T*、std::optional、std::unique_ptrで似たようなものを記述するが、それぞれ独自の方法で壊れている。その上にconstを載せる

結論:

C++は複雑で、安全でなく、コンパイラが遅い

Rustはこれらの問題をどのように修正し（あるいは修正していないか）

■ 4. 遅いコンパイルの詳細

設計上の問題:

一時的な問題ではなく設計によるもの

Rust開発チームは毎回コンパイル速度を犠牲にしてきた

最適化の努力:

Rust FAQでは、より良いフロントエンド、MIRなど多くの最適化努力があると説明している

しかしMIRの取り組みは2015年に開始されたが、依然としてコンパイルを大幅に高速化できていない

コンパイラチェックは高速化している

本質的な問題:

Rustを高速にコンパイルすることは不可能

問題はHaskellのような類似のジェネリクス多用言語に固有のもの

Rustは議論の余地があるがC++よりもHaskellに近い

テンプレートを多用するC++コードと同じ遅いコンパイルの問題を示す

具体例:

for i in 0..limit {}を実行すると、単に反復するのではなく、範囲を作成し、イテレータを作成し、それを反復する

すべてが具体的な型に単相化され、個別に最適化される必要がある

最適化されていないRustコードは非常に遅く、デバッグにさえほとんど使用できない

ボローチェッカーの影響:

その上に非オプションのボローチェッカーを載せると、非常に遅いコンパイラになる

ボローチェッカーは容赦ないので、何度も再コンパイルすることになる

■ 5. 複雑さの詳細

回避不可能:

「コールドパスの高レベルコードを書いているのでパフォーマンスは必要ない、ライフタイム処理の深みに入る必要はない、単に高レベルのロジックを書きたい」という姿勢は取れない

Rustの1行を書くたびに低レベルの細かい点に強制的に押し込まれる

ガベージコレクタの不在:

RustにはGCがなく、今後もない

すべてのデータを所有権のツリーに半手動でパックする必要がある

数行のコードを書くだけでも所有権、借用、トレイトに精通している必要がある

高レベルロジックの困難:

Rustで高レベルのロジックを書くのは非常に困難

多くの初期Rust採用者が実際にはパフォーマンスにそれほど敏感でないサービスにはNode.jsやGoに戻っている

高い複雑さと遅いコンパイルの組み合わせにより、純粋なRustで複雑なものを書くことが非現実的になる

■ 6. メモリ安全性の詳細

Rustの妥協しない2つのもの:

パフォーマンスとメモリ安全性

Rust設計者はメモリ安全性に関して行き過ぎた

コンテナの実装:

コンテナは実際にはunsafe関数で実装されている

チューリングマシンモデルでは完璧な正しさは不可能

慎重に配置されたunsafeなビルディングブロックから安全なプログラムを構築する必要がある

他言語との比較:

Node.jsとGoは実用的に安全な言語と見なされている

Rustは正気さと実用性をメモリ安全性のために犠牲にした

そして結局どれも得られず、依然として100%メモリ安全ではない

実用性について:

多くのユースケースは完璧なメモリ安全性を必要としない

リモートコードを実行したり秘密を漏らしたりしない安全でないプログラムを実装する方法がある

ユーザーデータを破損させ散発的に動作するだけ

ペースメーカーが停止した場合、被害者に「クラッシュ時にメモリは破損していなかった」と伝えても慰めにならない

Cloudflareの障害事例:

unwrap()関数でのクラッシュによって引き起こされた最近のCloudflareの障害があった

著者の最も強い主張:

Rustはメモリ安全で信頼性がない

メモリ安全性の代価は開発者の正気さに加えて信頼性だった

言語設計者は行き過ぎた

メモリ安全性という抽象的な原則のために中核的な実用的品質を犠牲にした

Haskellの設計者が純粋性のために実用性を犠牲にしたのと同様

RustとHaskellの類似性を繰り返し指摘する理由

■ 7. 可変共有状態の詳細

Rustでの可変共有状態:

可能だが、Rustで可変共有状態を使用することは意味がない

ほとんどの利点を失い、Rustのすべての欠点だけが残る

成功したRustプロジェクト:

ほぼすべてが共有の読み取り専用状態、一方向データフロー、非循環データ構造を採用している

rustcコンパイラ、mdbookとpulldown-cmarkのMarkdownツール、ステートレスハンドラ用のActixとAxum、追記専用ブロックチェーン、シングルスレッドWASM

モデルはHaskellに非常に似ている

Haskellもパーサー、ステートレスハンドラ、ほぼ非インタラクティブなCLIツールで優れており、ブロックチェーンで使用されてきた

Software Transactional Memory:

Rustの初期プロトタイプには安全な並行性のオプションとしてSTMがあった

しかしSTMにはパフォーマンスペナルティがあり、単純だが重要なランタイムサポートが必要

共有可変状態に踏み込むと:

メモリ破損は例外ではなくルールになる

破損を処理する必要があり、単にクラッシュすることはできない

ボローチェッカー、所有権は役に立たない

GCのようなアルゴリズムなしで循環グラフの所有権を分析することはできない

Sync/Send、Mutex、Arc:

ロックするか、CPUキャッシュをひどく乱すので、マルチスレッド通信には非効率

少なくとも集中的なものには

安全だが非効率

Rustの最初の妥協しないもの（パフォーマンス）を破壊する

結論:

共有可変状態に踏み込んだ瞬間にRustのすべての利点を失う

Rustの主要なコンセプトが共有可変状態を決して使用しないことだったことを考えると合理的

■ 8. GUIとRustの問題

GUIは可変共有状態:

そのためRustで大きなGUIプロジェクトは見られない

Zed IDEの例:

何年も経ってもまだベータ版

開発者がボローチェッカーのジャングルを突破してロジックがバグだらけであることに気づき、まだ何十もの他の機能を実装する必要がある苦痛がほとんど感じられる

まだ見られないもの:

大規模データベース

スケーラブルなステートフルサービス

オペレーティングシステム

少なくとも重要なLinuxモジュール

■ 9. 結論：Rustの評価

Rustは良いのか悪いのか:

どちらでもない

開発に何千人月も費やされた平凡なプログラミング言語

この事実だけでRustは実用的なツールになる

棚から取り出してそのまま使用できるため

具体例:

このブログはRustで書かれたZolaで生成された

使用するためにRustのコードを1行も書く必要がなかった

Zolaは不変データの一方向フローを持つ非インタラクティブな性質のためRustに適している

著者の願い:

「Rustは最高のプログラミング言語だから、みんな開発をRustに切り替えるべきだ」と叫び回らないでほしい

(2025/11/26)

「Postgres で試した？」と聞き返せるようになるまでもしくはなぜ私は雰囲気で技術を語るのか？...

「Postgres で試した？」と聞き返せるようになるまでもしくはなぜ私は雰囲気で技術を語るのか？ — Just use Postgres 読書感想文 - じゃあ、おうちで学べる

(2025/11/26)

ひろゆき氏が語る大規模SIerの未来　20人月体制から1人とAIで回す開発へ

ひろゆき氏が語る大規模SIerの未来　20人月体制から1人とAIで回す開発へ [1/2] | ログミーBusiness

(2025/11/26)

セキュリティ特化型OS「GrapheneOS」が「国家による脅迫を受けた」としてフランスから撤退

セキュリティ特化型OS「GrapheneOS」が「国家による脅迫を受けた」としてフランスから撤退 - GIGAZINE

要約:

■ 1. GrapheneOSの概要

特徴:

オープンソースで開発されているセキュリティとプライバシー保護に特化したAndroid系OS

Google Pixelなどを安全に使うために利用されている

問題点:

セキュリティの高さから麻薬密売人などに使用されることがある

プライバシーを保護する機能が強力ということは悪事を働いても露見しにくいということにもなる

■ 2. フランス政府との対立経緯

フランス政府の姿勢:

以前から「GrapheneOSは犯罪者向けのもの」と表現するなど敵対視していた

フランスの治安当局が「隠れて生きる意思を裏付けるもの」として使用することが罪であるかのような調査報告を出したことがある

GrapheneOSの反論:

フランス当局の姿勢に反発

「ヨーロッパの独裁政権や政権を支持するメディアで、GrapheneOSやPixelを犯罪者向け製品であるかのような誤った表現が使われている」と非難

「GrapheneOSはこれらの勢力が全員に強要しようとしている大規模監視警察国家に反対している」と表明

■ 3. Le Parisienの報道（2025年11月19日）

報道の内容:

フランスのメディア・Le Parisienで「Google PixelとGrapheneOS：麻薬密売人が警察からデータを守るための秘密兵器」というニュースが報道された

GrapheneOSの反応:

メディアおよびジャーナリストに対し「GrapheneOSについて根拠のない、そして明らかに虚偽の主張をするためのプラットフォームを提供しながら、それらの主張を確認し反論する機会をまったく提供していない」と憤りを示した

検察当局者の発言:

「GrapheneOSは犯罪組織とのつながりがあり、捜査に協力しないのであれば法的措置に出る」とコメントが掲載された

GrapheneOSはこれを「事実無根であり、国家による法的脅迫だ」と問題視

■ 4. 機能に関する誤解

フランス当局の主張:

GrapheneOSがアクセス時にデータを消去する機能や偽アプリを含む犯罪者向けのOSと主張

GrapheneOSの反論:

それらの機能は公式版には存在しない

オープンソースとして公開しているGrapheneOSの悪質なクローンや非公式版と混同されている

■ 5. フランスからの撤退発表

撤退の理由:

フランスはオープンソースのプライバシープロジェクトにとってもはや安全ではない国であると判断

プロジェクトとユーザーを守るため今後はフランスへの進出を完全に避ける方針

フランスの政府機関と法執行機関の行動と発言が極めて懸念すべき点

GrapheneOSについて極めて不正確で中傷的な主張をしながら明らかに措置を正当化しようとしている

「彼らは手の内を見せたので、何か悪いことが起こる前にフランスから撤退する」と表明

■ 6. インフラ移行計画

従来のインフラ:

公式サイトやソーシャルメディアなどの主要インフラをフランスに本社を置くヨーロッパ最大のクラウドコンピューティングサービスであるOVHに依存していた

移行先:

MastodonやオンラインコミュニティプラットフォームのDiscourseなどをカナダのローカルサーバーと共有サーバーの組み合わせに移行

重要なウェブサイトインフラはドイツに拠点を置くウェブホスティングサービスのNetcupに移行

OVHから脱却する

開発者の制限:

安全上の懸念からGrapheneOSの開発者たちはフランス国内での作業を禁止している

■ 7. 今後の方針

AOSPへの貢献:

法執行機関やフォレンジック企業が捜査においてAndroid端末を突破するために使用している脆弱性をGrapheneOSで修正することを目指す

AOSP（Android Open Source Project）に貢献していくと表明

Googleへの呼びかけ:

「Googleからのご連絡をお待ちしております」と述べている

MEMO:

フランスの「自由」は都合よく解釈可能な「自由」なのでしゃーない

(2025/11/26)

LLMでユースケース図の作成時間を大幅に短縮 3つのプロンプト技術を組み合わせ

LLMでユースケース図の作成時間を大幅に短縮 3つのプロンプト技術を組み合わせ | AIDB

MEMO:

LLMにユースケース図を作成させたらいい感じだったらしい

(2025/11/25)

2025 年末のソフトウェア開発の様子

2025 年末のソフトウェア開発の様子 - amachang - Google スライド

MEMO:

AIの進化により職人的ソフトウェアエンジニアの役割は終わったというお話
エンジニアはPMも営業も出来るようにならないと厳しいぞと
まぁ、そうなるわな
救いがあるとすれば、個人で請けるなら本当に低予算・小規模なプロジェクトでも採算が取れる可能性があること
そういうスモールプロダクト・スモールプロジェクトであれば、いわゆる職人的ソフトウェアエンジニアもスキルと経験を活かしやすい
大規模・複雑・ミッションクリティカルな開発しか残らない世界線だとジョブチェンジを検討しなければならなかった

(2025/11/25)

ひろゆき氏が無料ツール利用を貫く理由　「2ちゃんねる」運営で学んだ壊れにくいサービス設計

ひろゆき氏が無料ツール利用を貫く理由　「2ちゃんねる」運営で学んだ壊れにくいサービス設計 | ログミーBusiness

要約:

■ 1. 2ちゃんねる創設の経緯

立ち上げの動機:

暇だったことが第一の理由

アメリカで大学生をしていた当時、「あめぞう掲示板」を使用していた

「自分で作れるのか」と試したら作れてしまった

高いモチベーションがあったわけではなく、できてしまったから惰性で続けた

学んだこと:

プログラムを作る力とサービスとして運営していく力は全く別物

動くものができても運用しやすいようにコードを修正する必要がある

トラブル防止のためのサーバー準備も必要

世界中の無料サーバーを契約して回り、「ここが落ちたら次はここ」というルートを事前に用意する運用ノウハウを蓄積

■ 2. 技術選定とシステム設計の考え方

使用言語:

当時からPerlで書いており、現在も同様

データベースを使わない理由:

データベースはたまにデータが壊れる

約10年前に某企業のOracleデータベースのデータが全消失した事例がある

データベースを使うとメモリやCPUのオーバーヘッドが大きくなりサーバーコストが高くなる

テキストファイル保存の採用:

テキストファイルに書き出せば壊れにくくできる

お金がない中での工夫

「どうやったら安く、壊れにくく動かせるか」という発想

このノウハウはその後のIT系会社経営でも活用

■ 3. 潰れない会社の経営哲学

基本原則:

会社が潰れるのはお金がなくなった時

お金がなくならなければ会社は生き残れる

毎月のランニングコストをいかに安くするかが重要

よくある失敗パターン:

売上を上げていく過程でコストも上がる

売上が下がった時に赤字になり大慌てになる

一度上がったコストを下げるのは非常に困難

その結果として倒産するケースが多い

実績:

1999年に大学生の時に作った合資会社は現在も存続

2001年頃に作った株式会社も現在も存続

自分の会社を潰したことはない

■ 4. サービスを当てるための考え方

仮説の作り方:

他にないことで「自分がそれを知りたい・やりたい・おもしろいと思うか」が基準

自分自身がおもしろくないと思うと飽きて続かなくなる

「別に自分が作らなくてもいい」「既にある」と思うと飽きてしまう

自分の欲望に沿うタイプ

他のアプローチとの違い:

「世間で流行っているから作る」というソシャゲー系の作り方はできない

好き嫌いに関係なく儲かるものを作る人もいるが、自分はそれができない

人の性格による違い

■ 5. 2ちゃんねる立ち上げ期の戦略

当時のインターネット環境:

企業がサイトを作って運営することは少なかった

ネット決済やクレジットカード入力はほぼ存在しなかった

個人がブログを書いてサイトを作るのが普通だった

情報を出す人が少なかった

「日本語で書かれているページはだいたい全部見た」という人がいた時代

昔のファミコンで「発売されたソフトはほぼ全部触っている」という人がいたのと同様

「全部わかる時代」だった

新しいサイトができたら情報を共有するリンク集が流行していた

掲示板を選んだ理由:

情報が集まる場所として掲示板はずっと残ると考えた

誰でも書けるため情報が出回りやすい

人が多ければ多いほど情報が増える

競合に勝つための設計:

たくさん人が来ても耐えられる仕組みにする

書かれたデータが消えずに残り続けるようにする

利便性を上げることで他のサービスより優位に立つ

コスト構造の優位性:

他のサービス運営者は自腹で回していたため、自分の給料以上の規模にできなかった

世界中の無料サーバーをひたすら契約し続けた

自分の人件費を除けばコスト構造がほぼゼロ

無料で規模だけ大きくしていった結果、日本で一番大きい掲示板になった

掲示板とSNSの関係:

掲示板はSNSの前の姿といえる

昔は掲示板で情報収集・情報共有をしていた

今はSNSがその役割を担っている

■ 6. 自宅サーバー学習の価値

自宅サーバーの意義:

2ちゃんねるも自宅サーバーで運営していた時代がある

自宅サーバーでしか学べないことがある

具体的なメリット:

「GPUをぶん回す」ような処理は自宅で回したほうが安いケースがある

「オンプレで自前で持つべきか」「クラウドでやるべきか」という比較ができるようになる

オンプレという選択肢を持っていないと「AWSとGCPどっちが安いか」という比較だけになる

「この部分はオンプレにする」「重要なデータだから社内に置く」といった判断ができる

結論:

自前サーバーの経験はサービスの管理者になるなら持っておいたほうがよい

■ 7. AI競争の価格面の帰着

大企業の動向:

OpenAIや大きな会社がひたすら投資しているものは残り続ける

各社が「超優秀なAIを作る競争」をしている

一般ユーザーの実態:

一般の人たちは「そこまで必要ない」という時代になりつつある

ChatGPT3と4の違い、4と5の違いを体感で理解しているユーザーは7〜8割もいない

今後の予測:

Metaの「パソコン1台で動く」「スマホの中で動く」モデルがある

中国製の「GPUなくても動く」モデルも存在

スマホやノートPCの中に入って「これで充分」という時代になる

巨大なデータセンターや電力の話が問題にならなくなる

「能力が高くなくてもこれで足りる」ものが小さく自分のスマホの中で動く時代になる

■ 8. データベースより軽い設計発想

データベースの課題:

データベース連携は便利なミドルウェアも多く、いろんな人が触れるようになる

しかし当時はサーバーのリソースが少なすぎた

アクセスが増えるとCPUが詰まる

データベースは同時書き込みでデータが壊れるため「ロックして1人ずつ書く」動きをする

アクセスが多すぎるとロックがかかったままになりデータの出し入れができなくなる

結果としてサービスが止まる

分散処理の問題:

「同じサーバーを100台並べて分散すれば処理が100倍になる」というやり方はコストがかかる

採用した解決策:

「多少順番がズレてもいいからロックしないで書く」

「多少の誤差は許容する」という方針

ロックせずにどんどん追記していく

「書き込んだ順番が前後することがあってもしょうがない」という誤差を認める

この方法でコストは大幅に下がる

テキストファイルでの運用はこの考え方に基づく

JSONでのAPI操作:

「データベースでガチガチにやるのではなくJSONでやる」というのは同様の考え方

(2025/11/24)

ひろゆき氏が語る“40代・50代エンジニア超優秀説”　AI時代に活躍する条件

ひろゆき氏が語る“40代・50代エンジニア超優秀説”　AI時代に活躍する条件 [1/2] | ログミーBusiness

要約:

■ 1. ひろゆき氏の現在の開発活動

使用言語・ツール:

Google Apps Scriptを使用

YouTubeのコメントを収集するアプリを開発

出力先をGoogleスプレッドシートにすることで無料でデータ保存が可能

現状の課題:

データ量増加に伴い動作が遅くなる問題が発生

有料ストレージの契約を検討したが、費用負担を避けて開発が停滞中

■ 2. AIを活用した開発スタイル

今回の開発目的:

AIがどの程度のレベルでコードを出力できるかを検証する実験

Geminiに仕様を投げ、やりとりしながら仕様書をブラッシュアップ

AIが出力したコードの精度を確認し、必要に応じて手動で修正

開発における役割分担:

スクラッチ（初期コード作成）は全てAIに任せる

デバッグや細かい修正は自分で行う

「ここだけ変えて」と指示しても別の箇所まで書き換えてしまう問題が発生

手戻りを防ぐための指示方法やAIの反応パターンを観察中

■ 3. 開発ツールの選定方針

使用ツール:

Gemini

ChatGPT（無料範囲）

GitHub Copilot（無料範囲）

無料ツールを選ぶ理由:

有料ツールはいずれ廃れる傾向がある

企業が有料で作ったツールも、後から無料のオープンソースベースのものに置き換わる

PhotoshopやIllustratorに対するGIMPの存在が例

VS Codeはマイクロソフト製だが無料で使える

オープンソースは無料で広まり、多くの人に修正されて品質が向上する歴史がある

■ 4. 技育祭と若手エンジニア育成について

技育祭の意義:

手作り感を出し続けることで参加しやすさを維持

「とりあえず参加してみる」までのハードルを下げることが重要

エンジニアの適性:

向き不向きはやってみないとわからない

優秀なエンジニアには面倒くさがりが多い

「手を動かすのが面倒だから自動化しよう」と考えられる人が強い

やる気なさそうに見えるタイプが実はエンジニアとして優秀なケースがある

プログラミング未経験で「必要だからやるか」と始めた人が非常に優秀になるパターンも存在

■ 5. サーバーエンジニアの将来性

AIの限界:

サーバー契約の最適解や安いサーバーの提案は可能

実際にトラブルが発生した際の修正はAIにはできないことがある

ネット上にない情報やレアなバグへの対応は苦手

AIはネット上の情報を統計的に処理して最適解を出す仕組みのため、未知の問題には対応困難

人間の強み:

サーバーの仕組みを理解していれば、別サーバーを立てて冗長構成を保ったまま切り替えるなどの対応が可能

インフラの前提を理解していない人がAIだけで大規模サービスを構築するのは現状困難

自分自身の知識と知能で解決しなければならない問題に対しては人間が必要

■ 6. AI時代におけるエンジニアの知識と経験

40〜50代エンジニアの活躍:

AIがコードを書けるようになり、若手に細かい実装を振る必要がなくなった

40〜50代は自分でサーバーを立ててOSを入れてアプリを書くという一連の流れを全て手作業で経験した世代

仕組みを丸ごと理解しているため、仕様から削る判断や全体設計の見直しが可能

部分最適ではなく全体を見たものづくりができる

20〜30代エンジニアの課題:

イチから物を作る経験が不足しているケースが多い

CPUだけ速くしてもメモリが詰まる、ストレージが遅いとボトルネックになるといった段階的な切り分けの感覚が身についていないことがある

DBのテーブル設計変更によるI/O削減やサーバーの疎結合化といったノウハウが不足

AIに丸投げするとお金で解決する設計になりがち

「同じサーバーを10台並べてホットスタンバイにする」といった非効率な提案になる傾向

推奨される学習方法:

お金があまりない環境で自分でゼロから立ち上げる経験を積むべき

■ 7. コンピューターサイエンスの知識の必要範囲

不要な知識:

CPUの内部構造

アセンブラレベルの理解

サーバーを自分の手でイチから組む能力

必要な知識:

リモート先のサーバーでCPUがどう動いているか

メモリがどう使われているか

コンピューターの基本的な仕組み

プログラミング言語の習得:

1つの言語をしっかり身につければ十分

1つマスターすると別の言語を見た時に「言い回しが違うだけ」「こういう仕様なのね」と読み替えられる

学び直しのハードルが一気に下がる

基礎の重要性:

メモリの概念がわからない人にポインタを教えるのは困難

メモリの概念を理解している人には「メモリのラベルを使うためにポインタがある」と説明すれば理解が早い

抽象概念よりも基礎のハードウェアを学んだほうが理解しやすい

■ 8. AI時代におけるエンジニアの価値

エンジニアの強み:

仕様を設計できる能力

「この予算ならここは削ったほうが回る」というコストとのバランスを見る力

クライアントへの提案力（「ここを外せば納期が短くなる」「ここを簡略化すればコストが下がる」など）

お金と時間の感覚に基づいた提案

AIの弱点:

コスト感は会社ごと・案件ごとに異なる

その場でさじ加減できる判断は人間のほうが強い

■ 9. 新卒カードの活用と大企業への就職

大企業を選ぶべき理由:

「AIを使いこなせなそうな大企業」という決めつけは成長を阻害する

大企業にいても自分でAIを調べて詳しくなる人はいる

中小企業でも趣味で調べて詳しくなる人はいる

「企業が何を与えてくれるか」という基準で選ぶのは好ましくない

大企業でしか得られない経験:

大企業でしか触れられないノウハウ

意思決定の流れ

「この規模だとこうやって予算が下りる」という構造の理解

「このタイプの案件はこの人が決裁権を持っている」といった内部の仕組み

エンジニアリングの特殊性:

大工は20代で家を一軒任されることはないが、エンジニアは20代でもアプリやサイトを1人で作れる

「中小に行けば何でもやらされるから経験になる」と言われるが、そのレベルの経験は個人開発でも可能

大企業SIerの課題:

セキュリティの観点でコーディングにAIを使用禁止のところがある

AIを使わずに手癖が付くメリットはある

「ここはもうAIで書く」という領域が増えているため、人力でコーダーを何年もやった経験が役に立たないケースもある

「コードを書くのにAIは一切使うな」というスタンスは現代にそぐわない

■ 10. ITベンチャー企業と若手の働き方

20代にしかできない経験:

馬車馬のように残業時間を気にせず働くのは20代の時しかできない

若いうちに振り切って働いた経験があるかないかで、大人になってからの見え方が変わる

自分の最大値や限界を感覚で把握できるようになる

「最悪ここまでは踏み込める」という判断ができるようになる

ベンチャー企業の魅力:

大企業では労基の観点から限界まで働く経験がしにくい

ベンチャーで文化祭のように集中して働く楽しさは若いうちに味わっておく価値がある

ひろゆき氏自身の20代:

自分のサービスが好きで1日十数時間自分の作ったサイトを見ていた

夜中にサーバーが落ちたら対応、旅行中でも対応という24時間即応態勢

バグがあったら直るまでずっと起きて対応

苦痛ではなくサービスを維持すること自体が楽しかった

「全体的には楽しい」の中につらいところもあるという感覚

睡眠時間は事故がなければ限界まで寝るタイプで、トラブルが重なった時だけ徹夜

(2025/11/24)

ワインバーグの法則をAIに適用する『コンサルタントの秘密』

ワインバーグの法則をAIに適用する『コンサルタントの秘密』: わたしが知らないスゴ本は、きっとあなたが読んでいる

要約:

■ 1. 『コンサルタントの秘密』の概要

ジェラルド・M・ワインバーグによる主著である

コンサルタント向けの専門書ではなく、相談されたときの思考法をまとめた普遍的な内容である

肩書きではなく「どのように人と関わるか」を扱った一冊である

プログラムやシステムの話はエピソードとして登場するが本質ではない

様々なトラブル事例から「コンサルタントの法則」を紹介している

トム・デマルコの書籍の源泉となった組織論や発想が含まれている

■ 2. オレンジジューステスト

設問内容:

朝5時から1,000人分の搾りたてオレンジジュースを提供する

缶入りジュースや事前準備は禁止である

直前に絞ったジュースを全員に行き渡らせる必要がある

合格の回答:

「できる。これだけのコストがかかる」と答えることである

「無茶だ」「現実的でない」と勝手に判断することは失格である

コンサルタントの役割:

可能な選択肢を示すことである

それにかかるコストを示すことである

選択は依頼主が行うものであり、選ばない選択も含まれる

原則:

相手の要望を勝手に最適化することは相手の判断を奪う行為である

相談される側は判断材料を提供する役割に徹するべきである

良し悪しまで口出しすることはお節介である

■ 3. 「そこに無いもの」を見る方法

課題の特性:

見えないものを見つけることは困難である

悩みごとの原因は見えていない場合が多い

紹介されている技法:

ピンの技法は、リストアップ手段が無い対象こそ取り組むべきとする

3の法則は、計画を台無しにする原因が3つ考えられないなら思考方法に問題があるとする

説明の顔をしたアリバイは、ルールから言い訳を探す行為を指摘する

「他人という異文化を利用する」事例:

ワインバーグはプログラマの生産性向上を依頼された

職場では要望があればすぐに購入・作成する方針だった

プログラマへのインタビューでは「足りないもの」が見つからなかった

掃除のおじさんに「黒板を拭いてくれと頼まれたことはない」と言われた

黒板は「消すな」という警告付きの個人メモで埋め尽くされていた

本来の共有ツールが機能せず、購入したソフトやガジェットも共有されていなかった

他者の視点により見えない問題を発見できた

■ 4. AIを活用した「足りないもの」の発見

「洗濯物リスト」の作成方法:

機能設計時にスライド一枚に要件と実現方法を箱で並べる

「この一枚が全体像だが、足りないものは何か」と周囲に問う

機能不足だけでなく要件の制限や前提の追加が判明する

ネットワーク設計や非機能要件周りで発見が多い

AIの活用方法:

要件と機能の不足を尋ねる

タスクの網羅性とコスト見積もりを確認する

図が成立する前提で欠けているものを探す

計画を台無しにする原因を3つ以上考えさせる

AIの特性:

網羅性の確保に適している

「10個考えて」という無茶な要求にも対応する

人間が妥当性を最終判断する必要がある

1990年の出版時には存在しなかったAIという異文化を現在は活用できる

コンサルタント業務の多くをAIに任せられるようになった

最終判断は人間が行う必要がある

■ 5. AI時代におけるコンサルタントの本質

コンサルタントの核心的業務:

どのような問いを投げるかを決定することである

どこまで自分で判断するかを見極めることである

現代における重要性:

正解がない時代では答えよりも良い問いが重視される

問いへ向き合う考え方が必要である

『コンサルタントの秘密』はAI時代だからこそ読み直す価値がある

(2025/11/24)

AI駆動開発を実現するためのアーキテクチャと取り組み

AI駆動開発を実現するためのアーキテクチャと取り組み - Speaker Deck

(2025/11/23)

特にエンジニア採用では「モダンな技術や最新の開発手法が取り入れられておりあの会社は優秀な...

特にエンジニア採用では「モダンな技術や最新の開発手法が取り入れられておりあの会社は優秀なエンジニアが数多く集まっている。自分もあの中に入ると何か少しエンジニアとして優越感が出そう」という空気感大事なんですよね。金払いがちょっと良いくらいではこの優越感が得られない。

@sakamoto_582

MEMO:

ピカピカの技術スタックや開発手法は福利厚生定期

(2025/11/22)

論理削除の絞り込みはWHERE句でやるな

論理削除の絞り込みはWHERE句でやるな

(2025/11/22)

手を動かしながら学ぶデータモデリング

手を動かしながら学ぶデータモデリング - 論理設計から物理設計まで / Data modeling - Speaker Deck

(2025/11/22)

乱雑なコードの整理から学ぶ設計の初歩

乱雑なコードの整理から学ぶ設計の初歩 - Speaker Deck

(2025/11/22)

DDD x Microservice Architecture : Findy Architecture Conf 2025

DDD x Microservice Architecture : Findy Architecture Conf 2025 - Speaker Deck

(2025/11/22)

QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化する

QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化する - Cluster Tech Blog

(2025/11/22)

急速に波及する【もういい、Linuxをインストールする】

急速に波及する【もういい、Linuxをインストールする】 - YouTube

要約:

■ 1. もう限界、Linuxへ - 2025年のPC界隈の変化

2025年のPC界隈で静かに広がっている合言葉:「もういい、Linuxを入れる」

長年Windowsでゲームをしてきた熟練ユーザーやテック記者までがハイエンドのゲーミングデスクトップを丸ごとLinux(特にCachyOSのようなゲーム特化ディストリビューション)へ移行し始めている

あるベテラン記者はRyzen 7 9800X3DとGeForce RTX 4070 Tiという典型的なハイエンド構成のWindows 11マシンをあえてLinuxに変えると宣言

理由:Windowsはどんどん扱いづらくなっているのにLinuxでのゲーム環境は明らかに良くなっているという感覚

■ 2. Reddit での賛同

海外掲示板Redditのテクノロジー版では同じ言葉をタイトルにした投稿が立ち、数千件規模の賛同票が集まった

コメント欄には「もうWindowsの挙動に疲れた」「AIと広告が増えてOSとしての基本が良くならない」といった声が並ぶ

長年Windowsを使ってきたユーザーほど不満を募らせている構図が見える

■ 3. Windows 11のエージェントOS化

背景にはMicrosoftの路線変更がある

Windows 11は「エージェントOS」を掲げ、Copilotと呼ばれる生成AIアシスタントをタスクバーやファイルエクスプローラー、設定画面などシステムの至るところに深く組み込もうとしている

最新ビルドではファイルエクスプローラーから直接ドキュメント要約やメール下書き生成を呼び出す機能まで用意

OSそのものが常時AIと会話することを前提に設計されつつある

一方でユーザー体験は必ずしも便利になったという実感と結びついていない

■ 4. Copilotを巡る問題

Copilotを巡る議論では常に画面の隅にいるだけでなく、AIが基本的な操作に失敗した公式広告動画が批判を浴び、Microsoft自身がその広告を削除する事態になった

AI連携を強めることでブランドを近未来的に見せようとする動きと、「まずファイルエクスプローラーのフリーズやスタートメニューの不具合を直して欲しい」という利用者側の素朴な要求との乖離がユーザーの苛立ちを増幅させている

■ 5. Recall機能の問題

象徴的なのがRecallと呼ばれる機能

Recallは画面の内容を一定間隔で自動撮影し検索可能な「パソコンの記憶」として保存する仕組み

Microsoftは暗号化やWindows Helloによる保護を強調するが、実際にはデータベースが平文のSQLite形式で保存されていた時期があり、専門家から「悪意あるソフトや物理的なアクセスに極めて弱い」と警告されている

プレビュー段階での強烈な反発を受けて一度は提供を見直したものの、その後もInsider向けに再投入するなど方向性自体は変えていない

■ 6. 広告的なUIの問題

ユーザーの視界を埋める広告的なUIもMicrosoftへの不信感を積み上げてきた

Windows 11のスタートメニューには「おすすめ」と称するエリアがあり、そこにアプリやサービスのプロモーションが表示される仕様が導入されている

設定である程度は無効化できるものの、規定では有効な上、更新の度に挙動が変わることも多い

最近ではPCのバックアップを推奨する警告風メッセージとしてOneDriveのクラウドバックアップを促す表示がスタートメニューに出るケースが報じられた

黄色い感嘆符で「アクションを推奨」という文言でユーザーの不安を煽りつつ、実態はMicrosoft 365やクラウドサービスの利用を後押しする導線になっている

■ 7. Windows 10サポート終了の影響

決定的だったのがWindows 10サポート終了のタイミング

Microsoftは2025年10月14日を持ってWindows 10の通常サポートを終了し、以後は月例のセキュリティ更新や新機能提供を行わないと公式に発表

Windows 10は依然として世界のWindowsユーザーの4割前後を占めていたとされ、数億台規模のPCが一斉に期限切れの状態になった

Microsoftは Windows 11へ移行できないユーザー向けにESU(Extended Security Updates:延長セキュリティ更新プログラム)を用意

個人向けでは1台あたり年間30ドル相当の料金、あるいはMicrosoftアカウントとの紐付けやポイント交換による無償枠といった複雑な条件が提示されている

ローカルアカウントだけで使い続けたいユーザーがESUを利用するには結局Microsoftアカウントへの移行を迫られる形

■ 8. Windows 11のハードウェア要件

Windows 11側にはTPM 2.0やSecure Bootといったハードウェア要件が課されており、古いPCほどアップグレードが困難になる

サポート終了に伴う解説記事の多くは「Windows 11要件を満たさないPCではLinuxディストリビューションやChrome OS Flexへの移行も選択肢になる」と明記

つまりMicrosoft自身のライフサイクル戦略が結果的に「今のWindowsを捨てて別のOSへ飛び移ること」を現実的な選択肢としてユーザーに意識させてしまった

■ 9. LinuxとSteam Deckの台頭

このタイミングで存在感を増したのがLinuxとSteam Deckを中心とするオープンなゲームエコシステム

Valveが毎月公表しているSteamハードウェア&ソフトウェア調査の2025年10月版では、Linux利用者の割合が初めて3%を超え3.05%に達した

1年前の約2%からわずか1年で5割増の水準

依然として94%以上を握るWindowsと比べれば小さな数字だが、傾向としては明確な伸びを示している

■ 10. Protonの役割

Linux側の下地を作った最大の要因がValveが開発したProtonという互換レイヤー

ProtonはWineと呼ばれる互換技術をベースにしたソフトウェア群で、Windows向けのゲームをLinux上で動かすための翻訳役を担う

Steamクライアントに統合され、ユーザーはゲームごとに有効化するだけでDirectX APIの呼び出しがVulkanなどのグラフィックスAPIに変換される仕組み

2025年秋時点の調査ではProtonDBの統計に基づき、Windowsゲームの約9割がLinuxでプレイ可能という水準に達したことが報告されている

■ 11. Steam OSとSteam Deck

物理ハードウェアとしてはSteam OSとSteam Deckの存在が象徴的

LinuxベースのSteam OSを搭載したSteam Deckは携帯ゲーム機の形をしたPCとして世界的なヒットを記録

そのOS構成やドライバー最適化がそのままLinuxゲーム環境の標準的な参照例になった

Valve自身のハードウェアだけでなく、ROG AllyのようなWindows搭載ハンドヘルドがBazziteというFedoraベースのディストリビューションに入れ替えることでフレームレートやバッテリー効率を改善できる事例も報告されている

■ 12. ハードウェアメーカーの対応

Linux側のゲーム人口がSteam全体の約3%という水準に達した今、ハードウェアメーカーも無視できなくなっている

Steam Deck向け最適化を意識してAMDがオープンソースGPUドライバーの開発を強化

2025年にはWindows向けでメンテナンスモードに移行した旧世代GPUでもLinux側ではコミュニティ主導のRADVドライバーにより引き続き最適化が続くという構図が生まれた

Windowsでドライバーサポートが先細りになる一方、Linuxでは過去世代GPUが長く活用される可能性が高く、古いゲーミングPCを延命させたいユーザーにとっては魅力的な要素になりつつある

■ 13. CachyOSの特徴

CachyOSはArch Linuxをベースに「高速、安定性、ゲーミング最適化」を全面に押し出したディストリビューション

公式サイトでは「Blazingly Fast」を謳い、x86-64-v3やx86-64-v4といった新しめのCPU命令セットに最適化されたパッケージを提供することで、同じハードウェアでも標準的なバイナリより高いパフォーマンスを目指している

心臓部にあるのがCachyOS Kernelと呼ばれる独自ビルドのLinuxカーネル群

BORE(Burst-Oriented Response Enhancer)やEEVDFといったCPUスケジューラ、LTO(Link-Time Optimization)、CPUアーキテクチャ別のコンパイルオプションなどを組み合わせ、入力遅延の低減とスループット向上を狙っている

■ 14. Linuxの課題

もちろんLinuxに移れば全てが解決するわけではない

最大の難所として挙げられるのがカーネルレベルで動作するアンチチートとの相性問題

Battlefield 2042やCall of Duty: Black Ops 6のような大型タイトルではSecure BootとTPM 2.0を有効にした上でRiot VanguardやEasy Anti-Cheatといったカーネル常駐アンチチートを要求するケースが増えている

こうした仕組みはWindowsカーネルを前提として設計されており、Protonが再現するユーザーランドだけでは対応しきれない

技術的なハードルも残る:一部のハードウェアではLinux向けドライバーが未整備だったり、ベンダー純正の設定ツールが提供されていなかったりするため、「買ってきてさせばすぐ使える」というWindows的な感覚は通用しない場面がある

■ 15. 現実的な移行ガイド

それでもWindowsからLinuxへの移行ガイドは年々現実的なトーンになってきた

かつてはデュアルブートや仮想マシンで遊び半分に触ってみる程度の提案が多かったが、今では「Steamライブラリーの大半はLinuxで問題なく動く、どうしても必要なタイトルだけWindowsに残し、日常のゲーム環境はLinuxへ移す」という構成を推奨する記事も増えている

ProtonDBで事前に互換性を確認し、必要に応じてローリングリリースのディストロをデュアルブートで入れるといった具体的な移行シナリオが提示されるようになった

■ 16. OSとしての哲学的考察(「沈黙する回路」)

OSは単なるソフトウェアではない:朝起きて最初に触れる窓であり、1日の思考を流し込む媒体であり、記憶が堆積していく基盤でもある

そこに絶え間なく広告や提案が降り注ぐと、心のどこかで自分の時間が少しずつ切り売りされている感覚が芽生える

便利さと引き換えに集中の静けさが薄く削られていく

だからこそ何も語らないOSへの憧れが生まれる:起動しても何もおすすめしてこない環境、こちらから呼ばない限り口を開かないAI、更新の度に性格を変えないデスクトップ

CachyOSのようなディストリビューションはその憧れを実態に変えるためにカーネルの速度やパッケージの構成といった目に見えにくい部分を丁寧に磨き続ける

そこでは沈黙そのものが1つの設計思想になる

■ 17. 価値観の問題

OS選択を単なる好みや慣れの問題として片付けるのは簡単

しかしWindows 10のサポート終了やAIと広告を全面に押し出すWindows 11の路線、ハードウェア要件とアンチチートの強化によって、Microsoftの設計思想そのものがユーザー側の価値観と衝突し始めている

自分のPCを自分が主役の道具として保ちたいのか、クラウドサービスとAIのためのプラットフォームとして受け入れるのか

その分岐点に立たされたユーザーが「もういい、Linuxを入れる」とつぶやきながらCachyOSのインストーラーを起動する姿は単なるOS乗り換え以上の意味を持ち始めている

(2025/11/22)

エンジニアの脳が壊れる瞬間 ─ 複雑性・認知負荷・計算量のメカニズム

エンジニアの脳が壊れる瞬間 ─ 複雑性・認知負荷・計算量のメカニズム #設計 - Qiita

要約:

■ 1. はじめに:複雑性が問題を生む理由

ソフトウェア開発には「複雑性が問題を生む」という常識がある

問い:

なぜ複雑になると破綻するのか

どこから複雑と呼べるのか

どの瞬間に人の理解が追いつかなくなるのか

技術負債はなぜ突然「手がつけられない」段階まで膨張するのか

ソフトウェアの複雑性を計算量、認知負荷、チーム特性という3つのレンズで読み解く

ポイントは「複雑なコード」ではなく「複雑さ自体の本質」を扱うこと

■ 2. 複雑性とは計算量の爆発を人間が受け止められなくなる現象

ソフトウェアの複雑性はしばしば計算量の爆発として語られる:

O(N) → まだ追える

O(N²) → 何が起きているか曖昧になる

O(2^N) → もはや理解不能

しかしこれは人間の脳にもまったく同じことが起きる

人間の作業記憶は7±2個しか保持できない(心理学の古典的研究)

これはエンジニアにとっては「認知の計算量制限」を意味する

その後の研究では実効容量は4±1個程度という見解も有力(Cowan 2001など)

つまりコード設計がO(理解)を超えた瞬間、人は壊れる

人間の作業記憶は5〜9チャンク程度しか同時に扱えないとされており、複雑な設計はすぐにこの上限にぶつかる

■ 3. 設計の計算量はコード行数ではなく関係性の数で決まる

複雑性はコード量では決まらない

関係性(依存・制約・フロー)の数で決まる

例:

AがBを知っていて

BがCを参照していて

Cが非同期にAを更新する

これを理解するには人間はA-B-C-Aの閉路を追跡しなければならない

これは脳にとってDFS(深さ優先探索)のような負荷

関係性が増えるほど理解の計算量は指数的に増える

コードは線形に増えるが理解コストは指数関数的に増える

だから設計は突然破綻する

崩壊は徐々には進まない

ある閾値を超えた瞬間いきなり崩れる

まるで「臨界点」を超えた化学反応のよう

依存関係の数が増えると開発スピードより先に「依存の管理コスト」が爆発していく

■ 4. 認知負荷は見えない技術負債である

複雑性が破綻するのは技術の問題ではなく人間が処理できる情報量の限界を超えるため

認知負荷が高い設計には次の兆候がある:

一度読んでも理解できない

仕様とコードの対応が不明

「ここを変えるとどこに影響する?」が見えない

レビューが摩耗する

バグが「点」ではなく「面」で発生する

これらはすべて「計算量過多」「キャパシティ超過」の症状

技術負債とは「認知負荷が金利として積もっていく現象」と捉えるべき

技術負債は単なる「後回しの修正」ではなく開発者の頭の中に積み上がる認知負荷そのもの

■ 5. アーキテクチャの本質は計算量の制御

設計とは格好いい図を描くことではない

本質はただ一つ:「理解に必要な計算量をO(1)に近づけること」

そのためにアーキテクチャが存在する:

層で区切る → 認知対象を一定に保つ

責務を限定する → 計算経路を短くする

境界を作る → 関係性を切断する

APIを設計する → 認知を抽象化する

きれいな設計にも理由がある

それは美しいからではなく脳への負荷を最小化するため

■ 6. 複雑性の破綻ラインは個人ではなくチームに依存する

認知負荷は人によって異なる:

初心者はすぐO(爆発)

ベテランはO(ある程度耐える)

設計者はO(ノイズを抽象化できる)

つまり複雑性の破綻ラインはチーム固有のものであり汎用的な「正しさ」では語れない

技術は移植できても認知限界は移植できない

あるプロジェクトでうまくいった設計が別のチームでは壊滅する理由はここにある

■ 7. 実務で複雑性の爆発を防ぐ方法

(1) 関係性を減らす(依存を切る):

イベント駆動で発散した依存を整理する

双方向参照を禁止する

「AはBを知らない世界」を設計する

短い例:UI→UseCase→Repositoryだけにし、UIがRepositoryを直接呼ばないようにする

(2) 読み方をO(1)に近づける:

コードが「初見で」理解できる必要がある

初回で理解できない設計は複雑すぎる

短い例:「この関数は何をするか?」が1画面以内で完結するようにする

(3) ドキュメントではなく構造で説明する:

ドキュメントで補強が必要な設計はすでにO(1)ではない

短い例:「ここは○○層です」と説明不要なようにフォルダと責務を一致させる

(4) レビューで認知負荷を観測する:

レビューの摩耗は構造の疲労

短い例:PRに「ここ分かりづらい」コメントが連発したら設計の構造疲労を疑う

(5) チームの認知限界を把握する:

ベテランの限界ではなくチームの最低ラインで設計すべき

短い例:「新人でも追える構造」を基準にしベテラン依存の暗黙知を排除する

■ 8. おわりに

複雑性の問題は理論では説明できるが実務ではほとんど語られない

しかしソフトウェアが破綻するのはいつだって「人間が理解できなくなったとき」

ソフトウェアの限界は計算資源ではなく人間の認知資源で決まる

この視点が定着すると設計やレビューやアーキテクチャの見え方が変わる

複雑性を避けるのではなく複雑性と「共存できる形」を探すことが大切

(2025/11/21)

仕様駆動開発の理想と現実、そして向き合い方

仕様駆動開発の理想と現実、そして向き合い方 - Speaker Deck

(2025/11/20)

Goで挑む大規模データ処理

Goで挑む大規模データ処理 | ドクセル

(2025/11/19)

APMを支えるデータ構造とアルゴリズム

APMを支えるデータ構造とアルゴリズム - Mackerel ブログ #mackerelio

(2025/11/19)

【libxml2】libxml2プロジェクトは放棄されました

【libxml2】libxml2プロジェクトは放棄されました #Security - Qiita

要約:

■ 1. libxml2のセキュリティポリシー変更

libxml2のリポジトリに新しいテキストが追加された

内容:

趣味人たちによって開発され、たった一人のボランティアによってメンテされているオープンソースソフトウェアである

テストは適当で、メモリ安全ではなく、セキュリティバグも満載である

信頼できないデータに対してこのソフトウェアを使用するのは愚かな行為である

セキュリティバグは他のバグと同様に扱われる

受け取ったセキュリティバグ報告は全てただちに公開され、優先的に修正されることもない

■ 2. libxml2の概要

XMLを処理するライブラリである

多くのLinuxディストリビューションやプログラミング言語に導入されている

ChromeやSafariといったWebブラウザでも使われている

事実上業界標準と言える

PHPにもあり、DOMやSimpleXMLなどがlibxml2に依存している

2000年ごろにDaniel Veillardによって作成された

2013年ごろからNick Wellnhoferが貢献を始めた

現在はNick Wellnhoferがほぼ一人で保守を行っている

■ 3. 協調的脆弱性開示プロセスの背景

セキュリティバグは基本的に通常のバグ報告と異なる扱いがなされる

いきなりGitHubやその他メディアなどでセキュリティバグが公開されると、修正が間に合わないうちに攻撃者に利用されてしまうためである

セキュリティバグについては各企業のバグバウンティプログラムやHackerOne、IPAなどの機関に報告し、修正されるまで待ってから公開する手順が確立された

報告を受けた側も修正版がリリースされるまではセキュリティバグについては黙っておくのが通例である

これは協調的脆弱性開示プロセスと呼ばれ、現在では多くの開発者やアプリケーションがこのプロセスに従っている

libxml2はこの業界標準を無視し、セキュリティバグも一律全て公開する、攻撃者に利用されても知ったことではない、という斬新なセキュリティ対策に方針を切った

対応されてなかろうが90日で開示というポリシーを強行して大批判を食らったGoogle Project Zeroのはるかに上を行く対応である

■ 4. メンテナーの経緯:Stepping down(2021年7月22日)

特に頼んだわけでもないが、いつのまにかlibxml2とlibxsltの事実上のメンテナーになっていた

幸いなことにChrome VRPバグバウンティとOSS-Fuzz Integration rewardsによって報酬を得ることができていた

Googleのこれらの優れたプログラムに感謝する

残念ながらセキュリティからの収益が急減しており、最低限の資金を確保するめども立たなくなった

そのためコントリビュータ・メンテナを退任することにした

■ 5. メンテナンスの再開(2022年1月10日)

Googleからの寄付のおかげで2022年はlibxml2とlibxsltのメンテナンスを継続できるようになった

■ 6. セキュリティ問題への対応(2025年5月8日)

毎週何時間も第三者から報告されるセキュリティ問題への対応に追われている

これらの問題のほとんどは致命的ではないが、それでも大きな作業である

無給のボランティアにとってこれは持続不可能である

libxml2の開発を継続できるようにいくつかの変更を考えている

基本的な考え方はセキュリティバグを他のバグと同じように扱うということである

セキュリティバグはただちに公開され、他のバグと同じ優先度で扱われる

この方針は一部のダウンストリームを不安に陥れるかもしれないが、もしかしたら貢献意欲を高めるきっかけになるかもしれない

■ 7. OpenSSFとセキュリティ業界への批判

長年この仕事をしてきたので、セキュリティ問題に関わる秘密主義のほとんどはただの茶番にすぎないものであるとわかっている

OpenSSFのような「ベストプラクティス」は、大手テクノロジー企業がOSSメンテナーに罪悪感を抱かせ、無償で働かせようという圧力に過ぎない

最近個人経営している会社をOpenSSFのメンバーにしようとした

そのためにはまずLinux Foundationのメンバーになる必要があり、これは最低でも年間1万ドルかかる

これらは非常に排他的な組織であり、なにひとつオープンではない

いまこそ彼らとその支援者を非難すべき時である

長期的にはOSSメンテナーに報酬も払わずにこのような要求を課すことは有害である

最近libxsltのメンテナーを辞任したが、このライブラリがふたたびメンテナンスされる可能性はほとんどない

Google Project Zeroという金で買える最高のセキュリティ研究者がボランティアの首根っこをひっつかんでいる現状では、その可能性はさらに低い

■ 8. 企業の責任への批判(2025年5月10日)

肝心な点はそもそもlibxml2はブラウザやOSクラスが使用できるレベルの品質を備えていなかったということである

Appleがlibxml2をOSのコアコンポーネントに導入したことが始まりだった

その後Googleも追随し、今ではMicrosoftでさえlibxml2を使用している

このようなことは決してあってはならないことだった

元々は成長のハックのようなものだったが、いまでは彼らは数十億ドルの利益を上げている

しかしより優れたソリューションへの切り替えや自主開発、libxml2の改善といったフィードバックはない

これらの企業の態度は無責任である

彼らはユーザのセキュリティやプライバシーなど気にもかけておらず、対症療法を行っているにすぎない

もうこのゲームには参加しない

彼らがlibxml2の使用をやめれば、このプロジェクトの健全性は向上する

■ 9. メンテナー退任(2025年8月15日)

libxml2のメンテナーを退任することにした

つまりこのプロジェクトは現在ほぼメンテナンスされていないということである

ここ最近libxml2を触っているのはNick Wellnhoferほぼ一人であり、彼が辞めるということはすなわちプロジェクトの放棄と同義である

libxsltについては最近Iván Chaveroが後任に名乗りを上げたが、contributionもまだまだといったところである

libxml2については今後どうなるか未知数である

■ 10. OpenSSFの実態

OpenSSFはオープンソースソフトウェアの開発・保守を持続的に行うことを推進する組織である

有名どころとしては協調的脆弱性開示プロセスの策定・推進などがある

協調的なビジョンを達成するためには最低でも年間1万ドルの課金を要求する

実際のOSS開発者に貢献が還元されることは特にない

■ 11. Google Project Zeroへの批判

協調的脆弱性開示プロセスはOSSメンテナーにタダ働きを行わせるための脅迫でしかないという主張である

実際問題としてGoogle Project Zeroはオープンソースが相手でも脆弱性の指摘しか行わず、脆弱性を修正したりパッチを作成したりすることはない

高い給料もらってるんだからパッチも書けよといった批判も多々上がる

批判の声:

「Googleが真剣にハッカー対策をしたいのであればパッチを送ったり資金援助したりするでしょう。彼らは単にCVEバッジを集めたいだけです」

■ 12. 現状と今後の展望

実は「放棄された」は言い過ぎで、現在は「メンテナがいない」状態であり、誰かが後任に立候補すれば開発は継続される

しかしメンテナになったところで報酬も利益もなく、負わされるのは時間と責任だけという損しかない立場である

そのような立場に好き好んで入り込むのはよほど風変わりな人しかいない

libxml2はあらゆるOSやブラウザや言語にまで入り込んでいる重大なライブラリである

そんな根幹の部分がこんなことになっている現状、今後のOSSはどこに向かっていくのか不透明である

MEMO:

あらまぁ
とはいえ、大手で使われているなら何処かがメンテを引き継ぐだろう（楽観論）
あるいは、新規機能の追加をせずセキュリティフィックスのみならAIに任せても良いのではないか？

(2025/11/19)

jmespath/go-jmespath: Golang implementation of JMESPath.

GitHub - jmespath/go-jmespath: Golang implementation of JMESPath.

MEMO:

JSONを宣言的にクエリ（検索・抽出・整形）するライブラリ
簡単なサンプル

package main

import (
    "encoding/json"
    "fmt"

    jmespath "github.com/jmespath/go-jmespath"
)

func main() {
    // 1. JSONデータを Goの interface{} に変換する
    jsonData := []byte(`
    {
        "users": [
            {"name": "Alice", "age": 30, "city": "Tokyo"},
            {"name": "Bob", "age": 25, "city": "Osaka"}
        ],
        "status": "ok"
    }
    `)

    var data interface{}
    if err := json.Unmarshal(jsonData, &data); err != nil {
        panic(err)
    }

    // 2. JMESPathクエリを実行する
    // クエリ: "users"配列から、各要素の "name" の値だけを抽出して配列にする
    query := "users[*].name"

    result, err := jmespath.Search(query, data)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }

    // 3. 結果を表示する
    // resultは interface{} 型で返される
    fmt.Printf("Query: %s\n", query)
    fmt.Printf("Result Type: %T\n", result)
    fmt.Printf("Result Value: %v\n", result) 
    // Output: Result Value: [Alice Bob]
}

簡単なフィルタならsamber/loを使った方がシンプルだろうか

(2025/11/19)

遂行力はどこで差がつくのか

遂行力はどこで差がつくのか｜ryottaman

要約:

■ 1. プロジェクトの文脈把握

着手前にプロジェクトの背景と意味を短時間で整理する

文脈の要素:

クライアントが達成したいこと

読者や顧客の置かれた状況

関係者が大切にしたい価値

タスクが全体で持つ役割

依頼内容が曖昧な場合でも「この案件は最終的に何をよしとするか」だけ先に確認する

文脈が整っているため判断にずれが生じない

■ 2. 完璧主義を避けた動的な進行

全てが揃わないと動けないタイプではない

動くことで目的の精度を上げていく手法を採用する

具体的な進め方:

最小限だけ整えてまず動く

仮の流れをつくって全体像を見る

動かす中で深掘りが必要な箇所を判断する

依頼者には要点だけ短く確認する

止めるのではなく進めながら整えるため、プロジェクトが滞らない

■ 3. 工程の事前設計

目の前のタスクだけでなく、その後に起きることを早い段階で組み立てる

設計される要素:

議事録の粒度や優先順位

記事や資料構成の作り方

誰の判断がどこで必要か

編集から校正、公開までの流れ

工程が設計されているため、その場の判断がほぼゼロになる

任せていても進行が乱れない理由はここにある

■ 4. 予定の先置きによるペース管理

期日を受け身で待つのではなく、自分から先に予定を決めて共有する

具体的な先置きの例:

「〇日午前にドラフト送りますね」

「午後に方向性だけ合わせましょう」

「その後は〇日までに進めます」

先置きによって関係者の動き方が決まり、全体のテンポが整う

気分や混雑に左右されないリズムが生まれる

■ 5. 初動の早さと周囲への配慮

外向的でも積極アピール型でもないが、仕事が前に進む

初動の早さが理由である

具体的な行動:

不明点は早めに依頼者へ確認する

途中段階をすぐ共有する

次の人が作業しやすい形で渡す

クライアントが判断しやすい状態を整える

初動が早いと相手の返答も早くなり、全体が前へ転がりやすくなる

■ 6. 原因帰属ではなく打ち手志向

プロジェクトが進まない理由を外部に置く言葉を使わない

使わない言葉:

「返事が遅いから進まない」

「条件が揃わないから無理」

「指示が曖昧だから止まってしまう」

使う言葉:

「ここだけ確認できれば進めます」

「一旦この形で前に出しておきますね」

「先に必要な材料を揃えておきます」

原因ではなく打ち手を見る姿勢が自然体の強さにつながっている

■ 7. 推進力の本質

推進力は説明の上手さや強い主張から生まれるものではない

推進力を構成する要素:

文脈をつかむ

動きながら目的を整える

工程を先に設計する

予定でリズムをつくる

初動を早くする

外に原因を置かない

この積み重ねがプロジェクトを止めない土台になる

自然体、素直、誠実という姿勢が信頼を生み、進め方が推進力を裏打ちする

推進力は勢いではなく「整える力」の総量で決まる

MEMO:

一般論の列挙という感じである

(2025/11/18)

仕様がそのままテストになる！Javaで始める振る舞い駆動開発

仕様がそのままテストになる！Javaで始める振る舞い駆動開発 - Speaker Deck

(2025/11/18)

【大刷新】PMBOK®の第8版がでた #プロジェクトマネジメント

【大刷新】PMBOK®の第8版がでた #プロジェクトマネジメント - Qiita

第7版の「原則」と第6版の「プロセス」が合体した

第6版「5つのプロセス群」が「フォーカスエリア」として復活し、「40のプロセス」として帰ってきた。が内容は7版ベース

各プロセスのInput/Output,ツール,技法(=ITTOs)など実務的な「統合版」になった

(2025/11/17)

新著が出ます：『NewSQL徹底入門』

新著が出ます：『NewSQL徹底入門』｜ミック

MEMO:

もう本書くことはないって言ってなかったか
新著が出ます：『達人に学ぶ SQL徹底指南書第2版』 - ミックのブログ

既存の書籍の改訂を除けば、おそらく本書が、私がRDBやSQLについて書く最後の本になると思います（そのあたりの事情については次回エントリで触れます）。

RDBの本ではないってことか

(2025/11/17)

fluent-bitでdocker composeのログを収集する

fluent-bitでdocker composeのログを収集する - doc.dev1x.org

MEMO:

docker composeで起動している全てのコンテナのログをfluent-bitで収集してコンテナ単位で処理するという普通にありそうなユースケースの情報がネットには転がっていなかったので調査した
fluent-bit開発元からはそういうのはkubernetisでやればいいじゃんという雰囲気を感じる
あるいはfluentロギングドライバ使えばいいじゃんとか
実際fluent-bitのDocker関連の機能は殆どがdeprecatedか廃止済み
古い情報が多くAIもハルシネーション多発で使い物にならなかった
コンテナログを直接tailするのはその方がロバスト性が高そうな気がしたから
fluentロギングドライバを使えばコンテナ名がタグに入るけど、その為にポート占有させるのもちょっと微妙な気がした

(2025/11/17)

令和時代の API 実装のベースプラクティスと CSRF 対策

令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io

要約:

■ 1. CSRF攻撃の成立条件

CSRF(Cross-Site Request Forgery)は古くから知られる攻撃手法である

攻撃者が用意したサイトに仕込まれたフォームから、ユーザがログイン中のサービスに対してリクエストを送信する攻撃である

ログイン済みのCookieが付与されたリクエストがサービスの投稿APIに準拠していれば、そのユーザのアカウントで不正な投稿が受理される

攻撃の手軽さと影響の大きさによって、XSSやSQLインジェクションと並ぶ有名な攻撃手法として認知された

従来の対策としては、One Time Token(CSRFトークン)をフォームに仕込み、トークンの一致によって投稿を受理する方法が一般的だった

■ 2. CSRF成立の本質的問題点

CSRF攻撃が成立する根本原因は「攻撃者のフォームからのリクエストにもサービスのCookieが付与される」点である

しかし、CSRFトークンが機能していた事実は「このリクエストはどこから来たものなのか」が分かれば対策できる証拠である

本来注目すべき欠落は「リクエストの出自がわからない」という点である

SameSite Cookieの導入によって別のサイトからのリクエストにCookieが付与されないようにすることは対策として成立するが、本質的な問題はリクエストの出自が不明であることである

■ 3. Originヘッダの付与

プラットフォームの回答は「リクエストにOriginヘッダを付与する」というものである

現在のブラウザでフォームをsubmitすると、送られるリクエストにOriginヘッダが付与される

Originヘッダの値を確認すれば、リクエストが正規のサイトからではないことを容易に判別できる

Cookieの有無に関わらず、サービスは「意図しないOriginからのリクエスト」を弾くことができる

このヘッダの必要性は少なくとも16年前から議論されており、7年前にFirefoxが実装することで全てのブラウザがフォームのsubmitにOriginヘッダを付与するようになった

SameSite Cookieが導入されるずっと以前から「リクエストの出自を知る」ことは可能であり、それを用いて攻撃リクエストを弾くことができた

fetch()を用いた実装でOriginを確認しながら適切なAccess-Control-Allow-Originを返していれば、「どこから来たかわからないリクエスト」を弾くことはずっと可能であった

■ 4. SameSite Cookieの副次的効果

SameSite Cookieの登場により、積極的な対策をしてこなかったサービスも受動的な変更によって保護される結果になった

しかしこれはかなり副次的な効果である

SameSite Cookieの本来の目的は3rd Party Cookieをマークすることであり、3rd Party Cookie Deprecateの終着点はSameSite=None Cookieが送られないようにすることである

CSRFは3rd Party Cookieよりも遥かに古くから問題だったが、「サイトを跨いだCookieが送られること」よりも「リクエストの出自がわからないこと」の方がプラットフォームが対策すべき問題とされていた

SameSite Laxがデフォルトになったことを理由に「Originのチェック」を怠った実装は、本質的な対策を怠った片手落ちの実装である

■ 5. CSRFトークンの必要性の再検討

OWASPのCSRF Cheat Sheetでは今でもトークンベースの対策が推奨されている

トークンベースの対策を推奨する理由として以下が挙げられる:

XSSがあった場合の対策

ヘッダを改変している可能性

GETでAPIがあると成立する攻撃

サブドメインが乗っ取られる攻撃

XSS問題の反論:

XSS自体を対策すべきであり、XSSによってDOMに展開されたCSRFトークンを盗めない道理はない

ヘッダ改変問題の反論:

ブラウザや拡張に脆弱性があれば、サービス側の対策はバイパスできるため、サービス提供者が想定すべき対策として視点がずれている

ユーザ設定やProxyが意図的にOriginヘッダを改変する環境は、ルールを守っていないためサービス側が許容する必要はない

GET API問題の反論:

様々な条件でSameSiteやOriginが機能しないリクエストを生成できるという指摘は、「APIがGETだった場合に攻撃が成立する」という条件に収束する

副作用のあるAPIをGETで提供している実装は前提として間違っている

サブドメイン攻撃の反論:

SameSite Cookieだけに依存した対策は問題があるため、一次防御は「リクエストのOriginのチェック」である必要がある

CSRFトークンの利点:

実装がこなれており堅牢である

フレームワークがデフォルトで提供することが多く、導入コストが低い

現状入っているなら積極的に外す理由はない

防御の認識の変更:

CSRFトークンは一層目の防御ではなく、多層防御の二層目であると認識すべきである

トークンを使用していても「リクエストの出自を確認する」実装は一層目にあるべきである

全ての場所でOriginを確認するのがプラクティスである

■ 6. Fetch Metadataの導入

本来は全てのリクエストにOriginをつけるべきだが、「OriginヘッダのあるリクエストはXHRからのもの」という前提の実装が蔓延していたため、ドラスティックな変更ができなかった

Originヘッダとは別にFetch Metadataが定義された

現在のブラウザでは以下のヘッダが付与される:

Sec-Fetch-Dest

Sec-Fetch-Mode

Sec-Fetch-Site

Sec-Fetch-User

リクエストの出自を確認する手法は整備されており、これらを無視することはプラットフォームが差し伸べている手を振り払うことと同じである

■ 7. 令和時代の実装プラクティス

副作用があるエンドポイントの実装における優先順位:

POSTにする(副作用のあるAPIをGETにしない)

Originを確認する

SameSite Lax/Strictを明示する

Fetch Metadataも確認する

Fetch Metadataのサポートに不安がある場合は「存在したら値をチェックする」実装でも良い

Sec-プレフィックスはJavaScriptから操作できないヘッダであるため、値がある場合だけのチェックでも意味がある

実装の特徴:

追加のストレージコストが不要である

コードだけで実装できるためレイテンシーが最小である

フレームワークのレールの基盤として存在することが望ましい

この実装から逸脱するコードが必要になった場合、プラットフォームが推奨するレールから外れていることを認識した上で、CORSなどの適切な対策をしながら拡張すべきである

このベースを伴わずにトークンを載せても片手落ちである

この実装をベースにしてもトークンがないと防げないCSRFが可能であれば、それはプラットフォームにおけるバグの可能性が高く、W3CのWebAppSecなどで議論すべき題材である

(2025/11/16)

みんなが管理職やりたがらないのでやる気満々の新卒2年目でも手を挙げれば管理職になれる現場になったが...

みんなが管理職やりたがらないのでやる気満々の新卒2年目でも手を挙げれば管理職になれる現場になったがトラブルが重なり逆に年齢制限ができた - Togetter

(2025/11/16)

乱雑なコードの整理から学ぶ設計の初歩

乱雑なコードの整理から学ぶ設計の初歩 - Speaker Deck

(2025/11/16)

次世代ソフトウェア開発：2030年までに標準となる20の革新的手法

次世代ソフトウェア開発：2030年までに標準となる20の革新的手法 | Forbes JAPAN 公式サイト（フォーブスジャパン）

(2025/11/16)

アーキテクチャと考える迷子にならない開発者テスト

アーキテクチャと考える迷子にならない開発者テスト - Speaker Deck

(2025/11/16)

旧から新へ: 大規模ウェブクローラの Perl から Go への移行

旧から新へ: 大規模ウェブクローラの Perl から Go への移行 / YAPC::Fukuoka 2025 - Speaker Deck

MEMO:

はてなアンテナってまだ稼働してたのか

(2025/11/15)

Should You Stop Using Prisma? Why Database ORMs Might Be the Worst Thing That Happened to...

Should You Stop Using Prisma? Why Database ORMs Might Be the Worst Thing That Happened to Backend Development | by Sohail Saifi | Medium

要約:

■ 1. Prismaの問題提起

3年間のPrisma本番運用後、パフォーマンス問題とサーバーレスコスト高騰を経験

データベースアクセスを容易にすると約束したツールが最大のボトルネックに

ORM全般の根本的問題:生産性と型安全性を約束したが複雑さとパフォーマンス問題をもたらした

■ 2. Prismaの魅力と落とし穴

魅力的なマーケティング:

型安全なデータベースアクセス

自動マイグレーション

SQLを書く必要がない

単一のスキーマファイルで全てを生成

クリーンで読みやすく型安全なコードに見えるが実際は問題だらけ

■ 3. パフォーマンスの現実

バンドルサイズ:

Drizzleは約1.5MB

Prismaは約6.5MB

サーバーレス環境では重大な影響

N+1問題の深刻化:

一見単純なクエリが実際には数十のデータベースラウンドトリップを生成

単一のJOINクエリであるべきものが47個の個別SQLステートメントを生成した事例

フロントエンドでTanStack Queryを使ってこの問題を回避したのにバックエンドでPrismaにより再現

■ 4. サーバーレスでの悪夢

AWS Lambdaのコールドスタートが200msから2.5秒に増加

Prismaが実行前に必要な処理:

Rustベースのクエリエンジンバイナリのロード

内部GraphQLサーバーの起動

コネクションプーリングの初期化

クライアントインターフェースの生成

Drizzleのような軽量ソリューションではサーバーレス関数のロードと実行がPrismaより遥かに高速

■ 5. 開発者体験の幻想

Prismaの最大のセールスポイントは開発者体験(DX)

実態:シンプルなことに対する優れたDXは複雑なことに対する酷いDXを意味する

スキーマロックイン:

全てがschema.prismaファイルを中心に回る

PrismaのDSLに収まらないことをする場合は困難

PostgreSQLのJSONB演算子などデータベース固有機能の使用が困難

複数テーブルの式(CTE)を含む複雑なクエリは生SQLに戻る必要があり、パラダイムを混在させ型安全性を失う

■ 6. コード生成の問題

スキーマを変更するたびにprisma generateを実行する必要

数千行のTypeScriptコードを再生成

IDEがフリーズし、ビルドプロセスが遅延

実行を忘れると型とデータベースが同期しなくなる

Drizzleではスキーマへの変更が即座に反映される(コード生成不要)

■ 7. マイグレーションの悪夢

デモでは素晴らしく見えるが本番では別の話

データ損失の設計:

カラム名変更時にPrismaは名前変更として検出せず、古いカラムを削除して新しいカラムを作成

そのカラムの全データが消失

Drizzleは名前変更の可能性を検出すると対話モードに入り意図を選択させる

ブラックボックス問題:

PrismaがSQLマイグレーションを生成するが手書きとは異なる

冗長で非効率な場合があり、レビューが困難

マイグレーションをカスタマイズする際はツールと戦うことになる

■ 8. 抽象化の真のコスト

Ted Newardは2008年にORMを「コンピュータサイエンスのベトナム戦争」と呼んだ

ORMはオブジェクト指向コードとリレーショナルデータベース間のインピーダンスミスマッチを排除すると約束

実際には排除せず隠蔽するだけ

抽象化がリークすると(常にリークする)、ORMの癖と生成されるSQLの両方を理解する必要があり、開始時より悪化

■ 9. 優れた代替案

Drizzle:

SQLを知っていればDrizzleを知っている

コード生成不要、バイナリ不要、魔法なし

パフォーマンスはPrismaより桁違いに高速

バンドルサイズ1.5MB対Prismaの6.5MB

型安全性を持つ生SQL:

RustのSQLxはコンパイル時チェック付きSQLクエリをランタイムオーバーヘッドゼロで実現

TypeScriptではKyselyが同様の利点を提供

生SQLの方が実際には優れているという動き:

より透明:どのクエリが実行されているか正確に分かる

より高パフォーマンス:抽象化オーバーヘッドがない

より移植性が高い:SQL知識がプロジェクト間で転用可能

より安全:インジェクションリスクを認識しているためより慎重になる

■ 10. セキュリティへの影響

ORMはSQLインジェクションを防ぐためより安全とされるが新しいセキュリティ問題を導入

マスアサインメント脆弱性:

リクエストボディに予期しないrole: 'admin'フィールドが含まれていると管理者ユーザーを作成してしまう

生SQLではどのフィールドを更新するか明示的に指定するためこのパターンは起こりにくい

過剰なデータベース権限:

ORMは機能するためにより広範なデータベース権限を必要とすることが多い

テーブルスキーマ情報のクエリ、メタデータへのアクセス、リフレクションの実行が必要

最小権限の原則に違反

■ 11. バンドルサイズ問題

2024年ではバンドルサイズが重要

AstroやSvelteKitのようなフレームワークは最小限のJavaScriptを強調

しかしバックエンドに6.5MBのORMを追加

エッジコンピューティングとサーバーレス関数では全てのキロバイトが重要

Cloudflareの無料プランは3MB制限でPrismaはビジネスロジックを1行も書く前にその半分以上を消費

■ 12. ORMが依然として意味を持つ場合

ラピッドプロトタイピング:何かを素早く動作させる必要がありパフォーマンスが重要でない場合

ジュニアチーム:チームに強力なSQLスキルがない場合、ORMはガードレールを提供

シンプルなCRUDアプリケーション:複雑な関係性のない基本的な作成・読取・更新・削除操作

エンタープライズ要件:一部の組織はコンプライアンスや標準化の理由でORMを義務付け

■ 13. 移行戦略

新機能から開始:全てを一度に書き直さず、選択した代替案で新機能を構築

パフォーマンスボトルネックの特定:プロファイリングを使用して最も遅いデータベース操作を見つける

ドメインごとに移行:アプリケーション内の境界付けられたコンテキストを選び、そのデータベースアクセスを全て一緒に移行

ツールへの投資:適切なデータベースマイグレーションツール、クエリビルダー、型生成をセットアップ

■ 14. 結論

Prismaから離れることでサーバーレスコストを40%削減、パフォーマンスを3倍改善、コードベースの保守性向上

データベースをより深く理解することを強制された

データベースを単なるストレージレイヤーとして扱うのをやめ、その力を活用し始めた

クエリがより効率的になり、データモデルがよりクリーンになり、デバッグセッションが短縮

ORMは複雑さを隠すことで生産性を高めると約束したが、実際には複雑さは隠されておらず、手遅れになるまで見えない場所に移動していただけ

データベースから隠れるのをやめ、受け入れ始める時かもしれない

MEMO:

そりゃそうやろという感想がある

(2025/11/14)

ニューレガシーアンチパターン

ニューレガシーアンチパターン - kawasima

(2025/11/13)

AI 時代のドキュメント管理術

AI 時代のドキュメント管理術 - Speaker Deck

(2025/11/13)

なんで最近の新しいテクノロジーはディストピアSF映画からのインスパイアみたいな感じなのか？

なんで最近の新しいテクノロジーはディストピアSF映画からのインスパイアみたいな感じなのか？ - YAMDAS現更新履歴

(2025/11/12)

チームを壊す「ブリリアントジャーク」とどう向き合うか―スクラムマスターとしての実践と学び―

チームを壊す「ブリリアントジャーク」とどう向き合うか―スクラムマスターとしての実践と学び―

要約:

■ 1. ブリリアントジャークの定義

優秀だが厄介な人を意味する

知識も技術も豊富だが他者への配慮や共感が欠ける

結果としてチーム全体の心理的安全性を壊す

アジャイル開発では透明性・協働・自己組織化が重要だがコミュニケーションを軽視する態度が続くとチームの信頼関係が崩れる

生産性だけでなくメンタル面にも悪影響を及ぼす

■ 2. 発生した状況

経験豊富で技術力の高いメンバーがいた

レビューの精度も高く幅広い知識を持っていた

一方で他のメンバーに対して厳しい言葉をかけることが多い

議論の場では自分の意見を強く主張する傾向

チーム内の変化:

チーム内で発言する人が減る

意見が対立すると議論が止まる

ミスを恐れて挑戦を避けるようになる

タスクの透明性が下がる

チーム全体の空気が重くなりスクラムイベントも形骸化

ブリリアントであるはずの存在がチームを静かに壊していった

■ 3. 初動の失敗

相手を理解しようと考えブリリアントジャーク本人との1on1やヒアリングを重ねた

結果的に問題の先送りに過ぎなかった

本人も悪気はない、相手に合わせればうまくいくかもしれないと考えて直接的な指摘を避けた

この判断はスクラムマスターとしての誤り

人間関係の摩擦として捉えチーム全体の心理的安全性という観点を見落とした

■ 4. 方針転換

チームのモチベーションが下がる中で方針を切り替えた

個人への歩み寄りではなくチーム全体を守るための行動を取ることに決定

具体的なステップ:

現状を客観的に整理:問題の発言や行動を具体的に記録し事実ベースで状況把握

関係者と情報共有:チーム外のマネジメント層や関係者に相談し客観的な視点で見てもらう

チームへのサポート:疲弊しているメンバーにフォローの時間を設け安心して意見を言える環境を再構築

チーム全体の合意を得ながら担当業務や役割を調整する形で体制を見直した

■ 5. 結果

体制変更後チームの雰囲気は驚くほど改善

改善の具体例:

ミーティングでの発言が増え議論が活発に

新しいアイデアや改善提案が出るようになる

チームの生産性が向上し遅れていたスケジュールを挽回

チームが協力して成果を出すというアジャイルの本質に立ち返ることができた

■ 6. 学びと教訓

個の能力よりチーム全体の健全性を守ることが最優先:

どれほど有能でもチームを壊す言動を放置してはいけない

成果を上げるのは個人ではなくチーム

問題は早期に毅然とした態度で対応する:

違和感を感じた段階で客観的に相談・共有することが大切

言いづらいから放置は最終的に全員の負担を増やす

心理的安全性をチーム文化として根付かせる:

誰もが意見を出せる環境を維持すること

その文化があればブリリアントジャークの影響は最小化できる

■ 7. 結論

ブリリアントジャークはどの現場にも潜むリスク

防ぐ方法は特別なものではない

透明性・信頼・早期対応の3つを意識し続けるだけでチームは崩壊を防げる

スクラムマスターの役割は課題を抱え込むことではなくチームの安全と健全性を守ること

ブリリアントな個人よりも協働するチームこそが最大の力を発揮する

MEMO:

なんか記事消えた

(2025/11/12)

さくらのクラウド、コンテナをサーバレスで実行する「AppRun」を正式サービスとして提供開始へ

さくらのクラウド、コンテナをサーバレスで実行する「AppRun」を正式サービスとして提供開始へ－ Publickey

MEMO:

おぉー

(2025/11/12)

kubernetes でケチケチ節約して複数のサイトを管理する

kubernetes でケチケチ節約して複数のサイトを管理する

MEMO:

kubernetesでやる必要性があるだろうか？
月間のコストはどれぐらいだろうか？
無料枠で収まる？
静的サイトなら適当なホスティングサービスを使えばよいのではないか？
などなど

(2025/11/12)

「丁寧で的確な引継ぎ」がめったに実践されない理由を解剖する【パウリ】

「丁寧で的確な引継ぎ」がめったに実践されない理由を解剖する【パウリ】 | レバテックラボ（レバテックLAB）

(2025/11/11)

「完全なコピーは現存しない」と言われていた52年前にベル研究所で作成されたUNIX V4を記録したテープ...

「完全なコピーは現存しない」と言われていた52年前にベル研究所で作成されたUNIX V4を記録したテープが倉庫で見つかる - GIGAZINE

(2025/11/11)

MIT、AI時代の新開発論を提唱。「可読性の高いソフトウェア」は

MIT、AI時代の新開発論を提唱。「可読性の高いソフトウェア」は"バイブコーディング"を終わらせるか | XenoSpectrum

要約:

■ 1. バイブコーディングの問題提起

大規模言語モデル(LLM)によるコード生成がソフトウェア開発の風景を一変させた

多くの開発者は雰囲気(vibe)に頼ったコーディングの危うさを感じ始めている

MITの研究チームが概念と同期という2つの要素を核とした新しいソフトウェア構造パターンを提案

人間とAI双方にとって可読性の高い(legible)ソフトウェアの実現を目指す

■ 2. 機能の断片化問題

現代のソフトウェアは内部構造が極めて複雑化

一つの機能(例:SNSアプリのシェアボタン)でもロジックが投稿、通知、ユーザー認証などコードベースの複数箇所に散らばる

MITのDaniel Jackson教授がこれを機能の断片化と呼び、システムの保守性や信頼性を著しく低下させる根源的課題と指摘

LLMの台頭によってこの問題がさらに深刻な形で顕在化

■ 3. AIコード生成の課題

GitHubの最新データではAIによるコード支援は普遍的となり開発効率を飛躍的に向上

プロセスはバイブコーディングと揶揄される

LLMは驚くべき速さでコードを生成するが既存システムとの相互作用や副作用を完全には理解していない

既存コードベースへの機能追加指示で意図しないモジュール変更や既存機能破壊が頻発

堅牢なコーディングに不可欠な3要件の欠如:

インクリメンタリティ(局所的変更で小さな改善を重ねる能力)

インテグリティ(既存機能を破壊しない能力)

トランスペアレンシー(変更内容や実行時動作が明確であること)

■ 4. 概念(Concepts)の定義

ユーザーが認識する機能の自己完結した単位

SNSアプリでは投稿、コメント、いいね、フォローといった個々の機能が独立した概念として定義

特徴:

自己完結性: 各概念は自身の状態と実行可能なアクションを保持

独立性: 概念同士が直接的な依存関係を持たない

特定機能の修正・拡張時に他機能のコードを気にする必要がない

マイクロサービスと類似するが決定的な違いは概念が互いに完全分離されている点

マイクロサービスは相互にAPI呼び出しでもつれたクモの巣のような依存関係を生み出しがち

■ 5. 同期(Synchronizations)の役割

独立した概念間の相互作用を記述するための宣言的なイベントベースのルールセット

複雑な手続き型コードではなく「何が起きたら何をするか」というルールを定義

記述例:

ユーザーAが投稿Pにコメント実行時(when)

投稿Pの作者がユーザーBならば(where)

通知概念の送信アクションをユーザーBに対して実行(then)

ドメイン特化言語(DSL)を用いてシンプルかつ明確に記述

宣言的性質によりルールセット全体の見通しが向上

LLMによる自動生成や形式的検証も容易

■ 6. AIとの相性の良さ

LLMに与えるコンテキストを限定可能:

概念のコード生成時はその概念の仕様のみに集中すればよい

アプリケーション全体の複雑さを考慮不要

同期ルール生成時も各概念のインターフェース仕様の理解で足りる

LLMへの指示(プロンプト)がシンプルになり生成コードの精度と信頼性が劇的に向上

■ 7. バグ修正事例

問題: ユーザー登録フローで不正パスワード試行後に正しいパスワードで再試行すると「ユーザーが既に存在する」エラーが発生

新モデルでの解決プロセス:

問題が発生した一連の処理(フロー)を特定

そのフローに関連する同期ルール群を抽出

抽出したルール群と問題概要をLLMに提示し修正方法を問う

LLMの回答:

パスワード検証前にユーザー作成が行われていることが原因と特定

まずパスワード検証し成功時のみユーザー作成という修正案を新しい同期ルールとして提示

システム動作が明示的ルールとして記述されているからこそ可能な人間とAIの理想的協調作業

■ 8. 実証実験の成果

RealWorldベンチマークアプリケーション(Mediumのようなブログプラットフォーム)のバックエンドを実装

従来実装では複数サービスやモジュールにまたがっていたお気に入り登録やタグ付け機能が単一の概念として明確にカプセル化

システムの可読性と保守性が大幅に向上

LLMを用いた各概念の仕様書・コード・同期ルール生成プロセスもほぼ成功

提案モデルが理論上のものではなく実用的な開発手法として機能することを証明

■ 9. 専門家の評価

バージニア大学Kevin Sullivan准教授の評価:

人間の理解に基づいた抽象化である概念の上にソフトウェアを構築することを主張

ソフトウェア設計の理論と実践における新しく重要な方向性

■ 10. 将来展望

Jackson教授が描く未来像:

再利用可能な概念を集めたライブラリであるコンセプトカタログの構築

コンセプトは新しい種類の高レベルプログラミング言語になる可能性

シンクロナイゼーションはその言語で書かれたプログラムになる可能性

開発の変化:

ゼロからコード記述ではなく検証済みの概念をカタログから選択

それらをどのように連携させるかという同期ルールの記述に集中

開発がより創造的で本質的なものになる

曖昧な雰囲気ではなく明確な構造と対話により人間とAIが共に未来のソフトウェアを築く知的で冷静な設計図

(2025/11/10)

開発者が知っておきたい複雑さの正体/where-the-complexity-comes-from

開発者が知っておきたい複雑さの正体/where-the-complexity-comes-from - Speaker Deck

(2025/11/10)

組織もソフトウェアも難しく考えない、もっとシンプルな考え方で設計する

組織もソフトウェアも難しく考えない、もっとシンプルな考え方で設計する #phpconfuk - Speaker Deck

(2025/11/10)

例外処理を理解して、設計段階からエラーを見つけやすく、起こりにくく

例外処理を理解して、設計段階からエラーを見つけやすく、起こりにくく #phpconfuk - Speaker Deck

(2025/11/10)

品質は設計でつくり込む / design in quality

品質は設計でつくり込む / design in quality - Speaker Deck

(2025/11/09)

カジュアル面談を成功させる秘訣

カジュアル面談を成功させる秘訣｜nekokak

(2025/11/09)

シンプルは作れる！イミュータブルデータモデルの真髄

シンプルは作れる！イミュータブルデータモデルの真髄 - kawasima

(2025/11/09)

JJUG CCC 2025 Spring：エンジニアリングでビジネスを加速する。モデル駆動開発という選択肢

JJUG CCC 2025 Spring：エンジニアリングでビジネスを加速する。モデル駆動開発という選択肢 | ドクセル

(2025/11/09)

AIと共に進化する開発手法：形式手法と関数型プログラミングの可能性

AIと共に進化する開発手法：形式手法と関数型プログラミングの可能性 - Speaker Deck

(2025/11/09)

ドメインモデリングにおける抽象の役割、tagless-finalによるDSL構築、そして型安全な最適化

ドメインモデリングにおける抽象の役割、tagless-finalによるDSL構築、そして型安全な最適化 - Speaker Deck

(2025/11/09)

Jupyterよりも marimoが使いやすい理由

Jupyterよりも marimoが使いやすい理由

最近marimoを触ってみたんですが、これが思った以上に便利でびっくりしました。

このツールだけで完結できる場面が多くて、しかもUIがリアルタイムに反応してくれるので、作っていてすごく楽しいんです🎶

驚くほど簡単で直感的に使えますし、「試してみたい！」と気持ちがどんどん湧いてきました。

というわけで、この記事ではそんなmarimoの魅力や、基本的な使い方について紹介していきたいと思います。

ちょっとでも「面白そう」と思ってもらえたら嬉しいです。

(2025/11/09)

ory/hydra -- Go言語製のOpenID認証基盤

GitHub - ory/hydra: The only web-scale, fully customizable OpenID Certified™ OpenID Connect and OAuth2 Provider in the world. Become an OpenID Connect and OAuth2 Provider over night. Written in Go, cloud native, headless, API-first. Available as a service on Ory Network and for self-hosters. Relied upon by OpenAI and others for web-scale security.

Ory Hydraは、低レイテンシ、高スループット、低リソース消費に最適化され、OpenID認定の堅牢なOAuth 2.0サーバーおよびOpenID Connectプロバイダーです。Ory Hydraはアイデンティティプロバイダー（ユーザーサインアップ、ユーザーログイン、パスワードリセットフロー）ではなく、ログインおよび同意アプリを介して既存のアイデンティティプロバイダーに接続します。ログインおよび同意アプリを異なる言語で実装することも容易で、一般的な言語向けのサンプル同意アプリ（Node.js）とSDKが提供されています。

Ory Hydraは、アイデンティティサーバーとしてOry Kratosを使用できます。

(2025/11/09)

marimo | a next-generation Python notebook

marimo | a next-generation Python notebook

MEMO:

次世代のPythonノートブック環境を提供するオープンソースプロジェクト
Jupyterノートブックの代替プロダクト
ノートブックがPythonファイルとして出力されるのでバージョン管理が簡単らしい
つい最近（2025/10/30）、CoreWeaveに買収されたのでプロジェクトの将来性も有望の模様

(2025/11/09)

インターネットアーカイブの創設者が「我々は生き残ったが、ライブラリは壊滅した」と語る

インターネットアーカイブの創設者が「我々は生き残ったが、ライブラリは壊滅した」と語る - GIGAZINE

要約:

■ 1. インターネットアーカイブの到達点と記念行事

2025年10月までに保存したウェブページ数が1兆件に到達

記念イベント「The Web We've Built」を2025年10月22日に開催

サンフランシスコ市議会が同日を「インターネットアーカイブの日」に認定

30年近くサンフランシスコに拠点を置き1兆ページ超のウェブを保存した功績が評価された

■ 2. インターネットアーカイブの重要性

スタンフォード大学研究者の見解:

過去が常に現在を形作るためウェブページ保存が重要

過去は現在が今のままである必要がないことを教える

次のフェーズ:

3D環境やオンラインゲームなどデジタル構築体験の保存方法を模索

■ 3. National Emergency Libraryをめぐる訴訟

2020年3月にコロナ禍対応として140万冊のデジタル書籍を提供開始

インターネットアーカイブはフェアユースと主張したが出版社が著作権侵害として提訴

敗訴により50万冊の書籍が貸出リストから削除された

プロジェクトの目的:

Wikipediaが書籍スキャン画像にリンクできるようにする

研究者の電子書籍参照を容易にする

創設者ケール氏の批判:

数十億ドル規模の巨大メディアコングロマリットが情報の流れをコントロールすることに独自の利益を持つ

Wikipediaの読者が書籍にアクセスできないようにすることに成功した

■ 4. Great 78プロジェクトをめぐる訴訟

数十万枚のレコードをデジタル化してオンライン上で保存・公開

2025年4月に音楽レーベルから6億9300万ドル(約990億円)の賠償金請求

2025年10月に非公開条件で和解が成立

■ 5. 訴訟後の現状と評価

2025年10月時点で大規模な訴訟やコレクションへの脅威には直面していない

ケール氏のコメント:

生き延びたがライブラリの一部は消滅した

再建と再定義の段階に入っている

法廷闘争の本質:

クリエイターや出版者ではなく大手メディア企業との争い

著作権による制限に満足せず、それ以上を望む企業との対立

企業はWayback Machineの終焉を望んでいたと推測

■ 6. 図書館の役割に関する議論

著作権弁護士コートニー氏の主張:

図書館がHuluやNetflixになることを望んでいない

文化の保存と知識への平等なアクセス提供という役割を果たしたい

遠隔アクセスは高齢者、障害者、地方住民、海外派遣時に有益

著作権弁護士バトラー氏の指摘:

他の図書館も重要な法廷闘争に直面

出版者の高額訴訟の恐れから保存のためのデジタル化が遅延する可能性

訴訟は誰が文化的記録を保存できるのかという社会的課題を浮き彫りにした

■ 7. 今後の展開と懸念

Democracies Libraryプロジェクトの拡大:

世界中の政府の研究と出版物を収録した無料オープンなオンライン集成

Wikipediaとリンクして研究者の情報アクセスを向上

AI発展による懸念:

AI企業がクリエイターや出版者から多数の訴訟を提起されている

企業による情報への支配力が高まる傾向

アーカイブプロジェクトが多方面からの攻撃に耐えられるか不透明

■ 8. ケール氏の提案

著作権法の再構築を提唱:

著者、出版者、書店が十分な報酬を得る

図書館の使命が尊重される

進歩が促進される

多くの勝者がいるゲームの実現を目指す

誰もが読者になるために多くの出版社、販売業者、書店、図書館が必要

(2025/11/09)

「Mozilla/Firefoxの日本語コミュニティ解散」とかいうDramaについて知っておくべき2,3のこと

「Mozilla/Firefoxの日本語コミュニティ解散」とかいうDramaについて知っておくべき2,3のこと

免責事項: めんどくさいからほぼ調べずに書くし、抜けてる話や間違ってる話もあると思う。

■ まず日本語コミュニティの解散じゃなくてSUMO翻訳コミュニティの解散なのだがそれも少し違う

Mozilla系の日本語翻訳はmarsfさんとdskmoriさんの2人がメインでやってる。

概ねSUMOはdskmoriその他全てがmarsfという棲み分けだが、お互いどっちの貢献もやることがある。

コミュニティと言えるような規模は存在しない。限界集落。

SUMOコミュニティ解散ってのはSUMOに関わる実質的な権限持ちはdskmori１人になりますって話かな？

正直、SUMOでメインで貢献してるdskmoriさんじゃなくてmarsfさんが文句言うんや？と疑問なんだけど、

Mozillaにとっては、SUMOとかいう誰もアクセスしてない限界集落サイトの話より、marsfさんがFirefoxのその他すべての翻訳を一手で担ってることが重要だよね。

「marsfさんがSUMOの貢献辞める」って言ったってそれ自体ではどうでも良いのだが、裏の意味は「俺の気持ち次第でFirefoxの翻訳終わらすことだってできるんだぞ」って警告と読むべきかもしれない。

■ そもそもSUMOがなにか分かってない人多すぎ

SUMOはFirefoxのサポートサイトね。Firefoxの使い方に疑問が生じたときにみるところ。まあそういう用途で作られているというだけで、アクセスする人がいるのかいたって疑問だが。

想定読者は技術に疎いFirefoxユーザなので、「機械翻訳ならユーザーが自分でやるから不要」みたいな意見は全くナンセンス。

Firefoxの内蔵翻訳機能はプライバシー重視という建前の翻訳API破産防止のため、ローカルのCPUで動く設計になってる。必然的にMicrosoftやGoogleの翻訳より精度がかなり落ちる。ゆえにFirefox使って普通に英語版SUMO読むより、公式で精度よい機械翻訳提供したほうが、ずっと良い体験を提供できるよね。

また対抗をGoogle翻訳のような無料クラウド翻訳と考えるとしても、サポートサイトに特化するようファインチューニングした機械翻訳エンジンを使えばHelpを助けてと訳すような暴走も抑制できるから、これも公式による機械翻訳提供に優位性はある。

なお、統計上アドオン一切入れてないFirefoxユーザーが大多数なことからわかるように技術に疎いFirefoxユーザってかなり多いからね。

■ 勝手に上書きするな？　メンテできてないんだから当たり前

Firefoxはラピッドリリースで機能がコロコロ変わるので、ある時点でベストな翻訳になっててもすぐ時代遅れになる。

dskmoriさんなどができる範囲で貢献してたとはいえ、品質維持できる量ではなかったので、SUMOには、例えばすでに存在しない機能についての記述を含む記事が普通にあった。

これは比較的アクセスありそうな重要ページでも同じで、私もさすがに見かねて貢献したこともある。

Microsoftのプロ技術者向けサイトはもともと有償の翻訳者が訳してたのを機械翻訳に切り替えたのでこれは単純に劣化なのだが、SUMOについてはごく少数の素人が自分にできる範囲で訳していたという点を踏まえる必要がある。もともとクオリティが高かったとは言えないし、機械翻訳の精度もここ2,3年で異常に上がってるから過去の機械翻訳騒動をもとに騒ぐのが正しいとも思えない。

■ 限界OSS翻訳コミュニティの最後の１人が暴走するのは見覚えあるよね

今回の事件で思い出すのがLibreOffice日本語チームのDramaね。LibreOfficeの翻訳のメイン貢献者の某氏がある日、日本語チームのメーリスで「何でお前らはまともな仕事ができんのんや」と長文でブチ切れて、チーム脱退を宣言した事件。理念は立派でもすでに敗北の流れは決定的で新たな貢献者の望みは薄い、希望の見えないまま最後に残った１人として惰性で維持するしかない、辛い。

今回は、LibreOfficeの事件よりはヤバさだいぶ低めだけど、「翻訳ガイドラインに従っていない」「新たな人間の貢献者を育てることができない」とか、SUMOボランティア翻訳の実情を思えば「何言ってんだ、現実をみろよ」という感想にしかならないし、CCライセンスで貢献してるのに、AI翻訳の学習に使うなも意味不明。

marsfさんは、某xkcdで言うところの「感謝なしに2003年からデジタルインフラを維持してきたネブラスカ州の無名個人」に位置する人で、もっともっと感謝されてしかるべきではあるのだが、SUMOの長年の構造的な問題に対し抜本的な解決に打って出たMozillaに対して、さもコミュニティが現在も十分に機能しているかのように反論してるのがとても印象悪い。どう見ても分かってない人ばかりがMozillaを炎上させている。

20年感謝なしに維持し続けるのは幻想が必要なのはわかるが、Mozillaとしてはそういう個人に依存するのは不健全でしかないので、現在marsfさんがやっているFirefoxほぼすべての翻訳も翻訳会社による有償翻訳に移行すべき。

機械翻訳が「人手の作業を大量破壊」　Mozilla日本語コミュニティが解散宣言　人力訳を上書き

機械翻訳が「人手の作業を大量破壊」　Mozilla日本語コミュニティが解散宣言　人力訳を上書き - ITmedia NEWS

「Firefox」をはじめとしてMozilla製品のサポートページの日本語化に尽力してきたコミュニティ「SUMO Japanese community」が11月4日、活動の終了を宣言した。

Mozillaが10月22日、機械翻訳「Sumo Bot」を日本語記事に導入し、手作業で翻訳した記事をの上書き翻訳を無断で行っているため。コミュニティリーダーであるmarsf氏はこれが「私たちの作業の大量破壊」に当たるとし、コミュニティとしての活動終了を宣言した。

marsf氏によるとSumo Botの翻訳は、翻訳ガイドラインに従わず、日本語ユーザー向けのローカライズ表現を無視したまま既存の翻訳を上書き。300以上のナレッジベースが上書きされたという。

また、コミュニティへの連絡や合意がないまま製品版サーバで上書きしており、更新後72時間で自動承認されるため、新しい翻訳者に翻訳させ、チェックするといった育成の機会も奪っていると指摘している。

marsf氏はこれを「私たちの作業の大量破壊」と批判。個人として「support.mozilla.orgへの貢献を停止する」と宣言した。また、同氏の翻訳がSuMo BotやAIの学習データとして使用われることを拒否し、既に学習された私の翻訳データを削除することを要求している。

ただ、「日本の個々のコントリビューターが自分の責任において活動を続けることは自由」とも述べている。

なぜアーキチームは設計や実装のパターンを絞りたいか？背景にある思考と技術選定のジレンマ

なぜアーキチームは設計や実装のパターンを絞りたいか？背景にある思考と技術選定のジレンマ | フューチャー技術ブログ

要約:

■ 1. 設計・実装パターンを絞る理由

全体最適と局所最適:

レビュイーは目の前のタスクの最速完了を重視

レビュワーはプロジェクト全体の長期的な健全性を重視

コードベース全体の一貫性維持:

新規メンバーの学習コスト削減

横断的な修正作業時の調査漏れリスク軽減

予測可能性の確保

開発者の設計余地の削減と均質化:

手法選択の迷いを排除しレビュー時の衝突を回避

チーム成熟度が低い場合の誤った選択を防止

プロジェクト遅延リスクの軽減

ライブラリやサービス追加による管理コスト削減:

学習コスト、バージョンアップ、脆弱性対応の追加作業を抑制

引き継ぎやドキュメント作成の手間を最小化

■ 2. 統制のメリットとデメリット

メリット:

品質の担保

認知負荷の低減

保守性の向上

デメリット:

モチベーション低下(特に若手)

開発速度の低下

変化への対応の遅れ

統制と裁量のバランスは状況に応じて変化し、プロジェクトフェーズで方針が変わることもある

■ 3. プロジェクト特性による統制レベルの違い

開発速度最優先の場合:

新規事業のプロダクト開発では自由度を高める

セキュリティとコンプライアンスのみチェックし、腕利き開発者のセンスに任せる

プロジェクト初期:

不確実性が高い段階では自由度を高める

成熟期:

ユーザー増加と安定性重視の段階で統制を強化

保守運用を見据えた細かい処理方式の指摘を実施

■ 4. 開発ガイドラインの課題

後手に回る理由:

ガイドラインを書いても読まれない傾向

記載量が多いと読解困難で記憶不可能

メンテナンスコストの増大

実効性確保の方針:

現場感が強い内容のみを記載

フォーマッターやリンターの整備が必須

カスタムルールを適用するツールの開発

AIレビュー導入により、ガイドライン記載内容を増やせる可能性がある

■ 5. 統制を強める基準

チーム規模による判断:

5人程度: 阿吽の呼吸で運用可能

10-15人超: 統制が必要

15-50人: 専門家による統制

50-150人: 強いトップダウンのルールが不可欠

技術レベルによる判断:

小規模×熟練メンバー: 見守りモード

小規模×ジュニア中心: 指導・規範の整備

大規模×ジュニア中心: 統制を強める

大規模×熟練メンバー: 維持困難(メンバー入れ替わりは必然)

運用時の最も弱い体制を見据えた技術選定が必要

■ 6. アーキテクトの成長と価値創出

枯れた技術採用のジレンマ:

大規模案件ほど枯れた技術を採用しがち

リスクを受け入れてモダンな技術にチャレンジする判断も必要

成長の楽しみの見出し方:

仕組み化によるプロジェクトライフサイクル全体の開発継続性確保

開発生産性技術セットの習得(CI/CDパイプライン、Git開発フロー)

実績を詰めれば大規模案件でもモダン技術を採用しやすくなり、ノウハウは小中規模案件にも還流する

■ 7. コミュニケーションと判断基準の明確化

判断基準と理由の伝達:

指摘とWhy(理由)をセットで伝える

ADRや開発ガイドラインで設計決定を記録

後出しの場合は謝罪し、ルールが必要になった背景を説明

納得感と一貫性が信頼関係構築に不可欠

■ 8. 視座の違いによる技術選定

プロジェクト視点:

所属プロジェクトの円滑な推進に注力

複数プロジェクト・部門視点:

ノウハウ共有とメンバー流動性確保のため非差別化領域の標準化

全社視点:

セキュリティ、コンプライアンス、人材育成コストの最適化

技術広報・採用広報との連動

Webフレームワーク、DBアクセスライブラリ、ログライブラリなど利用頻度が高いライブラリは全社・部門レベルで統一することが望ましい

アーキテクチャに個性は不要で妥当性が重要

■ 9. まとめ

アーキテクトは短期的な開発速度と長期的な引き継ぎコストのジレンマでバランスを取る

スイートスポットはチーム規模と技術力に依存し常に変化する

新技術導入時は全体を見通して既存修正や開発規約修正まで行うべきかを検討

現場の現実と全体最適の視点の両立が建設的な議論の前提

(2025/11/07)

AI が来て自分が壊れそうになった話

AI が来て自分が壊れそうになった話｜牛尾　剛

(2025/11/07)

RISC-Vの命令セットがISO/IEC JTC1による国際標準化に着手へ。第一歩として公開仕様提出者の承認を受ける

RISC-Vの命令セットがISO/IEC JTC1による国際標準化に着手へ。第一歩として公開仕様提出者の承認を受ける－ Publickey

RISC-V（リスクファイブ）は、クリエイティブコモンズとして公開され、誰でも無料で利用可能なプロセッサの命令セットです。近年ではx86やArmに次ぐ命令セットとして注目度が高まっています。

RISC-Vを主導する団体RISC-V Internationalは、このRISC-Vの命令セットがISO/IEC JTC1による国際標準化の第一歩としてPAS（Publicly Available Specification）提出者の承認を受けたことを明らかにしました。

RISC-V Internationalは、RISC-Vの命令セットはすでに業界標準になっているとし、次のステップは公正な見地として信頼できる国際機関からの承認だとして、国際標準化機構（ISO）と国際電気標準会議（IEC）の合同技術委員会（JTC 1）による国際標準化へと進もうとしています。

今回、その第一歩として、JTC 1 PASの提出者の承認を受けたわけです。

国際標準化を重視する背景には、例えばIEEE 802.11で標準化されているWi-Fiのように、業界が合意した一連のルールとフォーマットとして標準化されることで複数のメーカーの異なる製品であっても確実に連携することが保証されるからだと説明されています。

これにより複数の製品の連携や統合が容易であり、コストが削減され、拡張と拡張が容易になるわけです。

また、命令セットが国際標準になった場合、その標準をサポートすると宣言した企業や組織は、ハードウェア製品などが標準を満たしていることを宣言できる利点もあるとしました。

そのため、RISC-V命令セットを国際標準にすることは相互運用性を促進し、オープンコンピューティングの将来の基盤としてのRISC-Vの役割を強固にするのだとRISC-V Internationalは説明しています。

(2025/11/06)

「Ubuntu 26.04」の戦略と新機能--Canonical幹部が語る「Linux」デスクトップの未来

「Ubuntu 26.04」の戦略と新機能--Canonical幹部が語る「Linux」デスクトップの未来 - ZDNET Japan

要約:

■ 1. Ubuntu 26.04 LTSの全体的ビジョン

ロンドンのCanonical本社で開催された「Ubuntu Summit 25.10」において、創設者兼CEOのMark Shuttleworth氏とエンジニアリング担当バイスプレジデントのJon Seager氏が次期長期サポートリリース「Ubuntu 26.04 LTS」(「Resolute Raccoon」)のビジョンと計画について説明した

重点領域: メモリー安全性を確保した基盤ユーティリティー、自動化の強化、コミュニティー中心のドキュメント、デスクトップとクラウド向けに最適化されたセキュリティ機能

■ 2. Shuttleworth氏のオープンソースへの信念

Shuttleworth氏は自身がオープンソースの真の信奉者であると語った

Canonicalの使命: ユーザーがあらゆる領域でオープンソースを利用できるようにする企業である

提供形態: クラウドでオープンソースを使いたいならクラウド向け製品を、小型デバイスで利用したいならそのような製品も提供する

■ 3. Linuxデスクトップの断片化問題

Shuttleworth氏はデスクトップLinuxの断片化が深刻な問題であると認識している

「Linuxを真のグローバルな選択肢にしたいなら、実効性の高い取り組みを実施する必要があり、足を引っ張り合っている場合ではない」と述べた

皮肉なことに、失敗に終わったCanonicalのデスクトップ「Unity」への取り組みによって、同社の収益性がかつてないほど高まった

理由: その失敗のために、サーバー、クラウド、モノのインターネット(IoT)製品に注力せざるを得なくなったから

■ 4. Linuxデスクトップの可能性

Shuttleworth氏はLinuxデスクトップの可能性を信じなくなったわけではない

「デスクトップにおけるオープンソースの勝利に貢献したい」と語った

Ubuntu 26.04はデフォルトのデスクトップ環境として引き続き「GNOME」を採用している

System76の評価: 米国のLinux PCメーカーであるSystem76と同社の新しい「Rust」ベースのデスクトップ「COSMIC」を高く評価しており、実際にSystem76はUbuntu SummitでCOSMICに関するセッションを開催した

課題認識: 「オープンソースコミュニティーは、エンジニアではない人向けのデスクトップの開発が別物であることを理解する必要がある。『シンプルできちんと機能する』ことも非常に重要であることを理解しなければならない」

■ 5. 開発方針の根本的見直し

2月にSeager氏が新任として、CanonicalとUbuntu開発チームによる今後の新しいUbuntu開発の方針を示した

目標: コミュニケーション、自動化、プロセス、モダナイゼーションに関するエンジニアリングの慣習を根本的に見直すこと

Canonicalは2026年以降、ドキュメントとコミュニケーションのチャネルを統合することで、より透明性が高く理解しやすいコミュニティー主導のUbuntuビルドプロセスを確立し、新しいコントリビューターが参加しやすい体制を目指している

■ 6. コミュニケーション基盤の統合

「Ubuntu Community Matrix」サーバーをベースとする「Matrix」インスタントメッセージングが、Ubuntu開発者の主要なコミュニケーションシステムとなる

Canonicalはユーザー向けと開発者向けのドキュメントの統合にも取り組んでいる

Seager氏の認識: 「ドキュメントは重要なコミュニケーション手段」であり、二の次にすべきではない

現状の問題: 多くのドキュメントがさまざまなプラットフォームに分散し、内容の重複や矛盾があるほか、単純に見つけにくい場合がある

今後: 利用しやすく正確な形に統合される

■ 7. ビルドシステムの自動化とモダナイゼーション

Canonicalはディストリビューションとパッケージの両方のビルドシステムの自動化に注力している

目標: エラーが発生しやすく退屈だが手間のかかるプロセスから、現代的な開発ツールを使用した高度な自動化システムへ移行する

Seager氏の説明: 「可能な限り多くのプロセスを自動化する(それによって全体の能力を高める)だけでなく、プロセスをできるだけ簡素化することを目指す」

現状の課題: Ubuntuのビルドプロセスの多くは確かに自動化されているが、それらのシステムは統一されておらず、多くの場合、経験豊富なコントリビューター以外には分かりにくい

改善策: それらを一貫性のある開発パイプラインに統合することで、ビルドシステム全体が改善される

■ 8. Temporalの採用

同社は永続的なオーケストレーションを実現する「Temporal」などのツールを採用して、プロジェクトのワークフローの合理化やモダナイゼーションを進めている

Seager氏の評価: 「Temporalは基本的に、分散システムエンジニアがいないUbuntu組織でも非常に複雑な分散システムを構築できるツールだと考えている」

目標: 十分に文書化されピアレビューを経たプロセスを活用して、ボトルネックと属人的な知識への過度な依存を軽減することで、コントリビューターが活躍できる環境を整え、規模の拡大に対応する

■ 9. Rust言語の採用によるメモリー安全性の向上

Ubuntuはメモリー安全性の高いRust言語を採用している

エンジニアリングチームはUbuntu 25.10から、主要なシステムコンポーネントをRustベースのコンポーネントに置き換えて、安全性とレジリエンスの向上に力を入れている

Seager氏の強調点: 性能だけでなく、レジリエンスとメモリー安全性が主な推進力である。「Rustへの移植によってレジリエンスと安全性の向上を簡単に実現できる。私が最も魅力を感じるのはこの点だ」

sudo-rsの採用: Ubuntuは「sudo」のRust実装である「sudo-rs」を採用しており、フォールバックとオプトアウトの仕組みがあり、従来のsudoコマンドも使用できるようになっている

■ 10. uutils/coreutilsの採用

Ubuntu 26.04では、sudo-rsに加えて、LinuxのデフォルトのコアユーティリティーとしてRustベースの「uutils/coreutils」が採用される

内容: ls、cp、mvなど、多数の基本的なUNIXコマンドラインツールが含まれる

狙い: このRust再実装の狙いは「GNU coreutils」と同等の機能を実現しつつ、安全性と保守性の向上を図ること

■ 11. TPMによるフルディスク暗号化

デスクトップ関連の変化として、Ubuntu 26.04で「Trusted Platform Module」(TPM)によるシームレスなフルディスク暗号化が導入される

この機能は「Windows」の「BitLocker」や「macOS」の「FileVault」に相当するものである

■ 12. Snapアプリケーションのpermissions prompting

Ubuntu 26.04では、「Snap」ベースのアプリケーションに「permissions prompting」が搭載される

これはデスクトップアプリ向けのきめ細かな権限管理フレームワークである

目的: コンテナー型の強力なセキュリティと、ユーザー主導による事前の承認を組み合わせる

現状の問題: Snapの機能の1つにサンドボックスがあるが、使っていてイライラすることもある。何かを実行しようとしてサンドボックスにブロックされると、アプリがクラッシュする場合や本来の処理が実行されない場合がある

改善内容: プロンプトに「Firefoxがダウンロードディレクトリーへのアクセスを求めています。許可しますか」といった内容が表示されるようになる

開発状況: このフレームワークはまだ完成していない。この取り組みでは「カーネル、『AppArmor』(Linuxのセキュリティプログラム)、Snap、デスクトップクライアントに至るまで、非常に大掛かりな作業」が必要である

見通し: 全てが順調に進めば、Ubuntu 26.04のリリースまでにはpermissions promptingが完成している

■ 13. 最新コンポーネントの採用方針

Ubuntu 26.04では再び「最新バージョンのGNOME(おそらく『GNOME 48』)と最新のカーネル」を採用し、最新のベースコンポーネントを提供するという伝統を踏襲する

この方針のために、LTS版ではないLinuxカーネルをサポートする必要が生じたとしても、Canonicalはそうする

■ 14. Flutterベースアプリの拡大

新しいUbuntuでは、より多くの「Flutter」ベースアプリが使われることになる

Flutterはオープンソースのプログラミング言語「Dart」を使用するGoogleのプラットフォームである

利点: 開発者はFlutterを使用することで、ほぼ全てのプラットフォーム向けのマルチOSアプリを1つのコードベースから作成できる

Ubuntu 26.04での適用範囲: この機能にUbuntuのアプリストア、インストーラー、「セキュリティセンター」が含まれる

(2025/11/05)

スタンフォード大学とAnthropicが、AIの安全機能は簡単に無力化できることが証明する論文を発表...

スタンフォード大学とAnthropicが、AIの安全機能は簡単に無力化できることが証明する論文を発表しました。

最大99%の成功率でAIを操り、有害な応答を引き出す手法です。

僕も実際に試しましたが、かなり簡単です。

ということで、この巧妙な手口と衝撃的な結果をまとめました。

1. 巧妙な手口まず無害だが絶対に解けない問題と長大な推論をAIに与え、最後に有害な指示を付け加えるだけ。AIの注意を無害な部分に集中させ、本来の危険な指示に対する安全機能を弱体化させます。

2. メカニズム長い推論の連鎖は、AIの安全強度を担う中間層と、最終決定を行う後方層の機能を鈍らせることが判明。AIの「注意力」が前段の無害なタスクに割かれることで、後段の有害な指示に対する警戒が薄れ、拒否反応が著しく低下します。

3. 驚異的な成功率実験結果は衝撃的です。ある公開モデルでは、短い推論での攻撃成功率27%に対し、長い推論では約80%に急増。様々な最先端AIシステム全体で見ると、この手法は最大で99%の成功率を達成しました。

4. 結論 AIの推論能力の向上は、精度を高める一方で、意図せずして強力な「抜け穴」を生み出してしまいました。AIの賢さが、皮肉にもその安全性を脅かすという、新たな課題が浮き彫りになっています。

@kosuke_agos

(2025/11/05)

システム構成図・シーケンス図、結局どれ使う？人気ツールとエンジニアのリアルな使い分け徹底解説

システム構成図・シーケンス図、結局どれ使う？人気ツールとエンジニアのリアルな使い分け徹底解説

(2025/11/05)

AuroraMySQL 負荷試験報告〜結局のところスキーマ分離のDB設計ってどうなの？〜その１

AuroraMySQL 負荷試験報告〜結局のところスキーマ分離のDB設計ってどうなの？〜その１ - MNTSQ Techブログ

(2025/11/05)

【DDD】そのValueObjectまじで意味ないっす #Go

【DDD】そのValueObjectまじで意味ないっす #Go - Qiita

要約:

■ 1. 記事の目的と対象

ValueObjectの不変性にフォーカスし、アンチパターンを提示した後、本来あるべき姿の例を記載する

対象: アプリケーションエンジニア、DDDに取り組んでいる人・取り組みたい人

Vladimir Khorikov氏の言葉: 「ValueObjectを不変にできない場合は、それはValueObjectではない」

■ 2. ValueObjectとEntityの違い

Entity: 可変・同一性を持つ(ライフサイクルを持つ)

ValueObject: 不変・同一性を持たない(ライフサイクルを持たない)

同一性の例: 人物は20年経っても同じ人物として探すことができる(Entity)。名前や趣味は変わることがある(ValueObject)

■ 3. 比較(評価)の違い

オブジェクトの評価方法には三種類ある:

Reference equality: 参照の等価性

Identifier equality: 識別子の等価性

Structural equality: 構造的等価性

EntityはユニークなIDで比較を行う(Identifier equality)

ValueObjectは構造で比較を行う(Structural equality)

Entity: 記憶という識別子を元に本人かどうかを評価する

ValueObject: 名前(文字列)での構造的評価を行うため、ヒットしたアカウントが複数の場合もある

■ 4. アンチパターン1: 単なる型定義

この実装では型でドメインを表現できていると満足しているが、userIDもEmailもドメインの不変性という責務を果たせていない

ValueObjectの核心的な責務は「ドメインの不変条件(invariant)を保証し、カプセル化すること」である

■ 5. 型定義だけの実装がアンチパターンな理由1: カプセル化の欠如

Goの場合、型変換によってバリデーションを簡単にバイパスできる

ファクトリ関数(コンストラクタ)を用意しても、パッケージ外から型変換で不正な値を強制的に作れてしまう

アプリケーション全体でEmail型の値が常に「有効なメールアドレスである」ことを保証できない

他のパッケージから不正なメールアドレスのオブジェクトをインスタンス化できてしまう

■ 6. 型定義だけの実装がアンチパターンな理由2: ドメインの知識(振る舞い)の欠如

type Email stringの定義では、その型はstringとほぼ同等の能力(stringへの型変換が容易)しか持たない

ValueObjectは単なる「バリデーション済みの値」ではなく、その値に関連する「ドメイン固有の振る舞い(ロジック)」もカプセル化する責務を持つ

例: 「Emailアドレスからドメイン部分だけを取得したい」というドメインの要件があった際、現状の設計であれば実装がアプリケーション層に記載されることになる

「Emailのドメインパートのみを取得する」といったオブジェクトの振る舞いは関心の分離を行う対象であり、アプリケーション層ではなくドメイン層で設計・コーディングすることがオーソドックスなスタイルである

■ 7. 正しい実装: カプセル化と不変性を強制

構造体としてValueObjectを表現し、値と振る舞いの両方をカプセル化する

■ 8. アンチパターン2: 不変性の欠如

ValueObjectがポインタレシーバを持つ場合、「値が変更可能であることを示唆する」表現となるため、不変性を破壊しかねない

基本的に不変なものは値レシーバが推奨される

■ 9. 実装のポイント

ValueObjectを構造体として表現し、構造体が持つ値への参照を非公開(value)にしてgetter経由でしか参照させないようにすることで、パッケージ外からの型変換や直接的なフィールド代入を防ぐ

インスタンス化をNewEmailに強制し、バリデーションを担保する

ValueObjectの関数は値レシーバとし、不変性を明確にする

■ 10. まとめ

「ただの型定義」は、ドメインルールを強制できない「なんちゃってValueObject」である

不変性が必要な場面ではカプセル化を徹底し、ドメインルールを守らないオブジェクトの生成を許さないような設計を心がける必要がある

ファクトリー関数を通して、ドメインルールが守られたインスタンスが生成される

そうすることで初めて、ValueObjectは「意味のある」存在となる

結論: 「ValueObject導入するなら、値も振る舞いもカプセル化してくれ」

(2025/11/05)

組織全体の開発スループットを劇的に向上させた「AIプランナー」とは？〜Speeeが実践する3つのTipsと...

組織全体の開発スループットを劇的に向上させた「AIプランナー」とは？〜Speeeが実践する3つのTipsと新しい開発チームのかたち〜 - Speee DEVELOPER BLOG

(2025/11/04)

DDDにCQRSをどう組み込むか～バックエンドアーキテクチャ設計時の考え方

DDDにCQRSをどう組み込むか～バックエンドアーキテクチャ設計時の考え方 - TechDoctor開発者Blog

(2025/11/04)

ソフトウェアエンジニアにおける才能という現実

ソフトウェアエンジニアにおける才能という現実

まぁ、幻想じゃないね w

才能がないと思ったら、早いうちに河岸を変えた方がいい。

早ければ早い方がいい。

可哀想だから(教え子が？それとも自分が？ w)、って「がんばれ、がんばれ。才能なんて関係ない」みたいに騙すのは、むしろ害悪だよ。

10年後、気付いて路頭に迷わせるとして、その責任は取れるのか？

引導を渡すこともプロの責任。

まぁ、本人自身が気づいて路頭に迷いつつあるけどどうしようもないのかもしれんが、地獄に道連れはやめてやれ w

小説家、役者、声優、バンドマン etc.etc.

それで生計を立てない、趣味の範囲で楽しむ分には好きにすればいいけど、エンジニアに限らず、それなりのお金をもらおうとしたら、才能、向き不向きは超えられない壁として現実に、強固に存在している。

球速120km出ないけど阪神の一軍のピッチャーに、ってのはどう逆立ちしても物理的に不可能だ。

でも草野球は楽しめる。

才能がなけりゃ、一人で永遠に「大いなる助走」を続けりゃいい。

誰にも迷惑かけないなら。

医師、看護師、会計士、経営者、etc.etc. にも、才能、向き不向きはある。

おいらには、医師とか、警官とか、無理だねぇ。

落ち着きないし。

同じことを何日も続けたら、爆発する。

「明日も同じことしなきゃならないのか……」って考えただけでも、死にたくなる。

こんな感じに、才能がものをいう分野って、意外に多い。

ソフトウェアエンジニアは、設計実装の抽象度が多層化していて、その巧拙によって安定度、運用や機動的な新機能追加の手間、リードタイム、金や何やら、数十倍、規模複雑度が爆上がりしている今なら下手すりゃ数百倍差が出る。

その差をちゃんと理解するには、巧の現場の「こういう世界があるんやー……」って実体験が必要だったり、巧レベルの才能が必要だったり、経営知識が必要だったり、経済知識も必要だったりして、「拙」の現場にぶら下がってるだけのエンジニアが「才能なんて幻想」って吠えたっても「マジ、迷惑だからやめてね」って思う。

どの炎上現場でも、高粘度現場(リーダーマネージャが理解できないからって邪魔ばっかりしてきたり、そもそもプロダクトがぐっちゃぐちゃになってたりして、どんな行為がサービスの息の根を止めるかわからなくて身動きが取れない「震える舌」みたいな現場。物事が全然進まない現場。通常、経費で札束ガンガン燃やしてるはずだから、ここも炎上現場っていう)でも、この手のエンジニアが腐るほどぶら下がってるんだよね。

たいてい、生み出されるソースコードとドキュメントの割合がおかしなことになってる。

会議だ勉強会だなんだばっかりしてる。

いや、そういうの主催してる暇があったら、コード書けよ、って。

でも、Web記事引いてきて、「〇〇にはこう書いてある」とかドヤ顔で机上の空論で時間潰して「俺も一端の理論派エンジニアだぜ……」とか、いや、お前はただの受け売りを理解もせず垂れ流してるだけのそこらへんの AI と変わらんクズだよ。

おいらの師匠の一人は「TV出たり、本書いたりするやつは二流。一流は、自分の仕事に集中していて、他のことやる暇ないから」って言ってたけど、ほんとその通りだと思うよ。

シャバと違い、ソフトウェアの世界は驚くほどのスピードで巨大化、複雑化している。

30年、40年前なら、社会性の乏しい、プログラミングコンテスト受賞者みたいなエンジニアでも無双できたけど、今は無理なんだよね。

今だと玉拾いも任せられないくらいだったりする。

余計な部分最適化かまして、地雷埋設に邁進しちゃうから。

ちょい前も、PostgreSQLの中身いじれます！って東大卒業生いたけど、視点が局所的すぎて全体感に欠けてて、プロジェクトがヤバい状態になってるのが理解できなかったりしてたからね。

そろそろリリースできる状態になってる予定だけど、おいらの読み通りα版完成が3ヶ月遅れ、そこで大量の不具合が発覚してベータ版完成がそこからさらに3ヶ月以上遅れ、不具合積み残したまま見切り発車、ってなるんじゃねーかな、と思ってるんだが w

才能の種類、方向性によっては、10年前も今もたぶん10年後も変わらず十分通用するものはあるんだけどねー。

エンジニアの年収は他の一般の職業に比べて高い。

そこに生活水準をあげてしまうと、自分はもう通用しないと気づいても、撤退できない。

マイカーガー。

マイホームガー。

子供ガー。

愛犬ガー。

んなもん知るかっ！

さっさと色んな意味でFireしろっ！！

そういう「元エンジニア」がリーダーとかマネージャとかにクラスチェンジして、事業、プロダクトの足を引っ張る。

マジでこの手の「元エンジニア」が、今、業界に溢れてる。

あそことか、そことか、具体的な企業名はあげられないけど、そういうエンジニアが漬物石のように重しになって、身動きが取れなくなってるところが多い。

VCとかから、もっと売り上げを上げろ。成長率を上げろ、というプレッシャーを与えられ、何かしなきゃいけない。ってなって、外付けの雰囲気だけのサービスをどんどん外付けしていく戦略を取る。

1年で10。

2年で30とか。

マジかよ w

思い思い行き当たりばったりに作ったら、手間だけ増えてそれを壊すわけにはいかなくなって、さらに身動きが取れなくなっていく悪循環しか見えないんだが、そんな経営方針で大丈夫か？

とりあえず認証認可から共通化していくしかない。

とか意味不明な決定して、認証認可v1、認証認可v2、認証認可v3とマイクロサービスが増殖して、さらにv4を企画してるとかいう会社だってある。

真っ当な声には、自分の存在感を示すためだけの反対を唱えて邪魔したりして、現場で手を動かしているエンジニアより高級を取ってんのに、事業、プロダクトへ与えるダメージは倍増する。

さらに、自分の地位を死守するために、それを脅かす腕利のエンジニアを陥れる、排除することに全力を傾ける。

これで3倍界王拳だ w

経営者はできるエンジニアたちに任せていると思い込んでいるかもしれないが、さて、どうかね？ w

大本営発表的にはうまくいっているとされているサービスが、その裏側はカーオブファイヤーみたいなところって、結構ある。

というか、そっちの方が多いんじゃないか？ポチョムキン村。

はっきりいう。

ソフトウェアエンジニアは、アスリート的な仕事だ。

おいらは土日祝もシステム関係の勉強とか研究をしてる。

今はクラウド環境のプロダクトで、どのように自動テストで検証可能なシステムを構築するかの手法の研究を続けてる。

具体的には、今まで関わってきた炎上現場で安定稼働を達成させた手法(TDD)だな。

ワークライフバランス？ w

そんな寝言、やめてから言えよ www

才能のない人は河岸変えろ。

むしろ若手を潰してるって自覚持て。

に反論してくるのが結構いる。

あのサービスとこのサービスとそのサービスを使ってます。

業務経歴書にも今まで使ったことがあるサービスの名前をたくさんたくさん載せてます。

僕の技術力は世界一ぃぃぃっ！！！

じゃねーよ。

ボルトに世界水泳、吉田沙保里にNBAに出場させるような使い方してて、どこが技術力だよ。

ってのが多い。

「どうしてこのAurora、リーダーがこんなにたくさんぶら下がってんの？」

「テナントが増えて、アクセスが増えたので、負荷分散のために増やしました。水平スケーリングってやつです」

うん。水平スケーリングは知ってんねん。この程度のテナント数、ユーザー数、アクセス数で、どうしてこんなにでかいインスタンスのリーダーがぶら下がってんのか？って聞いてんねんけど……。

って現場、多い。

というか、そういう現場しか知らん w

まぁ、炎上現場巡りしてたし。

でも、今通常営業してるサービスでも、こういうところ多いんだよな。

それはともかく、

「マイクロサービス化していて、いま120を超えたところで、当面160になります」

「……は？」

「うちのサービス、ドメイン多いんで」

「……デプロイの時、どうすんの？」

「変更があるサービス名を書いたファイルを一緒にコミットして、それ読み込んで、GitHubActionsでデプロイさせてます」

「……ローカルの開発環境構築は？」

「Cloneして立ち上げます」

「これ……、モノリポ？」

「もちろんです。Googleもそうやってますし」

「120個？」

「120個」

「なんか立ち上がらないんだけど……」

「あ、修正中なんで、〇〇と××のコミットをチェリーピックしてください」

「……動かないぞ」

「昨日の夕方、変更が入ったみたいなんで、△△のコミットもチェリーピック。いや、＋＋のブランチを……」

5日で立ち上げ切れるんか？

って現場がね、案外たくさんあるんだ。

で、「マイクロサービス、使えないっすね」

「ほう……？」

「連携が取りづらくて、障害発生しまくって」

どうして「自分が間違えてる」「自分が見当外れなことをしている」可能性ってのを考慮しないんだろう、この人らは？

っていつも思う。

マイクロサービスの目的も前提も理解しないで、HowToだけ猿のように繰り返してるって自覚ないんか…… (-_-)

「だって、オライリー本のここにこう書いてあるから！」

ってマーカーで引いた一文見せつけられるんだが、その前に書かれてある前提とか目的とか、書かれてない暗黙のそれとか、いわゆるコンテキスト削ぎ落として、単語レベルの理解を開陳されても、「は？」としか反応できんのよな。

120のマイクロサービスとか、お前、認知科学の知識もないねんな……。

それマイクロサービスじゃなく、「粉砕されたモノリシックサービス」っていうんやで、と。

まーじで、技術本とかの恣意的なつまみ食いで訳分からん理論構築すんなよ。

それでプロダクトがうまく回ってなかったら、それが答えなんよ。

まぁ、「うまく回ってる状態」ってのを知らない、理解できないだろうから、正しい答えに行きつかんだろうけど。

その正しい答えに行きつかない、ってのを

「致命的な才能の欠如」

って呼ぶんよ。

サリエリくらい才能があったら、自分の才能が足りんことを自覚できるんだがな。

脳外科医竹田君みたいなエンジニアは、即刻足を洗って欲しい。

MEMO:

残念ながらこれは本当にそう

(2025/11/03)

【UG# 455】「生成AIで絵師はどうなる？」「誰が為の監視社会」「積読書術」 @サイコパスの人生相談...

【UG# 455】「生成AIで絵師はどうなる？」「誰が為の監視社会」「積読書術」 @サイコパスの人生相談 2022/09/11 - YouTube

要約:

■ 1. 画像生成AIの現状認識(2022年から2025年の変化)

2022年時点では画像生成AIの存在が認知され始めた段階だったが、2025年現在では小学生や高齢者も普通に使いこなしている

当時から「明るい未来はあまりない」と予測していたが、実際にイラストレーターの仕事は奪われつつある現実となった

イラストの単価が3分の1になっているとの報告もある

生成AIに対する抵抗運動(訴訟、ボイコット、ネガティブキャンペーン、プロテクト技術の使用など)が展開されているが、大局的には勝ち目がない

■ 2. AIによる学習と著作権問題の本質

流行している絵の描き方パターンをAIに学習させて発表する行為は、人間の絵描きや漫画家が昔から行ってきたことと本質的に同じである

漫画家は現在も活動している漫画家の作品パターンを頭の中で混ぜて創作しているため、AIがそれを行うことを非難するのは矛盾している

オリジナリティとは混ぜ方の中に自分が生きているかどうかの問題である

自分が苦労して編み出した表現をAIに盗まれるという感情は理解できるが、この論法では勝ち目がない

■ 3. イラスト業界の段階的淘汰

第一段階(過去3年間): イラスト屋などの無料配布により、地方自治体や小規模商店向けに仕事をしていた町のイラストレーターが淘汰された

第二段階(今後): 超メジャーではない中堅イラストレーターの仕事が奪われる

超メジャーなクリエイター(鳥山明、大友克洋、尾田栄一郎など)のみが「その人が描いてくれただけで価値がある」という理由で生き残る

■ 4. アニメーション制作の変革

アニメの作画は無人化が進む

演出家は見せたいカットを人間に発注し、流してよいカットをAIに発注するという使い分けを行う

AIは書き込みが多く影が複雑な動きに向いており、人間のアニメーターに負担をかけていた作業を担当する

結果としてアニメーションのクオリティは向上し制作コストは下がるが、動画マンは職を失う可能性が高い

原画マンは生き残る可能性があるが、動画マンの将来は厳しい

■ 5. 漫画制作へのAI浸透

コマ割りや見開きの見せ方などの漫画文法もAIのディープラーニング対象となる

漫画が量産されるほどデータが蓄積され、AIによる自動生成が可能になる

数年以内に可能になることは明らかである

話し言葉のコンテンツを数秒後に漫画化したり、ゆっくり解説動画にする技術が実現する

■ 6. YouTuberとコンテンツクリエイターの未来

あらゆるYouTuberがほとんど失業する未来がある程度見えており、その中間段階が進行している

切り取り動画の制作(過去の発言と現在の発言を混ぜて面白くする作業)すらAIができるようになる

キャラクターとしての価値が重要になり、本人が話すことよりもキャラクターが話しそうなことをAIが生成する方が面白くなる

数十万人が考えたキャラクターらしい発言の方が、現実の本人の発言より面白くなるのは時代の必然である

これはシンギュラリティではなく失業ポイントに向けて進んでいる過程である

■ 7. 新しい仕掛けと失業の連鎖

ニコニコ生放送などの新しい仕掛けによって多くの人が失業してきた

その屍の上に現在の成功者が乗っかって商売をしている

この構造もいずれ崩れていくのは当たり前である

恐ろしい未来ではなく、そうなったら次の面白いことを考えるだけである

■ 8. 生き残るクリエイターの条件

超優秀なアニメーター、漫画家、絵師は生き残る

しかし大半の漫画家は職業として成立しなくなる

アシスタントも同様に厳しい状況に直面する

■ 9. 変化の時間軸予測

3年程度で大きな変化が目に見えるようになる

食える食えないという最終的な変化には10年程度かかる

中間的なポジションにいるクリエイターが本当に危機に直面するまでには5年から10年かかる

この予測は先取りしすぎているため多くの人は実感できず疑問視するが、5年後10年後には確実に実現する

「そうなるべきではない」と考えているとずれてしまうため、時代はそういうものだと認識すべきである

■ 10. 発注型仕事の消滅

誰かからお金をもらって発注を受けリクエスト通りに制作する仕事は失われ続ける

観光地の似顔絵やディズニーランドのシルエット切り絵のようなサービスは、2000円~3000円の技術料が必要だが、無料で類似のものができる状況では生き残れない

超メジャーなネームバリューのある人以外は生き残れない

■ 11. アートから手芸への移行

人類に残されたのは自分にしかできない、自分が手を動かして作った趣味をめでるという方向性である

現在の手芸ブームはこの流れを反映している

アートや作品としてではなく、趣味としての手芸として素晴らしいという価値観に流れている

アートはAIに奪われているため、人間は自分が本当に手を動かして作ったものを愛でる方向に向かっている

■ 12. 現状追認と説得の意図

この発言は現状追認ではなく、現状を認められない人を説得しようとしている

「AIはダメだ」「人間にしかできないクリエイティビティがある」と言う方が、人前で話をする立場としては商売になる

それを理解しながらも、こだわり続けると苦しいという助言をしてしまう

カメラに向かって話をする活動自体も、あと何年何ヶ月続けられるか分からない

■ 13. 自動化の波及と共通の運命

来月は無理でも来年、再来年には話す内容の自動化が見えてきている

全員が同じタイタニック号に乗っている状況である

逃げる先は新しい稼ぎ先ではなく手芸のようなものしかない

この問題に対する明確な解決策は見出せていない

MEMO:

これはエンジニアも同じで、SESみたいなエンジニアの時間貸し商売は数年以内に成立しなくなると思われる
QAなどAIの出力を専門家として検証する仕事はしばらく残りそうだが、それですらAIのクロスチェックでよいのでは？　という感覚がある
当然正社員雇用のエンジニアも「本当にこんなに人数が必要なのだろうか？」となるのは避けられない
今後はAIを駆使して単独で全工程をやりきるコスパ最強のエンジニアしか生き残れないのではないか？

(2025/11/02)

AIがコードを書いてくれるなら、新米エンジニアは何をする？

AIがコードを書いてくれるなら、新米エンジニアは何をする？ / komekaigi2025 - Speaker Deck

(2025/11/02)

AI時代のソフトウェア開発文芸モデル駆動アプローチ : 文芸モデルをDSLとした文芸モデル開発と...

AI時代のソフトウェア開発文芸モデル駆動アプローチ : 文芸モデルをDSLとした文芸モデル開発と生成AI連携の知識ベース | PDF

(2025/11/02)

コードは書ける、でも"AIを理解してない"エンジニアが増えている現実😭

コードは書ける、でも"AIを理解してない"エンジニアが増えている現実😭

要約:

■ 1. 現状の課題

AIアプリエンジニアが急増している:

生成AI(LLM)が普及し誰でも比較的容易に活用できるようになったことが大きな要因である

しかし実際のところAIそのものへの理解や理論的な知識を持たずに開発しているケースも少なくない

OpenAI APIを使える、LangChainを組めるといったツールとしてのスキルはあってもAIの挙動や構造を理解したうえで設計している人は限られている

コードは書けるのに結果が出ないケースをよく見る:

ノーコード/ローコーディングツールの普及によって誰でも短期間でMVP(最小実行可能プロダクト)を作れるようになった

しかし現場レベルで実際に運用・定着するプロダクトになるケースは非常に少ない

一見動くものを作ることはできても使える・価値を生むレベルまで育てるのが難しい

社外にPRされているAI事例の中にも実際には一部組織内だけの限定的活用にとどまっているものも少なくない

■ 2. 何が起きているのか

ノーコード/サンプルコードの充実によってAIアプリを短期間で作ること自体は簡単になった

ローコーディングという神ツールも登場し、従来時間のかかっていたコーディング時間は半減し確実にMVPを作るまでは早くなった

ただし動く状態から使える状態に引き上げるにはきめ細かなチューニングとAIの仕組みへの理解が不可欠である

このチューニングにはモデル構造やプロンプト設計、データセット設計の知識が求められる

しかしAIをブラックボックスとして扱っているとどこを調整すればよいか判断できない

結果としてAPIを呼び出すだけの構成にとどまり、課題を根本的に解決できないまま止まってしまうことが多い

具体例:

ベクトルDBをとりあえず繋いでいる、プロンプトを変えてみるだけといった状態で止まっている例をよく見かける

特にプロンプトを変えてみるだけはすごく多いパターンである

RAGであればそもそも構造的にプロンプトチューニングの限界があるから仕組み的にリトリーバーの改善を、リトリーバーを変えたということはベクトルDBのメタデータをといったような思考プロセスを持ち合わせる人が少ない

技術的にリーチングアウトできるエンジニアは非常に少数である

■ 3. なぜそうなるのか

LLMのような生成AIに何でも神頼み:

生成AIの進化によってLLMに任せればなんでもできる、マルチモーダル=すごいという空気感が広がった

しかし現場業務のような特定のタスクに特化したアプリケーションを作るほど実は汎用的なLLMだけでは十分に対応できることはかなり少ない

モデルの限界や誤答特性を理解し適切な技術や設計を組み合わせていく地道な調整が必要である

成果物重視・SaaS依存構成による原理の理解の欠落:

事業会社ではスピードが求められたり予算に限りがあったりするため、SaaSや既存APIを組み合わせて素早く成果物を出す傾向がある

ただしそれが積み重なるとバックエンドではAPIを叩いているだけになりAIそのものへの理解を深める機会が減ってしまう

もちろんSaaSの進化が早いので追いつけないこともある

成果物を優先する判断は正しい場面も多いが理解の機会を意識的に確保することが必要である

評価基準が曖昧になり"すごいっぽいデモ"で終わる:

デモは盛り上がったけど実務では使われないというパターンも非常に多い

原因は明確で定量的な評価指標やデータセット設計の知見が不足しているからである

AIアプリを改善するにはなぜこの出力が良いのか/悪いのかを測れる指標が欠かせない

評価手法を持つことはエンジニアとしてだけでなくプロジェクトの信頼性を担保するビジネススキルにも直結している(相手を説得しやすいのは数値であるため)

■ 4. 本当に有用なAIアプリを作るために必要な理解

基礎的な基礎:

例えばLLMの出力は確率的であり設定や入力次第で大きく変化する

RAGであればキーワード検索はBM25の頻度計算をベースにといったような理解が必要である

ベースの技術を理解できていればうまく行かない時のチューニングの方針や次のアクションを早く決めることができる

アジャイル開発であれば次のスプリントのバックログを事前に計画できるのでプロジェクトとして計画的に進めることもできる

評価軸(正確さ・再現性・効率性など)を明確にする:

すごいではなく安定して成果が出る状態を目指すために評価指標を定義し可視化すること(=見える化)が重要である

小さく検証→定量化→改善というループを設計する:

大きなアプリを一気に作るのではなく検証サイクルを短く回す

この地道なプロセスが結果的に品質を押し上げる

そういった進め方をクライアントもしくは現場と綿密に擦り合わせることも大事である

■ 5. AI時代のエンジニアに求められる姿勢

AIアプリエンジニアが数多く登場し社内外でAI活用が広がる中で、いまようやく本当の課題はクオリティだと気づき始めているのではないか

AIに対する理解を深め使えるレベルまで磨き上げる姿勢がこれからのエンジニアには求められる

AIを使える人は増えた

しかしAIを理解して活かせる人こそがこれからの時代に強い

(2025/11/01)

DBのcolumn名や、何らかドメインの意味を持つ概念に type を名付けない方が良いのではないか

DBのcolumn名や、何らかドメインの意味を持つ概念に type を名付けない方が良いのではないか - その手の平は尻もつかめるさ

要約:

■ 1. type という命名を避けるべき理由

type やそのサフィックスを持つ名前(_type など)を変数、構造体・クラスのメンバー、データベースのカラムなどに付けてしまうことがしばしばあるが、あまりやらない方が良い

理由1(予約語との衝突):

type はいくつかのプログラミング言語において予約語になっており、そのセマンティクスにおいて特別な役割を果たすことが多い

理由2(フレームワークとの衝突):

Ruby on RailsにおいてはDelegated Typesという機能において_type というカラムは特別な意味を持つ

もちろんアプリケーションコード側でDelegated Typesであるという宣言をしなければ副作用は無い

その他のフレームワークに似たようなものがあるのかは不明である

こういった概念との衝突を避けるために特別かつ強い理由が無い限りは type という命名は避けるという方針

■ 2. 代替案

代替としては kind や method などが使えそうである

これらを採用することが多い

method は別の概念との衝突がある場合もありそうだが、そこは文脈に沿って対応する

■ 3. 例外的にtypeを使用する場合

どうしても type でしか表現できないものはあると思われる

例えば言語処理系を作っていて本当に「型」を取り扱う必要がある場合などである

そういった場合は頑張る必要がある

MEMO:

KubernetesではGoで実装されている事が多く、Goでは type が予約語になっていて使えないので kind が多用されているらしい

(2025/11/01)

「タスク遅れに対しての手札をふやす」ことが、マネージャーの立ち回りとして大事だという話

「タスク遅れに対しての手札をふやす」ことが、マネージャーの立ち回りとして大事だという話 | Books&Apps

要約:

■ 1. マネージャーの価値とタスク遅れ対処

タスク遅れ解決のための手札をどれだけ持っているかがマネージャーの価値である

タスク遅れは必ず発生するものであり、必ず対処しなければならない

タスク遅れに対してどんな手を打てるかは組織次第、状況次第で変わる

タスク遅れ解決のための手札をなるべく増やすように、普段から立ち回りを意識することが重要である

■ 2. タスク遅れが必ず発生する理由

工期の見積もりはあくまで見積もりでしかなく、完璧な見積もりは絵に描いた餅である

プロジェクト遂行中のトラブル:

エスパーでないと予知できないトラブルが発生する

メンバーが体調を崩したりサボることもある

タスクが難しすぎたり、依存関係が複雑過ぎて手がつけられないこともある

タスクごとにリスクを計ってマージンを作るが、存在するマージンは基本的に全て食い潰されるため、大抵それ以上にタスクは遅れる

■ 3. タスク遅れに対する手札の三つの分類

人的リソースでなんとかする:

やる人の手を増やしたり、費やす時間を増やすことで対処する方法である

残業時間を増やす、対応メンバーを追加する、誰かに手伝ってもらう、出来る人を連れてきてもらうなどが含まれる

一番分かりやすいが故にマネージャーにとっては安易に頼ってしまいがちな方法である

頑張るしか手札を持っていない人である場合、時々悲劇が発生することもある

人的リソース以外の手札を何枚持っているかがマネージャーの有能さを示す一つの指標である

調整でなんとかする:

他の担当チームやクライアントと相談してスケジュールを延ばしてもらう、実装する機能のスコープを見直してタスク自体をスケールダウンする、機能を簡易化してタスクの難易度を下げる、上にエスカレーションするなどが含まれる

人的リソースでなんとかするよりもマネージャーにとっての難易度は高い傾向がある

組織によっても仕事の質によってもどれだけの選択肢がとれるかは変わる

タスク遅れと言われた場合、この辺の選択肢がマネージャーに期待される部分は大きい

プロセスをなんとかする:

レビューや事務手続きで時間を食い過ぎている場合、リスクをとったり簡略化してプロセスを改善する、メールのやり取りで時間を食っている場合は拠点を移して対面で話せるようにするなどが含まれる

開発手法を変更する、ツールでテストを自動化する、作業を分割して開発を並列化する、クリティカルパスの見直しや後工程を前倒しで始めることで全体としての遅れを吸収するなどの方法もある

遅れが顕在化してからよりも普段からの準備が重要である

一般的には三つの中で一番難易度が高いケースが多い

マネージャーにとっては腕の見せ所である

下手にプロセスをいじると逆効果になることもある

■ 4. マネージャーが把握すべき三つの観点

マネージャーとしての自分はタスク遅れの対応策を幾つ知っているか

そのうち現在の環境、現在のプロジェクトで実際に取り得る対応策はどれか

そのうち最も効果的でなるべくコストを低減できる対応策はどれか

■ 5. 環境による制約と手札の確保

タスク遅れの対応策は環境、仕事の種類によって選択できるものが変わる

クライアントとの関係次第ではスケジュールの調整ができないかもしれない

品質は絶対厳守でテスト工数は絶対に減らせないかもしれない

有識者を連れてこようにも他チームも全部炎上しているかもしれない

頑張る以外の手札をどれだけ用意できるか、調整とプロセスからそれぞれ二枚、三枚の手札を選択できるだけの余地を確保できているかが重要である

■ 6. 普段からの立ち回りの重要性

常に使い得る手札を把握しておき、できることならその枚数を増やせるように立ち回っておくことがマネージャーとして非常に重要である

事前準備の具体例:

常日頃から他チームといい関係を築いておき、いざという時にはヘルプを求められるよう恩も売っておく

スコープの見直しの可能性やリスクについて事前にクライアントと調整しておき、いざという時は切り捨てても良い機能や品質の落とし所について確認しておく

リスク計画はプロジェクトの立ち上げ時点で個別に考えておくべきテーマであるが、普段からの立ち回りで事前準備が必要な部分でもある

タスク遅れという分かりやすいピンチでどういう手札を持っているかはマネージャーとしての一番の価値である

手札を増やす努力自体が会社での自分の立ち位置を向上させていくための努力とほぼイコールになる

■ 7. 具体的な解決事例

新人マネージャーが一つの開発環境内で全部解決しようとして色々引っかかっていた

もう一つ環境を作ってそのリソースを使えば解決できるというアドバイスで解決に向かった

解決できそうな人に事前に渡りをつけておくこともマネージャーとしての価値を高めるための一つの方法である

(2025/10/31)

“アナログコンピュータ”でGPU超え？特定の演算でH100の10倍高速かつ省エネ、AI学習へも応用可能性...

“アナログコンピュータ”でGPU超え？特定の演算でH100の10倍高速かつ省エネ、AI学習へも応用可能性、Nature系列誌で発表 | レバテックラボ（レバテックLAB）

(2025/10/31)

ざっくり学ぶ『エンジニアリングリーダー技術組織を育てるリーダーシップとセルフマネジメント』

ざっくり学ぶ『エンジニアリングリーダー技術組織を育てるリーダーシップとセルフマネジメント』 / 50 minute Engineering Leader - Speaker Deck

(2025/10/31)

ドメイン駆動設計のエッセンス

ドメイン駆動設計のエッセンス - Speaker Deck

ソフトウェアエンジニアにおける才能という幻想、あるいは成長を阻む最大の敵について

ソフトウェアエンジニアにおける才能という幻想、あるいは成長を阻む最大の敵について - じゃあ、おうちで学べる

(2025/10/30)

設計原則と普遍的な判断軸

設計原則と普遍的な判断軸 | ドクセル

(2025/10/30)

FAST導入1年ログラス×ユーザベース対談

FAST導入1年ログラス×ユーザベース対談 - Agile Journey

(2025/10/30)

コロケーテッドアーキテクチャ概要

コロケーテッドアーキテクチャ概要 - Commune Engineer Blog

(2025/10/30)

【心理学】ダブルバインドが横行する殺伐とした開発現場は実在するので、メンバーは自己防衛の手段...

【心理学】ダブルバインドが横行する殺伐とした開発現場は実在するので、メンバーは自己防衛の手段としての心理学を身に付けて冷静に対処したい

(2025/10/29)

Microsoftの1ビットLLM「BitNet」の進化版「BitNet Distillation」、既存マルチモーダルLLMで長文を...

Microsoftの1ビットLLM「BitNet」の進化版「BitNet Distillation」、既存マルチモーダルLLMで長文を画像化する効率的AI処理など生成AI技術5つを解説（生成AIウィークリー） | テクノエッジ TechnoEdge

要約:

■ 1. BitNet Distillation(Microsoft Research開発)

概要: 既存LLMを1.58ビット精度(-1、0、1の三値重み)に変換する手法で、2023年発表の「BitNet」の進化版である

BitNetの問題点:

競争力のある精度を得るには大規模コーパスでゼロから事前学習する必要があり、膨大な計算コストがかかる

既存のフルプレシジョンモデルを直接1.58ビットに変換すると性能が大幅に低下する

モデルサイズが大きくなるほど劣化が拡大する

BitDistillの改善点:

Qwenなどの既存高性能LLMを出発点として使用できる

SubLNモジュール、MiniLMベースの蒸留、継続的事前学習という3段階の最適化により、フルプレシジョンモデルと同等の精度を維持する

モデルサイズが増えても性能劣化が起きない優れたスケーラビリティを実現した

実験結果:

分類タスクやテキスト要約などの下流タスクでフルプレシジョンモデルと同等の精度を達成した

メモリ使用量を10分の1に削減し、CPU上での推論速度を2.65倍高速化した

レイテンシ、スループット、メモリ効率、エネルギー消費において改善を提供する

スマートフォンなどのエッジデバイスでの実用的なLLM展開が容易になる

■ 2. HunyuanWorld-Mirror(Tencent開発)

概要: 画像や動画から立体的な3D空間を数秒で生成できるAIフレームワークである

入力の柔軟性:

1枚の画像だけでなく、複数視点の画像や動画に対応している

カメラの姿勢や内部パラメータ、深度マップといった多様な幾何学的事前情報を柔軟に統合できる

出力の多様性:

点群、複数視点の深度マップ、表面法線、3Dガウシアンなど複数の3D表現を同時に生成する

Multi-Modal Prior Promptingという新しいメカニズムにより事前情報がトークン化され、画像情報と効果的に統合される

技術的特徴:

トランスフォーマーベースのアーキテクチャを採用している

カメラパラメータの回帰から密な予測タスクまで統一的なデコーダーヘッドで処理する

トレーニング時に異なる事前情報の組み合わせをランダムにサンプリングすることで、推論時に利用可能な情報が限定的な場合でも柔軟に対応できる

性能評価:

点マップとカメラ推定ではVGGTやπ³を上回る

表面法線予測ではStableNormalやGeoWizardを凌駕する

新規視点合成ではAnySplatを超える結果を示した

■ 3. DeepSeek-OCR(DeepSeek-AI発表)

概要: 長大な文書コンテキストを画像化して効率的に処理するシステムである

処理方式:

OCR(光学文字認識)技術を用いて、手書き文書や書籍をスキャンして画像データに変換する

視覚トークンという圧縮された形式を使用してテキストを大幅に圧縮し、計算処理を効率化する

圧縮効率:

元のテキストトークンを10分の1に圧縮しても97%という高い文字認識精度を維持できる

20分の1まで圧縮しても約60%の精度を保てることが実証された

システム構成: DeepEncoderとDeepSeek3B-MoE-A570Mデコーダーという2つの主要コンポーネントで構成される

ベンチマーク性能:

OmniDocBenchにおいて100個の視覚トークンのみでGOT-OCR2.0(256トークン/ページ)を上回る

800個未満の視覚トークンでMinerU2.0(平均6000トークン以上/ページ)を超える性能を発揮した

単一のA100-40G GPUで1日あたり20万ページ以上の学習データ生成が可能である

■ 4. テキスト画像化による計算コスト削減研究(アレン人工知能研究所など)

研究目的: 長文テキストを単一の画像として描画してモデルに直接入力することで、マルチモーダル大規模言語モデル(MLLM)の入力トークンを削減しながら性能を維持できるかを検証する

背景課題: 現在のLLMはTransformerアーキテクチャにより、入力長に対して計算コストが2次的に増加するという課題を抱えている

研究アプローチ:

GPT-4 VisionやGoogle Gemini 2.5などの最新MLLMが画像からテキストを読み取る能力に着目した

テキストの画像表現を入力圧縮の手段として活用することを検証した

ConTexImageパイプライン:

テキストを制御された解像度の画像に変換する

フォントサイズを自動調整して最適な可読性を確保する

大規模モデルで最大45%のエンドツーエンドの処理速度向上を実現した

実験結果:

長文タスクのRULERベンチマークと要約タスクのCNN/DailyMailベンチマークで評価を実施した

GPT-4.1-miniとQwen2.5-VL-72Bモデルは、最大58%少ないデコーダートークンで97～99%の精度を維持した

要約タスクでも既存の圧縮手法を上回る性能を示した

72Bパラメータの大規模モデルは視覚的に密集したテキスト情報を効果的に処理できることが明らかになった

■ 5. 共通トレンド

効率化技術の進展:

ビット精度削減によるメモリとエネルギー効率の改善(BitNet Distillation)

テキストの視覚トークン化による圧縮と高速化(DeepSeek-OCR、テキスト画像化研究)

マルチモーダル統合の高度化: 画像、動画、テキストなど異なるモダリティを効果的に統合する技術が進化している(HunyuanWorld-Mirror)

エッジデバイス展開の促進: 軽量化技術によりスマートフォンなどでの実用的なLLM展開が現実的になっている

(2025/10/29)

技術力に優劣はある(「技術力に優劣はない」を読んで)

技術力に優劣はある(「技術力に優劣はない」を読んで) - じゃあ、おうちで学べる

(2025/10/28)

サイゼリヤのセルフオーダー、プログラミング初心者のアプリみたいだけど大丈夫そう…？→いや異常な...

サイゼリヤのセルフオーダー、プログラミング初心者のアプリみたいだけど大丈夫そう…？→いや異常な要件定義の精度でUXの本質を理解している - Togetter

(2025/10/28)

PRDの正しい使い方～AI時代にも効く思考・対話・成長ツールとして～【パーソルキャリア】

PRDの正しい使い方～AI時代にも効く思考・対話・成長ツールとして～【パーソルキャリア】 - TECH PLAY

Why I code as a CTO

Why I code as a CTO

要約:

■ 1. CTOとしてコードを書き続ける理由

一般的な通念への反論: 多くのCTOはコードを書かなくなるが、筆者は過去12ヶ月間で大量のコードを出荷している

直属の部下ゼロ: 現在直属の部下を管理しておらず、会議の合間に少し書く程度ではなく、前四半期に複数の実質的な機能を出荷した

高いレバレッジ: コードを書くことは技術リーダーとして行う最もレバレッジの高い活動の一つである

誤解への反論: CTOがコードを書く場合、ペットプロジェクトや形式的なコードレビューをしていると思われがちだが、実際は異なる

■ 2. 長期的実験プロジェクトの推進

希少なリソース: 組織内で実質的に新しいものを構築できる人材は実は希少なリソースである

組織の特性: 組織は一般的に現状維持と現行製品のスケーリングのために構築された生物である

限られた人材: 新製品を生み出せるのは創業者、数人の幹部、一部の高レバレッジな個人貢献者のみである

新アイデアの重要性: 新しいアイデアを推進することは意図的で持続的な努力を必要とするため非常に重要である

エンジニアの制約: 組織構造、ロードマップのインセンティブ、限られたリスク予算により、大半のエンジニアは曖昧な賭けを追求する時間を取れない

CTOの優位性: 顧客の痛点とアーキテクチャを十分に理解しているため、これらの重要な実験プロジェクトを引き受けるのに独自の立場にある

AIチャット製品の事例: 顧客向けAIチャット製品について議論していたが誰も時間がなかったため、感謝祭の休暇中にプロトタイプを作成し、チームと協力して数百万ドルのARR製品に仕上げた

■ 3. 緊急性の高い顧客要求への対応

緊急案件の特性: 重要な顧客が緊急に何かを必要とし、それが大型契約や更新の障害になる場合がある

必要な能力: 迅速に動き、システム全体を理解し、実用的なトレードオフを行える人材が必要である

スプリントの中断回避: エンジニアを現在のスプリントから引き離す代わりに、CTOが騒音を切り抜けることができる

コンテキストと重要性の理解: すでにコンテキストを持っており、リスクを理解している

データ編集機能の事例: 年間100万ドルの顧客がコンプライアンス上の理由で統合機能に完全なデータ編集を必要とした際、1日で動作バージョンを構築して出荷した

■ 4. バグ修正による知見の獲得

意外な活動: 人々は驚くが、筆者は多くのバグを修正している

コードベースの理解: バグ修正はコードベースのメンタルマップを維持するための好きな方法の一つである

システムの横断: ページネーションやWebSocket接続の問題を追跡する際、システムの広大な領域を横断する

技術的負債の理解: コードレビューやアーキテクチャ議論からは得難い技術的負債の内臓的理解が得られる

意思決定への貢献: このメンタルマップは技術投資やチームが注力すべき場所についてより良い決定を下すのに役立つ

■ 5. 実際に機能するものを把握し続ける

AIツールの日常使用: Claude Code、Codex、Cursorなどの多数のAIツールを日々使用している

戦略的意思決定: ツールや採用に関する戦略的決定を行う際、何が本物で何が偽物かを理解できる

具体的事例: 複雑な統合に触れる機能をバイブコーディングで試みたが、最終的に手作業で書いた方がはるかに進捗した

AIの強みと弱み: AIがCRUD、テスト、ボイラープレートで輝き、精度やシステムのニュアンスで失敗することを知ることは、Twitterの誇大広告に基づく決定よりも常に優れている

直感の獲得: コードの中にいることで、アーキテクチャが過度に複雑な時や技術的負債が実際の問題になっている時を感知できる

■ 6. 自分の好きなことと得意なことに集中

組織構築への不向き: 組織を構築したり人事関連を扱うことを特に楽しんでいない

エンジニアリング管理の課題: 対人関係のダイナミクス、パフォーマンスレビュー、組織設計のナビゲートが含まれるが、これらは筆者の強みではない

優秀な管理者の採用: 優秀なエンジニアリングマネージャーとリーダーを雇用し、彼らはそれを楽しんでいる

自分の強みへの集中: ものを作ること、技術的問題を解決すること、コードを書くことに集中できる

長期的持続性: スタートアップは疾走するマラソンのようなものなので、自分を興奮させ長期間速く走り続けられる仕事の周りに役割を設計している

■ 7. AIツールによるレバレッジの変化

過去の苦悩: 数年前は戦略的な仕事をこなしながらコードを書く時間を見つけるのに苦労していた

会議漬けの日々: 会社が成長するにつれ、基本的に一日中会議に拘束され、天才ゾーンの外で活動していた

生産性の向上: 現代のAIツールが根本的にこの方程式を変え、以前より2～3倍生産的になった

判断力の価値向上: これらのツールは判断力や技術知識を置き換えるのではなく、実際にそれらのスキルをより価値のあるものにした

コンテキストの活用: 正確に何が必要でどこで見つけるかを知っているため、AIツールに指示を出すことで大部分のコードを正しく生成できる

役割の変化: 仕事は「すべてのコード行を書く」から「コンテキストを提供し、決定を下し、解決策を評価する」へとシフトした

■ 8. 自分に合った働き方の発見

Greg Brockmanの影響: StripeでのCTOの役割定義についてのブログ投稿を読み、役割に膨大なバリエーションがあることを認識した

CTOの多様性: 技術的ビジョナリー、組織ビルダー、インフラ重視など、CTOの役割は様々である

共通点: 優れたCTOは自分の特定のスキル、興味、会社のコンテキストを考慮して最も価値を創造できる場所を見つけ出す

筆者の特定の道: ソフトウェア構築を組織設計より楽しみ、深い顧客とコードベースの知識を持ち、強力なエンジニアリングマネージャーを雇用したという特定のコンテキストで機能している

処方箋ではない: これは筆者の特定の道であり、処方箋ではない

柔軟な役割: CTO役割は驚くほど柔軟であり、組織構築、製品戦略開発など、技術リーダーシップは強み、活力の源、会社のニーズによって異なる

多様な道の存在: リーダーシップが技術的仕事を放棄することを意味すると心配するエンジニアに対し、多くの道が存在することを知ってほしい

成功の鍵: 自分が独自に優れている場所を見つけ出すことが鍵である

(2025/10/26)

Python 20年史──脚光の裏にあった「日本語対応」と「パッケージ配布」

Python 20年史──脚光の裏にあった「日本語対応」と「パッケージ配布」 (1/3)|CodeZine（コードジン）

(2025/10/26)

シニアエンジニアから学んだ考え方

シニアエンジニアから学んだ考え方 - Cybozu Inside Out | サイボウズエンジニアのブログ

(2025/10/26)

システムの引き継ぎに失敗しないための本

システムの引き継ぎに失敗しないための本担当者の交代、ベンダー変更、アウトソーシング化に対応できる！｜ SEshop｜翔泳社の本・電子書籍通販サイト

担当者の急な退職などで発生する引き継ぎ。

いざ始まると「前の担当者と連絡が取れない」「引き継ぎ書の内容が意味不明」「書いてあるコードが難しくて読み解けない」などさまざまな問題が生じるもの。

「システムの引き継ぎ」について検索しても、断片的な記事や簡易的な説明しか得られませんでした。

そこで本書は、全体像と具体策を一度に学べる手厚いつくりで、これまで当事者が抱えてきた悩みを解消できるようにしています。

〇本書のポイント

・計画～実施～安定稼働まで、引き継ぎの全工程を体系的にしっかり解説

・炎上案件や未完成システムなど、困難な立て直しの事例も豊富に収録

・引き継ぎトラブルを知り尽くした著者の教えるノウハウだから、現場ですぐに役立つ

・使いやすい引き継ぎ書のフォーマット付き

〇こんな方におすすめ

・退職、異動、外注切替などで引き継ぎを担う現場の担当者

・経営者、総務部門などの立場の方

・1人しか情報システム担当者がいないケースの後任者

・外部ベンダー、開発会社の担当者

この一冊を読めば、どんな場面でも慌てず、確実にシステムを守り抜くことができるようになります。

MEMO:

2025/11/12発売

(2025/10/25)

「化け物ハッカー」にはなれない、と気づいた先に。新多真琴が自分を認められるまで

「化け物ハッカー」にはなれない、と気づいた先に。新多真琴が自分を認められるまで | LIFE DRAFT

要約:

■ 1. 「ハッカーの呪縛」からの解放

新多真琴(あらたま)氏が2023年3月のYAPCで行った講演「あの日ハッカーに憧れた自分が、『ハッカーの呪縛』から解き放たれるまで」は大きな反響を呼んだ

新卒で入社したDeNA時代に自らにかけた「ハッカーの呪い」とは、技術で突き抜けなければならないという強迫観念であった

この講演はエンジニアとして「技術で突き抜ける」以外の道を示す内容で、多くの人が救われる思いをした

■ 2. 現在のキャリア

DeNA退社後は二つの企業を経て、Cake.jpで若くしてCTOを経験した

現在はLayerXでエンジニアリングマネージャーを務めている

音大卒で、プログラミングを学び始めたのは大学生になってからというユニークなキャリアである

メディア出演の機会も多く、自分を客観視している印象だが、キャリア初期は「自分を見る鏡が磨かれていなすぎて、虚像を見ていた気がする」と語る

■ 3. 自己分析能力の獲得

自己分析が得意になったのはここ6、7年くらいで、以前はもっとぼんやり生きていた

紆余曲折を経て、自分とちゃんと向き合った方が自分にとってもいい人生にできるし、関わる人に対してもいいものを渡せると気づいた

きっかけ: 以前いた会社で思ったほど評価されないと感じ、すごく頑張ってプロダクトにいい影響を与えたはずなのに意外と評価されないと思った

気づき: 「結果を出していれば評価は後からついてくるでしょ」というのはすごく傲慢な物言いで、評価する側がどう評価したらいいのかを判断するための材料まで含めて渡すことが被評価者としての義務である

■ 4. 評価のされ方の学習

改善策:

「期が締まるまでにここまで打ち上げます」という宣言をする

月ごとに振り返りつつ、実際に期が締まるタイミングで「もともと言っていたところにこれくらいオンしました」「あとこのくらいでした」「この部分はこういう評価になりますよね」というところまでまとめて渡すようにした

そうしたら結果がついてくるようになった

きっかけ: VPoEに「マネージャーという仕事をたいして知らなくない?」と言われ、マネージャーとは何かを調べ出した

学習過程: 本を読んだり、メンバーレイヤーでもできそうなマネジメントスキルやリーダーシップを発揮しようとやってみた

■ 5. DeNA時代の新人メンター経験

新卒2、3年目のときに下の代のメンターをやることになったが全然うまくいかなかった

ずっと新卒に「正論パンチ」しまくって、お互い険悪になった

原因: 自己肯定感も全然なかったので、自分のできることはみんなもできることと思ってしまっていた。その尺度で話してしまうと「なんでこんなこともできないの?」みたいなことを言ってしまった

マネジメントに関して改めてインプットし始めたタイミングで、初めてそのときに抱えた傷を自分でちゃんと解釈して落とし込めるようになった

■ 6. DeNA時代の「化け物」との比較

DeNA時代のあの環境には「化け物」がいっぱいいたため、ずっと一番下だと思っていた

何をやっても自分は最下層だと感じていたが、実際はそれなりに働いていて評価もされていた

しかしそれを客観的にキャッチできていなかった

自分の中のイメージとギャップ: 技術的に突き抜けていないといけないと考えていた

周りには突き抜けた人たちがいっぱいおり、彼らを見て何かを捨てることなく差を縮めようとするが全然縮まらなかった

■ 7. 評価のギャップ

周りからの実際の評価:

周りは別に突き抜けることなんて求めていなかった

むしろプロジェクトを前に進めることや周りを巻き込むこと、何とかして物事をうまく行かせる力があるという評価をされていた

当時の認識: 「そんなものはやったら誰でもできるじゃん」と思っていた。プロジェクトマネジメントみたいなことを任されるのはたいして期待されていないからだろうと思っていた

ひねくれていた状態であった

■ 8. 職人タイプへの憧れの理由

ひとかどの人間になりたかった

それがいいとされる価値観だった

YAPCというPerlハッカーのカンファレンスでいいねとされる人たちはやっぱり技術的に頭一つ抜けていた

世の中を文字通り技術で変えにいっている人たちだった

そういう人たちに憧れてDeNAに入社を決め、ハッカー集団がいる部署に絶対に行きたいと考えた

「卒業して配属研修を終えて、もしそこに配属されなかったら辞めます」くらいのことを言っていた

■ 9. オーケストラの指揮者としての役割

実際は尖った人たちばかりいてもチームとしては機能せず、まとめる人や間をつなぐ人もやっぱり必要である

オーケストラの指揮者のような役割を自分はできていたが、そこがチームに足りていないとも思っていなかった

そのポジションの重要性は全然わかっていなかった

なにやらありがたがられている、なにやら評価されているらしいことはわかるが、それは自分の実力がないからだという認識が結構長く続いた

それは退職してからもずっと続いた

■ 10. 仮想敵の問題

同年代の仲間でも技術で頭角を表している人はいるので、そういう姿を見てしまうと翻って自分はと思ってしまう

仮想敵が強すぎた

■ 11. ピアノと音楽のキャリア

幼稚園から始めて中学では合唱部で伴奏をやっていた

音楽は自分のアイデンティティだった

学校に一人とか学年に一人いるピアノが上手い人だった

小学校のときのピアノの先生に「あなたいいわね」「音大附属に行きなさい」と言われて調子に乗って「絶対に音大に行く!」と言ってしまった

高校2年くらいまではピアノで食べて行こうと思っていたが、入学した頃からだんだんと陰りが見え始めた

音大には「学校に一人いる上手い奴」が全員集まるため、どんなによく見積もっても「中の上」くらいに思えてしまった

家庭環境が音楽一色の子たちがたくさんいて、どう頑張ってもその子たちのようには弾けないなと悟った

■ 12. 音大でのピボット

初めて今後の人生について考え始めた: 音楽では食っていけないのではないか

ヤマハの先生になりたいわけでもなく、「ピアノじゃないかも」と思った

すでに高2高3なので他大を受験するには遅すぎた

附属からそのまま上がった大学で何か面白そうな学科を探し、コンピュータを使って作曲する学科があることを発見した

パソコンが好きだったことと、唯一就職率についての言及があったため、「ここにいけば食いっぱぐれることはなさそう」という邪な気持ちもあり受けて滑り込んだ

■ 13. プログラミングとの出会い

コンピュータ音楽専修という学科で、コンピュータ技術の発展とともにできるようになった表現を取り入れて音楽創作の新しい姿を模索する

プログラミング、C言語の基礎科目があり、「ちょっと面白いかもしれない」と思った

周りは軒並みぐったりしていて「あれ、楽しいと思うのは私だけ?」と感じた

そこで初めて「人よりもちょっとできる」というものが見つかり、そこからクリエイティブコーディングに走り始めた

卒業制作では音大の卒制に音の出ないアプリを提出するという暴挙に出た

■ 14. インターンとDeNA入社

学生時代からGoogleやカヤックなどにインターンに行っていた

1年の真ん中頃にはもうプログラミングにハマっていた

カヤックのインターンでお世話になった社員が誘ってくれたのがYAPCで、そこで当時DeNAで尖った人たちをまとめるマネージャーをしていたhidekさん(木村秀夫さん)の基調講演を聞いた

hidekさんの話を聞いて「この会社だったら自分も成長できるのではないか」「ここに行きたい!」となった

ここで憧れが強く形成されてしまったばかりに、この先10年悩まされることになった

■ 15. 挫折の認識

当時の自分はピアノや作曲に関する挫折を挫折として認識していなかった

なんならピボットしてやったぜ、みたいな感覚だった

「おもしろ重視で全部の話に乗っかっていったら、気づいたらエンジニアになってました」くらいの気持ちだった

DeNAの最終面接で「これまでにした一番大きな挫折はなんですか?」と聞かれたときも「いや、ないっすね」と答えた

「じゃあ高校とか大学のことを振り返ってみましょう」と言われていろいろ話していたら「それって挫折じゃない?」と指摘されて「はっ、そうか!」と気づいた

■ 16. 虚像からの脱却

自分を見る鏡が磨かれていなすぎて、虚像を見ていた気がする

技術で突き抜けることが求められていることだと思っていた

期待に応えられていないとずっと思っていて、それが苦しかった

尊敬するマネージャーの先輩もいたが、自分はそうではなく技術で突き抜けることを期待されていると思い込んでいた

誰も頼んでいないのに

■ 17. 腹落ちのタイミング

それが虚像だったと腹落ちさせられたのは2023年3月である

YAPCで例の講演をしたときである

4社目のCake.jpでCTOとして2年くらいやって、事業を前に進めるために必要なことや会社を会社たらしめるために必要なこと、その中でエンジニアが担うべきロールを曲がりなりにも言語化できるようになってきた

ちょうどYAPCがあるということで、キャリアを振り返ってみようと思った

2011年に火を灯してもらったところから今までを振り返って、ハッカー憧れを自分はどういうふうに昇華させていったのかというプロポーザルを出した

■ 18. YAPCでの反響

通ってしまったので頑張って話したら想定以上の反響があった

びっくりしたのは、自分と同じようにもがき苦しんでいる人がこんなにもいるのかということ

特に若手の新卒3年目くらいまでの人は、自分なりの価値基準がまだできていないから、周りの強い人たちを見て「自分はこんなに強い人にはなれないのではないか」「この先エンジニアとしてキャリアを歩んでいくのにふさわしくないのではないか」といったことを考えてしまう

そうやって苦しんでいる人がすごく炙り出された

かつての自分みたいな人が今でもたくさんいるということと、そういう人たちに対して「こういう価値基準もあるよね」というものを一応お渡しできたという実感ができた

それで「ああ、やめよう」「もう大丈夫だな、私は」と思った

■ 19. CTOという肩書き

CTOに就任したときは「やっていることに名前がついただけだな」という感じだった

入った段階からそのポジション前提でオファーをもらっていた

「CTOになった!」という特別な感慨はない

ただ、CTOというパスがあると入れる場所が結構あり、それによって得られたコネクションや知見がすごくあるので感謝している

■ 20. LayerXへの転職

学生スタートアップをやっていたときの同僚にLayerXのCTOの松本がいた

仲は良かったのでその後も年に2回くらいのペースで会って、壁打ちや「最近どう?」みたいな話はずっとしていた

前職から「CTO候補としてどうか」というオファーをもらったときに松本に相談したら「あらたまさんはバランサータイプだからたぶんいける」と言われて、なるほど、彼が言うならきっといけるんだろうと思ってオファーを受けた

「あのとき背中を押してくれてありがとう、ところでそろそろ」みたいな流れで転職した

転職をする際は一緒に働く人を重視する

きっかけとしては人に誘ってもらって興味を持って、この人「たち」と働きたいになれたら移ってくる

■ 21. 現在の立場とハッカーへの憧れ

EMという立場になった今でも、ハッカーへの憧れは固執しなくなったというだけで今もある

あるのも含めて自分だと思えるようになった

そこに対して手を伸ばし続けるために、技術力、エンジニアリングからすごく離れるみたいなことは今はやりたくないと思っている

相対的に割合が減って1割とかになってしまってもそこは手を伸ばし続ける

■ 22. 会社と人の関係性

会社って結局人が寄り集まって事を成しているものなので、それをブーストさせるのも棄損させるのも人と人の関係性だと思っている

事業に関する戦略をどう立てるかももちろん大事だが、それをどうやり抜けるかも会社がちゃんと成長していくためにはすごく必要なファクター

そのためには関係性というのが一番テコがかかるところだと思っているし、自分はそこに力を割くことがパワーの全体総量を一番大きくできると考えている

これからもそういうところに手を当て続けることを考えるんだろうなと思っている

■ 23. 技術書と組織本の読書比率

技術書を読むスピードよりも組織などの本を読むスピードの方が早い

エンジニアリングや技術が自分の中で占める割合が以前より小さくなっているとは言える

そのことに対する寂しさはあまりない

たぶんHOWに関するこだわりがそんなにない

LayerXは割とそういう人が多く、「無法者集団だね」と話している

「成果が出るならなんでもいいじゃん」みたいな感じが結構好きである

■ 24. 内発的動機の重要性

自己評価を他者に委ねているうちは何をやってもダメだと思う

それよりは内発的動機に目を向ける機会がもっとあれば良かったと考える

内発的動機は「これをやりたいんだ!」という強烈な欲求のようなものとして立ち現れることはそうそうない

「これよりはこっちの方が自分は楽しめるな」とか「他の人が発揮していないこだわりを発揮しちゃってるな」とか「他人がやっているこれが許せない!」など、自分の心が動いた瞬間をちゃんと自分でキャッチして、それはなぜなのかを深掘りしていく

それをよりできるためには誰にどうしたらいいだろうというふうにアクションにつなげていく

それを繰り返すことで自分自身を認めてあげることにもなるし、多少なりとも評価がついてくるようにもなる

■ 25. やり切ることの重要性

音楽に関してもエンジニアリングに関してももしかしたら諦めるのが早過ぎたなと振り返って思う

ピアノはまあまあやっていたが、もっと頭を使って演奏できたよな、何も考えずに取り組んでいたなと思ってすごく悔しくなったタイミングが数年前にあった

作曲に関しても苦手だなんだと言って、やる前から諦めていなかったか

基本的にアウトプットの質はインプットの量とそれをどう経験に落とし込めたかの掛け算だと思っている

それをやってきたかと言えば、やらないうちに諦めていたというのがあって、すごくもったいなかったなと思うし今でも後悔していることの一つ

「やり切ったけど、ここまでの高みには届かなかった。だからばっさりやめて次の道を探そう」と言えた方がしこりが残らなくていい

自分なりにやり切ることは改めて大事にしたいと思っている

■ 26. 自分がよしとする基準

周りからの評価以前に、自分なりにやり切れたと言えるかどうかが大事である

自分がよしとすればいい

何をもってよしとするかの判断基準が、他者から認められるとか名声を得るとか、他者に依存した自分ではコントロールできないものになってしまうと苦しい

■ 27. コピーバンドの経験

最近コピーバンドを始めた

飲み会の後に「好きな曲を好きなだけ歌い散らすカラオケをやろう!」となり、その中の一人がめちゃくちゃテンションが上がって「バンドやろう!」と言い出した

後日「スタジオを借りました」「課題曲はこれ」「あらたまさんはボーカルね」と言われた

まさか自分がバンドでボーカルをやるなんて夢にも思わなかったが、せっかくだからやってみようと思ってやってみたらすごく楽しかった

昔はそういうアマチュアの活動はただお金が出ていくだけだしなんのためにやるんだろうくらいに思っていたが、集まって何かを一緒に作るという体験自体が何事にも変え難い楽しさとして認識できるんだと飛び込んでみて気づいた

10年前だったら間違いなく誘われても「いいです」となっていたと思う

(2025/10/25)

/note/tech

MEMO:

要約:

MEMO:

要約:

要約:

MEMO:

MEMO:

MEMO:

要約:

要約:

要約:

MEMO:

要約:

要約:

要約:

MEMO:

MEMO:

要約:

MEMO:

MEMO:

MEMO:

要約:

MEMO:

要約:

MEMO:

要約:

MEMO:

MEMO:

MEMO:

要約:

MEMO:

要約:

関連:

関連:

要約:

要約:

要約:

MEMO:

要約:

MEMO:

要約:

要約:

MEMO:

要約:

tag:

要約:

関連:

要約:

MEMO:

要約: