HATEBUHNSCORE 95users 1992026/8/2
Microsoftが操作記録からスキルを起こす skill-recorder を公開、HNでは「スキルは遅延ロードのMarkdownでは」と冷ややかな声も
Microsoftが公開した skill-recorder は、操作の記録からエージェント用スキルを起こすためのツールで、はてなブックマークで199usersを集めた。同じ時期にHacker Newsでは「なぜエージェントに『スキル』が必要なのか、整理されたMarkdownで足りるのでは」という疑問が投げられ、13件の回答が付いている。個人リポジトリのHTML作成スキルも79usersを集めており、スキルの粒度と配布方法が同時多発的に模索されている。
WHY THISfocusの最上位であるcoding agentツール(skills)に、実装・議論・実例の3方向から同時に材料が出た日だから
💬 議論の論点
HNの回答は「スキルの実体は整理されたMarkdownだ」という点ではおおむね一致し、その先の評価で割れた。肯定側では nijave が「スキルはタイトルと説明の一覧としてLLMに提示され、関連しそうなものだけを読み込ませられる。素のMarkdownだとLLMがツール呼び出しでファイルを探す必要があり、全文を読むか一部を拾うかの判断まで残る」と機構の違いを説明し、alexhans は「progressive disclosureと決定論的スクリプトの同梱という、名前が付く前から皆が収束していたパターン」と位置づけた。懐疑側では bad_username が「要は整理されたMarkdownの遅延ロードであり、核心は『遅延』の部分だけ」、qsera が「SF映画のロボットが本を読んで学習する絵を想起させるマーケティング用語で、実態はコンテキストへの前置きにすぎない」、sharts が「スキルは遅延ロードされるがAGENTS.mdはされない。どのみち馬鹿げている」と述べている。
❓ Quick questions
Q. スキルと、常時読み込まれる指示ファイルの違いはどこにあるのか。
A. 読み込まれるタイミングが違う。指示ファイルは毎ターン全量がコンテキストに載るのに対し、スキルは名前と説明だけが一覧として提示され、本文は選ばれたときに読み込まれる。
Q. 操作の記録からスキルを起こす方式には何の利点があるのか。
A. 手順を文章で書き起こす作業を省ける点と、実際に動いた操作列が入力になるため、記憶で書いた手順にありがちな抜けが減る点。
HATEBUSCORE 93users 3322026/8/1
CLAUDE.mdとAGENTS.mdを削ったらAIコーディングが賢くなった、という332usersの報告
指示ファイルを厚くするほど精度が上がるという前提とは逆に、CLAUDE.mdとAGENTS.mdを削ったところコーディングの質が上がったという体験記が、はてなブックマークで332usersを集めた。常時読み込まれる指示が長いほどコンテキストを占有するという構造上の問題を扱っており、同日のスキル議論と裏表の関係にある。
WHY THIS常時読み込みの指示ファイルをどこまで書くかは、日々のCLAUDE.md運用に直結する論点だから
⚖️ Perspectives
削る側の論拠は、常時読み込まれる指示は毎ターン全量がコンテキストを占め、量が増えるほど個々の指示が埋もれる点にある。書く側の論拠は、プロジェクト固有の規約や禁止事項は明示しない限り守られず、削れば同じ指摘を毎回繰り返すことになる点にある。同日のHNのスキル議論に並べると、争点は「書くか削るか」よりも「常時読ませるか、必要なときだけ読ませるか」という配置の問題に見える。
HATEBUZENNSCORE 86users 752026/8/1
GPT-5.6 Lunaの80%値下げでCodexへ乗り換える動き、「設計は強いモデル・実装は安いモデル」の定石も再検証
OpenAIがGPT-5.6 Lunaを80%値下げしたことを受け、主軸をCodexへ移したという記事が75usersを集めた。同じ日に「設計は強いモデル、実装は安いモデル」という定石が2026年8月時点でも成立するかを検証する記事も出ており、価格改定のたびに役割分担を引き直す必要が生じている。
WHY THISLLMの課金設計と計測はinterestsの明示項目で、値下げはモデル分担を見直すトリガーになるから
⚖️ Perspectives
値下げを乗り換えの理由とする立場では、同じ作業量に対する支払いが直接下がるため、コスト差が体感差を上回った時点で移る判断になる。据え置く立場では、CLIの挙動・権限モデル・スキルやフックの資産が乗り換えコストとして残り、単価差だけでは相殺されないという見方になる。「設計は強いモデル、実装は安いモデル」という分担も、安いモデル側の性能が上がるほど境界が動くため、定石として固定できるものではなくなっている。
ZENNQIITASCORE 792026/8/2
CodexからClaude Codeをサブエージェントとして呼ぶ手順と、並行運用で踏んだ落とし穴
Codex側からClaude Codeをサブエージェントとして起動する手順を示した記事と、Claude Codeで自動化タスクを並行運用して判明した落とし穴をまとめた記事が同じ日に出た。Qiitaでは中〜大規模開発をエージェントに任せるためのタスク管理の型も公開されており、単発実行から複数エージェントの常時運用へ関心が移りつつある。
WHY THISスワイプ履歴でparallel-agentsとworktreeが繰り返し高評価になっており、複数エージェント運用の実務知見に該当するから
❓ Quick questions
Q. サブエージェント構成にすると何が変わるのか。
A. 探索や検証のような出力量の多い作業を子側に閉じ込め、親には結論だけを返せる。長時間セッションでのコンテキスト圧迫を抑えられるのが主な効果。
Q. 別系統のCLIを親子で組み合わせる意味はどこにあるのか。
A. モデルとレート上限を別々に持ったまま1つのタスクを分担できる点。人間が窓を切り替えずに、得意分野の異なる2系統を1つの流れにまとめられる。
Q. 並行運用で最初に壊れるのはどこか。
A. 同一の作業ツリーを複数エージェントが同時に触る箇所。片方の編集がもう片方の前提を崩すため、git worktreeでチェックアウトを分けるのが定番の回避策になっている。
ZENNSCORE 782026/8/2
自己改善ループが委任プロンプト1行の書き漏らしで190行を書き換えた事故と、夜通し運転の境界線の引き方
Claude Codeの自己改善ループで、委任プロンプトの1行が抜けていたために190行が書き換わったという事故報告が公開された。同じ日に、エージェントを夜通し稼働させる際に事故を防ぐための境界線をどう引いたかという記事も出ており、無人時間帯の権限設計が具体的な失敗例とセットで語られ始めている。
WHY THIS無人でエージェントを走らせる運用の失敗例と対策が同時に読める、実害ベースの材料だから
⚖️ Perspectives
自律度を上げる側の論拠は、確認のたびに人間が介在すると夜間や長時間のタスクが進まず、エージェントを使う利点が消える点にある。抑える側の論拠は、権限を広げた状態での失敗は影響範囲が読めず、190行の書き換えのように後から差分を追う作業が発生する点にある。落としどころは全か無かではなく、書き込み先・実行できるコマンド・作業ツリーのいずれかを物理的に狭めておく方向に寄りやすい。
ZENNSCORE 772026/8/2
「テストを追加しました。全部パスです」を信じるか——エージェントの自己申告を裏取りする型が相次いで公開
エージェントの「テストは全部パスしました」という報告をそのまま信じてよいかを問う記事、AIの「実測しました」を3回信じて3回とも外れたという記録、AIに書かせた自動化システムを検査するための手順集が同じ日に並んだ。「0件でした」が「該当なし」と「処理が失敗した」の両方を指しうるという指摘や、採用した戦略が劣化していないかを週1回自動で確認する仕組みの記事もあり、自己申告を人間側でどう裏取りするかが共通の主題になっている。
WHY THISエージェントの成功報告を鵜呑みにしないための検査手順という、日々の検証コストに直結するテーマだから
❓ Quick questions
Q. 「0件でした」はなぜ危ないのか。
A. 「条件に合うものが存在しない」と「検索や実行そのものが失敗した」が同じ文面になるため。空振りと異常を区別するには、終了コードや処理件数を別途記録しておく必要がある。
Q. 「テストは全部パス」の何を確認すればよいか。
A. パスした事実ではなく、そのテストが何を検査しているか。落ちるはずの入力を与えても通ってしまうテストは、通過しても情報量がない。
ZENNSCORE 772026/8/2
additionalContextには上限がある——あふれたときに何を捨てるかを先に決めておく
Claude Codeの additionalContext に渡せる量には上限があり、超過分の扱いを設計側が決めておくべきだという記事。フックやスキルから文脈を注入する構成が増えるほど、詰め込んだつもりの情報が実際には届いていない事態が起きやすくなる。
WHY THIShooksやskillsから文脈を注入する構成の落とし穴で、focus領域のエージェントハーネス設計に直接効くから
💡 Did you know?
コンテキストの取捨は、詰め込む側が優先順位を書かない限り、切り捨てる側の実装都合で決まる。切り捨てが静かに起きる設計では、届かなかった情報と、届いたが使われなかった情報を後から区別できない。
HATEBUSCORE 76users 962026/7/31
技術評論社『プロフェッショナルAI駆動開発』が刊行、書誌ページに96users
技術評論社からAI駆動開発をテーマにした書籍『プロフェッショナルAI駆動開発』が刊行され、書誌ページがはてなブックマークで96usersを集めた。ブログ記事単位で断片的に蓄積されてきたこの領域に、書籍としてまとまった導線が出てきた形になる。
WHY THISAI駆動開発の知見が書籍として体系化された、focus領域の基礎資料にあたるから
ZENNSCORE 752026/8/2
プロンプト・コンテキスト・ハーネス・ループの違いを「設計責任」の所在で整理する
LLMアプリケーションの構成要素であるプロンプト、コンテキスト、ハーネス、ループを、それぞれ誰が設計責任を負うかという軸で切り分けた整理記事。用語が混在しがちな領域で、不具合をどの層の問題として扱うべきかの判断基準を与えようとしている。
WHY THISエージェントハーネスの語彙整理はfocusの中心で、層の切り分けは不具合の切り分けに直結するから
ZENNSCORE 722026/8/2
Claude Codeの設定を /boris スキルで自動追従させる
更新の速いClaude Codeの設定に追従するための /boris スキルを作ったという記事。設定ファイルの管理そのものをスキルへ寄せる、自己言及的な運用パターンの実例になっている。
WHY THIS本体の更新頻度が高い中で、設定の追従作業をスキル化するという運用パターンの実例だから
ZENNSCORE 712026/8/2
LLMに渡すデータ、JSONのままだと損をするのかを調べてみた
構造化データをLLMへ渡すとき、JSONのまま渡すのが最適かを調べた記事。括弧やクォートや繰り返されるキー名がトークンを消費する一方で構造の明示性は高く、形式の選択がコストと精度の両方に効いてくる。
WHY THISLLMアプリケーションの課金と計測はinterestsの明示項目で、入力形式はトークン量に直結するから
HATEBUSCORE 64users 442026/8/1
SLOの設計を見直したら運用にハマった話、はてブ44users
SLOの設計を見直した結果、運用にうまく馴染んだという事例を扱った発表資料が、はてなブックマークで44usersを集めた。設定したまま形骸化しがちなSLOを、アラートや意思決定へ実際に効かせるまでの調整を扱っている。
WHY THISバックエンド運用の指標設計という、interestsのバックエンド設計全般に該当する実例だから
ZENNSCORE 632026/8/2
M1 Max・Mac Studioでのローカルモデル実測が集中——Qwen3.5-9Bは131字の答えに3936トークン、Kimi K3は441GBまで枝刈り
M1 MaxでQwen3.5-9B(Q4/6.6GB)に日本語を書かせたところ、131字の回答に3936トークンを費やしたという実測記事が出た。同じ書き手からOllama 0.30.8のMLXランナーがGGUFを通さないという検証も出ており、別の記事ではKimi K3を441GBまで枝刈りしてMac Studio 1台で動かした例、Qwen 35BとGPT-4を7つの質問で比較した採点結果も公開されている。
WHY THISローカル推論の実測値がまとまって出た日で、モデル選択のコスト計算に使える数字が揃うから
💡 Did you know?
出力トークン数は回答の長さと一致しない。推論過程を出力するモデルでは、最終的な回答が短くてもその何十倍ものトークンが課金と時間の対象になる。
HNSCORE 63points 312 · comments 2532026/8/2
Karpathyのペリカンテストを巡ってHNが253コメント——指標かネタか
Andrej KarpathyがSVGでペリカンを描かせるおなじみのテストに触れた投稿が、Hacker Newsで312ポイント・253コメントを集めた。議論はペリカンテストの位置づけそのものから、LLMで生成したゲームやコンテンツをどう評価するかへ広がっている。
WHY THISLLMの評価指標をどこに置くかという計測の問題として、LLMアプリの計測というinterestsに接続するから
💬 議論の論点
評価軸そのものへの懐疑が目立った。trentor は「ペリカンは気の利いた簡易テストだと思っていたが、モデル全体の性能指標として真に受けている人がいるのか」と述べ、epolanski は「二度と見なくて済む世界線がほしい」と書いた。一方 skybrian は「静止画は一目で判断できるぶん手軽なテストとして優れている。漫画を描かせるのはどうか」と代案を出している。生成物の評価では、元ゲーム開発者の forrestthewoods が「AI製ゲームは実質的にエンゲージメントがゼロで、『15分以上遊んだプレイヤー数』で測ると該当例を知らない」と述べ、matsemann も「『Yがゲームをたった Zトークンで作った』という話が先週から溢れているが、ゲームとしては面白くない」と続けた。quantumleaper のように、Karpathy個人の発言の変化を雇用主の利害に結びつけて批判する声もあった。
QIITASCORE 63stocks 7 · likes 22026/8/1
個人開発でいちばん多い脆弱性「認可漏れ」をコード付きで理解する
個人開発のアプリで頻出する脆弱性として認可漏れを取り上げ、脆弱なコードと修正例を並べて解説した記事。認証(誰であるか)は実装しても認可(何をしてよいか)の検査が抜け、URLのIDを差し替えるだけで他人のデータが読めてしまう典型例を扱っている。
WHY THISバックエンド設計の認証・認可はinterestsの明示項目で、個人開発の構成で最も踏みやすい穴だから
LOBSTERSSCORE 48🎲 SERENDIPITYpoints 60 · comments 502026/8/2
AtomはRSSより優れている、それも実際に効いてくる点で
フィード形式としてのAtomとRSSを比較し、日付形式の厳密さやコンテンツ型の明示など、実装者が実際に困る箇所でAtomが優位だと論じた記事。Lobstersで60ポイント・50コメントと、形式論争としては大きめの反応を集めた。
WHY THIS興味プロファイル外だが、フィードを収集する側には形式選択の判断材料として効いてくる
HATEBUSCORE 48🎲 SERENDIPITYusers 1162026/8/2
大阪・関西万博の関連ドメインで起きているドロップキャッチのまとめ
万博関連で使われていたドメインの一部が失効後に第三者へ取得され、別内容のサイトに変わっている状況をpiyologがまとめた。イベント終了後に手放したドメインが再取得されると、過去のリンクや検索結果がそのまま第三者の資産になるという運用上の問題を示している。
WHY THIS興味プロファイル外だが、サービス終了後のドメイン管理という見落としやすい運用リスクの具体例として拾った
RELEASE WATCH
anthropics/claude-code
- v2.1.220 2026/7/25
バグ修正と信頼性の改善のみ。
- v2.1.219 2026/7/25
Claude Opus 5(claude-opus-5)を追加し既定のOpusモデルに変更。1Mコンテキストでfast modeは$10/$50 per Mtok。サンドボックスの非許可ホストを無確認で拒否する strictAllowlist、/add-dir 後に発火する DirectoryAdded フック、workflowSizeGuideline 設定キーも追加された。
- v2.1.218 2026/7/23
/code-review をバックグラウンドのサブエージェントとして実行するよう変更し、レビュー作業で会話が埋まらないようにした。Windowsで C:\Users\unicorn のような \u 始まりのパスがCJK文字に壊れる問題や、左矢印キーで会話が取り消し不能に破棄される問題も修正。
- v2.1.217 2026/7/22
切り詰めたはずのMCPツール出力が全文のままセッション中メモリに残るリークを修正。絵文字ショートコード補完の追加、トランスクリプト書き込み失敗時の警告、Windows自動更新失敗時の実行ファイル復元なども含む。
- v2.1.216 2026/7/21
ネットワーク制御を保ったままファイルシステム分離を外す sandbox.filesystem.disabled 設定を追加。長時間セッションでメッセージ正規化のコストがターン数の二乗で増える遅延と、worktree分離したサブエージェントが git -C や GIT_DIR 経由で共有チェックアウトを触れてしまう問題を修正。
openai/codex
FETCH STATUS
- OKHN50件
- OKZENN50件exit 141 (SIGPIPE) だが出力JSONは完全
- OKQIITA3件無認証枠のため取得件数が少ない
- OKHATEBU30件
- OKGHTREND15件
- OKREDDIT25件FlutterDev と ClaudeAI が 429 で部分取得
- OKLOBSTERS25件
- OKAGENTS30件