全727件 / 37ページ中 3ページ目

20件表示

🟠
Hacker News

Firefoxが「非対応ブラウザ」扱いされ始めた——ChromeオンリーWebの現実と対処法

「ChromeがIEになった」という指摘が刺さる。Firefoxユーザーはもちろん、Web標準とブラウザ多様性を気にするエンジニア全員に読んでほしいスレッドだ。

「お使いのブラウザはサポートされていません。Chromeに切り替えてください。」——Firefoxユーザーなら一度は見たことがあるメッセージではないだろうか。Hacker Newsに投稿されたあるスレッドが、静かに広がるこの問題を改めて可視化した。 何が起きているか 投稿者のgurjeetは、わずか2日間で2件の「Firefox非対応」に遭遇したと報告した。 - Apple Business Manager(business.apple.com):「非対応ブラウザです」と表示し、Firefoxではログイン不能 - <strong>Alma(移民ビザ申請プラットフォーム)</strong>:「本プラットフォームはGoogle Chromeのみに対応しています」と明記 興味深いのは、AlmaのトップページはFirefoxで動作するのに、app.tryalma.comというアプリ本体だけがChrome限定になっている点だ。Safariでもブロックされるという報告もあり、これは<strong>「Firefoxへの敵対」というより「Chrome以外を切り捨てる」</strong>動きと見るべきかもしれない。 なぜこうなるのか——開発者視点の現実 HNのコメント欄では「怠惰な開発者の問題」という指摘が多い。実際、Firefoxのシェアはすでに約2〜3%まで落ちており、「IE6やIE11を切り捨てたときと同じ話だ」という声もある。 ただし、IEとFirefoxを同列に語るのは誤りだ。 - IEはプリインストールされていたが、Firefoxは意図的に選択したユーザーが使っている - IEはクロスブラウザ対応が技術的に困難だったが、Firefoxはモダンな標準実装でほとんどのWebサイトで動く - Firefoxをブロックするほとんどのケースは「UserAgent文字列のチェックが雑」なだけで、実際には動作する 今すぐできる回避策:User-Agent偽装 投稿者本人がスレッド内で有効な対処法を紹介している。User-Agent Switcherアドオン(Firefox公式アドオンストアで入手可)を使い、UAを「Windows / Chrome 146」に偽装するだけで、多くのChrome限定サイトが動作するようになる。 ` 手順: 1. Firefox Add-ons から「User-Agent Switcher」をインストール 2. ツールバーのアイコンをクリック 3. 「Windows / Chrome 146」などを選択 4. ページをリロード ` これが機能するという事実は、そもそもサイト側に技術的な理由がないことを示している。単純なUA文字列チェックによる排除なのだ。 「ChromeがIEになっている」という皮肉 スレッドの中で最も刺さるコメントがこれだ。「Chrome is the new IE!」——かつてIEの独占に抗ってFirefoxが生まれたように、今度はChromeが事実上の標準となり、他ブラウザを排除し始めている。 Webの多様性・オープン性の観点からすると、これは深刻なトレンドだ。ブラウザエンジンの多様性が失われれば、GoogleがWebの仕様を事実上コントロールする状況が加速する。Mozillaが弱体化し、Firefoxのシェアがさらに下がれば、この悪循環は止まらない。 まとめ Firefoxが「非対応」とされる現象は、技術的な問題ではなく開発コストとシェアのトレードオフが生んだ怠惰の結果だ。UA偽装で大半は回避できるが、それが必要という時点でWebの健全性が問われている。Firefoxを使い続けること自体が、オープンWebへの小さな投票だと思っている。

📝
Qiita

New Relicのユーザー管理を完全理解|Organization・Account・Role の設計方針と操作手順

New Relicの導入初期に「とりあえず」でユーザーを追加してしまい、後から権限設計が崩壊するのはあるあるの失敗。Organization・Account・Role の概念を整理してから動く、という順序を丁寧に解説している点が実践的で価値が高い。

New Relicを導入したはいいけれど、「ユーザー管理をちゃんとしよう」と思った瞬間に用語の多さで思考停止した経験はないだろうか。Organization / Account / Group / User / Role という5つの概念が絡み合い、どこから手をつければいいかわからなくなる——そんな管理者の悩みにまっすぐ答えてくれるのが本記事だ。 まず「構造設計」から始める New Relicのユーザー管理で最初につまずくのは、「いきなり設定画面を開いてしまう」ことだ。本記事が強調しているのは、運用を開始する前に方針を決めるという順序の大切さ。具体的には以下の3つの観点で整理する。 - <strong>Organization(組織)の分割方針</strong>: Organizationを分けると契約と請求も分かれる。プロジェクト単位で厳密に費用を分離したい場合のみ検討する - <strong>Account(アカウント)の分割方針</strong>: Accountはデータ参照の境界になる。本番/開発などの環境別、あるいは複数システムを管理する組織・システム別でアカウントを分けるのが基本 - 機能制限の方針: 一部機能だけ使わせたい場合は、専用のカスタムロールを作ってパーミッションを絞り込む Accountが増える見込みがあるなら、最初からprod-やdev-といったシステム名や環境名をプレフィックスとして命名規則に組み込むと後々管理が楽になる。 アカウント作成の手順 アカウントの作成は管理画面(Administration)から行う。 ` 1. 右上のアイコン → Administration を開く 2. 左メニュー「Access Management」を選択 3. 「Accounts」タブ → 「Create account」ボタン 4. アカウント名を入力して作成 ` 注意点として、アカウントは無効化できるが削除できない。一度作成したら残り続けるため、命名と用途の設計は慎重に。アカウント名は後から変更可能なので、最初は大まかなルールで始めてもOKとのことだ。 ユーザー管理方式の選択肢 管理者がユーザーをどう管理するかも重要な設計ポイントだ。New Relicが提供するのは主に3つの方式。 - New Relic UIで直接管理: 小規模チーム向け。シンプルで即座に始められる - <strong>SSO(シングルサインオン)連携</strong>: 既存のIDプロバイダー(Okta・Azure AD等)と統合。認証を一元化したい場合に有効 - <strong>SCIM(自動プロビジョニング)</strong>: ユーザーの追加・削除をIDプロバイダー側から自動化。大規模組織での管理工数を大幅に削減できる SSOやSCIMは初期設定のハードルはあるが、組織規模が50人を超えるなら投資する価値は高い。 所感:「設計先行」が可観測性運用の質を決める New Relicに限らず、オブザーバビリティツールのユーザー管理は「後回しにしがちだが後から直すのが大変」な領域の筆頭だ。本記事が示す「まず方針を決める→アカウント設計→ユーザー管理方式の選択」というステップは、スタートアップから大企業まで普遍的に使える思考フレームだと感じた。New Relicを使い始めたチームや、すでに運用しているが管理が煩雑になってきたチームに、ぜひ一度通しで読んでほしい内容だ。

🔥
Zenn

「質とスピードはトレードオフ」は誤解だった——t-wadaさん講演から学ぶ内部品質の本質

「質かスピードか」の二択で悩んでいるエンジニア・Tech Leadに直接刺さる内容。t-wadaさんの講演を単なるレポートに留めず、AI時代における内部品質の再定義まで踏み込んでいる点が秀逸。

「今はスピード優先でいこう」「品質は後で整えればいい」——開発現場でこういう判断を下したことがある人は多いはずだ。しかし、その積み重ねが開発速度を落とす元凶になっているとしたら? 2026年2月、GENIEEが開催した社内勉強会でt-wada(和田卓人)さんが語った内容は、まさにその「前提」を根底から揺さぶるものだった。 削られているのは「外部品質」ではなく「内部品質」 講演でまず整理されたのは、「品質」という言葉の曖昧さだ。品質には大きく分けて以下の3層がある。 - 利用時の品質:ユーザーが実際に使う際の体験・満足度 - 外部品質:バグの少なさ・動作の正確さなど外から見える品質 - 内部品質:コードの保守性・理解しやすさ・変更しやすさ・テストしやすさ 現場で「品質を少し落としてでも急ごう」と言うとき、犠牲になっているのはユーザーに見える品質ではなく、開発チームが日々向き合う内部品質だ。特に削られやすいのが「理解しやすさ」「変更しやすさ」「テストしやすさ」の3つ。短期的には機能を出せてしまうため後回しにしやすいが、これが蓄積すると調査・レビュー・手戻りコストとして現場に返ってくる。 品質を保っているから速い、という逆転の発想 講演の核心は「質とスピードは本質的なトレードオフではない」という主張だ。コードが理解しやすく・変更しやすく・テストしやすい状態であれば、実装・修正・レビューにかかるコストは下がる。逆に保守性が低下すると、実装そのものより調査と確認と手戻りに時間を奪われる。 > 品質を保っている「にもかかわらず」速いのではなく、品質を保っている「からこそ」速い。 このフレーミングの転換は強烈だ。「今は急ぐから後で整える」という判断は、現場では合理的に見える。しかし実際にはその判断の瞬間から速度が落ち始めているという構造を、t-wadaさんは丁寧に解説した。 内部品質への投資は思ったより早く効く 「内部品質を整えても効果は数年後」と思いがちだが、講演ではそれも誤解として指摘されている。テスト自動化の損益分岐点は概ね3〜4回の実行で訪れることが多く、内部品質改善の効果は1か月以内に見え始めることもある。そして2026年現在、コーディングエージェントの登場により、その差分は数日〜1週間程度まで前倒しされつつあるという。 さらに興味深いのはAI時代における内部品質の重要性だ。「AIが外から品質を担保するなら内部品質は不要では?」という問いに対し、t-wadaさんはこう答えた——コーディングエージェントが出すコードの質は既存コードベースの規模と品質に強く影響される。結合度が高いほど変更コストが高く、AIも手こずる。AIとも「理解しやすさ・変更しやすさ・テストしやすさ」を共有しながら高い内部品質を保つほうが、結局は速くスケールする。 Q&Aで語られた「明日から使える実践」 講演後の質疑で印象的だったアドバイスを抜粋する。 既存システム改善は段階的に<strong>: 大規模モダナイゼーションは成功確率が低い。王道は「一定の投資を継続しながらじわじわ改善」。AIは大規模書き換えよりも、</strong>調査・影響範囲把握などの「読む」作業に実戦投入できる段階にある。大規模レガシーは実はコードを書く時間より調査時間のほうが長い——そこにAIを活用するのが現実的だ。 自分でコードを書くのをやめない<strong>: AIが書く割合が増えても、「AIが出した3つの方針のどれを選ぶか」「何か変だと気づいて方向修正できるか」という</strong>判断力が競争力になる。その力は自分で書いてフィードバックを受ける中でしか鍛えられない。AIを使い倒すことと、自分で筋トレすること——両方続けるのが最強。 所感:「地道なことを高速に回す」時代 t-wadaさんがQ&Aで発した「AI時代は、地道なやり方を高速に回せるようになった」という言葉が刺さった。派手なアーキテクチャ変換よりも、テストを書き・コードを整理し・少しずつ改善するという職人的な積み重ねがより速く効くようになった時代。それが2026年の現在地なのだと感じた。 品質は美意識や職人性の話ではなく、開発生産性そのものに直結するテーマだ。この視点を持って日々の開発判断に臨みたい人に、元記事はぜひ一読してほしい。スライド原典も含めて丁寧にまとめられている。

🛠️
Simon Willison

datasette-showboat 0.1a2リリース — Markdownエクスポートでリモートへの差分配信が可能に

Datasette エコシステムに差分配信の仕組みが入ってきた点が興味深い。SQLiteベースのデータをMarkdown経由でリモート配信するパターンは、個人開発の静的サイト運用にそのまま応用できそうで要注目。

Simon Willison が開発する datasette-showboat のバージョン 0.1a2 がリリースされた。今回のアップデートで追加された機能は小さいが、使い方次第でローカルデータの公開フローを大きく変えるかもしれない。 datasette-showboadとは何か datasette-showboat は、オープンソースのデータ探索ツール Datasette 向けのプラグインだ。SHOWBOAT_REMOTE_URL という環境変数と連携し、Datasette 上で管理・閲覧しているデータやコンテンツをリモートサーバーへ配信する仕組みを提供する。Datasette 自体は SQLite データベースをブラウザで即座に公開・検索できるツールとして知られており、Simon Willison が長年メンテしている代表的なOSSプロジェクトのひとつだ。 今回の変更点:Markdownエクスポートによる差分配信 0.1a2 のポイントはシンプルだ。 - Markdown ファイルのエクスポート機能を追加 - エクスポートしたファイルを使って、<strong>リモートサーバーへのインクリメンタル(差分)配信</strong>が可能になった - 全件再送信ではなく「更新分だけ」を送れるため、帯域・コスト・時間を節約できる この「差分配信」というアプローチは、ブログやドキュメントサイトの静的ホスティングでよく見られるパターンだが、Datasette のデータパイプラインに組み込めるのが新鮮だ。ローカルで SQLite に溜めたデータを Markdown に変換して、そのまま Netlify や Cloudflare Pages、あるいは自前サーバーに差分アップロードするユースケースが想定できる。 実際の使い方イメージ インストールは Datasette のプラグイン機構で行う。 `bash datasette install datasette-showboat ` その後、SHOWBOAT_REMOTE_URL に配信先URLを設定し、アプリ内のエクスポートオプションから Markdown ファイルを出力、リモートに送信する流れになる。現時点ではアルファ版(0.1a2)のため、APIや挙動は変わる可能性があるが、Simon のプロジェクトらしく実用的な方向に素早くイテレーションされていくはずだ。 所感 まだアルファ段階とはいえ、<strong>「Datasette をデータ配信のバックエンドとして使う」</strong>という発想は面白い。SQLite+Datasette+静的サイトという組み合わせは、サーバーレスでコストを抑えながら動的データを扱いたい個人開発者やスモールチームにとって魅力的な選択肢だ。Simon Willison のブログや GitHub を追っておくと、このプロジェクトの方向性がより見えてくるだろう。

🟠
Hacker News

AIエージェントにファイルを消される前に:Linux軽量サンドボックス「jai」の使い方と仕組み

AIエージェントによるファイル消失事故が実際に多発しているいま、ワンコマンドで導入できる現実解として注目したい。Docker不要でCoWオーバーレイという設計のスマートさも、Linux使いには刺さるはず。

「AIに頼んだら、ホームディレクトリが丸ごと消えた」——これはもはや笑えない話だ。Claude Code、Cursor、CodexといったAIコーディングエージェントをローカルマシンで使っている人なら、この恐怖は他人事ではない。実際にGitHub IssueやRedditには「15年分の家族写真が消えた」「開発プロジェクトがすべて吹き飛んだ」「100GBを削除された」といった被害報告が続々と上がっている。 そんな状況に対して、スタンフォード大学のSecure Computer Systems研究グループが開発したのが jai(ジェイ)だ。Dockerイメージも不要、Dockerfileも不要、複雑なbwrapの呪文も不要。ワンコマンドでAIエージェントを「ゆるく封じ込める」ためのLinux向け軽量サンドボックスツールである。 jaiの仕組み:Copy-on-Writeオーバーレイ jaiの核心は <strong>Copy-on-Write(CoW)オーバーレイ</strong> にある。動作の流れはシンプルだ: - <strong>カレントディレクトリ(CWD)</strong>:フルの読み書きアクセスを維持 - ホームディレクトリ:変更はオーバーレイに記録され、オリジナルは一切触れない - /tmp・/var/tmp:プライベートな独立空間 - その他のファイル:読み取り専用でロック 使い方はプレフィックスをつけるだけ: `bash Claude Codeをサンドボックス内で起動 jai claude Codexをサンドボックス内で起動 jai codex サンドボックス内のシェルを起動 jai ` 3つのモードで用途別に使い分け jaiはCasual・Strict・Bareの3モードを提供している: - <strong>Casual(カジュアル)</strong>:ホームはCoWオーバーレイ。自分のユーザーで動作。機密性は弱いが整合性は保護される。日常的なコーディング補助に最適 - <strong>Strict(ストリクト)</strong>:別の非特権ユーザーで動作し、空のプライベートホームを使用。機密性・整合性ともに強力。NFSホームは非対応 - <strong>Bare(ベア)</strong>:ホームを完全に隠蔽。自分のUIDで動作。インストーラースクリプトの検証実行などに向く なぜDockerやbwrapではなくjaiなのか 「Dockerでいいじゃないか」という意見はもっともだが、jaiが狙うのはDocker以前の手軽さ<strong>だ。イメージビルドが不要で、ホストのツールをそのまま使える。bwrap(bubblewrap)は強力だが、ファイルシステムビューを明示的に組み立てる必要があり、結局長大なラッパースクリプトになりがち。</strong>「コンテナより気軽じゃないなら、誰もやらない」——これがjaiの設計哲学だ。 注意点:jaiは「完全な安全」ではない プロジェクト自身が明記しているが、jaiはblast radiusを減らすカジュアルサンドボックスであり、完全な安全を保証するものではない。Casualモードは機密性を保護しない(多くのファイルが読み取り可能)。マルチテナント環境や高度な攻撃者への対策には、ハードニングされたコンテナやVMを使うべきだ。あくまで「何もしないよりは格段にマシ」という位置づけである。 フリーソフトウェアとして公開されており、スタンフォードの研究グループが「AIをより安全に使ってもらうこと」を目標に開発している点も信頼感がある。AIエージェントをローカルで走らせている全てのLinuxユーザーにとって、導入のハードルは限りなく低い。まず jai を使ってみるところから始めてほしい。

🔥
Zenn

ソフトウェアテストの「本質」を古典から学ぶ——1949年チューリングから現代JSTQBまでの思想的系譜

テストの「定義」が時代ごとにどう変わってきたかを一次資料で追う稀有な記事。JSTQB受験準備中の方だけでなく、テスト設計に関わるすべてのエンジニアが自分の立ち位置を確認するために読んでおきたい。

テストってそもそも何をするものなのか、ちゃんと説明できますか? 「バグを見つけること」——それが答えだと思っていたが、実はその定義自体が時代と共に劇的に変化してきた。Zennに掲載されたmima_itaさんの記事「ソフトウェアテストの古典から現在まで」は、1949年のチューリングの論文から現代のISTQB/JSTQBまで、テストという概念の思想的進化を一次資料を辿りながら整理した力作だ。テスト設計をする機会があるなら、この系譜を知っておいて損はない。 テストの進化5段階——「動くことを示す」から「欠陥を未然に防ぐ」へ 1988年にGelperinとHetzelが発表した The Growth of Software Testing では、ソフトウェアテストの進化を5つの時期に整理している。 - デバッグ志向期:テストとデバッグの区別がなく、「バグを取り除くあらゆる活動」がテストだった - 実証志向期:「プログラムが正しく動くことを確かめる」——テストは成功を示すもの - <strong>破壊(欠陥検出)志向期</strong>:「エラーを見つける意図を持って実行するプロセス」——Myers の名著 The Art of Software Testing(1979)がこの転換点 - 評価志向期:レビュー・分析を含む VV&T(Validation, Verification & Testing)がライフサイクル全体に拡大 - 予防志向期:テスト設計を早期から重視し、要求・設計段階での欠陥防止を重視 この流れを知ると、「なぜ現代のテストでは設計フェーズからQAが関与するのか」が腑に落ちる。ウォーターフォールの末端にテスターがいた時代から、シフトレフトが叫ばれる現代まで、思想の連続性が見えてくる。 一次資料で読む「テストの古典」 記事が特に価値を発揮するのは、一次資料への丁寧な言及だ。いくつかピックアップしたい。 <strong>Alan M. Turing「Checking a Large Routine」(1949)</strong> 大規模ルーチンの正当性証明を論じた最初期の論文。後の形式的検証(Formal Methods)に通じる発想がある。テストの起源がここまで遡れるという事実だけで読む価値がある。 <strong>Glenford J. Myers「The Art of Software Testing」(1979)</strong> この本が提示したフレーズ—— > Testing is the process of executing a program with the intent of finding errors. ——が、支配的だった「動くことを示すプロセス」からの決定的な転換を宣言した。A Self-Assessment Test という演習はテストケース設計者なら全員挑戦すべきと著者は評している。2011年改訂版ではアジャイル・Webアプリ・モバイルのテスト章も追加されており、今でも2冊目の教科書として推薦できる。 <strong>Boris Beizer「Software Testing Techniques」(1983)</strong> パステスト・データフローテスト・状態遷移テストなどの技法を体系化した書籍。邦訳タイトルは『ソフトウェアテスト技法——自動化、品質保証、そしてバグの未然防止のために』。2版ではテスト設計こそがバグ防止において実行より効率的という主張が加わり、予防志向への移行を示している。 現代のスタート地点——JSTQB と ISO/IEC/IEEE 29119 「今のソフトウェアテストの概念」を把握したいなら、まず <strong>JSTQB(Japan Software Testing Qualifications Board)</strong> のシラバスが出発点になる。CTFLv4.0は日本語で無料公開されており、現代のテスト概念・用語が体系的に整理されている。 規格レベルでは ISO/IEC/IEEE 29119<strong> シリーズ(テストプロセス・文書・技法)が基準となるが、IEEEは有料。一方 </strong>JIS X25010<strong>(品質モデル)は日本産業標準調査会でユーザー登録すれば無料で閲覧できる。また </strong>SQuBOK(Software Quality Body of Knowledge) は規格・手法・概念を横断して体系化されており、全体像を掴む入り口として有用だ。 まとめ——「テストとは何か」を問い直す価値 テストの思想は「動くことを示す」→「壊す意図で実行する」→「ライフサイクル全体で予防する」と変化してきた。現代のシフトレフト・TDD・契約による設計といったプラクティスは、この進化の延長線上にある。 古典を読むのは懐古趣味ではなく、なぜ今の手法がこの形になっているのかを理解する近道だ。JSTQBを受験しようとしている人はもちろん、「テストを書いてはいるけど設計の意図まで考えたことがなかった」というエンジニアにも、元記事が指し示す一次資料の系譜を辿る読書体験を強くすすめたい。

🟠
Hacker News

ISBNの宇宙を可視化する——Anna's Archiveが世界の書籍データを地図にした

書籍の識別番号「ISBN」の全空間を視覚的にマッピングするというアイデアが純粋に面白い。データビジュアライゼーションや出版・図書館情報学に興味のある人はもちろん、「世界に何冊の本が存在するのか」という問いを持ったことがある人なら誰でも引き込まれる作品だ。

「この本、本当に存在するのか?」という問いに、番号の地図で答えようとするプロジェクトがある。Anna's Archive<strong>(影の図書館と称される書籍メタデータ横断検索エンジン)が公開した </strong>ISBN Visualization は、世界中の書籍に割り振られたISBN番号空間を視覚的にマッピングした試みだ。書籍に興味のある開発者・司書・データエンジニアにとって、これは単なる「きれいな図」ではなく、出版業界の構造をそのまま映し出す鏡となっている。 ISBNとは何か——13桁に込められた出版の秩序 <strong>ISBN(国際標準図書番号)</strong>は、書籍を一意に識別するための国際規格だ。現在主流の ISBN-13 は以下の構造を持つ: ` 978 - 4 - 10 - 109205 - 0 │ │ │ │ └ チェックディジット │ │ │ └─── 書名コード(タイトル識別) │ │ └──────── 出版社コード │ └───────────── 国・地域・言語グループ(4 = 日本語) └─────────────────── プレフィックス(978 or 979) ` - 978プレフィックス:従来のISBN-10からの移行組 - 979プレフィックス:需要増加に伴い拡張された新領域 - 日本語書籍は 978-4- または 979-12- などで始まることが多い - 割り当て可能なISBN総数は約100億冊分に及ぶ Anna's Archiveが可視化した「番号空間の実態」 Anna's Archiveは、Sci-Hub・LibGen・Z-Libraryなどを横断してメタデータを収集・統合し、現時点で 数千万冊規模の書籍カタログを構築している。今回の可視化は、そのデータを使ってISBN番号空間の「どこが埋まっていて、どこが空白か」を一望できるようにしたものだ。 注目すべきポイントは以下の通り: - 出版社の集中度:大手出版社は連続したISBNブロックを持つため、可視化上で塊として現れる - 国・言語ごとの密度差:英語圏は圧倒的な密度、他言語圏との格差が一目でわかる - 未割り当て番号の分布:番号空間はスカスカではなく、規則的なパターンを持つ - デジタル化・索引化の進捗:Anna's Archiveが実際にアクセス可能な書籍の割合を色分けで示す こうした可視化は「知識のデジタルデバイド」を数値ではなく視覚的に突きつける力がある。 技術的にどう作るか——ISBNビジュアライザの実装アプローチ このような可視化を自分で試みるとすれば、以下のようなアプローチが考えられる: `python ISBNの番号空間をビットマップ的に可視化するイメージ import numpy as np import matplotlib.pyplot as plt ISBN-13の978プレフィックス帯をサンプリング 実際には大規模DBからの集計が必要 isbn_space = np.zeros((1000, 1000)) # 100万冊分のサンプル 既知のISBNをプロット(0=未確認, 1=存在確認, 0.5=メタデータのみ) for isbn, status in isbn_database.items(): idx = isbn_to_index(isbn) isbn_space[idx // 1000][idx % 1000] = status plt.imshow(isbn_space, cmap='viridis', interpolation='nearest') plt.title('ISBN Space Coverage') plt.colorbar(label='Coverage Status') plt.show() ` Anna's Archiveの実装はおそらくWebベースのインタラクティブな可視化(D3.jsやWebGLベース)で、ズームイン・アウトしながら任意のISBN帯を探索できる設計になっていると思われる。 まとめ——番号の地図が語るもの ISBNの可視化は「書籍が存在する」ことと「デジタルでアクセスできる」ことの乖離を浮き彫りにする。Anna's Archiveの取り組みは法的・倫理的議論を常に伴うが、技術的・学術的観点では世界最大規模の書誌データインフラを構築しているという事実は無視できない。図書館員・出版業界・オープンナレッジ活動家のいずれにとっても、ISBNという番号体系がいかに「知識の地図」として機能しているかを再考するきっかけになるはずだ。元の可視化は https://annas-archive.gd/isbn-visualization で直接体験できる。

📝
Qiita

VSCode更新後に配色・シンタックスハイライトが崩れたときの原因と直し方

「VSCode更新後 色 おかしい」で検索してここに辿り着くエンジニアが多そうな、あるある系トラブル記事。テーマ固定の方法やSettings Syncまで補足したので、再発防止まで一気に解決できる内容に仕上げた。

VSCodeをアップデートしたら急にエディタの見た目がおかしくなった――そんな経験はないだろうか。Pythonのコードが色分けされなくなった、全体的にテーマがくすんだ、以前と雰囲気が変わった……これらはすべて カラーテーマの意図せぬ変更 が原因である可能性が高い。 なぜ更新後にテーマが変わるのか VSCodeのメジャー・マイナーアップデートでは、見た目に関する設定がリセットされることがある。具体的には以下のケースが多い: - デフォルトテーマが Default Dark Modern や Visual Studio Dark に上書きされる - 拡張機能(特にテーマ系)が更新されて設定が競合する - settings.json のスキーマ変更により一部設定が無効化される とりわけ Pythonのシンタックスハイライト は、テーマ側の tokenColors に依存しているため、テーマが変わると一気に色が飛んで見えることがある。 確認・解決手順 1. カラーテーマを確認・変更する ` Ctrl + Shift + P(macOSは Cmd + Shift + P) →「配色テーマ」または「Color Theme」と入力 → 一覧から好みのテーマを選択 ` 元のテーマが何だったか覚えていない場合は、以下の人気テーマを試してみるとよい: - Default Light+ / Default Dark+(VSCode標準) - One Dark Pro(暗め・コントラスト高め) - GitHub Theme(明るく読みやすい) - Dracula Official(鮮やかな配色) 2. settings.json でテーマを固定する アップデートのたびに変わるのを防ぐには、settings.json に明示的に記述しておくと安心だ: `json { "workbench.colorTheme": "One Dark Pro" } ` Ctrl + Shift + P → 「設定を開く(JSON)」 で直接編集できる。 3. Python拡張機能のシンタックスハイライトが消えた場合 テーマを戻してもPythonの色分けが復活しない場合は、Pylance や Python 拡張機能のバージョンも確認しよう。拡張機能の更新が絡んでいることもある。 ` Ctrl + Shift + X → 「Python」で検索 → バージョン確認・再インストール ` VSCode更新後にチェックすべき設定 テーマ以外にも、アップデート後に変わりやすい設定は以下の通り: - フォント設定(editor.fontFamily / editor.fontSize) - 自動保存(files.autoSave) - ミニマップ表示(editor.minimap.enabled) - 拡張機能の有効/無効状態 更新前に settings.json をバックアップしておくか、Settings Sync(VSCode標準のGitHub連携機能)を使えば設定をクラウドに同期できるので、次回のアップデート後もすぐに元の環境に戻せる。 まとめ VSCodeの配色が崩れた場合、まず疑うべきは カラーテーマの変更<strong> だ。Ctrl + Shift + P → 「配色テーマ」の手順で確認・復元できる。再発防止には settings.json への明示的な記載と </strong>Settings Sync の活用が効果的。細かい設定が積み重なって作り上げた開発環境が、アップデートひとつでリセットされるのは本当に地味にストレスなので、バックアップの習慣もついでに持っておきたい。

🟠
Hacker News

Velxio 2.0 とは?ブラウザでArduino・ESP32・Raspberry Piを動かせる無料エミュレーター【ハードウェア不要】

ハードウェアなしでArduinoやRaspberry Piを動かせるというアイデアは、IoT入門者や教育現場にとって革命的。19ボード対応というスペックも本気度が伝わる。

「Arduinoを試してみたいけど、まだボードを持っていない」「ESP32の動作を手軽に検証したい」——そんなエンジニアや学習者に刺さるOSSが登場した。Velxio 2.0 は、ブラウザ上でArduino・ESP32・Raspberry Piなどのマイコンボードをエミュレートできる無料ツールだ。 Velxio 2.0 とは Velxioは、実機なし・クラウドなし・インストールなしで、19種類のリアルボードをブラウザ内でエミュレートできるプラットフォームだ。コードの記述・コンパイル・実行までをブラウザだけで完結できる。対応ボードの一部を挙げると: - Arduino Uno - ESP32 / ESP32-C3 - Raspberry Pi Pico - Raspberry Pi 3 - その他、計19種類のボードに対応 GitHubでオープンソースとして公開されており、Discordコミュニティも存在する。 なぜ重要か:ハードウェアの壁をなくす 組み込み開発・IoT学習の最大の障壁のひとつが「実機の入手コスト」と「環境構築の煩雑さ」だ。Arduino IDEのセットアップ、ドライバインストール、書き込みエラーのトラブルシューティング……これらは入門者が途中で諦める主な原因になっている。 Velxioはこの壁を完全に取り払う。ブラウザを開くだけで、本物に近い挙動でコードを動かせる環境が整う。教育現場・ハンズオン講座・プロトタイプ検証など、幅広いシーンで活躍できる。 実際の使い方イメージ Velxioはブラウザ上で以下のようなフローを実現する: ` 1. ブラウザでVelxioを開く 2. エミュレートしたいボード(例: Arduino Uno)を選択 3. コードエディタにスケッチを記述 4. コンパイル → エミュレーター上で実行 5. シリアルモニタ・LEDの点滅など、仮想ボードの反応を確認 ` たとえばArduinoの定番「Lチカ」をブラウザ上で動かしたり、ESP32のWi-Fi処理を手元で試したりといったことが、実機ゼロで可能になる。 まとめ・所感 Velxio 2.0は、組み込み・IoT開発の「入門コスト」を劇的に下げる可能性を持ったツールだ。特にRaspberry Pi 3のエミュレーション対応は珍しく、Linuxベースのシングルボードコンピュータをブラウザで試せる点は注目に値する。Hacker Newsでも話題になっており、今後の機能拡張が期待される。実機購入前の下調べや、授業・勉強会での活用にぜひ試してみてほしい。GitHubリポジトリ(davidmonterocrespo24/velxio)からすぐにアクセスできる。

🌐
web.dev

2026年3月にブラウザへ追加されたWeb新機能まとめ — スクロールアニメーションCSSネイティブ対応など

CSSだけでスクロールアニメーションが書けるようになるのは地味に革命的で、IntersectionObserverのボイラープレートから解放される日が近づいてきた。コンテナクエリの名前指定も3ブラウザ揃って実用段階に入ったので、デザインシステム構築者には今すぐ試してほしい内容。

毎月恒例のweb.devによるブラウザ新機能まとめ。2026年3月は Chrome 146・Firefox 149・Safari 26.4 がそれぞれStableリリースされ、フロントエンド開発に直結する注目機能がいくつか着地した。「CSSでスクロールアニメーションってどうやるの?」「コンテナクエリの名前だけ指定できる?」といった疑問を持っている人はぜひ読んでほしい。 スクロールトリガーアニメーションがCSSネイティブに(Chrome 146) Chrome 146 で待望の Scroll-triggered animations<strong>(スクロール連動アニメーション)が正式サポートされた。これまでIntersection ObserverやJavaScriptのscrollイベントで頑張っていた実装が、</strong>CSSだけで宣言的に書けるようになる。 最大のメリットはパフォーマンス。アニメーション処理がワーカースレッドにオフロードされるため、メインスレッドのJavaScriptがブロックされてもアニメーションが滑らかに動く。JavaScript APIも用意されており、Web Animations APIと組み合わせた細かい制御も可能だ。 `css / スクロール位置に連動してopacityをアニメーション / @keyframes fade-in { from { opacity: 0; transform: translateY(20px); } to { opacity: 1; transform: translateY(0); } } .card { animation: fade-in linear; animation-timeline: view(); / ビューポートへの進入を監視 / animation-range: entry 0% entry 50%; / 進入開始〜50%で完了 / } ` これだけでスクロールに合わせた出現アニメーションが完成する。animation-timeline: scroll() を使えばページ全体のスクロール量に比例した進捗バーなども簡単に作れる。 コンテナクエリに「名前だけ指定」が可能に(Firefox 149・Safari 26.4) Firefox 149 と Safari 26.4 が揃って <strong>名前のみのコンテナクエリ(Optional container query conditions)</strong> に対応した。Chrome はすでに先行対応済みのため、これで主要3ブラウザが出揃ったことになる。 従来の @container クエリはサイズや style() などの条件が必須だったが、今回から条件なしで名前だけを指定できるようになった。 `css / コンテナを名前付きで定義 / .sidebar { container-name: sidebar; container-type: inline-size; } / 名前だけでマッチ(サイズ条件不要)/ @container sidebar { .widget { font-size: 0.875rem; padding: 8px; } } ` これにより「このコンポーネントがサイドバーの中にある場合」というコンテキスト依存スタイルが、サイズを問わず適用できる。デザインシステムで「どのコンテナに入るかでスタイルを変えたい」ケースで特に有用だ。 まとめ・所感 今月のアップデートで特に注目したいのはスクロールアニメーションのCSS化だ。JavaScriptへの依存を減らしつつパフォーマンスも改善できる一石二鳥の機能で、ランディングページやポートフォリオサイトの実装が大きく変わりそうだ。コンテナクエリの名前指定もFirefox/Safariへの普及が完了し、実運用に使えるフェーズに入った。詳細は web.dev の原文記事 で各機能のブラウザサポート表や追加リンクが確認できる。

🟠
Hacker News

ブラウザで動くSFXシンセサイザー「Knell」— WASMとZigで実現したリアルタイム音響合成

ZigをWASMにコンパイルしてブラウザ上で音響合成するという構成が技術的に面白い。ゲーム開発者やWASM/Zigを試したいエンジニアに特にお勧めしたい一本。

「ブラウザだけで本格的なSFXを作れないか?」と思ったことのある開発者に刺さる話だ。Knellは、<strong>WebAssembly(WASM)</strong>とZig言語を組み合わせてブラウザ上で動く効果音シンセサイザーで、インストール不要・プラグイン不要でリアルタイムの音響合成を実現している。 なぜWASM × Zigなのか オーディオ処理はCPUに高い負荷をかける計算集約型の処理だ。JavaScriptだけでは遅延やドロップアウトが発生しやすく、本格的なリアルタイム合成には向かない。そこで登場するのが WebAssembly — ブラウザ上でネイティブに近い速度でバイナリを実行できる技術だ。 一方の Zig は、C言語の後継として注目される低レベルシステム言語。C ABI互換でありながら、メモリ安全性の改善や明示的なエラーハンドリング、ビルドシステムの内包など現代的な設計が特徴だ。ZigはWASMターゲットへのコンパイルを公式にサポートしており、音響処理エンジンをWASMとして出力するのに適している。 ` Zigでのwasm32ターゲットビルドイメージ zig build-lib src/synth.zig \ -target wasm32-freestanding \ -O ReleaseFast ` SFXシンセサイザーとしての使いどころ Knellはゲーム開発・インディーゲーム・チップチューンなど、<strong>効果音(SFX)を自作したい開発者やクリエイター</strong>を主なターゲットにしていると思われる。ブラウザベースの強みは以下の通り: - 即時アクセス — URLを開くだけで使える(https://knell.medieval.software/studio) - クロスプラットフォーム — OS・環境を問わず動作 - 低レイテンシ — WASMによる高速処理でリアルタイム応答 - 共有・埋め込みのしやすさ — パラメータをURLに持てれば音色の共有も容易 この種のツールの先駆けとして sfxr や jsfxr があるが、ZigとWASMという現代的なスタックで実装し直した点が新しい。 技術スタックの面白さ Zigでオーディオエンジンを書いてWASMにコンパイルし、Web Audio APIと組み合わせるアーキテクチャは、Rustを使わずとも高性能なブラウザ音響処理が実現できることを示す好例だ。Zigの comptime(コンパイル時計算)を活用したウェーブテーブルや定数テーブルの生成なども、オーディオ用途では有効に働く。 Hacker Newsに登場したことで、「ZigをWASMターゲットとして使う実例」として開発者コミュニティから注目を集めている。ゲームエンジン・WebAudio・低レベル言語に興味がある人は、ソースコードやアーキテクチャを追ってみる価値がある。 まとめ Knellは単なるSFXツールにとどまらず、「ZigでWASMを書く」という実践的なユースケースを示したプロジェクトとして技術的に興味深い。インディーゲームの効果音作成にすぐ使えるだけでなく、WASM × 音響処理の実装を学ぶ参考にもなる。まずは スタジオを開いて 音を出してみるのが一番の入門だ。

🟠
Hacker News

AIが書いたext4ドライバをOpenBSDに投稿したら何が起きたか——LLM生成コードの著作権問題が炸裂

「AIが書いたコードに著作権は存在するか」という抽象論が、実際のOSSプロジェクトでリジェクトという形で顕在化した歴史的な事例。LLMをコード生成に使っているすべての開発者が知っておくべき論点が凝縮されている。

「AIが書いたコードの著作権は誰のものか?」——この問いは法律家も答えを持っていない。2026年3月、OpenBSDのメーリングリストで起きた一件は、その問いをOSSコミュニティに突きつける格好の事例となった。 事の発端:ChatGPT+Claude製のext4実装 Thomas de Grivel氏が OpenBSDのopenbsd-techメーリングリスト に、Linuxのext4ファイルシステムをOpenBSD向けに実装したパッチを投稿したのが3月17日。読み書き両対応、e2fsckも通過するというなかなかの完成度だ。ただし ジャーナリング非対応。 コード自体には著作権表示があったが、「どうやって書かれたか」は明記されていなかった。しかし別途公開したブログ記事で本人はこう明かした: > Linuxのソースファイルは一切読んでいない。純粋にAI(ChatGPTとClaude Code)と、自分による丁寧なコードレビュー・エラーチェック・ビルド・テストで作った。 なぜ問題になるのか:3つの地雷 この投稿には複数の問題が折り重なっていた: - GPL汚染リスク:LLMがLinuxのext4実装(GPL)を学習している以上、生成物が派生物とみなされる可能性がある - ドキュメント問題:ext4の仕様ドキュメント自体がGPL下のwikiページを参照しており、「知識」レベルでの汚染を指摘する声も - 著作権の帰属不明:これが最大の論点。AIが生成したコードの著作権は誰に帰属するのか? Theo de Raadtの見解:「著作権が存在しない」 OpenBSDの創設者 Theo de Raadt は、アルゴリズムや構造の再実装は著作権法上許容されると指摘しつつも、こう断言した: > 現時点では、ソフトウェアコミュニティも法律コミュニティも、AIが生成した成果物が「AIを操作した人間」によって著作権を主張できるとは認めていない。AIや AI企業も、著作権条約・法律上、著作権者として認められていない。 > > つまり今日現在、著作権制度は「非人間が生成したファイル群」に対して、OpenBSDが再配布に必要な権利を付与する手段を持っていない。 Damien Miller も同様に「著作権者が誰なのか特定できない」と述べた。訓練データに含まれるコードを書いた人々なのか、AIを所有する企業なのか——法律がテクノロジーに追いついていない状態では、後からリスクが顕在化したときに手遅れになりかねない。 OSSプロジェクトが直面する現実的なリスク この件が示すのは、単なるOpenBSD固有の問題ではない。あらゆるOSSプロジェクトが同じリスクを抱えている: - LLM生成コードを受け入れた場合、著作権が不明なコードがコードベースに混入する - 将来、法律がAI企業に有利な形で整備されたとき、使用中のコードが問題になる可能性 - copyleftライセンスのコードに学習したLLMの出力物は「派生物」と判断されうる 一方でde Grivel氏はコードの著作権主張を撤回せず、「LLMによって私たちは新しいやり方でお互いのアイデアを自由に盗み合える」と主張した。コントリビューターと保守者の間に埋めがたい認識の溝がある。 まとめ:「動く」だけでは不十分な時代 LLM生成コードは確かに動く。精度も上がっている。しかしOSSプロジェクトへの取り込みには「動作品質」以外の障壁——著作権の法的安定性——が立ちはだかる。OpenBSDはその問いに対して現時点で明確に「No」と答えた。 元記事(LWN.net)では、メーリングリストの議論全文や各開発者の発言が丁寧に整理されている。AIとOSSの交差点に興味があるなら必読だ。LWNはサブスクリプション制だが、記事公開後しばらくすると無料でも読めるようになる。

🟠
Hacker News

macOS 26のウィンドウ角丸を統一する方法:DYLD_INSERT_LIBRARIESとMethod Swizzlingで「一貫して丸く」する

SIP無効化なしで `DYLD_INSERT_LIBRARIES` + Method Swizzlingを使ってmacOSのウィンドウ角丸を統一するハック。「丸をなくす」より「全部統一して丸くする」という発想の転換が痛快で、macOSインターナルに興味があるエンジニアにはたまらない一本。

macOS 26のコーナーデザインが気になる人へ——アップデートしたら角丸の半径がアプリによってバラバラで落ち着かない、という経験はないだろうか。Safariやシステムアプリはやたらぐるっと丸いのに、サードパーティアプリの角は微妙に違う。この「不統一感」こそが問題だ、という視点から書かれた記事を紹介する。 背景:「丸すぎる」より「バラバラ」がつらい macOS 26では角丸デザインが強化されているが、システムアプリとサードパーティアプリの間でコーナー半径に大きなばらつきが生じている。よくある対処法は <strong>SIP(System Integrity Protection)を無効化</strong> してシステムライブラリを直接書き換えることだが、これは /root 以下のセキュリティを下げるリスクを伴う。 作者が選んだアプローチは逆転の発想だ——「全部を角なしにする」のではなく、「全部を同じ半径で丸くする」。SIPを無効にせずに実現できるのがポイントである。 仕組み:DYLD_INSERT_LIBRARIES × Objective-C Method Swizzling macOSには DYLD_INSERT_LIBRARIES という環境変数があり、プロセス起動時に任意の <strong>dylib(動的ライブラリ)</strong> を注入できる。Linuxの LD_PRELOAD に相当する仕組みだ。 このdylibの中でObjective-Cの Method Swizzling を使い、NSThemeFrame(ウィンドウフレームを管理するAppKitのクラス)のコーナー半径を返すメソッドを差し替える。対象は以下の4メソッド: - _cornerRadius - _getCachedWindowCornerRadius - _topCornerSize - _bottomCornerSize すべて固定値 23.0 を返すように上書きする。また com.apple. プレフィックスを持つApple純正アプリはスキップし、サードパーティGUIアプリのみに適用する設計になっている。 実装例:ビルドから自動ロードまで `objc // SafariCornerTweak.m(抜粋) static CGFloat kDesiredCornerRadius = 23.0; static double swizzled_cornerRadius(id self, SEL _cmd) { return kDesiredCornerRadius; } // ... 他3メソッドも同様に差し替え __attribute__((constructor)) static void init(void) { NSString *bid = [[NSBundle mainBundle] bundleIdentifier]; if (!bid || [bid hasPrefix:@"com.apple."]) return; Class cls = NSClassFromString(@"NSThemeFrame"); // method_setImplementation で差し替え } ` コンパイル・署名・配置は以下のコマンドで行う(arm64e/x86_64のユニバーサルバイナリ): `bash clang -arch arm64e -arch x86_64 -dynamiclib -framework AppKit \ -o SafariCornerTweak.dylib SafariCornerTweak.m sudo mkdir -p /usr/local/lib/ sudo cp SafariCornerTweak.dylib /usr/local/lib/ sudo codesign -f -s - /usr/local/lib/SafariCornerTweak.dylib ` ログイン時に自動適用するために LaunchAgents のplistで DYLD_INSERT_LIBRARIES をセットする仕組みも紹介されており、再起動後も設定が維持される。 まとめ・所感 SIPを無効にせずに DYLD_INSERT_LIBRARIES で振る舞いを変えるアプローチは、macOSのローレベルハックとして非常に参考になる。Method Swizzlingはデバッグやテストでもよく使われる手法だが、こうした「UIの統一感」という実用目的で使うのは面白い視点だ。 AppleがUI設計の基準として大きな影響力を持つがゆえに、デザイナーが「Appleに倣え」と判断しがちになる、という作者の指摘も鋭い。丸角のトレンドがYouTubeなど他社UIにも波及していることへの皮肉も含まれており、技術的な解決策だけでなくデザイン哲学への問いかけとしても読める記事だ。macOSのUI挙動を制御したい開発者や、dylibインジェクションに興味があるiOS/macOSエンジニアは元記事のコードも確認してほしい。

🟠
Hacker News

BrotherプリンターにLet's Encrypt証明書を自動インストールする方法 — Certbot + Cloudflare DNS連携

「プリンターのブラウザ警告」という地味だけど実は誰もが気になる問題を、Certbot + Cloudflare DNSで根本解決するニッチな良記事。NASやIPカメラにも応用できる汎用テクニックとして、ホームラボ勢・社内インフラ担当者に刺さります。

プリンターの「この接続は安全ではありません」を解消したい Brotherをはじめとする業務・家庭用プリンターは、Webブラウザから管理画面にアクセスできる便利な機能を持っています。しかし、デフォルトでは<strong>自己署名証明書(オレオレ証明書)</strong>を使っているため、ブラウザが毎回「安全でない接続」と警告を出します。これが地味にストレスです。ましてやローカルネットワーク内とはいえ、設定ページでパスワードを入力するシーンもある。「どうせ社内だから」で済ませていいのか、と気になっていた方も多いはず。 この問題、Let's Encrypt + Certbot + Cloudflare DNS の組み合わせで、完全自動化して解決できます。 なぜ「DNS-01チャレンジ」が必要なのか Let's Encryptで証明書を取得するには、ドメインの所有権を証明する「チャレンジ」をパスする必要があります。一般的なWebサーバーならHTTP-01チャレンジ(特定URLにファイルを置く)が使えますが、プリンターはWebサーバーではないのでこの方法は使えません。 ここで登場するのが DNS-01チャレンジ です。 - ドメインのDNSに一時的なTXTレコードを追加することで所有権を証明 - プリンター側に何もインストール不要 - CloudflareのDNSを使っていれば、APIで自動化できる Certbotの certbot-dns-cloudflare プラグインを使えば、TXTレコードの作成・削除をすべて自動でやってくれます。 セットアップ手順 1. Certbot + Cloudflareプラグインのインストール `bash sudo apt install certbot python3-certbot-dns-cloudflare または pip で pip install certbot certbot-dns-cloudflare ` 2. Cloudflare APIトークンの設定 Cloudflareのダッシュボードで「Zone:DNS:Edit」権限を持つAPIトークンを発行し、以下のファイルに保存します。 `ini /etc/letsencrypt/cloudflare.ini dns_cloudflare_api_token = YOUR_CLOUDFLARE_API_TOKEN ` `bash chmod 600 /etc/letsencrypt/cloudflare.ini ` 3. 証明書の取得 プリンターのローカルIPに対応させたいドメイン(例: printer.example.com)で証明書を取得します。 `bash sudo certbot certonly \ --dns-cloudflare \ --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \ -d printer.example.com ` 4. 証明書をBrotherプリンターにインポート 取得した証明書(fullchain.pem と privkey.pem)を、BrotherプリンターのWeb管理画面からインポートします。 - http://<プリンターIP>/net/net/ssl_certificate.html にアクセス - 「証明書のインポート」から privkey.pem(秘密鍵)と fullchain.pem(証明書チェーン)をアップロード - プリンターを再起動 <strong>5. 自動更新フックの設定(deploy-hook)</strong> Certbotの --deploy-hook オプションを使えば、証明書更新時にプリンターへの自動アップロードも可能です。curl でBrotherの管理APIを叩くスクリプトを書いておけば、certbot renew を cron や systemd timer に登録するだけで完全自動化できます。 `bash /etc/letsencrypt/renewal-hooks/deploy/brother-printer.sh #!/bin/bash curl -k -u admin:PASSWORD \ --form "key=@/etc/letsencrypt/live/printer.example.com/privkey.pem" \ --form "cert=@/etc/letsencrypt/live/printer.example.com/fullchain.pem" \ http://192.168.1.x/net/net/ssl_certificate_import.html ` まとめ・所感 プリンターに正規のTLS証明書を入れるのは「やりすぎでは?」と思われそうですが、管理画面への認証情報を平文で流さないという意味では普通に正当な対策です。特にクリニック・学校・オフィスなど、複数人がネットワークを共有する環境では効果的。 CertbotのDNS-01チャレンジとCloudflare APIの組み合わせは、プリンター以外にもNAS・ルーター・IPカメラなど、Webサーバーを持たないデバイス全般に応用できます。「ローカルLAN内のデバイスにもちゃんとHTTPSを」という管理ポリシーを持っている方にとって、この手法はかなり使い回しが効きます。元記事にはより詳細な手順・スクリプト例が掲載されているので、ぜひ参照してみてください。

📝
Qiita

「エンジニアは難しい」の正体とは?未経験から転職した人が語るリアルな壁と乗り越え方

未経験からエンジニアを目指す人が最初につまずく「心理的バリア」を丁寧に言語化した記事。転職・学習初期の人に読ませたい一本です。

「エンジニアに転職したいけど、自分にできるのか不安」――そう感じて踏み出せずにいる人は少なくない。理系じゃないと無理、数学ができないと厳しい、なんとなくレベルが高そう。この記事では、未経験からエンジニアになった筆者が語る「難しさの正体」と、その乗り越え方をまとめる。 「難しそう」の正体は「よく分からないもの」への怖さ Qiitaに投稿されたこの記事で筆者のひとみさんが最初に指摘するのは、<strong>エンジニアへの第一歩を阻むのは「難しさ」ではなく「未知への恐怖」だ</strong>という点だ。転職を考えたとき、「自分には無理かも」と感じるのは、具体的な根拠があるからではなく、輪郭がつかめないものに対する漠然とした不安から来ている。 これは多くの未経験エンジニアに共通する心理的バリアだ。プログラミングをやったことがない段階では、何が難しくて何がそうでないかすら判断できない。そのため「全部難しそう」という印象が先行してしまう。 実務でぶつかる壁の正体 実際にエンジニアとして働き始めると、「よく分からないもの」の正体に触れる瞬間が訪れる。筆者が例として挙げるのは、機能設計を任されたときの体験だ。なんとなく形は見えているのに、うまく言語化できない、コードに落とし込めない――このギャップこそが実務における本当の「難しさ」の入り口になる。 ここで重要なのは、この壁が<strong>「知識不足」ではなく「思考の型がない」ことから来ている</strong>という視点だ。技術的な知識はドキュメントや検索で補えるが、設計の考え方や問題の分解方法は経験と振り返りで身につくものであり、最初からできる人はほとんどいない。 未経験者が勘違いしがちな「難しさ」のパターン - <strong>「コードを暗記しなければならない」</strong> → 実際はドキュメントと検索が前提。暗記力は不要 - <strong>「数学・理系センスが必要」</strong> → 論理的思考は必要だが、高校数学を超える場面は限定的 - <strong>「エラーが出たら詰んだ」</strong> → エラーは情報。読んで検索すれば大半は解決できる - <strong>「自分だけ遅い・できない」</strong> → 成長の速度は人それぞれで、比較はほぼ無意味 このような「勘違い」を早めに解体できるかどうかが、学習継続のカギになる。 まとめ:「難しい」を解像度高く見ることから始める エンジニアリングは確かに簡単ではない。しかし「難しい」という言葉の中身を解像度高く見ると、乗り越えられる難しさと慣れるしかない難しさに分かれることが多い。元記事はその整理を丁寧に行っており、未経験から転職を考えている人や、学習中に「自分には向いていないのかも」と感じている人に特に刺さる内容だ。 「難しさの正体」を知ることが、一番の壁を突破する第一歩になる。Qiita原文もぜひ読んでみてほしい。

🔥
Zenn

GitHub Copilot サブエージェント(.agent.md)でモデル指定が無視される問題——VS Code 1.113.0でも未解決の現状と回避策

「ドキュメントに書いてあるのに動かない」という開発者あるあるをしっかり掘り下げた良記事。Copilot エージェント構成を本番運用しようとしている方には直撃する内容で、フィードバック先リポジトリの移行情報まで含む実用度の高い一本です。

VS Code の GitHub Copilot Chat<strong> で .agent.md を使ったカスタムエージェントを組んでいる方なら、一度はこの壁にぶつかったはずだ。「サブエージェントごとに使うモデルを変えたい」——そのニーズは至極まっとうなのに、現状では </strong>フロントマターに model を書いても完全に無視される。本記事ではその実態と背景、そして今できる現実解をまとめる。 何が起きているのか .agent.md のフロントマターには公式ドキュメントで model フィールドが定義されており、以下のような書き方が想定されている。 `yaml --- name: type-checker description: 静的型付けの厳密なコードレビューを行うエージェント tools: "read", "edit"] model: - "Claude Sonnet 3.6 (copilot)" - "GPT-5 (copilot)" --- ` これは「軽いタスクはメインの GPT-4o mini に任せつつ、型推論など複雑な処理だけ強力なモデルに委ねる」という コスト最適化・パフォーマンス最適化 を実現するための機能として期待されている。しかし実際には、親チャットセッションで選択されているモデルがサブエージェントにも強制的に引き継がれる。VS Code 1.113.0(2026年3月25日リリース)でも挙動は変わっていない。 なぜ無視されるのか——考えられる構造的理由 Microsoft / GitHub から「意図的な仕様」と明言された一次情報はない。ただし以下の事実から、ある程度の推測はできる。 - <strong>サブエージェントは「ツール実行」に近い内部扱い</strong>になっており、独立したモデルリクエストとして扱われていない可能性がある - 課金・レート制限はチャットセッション単位で管理されているため、サブエージェントで任意にプレミアムモデルへ切り替えられると課金境界が崩壊する - 関連 Issue([#292452)では「Billing can be bypassed using subagents」として課金のリークが報告されており、システム側がモデル切り替えを意図的に封じている可能性が高い dev.to の技術記事 How VS Code Copilot Chat Premium Features Leak into Subagents でも、モデル実行・課金・サブエージェント呼び出しの境界が一致していないことが詳細に分析されている。 関連 Issue と追跡先の変更 現時点で確認できる主な Issue は以下の通り。 - vscode#301966: サブエージェントや skills 情報がモデルリクエスト生成時に欠落するケース - vscode#292452: プレミアムモデルの課金境界とサブエージェントの問題 なお、microsoft/vscode-copilot-release は 2026年3月23日にアーカイブされ読み取り専用になった。今後 Copilot 関連の Issue を出す・追跡する場合は microsoft/vscode リポジトリが窓口となる。 現状の現実的な運用策 残念ながら、今すぐモデルの使い分けでコスト・パフォーマンスを最適化することは不可能だ。現時点で取れる現実解は一つ。 > メインエージェント側に、タスク全体の最大負荷に耐えられる強力なプレミアムモデルを最初から固定で選択しておく 妥協策ではあるが、これが安定稼働への近道だ。その上で、プロンプトの洗練とコンテキストの絞り込み(渡すファイルや情報の最小化)でトークン消費を抑えるアプローチが現実的。将来的に「正当にリクエスト枠を消費する形でのモデル独立指定」がサポートされることに期待しつつ、Issue の動向を追い続けたい。 GitHub Copilot のエージェント機能はまだ発展途上。公式ドキュメントと実装の乖離が残るこの時期だからこそ、現場での検証と情報共有が特に価値を持つ。

💻
Bleeping Computer

Windows 11 KB5079391 更新プログラム:Smart App Controlがクリーンインストール不要でON/OFF切り替え可能に

「SACを切ったらもう戻せない」という常識を覆す地味に重要なアップデート。Windows環境を管理する開発者・ITエンジニアは要チェックだ。

Windows 11のSmart App Controlの設定変更にクリーンインストールが必要だった——そんな不満を抱えていたユーザーに朗報だ。2026年3月27日にMicrosoftがリリースしたプレビュー累積更新プログラム KB5079391 により、この制約がついに解消された。 KB5079391とは何か? KB5079391は、Windows 11 24H2・25H2<strong> を対象としたオプションの非セキュリティ更新プログラム(マンスリープレビュー)だ。毎月末に配信されるこのプレビュー更新は、翌月の </strong>Patch Tuesday で正式展開される機能・修正のテスト版として位置づけられている。セキュリティパッチは含まれないため、インストールは任意となる。 ビルド番号は以下の通り: - Windows 11 25H2 → ビルド 26200.8116 - Windows 11 24H2 → ビルド 26100.8116 Smart App Control:クリーンインストール不要でON/OFF切り替えが可能に 今回の最大のポイントは <strong>Smart App Control(SAC)</strong> の改善だ。これまでSACの有効・無効を切り替えるにはOSの再インストールが必要だったが、今後は以下の手順だけで変更できる。 ` 設定 > Windows セキュリティ > アプリとブラウザーのコントロール > Smart App Control の設定 ` SACはMicrosoftが署名・信頼していない未知のアプリの実行をブロックするセキュリティ機能で、特にマルウェア対策として有効だ。ただし、独自ビルドのツールや開発環境では誤検知が起きやすく、これまでは「一度オフにしたら戻せない」という運用上の課題があった。今回の変更により、検証環境と本番環境で柔軟に切り替えられるようになった点は開発者にとっても大きい。 ディスプレイ・その他の改善点 KB5079391には29項目の変更が含まれており、主要なものを整理すると: ディスプレイ関連 - 1000Hz超のリフレッシュレートを報告するモニターへの対応 - ネイティブUSB4モニター接続のサポート改善 - HDR信頼性の向上 パフォーマンス・安定性 - ARM64デバイスでx64アプリをWindows Recovery Environment(Windows RE)上で実行した際の安定性改善 - 設定 > システム > 詳細設定 から必須更新プログラムをダウンロードする際の信頼性向上 Windows Hello - 一部デバイスでの指紋認証の信頼性改善 - 設定 > アカウント > 他のユーザー のダイアログがモダンデザイン+ダークモード対応に刷新 インストール方法 オプション更新のため、通常は自動インストールされない。以下いずれかの方法で適用できる。 - Windows Update経由:設定 > Windows Update > 更新プログラムのチェック → 「ダウンロードしてインストール」リンクをクリック - Microsoft Update Catalogから手動でダウンロード 「利用可能になったらすぐに最新の更新プログラムを取得する」オプションを有効にしている場合は自動インストールされる。 まとめ・所感 Smart App ControlのON/OFF切り替えがクリーンインストール不要になったのは、地味ながら実務上インパクトが大きい改善だ。セキュリティポリシーを厳格に運用したい企業環境と、開発中に柔軟さが必要な個人環境の両方で恩恵を受けられる。1000Hz超のリフレッシュレート対応も、ゲーミングモニター市場の進化を受けた現実的な対応といえる。4月のPatch Tuesdayで正式展開される前に、検証環境で試しておく価値は十分ある。

📝
Qiita

Claude Code 5つの習熟レベル完全解説|CLAUDE.mdで止まっている人が知らないSkills・Hooks・Orchestrationとは

「CLAUDE.mdを書いた、で終わってる」人に刺さる記事。Skills・Hooks・Orchestrationという3つの概念を5段階のフレームワークで整理しており、自分の現在地と次のアクションが明確になる。Claude Codeをチームや個人プロジェクトで本格運用したい人に強くすすめたい。

Claude Code<strong> を使い始めて、「なんとなく動いてる」から「本当に使いこなせてる」へ。この壁を超えられている人は、実はまだ少ない。Redditで話題になった「The 5 Levels of Claude Code」というフレームワークは、その差を鮮やかに言語化してくれた。投稿者のDevMoses氏は </strong>198エージェントを32セッションで並列実行し、マージコンフリクト率わずか3.1% という驚異的な運用を実現している。その核心にあるのが、この5段階の習熟モデルだ。 5つのレベル全体像 各レベルは「前のレベルの課題を解決するために自然と必要になる」という構造になっている。スキップはできない。 | レベル | 名称 | 核心 | トークン消費 | |--------|------|------|--------------| | Level 1 | Raw Prompting | 都度手入力 | 毎回繰り返し | | Level 2 | CLAUDE.md | プロジェクトルール永続化 | セッション開始時に読み込み | | Level 3 | Skills | 手順書をスラッシュコマンドで注入 | 呼び出し時のみ消費 | | Level 4 | Hooks | ライフサイクルに自動処理を挟む | ほぼゼロ(外部スクリプト) | | Level 5 | Orchestration | 複数エージェントの並列統制 | エージェント数に比例 | 重要な洞察は「自分で次のレベルに進もうと決めるのではなく、天井にぶつかって摩擦が押し上げる」という点だ。CLAUDE.mdが150行を超えて遵守率が下がったとき、Skillsが必要になる。Skillsだけでは品質を担保できなくなったとき、Hooksへ進む。この流れは自然な摩擦の結果として起きる。 Level 1〜2:基礎固め(Raw Prompting → CLAUDE.md) <strong>Level 1(Raw Prompting)</strong> は、インストール直後のそのまま使っている段階。小規模タスクなら十分機能するが、プロジェクトが成長すると「毎回TypeScriptで書いてね」「テスト書いて」「ESLintを通して」と同じ指示を繰り返す羽目になる。コンテキストも毎セッション説明し直しだ。 <strong>Level 2(CLAUDE.md)</strong> は、セッション開始時にClaudeが自動で読み込むMarkdownファイルをプロジェクトルートに置く段階。コーディング規約・ビルドコマンド・禁止事項などを書いておけば、毎回説明しなくて済む。 `markdown CLAUDE.md の例 コーディング規約 - TypeScript必須。any禁止 - テストはVitest、カバレッジ80%以上 - コミット前に npm run lint && npm run test を実行 アーキテクチャ - src/features/ に機能単位でディレクトリを切る - APIクライアントはsrc/lib/api.tsに集約 ` ただし、CLAUDE.mdが肥大化すると遵守率が落ちる。150行を超えたあたりから「あれ、この規約守られてないな」という体験が増え始める。それがLevel 3への扉だ。 Level 3:Skills(スラッシュコマンドで手順書を注入) Skillsは、特定の作業手順をMarkdownファイルとして .claude/commands/ に配置し、/コマンド名 で呼び出す仕組みだ。CLAUDE.mdに全部詰め込む代わりに、必要な手順を必要なときだけ注入できる。 `bash ディレクトリ構造 .claude/ commands/ review-pr.md # /review-pr で呼び出し deploy.md # /deploy で呼び出し debug.md # /debug で呼び出し ` `markdown .claude/commands/review-pr.md このPRをレビューしてください。以下の観点で確認してください: 1. セキュリティ上の問題(SQLインジェクション、XSSなど) 2. パフォーマンスへの影響 3. テストの抜け漏れ 4. コーディング規約の遵守 問題があれば具体的な修正案とともに報告してください。 ` トークンの観点でも効率的だ。CLAUDE.mdは毎セッション全体が読み込まれるが、Skillsは呼び出したときだけ消費される。 Level 4:Hooks(ライフサイクルへの自動処理挿入) Hooksは、Claude Codeの動作ライフサイクルの特定タイミングに外部スクリプトを自動実行する仕組みだ。「ファイルを編集したら自動でlintを走らせる」「コミット前に自動でテストを実行する」といった自動化が、Claudeのトークンをほぼ消費せずに実現できる。 `json // settings.json の例 { "hooks": { "PostToolUse": [ { "matcher": "Edit", "hooks": [ { "type": "command", "command": "npm run lint --fix" } ] } ] } } ` 主なフック実行タイミング: - PreToolUse : ツール実行前(危険操作のガード等) - PostToolUse : ツール実行後(lint・フォーマット・テスト等) - Stop : Claudeが応答を終えたとき(通知・ログ等) Skillsが「Claudeに頼む作業の品質」を上げるのに対し、Hooksは「Claudeが触れるたびに自動で起きること」を定義する。この組み合わせで、人間がレビューしなくても一定品質が担保される環境が作れる。 Level 5:Orchestration(並列エージェント統制) 最上位レベルは、複数のClaudeエージェントを並列で動かし、1つのオーケストレーターが統制するアーキテクチャだ。DevMoses氏の「198エージェントを32セッションで並列実行」はこのレベルの産物だ。 典型的なパターン: - <strong>Orchestrator(親)</strong>: タスクを分解し、サブエージェントに割り振る - <strong>Worker(子)</strong>: 独立した部分タスクを並列実行 - <strong>Reviewer(子)</strong>: 各Workerの出力を検証 ` Orchestrator ├── Worker A: フロントエンド実装 ├── Worker B: APIエンドポイント実装 ├── Worker C: テスト作成 └── Reviewer: A・B・Cの出力をレビュー・統合 ` Claude Code公式のAgentツールやclaude -p(ヘッドレスモード)を組み合わせることで実現できる。マージコンフリクトを最小化するには、各エージェントが触れるファイル範囲を事前に設計しておくことが鍵だ。 まとめ:あなたは今どのレベルにいるか Level 2(CLAUDE.md)で止まっている人が最も多い。それは悪いことではない——そこまで来られていること自体、多くの人が到達していない領域だ。ただ、「最近Claudeが指示を守らない」「同じことを何度も説明している」と感じ始めたなら、それはLevel 3のSkillsが必要になっているサインだ。 摩擦を感じたとき、それが次のレベルへの扉だと覚えておくといい。元記事はQiitaのmiruky氏が公式ドキュメントとRedditの知見をもとに体系化しており、各レベルの具体的な設定例も豊富だ。Level 4・5の実装詳細まで読む価値がある。

📝
Qiita

【Unity】UniRxの後継「R3」入門 — 基礎から学ぶリアクティブプログラミング 2026年版

UniRxの作者本人によるR3入門シリーズという信頼性の高さが光る。「UniRxからR3は機械的に置き換えられない」という明確な警告は、移行を検討している全Unityエンジニアが読んでおくべき内容だ。

UnityでリアクティブプログラミングといえばUniRxだった時代は終わった。2026年現在、UniRxのGitHubリポジトリはアーカイブされメンテナンス終了<strong>となり、後継ライブラリ「</strong>R3」への移行が事実上の標準となっている。UniRxを使い続けているプロジェクトや、これからリアクティブプログラミングを学ぼうとしているUnityエンジニアにとって、R3は避けて通れない存在だ。 R3とは何か — UniRxとの本質的な違い R3は「現代のC#に合わせてRx/UniRxを再設計したライブラリ<strong>」である。単なるバージョンアップではなく、根幹となるObservableの概念や振る舞いに</strong>破壊的変更が加えられている点が重要だ。主な違いを整理すると: | 観点 | UniRx | R3 | |------|-------|----| | エラー時の挙動 | Observableが購読終了 | 動作を継続する | | 完了後の再利用 | 場合によって再購読可能 | 不可(新しく作り直す) | | OnCompleted | 実装次第 | 原則として必ず発行 | | 時間管理 | Scheduler | TimeProvider / FrameProvider | | async/await連携 | 最低限 | 前提として構築 | この違いは「機械的に置き換えられない」ことを意味する。既存のUniRxコードをR3に移行する際は、エラーハンドリングやストリームのライフサイクル管理を見直す必要がある。 R3でできること — ゲーム開発との親和性 リアクティブプログラミングとは「<strong>時間とともに流れるデータ(イベント)を宣言的に扱うスタイル</strong>」だ。Unityのゲーム開発では特に以下のようなケースで力を発揮する: - キャラクター状態の変化検知 — HPが0以下になった瞬間だけ処理を走らせる - 入力の連打・長押し判定 — 一定間隔内の連続入力をまとめて扱う - UI更新タイミングの制御 — 値の変化があったときだけUIを再描画する - 数フレーム前との比較 — フレームをまたいだ状態遷移の検知 - 一定時間後の処理 — コルーチン不要でタイムアウト処理を記述する R3では「今この瞬間の値」だけでなく「時間的な変化」も含めて処理できる点が、従来のイベントやコールバックと一線を画す。 前提条件と学習のステップ R3を学ぶ前に以下を理解しておくことが推奨されている: `csharp // R3を使う上で必須の知識 // - event, LINQ, delegate, ラムダ式, 拡張メソッド // - async/await, CancellationToken(特に重要) // - UniTask(導入済み前提) ` 特にasync/awaitとCancellationTokenはR3の設計思想と深く絡んでいるため、これらを理解していないと詰まる場面が多い。UniTaskとの組み合わせが前提となっているのもR3の大きな特徴だ。 セットアップや導入手順は「R3入門 ~導入編~」として別記事にまとめられているので、インストールから始めたい場合はそちらを先に参照するとよい。 まとめ — 今からUnityでRxを使うならR3一択 UniRxから乗り換えるにせよ、初めてリアクティブプログラミングを学ぶにせよ、2026年時点でUnityにRxを導入するならR3が唯一の正解だ。UniRxの知識は活かせるが、設計思想の差異を理解せずに移行すると予期せぬバグを招く。本記事のような体系的な日本語資料が整いつつある今こそ、腰を据えてR3に向き合う絶好のタイミングといえる。元記事はシリーズ形式で続きが公開予定とのことで、Operator・Subject・ライフサイクル管理など実践的な内容も期待できる。

📝
Qiita

本番デプロイで1時間が8時間に——seedファイルとAWS Lambdaで踏んだ6つの罠と回避策

「見積もり1時間→実績8時間」の地獄を丁寧に振り返った実録レポート。特にLambdaとブラウザ依存ライブラリの落とし穴は、今後 pdfjs-dist を使おうとしている人に刺さる一次情報だ。

「見積もり1時間、実績8時間」——このフレーズに心当たりのあるエンジニアは少なくないはず。本記事は、Qiitaに投稿された実録デプロイ失敗談を元に、本番環境特有の落とし穴と事前に防げたミスを整理する。Next.js + AWS Lambda 構成で開発しているチームには特に刺さる内容だ。 背景:なぜ「1時間」のはずが「8時間」になったのか 仮完成報告会の前日、チームメンバーに触れるデータを本番環境に投入する作業が発生した。普段はローカルで seed ファイルを使い一括生成しているため、「同じことを本番でやるだけ」という認識だった。しかし本番環境は、ローカルとはまったく異なる地雷原だった。 筆者は6つの誤算を3カテゴリに分類している。 - 本番環境特有のエラー:誤算1(認証メール)、誤算2(Lambdaライブラリ) - ローカルで防げたはずのエラー:誤算3(謎のリダイレクト)、誤算4(404)、誤算5(メイン機能停止) - 焦りが招いた判断ミス:誤算6(本番でのビルド実行) 技術的に最も重要な教訓:Lambdaで動かすライブラリの選び方 誤算2が特に技術的な学びとして深い。PDF解析に使っていた pdfjs-dist が、Lambda(Node.jsランタイム)上で動作しなかった。 原因は pdfjs-dist がブラウザの DOM API(DOMMatrix、Path2D など)に依存していること。ブラウザ前提で設計されたライブラリはLambdaでは動かない。 `bash Lambda環境でのエラー例(イメージ) ReferenceError: DOMMatrix is not defined at new PDFPageProxy (/var/task/node_modules/pdfjs-dist/...) ` 解決策は <strong>pdf2json(純粋Node.js実装)に戻す</strong>こと。Lambda上でライブラリを使う際は「ブラウザ依存か・純粋Node.js実装か」を必ず確認する習慣が欠かせない。 ローカルで防げたはずの3つのミス 誤算3〜5はすべて「ローカル環境でのステージング確認不足」が根本原因だ。具体的には: - 誤算3:有料プランユーザーのはずなのに、フリープラン制限画面にリダイレクトされた(プラン判定ロジックのバグ) - 誤算4:本番でのみ発生する404(パス設定やルーティングの差異) - 誤算5:メイン機能が丸ごと停止(上記バグの連鎖) これらは「本番同等の環境でseedを流すテスト」を1回やっておくだけで発見できた可能性が高い。本番デプロイ前にステージング環境でseedを一度流すというプロセスを標準化する価値は大きい。 まとめ:チェックリストとして使える教訓 この記録から抽出できる実践的なチェック項目: - [ ] Lambdaで使うライブラリはブラウザ依存がないか確認する - [ ] 認証フロー(メール送信含む)を本番環境で事前検証する - [ ] seedファイルはステージング環境で一度試してから本番適用する - [ ] 焦っているときほど「本番でビルドする」などの判断を慎重にする - [ ] デプロイ作業の見積もりにはバッファを2〜3倍見ておく 元記事では誤算4〜6の詳細や、各誤算でどう判断して乗り越えたかも丁寧に書かれている。<strong>「次の自分が同じ罠を踏まないための記録」</strong>として書かれた誠実な技術ブログで、デプロイ作業を控えているチームに一読を強くすすめたい。