Linuxカーネルのリソースノードのリライトに対する、たった1つの修正がことの発端だった。Linus Torvalds氏は、その修正を見れば見るほど当惑していった。なぜなら、その修正は「実際には何も修正していなかった」からだ。
同氏は「この無意味なコミットの理由を説明してくれることを期待して、『Link:』引数を確認した。しかし、いつものように、そのリンクはすでに存在するくだらない情報を指し示しているだけで、ただ時間を無駄にした」という。
その後、Torvalds氏は「もうこのゴミはやめろ」と語り、Linux Kernel Mailing List（LKML）での議論において、当惑から瞬く間に怒りへと変わった。同氏はさらにこう続ける。「私の最初の反応が間違っている理由を説明してくれるような、何か不具合報告などを指し示していることを期待していた」が、結局は期待外れに終わった。
Torvalds氏は「人の時間を無駄にする無意味なLink引数を追加するのはやめてくれ。“追加”の情報がある場合にのみリンクを追加してほしい」と宣言した。また、「この無意味なリンクは本当に嫌いだ。“役に立つ”リンクは大好きだが、実際に見るリンクの99％は、ただの愚かで役に立たないゴミを指しているだけで、私の時間をただただ無駄にしている。今回もだ！」といら立ちをあらわにした。
要するに、同氏は「もし私にプルすることを本当に期待しているなら、役に立たないリンクではなく、ちゃんとした説明が欲しい」と語っている。さらに、「そうだ、私は機嫌が悪い。私の主な仕事、いや、本当に唯一の仕事はプルリクエストを理解することだと感じており、だからこそ、自動的に追加され、私の仕事をより困難にするだけのこうしたものが、心底嫌いなのだ」と心情を吐露した。
他の人々もTorvalds氏の意見に同意している。あるRedditの投稿者は、「Linusの言うことは一理ある。あの元のパッチはAIが書いた要約のように見えたし、問題の説明へのリンクも同じ要約だった」と述べている。
仕様駆動開発（Specification-Driven Development）は、まず仕様を明確に作成し、その仕様を基に実装計画を立ててコーディングを行うという開発手法です。
Amazon Web Services（AWS）が7月に発表したコーディング支援ツール「AWS Kiro」がこの手法を採用しており、それがきっかけで注目されるようになりました。
参考：AWSがAIコードエディタ「Kiro」をプレビュー公開、VS Code互換。AIとチャットしながらプロダクトを開発
今回GitHubが公開したSpec Kitは、この仕様駆動開発のワークフローの実行を生成AIが支援してくれる仕組みを備えており、後述するようにGitHub CopilotやClaude Code、Gemini CLIで仕様駆動開発が容易に実現できます。
【ニューヨーク共同】生成人工知能（AI）の開発に著作を不正に使われたとして、作家らが米新興企業アンソロピックを訴え、15億ドル（約2200億円）を原告に支払う和解案で合意したことが5日、分かった。
JavaScriptランタイム「Bun」の最新バージョンとなる「Bun v1.2.21」がリリースされ、BunがMySQL/PostgreSQL/MySQLを単一のBun.SQL命令でサポートするユニバーサルなデータベースクライアントとなることが示されました。
Bunは、2023年に登場したバージョン1.0の時点でデータベース機能としてSQLiteを内蔵しており、今年（2025年）1月にリリースされたBun 1.2で、MySQLとPostgreSQLのクライアント機能を搭載しています。
本バージョンでBunが備えるデータベースクライアントライブラリのBun.SQL命令が、Bunに内蔵されたSQLiteをサポートしたことで、主要な3つのデータベースに対して単一のBun.SQLが利用可能になりました。
- 開発フローの「型」: 効果的な利用のためには、利用方法に「型」を決め、インクリメンタル（段階的）に進めることが重要だと述べられています。
- 具体的なコマンドとプロセス:
/design: 実装計画の作成/revise: 計画の修正/implement: 実装/ask、/instruct: 実装内容の修正/review: コードレビュー/recap: タスクの振り返り、ナレッジの蓄積- ツールの活用:
- Git: 細かくコミットを行い、
difitのようなツールでレビューを繰り返すことが推奨されています。- CLIツール: Neovimやtmuxなど、ターミナルを広く使うことで作業効率を高めています。
- Obsidian: 開発で得られたナレッジを管理するために使用しています。
- 公開されているリソース: 記事内で紹介されているスラッシュコマンドやサブエージェントは、Gistで公開されており、読者も利用可能です。
日本政府は8月27日、米国・韓国と共同で、身分および所在地を偽って業務を受注し、核や弾道ミサイル開発の資金源としている北朝鮮IT労働者に対して懸念を表明する「北朝鮮IT労働者に関する共同声明」を公表した。
北朝鮮IT労働者は、AIツールの活用や外国の仲介者との協力などのさまざまな手法により、偽の身分および所在地を活用して非北朝鮮IT労働者として偽装し、世界中の標的となる顧客からフリーランスの雇用契約を獲得するため、高度なITスキルへの需要を利用しているという。また、北朝鮮IT労働者自身も、悪意あるサイバー攻撃に関与している可能性が極めて高いといい、知的財産やデータ、資金の窃取など、深刻なリスクをもたらすとしている。
同声明では、これらの活動について懸念を表明するとともに、脅威を阻止するための連携について公表された。あわせて、日本では、2024年3月に公表した「北朝鮮IT労働者に関する企業等に対する注意喚起」を更新し、米国は、北朝鮮IT労働者に関する計画を促進する4つの団体および個人を関連措置の追加対象へ指定、韓国は、北朝鮮IT労働者の活動に関するアドバイザリを発出した。
3カ国は8月26日、サイバーセキュリティ企業のMandiantと連携し、北朝鮮の攻撃に対して官民の連携を向上させ、国際的な業界連携を支援するための行事を東京で主催した。今後、北朝鮮による悪意あるサイバー活動及び不法な資金調達に対処するため、3カ国間の連携を強化し、官民連携を強化する取り組みについて改めて確認するとした。
ITエンジニアが導入の必要もない超シンプルなサービスにk8sを導入して転職するムーブを「履歴書駆動開発」と評している人がいてワロタ
このエントリには直接書いてないのですが、このエントリでは要するに 名前について仮定を置くな と言っているのです。言い換えれば、 名前を入力するフィールドを「姓と名」に分けたり、長さとか文字の種類についてバリデーションするべきでない ということを主張しているのです。
とはいえ、実際にシステムを作るときには、次に3点だけは制約としてあっていい、と 個人的には 思っています。件のブログによるとこの仮定すら本当は間違っているのですが、流石にシステムを設計するときには、この3つの仮定くらいは設けないと、先に進めませんからね*1。
- 人の名前は Unicode 16.0 で表現できる。
- 人には1文字以上からなる名前がある。
- 人の名前は255文字以下である（あるいは100文字以下、ないし50文字以下。正確な値はシステムの要件に合わせて決めてください）
Googleは「信頼性を確保するために待機しているアイドル状態のマシンも考慮する」「GPUやTPUなどのAI処理用チップだけでなくCPUやDRAMも考慮する」「計算用マシンだけでなくデータセンターの冷却システムや配電システムも考慮する」といった条件を付加し、より実際の運用に近い値を算出しました。その結果、Geminiは電力消費量の中央値は1プロンプト当たり0.24Whで、二酸化炭素排出量は0.03g、水の消費量は0.26mlであることが明らかになりました。これは「テレビを9秒みた際の電力消費量」や「5滴の水」に相当します。
GoogleはGeminiの開発時にエネルギー効率の高いアルゴリズムを選択していることや、Google製AI処理チップ「TPU」の電力効率の高さが今回の結果をもたらしたとアピールしています。また、Googleは今後も電力および水の消費量削減に取り組んでいく姿勢を示しています。
フューチャー社内の有志メンバーでI/F設計ガイドラインを作成し、公開しました。
- I/F設計ガイドライン | Future Enterprise Arch Guidelines
システム開発、特にエンタープライズ領域においてシステム間のデータ連携は避けて通れません。
本ガイドラインは、クラウドネイティブな環境におけるモダンなシステム間連携の設計指針を提供することを目指しています。
アピールポイント
連携方式の選定といった上流のアーキテクチャ設計から、ファイル形式や冪等性といった下流の詳細設計、そして結合テスト計画の指針まで網羅されたガイドラインになっています。
■ まとめ
- POML (Prompt Orchestration Markup Language) はプロンプトを構造化された文書として管理するためのマークアップ言語
- VS Code 拡張機能や TypeScript, Python を通じて POML ドキュメントを解析しプレーンテキストに変換できる
- .poml 拡張子のファイルで POML ドキュメントを保存し、HTML タグに似た構文でプロンプトを定義
- ドキュメントのルートは <poml> タグで始まり、<role> や <task> といったセマンティックなコンポーネントを使用
- <img>, <table> などのコンポーネントを使用して、リッチなコンテンツを表現
- 変数の定義やループ、条件分岐を使用して動的なプロンプトを生成可能
- <meta> タグを使用して POML ドキュメントにバージョン要件やレスポンススキーマ、ツールスキーマを追加
IT「人手不足です」
求職者「働きます」
IT「未経験者はいりません」
求職者「じゃあ諦めます」
IT「人手不足です」
求職者「働きます」
IT「未経験者はいりません」
ずっとこんな感じじゃん
官公庁関係のBPO業務やってる会社から仕事分解して未経験者がこなせる難易度に落とし込むノウハウ盗んだ方がいいんじゃねえか？
■ ステップ1：まず章をざっと眺める
目的：章全体の内容を把握する。
方法：詳細には読まず、ページをパラパラとめくる。写真・見出し・グラフ・図表に目を通し、長さ／テキストと図の配分／目立つ要素をつかむ。
■ ステップ2：章末のクイズを先に読む
目的：その章が教えようとしていることを理解する。
方法：本文に入る前に、章末のクイズや要約質問を確認。著者が重要とみなすポイントを先に把握して、読む目的を明確にする。
■ ステップ3：太字だけを読む
目的：重要概念と章の構成をつかむ。
方法：章頭に戻り、太字（タイトル／小見出し／トピック見出し）のみを拾い読み。主要な概念と流れの骨格をつくる。
■ ステップ4：各段落の最初と最後の文だけを読む
目的：各セクションの概要をつかむ。
方法：再度ざっと流し読みし、各段落の第1文と最終文だけ読む。段落の要点を短時間で押さえ、章全体のマインドマップを頭の中に形成。
■ ステップ5：章全体を読む
目的：章を詳細に理解する。
方法：ここで初めて通し読み。すでに全体像と重要点を知っているため、集中と選択が効く。重要箇所はメモや余白ノートに要点・疑問・関連知識を書き出す。
■ ステップ6：復習と繰り返し
目的：繰り返しによる記憶の定着。
方法：ノートやハイライトを定期的に見直す。翌日・1週間後・1か月後と、間隔反復で復習すると効果的。
■ 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投稿）