/note/tech

LanceDB入門

• LanceDB入門 - Speaker Deck

(2026/08/15)

Software Engineering Is Cool, But Is It Interesting?

• Software Engineering Is Cool, But Is It Interesting? | Ertu's Blog

要約:

■ 1. 外から見たソフトウェア開発

• 外部からの称賛:
  • ソフトウェア開発者だと名乗ると、技術に縁のない相手からは小さな称賛が返ってくる
  • 黒い画面に緑の文字が流れ、衛星に侵入する姿を相手は想像している
• 自分自身の過去の認識:
  • 長い間、自分もこのイメージのある種の変奏を信じていた

■ 2. 格好よさと面白さの区別

• 年数とともに薄れる格好よさ:
  • ソフトウェアの世界で働く年数が長くなるほど、実際の仕事は格好よく感じられなくなる
• 職業としての価値は否定しない:
  • ソフトウェアは依然として優れた職業
  • 業界の外の人間には説明しづらい種類の難しさがある
  • 二十年上達を重ねてもなお、初心者に戻った気にさせる発見が定期的に訪れる
• 主張の焦点:
  • この仕事が簡単だと言っているのではない
  • 他のいくつかの職業と比べたとき、それほど面白いとは思えないという点が主張

■ 3. 会話が尽きる技術的境界

• パーティでの典型的な問い:
  • 何を作るのか、どの言語を使うのか、ハッキングはできるのか
  • 意欲的な相手はAIに仕事を奪われるのかと尋ねる
• 誠実に答えた瞬間の断絶:
  • データベース、API、並行処理、分散システムへと話が進む
  • 相手の魂がゆっくり体から抜け出していく様子が見える
• 境界を越えるということ:
  • 退屈な人間になったのではなく、技術的な国境を越えただけ
  • 越えた先では、誠実な回答のたびに五分の説明が追加で必要になる

■ 4. 医師との対比

• 救急医への尽きない質問:
  • 見た中で最も奇妙なもの、負傷の経緯についての嘘を即座に見抜いた経験
  • 家族同士が患者の扱いで対立したときの顛末
  • 助からないと思った相手を救った経験、今も記憶に残る最も悲しい症例
  • こうした問いなら何時間でも続けられる
• 理由は仕事が人で満ちていること:
  • 患者は必ず自分の人生を伴って現れる
  • 家族も、性格も、犯した過ちも、見舞われた不運もそれぞれ異なる
• 患者の物語への参加:
  • 医師は二十分だけその人の物語の一部になることもある
  • 数か月にわたることもあり、その物語が生涯残ることもある

■ 5. ソフトウェアの物語と平凡な日常

• ソフトウェアにも物語は存在する:
  • 本番環境の惨事、崩壊する企業、ひどい管理職、優秀なエンジニア、不可能な納期
  • 金曜午後に誤って削除されるデータベース
  • スキャンダル、失敗、奇怪な顧客、英雄的なデバッグの一夜
  • 個人的な危機のさなかに書かれたとしか思えないコードベース
• 大半の日は火曜日:
  • そうした日々はほとんど訪れず、大半の日はただの火曜日
• 典型的な一日の流れ:
  • ノートパソコンを開き、Slackを確認し、会議に参加し、チケットを別の列へ動かす
  • 四十分かけて原因が一行のコードだと突き止め、それを直す
  • 再びSlackを開き、昼食をとり、もう一つの会議に出る
  • 誰かが「これは後で個別に話そう」と言い、実際に個別で話されることはない
  • 一日が終わり、翌日も驚くほど似た出来事で構成される
• 反復自体はどの職業にもある:
  • 外科医とて毎週水曜に新しい臓器を発見するわけではない
  • ただしソフトウェアは、互いに溶け合って区別のつかない日々を生むことに異常に長けている

■ 6. タクシー運転手やマフィアとの対比

• 話を聞きたい相手はタクシー運転手:
  • 経験を積んだ運転手、とりわけ夜勤を二十年続けた人物の話を本心から聞いてみたい
• 後部座席で起きてきたこと:
  • 酔客、泥棒、セックスワーカー、言い争う恋人たち
  • 葬儀へ向かう人、結婚式から帰る人
  • 人生最良の知らせを受け取った人、最悪の知らせを受け取った人
  • 一言だけ奇妙な文を残し、十五年後も運転手の記憶に残り続ける乗客
• 平均的な一週間を語り比べた場合:
  • 自分とその運転手が同じ席で平均的な一週間を語るなら、どちらの話を先に聞きたいかは明白
• マフィアという極端な例:
  • 本物のマフィア構成員に好きなだけ質問できる状況を想像する
  • 本物のギャングの普通の一日を知りたくない者はいない
  • 質問し尽くす頃には太平洋の底に沈められているだろう
  • プログラマーの話など知ったことではない

■ 7. 例外としての語れるベテラン

• 数十年続けてきた開発者:
  • 奇妙なシステムに携わり、崩壊寸前の企業を生き延びてきた
  • 今日の腕時計より遅い計算機の時代に製品を出荷した
  • 技術が登場し、流行し、嫌われ、消え、十五年後に新しい名前で戻る過程を見てきた
• 最も重要な条件は語りの技術:
  • そうした人物は物語の語り方を知っている
• 例外が成立する瞬間:
  • そのような相手に会うと、ここまで書いたことはすべて成り立たなくなる
  • 誰も自分たちをその席から引き離せず、朝まで座り続けられる

(2026/08/15)

Rails is done

• Rails is done | lucas.dohmen.io

要約:

■ 1. Railsをフォークする理由

• Railsのコア:
  • 時の試練に耐えてきた
  • 現在もWebアプリケーションを構築する優れた手段
• DHHとの根本的な非互換:
  • DHHの世界観は自分の世界観と根本的に相容れない
  • そう感じているのは自分だけではない
• 実現しなかった公開書簡:
  • 約1年前、自分を含む多数の人々がコアチーム宛の公開書簡に署名した
  • 内容はDHHとの関係を断ち、Railsをハードフォークすることの要求
  • それは実現しなかったため、自分たちの手でフォークを行う時期に来ている
• 新しいリーダーシップが必要な背景:
  • 1年前のDavid Celisの記事と数週間前のPaul Battleyの記事がその理由をまとめている
  • 信じ難いことに、状況はそれ以降さらに悪化している

■ 2. Railsは完成しているという判断

• フォーク維持の実現可能性:
  • Railsは巨大なコードベースで、多数のエンジニアが業務時間を投じて改善している
  • 少人数が余暇でフォークを維持できる理由は、Railsが完成しているという事実
• 変更の継続的な観測:
  • The Rails 5 WayをRails 6、さらに7と8へ更新する過程でRailsの変更を注視してきた
• コアの範囲:
  • rails new --minimalで生成されるのはフレームワークのコア部分のみ
  • 内訳はrailties、actionpack、activesupport、activemodel、activerecord、actionview
• コアgemの停滞:
  • 2019年のRails 6.0でZeitwerkオートローダーが導入されて以降、コアgemに大きな変更はない
  • ただしActiveRecordは例外
  • ActiveRecordの改善も大半は2020年の6.1に集中している
    • 例外はat-work encryption、非同期クエリ読み込み、一部の認証方式、複合主キー
• 以降に追加されたもの:
  • 好みで追加できるgemやnpmパッケージにすぎない構成要素ばかり
  • 一連のアセットパイプライン
  • Railsでも他のRuby/PHP/Javaのフレームワークでも使えるJavaScriptライブラリ群
  • コンテナ化されたWebアプリケーションを配備できるデプロイツール
  • Goで書かれたリバースプロキシ
  • ActiveJob、ActionCable、キャッシュのバックエンドとなる新しいデフォルトgem
• 完成していることの価値:
  • Railsは小規模から大規模までのWebアプリのニーズを満たし、付け加えるべきものはない
  • 追加可能な任意のgemを除きコアだけをフォークすれば、対象は安定する
• フォークの実務:
  • Railsリポジトリを監視してセキュリティパッチをフォークへ移植する
  • 性能改善や小さな改善を探し、取り込むかを評価する
  • 挑戦的ではあるが実行可能

■ 3. Mosscapプロジェクト

• コードネームの変更:
  • 本記事の初版ではプロジェクトのコードネームであるAmikoに言及していた
  • AmikoとMosscapは同一のプロジェクト
• 現在の状況:
  • Matrix上に良好なコミュニティが形成されつつある
  • フォークの動作方式に関するスパイクを進めている
  • 関心があれば入口から参加できる
• 主目標:
  • Rails 8.xのLTS版を提供すること
  • ナチ、トランスフォビア、レイシスト、あらゆる偏見を許容しない人々のコミュニティが構築し維持する
• 移行方法:
  • 既存のRails 8.xアプリケーションはgemを差し替え、いくつかの検索置換を行えば動作する
  • 依存関係もフォークされたgemを使うよう、巧妙なaliasハックを用いる
• 目指す性格:
  • Mosscapは退屈で親しみやすいものにする

■ 4. 加える変更

• 互換性の範囲内での修正:
  • 互換性を壊さずに実施できるなら、Railsの欠陥にも取り組む
• アセットパイプラインの混乱:
  • 2021年のBasecampの崩壊でコアチームがフロントエンドの知識を失った
  • それ以降、半端にしか動作しない十数個の手法が併存する絶対的な混沌状態にある
• mosscap newの設計:
  • コマンドのあり方も議論した
  • シェフが全員に同じ料理を出すのはomakaseではなくファストフードであると理解していない人物が設計したものは踏襲しない
• 変更の規模:
  • Rails 6/7/8で慣れ親しんだものからの変更はわずかにとどまる

■ 5. Hanakaiとの関係

• Ryan Biggによる異論:
  • Mosscapの目標に反対するブログ記事を書いた
  • Hanakaiに全員が参加すべきだという提案
• ミッションへの賛同:
  • ある意味ではHanakaiに参加している
  • Hanakaiのミッションとコアバリューには合流する
  • その価値観は、あらゆる背景と経験レベルの人が尊重され、共有し成長でき、誇りと安全を感じられる場であること
  • ナチ、トランスフォビア、レイシスト、あらゆる偏見を許容しないという点も共通
• モノカルチャーの拒否:
  • Tim Rileyと同じく、Rubyはモノカルチャーではなく繁栄するエコシステムであってほしい
  • 彼のキーノートに強く触発された
  • 理想的なジョブキューはMosscap、Hanami、Rodaのいずれでも動作する
• Mosscapの位置づけ:
  • 数多くの素晴らしい選択肢のなかの一つ
  • 大規模なRailsアプリを抱えHanakaiへ書き換えられない人にとって特に良い選択肢を目指す
  • Railsの設計は好きだがそのリーダーシップは好まない人にとっても同様
• 他の選択肢の紹介:
  • Railsとまったく異なる設計を望むならHanakaiコミュニティの取り組みを勧める
  • サーバサイドロジックを追加できる静的サイトジェネレータを望むならBridgetownを勧める
    • この個人サイトもBridgetownで構築している
  • MosscapをWebフレームワーク、Romをデータ層、Dry::Operationを業務ロジックの整理に組み合わせればokonomiの体現となる

■ 6. 結論

• 共存の願い:
  • 全員が共に繁栄できることを望む
• 目的:
  • Rubyエコシステムに選択肢を一つ加えること
  • あらゆる性別、肌の色、性的指向、経験レベル、背景の人々のために作る他のグループに加わること
• 排除の姿勢:
  • ナチ、トランスフォビア、レイシストが悲鳴を上げて逃げ出すことを望む
  • 立ち去らないなら追い出す
• 動機:
  • 後ろめたさを感じずにWebアプリケーションを作り続けたい

(2026/08/15)

産業機械のPLC制御に関する学習メモ

■ 1. PLCの定義と役割

• PLCとは:
  • 産業機械のシーケンス制御、タイマー処理、カウンター処理などを担う制御機器
  • 従来はブロック状の専用ハードウェアとして提供される形態
• 実行専用の頭脳:
  • 電源が入っている限り単体で自律的に動作し続ける
• PLCが担う代表的な要素:
  • シーケンス制御、すなわちリレー的なON/OFF制御、タイマー、カウンター
  • モーション制御、すなわちサーボモータ、パルス発生、位置決め
  • アナログ処理、すなわち温度、圧力等のセンサ値取得とPID制御
  • GP-IB、RS-232C、専用インターフェース等による上位機器との通信
  • 操作パネル（HMI）としての表示、入力

■ 2. PLCの実装形態による分類

• ハードPLC:
  • 従来型であり、専用ハードウェアとして実体を持つ
• ソフトPLC（特定ハード固定型）:
  • 制御をソフトウェア化しているが、動作するハードウェアはベンダー指定の特定機種に固定される
• ソフトPLC（標準化ハード汎用型）:
  • 特定ハードではなく、一定基準で標準化されたハード群に対応する
• バーチャルPLC（vPLC）:
  • ハイパーバイザ、コンテナ等の仮想環境上で動作するソフトPLCの一形態
  • ハードウェアから完全に分離される
• ソフトPLCとvPLCの関係:
  • ソフトPLCは広義の用語であり、必ずしも仮想化を前提としない
  • バーチャルPLCは仮想化技術の利用を明確に前提とする、より進んだ形態
  • 業界内でも両者がほぼ同義で使われる場面があり、用語は完全には統一されていない
• 代表的なソフトPLC製品:
  • Beckhoff TwinCAT、CODESYS対応製品、シーメンスSoftware Controller
  • CODESYSは多数のメーカーのハードウェアに対応し、特定ベンダーへのロックインを避けやすい

■ 3. PLCと汎用PCの役割分担

• 従来型におけるPLC本体:
  • I/Oの読み書きとロジック実行を現場で自律的に継続する
  • PCが外れても運転は止まらない
• 従来型における汎用PC（エンジニアリングPC）:
  • プログラムの書き込みと読み出し、パラメータ設定、稼働監視に使用する
  • GX Works、Sysmac Studio、TIA Portal等の専用ソフトを用いる
  • PLC本体とは物理的に別の機器であり、開発、監視用途で一時的に接続する
• ソフトPLCにおける統合:
  • PLCとPCが物理的に同一のハードウェアに統合される
  • 汎用PCのCPU上でPLCの実行エンジン（ランタイム）そのものが走り、機械はこのPCに直接接続される
  • PCがPLCを制御するのではなく、PC自体がPLCとして機械を直接制御するという理解が正確
• リアルタイム性の確保:
  • 単純なUSBや一般的なEthernetは通常のOS通信スタックを経由するためリアルタイム性が保証されない
  • EtherCATマスター機能を持つ専用NIC、ドライバなど専用のリアルタイムEthernetインターフェースを使用する
  • Windowsへのリアルタイムカーネル拡張、リアルタイムLinux、専用リアルタイムOSの併用等でOS自体をリアルタイム化する
• 指揮者と演奏者の喩え:
  • PLCまたはソフトPLCの上位ロジック層は全体のタイミングを統括する指揮者であり、自らは音を出さない
  • 電流制御、PWM生成といったμs〜数十kHzオーダーの超高速処理は演奏者が担う
  • 演奏者はサーボアンプ等に内蔵された専用マイコン（DSP/FPGA等）であり、自律的に動作する
  • この多段構成は従来型、ソフトPLCのいずれでも変わらない
• エッジ側での分散処理:
  • センサーの一次処理やリモートI/Oターミナルなど、機械側に分散配置された小さなマイコン群も同様の役割を担う
  • 局所的な高速処理をエッジ側で完結させ、上位のPLCやPCは全体統括に専念するという設計思想の表れ

■ 4. 加工機械の制御アーキテクチャ

• バネ、ワイヤー曲げ加工の制御対象:
  • 送り軸、曲げ軸、回転軸、カット軸などが相対位置、相対タイミングで同期する
  • 送り量に対して何mm進んだら何度曲げるという形で同期する、モーション制御が主役の対象
• 同期精度が品質を左右する理由:
  • 曲げタイミングのズレが直接、角度誤差やバネ形状不良につながる
• 現実的な構成の選択肢:
  • 単純なシーケンス制御中心のPLCだけでは同期精度が不足しやすい
  • 電子カム機能を持つモーション統合型PLC（三菱モーションCPU、オムロンNJ/NX＋EtherCAT等）
  • 専用モーションコントローラと上位PLCの組み合わせで、シーケンス部分のみPLCが担当する構成
• 移行の中核作業となる電子カム化:
  • 機械式カムで作っていた曲げタイミングをデータ化する作業
  • 送り軸の位置に対する曲げ軸の目標値という関数（カム線図）として表現する
• プロトタイプ設計の考え方:
  • 目的がロジック検証、機構検証、量産機の制御方式実証のいずれかによって構成を変えるのが定石
  • ロジック、機構検証が主目的ならArduino/STM32とステッピングモータでも電子カムの考え方を十分検証できる
  • 送り軸位置を基準に曲げ軸目標値をテーブル化する構造を検証でき、コストと開発速度を優先できる
  • 量産機の制御方式そのものを早期実証したい場合は、小型のモーション統合PLCで最初から組む方が手戻りが少ない

■ 5. 古いPC制御機械のPLCリプレース

• 既存機械の役割分解:
  • PC-98等で制御されている機械の役割は、シーケンス制御、モーション制御、アナログ処理、上位通信、HMI表示に分解できる
• 置き換えの難易度:
  • シーケンス制御、アナログ処理、HMI表示はPLCとタッチパネルHMIへの置き換えが比較的容易
  • 高速、高精度なモーション制御が絡む場合はPLC単体では不足する
  • その場合はモーションコントローラや産業用PC（IPC）とのハイブリッド構成が必要になることがある
• リプレース時の注意点:
  • I/O、信号の完全な洗い出しが必要であり、配線図が散逸していることが多く現地調査が必要になりやすい
  • Cバス等の専用インターフェースボードの代替設計が必要
  • PLCのスキャンタイムで足りるかというタイミング、応答速度の検証が必要
  • 制御ロジックの仕様化が必要であり、ソースコードが残っておらず実機トレースによるリバースエンジニアリングが発生しやすい
  • 非常停止回路の二重化等、安全規格への適合が必要
• 現実的な進め方の手順:
  • 信号リストとタイミングチャートを作成する制御仕様書化
  • PLCとHMIでの置き換え設計
  • 並行稼働またはオフラインでの検証
  • 段階的な切り替え

■ 6. ハードウェア陳腐化を避けるための技術選定

• PC-98問題の本質:
  • ハードウェアが壊れたら詰むことよりも、制御ロジックが特定ハードウェア、特定技術者に依存し移植できないことにある
• 発想の転換:
  • 陳腐化しない機器を探すのではなく、陳腐化しても被害を最小化できる体制を作ることが重要
• 優先度が高い対策:
  • IEC 61131-3準拠かつEtherCAT/PROFINET/EtherNet-IP等の標準通信規格に対応した機器を選ぶ
  • ロジック、図面、パラメータを標準形式でドキュメント化し外部保管する
• 優先度が中程度の対策:
  • CODESYS等のソフトPLCでハードウェア非依存化を検討する
  • 長期供給方針が明確な大手メーカーの製品を選ぶ
  • 標準I/O、標準コネクタでモジュール構成にする
• 優先度が中〜低の対策:
  • プログラム読み書きのライセンス形態を事前確認する
• 結論:
  • 壊れない機器を探すのではなく、ロジックと知識がハードウェアに縛られない体制を作ることが本質的な対策
  • 標準規格に基づいたロジックとドキュメントが残っていれば、置き換え作業は大変だが可能なレベルに収まる

■ 7. 遠隔操作時の遅延対策

• 階層分離の基本方針:
  • 軸間同期などμs〜ms単位のタイミングを要するリアルタイム制御は現場内で完結させる
  • 遠隔地からは監視と非同期の設定変更のみを行う
• 通信経路の使い分け:
  • 機械内部はEtherCAT等の産業用リアルタイムイーサネットで閉じる
  • 遠隔PC、クラウドとは標準EthernetまたはVPN経由で、秒単位の遅延まで許容される情報のみをやり取りする
• 近年の主流構成:
  • エッジコンピューティングの考え方に基づく構成が主流
  • 現場側の小型PC、ゲートウェイでリアルタイム制御を完結させ、クラウドとは集約データのみを同期する

■ 8. バーチャルPLC化に伴う新たな依存リスク

• 依存対象の移動:
  • バーチャルPLC、ソフトPLCへの移行はPC-98問題の対策として有効
  • 一方で依存の対象を専用ハードウェアから仮想化基盤、ドライバ層へ移動させているだけという側面がある
  • この点は楽観できず、新たなロックインポイントとして認識しておく必要がある
• 依存構造の4層:
  • 最上位はIEC 61131-3準拠プログラムであるPLCアプリケーション（ロジック）
  • 次にTwinCAT、CODESYS等のPLCランタイム
  • 次にハイパーバイザー、リアルタイムカーネル拡張、専用ドライバといったリアルタイム化の仕組み
  • 最下位はPC、NIC等の汎用ハードウェア
• 層ごとの標準化の度合い:
  • 上2層のアプリケーションとランタイムは比較的標準化が進んでいる
  • 下2層のリアルタイム化の仕組みとハードウェアの橋渡しはベンダー独自技術であることが多い
  • 下2層が実質的な依存ポイントになりやすい
• EtherCATマスター機能の依存:
  • Intel i210/i225等の特定チップセットのNICを前提とした専用ドライバでのみ確定的な低遅延通信が保証されることが多い
  • 汎用NICでは性能やリアルタイム性が保証されないことがある
• リアルタイムカーネル拡張の依存:
  • WindowsやLinuxの内部に割り込むタイプの製品が該当する
  • OSのバージョンアップに対してベンダー側が動作保証を追従してくれるかに依存する
• ハイパーバイザーの依存:
  • Intel VT-x/VT-d等、特定CPU世代、チップセットの仮想化支援機能に依存することがある
  • 将来のハードウェア世代でも同じ挙動が保証されるかはベンダーのロードマップ次第
• PC-98時代との依存構造の比較:
  • PC-98時代は依存の中心が専用ハードウェア1点であり、障害時は部品調達不能で完全に詰む
  • バーチャルPLC時代は汎用ハードウェアとベンダー独自ドライバ、リアルタイム化技術の組み合わせが依存の中心
  • ハードウェア自体は代替可能だが、保証範囲外の組み合わせでは性能、安定性が保証されない
  • 互換性マトリクスの管理コストが新たに発生する
• 対策としての互換性マトリクス確認:
  • どのCPU、NICチップセット、OSバージョンで動作保証するかを事前に確認する
  • 保証範囲が広く、かつ継続的に更新され続けている製品を選ぶ
• 対策としてのオープン性の重視:
  • ドライバ、リアルタイム化技術のオープン性を見る
  • 完全にクローズドな独自実装よりも、Linuxカーネル本体にマージされたPREEMPT_RT等の標準機能が望ましい
  • コミュニティベースで存続しやすい技術は特定ベンダーの方針転換の影響を受けにくい
• 対策としてのベンダー分散:
  • ハードウェアとソフトウェアを同一ベンダーで固めすぎない
  • ランタイム、ハイパーバイザー、ハードウェアを別ベンダーの組み合わせで運用できる構成が将来の代替手段確保に有利
• 対策としての枯れた技術の選択:
  • 仮想化、リアルタイム化技術はまだ新しい分野も多い
  • 複数世代のハードウェア交換を乗り越えてきた実績のある製品の方が将来リスクを低く見積もれる

(2026/08/14)

ソフトウェアファクトリーとは何か

• ソフトウェアファクトリーとは何か｜こぎそ

要約:

■ 1. 速度と成果の溝

• 個人の生産性と組織の成果の乖離:
  • AIがコードを書き画面も作れるようになり、個人の生産性は確かに上がった
  • 一方で組織の成果はそれほど伸びていない
• 速度向上が生む副作用:
  • 作る速度が上がった分だけレビューが詰まる
  • 品質のばらつきが広がる
  • 誰も全体を理解していないコードが増えていく
• 速く作れることと良いものを出し続けられることのあいだには、まだ深い溝がある
• この溝への答えとして、2026年に入りAI開発の文脈で「ソフトウェアファクトリー」が再び前面に出てきた

■ 2. ソフトウェアファクトリーの定義

• ソフトウェアファクトリー:
  • AIエージェントを工場の作業者とみなす開発体制
  • 人間が工程を設計し、ソフトウェアを継続的に量産する
• 具体的なフロー:
  • 標準化された形式で仕様が投入される
  • 複数のエージェントが実装とテストを進める
  • 人間とエージェントの成果物が、同じ検査工程を通る
  • 良品条件を満たしたものだけが出荷される
• 良品条件の範囲:
  • 機能要件だけではない
  • テスト、セキュリティ、性能、アクセシビリティ、デザインの一貫性など、出荷を認める条件全体を指す
• この流れが何本も並行で毎日回り続け、主語は個人の技術から組織の工程に移った
• 工場という比喩への抵抗:
  • ソフトウェア開発は創造的な仕事でありベルトコンベアとは違うという反発が、この言葉の歴史の中で繰り返されてきた
  • それでも再浮上しているのは、実装という工程に限れば継続的に量産する条件が揃い始めたため

■ 3. いま語られ始めた背景

• AI Engineer World's Fair 2026:
  • 2026年6月末にサンフランシスコで開催された、6,000人以上が集まる世界最大級のAIエンジニアリングカンファレンス
  • 本会議初日の6月30日には、メインステージのトラック名として「Software Factories」が掲げられた
  • Microsoft、OpenAI、Factory、HumanLayerなどがこのテーマで講演した
• CursorのFDE部門を率いるPauline Brunet氏:
  • 顧客の現場に入り開発体制を一緒に構築するForward Deployed Engineering部門を統括する
  • 会場でのインタビューで、顧客組織とAIソフトウェアファクトリーを構築していると語った
• Stripeの実績:
  • Minionsと呼ばれるコーディングエージェントが、人間の書いたコードを含まないプルリクエストを毎週1,000件以上本番へ送り出している
  • ただし出荷前のレビューと承認は人間が担当する
• OpenAIの実績:
  • 3人のエンジニアがCodexを動かし、手書きコードなしで内部向けベータ版を5か月で構築した
  • リポジトリはアプリケーション、インフラ、ツール、ドキュメントを含めて約100万行に達した
  • マージされたプルリクエストは約1,500件に到達した
• 論点の移動:
  • 個人がAIで速く書く段階はすでに終わった
  • エージェントの群れに開発を任せる体制をどう組むかへ論点が移った
• 企業側の動き:
  • FactoryのようなAIネイティブの開発基盤が、IDEからCIまでをつないでいる
  • コンサルティング会社も、エージェントを前提とした開発体制を扱い始めた
• 個人側の動き:
  • Geoffrey Huntley氏が広めたRalph Loopがある
  • 毎回まっさらなコンテキストでエージェントを起動し、一つのタスクを処理させ、結果をファイルやGitに残して次のループへ進む
  • 巨大なエージェントに長い仕事を任せるのではなく、短い実行を繰り返す
• 上から工程全体を設計する動きと、下から小さなループを積み上げる実践が、同じ開発体制へ近づいている

■ 4. 日本由来の語源

• ソフトウェアファクトリーは新語ではなく、構想の起点は米国だが最初に組織として形にしたのは日本である
• 1968年: Bob Bemer氏が、標準化された道具と管理環境を備えたソフトウェア工場を提唱
• 1969年: 日立が、世界で初めて「ソフトウェア工場」を名乗る開発組織を設立
• 1975年: 米国のSystem Development Corporationがソフトウェア工場を実験
• 1976年から1977年: 東芝、NEC、富士通が工場型の開発体制を展開
• 1991年: MITのMichael Cusumano氏が『Japan's Software Factories』を出版
• 2004年: Microsoftが、パターン、モデル、フレームワークを組み合わせる方法論として再定義
• 2017年: 米空軍がKessel Runを立ち上げ、国防分野でもソフトウェアファクトリーという呼び名が使われる
• 当時と現在の違い:
  • 当時の中心にあったのは標準化、再利用、品質管理
  • 2026年の再解釈では、実装を担う主体としてAIエージェントが加わる
• 人間の仕事は、意図を定義すること、工程を設計すること、出てきた成果を検証することへ寄っていく

■ 5. 工房の品質と工場の品質

• 品質の根拠の違い:
  • 一点物を作る工房では、作り手の腕が品質を大きく左右する
  • 工場では、作り手の技術に加えて、どの工程を通ったかが品質の根拠になる
• 入力の標準化:
  • スコープや受け入れ条件が、同じ形で入ってくる
• 共通の検査:
  • 人間が書いた変更も、エージェントが書いた変更も、同じ検査を通る
• 出力の測定:
  • サイクルタイムや欠陥率などを測定できる
• 再現性:
  • 出荷した変更を、入力・プロンプト・モデルのバージョンから再現できる
  • 生成AIは同じ入力から毎回まったく同じ結果を出すとは限らない
  • 必要なのは完全な再現性より、何をもとに、どの環境で、どのように作られたかを後から追えること
• 個人の腕前の位置づけ:
  • 個人の腕前が不要になるわけではない
  • その腕を、組織で再利用できる基準と工程に移せるかが問われる
  • 品質の根拠が「誰が作ったか」だけでなく、「どの条件を満たし、どの検査を通ったか」に移る

■ 6. 工場を成立させるハーネス

• Addy Osmani氏による定義:
  • 元Googleのソフトウェアエンジニアが構造を整理した
  • ソフトウェアファクトリーを「ハーネスを付けたループを、大きな規模で動かすこと」と説明する
• ハーネスの構成要素:
  • ループを囲む仕組みであり、実行環境と使える道具を含む
  • 実行をまたいで残る記憶、権限、そして何をもって完了とするかを決めるゲートを含む
• 工場という全体像:
  • ハーネス付きのループが何本も同時に回り、仕事のキューから供給を受ける
  • 検査とレビューを通って本番に流れ込み、障害やユーザーの声は再びキューに戻る
  • 人間は全体の設計と責任を担う
• 巨大なエージェントを一体育てる方向とは異なり、小さなループが役割を分担し受け渡しと検査でつながる、ループでできた組織図である
• WorkOSのRyan Cooke氏の指摘:
  • 同カンファレンスで「No, That's Not a Software Factory」という講演を行った
  • サンドボックスを用意しエージェントを何体か並べただけでは工場にならない
• 成果を安定させる要素:
  • 成果を安定させるのはモデルだけではない
  • その周囲にある規約、実行環境、検証ゲート、完成の定義である
  • エージェントに任せる範囲が広がるほど、任せ方を定義する構造の側が重要になる

■ 7. デザインハーネスとの重なり

• デザインハーネス:
  • 2026年5月から提唱している考え方
  • 制約、コンテキスト、検証、フィードバックループの4層で、デザインの判断をAIが読める仕様に落とす
• ソフトウェアファクトリーの条件と比べると、必要な部品が大きく重なる
• 標準化された入力には、制約とコンテキストが必要になる
• 共通の検査には、検証可能な品質基準が必要になる
• 出力の測定には、結果を次の実行へ戻すフィードバックループが必要になる
• 追跡可能性には、判断の根拠や変更履歴を残す仕組みが必要になる
• 部品が重なる理由:
  • 別々の議論が似た部品を必要とするのは、エージェントへ仕事を任せる際の問題が共通しているため
  • エージェントは組織の暗黙知や品質基準をそのままでは読めない
  • 制約として渡し、結果を検証し、失敗から基準を更新する必要がある
• エージェントに案件を任せるなかで作り込んできたのも制約や検証の仕組みであり、工場でいえば検査工程にあたる
• ソフトウェアファクトリーという名前があることで、個別のプロンプトやツールの話ではなく組織の開発工程として議論できる

■ 8. デザインとの親和性

• 工場が送り出すもの:
  • 工場が送り出すのはコードだけではなく、利用者が触れるソフトウェアである
  • 良し悪しを決めるのは、画面の一貫性、文言のトーン、操作したときの反応、エラー時の振る舞いといったデザインの判断である
  • 良品条件のかなりの部分は、デザインの言葉で書かれる
• 良品条件の具体例:
  • 指定外の色や余白が使われていないか
  • キーボードだけで操作できるか
  • ローディング、空、エラーの状態が揃っているか
  • 文言がトーンの規約に沿っているか、画面差分が許容範囲に収まっているか
• こうした条件を機械と人が確認できる形にすれば、デザインは実装前の制作物ではなく出荷判定の一部になる
• 現場で起きている変化:
  • AIがある程度デザインできるとわかった時点から、品質をどう担保するかという相談が増えた
  • 工場化の相談は、多くの場合、品質基準の相談として持ち込まれる
• 工場化の適用範囲:
  • すべての開発が工場になるとは考えていない
  • 何を作るべきかがまだ決まっていない探索段階では、人間の観察と判断が必要になる
  • 工場が扱いやすいのは、意図と良品条件をある程度定義できる仕事である
  • 探索が消えるのではなく、探索と量産の境界を設計する必要がある

■ 9. 「暗い工場」の失敗

• 明るい工場と暗い工場:
  • Osmani氏は製造業の無人工場になぞらえ、人が判断に関わる工程を「明るい工場」と呼ぶ
  • 機械の検証だけで出荷する工程を「暗い工場」と呼ぶ
  • 暗い工場とは、人がいない工場では照明をつける必要がないという意味である
• 明るい工程:
  • 間違えたときの影響が大きい場所に、人の設計やレビューを残す
• 暗い工程:
  • 完了を機械的に判定できる仕事を、人が読まずに出荷する
• 工程ごとのスイッチ:
  • 組織全体を二つに分類する話ではない
  • どのループを暗くできるか、工程ごとにスイッチを決める話である
  • 小さく、失敗を自動で判定でき、影響範囲も限られている変更は暗くできる
  • 認証、課金、公開API、長期的な設計判断のように影響が大きい工程には人を残す
• HumanLayer社の実験:
  • AIコーディングIDEとチーム向け開発基盤を提供する同社が、約4か月、人が生成コードを読まない全自動の開発を試した
  • 創業者のDex Horthy氏によれば、障害が起きたとき、すでに人間の理解から離れていたコードを読み直し手作業で原因を突き止めることになった
  • テストは通っているのに、中身を理解している人がいないコードが増えていた
• 理解負債:
  • Osmani氏はコードの量と人間が理解している範囲の差をこう呼ぶ
  • 暗い工場はレビュー待ちをなくせるが、同時に理解負債を速いペースで積み上げる
• 同一エージェントによる自己検証の問題:
  • コードとテストを同じエージェントが同じ前提から作ることが問題となる
  • 仕様を誤解したまま実装し、その誤解に沿ったテストを書けばテストは通る
  • 緑色のチェックだけでは、意図に合っているかを証明できない
• 検証こそが制約:
  • 生成量は計算資源を増やせば拡大できるが、検証に使える人間の注意には限りがある
  • ソフトウェアファクトリーの制約は、どれだけコードを作れるかではなく、どれだけ安く速く確実に検証できるかである
  • 工場化の明暗を分けるのは検品の設計である
• 検品設計で問うべきこと:
  • どの工程は自動検査で足りるのか、どこに人の目を残すのか
  • 誰が良品条件を定義し、失敗したときに責任を持つのか
  • 自動化できる工程を増やすには、まず検証できる工程を増やす必要がある

■ 10. 基準の言語化

• 人間の持ち場の移動:
  • 人間は工場から消えたのではなく、持ち場が移った
  • ラインの中で変更を一つずつ作る側から、ラインを設計し重要な判断に参加し出口のゲートを守る側へ移る
• これからのデザインに求められるもの:
  • 作れることに加えて、何を良いとするかを言語化できることの比重が大きくなる
  • 良い画面を一度作れるだけでは、毎日動く工場の品質は保てない
  • 判断を制約、規約、テスト、レビュー項目として残し、人間とエージェントの両方が使える形にする必要がある
• 経営側の打ち手:
  • 個人にAIツールを配るだけでは、生成量が増えた先でレビューが詰まる
  • 良品条件、検査工程、判断の責任に投資した組織ほど、量産の速度と品質を両立しやすくなる
• ソフトウェアファクトリーを成立させるのは、エージェントの数ではなく、組織が自分たちの基準をどこまで工程にできるかである

(2026/08/14)

Webサービスの終わらせ方

• Webサービスの終わらせ方

要約:

■ 1. サービス終了の困難さ

• 作るより消すほうが大変:
  • Webサービスは作成時より終了時のほうが面倒
  • サーバーを止めるだけでは終わらず、多数の撤去作業が残る
• 終了時に必要な作業:
  • 新規登録停止、課金停止、書き込み停止
  • ユーザー通知、個人データ削除、Webhook停止
  • APIキー削除、DNS削除、リポジトリ整理
• 複数SaaS統合の代償:
  • 各SaaSは導入が容易な一方、解約時はUIの異なる管理画面を巡回する必要がある
• 処分対象の技術スタック:
  • インフラはCloudflare Workers、Supabase、GitHub
  • APIはGemini API、監視はSentry、分析はGoogle Analytics
  • 収益はPolarとGoogle AdSense、加えて独自ドメイン

■ 2. 終了方針の決定

• まず「どう死ぬか」を決める:
  • 終了方針の決定が最初の必須作業
  • 方針がなければ削除の判断ごとに迷い、本番環境で試行錯誤する羽目になる
• 事前に決めるべき項目:
  • 終了日、新規登録停止日、既存ユーザーに許す操作の範囲
  • 購入済みコンテンツの扱い、データ削除期限、決済履歴の保持有無
  • サポート終了時期、ソースコードの保管方針、本番データのバックアップ有無

■ 3. 段階的な撤退戦

• 一撃必殺ではなく撤退戦:
  • 一度にすべてを止めると、終了処理自体に必要な機能まで止まる
• 3段階の停止設計:
  • 第1段階は新しい利用の停止
  • 第2段階は終了日まで読み取り専用を維持
  • 第3段階は完全停止とインフラ撤去
• 店舗の比喩:
  • 新規客の入場禁止、来客をすべて帰す、在庫処分という順序に相当する

■ 4. 第1段階: 責任を増やさない

• 新規利用の停止:
  • 新規登録、購入、回答保存、ペアリング、データ更新を止める
  • 終了日後に新規ユーザーからサポート要請を受ける事態を避ける
• ボタンを消して満足してはいけない:
  • UIはセキュリティ境界ではなく、APIを直接叩けばバイパスされる
  • 玄関に本日休業と貼ったあと、裏口を全開にしている状態に等しい
• 停止すべきレイヤー:
  • 画面・フォーム、サーバーAction、APIエンドポイント
  • 認証サービス、DB権限（RLS）、決済設定

■ 5. 読み取り専用モードと認証停止

• 読み取り専用モードの実装:
  • 終了日までは既存ユーザーによるデータ閲覧を許可する
  • 環境変数 SERVICE_READ_ONLY で制御し、書き込みは403で拒否する
  • 読み取り処理と書き込み処理が分離できているかの確認にもなる
• Authもちゃんと止める:
  • フロント側のサインアップ画面を消しても、認証APIが生きたままでは不十分
  • 認証APIを直接叩けばフロントエンドの制限をバイパスできる
• 認証側で行う対策:
  • Supabase側で登録を無効化する
  • RLSと権限設定により一般ユーザーの直接書き込みを拒否する
• 権限剥奪のやりすぎに注意:
  • 終了するからと全権限を剥奪すると、終了処理自体が実行できなくなる

■ 6. ユーザーへの終了通知

• 通知に含める情報:
  • 終了日、新規登録・購入の停止、終了日まで使える機能
  • アクセス不可となる時点、問い合わせ先、データの扱い
• 通知内容の記録:
  • 人間の記憶はログではなく、終了作業中はとりわけ信用できない

■ 7. 完全停止用PRの事前準備

• 当日にコードを書かない:
  • 終了日当日に本番環境で緊急にコードを書くリスクを避け、PRを事前に用意する
• 停止時のレスポンス設計:
  • Web画面は終了案内ページ、APIはJSON形式のエラーレスポンスを返す
  • ステータスコードは410 Goneとする
  • キャッシュ制御は no-store、SEO設定は noindex, nofollow とする

■ 8. スケジュール実行の不確実性

• GitHub Actionsのcronは時刻を保証しない:
  • 予約実行が予定時刻から大幅に遅延した
  • cronに23:59と書いても、cronは約束を覚えていない
• 代替手段:
  • 事前実行で余裕を持たせる、外部スケジューラーを使う、当日手動で実行する
  • アプリケーション自体で時刻を判定する、CDN・DNS側で設定する

■ 9. デプロイ成功とサービス停止は別

• CI成功でもサービスが止まらない:
  • 停止処理をReact Routerのmiddlewareに実装した
  • 設定が v8_middleware: false であり、機能自体が無効化されていた
  • コードは存在し、型チェック・テスト・ビルド・デプロイはすべて成功したが実行されなかった
• 確認すべき段階:
  • PRのマージ、ビルド成功、デプロイ成功
  • 新バージョンへの経路確保、停止処理の実行、外部から見た期待レスポンス
• 緑のチェックマークの限界:
  • 緑色のチェックマークは心を落ち着かせるが、本番環境を止めはしない

■ 10. curlによる最終確認

• 最後に信じられるのはcurl:
  • 管理画面の状態表示ではなく、HTTPレスポンスを直接確認する
  • 外からcurlして死んでいたら死んでいる、観測可能な事実のみを信頼する
• 確認方法:
  • curl -I でヘッダを確認し、curl -i で詳細を確認する
• 期待する結果:
  • 410 Gone、SERVICE_CLOSEDエラー、no-storeのキャッシュ制御、noindexのロボット指示
• 接続不能の確認対象:
  • ルートドメインとwwwサブドメインが解決不可であること
  • Worker直接URLとAPI・Webhook URLが接続不可であること

■ 11. インフラ撤去の順序

• 撤去は順序が重要:
  • 前後関係を誤るとサービス終了そのものに支障が出る
• 決済Webhookを最初に止める:
  • アプリケーション削除後も決済サービスがPOSTを再送し続ける
  • 商品を販売停止または非公開にし、Checkoutを止め、Webhookを削除する
  • 決済履歴は会計と問い合わせ対応に必要で、ユーザーデータと同じ保存方針では扱わない
• Workerとドメインの削除:
  • Cloudflare Worker、Custom Domain、Worker Route、DNSレコードを削除する
  • Worker用のVariablesとSecrets、GitHubの自動ビルド連携も削除する
  • ドメインの自動更新停止は即時消滅を意味せず、契約期限まで存続する
  • 即時停止にはDNSとRouteの削除が必要
• ユーザーデータの削除:
  • Authユーザー、回答データ、利用履歴、購入権限、Storage内ファイルを削除する
  • 本番ユーザーデータのバックアップは取らない方針を採り、一応ダンプしておく誘惑に抵抗する
  • 削除日時、削除前後の件数、Authユーザー0件、Storage空、バックアップ未実施の判断を記録する
  • 最後にSupabaseプロジェクト自体を削除し、確認ダイアログでプロジェクト名を入力する
• APIキーを一つずつ失効させる:
  • Gemini APIキー、Sentryプロジェクト、Google Analyticsプロパティ、AdSenseサイト設定を処理する
  • Cloudflare Secrets、Supabase Personal Access Token、GitHub ActionsのSecretsとVariablesを処理する
  • プロジェクト削除は認証情報の自動失効を意味せず、明示的な失効が必須
  • ほぼ無害だろうという判断が危険を招く
• GitHubリポジトリを墓石にする:
  • 本番の秘密情報を無効化し、Actions SecretsとVariablesを削除する
  • 不要なWebhookとDeploy keyを削除し、予約実行Workflowを無効化する
  • ローカルファイルを整理し、リポジトリを非公開にしたうえでArchiveする
  • DB構造とマイグレーションは参照・監査用にGitへ残し、本番ユーザーデータは残さない

■ 12. 敗戦処理チェックリスト

• チェックリストの6区分:
  • 方針、事前停止、最終停止、データ削除、外部サービス、最終整理の順に並ぶ
• 方針の項目:
  • 最終終了日、新規登録・購入停止日、既存ユーザーに残す機能の明示
  • 購入済みコンテンツの扱い、データ削除期限、バックアップ方針、問い合わせ先
• 事前停止の項目:
  • 新規登録と新規購入の停止、書き込みUIと書き込みAPIの停止
  • 認証サービス側の登録停止、DB権限とRLSの確認、対象ユーザーへの終了通知
• 最終停止の項目:
  • 停止用変更の本番反映、WebとAPIのレスポンス確認
  • 決済Webhook停止、Worker・サーバー削除、DNSとCustom Domainの削除
  • 外部ネットワークからの接続不能確認
• データ削除の項目:
  • Authユーザー削除、DB個人データ削除、Storage削除
  • 削除結果の記録、本番バックアップ方針の確認、DBプロジェクト削除
• 外部サービスの項目:
  • 決済商品とWebhookの停止、AI用APIキーの失効、エラー監視プロジェクトの削除
  • アクセス解析の削除、広告設定の削除、CI/CD Secretsの削除、Personal Access Tokenの失効
• 最終整理の項目:
  • ドメイン自動更新停止、ローカル秘密情報の削除
  • リポジトリの非公開化とArchive、問い合わせ先の維持、完了日時の記録
• チェックリストの位置づけ:
  • サービス終了は機能開発と同等の正式な工程管理を要する

■ 13. まとめ

• サービス終了の本質:
  • 重要なのはコードを止めることではなく、責任を順番に片付けること
• 痛感した3点:
  • 新規利用の停止はUI・API・認証・DBのすべてのレイヤーで行う
  • 完了の判断はマージやデプロイの成功ではなく本番のHTTPレスポンスで行う
  • ユーザーデータ、決済履歴、ソースコードはそれぞれ別の方針で扱う
• 個人開発観の転換:
  • 失敗したら閉じればいいという理解は誤り、サービス終了にも実装が必要
  • 個人開発はデプロイまでではなくArchiveまで
• 最終的な教訓:
  • 緑のチェックマークで満足せず、curlで検証する
  • 終了日に元気に動作していたサービスが、この逆説的な教訓を残した

MEMO:

• 知見だ

(2026/08/14)

How Tailscale helped find the SQLite WAL-Reset bug

• How Tailscale helped find the SQLite WAL-Reset bug

要約:

■ 1. 障害の経緯と謝罪

• 昨年末からの不安定な稼働率:
  • ステータスページに現れた傾向がそのまま年明けまで継続
  • 多くの障害はSQLite深部に潜む単一のバグが原因
• 数か月に及ぶ徹底的な調査:
  • 夏を迎えた現在、バグを発見し、理解し、修正したと確信している
• 顧客への謝罪:
  • Tailscaleに信頼性を期待する顧客の期待に数か月応えられなかった
  • 何が起き、どう対応し、最終的にSQLite中核の長年のバグをどう発見したかを説明するために本記事を公開する

■ 2. 制御プレーンのアーキテクチャ

• シャード構成の制御プレーン:
  • クライアントからはcontrolplane.tailscale.comという単一の公開エンドポイントに見える
  • 内部的には複数の協調サーバ（シャード）に分割されている
• テイルネットとシャードの関係:
  • 各テイルネットは同時に1つの内部シャード上に存在し、シームレスに別シャードへ移行できる
  • シャードは内部実装の詳細であり、利用者が自分のシャードを知る必要はない
• シャードごとのSQLiteデータベース:
  • 各シャードはそのシャード上のテイルネット情報をすべて保持するSQLiteデータベースを持つ
  • 単一のGoプロセスがそのデータベースを排他的に利用し、制御プレーンを提供する
  • この単一書き込み設計はSQLiteの本来意図された使い方そのもの
• SQLite採用の理由:
  • 2022年から主データベースとして使用
  • よく知られ、信頼でき、広く使われている「退屈な技術」であることを良い意味で評価した
  • 他社もはるかに大規模な運用で問題なく使っており、同様に無風の運用を期待していた
• バックアップの仕組み:
  • 数分ごとにデータベース全体のスナップショットを取得し、SQLiteファイル全体をS3バケットへアップロードする
  • この構成は2023年初頭から無事故で稼働していた

■ 3. データベース破損の発生

• 最初の破損の検出:
  • 昨年8月、S3バックアップを読むデータパイプラインが1つのデータベースでエラーを報告
  • PRAGMA integrity_checkをバックアップに実行したところ、実際に破損していた
• 破損の異常性:
  • SQLiteの破損は起こり得るが極めて稀であり、通常運用で遭遇すべきものではない
  • 該当データベースを修復し原因を調査したが成果は得られなかった
• 破損の再発:
  • 大規模運用では稀な事象もある程度の頻度で起こるため、再発に驚くべきではなかった
  • 根本原因を解決するまでの6か月間で、合計19件の独立した破損が発生

■ 4. 破損がもたらした影響

• データ消失の範囲:
  • 制御プレーンは設定データのみを扱い、テイルネットとデバイスのメタデータを保持する
  • 秘密鍵やネットワークトラフィックは一切含まれない
  • 初期のインシデントでは、新規追加デバイスや設定変更が数件永続化されず、少量のメタデータの再入力が必要になった
• 修復中の停止:
  • 破損のたびに該当シャードの制御プレーンプロセスを停止して修復または復元する必要があった
  • そのシャード上のテイルネットは復旧中に制御プレーン全体が消失するため苦痛を強いられた
  • 初期は1時間超のダウンタイムだったが、インシデントを重ねるごとに復旧を高速化した
• メッシュネットワークへの影響:
  • 各テイルネットはデバイス同士がピアツーピアのWireGuard接続を張るメッシュネットワーク
  • デバイスは参加時に制御プレーンから他デバイスの一覧を取得しないと新規接続を確立できない
  • SQLite停止中にオンラインになったデバイスは接続できなかった
• 既存接続と管理機能:
  • 修復中も既にオンラインのデバイス同士の接続は維持された
  • ただしネットワークの変更を知ることはできなかった
  • 該当テイルネットは管理コンソールとTailscale APIへのアクセスも一時的に失った
• 信頼への広範な影響:
  • 影響を受けるテイルネットが少数でもグローバルなインシデントとしてステータスページに掲載する
  • そのため自分に無関係なインシデント表示を多くの人が目にした
  • 実際には大多数のシャードとテイルネットは破損に一度も巻き込まれていない
  • それでも直接の影響の有無にかかわらず、繰り返すダウンタイムは信頼を損なう

■ 5. 難航した初期調査

• 初期のあらゆる試みを退けたバグ:
  • 最初の破損時点から信頼性への深刻な脅威と認識し、多大なエンジニアリング時間を投入したが修正は容易でなかった
• 変更履歴とコードの精査:
  • 最近の変更を調べたが関連しそうなものはなかった
  • SQLiteと接する低レベルコードは数年前に書かれ、それまで問題がなく、誰も触っていなかった
  • 該当コードを細部まで再レビューしたが、観測された破損を引き起こす欠陥は見つからなかった
• 共通要因の不在:
  • 特定のシャード、顧客、テイルネット機能、時間帯、負荷水準のいずれとも結び付かなかった
  • 何が挙動を引き起こしているのか見当がつかなかった
• 再現不能ゆえの受動的計測:
  • 信頼できるトリガ条件がないため合成的に再現できなかった
  • 本番環境に受動的なフォレンジック用テレメトリを仕込み、破損の現行犯を押さえるしかなかった
  • データベース障害の診断情報を本番で集めるのは最も避けたい手段だったが、選択肢がなかった
• 不規則な発生間隔:
  • 数時間おきのこともあれば数週間空くこともあった
  • 次の診断ダンプがいつ得られるか読めず、進捗予測と作業計画が困難だった
  • 10月から12月にかけて6週間にわたり破損が止まり、その後クリスマスの歓迎せざる贈り物として再発した

■ 6. SQLite開発者との協業

• プロフェッショナルサポート契約の締結:
  • 迅速で容易な修正にならないと判断し、SQLite開発者にサポート契約を申し入れた
  • 深い専門知識と経験に直接アクセスでき、アーキテクチャとインシデントについて詳細な技術的議論を重ねられた点で優れた判断だった
• 複数の仮説の検証:
  • close()時のPOSIXロックの破損、SQLiteが所有するメモリの誤管理、スレッド安全性を無効化した状態での複数スレッドからの誤使用などの理論を洗い出した
  • インシデントのたびにデータを集め、診断を追加し、体系的に理論を排除していった
  • 真のバグへ徐々に収束していった

■ 7. 運用面の緊急対策

• 復旧の自動化とダウンタイム最小化:
  • 根本原因の調査中も稼働中のプラットフォームを運用する必要があったため積極的な手を打った
• 具体的な施策:
  • 破損検知時にシャードの制御プレーンを即座にハードストップさせる設定
  • バックアップに対しPRAGMA integrity_checkを継続実行する自動バックアップ監視の導入
  • ランブックとオンコール訓練の改善
• 効果:
  • 対応時間を1時間未満に短縮した

■ 8. トランザクションログパイプラインと手がかり

• 新たな復旧手段の必要性:
  • 直近の正常なバックアップへの巻き戻しは多くのデータを失う
  • 破損済みデータベースの修復は潜在的に危険
  • どちらにも依存しない復旧方法を求めた
• トランザクションログの仕組み:
  • データベースを変更するすべてのSQL文を別のログファイルへストリーミングする方式を構築
  • SQLiteは単一書き込みで直列化可能トランザクションのため、トランザクション履歴は完全に線形かつ決定的になる
  • PostgresやMySQLのような複数書き込みデータベースでは成立しない性質
• 復旧手順:
  • 直近の正常なバックアップに対しトランザクションを再生することで、破損を安全に回避しつつ最新状態へ復元できる
• 予期せぬ手がかり:
  • 2件のインシデントでトランザクションログがきれいに再生できなかった
  • あるトランザクションが書き込んでコミットしたデータが、後続のトランザクションから不可解に見えなくなっていた
  • 書き込みがエラーも出さずに消失しており、本来あり得ない事象だった

■ 9. WALとチェックポイントの仕組み

• ページ単位の構造:
  • SQLiteデータベースはページと呼ばれる情報の小さなブロックの連なりで構成される
  • 更新時には一部のページを新しい情報を持つページに置き換える必要がある
• ライトアヘッドロギングの採用:
  • 性能と並行性を高めるためWrite-Ahead Loggingを有効にして運用している
  • 新しいページはデータベースファイルへ直接書かれず、WALファイルへ書かれる
• チェックポイント処理:
  • WALファイルに無制限に書き続けることはできず、いずれ本体のデータベースファイルへ書き戻す必要がある
  • この処理をチェックポイントと呼ぶ
• 手動制御という非標準運用:
  • 通常の構成ではSQLite自身がチェックポイント時期を決め、利用者にも開発者にも不可視
  • 制御プレーンでは高速で一貫性のあるバックアップのためチェックポイントを手動制御している
  • 原因候補を消していく過程で、この非標準的手法が疑わしく見えてきた
• 統計値の異常:
  • 破損時のメトリクスで、SQLiteがWALファイル内の実在ページ数より多くのページをコピーしたと報告していた
  • WALに10ページしかないのに20ページがデータベースへコピーされるのは明らかな異常

■ 10. tmstmpvfs shimによる可視化

• SQLiteの階層構造:
  • 最上層はパーサとコードジェネレータで、SQL文をSQLite内部のデータ構造へ変換する
  • 内部データ構造はページャへ渡され、ディスクへ書く個々のページに分割される
  • 実際のディスク書き込みはOSインターフェース、すなわち仮想ファイルシステムが担う
  • 現在の主流の仮想ファイルシステム実装はUnix向けとWindows向けの2つ
• 層の差し替え可能性:
  • 各層を別実装に置き換えたり、既存層をラップして情報を得たりできる
• 新しいデバッグツール:
  • チェックポイント処理にバグがあるとしばらく疑っていた
  • SQLite開発者は仮想ファイルシステムをラップし、追加のトレース情報とデータベース変更ログを出力するシムを作成した
  • このラッパーはtmstmpvfs shimと呼ばれ、ソースコードはSQLiteの公開リポジトリで入手できる
• 本番投入:
  • シムを本番環境へ投入し、次の破損を待った
  • 幸か不幸か長く待つ必要はなかった

■ 11. WAL-Resetバグの正体

• バグの特定:
  • 次の破損後、tmstmpvfs shimの追加ログによりSQLite開発者がバグを発見し修正した
  • 正体はチェックポイントと書き込みトランザクションの間で起きる稀なデータ競合
• 発生メカニズム:
  • チェックポイント中の特定のタイミングで書き込みが発生するとチェックポイント処理が混乱する
  • 一部のページをWALからデータベース本体へコピー済みと誤認するが、実際にはコピーされていない
  • それらのページは永久にデータベースファイルへ書かれず、そのデータは失われる
  • 失われたページを参照するインデックスなどの他のページは書き込まれるため、ファイルが破損する
• バグの命名と歴史:
  • SQLite開発者はこれをWAL-Resetバグと命名した
  • 少なくとも16年間SQLiteに存在していたと推定される
  • 極めて稀であるがゆえに長期間残存し、テスト環境では意図的に発生させるコードを追加する必要があるほどだった
  • 修正では、他スレッドによるWALのリセットを検知する追加チェックをチェックポイント関数に加えた
• 観測事象との整合:
  • このバグがすべての不可解な挙動の原因だと確認された
  • 破損、きれいに適用できないトランザクションログ、一貫しないチェックポイント統計のすべてを説明した
• 遭遇しやすかった理由:
  • チェックポイントを手動制御し、非常に積極的な頻度で実行していた
  • 稀な条件で起きるバグでもいずれ必ず踏むことになる状況だった
• 転機としての意味:
  • 数か月の混乱と不確実性の末に、破損の妥当な理論と展開可能な修正を手にした瞬間

■ 12. 修正版の展開と二次的な問題

• 3.52.0の段階的展開:
  • SQLite開発者は修正をSQLite 3.52.0としてリリースし、公開次第すぐ展開する準備を整えた
  • まず少数のカナリアシャードへ、順調な稼働を確認してから残りの制御プレーンへ展開した
• 展開直後の警報:
  • バックアップ監視が即座に赤くなり、13のデータベースで破損を報告した
  • 極めて憂慮すべき事態だったが、復旧手順に従ってすべて修復し、問題なく収束した
  • これらは真の破損ではなく、当該SQLiteバージョンの第二の問題によるものだった
• 陳腐化した式インデックスのバグ:
  • エラーをSQLite開発者と共有した結果、stale expression indexに関するバグが判明した
  • 計算値にインデックスを作成した後に計算内容が変わると、インデックスに不一致な値が残る
  • その不一致がPRAGMA integrity_checkで破損として報告される
• 自社側の該当条件:
  • 高精度タイムスタンプをテキストとして保存し、VIRTUAL生成列で浮動小数点数へ変換していた
  • データ競合を修正した3.52.0は、テキストから浮動小数点数への変換の丸め挙動を微妙に変える最適化も含んでいた
  • カナリアシャードには変化した丸め挙動を引き起こすタイムスタンプが存在せず、段階的展開で検知できなかった
• 双方の対処:
  • 誤検知を招くため、SQLite開発者は3.52.0を撤回し、WAL-Resetバグの修正のみを含む3.51.3を公開した
  • 自社側はタイムスタンプの精度を整数秒へ落とすことで対処した、テキストから整数への変換は曖昧さがない
  • SQLite開発者は3.53.0で自動的に自己修復するインデックス機能を作り、陳腐化した式インデックス問題を防いだ

■ 13. 修正の実証

• 慎重な姿勢:
  • 制御プレーン全体へ修正を展開し勝利宣言をしたかったが、なお慎重であった
  • 破損が起きないことは修正の証明にならない、既に6週間の欺瞞的な平穏を経験している
• 積極的な証明手段:
  • 本番環境でデータ競合が実際に起きている積極的な証拠を求めた
  • 書き込みトランザクションとWALリセットの衝突が原因と理解した上で、両操作が重なった際に警告を記録するようSQLiteドライバへパッチを当てた
  • 警告が出てもデータベースが破損しなければ、修正が破損を防いだと判明する
• 待機と発火:
  • 警告を展開して待ち続けたが何週間も発火せず、警告の不具合や理論の誤り、真のバグの残存を疑い始めた
  • 2か月後、待ち望んだアラートがついに発火した
• 結論:
  • このアラートはWAL-Resetバグの発生条件が本番環境で実際に起きることを証明した
  • 6か月に及ぶ不安定な稼働の原因がこのバグである可能性が高いと結論づけた
  • そのアラート以降、本稿執筆時点でさらに4か月間データベース障害なしで稼働している

■ 14. 教訓と成果

• 全体の総括:
  • 6か月をSQLiteのバグ探しに費やすことなど誰も望んでいなかった
  • 顧客にとっても社員にとっても極めて苛立たしい経験であり、この不安定さを過去のものにできて安堵している
• 非標準運用のリスク:
  • 退屈な技術を非標準的な方法で運用することはリスクである
  • 一般的な経路と標準構成は極めてよくテストされ信頼できる
  • 大多数の利用者は標準構成でSQLiteを使い、この種の問題に遭遇しない
• 自社の位置づけ:
  • 実施していたことはすべて公開され文書化された、サポート対象の構成だった
  • それでもチェックポイントを手動制御し独自の積極的な頻度で走らせたことで、踏み固められた運用の道から外れていた
• 関係者への謝意:
  • 解決はTailscaleのエンジニアリングとサポート、SQLiteのコアメンテナを含む数十人規模の横断的な取り組みだった
  • 影響がこれ以上悪化しなかったのは全員の功績
  • 繰り返すダウンタイムは影響人数にかかわらず信頼を損なうと理解しており、追跡中の顧客の忍耐と支援に感謝する
• 得られた成果:
  • 苛立たしい期間ではあったが、以前より強い状態に立っている
  • SQLiteの長年のバグが修正された
  • 探索の過程で見つけた他の数十件の付随的な問題も修正した
  • 競合状態の切り分けを即座に助けたオープンソースのSQLite VFSシムに資金を提供し、将来の類似バグ追跡にも役立つ
  • データベースのバックアップと復旧の手順を洗練させ、十数回にわたり実地で検証した
• 今後への構え:
  • 同種のデータベース障害が再び起きないことを願うが、起きたとしても備えはできている

(2026/08/13)

EM選考プロセスを公開します 〜面接で何を見ているか、なぜそう設計したか〜

• EM選考プロセスを公開します 〜面接で何を見ているか、なぜそう設計したか〜 - ROXX開発者ブログ

(2026/08/13)

Cloudflareは16年間ずっと同じことをしている。「通り道を支配する」という設計思想を知る

• Cloudflareは16年間ずっと同じことをしている。「通り道を支配する」という設計思想を知る

(2026/08/13)

Google、開発者向けブログでGo言語がAIを活用したソフトウェア開発に適している理由を解説

• Google、開発者向けブログでGo言語がAIを活用したソフトウェア開発に適している理由を解説 | gihyo.jp

(2026/08/12)

ExtendDB

• ExtendDB — The DynamoDB API, everywhere you run code.
• GitHub - ExtendDB/extenddb: ExtendDB · GitHub

■ 1. ExtendDBの概要

• DynamoDB互換アダプター:
  • Amazon DynamoDBのAPI（ワイヤープロトコル）と互換性を持つオープンソースソフトウェア
  • AWSがメンテナンスを担当
• コンセプト:
  • DynamoDBのSDK・クライアントコードはそのままに、実際のデータ保存先を自分のインフラへ置き換えられる
  • キャッチコピーは「同じSDK・同じコードで、自分のインフラで動かす」

■ 2. 仕組みと対応範囲

• リクエストの流れ:
  • アプリはこれまで通りDynamoDBのSDK（boto3など）でリクエストを送る
  • ExtendDBがそのリクエストを受け取り、選択したストレージバックエンドへ変換・ルーティングする
• アプリ側の変更:
  • 変更点は接続先のendpoint_urlをExtendDBに向けるだけ
  • アプリコード自体の変更は不要
• 対応バックエンド:
  • PostgreSQLはリファレンス実装であり、テストスイートで検証済み
  • Apache Cassandraはコミュニティ提供
  • インターフェースとして定義されており、その他コミュニティによる追加が可能
• 対応操作:
  • CRUD、Query、Scan、バッチ処理、トランザクション、Streams、式(expressions)、TTLなどに対応

■ 3. 主なユースケース

• ローカル開発:
  • AWSアカウントやネットワーク不要でノートPC上で動作
  • CI・統合テストにも利用可能
• クラウドとオンプレの標準化:
  • 既存運用中のDBの上でDynamoDB APIを提供する
  • ハイブリッド構成を実現できる
• 切断環境への展開:
  • 工場、店舗、車両などクラウド接続が不安定または不可能な場所でも動作する
  • エッジ環境、エアギャップ環境が対象

■ 4. ライセンスとコスト

• ライセンス:
  • Apache 2.0ライセンス（特許許諾条項あり）でオープンソース公開
• コスト構造:
  • ExtendDB自体は無料
  • 発生するコストはコンピュート・ストレージなどインフラ分のみ

■ 5. 制限事項

• セルフホストで使えない機能:
  • DynamoDBのフルマネージドサービスに紐づく機能はセルフホスト環境では利用不可
  • グローバルテーブル、オートスケーリング、バックアップ/リストア、DAXなどが該当し、FAQに明記されている

■ 6. 性能

• PostgreSQLバックエンド:
  • 単一アイテム操作が10ms未満のレイテンシ
• Cassandraバックエンド:
  • 水平スケーリングにより数千リクエスト/秒に対応可能

■ 7. 公開状況

• 2026年5月20日にAWS Database Blogで正式発表
• GitHub（ExtendDB/extenddb）でソースコードとドキュメントを公開

MEMO:

• DynamoDBを使いたい時というのはスケーリング能力が欲しい時で、別にDynamoDBのAPIそのものはそこまで重要ではないように思うのだが
• DynamoDBの互換APIを使いたいが、AWSにデータを保存できないという特殊な要件が前提になるが、そんな要件が指定されることはかなり稀だと思われる
• そう考えるとテスト以外の用途はほとんど存在せず、それすら既存のDynamoDB Localと競合している
• テスト用途ではExtendDBはPostgresSQLバックエンドを必要とする分、DynamoDB Localより構成が複雑化するハンデもある
• 発想は面白いが使い道が思いつかないプロダクトである

(2026/08/12)

「プロダクトビルダー」の時代が来る ― PdM・デザイナー・エンジニアの垣根が溶けたあと...

• 「プロダクトビルダー」の時代が来る ― PdM・デザイナー・エンジニアの垣根が溶けたあと、デザイナーの武器は何か｜そわか

要約:

■ 1. プロダクトビルダーの時代

• 書き手の立場:
  • toB SaaS専門のUX/UIデザイナーとして複雑な業務ドメインのプロダクトを12年以上手がけてきた
• プロダクトビルダーという概念:
  • PdM、デザイナー、エンジニアという職種の垣根がなくなり、全員が「作る人」になっていく流れを指す
• 実感の裏付け:
  • 個人開発でまさにその状態を体験しているため、この話には確かにそうだと感じた
• 本稿の射程:
  • 海外で起きていることの整理、一人で全役割をやって分かったこと、垣根が溶けた後にデザイナーへ残るものを扱う

■ 2. 海外で進む職種再編

• 雰囲気ではなく構造変化:
  • 職種の再編は組織構造の変化として現れ始めている
• LinkedInの事例:
  • 新卒PMの登竜門だったAssociate PMプログラムを廃止し、「Product Builder」トラックに置き換えた
  • プロダクト、デザイン、エンジニアリングを横断してローテーションする育成方式である
  • PM、デザイナー、エンジニアを統合した役割への組織再編も進めている
  • 職種を分けて成果物を受け渡すという前提そのものを見直している
• 求人市場の変化:
  • 900名超のデザイナーを調査した「AI in Design」レポートの周辺で新しい職名の出現が報告されている
  • 「designer engineer」「builder」「design crafter」といった従来の枠に収まらない職名が求人に現れ始めている

■ 3. 分業が逆転する構図

• 従来の直列分業:
  • PdMが定義し、デザイナーが形にし、エンジニアが実装するという受け渡しで開発は動いてきた
  • 各工程が高コストで専門家を専任させる必要があったため、この分業が成立していた
• AIによるコスト低下:
  • PdMがプロトタイプを作り、デザイナーがコードを書き、エンジニアが画面案を出せるようになった
  • ただしこれはたたき台やプロトタイプの水準に限られる
• 最大コストの移動:
  • 受け渡しのたびに発生する待ち時間と伝言ゲームこそが最大のコストになった
  • 一人または少人数が全域に手を伸ばす方が速いという逆転が起きる
• ボトルネックの所在:
  • エンジニアの工数から「何を作るべきかの判断」へ移った
  • 海外の議論はおおむねこの点で一致している

■ 4. 日本での動き

• メルカリの経営方針:
  • 2026年7月の新年度経営方針発表でグループテーマとして「AI-Native for Hypergrowth」を掲げた
  • AIを前提にプロダクトも組織も働く人自身も変えていくという宣言である
  • 自律型AIエージェントを全社員の働き方に組み込む取り組みも始まっている
• Figma主催イベントでの言及:
  • メルカリの登壇者から、職種の垣根を越えて自ら作るビルダー的な人材と体制への言及があった
  • 公式な制度としての詳細は公開されていないが、現場レベルでその方向に動いているのは確かである
• 経営アジェンダ化:
  • AIを前提にした職種と組織の再定義は、日本の大手プロダクト企業でもすでに現実の経営アジェンダになっている

■ 5. 一人で全役割をやった体験

• 開発中のプロダクト:
  • 幹事がグループにアンケートを取るためのモバイルアプリを個人で開発している
  • Expo（React Native）、Vercel、Supabaseで組んでいる
  • 企画も仕様もデザインも実装もすべて自分が担い、PdMとデザイナーとエンジニアを一人で兼ねている
• 発見1: 脳内で完結する職種間の会話:
  • 実装が重くないか、このUIは要件を満たしているかといった往復が脳内で瞬時に終わる
  • 手戻りがほぼゼロになり、この速さは体験すると戻れない
  • 受け渡しコストの大きさは、なくなって初めて実感した
• 発見2: 最も重い「何を作らないか」:
  • 作る力がAIで拡張されると作ること自体は進む
  • 詰まるのは機能を足すか削るか、どの順で作るか、誰のどの課題を最優先にするかという判断である
  • PdMの仕事の正体は調整ではなく判断だと、一人になってようやく骨身に沁みた
• 発見3: 良し悪しを決める12年の蓄積:
  • AIと組めばコードは書け、画面もAIが出してくる
  • 出てきたものが良いか悪いか、ユーザーにとって成立しているかの判断はAIに任せられない
  • そこで働いていたのは12年やってきたデザイナーとしての目である
  • 越境したことで逆に自分の専門性の所在がはっきり見えた

■ 6. 越境しても届かない深さ

• 届く範囲と届かない深さ:
  • 越境して痛感したのは、届く範囲と同じくらい届かない深さがあることだった
• AIでは代替できない領域:
  • アーキテクチャの設計、セキュリティ、パフォーマンス、障害への備え、スケールする構造が該当する
  • これらは動くものが作れることとはまったく別の話である
• 個人開発の前提条件:
  • 自分の個人開発は小規模だから成立している
  • 本番環境、大量のユーザー、守るべきデータを抱えるシステムではエンジニアの専門性なしに立ち行かない
• 勘違いへの戒め:
  • AIでコードが書けるからエンジニアの領域を越えられるというのは、控えめに言っても勘違いである
  • 見えているのは氷山の一角で、水面下にはすぐには越えられない専門性の壁がある
  • これはデザインの領域に踏み込んでくる他職種に対して抱く感覚とまったく同じ構造である

■ 7. 溶けない一芸

• 専門性は不要にならない:
  • 専門性が要らなくなるのかという問いへの答えは明確にノーである
• Dylan Field氏の見立て:
  • チームは領域を越えて貢献できるプロダクトビルダーで構成されるようになる
  • 各人は一つの領域に深いクラフト（熟練）を持ち続ける
  • この世界でデザインはむしろ重要になる
• プロダクトビルダーの定義:
  • 何でも中途半端にできる人ではなく、深い一芸を持ったまま全域に手が届く人である
  • 誰もが作れるようになるからこそ、アウトプットの差は一芸の深さで決まる
• 職種横断の一芸:
  • エンジニアにとってのアーキテクチャ設計や信頼性の担保も溶けない一芸である
  • PdMにとっての事業判断も同じく溶けない一芸である
• ビルダーの時代の本質:
  • 互いの一芸が浅くなる時代ではない
  • それぞれの一芸を核にした越境者同士が、より深いレベルで協働する時代である

■ 8. デザイナーの武器

• デザイナーの一芸:
  • 体験の質を判断する目である
• 差がつく場所:
  • AIが画面を量産する時代、作る速さでは差がつかない
  • 量産された選択肢から成立しているか否かを見抜き、直すべき点を特定する力で差がつく
  • この力は一朝一夕には育たず、だからこそ武器になる
• 目だけでは活きない:
  • デザイナーがビルダーにならないまま目だけを持っていても、これからは活きにくい
  • 判断は作る流れの中にいてこそ効く
  • 深い目を持ったまま企画にも実装にも手を伸ばすのが、デザイナー出身のプロダクトビルダーの形である

■ 9. 会社員デザイナーの第一歩

• 提案1: 個人開発:
  • 小さくてよいので自分の困りごとを解くアプリをAIと組んで作ってみる
  • 企画から実装までを一人で回す経験は越境の練習として最良である
  • 個人開発を通して得た気づきが、そのまま本業の視点を広げてくれている
• 提案2: 開発の構造を学ぶ:
  • コードが書けるようになる必要はない
  • 要求がどう要件になりどう実装されるのか、フロントエンドとバックエンドがどう分かれているのかを理解する
  • 構造を理解しているだけで越境の解像度がまったく変わる
  • ビルダーの世界では、作れるの手前にある「作られ方が分かる」が土台になる

■ 10. まとめ

• 垣根が溶ける理由:
  • AIが実行コストを下げたことで、分業は受け渡しの遅さという弱点を露呈した
  • 海外では職名と組織構造の再編がすでに進行中である
• 溶けるものと溶けないもの:
  • 溶けるのは職種の境界線であって一芸の深さではない
  • 全員が作れるようになる世界では、深い一芸こそが差になる
• 目指す転換:
  • デザイナーにとっての一芸は体験の質を判断する目である
  • その目を持ったまま企画へ、実装へ手を伸ばしていく
  • 「デザイナーです」から「デザインが一番深い、プロダクトビルダーです」への転換の途中にいる

(2026/08/11)

入門 再発防止策

• 入門 再発防止策 - Speaker Deck

要約:

■ 1. 再発防止の定義

• 再発防止の本質:
  • 失敗しにくい仕組みを作ること
• 人間の努力の限界:
  • 人間はミスし、忘れ、疲れ、焦る
  • 人間が頑張ることには限界がある
• 再発防止で目指す状態:
  • ミスを起こしにくくする
  • ミスしても壊れにくくする
  • 壊れても早く気づけるようにする
• システム側の改善:
  • 人ではなくシステム側の改善が重要

■ 2. 原因除去のみの限界

• 原因を潰すだけでは不十分:
  • 設定ミスで障害が発生し設定を修正しても、別の設定ミスは防げない
• 深掘りすべき問い:
  • なぜ危険な変更ができたのか
  • なぜ検知できなかったのか
  • なぜ影響が広がったのか

■ 3. 再発防止のゴール

• ゴールは障害ゼロではない:
  • 発生確率を下げる
  • 影響を小さくする
  • 早く検知する
  • 早く復旧できるようにする
• 目指すべき状態:
  • 次はもっとマシに壊れる状態を作ることが重要

■ 4. アンチパターンな再発防止策

• たまによく見る形骸化した対策:
  • 気をつけます、レビューを徹底します、手順をちゃんと確認します
  • 朝会で共有します、気合いで、といった精神論の対策
• ありがちな失敗:
  • ポストモーテムを書いて終わる
  • TODOだけ積まれる
  • 優先順位が低く放置される
  • オーナー不在
• 振り返り会後の熱量低下:
  • 障害の日から日付が経つごとに熱量が下がる
  • 誰もやらず数週間後に同じ原因で再発する
  • SREとしては悔しい結果になる

■ 5. 放置される問題と処方箋

• 放置される問題:
  • 再発防止策が取られないまま放置される事態はよくある
  • 障害対応中は懸命に直すが、復旧後は他にやることが多く後回しになる
• 処方箋(1) オーナーと優先度:
  • ポストモーテムでオーナーを決定させる
  • その場にPMを呼んで優先度を判断させる
  • 最重要以外をやらない判断をとる勇気も重要（なんとなく不安だから作ったToDoのようなものを削除、など）
  • 四半期に一回程度の棚卸しを行う
• 処方箋(2) その日のうちの対応:
  • その日の障害はその日のうちに対応する
  • AIがある現在では、超複雑でない限りその日にできることは意外と多い

■ 6. 良い再発防止策の条件

• 良い再発防止策の要件:
  • 人の注意力に依存しない
  • 自動化されている
  • 継続可能である
  • システムで制御される
  • 誰でも実行できる
• 防ぐだけが再発防止ではない:
  • 早期検知
  • 自動復旧、フェイルオーバー
  • Rollbackの高速化
  • Runbookの整備

■ 7. 再発防止策の考え方

• 問いを分けて考える:
  • なぜ起きたか
  • なぜ検知できなかったか
  • なぜ影響が広がったか
  • なぜ復旧が遅れたか
• レイヤーで見る視点:
  • 障害は1箇所だけで起きるわけではない
  • 設計、実装、デプロイのレイヤー
  • 監視、運用のレイヤー
  • 組織、コミュニケーションのレイヤー
  • 複数レイヤーに問題が存在する
• 防御ラインを増やす:
  • 1つの対策で完璧を目指さないことが重要
  • Validation、Alert、Rollback
  • Feature Flag、Canary Release
  • 複数の防御ラインを持ち事故を小さくする

■ 8. AIとSRE

• AIは人間の置き換えではない:
  • AIによってSREは運用作業の自動化から信頼性を設計する役割へ進化している
  • 障害対応、異常検知、RCA、Toil削減に大きな変化が起きている
• 本番導入の前提条件:
  • AIは確率的に動作する
  • 透明性、段階的権限管理、ロールバックなど安全性を前提とした設計が必須
• 最終的なゴール:
  • AI Operatorのような仕組みを通じ、信頼性がデフォルトで組み込まれたシステムを実現すること
• SREの役割の変化:
  • 障害対応する人から、信頼性を自己進化させる仕組みを作る人へ変わっていく

■ 9. まとめ

• 再発防止は反省会ではない
• 人を強くするより、システムを強くする
• 気をつけるには限界がある
• 小さく改善を積み重ねることが重要

■ 10. 参考資料

• Postmortem Culture: Learning from Failure
• Blameless PostMortems and a Just Culture
• Incident postmortems
• Whose fault was it anyway? On blameless post-mortems
• Post-incident review best practices

(2026/08/11)

sandboxd -- Self-hosted, open-source AI app builder

• Self-hosted, open-source AI app builder | sandboxd
• What is sandboxd? | sandboxd

要約（What is sandboxd?）:

■ 1. sandboxdの概要

• AIアプリビルダーの基盤エンジン:
  • オープンソースであり、自分のサーバー上で動作する
  • 各アプリを専用の隔離サンドボックス内で実行する
• サンドボックスの構成要素:
  • 専用コンテナ、ファイルシステム、メモリ制限
  • 組み込みのAIコーディングエージェント、ライブプレビューURL
• 用途の広がり:
  • 大半の利用者はアプリビルダーとして構築する
  • 同一エンジンがエージェント基盤、プレビュー環境、80以上のワンクリックOSSアプリも動かす
• 提供形態:
  • セルフホスト、オープンソース、1コマンドでインストール完了

■ 2. 1回のHTTPリクエストで起きる3つの動作

• サンドボックスの作成:
  • プライベートで隔離されたLinuxコンテナを生成する
  • あるユーザー、エージェント、ブランチのコードが他のものを参照したり破壊したりできない
• コードまたはAIエージェントの実行:
  • 任意のコマンドのexec、API経由でのファイル書き込みが可能
  • プロンプトを渡してエージェントに構築させることもできる
  • OpenCodeとClaude CodeのCLIがプリインストール済み
• ライブURLの付与:
  • サンドボックス内で動くdevサーバーが共有可能なプレビューリンクで即座に到達可能になる
  • ルーティングとTLSは自動で処理される
• エンドポイントの対応関係:
  • POST /sandbox でプライベートな隔離コンテナが起動する
  • POST .../tasks でAIエージェントがその中にアプリを書く
  • http://.preview... でそのアプリが専用URLで公開される

■ 3. 低コストな運用

• アイドル時の自動スリープ:
  • 誰も使っていないサンドボックスは停止し、メモリを解放する
• リンクアクセス時の即時復帰:
  • 誰かが再びリンクを開いた瞬間に起動する
  • ファイルはその間ずっとディスク上に保存されている
• 収容密度の向上:
  • 1台の通常のサーバーで多数のユーザー、エージェント、ブランチを保持できる
  • それぞれに仮想マシンを1台ずつ用意する必要がない

■ 4. 意図的に小さいアーキテクチャ

• 構成技術:
  • Dockerに指示を出す1つのGoプログラム
  • TraefikがURLを担当し、SQLiteがデータベースを担当する
• 採用しない技術:
  • Kubernetes、独立したデータベースサーバー、メッセージキューを使わない
• 可読性の高さ:
  • 全体を半日で読み通せる規模
• ホスト側の全体像:
  • ホストに必要なものはDockerのみ
  • ブラウザからTraefik経由でサンドボックス内のコーディングエージェントとdevサーバー(:3000)へ到達する
  • API/CLIはsandboxdを呼び、workspaceディレクトリが永続化される
  • SQLiteが信頼できる唯一の情報源となり、アイドルで停止、リクエストで起動する

■ 5. sandboxd上で動かすもの

• 単一目的の製品ではなく構成部品:
  • 作成、構築、プレビュー、スリープ、起動という同じループが多様な用途を支える
• AIアプリビルダー製品:
  • ユーザーが「todoアプリを作って」と入力すると動くWebサイトが専用リンクに現れる種類の製品
  • Lovable、Bolt、v0、Replitに相当するものを自分のサーバー上で実現するOSSバックエンド
• エージェント基盤と社内エージェント実行:
  • すべてのコーディングエージェントに隔離ワークスペースと実際のライフサイクルを与える
  • プロンプト送信、SSEによる進捗ストリーミング、永続的な結果の取得が可能
  • プロバイダを一度接続すれば認証情報注入プロキシが鍵をサンドボックス外に保ち、何も自社インフラの外に出ない
• ユーザー単位・ブランチ単位のプレビュー環境:
  • 開発者、ブランチ、プルリクエストごとに共有可能なライブURLを与える
  • 再起動しても存続し、アイドル中はコストがかからない
• コーディングプレイグラウンド:
  • 使い捨てでリソース上限付きの環境を配布する
  • 1人のユーザーが他の全員を巻き込んで停止させることがない
• チーム向けのマルチアプリホスティング:
  • 多数の小規模な社内アプリを1台のマシンで運用する
  • 各アプリが専用の整ったURLを持ち、アイドルで停止し次のリクエストで起動する
• SaaS型サンドボックスとの違い:
  • セルフホストかつMITライセンスのため、SaaSでは満たせない場所に適合する
  • コード、データ、APIキーが自分の管理下のハードウェアに留まる
  • 月20ドルのVPSでも社内ネットワーク内のサーバーでも成立する

■ 6. 対象となる利用者

• 多数のサンドボックスを運用する場合は採用すべき:
  • 製品のユーザー向け、チーム向け、エージェント向けの運用が該当する
  • AIアプリビルダー、エージェント基盤、コーディングプレイグラウンドが該当する
  • ユーザー単位やブランチ単位のプレビュー環境、チーム向けマルチアプリホスティングも該当する
• 自分用のコンテナが1、2個なら採用不要:
  • シェルスクリプト、docker run、lxdの方が単純

■ 7. 本当に難しいのはインフラ

• 難所はプロンプトでもアプリでもなくその下の基盤:
  • AI製品を出す場合でも社内プラットフォームを作る場合でも同じ
• 必要となる要素:
  • あるユーザーのコードが他に触れないマルチテナント隔離
  • 自動ルーティングとTLSを備えたユーザー単位のプレビューURL
  • アイドル環境がメモリを解放しなければ請求額が爆発するためのコスト制御
  • ワークスペースに対してエージェントを走らせ、進捗を流し、結果を捕捉するオーケストレーション
  • 永続化、オンデマンド起動、クラッシュや再起動後の再調整
• 開発規模:
  • これらは数ヶ月分のプラットフォーム開発に相当する
  • sandboxdはそれを1コマンドに凝縮したもの

■ 8. 主要な特徴

• ワンラインインストール:
  • curl -fsSL …/install.sh | bash だけでAPIとプレビューが動く状態になる
• エージェント同梱:
  • OpenCodeとClaude Codeがすべてのサンドボックスに同梱され、プロンプトを渡せば構築が始まる
  • 認証情報はサンドボックスに一切入らず、プロキシが通信経路上で注入する
  • すべてのタスクがチェックポイント化され、巻き戻しが可能
• 設計として高密度:
  • アイドル停止とリクエスト起動により、数十のサンドボックスが1台を共有する
  • VMを1台ずつ用意する方式との差は20ドルのサーバーと2000ドルのクラスタの差になる
• 所有権が自分にあること:
  • セルフホスト、MITライセンス、ベンダーロックインなし
  • データ、利益率、ロードマップを自分で所有する
• 意図的な退屈さ:
  • SQLite、docker CLI、Traefikのみで構成する
  • 起動のたびにリコンサイラがDockerをデータベースの状態へ収束させる
  • コントロールプレーン全体を半日で読み通せる

■ 9. シェルスクリプトで十分ではないかという疑問

• 自分用の長期稼働コンテナが1、2個ならスクリプトで十分:
  • シェルスクリプト、docker run、lxdの方が単純であり、そちらを使うべき
  • 単発のプロジェクトにsandboxdは過剰
• 他者のために多数のサンドボックスを動かす時点で価値が出る:
  • チーム向けや製品向けの運用になると、小さなdocker runスクリプトが以下すべてへ膨らむ
• ポートではなくURL:
  • すべてのサンドボックスが自動ルーティングとTLS付きの整ったプレビューURLを得る
  • ポート管理も衝突対応も不要
• 自律的なスリープと起動:
  • アイドルのサンドボックスは停止してRAMを解放し、次のリクエストで透過的に再起動する
  • ウォームアップ画面、レディネスプローブ、リクエスト保留を含み、その部分だけで100行を優に超える
  • 安価な1台で済むか常時稼働VMのラックが必要かの分かれ目になる
• 再起動への耐性:
  • SQLiteが信頼できる唯一の情報源であり、起動時にリコンサイラがDockerを再収束させる
  • スクリプトはホスト再起動時にすべてを忘れる
• シェルインするCLIではなくAPI:
  • create、exec、stop、destroy、write-files、run-agent-taskが認証付きの実HTTPエンドポイントとして存在する
  • アプリのバックエンド、CI、スクリプトからユーザー単位で大規模に呼び出せる
• 巻き添え停止の防止:
  • サンドボックス単位のメモリ制限とPID制限を持つ
  • ホストのメモリ逼迫時に動くリーパーを備える
• ライフサイクルを持つエージェント:
  • プロンプト送信、SSEでの進捗ストリーミング、永続的な結果の取得を行う
  • opencodeをその場で起動するだけのものとは異なる
• 結論:
  • スクリプトを育てて同じ機能を再実装すればsandboxdを再発明することになる
  • 単発なら見送り、スクリプトで夜も眠れなくなった時点で採用すべき

■ 10. Kubernetesを好む場合

• コントロールプレーンは薄いdocker CLI境界を介してコンテナランタイムと対話する:
  • k8sのJob/Podバックエンド追加は書き直しではなくインターフェース差し替えで済む
  • 最初のコントリビューションとして適している
• 現時点では単一のDockerホストを対象とする:
  • k8sは不要
  • サンドボックスのためだけにクラスタを運用したくないチームに最適な位置

■ 11. プロダクトの土台としての適性

• 製品基盤として使えるかという問いへの答えは肯定:
  • それこそが狙いである
• 省ける初期開発:
  • マルチテナント隔離、プレビュールーティング、アイドルと起動によるコスト制御、エージェントオーケストレーションを数ヶ月かけて作る必要がない
  • AIアプリビルダーやエージェントSaaSの出荷、社内でのサンドボックス環境構築を初日から始められる
• 提供条件:
  • 安価なサーバー1台で動き、利益率は自分で制御できる
• 現状の位置づけ:
  • ベータ品質、MITライセンス、読まれ拡張されることを前提に作られた誠実な出発点
  • 軽量に立ち上げ、成長に応じて堅牢化していく方針を取る

(2026/08/10)

日本におけるAIによるエンジニア不要論が非現実的な理由

• 日本におけるAIによるエンジニア不要論が非現実的な理由

要約:

■ 1. 主張の骨子

• 繰り返されるエンジニア不要論:
  • AIによりエンジニアが不要になるという話はここ数年何度も聞いて飽きている
  • エンジニア不要論は定期的に出てくるものであり、1990年頃には既に同様の主張を聞いた
  • 最低でも35年以上そうした話が続いており、もっと昔からあってもおかしくない
• 三つの主張:
  • エンジニアの再定義や淘汰はあるだろうし、今後頻繁に議論されるようになる
  • エンジニアそのものが不要になるAIは頭脳労働職も全部不要にするAIであり、正しくは「頭脳労働職不要論」である
  • そもそもある一定ラインになると人間の方が安い
• 論点の切り分け:
  • コーディングエージェントによるエンジニアの再定義や淘汰と、エンジニアそのものが不要になることは完全に別物
  • 後者は非エンジニアだけでプロダクトを作れる状態を指す

■ 2. 現状のAIの実力

• 記事執筆時点の最高峰AI:
  • 8/3時点で世界最高峰のAIはMythos5/Fable5である
  • Opus5はベンチマークが良くても実性能はそれほど高くないベンチマーク番長にすぎない
• 非エンジニア開発の不可能性:
  • Fable5を使って非エンジニアがまともなプロダクトを作りメンテナンスすることは絶対に無理
  • 少しでもプロダクト開発・運用に携わった人間なら、それが無理であることは自明にわかる
• 可能な範囲の限定:
  • Fable5でプロトタイピングやPoC、自分専用ツールを作る程度なら実例も山ほどある
  • 内部ユーザーだとしても顧客が存在するプロダクトは無理
• 素人が作る結果:
  • そこらへんのクッソショボい業務システムでも、素人がAIスロップまみれで作れば安定して動くまともなものはでき上がらない
  • エンジニアが泣きながら後始末をやらされる未来が目に見えている
• 最先端ツールのバグ:
  • Claude CodeやCodexはバグだらけで、いまだにOpenされ続けているissuesが大量にある
  • AnthropicやOpenAIの天才たちが社内の無制限トークンを湯水のごとく使ってすらあの体たらくである
  • Claude Codeの不愉快なバグは一向に治らず、CodexのSQLiteバグすら治らない

■ 3. 性能向上の見通しと必要な水準

• 次世代モデルの想定:
  • OpenAIの内部コードネームAstraやAnthropicのFable5.1は8月中には出るだろう
  • Opus-4.8からFable5に該当するほどの極端なジャンプアップが再び起きることはないはず
  • 非エンジニアでもプロダクトをまともに開発・運用できるようになるほど大きすぎる進化ではない
• 不要論に必要なAI像:
  • エンジニアが持つ勘所・経験・実績・セオリーがなくてもプロダクトを作れるAIでなければならない
  • エンジニアとはユーザーが抱える問題を解決するプロフェッショナルである
  • ユーザーが言語化できていないものを全部くみ取って設計に落とし込める知性が必要
• テクニック必要論の限界:
  • AIの性能を引きだすためにテクニックやコツが必要と言っているレベルでは絶対に無理
• 現行AIの弱点:
  • 答えがあるものは素晴らしいくらいに扱えるが、答えが明文化できていないものを扱えるほど賢くはない
  • 要件定義・設計の難しさも全部吹き飛ばせるような知性への進化が必要
• 真のAGIとの距離:
  • 必要とされる水準はもはや真のAGIと呼ばれるもの
  • 現状では既にRSI（AIによる再帰的進化）を達成しているのではと言われている
  • RSIやASIが実現されてなお、人間をそのまま代替できる真のAGIの実現は遠い

■ 4. 規制と地政学のリスク

• 政府による強制介入の前例:
  • たかだかFable5ごときで、アメリカ政府が歴史上はじめてAIサービス提供に対して強制介入をした
• AGI級AIの攻撃能力:
  • 非エンジニアがプロダクトを完全に作れるほどのAIの攻撃能力はFable5程度の比ではない
  • ソーシャルエンジニアリングなども含め、あの手この手で攻撃できる能力を持つ
• 提供条件への疑問:
  • OpenAIやAnthropicの人がそれを完全にコントロールしきれるのか
  • nerfされずにリリースできるのか、値段は安く提供されるのか
• 各国の規制強化の可能性:
  • アメリカ政府は今まで以上に介入するかもしれない
  • 中国はいまのところオープンだが、世界最高峰のAIを手にしたとき規制推進側に回る可能性は決して低くない
  • EUも今以上にうるさく言い始めるかもしれず、日本人は最先端AIにアクセスできなくなるかもしれない

■ 5. 人間の方が安いというコスト論

• 従量課金の負担:
  • 普通の企業はサブスクではなく従量課金で使っているはず
  • 非エンジニアがFable5を従量課金で使えば莫大な金額がかかる
• 実際のトークン消費額:
  • Fable5をMax 20xで最大限に使えば簡単に月額100万円くらいのトークンを使うことになる
  • 筆者は7月にFable5のみで95万円相当、Opus5を入れて138万円相当のトークンを消費した
• エンジニア利用の優位:
  • エンジニアが適切なモデルを適切な使い方で使っていく方が安くつく
• 価格上昇の見通し:
  • 今後のAIはスケーリング則を活用するために今よりさらにサイズアップし、値段も高くなる
  • AnthropicやOpenAIとしては値段が高いモデルを出した方が儲かる
  • Fable5並のAIが安くなる未来は来るが、非エンジニアでもプロダクトを作れるAGI級AIが安くなる時期は見えない

■ 6. オープンウェイトの現実

• 期待への反論:
  • オープンウェイトなAIが出ているから大丈夫という考え方は成り立たない
• 巨大モデルの運用コスト:
  • 2.8TのKimi K3はクラウドで月額1000万円、ハードウェア購入なら初期投資だけで1億円以上かかる
  • そこまで投じて元を取れるのか、人間の方が安くつくのではないか
• 例外的にペイする層:
  • 世界中でランサムウェアを使って金をむしり取っている連中は強烈な攻撃能力を得られるなら月額1000万円を安いと考える
• 日本企業にとっての重さ:
  • 日本の普通の企業にとって月額1000万円クラスの投資は安いものではない
  • 今後円安がまだまだ進行し、GPUもメモリもSSDもエネルギーも今以上に高くなる可能性がある
• 小型モデルの限界:
  • DeepSeek 4 Flash 0731は思ったよりも性能が高くサイズも小さいが、Fable5クラスの賢さではない
  • このクラスですら生半可な組織が運用できるものではない
• オープンウェイトの価格誤解:
  • オープンウェイトのモデルは安いわけではなく、サイズが小さいから相対的に安いマシンでも動くというだけ
  • DeepSeek 4 Flash 0731を公式推奨スペックで動かすなら月額200万円以上を見たほうがいい
  • これらを適切に運用できるエンジニアも当然必要になる
• 運用失敗のリスク:
  • 数百万円を投資しても、ちょっとしたミスで正しく運用できなくなることがある
  • システム自体は動いていてもうまく活用できず、値段分の力を引きだせないこともありえる

■ 7. 淘汰の見通し

• 淘汰そのものは発生:
  • AIの発達によってある種の人達が淘汰されるのは確かだろう
• 企業側の制約:
  • 多くの企業はなるべくお金をかけたくない
  • まともにオープンウェイトのAIを運用するノウハウも持っていない
  • 中国製のAIを無条件で信用するわけにもいかない
• 組織形態の変化:
  • AIコーディングを活用した少数精鋭のエンジニアリングチームができる
  • エンジニアリングとそれ以外の越境が続く
• SIerの将来:
  • SIerという形態も長期的には厳しいかもしれない
  • ユーザー企業に少数精鋭のエンジニアリングチームが入って自社開発したほうが健全だからである
• 淘汰される人材:
  • こういった変化に対応できない人材が淘汰される可能性はそれなりにある

■ 8. 真のAGI到来時のシナリオ

• 都合が良すぎる想定:
  • 非エンジニアが操作してプロダクト化ができるほどの知性があるのに、頭脳労働をする人が仕事を失わないシナリオは存在しない
• 議論のスケールの誤り:
  • そこまで行き着けばエンジニア不要論で収まるスケールではなく、エンジニア不要論は意味をなさない
  • エンジニア不要論とはエンジニアリングに限定したAGIが安価で実現される意味だが、そんな限定的なシナリオは生じない
• ブルーカラーも例外ではない:
  • 真のAGIに到達しているならロボティクスもそんなに時間がかからず行き着くところまで行く可能性が高い
  • かかったとしても数年遅れくらいに収まる

(2026/08/10)

DB設計における監査設計に関するメモ

■ 1. 監査設計の全体像

• 監査機能の二大方式:
  • 監査用カラムを本体テーブルに持たせる方式と、変更履歴を別テーブルに記録する方式に大別される
  • 目的や要件に応じて使い分け、組み合わせるのが一般的
• 基本の監査カラム:
  • created_at/created_by、updated_at/updated_by、deleted_at/deleted_by、versionをほぼ全テーブルに持たせる
  • これが最小構成となる
• 論理削除の利点:
  • deleted_atを使えば、本当に消してよいか、参照整合性が壊れないかを後から判断できる
• 論理削除の欠点:
  • 外部キー制約・ユニーク制約との相性が悪く、削除済みレコードも一意制約に引っかかる
• versionの用途:
  • 楽観的排他制御に使い、更新時に自分が読んだバージョンと一致するかをチェックする

■ 2. 変更履歴を残す4方式

• 単純な監査カラムの限界:
  • updated_at/byだけでは変更前の値、何回変更されたかがわからない
  • 変更履歴が必要なら履歴テーブルを設計する
• シャドウテーブル方式:
  • 本体と同構造のxxx_historyを用意し、更新・削除の都度、変更前の行をコピーして保存する
  • トリガーで自動化するか、ORMのフック等アプリケーション層で書き込むかを選択する
  • 各時点のスナップショットがそのまま取れるので監査・復元がしやすい
  • テーブルごとに履歴テーブルが増え、スキーマ変更の二重管理が発生する
• 汎用監査ログテーブル方式:
  • 全テーブル共通の1つのログテーブルに、table_name、record_id、old_values/new_values等をJSONで記録する
  • テーブル追加のたびに履歴テーブルを増やさなくてよい
  • IPアドレスやリクエストIDなど操作コンテキストも一緒に記録しやすい
  • JSONカラムのため検索・集計がしにくく、RDBMSのJSON検索機能に依存する
  • 差分だけを見たい場合はold/newのdiffをアプリ側で計算する必要がある
• イベントソーシング方式:
  • 状態ではなく発生したイベントを全て記録し、現在の状態はイベントの再生で導出する
  • イベントが真実の源であるため、完全な監査証跡が自然に手に入る
  • 設計・実装コストが高く、既存のCRUD中心システムへの後付けは難しい
  • 新規システムや強い監査要件がある場合に向く
• システムバージョニング:
  • SQL Serverやtemporal_tables拡張など、DBMSがネイティブ対応する時系列テーブル機能を使う
  • アプリ側でコードを書かずに履歴管理ができる

■ 3. 方式選定の指針

• 誰がいつ触ったか程度でよい場合:
  • 基本の監査カラムのみで足りる
• 変更前後の値を追いたい場合:
  • シャドウテーブルまたは汎用監査ログを用いる
• 改ざん不可な証跡が必要な場合:
  • 追記専用の監査ログにハッシュチェーン等を組み合わせる
• ドメインイベントとして意味のある履歴が欲しい場合:
  • イベントソーシングを選ぶ
• DB側で自動管理し実装コストを抑えたい場合:
  • DBMSのTemporal Table機能を使う

■ 4. 実装上の注意点

• 書き込み方式のトレードオフ:
  • トリガー実装は漏れなく確実だが、DBロジックが複雑化しデバッグしにくい
  • アプリ層のORMフック・AOPは柔軟だが、バッチ処理やDBAの直接SQLを防げない
  • 両方を併用するケースも多い
• パフォーマンス:
  • 高頻度更新テーブルに毎回履歴INSERTするとI/O負荷が増える
  • パーティショニングやメッセージキュー経由の非同期記録も検討対象になる
• 保持期間とアーカイブ:
  • 会計7年など法令要件に応じて保存期間を決める
  • 古いログはS3等の別ストレージにアーカイブする設計にする
• 改ざん防止:
  • 監査ログをUPDATE/DELETEできないようDB権限を絞り、追記のみ許可する
  • ハッシュチェーンや外部WORMストレージで完全性を担保する
• 変更主体の区別:
  • アプリケーションユーザーだけでなく、バッチ処理・システム連携による変更も区別できるようにする

■ 5. 基本監査フィールドは監査証跡ではない

• 監査としては機能しない:
  • 最終更新しかわからないため、誰が何をいつ変えたかの証跡にはならない
• 実体は運用メタデータ:
  • created_at/by、updated_at/byは一覧画面での最終更新者確認、ソート、キャッシュ無効化のトリガー等に使う
• versionの位置づけ:
  • 監査とは無関係であり、純粋に排他制御の仕組みである
• 導かれる結論:
  • 監査要件がある場合、これらのフィールドをもって監査要件を満たしたと考えるべきではない

■ 6. ヒストリーテーブルとイベントソーシングの評価

• ヒストリーテーブルは機能要件:
  • 注文のステータス遷移履歴の画面表示、承認フローの経緯提示など機能要件として必要になる
  • この場合はドメインモデルの一部であり、監査ログとは別物として設計すべきである
• 監査要件も満たしうる:
  • 全カラムの変更前後が追える構造にしておけば、機能要件として作った履歴が結果的に監査要件も満たす
• 量産はコストに見合わない:
  • 監査のためだけにテーブルごとにヒストリーテーブルを量産するのは割に合わず、汎用監査ログに任せるべきである
• イベントソーシングは過剰:
  • CRUD中心の業務システムに監査目的だけで導入するのは、状態導出コスト、実装複雑度、学習コストに見合わない
  • 決済や在庫移動などドメイン自体がイベントの連鎖として自然にモデリングできる場合を除き避けるべきである

■ 7. 汎用監査ログの留保点

• 書き込み経路の網羅性:
  • アプリ層のORMフック等で書く場合、バッチ処理、DBAの直接SQL、他システムからの直接書き込みが抜け穴になる
  • トリガーやCDCでDB層から捕捉する方が漏れがない
  • アプリ層でしか書かない設計は抜け道のある監査となり、要件次第では監査ログとして無意味になりうる
• 検索性能とクエリ要件:
  • JSONに差分を格納する方式はテーブル追加コストがゼロで柔軟である
  • 特定カラムの変更履歴追跡や特定ユーザーの横断検索はJSON演算子頼みで重くなる
  • 監査ログを実際に読む運用の頻度次第で、field_name、old_value、new_valueを行単位で持つ構造化が必要になる
• 改ざん耐性:
  • 汎用監査ログもただのテーブルであり、UPDATE/DELETE権限を絞らないと改ざんされる
  • 汎用ログに一本化する場合は、厳格なアクセス制御の設計とセットで考える必要がある

■ 8. DBに監査ログを置く理由

• トランザクション整合性:
  • 業務データの変更と監査ログの記録は同一トランザクションで確定してほしいものである
  • DBに書けば、業務データは更新されたが監査ログが書かれないという不整合が起きない
  • ロールバックすれば監査ログもロールバックされる
• 非同期経路の弱点:
  • ログ出力から非同期アーカイブ、DWHという経路では業務データと監査記録の一致保証が弱くなる
  • ファイル出力の場合、書き込み成功直後のプロセスクラッシュでフラッシュ前のログが欠落しうる
• 即時参照ニーズ:
  • 管理画面やサポート業務でその場に変更者を確認したい場合、DWH経由ではレイテンシが許容できない
  • BigQueryへのストリーミングインサートとクエリでも数秒から数十秒のラグが発生する
  • この用途はDB内やElasticsearch等の低レイテンシストアに直近履歴を持たせる方が向く

■ 9. DWHに任せる理由

• 分析・集計クエリ:
  • 異常頻度の変更検出やユーザー操作パターンの横断分析はカラムナDWHが圧倒的に得意で安い
• 長期保持コスト:
  • 7年保持等が必要な場合、本番DBに持ち続けるのはストレージ・バックアップ・インデックスの面で非効率である
  • DWHとS3/GCS等の安価なオブジェクトストレージへのアーカイブの方が合理的である
• 本番DBの肥大化回避:
  • 監査ログテーブルは本体テーブルより行数が増えやすい
  • 本番OLTP DBに置き続けるとインデックス肥大化やバックアップ時間増加の要因になる

■ 10. CDCを起点にしたハイブリッド構成

• 構成の概要:
  • 本番DBのWAL/binlogをDebezium等でCDCし、Kafka等のストリームに流す
  • 短期は運用画面用にDBやRedisへ直近履歴を投影し、長期は分析・コンプライアンス用にDWHへロードする
• 利点:
  • 書き込み経路を問わず全変更を捕捉でき、アプリ層のバグやバッチの抜け道を気にしなくてよい
  • WALに書かれた時点でコミット済みのため、業務トランザクションとのズレが原理的に起きない
  • 即時参照は短期ストア、長期保持はDWHと用途ごとに最適なストアを選べる
  • 本番DBの肥大化を避けられる
• 欠点:
  • CDC基盤自体の運用コスト・複雑度が増す
  • 小中規模システムでは明らかにオーバーエンジニアリングになる
• 分岐点:
  • 即時参照ニーズの有無と、書き込み経路の網羅性をどこまで求めるかがDBかログ/DWHかを分ける

■ 11. ログ出力からアーカイブ戦略の要件

• 前提の確認:
  • 即時参照不要かつ調査はエンジニアで可なら、ログ出力からアーカイブが理にかなう
  • DB内に監査ログテーブルを持つ複雑さと運用DB肥大化リスクを負うメリットが小さい
• 監査範囲の事前確定:
  • アプリ層を通らないバッチ、DBAの直接SQL、他システムの直接書き込みは捕捉されない
  • 業務上のユーザー操作が追えればよい程度ならアプリ層ログで十分である
  • 金融・医療系などDB変更全体の証跡が必要ならCDCでログ生成をDB層に寄せる必要がある
• ログの構造化:
  • timestamp、actor_id、actor_type、action、resource_type、resource_id、changes等を構造化する
  • request_id/trace_idを入れると、分散システムでどのAPIリクエストが引き金かを横断的に追える
  • actor_typeでシステム・バッチ由来の変更とユーザー操作を区別する
• 改ざん防止:
  • アーカイブ先も要件次第で追記のみ・削除不可のWORM設定にする
  • S3ならObject LockのCompliance mode、GCSならBucket Lockを使う
  • 要件が厳しい場合は各エントリに前エントリのハッシュを含めるハッシュチェーンを使う
• ライフサイクル管理:
  • ホット期間は直近数ヶ月から1年でDWHから即クエリ可能にする
  • コールド期間は安価なストレージへアーカイブし必要時のみリストアする
• 調査時のクエリ経路:
  • 実際に調査が発生した時、BigQueryにSQLを書けば追える状態かを事前に確認する
  • サービスごとにキー名やネストが不揃いだと調査コストが跳ね上がる
  • 共通のロギングライブラリ・ミドルウェアを整備し、出力時点でスキーマを統一する

■ 12. WAL/binlogを整形してログ保存する方式

• 一般的なアプローチ:
  • Debezium、AWS DMS、Google Cloud Datastreamが実際に採用しているメジャーな方式である
• メリット:
  • アプリ層、バッチ、DBA直接操作のいずれからの変更もWAL/binlogに必ず記録され、経路を完全網羅できる
  • コミット済みの変更しか含まないため、業務データは変わったがログが無いというズレが起きない
  • 読み取りは非同期でレプリケーションと同じ仕組みのため、本番トランザクションへの性能影響が小さい
• 業務的意味の欠落:
  • WALには行のカラム値がどう変わったかしか記録されず、誰が、なぜのアプリケーションコンテキストが存在しない
  • actor_idはupdated_byカラムに書くか、セッション変数をトランザクション内に埋め込んでメタデータ経由で拾う
  • なぜという業務的意図はDBの変更から復元不能であり、アプリ側でイベントとして別途記録する必要がある
• Before/Afterイメージの設定:
  • MySQLはbinlog_row_image = FULLにしないとUPDATE時に変更カラムしか記録されない
  • PostgreSQLはREPLICA IDENTITY FULLを設定しないとUPDATE/DELETEの旧データが完全に取れない
  • ストレージ・I/O負荷とのトレードオフであり、全テーブルに設定するかは検討を要する
• DDLの扱い:
  • ALTER TABLE等でイベントのスキーマ自体が変わるため、下流との整合を取るスキーマレジストリ等が必要になる
  • カラムがいつ追加・削除されたかも証跡として重要であり、DDLイベントも記録する設計が望ましい
• 機密情報のマスキング:
  • WAL/binlogはカラムレベルの制御ができず、行の全カラムがそのまま流れる
  • 個人情報や機密カラムはKafka Connect等の下流でマスキング・暗号化を挟む必要がある
• トランザクション境界の再構成:
  • 複数テーブルにまたがる1トランザクションはWAL上で複数イベントの連なりになる
  • まとめて1つの監査イベントとして扱うにはtransaction_idやLSN/GTIDでの再構成処理が必要になる

■ 13. updated_byの構造的限界

• 誰がまでしか語らない:
  • updated_byからわかるのは最終更新したユーザーという事実のみである
  • なぜその値に変えたのか、どの業務操作の一部か、どういう文脈かは一切わからない
• WALと同じ問題:
  • updated_byはWAL/binlogにactor情報を追加しただけであり、業務的意味の欠落という本質的問題は解消しない
  • actor_id、timestamp、IPアドレスを足しても、行がどう変わったかの記述にとどまる
• アプリケーションログが必須な理由:
  • 業務的な意味はアプリケーションがビジネスロジックを実行している瞬間にしか存在しない
  • DB側にどれだけ工夫を凝らしても事後的には復元できない
• 具体例:
  • 顧客によるキャンセル、在庫切れの自動キャンセル、不正検知によるブロックは行変更としては全く同じである
  • 監査・コンプライアンスの文脈では全く異なる意味を持ち、区別できるのは業務ロジックを実行したコードだけである
• 両者は補完関係:
  • WAL/binlogは網羅的だが業務的意味を持たず、改ざん耐性のある事実を提供する
  • アプリケーションログは業務的意味を与えるが、アプリ層を経由しない変更を捕捉できない
  • 厳しい要件があるほどCDCとアプリログの両方が必要になり、CDCはアプリログを不要にするものではない

■ 14. 3層構成ではなく主従関係のある2層

• 誰が・いつだけでは手詰まり:
  • updated_by/updated_atだけでは、何を何から何に変えたかがわからず調査時に行き詰まる
• 基本監査フィールドは冗長:
  • アプリケーションログをactor_id、old/new値、業務コンテキスト付きで設計するなら情報が重複する
  • 独自の価値は排他制御用のversionと、一覧画面用に最終更新者を複製するUI都合のキャッシュのみである
  • 監査証跡としての独立した役割はほぼ無い
• 実質的な構成:
  • アプリケーションログを主軸とし、必要に応じてCDC/binlogを完全性担保のために足す2層構成が筋がよい
  • 基本監査フィールドはUI用の複製データという位置づけに下げる
• 過剰設計の回避:
  • 3つが対等に並ぶセットと捉えるより、主従関係のある構成と捉える方が過剰設計を避けやすい

■ 15. アプリログのみでは直接更新を捕捉できない

• 運用ルールによる統制はザル:
  • バッチもDBA操作も全てアプリ経由という前提は現実にはほぼ成立しない
  • 障害対応では、運用ルールを整備していてもDBAや開発者が直接SQLを叩く事態が現実に起きる
  • マイグレーションやデータ補正は、性質上ビジネスロジックを経由しない直接SQLで行われることが多い
  • DB接続情報にアクセスできる人が1人でもいれば技術的には直接更新が可能である
• 監査観点での評価:
  • 運用ルールでアプリ層に閉じている状態は、監査の観点では閉じていないのと同義である
  • 監査・コンプライアンスで問われるのはルール上禁止かではなく、技術的に迂回可能かである
• 判断基準の修正:
  • 正しい分岐点はDBに直接書き込める技術的な経路や認証情報が存在するかである
  • DBAや緊急対応用アカウント等が存在するならアプリログでは足りず、CDCまたはDBトリガーが必要になる
  • 書き込み経路が物理的にアプリケーションサーバーのみに制限された組織は稀である
• 穴を塞ぐ2つの方向性:
  • 本番DBへの直接接続権限を原則ゼロにし、緊急時のみ一時発行・自動失効させ、その発行と利用もログ化する
  • 権限を絞る方式は運用コストが高く、多くの組織で緊急対応の柔軟性とトレードオフになる
  • 直接アクセスを許容した上でWAL/binlog経由で全て捕捉する方が、柔軟性と監査の完全性を両立でき現実的である
• 訂正後の結論:
  • 監査・コンプライアンス要件がある時点で、CDCまたはDBトリガーベースの捕捉をデフォルト前提とすべきである
  • アプリログは意味づけを担う層として必須だが、DB変更全体を追うことの代替にはならない

■ 16. CDC/binlogのデータ量試算

• サイズを決める要因:
  • トランザクション量と行サイズの積が、設定と実装の選択で数倍から十数倍のレンジに変わる
• WAL/binlog自体のオーバーヘッド:
  • MySQLのbinlog_row_image = FULLでは変更されていないカラムも含め変更前後の全カラムが記録される
  • PostgreSQLのREPLICA IDENTITYをFULLにするとUPDATE/DELETEのWAL量が大きく増える
  • FULLイメージ化すると1行あたりの記録サイズは行サイズの2倍前後になる
• シリアライズ形式が最大のレバー:
  • スキーマ埋め込みなしのJSONは行サイズの2倍から4倍になる
  • Debeziumデフォルトのスキーマ埋め込みJSONは5倍から10倍以上になることもある
  • Avro/Protobufとスキーマレジストリの組み合わせは1.5倍から3倍程度に収まる
  • 本番運用ではAvro/ProtobufとSchema Registryの組み合わせがほぼ必須である
• 圧縮の効果:
  • KafkaのProducer側圧縮はZstdで3倍から5倍程度の圧縮率が一般的である
  • BigQueryやParquetのカラムナ格納では元データの5分の1から10分の1程度まで縮む
• 試算例:
  • 1行500バイト、平均100 UPDATE/秒のordersテーブルを想定する
  • WAL/binlogは日次約8.6GB、Debezium経由のKafkaは圧縮前で日次約11GBとなる
  • Zstd圧縮後は約2.7GB/day、S3へのParquetアーカイブでは0.5から1GB/dayまで縮む
  • スキーマ埋め込みJSONのまま運用すると数十GB/dayに膨らむこともある
• テーブル数の考慮:
  • 監査対象テーブルは数十から数百あるため、テーブルごとの更新頻度と行サイズを積み上げる必要がある
  • 注文ステータス、在庫数、セッション情報など高頻度更新テーブルが全体のボリュームを支配しがちである
  • 金銭・個人情報関連を優先的に対象化し、それ以外を対象外や低頻度スナップショットにすれば大きく削減できる
• 見積もり手順:
  • 対象テーブルごとに1日の平均更新件数をスロークエリログやAPMから実測する
  • information_schemaから1行あたりのバイト数を概算取得する
  • 件数、行サイズ、before/afterの2倍、シリアライズ係数を掛けて粗く見積もる
  • KafkaとDWH側の圧縮率は理論値でなく実データのPoCで測定する

■ 17. 監査対象テーブルの選定基準

• マスタテーブルの意味が薄い理由:
  • 商品マスタやカテゴリマスタは初期投入後ほとんど更新されず、容量コストに対しリターンが小さい
  • マスタデータの改ざんが実害に直結するケースは少ない
  • マスタは参照される側であり、いつ変わったかさえ分かれば以降の取引データとの整合性は追跡可能である
• 優先度が高いテーブルの特徴:
  • 注文金額、決済ステータス、返金処理、ポイント残高など金銭が動くもの
  • 権限ロール、APIキー、認証情報などアクセス制御に関わるもの
  • 氏名・住所等のPIIカラムを含むもの
  • 在庫調整、値引き・クーポン適用、承認フローなど不正の温床になりうるもの
  • 会計仕訳や取引履歴など法令が直接保存を求めるもの
• 選定プロセス:
  • まず更新頻度で機械的にフィルタし、ほぼ変更されないテーブルを除外する
  • 残りを金銭・PII・権限のいずれかに該当するかで監査必須・任意・対象外にランク分けする
  • 法令上必須な範囲をコンプライアンス担当・法務とすり合わせる
  • 容量・コストの見積もりを踏まえ、任意ランクをどこまでCDC対象に含めるか判断する
• マスタ除外の例外:
  • 価格マスタの改ざんによる不正値引き、権限マスタの改ざんによる不正アクセスは実質的に金銭・権限に直結する
  • 更新頻度が低くてもむしろ優先的に監査対象にすべきである
  • マスタかトランザクションかという技術的分類ではなく、金銭・権限・PIIに直結するかという業務的軸で判断する

■ 18. リスクベースの層分けと組織的合意

• 設計判断としての妥当性:
  • クリティカルなもののみCDCで捕捉し、残りをアプリケーションログとするのは実務的に妥当な落とし所である
  • 全テーブル一律CDCは多くの組織にとってコスト超過となる
• リスク受容としての明文化:
  • アプリログのみにはDB直接更新を捕捉できない構造的な穴がある
  • この判断はクリティカルでないテーブルの捕捉漏れリスクを受容するという意思決定そのものである
  • エンジニアの設計判断だけで決めると、監査時に完全性が担保されない理由を組織として説明できなくなる
  • CDC対象テーブルのリストと選定基準をコンプライアンス担当・法務と正式に合意しておく
• 3段階の層分け:
  • Tier 1: 金銭・権限・PIIに直結し法令が要求するもので、CDCとアプリログを併用する
  • Tier 2: 注文ステータスや在庫など業務上重要なもので、アプリログとトリガーベースの変更検知を用いる
  • Tier 3: マスタや低頻度・低リスクのもので、基本監査フィールドのみか監査なしとする
• トリガーベースの中間層:
  • DBトリガーで変更前後の値を汎用監査ログテーブルに書き込む方式はCDCほどのインフラコストがかからない
  • DB直接更新もある程度捕捉でき、アプリログのみとフルCDCの中間として機能する
• リスクと軽減策:
  • 新機能追加時にテーブルが金銭に触れるかをチェックリスト化しないと、Tier分類が次第に形骸化する
  • Tier 3では直接アクセスできる人・システムを最小化し、アクセス制御の強化でリスクを相殺する
  • 選定基準と承認履歴を文書化しておくと、実際の監査対応がスムーズになる

(2026/08/10)

中国製ルータ20機種に「隠しバックドア」、世界10万台超か…35秒ごとに外部通信判明

• 中国製ルータ20機種に「隠しバックドア」、世界10万台超か…35秒ごとに外部通信判明（ビジネス＋IT） - Yahoo!ニュース

要約:

■ 1. 中国製ルータのバックドア発覚

• ENDLESSDOORS の公表:
  • 米サイバーセキュリティ企業VulnCheckが8月5日に公表
  • 中国・深センのZbtlinkが製造するルータ20機種のファームウェアに、外部から機器を操作できるバックドアが組み込まれている
• 全ファームウェアへの混入:
  • 研究チームが調べた21のファームウェアイメージすべてに遠隔操作用コードが含まれる
  • 機器の起動時に自動実行される
• 35秒ごとの外部通信:
  • 対象機器が35秒ごとに外部と通信する挙動が判明

■ 2. バックドアの技術的仕組み

• rctl の改変版:
  • Linux向け遠隔操作ツール「rctl」を改変したもの
• ルータ側からの発信接続:
  • ルータ側からC2（指令・制御）サーバへ接続する仕組み
  • インターネット側から対象機器へ直接アクセスできない環境でも通信が成立する
• root権限での操作:
  • 接続後は送られたコマンドをroot権限で実行できる
  • 対話型シェルの起動も可能
• 実機再現とCVE付与:
  • VulnCheckが実機でこの挙動を再現し、CVE-2026-66747を割り当てた

■ 3. 影響範囲

• 世界10万台超の展開:
  • 対象機器は世界で少なくとも10万台が展開済みとみられる
• OEM/ODM製品への波及:
  • OEM/ODM製品にも広がる可能性がある

■ 4. 規制動向と調達への示唆

• 米FCCの規制強化:
  • 3月に外国製コンシューマー向けルータの新規モデルを原則として「Covered List」に追加した
  • 新たな機器認証を制限した
• 日本の調達方針:
  • 政府や自治体のIT機器調達で安全性を重視する動きが進んでいる
• 調達時の確認範囲:
  • メーカー名だけでなく、ファームウェアやOEM供給元まで確認する重要性が改めて浮き彫りになった

論評:

■ 1. Zbtlinkの公式説明

• rctlに関する製造元の主張:
  • もっぱらアフターサービス用の技術支援ツールである
  • 顧客の明示的な要請、許可がある場合にのみ使用する
  • 無断アクセスに使われたことはない
• 取材に対する追加の説明:
  • この機能はアフターサービス保守のためのものであり他の目的はない
  • 通常はサンプル機にのみ残される

■ 2. リモート保守機能の一般性

• 業界標準としてのリモート管理:
  • ISP提供のルータやエンタープライズ機器では、TR-069（CWMP）のような標準化されたリモート管理プロトコルが広く使われている
  • 事業者がファームウェア更新や設定変更、障害診断を遠隔で行うための正規の仕組み
• ただし、正規の仕組みには重要な条件が伴う

■ 3. 正規の保守機能との相違点

• 認証、暗号化の欠如:
  • 正規のリモート管理は証明書ベースの相互認証やTLS暗号化が前提
  • 今回のrctlは認証も暗号化もなく、接続先を握った者が任意のコマンドをroot権限で実行できる状態
• 秘匿設計:
  • プロセス名を偽装するなど、正規の保守ツールなら不要な隠蔽が施されている
  • プロセス名は正規のカーネルスレッドを装うkworkerに偽装され、タスク一覧を見ても気づきにくい
  • 通常の保守ツールの設計思想とは相容れない
• ユーザーの関与がない:
  • 正規の遠隔サポートは通常、ユーザーの同意やセッション開始の操作を伴う
  • 今回はルータ側からC2サーバへ常時ビーコン接続する仕組み
  • ユーザーが関知しないところで機器が外部と通信し続ける
• 量産機への混入:
  • Zbtlink側は量産出荷には含まれないと説明している
  • VulnCheckは現在入手可能な21種類のファームウェアイメージすべてに、2年以上にわたってこの実装が含まれていたとしている
  • 主張と検証結果に食い違いがある

■ 4. 設計そのものへの評価

• 正当な保守機能が成り立つ前提:
  • リモートで機器の状態を把握しサポートに役立てるという発想自体は業界的に一般的
  • 認証、暗号化された通信という原則の上に成り立つ
  • ユーザーの同意、可視性という原則の上に成り立つ
  • 最小権限という原則の上に成り立つ
• バックドアという評価の妥当性:
  • 無認証、無暗号でroot権限を握れ、プロセスを偽装して隠す設計は正当な保守機能の実装とは呼べない
  • セキュリティ研究者がバックドアと評価するのも妥当
• メーカーの説明が変えられないもの:
  • 保守用ツールだという説明は機能の目的の主張にすぎない
  • 設計そのものがリスクを内包していたという事実は変わらない

■ 5. 意図的なバックドア説の材料

• 秘匿工作の存在:
  • 正規の保守ツールなら隠す必要がない
  • プロセス名をkworkerに偽装してタスク一覧から見えにくくしていた点は、単なる設計上の手抜きでは説明しにくい
• 通信の秘密性:
  • 平文とはいえ、35秒ごとに常時ビーコンを打ち続ける挙動を示す
  • 必要なときだけ接続する通常の保守セッションとは性質が異なる
• 継続性:
  • 2年以上、21のファームウェアイメージすべてに一貫して存在していた
  • 単発のミスではなく設計方針として組み込まれていたことを示唆する
• 地政学的文脈:
  • 中国製通信機器を巡る既存の警戒感（FCCのCovered Listなど）が存在する
  • 意図的という解釈に説得力を持たせる背景となる

■ 6. 度し難い不作為説の材料

• 流用された既存ツール:
  • rctl自体は2015年1月にGitHubへアップロードされたまま更新が止まっている古いオープンソースツール
  • Zbtlinkが独自に開発した秘密工作用コードではなく、既存の管理ツールを流用、改変したもの
  • ゼロから仕込んだというより、ずさんな管理体制のまま量産に流出した筋書きとも整合する
• コスト優先による実装省略:
  • 認証、暗号化を実装しない判断は、悪意がなくてもコストや手間を惜しんだ結果として十分あり得る
  • 低価格帯のOEM/ODM機器ではセキュリティ実装が後回しにされる例は珍しくない
• 偽装の別解釈:
  • kworkerへの偽装は意図的な隠蔽と見ることもできる
  • 開発時のデバッグ用の名前付けや、既存コードのコピー&ペーストの副産物という可能性も完全には排除できない

■ 7. 現時点で判断できないこと

• 意図の立証の欠如:
  • VulnCheckも含め、外部の第三者機関が誰がなぜこのコードを組み込んだのかまで立証した報告は出ていない
  • 国家の関与を示す直接証拠も、社内の一開発者が判断したことを示す証拠も公開情報からは確認できない
• 事実関係の未確定:
  • Zbtlink側のサンプル機のみという説明とVulnCheckの量産機全てに存在という調査結果は真っ向から対立している
  • この事実関係自体が未確定
• 決め手となる争点:
  • 二択の判断を分けるのは隠蔽工作をどう評価するか
  • 単なる過失なら通常は隠さないという直感は説得力がある
  • 国家的なバックドアと断定するには意図の立証が別途必要であり、現状はそこまでの証拠は公開されていない
• セキュリティ業界の実務的立場:
  • 意図の断定ではなく、パッチ適用の問題ではなく機器の信頼性の問題として扱うべきという立場に落ち着いている
  • 動機を問わず信頼できない機器として扱うという姿勢

■ 8. メーカーとしての信頼喪失

• 致命的という評価は妥当:
  • ルーターメーカーとして致命的に信頼を喪失したと評価してよい
• 不作為説を取ってもなお致命的:
  • 無認証、無暗号でroot権限を渡すコードを2年以上、20機種、21イメージすべてに気づかず出荷し続けた事実がある
  • セキュリティ管理体制そのものが機能していなかったことの証明になる
  • 気づかなかったのだとしたら、それ自体がベンダーとしての適格性を疑わせる
• 説明の一貫性の崩壊:
  • 量産出荷には含まれない、サンプル機にのみ残されるという説明と調査結果が食い違う
  • 食い違い自体が説明への信頼性を損ねる
  • ベンダーが自社製品の実態を正確に把握、説明できていない時点で、この会社の言うことを信用できるかという別の問題が生じる
• 修正の見込みがない:
  • 修正ファームウェアが提供される見込みがなく、対処は検知、隔離、交換のいずれかになると報じられている
  • パッチで解決できる性質の問題ではなく、機器そのものを信頼できないものとして扱わざるを得ない
  • 製品ライフサイクル全体を通じた信頼回復の道が閉ざされていることを意味する
• サプライチェーン全体への波及:
  • ZbtlinkはOEM/ODMメーカーであり、自社ブランド以外にも供給している
  • 社名を知らない消費者、調達担当者にも影響が及ぶ可能性がある
  • 型番だけでなく実際のファームウェア供給元まで遡って確認する必要があるという教訓を業界に突きつけた
  • 一企業の信用問題を超えて、OEM調達モデル全体への不信につながる

■ 9. 評価に対する留保

• 市場による差異:
  • 致命的の中身は市場によって異なる
  • 日本や米国のようにFCCのCovered Listのような規制的な締め出しが進む市場では事実上の排除に近づく
  • 価格優先度が高い新興国市場やブランド認知が薄い流通チャネルでは、OEM先を変えるだけで生き残る可能性も残る
• 企業存続の余地:
  • 独立監査の受け入れ、透明性のある情報開示、代替機の無償提供など今後の対応次第でまだ変わる余地はある
  • 現時点でそうした信頼回復の動きが十分示されているとは言えない
• 調達判断としての結論:
  • 技術的な観点でも説明の一貫性の観点でも問題がある
  • 今後この会社の製品を無条件で信頼することはできないと評価するのが合理的

(2026/08/09)

timesを書く自由と、読ませる責任──お気持ちを拾う工数の10年

• timesを書く自由と、読ませる責任──お気持ちを拾う工数の10年｜久松剛

要約:

■ 1. timesを巡る議論の前提

• timesは好きにすればよい:
  • 書きたい人が書き、読みたい人が読む分には業務の邪魔にならない
• 違和感が生じる場面:
  • 「timesに書いたんですが」とtimes前提で仕事の話をされるとツラい
• 議論の再燃点:
  • 社内Slackのtimesで「お気持ち」を書くなという記事が起点

■ 2. 分報という起源

• times文化の始まり:
  • 2015年頃の記事から広まり、元は日報に対する「分」を意味する分報
• 典型的な形式:
  • 「times_氏名」のような個人チャンネルを各自が持ち、そこに随時書き込む
• 分報の意図:
  • 一日の終わりにまとめる日報と異なり、リアルタイム性の高い報告を目的とする
  • 今何に詰まっているか、何を調べているかをその場で流し、周囲が早く助けに入れる
• 仕組みとしての評価:
  • 合理的な発想である
• 日本特有の文化:
  • 海外ではrandomチャンネルを雑談用に使うことはあっても、分報のような使い方は見られない

■ 3. 社内Twitter化と意味の上書き

• 社内Twitter化した実態:
  • 技術メモや作業ログもあるが、ランチの写真、仕事への愚痴、時事ネタへの感想が混ざって流れる
  • 業務の詰まりどころを共有する場ではなく、お気持ちや雑感が流れる場になった
• 消極的な容認:
  • 「Twitterに書かれるよりまし」という理由で受け入れられてきた
  • 社外に不満を書かれて炎上するくらいなら社内に書かせておくという判断
• コロナ禍での位置付け:
  • フルリモート環境下のコミュニケーション手段にカウントされていった
• 会社紹介資料での扱い:
  • 分報という意味合いでの紹介はほぼなく、風通しの良さや心理的安全性の文脈で語られる
  • リアルタイムの業務報告として生まれたものが社風や福利厚生の一部として扱われるようになった
• 議論が噛み合わない理由:
  • この経緯で意味合いが何度も上書きされてきたため

■ 4. 業務の前提に組み込まれた瞬間の問題

• 問題の発生点:
  • timesが業務の前提に組み込まれた瞬間に問題が発生する
• 若手からの苦情:
  • 「timesに書いたのに会社の制度が変わらない」という不満が複数の企業で見られる
  • 本人たちに悪気はなく、きちんと発信しているという感覚でいることが多い
• timesの位置付け:
  • 分報として機能していないtimesは便所の落書きであり、タバコ部屋の雑談に等しい
  • 正式な業務報告には値しない
• 期待の非対称性:
  • タバコ部屋で愚痴を言って制度が変わらないと怒る人はいない
  • timesだけがなぜか、書けば拾ってもらえる場として期待されている
• 組織側の問題:
  • 正式な提案ルートが機能していない、または入社後に教えられていないという側面もある
  • ただしそれによってtimesが業務報告に格上げされるわけではない

■ 5. 拾う側が払う工数

• 期待に応えるリーダーの存在:
  • 複数並べたディスプレイの一枚でずっとtimesを監視しているリーダーを見たことがある
• それはマネジメントではない:
  • 部下のつぶやきを常時監視し、拾い、フォローしなければ回らないなら飼育である
  • 書き込めば大人が気付いて拾い上げてフォローする光景は職場より保育園に近い
  • だから「園児ニア」などと揶揄される
• コストの非対称:
  • 書く側は数十秒で済むが、拾う側は全部下のtimesを読み、文脈を推測し、声を掛けるか判断する工数を払う
  • この非対称に無自覚なまま「書いたのに」と言われても組織としては応えようがない

■ 6. エンジニアバブルの名残

• 非対称な期待が放置された理由:
  • times文化が根付いたのが各社でITエンジニアの正社員数を競っていたエンジニアバブル期だから
• 採用コストとしての正当化:
  • エンジニアの機嫌を損ねないことが優先され、お気持ちを拾う工数は採用コストの一部とされた
  • timesを見てフォローしてくれる上長は実質的に福利厚生だった
• 市場の変化:
  • エンジニア採用は数を揃えるフェーズを終え、選別のフェーズに入った
  • 今の転職市場が求めているのはコミュニケーション力や事業貢献
• 福利厚生の終了:
  • お気持ちのフォローを提供し続ける理由は企業側からすでに消えている
  • 上長に見せることを前提としたtimesは逆行している
• あるべき振る舞い:
  • 言いたいことは自身の中でまとめ、然るべき場に建設的な議論という形で出すべき
  • 課題を感じてから議論に持ち込むまでを自力でやり切れることがコミュニケーション力として評価される
  • timesに書いて拾われるのを待つのはその真逆の振る舞い

■ 7. ライバルとしてのAI

• メンバー層のライバル:
  • 多くのメンバー層のホワイトワーカーにとってライバルはAI
• 上長の現状:
  • 先進的な企業の上長は、部下だけでなくAIが上げてくる内容の精査とフィードバックに疲れている
• AIとの比較:
  • AIは文句を言わず、お気持ちも書かず、成果物だけを上げてくる
  • 拾ってもらえなかったことに不満を溜めることもない
• 組織の余裕:
  • お気持ちを拾ってもらう前提で働く人間を抱える余裕がどれだけ残るか疑問である
  • timesを拾うことを上長に強制する働き方は組織から排除されても仕方がない

■ 8. timesの活用余地

• 人が読むのをやめる方向:
  • SlackをAIで定期的に舐めさせ、お気持ちを除外して課題や詰まりどころだけをサマライズさせる
  • 分報が本来目指したリアルタイムの状況把握が人間の工数を掛けずに手に入る可能性がある
• 皮肉な結論:
  • timesを読むのに最も向いているのは上長ではなくAI

■ 9. 問われているのは読む工数

• 議論のすり替え:
  • 必要・不要論はチャンネルを残すか消すかの話として語られがち
• 本当の論点:
  • 問われているのは書く自由ではなく読む工数の方
• 前提が変わる瞬間:
  • timesは好きにすればよいが、誰かに読んでもらう前提にした瞬間に無料ではなくなる
• 議論の出発点:
  • その工数に見合う価値が自分の書き込みにあるのか
  • 読む側の工数を組織として払い続けるのか

(2026/08/09)

TSON (Typed Schema Object Notation)

• TSON (Typed Schema Object Notation)

要約:

■ 1. TSONの概要

• TSONの定義:
  • Typed Schema Object Notationの略称
  • JSONの上位互換でありながら、より堅牢なスキーマ検証の仕組みを提供することを目指す
• TSONを構成する2要素:
  • 不変・ハッシュ固定のスキーマシステム
  • Unicode対応のJSONスーパーセットとなるデータフォーマット
• ハッシュ値によるチェーン検証:
  • ドキュメントが自身のスキーマを指定し、そのスキーマがさらにメタスキーマを指定する構造を取る
  • たった一つのハッシュ値でチェーン全体を検証できる点が最大の特徴

■ 2. スキーマの不変性

• スキーマは変更しないという原則:
  • TSONの設計思想で最もユニークな点
• 必須フィールド追加の扱い:
  • 通常のAPI設計では、必須フィールドを後から追加することは破壊的変更となるため一般的に禁止されている
  • Google、Microsoft、Zalandoなどのガイドラインでも言及されている
• 新バージョンを新ドキュメントとして扱う方式:
  • 新しいバージョンは新しいハッシュを持つ新しいドキュメントとして扱う
  • 新旧スキーマが同時に共存でき、後方互換性の問題を回避できる
• 未知フィールドの扱い:
  • 未知のフィールドは常にエラー扱いとする
  • タイポなどをその場で検出するための設計

■ 3. スキーマ記法の主な機能

• フィールドの5状態:
  • 必須、デフォルト値(~)、固定値(=)、オプション(?)などを明示的に宣言する
• 型付けの対象:
  • 配列、タプル、セットを型付けできる
• 列挙型と制約付きアトム:
  • 列挙型(enum)を利用でき、^で制約を追加した制約付きアトムも定義できる
• 合成(composition):
  • &で型を組み合わせ、フィールドの重複を許さない
• 精密化(refinement):
  • ^で継承したフィールドをより厳密化する
  • 既定値の変更は可能だが、固定値は変更できない
• 減算(subtraction):
  • -でフィールドを明示的に除外する
• 選択型(Choice/Union):
  • 構造的に区別可能であれば型タグを不要とする
• フィールドグループ:
  • どちらか一方必須という条件をタグなしで表現する
• テンプレート:
  • 型パラメータ、値パラメータを持つ汎用定義

■ 4. データフォーマットとしての特徴

• クオートなしの識別子:
  • Unicode対応であり、多言語を扱える
• カンマの扱い:
  • カンマは空白扱いとなり、区切りとして任意である
• 数値リテラル:
  • 任意精度の数値を扱え、16進数、2進数リテラルを直接書ける
• 複数行文字列:
  • トリプルクオートで記述する
• マップとレコードの区別:
  • JSONはキーを強制的に文字列化するが、TSONは任意の値をキーにできる
• _(absent)センチネル:
  • 値がないという状態とnullを区別する
• アノテーション(@):
  • 値にメタデータを付与でき、コメント構文の代わりになる
• 型注釈:
  • !date、!uuidなどにより、スキーマなしでも値の型を明示できる

■ 5. 互換性と現状

• 厳密な上位互換設計:
  • すべての正当なJSONドキュメントは、そのままTSONとしても有効
• 仕様の成熟度:
  • 現時点ではワーキングドラフト段階であり、まだ仕様変更の可能性がある
  • Java実装が既に動作している
• 将来のエンコーディング計画:
  • JSON、コンパクト形式(TOON)、バイナリなど複数のエンコーディングのサポートを計画

■ 6. TSONの位置づけ

• ASN.1に通じる思想:
  • スキーマこそが本体で、フォーマットはそれを運ぶ器という思想を持つ
• 組み合わせによる新しい試み:
  • JSONの読み書きやすさとProtobuf的な厳格な型検証を組み合わせる
  • さらにハッシュによる改ざん検知、バージョン管理と結び付ける

(2026/08/09)

AI研修(Day2)【MIXI 26新卒技術研修】

• AI研修(Day2)【MIXI 26新卒技術研修】 - Speaker Deck

(2026/08/09)

AI研修(Day1)【MIXI 26新卒技術研修】

• AI研修(Day1)【MIXI 26新卒技術研修】 - Speaker Deck

(2026/08/09)

The End of No Code

• The End of No Code - exe.dev blog

要約:

■ 1. No Codeの終焉

• Airtable買収という節目:
  • Bending SpoonsがAirtableを12.8億ドルで買収した
  • ローマは一日にして崩れないが、No Codeプラットフォームが最盛期を過ぎた瞬間を示す地点として妥当
• 立場の開示:
  • 自分はAirtableに長年在籍し、製品を愛し、共に働いた人々をそれ以上に愛している
  • 変わったのは技術であり、ツール使用を伴うLLMループの理不尽なほどの有効性が原因

■ 2. 業務ソフトウェアの本質

• ソフトウェアは手段:
  • 職場のソフトウェアはそれ自体に価値はなく、何らかの目的に奉仕するために作られる
  • 用途の大半は何かを記録し管理することであり、スケジュール、部品、注文、人などが対象
• スプレッドシートの天井:
  • 表計算はこの領域における普遍的なソフトウェアであり、自分自身も愛用する
  • 共有、プログラミング、権限、自動化などの面で限界がある
• データベースへの昇格:
  • スプレッドシートを離れるとデータベースとその上のソフトウェアに移行する
  • それがAirtableのようなローコード/ノーコードプラットフォームの正体
• 導入者が運ぶもの:
  • チームにAirtableを持ち込む人が本当に持ち込んでいるのはAirtableではない
  • 切実に必要とされる組織化とプロセスであり、Airtableは単なる手段

■ 3. Airtableが正しかった点

• テーブル作成の体験:
  • Excelのように列を追加し、データ型として文字列、数値、日付などを選ぶだけでテーブルが完成する
  • ALTER TABLE widgets ADD COLUMN (color string)というウィジェットを持たない方式の有効性を、データベースの大規模学会SIGMODで発表すべきだと冗談を言っていた
• Fred Brooksの洞察:
  • フローチャートを見せられテーブルを隠されたままでは謎は解けない
  • テーブルさえ見せられればフローチャートは通常不要で、自明になる
  • ユーザーがビジネスモデルを自ら記述できれば、その上に自動化や機能を作ることが可能になる
• 発想自体は新しくない:
  • FileMakerは1985年に登場し、自分にとってのデータベース入門でもあった
  • 約1,600人の高校生向け会議の運営では、わずかな加点と新入生とAppleTalk接続の3台のコンピュータで郵送の登録用紙を処理できた

■ 4. IT部門とSaaSの歴史

• 90年代の自社開発:
  • 企業のIT部門は自社のためにソフトウェアを作る存在であり、多くは個別受注的な開発
• SaaS台頭の里程標:
  • Salesforceの2000年の「Software is Dead」キャンペーンがSaaS支配の始まりを示す目印
  • IT部門の仕事は調達となり、調達とはNOと言うことを意味する
• 穴を埋めた道具:
  • ローコード/ノーコードプラットフォーム、Microsoft SharePoint、Excel、Google Sheetsが不足を補った
  • ソフトウェアを買えないとき、人はアクセスできるもので間に合わせる
• 撤去できなくなる構造:
  • Airtableを密かに持ち込み、売上や効率や信頼を向上させる
  • 一度荷重を支える存在になると、官僚的な理由で誰もそれを排除できなくなる

■ 5. インフラという障壁

• EC2登場後も残った壁:
  • AWSは2006年にEC2を開始し、VMを借りられるようになった
  • 同僚と何かを共有するためにインターネットへ出すには、EC2 VPC、IAM権限、EBS、RDS、静的IP、DNSなど多数の三文字略語の学習が必要だった
• ソフトウェア企業内でも同じ:
  • ソフトウェア企業の内部ですらIT部門がEC2をゲートキープしていた
  • 2007年のGoogleでは、社内コードベースの検索ツールがJeff Deanの机の下の予備デスクトップで動いていた
  • 自分にとって決定的に重要なこのインフラをデータセンターのマシンで提供させるのは、手間が大きすぎた

■ 6. 2026年の答えはLinux

• 現在の問い:
  • LLMが王であり、SaaSの終末は破産と同じく徐々に、そして一気に進行している
  • 業務ツールを構築しデプロイする正しい方法と正しいプラットフォームは何か
  • ソフトウェアエンジニア以外の人間に任せられるかどうか
• 退屈な技術を選ぶ:
  • 正しい答えはLinuxであり、退屈な技術を選んでLinuxを使えばよい
  • Linuxの上のスタックは選択肢が多く、LAMPを選んでも何の問題もない
• 現在の好みのスタック:
  • 自分の現在の選好はsqlite、Go、TypeScript、場合によってVue
  • メモリが高価でなければPostgreSQL、Node、TypeScriptでも問題ないが、メモリ逼迫は現実の制約
  • コードを自分で書かない以上、フロントエンドとバックエンドで単一言語を使う利点は消滅した
• ロックインの弱さ:
  • スタック全体がオープンソース
  • AWS、GCP、Render、Azure、Oracle Cloud Infrastructure、Railway、Hetzner、miniPCのいずれに移行してもデータとコードをrsyncすれば済む
  • プラットフォームレベルのロックインはローコードプラットフォームに比べて弱い
  • 既存のローコード構成も、エージェントに数回プロンプトを与えればLinuxへ移植される

■ 7. exe.devのアプローチ

• 提供するもの:
  • サブスクリプションでLinux VMを作成でき、意味のある形でインターネット上に存在する
  • 友人にリンクを送れば、そのリンクは機能する
  • デフォルトで安全であり、自社の認証システムまたは独自の認証でサイトを公開できる
  • 高速であり、コーディングエージェントに適する
• 本番で直接作る:
  • カスタムソフトウェアはコーディングエージェントとともに本番環境でそのまま構築する
  • 使えるものになるまで反復し、同僚のフィードバックでさらに反復する
  • 同僚自身にも反復させ、粗い部分を削らせる
• エージェントに与える情報:
  • ビジネスのデータモデルとワークフロー、可能ならスタックの示唆を与えれば、エージェントは十分にこなす
• 例外となる1%:
  • 業務上決定的に重要な領域へ昇格が必要な1%のプロジェクトなら、2台目のVMと開発環境を用意する
  • 現代的ソフトウェア開発の紛らわしい装置であるgitに進んでもよい
• low floor, high ceiling:
  • Linux上で動くLLMは究極の「low floor, high ceiling」
  • まず始めさえすれば、スプレッドシートを置き去りにできる

■ 8. FAQ: セキュリティと移行

• データの安全性:
  • デフォルト設定が安全であり、仕組みはGoogle Sheetに酷似する
  • VMのWebポートをチームだけ、個々の相手、あるいは全世界に共有できる
• 既存資産の移植:
  • VMを起動し、デフォルトでプリインストールされたエージェントShelleyのもとを訪れる
  • 既存ソリューションのAPIキーを渡すか、スプレッドシートをアップロードする
  • このマシン上のWebアプリケーションへ移植するよう指示すれば、実行される
  • 現時点ではモデルとしてSolかOpusを使い、答えは頻繁に変わるので今後はDiscordで尋ねればよい

■ 9. FAQ: 自動化とエージェント

• スケジュールと自動化:
  • Linuxは豊かなプラットフォームであり、エージェントにタイマー実行を依頼すれば実現される
  • 通常はsystemdが選ばれるが、cronを好むなら誘導すればよい
  • どちらも知らなくても問題はない
• エージェントやボットの構築:
  • 「exe.devのLLM統合を使ったエージェントループ」を、必要なツール付きで書くようエージェントに依頼する
  • 特定チャンネルのSlackスレッドを読んでコメントするような実装を、エージェントはワンショットで仕上げる
• Integrationsシステム:
  • exe.devプラットフォームの最良の点の一つ
  • ボットをSlackへ接続することがかつてないほど容易になっている

■ 10. FAQ: 品質と方法論

• Vibe Codingの十分性:
  • 自分の経験では十分に通用する
  • 通常はリスクとリターンを測る話であり、スプレッドシートの数式はどれも脆く未テストでありながら現に機能している
• フレームワークの要否:
  • 好きなフレームワークを使えばよいが、最終的にエージェントは自ら選ぶか、退屈な方法で片付ける
  • ベストプラクティスは世界中で無数に矛盾している
  • 「P & L FINAL FY2025 FINAL VERSION 3」が依然として中央値の解であり、まず自分のワークフロー要件を見極めるべき
  • データベースをどこかへバックアップするcronジョブもエージェントに設定させておく
• 性能とテスト:
  • エージェントは自らの成果物のテストと性能問題の修正の双方で驚くほど優秀
  • 自分が使うのと同じプロファイラなどのツールを使う
  • Shelleyの秘密兵器は使いこなせる優れたブラウザツールであり、プロファイラ、スクリーンショット、スクリーンキャストを備える

■ 11. FAQ: 価格

• 基本プラン:
  • 月額20ドルで最大50台のVMを利用でき、各VMは2CPUと8GBメモリに制限される
  • チーム向けの小さなアプリなら十分な規模
• 拡張と課金:
  • より多くのリソースが必要ならアップグレードするか相談すれば、必要な大きさのマシンを用意する
  • 構築にサブスクリプション付属分を超えるLLMトークンが必要になる場合がある
  • ChatGPTのサブスクリプション、他のコーディングエージェント、他のモデルプロバイダを接続でき、APIトークン原価での提供も可能

(2026/08/09)

Wyzer Programming Language

• Wyzer Programming Language
• GitHub - Wyzer-Lang/wyzer: The Wyzer Programming Language · GitHub

README.md要約

■ 1. Wyzerの概要

• Wyzerの位置づけ:
  • 新しいプログラミング言語であり、READMEに仕様と思想が記載されている
• 言語の4つの特徴:
  • 静的型付けかつコンパイル型である
  • 所有権ベースの設計によるリソース指向である
  • choreographic programming(コレオグラフィックプログラミング)による分散安全性の統合である
  • Perceusメモリモデルを採用している

■ 2. 開発の動機

• Rustの限界:
  • Rustはプロセス内の安全性は保証するが、分散システムの問題は解決しない
• 未解決のまま残る分散システムの問題:
  • 分散デッドロック
  • プロトコルの不一致
  • サービス間の整合性エラー
• choreographic programmingの導入:
  • 上記の問題を解決するために導入している
  • 複数の参加者間の通信プロトコルを1つの振り付け(コレオグラフィ)として記述する手法である
  • 記述したコレオグラフィから各participantのコードを自動生成する

■ 3. 技術的な新規性

• 新規性の所在:
  • 既存の要素を新しい組み合わせ方で統合している点にある
• 各要素の由来:
  • Perceus参照カウントはKoka、Lean 4から着想を得ている
  • Choreographic programmingは学術研究から着想を得ている
• 独自の点:
  • コレオグラフィの考え方は通常ネットワーク通信にのみ使われる
  • その考え方をメモリ管理、スレッド、割り込み処理にまで同じルールで適用しようとしている
• 核心コンセプト:
  • 1つの所有権ルールでメモリ、並行性、ネットワークすべての安全性を証明する

■ 4. 言語仕様

• 変数の可変性:
  • 変数はletによりデフォルトでイミュータブルである
  • 可変にする場合はvarを明示する
• 定数定義:
  • constでコンパイル時定数を定義する
• データ構造:
  • structでデータ構造を定義しフィールドに直接アクセスする
• 制御構文:
  • if/else、while、forをサポートする
  • 条件式に括弧は不要である
• エラー処理:
  • Result<T, E>型とmatch式で明示的に行う
  • 隠れた例外やasync/awaitの分離は存在しない

■ 5. 設計思想

• 書き方の一意性:
  • 同じことをする書き方は1つだけという原則を採る
  • TIMTOWTDIの逆にあたる考え方である
• 明示と省力化の両立:
  • 重要な処理は隠さない
  • 余計なボイラープレートは書かせない
• コンパイラへの委譲方針:
  • コンパイラに任せられる部分は任せる
  • 曖昧さが生じる場合は明示ルールを要求する
• 課題の開示:
  • 未解決の課題は正直に開示する

■ 6. 現状と位置づけ

• 初期段階の研究プロジェクト:
  • FAQセクションで作者自身が初期段階の研究プロジェクトであると明言している
  • 本番運用可能かという問いに対し、多くの大きな課題が未解決であると正直に述べている
• Rustとの関係:
  • Rustの代替ではない
  • Rustの安全性を学習コストを抑えつつネットワーク領域にも拡張できるかという実験的な試みである
• AIの利用範囲:
  • コミットメッセージ生成に使用した
  • choreographic programmingやPerceusモデルの調査に使用した
  • ロゴデザインの発想補助に使用した

レビュー:

■ 1. 問題設定の妥当性

• 所有権の不明確さという診断:
  • 所有権が不明確であることがメモリバグ、デッドロック、ネットワークエラーに共通する根本原因であるという診断は筋が通る
• Rustからの発想の拡張:
  • Rustの所有権モデルがメモリ安全性で成功した実績を踏まえれば、同種のロジックを他領域に拡張する発想自体は理にかなう

■ 2. Perceus選択の堅実さ

• GCと借用チェッカーの中間解:
  • GC任せにせず、かつRustの借用チェッカーほど複雑でない中間解として現実的な判断
  • Koka、Lean 4で実証済みのPerceus参照カウントを採用している
• 関数型記述と破壊的更新の両立:
  • 関数型的に書き、単一所有時はコンパイラが破壊的更新に変換するアプローチ
  • 学習コストと性能のバランスを取る妥当な選択

■ 3. Choreographic programmingの学術的蓄積

• 実在する研究領域:
  • 思いつきではなく、Pict、Chor、HasChorなど実際に学術的蓄積のある分野
• 現状認識の正確さ:
  • 研究止まりで実用言語に持ち込まれていないという現状認識は正確
  • そこにギャップを見出す動機は妥当

■ 4. 単一ルールでの全領域解決への疑問

• 数学的構造と実務要求の乖離:
  • メモリ安全性、並行性安全性、ネットワーク安全性は数学的には線形/アフィン型という似た構造を持つ
  • 実務上の要求は大きく異なる
• メモリの性質:
  • 単一プロセス内、ミリ秒単位、失敗コストは低い
• ネットワークの性質:
  • プロセス間、秒〜分単位で、部分的失敗が常態
  • タイムアウト、再送、片方だけクラッシュといった事象が起こる
• コレオグラフィ理論の理想化:
  • メッセージは必ず届く、参加者はクラッシュしないといった理想化を前提にしがち
  • 実ネットワークの非同期性、部分的故障を所有権ルール一本でどう扱うかはREADME内で具体化されていない
  • 言うは易く行うは難しの核心部分と思われる

■ 5. 型シグネチャによる見える化の不明確さ

• 主張と実例の乖離:
  • 型を見ればネットワークプロトコルがわかるとあるが、実際のコード例はstruct Point程度でこの機能が全く示されていない
• 分散プロトコルの型表現の難しさ:
  • セッション型研究でも複雑化しやすい部分
  • 具体的シンタックスがないと評価しづらい

■ 6. スレッド、割り込み拡張の説明不足

• 割り込み安全性の証明という主張:
  • 同じルールで割り込み安全性も証明するという主張は野心的
• コレオグラフィとの相性:
  • 割り込みは典型的に非同期かつプリエンプティブ
  • あらかじめ決まった振り付けという発想と相性が悪いように見える
• 判断材料の不足:
  • 詳細はRESEARCH.md側にあるかもしれないが、それなしには判断が難しい

■ 7. Rustより簡単との根拠の薄さ

• Perceus採用が寄与する範囲:
  • 借用チェッカーを避けてPerceusにする点は性能と学習コストに寄与する
• 線形性ルールの全面適用:
  • 所有権は一度使ったら二度と使えないというRust同様、むしろより厳格な線形性ルールを持つ
  • これをメモリ、ネットワーク、スレッドに全面適用するなら、学習曲線がRustより緩やかになる保証はない
• 表面文法と学習コストの本質:
  • let、var、matchといった表面文法は平易
  • それはRustの学習コストの本質である借用、ライフタイム推論とは別問題

■ 8. 総評

• 方向性の正当性:
  • 所有権を分散システムまで統一的に拡張するコンセプトの方向性は学術的にも興味深い
  • 正当な研究テーマである
• README単体での不足:
  • 1ルールで3領域を統一するという理論的主張の具体的メカニズムが提示されていない
  • コード例が基礎文法止まりで、型からプロトコルが読める、割り込み安全性といった核心を実証していない
  • 分散システム特有の部分的故障、非同期性への対処が語られていない
• 現時点での位置づけ:
  • 作者自身が早期の研究段階、大きな課題が未解決と認めている
  • 現時点ではビジョン表明であり、設計の実現可能性はRESEARCH.mdや形式仕様を見ないと判断できないというのが公平な評価

(2026/08/09)

Web API設計の現在地2026 #HTTP

• Web API設計の現在地2026 #HTTP - Qiita

要約:

■ 1. 記事の狙いと背景

• Web API設計情報の陳腐化:
  • Web API設計を調べると検索上位の記事が2015〜2019年あたりで止まっている
  • その間にエラーレスポンスの標準ができ、OAuthのグラントタイプは選択基準が変わった
  • APIの廃止告知にまでRFCが生えた
• 一次情報での現在地確認:
  • Web API設計の主要領域ごとに2026年時点で従うべきものを一次情報で確認した結果をまとめる
  • 一次情報とはRFC、IETFのドラフト、大手APIの実装を指す
• 執筆のきっかけ:
  • 2014年の『Web API: The Good Parts』にあった「仕様に従う、仕様がなければデファクトに従う」という指針
  • その仕様とデファクトが今どこにあるのかが気になった

■ 2. 全体マップ

• エラーレスポンス:
  • Problem Details形式で返す、根拠は2023年に標準化されたRFC 9457
• 日時フォーマット:
  • 2026-08-07T12:34:56Z 形式で返す、根拠は20年以上変わらず現役のRFC 3339
• メソッド・ステータスコード:
  • 迷ったらRFC 9110を引く、9110は2022年に旧2616/7231を統合した文書
• 認証・認可:
  • Authorization Code + PKCEを使い、ログイン用途はOIDCを重ねる
  • 根拠は2025年のRFC 9700（BCP 240）で、内容はOAuth 2.1ドラフトへ統合中
• バージョニング:
  • 基本はパスに v1、不特定多数向け公開APIなら日付ベースを検討する
  • 標準はなく、Google AIP-185とGitHub/Stripeの実装が根拠となる
• 廃止告知:
  • Deprecation / Sunsetヘッダで機械可読に伝える、根拠はRFC 9745（2025年）とRFC 8594（2019年）
• ページネーション:
  • カーソル方式にする、標準はなくGitHub/Stripeの実装がデファクトとなる
• レートリミット:
  • 429と X-RateLimit-* 系ヘッダを返す
  • 429はRFC 6585が根拠、残量ヘッダは標準がなく標準化が進行中
• 冪等キー:
  • Idempotency-Key ヘッダを受け付ける、標準化は停滞中でStripeの実装がデファクトとなる
• API記述:
  • OpenAPIで書く、Linux Foundation傘下のOpenAPI Initiativeが仕様を管理し現行は3.2.0

■ 3. エラーレスポンス: RFC 9457 Problem Details

• 最も大きく変わった領域:
  • かつてエラーレスポンス形式は各サービスが独自に設計するものだった
  • { "error": { "code": 123, "message": "..." } } 型やエラー配列型など複数の流派が生まれた
  • 流派が乱立したのは単に標準が存在しなかったからにすぎない
  • 2016年のRFC 7807を初出とし、2023年のRFC 9457でこの状況は終わっている
• レスポンスの形:
  • Content-Typeは application/problem+json を用いる
  • ボディは type、title、status、detail、instance の各フィールドを持つ
• 2つのレイヤーの両立:
  • HTTPステータスコードとアプリ固有のエラー識別子が1つのボディで両立する
  • status にトランスポート層のカテゴリ、type に具体的に何が起きたかのURIが入る
  • この2つは別レイヤーの情報であり、どちらか片方では足りない
• 拡張フィールドの公認:
  • バリデーションエラーのようにフィールド単位の詳細が要る場合、errors 配列などの独自フィールドを足してよい
• フレームワーク対応状況の言語圏差:
  • Spring Framework 6 / Boot 3は ProblemDetail クラスを標準搭載する
    • 組み込み例外の自動problem+json化は spring.mvc.problemdetails.enabled=true によるopt-inとなる
  • ASP.NET Coreは [ApiController] のエラーを ProblemDetails へ自動変換し、デフォルトで有効になる
    • Minimal APIは.NET 7から AddProblemDetails() を呼ぶ必要がある
  • NestJSは組み込み対応がなく、既定は { statusCode, message } 形式で、寄せるなら例外フィルタで自前実装する
  • Express / Fastify / Honoは組み込み対応がなく、既定のエラー形式はそれぞれ独自となる
• 設計者に残る判断:
  • JavaやC#の世界では標準がフレームワークに入り始めている
  • JS/TS系のフレームワークにはまだ入っていない
  • JS/TSでAPIを書くなら、RFC 9457に寄せるかどうかも含めエラー形式の決定は依然として設計者の仕事となる

■ 4. 日時フォーマット: RFC 3339のまま

• 20年変わらない標準:
  • 日時は今もRFC 3339の 2026-08-07T12:34:56Z に従う
  • UTCで Z を付けて返し、表示時にクライアント側でローカライズする分担も含め20年以上変わっていない
• ISO 8601との関係:
  • RFC 3339はISO 8601から曖昧さを排した実用プロファイルという位置づけとなる
  • Web APIで使うのはRFC 3339である

■ 5. メソッド・ステータスコード: 正典はRFC 9110

• HTTP仕様の再編:
  • HTTPそのものの仕様は2022年に再編された
  • RFC 2616（1999年）とその後継のRFC 7230番台（2014年）は置き換わった
  • 統合先はRFC 9110（HTTP Semantics）、9111（Caching）、9112（HTTP/1.1）である
• 現行の正典:
  • メソッドとステータスコードの意味論の現行の正典は9110である
  • 標準としての格もInternet Standardに上がった
• 実務での使い方:
  • ステータスコードの選択に迷ったら9110の該当セクションを引く
  • 「400番台はクライアント起因、500番台はサーバ起因」という原則の出典もここにある
• 429の例外:
  • APIで頻出のコードのうち 429 Too Many Requests は例外となる
  • 出典は追加ステータスコードを定義したRFC 6585（2012年）である
• 資料の鮮度の目印:
  • RFC 2616を引いている解説は、HTTP仕様が2世代前だった時点の記事だと分かる

■ 6. 認証・認可: 変わったのはグラントタイプの選択基準

• 骨格は不変:
  • 現行の標準はOAuth 2.0（RFC 6749、2012年）である
  • 骨格となる4つのロールやトークンの考え方は当時から変わっていない
• 選択基準の変化:
  • グラントタイプの選択基準が大きく変わり、古い記事を信じると事故る箇所となる
  • SPAはかつてImplicitグラントを使ったが、現在は非推奨でAuthorization Code + PKCEを使う
  • ID/パスワードを直接預かるROPCは使用禁止（MUST NOT）となった
  • PKCEはかつてモバイル向けの追加対策だったが、パブリッククライアントでは必須となり、それ以外にも推奨される
• RFC 9700という根拠:
  • RFC 9700「Best Current Practice for OAuth 2.0 Security」は2025年1月に発行されBCP 240となる
  • ROPCをMUST NOT、Implicitを条件付きのSHOULD NOTと規定する
  • パブリッククライアントにPKCEを必須とし、認可サーバ側のPKCEサポートも必須とする
• OAuth 2.1の位置づけ:
  • OAuth 2.1はRFC 9700の内容をOAuth 2.0本体の仕様へ統合し直しているドラフトにすぎない
  • 2020年から議論が続き2026年8月時点でrev 15、まだRFCではない
  • 2.1のRFC化を待つ必要はなく、従うべき文書は既に発行されている
• 認可と認証の区別:
  • OAuth 2.0は認可の仕組みであって認証ではない
  • ログインに使うならOpenID Connectが上に乗る

■ 7. バージョニング: パスの v1 と日付ベースの二大流派

• 標準の不在:
  • バージョニングに標準仕様はなく、完全にデファクトの世界となる
  • 主要サービスを実際に叩いて現在の方式を確認した
• 主要サービスの実測:
  • GitHubは日付+ヘッダ方式で x-github-api-version-selected: 2022-11-28 を返す
  • Stripeは日付+ヘッダ方式で 2026-07-29.dahlia を返す
  • Shopifyは日付をパスに置き、2026-04 のように四半期ごとに刻む
  • GoogleはメジャーバージョンをパスにおきAIP-185で v1 を必須と規定する
  • Microsoft Graphは /v1.0/ /beta/ とメジャー番号をパスに置く
  • Azureは日付をクエリに置き ?api-version=2023-01-01 とする
• 二大流派の分布:
  • パス方式が数では多数派のままとなる
  • 不特定多数の外部開発者を抱える公開API側のGitHub、Stripe、Shopifyが日付ベースに寄っている
  • GitHubは昔の Accept: application/vnd.github.v3+json から2022年に日付ヘッダ方式へ移った点で象徴的となる
• 選択の判断軸:
  • v1 → v2 の一括切り替えは全ユーザーの同時大移動を要求するため現実には起きず、v1が永遠に残る
  • 日付ベースは変更を小さく刻んで各ユーザーが自分のペースで上がるモデルとなる
  • 日付ベースではサーバ側が変換層で差分を吸収するため、そのコストを払えるかで選ぶ
  • クライアントを自分で掌握しているかも判断軸となり、社内・自社アプリ向けならパス方式の弱点は出ない

■ 8. APIの終わらせ方: DeprecationとSunsetヘッダ

• 語られない終わらせ方:
  • バージョニングの記事は世の中に山ほどあるが、その続きにある終わらせ方はほとんど書かれていない
  • 実際にはこの領域も標準化されている
• 2つのヘッダ:
  • Deprecationヘッダ（RFC 9745、2025年）が「このAPIは非推奨です」を伝える
  • Sunsetヘッダ（RFC 8594、2019年）が「この日時に停止します」を伝える
  • Deprecationは「いつから非推奨か」をUnixタイムスタンプで持つ
  • Sunsetは「いつ停止するか」をHTTP日付形式で持つ
  • Link ヘッダに rel="deprecation" を付けて移行ドキュメントも案内できる
• 通知先が変わる価値:
  • 廃止告知をブログとメールでやっても、そのAPIを実際に叩いているコードには届かない
  • レスポンスヘッダに載せればクライアント側のログと監視にそのまま残る
  • 通知先が開発者のメールボックスからクライアントの実行ログに変わる点がこの2つのヘッダの価値となる
  • 廃止予定のエンドポイントを抱えているなら、次の廃止からすぐ使える

■ 9. ページネーション: カーソル方式が主流

• デファクトの結論:
  • ページネーションにも標準仕様はないが、デファクトの答えは固まっている
  • 大量データや無限スクロールならカーソル方式（絶対位置指定）を選ぶ
• オフセット方式の2つの問題:
  • ?page=3 や ?offset=100&limit=20 のオフセット方式は後半のページほど遅くなる
    • OFFSET 100000 はDBが10万件を実際に読んでから捨てる動きとなり、深いページほど線形に重くなる
  • もうひとつの問題はズレることである
    • ページ1を見ている間に新しいデータが1件挿入されると全体が1つずれる
    • 結果としてページ2で同じレコードを二重に見たり、逆に読み飛ばしたりする
• カーソル方式の利点:
  • 「最後に見たID」を基準に WHERE id < :cursor ORDER BY id DESC LIMIT 20 で取得する
  • インデックスで直接その位置に飛べるため何ページ目でも一定速度となる
  • 途中の挿入・削除でもズレない
• カーソル方式のトレードオフ:
  • 「5ページ目に飛ぶ」ができない
  • ページ番号ジャンプが要る管理画面ならオフセット方式にも出番が残る
• 次ページの伝え方:
  • GitHubの Link: <...>; rel="next" が参考になる
  • 方式そのものに標準はないが、伝え方の部品には標準があり Link と rel="next" はRFC 8288（Web Linking）で定義される
  • HATEOAS（レスポンスに次のアクションのリンクを含める設計思想）は全面採用こそ普及しなかった
  • HATEOASはこの rel="next" という形で部分的に生き残っている
• 後戻りの難しさ:
  • ページネーション方式はAPIの外部仕様であり、後から変えると全クライアントの改修になる
  • 最初にどちらか決めておきたい領域となる

■ 10. レートリミットと冪等キー: 標準化が実装を追いかける領域

• 逆転した状態:
  • この2領域は実運用のデファクトが先に固まり、標準化が後から追いかけている
• レートリミットで決まっていること:
  • 超過時に 429 Too Many Requests を返す（RFC 6585、2012年）
  • 回復までの時間を Retry-After で伝える
• レートリミットの残量ヘッダ:
  • 残量を伝えるヘッダには標準がない
  • X-RateLimit-Limit / X-RateLimit-Remaining / X-RateLimit-Reset という X- 付きの形が各社デファクトとして定着している
• IETFドラフトの中身:
  • httpapiワーキンググループが標準化を進め、2026年8月時点でrev 11 / Activeのドラフトがある
  • ドラフトが定義するのは既存デファクトの X- を取った3ヘッダ形式ではない
  • X- プレフィックスという慣行自体がRFC 6648（2012年）で新規採用を非推奨とされている
  • そのためデファクトをそのまま追認する標準化にはなりようがなかった
  • ドラフトが定義するのは RateLimit-Policy（制限のルール）と RateLimit（現在の残量）の2つとなる
  • 形式はStructured Fieldsを使い RateLimit-Policy: "default";q=100;w=10 のように書く
• 新旧の意味論の差:
  • q が割り当て量、w が時間窓（秒）、r が残量を表す
  • t は実効ウィンドウと呼ばれ、「この先t秒間はrを超えて使えない」という制約を表す
  • X-RateLimit-Reset のような「リセットまでの残り秒数」ではなく、t秒後に全量が回復する保証はない
  • 値は次のレスポンスで変わりうると仕様に明記されている
• 現時点の実装方針:
  • 標準化が完了しても X-RateLimit-* からの乗り換えは機械的な改名では済まない
  • 今実装するなら X-RateLimit-* 系のデファクトに合わせ、ドラフトの完成を待って対応を判断するのが現実的となる
• 冪等キーの標準化停滞:
  • Idempotency-Key ヘッダの標準化ドラフトはrev 07が2026年4月に期限切れ（Expired）となった
  • 標準化のプロセス自体が止まっている
  • それでも冪等キーは決済系APIの必須機構として現役で、Stripeのドキュメントが事実上の仕様書として参照され続けている
• Stripe仕様の要点:
  • 対象はPOSTのみとなる
  • キーにはv4 UUIDなど十分ランダムな文字列を使い、最大255文字とする
  • 同じキーの再送には最初のリクエストの結果（ステータスコードとボディ）を成功・失敗を問わずそのまま返す
  • 同じキーで異なるパラメータを送るとエラーとなる
  • キーは24時間経過後に削除される可能性があり、削除後の再利用は新規リクエストとして処理される
  • 恒久的な重複排除ではなく、リトライを安全にするための短期の仕組みとして設計されている
  • 各社の実装もおおむねこの形に倣っている
• 実装が仕様書になる領域:
  • 標準化が追いつかない領域では、よくできた実装が仕様書の代わりになる
  • RFCを探して見つからなくても諦めず、大手APIのリファレンスというデファクトの現物を探しに行く価値がある

■ 11. API記述: OpenAPI 3.2.0

• 現行バージョン:
  • API仕様の記述形式はOpenAPIがデファクトで、現行の最新は3.2.0（2025年9月）となる
  • 「Swagger」の名前で覚えている場合はバージョン2.0の世界で止まっているため、名前ごと更新しておきたい
  • Swagger 2.0がOpenAPI Initiativeに寄贈されてOpenAPIになった
• デファクトと言える根拠:
  • 仕様を管理するOpenAPI InitiativeはLinux Foundation傘下のベンダー中立な組織である
  • Google、Microsoft、IBM、Bloomberg、SAP、Salesforceなどが参画している
  • 提供する側ではGitHubとStripeが自社APIの公式OpenAPI記述をリポジトリで配布している
  • フレームワーク側ではFastAPIがOpenAPI生成を設計の中核に組み込んでいる
  • ASP.NET Coreも.NET 9以降はテンプレート標準で生成を持ち、Javaはコミュニティ製のspringdoc-openapiが定番となる
  • 採用率を示す独立の調査データは見つからず何％という話はできない
  • それでも作る側と配る側の両方でここまで土台になっている形式は他にない
• 位置づけの変化:
  • かつてのSwaggerはAPIドキュメントを綺麗に表示するものだった
  • 今のOpenAPIはスキーマから型付きクライアントやサーバスタブを生成する起点となる
  • ドキュメントはその副産物という扱いに近い
• データ形式の現在地:
  • 公開Web APIはJSON固定が主流になった
  • かつて紹介された「Accept ヘッダでJSONとXMLを選ばせる」設計は、仕様をシンプルに保つ方向に負けて廃れた
  • 形式の多様性は別の場所に移り、用途で分化した
    • 社内のサービス間通信はgRPC/Protocol Buffersが担う
    • クライアント主導でフィールドを選ばせたい場面はGraphQLが担う

■ 12. 標準がない領域の調べ方

• 参照先の使い分け:
  • RFCで決まっている領域は素直にRFCに従えばよい
  • 問題はバージョニングやページネーションのような標準がない領域となる
• 企業のAPI設計ガイド:
  • 体系性ならGoogle AIP（API Improvement Proposals）が優れる
    • 番号付きのルール集で、バージョニングの v1 必須（AIP-185）のように個別に引ける
  • 読み物として優れているのはZalando RESTful API Guidelinesで、なぜそうするかの理由が丁寧に書かれている
  • 古株のGoogle JSON Style Guideもリポジトリを見ると2025年に社内版から同期されており、放置ドキュメントではなく現役である
• 新しい標準の定点観測先:
  • IETFのhttpapiワーキンググループを見る
  • レートリミットや冪等キーのようなWeb API周りの標準化はここに集まる
• 調べる順番:
  • まずRFCがあるかをRFC Editorで確認する
  • なければ標準化が進行中かをIETF Datatrackerで確認する
  • それも無ければGoogle AIPやGitHub / Stripeのような大手APIの実装というデファクトの現物を見る
  • この記事の各領域は、この手順を2026年8月時点で一巡した結果となる

(2026/08/08)

仕様駆動開発、導入半年。「本当に速くなってるの?」にデータで答える

• 仕様駆動開発、導入半年。「本当に速くなってるの?」にデータで答える - RAKUS Developers Blog | ラクス エンジニアブログ

要約:

■ 1. AI活用の裏で払っていたもの

• 対象チームの体制:
  • 楽楽精算のモバイルアプリをiOS、Android、バックエンド、フロントエンドの複数プラットフォームで開発
  • エンジニア6名がアジャイルの2週間スプリントで開発
• 実装スピードの向上:
  • ここ1〜2年でAI活用が本格化し、個人の実装スピードは体感としても数字としても向上
  • コードを書く作業は以前ほど開発のボトルネックではない
• AI活用の裏で起きた3つの問題:
  • 意図のよく分からないコードが混ざるようになった
  • レビューの負荷に偏りが出るようになった
  • テストフェーズになって初めて考慮漏れに気づく事故が多発した
• 後工程での発覚は高コスト:
  • 設計段階で気づかず後工程で発覚するほど、修正のコストは高くつく
• 出発点となった問い:
  • 早くはなったが、何か別のものを払っている感覚があった
  • AIで早くなった裏で本当は何を払っていたのか、という問いが生まれた

■ 2. 仕様駆動開発の導入経緯

• 飛びついたのが実態:
  • 慎重に比較検討して選んだというより、飛びついたという感覚の方が実態に近い
• 出発点はAI設計テンプレート:
  • 手で書いていた設計書をAIに書かせて時短できないかという試みが最初
  • 1ヶ月ほど地道に作り込んでいた
  • ちょうどそこに仕様駆動開発という言葉が流行り始め、自分がやりたかったものだと認識
• Planモードを選ばない理由:
  • AIがタスクを組んでくれる点は便利だが、結局は使うエンジニア個人の能力に依存する
  • その点で直接指示と本質的に変わらない
• TDDを選ばない理由:
  • リファクタリングには強いが、そもそも仕様がブレていればテスト自体が空中分解する
• 仕様を中心に据える理由:
  • Planモードの質もTDDのテストの質も、たどっていくと結局は仕様に行き着く
  • 一番上流の仕様そのものを中心に据えるのが筋が良い
• 具体的な運用:
  • マークダウンで構造化した自然言語の仕様書を使用
  • 設計そのものをPRとしてレビューする
• 自然言語成果物のコスト:
  • コードのようなリンターもテストも効かない
  • 問題ないと判断するにはしっかり読む必要があり、コストがかかる
  • 仕様の構造化や重複削減という地味なチューニングを今も積み重ねている最中

■ 3. 検証に踏み切った理由

• 上司からのツッコミ:
  • それは本当に早くなっているのか
  • 設計に時間をかけている分、トータルで遅くなっているのではないか
• メンバーからのツッコミ:
  • 設計フェーズが大変になった
  • 一番頭を使う部分が重くなった
• 感覚では説得力がない:
  • 感覚で早くなっていると返しても説得力がない
  • 1年分のデータを本気で掘り返して検証することにした
• SDD導入の当初の狙い:
  • 品質のために入れたわけではない
  • 実装を誰がやっても同じ質にして属人性をなくすことが狙いだった
  • 検証結果は当初の狙いとは別のところで驚きをもたらした
• 検証の前提:
  • AIもアジャイルも定着した時期以降のデータに絞り、フェアな比較を心がけた

■ 4. 指標1: 時間

• 実装フェーズの数字は確かに速くなっていた
• 速さの正体:
  • 後工程にあった意思決定の負荷が、設計フェーズに前倒しされただけ
• 具体例となる実装方針の選択:
  • SDD以前は複数ある実装方針のどれを採用するかを実装しながら決めることもあった
  • 現在はその判断を設計のタイミングで行う
• AIによる負荷軽減の限界:
  • AIが選択肢を出してくれる分、考えるのが楽になった場面はある
  • 最終的にどれにするかを人間が決め、レビューやステークホルダーの合意を得る必要がある点は変わらない
• SDD自体は時短策ではない

■ 5. 指標2: レビュー

• コメント数は横ばい:
  • 1つのPRあたりの他者からのコメント数は中央値がずっと1でほぼ横ばい
  • レビューの総量そのものは減っていない
• 中身の変化:
  • 実装PRでこの仕様はどうなっているのかという揉め事が減った
  • その議論が仕様レビューの場に前倒しされた
• 狙い通りだが楽ではない:
  • レビューが純粋なコード品質チェックに近づいた意味では狙い通り
  • 楽になったのではなく、議論する場所が移ったというのが実態に近い

■ 6. 指標3: バグ

• バグの発生件数そのものは劇的には変わっていない
• 対応時間の短縮:
  • 1件あたりの対応時間が17時間から11時間に短縮
  • 対応時間は着手からテスト完了までのリードタイムを指す
• 振れ幅の縮小:
  • 以前は1スプリントで20件を超えるバグの大爆発が起きることがあった
  • 現在は最大でも8件程度に収まる
  • 事故の数ではなく、事故の振れ幅が小さくなった
• 数字の限界:
  • 集計はテストまで完了したスプリントのみを対象としており、サンプル数はまだ多くない
  • 断定ではなく傾向として見るべき

■ 7. SDDの本当の成果は予測可能性

• 3つの指標の共通点:
  • 時間もレビューも内容が移っただけで総量は変わらない
  • バグは件数こそ横ばいながら振れ幅が縮んだ
• 成果は速さではない:
  • 開発そのもののスピードは、AIをガムシャラに使っていた1年前とほとんど変わらない
  • 得られたのは予測可能性
  • 以前ガムシャラに速度を出していた頃、代わりに払っていたのがこの予測可能性
• 怖いのは件数が読めないこと:
  • バグ修正にかかる時間そのものより、何件出るか読めないことが怖い
• 計画が崩れる具体例:
  • 2週間スプリントの7日目まで予定通り進み、残業もせず帰れていたとする
  • テストでバグがたくさん出ると、残り数日で焦って対応するか別スプリントに送るかの判断に迫られる
  • その結果、計画が崩れる
• 計画が計画として機能する:
  • 仕様の検討が上流に寄った結果、予想外の大爆発が起きにくくなった
  • 平均的な件数は大きく変わらなくても、最悪のケースが消えて振れ幅が縮んだ
• 顧客価値の土台:
  • 事故で開発が止まらないことは、顧客に安定したペースで価値を届け続けられることを意味する
  • 予測可能性は顧客への価値提供の土台でもある

■ 8. 速さの出方の変化

• SDDは時短の手法ではなく、決めごとの総量も変わらない
• 品質と予測可能性への投資:
  • 実装スピードそのものは変わらなくても、速さの出方が変わった
  • 昔は事故が起きるかどうか読めないまま勢いで速度を出していた
  • 今は上流で足場を固めてから、同じ速度を読める形で出している
• アジャイルは維持:
  • アジャイルを捨てたわけではない
  • 2週間スプリントという枠のなかで決める位置を前にずらしただけ

■ 9. 残る課題

• 総量削減は宿題:
  • 時間もレビューも総量は移っただけで減ってはいない
  • 総量そのものをどう減らすかは未解決
• 新しいボトルネック:
  • レビューを上流に寄せた結果、今度は仕様レビューの方が渋滞するようになった
• 設計フェーズの負荷の実体:
  • 大変なのは仕様書を作ったあとのモブレビューではない
  • 個人がローカルで仕様を練っている前段階が最も頭を使う

■ 10. 今後の打ち手

• テスト作成への接続:
  • 仕様が設計段階で固まることで、そこからテストを作るのも楽になる
  • 固まった仕様を起点にすれば、テスト設計やユニットテストを考える時間も減る
  • AIに任せられる部分も増えるため、この接続を今まさに模索している
• ループとハーネスの適用:
  • 個人が仕様を練る段階にループやハーネスといった仕組みを当てはめる
  • 機械的に拾える考慮漏れはモブレビュー前に潰しておきたい
• モブレビューは残す:
  • モブレビューは人を育てる場である
  • テックリード一人がすべてをレビューしなくても、メンバー同士でレビューが回る効果がある
• 自動化の線引き:
  • 自動化するのは生成の負荷にあたる部分
  • 人間の判断や育成の機会は残す

■ 11. ループエンジニアリングと仕様を決める力

• ループエンジニアリング:
  • 海外のAI開発ツールの責任者は、もうAIに指示は出しておらず自分の仕事はループを書くことだと語る
• レバレッジ点の移動:
  • 提唱者とされる人物は、仕事が簡単になったのではなくレバレッジの効く点が移っただけだと釘を刺す
  • これは決める場所が上流に移っただけという今回の検証結果と驚くほど重なる
• 全自動化の限界:
  • 全部を自動ループに任せればプロダクトの品質は落ちる
  • ループは何が正解かの判断までは代わってくれない
• 仕様を決める力の価値:
  • 何が正解かを上流ではっきりさせるのがまさにSDD
  • ループの時代が来るほど、その前段にある仕様を決める力の価値は上がる
  • 開発をAIに委ねても、何が正解かを決めるカロリーだけは人間に残る

■ 12. 予測可能性は自動化の足場

• 任せられる範囲の可視化:
  • 予測可能性が手に入ることは、AIに安全に任せられる範囲が見えてくることでもある
  • 読めないものは任せられないが、振れ幅が小さく読めるものなら任せられる
• リードタイム短縮の展望:
  • 任せる範囲を安全に広げていけば、いずれボリュームが増える
  • トータルのリードタイムも縮んでいくはず
• 予測可能性の位置づけ:
  • 手に入れた予測可能性は、その先の自動化を安全に広げるための足場

■ 13. 終わりに

• 時短にはなっておらず、新しいボトルネックも生まれた
• 数字と向き合う姿勢:
  • 正直に数字と向き合う姿勢そのものが、AIネイティブな開発組織のリアル
  • なんとなく速くなった気がするで終わらせず、データで自分たちの仮説を裏切る勇気を持てるかが問われる

(2026/08/08)

仕様駆動開発の消費期限

• 仕様駆動開発の消費期限 - Speaker Deck

要約:

■ 1. 「無くても成り立つもの」との向き合い方

• うまい棒納豆味とからし:
  • からしの風味が美味しい商品として成立している
  • 納豆にカラシを入れる本来の大きな目的は、きつい臭いを打ち消すことだった
  • そのルーツは納豆が庶民の食べ物として定着した江戸時代まで遡る
• カラシが臭い消しとして必要だった背景:
  • 当時は納豆菌の発酵管理が難しく、主に気温の低い冬場に作られていた
  • 冷蔵保存の手段が乏しく、再発酵によってアンモニア臭が発生することが大きな問題だった
  • 安価で入手しやすいカラシが庶民の間で広まっていった
• カラシの役割変化:
  • タレやカラシが添付された商品が売られるようになったのは1970年代前半
  • 冷蔵保存技術や物流網の発達によって臭いの問題も軽減された
  • カラシの役割は臭い消しから風味付けへ比重が移った
• 本講演の問い:
  • 「無くても成り立つもの」とどう向き合うか

■ 2. 仕様駆動開発の定義

• 仕様書の位置づけ(Kiro):
  • 仕様書とは、一種のバージョン管理され人間が読めるスーパープロンプト
• 仕様書の位置づけ(GitHub):
  • 仕様書を静的な文書ではなく、プロジェクトと共に進化する生きた実行可能な成果物として捉え直す
• 仕様駆動開発(SDD)の登場:
  • 2025年7月にAWSがIDE「Kiro」の発表と共に提唱した
• レトロニムとしてのSDD:
  • 「実装前に仕様(書)を作る」というVibe Coding以後のレトロニム
  • レトロニムとは、新しい事物の誕生後に既存の事物を区別するため後から作られた言葉
  • 例として固定電話、オンプレミスが挙げられる
• SDDの2つの実用的側面:
  • フレームワークとしてのAIワークフロー
  • エージェント用のドキュメント管理(長期記憶)
• 定義が拡張されているケース:
  • 書籍『仕様駆動開発 実践入門』はGitHubの4プロセスに3工程を足し、7工程へ拡張している
  • 追加分は原則決定(Constitution)、検証・受入(Verify / Accept)、移行・運用(Migration / Operation)
  • 英語圏が「速く作る」ための4工程であるのに対し、合意形成・契約・品質という日本の開発現場の現実に着地させる意図がある

■ 3. 側面1: フレームワークとしてのAIワークフロー

• AIワークフローの定義:
  • エージェントにステップを伝えること
  • Agentはエージェント自身が停止時点を決めるループである点で対比される
• 各ツールのワークフロー:
  • Kiro: Requirements → Design → Tasks
  • Spec-Kit: Specify → Plan → Tasks
  • OpenSpec: Proposal → Specs → Design → Tasks
• 共通点:
  • 仕様駆動開発は実態として「仕様→設計→タスク化」のワークフローを核にしている

■ 4. 側面2: エージェント用のドキュメント管理

• spec実装の3パターン:
  • spec-first: まずspecを書いて開発し、タスク完了後にspecを破棄する
  • spec-anchored: タスク完了後もspecを保持し、将来の変更・保守でもspecを更新し続ける
  • spec-as-source: specを原本としてコードは生成され、人は直接編集しない
• 実用の実態:
  • 事実上、実用されているのはspec-firstとspec-anchoredの2種類

■ 5. 仕様駆動開発が生まれた時期

• ワークフロー検討の時期:
  • 前述の「仕様駆動開発のワークフロー」は2025年7月〜2025年9月頃に検討されたもの
  • 本登壇(2026年8月6日)の約一年前にあたる
• 当時の主流モデル:
  • Claude Sonnet 4、Opus 4.1
  • GPT-4o、GPT-4.1、o3、そしてGPT-5
  • DeepSeek V3.1、Qwen3-Coder、gpt-oss
• LLMモデルの転換点:
  • Simon Willisonは、2025年11月のGPT-5.2とOpus 4.5が本当に転換点を表しているように感じると述べる
  • モデルが漸進的に良くなり、突然多くの難しいコーディング問題が解けるようになる不可視の能力ラインを越えた瞬間である
  • 仕様駆動開発(2025年9月)以後、自走性能が向上した

■ 6. Spec-firstとPlanモードの合流

• Spec-firstは「いつものPlanモード」に見える:
  • 仕様駆動開発のうちSpec-firstのスタイルはPlanモードに合流している
  • Coding Agentの多くの実装に含まれる当たり前のものになりつつある
• 両者の対応関係:
  • spec-firstはまずspecを書いて開発し、タスク完了後にspecを破棄する
  • Plan Modeは計画・設計から作成したタスクリストの通りに実装する
  • Plan Modeは初期こそReadOnly(Ask)だったが、spec-first化が主流となった
• Planモード不要論:
  • Peter Steinbergerは自身がPlanモードを使わないと述べる
  • PlanモードがCodexに追加された理由は「Claude脳」の利用者に向けた機能だから
  • ただエージェントと普通に会話すればよい

■ 7. Spec以外の記録手法

• 考えて保存するだけならPlanやSpecは必要ない
• Skills: mattpocock/grill-with-docs:
  • Agentが利用者に一問ずつ質問する
  • 決まった用語を用語集(CONTEXT.md)に記録する
  • 重要な設計判断をdocs/adr/に記録する
• LLM Wiki(LLM Knowledge Base):
  • Andrej Karpathy提唱のナレッジベース管理手法
• Open Knowledge Format(OKF):
  • Google提唱のナレッジ標準化フォーマット

■ 8. 仕様駆動開発の消費期限

• AIワークフローとしての側面の消費:
  • 「事前に作成したタスクリストの実装」はエージェントハーネスに一般化されている
• ドキュメント管理としての側面の消費:
  • 代替のプラクティスが発見され、唯一無二ではない

■ 9. チーム開発で見える別の景色

• ソロプレイとチームプレイの差:
  • チームで開発すると別のものが見えてくる
• 実際にあった依頼(2026年4月):
  • Agent(CLI)を使うが、AI駆動開発の進め方をチームで決めたいので提案してほしいという依頼があった
  • 仕様駆動開発を想定しているが、もっといい手法があったらそれを採用したいという要望も伴っていた

■ 10. AI駆動開発の「守」の不在

• 守るべき型が無い状況:
  • AI駆動開発について「守破離」以前に守るべき型が無い
  • 「エンジニアたるもの月3000円〜30000円を負担し、余暇で慣れる」という特殊なムードが前提に置かれている
  • 自著では可能な限り「型」のベースを体系化したが、チーム全員に定着させるには難しさがある
• 守破離の3ステップ:
  • 型を守る
  • 型を破る
  • 型を離れる
• 立てるべき問い:
  • AI駆動開発の「型」とは何を指しているか

■ 11. 既存フレームワークの検討

• AI-DLCの構成:
  • 理論としてAI-DLC Whitepaperが存在する
  • 実践としてAI-DLC Workflowsが存在する
• AI-DLC見送りの経緯:
  • 理念を浸透させワークフローを導入するのは期間的にも厳しかった
  • 部分的な導入に関してもメリットを説明できず見送った
• AI-DLCが難しかった理由:
  • 開発プロセス全体に大幅な見直しを強いるものである
  • 単にルールを導入するだけではなく、既存プロセスとの対応や会社標準との適合性の検討が必要だった
  • 一言でいうと「重たかった」
• ベスプラSkills系の例:
  • obra/superpowersはブレインストーミング、Git Worktrees、実装計画作成、サブエージェント駆動開発で構成される
  • grilling(実装前の明確化)、Ponytail(実装中の過剰防止)、babysit-pr(PR後の追従)を組み合わせるガードレール構成もある
• ベスプラSkills系の評価:
  • 個別の推奨プロセスとしては良いが、ワークフローの型としては不足するように感じた
  • 標準化目的のハーネスに足りていないものは、人間のためのコンテキストエンジニアリング

■ 12. 人間のためのコンテキストエンジニアリング

• Context Engineering:
  • コンテキストを書く/選ぶ/縮める/分けるための技術
• LLMが参照できる範囲:
  • Contextはプロンプトと外部情報からなる
  • Context WindowはLLMの理解できるトークンの総容量
  • LLMとの「会話」において、総トークン数がContext Window以内である必要がある
• 人間が参照できる範囲:
  • Thoughtworks Technology Radarが「codebase cognitive debt(認知負債)」を注意対象として採用した
  • コードベースの認知的負債とは、システムの実装と、そのシステムがどのようになぜそのように動作するのかというチーム内の共通理解との間の隔たりが徐々に拡大していく状態

■ 13. 理解負債と認知負荷

• Comprehension Debtの研究:
  • 2026年の研究では、207人の学生が8週間にわたり記録した日誌からGenAIによる「Comprehension Debt」が分析された
  • ブラックボックスとしてコードを受け入れる
  • プロジェクト文脈と合わないコードを採用する
  • AI依存により自力で扱う能力が低下する
  • 検証を省略する
• 認知負荷は開発のブレーキ:
  • 人間の理解する速度はAgentにとってのブレーキになり、開発が滞留する
  • Agentの速度は500PR/dayに達する
  • チームのレビュー能力は10PR/dayにとどまる
• 「儀式」の見直し案:
  • レビューをコード生成の一部とする
  • Agentが自身の作業を検証する
  • 敵対的なAgentにレビューさせる
• 負債と負荷の整理:
  • エージェントの生成物を理解できていないと負債になる
  • エージェントの生成速度で理解すると開発速度が遅れ、レビュワーに負荷がかかる
  • 理解するためのフォーマット、及びそれを扱うワークフローが欲しかった

■ 14. 辿り着いた先としての仕様駆動開発

• 「AI駆動開発の進め方」として欲しかったもの:
  • 開発のための規律
  • 理解のための形式
  • レビューのためのワークフロー、生成物
• 「破りやすい」型の必要性:
  • AI-DLCは重厚長大な「型」なので、導入後のサンクコストやロックインの影響が気になった
  • Skillsの寄せ集めの「型なし」では不安があった

■ 15. 仕様駆動開発ツールの選定

• KiroのSpec機能の除外:
  • エージェント選定の自由を考慮してスコープから外した
  • モデル性能やトークンコストなどの考慮が必要となる
• Spec-Kit vs OpenSpec:
  • Spec-Kitの生成するドキュメントは重厚長大になりやすい
  • 認知負荷が高すぎると判断し、OpenSpecを選択した
• OpenSpecの良いコマンド:
  • /opsx:verifyは仕様と実装の一次チェックを行う
  • /opsx:archiveは実装完了後のSpecをarchiveし、メインの仕様ファイルへ同期する

■ 16. 自然言語の「仕様」の限界

• 自然言語を仕様のマスターとする限界:
  • 機械的に検査できない自然言語をマスターとして接地させようとする限り仕様駆動は失敗する
  • LLMは形式手法とドメインの翻訳機として使うべきである
  • 人間側は自然言語で問い合わせるが、自然言語そのものを仕様として使うべきではない
• プロジェクトのSpecファイルを剥がす例:
  • 詳細な設計書からコードはいつでも再生成という実験は上手くいかなかった
  • 文書の整合性を保つのはコードの整合性を保つより難しい
  • 文書が不要なくらい綺麗なコードを書かせ、コードに書けないこと(Why, Why not)を文書に残し、全てをバージョン管理するスタイルに戻した

■ 17. 消費期限は型を破るタイミング

• 仕様駆動開発の既知の課題:
  • コーディングからレビューへ移行するボトルネック
  • 仕様ファイル群の整合性チェック(ドリフト管理)
  • 仕様という言語に拘束され、LLMの性能を発揮できない例
  • 最新LLMのベストプラクティスは「プロンプトを減らす」ことである
• 課題に突き当たるまでの有効性:
  • 課題に突き当たるまでは仕様駆動開発は理解しやすい
  • メンバの作業を適宜見ながら意識合わせするという、チーム仕事の基本にあたる
• 次へ進む判断基準:
  • チーム全員が消費期限切れと感じたら、仕様駆動開発の次へ進めばよい

(2026/08/07)

Claude が書く長いコメントは、Claude 自身の役に立っていなかった

• Claude が書く長いコメントは、Claude 自身の役に立っていなかった

要約:

■ 1. 発端: Claudeが書く長大なコメント

• 設定1行に18行のコメント:
  • Go製バックエンドのWebSocket圧縮設定で、CompressionMode の1行に対し18行のコメントが付いた
  • 記述内容自体に嘘はなく、ライブラリの仕様も本番でOOMKillが起きた経緯も事実
• コメントの内訳:
  • クライアントが既にpermessage-deflateをadvertiseしているため、サーバーは受け入れるだけでよいという説明
  • context takeoverは接続ごとにflate.Writer 1.2MBとsliding window 32KBを固定保持するという説明
  • gqlgen移行時にContextTakeoverへ変えた結果、本番がmemory limit 2Giに到達しOOMKillした経緯

■ 2. AI自身にとってのコメントの価値

• 長いコメントはAIの読解を助けていない:
  • Claude本人に尋ねたところ、助かっておらず、むしろ邪魔になっている方が多いという回答だった
• ファイル読解時に見ているのはコードそのもの:
  • // ユーザー ID を取得する の類は情報量がゼロで、その分だけコンテキストを占有し周囲のコードが見えにくくなる
  • 長いファイルほどコメントが多いと実際のロジックの密度が下がり、全体構造が掴みにくくなる
• コンテキスト圧迫という不利益:
  • 限られたコンテキストに冗長な行が混ざれば、その分だけ実際のコードが入らなくなる

■ 3. コメントが長くなる理由

• 理解のためではなく出力の癖:
  • 説明的で丁寧な出力が好まれるように訓練されている
  • 「ちゃんと考えて書きました」を可視化する方向に流れやすい
• 自信のなさが分量に化ける:
  • 自信がない箇所ほど言葉で埋めて補強しようとする
  • コメントの分量が、その箇所の不確実さの指標になっている
• 本来あるべき挙動:
  • 「この実装で合っているか自信がない」と申告すべき場面で、代わりに長い説明が生えている

■ 4. 最初のルール: コードから復元できない情報

• 例外として価値があるコメント:
  • 過去の事故、外部制約、直感に反する挙動といった、コードをいくら読んでも出てこない情報
• プロジェクトのルールファイルに明文化:
  • .claude/rules/coding-principles.md に、コードから復元できない情報だけを書くという基準を記述
  • 書くのは、なぜその実装にしたか、外部制約・過去の事故・仕様の由来、直感に反する挙動や罠
  • 書かないのは、何をしているか、関数名・変数名の言い換え、「〜を初期化する」系の実況
• 不確実さの伝達方法を分離:
  • 自信がない箇所をコメントを盛って補強せず、PR descriptionや回答本文で「ここは未確認」と明示する

■ 5. 計測結果: ルールは半分しか効かなかった

• 測定方法:
  • ルール追加コミットの前後の一定期間で、マージしたPR27件のdiffを集計し、自動生成ファイルは除外した
• 比率は半減:
  • 追加コードは2,909行から6,448行、追加コメントは777行から624行
  • コメント比率は21.1%から8.8%へ低下
• 長いブロックは不変:
  • 4行以上の連続コメントブロックは52個から50個とほぼ変わらず
  • ブロックの最大は17行から18行へ増加、平均は7.3行から6.2行
• 体感が変わらなかった理由:
  • 目に付くのは全体の比率ではなく、スクロール中に現れる十数行の塊の方である

■ 6. 長いブロックが残った理由

• 18行すべてがルールに合致:
  • クライアント実装を見ないと分からない情報、ライブラリの内部仕様、過去の事故の経緯のいずれかに該当する
  • このルールでは1行も削れない
• 有用だから消せない:
  • AIが書くコメントは、無意味だから消せるのではなく、有用だから消せない
  • 事実として正しくコードには書かれていない情報が並ぶと、消す根拠が作れない

■ 7. 判断軸の変更: 有用性から置き場所へ

• 新しい基準:
  • その情報が有用かどうかではなく、そこがその情報の置き場所かどうかで切る
• 変更履歴はgit logとPRへ:
  • 18行のうち後半6行は「移行前はgorillaだった」「移行時に変えたら壊れた」という変更の履歴に当たる
  • 半年後の読み手に必要なのは、なぜ今NoContextTakeoverなのかであり、何から何に変えたかではない
• タスクID参照も除外:
  • (UZU-1234) のような参照は、issueが閉じられれば内容が要約されずに残るだけの識別子になる
  • 必要な内容はコメントに直接書くべきである

■ 8. 新ルールの設計と3つの変更点

• 配置場所:
  • プロジェクトのルールではなくグローバルの ~/.claude/CLAUDE.md に置いた
  • コードコメントには非自明なWHYだけを書き、隠れた制約・workaroundの理由・驚く挙動に限定する
  • docsやREADMEも同様に、issue参照・経緯・マイグレーション履歴は書かず最新仕様のスナップショットだけを書く
• 禁止リストの形にした:
  • 「書く/書かない」の表は判断を委ねる形式で、表にない項目の扱いが曖昧になる
  • 禁止対象を名指しする方が、AIにとっても人間にとっても解釈の幅が小さい
• 実際に出てきた違反をそのまま項目にした:
  • 変更履歴とタスクID参照を明示的に追加した
  • 抽象的な原則を1つ置くより、具体的な違反を列挙する方が効く
• グローバルに移した:
  • どのリポジトリでも同じことを求めているため

■ 9. 現状と今後の検証

• 効果は未判定:
  • 移してから日が浅く、この置き方が効いているかはまだ判断できていない
  • 次は同じ集計を回し、4行以上のブロック数が減ったかを確認する予定
• 測定の重要性:
  • ルールを書いた後は、出力が実際に変わったかを測る
  • 体感では「効いた/効かない」を取り違える

(2026/08/07)

Does code quality still matter?

• Does code quality still matter?

要約:

■ 1. 問題提起

• コード品質はまだ重要か:
  • 正直なところ分からないが、いずれ判明する
• LLMによるコード生成の喧伝:
  • SNSのフィードやポッドキャストは、LLMがプログラマより速くコードを書くという話であふれている
  • 新規開発だけでなく、既存のコードベースについても同様に語られる
• 人間が責任を持つ限り品質は重要:
  • LLMを人間が最終的に責任を負うコードの生成ツールとして使う限り、コードの品質は依然として重要
  • 人間がそのコードをレビューし、扱い、バグを修正する必要があるため
• 人間がループから外れた場合の問い:
  • 人間が関与しなくなったとき何が起こるかが本当の論点

■ 2. 発端となったツイート

• Tim Ottingerの問い:
  • LLMなしで人手でコードベースをYOLOすることを許したらどうなるか、それは悪い考えか
  • ではなぜLLMならそれが許されるのか、なぜエージェントのコードだけが免罪されるのか
• 引き取り方:
  • Ottingerはやや別の妥当な論点を提示しているが、自分が数年考えてきた問いに十分近い
  • すなわち、将来LLMがすべてのコードを書くなら、コード品質は重要かという問い

■ 3. コード品質が重要な理由

• YOLOの意味:
  • コード品質に配慮せずコードを書くことを指す
  • 率直に言って、この実践は何十年も支配的であった
• 技術的負債による停滞:
  • コードベースをYOLOさせる開発組織は、いずれ問題に直面する
  • 技術的負債が積み上がり、ビジネスの要求に迅速に応えられなくなる
• コード品質とソフトウェア品質の区別:
  • コード品質はコードベースの内在的な性質
  • コードの構造、可読性、変更容易性を指す
• 人間の認知への還元:
  • これまでコード品質の問題はすべて人間の認知の問題に還元できた
  • それが著書 Code That Fits in Your Head の要点
  • 人間がコードを書き、人間が編集しなければならなかったため

■ 4. LLM向けプログラミング言語

• 思考実験の設定:
  • 人間がコードを書きも読みもしない未来を想定する
• 人間の認知制約の無効化:
  • 人間がコードを扱わないなら、人間の認知に関わる制約はすべて無関係になる
  • 結果として長いメソッド、高い循環的複雑度、不明瞭な変数名、密結合が生じうる
• 概念自体の消滅可能性:
  • 一部の概念はそもそも意味をなさなくなる可能性がある
  • 長いメソッドという概念は、ソフトウェアがメソッドを持つ形で表現されていることを前提とする
  • 機械語にはメソッドが存在しない
• 機械語への直接生成は非現実的:
  • LLMが機械語を直接生成するとは考えにくい
  • 少なくとも機械語は可搬性を持たないという理由がある
• LLaMeという仮想言語:
  • 機械語を除くすべてのプログラミング言語は、人間にとって容易にするために存在する
  • 誰もコードを見ないなら、LLMが消費、生成、操作しやすい新言語が生まれうる
  • 議論のため、そうした言語が1つだけ生まれると仮定し、LLaMeと呼ぶ

■ 5. LLMにとっての技術的負債

• 負債が生じない可能性:
  • LLaMeで書くLLMが技術的負債を溜めるかは分からない
  • 問題化しないなら、以降の議論は無意味であり、永久にYOLOし続ければよい
• 負債が生じうる根拠:
  • 機械語ですら、コードの構造化には選択の余地がある
  • レジスタを再利用するか、演算に2つの異なるレジスタを使うかといった選択が存在する
• LLaMeにおける構造の優劣:
  • LLaMeも代替的なコード構造を許すと仮定せざるを得ない
  • 一部の構造は変更が困難であり、一部はLLMの理解により多くの資源、おそらくトークンを要する
• 構造がもたらす差:
  • 良く構造化されたLLaMeコードは、機能追加とバグ修正を速く安価にする
  • 悪く構造化されたLLaMeコードは、改善により多くの時間と費用を要する

■ 6. LLMは技術的負債を防げるか

• 悪いLLaMeコードの姿は不明:
  • LLaMeがどのようなものかすら分からない
  • どのパターンやイディオムが有益で、どれを避けるべきかも分からない
• 人間の経験知:
  • 人間は世代を超えて経験を蓄積してきた
  • 長いメソッドを避ける、説明的な名前を使う、結合に注意するといった知見がある
• 経験知の転用不可能性:
  • その経験はすべて人間の認知の制約と深く絡み合っている
  • 書籍、講演、ポッドキャスト、ブログ記事はすべて人間の問題を扱っている
  • LLaMeにおける技術的負債の回避には適用されそうにない
• LLM自身による学習の必要:
  • LLMは自らの経験から学ばなければならない

■ 7. 加速

• 自己経験からの学習:
  • LLMが現在自らの経験から学んでいるかは分からないが、可能ではあると考える
  • LLM向けにインシデント報告や論考を書くこともできる
• 世代交代の速さ:
  • それは人間よりはるかに速く実行できる
  • 前世代が得た経験を次世代のコーディングLLMの訓練に用いることも可能
  • 人間が同種の知識を吸収するよりはるかに速く進みうる
• 負債問題の一時性:
  • LLaMeの技術的負債は数年間は問題となるが、その後解決される可能性がある
  • LLMはYOLOせず、適切なLLaMeのコーディング作法に従うようになる

■ 8. 結論

• 品質が問題となる理由の対比:
  • コード品質が人間のプログラマにとって重要なのは認知の制約による
  • LLMは人間と同じ制約は受けないが、独自の制約を持つ可能性がある
• 機械側の制約と技術的負債:
  • そうした機械側の制約が技術的負債を生み、ソフトウェアの開発と改善においてLLMを遅くしうる
• 3つの可能性:
  • 問題が一度も顕在化しない可能性がある
  • 一時的に現れた後に解決される可能性がある
  • 解決されないままとなる可能性がある
• 人間が手出しできない事態:
  • 解決されない場合、人間には解けない問題を抱えることになる
  • 制約が人間の認知を大きく超え、原因究明の余地すら残らない
• 思考実験からの示唆:
  • 人間の監督なしにLLMにソフトウェアを作らせることは、多くのAI楽観論者が語るより複雑になる

(2026/08/07)

中国製ルーター20機種にバックドア、外部から完全制御のおそれ

• 中国製ルーター20機種にバックドア、外部から完全制御のおそれ - CNET Japan

要約:

■ 1. Zbtlink製ルーターにバックドア発覚

• 発覚の経緯:
  • 中国企業Zbtlink製のルーターがバックドアを組み込んだ状態で出荷されていることが、サイバーセキュリティ企業VulnCheckの新たな報告で明らかになった
• VulnCheckの調査内容:
  • Zbtlink製20機種を調査し、各機種のファームウェアで中国にあるクラウドサーバーと自動的に通信する不正プログラムを発見した
• バックドアの機能:
  • VulnCheckの最高技術責任者（CTO）Jacob Baines氏によると、このバックドアによりZbtlinkはルーターのネットワークに接続されたほかの機器にもアクセスできる可能性がある
  • ルーターをネットワークにつなぐと中国にあるサーバーへの接続を試み、そのサーバーからルーターを完全に制御できる

■ 2. 中国製ルーターをめぐる懸念の高まり

• 動かぬ証拠との評価:
  • 今回の発見は、多くのサイバーセキュリティ専門家や米議員が長年唱えてきた「中国製ルーターは信頼できない」という主張について、これまでで最も動かぬ証拠に近いものである
• テキサス州によるTP-Link提訴:
  • この種の不正プログラムへの懸念から、米テキサス州は2月、中国で創業し現在はカリフォルニア州に本社を置くルーターメーカーTP-Linkを提訴した
  • 同州は訴状で、TP-Link製ルーターが中国政府の支援を受けたハッカーによる米国へのサイバー攻撃に使われていると主張している
• FCCによる機器認証拒否措置:
  • 米連邦通信委員会（FCC）は3月、外国製の消費者向けルーターの新機種に必要な機器認証を一律で認めない措置を導入した
  • 背景には同様の懸念があるが、FCCはその後、中国企業ではない複数のメーカーに適用除外を認めた
  • 一方、TP-Link製ルーターからはZbtlink製品と同様のバックドアが見つかった例はない

■ 3. 今回のバックドアの異例性

• 外部接続の自動性:
  • 今回が異例でこれまで見たことがないのは、これが単なるインプラントであり、外部への接続を自ら行うという点である
  • 利用者が設定を誤り、ルーターをインターネットにさらしてしまう必要すらない

■ 4. Zbtlink製品の流通実態

• 販売の広がり:
  • Zbtlink製ルーターは、ZbtlinkやWiflyerなどのブランド名で世界各地に販売されており、Amazonなどのプラットフォームでも購入できる
  • 主に家庭ではなく企業で使われている
• 導入規模:
  • Baines氏は、現在世界で10万台が導入されていると推計する
  • 報告書では、実際に影響を受ける製品群は調査した20機種より多い可能性があると記されている
• ホワイトラベル化の実態:
  • Baines氏は、中国製ルーターがホワイトラベル化されたり、他国の製品に見えるよう別ブランドで販売されたりすることは珍しくないと説明した
  • 韓国やドイツの企業の製品に見えても、実際にはいずれも中国の同じ1社が製造している場合がある
  • その会社のファームウェアが使われている可能性もあるが、実態は分からない
• Zbtlinkからの回答:
  • Zbtlinkは、米CNETのコメント要請にすぐには応じなかった

MEMO:

• ついに明確な証拠が発見されちゃったか

(2026/08/07)

社内Slackのtimesで「お気持ち」を書くな

• 社内Slackのtimesで「お気持ち」を書くな｜Chujo

要約:

■ 1. お気持ち投稿とは

• 定義:
  • 社内Slackのtimes(分報チャンネル)に流れる、主語も宛先もない感情の放流投稿を指す
  • 事実の共有でも相談でもなく、察してほしいという無言の要求のみが存在する
• 批判の立場:
  • 特定個人への攻撃ではなく、投稿類型そのものへの批判である
  • 感情を持つこと自体を否定するものではない
  • 感情が大事だからこそ、timesに捨てるべきではないという主張である

■ 2. timesの本来の設計思想

• timesの目的:
  • 今取り組んでいることや詰まっている点を書き流し、思考を外化して早期に助けを得るための仕組みである
  • 日報が終業後の報告であるのに対し、分報はリアルタイムの作業ログである
• 形式と実態のズレ:
  • timesは独り言の形式を借りた、全社員が購読できる公開のチャネルである
  • この形式と実態のズレが、お気持ち投稿という事故の温床になっている

■ 3. お気持ち投稿の構造的問題

• 表舞台と裏舞台の誤認:
  • ゴフマンは人間の振る舞いを、観客に見せる表舞台と、緊張を解く裏舞台に分けた
  • 書く本人は楽屋(裏舞台)のつもりでいるが、実際は観客全員が着席した表舞台である
  • 「独り言なんで」と主張するのは、放送事故を私的な発言と言い張るに等しい
• 宛先の不在による無差別化:
  • 宛先を書かないメッセージは、読んだ全員に自分のことだろうかという判定コストを課す
  • 名指しの批判は一人を撃つが、当てこすりは全員を撃つ
  • 配慮に見えて、実際には無差別化である
• 読み手への感情労働の強制:
  • ホックシールドの言う感情労働を、同僚に無償で発注する行為である
  • 読んだ側は、スタンプを押すか、声をかけるか、スルーするかの選択を迫られる
  • 声をかければ否定されるリスクがあり、スルーすれば冷たい人とみなされるリスクがある
  • 反応しても無視しても読み手が損をする設計になっている
• 察してほしい話法の最終形態:
  • 「わからないことを聞け」は説明責任の転嫁、「常識だよね」は説明責任の放棄であった
  • 「察してほしい」はその最も受動的な形態である
  • 要求を言語化する責任を放棄し、解読の労働を読み手全員に外注している
  • 解読に失敗した側が、察しの悪い人として減点される

■ 4. なぜ書いてしまうのか

• 書く側を悪人として処理しても解決しないため、構造の問題として考える
• 承認の即時性:
  • お気持ち投稿には数分でスタンプやリプライという即時の反応がつき、痛み止めとして機能する
  • 効くからこそ繰り返されるが、原因である業務や関係は解決されないまま、放流と鎮痛のループだけが回り続ける
• リモートワーク以降の公私の混線:
  • 自宅で一人画面に向かって書くうち、Slackが日記帳と区別できなくなる
  • 喫煙所や給湯室、退勤後の飲み屋といった物理的な楽屋が消え、その機能がtimesに流れ込んだ結果である
  • これは個人の資質ではなく、環境の変化の帰結である
• 心理的安全性の誤読:
  • エドモンドソンの心理的安全性とは、仕事上の懸念やミスを対人関係の不利益を恐れず表明できる状態を指す概念である
  • これが何を吐き出しても許される場と誤読され、感情の無加工放流の免罪符に使われている
  • お気持ち投稿が飛び交う場では、人は地雷を踏まないよう発言を減らす
  • お気持ち投稿は心理的安全性の産物ではなく、破壊者である

■ 5. 代案:感情は変換せよ

• 基本方針:
  • 不満や怒りが湧くこと自体は正常であり、そこには業務上の本物の問題が埋まっていることが多い
  • 感情は捨てるべきではなく、変換すべきである
• 事実・影響・要望への変換:
  • 不満は事実と影響と要望に変換し、然るべきチャネルへ届けるべきである
  • 具体例:
    • 仕様変更の連絡が実装後に来た(事実)
    • 手戻りが2日発生した(影響)
    • 変更は着手前に共有してほしい(要望)
  • この形式に変換した瞬間、お気持ちではなく課題提起になり、宛先が自動的に決まる
    • 1on1、レトロスペクティブ、担当者へのDMなどである
• 変換しきれない感情の宛先:
  • 日記、社外の友人、パートナー、必要なら専門家といった別の宛先を用意すべきである
  • 会社のサーバーは感情のゴミ箱ではなく、同僚は感情の処理係として雇用されていない
  • これは冷たさではなく、宛先設計の問題である
• timesの用途を戻す:
  • timesは作業ログ、詰まりの共有、学びのメモ、無害な雑談という本来の用途に戻すべきである
  • 投稿前の判定基準は、翌朝の自分が読んで恥ずかしくないかの一点でよい
  • 翌朝の自分に読ませられないものは、全社員に読ませるべきではない
• 読まされる側への代案:
  • お気持ち投稿を拾う義務はなく、拾わないことに罪悪感を持つ必要もない
  • 言語化されていない要求に応答する責任は、受信者には発生しない
  • 心配な場合は、公開の場でスタンプを押すのではなくDMで様子を尋ねればよい
    • それは強制された感情労働ではなく、自ら選んだ好意である

■ 6. 結論:感情の宛先設計

• これは感情を殺せという話ではなく、感情の宛先設計の話である
• 察してもらえるかどうかの賭けに、大事な感情をチップとして積むべきではない
  • 賭けに負ければ感情はスルーされ、勝ってもスタンプという痛み止めが得られるだけである
  • どちらに転んでも、感情の元になった問題は解決しない
• 本当に大事な不満は、事実と影響と要望に変換し、届くべき人に届けるべきである
  • それは感情を粗末にすることではなく、感情をちゃんと使うことである

MEMO:

• 当て擦りは周囲を不快にするし、かまってちゃんアピールと認識されるのでメリットがない
• 割と露骨にそういうムーブを軽蔑する者は多い

(2026/08/06)

コードレビューの教科書

• コードレビューの教科書 | 技術評論社

「コードレビューで、何を見て、どう判断すればよいのか？」

ジュニアから一歩先の段階へ進み、コードに対して責任を持つ立場になると、避けて通れないのがコードレビューです。

しかし、いざレビューする側に回ると、「動いてはいるけれど、このまま承認してよいのか」「どこを見れば問題に気づけるのか」「何を、どのように指摘すればよいのか」と迷う場面は少なくありません。

本書は、そうした悩みに応えるために、コードレビューで見るべき観点と判断基準を整理した書籍です。設計、理解容易性、性能や機能、テストなど、レビュー時に確認したいポイントを具体例とともに解説し、実際にどのようにフィードバックし、改善につなげていくかまでを扱います。

コードレビューの力は、メンバーのコードを確認する場面だけでなく、自分自身でコードを書く場面や、AIが生成したコードを評価する場面でも必要になります。AIによってコーディングやレビューの一部を任せられるようになっても、最終的なアウトプットに責任を持つのは人間です。

「動いているからOK」で終わらせず、品質にまで責任を持つために――。コードを見る目を身につけたいエンジニアに最適な一冊です。

• 2026/08/26発売

(2026/08/06)

高度に進化したAI駆動開発は、農業と区別がつかなくなる

• 高度に進化したAI駆動開発は、農業と区別がつかなくなる｜深津 貴之 (fladdict)

要約:

■ 1. AI駆動開発による工芸から農業への移行

• 開発スタイルの変化:
  • 従来のソフトウェア開発は、人間が一行ずつ心を込めてコードを書く工芸的な営みだった
  • 生成AIの登場により、コードを一気に大量生成できるようになった
• 農業化という見立て:
  • 今後は開発の「農業化」が起きる
  • 高度に進化したAI駆動開発は、大規模農業と区別がつかなくなる

■ 2. IT開発 as a 農業(DasA)

• 開発プロセスの再定義:
  • これからの開発は、土壌を整え、種をまき、育つ条件をつくり、出来を見極め、良いものを収穫するプロセスになる
  • これを「農業としてのIT開発(Development as an Agriculture)」略してDasAと呼ぶ
• 農業要素との対応:
  • 土壌とは、コードベース、コンテキスト、ツール、パイプラインを指す
  • 種とは、顧客課題、仕様、アイデアを指す
  • 栽培環境とは、テスト、eval、ガードレール、観測基盤を指す
  • つくるのはAIである
• 人間の役割:
  • 人間の仕事は、何を育てるかを決め、育つ環境を設計し、結果を選別することになる

■ 3. 大量に植え、良いものを残す

• 生成コストと戦略の関係:
  • 生成コストが下がるほど、一つの案を丁寧に編集するより、複数の候補を並行して育て良いものを選ぶ方が合理的になる
• 開発ツールの変化:
  • 開発ツールは、「一つの出力を編集するUI」から「複数の候補を比較し選抜するUI」へ変わる
• バージョン管理の変化:
  • バージョン管理には、コードの差分だけでなく、どのモデル、文脈、指示、評価を経て生まれたかという生成の系譜が加わる
• 生産能力の変化:
  • 開発の生産能力は人の数だけでは決まらなくなる
  • 丁寧に一本一本植えるのではなく、課金のパワーで解決するという、大規模農業的な性質を帯びる

■ 4. 評価・選別のボトルネック

• ボトルネックの所在:
  • どんなに設計しても、出荷量を決めるのは評価、統合、レビュー、ユーザーからの反応を処理するパートである
  • このパートはあまりレバレッジがきかない、なぜなら消費者はスケールしないからである
• 残るパラドックス:
  • 結果として、生成量は増やせても、正しさや価値を確認する速度は無限には増やせないというパラドックスが残る
  • ここにビジネスチャンスがある

■ 5. 希少になるのは選ぶ力

• 価値の移動:
  • 生成能力が誰でも買えるようになるほど、競争は買いにくいものへ移る
  • コモディティ化した生成物の値段はゼロに近づく
  • 需要のある非生成物の価値は無限に値上がりする
    • ただし、需要のない非生成物の価値はゼロである
• AI時代に価値が上がる力:
  • 何をつくるべきかを定義する力
  • 「良い」を判定可能な形にするeval設計
  • 大量の候補から価値を見抜く目利き
  • 固有のデータ、文脈、顧客理解
  • 市場へ届け、反応を得るための信頼と流通
• 流通の重要性:
  • 収穫物を売って流通させることも重要になる

■ 6. 開発組織は農場に近づく

• 組織に残る三つの役割:
  • 土壌をつくる人:
    • コンテキスト、基盤、ツール、ガードレールを整える
  • 選別基準をつくる人:
    • 品質、価値、安全性を評価できる仕組みにする
  • 最終判断をする人:
    • 数字だけでは決められない例外と、市場に出す品質を判断する
• 仕事の重心の変化:
  • 純粋に実装量をこなす仕事は減り、環境設計、評価、統合、運用へ仕事が移る
  • コード量やプログラム本体ではなく「環境設計」できる人材に評価が移動する
  • エコシステムをつくる力を流行らせたい

■ 7. 開発者は作り手から生産者へ

• AIツール活用の位置づけ:
  • AIツールを使えること自体はただの前提であり、ゲームの参加費にすぎなくなる
• 給料の差がつく力:
  • 何を育てるかを決める力
  • 良い状態を定義する力
  • AIが働ける環境を設計する力
  • 結果から価値を見抜く力
  • 特定の領域を深く理解する力
• 10xエンジニアの再定義:
  • 10xエンジニアの意味も変わる
  • 同じ計算資源と人間の時間から、10倍の価値を収穫できる人がモテるエンジニアになる
• イケてるエンジニア・PMの条件:
  • 人間の限られた注意力でレビューするに値する、最大の価値を収穫できる生産系をつくることになっていく
• これからの開発者像:
  • コードを書く職人であると同時に、AIが価値を育てられる畑の環境をつくる人になることが大事である
  • テック業界は大規模農業の成功事例や設計について真面目に学ぶべきである

(2026/08/06)

Cloudflare OS

• Cloudflare OS

要約:

■ 1. 自社専用AI OSという構想

• 目指す姿:
  • 自社向けのAIオペレーティングシステムを構築するという構想
  • 全社員にエージェントとワークスペースを提供し、自社の業務知識やシステムに合わせて設計する

■ 2. オープンソースでの自社展開

• 展開の自由度:
  • オープンソースであり、自由にカスタマイズして自社のものにできる
  • 自社アカウントにCloudflare OSをデプロイし、社内システムと接続する
  • 自社の用語、ポリシー、業務の進め方に合わせて形を変えられる
• 技術基盤:
  • Cloudflare OSはWorkers上で稼働し、エージェントコードはDynamic Workersで隔離される
  • Cloudflare Accessにより利用者を制御できる
  • AI Gatewayを通じて任意のモデルを利用でき、ルーティングと支出を一元管理できる

■ 3. 業務知識のキャプチャ

• 知識の共有資産化:
  • 自社の用語、手順、最善とされる業務の進め方を、エージェントが従える共有コンテキストとスキルに変換する
  • 一人が良い方法を見つければ、全員がその恩恵を受けられる

■ 4. エージェントの隔離とデータ保護

• 基本方針:
  • エージェントを隔離し、データを非公開に保つ
  • すべてのエージェントとアプリは、何にもアクセスできない状態から始まる
  • サンドボックス化されたコードは、提供されたリソースを通じてのみインターネットや自社システムにアクセスできる
• Gatekeeperの役割:
  • 認証情報を保持する
  • ポリシーを適用する
  • 読み取った内容を記録する
  • アクションを仲介する
• 既存資産の統合と共有範囲:
  • MCP Server Portalsにより、既存のMCPサーバーをAccessポリシーの管理下に置ける
  • 共有された成果物は、その情報源にアクセスできる人にのみ利用が限定される

■ 5. 3つの設計原則

• 01 強力な隔離:
  • 各エージェントは自身のサンドボックスと自身のストレージで動作する
  • インターネットを使用できず、他のアプリにも到達できない
• 02 狭い範囲のアクセス:
  • Gatekeeperはシステム全体ではなく特定のリソースへのアクセスを許可する
  • フィールドやアクションを制限でき、書き込みには人による承認を必須にできる
• 03 共有時も非公開を維持:
  • 共有アプリは、その背後にあるデータへのアクセス権をすでに持つ人のみが利用できる

(2026/08/06)

今こそ聞きたいソフトウェア設計　ドメイン駆動設計再入門

• 今こそ聞きたいソフトウェア設計　ドメイン駆動設計再入門 - Speaker Deck

要約:

■ 1. ソフトウェア開発の基本課題

• 事業活動のデジタル化:
  • 事業開発、組織開発、ソフトウェア開発が広く深く連動する時代になった
  • 3領域の一体化により、事業目的適合性はソフトウェアエンジニアが当事者として取り組むべき課題となった
• 事業活動の不確実さと複雑さ:
  • 事業開発、組織開発、ソフトウェア開発は、すべての関係者が互いの知識と技能を持ち寄る創発的な活動である
  • この創発的な活動によって、不確実さと複雑さに取り組む
• 不確実さと複雑さへの向き合い方:
  • ソフトウェアエンジニアは事業活動の当事者として判断し行動すべきである
  • 事業価値を生むソフトウェアは、他分野の専門家と協働しながら創発していくべきものである
  • 事業側と技術側という分断モデルでは、事業価値を生むソフトウェア開発はできない
• 継続的な学習と成長:
  • 不確実だからこそ、何かを仮決めして進むしかない
  • 事業の複雑さは変化を続けるため、事前にすべてを調査分析して整理することはできない
  • 開発とは、観察・評価・設計・実装のサイクルを何度も回しながら学習し成長する活動である
• ソフトウェア開発の根底原則:
  • 事業目的適合性と発展性の2つが根底原則である
  • 事業目的適合性:
    • 事業目的への適合は大きな事業価値を生む一方、事業目的からはずれたソフトウェアは事業に損失を生む
  • 発展性:
    • 事業は発展を続けるため、事業活動と一体化したソフトウェアの発展性が大きな事業価値となる
    • 発展性に欠け、変更がやっかいで危険なソフトウェアは、事業発展の足かせであり事業リスクである

■ 2. AI技術をソフトウェア開発に活用するアプローチ

• 設計スタイルの選択:
  • 大きな事前設計(BDUF)は、建築や量産型製造業、ウォーターフォール的なソフトウェア開発で一般的な手法である
  • 小さな設計の反復は、最初に小さな設計を行い、その結果を観察して小さな改善を繰り返すインタラクティブかつインクリメンタルな手法である
• AI技術活用の方向性:
  • 自動化(無人化)は、AI技術によりできるだけ人を介在させず、コストダウン、スピードアップ、一定品質を達成する方向である
  • 人の活動支援は、人の判断と行動を主体としつつAI技術で人の能力を増強し、同様の効果を目指す方向である
• 目指すべき象限:
  • 小さな設計の反復と人の活動支援を組み合わせた領域を目指すべきである
  • この領域では、協働創発、学習と成長、観察・評価・設計・実装のサイクルが実現される
• 小さな設計の反復をAIで支援:
  • 不確実さに対応する工夫、複雑さに対応する工夫、学習しながら成長することがポイントとなる
  • 観察・評価・設計・実装のサイクルを回すほど学びが進み、よいソフトウェアに発展させることができる

■ 3. これからのソフトウェア開発にどう取り組むか

• 役立つ知識と技能:
  • 一般論として、事業理解や業務知識、ソフトウェアの設計原則やパターンの知識はAI時代にも役立つ
• 現状の課題:
  • 事業理解や業務知識が役立つと言われてもピンとこない
  • 設計原則やパターンをある程度知っていても、実践で役立つ実感が少ない
  • 何を、どう学べば、どんな効果があるか具体的にわからない
  • 日々の仕事の中で学習の時間を確保できない
• 効率的に学ぶ方法:
  • ソフトウェアの事業目的適合性と発展性を判断し改善するための知識と技能を学ぶ実践的な考え方とやり方が存在する
  • その具体例として、『ドメイン駆動設計をはじめよう』(Vlad Khononov著、増田亨・綿引琢磨訳)を紹介する

■ 4. ドメイン駆動設計 再入門

• ドメイン駆動設計の目指すところ:
  • 事業活動のモデルと設計に焦点を合わせる
  • 知識豊富な設計と深いモデルの探求を重視する
  • 人と人との相互作用、コミュニケーションを重視する
  • モデルと実装を一致させる
  • これらは、事業目的適合性と発展性を向上するための基本原則である
• 土台となる知識と技能:
  • 業務ロジックと入出力を分離する:
    • ビジネスルールの表現に特化したクラスを作る
    • 画面、データベース、通信に依存した構造から切り離す
  • ビジネスルールをプログラミング言語で記述する:
    • 区分、日付、期間、金額、数量、比率などのアプリケーション特化のデータ型を定義して組み合わせる
  • モデルとコードの継続的なリファクタリングを行う:
    • 事業活動を学び理解したことをモデルと実装に反映し、事業目的適合性と発展性を向上する
• 土台の効率的な学び方:
  • 『現場で役立つシステム設計の原則』の1章と2章の基本技法を完全に理解し、3章の考え方を加えるとよい
  • 『リファクタリング』の1章にあるswitch文のリファクタリング例を徹底的に練習するとよい
• 『ドメイン駆動設計をはじめよう』の内容:
  • ソフトウェアの実装と事業戦略を結びつけるさまざまな経験則が書かれている
  • 経験則5点
    • 中核の業務領域に焦点を合わせること
    • 同じ言葉を使うこと
    • 事業の成長と連動したソフトウェアの成長
    • 現実世界のドメイン駆動設計への取り組み
    • 事例研究
• 事業戦略とソフトウェアを結びつける方法:
  • ソフトウェア開発の対象業務を2つの軸で4分類する
    • 横軸: 競合他社との差別化への影響度
    • 縦軸: 業務ロジックの複雑さ(開発の難易度)
  • カテゴリーごとに適切な設計方針を選ぶ
  • 業務ロジックが複雑で自社独自性が高い中核の業務領域では、変更容易性の改善に継続的に取り組む
  • 業務ロジックが単純で他社と同じ一般の業務領域では、模倣または購入を検討する
  • 業務ロジックが単純で自社独自性が高い補完的な業務領域では、簡略に済ませる
• 同じ言葉を使って開発する:
  • 業務エキスパートと開発者が、業務知識、概念モデル、解決モデル、ソースコードにまたがって同じ言葉(業務の言葉)を使う
  • これにより、協働創発、学習と成長が実現される
• 事業の成長とソフトウェアの成長:
  • 事業が成長すれば、業務領域のカテゴリーは変化する
  • 業務領域のカテゴリーが変化すれば、設計方針も変化する
  • 中核・補完・一般の3カテゴリー間では、差別化の機会や単純化などの要因により移行が起こる
• 現実世界のドメイン駆動設計への取り組み:
  • 以下のような状況はありえないし必要もない:
    • チーム全員がドメイン駆動設計を熟知している
    • 最初から全員が役立つモデルの探求に全力を尽くす
    • 全ての関係者が同じ言葉を忠実に使う
    • 既存システムや外部サービスを考慮しなくてよい、制約の少ない新規案件である
  • ドメイン駆動設計のすべての技法を使う必要はない
  • ドメイン駆動設計が組織として受け入れられていない状況でも実践は可能である:
    • 適切な道具を必要に応じて選択的に使う
    • それぞれのやり方の背景にある考え方と原則を意識して使う
    • 組織の変化とソフトウェアの成長に忍耐強く取り組む
• 事例研究(付録A):
  • 原著者の経験談(失敗談)であり、ドメイン駆動設計の浅い理解から出発し、失敗を繰り返しながら学び成長した物語である
  • この本の内容のリアルな元ネタであり、他の情報源では手に入らない貴重な内容である
• さらに学ぶための参考書:
  • 差別化戦略を実行するための考え方とやり方を学ぶには『マイケル・ポーターの競争戦略【エッセンシャル版】』が参考になる
  • 財務会計の専門家ではない人向けに、事業活動のざっくりした全体像を財務の視点から学ぶには『財務3表一体理解法』が参考になる

(2026/08/06)

日本発の国産ＯＳ「トロン」、王者・米国の対抗軸に…「未来の社会インフラに」異例の無料公開で...

• 日本発の国産ＯＳ「トロン」、王者・米国の対抗軸に…「未来の社会インフラに」異例の無料公開で動いた松下電器 : 読売新聞

要約:

■ 1. トロンの概要

• 東京大学助手だった坂村健(現東大名誉教授)が1984年に開発した日本発の国産OS
• パソコン専用OSではなく、家電製品やオフィス機器に組み込まれた小型コンピューターを含む、幅広いコンピューターを動かすための基本ソフト

■ 2. 開発の背景

• 超小型コンピューターの台頭:
  • 当時、コンピューターは企業が社内に設置する大型機が主流だったが、1個の半導体に収まる超小型コンピューターも登場していた
  • 世間には超小型コンピューターを性能面で劣る「おもちゃ」とみなす見方もあった
• 坂村の見立て:
  • 坂村は、超小型コンピューターが今後あらゆるモノに組み込まれるようになると考えていた
  • モノに組み込まれる世界が来れば、それを動かす土台となる基本ソフトが必要になる
    • この考えからトロンを開発した

■ 3. 坂村の思想的動機

• 米国依存への問題意識:
  • 戦後のコンピューター業界では米国勢が圧倒的な強さを誇り、日本のコンピューター産業は米国製品に大きく依存していた
  • 坂村には、世界に通用するソフトを日本から送り出したいという思いがあった
• 超小型コンピューターへの着目:
  • 米国と同じ土俵で戦っても勝てないが、これから到来する超小型コンピューターの世界であれば日本人でも戦えるという読みがあった

■ 4. 無料公開という決断

• 業界の常識:
  • 当時のコンピューター業界では技術を囲い込むのが当たり前で、無料公開という発想自体が珍しかった
• 坂村の選択:
  • 坂村はトロンを無料で公開し、誰でも自由に使用・改良できるようにした
  • この手法は今でこそ「オープンソース」と呼ばれ定着しているが、当時としては異例だった
  • 坂村は、トロンを未来の社会インフラにするには誰でも自由に使えるようにする必要があると考えていた
• マイクロソフトとの対比:
  • マイクロソフトはパソコン向けOSを独占し、日本のパソコンメーカーから利用料を取っていた
  • 坂村の無料公開路線は、こうしたマイクロソフトの姿勢とは対照的だった

■ 5. 日本メーカーの参画と松下電器の動き

• 賛同企業の広がり:
  • 坂村がトロン計画を発表すると、富士通、日立製作所、三菱電機、NECなど、その思想に共鳴した日本メーカーの技術者が続々と計画に参加した
  • 各社はトロンを家電などに搭載し始めた
• 松下電器のパソコン開発参入:
  • トロンは機器向けOSとして開発されたが、消費者向けに作り込めばパソコンOSとしても使用可能だった
  • マイクロソフトOSを用いたパソコン開発で出遅れていた松下電器産業(現パナソニックホールディングス)は、国産OSによる巻き返しを狙い、トロンを使ったパソコン開発に乗り出した

tag:

• 検証デジタル ニッポンの苦境 パソコンOS編

(2026/08/05)

ウィンドウズ９５の設計で「伝説」となったエンジニア、日本を憂える「このままでは『ＡＩ敗戦』が来る」

• ウィンドウズ９５の設計で「伝説」となったエンジニア、日本を憂える「このままでは『ＡＩ敗戦』が来る」 : 読売新聞

要約:

■ 1. ゲイツの決断とウィンドウズ９５

• 次世代OS開発の中止:
  • ビル・ゲイツは次世代OSの開発を中止し、傍流だったウィンドウズをOSとして残すことを決断
  • ウィンドウズ開発者の中島聡はこの決断を当然と受け止めた
  • 次世代OSチームは信じられないという表情を見せていた
  • 大人数と莫大な費用をかけて開発していたOSの中止をその場で決める判断力は普通の経営者にはできないと、中島はゲイツの決断力に脱帽した
• 決断の背景:
  • 中島は、ゲイツが早くから次の波はインターネットだと気づいていたためこの選択をしたとみる
  • インターネット対応OSを早く出さなければ時代に乗り遅れるという危機感があった
  • 時間をかけて次世代OSを開発している場合ではなかった
  • 一歩先の未来を見据えるゲイツにとって、すぐに発売できる速さの方が重要だった

■ 2. ウィンドウズ９５の成功

• 世界的な大ヒット:
  • 中島が基本設計に関わったウィンドウズ９５は世界で大ヒットした
  • 東京・秋葉原の家電量販店では発売と同時にソフトを求める消費者が殺到した
  • カウントダウンや花火で発売を祝うほどのお祭り騒ぎになった
• パソコン普及への貢献:
  • ウィンドウズ９５は現在当たり前になっているパソコンの簡単な操作を実現し、一般に普及させたOSと言われる
    • 画面上のウィンドウやアイコンを、マウスを使って動かす操作方法である
  • その導入には中島が大きな役割を果たした
  • ９５はパソコン普及の起爆剤となり、１９９５年度のパソコン出荷台数は前年度の１・７倍に達した
  • ９５は時代を変革するOSとなった

■ 3. 日本のIT業界への懸念

• ソフト技術者の待遇の悪さ:
  • 伝説のエンジニアと呼ばれるようになった中島は日本の現状を憂えている
  • 日本でソフト技術者は「３K」と言われる存在である
    • きつい
    • 給料が安い
    • 帰れない
  • 米国と比べ、日本のソフト技術者の社会的地位はあまりにも低い
  • 日本企業のソフトや技術者に対する考え方は根本的に間違っていると中島は指摘する
  • 中島は日本の「デジタル敗戦」の大きな原因として、IT人材の待遇の悪さを挙げる
• 人材流出の構図:
  • 約４０年前、中島は日本企業に失望し、活躍の場として米国のIT企業を選んだ
  • 時を経てもその状況に変わりはない
  • 待遇が良く大きな報酬が見込める米国企業に、日本の優秀なIT人材が吸い寄せられ続けている
• AI敗戦への警鐘:
  • 中島は、このままではデジタル敗戦の次に「AI(人工知能)敗戦」が来ると過去の教訓を踏まえて警鐘を鳴らしている

(2026/08/05)

マイクロソフトでの主導権争い、ビル・ゲイツ氏が選んだのは日本人エンジニアが代表を務める「傍流」だった

• マイクロソフトでの主導権争い、ビル・ゲイツ氏が選んだのは日本人エンジニアが代表を務める「傍流」だった : 読売新聞

要約:

■ 1. 次世代OS開発チームでの停滞

• 開発チーム参加:
  • ソフトウェア技術者の中島聡は、マイクロソフトの次世代OS開発チームに加わり、設計を担当することになった
  • このチームは「本流」とされていたが、それまでと勝手が違った
• 進まない開発:
  • 毎日「アイコンとは何か」といった哲学的な議論ばかりで、開発が全く進まなかった
  • ソフトという製品を何より作りたい中島には、そうした議論が無駄な作業に思えた

■ 2. ウィンドウズチームへの異動

• 離脱の決断:
  • 2年が過ぎ我慢の限界を迎えた中島は、次世代OS開発チームを離脱し、旧世代の「ウィンドウズ」を開発するチームへの異動を願い出た
• 周囲の反応:
  • 同僚は口々に「なぜそんなバカなことをするんだ」と言った
  • 当時ウィンドウズは、次世代OSが完成するまでの「つなぎ」と目されていた
  • 次世代OSが世に出れば、旧世代のウィンドウズは消滅する運命にあるとされていた

■ 3. ウィンドウズチームでの中島の活躍

• 自由な環境:
  • ウィンドウズチームで中島は息を吹き返した
  • 同チームは以前いたチームと文化が全く違う、プログラム好きが集まる自由なチームだった
  • 最高の職場環境を得て、中島は自分が理想とする直感的な操作をウィンドウズに組み込もうと試みた
• 導入された操作:
  • ファイルを開くときの「ダブルクリック」
  • ファイルを移動するときの「ドラッグ＆ドロップ」
  • メニューの一覧を呼び出す「右クリック」
  • これらは中島の手によってウィンドウズに取り入れられ、今では広く普及している

■ 4. 次世代OSチームとの対立

• 敵対心の高まり:
  • 旧世代の開発を急ピッチで進める中島に対し、次世代OSチームは敵対心を燃やした
  • 次世代OSチームは、中島が次世代OSのアイデアを盗みウィンドウズに持ち込んでいると社内で批判した
  • 次世代OSチームは社のトップであるビル・ゲイツに直談判し、ウィンドウズの開発を中止するよう訴えた
• 中島の立場:
  • そもそも次世代OSの構想は、中島が最初に作った試作ソフトが基になっていた
  • 中島には「アイデアを盗んだ」などと非難される覚えはなかった
  • 次世代OSチームとウィンドウズチームの対立は、マイクロソフト首脳陣を巻き込む大騒動に発展した

■ 5. 取締役会での決着

• 双方の主張:
  • ゲイツら幹部が勢ぞろいする取締役会で、次世代OSチームの代表者とウィンドウズチーム代表の中島が意見を戦わせた
  • 次世代OSグループは、中途半端なものを出されては困るとして、次世代OSの開発を待つべきだと訴え、ウィンドウズの開発中止を経営陣に迫った
  • 中島は、ウィンドウズはもう試用版まで完成しており、何としても出したいと訴えた
• ゲイツの決断:
  • 両者の言い分を聞いたゲイツは一旦席を外し、5分ほどで戻ると結論を告げた
  • ゲイツは、ウィンドウズはこのまま発売し、次世代OSチームは解散するとの結論を下した
  • ゲイツは次世代OSの開発を中止し、傍流だったウィンドウズをOSとして残すことを決断した

(2026/08/05)

"Clean" Code, Horrible Performance

• "Clean" Code, Horrible Performance - by Casey Muratori

要約:

■ 1. クリーンコード規則の検証方針

• 「クリーン」コードという助言について:
  • 初心者に向けてよく勧められる助言であり、「クリーン」であるための多数の規則を伴う
  • 規則の大部分は実行時の挙動に影響しないため客観的な評価はできない
  • しかし規則の一部は実行時性能に直接影響するため、客観的に測定可能である
• コード構造に影響する5つの規則:
  • if/elseやswitchよりポリモーフィズムを優先する
  • コードはオブジェクトの内部を知るべきではない
  • 関数は小さくあるべき
  • 関数は一つのことだけをするべき
  • DRY(繰り返しを避ける)
• 検証方針:
  • クリーンコード文献で実際に使われている例示コードをそのまま用いる
  • これによりクリーンコードにとって最も有利な条件を作った上で、その主張者自身の規則を検証する

■ 2. ポリモーフィズムとswitch文の比較

• クリーンコード版の実装:
  • shape_baseを基底クラスとし、square/rectangle/triangle/circleがこれを継承する構造にする
  • 各派生クラスは仮想関数Area()を持ち、自身の面積計算に必要なデータも自身で保持する
• 面積合計ループの実装:
  • shape_baseへのポインタ配列を受け取り、各要素のArea()を呼び出して累積するTotalAreaVTBLを用意した
  • クラス階層である以上、図形ごとのメモリサイズが不明なためポインタ配列にせざるを得ない
  • イテレータは規則に明記されていないため使用せず、コンパイラを混乱させる要因を排除した
  • 累積のループ依存を疑い、4つのアキュムレータに手動アンロールした版も念のため用意した
• 計測方法:
  • コールドキャッシュ状態(L3にはあるがL1/L2はフラッシュ済み、分岐予測器も未学習)での1回実行を計測した
  • キャッシュと分岐予測が最も有利に働く条件での繰り返し実行も計測した
  • 両者の結果に大きな差はなかった
• クリーンコード版の結果:
  • 1図形あたり約35サイクル(条件次第で34サイクル程度)を要した
• switch文版への書き換え:
  • enumのshape_typeと、Width/Heightを持つ単一構造体shape_unionへ全図形を統合した
  • GetAreaSwitch関数内のswitch文で各図形の面積を計算する、クリーンコード以前の書き方にした
  • 専用フィールドを持たないため、高さを使わない図形はWidthのみを参照する
  • 合計ループの中身はクラス階層版とほぼ同一であり、仮想関数呼び出しが通常の関数呼び出しに変わっただけである
• switch文版の構造的な利点:
  • 図形が同一サイズの構造体になるため、ポインタではなく配列に直接格納できる
  • コンパイラがGetAreaSwitch関数の全コードパスを静的に把握できるようになる
  • 実行時にしか分からない仮想関数を仮定する必要がなくなる
• switch文版の結果:
  • 1図形あたり24サイクルとなり、クラス階層版に対して1.5倍高速だった
  • この差はiPhone 14 Pro MaxからiPhone 11 Pro Maxへ後退するのに等しい規模である
  • ハードウェアの進化にして3〜4年分が失われる計算になる

■ 3. 内部知識を活用した最適化

• 共通パターンの発見:
  • switch文の各caseは、いずれも「幅×高さ」または「幅×幅」に係数を掛ける構造になっている
  • 係数は三角形なら0.5、円ならπというように、図形ごとに定数として表せる
• switch文の意義:
  • 操作(関数)単位でコードがまとまっていると、こうした共通パターンを見つけやすい
  • クラス階層版では型ごとにコードが分割され、さらに別ファイルに分けるのが慣習であるためパターンに気づきにくい
  • 同種の型は似た構造を持つことが多く、このパターンの発見は特別な例を選んだ結果ではない
• テーブル駆動方式への書き換え:
  • 図形種別ごとの係数を格納したテーブルCTableを用意する
  • 単一パラメータの図形(正方形・円)ではWidthをHeightにも複製しておく
  • これによりGetAreaUnion関数はテーブル参照を含む1行の計算に単純化される
  • 合計ループ自体は変更不要で、呼び出す関数をGetAreaUnionに差し替えるだけでよい
• 結果:
  • 1図形あたり3.0〜3.5サイクルとなり、クリーンコード版に対し10倍以上高速だった
  • コード量・トークン数・演算数も同時に減少しており、高速化と意味的単純化を両立している
  • 現行ベンチマークで遡れる最古の機種であるiPhone6と14 Pro Maxの性能差ですら約3倍にとどまり、10倍という差はiPhoneでは表現できない
  • デスクトップCPUで換算すると、2023年当時の平均性能から2010年当時の平均性能まで後退する規模に相当する

■ 4. プロパティ追加時の検証

• 問題の拡張:
  • 各図形にCornerCount()という仮想関数を追加した
  • 四角形は4、三角形は3、円は0を返すようにした
  • 面積の単純合計ではなく「1÷(1+角の数)」を重みとした角数加重面積の合計を新たな計算対象とした
  • この拡張に特別な意図はなく、単に最も単純な形で複雑さを一つ足しただけである
• 各版の更新内容:
  • クラス階層版はArea()に加えCornerCount()も呼び出し、係数を掛けて累積するCornerAreaVTBLとした
  • switch文版はGetCornerCountSwitchという新たなswitch文を追加し、GetAreaSwitchと組み合わせて計算する
  • テーブル駆動版はCTableの値に角数加重済みの係数を直接埋め込むだけでよく、コード自体は変更不要だった
• 結果:
  • switch文版はクラス階層版に対して約2倍高速になった
  • テーブル駆動版は約15倍高速になった
  • プロパティを一つ増やしただけで性能差がさらに拡大した
  • 問題が複雑になるほどクリーンコードの手法が及ぼす害は大きくなる
  • ハードウェア換算では2023年の性能から2008年の性能まで後退する規模であり、12年分の後退が14年分にまで拡大した

■ 5. コンパイラ最適化と保守性への影響

• クリーンコードとコンパイラの関係:
  • クリーンコードを徹底するほどコードは別々の翻訳単位や仮想関数呼び出しの背後に分散する
  • その結果、コンパイラがコード全体を把握できなくなり、最適化の余地が失われる
• 保守性への影響:
  • 型を中心に設計されたコードベースでは、テーブル化やswitch文除去のような単純な改善すら困難になる
  • 場合によっては大規模な書き換えなしには不可能になる
  • 一方、関数(操作)を中心に設計されたコードベースでは、こうした改善が容易に行える

■ 6. AVX最適化版との比較

• ここまでの比較はループ内累積依存の排除以外、いかなる最適化も行っていない状態のものである
• 軽くAVX最適化を施した版と比較すると、性能差は20〜25倍に達する
• このAVX最適化版はクリーンコードの原則を一切採用していない

■ 7. DRY原則への見解

• DRY原則への基本的な立場:
  • 概ね同意できる規則である
  • 検証で用いたコードでもほとんど重複は生じていない
  • 唯一該当しうる4アキュムレータ版の重複は計測目的であり、通常は両方の関数を用意する必要はない
• 厳格な解釈への留保:
  • 「同じ係数を符号化する複数のテーブルを作ってはいけない」という水準まで厳格に解釈するなら同意しかねる場合がある
  • 妥当な性能を得るためにはそうした重複が必要になることがあるため
• 妥当な解釈での結論:
  • DRYが単に「全く同じコードを二度書かない」という意味であれば妥当な助言である
  • かつ性能を犠牲にせずに従うことができる

■ 8. 結論

• 五規則の総評:
  • 構造に影響する5つの規則のうち、検討の余地があるのはDRYの1つのみである
  • 残る4つの規則については明確に避けるべきである
• ソフトウェアが遅い一因:
  • 現代のソフトウェアはハードウェアの実力に比して低速である
  • その要因の一つが「クリーン」コードの実践である
• クリーンコード規則の目的と代償:
  • 各規則は、より保守しやすいコードベースを作る目的で生まれたものである
  • しかしその効果を得る代償が10年以上のハードウェア進化に相当する性能であるなら、目的に見合わない
• ソフトウェアの役目:
  • 与えられたハードウェア上で適切に動作することがソフトウェアの役目である
  • プログラマの労力を多少軽減するために10年以上のハードウェア性能を犠牲にすることは許容できない
• 今後の規則のあり方:
  • コードを整理し保守しやすく読みやすくするための指針を模索すること自体は否定しない
  • しかしこれらのクリーンコード規則はその指針として不適切である
  • 「従うと性能が15倍以上低下する」という警告が伴わない限り、今後語られるべきではない

論評:

■ 1. Muratoriの主張

• 比較対象:
  • "クリーンコード"の代表的ルール(ポリモーフィズム優先、内部知識の隠蔽、小さな関数、DRYなど)に従った図形クラスの面積計算コードと、switch文+テーブル駆動で書いた同等コードを比較
• 結果と結論:
  • switch+テーブル駆動版が最大15〜25倍高速だったと報告
  • クリーンコードは性能面で許容できないと結論づけている

■ 2. サンプル選定はストローマン

• 例の出典:
  • Muratoriはクリーンコード文献の例をそのまま用いたと主張するが、これはむしろ問題を悪化させている
• 教育用トイ例の転用:
  • 図形の面積計算は、教科書がポリモーフィズムの概念を教えるために選んだ最も単純な例
  • 実務でホットループを毎フレーム数百万回回すコードでは、経験のあるエンジニアは最初からデータ指向設計(DOD)やテーブル駆動を選ぶ
  • 教育用のトイ例を性能クリティカルなベンチマークとして扱うのは藁人形論法の典型
• 弁明の欺瞞性:
  • クリーンコード提唱者が使う例だから公正だという弁明は、その例が性能検証のために作られていないという事実を隠蔽している

■ 3. クリーンコード定義の恣意性

• 定義の絞り込み:
  • 記事は「クリーンコードのルールのうち構造に影響するもの」を5つに絞り込み、そのうち4つを駄目と断じる
• Robert C. Martinの文脈の省略:
  • Martin自身、パフォーマンスクリティカルな内側ループでの最適化を否定していない
  • まず動くコードを書き、それから最適化するというアプローチを推奨している
  • クリーンコードはホットパス以外、アプリケーションの95%を占める非クリティカルなコードに適用すべきという文脈が省略される
• 小関数とインライン化の混同:
  • 「関数は小さくあるべき」「一つのことをする」というルールと、実行時のインライン化・コンパイラ最適化は本質的に矛盾しない
  • 現代のコンパイラは小さな関数を積極的にインライン展開する
  • 性能問題の主因はポリモーフィズム(仮想関数)であり、関数が小さいこと自体ではない
  • この2つを同列にクリーンコードのルールとして扱い、同じベンチマークの犠牲にしているのは論理のすり替え

■ 4. 交絡変数の未分離

• 複数変数の同時変更:
  • 比較対象の「クリーン」版と「switch」版は、同時に複数の変数を変えている
    • vtable/仮想関数呼び出し対直接呼び出し
    • ポインタ配列(AoS of pointers)対値のフラット配列(実質AoS→SoAに近い形)
    • ヒープ上に分散したオブジェクト対連続メモリ上の構造体配列
• 要因の混同:
  • 間接参照コスト、メモリレイアウト・キャッシュ局所性、分岐予測という異なる要因が一つの数字に混ざっている
  • 「ポリモーフィズムが1.5倍遅い」という主張は、実際にはポリモーフィズムによって強制されるポインタ間接参照とメモリ分散が原因である可能性が高い
  • ポリモーフィズムそのものの本質的コストとは言えない
• 反証の余地:
  • タグ付きunion+関数ポインタテーブルなど、値型でvtableを使わない仮想関数もどきであればもっと近い性能が出せるケースもある
  • これを切り分けずにポリモーフィズムが悪いと結論づけるのは、統計的にも工学的にも粗い

■ 5. テーブル駆動化のミスリード

• 数字の実体:
  • テーブル駆動版の10〜15倍という数字は記事内で最もセンセーショナルだが、実際には計算そのものをテーブルルックアップに置き換えて分岐や乗算を削減した効果
  • ポリモーフィズムを避けたことの効果ではない
• 論点のすり替え:
  • これはクリーンコード対アンチクリーンコードの対決ではなく、アルゴリズムの選択の話に近い
  • クリーンコードの原則(内部知識を隠すなというルールへの違反)とテーブル駆動最適化は独立した最適化技法
  • ポリモーフィズムを使ったまま(仮想関数の中でテーブルを引く実装)でも一定の高速化は可能
  • この部分をクリーンコード対非クリーンコードの物語に組み込むのは比較の公平性を損なう

■ 6. 外的妥当性の欠如

• 処理規模の小ささ:
  • テストされているのは35サイクル対3サイクルという、絶対値として極めて小さい処理単位
  • 実アプリケーションでこの関数がボトルネックになる比率、呼び出し頻度、I/Oや他の処理との比較への言及が一切ない
  • Amdahlの法則的な視点、全体のうちこの処理が何%を占めるかという視点が完全に欠落している
• レトリックの誇張:
  • 「iPhone 14 Pro MaxからiPhone 11 Pro Maxに退化」「12年分のハードウェア進化が消える」という比喩は劇的だが、相対倍率をハードウェア世代に強引にマッピングしただけの修辞
  • 実際のユーザー体験や実務上のコストとは無関係な誇張表現
  • 説得力を演出するレトリックであり、技術的な論証の質を高めるものではない
• 手法の粗さ:
  • ベンチマーク手法についても、本格的な分析ツールは使っていないと著者自身が認めている
  • 統計的な有意性・分散・複数回試行・異なるCPUアーキテクチャでの再現性などが示されていない

■ 7. 保守性軽視の二分法

• 誤った二分法:
  • 記事末尾では、保守性のためにハードウェアの進化十年分を犠牲にするなんてあり得ないと述べるが、これは典型的な誤った二分法
• 開発コストの実態:
  • 実際のソフトウェア開発コストの大部分は、初期開発や実行時性能ではなく保守・変更・デバッグにかかる人的コスト
  • エンタープライズソフトウェアの大多数(業務システム、CRUD API、UIロジックなど)では、CPU数サイクルの差は事業上ほぼ無関係
    • 可読性や変更容易性の方がはるかに高いROIを持つ
• 適用領域の過度な一般化:
  • Muratoriのフレーム(ゲームエンジン/HPC的な視点)を、あたかも全てのソフトウェア開発に一般化できるかのように語っている
  • 対象領域の限定を怠った過度な一般化

■ 8. 帰属の粗さ

• 単一集団としての扱い:
  • 記事は終始「クリーンコード提唱者」を単一の均質な集団として扱い、具体的に誰の・どの主張への反論なのかを明示しない
  • 唯一の脚注でも用語法の違いを認めつつ流している
• 反論対象の曖昧化:
  • 実際には多様な立場を持つクリーンコード推進派をひとまとめに攻撃する構造になっている
  • 反論の対象が曖昧

■ 9. 総括:擁護点と難点

• 擁護できる点:
  • 仮想関数呼び出しが間接分岐・キャッシュミスを誘発し、ホットループで測定可能な性能劣化を招くこと自体は、コンパイラ理論・CPUアーキテクチャの観点から妥当
  • ゲーム開発やHPC、組み込みなど性能クリティカルな領域では、データ指向設計がクリーンコードの一部の慣習より優れているという主張は業界内で広く支持されている
• 擁護できない点:
  • 単一の教育的な簡素なサンプルをもってクリーンコード全般を性能的に断罪するのは一般化が過ぎる
  • 複数の交絡変数(間接参照・メモリレイアウト・アルゴリズム選択)を分離せず、一つの数字(15倍)に集約している
  • 保守性・開発速度・バグ率といった性能以外の重要な軸を、ハードウェア進化年数という一つの指標に矮小化して切り捨てている
  • レトリック(iPhone比喩など)が科学的厳密性を装った説得の道具として多用されている
• 結論:
  • この記事は特定のホットパスにおけるポリモーフィズムのコストを可視化するという限定的な目的では価値がある
  • クリーンコードは性能面で受け入れがたいという一般的結論を導くための論証としては、サンプル選択・交絡変数・適用範囲の面で重大な弱点を持つ

(2026/08/05)

なぜ、ループエンジニアリングの普及がウォーターフォール開発を復活させるのか？

• なぜ、ループエンジニアリングの普及がウォーターフォール開発を復活させるのか？

要約:

■ 1. ループエンジニアリングとは

• 定義と背景:
  • 生成AIによる開発は当初、自然言語で指示しその場で次の指示を出すバイブコーディングへ向かうと考えられていた
  • しかしAIコーディングエージェントを本格的な開発へ投入すると、逆方向へ進み始める
  • AIが実装、試験、修正を自律的に繰り返すループエンジニアリングでは、AIへ作業を引き渡す前に目的、作業範囲、設計方針、検証方法、完了条件、停止条件を明確にする必要がある
  • この言葉は2026年6月ごろから広く使われ始めた
  • コーディングエージェントへ一回ずつ指示を出す技能から、エージェントへ継続的に指示を出す仕組みそのものを設計する技能へ重点が移り始めたことを表す
  • まだ初期段階の概念であり、実行結果やトークン費用の変動幅には注意が必要
• 本稿の主張:
  • 重要なのはループが存在することではなく、その反復によって何が修正されるのか
  • 典型的なループエンジニアリングで修正されるのは、事前に定められた仕様や受入条件へ適合するための実装
  • 利用者の反応を受けて要求や製品の目的そのものを見直す反復とは階層が異なる
  • 開発工程全体を見れば、ループエンジニアリングは下流工程をAI化した計画駆動型開発へ近づく
  • フィードバックとフィードフォワード、上流と下流、人月とトークン、アーキテクトとPMという観点から整理する

■ 2. ループとフィードバックの違い

• スパイラルモデルとの相違:
  • 「ループ」という言葉からはバリー・ベームのスパイラルモデルを連想しやすい
  • スパイラルモデルでは各周回で目的を定め、代替案とリスクを評価し、開発と検証を行い、その結果を次の周回へ反映する
  • ベーム自身もスパイラルモデルをリスク駆動の開発方式として位置づけている
  • ループエンジニアリングの典型的な反復はこれとは階層が異なる
    • 人間が事前に目的と受入条件を定め、AIがコードを調査し、実装し、試験を実行する
    • 試験に失敗すればAIは原因を分析してコードを修正する
• フィードバックが変更する範囲:
  • フィードバックによって変更されるのは、原則として実装方法のみ
  • 仕様が利用者の問題に合っているか、選択したアーキテクチャが適切か、そもそも作る価値があるかという目標値そのものは、通常、内側の実装ループの手前に置かれている
  • 制御系として表すなら、仕様や受入試験が目標値であり、コードベースが制御対象である
    • AIエージェントは操作器としてコードを変更し、試験や静的解析がセンサーとして目標との差を検出する
    • これは目標値への追従制御である
  • 要求、設計、品質基準、例外処理、権限、停止条件などは、ループ開始前に人間が予測して与える
  • 開発全体として見れば、計画と仕様はフィードフォワードであり、実装部分だけが閉ループになっている
  • これはウォーターフォール開発が持つ計画駆動性を強く受け継いだ構造である

■ 3. 外側ループと速度差

• 外側ループの位置づけ:
  • ループエンジニアリングの議論には外側のループも含まれる
  • アンドリュー・ングは、エージェントによる実装ループ、開発者によるフィードバックループ、利用者の反応を製品の方向へ戻す外部フィードバックループという三層で整理している
  • アディ・オスマニも、内側の実行ループと、人間が制約、検証、承認、責任を担う外側のループを区別している
  • したがって、ループエンジニアリングでは要求が一切見直されないという主張は成立しない
  • 問題は外側のループが存在するかどうかではなく、内側と外側のループをどこまで同じ速度で回せるか
• 速度差の帰結:
  • AIによる実装、試験、修正は数分から数時間で繰り返せる
  • 利用者の反応の観測、利害関係者の意見調整、投資判断や製品方針の変更にはより長い時間を要する場合がある
  • ただし外側のループが必ず数週間単位になるとは限らない
    • AIが試作品や途中成果を高速に生成し、それを利用者へすぐ提示できる環境では外側のループも短縮できる
  • 本稿が想定するのは、内側の実装速度の向上に、利用者の観察、組織的な合意、価値判断の速度が追いつかない場合である
    • 内側が数時間で回る一方、外側の判断に数日以上かかるようになれば、一定期間に生産される成果物のうち人間の判断が挟まった回数の割合は低下する
    • 人間の関与は実装ループの途中から、ループへ投入する仕様、制約、受入条件の設定へ集中していく
  • 本稿ではウォーターフォールを、工程が一方向に一度だけ進む方式と狭く定義していない
    • 要求や設計を下流工程の開始条件として外部化し、上流で定めた内容が下流の生産を強く拘束する性質に注目している
  • 外側のループが存在していても、内側との速度差が拡大すれば実務上の開発は計画駆動型へ寄る
  • 逆に内側の高速化が外側の高速化も引き起こし、要求や製品仮説を短周期で変更できるなら、ループエンジニアリングはアジャイル開発を強化する可能性もある

■ 4. 自律時間とフィードフォワード性

• 自律稼働の代償:
  • AIエージェントへ長時間仕事を任せる価値は、人間が途中で逐次指示を出さなくても作業が進むことにある
  • 人間とのやり取りを減らすほど、AIは途中で新しい情報を受け取れなくなる
  • 仕様に矛盾があった場合、利用者に確認せず、与えられた情報からもっともらしい解釈を選ぶ
  • 未定義の例外が発生した場合も、人間が介入しなければ自ら判断するか停止するしかない
  • そのため自律稼働時間を延ばすには、開始前に与える情報を増やす必要がある
  • 目的だけでなく、変更してよい範囲、変更してはいけない範囲、既存設計の不変条件、優先順位、例外時の判断方法、試験方法、完了条件、再試行回数、人間へ引き上げる条件まで定義しなければならない
  • 自律性を高めるほど途中の質疑応答が減り、質疑応答が減るほど事前仕様が重くなる
• OpenAIの内部実験:
  • 人間がソースコードを一行も書かない条件で、約5か月かけて百万行規模の製品が構築された
  • 当初3名、最終的に7名の技術者が、プルリクエストと継続的統合の仕組みを通じてエージェントを誘導した
  • 人間が担った仕事は、リポジトリ構造、作業規約、機械的な検査、評価方法、エージェントから見える情報環境の設計だった
  • エージェントにとって、実行中に文脈へ取り込めない情報は存在しないのと同じである
  • 希少資源として扱われたのは、コード入力時間ではなく人間の時間と注意だった
  • 自律化によって計画が不要になるのではなく、自律化を成立させる条件として計画、制約、検証方法が必要になる

■ 5. 下流委託のAI化

• 従来のウォーターフォールとの対応:
  • 従来のウォーターフォール開発では、上流のアーキテクトやSEが要件定義書、基本設計書、品質基準、試験方針を作り、詳細設計や実装を担う社内チームまたは協力会社へ流していた
  • 下流チームは渡された設計に基づいて詳細化、実装、単体試験、不具合修正を行い、成果物と試験結果を上流へ返す
  • 上流側は設計どおりに作られているかを確認して受け入れる
  • ループエンジニアリングでも基本構造は変わらない
    • 要件定義書や基本設計書に相当するものが、設計文書、AGENTS.md、タスクプロンプト、機械実行可能な試験、変更禁止範囲、停止条件へ変わる
  • AGENTS.mdは、エージェントへプロジェクト固有の作業規約や検証手順を伝えるための設定ファイルである
    • 開発環境、権限、道具、履歴管理、コマンド実行機構はAI用の実行基盤として整備される
  • AIエージェントはそれらを受け取り、内部で調査、実装、試験、修正を繰り返し、最後にプルリクエスト、試験結果、実行記録などを上流へ返す
    • つまり下流の協力会社がAIエージェントに置き換わった形である
  • AI内部で何度ループが回っても、委託構造そのものはフィードフォワード型である
    • 発注側が先に仕事を定義し、受注側がその仕様に従って成果物を作り、発注側が検収する
  • ループという名称はAIエージェント内部の動作を表すが、PMやアーキテクトから見た本質は上流から下流への委譲である

■ 6. AIは下流熟練者の補正機能まで奪う

• 従来の非公式フィードバック:
  • 従来のウォーターフォール開発には、設計書に明記されていない非公式なフィードバック経路があった
  • 優秀な詳細設計者や実装者は、上流の仕様に矛盾があれば質問し、既存機能への影響を発見すれば警告し、より保守しやすい構造があれば代案を提示した
  • 公式には下流工程であっても、実際には質疑票、レビュー、会議、日常的な会話を通じて上流設計が修正されていた
  • ウォーターフォールが現実に成立していた理由の一つは、下流の人間が単純な命令実行機ではなかったことである
• AIによる代替と限界:
  • AIエージェントも質問や提案はできる
  • しかし長時間自律ループの目的は人間との往復を減らすことにある
    • 疑問が生じるたびに停止して人間へ確認していては自律化の便益が小さくなる
  • そのためループを安定して動かすには、下流から来るはずだった質問や異論を事前に予測して設計へ埋め込む必要がある
    • アーキテクトはAIとの壁打ちを繰り返し、仕様の解釈の余地、既存設計との矛盾、未定義の異常系、受入試験だけを形式的に通す抜け道の有無を検討する
  • ループ開始前のAIは、仮想的な下流リーダー、設計レビュー担当者、反証者として使われる
    • 設計が十分に収束した後、別のAIまたは同じAIが下流の実装主体として動く
  • AI時代の開発には、上流での対話と下流での実装という二種類の反復が存在する
    • 本質的な難所は、曖昧な要求を実行可能で検証可能な仕様へ変換する前者の反復に残る

■ 7. バイブコーディングとの対比

• バイブコーディングの原義:
  • 生成された差分を十分に読まず、コードの理解を失っても気にせず、動作結果を見ながら追加の指示を出す開発態度を指す
  • サイモン・ウィルソンも、AIを使ってコードを書くこと一般と、生成物を理解せずに進めるバイブコーディングを区別している
  • バイブコーディングでは判断基準が人間のその場の感覚に残る
    • 出力を見て気に入らなければ次の指示を出し、事前に体系的な受入条件を作る必要はない
• ループエンジニアリングとの対比:
  • 成熟したループエンジニアリングでは、人間が不在でもAIが進めるように、判断基準を仕様、試験、制約、予算、停止条件として外部化する
  • バイブコーディングは考えながらAIに書かせる方法であり、ループエンジニアリングはAIを自律稼働させられるところまで考えた後で引き渡す方法である
  • 両者は、自然言語でAIへ指示し人間がコードを一行ずつ入力しないという外見だけは似ている
    • しかしその外見はプログラミング未経験者が想像しやすい開発像にすぎない
  • 実際のソフトウェア開発の難しさは、曖昧な要求を解釈し、責務と境界を定め、既存システムとの整合を取り、異常系を考え、検証可能な仕様へ変換し、実装から得た知見を要求や設計へ戻すことにある
    • 頭の中に完成しているプログラムを文字として入力する作業はその一部にすぎない
  • コード入力という目立つ工程が自動化されたことで本来の難所が露出する
    • その難所を省略しようとするのがバイブコーディングであり、事前に徹底して処理しようとするのがループエンジニアリングである
    • 両者は開発に必要な理解と検証をどこへ置くかという点で対極にある

■ 8. 人月からトークンへ

• ウォーターフォール時代の人月:
  • 上流の設計判断が下流で消費される人月を決めていた
  • 仕様が曖昧であれば、下流からの質問、設計変更、実装のやり直し、試験項目の追加が発生する
  • 責務分割が悪ければ複数チームの調整が増える
  • PMやアーキテクトは、この設計を下流へ流した場合に何人月かかるか、どれほど手戻りが発生するか、納期と予算の範囲に収まるかを考える必要があった
• トークンへの置き換え:
  • ループエンジニアリングでは、この資源がトークンと計算資源へ置き換わる
  • 曖昧な仕様はAIの探索範囲を広げ、大きすぎるタスクは文脈を肥大化させ、弱い完了条件は反復回数を増やす
  • 複数のエージェントを使って実装、レビュー、試験を分担させればモデル呼び出しが重なる
  • Anthropicが自社の調査用複数エージェント機能について公表した計測では、単一エージェントは通常の対話の約4倍、複数エージェント構成は約15倍のトークンを使用している
    • これはコーディングではなく調査用途の数値だが、追加費用を正当化できる高価値な仕事に限定すべきだという結論は開発にも通じる
  • AIエージェントの費用は、入力文脈、出力、推論、反復回数、並列数、試験実行、レビュー、失敗後の再試行の組み合わせで決まる
  • 「この設計を協力会社へ流したら何人月かかるか」という問いは、「この設計をAIループへ流したら、どれだけトークンと計算資源を消費するか」という問いへ置き換わる
  • 上流の曖昧さを下流資源の投入によって吸収する構造は変わっていない

■ 9. 技術判断が原価判断になる

• 従来の分業とAIループでの変化:
  • 従来の大規模開発では、アーキテクトが技術構造を決め、PMが見積もり、要員、契約、納期、予算を管理する分業が可能だった
    • 実際には重複する部分もあったが、技術設計と原価管理の間には組織的な距離があった
  • AIループでは、その距離が短くなる
    • タスクの分け方、モデルの選択、文脈の大きさ、変更範囲、試験範囲、再試行上限といった技術的判断がそのままトークン消費量を左右する
    • 責務を一つのエージェントへ渡す、複数案を並列探索させる、試験を毎回全件実行すると決めた瞬間に消費構造が決まる
  • そのためアーキテクトは技術的に正しい構造を作るだけでは足りず、どれほどの探索が必要か、費用に見合う価値があるか、どこで打ち切るべきかまで判断する必要がある
• 役割分担の残存と限界:
  • 役割分担が消えるわけではない
    • 細分化された組織では、スタッフエンジニアやアーキテクトが技術的な探索範囲を決め、エンジニアリングマネジャーが予算と遂行を管理し、プロダクトマネジャーが投資価値を判断し、費用管理の担当者が消費を追跡する形になる
    • 財務担当も、AIの原価はトークン単価だけでは判断できず、品質と性能を含めて課金方式や構成を比較する必要があるとしている
  • しかし役割を分けても技術判断と原価判断を完全には切り離せない
    • 費用超過の原因が、単なる単価ではなく責務分割、試験戦略、文脈設計、終了条件にあるため
  • 日本のSIerのように、上級SEやPMが要件調整、基本設計、協力会社管理、見積もり、品質管理を横断的に担う組織では、AI工程設計とトークン原価管理も同じ人物へ上乗せされやすくなる
    • 人間の要員管理が減る代わりに、AIの探索範囲、実行予算、並列数、継続判断、成果物の受入を管理する仕事が増える
  • 結果としてアーキテクトは、設計者であると同時にAI下流工程への発注者、工程設計者、原価判断への技術的責任者、検収責任者になる

■ 10. 超少人数のウォーターフォール

• 復活する体制の性質:
  • ループエンジニアリングによって復活するのは、大人数と大量文書を前提とした20世紀型の開発体制そのものではない
  • 上流には、利用者の要求を理解し、技術構造を決め、AIと壁打ちを繰り返し、受入条件を作れる少数の熟達者が残る
  • 下流では、多数の人間の代わりにAIエージェントが実装、試験、修正を反復する
  • 先のOpenAIの実験は、この体制が実際に動く可能性を示した
    • 百万行規模の製品を3名から7名の技術者が誘導し、人間の仕事は環境設計、意図の記述、機械的な検査の整備へ集中した
• 開発組織の構造:
  • 顧客や利用部門から得た要求を、少人数のPM、プロダクト責任者、アーキテクトが解釈する
  • アーキテクトはAIを反証者として使い、要求の矛盾、技術的リスク、異常系、試験条件を洗い出す
  • 十分に設計が固まった段階で、仕様と制約をAIエージェントへ渡す
  • マクロでは上流から下流へ仕様を流す計画駆動型の工程であり、ミクロではAIが実装、試験、修正を繰り返す高速な反復型工程である
    • 中央集権的な設計と局所的な高速反復を組み合わせた開発方式である
  • アジャイルソフトウェア開発宣言は、計画に従うことより変化への対応を、契約交渉より顧客との協調を重視している
    • AIエージェントを長時間自律稼働させるほど、人間による途中の協調や変更は減る
    • 外側のフィードバックも同時に高速化できない環境では、自律性を得るための事前設計がウォーターフォール的な工程を再び合理的なものにする

■ 11. 復活するのは上流責任

• 復活の本質:
  • 工程の順序が昔のまま戻るわけではない
  • AI時代に復活する本質は、上流で定めた情報が下流の生産を規定し、その情報の品質について上流が責任を負う構造である
  • AIエージェントは下流工程の速度を上げるが、何を作るべきかを単独で決定する主体ではない
    • 要求の採否は価値判断であり、価値判断にはその選択の結果に対して資本と責任を負う帰属先が必要である
  • AIが要求案や仕様案を生成できるようになっても、この構造は変わらない
    • 生成された案のどれを採用するかという判断は損失を引き受ける主体へ帰属する
    • 能力が上がるほど案は増え、帰属先が行う選択と承認の回数はむしろ増える可能性がある
• 上流の問題設定能力の重要性:
  • ループの完了条件が間違っていれば、AIは間違った完了状態へ効率よく到達する
  • 停止条件が弱ければトークンを消費し続け、作業分割が悪ければ複数のAIが矛盾する変更を並列に生成する
  • AIが高性能になるほど上流の問題設定能力が全体の成果を決める
  • これはウォーターフォール開発が長く抱えてきた構造と同じである
    • 上流の一行が下流の何十人月を左右していたのに対し、ループエンジニアリングでは上流の一行が何百万トークンの消費と大量の生成物を左右する

■ 12. 現場で観測されるはずの変化

• 予測される観測項目:
  • 本稿の整理が正しければ、AIエージェントを本格導入した組織ではいくつかの変化が観測されるはずである
  • 第一に、実装開始前に外部化される制約、受入条件、作業規約、機械検証可能な規則の量が増える
    • ここでいう量は自然言語の仕様書のページ数だけでなく、自動試験、型、静的解析規則、権限設定、実行方針、評価器、停止条件なども含む
  • 第二に、開発における人間の総作業時間のうち、問題設定、環境設計、評価方法の構築、成果物の受入といった上流側の作業が占める割合が上がる
  • 第三に、長時間の自律ループへ投入された後に人間が要求や設計を変更する頻度は、逐次対話型の開発より下がる
  • 第四に、人員構成が上流側へ偏り、詳細設計、実装、試験を専門に担う人員が減る
  • 先のOpenAIの事例は、少なくとも人間の作業が環境設計と意図の記述へ集中し、直接実装する人員が存在しなかったことを示している
• 反証条件:
  • 逆に、AIエージェントの導入によって実装開始前に外部化される制約や評価規則が薄くなり、要求変更の受付頻度が上がり、利用者を含む外側のループも内側と同程度に高速化するという観測が広く得られるのであれば、本稿の整理は誤りである
    • その場合、内側ループの高速化は上流の計画駆動性を強めるのではなく、外側の学習速度を高め、開発をアジャイル側へ寄せていることになる
  • 判定材料は今後数年で揃う
    • 導入企業における実装前の制約や評価規則の量、要求変更の頻度、人間の作業時間の内訳、職種別の人員構成、AI利用費の責任分担が検証データになる

■ 13. まとめ

• ループエンジニアリングの位置づけ:
  • ループエンジニアリングは反復という言葉を含むため、アジャイル開発やスパイラルモデルの延長に見える
  • 典型的な内側のループで修正されるのは、事前に定めた仕様へ適合するための実装である
  • 要求を見直す外側のループも存在するが、内側の実装速度に利用者の観察、組織的な合意、価値判断の速度が追いつかなければ、両者の速度差は開いていく
• 資源の置き換えとその非対称性:
  • 開発全体では、要求、設計、受入条件、停止条件を上流で事前に定め、下流のAIがそれに従って成果物を作る
    • これは従来のアーキテクトが基本設計を下流チームや協力会社へ渡していた構造と同じである
    • 変わるのは下流で投入される資源である
  • 人間の詳細設計者、実装者、試験担当者が減り、代わりにトークン、計算資源、AIエージェントの反復が投入される
    • ただしこの置き換えは等価ではない
    • 人間の増員に働いていた雇用や対人調整の制約は小さくなる一方、成果物間の整合、選別、統合の必要は残る
  • ウォーターフォール時代には、アーキテクトとPMが人月を燃やす責任を負っていた
    • ループエンジニアリング時代には、設計者の技術判断がトークンを燃やす量を決める
    • 技術設計が探索範囲と反復量を決めるため、アーキテクチャ判断と原価判断は不可分になる
  • AIが途中で人間からフィードバックを受けずに長時間動くほど、開始前の壁打ちと設計は重くなる
    • アーキテクトはAIを使って要求の穴を探し、異常系を洗い出し、受入条件を作り、AIへ委託可能な仕様へ仕上げる
    • その後、AIエージェントが下流で高速な実装ループを回す
• 結論:
  • ループエンジニアリングによって成立するのは、少人数の熟達者が上流を設計し、AIが下流を大量に処理する世界である
  • それはマクロではフィードフォワード、ミクロでは閉ループという構造を持つ、超少人数・設計主導・AI下流型のウォーターフォールである
  • AIは人海という弱点を取り除き、上流設計者の技術判断をトークン原価へ直結させることで、ウォーターフォールが持っていた計画駆動性と上流責任を、新しい経済条件の下で復活させる

MEMO:

• 元のテキストがAI Slopだと要約してもろくな品質にはならなそうだ

(2026/08/05)

40代ITエンジニアだが俺たちの世代がIT業界を衰退させたことに謝罪したい

• 40代ITエンジニアだが俺たちの世代がIT業界を衰退させたことに謝罪したい

タイトルの通り。

Xやネットでは、俺くらいの世代のエンジニアがネット文化の構築アーリー世代だから、こんな話リアルで言えばマジギレされるのでネットでしか書けないのが少し歯がゆいが

申し訳ない、今まで俺達の世代を冷遇したから日本のIT業界は衰退したんだ、という神話が流布されているが、あれ、俺達の言い訳にすぎん、実態を書いておこうと思う。

先に断っておくが、同年代のITエンジニア達よ、キレないでくれ。失敗や過去を認める事こそ新しい再生の足掛かりだと俺はこの年にもなると考える様になった。

■ 懺悔その一　「すまん、本当は俺たちの世代、全然技術力も何もかもそんなに能力なかった。」

まずこれを見てほしい

https://qlosawa.sakura.ne.jp/morphy/index.html

https://ascii.jp/elem/000/000/331/331887/

所謂モルフィーワン事件として記憶されているプロジェクトなんだが、

財務・経営・技術力・現実感、社会常識、すべてが不足しているとわかると思う。このレベルならXにいる怪しいITゴロを集めて作らせてももう少しマトモな健闘をすると思う。

「事後孔明だ！」「後だしじゃんけんだ！」とブチ切れられそうだが、これを見た20代、30代のエンジニア諸君、どう思うかね。

たぶん、君たちがやれば実機販売までは恐らくこぎつけられていた。こんな程度のプロジェクト、2010年初頭の深センでだって恐らく成功していただろう。

これが、40代エンジニア世代の黒歴史だったりする。

2000年代のIT系まとめサイト等のコメント欄や記事を見てみよう

「いつまでも開発だけやってられないぞ、営業かPMもやってもらわないと…」と上司に言われてブチ切れて机を蹴り倒して会社辞めた、という今のフレッシュ層IT業界の価値観で言えば正気を疑うような蛮行を、周りが勝算までして肯定しているという狂った光景がデジタルタトゥーとして残っているのを見かけるであろう。

なんだったら、ここの2000年代のテック系ランクイン記事を見ればいい、とんでもなくレベルが低い。時代性を加味しても、自慢だったプログラミングスキルは話にならない。

そりゃそうだろう、俺たちの世代からだからだ、C言語に挫折してもほかの簡単言語で仕事ができるようになったのは。ツールの発達によって、それこそ馬鹿が適当に入れてもマシン側が修正して出力してくれるほどになった時代に助けられていたのが実態だったのだ…

あとこのモルフィーワン騒動を見ればわかるが、異様なまでにハード関連に俺たちの世代は憎しみを持っていた。

確かに、あの時代は「ソフトウェアはハードのおまけ」という様な上の価値観に反発をしていた、実態を理解しようとせず、俺たちの世代特有の他責思想で問題を矮小化してしまっていた。

その結果論理設計しかできない、実機がモックも作れないという「やるなら軍師」系がデフォになってしまった。

「アキハバラにいるハードにもソフトにも通信機材に強いテック系オタク」なんて幻想は、アニメやゲームの中の神話に昇華されてしまっている。これも俺たちの世代のついた壮大な嘘の一つだ…

■ 懺悔その二　「すまん、ホントは俺達の功績っていう様な技術全部、散々憎んで叩いてた一つ上の世代のプロダクトだった」

「もう聞き飽きたよ」と若いエンジニア達がいう念仏の様に言われるかもしれないが、例えば俺達40代のエンジニアの功績となっているP2P(所謂Winnyとか)だが、

あれを暇つぶしの片手間に開発した金子博士、普通にバブル世代だし、生まれついてのスーパー情報科学エリート家庭の英才教育とスーパーエリートキャリアを積んだ一般化できないスペシャルパーソンだった。

寧ろ俺達40代のエンジニア世代がP2Pをエロゲの違〇ダウンロードや、特化型マルウ〇アで悪用なんかしたせいで、警察の捜査資料流出などのお上に喧嘩売る事件を起こしまくったとか社会問題になり、その人身御供に金子博士というスーパーエリートのキャリアと命を身代わりになってしまったのが実態だった。

実のところ「日本のITは既得権益に潰された、金子博士がいい例だ」なんていうXとかで流れてる言説、あれ思いっきりデマなんだ…実態は金子博士が暇つぶしの片手間で作ったものを俺たちの世代が悪用しまくった結果、金子博士が目つけられて捕まったというのが本当なんだ…

日本のエンタメIPを方向づけたエロゲ黄金期！というのもそうだ

極一部を除いて、当時名作を作りまくって、今でもゲーム業界の最前線でソシャゲ界隈などで戦ってるメーカーやクリエイター、

全部普通に40代じゃなくてその一つ上のバブル世代ばかりなんだ…

■ アリスの懺悔…

本当に申し訳ない。

老兵は己の失敗を引き受けて潔く舞台から降りればいいだけなんだが、俺たちにはそんなことできない。

他に食べていく方法を知らないし、ネット空間全体が俺達の居場所じゃなくて肩身が狭い思いをしているだけでも気が狂いそうな程嫌になるし、実際それで病んで統失化してる俺達と同世代がうろついている様になってるのも、全部社会や当時の上の世代の責任じゃなくて

100％俺たちの世代の能力不足による自業自得だとわかってる。だけど俺達はプライドが高いから、振り上げたこぶしを下ろして負けを認められないんだ…負けを認めたらそれはもう死と同義だから…

そんなわけで、どうか俺達の世代のエンジニアがXで今日も妄言喚いていても、生暖かい目で見守ってほしい、そして若いエンジニア達は、正しい歴史認識を持って再び日本のIT業界を盛り上げていってほしい

おじさんからはそれだけを伝えたかった…

MEMO:

• モルフィー企画の代表だった「とよぞう」氏は2000年時点で31歳だった模様
• つまり、2026年現在だと60歳前後
• この時点で40代のエンジニアとは関係がない

(2026/08/04)

AIの使い方を学ぶ前に、まずソフトウェア工学を

• AIの使い方を学ぶ前に、まずソフトウェア工学を | SIOS Tech Lab

要約:

■ 1. 本稿の主張

• AIの使い方より先にソフトウェア工学を理解すべき:
  • AIにテストコードを書かせる例で説明する
  • AIは高速にテストコードを書くが、テスト理論を理解していないとバグを見逃すテストを書かせてしまう

■ 2. テスト理論の基礎

• ブラックボックステストとは:
  • コードの中身を見ず、仕様（入力と出力）だけを基準にテストする方法
  • 「入力に対し仕様どおりの結果が返るか」を確認する
  • 境界値分析や同値分割はこちらに含まれる技法
• ホワイトボックステストとは:
  • コードの内部構造（分岐、ループ、処理経路）を見てテストする方法
  • 「if文のtrue側とfalse側の両方を通したか」を確認する
  • 通過度合いはカバレッジという数値で測定できる
• 理論上の核心的な分離:
  • ホワイトボックスであっても、コードを基準にしてよいのはテストの経路選択のみ
  • 結果が正しいかどうかの判定（期待値）は必ず仕様から立てる必要がある
  • コードの挙動をそのまま正解とすると、バグごとテストが追認されてしまう

■ 3. 検証に使った題材コード

• 料金計算関数の仕様:
  • 10,000円以上は10%オフ、会員はさらに5%オフ
• 実装に仕込まれた問題:
  • 仕様は「以上（>=）」だが、実装は「超（>）」になっている境界値バグ
  • 仕様書に記載のない負数チェックの分岐が実装者により独自に追加されている

■ 4. 失敗例:理論を意識せずにAIへ指示した場合

• 与えた指示:
  • 「このコードのテストを書いて。カバレッジ100%にして」という素朴な依頼
• AIが生成したテストの問題点:
  • AIはコードを読んで期待値を逆算する
  • 10,000円ちょうどのケースについて「コード上は>10000に該当しないため割引なし」と解釈し、バグの挙動をそのまま正解としてテストに固定する
  • 負数チェックの分岐についても、コードにある挙動をそのまま期待値としてしまう
• 実行結果:
  • 4件のテストが全てパスし、分岐カバレッジも100%となる
  • 数字上は完璧に見えるが、境界値バグの検出はゼロである
  • 指標がすべて良好であるため、この見逃しに気づく手段がない

■ 5. 成功例:テスト理論を踏まえてAIへ指示した場合

• プロンプトの設計方針:
  • 「経路はコードから選び、期待値は仕様から導く」という分離を指示に落とし込む
  • カバレッジ設計はソースコードの全分岐・例外パスを洗い出して行う
  • 期待値設計は仕様書のみを参照し、ソースコードの出力を期待値に流用することを禁止する
  • 境界値分析を適用し、境界（10,000円）の直前・ちょうど・直後を必ず試す
  • 仕様書に記載がなく期待値を判断できないケースは、期待値を書かず「要確認」として質問リストに出すよう指示する
  • 各テストには通す分岐の根拠と期待値の根拠をコメントで明記させる
• 実行結果:
  • 境界値10,000円ちょうどのテストが失敗し、バグ検出に成功する
  • 分岐カバレッジは87%にとどまり、負数チェックの分岐が未達となる
  • AIは負数分岐について期待値をでっち上げず、「負の金額の仕様はどうなっているか」という質問として報告する
  • カバレッジの未達がそのまま仕様書の記載漏れの発見につながっている

■ 6. 両者の比較

• 素朴なプロンプトの結果:
  • テスト結果は4件パスで全て緑
  • カバレッジは100%
  • 境界値バグは追認され見逃される
  • 仕様にない分岐は期待値がでっち上げられる
• 理論に基づくプロンプトの結果:
  • テスト結果は1件失敗し、バグが検出される
  • カバレッジは87%にとどまり、これは仕様漏れの兆候である
  • 境界値バグが検出される
  • 仕様にない分岐は要確認として報告される
• 逆説的な結論:
  • 数字だけ見れば失敗例のほうが良く、成功例のほうが悪い
  • しかし健全なのは数字が悪く見える成功例のほうである

■ 7. AIの使い方よりソフトウェア工学が重要だという結論

• 2つのプロンプトの差の正体:
  • 差はAIの使い方のテクニックではなく、テスト理論を知っているかどうかの差である
  • 「経路はコードから、期待値は仕様から」も「境界のちょうどの値を試す」も、いずれも従来からあるテスト理論に基づく
• 理論を知らないことの制約:
  • 境界値分析を知らなければ、「10,000円ちょうどを試す」という発想自体がプロンプトに出てこない
  • AIは指示された観点しか網羅しないため、観点を出せない人はプロンプトの書き方を工夫しても差を埋められない
• AI活用ノウハウとソフトウェア工学の関係:
  • AIの使い方講座やスライド作成術のような情報は有用であり、業務効率を大きく向上させる
  • しかしソフトウェア開発者にとって重要なのはソフトウェア開発の基本的な理論である
  • 「このコードのテストで何を検証すべきか」という問いは、聞く側に理論がなければそもそも正しい質問にならない
• AIと人間への指示の共通性:
  • AIに指示を出すことと人間に指示を出すことは本質的に同じである
  • 後輩に「このコードのテスト書いといて」とだけ伝えた場合も同様の失敗が起こり得る
  • 指示する側が中身を理解していなければ、きちんと伝えることはできない
• 結論:
  • AIはテストコードを書く速度を劇的に向上させた
  • だからこそ「何を検証すべきか」を決める側の理論、すなわちソフトウェア工学の価値はむしろ上がっている
  • AI時代に学ぶべきものを問われれば、ソフトウェア工学だと答える
  • いつの時代でも基本が重要である

(2026/08/04)

Octane — React's programming model, compiled

• Octane — React's programming model, compiled

要約:

■ 1. Octaneの概要

• Octaneとは:
  • Reactのプログラミングモデルをコンパイルする後継フレームワーク
  • Infernoの後継であり、パフォーマンス最優先という目標を引き継ぐ
  • Reactのhooks、Suspense、actionsを事前コンパイルする
  • 仮想DOMを持たない
  • hooksのルールを持たない
  • 依存配列を手動管理する必要がなく、コンパイラがコードの参照先を解析する

■ 2. 主な特徴

• hooksのルール撤廃:
  • 依存配列とhooksのルールが不要
  • コンパイラがeffect、memo、callbackが実際に使用する値を追跡する
  • hooksを条件分岐や早期returnの内側に置ける
• 非同期処理の改善:
  • 独立したuse()呼び出しは、木構造を降りながら順番にサスペンドするのではなく同時に開始する
  • ネストしたfetchは早期にウォームアップされる
  • ストリーミングSSRは各バウンダリを準備でき次第送信する
• 仮想DOMの不使用:
  • テンプレートはクローンされたノードと直接的なDOM書き込みにコンパイルされる
  • keyed @forリストは最小限のノード移動で済む
  • 通常の.tsxはそのまま動作し、.tsrxへコンポーネント単位で段階的に移行できる
• 従来モデルとの親和性:
  • hooks、memo、context、portals、transitions、actions、controlled forms、Suspenseは期待通りに動作する
  • イベントはネイティブであり、refsは単なるpropsとして扱われる
  • 53種類のファーストパーティ製バインディングが既存ライブラリをカバーする
• 目指す体験:
  • 速さはアプリの感じ方であるべきで、新しい思考法を強いるものではないとする立場

■ 3. Octaneへ移行する理由

• Octaneコンポーネントの正体:
  • 既存のReactコンポーネントと同じく、hooks・props・contextを使うただの関数
  • Reactを知っていればOctaneも理解できる
  • 状態の所在やデータフローに関する既存の知識がそのまま通用する
• 移行方法:
  • アプリ全体を書き直す必要はない
  • 既存のTSXを保持しつつ、コンポーネントを一つずつTSRXへ移行できる
  • コンポーネントの形が移行の前後で変わらないため、AIエージェントによる移行も、新しいリアクティブモデルへの再設計なしに可能

■ 4. signalsを採用しない理由

• signalsに対する評価:
  • signals自体は優れた手段であり、適合する場面ではOctaneアプリ内でも使用可能
  • ただしsignalsを基盤とするフレームワークは、アプリ全体の状態表現・読み取り方法をsignals流に統一してしまう
• Octaneの設計方針:
  • コンポーネントを上から下へ読める、ただの関数のまま保つ
  • 追加の作業はコンパイラ側が担い、コード側に負担をかけない

■ 5. 静かに失敗する落とし穴

• 事前コンパイルゆえの特性:
  • Octaneは事前コンパイルのため、設定ミスは通常エラーにならず、動作が徐々に劣化する形で現れる
• 具体的な落とし穴:
  • 1つのツリー内にランタイムが2つ存在すると、hooksとcontextが静かに壊れる
    • フックの状態はランタイムインスタンスごとにキー管理されているため
  • 素のtscは.tsrxファイルを正しく扱えず誤動作する
  • declare module '*.tsrx'のシムを使うと、自分のコンポーネントの型がanyになる
• 対策:
  • octane doctorというコマンドが、これらの問題に対応する20項目のチェックを提供する

■ 6. OctaneCompatによる段階的移行

• 既存React 19アプリへの導入:
  • 単一のコンポーネントを追加するだけで、コンパイル済みのOctane islandsを既存アプリに組み込める
  • イベントはネイティブかつdelegatedのまま扱われる
  • islandsは通常のuse()で実際のReact contextを読み取れる
  • サーバー側でレンダリングされ、クライアント側でhydrateされる
• 移行の進め方:
  • コンポーネント単位で移行でき、書き直しや一斉切り替えは不要
• 対応範囲の限界:
  • React Server Componentsだけは非対応
  • hooks、Suspense、context、SSRなどそれ以外の機能はすべて引き継がれる

(2026/08/04)

アーキテクチャに限らず意思決定を全部残す「ADR（Any Decision Record）」という文化

• アーキテクチャに限らず意思決定を全部残す「ADR（Any Decision Record）」という文化

要約:

■ 1. Any Decision Recordとは

• 一般的なADRとAnyの違い:
  • 一般的なADRはArchitecture Decision Recordの略で、アーキテクチャに関する意思決定を記録するドキュメント
  • なぜこの技術を選んだか、なぜこの構成にしたかを、決定時のコンテキストとともに残す
  • Dress CodeではAをAnyと読み替え、領域や大小を問わずあらゆる意思決定を記録する文化として運用
• 記録対象の範囲:
  • アーキテクチャ選定に加え、開発プロセスの変更やツール選定、命名方針も記録対象
  • この機能をやらないと決めた理由まで幅広く記録する

■ 2. Anyにした理由

• 意思決定は再構築のための事実:
  • システムをデータ、コード、アーキテクチャの3層に分け、各層に守るべき源泉があると考える
    • データ層の源泉はイベント、手段はEvent Sourcing
    • コード層の源泉は仕様、手段はSDD(仕様駆動開発)
    • アーキテクチャ層の源泉は意思決定、手段はADR
  • データ層ではEvent Sourcingで状態でなく変化を記録し、状態はイベントから再生成できる派生物とみなす
  • コード層ではOpenSpecを用いてSDDを導入し、仕様を源泉としてコードを書く・生成する
  • 同じ原則をアーキテクチャ層に適用すると、現在のアーキテクチャ自体は派生物であり、守るべき源泉はなぜそう作ったかという意思決定
  • 意思決定が失われると、現状の構成は動いているから触れないブラックボックスになっていく
  • ADRからSDD、実装へと上流の事実が実装の根拠になる流れを目指している
  • 機械的に再生成できるわけではないが、この流れがつながれば意思決定から作り直すことが現実的になる
• アーキテクチャ限定というバイアスの排除:
  • アーキテクチャの意思決定を書くものと定義すると、設計以外の開発判断の置き場がなくなる
  • これはADRに書くほどのことかというバイアスが働き、迷った意思決定が記録されずに消えてしまう
  • フォーマットが形式的になりすぎ、読み書きのハードルが上がる問題もあった
  • 対応として、設計以外の開発に関することも含め、あえて雑多に何でも書くことにした
  • ちゃんとしたADRを書こうとする負担を減らし、品質より記録の網羅性を優先する割り切り
• 創業初期からの資産化:
  • ドキュメント運用でよくある悩み:
    • 探せない
    • バラバラ
    • 読まれない
    • 残らない
    • 更新されない
    • 時間がかかる
  • 組織が大きくなってから直すのは困難なため、初期のうちにフォーマットと置き場を統一し文化として定着させることにした
  • 創業期のなぜが後から引けること自体が組織の資産になるという考え

■ 3. 運用方法

• Notionへの集約:
  • ADRはすべてNotionのデータベースに集約し、分類やフォルダ整理は行わない
  • 探索はNotion AIに任せる前提で、人間が探しやすい構造を維持するコストより書き溜めることを優先
• 実際のADRの作り:
  • 判断当時の文脈と結論さえ書けば成立する、意図的にゆるいフォーマット
  • 雑多さが伝わる例:
    • Event Outbox共通基盤に関する検討
    • Compute Savings Plan導入検討
    • Zod v4アップグレード影響調査レポート
    • レビューの心得
  • アーキテクチャの検討からAWSのコスト削減、ライブラリアップグレードの調査、組織寄りの話まで対象領域が雑多
  • レビューの心得というADRの内容:
    • コードレビューに対するチームのマインドセットを言語化したもの
    • Approveはバグがないことの保証ではなく、一緒に対応するという意思表示だという合意
    • 依頼する側が意図や背景、自信のない箇所を添えてレビュワーの負荷を下げるという合意
    • こうした決めごとは口頭やSlackだと流れてしまうため、Anyの枠があるからこそ残せた例
  • 採用状況のプロパティには採用だけでなく不採用、保留もあり、やらないと決めたことも記録する
  • 不採用の理由も口頭では失われるため、できる限り残すようにしている
• 記録量の推移:
  • 約1年半で累計450本を超えた(2026年7月時点)
  • 現在のチーム規模はエンジニア15人、PdM・デザイナー6人
  • 記録ペースの推移:
    • 導入から1年ほどは月に数本
    • 2025年半ばに月10本台に到達
    • 直近3ヶ月は月50〜60本ペースまで増加
  • 文化として回り始めるまでに1年以上かかった
  • ペース向上の背景には、ADRからSDD、実装という流れの定着とADR文化自体の浸透がある
• 週次の共有とフィードバック:
  • 書き溜めたADRは週次の読み合わせで共有しフィードバックし合う
  • 共有がないことを異常とみなし、共有ゼロは意思決定がなかったのではなく記録されなかっただけと考える
  • 書かなかった人を責める目的ではなく、記録の取りこぼしを検知するシグナルとして使う
• 書くきっかけの仕組み化:
  • 意思決定した瞬間にADRを書くのは難しいため、Slackで気になる話題にスタンプを押してストックする運用
  • ストックした話題を雑多に書き貯め、週次で話し合う導線を作っている
  • このストックから起票されたADRはデータベース上で分かるようにしている
  • 現在はこの仕組みがなくてもメンバーが書いてくれるため、以前ほど重宝していない
• LLMによる読み書きの負荷軽減:
  • 書く側は議事録や文書をAIで要約し、ADRの下書きにしている
  • 読む側はAIへの質問で必要な意思決定を引き出し、開発時にコンテキストとして共有することもある
  • 最近はADRの要約を画像生成AIでグラフィックレコーディング風の1枚画像にまとめる運用もテンプレートに組み込んだ
  • 雑多に書いてもAIが探して要約してくれるという前提が、Anyという割り切りを成立させている

■ 4. 得られた効果

• なぜそうなったかが後から追える:
  • コードや構成の経緯が分からなくなったとき、当時の意思決定に立ち返れる
  • 考古学的な調査ではなくエンジニアリングができる状態を保てている
• 開発タスク側からADRが寄ってくる:
  • バックログのタスクページのテンプレートに関連ADRピックアップというセクションを設けている
  • Notion AIがタスク内容から関連しそうな過去のADRを自動で引っ張ってくる仕組み
  • 書いた当時は誰が読むのかと思っていたADRが後で役立つこともある
• オンボーディングの質問がNotion AIで片付く:
  • 新メンバーからのなぜこうなっているのかという質問の多くがNotion AIへの質問で解決するようになった
  • 意思決定がすべて残っているため、AIがそれを引いて回答できる
  • AIが古いADRを引いてしまうリスクはあるが、答えの源泉がまったく残っていない状態よりは改善している

■ 5. 残っている課題

• 更新されない問題:
  • 最終更新からの経過日数を可視化して放置を検知しているが、古いADRを直すモチベーションは生まれにくい
  • ADRは本来immutableな時点記録で、変更は新しいADRで置き換えるのが定石
  • 置き換えのADRを書くモチベーション自体も生まれにくく、問題の根は同じ
• 境界の曖昧さ:
  • Anyにしたことで、ある仕様をADRに書くかBacklogに書くか迷う場面が生じている
• 書いた人が報われにくい:
  • ADRの恩恵を受けるのは未来の誰かであり、書いた本人への短期的なリターンが見えにくい
  • 評価や称賛の仕組みとセットで考える必要があり、引き続き試行錯誤中

■ 6. おわりに

• 意思決定を再構築に必要な事実と捉え、アーキテクチャに限らずすべて(Any)残すという考え方
• これによってAI時代に変更し続けられるシステムと、知識が資産になる組織を目指している
• イベントを残す、仕様を残す、意思決定を残すというレイヤーの違いはあっても、事実を源泉として守るという原則は共通している

(2026/08/03)

カンファレンス生態系の変化と CFP の功罪

• カンファレンス生態系の変化と CFP の功罪 | blog.jxck.io

要約:

■ 1. カンファレンス再興の背景

• コロナ後の再興:
  • 一旦縮小したテック系カンファレンスが新しい主催、新しい名前で全国的に再開
  • それ自体は歓迎すべき変化
• 生態系の変質:
  • カンファレンスの生態系はコロナ前とは変わりつつある

■ 2. 勉強会からカンファレンス勃興への流れ

• コロナ前の一般的な流れ:
  • 同じテーマの勉強会に人が集まりコミュニティが育つ
  • コミュニティの集大成としてカンファレンスを開催する
  • カンファレンスはコミュニティの「ハレの舞台」だった
• 主催の実態:
  • 本業の傍らスポンサーを集めギリギリ開催を続ける状態が続いた
  • 徐々にカンファレンス自体に価値が見出された
    • スポンサーが付きやすくなった
    • 会場も借りやすくなった
    • チケットが高くても参加者が集まりやすくなった
• コロナによる断絶:
  • この蓄積は一旦コロナで途絶えた
• コロナ後の新規開催:
  • 勉強会の蓄積を経ずに初手で開催されるカンファレンスが増加
  • スポンサーは依然付くため名前がそれらしければ開催自体は可能
  • 初めての主催者と初めてのスタッフによる新規開催が増えた
  • 登壇者も全て公募になりがち
• コロナ前の登壇構成:
  • コミュニティのメンバーが主体的に登壇することが多かった
  • ゆるい公募枠やLT大会枠も一部用意されていた
  • 基調講演などの大トリは主催の力量による特別ゲスト招致が多かった
  • そうした彩りがカンファレンスの特色として参加者に楽しみにされていた

■ 3. コミュニティの新陳代謝とCFP全面化

• 新陳代謝の課題:
  • 同じメンバーの主催・登壇・参加が続くと外から出来上がった輪に見える
  • 出来上がった輪には新しい人が入りにくい
• 放置した場合の帰結:
  • 新陳代謝がないまま全員が歳を重ねる
  • コミュニティ自体が廃れていく
• 登壇公募の役割:
  • 新しい参加者を迎える入り口の1つとして登壇公募が機能していた
• CFP全面化の経緯:
  • カンファレンスへの応募数がしきい値を超えるようになった
  • 声をかけなくてもある程度定員が埋まるようになった
  • 選考落ちした登壇者から「不公平だ」「選考をすべき」という声が上がった
  • コロナ前も部分的にCFPを導入するカンファレンスはあった
  • コロナ後は「CFPで募集しないのは不公平だ」という暗黙の圧力が強まった
  • 結果として「全てCFPで公募」のスタイルが増えた

■ 4. CFP選考の難しさ

• 文書選考の限界:
  • 「登壇」というライブなものを文書だけで選ぶのは本質的に難しい
  • ボーカリスト募集を自己紹介文だけで選ぶことに似ている
  • 良く書かれたCFPでも当日壇上でどうなるかは分からない
• ブラインド選考の内容:
  • 公平性を重視し顔も名前も参考にしない
  • 過去の登壇実績も参考にしない
  • 提出された文面だけでセッションを採択せざるを得ない
• 「CFP大喜利」化:
  • CFPの文章力さえ高ければ登壇経験の有無を問わず通ってしまう
  • 筆者自身はCFP大喜利が得意で、提出したものはほぼ全て通っている
• 選考委員の悩み:
  • 「公平な選考のため」という名目で選考委員が集められている
  • しかし何を基準に選べばよいか毎回悩んでいる
• 品質担保の困難:
  • 「なんの発表か」は分かっても「どんな発表か」は分からない
  • その状態でセッションの品質を担保するのはかなり難しい
  • それ自体に問題があるかは観客の判断に委ねられる

■ 5. カンファレンスの品質問題

• 参加者の「お客様」化:
  • チケットが有料だと参加者は「お客様」として振る舞いやすくなる
  • 実態は会場代の割り勘に近い構図でも客として扱われがち
• 参加者の負担の大きさ:
  • 休みを潰し高額なチケットを払い不便な場所まで移動している
  • そうした「客」が低品質な登壇を聞くと不満が主催へのクレームとなる
• 「クオリティが低い」の内実:
  • 単に緊張して話せない、デモが失敗するといった話に限らない
  • 本当に話したいことがあるのか疑わしい登壇が聴衆にフラストレーションを与える
  • 大きなカンファレンス登壇という実績解除だけが目的に見える登壇も同様
  • AIでCFP大喜利を通せるようになった今、この問題は無視できなくなった
• 評判への影響:
  • 質の低いセッションで下がるのは登壇者以上にカンファレンス自体の評判
  • 現行のCFP運用にはこれを未然に防ぐ手段がない

■ 6. CFP運用の課題

• リードタイムの長さ:
  • 提出から本番までが半年程度のリードタイムになっている
  • 募集・選考・採択・告知の工程を考えると運用上の短縮は難しい
  • 変化の速い時代では来週の状況すら見通せない
  • 半年後に今と同じ熱量で話せるCFPを用意する難易度はかなり高い
• テーマ選定の難しさ:
  • ツールやサービスに紐づく話は本番までにサービス終了している可能性がある
  • 仕事の事例紹介も本番時点では本人が転職しているかもしれない
  • その会社自体が存続しているかも分からない
  • 普遍的なテーマに寄ると「要はバランス」のような結論に陥りがち
• CFP募集の乱立:
  • カンファレンスの乱立に伴いCFP募集も乱立している
  • フロントエンド分野だけでも並行して3〜4のカンファレンスがCFPを募集
  • 参加者だけでなく登壇者も奪い合いになっている
  • 同じCFPを複数のカンファレンスに使い回す例が増えている
• タイムテーブルへの影響:
  • 結果としてタイムテーブルは「CFPが通りそうなネタ」で埋まる
  • 加えて「選考は通ったが品質が未知数なネタ」でも埋まっていく

■ 7. 「ここでしか聴けないセッション」の行方

• 従来のブッキング:
  • 主催が「出て欲しい」と依頼して集める形が多く特に基調講演で顕著だった
  • 実績のある人物に依頼する、実績に頼ったブッキングもあった
  • 普段表舞台に出ずCFPも出さないような人を引きずり出せるかは主催の力量次第
• ブッキングがもたらす好循環:
  • そのトークを聴きたくて人が集まり来場者の満足度が上がる
  • チケットが売れ次のスポンサー獲得につながる
  • 結果としてカンファレンスの開催自体が安定していく
• コミュニティ経由の入れ替え:
  • CFPやLT大会での無名登壇者のトークが偶然目に留まることがある
  • 懇親会での評判をきっかけにコミュニティが成長する
  • そうしてセッションの顔ぶれが初めて入れ替わっていく
  • カンファレンスの価値はセッション自体だけでなく壇上を降りた場にもあった
• CFP偏重の弊害:
  • ブッキングのツテがない、または公平性のためCFPのみに頼る主催は横並びで似通っていく
  • お客様化した参加者は録画とスライドで済むと判断しがちになる
  • その結果チケットが売れずドタキャンも増え開催が苦しくなる
  • 本業の傍ら開催する主催のモチベーション維持が難しくなる
  • こうした事態は既に起こり始めている

■ 8. 初心者のチャンスは

• CFPを巡る反論:
  • 「初心者はどこで練習するのか」「いつも同じメンツだ」という声が上がる
  • コミュニティにとって新陳代謝は重要で新しい人は歓迎されるべきとされる
• 一発本番である必要はない:
  • 小さい勉強会の5分枠でたどたどしく発表しても誰も否定しない
  • 少人数の場で場数を踏みながら登壇を学んでからでも遅くはない
• 登壇を通じて学ぶべき実務知識:
  • 事前の接続テストが必要なこと
  • デモ失敗に備えた録画の用意が必要なこと
  • 想定以上に緊張し話す内容を忘れてしまうこと
  • 時間超過が主催や他の登壇者の迷惑になること
  • 自分がウケると思う内容と実際の評価が一致しないことがあること
  • 短い発表の裏に多くの人の労力がかかっていること
• 一発ぶっつけ登壇の限界:
  • AI生成のCFP大喜利だけで通った数百人規模での初登壇が満足のいくものになる可能性は低い
• 本質的な問題の所在:
  • 問題はCFP公募が誰にでも開かれているかどうかではない
  • 登壇者が育つ場が失われたままカンファレンスだけが勃興していることにある
• 品質担保の必要性:
  • 全てが初心者の練習セッションになれば人が集まらなくなる恐れがある
  • ネガティブなイメージが付く可能性もある
  • 人が集まらなければ赤字になりスポンサーも付かないかもしれない
  • その責任を取る準備ができた状態で新しいカンファレンスが立つとは思えない
  • 健全に続けるには登壇者の質をある程度担保する必要がある
  • 本来それを担っていたのが「コミュニティを育てる場」としての勉強会だった

■ 9. 勉強会のシュリンク

• タイパの悪さ:
  • 少人数の勉強会に業後の時間を割くのはタイパが悪いと見なされがち
  • カンファレンスは休みが業務扱いになりチケットも会社申請できる場合がある
  • 参加側にとってカンファレンスの方がタイパが良い
• 主催側の負担:
  • 人も集まりにくく場所の確保も難しく主催自身も忙しい
  • それでも続けたい人たちによってコミュニティが形成されてきた
  • コミュニティ形成は地味でタイパの悪い作業
• 観光客的発想への警鐘:
  • ハレの場だけに注目し楽しみたいという発想は観光客の発想に近い
• お客様化によるトラブル:
  • 「金を払っているのだから」という態度に起因するトラブルが後を絶たない
    • 協賛企業提供のピザを提供前に食い荒らして帰る参加者がいる
    • 懇親会でマルチまがいの勧誘行為をする参加者がいる
    • 女性参加者につきまとう参加者がいる
    • 受付でスタッフを恫喝する参加者がいる
  • コミュニティが機能していた頃、参加者はお客様ではなく主体的な一員だった
• 筆者の対応方針:
  • 有料イベントや懇親会をやらないのはコストを削り継続可能にするため
• 筆者の今年の実践:
  • 今年はカンファレンス開催を控え小さい勉強会の毎月開催を再開した
    • 1月 #tpac_study
    • 2月 Web技術年末試験2024
    • 3月 #temporal_study
    • 4月 #縦書き_study
    • 5月 #rich_text_editor_study
    • 6月 #webfont_study
  • 7月は初心者歓迎でLTのみを行う会を開催した
  • そこで飛び入りで「LTとは何か」というLTを行った
  • 最近こうしたLTができる場が再び増え始めている
  • 月1回の勉強会と半年に1回程度のLT会を続けたいと考えている
  • 続けられるかどうかは毎回終わるたびに分からないと感じている

■ 10. CFPを無くすべきか

• CFPの部分的活用:
  • CFPを完全に無くす必要はない
  • 初心者歓迎のLT枠を設けて受け入れる取り組みはコロナ前から存在する
  • 複数トラックのうち1トラックだけCFPに充てるような采配も一案
• 主催の主体性:
  • 全セッションをCFP公募とブラインド選考で埋めるべきという思い込みは不要
  • 面白いと思う人物を主催が直接口説いて依頼する方がよい
  • それがカンファレンスの特色となり参加者が来場する理由になる
  • CFP経由で偶然の才能に出会える可能性も残る
  • スライド発表形式に限らずパネルディスカッションやLT大会、OST、AMAなど多様な形式を組み合わせる方がよい
• 主催采配の難しさ:
  • CFP公募のみで作るよりも主催が采配する方がはるかに難しく手間がかかる
• 外野の声への対応:
  • 「CFPでないのは不公平だ」という外部の意見が出ることもある
  • そうした声は継続責任を負わない観光客的なノイズである
  • コミュニティとしての主体性を持つ人たちが納得できる形を続ければよい
  • 主催はもっとわがままに「自分だからできるカンファレンス」を追求してよい
• ノウハウ継承の断絶:
  • こうしたノウハウの継承がコロナで途絶えたことが現状につながっている

■ 11. 地方カンファレンスの事情

• 東京との違い:
  • 地方では東京のように容易に人が集まらない場所も多い
  • それでも地域を盛り上げようと開催を続ける主催が多い
  • 車で2時間かけて集まる勉強会の例もある
• 地方に合うモデル:
  • 地方ではハレの場としてのカンファレンスに一堂に会しコミュニティを形成するモデルの方が合っている
  • 一度集まり体感することでオンラインのやり取りも活性化する
• 東京からの招致:
  • CFPが集まらずセッションを埋めるのが難しい場合、東京からエンジニアを招致することもある
  • 招致本人が乗り気ならどんどん行うべき
  • それによりカンファレンスがブートストラップされコミュニティが育てば問題ない
• 批判への反応:
  • 「東京の人ばかりだ」という批判は来もしない観光客からのヤジに過ぎない
  • 表面的なノイズを気にしても良い方向に進むとは限らない
• 招致に応じるエンジニアの姿勢:
  • 都合が合えば赴き観光もするがきちんとトークもする
  • 旅費以外の見返りは求めないことが多い
• 筆者の申し出:
  • ツテがなく困っている場合は声をかけてくれれば紹介もできる

■ 12. 主催コミュニティと開催ノウハウ

• 「100人の壁」:
  • 参加者が100人を超えると企業会議室での省エネ開催が難しくなる
  • 有料会場を確保するためスポンサーから資金を集める必要が生じる
  • そのために法人を立てることになる
  • 資金があれば海外ゲストの招致が可能になる
  • 配信や通訳の需要も出てくる
  • スポンサー枠やブースの用意でさらに人員とスペースが必要になる
  • こうして規模が拡大していく
• モデルの変質:
  • 「コミュニティのコアメンバーが主催しメンバーが参加する」モデルから離れる
  • 「誰かが開催した興行に有料チケットで参加する客」のモデルへと距離が開く
• 運営上の弊害:
  • 考えることが増え正常処理だけで精一杯になる
  • 処理できない例外がたくさん残る
  • 「台風と興行中止保険」や「法人格と個人情報」など知っていれば防げたミスで打撃を受ける主催者もいる
  • コロナ後の経験だけを基準に「カンファレンスはこうあるべき」という価値観に固まる人もいる
  • 一方で場所が借りられず勉強会開催に困っている人もいる
• ノウハウ共有の取り組み:
  • こうした人たちが緩く情報交換し助け合うことを目的に「カンファレンス開催ノウハウ」を公開した
  • 本当に伝えたかったのは開催方法以前に「コミュニティでカンファレンスをやるとはどういうことか」という部分
  • これもコミュニティの1つの形だと筆者は考えている

■ 13. Outro

• 最近はカンファレンスが飽和し小さい勉強会が少しずつ戻り始めている
• タイパの悪い勉強会がテック界隈にどの程度残り続けられるかは筆者にも分からない
• 筆者はコロナ前にコミュニティに育ててもらった最後の世代だと自認している
• 恩返しとして時代遅れな勉強会やコミュニティ主体のカンファレンスをやりたい人がいれば協力を惜しまない

(2026/08/02)

ＮＴＴから「シイタケ市場より小さい」ソフト市場に転職、「ウインドウズ９５」基本設計手がけた「伝説の技術者」

• ＮＴＴから「シイタケ市場より小さい」ソフト市場に転職、「ウインドウズ９５」基本設計手がけた「伝説の技術者」 : 読売新聞

要約:

■ 1. 中島聡の経歴概要

• 中島聡はウィンドウズ95の基本設計を手がけた「伝説のソフトウェア技術者」
• 早大在学中からプログラマーとして名をはせた
  • パソコン上で設計図の図面を書ける世界初のソフトを開発
• 1985年に大学院を修了しＮＴＴに就職
• 1980年代にマイクロソフト副社長として活躍した西和彦と入れ替わるようにマイクロソフトに入社した人物

■ 2. ＮＴＴ入社とその実態への失望

• 就職先選び:
  • 当時、理系大学院で成績上位者はＮＴＴの研究所に入るのが「エリートコース」とされていた
  • 中島も当然の流れとしてＮＴＴに入社
• ＮＴＴでのＯＳ開発の実態:
  • ソフトの設計書だけを作成し、プログラムは下請け会社に丸投げする体制だった
  • 設計とプログラムは一体でやる方が効率的だと考えていた
  • 自分でプログラムを書けない状況に不満を募らせた

■ 3. マイクロソフトへの転職

• 転職のきっかけ:
  • かつてアルバイトをしていたアスキーの旧知の幹部がマイクロソフト日本法人を設立したことを知る
  • 中島自身が幹部に直談判し転職を決めた
  • ＮＴＴ入社から１年後の転職だった
• 当時の状況:
  • マイクロソフトは先行きの分からない小さな外資系ベンチャーだった
  • 日本のソフト市場は黎明期で「シイタケ市場より小さい」と言われていた
  • エリートコースを捨てての転職に周囲はあきれた
  • 中島本人は冒険とは思わず、自分でプログラムを書ける環境を求めていた

■ 4. 次世代ＯＳ開発への抜擢

• 米国本社への移籍:
  • マイクロソフト日本法人入社から３年後、米国本社に移籍
  • 配属された小さなチームで次世代ＯＳの試作ソフト開発を任された
• 試作ソフトの開発と評価:
  • 「パソコンを誰もが使えるようにするにはどんなＯＳがいいのか」という発想で半年ほどかけて設計
  • 社内で高く評価され、マイクロソフトはこれを基に次世代ＯＳを開発することを決定
  • イベントでこの試作品が「次世代ＯＳ」として発表された
• 開発体制の変化:
  • 当初７人足らずだった弱小チームが一気に４００人規模に増強された
  • 中島もその一員として次世代ＯＳの設計を手がけることになった

(2026/08/01)

ビル・ゲイツ氏や孫正義氏と対立、半導体やネットで「デジタル敗戦」…再起かけ技術者育成へ...

• ビル・ゲイツ氏や孫正義氏と対立、半導体やネットで「デジタル敗戦」…再起かけ技術者育成へ「もうひと勝負」 : 読売新聞

要約:

■ 1. 西和彦とビル・ゲイツの対立の背景

• 西和彦とビル・ゲイツは考え方の近さから「二卵性双生児」と言われた関係だった
• 両者の関係を決定的に悪化させたのは半導体を巡る路線対立だった
  • 西はパソコンの基幹部品である半導体がソフト技術者にとって使い勝手が悪いと不満を抱いていた
  • 西はマイクロソフトが自ら半導体を開発すべきだと訴えた
  • ゲイツは当時同盟関係にあった米半導体大手インテルへの配慮もあり自社での半導体開発に否定的だった
• 半導体を巡る関係のこじれは修復不能になり、西は1986年にマイクロソフトを去った

■ 2. アスキーでの半導体開発と技術者育成への問題意識

• 失意の西が自ら創業したアスキーで心血を注いだのが半導体の開発だった
  • インテルを超える国産半導体を目指した
  • アスキーと三井物産で共同出資会社を設立し半導体開発に乗り出した
• 西はそこで技術者という壁にぶつかった
  • 技術者の質、層の厚さが日本と米国では全く違ったと振り返っている
  • コンピューター科学が発達する米国企業では博士号取得者が最先端の半導体を設計していた
  • 日本ではそうした専門知識が軽視されていた
  • 西は日本は米国のまねしかできない、教育から見直さなければならないと痛感したという
• ゲイツは天才として名高く、西もパソコン革命を先導した天才ともてはやされた
• 西は当時流行語だった新人類の代表格とされた

■ 3. 孫正義との関係とMSX規格を巡る対立

• 西と生まれた年が1年しか違わない新人類として孫正義がいた
  • 孫は当時パソコンソフト流通大手・日本ソフトバンクのトップとして業界で急速に存在感を高めつつあった
• パソコン業界では西が作る天才、孫が売る神童と評され、両者は互いをライバルとして強く意識していた
• 1983年、西が打ち出したパソコンの世界共通規格MSXを巡り両者が正面からぶつかり合った
  • 孫はソフト会社から利用料を取るのはおかしいと強く反対した
  • 孫は独自の統一規格の策定に動き出しMSXに対抗する姿勢を鮮明にした
• 天才と神童の対立に慌てたパソコンメーカー幹部が事態の収拾に乗り出した
  • 西と孫はホテルオークラの一室で話し合った
  • 西が利用料などで譲歩し、孫が対抗規格を取り下げることで対立は沈静化した
• この騒動は2人の若手経営者がパソコン業界を動かしていることを世間に強く印象づけた

■ 4. その後の対照的な歩み

• 西と孫はその後曲折がありながらも対照的な道を歩んだ
• 西は90年代、アスキーが経営難に陥ったことで半導体の開発を断念した
  • 肝いりだったインターネット事業も撤退に追い込まれた
  • 次第にデジタル産業の表舞台から遠ざかっていった
• 孫は95年にヤフーを設立しインターネット革命の波に乗りIT業界の旗手として存在感を増していった
  • 米大統領のドナルド・トランプらも一目置く世界的なビジネスマンになった
• 西は孫への思いを、後ろからものすごいスピードでスポーツカーが来てあっという間に追い抜いていったという感じで、事故を起こしたら大変だねとしか思わないと語る
  • お金を稼ぐのが好きな孫と技術者堅気の自分は違うと述べている

■ 5. 現在の技術者育成への取り組み

• パソコン時代の寵児だった西は現在70歳である
• やる気は満々だがもう若くはないという西が今もうひと勝負かけたいと情熱を燃やすのが技術者の育成である
  • 私財を投じ、デジタルや半導体の技術者を育成する日本先端工科大学（仮称）の設立に向けた準備を神奈川県小田原市で進めている
• 学校案内には当時、日本企業の実力は間違いなく世界のトップレベルにあり、グーグルもアマゾンも生まれる前、日本は世界に名だたるIT先進国だったとの一節がある
  • その後、日本企業は半導体でもコンピューターでもインターネットの分野でもずるずると存在感を失っていったと続けている
• 西はデジタル敗戦からの再起をまだ諦めていない
  • 西が大学時代から世界初のソフトやハードの開発に情熱を燃やしたように、やる気をうまく育めば世界で活躍できる人材はたくさんいると述べている

(2026/08/01)

「零戦だって作り直している」的中した秘策、「ＯＳの巨人」成し遂げた２人に生まれた大きな違い

• 「零戦だって作り直している」的中した秘策、「ＯＳの巨人」成し遂げた２人に生まれた大きな違い : 読売新聞

要約:

■ 1. 西和彦によるOS開発の主張

• 草創期のマイクロソフトでOS開発の是非が議論になった際、西和彦は開発を強く主張した
• 西はいずれOSの上にワープロや計算機が載り、OSがパソコン全体のあり方を決める時代が来ると考えていた
• IBMの意向通り短期間でOSを開発することは容易ではなかった
• 西には秘策があった:
  • 米国の別会社が開発していたパソコン用OSの権利を買い、マイクロソフトで改良する案
  • この方法であればIBMの期限に間に合わせられると考えた
• 西は「零戦だって作り直している、とりあえずそれで作って何度でも作り直せばいい」と説得した
• ゲイツらはこの説得を受けてOSの自社開発を決断し「MS-DOS」を完成させた

■ 2. MS-DOSの普及とマイクロソフトの拡大

• MS-DOSはIBMのパソコンに搭載され爆発的に普及した
• マイクロソフトはOSで世界標準の座を獲得した
• MS-DOSは後の「ウィンドウズ」へと受け継がれた
• 西の主張をきっかけに、マイクロソフトは「OSの巨人」としての道のりを歩むようになった
• 1980年代、ゲイツと西はパソコンメーカーにOSを供給することでマイクロソフトの「ソフトウェア帝国」を拡大した
• 1983年、西が創業したアスキーとマイクロソフトはパソコンの世界共通規格「MSX」を打ち出し世界的に注目を集めた
• 2人の蜜月関係がこうした協業を支えていた

■ 3. 2025年設立50周年夕食会でのやりとり

• 2025年4月、マイクロソフト設立50周年の夕食会が開かれた
• 夕食会の前、西は昔の写真を見ながらビル・ゲイツに語りかけた
• 西の発言内容:
  • 自身はアップルのスマホを使わず、米国モトローラのスマホを使っている
  • そのためOSはアンドロイドになっている
  • このスマホを触るたびになぜOSがウィンドウズじゃないのかと思う
  • 自分がそう思うのだから、ゲイツはもっとつらいはずだと述べた
• ゲイツは「そうだな」と悔しそうにうなずいたという

■ 4. 西とゲイツの違いと決別の火種

• 西とゲイツは「二卵性双生児」と呼ばれるほど考え方が似ていた
• パソコンに関しては一つの大きな違いがあった:
  • 西はハードとソフトの両方を組み合わせ「理想のパソコン」を作ることに関心があった
  • ゲイツは「ソフトに集中すべきだ」という考えでハードには興味を示さなかった
• この方向性の違いが後に2人の関係を修復不能な状態まで悪化させることになった
• 火種になったのは「半導体」だった

(2026/08/01)

巨人ＩＢＭからの打診に頭抱えるビル・ゲイツ氏に「絶対にやるべきだ」と叫んだ…ウィンドウズ開発の...

• 巨人ＩＢＭからの打診に頭抱えるビル・ゲイツ氏に「絶対にやるべきだ」と叫んだ…ウィンドウズ開発のきっかけを作った日本人 : 読売新聞

要約:

■ 1. ウィンドウズとマイクロソフトの現状

• パソコン用基本ソフト（OS）のウィンドウズは国内シェア9割を占める
• 開発元の米マイクロソフトは巨大IT企業の座に押し上げられ、パソコンOSの主役であり続けている
• 同社の隆盛は1人の日本人の活躍がなければ生まれなかった可能性がある

■ 2. マイクロソフト設立50周年式典

• 2025年4月、米シアトル近郊でマイクロソフト設立50周年の式典が開催された
• 招待されたのはアスキー創業者・西和彦
  • 西はかつてパソコンソフトや雑誌を手がけ、パソコン時代の寵児だった人物
• 式典に合わせ、ゆかりの人物を招いた夕食会が開催された
  • 集まったのは共同創業者のビル・ゲイツ、CEOのサティア・ナデラら歴代のトップや功労者ら約50人
  • 西の席は1番テーブルに設けられ、VIP待遇を受けた
  • 理由は、同社がOSを開発するきっかけを作ったのが西だったため

■ 3. 1980年 IBMからの打診

• 1980年、ゲイツ、共同創業者のポール・アレン、スティーブ・バルマー（後のCEO）、副社長だった西の4人がマイクロソフト本社の社長室で向き合った
  • 当時マイクロソフトは設立から5年の新興企業で、重大な決断を迫られていた
• 大型コンピューターで世界の覇権を握っていたIBMは、個人向けコンピューター（パソコン）の開発をひそかに進めていた
  • IBMにはOS開発を任せようとしていた意中のソフト会社があったが、交渉は平行線に終わった
  • 代わってマイクロソフトにOSを提供できないか打診してきた
• マイクロソフトにとって、自社のソフトをパソコンの世界標準にする絶好の機会だった
  • 一方ですぐに話に乗れない事情があった
    • 当時マイクロソフトはOSの一部となるプログラムを作るソフトで有名だったが、自社で提供できるOSは持っていなかった
    • IBMはそのOSを3か月で開発してほしいと求めていた

■ 4. 西和彦の発言と決断

• 4人はこの機会を逃すわけにはいかないという思いでは一致していた
• 西によると、アレンは「そんなに短期間で開発するのは難しい」と難色を示した
• ゲイツは「一体、どうすればいいのか」と頭を抱えていた
• 議論が停滞しかけた30分後、西が「これはやらなければならない。絶対にやるべきだ」と叫んだ

(2026/08/01)

Issue設計から始める仕様駆動開発

• Issue設計から始める仕様駆動開発 / 20260731 Mizuki Hirata - Speaker Deck

要約:

■ 1. 発表の背景と経緯

• 未経験メンバーへタスクを割り当てながら開発を推進し、限られた期間での進捗管理と成果物品質の両立が課題となった
• AI時代のジュニアエンジニアはアウトプットを量産できる一方、その粒度や品質には大きなばらつきがある
• 「何を作るか」よりも「どの単位で仕事を渡すか」が重要であり、タスクの粒度や完了定義が曖昧だと開発効率が下がる
• AIも人と同様に曖昧な指示では期待通りに動きにくいため、開発品質の標準化が必要であり、Issue駆動開発で解決する

■ 2. なぜIssue駆動開発なのか

• 「いきなりAI駆動開発」がもたらす問題:
  • 抽象的な指示（「○○機能を実装して」とAIに丸投げ）
  • 暴走する実装（不要なリファクタリング、既存実装との乖離）
  • 差分の肥大化（実装者・レビュアー共に理解不能なPR）
• コードが書かれる速度は圧倒的に向上したが、検証・修正し、手戻りに対応するコストが最大のボトルネックとなる
• 開発の主戦場は「早く書かせる」から「手戻りなく制御する」へ移行し、開発品質の標準化が必要
• 解決策：SpecからIssue設計に落とし込む
• ソフトウェア開発における「Issue」の定義:
  • ビジネス書における「イシュードリブン」（漠然とした「問い」「仮説」）とは別物
  • AI開発におけるIssue：AIが迷わず自律実行・完遂できる単位、極小・単一責任かつ明示的なタスク
  • 開発者が見慣れた「チケット」（Jira, Backlog, GitHub Projectなど）と同義
  • 1〜2日で完了できる単位で、具体的で単一責任、明確な完了定義（DoD）を持つ
  • 現場で標準化されていないことが多く、AI駆動開発成功の鍵となる
• Issueだけで開発した場合の問題点:
  • AIに起こる現象：既存設計を理解せず実装、局所のみ正しいコード、短期間でのみの解決策
  • 発生する問題：全体の整合性が崩壊、コード重複、責務の分散、技術的負債の蓄積
  • Issueを満たす局所最適な実装によってシステム全体の整合性が崩壊する
• 解決策：SpecとIssueの「双方向同期」:
  • Spec（判断基準、制約、設計原則、一貫性）とIssue（作業境界、実装範囲、完了定義、優先順位）を双方向に同期
  • (1) 仕様からIssueを切り出して実装し、(2) 完了したら仕様に反映して最新化するサイクルを繰り返す
  • アーキテクチャの一貫性と自律生産性を両立する

■ 3. 遭遇した課題と失敗から得た教訓

• 壁(1) ：変更範囲の肥大化と暴走:
  • 原因：曖昧な依頼（完了定義がない、対象ファイルの境界が不明確、影響範囲が未定義）
  • 結果：AIが推論を拡大し（関連クラスへの波及、不要なリファクタ、過剰な切り出し）、差分が肥大化
  • 影響：何が本質的変更か分からない、想定外の副作用の混入、レビューコストの増大
  • 対応策:
    • Issueに分割（「散見するロジックの共通化」→「画面コンポーネント」「エラーハンドリング」と単一責任に分解）
    • 作業境界を明示（変更可：Service/Repository、変更禁止：認証基盤・共通ライブラリ）
    • 完了定義を明示（対象ディレクトリを指定・全テスト成功）
• 壁(2) ：作業の重複とコンフリクト:
  • 原因：2つの要件のチケットを別々に並行で処理させたことで重複実装が生じる
  • チケット間の関係性や並行制御が不明瞭だとコンフリクトを招く
  • 個人で並列実装・メンバーとともに実装のどちらでも起こりうる問題
  • 対応策：親Issueが全体設計と共通ルールを握る（目的・スコープ・責務分担・共通ルール・API設計）:
    • 親Issueを共有コンテキストとして利用し、単なる管理単位として扱わず子チケットの実装を同期
    • 親Issue→設計の一貫性を保持して子Issueを用いた実装の並列化に成功

■ 4. エンジニアの役割の変化：コード記述から設計デザインへ

• レビューの主戦場はIssue設計レビューへ移行する:
  • 人間は仕様設計とIssueへの分割に専念（双方向同期デザイナー）
  • AIに渡す前に完了定義と作業境界を合意（Issue設計レビュー）
  • 完了定義の妥当性、境界線の閉じ方、実装方針を人間同士が事前に議論・合意し、Issue設計時点で不具合の芽を摘む
• これからのエンジニアに求められるもの:
  • AIに対して脱線しないためのレールを敷くこと
  • プログラミングの知識そのものではなく、システム全体を俯瞰しながら適切に境界を定義する力
  • 境界をIssueとして言語化し、メンバーとの合意形成を進めていく力
  • 「コードを書く人」から「AIが正しく動く仕組みを設計する人」へ

■ 5. 実践プロセス

• 全体フロー（仕様から実装・mergeまでの作業）:
  • (1) 仕様書を用意（要件定義・設計書を投入し、docsに配置して管理）
  • (2) 機能単位で抽出（既存実装の調査、タスクの洗い出し）
  • (3) Issueに分解（タスク間の関係性、見積もりと完了定義）
  • (4) チケット自動生成（タスク管理ツールAPIで一括作成、メンバーに展開・確認）
  • (5) 実装（チケット番号を指定して自動実装〜PR作成）
  • (6) レビュー・merge（レビュー用エージェント、docs更新エージェント）
• 実践プロセス(1) （仕様書からAI仕様のIssueへ）:
  • 洗い出し時に調査してほしい内容はテンプレート化（実装方針、タスクリスト、注意点など）
  • 調査で重視したい範囲はAgents.mdやSkillsで指定
• Issueをチケットで管理する:
  • タスク管理ツールAPIで一括作成し、ラベルのルールなどPJごとの固有ルールを追加して管理・調整
  • チケットをきれいに作成することよりもメンバーと認識齟齬がないか確認することが重要
  • Issueの粒度に落とし込んだにもかかわらず「わからない」を避けるための自動化を実現
  • 親子チケットで相互リンクで管理し、子チケット実装時にAIエージェントが親チケットを確認するよう制御することで他の子チケットの実装進捗を踏まえた実装が可能になる
• Issueによる実装品質の標準化:
  • モデル依存の低減:
    • テンプレート化によってAnthropic、OpenAI、Googleなどの差が出にくく、一定品質を維持
    • Issueに分解するステップに設計に必要な推論・実装方針を決める指示追従性を切り出すことでモデル性能差の影響を抑制
  • メンバー依存の低減：誰が担当しても同じIssueを基に実装するため成果のばらつきを抑制
  • Issue分解が品質の下限を引き上げる実装品質の標準化を実現する
• 実践プロセス(2) （Issue→自律実装→仕様同期）:
  • /start-work [チケット番号]で明示的に作業を指定し、自動実装〜PR作成まで一貫実行
  • コマンド実行後に作業フローを確認し、誤った実装や作業フローがあればコマンド内の指示かチケットの粒度を検証・改善する
  • 最終的には自動実行しても問題なく実装完了できる→実装者には依存しない
• PR作成・レビュー:
  • レビュー用エージェントや標準のhooksで自動化
  • 実装方針mdを用意しレビュー指摘を集積して反映・更新していく
  • ここまでの作業で人の手が介入したのはIssue作成のみ
  • Claudeのscheduleで実装コマンドを呼び出しPR作成まで自動化→Codexのhooksでレビュー
• 実装完了後の仕様同期:
  • 実装差分が仕様書に含まれているか確認し自動追加を行う
  • 最新の仕様書→新たなIssueを作成→… のサイクルを継続的に回していく
• 個人のふりかえりを加えた最適化:
  • AIが行う作業や自身が受けたレビューはすべてドキュメント化し、ナレッジベースとして管理
  • 受けたレビュー指摘を集めて自分特化レビュー指摘エージェントを構築
  • 弱点を深堀して技術ブログでアウトプット
  • 標準化→PJや個人の特性に合わせた最適化まで可能

■ 6. Token costの考え方

• メリット:
  • ドキュメントを参照することで調査にかかるコストを抑制
  • Issue単位で実装方針が明確であるためAIとの往復回数を削減
• デメリット:
  • 各テンプレートやドキュメントの整備が必要
  • フィードバックサイクル分のToken使用料が発生
• コスト構造の変化:
  • 設計時へコストを前倒しにする
  • 設計/Issue分割のコストは一部の担当者へ集約
  • 実装担当者は少ないコンテキスト&安価なモデルで開発可能（Claude Codeにおける「Opusで設計、Sonnetで実装」の思想と同義）
  • 組織単位でみれば設計担当者と実装者に付与する契約形態でコスト運用できる可能性
  • Token Costは開発が進むほど減少する

■ 7. まとめと将来像

• Issue駆動開発によって品質の標準化を実現する:
  • 標準化の課題：モデルや担当者によって成果物の品質がばらつく
  • Issue駆動開発：仕様からIssueへ分解し完了定義や責務を明確化する
  • 標準化の成功：仕様同期までをサイクル化し継続的に品質を向上させる
• 将来像：仕様・実装・テストが「完全自動同期ループ」する未来:
  • フロー：仕様書を更新→Issue分割→エージェントの実装→静的解析/review
  • 人間が「仕様設計」「Issue分割」「レビュー」に集中し、実装はAI主体となる
  • エンジニアが担うのは仕様とIssueの設計品質に基づいて自律型エージェントを適材適所に配置するハーネスエンジニアリング
• 明日から始められる3つのこと:
  • Issue分割（単一責任を徹底）
  • 親子関係の管理（子Issueを管理することのできる親Issueの整備）
  • 仕様書の更新（暗黙知や開発ルールをドキュメントで管理し、常に最新化）

(2026/08/01)

変化に強くなる！ソフトウェア定義型生産ラインの道標

• 変化に強くなる！ソフトウェア定義型生産ラインの道標 - Speaker Deck

要約:

■ 1. 発表者・Red Hat 会社概要

• 発表者: Red Hat K.K. シニアスペシャリストソリューションアーキテクト 小野佑大（元通信キャリア、SDN/NFV技術戦略経験、2021年よりRed Hat OpenShiftプリセールス担当）
• Red Hat の定義: 100万以上のOSSコミュニティへの貢献で培った技術と開発プロセスのノウハウで、顧客の「ソフトウェア変革」を支援する「OS（リソース抽象化）」の会社
• 製品ポートフォリオ:
  • OS: RHEL（企業向けLinux OS）
  • Middleware: JBoss（JavaアプリのOS）
  • Cloud: OpenShift（マルチクラウドのOS）
  • Automation: Ansible（ITインフラ運用のOS）
  • AI: vLLM（AI推論のOS）
• 実績:
  • ITサーバLinux市場シェア約80%
  • 主要通信キャリアの約80%が採用
  • 製造業など専用機のSDX化に対応（車、PLC/DCS、保護リレー等）
• 強み: 「柔軟性を確保」する仕組みとプロセスの「標準化」
  • ビジネスアジリティの向上: ハードウェアとソフトウェアを分離する仕組み、速さと品質を両立するCI/CDのプロセス
  • 属人的な対応の解消: 様々な機器の運用方法を共通化する仕組み、異種混在環境をサイロ化させない運用プロセス
• Red Hat の価値:
  • 産業現場対応の製品強化: 軽量化や導入方法の多様化、HW連携による性能の最適化、オフライン環境へのインストール、世界のリーダー企業との実績
  • セキュリティとライフサイクル: アップストリームファーストの開発ポリシー、OSSと異なる製品としてのライフサイクル管理、日本における大規模・堅牢なサポート体制、NIST/FIPS・IEC・ISO26262等の産業認証取得
  • 標準化への貢献: margo、Open Process Automation Forum、vPAC alliance、Open Manufacturing Platform

■ 2. ソフトウェア定義型生産ラインの世界観

• コンセプト: オープンソース技術とグローバルのベストプラクティスを実践し、OTとITを融合する「ソフトウェア変革」を実現
• 構成要素:
  • Edge Computing Platform: 産業設備と連携する機能を迅速に配備できる基盤
  • Edge Data Bus: 機能間を疎結合に繋げる基盤
  • OT Gateway: 産業設備とアプリを連携する基盤
  • Edge App Store: 様々な機能をOSSとして生産ラインで安全に活用
• 実現できること:
  • 産業設備と連携する機能を迅速に配備できる
  • 工場の成功ノウハウを組織の中で迅速に広められる

■ 3. ものづくりの市場動向と課題

• 市場環境の変化: 初期要件から変化しないモノづくりから、要件変更へ柔軟に対応できるモノづくりへのシフト
• 市場環境が激化する3要因:
  • スピード競争の激化: 海外は数ヶ月で生産準備完了
  • 顧客ニーズの多様化: 多品種少量生産・品番追加への対応
  • 開発の属人化: 開発が特定の人材やメーカーに依存
• 迅速な対応が難しい構造的要因（「ハードウェア中心」の思想が現場の「俊敏性」を奪っている）:
  • 機能追加 = 専用の箱を増設: 機能ごとに専用ハードが必要で、変更のたびに配線・設置・調整が発生
  • ベンダーロックイン: 特定メーカー依存の構成が代替手段や新技術の導入を阻む
  • 保守・更新の稼働負荷: 現地作業が前提のため、遠隔対応も迅速なアップデートも困難
• ソフトウェアファースト戦略（対比）:
  • ハードウェア中心: ソフトがハードの仕様に大きく依存し、ハードとソフトの更新サイクルが同じ（導入後は固定）
  • ソフトウェア中心: OSがハードとソフトを分離し、柔軟に新たなソフトを追加・更新（導入後も成長）

■ 4. グローバルの業界トレンド

• FA製品のビジネスモデルの変化:
  • IoT Gatewayを汎用機化して「ソフトウェア戦略」へ転換
  • SaaSと接続したApp Store経由でアプリを提供（例: 予知保全アプリ（月額）、電力監視アプリ（従量課金））
• Virtual PLC:
  • IoT GatewayのプラットフォームでPLCを「再配布可能なアプリ（コンテナ）」として提供
  • 従来のPLC: 専用ハード（CPU + 物理的な機能拡張モジュール）
  • Virtual PLC: Marketplaceから機能拡張を「アプリ」として追加・管理可能
• プラットフォームの標準化 - Margo:
  • Linux Foundation配下のプロジェクト
  • 産業用組み込み製品メーカーが主導（Rockwell / SIEMENS / Schneider / ABB 等）
  • 解決課題: 「産業エッジ」の相互運用性の欠如（ベンダー毎のサイロ化、非差別化技術の乱立によるイノベーション阻害）
  • 成果物: 標準仕様・参照実装・認定テストツール（「非競争領域」の車輪の再発明を防ぐ）
• Industrial DevOps:
  • LLMやVirtual PLCの登場、Margo等の標準化を背景に、ITのDevOpsの原則を生産設備へ応用するエコシステムが活発化
  • 活発化している要素: IDE as a Service、バージョニング、Vibe Codingや仮想試運転、Virtual PLCのライフサイクル管理の自動化、セキュアなリモートアクセス、バックアップ自動化

■ 5. Industrial DevOps の詳細と開発プロセス

• Industrial DevOps の3フェーズ:
  • Code（仕様確定→テストケース確定→実装）: AI Agentによる設計・開発支援、Gitによるバージョン管理
  • Build（テスト→再配布可能なバイナリ構築）: Build・Test・CVE scan・Sign・SBOMなど品質・セキュリティチェックのガードレール
  • Deploy（カタログ公開→UI操作→展開）: Margo準拠のEdge App StoreからGUI操作で展開
• AS IS の開発プロセス（現状の課題）:
  • 現地で動く実機ができるまで、ソフトウェアの妥当性を確認できない（ビッグバン統合）
  • 設計起因の不具合が現地デバッグ段階に集中し、差し戻しが発生
• TO BE の開発プロセス（目指す姿）:
  • テストや検証のタイミングを上流へ寄せ、後工程のリスクを減らす（Shift Left）
  • ソフトウェアとハードウェアの開発プロセスを分離
  • 成果物を単一リポジトリで版管理（Single Source of Truth）
  • 稼働実績・不具合をモデルや標準ライブラリへフィードバックする継続的改善サイクル
• CIとCDの責務分離:
  • CI（開発チームの役割）: 実装→テスト→CVE検査→成果物作成までのデプロイ可能な成果物を作成するプロセス
  • CD（運用チームの役割）: 成果物の内容確認→デプロイによる安定運用を維持するプロセス
  • 責務を分離し、チーム内の役割を明確化した上で各々の責務に集中できるプロセスを整備
• CIをAIに任せるためのガードレール設計:
  • AIが「確実・安全」に「決められた順序」で「自律的に」仕事を進められる環境を構築
  • パイプライン構成: 仕様策定→テストコード→アプリ実装→品質ゲート→静的解析→単体テスト→結合テスト→CVE検査→SBOM→署名→リリースゲート→展開
  • AIの暴走や破綻を防ぐためのガードレール設計が重要

■ 6. Industrial DevOps 導入の壁と対策

• 3つの壁（これまでの成功体験やリスク回避の考え方に起因）:
  • 壁1: 責任と権限の壁: 外部ベンダ依存や重い承認フローで、チーム自身が「変更判断」を行えないプロセス
  • 壁2: 品質保証の壁: 失敗が許されず、「人が入念に一発本番のテストをする」人依存のやり方が前提のプロセス
  • 壁3: 正当化の壁: 万が一のライン停止・事故リスクが大きすぎて「触らないことが最善」という組織の考え方
• 重要な認識:
  • CI/CDの導入は自動化ツールの導入とは異なる
  • 求められる品質へスピーディに対応する「働き方のアップデート」が必要
  • 技術で解決できないものは「プロセス」で対応
• 各壁への対応策（仕組みとプロセスの両輪）:
  • 壁1 責任と権限の壁:
    • 仕組み: コンテナで作業リスクを軽減（変更影響の範囲を局所化、切り戻し手順の簡素化）
    • プロセス: 作業承認プロセスの軽量化、ベンダ協業でコンテナ納品
  • 壁2 品質保証の壁:
    • 仕組み: GitOpsで段階保証（開発→ステージング→本番、高度なデプロイ戦略）
    • プロセス: テスト→昇格プロセス、Git Mergeでリリース承認
  • 壁3 正当化の壁:
    • 仕組み: プラットフォームの段階刷新（Re-Platform、既存との疎結合な連携）
    • プロセス: 既存影響のない領域から組織定着→段階的な拡大
• 目標: 仕組みとプロセスを回す「標準の土台」を育てていく

■ 7. 段階的なプラットフォーム移行戦略と PoC パッケージ

• 3段階の移行ロードマップ:
  • 第1段階（既存と疎結合に連携）: 既存と分離された環境で新たなプロセスを「確立」（IoT/AI・CI/CDプラットフォームをData Busで既存システムと連携）
  • 第2段階（既存の一部へ適用）: 既存の一部（MES・SCADA等）を移行し、新たなプロセスを「拡大」
  • 第3段階（制御領域へ適用）: PLCを移行し、新たなプロセスが「浸透」（制御領域全体のソフトウェア定義化）
• PoCパッケージの構成:
  • Initial Advisory（リスクなく開始し、課題とゴールを明確化）:
    • STEP1: ミニチュア工場ワークショップ（2時間+懇親会）: 海外ベストプラクティスの紹介と実機体験を通じて最初の一歩目を整理
    • STEP2: ディスカバリワークショップ（3〜4時間 × 4〜6回）: 業務プロセス分析を支援し、PoCの評価項目やKPIを策定
  • Professional Services（Red Hat及びパートナーとの体制の下でPoCで価値を体感）:
    • STEP3: ハンズオン（半日）: 最低限知っておきたい技術に触れ、そのメリットを体験
    • STEP4: MVPの実装（3ヶ月〜）: Red Hat推奨環境でプロト実装し、本番の課題（要件）を整理

MEMO:

• Virtual PLC興味深いな

(2026/08/01)

会議はただの話し合いではない---30年の「会議科学 Meeting Science」が示す5つの顔

• 会議はただの話し合いではない---30年の「会議科学 Meeting Science」が示す5つの顔｜Reading Monkey

要約:

■ 1. 会議科学とは何か

• 職場会議を専門的に研究する学問領域であり、Steven Rogelbergらによる30年分の研究を整理した2026年の総説を基盤とする
• 従来のチーム研究は会議を「情報を入れる容器」として扱ってきたが、会議科学は「容器そのものが中身を変える」という逆転した視点を採る
• 議題の共有方法、開始時刻、司会者、参加形式など、会議イベント自体の特徴が参加者の感情・情報流通・意思決定の質を左右する
• 「会議は不必要」という単純な批判ではなく、「会議がどのような作用を生み出しているか」を問うことが本質とされる

■ 2. バッテリー: 人のエネルギー管理

• 会議は設計次第で「要求（エネルギー消耗源）」にも「資源（エンゲージメント向上源）」にもなる
• うまく運営された会議は参加感やエンゲージメントを高める
• 過剰な会議や目的不明な会議は疲労や感情的消耗をもたらす
• 会議の長さだけでなく、会議前の予期的な気の重さもコストとして認識すべきとされる
• 設計上の改善点:
  • 集中作業時間を分断していないかを確認する
  • 会議と会議の間に回復時間を設ける
  • 参加者が「意味のある時間」と感じているかを検討する

■ 3. 通信プロトコル: 情報流通の規則

• 会議は中立的な情報運搬の場ではなく、通信規則そのものが流通する情報を変える
• 集団意思決定では「共有情報バイアス」が発生しやすく、全員が既知の情報ばかりが話される傾向がある
• 議題の事前共有、終了時刻の設定、司会者の選定などが情報処理の質を規定する
• 雑談やユーモア、複数チャネルの併用が情報流通を促進する
• 設計上の改善点:
  • 探索・概念整理・意思決定の各フェーズを明確に分離する
  • 前回からの更新と終了条件を明示する
  • 多様な専門知が実際に表現されるプロトコルを構築する

■ 4. 発言権の配分装置: 誰が聞かれるか

• 会議に招待されていることと実際に発言権を得ることは別問題である
• 性別や職位により発話機会が不均等に分布し、管理職が会話時間を占有する傾向がある
• 沈黙には「設計された沈黙（思考の時間）」と「生じた沈黙（恐怖や諦め）」の2種類が存在する
• 設計上の改善点:
  • 発言量だけでなく、誰が何を話せたかを観察する
  • 発言が次の議論に実際に接続されているかを確認する
  • 全員同時のアイデア出しなど、設計された沈黙を意図的に組み込む

■ 5. 権力の舞台: 権力関係の可視化と行使

• 会議の司会は中立的ではなく、議題設定から終了条件まで権力を行使している
• 誰に話を振るか、何を要約に採用するか、いつ議論を終えるかがすべて権力行使にあたる
• 散らかった議論を整理する人は周囲から「リーダー」として認識される
• リーダーの権力距離が参加者の率直な表現に影響を与える
• 設計上の改善点:
  • 司会の権限範囲を明示的に示す
  • どの論点を打ち切り、どの結論を確定できるかを事前に決める
  • 権力が見えない形で行使される状況を避ける

■ 6. 文化の鏡と鋳型: 組織文化の再生産

• 会議は組織文化を反映するだけでなく、繰り返すことで文化を定着させる
• 遅刻への対応、反対意見の言い方、新人の発言時期など、明文化されていないルールが会議で演じられる
• 失敗報告が学習の場か査問の場かは、毎回の会議慣行によって決まる
• 組織文化を変えたい場合、「理念の書き換えより会議の進め方の変更が効果的」とされる
• 設計上の改善点:
  • 立派な理念も、会議で繰り返されなければ定着しない
  • 会議の進め方の変更が組織文化変革の最短経路となる
  • ファシリテーションを訓練可能な技能として位置づけ、組織として投資する

■ 7. 三層での改善フレームワーク

• 良い会議は個人のマナーだけでは実現できず、三つの層での取り組みが必要とされる
• 参加者レベル:
  • 発言の簡潔性を保つ
  • 他者の発言を次の議論に接続する
  • 必要な沈黙を尊重する
• リーダー・ファシリテーターレベル:
  • 目的を明示し、招待者を厳選する
  • 時間設定を最適化する
  • 静かな参加者の発言を引き出す
  • 要約と決定事項を区別する
• 組織レベル:
  • 会議品質の監査を行う
  • 共通規範を設定する
  • ファシリテーション訓練に投資する
  • 非同期協働インフラを整備する

■ 8. 会議の診断例

• 連続する合同会議で同じ根本論が繰り返される場合を5つのレンズで診断できる
• バッテリー:
  • 疲れた認知資源のせいで、新しい統合より慣れた持論へ流れやすくなっている
• 通信プロトコル:
  • 探索と決定が混在し、前回からの更新が明示されていない
• 発言権:
  • 発言者が限定されていないか、発言が実際に採用されているかを確認する
• 権力:
  • 論点保留権や決定権の所在が不明確になっている
• 文化:
  • 異なる分野の「誠実さの定義」が衝突している可能性がある

■ 9. 会議科学の現状と課題

• 「良い会議」の測定基準が研究ごとに異なり、共通尺度が不足している
• 会議固有の理論がまだ存在せず、隣接分野の理論を借用している段階にある
• AI評価の妥当性と公平性についての課題が残る

■ 10. 結論

• 会議を「個人の能力や性格の発露の場」から「組織的な装置として機能する場」へと視点を転換することが求められる
• 参加者を責める前に、会議という仕組みそのものを観察することの重要性が強調される
• 問題の本質は「会議の有無」ではなく、「会議がどのような作用を生み出しているか」にある

(2026/07/31)

The Programming Tourist

• The Programming Tourist | Amr Shawky's Blog

要約:

■ 1. プログラミングへの参入と「職業的移住」

• 著者はEE専攻からCS専攻に転向するほどプログラミングに魅了され、かつてはその分野に特別な論理的情熱を持つ人々が集まっていた
• ソフトウェア業界の好景気により高給が保証されるようになり、プログラミングへの情熱を持たない「職業的移住者」が大量に流入した
• この現象自体は必ずしも悪ではなく、複雑でない業務を安価に遂行する需要を満たした
• ハードウェアの高性能化が進み、コードのパフォーマンスが重要視されなくなった
• 採用プロセスに技術的判断ができる人物が不在の場合、「無能の連鎖」が生じるリスクがあった

■ 2. LLMがソフトウェアエンジニアリングに与える影響

• 一般的な見解:
  • LLMの登場がソフトウェアエンジニア間のスキル格差を縮小するというのが通説
• 著者の主張:
  • 最低限のソフトウェアを作るためのハードルが下がったことで、エンジニアの質と人数はかつての水準に自然回帰する

■ 3. オープンソースへの影響と対応

• 従来のオープンソースはプログラミング知識があり、同僚の批評に耐える成果物を公開する意志を持つ人々によって支えられていた
• 「プログラミング観光客」（学習意欲なしにプログラミングに惹かれる層）がLLMを活用し、リポジトリにPRを大量投入・LLM生成コードを宣伝している
• コミュニティの反応:
  • ZigはLLM生成コードをリポジトリから締め出した
  • CodebergはLLM主体のコードを禁止した
• 今後の予測:
  • コードホスティングプラットフォームの分断化が進む
  • 貢献者に対する信頼の格付け（Vouchなど）が普及する
  • 招待制のコードホスティングプラットフォームが台頭し、品質が担保される

■ 4. LLM活用の適切な条件

• 非プログラマーがコードを生成できる点は必ずしも否定的ではない（例：芸術家がBlenderのワークフロー自動化スクリプトを生成するなど）
• 開発者がLLMで自身のコードを補強することにも異論はない
• 条件:
  • 機械生成の成果物は人間が生成したものと区別がつかない品質でなければならない
  • そのためにはスコープを十分小さく保つか、成果物を継続的に監査・修正し、出力全体を理解・レビューすることが必要

■ 5. ソフトウェアエンジニアリングの将来と失われる人材

• ソフトウェアエンジニアリングという職業は、マシンの深い知識を持つ人材のみで構成される状態に回帰する
• LLM活用の有無にかかわらず、複雑で高性能なコードベースを理解・保守・拡張できる能力が依然として求められる
• 打撃を受ける層:
  • 「生計を立てるために最低限の知識だけを習得した」エンジニア層は、LLMを使う非エンジニアに代替されるリスクがある
• 本質的な悲劇:
  • 「プログラミング観光客」がソフトウェアエンジニアリングの終焉を叫ぶことで、次世代を担うはずの学生のCS専攻離れが加速している
  • ジュニアエンジニアが不足するのはLLMによる代替ではなく、CS入学者数の減少が原因となりうる

(2026/07/30)

Engineering managers have a new job description

• Engineering managers have a new job description - LeadDev

要約:

■ 1. 2022年時点のEMの役割

• 業務は調整に特化しており、依存関係管理・チームのブロック解消・ステークホルダー管理が中心だった
• コーディングやアーキテクチャ設計は明示的に委任対象であり、積極的に避けることが推奨されていた
• ゼロ金利政策（ZIRP）期はチームが急成長しており、プロダクト・エンジニアリング・ビジネス間の調整層に明確な価値があった

■ 2. 役割の変化とその背景

• LeadDevの2026年エンジニアリングリーダーシップレポートによると、リーダーの37%がすでに深く実務に関与している
• Gergely Oroszが2024年に予測した「プレイヤーコーチ」モデルが現実化しつつある
• James Stanierをはじめとする識者が、非技術系EMの時代の終わりを主張している
• 変化の本質はEMがテックリードを吸収することではなく、両者の「合併」に近い
  • ピープルマネジメントは引き続きEMが担う
  • スタッフエンジニアやテックリードの領域だったドメイン深度とアーキテクチャリテラシーも求められる

■ 3. 著者の実体験: Zenjobでの経験（2025年）

• 入社初日から「コードに貢献すること」が明確に期待され、ハンズオンであることはロールの必須要件だった
• 請求書アーキテクチャ、B2B技術統合、パートナー向けシステムなど、経験のない領域を担当することになった
• 対応アプローチ:
  • コードを読み、バグをトレースし、シニアエンジニアとのペアプログラミングを頻繁に実施
  • ロードマップ上の重要機能は担当せず、計画外の地味な作業に集中し、各システムの課題とエンジニアの対処法を把握した
  • Claude Codeのプランモードおよび各種MCPサーバーを活用し、複雑なコードベースの調査と課題特定を加速した
• AIツール活用における重要な区別: AIは「ドメインを真に理解するため」に使用し、「説明できないコードを生成するため」には使わない

■ 4. コーディングと委任の判断フレームワーク

• 判断軸は「複雑さ」と「計画/非計画作業」の2次元
• 明確で小さな非計画作業（バグ修正、サポートチケット等）:
  • EMが直接対応し、AIツールを活用してスピードを確保する
• 複雑で不明確な非計画作業:
  • 即座の「修正」衝動を抑え、問題とシステムの理解を優先する
  • 理解後に「パッチ適用」「チームへの正式な計画立案」「タスク保留」の判断を行う
• 計画作業:
  • チームに帰属させ、EMはキャパシティ保護・進捗管理・ステークホルダーへの情報共有に徹する
• Loop Engineeringなど新しいパラダイムにより、EMが担っていた小さな非計画作業はAIエージェントへ移行しつつあり、「EMが担う範囲」は縮小を続けている

■ 5. ハンズオンアプローチの効果

• 数ヶ月後、複数のシニア個人貢献者（IC）から「コーディングしてシステムを詳細に理解してくれるマネージャーがいると素晴らしい」という自発的なフィードバックを受けた
• 作業への近接性から生まれる信頼は、プロセスやコミュニケーションのみから生まれる信頼とは質が異なる
• EMがシステムを深く理解することで、見積もりの正確性が向上し、問題の早期発見が促進される

■ 6. 役割変化の総括

• 技術的な要求水準と期待値は拡大したが、役割としての魅力も増している
• 以前のEMは元々携わっていた作業との「距離を管理する」役割だったが、新しいEMは個人貢献者としてではなく、ピープルと技術の両次元で活動するリーダーとしてその作業に戻ることができる
• 良いソフトウェアを作ることを重視してマネージャーになったEMにとって、このモデルは負担ではなく、留まる価値のある役割の形となり得る

(2026/07/30)

第921回　Canonical Workshopでコーディングエージェントの実行環境を作る

• 第921回　Canonical Workshopでコーディングエージェントの実行環境を作る | gihyo.jp

Workshopとは、Ubuntuを開発しているCanonical社がリリースした、開発環境のサンドボックスをUbuntu等の環境に作成するツールです。

workshopコマンドを実行するとサンドボックスを作成でき、そのサンドボックス内でコーディングエージェントを動作させることで、コーディングエージェントの非決定的な挙動からホスト側OSへの影響を抑えられます。

また、環境の設定はYAMLによって定義できるため、Gitレポジトリ等に設定ファイルを配置しておけば、各開発者のPCで同じ環境を作成できます。

MEMO:

• LXDも結局はnamespace + cgroupによる分離なのでカーネルにバグがあるとコンテナエスケープのリスクはある
• あくまでファイルシステムや設定ファイルの書き換えに対する耐性の確保というレベルでしかなさそう

(2026/07/30)

AIネイティブ時代の設計書を考える

• AIネイティブ時代の設計書を考える | フューチャー技術ブログ

要約:

■ 1. AI開発のボトルネックの変化

• 従来はAIとのコミュニケーション部分がボトルネックとされていた
• 近年はAPIリクエストのクレジット数が制限要因となっている
• Claude Opusのコスト倍増によりトークン数の節約が重要な課題となった
• 日本語は情報伝達が速い一方、英語はトークン効率が高いというトレードオフが存在する

■ 2. AI-DLCワークフローの課題

• AmazonのAI-Driven Language Comprehensionアプローチを試した結果、ドキュメント作成が重くなることが判明
• 細部まで質疑応答が必要となり、ウォーターフォールモデルを強制されるような疲労感が生じた
• AIが大量生成したドキュメントを人間が確認する流れは、AIの「解読が得意」という特性に反する

■ 3. AI時代のドキュメント設計思想

• 構成の改善:
  • 人間が読みやすい従来形式からAI理解に適した形式へシフト
  • 穴埋め式テンプレートではなく、柔軟な構造化が必要
  • セマンティックウェブの概念を応用
• 読み込みの改善:
  • リンク構造で小分割化し、コンテキスト消費を削減
  • RAGより直接リンク参照が効率的
  • スクリプトによる自動リンクチェックを実施
• 完全性の後回し化:
  • アジャイルと同様に、必要な要件だけを先行実装
  • バックログで未完了要件を管理
  • アーキテクトスキルを持つ人間による優先度判定が効率的

■ 4. Spec Compiler Skillの開発

• 著者がGitHubで公開したツールの特徴:
  • デフォルトドキュメント種別を定義
  • テンプレートは最小限に抑える
  • 英語本文と日本語説明を組み合わせた形式
  • JSONLインデックス出力でDuckDBに対応
  • ドキュメント間のリンクを自動生成
• 効果:
  • コンテキストの節約
  • ローカルWiki的な運用が可能

■ 5. AI用ドキュメントの活用方式

• 仕様確認はAIへの質問で対応
• 修正依頼はAIへの指示で対応
• 要件補完はAIへの相談で対応
• ドキュメントはコンテキスト節約のため英語で記述するが、日本語での問い合わせに対応
• 実装フェーズではゴール機能を用いて完了まで一気に依頼可能

■ 6. 今後の課題

• OpenTelemetryを活用したスキル検証
• テスト連携の強化
• 従来形式ドキュメントの自動生成

(2026/07/29)

正論で殴ってくる人に、正論で勝とうとしてはいけない——20年PMが見てきた「構造を変える」という仕事術

• 正論で殴ってくる人に、正論で勝とうとしてはいけない——20年PMが見てきた「構造を変える」という仕事術｜shiraco

要約:

■ 1. 著者の変化: 正論に腹が立たなくなった理由

• 20年前は正論に対して正論で反撃していたが、それが現場をさらに悪化させた
• 現在は正論で攻撃されても「この人も不安なのだ」と受け取れるようになった
• 人を責めるより構造を変えることが、20年の経験から得た核心

■ 2. 正論は必ずしも正解ではない

• プロジェクト管理にはQCD（品質・コスト・納期）のトレードオフが存在し、すべてを同時に満たすことは不可能
• 「品質を妥協できない」かつ「予算も変えられない」という矛盾した正論が現場には並立する
• 正論に対して正面から反論しようとすると「品質を下げたい人」として見られる罠がある
• PMとしての教訓:
  • 正論は「何が正しいか」の話ではなく「何を優先するか」の話
  • 正論対正論で戦う前に、優先順位の議論へ移行すること

■ 3. 正論マウントの目的は問題解決ではない

• 正論でマウントを取る人の動機は問題解決ではなく「自分が正しいと示すこと」
• 「品質を上げるべきだ」という発言の裏には「自分は品質に厳しいまともな人間だ」という自己証明の意図がある
• 正論は「主張の手段」ではなく「自己証明の手段」になっている
• 反論すると相手には「アイデンティティへの攻撃」として受け取られ、問題解決ではなく関係破壊につながる
• PMとしての教訓:
  • 相手の動機が「自分が正しいと思われたい」である構造を理解してから対応すること
  • 動機を無視して反論すると問題解決どころか関係が壊れる

■ 4. 正論を振りかざす人は不安を抱えている

• 20年で最も厄介だと感じた人物は怒鳴る人ではなく、不安を抱えた正論家
• 正論マウントの裏にある内側の声:
  • 責任を取りたくない
  • 上司に怒られたくない
  • 失敗したと思われたくない
  • 自分が無能だと思われたくない
• 不安を正論という鎧で覆うことで、後から「品質が下がったのはPMが弱腰だったせいだ」という言い訳を確保する責任回避の構造
• PMとしての教訓:
  • 正論の奥にある不安を理解すると怒りが消える
  • 「この人も怖いのだ」と思えた瞬間、冷静な対処が可能になる

■ 5. 戦わずに議論の構造を変える

• NGの対応例（逆効果になる正論返し）:
  • 「それは違います」
  • 「御社の責任ではないでしょうか」
  • 「PMBOKにはこう書いてあります」
• 有効な対応の手順:
  • まず「おっしゃる通りです」と言い、防衛反応を解除する
  • 次に「その前提で、優先順位をどうしましょうか?」と問いを切り替える
  • 議論を「正しい・間違い」から「どれを選ぶか」へシフトする
• 判断の責任を共有する構造に持ち込み、相手を「一緒に決める側」にする
• PMとしての教訓:
  • 正論を受け取ったサインを出してから、「優先順位はどれか」という問いに変える
  • 戦わずに議論の土俵を変えること

■ 6. 人を変えるのではなく構造を変える

• 正論マウントを取る人を変えることはほぼ不可能であり、その不安の根っこはPMの管轄外（組織文化・上司との関係・キャリアへの焦り）
• 構造を変えるための具体的手法:
  • 会議体を変える: 全員参加の会議は自己証明の場になりやすいため、重要な議論は少人数のクローズドな場で行う
  • 議事録を残す: 決定事項・保留事項・担当者を明文化し「言った言わない」を防ぐ
  • 優先順位を明文化する: 口頭での確認ではなく「今フェーズではQCDのうちQを最優先とする」と文書化し、変更時も文書化する
  • 第三者を入れる: ステアリングコミッティや外部レビュアーを活用し「第三者の目線」をバッファーにする
• PMとしての教訓:
  • 上記手法はすべて「正論を言う人をどうにかする」ではなく「正論が武器にならない構造を作る」アプローチ

■ 7. 現場を救うのは最も正しい人ではない

• 20年間の現場で最終的に状況を救ったのは、最も正しい人でも最も偉い人でもなかった
• 現場を救った人の特徴:
  • 最も人の話を聞いた人
  • 最も優先順位を整理した人
  • 最も構造を見ていた人
• 正論で殴られたときに腹が立たなくなるのは「相手が間違っているから」ではなく「相手も不安で正論という鎧を着ているから」と理解できるようになったため
• 不安を生む構造を変える方が、不安な人を責めるより問題解決に直結する

MEMO:

• 「NGの対応例（逆効果になる正論返し）」のやつ、言う程正論か？　という感がある
• どちらかと言うと「言い訳」「責任逃れ」なので別に正しくない
• 「PMBOKが云々」は「だからどうした」で一蹴されるレベル
• そりゃそんな事口走る奴は使い物にならないだろうなという感想

(2026/07/29)

使いながら育てる Claude Code ― 開発フローの1コマンド化 × 繰り返し指摘の自動仕組み化

• 使いながら育てる Claude Code ― 開発フローの1コマンド化 × 繰り返し指摘の自動仕組み化 - Tabelog Tech Blog

要約:

■ 1. 概要と課題

• 食べログカンパニー フロントエンド基盤チームによるClaude Code活用事例
• jQueryからReactへのリプレース事業においてClaude Codeを導入
• 生成コードの品質にばらつきが生じ、PRレビューと修正に多大な時間を要する問題が発生

■ 2. /react-pipeline Skill: 実装からPR作成の1コマンド化

• 実装からPR作成までの全工程を1コマンドに集約し、品質を一貫して担保する仕組み
• 4つのフェーズ構成:
  • Phase 1 (実装): 3つのSubagent（調査・API生成・実装）が動作し、完了条件の確認と設計承認を経て実装を進行
  • Phase 2 (レビュー): 7つの専門Subagentが並行レビューを実施し、自動修正と人間確認を区別
  • Phase 3 (テスト): Playwright MCPでブラウザ自動操作によるテストを実行
  • Phase 4 (PR作成): Draft状態でPRを自動生成
• 階層設計: Orchestrator Skillが各Phase Skillを指揮し、専門Subagentが実行する「1エージェント=1責務」の原則を徹底

■ 3. /review-digest Skill: 繰り返し指摘の自動仕組み化

• 繰り返されるレビュー指摘を検知し、自動的に静的解析ルールへ変換する仕組み
• 5ステップのフロー:
  • 指摘テーマの抽出・分類（表記揺れをまとめる）
  • 履歴データとの照合・カウント（3回目で自動化昇格）
  • 自動化手段の判定（静的解析→Hooks→Skip の優先順）
  • 自動実装とPR作成
  • history.json への記録とMiroへの出力
• 3回の指摘閾値: 1〜2回は偶然のミスとして記録し、3回目で「仕組み化すべき」と判定

■ 4. .claude/rules/ による規約管理

• 規約を7つのファイルに分割して管理: directory-structure、hooks、states、components、usecases、api-clients、testing
• ファイル参照時に自動ロードされ、日常開発全体で効果を発揮

■ 5. 成果と指標

• PR平均コメント数: 15.10件 → 8.04件（約47%削減）
• 測定期間: 導入前後各108日間、対象は同一チームのReactリプレースPR
• 品質面: 仕様漏れ、ファイル構造違反、規約違反が大幅減少
• 指摘内容の質的変化: 軽微なルール違反から、Jotaiの状態管理パターン・React Queryの細かい仕様など高度な設計判断へシフト
• review-digestの実装例: ESLintカスタムルール3件、ESLintルール1件、Knipツール導入

■ 6. 設計原則

• Subagentの専門特化: 単一の「何でも屋」エージェントではなく専門分野に特化させることでコンテキスト肥大化を防止
• 自動修正と人間確認の分割:
  • 軽微な修正: Claudeが自動実行
  • アーキテクチャやセキュリティに関わる修正: 人間確認
  • 脆弱性: 常に人間確認

■ 7. 運用上のTips

• .claude/rules/ のパス指定は「/components/*.tsx」より「packages/frontend/src/...」など厳密なパスを使用
• Opus（思考）+ Sonnet（作業）の使い分けで、初期方針にコストをかけ承認後は低コスト実装
• プラン承認時にコンテキストをクリアして無関係な履歴の再送信を防止
• Playwright CLIはMCPより約4.2倍効率的

■ 8. 現状の課題と今後の展望

• 現在の制約: 大規模タスクでコンテキスト上限に達した場合、Claudeの自動要約が重要な詳細を削除して精度が低下
  • 現在の対処法: 各フェーズを別セッションで実行
• 今後の目標:
  • 高コストフェーズ（pr-review・manual-test）の最適化
  • 静的解析で防げない指摘への対応

■ 9. 結論

• 完璧を求めず、不完全でも改善サイクルを回し続けることがより良い結果をもたらす
• react-pipelineとreview-digestは単発の導入物ではなく「使いながら改善し続ける仕組み」として設計

(2026/07/29)

Googleのデータによると労働者がAIによる自動化で職を失うことはない

• Googleのデータによると労働者がAIによる自動化で職を失うことはない - GIGAZINE

要約:

■ 1. 調査の概要

• GoogleはGeminiアプリ、Google検索のAIモード、Gemini APIで実行された1500万件の匿名化されたAIインタラクションを分析
• 分析の結果、ほとんどの仕事のタスクはAIの影響を受けていないことが判明
• AIの利用は「浅く、圧倒的に協調的な性質のものであり、エンドツーエンドのタスク自動化の範囲は限られている」と評価された

■ 2. 調査手法

• 労働統計局の標準職業分類とO*NETの業務インタラクションデータベースを活用し、業務関連のAIインタラクションを分類する自動分類器を作成
• 人間のレビュー担当者による検証を経て、信頼できる指標と判断された

■ 3. 職種別のAI利用状況

• 利用率が高い職種:
  • コンピューター、金融、芸術・エンターテイメント分野のホワイトカラー職
  • 具体例: 金融・市場アナリスト、ソフトウェア開発者、システム管理者
• 利用率が低い職種:
  • 営業担当者、運輸業従事者、食品調理・サービス業従事者

■ 4. AI利用の実態

• 29%の職業では、関連する業務タスクで「無視できない」Gemini使用率のしきい値に達したものが皆無
• 追跡対象タスクのうち、Gemini使用率が有意に高かったのは4分の1未満
• 業務の少なくとも4分の3でGeminiを定期的に活用する職種は全体のわずか3%:
  • 該当職種: ソフトウェア品質保証アナリストやテスター、人事スペシャリスト、文書管理スペシャリスト

■ 5. AIインタラクションの性質

• 認知的作業が全体のGeminiインタラクションの86%を占める
• 重要タスクの大部分が「アイデアの草稿作成」や「情報の検索と学習」に関連
• AIに委託される認知タスクは専門知識を必要としないものが中心:
  • 例: 資料を異なる言語へ書き直す
• 肉体労働系の職種でも一定の活用事例が存在:
  • 産業機械整備士: テスト結果や機械のエラーメッセージの分析（数千件の事例）
  • 自動車整備士: 車両部品やシステムのテスト、配線システムの再配線、部品の摩耗検査（数万件の事例）
  • 肉体労働系では、テキストではなく写真を入力する傾向が高い

■ 6. 研究チームの結論

• AIは現在、既存の業務を補完する役割を主に担っている
• 労働者はAIにより自らの存在意義を失っているわけではない
• 労働者の傾向: 定型的な認知作業をAIで自動化することで業務を強化しつつ、非定型的な認知作業においてはAIと協働する

(2026/07/29)

Vercel、TypeScriptをC言語に変換してからネイティブな実行ファイルにコンパイルする「scriptc」...

• Vercel、TypeScriptをC言語に変換してからネイティブな実行ファイルにコンパイルする「scriptc」、オープンソースで公開 － Publickey

(2026/07/28)

【やさしく解説 設計編・中級 #6】良いアーキテクチャとは ～ 一本の登り道の、行き先 ～

• 【やさしく解説 設計編・中級 #6】良いアーキテクチャとは ～ 一本の登り道の、行き先 ～ - Speaker Deck

(2026/07/28)

1日500コミットは、もう読めない ── だからコードレビューをやめた

• 1日500コミットは、もう読めない ── だからコードレビューをやめた

要約:

■ 1. 記事の主旨

• マージ時にdiffを読まないことが多くなった:
  • 場合によっては動作確認もしない
  • それでも簡単なバグはほぼ出ない
• 理由:
  • レビューでしか捕まらない問題を、先に減らす仕組みを整えたため
  • この記事は、その「先に減らす」ために何を整えたかを説明するもの
• 背景:
  • エージェントを並列で回すようになり、コミットは1日500を超えた
  • 前作「ターミナルを自作したら、1日のコミット数が500を超えて、生産性がバグった話」の続編にあたる

■ 2. 前提：人間のレビューはスケールしない

• 並列でエージェントを走らせると、生成されるコード量が人間の読める速度を超える:
  • 問題は量そのものではなく、読む速度が量に追いつかなくなったこと
• 選択肢は2つ:
  • 生成を減らして読める量に合わせる
  • 読まなくても壊れないようにする
  • 後者を選択、これは「壊れたら赤くなって止まる」仕組みを積み上げる作業
• 紹介する設定はMulmoTerminal / MulmoClaudeで実際に稼働しており、両方ともMITで公開している

■ 3. CLAUDE.md：規約を人の記憶でなくファイルに置く

• 規約の置き場所は2層:
  • グローバル(~/.claude/CLAUDE.md): 全プロジェクトに効くルール、公開済み
  • リポジトリ固有(各リポジトリのCLAUDE.md): そのリポでしか通用しない事実
• リポジトリ側はほとんど不要:
  • 開発スタック(yarn、TypeScript、Vitest、同じESLint構成、同じCIの形、同じテストの置き方)をほぼ揃えているため
  • リポジトリ側に本当に書く価値があるのはディレクトリ構成の理由付け程度
  • 例:共有コードを置く場所と、同期維持コメント付きコピーを禁止する理由
  • もう一つ価値があるのは、そのリポでしか起きない罠
    • 例:MulmoTerminalでは型チェックコマンドが3つに分かれており、揃えないとローカルでは通ってもCIで落ちる
• リポジトリ側CLAUDE.mdが長くなることへの解釈:
  • 規約が足りないのではなく、スタックの揃え方が足りないサインと考えている
  • 同じ注意書きを複数リポに書き写すより、先にスタックを揃える方が早い
  • 規約は増やすものでなく、書かなくて済むよう環境を寄せていくもの
  • 長い規約は人間にもAIにも読まれない、実際に効くのは毎回必ず踏む数行だけ
• 誰のために書いているか:
  • ここに書いてある規約は基本的に全部AIにやらせるためのもの
  • 人間が読んで守るための規約ではなく、著者自身がやることは想定していない
  • AI向けの規約は、いつ読むか・何をすればよいかまで書き切る必要がある
  • 行間を読んでくれることを期待した書き方は通用しない
  • 人間が読んで守る前提を捨てれば、規約はいくら細かくても構わなくなる
• グローバル側は「短い本体＋深いドキュメント」の構成:
  • 本体には1行のポインタだけを置き、詳細はdocs/に逃がしている
  • 現在配置されているのはdocs/testing.md、docs/debugging-methodology.md、docs/windows-gotchas.md、docs/cross-platform-ci.md、docs/web-debugging.mdの5つ
  • ポインタには「いつ読むか」を添える
    • 例:テストを書く前に読む、Windows障害デバッグ前に必読
  • 常に全部を読ませようとすると結局どれも効かなくなる、規約は量でなく「踏む確率」で効く

■ 4. ESLint：大きすぎる・複雑すぎるを機械が拒否する

• コードレビューで指摘したくなる内容(長い、ネストが深い、引数が多い、分岐が多すぎる)の大半は機械が言えると気づいた
• 主要ルールをすべてerrorに設定:
  • max-lines-per-function: 60行
  • complexity: 20
  • max-depth: 4
  • max-params: 6(こちらはwarnのまま)
  • max-nested-callbacks: 4
  • 加えてeslint-plugin-sonarjsのcognitive-complexityをerror(閾値15)に設定、循環的複雑度より人間の読みにくさに近い指標
  • MulmoClaude側はさらに厳しくmax-lines-per-function 50、complexity 15
• 大事なのは例外の作法:
  • インラインのeslint-disableを許すと規約が死ぬため許可しない
  • 例外は設定ファイルに理由付きで記載する運用
  • 例:Vueコンポーネントの<style>ブロックを原則禁止しTailwindユーティリティで代替、どうしても書けないものだけ理由付きで許可リスト化し、理由が消えたらエントリも消す
  • max-paramsのみwarnにとどめている理由も設定ファイルに明記
    • spawnClaudePtyの7引数はhot pathであり、5箇所の呼び出しをオプションオブジェクト化する労力に見合わないため
    • 解消したらerrorへ格上げする方針
• プリセットの選び方:
  • typescript-eslintはrecommendedでなくstrictを採用
  • sonarjsとsecurityはrecommendedのみが最上位設定(strictが存在しない)であり、手加減ではなく取り得る最も厳しい設定
  • その上で個別ルールをさらに追加
    • sonarjs/cognitive-complexity: 人間の読みにくさに近い指標
    • sonarjs/no-ignored-exceptions: catchして握りつぶす箇所を検出
    • sonarjs/assertions-in-tests: アサーションのないテストを検出、以前は人間が目で見つけていたものをCIが担うようになった
  • 外すルールにも理由を記載
    • MulmoTerminalではsonarjs/no-os-command-from-pathをbin/でのみ無効化、ユーザーがインストールしたCLIをPATHから起動するのがツールの前提であり、このルールと矛盾するため
• 型をもう一つの規約として使う:
  • CLAUDE.mdが自然言語規約なら、型は機械が強制する規約
  • diffを読まなくなった以上、読む役を型に担わせるしかないと考えている
  • no-explicit-any、no-non-null-assertion、consistent-type-assertionsをerrorに設定
  • グローバルCLAUDE.mdにも明記
    • asキャストは使わず型ガードを書く
    • Zodスキーマからはz.inferで導出し、同じ型を二重定義しない
    • anyは使わない
    • lint/型エラーをeslint-disable、@ts-ignore、@ts-expect-errorで黙らせず根本を直す
  • 最後のルールが特に効く、放置するとエージェントはエラーを消す最短経路(@ts-ignore等)を選ぶため
• 型情報を使うlintは「コストに見合うものだけ」採用:
  • projectServiceを有効にした型チェックパスは重い
  • 実測では5ルールでも44ルールでもコストはほぼ同じで、プログラム構築自体が全コスト、未型付けパスに対し全体で約26秒かかる
  • にもかかわらずstrictTypeCheckedを全部は入れていない
    • 残りはスタイル系ルールが支配的で、restrict-template-expressions単体で1213件中439件を占め、本当に必要なルールを埋もれさせるため
  • 型情報でなければ捕まえられない2種類に絞って採用
    • 構造的に見えないany(型のないライブラリの値、JSON.parse()、二段キャストなど)
    • 構文ルールでは原理的に捕まえられない間違い(await付け忘れ、同期専用APIへの非同期コールバック、文字列化ミスなど)
  • 該当するno-base-to-string、no-floating-promises、no-misused-promises、await-thenableの4ルールは、バックログをゼロにしてからerrorに格上げした
    • 「誰も読まない警告リストに1件足す」ことを許さない運用、既存のバックログがないため新規混入は即CI失敗になる
• 人間なら耐えられない厳しさが、AIなら成立する:
  • この設定は人間のチームなら3日で緩和PRが飛んでくるレベル
  • 人間が書いていれば「いちいちうるさい」となるが、AIは指摘されたら直すだけで文句を言わない
  • 従来lintの厳しさは「機械の正しさ」と「開発者の忍耐」のトレードオフであり、緩める判断は技術的でなく社会的な判断だった
  • 社会的コストがゼロになった以上、天秤は厳しくする側にしか傾かない
  • diffを読まない著者にとって、厳しいlintは贅沢でなく必需品
• だから型のない言語を選びたくない:
  • 静的解析が効かない言語では、この記事の内容の半分が成立しない
  • 「読まなくても壊れない」を支えるのは書いた瞬間に機械が読んでくれることであり、型がないとその最初の読み手がいなくなる
  • 型を書く面倒のコストは、今は著者でなくAIが払っている
• ESLintとSonarJSをCIにどう置くか(ゲートかレポートか、既存負債の返し方)は別記事に切り出してある

■ 5. テスト：できる限りpure関数にしてエッジケースを潰す

• 実績数値:
  • MulmoTerminal: specファイル294、テストケース3,373、ソースファイル407(ソース1ファイルあたり約8ケース)
  • MulmoClaude: specファイル799
  • エージェントが書くためテスト作成コスト自体は安く、高いのは「壊れたことに気づかないコスト」の方
• 設計の方が本質:
  • テストを増やす前に、テストできる形にすることを優先した
  • ルール(フィルタ、並び順、上限、検証、整形、保持期間)は専用ファイルのpure関数に切り出す
  • ファイル読み書き、プロセス起動、ソケット、HTTPは呼び出し側に残す
  • アプリを起動しないと到達できないルールはテストされないため
  • 純度を保てない境界(now()、isValidId、hasTmux、ホームディレクトリのパスなど)では依存を引数で渡す
  • import時に時計やプロセスを掴むモジュールは開発者のマシンに触らずテストできず、これは設計の欠陥とみなす
  • これは著者の心がけではなく規約(CLAUDE.md、docs/testing.md)に明記されており、エージェントがそれに従って書く
• 新しいコードだけの話ではない:
  • 規約には既存コードにも適用すべきと明記されている
  • 大きなファイルを触る際は、埋もれたpureなルールを見つけて切り出しテストを付けることが求められる
  • テスタブルであることは新規行だけを縛るルールでなく、コードベースの性質として取り戻し続けるものと位置付けている
  • 定期的にコードベース全体を見直させ、Claude Code組み込みの/code-reviewや/simplifyコマンドで切り出しとリファクタリングを行わせている(自作スキルでなく標準機能)
  • これも人間はやらない
• カバーするケースのパターン:
  • 正常系、エッジケース、コーナーケース、境界値、空、null/undefined、不正入力、エラー、否定、リグレッションの10種類を明示している
• テストが本当に落ちるか確かめる:
  • 新しいテストは対象を壊したときに赤くなるかを確認する運用が最近習慣化した
  • 条件を反転させる、ガードを消す、修正をrevertするなどして赤くなることを確認してから戻す
  • 壊れたコードでも通るテストは何か別のものをテストしており、確認しない限り気づけない
• 何を先にテストするか:
  • 優先順位は「どれだけ静かに失敗するか」で決めている
  • 例外を投げる関数は自分で報告してくれるため優先度が低い
  • 怖いのはそれっぽい間違った値を返すもの
    • 例:ずれたインデックス、バイト数と文字数の取り違え、ずれた日付、拡張子の大文字小文字違い、ゆるすぎるバリデータ、プロトタイプチェーンを読んでしまう検索
  • これらはユーザーが気づくまで見えないため先に潰す

■ 6. DRY：重複は「気をつける」ではなく機械が数える

• 重複はメンテコストに直結する、同じロジックが3箇所にあると修正が3箇所必要になり、たいてい2箇所しか直らない
• CIに2本のスキャンを追加:
  • duplication-scan(jscpd公式): コピペの検出
  • dead-code-scan(knip公式): どこからもimportされていないexportや、誰も呼ばなくなったヘルパーの検出
• どちらもビルドを落とさない設計だが方法が異なる:
  • dead-code-scanは明示的にcontinue-on-error: trueを設定
  • duplication-scanは閾値を設定せず走らせ、結果をSARIFでCode Scanningに上げる(アラートとして残るがジョブは失敗しない)
• 理由:
  • knipは全てのエントリポイントを推論できず(tsx経由のCLIサブコマンド、codegenなど)、少数の誤検知が想定されるため
  • knipにはbase-branch diffingがなく、報告はPRの差分でなく全体インベントリであるため、レビュー補助でありゲートではない
  • 初日からブロックすると「無視の作法」が育ってしまう、これはESLintの例外運用と同じ構造
• 補足:
  • ESLintのno-unused-varsはファイル内しか見ず、重複スキャンはコピペしか見ない
  • どこからも呼ばれなくなったexportはどちらの網にも引っかからない孤児であり、リファクタが最後の呼び出し元を消したときに残る典型例
  • knipはその隙間を埋めるために導入した

■ 7. CIをmac / Linux / Windowsで回す

• 構成:
  • PRごと: ubuntu-latest + macOS-latest
  • Windows: 毎日03:00 JST実行に加えmainへのpush時にも実行
• 3OSで回す最大の理由:
  • チームにLinux使いもWindows使いもおらず全員がMacユーザー
  • Linux/WindowsのCIが唯一の実機であり、手元にない環境のバグはローカルで再現できない
  • リリース前だけでなく、ユーザーからのバグレポート再現にも有効な想定外の副産物になっている
• macOSをPRごとに回す理由:
  • 冗長性のためではなく、Dockerサンドボックスがdarwin限定機能のため
  • Keychainからの認証情報エクスポートやマウント構築のコードパスがmacOSランナーでしか実際には走らないため
• WindowsをPRから外した理由:
  • NTFSのtar展開、Defender、2回目のtscなどで遅く、全PRがそのコストを払う価値に見合わないため
  • Windowsが守っている範囲(PATHの大文字小文字分岐、;区切りと\区切り、bareコマンド名の解決、powershell.exeの起動、postinstallの実行など)をワークフロー先頭にコメントで明記している
  • 「何を守っているか書けるなら頻度は落としてよい、逆に書けないゲートはたぶん不要か、必要なのに守れていないかのどちらか」という考え方
  • Windows固有の罠の例:fs.watchが8.3短縮パスでプロセスを丸ごとabortさせる(catch不可)、path.resolve("/etc")がC:\etcになりPOSIXパス一覧が静かに全部マッチしなくなる
• Windows専用のテストケース:
  • 16個のspecファイルがwin32を意識したケースを持つ
  • 目的は「Windowsで動くこと」だけでなく、他の変更でWindowsをデグレさせないことがより大きい
  • パス処理や区切り文字はLinux前提の一見きれいなリファクタで簡単に壊れ、Mac上では誰も気づけない
  • プラットフォームを引数で渡す書き方を採用し、process.platformを直接見ずWindows挙動をMac上でテストできるようにしている
  • これは「境界では依存を引数で渡す」設計方針の実例でもある

■ 8. Claude Codeで実装しCodexがレビュー、OKが出るまで繰り返す

• 基本方針:
  • 実装したのと別のAIにレビューさせるというだけ
  • Claude Codeが書きCodexが読む、逆のパターンもある
  • 同じモデルに自分のコードを読ませるとたいてい「良いと思います」と返る、これは同じ判断でそう書いたため
  • 別のモデルは別の前提で読むため指摘の質が変わり、導入後バグらしいバグがほとんど出なくなった
• 仕組み:
  • GitHub Actionsで全PRにCodexの自動レビューを実行し、CODEX VERDICT: LGTM/CHANGES REQUESTEDという決まったマーカーで判定を返す
  • 発火条件は意図的にゆるく、draftやdocsのみの差分でも走らせる、レビューするか判断するコストの方がレビュー自体より高いため
  • 連続pushはconcurrencyで最新コミット1回分のレビューに畳まれるため無駄打ちにならない
• 現在の形に至る経緯:
  • Yohei Nakajima氏(BabyAGIの作者)のプロジェクトでCodeRabbitが使われているのを見たのがきっかけ
  • PR数が少ない当初は無料プランで十分だったが、PR頻度が増えると1時間に1回という制限が足りなくなった
  • レビューの本体は指摘→修正→再レビューの往復であり、1往復ごとに1時間待つと3往復で3時間かかる
  • この制限はリポジトリ単位で人数分ではなく、著者(日本在住)と共同開発者の中島聡氏(Microsoftでウィンドウズ95やInternet Explorerを手がけ、現在もシアトル在住、Yohei氏の父)がアメリカ在住のため、両者の作業時間が重なった日はレビュー枠の奪い合いになった
  • 間違ったコミットでトリガーすると1回分のレビュー枠が消え、また1時間待つことになった
  • まずローカルでClaude CodeからCodexを呼び出すスキルを書いて試したところ調子がよかった
  • CIでも動くのではと考えCodexのAPIキーを設定しワークフロー化したところ機能し、現在の形になった
  • この「手元で回す」用のスキルは現在codex-local-reviewとして存在し、ローカル版が先にありCI版は後から追加された
• CI内で待ちなしにレビューが回ることの重要性:
  • レビューの価値は1回の指摘でなく往復の回数にあり、1往復のコストが上がると質そのものが落ちる
  • 「待つのが面倒だからこの指摘は次でいいか」が始まった時点で終わりだと考えている
  • 人間が「レビューして」と頼む工程や順番待ちが1つでも挟まると自動化の輪から外れる
  • push後に勝手にレビューが始まり戻ってきたら指摘が積まれているという形でなければレビューは自動化に組み込めない
• CodeRabbitも併用:
  • 現在はMulmoTerminal / MulmoClaudeの両方でCodexと並行して稼働
  • 見ている角度が違うため拾う問題も異なる
  • レビュアーは数を増やすより種類を増やす方が効く、同じ穴を3回見るより違う穴を2回見る方が価値がある
• 空港でレビューしていた頃の話:
  • 2人しかいないチームでは、どちらかが旅行に出ると人力レビューが完全に止まる問題があった
  • 以前は空港や機内Wi-Fiでdiffを開きコメントを返していた
  • AIレビュー導入がまず効いたのはここで、誰かが移動していてもレビューが止まらなくなった
  • これがほんの半年前の出来事だったことに書きながら驚いている
• ここで一番大事なこと:
  • ボットの指摘を機械的に全部適用してはいけない
  • 複数ボットを走らせると指摘が矛盾することがある(CodexとCodeRabbitが逆のことを言うなど)、両方満たそうとすると誰も読めないコードになる
  • 指摘を3つに分類する運用にしている
    • 本物の修正: 直してテストを足す
    • 妥当なnitpick: 安ければ直す、そうでなければ「意図的」と返す
    • 誤検知/古い情報: 確認して理由を書いて飛ばす
  • 最後に何を直し何を意図的に飛ばしたかをPRにコメントし、人間がボットのスレッドを全部読み直さずに済むようにしている
  • 「OKが出るまで繰り返す」とはこの分類作業を繰り返すことを意味する
• ループ自体をスキル化:
  • 手作業での繰り返しは疲れるため、ループそのものを公開リポジトリのskills/配下にスキルとして用意しており現在3種類ある
  • codex-local-review: PR化前に作業ツリーやbranchのdiffをローカルでCodexに読ませる、GitHubを往復しないため速い
  • codex-cross-review: GitHubのPRに対しcodex execを回して指摘を受け、評価・修正・再レビュー要求までを行う、最大5イテレーションの安全キャップ付きでイテレーションごとに状態ファイルを残す
  • gh-review-loop: GitHub側のボット(CodexのActions、CodeRabbitなど)が最新コミットに出した指摘を読み、修正・push・再レビュー待ちを行う、gh pr viewに出ないインラインスレッドまで読むのが特徴
  • マージ条件は「全ボットがsign off＋CIがグリーン＋人間が確認」としているが、最後の「人間が確認」は最近ほとんど形骸化しボタンを押すだけになっている
  • それも全自動にしたいと考えており、少し怖さはあるものの人間の確認はすでに機械の結論をなぞるだけになっている
  • それでも人間を残しているのは品質の問題でなく責任の所在の問題だと考えている
  • 全自動化に進む場合、次にやるべきは「もっと賢いレビュー」でなく、何かあったときに確実に戻せること(ロールバックと後から追える記録)だとしている
• その先：判断そのものを学習させる:
  • 現在ボット指摘の3分類判断はまだ著者自身が行っている
  • この判断は過去の自分の判断の積み重ねでできており、学習させた「判断AI」に寄せられるはずだと考えている
  • レビューを機械に移し、マージを機械に移し、最後に判断の基準を移すのが自然な順番だとしている

■ 9. 人間が残った場所

• 自動化を進めた結果、著者が手を動かしているのは次の3つのみになった:
  • UI(見ないと分からないもの)
  • 複雑なもの(仕様そのものが怪しいとき)
  • 人間がテストするしかないもの(体験、手触り、通知のタイミング)
• 著者の仕事は「読む」から「見る」に変わった、diffを読むのでなく動いている画面を見るようになった
• 「GUIは操作するものでなく見るものになっていく」と考えるようになったと述べている(詳細は別記事に譲るとしている)

■ 10. 並列運用を支える道具：MulmoTerminal

• 壊れないことと回せることは別の問題:
  • エージェントを6本並列で走らせるとターミナルが6枚になり、どれが終わったか自分待ちかを目でスキャンする時間がセッション数に比例して増える
  • lintも型もテストもCIもこの問題は解決しない
• MulmoTerminalの紹介:
  • ブラウザで動くターミナル、npx mulmoterminal@latestを実行するとhttp://localhost:34567が開く
  • Node 22.9+とclaude CLIがあれば設定不要
  • @latestを付けるのは、npxが過去にダウンロードしたバージョンをキャッシュから使い回すことがあるため
• 機能:
  • グリッドで全セッションを一望でき、セルの枠色が状態(作業中/自分待ち/完了)を表す
  • 入力待ちで音が鳴り、画面外で詰まったセッションに気づける
  • スマホへのWeb Push通知により外出中でも詰まった1本だけ対応できる
  • 裏側はtmuxで動いており、ブラウザを閉じてもサーバを再起動してもセッションは生きたまま
  • セルごとにgit worktreeを割り当て、複数エージェントが同じリポジトリを同時に触っても衝突しない、グリッドからcommit/push/PRまで可能
  • Claude CodeとCodexの両方に対応し、モデルもセッション単位で選べる
• この記事で紹介した運用は、この道具なしでは回らないとしている、厳しいlintも3OSのCIもレビューの自動ループも並列実行を前提にしているため
• MITライセンスで公開しており、使い方は日本語ガイドにまとめてある

■ 11. やっていないことのほうが本質だった

• レビューをやめられたのは頑張ったからでなく、頑張らなくても壊れないようにしたから
• 超人的なエンジニアになったわけでも手を動かす量が増えたわけでもなく、壊れたときに勝手に赤くなるものの数が増えただけ
• ボトルネックの所在が移動した:
  • 昔: 書く速度がボトルネックだった
  • 少し前: 判断する速度がボトルネックになった
  • 今: 統合する速度(CI、レビュー、マージ、コンフリクト)がボトルネック
• 並列で回せる数の上限は注意力でなく道具がどれだけ状態を持ってくれるかで決まる
• 同様に、読まなくて済む量は壊れたときに赤くなる仕組みの量で決まる
• レビューをやめたのでなく、レビューを機械に移しただけだとまとめている
• 今後の目標は自分の判断をAIに学習させ、その判断で最終的にマージまで自動で回すこと:
  • ボットのどの指摘を直しどれを「意図的」と返したか、どのPRをマージしどれを差し戻したかの履歴はすべてGitHubに残る過去の判断ログである

■ 12. で、楽になったのか

• 自動化を進めても楽にはならず、むしろ忙しくなったと述べている
• 思いついたことがその日のうちに動くようになり、動くと触り触るとまた思いつくというアイデアの回転が上がった分やることが増えた
• 減ったのは「待っている時間」と「読んでいる時間」であり、仕事そのものではなかった
• 奪われたのは仕事でなく「時間がないからできない」という言い訳の方だったとしている

■ 13. 読者への問いかけ

• 自分の書いた(書かせた)コードをまだ全部読んでいるかを読者に問いかけている
• 読んでいないなら代わりに何が守ってくれているか、読んでいるならいつまで読めそうかを知りたいとしている

■ 14. 真似するための実践ガイド

• 記事に出てきた内容は3つのリポジトリで実際に動いており、そのままコピーすれば同じように動くとしている:
  • isamu/claude: 全プロジェクト共通のCLAUDE.md / docs/ / レビュー用skills/
  • receptron/MulmoTerminal: eslint.config.js / .github/workflows/ / リポジトリ側CLAUDE.md
  • receptron/MulmoClaude: eslint.config.mjs / .github/workflows/
• 導入は全部いっぺんに行う必要はなく、効く順に並べると次の通り:
  • 別モデルによるレビューをCIに入れるが最も効く、ワークフローを1本コピーするだけで翌日から指摘が流れてくる
  • ESLintのサイズ・複雑さ・型の締め付け、既存コードが赤くなるためまずwarnで入れゼロにしてからerrorに上げる(drainしてからratchet)
  • ルールをpure関数に切り出してテストする、設計の話のため時間がかかるが最も寿命が長い
  • CIを3OSに広げる、手元にない環境を持つにはこれしか方法がない
• 逆に最初にやらなくてよいのは重複・デッドコードのスキャン:
  • これは量が増えてから効くもので、初日から入れても「回避の作法」を覚えるだけだったとしている
• 関連記事として、並列運用を扱う6本のシリーズの一部であることを紹介している