タグ

2026年6月29日のブックマーク (4件)

  • Claude Codeのセッションを見下ろし型オフィスとして可視化するツールを作った

    作ったもの Claude Code のセッションを、見下ろし型のオフィスとして眺められるデスクトップアプリを作りました。 ローカルの ~/.claude/ を監視していて、エージェントを社員、動いているセッションをオーケストレーターとして描いています。誰が今なにをしているか、どの hooks がいつ発火したか、といったものがリアルタイムで動く、というものです。 リポジトリはこちら。macOS 専用です。 なぜ作ったのか 既存のプロジェクトを Claude Code で触っていると、チーム固有のコーディングルールを守ってほしいとか、既存の実装に合わせてほしい、みたいな要求が当然出てきます。で、これを守らせようとプロンプトやスキルを整備しても、セッション1つだけでは守られないことが多いです。 なので、ちゃんとチェックして、ルールから外れていたら指摘してブロックするためのセッションを hooks

    Claude Codeのセッションを見下ろし型オフィスとして可視化するツールを作った
  • LLM 事後学習 (SFT / RLHF / DPO / RLVR / GRPO / 自己蒸留) を教師信号から眺める

    ここで \pi_\theta は、入力 x に対して応答 y を出す確率分布です。強化学習の言葉では、この確率分布を方策と呼びます。LLM では、ここまでの文脈から次に出すトークンを選ぶ確率分布として扱います。応答全体の確率は、各時点の出力確率の積として分解できます。 \pi_\theta(y \mid x) = \prod_{t=1}^{T} \pi_\theta(y_t \mid x, y_{\lt t}) 模範応答から学ぶ 回答形式、文体、基的な解き方を入れるには、入力と模範応答の組を使います。応答を採点したり比較したりする前に、まず望ましい出力の形をまねさせる段階です。 教師ありファインチューニング (Supervised Fine-Tuning; SFT)[7:3] は、入力 x と模範応答 y^\ast の組を使って、模範応答の尤度を上げます。目的関数は、次の負の対数尤度です

    LLM 事後学習 (SFT / RLHF / DPO / RLVR / GRPO / 自己蒸留) を教師信号から眺める
  • Claudeに「オントロジー」を持たせたら、コスト半分・3倍速になるかも

    Komlock lab VPoE阿部(@takupeso)です。 ClaudeCodeに既存設計・コードに関するナレッジを渡すとき、僕はずっと同じやり方をしていました。@でファイルを指定し、CLAUDE.mdにルールを足し、.claudeを整備していました。 これももちろん有効な手法です。ただ、AIの調子でアウトプットの精度にブレが出ます。同じナレッジを渡しても、関連する事実をうまく結びつけてくれる日もあれば、そうでない日もあります。もっと安定して効く情報整理の手法はないのかな、と思っていました。 そこで「オントロジー」について調べてみました。情報整理の文脈でたまに聞くものの、正体も導入方法も曖昧なままだった概念です。 調べてわかったのは、ブレの原因が「量」ではなく「形」にあるということでした。@指定もMarkdownの箇条書きも、結局は資料をフラットに並べているだけ。Claudeは一枚ず

    Claudeに「オントロジー」を持たせたら、コスト半分・3倍速になるかも
  • Web 標準の議論を LLM-Wiki で追う | blog.jxck.io

    Intro Web 標準の議論を長いこと追ってきたが、追えば追うほど、追うべきものは増えていく。 また、最新の情報を追うこと自体は比較的簡単でも、なぜそうなったのかといった経緯を過去にさかのぼって調べるのは、なかなか難しい。 これを LLM-Wiki を使うことで大幅に改善することができた。 標準化の議論 Web 標準はある日突然降って湧くわけではない。 然るべきところで誰かがアイデアを出し、それを長い時間かけて議論し、実装しながら仕様を詰め、フィールドトライアルし、完成品が開発者の手元に届く。 最初に誰かが出すアイデアにも、「こういう問題がある」といったきっかけがある。それが今までできなかった理由も、標準化していける理由も、それ以前の議論と線形に流れる文脈の上にある。その文脈の中で、否定され消えていったものもたくさんある。 追うだけなら完成品と API だけを見ればよい。しかし、「なぜこ

    Web 標準の議論を LLM-Wiki で追う | blog.jxck.io