Redis Pub/Sub から Streams への移行で帯域 99% 削減 — 同時接続 30 万超チャットの実践記録 Keisuke Nishitani 氏(@Keisuke69)のポストで、LY Corp（旧 LINE）の技術ブログ記事が紹介されていました。同時接続数 30 万超の LINE 公式アカウント（OA）チャットが、メッセージ配信基盤を Redis Cluster の Pub/Sub から Redis Streams へ移行した事例です。ピーク時 1.5 Gbps だったノードあたりの帯域が 11 Mbps まで削減されたという結果は、大規模リアルタイムシステムを運用するエンジニアにとって示唆に富む内容です。 同時接続数30万超のチャットサービスのメッセージ配信基盤をRedis Pub/SubからRedis Streamsにした話 — @Keisuke69 背景 — Redis Cluster Pub/Sub のスケール限界 LINE 公式アカウントのチャット機能（OA チャット）は、ユーザーから送られたメッセージを OA オーナーにリアルタイムで配信する仕組みを持っています。この配信基盤として Redis Cluster の Pub/Sub を使用していました。 問題は Redis Cluster における Pub/Sub の仕様にあります。あるシャードに publish されたメッセージは、クラスター内の全シャードにブロードキャストされます。24 シャード構成であれば、1 メッセージが残り 23 シャードに伝搬するため、アウトバウンドトラフィックはインバウンドの 23 倍になります。 指標 値 クラスター構成 24 シャード / 48 ノード ノードあたり帯域（平常時） 500 Mbps ノードあたり帯域（ピーク時） 1.5 Gbps シャードを増やせばクラスター性能は上がりますが、同時にブロードキャストのトラフィックも増えるというジレンマがあり、スケールアウトが頭打ちになっていました。 ...

SaaS の終焉（SaaSpocalypse）— 自律エージェントが Seat 課金を破壊し、ソフトウェア業界を再編する @shoji_hq 氏が X で共有した、Insight Partners 共同創業者による「SaaS の終焉（Apocalypse）」Podcast の備忘メモが注目を集めています。 AIの津波はまだこれから。本丸は「Autonomous Agents（自律エージェント）」であり、これが今からやってくる。これが浜にぶつかった瞬間、大きな津波になる。 この警告は予言ではなく、すでに現実になりつつあります。2026 年 2 月、ソフトウェアセクターは「SaaSpocalypse」と呼ばれる大暴落を経験し、1 兆ドル超の時価総額が消失しました。本記事では、何が起きているのかを構造的に整理します。 Insight Partners が語った 5 つの構造変化 @shoji_hq 氏のメモは、Podcast の要点を 5 つに整理しています。それぞれを掘り下げます。 1. 自律エージェントが本丸 自律的にタスクを分解し、ツールを選び、実行し、報告する存在。これが世の中の構造を変える。 Insight Partners 自身も「million-Agent problems」という表現を使っています。協調する複数のエージェントが、一晩かけて自律的に作業を完了し、翌朝には成果物が揃っている世界です。Deloitte の予測では、自律型 AI エージェント市場は 2026 年に 85 億ドル、2030 年に 350 億ドルに達するとされています。 重要なのは、これが単なるチャットボットの延長ではない点です。CUA（Computer-Using Agent）は複雑なソフトウェアインターフェースを人間より上手に操作できるレベルに達しており、「デジタル従業員」として機能し始めています。 2. API の応答速度が UI より重要になる 人間は400msで遅延を感じる。エージェントは80msを最適化する。美しいUIより、APIの応答速度が大切。 エージェントが主要なユーザーになると、設計のプライオリティが逆転します。 指標 人間向け設計 エージェント向け設計 遅延の閾値 400ms 80ms 重視する点 UI/UX の美しさ API のレスポンス速度 インターフェース グラフィカル プログラマティック 同時接続 数百〜数千 数万〜数百万 稼働時間 営業時間 24 時間 365 日 Insight Partners の Ryan Hinkle 氏は「ナレッジワーカーが仕事に不可欠とするシステムは AI の大きな恩恵を受ける。ただのファイリングキャビネットは脅威にさらされる」と述べています。 ...

Second Me — AI に「自分の分身」を持つ時代と OpenClaw との本質的な違い 前回の記事で OpenClaw による 13 体 AI チーム構築を紹介しました。OpenClaw では SOUL.md というファイルでエージェントの「人格」を定義しますが、これは本当に「自分の分身」と呼べるのでしょうか。Second Me というプロジェクトは、まったく異なるアプローチで「AI による自分の分身」を実現しようとしています。 SOUL.md の限界 — 「指示書」は「分身」ではない OpenClaw の SOUL.md は Markdown で書かれた設定ファイルです。エージェントの名前、性格、役割、制約を自然言語で記述します。 1 2 3 4 5 6 7 8 9 10 --- name: sales-agent model: claude-sonnet-4-6 --- あなたは営業チームの一員です。丁寧に話してください。 ## 役割 - リード情報の整理と優先順位付け - 提案メールの下書き作成 これは強力な仕組みですが、あくまで外から与える指示書です。「営業エージェントをこう振る舞わせたい」という設計者の意図を反映したものであり、「この人ならどう考えるか」を再現するものではありません。 ...

ハーネスエンジニアリング入門 — AIエージェントの性能はモデルではなく「周辺設計」で決まる 朱雀氏のポストが、Claude Code や Codex の仕組みを理解するうえで「ハーネス」の概念が重要だと紹介しています。2026 年に入り、AI エージェント開発の焦点は「どのモデルを使うか」から「モデルの周囲をどう設計するか」に移りました。この周辺設計を指す言葉がハーネスエンジニアリングです。 Claude CodeやCodexの仕組みを詳しく理解したい人にはこれがおすすめ。「ハーネス」について詳しく解説してくれている。 ハーネスとは何か ハーネスとは、AI モデルを囲む運用インフラのことです。Phil Schmid 氏の解説では、コンピュータに例えて次のように整理しています。 コンピュータ エージェント CPU モデル（推論エンジン） RAM コンテキストウィンドウ（作業メモリ） OS ハーネス（コンテキスト管理、ツール処理、起動シーケンス） アプリケーション エージェント（ユーザー固有のロジック） モデルが CPU なら、ハーネスは OS です。どれだけ高性能な CPU を積んでも、OS が貧弱では実用的なアプリケーションは動きません。 具体的には、ハーネスは以下の要素を管理します。 会話・コンテキスト管理: セッション間の記憶、コンテキストウィンドウの最適化 ツール呼び出し層: MCP/SDK ツールの提供と制御 権限管理: 実行可能な操作の制御 セッション・ファイルシステム状態: 作業ディレクトリ、Git 状態の管理 ループ制御・エラーハンドリング: リトライ、ガードレール、検証 観測性: ログ、メトリクス、テレメトリ モデルではなくハーネスが性能を決める 2026 年に入ってから、ハーネスの重要性を示す数値データが相次いで公開されています。 ハーネス変更だけで性能が 10 倍に ベンチマーク結果によると、ツール形式を変えただけで 15 モデルすべてのスコアが改善しました。最も劇的だったのは Grok Code Fast 1 で、6.7% から 68.3% に跳ね上がり約 10 倍でした。モデルの重みには一切手を加えていません。 同じモデルでもスキャフォールドで倍近い差 Claude Opus 4.5 は、あるスキャフォールドで 42%、別のスキャフォールドで 78% を達成しました。同じモデルでも、ハーネスの設計次第で性能が倍近く変わります。 ...

オープンソース AI は「無料」でも「民主化」でもない — 重みの公開と推論コストの間にある物理法則の壁 @kubotamas 氏が X で共有した、Anthropic CEO Dario Amodei の発言が議論を呼んでいます。 AIのオープンソース化は無料でも民主化でもない。モデルの重みをダウンロードすることは出来ても、実際に推論するのにコストがかかる。AIは従来のオープンソースとは本質的に異なる。重みを手に入れても計算資源がなければ、解釈・改変することはできない。オープン化という約束は物理法則の壁で制限されている この投稿は、@r0ck3t23 氏（Dustin）のツイートを引用しています。Dustin 氏は Amodei の動画インタビューから「オープンソース AI は無料ではなかった。一度もそうだったことはない」とまとめ、1,200 以上のいいねを集めました。 本記事では、この「オープンソース AI の幻想」の構造を掘り下げます。 Amodei の主張 — 「これは Linux ではない」 Dario Amodei はインタビューの中で明確に述べています。 “It’s not free. You have to run it on inference and someone has to make it fast on inference.” （無料ではない。推論を実行する必要があり、誰かがそれを推論で高速にする必要がある） “This is not Linux. You can’t see inside.” （これは Linux ではない。中身は見えない） 従来のオープンソースソフトウェア — Linux、PostgreSQL、React — は、ソースコードを読み、理解し、フォークし、改変できます。ノートパソコン 1 台で動かせます。しかし AI モデルの「重み」は、数百ギガバイトの数値の羅列です。ソースコードのように「読んで理解する」ことはできません。 ...

テストダブル完全分類ガイド — Mock, Stub, Spy, Fake, Dummy の違いを図解で理解する t_wada 氏（和田卓人氏）のポストが、テストダブルの分類について「混乱しがちなテストダブルの分類については、この図がおすすめです」と NTT の解説記事を紹介しています。テストダブルという用語は現場でよく使われますが、「全部モックと呼んでしまう」「Stub と Mock の違いが曖昧」という混乱が起きがちです。この記事では、xUnit Test Patterns に基づく正確な分類を整理します。 テストダブルとは テストダブルは、映画のスタントダブル（代役）から名付けられた用語です。テスト対象のコード（SUT: System Under Test）が依存するコンポーネント（DOC: Depended-on Component）の「身代わり」として使うオブジェクトの総称です。 Gerard Meszaros が著書 xUnit Test Patterns で体系化し、Martin Fowler が “Mocks Aren’t Stubs” で広めました。 なぜテストダブルが必要か 外部依存の排除: データベース、外部 API、ファイルシステムなどの影響を受けずにテストできる 再現困難な条件のテスト: ネットワーク障害、ディスクエラーなどの例外条件を再現できる テスト速度の向上: メモリ上で動作するため高速に実行でき、並列動作も容易 決定性の確保: 外部環境に左右されない安定したテスト結果を得られる SUT と DOC の関係 テストダブルの分類を理解するには、まず情報の流れを整理する必要があります。 テスト → [直接入力] → SUT → [直接出力] → テスト ↕ [間接入力/間接出力] ↕ DOC 用語 意味 例 SUT (System Under Test) テスト対象 テストしたいクラス・関数 DOC (Depended-on Component) SUT が依存するもの DB、外部 API、時刻関数 直接入力 テストから SUT に渡す値 関数の引数 直接出力 SUT からテストに返る値 関数の戻り値 間接入力 DOC から SUT に渡される値 DB のクエリ結果、API のレスポンス 間接出力 SUT から DOC に渡す値 DB への書き込み、API へのリクエスト テストダブルは、間接入力と間接出力のどちらを制御するかで分類されます。 ...

リクルート新卒研修の React 資料が「無料で最高の教材」と言われる理由 sigumataityouda 氏のポストが、リクルートの新卒研修資料を「React を語る上で欠かせないもの」「完成度が非常に高い」と紹介しています。リクルートは 2017 年から毎年、新卒エンジニア向け研修資料を無料公開しており、React 研修資料は特に業界で高く評価されています。 React語る上で欠かせないものとしてリクルートの新卒研修資料というのもがある。完成度が非常に高い。 リクルートの React 研修資料とは React 研修 (2024) は、リクルートのエンジニアコース新卒研修「BootCamp」で使われている講義資料です。約 170 スライド以上で構成され、Speaker Deck で無料公開されています。 研修の位置づけ リクルートの新卒エンジニアは配属前に約 3 ヶ月間の BootCamp を受講します。2024 年度は 24 講座以上が開講されており、React 研修はフロントエンド技術スタックの中核として位置づけられています。 研修カテゴリ 主な講座 フロントエンド JavaScript、TypeScript、React、Next.js バックエンド データベース設計、API 設計 品質・テスト テスト駆動開発（講師: t_wada 氏） セキュリティ セキュリティ演習 AI テキスト生成 AI 活用 マインドセット ソフトウェアエンジニアとしての姿勢と心構え 最初の講座「ソフトウェアエンジニアとしての姿勢と心構え」は、技術顧問の t_wada 氏が担当し、「技術の学び方を学ぶ」ことに重点を置いています。 資料の構成 React 研修資料は 5 つのセクションで構成されています。 1. Web アプリ開発の変遷 React を学ぶ前に、Web アプリケーション開発がどう進化してきたかを整理します。 世代 アーキテクチャ 特徴 第 1 世代 MPA（クラシック SSR） サーバーが HTML を生成、ページ遷移ごとにリロード 第 2 世代 MPA + jQuery DOM 操作で部分的な動的 UI を実現 第 3 世代 SPA（CSR のみ） クライアントで描画、リッチな UX 第 4 世代 SPA（CSR + 事前レンダリング） SSR / SSG で初期表示を高速化 この変遷を理解することで、「なぜ React が必要になったのか」という文脈が掴めます。jQuery 時代の命令的 UI と React の宣言的 UI の違いを、歴史的な流れの中で説明しているのが特徴です。 ...

name: security-check description: Claude Code 利用における情報漏えいリスクをチェックする。 Auto Memory や CLAUDE.md への機密混入、.env の gitignore 漏れ、機密ファイルの存在などを検査する。 Claude Code の利用に関する情報漏えいリスクをチェックしてください。 チェック対象 以下の 4 カテゴリを順番に検査する。 1. Auto Memory の機密スキャン ~/.claude/ 配下の memory ファイルを検査する: 以下のパスを Glob で列挙する: ~/.claude/projects/*/memory/*.md ~/.claude/projects/*/memory/**/*.md 各ファイルを Read で読み込み、以下のパターンを Grep で検出する: API キー・トークン: (?i)(api[_-]?key|secret[_-]?key|access[_-]?token|bearer)\s*[:=]\s*\S+ パスワード: (?i)(password|passwd|pwd)\s*[:=]\s*\S+ AWS 認証情報: (?i)(AKIA[0-9A-Z]{16}|aws[_-]?secret) 接続文字列: (?i)(mysql|postgres|redis|mongodb):\/\/\S+ 個人情報パターン: メールアドレス、電話番号、マイナンバーらしき数字列 金額・契約情報: (?i)(契約金額|単価|請求|売上)\s*[:：]\s*[\d,￥¥$]+ 顧客 ID の具体値: (?i)(顧客id|customer[_-]?id|ユーザーid|user[_-]?id)\s*[:=：]\s*\d+ 検出があれば、ファイルパス・行番号・該当箇所を報告する 2. CLAUDE.md の機密スキャン プロジェクトの CLAUDE.md およびグローバルの ~/.claude/CLAUDE.md を検査する: 両ファイルを Read で読み込む チェック 1 と同じパターンで Grep 検査する 加えて、以下も確認する: URL にトークンやキーが含まれていないか（?token=, ?key=, ?secret=） 内部 IP アドレスやホスト名が含まれていないか CLAUDE.md はリポジトリにコミットされるため、検出時は即時対応を推奨として強調する 3. 機密ファイルの gitignore チェック プロジェクトルートで以下を確認する: ...

東京大学が無料公開した「思考の解像度を上げる」全118スライド – 深さ・広さ・構造・時間の4軸フレームワーク @MacopeninSUTABA（かずなり｜生成AI×ビジネスハック）氏のポストが話題です。 東京大学が無料公開した「思考の解像度を上げる全ノウハウ」が凝縮された資料が有益。「解像度が低い＝深さ・広さ・構造・時間の不足」という定義から、分析を劇的に深めるテクニック、そして「実装可能」なレベルまで鮮明にする方法まで、余すことなく学べる。 東京大学 FoundX ディレクター・馬田隆明氏が SpeakerDeck で公開しているスライド「解像度を上げる」は、累計 570 万回以上閲覧された「神スライド」として知られています。本記事では、このスライドの核心である「4つの視点」と「48の実践パターン」を掘り下げます。 「解像度」とは何か ビジネスの現場で「あの人は解像度が高い」という表現を耳にすることが増えました。馬田氏はこの「解像度」を次のように定義しています。 顧客の状況や課題、次に取るべきアクションが鮮明に見えている状態 逆に、解像度が低いとは「思考や事実認識が粗い」状態です。つまり、課題を構成要素に分解できておらず、各要素の理解が浅い状態を指します。 重要なのは、解像度は単に「知識量が多い」ことではないという点です。情報を持っていても、それを構造化し、深く掘り下げ、時間軸で捉えられなければ、解像度は低いままです。 4つの視点 スライドの中核をなすのが、解像度を構成する 4 つの視点です。 視点 問い 低い状態 高い状態 深さ なぜそうなるのか？ 表面的な症状だけを見ている 根本原因まで掘り下げている 広さ 他にどんな可能性があるか？ 1つのアプローチしか検討していない 複数の視点・手法を比較している 構造 要素間の関係はどうか？ 情報がバラバラで整理されていない 因果関係と優先順位が明確 時間 過去から未来へどう変化するか？ 現在のスナップショットだけ 経時変化とプロセスを捉えている 馬田氏が繰り返し強調するのは、4 つの視点のうち最も不足しがちなのは「深さ」であるという点です。多くの人は課題を広く浅く捉えることはできても、1 つの課題を徹底的に掘り下げることが不十分だと指摘しています。 問題と解決策の両面で解像度を上げる このフレームワークのもう一つの特徴は、解像度を問題側と解決策側の 2 軸で捉える点です。 問題の解像度 解決策の解像度 深さ 根本原因の特定 実装の具体性 広さ 顧客セグメントの網羅 代替手段の検討 構造 課題間の因果関係 アーキテクチャ設計 時間 課題の変遷 ロードマップ ビジネスで価値を生むには、「顧客の課題」と「それに対応する解決策」の両方の解像度を上げる必要があります。どちらか一方だけでは不十分です。 48 の実践パターン 書籍版では、4 つの視点ごとに具体的なアクションが「型」として整理されています。「情報 × 思考 × 行動」を組み合わせた 48 のパターンです。代表的なものを紹介します。 ...

組織の課題管理から個人のタスク整理と優先度づけへ — Claude Code によるタスクトリアージ 各システムの役割と利用者 システム 主な利用者 目的 Backlog 利用者側の責任者・管理部門 利用者が課題を把握・確認するため Asana 開発会社の PM・経営者 開発会社の責任者が状況を把握するため GitHub 開発担当者 作業担当者が実装・コード変更を管理するため 3層の責任構造 利用者（顧客） 開発会社（経営・PM） 開発会社（作業担当） │ │ │ Backlog Asana GitHub 課題確認会で 経営判断・ Issue/PR で 進捗レビュー リソース配分 実装を管理 各システムは異なるステークホルダーが、それぞれの責任範囲で状況を把握するために存在する。 これは冗長ではなく、報告先ごとに適切な粒度・視点で情報を提供するための構造。 担当者の課題: 「今何をすべきか」の判断 3システムはどれも他者への報告用であって、担当者が「自分が次に何をやるか」を整理する場所ではない。 システム 読者 自分の優先度確認に使えるか Backlog 利用者の責任者 △ 顧客視点の優先度であって自分の作業順ではない Asana 開発会社の経営・PM △ 経営視点のフィルタがかかっている GitHub (epm-server) 作業担当者 △ Issue は技術タスク単位で、全体俯瞰しにくい 解決策: Claude Code でタスクトリアージ → プライベートリポジトリの Issue に記録 タスクトリアージ（状況分析と優先度づけ）は Claude Code セッションで行い、結論の記録先は社内プライベートリポジトリの GitHub Issue に置く。 ...