■ 1. Linuxへの移行が進んでいる証拠
- 同僚のJack Wallenと筆者は以前からWindowsからLinuxへの乗り換えを提案してきた
- 一部の人々にその声が届いているようである
- Zorin OS 18の事例:
- 公開からわずか1カ月余りで100万件のダウンロードを達成した
- そのうち78%以上がWindowsユーザーによるものである
- 78万人ものWindowsユーザーが3.5GBものLinuxデスクトップディストリビューションをダウンロードするのは単なる気まぐれではない
- Linuxデスクトップの愛好家なら異なるディストリビューションを試すのは趣味の一環だが、Windowsユーザーの場合は本気でLinuxへの移行を検討していると考えるべきである
■ 2. Linuxデスクトップの市場シェアの成長
- StatCounterのデータによれば、2020年にわずか1.5%だったLinuxデスクトップの世界シェアは、2024年には4%を超え、2025年には米国で過去最高の5%超に達した
- StatCounterの最新の米国データ(10月まで)ではLinuxは3.49%と表示されている
- ただし「unknown」が4.21%を占めている
- 推測としてこの「unknown」はLinuxを動かしているのではないか
- 他にFreeBSD、UNIX、OS/2である可能性は低い
- ChromeOSは3.67%とされているがこれは低すぎる印象である
- ChromeOSもLinuxの一種である(KDE PlasmaやCinnamonなどのLinuxデスクトップ環境ではなく、Chromeブラウザーをインターフェースとして使っているだけ)
- これらを全て合算するとLinuxデスクトップの市場シェアは11.37%になる
■ 3. エンドユーザーOS全体におけるLinuxの立場
- PCだけでなくスマートフォンやタブレットを含むエンドユーザーOS全体を見れば、Linuxの立場はさらに強固である
- 米国ではAppleのiPhoneが人気だが、StatCounterの最新データによるとAndroid(これもLinuxディストリビューション)が41.71%のシェアを誇っている
- 世界全体ではAndroidが72.55%という圧倒的なシェアを持っている
- PC、タブレット、スマートフォンを含むエンドユーザー向けOS全体の指標を広げて捉えるならば、Linuxこそがすでに支配的な立場にあると合理的に主張できる
■ 4. Digital Analytics Program(DAP)から見た現状
- StatCounterの数字には問題があるとの指摘がある
- 筆者がOSのシェアを確認する際に好んで使うデータソースは米国連邦政府のDigital Analytics Program(DAP)である
- このサイトは米国政府のウェブサイトへの訪問数とその分析をリアルタイムで提供している
- 過去30日間の平均セッション数は16億件に達し、1日当たり数百万のユーザーが訪問している
- DAPはデータを加工することなく、人々が実際に何を使っているかを詳細に示している
- DAPはGoogle Analyticsのアカウントから生データを取得している
- DAPはデータをウェブ上に表示するコードやデータ収集コードをオープンソース化しており、JSON形式でデータをダウンロードして自分で解析することもできる
- DAPの集計結果:
- Linuxデスクトップのシェアは現在5.8%である
- 筆者が10年前にDAPの数字を見始めた頃、Linuxデスクトップのシェアはわずか0.67%だったことを考えると驚くべき成長である
- Chrome OS(1.7%)とAndroid(15.8%)を加えると、米国政府のウェブサイトにアクセスするユーザーの23.3%がLinuxユーザーということになる
- Linuxカーネルのユーザー向けの存在感は「デスクトップLinux」というラベルが示す以上に大きい
- Windows 10とWindows 11の状況:
- Windows 10はすでに引退期に入っているはずだが、DAPの数字では依然として人気があり16.9%を占めている
- Windows 11は13.5%である
- これに対しStatCounterでは米国においてWindows 11がリードしており、全Windowsユーザーの64.83%を占め、Windows 10は31.92%と大きく後退している
- それでもWindows 10を使い続けてセキュリティリスクを抱えているユーザーがあまりにも多い
- IT資産の検出とインベントリーを行う企業Lansweeperによると、1500万以上の消費者向けデスクトップOSを分析した結果、Linuxデスクトップは現在PC市場シェアの6%強を占めている
■ 5. Linuxが成長している理由(当初挙げた5つの要因)
- 筆者は2025年、WindowsからLinuxへの移行を促す要因として5つを挙げた:
- MicrosoftがWindowsを製品として扱う姿勢からMicrosoft 365やクラウドサービスへ重点を移したこと
- SteamとProtonによるゲームの実用性向上
- 主要ディストリビューションの使いやすさが劇的に改善されたこと
- ハードウェア対応の拡大
- プライバシーやデータ管理への懸念の高まり
■ 6. 追加で浮上した3つの要因
- Windows 11へのアップグレードができないハードウェア制約:
- 多くの企業やユーザーがWindows 11に「アップグレード」できないにもかかわらず、まだ十分に使えるWindows 10マシンを所有している
- ControlUpの調査によると、消費者および企業のWindows 10マシンの約25%はWindows 11に移行できない
- このハードウェア制約はMicrosoftの仕様を満たすためだけに新しいマシンを購入するのではなく、Windows 10のサポート終了後も使い続けようとする大きな理由になっている
- Windows 11への移行を強く望んでいない事実:
- 英国の消費者団体Which?が2025年9月に実施した調査では、回答者の26%がアップデート終了後もWindows 10を使い続ける意向を示した
- 興味深いことに6%はLinuxなどの代替OSへの移行を計画している
- ユーザーがためらう主な理由は3つ:
- Windows 10は「十分に良い」
- Windows 11は意味のある改善と見なされていない
- 強制的なインターフェース変更(中央配置のスタートメニュー、コンテキストメニュー、既定アプリの挙動、Copilotの統合)を好まない
- ゲーマーはWindows 11がゲームを遅くしたり互換性の問題を引き起こしたりするのではないかと懸念している
- 実際、Windows 11の10月のアップデートではNVIDIA搭載の一部ゲーミングPCでパフォーマンスを低下させるバグが発生した
- Windows 11のAIエージェント型OSへの変貌:
- Windows 11がAIエージェント型OSへと変貌していることを全ての人が歓迎しているわけではない
- AIブームにもかかわらず、Microsoftに行動を逐一監視されるようなAIを望まない人もいる
- MicrosoftでWindowsおよびDevices担当プレジデントを務めるPavan Davuluri氏が11月10日に「Windowsはエージェント型OSへ進化し、デバイス、クラウド、AIを接続して、インテリジェントな生産性と安全な作業環境を実現する」とXに投稿した際、ユーザーがこのビジョンを歓迎することを期待していた
- しかし現実は違った
- 最も多くの反応を得たコメントは「それはMacやLinuxへの移行を促す製品に進化している」というものだった
- AIによる監視を受けず、自分のPCで何が起きているかを完全にコントロールできる従来型のデスクトップを求めるなら、今後Linuxがほぼ唯一の選択肢になる
■ 7. デジタル主権の問題
- WindowsからLinuxへの移行を検討する最後の理由は、米国のユーザーにとってはあまり重要ではないが、米国外のユーザーにとっては非常に大きな意味を持つ
- 欧州連合(EU)の政府は米国の政治的圧力の下でMicrosoftがサービスの約束を果たすことを信用していない
- この不信感は「デジタル主権」という取り組みに発展し、EU企業が米国のテック大手よりもはるかに信頼できる存在と見なされるようになった
- その結果、多くのEU加盟国はMicrosoftのプログラムを廃止し、オープンソースソフトウェアへと移行している
- それはデスクトップ分野にも及んでいる
- あるEUグループは「EU OS」を開発した:
- FedoraベースのディストリビューションにKDE Plasmaデスクトップ環境を採用したLinuxデスクトップの概念実証版である
- こうした動きはEUに限らない:
- 英国もまたMicrosoftにデータを委ねることを信用しなくなっている
- 2024年にComputer Weeklyが報じたところによると、Microsoftはスコットランド警察に対しMicrosoft 365やAzureのデータが英国国内にとどまることを保証できないと伝えた
- 当時、英国内閣府の元ICT責任者であるNicky Stewart氏は「Microsoftは『主権クラウド』と称するものを売り込んでいるが、主権とは何を意味するのか。真に主権的なデータであれば、いかなる状況でも海外に送られることはないはずだ」と語った
- Windows 11のデータが米国のデータセンターとの間でやりとりされる可能性がある以上、今後ますます多くの政府がWindowsを信用することに慎重になる
■ 8. 結論
- これら全ての変化を総合するとLinuxはもはや「マニア向けの特別な選択肢」ではなく、Windowsのアップグレード地獄やサブスクリプションモデルから抜け出したい人々にとって現実的な選択肢となりつつある
- デスクトップLinuxは長年の「負け犬」から脱却し、日常的なコンピューティングにおいて小さいながらも意味のある存在へと進化している
- 特に技術に精通したユーザー、米国外の公共機関、そしてより安価で信頼できるデスクトップを求める一般消費者や企業ユーザーの間でその存在感を高めている
■ 1. AIと歴史的先例の比較
- AIは様々な歴史的先例(電気、産業革命など)と比較されてきた
- 最も強力な類似性はAIを新しいコンピューティングパラダイムとして捉えることである
- なぜなら両者は根本的にデジタル情報処理の自動化に関するものだからである
■ 2. Software 1.0時代の特徴(1980年代のコンピューティング)
- 1980年代に雇用市場へのコンピューティングの影響を予測する場合、タスク/仕事の最も予測力のある特徴は「指定可能性(specifiability)」であった
- 指定可能性とは、機械的に情報を定型的で簡単に指定できるアルゴリズムに従って変換しているだけかどうかである
- 例:タイピング、簿記、人間計算機など
- 当時、これはその時代のコンピューティング能力が手作業で手動で書くことを可能にしたプログラムのクラスであった
- 筆者はこの手書きプログラムを「Software 1.0」と呼んでいる
■ 3. Software 2.0時代の特徴(AI時代)
- AIによって、これまで手作業では書くことができなかった新しいプログラムを書くことができるようになった
- 方法:
- 目的(例:分類精度、報酬関数)を指定する
- 勾配降下法を介してプログラム空間を探索し、その目的に対してうまく機能するニューラルネットワークを見つける
- これが筆者が以前のブログ投稿で述べた「Software 2.0」である
- この新しいプログラミングパラダイムでは、注目すべき新しい最も予測力のある特徴は「検証可能性(verifiability)」である
■ 4. 検証可能性の定義と条件
- タスク/仕事が検証可能であれば、直接的にまたは強化学習を通じて最適化可能である
- ニューラルネットは極めて優れた動作をするように訓練できる
- これはAIがどの程度何かを「練習」できるかということである
- 環境は以下の条件を満たす必要がある:
- リセット可能(resettable):新しい試行を開始できる
- 効率的(efficient):多くの試行を行うことができる
- 報酬可能(rewardable):行われた特定の試行に報酬を与える自動化されたプロセスが存在する
■ 5. 検証可能性と自動化の関係
- タスク/仕事が検証可能であればあるほど、新しいプログラミングパラダイムにおける自動化に適している
- 検証可能でない場合、以下のいずれかに依存する必要がある:
- ニューラルネットの汎化の魔法から生じることを期待する(指を交差させて祈る)
- 模倣のようなより弱い手段を使う
■ 6. LLMにおける進歩の「ギザギザした」フロンティア
- 検証可能なタスクは急速に進歩する:
- トップエキスパートの能力を超える可能性も含む
- 例:数学、コード、動画視聴に費やされた時間、正解のあるパズルのように見えるもの
- 他の多くのタスクは比較的遅れている:
- 創造的なタスク
- 戦略的なタスク
- 現実世界の知識、状態、コンテキスト、常識を組み合わせるタスク
- これがLLMの進歩における「ギザギザした(jagged)」フロンティアを推進している
■ 7. まとめ
- Software 1.0は指定できるものを簡単に自動化する
- Software 2.0は検証できるものを簡単に自動化する
■ 1. GitHubの考察記事の公開
- GitHubは開発ツールとしてAIが導入されていくことで、プログラミング言語やフレームワークの選択にどのような影響を与えるかを考察したブログ記事を公開した
- 記事タイトルは「TypeScript, Python, and the AI feedback loop changing software development」(TypeScript、Python、そしてAIフィードバックループがソフトウェア開発を変えていく)である
■ 2. AI導入による静的型付け言語の選択傾向
- 静的型付け言語の方がAIがより正確なコード生成を行いやすい傾向にある
- それゆえにAIツールを利用する開発チームでは開発者の好みよりもAIとの相性が良いプログラミング言語が選ばれるようになる
- 多く使われるプログラミング言語はAIによる学習がより強化される
- それによってさらに多くの現場で使われるようになるというフィードバックループを形成していく
- 今年GitHubで最も使われている言語として、昨年まで1位だったPythonを抜いてTypeScriptが1位となった
- その背景にはこうした理由があったとされている
■ 3. AIとの相性が良い言語の特徴
- AIとの相性が良い言語が選ばれやすくなる傾向はTypeScriptに限らない
- Python、Java、Goのようにすでに大量のサンプルコードが世の中に存在し、同時にさまざまな目的に利用できるフレームワークが充実しているプログラミング言語ほど、AIによるコード生成で目的の達成が容易である
- そのためAIによる目的の達成が容易なプログラミング言語ほど、開発言語として選択されやすくなると予測されている
- AI登場以前、プログラミング言語の選択はランタイムとライブラリエコシステム、そして個人の習熟とのトレードオフであった
- しかしAI登場後は新たな制約が表面化する
- それはある言語を選択したときに、それがAIモデルによってどれほどの利点があるか、という点である
■ 4. AIによる適切な言語選択の容易化
- AIの登場は人気のプログラミング言語の人気をさらに増加させる傾向がある一方で、プログラムとプログラムをつなぐ「ダクトテープ」のような役割を担うBashのようなシェルスクリプト言語の利用増加にも貢献した
- それはコーディングの面倒な部分をAIに任せることができるようになったことで、開発者はその言語の好き嫌いよりも適切なツールかどうかを選択基準にしやすくなったためである
- つまりAIは単純にTypeScriptのようなプログラミング言語への人気の集中を招くわけではなく、開発者の好き嫌いや習熟の度合いによって乗り越えられていなかった目的に沿って適切なプログラミング言語を選択することも容易にする
■ 5. 結論
- 開発者はTypeScriptのように特定の言語を学ぶべきというわけではない
- 次の10年で生き残るであろう言語とツールとは、デベロッパーが最も好むものではなく、デベロッパーとマシンの両方が最も利点を共有できるものになるだろう
■ 1. 発表者の背景とテーマ
- 発表者は横山(ハンドルネーム:ゆずたそ)で、風音屋という会社に所属している
- データウェアハウスやデータ分析系の活動を行っている
- 風音屋はデータ分析、データ基盤の構築を支援する会社である
- 昨年「アジャイルデータモデリング」という訳書を出版した
- テーマはExcelデータ分析でディメンショナルモデリングを扱う
- エントリー向けの内容を紹介する
■ 2. データ分析の前提条件
- 構造化データを扱うことを想定している
- 構造化データとは行や列など表形式で表現されるデータのことである
- これは従来のデータベースが前提としている形式で、最も安定してデータを管理利用しやすい
- テーブル(表形式)で管理するデータの関係性を表現したER図がある
- テーブル名と列名があり、Excelで例えるとシート名とその中に並ぶ列のようなイメージである
- 複数のテーブルをIDや識別値で結合していく
- 細かくテーブルを分けていくとデータの更新箇所が最小限で済む
- モデルの書き方として概念モデル、論理モデル、物理モデルといった書き方がある
- 正規化と呼ばれる概念がある:
- データの重複や不整合を防いで効率的に管理するために行う
- いくつか正規化の形があり、その条件を満たすようにテーブルを分解していく
- 第3正規化された状態のことを第3正規形と呼ぶ
■ 3. Excelでのデータ分析における課題
- ビジネスパーソンは以下のような流れでデータ分析を行っている:
- ローデータ(機関システムから出力したものなど)を一旦貼り付ける
- 注文テーブル、商品のシートなどがある
- それらを元にして別のExcelタブで集計を行う
- 最終的に表示したい形式(例:商品カテゴリー別の毎月の注文数)を出す
- この集計データを作ってからグラフに表示する
- 最終的に見たい形は正規化されたものではなく、分析要件に基づいて集計した結果である
- 営業地域別と業種別の切り替えの問題:
- 多くの会社では日々の業務要件に適した形でデータを管理しがちである
- 営業地域ごとに営業署があり、それぞれの中で管理している場合、営業地域別でデータを管理することになる
- 担当エリアがあり、エリアに合わせてフォルダーが分かれている
- 年月ごとにシート分けしている(例:京都の1月、2月、3月)
- この単位で入力するため、入力しやすい形でシステムが作られていく
- モニタリングも基本的には年月と地域の単位で行われる
- 当初は想定していなかった観点(例:業種別)でレポートを作るニーズが発生することがある:
- マーケット環境が変化した時に適用するため
- コロナのような事態が発生した場合、業種別で数字を見る必要が出てくる
- 飲食店などの店頭サービス業での契約が減っている可能性がある
- 逆にこの状態で伸びている業種があるかもしれない
- Excelファイルごとに分かれていると全部のシートを開いて業種の列を抽出していく作業が発生する
- これはあまり現実的ではない
- 当初の要件を満たすテーブルではなく、切り口を柔軟に変更できるテーブルが求められる
■ 4. データ分析における複数データソースの組み合わせの必要性
- データ分析を行う時は複数の元のデータを組み合わせていくことが一般的である
- 例:駅に近い店舗は雨の時だけ注文が上がった/下がったからクーポンを打つ場合:
- 駅がどこにあるのかという情報が必要
- 店舗がどこにあるのかという情報が必要
- 駅に近いかどうかを判定する必要がある
- 天気の情報が必要
- 注文数がどう変わっているかの情報が必要
- これらを組み合わせて使う必要がある
- 駅と店舗は住所が書いてあるが距離を測るには緯度経度が必要になる可能性がある
- 住所と緯度経度を変換するための前処理が必要で、そのための変換データを引っ張ってくる必要がある
- 店舗マスターは社内にある、駅の情報もどこかにある、住所と緯度経度の変換データもどこかにある、天気のデータは気象庁から引っ張ってくるなど、様々なものを集めてきて組み合わせていく
- データは事前に統合されていて一元管理されている方が分析する側からすると嬉しい
- データ基盤という言葉が一部で注目されている
- 複数のユースケースと複数のデータソース(情報源)をリボンのように結びつけていく一連のサービス群がデータ基盤と呼ばれるものである
■ 5. 正規化の問題点
- 正規化すれば解決するのではないかという考え方がある
- シートを細分化して第3正規形などで作る
- 契約の一覧、相談問い合わせ、契約明細、商品一覧、プロモーション一覧、顧客一覧、業種一覧、都道府県一覧、従業員一覧、所属一覧、部門一覧、担当エリア一覧などに細かく分ける
- 顧客の中に業種IDや都道府県IDがあるため、都道府県IDを見ていたところを業種IDを見るようにすれば集計は簡単にできる
- 理屈上は可能である
- ただし使う側(ビジネスユーザー、ITスキルが必ずしも高くないユーザー)からすると使いにくいポイントがある:
- 毎回分析やモニタリングをするたびにER図を読む必要がある
- そもそもER図の読み方を勉強しなければいけない
- 数十枚あるシートを連携していく必要がある
- 毎回その結合時の注意点をチェックしていく必要がある
- キャンペーンの分析をする場合は日付の曜日や祝日を毎回計算する必要がある
- データをどう組み合わせるかを使う時に考える必要がある
- 使う側のリテラシーを求めてしまう
- 分析の時にこれとこれとこれを結合してというのはややこしい
- 結果として使う側がユーザー手元でカスタマイズして結局自分用の使いやすいシートを作ってしまう
- 顧客一覧、業種一覧、都道府県一覧を3つのシートに分けるのではなく、顧客一覧シートの中で列として業種や都道府県の結果も書いてしまう
- これは使われないモデリングである
- 第3正規形が悪いわけでは当然なく、システム作る上で分けていった方がいい場面はもちろんある
- 記入やインサート・アップデートを考えてももちろん正規化の方がやりやすい
- ただし使う側がこうやって使ってしまうことは起きがちである
- 使う側の立場にちょっと寄り添う必要がある
- 最初から使われるこのシートをモデリングする側が提供するのも一つある
■ 6. ディメンショナルモデリングの基本概念
- トランザクションとマスターで分けるとちょうどいい
- ファクト(トランザクションに近いもの、集計対象となる出来事):
- 例:契約シートが1個ある
- これを見ると合計でいくらの契約になったかが分かる
- ディメンション(マスターに近いもの、比較の切り口となる軸):
- 顧客ディメンション:業種別、エリア別の契約金額などの切り口のヒントになる
- 従業員ディメンション:部署別の契約金額や営業成績などに使える
- カレンダーディメンション:今月の契約金額、祝日や曜日によって効果が違うかを見る
- 日付に対して祝日かどうか判定するフラグがあってもいい
- データ分析の場合、日付は結合キーになることがあり得る
- キャンペーンの取り組みと実際に注文があった時を紐付けて、このキャンペーンには効果があったかを判定することがある
- ファクトとディメンションを組み合わせて使えば使うだけで良い
- 契約の件数がどのくらい増えているか減っているかは、顧客のシートと組み合わせて顧客のシートの方で業種や都道府県を切り替えて見ていけばいい
- 使う側の都合だけを言うとこのくらいシンプルだと分かりやすい
- これがディメンショナルモデリングと呼ばれるものである:
- ディメンション(分析の切り口)とファクト(集計対象となる出来事・事実)を提供するテーブル設計手法である
- これらを組み合わせてデータ分析を行う
- 昨年出版した「アジャイルデータモデリング」という本はこれを紹介する本である
■ 7. データ分析の概念的説明
- 緑のキューブがあり、これが売上累計30億円という大きな事実(ファクト、出来事)の塊である
- データを分析する時はスライスしていく:
- いろんな次元にスライスしていく
- この期間での売上という風に切るとそれが2億円まで減る
- さらに製品で切っていくと5000万円まで減る
- さらに店舗という場所で分けていく
- 全体のキューブの中のこの部分まで絞ると800円になる
- これを比較する:
- この製品とこの製品で比べてどうなのか
- 去年と比べて去年調子良かったのか悪かったのか
- コロナの前と後でどのくらい減っているのか
- こうやって分けて比べていくのがディメンション(次元)である
- 多次元で切っていく、分析していくからである
- 実際の例:倉しコム(数年前に上場した新興企業、ECサイトを提供):
- BIツールを使って画面上でディメンションをポチポチと絞り込んでいく
- 直近90日で日時で見たい、モバイルアプリとウェブサイトで分けて見たい、商品のカテゴリーごとに分けたいなどを指定していってボタンを押すと欲しいデータが出てくる
- 使う側は相当楽である
- ファクトとディメンションの組み合わせをポチポチ選んでいけば集計できる状態が使う側だけからすると理想である
■ 8. BEAMフレームワーク
- BEAMとは:
- ビジネスイベントアナリシス&モデリング(Business Event Analysis & Modeling)の略である
- ビジネス上の出来事から要件分析してテーブルを設計していく
- 結果としてスタースキーマ(真ん中にファクトがあって周りにディメンションがある形)を作る
- スタースキーマは星型に見えるのでスターと呼ばれる
- ステイクホルダーと協力しながらブレインストーミングを行ってデータモデリングを進めるアプローチである
- このモデリングは使う人向けのテーブル設計である
- この本ではモデルストーミングと呼んでいる
- BEAMテーブル:
- どんなデータが欲しいのかを具体的に書いていく
- この人がこれをいつここで買ったみたいな情報が欲しいというのをずらっと実際に書いていく
- なるべく具体的に書いていく
- 最大で10年前まで遡りたい、最短で翌日にはデータを使いたい、物販と自社のECと外部ECまで分析したいなどの要件が見えてくる
- 元のデータベースは違う可能性がある(物販の店舗だとPOSレジにデータがある、自社のECと外部ECでデータベースも違う)
- データをどこに保存するかというモデリングをするとこれらはバラバラになるはず
- しかし使う側からするとこれらはまとめて分析したいので同じディメンションに入れる必要がある
- この差が見えてくる
- クリエイト(作成)やアップデート(更新)をするのとは別にリード(読み取り)に特化したモデルがあるだろう
- そのためにはその要件を顕在化するにはどんな風にデータを使いたいんですかというところの分析をする人がどんなデータが来るといいのかという具体例を書いていくことによって隠された要件を暴り出していく
- イベントマトリックス:
- ファクトとディメンションをマトリックスで書いていく
- 縦にディメンション、横にファクトを書いて、その組み合わせをチェックしていく
- これらを使って定期的なミーティングでこれらの中間成果物を更新したりしながら、次はこれを整備していこうかというTODOリストを作ってそれを対応していくサイクルを回していく
- これをアジャイルのプラクティスに沿ってやっていくことによって変化に対応していく
- これがアジャイルデータモデリング(原書タイトル:アジャイルデータウェアハウスデザイン)でアジャイルという言葉を使っている理由である
■ 9. ファクトのモデル化
- 分析対象の構造を確認する:
- ビジネスの構造、業務フロー、業務の流れ、ユーザーの行動などをまず把握していく
- ファクト(集計対象、トランザクションファクト)は以下に分けられる:
- 出来事
- 指標
- 計算方法
- ビジネスイベントの洗い出し:
- モデル化した図からビジネスイベントを洗い出す
- 来店して注文して発送して返品するみたいな流れがある
- 注文と呼ばれるビジネスの中にも指標がある(件数、人数、商品数、金額など)
- さらに計算方法もメリットがあるかもしれない(合計値、1人当たりの注文件数、1商品あたりの注文件数、YoY(去年に比べて今年がどのくらい増えているか)、増加率、増加数など)
- ビジネスイベント:
- ビジネスにおいて発生する出来事である
- この1つ1つのビジネスイベントが繋がってビジネスは実現される
- ビジネスを改善するのはこの1つ1つのビジネスイベントを改善することとニアリーイコールである
- 例:来店を増やす、注文を増やす、発送を早くするなど
- 指標:
- ビジネスイベントを定量的に評価するための指標を定める
- イベントがどうなって欲しいか、どうなると困るかを見ていくと決まるはず
- 件数、人数、商品数、金額、時間、距離など
- 多い少ない、長い短い、重い軽いなどの観点がある
- 計算方法:
- 注文の中にも合計、1人当たり、1品あたりといったものがある
- 場合によってはツールに任せるケースもある
- テーブルとしてモデルに反映するのか、ツールに任せるのかはやり様がある
■ 10. ディメンションのモデル化
- ディメンションは5W1Hで考えると分かりやすい:
- 誰が、何を、いつ、どこで、なぜ、どのように
- ビジネスにおけるデータ分析の場合、分析軸5W1Hで比較することが多いから
- 例:都心の店舗は郊外の店舗よりも客が多い(Where)、今年は去年より注文が増えている(When)、バッグは靴よりも平均単価が高い(What)
- どんな軸で分けて比べるのかを洗い出していく必要がある
- 洗い出しのヒント:
- 業務フローから洗い出すパターン:
- 誰が何に対してどんな作業をいつするのかが見えてくる
- 店頭スタッフという人がいて、各商品の在庫があって、毎日20時お店が閉まった後に棚卸しをするなどが見えてくる
- スタッフ別の切り口で分析をするかもしれない、商品ごとや在庫ごとに分析をするかもしれない、閉店後か閉店前かによって分析の軸が変わってくるなどが見えてくる
- 具体例(レコード)から洗い出すパターン:
- 同じ商品AとBがあった時に両方とも衣類という共通点がある場合、商品カテゴリー「衣類」がある
- サイズで言うと同じ衣類でも夏物と冬物がある場合、販売時期という観点で見ていくとポイントがあるかもしれない
- 一般的に冬物の方が重くて値段が高かったりすることが多い
- 同じレコードの中のレコードの共通点や差異点を言語化していくと、そこがそのまま切り口になっている可能性が高い
- 階層図:
- 同じ商品でもカテゴリーもあればサブカテゴリーもある
- 衣類があれば衣類の中に夏物というカテゴリーがあるかもしれない
- 価格帯も1円単位の価格よりは1万円単位でまとめるとか
- ユーザーや人間も性別と年齢がある
- 性別と年齢は相互に連動しない概念である
- ただし年齢「◯◯歳」と「◯◯代」はここは階層の粒度がより荒いのと細かいのになっている
- 25歳と20代は粒度の関係になっている
- 荒い方から細かい方に直すことはできないが、細かい方から荒い方に丸めることはできる
- 20代から25歳は言えない(26歳かもしれないから)が、25歳は20代であることは言える
- 細かい方で持っておけば荒く出すことはできる
■ 11. ディメンションテーブルの具体的設計
- 商品ディメンションの作り方:
- 使う側が便利なExcelを作ろうとしたらどうなるか
- 正規化しない状態でどうやって作るか
- 価格という1円単位の列があった後に価格帯1万円単位という列も作っておく
- 27円みたいなのが次は「1万円台」という値が入る
- カテゴリーとサブカテゴリーがあるなど
- 横に必要な粒度で集計できるように1番細かい状態を持たせておきながら、必要な粒度があるんだったらそれも集計できるようにしておく
- カレンダーディメンションの考え方(よくある質問):
- 8月1日13時29分11.55秒をディメンションテーブルでどうやって切り出すか
- ディメンションは単に5W1Hで切ったものではなく、あくまで分析軸である点がポイント
- 0.55秒であることを軸にして何かカウントしたいか集計したいか→大抵の場合ノーである
- たまに工場の産機器や自動車の機器が特定の時にだけ変な挙動をする可能性もあるかもしれないが、それは分析定義はアドホックで都度個別的にクエリを書いた方が良く、毎月毎月Excelシートで役員たちがモニタリングをするのとは違う
- これであればテーブルとして用意するのではなく都度仮説があったらデータを直接見る方がいい
- 8月1日であることを軸にしてカウントしたいか→イエスである(ケースバイケースだが、こういったケースが多い)
- 日付からロールアップして、8月は例年売上が高い、この月曜日は、夏は毎年こうだ、この曜日は毎週こうだという特徴があるかもしれない
- 8月1日を軸にしてこういったいろんな属性をつけていくことはあり得る
- カレンダーディメンションを作っておいて日付ごとに1レコードのテーブルを作っておくのは1つのプラクティスとして有効である
- 13時であることを軸にしてカウントしたいか→三角(UELか)くらいである
- 飲食店だったらこの昼の時間帯や13時代の客数を集計したくなる可能性はある
- シフトを決めるのにどのくらい来るのかによってシフトを決める必要があるから
- 大きな経営計画を立てる時にざっくりとした推定を行うにはこういった情報があった方がいいかもしれない
- ただしこれは8月1日とは関係なくはないかもしれないが、ちょっとまた別の文脈である
- やるとしたらカレンダーディメンションとは別に時計ディメンションを作っておいて日付を付与しないで何時何分だけ持たせるのが1個テクニックとしてはある
- 分析の粒度でこれを本当に1時間単位にするか、細かく1分単位にするか、10分単位や30分単位にするかは分析の粒度に合わせて調整していくのが現実的である
- 5W1Hに囚われるというよりは分析軸を意識して設計する
■ 12. アジャイルデータモデリングの必要性①チームの変化
- チームが変わるからデータモデリングを変えていくことが大事である
- 仮想ケースの例:
- 刑人(経営者):データをモニタリングできるようにしたい
- コンサルタント:ERPを整備しよう、収支や在庫などの経営資源を管理するのが重要
- 取締役:リソース調整はできるようになったが、もうちょっとビジネスを成長させるための中身の話をしていきたい
- 事業部長:うちのメインの事業、Web経由の申し込みで結構予算達成が左右される、ここを見た方がいいんじゃないか、事業成長のエンジンをウォッチするのが大事
- マーケティング担当:アクセス解析ツールで見ましょう、どこの工程で止まっているのか、どの経路が活発なのか見よう
- 経路5はすごく調子がいい、経路3は割と早々に工程2で止まってしまう
- 経路3は一旦捨てて経路5に集中しようという会話ができる
- この日人気YouTuberが商品言及してくれた、SNSですごい話題になった
- アクセス解析ツールを見ると指名検索(商品名で検索してきている)であることしか分からないが、YouTuber効果なんじゃないか
- そしたらもうYouTuberとガンガンコラボしたり広告出した方がいいんじゃないか
- SNSの投稿なども含めていろんな関連データを社内外横断して見たい
- それをできれば社員全員がモニタリングしてどんどん仮説を回していきたい
- データエンジニアやソフトエンジニアがそういった基盤を作ってマーケティング担当がこれを見ながら全社員マーケティングやってくぞという動きになってくるかもしれない
- 会社全体で追うべきデータは当初の想定とはだいぶ違ってくる
- チームが何を重視するかは本人たちでも事前には予測できない
- 当然見るべきデータも変わってくる
- 見るべきデータが変わるということは、データをどこに保存するかを一旦置いといて、どうやって見るか、データを分析する時にどういうデータの形式だと使いやすいかという使う側のデータモデルのあり方は少なくとも変わってくるはず
- アジャイルな仮説検証サイクルは大事だが、今どんなデータがあるといいんだっけというのを言語化して、それを実装してデータを整備して分析してまた色々見えてくるので要求が変わってまた反映していくというサイクルを回す
- このデータモデルを継続的に改善するというサイクルを回して要求の変化に対して迅速に対応していく、適用していくのがポイントである
- だからアジャイルデータモデリングである
■ 13. アジャイルデータモデリングの必要性②ビジネスの変化
- ビジネス自体が変わる話をする(仮想ケース、あえて極端な話):
- 自動車メーカーからゲームメーカーに転進することがあるかもしれない
- 乗り物の部品を作っている町工場のメーカーがあった
- 売上は堅調だが物価高等で苦しくなってきた
- 主要販売先や銀行からプレッシャーを受けている
- 反応を拓の位置を下げるために展示会で新素材を体験してもらおう
- デモンストレーションとして体験型の運転シミュレーションゲームをセットで設置した
- ものづくり好きな技術者が最高のクオリティに仕上げてしまった、レベルが高すぎる
- 展示会にゲスト参加した海外の著名人がSNSで言及して世界中で話題になった
- 試しにゲームを販売したら世界中で飛ぶように売れる
- しかも円安でソフト産業は限界利益が少ない、部品に比べて収益率がすごい高い
- 本当に黒字赤字ギリギリみたいな状態だったら部品の利益を超える可能性もある
- 部品メーカーとして20年使えるはずのデータモデルを設計してERPを導入したところが、今ゲームメーカーとしてどんどん伸びている
- どっちかっていうとゲームのプレイヤーの利用状況やSNSで話題になっている箇所、どこがスクリーンショットで取られているのかを分析する方が実は重要になってくる可能性もある
- さらにCG制作会社、芸能プロダクションになってくることもあるかもしれない
- 物の珍しさで最初はゲームが売れたが、徐々に売れなくなってくる
- むしろ他のゲームメーカーからゲーム内の乗り物のCGを作ってくれないかという相談を受ける
- CG制作会社として大活躍、めちゃくちゃ細かいところまで作り込んでいる
- ゲームだけではなくて映像作品、世界中の映像作品でも引っ張りだこになる可能性もある
- 日本のアニメーション映画が全世界でヒットしているというトレンドに乗って、海外のあらゆる映像関係者が注目するような会社になるかもしれない
- CG制作会社としてモニタリングをすることになるかもしれない
- 映画特集のテレビ番組に社員が出演する、社員の対応が結構いい感じで俳優じゃないかということでまた話題になる
- 各局に呼ばれるかもしれない、結果芸能プロダクションとして有名になる可能性も0じゃない
- 芸能プロダクションとしての形態のモデルになってくる
- 実際にビジネスは結構変わっている:
- 旗売機を作っている会社が自動車を作り始める(トヨタ)
- アニメーション映像を作っている会社がテーマパークも作り始める(ディズニー)
- 花札を作っている会社がビデオゲームを作ってストリーミング販売に対応していく(任天堂)
- 広告の雑誌を作っている会社がPOSレジや結婚相談を始める(リクルート、結婚相談はこの間やめることが発表された)
- 専門書の物販を行っている会社がデータセンターを建設する(Amazon)
- 進学塾を提供していた会社がホテルなどの不動産事業に切り替える(四谷と呼ばれる会社)
- フリマアプリを作っている会社が決済アプリを作る(メルカリ)
- メルペイの立ち上げは1年間で決済を立ち上げる、毎週毎週加盟店が増えていく、当然加盟店ごとにスキームや契約のスキームは違うだろうということでめちゃくちゃ大変だった
- 発表者自身がこれを体験したからこそすごく思うことがある
- マーケットやビジネスが変わり続ける
- 10年後、20年後本当に未来を見通せるんだったら皆様今頃億万長者になっているはず
- そうじゃないんだとしたら自分は10年後、20年後読み通せないと思っていた方がいい
- マーケットやビジネスが変わり続けるという中で当然ながら見るべきデータも変わる
- 当然ながらそうするとデータモデルも変わる
- 継続的に要求を見直して設計を見直してモデリングを見直してそれを実装して整備して分析してまたサイクルを回すのが大事である
■ 14. AIエージェントとディメンショナルモデリング
- 生成AIによってデータ分析の自動化がすごい楽になりつつある:
- ジュニアの分析者よりも正確だし、シニアの分析者よりも安いし早い
- クロードデスクトップといったツールでデータを繋いでやっていけばそれっぽいレポートをすぐに作ってくれる
- BIツール上の対話エージェント機能なども提供されている
- 生成AIがデータを正しく使うにはやっぱりデータの整備が必要である:
- 社内の売上テーブルが50個あったらどの売上で分析すればいいか判断できない
- 売上って何なのか(消費税含むのか含まないのか、途中解約ってどうやって計上するのか、年間契約って月で割り算するのか、割引ってどこで引くのか、返金って後で引くのかそれとも遡って引くのか、通販サイトやアプリ決済の場合決済手数料ってどうやって管理するのか)
- 年間契約の場合、ある分析では今年の今月の売上すごい伸びていると報告しても、別の売上別の分析では月割で割り算したら半分になる
- AIが生成した2つのレポートを見比べると今年の今月の売上が10倍近くずれる
- これは話にならない
- ファクトとディメンションのテーブルが用意されているといい:
- ここに売上テーブルがあり、カラムで消費税データを管理すると嬉しい
- ファクトとディメンションのテーブルは用意されている
- この時点でディメンショナルモデルだとAIは理解してくれる
- この形式を見た瞬間に、これはディメンショナルモデリングで作られたテーブルだと気づける
- こういう集計をするにはファクトのこれとディメンションを組み合わせて使えばいいんだろう、集計対象がファクトだろう、切り口がディメンションだろうということに気づける
- このIDの列で結合すればいいんだろうということが判定できる
- 割り算とか消費税抜きとかという列が仮にあると、こういった条件だったらこれを見ればいいんだろうということが見えてくる
- AIが事業年度を多分日本の企業は4月から翌年3月なんじゃないですかって推測するんじゃなくて、事業年度列が既にあったらそれを使えばいい
- 整備されているほどデータ品質が安定する、データの分析の品質が安定する
- そうすると従業員がカジュアルに生成AIに頼れるようになってくる
- 実際の事例:
- MicrosoftのPowerBIというBIツールを使う場合はディメンショナルモデリング(スタースキーマ)を結構前提としている
- コパイロットの機能を使う場合も当然その前提である
- メルカリ社のソラテスという分析のAIエージェントは、ベーシックテーブルと彼らが呼んでいるテーブルに依存して、このテーブルだけは見るようにという整備をしている
- データ活用の課題:
- 活用効果が期待以上となる要因としてデータ品質が日本・アメリカ共に2位として上げられている
- 国内686社の調査でデータ活用の課題として、セキュアな量を備えたデータの取得・整備ができないことが言われている
- オラクルの2020年の調査で、データが細分化されていて使いにくいということを世界のグローバルの670人のテクノロジー部門の上級決定者とCO的な人達のうち73%が答えている
- シングルソースオブトゥルース(信頼できる唯一の情報源):
- ここを見たら一旦ここを見ればいいんじゃない、ここを見たらデータを分析できるんじゃないという信頼できる軸がある���いい
- 全体売上と言ったらこの箱を見る、こういった切り口で見ていくと見れるというのが概念としては必要なはず
- 画面のイメージで言うとポチポチボタン押していくと欲しいデータが取れるになっていると使いやすいはず
- データパイプライン:
- ファクトとディメンションを作るのはいきなりこれで作るんじゃなくて、機関システムなら機関システム、SNSならSNSからのデータ、スクレイピングしたデータなど各データがあるはず
- それをやっぱり一元で前処理をして集計ロジックをかました上でファクトとディメンションを作っていく
- これは使う側(理由側)のモデルとビューに分けるとしたら、こっちがモデルでこっちがビューみたいな感じ
- DDD的に言ったら永続化とプレゼンテーション層と言ってもいい
- 今回はこっち(ファクトとディメンション)の話をする
- これを作るにはこれらのデータを組み合わせて作っていく必要がある
■ 15. 本書で扱わなかった内容
- 今回はエントリーの内容なので取り扱わなかったポイントがいくつかある:
- 実際にファクトとディメンションをどんな風に設計するのか例をいっぱい知りたい
- 今回ファクトが1個あってディメンションが周囲にあるという紹介をしたが、叩いたの関係もあるはず
- マスターの値が変わる場合(ユーザーが静岡から東京に引っ越した場合、そのままマスターを上書きしちゃうと去年の購入が静岡じゃなくて東京に計上されてしまう)どうするのか
- これらの回答は「アジャイルデータモデリング」の本に書いてある
■ 1. 発表者の背景と取り組み
- 発表者はVALUソースという会社を経営している
- 要件定義とシステムの可視化を行っている
- 最近はAIを使った要件定義に注力している
- いかにして要件定義をAIでやらせるかを毎日取り組んでいる
■ 2. AIで要件定義を行う際の前提条件と課題
- 前提条件:
- AIは個別の企業のことを何も知らない
- 3つの課題:
- LLMの出力をいかに理解するか（最も大きな問題である）
- ある程度少量のデータで大量に出てくるため、どうやって理解するかが問題である
- AIに適切なコンテキストをどうやって用意するか
- 中規模から大規模なシステムでは最初の入力だけではどうにもならないため、軌道修正しながら最終的な要件に組み立てていく必要がある
- 軌道修正をどうするかについて一つの形が見えてきている
■ 3. 課題解決のアプローチ
- 初期要望の入力:
- ビジネスの背景や概要などの初期要望を入れてAIに要件定義させる
- 要件のビジュアライズ:
- 文章だけではなかなか理解できないため、様々なものの繋がりをビジュアライズする
- 画面の確認:
- 画面を中心に話をすると要件的にも進みやすい
- LLMが出した出力から各アクター別にどんな画面になるのかをすぐに確認できるようにする
- LLMが出したものがどういうものなのかということを理解するために用意している
- 要件の妥当性検証:
- AIが出してきたものが本当に現場に適用できるのかを検証する
- 環境を入力してそれで妥当性検証を行う
- 論理データモデルの活用:
- 論理データモデルを出して、論理データモデルから要件を突き上げて正しいのか判断する
- 中心となるモデル:
- 要件定義における要件には構造があると定義している
- その定義に従ってAIを作業させる
- モデルの周りにビジュアライズ、画面出力、論理データモデル作成などが付随している
- 最終的にAIが出した要件を確認していく
■ 4. 入力サンプルの内容
- システムの概要を入力する:
- サンプルとして訪問介護のシステムを使用している
- どんな背景なのか、要求、ビジネスポリシーなどを記述する
- ビジネスパラメーター（介護会員のランク、サービススタッフの働き方の種別など）を記述する
- 業務概要を記述する
■ 5. 実装方法の変遷
- 昨年の実装:
- プログラムでAIを使って要件定義させることをトライしていた
- プログラムからAIのAPIを呼んで要件定義させて保存するという流れを何フェーズかに分けて実行していた
- 現在の実装:
- 昨年の暮れからエージェントがすごいことになり出した
- プログラム作成では全然追いつかないと判断した
- 要件を定義することに関しては全てエージェントにやらせることに方針転換した
- 動作環境:
- カーサーを使用している（クロードコードやCLIツールでも可能）
- フェーズが4つあり、フェーズごとに出力される
- 徐々に出力を厚くしていくやり方をしている
- 実際の出力には2〜3分かかる（デモは10倍速）
- 現在の能力:
- モデルがかなり賢くなっているため、ほぼほぼ全てAIで要件定義できるレベルになっている
■ 6. ビジュアライズ機能
- 全体俯瞰:
- AIで出したものをビジュアルに表現している
- 業務とコンテキストが表示される
- コンテキストを選ぶとその中にどんな情報があって、どのケースと繋がっているのかが出てくる
- 情報の表現:
- IDを中心としてある程度具体的なエンティティを出す
- 細かいものは出さず、ビジネスで認識しているIDを情報という形で出している
- この関係付けもAIが行っている
- 様々な視点からの確認:
- 訪問介護スタッフを選ぶと、その訪問介護スタッフを中心にどういう画面を使っていて、その画面はどのケースに繋がっていて、そのユースケースはどの業務でどのアクティビティなのかが全部俯瞰して見える
- 1つのアクターに多数の画面がついている場合、ロールが足りていないことが分かる
- 1つのロールでそんなに多くの画面を扱うことは普通ないため、ロール見直しの必要性が判断できる
- 画面が多すぎる場合、システム化する必要がないのではないかという議論もできる
- 状態遷移の確認:
- 状態遷移があり、この状態遷移に関わるユースケースは何があるのかが見える
- この状態は本当に役に立っているのか、この状態を実現するための情報は何なのかという話もできる
- 活用方法:
- 1回AIでガーっと出すとこのビューを使って様々に分析しながら本当にこの要件でいいのかを考えていく
- AIに引きずられているような感じになるが、AI要件定義そのものはもうAIでできることが分かったため、いかに理解するかが重要になっている
■ 7. 画面イメージの生成
- アクター別の画面を作成する:
- 具体的にその画面でどういうことが行われているのかが分かるように、AIにアクター別の画面を作らせる
- 介護スタッフを選ぶと介護スタッフの使う画面が見える
- イメージではあるが、この介護スタッフはどういう業務でどういうビジネスケースでこの画面を使うのかをイメージしながら要件定義をしていく
- アクターごとに確認しながら使っていく
■ 8. VGモデルによる妥当性検証
- 左側（要件生成）:
- フェーズ1234の4つのフェーズでAIが出力したものを作成する
- 右側（妥当性検証）:
- 本当にその要件が妥当なのか、このままシステムとして導入して役に立つのかを検証する
- 検証方法:
- 対象システムの拠点やアクターにどういう制約があるのかを入力する
- この制約と組み立てた要件をぶつけて妥当性を検証する
- ある程度その環境を入力することによってAIが生成した要件が妥当なのかどうなのかを判断する
- 検証結果:
- 色々と出てくるが、感覚的には60点ぐらいである
- 重要度や改善提案がやたらに出てくるが本当かなというものもある
- ただし出力された要件を見直すという意味においては、VGモデルの右側からどういう環境にシステムを入れるのかを入力するのは結構有効である
- そもそもこの入力を作るという行為そのものがかなり重要であり、これで現場というものを強く意識できる
■ 9. 論理データモデルとビジネスルールの生成
- ビジネスルールの叩き台:
- 要件として出されたビジネスルールの叩き台を作る（正式なものではない）
- ラドラという手法では条件という名前のものがビジネスルールを表す
- スキルマッチング条件があった場合、それはどのケースから呼ばれていて、その条件はどういうサービス種別やスキルレベルなどのバリエーションに繋がっているかが書かれている
- この条件からビジネスルールを作ってくれとAIに言うと叩き台が出てくる
- 実際の仕様においては、仕様化の時にこの形式で本当にいいのか、もうちょっと違った形でビジネスルールをきちっと書いていく
- 叩き台があるだけでかなり見通しは良くなる
- 論理データモデル:
- 要件から論理データモデルを作ってというとそこそこの論理データモデルが出てくる
- データモデルの得意な人はデータモデルを見るとかなり業務が分かる
- こちら側から今回の要件が妥当なのか、ピントがボケているなどが判断できる
- 論理データモデルが読めない・苦手という方は、エンティティの役割と他のエンティティとの関係からこの論理データモデルのできることや役割を分かりやすく説明してとAIに訊ねると、それなりに説明してくれる
- 分かりにくい場合はさらに質問すれば分かってくる
■ 10. 適切なコンテキストの提供
- 重要性:
- コンテキストとして生成したものを積み上げていくことが大事である
- 4つのフェーズの構成:
- AIが要件をどう組み立てていけばいいのかというナレッジをあらかじめ入れている
- IDEではラドラナレッジというところに各々フォルダーを切ってその中に様々なプロンプトなどが入っている
- 人が行うこと:
- 基本的に人が行うことは初期の要望を書くことである
- それでフェーズごとに実行して出力された内容を見直して、また次のフェーズに行くことを繰り返していって洗練化する
- 軌道修正:
- AIが出した出力を人間が見直して軌道修正する
- 細かく見て直すというのは人間にとってかなり負荷が高いため、明らかに違うということだけ直す
- いらないものを基本削除するという方向で修正していく
- 実際の運用:
- 最初に初期要望を入れて1回動かすと解像度が悪い感じになるため、この初期要望を見直す
- ある程度こんな感じかなと思ったら次からどんどん次に行く
- 当初はフェーズ1見直したらフェーズ2、フェーズ3と思ったが、人間の負荷から言うとフェーズごとに見直すのはかなり耐えられない
- 今は初期要望と最初のフェーズを繰り返したらあとは一気に最後まで行くという感じである
- 一気に最後まで行って要件として組み立てたら、その後でビジュアライズしたもので色々な角度で見直して再度生成し直す
- その方が楽である
- 最終確定:
- AIで出されたものはどこまでも叩き台である
- 最終的にはラドラという手法の形式で出して人間が最終的に要件を確定するというやり方をしている
■ 11. モデルベースのアプローチ
- ラドラという手法の構造:
- 要件には形がある、構造があると規定している
- 4つのレイヤーがあり、各々要素があって、その要素が全部繋がっている
- 右から左に依存するという構造を持っている
- 右の要素は左の要素がホワイトになっている
- 左の要素がこうだから右の要素はこうだという考え方である
- クラス図による表現:
- この構造をクラスで表すことができる
- この構造に従って要件を定義させるので連続的に要件が定義できる
- 段階的なモデル構築:
- 最終形に持っていくために段階的にモデルを組み立てる
- 徐々にオブジェクトを増やして関係付けすることを内部で行っている
- AIで出力されるのは表形式だが、内部ではこれらが全部完全に繋がり合っていてオブジェクト構造として持たれている
- 詳細なレベルから俯瞰したレベルまで見ることができる
- 画面生成の仕組み:
- このオブジェクト構造があるため、定義されたオブジェクト構造から画面用のアクター、画面、項目という構造に変換する
- 当初これをエージェントで変換していたが、こんな決まりきったことをエージェントでやるのはトークンが無駄だと判断した
- エージェントにプログラムを作らせるようにしている
- この構造のものをこっちの構造にしてくれという構造変換のプログラムを作らせる
- プログラム変換させたものをJSONとして出してこのJSONを画面が読んで生成されたものの画面をアクター別に出す
- モデルの言語化:
- クラス図の1個1個のクラスと関係を言葉で定義している
- アクターとはこうだ、業務とはこうだということを書いて言語化している
- これを食わせている
- 実際には表形式で出ているため、表形式はダイアグラムの関係性を表として再現できるようにしている
- この表の構造も全部言語化して、こういう繋がりはこういう表で出力してくれということを全部書くことによって出力される
■ 12. まとめと提供サービス
- IDEの活用:
- IDEの中であらかじめナレッジをモデルベースで入れておく
- 初期の要望をファイルに入れて実行すると要件定義が生成される
- 複雑なタスクへの対応:
- 要件定義みたいな複雑なものはまずフェーズに分ける
- フェーズごとのナレッジを作る
- フェーズごとの成果物のフォルダーを用意する
- 成果物のフォルダーがAIに渡すコンテキスト情報になるため、それを見直すことによって軌道修正してちゃんと辻褄の合った要件定義に持っていく
- 無料相談の提供:
- 要件定義や家の設計など創造的で難しいところをどうやったらAIでやれるのかを悩んでいる方向けに無料相談を提供している
- XのアカウントにてDMで相談を受け付けている
■ 1. ドメインモデルの定義と階層
- ドメインモデルの基本概念:
- 現実世界の複雑さを抽象化して表したものである
- 枝葉となる環境や実装技術に依存した部分を切り落として業務の本質的なコアの部分を抽象化したものである
- ドメインモデルの3つのレベル:
- データベースやデータモデリングに概念モデル、論理モデル、物理モデルというレベルがあるように、ドメインモデルにも概念モデル、仕様モデル、実装モデルというレベルがある
- この区別は2000年頃の論文「Modeling with sense」(マーティン・ファウラーのサイトに掲載)で提唱されている
- 現状の課題:
- 実際にはこの仕様モデルと実装モデルがあまりはっきりした区別をされずに今まで来ている
- ドメインモデルは抽象概念なので仕様レベルでの話が重要である
- しかしオブジェクト指向プログラミングのエッセンスなど実装の都合や技術都合に引きずられてどう実装するかの話で片付けられることが多い
- DDDも実装論ばかりされているように見える
■ 2. 仕様モデルの定義
- 仕様モデルの役割:
- ソフトウェアシステムが何をしなければいけないか、どのような情報を保持しなければならないか、どのような振る舞いを示さなければならないかを定義する
- 端的に言えばデータと振る舞いを定義する
- 仕様ドメインモデルの構成:
- 仕様ドメインモデルは工学的な抽象レベルで記述された業務のデータと振る舞いで構成される
- 主にはデータと振る舞いで構成されるものである
■ 3. オブジェクト指向と関数型のドメインモデリング
- オブジェクト指向のドメインモデリング:
- データと振る舞いの関係性をマッピングしていく
- 行列を並び替えながらうまいことクラスだったっぽいものを見つけてクラスとして整理していく
- クラスターの決め方は自由度が高い
- 人によって設計できる人と設計できない人のばらつきが出る
- 関数型のドメインモデリング:
- 基本的には同じであるがそれぞれの振る舞いができる限り全域性を満たすようにする
- 対象とその全ての入力データに関して定義できない振る舞いは実装しない、別の振る舞いにするかデータ型を分ける
- 例外を発生させないように振る舞いやデータを調整していく
- 全域性を保つことで組み合わせ可能性(コンポーザビリティ)が高まる
- 本質的な違い:
- 仕様ドメインモデルのレベルでは本質的な違いはない
- オブジェクト指向の方が自由度が高い
- 関数型モデリングはさらに全域性を保つなどの制約が加わるためより厳密になる
■ 4. 仕様モデルの記述方法
- 従来ツールの問題:
- 従来のモデリングツールでは仕様のモデルを書いているのか実装のモデルを書いているのかが曖昧である
- モデル駆動開発(MDA)で仕様書いたらそこからコードがジェネレートされるという夢の世界の影響があった
- 実装モデルに近い設計要素が入ってしまっている
- 記述のアプローチ:
- 従来のツールは一旦置いといて純粋にデータと振る舞いだけを書き出すことにフォーカスする
- DSL的に簡単なシンタックスで記述する
- データの定義はデータ型で名前をつけて何から構成されるかを書く(代数データ型と同じ)
- ANDで直積とORで直和を使ってデータと振る舞いを表していく
- データ定義の例:
- データはANDで複数の要素を組み合わせる
- ORで複数の選択肢から1つを選ぶ(例:連絡先はメールアドレスか電話番号か住所)
- 振る舞いは基本的に入力から出力への変換である
- 入力のデータとそれが出力のデータとして何が出てくるのかを定義していく
■ 5. 抽象化の重要性
- 振る舞い抽象:
- 実装の詳細を知らなくてもその振る舞いが提供する機能を利用できることである
- 実装の用語で言えばインターフェースに対して実装していくことと同義である
- データ抽象:
- 対象のデータの詳細を知らなくてもそのデータに対しての振る舞いを実行できることである
- 仕様モデルの要件:
- 仕様モデルはこれらの振る舞い抽象とデータ抽象でなくてはならない
- 振る舞いがない場合は実装の詳細を仕様として書いてしまいがちである
- SI現場で見られる詳細設計書のように実装レベルの処理順を書いてしまうと、中身の実装を全部知らないとロジックを安全に呼び出せなくなる
- プログラム修正においても詳細全部を知らないと何も修正できなくなる
■ 6. 仕様記述の要素
- バーバラ・リスコフの手続き抽象の仕様構成要素:
- 入力と出力(データ抽象が入力と出力になる)
- Requires(事前条件):入力が受け付けられないものがある場合にその条件を書く
- Modifies(変更条件):中で書き換えられる入力があったらそれについても書く
- Effects(効果):入力についての書ききれない振る舞いの詳細を書く
- 良い仕様の3つの条件:
- Restrictiveness:使う側にとって受け入れられない実装が全て排除されていなければならない
- Generality:受け入れられる実装を仕様として排除してはならない(実装の選択肢を勝手に削らない)
- Clarity:仕様の読み手がその意味を十分理解できること
■ 7. 全域性の追求
- 全域性の定義:
- 取りうる入力の全てに対して対応する出力が必ず存在することである
- 全域性の実現方法:
- 振る舞いが受け入れられない入力を仕様として示すのではなく、型として調整する
- 例:割り算で除数が0ではないことをRequiresとして仕様に書くのではなく、NonZeroInteger(0を除いた整数)という型を定義する
- これにより自然言語として書かなければいけない仕様が少なくなっていく
- ステータスの問題:
- ステータスは全域性を損なうサインである
- 注文ステータスがあるということは、そのステータスによって適用できる振る舞いが違うことを意味する
- ステータスではなくデータ抽象で表すことで適用できる振る舞いの条件が明示される
- 仕様レベルではステータスがなくなるようにデータ抽象を作っていくことが重要である
■ 8. 実装の選択肢を残す
- Generalityの実現:
- 良い仕様は実装者が要求を満たす上で最も最適な実装が選べるように最大の選択肢を残してあげなければならない
- SI現場では実装の話まで仕様にたくさん書いてしまいがちである(例:ループ処理、データベースアクセスの方法など)
- これは性能問題に直結する
- データ抽象の適切な設計:
- テーブル駆動で設計するとデータ抽象が適切に設計されないことがある
- 例:受注生産の場合だけサプライヤーIDが入るという仕様で、このフィールドがNULLかどうかで受注生産商品を判定するロジックが各所に埋め込まれる
- これは抽象が漏れ出している(Leaky Abstraction)状態である
- 対策はデータ抽象をちゃんと分けること(通常商品と受注生産商品を別のデータ型にする)
■ 9. Clarityの向上
- スタンプ結合の廃止:
- 入力のデータの全部をその振る舞いで使うわけではないことがよくある
- 大きなデータを渡しがちだがそうするとテストしにくくなる
- 使ってないデータに依存した振る舞いがあるので修正時の影響調査が必要になり修正コストが高くなる
- データ抽象の粒度が大きいと何をやっているかが分からなくなる
- ビジネス不変条件の保証:
- 仕様としてのデータ抽象はビジネス不変条件をちゃんと保証するものでなければならない
- 例:チェックイン日はチェックアウト日よりも前の日付でなければならない
- これを型として明示しておくとより不変条件が明らかになる
- バラバラのフィールドではなく「宿泊」というデータを別に作り、それを「日付の範囲」として定義する
- 単一責務の原則:
- 振る舞い抽象は単一責務でなければならない
- 複数の責務が混ざっている振る舞いは正確に名前に反映させることで発見できる
- 名前に「〜の場合は」「〜をして〜をします」「そして〜をします」(英語だとAND/OR)が入る場合は複数の責務が混ざっている
- 正直正確で完全な名前を一回つけてみて、そこにAND/ORが繋がるようだったらそこで分割する
■ 10. 仕様モデルから実装モデルへ
- 良い仕様モデルの条件:
- スタンプ結合を除去する
- 振る舞いが全域性を持つようにする
- 振る舞いを単一責務にする
- これらは疎結合や高凝集を目指す良い設計と全く同じ話である
- これを仕様レベルでちゃんと保とうということである
- 実装モデルへの変換:
- 良い仕様ドメインモデルが書ければ実装言語に合わせて実装ドメインモデルにエンコーディングすればよい
- データと振る舞いをクラスごとに整理するのがオブジェクト指向言語向けのドメインモデルである
- データを型に、振る舞いを関数にエンコーディングするのが関数型のドメインモデルである
■ 11. 開発アプローチの転換
- アウトサイドイン開発の問題:
- 現状のSI現場で多い開発スタイルはアウトサイドイン開発である
- 業務コアの概念が分からないまま画面設計書を作り、テーブル設計を作り、そこで開発をスタートする
- 外側(実装の詳細)から詰めていって中(業務コア)に向かって開発を進めていく
- 仕様モデルを書く隙間がこのプロセスにはない
- 結果として配線プログラミング(画面項目とデータベースのマッピング線だけ設計する)になる
- システムの理解容易性と変更性が低下しやすい
- インサイドアウト開発への転換:
- 仕様モデルをちゃんと書いて、その仕様モデルに沿ったプレゼンテーションのモデルや永続化のモデルを書いて画面と繋げていく
- インサイドアウトの開発にすべきである
- 仕様モデルがちゃんと書けていればこの外側に向かってコードを書く部分は生成AIがうまいことやってくれる
■ 12. 仕様モデル駆動設計
- 従来の仕様駆動開発(SDD)の問題:
- 仕様として何が必要かという定義がない
- 従来の開発延長線上に仕様駆動開発をやってみようとなるとアウトサイドインになる
- AIが勝手に想像して変なコードを出してしまう
- 仕様モデル駆動設計の提案:
- ちゃんと仕様モデルを先に書いてインサイドアウトで開発すると、当然ながらそのモデルが先に作られている状態である
- AIはそれをちゃんと理解した状態で画面やDBにマッピングしてくれるので割と綺麗に作ってくれる
- これを仕様モデル駆動設計と呼んで広めていく
■ 1. ワークショップ1:モデル駆動設計の実践
- 開催概要:
- 講師は増田氏と佐藤氏である
- 先週月曜日に4時間(13時から17時)で開催された
- 会場はNEC本社を借用した
- ワークショップの内容説明15分、モデリング3時間、増田氏によるレビュー45分で構成された
- 2人から4人のテーブルに分かれてワークを行い、30分に1回程度全体で議論した
- 参加者属性:
- 申し込み者数は26人で当日参加が23人、アンケート回収数が15である
- システムエンジニアとプログラマーの方が多数を占めた
- 現業務現場でのモデリング経験がある方が66.7%で、3人に2人はモデリング経験がある
- UMLの利用経験が3年以上の方が40%、1から3年が26.7%、1年未満が20%で、約80-90%がUML利用経験を持つ
- ワークショップの内容:
- モデル駆動設計とはという導入部を6個のスライドで説明した
- 調整さんのようなものをテーマにルールをコードで記述することを課題とした
- シンプル版として特定の日付に決定するルールをプログラミング言語で表現することから始めた
- 終わった方から段々ルールを複雑にしていくことに取り組んだ
- 参加動機:
- 講演内容に興味があった(モデル駆動設計)
- 講演者に興味があった
- モデリング技術に関する最新情報収集のため
- 会社からの案内、UMTPのメールとホームページ、川島氏のXのポストが情報源となった
- 満足度と使用ツール:
- 非常に満足と満足を合わせて73%の満足度があった
- 使用ツールはJavaが10件、Goが5件、UMLが5件、C#、Python、Ruby、Mermaidも使用された
- プラス評価:
- 最後45分間の増田氏による3人の方の実際のコードレビューが非常に良かった
- グループで30分に1回程度どういう風にやっているかを話した際の意見や解釈、感覚を共有したのは収穫であった
- 調整さんの表から分かる表からモデルコードに落とし込む作業が予想以上に大変だったことを体感できた
- モデルをコードで表現するという観点を強く意識する機会となった
- 4時間集中して取り組む時間になった
- 改善点:
- 増田氏ならどのような実装になるのか見てみたかった(あえて模範回答を用意しない方針だった)
- 増田氏のレビューを受けたかったのでレビュー時間を長くして欲しい(45分でも足りなかった)
- コードによるモデリング方法の具体的な説明がなくモデル駆動設計の解像度が上がらなかった
- モデル=コードという考え方が伝わらなかった
- コードではなくても(図などで)レビューして欲しかった
- チーム分けで得られるものが異なり、テーブル内で同じような接近になってしまった
■ 2. モデル駆動設計の核心概念
- モデル=コードの原則:
- 今回のポイントはコードでモデルを表現することである
- モデル=コードが理解して欲しいポイントである
- ドメイン駆動設計(エヴァンス本)では「モデルと設計の下」において、モデルと設計及びコードを単一の活動として改良し続けることを説明している
- 1つ作ればモデルにもなるし設計にもなるというのがポイントである
- モデルで表現すべきもの:
- 事業、業務、業務ルール(ビジネスルール)をコードで表現してモデルにもなる
- テクニックとしてDDDで語られているエンティティ、値オブジェクト、ユビキタス言語を使った命名などがある
- モデルとコードの乖離:
- 手続き型で処理順に書いていってしまうとモデルとコードが乖離していく
- 実際に多くの参加者のコードでこの乖離状態が見られた
- 実装が進んでレベルの高い方でもこの問題が発生していた
- 具体的な問題点:
- 重要概念がクラスではなくプリミティブ型の変数で表現されていたため、重要概念がモデルとして伝わってこない
- 処理が書いてあってそこにコメントで一生懸命説明しているが、それがコードに現れてきていない
- このような状態ではモデルとコードが乖離している
■ 3. 開催者の所感
- モデリングの習得における課題:
- モデリングを頭で理解するのと体得の間には崖がある
- 実際に参加者がモデリングしているところを見てこれを実感した
- 本を読んで頭で理解したつもりでも実際やってみるとできないというギャップがある
- ワークショップの価値:
- モデリングの体得のきっかけとしてワークショップという場は価値がある
- 頭で理解したつもりだったけども実際やってみるとできないということに気づくきっかけとなる
- 気づいたら自分で色々書いてみたり、実プロジェクトで部分的にやってみたり、師に習う(お互いにレビューし合ったり、習得した人に見てもらう)ことが重要である
- AI時代におけるモデリング体得の必要性:
- 生成AIがモデリングをするにしても人が体得することは必要である
- 生成AIがモデリングして人がそのAIが作ったモデルの良し悪しを判断できないと体得していないので良いか悪いか判断できない
- 判断できないと知らないうちに歪んだ設計がソフトウェアに埋め込まれていく
- AIで動くものは作っていくが知らないうちにソフトウェアの内側から劣化して開発生産性や品質が低下し、リリーススピードが低下して事業に悪影響を長期的には及ぼす
- 生成AIがモデリングしたとしても人がAIが作ったモデルの良し悪しを判断して最終的には受け入れ判断をする必要がある
- そうするとソフトウェアの内側が綺麗に保たれて変更容易性が高まって生産性が上がって事業にどんどんリリースできるので事業に貢献できる
- ドメインのところをソースコードから綺麗に保っていくことでソフトウェアの変更容易性が高まって事業に貢献できることにつながる
■ 4. ワークショップ2:モデルとは何かの本質洞察
- 開催概要:
- 11月19日にリモートで開催された
- 参加者は16名で19人で実施された
- 企画の方、アーキテクトの方、学生、プロダクトデザイナーなど多様なバリエーションの参加者がいた
- 最も多かったのはシステムエンジニアとプログラマーである
- 目的:
- モデルについてみんなで対話を重ねて深く考える時間を持つこと
- いろんな立場の様々な視点の人々との対話からモデルとは何かを探っていく
- 自然言語でモデルとは何かを思考実験して検討していく
- 特定のUMLを使うことは目指していない
- 概念工学に近いことをみんなで体感する
- 本質洞察の実践という形で自分の実感体験と言葉によるある程度明確な記述をいかにすり合わせて近づけていくかを繰り返す
- 共通性を見つけ本質の定義に近づいていく
- いろんなエピソードを少しでも広くカバーできるような概念を見つけ出す
- 実感体感と一般化、抽象化、理想化、形式化の間を行ったり来たりしながらうまい表現記述を見つけ出す
- 参加者属性:
- モデリングの現場での経験がある方が83%である
- UMLの利用経験が3年以上の方が33%、1から3年が10%未満、1年未満が16%で、40%の方は使ったことがない
- 満足度と感想:
- それなりに満足度は高かった
- モデリングの良い経験になった
- グループで異なる方と議論ができた
- モデルに対する理解を深めることができた
- 業務で役立つ知識を得られたような感じはしなかった(目的はそこではなかった)
- モデリングを学んだというよりモデリングについて学んだという感じで実務には役立たなさそうだった
- ワークショップではかなり良い体験ができた
- 新モデリング宣言に関して哲学とソフトウェア工学をどのように結びつけられるかを知ることができた
- モデリングとは何かを再確認し、またモデリングを展望する機会となった
■ 5. ワークショップの流れ
- エピソード収集:
- モデルやモデリングというキーワードを含んだ自分の実体験のエピソードを2つ以上書く(200字以上400字未満程度で2つ分)
- 文章をお互いに見せ合い説明し合いながら自己紹介タイムを実施した
- 体験、実感というものが大事で、これが核になって初めて共同感覚を引き出せる
- 多様なエピソード:
- プラモデルを作るというモデリング経験
- 救援活動の納得感を構成するためのモデリング
- PTA活動の際の組織構成の構造を作る経験
- 日常生活業務やIT開発設計業務など様々な場面でのモデリングの実感を伴ったエピソードが集まった
- 本質洞察の実践:
- 本質洞察とは何かを説明した上でモデルの本質とはどんなところにあるのかを語ったエピソードの中から共通性を抽出する作業を実施した
- カードに書いていく形式で進めた
- 揺さぶりをかける新しい視点:
- 画家が絵を描く際のモデルさんというモデル
- ファッションモデルは一体何のモデルなのかという問いかけ
- 数学の理論に対してその理論を適用した具体例のことをモデルと数学では呼ぶが、その理論とモデルがITやエンジニアリングの分野のモデルの扱いと逆転しているように見えるのはなぜか
- チームごとの整理:
- Aチームはモデルの目的やモデルの特徴をいろんな観点で整理した
- Bチームはソフトウェア開発という分野に絞ってモデルの共通性を導こうと努力した
- Cチームは複雑な内容を短時間で共有するというコミュニケーションに着目してそれを整理しようとした
- 追加された観点:
- 型という観点、お手本という観点、具体例という観点、象徴という観点、抽象化、予測可能性といった観点が追加された
■ 6. モデルの定義試作
- Aチームの定義:
- 共通言語、コミュニケーション、文法がある程度存在する
- 抽象度を変えることができて可視化できる
- 関係性が明確化に明確になっている
- Bチームの定義:
- モデルとは共通認識の形成のために作られ、関心ごとの対象をシンプルかつ他人に共有可能な形式で表現したものである
- さらに洗練してモデルとは現実世界を認識再利用するためにモデルを共有する人や社会が共通に理解できる表現対象である(50文字以内に収まった)
- Cチームの定義:
- 物事の基準で再現可能なものである
- 目的に応じた要素に絞り複数要素とそれらの関係で構成する
■ 7. モデルの語源と二重構造
- モデルの語源:
- ラテン語で測定器具や基準という意味から始まっている
- 伝統的なモデリング:
- 画家の人やファッションモデルのようにある基準がモデルで、それを参照して何か作品を作るモデリングの仕方がまず最初に現れた
- 工学的モデリング:
- 工学の世界では色々な具体事例をうまくコントロール制御してより良い製品、より良い作品をするためにはどんなお手本があったらいいだろうということを考える
- 今度は具体的な作品事例から逆算してモデルというものを作るということが行われるようになってきた
- 二重構造の統合:
- 従来のお手本から作品を作るという次元のモデリングと、具体例を基準となる作品を作る際にお手本にするといいようなエッセンスを人工的な構成物として作り出すという新しい活動が二重に重なっている
- アジャイルなぐるぐるモデリングのように、作品が色々ある中からいい基準を見つけ出してそれをモデルとして抽出し、それに基づいて作品をまた作り、それをまた妥当性を判断し、それをまた抽象化するということがぐるぐる回るようなエンジニアリング的な活動に移ってきた
- UMTP新モデリング宣言との関連:
- このような従来のお手本としてのモデルが工学的な活動の中で三角関係になっていき、ぐるぐる回るモデリングに移行してきた
- これはUMTP新モデリング宣言で呼ばれるところのリベラルアーツとしてのモデリングに通じる
【本書の構成】
◆第1部 導入編
第1章 なぜデータの「意味」が大切なのか？
◆第2部 文法編
第2章 概念データモデルの文法の基礎概念
第3章 KEYとRKEY
第4章 分類構造と分担構造
第5章 関係
第6章 エンティティ類型
第7章 加工データとSPFチャート
◆第3部 手順編
第8章 データモデリングプロジェクトの手順
第9章 データモデリングプロジェクトの成果物
第10章 データモデリングプロジェクトの知識
◆第4部 実践編
第11章 業務システム領域の概念データモデル
第12章 データ活用領域の概念データモデル
実践で学べるドメイン駆動設計！
この本は、TypeScript を使用してドメイン駆動設計（DDD）の原則に基づいた Web API サーバーの構築を学ぶためのガイドです。
この本ではオンライン書店サービスをドメインとして扱い、その中でもカタログ管理に関するサービスを取り上げます。そのドメインを実装するための Web API サーバーの構築を通してドメイン駆動設計の基本的な概念や原則、実践的な実装方法を学びます。ハンズオン形式で進んではいきますが、辞書のように使っていただくことも可能となっています。
著者は、ドメイン駆動設計を利用して TypeScriptでWeb API サーバーの構築を行う際に、十分な情報やガイドを見つけられず、苦労しました。本書を通じて、複雑なビジネス要求を効果的にソフトウェアに反映する手法を探している開発者の方々へ、実践的な知識とノウハウを共有できたら幸いです。
■ 1. AIブームの根本的誤解
- ベンチャー企業Cognitive Resonanceの創業者ベンジャミン・ライリー氏の主張:
- AIブームは言語能力と知能についての根本的な誤解に基づいている
- 大手IT企業幹部の発言:
- Metaのマーク・ザッカーバーグCEOが「超知性の開発は今や目前に迫っています」と発言した
- OpenAIのサム・アルトマンCEOが「従来理解されてきた意味での汎用人工知能(AGI)を構築する方法について、私たちは今や確信を持っています」と主張した
- 大手IT企業の幹部らはAGIの構築に自信を見せている
- ライリー氏の反論:
- 人間の知能に関する科学的見解やこれらの企業が生み出してきたAIシステムを見る限り、とてもこれらの発言を信じることはできない
■ 2. 大規模言語モデルの本質
- 現在のAIの基本構造:
- OpenAIのChatGPT、GoogleのGemini、AnthropicのClaude、MetaのAI製品群のいずれも「大規模言語モデル」である
- これらは基本的に膨大な量の言語データを収集し、単語(トークン)間の相関関係を見つけ、入力されたプロンプトに対してどのような出力が続くのかを予測するものである
- これらの企業が開発するAIはどこまで行っても、本質的には言語モデルである
- 「言語=思考」仮説の問題:
- 仮に「言語=思考」なのであれば、AI開発企業が世界に関する膨大なデータを収集し、それをますます強力なコンピューティングパワーと組み合わせることで統計的相関関係を改善していけば、あっという間にAGIは実現する
- 大きな問題は、現在の神経科学に基づくと、人間の思考は言語とほとんど無関係だという点である
- 言語と思考の関係:
- 確かに人間は言語を用いて推論や抽象化、一般化といった知能の成果を伝達している
- 言語を使って思考することもある
- だからといって「言語=思考」とはならない
- いくら言語モデルを洗練させていったところで、それが人間を超える知能につながるという保証はどこにもない
- ライリー氏の批判:
- この理論には重大な科学的欠陥がある
- 大規模言語モデルは言語のコミュニケーション機能を模倣する単なるツールである
- どれだけ多くのデータセンターを構築したとしても、思考と推論という独立した明確な認知プロセスにはならない
- この違いを理解することが、科学的事実とAIに熱狂するCEOたちの空想的なSFを区別する鍵となる
■ 3. 言語と思考に関する科学的研究
- Nature論文の概要:
- 2024年、マサチューセッツ工科大学やカリフォルニア大学バークレー校などの研究者らが「Language is primarily a tool for communication rather than thought(言語は思考というよりもコミュニケーションのためのツールである)」という論文を学術誌のNatureに発表した
- この論文は言語と思考に関連する数十年にわたる科学的研究をまとめたものである
- AIブームを取り巻く誤解をひもとく上でも役立つ
- 「言語が思考力や推論力を生み出す」という概念の誤り:
- 仮に言語が思考に必要不可欠だとすれば、言語が奪われれば思考能力も奪われるはずである
- 高度な機能的磁気共鳴画像法(fMRI)で脳のどの部位が活性化しているのかを調べると、「数学の問題を解く」「他人の心を推測する」といった思考を行う際には、言語能力とは異なるネットワークが活性化している
- 脳損傷やその他の障害によって言語能力を失った人において、思考能力全般が損なわれるわけではないことは明らかである
- 重度の言語障害を抱えながらも数学の問題を解いたり、非言語的な指示に従ったり、他者の動機を理解したり、論理的推論や因果的推論を行ったりすることは可能である
- 言語能力を獲得する前の赤ちゃんも、日々の暮らしの中でさまざまなことを発見・理解し、世の中について学んでいる
- 科学的にいえば言語は人間の思考能力の一側面に過ぎず、多くの知能は非言語的能力に関わっている
- 言語の本質:
- 言語は人々が互いに考えを共有するためのツール、すなわち効率的なコミュニケーションコードである
- 言語は生成しやすい上に理解・学習が容易である
- 簡潔かつ効率的に使用でき、ノイズに対して堅牢である
- こうした特徴により、人類は言語を用いて知識を共有することが可能となり、世代を超えて並外れた文化を築き上げることができた
- 人間の認知能力が言語によって底上げされるからといって、思考全般が言語によって生み出されたり定義されたりするわけではない
- たとえ話す能力を奪われようと、人間は考え、推論し、信念を作り上げ、恋に落ち、世界中を探索することが可能である
■ 4. 大規模言語モデルの限界
- 言語モデルの構造的制約:
- 人間において「思考=言語」ではない
- 既存のAIの基盤となっている大規模言語モデルから言語を取り除くと、文字通り何も残らない
- AIが人間とはまったく異なるルートで超知能に到達する可能性もゼロではない
- しかしテキストベースの訓練によってAGIに到達できると考える明確な根拠もない
- AI研究コミュニティの認識変化:
- 「大規模言語モデルだけでは人間の知能モデルとしては不十分だ」という認識が高まりつつある
- ヤン・ルカン氏の取り組み:
- AI研究でチューリング賞を受賞したヤン・ルカン氏はMetaを辞任した
- 「物理世界を理解し、持続的な記憶を持ち、推論でき、複雑な行動シーケンスを計画できるシステム」である世界モデル構築のためのAIスタートアップを設立した
- ヨシュア・ベンジオ氏らの定義:
- ルカン氏と共にチューリング賞を受賞したヨシュア・ベンジオ氏らは、AGIの暫定的な定義を「十分な教育を受けた成人の認知的多様性」を持つものと定義した
- 知能は「Knowledge(知識)」「Math(数学)」「Working Memory(ワーキングメモリー)」「Visual(視覚)」「Auditory(聴覚)」など、さまざまな項目から成り立っていると主張している
- ライリー氏の評価:
- 大規模言語モデルにとらわれてきた従来の枠組みを脱するという点では評価できる
- しかしこれらの合計がAGIであると見なすのは難しい
■ 5. 認知的飛躍とAIの限界
- 革新的発見の可能性:
- 仮にベンジオ氏らが主張する知能をすべて達成するAIが登場したとしても、それは革新的な科学的発見につながるようなAIではないだろう
- たとえAIが人間の思考を模倣できたとしても、人間が行うような「認知的飛躍」を達成できる保証はない
- パラダイムシフトの本質:
- 「パラダイム」は人々から熱心に支持されるユニークさを持ち、さまざまな問題を研究グループに提示する業績のことを指す
- 科学の歴史ではたびたびパラダイムが大きく転換するパラダイムシフトが起きている
- これは反復的な実験の結果ではなく、既存の科学的記述に当てはまらない新しい疑問やアイデア、つまり認知的飛躍が起きた時に発生した
- 複数の認知領域にまたがるAIの限界:
- 複数の認知領域にまたがるAIシステムは、確かに与えられた指示に対して、高い知能を持つ人間のように予測・再現することができる
- しかしこれらの予測はいずれも既存のデータを電子的に集約・モデル化することで実行される
- 入力されたデータそのものに不満を抱くことは難しい
- 結果として人間のような認知的飛躍を達成する可能性は低い
- ライリー氏の結論:
- 確かにAIシステムは私たちの知識を興味深い方法でリミックスし、再利用するかもしれない
- しかしAIにできることはそれだけである
- AIは私たちがデータにエンコードし、学習に使用したボキャブラリーの中に永遠に閉じ込められてしまう
- 思考し、推論し、言語を用いて互いの考えを伝え合う存在である実際の人間は、世界に対する理解を変革する最前線にとどまり続ける
「英国の銀行システムには、今も1960～1970年代に書かれたソフトウェアコードが使われている」――経営コンサルタント会社Baringaが英国の銀行員200人を対象に実施した調査では、回答者の16％が1960年代のソフトウェアを、約40％が1970年代に書かれたソフトウェアコードを使用し続けていることが分かった。約50％の回答者は、「退職間近の従業員数人のみが理解しているソフトウェアに依存している」と答えた。
半世紀前のコードが支える現代の銀行システム
調査は、英国の銀行システムがレガシーな技術基盤に依存している実態を浮き彫りにした。同調査によると、38の金融機関がパンチカードなど、物理的なシステム上で動作するように設計されたコードを今も使用していると回答した。15％の回答者は、かつて販売されていた、部屋を占有するサイズのメインフレーム用に書かれたコードを稼働し続けていると答えた。
現場からは切実な声も寄せられた。ある回答者は「銀行のATMネットワークは、パッチを当てた古いWindows NT系のサーバで運用している」と述べる。別の回答者は「主要銀行の基幹システムは1970年代に構築され、今もCOBOLを使い続けている」と明かす。COBOLは、税務当局、銀行、保険会社、住宅ローン会社などが使用する信頼性の高い金融、管理システムの頼りになる技術だった。
ある金融機関の上級IT専門家は、1960～80年代のシステムを数多く扱ってきた経験から次のように語る。「古いシステムが長く使われたのは、シンプルで安定し、大量の単純取引を効率よく処理できたからだ。しかし今やレガシーなシステムの理解者は退職を控え、若手はCOBOLを学びたがらない。結果として、金融機関はこれらのシステムから徐々に離れざるを得ない状況にある」
Baringaのポール・ミハイロビッチ氏（銀行および市場技術部門エキスパート）は「複雑な技術資産の中に古い技術が一部残ってしまうのは避けられない」と指摘する。「金融機関は巨大な組織であり、国全体で数百万の顧客にサービスを提供している。技術革新のたびにインフラを全面的に作り直すことは現実的ではない」 銀行が直面する2つのリスク
ミハイロビッチ氏は、数十年前に書かれたコードを使い続けることで銀行が直面するリスクを2つに整理している。
・重要インフラへの深刻なリスク
特定の用途向けに運用されたシステムで長期間使用され、少数の高齢の専門家によって保守されているコードは、重要なインフラにとって重大なリスクとなる。維持できるのは少数の高齢専門家だけで、トラブルが起きても修復は困難となる恐れがある。
機敏性の欠如とコストの増大
・特定のレガシーシステムを維持するためだけに専門家を抱える状況が続けば、顧客ニーズの変化に素早く対応できない。維持コストも膨大になる。
一言で言うと、これは「ClaudeがToolを呼び出す処理をPythonコードとして生成し、 Anthropicが提供するサンドボックス内で実行する」機能です。
従来のTool Useでは、Toolを1つ呼ぶたびにClaudeが次のアクションを判断し、 その結果をすべてコンテキストウィンドウに追加していました。 10個のToolを連鎖して呼び出すと、10回分の推論と、 10回分の生データがコンテキストを圧迫します。
実際、この問題は Claude for Excel で顕著でした。Anthropic 公式記事でも「数千行以上のスプレッドシートを読むだけで、中間データがコンテキストを圧迫し、推論が破綻する」という課題が挙げられています。
Claude for Excel は PTC を利用し、
- スプレッドシートの巨大データをすべてコード実行側で処理し
- Claude が受け取るのは 最終的な集計・分析結果だけ
という形にすることで、コンテキスト肥大化を根本的に解決しています。
PTCでは、Claudeは「Tool呼び出しを含むPythonコード」を一度だけ生成し、 あとはサンドボックス内でPythonが逐次実行します。 中間結果はサンドボックスのメモリ内に閉じ、 Claudeのコンテキストに戻るのは print() で出力した最終結果だけです。
■ 1. Embulkの「メンテナンス・モード」発表
- 発表の経緯:
- 2025年10月15日、GitHubのembulk organizationに入っていたメンバーにメールを送付
- Embulkというオープンソースプロジェクトの「メンテナンス・モード」への移行を提案
- 背景となった問題意識:
- RubyGems周辺で発生したセキュリティ事件から教訓を得た
- 「複数の利害関係者が交わるオープンソース・プロジェクトでは、問題が起こる前にコミュニティで平和的に民主的に話し合えるうちにプロジェクトのガバナンスを実態に即して整えて形にして明示しておくべき」
- 特にセキュリティが重要な課題となりえて、かつ営利企業や金銭が関わる場合には重要
- Embulkの現状:
- 著者がメンテナーとして非アクティブとなり「アクティブなメンテナーはいない」状態になって既に半年が経過
- 本体に近いところでは著者と佐藤さんのみが見ている状態
- ときどきJDBC関係で@hito4_tさんにお声をかけて見てもらっている
- embulk-output-bigqueryについては独立したメンテナーが何人かいる
■ 2. メンテナンス・モードの具体的内容
- 対応内容:
- GitHub orgのメンバーやCore Teamを「今後もそれなりには関わり続ける気がある人」の最小限に絞る
- 「もう積極的にメンテナンスを続けられる状態ではない」ことを残るメンバー間で合意する
- 管理する対象自体（Zulipチャットなど）を減らす
- Embulkそのものについて引き継ぎたいと手が挙がったときは残るメンバーで検討する
- 以上をもって「メンテナンス・モード」とし外部に見える形で宣言する
- 今後の見通し:
- Embulkがアクティブにメンテナンスされることを期待しないでほしい
- pull requestなどを送っていただいてもレビューもマージもされないかもしれない
- Embulkはもともと無保証のApache License 2.0でライセンスされている
■ 3. organizationに残るメンバー
- 最終結果:
- 18人にメールを送付し、10人から期日内に返信があった
- 最終的に4人のみがGitHubのembulk organizationに残ることになった
- @frsyuki（原作者）、@hito4t、@hiroyuki-sato、@dmikurube（アナウンスの書き手）
■ 4. 更新の見込み
- 今後の更新について:
- 「二度と」更新しないというつもりはない
- 気が向いたときには更新するかもしれないが期待はしないでほしい
- ちょっとした改善や整理は入れるかもしれない
- もっと先のJavaへの追随や非互換ライブラリの更新（Jackson 2から3など）のような大きな更新を入れるのは現実的ではない
- 引き継ぎの可能性:
- 引き継ぎたいという人から手が挙がれば残るメンバーで議論する
- ただし実現しないだろうと個人的には思っている
- 昨年にはアナウンスを出していたが積極的な提案や反応はなかった
- 引き継ぎの難しさ:
- 「引き継いでくれるのなら誰でも、私たちが知らない人でも引き継ぐ」という態度は必ずしもユーザーのためにはならない
- 機密データの転送にもEmbulkを使っている組織がある
- 悪意を持つ誰かにEmbulkを引き渡してしまったら問題が起きる
- 悪意を持った引き継ぎの提案は拒否して単純にプロジェクトを継続しないほうがユーザーにとっても良い選択肢かもしれない
■ 5. ミドルウェアの定義と特性
- ミドルウェアの特徴:
- ミドルウェアを直接「使う」のは人間よりも主に誰か他の人が書いたソフトウェア・プログラム
- 「複数のソフトウェア・プログラムから同時に使われる・依存される」ソフトウェアという整理ができる
- ライブラリとの違い:
- ライブラリなら非互換を少し入れてしまっても「アプリケーション・コードのほうを直してね」で済む
- ミドルウェアではそうはいかない
- 典型的なミドルウェアであるRDBMSがいきなりSQL文法や接続プロトコルを変えてしまったら依存関係を考慮した複雑な対応が必要になる
- ミドルウェアの宿命:
- 依存関係グラフが深く複雑になるほど対応も複雑になる
- GuavaやJacksonのような「いろいろなJavaライブラリやミドルウェアから推移的に依存され互換性問題で悲鳴が上がるようになってしまったライブラリ」はミドルウェア的な宿命を背負わされて「ミドルウェア化」してしまった哀しきライブラリと見ることもできる
- 多様なプラグインから依存され、そのプラグインとEmbulkを組み合わせて使う多様なユーザーがいたEmbulkは正しく「ミドルウェア」だった
■ 6. オープンソースとメンテナンス
- メンテナンスの長期性:
- あるソフトウェアがミドルウェアであることと「長期間メンテナンスされ続けてきた」ことはほぼ不可分
- あるソフトウェアが他のソフトウェアから依存され互換性を気にされることはそのソフトウェアがそれなりに長期間メンテナンスされ信頼されてきた証
- オープンソースの現状:
- 近年では使われるミドルウェアの多くをオープンソースが占めるようになった
- この十年強の間に新しく生まれたミドルウェアは企業のsource-availableソフトウェアを除けば大部分がオープンソース
- 大規模なミドルウェアをメンテナンスする苦悩にはオープンソース・プロジェクト運営の苦悩も同時につきまとうようになった
- Honoの例:
- YAPC::Fukuoka 2025でHonoのYusuke Wadaさんが「OSS開発者の憂鬱」というトークをされた
- 「クリエイターからメンテナーへ」「作っていればよかったのが保守しなくてはいけなくなる」「Noを言うには体力がいる」「政治に巻き込まれる」
■ 7. Linux開発者の見解
- Linus TorvaldsとDirk Hohndel氏の発言:
- 「メンテナーの疲労と、その仕事がいかに消耗させられる、ストレスが強いものか」という問題
- Linuxカーネルのメンテナーはその必要不可欠で大変な仕事に以前よりも強い緊張を感じるようになっている
- 「オープンソースの世界はプログラミングがすべてだと思っている人も多いが、実はコミュニケーションが占める割合も大きい」
- 「メンテナーの仕事は翻訳であり、それは必ずしも言葉を翻訳するということではない。文脈、つまりそのコードであるべき理由を説明するということであり、それは大変な仕事だ」
■ 8. 悪意の存在
- サプライチェーン攻撃の現実:
- オープンソース・プロジェクトがソフトウェア・サプライチェーンの重要な位置を占めるようになった
- 悪意を持つ攻撃者にとってオープンソース・プロジェクトは格好の攻撃対象になっている
- サプライチェーンの根っこのほうを乗っ取れれば攻撃者にとって得るものが大きい
- XZ Utilsの事例:
- XZ Utilsに悪意のあるコードが挿入された問題（CVE-2024-3094）が確認されたのが2024年3月
- これは偶然にも氷山の一角が見つかった幸運な事例
- おそらくいくつかの攻撃は既に成功していて私たちのソフトウェア・サプライチェーンには悪意のあるコードがとっくに入り込んでいると認識しておくべき
- Embulkでの経験:
- 確実な証拠や確信こそ無いものの「これは攻撃だったんだろうな」という事例があった
■ 9. 個人によるメンテナンスの限界
- 現状の問題:
- 多くのオープンソース・ミドルウェアや「ミドルウェア化」したオープンソース・ライブラリが「個人」の手になるメンテナンスに依存
- 多くのメンテナーが「疲弊」している
- この数ヶ月の間だけでもcurlやlibxml2の話題が挙がっている
- エコシステムの持続性への疑問:
- 個人で続けられるか疑問
- 私たちのソフトウェア・エコシステムがいつまで保つか
- 2025年の日本各地で問題のクマ対応とも相似形の問題を感じる
■ 10. Embulkの場合の詳細
- 著者の状況:
- 半年ほど前にTreasure Data（TD）を退職
- Embulkの「アクティブ」なメンテナーから「降りて」いる状態
- この時点でEmbulkには「個人」のメンテナーしか残っていない状態だった
- 新しい職場でEmbulkを使う見込みはなかった
- 以前からの活動:
- 「オープンソースとしてのEmbulkのメンテナーを他にも割り当ててちゃんと引き継げる状態にしませんか」という活動を社内で数年前からしていた
- 社外でもEmbulkを使っていると対外的にも知られた企業さんなどに「一緒にメンテナーやりませんか」と言ってきた
- Core Teamのような形を作って少しずつでも関わってもらおうという取り組みもしていた
■ 11. プロジェクトをたたむ決断
- 決断の背景:
- 引き継ぐ意志を明示的に示す人や組織が現れない限り既定路線だった
- 当時の勤務先から積極的なサポートも見込めなかった
- 自分はオリジナルの作者でもない
- 個人として続けても安定した収入に結びつくわけでもない
- メンテナンスを続けるしんどさだけがそこにある
- 「これは攻撃だったんだろうな」の件も最後の追い打ちになった
- たたみ方の方針:
- 「メンテナンスを静かに止めて言及も止めてアナウンスもせず、いつの間にかフェードアウト」のような態度を取るべきでないと考えた
- 企業などで重要データを運ぶこともあるEmbulkのユースケースを考えれば盛大に事故る前に落ち着いて切り替えができるうちに公式なアナウンスをしておくことがメンテナーの責務
- 悪意を持った人や組織にプロジェクトを引き継いでしまうくらいなら、プロジェクトをちゃんとたたむほうが結果的にユーザーにとっても良い
■ 12. 軟着陸のための方針
- 取り組み内容:
- 「このままだと続かないよ」という広報を陰に陽に続け、引き継ぐという人や組織が現れれば歓迎し、引き継ぐために労力を割く意志も示す
- 引き継ぎやすくするために今のEmbulkの設計について「なぜそうしたのか」を記録したドキュメント（Architectural Decision Record的なもの）をなるべく書き残す
- 「メンテナンス・モード」になっても即座に「使えなく」はならない程度に「塩漬け」の準備をする
- 評価:
- 100%狙いどおりにいったとは言えないが、たたみ方として悪くない着地になった
- Embulkのコア機能やSPI（Service Provider Interface）の設計はよくできている
- もうしばらくはこのままでもいちおうは「使える」
- ただし無保証のオープンソース・ソフトウェアなので保証はない
- 「いちおうは使える」うちに落ち着いて移行や社内forkなどを進めることをおすすめする
■ 13. 引き継ぎの困難さ
- 現在の引き継ぎの可能性:
- いまからでも引き継ぐ道筋はいちおう残している
- ただし当時ほど現実的な選択肢ではもうない
- 困難な理由:
- 「引き継ぎのために著者が割けるのは100%プライベートの時間のみになった」こと
- 「引き継ぎを申し出た人や組織に『悪意がない』ことを確認するのが難しい」こと
- それらを乗り越えてでも引き継ぐ意志のある組織の方がいれば連絡してほしい
■ 14. メンテナーの仕事と責任
- メンテナンスの困難さ:
- オープンソース・プロジェクトを、中でも「ミドルウェア」的な立ち位置になったソフトウェアのメンテナンスを「個人」の手のみによって続けるのは無理
- これは一つのオープンソース・プロジェクトのメンテナーを十年近く続けてみることで得た当事者としての結論
- 開発とメンテナンスの違い:
- 新規のオープンソース・ソフトウェアを開発するとか定期的に「コントリビューションする」とかはけっこう「個人」でできる
- しかし「メンテナー」の役務はこうした「開発」とはまったく異なる
- オープンソース・ミドルウェアのメンテナーが担うのは聞き取り、コミュニケーション、判断、意思決定、その意思決定の末にやってくる結果に責任を負うこと
- 責任の本質:
- オープンソースは「無保証」でありユーザーが損害を被ってもメンテナーはその損害に責任を負うものではない
- しかし「俺は俺が公開したいコードを好きに公開してるだけだし、ユーザーのことなんか知らね」と考える開発者なら最初からオープンソース・ミドルウェアの開発やメンテナンスなんかやっていない
- 「あのときの自分の判断と意思決定の結果、どれだけのユーザー開発者がどのような影響を受けたのか」に向き合い続けるのがオープンソース・ミドルウェアのメンテナー
- Linuxからの教訓:
- メンテナーは異なる意見を持つ開発者間の調停役を務めたりベンダーやユーザーとやり取りをする必要もある
- 「開発者を見つける方はずっと簡単だ。開発者はたくさんいる」
- 「メンテナーになるためには、他人のコードの善し悪しを判断できるだけのセンスを持っていなければならない」
- 「それは通常、単に十分な経験があるかどうかの問題だ」
■ 15. 企業・組織の貢献と責任
- 企業ユーザーの困難:
- 「企業ユーザー」が依存し始めた「ミドルウェア」のメンテナンスを「個人」の手のみによって続けるのは無理
- しかし「企業ユーザー」は無理では困ってしまう
- コントリビューションの誤解:
- 「もっと積極的に『コントリビューション』します」と考えるなら記事を読み返すべき
- 徒に「コントリビューション」（pull requestなど）ばかりを増やすのはむしろメンテナーの負担を増やすだけの結果になるかもしれない
■ 16. オープンソース・プロジェクトの現在地とポリシーを知る
- 把握すべきこと:
- 依存しているそのオープンソース・プロジェクトはどこの誰がどう開発やメンテナンスをしているか把握しているか
- 様々なケース:
- 一個人が趣味で開発・公開しただけのまだ「メンテナンス」という段階ですらないもの
- 開発者自身がオーナーシップを握って互換性など気にせず変えながら外部からのコントリビューションも入れず好きなように開発したいと思っているもの
- 個人や数人レベルで開発しつつそろそろライブラリやミドルウェアとして安定してきていろんな人に使ってもらいたいと思っている段階のもの
- 企業発のオープンソース・プロジェクトだが社内で作ったコンポーネントをせっかくだからと公開しただけで広く使ってもらおうという気は特になく社外の互換性都合など気にするつもりもなく外部からのコントリビューションを受け付ける気もないもの
- 企業からオープンソース・プロジェクトとして公開しているが外部からのコントリビューションを受ける気はなく自社プロダクトを購入してもらうための導線として公開しているだけのもの
- 企業発の門戸を開いたオープンソース・プロジェクトとして主導権は持ちながらエコシステムとともに発展させたいと考えているもの
- 個人や企業から始まったオープンソース・プロジェクトだが大規模化して複数の個人や企業関係者が意思決定に参加するはっきりしたガバナンスを持つプロジェクトになっているもの
- 個人発でも企業発でも今後のメンテナンス継続に限界を感じている状態のもの
- これらのケースの間のグラデーションのどこかに位置するあいまいな状態のもの
- 判断の必要性:
- 一口に「オープンソース・プロジェクト」といってもいろいろ
- 「オープンソース」はただのライセンスでしかない
- あなたの企業はそのオープンソース・プロジェクトに依存しても大丈夫か
■ 17. オープンソース・プロジェクトが求める貢献の形
- pull requestの誤解:
- プロジェクトをGitHubに公開すると問答無用でpull requestを受け入れる状態にさせられてしまう
- 「オープンソース・プロジェクトにはpull requestという名の『コントリビューション』を送るものなんだ」という「誤解」がすっかり広まってしまった
- オープンソースであってもすべてのプロジェクトが外部からのpull requestを実際に受け入れているとは限らないし受け入れていても喜ばれるとは限らない
- 求められる貢献の形:
- ただ応援してほしいだけかもしれない
- スターがつくと嬉しいプロジェクトもあるかもしれない
- いろんな人からのpull requestが嬉しいプロジェクトかもしれない
- バグ報告は欲しいがpull requestは求めていないかもしれない
- スポンサーのほうがpull requestよりも嬉しいかもしれない
- 最終的には自社プロダクトを購入してほしいかもしれない
- メンテナーとして共に持続的に役務を負ってくれる人を求めているかもしれない
■ 18. お金をとおしてメンテナンスに貢献する
- スポンサーの方法:
- GitHub SponsorsやOpen Collectiveをとおしてスポンサーするのが話が早い
- このような形でスポンサーを求めていないプロジェクトにスポンサーするのはややこしいが求めているプロジェクトには遠慮なく支払える
- 企業としての検討:
- 企業としてスポンサー支出に正当性を持たせるのが難しいのはわかる
- すべての依存プロジェクトをスポンサーするのは不可能
- ただし「もしこのプロジェクトのメンテナンスが途絶えたらビジネスの継続にも支障が出る」というオープンソース・プロジェクトはないか
- そういう単一障害点すら特定できていないのであればまずその特定をしたほうがいい
- オープンソース・プロジェクトなんていつ止まってしまうかわからない
- その単一障害点にあるプロジェクトくらいスポンサーを検討してもいいのではないか
- 製品購入:
- そのオープンソース・プロジェクトがあくまで製品への導線で企業ユーザーとしてそのプロジェクトに依存するレベルで使おうとしているならちゃんと製品を購入すべき
■ 19. スポンサーの限界
- スポンサーの現実:
- お金をとおして貢献できるプロジェクトばかりではない
- そのメンテナーが人生をかけて個人でやっているのならスポンサーによってメンテナーの命と生活が助かるかもしれないがそんなプロジェクトはごく少数
- 個人メンテナーにとってスポンサーはお小遣いくらいにはなるかもしれないが安定した収入として生活を支えられるようなものにはそうそうならない
- Embulkの場合:
- 企業発という出自もあってスポンサーを募ったりはしていなかった
- 仮にTreasure Dataとは独立にスポンサーを募って個人としてメンテナーを続けたとしても自分や家族の生活を支えられるとは思えない
- 本質的な問題:
- 多くのオープンソース・プロジェクトにとってスポンサーは継続そのものの助けにはならない
- 多くのオープンソース・プロジェクトには結局本来そもそも持続に必要なだけのメンテナーが「いない」
- 多くのメンテナーが手弁当でメンテナンスを続けている（そして続けられていない）
- Linuxにおいてすらそうである
■ 20. 雇用をとおしてメンテナンスに貢献する
- 課題の本質:
- 私たちの「足元」があとどれだけ保つか
- そこにある課題は「持続とメンテナーの安定」
- 「持続と安定」に対して企業に期待される最もわかりやすい貢献は結局「雇用」
- 現実的な提案:
- ほとんどの企業にとって「オープンソース・ソフトウェアのメンテナーをフルタイムで雇用する」なんていうのは難しい
- しかし強く依存する途絶えては困るオープンソース・ソフトウェアが今後も持続するために雇用コストのごく一部でも正式に割くことはそんなに難しいか
- ほとんどのオープンソース・ソフトウェアはかならずしもフルタイムでメンテナンスに従事するほどのメンテナーを必要としてはいない
- 一方で個人の業務時間外の時間のみで持続できるものでもない
- 具体的な提案:
- 自社が依存するオープンソース・プロジェクトとその現状を把握する
- その維持が苦境にあれば会社としてその「メンテナンス」に貢献する意志を示す
- 従業員がメンテナーとして継続的にそのプロジェクトに関与することを推奨する
- その従業員の勤務時間のn割はメンテナンス活動に使うことを認知する
- それを正式に評価する
- フルタイムではなくこれだけでもメンテナーの状況はかなり改善する
- 危機感:
- 世のbig techな企業はそれとはむしろ逆の方向に舵をきっていそう
- 「たたむ」オープンソース・プロジェクトはこれからおそらく増えていく
- その「足元」であなたの会社のビジネスは継続できそうか
■ 1. Rustに対する著者の立場
- 著者の姿勢:
- かつて自分をRustヘイターと呼んでいた
- しかしそれはStack Overflowの調査で最も愛されている言語としてRustがトップになるようなファンボーイ的傾向を相殺するためだった
- C++を嫌う理由は多くあり、著者もC++を嫌っている
- 多くの人がより良いプログラミング言語を待っていたが、代わりにRustを得た
■ 2. Rustの4つの核心的問題
- コンパイルが遅い:
- 単に遅いのではなく非常に遅い
- C++より遅い
- 年々Rustは数倍速くなったが、客観的には2倍ではなく2桁（100倍）速くなる必要がある
- 複雑である:
- C++と同程度に複雑
- しかしC++にはレガシーがあったがRustにはなかった
- Arc<Mutex<Box<T>>>のジャングルを毎回通り抜けなければならない複雑さが、実装されるロジックの品質に直接影響する
- 木を見て森を見ずの状態になる
- C++も同じ問題を抱えているなら、結局言語を切り替える意味は何なのか
- メモリ安全性はそれほど神聖ではない:
- 実際、多くのアプリケーションではクラッシュするよりも誤動作する方が良い
- 特にRustが存在したがっている組み込みの世界ではそうである
- Rustでは99.999%の信頼性を得ることはできない
- 常にクラッシュする
- 可変共有状態の処理において:
- GUI、データベース、ステートフルサービス、OS/ハードウェアなど多くの可変共有状態を扱う場合
- ネイティブのRustメモリモデルのパフォーマンスは劣る
- 非ネイティブのunsafeを使うとコンパイルが遅く、複雑性が高く、結局メモリ安全性もなくなる
- 重い可変状態の仕事に対してRustは実質的に無意味になる
■ 3. C++の問題点
- 未定義動作の遍在:
- 未定義動作（UB）は言語の基本的な側面
- 単にUBに遭遇するのではなく、言語全体がUBの上に構築されている
- 配列のインデックスアクセスで即座にUBに遭遇する
- 言語が範囲外アクセスをチェックしないため
- 多くのUBはパフォーマンスの理由でさえ正当化されない
- Cから引き継がれC++で増幅された完全にずさんな設計
- C++の具体的な問題:
- 暗黙の型変換、暗黙のコピー、暗黙のコンストラクタ、暗黙のオブジェクトスライシング、ほぼすべてが暗黙的
- 関数オーバーロード（暗黙的）、特にSTLでの遍在性を考慮すると
- 例外を後付けとした非統一なエラーハンドリング
- Cから40年経っても#includeでテキストファイルを取り込んでおり、One Definition Ruleはコンパイラによるチェックがほとんどない
- パラダイムの不健全な組み合わせ（子孫クラスでジェネリック関数をオーバーライドする幸運を祈る）
- ジェネリックプログラミングの中核メカニズムとしてのSFINAEの厄介さ
- T、T&、T*、std::optional、std::unique_ptrで似たようなものを記述するが、それぞれ独自の方法で壊れている。その上にconstを載せる
- 結論:
- C++は複雑で、安全でなく、コンパイラが遅い
- Rustはこれらの問題をどのように修正し（あるいは修正していないか）
■ 4. 遅いコンパイルの詳細
- 設計上の問題:
- 一時的な問題ではなく設計によるもの
- Rust開発チームは毎回コンパイル速度を犠牲にしてきた
- 最適化の努力:
- Rust FAQでは、より良いフロントエンド、MIRなど多くの最適化努力があると説明している
- しかしMIRの取り組みは2015年に開始されたが、依然としてコンパイルを大幅に高速化できていない
- コンパイラチェックは高速化している
- 本質的な問題:
- Rustを高速にコンパイルすることは不可能
- 問題はHaskellのような類似のジェネリクス多用言語に固有のもの
- Rustは議論の余地があるがC++よりもHaskellに近い
- テンプレートを多用するC++コードと同じ遅いコンパイルの問題を示す
- 具体例:
for i in 0..limit {}を実行すると、単に反復するのではなく、範囲を作成し、イテレータを作成し、それを反復する- すべてが具体的な型に単相化され、個別に最適化される必要がある
- 最適化されていないRustコードは非常に遅く、デバッグにさえほとんど使用できない
- ボローチェッカーの影響:
- その上に非オプションのボローチェッカーを載せると、非常に遅いコンパイラになる
- ボローチェッカーは容赦ないので、何度も再コンパイルすることになる
■ 5. 複雑さの詳細
- 回避不可能:
- 「コールドパスの高レベルコードを書いているのでパフォーマンスは必要ない、ライフタイム処理の深みに入る必要はない、単に高レベルのロジックを書きたい」という姿勢は取れない
- Rustの1行を書くたびに低レベルの細かい点に強制的に押し込まれる
- ガベージコレクタの不在:
- RustにはGCがなく、今後もない
- すべてのデータを所有権のツリーに半手動でパックする必要がある
- 数行のコードを書くだけでも所有権、借用、トレイトに精通している必要がある
- 高レベルロジックの困難:
- Rustで高レベルのロジックを書くのは非常に困難
- 多くの初期Rust採用者が実際にはパフォーマンスにそれほど敏感でないサービスにはNode.jsやGoに戻っている
- 高い複雑さと遅いコンパイルの組み合わせにより、純粋なRustで複雑なものを書くことが非現実的になる
■ 6. メモリ安全性の詳細
- Rustの妥協しない2つのもの:
- パフォーマンスとメモリ安全性
- Rust設計者はメモリ安全性に関して行き過ぎた
- コンテナの実装:
- コンテナは実際にはunsafe関数で実装されている
- チューリングマシンモデルでは完璧な正しさは不可能
- 慎重に配置されたunsafeなビルディングブロックから安全なプログラムを構築する必要がある
- 他言語との比較:
- Node.jsとGoは実用的に安全な言語と見なされている
- Rustは正気さと実用性をメモリ安全性のために犠牲にした
- そして結局どれも得られず、依然として100%メモリ安全ではない
- 実用性について:
- 多くのユースケースは完璧なメモリ安全性を必要としない
- リモートコードを実行したり秘密を漏らしたりしない安全でないプログラムを実装する方法がある
- ユーザーデータを破損させ散発的に動作するだけ
- ペースメーカーが停止した場合、被害者に「クラッシュ時にメモリは破損していなかった」と伝えても慰めにならない
- Cloudflareの障害事例:
- unwrap()関数でのクラッシュによって引き起こされた最近のCloudflareの障害があった
- 著者の最も強い主張:
- Rustはメモリ安全で信頼性がない
- メモリ安全性の代価は開発者の正気さに加えて信頼性だった
- 言語設計者は行き過ぎた
- メモリ安全性という抽象的な原則のために中核的な実用的品質を犠牲にした
- Haskellの設計者が純粋性のために実用性を犠牲にしたのと同様
- RustとHaskellの類似性を繰り返し指摘する理由
■ 7. 可変共有状態の詳細
- Rustでの可変共有状態:
- 可能だが、Rustで可変共有状態を使用することは意味がない
- ほとんどの利点を失い、Rustのすべての欠点だけが残る
- 成功したRustプロジェクト:
- ほぼすべてが共有の読み取り専用状態、一方向データフロー、非循環データ構造を採用している
- rustcコンパイラ、mdbookとpulldown-cmarkのMarkdownツール、ステートレスハンドラ用のActixとAxum、追記専用ブロックチェーン、シングルスレッドWASM
- モデルはHaskellに非常に似ている
- Haskellもパーサー、ステートレスハンドラ、ほぼ非インタラクティブなCLIツールで優れており、ブロックチェーンで使用されてきた
- Software Transactional Memory:
- Rustの初期プロトタイプには安全な並行性のオプションとしてSTMがあった
- しかしSTMにはパフォーマンスペナルティがあり、単純だが重要なランタイムサポートが必要
- 共有可変状態に踏み込むと:
- メモリ破損は例外ではなくルールになる
- 破損を処理する必要があり、単にクラッシュすることはできない
- ボローチェッカー、所有権は役に立たない
- GCのようなアルゴリズムなしで循環グラフの所有権を分析することはできない
- Sync/Send、Mutex、Arc:
- ロックするか、CPUキャッシュをひどく乱すので、マルチスレッド通信には非効率
- 少なくとも集中的なものには
- 安全だが非効率
- Rustの最初の妥協しないもの（パフォーマンス）を破壊する
- 結論:
- 共有可変状態に踏み込んだ瞬間にRustのすべての利点を失う
- Rustの主要なコンセプトが共有可変状態を決して使用しないことだったことを考えると合理的
■ 8. GUIとRustの問題
- GUIは可変共有状態:
- そのためRustで大きなGUIプロジェクトは見られない
- Zed IDEの例:
- 何年も経ってもまだベータ版
- 開発者がボローチェッカーのジャングルを突破してロジックがバグだらけであることに気づき、まだ何十もの他の機能を実装する必要がある苦痛がほとんど感じられる
- まだ見られないもの:
- 大規模データベース
- スケーラブルなステートフルサービス
- オペレーティングシステム
- 少なくとも重要なLinuxモジュール
■ 9. 結論：Rustの評価
- Rustは良いのか悪いのか:
- どちらでもない
- 開発に何千人月も費やされた平凡なプログラミング言語
- この事実だけでRustは実用的なツールになる
- 棚から取り出してそのまま使用できるため
- 具体例:
- このブログはRustで書かれたZolaで生成された
- 使用するためにRustのコードを1行も書く必要がなかった
- Zolaは不変データの一方向フローを持つ非インタラクティブな性質のためRustに適している
- 著者の願い:
- 「Rustは最高のプログラミング言語だから、みんな開発をRustに切り替えるべきだ」と叫び回らないでほしい
■ 1. フルスタックエンジニアを目指すべき理由
- ひろゆき氏が目指すなら「全部やる」エンジニアである
- フロントエンジニアの限界:
- フロントしかできない場合、バックエンドがよくわからないため誰かに頼まなければならない
- その誰かのコストが高かったり優秀でなかったりしても対抗できなくなる
- 全部できることの利点:
- 自分1人で全部できるようにしたほうがよい
- バックエンドをやっている人を選ぶ時に話が通じる
- 優秀な人を見抜くにはその業界の知識が必要である
- サーバーを立てたことがない人に優秀なサーバーエンジニアを選ばせても、どういう基準で話をしたらいいかわからない
- ひと通り理解することを早めにやっておいたほうが人生で得することが多い
■ 2. コミュニケーション能力の必要性
- エンジニアにコミュニケーション能力は必須ではない:
- ひろゆき氏は月に3、4,000万人が使う「4chan」を運営している
- エンジニアとのやり取りは基本的に全部メールかネットワーク経由である
- 直接会ったことがある人は1人もいない
- 電話で話したことがある人は何人かいる程度である
- テキストベースのやり取りの利点:
- 実際のやり取りはテキストベースである
- その人が本当に英語を理解しているかどうかもわからない
- 翻訳ツールを使っているかもしれないが、「これやって」と言ったらやってくれるので困ったことがない
- タイムゾーンの問題もあるため顔を合わせてやる必要がない
- テキストで「これやっておいて」と言ったほうが口頭で説明するよりも情報が伝播しやすい
- コミュニケーションが苦手な方が有利:
- ある国の山奥に住んでいるエンジニアは「都会は人が多くてゴミゴミしていて、自然が美しくないから嫌だ」という理由で移住した
- たぶん彼はコミュニケーションが苦手だが、何の問題もなく暮らしている
- コミュニケーションが苦手な方のほうがエンジニアはやりやすい
■ 3. エンジニア像の多様化
- リア充エンジニアとギーク文化:
- 最近のIT界隈ではリア充っぽいエンジニアが増えているという指摘がある
- オタク的なギーク文化が失われつつあることへの寂しさを感じる声がある
- 実態は両方が増加:
- オシャレ系エンジニアもコミュニケーションが苦手エンジニアも増えている
- エンジニアの枠自体がどんどん増えている
- エンジニアという職業の人が増えているため、ギーク的でニッチなことが好きなオタクと言われるような人数もめちゃくちゃ増えている
- 多様性のメリット:
- 「同じ考え方のエンジニアだけ集めたいです」というのはやりやすくなっている
- 幅広くなってよかったという話である
- 女性エンジニアもそんなに珍しくないため、「女性同士でエンジニアの話したいです」という人でもちゃんとコミュニティが作れる時代になっている
- いい時代になっている
■ 4. SIerの未来予測
- 大規模SIerの衰退予測:
- これからはプロジェクトに必要なエンジニアが減る
- 外注しなくても自社でエンジニアを迎えるようになる
- SIerが衰退している
- AIによる構造変化:
- 「大規模なSIerにお願いして20人チームを派遣してもらって作る」よりも「めちゃくちゃ優秀なエンジニア1人がAIを使い倒して、20人分のコードを書かせる」ほうがよい状況になる
- 本来ならSIerに頼んで「20人月です」という案件でも、フリーランスのすごい人が「じゃあこれ4ヶ月で俺1人でやりますよ」と言えるようになる
- 発注側もその1人と話すだけで済み、20人月で契約するより安く話が早い
- SIerの今後:
- 大規模SIerはけっこう仕事が取りづらくなる
- 1人でフリーランスをやっててAIを使って「コードはバンバン書けます」という人はかなりいい金額を取れるようになる
- SIer的な仕事自体は残る
- 「20人派遣します」みたいな大人数前提のやり方は銀行業界など特殊なセキュリティ要件があるところを除けばわりと衰退していく
■ 5. 発言スタイルと切り抜かれやすさ
- 意図的な発言スタイル:
- ひろゆき氏はわざと切り抜かれやすいような言い方をしている
- 尖った発言のほうが切り抜かれやすい
- 端的に説明したほうが理解されやすい
- 長文が読まれない時代:
- 長い文章を読めない人が日本で増えている
- もともとそんなに読解力が高くない人たちもインターネットを使うようになってきている
- 結論先行型の話法:
- 結論を最初に「はい」「いいえ」「ノーコメント」みたいに言って、そのあとに理由を説明するほうが伝わりやすい
- それをやると最初に「あなたの意見には乗りません」というのがハッキリしてしまう
- 「理由はこれです」と続けるため、人と仲良くしながらフワッと否定するような日本語っぽい言い方がしづらくなる
- だから引っかかりやすい
- 海外生活の影響:
- 岸谷蘭丸氏も同じしゃべり方をしている
- 海外で、しかも学生として生活していた人はこうなる
- 英語圏で生活すると、最初にYes/Noを言ってから理由を言うというのが身についてしまう
- だから日本語で話すときもその感じが出てしまう
■ 6. 就職先選択の基準
- 最も重要な基準:
- 会社に入るときに一番大事なのは「相談できる相手がいるかどうか」である
- 自分がわからないことや「これどうやるのが正解なんだろう？」と聞いたときに、ちゃんと丁寧に教えてくれる人がいる会社は所属する価値がある
- それがないんだったら「自分ひとりでやってるのと一緒じゃん」という話である
- 業種よりも社風:
- 業種がどうこうというより「同僚が、聞いたらちゃんと答えてくれる空気の会社かどうか」のほうが大事である
- 面接での見極め方:
- エンジニアの面接では一次は人事だけだが、二次以降でエンジニアの人が出てくることがある
- そのときにこちらが何か質問したら、どれくらい丁寧に答えてくれるかを見るとよい
- 「あ、この人はちゃんと答えようとするタイプだな」とわかれば、その会社にはそういうエンジニアがいるということである
- 逆に「え、それも知らないんですか？」みたいな反応をしてくる会社だと「あ、ここは自分が入っても質問しにくいな」となる
- エンジニアにとって質問しやすいかどうかやオープンな社風があるかどうかのほうが大事である
- 業種による違い:
- 業種がSESだったとしても、めちゃくちゃ親身になって教えてくれるスタッフが多い会社もある
- 「みんなでちょっとずつスキル上げていこうぜ！」というタイプのところもある
- 一方で、同じSESでも実態はほぼ個人事業主の集まりみたいになっていて「それ自分で調べて」「お前の仕事手伝っても俺の給料増えないし」みたいな人が多い会社もある
- 社風は面接や実際に話してみないとわからない
■ 7. 企業の自社エンジニア枠の増加予測
- 自社エンジニア枠は増加する:
- AIでエンジニアがうんぬんという話があるが、SES自体が減っていって「これは他社に任せるより自社でやったほうがいいよね」となる
- けっこう増えると考えられる
- オウンドメディアの増加:
- 最近「Nintendo Direct」みたいなオウンドメディアを持つ会社も増えている
- 自社でいろいろやろうとすると結局ぜんぶインターネット経由になる
- 物を売るのも知ってもらうのもインターネットになる
- だったらその部分は他社に丸投げするより自社で持ってたほうがいいという話になる
- コスト構造の変化:
- 今までは自社で抱えるとエンジニアコストが高かった
- わりと優秀な人を1人置いておいて、あとはAIにやらせるようなやり方でもそこそこ回るようになってきた
- 中堅企業でも「自社エンジニア枠」をちょこちょこ入れていく流れになる
- フリーランス活用の増加:
- フリーランスと契約して「うちの会社のこと頼んでいる人なんですよ。フリーランスですけどね」みたいな関わり方をするパターンもある
- そういうタイプの業務はこれから増えていく
■ 1. GrapheneOSの概要
- 特徴:
- オープンソースで開発されているセキュリティとプライバシー保護に特化したAndroid系OS
- Google Pixelなどを安全に使うために利用されている
- 問題点:
- セキュリティの高さから麻薬密売人などに使用されることがある
- プライバシーを保護する機能が強力ということは悪事を働いても露見しにくいということにもなる
■ 2. フランス政府との対立経緯
- フランス政府の姿勢:
- 以前から「GrapheneOSは犯罪者向けのもの」と表現するなど敵対視していた
- フランスの治安当局が「隠れて生きる意思を裏付けるもの」として使用することが罪であるかのような調査報告を出したことがある
- GrapheneOSの反論:
- フランス当局の姿勢に反発
- 「ヨーロッパの独裁政権や政権を支持するメディアで、GrapheneOSやPixelを犯罪者向け製品であるかのような誤った表現が使われている」と非難
- 「GrapheneOSはこれらの勢力が全員に強要しようとしている大規模監視警察国家に反対している」と表明
■ 3. Le Parisienの報道（2025年11月19日）
- 報道の内容:
- フランスのメディア・Le Parisienで「Google PixelとGrapheneOS：麻薬密売人が警察からデータを守るための秘密兵器」というニュースが報道された
- GrapheneOSの反応:
- メディアおよびジャーナリストに対し「GrapheneOSについて根拠のない、そして明らかに虚偽の主張をするためのプラットフォームを提供しながら、それらの主張を確認し反論する機会をまったく提供していない」と憤りを示した
- 検察当局者の発言:
- 「GrapheneOSは犯罪組織とのつながりがあり、捜査に協力しないのであれば法的措置に出る」とコメントが掲載された
- GrapheneOSはこれを「事実無根であり、国家による法的脅迫だ」と問題視
■ 4. 機能に関する誤解
- フランス当局の主張:
- GrapheneOSがアクセス時にデータを消去する機能や偽アプリを含む犯罪者向けのOSと主張
- GrapheneOSの反論:
- それらの機能は公式版には存在しない
- オープンソースとして公開しているGrapheneOSの悪質なクローンや非公式版と混同されている
■ 5. フランスからの撤退発表
- 撤退の理由:
- フランスはオープンソースのプライバシープロジェクトにとってもはや安全ではない国であると判断
- プロジェクトとユーザーを守るため今後はフランスへの進出を完全に避ける方針
- フランスの政府機関と法執行機関の行動と発言が極めて懸念すべき点
- GrapheneOSについて極めて不正確で中傷的な主張をしながら明らかに措置を正当化しようとしている
- 「彼らは手の内を見せたので、何か悪いことが起こる前にフランスから撤退する」と表明
■ 6. インフラ移行計画
- 従来のインフラ:
- 公式サイトやソーシャルメディアなどの主要インフラをフランスに本社を置くヨーロッパ最大のクラウドコンピューティングサービスであるOVHに依存していた
- 移行先:
- MastodonやオンラインコミュニティプラットフォームのDiscourseなどをカナダのローカルサーバーと共有サーバーの組み合わせに移行
- 重要なウェブサイトインフラはドイツに拠点を置くウェブホスティングサービスのNetcupに移行
- OVHから脱却する
- 開発者の制限:
- 安全上の懸念からGrapheneOSの開発者たちはフランス国内での作業を禁止している
■ 7. 今後の方針
- AOSPへの貢献:
- 法執行機関やフォレンジック企業が捜査においてAndroid端末を突破するために使用している脆弱性をGrapheneOSで修正することを目指す
- AOSP（Android Open Source Project）に貢献していくと表明
- Googleへの呼びかけ:
- 「Googleからのご連絡をお待ちしております」と述べている
■ 1. 2ちゃんねる創設の経緯
- 立ち上げの動機:
- 暇だったことが第一の理由
- アメリカで大学生をしていた当時、「あめぞう掲示板」を使用していた
- 「自分で作れるのか」と試したら作れてしまった
- 高いモチベーションがあったわけではなく、できてしまったから惰性で続けた
- 学んだこと:
- プログラムを作る力とサービスとして運営していく力は全く別物
- 動くものができても運用しやすいようにコードを修正する必要がある
- トラブル防止のためのサーバー準備も必要
- 世界中の無料サーバーを契約して回り、「ここが落ちたら次はここ」というルートを事前に用意する運用ノウハウを蓄積
■ 2. 技術選定とシステム設計の考え方
- 使用言語:
- 当時からPerlで書いており、現在も同様
- データベースを使わない理由:
- データベースはたまにデータが壊れる
- 約10年前に某企業のOracleデータベースのデータが全消失した事例がある
- データベースを使うとメモリやCPUのオーバーヘッドが大きくなりサーバーコストが高くなる
- テキストファイル保存の採用:
- テキストファイルに書き出せば壊れにくくできる
- お金がない中での工夫
- 「どうやったら安く、壊れにくく動かせるか」という発想
- このノウハウはその後のIT系会社経営でも活用
■ 3. 潰れない会社の経営哲学
- 基本原則:
- 会社が潰れるのはお金がなくなった時
- お金がなくならなければ会社は生き残れる
- 毎月のランニングコストをいかに安くするかが重要
- よくある失敗パターン:
- 売上を上げていく過程でコストも上がる
- 売上が下がった時に赤字になり大慌てになる
- 一度上がったコストを下げるのは非常に困難
- その結果として倒産するケースが多い
- 実績:
- 1999年に大学生の時に作った合資会社は現在も存続
- 2001年頃に作った株式会社も現在も存続
- 自分の会社を潰したことはない
■ 4. サービスを当てるための考え方
- 仮説の作り方:
- 他にないことで「自分がそれを知りたい・やりたい・おもしろいと思うか」が基準
- 自分自身がおもしろくないと思うと飽きて続かなくなる
- 「別に自分が作らなくてもいい」「既にある」と思うと飽きてしまう
- 自分の欲望に沿うタイプ
- 他のアプローチとの違い:
- 「世間で流行っているから作る」というソシャゲー系の作り方はできない
- 好き嫌いに関係なく儲かるものを作る人もいるが、自分はそれができない
- 人の性格による違い
■ 5. 2ちゃんねる立ち上げ期の戦略
- 当時のインターネット環境:
- 企業がサイトを作って運営することは少なかった
- ネット決済やクレジットカード入力はほぼ存在しなかった
- 個人がブログを書いてサイトを作るのが普通だった
- 情報を出す人が少なかった
- 「日本語で書かれているページはだいたい全部見た」という人がいた時代
- 昔のファミコンで「発売されたソフトはほぼ全部触っている」という人がいたのと同様
- 「全部わかる時代」だった
- 新しいサイトができたら情報を共有するリンク集が流行していた
- 掲示板を選んだ理由:
- 情報が集まる場所として掲示板はずっと残ると考えた
- 誰でも書けるため情報が出回りやすい
- 人が多ければ多いほど情報が増える
- 競合に勝つための設計:
- たくさん人が来ても耐えられる仕組みにする
- 書かれたデータが消えずに残り続けるようにする
- 利便性を上げることで他のサービスより優位に立つ
- コスト構造の優位性:
- 他のサービス運営者は自腹で回していたため、自分の給料以上の規模にできなかった
- 世界中の無料サーバーをひたすら契約し続けた
- 自分の人件費を除けばコスト構造がほぼゼロ
- 無料で規模だけ大きくしていった結果、日本で一番大きい掲示板になった
- 掲示板とSNSの関係:
- 掲示板はSNSの前の姿といえる
- 昔は掲示板で情報収集・情報共有をしていた
- 今はSNSがその役割を担っている
■ 6. 自宅サーバー学習の価値
- 自宅サーバーの意義:
- 2ちゃんねるも自宅サーバーで運営していた時代がある
- 自宅サーバーでしか学べないことがある
- 具体的なメリット:
- 「GPUをぶん回す」ような処理は自宅で回したほうが安いケースがある
- 「オンプレで自前で持つべきか」「クラウドでやるべきか」という比較ができるようになる
- オンプレという選択肢を持っていないと「AWSとGCPどっちが安いか」という比較だけになる
- 「この部分はオンプレにする」「重要なデータだから社内に置く」といった判断ができる
- 結論:
- 自前サーバーの経験はサービスの管理者になるなら持っておいたほうがよい
■ 7. AI競争の価格面の帰着
- 大企業の動向:
- OpenAIや大きな会社がひたすら投資しているものは残り続ける
- 各社が「超優秀なAIを作る競争」をしている
- 一般ユーザーの実態:
- 一般の人たちは「そこまで必要ない」という時代になりつつある
- ChatGPT3と4の違い、4と5の違いを体感で理解しているユーザーは7〜8割もいない
- 今後の予測:
- Metaの「パソコン1台で動く」「スマホの中で動く」モデルがある
- 中国製の「GPUなくても動く」モデルも存在
- スマホやノートPCの中に入って「これで充分」という時代になる
- 巨大なデータセンターや電力の話が問題にならなくなる
- 「能力が高くなくてもこれで足りる」ものが小さく自分のスマホの中で動く時代になる
■ 8. データベースより軽い設計発想
- データベースの課題:
- データベース連携は便利なミドルウェアも多く、いろんな人が触れるようになる
- しかし当時はサーバーのリソースが少なすぎた
- アクセスが増えるとCPUが詰まる
- データベースは同時書き込みでデータが壊れるため「ロックして1人ずつ書く」動きをする
- アクセスが多すぎるとロックがかかったままになりデータの出し入れができなくなる
- 結果としてサービスが止まる
- 分散処理の問題:
- 「同じサーバーを100台並べて分散すれば処理が100倍になる」というやり方はコストがかかる
- 採用した解決策:
- 「多少順番がズレてもいいからロックしないで書く」
- 「多少の誤差は許容する」という方針
- ロックせずにどんどん追記していく
- 「書き込んだ順番が前後することがあってもしょうがない」という誤差を認める
- この方法でコストは大幅に下がる
- テキストファイルでの運用はこの考え方に基づく
- JSONでのAPI操作:
- 「データベースでガチガチにやるのではなくJSONでやる」というのは同様の考え方
■ 1. ひろゆき氏の現在の開発活動
- 使用言語・ツール:
- Google Apps Scriptを使用
- YouTubeのコメントを収集するアプリを開発
- 出力先をGoogleスプレッドシートにすることで無料でデータ保存が可能
- 現状の課題:
- データ量増加に伴い動作が遅くなる問題が発生
- 有料ストレージの契約を検討したが、費用負担を避けて開発が停滞中
■ 2. AIを活用した開発スタイル
- 今回の開発目的:
- AIがどの程度のレベルでコードを出力できるかを検証する実験
- Geminiに仕様を投げ、やりとりしながら仕様書をブラッシュアップ
- AIが出力したコードの精度を確認し、必要に応じて手動で修正
- 開発における役割分担:
- スクラッチ（初期コード作成）は全てAIに任せる
- デバッグや細かい修正は自分で行う
- 「ここだけ変えて」と指示しても別の箇所まで書き換えてしまう問題が発生
- 手戻りを防ぐための指示方法やAIの反応パターンを観察中
■ 3. 開発ツールの選定方針
- 使用ツール:
- Gemini
- ChatGPT（無料範囲）
- GitHub Copilot（無料範囲）
- 無料ツールを選ぶ理由:
- 有料ツールはいずれ廃れる傾向がある
- 企業が有料で作ったツールも、後から無料のオープンソースベースのものに置き換わる
- PhotoshopやIllustratorに対するGIMPの存在が例
- VS Codeはマイクロソフト製だが無料で使える
- オープンソースは無料で広まり、多くの人に修正されて品質が向上する歴史がある
■ 4. 技育祭と若手エンジニア育成について
- 技育祭の意義:
- 手作り感を出し続けることで参加しやすさを維持
- 「とりあえず参加してみる」までのハードルを下げることが重要
- エンジニアの適性:
- 向き不向きはやってみないとわからない
- 優秀なエンジニアには面倒くさがりが多い
- 「手を動かすのが面倒だから自動化しよう」と考えられる人が強い
- やる気なさそうに見えるタイプが実はエンジニアとして優秀なケースがある
- プログラミング未経験で「必要だからやるか」と始めた人が非常に優秀になるパターンも存在
■ 5. サーバーエンジニアの将来性
- AIの限界:
- サーバー契約の最適解や安いサーバーの提案は可能
- 実際にトラブルが発生した際の修正はAIにはできないことがある
- ネット上にない情報やレアなバグへの対応は苦手
- AIはネット上の情報を統計的に処理して最適解を出す仕組みのため、未知の問題には対応困難
- 人間の強み:
- サーバーの仕組みを理解していれば、別サーバーを立てて冗長構成を保ったまま切り替えるなどの対応が可能
- インフラの前提を理解していない人がAIだけで大規模サービスを構築するのは現状困難
- 自分自身の知識と知能で解決しなければならない問題に対しては人間が必要
■ 6. AI時代におけるエンジニアの知識と経験
- 40〜50代エンジニアの活躍:
- AIがコードを書けるようになり、若手に細かい実装を振る必要がなくなった
- 40〜50代は自分でサーバーを立ててOSを入れてアプリを書くという一連の流れを全て手作業で経験した世代
- 仕組みを丸ごと理解しているため、仕様から削る判断や全体設計の見直しが可能
- 部分最適ではなく全体を見たものづくりができる
- 20〜30代エンジニアの課題:
- イチから物を作る経験が不足しているケースが多い
- CPUだけ速くしてもメモリが詰まる、ストレージが遅いとボトルネックになるといった段階的な切り分けの感覚が身についていないことがある
- DBのテーブル設計変更によるI/O削減やサーバーの疎結合化といったノウハウが不足
- AIに丸投げするとお金で解決する設計になりがち
- 「同じサーバーを10台並べてホットスタンバイにする」といった非効率な提案になる傾向
- 推奨される学習方法:
- お金があまりない環境で自分でゼロから立ち上げる経験を積むべき
■ 7. コンピューターサイエンスの知識の必要範囲
- 不要な知識:
- CPUの内部構造
- アセンブラレベルの理解
- サーバーを自分の手でイチから組む能力
- 必要な知識:
- リモート先のサーバーでCPUがどう動いているか
- メモリがどう使われているか
- コンピューターの基本的な仕組み
- プログラミング言語の習得:
- 1つの言語をしっかり身につければ十分
- 1つマスターすると別の言語を見た時に「言い回しが違うだけ」「こういう仕様なのね」と読み替えられる
- 学び直しのハードルが一気に下がる
- 基礎の重要性:
- メモリの概念がわからない人にポインタを教えるのは困難
- メモリの概念を理解している人には「メモリのラベルを使うためにポインタがある」と説明すれば理解が早い
- 抽象概念よりも基礎のハードウェアを学んだほうが理解しやすい
■ 8. AI時代におけるエンジニアの価値
- エンジニアの強み:
- 仕様を設計できる能力
- 「この予算ならここは削ったほうが回る」というコストとのバランスを見る力
- クライアントへの提案力（「ここを外せば納期が短くなる」「ここを簡略化すればコストが下がる」など）
- お金と時間の感覚に基づいた提案
- AIの弱点:
- コスト感は会社ごと・案件ごとに異なる
- その場でさじ加減できる判断は人間のほうが強い
■ 9. 新卒カードの活用と大企業への就職
- 大企業を選ぶべき理由:
- 「AIを使いこなせなそうな大企業」という決めつけは成長を阻害する
- 大企業にいても自分でAIを調べて詳しくなる人はいる
- 中小企業でも趣味で調べて詳しくなる人はいる
- 「企業が何を与えてくれるか」という基準で選ぶのは好ましくない
- 大企業でしか得られない経験:
- 大企業でしか触れられないノウハウ
- 意思決定の流れ
- 「この規模だとこうやって予算が下りる」という構造の理解
- 「このタイプの案件はこの人が決裁権を持っている」といった内部の仕組み
- エンジニアリングの特殊性:
- 大工は20代で家を一軒任されることはないが、エンジニアは20代でもアプリやサイトを1人で作れる
- 「中小に行けば何でもやらされるから経験になる」と言われるが、そのレベルの経験は個人開発でも可能
- 大企業SIerの課題:
- セキュリティの観点でコーディングにAIを使用禁止のところがある
- AIを使わずに手癖が付くメリットはある
- 「ここはもうAIで書く」という領域が増えているため、人力でコーダーを何年もやった経験が役に立たないケースもある
- 「コードを書くのにAIは一切使うな」というスタンスは現代にそぐわない
■ 10. ITベンチャー企業と若手の働き方
- 20代にしかできない経験:
- 馬車馬のように残業時間を気にせず働くのは20代の時しかできない
- 若いうちに振り切って働いた経験があるかないかで、大人になってからの見え方が変わる
- 自分の最大値や限界を感覚で把握できるようになる
- 「最悪ここまでは踏み込める」という判断ができるようになる
- ベンチャー企業の魅力:
- 大企業では労基の観点から限界まで働く経験がしにくい
- ベンチャーで文化祭のように集中して働く楽しさは若いうちに味わっておく価値がある
- ひろゆき氏自身の20代:
- 自分のサービスが好きで1日十数時間自分の作ったサイトを見ていた
- 夜中にサーバーが落ちたら対応、旅行中でも対応という24時間即応態勢
- バグがあったら直るまでずっと起きて対応
- 苦痛ではなくサービスを維持すること自体が楽しかった
- 「全体的には楽しい」の中につらいところもあるという感覚
- 睡眠時間は事故がなければ限界まで寝るタイプで、トラブルが重なった時だけ徹夜
■ 1. 『コンサルタントの秘密』の概要
- ジェラルド・M・ワインバーグによる主著である
- コンサルタント向けの専門書ではなく、相談されたときの思考法をまとめた普遍的な内容である
- 肩書きではなく「どのように人と関わるか」を扱った一冊である
- プログラムやシステムの話はエピソードとして登場するが本質ではない
- 様々なトラブル事例から「コンサルタントの法則」を紹介している
- トム・デマルコの書籍の源泉となった組織論や発想が含まれている
■ 2. オレンジジューステスト
- 設問内容:
- 朝5時から1,000人分の搾りたてオレンジジュースを提供する
- 缶入りジュースや事前準備は禁止である
- 直前に絞ったジュースを全員に行き渡らせる必要がある
- 合格の回答:
- 「できる。これだけのコストがかかる」と答えることである
- 「無茶だ」「現実的でない」と勝手に判断することは失格である
- コンサルタントの役割:
- 可能な選択肢を示すことである
- それにかかるコストを示すことである
- 選択は依頼主が行うものであり、選ばない選択も含まれる
- 原則:
- 相手の要望を勝手に最適化することは相手の判断を奪う行為である
- 相談される側は判断材料を提供する役割に徹するべきである
- 良し悪しまで口出しすることはお節介である
■ 3. 「そこに無いもの」を見る方法
- 課題の特性:
- 見えないものを見つけることは困難である
- 悩みごとの原因は見えていない場合が多い
- 紹介されている技法:
- ピンの技法は、リストアップ手段が無い対象こそ取り組むべきとする
- 3の法則は、計画を台無しにする原因が3つ考えられないなら思考方法に問題があるとする
- 説明の顔をしたアリバイは、ルールから言い訳を探す行為を指摘する
- 「他人という異文化を利用する」事例:
- ワインバーグはプログラマの生産性向上を依頼された
- 職場では要望があればすぐに購入・作成する方針だった
- プログラマへのインタビューでは「足りないもの」が見つからなかった
- 掃除のおじさんに「黒板を拭いてくれと頼まれたことはない」と言われた
- 黒板は「消すな」という警告付きの個人メモで埋め尽くされていた
- 本来の共有ツールが機能せず、購入したソフトやガジェットも共有されていなかった
- 他者の視点により見えない問題を発見できた
■ 4. AIを活用した「足りないもの」の発見
- 「洗濯物リスト」の作成方法:
- 機能設計時にスライド一枚に要件と実現方法を箱で並べる
- 「この一枚が全体像だが、足りないものは何か」と周囲に問う
- 機能不足だけでなく要件の制限や前提の追加が判明する
- ネットワーク設計や非機能要件周りで発見が多い
- AIの活用方法:
- 要件と機能の不足を尋ねる
- タスクの網羅性とコスト見積もりを確認する
- 図が成立する前提で欠けているものを探す
- 計画を台無しにする原因を3つ以上考えさせる
- AIの特性:
- 網羅性の確保に適している
- 「10個考えて」という無茶な要求にも対応する
- 人間が妥当性を最終判断する必要がある
- 1990年の出版時には存在しなかったAIという異文化を現在は活用できる
- コンサルタント業務の多くをAIに任せられるようになった
- 最終判断は人間が行う必要がある
■ 5. AI時代におけるコンサルタントの本質
- コンサルタントの核心的業務:
- どのような問いを投げるかを決定することである
- どこまで自分で判断するかを見極めることである
- 現代における重要性:
- 正解がない時代では答えよりも良い問いが重視される
- 問いへ向き合う考え方が必要である
- 『コンサルタントの秘密』はAI時代だからこそ読み直す価値がある
特にエンジニア採用では「モダンな技術や最新の開発手法が取り入れられておりあの会社は優秀なエンジニアが数多く集まっている。自分もあの中に入ると何か少しエンジニアとして優越感が出そう」という空気感大事なんですよね。金払いがちょっと良いくらいではこの優越感が得られない。
■ 1. もう限界、Linuxへ - 2025年のPC界隈の変化
- 2025年のPC界隈で静かに広がっている合言葉:「もういい、Linuxを入れる」
- 長年Windowsでゲームをしてきた熟練ユーザーやテック記者までがハイエンドのゲーミングデスクトップを丸ごとLinux(特にCachyOSのようなゲーム特化ディストリビューション)へ移行し始めている
- あるベテラン記者はRyzen 7 9800X3DとGeForce RTX 4070 Tiという典型的なハイエンド構成のWindows 11マシンをあえてLinuxに変えると宣言
- 理由:Windowsはどんどん扱いづらくなっているのにLinuxでのゲーム環境は明らかに良くなっているという感覚
■ 2. Reddit での賛同
- 海外掲示板Redditのテクノロジー版では同じ言葉をタイトルにした投稿が立ち、数千件規模の賛同票が集まった
- コメント欄には「もうWindowsの挙動に疲れた」「AIと広告が増えてOSとしての基本が良くならない」といった声が並ぶ
- 長年Windowsを使ってきたユーザーほど不満を募らせている構図が見える
■ 3. Windows 11のエージェントOS化
- 背景にはMicrosoftの路線変更がある
- Windows 11は「エージェントOS」を掲げ、Copilotと呼ばれる生成AIアシスタントをタスクバーやファイルエクスプローラー、設定画面などシステムの至るところに深く組み込もうとしている
- 最新ビルドではファイルエクスプローラーから直接ドキュメント要約やメール下書き生成を呼び出す機能まで用意
- OSそのものが常時AIと会話することを前提に設計されつつある
- 一方でユーザー体験は必ずしも便利になったという実感と結びついていない
■ 4. Copilotを巡る問題
- Copilotを巡る議論では常に画面の隅にいるだけでなく、AIが基本的な操作に失敗した公式広告動画が批判を浴び、Microsoft自身がその広告を削除する事態になった
- AI連携を強めることでブランドを近未来的に見せようとする動きと、「まずファイルエクスプローラーのフリーズやスタートメニューの不具合を直して欲しい」という利用者側の素朴な要求との乖離がユーザーの苛立ちを増幅させている
■ 5. Recall機能の問題
- 象徴的なのがRecallと呼ばれる機能
- Recallは画面の内容を一定間隔で自動撮影し検索可能な「パソコンの記憶」として保存する仕組み
- Microsoftは暗号化やWindows Helloによる保護を強調するが、実際にはデータベースが平文のSQLite形式で保存されていた時期があり、専門家から「悪意あるソフトや物理的なアクセスに極めて弱い」と警告されている
- プレビュー段階での強烈な反発を受けて一度は提供を見直したものの、その後もInsider向けに再投入するなど方向性自体は変えていない
■ 6. 広告的なUIの問題
- ユーザーの視界を埋める広告的なUIもMicrosoftへの不信感を積み上げてきた
- Windows 11のスタートメニューには「おすすめ」と称するエリアがあり、そこにアプリやサービスのプロモーションが表示される仕様が導入されている
- 設定である程度は無効化できるものの、規定では有効な上、更新の度に挙動が変わることも多い
- 最近ではPCのバックアップを推奨する警告風メッセージとしてOneDriveのクラウドバックアップを促す表示がスタートメニューに出るケースが報じられた
- 黄色い感嘆符で「アクションを推奨」という文言でユーザーの不安を煽りつつ、実態はMicrosoft 365やクラウドサービスの利用を後押しする導線になっている
■ 7. Windows 10サポート終了の影響
- 決定的だったのがWindows 10サポート終了のタイミング
- Microsoftは2025年10月14日を持ってWindows 10の通常サポートを終了し、以後は月例のセキュリティ更新や新機能提供を行わないと公式に発表
- Windows 10は依然として世界のWindowsユーザーの4割前後を占めていたとされ、数億台規模のPCが一斉に期限切れの状態になった
- Microsoftは Windows 11へ移行できないユーザー向けにESU(Extended Security Updates:延長セキュリティ更新プログラム)を用意
- 個人向けでは1台あたり年間30ドル相当の料金、あるいはMicrosoftアカウントとの紐付けやポイント交換による無償枠といった複雑な条件が提示されている
- ローカルアカウントだけで使い続けたいユーザーがESUを利用するには結局Microsoftアカウントへの移行を迫られる形
■ 8. Windows 11のハードウェア要件
- Windows 11側にはTPM 2.0やSecure Bootといったハードウェア要件が課されており、古いPCほどアップグレードが困難になる
- サポート終了に伴う解説記事の多くは「Windows 11要件を満たさないPCではLinuxディストリビューションやChrome OS Flexへの移行も選択肢になる」と明記
- つまりMicrosoft自身のライフサイクル戦略が結果的に「今のWindowsを捨てて別のOSへ飛び移ること」を現実的な選択肢としてユーザーに意識させてしまった
■ 9. LinuxとSteam Deckの台頭
- このタイミングで存在感を増したのがLinuxとSteam Deckを中心とするオープンなゲームエコシステム
- Valveが毎月公表しているSteamハードウェア&ソフトウェア調査の2025年10月版では、Linux利用者の割合が初めて3%を超え3.05%に達した
- 1年前の約2%からわずか1年で5割増の水準
- 依然として94%以上を握るWindowsと比べれば小さな数字だが、傾向としては明確な伸びを示している
■ 10. Protonの役割
- Linux側の下地を作った最大の要因がValveが開発したProtonという互換レイヤー
- ProtonはWineと呼ばれる互換技術をベースにしたソフトウェア群で、Windows向けのゲームをLinux上で動かすための翻訳役を担う
- Steamクライアントに統合され、ユーザーはゲームごとに有効化するだけでDirectX APIの呼び出しがVulkanなどのグラフィックスAPIに変換される仕組み
- 2025年秋時点の調査ではProtonDBの統計に基づき、Windowsゲームの約9割がLinuxでプレイ可能という水準に達したことが報告されている
■ 11. Steam OSとSteam Deck
- 物理ハードウェアとしてはSteam OSとSteam Deckの存在が象徴的
- LinuxベースのSteam OSを搭載したSteam Deckは携帯ゲーム機の形をしたPCとして世界的なヒットを記録
- そのOS構成やドライバー最適化がそのままLinuxゲーム環境の標準的な参照例になった
- Valve自身のハードウェアだけでなく、ROG AllyのようなWindows搭載ハンドヘルドがBazziteというFedoraベースのディストリビューションに入れ替えることでフレームレートやバッテリー効率を改善できる事例も報告されている
■ 12. ハードウェアメーカーの対応
- Linux側のゲーム人口がSteam全体の約3%という水準に達した今、ハードウェアメーカーも無視できなくなっている
- Steam Deck向け最適化を意識してAMDがオープンソースGPUドライバーの開発を強化
- 2025年にはWindows向けでメンテナンスモードに移行した旧世代GPUでもLinux側ではコミュニティ主導のRADVドライバーにより引き続き最適化が続くという構図が生まれた
- Windowsでドライバーサポートが先細りになる一方、Linuxでは過去世代GPUが長く活用される可能性が高く、古いゲーミングPCを延命させたいユーザーにとっては魅力的な要素になりつつある
■ 13. CachyOSの特徴
- CachyOSはArch Linuxをベースに「高速、安定性、ゲーミング最適化」を全面に押し出したディストリビューション
- 公式サイトでは「Blazingly Fast」を謳い、x86-64-v3やx86-64-v4といった新しめのCPU命令セットに最適化されたパッケージを提供することで、同じハードウェアでも標準的なバイナリより高いパフォーマンスを目指している
- 心臓部にあるのがCachyOS Kernelと呼ばれる独自ビルドのLinuxカーネル群
- BORE(Burst-Oriented Response Enhancer)やEEVDFといったCPUスケジューラ、LTO(Link-Time Optimization)、CPUアーキテクチャ別のコンパイルオプションなどを組み合わせ、入力遅延の低減とスループット向上を狙っている
■ 14. Linuxの課題
- もちろんLinuxに移れば全てが解決するわけではない
- 最大の難所として挙げられるのがカーネルレベルで動作するアンチチートとの相性問題
- Battlefield 2042やCall of Duty: Black Ops 6のような大型タイトルではSecure BootとTPM 2.0を有効にした上でRiot VanguardやEasy Anti-Cheatといったカーネル常駐アンチチートを要求するケースが増えている
- こうした仕組みはWindowsカーネルを前提として設計されており、Protonが再現するユーザーランドだけでは対応しきれない
- 技術的なハードルも残る:一部のハードウェアではLinux向けドライバーが未整備だったり、ベンダー純正の設定ツールが提供されていなかったりするため、「買ってきてさせばすぐ使える」というWindows的な感覚は通用しない場面がある
■ 15. 現実的な移行ガイド
- それでもWindowsからLinuxへの移行ガイドは年々現実的なトーンになってきた
- かつてはデュアルブートや仮想マシンで遊び半分に触ってみる程度の提案が多かったが、今では「Steamライブラリーの大半はLinuxで問題なく動く、どうしても必要なタイトルだけWindowsに残し、日常のゲーム環境はLinuxへ移す」という構成を推奨する記事も増えている
- ProtonDBで事前に互換性を確認し、必要に応じてローリングリリースのディストロをデュアルブートで入れるといった具体的な移行シナリオが提示されるようになった
■ 16. OSとしての哲学的考察(「沈黙する回路」)
- OSは単なるソフトウェアではない:朝起きて最初に触れる窓であり、1日の思考を流し込む媒体であり、記憶が堆積していく基盤でもある
- そこに絶え間なく広告や提案が降り注ぐと、心のどこかで自分の時間が少しずつ切り売りされている感覚が芽生える
- 便利さと引き換えに集中の静けさが薄く削られていく
- だからこそ何も語らないOSへの憧れが生まれる:起動しても何もおすすめしてこない環境、こちらから呼ばない限り口を開かないAI、更新の度に性格を変えないデスクトップ
- CachyOSのようなディストリビューションはその憧れを実態に変えるためにカーネルの速度やパッケージの構成といった目に見えにくい部分を丁寧に磨き続ける
- そこでは沈黙そのものが1つの設計思想になる
■ 17. 価値観の問題
- OS選択を単なる好みや慣れの問題として片付けるのは簡単
- しかしWindows 10のサポート終了やAIと広告を全面に押し出すWindows 11の路線、ハードウェア要件とアンチチートの強化によって、Microsoftの設計思想そのものがユーザー側の価値観と衝突し始めている
- 自分のPCを自分が主役の道具として保ちたいのか、クラウドサービスとAIのためのプラットフォームとして受け入れるのか
- その分岐点に立たされたユーザーが「もういい、Linuxを入れる」とつぶやきながらCachyOSのインストーラーを起動する姿は単なるOS乗り換え以上の意味を持ち始めている
■ 1. はじめに:複雑性が問題を生む理由
- ソフトウェア開発には「複雑性が問題を生む」という常識がある
- 問い:
- なぜ複雑になると破綻するのか
- どこから複雑と呼べるのか
- どの瞬間に人の理解が追いつかなくなるのか
- 技術負債はなぜ突然「手がつけられない」段階まで膨張するのか
- ソフトウェアの複雑性を計算量、認知負荷、チーム特性という3つのレンズで読み解く
- ポイントは「複雑なコード」ではなく「複雑さ自体の本質」を扱うこと
■ 2. 複雑性とは計算量の爆発を人間が受け止められなくなる現象
- ソフトウェアの複雑性はしばしば計算量の爆発として語られる:
- O(N) → まだ追える
- O(N²) → 何が起きているか曖昧になる
- O(2^N) → もはや理解不能
- しかしこれは人間の脳にもまったく同じことが起きる
- 人間の作業記憶は7±2個しか保持できない(心理学の古典的研究)
- これはエンジニアにとっては「認知の計算量制限」を意味する
- その後の研究では実効容量は4±1個程度という見解も有力(Cowan 2001など)
- つまりコード設計がO(理解)を超えた瞬間、人は壊れる
- 人間の作業記憶は5〜9チャンク程度しか同時に扱えないとされており、複雑な設計はすぐにこの上限にぶつかる
■ 3. 設計の計算量はコード行数ではなく関係性の数で決まる
- 複雑性はコード量では決まらない
- 関係性(依存・制約・フロー)の数で決まる
- 例:
- AがBを知っていて
- BがCを参照していて
- Cが非同期にAを更新する
- これを理解するには人間はA-B-C-Aの閉路を追跡しなければならない
- これは脳にとってDFS(深さ優先探索)のような負荷
- 関係性が増えるほど理解の計算量は指数的に増える
- コードは線形に増えるが理解コストは指数関数的に増える
- だから設計は突然破綻する
- 崩壊は徐々には進まない
- ある閾値を超えた瞬間いきなり崩れる
- まるで「臨界点」を超えた化学反応のよう
- 依存関係の数が増えると開発スピードより先に「依存の管理コスト」が爆発していく
■ 4. 認知負荷は見えない技術負債である
- 複雑性が破綻するのは技術の問題ではなく人間が処理できる情報量の限界を超えるため
- 認知負荷が高い設計には次の兆候がある:
- 一度読んでも理解できない
- 仕様とコードの対応が不明
- 「ここを変えるとどこに影響する?」が見えない
- レビューが摩耗する
- バグが「点」ではなく「面」で発生する
- これらはすべて「計算量過多」「キャパシティ超過」の症状
- 技術負債とは「認知負荷が金利として積もっていく現象」と捉えるべき
- 技術負債は単なる「後回しの修正」ではなく開発者の頭の中に積み上がる認知負荷そのもの
■ 5. アーキテクチャの本質は計算量の制御
- 設計とは格好いい図を描くことではない
- 本質はただ一つ:「理解に必要な計算量をO(1)に近づけること」
- そのためにアーキテクチャが存在する:
- 層で区切る → 認知対象を一定に保つ
- 責務を限定する → 計算経路を短くする
- 境界を作る → 関係性を切断する
- APIを設計する → 認知を抽象化する
- きれいな設計にも理由がある
- それは美しいからではなく脳への負荷を最小化するため
■ 6. 複雑性の破綻ラインは個人ではなくチームに依存する
- 認知負荷は人によって異なる:
- 初心者はすぐO(爆発)
- ベテランはO(ある程度耐える)
- 設計者はO(ノイズを抽象化できる)
- つまり複雑性の破綻ラインはチーム固有のものであり汎用的な「正しさ」では語れない
- 技術は移植できても認知限界は移植できない
- あるプロジェクトでうまくいった設計が別のチームでは壊滅する理由はここにある
■ 7. 実務で複雑性の爆発を防ぐ方法
- (1) 関係性を減らす(依存を切る):
- イベント駆動で発散した依存を整理する
- 双方向参照を禁止する
- 「AはBを知らない世界」を設計する
- 短い例:UI→UseCase→Repositoryだけにし、UIがRepositoryを直接呼ばないようにする
- (2) 読み方をO(1)に近づける:
- コードが「初見で」理解できる必要がある
- 初回で理解できない設計は複雑すぎる
- 短い例:「この関数は何をするか?」が1画面以内で完結するようにする
- (3) ドキュメントではなく構造で説明する:
- ドキュメントで補強が必要な設計はすでにO(1)ではない
- 短い例:「ここは○○層です」と説明不要なようにフォルダと責務を一致させる
- (4) レビューで認知負荷を観測する:
- レビューの摩耗は構造の疲労
- 短い例:PRに「ここ分かりづらい」コメントが連発したら設計の構造疲労を疑う
- (5) チームの認知限界を把握する:
- ベテランの限界ではなくチームの最低ラインで設計すべき
- 短い例:「新人でも追える構造」を基準にしベテラン依存の暗黙知を排除する
■ 8. おわりに
- 複雑性の問題は理論では説明できるが実務ではほとんど語られない
- しかしソフトウェアが破綻するのはいつだって「人間が理解できなくなったとき」
- ソフトウェアの限界は計算資源ではなく人間の認知資源で決まる
- この視点が定着すると設計やレビューやアーキテクチャの見え方が変わる
- 複雑性を避けるのではなく複雑性と「共存できる形」を探すことが大切
■ 1. libxml2のセキュリティポリシー変更
- libxml2のリポジトリに新しいテキストが追加された
- 内容:
- 趣味人たちによって開発され、たった一人のボランティアによってメンテされているオープンソースソフトウェアである
- テストは適当で、メモリ安全ではなく、セキュリティバグも満載である
- 信頼できないデータに対してこのソフトウェアを使用するのは愚かな行為である
- セキュリティバグは他のバグと同様に扱われる
- 受け取ったセキュリティバグ報告は全てただちに公開され、優先的に修正されることもない
■ 2. libxml2の概要
- XMLを処理するライブラリである
- 多くのLinuxディストリビューションやプログラミング言語に導入されている
- ChromeやSafariといったWebブラウザでも使われている
- 事実上業界標準と言える
- PHPにもあり、DOMやSimpleXMLなどがlibxml2に依存している
- 2000年ごろにDaniel Veillardによって作成された
- 2013年ごろからNick Wellnhoferが貢献を始めた
- 現在はNick Wellnhoferがほぼ一人で保守を行っている
■ 3. 協調的脆弱性開示プロセスの背景
- セキュリティバグは基本的に通常のバグ報告と異なる扱いがなされる
- いきなりGitHubやその他メディアなどでセキュリティバグが公開されると、修正が間に合わないうちに攻撃者に利用されてしまうためである
- セキュリティバグについては各企業のバグバウンティプログラムやHackerOne、IPAなどの機関に報告し、修正されるまで待ってから公開する手順が確立された
- 報告を受けた側も修正版がリリースされるまではセキュリティバグについては黙っておくのが通例である
- これは協調的脆弱性開示プロセスと呼ばれ、現在では多くの開発者やアプリケーションがこのプロセスに従っている
- libxml2はこの業界標準を無視し、セキュリティバグも一律全て公開する、攻撃者に利用されても知ったことではない、という斬新なセキュリティ対策に方針を切った
- 対応されてなかろうが90日で開示というポリシーを強行して大批判を食らったGoogle Project Zeroのはるかに上を行く対応である
■ 4. メンテナーの経緯:Stepping down(2021年7月22日)
- 特に頼んだわけでもないが、いつのまにかlibxml2とlibxsltの事実上のメンテナーになっていた
- 幸いなことにChrome VRPバグバウンティとOSS-Fuzz Integration rewardsによって報酬を得ることができていた
- Googleのこれらの優れたプログラムに感謝する
- 残念ながらセキュリティからの収益が急減しており、最低限の資金を確保するめども立たなくなった
- そのためコントリビュータ・メンテナを退任することにした
■ 5. メンテナンスの再開(2022年1月10日)
- Googleからの寄付のおかげで2022年はlibxml2とlibxsltのメンテナンスを継続できるようになった
■ 6. セキュリティ問題への対応(2025年5月8日)
- 毎週何時間も第三者から報告されるセキュリティ問題への対応に追われている
- これらの問題のほとんどは致命的ではないが、それでも大きな作業である
- 無給のボランティアにとってこれは持続不可能である
- libxml2の開発を継続できるようにいくつかの変更を考えている
- 基本的な考え方はセキュリティバグを他のバグと同じように扱うということである
- セキュリティバグはただちに公開され、他のバグと同じ優先度で扱われる
- この方針は一部のダウンストリームを不安に陥れるかもしれないが、もしかしたら貢献意欲を高めるきっかけになるかもしれない
■ 7. OpenSSFとセキュリティ業界への批判
- 長年この仕事をしてきたので、セキュリティ問題に関わる秘密主義のほとんどはただの茶番にすぎないものであるとわかっている
- OpenSSFのような「ベストプラクティス」は、大手テクノロジー企業がOSSメンテナーに罪悪感を抱かせ、無償で働かせようという圧力に過ぎない
- 最近個人経営している会社をOpenSSFのメンバーにしようとした
- そのためにはまずLinux Foundationのメンバーになる必要があり、これは最低でも年間1万ドルかかる
- これらは非常に排他的な組織であり、なにひとつオープンではない
- いまこそ彼らとその支援者を非難すべき時である
- 長期的にはOSSメンテナーに報酬も払わずにこのような要求を課すことは有害である
- 最近libxsltのメンテナーを辞任したが、このライブラリがふたたびメンテナンスされる可能性はほとんどない
- Google Project Zeroという金で買える最高のセキュリティ研究者がボランティアの首根っこをひっつかんでいる現状では、その可能性はさらに低い
■ 8. 企業の責任への批判(2025年5月10日)
- 肝心な点はそもそもlibxml2はブラウザやOSクラスが使用できるレベルの品質を備えていなかったということである
- Appleがlibxml2をOSのコアコンポーネントに導入したことが始まりだった
- その後Googleも追随し、今ではMicrosoftでさえlibxml2を使用している
- このようなことは決してあってはならないことだった
- 元々は成長のハックのようなものだったが、いまでは彼らは数十億ドルの利益を上げている
- しかしより優れたソリューションへの切り替えや自主開発、libxml2の改善といったフィードバックはない
- これらの企業の態度は無責任である
- 彼らはユーザのセキュリティやプライバシーなど気にもかけておらず、対症療法を行っているにすぎない
- もうこのゲームには参加しない
- 彼らがlibxml2の使用をやめれば、このプロジェクトの健全性は向上する
■ 9. メンテナー退任(2025年8月15日)
- libxml2のメンテナーを退任することにした
- つまりこのプロジェクトは現在ほぼメンテナンスされていないということである
- ここ最近libxml2を触っているのはNick Wellnhoferほぼ一人であり、彼が辞めるということはすなわちプロジェクトの放棄と同義である
- libxsltについては最近Iván Chaveroが後任に名乗りを上げたが、contributionもまだまだといったところである
- libxml2については今後どうなるか未知数である
■ 10. OpenSSFの実態
- OpenSSFはオープンソースソフトウェアの開発・保守を持続的に行うことを推進する組織である
- 有名どころとしては協調的脆弱性開示プロセスの策定・推進などがある
- 協調的なビジョンを達成するためには最低でも年間1万ドルの課金を要求する
- 実際のOSS開発者に貢献が還元されることは特にない
■ 11. Google Project Zeroへの批判
- 協調的脆弱性開示プロセスはOSSメンテナーにタダ働きを行わせるための脅迫でしかないという主張である
- 実際問題としてGoogle Project Zeroはオープンソースが相手でも脆弱性の指摘しか行わず、脆弱性を修正したりパッチを作成したりすることはない
- 高い給料もらってるんだからパッチも書けよといった批判も多々上がる
- 批判の声:
- 「Googleが真剣にハッカー対策をしたいのであればパッチを送ったり資金援助したりするでしょう。彼らは単にCVEバッジを集めたいだけです」
■ 12. 現状と今後の展望
- 実は「放棄された」は言い過ぎで、現在は「メンテナがいない」状態であり、誰かが後任に立候補すれば開発は継続される
- しかしメンテナになったところで報酬も利益もなく、負わされるのは時間と責任だけという損しかない立場である
- そのような立場に好き好んで入り込むのはよほど風変わりな人しかいない
- libxml2はあらゆるOSやブラウザや言語にまで入り込んでいる重大なライブラリである
- そんな根幹の部分がこんなことになっている現状、今後のOSSはどこに向かっていくのか不透明である
package main
import (
"encoding/json"
"fmt"
jmespath "github.com/jmespath/go-jmespath"
)
func main() {
// 1. JSONデータを Goの interface{} に変換する
jsonData := []byte(`
{
"users": [
{"name": "Alice", "age": 30, "city": "Tokyo"},
{"name": "Bob", "age": 25, "city": "Osaka"}
],
"status": "ok"
}
`)
var data interface{}
if err := json.Unmarshal(jsonData, &data); err != nil {
panic(err)
}
// 2. JMESPathクエリを実行する
// クエリ: "users"配列から、各要素の "name" の値だけを抽出して配列にする
query := "users[*].name"
result, err := jmespath.Search(query, data)
if err != nil {
fmt.Println("Error:", err)
return
}
// 3. 結果を表示する
// resultは interface{} 型で返される
fmt.Printf("Query: %s\n", query)
fmt.Printf("Result Type: %T\n", result)
fmt.Printf("Result Value: %v\n", result)
// Output: Result Value: [Alice Bob]
}
■ 1. プロジェクトの文脈把握
- 着手前にプロジェクトの背景と意味を短時間で整理する
- 文脈の要素:
- クライアントが達成したいこと
- 読者や顧客の置かれた状況
- 関係者が大切にしたい価値
- タスクが全体で持つ役割
- 依頼内容が曖昧な場合でも「この案件は最終的に何をよしとするか」だけ先に確認する
- 文脈が整っているため判断にずれが生じない
■ 2. 完璧主義を避けた動的な進行
- 全てが揃わないと動けないタイプではない
- 動くことで目的の精度を上げていく手法を採用する
- 具体的な進め方:
- 最小限だけ整えてまず動く
- 仮の流れをつくって全体像を見る
- 動かす中で深掘りが必要な箇所を判断する
- 依頼者には要点だけ短く確認する
- 止めるのではなく進めながら整えるため、プロジェクトが滞らない
■ 3. 工程の事前設計
- 目の前のタスクだけでなく、その後に起きることを早い段階で組み立てる
- 設計される要素:
- 議事録の粒度や優先順位
- 記事や資料構成の作り方
- 誰の判断がどこで必要か
- 編集から校正、公開までの流れ
- 工程が設計されているため、その場の判断がほぼゼロになる
- 任せていても進行が乱れない理由はここにある
■ 4. 予定の先置きによるペース管理
- 期日を受け身で待つのではなく、自分から先に予定を決めて共有する
- 具体的な先置きの例:
- 「〇日午前にドラフト送りますね」
- 「午後に方向性だけ合わせましょう」
- 「その後は〇日までに進めます」
- 先置きによって関係者の動き方が決まり、全体のテンポが整う
- 気分や混雑に左右されないリズムが生まれる
■ 5. 初動の早さと周囲への配慮
- 外向的でも積極アピール型でもないが、仕事が前に進む
- 初動の早さが理由である
- 具体的な行動:
- 不明点は早めに依頼者へ確認する
- 途中段階をすぐ共有する
- 次の人が作業しやすい形で渡す
- クライアントが判断しやすい状態を整える
- 初動が早いと相手の返答も早くなり、全体が前へ転がりやすくなる
■ 6. 原因帰属ではなく打ち手志向
- プロジェクトが進まない理由を外部に置く言葉を使わない
- 使わない言葉:
- 「返事が遅いから進まない」
- 「条件が揃わないから無理」
- 「指示が曖昧だから止まってしまう」
- 使う言葉:
- 「ここだけ確認できれば進めます」
- 「一旦この形で前に出しておきますね」
- 「先に必要な材料を揃えておきます」
- 原因ではなく打ち手を見る姿勢が自然体の強さにつながっている
■ 7. 推進力の本質
- 推進力は説明の上手さや強い主張から生まれるものではない
- 推進力を構成する要素:
- 文脈をつかむ
- 動きながら目的を整える
- 工程を先に設計する
- 予定でリズムをつくる
- 初動を早くする
- 外に原因を置かない
- この積み重ねがプロジェクトを止めない土台になる
- 自然体、素直、誠実という姿勢が信頼を生み、進め方が推進力を裏打ちする
- 推進力は勢いではなく「整える力」の総量で決まる
第7版の「原則」と第6版の「プロセス」が合体した
第6版「5つのプロセス群」が「フォーカスエリア」として復活し、「40のプロセス」として帰ってきた。が内容は7版ベース
各プロセスのInput/Output,ツール,技法(=ITTOs)など実務的な「統合版」になった
既存の書籍の改訂を除けば、おそらく本書が、私がRDBやSQLについて書く最後の本になると思います（そのあたりの事情については次回エントリで触れます）。
■ 1. CSRF攻撃の成立条件
- CSRF(Cross-Site Request Forgery)は古くから知られる攻撃手法である
- 攻撃者が用意したサイトに仕込まれたフォームから、ユーザがログイン中のサービスに対してリクエストを送信する攻撃である
- ログイン済みのCookieが付与されたリクエストがサービスの投稿APIに準拠していれば、そのユーザのアカウントで不正な投稿が受理される
- 攻撃の手軽さと影響の大きさによって、XSSやSQLインジェクションと並ぶ有名な攻撃手法として認知された
- 従来の対策としては、One Time Token(CSRFトークン)をフォームに仕込み、トークンの一致によって投稿を受理する方法が一般的だった
■ 2. CSRF成立の本質的問題点
- CSRF攻撃が成立する根本原因は「攻撃者のフォームからのリクエストにもサービスのCookieが付与される」点である
- しかし、CSRFトークンが機能していた事実は「このリクエストはどこから来たものなのか」が分かれば対策できる証拠である
- 本来注目すべき欠落は「リクエストの出自がわからない」という点である
- SameSite Cookieの導入によって別のサイトからのリクエストにCookieが付与されないようにすることは対策として成立するが、本質的な問題はリクエストの出自が不明であることである
■ 3. Originヘッダの付与
- プラットフォームの回答は「リクエストにOriginヘッダを付与する」というものである
- 現在のブラウザでフォームをsubmitすると、送られるリクエストにOriginヘッダが付与される
- Originヘッダの値を確認すれば、リクエストが正規のサイトからではないことを容易に判別できる
- Cookieの有無に関わらず、サービスは「意図しないOriginからのリクエスト」を弾くことができる
- このヘッダの必要性は少なくとも16年前から議論されており、7年前にFirefoxが実装することで全てのブラウザがフォームのsubmitにOriginヘッダを付与するようになった
- SameSite Cookieが導入されるずっと以前から「リクエストの出自を知る」ことは可能であり、それを用いて攻撃リクエストを弾くことができた
- fetch()を用いた実装でOriginを確認しながら適切なAccess-Control-Allow-Originを返していれば、「どこから来たかわからないリクエスト」を弾くことはずっと可能であった
■ 4. SameSite Cookieの副次的効果
- SameSite Cookieの登場により、積極的な対策をしてこなかったサービスも受動的な変更によって保護される結果になった
- しかしこれはかなり副次的な効果である
- SameSite Cookieの本来の目的は3rd Party Cookieをマークすることであり、3rd Party Cookie Deprecateの終着点はSameSite=None Cookieが送られないようにすることである
- CSRFは3rd Party Cookieよりも遥かに古くから問題だったが、「サイトを跨いだCookieが送られること」よりも「リクエストの出自がわからないこと」の方がプラットフォームが対策すべき問題とされていた
- SameSite Laxがデフォルトになったことを理由に「Originのチェック」を怠った実装は、本質的な対策を怠った片手落ちの実装である
■ 5. CSRFトークンの必要性の再検討
- OWASPのCSRF Cheat Sheetでは今でもトークンベースの対策が推奨されている
- トークンベースの対策を推奨する理由として以下が挙げられる:
- XSSがあった場合の対策
- ヘッダを改変している可能性
- GETでAPIがあると成立する攻撃
- サブドメインが乗っ取られる攻撃
- XSS問題の反論:
- XSS自体を対策すべきであり、XSSによってDOMに展開されたCSRFトークンを盗めない道理はない
- ヘッダ改変問題の反論:
- ブラウザや拡張に脆弱性があれば、サービス側の対策はバイパスできるため、サービス提供者が想定すべき対策として視点がずれている
- ユーザ設定やProxyが意図的にOriginヘッダを改変する環境は、ルールを守っていないためサービス側が許容する必要はない
- GET API問題の反論:
- 様々な条件でSameSiteやOriginが機能しないリクエストを生成できるという指摘は、「APIがGETだった場合に攻撃が成立する」という条件に収束する
- 副作用のあるAPIをGETで提供している実装は前提として間違っている
- サブドメイン攻撃の反論:
- SameSite Cookieだけに依存した対策は問題があるため、一次防御は「リクエストのOriginのチェック」である必要がある
- CSRFトークンの利点:
- 実装がこなれており堅牢である
- フレームワークがデフォルトで提供することが多く、導入コストが低い
- 現状入っているなら積極的に外す理由はない
- 防御の認識の変更:
- CSRFトークンは一層目の防御ではなく、多層防御の二層目であると認識すべきである
- トークンを使用していても「リクエストの出自を確認する」実装は一層目にあるべきである
- 全ての場所でOriginを確認するのがプラクティスである
■ 6. Fetch Metadataの導入
- 本来は全てのリクエストにOriginをつけるべきだが、「OriginヘッダのあるリクエストはXHRからのもの」という前提の実装が蔓延していたため、ドラスティックな変更ができなかった
- Originヘッダとは別にFetch Metadataが定義された
- 現在のブラウザでは以下のヘッダが付与される:
- Sec-Fetch-Dest
- Sec-Fetch-Mode
- Sec-Fetch-Site
- Sec-Fetch-User
- リクエストの出自を確認する手法は整備されており、これらを無視することはプラットフォームが差し伸べている手を振り払うことと同じである
■ 7. 令和時代の実装プラクティス
- 副作用があるエンドポイントの実装における優先順位:
- POSTにする(副作用のあるAPIをGETにしない)
- Originを確認する
- SameSite Lax/Strictを明示する
- Fetch Metadataも確認する
- Fetch Metadataのサポートに不安がある場合は「存在したら値をチェックする」実装でも良い
- Sec-プレフィックスはJavaScriptから操作できないヘッダであるため、値がある場合だけのチェックでも意味がある
- 実装の特徴:
- 追加のストレージコストが不要である
- コードだけで実装できるためレイテンシーが最小である
- フレームワークのレールの基盤として存在することが望ましい
- この実装から逸脱するコードが必要になった場合、プラットフォームが推奨するレールから外れていることを認識した上で、CORSなどの適切な対策をしながら拡張すべきである
- このベースを伴わずにトークンを載せても片手落ちである
- この実装をベースにしてもトークンがないと防げないCSRFが可能であれば、それはプラットフォームにおけるバグの可能性が高く、W3CのWebAppSecなどで議論すべき題材である
■ 1. Prismaの問題提起
- 3年間のPrisma本番運用後、パフォーマンス問題とサーバーレスコスト高騰を経験
- データベースアクセスを容易にすると約束したツールが最大のボトルネックに
- ORM全般の根本的問題:生産性と型安全性を約束したが複雑さとパフォーマンス問題をもたらした
■ 2. Prismaの魅力と落とし穴
- 魅力的なマーケティング:
- 型安全なデータベースアクセス
- 自動マイグレーション
- SQLを書く必要がない
- 単一のスキーマファイルで全てを生成
- クリーンで読みやすく型安全なコードに見えるが実際は問題だらけ
■ 3. パフォーマンスの現実
- バンドルサイズ:
- Drizzleは約1.5MB
- Prismaは約6.5MB
- サーバーレス環境では重大な影響
- N+1問題の深刻化:
- 一見単純なクエリが実際には数十のデータベースラウンドトリップを生成
- 単一のJOINクエリであるべきものが47個の個別SQLステートメントを生成した事例
- フロントエンドでTanStack Queryを使ってこの問題を回避したのにバックエンドでPrismaにより再現
■ 4. サーバーレスでの悪夢
- AWS Lambdaのコールドスタートが200msから2.5秒に増加
- Prismaが実行前に必要な処理:
- Rustベースのクエリエンジンバイナリのロード
- 内部GraphQLサーバーの起動
- コネクションプーリングの初期化
- クライアントインターフェースの生成
- Drizzleのような軽量ソリューションではサーバーレス関数のロードと実行がPrismaより遥かに高速
■ 5. 開発者体験の幻想
- Prismaの最大のセールスポイントは開発者体験(DX)
- 実態:シンプルなことに対する優れたDXは複雑なことに対する酷いDXを意味する
- スキーマロックイン:
- 全てがschema.prismaファイルを中心に回る
- PrismaのDSLに収まらないことをする場合は困難
- PostgreSQLのJSONB演算子などデータベース固有機能の使用が困難
- 複数テーブルの式(CTE)を含む複雑なクエリは生SQLに戻る必要があり、パラダイムを混在させ型安全性を失う
■ 6. コード生成の問題
- スキーマを変更するたびにprisma generateを実行する必要
- 数千行のTypeScriptコードを再生成
- IDEがフリーズし、ビルドプロセスが遅延
- 実行を忘れると型とデータベースが同期しなくなる
- Drizzleではスキーマへの変更が即座に反映される(コード生成不要)
■ 7. マイグレーションの悪夢
- デモでは素晴らしく見えるが本番では別の話
- データ損失の設計:
- カラム名変更時にPrismaは名前変更として検出せず、古いカラムを削除して新しいカラムを作成
- そのカラムの全データが消失
- Drizzleは名前変更の可能性を検出すると対話モードに入り意図を選択させる
- ブラックボックス問題:
- PrismaがSQLマイグレーションを生成するが手書きとは異なる
- 冗長で非効率な場合があり、レビューが困難
- マイグレーションをカスタマイズする際はツールと戦うことになる
■ 8. 抽象化の真のコスト
- Ted Newardは2008年にORMを「コンピュータサイエンスのベトナム戦争」と呼んだ
- ORMはオブジェクト指向コードとリレーショナルデータベース間のインピーダンスミスマッチを排除すると約束
- 実際には排除せず隠蔽するだけ
- 抽象化がリークすると(常にリークする)、ORMの癖と生成されるSQLの両方を理解する必要があり、開始時より悪化
■ 9. 優れた代替案
- Drizzle:
- SQLを知っていればDrizzleを知っている
- コード生成不要、バイナリ不要、魔法なし
- パフォーマンスはPrismaより桁違いに高速
- バンドルサイズ1.5MB対Prismaの6.5MB
- 型安全性を持つ生SQL:
- RustのSQLxはコンパイル時チェック付きSQLクエリをランタイムオーバーヘッドゼロで実現
- TypeScriptではKyselyが同様の利点を提供
- 生SQLの方が実際には優れているという動き:
- より透明:どのクエリが実行されているか正確に分かる
- より高パフォーマンス:抽象化オーバーヘッドがない
- より移植性が高い:SQL知識がプロジェクト間で転用可能
- より安全:インジェクションリスクを認識しているためより慎重になる
■ 10. セキュリティへの影響
- ORMはSQLインジェクションを防ぐためより安全とされるが新しいセキュリティ問題を導入
- マスアサインメント脆弱性:
- リクエストボディに予期しないrole: 'admin'フィールドが含まれていると管理者ユーザーを作成してしまう
- 生SQLではどのフィールドを更新するか明示的に指定するためこのパターンは起こりにくい
- 過剰なデータベース権限:
- ORMは機能するためにより広範なデータベース権限を必要とすることが多い
- テーブルスキーマ情報のクエリ、メタデータへのアクセス、リフレクションの実行が必要
- 最小権限の原則に違反
■ 11. バンドルサイズ問題
- 2024年ではバンドルサイズが重要
- AstroやSvelteKitのようなフレームワークは最小限のJavaScriptを強調
- しかしバックエンドに6.5MBのORMを追加
- エッジコンピューティングとサーバーレス関数では全てのキロバイトが重要
- Cloudflareの無料プランは3MB制限でPrismaはビジネスロジックを1行も書く前にその半分以上を消費
■ 12. ORMが依然として意味を持つ場合
- ラピッドプロトタイピング:何かを素早く動作させる必要がありパフォーマンスが重要でない場合
- ジュニアチーム:チームに強力なSQLスキルがない場合、ORMはガードレールを提供
- シンプルなCRUDアプリケーション:複雑な関係性のない基本的な作成・読取・更新・削除操作
- エンタープライズ要件:一部の組織はコンプライアンスや標準化の理由でORMを義務付け
■ 13. 移行戦略
- 新機能から開始:全てを一度に書き直さず、選択した代替案で新機能を構築
- パフォーマンスボトルネックの特定:プロファイリングを使用して最も遅いデータベース操作を見つける
- ドメインごとに移行:アプリケーション内の境界付けられたコンテキストを選び、そのデータベースアクセスを全て一緒に移行
- ツールへの投資:適切なデータベースマイグレーションツール、クエリビルダー、型生成をセットアップ
■ 14. 結論
- Prismaから離れることでサーバーレスコストを40%削減、パフォーマンスを3倍改善、コードベースの保守性向上
- データベースをより深く理解することを強制された
- データベースを単なるストレージレイヤーとして扱うのをやめ、その力を活用し始めた
- クエリがより効率的になり、データモデルがよりクリーンになり、デバッグセッションが短縮
- ORMは複雑さを隠すことで生産性を高めると約束したが、実際には複雑さは隠されておらず、手遅れになるまで見えない場所に移動していただけ
- データベースから隠れるのをやめ、受け入れ始める時かもしれない
■ 1. ブリリアントジャークの定義
- 優秀だが厄介な人を意味する
- 知識も技術も豊富だが他者への配慮や共感が欠ける
- 結果としてチーム全体の心理的安全性を壊す
- アジャイル開発では透明性・協働・自己組織化が重要だがコミュニケーションを軽視する態度が続くとチームの信頼関係が崩れる
- 生産性だけでなくメンタル面にも悪影響を及ぼす
■ 2. 発生した状況
- 経験豊富で技術力の高いメンバーがいた
- レビューの精度も高く幅広い知識を持っていた
- 一方で他のメンバーに対して厳しい言葉をかけることが多い
- 議論の場では自分の意見を強く主張する傾向
- チーム内の変化:
- チーム内で発言する人が減る
- 意見が対立すると議論が止まる
- ミスを恐れて挑戦を避けるようになる
- タスクの透明性が下がる
- チーム全体の空気が重くなりスクラムイベントも形骸化
- ブリリアントであるはずの存在がチームを静かに壊していった
■ 3. 初動の失敗
- 相手を理解しようと考えブリリアントジャーク本人との1on1やヒアリングを重ねた
- 結果的に問題の先送りに過ぎなかった
- 本人も悪気はない、相手に合わせればうまくいくかもしれないと考えて直接的な指摘を避けた
- この判断はスクラムマスターとしての誤り
- 人間関係の摩擦として捉えチーム全体の心理的安全性という観点を見落とした
■ 4. 方針転換
- チームのモチベーションが下がる中で方針を切り替えた
- 個人への歩み寄りではなくチーム全体を守るための行動を取ることに決定
- 具体的なステップ:
- 現状を客観的に整理:問題の発言や行動を具体的に記録し事実ベースで状況把握
- 関係者と情報共有:チーム外のマネジメント層や関係者に相談し客観的な視点で見てもらう
- チームへのサポート:疲弊しているメンバーにフォローの時間を設け安心して意見を言える環境を再構築
- チーム全体の合意を得ながら担当業務や役割を調整する形で体制を見直した
■ 5. 結果
- 体制変更後チームの雰囲気は驚くほど改善
- 改善の具体例:
- ミーティングでの発言が増え議論が活発に
- 新しいアイデアや改善提案が出るようになる
- チームの生産性が向上し遅れていたスケジュールを挽回
- チームが協力して成果を出すというアジャイルの本質に立ち返ることができた
■ 6. 学びと教訓
- 個の能力よりチーム全体の健全性を守ることが最優先:
- どれほど有能でもチームを壊す言動を放置してはいけない
- 成果を上げるのは個人ではなくチーム
- 問題は早期に毅然とした態度で対応する:
- 違和感を感じた段階で客観的に相談・共有することが大切
- 言いづらいから放置は最終的に全員の負担を増やす
- 心理的安全性をチーム文化として根付かせる:
- 誰もが意見を出せる環境を維持すること
- その文化があればブリリアントジャークの影響は最小化できる
■ 7. 結論
- ブリリアントジャークはどの現場にも潜むリスク
- 防ぐ方法は特別なものではない
- 透明性・信頼・早期対応の3つを意識し続けるだけでチームは崩壊を防げる
- スクラムマスターの役割は課題を抱え込むことではなくチームの安全と健全性を守ること
- ブリリアントな個人よりも協働するチームこそが最大の力を発揮する
■ 1. バイブコーディングの問題提起
- 大規模言語モデル(LLM)によるコード生成がソフトウェア開発の風景を一変させた
- 多くの開発者は雰囲気(vibe)に頼ったコーディングの危うさを感じ始めている
- MITの研究チームが概念と同期という2つの要素を核とした新しいソフトウェア構造パターンを提案
- 人間とAI双方にとって可読性の高い(legible)ソフトウェアの実現を目指す
■ 2. 機能の断片化問題
- 現代のソフトウェアは内部構造が極めて複雑化
- 一つの機能(例:SNSアプリのシェアボタン)でもロジックが投稿、通知、ユーザー認証などコードベースの複数箇所に散らばる
- MITのDaniel Jackson教授がこれを機能の断片化と呼び、システムの保守性や信頼性を著しく低下させる根源的課題と指摘
- LLMの台頭によってこの問題がさらに深刻な形で顕在化
■ 3. AIコード生成の課題
- GitHubの最新データではAIによるコード支援は普遍的となり開発効率を飛躍的に向上
- プロセスはバイブコーディングと揶揄される
- LLMは驚くべき速さでコードを生成するが既存システムとの相互作用や副作用を完全には理解していない
- 既存コードベースへの機能追加指示で意図しないモジュール変更や既存機能破壊が頻発
- 堅牢なコーディングに不可欠な3要件の欠如:
- インクリメンタリティ(局所的変更で小さな改善を重ねる能力)
- インテグリティ(既存機能を破壊しない能力)
- トランスペアレンシー(変更内容や実行時動作が明確であること)
■ 4. 概念(Concepts)の定義
- ユーザーが認識する機能の自己完結した単位
- SNSアプリでは投稿、コメント、いいね、フォローといった個々の機能が独立した概念として定義
- 特徴:
- 自己完結性: 各概念は自身の状態と実行可能なアクションを保持
- 独立性: 概念同士が直接的な依存関係を持たない
- 特定機能の修正・拡張時に他機能のコードを気にする必要がない
- マイクロサービスと類似するが決定的な違いは概念が互いに完全分離されている点
- マイクロサービスは相互にAPI呼び出しでもつれたクモの巣のような依存関係を生み出しがち
■ 5. 同期(Synchronizations)の役割
- 独立した概念間の相互作用を記述するための宣言的なイベントベースのルールセット
- 複雑な手続き型コードではなく「何が起きたら何をするか」というルールを定義
- 記述例:
- ユーザーAが投稿Pにコメント実行時(when)
- 投稿Pの作者がユーザーBならば(where)
- 通知概念の送信アクションをユーザーBに対して実行(then)
- ドメイン特化言語(DSL)を用いてシンプルかつ明確に記述
- 宣言的性質によりルールセット全体の見通しが向上
- LLMによる自動生成や形式的検証も容易
■ 6. AIとの相性の良さ
- LLMに与えるコンテキストを限定可能:
- 概念のコード生成時はその概念の仕様のみに集中すればよい
- アプリケーション全体の複雑さを考慮不要
- 同期ルール生成時も各概念のインターフェース仕様の理解で足りる
- LLMへの指示(プロンプト)がシンプルになり生成コードの精度と信頼性が劇的に向上
■ 7. バグ修正事例
- 問題: ユーザー登録フローで不正パスワード試行後に正しいパスワードで再試行すると「ユーザーが既に存在する」エラーが発生
- 新モデルでの解決プロセス:
- 問題が発生した一連の処理(フロー)を特定
- そのフローに関連する同期ルール群を抽出
- 抽出したルール群と問題概要をLLMに提示し修正方法を問う
- LLMの回答:
- パスワード検証前にユーザー作成が行われていることが原因と特定
- まずパスワード検証し成功時のみユーザー作成という修正案を新しい同期ルールとして提示
- システム動作が明示的ルールとして記述されているからこそ可能な人間とAIの理想的協調作業
■ 8. 実証実験の成果
- RealWorldベンチマークアプリケーション(Mediumのようなブログプラットフォーム)のバックエンドを実装
- 従来実装では複数サービスやモジュールにまたがっていたお気に入り登録やタグ付け機能が単一の概念として明確にカプセル化
- システムの可読性と保守性が大幅に向上
- LLMを用いた各概念の仕様書・コード・同期ルール生成プロセスもほぼ成功
- 提案モデルが理論上のものではなく実用的な開発手法として機能することを証明
■ 9. 専門家の評価
- バージニア大学Kevin Sullivan准教授の評価:
- 人間の理解に基づいた抽象化である概念の上にソフトウェアを構築することを主張
- ソフトウェア設計の理論と実践における新しく重要な方向性
■ 10. 将来展望
- Jackson教授が描く未来像:
- 再利用可能な概念を集めたライブラリであるコンセプトカタログの構築
- コンセプトは新しい種類の高レベルプログラミング言語になる可能性
- シンクロナイゼーションはその言語で書かれたプログラムになる可能性
- 開発の変化:
- ゼロからコード記述ではなく検証済みの概念をカタログから選択
- それらをどのように連携させるかという同期ルールの記述に集中
- 開発がより創造的で本質的なものになる
- 曖昧な雰囲気ではなく明確な構造と対話により人間とAIが共に未来のソフトウェアを築く知的で冷静な設計図
最近marimoを触ってみたんですが、これが思った以上に便利でびっくりしました。
このツールだけで完結できる場面が多くて、しかもUIがリアルタイムに反応してくれるので、作っていてすごく楽しいんです🎶
驚くほど簡単で直感的に使えますし、「試してみたい！」と気持ちがどんどん湧いてきました。
というわけで、この記事ではそんなmarimoの魅力や、基本的な使い方について紹介していきたいと思います。
ちょっとでも「面白そう」と思ってもらえたら嬉しいです。
Ory Hydraは、低レイテンシ、高スループット、低リソース消費に最適化され、OpenID認定の堅牢なOAuth 2.0サーバーおよびOpenID Connectプロバイダーです。Ory Hydraはアイデンティティプロバイダー（ユーザーサインアップ、ユーザーログイン、パスワードリセットフロー）ではなく、ログインおよび同意アプリを介して既存のアイデンティティプロバイダーに接続します。ログインおよび同意アプリを異なる言語で実装することも容易で、一般的な言語向けのサンプル同意アプリ（Node.js）とSDKが提供されています。
Ory Hydraは、アイデンティティサーバーとしてOry Kratosを使用できます。
■ 1. インターネットアーカイブの到達点と記念行事
- 2025年10月までに保存したウェブページ数が1兆件に到達
- 記念イベント「The Web We've Built」を2025年10月22日に開催
- サンフランシスコ市議会が同日を「インターネットアーカイブの日」に認定
- 30年近くサンフランシスコに拠点を置き1兆ページ超のウェブを保存した功績が評価された
■ 2. インターネットアーカイブの重要性
- スタンフォード大学研究者の見解:
- 過去が常に現在を形作るためウェブページ保存が重要
- 過去は現在が今のままである必要がないことを教える
- 次のフェーズ:
- 3D環境やオンラインゲームなどデジタル構築体験の保存方法を模索
■ 3. National Emergency Libraryをめぐる訴訟
- 2020年3月にコロナ禍対応として140万冊のデジタル書籍を提供開始
- インターネットアーカイブはフェアユースと主張したが出版社が著作権侵害として提訴
- 敗訴により50万冊の書籍が貸出リストから削除された
- プロジェクトの目的:
- Wikipediaが書籍スキャン画像にリンクできるようにする
- 研究者の電子書籍参照を容易にする
- 創設者ケール氏の批判:
- 数十億ドル規模の巨大メディアコングロマリットが情報の流れをコントロールすることに独自の利益を持つ
- Wikipediaの読者が書籍にアクセスできないようにすることに成功した
■ 4. Great 78プロジェクトをめぐる訴訟
- 数十万枚のレコードをデジタル化してオンライン上で保存・公開
- 2025年4月に音楽レーベルから6億9300万ドル(約990億円)の賠償金請求
- 2025年10月に非公開条件で和解が成立
■ 5. 訴訟後の現状と評価
- 2025年10月時点で大規模な訴訟やコレクションへの脅威には直面していない
- ケール氏のコメント:
- 生き延びたがライブラリの一部は消滅した
- 再建と再定義の段階に入っている
- 法廷闘争の本質:
- クリエイターや出版者ではなく大手メディア企業との争い
- 著作権による制限に満足せず、それ以上を望む企業との対立
- 企業はWayback Machineの終焉を望んでいたと推測
■ 6. 図書館の役割に関する議論
- 著作権弁護士コートニー氏の主張:
- 図書館がHuluやNetflixになることを望んでいない
- 文化の保存と知識への平等なアクセス提供という役割を果たしたい
- 遠隔アクセスは高齢者、障害者、地方住民、海外派遣時に有益
- 著作権弁護士バトラー氏の指摘:
- 他の図書館も重要な法廷闘争に直面
- 出版者の高額訴訟の恐れから保存のためのデジタル化が遅延する可能性
- 訴訟は誰が文化的記録を保存できるのかという社会的課題を浮き彫りにした
■ 7. 今後の展開と懸念
- Democracies Libraryプロジェクトの拡大:
- 世界中の政府の研究と出版物を収録した無料オープンなオンライン集成
- Wikipediaとリンクして研究者の情報アクセスを向上
- AI発展による懸念:
- AI企業がクリエイターや出版者から多数の訴訟を提起されている
- 企業による情報への支配力が高まる傾向
- アーカイブプロジェクトが多方面からの攻撃に耐えられるか不透明
■ 8. ケール氏の提案
- 著作権法の再構築を提唱:
- 著者、出版者、書店が十分な報酬を得る
- 図書館の使命が尊重される
- 進歩が促進される
- 多くの勝者がいるゲームの実現を目指す
- 誰もが読者になるために多くの出版社、販売業者、書店、図書館が必要
免責事項: めんどくさいからほぼ調べずに書くし、抜けてる話や間違ってる話もあると思う。
■ まず日本語コミュニティの解散じゃなくてSUMO翻訳コミュニティの解散なのだがそれも少し違う
Mozilla系の日本語翻訳はmarsfさんとdskmoriさんの2人がメインでやってる。
概ねSUMOはdskmoriその他全てがmarsfという棲み分けだが、お互いどっちの貢献もやることがある。
コミュニティと言えるような規模は存在しない。限界集落。
SUMOコミュニティ解散ってのはSUMOに関わる実質的な権限持ちはdskmori１人になりますって話かな？
正直、SUMOでメインで貢献してるdskmoriさんじゃなくてmarsfさんが文句言うんや？と疑問なんだけど、
Mozillaにとっては、SUMOとかいう誰もアクセスしてない限界集落サイトの話より、marsfさんがFirefoxのその他すべての翻訳を一手で担ってることが重要だよね。
「marsfさんがSUMOの貢献辞める」って言ったってそれ自体ではどうでも良いのだが、裏の意味は「俺の気持ち次第でFirefoxの翻訳終わらすことだってできるんだぞ」って警告と読むべきかもしれない。
■ そもそもSUMOがなにか分かってない人多すぎ
SUMOはFirefoxのサポートサイトね。Firefoxの使い方に疑問が生じたときにみるところ。まあそういう用途で作られているというだけで、アクセスする人がいるのかいたって疑問だが。
想定読者は技術に疎いFirefoxユーザなので、「機械翻訳ならユーザーが自分でやるから不要」みたいな意見は全くナンセンス。
Firefoxの内蔵翻訳機能はプライバシー重視という建前の翻訳API破産防止のため、ローカルのCPUで動く設計になってる。必然的にMicrosoftやGoogleの翻訳より精度がかなり落ちる。ゆえにFirefox使って普通に英語版SUMO読むより、公式で精度よい機械翻訳提供したほうが、ずっと良い体験を提供できるよね。
また対抗をGoogle翻訳のような無料クラウド翻訳と考えるとしても、サポートサイトに特化するようファインチューニングした機械翻訳エンジンを使えばHelpを助けてと訳すような暴走も抑制できるから、これも公式による機械翻訳提供に優位性はある。
なお、統計上アドオン一切入れてないFirefoxユーザーが大多数なことからわかるように技術に疎いFirefoxユーザってかなり多いからね。
■ 勝手に上書きするな？ メンテできてないんだから当たり前
Firefoxはラピッドリリースで機能がコロコロ変わるので、ある時点でベストな翻訳になっててもすぐ時代遅れになる。
dskmoriさんなどができる範囲で貢献してたとはいえ、品質維持できる量ではなかったので、SUMOには、例えばすでに存在しない機能についての記述を含む記事が普通にあった。
これは比較的アクセスありそうな重要ページでも同じで、私もさすがに見かねて貢献したこともある。
Microsoftのプロ技術者向けサイトはもともと有償の翻訳者が訳してたのを機械翻訳に切り替えたのでこれは単純に劣化なのだが、SUMOについてはごく少数の素人が自分にできる範囲で訳していたという点を踏まえる必要がある。もともとクオリティが高かったとは言えないし、機械翻訳の精度もここ2,3年で異常に上がってるから過去の機械翻訳騒動をもとに騒ぐのが正しいとも思えない。
■ 限界OSS翻訳コミュニティの最後の１人が暴走するのは見覚えあるよね
今回の事件で思い出すのがLibreOffice日本語チームのDramaね。LibreOfficeの翻訳のメイン貢献者の某氏がある日、日本語チームのメーリスで「何でお前らはまともな仕事ができんのんや」と長文でブチ切れて、チーム脱退を宣言した事件。理念は立派でもすでに敗北の流れは決定的で新たな貢献者の望みは薄い、希望の見えないまま最後に残った１人として惰性で維持するしかない、辛い。
今回は、LibreOfficeの事件よりはヤバさだいぶ低めだけど、「翻訳ガイドラインに従っていない」「新たな人間の貢献者を育てることができない」とか、SUMOボランティア翻訳の実情を思えば「何言ってんだ、現実をみろよ」という感想にしかならないし、CCライセンスで貢献してるのに、AI翻訳の学習に使うなも意味不明。
marsfさんは、某xkcdで言うところの「感謝なしに2003年からデジタルインフラを維持してきたネブラスカ州の無名個人」に位置する人で、もっともっと感謝されてしかるべきではあるのだが、SUMOの長年の構造的な問題に対し抜本的な解決に打って出たMozillaに対して、さもコミュニティが現在も十分に機能しているかのように反論してるのがとても印象悪い。どう見ても分かってない人ばかりがMozillaを炎上させている。
20年感謝なしに維持し続けるのは幻想が必要なのはわかるが、Mozillaとしてはそういう個人に依存するのは不健全でしかないので、現在marsfさんがやっているFirefoxほぼすべての翻訳も翻訳会社による有償翻訳に移行すべき。
「Firefox」をはじめとしてMozilla製品のサポートページの日本語化に尽力してきたコミュニティ「SUMO Japanese community」が11月4日、活動の終了を宣言した。
Mozillaが10月22日、機械翻訳「Sumo Bot」を日本語記事に導入し、手作業で翻訳した記事をの上書き翻訳を無断で行っているため。コミュニティリーダーであるmarsf氏はこれが「私たちの作業の大量破壊」に当たるとし、コミュニティとしての活動終了を宣言した。
marsf氏によるとSumo Botの翻訳は、翻訳ガイドラインに従わず、日本語ユーザー向けのローカライズ表現を無視したまま既存の翻訳を上書き。300以上のナレッジベースが上書きされたという。
また、コミュニティへの連絡や合意がないまま製品版サーバで上書きしており、更新後72時間で自動承認されるため、新しい翻訳者に翻訳させ、チェックするといった育成の機会も奪っていると指摘している。
marsf氏はこれを「私たちの作業の大量破壊」と批判。個人として「support.mozilla.orgへの貢献を停止する」と宣言した。また、同氏の翻訳がSuMo BotやAIの学習データとして使用われることを拒否し、既に学習された私の翻訳データを削除することを要求している。
ただ、「日本の個々のコントリビューターが自分の責任において活動を続けることは自由」とも述べている。
■ 1. 設計・実装パターンを絞る理由
- 全体最適と局所最適:
- レビュイーは目の前のタスクの最速完了を重視
- レビュワーはプロジェクト全体の長期的な健全性を重視
- コードベース全体の一貫性維持:
- 新規メンバーの学習コスト削減
- 横断的な修正作業時の調査漏れリスク軽減
- 予測可能性の確保
- 開発者の設計余地の削減と均質化:
- 手法選択の迷いを排除しレビュー時の衝突を回避
- チーム成熟度が低い場合の誤った選択を防止
- プロジェクト遅延リスクの軽減
- ライブラリやサービス追加による管理コスト削減:
- 学習コスト、バージョンアップ、脆弱性対応の追加作業を抑制
- 引き継ぎやドキュメント作成の手間を最小化
■ 2. 統制のメリットとデメリット
- メリット:
- 品質の担保
- 認知負荷の低減
- 保守性の向上
- デメリット:
- モチベーション低下(特に若手)
- 開発速度の低下
- 変化への対応の遅れ
- 統制と裁量のバランスは状況に応じて変化し、プロジェクトフェーズで方針が変わることもある
■ 3. プロジェクト特性による統制レベルの違い
- 開発速度最優先の場合:
- 新規事業のプロダクト開発では自由度を高める
- セキュリティとコンプライアンスのみチェックし、腕利き開発者のセンスに任せる
- プロジェクト初期:
- 不確実性が高い段階では自由度を高める
- 成熟期:
- ユーザー増加と安定性重視の段階で統制を強化
- 保守運用を見据えた細かい処理方式の指摘を実施
■ 4. 開発ガイドラインの課題
- 後手に回る理由:
- ガイドラインを書いても読まれない傾向
- 記載量が多いと読解困難で記憶不可能
- メンテナンスコストの増大
- 実効性確保の方針:
- 現場感が強い内容のみを記載
- フォーマッターやリンターの整備が必須
- カスタムルールを適用するツールの開発
- AIレビュー導入により、ガイドライン記載内容を増やせる可能性がある
■ 5. 統制を強める基準
- チーム規模による判断:
- 5人程度: 阿吽の呼吸で運用可能
- 10-15人超: 統制が必要
- 15-50人: 専門家による統制
- 50-150人: 強いトップダウンのルールが不可欠
- 技術レベルによる判断:
- 小規模×熟練メンバー: 見守りモード
- 小規模×ジュニア中心: 指導・規範の整備
- 大規模×ジュニア中心: 統制を強める
- 大規模×熟練メンバー: 維持困難(メンバー入れ替わりは必然)
- 運用時の最も弱い体制を見据えた技術選定が必要
■ 6. アーキテクトの成長と価値創出
- 枯れた技術採用のジレンマ:
- 大規模案件ほど枯れた技術を採用しがち
- リスクを受け入れてモダンな技術にチャレンジする判断も必要
- 成長の楽しみの見出し方:
- 仕組み化によるプロジェクトライフサイクル全体の開発継続性確保
- 開発生産性技術セットの習得(CI/CDパイプライン、Git開発フロー)
- 実績を詰めれば大規模案件でもモダン技術を採用しやすくなり、ノウハウは小中規模案件にも還流する
■ 7. コミュニケーションと判断基準の明確化
- 判断基準と理由の伝達:
- 指摘とWhy(理由)をセットで伝える
- ADRや開発ガイドラインで設計決定を記録
- 後出しの場合は謝罪し、ルールが必要になった背景を説明
- 納得感と一貫性が信頼関係構築に不可欠
■ 8. 視座の違いによる技術選定
- プロジェクト視点:
- 所属プロジェクトの円滑な推進に注力
- 複数プロジェクト・部門視点:
- ノウハウ共有とメンバー流動性確保のため非差別化領域の標準化
- 全社視点:
- セキュリティ、コンプライアンス、人材育成コストの最適化
- 技術広報・採用広報との連動
- Webフレームワーク、DBアクセスライブラリ、ログライブラリなど利用頻度が高いライブラリは全社・部門レベルで統一することが望ましい
- アーキテクチャに個性は不要で妥当性が重要
■ 9. まとめ
- アーキテクトは短期的な開発速度と長期的な引き継ぎコストのジレンマでバランスを取る
- スイートスポットはチーム規模と技術力に依存し常に変化する
- 新技術導入時は全体を見通して既存修正や開発規約修正まで行うべきかを検討
- 現場の現実と全体最適の視点の両立が建設的な議論の前提
RISC-V（リスクファイブ）は、クリエイティブコモンズとして公開され、誰でも無料で利用可能なプロセッサの命令セットです。近年ではx86やArmに次ぐ命令セットとして注目度が高まっています。
RISC-Vを主導する団体RISC-V Internationalは、このRISC-Vの命令セットがISO/IEC JTC1による国際標準化の第一歩としてPAS（Publicly Available Specification）提出者の承認を受けたことを明らかにしました。
RISC-V Internationalは、RISC-Vの命令セットはすでに業界標準になっているとし、次のステップは公正な見地として信頼できる国際機関からの承認だとして、国際標準化機構（ISO）と国際電気標準会議（IEC）の合同技術委員会（JTC 1）による国際標準化へと進もうとしています。
今回、その第一歩として、JTC 1 PASの提出者の承認を受けたわけです。
国際標準化を重視する背景には、例えばIEEE 802.11で標準化されているWi-Fiのように、業界が合意した一連のルールとフォーマットとして標準化されることで複数のメーカーの異なる製品であっても確実に連携することが保証されるからだと説明されています。
これにより複数の製品の連携や統合が容易であり、コストが削減され、拡張と拡張が容易になるわけです。
また、命令セットが国際標準になった場合、その標準をサポートすると宣言した企業や組織は、ハードウェア製品などが標準を満たしていることを宣言できる利点もあるとしました。
そのため、RISC-V命令セットを国際標準にすることは相互運用性を促進し、オープンコンピューティングの将来の基盤としてのRISC-Vの役割を強固にするのだとRISC-V Internationalは説明しています。
■ 1. Ubuntu 26.04 LTSの全体的ビジョン
- ロンドンのCanonical本社で開催された「Ubuntu Summit 25.10」において、創設者兼CEOのMark Shuttleworth氏とエンジニアリング担当バイスプレジデントのJon Seager氏が次期長期サポートリリース「Ubuntu 26.04 LTS」(「Resolute Raccoon」)のビジョンと計画について説明した
- 重点領域: メモリー安全性を確保した基盤ユーティリティー、自動化の強化、コミュニティー中心のドキュメント、デスクトップとクラウド向けに最適化されたセキュリティ機能
■ 2. Shuttleworth氏のオープンソースへの信念
- Shuttleworth氏は自身がオープンソースの真の信奉者であると語った
- Canonicalの使命: ユーザーがあらゆる領域でオープンソースを利用できるようにする企業である
- 提供形態: クラウドでオープンソースを使いたいならクラウド向け製品を、小型デバイスで利用したいならそのような製品も提供する
■ 3. Linuxデスクトップの断片化問題
- Shuttleworth氏はデスクトップLinuxの断片化が深刻な問題であると認識している
- 「Linuxを真のグローバルな選択肢にしたいなら、実効性の高い取り組みを実施する必要があり、足を引っ張り合っている場合ではない」と述べた
- 皮肉なことに、失敗に終わったCanonicalのデスクトップ「Unity」への取り組みによって、同社の収益性がかつてないほど高まった
- 理由: その失敗のために、サーバー、クラウド、モノのインターネット(IoT)製品に注力せざるを得なくなったから
■ 4. Linuxデスクトップの可能性
- Shuttleworth氏はLinuxデスクトップの可能性を信じなくなったわけではない
- 「デスクトップにおけるオープンソースの勝利に貢献したい」と語った
- Ubuntu 26.04はデフォルトのデスクトップ環境として引き続き「GNOME」を採用している
- System76の評価: 米国のLinux PCメーカーであるSystem76と同社の新しい「Rust」ベースのデスクトップ「COSMIC」を高く評価しており、実際にSystem76はUbuntu SummitでCOSMICに関するセッションを開催した
- 課題認識: 「オープンソースコミュニティーは、エンジニアではない人向けのデスクトップの開発が別物であることを理解する必要がある。『シンプルできちんと機能する』ことも非常に重要であることを理解しなければならない」
■ 5. 開発方針の根本的見直し
- 2月にSeager氏が新任として、CanonicalとUbuntu開発チームによる今後の新しいUbuntu開発の方針を示した
- 目標: コミュニケーション、自動化、プロセス、モダナイゼーションに関するエンジニアリングの慣習を根本的に見直すこと
- Canonicalは2026年以降、ドキュメントとコミュニケーションのチャネルを統合することで、より透明性が高く理解しやすいコミュニティー主導のUbuntuビルドプロセスを確立し、新しいコントリビューターが参加しやすい体制を目指している
■ 6. コミュニケーション基盤の統合
- 「Ubuntu Community Matrix」サーバーをベースとする「Matrix」インスタントメッセージングが、Ubuntu開発者の主要なコミュニケーションシステムとなる
- Canonicalはユーザー向けと開発者向けのドキュメントの統合にも取り組んでいる
- Seager氏の認識: 「ドキュメントは重要なコミュニケーション手段」であり、二の次にすべきではない
- 現状の問題: 多くのドキュメントがさまざまなプラットフォームに分散し、内容の重複や矛盾があるほか、単純に見つけにくい場合がある
- 今後: 利用しやすく正確な形に統合される
■ 7. ビルドシステムの自動化とモダナイゼーション
- Canonicalはディストリビューションとパッケージの両方のビルドシステムの自動化に注力している
- 目標: エラーが発生しやすく退屈だが手間のかかるプロセスから、現代的な開発ツールを使用した高度な自動化システムへ移行する
- Seager氏の説明: 「可能な限り多くのプロセスを自動化する(それによって全体の能力を高める)だけでなく、プロセスをできるだけ簡素化することを目指す」
- 現状の課題: Ubuntuのビルドプロセスの多くは確かに自動化されているが、それらのシステムは統一されておらず、多くの場合、経験豊富なコントリビューター以外には分かりにくい
- 改善策: それらを一貫性のある開発パイプラインに統合することで、ビルドシステム全体が改善される
■ 8. Temporalの採用
- 同社は永続的なオーケストレーションを実現する「Temporal」などのツールを採用して、プロジェクトのワークフローの合理化やモダナイゼーションを進めている
- Seager氏の評価: 「Temporalは基本的に、分散システムエンジニアがいないUbuntu組織でも非常に複雑な分散システムを構築できるツールだと考えている」
- 目標: 十分に文書化されピアレビューを経たプロセスを活用して、ボトルネックと属人的な知識への過度な依存を軽減することで、コントリビューターが活躍できる環境を整え、規模の拡大に対応する
■ 9. Rust言語の採用によるメモリー安全性の向上
- Ubuntuはメモリー安全性の高いRust言語を採用している
- エンジニアリングチームはUbuntu 25.10から、主要なシステムコンポーネントをRustベースのコンポーネントに置き換えて、安全性とレジリエンスの向上に力を入れている
- Seager氏の強調点: 性能だけでなく、レジリエンスとメモリー安全性が主な推進力である。「Rustへの移植によってレジリエンスと安全性の向上を簡単に実現できる。私が最も魅力を感じるのはこの点だ」
- sudo-rsの採用: Ubuntuは「sudo」のRust実装である「sudo-rs」を採用しており、フォールバックとオプトアウトの仕組みがあり、従来のsudoコマンドも使用できるようになっている
■ 10. uutils/coreutilsの採用
- Ubuntu 26.04では、sudo-rsに加えて、LinuxのデフォルトのコアユーティリティーとしてRustベースの「uutils/coreutils」が採用される
- 内容: ls、cp、mvなど、多数の基本的なUNIXコマンドラインツールが含まれる
- 狙い: このRust再実装の狙いは「GNU coreutils」と同等の機能を実現しつつ、安全性と保守性の向上を図ること
■ 11. TPMによるフルディスク暗号化
- デスクトップ関連の変化として、Ubuntu 26.04で「Trusted Platform Module」(TPM)によるシームレスなフルディスク暗号化が導入される
- この機能は「Windows」の「BitLocker」や「macOS」の「FileVault」に相当するものである
■ 12. Snapアプリケーションのpermissions prompting
- Ubuntu 26.04では、「Snap」ベースのアプリケーションに「permissions prompting」が搭載される
- これはデスクトップアプリ向けのきめ細かな権限管理フレームワークである
- 目的: コンテナー型の強力なセキュリティと、ユーザー主導による事前の承認を組み合わせる
- 現状の問題: Snapの機能の1つにサンドボックスがあるが、使っていてイライラすることもある。何かを実行しようとしてサンドボックスにブロックされると、アプリがクラッシュする場合や本来の処理が実行されない場合がある
- 改善内容: プロンプトに「Firefoxがダウンロードディレクトリーへのアクセスを求めています。許可しますか」といった内容が表示されるようになる
- 開発状況: このフレームワークはまだ完成していない。この取り組みでは「カーネル、『AppArmor』(Linuxのセキュリティプログラム)、Snap、デスクトップクライアントに至るまで、非常に大掛かりな作業」が必要である
- 見通し: 全てが順調に進めば、Ubuntu 26.04のリリースまでにはpermissions promptingが完成している
■ 13. 最新コンポーネントの採用方針
- Ubuntu 26.04では再び「最新バージョンのGNOME(おそらく『GNOME 48』)と最新のカーネル」を採用し、最新のベースコンポーネントを提供するという伝統を踏襲する
- この方針のために、LTS版ではないLinuxカーネルをサポートする必要が生じたとしても、Canonicalはそうする
■ 14. Flutterベースアプリの拡大
- 新しいUbuntuでは、より多くの「Flutter」ベースアプリが使われることになる
- Flutterはオープンソースのプログラミング言語「Dart」を使用するGoogleのプラットフォームである
- 利点: 開発者はFlutterを使用することで、ほぼ全てのプラットフォーム向けのマルチOSアプリを1つのコードベースから作成できる
- Ubuntu 26.04での適用範囲: この機能にUbuntuのアプリストア、インストーラー、「セキュリティセンター」が含まれる
スタンフォード大学とAnthropicが、AIの安全機能は簡単に無力化できることが証明する論文を発表しました。
最大99%の成功率でAIを操り、有害な応答を引き出す手法です。
僕も実際に試しましたが、かなり簡単です。
ということで、この巧妙な手口と衝撃的な結果をまとめました。
1. 巧妙な手口 まず無害だが絶対に解けない問題と長大な推論をAIに与え、最後に有害な指示を付け加えるだけ。AIの注意を無害な部分に集中させ、本来の危険な指示に対する安全機能を弱体化させます。
2. メカニズム 長い推論の連鎖は、AIの安全強度を担う中間層と、最終決定を行う後方層の機能を鈍らせることが判明。AIの「注意力」が前段の無害なタスクに割かれることで、後段の有害な指示に対する警戒が薄れ、拒否反応が著しく低下します。
3. 驚異的な成功率 実験結果は衝撃的です。ある公開モデルでは、短い推論での攻撃成功率27%に対し、長い推論では約80%に急増。様々な最先端AIシステム全体で見ると、この手法は最大で99%の成功率を達成しました。
4. 結論 AIの推論能力の向上は、精度を高める一方で、意図せずして強力な「抜け穴」を生み出してしまいました。AIの賢さが、皮肉にもその安全性を脅かすという、新たな課題が浮き彫りになっています。
■ 1. 記事の目的と対象
- ValueObjectの不変性にフォーカスし、アンチパターンを提示した後、本来あるべき姿の例を記載する
- 対象: アプリケーションエンジニア、DDDに取り組んでいる人・取り組みたい人
- Vladimir Khorikov氏の言葉: 「ValueObjectを不変にできない場合は、それはValueObjectではない」
■ 2. ValueObjectとEntityの違い
- Entity: 可変・同一性を持つ(ライフサイクルを持つ)
- ValueObject: 不変・同一性を持たない(ライフサイクルを持たない)
- 同一性の例: 人物は20年経っても同じ人物として探すことができる(Entity)。名前や趣味は変わることがある(ValueObject)
■ 3. 比較(評価)の違い
- オブジェクトの評価方法には三種類ある:
- Reference equality: 参照の等価性
- Identifier equality: 識別子の等価性
- Structural equality: 構造的等価性
- EntityはユニークなIDで比較を行う(Identifier equality)
- ValueObjectは構造で比較を行う(Structural equality)
- Entity: 記憶という識別子を元に本人かどうかを評価する
- ValueObject: 名前(文字列)での構造的評価を行うため、ヒットしたアカウントが複数の場合もある
■ 4. アンチパターン1: 単なる型定義
- この実装では型でドメインを表現できていると満足しているが、userIDもEmailもドメインの不変性という責務を果たせていない
- ValueObjectの核心的な責務は「ドメインの不変条件(invariant)を保証し、カプセル化すること」である
■ 5. 型定義だけの実装がアンチパターンな理由1: カプセル化の欠如
- Goの場合、型変換によってバリデーションを簡単にバイパスできる
- ファクトリ関数(コンストラクタ)を用意しても、パッケージ外から型変換で不正な値を強制的に作れてしまう
- アプリケーション全体でEmail型の値が常に「有効なメールアドレスである」ことを保証できない
- 他のパッケージから不正なメールアドレスのオブジェクトをインスタンス化できてしまう
■ 6. 型定義だけの実装がアンチパターンな理由2: ドメインの知識(振る舞い)の欠如
type Email stringの定義では、その型はstringとほぼ同等の能力(stringへの型変換が容易)しか持たない- ValueObjectは単なる「バリデーション済みの値」ではなく、その値に関連する「ドメイン固有の振る舞い(ロジック)」もカプセル化する責務を持つ
- 例: 「Emailアドレスからドメイン部分だけを取得したい」というドメインの要件があった際、現状の設計であれば実装がアプリケーション層に記載されることになる
- 「Emailのドメインパートのみを取得する」といったオブジェクトの振る舞いは関心の分離を行う対象であり、アプリケーション層ではなくドメイン層で設計・コーディングすることがオーソドックスなスタイルである
■ 7. 正しい実装: カプセル化と不変性を強制
- 構造体としてValueObjectを表現し、値と振る舞いの両方をカプセル化する
■ 8. アンチパターン2: 不変性の欠如
- ValueObjectがポインタレシーバを持つ場合、「値が変更可能であることを示唆する」表現となるため、不変性を破壊しかねない
- 基本的に不変なものは値レシーバが推奨される
■ 9. 実装のポイント
- ValueObjectを構造体として表現し、構造体が持つ値への参照を非公開(value)にしてgetter経由でしか参照させないようにすることで、パッケージ外からの型変換や直接的なフィールド代入を防ぐ
- インスタンス化をNewEmailに強制し、バリデーションを担保する
- ValueObjectの関数は値レシーバとし、不変性を明確にする
■ 10. まとめ
- 「ただの型定義」は、ドメインルールを強制できない「なんちゃってValueObject」である
- 不変性が必要な場面ではカプセル化を徹底し、ドメインルールを守らないオブジェクトの生成を許さないような設計を心がける必要がある
- ファクトリー関数を通して、ドメインルールが守られたインスタンスが生成される
- そうすることで初めて、ValueObjectは「意味のある」存在となる
- 結論: 「ValueObject導入するなら、値も振る舞いもカプセル化してくれ」
まぁ、幻想じゃないね w
才能がないと思ったら、早いうちに河岸を変えた方がいい。
早ければ早い方がいい。
可哀想だから(教え子が？ それとも自分が？ w)、って「がんばれ、がんばれ。才能なんて関係ない」みたいに騙すのは、むしろ害悪だよ。
10年後、気付いて路頭に迷わせるとして、その責任は取れるのか？
引導を渡すこともプロの責任。
まぁ、本人自身が気づいて路頭に迷いつつあるけどどうしようもないのかもしれんが、地獄に道連れはやめてやれ w
小説家、役者、声優、バンドマン etc.etc.
それで生計を立てない、趣味の範囲で楽しむ分には好きにすればいいけど、エンジニアに限らず、それなりのお金をもらおうとしたら、才能、向き不向きは超えられない壁として現実に、強固に存在している。
球速120km出ないけど阪神の一軍のピッチャーに、ってのはどう逆立ちしても物理的に不可能だ。
でも草野球は楽しめる。
才能がなけりゃ、一人で永遠に「大いなる助走」を続けりゃいい。
誰にも迷惑かけないなら。
医師、看護師、会計士、経営者、etc.etc. にも、才能、向き不向きはある。
おいらには、医師とか、警官とか、無理だねぇ。
落ち着きないし。
同じことを何日も続けたら、爆発する。
「明日も同じことしなきゃならないのか……」って考えただけでも、死にたくなる。
こんな感じに、才能がものをいう分野って、意外に多い。
ソフトウェアエンジニアは、設計実装の抽象度が多層化していて、その巧拙によって安定度、運用や機動的な新機能追加の手間、リードタイム、金や何やら、数十倍、規模複雑度が爆上がりしている今なら下手すりゃ数百倍差が出る。
その差をちゃんと理解するには、巧の現場の「こういう世界があるんやー……」って実体験が必要だったり、巧レベルの才能が必要だったり、経営知識が必要だったり、経済知識も必要だったりして、「拙」の現場にぶら下がってるだけのエンジニアが「才能なんて幻想」って吠えたっても「マジ、迷惑だからやめてね」って思う。
どの炎上現場でも、高粘度現場(リーダーマネージャが理解できないからって邪魔ばっかりしてきたり、そもそもプロダクトがぐっちゃぐちゃになってたりして、どんな行為がサービスの息の根を止めるかわからなくて身動きが取れない「震える舌」みたいな現場。物事が全然進まない現場。通常、経費で札束ガンガン燃やしてるはずだから、ここも炎上現場っていう)でも、この手のエンジニアが腐るほどぶら下がってるんだよね。
たいてい、生み出されるソースコードとドキュメントの割合がおかしなことになってる。
会議だ勉強会だなんだばっかりしてる。
いや、そういうの主催してる暇があったら、コード書けよ、って。
でも、Web記事引いてきて、「〇〇にはこう書いてある」とかドヤ顔で机上の空論で時間潰して「俺も一端の理論派エンジニアだぜ……」とか、いや、お前はただの受け売りを理解もせず垂れ流してるだけのそこらへんの AI と変わらんクズだよ。
おいらの師匠の一人は「TV出たり、本書いたりするやつは二流。一流は、自分の仕事に集中していて、他のことやる暇ないから」って言ってたけど、ほんとその通りだと思うよ。
シャバと違い、ソフトウェアの世界は驚くほどのスピードで巨大化、複雑化している。
30年、40年前なら、社会性の乏しい、プログラミングコンテスト受賞者みたいなエンジニアでも無双できたけど、今は無理なんだよね。
今だと玉拾いも任せられないくらいだったりする。
余計な部分最適化かまして、地雷埋設に邁進しちゃうから。
ちょい前も、PostgreSQLの中身いじれます！ って東大卒業生いたけど、視点が局所的すぎて全体感に欠けてて、プロジェクトがヤバい状態になってるのが理解できなかったりしてたからね。
そろそろリリースできる状態になってる予定だけど、おいらの読み通りα版完成が3ヶ月遅れ、そこで大量の不具合が発覚してベータ版完成がそこからさらに3ヶ月以上遅れ、不具合積み残したまま見切り発車、ってなるんじゃねーかな、と思ってるんだが w
才能の種類、方向性によっては、10年前も今もたぶん10年後も変わらず十分通用するものはあるんだけどねー。
エンジニアの年収は他の一般の職業に比べて高い。
そこに生活水準をあげてしまうと、自分はもう通用しないと気づいても、撤退できない。
マイカーガー。
マイホームガー。
子供ガー。
愛犬ガー。
んなもん知るかっ！
さっさと色んな意味でFireしろっ！！
そういう「元エンジニア」がリーダーとかマネージャとかにクラスチェンジして、事業、プロダクトの足を引っ張る。
マジでこの手の「元エンジニア」が、今、業界に溢れてる。
あそことか、そことか、具体的な企業名はあげられないけど、そういうエンジニアが漬物石のように重しになって、身動きが取れなくなってるところが多い。
VCとかから、もっと売り上げを上げろ。成長率を上げろ、というプレッシャーを与えられ、何かしなきゃいけない。ってなって、外付けの雰囲気だけのサービスをどんどん外付けしていく戦略を取る。
1年で10。
2年で30とか。
マジかよ w
思い思い行き当たりばったりに作ったら、手間だけ増えてそれを壊すわけにはいかなくなって、さらに身動きが取れなくなっていく悪循環しか見えないんだが、そんな経営方針で大丈夫か？
とりあえず認証認可から共通化していくしかない。
とか意味不明な決定して、認証認可v1、認証認可v2、認証認可v3とマイクロサービスが増殖して、さらにv4を企画してるとかいう会社だってある。
真っ当な声には、自分の存在感を示すためだけの反対を唱えて邪魔したりして、現場で手を動かしているエンジニアより高級を取ってんのに、事業、プロダクトへ与えるダメージは倍増する。
さらに、自分の地位を死守するために、それを脅かす腕利のエンジニアを陥れる、排除することに全力を傾ける。
これで3倍界王拳だ w
経営者はできるエンジニアたちに任せていると思い込んでいるかもしれないが、さて、どうかね？ w
大本営発表的にはうまくいっているとされているサービスが、その裏側はカーオブファイヤーみたいなところって、結構ある。
というか、そっちの方が多いんじゃないか？ ポチョムキン村。
はっきりいう。
ソフトウェアエンジニアは、アスリート的な仕事だ。
おいらは土日祝もシステム関係の勉強とか研究をしてる。
今はクラウド環境のプロダクトで、どのように自動テストで検証可能なシステムを構築するかの手法の研究を続けてる。
具体的には、今まで関わってきた炎上現場で安定稼働を達成させた手法(TDD)だな。
ワークライフバランス？ w
そんな寝言、やめてから言えよ www
才能のない人は河岸変えろ。
むしろ若手を潰してるって自覚持て。
に反論してくるのが結構いる。
あのサービスとこのサービスとそのサービスを使ってます。
業務経歴書にも今まで使ったことがあるサービスの名前をたくさんたくさん載せてます。
僕の技術力は世界一ぃぃぃっ！！！
じゃねーよ。
ボルトに世界水泳、吉田沙保里にNBAに出場させるような使い方してて、どこが技術力だよ。
ってのが多い。
「どうしてこのAurora、リーダーがこんなにたくさんぶら下がってんの？」
「テナントが増えて、アクセスが増えたので、負荷分散のために増やしました。水平スケーリングってやつです」
うん。水平スケーリングは知ってんねん。この程度のテナント数、ユーザー数、アクセス数で、どうしてこんなにでかいインスタンスのリーダーがぶら下がってんのか？ って聞いてんねんけど……。
って現場、多い。
というか、そういう現場しか知らん w
まぁ、炎上現場巡りしてたし。
でも、今通常営業してるサービスでも、こういうところ多いんだよな。
それはともかく、
「マイクロサービス化していて、いま120を超えたところで、当面160になります」
「……は？」
「うちのサービス、ドメイン多いんで」
「……デプロイの時、どうすんの？」
「変更があるサービス名を書いたファイルを一緒にコミットして、それ読み込んで、GitHubActionsでデプロイさせてます」
「……ローカルの開発環境構築は？」
「Cloneして立ち上げます」
「これ……、モノリポ？」
「もちろんです。Googleもそうやってますし」
「120個？」
「120個」
「なんか立ち上がらないんだけど……」
「あ、修正中なんで、〇〇と××のコミットをチェリーピックしてください」
「……動かないぞ」
「昨日の夕方、変更が入ったみたいなんで、△△のコミットもチェリーピック。いや、＋＋のブランチを……」
5日で立ち上げ切れるんか？
って現場がね、案外たくさんあるんだ。
で、「マイクロサービス、使えないっすね」
「ほう……？」
「連携が取りづらくて、障害発生しまくって」
どうして「自分が間違えてる」「自分が見当外れなことをしている」可能性ってのを考慮しないんだろう、この人らは？
っていつも思う。
マイクロサービスの目的も前提も理解しないで、HowToだけ猿のように繰り返してるって自覚ないんか…… (-_-)
「だって、オライリー本のここにこう書いてあるから！」
ってマーカーで引いた一文見せつけられるんだが、その前に書かれてある前提とか目的とか、書かれてない暗黙のそれとか、いわゆるコンテキスト削ぎ落として、単語レベルの理解を開陳されても、「は？」としか反応できんのよな。
120のマイクロサービスとか、お前、認知科学の知識もないねんな……。
それマイクロサービスじゃなく、「粉砕されたモノリシックサービス」っていうんやで、と。
まーじで、技術本とかの恣意的なつまみ食いで訳分からん理論構築すんなよ。
それでプロダクトがうまく回ってなかったら、それが答えなんよ。
まぁ、「うまく回ってる状態」ってのを知らない、理解できないだろうから、正しい答えに行きつかんだろうけど。
その正しい答えに行きつかない、ってのを
「致命的な才能の欠如」
って呼ぶんよ。
サリエリくらい才能があったら、自分の才能が足りんことを自覚できるんだがな。
脳外科医竹田君みたいなエンジニアは、即刻足を洗って欲しい。
■ 1. 画像生成AIの現状認識(2022年から2025年の変化)
- 2022年時点では画像生成AIの存在が認知され始めた段階だったが、2025年現在では小学生や高齢者も普通に使いこなしている
- 当時から「明るい未来はあまりない」と予測していたが、実際にイラストレーターの仕事は奪われつつある現実となった
- イラストの単価が3分の1になっているとの報告もある
- 生成AIに対する抵抗運動(訴訟、ボイコット、ネガティブキャンペーン、プロテクト技術の使用など)が展開されているが、大局的には勝ち目がない
■ 2. AIによる学習と著作権問題の本質
- 流行している絵の描き方パターンをAIに学習させて発表する行為は、人間の絵描きや漫画家が昔から行ってきたことと本質的に同じである
- 漫画家は現在も活動している漫画家の作品パターンを頭の中で混ぜて創作しているため、AIがそれを行うことを非難するのは矛盾している
- オリジナリティとは混ぜ方の中に自分が生きているかどうかの問題である
- 自分が苦労して編み出した表現をAIに盗まれるという感情は理解できるが、この論法では勝ち目がない
■ 3. イラスト業界の段階的淘汰
- 第一段階(過去3年間): イラスト屋などの無料配布により、地方自治体や小規模商店向けに仕事をしていた町のイラストレーターが淘汰された
- 第二段階(今後): 超メジャーではない中堅イラストレーターの仕事が奪われる
- 超メジャーなクリエイター(鳥山明、大友克洋、尾田栄一郎など)のみが「その人が描いてくれただけで価値がある」という理由で生き残る
■ 4. アニメーション制作の変革
- アニメの作画は無人化が進む
- 演出家は見せたいカットを人間に発注し、流してよいカットをAIに発注するという使い分けを行う
- AIは書き込みが多く影が複雑な動きに向いており、人間のアニメーターに負担をかけていた作業を担当する
- 結果としてアニメーションのクオリティは向上し制作コストは下がるが、動画マンは職を失う可能性が高い
- 原画マンは生き残る可能性があるが、動画マンの将来は厳しい
■ 5. 漫画制作へのAI浸透
- コマ割りや見開きの見せ方などの漫画文法もAIのディープラーニング対象となる
- 漫画が量産されるほどデータが蓄積され、AIによる自動生成が可能になる
- 数年以内に可能になることは明らかである
- 話し言葉のコンテンツを数秒後に漫画化したり、ゆっくり解説動画にする技術が実現する
■ 6. YouTuberとコンテンツクリエイターの未来
- あらゆるYouTuberがほとんど失業する未来がある程度見えており、その中間段階が進行している
- 切り取り動画の制作(過去の発言と現在の発言を混ぜて面白くする作業)すらAIができるようになる
- キャラクターとしての価値が重要になり、本人が話すことよりもキャラクターが話しそうなことをAIが生成する方が面白くなる
- 数十万人が考えたキャラクターらしい発言の方が、現実の本人の発言より面白くなるのは時代の必然である
- これはシンギュラリティではなく失業ポイントに向けて進んでいる過程である
■ 7. 新しい仕掛けと失業の連鎖
- ニコニコ生放送などの新しい仕掛けによって多くの人が失業してきた
- その屍の上に現在の成功者が乗っかって商売をしている
- この構造もいずれ崩れていくのは当たり前である
- 恐ろしい未来ではなく、そうなったら次の面白いことを考えるだけである
■ 8. 生き残るクリエイターの条件
- 超優秀なアニメーター、漫画家、絵師は生き残る
- しかし大半の漫画家は職業として成立しなくなる
- アシスタントも同様に厳しい状況に直面する
■ 9. 変化の時間軸予測
- 3年程度で大きな変化が目に見えるようになる
- 食える食えないという最終的な変化には10年程度かかる
- 中間的なポジションにいるクリエイターが本当に危機に直面するまでには5年から10年かかる
- この予測は先取りしすぎているため多くの人は実感できず疑問視するが、5年後10年後には確実に実現する
- 「そうなるべきではない」と考えているとずれてしまうため、時代はそういうものだと認識すべきである
■ 10. 発注型仕事の消滅
- 誰かからお金をもらって発注を受けリクエスト通りに制作する仕事は失われ続ける
- 観光地の似顔絵やディズニーランドのシルエット切り絵のようなサービスは、2000円~3000円の技術料が必要だが、無料で類似のものができる状況では生き残れない
- 超メジャーなネームバリューのある人以外は生き残れない
■ 11. アートから手芸への移行
- 人類に残されたのは自分にしかできない、自分が手を動かして作った趣味をめでるという方向性である
- 現在の手芸ブームはこの流れを反映している
- アートや作品としてではなく、趣味としての手芸として素晴らしいという価値観に流れている
- アートはAIに奪われているため、人間は自分が本当に手を動かして作ったものを愛でる方向に向かっている
■ 12. 現状追認と説得の意図
- この発言は現状追認ではなく、現状を認められない人を説得しようとしている
- 「AIはダメだ」「人間にしかできないクリエイティビティがある」と言う方が、人前で話をする立場としては商売になる
- それを理解しながらも、こだわり続けると苦しいという助言をしてしまう
- カメラに向かって話をする活動自体も、あと何年何ヶ月続けられるか分からない
■ 13. 自動化の波及と共通の運命
- 来月は無理でも来年、再来年には話す内容の自動化が見えてきている
- 全員が同じタイタニック号に乗っている状況である
- 逃げる先は新しい稼ぎ先ではなく手芸のようなものしかない
- この問題に対する明確な解決策は見出せていない
■ 1. 現状の課題
- AIアプリエンジニアが急増している:
- 生成AI(LLM)が普及し誰でも比較的容易に活用できるようになったことが大きな要因である
- しかし実際のところAIそのものへの理解や理論的な知識を持たずに開発しているケースも少なくない
- OpenAI APIを使える、LangChainを組めるといったツールとしてのスキルはあってもAIの挙動や構造を理解したうえで設計している人は限られている
- コードは書けるのに結果が出ないケースをよく見る:
- ノーコード/ローコーディングツールの普及によって誰でも短期間でMVP(最小実行可能プロダクト)を作れるようになった
- しかし現場レベルで実際に運用・定着するプロダクトになるケースは非常に少ない
- 一見動くものを作ることはできても使える・価値を生むレベルまで育てるのが難しい
- 社外にPRされているAI事例の中にも実際には一部組織内だけの限定的活用にとどまっているものも少なくない
■ 2. 何が起きているのか
- ノーコード/サンプルコードの充実によってAIアプリを短期間で作ること自体は簡単になった
- ローコーディングという神ツールも登場し、従来時間のかかっていたコーディング時間は半減し確実にMVPを作るまでは早くなった
- ただし動く状態から使える状態に引き上げるにはきめ細かなチューニングとAIの仕組みへの理解が不可欠である
- このチューニングにはモデル構造やプロンプト設計、データセット設計の知識が求められる
- しかしAIをブラックボックスとして扱っているとどこを調整すればよいか判断できない
- 結果としてAPIを呼び出すだけの構成にとどまり、課題を根本的に解決できないまま止まってしまうことが多い
- 具体例:
- ベクトルDBをとりあえず繋いでいる、プロンプトを変えてみるだけといった状態で止まっている例をよく見かける
- 特にプロンプトを変えてみるだけはすごく多いパターンである
- RAGであればそもそも構造的にプロンプトチューニングの限界があるから仕組み的にリトリーバーの改善を、リトリーバーを変えたということはベクトルDBのメタデータをといったような思考プロセスを持ち合わせる人が少ない
- 技術的にリーチングアウトできるエンジニアは非常に少数である
■ 3. なぜそうなるのか
- LLMのような生成AIに何でも神頼み:
- 生成AIの進化によってLLMに任せればなんでもできる、マルチモーダル=すごいという空気感が広がった
- しかし現場業務のような特定のタスクに特化したアプリケーションを作るほど実は汎用的なLLMだけでは十分に対応できることはかなり少ない
- モデルの限界や誤答特性を理解し適切な技術や設計を組み合わせていく地道な調整が必要である
- 成果物重視・SaaS依存構成による原理の理解の欠落:
- 事業会社ではスピードが求められたり予算に限りがあったりするため、SaaSや既存APIを組み合わせて素早く成果物を出す傾向がある
- ただしそれが積み重なるとバックエンドではAPIを叩いているだけになりAIそのものへの理解を深める機会が減ってしまう
- もちろんSaaSの進化が早いので追いつけないこともある
- 成果物を優先する判断は正しい場面も多いが理解の機会を意識的に確保することが必要である
- 評価基準が曖昧になり"すごいっぽいデモ"で終わる:
- デモは盛り上がったけど実務では使われないというパターンも非常に多い
- 原因は明確で定量的な評価指標やデータセット設計の知見が不足しているからである
- AIアプリを改善するにはなぜこの出力が良いのか/悪いのかを測れる指標が欠かせない
- 評価手法を持つことはエンジニアとしてだけでなくプロジェクトの信頼性を担保するビジネススキルにも直結している(相手を説得しやすいのは数値であるため)
■ 4. 本当に有用なAIアプリを作るために必要な理解
- 基礎的な基礎:
- 例えばLLMの出力は確率的であり設定や入力次第で大きく変化する
- RAGであればキーワード検索はBM25の頻度計算をベースにといったような理解が必要である
- ベースの技術を理解できていればうまく行かない時のチューニングの方針や次のアクションを早く決めることができる
- アジャイル開発であれば次のスプリントのバックログを事前に計画できるのでプロジェクトとして計画的に進めることもできる
- 評価軸(正確さ・再現性・効率性など)を明確にする:
- すごいではなく安定して成果が出る状態を目指すために評価指標を定義し可視化すること(=見える化)が重要である
- 小さく検証→定量化→改善というループを設計する:
- 大きなアプリを一気に作るのではなく検証サイクルを短く回す
- この地道なプロセスが結果的に品質を押し上げる
- そういった進め方をクライアントもしくは現場と綿密に擦り合わせることも大事である
■ 5. AI時代のエンジニアに求められる姿勢
- AIアプリエンジニアが数多く登場し社内外でAI活用が広がる中で、いまようやく本当の課題はクオリティだと気づき始めているのではないか
- AIに対する理解を深め使えるレベルまで磨き上げる姿勢がこれからのエンジニアには求められる
- AIを使える人は増えた
- しかしAIを理解して活かせる人こそがこれからの時代に強い
■ 1. type という命名を避けるべき理由
- type やそのサフィックスを持つ名前(_type など)を変数、構造体・クラスのメンバー、データベースのカラムなどに付けてしまうことがしばしばあるが、あまりやらない方が良い
- 理由1(予約語との衝突):
- type はいくつかのプログラミング言語において予約語になっており、そのセマンティクスにおいて特別な役割を果たすことが多い
- 理由2(フレームワークとの衝突):
- Ruby on RailsにおいてはDelegated Typesという機能において_type というカラムは特別な意味を持つ
- もちろんアプリケーションコード側でDelegated Typesであるという宣言をしなければ副作用は無い
- その他のフレームワークに似たようなものがあるのかは不明である
- こういった概念との衝突を避けるために特別かつ強い理由が無い限りは type という命名は避けるという方針
■ 2. 代替案
- 代替としては kind や method などが使えそうである
- これらを採用することが多い
- method は別の概念との衝突がある場合もありそうだが、そこは文脈に沿って対応する
■ 3. 例外的にtypeを使用する場合
- どうしても type でしか表現できないものはあると思われる
- 例えば言語処理系を作っていて本当に「型」を取り扱う必要がある場合などである
- そういった場合は頑張る必要がある
■ 1. マネージャーの価値とタスク遅れ対処
- タスク遅れ解決のための手札をどれだけ持っているかがマネージャーの価値である
- タスク遅れは必ず発生するものであり、必ず対処しなければならない
- タスク遅れに対してどんな手を打てるかは組織次第、状況次第で変わる
- タスク遅れ解決のための手札をなるべく増やすように、普段から立ち回りを意識することが重要である
■ 2. タスク遅れが必ず発生する理由
- 工期の見積もりはあくまで見積もりでしかなく、完璧な見積もりは絵に描いた餅である
- プロジェクト遂行中のトラブル:
- エスパーでないと予知できないトラブルが発生する
- メンバーが体調を崩したりサボることもある
- タスクが難しすぎたり、依存関係が複雑過ぎて手がつけられないこともある
- タスクごとにリスクを計ってマージンを作るが、存在するマージンは基本的に全て食い潰されるため、大抵それ以上にタスクは遅れる
■ 3. タスク遅れに対する手札の三つの分類
- 人的リソースでなんとかする:
- やる人の手を増やしたり、費やす時間を増やすことで対処する方法である
- 残業時間を増やす、対応メンバーを追加する、誰かに手伝ってもらう、出来る人を連れてきてもらうなどが含まれる
- 一番分かりやすいが故にマネージャーにとっては安易に頼ってしまいがちな方法である
- 頑張るしか手札を持っていない人である場合、時々悲劇が発生することもある
- 人的リソース以外の手札を何枚持っているかがマネージャーの有能さを示す一つの指標である
- 調整でなんとかする:
- 他の担当チームやクライアントと相談してスケジュールを延ばしてもらう、実装する機能のスコープを見直してタスク自体をスケールダウンする、機能を簡易化してタスクの難易度を下げる、上にエスカレーションするなどが含まれる
- 人的リソースでなんとかするよりもマネージャーにとっての難易度は高い傾向がある
- 組織によっても仕事の質によってもどれだけの選択肢がとれるかは変わる
- タスク遅れと言われた場合、この辺の選択肢がマネージャーに期待される部分は大きい
- プロセスをなんとかする:
- レビューや事務手続きで時間を食い過ぎている場合、リスクをとったり簡略化してプロセスを改善する、メールのやり取りで時間を食っている場合は拠点を移して対面で話せるようにするなどが含まれる
- 開発手法を変更する、ツールでテストを自動化する、作業を分割して開発を並列化する、クリティカルパスの見直しや後工程を前倒しで始めることで全体としての遅れを吸収するなどの方法もある
- 遅れが顕在化してからよりも普段からの準備が重要である
- 一般的には三つの中で一番難易度が高いケースが多い
- マネージャーにとっては腕の見せ所である
- 下手にプロセスをいじると逆効果になることもある
■ 4. マネージャーが把握すべき三つの観点
- マネージャーとしての自分はタスク遅れの対応策を幾つ知っているか
- そのうち現在の環境、現在のプロジェクトで実際に取り得る対応策はどれか
- そのうち最も効果的でなるべくコストを低減できる対応策はどれか
■ 5. 環境による制約と手札の確保
- タスク遅れの対応策は環境、仕事の種類によって選択できるものが変わる
- クライアントとの関係次第ではスケジュールの調整ができないかもしれない
- 品質は絶対厳守でテスト工数は絶対に減らせないかもしれない
- 有識者を連れてこようにも他チームも全部炎上しているかもしれない
- 頑張る以外の手札をどれだけ用意できるか、調整とプロセスからそれぞれ二枚、三枚の手札を選択できるだけの余地を確保できているかが重要である
■ 6. 普段からの立ち回りの重要性
- 常に使い得る手札を把握しておき、できることならその枚数を増やせるように立ち回っておくことがマネージャーとして非常に重要である
- 事前準備の具体例:
- 常日頃から他チームといい関係を築いておき、いざという時にはヘルプを求められるよう恩も売っておく
- スコープの見直しの可能性やリスクについて事前にクライアントと調整しておき、いざという時は切り捨てても良い機能や品質の落とし所について確認しておく
- リスク計画はプロジェクトの立ち上げ時点で個別に考えておくべきテーマであるが、普段からの立ち回りで事前準備が必要な部分でもある
- タスク遅れという分かりやすいピンチでどういう手札を持っているかはマネージャーとしての一番の価値である
- 手札を増やす努力自体が会社での自分の立ち位置を向上させていくための努力とほぼイコールになる
■ 7. 具体的な解決事例
- 新人マネージャーが一つの開発環境内で全部解決しようとして色々引っかかっていた
- もう一つ環境を作ってそのリソースを使えば解決できるというアドバイスで解決に向かった
- 解決できそうな人に事前に渡りをつけておくこともマネージャーとしての価値を高めるための一つの方法である