Apple初の折りたたみ機iPhone Duoが1,999ドルで登場し、Tailwind LabsはShopifyへ

Metaのパーソナルエージェント「Muse」の紹介ページ。独自のブラウザを持ち、生活のあらゆる面にアクセスするという位置づけで説明されている。

コメントの大半はMetaに個人情報を渡すことへの拒否感で占められている。サイトの例が「チケットを取る」「ベビーカーを買う」といった購買中心である点から、広告的な提案が送られてくるのではないかという懸念、内蔵ブラウザが収集するPIIの範囲への警戒、これまでの行動を踏まえてなぜMetaに生活全体を預けるのかという書き込みが続く。

2015年のFacebook Mを引き合いに、当時は裏側がほぼ人力で、いずれ置き換える構想だったという指摘もある。完成度の高いエージェント製品を先に出したこと自体は評価する声も見られる。

著者が自分のプロジェクトのライセンスをEUPLに変更した経緯。オープンソース側は自由ソフトウェア陣営との議論に勝ったが、利用者にも開発者にも利益はなく、大企業が安く作れるようになっただけだ、という認識が出発点になっている。

コメントでは、2年前に同じ結論に至ってAGPLを選んだという報告があり、AGPLは広く知られている分だけ何が起きるか予測しやすいという指摘が付いている。

MITを選ぶのは利用者や開発者のためではなく自分のためであり、収益化も企業を縛ることも考えていない、という反論も出た。これに対して、企業が改良を公開しない分だけプロジェクトの利用者が不利益を被るのではないか、という応答が続いている。

著者がパスワードマネージャーをApple Passwordsへ移行した記録。

コメントでは、Apple Passwordsのパスキーに触れられるブラウザがAppleの許可制である点が最初に挙がった。Chrome、Safari、Firefoxは対象だが、自前でビルドしたUngoogled ChromiumやFirefoxは組織の開発者IDで署名されていないため使えない、という説明が続く。

任意のプログラムにパスキーへのアクセスを許すべきかで意見が割れ、macOSのキーチェーンのようにOSのパスワードを入れれば済むようにしてほしいという意見に対し、パスキーの脅威モデルはブラウザが信頼できる前提で成り立ち、どのRP IDが認証を求めているかの提示がフィッシング耐性の根拠になっている、という指摘が出ている。1Passwordでも同種の許可リスト問題があったという報告もある。

欧州のクラウド事業者の現状をまとめた記事。

コメントでは実際の運用体験が具体的に語られている。UpCloudを使っていたユーザーが、先週DDoSを受けた際に通知のないままサーバーをnull routeされていたとして移行を決め、移行先はHetznerのベアメタルとVPSだと述べている。

もう一つの論点は記事が挙げた「エストニアの事業者」で、実態はe-Residency経由で登記された会社であり、住所も「もっともらしく見える私書箱」サービスのものではないかという指摘が出た。何をもってエストニアの企業と呼ぶのか、エストニアの法律に従うなら十分ではないか、という議論が続いている。

ESP32とeInkを使ってプリンターを自作した記録。ESP32のRAMでは画面全体を保持できないため、描画済みのデータをネットワーク越しに行単位で流し込む構成を取っている。

コメントでは、同じ手法でHome Assistant用のeInkディスプレイを作った例が挙がり、Raspberry Piで描画してストリームしているという報告が続く。初期の家庭用コンピュータも同じ制約を抱えており、スプールファイルへの印刷が常套手段だったという指摘も出ている。

QuickDrawのスプールファイルはビットマップではなく描画プリミティブを保存し、ページ全体を短いビューポートに切り取りながら繰り返し描画していた、という補足も付いた。reMarkable向けにIPPサーバーを書きたくなったという反応もある。

クライアント側のJavaScriptを使わず、サーバーがHTMLを送り続けることでページを更新する手法を扱った記事。

コメントでは、これは新しい手法ではなくIE時代から使われていたという指摘が出て、いわゆる「forever frame」であること、nginxにその用途のpush streamモジュールが存在することが共有された。Lobstersでも1年ほど前に同じ仕組みの記事が出ていたという言及もある。

別の流れとして、「rendering」をHTML生成の意味で使うのは誤用で、ブラウザのレンダリングエンジンが行う処理を指すべきだという主張が出ている。SSRという語がモバイル黎明期には別の意味で使われていたという回想も続いた。

エージェント向けに39種類の編集用ダイアグラムを生成するスキル。出力は自己完結したHTMLとSVGで、Mermaidにもdraw.ioにも依存しない。対応先はClaude Code、Codex、Factory Droid、Pi、およびAgent Skills互換のホスト。

2.5.10では、Sankey、特性要因図、Wardleyマップ、かんばん、ユーザージャーニー、デプロイ図、依存グラフ、UMLクラス図、ストーリーマップ、DBスキーマの10種類が追加された。2.3で入ったセマンティックパターンは振る舞いをレイアウトから分離して記述し、キューやポリシートレース、トラスト境界を型を増やさずに表現する。

静的HTMLが既定で、順序のある説明にはアクセシビリティに配慮したモーションを選べる。draw.ioやMermaidのソースを指定の形式・サイズ・詳細度で描き直す機能もある。

複数のエージェントハーネスにまたがって、スキル、instinct、メモリ、セキュリティ、リサーチ先行の開発手順を提供するシステム。Claude Code、Codex、Opencode、Cursorなどに対応する。

READMEは冒頭に警告を置き、配布元をGitHubリポジトリ、npmのecc-universalとecc-agentshield、GitHub App、プラグインのecc@ecc、サイトのecc.toolsに限定している。第三者による再アップロードやミラーはプロジェクトが保守もレビューもしておらず、マルウェアを含む可能性があるとしている。

導入はnpx ecc-universal setupで、Node.js 18以降、Git、PATH上のClaude Code 2.1以降が必要。npmのバージョンやキャッシュのエラーが出た場合はnpm view ecc-universal versionでの確認を案内している。

コーディングエージェント向けの開発方法論を、組み合わせ可能なスキル群と初期指示としてまとめたリポジトリ。エージェントが起動直後にコードを書き始めず、一度立ち止まって進め方を決めるところから始まる。

対応ホストはClaude Code、Antigravity、Codex AppとCodex CLI、Cursor、Devin CLI、Factory Droid、Gemini CLI、GitHub Copilot CLI、Grok Build CLI、Kimi Code、OpenCode、Pi、Hermes Agentと広い。

READMEには基本ワークフロー、収録スキルの一覧、設計思想、更新方法に加え、商用サービスとビジュアルコンパニオンのテレメトリの節も置かれている。

GPT-Image2向けに、プロンプトをコードのように扱うテンプレート集。500件を超える事例を逆算し、20種類以上のテンプレートとして整理している。

GPT Image 2.5では、生成と精密な編集を担うSunburstと、高速な日常向け生成のFlareという2つのモデルを取り上げ、同一プロンプトでの比較をドラッグ可能な仕切りや並列表示で見られるサイトを用意している。レモンのキャンペーン、リオのジオラマ、マンハッタンの水彩、ショップアイコンの4例では、元の画像とギャラリー掲載のプロンプトをそのまま使って再生成している。

ドキュメントは英語、簡体字中国語、日本語で提供されている。

チームで使うスキル、ルール、MCP設定、ナレッジを、Claude Code、Codex、CodeBuddy、WorkBuddy、OpenCodeなど複数のエージェントにまたがって管理するCLI。Tencentが公開している。

導入はnpm install -g teamai-cli。管理者はGitホスト上に共有リポジトリを作り、メンバーに書き込み権限を与えたうえでteamai init <リポジトリURL>を実行する。対応するホストはGitHub、GitLab、GitCode、CNB、TGit、プライベートGitサービス。

共有リポジトリがない場合に備えて、実運用向けのスキル、ルール、レビューエージェントを収めたテンプレートも用意されている。

Codexプラグインの実装例を集めた公式リポジトリ。各プラグインはplugins/以下に置かれ、.codex-plugin/plugin.jsonのマニフェストを必須とし、skills/、.app.json、.mcp.json、agents/、commands/、hooks.json、assets/などを任意で持つ。

既定のマーケットプレイスは.agents/plugins/marketplace.jsonにあり、plugins/ディレクトリを指す。APIキーでログインするユーザー向けにはapi_marketplace.jsonが別に用意されている。

内容の厚い例として、figma（use_figma、Code to Canvas、Code Connect、デザインシステムのルール）、notion、build-ios-apps、build-macos-apps、build-web-apps、expo、netlify、remotionなどが挙げられている。

AIエンジニアリングを手を動かして学ぶ無料のカリキュラム。523レッスン、20フェーズ、およそ342時間の分量で、Python、TypeScript、Rust、Juliaを扱う。MITライセンスで公開されている。

各レッスンはプロンプト、スキル、エージェント、MCPサーバーのいずれかを成果物として残す構成。523レッスンを最初に見渡す必要はなく、作りたいものを1つ選んで始める形が案内されている。

冒頭には、学生の84%がすでにAIツールを使っている一方、職業として使う準備ができていると答えたのは18%という数字を掲げ、その差を埋めることを目的としている。2026年8月29日時点で読者114,584人、直近30日のページビューは181,995と記載がある。

不具合修正のPRをレビューする際、追加されたテストが修正前のコードで本当に落ちていたのかは、CIがGreenになっただけでは分からない。この記事は、Redの状態そのものをCIがGreenと判定できる形にして残す「Red-Green Stacked PR」という手法を扱う。TDDのRed-Green RefactorとGitHubのStacked pull requestsを組み合わせた、筆者による造語である。

従来レビュアーは、ブランチをローカルに取得し、修正コードをコメントアウトしてテストが落ちることを確認し、戻してもう一度通ることを確認する手順を踏む必要があった。確認できるのはその場かぎりで、結果はレビュアーの手元にしか残らず、PRが増えればボトルネックになると整理している。

2026年9月時点でGitHubのStacked pull requestsとgh stackはPublic Previewであり、仕様やCLIが変わる可能性があると注記されている。

HTMLを社内だけで共有するWebサービス「Artifact Share」を1人で開発した記録。開発開始から4か月でTypeScriptのコードは25万行を超え、マージしたPRは1,144本、Issueは777件に達している。

筆者はコードも差分も読まず、AIと壁打ちして作ったIssue、PRのタイトル、CIが緑かどうかの3点だけを見ている。PRの本文もAI同士のレビュー結果も普段は読まない。7月から有料課金を始めており、クライアント企業1社、カリフォルニアの企業1社、個人1人が課金し、無料を含むワークスペースは133、先週は50人がこのサービスでHTMLを共有した。

直近4週間ではマージ233本に対しrevertはゼロ、全停止するようなサービスダウンも起きていないとして、試行錯誤の末に残った仕様と実装のレビューループを説明している。

Goでコードを書いていてdomain層にロジックが集まらない、リポジトリを呼ぶためにdomainへcontextとerrorを持ち込むか迷う、という状況を扱った記事。ドメインモデル貧血症は怠慢ではなく構造的なトリレンマの結果として生まれやすい、という立場を取る。

戦術的パターンの目的として、モデル駆動設計、不変条件の保護、テスタビリティ、交換可能性の4つを挙げ、この記事が扱うのはモデル駆動設計の一面だけだと範囲を限定している。X上の「戦術的パターンの多くは2003年当時のJava/OOPの制約の産物で、代数的データ型のある言語では価値が目減りしている」という評価にはおおむね同意しつつ、そこで止まらずに構造的な理由を追う形を取る。

結論として、「判断するために何が要るか」を型で返せば、型の制約を保ったままトリレンマを解けるとしている。

技術は追いたくなった時点で追ったほうがいい、という主旨の記事。筆者はインフラエンジニアで、Vimには何度か挑戦して挫折していたが、動画でカスタマイズされたNeovimとLSPを知り、実践Vim入門を買って操作を覚え、プラグインを入れて楽しんでいたという経緯を書いている。

本格的にのめり込んだのは2025年12月で、その直前の11月にOpus 4.5が出て世間はAI一色になっていた。そこからVibe Codingが広がり、人が手でコーディングしない時代になったため、カスタマイズしたNeovimで書く楽しさを味わう期間はほとんどなかったとしている。

プラグイン開発にも興味を持ったがエコシステムはすでに成熟し、Vibe Codingの流れでプラグインを外す動きさえ出てきた、と書いている。

社内システムの管理機能をループエンジニアリング（ralph loop）で作り直した記録。対象の画面はReact JSON Schema FormでJSON Schemaから生成しており、AIが完成形のDOMを想像できないため、通常のReactに比べて不具合や手直しが多かったという背景がある。

画面は40枚近くあり、利用者が限られるためリソースを多くは割けない。そこで管理機能用のデザインシステムと画面一覧を先に作り、画面ごとに、旧デザインの実装から要件を起こす、別のエージェントで漏れや誤りを確認する、直すのではなく新しく作り直す、要件からテスト仕様書を作って新旧の挙動を比較する、という4ステップの計画を立てた。

記事はまず失敗編から始まり、Main AgentとTest Agentなど3つのエージェントを立てて進めようとした構成を振り返っている。

事前知識のない状態から学習させ、ルービックキューブを一撃で解く専用LLM「CUBE ZERO」を作った記録。モデルは現在のキューブと過去の手順を受け取り、次の1手を自己回帰的に生成する。学習後は、初めて見る局面の99.83%を1回の生成で解いた。

記事は難易度を状態数で説明している。キューブの状態は約4.3×10^19通りあり、完成状態からの最短手数をdepthとすると、depth 6までの累計が約824万局面であるのに対し、depth 7だけで約1億局面に達する。ここから先は単純な丸暗記では扱えなくなる。

God's Numberが20であること、実験で使うdは厳密な最短距離ではなく完成状態からランダムに回した回数であることにも触れ、d=30の局面は実用上ほぼ最難関を含むとしている。

Claude Codeを複数並列で動かすための環境構成をまとめた記事。同じ作業ディレクトリで2つ動かすと、片方のgit switchがもう片方の読んでいるファイルまで入れ替えてしまうため、git worktreeで作業ディレクトリを分ける。

ただしworktreeを作るたびにgit worktree addを打ってディレクトリを移動する手間があり、worktreeの数だけディレクトリとターミナルが増えて散らかるため、筆者は一度使わなくなったと書いている。

その後、並列で動くエージェントの状態を一目で把握するためにターミナルマルチプレクサのHerdrを導入したところ、worktreeの管理とも噛み合うことに気づいた、という流れ。git worktreeとClaude Code自身のworktree機能の違いにも触れ、前者はcloneと違って.gitを共有する点を説明している。

AIに書かせたテストコードをレビューする側から見た記事。筆者は1年ほど、構造や仕様をAIに与えてテストケースを作らせ、実装も書かせたうえで、チームで互いにレビューする形で開発している。

問題として挙げているのは、書かれたテストが何も保証していない例が増えたこと。検証すべき挙動が内部で呼ぶ関数をすべてモックしていたケース、内部属性を呼び出して細かな処理や値だけを数百行にわたって固定し、本来固定すべき仕様や全体の流れは検証していないケースを挙げている。

AIに実装やテストを書かせること自体は否定していない。読まないまま他人に投げてレビューさせる姿勢が問題であり、レビュアーがテスト全体の無意味さを説明する時間が失われる、という主張である。

GPT-6 Astraに、3Dモデリングソフトを介さずコードだけで3Dシーンを作らせる「コードファースト3Dモデリング」を、週末2日で試した記録。

X上に流れているAstra製の高品質な3DシーンはMCP経由でBlenderなどを操作させたものが多く、アプリ内でコードから直接生成するとクオリティが落ちがちだ、という前提を置いている。筆者はこれまでCodexやClaude CodeでSol、Terra、Fable、OpusにiOS向けの3Dゲームを作らせており、特にRealityKitでは単純な立体を組み合わせただけの結果になりがちだったと書いている。

Astraのリリース当日に見かけた投稿をきっかけに、RealityKitとSwiftのコードだけでどこまでいけるかを検証し、ある程度の成果が得られたとして知見を共有している。

ChatGPTのGPT Imageで資料やWebサイト用のイラストを作る際に、線が均一すぎる、グラデーションが滑らかすぎる、顔が整いすぎている、背景に意味のない小物が増える、といった特徴からAI生成だと分かってしまう問題を扱った記事。

日本語の指示文の後ろに貼るだけで画風を固定できるプロンプトを38種類作り、すべて「日本の少女を描いて」という同じお題で生成して並べている。どれが効くかは事前に分からないため総当たりで試した、としている。

画風を表す語彙（linework、halftone、registrationなど）は英語のほうが素直に効くため、内容は日本語、画風は英語という組み合わせを取っている。AIっぽさを弱める追加ブロックと、そのまま使えるテンプレートも併せて掲載している。

重くなったローカルのDocker環境（Windows）を軽量化する手順をまとめた記事。リソース削除やnamed volumeの移行など、確認やバックアップを省くとローカル環境に影響が出る操作を含むため、まず作業用コピーや不要なデータで試すよう断っている。

最初の手順は不要リソースの掃除。Dockerはビルドキャッシュや古いイメージ、停止済みコンテナを自動では消さないため、docker system dfでRECLAIMABLE列を確認し、数十GB単位で溜まっていればdocker ps -a、docker images、docker volume lsで対象を確かめてからdocker system pruneでまとめて削除する。

.dockerignore、マルチステージビルド、ベースイメージの軽量化、ビルドキャッシュの活用は、ビルドやpull、コンテナ再作成、起動の時間に効くもので、稼働中のページ応答を速くする対策ではないと注意している。

新卒1年目の筆者が、生成AIに実装を依頼するとコードを書く時間は短縮できる一方、生成されたコードを理解するまでに時間がかかり、開発全体は期待したほど速くならないと感じた経験から書かれた記事。

最初はAIにレビューガイドを作らせたが、個々の処理が何をしているかは確認できても、それらがどうつながり、なぜその構成なのかまでは理解できなかったという。結局コードを読み直し、理解できているか不安なまま先輩にレビューを頼むことになっていた。

そこで問題はコードの読み方ではなく実装を依頼する前の準備にあると考え、AIとの壁打ちで要件と実装範囲を整理してADRに残す方法を取った。目標は「出力を読みやすくする」ではなく「出力を想像できるようにする」ことだとし、レビュー指摘の減少や意図を説明しやすくなった変化を挙げている。

Claude Codeで最近取り入れたtipsを4つ紹介する記事。大がかりな仕組みではなく、気になったものだけ拾えばよい、という構成になっている。

1つ目はセッション名の自動命名。Claude Codeのセッションには/renameで名前を付けられ、プロンプト入力欄の右下にチップとして表示される。複数セッションを並行して動かすとどれが何の話か分からなくなるため名前を付けるようになったが、毎回手で打つのが面倒だったことが出発点だとしている。

仕組みの説明として、Claude Codeがセッションのタイトルをai-titleとcustom-titleの2種類持っており、それぞれ誰が作るか、どこに表示されるかが異なることを表で整理している。

採用広報の担当者が、未経験からIT業界への転職を考える人に向けて書いた記事。面接で会う20代から30代の人から「今の仕事をこのまま続けていいのか」「特別なスキルもない自分にできるのか」という不安をよく聞く、としている。

主張は、最初から明確なキャリア像や専門スキルを持っている必要はまったくない、というもの。転職活動を始めると3年後の姿を問われるが、先のことは入ってから一緒に考えればいい、と書いている。

同じ筆者による未経験者向けシリーズの1本で、自社の職員インタビューへの導線が含まれる。