/note/tech

AIが書かなくとも、クローズドソースがメジャーな時代からソフトウェアをずっと使い続けているので...

AIが書かなくとも、クローズドソースがメジャーな時代からソフトウェアをずっと使い続けているので、別にソースが読めなくても気にはしないのだが、一方で、昔のクローズドソースソフトウェアには、立派なドキュメントが付属していたのだ。MSのドキュメントは極めて充実していた。今や、ソフトウェアもゴミ、ドキュメントもゴミ。

@espresso3389

MEMO:

• MSDNのドキュメントはそんなに立派だった記憶は無いが

(2026/05/27)

Linuxにも年齢確認を強制する法案、批判殺到で修正へ

• Linuxにも年齢確認を強制する法案、批判殺到で修正へ - GIGAZINE

要約:

■ 1. 概要

• カリフォルニア州のデジタル年齢保証法(AB 1043)は、OSプロバイダーにユーザーの年齢情報収集を義務付ける法律
• Linuxコミュニティからの反発を受け、オープンソースOSを対象外とする修正法案(AB 1856)がカリフォルニア州議会で審議されている

■ 2. デジタル年齢保証法(AB 1043)の内容

• 概要:
  • OSのアカウント設定時にユーザーの年齢情報を入力させ、アプリ起動時に年齢区分信号をアプリ開発者へ渡すことをOSプロバイダーに義務付ける
• 年齢区分:
  • 13歳未満
  • 13歳以上16歳未満
  • 16歳以上18歳未満
  • 18歳以上
• 施行予定日: 2027年1月1日
• 罰則:
  • 過失による違反: 影響を受けた子ども1人あたり最大2,500ドル(約40万円)の民事制裁金
  • 故意による違反: 最大7,500ドル(約120万円)の民事制裁金

■ 3. 対象範囲と問題点

• OSプロバイダーの定義:
  • 「コンピューター、モバイルデバイス、その他の汎用コンピューティングデバイス上のOSソフトウェアを開発、ライセンス供与、または管理する者」と広く定義
  • Windows、macOS、Android、iOSに加え、LinuxディストリビューションやSteamOSも対象に含まれる可能性が指摘された
• Linuxに対する問題点:
  • 多くのLinuxディストリビューションはボランティアやコミュニティによって維持されており、単一企業が管理する商用プラットフォームではない
  • ユーザーアカウント機能や利用状況の送信機能を持たないディストリビューションが多く、年齢確認のための個人情報収集システムを新規実装する必要が生じる
  • 批判者は「法律の文言が広すぎるため、オープンソースOSを年齢確認プラットフォームに変えることを技術的に強制しかねない」と主張

■ 4. Ageless Linuxの登場

• 2026年3月、デジタル年齢保証法への意図的な不遵守を目的とした「Ageless Linux」が登場
• DebianベースのLinuxディストリビューションであり、ユーザーの年齢情報を収集しないことを掲げる
• 開発者のジョン・マッカードル氏の主張:
  • 年齢確認システムを実装できる資金や人員を持つのは大企業だけ
  • 小規模な開発者やボランティア中心のLinuxディストリビューションにとって、同法は大きな負担となる

■ 5. 修正法案AB 1856の内容

• AB 1856(2026年5月18日版)の修正内容:
  • OSプロバイダーの定義から「受領者がソフトウェアをコピー、再配布、変更できるライセンス条件でOSまたはアプリを配布する人や団体」を除外する文言を追加
  • オープンソースライセンスで配布されるOSはデジタル年齢保証法のOSプロバイダーに該当しない方向
• AB 1856はデジタル年齢保証法の廃止法案ではなく、OSプロバイダーの定義を狭める内容にとどまる

■ 6. 今後の焦点

• 独自のアプリストアや商用アプリ配信基盤を持つOSは引き続き対象となる可能性がある
• SteamOSのようにLinuxベースでありながら独自の商用アプリ配信基盤と強く結びついたOSが対象外となるかは不透明
• 商用プラットフォームとオープンソースOSの線引きが今後の焦点となる

(2026/05/27)

RESTはどのようにバズワード化したか

• RESTはどのようにバズワード化したか | BEAR Blog

要約:

■ 1. RESTの本来の定義と一般的な誤解

• 一般的にREST APIは「リソース指向のURL設計とHTTPメソッドによるCRUD操作のスタイル」として認識されている
• 本来のRESTは、サーバーのレスポンスに含まれるリンクを辿ってアプリケーション状態を遷移させる、ハイパーメディアを基本とした分散システムの設計原理である
• RESTはAPI設計手法ではなく、HTTPの設計原理を体系化した分散ハイパーメディアシステムの概念である

■ 2. REST論文成立の背景

• 時系列:
  • 1996年: Roy T. FieldingがTim Berners-LeeらとHTTP/1.0（RFC 1945）を策定
  • 1997〜1999年: FieldingがHTTP/1.1の共著者として設計に深く関与し、プロキシ可能性・キャッシュ可能性を損なうMGET・MHEADの提案を却下
  • 2000年: Fieldingがカリフォルニア大学アーバイン校に博士論文「Architectural Styles and the Design of Network-based Software Architectures」を提出

■ 3. Fielding論文の内容

• 論文の動機:
  • 新しいAPI設計手法の提案ではなく、HTTP/1.1策定プロセスで採用したアーキテクチャ上の原理を事後的に体系化したもの
  • HTTPの設計判断を振り返り、その背後にあった原理を「REST」として定式化した
• 論文の主題:
  • 主題はネットワークベースのソフトウェアアーキテクチャスタイルの分類学であり、RESTが直接語られるのは1章のみ
  • Pipe-and-Filter、Layered-Client-Server、Client-Cache-Stateless-Serverなどの分類スタイルが並列に論じられ、RESTはこれらの制約を組み合わせた派生スタイルに位置づけられる
• 論文の核心的メッセージ:
  • 「一つのアーキテクチャスタイルをすべてに使うな。アプリケーションの要件に合ったスタイルを選べ」
  • RESTの適用範囲は「大粒度のハイパーメディアデータ転送」に最適化されており、他の形式には最適ではないと明記されている
  • 対象問題領域はWebそのものの構造（組織や国境を越えたドキュメント接続）であり、企業内のバックエンドAPIやモバイルアプリのBFFではない
• 統一インターフェース（Uniform Interface）の4つのサブ制約:
  • リソースの識別（Identification of Resources）: すべてのリソースにURIで識別できるアドレスを与える
  • 表現を通じたリソースの操作（Manipulation of Resources through Representations）: リソースそのものではなく表現（JSON、HTML等）を介して操作する
  • 自己記述的メッセージ（Self-descriptive Messages）: メッセージ自体に処理に必要な情報がすべて含まれる
  • HATEOAS: 次に何ができるかはサーバーが返すリンクが示し、クライアントはそのリンクを辿って次のアクションを発見する

■ 4. SOAPの時代とRESTバズワード化の過程

• SOAPの時代（2000年代前半）:
  • XMLベースのSOAPが企業間サービス連携の主流であり、WSDL・UDDI・WS-Securityなどの関連仕様が層をなしていた
  • 形式性が信頼性の証とみなされていた
• RESTバズワード化（2000年代中頃）:
  • SOAPの複雑さへの反動として「HTTPの機能をそのまま使う」アプローチが浮上した
  • 2004年、英国オックスフォード大学のMatthew J. DoveyがFielding論文を参照しつつ「REST maps the CRUD operations onto the HTTP verbs」と記述した記事を公開した
  • SOAPへのカウンターカルチャーのバズワードとして「REST」という言葉が流通し始めた
  • TwoBitHistory（2020年）はこのアプローチをFIOH（Fuck It, Overload HTTP）と呼び、FIOHそのものには問題はないが、FIOHに過ぎないものに「REST」という学術的名称が被せられたことが問題だと指摘した

■ 5. DHHとRailsによる普及

• 2007年のRails 2.0リリースでSOAPサポート（ActionWebService）がデフォルトから廃止され、RESTfulルーティングがフレームワークの中心的な規約として導入された
• DHHの判断は無知に基づくものではなく、Fielding論文を理解し、Fielding本人と直接対話し、HATEOASを試みた上で「自分には要らない」と判断した意図的な選択であった
• 2012年のブログでDHHは導入動機を「知的純粋性のためではない」と述べ、HATEOASを「completely overblown（完全に過大評価）」と断じた
• 「REST」の名を選んだ背景には、アンチSOAPの旗印としてのマーケティング的意味と権威づけの意味があったと筆者は考察している

■ 6. Fielding本人の反応と「RESTish API」の誕生

• 2008年、FieldingはブログにてあらゆるHTTPベースのインターフェースをREST APIと呼ぶ状況に対するフラストレーションを公表した
• 今日「RESTful API」と呼ばれているもの（RESTish、すなわち「なんちゃってREST」）の規則群:
  • URL設計: リソースを名詞で表現し、階層構造をパスで表す
  • HTTPメソッドのCRUDマッピング: GET（取得）、POST（作成）、PUT（全体更新）、PATCH（部分更新）、DELETE（削除）
  • ステータスコードでビジネスロジックの結果を表現する
  • データ形式はJSON
  • OpenAPI等の外部ドキュメントでエンドポイント仕様を共有する
• この規則群はFieldingが定義した統一インターフェースの4つの制約とは異なるものである

■ 7. リチャードソン成熟度モデルとベストプラクティス化

• 普及の経路:
  • 2007年: O'ReillyからREST名を冠した初の本格書籍「RESTful Web Services」（Richardson、Ruby著）がCRUD-over-HTTPスタイルを体系的に解説
  • 2008年: Richardson Maturity ModelがQConで発表され、2010年にMartin Fowlerが記事化して広く知られるようになった
  • 2012年: Apigeeが「Web API Design」eBookを公開し、「pragmatic REST」を提唱、Fieldingの論文に忠実な立場を「RESTifarian（REST原理主義者）」と呼んだ
  • 2016年: GoogleがApigeeを買収し、体系化に権威が加わった
• リチャードソン成熟度モデルの構造:
  • Level 0: HTTPを単なるトランスポートとして使用
  • Level 1: 個別のリソースにURIを割り当てる
  • Level 2: HTTPメソッドを使い分ける（実質的に「RESTful」と称される水準）
  • Level 3: HATEOAS（最上位の「到達すれば理想的」なオプション扱い）
• FieldingがRESTの必須要件と位置づけたHATEOASが、このモデルではオプションに格下げされている
• 2013年のO'Reilly書籍「RESTful Web APIs」はハイパーメディアを中心に据え直した「前著の完全な置き換え」を意図したが、誤用はすでに定着していた

■ 8. 修正が機能しなかった構造的理由

• 誤用への指摘は繰り返されたが、議論は「どちらが実用的か」という話にすり替えられた
• 「それはFieldingのRESTではない」（事実の問い）に対して「でも便利だから」（実用の問い）が反論として機能してしまう構造がある
• 事実の問題が価値判断の問題に置換されることで、誤用は誤用のまま定着し続けた

■ 9. 三つの問いの区別

• 混同されている三つの問い:
  • 事実の問い: Fieldingの論文は何を書いていたか
  • 実用の問い: CRUD-over-HTTPは便利か
  • 命名の問い: それを「REST」と呼ぶ必要があったか
• 実用の問い（2番）の答えは「はい」であるが、2番が正しいことは事実の問い（1番）や命名の問い（3番）への回答にはならない
• 「REST論争」ではこの三つが「学術的な正しさ vs 実用性」という二項対立に圧縮されてきた

■ 10. Fieldingの回顧

• 2017年のESEC/FSE講演でFieldingは「RESTはバズワードになった。別にかまわない——この私か、私と働く人間でさえなければ」と述べた
• 2021年のツイートスレッドでFieldingは以下を述べた:
  • RESTはAPIについてのものではなく、ネットワークベースのアプリにおけるシステム間の相互作用についてのものである
  • APIが欲しい人々は「RESTから学べ」を「RESTを使え」と解釈してしまう
  • 当時、開発者を読者として想定しないと決めたのはFielding自身であると認めた
  • 「自分が対価を得ている理由は、自分の頭を使って自分のシステムの文脈に合わせた詳細を埋めていける能力があるからだ」と述べた

(2026/05/26)

ソフトウェアの見積もり

• ソフトウェアの見積もり - kawasima

要約:

■ 1. 概要と背景

• ソフトウェア工数見積もりは40年以上研究されてきた古いテーマだが、現場で流布する「常識」の多くは一次資料まで遡ると実証根拠が確認できない
• 確率分布を前提とした見積もり研究は、確率分布が原理的に書けない領域から来る大幅超過には対応していない
• 見積もりが大幅に外れる事例の多くは、見積もり研究が前提としてきた範囲の外側で起きている

■ 2. 見積もり手法の分類

• エキスパート判断系:
  • 直感見積もり、アナロジーベース見積もり、Wideband Delphi、Planning Poker、PERT 3点見積もりで構成される
  • 現場で最も広く使われており、Jørgensenの系統的レビューでは形式モデルと精度差が系統的に出ない
• 形式モデル系（パラメトリック）:
  • COCOMO、COCOMO II、SLIM、Function Point、COSMIC Function Point、Use Case Points、商用モデル（SEER-SEM等）で構成される
  • 入力パラメータと回帰式で工数を算出する
• 機械学習ベース（LLM以前）:
  • 回帰木/Random Forest、Case-Based Reasoning、浅層ニューラルネットワーク、Deep-SE（LSTM+RHN）で構成される
• 確率的見積もり / フロー計測系:
  • モンテカルロシミュレーション、Evidence Based Scheduling、スループット / サイクルタイムベース予測、参照クラス予測法、ベイズ推定、#NoEstimatesで構成される
• LLMベース:
  • GPT2SP、Few-shot prompting + Search-based最適化、比較学習、マルチエージェント合議、Embeddingベースで構成される
• 見積もり単位の並立:
  • KLOC、Function Point、ストーリーポイント、サイクルタイム、スループット等が流派ごとに並立している
  • ストーリーポイントの命名者Jeffries自身が2019年に後悔を表明している
• 手法・単位が多数並立しているにもかかわらず、「特定の手法がエキスパート判断を系統的に上回る」証拠は集計結果として出ていない（Jørgensen 2007）

■ 3. 見積もりが外れ続ける理由

• コスト超過の分布はガウス分布ではなくべき乗則分布に従う:
  • 5,392件分析（Flyvbjerg 2022）で18%のプロジェクトが50%以上超過、その平均超過率は447%
  • 「Double Whammy（2013）」は1,471件のICT累積分布に2つの転換点を見出し、第2転換点以降を「Black Swan Blindness」と命名した
• 超過の発生源は「分布の前提に入っていない事象」であり、確率分布が原理的に書けない「深い不確実性（Deep Uncertainty）」の領域に属する
• Cynefin frameworkは、因果関係が事前に分からない「Complex」領域および秩序が存在しない「Chaotic」領域では予測そのものが意味を持たないと論じる
• 列挙できる不確実性と列挙できない不確実性の区別:
  • 列挙できる不確実性: 事前に事象を挙げられ確率を付与できる。見積もりが対応できるのはこの層のみ
  • 列挙できない不確実性: 規制変更、外部API廃止、市場急変、組織方針転換等、見積もり時点で想定リストに入らない事象
• コンティンジェンシーバッファとマネジメントバッファは別建てで計上する必要がある:
  • コンティンジェンシーバッファ: 列挙できる不確実性の予測誤差を吸収する予備
  • マネジメントバッファ: 列挙できない事象に備える独立した予算枠
• 計画錯誤、アンカリング、戦略的虚偽表明、スコープクリープ等は研究が扱ってきた誤差要因だが、447%超過の発生源にはならない

■ 4. 古典の「常識」の実証検証

• 不確実性のコーン:
  • McConnell（2006）が広く流布させた「プロジェクト初期±4倍の幅が進行に伴い自動的に収束する」という経験則
  • 一次資料を辿ると収束を支える経験データは存在しない
  • Bossavit（2015）がBoehmの原典まで遡り、1981年の図は経験データではなく主観的スケッチであることを示した
  • Rothmanの現場データでは、小さい仕事が大きい仕事と同等かそれ以上に外れることを報告している
• 形式モデル系（COCOMO、SLIM、Function Point）:
  • Jørgensen（2007）の系統的レビューにより、形式モデルがエキスパート判断を系統的に上回ったとは言えないと結論された
  • 「パラメトリックモデルを導入すれば精度が系統的に上がる」という前提は研究集計で支持されない
• Chaos Report:
  • 「ITプロジェクトの大半が失敗する」「平均コスト超過189%」という数字は方法論的根拠を欠く
  • サンプリングが失敗プロジェクトに偏っている疑いがあり、他の独立調査の平均30〜40%と桁が違う

■ 5. エキスパート判断の系統的バイアス

• 順序効果（Jørgensen & Halkjelsvik 2019）:
  • 似たサイズのタスクが続くと後の見積もりが大きい方に引っ張られるコントラスト効果が生じる
  • サイズが大きく異なるタスクが並ぶと前の値に引きずられるアシミレーション効果が生じる
  • 大タスクを小タスクの直後に見積もると平均24%過小評価、小タスクを大タスクの直後に見積もると平均25%過大評価される
  • 熟練度では抜けられない（スキルレベルで統計的差異なし）
  • Planning Pokerセッションでは大小ストーリーを混ぜず、サイズ帯ごとにバッチ化することが対策となる
• 見積もりの加算性問題（Halkjelsvik & Jørgensen 2022）:
  • 加算が数学的に成立するのは期待値（平均値）のみ
  • 開発者が「典型的にはどれくらいか」と答えるのは中央値・最頻値に近く、合計すると系統的に過小になる
  • WBS分解＋合計は過小見積もりに偏る数学的な構造を持つ
  • モンテカルロシミュレーションは分布の畳み込みを取ることでこの問題を回避する
• MMRE（平均絶対相対誤差）の適切性問題（Jørgensen et al. 2022）:
  • MMREは最頻値を出すモデルだけを有利に評価する特性を持つ
  • 各モデルが分布のどの点を狙っているかが揃っていなければ比較結果は数学的に無意味になる
  • 開発者は最頻値を答え、計画担当者は中央値で資源配分し、モデルは平均値を出し、評価はMMREで行うという不整合が発生している

■ 6. 古典に代わる潮流

• 確率的見積もり（スループットベース予測）:
  • 過去スループット分布をモンテカルロ法で外挿し「85%の確率でN営業日以内に完了」等の確率付き予測を返す
  • Evidence Based Scheduling（Spolsky 2007）、Actionable Agile Metrics（Vacanti 2015）、Forecasting and Simulating Software Development Projects（Magennis 2011）が代表的
  • コーンの収束過程に依存せず、COCOMOのようなパラメータチューニングも不要
  • 限界: 過去スループットが外挿の根拠であるため、チーム構成・技術スタック・要件性質が変わると適用できない
• 参照クラス予測法（Flyvbjerg 2008）:
  • 内部視点の見積もりを類似プロジェクト群の実績分布（外部視点）で補正する
  • 元はインフラ建設の巨大プロジェクト向けに開発された手法
  • 1,471件のITプロジェクト集計（HBR 2011）で平均コスト超過27%、6件に1件が200%超過のブラックスワンを報告
• #NoEstimates運動:
  • Zuill、Duarte、Holubらが推進した「タスク単位の見積もりは推測に過ぎず害が大きい」という立場
  • Duarte（中道）: ストーリーポイントをやめ最近のスループットだけで予測する
  • Holub（過激）: 見積もりに使う時間で実装すべきと論じる
  • 予測そのものを否定しているわけではなく、タスク単位で見積もり数値を生成する活動を否定している
• Rothmanの整理:
  • 見積もりの行為は有用だが見積もり値はそうでもない（estimation useful, estimates not so much）
  • 計画は常に必要だが見積もりが必要なのは「学びを得る / 期日合意を要する場面」だけ
  • 計画と見積もりは別の活動として区別する

■ 7. 見積もりの用途区分

• 見積もりの用途ごとに要求される精度、単一値か分布か、責任の所在が異なる:
  • 契約・予算化: 発注側・受注側間の金額確定。単一値が要求され、参照クラス分布での補正を組み合わせる
  • コミットメント: ステークホルダーへの宣言。形式上は単一値だが内部では信頼区間上限を変換する運用もある
  • 計画立案: 分布で扱える領域だが現場では単一値に置き換わることが多い
  • 進捗予測: スループットベース予測が主に扱う用途
  • 意思決定支援: 桁感を掴む場合は単一値、リスク評価は分布
  • 学習・対話: 数値より過程に価値がある
• #NoEstimatesが否定しているのは主に計画立案用途で生成されるタスク単位の単一値見積もりであり、進捗予測の分布や対話用途の見積もり過程は否定の対象ではない
• 用途を混ぜると系統バイアスが発生する:
  • 契約用途の保守値で進捗予測すると常に余裕がありすぎる
  • 計画立案の最頻値で契約すると常に超過する

■ 8. 達成率指標とライトサイジング

• 計画ポイントに対する実績ポイントの達成率を計画予測可能性の指標にする運用は、計画立案用途の見積もり値を進捗予測用途の指標に流用する典型例となる
• 達成率を歪める要因:
  • ゲーミング: 見積もりインフレ、ユーザーストーリー以外の項目へのポイント付与
  • 計画値への主観混入: 直前イテレーションの結果に応じてストレッチ目標を上下させる調整
• Yesterday's Weather:
  • 直近3〜4イテレーションのスループットのみを使う簡易予測
  • モンテカルロ予測の中央値だけを取った簡易版にあたる
• ライトサイジング（Right-sizing）:
  • 作業項目を「N日以内に終わるサイズ」に分割してサイズ分布の上裾を切り落とす運用
  • サイズのばらつきが予測精度を下げる主要因であり、均一化することでモンテカルロ予測とSLEの予測幅が安定する
  • ストーリーポイントを置き換える運用でもあり、「揃った個数=スループット」として扱う

■ 9. LLMとAIコーディングの影響

• LLM見積もり研究の現状:
  • GPT2SP（IEEE TSE 2023）はDeep-SE比6〜47%の精度向上を報告したが、Tawosiらの再現研究（2022）でMAE計算バグによる精度水増しが指摘された
  • 再現研究では、GPT2SPが中央値ベースラインを統計的有意に上回るのは16プロジェクト中3件のみで、効果量も無視できる程度から小程度にとどまる
  • Çalıklıら（FSE 2025）はGPT-4等が人間と同じアンカリングバイアスを示すことを実験で確認した
  • プロジェクト横断での汎化の壁は依然として残っている
  • 「新SOTA論文が出る→再現研究で結果が覆る」という流れが繰り返されている
• AIコーディング時代の見積もり前提の変化:
  • METR（2025）のRCTにより、AI使用下で開発者は24%の高速化を予測したが、実測では完了時間が19%増加した
  • 見積もりの方向性そのものが予測と逆転した事例であり、外部参照クラスで補正できない状況を意味する
  • Microsoft/Accenture（2024）やGoogle（2024）のRCTでは26%・21%の効率改善が報告されており、AIの効果は対象集団・指標・タスク性質で方向が変わる
  • Frontiers AI（2026）は既存手法（COCOMO、ストーリーポイント等）が「人間のコーディング労力が支配的」という前提に乗っており、LLM支援開発下では工数の内訳がプロンプト設計・生成結果の検証・統合・往復に移ると主張する
  • 同論文はHybrid Intelligence Effortとして5次元（LLMの推論複雑性、コンテキスト完全性、コード変換の影響、反復推論サイクル、人間の監督工数）での見積もり枠組みを提案しているが、概念枠組みの段階にとどまる
  • AI導入の前後でサイクルタイム分布の母集団が変わるため、スループットベース予測の過去分布外挿は成立しない

■ 10. エビデンスの非対称と見積もりの組み立て方

• エビデンスの非対称:
  • 古典が支持されないことは示せても、代替が古典より優れていることまでは同じ密度で示せていない
  • 「古典に根拠なし」を示す作業は一次資料の追跡で可能だが、「代替が古典より良い」を示すにはRCT級の介入実験が必要で現実的に困難
• 見積もりを依頼するときに代表値を指定する:
  • 契約・予算化用途は平均値か信頼区間上限、計画立案用途は最頻値、進捗予測用途は分布を指定する
  • 指定がなければ開発者は無意識に最頻値を答え、集計・評価・契約に系統バイアスが発生する
• 参照クラスで内部見積もりを補正する:
  • 同業界・同規模・同技術スタックの類似プロジェクトを10件以上集める
  • 各プロジェクトの超過率分布を作成し、中央値・90パーセンタイル・最悪値を内部見積もりに掛けた3点を併記する
  • サブタスクの点見積もりを単純合計することは加算性問題により避ける
• 判断見積もりの順序を設計する:
  • サイズ帯ごとにバッチ化する
  • 相対見積もりのベースラインは中〜やや大のものを選ぶ
  • 順序効果は「気をつける」では避けられないため運用設計で吸収する
• バッファは二段で持つ:
  • コンティンジェンシーバッファ: 参照クラス分布の中央値〜90パーセンタイルの超過率を基準に算定する
  • マネジメントバッファ: 参照クラスの最悪値またはFlyvbjergのP90超過を基準に算定し、別費目で計上する
  • 不確実性のコーンを信じて「期間が進めば精度が自動的に上がる」と仮定してバッファを縮める運用は避ける
• 列挙できない事象は見積もりの仕事ではない:
  • Walking Skeleton: プロジェクト初期に最薄のエンドツーエンド実装を作り想定外挙動を引き出す
  • MVP / A/Bテスト: 仮説検証だけを目的にした小さな実装を本番環境に出す
  • スパイク: 不明領域に期限を切った調査タスクを置き未知を既知化する
  • これらはCynefinの「probe → sense → respond」循環に対応し、見積もりサイクルの外側に置く別系統の活動となる
• AI導入の前後でサイクルタイム分布は別物として扱う:
  • チケットにAI使用フラグを立て、AI導入前後で記録を分けてモンテカルロシミュレーションや参照クラスに混ぜない
  • AI後のサイクルタイムが30件溜まるまで予測幅を広める
  • 参照クラス予測法もAI導入前後で別建てにする

(2026/05/26)

コミュニケーションの摩擦は仕組みで減らす。フルリモート環境で開発案件をなめらかに進めるアプローチ

• コミュニケーションの摩擦は仕組みで減らす。フルリモート環境で開発案件をなめらかに進めるアプローチ - ぐるなびをちょっと良くするエンジニアブログ

要約:

■ 1. 記事の概要

• ネット予約システム開発チームによる、フルリモート環境でのコミュニケーション施策の紹介
• オフィスで自然発生していたコミュニケーションがリモート環境では生まれないため、意図的に仕組みとして設計した取り組みを対象とする

■ 2. リモートワークにおける課題

• オフィスでは隣席メンバーへの自然な声掛けや、すれ違いざまの状況把握が可能だった
• フルリモート環境では偶発的・自然なコミュニケーションが発生しない
• テキストチャット中心のやり取りにより「用件があるときだけ話しかける」状態になりがち
• 相手の状況や人となりが見えづらくなり、心理的距離やコミュニケーションの摩擦が生じやすい

■ 3. 実践した施策

• バーチャルオフィスとGoogle Meetの使い分け:
  • バーチャルオフィスは軽い声掛けやリアルタイムなステータス確認に使用
  • マップ上で「誰と誰が集まって話しているか」が可視化され、進行中の議論に自ら参加できる
  • Google Meetは画面共有を伴う設計相談や、文字起こし・録画を残す必要があるときに使用
  • バーチャルオフィスで話し始めた後、必要に応じてMeetへ切り替えることも可能
• 隔週30分のプライベートメインの振り返り:
  • 業務進捗確認とは切り離した、メンバーの人となりを知るための時間
  • 近況の食べ物や映画鑑賞など些細な日常の共有で十分とする共通認識を持つ
  • わずかな個人的背景の共有により、その後の業務連絡における心理的ハードルが低下する
• 毎日15時の集合タイム:
  • 些細な疑問（ドキュメントの場所、仕様の確認など）を気軽に質問できる固定の同期イベント
  • 「お困りごとがなければ即解散」を原則とし、数分で終了することが多い
  • 深い議論が必要なメンバーだけを残し、関係のないメンバーはすぐ作業へ戻れるよう運用
  • 「15時になれば確実に聞ける」という安心感がメンバーの自律的な行動を促す
• 新メンバー向けのなんでも会:
  • チーム歴の長いメンバーがホストとなり、暗黙知の解消を目的に実施
  • 新メンバーの不安解消だけでなく、ホスト側にもナレッジ不足や仕様理解の曖昧さへの気づきをもたらす
  • チーム全体のドキュメントや知見のアップデートを促すきっかけとなっている
• 雑談用Slackチャンネルの設置:
  • 業務チャンネルとは切り離した雑談専用チャンネルを用意
  • 技術ニュースから日常のつぶやきまで気兼ねなく発信・反応できる場として機能

■ 4. オンラインとオフラインのバランス設計

• 週次出社日や頻繁なオンライン飲み会は、メンバーの家庭事情や居住地の差異から一律強制が困難と判断
• 基本はフルリモートを維持し、開発部全体のイベントや歓迎会など特定のタイミングのみオフラインで集まる方針を採用

■ 5. 施策の成果

• 日々の開発案件において、テキスト行き詰まり時に口頭切り替えを躊躇なく行うカルチャーが定着
• 緊急トラブル発生時にもスムーズな連携と迅速な集合が可能になった
• 外部の業務委託メンバーから「経験した中で最も会話量が多くコミュニケーションが取りやすいチーム」との評価を得た
• 定期的な同期イベントの導入により、非同期コミュニケーションにおけるレスポンス待ち時間やテキストの書き方に悩む時間が削減された

■ 6. 今後の課題

• チーム内のコミュニケーション摩擦は大幅に減少し、開発案件をなめらかに進める土台が整備された
• チーム外（他チーム・他部署）との連携においてはリモート環境ゆえの壁が残っており、新たな課題として認識
• チーム内の取り組みを参考にしながら、チーム外ともよりオープンで滑らかな関係構築を模索していく方針

(2026/05/26)

「誰かが決めるだろう」をやめた。仕事を前に進めるための“やらないこと”

• 「誰かが決めるだろう」をやめた。仕事を前に進めるための“やらないこと” - Findy Media | IT/Webエンジニアの転職・求人サイトFindy – GitHubからスキル偏差値を算出

要約:

■ 1. 筆者と問題意識

• 筆者はソフトウェアエンジニア/データベーススペシャリストであり、予防医療領域のスタートアップでCTO・COOを務める
• 専門はRDBMS（特にPostgreSQL）を中心としたデータモデリングおよびシステム改善
• 「誰もやらない仕事」とは、やった方がいいとわかっているのに誰も手をつけない仕事のこと
  • 例: ドキュメント整備、テスト追加、CIの改善、再現性のない障害調査
  • これらは優先順位リストの下に沈み続け、やがて「誰もできない仕事」になる
• 「やらないこと」を決める目的は単に業務削減だけでなく、重要な仕事に集中するための時間と意思決定できる状態の確保にある

■ 2. 組織は意思決定しない: 決めるのは人

• 仕事が前に進まない原因:
  • 仕様が曖昧なまま放置されている
  • 意思決定者が定まっていない
  • リスクを誰も引き受けていない
  • 担当者が曖昧になっている
• 「組織として決める」という表現が用いられるが、実際に決めるのは組織に紐づいた個人である
• 筆者がやめたこと: 「誰かが決めてくれるだろう」と待つこと
• 筆者が代わりに行うこと:
  • 自分が決める立場なら決める
  • そうでなければ、決める人が決められる状態をつくる
  • 具体的な手段: 選択肢の整理、判断材料の収集、リスクの言語化、期限の設定、推奨案の提示
• 意思決定の裁量を握ることだけでなく、「決められる状態をつくること」自体が立派な仕事である

■ 3. 他人に期待することをやめた

• 「誰かが決めてくれるだろう」と待つことは、合意のない期待を相手にしている状態である
• 筆者がやめた期待の種類:
  • 「きっと察してくれるだろう」
  • 「そのうち誰かが拾ってくれるだろう」
  • 「あの人がなんとかしてくれるだろう」
• 合意のない期待の問題点:
  • 仕事が進まない
  • 責任の所在が明確にならない
  • 相手が何を求められているか分からない
• 期待の代わりに行うこと: 5W1Hの明確化
  • 誰がやるのか、何をやるのか、いつまでにやるのか
  • 何が完了条件なのか、何を決める必要があるのか、誰に決めてもらう必要があるのか
• 期待する代わりに「依頼する、明確にする、仕組みで解決する」という選択肢に切り替える
• 「分かってくれるはず」と黙っていることは相手に不親切であり、「誰かがやってくれるはず」と放置することはチームに不誠実な態度である
• 「誰もやらない仕事」の多くは悪意による放置ではなく、担当者が曖昧なだけである

■ 4. 自分に期待することをやめた

• やる気や頑張りに依存することをやめた
• 仕事の品質がやる気に左右されることはプロフェッショナルな振る舞いではない
• 仕事で重要なのは「やる気があること」ではなく「成果を出すこと」である
• 「頑張ります」に代わる具体的な仕組みづくり:
  • 「次は頑張ります」→ 次に何を変えるかを決める
  • 「気をつけます」→ 気をつけなくても間違えない仕組みをつくる
  • 「ちゃんと見ます」→ チェックリストをつくる
  • 「忘れないようにします」→ 自動化する
  • 「障害を起こさないようにします」→ 検知・迅速回復の仕組みをつくる
• やる気・頑張りは個人の状態に依存するが、仕組みは再現性があり、チームや会社の資産となる
• 気合いで乗り切ると問題が隠蔽され根本解決につながらない
• 「頑張らなくても成果が出る構造をつくること」に時間を使う

■ 5. 自分を仕事の枠にはめることをやめた

• 肩書の利点:
  • 役割の説明が容易になる
  • 周囲の期待と自分の責任範囲を明確にしやすい
• 肩書の弊害: 「これは自分のミッションではない」という線引きにより重要な問題を見過ごすことがある
• 「誰もやらない仕事」は職種と職種のあいだに落ちていることが多く、誰かが拾わなければ前に進まない
• 岩田聡氏（任天堂）の言葉: 「これは自分でやるのが最も合理的だ」と思えれば覚悟がすぐに決まる
• 肩書は責任を説明するためのものであり、自分の可能性を制限するためのものではない
• 問題の構造を整理した上で、「自分がやることが最も合理的」と判断できれば、自分がやれば良い

■ 6. 本質の見極めと構造化による仕事の前進

• 「やらないこと」を決めることは消極的な行為ではなく、何に責任を持つかを決める最初の意思決定である
• やらないことを絞ることで、自分が向き合うべき本質的な仕事が見えてくる
• 仕事は誰かが覚悟を決めて意思決定した結果として前に進む
• 「誰もやらない仕事」を拾い、構造化し、前に進め続けることでチームが強くなり、事業が前進する
• その積み重ねがキャリアの道となり、自分にしかできない仕事につながる

(2026/05/25)

「全ては会社の競争力を生み出すために」アーキテクチャを刷新し、ドメインモデリングも組織再編も...

• 「全ては会社の競争力を生み出すために」アーキテクチャを刷新し、ドメインモデリングも組織再編もエンジニア教育も一つ一つ丁寧に積み上げてモダナイズを進めた話｜CTOロングインタビュー - MonotaRO Tech Blog

要約:

■ 1. 企業概要とビジネスの特徴

• 企業理念は「資材調達ネットワークを変革する」であり、間接資材の調達工程を削減することで事業者の時間資源を創出することを目指す
• 約2,000万SKUを取り扱うB2B向けECサービスであり、モール型ECとは異なり自社で在庫を保有する
• サプライヤから顧客までのサプライチェーンをオペレーション、データ、ソフトウェアで最適化・コントロールする
• B2B商材特有の複雑性:
  • 注文数量のばらつきが大きく、数十～数百単位の発注が発生する
  • ロングテールの商品数が膨大であり、特殊なニーズへの対応が求められる
  • 納期のセンシティブ性が高く、遅延が事業者のビジネスに大きな影響を与える
• 10年連続で約20%の事業成長を実現してきた
• テクノロジーによる競争優位性の獲得を重要な方針として位置づける

■ 2. システム課題と解決方針

• 課題の背景:
  • 組織とシステムの拡大により複雑性が増し、新規取り組みに向けるリソースが不足している
  • ビジネス戦略に素早く対応するための変更容易性が確保できていない
• 解決方針として「分割統治」を採用する:
  • 大きな問題を小さな部分問題に分割し、個別に解決することで全体の複雑性に対処する
  • モノリスアーキテクチャからマイクロサービスアーキテクチャへの移行はその手段と位置づける
  • アーキテクチャ変更と同時に開発プラットフォームおよび開発プロセスを刷新する
  • 組織構造も開発アジリティが高まる形に変更する

■ 3. ドメインモデリングとアーキテクチャへの取り組み

• 組織再編の実施:
  • 逆コンウェイ戦略に基づき、2023年春にドメインに合わせた組織グループの分割を実施した
  • 2023年12月にはすべてのソースコードをいずれかのドメインに整理し、実行環境の分離を完了した
• ドメインモデリングの進め方:
  • AWSのソリューションアーキテクトのサポートを受けながら実施した
  • イベントストーミングを活用し、ビジネス側とシステム側の共通のビジネスモデルとユビキタス言語を獲得する
  • ドメイン境界に沿ってデータベースを分割し、他ドメインからアクセスするAPIを順次開発する
• イベントドリブンアーキテクチャの採用:
  • ドメイン間の疎結合化を促進するために導入を進めている
  • 業務イベントを抽出し、その事実情報を他ドメインに伝播させて処理する
• イベントストーミングによる発注ドメインの分析事例:
  • 発注点の算出とサプライヤー発注が密結合になっており、変更容易性が確保できていなかった
  • モデリング作業を通じて需要予測・在庫配置に関わる計算と発注コントロールの責務を分離すべきと判明した
• ヘキサゴナルアーキテクチャを採用し、業務ロジックをドメイン内に閉じ込めて変更容易性を維持する
• テンプレートリポジトリの整備:
  • CI/CDパイプライン、オブザーバビリティ、共通ライブラリを含む
  • 新規開発の立ち上げを高速化し、スキーマファースト開発や分散トレーシングなどのプラクティスを標準化する

■ 4. 商品検索体験向上への取り組み

• データ駆動による検索精度向上:
  • 商品情報に存在しない通称語（例: 「涙目」）での検索に対し、購買データの解析から意図を把握するアプローチを採用する
  • 6〜7億の商品カタログデータから属性データを作成し、言語処理解析により約7割を自動抽出する
• パーソナライゼーションの推進:
  • 顧客の検索履歴や購買履歴に基づき、カテゴリの上位表示を最適化する
  • 直前の閲覧・購買行動を含むリアルタイムデータを活用したパーソナライズ化を進めている
  • 検索結果画面のコンポーネントごとにアルゴリズムによる最適化を行い、ABテストで継続的改善を行う

■ 5. Tech組織の体制と取り組み

• Tech Visionの策定:
  • 「常に事業者に選ばれる世界で唯一の顧客価値を提供するため、データとテクノロジーを徹底的に活用する」と定義する
  • 組織規模が120名を超えた2021年ごろから価値観の統一が課題となり、策定に至った
• 5つのTech Principle:
  • 守→破→離: 世の中の「型」を学んだうえで、自分たちに合う形で改善する
  • 思考を言語化して伝える: 組織拡張に伴うコミュニケーションコストに対処する
  • 好奇心を育み、成功に導く
  • 生み出す価値を定義する
  • 自律と協調の両立: 各チームが自律的に動きながら、組織全体の最適化に貢献する
• ロールの設定:
  • 組織マネージャー、テックリード、プロデューサーなどの役割を明文化し、責務・権限・オーナーシップを明確化した
  • 権限集中やボトルネックを解消し、スケールしやすい組織体制を実現する
• プロダクト開発とプラットフォーム開発の分離:
  • プロダクト・ドメインチーム（ストリームアラインドチーム）は業務とサービスの進化に集中する
  • プラットフォーム組織はテクニカルな複雑性を引き受け、イネイブリングとプラットフォームの提供を行う
• 育成の取り組み:
  • コンピテンシーマトリックスを作成し、Tech PrincipleをJobグレードごとの具体的な行動指針に落とし込んだ
  • 社内育成機関「MonotaRO DOJO」を設立し、ドメインモデリング、アーキテクチャ、アジャイルなど多岐にわたるコースを実施する
  • 2023年中にMenuMapに基づくコースの第一回を実施した

■ 6. 今後の展望

• 在庫管理のさらなる高度化が企業理念実現の重要課題と位置づけられている
• サプライヤ（中小企業が多い）のDXを支援し、電子データによる在庫管理の普及を目指す
• サプライヤ支援まで含めることで、資材調達ネットワークとしての事業可能性が拡大すると見込む

(2026/05/24)

ハーネスエンジニアリングとは？AI時代の開発生産性を高める考え方と実践手順を解説

• ハーネスエンジニアリングとは？AI時代の開発生産性を高める考え方と実践手順を解説

要約:

■ 1. ハーネスエンジニアリングとは

• AIエージェントが継続的に正しい仕事を進められるように、環境・文脈・評価・フィードバックループを人間が設計する手法
• 「harness」はモデル単体ではなく、入力、ツール呼び出し、状態管理、評価、記録を束ねてエージェントとして機能させる土台を指す
• エージェント主導の開発では、人間の主な仕事が「コードを書くこと」から「環境を設計し、意図を指定し、信頼できるフィードバックループを作ること」へ移行する

■ 2. ハーネスエンジニアリングが必要な背景

• コード生成速度の増大に伴う課題:
  • OpenAIはエージェント主導で空のGitリポジトリから初期構成・CI設定・AGENTS.md・アプリケーション実装までを構築し、人間はプロンプト・環境設計・レビュー方針の設計に回った
  • コードスループットが上がるにつれて、ボトルネックが human QA capacity に移行することが判明した
  • AIが生成する差分量が増えるほど、確認待ち・差し戻し・手戻り・仕様の見落としが累積しやすくなる
• 組織能力の問題:
  • DORAは、AI導入の成否はツール単体ではなく、内部データ・ワークフロー・評価の仕組みといった組織能力に左右されると整理している
  • AIは「増幅器」であり、整った組織では強みを伸ばし、弱い組織では弱点を速く拡大する
  • 内部の情報基盤が弱いままAIを導入すると、入力がぶれ、レビュー負荷が増える

■ 3. 関連概念との層構造

• プロンプトエンジニアリング・コンテキストエンジニアリング・ハーネスエンジニアリングは横並びではなく、prompt ⊂ context ⊂ harness の包摂関係にある
• 各レイヤーの定義:
  • プロンプトエンジニアリング: 1回の推論で、どう指示を書くか（最も内側のレイヤー）
  • コンテキストエンジニアリング: その推論に、何の情報を入れるか（AIに何を見せるかを設計する考え方）
  • ハーネスエンジニアリング: 複数回の推論とツール利用を含む作業全体を、どう運転するか（最も広い概念）
• コンテキストエンジニアリングはハーネスエンジニアリングの重要部品だが、ハーネスそのものではない
• 「プロンプトを工夫しているのに成果が安定しない」場合、問題は書き方ではなく、渡している情報・評価ループ・引き継ぎ設計にある可能性がある

■ 4. ハーネスエンジニアリングを構成する4つの要素

• リポジトリ知識を正本にする:
  • 巨大なAGENTS.md 1枚にすべてを書き込む方法は失敗する
  • 短いAGENTS.mdを目次として使い、構造化されたdocs/ディレクトリをsystem of recordとして運用する
  • 「何が正本で、どこを見に行けばよいか」をエージェントに迷わせないことが重要
• アプリケーションとリポジトリをエージェントにとって読める状態にする（legibility）:
  • UI・ログ・メトリクスをAIが直接読めるようにする
  • エージェントから見えていないものは存在しないのと同じであるため、情報はリポジトリ内で発見可能かつバージョン管理された形に保つ必要がある
  • Google Docs・チャット・口頭で完結している情報はAIにとって不可視であるため、リポジトリ内に押し戻す
• フィードバックループを実装し、生成から修正までを自走させる:
  • AIに自己レビュー・追加レビュー・フィードバック反映・再実行をループさせ、Pull Requestを完成に近づける
  • 1つのプロンプトから現状確認・不具合再現・修正・再検証・PR作成・レビュー応答・マージまで進められる仕組みを目指す
  • 「出力をもらう仕組み」ではなく「検証とやり直しまで含めて作業を閉じる仕組み」として設計する
• アーキテクチャ原則を機械的に強制し、継続的に掃除する:
  • 完全自律に近づくほど、AIは既存リポジトリ内の不均一なパターンや最適でない実装も増幅する
  • 「AI slop（その場では動くが徐々に荒れていくコードベース）」の蓄積を防ぐために機械的な仕組みが必要
  • golden principles（機械的に判定できる明確なルール）をリポジトリに埋め込み、定期的なクリーンアップタスクを自動で回す
  • 生成時の制御だけでなく、生成後に蓄積するエントロピーを減らす運用まで含めて設計する

■ 5. ハーネスエンジニアリングの進め方

• 短いガイド（AGENTS.md）を入口の地図として作成する
• AGENTS.mdの構成:
  • このファイルの役割: 詳細仕様をすべて書く場所ではなく、参照先と作業ルールを示す入口
  • 最初に確認するもの: ARCHITECTURE.md、docs/product-specs/index.md など
  • 作業ルール: 仕様書の確認、ドキュメント更新、build/test/lint の実行
  • 完了条件: 仕様との整合性、テストと検証の完了、ドキュメント更新の反映
• ディレクトリ構造はdocs/以下にdesign-docs/・exec-plans/・product-specs/・references/などを整備する

■ 6. よくある失敗とまとめ

• よくある失敗:
  • AIの賢さを過大評価し、組織の未整備を過小評価する
  • ドキュメントが曖昧・レビュー基準が人依存・変更サイズが大きい・責任境界が曖昧なままAIを導入すると、生成量だけ増えて下流が詰まる
  • 「ツールを変えれば解決する」という誤解を持ち、開発プロセスや仕組みなどの構造を変えないまま運用する
• まとめ:
  • ハーネスエンジニアリングは、AIにうまく指示する技術ではなく、AIが継続的に成果を出せるように開発組織そのものを再設計する技術
  • モデルの性能よりも、AIが迷わず進め・途中でミスを検知でき・ミスを修正できる仕事の仕組みを作ることが重要

(2026/05/24)

ハーネスエンジニアリングを理解する

• ハーネスエンジニアリングを理解する - サーバーワークスエンジニアブログ

要約:

■ 1. ハーネスエンジニアリングの定義

• AIエージェントは「Agent = Model + Harness」の構造で表される
• 「ハーネス」とはAIモデルを正しく動かすための環境全体を指す
• AIの成果はモデルの賢さだけでなく、環境の設計によって決まる

■ 2. ハーネスの3つの基本要素

• ルールファイル:
  • AIへの行動規範を定義するファイル
  • ツールごとに配置場所が異なる（Claude Code: CLAUDE.md、Kiro: .kiro/steering/*.md、Codex: AGENTS.md）
  • AIが間違えやすいプロジェクト固有のルールに絞り、60行以内が目安
• フィードバックループ:
  • AIの出力を自動チェックし、問題があれば自動修正させる仕組み
  • コード生成→テスト実行→エラー情報のフィードバック→AI修正というサイクルで機能する
  • リンター、フォーマッター、型チェックも有効なフィードバック手段となる
• コンテキスト管理:
  • AIが長いタスクで作業内容を忘れないよう、進捗をファイルに記録して引き継ぐ仕組み
  • Anthropicは「初期化エージェント」と「コーディングエージェント」の2段階構成を推奨
  • 役割分担によりコンテキスト消費を抑えながら大きなタスクを遂行できる

■ 3. ハーネス設計の重要性

• SWE-benchの分析では、同一モデルでもハーネス設計の変更により20ポイント以上のスコア差が生じた
• フロンティアモデル同士を入れ替えた場合のスコア差はわずかにとどまる
• モデルを最新化するよりハーネスを見直す方が、成果への影響が大きい

(2026/05/24)

コードレビューを6段階にしたら、AIと人間の分業が見えた

• コードレビューを6段階にしたら、AIと人間の分業が見えた

要約:

■ 1. 3バグ通過の教訓と6段階モデルへの移行背景

• AIにLogic層を任せた結果、本番環境でエッジケース判定漏れ・空配列の扱いミス・外部APIリトライ条件のずれという3バグを通した
• バグを通した本質的な原因は、「AIが見ているから自分は見なくていい」という無意識の判断
• 3層モデル（自動ゲート・AIレビュー・人間レビュー）は粒度が粗く、Logic層に責任が集中する構造だった
• 6段階への切り直しにより、各段階の担当と境界が明確になった

■ 2. 6段階モデルの概要

• 3層モデルとの関係:
  • 3層モデルは「誰が何を見るか」の設計図
  • 6段階モデルは「AIと人間の境界線をどこで切るか」の解像度を高める補完的な定義
• AI比率の分布:
  • Stage 1 - Format: AI 100% / 人間 0%（ツール: pre-commit hook、Prettier）
  • Stage 2 - Lint: AI 100% / 人間 0%（ツール: ESLint、Ruff、mypy、tsc）
  • Stage 3 - Style: AI 90% / 人間 10%（ツール: CodeRabbit、GitHub Copilot）
  • Stage 4 - Logic: AI 60% / 人間 40%（ツール: Claude Code Review）
  • Stage 5 - Design: AI 30% / 人間 70%（ツール: ペアレビュー）
  • Stage 6 - Architecture: AI 0% / 人間 100%（ツール: シニアエンジニア、テックリード）
• 段階が下がるほど「正解が一意でない問題」へと性質が変化し、AI比率が低下する

■ 3. 各段階の詳細

• Stage 1 - Format:
  • インデント・空白・改行コード・末尾セミコロンをpre-commit hookで全自動処理
  • 人間の判断は不要
• Stage 2 - Lint:
  • 未使用変数・到達不能コード・暗黙的な型変換を静的解析ツールで検出
  • FormatとLintの区別: Formatは「見た目」の規約、Lintは「意味」の規約（Lintの違反は動作不良につながる）
  • Stage 1-2はPRに到達させない層であり、毎週30分の指摘時間を構造的にゼロにできる
• Stage 3 - Style:
  • 命名・関数分割粒度・コメントの過不足・可読性が対象
  • コードベース全体の命名規則に依存する判断は完全自動化不可
  • AIが90%の指摘を出し、人間が採用・却下を判断する運用
• Stage 4 - Logic:
  • N+1問題・SQLインジェクション・未処理例外・エッジケースが対象
  • AIバグ検出精度のベンチマーク: Macroscope 48%、CodeRabbit 46%、Cursor BugBot 42%、Greptile 24%
  • CodeRabbit vs Copilot比較: CodeRabbit F1 51.5% / recall 52.5%、Copilot F1 44.5% / recall 36.7%
  • AIは仕様書を参照できないため、ビジネスロジック由来のエッジケースを「コードとして正しい」と判定する
  • 通過した3バグの例: 空配列の処理スキップ仕様の見落とし、外部APIの429限定リトライ条件の誤判定、ページネーション境界の1件ずれ
  • 運用ルール: AIが指摘した部分はAIに任せ、AIが指摘しなかった部分こそ人間が念入りに確認する
  • AIコメントがゼロのPRほど仕様書を開いて精査する価値がある
• Stage 5 - Design:
  • 責務分割・APIの境界・依存関係の方向が対象
  • AIはコードベース固有のローカルルール（例: マルチテナントDB固有の制約）を読み取れない
  • AIへの期待は機械的なヒント（例: 関数が150行ある旨の通知）に留まる
  • ペアレビューにより、設計判断と個人の好みを区別できる
  • 設計の方向性はコードに先行する暗黙のチーム合意に依存するため、文章化されていない情報をAIに読ませることは原理的に困難
• Stage 6 - Architecture:
  • システム境界・データフロー・認証の責任範囲・デプロイ単位が対象
  • アーキテクチャ判断は「正解」ではなく「未来予想」であり、AIは責任を取れない
  • GitHub Copilotも公式に「アーキテクチャ上の懸念の多くを見逃す」と明記
  • PRレビューではなく、PR前の設計会議（ADR作成・テックリードによるファシリテート）として実施すべき
  • ADRを文章化することで、Stage 6の一部がStage 5やStage 4に降りてくる（文章化によりAI比率が上がる）

■ 4. 6段階モデルによるApproveの意味の変化

• 3層モデル時のApproveは「フォーマットOK・AIのOK・ざっと確認」の3点セット
• 6段階モデルでは、Approve前に「どの段階まで責任を持っているか」を自問する
• 各段階の確認（Format・Lint通過、Style同意、Logic仕様照合、Design検証、Architecture事前議論済み）が揃うことでApproveの重みが増す
• Logic・Designに不安がある場合は「Approveしない選択」をしやすくなり、「とりあえずLGTM」が出にくくなる

■ 5. チームへの導入ステップ

• Step 1: Stage 1-2をhooksで固める（1日で完了、即日効果が出る）
• Step 2: Stage 3にCodeRabbitまたはCopilotを導入（1週間慣らす）
• Step 3: Stage 4のための仕様書整備（最も時間がかかる、AI不可視の仕様由来エッジケースを明文化する）
• Step 4: Stage 5-6をチーム文化として育てる（ペアレビューとADRの習慣化）

■ 6. AIへの過度な依存のリスク

• Logic層（Stage 4）が最も危険な理由:
  • AIカバー率60%という「中途半端な高さ」が「7割ぐらいは大丈夫」という油断を生む
  • カバー率0%なら人間が全部見る、100%ならAIに任せるという明確な判断ができるが、60%はその中間にある
• AIレビュー導入チームに共通する認知的ショートカット: 「AIが見ているから自分は見なくていい」という無意識の判断
• 6段階モデルの最大の効用: Stage 4が「中間ゾーン」として可視化され、人間の集中力が最も必要な場所を認識できる
• AI比率の境界線をどこで引くかは、各チームが自分で決めるべきこと

(2026/05/24)

日々の開発で使っているClaude Code Skills

• 日々の開発で使っているClaude Code Skills

(2026/05/24)

複数集約を跨ぐ処理を1つのDBトランザクションで括る前に読む記事

• 複数集約を跨ぐ処理を1つのDBトランザクションで括る前に読む記事

要約:

■ 1. 問題提起: 複数集約を単一DBトランザクションに束ねることへの警告

• 注文確定処理において在庫集約と注文集約を同一トランザクションで更新するパターンが示される
• 複数集約を常にアトミックに更新する必要性を感じる場合、それは集約の境界設計を見直すべきシグナルである
• 集約とは整合性境界そのものであり、常に同一トランザクションで更新が必要な複数集約は、本来1つの集約として再設計すべき可能性がある
• この考え方はヴォーン・ヴァーノン『実践ドメイン駆動設計』やクリス・リチャードソン『マイクロサービスパターン』等の既存文献で既に整理されている

■ 2. 強整合の境界と弱整合の境界

• 整合性の境界は二層に区別される:
  • 集約の境界（強整合）: 内側の不変条件をアトミックに維持する
  • ユースケースの境界（弱整合）: 複数集約に跨がり、即時性や不可分性を求めない
• 複数集約を跨ぐユースケースは弱整合の境界として扱うべきであり、ユースケースの都合を強整合の境界にしてはならない

■ 3. 単一DBトランザクションに束ねるコストとリスク

• History list lengthの問題:
  • 長いトランザクションによりMySQL/InnoDBで古い行バージョンの後始末が遅延する
  • 読み書きの遅延、パージ処理の遅れ、Upgrade・Recoveryの複雑化が生じる
• ロック獲得順序と循環デッドロック:
  • 複数トランザクションが異なる順序でロックを獲得すると循環デッドロックが発生する
  • ロック獲得順序はドメインモデルから導かれない永続化層由来の暗黙的制約である
  • 低負荷環境では顕在化せず、本番ピーク時に初めてエラーが頻発する
  • 楽観ロックを用いてもversion不一致による失敗とロック競合の両方が発生しうる
• 読み取り側への暗黙的依存:
  • 複数集約の同時更新前提はクエリ設計にも組み込まれる
  • 後から更新手順を変更する際、読み取り側も見直しが必要となり変更コストが増大する

■ 4. アクターモデルによる解決: 1集約1アクター

• CQRS/ES環境でアクターモデルを採用する場合、1集約が1アクターに対応する
• 強整合の境界が構造的に強制されるため、複数集約を跨ぐアトミック更新の経路が通常のコマンド処理に置かれない
• DB由来の循環デッドロックが構造上発生しないという利点がある

■ 5. プロセスマネージャーによる弱整合設計

• 設計方針:
  • 複数集約を跨ぐユースケースはプロセスマネージャー（オーケストレーション型のサーガ）で調停する
  • 各ステップを個別の集約更新として実行し、失敗時は補償アクションで取り消す
• ACDとしての捉え方:
  • Atomicity: 補償アクションにより業務上の取り消し済み状態へ収束する
  • Consistency: 最終的にドメイン状態の整合を満たす
  • Durability: 各ステップのプロセス状態を永続化する
  • Isolation（欠如）: 途中状態が外部から見える可能性がある
• 設計対象となる項目: 補償処理、冪等性、再試行、タイムアウト、重複要求の吸収
• 読み取りモデルでの中間状態の制御:
  • 中間状態を「payment_pending」や「compensating」等のドメイン語彙としてモデル化する
  • 通常一覧には確定済みの注文のみを表示し、中間状態は処理中ビューや管理者向けビューで表示する

(2026/05/23)

なぜ、Claude CodeのせいでIT業界はアニメ業界みたいになったのか？

• なぜ、Claude CodeのせいでIT業界はアニメ業界みたいになったのか？

要約:

■ 1. 概要

• Claude CodeやCodexの登場により、IT業界はコードを書く仕事から監修する仕事へと重心が移りつつある
• この構造変化は、アニメ業界における動画・第二原画の外注と作画監督による修正という分業モデルに類似する
• AI時代のIT業界を理解する中心的な論点: AI生成コード、監修産業化、作画監督化、アナロジーの破れ目、育成ラインの断絶

■ 2. 従来のIT業界でアニメ型分業が成立しなかった理由

• アニメ業界の前提:
  • 外注から返ってくる成果物は品質に問題があっても最低限「絵」として修正可能
  • 作画監督が修正すれば最終的な映像品質に近づけられる
• IT業界の前提:
  • 外注や未熟なプログラマーの成果物は「修正可能性そのものが低い」場合が多い
  • 仕様理解の欠如、設計破壊、例外処理の欠落、既存コードとの接続破綻が普通に発生
  • プログラマーの質のばらつきがアニメ型分業の阻害要因であった

■ 3. Claude CodeとCodexが変えたもの

• AIが変えたのはプログラミング能力の頂点ではなく底上げの部分
• AIの主な特性:
  • 「それっぽいコード」を高速に返す
  • 既存コードを読ませると類似した形の修正を出す
  • テストコードの作成、単純なリファクタリング、定型的な実装が可能
• 結果としてプログラミング作業のばらつきがある程度均質化された
• AIは天才プログラマーではなく「最低限修正可能な素材を大量に返す外注先」となった
• IT業界は実装者不足の産業から監修者不足の産業へと重心が移り始めた

■ 4. 「修正可能な素材」という前提への留保

• AI生成コードは「修正可能な素材」ではなく「書き直し前提のたたき台」に近い場合がある
• プロンプトを練り直して再生成する方が、既存の生成物を手で直すより早い判断が現場で生じることがある
• 「修正主義」と「再生成主義」はAI時代の開発における二つの戦略であり、どちらが優勢かは案件特性によって変わる
• アナロジーは万能ではなく適用範囲がある

■ 5. IT業界がアニメ業界化した意味

• コードを書く仕事が消えたのではなく、コードが大量に出てくるようになったことを意味する
• アニメとソフトウェアの対比:
  • アニメ: キャラクターの顔は描けているが設定画と微妙に違う、カット単体では成立しているが前後の流れとつながらない
  • ソフトウェア: コードは動いているが責務分割が違う、テストはあるが仕様の本質を見ていない、例外処理はあるが運用思想と合っていない
• AI時代の熟練エンジニアは、作画監督のように全体の統一感を守り、崩れた箇所を直し、直すべき箇所と許容すべき箇所を判断する役割を担う

■ 6. 作画監督化するチームプログラマーとアーキテクト

• AI時代に仕事が増えるのはチームプログラマー、リードエンジニア、アーキテクト
• AIによってチーム全体のコード生成量が増え、レビュー対象も増える
• AI生成コードは見た目が整っているため雑なコードより危険な場合がある（問題が見えにくい）
• 熟練者が継続して判断すべき事項:
  • 既存設計との整合性
  • 抽象化の必要性
  • 将来の変更コストへの影響
  • テストが何を保証しているか
  • 他仕様への影響
• 設計意図の維持、品質の統一、レビュー滞留、監修容量がAI時代の開発現場の主要な制約となる

■ 7. コード生産性差の圧縮と監修能力差の拡大

• 従来: プログラマーごとの作業速度差がチームのベロシティに直接影響していた
• AIによって定型的なコードを書く速度の個人差は圧縮される
• 一方でAIによって拡大する個人差の軸:
  • AI生成物の構造的破綻を見抜く能力
  • AIに渡すコンテキストを正しく組み立てる能力
  • 生成結果を疑える能力
  • 設計意図に照らして却下する能力
• チームのボトルネックは実装者のコーディング速度から熟練者の監修能力へ移る
• AI時代の開発計画における上限は生成量ではなく監修者の処理能力で決まる

■ 8. AIは無料の外注先ではない

• AIは時間、トークン、API費用、コンテキスト管理、人間の確認時間を消費する
• AIの生成速度のみを見て生産性が上がったと錯覚するリスク:
  • 未検証のコードが増えただけかもしれない
  • レビュー待ちが増えただけかもしれない
  • 人間が書いた方が早かった可能性がある
  • 生成物が多すぎて設計意図が薄まっただけかもしれない
• 監修者の負荷は集中力・判断力・設計理解・文脈把握が必要であり、単純に時間を増やすことで解決できない
• AI利用の原則:
  • AIに任せるべき作業と人間が直接やるべき作業を分ける
  • AIを使うこと自体を成果と見なさず、完成物として責任を負えるかを見る
  • 生成コスト・確認コスト・手戻りコストを合わせて判断する

■ 9. アニメ業界とのアナロジーが破れる点: 共通参照画の不在

• アニメ業界には設定資料集・キャラクター表・美術設定・絵コンテという外部化された判断基準がある
• ソフトウェアには設計意図の外部化がなく、判断基準が特定の人間の頭の中にのみ存在することが普通に起きる
• 作画監督とIT監修者の役割の違い:
  • 作画監督: 外部化された参照に照らして修正する
  • IT監修者: 外部化されていない参照を頭の中で再構築しながら修正する（編集者やシリーズ構成に近い役割が混じる）
• AI生成コードはこの問題を悪化させる:
  • 表面的な「らしさ」は揃えるが、見えない設計意図には到達しない
  • 内部構造を微妙に壊し、その破壊が将来の変更コストとして遅れて現れる
  • 表面的な成立がむしろ問題を隠す方向に働く

■ 10. 仕様流動性という非対称性

• アニメ業界: 制作開始時点で基本構造（話数・尺など）が固まっている
• ソフトウェア開発: 要件・仕様がステークホルダー、ユーザー、市場、法令、経営判断によって開発中に変わる
• アジャイル開発という方法論自体が仕様流動性を前提に設計されたものである
• AI時代の監修の実態:
  • 固まった参照画と照合する作業ではなく、流動する仕様の最新版を頭の中で保持しつつ照合する作業
  • 昨日の正解が今日の不正解になることがある
• 仕様流動性そのものがAI時代の監修負荷を底上げしており、アニメ業界が経験していない種類の困難である

■ 11. 育成ラインの断絶

• アニメ業界の育成階段: 新人→動画→第二原画→原画→作画監督
• IT業界の従来の育成階段: ジュニア（バグ修正・画面修正・CRUD実装・テストコード）→ミドル→シニア→リード→アーキテクト
• AIによる変化:
  • Claude CodeやCodexがジュニアの担っていた地味な実装を代替し始めた
  • 経済合理性の観点からAIに任せた方が速く安いため、ジュニアから経験の場が奪われる
• 長期的問題:
  • 下位工程を経験せずに監修側に立てる人間はいない
  • 監修者が必要な産業に移行したにもかかわらず、監修者を育てる工程がAIに置き換えられている
  • 5年・10年のスパンで決定的な影響が生じる
• アニメ業界との共通課題: 育てた人材が他社・海外に流出する移籍リスクとAIによる育成機会縮小の組み合わせ

■ 12. まとめ

• AI時代のIT業界変化の本質:
  • AIが優秀なプログラマーを置き換えたのではなく、修正可能な素材を大量に返す外注先として機能し始めたことによる変化
  • 価値の中心: コードを書くこと→返ってきたコードを監修すること
  • チームのボトルネック: コーディング速度→監修者の処理能力
• アナロジーの破れ目（複数存在）:
  • AI生成コードが「修正可能な素材」より「書き直し前提のたたき台」に近い場合があり、修正主義と再生成主義のどちらが支配的かは案件によって変わる
  • ソフトウェアには共通参照画（設計意図の外部化）がない
  • ソフトウェアの仕様は流動的であり、アニメのように制作開始時点で固まらない
• これらの破れ目によりIT業界の監修者は作画監督より重い役割を背負っている
• AIが下位工程を担うことで次世代監修者を育てる育成ラインが断絶しつつある
• AI時代のIT業界は「コードが足りない業界」ではなく「作画監督が足りない業界」になりつつある

MEMO:

• であれば、現在適切に経験と技能を蓄積した人間は暫く食いっぱぐれが無いという事で、そこは朗報
• 将来の作画監督が不足するというのはどうなんだろうか
• 高級言語が生まれた時に「将来アセンブラを書けるエンジニアがいなくなるぞ」という意見と同じで杞憂ということになるのだろうか？

(2026/05/23)

クラウドが開発と運用をつないだように、AI駆動開発は要件定義と実装をつなぐのか

• クラウドが開発と運用をつないだように、AI駆動開発は要件定義と実装をつなぐのか - arclamp

要約:

■ 1. LLMとクラウドの技術的共通性

• LLMは「言語を使った作業を操作可能にする技術」であり、入力プロンプトをもとに語の確率分布から人間らしい文章を生成する統計モデル
• システム開発はドキュメント作成やコーディングなど言語を使った作業が多く、LLMによる補完・自動化の可能性がある
• クラウドは「インフラ作業を操作可能にする技術」であり、仮想化技術をベースにインフラ構築・運用作業がAPI化された
• 両者は「人手でしかできなかった作業を操作可能にする技術」として比較できる
• システム開発という文脈では「特定の工程が自動化されたことで何が起きるか」という視点での比較が有効

■ 2. クラウドがもたらした変化

• NoOps（2011年）:
  • インフラ構築・運用作業の自動化により、従来の運用という概念が変化
  • Netflixでは運用部門の目的が「開発者が運用するのに必要なツール・プラットフォームを整備すること」に変化
  • 開発者がセルフサービスで運用作業を実施し、DevOpsエンジニアがそのツールを作る体制が確立
• IaC（Infrastructure as Code）:
  • インフラのあるべき構成をコードとして管理し、定義と現在状態の差分から変更計画を生成するツール
  • インフラ構成がコードとして確認・比較・レビュー・再現できる対象となる
  • 現在状態との差分やドリフトを検知し、あるべき状態へ収束させることが可能
• マイクロサービス（2014年）:
  • インフラの高度な自動化を前提に、大規模システムを複数のサービスに分割して構成するアーキテクチャ
  • 他チームとの調整なく各チームが独立したリズムでサービスを変更・リリースできる
  • 巨大なサービス全体における漸進的な改善が可能になる

■ 3. クラウドの歴史から学べること

• 自動化された工程の担当者は、自動化ツールを整備する側に移行し、前工程の作業者がセルフサービスで作業するようになる
• 自動化ツールは抽象化された構成管理ツールとして高度化する
• チーム構成や仕事の進め方も変化していく

■ 4. AI駆動開発の現在

• AIエージェントへのタスク委任が主流になりつつあり、象徴的な例としてClaude Codeによるエージェント型コーディングがある
• エージェント型コーディングでは利用者が「何を作りたいか」というタスクを与え、AIエージェントが実行する
• AIエージェントが動く環境として以下の構成要素（AIハーネス）が必要:
  • Context: プロジェクトの前提・ルールとして共有する情報
  • Skills: 繰り返し使う作業手順を与えるためのスキル定義
  • Subagents: 作業ごとの役割・文脈・権限を分けるための専門エージェント
  • Hooks: 特定タイミングで自動実行する処理を定義するための仕組み
  • MCP servers: 外部ツールや外部データに接続するための仕組み
• AIエージェントはAIモデルとAIハーネスの組み合わせとして定義される

■ 5. AI駆動開発の未来

• AIハーネス開発者の登場:
  • DevOpsが運用オペレーターの役割を変えたように、AI駆動開発ではシステムエンジニアやプログラマの役割が変化する
  • 「エンジニアが不要になる」のではなく、DevOpsエンジニア・SREのように「AIハーネス開発者」という役割が重要になる
  • AIハーネス開発者は、エージェントツール環境管理・ハーネス設定・ナレッジ整備・エージェント動作管理・品質管理などに細分化される
• 要件構成管理ツールの必要性:
  • POがコーディングエージェントを使うには精度の高い要件が必要だが、従来の要件定義手法では人間の認知限界を超えられない
  • LLMは文章で記載された要件同士の関係を読み取り、矛盾や抜け漏れを機械的に確認できる
  • IaCツールがインフラ構成を管理したように、要件構成を管理するためのツールが重要になる
• BIMとの類比:
  • 建設業界のBIM（Building Information Modeling）は、部品単位でデータを持った3Dモデルとして建物を扱い、設計精度を高める仕組み
  • システム開発の要件管理でも、LLMによって要件や構造の意味的な整合性を機械的に確認することが可能になる
• 要件構成管理ツールの想定される姿:
  • 小さな要件を候補要件モジュールとして登録する
  • 候補要件モジュールの選択から依存性・影響を踏まえた「リリース要件構成情報」を組み上げる
  • 「リリース要件構成情報」を「全体実現構造モデル」に組み込む
  • 「全体実現構造モデル」の更新差分から「実現構造モデル差分」を生成する
  • 「実現構造モデル差分」からコーディングエージェントが各サービスを開発する
  • 「リリース要件構成情報」に対して受入テストを実施する
• 新たな役割の登場:
  • 要件構成設計エンジニア: POの横で要件モジュールを整理し、要件同士の依存性を管理する
  • 実現構造設計エンジニア: 要件構成から実現構造を導く
  • 建築業界における「意匠設計」（目的・空間設計）と「構造設計」（物理的・構造的実現）の分離に相当する
• チーム・マネジメントの変化:
  • 複数の開発チームが複数のサービスを個別管理する形から、AI駆動開発プラットフォーム上で横断的に管理する形に変化
  • 1つの要件に対して複数のサービスにまたがる変更を整合性を保ったまま一括して計画・実装・リリースできるようになる

■ 6. まとめ

• 従来のSEやプログラマの役割は、コーディングエージェントを正しく動かすための環境・制約・ナレッジを整備するAIハーネス開発者へ移行する
• ビジネス側がコーディングエージェントを使いこなすには精度の高い要件が必要であり、要件構成管理ツールが必要になる
• 「何のためにやるか」という要件構成を設計するエンジニアと「どう実現するか」という実現構造を設計するエンジニアという新たな役割が登場する
• AI駆動開発はコード生成の自動化にとどまらず、要件・実現構造・実装・テストのつながりをAIによって再設計することにある

(2026/05/22)

A Markdown-based test suite

• A Markdown-based test suite - by Julio Merino

要約:

■ 1. 概要と背景

• EndBASICのコアを書き直すにあたり、テストをRustのユニットテストからMarkdownで記述する方式に移行
• AIコーディングエージェントの実験がEndBASIC開発の再開を動機付け
  • AIエージェントがEndBASIC公式ドキュメントをもとにゲームを生成することに成功
  • これを受けてEndBASICの「自己文書化」強化、高速化、機能拡張の三方針を立案
• テストをMarkdownで書くことで、LLMがテストから言語仕様・動作ルールを自律的に学習できると判断

■ 2. Markdownテストスイートの構成

• テストスイートの実体:
  • core/tests/ ディレクトリ以下の .md ファイル群（現在448テストケース、13,000行超）
  • 各ファイルが複数のテストケースを含むコンテナとして機能
• テストケースの構造:
  • ■ Source — コンパイラへの入力（BASICソースコード）
  • ■ Compilation errors — コンパイル失敗時のエラーメッセージ（失敗時のみ）
  • ■ Disassembly — コンパイル後のバイトコード（成功時）
  • ■ Exit code — ゼロ以外の終了コード（任意）
  • ■ Output — プログラムのコンソール出力（成功時）
  • ■ Runtime errors — 実行時エラー（成功時）

■ 3. テストの実行方法

• ドライバの動作:
  • tests/ ディレクトリ内の全Markdownファイルを列挙して順次処理
  • 各ファイルからテストケースのタイトルと Source セクションを抽出
  • 各テストケースをコンパイラ・VMに投入し、副作用をキャプチャ
  • 実行結果を新規Markdownファイルとして出力（actual）
• ゴールデンファイルとの比較:
  • ドライバが出力したファイル（actual）をリポジトリにチェックインされた既存ファイル（golden）と差分比較
  • 差異があればテスト失敗とし、diff で差分を表示
• ゴールデンファイルの再生成:
  • REGEN=true 環境変数を設定することで、ドライバがゴールデンファイルをその場で上書き再生成
  • 再生成後はGitで差分を確認し、コード変更と合わせてコミット

■ 4. 評価

• メリット:
  • 以前のRustベースのテストと比較して格段に修正・確認が容易
  • 主要なテキストエディタのMarkdownサポートを活用でき、フェンスコードブロックの整形も機能
  • LLMが言語仕様のルールをMarkdownテストから自律的に抽出・学習できる
• デメリット:
  • REGEN=true による再生成が容易すぎるため、ソース位置や逆アセンブルコードの細かいミスを見逃しやすい
  • 逆アセンブルの差分が命令アドレスを含むため、命令の追加・削除で全アドレスがシフトしノイズが多い
  • Rustの cargo test によるテストフィルタリングが機能せず、Markdownファイル内の個別テストケースは実行単位として扱えない
  • エンドツーエンドテストが安価なコンポーネントに限定的で汎用性に乏しい

(2026/05/22)

AIがコードを書く時代に、なぜ「効率」を学ぶのか。mattnが全サーバサイドエンジニアに推す一冊『効率的なGo』

• AIがコードを書く時代に、なぜ「効率」を学ぶのか。mattnが全サーバサイドエンジニアに推す一冊『効率的なGo』 - エンジニアtype | 転職type

要約:

■ 1. 書籍・著者の概要

• 書籍名は『効率的なGo』（オライリー・ジャパン）、紹介者はVimおよびGoコントリビューターとして知られるmattn氏
• 著者はPrometheusの公式メンテナー兼Thanosの共同開発者であるBartlomiej Plotka氏
• 執筆に約1,200時間を費やした書籍
• 全11章のうち8章はGo言語に依存しない内容で構成されており、サーバサイドエンジニア全般に向けた書籍

■ 2. 本書を読んだ背景

• Grafana Labs（元Google/AWS）の山口能迪氏（@ymotongpoo）による翻訳レビューへの参加がきっかけ
• 読者自身は性能と効率を実践的に理解していたが、他者への説明に使える「共通言語」が不足していたと認識
• 本書を通じて「性能を語るための共通言語」を得られた

■ 3. 本書の主要な学び

• 性能の定義:
  • 「性能 = 精度 × 効率 × 速度」と定義される
  • 精度: 間違いを犯していないか
  • 効率: 余計な仕事をしていないか、リソースを使い過ぎていないか
  • 速度: 速くできているか
• 「早すぎる最適化は諸悪の根源」の誤用への指摘:
  • この言葉が「最適化を考えなくて良い言い訳」として使われる風潮に対し本書は警鐘を鳴らす
  • Herb SutterとAndrei Alexandrescuの引用「単に不必要な悲観的実装を避けるだけ」が紹介される
  • 「悲観的実装」とは、効率の良い書き方と悪い書き方で読みやすさがほとんど変わらないのに悪い方を選ぶこと
  • 例として、配列サイズが既知の場合にmake([]T, 0, n)で容量を確保せずループ内でappendのみを行うケースが挙げられる
• 著者自身の反省:
  • Thanosプロジェクトについて「最初から明確な効率要件を持ち、ベンチマークとプロファイリングにもっと投資すべきだった」と率直に述懐
  • 5日間で17.61TBのメモリを割り当てたプロファイル図を本書内に掲載

■ 4. 実務での活用

• 習慣そのものより「習慣を説明する言葉」が変化した
• 各章の内容:
  • 第8・9章: マイクロベンチマークとプロファイリングの解説
  • 第9章: ヒープ・ゴルーチン・CPU・Off-CPUの各プロファイルの読み方を網羅、pprofの手引きとなる
  • 第10章: bytes.Splitやstrconv.Parseを題材にした最適化の実例
  • 第11章: 「3つのR」（Reduce・Reuse・Recycle）というパターンを提示
• 手癖で行っていた実装に体系的な名前と理由付けができるようになった
  • 例: 「なんとなくsync.Poolを入れる」から「ホットパスに乗っているためReuseを適用する」へ

■ 5. まとめ・推薦理由

• Go言語のテクニック書ではなく「性能とは何か・効率とどう向き合うか」の土台を提供する書籍
• 土台を得ることで、Goの細かいテクニックの理解が深まる
• AI時代における効率学習の必要性:
  • AIが生成したコードにも効率の観点は必要
  • AI時代だからこそ、性能・効率の知見は体験を通じて習得すべき
• 持続可能なソフトウェア開発の観点:
  • CPU時間・メモリの浪費はビジネスコストとエネルギーの両方に影響する
  • AIワークロードが計算資源を大量消費する時代に効率を語れるエンジニアの価値は高まる
• サーバサイドソフトウェアに関わる全エンジニアに推薦される

関連:

• 効率的なGo - O'Reilly Japan

(2026/05/22)

Google、モダンなWeb開発を支援するエージェントスキル「Modern Web Guidance」を公開

• Google、モダンなWeb開発を支援するエージェントスキル「Modern Web Guidance」を公開 | gihyo.jp

要約:

■ 1. 概要

• GoogleはGoogle I/O 2026に合わせ、モダンなWeb開発を支援するエージェントスキル「Modern Web Guidance」を早期プレビューとして公開
• アクセシビリティ、パフォーマンス、セキュリティを考慮したWebアプリ実装をコーディングエージェントに支援させることを目的とする

■ 2. コーディングエージェントへのガイダンス提供

• モダンなWeb開発に関するガイダンスをコーディングエージェントに読み込ませるスキルとして提供
• 開発者はターミナルから用途に応じたガイドを検索・取得し、エージェントのコンテキストへ渡すことが可能
• 解決する課題:
  • コーディングエージェントはモデルの学習データにレガシーコードが多く含まれるため、JavaScriptを多用する実装や古い回避策を生成しやすい
  • モデルがAPIの存在を知っていても、本番向けの具体的な実装パターンが不足しやすい
• 誘導対象の機能: Popover API、CSS Anchor Positioning、<dialog>要素、パスキー、Content Security Policy、Core Web Vitalsの改善などのモダンなWeb機能
• 対象領域: ユーザーインターフェイス、CSSレイアウト、パフォーマンス、フォームとUI、アクセシビリティ、ブラウザ内蔵AIなど

■ 3. Baselineとの連携

• Webプラットフォーム機能の対応状況を示す「Baseline」と連携し、使用する機能とフォールバックをエージェントが判断できるよう支援
• フォールバック方針:
  • 追加的な改善と代替実装が必要な処理を区別して扱う
  • 50行未満の軽量な個別実装や条件付きポリフィルを優先
  • fetchLater()の64KBペイロード上限やmacOS固有のスクロールバー挙動など、実装時の注意点も収録
• 実際のユーザーが使っているブラウザデータからBaselineターゲットを検討できる「Baseline Checker」も関連ツールとして紹介

■ 4. 導入方法

• Google Antigravityへのワンクリックインストールに対応
• npx経由での導入も可能
  • 推奨コマンド: npx modern-web-guidance@latest install
  • インストール後に導入先のエージェント環境を選択する画面が表示される
• 対応エージェント環境: npx skills、GitHub CLI、Antigravity CLI、Gemini CLI、GitHub Copilot CLI、Claude Codeなど

■ 5. 収録コンテンツと機能

• 数十の新しいWeb機能を扱い、100以上の実装場面に対応
• ガイドの検索・取得:
  • npx modern-web-guidance@latest search でユースケースIDを検索
  • npx modern-web-guidance@latest retrieve でガイドMarkdownをターミナルに表示
  • 検索はオフラインのTensorFlow.jsモデルを使いローカルで動作（ネットワーク呼び出しやAPIキー不要）
• Chrome拡張開発向けのchrome-extensionsスキルパックも提供
  • npx modern-web-guidance@latest install --choose でchrome-extensionsも選択可能
• 開発・評価用ソースリポジトリ「GoogleChrome/modern-web-guidance-src」も公開
  • スキルとして配布されるガイダンスの作成、調整、評価が可能
  • Google ChromeチームとMicrosoft Edgeチーム、Web開発コミュニティが支援

■ 6. Chrome DevTools for agentsとの連携

• Chrome DevTools for agentsと組み合わせた使い方が可能
• 役割分担:
  • Modern Web Guidance: 実装方針やコードパターンを提供
  • Chrome DevTools for agents: コンソールログ、ネットワーク通信、アクセシビリティツリーなど実行中のページ情報を提供
• 両者を組み合わせることで、パフォーマンス監査、アクセシビリティツリーの確認、コンソールログの取得を行い、その結果をもとにモダンなWebコードへ修正する流れを構築可能

■ 7. Google I/O 2026のその他の発表

• WebMCP:
  • WebサイトがJavaScript関数やHTMLフォームなどの構造化ツールをブラウザベースのエージェントへ公開するためのオープンWeb標準として提案
  • MCPの代替ではなく、Webサイト側からブラウザエージェントに操作手段を渡す仕組み
  • Chrome 149でオリジントライアルを開始し、Gemini in ChromeもWebMCP APIに対応予定
• Chrome DevTools更新:
  • AIアシスタンスがLighthouseデータにアクセス可能に
  • より自由度の高い質問に答えるため、追加の文脈を自動検索する機能を追加
• Webプラットフォーム新API:
  • HTML-in-Canvas API、Soft Navigations API、Declarative Partial Updates、Immediate UI modeなどを発表
• AI関連:
  • Built-in AIのPrompt API安定版を公開
  • 要約などの用途別APIを端末の幅広い層で動かすための小型モデル「Gemma 197M」を紹介
• Gemini in Chrome:
  • Android対応
  • ブラウザ上の面倒な作業を自動化する「auto browse」
  • 閲覧中のページから画像を生成・編集する「Nano Banana」
  • よく使うAIプロンプトを保存して再利用する「Skills in Chrome」
  • 画面上の要素を選んでGeminiに質問する機能
  • 音声入力支援

(2026/05/22)

Claude Code を大規模コードベースで使うベストプラクティス

• Claude Code を大規模コードベースで使うベストプラクティス - izanami

要約:

■ 1. Claude Codeのアーキテクチャ

• Claude CodeはRAG型のインデックスを持たず、ファイルツリーとgrepによるライブ探索を行う
• 常に最新のコードベースを参照できる一方、探索の手がかりがないとコンテキスト上限に達するリスクがある
• ハーネスの整備が探索精度に直結する

■ 2. 性能を決めるハーネス

• 性能はモデルよりもハーネスの整備で決まる
• ハーネスの構成要素と役割:
  • CLAUDE.md: 文脈の提供
  • hooks: 自動化
  • skills: 専門知識
  • plugins: 配布
  • MCP: 外部ツールへの接続
• 積む順序はCLAUDE.md → hooks → skills → plugins → MCPの順が基本
• 土台が固まる前に上位層を追加しても不安定な状態が増すだけになる

■ 3. CLAUDE.mdの設計原則

• ルートのCLAUDE.mdは全体像とハマりどころのみに絞り、薄く保つ
• 細かいローカルな規約は該当サブディレクトリのCLAUDE.mdに記載する
• Claudeはディレクトリを下りながら各階層のCLAUDE.mdを順に読み込むため、ルートを薄くしても深い文脈は積み上がる

■ 4. 起動位置の最適化

• 作業はリポジトリルートではなく、タスクに関係するサブディレクトリで開始する
• サブディレクトリで起動しても、Claudeは親をたどってルートの文脈を取得する
• テスト・リントコマンドはサブディレクトリ単位でCLAUDE.mdに記載し、不要なスイート全体の実行を避ける

■ 5. hooksの活用

• hooksの主な価値は制止スクリプトではなく、設定の自己改善にある
• stop hook: セッション終了時にその回の内容を振り返らせ、CLAUDE.mdの更新案を生成することで設定を自動育成する
• start hook: セッション開始時にチーム固有の文脈を動的に読み込ませる
• リント・フォーマットなど定型チェックはhooksで機械的に実行する方がモデルへの依存より安定する

■ 6. 設定の定期棚卸し

• モデルの進化により、旧バージョン向けの指示が新モデルの能力を制限する場合がある
• 3〜6ヶ月ごと、または大きなモデル更新後に設定を棚卸しする
• モデルの弱点補完のために作ったskillsやhooksは、その弱点が解消された時点でオーバーヘッドになる

■ 7. 個人開発者向けの実践指針

• CLAUDE.mdを薄く保ち、ルートは要点とハマりどころのみにする
• サブディレクトリでClaudeを起動する習慣をつける
• stop hookを1つ導入してCLAUDE.mdを自己成長させる
• 新モデルのリリース時にCLAUDE.mdを棚卸しする
• skills、plugins、MCPは土台（CLAUDE.mdとhooks）が固まってから追加する

■ 8. 組織への普及体制

• 広いアクセス開放の前に専任の少人数チームがツールを整備することで、最初から生産的な体験を提供できる
• DRI（直接責任者）を1人定め、設定・権限ポリシー・CLAUDE.mdの規約管理を担わせる
• ボトムアップの盛り上がりだけでは良い設定が属人化し、普及が頭打ちになる

(2026/05/22)

ポーリング処理廃止によるイベント駆動アーキテクチャへの移行

• ポーリング処理廃止によるイベント駆動アーキテクチャへの移行 - Speaker Deck

要約:

■ 1. 既存アーキテクチャと課題

• 各クライアントが30秒間隔でポーリングを実施し、1回あたり9回のAPIコールが発生
• 予約検索APIで約2,000 req/秒の高負荷が生じている
• 課題として高負荷、スケーラビリティへの懸念、非効率なリソース利用の3点が存在

■ 2. 問題の本質

• ポーリングはデータ変更の有無にかかわらず定期的にリクエストが発生する
• 無駄なリクエストが多いことがポーリングの根本的な問題

■ 3. サーバープッシュ型通信方式の比較

• WebSocket:
  • リアルタイム性が高く、双方向通信が可能で低レイテンシ
  • 通知用途には過剰機能であり、接続管理が複雑でスケーリングが難しい
• Server-Sent Events:
  • ブラウザネイティブ対応でHTTP/1.1で動作し、自動再接続機能を持つ
  • 接続管理が複雑でスケーリングが難しい
• gRPC Server Streaming:
  • 型安全でバイナリ効率が良く、モバイル/BFF構成と相性が良い
  • ブラウザはgRPC-Web経由のため導入コストが高く、接続管理が複雑でスケーリングが難しい
• 3方式に共通する課題:
  • 接続がPodに固定されるため、別Podに届いたイベントを他Podの接続クライアントへ転送する仕組みが別途必要

■ 4. 新アーキテクチャ: Firestoreを用いたイベント駆動設計

• Firestoreを採用した理由:
  • SDKのみで接続管理なしにリアルタイム同期が実現可能
  • クライアント数の増加に対してインフラ側での対応が不要
  • 薬局ごとのドキュメント分離により、各薬局が自身に関係するドキュメントのみを購読できる
  • GKEやCloud Pub/Subをすでに使用しており、同じGoogle Cloudエコシステム内で完結できる
• 新アーキテクチャのフロー:
  • 予約サービスがイベントを発火し、Cloud Pub/Subにメッセージを配信
  • イベント伝播サービス（GKE）がCloud Pub/Subを購読
  • イベント伝播サービスがFirestoreの薬局別ドキュメントを更新
  • フロントエンドが薬局別ドキュメントを監視し、Firestoreの変更をリアルタイム検知
  • 変更検知後、予約取得APIから予約データを取得

■ 5. 追加課題と解決策: 短時間における大量イベントへの対処

• 課題:
  • 短時間に多数のイベントが発生した場合、そのままクライアントへ伝播すると都度APIが呼び出される
  • スロットリングなしでは0.3秒間に4件のイベントが発生した場合、4回のAPI呼び出しが生じる
• 解決策:
  • Cloud Tasksを用いたスロットリング機構を導入
  • 10秒間隔のウィンドウ内に発生した複数のイベントを1回の通知にまとめる
  • 同一ウィンドウ内の後続イベントはタスク登録をスキップし、APIリクエストの集中を回避

■ 6. 移行後の結果

• 定性的な改善:
  • 予約一覧更新のリアルタイム性が向上
• 定量的な改善:
  • 予約検索APIの秒間リクエスト数が約2,000/秒から約1,000/秒へ50%削減
  • DBコストが100%から70%へ30%削減

(2026/05/21)

GoにおけるMutation Testingの実践チャレンジ

• GoにおけるMutation Testingの実践チャレンジ | ドクセル

要約:

■ 1. 発表概要

• 発表者: 伊藤瑛（DeNA エンジニアリング室 開発デザイングループマネージャー）
• イベント: Go Junction #1（2026年3月23日）
• テーマ: Goにおけるテスト品質測定手法としてのMutation Testingと、独自ツール「rmut」の設計・実装

■ 2. Mutation Testingの概念

• 定義: 意図的な不具合（ミュータント）をコードに埋め込み、テストの失敗可否でテスト品質を測定する手法
• 用語:
  • survived: ミュータント埋め込み後もテストが通過した状態
  • killed: ミュータント埋め込みによりテストが失敗した状態
• カバレッジとの違い: カバレッジはテストの通過確認のみを行うが、Mutation Testingは不具合検出能力を測定する

■ 3. ユースケース

• 年齢判定の例:
  • > を >= に変更しても既存テストが通過する問題を検出
  • テストの不十分さを機械的に発見できる
• Query Builderの例:
  • 複雑なSQL条件テストにおけるテストデータの網羅性を確認できる
• 検出可能な問題:
  • テストデータ・フィクスチャの網羅性不足
  • Assertionの正確性欠如
  • ライブラリ動作の誤解（Equalsの振る舞いなど）

■ 4. rmutの設計と実装

• 高速化アプローチ:
  • 1回のAST書き換えで全ミューテーションを埋め込む
  • TestMainでテストをループさせ、ループごとに異なるmutatorを起動させる
  • 通常の「mutant1つごとにTest Suite全体を実行」する構造を改善
• 実装上の課題:
  • 型情報の確認: 書き換え対象式の型をpackages.Loadで取得する必要がある
  • Untyped型への対応: リテラル値だけからは型判定ができない場合がある
  • Compile Error回避: 親ノードのコンテキスト分析が必須
• 無限ループ対策:
  • LoopCounter: for文検出時にループ回数制限を埋め込む
  • Timeout: Go標準の機構を活用
  • 再帰やgotoによる無限ループには未対応
• 運用上の工夫:
  • sync.*系ミューテーションを除外（デッドロック回避）
  • gitのdiffとcallgraph解析で適用範囲を限定
  • カスタムmutator用プラグイン機構（squirrel等の非標準ライブラリ対応）

■ 5. 残存する課題

• Compile Error: 予期しない構文で発生する
• 実行時間の不安定性: ミューテーション数に応じて増加する
• 無限ループの遭遇: パニック回避の限界がある
• Survivedミューテーションの意味: ロギングや例外処理では無意味化する場合がある
• プラグイン配布の困難: go/pluginの制限、WASI対応の困難がある

■ 6. 結論

• テスト品質の評価を「Testの品質を測定しよう」という観点から行うべき
• AI時代においてテスト生成の「正しさ」を計測する手法として重要性が増している
• 参考資源: Stryker Mutator、pitest（Java向けツール）、Google Research「State of Mutation Testing at Google」

MEMO:

• 実行/運用コストがめっちゃ高いのがネックか

(2026/05/21)

全員が正しいのに何も決まらない会議の正体

• 全員が正しいのに何も決まらない会議の正体 | サイボウズ式

要約:

■ 1. 全員が正しいのに収束しない議論の構造

• 本番障害の振り返り会議で5人のエンジニアが監視しきい値、カナリアリリース、基本設計、テストカバレッジ、アラート設計という5つの正しい提案を出したが、30分経っても結論が出なかった
• 「全員が正しい」状況が収束を阻む構造的問題の典型例である
• 個人の論理的正確さが、集団としての判断を歪める

■ 2. 賢い人ほどバイアスを検出できない

• 高い知性はバイアスの「検出」には役立たず、むしろバイアスを「正当化」する能力を高める
• 賢い人ほど「自分は客観的に判断できている」という確信が盲点を深くする
• 自分の直感を支持する論拠を素早く構築し、反証を退けることで、バイアスに基づく判断を「論理的に正しい」として提示する
• Rustの技術選定の例として、「Rustを使いたい」という動機が先にあり、それを正当化する論理を後から組み立てていたことが挙げられる

■ 3. 「合理的判断」が生む2つの罠

• 戦略的無知:
  • 自分の信念に反する情報を意図的に避ける行動
  • データやアンケート結果が目の前にあっても「有意ではない」と退ける
  • 情報が存在するにもかかわらず意図的に無視する点で、知識の欠如ではなく戦略的選択である
• 機能的愚鈍:
  • 組織内で批判的思考を停止する圧力
  • 「なぜ」を問うことにインセンティブがない構造では、前例に従うことが組織内の最適戦略になる
  • 沈黙が罰せられず報われるため、形骸化した構造が温存される
  • 承認フローの形骸化を認識しながらも指摘しなかった経験を例として挙げている

■ 4. 賢さが壊す集団判断の2つのパターン

• データの使い方の罠:
  • 「データドリブン」が実質的に「確証バイアスドリブン」に変質する
  • 仮説を支持するデータのみを収集し、反する証拠を「ノイズ」として無視する（確証バイアス）
  • A/Bテストで「有意差あり」の結果が出るまで条件を変えて繰り返す行動もこれに含まれる
• 成功体験の罠:
  • 過去に成功した判断が将来も正しいとは限らない（成功には時効がある）
  • 成功体験は未来のリスクを見えなくする遮蔽物として機能する
  • クラウド移行を「安定稼働中」を理由に見送り、2年後にスケーリング限界に直面した例がある
  • 科学界の「再現性の危機」（心理学実験の半数以上が追試で再現不可）と同じ構造が職場にも存在する

■ 5. 集合知はIQで決まらない

• チームの成績を最も強く予測するのはメンバーの平均IQではない
• チームの知性を高める有効な要素:
  • 相手の感情を読み取る力（誰が困っているか、誰が発言を飲み込んでいるかへの感受性）
  • 発言の平等性（特定の個人が議論を支配せず、全員に発言機会が行き渡ること）
• チームの知性は「誰がいるか」ではなく「どう関わるか」で決まる
• チームの成果は個人の能力の「総和」ではなく、個人間の「相互作用」によって決まる（システム思考の観点）
• 採用において「優秀な個人を集めれば強いチームになる」という信念は、この構造を見落としている

■ 6. 必要なのは「賢い人」ではなく「賢く疑える構造」

• 知的謙虚さ、感情の制御、直感の較正といった個人の能力だけでは不十分
• 個人が「賢く疑える能力」を持っていても、組織が疑うことを許さなければ機能しない
• バイアスを持った人間がバイアスを補正する構造を設計するという再帰的困難が存在する
• 完璧な構造は存在しないが、「自分たちの構造にも盲点がある」と前提に置くこと自体が構造の一部になり得る

■ 7. AIと人間: 疑う能力の差異

• AIは既知のパターン適用、定型コード生成、大量ドキュメントからの情報抽出において速く正確
• AIは統計的にもっともらしい出力を生成するが、それは「考えている」こととは異なる
• AIは「この回答は間違っているかもしれない」と自ら疑うことができない（自己修正の指示への反応は「疑い」ではなく「新しい入力への反応」）
• 人間は「自分は間違っているかもしれない」と疑える可能性を持つ点でAIと異なる
• AIが速さと正確さを提供する時代におけるチーム固有の価値は、「自分たちの判断を自分たちで疑い、修正し続けられること」にある

■ 8. 問いの変更が議論の質を変える

• 「誰の提案が正しいか」から「何がこの結果を構造的に生んだか」への問いの転換により議論の質が変化した
• 5つの個別提案は、実際には「デプロイ前の品質保証とデプロイ後の監視のバランス」という1つの構造的問題の5つの断面だった
• 人が変わらなくても、問いが変わることで知性の使われ方が変わる
• ただし、問いを変える権限を持つ立場（ファシリテーター）にいるかどうか自体が構造の問題である
• 個人の認知を超えた構造的な「疑いを許す仕組み・制度」が必要である

論評:

■ 1. 総評

• 読みやすく個人の誠実さが伝わるエッセイであるが、読後感の良さと論証の厳密さは別物である
• 評価軸は論理構造・説得力・主張の妥当性の3点

■ 2. 論理構造 (3/5)

• 強み:
  • 「問題提示→原因分析→構造的解決」という骨格を持ち、展開の意図が読み取れる
  • 自説の限界を自ら示す誠実さ（翌月の障害での失敗告白）が論証の信頼性を下支えしている
• 弱点:
  • 単一事例から一般命題へのジャンプが多い（5人の振り返り会議→「賢い人が集まっても問題は解決しない」はサンプル数1の観察から引き出されている）
  • 「IQが高いほど自分のバイアスに気づけない」という主張は因果の方向が曖昧（「より多くバイアスを持つ」のか「より巧みに隠す」のかが不明確）
  • 実際の認知科学研究（Stanovichらの合理性研究）ではIQと一部のバイアス耐性の間に正の相関が報告されており、著者の断言は過度に単純化している
  • 「個人の知性の総和より相互作用が重要」という主張と「賢さの罠」論の連結が粗く、主因が途中で「賢さ」から「構造」へ入れ替わっている

■ 3. 説得力 (3/5)

• 強み:
  • 著者の自己開示（Rustの件、承認フローへの沈黙）が読者との共感的距離を縮める
  • 「問いを変えたら議論が変わった」というエンディングと、「しかし翌月には自分がそれをできなかった」という即座の裏切りが説得力の構造として優れている
• 弱点:
  • 参考文献（David Robson、Stuart Ritchie）が挙げられているが、記事内でどの主張がどの知見に基づくかが示されていない
  • 「相手の感情を読み取る力」「発言の平等性」がチーム成績を予測するという主張はGoogleのProject Aristotleを指すと推測されるが明示されておらず検証不能
  • 「科学界の再現性の危機」と「職場の成功事例」をアナロジーで結ぶ部分は修辞的な借用であって論証ではない

■ 4. 主張の妥当性 (2.5/5)

• AI論の接合の不自然さ:
  • 終盤のAI批評は記事の中心テーゼ（賢さの罠・集合知）とほぼ独立して挿入されている
  • 「AIは自己修正の指示を出せば修正するが、それは疑ったのではなく新しい入力に反応しただけ」という主張が「賢さの罠」の議論に何を加えるかが不明確
  • 人間がAIより優れているという結論を補強するためにAIを道具として召喚している印象がある
• 「構造」の処方箋の空虚さ:
  • 「賢く疑える構造が必要だ」という結論に至るが、その構造の具体像は最後まで示されない
  • 著者自身が「バイアスを持った人間がバイアスを補正する構造を設計する再帰的困難がある」と認めているにもかかわらず、議論がそこで止まる
  • 「次回は善意と制度の関係を見ていきます」という引きは論証の先送りとも読める
• 「問いを変える」という解法の過大評価:
  • 「誰の提案が正しいか」から「何が構造的にこの結果を生んだか」へと問いを変えたことで議論が前進した体験談は示唆的だが、著者はその直後に「自分がファシリテーターだったから可能だった」と自ら無効化している
  • 「問いを変える権限を持つ人間をどう配置するか」という構造問題に帰着するなら、問いの変更自体は解法ではない

■ 5. 総合評価

• 総合スコア: 2.8/5（論理構造3/5、説得力3/5、主張の妥当性2.5/5）
• 記事が最も説得力を持つのは「問いを変えたら議論が変わった」という体験談
• 最も弱いのは「だから構造が必要だ」という結論部分
• 問題の定式化は鋭いが、解の輪郭を示さないまま終わる点は、著者が批判した「何も決まらない会議」と同じ構造である

(2026/05/21)

コンテナのGoアプリ、過剰並列になっていませんか？──cgroup環境のGOMAXPROCSチューニングをMacで実測

• コンテナのGoアプリ、過剰並列になっていませんか？──cgroup環境のGOMAXPROCSチューニングをMacで実測 - Timee Product Team Blog

要約:

■ 1. 問題の概要

• Go 1.24以前は、コンテナのcgroup CPU制限を無視してGOMAXPROCSを設定する
• GOMAXPROCSはGoランタイムが制御するOSスレッド数であり、ホスト全体のCPU数に設定される
• EKS上で48コアのノードにCPU制限5コアを設定しても、GOMAXPROCSは48のままとなる
• 過剰な並列実行によりCPUスロットリングが発生し、スループット低下を引き起こす

■ 2. 検証環境

• macOS上のDocker Desktop（11コアのLinux VM）を使用
• Go 1.24でコンパイルしたベンチマークアプリを作成
• info、benchmark、throttle-demoの3モードを実装して検証

■ 3. 実験結果

• 実験1 (GOMAXPROCS無視の確認):
  • CPU制限1コア（--cpus=1.0）でもGOMAXPROCSは11のまま
  • cgroupには正しくcpu.max: 100000 100000が設定されている
• 実験2 (スループット低下):
  • CPU制限1コア環境で100goroutineを実行した結果
  • GOMAXPROCS=1の場合：21,504 Ops/sec
  • GOMAXPROCS=8の場合：6,833 Ops/sec（68.2%低下）
• 実験3 (CPU停止時間の測定):
  • CPU制限0.5コア、5秒間のテストを実施
  • GOMAXPROCS=8の場合：39秒のCPU停止
  • GOMAXPROCS=1の場合：2.6秒のCPU停止（14.8倍の差）
  • スロットリング発生率は両者とも98%だが、実際の停止時間に大きな差がある
• 実験4 (線形相関):
  • GOMAXPROCSを1から16に段階的に増加させると、累積CPU停止時間がほぼ比例して増加
  • GOMAXPROCS=16では5秒のテストで50.3秒分のCPU停止が発生

■ 4. 技術的解説

• CFS帯域制御の仕組み:
  • 各ピリオド（100ms）内でCPUクォータが割り当てられる
  • n本のスレッドが同時稼働すると、クォータ枯渇速度がn倍になる
  • クォータ枯渇後は全スレッドが一斉に停止する（Thundering Herd問題）
• CPU使用率では問題が見えない理由:
  • CPU使用率は「クォータ消費量÷割り当て」で計算されるため、消費ペース（バースト性）を反映しない
  • 同じ使用率100%でも、1スレッドが穏やかに消費する場合と複数スレッドが瞬時に消費する場合ではレイテンシが大きく異なる

■ 5. 監視ポイント

• 以下3指標をセットで監視することを推奨する
• nr_periods：スケジューラの計測ピリオド総数
• nr_throttled：スロットリングが発生したピリオド数
• throttled_usec：実際のCPU停止時間（マイクロ秒）であり、最も重要な指標

■ 6. 対策

• Go 1.25+では、cgroup対応のGOMAXPROCS自動設定が実装される
• Go 1.24以前では、uber-go/automaxprocsライブラリを使用してcgroup対応を実現する
• Ruby（Puma）、Java、Node.js、Nginxなど各言語ランタイムでも並列設定の確認が必要
• CPU使用率だけでなく、CPU停止時間メトリクス（throttled_usec）の監視も必須とする

(2026/05/21)

[CloudNative会議2026] ペアーズ本番環境でのcgroup-aware化との死闘録

• [CloudNative会議2026] ペアーズ本番環境でのcgroup-aware化との死闘録 - Google スライド

要約:

■ 1. 概要

• 発表: クラウドネイティブ会議 2026年5月14日
• 発表者: James Kirk（株式会社エウレカ、Engineering Manager）
• テーマ: 恋活・婚活マッチングアプリ「Pairs（ペアーズ）」本番環境におけるcgroup-aware化の取り組みと事例

■ 2. 対象システム: pairs-main（2024年当時）

• コア体験の中心にあるAPIで、Go言語で実装、Amazon EKS上で運用
• 1 Nodeで二桁のpairs-main Podが稼働
• ワークロードはI/Oヘビーで並行処理が多い
• Amazon Aurora MySQLのリードレプリカをHAProxyでロードバランス

■ 3. Act 1: CPUリソースの「空回り」

• GoのCPU改善の経緯:
  • CPUプロファイル駆動でGoのガベージコレクター（GC）を主なターゲットに改善を実施
  • 実施内容: RDBのORM置き換え、DynamoDB SDKの独自シリアライザの開発、ホットパスのallocation削減
  • 結果: Go GCのCPU使用率を60%以上削減
• GOMAXPROCSの過剰並列:
  • GoのランタイムスケジューラがCPUの約15%を占有していたため、次の改善対象として調査を開始
  • Goはgoroutineをワーカースレッドに割り当てて実行し、スレッド数はGOMAXPROCS変数で調整される
  • GOMAXPROCSがCPUコア数を超えると過剰並列となり、GoとOSスケジューラのオーバーヘッドが増大してCPU使用率が悪化する
  • pairs-mainではlimits.cpu=5000m（5コア分）に対し、GOMAXPROCS=48（ノードのコア数）が設定されていた
  • Go 1.24以前はGOMAXPROCSのデフォルト値がコンテナのLimitsを考慮しなかった（1.25からcontainer-aware化）
• GOMAXPROCS変更後の初期結果と問題:
  • GOMAXPROCS=5に変更後: スループット大幅増加、Goスケジューラのcpu使用率50%以上削減
  • 夕方になるとレイテンシーが急増し、Pod CPUは安定していたためオートスケールが反応しなかった
  • 変更をロールバックし、根本原因の調査を開始

■ 4. Act 2: 監視の死角に潜んでいたもの

• レイテンシー急増のドリルダウン:
  • 平均レイテンシーが急増し、エンドポイントの偏りはなし
  • Goのスループット改善によりdownstreamの詰まりを疑い、アプリケーション層のトレースでサービス別レイテンシーを確認
  • Auroraリードレプリカのレイテンシーが急増前から右肩上がりになっていたことを確認
• Aurora調査結果:
  • Auroraリードレプリカ: CPU余力あり、週比で良化傾向でレイテンシーも良化
  • レイテンシー急増の原因とは考えにくい状態
• HAProxyのボトルネック発見:
  • GoとAuroraの間に存在するHAProxyを調査するため、全メトリクスを洗い出し
  • 洗い出した結果、CPUスロットリング（CPU使用が一時的に止められる現象）が原因と判明
  • HAProxyに限らず、当時の監視の死角となっていた
  • HAProxyのCPUスロットリングは数ヶ月前から徐々に悪化しており、HAProxy 2.0へのアップデートと時期が一致
  • HAProxy 2.0以降、Multithreadingがデフォルトで有効化され、並列数はnbthreadという設定で決定される
• HAProxyの過剰並列:
  • limits.cpu=1000m（1コア分）に対し、nbthread=48（ノードの48コアから取得）が設定されていた
  • GOMAXPROCSと同様の過剰並列の問題
  • nbthread=1に変更した結果: スロットリングが完全に解消し、CPU・メモリも半分以下に削減

■ 5. Act 3: CPU制限と過剰並列の衝突

• Linux cgroupsの仕組み:
  • KubernetesではRequests（競合時の配分）とLimits（制限）でCPUリソースを指定する
  • これらがLinuxのcgroupのパラメータに変換され、LinuxデフォルトスケジューラであるCFS（Completely Fair Scheduler）がCPU時間を管理する
  • cgroup v1（v1.35から非推奨）: requests.cpu → cpu.shares、limits.cpu → cpu.cfs_quota_us / cpu.cfs_period_us
  • cgroup v2: requests.cpu → cpu.weight、limits.cpu → cpu.max
• Requestsの動作:
  • requests.cpuはcpu.weightに変換される
  • cpu.weightは競合時の相対的な配分比率を表す（例: 500m : 1500m = 1 : 3 → 25% : 75%）
  • 競合時はCPU時間がその比率に応じて優先的に割り当てられる
  • 非競合時はRequestsを超えて余剰CPUを利用可能であり、cpu.weightの比率は使用上限ではない
• Limitsの動作:
  • limits.cpuはcpu.maxに変換され、ピリオド（期間）とクォータ（上限時間）で構成される
  • ピリオドのデフォルト値は100ms
  • クォータはLimitsの1コア分（1000m）あたり1ピリオド分（100ms）で計算される（例: 500m → 50ms）
  • ピリオド内でクォータを使い切ると、次のリセットまでスロットリング（停止）が発生する
• クォータとスロットリングの関係:
  • クォータはコンテナ内のスレッド間で共有される
  • スレッドが多いほど共有クォータを早く消費しやすく、スロットリング時はコンテナ内の全スレッドが同時に停止する
  • HAProxyの場合: limits.cpu=1000mで100msのクォータに対し、nbthread=48の48本のワーカースレッドが共有クォータを瞬時に消費し、全スレッドが同時にスロットリングするThundering Herdが発生
• CPU使用率では気づけなかった理由:
  • 停止時間が長いほど、平均CPU使用率のような集約値は実態とズレやすい
  • CPU使用率に加えて、スロットリングのピリオドと時間をセットで監視することが重要
• Limitsを外す場合の考慮事項:
  • Limitsなしではスロットリングが発生せず余剰CPUも利用可能
  • ただし、CPU使用を抑える上限とスロットリングのメトリクスを失う
  • マルチテナント環境では、CPU上限自体がセーフティとして機能する
  • GOMAXPROCSなどのcgroup-awareなデフォルト値はLimitsに依存するため、Limitsを外す場合はRequests・プロセスの並列数・異常検知をセットで考える必要がある

■ 6. まとめ: pairs-mainのcgroup-aware化の進捗と学び

• cgroup-aware化の進捗:
  • GOMAXPROCSの最適化（リベンジ）に成功し、Pod数を数割カット
  • Nginxのworker_processesにも対応し、メモリ使用量を220 MB→8 MBに削減
  • 現在は全コンテナ（Go: GOMAXPROCS、Nginx: worker_processes、HAProxy: nbthread、Datadog Agent: GOMAXPROCS）がcgroup-aware化済み
• 学び:
  • 各プロセスのデフォルト設定・挙動を把握し、過剰並列を避ける
  • プロセスの並列数はRequests・Limits・ワークロード特性を踏まえて決める
  • CPU使用率だけでなくスロットリングも監視する
  • Limitsなしでは過剰並列と異常検知をセットで考える

(2026/05/21)

JTCの壁を壊す「Redmine参謀本部」という戦略～現場の職人気質を活かす組織論

• JTCの壁を壊す「Redmine参謀本部」という戦略～現場の職人気質を活かす組織論: プログラマの思索

要約:

■ 1. JTCにおけるRedmine導入の課題

• Redmine環境を整備しても社員が使用しない問題が発生する
• 標準プロセス・標準ワークフローの強制により不満が生じる
• 各プロジェクトが個別にRedmine環境をホスティングすると開発プロセスが乱立し、バージョンアップが困難になる

■ 2. 製造業とアジャイル開発の必要性

• 製造業はマスタスケジュールに基づくガントチャートでの予実管理を基本とする
• ホルムズ海峡の石油不足、半導体不足、サプライチェーン激変などの外部環境変化により当初計画通りの進捗管理が困難になっている
• 顧客からの仕様変更・注文が頻繁に発生し、製造リードタイムの長い製造業ほど顧客満足の実現が困難
• 量産品・特注品いずれの製造業においてもアジャイル開発の必要性が高まっている

■ 3. マネジメントとエンジニア気質の対立

• 対立構造:
  • マネージャ・リーダーはマイクロマネジメントを好む傾向がある
  • エンジニア気質の社員は技術習熟を重視し、アジャイル開発を志向する
• 日本的職人気質の影響:
  • 日本人エンジニアはマネジメントより技術習得を優先する傾向が強い
  • SIerにおいてもプログラマ・エンジニアとしての技術研鑽を好む人材が多い
• 製造業における同様の構造:
  • メカ・エレキ・ソフトの技術者が多く、マネジメントより技術専念を望む傾向がある
  • マネージャのマイクロマネジメントとエンジニアのアジャイル志向が衝突しやすい

■ 4. Redmine参謀本部（AMET）の概念と役割

• 位置づけ:
  • Redmine運用事務局・運用推進部を戦略的に表現した組織体
  • 「アーキテクチャモダナイゼーション」のAMET（Architecture Modernization Enabling Team）に類似する機能を持つ
  • 各プロジェクトへの技術的・マネジメント的支援を担う
• 役割:
  • 運用戦略の策定（軍事における参謀本部の戦略立案に相当）
  • 高性能サーバや開発能力の調達（兵站・ロジスティクスに相当）
  • JTC内部への展開組織体制の整備・推進（教育訓練に相当）
• 期待される効果:
  • マイクロマネジメントからの脱却を実現する
  • 個人の能力を活かしチームの一体感を醸成する
  • JTCという旧来型組織においてもRedmineの運用・活用を可能にする
• 提言:
  • JTCではまずRedmine参謀本部を設置することが必要

MEMO:

• 要するにRedmine導入サポートチームみたいなものが必要という話だろうか？

(2026/05/20)

見える化する要求仕様 〜 EARS（Easy Approach to Requirements Syntax）を活用したシステム要求の書き方 〜

• 見える化する要求仕様 〜 EARS（Easy Approach to Requirements Syntax）を活用したシステム要求の書き方 〜 - ビジネスガレージ株式会社

要約:

■ 1. 概要

• Automotive SPICE 4.0 に関するコラムとして、EARSを活用した要求文の書き方を解説
• 明確で一貫性のある要求仕様の記述はシステム開発において極めて重要
• 要求の記述が曖昧で解釈の余地が大きい場合、後の開発フェーズで認識のズレや仕様変更が生じ、コスト・工数の増加につながる
• EARS（Easy Approach to Requirements Syntax）は要求をシンプルかつ明確に記述するための構文テンプレートであり、解釈のブレを防ぐことができる

■ 2. EARSの基本構造

• Ubiquitous（一般的な要求）:
  • 常に適用される要求に使用
  • 形式: 「The [システム] shall [動作]」
  • 例: 「システムは、車両の衝突が検知された場合、適切なエアバッグを30ミリ秒以内に展開しなければならない」
• Event-driven（イベント駆動要求）:
  • あるイベントが発生した場合に適用される要求に使用
  • 形式: 「When [イベント], the [システム] shall [動作]」
  • 例: 「正面衝突を検知した場合、システムは30ミリ秒以内にフロントエアバッグを展開しなければならない」
• State-driven（状態駆動要求）:
  • システムが特定の状態にある場合に適用される要求に使用
  • 形式: 「While [状態], the [システム] shall [動作]」
  • 例: 「車両が走行中である間、システムは衝突を検知するために衝撃センサーを監視しなければならない」
• Optional（オプション要求）:
  • 追加機能やオプションの機能に関する要求に使用
  • 形式: 「Where [条件], the [システム] shall [動作]」
  • 例: 「車両が助手席用エアバッグを搭載している場合、システムは助手席の占有センサーを監視しなければならない」
• Unwanted Behavior（望ましくない動作の要求）:
  • 望ましくない状況を回避するための要求に使用
  • 形式: 「If [条件], the [システム] shall not [動作]」
  • 例: 「助手席に乗員がいない場合、システムは助手席エアバッグを展開してはならない」
• Complex（複雑な要求）:
  • 複数の条件やイベントを組み合わせて記述する要求に使用
  • 形式: 「When [イベント], if [条件], then the [システム] shall [動作]」
  • 例: 「正面衝突が検知され、かつ助手席が占有されている場合、システムは助手席のエアバッグを展開しなければならない」

■ 3. 適用時の注意点

• EARSの形式に従うだけでは必ずしも適切な仕様にはならず、要求の内容そのものが不適切な場合は意図しない動作を引き起こす可能性がある
• 問題のある要求の例:
  • 「車両が静止している間、システムはエアバッグを展開してはならない」という仕様は、停車中に衝突された場合でもエアバッグが展開しない危険性がある
• 改善された要求の例:
  • 「車両が静止中かつ衝突の加速度が1.0 G未満の場合、システムはエアバッグを展開してはならない」と記述することで、誤展開を防ぎながら必要な場合に展開可能な仕様となる
• 要求の意図を明確にし、条件を具体的に記述することが重要

■ 4. 活用時の留意点

• 簡潔かつ明確に: 余計な修飾を避け、短く分かりやすい表現を心がける
• 一貫性の確保: SHALL（〜しなければならない）の使い方を統一し、主語を明確にする
• 必要十分な情報を含める: 曖昧な表現を避け、要求に不足がないようにする
• トレーサビリティを意識: システム仕様や上位要件との整合性を確保する

■ 5. まとめ

• EARSはシンプルな構文によって要求の曖昧さを排除し、仕様の誤解や抜け漏れを防ぐのに有効な手法
• 形式に従うだけでは不十分であり、意図や条件を明確に記述することが重要
• 特に安全性が求められるシステムでは、適切な要求仕様が欠かせない

(2026/05/19)

「エンジニアは趣味で勉強するもの」が前提ではなくて、趣味でエンジニアリングしてた社会不適合者...

「エンジニアは趣味で勉強するもの」が前提ではなくて、趣味でエンジニアリングしてた社会不適合者がなるものであって因果が逆。そこにGREE/DeNAの人材獲得合戦で待遇があがって「未経験からエンジニア」みたいなのも増え普通の職として就く人が増えただけである

(要出典

エンジニアだけ「休日も勉強してますか？」って聞かれるの、なんか変じゃない？

営業とか経理には聞かないのに。

「エンジニアは趣味で勉強するもの」という謎の前提、いつ誰が作ったんだろう。

@sassu_carrier

@kis

MEMO:

• これは実際そう
• WEB/スマホゲーム系の企業の人材獲得合戦によってエンジニアの市場価値が上昇、それに伴う待遇上昇でソフトウェア開発に関心の無かった層が未経験エンジニアとして参入し「趣味で勉強しないエンジニア」が大量発生した

(2026/05/19)

ソフトウェア開発プロジェクトの設計

• ソフトウェア開発プロジェクトの設計 - kawasima

要約:

■ 1. 概要

• ソフトウェア開発方法論は「ウォーターフォールかアジャイルか」の二択で語られることが多いが、解像度が低い
• 実際には別々に決めるべき4つの論点が存在する
  • 開発ライフサイクル（予測型 / 適応型）
  • 固定するプロジェクト変数（スコープ固定 / コスト固定）
  • デリバリーケイデンス（単一 / 複数 / 定期）
  • 効率パラダイム（リソース効率 / フロー効率）
• 「ウォーターフォール」「アジャイル」という手法名は、4つの論点をまとめて選んだ結果のラベルでしかない
• 決めるべきは手法名ではなく、4つの論点それぞれに自分のプロジェクトでどう答えるかである

■ 2. 手法名は複数の判断をまとめてしまう

• ウォーターフォールは典型的には予測型の開発ライフサイクルであり、スコープを定義し、スケジュールやコストを見積もり、計画に対するズレを管理する
• アジャイルは典型的には適応型の開発ライフサイクルであり、短いサイクルで作り、検査し、学習し、次の計画を調整する
• 反復しているから適応型とは限らない
  • 機能セットを固定し最初に決めたスコープの完了率だけを追っているなら、それは短い周期で進めている予測型計画である
  • Dave Nicoletteはこれを「イージーライダー」と呼び、予測型と適応型の都合のよい部分だけを切り貼りしてどちらの規律も持たない状態を批判している
• 「ウォーターフォール vs アジャイル」という対比では、何を固定し、何を可変にし、どの周期で学習し、何を最適化しているのかが見えない

■ 3. 論点1: 開発ライフサイクル

• 予測型と適応型の対比はMartin Fowlerによる区別である
• 予測型:
  • 作るものが予測可能であることを前提にする
  • 不確実性の量を見積もり、計画にバッファとして織り込む
  • 目標と実績のズレを検知し、計画へ近づけるように是正する
  • PMBOKのContingency ReserveとManagement Reserveの階層はこの発想の延長にある
• 適応型:
  • 最終的に作られるものを正確には予測できないことを前提にする
  • 大きな方針やビジネスゴールはあるが、具体的な成果物は変わりうる
  • 近い目標を置き、短い周期で検査しながら進む
  • ソフトウェア開発の不確実性は要件・技術・市場のいずれの方向にも漏れるため、サイクルで吸収する設計になる

■ 4. 論点2: 固定するプロジェクト変数

• プロジェクトには品質、コスト、期間、スコープといった変数があり、全てを同時に固定することはできない
• 品質は制御変数にはならない:
  • 内部品質をコスト・スコープ・速度とトレード可能な変数として扱うと、内部品質に投資する理由が消える（Fowler: Tradable Quality Hypothesis）
  • 内部品質が落ちれば数週間で開発速度が落ち、トレードで稼げる余地はほとんどない（Design Stamina Hypothesis）
  • 可用性、性能、セキュリティといった外部品質特性も一定閾値を下回るとサービスとして成立しないため、調整弁にはできない
• 期間はコストの構成要素として扱える:
  • ソフトウェア開発では人月が主原価であるため、期間を延ばせば人件費が積み上がる
  • 人を増やしてもBrooks流の摩擦で線形には短縮しない
• スコープ固定（コスト可変）は予測型と相性がよい:
  • 契約、投資判断、予算承認、外部調整などの場面でスコープを約束する必要がある
  • 不確実性が顕在化すればコストに転化する
• コスト固定（スコープ可変）は適応型と相性がよい:
  • 限られた期間とチームで、最も価値のあるものから作る
  • 作るものの詳細は学習によって更新される
  • スコープ可変には「ここまで満たせば出せる」という最小条件（Definition of Done）が必要であり、これがなければ可変スコープは未完成項目を増やすだけになる

■ 5. 論点3: デリバリーケイデンス

• デリバリーサイクルには3つの選択肢がある:
  • 単一デリバリー: プロジェクトの最後に一度だけ届ける。価値の検査が終盤に寄るため、計画精度・リスク管理・変更管理の重みが増す。予測型と組み合わさりやすい
  • 複数デリバリー: 期間中に複数回届ける。回数は決め打ちで、間隔は固定しない
  • 定期デリバリー: 固定された周期で届ける
• 複数・定期デリバリーは途中で価値を届けながら学習できる点で適応型と組み合わさりやすい
• デリバリーケイデンスの選択は、不確実性をどの周期で観測し、どの周期で意思決定を更新するかを決める
• ここでのデリバリーは本番リリース一歩手前まで持っていくことを指し、デプロイやリリースとは異なる概念である

■ 6. 論点4: 効率パラダイム

• リソース効率とフロー効率の区別はNiklas Modig & Pär Åhlström「This is Lean」が提示した概念である
• リソース効率: 各人の稼働率を高めることを重視し、人が遊んでいない状態をよしとする
• フロー効率: タスクがどれだけ短いリードタイムで流れるかを重視する
• この2つはよく衝突する:
  • 全員の稼働率を最大化するとWIPが増え、コンテキストスイッチが増え、コラボレーションが減り、サイクルタイムが長くなる
  • リトルの法則から、平均WIPが増えれば平均サイクルタイムが伸びる
  • 各人は忙しいのに、価値の流れは遅くなる
• 定期デリバリーや適応型プロセスではフロー効率が要になる:
  • 短い周期で検査・学習・計画更新するには、タスクが流れていなければならない
  • KanbanがWIP制限を中心メカニズムに据えているのはこのためである
• 単一デリバリーの予測型プロジェクトではリソース効率を優先する設計が採用されやすい:
  • 固定スコープ・固定予算の枠で外部と合意するとき、稼働率管理は会計上扱いやすい
  • フロー効率が常に上位の概念というわけではなく、前提条件が異なる

■ 7. 4つの論点の組み合わせ

• 基本となる組み合わせは2つあり、両者は並列ではない
• 第一の基本形（予測型 + コスト可変 + 単一デリバリー + リソース効率）:
  • SI契約、規制対応、ハードウェア同梱のソフトウェアなど外部に「何を、いつまでに、いくらで」を確約する案件が採る
  • 運用にはリスク管理・変更管理・バッファ管理が必要
  • 前提条件は「作るものが事前に予測可能」であること。これが満たせなければ、どれだけ計画を作り込んでも実装中にスコープが動き、コストが外れる
• 第二の基本形（適応型 + スコープ可変 + 定期デリバリー + フロー効率）:
  • 運用にはDoneの定義・本番投入可能性・WIP制限・メトリクスが必要
• 例外的な組み合わせも存在する:
  • 予測型 + スコープ固定 + 複数デリバリー + リソース効率: 年度予算の上限などで複数年度に分割して届ける案件。フェーズごとに要員を割り当てて稼働率を管理する
  • 適応型 + スコープ固定 + 複数デリバリー + フロー効率: 受託開発で発注側との契約はスコープ固定だが、内部ではアジャイルプラクティスを適用するスタイル（中菱エンジニアリングの事例）。外向きには予測型に見せ、内向きには適応型で運用する二層構造
  • 適応型 + コスト固定 + 定期デリバリー + リソース効率: Leanを伴わずにアジャイルを運用する場合。WIP制限を採用せず稼働率管理を最適化の論点に置く

■ 8. まとめ

• 「ウォーターフォールか、アジャイルか」という問いは、開発ライフサイクル一つの差を過大に見せる
• プロジェクト運営の設計は少なくとも4つの論点で考える必要がある:
  • 開発ライフサイクル: 予測型か、適応型か
  • 固定するプロジェクト変数: スコープを固定するか、コストを固定するか
  • デリバリーケイデンス: 単一か、複数か、定期か
  • 効率パラダイム: リソース効率か、フロー効率か
• これらは独立した好みではなく、不確実性をどこに押し込み、どの周期で観測し、何を最適化するかというひとつの設計問題の4つの側面である
• 自分たちのプロジェクトでこの4つにどう答えるかを明示するところから、プロジェクト設計は始まる

(2026/05/18)

Big Data is Dead

• Big Data is Dead

要約:

■ 1. 主張の概要

• 「ビッグデータ」時代は終わりを迎えつつある
• データ規模の問題を理由にした新技術への投資は、多くの場合で実際の問題を解決しなかった
• 現在は、データサイズではなくデータをどう活用するかに焦点を移すべき時代にある
• 本記事の根拠はBigQueryのクエリログ、顧客対応、ベンチマーク結果、業界アナリストとの対話などに基づく

■ 2. 著者の背景

• Google BigQueryの創設エンジニアであり、ビッグデータ普及の推進者として世界中の会議で講演を行った
• 2018年にプロダクトマネジメントに転身し、顧客との対話と製品メトリクス分析を担当した
• BigQueryの利用実態を分析する中で、「ビッグデータ」を持たないユーザーが大多数であることを発見した

■ 3. ほとんどの組織はビッグデータを持っていない

• BigQueryの顧客データ:
  • 大多数の顧客の総ストレージは1テラバイト未満
  • 頻繁に利用する顧客の中央値は100GB未満
  • 顧客のデータサイズはべき乗則分布に従う
• 業界アナリスト（Gartner、Forresterなど）の見解:
  • 大多数の企業のデータウェアハウスは1テラバイト未満
  • 一般的な目安は100GB程度のオーダー
• 投資家がポートフォリオ企業を調査した結果:
  • 大規模B2B企業でも約1テラバイト程度
  • 大規模B2C企業でも約10テラバイト程度
• 一般的な業務では膨大なデータは生成されにくい:
  • 1,000顧客、1日100明細の受注でも1日1MB未満
  • 100万件のマーケティングリードでも数ギガバイト程度
• NoSQLやNewSQLの停滞と、SQLite・PostgreSQL・MySQLの堅調な成長がこの実態を裏付ける

■ 4. ストレージとコンピュートの分離とその偏り

• ストレージとコンピュートの分離は過去20年で最も重要なアーキテクチャ変革
• S3・GCSなどのオブジェクトストレージの普及により、柔軟なスケーリングが可能になった
• 実態として、ストレージはコンピュートよりはるかに速く増大する:
  • データは時間軸に沿って線形に蓄積される
  • 分析は主に直近のデータに対して行われるため、コンピュート需要はほぼ横ばい
• 実例として、ある大手小売業者がオンプレミスからクラウド移行後にストレージは300倍（100TB→30PB）増加したが、コンピュート費用はごくわずかにとどまった
• オブジェクトストレージの活用により、分散処理が不要なケースも多い

■ 5. ワークロードのサイズは実際には小さい

• BigQueryの年間1,000ドル以上支出顧客の分析結果:
  • クエリの90%は処理データ量が100MB未満
  • テラバイト規模のクエリは極めて少数
• 巨大なデータを持つ顧客も、日常的には少量のデータしかクエリしない
• 大規模クエリはレポート生成目的が多く、パフォーマンスは優先されない
• データ処理量を削減する技術的手法:
  • カラム射影（Column Projection）
  • パーティションプルーニング（Partition Pruning）
  • セグメント除去（Segment Elimination）
  • 圧縮データへの演算、述語プッシュダウン
• 経済的なインセンティブも処理量削減を促す:
  • ステージ上で行ったペタバイトクエリは小売価格で5,000ドルの費用がかかる
  • クエリを小さくすることで、インスタンスサイズの縮小、コスト削減、並列実行数の増加につながる

■ 6. ほとんどのデータはほとんどクエリされない

• データアクセス頻度は鮮度に強く依存する:
  • 処理データの大部分は24時間以内のもの
  • 1週間経過すると直近1日比で約20分の1の頻度
  • 1ヶ月以上経過したデータはほぼアクセスされない
• ストレージの年齢分布はフラットだが、アクセス分布は直近に集中する:
  • 直近1ヶ月が全ストレージの5%でも全アクセスの80%を占める
• 結果として、実際のワーキングセットサイズは想定より管理しやすい

■ 7. ビッグデータの境界は後退し続けている

• 「ビッグデータ」の定義は「1台のマシンに収まらないデータ」であるが、該当するワークロードは年々減少している
• ハードウェアの進化:
  • 2006年のAWS EC2初期インスタンスはシングルコア・2GBのRAM
  • 現在の標準インスタンスは64コア・256GBのRAM（RAMで約2桁の向上）
  • メモリ最適化インスタンスでは24TBのRAMや445コアも選択可能
• コストスケールの変化:
  • クラウドではコンピュートコストはほぼ線形にスケールする
  • 2004年のDremelペーパーで3,000並列ノードを要した処理が、現在は単一ノードで実行可能

■ 8. データはリスクでもある

• 「ビッグデータ」の別の定義は「削除対象を判断するコストより保持コストが低い状態」
• データ保持に伴う法的・規制上のリスク:
  • GDPRやCCPAにより、特定データの利用追跡・削除義務が発生する
  • データレイクに放置された個人データは法令違反につながる可能性がある
• データは訴訟においてリスク要因になり得る:
  • セキュリティバグやSLA違反を示すログが訴訟に利用される可能性がある
  • メール保持期限と同様に、データ保持期限を設けることがリスク管理として有効
• データの「ビット腐敗」問題:
  • フィールドの意味の変化やデータバグの蓄積により、歴史データの解釈が困難になる
  • 時代ごとの参照フィールドの違いなど、複雑なビジネスロジックが生じる
• データ保持の目的を明確にすることが重要:
  • 同じ質問を繰り返すなら集計データの保持で足りる
  • 将来のための保持なら、実際に必要になる可能性の評価が必要

■ 9. ビッグデータの1%に該当するか

• 以下の問いに一つでも「否」があれば、ビッグデータへの大規模投資は不要である可能性が高い:
  • 本当に大量のデータを生成しているか
  • そのデータを一度に大量に使う必要があるか
  • データが1台のマシンに収まらないほど大きいか
  • 単なるデータホーダー（溜め込み癖、捨てる事への恐怖症的な意味）ではないか
  • 集計・要約では要件を満たせないか
• 大多数の組織は実際のデータサイズに見合ったツールを選択することが合理的

(2026/05/18)

シニア開発者はなぜ専門知識をうまく伝えられないのか？

• シニア開発者はなぜ専門知識をうまく伝えられないのか？ - GIGAZINE

要約:

■ 1. 背景: AIと開発者の役割

• AIエージェントによるソフトウェア開発の普及に伴い、開発者の必要性への疑問が生じている
• シニア開発者の役割は単なるコード記述にとどまらず、不要な開発の回避、複雑さの抑制、稼働中のシステムの維持にある
• コピーライターのトゥヒン・ナイール氏が、シニア開発者の専門知識が伝わりにくい理由を「複雑さ」と「不確実性」の観点から説明している

■ 2. シニア開発者の2つのタイプ

• 新しいツールや外部のベストプラクティスを持ち込むタイプ
• 実装の必要性を問い、既存のもので対応できないかを検討するタイプ
  • ナイール氏はこの後者を評価している
  • コードを増やす前に、実装の回避・規模の縮小・既存リソースの再利用を検討する

■ 3. 複雑さと不確実性の対立

• シニア開発者が警戒するもの: 「複雑さ」
  • 新しい条件分岐、データベーステーブル、コンポーネントの追加がシステムを複雑にする
  • コードを増やす前に「本当に必要か」を確認する
• ビジネス側が恐れるもの: 「不確実性」
  • 市場向けループ: 会社が市場にプロダクトを出し、フィードバックを受け取る
  • マーケター、営業、PM、CEOなどが「何に価値があるか分からない」という不確実性を減らそうとする
  • できるだけ早く市場に出して反応を得ることが重要
  • 既存ユーザー向けループ: 会社が既存ユーザーにサービスを提供し、支払いを受ける
  • サービスの継続稼働、問題発生時の理解・修正・デバッグの容易さが重要
  • 複雑さが増すほどこれらが困難になる

■ 4. 専門知識が伝わりにくい理由

• 市場向けの人々は「早く出してフィードバックを得たい」と考える
• シニア開発者は「複雑さを抑えて安定したサービスを提供したい」と考える
• 優先する問題が異なるため、専門知識が伝わりにくい

■ 5. シニア開発者の専門知識の示し方

• 「複雑さを増やしたくない」と伝えるだけでなく、「不確実性をより早く減らす方法」として専門知識を示す必要がある
• 不要なものを作らない力と既存のものを再利用する力が有用
• 具体例:
  • 調査データ収集: 新しい機能を作る前にGoogle Formsを活用する
  • 新機能への需要確認: 完全な機能開発前に既存UIへのボタン設置でクリック率を確認する
  • 新しい分析サービス: 「一つの判断、一つのグラフ、一つの指標」から始める
• フレーズ: "Can we try something quicker?"
  • 「quicker」: 相手が求める速さを認める
  • 「something」: 別の方法の存在を示す
  • 「try」: 不完全な状態でも試せる余地を残す

■ 6. AIの役割と責任の所在

• AIによって試作品やコードの作成速度は大幅に向上する
• AIにはシニア開発者が担う「責任を取ること」はできない
  • AIが書いたコードでシステムが理解しにくく、修正・デバッグ・教育が困難になっても、顧客への責任はAIではなく開発者が負う

■ 7. 2システム構造の提案

• スピード版: 速く試すためのシステム
  • AIエージェント、未レビューの生成コード、ジュニア開発者、マーケティング担当者が使用
  • 市場からフィードバックを得られる程度のものを素早く作ることが目的
• スケール版: 安定して運用するためのシステム
  • シニア開発者が安定性・理解しやすさ・拡張しやすさを重視して整える
  • スピード版で有効と判明したものを顧客向けに信頼できる形へ組み込む
• 実用例: 「スピード版は3日、スケール版は6週間」という提案が可能になる

■ 8. シニア開発者の再定義

• ナイール氏は、シニア開発者を「senior software developer」でなく「senior software editor（シニアソフトウェア編集者）」と呼ぶべきと結論づけている
  • 小説家が初稿を急いで書き、編集者が整えるプロセスに例えている

MEMO:

• 2つのシステムを並走させるのはちょっとなぁという感はある
• 正直に言うと勘弁願いたいし、そちらの方が複雑性が上がっているのではないか？
• フィーチャーフラグとかの方がよいのではないか？

(2026/05/18)

ソフトウェアの「設計原則」を、なぜ一部のエンジニアは生理的に嫌うのか

• ソフトウェアの「設計原則」を、なぜ一部のエンジニアは生理的に嫌うのか

要約:

■ 1. 記事の主張

• エンジニア間の「すれ違い」は性格や能力の問題ではなく、情報処理における認知戦略の構造的な違いから生じる
• チームで観察される共通のパターン:
  • コードレビューで矛盾した指摘が出る
  • 設計について「すぐ着手派」と「全体合意派」に分かれる
  • ドキュメント作成の習慣に大きな個人差がある
  • 同じタスクでも時間と成果物のスタイルが異なる
  • 技術力は高いが説明が苦手な人がいる
• これらの症状はリーダーから「怠慢」「スキル不足」「コミュニケーション能力の欠如」と判断されがちであるが、実態は異なる:
  • ドキュメントを書かない人: 本人の頭の中では完全につながっており、外部化に価値を感じていない
  • 作業が遅い人: 見えない工程（構造化、可視化）に時間を投資している
  • プレゼンが下手な人: 聴者レベルに合わせた知識の再構成プロセスが認知で機能しにくい

■ 2. 情報処理の二つの戦略

• 圧縮型（Internalizer）:
  • 情報を脳のワーキングメモリ内に保持することを優先する
  • 短い識別子、簡潔なコード、ショートカットの多用を好む
  • 迅速な判断と手数の少なさを重視する
  • 外化を「速度を落とすもの」と感じる傾向がある
  • 強み: コードベース全体を頭の中に保持し、実装レベルのバグや既知パターンの問題を検出する能力が高い
  • 弱み: 知識が内部に閉じ込められ、プレゼン能力が低下しやすい
• 展開型（Externalizer）:
  • ワーキングメモリを超える情報を外部（図、文書、コメント）に配置する
  • 長く説明的な識別子、詳細なドキュメントを好む
  • まず全体像を描いてから実装する
  • 文脈や意図の保存を重視する
  • 強み: 全体像を外部で俯瞰することで、構造的ゆがみや設計の一貫性欠如を検出する能力が高い
  • 弱み: タスク完了速度が遅くなる傾向がある

■ 3. 違いが生じる根本原因

• 両戦略は、同じ物理的制約（ワーキングメモリの容量限界）に対する異なる最適化である:
  • 圧縮型: 容量内に収めるために情報を削りたい
  • 展開型: 容量外に情報を置きたい
• 未確定情報への対応が両者の決定的な違いである:
  • 圧縮型: 曖昧さをワーキングメモリに「非圧縮のまま」置く必要があるため高コストを感じ、早期確定を求める
  • 展開型: 曖昧さを「？」付きで外部に置けるため、低コストで保持できる

■ 4. エラー検出能力の非対称性

• 圧縮型が得意な検出: 実装レベルのバグ、既知パターンの問題
• 展開型が得意な検出: 構造的ゆがみ、設計の一貫性欠如、未認識問題
  • ドメイン概念の不自然な統合
  • 特定コンポーネントへの依存集中
  • モジュール粒度の不均一性
  • 層構造の不自然な飛び越え

■ 5. 知識の呪いとプレゼン能力

• 圧縮型の人は高度に圧縮された知識をもつため、背景や文脈を「自明」として意識から除外している
• 聴者にとって理解の手がかりとなる情報がプレゼンに含まれない結果、説明が不十分になる
• 展開型は知識を外部に展開した状態で保持するため、「聴者が持たない部分」を構造的に認識でき、より効果的なプレゼンができる

■ 6. 認知戦略の発生過程

• 認知戦略は「生まれつきの性格」ではなく、後天的に獲得されるものである
• 発達段階:
  • 学校教育段階: 全員が圧縮と外化の両方を訓練される
  • プログラミング導入期: コードという強力な圧縮表現を発見し、一部の人が外化を「不要」と感じ始める
  • 初期の成功体験: 圧縮で成功した人は外化を捨て、外化で成功した人は維持する
  • 環境複雑化時: 外化を捨てた人も再び必要性を感じ、拾い上げる
• 圧縮型が外化スキルを習得することは純粋な能力拡張（新しい記憶域の追加）であり、比較的容易
• 展開型がワーキングメモリを物理的に増やすことは困難

■ 7. 設計原則と認知の前提

• 設計原則（関心の分離、単一責任、レイヤード化など）は展開型の認知を前提としている
• これらの原則は「システム全体を一度に頭に入れなくてよい構造を作る」ためのもの
• 圧縮型にとっては既に全体が見えているため、分割は「余計」「不要な間接参照」に感じられる
• 圧縮型/展開型は固定的なラベルではなく環境との相対的な位置であり、同じ人が別のチームでは別のタイプに見えることもある

■ 8. 実践的な対処法

• 冗長度の明示的合意:
  • ADR（意思決定記録）、ランブック化、コメント規則など、成果物ごとに「何をどこまで外化するか」をチームで定める
• 双方の貢献を評価できる基準の設定:
  • 圧縮型の貢献は即座に観測可能だが、展開型の貢献は「起きなかった障害」など反事実的である
  • 評価軸として「持続資産」「検知貢献」「育成・伝播」を独立させる
• 圧縮型の外化スキル獲得:
  • 尊敬する実践者の模倣から始める
  • 自己像との衝突を超える必要があり、「能力拡張」という認識が重要
• 展開型の効率化:
  • 「圧縮を強いる」のではなく、外化のI/Oコストを下げることが効果的
  • テンプレート整備、検索性向上、参照のボトルネック解消など
• フェーズごとの期待値変更:
  • 初期: 圧縮型的な素早さが優先される
  • 成長期: 設計可視化が重視される
  • スケール期: 構造の安定性が重視される
  • チームの行動規範や評価軸をフェーズに応じて更新する

■ 9. AI時代の展望と教育への示唆

• AIは「究極の圧縮型」として位置づけられる:
  • 圧縮型の強み（広域スキャン、論理的探索）で圧縮型の作業を完全に代替する
  • 展開型の作業面での強み（文書作成、可視化）も大部分代替する
  • 両者に共通で残るのは「何を問うべきかの組み立て」という判断力
• AIの普及により、形式化された問題解決能力の価値が相対的に低下し、曖昧な要件から本質を見極める力がより重視される
• 従来の学校教育は圧縮と外化の両方を訓練してきたが、プログラミング教育偏重やAI教育偏重ではこの基盤が失われる可能性がある
• AIを使いこなすには、AIなしで考える能力が前提になる

■ 10. 結論

• 圧縮型は本質を見出す力を持ち、展開型は歪みを見出す力を持つ
• この二つが補完関係にあることを理解することが、チームの認知能力を最大化する第一歩である

論評:

■ 1. 概要

• 本記事はエンジニア間の「すれ違い」を「圧縮型（Internalizer）」と「展開型（Externalizer）」の二類型で説明するモデルを提示する
• 著者の数十年にわたる個人的観察に基づく
• 著者自身が「科学的に証明された理論ではない」と明示しているが、その後の論述は留保と整合しない強度の主張を多数含む

■ 2. 論理構造の一貫性

• 二分法の採用と放棄の混在:
  • 「スペクトラムであり0か1ではない」と断りつつ、両者をほぼ固定的な類型として扱い続ける
  • 「展開型はワーキングメモリを物理的に増やせない」という非対称な主張はスペクトラムモデルと相性が悪い
  • どちらの前提で議論しているかが揺れており、都合に応じて使い分けられている
• 圧縮型の定義における循環論法:
  • 「圧縮型は先天的に大きなワーキングメモリを持っていることが多い」という主張の根拠が不明
  • ワーキングメモリの大きさを観察する方法が「圧縮型的な行動をとる」ことであり、説明が循環している
• 結論が前提を証明していない:
  • 設計原則への忌避反応という「症状」から認知戦略の差異という「原因」を推論している
  • 同じ症状を説明できる他の原因（訓練不足、組織文化、インセンティブ構造、経験領域の偏り）への検討がほぼない

■ 3. 主張の妥当性・実証性

• 「ワーキングメモリ」の使い方が認知科学と乖離:
  • 成人のワーキングメモリ容量は概ね4チャンク前後（Cowan 2001）という制約がある
  • 記事はこれを「圧縮型は先天的に大きい」「展開型は小さい」として個人差を本モデルの基軸に据えるが、根拠が薄弱
  • チェス熟練者の研究（Chase & Simon 1973）への言及はチャンク化による圧縮の説明であり、ワーキングメモリ容量の個人差の証拠にはならない
• 訓練非対称性の主張が強すぎる:
  • 「圧縮型が展開スキルを獲得することは比較的容易、展開型がワーキングメモリを増やすのは困難」という主張は一方向的に過ぎる
  • 展開型もチャンクの品質を高めることで処理できる情報量を増やせる
  • 圧縮型の外化習慣化の困難さは「比較的容易」と言えない程度の摩擦がある
• 「35歳定年説」の再解釈が投機的:
  • 「加齢による能力低下ではなく認知戦略の不適合が原因」という仮説に対し、他の説明（市場変化、給与水準の上昇、家庭責任、技術スタックのシフト）を退ける根拠がない
  • 著者の信念の表明であって論証ではない

■ 4. 設計原則についての主張

• 「設計原則（関心の分離・SRP等）は展開型の認知を前提としている」という着眼はユニークで一定の説得力がある
• 「設計原則 ＝ 展開型のための道具」と断定することの問題:
  • 設計原則が生まれた背景にはテスタビリティ、保守性、チームスケール、変更容易性など複数の動機がある
  • 「展開型認知への適合」は後付けで接続できる説明の一つに過ぎない
  • 因果の方向が逆の可能性（展開型の思考法と親和性が高いから好む）も検討されていない
• 展開型が設計原則に「溺れる」リスク（過剰なマイクロサービス化など）への言及は公正

■ 5. AI論の妥当性

• 「AIは究極の圧縮型」という比喩の問題:
  • AIにワーキングメモリという概念は当てはまらない
  • LLMのコンテキストウィンドウや推論機構は人間の作業記憶とは全く異なる仕組み
  • 比喩を事実として使用する論理的誤謬がある
• AI代替についての主張:
  • 「圧縮型の作業はほぼ完全に代替され、展開型の作業的強みも大部分代替される」という主張は現時点のAI能力の過大評価と将来についての根拠のない断言が混在している
• 「残るのは問いの組み立てと判断力」という結論は本記事のフレームワークから導出されたものではなく、既存の言説に乗っかっている

■ 6. 実践的有用性

• 有用な提案:
  • 「冗長度（外化水準）を成果物ごとにチームで明示的に合意する」という提案は具体的かつ実行可能
  • 「圧縮型の遅さを叱るのではなく外化I/Oコストを下げる」という発想の転換は有用
  • フェーズ別の期待値変更（初期は速度優先、成長期は可視化重視）は実務的に正しい観察
• 問題点:
  • 圧縮型が外化スキルを獲得するための具体的な方法が「尊敬する実践者を模倣する」という程度に留まっており、最も重要な部分が最も薄い

■ 7. 総合評価と総括

• 総合評価（2.4/5）:
  • 論理構造の一貫性: 2/5
  • 主張の妥当性・実証性: 2/5
  • 設計原則論の妥当性: 3/5
  • AI論の妥当性: 1.5/5
  • 実践的有用性: 3.5/5
• 最大の問題は「科学的証明はない」という免責と、科学的に証明されたかのような強度で行われる主張の間の矛盾:
  • 「ワーキングメモリ容量の先天的差異」「訓練可能性の非対称性」「AIが圧縮型の仕事をほぼ完全代替する」はいずれも免責文言と整合しない断定の強さで語られている
• 個人観察を経由した仮説に神経科学・認知科学・AI論を接合することで疑似的な権威付けを行っており、接合部の論理が弱い
• エンジニア間のすれ違いを「性格ではなく構造」として再解釈しようとする動機と方向性自体は評価できる
• 「ワーキングメモリ容量の先天的差異」を持ち出すことは「性格の問題」を「脳の問題」に置き換えているだけであり、本質主義の罠に落ちている可能性がある

(2026/05/18)

Umbrella issue という well-known な 1 単語を覚えただけで、1 日 20 PR がリアルになった

• Umbrella issue という well-known な 1 単語を覚えただけで、1 日 20 PR がリアルになった - CARTA TECH BLOG

要約:

■ 1. 記事概要

• タイトル: 「Umbrella issue という well-known な 1 単語を覚えただけで、1 日 20 PR がリアルになった」
• 著者: NAKKA-K（CARTA HOLDINGS テックブログ、2026-05-11 公開）
• 主題: AI支援開発において「Umbrella issue」という概念を活用することで開発速度が向上するという知見

■ 2. 1 日 20 PR の壁はコンテキストの供給にある

• AI コーディングのボトルネックは LLM 側ではなく、開発者側のコンテキスト供給にある
• 個別タスクごとにプロンプトで指示を書く従来のアプローチは、全タスクを分割して他人に依頼する構造と本質的に変わらない
• 先に高品質なコンテキストを入力し自律的に進められる環境を整えることで、後続の指示を簡潔化できる
• 1 日 20 PR の実現は、この設計の効果に依存する

■ 3. well-known な単語が長い前提説明を肩代わりする

• 運用パターンに共有された名前がつくと、その 1 単語で前提説明をまるごと省ける
• 「依存構造を持つ複数の issue / PR をまとめて、親 issue から checklist で潰していく運用」を説明するだけで数百 token が消費される
• well-known な名札があれば、1 単語に同じ構造が圧縮されており、キーワードを 1 個渡すだけで済む
• 複数のレベルで効果がある:
  • 人相手には共通言語として機能する
  • LLM 相手には token 節約として機能する
  • 自分相手には頭の整理として機能する
• 使える語彙を増やすこと自体が、AI コーディングのスループットを押し上げる行為になっている

■ 4. Umbrella issue の定義と運用

• 定義: 「ある領域に対する Day 0 triage の結果と、複数 PR で潰していく checklist を 1 枚にまとめた親 issue」
• 単なる親 issue ではなく、特定の運用パターンを指す
• 実例:
  • https://github.com/facebook/react/issues/16087
  • https://github.com/JedWatson/react-select/issues/4559
  • https://github.com/gatsbyjs/gatsby/issues/21995
• 運用フロー:
  • Day 0 triage: 領域の現状を一気にスキャンして scorecard 化する
  • Checklist 化: タスク一覧を整理する
  • 独立 PR で潰す: 各タスクを個別 PR で実装する
• Scorecard の構成例（frontend 領域を対象にした場合）:
  • lockfile
  • TS strict
  • Biome
  • coverage
  • E2E
  • CI 中央値
  • TODO 真数
• 各タスクは独立した PR で出され、PR 説明に親 issue への Refs を記載し、マージ時に該当 checkbox が自動で閉じられる

■ 5. 圧縮された言葉が人にも AI にも効く

• 自分の頭の中:
  • タスクの依存・順序・残量が 1 枚に集約される
  • 「次どれやる？」が 5 秒で決まる
• AI への指示:
  • 「Umbrella issue をできるところまで全て並列でやって」という簡潔な指示で済む
  • 背景・Scorecard・関連 PR の文脈はその場で参照される
• PR 説明:
  • 親 issue への Refs 1 行で必要な背景が貼り付く
  • 冗長な説明文が不要になる

■ 6. Umbrella issue の前提条件と実感

• Claude Code が常時アクセスでき、セッションを跨いで利用できるチェックリストが必要という前提がある
• Umbrella issue という言葉を使うことで、タスクを進めるためのフェーズ分けや TODO の洗い出し精度が明確に向上する
• 現在、著者が開発しているものだけでも、複数のリポジトリで並列にそれぞれ 10〜20 PR が動いている状況
• 推奨する始め方: 明日、自分の担当領域で Umbrella を 1 本書いてみること

MEMO:

• 「Umbrella issue」という単語の意味が分からなかったのだが、英語圏ではUmbrella（傘）は複数の要素を束ねるという含意を持つらしく、Umbrella issuとは複数のイシューを束ねたイシューというニュアンスになる模様

(2026/05/17)

テストケースをコードで書かないE2Eテスト ── Claude CodeとPlaywright CLIで実現する自然言語...

• テストケースをコードで書かないE2Eテスト ── Claude CodeとPlaywright CLIで実現する自然言語テスト自動化 - ZOZO TECH BLOG

要約:

■ 1. 背景と課題

• ZOZOのカート・決済チームにおいて、E2Eテストの整備に多大なコストが発生していた
• 課題の内訳:
  • 機能リプレイスに伴い、プロジェクトあたり100件以上のテストケースが発生する
  • 割引・クーポン・ポイント・税計算など複雑な注文金額の手動検証に多くのリソースを要する
  • 従来のPlaywrightによる自動化にはプログラミングスキルが必要で、担当者に依存が生じていた

■ 2. システム構成

• 主要コンポーネント:
  • Claude Codeエージェント（zozotown-qa-tester）: テスト実行全体を管理する
  • Playwright CLI: コマンド経由でブラウザを操作し、スナップショットベースで要素を選択する
  • Agent Skills: 再利用可能な操作手順をMarkdownファイルで定義したもの
  • TypeScript製計算サービス: テストの期待値を算出する
  • カスタムCLI（atlassian-cli、zozo-sql-server-cli）: ConfluenceおよびDBへのアクセスを担う

■ 3. 主要技術: スナップショットベースの要素選択

• CSSセレクタではなく、ページ構造をYAML形式でref番号付きのスナップショットとして取得する
• AIがスナップショットを解釈して対象要素を特定し、ref番号を用いて操作を行う
• 小規模なUI変更に対して従来手法より高い耐性を持つ

■ 4. テスト実行フロー

• 6ステップの実行フロー:
  • ステップ1: Confluenceからテストケースを取得する
  • ステップ2: 期待値を含むテスト計画を生成し、ユーザーの承認を得る
  • ステップ3: テスト環境を準備する
  • ステップ4: Agent Skillsに従い操作を実行する
  • ステップ5: 結果とスクリーンショットを記録する
  • ステップ6: 結果をレポートとして出力する
• 承認ステップの目的:
  • 実行前に解釈の誤りを防ぐ

■ 5. 検証戦略

• システム実装とテスト実装を仕様から独立してそれぞれ別に実装する
• 実装の共通化を避けることで、共通バグの混入を防ぎ、真の検証を可能にする

■ 6. Agent Skillsの設計方針

• スキルの粒度は、ログインやカート操作など単一の手順単位が最適とされる
• 未定義の操作が発生した際、自動的に新規リファレンスを生成する自己改善の仕組みを持つ

■ 7. 従来手法との比較

• テスト形式:
  • コードベース: TypeScript/JavaScriptで記述する
  • Claude + Playwright: 自然言語（Confluence）で記述する
• テスト作成に必要なスキル:
  • コードベース: プログラミングスキルが必要
  • Claude + Playwright: ドメイン知識のみで作成可能
• UIへの耐性:
  • コードベース: 低い
  • Claude + Playwright: 高い

■ 8. 実績と効果

• プロジェクトあたり約20〜70件のテストケースを実行する
• PCとSP（スマートフォン）のバリアントを並行して実行する
• 複雑な計算検証における手動作業の負担が大幅に軽減された
• リファレンスの自己改善により、将来のテスト作成が加速する

(2026/05/17)

CQRS/ESはなぜ書き込みDBと 読み取りDBを分けるのか？

• CQRS/ESはなぜ書き込みDBと 読み取りDBを分けるのか？ - Speaker Deck

要約:

■ 1. 発表の概要と問題提起

• 発表者のバックグラウンド:
  • RailsWayを守りつつDDD・モジュラーモノリス・クリーンアーキテクチャを実践し、さらなる設計スキルアップとしてCQRS/ESをフルスクラッチで学習中
• 問いの出発点:
  • 「CQRS/ESはソースコードレベルで実装を意識していればメリットを受けられるのか」
• 発表者の見解:
  • 書き込みDBと読み取りDBが分離されない場合、CQRS/ESのメリットを享受できない
  • CQRS/ESのメリットを享受する為には書き込みDBと読み取りDBは分離されるべきである
• 本LTの目的:
  • CQRS/ESにおいてなぜ書き込みDBと読み込みDBを分けるとよいのかを伝えること

■ 2. DBが依存している場合の問題

• 典型的なコード例として、コマンド（更新処理）の直後にクエリ（取得処理）で同一テーブルを参照するパターンが挙げられる
• 書き込みDB側の問題:
  • シンプルさと再現性を持たせることができない
• 読み込みDB側の問題:
  • 拡張性が持ちにくく柔軟に対応できない

■ 3. CQRS/ESの書き込みDB・読み込みDBの特徴

• 書き込みDB:
  • 「出来事」を追記するだけなので、いつ・何が起きたかを時系列で正確にさかのぼれる
  • 追記のみのシンプル構造により、従来のDB設計と比較して高トラフィック下でも高スループットを維持できる
• 読み込みDB:
  • 画面やレポート用に「そのまま使える形」でデータを保持する
  • ユースケースごとに自由なリードモデルをいくつでも追加できる
  • データは自己完結であり、他のテーブルに依存しない

■ 4. CQRS/ESがもつ3つのメリットと、DBが依存する場合に失われる理由

• システムで実行した履歴を追える:
  • 本来の姿: 追記のみのイベント蓄積データにより「いつ・誰が・何を」実行したかを保持できる、ログをリプレイすれば当時の挙動を再演できる、任意時点のRead Modelをいつでも即生成できる
  • 依存する場合に失われる理由: 状態を上書き保存する構造のためイベントが残らない、「最新の状態だけが真実」という前提に縛られ過去履歴が捨てられる、変更箇所がDBに残らないためログが存在するかどうかに依存するしかない
• ハイトラフィックな書き込みへの対応がしやすい:
  • 本来の姿: 書き込みDBは最小限のデータ追記だけで済むため高速処理が可能であり、イベント追記のコードだけ調整すればパフォーマンスを改善できる
  • 依存する場合に失われる理由: 書き込みと読み込みを同じテーブルで連続実行するため書き込み処理が遅くなる、書き込み用と読み込み用が同一DBにあるため読み取り側の負荷も考慮しながらチューニングしなければならない、イベント追記とは無関係な箇所が遅延の原因になりうる
• ユースケースに特化した表示用データが簡単に作成できる:
  • 本来の姿: ユースケースに合わせてRead Modelを任意の形で作成でき、余計なJOINや正規化を意識しなくてよい、UIや画面が変わっても書き込みロジックに影響しない
  • 依存する場合に失われる理由: イベントが更新方式では履歴が残らないため過去の流れをたどってRead Modelを再構築できない、読み取り用テーブルを追加するたびに書き込みDBのスキーマ変更が必要となり影響範囲が広く気軽に増やせない、普通のDB設計となりテーブル同士が独立せず複雑なSQLが必要になる

■ 5. 推奨される設計

• 書き込みDBへの書き込みタイミング:
  • コマンドが実行されて確定し、イベントが発行されたタイミングで書き込みDBにイベントを追記する
  • 更新は行わず、イベントの追記のみを担い、表示側のことは一切考えない
• 読み込みDBへの書き込みタイミング:
  • コマンド側からイベントの発行を受け取り、それをプロジェクティングして読み込みDBを更新する
  • 読み込みDBのリードモデルは、書き込みDBを参照して必要になったタイミングでいつでも作成できる
• プロジェクティングとは:
  • イベントは何が起きたかという事実の記録であり、表示側の都合を考えず書き込みDBに追記する
  • そのイベントを表示用に整形して読み込みDBに書き込む処理がプロジェクティング

■ 6. CQRS/ESのDBの流れ

• コマンドを実行 → イベント発行 → 書き込みDBにイベントを追記 → プロジェクティングによりリードモデルを生成 → 読み込みDBへ反映 → 表示用データの取得
• 書き込みDBと読み込みDBは独立しており、読み込みDBは書き込みDBを参照して任意のタイミングで生成・再生成が可能

■ 7. DBを分けることが適しているユースケース

• DBを分けることで複雑なシステムへの対応が可能になる
• 適用が有効なケース:
  • ハイトラフィックなサービス
  • 業務向けサービスやSaaS
  • その他の複雑なサービス全般

MEMO:

• 「■ 2. DBが依存している場合の問題」で例示されたコードはCommandを担うロジックがQueryの役割まで担っているという点が根本的な問題と思われる

(2026/05/16)

AI時代に、チケットというUIはまだ最適なのか

• AI時代に、チケットというUIはまだ最適なのか - TechDoctor開発者Blog

要約:

■ 1. チケットの役割と定義

• チケットは以下の課題を解決するインターフェースとして機能してきた:
  • バグや変更要求の追跡
  • 作業の優先順位付け
  • チーム間のハンドオフ
  • 責任の明確化
  • 進捗管理と証跡保存
• チケットは「文脈圧縮インターフェース」と定義され、実装が遅く多くのハンドオフが必要だった時代に最適化されたものである

■ 2. AI時代における課題

• AIが実装、テスト生成、レビュー補助を高速化することで、チケット作成に費やす時間の相対的なコストが増大している
• チケット中心の開発から、「何を実現したいのか」という意図（Intent）を軸にした開発へのシフトが求められる

■ 3. チケットの役割分解と再配置の提案

• 従来チケットが担ってきた複数の役割を分解し、それぞれ適切な場所に配置することが提案されている:
  • 背景・意図: 設計ドキュメント、ADR
  • 仕様・制約: 実行可能な仕様、テスト
  • 作業実行: AIエージェントが動的に生成
  • 進捗管理: PR、CI/CD、自動観測
  • 検証: テスト、CI、AIレビュー
  • 証跡: PR、commit、実行履歴

■ 4. 結論

• チケットは消滅するのではなく、開発の唯一の中心ではなくなる
• Intentを軸につながった情報を人間が確認するための「ビュー」へと進化していく

(2026/05/16)

クラウドネイティブ DB はいかにして制約を 克服したか？ 〜進化歴史から紐解く、スケーラブル...

• クラウドネイティブ DB はいかにして制約を 克服したか？ 〜進化歴史から紐解く、スケーラブルアーキテクチャ設計指針〜 - Speaker Deck

要約:

■ 1. クラウドネイティブDBの定義

• CNCF Cloud Native Definition v1.1 に基づき、近代的でダイナミックな環境において以下を実現するDBを指す
  • 動的にスケールできる能力
  • 回復性・管理力・可観測性のある疎結合システム
  • インパクトのある変更を最小限の労力で行える能力
• CNCF定義の3項目は、DBでは4つの実装パターンに分解される
  • スケーラビリティ: 動的スケーリング / Scale to Zero
  • 疎結合の実現: Compute / Storage 分離
  • 管理力・回復性: マネージド運用 / 自己修復
  • DB固有の整合性: 分散合意 + 時刻順序

■ 2. クラウドネイティブDBが克服すべき3つの壁

• 壁①書き込みボトルネック:
  • 単一プライマリでの書き込み頭打ち
  • 単一障害点（SPOF）のリスク
  • 手動シャーディングの運用負荷
  • トレードオフ: 運用負荷
• 壁②I/O負荷とスケーリング:
  • 従来RDBのアーキテクチャ限界
  • 可用性と拡張性の両立困難
  • ハードウェア故障時のリカバリ負荷
  • 高速なスケールアウトが不可能
  • トレードオフ: ネットワーク帯域
• 壁③分散下の強い一貫性:
  • ノードのクラッシュの復旧
  • 不可避な「時計のズレ」
  • レプリケーションラグの影響
  • イベント順序の非決定性による不整合
  • トレードオフ: レイテンシ

■ 3. 第1章: 書き込みスケールの壁 ─ シャーディングの系譜

• ボトルネックの要因: DISK IO / CPU（ロック競合、計算）/ 帯域 / RAM の物理的上限（単一ノード性能上限）
• 解決策: データを複数ノードに分散し、書き込みを並列化する（シャーディングによるスループットの水平スケール）
• シャーディングの配置場所による設計パターン:
  • 手動シャーディング:
  • アプリケーション側でシャードキーを管理する原始的な水平分割
  • 得たもの: 書き込みスケール、データ局所性、障害影響範囲の分離
  • 失ったもの: クロスシャードJOIN、分散トランザクション、透過的なリバランス
  • 運用上の痛み: シャード追加・リバランスが手作業で重い、アプリ側にデータ配置ロジックが漏れる、シャードキー変更が事実上不可能
  • マネージドシャーディング:
  • ミドルウェア・プロキシ層が複雑なシャーディング構造を抽象化
  • 代表例: Vitess（MySQL前段）、Citus（PostgreSQL拡張）、Aurora PostgreSQL Limitless
  • 進化点: シャード管理の自動化、透過的なクエリルーティング、リシャーディングの簡素化
  • 重要な制約: ミドルウェアで隠蔽しても、データ局所性の設計は不可欠、ノード間を跨ぐJOINや集計処理のパフォーマンス劣化が発生
  • シェアードナッシング:
  • 各ノードが独自のCPU/メモリ/ディスクを保持し、運用中に自動リバランスを実行
  • 代表例: Spanner、CockroachDB、TiDB、YugabyteDB
  • 利点: ノード追加による水平スケール、自動でのリバランス（Split, Merge）
  • 課題: 特定ノードへの負荷集中（ホットスポット）、通信オーバーヘッドによるレイテンシ、分散クエリの効率低下
• 設計指針の適用:
  • 制約の明示化: シャードキー設計＝「データ局所性」を明示的に設計に組み込む
  • 責任の所在の移動: アプリ → ミドル → DB自身（隠蔽の度合いが向上）
  • トレードオフの選択: 分散処理（JOIN/トランザクション）やリバランスコストの受容
• 残る課題: シャーディングでも解決しない1ノード内のI/O負荷限界、リカバリ・ノード追加の高いコスト、より高速で柔軟なスケーリングの必要性

■ 4. 第2章: I/O負荷とスケーリングの壁 ─ ログ適用型ストレージの系譜

• 従来DBの問題: 「単一サーバー前提アーキテクチャ」における多すぎる責務がI/O増幅を招き、スケーリングを困難にする
  • 多すぎる責務: ログ生成/ページ更新、チェックポイント作成、レプリケーション/バックアップ、リカバリ
  • I/O増幅の発生: 1更新が複数の物理I/O（ログ生成、バックアップ用ログの二重書き、フルページ書き込み、データページ書き出し）に
  • 負の連鎖（悪循環）: ノード追加には重いデータコピーが必須、高負荷時にスケールアウトするとコピー処理でさらに負荷が上がる矛盾
• 解決策: コンピュート/ストレージの分離 と ログ適用型ストレージ の組み合わせ
  • コンピュート/ストレージの分離:
  • 単一サーバー前提を解く第一歩
  • スケール操作からデータコピーを切り離す
  • ステートレス化されたコンピュート層で柔軟なスケールを実現
  • ログ適用型ストレージ（"Log is the DB"）:
  • コンピュート層: redo log recordだけを生成・送信
  • ストレージ層: redo logからページを再構築
  • redo処理 / fault-tolerant storage / self-healing / quorum をストレージサービス側に集約
• 分離する理由:
  • ノード追加コストの解消: 共有ストレージ参照のみで起動、ノード追加が数時間 → 数秒に短縮
  • きめ細かなスケーリング: コンピュートをステートレスにすることで分単位の弾力性を実現、Scale to Zeroも対応可能（Aurora Serverless / Neon）
  • 非対称なリソース消費: コンピュートはスパイク型、ストレージは単調増加型、別々にスケールすることが合理的
• ログ適用型ストレージの効果（Aurora SIGMOD 2017より）:
  • Network I/O削減: 7.7倍
  • Throughput向上: 35倍
• 業界横断のパラダイム:
  • Aurora（AWS、2014〜）: log-applied storageの元祖、6-way/3 AZ、Limitlessで水平スケール、DSQLでmulti-region active-active
  • Neon（Serverless）: Pageserver + Safekeeper構成、Paxos-based consensus、Branching / Scale to Zero、秒単位の課金体系
  • AlloyDB（Google Cloud、2022）: Paxos + HTAP、内部にLog Processing Service（LPS）、カラムナエンジンでHTAP対応、Omniでオンプレミス環境にも対応
• 設計指針の適用:
  • 制約の明示化: I/O増幅を「redo logのみ送信 + ストレージ側で実体化」として明示化
  • 責任の分離: computeとstorageを別の層として切り離す
  • トレードオフの選択: ネットワーク帯域 / quorum待ちレイテンシ
• 残る課題: コンピュートを分離しても、複数ノードに跨る整合性・順序づけは依然として別次元の難題

■ 5. 第3章: 強い一貫性の壁 ─ 分散合意とグローバル順序づけの系譜

• 課題: 分散すると、複数ノード間での「合意」と「順序づけ」が必要
  • replication順序: レプリカ間でログ順序を一致させる（= 分散合意）
  • transaction順序: 実時間の順序づけ（= グローバル時刻）
  • 両方解かないと強い一貫性には到達しない
• 2PCの問題点:
  • coordinator が死ぬと停止し、残ったworkerはcommit/abortを判断できない
  • 不確定状態のままworkerはロックを保持し続ける（連鎖的にハング）
  • 死んだと思ったcoordinatorが復活すると不整合が起きる
• 分散合意（Paxos / Raft）が解決すること:
  • 自動フェイルオーバー: リーダー障害時の自動再選出
  • データの自動同期: ログレプリケーション
  • 一貫性の維持: リーダー経由 / コミット済みは必ず読める
  • ネットワーク分断耐性: 過半数側が継続、少数派は停止
  • Paxos系: Spanner（Multi-Paxos）/ Neon
  • Raft系: CockroachDB / TiDB（TiKV）/ YugabyteDB / etcd / Consul
• 分散DBの中核処理は時刻に依存する:
  • 分散MVCC: 各ノードが独立にIDを発番できないため、グローバルなタイムスタンプが必要（Spanner: TrueTime、CRDB/Yuga: HLC、TiDB: TSO）
  • Snapshot Isolation: 全ノードで「どの時刻か」の合意が必要
  • Read at Timestamp / Time Travel: クロックスキューが大きいと整合性が壊れる
• 時刻同期の難しさ:
  • ノード間のクロックは必ずズレる（NTP: ms級 / PTP: μs級）
  • ネットワーク通信のラグ（RTT）が存在する
  • 「どのトランザクションが先か」を全ノードで合意するのは本質的に困難
• 各NewSQLのアプローチ比較:
  • Spanner（Google、2012）: TrueTime API + Commit Wait
  • 時刻を[earliest, latest]の区間として定義し、クロックの不確実性（ε）をAPIとして明示的に露出
  • Commit Waitによりε msだけ待機することで実時間順序 = タイムスタンプ順序を保証（External Consistency）
  • トレードオフ: commit wait（代償: ε msのwait / strict serializable）
  • CockroachDB（2015〜）: HLC（Hybrid Logical Clock）、汎用NTP環境でも因果順序を追跡可能
  • strict serializableは提供しない、causal reverse異常を許容
  • clock offset平均値が400msを超えると自己shutdown（Fail-Safe設計）
  • トレードオフ: retry + causal reverse許容
  • TiDB（PingCAP、2016〜）: TSO（Timestamp Oracle）+ PD（Placement Driver）による集中型タイムスタンプ発番
  • 順序づけがサービス化（集中管理）され、HLCのような複雑な時刻ズレ管理から解放される
  • トレードオフ: PD取得待ち（代償: Snapshot Isolation / cross-DCレイテンシ）
  • YugabyteDB（2016 / ClockBound 2025）: HLC + ClockBound統合
  • v2025.2 LTSでAWS ClockBound統合、TrueTimeに近い区間APIを活用、PHCによりμs級skewを実現
  • ClockBound有効時: Transaction Latency最大3倍短縮、Throughput 2倍向上（RF=3 / geo-distributed条件）
  • トレードオフ: クラウド時刻API（代償: AWS/GCP限定 / Serializableまで選択可）
  • Aurora DSQL（AWS、2025 GA）: Time Sync Service + Journal
  • トレードオフ: OCC retry（代償: 競合時のretry / region-set内）
• 設計指針の適用:
  • 制約の明示化: 時刻不確実性をAPIに組み込む
  • 責任の分離: 時刻管理を分離する
  • トレードオフの選択: commit waitによる書き込みレイテンシ / OCCによるリトライレイテンシ / TSO取得レイテンシ

■ 6. 3章の統合: NewSQLへの帰結

• 3つの壁すべてを解くのがNewSQL
  • 壁①のみ解く → シャーディングDB（Vitess / Citus）
  • 壁②のみ解く → クラウドRDB（Aurora / AlloyDB / Neon）
  • 壁③のみ解く → 分散KVS（etcd / Consul）
  • 壁①②③すべて解く → NewSQL
• 5つのNewSQLの3軸での比較:
  • Spanner: auto split/merge / Colossus + Paxos / TrueTime + Commit Wait
  • CockroachDB: range分割 / local + Raft / HLC
  • TiDB: region分割 / TiKV + Raft / TSO / PD
  • YugabyteDB: tablet自動分割 / DocDB + Raft / HLC + ClockBound
  • Aurora DSQL: region-set / Journal + 分離 / Time Sync Service + OCC
• 同じ"NewSQL"でも、3軸の選び方で性格が変わる

■ 7. 応用: 最適な選択基準の策定

• 壁①書き込みスケールを優先する場合:
  • MySQL互換で大規模分割 → Vitess / TiDB
  • PostgreSQL互換で水平分割 → Citus / Aurora Limitless
• 壁②I/O負荷・運用負荷を優先する場合:
  • 単一region・運用簡素化 → Aurora / AlloyDB
  • Scale to Zero・コスト効率 → Neon / Aurora Serverless
• 壁③強い一貫性を優先する場合:
  • 単一クラウドで強整合 → Aurora DSQL / Spanner
  • マルチクラウド対応 → CockroachDB / YugabyteDB / TiDB
• 経験則: 3つの壁すべてが本当に必要 → NewSQL系が見合う、2つ以下しか必要ない → マネージドDBで十分
• 3指針×5つの問い:
  • Q1（制約の明示化）何をスケールするか: 書込み大量 → Limitless / Vitess / NewSQL系、読込中心 → Aurora
  • Q2（責任の分離）どこにデータ配置するか: 単一region → Aurora / Spanner、全大陸 → Spanner、2region active → DSQL
  • Q3（トレードオフの選択）どの整合性か: strict serializable → Spanner / DSQL、SI → TiDB / Yuga、RCで十分 → Aurora
  • Q4（トレードオフの選択）何を犠牲にするか: commit wait許容 → Spanner、retry許容 → DSQL、causal reverse許容 → CockroachDB、TSO待ち許容 → TiDB
  • Q5（責任の分離）誰が複雑性を吸収するか: ベンダー全任せ → マネージド、自社運用 → OSS
• 同じ問いはメッセージングなどあらゆる分散システムに適用可能
• 大前提: 分散システムを作らない、制約を解決するために本当に分散システムが必要か十分に考慮すること

■ 8. まとめ: 分散システムの設計指針

• クラウドネイティブDBの進化は「制約 ↔ 分離 ↔ トレードオフ」という設計判断の積み重ねである
• 3つの壁とその克服:
  • 壁①書き込みボトルネック・運用負荷 → シャーディング、そして自動化（アプリ → ミドルウェア → DB自身）
  • 壁②I/O負荷・スケーリング → ストレージ分離、ストレージインテリジェント化（ログ適用型ストレージ）
  • 壁③分散環境下の強い一貫性 → 分散合意アルゴリズム + 一貫した時刻の管理（commit wait / OCC retry / TSO待ち / クラウド時刻API）
• 選択は「最強」ではなく「最適なトレードオフ」
  • 自分の要件で要らない機能の代償を払わない
• 分散システム設計の3指針:
  • ①制約を明示化する: 暗黙の前提を捨て、API・構造・境界として「可視化」する
  • ②責任を分離する: compute / storage、replication / transaction... 層をまたぐ責任を切る
  • ③トレードオフを選ぶ: 何を守り、何を犠牲にするか意図的に決める

(2026/05/16)

絶対に二度と触りたくないシステムランキング

絶対に二度と触りたくないシステムランキング

第3位　SAP GUI

もはや不動。不動ゆえに絶対に揺るがぬ王者。だったのだが、近年はコイツを脅かす存在が出てきている

第2位　SAP CONCUR

請求書、立替精算が楽になるとは何だったのか。コレが楽なら、人生は地獄だ。

何故ならこのシステムより楽なものが世界に存在しないことになるからだ

第1位　SAP Hana S4

最新版だからマシ？いやいや、その前にコイツに移すのが地獄だ。変更するのはSAP側のライセンスの問題である。

にも関わらず、多額の費用及び人員を投じて設計しなおしだ。ふざけんな。

全てのカルマを統合し、第一位としたい。

@Duetousandyou

MEMO:

• 全部SAPやんけ

(2026/05/16)

コンピューターの処理速度1000倍へ、東大が素子開発　発熱せず稼働

• コンピューターの処理速度1000倍へ、東大が素子開発　発熱せず稼働 - 日本経済新聞

要約:

■ 1. 研究概要

• 東京大学などの研究チームが、半導体チップの情報処理速度を1000倍速くする素子を開発した
• 研究成果は米科学誌「サイエンス」に掲載された
• 2030年までに実用的な試作チップの開発を目指す

■ 2. 素子の技術的特徴

• 名称: 「不揮発量子スイッチング素子」
• 動作原理:
  • 電気の流れではなく、電子が持つ磁石の性質（スピン）を使ってビットを表す
  • タンタルとマンガンスズの2種類の素材で構成される
  • タンタルに流した電気信号が、マンガンスズに微小な磁力の向きとして記録される
• 処理速度:
  • 1ビットの情報を40ピコ秒（従来の1000分の1）で処理できる
  • 従来技術では1ビットの記録に最短1ナノ秒を要する
• 耐久性:
  • 熱が生じにくく、1000億回以上の繰り返し処理でも安定して動作する
  • 既存技術で同等の処理速度を実現しようとすると、1000〜100万回程度で熱により故障する
• 応用:
  • 不揮発性メモリーへの応用が可能で、エネルギーをほぼ消費せずに情報を記録できる

■ 3. 既存技術の課題と背景

• 既存のトランジスタ技術では、処理速度が一定を超えると電力消費が急増し、熱が生じる課題があった
• 既存技術の処理速度は2000年代に限界を迎えていた
• AIの普及により処理する情報量と電力需要が増加している
• IEA（国際エネルギー機関）によれば、AIの普及でデータセンターの電力需要が2030年に945テラワット時に達すると見込まれ、2024年時点の2倍以上となり日本の総電力消費を上回る見通しである

■ 4. 実用化への展望

• 小型化に応じて性能が向上する傾向があり、実用化できれば消費電力を既存技術の100分の1に削減できる可能性がある
• 例として、1時間かかっていたデータのダウンロードを1秒で処理できる可能性がある（東大・中辻知教授）
• 試作チップの開発や製造には企業との協力が重要であり、グローバルな連携による社会実装を目指す

MEMO:

• 「1時間かかっていたデータのダウンロードを1秒で処理できる可能性がある」
• どういうことだ？
• データのダウンロードはネットワーク速度に依存すると思われるが？
• 比喩的なコメントがそのまま報道されちゃった感じか

(2026/05/15)

「医療システムの仕様」が原因で入院患者が死亡、なぜ病院側は要件定義の際に気付けなかったのか……

• 「医療システムの仕様」が原因で入院患者が死亡、なぜ病院側は要件定義の際に気付けなかったのか…… (1/3)|EnterpriseZine（エンタープライズジン）

要約:

■ 1. 要件定義上の不備とテストの限界

• 情報システムは複数のコンポーネントが複雑に連携して動作するため、機能間の連携仕様を要件として明確に定義する必要がある
• 結合テストや総合テストはプログラム間のインタフェース・処理タイミングの不正を検出するが、「連携を想定して定義されていない」要件上の不備は検出できない
• 機能間の連携をどのように定義するかは業務目線で判断すべき事項であり、テストの合否では判断できない

■ 2. 事件の概要

• 事件の背景:
  • ある病院では患者の生体情報を監視する「ベッドサイドモニタ」と「セントラルモニタ」がネットワーク連携するシステムを導入していた
  • ベッドサイドモニタにはアラーム設定を患者ごとに個別設定できる機能があり、異常時にアラームを発信する仕組みだった
• 事故の経緯:
  • くも膜下出血患者が転床した際、セントラルモニタで転床確定操作が実施された
  • この操作によりベッドサイドモニタのアラーム設定が病棟の初期値（アラーム音量ゼロ等）に上書きされた
  • 担当看護師はアラームをONにしたと認識していたが、システムの連携動作によって意図に反して設定が消滅した
  • 患者の容態が急変した際にアラームが鳴らず、医師の対応が遅れたため患者が死亡した
• 訴訟の概要:
  • 遺族が、担当医師または看護師のアラーム設定の誤りおよび見落としを過失として損害賠償請求訴訟を提起した（東京地方裁判所 令和2年6月4日判決）

■ 3. システム仕様と要件定義の問題点

• システム仕様の性質:
  • セントラルモニタが転床確定操作時にベッドサイドの設定を初期化する動作はシステム仕様どおりであり、プログラミングミスや不具合ではない
  • アラームのデフォルト値が音量ゼロである点にも、患者によってはアラームが身体に悪影響を与えるという医療上の理由が存在する
• 要件定義の不備:
  • ベッドサイドモニタとセントラルモニタそれぞれ単体の機能要件は十分だったが、機能連携時に発生し得るリスクの検討が不足していた
  • 設定が上書きされる際の警告メッセージは存在したが、「設定の完全な消滅」を予見させる具体性・強度を欠き、形式的なものにとどまっていた
  • 転床時にベッドサイド設定を先に行いセントラル側を後から設定するといった操作順序の揺れが業務上発生し得ることが想定されていなかった

■ 4. 裁判所の判断

• 転床確定操作を行った看護師について、以下の注意義務違反が認定された:
  • 転床確定操作によりベッドサイドモニタのアラーム設定値が初期値に更新されることを認識し得た
  • 操作後に患者の病状に即した適切なアラーム設定となっているか確認すべき注意義務があった
• 裁判所は病院側が十分に注意義務を果たさなかったと判断した

■ 5. 事故防止に向けた教訓と対策

• 要件定義の在り方:
  • 機能単体の要件定義だけでなく、機能連携時に発生し得るリスクシナリオを要件として定義しなければならない
  • 業務の中で様々に発生し得る状況とそのときのシステム挙動をリアルに想像し、仕様の問題点を十分に洗い出す必要がある
  • 要件上の不備は後続工程（テスト等）での発見が困難であるため、要件定義工程での網羅的な検討が不可欠
• 現場を巻き込んだ要件定義の実施:
  • 開発担当者はシステム利用者（今回の場合は現場の医療従事者）を要件定義に参加させ、各業務フローをウォークスルーしながら要件を詳細化する必要がある
  • 現場の実務経験を持つ担当者が参加することで、システム連携時の不備が現場への導入前に発覚する可能性が高まる
  • AIを活用しながら要件の精度と網羅性を高めることも、悲劇を防ぐ方策の一つとなる
• 病院側の対応:
  • システム導入に精通した要員の拡充や育成を含む様々な対策が求められる

(2026/05/15)

いまITエンジニアの人たちは今後のキャリアについてどう考えているのだろう？…いろんな人の話を聞いて...

• いまITエンジニアの人たちは今後のキャリアについてどう考えているのだろう？…いろんな人の話を聞いてみたい「まじで何ができるんだろう」「別職種への転職はありかも」 - Togetter

要約:

■ 1. 問題意識と背景

• AIの発展により、ITエンジニアの今後のキャリアに対して不安や疑問を持つ者が増加している
• エンジニア自身がエンジニア業への興味を失いつつあると感じているケースがある
• キャリア年数が浅い若いエンジニアほど失業への危機感が強い
• 就職活動中の学生も、IT系職種での生存可能性について懸念を示している

■ 2. 現状認識

• AIの影響に関する認識:
  • ノーコード・ローコードの台頭により、難易度の低い仕事は減少しつつある
  • 価値を創出できないエンジニアは不要になりつつある
  • 「言われたことをやるだけ」の人材は不要とする経営者の視点がある
  • コーディングのみを担う人材は淘汰されるという見方が多い
• AIの現状の限界に関する認識:
  • AIは不正確な回答をすることがあり、使い手側の知識レベルや監査能力が求められる
  • AI活用によって非エンジニアとの差別化が図れているという見方もある
  • 要件定義とアウトプットのレビューができなければ大したものは作れない

■ 3. キャリアの方向性

• 短期志向（特に中高年エンジニア）:
  • AIに駆逐されるまで働き続けるという割り切った姿勢
  • 10年以内に稼ぎ切って、その後はのんびりする計画を持つ者がいる
  • 残り年数が見えているため、どうとでも立ち回れるという余裕がある
• 適応・変化志向:
  • 時代の変化に乗り続けることが成長につながるという考え方
  • 変化に合わせて次の仕事が探せる経歴を積み重ねるという姿勢
  • 1つの業界やビジネス形態に特化して事業サイドの視点で自走することを意識する者がいる
• アプローチの転換:
  • 「技術を活かす仕事」から「技術という観点で問題解決をする仕事」への転換
  • 社内コンサルのような立ち位置で動くエンジニアが増えている
  • 技術に固執すると状況変化に弱くなるという認識がある

■ 4. 残る仕事・新たに発生する仕事

• AIと業務の仲立ち・パイプ役（数年後には不要になる可能性もあるという見方もある）
• セキュリティエンジニア:
  • AIの台頭によりセキュリティエンジニアの人材が不足している
  • AIを使って行われる攻撃への防御業務がメインになりつつある
• 自動化・効率化:
  • 謎業務を探して自動化することで、レイオフを提案する側に回れる
  • AIで何でも解決できるわけではなく、やることはまだある
• 粗雑なシステムの管理・保守:
  • ノーコード・ローコードで作られたセキュリティ・リスクを考慮しないシステムの管理
  • バイブコーディングで作られた肥大化したシステムの改修
  • 非エンジニアが作ったシステムの設計的な問題への対応
• その他継続・拡大する分野:
  • GWSやMicrosoft365のような大規模SaaSの導入（AIによる自動化が難しい）
  • レガシーシステムのリプレース、古い端末のスマホ化
  • AIを動かす基盤の構築・ツール間のパイプライン接続
  • ビジネス側との連携・上流工程の担当

■ 5. 別職種への転職

• エンジニアの技術・AI活用スキルを活かした別業種への転職を検討する者がいる
• ITで食えなくなった場合に備えて電工二種・電験三種などの資格取得を考えている者もいる
• 実際に飲食業やホテルフロントなど、IT以外の業種へ転職した事例がある

■ 6. その他の見方

• 直ちに仕事がなくなるわけではないという見方:
  • COBOLやCの組み込みなど、20年以上前から不要と言われながら需要が続いている技術がある
  • 保守性や既存システムとのすり合わせが多いため、職を失うことはないという意見がある
  • テスト業務はAIには難しいとして楽観視している者もいる
• 懸念・疑問:
  • 仕事が10倍速になっても、仕事が10倍振られるだけになるという懸念がある
  • ビッグテックが人間のエンジニアにどれだけの余地を残すかという疑問がある
  • AIの電力・メモリ問題でAI利用コストが高騰し人間に回帰する可能性がある
• ポジティブな見方:
  • AI活用でむしろ開発が楽しくなったという意見がある
  • 優秀な非エンジニアがバイブコーディングを自分で行った上でエンジニアに依頼するケースがあり、エンジニアが活躍している

MEMO:

• エンジニアとして稼げる間は稼ぎ、稼げなくなったら別業種に手を出すつもり
• とにかくスピード勝負になると思われるので、いずれ追従出来なくなる日が来るのは間違いない

(2026/05/15)

日産、次世代の車載OSにレッドハットを採用

• 日産、次世代の車載OSにレッドハットを採用 - ZDNET Japan

要約:

■ 1. 日産とRed Hatの次世代SDVプラットフォーム開発

• 日産自動車とRed Hatは、次世代ソフトウェア定義車両（SDV）プラットフォームを共同構築するエンジニアリングイニシアチブを発表した
• 発表は米国アトランタ開催の年次カンファレンス「Red Hat Summit 2026」（2026年5月14日まで）にて行われた
• 日産SDVソフトウェアプラットフォーム開発部ゼネラルマネジャーの杉本一馬氏が基調講演でRed Hatとの取り組みを紹介した

■ 2. 安全性と更新性を両立するアーキテクチャ

• 採用OS:
  • 「Nissan Scalable Open Software Platform」（SW PF）の基盤OSとして「Red Hat In-Vehicle Operating System」を採用する
  • 同OSはRed Hat Enterprise Linux（RHEL）ベースで、標準化されたスケーラブルなLinux基盤を提供する
• 従来の課題:
  • 従来の車載ソフトウェアは、品質・安全性の検証後に変更しないことを前提に設計されてきた
  • ソフトウェアの急速な進化により、従来の前提が通用しなくなった
• 新アーキテクチャの方針:
  • ソフトウェアを「安全性クリティカル領域」と「高頻度アップデート領域」に分離する
  • 高頻度アップデート領域にLinuxを採用し、チップ・センサーの世代交代がソフトウェアスタック全体に波及しない構造を実現する
  • SW PFはAmazon Web Services（AWS）上に構築される
• 分離アーキテクチャを支える2つの中核概念:
  • 抽象化とクリアなインターフェース設計: ドライバーおよびハードウェア依存レイヤーを分離し、上位レイヤーには標準化されたAPIのみを公開することで、ハードウェア交換時の影響を最小化する
  • モジュール化と独立デプロイ可能性: 機能をコンテナーやサービスユニットに分割し、各機能を独立してビルド・テスト・デプロイ・アップデートできるようにする、これによりターゲットを絞ったOTA（Over-the-Air）アップデートが可能となり、車両ソフトウェアの継続的な進化を支える

■ 3. AI定義車両が変えるコンピュートとデータの要件

• AI定義車両への発展:
  • 日産はSDVをさらに進化させ、AIを車両の中核に据えた「AI定義車両」（AI-Defined Vehicle）へと発展させる
  • この転換によりコンピュートとデータの要件が根本的に変わるとされる
• コンピュートの方針:
  • 進化し続けるAIワークロードへの対応を最優先課題と位置づける
  • 車載・車外・ハイブリッドのいずれにも柔軟に対応でき、特定のチップ世代に縛られないアーキテクチャを目指す
• データの方針:
  • モデル改善にとどまらず、説明責任・信頼性・継続的な学習の確保を重要課題とする
  • セキュリティ・プライバシー・ガバナンスの組み込みを前提とする
• 統合開発モデル:
  • Red Hatのエンジニアリング人材を日産の開発パイプラインに直接組み込む「統合開発モデル」を採用する
  • 技術革新と同等に、人材とパートナーシップを重要視する
  • Red Hatとの協業を通じ、内部能力の強化とAI定義車両の展開加速を目指す

(2026/05/15)

なぜ、今「会社に戻る」のか　フリーランス→正社員が2.8倍の背景

• なぜ、今「会社に戻る」のか　フリーランス→正社員が2.8倍の背景（ITmedia ビジネスオンライン） - Yahoo!ニュース

要約:

■ 1. フリーランスから正社員への転換増加の実態

• 転職支援サービス「リクルートエージェント」の2024年4～9月の実績では、正社員への転職数が5年前比2.8倍に達した
• 「doda」でも同期間で2.7倍に増加した
• Hajimariの正社員転換支援実績は直近1年で250%（3.5倍）増加した
• 一方、フリーランス人口は2024年に1303万人と10年前比40%増であり、フリーランス市場そのものは拡大している

■ 2. 正社員回帰の主な要因

• コロナ禍の反動:
  • 2020～21年にIT需要が急増し、経験の浅い人材もフリーランスになりやすい環境が生まれた
  • 2023年以降、市場の成長鈍化や収入面の厳しさに直面した人が正社員への転換を求めるようになった
• AIへの不安:
  • 先行きが見えないことがフリーランスの不安の源となっている

■ 3. 正社員に転換するフリーランスの4つのパターン

• スキルが十分でないまま独立した20～30代の若手
• ライフステージの変化で安定を求める40代
• AIや市場の変化に敏感に反応する層
• プロダクトや組織に深くコミットしたいと考える上流志向の層

■ 4. フリーランスの収入構造の実態

• 高収入の可能性:
  • スキルの高いエンジニアであれば月単価90万円以上の案件もあり、年間売上が1000万円を超えるケースもある
  • Hajimariの調査では「年収1000万円は余裕で稼げる」との回答が38%に上った
• 収入の実質的な制約:
  • 社会保険料の会社負担分、退職金、有給休暇、賞与はフリーランスが自力で賄う必要がある
  • 休めば収入がゼロになり、営業活動や請求業務も無給の労働となる
  • 会社員と同じ生活水準を維持するには1.5～2倍の売上が必要とされる
• 収入への不満:
  • ランサーズの調査では収入に「満足している」フリーランスは32%にとどまる
  • 1人当たりの紹介案件数が減少傾向にあり、案件の奪い合いが続いている

■ 5. AIの台頭による業務・役割の変化

• AIの影響による市場変化:
  • 生成AI関連のフリーランス案件単価は他職種比で月10万～20万円高い傾向にある
  • 要件定義や設計などの上流工程の求人はこの1年で10%増加した
  • コーディングなどの下流実装業務は単価が低下し、求人数も5%減少した
  • 米Upworkのデータでは生成AI登場後にライティングの求人が33%減少した
• 求められる役割の変化:
  • エンジニアの役割は自らコードを書く「作り手」から、AIに指示してプロジェクトを統括する「設計者」へと移りつつある
  • 何を作るか・なぜ作るかを判断する上流工程の価値が相対的に高まっている
  • 上流の仕事をこなすには下流の経験が不可欠であり、コーディング経験がAIへの的確な指示につながる

■ 6. フリーランスのキャリア展望に対する不安の拡大

• 日本労働組合総連合会の調査では「将来の展望がある」と回答したフリーランスの割合が2023年から2024年にかけて、20代で13.5ポイント、30代で14.7ポイント、40代で13.2ポイントそれぞれ低下した
• フリーランスには教育・研修の機会が乏しく、先輩や仲間から学ぶ環境がほとんどない
• 組織に属していれば、研修などを通じて上流工程への移行を図りやすい
• AIの開発に必要な企業のデータは、情報セキュリティの観点から外部人材には開示されないケースが多く、フリーランスは重要度の低い周辺業務にとどまりやすい

■ 7. 企業側の受け入れ環境の変化

• ジョブ型雇用やリモートワークの普及により、正社員でも柔軟な働き方が可能になった
• GIGの調査（2025年）では、フリーランスが正社員転換時に最も重視する条件は「リモートワークやフレックス勤務の確保」（69.2%）であり、「年収・給与」（57.5%）を上回った
• 企業向け調査では54.7%がフリーランスの正社員採用実績を持ち、73.6%が今後も積極的に採用したいと回答した
• SOMPOホールディングスなどの大手企業がDX部門を中心にフリーランス経験者の正社員登用を進めている
• フリーランス経験者は、スキルが明確でミスマッチが起きにくい人材として評価されている

■ 8. 今後の見通しと必要なスキル

• フリーランス市場の二極化:
  • フリーランス市場は今後も拡大するが、AIを活用できる人とできない人の格差がさらに広がる
  • ランサーズの調査ではフリーランスのAI活用率が3割以下にとどまる
  • 2024年施行のフリーランス新法の下でも、報酬や取引条件をめぐるトラブルは後を絶たない
• フリーランスとして活躍し続けるための要件:
  • AIを使いこなすスキルを前提として、主体性が必要とされる
  • 情報を自らキャッチアップし、能動的にコミュニケーションを取り、信頼を積み重ねることが求められる
  • AIの発達によりスキルのコモディティ化が進む中、主体性の重要性がいっそう増している

■ 9. キャリアの再設計という視点

• フリーランスから正社員に戻ることは「後退」ではなく、AI時代に求められるスキルを身に付けるための「再設計」と捉えるべきである
• キャリアの選択肢が広がった現在、問われているのは雇用形態ではなく、自分の市場価値をどう高め続けるかという視点である

(2026/05/15)

Replacing a 3 GB SQLite database with a 10 MB FST (finite state transducer) binary

• Replacing a 3 GB SQLite database with a 10 MB FST (finite state transducer) binary Andrew Quinn's TILs

要約:

■ 1. プロジェクト概要: Taskusanakirja (tsk)

• フィンランド語-英語辞書アプリ「Taskusanakirja（tsk）」の開発プロジェクト
• インクリメンタルな検索機能（入力に応じたリアルタイム検索）を備える
• 設計当初より、単一バイナリ（.exe、.app、静的リンクバイナリ）での配布を目標とする
• 「ポケット辞書（taskusanakirja）」のコンセプトに基づき、古いノートPCでも動作することを要件とする
• Go言語によるTUIプログラムとして開発を開始し、fzfプロトタイプ（finstem）から発展した経緯を持つ
• 本記事における数値はすべて最初の有効数字に丸めて表記している（Rob Eastawayの「zequals」手法に基づく）

■ 2. 初期実装: トライ木によるプレフィックス検索

• 実装内容:
  • Go言語でトライ木（trie）を用いたプレフィックス検索を実装
  • 上位50〜100件への絞り込みと、1〜3文字の組み合わせのメモ化により遅延を解消
  • 基本的な最適化により約60MBのメモリ使用量を実現
• フィンランド語の特性による限界:
  • フィンランド語は高度に膠着語的な言語であり、語幹1つから100以上の語形が生成される
  • 子音交替（例: katu → kadun）と母音調和が同時に作用し、語形変化が複雑となる
  • 15の格、2つの数、6つの所有接尾辞、不定数の付加詞の組み合わせにより、語形数が爆発的に増加する
  • トライ木は接頭辞（プレフィックス）のみを共有するため、-ssa-mme-kinのような共通接尾辞を持つ数千の単語のコストを共有できない
  • 40〜60万件の語形を格納しようとすると、トライ木では対応不可能となる

■ 3. 暫定解決策: SQLiteデータベース

• SQLite + FTS（全文検索）拡張機能を採用した暫定的な解決策を実施
• 検索遅延は体感上なく機能したが、初回ダウンロードに3GBを要するという問題を抱える
• この状態で約9ヶ月間停滞

■ 4. FST（有限状態トランスデューサ）による解決

• 発見の経緯:
  • BurntSushi（Andrew Gallant）による記事「Index 1,600,000,000 Keys with Automata and Rust」からfstクレートを発見
  • 有限状態機械を用いて文字列の順序集合・マップを圧縮表現し、前方一致・曖昧・後方一致検索が可能
• 実装と結果:
  • Rust言語でSQLiteデータベースからデータを抽出し、FSTバイナリに変換するプログラムを実装
  • 3GBのSQLiteデータベースを10MBのFSTバイナリに置き換え
  • 約300倍のメモリ削減を達成
• FSTがフィンランド語辞書に特に適した技術的理由:
  • FST（最小非巡回決定性有限オートマトン）はプレフィックスとサフィックスの両方を共有する
  • トライ木は接頭辞のみを共有するのに対し、FST構造的に同一なサブツリーをすべて統合する
  • フィンランド語では数十万の単語が同一の数十種類の活用パターン（接尾辞）を共有するため、FST構造との親和性が極めて高い
  • データがランタイム時に静的であるため、fstクレートの主要な制約（動的更新不可）を回避できる
• Rustへの書き換えについて:
  • 「Rewrite It In Rust（Rustで書き直せ）」はミームとして知られる
  • 「高速性・移植性が求められ、既存ツールのメモリ効率に問題がある」場合には有効な選択肢となる

■ 5. v2.0.0の展望

• Pro版v2は全機能込みで約20MBとなる見込み
• v1の無料版（約60MB）の3分の1以下のサイズとなる
• v1で使用していたFTSを利用する一部機能はv2での削除が検討されている

■ 6. 反復的問題解決に関する考察

• 暫定的なSQLite解決策の採用が、後のFST最適解への到達の前提となった
• 問題を二度解くことの意義:
  • SQLiteによる最初の解決策は機能し、B木やFTS拡張機能の仕組みへの理解を深めた
  • 9ヶ月の実務経験を経て、より優れた解決策（FST）への到達が実現した
• 車輪の再発明に関する見解:
  • 多くの分野では4〜5回、数学・計算機科学では20〜30回程度の再発明が、知識の最前線への到達を促進する
  • 受動的な学習の同量の時間と比較しても、再発明と問いかけの実践の方が最前線への到達が速い
  • カプランの観点「学校が職業スキルをほとんど教えない中で人はいかにして職業的熟達を得るのか—カーネギーホールへの道と同じく、練習によってである」を支持する
  • 「Do Ten Times as Much（10倍やれ）」を、不快だが効果的なアドバイスとして挙げる

(2026/05/14)

アジャイルの
「ベストプラクティス」と「アンチパターン」〜その裏側にある原則を読み解く〜

• アジャイルの
「ベストプラクティス」と「アンチパターン」〜その裏側にある原則を読み解く〜 | Ryuzee.com

(2026/05/14)

プログラマーの方々の全体的な傾向として自分が感心しているのは、プログラミングによってプログラマー...

プログラマーの方々の全体的な傾向として自分が感心しているのは、プログラミングによってプログラマーという職能が代替されそうな時に、淘汰されるのであれば仕方あるまい、とそそくさと諦めているところ

共感はしないけど、（ハッカーに比較的多い）リバタリアン／新自由主義者として筋が通ってる

もう少し実存的危機に陥ったり、お気持ち表明してみたり、アーツ・アンド・クラフツ運動みたいな言説をしたり、一部の士業のようにレントシーキングしたって人間臭くていいのに

@_baku89

MEMO:

• エンジニアの仕事は突き詰めて言えば「人間の仕事を無くすこと」なので、自分の仕事が無くなるのは当然の帰結だし望むところでもある
• 結果、生業が無くなる・失業するというリスクはあるが、それがどうしたという感覚の方が強い
• プログラマとしての職を失う程度のことで実存的危機に陥る感覚は理解不能なところがある
• AIに仕事が奪われるならAIに指示する側に回ればええやんけという楽観主義もある

(2026/05/14)

第910回　GPGより簡単でZIPより安全。シンプルな暗号化ツール「age」を試す

• 第910回　GPGより簡単でZIPより安全。シンプルな暗号化ツール「age」を試す | gihyo.jp

ageはコマンドラインで簡単に使える暗号化ツールです。GitHubのREADMEによると「age is a simple, modern and secure file encryption tool, format, and Go library. It features small explicit keys, post-quantum support, no config options, and UNIX-style composability. （⁠意訳: ageはシンプルでモダンかつ安全なファイル暗号化ツールであり、暗号化ファイルのフォーマットであり、そしてGoライブラリでもあります。 短く明示的な鍵、ポスト量子暗号への対応、設定不要のシンプルな設計、そしてUnixライクのツールらしく、パイプなどで他のコマンドと組み合わせやすいことを特徴としています⁠）⁠」とのことです。

ageの最大の特徴は、暗号化ツールとしてのシンプルさです。GPGのようにキーリングや信頼度管理、キーサイン、鍵サーバーなどを含む大きな仕組みではなく、「⁠指定した相手の鍵でファイルを暗号化し、対応する秘密鍵で復号する」という用途に絞られています。そのため使い方が分かりやすく、スクリプトにも組み込みやすくなっています。

たとえばバックアップファイルを暗号化して、ファイルサーバーやオブジェクトストレージに保存するといった用途では、サーバー側には暗号化用の公開鍵だけを置き[1]、復号用の秘密鍵は別の安全な場所に保管できます。これによりバックアップ処理を自動化しつつ、サーバーや保存先から平文のデータが漏れるリスクを抑えられます。

(2026/05/14)

国内最大級の転職サイト「doda」は、15年以上稼働するシステムの技術的負債をどう乗り越えたのか？

• 国内最大級の転職サイト「doda」は、15年以上稼働するシステムの技術的負債をどう乗り越えたのか？ (1/3)|CodeZine（コードジン）

要約:

■ 1. インタビュー対象者の概要

• パーソルキャリアに2022年7月入社、エンジニア歴は約8年
• 入社後は機能追加チームを経て、自ら希望してdodaリビルドプロジェクトに参画
• 現在はシステムアーキテクトとして、求人領域のチームリーダーを務めマイクロサービス化を推進

■ 2. dodaシステムが抱えていた課題

• システムは15年以上稼働する大規模な構成
• 技術的負債と開発効率の課題:
  • フロントエンドとバックエンドのソースが混在し、軽微な改修でも影響範囲が広く開発速度が低下
  • フロントエンドにJakarta Pages（JSP）を採用していたため、バックエンドとの密結合が発生
  • 外部ベンダーへの開発委託期間（6〜7年前まで）により、保守性を考慮しない設計になっていた
• ユーザー体験の課題:
  • Webサイトの描画速度が遅く、サイト内パーツの動作も緩慢
  • Googleの「Core Web Vitals」の数値が競合他社と比較して低水準
• 以上の背景から2020年以降、内製化の方向性に転換

■ 3. dodaリビルドプロジェクト

• 目的: フロントエンドとバックエンドを分離し、JSPからReactへ置き換え
• チーム体制の改善:
  • 当初はフロントエンドとバックエンドでチームが分離しており、APIインタフェースの不整合による手戻りが頻発
  • 担当者の提案により画面ごとに両領域のメンバーを混在させたチーム編成を導入
  • 再編成によりコミュニケーションロスと手戻りが改善
• ドキュメント不足への対応:
  • 設計書ではなくソースコードを「正」として、リバースエンジニアリングで仕様を起こした
  • プルリクエストによるレビューでダブルチェック体制を整備
  • 完璧を目指さず90%を目標とし、問題発生時に旧アーキテクチャへ即時ロールバックできる体制を構築
• 改善結果:
  • Core Web Vitalsの3指標すべてで網羅率80%超を達成（目標水準は70%以上）
  • モダンなアーキテクチャへの移行によりリリース頻度が増加し、開発効率が向上
  • バックエンドにクリーンアーキテクチャを採用し、外部依存を排除することで保守性を向上

■ 4. dodaマイクロサービス化プロジェクト

• 背景と課題:
  • doda周辺システムがすべて同一の巨大な共有データベースを参照しており、変更時の影響範囲が広い
  • 影響範囲の調査だけで時間を要し、開発速度の低下を招いていた
• プロジェクトの方針:
  • 各アプリケーション専用のデータベースを切り出し、アプリケーション単体でリリース可能な構成に変更
  • リビルドプロジェクトでフロントエンドの密結合を解消した後、共有データベースの密結合解消を目指す流れ
• マイクロサービスを選択した理由:
  • 規模の小さなアプリケーションではモノリス回帰の事例が増えているが、dodaほどの規模では各アプリケーションをスリム化する方が保守性と生産性の向上に有効と判断

■ 5. AI活用の取り組み

• 社内でClaude Codeを導入し、仕様調査・テスト・実装の各フェーズで活用
• 運用上の課題と対策:
  • 社内では1日のトークン使用量に上限があり、マイクロサービス化されていないコード量の多い部分では制限に達しやすい
  • CLAUDE.mdに情報を記述することでAIに方針を与え、迷走を防ぐ仕組みを導入
  • OSSのガードレールフレームワークを活用し、安全な生成AI利用を実現
• マイクロサービス化とAI活用の関係:
  • 細かいリリースを可能にするマイクロサービス化はAI活用の推進にも有効
  • AIを活用することで、仕様の要望を即座に動くものとして提示できるスピード感が実現可能になる見込み
• 将来構想:
  • AIエージェントを求人検索に活用し、ユーザーがチャットで話しかけるだけで個人の志向や将来像に合わせた求人を提案できるシステムを目指す

■ 6. 組織文化とリーダーシップ

• パーソルキャリアの組織風土:
  • 挑戦したいことに自ら手を挙げることで参画できる環境
  • 技術選定をボトムアップで進められる裁量の大きさがある
• リーダーシップのスタイル:
  • サーバントリーダーシップを意識し、メンバーが主体的に動ける環境づくりを優先
  • チーム内の心理的安全性の確保と情報共有の仕組み化を重視
  • 優秀なメンバーにはマイクロマネジメントよりも自律的に動ける環境が生産性向上につながると考える
• 今後のキャリア目標:
  • 傾聴スキルやサーバントリーダーシップに関する知識を習得し、マネジャーへのキャリアアップを目指す
  • 自らの組織像を描き、実現に向けたロードマップを引けるマネジャーを目指す
  • 生成AIを活用した開発手法の導入による生産性向上に継続して取り組む

(2026/05/13)

DBを使うGoのテストを速く・壊れにくくする

• DBを使うGoのテストを速く・壊れにくくする - enechain Tech Blog

要約:

■ 1. 概要

• DBを使うGoのテストを高速かつ壊れにくくするためのヘルパーパッケージの設計と実装を紹介する
• 当初はモックを使用していたが、メンテナンスコストの高さとテスト対象のズレが問題となった
• Testcontainersに移行したが、Dockerへの依存とコンテナ起動時間が課題となった
• 解決策として「1行呼ぶだけでマイグレーション済みの空のDBが手に入る」ヘルパーパッケージを整備した

■ 2. 設計の方針

• 提供する機能:
  • テストコードから1行呼ぶだけでマイグレーション済みの空のDBが使える
  • 実行環境を見てPostgreSQLのプロセス起動とTestcontainersを自動で切り替える
  • テストごとに独立したDBを高速に生成し、終わったら片付ける
• APIの設計:
  • pi.GetDatabase(t) を呼ぶだけで *sql.DB が得られる
  • t.Cleanup を内側で呼び、テスト終了時に接続のクローズとDBの削除を自動で行う
  • パッケージ内で1つのPostgreSQLインスタンスを共有し、各テストケースでDBを複製する

■ 3. テンプレートDBによる高速化

• マイグレーションをテストごとに実行するとスケールしないため、結果をキャッシュして再利用する
• PostgreSQLのテンプレートデータベース機能を利用する:
  • PostgreSQLの起動直後にマイグレーション済みのテンプレートDBを1つ作成する
  • テストごとに CREATE DATABASE <random_name> TEMPLATE <template_db> を発行する
  • ファイルレベルのコピーで済むため、マイグレーション実行より大幅に高速
• データベース名はランダムに生成し、t.Parallel() による並列テストでも各テストが独立したDBを持つ

■ 4. 環境差の吸収

• 実行環境に応じてPostgreSQLの起動方法を切り替える:
  • macOS: pg_ctl 経由でプロセスを起動し、一時ディレクトリにdataディレクトリを作成する
  • Debian / GitHub Actions: pg_createcluster を使用し、GitHub Actionsランナーでは sudo 経由で呼び出す
  • Dockerのみの環境: Testcontainersを使用し、pg_bigm 拡張を含むDockerfileを動的に生成してビルドする
• 環境の判定は pg_ctl や pg_createcluster のパスの存在確認、および RUNNER_ENVIRONMENT 環境変数で行う

■ 5. ハマりどころ

• panic時にPostgreSQLのプロセスが残る問題:
  • t.Parallel() で並列化したテストの1つがpanicすると、TestMainのdeferが呼ばれない
  • 起動したPostgreSQLが別のプロセスグループになるためゾンビ化する
  • 緩和策として、テストの失敗を検知した場合に他のテストの完了を30秒待ってからPostgreSQLを停止する
  • GitHub Actionsではrunnerごと使い捨てられるためこの処理は走らせない
• t.Failed() がpanic時にfalseを返す問題:
  • Go標準ライブラリのバグ（golang/go#49929）として報告されている
  • ワークアラウンドとして、reflect で testing.common の finished フィールドを参照しpanicを判定する
• DBの起動完了を観測する必要がある問題:
  • プロセス起動の場合: 確保したポートへの接続と sql.DB.Ping() の成功まで待機する
  • コンテナ起動の場合: TestcontainersのWaitStrategyを使用して待機する

■ 6. さらなる高速化: プロセスの再利用

• Goのテストはパッケージ単位で別プロセスとして実行されるため、パッケージごとにPostgreSQLの初期化・起動が行われる
• GitHub Actions上ではPostgreSQLを一度起動して使い回す最適化を実施:
  • テスト実行前に専用コマンドでPostgreSQLを起動し、テンプレートDBまで作成する
  • プロセス情報をJSONファイルに書き出し、そのパスを環境変数で各テストプロセスに伝える
  • テスト側は環境変数を見て既存のプロセスを再利用する
  • teardownは意図的に行わない（runnerがジョブ終了時に破棄されるため）
• 再利用による効果:
  • 通常の実行時間: 各パッケージ7〜8秒
  • 再利用時の実行時間: 各パッケージ247〜353ms（約3〜4%）

■ 7. 所感

• 良い点:
  • テストを書く側はDBの詳細を意識せずに済む
  • 手元とCIで同じ抽象化を共有しているため「CIでだけ落ちる」が起きにくい
  • 並列テストでもデータが汚染されない
  • flakyテストが起きづらくなった
• 残っている課題:
  • t.Failed() のワークアラウンドがreflectに依存しており、Go側の修正で壊れる可能性がある
  • ゾンビプロセスが稀に発生することがある
  • 実DBを使う以上、テストに必要な事前データは自分で用意しなければならない

(2026/05/13)

ベストプラクティスもアンチパターンも、それ自体は何も解決しない（かも）

• ベストプラクティスもアンチパターンも、それ自体は何も解決しない（かも）

要約:

■ 1. 他社事例・ベストプラクティス・アンチパターンへの依存の問題

• 勉強会等での相談に「他社の事例」「ベストプラクティス」「アンチパターン」を求める声が多い
• 他社事例を求める背景には「他社でうまくいった方法をそのまま流用したい」という思考がある
• 他社のベストプラクティスが自社のベストとは限らない
  • 業種、組織の規模、組織のルール、プロダクトの性質、ステークホルダー、チームのスキルは各社で異なる
  • 大企業では部門単位でも文脈が異なる
• 文脈が違えば答えは変わるため、表面だけの模倣は意味をなさない
• 単純な模倣は自分の頭で考えることの放棄であり、効果を生まない

■ 2. ベストプラクティスの形骸化リスク（ベロシティの例）

• 「みんなやっているから」「うまくいくらしいから」という理由でプラクティスを導入しても、その原理を理解していなければ形骸化や悪用が起きる
• スクラムにおけるベロシティの本来の位置づけ:
  • スクラムは経験主義（透明性・検査・適応）を重視する
  • ベロシティはチームが自分たちの力量を見える化し、改善や予測に活用するためのツール
• 原則を理解しないことで生じる問題:
  • ベロシティが報告対象・約束の対象になる
  • 外部からベロシティの向上を要求される
  • 他チームとの比較に使われる

■ 3. アンチパターン回避だけでは不十分（兼務の例）

• 「兼務」はプロダクト開発における定番のアンチパターンであるが、「避けろ」と言うだけでは解決しない
• 兼務が問題とされる根拠:
  • 集中の阻害: 難しい仕事は細切れの時間では遂行できない
  • フローへの悪影響: 複数業務の並行は仕掛中の時間を伸ばし、価値を生まない期間が増える
• 原則を理解していれば、制約の中でも代替策を検討できる:
  • 時間ではなく期間で業務を割り当てる（例: 今週はAプロダクト、来週はBプロダクト）
  • 専任メンバーと限定的関与のメンバーを区別する
  • コアタイム制による集中時間の確保
  • 並行して兼務解消に向けた組織的な取り組みを行う
• アンチパターンを回避してもプロダクトが失敗することはあり、アンチパターンを踏んでも成功することもある

■ 4. 根底にある原則の理解が本質

• 事例・ベストプラクティス・アンチパターンはいずれも原則の表現形態の一つに過ぎない
• 各プラクティスやアンチパターンの背後には必ず原則が存在する:
  • ベロシティの背景: 経験主義（透明性・検査・適応）
  • 兼務の背景: 集中とフローの原則
  • ステークホルダーの言いなりになるアンチパターンの背景: 価値駆動と顧客との協調
• 原則を押さえることで応用が効く:
  • 「集中とフローを大事にする」という原則を理解していれば、兼務・長すぎる会議・割り込みタスクの常態化を同一の枠組みで捉えて対処できる
• 原則を理解せずプラクティスのみを覚えると「うちには合わなかった」で終わる
• 事例・ベストプラクティス・アンチパターンを探す前に、どの原則を満たそうとしているかを考えることが重要

■ 5. プラクティスは仮説として扱う

• プラクティスは「仮説」として扱うことが健全
  • 導入し、観察し、効果がなければやめる
  • 違和感があれば元に戻すか別の方法を試す
• 短いサイクルで検査と適応を繰り返せば、誤りがあっても取り戻せる
• 「後戻りできない」と思い込んで継続することのほうがダメージが大きい
• 生成AI関連のプラクティスにも同様のことが当てはまる

(2026/05/12)

バリデーションはドメインオブジェクトとAPIスキーマ定義のどっちに書くべきか

• バリデーションはドメインオブジェクトとAPIスキーマ定義のどっちに書くべきか - pospomeのプログラミング日記

要約:

■ 1. バリデーション定義の重複問題

• バックエンドサーバのバリデーション定義が、ドメインオブジェクトとAPIスキーマ定義の両方で重複して定義される問題がある
• 重複を避けるため片方に集約したいが、それぞれの選択肢に課題が生じる

■ 2. 実装パターン

• ドメインオブジェクトに全部実装するパターン:
  • リポジトリパターンによってデータ登録・更新・削除が保証されるため、いつでも・どこでもバリデーションが適用可能
  • バッチ処理でもドメインオブジェクトを生成することでバリデーションが機能する
  • コードで記述するためプログラマブルなバリデーションが可能で、複雑な条件分岐にも対応できる
• APIスキーマ定義に全部実装するパターン:
  • APIが期待する入力値の制約がスキーマ定義から一目で把握できる
  • マイクロサービス環境やAIによるAPI実装時の利便性が高い
  • 課題:
  • 複雑な条件分岐（有料会員のみのデータ登録制限など）は実装できない場合があり、結局ドメインオブジェクトにもバリデーションの実装が必要になる可能性がある
  • API経由の入力にしかバリデーションが効かないため、バッチ処理での直接DB登録にはバリデーションが機能しない
  • バリデーションエラーメッセージの柔軟な定義に制限がある場合がある（CEL式によるカスタムルールで日本語メッセージ等の対応は可能だが、手間がかかる）
• 両方に定義するパターン:
  • 2重管理となりメンテナンスコストが高く、ルール変更時に両方の修正が必要
  • 亜種として「APIスキーマ定義のコメントにバリデーション定義を記述するだけ（実際にはバリデーションしない）」パターンも存在するが、機械的な検証ができないため複雑さが増す可能性がある

■ 3. 推奨パターンと考え方

• APIスキーマ定義によるバリデーションを推奨する（APIスキーマ定義で実現できないバリデーションはドメインオブジェクトに実装する）
• 「API経由の入力にしかバリデーションが効かない」問題への対応方針:
  • 入力をAPI経由のみに制限する
  • バッチ処理でのDB登録もAPIを経由し、直接DBに登録しない
  • バッチ処理の要件にマッチしない場合は専用エンドポイントを作成・改修する
• APIに入力を集約することで得られる追加メリット:
  • バックエンドサーバの正常な挙動の保証
  • Rate Limitの適用
  • エンドポイントの認証・認可
  • ログ（監査ログ、アクセスログ、エラーログ）
  • アラート・モニタリング
• データの入り口を一箇所に絞ることで可用性や信頼性が向上し、大規模サービスほどトラブル防止の恩恵が大きい
• Amazonの「ベゾスの掟」もこの考え方と同様の方針であり、大規模開発組織やマイクロサービスの安全なスケールに寄与する
• この推奨は、規模が大きくトラフィックが多い、開発組織が大きい、マイクロサービスを採用しているサービスを前提とした場合に特に有効

(2026/05/12)

JavaScriptランタイムのBun、Claudeを使って開発言語をZigからRustへ移行中

• JavaScriptランタイムのBun、Claudeを使って開発言語をZigからRustへ移行中 － Publickey

要約:

■ 1. 概要

• JavaScriptランタイムBunの作者Jarred Sumner氏が、開発言語をZigからRustへ移行中
• 移行作業にはClaudeを活用し、約1週間でほぼ全工程が完了
• 2026年5月11日時点で、次のバージョンがZig言語での最後のBunになる可能性がある
• Windows、macOS、Linuxでのテストにすでに合格

■ 2. 移行の理由

• メモリ安全性の確保:
  • メモリリーク、クラッシュ、安定性の問題の修正に多大な時間を要することへの疲弊が主因
  • Rustはメモリ安全（Memory Safe）なソフトウェアを実現する仕組みを言語レベルで備える
  • 米国政府も2024年にRust等のメモリ安全な言語の利用を推奨

■ 3. 移行の経緯

• 2026年5月4日:
  • SumnerがGitHubのBunリポジトリに「Zig → Rust porting guide」のMarkdownファイルを作成
  • 同ファイルはClaudeへの変換指示として機能し、これを機にClaude主導の移行作業が開始
  • BunはAnthropicに買収済み（2025年12月）
  • この時点でSumner氏は「実験的な試みであり、移行を決定したわけではない」と発言
• 2026年5月7日:
  • Rust移植版はほぼ機能していない状態であり、出荷できる段階ではないと報告
  • Claude Codeによる作業は継続中
• 2026年5月8日:
  • ローカル環境でのテストパス率に前向きな手応えを感じていると言及
  • CIでのテスト実施前であり、性能についての評価は時期尚早と付言
• 2026年5月9日:
  • Linux x64 glibc環境においてRust移植版が99.8%のテストにパス
  • この段階からRustへの本格移行が真剣に検討されるようになった
• 2026年5月11日:
  • 次のBunバージョンがZig言語での最後のリリースになる可能性をSumner氏が示唆
  • 移行過程についてのブログ執筆を予定しているとポスト

(2026/05/12)

AIの電力限界に挑む——Extropicが狙う「熱力学コンピューティング」とは

• AIの電力限界に挑む——Extropicが狙う「熱力学コンピューティング」とは｜Neo Tech World

要約:

■ 1. 背景: AIの電力・コスト問題

• 生成AIは学習・推論において膨大な計算を要し、中心にあるGPUは高性能だが消費電力も大きい
• AI業界の課題は「モデルの高性能化」だけでなく、電力と設備コストへと移ってきている
• 高性能GPUを大量に並べる方式では、電力・冷却・設置面積・設備投資の負担が増大する
• 現在の機械学習はGPUに合わせて進化してきた仕組みであり、計算需要は決定論的処理から確率的処理へ、性能制約からエネルギー制約へと移行しつつある

■ 2. Extropicの概要

• 2022年創業、2023年12月に1410万ドルのシード資金を調達
• GPUの改良ではなく、生成AIに必要な計算そのものを作り直す「熱力学コンピューティング」を提唱
• 通常のデジタル計算機が0か1を厳密に固定して計算するのに対し、回路の揺らぎを計算資源として利用する
• ハード・アルゴリズム・ソフトウェアを並行して外部に示しており、単なる研究アイデアの段階を超えている

■ 3. 中核技術: p-bitと確率回路

• p-bit（確率ビット）:
  • 普通のビットが「0か1かが決まったスイッチ」であるのに対し、「0と1の間を行き来しながら、どちらに寄りやすいかを調整できるスイッチ」
  • 従来の計算機がノイズを減らそうとしてきたのに対し、揺らぎを計算資源として利用する点が異なる
• 確率回路の種類:
  • PBIT: 0か1を指定した確率で出し分ける最も基本的な回路（重み付きコインに相当）
  • PDIT: 複数の離散的な候補から確率に応じて選ぶ回路（重み付きサイコロに相当）
  • PMODE: 連続的な値をとるガウス分布（山形の分布）を表現する回路
  • PMOG: 山が複数ある複雑な分布を扱う回路
• 確率的な選択をデジタル計算であとから作るのではなく、回路そのものの動きとして直接実現することを目指す

■ 4. ハードウェアロードマップ

• X0:
  • 2025年Q1のシリコン試作
  • 単純な確率分布からサンプルを生成する高効率な確率回路の製造可能性を実証
• XTR-0:
  • 2025年Q3の実験・研究プラットフォーム
  • Extropicのチップと従来型プロセッサを低遅延で接続し、超高効率なAIアルゴリズムを開発する基盤
• Z1:
  • 2026年early access予定の初の量産規模チップ
  • 1チップあたり数十万、1カードあたり数百万の確率回路を搭載
  • 標準的なCMOSプロセスでの量産が可能

■ 5. ソフトウェア・アルゴリズム基盤

• TSU（Thermodynamic Sampling Unit）:
  • 複雑な確率分布から直接サンプルを出すことを目的とした装置
  • 従来は大量の行列計算で確率表を作ってからサンプリングするのに対し、確率的な選択をハードウェアの中心に置く
• DTM:
  • 拡散モデルに近い発想で、ノイズから少しずつ意味のあるデータを取り出す生成方式
  • 普通の拡散モデルがGPU上の大量のデジタル計算と疑似乱数に頼るのに対し、TSUの確率的性質を前提に設計
• THRML:
  • 熱力学コンピューティング向けアルゴリズムをGPUなど既存環境上で試すためのオープンソース開発基盤
  • GitHubで公開済みであり、外部から触れられる状態にある

■ 6. 技術的ブレークスルー

• TSUによるサンプリング装置の発想:
  • 確率的な選択をハードウェアの中心に置く設計思想
  • 従来の行列計算によるサンプリングとは異なるアプローチを取る
• 量産を見据えた実装可能性:
  • p-bitをトランジスタだけで構成でき、小さく・省エネで・既存回路と統合しやすい
  • 標準的なCMOSプロセスでの量産が可能であり、研究室のデモにとどまらない
• ハードとアルゴリズムの一体設計:
  • TSU・DTM・THRMLをセットで開発・公開
  • 小規模生成AIベンチマークにおいて、TSU上のDTMがGPUベース手法より最大約10,000倍高いエネルギー効率になりうるとの分析結果がある（ただし特定条件下での分析であり、大規模商用基盤モデルを実運用で置き換えた実証ではない）

■ 7. 実用化に向けた課題

• スケールの課題:
  • 小規模での成果が大規模システムへの拡張時に維持できるかどうかが不明
  • 量産時の歩留まり（正常動作するチップの割合）・配線・発熱・制御の複雑さが障壁となる
• ソフトウェアエコシステムとの接続:
  • 現在のAI開発はCUDA等GPU前提の巨大なエコシステム（開発ツール・ライブラリ・人材・運用ノウハウ）上で動作する
  • THRMLの公開はこの問題への対策だが、まだ出発点にすぎない
  • 「使ってみたい技術」から「導入できる技術」への転換が必要
• 用途の見極め:
  • あらゆる計算でCPUやGPUを置き換えるものではなく、確率分布を扱う処理・サンプリングが重い処理・生成や推定の処理との相性が良いと考えられる
  • 気象など複雑系を扱う分野への応用可能性もある
  • 最初の勝ち筋は「特定の確率的ワークロードで圧倒的に省エネ」という狭く深い突破口になる公算が大きい

■ 8. 確定点と未確定点の整理

• 確定している事実:
  • 2025年10月に熱力学コンピューティングの全体像（TSU・DTM・THRML・XTR-0）を公表
  • X0（2025年Q1シリコン試作）・XTR-0（実験プラットフォーム）・Z1（2026年early access）というロードマップを明示
  • THRMLをGitHubで公開し、外部から利用可能な状態にある
  • 2023年のシード調達以降、ハード・アルゴリズム・ソフトウェアを並行して外部に示している
• 未確定な点:
  • 大規模商用AIの現場でGPUの代替・補完として機能できるかどうか
  • 小規模ベンチマークでの約10,000倍のエネルギー効率向上が実運用規模に適用できるかどうか
  • Z1のearly access（2026年）における量産出荷完了や大規模顧客への本格導入の実現可否
• 現時点でのExtropicの位置付け: 技術的な成立可能性と初期ロードマップを市場に示した段階であり、商用スケールで勝ち筋が実証された段階ではない

■ 9. 今後の焦点

• XTR-0やTSUの考え方が試作にとどまらず、大きな規模へ拡張できるかどうか
• THRMLを起点に外部の研究者や開発者が参加し、技術の土台が広がるかどうか
• 画像生成・気象・科学計算のような確率的処理が重い分野で、最初の具体的な実用価値を示せるかどうか
• これら三点が実現すれば「面白い技術」から「業界の現実的な選択肢」へ進む可能性があり、実現しなければ高く評価されながらも広くは採用されない技術にとどまる

(2026/05/11)

I returned to AWS - and was reminded HARD why I left.

• A blog about various stuff.: I returned to AWS - and was reminded HARD why I left.

要約:

■ 1. AWSへの初期支持と熱狂

• クラウドコンピューティング登場当初からAWSの積極的な支持者であった
• メルボルンで最初のAWSイベントを主催し、AWS黎明期から深く関与した
• 約15年間にわたり熱烈な支持者であり続けた

■ 2. 不満の蓄積による支持の喪失

• クライアントライブラリの未整備:
  • 創業から6年間、Pythonなどのクライアントライブラリ整備をコミュニティに委託し続けた
• Python移行の遅延:
  • Python 2からPython 3への移行が著しく遅延した
• DynamoDBの問題:
  • 1日で75ドルの請求が発生した
  • 設計・使い勝手の両面で欠陥があると評価する
• データ転送コストの高さ:
  • 当初1ギガバイトあたり20セント、現在でも9セントと依然として高額である
• 不透明な課金体系:
  • 内部データ移動に対して二重・三重請求が発生する
  • 専門知識なしでは回避困難なコスト上の落とし穴が多数存在する
• IAM（認証・アクセス管理）の複雑性:
  • 過度に複雑な設計であり、習得・運用コストが高い
• AWS全体の複雑性:
  • 高額な専門家チームの雇用が必要である
  • 「自前運用は複雑」を利用理由とする主張が、AWS自体の高い複雑性と矛盾している
• AWS Lambdaの問題:
  • 起動時間の遅さと開発複雑性が高い
  • 独自Webサーバーと比較した実質的なメリットが存在しない
  • ベンダーロックインが深刻であり、移行コストが大きい
• オープンソースプロジェクトへの侵害:
  • Elasticsearch、Redis、MongoDBに対抗し、OpenSearch、Valkey、DocumentDBを展開した
  • コミュニティが構築した市場を収奪し、SSPL・Elastic Licenseなど防衛的ライセンスの採用を招いた

■ 3. AWSからの離脱

• 不満の蓄積により、支持者から批判者へと転換した
• 大部分のサービスをAWSから移行し、アカウントを閉鎖した
• Route53（ドメイン管理）、S3（バックアップ）、WorkMail（業務メール）のみ継続利用した

■ 4. AWSへの再訪と目的

• 検証目的1: AWS Bedrock上でのClaude/Anthropicの動作確認
  • Anthropicの直接サブスクリプションと比較して低速かつ大幅に高額であると判明した
• 検証目的2: 高性能マシン（192コア・1TB RAM）でのコードベンチマーク

■ 5. アカウント停止インシデント

• 長期間休眠状態のアカウントで高額インスタンスを稼働させたことがセキュリティアラームを誘発した
• AWSによりアカウントが停止・制限された
• 停止による影響:
  • WorkMail（主要業務メールアドレス）が機能停止し、送受信が不可能となった
  • 予定していたベンチマークテストが中断された

■ 6. サポート対応の問題

• メールでの問い合わせに3日間無応答であった
• フォーラム経由でチャットサポートの利用を案内された
• 約30分の待機後にチャット対応を受けた
• パスワード変更・アクセストークン削除・請求内容確認など要求事項をすべて完了した
• 担当者は内部チームへのエスカレーションを確約した
• 8時間後のフォローアップに対して「待て」との回答のみが得られた
• 4日が経過した時点でもアカウント停止状態が継続していた

■ 7. 結論

• 今回の経験によりAWSを離脱した判断の正しさが再確認された
• WorkMailからの移行とRoute53からのドメイン移管を計画している
• 残存サービスへの依存を過去の誤った判断として反省している

(2026/05/11)

coderamp-labs/pad.ws: Whiteboard as an IDE, draw and code in your browser

• coderamp-labs/pad.ws: Whiteboard as an IDE, draw and code in your browser

(2026/05/10)

お前のAIスロップなんざ誰も読みたくねえよ（送りつけてくんな）

• お前のAIスロップなんざ誰も読みたくねえよ（送りつけてくんな） » p2ptk[.]org

要約:

■ 1. AIチャットログの無断共有

• 自分の夢がいかに興味深くとも他者には退屈であるのと同様に、AIとの会話を他者が読みたいと思い込んではならない
• 同意を明確に得ていない状態でAIチャットのログを友人に転送することは友情への甘えであり、チャットボットの回答が冗長であることを考えればその迷惑の度合いはさらに増す
• 見知らぬ相手とのソーシャルメディア上の会話にチャットボットを呼び出す行為は、公衆の面前での自慰行為に等しい

■ 2. AI生成の批評を著者へ送りつける行為

• 他者の文章を読み、チャットボットにその批評を生成させ、著者本人に無断で送りつける行為は、同意なくチャットボットを対話に割り込ませることよりもさらに悪質な類型に属する
• 主題の理解と批評生成:
  • AI企業自身がAI出力には誤りが多く、人間による監視が必要であると認めている
  • 主題を十分に理解していない者がAIに反論を生成させても、理解不足という事実は何も変わらない
  • AI出力は、その問題を理解した人間が一行ごとに検証するまで確率論的なワードサラダに過ぎない

■ 3. AI出力の評価責任と強要される労働

• AIに反論を生成させるプロンプトを入力しても、入力した者に理解がもたらされることはない
• AI出力の評価資格:
  • 元の著者の主張に対するAI出力を評価できるのは、そのAI出力を送りつけられた著者本人のみである
  • 見知らぬ相手に未検証のAI出力を送りつける行為は対話ではなく、他者へのタダ働きの強要である
  • 受け取った相手はAIの出力を検証するために貴重な時間を割く義務を持たない
• AI企業自身がAI出力の監視は価値ある労働であると認めており、コストゼロで生成できる文章を他者が採点する時間があるとは限らない

■ 4. AI要約による生産性向上の幻想

• 理解していない主題をAIに要約させることで生産性が上がるという考えには致命的な欠陥がある
• 主題を理解していない者は、その要約を評価する資格を持たない
• 知的参加の代替不可能性:
  • ある主題を学び、新たな知見を加えたり欠陥を指摘したりできる水準の理解に達することの代替物は存在しない
  • チャットボットに自らの代わりに議論へ参加させても、自らに洞察が生まれることはない
  • それは自らの頭と経験によって参加の努力を実際に重ねてきた人々へのおぞましい押し付けである

(2026/05/10)

CPUは4ビットから始まって64ビットまで来ましたが、もうすぐ128ビットとかになりますか？に対する山口...

• CPUは4ビットから始まって64ビットまで来ましたが、もうすぐ128ビットとかになりますか？に対する山口 浩さんの回答 - Quora

非常に鋭いご質問です。30年以上も「64」という数字に留まっていると、技術が停滞しているように感じるのも無理はありません。

しかし、結論から申し上げますと、「一般的なコンピュータにとって、128ビット化するメリットが現在はほとんどない」というのが大きな理由です。

なぜ128ビット化が進まないのか、3つのポイントで整理して解説します。

■ 1. 「扱えるメモリ量」がすでに十分すぎる

CPUのビット数は、一度に扱えるデータの幅だけでなく、「認識できるメモリの住所（アドレス空間）」の広さを決めます。

• 32ビット: 最大 4GB まで（今のスマホやPCでは足りません）
• 64ビット: 最大 1,600万TB（テラバイト） まで

現在のスーパーコンピュータや巨大なサーバーでも、数TBのメモリがあれば十分足ります。1,600万TBを使い切るような状況は、現在の物理的なハードウェアの限界をはるかに超えており、128ビットにしてさらに住所を増やす必要性がまだ来ていないのです。

■ 2. 計算精度の問題

「128ビットになれば計算が速くなる」と思われがちですが、実はそうとも限りません。

多くの事務作業やネット閲覧、あるいはゲームの処理において、64ビットの計算精度で十分すぎるほど正確です。もし128ビットにすると、1回の計算で扱うデータ量が2倍になり、逆に消費電力が増えたり、キャッシュメモリを圧迫して速度が落ちたりするというデメリットの方が上回ってしまいます。

■ 3. 実は「部分的に」128ビット化は進んでいる

「CPU全体」を128ビットにする必要はありませんが、特定の計算を高速化するために、「データを通る道（バス幅）」や「特定の計算ユニット」はすでに128ビットや256ビット、あるいは512ビットに拡張されています。

• 画像処理やAI計算: GPU（画像処理プロセッサ）などでは、一度に大量のデータを処理するために非常に広いビット幅が使われています。
• SIMD命令: 最近のCPUには、128ビット分のデータを一気に計算する専用の仕組み（IntelのAVXなど）がすでに組み込まれています。

■ まとめ

現在のコンピュータ設計において、64ビットは「広大な土地（メモリ空間）と、十分な計算精度」を兼ね備えた、非常にバランスの良い「黄金比」のような状態にあります。

将来、私たちがテラバイトではなく「ゼタバイト」級のメモリを個人で扱うような時代が来れば、128ビットCPUが標準になる日が来るかもしれませんね。

ちなみに、1990年代に64ビットCPU（MIPS R4000など）が登場した当時の衝撃を覚えている世代からすると、今の進化の方向性は「幅」よりも「効率や並列処理」に向かっているのが面白いところです。

(2026/05/10)

はてな、約11億円の資金流出で特別調査委員会を設置　外部の専門家で構成

• はてな、約11億円の資金流出で特別調査委員会を設置　外部の専門家で構成 - ITmedia NEWS

インターネット関連事業を手掛けるはてな（京都市中京区）は5月7日、不正な送金指示によって約11億円の資金が銀行口座から流出した件で、外部の専門家で構成する特別調査委員会を設置すると発表した。同日行われた取締役会で決議した。

特別調査委員会は、田辺総合法律事務所の中西和幸さんら、弁護士や公認会計士、公認不正検査士で構成。事実関係の解明および原因の究明、再発防止策の策定などを行う。

はてなは調査に全面協力し、調査報告書を受け取り次第、速やかに開示する考え。「調査の独立性、客観性を高め、ステークホルダーに対する説明責任を果たすことが不可欠と判断した」としている。

はてなは、4月24日に約11億円の資金が銀行口座から流出したと公表。21日に取引先銀行から不審な送金が行われていると連絡があり、確認したところ悪意ある第三者から虚偽の送金指示により、20日と21日にある従業員のアカウントから銀行預金を外部の口座へ送金していたことが分かった。

MEMO:

• 従業員の独断で11億も送金できた体制の謎が明らかになるのだろうか

(2026/05/09)

Open question for the reason why other maintainers were removed from the org（fsnotify Issue #757）

• Open question for the reason why other maintainers were removed from the org · Issue #757 · fsnotify/fsnotify

要約:

■ 1. 概要

• GitHubリポジトリfsnotifyのIssue #757における、メンテナー権限の剥奪をめぐる議論の整理
• 発端はymotongpooによる「他のメンテナーがorgから外された理由の説明を求める」問題提起
• 議論はarp242・mattn双方の主張の対立を軸に展開し、複数の匿名コメントによる事実確認を含む

■ 2. 登場人物

• ymotongpoo: Google社員、Issue開設者、説明を求める立場
• arp242 (Martin Tournoij): fsnotifyの実質メンテナー（178コミット）、権限整理を実施した当事者
• mattn: 日本のGoエンジニア（15コミット）、権限を剥奪された当事者
• umlx5h: 第三者として事実確認を行う

■ 3. 権限整理の経緯（arp242の主張）

• 権限整理の背景:
  • 権限を持つ関係者の多くは「昔PRを出したら全員にcommit権限を渡す」という過去の慣行（Issue #126）に基づくものであり実質的なメンテナーではなかった
  • 外されたのはコミット数が19・8・5・1の貢献者たちであり、Kubernetesが依存するライブラリでコミット数の少ないユーザーがrelease権限を持つことの危険性が指摘された
• PR品質の問題:
  • mattn・shogoのPRはレビューなしで数分以内にrubber-stamp approveされてマージされた
  • 変更の品質が低く（「AI slop」と表現）修正作業に前日の午前中をほぼすべて費やした
  • fsnotifyは全プラットフォームで一貫した動作が求められる難しいプロジェクトでありgo testを走らせるだけでは正しさを確認できない
• FUNDING.ymlの問題:
  • mattnが5コミットのみの状態で自身をFUNDING.ymlに追加した
  • mattnはthanks.devから実質的な作業を行う前に過去複数回資金を引き出していた背景がある

■ 4. Twitterで拡散した誤情報への反論（arp242）

• 「以前fsnotifyが維持不能になりメンテナーを募集した」という主張はrepositoryがarchiveされていた事実の誤認であり自分がNathanにメールして引き継いだ
• 「original authorまで外した」という主張に対し、Nathanは自らorgを離れており「安心してfsnotifyから離れられる」というメールを受け取っている
• コミットログは隠すものではなくgit logの出力（178コミット等）を公開した

■ 5. mattnの反論と説明

• 誤認の謝罪:
  • howeyc/nathanyが今回外されたと誤認していた点を謝罪
• 活動実績の説明:
  • Issue #735（「1年以上releaseがなくautomated dependency scannerに『unmaintained』と判定される」）を受け、半年間動きのなかったrepoを確認を待たずに整備した
  • 2026年4月21日〜5月4日の間に11本のPR（バグ修正・テスト安定化・toolchain更新など）をマージしv1.10.0とv1.10.1をリリースした
• FUNDING.ymlについて:
  • メンテナーとしての認識の下でコミットした
  • 事前確認なしにmainに直接コミットしたのは判断ミスだったと認める
• thanks.devについて:
  • 2023年頃にfsnotifyのメンテナーとして登録されていた
  • 現在はorgメンバーでなくなったためダッシュボードからfsnotifyが消えており詳細を確認できないが一定の金額を受け取っていた可能性は否定しない
  • 調査の上判明すれば公開すると述べる
• PR #756の評価について:
  • 「AI slopのrollback」という評価は実際のdiffと一致しない
  • バグ修正（#736等）はmainに残っており#756で戻されたのはリネームや再構成が中心
  • Windowsのドキュメントについては、MicrosoftおよびJim Beveridgeの文書を根拠に記述したもの
• gofsnotify/fsnotifyについて:
  • orgへのアクセスを失った後に作成した独立実装（forkではない）
  • 既存の代替として提示したものではない

■ 6. 主要な争点

• 権限整理の正当性:
  • arp242: 過去の慣行による残存権限を整理したに過ぎない
  • mattn: 1年間inactive後に活発に貢献した実績があった
• FUNDING.ymlの変更の適切性:
  • arp242: 実質作業前に資金を受け取っていた前歴があり不信感を持つのは自然
  • mattn: メンテナーとしての認識でコミットし事前確認しなかったのは判断ミスと認める
• Twitterでの情報発信の適切性:
  • arp242: issueではなくTwitterで批判するのは不適切
  • mattn: 一方的な状況になっているのを見て書かざるを得なかった、誤りは謝罪
• PR品質の評価:
  • arp242: AI生成を含む低品質で修正に相当な時間を要した
  • mattn: バグ修正の実績は具体的に示した、ドキュメントにも根拠がある

■ 7. 未解決事項

• arp242からmattnのコメントへの直接返答がない
• Issue自体はOpenのまま
• thanks.devの具体的な金額の開示がなされていない
• 権限整理の事前通知がなかった点についてarp242からの謝罪・説明がない
• fsnotifyの今後のガバナンス（単独メンテナー問題）への具体的な回答もない

論評:

■ 1. arp242の評価

• 正当性が高い点:
  • Issue #757での説明はcommit log公開・Nathanからの引き継ぎ経緯・thanks.devでの資金引き出し時系列など一次情報に基づく具体的かつ検証可能な根拠を伴っている
  • FUNDING.ymlの問題はmattn自身が「判断ミスだった」と認めており不信感は事後的に正当化された
  • Issue #126に基づく権限整理の説明はsupply chain securityの観点から筋が通っている
• 批判が残る点:
  • 権限剥奪を無言で行ったことが致命的な落ち度である
  • mattnが2週間で11本のPRをマージし2回のreleaseを切るという活発な貢献をしていた人物をissueひとつ立てることなく突然外したことはコミュニティの信頼という観点で拙かった
  • 「説明しなかったのは余計な炎上を避けたかったから」という釈明は結果として逆効果であったことを自ら認めている
  • Twitterで火がついてから初めてissueで説明するという順序はgovernanceとして最悪のパターンである
  • PR #756において技術的なバグ修正PRのスコープに実質的な権限整理が紐付いていた点は変更の透明性という観点で擁護しにくい
  • 「AI slop」という表現は感情的すぎる
  • 品質問題と権限剥奪を直接結びつけるならPRのレビューで具体的に指摘するのが先であり後から「低品質だった」と説明するのは後付けの印象が拭えない
• 総合評価:
  • 「何をしたか」は概ね正当化できるが「どうやったか」と「何を言ったか」に問題が集中している
  • 長年の貢献者としての正当性とコミュニティ運営者としての成熟度の間に大きな乖離がある

■ 2. mattnの評価

• 正当性が高い点:
  • Issue #735（1年以上releaseがなくdependency scannerにunmaintainedと判定される）という具体的なユーザーの声を受けて動いた動機は利用者目線のものとして理解できる
  • 11本のPR・2回のreleaseという活動量はissueで丁寧に説明されており単純な批判と噛み合っていない部分がある
  • Xでの誤情報（howeyc/nathanyが外されたという誤認）を率直に謝罪し自分のポストを削除した
  • arp242へのdownvoteをしないよう呼びかけ議論を建設的に収めようとする意志を示した
• 批判が残る点:
  • FUNDING.ymlの変更が最大の問題であり mattn自身が「判断ミスだった」と認めているがこれを「認めた」で済ませるのは軽すぎる
  • fsnotifyはKubernetesが依存するpublicなOSSであり既存のmaintainerであるarp242の明示的な合意を取らずに直接mainにpushしたことは手続きとして誤りである
  • 「メンテナーとして活動していた認識だったから」という説明は自分でその認識を設定して自分でその認識を根拠にした循環論法に近い
  • thanks.devの問題は深刻であり「作業をする前に資金を引き出していた可能性がある」ことを実質的に認めたがissue上でその後の開示はない
  • issueでの確認よりも先にXで動いたことが不必要な炎上を招いた
  • shogoが数分でrubber-stamp approveしてマージしたという事実があり レビュープロセスが形骸化していたことは否定できない
• 総合評価:
  • 「何をしようとしたか」は理解できるが「どういう順序でやったか」と「資金面の透明性」に問題が残る
  • thanks.devの件はissueでの謝罪後も追跡調査・公開がなされていないとすれば誠実さの評価を大きく下げる要因になる

■ 3. 両者の比較

• 技術的貢献の正当性:
  • arp242: 高い
  • mattn: 議論あり（短期・品質問題）
• 権限整理の根拠:
  • arp242: 筋が通る
  • mattn: 該当なし
• 手続きの適切さ:
  • arp242: 問題あり（無言で実行）
  • mattn: 問題あり（合意なしでFUNDING変更）
• 情報発信の適切さ:
  • arp242: 遅すぎた
  • mattn: 不正確かつ順序が逆
• 事後の説明:
  • arp242: 具体的・検証可能
  • mattn: 誠実だが資金面に不透明さが残る
• コミュニティへの影響:
  • arp242: 単独メンテナー問題を放置
  • mattn: 誤情報拡散・不必要な炎上

■ 4. 構造的な問題

• 両者の個別の行動を超えてこの件が示しているのはOSSガバナンスの設計不全である
• arp242が「権限整理は当然だ」と言えてしまうほどfsnotifyには明文化されたガバナンスルールが存在しなかった
• 誰がmaintainerでどういう条件でFUNDINGを変更できどういう手続きで権限を外すかが定義されていなければ今回のような衝突は構造的に起きうる
• 両者の行動を裁くより「こういう事態を防ぐにはどんなガバナンスが必要か」を問う方がOSSコミュニティにとって生産的な問いである

MEMO:

• 今のところmattn氏が形勢不利という感じか

(2026/05/08)

fsnotify の件、arp242 氏が一方的に悪者にされているのはかなり違和感

• fsnotify の件、arp242 氏が一方的に悪者にされているのはかなり違和感

fsnotify の maintainer 権限まわりで少し騒ぎになっている。

日本語圏では、mattn 氏が X で発信したこともあって、「arp242 氏が横暴に maintainer を外した」「有名 OSS を乗っ取った」「怖い」みたいな受け止め方がかなり広がっているように見える。

ただ、GitHub 上の issue や commit log、実際の contribution を見ると、この見方はかなり雑ではないかと思った。

少なくとも、公開情報を見る限り、arp242 氏が一方的に悪いという話には見えない。むしろ、実質的に長く fsnotify をメンテしていた arp242 氏が、過去の緩い権限付与によって残っていた commit 権限を整理した、という見方のほうが自然に見える。

■ fsnotify は「誰のプロジェクト」だったのか

まず前提として、fsnotify は Go のファイル監視ライブラリで、いろいろなプロジェクトに使われている。Kubernetes などでも間接的に関係するため、supply chain 的にも軽く扱えるものではない。

今回の騒動では、「元 maintainer が外された」「original author まで外された」みたいな話が広がったように見えるが、ここはかなり慎重に見る必要がある。

GitHub の Issue #757 で arp242 氏は、過去に repo が archived されていたこと、自分が Nathan に連絡して引き継ぎ、かなりの時間をかけて整理してきたことを説明している。

また、commit log を見ても、近年の実質的なメンテナンスは arp242 氏がかなり担っていたように見える。arp242 氏自身も以下のような contributor 数を出している。

178 Martin Tournoij <[email protected]>
160 Nathan Youngman <[email protected]>
112 Chris Howey <[email protected]>
...
15 mattn <[email protected]>
...
5 ICHINOSE Shogo <[email protected]>

もちろん commit 数だけがすべてではない。だが、少なくとも「arp242 氏は急に現れてプロジェクトを乗っ取った人」ではない。むしろ、長い間かなり実質的に面倒を見ていた側だと見るべきだと思う。

■ 古い commit 権限と、現在の maintainer 権限は同じではない

この件で重要なのは、fsnotify には過去にかなり緩く commit 権限を与えていた時期があったらしい、という点だ。

Issue #126 では、当時の maintainer が「最初の PR 後に commit access を与える」ようなかなり liberal な方針について話している。

つまり、過去に commit bit を持っていたからといって、それが現在の production-critical な OSS における release 権限や main への直接 push 権限を持つべきだ、という話にはならない。

昔の小規模 OSS では、PR を投げてくれた人に commit 権限を渡すような文化はあった。善意ベースではある。しかし、今となってはそのまま残しておくのはかなり危うい。

特に fsnotify のように広く使われるライブラリでは、「昔 PR を出したことがある人」がそのまま release できる状態になっているほうが、むしろ supply chain 的には怖い。

だから、arp242 氏が権限を整理したこと自体は、それほど不自然ではない。むしろ、実質 maintainer としてはやるべき整理だった可能性がある。

■ FUNDING.yml の変更は軽く見てはいけない

今回、個人的に一番引っかかるのは、mattn 氏が .github/FUNDING.yml を変更して、自分を GitHub Sponsors に追加している点だ。

commit はこれ。

- github: arp242
+ github: [arp242, mattn]

これは単なるバグ修正ではない。資金導線の変更である。

OSS において funding の設定を変えることは、コードの typo 修正や CI 修正とは意味が違う。既存 maintainer との明示的な合意なしに、自分を sponsor 対象に追加するのは、かなり強い行動だと思う。

しかも、arp242 氏の説明によると、mattn 氏は thanks.dev から過去に funds を引き出していたが、fsnotify で実質的な作業をする前だった、という文脈もあるらしい。

この説明が事実なら、arp242 氏が不信感を持つのはかなり自然ではないか。

少なくとも、「mattn 氏が善意で助けようとしただけなのに、arp242 氏が急に怒って追い出した」という単純な話ではない。

■ mattn 氏の行動にも疑問がある

mattn 氏は日本の Go 界隈では非常に有名な人で、技術的な実績も大きい。それは否定しない。

ただ、今回の個別の行動が妥当だったかは別問題だ。

疑問点は複数ある。

• fsnotify の issue 上で十分に確認する前に、X で強い印象を与える形で発信したように見えること
• FUNDING.yml に自分を追加したこと
• メンテナ権限を外されたあと、似たような API の gofsnotify/fsnotify を立ち上げたこと

もちろん fork や別実装を作る自由はある。OSS なので、それ自体は問題ではない。

しかし、今回の流れでそれをやると、「元プロジェクトの信頼性に疑問があるから、こちらに移行しよう」という空気を作りやすい。実際、日本語圏ではそういう反応も見かける。

これはかなり危ういと思う。

■ AI rewrite 的な振る舞いは軽く見られすぎている

gofsnotify が実際にどういう意図で作られたのかは、外からは断定できない。

ただ、既存プロジェクトと似た API の代替実装を、権限トラブルの直後に短期間で立ち上げることには、少なくとも行儀の悪さがあると思う。

最近は、既存 OSS のコードを AI に rewrite させれば、ライセンス上の制約や由来の問題を回避できる、というような雑な発想も批判されている。AI を通したからといって、設計・API・挙動・テスト・不具合修正の蓄積までクリーンになるわけではない。

gofsnotify がライセンス逃れ目的だと言いたいわけではない。そこは断定できない。

ただ、元プロジェクトへの不信が広がっているタイミングで、似た API の代替実装を AI 利用込みで出し、それを周囲が「移行先」として扱うのは、かなり慎重であるべきだと思う。

少なくとも、「AI で作ったから問題ない」「別実装だから問題ない」「有名人が作ったから信用できる」といった雑な受け止め方は危うい。

■ 日本語圏の反応がかなり危うい

今回一番気になったのは、日本語圏での反応だ。

• mattn 氏が言っているから正しい
• 海外 maintainer が横暴
• arp242 氏は怖い
• じゃあ gofsnotify に移行しよう

みたいな流れが、かなり安易に見える。

有名人の発言は強い。特に日本語圏では、海外 OSS の issue をちゃんと読まずに、日本語の X の空気だけで判断する人も多い。

しかし OSS の maintainer 権限、release 権限、funding、supply chain は、感情で判断するものではない。

mattn 氏のこれまでの実績と、今回の行動の妥当性は分けて考えるべきだ。

同じように、arp242 氏の言い方がきついことと、権限整理の妥当性も分けて考えるべきだ。

■ arp242 氏にも落ち度はある

もちろん、arp242 氏が完璧だったとは思わない。

権限を外すなら、事前または直後に issue を立てて説明したほうがよかった。

たとえば、

• 過去の緩い commit access を整理する
• 実質 maintainer と release 権限を明確化する
• funding の変更には事前合意を必要とする
• main への直接 push を制限する
• 過去 contributor は collaborator ではなく contributor として扱う

といった governance note を出しておけば、ここまで燃えなかったかもしれない。

その意味で、arp242 氏の手続きは雑だったと思う。

ただし、それは「arp242 氏が悪意を持って乗っ取った」という話とはまったく違う。

説明不足だったことと、権限整理の理由がなかったことは別である。

■ まとめ

自分の見方はこうだ。

• arp242 氏は説明の出し方が悪かった
• しかし、fsnotify を実質的に長くメンテしてきたのは arp242 氏側に見える
• 過去の緩い commit 権限を整理すること自体は不自然ではない
• FUNDING.yml に自分を追加する行動はかなり重い
• mattn 氏の X での発信は、結果として arp242 氏への過剰な攻撃を招いたように見える
• その後に似た API の gofsnotify を短期間で出し、周囲が移行先として扱う流れもかなり危うい

だから、今回の件を「arp242 氏が横暴だった」で片付けるのはかなり無理があると思う。

むしろ、日本語圏の反応こそ反省したほうがいい。

OSS の信頼性は、有名人が怒っているかどうかではなく、実際の履歴、権限、資金導線、review、release policy、長期保守の実績で判断するべきだ。

少なくとも、fsnotify から gofsnotify に移行しよう、みたいな話を軽くする段階ではない。

MEMO:

• バグ修正のリリースにしれっとFUNDING.ymlの変更を混ぜ込むのは確かに行儀の悪い振る舞いである

(2026/05/08)

要件定義の精度を高めるための型と生成AIの活用

• 要件定義の精度を高めるための型と生成AIの活用 / Using Types and Generative AI to Improve the Accuracy of Requirements Definition - Speaker Deck

要約:

■ 1. 概要

• 発表: BPStudy #224（2026年4月30日）
• 発表者: 佐藤治夫（株式会社ビープラウド 代表取締役社長）
• テーマ: 要件定義の精度を高めるための「型」と生成AIの活用
• アジェンダ構成:
  • 01 再浮上する要件定義不要論
  • 02 エージェントによる開発と要件定義
  • 03 コンテキストエンジニアリングとRDRAの親和性
  • 04 モデルベース要件定義手法 RDRA とは
  • 05 RDRA Agent の価値
  • 06 エンジニアリングの重要性の高まり

■ 2. 再浮上する要件定義不要論

• 時代背景:
  • 2025〜2026年にAI Agent時代が到来しつつある
  • コードを書く主体が「人間」から「エージェント」へ移行しつつある
  • 従来のSDLC（要件→設計→実装→テスト→レビュー→デプロイ→監視）が「意図→エージェント→コード+テスト+デプロイ→動作確認→出荷」へ変化しつつある
• 要件定義不要論の背景にある思惑:
  • 作ってから直せばよい（フィードバックを元に直せるという前提）
  • 作ったものを見ないと要件はわからない（動く実物が要件を引き出すという考え方）
  • 動くものがあると進んでいるようで安心する（進捗報告がしやすい）
  • 早く開発したい（設計以降の作業の方が得意・楽しい）
  • 要件定義は不要だとイーロン・マスクも言っている
• 要件定義を省略すると起こること:
  • 不要なものを必要以上に作ってしまう（本来不要な機能や仕様まで実装）
  • 要求の爆発（整理されないまま要求が雪だるま式に膨らむ）
  • 手戻り工数の増大（後工程ほど修正コストが指数的に上昇）
• 後になるほど大変になるため「急がば回れ」の心構えが必要
• アジャイル開発においても各スプリントが「開発対象スコープの要件定義」を内包する

■ 3. エージェントによる開発と要件定義

• エージェント開発での問題の顕在化:
  • 不要なものを必要以上に作る → 工数を吟味せず開発してしまう
  • 要求の爆発 → Why/Whatが無いため優先順位付けが難しい
  • 手戻り工数の増大 → トークンのムダな消費
• 大規模システムをエージェントだけで作るのは手戻りが大きくほぼ不可能
• 「XXXシステムをつくりたい」だけをエージェントに渡しても意図と実装の差分が大きく失敗する
• 対策: システムをユースケース・ストーリー単位に適切に分割する
• ユースケース（ストーリー）がコンテキストとなるコンテキスト設計が有効
• 要件定義の成果物がそのままコンテキストエンジニアリングの入力になる

■ 4. コンテキストエンジニアリングとRDRAの親和性

• コンテキストの腐敗:
  • 入力コンテキストが増えるほど回答精度が低下する現象が存在する
  • 理想的な回答精度に対して実際の回答精度は入力量が増えるほど低下する
• 自然言語ベースのユースケース記述やストーリーはコンテキストとして悪くはないが解像度が粗い:
  • 曖昧さが残りAIへの問い直しが多発する
  • AIとの往復が繰り返し発生しトークン消費・時間コストが嵩む
• RDRAのユースケースは「画面・イベント・タイマー・情報・条件・バリエーション・状態（遷移）」と関係づけて記述する
• RDRAの要素のつながりがコンテキストとして有効である（仮説）

■ 5. モデルベース要件定義手法 RDRA とは

• RDRAの定義（Relationship Driven Requirement Analysis）:
  • システム開発のための要件定義手法（現場で適用できる実装可能な方法論）
  • 要素同士の「関係（Relationship）」を定義する
  • モデルとして可視化する（俯瞰できるモデルを作る）
• システムの定義:
  • 極めて多数の構成要素から成る集合体で各部分が有機的に連携して全体として一つの目的を持った仕事をするもの（新明解国語辞典 第7版）
• 従来の要件定義手法の問題点:
  • 自然言語と断片的な図で記述することが多い
  • システムにとって重要な「要件（構成要素）間のつながり」を読み手が推測して理解する必要がある
  • 抜け漏れ・不整合が発生しやすく要件定義の精度が低下する
• RDRAによる要件定義の優位性:
  • 要素のつながりを明示的に定義する
  • 推測不要（関係性が定義として書かれている）
  • 抜け漏れ・不整合を自動的に検出できる
  • 要件定義の精度・品質が上がる
• RDRAの全体像（4層構造）:
  • システム価値: 要求確認（システム・外部システム・要求）
  • システム外部環境: 業務要件定義（業務・BUC=Business Use Case）
  • システム境界: システム要件定義（UC=Use Case・画面・イベント・情報・条件・タイマー）
  • システム: コンテキスト・情報モデル・状態モデル・条件・バリエーション
• RDRAの進め方:
  • RDRA定義・分析Sheet（Google Sheetsで要件を定義・分析・検証する）
  • RDRA Graph（ブラウザでモデルをビジュアルに確認する）
  • 「関連データ」シートからRDRA Graphを開く
• 要素の定義と関連付けをシートで実施する構成要素:
  • アクター・外部システム（システム価値・外部環境）
  • BUC（システム外部環境・システム境界）
  • 情報・状態・条件・バリエーション（システム内部）
• RDRAによる要件定義の3フェーズ:
  • Phase 1（枠組みを作る）: 議論の土台作り（全体の構成要素を洗い出す）
  • Phase 2（要件を組み立てる）: 要素を関連づけて骨格を組む（トップダウン+ボトムアップ）
  • Phase 3（整合性・網羅性を高める）: 要件定義の仕上げと仕様化の準備（矛盾を解消し整合性を高める）

■ 6. RDRA Agent の価値

• 従来の悩みどころ:
  • 土台を1から作るのが重い（0から構造を組み立てる工数が大きい）
  • 抜け漏れが出やすい（初期に観点を網羅しきれない）
• RDRA ZeroOne / RDRA Agentの価値:
  • LLMを活用してモデルの叩きを0→1で自動生成する
  • テキストデータをクリップボードから読み込みRDRA Graphを開く
  • 「ZeroOne」シートにテキストを貼り付けRDRA定義・分析Sheetを生成する
  • 土台を自動生成することで議論から開始できる
• 制約事項:
  • 整合性・精度向上フェーズ（Phase 2・Phase 3）は人による議論と合意が必須

■ 7. エンジニアリングの重要性の高まり

• AIエージェントの二面性:
  • 業務の生産性や成果を劇的に高める「能力増幅装置」として機能する
  • 適切に管理されない場合はリスクを拡大させる装置にもなり得る
• エンジニアリング原則（手戻りコストの影響を常に意識する）:
  • ソフトウェア開発201の鉄則「鉄則41: 今すぐ要求仕様書の誤りを直せ」
  • 要求仕様書の誤りは発見が後になるほどコストが増大する
  • 設計まで残ったら修正に5倍のコスト
  • コーディングまで残ったら10倍のコスト
  • テスティングまで残ったら20倍のコスト
  • 納入時点まで残ったら200倍のコスト
  • 「後で修正すればいい」という考え方が最終的な納期とコストを破壊する
• エンジニアリング原則（インサイドアウトで品質を高める）:
  • プロセス品質（要件管理・設計基準・レビュー・早期テスト）
  • 内部品質（保守性・再利用性・テスト容易性）
  • 外部品質（機能・性能・セキュリティ）
  • 利用時の品質（目的の達成・価値の創出）
  • これらが連鎖することで品質+開発生産性の向上につながる
• エンジニアリング原則（V字モデルを開発の地図として持つ）:
  • 企画→業務要件定義→システム要件定義→基本設計→詳細設計→プログラミング（左下降）
  • コードレビュー→単体テスト→結合テスト→システムテスト→運用テスト→運用・評価（右上昇）
  • 効果的なエンジニアリングがAIの使用効率も高める
• 弁証法的考察（螺旋階段モデル）:
  • 世の中全ての物事の進歩や発展は右肩上がりに一直線に進歩・発展するのではない
  • あたかも「螺旋階段」を登るようにして進歩・発展していく（田坂広志『使える弁証法』より）
  • 正（テーゼ）→反（アンチテーゼ）→合（ジンテーゼ・アウフヘーベン＝否定の否定）のサイクルで発展する
• エンジニアリングの変遷（弁証法的な螺旋発展）:
  • 2000年代: エンジニアリング重視（プロセス・モデリング・設計、オブジェクト指向設計、RUP・UML・PoEAA・アナリシスパターン）
  • 2010年代: アジャイル開発が台頭（プロセスを重視した開発へのアンチテーゼとして技術・実装重視へ）
  • 2025年以降: 新しいエンジニアリングの在り方（エンジニアリングと技術・実装が融合されたものへ）

■ 8. まとめ

• 再浮上する要件定義不要論: 手を抜くと後ほど大変になる（不要なものを開発・要求の爆発・手戻り工数の増大）
• エージェントによる開発と要件定義: 企画・要件定義の内容がコンテキストエンジニアリングにそのままつながる
• コンテキストエンジニアリングとRDRAの親和性: RDRAの要素のつながりがコンテキストになる
• モデルベース要件定義手法RDRA: システムを構成する要素同士の関係（Relationship）を定義することでモデルとして可視化する
• RDRA Agentの価値: 叩きが生成されることでゼロからのスタートを回避できる
• エンジニアリングの重要性の高まり: AIエージェントは「能力増幅装置」だからこそエンジニアリングが効く

(2026/05/08)

生成AIでスクラムによる開発はどう変わるか

• 生成AIでスクラムによる開発はどう変わるか | Ryuzee.com

要約:

■ 1. 概要

• タイトル: 生成AIでスクラムによる開発はどう変わるか
• 登壇者: 吉羽龍太郎（株式会社アトラクタ CTO・認定スクラムトレーナー）
• 日時: 2025年10月17日

■ 2. 生成AI導入の現状

• 調査回答者の90%が仕事でAIを利用
• 80%以上が生産性向上を実感
• AI導入はもはや検証段階でなく利用しないことがマイナスな状況

■ 3. 従来のスクラムにおける時間配分

• 実装作業が律速要因
• スプリントの時間配分は開発作業の最大化を優先
• スクラムイベント・リファインメント・事務作業を最小化する構造

■ 4. 生成AIによるボトルネックの変化

• 実装時間の激減:
  • 調査・実装・テスト支援が大幅短縮
• ボトルネックの移動:
  • 実装から「事前のドキュメント化」と「事後の検証」へシフト

■ 5. ドキュメント中心化

• AIは「考えを想像」しないためテキスト化されたドキュメントが必須
• 詳細化が重要なドキュメント:
  • プロダクトバックログ
  • スプリントゴール
  • 完成の定義
  • アーキテクチャー
  • コーディング規約
• ドキュメント化のコツ:
  • 前提条件・入力・出力を具体化
  • 例と反例を示す
  • 参照先を紐付ける
  • 用語の一貫性を保つ

■ 6. チーム構成の変化

• モブプログラミングへのシフト:
  • 並列作業の必要性が低下
• 小チーム化:
  • コミュニケーションコスト削減
  • 合意形成の高速化
• ドメイン分割による複数小チーム構成が有効

■ 7. スクラムイベントの変化

• スプリント期間:
  • 従来は1〜2週間が一般的
  • 実装が速くなり1週間以下も可能
• スプリントプランニング:
  • 詳細化のタイミングを遅延可能
  • スプリント中のモブ作業で詳細化
• スプリントゴール:
  • 短期化に伴い重要性が増加
  • 明確なテーマで集中促進
• デイリースクラム:
  • モブ化で常時スクラムの状態
  • 形式的イベントの重要性が低下
• スプリントレビュー:
  • ステークホルダー参加頻度がボトルネック化
  • AIを前提とした期待値調整が必要
• スプリントレトロスペクティブ:
  • AI活用方法の改善が常時テーマ
  • 実験・検証が定常化

■ 8. プロダクトバックログアイテムの変化

• 粒度:
  • 1スプリント単位でなく「AI入力単位＋検査容易性」で設計
• 見積りの意味低下:
  • 実装時間の不確実性低減でベロシティ計測の重要性が減少
• 受け入れ基準の詳細化:
  • テストケースなどを先行検討

■ 9. 現場の課題

• 説明責任:
  • AIに責任を委譲しない
  • 決定と根拠をドキュメント化
  • 完成の定義に説明可能性を含める
• 品質管理:
  • 入力品質とベースコード品質が出力を決定
  • レビュー・ガイドライン・テンプレートの重要性向上
  • 検査と適応の頻度を上げる
• 人材育成:
  • AI活用でコーディング経験機会が激減
  • シニアエンジニアの育成パイプラインが危機的
  • 組織的なスキル投資が必須

■ 10. まとめ

• スプリント短期化とドキュメント優先
• 見積りより内容の合意を重視
• AI活用方法の継続改善
• 品質維持の仕掛けの整備
• 透明性・検査・適応の不変性
• 学習への継続投資

(2026/05/07)

以前、fsnotify がメンテ出来なくなりメンテナを募集　→ 知見があるのでメンテナに参加　→ その時、某氏...

以前、fsnotify がメンテ出来なくなりメンテナを募集

→ 知見があるのでメンテナに参加 → その時、某氏も参加 → 活動しようと思ったら「勝手な事をするな」と叱られる

それからしばらく経って

→ ユーザから「このリポジトリもうメンテしてないん？」と言われる → 見てみるともう 2～3カ月活動がない → 「僕がやるわ」と即答 → 幾らかバグを潰しリリースもした → そして今日突然なんの通告もなく fsnotify の org から強制除名。

某氏、勢い余ってか fsontify の元作者すらも org から削除してしまった様で、ぶっちゃけ怖い。

@mattn_jp

いっぽうで、僕はもう気軽に fsnotify/fsnotify を使う事が出来なくなってしまったので、gofsnotify/fsnotify を作って自分で育てていく事にしました。今のところ僕専用です。

https://github.com/gofsnotify/fsnotify

@mattn_jp

フォークしたリポジトリでの経緯説明

• https://github.com/gofsnotify/fsnotify/issues/1#issuecomment-4386693483

A bit of background on why this project exists. Some time ago the original fsnotify lost its active maintainer and a call went out for help, and since I had prior experience in this area I joined the maintainer team. Another person signed on around the same time, and when I tried to start contributing I was told not to "act on my own."

A while later a user asked me whether the repository was still being maintained. I checked and saw there had been no activity for two or three months, so I stepped in, fixed several bugs, and even cut a release. Then today, with no prior notice, I was suddenly removed from the fsnotify organization.

The upshot is that I can no longer work on fsnotify in my own style, so I'm building my own here under a separate organization. The name happens to match, but the implementation does not reference the original source — though for a feature set like this, the public API will naturally come out looking similar. I don't expect to return to fsnotify/fsnotify either. The API design here may evolve over time, but at minimum, my expertise around Windows will be poured into this codebase.

このプロジェクトが立ち上がった経緯について少し説明します。少し前、オリジナルのfsnotifyはアクティブなメンテナを失い、助けを求める呼びかけがありました。私はこの分野での経験があったため、メンテナチームに加わりました。ほぼ同時期に別のメンバーも加わりましたが、私が貢献を始めようとしたところ、「独断で行動しないように」と言われました。

それからしばらくして、あるユーザーからリポジトリがまだメンテナンスされているか尋ねられました。確認してみると、2、3ヶ月間活動がなかったため、私が介入していくつかのバグを修正し、リリースまで行いました。ところが今日、事前の通知もなく、突然fsnotifyの組織から除外されてしまいました。

結果として、私はもはや自分のスタイルでfsnotifyに取り組むことができなくなったため、別の組織の下で独自のプロジェクトを構築しています。名前は偶然一致していますが、実装は元のソースコードを参照していません。とはいえ、このような機能セットの場合、公開APIは当然似たようなものになるでしょう。fsnotify/fsnotifyに戻るつもりもありません。ここのAPI設計は今後進化していくかもしれませんが、少なくとも、Windowsに関する私の専門知識はこのコードベースに注ぎ込まれることになります。

その後

件の fsnotify に関する投稿を削除しました。必要以上に不安を煽ってしまったり混乱を起こしてしまうのは僕も避けたい為であり、それ以上の意味はありません。

なおエビデンスを消した訳ではなく、投稿は自ら魚拓を取って保存しており必要な場面があれば提出します。

@mattn_jp

MEMO:

• 追放した某氏は↓
• arp242 (Martin Tournoij)
• 幼稚な独占欲によるものか、何かよからぬ事を考えているのか

(2026/05/07)

おい、要件を動くものにしろ

• おい、要件を動くものにしろ - じゃあ、おうちで学べる

要約:

■ 1. 記事の概要

• タイトルは「おい、要件を動くものにしろ」であり AI時代における要件工学シリーズ第2部にあたる
• 要件は文書として残すものではなく 型システム・テスト・CI/CDパイプライン・コードスキーマ・自動レビューに埋め込まれた「動くもの」として存在すべきであると主張する
• ドキュメントは書かれた瞬間から腐敗が始まるが コードに埋め込まれた要件は毎日読まれ検証され続ける

■ 2. 要件・仕様・契約の定義整理とスペック駆動開発の分類

• 三つの概念の定義:
  • 要件:ビジネスが達成したいこと
  • 仕様:システムがその要件をどのように実装するか
  • 契約:コンポーネント間の保証
• スペック駆動開発の3分類:
  • スペックファースト:仕様は実装後に破棄される
  • スペックアンカード:仕様は実装と並走して更新される
  • スペックアズソース:コードは仕様を唯一の真実の源として導出される
• 著者はハイブリッドアプローチを推奨し 仕様が価値を生む箇所にのみ適用することを提唱する

■ 3. AIコードのレビューが困難な理由と信頼構築の方向性

• AI生成コードのレビューには通常の3倍の時間がかかる
• 原因は読む時間の増加ではなく「共有コンテキストの欠如」にある
• 人間のレビュアーが依存する暗黙のチーム知識をAIは持たない
• 解決策はより良いプロンプトではなく より良いコンテキストの提供にある
• 信頼構築のための4方向:
  • ドメイン知識を明示的に構造化する
  • 責任の境界を明確にする
  • 実装前に要件合意を明示的に確保するようプロセスを再設計する
  • AIへの指示をチームの共有資産へ移行する

■ 4. 要件の5層分散

• 原則:1つの要件は1箇所に配置し 検証されるタイミングによって配置先を決定する
• 各層の配置:
  • プロジェクトレベル:CLAUDE.mdに記述する
  • ドメイン固有:ドキュメントとスキルに記述する
  • 機能固有:コミットメッセージ・PRテンプレート・テストコメントに記述する
  • 手続き的:CIワークフローとリンティングルールに記述する
  • 振る舞い:実行可能なテストスイートに記述する

■ 5. 主観的レビューの削減とアーキテクチャの役割

• 著者は「客観的／主観的 × 予防的／回復的」の2×2マトリクスを提示する
• AI時代のボトルネックは「主観的×予防的」の象限であり 自動化できない人間の判断を要する
• アーキテクチャによりこの象限を最小化する手法:
  • 境界付きコンテキスト:意思決定の境界を明確にする
  • 常に有効なドメインモデル:型によって不正な状態を表現不可能にする
  • タイプファースト開発:型を優先して設計する
  • 可変コードと不変コードの分離
  • イベントソーシングによる説明責任の確保

■ 6. 受け入れ基準の実行可能化

• 曖昧な記述（例:「速くなければならない」）を具体的な形式に変換する
• 要件は「いつ・誰が・どこで・何を・どのように・どのくらい」の6要素で記述する
• 具体例:「ユーザーがクリックしたとき APIは200ms以内に応答する」という形式にする
• 「してはならないこと」と「明示的にスコープ外のこと」も記述する

■ 7. 非機能要件とトレードオフの管理

• 非機能要件（性能・セキュリティ・保守性など）は相互に干渉する
• セキュリティ強化は性能を低下させるなど 全てを同時に最大化することはできない
• 「上位3つ」の優先順位を特定し 何がハード目標（二値的合否）で何がソフト目標（程度による）かを認識する
• プロジェクトのフェーズが変化するにつれて優先順位を定期的に見直す

■ 8. 著者のスタンスと実践的原則

• 著者は「仕様書よりも検証を重視する」立場をとる
• 厚い要件ドキュメントよりも 厚いテストとガードレールを重視する
• 実践的原則:
  • 要件は読まれる場所に記述する:別途ドキュメントではなくコードのコンテキストに記述する
  • 測定可能なものは全て自動化し 本物の判断が必要なものにのみ人間のレビューを用いる
  • 要件の進化を認識し「上位3つ」の優先順位をプロジェクト成熟に合わせて見直す
  • 要件はカテゴリではなく検証タイミングによって配置する
  • 書き込み操作と読み込み操作を分離しレビューの強度に差をつける

論評:

■ 1. 総評

• 記事の主張密度と文章量の比率が逆転している
• 核心的な主張は早期に確立されており 以降は同じ主張の繰り返しまたは傍証の積み上げに費やされている
• 記事全体は必要な分量の2倍に相当する

■ 2. 論理的に機能している部分

• 中心テーゼの明確さ:
  • 「ドキュメントに置かれた要件は腐る 動くもの（テスト・型・CI・CLAUDE.md）に分散させた要件だけが毎回検証される」という主張が一貫している
• 撤回条件の明示:
  • この種の実践知系記事では珍しく誠実であり 論述の信頼性を高めている
• 要件/仕様/契約の3区分:
  • 実用的で読者に整理をもたらす
  • 仕様駆動開発の文脈でこれを明示したことに価値がある

■ 3. 論理的に脆弱な部分

• 「動くものは腐らない」という前提の誤り:
  • 著者自身が結論部でテスト・lintルール・CLAUDE.mdも古びると認めている
  • 「腐らない」ではなく「腐ったとき気づきやすいかどうか」という違いを論じるべき
  • 強い主張を採用したまま自己矛盾を抱えている
• 「3倍のレビュー時間」の根拠の脆弱さ:
  • N=1の自己計測にすぎない
  • この数値から「AIで書いたコードは構造的に信頼できない」という一般命題を導いており 観測規模と主張のスケールが不釣り合い
• 「5つの場所に散らす」処方箋の構造的問題:
  • 処方箋を先に提示した後 その問題点として自らの失敗事例が続く
  • 読者を混乱させる順序であり 「1つの要件は1つの場所」を前提として先に述べ 5つは「置き場の種類」として整理し直す必要がある
• 「AIのエラーは新種ではない」という主張の検証不可能性:
  • 撤回条件として「AI固有で以前には観測されなかったエラーを列挙できたら撤回する」と記載している
  • 「AI以前に存在しなかった新種エラー」の同定自体が主観的かつ困難であり 撤回条件が実質的に機能しない
• 4象限モデルの「主観×予防がボトルネック」の論証不足:
  • 「他の象限が自動化・高速化したから相対的に目立つ」という相対論的推論のみで 「最大」と断言するには不十分

■ 4. 主張の冗長パターン

• パターンA（テーゼの繰り返し）:
  • 「動くものに要件を散らす」「ドキュメントは腐る」「機械に判定させる」が複数の節でほぼ同一命題として再登場する
• パターンB（撤回条件の儀式化）:
  • 5〜6回登場することでテンプレート的な免責事項に見えてくる
  • 主要な主張に1〜2回絞った方が誠実さが際立つ
• パターンC（非機能要件節の逸脱）:
  • 「トレードオフ」「Top 3」「時間軸の変化」「AIシステムの新しい品質要件」は中心テーゼとの接続が薄い
  • 結論に辿り着くまでの道のりが長すぎる
• パターンD（個人エピソードの過剰使用）:
  • マイナス在庫の失敗・深夜の差し戻し・空調管理システム・保持期間インシデント等 主張の補強よりページ数の補充として機能している場面が多い

■ 5. 構造的批判

• 記事は実質的に5本の異なる記事を1本に詰め込んでいる:
  • 仕様駆動開発の用語整理と分類
  • AIコードレビューの構造的困難
  • 要件を実行可能な形へ変換する技法
  • 認知負荷を減らすアーキテクチャパターン
  • 非機能要件のトレードオフ管理
• タイトル「おい 要件を動くものにしろ」に対して読者が期待するのは「要件を実行可能な形へ変換する技法」のみ
• 仕様駆動開発の用語整理とAIコードレビューの困難は導入として機能するが アーキテクチャパターンと非機能要件管理は本記事の射程を超えている
• 4象限モデル以降は別稿にすべきであり そうすることで本論が締まる

■ 6. 結論的評価

• 中心テーゼの明確さ: 高い
• 論理の整合性: 中程度（自己矛盾あり）
• 証拠の質: 低め（個人観測が中心）
• 冗長さ: 問題あり（2倍の分量）
• 実務上の有用性: 高い（具体的な処方箋は有用）
• 「ドキュメントより実行可能なもので要件を保つ」という主張は正しく実践的な価値も高い
• 主張の強さに対して論証が追いついていない
• 分量を半分にして核心（要件を動くものへ変換する技法）に絞れば 説得力は現状より増す

(2026/05/06)

ソフトウェア開発の本質的な問題は何だと思いますか？に対する山本 聡 (Satoshi Yamamoto)さんの回答

• ソフトウェア開発の本質的な問題は何だと思いますか？に対する山本 聡 (Satoshi Yamamoto)さんの回答 - Quora

要約:

■ 1. ソフトウェア開発の難しさ：複雑さとの戦い

• ソフトウェアは機能追加により必然的に大規模化し機能間の関係が複雑さを生む
• 複雑さが個人やチームの許容値を超えると不具合増加・工数超過・開発停滞が発生する
• 複雑さを制御しシンプルさを保つことがソフトウェア開発の核心的課題である

■ 2. 複雑さへの対処：継続的リファクタリング

• 機能追加後に複雑化したまま放置せずその場でリファクタリングを行う
• コードへの理解が深い段階で修正することで修正コストが最小化される
• 「新規機能開発前に十分なリファクタリングをしているか」を方針として掲げる
• Joel Testの「バグ修正優先」をさらに発展させリファクタリングを先行させる
• リファクタリングを認めるプロジェクトは複雑さを抑制し順調に進む傾向がある
• 製造業のカイゼン（整理整頓）と同様にソースコードも継続的な整理整頓が有効である

■ 3. ソフトウェア開発の本質的な問題：「見えない」こと

• 良いものと悪いものの判断がすぐにはできないことが本質的問題である
• ホテルや自動車は素人でも品質の良否をある程度観察できる
• ソフトウェアのコードは熟練技術者でも数ヶ月読み込まないと良否の判断が困難である
• 言語が異なれば上級者であっても判断不能になる

■ 4. 「見えない」ことが引き起こす問題

• 上級者には明らかな問題が初心者・中級者には「意見の相違」として処理される
• 良くないコードがマネジメント層には問題に見えずリファクタリングの必要性が無視される
• 初心者・中級者が上級者のコードを誤って低く評価するケースも生じる
• コード断片の善し悪し→プロジェクト全体の善し悪し→プロジェクト運営の善し悪しと段階的に判断が難しくなる
• 顧客と開発者の意思疎通困難・開発者同士の相互理解困難・見積もりの困難もすべて「見えない」問題に帰結する

■ 5. 観察と誤った改善への注意

• うまくいっていないのにカイゼン不要と思い込み現状維持のまま手遅れになるケースがある
• うまくいっていることをカイゼンしようとして逆効果を招くケースもある
• 例：ドキュメント不要で順調だった開発にドキュメント作成を導入し開発速度が低下する
• 何がうまくいっていて何がうまくいっていないかを正確に観察することが重要である

(2026/05/06)

人月の神話

• 人月の神話 - Martin Fowler's Bliki (ja)

要約:

■ 1. 書籍の概要

• フレッド・ブルックスが1960年代初頭にIBM System/360開発プロジェクトを統括した経験をもとに執筆
• 1975年に出版された『人月の神話』はソフトウェア開発において最も影響力のある書籍の一つ
• 2026年時点で一部の内容は時代遅れとなっているが多くの教訓は現在も有効

■ 2. ブルックスの法則

• 「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」という法則を提唱
• 要員増加により生じる問題:
  • コミュニケーション経路が指数関数的に増加する
  • コミュニケーション設計が不十分な場合作業が混乱に陥る

■ 3. コンセプトの完全性

• システム設計において最も重要な考慮事項はコンセプトの完全性である
• 設計思想に一貫性のあるシステムは機能が限定されていても優れたアイデアを無秩序に詰め込んだシステムより望ましい
• コンセプトの完全性を構成する要素:
  • 簡潔さ（simplicity）
  • 直截（straightforwardness）：要素を容易に組み立てられるかどうか

■ 4. 推奨事項

• 20周年記念版の入手を推奨
• 1986年の影響力の大きい論文「銀の弾などない」が同版に収録されている

(2026/05/06)

人を増やしても減らしてもアウトプットの品質は向上しない

• 人を増やしても減らしてもアウトプットの品質は向上しない - kosui

要約:

■ 1. 結論

• 人数の増減はアウトプットの品質向上に直結しない
• 問題の本質はコミュニケーションパスの増加と知識のエントロピー拡大が引き起こす中央集権化ループにある
• 解決策は「何を許し何を禁じるか」を自動検出可能な少数の条文として明文化する規範レイヤーの整備である
• 条文はリスクの大きさに応じて詳細度を配分し人間が読まなくても自動で機能する最小集合に絞り込むことが重要

■ 2. 人数増減の限界

• 人を増やした場合の問題:
  • コミュニケーションパスがN(N-1)/2で指数的に増加する（10人で45本・20人で190本・30人で435本）
  • 知識のエントロピー（メンバーが持つ知識分布のばらつき）が拡大し文脈共有コストが増大する
• 人を減らした場合の問題:
  • 解くべき問題の複雑さは変わらず1人あたりの担当範囲が広がる
  • 知識のエントロピーはむしろ増し各人の認知負荷が積み上がる
• 共通の帰結:
  • いずれの場合も意思決定が特定のリードに集中する中央集権化ループに陥る
  • 中央集権体制は意思決定速度を一時的に回復するが分散意思決定と構造的に両立しない
  • リードへの認知負荷累積は判断品質の低下と育成機会の喪失をもたらす

■ 3. 自律的な存在が解決しない問題

• 一貫性の喪失:
  • 局所最適の許容によりUI・データモデル・命名のばらつきが累積する
  • 後続実装者の読解コスト増加がゼロから書く動機を生みばらつきがさらに加速する強化ループに入る
  • 一貫性を収束させようとするレビュワーへの依存が強まり前章と同じ中央集権化ループに帰着する
• ナレッジの劣化:
  • AIによる書き込み頻度の増加に対し剪定役が不在であれば矛盾と陳腐化が加速度的に累積する
  • ナレッジベースへの不信が暗黙知化を進め知識のエントロピーを押し上げる
  • AIエージェントは文脈共有をeasyにするが共有すべき内容そのものをsimpleにはしない
• 自律的な人間の燃え尽き:
  • AI活用度が高い人ほど一人あたりの判断量が増え育成に割ける時間が圧迫される
  • 育成停滞により後進に任せられない状態となり特定人物への判断集中がさらに強まる
  • 判断品質の低下や離脱が残メンバーの負担へ転じ組織全体のパフォーマンスが低下する

■ 4. 規範レイヤーの設計

• 設計の方向性:
  • 「組織として何を許し何を禁じるか」を共有された規範として明文化する
  • ホラクラシー憲章は権力配分の枠組みを定めるが組織横断的な行為規範を含まない
  • 規範なしにリードの暗黙知に依存した運用を続けるとリードへの依存ループが維持される
• 条文の要件:
  • 型検査・CI・Linterとして表現できるものはそこに記述し自動検出を優先する
  • AIエージェントがパターン的に判断できる形での形式化も許容する
  • 規則はADRによってのみ変更可能とする
  • PRD・Design Doc・ADRは人間レビューの前に規範に準じて機械的に評価される
• 条文の例:
  • PIIを永続化する場合はADRやDesign Docで理由を必ず明示する
  • プラットフォームシステムではPHIを永続化してはならない
  • IDや金額などのリテラル値は固有の型を必須とし型検査で取り違えを防ぐ

■ 5. 条文設計の品質基準

• 官僚化リスク:
  • 条文を増やすほど組織は官僚的な方向へ近づきデリバリ性能が低下する
  • Accelerate（DORA調査）はWestnumの3類型（病的・官僚的・生成的）を引用し生成的文化の組織ほどデリバリ性能が高いことを示す
  • 詳細なチェックリストは形骸化し規則を守ることが目的化する文化を育てる
• 絞り込みの原則:
  • 条文数が少なく抽象度が高く自動検出比率が高いほど生成的な文化を維持しやすい
  • 「人間が読まなくても自動で回る最小の集合」に絞り込めないなら未整備のままにしておく方が健全
  • 最重要機能・品質を見極めリスクの大きさに応じてのみ詳細な条文を割り当てる
  • それ以外は原則レベルにとどめ判断の余地を残す
• アーキテクチャとの関係:
  • Accelerateが示す「疎結合なアーキテクチャ」と「分散した意思決定」は少数の高抽象条文なしには成立しない
  • チームが守るべき不変条件が明文化され自動検査されていることが分散意思決定の前提となる
  • あらゆるサブドメインへ詳細条文を網羅して押し付けることはチームが本来払うべき関心を奪う

(2026/05/05)

Product Management Summit 2026　リチェルカ登壇資料『PdMを廃止しました。』

• Product Management Summit 2026　リチェルカ登壇資料『PdMを廃止しました。』 - Speaker Deck

要約:

■ 1. 登壇者・会社概要

• 登壇者は株式会社リチェルカ共同創業者・取締役COOの幸田桃香氏
• 経歴はワークスアプリケーションズ（ERP営業）→FORCAS（SaaS営業）→AI inside（事業開発・代理店営業責任者）→HashPort（Web3.0事業マーケ・PR責任者）→リチェルカ（PM+PdM・コンサル・導入・開発）
• リチェルカは2022年4月設立・資本金約7億9500万円・「AIの社会実装を通じて今までの"できない"を解決する」をミッションとする
• 主要投資家はAngel Bridge・Genesia Ventures・NEW COMMERCE VENTURES
• 借入金融機関はみずほ・SMBC・りそな・商工中金・常陽銀行・北國銀行

■ 2. リチェルカのプロダクト戦略

• 「つくってばらまくSaaS」ではなく、顧客の業務に深く入り込んで課題を解くアプリケーションを開発する「レゴブロック型開発」を採用
• 開発フロー:
  • 顧客Aのペインを深く把握しアプリを開発する
  • 開発したモジュールを汎用化する
  • 汎用化したモジュールを顧客Bの武器として展開する
• 戦略の特徴:
  • エンタープライズの受発注領域に特化する
  • 顧客に深く入り込むほど次プロダクトの土台が積み上がる
  • 1社あたりで展開できるモジュール数（=ARR）が増加する複利構造を持つ

■ 3. PdM廃止の背景と経緯

• 創業当初（2023年〜）の開発体制は「営業→PdM→エンジニア」というリレー型であった
• PdMの役割はERPの業務フロー・ER図の整理、ユースケース作成、PRDの作成
• 従来体制の構造的問題:
  • 顧客の声とプロダクトをつなぐ役割が1職種に集中する
  • エンプラのペインは「深さ」が命であり、伝言ゲームによって希薄化する
  • 役割分担のリレー方式は後発SaaSには遅すぎる
• 2026年にPdMを廃止し、「1人1人が製品責任者」となる体制とFDEの新設へ移行

■ 4. PdM廃止後の新組織体制

• PdMという職種名を廃止し、全員がPdM・製品/機能責任者として機能する体制に移行
• 新設・再定義された役割:
  • クライアントアドバイザー: 既存プロダクトで顧客を立ち上げ、Tier管理しながらペイン抽出→開発連携を担う
  • コンサル: 大型案件で顧客視点を担い、業務理解・折衝・As-Is整理を行う
  • FDE（Forward Deployed Engineer）: エンジニア視点で仮説検証・プロト開発・要件仕様の具体化を担う
  • Application Engineer: 共通基盤の開発と各プロジェクトへの横断アサインを担う

■ 5. FDE（Forward Deployed Engineer）の定義と役割

• 定義: 「誰よりも業務を理解して、As-Is To-Beを描きながら、自分で開発し、顧客の"できない"を解決する役割」
• 必要スキル:
  • ドメイン理解力
  • 仮説構築力
  • 実装力
  • コミュニケーション力
• 他職種との差異:
  • vs PdM: 顧客課題の解決に責任を持ち、1社に深く入り込む
  • vs PM: 自分でコードを書き、モックを開発して語ることができる
  • vs Engineer: 顧客と直接話して仮説を構築できる
• FDEが担う業務範囲: プロジェクトアサイン→顧客との要件定義→プロダクト要件仕様→仮説検証→プロト開発→Application Engineer連携
• 守備範囲が広い理由:
  • 大企業と同じやり方では後発SaaSは勝てない
  • リレー型の役割分担では速度が不足する
  • 勝ち筋は「顧客の深いペインを爆速で形にすること」
  • ペインを聞く人と作る人が同一人物であるべき

■ 6. 現場における変化

• ラストワンマイル問題:
  • AIによって顧客社内でアイデアは広がっているが、組織として運用に乗せるところはほとんど進んでいない
  • 個人レベルでは個人開発・プロトタイプ・PoCが可能になった
  • 組織レベルでは共通AIの導入・業務オペレーションへの組込み・全社再現可能な仕組み・ROIが出るプロダクト化が進んでいない
  • 「個人で作れるものと、組織で回るものは別物」であり、その差を埋めるのがFDEの仕事
• WOW問題:
  • 以前はAIデモを見せるだけで顧客が驚いた
  • ChatGPT・Cursor・Copilotの普及により顧客リテラシーが向上し、WOW演出だけでは価値を出せなくなった
  • 現在の価値源泉は「業務を顧客以上に深く理解し、質の高いアウトプットを速く出せるかどうか」

■ 7. これから求められるスキル

• 求められるのは「営業力×コンサル力×開発力」の掛け算
  • 営業力: 顧客を動かす
  • コンサル力: 課題を構造化する
  • 開発力: 解決策を形にする
• スキルに関する考え方:
  • 全部できる必要はないが、何かが突出して強くなければ深いペインに届かない
  • 営業出身・エンジニア出身・コンサル出身いずれからでも活躍できる
  • 器用貧乏では深いペインに届かない
  • 自分の強みを軸に、他の領域へも「越境する意志」があるかどうかが重要

(2026/05/04)

Go開発者によるDDDの実践：概念理解から具体的な応用まで

• Go開発者によるDDDの実践：概念理解から具体的な応用まで - DMM Developers Blog

要約:

■ 1. プロジェクト概要とリプレース背景

• DMMブックスのバックオフィス向け管理画面サービス（10年以上の運用歴）において技術的負債解消を目的とした大規模リプレースを実施
• 旧構成のPHP（FuelPHP）から新構成へ移行
  • フロントエンド: React（コンポーネントベースによるUI再利用性・保守性向上）
  • バックエンド: Go（静的型付けによる安定性・保守性向上）
  • 設計手法: DDD（ドメイン駆動設計によるビジネスロジック中心の設計）
• 再構築による期待効果
  • システムの持続可能性向上（変化に強く柔軟なシステム）
  • 開発生産性向上（迅速な機能追加・改修）
  • 保守性向上（長期的な運用コスト削減）
  • 開発者体験の向上（最新技術導入によるモチベーション向上と人材確保）

■ 2. DDD導入における課題と対策

• 課題:
  • 概念と実践のギャップ: Entity・Value Object・Aggregateなどの概念をGoコードへ落とし込む具体的なイメージが掴みづらい
  • Go言語特化のノウハウ不足: Go向けDDD実装例が少なく自力での試行錯誤が必要
  • ビジネスロジックの配置判断: ドメイン層・UI層・インフラ層の境界線の引き方が難しい
• 対策:
  • 実践重視のアプローチを採用し概念の疑問をチーム内で徹底議論
  • 実装コードを必ずチームレビューし原則への適合性と改善点を多角的に検討
  • レビューを通じたチーム内知識共有でDDD実装スキルを向上
  • Go言語の特性を活かした実装方法を試行錯誤し独自のベストプラクティスを確立

■ 3. DDDの基本概念

• ドメイン:
  • ビジネスが取り組む問題領域全体（例: 商品販売・顧客管理・在庫管理・決済）
• エンティティ:
  • 一意の識別子を持つオブジェクト（例: ProductID で識別される Product 構造体）
• バリューオブジェクト:
  • 属性の値を表す不変オブジェクト（例: 金額と通貨で構成される Price 構造体）
  • コンストラクタ以外に値を変更する手段を提供しないことで不変性を保証
• アグリゲート:
  • エンティティとバリューオブジェクトの集合で一貫性の境界を形成
  • アグリゲートルートが全体を管理（例: Order がルートで OrderItem をバリューオブジェクトとして保持）
• リポジトリ:
  • アグリゲートの永続化を担うオブジェクトでデータベースアクセスを抽象化
  • インターフェースとして定義し具体的な実装はデータストアに依存
• サービス:
  • 特定のエンティティやバリューオブジェクトに属さないドメインロジックを実行（例: 注文合計金額の計算）

■ 4. DI/DIPの実装

• 依存性逆転の原則（DIP）:
  • 上位モジュールと下位モジュールの両方が抽象（インターフェース）に依存
  • 具体的な実装ではなくインターフェースに対してプログラミングすることが原則
• 依存性注入（DI）:
  • 依存オブジェクトの生成と注入を外部が担当しモジュール間の結合度を低下
• Goでの実装構成:
  • ドメイン層: UserRepository インターフェースと UserService をdomainパッケージに定義し UserService はインターフェースのみに依存
  • インフラストラクチャ層: MySQLUserRepository がインターフェースを実装しDBアクセスを担当
  • main関数: MySQLUserRepository のインスタンスを生成して UserService へ注入
• DI/DIP適用のメリット:
  • テストの容易性: モックリポジトリを注入することでDBアクセスなしにテスト可能
  • 変更への柔軟性: DBを変更する場合はインターフェース実装とmainでの注入箇所を変更するだけでドメイン層は無変更

(2026/05/04)

エラー処理の温故知新

• エラー処理の温故知新 / history of error handling technic - Speaker Deck

要約:

■ 1. 概要

• 発表者: Nakaya Ryota（株式会社ギフティ バックエンドエンジニア）
• 発表日時: 2026年05月01日 giftee TechBash
• テーマ: エラー処理の歴史的変遷と各言語の設計思想の比較

■ 2. エラーの定義と分類

• エラーの定義:
  • エラーとはプログラムの期待と現実のギャップである
  • プログラムが置いた前提や仮定が崩れた瞬間がエラーである
  • 前提は必ずどこかで崩れるためエラー処理は不可避である
• エラーの発生原因:
  • ファイルが存在しない
  • ネットワーク障害
  • 入力値の不正
  • NULLポインター
  • 型の不一致
• エラーの分類:
  • ドメインエラー: 入力値の不正 / 実行前提条件の未充足 / 認証・認可の失敗
  • 非ドメインエラー: メモリ不足（OOM） / ネットワーク障害 / NULLポインター参照

■ 3. C言語の時代 — 値としてのエラー

• C言語とUnix哲学においてエラーは「値」であり プログラムのロジックで処理するものとして扱われた
• 関数やプログラムは成功・失敗を数値で表現する（0なら正常 0以外なら異常）
• 利点:
  • シンプルな記述が可能
• 欠点:
  • 戻り値のチェックを忘れるリスクがある
  • 正常系と異常系のコードが混在する

■ 4. Exceptionの時代

• 概要:
  • C++ / Java / Python / Rubyなど現代主流の言語で採用される方式
  • 例外機構自体は以前から存在していたが 90年代の言語普及が広めた
• 利点:
  • 正常系と異常系のフローを分けて記述できる
  • 大域脱出するためチェック漏れのリスクがない
• 課題:
  • どこでどういう例外が発生するのかを関数シグネチャから把握できない
  • プログラム全体を見ないとハンドリング箇所が把握できず設計難易度が高い
  • スローされたまま誰もキャッチしない事態が生じる
  • 意図せず握りつぶされるリスクがある

■ 5. Javaの検査例外

• 概要:
  • 関数がスローしうる例外をシグネチャで明示する仕組み
  • キャッチして処理するかスローを伝播するかのどちらかを選ばないとコンパイルが通らない
  • 処理漏れをコンパイル時に防止できる
• トレードオフ:
  • 伝播コスト: 全呼び出し層でキャッチ・スローを記述する必要があり ラップしてリスローするコードが量産される
  • API変更への脆弱性: 例外の種類を増やすと呼び出し側全員がキャッチ処理を追加する必要がある
  • 高階関数やラムダ式など関数型記法との相性が悪い
  • 失敗可能性の明示と失敗からの回復可能性は別問題であるという本質的な課題がある

■ 6. Goのエラーハンドリング — 値への回帰

• 概要:
  • 2009年に登場したGoはエラーを値として返す古典的方法を意図的に選択した
  • "Errors are values" — Rob Pike の思想が基盤にある
• 設計思想:
  • 例外は使用しない（panicは回復不能な異常時のみ使用）
  • エラーは日常的な事象であり 特別な制御構造ではなく通常の値として扱う
  • 常にその場で処理するか 呼び出し元に返すかを明示する
  • 「魔法を減らせ」という哲学に基づく
• 値リターンへの回帰の理由:
  • Exceptionはシグネチャに現れず制御フローが追いにくい
  • throw元とcatch先が離れるためデバッグが困難（"Cleaner more elegant and wrong" — Raymond Chen）
  • 暗黙の大域脱出が隠れており制御フローの把握が難しい
  • ドメインエラーはロジックで処理し 非ドメインエラー（OOM / NPE）は大域脱出とする使い分けが可能
  • gotoと同様に例外だけを特別扱いする設計への疑問

■ 7. オフトピック: Clean Codeの見解

• 『Clean Code』の著者は値リターンはコードの可読性を下げるためお勧めしないと記している
• 正常系がストレートに読める方がコードの意図が掴みやすいとされる
• ただしイディオムの違いによる可読性の議論は宗教論争になりがちである

■ 8. 型によるエラー表現

• 概要:
  • Rust / Haskell / Scala / Swift / Kotlinなど近年の言語で採用される方式
  • 失敗する可能性を型システムで表現する（例: Result<String, Error>）
  • 成功値または失敗値のどちらかが返ることが型レベルで保証される
• 値としての扱い（Go）vs 型としての扱い（Rust）の違い:
  • Goの値: errを無視してもコンパイルは通り チェックは開発者の自己責任
  • Rustの型: Resultを開かないと中身を使えず コンパイラが処理を強制する
• Result型のハンドリング（Rust）:
  • matchで全パターンを網羅しないとコンパイルエラーとなる
  • Okケースのみ記述してErrを省略するとコンパイルエラー
  • 「処理し忘れ」がそもそも起こりえない構造になっている
  • 意図的に捨てることは可能（let _ = read_file();）
  • Javaの検査例外と異なり どの階層で処理するかは開発者が自由に選べる
• 型によるエラー表現の特徴:
  • うっかり無視はできないが意図的に捨てることはできる
  • Java検査例外: 各階層に「処理または宣言」を強制
  • RustのResult: 失敗の可能性を示すが どこで処理するかは自由
  • コンパイラが処理漏れを検出できる（例外より明示的）
  • エラーを合成でき関数型との相性が良い
  • 記述量が増える場合がある

■ 9. まとめ

• エラー処理の仕組みと思想は言語ごとに異なる
• 最近の言語トレンドはエラーを型で表現する方向に向かっている
• それぞれの特性を理解して正しく向き合うことが重要
• エラー処理に銀の弾丸はない

(2026/05/04)

AIが週報をつまらなくした。週報のフォーマットを大幅改訂しました

• AIが週報をつまらなくした。週報のフォーマットを大幅改訂しました｜山田裕一朗（CEO at Findy Inc.）

要約:

■ 1. 週報の目的と背景

• FindyではAI活用以前から全スタッフに週報を義務付けている
• 週報の目的は2つある
  • 経営陣が現場の解像度を維持し意思決定の質を高めること
  • メンバー個人の振り返りと成長の機会を創出すること
• 近年AI生成と判別できる週報が増加し読む価値が低下している

■ 2. AIによる週報の問題点

• AI生成週報に共通する問題点は以下の通り
  • カレンダーの予定やNotionのメモ・GitHubイシューをまとめただけの内容になっている
  • 不必要に長く読むのが困難
  • 経営が必要とする個人の考えや気づき・現場の一次情報が欠落している
• AIによる業務整理自体は問題ないが週報そのものになると読む価値がほぼなくなる

■ 3. 良い週報の共通点

• 顧客・ユーザーの生の声が含まれている
• 新技術や施策を試した体験と結果が記述されている
• これらはAIには生成不可能な書き手固有の情報である

■ 4. 新フォーマットの構成

• (1) 今週の印象的な出来事・気づき:
  • 現場でしか捉えられない一次情報として冒頭に配置する
  • ユーザーの声・商談・新技術体験など内容は問わない
• (2) 経営とマネジメントの気づき:
  • 出来事から経営・マネジメント視点での解釈を記述する
  • 「なぜ起きたか」「市場や技術として言えること」「組織・事業として何をすべきか」を問う
  • (1)と(2)についてはAIを使わず自分で書き切ることを推奨する
• (2) 数字・進捗:
  • 営業・プロダクト・エンジニアリングなど自分の仕事に紐づく数字を記載する
  • 全ての仕事に数字が存在するという認識を全員に持たせる意図がある
• (4) 個人の振り返り:
  • 今週の学びと来週の変化を短く記述する

■ 5. 改訂の目的

• 経営への効果:
  • 冒頭から現場の一次情報と思考プロセスを取得できるようにする
  • メンバーの体験と気づきを通じ経営陣の現場解像度を向上させる
• 個人成長への効果:
  • 毎週「数字」「印象的な体験」「経営・マネジメントの気づき」を問い続けることで習慣化する
  • 現場体験から気づきを引き出す能力が積み上がり長期的な成長につながる

■ 6. AIと週報に関する方針

• 業務効率化にAIを活用すること自体は推奨する
• 週報は「自分がどう考えたか」を残す場所として位置づける
• AI時代だからこそ思考の痕跡を残すアウトプットの価値は高まる
• 全員が現場体験から経営・マネジメントの気づきを発見する習慣を醸成し会社全体の意思決定の質向上を目指す

(2026/05/03)

AI時代のエンジニアに必要なパラダイムシフト － 自己否定の先にあるもの

• AI時代のエンジニアに必要なパラダイムシフト － 自己否定の先にあるもの - NRIネットコムBlog

要約:

■ 1. AIによる「知識の価値」の変容

• フレームワークの使い方・設計パターン・言語への精通・ベストプラクティスといった従来の技術知識はAIが即座に再現可能になった
• 「知っている」こと自体の価値が急速に薄れている
• ビッグテックCEOの発言がこの変化を裏付ける:
  • Google CEO Sundar Pichai: 2024年10月にGoogleの新規コードの25%以上がAI生成と発言
  • Meta CEO Mark Zuckerberg: 2025年中にミッドレベルエンジニアの仕事をAIが代替し始めると予測
  • Anthropic CEO Dario Amodei: 3〜6ヶ月以内にAIがコードの90%を書くようになると予測し同年10月にAnthropic社内での実現を述べた

■ 2. 従来のパラダイムと新しいパラダイムの対比

• 従来のパラダイム:
  • 価値の源泉: 技術力（書く・知る・解く）
  • エンジニアの役割: 手を動かす職人
  • 評価の尺度: どれだけ良いコードを書けるか
• 新しいパラダイム:
  • 価値の源泉: 課題設定力・判断力・実行力（定義する・見抜く・届ける）
  • エンジニアの役割: AIを指揮して実現する人
  • 評価の尺度: どれだけ大きな課題を解決できるか

■ 3. AI時代に価値が増す3つの力

• 課題設定力（何を作るべきかを定義する力）:
  • AIの出力品質は入力の品質に完全に依存するため問いの質が成果を決定する
  • 現場を知り人と話し判断できる人間にしかできない
  • ドメイン知識・ユーザーとの接点・技術的実現可能性の感覚・課題の構造化能力が基盤となる
• 判断力（AIの出力の良し悪しを見抜く力）:
  • AIモデルは確率的にもっともらしい出力を返す統計的機械であり正しさを保証する仕組みを内部に持たない
  • 過去の障害対応経験・ユーザー行動の観察・ステークホルダーとの会話の蓄積が判断力の土台となる
  • 判断力はレビューと方向修正に使うものであり自分で書き直す理由にしない
  • 例外として軽微な修正・AI利用コスト制約・AI障害時は自分で実装する場合もある
• 実行力（実現してユーザーに届けきる力）:
  • インフラ構成・ステークホルダーとの合意形成・障害時の判断・フィードバックによる方向転換は人間の仕事
  • 粘り強くやり抜く力・人の感情を汲み取る力・不確実な状況での責任を引き受ける力が含まれる

■ 4. 自己否定（Self-Disruption）の概念と必要性

• 「自己否定」はSelf-Disruptionの意味で使用する:
  • 競合や市場に破壊される前に自らの既存の成功モデルを能動的に壊すビジネス戦略の概念
  • NetflixがDVD事業を捨ててストリーミングに転換しAppleがiPodを潰してiPhoneを生み出した事例が代表例
• 著者が否定した信念:
  • 「自分の手で書いたコードに価値がある」→ コードの価値は誰が書いたかではなく何を解決するかで決まる
  • 「深い技術知識が優秀さの証明」→ 優秀さの尺度はAIを活用して成果を出せるかに移りつつある
  • 「AIより自分の方がうまく書ける」という判断で手を動かす習慣→ 方向修正のフィードバックとしてAIに返すべき
• 否定しなかったもの:
  • 課題設定力・判断力・実行力はむしろ価値が高まっている
  • 技術知識の活かし方を「自分で書く」から「AIの出力を横断的にレビューし方向修正する」へ再定義した
• 自己否定は一回きりのイベントではなくAIの能力進化に合わせて継続的に自分の価値を問い直す姿勢そのもの

■ 5. ローカルAIエージェントと技術進化

• オンラインAIエージェントとローカルAIエージェントの違い:
  • オンラインAI（ChatGPT・Claude Webなど）: ブラウザ・チャット画面越しに使用しハーネス・エンバイロメントは提供側に固定される
  • ローカルAI（Claude Code・Codexなど）: PC内のファイルシステムへ直接アクセスし自律的に動作する
• Claude Codeの自律性が著者の自己否定の触媒になった:
  • 「書く→動かす→失敗を見て直す」ループを人間の介在なしに回す
  • コードベース全体・プロジェクト固有の文脈を取り込んで自己修正できる
• AI活用の技術進化の変遷:
  • ～2024年頃: プロンプトエンジニアリング（どう指示を書くか）
  • 2024〜2025年頃: コンテキストエンジニアリング（RAG等で背景情報をどう教え込むか）
  • 現在以降（並列の対）:
  • ハーネスエンジニアリング: AIエージェントのランタイムをどう構成するか（パーミッション・フック・MCP・CLAUDE.md等のプロセス内設計）
  • エンバイロメントエンジニアリング: AIエージェントが動く世界をどう囲うか（OSユーザー・サンドボックス・ネットワーク制御等のプロセス外設計）

■ 6. 個人としての行動変容

• コードはAIに書かせて自分は「定義」と「判断」に集中する:
  • 課題の定義・要件の構造化・AIへの指示と出力のレビューが業務の中心になった
  • 同じ時間でカバーできる範囲が大きく広がった
• T型スキルセットから「面で動く」スタイルへ:
  • フロントエンド・バックエンド・インフラ・DB・セキュリティ全領域にAIを通じて指示を出せる理解と判断経験が必要
  • 詳細仕様知識ではなく本質を押さえた上でAIを使いこなせる経験値が求められる
• 考え込む前に作って検証するサイクルへ移行:
  • 従来: 2週間で設計を固め2週間で実装し合わなければ手戻り
  • 今後: 1時間で仮説を立ててAIに実装させ動くものを見て検証し方向転換するサイクルを1日に何度も回す
• 「自分にしかできない仕事」を問い続ける:
  • AIにできること（CRUD実装・テスト・ドキュメント・バグ調査の一報）はAIに任せる
  • 自分の時間はユーザーとの課題発見・事業戦略と技術戦略の接続・技術的意思決定のリード・障害時の最終判断に使う

■ 7. チームとマネジメントへの影響

• チーム構造の変化:
  • 従来10人で担っていたプロダクト開発を2〜3人のエンジニアがAIと協働してカバーできる
  • 少数精鋭のチームでは一人ひとりが課題設定力・判断力・実行力を高いレベルで持つ必要がある
• マネジメントの焦点の変化:
  • 工数見積・タスク割り振り・進捗管理→課題の優先順位づけ・「何をAIに任せ何を人間がやるか」の設計・アウトプットの品質レビューへ移行する
• 評価基準の再定義:
  • コード量・コミット数・資格数による評価は不十分になる
  • 新しい評価基準: インパクトある課題の定義・AIの出力の品質担保・仮説検証の速さ・チームのAI活用レベルへの貢献
• ジュニアエンジニア育成の課題:
  • AIがジュニアレベルのタスクをこなすようになると経験を積む機会が減るという構造的課題がある
  • 「AIが書いたコードをレビューすること自体を学習の場にする」アプローチが判断力育成に有効な可能性がある
  • コードそのものよりも判断の根拠を共有するチーム文化が従来以上に重要になる

■ 8. AIには決められない「何を実現すべきか」

• AIはコードの速度・品質で人間を上回る場面が多いが「何を実現すべきか」を自分では決められない
• 課題設定力で良い問いを立て・判断力で出力を正しく見極め・実行力で届けきる人間がAI時代に最も価値を持つ
• AIが実装を担うことでエンジニアは「何を作るべきか」「なぜ作るのか」「本当にユーザーの課題を解決できているか」というより本質的な仕事に集中できる
• 自己否定とは立ち止まることではなく自分が積み上げてきたものを見つめ直し変化すべき部分を見極めて次に進むこと

(2026/05/02)

品質の言語化のススメー早期テストの原則をClaude Code Agent Skillsで実現する試み

• 品質の言語化のススメー早期テストの原則をClaude Code Agent Skillsで実現する試み - LayerX エンジニアブログ

要約:

■ 1. 概要

• LayerX QAエンジニアによるClaude Code Agent Skillsを活用した品質管理の取り組みの紹介
• AIコーディングアシスタントの普及に伴い「どこまで厳密なエラーハンドリングが必要か」「テストはどの程度書くべきか」という課題が発生
• バクラク事業部の品質定義・テスト戦略を言語化しClaude Codeにリスクの高い箇所を保護させテストを同時生成させる試みを実施

■ 2. 早期テストの原則

• JSTQB FLシラバスに定義されるテストの原則の1つ「早期テストで時間とコストを節約する」を基盤とする
• プロセスの早い段階で欠陥を取り除くことで後半に発生する故障が減少し品質コストが削減される
• テスト実行のみならず要件レビューや質問といった活動も含む
• 欠陥の予防が最もコスパが高くアジャイル開発とも親和性が高い
• この原則をClaude Codeの動作に適用することを目指す

■ 3. Skillsに組み込む判断基準

• AIによる予防を実現するため以下の3つの判断基準を言語化:
  • 目指す品質
  • 目指す品質を判断するためのリスクと基準
  • 自動テストのスコープ
• 上記定義によりAIが以下を思考・実行可能になる:
  • 今目指すべき品質のゴールの把握
  • 今守るべきリスクの特定
  • リスクに応じた実装基準の決定
  • 各自動テストで担保すべきスコープの特定

■ 4. 判断基準の言語化

• 目指す品質:
  • バクラクはセンシティブな情報を預かるプロダクト群であり一定以上の品質水準の維持が必要
  • プロダクトのフェーズごとに「バクラク事業部が目指す品質」を定義
  • 市場へのリリースでフィードバックを集めるフェーズと運用中フェーズで優先すべき品質の側面が異なる
• リスクと基準:
  • バクラク事業部ではコンパウンド戦略を採用し複数プロダクトそれぞれに固有のリスクが存在
  • severityの度合いとその影響範囲をまとめたリスク情報をプロダクトごとにskills上で定義
  • 特定期間ごとにチームでリスク定義をアップデートする習慣が社内に確立済み
  • リスク情報に基づきカバレッジの基準を決定
• 自動テストのスコープ:
  • テストピラミッド戦略として自動テストの各レイヤーで検証すべき内容をLayerX社内で定義済み

■ 5. Claude Codeへの統合と動作

• 言語化した情報をClaude Code Agent Skillsとして実装
• フェーズ判断:
  • タスク内容からプロダクトのフェーズを判断
  • 不明な場合はHITL(Human In The Loop)でユーザーに質問
• リスク評価:
  • 機能カテゴリを参照しリスクレベルを評価
  • compaction(コンテキスト肥大化・圧縮による精度低下)防止のため開発対象プロダクトのリスク情報のみを読み込む設計
• 基準の適用:
  • 判断したフェーズとリスクレベルに基づき実装方針・テスト戦略(カバレッジ目標)・コーディング規約を自動適用
• 用途は製品開発のみならずテスト計画・設計・自動テスト整備相談にも対応

■ 6. 実施結果

• skill-creatorのEvalsを使って効果測定を実施し改善効果を確認
• リスクが高い機能開発:
  • Claude Codeが自らリスクの高さを判断しトランザクション管理・ロールバック処理を含む堅牢なコードを生成
  • 定義した基準のユニットテストカバレッジを達成
• テストカバレッジの比較:
  • スキルなし: 65%
  • スキルあり: 95%

■ 7. 結論

• AIがコードを書く時代において人間の役割は「あるべき姿を定義(言語化)すること」へシフト
• 暗黙知になっている品質の姿を言語化しAIに組み込むことでQuality Harnessとして機能させフィードバックループを加速可能
• モデル性能向上に伴いスピードと質が向上する世界において品質のポイントを押さえることの重要性を強調

(2026/05/02)

「Copy Fail」CVE-2026-31431 — 9年間潜んでいた732バイトPythonでLinuxがroot化される脆弱性と対策

• 「Copy Fail」CVE-2026-31431 — 9年間潜んでいた732バイトPythonでLinuxがroot化される脆弱性と対策｜zephel01

要約:

■ 1. 脆弱性の概要

• 名称はCVE-2026-31431（通称「Copy Fail」）
• 2017年以降のほぼすべての主要Linuxディストリビューションに影響するローカル権限昇格の脆弱性
• 732バイトのPythonスクリプト一つでroot権限を取得可能
• 2017年のカーネルコミット導入から9年間発見されずに潜伏していた

■ 2. 技術的詳細

• 原因:
  • Linuxカーネルのcryptoモジュール（algif_aead）に2017年追加された「in-place最適化」のロジックバグ
• 攻撃手法:
  • AF_ALGソケットとsplice()を組み合わせ、任意の読み取り可能ファイルのpage cache（メモリ内キャッシュ）に4バイトを任意に書き換える
  • /usr/bin/suなどのsetuidバイナリをメモリ内で書き換えることでroot権限を即座に取得する
• 特徴:
  • ディスクへの書き込みが一切ないため再起動で自然に元の状態に戻る
  • race conditionやアドレスリークが不要
  • Ubuntu・RHEL・Amazon Linuxなど複数ディストリビューションで同一スクリプトが動作する
  • リモートからの直接攻撃は不可だが他の脆弱性と組み合わせた場合に深刻化する

■ 3. 影響範囲

• 対象環境:
  • 脆弱なコミット（72548b093ee3）導入以降の全主要Linuxカーネル（Ubuntu・Debian・RHEL・Fedora・Amazon Linux・SUSE・Archなど）
  • 4.14以前の旧カーネルは対象外
• 脆弱なバージョン（系列別の上限）:
  • 5.10系列：5.10.254未満
  • 5.15系列：5.15.204未満
  • 6.1系列：6.1.170未満
  • 6.6系列：6.6.137未満
  • 6.12系列：6.12.85未満
  • 6.18系列：6.18.22未満
  • 6.19系列：6.19.12未満
• 特に危険な環境:
  • 共有サーバー
  • Kubernetesコンテナ（page cache共有によるホスト脱出が可能）
  • CI/CDランナー（GitHub Actionsなど）
  • クラウドのサンドボックス環境

■ 4. コミュニティの反応

• X（旧Twitter）での状況:
  • 元投稿が数万ビューを超えvx-undergroundなど著名アカウントが拡散
  • 「732バイトで全ディストリ即root」「9年間潜伏したバグが怖い」「AIが発見したのが衝撃」という声が多数
  • 3000台規模での即時mitigation実施報告やコンテナ環境での危険性を指摘する実務報告が相次ぐ
• Reddit（r/linux・r/sysadmin・r/homelab・r/Proxmoxなど）での状況:
  • Ubuntu 24.04でのPoC実行によりsuが実際に書き換わったという報告が殺到
  • 共有ホスト・K8s・CI/CD環境での深刻性を指摘する声が目立つ
  • CVSS 7.8に対するModerate評価の妥当性に疑問を呈する議論も発生
  • algif_aead無効化コマンドのワークアラウンドが広く共有される

■ 5. 修正状況

• 修正コミット：a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5（crypto: algif_aead - Revert to operating out-of-place）
• mainlineでは7.0-rc7以降に取り込み済み
• 各ディストリビューションで2026年4月29〜30日時点からバックポートが順次提供開始

■ 6. 対策

• 最優先：カーネル更新:
  • パッチコミットa664bf3d603dが含まれるカーネルへ更新する
  • Ubuntu/Debian系：sudo apt update && sudo apt upgrade linux-image-$(uname -r)
  • RHEL/Fedora/Amazon Linux系：sudo dnf update kernel
  • 更新後に再起動しuname -rでバージョンを確認する
• 緊急ワークアラウンド（パッチ未適用時）:
  • algif_aead モジュールを無効化する
  • echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
  • rmmod algif_aead 2>/dev/null || true
  • dm-cryptやIPsecなどの通常利用への影響はほぼない
• 追加対策（コンテナ・CI環境推奨）:
  • seccompフィルタでAF_ALGソケット作成をブロックする
  • unprivileged user namespaceを無効化する（sysctl -w user.max_user_namespaces=0）

(2026/05/01)

Before GitHub

• Before GitHub | Armin Ronacher's Thoughts and Writings

要約:

■ 1. GitHub以前のオープンソースの姿

• SourceForge・Trac・Subversionが主要な開発基盤であり 開発者自身がサーバを運用するのが通常であった
• プロジェクトには固有のウェブサイト・メーリングリスト・リリースプロセスがあり 依存関係の追加には相当な調査と理解が伴った
• 評判と実績が信頼の基準として機能し 長期にわたるメンテナンスの継続が重視された
• 小規模プロジェクトは大学サーバや共有インフラ上に置かれ 大規模プロジェクトは自前のインフラを維持するか複数プロジェクトが連合して運用コストを分担した
• MercurialやGitの登場により分散型バージョン管理が普及したが 皮肉にも一極集中型のGitHubが標準プラットフォームとなった

■ 2. GitHubがオープンソースにもたらしたもの

• プロジェクトの作成・発見・コントリビューションの障壁を大幅に引き下げた
• イシュートラッカー・プルリクエスト・CI・Webhook・APIなどの開発インフラを一元提供した
• オープンな開発履歴と可視化されたコラボレーションを業界標準として定着させた
• 放棄されたプロジェクトを含む膨大なコードを検索可能な状態で保存する事実上のアーカイブとして機能した
• 制裁対象国へのアクセス維持に尽力するなど 歴史的には開放的な姿勢を示した

■ 3. 依存関係の爆発的増加とその問題

• GitHubとnpmの組み合わせにより コードの公開・消費・依存が事実上コストゼロになった
• GitHub以前は依存関係の選択において評判・寿命・ベンダリングが自然なフィルタとして機能していた
• マイクロ依存関係の急増により パッケージグラフが人間の把握能力を超えて拡大した
• GitHubはnpmなどのレジストリへの信頼できる公開経路としても機能するようになり サプライチェーン文化の中核を担った
• GitHubへの信頼が低下することはソースホスティングだけでなくサプライチェーン全体に影響を及ぼす

■ 4. GitHubの衰退と分散化の動き

• 現在のGitHubはCopilot AIによるノイズ・製品の迷走・不明確なリーダーシップ・コミュニティ軽視への批判に直面している
• エージェント型コーディングの台頭が組織に大きな圧力をかける一方でリーダーシップが不在の状態にある
• GhosttyのMitchell Hashimotoら影響力のある開発者がGitHubからの移行を表明し始めている
• StrudelやTenacityはCodebergへ移行しており 非GitHubプロパティへの訪問頻度が著者自身にも増加している
• Gitはもともと多数の拠点を想定して設計されており 単一企業への依存はGitの設計思想に反する

■ 5. 分散化のコストとアーカイブの必要性

• 分散化の進展はプロジェクトの自律性を回復し 特定企業の意思決定への依存を減らす
• 一方でコード以外の社会的文脈(イシュー・レビュー・設計議論・リリースノート・セキュリティ情報)は分散環境で失われやすい
• メーリングリストは現代のOSSニーズに対応できておらず代替としての機能を果たしていない
• 公的資金または寄付基金によって維持される中立的なOSSアーカイブ機関の設立が必要である
• アーカイブの目的は開発者生産性市場の獲得ではなく ソース・リリース成果物・メタデータ・プロジェクト文脈の永続的保存に限定すべきである
• Google CodeやBitbucketの前例が示すように 一企業への依存が終わった後にアーカイブ機能が自然発生することは期待できない
• 次世代のプラットフォームはプロジェクトの移行容易性・社会的文脈のミラーリング・リリース保存の堅牢性を設計原則とすべきである

(2026/04/30)

人間レビューはもう不要？ AI と人間のレビューの線引きを決めた話

• 人間レビューはもう不要？ AI と人間のレビューの線引きを決めた話 | Acsim

要約:

■ 1. 背景と課題

• AI駆動開発によりコード生産量が急増した一方で人間のレビュー時間は変わらずPRのスタックが問題となった
• 「最低1人からApproveをもらう」ルールにより数時間待った末にnitpickレベルの指摘を受けて修正・再依頼するという非効率な状況が常態化していた
• すべてのPRに人間レビューを必須とすることの合理性が問い直されるようになった

■ 2. One-Way Door / Two-Way Door フレームワーク

• Amazonの創業者Jeff Bezosが株主への手紙で示した意思決定の分類フレームを採用した
• 基本方針:
  • One-Way Door（戻れない決定）: 慎重に審査する
  • Two-Way Door（戻れる決定）: 速く判断する
• 代表的なOne-Way Door例はデータベース設計であり スキーママイグレーションやデータマイグレーションに多大な工数がかかる
• フロントエンドのUI変更やAPIスキーマの改修などはTwo-Way Doorに該当し少ない工数で方針変更が可能
• PRの大半はTwo-Way Doorであり人間レビューを必須とする合理的理由はないという仮説を立てた

■ 3. セルフマージガイドライン

• 判定の軸: 「その変更は容易にやり直せるか」で決まる
• 人間レビュー必須の対象（特定領域・パス指定）:
  • DBスキーマ・マイグレーション（カラム削除や型変更はデータ消失を伴い本番適用後のDDLロールバックも困難）
  • RLSポリシー（設定ミスが即座に全テナントへ波及しセキュリティインシデントにつながる）
  • 認証・認可（認証バイパスやセッション漏洩はrevertしても被害が残る）
  • インフラ（IaC）・CI/CDのデプロイ系ワークフロー
  • AI基盤設定・リリース制御・依存関係のMajorアップデート
• 人間レビュー必須の対象（アプリケーション全体に波及する変更・性質指定）:
  • 基盤ライブラリの追加・置換（フレームワーク・ORM・AI基盤・認証基盤など）
  • マネージドサービスの追加・変更
  • ミドルウェア構成・エラーハンドリング戦略・ロギング基盤などの横断的関心事
  • モノレポ構成の変更
• 例外: Design Docs・ADR・コーディング規約などチーム合意を伴うドキュメントはOne-Way Doorではないが人間レビューを必須とする（合意形成プロセスを経ない更新を防ぐため）
• 上記に該当しないものはTwo-Way Doorとみなしてセルフマージ可とし 判断に迷った場合は人間レビューを選ぶことをデフォルトとする

■ 4. Claude Code Actionによる自動判定

• PR作成時にClaude Code Actionがガイドラインと差分を読み込みセルフマージ可否をコメントで投稿する
• 判定結果は「セルフマージ可」「人間レビュー必須」のいずれかで根拠となるガイドライン該当項目と該当ファイルもあわせて提示される
• PR作成者もレビュアーもその場でセルフマージの可否とその理由を把握できる
• 判定が誤っていると感じた場合はPR作成者がコメントで反論したりガイドライン自体を更新したりできる
• Claude Code Actionの判定はあくまで判断の拠り所であり最終決定権は人間にある

■ 5. 導入効果（運用開始後2週間）

• セルフマージ判定結果:
  • 159件中80%（127件）が「セルフマージ可」と判定された
  • 事前想定（約2/3）を上回る比率でセルフマージが適用可能であった
• リードタイム改善:
  • p90リードタイムが過去13週の132〜316hのレンジから直近週は92hに短縮された（約30〜70%削減）
  • 24h以内マージ率が48〜68%から77%に向上した
  • 中央値は1.7hとなりほとんどのPRが同日中にマージされる状態に近づいた

■ 6. リスク対策

• Design Docによる事前合意:
  • 新規機能開発時に機能要件と技術的な設計の両方をDesign Docにまとめて1つのPRで人間レビューを必須とする
  • POからビジネス要求のApproveを Devメンバーからエンジニアリング判断のApproveをそれぞれ取得する
  • 事前すり合わせにより以後の開発をほぼセルフマージで進めつつ要件や実装方針のブレリスクを抑制できる
• ドキュメントの剪定:
  • AIレビューの精度はチームのドキュメント品質に強く依存するためドキュメント管理を整備する
  • AI自身がドキュメントを書くようになり1ファイル1000行近くに達するものも出てきたため扱いづらくなっていた
  • ドキュメンテーションガイドラインを策定しAgent Skillsでリポジトリ全体を継続的に剪定する仕組みを整えた
• AIレビューの拡張:
  • 既存のDevin Review・CodeRabbit・CopilotにClaude Code Actionによるコードレビューを追加した
  • Claude Code Actionはプロンプトを細かく指定できSub Agentを並列に動かして観点を独立して増やせる点が優れている
  • AIレビューが過剰になったり的外れなコメントが続いたりすると開発者が疲弊してスルーするリスクがある
  • AIレビューの精度や指摘傾向を継続的に観測して改善するループを設計中である

■ 7. 結論

• 人間レビュー必須のルールはコードを人間が書いていた時代に作られたものでありAI駆動開発の現在では見直しが必要
• One-Way Door / Two-Way Doorの考え方でAIと人間のレビューを線引きし判定をClaude Code Actionに委任することでPRの約8割が人間レビューを介さずマージできるようになった
• p90リードタイムは過去13週のレンジと比較して約30〜70%短縮され開発者はレビュー待ちなく次のタスクに着手できる状態となった
• AI駆動開発の中では開発プロセスのあらゆる前提が問い直し対象となり引き続き仕組みのアップデートを続ける方針である

(2026/04/29)

はてな株に売り殺到、終日値付かず　“11億円流出”ショックで

• はてな株に売り殺到、終日値付かず　“11億円流出”ショックで - ITmedia NEWS

ブログサービスなどを運営するはてな（京都市中京区／東証グロース）の株価が4月27日、値幅制限の下限（ストップ安）水準の881円で売り気配のまま推移し、終日値が付かなかった。同社が前週末に発表した、不正な送金指示による最大約11億円の資金流出事案が嫌気された。

前週末24日の終値は1181円で、27日のストップ安水準は300円安の881円。同日は寄り付きから売り注文が積み上がり、買いが追いつかなかった。

売り材料となったのは、24日に開示した資金流出事案だ。4月20日と21日、悪意ある第三者から虚偽の送金指示に従い、従業員のアカウントから銀行預金を外部の口座に送金していた。

同社の2026年7月期通期業績予想は、売上高38億5900万円、営業利益1億3600万円。最大被害額は、通期営業利益予想の約8倍に相当する規模だ。

同社は手元の運転資金について「十分な流動性を確保しており、事業運営や資金繰りに支障はない」と説明。業績への影響は「精査中」としている。

MEMO:

• はてながこの先生きのこるには

(2026/04/28)

hotchpotch/sqlite-vaporetto: SQLite FTS5 extension for fast Japanese full-text search

• GitHub - hotchpotch/sqlite-vaporetto: SQLite FTS5 extension for fast Japanese full-text search with 🛥Vaporetto / Vaporetto による高速な日本語全文検索を SQLite FTS5 で実現する拡張機能 · GitHub

Vaporetto を利用した、SQLite 向けの高速な日本語全文検索拡張です。

sqlite-vaporetto は FTS5 用の SQLite loadable extension です。 vaporetto という tokenizer を追加し、SQLite が index する前に日本語テキストを検索に適した単語へ分割します。

SQLite の FTS5 は小さくポータブルな全文検索エンジンで、Vaporetto は高速な日本語 tokenizer です。sqlite-vaporetto はこの 2 つを組み合わせ、通常の SQLite database の中で、単語単位の日本語 tokenization、ASCII の大文字小文字を区別しない検索、MATCH query、bm25() ranking、highlight() を使えるようにします。

(2026/04/28)

「FILCO」のダイヤテック閉業、予兆はあった？ ファンアカウントが見たここ半年の「異常な動き」とは

• 「FILCO」のダイヤテック閉業、予兆はあった？ ファンアカウントが見たここ半年の「異常な動き」とは【やじうまWatch】 - INTERNET Watch

FILCOブランドで知られたダイヤテック社の突然の閉業について、この半年間にみられた同社の異常な動きを、ファンアカウントが動画でまとめている。

4月22日にホームページ上で突如発表された同社の事業終了は驚きを持って迎えられたが、詳しい理由やブランドの今後などについては触れられておらず、すべてが謎のまま。そんな同社について、ファンアカウントであるYouTubeの「勝手にFILCOコレクション」が、昨年からの同社の異常な動きについてまとめている。

それによると、同社は昨年後半からこれまでにないほどの破格のセールを連発し、年明けには「単位がおかしい、価格がおかしい」と銘打った在庫一掃セールを実施。それらが一区切りついた2月にはYahooダイレクト店がリニューアルと告知しつつ事実上の閉店。また、ダイレクトショップは3月に入ってから在庫が枯渇し、3月18日にはメンテナンスの告知が掲載されるも以後改善されることなく、4月中頃にはサポートページのお問い合わせフォームが閉鎖され、今回の事業終了の発表に至ったとしている。このほか、ほぼ毎日行われていた公式Xアカウントの投稿も3月6日を最後に中断しており、同社の動きを注意深く観察していれば何かが起きていると分かる予兆はあったようだ。

関連:

• 「FILCO」「Majestouch」のダイヤテックが閉業

(2026/04/27)

COBOL技術者に汎用機の話を聞いて「え、全然汎用じゃないじゃん。どちらかというと専用機...

COBOL技術者に汎用機の話を聞いて

「え、全然汎用じゃないじゃん。どちらかというと専用機に近い（Win、Linuxのオープン系と比較した場合）」

って言ったら

「おまえ全然わかってない。汎用の意味を」

と言われたから

「例えば自分はPerlでCPANモジュール読み込んでサクッとWebサーバ作れますよ？COBOLでできますか？」

と言ったら

「Webサーバ？何だそれは？っていうかCOBOLはPerlではない。Perlの話を持ち出すな」

と否定するばかりで理解しようとせずに自分の中の「汎用」を無意識のうちに守りに入っていた

25年前のIT業界はこういうタイプの人が大量に先輩として存在していた

@ebiebi_pg

MEMO:

• COBOLが動作する汎用機/メインフレームというのは、それ以前のコンピュータが特定用途の計算に特化した専用機であったことへのセールスポイントとしてプログラムを交換するだけであらゆる用途の計算ができる（汎用計算機）ということ
• WindowsやLinuxはその汎用機の更に進化版（かつ廉価版）
• パイセンはその程度はサラッと答えて欲しいところである

(2026/04/26)

ハーネスエンジニアリングとは？

• ハーネスエンジニアリングとは？ - Speaker Deck

要約:

■ 1. 概要

• 本資料はKinopee（きのぴー）による「ハーネスエンジニアリングとは何か」をテーマとした発表スライドである（2026年4月24日）
• ハーネスエンジニアリングという概念には複数の流派が存在し、論者によって定義と重心が異なる
• 資料はハーネスエンジニアリングの5つの流派の整理と、ハーネス・ガードレール・フィードバックループの実践的解説の2部構成をとる

■ 2. ハーネスエンジニアリング 5つの流派

• Chase派（広義・分類論）:
  • 代表者はHarrison Chase（LangChain創業者）
  • 出典は2025年10月のブログ記事「Agent Frameworks, Runtimes, and Harnesses」
  • 原器はDeepAgents（LangChain）
  • framework / runtime / harness の三分類を提示し、モデル以外のすべての構成要素（ツール・メモリ・サブエージェント・ガードレール・オーケストレーション・リトライ・状態管理）をハーネスに包含する
  • ハーネスは「コンテキストを生成する外側の層」であり、コンテキスト設計はその一構成要素として位置づけられる
  • 代表フレーズは「If you're not the model, you're the harness.」（Vivek Trivedy）
• Hashimoto派（運用哲学・失敗駆動）:
  • 代表者はMitchell Hashimoto（HashiCorp創業者）
  • 出典は2026年2月の自身のブログ記事で、OpenAI Codex事例と合わせて急速に普及
  • 原器はAGENTS.md / CLAUDE.md / .cursorrules
  • エージェントが失敗した際に同じミスが物理的に発生しないよう環境を再設計することを基本原則とする
  • AGENTS.mdに失敗防止ルールを一行ずつ追加していく「運用の累積」がハーネスエンジニアリングの実体である
  • ハーネスは設計物ではなく育てていくプロセスとして捉える
  • 日本の.cursorrules運用者と地続きであり、現場感覚に最も近い流派とされる
  • サイクルは「実行→失敗→AGENTS.mdへの追記→再発不能」の繰り返しである
• Fowler派（狭義ハーネス・制御理論）:
  • 代表者はMartin Fowler（Thoughtworks Distinguished Engineer）
  • 出典は2026年のThoughtworks記事「Harness engineering for coding agent users」
  • 原器はClaude Code / Cursor / Devinなどコーディングエージェント全般
  • 5流派の中で唯一、ハーネスをコンテキストの内側（特殊形）に位置づける
  • guides（feedforward制御：事前ルール・制約）とsensors（feedback制御：テスト・lint・事後検証）の両輪でエージェントを信頼に足るものにする
  • 「不要な出力を事前に防ぐ仕組み」と「逸脱を検知して自己修正させる仕組み」の組み合わせとして定義する
  • 制御工学の語彙（フィードバックループ・センサー）に接続する理論志向をとる
  • 代表フレーズは「ハーネス設計はコンテキスト設計の特殊な一形態である」
• Chawla派（同心円モデル・OS比喩）:
  • 代表者はAvi Chawla（Daily Dose of DS）および教育系ライター群
  • 出典は2026年前半「The Anatomy of an Agent Harness」ほか
  • 原器は特定ツールではなく概念モデル
  • プロンプト・コンテキスト・ハーネスを三重の同心円で整理する
  • Beren Millidge（2023）のOS比喩を継承し、LLMをCPU・コンテキストをRAM・ツールをデバイスドライバ・ハーネスをOSに対応させる
  • 定義の厳密さより初学者への説明しやすさを優先する立場をとる
  • Chase派と論理的には整合的だが、より図解寄り・入門記事向きの位置づけである
  • 代表フレーズは「LLMはOSなしの裸のCPUだ。ハーネスがOSに当たる。」（Beren Millidge）
• Codex派（スケール駆動・プロダクション答え）:
  • 代表者はRyan Lopopolo / OpenAI Codexチーム
  • 出典は2026年2月のOpenAI事例公表（エンジニア3名で百万行・95%AI生成）
  • 原器はOpenAI Codexおよびその内部ハーネス
  • プロンプト・コンテキスト設計では解決できない、多段ステップ・自律実行・並列処理に特有の故障モードが存在することを前提とする
  • それらの故障モードを解くものとしてハーネスを定義する（スケール駆動の動機づけ）
  • 他流派と直接対立せず、ハーネス概念が要請された背景と理由を提供する立場をとる
  • Prompt Engineering（2022年〜）→ Context Engineering（2024年〜）→ Harness Engineering（2026年〜）という進化の文脈で位置づける
  • 代表フレーズは「Agents aren't hard; the Harness is hard.」（Ryan Lopopolo）

■ 3. 流派間の対立構造

• 包含関係の逆転が流派間で最も劇的な噛み合わなさを生む
• Chase派・Chawla派の立場:
  • ハーネス ⊃ コンテキスト（ハーネスが外層、コンテキストを包含する）
  • 総合フレームワーク設計の視点
• Fowler派の立場:
  • コンテキスト ⊃ ハーネス（コンテキスト設計が外層、ハーネスはその特殊形）
  • 制御理論（feedforward / feedback）の視点
• 日本に紹介する際は、どちらの意味で語られているかを毎回明示する必要がある

■ 4. ハーネスとガードレールの定義

• ハーネス（馬具）:
  • 役割は走り出す前に「どう走ってほしいか」を伝える事前設計の層
  • 具体的な道具はカスタムインストラクション・プラン・Skills・サブエージェント
  • ハーネスは主観的な設計物であり、現場では名称がつく前から実践されてきた
• ガードレール（道を外れないための柵）:
  • 役割は走った後に「道から外れていないか」を機械で自動検証する事後検証の層
  • 具体的な仕組みは静的解析（lint・型チェック）・ビルド・テスト
  • ガードレールは客観的な機械判定であり、判定の強度がエージェントの自律性を高める鍵となる

■ 5. フィードバックループ

• ハーネス（馬具）とガードレール（柵）だけでは、エージェントは目的地にたどり着けない
• ループの構造:
  • 走らせる（エージェントにタスクをやらせる）
  • 逸脱を観察（期待からのズレを検知する）
  • 軌道を戻す（失敗を受けて修正・再実行する）
  • 上記を繰り返す
• 具体的な適用:
  • テストが落ちたら直させる
  • lintが出たら修正させる
  • 型が通らなければやり直させる

■ 6. 結論

• 言葉の定義の優先順位は低い
• 大切なのは期待した結果を得ることである
• ハーネス・ガードレール・フィードバックループのいずれも、今使える手段を総動員して適切な場所で適切に使い、良い結果を得ることが目的である

(2026/04/26)

再委託先ガバナンスの限界——IPA・ストーンビート指名停止が突きつけた「契約では守れない」時代

• 再委託先ガバナンスの限界——IPA・ストーンビート指名停止が突きつけた「契約では守れない」時代｜Vlightup | デジタルとリアルを繋ぐ、新しい信頼のカタチ -ブライトアップ株式会社

要約:

■ 1. 事件の概要

• 2026年4月10日、内閣官房が独立行政法人情報処理推進機構（IPA）に対し指名停止措置を公表
• 指名停止期間は2026年4月10日から同年9月9日までの5ヶ月間
• 対象契約は「令和7年度 独立行政法人等に対する監査業務の委託」
• 再委託先であるストーンビートセキュリティ株式会社が契約違反行為を行い、業務の一部について履行義務を果たさなかったことが「不誠実な行為」と認定されたことが原因

■ 2. 問題の構造

• 再委託先の管理:
  • IPAは内閣官房から受託した業務をストーンビートセキュリティ株式会社に再委託
  • 再委託先の契約違反が元請であるIPAの指名停止に直結
• 構造的矛盾:
  • IPAはセキュリティ分野の統括・監督機関であるにもかかわらず、自らがガバナンス上の問題に直面
  • 政府機関の監査業務という重要領域で管理体制の不備が露呈

■ 3. 本事件が示す課題

• 再委託先ガバナンスの限界:
  • 契約上の義務を課すだけでは再委託先の不誠実な行為を防止できない
  • 契約管理の複雑性と実際の業務遂行における乖離が顕在化
• 時代的示唆:
  • 「契約では守れない時代」という認識のもと、契約に依存しない新たなガバナンス手法の必要性が浮上
  • 企業グループ・委託チェーン全体での実効的な管理体制の構築が課題

(2026/04/25)

〇〇の人と言われたくて〇〇の人になった

• 〇〇の人と言われたくて〇〇の人になった

エンジニア界隈のイベントで、特定のOSSや手法をもって「〇〇の人」と呼ばれている人に強い憧れを持っていた。

自分もあるプロダクトのエバンジェリストとして小さな周辺の界隈ではあるが活動を続けて少しずつ「〇〇の人ですよね」と話しかけられる事が増えてきた。

憧れの「〇〇の人」が集まるようなカンファレンスにも呼ばれたりして「自分も憧れのネームドの仲間入りかな」と浮かれていた部分も正直かなりあった。

でも実態は違った。

実際会って話せるようになってみると、その「〇〇の人」達は技術に興味がない事がほとんど。

違う飲み会に行けば裏で「まあ、あの人はあぁいう人だから…」「上手く使えばイベントやってくれる」みたいに言われている。

ネームドではないけど技術力や仕事力がある人、ネームドだけど技術力や仕事力がある人、そこに割合の違いは無かったんだと気付いた。

で、自分もこのままじゃヤバいかもと転職エージェントに相談してみたんだけど「〇〇の人なんでその求人ですよね」という前提で話される。

話しても「もったいないですよ」と理解してもらえず、人生詰んでる。

絶対に外では言えないけど、正直プロダクトとして廃れて無かったことになってほしい。

みんなは、俺みたいなやつが二度と生まれないよう、後輩に現実を早く突き付けてあげて欲しい。

MEMO:

• 「〇〇の人」になれたのに転職エージェント使わなきゃいけないの侘しさある
• 〇〇界隈の企業からは声が掛からなかったのか
• みたいな事を思わなくもないが、この増田は高確率で嘘松
• 登壇経験があればGreenみたいな転職サイトに登録しておけばうんざりするほど企業からのスカウトが来る
• それに、あるプロダクトのエバンジェリストが別のプロダクトに乗り換えることは普通のこと
• 他人の過去なんて誰も気にしない
• 転職エージェントは所詮他人なので理解してもらえないなら別のエージェントに乗り換えるだけの話なので詰むという発想自体がおかしい
• ということで、創作増田であろう

(2026/04/25)

内閣官房から指名停止のIPA、再委託先デロイト傘下の不正な行為見つける

• 内閣官房から指名停止のIPA、再委託先デロイト傘下の不正な行為見つける | 日経クロステック（xTECH）

内閣官房が2026年4月に公表した指名停止措置の対象に、情報処理推進機構（IPA）の名があることがSNS（交流サイト）などで話題になっている。IPAが再委託先の契約違反行為を把握し、国家サイバー統括室へ報告したことが発端だった。委託先選定の難しさが浮き彫りになった。

MEMO:

• どういうことなのか？
• 詳細はペイウォールの向こうなので確認できず

(2026/04/25)

はてな、11億円の資金流出　振り込め詐欺か

• はてな、11億円の資金流出　振り込め詐欺か - ITmedia NEWS

インターネット関連事業を手掛けるはてな（京都市中京区）は4月24日、不正な送金指示によって約11億円の資金が銀行口座から流出したと公表した。第三者から虚偽の送金指示があったという。

4月21日に取引先銀行から不審な送金が行われていると連絡があり、確認すると4月20日と21日にある従業員のアカウントから銀行預金を外部の口座へ送金していた。その従業員に確認したところ、悪意ある第三者から虚偽の送金指示があったことが分かった。

はてなは、捜査機関へ全面的に協力するとともに、関係金融機関と被害回復に向けた措置を講じている。社内にも来栖義臣社長を中心とする対策本部を設け、外部の弁護士なども交えて事実関係の調査を進めるという。

なお、この事案に関連して個人情報や顧客情報の流出は24日時点で確認されていない。はてなの運転資金についても十分な流動性を確保しており、事業運営や資金繰りに支障はないとしている。

はてなは関係者や株主に謝罪。「本事案を極めて厳粛に受け止め、捜査へ全面的に協力するとともに、外部専門家を交えた事実関係の詳細な調査および原因の究明、再発防止策の策定を迅速に進める」としている。

MEMO:

• 11億円の振り込みを役員決済もなく従業員の独断で行えるものなのか？
• 従業員の横領がバレただけなのでは？

(2026/04/25)

Metaが、社員の1割である8,000人をクビにすると発表したが、残った社員のパソコンに、新しいソフト...

• Metaが、社員の1割である8,000人をクビにすると発表したが、残った社員のパソコンに、新しいソフトを入れ始め、社員のマウスやキーボードの動きを記録し、画面の中身も、ときどきスクショで取り、AIに学習させていた - posfie

もう少しかみ砕く。

たとえば、社員がメールを書いているとする。

どのキーを、どの順番で叩いているか。

マウスをどこに動かし、どのボタンをクリックしたか。

画面にどんな情報が映っていたか。

これらが、社員のパソコンから吸い上げられる。

そのデータを、会社のAIが受け取る。

じっと見て、学んでいく。

人間はこの仕事を、こう進めているのか、と。

それを毎日、大勢の社員ぶん、同時に繰り返す。

MEMO:

• 社員のアウトプットは企業が正当な権利として利用できるのだからAIの学習の為にキーロガーは必要無いような
• ただの監視では？

(2026/04/25)

「FILCO」「Majestouch」のダイヤテックが閉業

• 「FILCO」「Majestouch」のダイヤテックが閉業 - PC Watch

FILCOブランドのキーボード製品などで知られるダイヤテック株式会社が4月22日をもって事業を終了した。現時点で閉業の理由については明らかにしていない。

ダイヤテックは1982年に設立。自社ブランドのFILCOを展開し、「Majestouch」シリーズをはじめとしたキーボードや周辺機器などの製造/販売を行なっていた。

なお、閉業にともなって、通販やサポートの業務で取得/保有していた個人情報は、4月22日までに個人情報保護法や社内規定などに基づき、適切な方法で安全に破棄/消去したと説明している。

MEMO:

• なんてことだ
• とはいえ、メカニカルキーボード市場はそんな大きくも無いし苦しかったのだろうという事は伺える
• 自分も10年前に購入したFILCOのMajestouch青軸を未だに使っているぐらいなので、買い替え需要も起きにくい商品でもある

(2026/04/25)

なぜ、2000年代には巷で耳にした「UML」を現在では全く耳にしないのか？

• なぜ、2000年代には巷で耳にした「UML」を現在では全く耳にしないのか？

要約:

■ 1. UMLの起源と制度的背景

• UMLはラショナルソフトウェアが主導した標準化プロジェクトとして誕生した
• ブーチ法・OOSE・OMTなど複数の方法論を統一するための記法として設計された
• 当初から業務分析・要求管理・設計・実装・テストをまたぐ共通表現として位置付けられた
• 2003年にIBMがラショナルを買収しUMLはプロセス・製品・教育・監査・成熟度まで背負う存在となった
• この経緯により「UML」という語は重厚長大な印象と不可分に結びついた

■ 2. ファウラーによるUMLの再解釈

• ファウラーはUMLの使い方をスケッチ・ブループリント・プログラミング言語の三種に分類した
• 2000年代に「重いUML」として販売されていた本丸はブループリント用途であった:
  • 図を完全な設計書とし実装者がそれを機械的にコードへ写し取る立場
  • 設計者と実装者を分離しモデルから実装まで一気通貫で支配しようとする発想
• ファウラー自身はブループリント的立場を否定しスケッチを重視した:
  • 図は完全な仕様書ではなく重要な点だけを伝える会話道具である
  • 「網羅性は理解しやすさの敵」という立場を明言した
  • 役目を果たした図は捨ててよいと述べた
• ファウラーはコードを主文書と位置付けた:
  • コードのみが十分に詳細かつ正確である
  • 図はコードの理解や対話を助ける補助線にすぎない

■ 3. 2000年代の実務における実態

• 表向きの礼賛と実際の運用の間には当初から温度差があった
• 2007年調査ではUML使用率は52%にとどまり一様ではなかった:
  • モデリングツールは主に初期設計で使用された
  • コード生成は広く使われていなかった
• 問題点として図の品質・非形式的利用・モデリング規約の欠如が挙げられた
• 多くの現場は最初からクラス図やシーケンス図の一部のみを使い残りはフリーハンドの図で済ませていた
• UMLは「看板だけ巨大で実務は最初から部分利用」であったと見るのが実態に近い

■ 4. MDA(モデル駆動アーキテクチャ)の失敗

• MDAはプラットフォーム非依存モデルから実装コードまでを自動生成する構想であった
• UML制度の最大の約束手形は「図を正しく描けばコードは自動的に出てくる」であった
• 2007年調査が示した通り現場ではコード生成はほとんど使われなかった:
  • 生成されるのは骨組みだけで振る舞いは人間が記述する必要があった
  • 生成コードを手で修正するとモデルとの同期が崩れ二重管理が常態化した
• MDAの失敗はCASEツール・RUP・監査向け成果物・モデル中心教育の正当化根拠を根元から失わせた

■ 5. 2010年代の技術環境の変化とアジャイルの定着

• 変更速度を引き上げた三方向からの圧力が同時に加わった:
  • 供給側: AWS S3(2006年)を起点とするクラウドが環境調達の待ち時間を縮め小刻みな試行を可能にした
  • 需要側: iPhone(2007年)がモバイル対応を必須化しアプリストア・OS更新を通じて短い更新周期を市場から要求した
  • 運用基盤側: JenkinsによるCI/CDとGitHubを介したコードレビュー文化がコードの変更と検証を日次レベルで回す基盤を確立した
• アジャイルが能動的に勝ったのではなく市場と技術基盤の側がアジャイルの前提条件を満たした
• 2014年のState of Agile調査では回答者の90%が1年以上のアジャイル経験を持ち採用理由の上位は製品提供の加速・優先順位変更への対応・生産性向上であった
• 同調査でアジャイル案件の管理にMicrosoft Excelが68%使用されIBM Rationalは13%にとどまった

■ 6. UML制度の死の本質

• 死んだのは図そのものではなくUMLという制度である:
  • 図を完全な設計書にし設計者と実装者を分けモデルから実装まで支配しようとする発想が死んだ
• 二重管理は手間の増加ではなく情報の腐敗構造である:
  • コードが変わるたびに図を直す義務が生まれる
  • 直されなかった図は残り続け嘘をつき始める
  • 変更速度が上がるほど図の腐敗速度も上がる
  • 腐った図はないよりも悪い情報源であり新しい図を描く動機まで奪う
• 2010年代にUMLが聞かれなくなったのは図法が間違っていたからではなく維持費が便益を上回ったからである
• 「UML」という語がCASEツール・RUP・MDA・監査文化を連想させる重い語彙になったため現場が軽量化に向かうほど語自体が敬遠された

■ 7. UML制度が死んだ領域と生き残った領域

• UML制度の死は変更速度の高い領域に限定された現象である
• 機能安全・認証が絡む領域ではUMLの系譜は必須の位置を占めている:
  • 自動車組込み: ISO 26262
  • 航空: DO-178C
  • 医療機器: IEC 62304
  • これらの領域ではSysML・MATLAB/Simulink・Stateflowが必須の形式的記述として機能する
• 領域間の非対称性はリリース周期の長さで説明できる:
  • Web領域はリリース周期が日次・週次に短縮され図の維持費が便益を容易に上回る
  • 航空・自動車・医療はリリース周期が年単位で失敗時の損害が人命に直結するため二重管理が安全網として機能する
• 境界線は業界ではなくリリース周期の短さとモデル維持費の損益分岐点にある

■ 8. UML的図法の日常化という逆説

• Web領域でUML制度は死んだがUML的な図はむしろ日常に入り込んでいる
• MermaidはフローチャートからシーケンスÃ図・クラス図・状態図・ER図・C4図まで扱える
• PlantUMLもシーケンス図・ユースケース図・クラス図・状態図などを広くサポートしている
• GitHubではMermaidのレンダリングがIssues・Discussions・プルリクエスト・Wiki・Markdownファイルで利用できる
• Mermaid自身の主目的は「ドキュメントを開発に追いつかせること」であり図を開発速度に追随する軽量文書として扱う
• 死んだのはブランドとしてのUMLであり生き残ったのは図法としてのUMLの断片である:
  • 名称として避けられるようになったのはUMLという語が重い連想を持つ語彙になったからである
  • 実質としてはシーケンス図や状態図の記述機会はむしろ増えている

■ 9. まとめ

• UMLが2000年代に普及したのは単なる図法ではなく標準化・統合・管理可能性の象徴として売られたからである
• ファウラーが整理した軽いUMLと市場が売り続けた重いUMLの間には当初から深いずれがあった
• MDAのコード生成失敗がUML制度の経済的根拠を失わせた
• クラウド・iPhone・CI/CDという三方向からの圧力が変更速度を引き上げアジャイルの前提条件を満たした
• 先に死んだのは図ではなくUMLという名称に付随していた制度と二重管理であった
• UMLは消えたのではなく名前を失って日用品になった

(2026/04/24)

実践ハーネスエンジニアリング：TAKTで実現するAIエージェント制御

• 実践ハーネスエンジニアリング：TAKTで実現するAIエージェント制御 / Practical Harness Engineering: AI Agent Control Enabled by TAKT - Speaker Deck

要約:

■ 1. ハーネスエンジニアリングの定義

• 「ハーネス」の定義は論者によって異なり、コンテキスト設計・出力検査・ガードレール・ドキュメント劣化対策など多義的に使われがちである
• Birgitta Bockeler氏がMartinFowler.comに公開した「Harness Engineering」記事を出発点とする
• 本資料における定義：モデルの外側でエージェントの振る舞いを制御・誘導・検証する仕組みの総称
• メタファー：馬具（手綱・鞍・ハミ）が馬を外から方向づけるように、フィードフォワード（FF）とフィードバック（FB）でAIエージェントを外から方向づける

■ 2. ハーネスの2種類：フィードフォワードとフィードバック

• フィードフォワード（動く前に方向づける）:
  • 誰として何を目的に動くかを明示する
  • 判断に必要な背景知識をあらかじめ渡す
  • 何をもって完了とするかを事前に合意する
  • 使える手段（ツール・権限）を必要な範囲に絞る
  • 現在の局面を示す位置情報を伝える
• フィードバック（動いた後に自己修正を促す）:
  • 出力を検査しやすい形で受け取る
  • 異なる観点から複数回チェックする
  • 不備があれば修正を促して再点検する
  • 改善が停滞したら別の手立てに切り替える
• ステアリングループ：FFとFBを継続的に改善しエージェントを操縦するループであり、結果を見てFF・FB両方を調整し続ける

■ 3. ハーネスが制御する3領域

• 保守性（Maintainability）:
  • コード品質・保守性を守る汎用的なハーネス
  • 重複コード・スタイル違反・力技の修正・過剰な設計を捕捉する
• アーキテクチャフィットネス（Architecture Fitness）:
  • アーキテクチャ特性を定義し測定するプロジェクト固有のハーネス
  • 性能（レイテンシ・スループット・リソース効率）・可観測性（ログの質・トレース可能性）・構造（レイヤー違反・循環依存・結合度）を対象とする
• 振る舞い（Behaviour）:
  • 期待した振る舞いをしているか検査する完全自動化が難しいハーネス
  • 仕様・ユースケース・E2Eテスト・フィクスチャベース検証を対象とする
• ハーネステンプレート：FFとFBをパッケージ化したもの

■ 4. TAKTの概要

• YAMLでマルチエージェントワークフローを記述するオーケストレーター（指揮者「タクト」のメタファー）
• ハーネステンプレートをworkflow.yamlとして定義して動かすOSS
• インストール直後からビルトインテンプレートをそのまま利用可能（npm install -g takt）
• 構成要素:
  • ワークフロー：STEPの有限状態機械
  • ファセット：プロンプトの部品（Persona・Knowledge・Instruction・Output Contract・Policy）

■ 5. フィードフォワードの実装（6つの手法）

• Faceted Prompting（ファセットの組み立て）:
  • プロンプトを5つのファセットに分離（Persona・Knowledge・Instruction・Output Contract・Policy）
  • PersonaはSystem Prompt、その他はUser Messageとして文脈→タスク→制約の順に組み立てる
  • PolicyをUser Messageの末尾に配置しRecency効果で遵守率を最大化する
• Quality Gates（完了条件の事前提示）:
  • STEP完了前にエージェント自身が検証すべき項目を明示する
  • ビルド成功・lint通過・テスト通過などをプロンプトに箇条書きで注入する
• ツール権限の制限:
  • required_permission_modeでreadonly / edit / fullを指定する
  • allowed_toolsで使用可能なツールを明示列挙する
  • レビュアーにはEdit/Writeを渡さず暴走を防止する
• ワークフロー構造の自己認知:
  • プロンプトに現在ステップ位置を自動注入しエージェントが前後関係を理解して動作する
  • 単独STEPで完結させようとする独走を防ぎInstructionBuilderが各STEPで再構築する
• Persona Providers（適材適所のモデル選択）:
  • ペルソナごとに別プロバイダー・モデルを指定する（例：実装はCodex・レビューはClaude）
  • provider_options.claude.effortで推論深度も指定可能
• Team Leader（動的タスク分解）:
  • リーダーエージェントがJSONでタスクを分割し各partを並列実行する
  • 結果を集約して次STEPへ渡すことでFFを動的に広げる

■ 6. フィードバックの実装（7つの手法）

• Output Contract（判定可能な形の強制）:
  • Result: APPROVE / REJECTを強制しfinding_id + family_tagで追跡可能にする
  • new / persists / resolved / reopenedで進捗を分類する
• 判定フェーズの分離:
  • Phase 1（実行エージェント）とPhase 3（conductor・判定専用）を別エージェントに分離する
  • 実行する人と判定する人を分けることで主観を判定から切り離す
• Rulesによる分岐:
  • 文字列conditionはタグ[STEP:N]で照合する
  • ai("……")で自然文条件をAIが判定する
  • nextにCOMPLETE / ABORT / 次STEP名を指定してルーティングする
• 改善ループ:
  • レビュー結果に基づき修正→再レビューを繰り返す（ai_review ⇆ ai_fix・reviewers ⇆ fix）
  • pass_previous_response: falseで前回判断の引きずりを防ぐ
  • session: refreshで会話セッション自体をリセット可能
• Parallel Reviewers（多視点フィードバック）:
  • parallelで複数レビュアー（アーキ・フロント・テスト・セキュリティ等）を並列実行する
  • all() / any()で集約判定し単一視点では見えない問題を補う
• Loop Monitors（収束・発散の判定）:
  • 対象cycleとthresholdを定義し閾値到達でJudge（supervisor）を起動する
  • finding_idの推移から収束・発散を判定し発散なら別ルート（ABORT等）に切り替える
• Worktree Isolation（安全な実行基盤）:
  • 各タスクをworktreeで隔離実行する（git worktreeではなく独自実装）
  • 失敗してもメインブランチを汚さず並列修正を安全に同時実行できる

(2026/04/24)

役割と責任の区別をつける

• 役割と責任の区別をつける

要約:

■ 1. 役割と責任の違い

• スクラムガイド2020での変更:
  • スクラムガイド2017まではプロダクトオーナー・開発者・スクラムマスターを「役割（Role）」と呼んでいた
  • スクラムガイド2020から「責任（Accountability）」という用語に変更された
• Accountability（説明責任）の定義:
  • 「行動・成果・意思決定に対して責任を引き受け、その結果について報告・説明・答弁する義務」
  • 意思決定の根拠・試みた内容・結果・次の行動について担当し説明できることを指す
  • 結果を保証することではなく「結果に対してオーナーシップを持つ」ことを意味する
• ResponsibilityとAccountabilityの区別:
  • Responsibility（実行責任）は実際に手を動かす責任であり誰が何をするかの話
  • 日本語の「責任」にはこの両方の意味が含まれるため混同されやすい
• スクラムガイド2020が用語を変えた意図:
  • 「誰が何をするか」はスクラムチームの自己管理として自分たちで決める
  • どの領域でAccountabilityを持つかは明確にする
• 責任・役割と肩書き・役職・職種は別物である:
  • プロダクトオーナーやスクラムマスターは会社の役職や職種ではなくスクラムチーム内の責任の区分
  • これを理解することで「それはあなたの仕事」「作業が進まない」といった発言がなくなる
• スクラムマスターのAccountability:
  • スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ
  • スクラムチームの有効性に責任を持つ
  • その果たし方はチームの状況やスクラムマスター自身のスタイルによって異なる
  • すべてのイベントの司会やファシリテーターをするResponsibilityは存在しない

■ 2. 「何もしない問題」の正体

• スクラムが適切に機能している場合:
  • スクラムマスターがスクラムチーム内でやることは多くない
  • スクラムチームの外側（組織）での取り組みが増えていくのが通常
  • チーム内の他メンバーから「何もしていないように見えている」だけの可能性がある
• 透明性と説明責任の不足:
  • 自分がどんな目的で何をしているかを公開していない状態が問題
  • スクラムマスターは自分が何に取り組んでいるかを他者からわかるようにする必要がある
• 本当に何もしていない場合の対処:
  • チームメンバーは助けてほしいこと・手伝ってほしいことを積極的に伝える
  • スクラムチーム全体として「毎スプリント価値あるインクリメントを届ける責任」があり一人だけ他人事は許容されない
  • 改善されない場合はマネージャーへエスカレーションしチームから外す

■ 3. 役割のオーバーラップと責任の明確化

• 生成AI時代のチームの変化:
  • チームは小さくなりメンバーのスキルがオーバーラップしている
  • 「これは自分の仕事ではない」という発言が成立しない状況になっている
  • 役割の境界は曖昧であってよい
• 責任の明確化の重要性:
  • 責任が曖昧になると誰も決定しなくなり合議制に陥る
  • 責任が明確であることで意図を持った意思決定が可能になる
• 生成AI時代のプロダクトマネージャー論への適用:
  • 従来プロダクトマネージャーが担っていた業務はチームの様々なメンバーが担うようになる
  • プロダクトマネージャーが持っていたAccountabilityは誰かが持たなければならない
  • 肩書きや職種の名称が変わっても責任そのものは消えない

(2026/04/23)

ドメイン記述ミニ言語の設計論

■ 1. 設計の前提

• ミニ言語が満たすべき三条件:
  • 半形式的であること（機械コンパイル不要だが文法的に曖昧でない）
  • 人間・ドメイン専門家・AIエージェントが共有できること（実装言語の知識を前提としない）
  • 四層（lexicon / syntax / semantics / pragmatics）を持つこと（semantics 層を含む点が用語集との分水嶺）

■ 2. 第一層：Lexicon（語彙）

• 名詞と動詞を対等に扱うことが出発点
• 用語集が失敗する原因は名詞しか定義しないため
• 動詞は必ずどの concept に属するかとセットで記述する規則が必須
  • 動詞が宙に浮くと semantics 層に繋がらない

concept 注文
concept 顧客
concept 注文明細

operation 確定する   (注文に対して)
operation キャンセルする (注文に対して)
operation 追加する   (注文明細を注文に対して)

■ 3. 第二層：Syntax（構成規則）

• ある concept がどんな要素から成り立つかを AND / OR / ? で記述する
• この層を書くことで「ありえない状態の構造的な排除」が始まる
  • OR 型で状態を列挙することで矛盾した状態が文法レベルで存在不可能になる
• 記法の選択方針:
  • Haskell / F# の代数的データ型記法を参考にすることは合理的
  • ドメイン専門家と共有する場合は自然言語寄りの表現も検討に値する
  • 一つのプロジェクト内で記法を混在させないことが肝要

注文 = 顧客 AND List<注文明細> AND 注文状態
注文明細 = 商品 AND 数量 AND 単価
注文状態 = 未確定 | 確定済み | 出荷済み | 完了 | キャンセル済み
数量 = 正の整数   // 型制約も文法の一部

■ 4. 第三層：Semantics（振る舞い）

• 用語集と言語の分かれ目であり設計の核心
• 不変条件（invariant）:
  • concept が存在している間常に真でなければならない規則
  • 構造定義だけでは表現できない意味を持ち込む手段
• 状態遷移:
  • ドメインの時間軸を言語に持ち込む
  • 「いつその操作が意味を持つか」を明確化する
• 事前・事後条件（pre / post）:
  • BDD の Given-When-Then と等価でありテストシナリオに自然に変換できる
  • 厳密な論理でなくともテストに翻訳できる精度があれば十分

注文 {
  invariant: 明細は1件以上存在する
  invariant: 合計金額 = sum(明細.単価 × 明細.数量)
}

注文状態の遷移 {
  未確定    --[確定する]--> 確定済み
  未確定    --[キャンセルする]--> キャンセル済み
  確定済み  --[出荷する]--> 出荷済み
  出荷済み  --[受領する]--> 完了
}

operation 確定する {
  pre:  注文状態 == 未確定
  pre:  明細.count >= 1
  post: 注文状態 == 確定済み
  post: 確定日時 が記録される
}

■ 5. 第四層：Pragmatics（文脈）

• 同じ語が Bounded Context によって意味を変える現象を扱う層
• mapping ブロックを書くことで Context 間の翻訳規則を言語として記録できる
  • 「翻訳の蓄積」という失敗モードへの直接の処方箋

context 受注管理 {
  concept 顧客 = 名前 AND 配送先住所 AND 注文履歴
}

context 与信管理 {
  concept 顧客 = 名前 AND 与信限度額 AND 支払い履歴
}

mapping 受注管理.顧客 <-> 与信管理.顧客 {
  共通キー: 顧客ID
  受注管理側では与信情報は不可視
}

■ 6. 設計原則

• 原則1「書けない状態は存在しない」:
  • 記法が表現できない状態や遷移はモデルに存在しないものとして扱う
  • この制約が言語に思考を強制する力を与える
• 原則2「操作は concept に帰属させる」:
  • 動詞を浮かせず「何が」その操作を持つかを明示する
  • 責務の設計とミニ言語が連動する
• 原則3「不変条件は構造定義の直後に書く」:
  • concept ブロックの中に invariant を置くことで定義と制約を分離しない
  • 後から別ファイルに書かれた不変条件は読まれなくなる
• 原則4「記法の複雑さはドメインの複雑さに合わせる」:
  • シンプルなドメインに複雑な記法を持ち込むとミニ言語自体が保守コストになる
  • 最初は lexicon + syntax + 状態遷移のみで始め段階的に導入するのが現実的
• 原則5「コードと並走する」:
  • ミニ言語のファイルをコードリポジトリと同じ場所に置きコードレビューの対象にする
  • ドキュメントとして別管理した瞬間にコードとの乖離が始まる

■ 7. 残された課題

• ミニ言語の設計完成後もドメイン専門家が実際に読み書きするかという問題は別途残る
• 形式的すぎると専門家が離れ自然言語に近づけすぎると曖昧さが戻るという張力は解消不可能
• ミニ言語はチームごとのキャリブレーションを必要とする一点制作品であり汎用フレームワーク化には本質的限界がある
• 四層の整理はキャリブレーションのための共通語彙として機能する
• 設計目標は「完全な形式言語の作成」ではなく「用語集で止まらないための最低限の文法を持つこと」

(2026/04/22)

ユビキタス言語

• ユビキタス言語 - kawasima

要約:

■ 1. 主張の核心

• ユビキタス言語が "language" と呼ばれる理由はその設計がドメインモデリングそのものだからである
• 言語の設計とは語彙のみならずデータの構造と振る舞いを文法として決めることを指す
• 用語集 (glossary) との本質的な違いは文法の有無にある

■ 2. 言語学的根拠

• 名詞の集まりだけでは言語にならない
  • Saussure: 言語は記号の体系であり個々の記号は差異によって意味を持つため語彙の並びだけでは体系にならない
  • Wittgenstein: 語の意味はその使用によって決まる (哲学探究 §43)
• 言語には語の組み合わせを規定する文法と語が使われる場の両方が要る
• 用語集は名詞の並びであり振る舞い・状態遷移・概念間の関係を記述する文法を持たない

■ 3. 言語の四層とドメインモデルの対応

• 言語学的な四層がドメインモデルの要素に一対一で対応する
  • lexicon (語彙): 概念と操作の名前 → 注文・顧客・検証する等の名詞と動詞
  • syntax (統語): 概念の構成規則 → AND・OR・? による複合・分岐・任意
  • semantics (意味): 語の使われ方 → 不変条件・事前/事後条件・状態遷移 (behavior の入出力仕様)
  • pragmatics (語用): 文脈による意味の変化 → Bounded Context による文脈の切り分け
• 用語集と言語の分かれ目は semantics の層である
  • behavior なしの用語集は語が使われてよい/使われてはいけない規則を書けない
  • behavior を書くことで語が実際にどう使われるかが定義される
• Evans の "a change in the language is a change to the model" はこの対応から導かれる

■ 4. 同方向の先行論

• ユビキタス言語を半形式の記述として扱う先行論が複数存在する
  • BDD (Dan North): Given-When-Then 構文 (Gherkin) による振る舞いの半形式記述
  • Scott Wlaschin "Domain Modeling Made Functional": F# の代数的データ型でドメインを記述しコードがユビキタス言語の記述になるとした
  • Cyrille Martraire "Living Documentation": ユビキタス言語はコードに埋め込まれており BDD シナリオを live specification として扱う
  • Vlad Khononov・Derek Comartin: DDD の core は tactical pattern ではなくユビキタス言語であると明示
• 先行論の共通点は「振る舞いを含む半形式の記述」としてユビキタス言語を扱う視点である
• 先行論が示さなかった点: Evans の定義の曖昧さを正面から問題化し syntax・semantics・pragmatics の三層を具体的に記述する形式の提示

■ 5. 概念が曖昧なまま流通してきた経緯

• Evans 自身がユビキタス言語の定義の曖昧さを認めている
  • 2014年 DDD Exchange: DDD の中核概念が実装レベルで機能せず慣習に頼らざるを得なかったと述べた
  • 2018年 Explore DDD: DDD の説明が "handwavy good advice" "feel good mush" に近いと自己批評した
  • 2019年 DDD Europe: Bounded Context を含む fundamental terms がしばしば誤解されていると認めた
• Evans 2015 DDD Reference の Ubiquitous Language 節は概念の定義ではなく実践の指示を主眼に置いている
• 曖昧さの結果として各地で形骸化が生じた
  • 英語圏: 同義語・一語多義・型/実体の混同・技術用語との衝突といった問題が報告された
  • 日本語圏: プラクティスが精神論として語られる傾向が定着した

■ 6. 実際の成果物は用語集になっている

• 公開されているユビキタス言語の成果物はほぼすべて名詞中心の用語リストである
  • IFRC CBS: 組織・役割・疾病・報告形式の名詞定義が中心で振る舞いや状態遷移の記述は限定的
  • LegalOn Technologies: 用語の日英併記定義が中心で動詞や状態遷移の具体的扱いは示されていない
  • Progate: スプレッドシートによる用語辞書と Figma のドメインモデル図で振る舞い・状態遷移の扱いには及んでいない
  • Matt Pocock の ubiquitous-language skill: 出力例は名詞の表と概念間のカーディナリティが中心
• Qiita の調査でも日本語圏の 6 事例のうち動詞を扱うのは 1 件のみである
• 各チームが自前で形式を発明した結果として最も作りやすい「名詞の辞書」が採用された

■ 7. 日本語訳が用語集理解を助長する問題

• Khononov 邦訳『ドメイン駆動設計をはじめよう』(2024) では ubiquitous language が「同じ言葉」と訳されている
• 「同じ言葉」は四層のうち lexicon の層にのみ対応する訳語である
  • 「同じ」は一意性の要求を「言葉」は語彙の並びを指す
  • syntax・semantics・pragmatics の三層が訳語に含まれない
• カタカナ表記であれば「語ではなく言語」という違和感が残るが「同じ言葉」だとその違和感もなくなる
• 既に名詞中心に偏っている現状で訳語自体がその偏りをさらに強める

■ 8. DSL との関係

• ドメイン記述ミニ言語は実行可能な DSL とは別の位置にある
  • Evans の論じる DSL はコンパイラで処理され実装になる実行可能な言語である
  • ドメイン記述ミニ言語は人間・ドメイン専門家・AI Agent が共有するための半形式的な記述言語である
• ミニ言語の記法は実装との対応が厳密でなくてよい
  • コレクションを示す List は実装構造の指定ではなく複数あるという業務上の意味を表す
• 実行可能な DSL はユビキタス言語の文法の一部を機械に渡す際の固定化であり言語設計そのものではない

■ 9. 用語集として扱うことの失敗モード

• 用語集として運用することは語彙だけを残し文法を捨てることである
• 具体的な失敗モードは以下の通り
  • 翻訳の蓄積: 文法が共通でないためドメイン専門家と開発者の語りの差を文単位で翻訳し続けることになる
  • 瞬間的表現の喪失: 用語集は文を作って使う場を持たないためドメイン理解の核心となる瞬間的な表現が記録されずに失われる
  • 動詞の欠如: 名詞の並びにはドメインの振る舞いが現れず anemic domain model と同じことが言語の側でも起こる
  • ありえない状態の許容: 文法なしではドメインの不変条件が型の段階で守られない
  • コードとの乖離: 言語としてコードと並行して使われないため時間経過とともにコードと食い違っていく

(2026/04/22)

言語化に苦しむ全ての人(エンジニア？)へ。今日から変わるコミュニケーション術補遺

• 言語化に苦しむ全ての人(エンジニア？)へ。今日から変わるコミュニケーション術補遺

要約:

■ 1. 記事の概要

• タイトル: 言語化に苦しむ全ての人(エンジニア？)へ。今日から変わるコミュニケーション術補遺
• 著者: ココナラ DevOpsグループCREチーム y.s.（@inu_no_hou）
• 公開日: 2026年4月20日
• テーマ: communication・mindset・technical writing

■ 2. 概念操作の手法

• 基本テーゼ:
  • 言語化とは「概念操作とその操作結果の伝達」である
  • 概念操作力とその伝達力の二軸を鍛えることが重要
• 主観と客観の整理:
  • 主観は自分のみで有効であり、客観は広く妥当する可能性が高い
  • ビジネスで求められる数値化やファクトとオピニオンの分離はこれに該当
• 抽象化:
  • 個別概念を削り落とす工程
  • 例: 「林檎2つ、バナナ3つ」→「果物5つ」
• 一般化:
  • 抽出した本質を複数の具象に当てはめる操作
  • 例: Tシャツの本質（襟なし・T字型・かぶり式）は生地や色を変えても成立
• 例え話:
  • 概念構造が瑣末な変更を経ても同一であることを利用する手法
  • 具体と抽象を行き来する能力を磨くことに有効
• メタ化:
  • 「本当だろうか？」という問いで自分の概念体系全体を問題化する
  • 問いの次数を上げ下げして視点を調整する
• 結論:
  • 概念操作力とは「具体と抽象を反復横跳びする筋力」であり日々の鍛錬が必要

■ 3. テクニカルライティングの鉄則

• 基本原則:
  • 文章の目的は読者が「わかった・できた」となること
  • 自分の賢さの披露や情報の網羅は目的ではない
• 7つの鉄則:
  • 短く書く: 1文=1アイデアとし文・語・段落を全て短くする
  • 能動態で書く: 「誰が」「何をした」を明確にする
  • 強い動詞を使う: be動詞やoccurではなくgenerate・trigger・deleteなど具体的な動詞を用いる
  • 無駄を削る: 冗長な修飾語や形容詞を排除し数字を活用する
  • 構造で見せる: 見出し・リスト・表で情報を構造化する
  • 読者を意識する: 対象読者の知識レベルを把握して執筆する
  • 一貫性を守る: 同じ概念に同じ用語を使い続ける

■ 4. セルフ編集チェックリスト

• 文の構造:
  • 1文1アイデアを守り複数概念を1文に詰め込まない
  • 受動態を能動態に変換する
  • be・occur・happenなど弱い動詞を回避する
  • 「There is/are」を削除し主語を前面に出す
  • 冗長表現を削除する（「in order to」→「to」・「make use of」→「use」）
• 語彙と用語:
  • 表記ゆれを避け初出時にフル名と略称を定義する
  • 頭字語は初出時に正式名称を説明する
  • It・This・They等の代名詞を具体的な名詞に置き換える
  • 形容詞を数値化する（「very fast」→「225-250%高速」）
• 段落構成:
  • 冒頭文で内容を予告し読者が先頭文のみで内容を判断できるようにする
  • 1段落1トピックを原則とし3〜7行を目安にする
• 見出しとリスト:
  • 見出しは内容を正確に予告する（「Details」×→「Configure the database connection」◎）
  • リストの並列構造を統一する（名詞のみ・命令形のみなど）
• トーンと表現:
  • ユーザーを責めない表現を使う（「Invalid ID」×→「You need an ID that looks like...」◎）
  • pleaseの過剰使用を避ける
  • ジェンダー・文化バイアスを排除する（he→you）
• エラーメッセージ:
  • 「何が問題か」と「どう直すか」の2点セットで構成する
  • 例: 「Error: Invalid input」×→「Can't save because file name contains invalid characters. Remove: / \ : * ? "」◎
• グローバル対応:
  • 文化固有表現を排除する（「a piece of cake」→「simple to set up」）

■ 5. LLMをテクニカルライティングに活用する方法

• 活用場面:
  • 初稿生成: 立場・対象読者・形式を指定して生成する
  • 文書推敲: 受動態検出・文法チェック・スタイル統一に使用する
  • フォーマット変換: Word→Markdownなどの形式変換に使用する
  • 要約: 長文の要点整理に使用する
• 注意点:
  • LLMはハルシネーション（虚偽出力）があるため事実確認が必須
  • 「提供テキストの情報のみ使用」と制約を明示する
  • LLMに書かせすぎるとメタ認知のメリットが消失する

■ 6. テンプレート集

• 技術ドキュメント: 概要・対象読者・前提知識・対象範囲・セクション・関連リソースで構成
• APIリファレンス: メソッド名・構文・パラメータ表・戻り値・例・備考・関連項目で構成
• エラーメッセージ: 何が問題か・なぜか・どう直すかの構成で良悪例を含む
• How-toガイド: タスク名・前提条件・手順・確認方法・トラブルシューティング表・次のステップで構成
• リリースノート: 新機能・改善・バグ修正・破壊的変更・既知の問題・アップグレード手順で構成
• トラブルシューティングガイド: 症状・原因・解決策・未解決時の対応で構成

■ 7. 結論

• 概念操作もテクニカルライティングも単なる筋トレであり継続的な実践が重要
• 日々の鍛錬は裏切らないと著者は強調する

(2026/04/21)

AIの電力限界に挑む——Extropicが狙う「熱力学コンピューティング」とは

• AIの電力限界に挑む——Extropicが狙う「熱力学コンピューティング」とは｜Neo Tech World

要約:

■ 1. 背景——AIの電力・設備コスト問題

• 生成AIは学習・推論において膨大な計算を必要とし中心にあるGPUは高性能だが消費電力も大きい
• AIの課題は「より賢いモデルを作ること」だけでなく現実に動かし続けるための電力と設備コストに移ってきた
• 高性能GPUを積み増すだけでは電力・冷却・設置面積・設備投資の負担が拡大する一方である
• 現在の機械学習はGPUに合わせて進化してきた仕組みであり計算需要は決定論的処理から確率的処理へエネルギー制約へと移行しつつある

■ 2. Extropicの概要と開発ロードマップ

• 2022年創業2023年12月に1410万ドルのシード資金を調達
• GPUの改良ではなく生成AIに必要な計算そのものを作り直す「熱力学コンピューティング」を掲げる
• 開発段階:
  • X0: 2025年Q1のシリコン試作——確率回路を実際に製造できることを実証
  • XTR-0: 2025年Q3の実験・研究プラットフォーム——Extropicのチップと従来型プロセッサを低遅延で接続し超高効率AIアルゴリズムの開発基盤とする
  • Z1: 2026年early access予定の初の量産規模チップ——1チップあたり数十万・1カードあたり数百万の確率回路を標準CMOSプロセスで量産可能とする
• ソフトウェア面ではオープンソース開発基盤THRMLを公開しGPUなど既存環境上で熱力学コンピューティング向けアルゴリズムを試験できる

■ 3. 技術的原理——p-bitと確率回路

• 通常のデジタル計算機が0か1を厳密に固定して計算するのに対しExtropicは回路の揺らぎを計算資源として利用する
• p-bit（確率ビット）:
  • 0と1の間を行き来しながらどちらに寄りやすいかを調整できるスイッチ
  • 従来の半導体がノイズを排除しようとしてきたのに対し揺らぎを計算に取り込む点が根本的に異なる
• 確率回路の種類:
  • PBIT: 0か1を指定した確率で出し分ける基本回路（重み付きコインに相当）
  • PDIT: 複数の離散的な候補から確率に応じて選ぶ回路（重み付きサイコロに相当）
  • PMODE: 連続値をとるガウス分布を表現する回路
  • PMOG: 複数の山を持つ複雑な分布を扱う回路
• TSU（Thermodynamic Sampling Unit）が中核であり複雑な確率分布から直接サンプルを生成することを狙う
• DTM（Diffusion Thermodynamic Model）は拡散モデルに近い発想でTSUの確率的性質を前提に生成処理を組み直したアルゴリズム

■ 4. 技術的ブレークスルーの三点

• TSUによるサンプリング:
  • 従来AIが行列計算で確率表を作りサンプリングするのに対しTSUは確率分布から直接サンプルを出す
  • 生成AIの中核にある確率的選択をハードウェアの中心に置く設計思想
• 量産を見据えた実装可能性:
  • p-bitをトランジスタのみで構成し小型・省エネ・既存回路との統合が容易と主張
  • 研究室デモにとどまらず実際の半導体として大規模化できる可能性を提示
• ハードとアルゴリズムの一体設計:
  • TSU・DTM・THRMLをセットで外部に公開し単なるアイデア企業を超えた段階にある
  • 公式発表では小規模生成AIベンチマークにおいてGPUベース手法より最大約10000倍のエネルギー効率向上の可能性を示す（特定条件下の分析であり商用基盤モデルの実運用置き換えを意味するものではない）

■ 5. 実用化に向けた課題と制約

• スケールの壁:
  • 小規模回路で有望な結果が出ても大規模システムへ拡張した際に同じ効率が維持できるとは限らない
  • 量産では歩留まり・配線・発熱・制御の複雑さが重くなり理論上の優位が崩れうる
• ソフトウェアエコシステムとの接続:
  • 現在のAI開発はCUDAをはじめGPU前提の巨大なエコシステムの上で動いている
  • THRMLの公開は対策の出発点にすぎず「使ってみたい技術」から「導入できる技術」への転換が必要
• 用途の限定性:
  • Extropicの方式はあらゆる計算でCPU・GPUを置き換えるものではない可能性が高い
  • 相性が良いのは確率分布を扱う処理・サンプリングが重い処理・ノイズを前提にした生成や推定の処理
  • 最初の勝ち筋は「全AIを置き換える」ことではなく特定の確率的ワークロードで圧倒的に省エネという狭く深い突破口になる公算が大きい

■ 6. 確定点と未確定点の整理

• 確定している事実:
  • 2025年にTSU・DTM・THRML・XTR-0を含む熱力学コンピューティングの全体像を公表
  • X0シリコン試作・XTR-0開発基盤・Z1量産スケールという三段階ロードマップを明示
  • THRMLをGitHubで公開し外部から触れられる状態にある
  • ハード・アルゴリズム・ソフトウェアを並行して外部に示し始めている
• 未確定の事項:
  • 大規模商用AIの現場でGPUの代替または補完になれるかは未実証
  • 小規模ベンチマークでの10000倍効率向上は特定条件下の分析であり商用スケールでの実証ではない
  • 2026年4月時点では量産出荷の完了や大規模顧客への本格導入を示す一次情報は確認できない
• 現在地の評価:
  • 「机上構想の会社」ではもうないが「GPUに対する勝敗が見えた会社」でもまだない
  • 技術的成立可能性と初期ロードマップを市場に示した段階であり商用スケールで勝ち筋が実証された段階ではない

■ 7. 今後の焦点

• XTR-0やTSUの考え方が試作にとどまらずどこまで大きな規模へ拡張できるか
• THRMLを起点に外部の研究者や開発者がどれだけ参加し技術の土台が広がるか
• 画像生成・気象・科学計算のような確率的処理が重い分野で最初の具体的な実用価値を示せるか
• 三つが揃えばExtropicは「面白い技術」から「業界の現実的な選択肢」へ進む可能性があり揃わなければ高く評価されながらも広くは採用されない技術にとどまる

(2026/04/21)

Why is IPv6 so complicated?

• misc/why6why.md at main · becarpenter/misc · GitHub

要約:

■ 1. IPv6が複雑である理由の概観

• IPv4のアドレスに単純にビットを追加するだけでは不十分であり IPv6の複雑さには正当な理由が存在する
• 主な理由は以下の3点に整理される
  • アドレスのビット数拡張は見た目より複雑である
  • 1994年当時 IPv4以外にも多くのネットワーク層プロトコルが存在しIPv4にない機能が求められた
  • IPv6設計者が過剰設計に陥った可能性がある（いわゆるSecond System Syndrome）
• IPv6開発の意思決定は1991年のIABワークショップを起点とし 1994年7月のIETF会議で正式に採択された

■ 2. アドレスのビット拡張が単純でない理由

• IPv4の実装はすべて32ビットアドレス形式をコードに組み込んでおり アドレス長を変更すると既存の実装はパケットを廃棄する
• アドレスサイズを拡張するには必ずプロトコルを変更する必要があり 以下の対応が不可避となる
  • バージョン番号の変更
  • 新バージョンを処理する新規コードの追加
  • 旧バージョンとの共存技術の実装
• 旧バージョンとの共存方式は数学的に以下の2つしか存在しない
  • デュアルスタック: 新しいマシンがIPv4とIPv6の両方を話す方式
  • トランスレーション: アドレスを旧・新プロトコル間で変換する方式
• IPv4/IPv6共存の複雑さはすべてこの構造的制約から生じており IPv6の設計詳細とは無関係である
• 「IPv8」提案者が主張する「IPv4アドレスの先頭にビットを追加する」方式も試みられたが実用性がなく廃止された（RFC3513 → RFC4291）

■ 3. 1990年代初頭のプロトコル環境

• 1990年代初頭はIPv4がまだ世界を支配しておらず 多数の代替ネットワーク層プロトコルが存在した
  • OSI（開放型システム間相互接続）プロトコル群: 各国政府や大企業が標準として支持
  • DECNET Novell Netware等の独自プロトコル群
• 新世代IPには単なるアドレス拡張ではなく これらの競合プロトコルを上回る機能が求められた
• この背景から IPv4単純拡張では市場・技術的ニーズを満たせなかった

■ 4. IPv6設計の過剰複雑化に関する検討

• IPv6は基本的に保守的な設計であり コネクションレス型パケット交換という基本モデルは維持されている
• 追加された主な機能は以下の通り
  • フローラベル（長年未使用でも無害）
  • フラグメンテーション機構の調整
  • IPv4「オプション」をIPv6「拡張ヘッダ」へ置き換え
  • ステートレスアドレス自動設定（SLAAC）とルータアドバタイズメント（RA）機構
• SLAACはDECNET・Netware・Appletalkに着想を得たものであり 手動アドレス設定を不要とする
• DHCPv6とSLAACが重複するのは SLAAC設計時にDHCPがまだ実績のない新技術だったためであり DHCPv6は後付けで追加された
• IPsecのサポートを必須とする政治的決定は 当時未成熟な技術を強制したことでIPv6普及の妨げとなり 後に撤回された
• IPv6展開の問題の大部分はIPv4/IPv6共存領域から生じており 設計の過剰さによるものではない

■ 5. 代替案（IPv8等）の問題点

• 一部の「IPv8」提案は解決どころか問題を悪化させる要素を含んでいる
  • 地理的アドレッシング: インターネットのドメイン間ルーティングと非互換
  • 自律システム番号に基づくアドレスプレフィックス: ルーティングを破壊する
  • アドレスビットに意味を持たせる設計: サイト再番号付けをさらに困難にする
  • これらは経路制御の破綻 アドレス枯渇の再発 広範囲な監視の容易化等を引き起こすリスクがある

■ 6. 普及に要する時間の必然性

• IPv6が約50%の普及率に達するまで25年以上を要した
• これはIPv6固有の問題ではなく インターネット規模の技術移行には例外なく数十年を要する
  • フレームリレーの廃止
  • ATMの置き換え
  • DNSSECの展開
  • RPKIの展開

■ 7. 結論

• IPv6の存在意義はアドレス空間の拡大にあり それ以外の複雑さは構造的に避けられないものである
• 32ビットを超えるアドレス長を採用した時点で 共存・移行に関するすべての問題は必然的に発生する
• デュアルスタックとトランスレーションの両方式は数学的に不可避であり 代替設計によって回避することは不可能である
• IPv8等の代替提案を検討することはコミュニティにとって時間の無駄である

関連:

• IPv4と完全下位互換の「IPv8」ドラフトが投稿。IPv6の課題を克服

(2026/04/21)

IPv4と完全下位互換の「IPv8」ドラフトが投稿。IPv6の課題を克服

• IPv4と完全下位互換の「IPv8」ドラフトが投稿。IPv6の課題を克服 - PC Watch

要約:

■ 1. IPv8プロトコルの概要

• 次世代ネットワークプロトコル「Internet Protocol Version 8(IPv8)」のドラフト版「draft-thain-ipv8-00」がOne Limited所属のJamie Thain氏によって2025年4月14日にIETFへ提出された
• 本ドラフトはIETFの承認や正式な策定プロセスを経たものではない
• IPv6はアドレス枯渇問題には対処したが管理上の断片化問題を解決できず25年間の展開努力にもかかわらず世界的なインターネットトラフィックのごく一部しか担えなかった
• デュアルスタックによる移行モデルと管理改善の欠如がIPv6の商業的受け入れを妨げた要因とされる

■ 2. アドレス設計と下位互換性

• IPv8のアドレスは64bitで構成され前半32bitのASNルーティングプレフィックス(r.r.r.r)と後半32bitのホストアドレス(n.n.n.n)に分かれる
• アドレス構造:
  • r.r.r.r.n.n.n.n の形式
  • r.r.r.r: 32bit ASNルーティングプレフィックス
  • n.n.n.n: 32bitホストアドレス(IPv4と同一の意味を持つ)
• IPv4との完全な下位互換性:
  • プレフィックスを0.0.0.0とした場合はIPv4アドレスとして機能する
  • IPv4はIPv8の完全なサブセットであり既存デバイス・アプリケーション・ネットワークを変更せずにIPv8ネットワークへ参加できる
  • デュアルスタック運用および強制的な移行期間(フラグデー)は不要
• アドレス空間:
  • 総アドレス数: 2^64 = 18,446,744,073,709,551,616
  • 各ASN保有者に2^32(約42億)のホストアドレスを割り当て
  • CGNATなどを不要とし根本的なアドレス枯渇問題を解決する

■ 3. ネットワーク管理の統合

• 「ゾーンサーバー」と呼ばれるプラットフォームがネットワーク管理の中核を担う
• ゾーンサーバーが提供する統合サービス:
  • DHCP8: アドレス割り当て
  • DNS8: 名前解決
  • NTP8: 時刻同期
  • NetLog8: テレメトリ収集
  • OAuth8: 認証キャッシュ
  • XLATE8: IPv4/IPv8変換
• デバイスは1回のDHCP8 Discover要求を行うだけですべての応答を受信できる

■ 4. セキュリティ機能

• 内部ネットワークの防御:
  • OAuth2 JWTトークンによるローカル認証を基盤とする
  • ACL8ゾーン分離によってデバイス間トラフィックを強制制御する
  • 許可されたルート以外の宛先への通信を排除するアーキテクチャを採用する
  • 3つの独立した強制レイヤーによる多層防御を提供する
• インターネット向けトラフィックの制御:
  • DNS8による名前解決とWHOIS8レジストリの検証を必須とする
  • DNS解決を伴わないハードコードIPアドレスによるマルウェアのC&Cチャネル通信を排除できる

■ 5. ルーティングの強化

• 32bitの累積メトリック「Cost Factor(CF)」を導入:
  • TCPセッションのラウンドトリップ時間・パケット損失・輻輳ウィンドウ状態・セッション安定性・リンク容量から導出される
  • 各ルーターは協調せず送信元から宛先まで累積CFが最低のパスを個別に選択する
• グローバルルーティングテーブルの肥大化問題への対処:
  • 最小プレフィックスを/16に制限する
  • BGP8のグローバルルーティングテーブルをASNごとに1エントリに制限する

(2026/04/20)

Friends Don't Let Friends Use Ollama

• Friends Don't Let Friends Use Ollama | Sleeping Robots

要約:

■ 1. Ollamaの概要と問題の本質

• OllamaはローカルLLM実行ツールとして最も普及しているが普及に値しない
• 普及の理由は先行者優位であり技術的優位性ではない
• llama.cppをラップしたツールでありながらその依存関係を長期間隠蔽してきた
• VC資金を受け取りながらオープンソースコミュニティの信頼を裏切ってきた

■ 2. llama.cppへの帰属問題

• Ollamaの推論機能はすべてGeorgi Gerganov作のllama.cpp(2023年3月)に依存している
• llama.cppはGitHub上で10万以上のスターと450名以上のコントリビューターを持つ
• Ollamaは1年以上にわたってREADMEにllama.cppへの言及を記載しなかった
• MITライセンスの唯一の要件である著作権表示を配布バイナリに含めなかった
• コミュニティからの指摘(Issue #3185)が400日以上放置された
• 最終的に追加されたのはREADME末尾の一行のみであり共同創業者のコメントは距離を置く意図を示唆した

■ 3. llama.cppからのフォークと性能劣化

• 2025年中頃にllama.cppを離れてggmlを直接ベースとしたカスタム実装へ移行した
• 移行理由として安定性を挙げたが実際にはllama.cppが解決済みのバグが再発した
• 主な問題:
  • 構造化出力サポートの破損
  • ビジョンモデルの失敗
  • GGMLアサーションクラッシュ
• ベンチマーク結果:
  • 同一ハードウェア・同一モデルでllama.cppはOllamaの1.8倍高速(161 vs 89 tokens/sec)
  • CPU使用時のギャップは30〜50%
  • Qwen-3 Coder 32Bではllama.cppがOllamaより約70%高スループット
• Georgi Gerganov自身がOllamaのGGMLフォークに問題のある変更があることを指摘した

■ 4. モデル名の誤表示

• DeepSeek R1リリース時に671Bパラメータの本体ではなく小規模蒸留モデルを「DeepSeek-R1」として表示した
• DeepSeek自身は「R1-Distill」プレフィックスで正しく命名しておりHugging Faceも正確に表示していた
• ollama run deepseek-r1は8Bの蒸留モデルを起動する
• Issue #8557と#8698は修正なしにクローズされた
• この誤表示によりDeepSeekの評判に悪影響を与えた

■ 5. クローズドソースアプリのリリース

• 2025年7月にmacOS/Windows向けGUIデスクトップアプリをプライベートリポジトリで開発しライセンスなしで公開した
• コミュニティからAGPL-3.0依存の可能性が指摘された
• WebサイトではGitHubリンクの隣にダウンロードボタンを配置しオープンソースアプリと誤認させる構造だった
• メンテナーは数ヶ月間沈黙し2025年11月にメインリポジトリへのマージが行われた

■ 6. Modelfileの問題

• GGUFはシングルファイルデプロイを原則とし必要な情報がすべてファイル内に含まれているが Ollamaはその上にModelfileという別設定ファイルを追加した
• Ollamaはハードコードされたリストに存在しないチャットテンプレートを自動検出できず{{ .Prompt }}にサイレントフォールバックする
• パラメータ変更のワークフロー:
  • Modelfileのエクスポート→編集→ollama createで新モデルエントリ作成という手順が必要
  • この過程でモデルファイル全体(30〜60GB)がコピーされる場合がある
• Jinja形式ではなくGoテンプレート構文を採用しており独自形式への変換が必要
• llama.cppではtemperatureや system promptはコマンドラインフラグで変更可能

■ 7. レジストリのボトルネック

• 新モデルのGGUFはHugging Face上で数時間以内に公開されるがOllamaレジストリへの追加は遅延する
• Ollamaが提供する量子化形式はQ4_K_SQ4_K_MQ8_0F16F32のみでQ5_K_MQ6_KIQクォントは非対応
• 新モデルリリース時にOllamaでテストした結果としてモデル自体ではなくOllamaのバックエンドに起因する問題がモデルの評判を損なう事例が複数発生している
• Hugging Faceがollama run hf.co/{repo}:{quant}形式をサポートしたが根本的な問題は解決されていない

■ 8. クラウドへの転換

• 2025年後半にクラウドホストモデルをローカルライブラリと並列で提供開始した
• MiniMaxなどのプロプライエタリモデルを選択した場合データが外部に送信されることの明確な開示がない
• Ollamaのドキュメントはプロンプトを保存・ログ記録しないと述べているが第三者プロバイダの扱いは不明
• Alibaba Cloudホストモデルにはゼロデータリテンション保証が存在しない
• CVE-2025-51471:悪意あるレジストリサーバーが通常のモデルpull中に認証トークンを奪取できる脆弱性が存在しPRが作成されるまで数ヶ月を要した

■ 9. VCバックドプロジェクトのパターン

• OllamaはY Combinator(W21)出資のスタートアップでKitematic(Docker GUIをDocker Incに売却)の創業者によって設立された
• 典型的な段階:
  • OSSをラップしてコミュニティの信頼を獲得
  • 帰属表示を最小化してプロダクトを自立しているように見せる
  • プロプライエタリなモデルレジストリ形式でロックインを作る
  • クローズドソースコンポーネントを追加
  • 収益化のためにクラウドサービスを導入
• モデルはハッシュ化されたファイル名でOllama独自形式で保存されており他ツールへの移行が困難

■ 10. 代替ツール

• llama.cpp:
  • OpenAI互換APIサーバー(llama-server)と組み込みWeb UIを提供
  • スループットはOllamaより一貫して高い
  • 2026年2月にggml.aiがHugging Faceと統合し長期持続性を確保
• Mozilla llamafile:
  • モデルとランタイムを1つの実行ファイルにパッケージ化し6つのOSで動作
• llama-swap:
  • 単一APIエンドポイント後ろでのマルチモデルオーケストレーション
• GUIオープンソース選択肢:
  • Jan(AGPLv3):ローカルファーストチャットアプリ
  • koboldcpp(AGPL):組み込みWeb UIを持つllama.cppフォーク
• クローズドソースラッパー:
  • LM Studio:llama.cppへの適切な帰属表示を維持し善意ある姿勢を示すプロプライエタリGUI
  • Msty:マルチモデルサポートと組み込みRAGを持つクローズドソースGUI
• Red Hat ramalama:依存関係を明示的にクレジットするコンテナネイティブなモデルランナー

■ 11. 結論

• llama.cppはGeorgi Gerganovが2023年3月に一夜で作成しローカル推論革命の基盤となった
• Ollamaはそのllama.cppをラップしVC資金を調達したが帰属を拒否しフォークを失敗させクローズドソースアプリを出荷しクラウドサービスへ転換した
• あらゆる判断ポイントでOSSエコシステムへの貢献よりも投資家向けの自立性アピールを優先した
• ローカルLLMエコシステムに必要なのはllama.cppであり Ollamaの代替ツールはすでに十分存在する

(2026/04/20)

Perry

• Perry — TypeScript → Native

MEMO:

• TypeScriptをネイティブバイナリにコンパイルするらしい
• 処理系はRustで記述され、ネイティブコードの生成はLLVMを使用している
• 対応プラットフォームは10種類と結構多いが、これはLLVMの恩恵だろうか
  • macOS, iOS, iPadOS, Android, Linux, Windows, watchOS, tvOS, WASM, Web
• 現時点（v0.5）ではGCが無いので長時間利用されるプロセスには不向きとのこと

(2026/04/20)

システムは「動く」だけでは足りない 実装編 - 非機能要件・分散システム・トレードオフをコードで見る

• システムは「動く」だけでは足りない 実装編 - 非機能要件・分散システム・トレードオフをコードで見る - Speaker Deck

要約:

■ 1. 概要

• 発表タイトル: 「システムは『動く』だけでは足りない 実装編 ― 非機能要件・分散システム・トレードオフをコードで見る」
• 発表者: @nwiizo（3-shake）
• 基礎編で示した「守るものが違うと設計が変わる」「分けると成功したか不明な場面が増える」「最後は何を守るために何を引き受けるかを決める」という原則を、小さなRustサンプルで具体的に再現する
• 取り上げるテーマ:
  • やり直し（Retry）だけでは危ない理由
  • レプリカ（replica）を読むことがなぜ少し古い値を連れてくるのか
  • その判断をどう残すか（ADR）

■ 2. サンプルの全体像

• サンプルは現実のシステムをかなり単純化したものであり、難しい仕組みを再現することではなく何を守ると何が増えるかを明示することを目的とする
• 注文処理の系:
  • FakePaymentGateway（テスト用決済サービス）
  • CheckoutService（注文を進める役）
  • OrderRequest（注文内容）
• 在庫参照の系:
  • InventoryStore（在庫を見る役）
  • primary（最新の在庫）
  • replica（少し前の在庫）
• 前半は「やり直しで事故が起きる」話、後半は「速く読むと少し古いかもしれない」話

■ 3. Rustを読むための最低限の知識

• struct（構造体）: 関連するデータをまとめる箱
  • 例: OrderRequest（注文番号・金額）、ChargeRecord（課金記録）
• enum（列挙型）: 「この中のどれか1つが起きる」と表すための型
  • 例: GatewayStep::TimeoutAfterCommit、TemporaryFailure、Success
• match（分岐）: 状態ごとにどう振る舞うかを決める書き方
• HashMap（辞書）: 「キー → 値」で覚える辞書
• 今回の目的はRustの文法を覚えることではなく、何を記録して、どこで分岐して、どう安全にしようとしているかを読めるようにすること

■ 4. テーマ1: やり直し（Retry）だけでは危ない

• 問題の核心:
  • タイムアウトが返ってきたとき、呼び出し元からは「返事がない」としか見えない
  • 返事がない原因は3つあり区別できない: (a)リクエストが途中で消えた (b)相手が止まっていた (c)相手は処理したが返事が消えた
  • 今回のコードが再現するのは(c)のケースで、決済サービスは内部的に成功扱いの記録を残しているのに、呼び出し元には失敗に見える状態
• retryのコード動作:
  • CheckoutServiceはタイムアウトを見たら素直にやり直す
  • 最大回数まで繰り返し → gateway.chargeで課金を依頼 → 成功（Ok）なら終了、タイムアウト（Timeout）なら次の回へ、回数を使い切ったら諦める
  • このコードだけ見ると自然だが、実際は成功済みだったら同じ課金をもう一度してしまう
• 実行結果（冪等性なし）:
  • charges: 2 / total_amount: 10000 → 5000円の注文なのに10000円引かれる（二重課金）
• 問題の本質: 失敗したことよりも、成功したのか失敗したのかを決めきれないことが難しい
• 解決策: 冪等性（べきとうせい / Idempotency）
  • retryをやめる工夫ではなく、成功したか失敗したか分からない場面でも事故を増やしにくくする工夫
  • 「このrequest_idはもう処理した」と覚えておけば、同じ依頼が再送されても2回目は捨てられる
• 冪等性のコード実装:
  • 確認: self.processed.contains_key(&request.request_id) → 処理済みなら何もせず「成功」を返す
  • 記録: .entry(...).or_insert(...) → 初めての依頼なら課金してrequest_idを記録する
• 実行結果（冪等性あり）:
  • charges: 1 / total_amount: 5000 → 正しい金額のまま
• 結論:
  • retryは止まりにくくするための道具（一時的な失敗から復帰しやすくなる）
  • 冪等性は「成功したか分からない場面」で事故を増やしにくくする道具（やり直しによる二重実行を抑える）
  • 分散では「止まりにくさ」と「二重実行しない」を組み合わせて守る

■ 5. テーマ2: 速さと最新性は両立しにくい

• リーダーベースレプリケーションの仕組み:
  • 書き込みはLeader（元データ）に行き、変更内容がFollower（複製）に流れる
  • 読み取りはFollowerからもできるので速い
  • ただし流れが追いつくまでは古い値が返る可能性がある
• サンプルのInventoryStore構造:
  • primary（プライマリ）: まず更新される、元の在庫
  • replica（レプリカ）: あとから追いつく、読むためのコピー
  • 書き込みはprimaryのみ、読み取りはprimaryまたはreplica
• 1回の流れ:
  • 最初はprimaryもreplicaも在庫3
  • purchase_on_primary()でprimaryだけ2になる
  • まだreplicaには反映されないので3のまま
  • replicate()を呼ぶとreplicaも2になる
• 実行結果:
  • primary stock right after purchase: 2
  • replica stock before replication: 3（古い）
  • replica stock after replication: 2
• replicaを使うことのトレードオフ:
  • 得られるもの: 読み取りを速くしやすい、混雑を分散しやすい
  • 失うかもしれないもの: 最新の値をすぐには見られない、場面によっては危険
• 場面による使い分け:
  • 商品一覧画面: 多少古くてもよい（速さが大事）→ replicaでよい
  • 購入確定直前: 古い在庫は危険（最新性が大事）→ primaryを見たい
  • どちらが正しいかは技術の好みではなく、その場面で何を守りたいかで決まる
• 同期・非同期レプリケーションのトレードオフ:
  • 同期レプリケーション（複製が終わるまで待つ方式）: 待ちが増える
  • 非同期レプリケーション（待たずに進める方式）: 古い値が見える
  • 速さを取りにいくほど、どこかで待つか、どこかで古さを受け入れるかの判断が必要

■ 6. テーマ3: コードを全部自分で書かない時代になぜ必要なのか

• コーディングエージェントが速くできること:
  • 画面やAPIの雛形を作る
  • テストコードをたたき台から書く
  • リファクタリングを進める
  • 定型的な実装をつなぐ
• 人が決めること（自動では決まらないこと）:
  • どこまでretryをしてよいか
  • timeoutを本当に失敗とみなしてよいか
  • 冪等性が必要な操作はどこか
  • primaryとreplicaをどの場面で使い分けるか
• 難しさはコードを書く量の問題ではなく、どう壊れるかと何を守るかの問題として残る
• 人に残る仕事は「決めること」と「確かめること」:
  • timeoutとsuccessが食い違う場面を想像できる
  • やり直しが二重実行を生む危険を説明できる
  • replicaの古さを許せる場面と許せない場面を分けられる
  • エージェントが書いた実装が、その考えに合っているか確かめられる
• エージェント時代に価値が上がるのは、何を守るかを決めて、大きい事故を小さい不便に変えられているか確かめる力

■ 7. 判断を残すためのADR（Architecture Decision Record）

• ADRとは: 大げさな設計書ではなく、何を決めて、なぜそうしたかを短く残すためのメモ
• ADRが必要な理由: 設計は図だけ見ても理由が分からなくなる
  • 図だけ残る場合: 「なぜそうしたのか」があとで読めない
  • ADRがある場合: 背景、決めたこと、その結果をあとから追える
• ADRの構成要素（4つ）:
  • Title（題名）: 何を決める話なのか
  • Context（前提）: どんな困りごとがあるのか
  • Decision（決めたこと）: 何を選ぶのか
  • Consequence（結果）: 何がよくなり、何が増えるのか
• ADRの記述例:
  • Title: Retry時の二重課金を防ぐためrequest_idを使う
  • Context: timeoutのあとにretryすると同じ課金が重なることがある
  • Decision: request_idで同じ依頼かどうかを見分ける
  • Consequence: 実装は少し増えるが、二重課金の事故を減らしやすくなる
• ADRは問題と判断と結果を短くつなぐメモだと考えると扱いやすい
• コードを自分で全部書かない時代ほど、その理由を短く残しておく価値が上がる

■ 8. まとめ・持ち帰ってほしいこと

• コードは短くても、設計の問題は見える（大規模な本番システムでなくても、本質は小さなサンプルで観察できる）
• 便利な仕組みにも別の困りごとがある（retryもreplicaも、それだけで安心とは限らない）
• 設計は「大きい事故」を「小さい不便」に変える仕事（どう壊れるかを先に考えて、何を守るために何を引き受けるかを決める）
• 基礎編との対応:
  • タイムアウト（Timeout）: 相手が成功しても、こちらからは失敗に見えることがある
  • やり直し（Retry）: 止まりにくくできるが、状態が読めない場面では事故も増える
  • 冪等性（Idempotency）: retryを入れても二重実行しにくくする
  • 一貫性（Consistency）: primaryは最新の値を返しやすい
  • 遅延（Latency）: replicaは速いが、少し古いことがある

(2026/04/19)

deleted_atにインデックスを雑に貼ったら本番DBが死んだ

• deleted_atにインデックスを雑に貼ったら本番DBが死んだ

(2026/04/18)

古典ドメインモデルパターンの解脱

• 古典ドメインモデルパターンの解脱

• Chapter 01 はじめに
• Chapter 02 古典ドメインモデルパターン
• Chapter 03 その構成の何が問題か
• Chapter 04 アウトサイドイン開発とBean Validation
• Chapter 05 パースとバリデーションを同時に行う
• Chapter 06 二つのアプローチの比較
• Chapter 07 Always-Valid Layer という切り口
• Chapter 08 未検証→検証済みという状態遷移
• Chapter 09 ドメインモデルから関心を分離する
• Chapter 10 データ詰め替え戦略の全体像
• Chapter 11 結合強度と距離のバランス
• Chapter 12 デコーダがレイヤーをつなぐ
• Chapter 13 既存コードへの導入
• Chapter 14 設計の重さを測る判断基準
• Chapter 15 付録: Raoh APIリファレンス（本書で使用するもの）
• Chapter 16 付録: 参考文献

本書は13章と付録で構成されています。

• 「問題の正体」（1〜2章）: 古典ドメインモデルパターンがどう見えるか、そこに潜む問題は何かを整理します。
• 「Parse, Don't Validate」（3〜5章）: Bean Validation の限界と、パースしてバリデーションと型変換を同時に行う Raoh デコーダのアプローチを示します。
• 「Always-Valid Layer」（6〜8章）: 「常に正しいデータだけが流れる層」という切り口から、状態遷移の型表現と、関心を分離したドメインモデル（record）を示します。
• 「結合のバランス」（9〜11章）: レイヤー間の詰め替え戦略と結合強度・距離の軸を整理し、デコーダがレイヤー間の接点として機能することを示します。
• 「実践」（12〜13章）: 既存コードへの段階的な導入手順と、どの設計を選ぶかの判断基準を示します。
• 付録: Raoh API リファレンスと参考文献。

初めて読む方は1章から順に読み進めることをお勧めします。既に Parse, Don't Validate や Always-Valid Layer に馴染みがある方は、9章から読み始めても意味が通るように書いています。

(2026/04/18)

DebConf 14: QA with Linus Torvalds

• DebConf 14: QA with Linus Torvalds - YouTube

要約:

■ 1. 概要

• Linus Torvaldsを招いたQ&Aセッションの書き起こし(場所はDebianカンファレンス)
• Linuxカーネル開発・ディストリビューション・ライセンス・セキュリティ等の幅広いテーマについて質疑応答が行われた

■ 2. Linuxディストリビューションと個人的な利用環境

• 2007年のインタビュー以降もDebianをインストールしたことはない
• ディストリビューションは「インストールが容易で作業の妨げにならないこと」が最重要との立場
• Ubuntuは試したがmake installが機能しなかったため断念した
• 個人の作業環境はWebブラウザと3つのターミナルウィンドウのみという極めてシンプルな構成
• 家族のマシンを管理する必要があるため一度使い始めたディストリビューションからの変更が困難

■ 3. Linuxデスクトップの普及問題

• アプリケーションのパッケージングがLinuxデスクトップ普及の最大の障壁
• Windowsや macOS向けにはバイナリを提供できるがLinux向けは困難な状況
• 問題の本質はディストリビューションごと・バージョンごとに異なるバイナリが必要になること
• glibcをはじめとする共有ライブラリが頻繁にABIを破壊することが根本原因
• カーネルにおける「ユーザ空間を壊さない」という唯一の絶対ルールをディストリビューションが守っていないと批判
• ValveがLinuxデスクトップを救う可能性があると期待:
  • 複数バイナリを作成せず静的リンクを使用するため各ディストリビューションも対応せざるを得ない
  • ゲーム自体よりもこのバイナリ配布モデルの実証が重要

■ 4. アプリケーションのバイナリ配布問題

• gitやsparseのような問題と異なり本質的に複雑であり短期間での解決は困難
• 解決策として現状は静的リンクと独自ファイルシステムの同梱が現実的
• Dockerコンテナを用いたアプリケーション配布の可能性に期待
• アプリケーションに求められる要件:
  • グラフィックライブラリやOpenGLなどのUI要素
  • USB・シリアルポート・Bluetooth等のハードウェア直接アクセス
  • Javaのような移植性重視の環境ではハードウェアアクセスが困難

■ 5. ディストリビューションに対する改善要望

• タイムゾーン設定や無線プリンタへの接続など日常操作に管理者権限が不要になること
• 一般ユーザが管理者権限なく作業できる環境を整備してほしい
• ディストリビューションのパッケージ管理者はコアパッケージに集中すべきであり小規模プロジェクトのパッケージ管理は工数の無駄

■ 6. コミュニティにおけるコミュニケーションスタイル

• 自身の攻撃的な言動を認めつつ文化的背景や個性の違いを理由に変える意思がないと表明
• 敬意は与えられるものではなく獲得するものという立場
• オープンソースでは合わない人物を避け自分に合う協力者を選べる利点がある
• 「政治的正しさ」を優先するあまり技術的品質が低下したプロジェクトの存在を懸念

■ 7. systemD

• 予想に反してsystemDを嫌いではないと表明
• 評価する点:
  • Unixのinitシステムの問題を解決した
  • 起動速度の向上は実質的な成果
• 批判する点:
  • バグレポートが無視される事例がある
  • Linuxカーネル固有技術への依存によるポータビリティの欠如

■ 8. GCCのバージョンについて

• 問題となっていたGCCの特定バグはカーネル側で修正済み
• インラインアセンブリを使用しないプロジェクトへの影響は限定的
• GCC 4.2以降のバージョンはおおむね問題なし

■ 9. revokeシステムコールの実装

• 実装に向けた提案パッチを確認中
• CFSと共通のインフラ基盤を使用できる可能性があり設計上の利点
• 実装は確実に行われる見込みだが次バージョンへの搭載は未確定

■ 10. ドライバ開発とioctlの問題

• ioctlはバイナリ互換を破壊しやすい設計上の問題を内包
• 典型的な問題:
  • 32ビットと64ビット環境でデータ型のアライメントが異なる(例: dma_addr_t)
  • ioctl呼び出しのデータ構造変更によるABI破壊
• ドライバ開発者がこれらの問題を認識していないケースが多く理解できるが残念
• GPUレイヤーはかつて同様の問題で被害を受けた後改善された事例がある

■ 11. 後方互換性の維持

• 1991年当時のバイナリが現在も動作するという実績がある
• 真の互換性問題は古いバイナリではなく現代の複雑なバイナリで発生
• UI関連ライブラリのほうが低レベルコードより互換性が壊れやすい
• ライブラリのバグ修正が依存アプリケーションを壊す具体例:
  • glibcがmemcpyの未定義動作への依存を修正したことでAdobe Flash Playerが動作しなくなった
• カーネルでもバグ修正が結果的に互換性を破壊する事例は発生しており完全な保証はできない
• 商用環境では2年遅れでカーネルを使用するケースがあり破壊が遅れて発覚することがある

■ 12. GPL v3とライセンス

• GPL v2の理念: ソースコードを提供する代わりに変更点を還元するという対等な関係
• GPL v3を強く批判する理由:
  • Tivoization条項により「ソースを渡しても自分のデバイスで使えない」状態が生じ得る
  • これはGPL v2の精神に反する
  • FSFがTivoization条項の無効化について不誠実な説明を行ったと批判
• 対応: Linuxカーネルを意図的に「GPL v2のみ」と明示しGPL v3への自動アップグレードを阻止
• GPL v3は別の目的のために選択するライセンスとしては有効であるという立場
• BSD/ISCライセンスは「コードを自由に使ってほしい」という目的に適している

■ 13. FSFへの評価

• FSFの一部の人物を「過激で視野が狭い」と批判
• 寄付先としてはEFFを推奨
• GPL v3をめぐるFSFの説明には不誠実な点があったと明言

■ 14. gitの発展

• gitの現在の成功はJunio Hamano(2006年頃から保守担当)の貢献によるところが大きい
• 良い技術者を見極める基準として「センス(taste)」があるとし、Junioにそれを認めた
• 分散型バージョン管理のモデルが広く受け入れられた
• GitHubがgit普及に大きく貢献した:
  • ホスティングを容易にした
  • オープンソースへの参入障壁を下げた
• かつて批判されたUI上の設計(リネームの扱い等)が後から正当性を認められた

■ 15. セキュリティへのアプローチ

• セキュリティコミットをコミットログに明示的に記載することに反対:
  • 攻撃者が最初に読むのがコミットログであるため情報提供になりかねない
  • あらゆるバグはセキュリティバグになり得るため区別に意味がない
• SELinuxへの評価:
  • かつてはパフォーマンスへの悪影響が深刻だったため無効化していた
  • 現在は改善されており有効化した状態で性能問題を修正した
• セキュリティは単一の層で解決できるものではなくカーネル・ユーザランド双方の多層防御が必要
• セキュリティ研究者(ブラックハット含む)の技術力を高く評価しつつも過度に白黒思考な姿勢を批判

■ 16. 世界観と現状認識

• 公の場での発言が批判的に見えるのは問題発生時にのみ発言するためであり基本的には楽観的
• かつて批判したNvidiaも現在はLinuxカーネルに積極的に貢献するようになった:
  • Android市場の重要性を認識したことが態度変化の主因
• Linux全体として良い方向に進んでいると評価

(2026/04/17)