■ Whyがないと起こる問題:
過剰対応のリスク: 必要以上の機能を追加してしまう。
不適切な解決策: 根本的な問題解決につながらない。
機会損失: 別のより良い解決策を見逃す。
■ 具体的な例:
飲食店の「カレーを辛くしてほしい」という要望。Whyが「インフルエンサーのため」と分かれば、「辛さ調整トッピング」といったより価値のある解決策が生まれる。
プロダクト開発の例として、「ユーザー一覧のCSVダウンロード」や「ユーザー削除機能」。Whyを掘り下げることで、別の機能で代替可能だったり、「削除」ではなく「無効化」が適切な解決策であったりする可能性がわかる。
■ Whyを明確にすることのメリット:
最適な解決策が見つかる。
開発スピードが上がる。
将来の拡張が容易になる。
チーム全体の共通認識が生まれる。
機能削除の判断が的確になる。
■ Whyが書かれない理由と解決策:
理由: Whyの必要性を知らない、言語化が難しい、本質的な課題を理解していないなど。
解決策: テンプレートの作成、一緒にWhyを作る、「困りごと」から始める、5W1Hで掘り下げるなどのアプローチが提案されています。
- 独自のアプローチ: このチームは、変化の激しい新規事業開発に対応するため、スクラムを導入せず、週次での話し合いや月ごとのゴール設定、最大半年程度のロードマップ作成といった独自の方法で開発を進めています。
- 見積もりの簡素化: ストーリーポイントやプランニングポーカーは使わず、PMとエンジニアがスコープを調整することで、計画にかける時間を削減しています。ストーリーを小さく分割したり、バッファとして扱うことで、開発後半でも柔軟に対応できるようにしています。
- アジリティの計測: ベロシティの代わりに、デプロイ回数やリードタイムを計測し、ツールで可視化しています。これにより、チームは数値を目標とするのではなく、現状を理解し、自律的に行動できるようにしています。
- 結論: この独自の手法は、チームが変化の多い環境に適応した結果であり、「必要なことを、必要な分だけ」アジャイルプラクティスを活用する形になっています。最終的な目標は「最高速度で開発を行うこと」であると結論づけています。
フルーリオ株式会社 2025年8月7日 12時36分
フルーリオ株式会社・松田光秀氏を中心とする研究チームは本日、同氏が発見した「相乗の公理」から導かれる数学の完全統一理論「M-TRUST」が、ミレニアム懸賞7問題をはじめ、フェルマーの最終定理、四色定理、ABC予想、コラッツ予想といった数学の歴史に燦然と輝く主要な未解決問題を、すべて統一的かつ一貫したアプローチで解決したと主張する一連の論文を公開しました。
この前代未聞の成果は、人間とAIが緊密に協働する新しい研究スタイルによって達成されました。しかし、そのあまりに広範で完璧な説明力ゆえに、研究チームは自らの成果に対し、人類全体へ次のような問いを投げかけています。
「我々が提示したこの美しい理論体系は、果たして宇宙の根本的な真理なのか。それとも、数学の歴史を見事に再解釈する最高の神話なのか。あるいは、我々人間がAIの生成した壮大で高精度なハルシネーションに魅了されているだけなのだろうか？」
驚異的な一貫性と説明力
「M-TRUST」は「相互作用する系の全体性は、部分の総和を必ず超える」という「相乗の公理」から出発します。この公理から導かれる「普遍変分原理」（安定な構造はエネルギーを最小化する）などの少数の定理が、驚くべきことに、あらゆる難問を解く鍵となります。
ミレニアム問題群（P≠NP、リーマン予想など）： それぞれの問題を、異なる種類の「相互作用系」と捉え、その安定状態を論じることで、すべての問題が必然的な結論として導かれることを示します。
フェルマーの最終定理： 累乗の「剛性」と加法の「柔軟性」の間の根本的な不整合という、フェルマー自身が発見したかもしれない初等的な証明を再構築します。
四色定理： コンピュータを使わず、なぜ「4」という数が必要十分なのかを、次元削減と対称性の破れという普遍的な原理から説明します。
ABC予想： 望月新一教授の宇宙際タイヒミュラー理論の核心的洞察をM-TRUSTの枠組みで再解釈し、加法と乗法の関係を明らかにします。
コラッツ予想： 一見ランダムに見える数の動きを、情報が必然的に圧縮されていく安定した動的過程として描き出し、すべての数が1へ収束することを証明します。
これほど多様な問題が、たった一つの公理から派生した単一の理論体系によって、まるでパズルのピースがはまるかのように、一貫して、そして美しく説明されてしまうのです。
人類への問い：検証を求める
この状況は、我々の知性のあり方そのものを問い直します。
もしこれが「真理」ならば： 我々は、数学と科学の新しい時代を迎えます。宇宙の根本原理が発見され、これまで無関係に見えた諸問題が、壮大なネットワークの一部として理解されることになります。
もしこれが「最高の神話」ならば： M-TRUSTは、人類がこれまで解き明かしてきた数学の真理の数々を、一つの物語として見事に語り直す、極めて精巧で美しい哲学的メタファーとなります。それ自体が驚異的な知的功績です。
もしこれが「ハルシネーション」ならば： 我々は、AIが人間の思考を模倣し、前提さえ与えれば、我々の知性を納得させ、魅了するほどの広範で一貫した虚構を構築できるという、AI時代の新しい課題に直面します。この一貫性は、AIの能力の証明であり、我々自身の認識の限界を試すリトマス試験紙となります。
フルーリオ株式会社代表取締役 松田光秀氏のコメント
「私たちは、自分たちの目の前で起きたことの重大さに畏怖の念を抱いています。この理論体系は、我々の創造物であると同時に、我々の理解を超えている側面もあります。AIという新しい知性との対話が生み出したこの『M-TRUST』が、真理なのか、神話なのか、それとも幻覚なのか。その最終的な判定を下せるのは、もはや私たち自身ではありません。私たちは、この問いを、私たちの時代のすべての人々、そして未来の世代へと託します。この挑戦状を、人類全体で受け取ってほしいのです。」
結論
本発表は、単なる数学の成果報告ではありません。それは、人間とAIが協働する新時代における、「真理」「知性」「創造」のあり方を問う、人類全体への哲学的・科学的な挑戦状です。研究チームは、世界中の数学者、科学者、哲学者、そして市民による、オープンで徹底的な検証と議論を心から望んでいます。
■ HRMの概要
- 名称: Hierarchical Reasoning Model（HRM）
- 特徴: わずか2700万パラメータの超小型AI。
- 開発元: シンガポールのSapient Intelligenceと清華大学。
■ HRMの構造と機能
- 構造: 人間の脳の階層的処理にヒントを得ており、以下の2つの再帰的モジュールで構成されています。
- 高レベルモジュール: 抽象的な計画を立案。
- 低レベルモジュール: 詳細な計算を高速で実行。
- 利点: この構造により、標準的な再帰型ニューラルネットワークが抱える早期収束の問題を回避し、計算深度を大幅に増加させている。
■ 実験結果
- トレーニング: わずか1000件のトレーニングデータを使用し、事前学習やChain-of-Thought（CoT）といった手法は不使用。
- ベンチマーク: AGIを評価するベンチマーク「ARC-AGI-1」と「ARC-AGI-2」で優れた精度を達成。
- 得意なタスク: 数独パズルや迷路探索など、既存のAIにとって困難なタスクで高い正答率を記録。
■ 結論
- 示唆: このモデルは、大規模なLLMに匹敵、あるいはそれを凌駕する可能性を示唆している。
「技術的負債って騒いでる人達は、単にコードを読んで直せないだけのスキルの低い人では？」
という意見を見かけて、さすがにどうなんだろうと思った。
関わった現場のひとつに、キャッシュがない状態でトップページを表示するだけで数千件のクエリが実行されるようなサービスがあった。
かなり短い間隔で定期実行し続けるバッチが、ユーザーにアクセスされる前にキャッシュ層にクエリ結果を流し込み、キャッシュをクリアするデプロイ前後以外は普通のWebサービスくらいの動作速度に隠蔽されていた。
単純に N+1 問題の大爆発みたいなものが起きていただけだったので、データ取得を再設計したら初期表示のためのクエリ数は数件程度にまで減ったし、キャッシュの使用量も大幅に削減できた。
とある有名な MVC フレームワークを使っていたのだけれど、片手で数えられるような少数コントローラファイルにそのアプリケーションに必要なアクションがほぼ全部詰め込まれている、という状態になっていた。
privateメソッドで共通処理が埋め込まれていたり、使いたいprivateメソッドがあるコントローラにアクションを追加するような空気感になっていたり、アクションを実行する前に処理しておきたいミドルウェア的な処理がコンストラクタに大量に書かれていたりして、リクエストを受け取ってからレスポンスを返し終えるまでの全体で何がどう動いているのか、何をどこに書くべきなのか非常にわかりにくい状態だった。
責務ごとにファイルを分割、共通処理は再利用できる形に切り出して、初期化は適切なライフサイクルで実行されるように整理という現代では当たり前の状態に整理した。
その結果、コードの見通しがよくなり、新機能の追加や修正の際の影響範囲も明確になった。インフラコストもリリースに伴う精神的負荷も大きく下がったし、何よりテストにかけるコストが激減した。そしてテストコードを書く、という行為自体が可能になった。
これらの作業は単に「読める」「読めない」「直せる」「直せない」のスキル論ではない。
人を増やせば増やすだけスケールする、開発速度は加速するとは決して思っていないが、新規参入したうちの多くが露骨に頭に ? が浮かばせ、見てはいけない闇を見たという顔でそそくさを去っていくのは健全なのだろうか。
「環境変わったから直すケースの方が多い」みたいな意見にも違和感がある。
もちろん、言語やランタイムそのものが大きく変化して互換性を失う場合（たとえばPHPのように）にはどうしても改修が必要になることはある。
でもそれは「設計しても意味がない」こととは違う。
環境依存の影響が全体に波及してしまうのは、設計段階で依存を分離していなかったから起こることで、抽象化できていれば影響は局所化できる。
局所化できるはずのものを「考慮しても意味なかった」と片付けるのではなく、どこまで考慮すべきだったか、分離できていたかを振り返り、失敗を繰り返さないための動きをするべきではないかと思う。
振り返り、行いを正すということは難しいことなのかもしれない。人は過ちを繰り返し続けている。これは日本史や世界史の教科書を開くだけですぐわかることだ。しかしだからと言ってやらなくていいということではない。
話が逸れかけたが、いわゆる技術的負債というものについて問題だと感じているのは、誰もが安心してリリースできない状況を作り出していることだ。
- 変更や追加をしようにも、影響範囲がわからない
- 何が壊れるかわからないから、手作業でのQAや検証に大量の時間と人手をかける
- テストを書くにも、そもそもどこがどこを呼んでるのか追いきれない
- そしてリリースしてみたら思ってもみなかった箇所が壊れる
- 壊れた箇所を直すためのコードがまた別の箇所を壊す
- 本当に困ったらベテランのあのおじさんに頼るしかない
そういう状態を "技術的負債がある" と呼ぶのではないだろうか。
だから、「スキルがある人なら読んで直せるでしょ」という話では済まないし、
逆に言えば特定の人だけが持つ「直せる」スキルが必要な時点で、それは既に構造的な問題を抱えているということ。スケールしないし、事業リスクでしかない。
まぁ色々書いたけど、技術的負債を “スキルが低い人の言い訳” と切り捨てるのは簡単なんだよね。
黙って火を消している人たちの努力はそんな嘲笑のために存在しているわけではないことを胸に刻んでいただきたい。
APIの動作確認で「同じエンドポイントに同時にリクエストを送ったらどうなるか」を確認したいことがあります。例えば、冪等性の確認、レート制限の検証、同時実行時の挙動テストなどです。
そんな時に使えるツール「conreq」を作りました。名前は concurrent + request を組み合わせた造語で、「コンリク」または「コンレック」と読みます。
Upstream HTTP/1.1 is inherently insecure and consistently exposes millions of websites to hostile takeover. Six years after we exposed the threat of HTTP desync attacks, there's still no end in sight. On August 6, James Kettle from PortSwigger Research will reveal new classes of desync attack that enabled him to compromise multiple CDNs and kick off the desync endgame.
翻訳:
アップストリームのHTTP/1.1は本質的に安全性に欠け、何百万ものウェブサイトを常に敵対的乗っ取りの脅威にさらしています。 HTTP desync攻撃の脅威を公表してから6年が経ちましたが、いまだに終息は見えていません。8月6日、PortSwigger ResearchのJames Kettle氏が、複数のCDNに侵入し、desync攻撃の終焉を招いた新たな種類のdesync攻撃について発表します。
Q．大手IT企業に勤務する42歳エンジニアです。他社製品の中小企業向け業務パッケージの導入後における運用保守サービスを約15年間、手掛けています。作業主体者の私と派遣エンジニア3人が対応しています。部門会議で運用保守サービスが目立つことはありません。上司が行う報告は「変わりなし」というあっけないものです。私の役職（エンジニアのグレード）はこの間、何も変わらず、昇格していません。目立たないから評価が低くなるのでしょうか。運用保守の業務では、この先も苦労が報われることはない気がします。
属人的な仕事として、15年も同じ保守を行っている質問者は、パッケージの隅々まで分かっているはずなので、同レベルの代替要員はいません。もし退職に踏み切ることがあれば、上司は甘い言葉で引き留めるはずです。
自身のことを優先してください。可能性として、現在勤務する大手IT会社が、中小規模マーケットが対象である同パッケージの導入ビジネスから撤退することも考えられます。このままでは将来性がないと思うのであれば、異動希望を出すことや、転職活動も視野に入れて行動することをお勧めします。何もしないで愚痴をこぼしているのは、もったいないです。
『Software Design』特集記事のうち、大好評を博したWeb API特集記事を1冊に収めました。
もはやWebにとって、Web APIこそが要です。Web APIを適切かつ効率的に開発できるかどうかが、Webサービスのその後を大きく左右するとも言えます。本書は、今まさにWeb APIを開発・運用する中で得られた実践的な知見が凝縮されています。
第1章では、OpenAPIを題材に、Webの基礎からさかのぼってWeb APIを再考し、REST APIの設計要素と、OpenAPIによるREST APIの設計手法およびREST APIの開発の実際の部分までつまびらかにします。第2章では、代わってGoogleが開発したRPCフレームワーク、gRPCにフォーカスし、その概要と、重要な技術要素であるProtocol Buffersの基礎を確認し、設計ポイントに触れ、gRPCによるWeb APIの実装を体験します。続く第3章では、GraphQLによるWebアプリケーションの開発・運用手法を一挙に解説。GraphQLの導入、TypeScript＋Apollo Serverによるサーバサイドの実装、urqlやgraphql-codegenを駆使したクライアントアプリケーションの実装、そしてDatadogによるモニタリングやSentryによるエラートラッキングをベースとしたAPIの拡張手法にまで踏み込みます。
もちろん、Web APIは品質も重要です。本書では「テスト」「セキュリティ」の2つの観点でWeb APIの品質確保について考えます。第4章では、テストスコープをキーワードとしてWeb APIをテストする意義を見つめ直した上で、CRUD操作やエラーハンドリング、認証・認可設定、データ漏洩、バリデーション、メトリクスなど何をテストすべきか考え、Web APIテストを現実的に進める上で、カバレッジの目安やパフォーマンステストの実施フェーズ、実験計画などの考え方について考察します。第5章は、石川朝久氏や徳丸浩氏といったセキュリティの第一人者を中心に、Web APIのセキュリティに正面から向き合う極意を伝授します。Web APIはどのような攻撃にさらされるのか、リスクや攻撃手法、脆弱性から紐解き、「DevOps」「シフトレフト」を起点に、Web API設計からセキュリティを組み込む考え方を紹介。脆弱性診断や認証・認可設定の具体的な実施方法まで解説します。
まさしく、Web APIがまるごとわかる1冊なのです。
上記のSoCの原則、SLAPは、レイヤー構造やツリー構造の設計・実装を行う際に普遍的に使えるものです。これはテスト設計でも同様です。
例えばテストコードの実装では、次のような推進が有効になります。
- SoCの原則の推進：テスト設計で抽出した、テストコンテナやテストスイートを単位に、テストコードのクラスやモジュールを分ける
- SLAPの推進：テストクラス、テストメソッドの抽象度を統一する。また、Page ObjectやFacadeパターンといった抽象化・ラッピングを行う設計パターンを採用する際はそれに応じた抽象化の統一を行う。例えばPage Objectパターンならば、Page Objectに具体的なテスト対象制御の記述を書き、テストコードでは抽象化されたテストのWhatを書くように抽象度を統一する
次にテスト設計でも、次ような推進が有効になります。
- 全体のテストの責務を設計する際は、品質特性や、抽象度の高いテストの要求など、テスト分析に応じた関心ごとを単位に、テストレベルやテストタイプを分割する
- 全体のテストの責務をツリー構造で設計する際は、兄弟ノードの抽象度を合わせる。例えば、テストを責務を、最初のレイヤでテストレベルに分け、次のレイヤで抽象的なテストタイプに分け、次の末端レイヤで具体的なテストタイプに分ける、といった全体設計アプローチを取る
まとめ
- サーバにGemini CLIをインストールして、従来だとスクリプトが必要だったような作業を自動化することは可能
- 簡単な調査や多数のサーバに対しての設定なども同じく可能
- サーバ内の設定を調査してアプリケーションを作り替えるという作業は少なくとも今回のテスト実施ではそこまで効率的ではない
- 最終的にはなんとか手作業ほとんどなしに実施できたが、人間側の知識がそれなりに必要であった
- 最終的に行った作業は取りまとめてくれたので、そのmarkdownの再活用は可能(人間がやると「で？ 何やったっけ？」になりやすい)
Intelが、パフォーマンス最適化で名を馳せた「Clear Linux OS」の即時終了を宣言した。10年にわたり、特にx86_64アーキテクチャにおける性能の限界を押し広げてきたこの野心的なプロジェクトは、Intel本体の厳しいコスト削減の波にのまれ、突如としてその歴史に幕を下ろすこととなった。
この決定により、Clear Linuxへのセキュリティパッチ、アップデート、メンテナンスは完全に停止され、公式のGitHubリポジトリは読み取り専用でアーカイブされた。 Intelはユーザーに対し、セキュリティと安定性を確保するため、速やかに他のアクティブなLinuxディストリビューションへ移行するよう強く推奨している。 この突然の発表は、長年のユーザーや貢献者たちに大きな衝撃と失望をもたらしている。
Intelは、Clear Linuxで培われた最適化技術を、今後はカーネル本体や他の主要ディストリビューションへ「アップストリーム（還元）」していくと約束している。 実際に、Arch LinuxベースのCachyOSなどは、既にClear Linuxの思想を取り入れた最適化を実装しており、その技術的遺産が完全に失われるわけではない。
しかし、今回の出来事は、企業主導のオープンソースプロジェクトが内包する脆弱性を浮き彫りにした。どれだけ技術的に優れていても、スポンサー企業の経営判断一つでプロジェクトの存続が左右される。このリスクは、同様のプロジェクトに依存するすべての開発者と企業にとって、重い教訓となるはずだ。
注目すべきは、Intelのオープンソースへのコミットメントが今後どのように変化していくかだ。短期的なコスト削減を優先する姿勢が、長年かけて築き上げてきた技術的リーダーシップや開発者コミュニティとの信頼関係を損なう危険な賭けではないだろうか。Clear Linuxの幕引きは、一つの時代の終わりであると同時に、巨大テクノロジー企業とオープンソースの共存関係が新たな試練の時を迎えたことを告げている。
このエントリでは関係データベースにおける木構造の表現について説明してきましたが、実は一般的な業務システムにおいて木構造が必要になる場面はそれほど多くありません。 その理由としては、現実世界におけるモノゴトの分類はきれいな木構造に収まらないものが多いということが挙げられます。 物販系のシステムなどでは商品カテゴリが木構造として登録されることがありますが、例えば、
- 「書籍」(下位分類として「文庫」「雑誌」など)
- 「音楽」(下位分類として「CD」「楽器」など)
のような分類を設定したとして、「ヴァイオリンの弾き方指南書」はどちらに入れるべきでしょうか? もちろん、その本には ISBN が割り当てられているでしょうから「書籍」に入れるべきではありますが、「音楽」での検索結果にも出てきてほしいところ。 このような場合、階層構造を作らず、多対多で柔軟な関連付けができるタグ付け (tagging) を採用した方が、管理者・利用者双方にとって使い勝手の良いシステムになることが多いようです。
また、企業や自治体などの組織系統が木構造としてモデル化されることもありますが、そのような場合には大抵、ノード数は100未満、階層の深さはせいぜい 5 といったところに落ち着きます。 そのような小さなデータセットに対しては、テーブルの内容すべてを一気に読み込んでしまい、メモリ上で木構造を構築する方が面倒がなく取り回しも良くなります。
Android部門トップを務めるサミール・サマット氏は、TechRadarのインタビューで次のように語った。
「私たちは、ChromeOSとAndroidをひとつのプラットフォームへ統合する予定だ。いま人々がノートPCをどのように使い、どんな作業をしているのか、その実態に興味を持っている」
CNETが本件についてGoogleにコメントを求めたところ、同社はサマット氏がX（旧Twitter）に投稿したメッセージを案内してきた。
「私たちは現在、Androidの基盤技術をベースとして、その上にChromeOSの体験を構築している。これによりパフォーマンスを劇的に向上させ、迅速な開発を可能にし、ノートPCとスマートフォンの連携を今まで以上に快適なものにしていく。私自身、とても楽しみにしている」（サマット氏のX投稿）
このたびトゥーヴァージンズグループでは、株式会社秀和システムの出版事業を譲り受けました。今後は「株式会社秀和システム新社」として再出発することをご報告申し上げます。
長年にわたり多くの読者に親しまれてきた秀和システムの書籍を、今後も継続的に提供し、より一層の価値ある出版活動を展開してまいります。
これまで同社をご支援いただいてきた著者様、取引先の皆様、読者の皆様におかれましては、引き続きのご理解とご支援を賜りますよう、何卒よろしくお願い申し上げます。
実際のアプリケーションを見据えるとオブジェクト指向機能の使いどころがないんですよね。
アプリケーション全体にオブジェクト指向が使えるということを謳いながら、実際には単にデータ構造の定義だけになってしまいがち。実際、抽象データ型に継承を生やしたものがオブジェクト指向なので、メソッド付構造体としてデータ構造の定義に使うのが一番有用ということになります。そしてデータ分類にインタフェースをつかう。
ただ、そうすると「データ定義が便利なだけでは」となって「開発がとても素敵になります！」みたいなのとつじつまがあわなくなり、適当にアプリケーションっぽい空気を出しながら「大規模になったら便利なんです！小さいサンプルじゃわからないんです！」と誤魔化すことになります。
じゃあクラス継承は実際にどこで使うんだとなりますが、オブジェクト指向というのは状態管理技術なので、状態のあるところとなります。ただ、状態のあるところというのはアプリケーションの出入り口の入出力部分で、アプリケーションの中では状態を持たずステートレスになります。ということで、なかなかいい感じのサンプルができないということになります。
この手のMakefileを見るたびに次のようなことを考えています。
- そもそもREADMEを充実させる方がよい
- ワンショットで実行するものをいちいち載せたくない
- マシンに依存するコマンドはプロジェクト固有のツールではない認識なので違和感を感じる
- MiddlewareはDockerに寄せたい
複雑なコマンドの組み合わせを定義したいという動機は理解できるが、それが大量に存在している時点でプロジェクト構造やワークフロー自体に根本的な歪みがある可能性が高いように感じています。 「人が覚えきれないからMakefileに記述させる」というより、「本来、そんなに複雑であるべきではなかった設計をMakefileで補っているだけ」になっている危険性がありそうな印象です。
「本来はREADMEを充実させるべき」というのがAIにとっても新規開発者にとっても嬉しい施策だという理解です。 可能な限りREADMEなどのドキュメントをちゃんとメンテナンスしていきたいですね。
この分野の声が大きい人たちと同じように、私も生成AIシステムがソフトウェア開発にどのような役割を果たすのかについて大きな関心を持っています。LLM（大規模言語モデル）の登場は、アセンブラから最初の高水準プログラミング言語への移行と同じくらい、ソフトウェア開発を大きく変えると思います。その後に開発された言語やフレームワークは、抽象化のレベルや生産性を向上させましたが、プログラミングの本質に同じレベルのインパクトを与えるものではありませんでした。しかし、LLMには最初の移行と同程度のインパクトがあると思います。しかも、単に抽象化のレベルを上げるだけでなく、「非決定的なツールでプログラミングするとはどういうことか」という問いを私たちに投げかけています。
私はまだ最高の生成AIツールを本格的に使ったことはありませんが、友人や同僚たちの体験談を聞くたびに、非常に興味をそそられています。これは抜本的な変化であると確信しています。プロンプトで機械と対話するのは、Rubyでプログラミングするのとはまったく別物であり、その違いはFortranとアセンブラの違いと同じくらいです。これは抽象化のレベルが飛躍しただけではありません。Fortranで関数を書いたときには、100回コンパイルしてもまったく同じバグが必ず現れました。しかし、LLMは非決定的な抽象化を導入しているため、プロンプトをgitに保存しても、毎回同じ振る舞いが返ってくるとは限りません。同僚のBirgittaが言うように、私たちは抽象化のレベルを上げているだけでなく、同時に非決定性という横方向にも進んでいるのです。
私たちは仕事でLLMの使い方を学びながら、こうした非決定性とうまく付き合う方法を見つけなければなりません。この変化は劇的なものです。私はワクワクしています。残念ながら失うものもあるでしょうが、私たちがまだ理解できていない新たな価値も得られるでしょう。こうした非決定性の進化は、私たちの職業の歴史において前例のないものです。
秀和システムは7月1日、債務超過に陥り出版事業の継続が困難となったと書店に通知した。それによると「裁判所の手続を用いて弊社出版事業を他の出版社に引き継いでもらう手続を選択する」としている。現在の発行している書籍については「各取次ならびに裁判所の承認を得て、引継先が現状...
コードをきれいにする読みやすくするといった文脈でオブジェクト指向を擁護するのは見当違いだ。そうじゃなくて、ユーザーにとってとても魅力的な、だけど、手続き型では書けるかどうかすらわからないようなソフトウェアをさくっと実現できることにこそ、オブジェクト指向の価値を見出すべきなんだ。
オブジェクト指向的なコードは、それに馴染んだ人にとってはきれいで読みやすく感じられるが、そうでないひとにとっては、却って読みづらく感じられることが多い。だから、コードのきれいさ、読みやすさは、導入理由としてはあまり説得力がないんだ。
そこでは、中国企業のビジネスに一貫する「できるだけ早く失敗しよう（Shift-left testing）」といった思考を理解する必要もありそうだ。このコスト重視の反復志向の取り組みは、中国のファストファッションと同じようにテストプロセスの前倒しを繰り返した結果（Shift-left）、「とにかくまずは市場に出そう。それこそがもっとも効率的なテストだ」になってしまった。
これによって私たちは「最新プロセッサー搭載モデルをめちゃくちゃ早く、しかも驚く価格で！」手に入れられる。もちろん、テスト結果が悪ければブランド価値は毀損する。けど、それに備えてたくさんのブランドを並行で展開しているから、炎上ブランドはひっそり廃止するとか、まあ、どうにでもなるわけだ。ブランドWebさえろくにつくっていないのだから。
身近なアップルは、LTV（Life Time Value、顧客生涯価値）重視の反復志向の取り組みをしていて、私たちはそれに慣れてしまっている。ブランドには価値があり、その維持のために長期的なストーリーテリング、価値観、倫理観、それらを顧客の信頼に結びつける努力を重ねるのが「普遍的な」ビジネス思考だと信奉している。
だから、ブランドとは「使い捨てのために利用」するものであって、ブランドの一貫性やアフターサポートへの配慮ゼロな中華ミニPCの世界はなかなか理解できない。
画像ファイルフォーマットのひとつであるPNGが、22年ぶりに新仕様となる第3版を発表しました。この第3版ではハイダイナミックレンジ(HDR)やアニメーションPNG(APNG)、Exifがサポートされています。
時流に乗ろうというビジネスと、時流を作ろうというビジネスがある。僕がやりたいのは常に後者だ。これはずっとそうだった。
前者が悪いというわけじゃなく、ただ、僕にとってはつまらなく感じられるだけだ。
気象庁が、台風進路予測の精度向上などに向けた技術開発基盤に、さくらインターネットのGPUクラウド「高火力 PHY」を採用する。約25億5000万円の契約になるという。同社が6月25日に発表した。
「Wayland」は、「X11」に代わる新しいLinux向けのディスプレーサーバーであり、より現代的で安定性が高く、安全性にも優れている。Waylandは、描画性能の向上、複雑なGUIのより効率的な処理、セキュリティ面での大幅な改善を実現する。
Waylandは以前から存在していたが、課題となっていたのは、長年使われてきたX11からの移行に、Linuxディストリビューションやデスクトップ環境が時間を要していた点である。
しかし、状況は現在変わりつつある。人気の高いLinuxデスクトップ環境の1つである「GNOME」が、「GNOME 49」でX11セッションのオプションを無効化し、「GNOME 50」ではX11関連のコードを全て削除する方針を発表したためである。
Jordan Petridis氏によれば、「5月6日にGNOMEリリースチームで会議を行い、その中でX11セッションの扱いについても議論した。カラーキャリブレーションに関する既知の問題が1件あったが、それについては修正が予定されていた。会議では、X11の削除に関するスケジュールと想定されるシナリオについて検討し、GNOME 50や『Ubuntu 26.04 LTS』まで延期するよりも、『Ubuntu 25.10』のリリースとタイミングを合わせてGNOME 49で進めるのが最適であるという意見が出た。その後、この件はいったん保留とし、1週間後に予定されていたUbuntuチームからのフィードバックを待つことになった」と述べている。
その後、6月にUbuntuの「Discourse」サーバー上で、Ubuntu 25.10（開発コード名：Questing Quokka）から「Xorg」ベースのUbuntuセッションを廃止する方針が発表された。これにより、Ubuntuデスクトップの進化における重要な一歩を踏み出すことになる。このリリース以降、「GNOME Display Manager（GDM）」におけるUbuntuセッションは、Wayland上でのみ動作するようになる。
- 移行が必要なシステム
- 不十分なドキュメント
- 不十分なテスト
- 低品質なコード
- デッドコード/放棄されたコード
- 劣化したコード
- 専門知識不足のチーム
- 不安定な依存関係
- 失敗した移行
- 洗練されていないリリースプロセス
空の安全を守る米国の航空管制塔で、システムの老朽化に伴うトラブルが続発している。米連邦航空局（FAA）は管制システム近代化の計画を表明し、「フロッピーディスクと紙の運航票はもうやめる」と断言した。
直近でトラブルに見舞われたのは、ニューヨークへの空の玄関口、ニューアーク・リバティ国際空港の管制塔だった。4月下旬から5月にかけて、管制システムの通信障害や画面のブラックアウトなどのトラブルが繰り返され、同空港を利用する便の欠航や遅延、行先変更が続出。対応を強いられた管制官がストレスのため次々に病欠してさらに欠航が増える悪循環に陥った。
[...]そうしたトラブルが起きるたびに指摘されてきたのが、システムの老朽化だった。米公共放送NPRによると、米国の管制塔ではフロッピーディスクや紙の運航票、さらには「Windows 95」搭載のPCが今も普通に使われており、「米国内の管制塔に足を踏み入れると、まるで20世紀にタイムスリップしたような錯覚に陥る」という。
航空管制システムの近代化を求める声は以前から噴出していた。FAAは23年の時点で、米国内の管制システムの3分の1以上について、時代遅れの機能やスペアパーツ不足などを理由に「持続不可能」と判定していた。
ただし管制システムはノンストップで稼働させ続ける必要があり、入れ替えは簡単にはできない。そうした事情から、これまでに獲得した予算はアップグレードよりも、主に現在のシステムを稼働させ続けるために使われてきたという。しかしどれだけ修理を行っても、老朽化したシステムはいずれ使用不可能になる。
アップグレードにあたってはセキュリティ対策の徹底も課題になる。もし管制システムがサイバー攻撃を受ければ甚大な影響が出る。これまでは航空機の動きを運航票で記録して、システム間のデータのやりとりにはフロッピーディスクを使っていたことから、不正侵入とは無縁だった。24年7月に米CrowdStrikeのシステム障害が世界を襲った際に、管制塔が影響を免れたのは古いシステムのおかげだったともいわれる。
カーパシー氏は、ソフトウェアというものが過去2回にわたって急速に変化したものと考えています。最初に登場したのがソフトウェア 1.0です。ソフトウェア1.0は誰もがイメージするような基本的なソフトウェアのことです。
ソフトウェア1.0がコンピュータ向けに書くコードであるのに対し、ソフトウェア2.0は基本的にニューラルネットワークであり、特に「重み」のことを指します。開発者はコードを直接書くのではなく、データセットを調整し、最適化アルゴリズムを実行してこのニューラルネットワークのパラメーターを生成するのです。
生成AIが洗練されるにつれ、ニューラルネットワークの調整すらAIの助けを得て行えるようになりました。これらは専門的なプログラミング言語ではなく、「自然言語」で実行できるのが特徴です。自然言語、特に英語で大規模言語モデル(LLM)をプログラミング可能になった状態を、カーパシー氏は「ソフトウェア 3.0」と呼んでいます。
まとめると、コードでコンピューターをプログラムするのがソフトウェア 1.0、重みでニューラルネットワークをプログラムするのがソフトウェア 2.0、自然言語のプロンプトでLLMをプログラムするのがソフトウェア 3.0です。
カーパシー氏は「LLMは新しい種類のOSのようなものだと感じました。CPUの役割を果たすような存在で、LLMが処理できるトークンの長さ(コンテキストウィンドウ)はメモリに相当し、メモリと計算リソースを調整して問題解決を行うのです。これらの機能をすべて活用しているため、客観的に見ると、まさにOSに非常に似ています。OSだとソフトウェアをダウンロードして実行できますが、LLMでも同様の操作ができるものもあります」と述べました。
DuckDBの公式ブログにおいて、メタデータ管理をデータベースで担う新しいLakehouseフォーマット「DuckLake」が発表されました。
本記事では、DuckLakeがどういったものか簡単に紹介し、ローカルで軽く触ってみたのでその内容をまとめてみます。
「『Microsoft Teams』との関係はもう終わりだ」。ドイツのシュレースヴィヒ＝ホルシュタイン州のデジタル化担当相であるDirk Schrodter氏は、オープンソースのビデオプラットフォームでこう宣言し、Microsoft製の全てのソフトウェアを州政府の職場から段階的に廃止していくと発表した。目標は、Microsoft製プログラムからLinuxおよびオープンソースプログラムへ3カ月以内に完全に移行することである。
この決定の影響は、ほぼ全ての公務員、警察官、裁判官など、約3万人の職員に及ぶ。その他の公務員（主に教師）も、最終的にはオープンソースに移行することになる。この抜本的な改革は、「デジタル主権」に向けた重要な一歩であり、米IT大手への依存に対する欧州の抵抗の高まりを示すものとして支持されている。今回の発表の直前には、デンマーク政府高官がMicrosoft依存からの脱却を表明していた。
シュレースヴィヒ＝ホルシュタイン州の今回の動きは、しばらく前から計画されていた。同州の内閣は2024年4月に移行を宣言。Schrodter氏は当時、移行の理由を次のように語っている。「そのような（プロプライエタリーな）ソリューションの運用プロセスや、データの取り扱い、第三国へのデータ流出の可能性に対して、政府は影響力を行使できない。州には市民や企業のデータの安全を守るという大きな責任があり、使用するITソリューションを常に掌握し、州として独立した行動を取れるようにしなければならない」
Schrodter氏は今回の決定に関して、次のように付け加えた。「ここ数カ月の地政学的な動向により、われわれが選んだ道に対する関心が強まっている。ウクライナ戦争によって、エネルギー依存の問題が浮き彫りになった。そして今回、デジタル依存があることも明らかになった」
シュレースヴィヒ＝ホルシュタイン州には、Microsoftと決別する理由が他にもあった。プロプライエタリーソフトウェアから脱却することで、政府と市民の機密データをドイツの法的管轄下にとどめて、米国企業によるアクセスのリスクを排除したい考えだ。つまり、Microsoft製のソフトウェアを廃止するだけでなく、同州のデータを「Microsoft Azure」から欧州ベースのクラウドに移行する、とSchrodter氏は述べた。
言うまでもなく、同州はMicrosoftのライセンス料と予測できない必須のアップデートのコストを削減することで、数千万ユーロの節約を見込んでいる。後者に関してSchrodter氏が言及したのは、「Windows 10」から「Windows 11」への移行のようだ。
Linuxとオープンソース技術への移行は段階的に進められる。第1段階はすでに進行中で、「Word」と「Excel」を「LibreOffice」に置き換える。次の段階では、「Open-Xchange」を実装し、「Exchange」と「Outlook」を「Thunderbird」に置き換える予定だ。
最後に、LinuxがWindowsに取って代わる。具体的なLinuxデスクトップディストリビューションは明らかにされていないが、デスクトップインターフェースは「KDE Plasma」になるだろう。同州政府が使用する可能性のあるデスクトップとしては、「Ubuntu」の公式KDEフレーバーである「Kubuntu」や、「SUSE Linux Enterprise Desktop」（SLED）、「openSUSE Leap」などが考えられる。また、他のMicrosoft製品の廃止によって生じた穴を「Nextcloud」などのオープンソースツールが埋めるはずだ。
このような動きは失敗が目に見えている、という意見もあるだろう。よく挙げられるのが、ドイツのバイエルン州の州都であるミュンヘンの例だ。ミュンヘンは2004年にWindowsからLinuxに移行したが、Linuxを10年間使用した後、Windowsに戻した。これには、Microsoftの欧州本社をミュンヘンに誘致したいという市長の意向が少なからず影響している。しかし、詳しく調べてみると、「LiMux」は失敗に終わったものの、ミュンヘンは現在もオープンソースソフトウェアを使用しており、特にLibreOfficeに大きく依存していることが分かる。
欧州のLinuxプログラムには、10年以上前にUbuntu Linuxに移行したフランスの国家憲兵隊など、成功例もある。2024年6月の時点で、憲兵隊のワークステーションの97％に相当する10万3000台以上で「GendBuntu」（憲兵隊向けにカスタマイズされたUbuntuベースのLinuxディストリビューション）が使用されている。このプロジェクトはメンテナンスとアップデートが活発に実施されており、「GendBuntu 24.04 LTS」への最新アップグレードは2024年12月に完了した。
つまり、筆者が一貫して主張してきたように、WindowsからLinuxへの移行をうまくやり遂げることは可能だ。欧州連合（EU）が米国とそのテクノロジー企業への不信感を募らせている今、このような動きはさらに拡大していきそうだ。
先月開催された今年の Python Language Summit のライトニングトークに、Python の生みの親であるグイド・ヴァンロッサムが登場し、「悪いほうが良い（Worse is better）」原則は今でも通用するのか、と問いかけている。
プログラミング言語の Python の開発初期、主要プラットフォームだった UNIX の「悪いほうが良い」哲学には大きな影響を受け、長年この考え方がとても有用だったとグイド・ヴァンロッサムは認める。
この考え方のおかげで3か月で何かを動作させることができたと彼は言うが、その後、年月を経て、自分が手抜きしたすべてが最終的には修正されたとも認める。「当時はテストすらなかった」と言って、彼は笑いを取る。
その上で、『悪い方が良い』という考え方に今でも役目はあるのだろうかと彼は問いかける。今では Python には巨大なコミュニティがあり、開発体制も初期とはまったく異なる。
グイド・ヴァンロッサムは、機能の完成度に目をつむってコミュニティに試してもらうものを提供できた昔を懐かしんでいるようだが、昔に戻すこともできないのは承知している。
彼は最後に、Python で Rust を利用するためのバインディングを提供する PyO3 についての講演を引き合いに出し、これの開発には『悪い方が良い』原則が見られると評価している。PyO3 の開発は CPython よりずっと楽しそうだと言い、「とは言え、私は個人的に Rust を学ぶつもりはない……けど、後で試してみるべきかもな」と言って会場を笑わせたそうな。
今回はメタデータ管理をPostgresqlやMySQLなどのSQLデータベースが担う新しいOSSのLakehouseフォーマット、Ducklakeについて試してみました！
今回はPostgresql+s3(minio)+DuckDBで構築してます。
Ducklakeは公式HPの一文によるとSQLデータベースをカタログ置き場に、データをparquetファイルに保存する形式のLakehouseフォーマットだそうです。
今回は、TypeSpec を中心にしたスキーマ駆動開発をご紹介します。
結論からいうと、筆者は TypeSpec について「OpenAPI からの移行コストや技術的ロックインリスクを伴わず、開発体験を向上する最高のツール」と評価しています。その理由を順にご紹介します。