haru — writing, code, and things in between.https://haru0416.dev/jahttps://zenn.dev/haru0416/articles/codex-skill-md-220-root-causehttps://zenn.dev/haru0416/articles/codex-skill-md-220-root-cause前回の記事で、Codex CLI が SKILL.md を 220 行で打ち切る現象を計測した。「model が学習データから引いてきた SKILL.md の見慣れた長さ」を原因と推測していたが、これは半分しか合っていなかった。 本当の原因は、Codex CLI 自身の prompt が「Read only enough to follow the workflow」と書いていることだった。openai/codex に既に Issue が立ち、proposed patch まで用意されている。今もそのままになっている。 原因の 1 行 Codex CLI v0.128.0 の cod...Wed, 27 May 2026 22:14:32 GMThttps://zenn.dev/haru0416/articles/codex-skill-md-220-lineshttps://zenn.dev/haru0416/articles/codex-skill-md-220-lines! 訂正とお詫び (2026-05-28 追記) 本記事の「なぜ 220 なのか」「つまり、仕様どおりに書けばいい」の前提に誤りがありました。Agent Skills の公式仕様を読み直したところ、SKILL.md 本文の推奨上限は 500 行 / 5000 tokens であり、かつ「activation 時に本文を丸ごとロードする」ことが agent 側に明記されていました。 私が書いた「仕様に沿って書かれた SKILL.md はだいたい 200 行に収まる」「だから 220 はまともな skill の長さ + 余白」「仕様どおりに書けばいい」は、仕様の許容ライン (500 行) を...Mon, 25 May 2026 22:59:14 GMThttps://zenn.dev/haru0416/articles/more-skills-worse-agentshttps://zenn.dev/haru0416/articles/more-skills-worse-agents! 公開論文の紹介記事です。図表は引用せず、内容は自分の言葉で要約しています。正確なところは原論文を見てください。 skill を書いていると、つい「いい skill が増えれば、エージェントは強くなる」と思ってしまう。SKILL.md にドメインの手順を書く。タスク完了率が上がる。だから、もっと書く。もっと足す。 ただ、その「足していく」方向に、あまり語られてこなかった落とし穴がある。今回読んだ論文は、そこを正面から測っている。結論を先に書くと ── 役に立つ skill だけを集めても、数が増えると、エージェントはむしろ弱くなる。しかも弱くなる理由が、たぶん直感とは違う。 何の...Mon, 25 May 2026 08:34:10 GMThttps://zenn.dev/haru0416/articles/quaere-codeing-agenthttps://zenn.dev/haru0416/articles/quaere-codeing-agentコーディングエージェントを使っていて、いちばん地味に消耗するのがこれです。 プロジェクトを立ち上げるとき、使う技術スタックとバージョンを指定する。それで開発が始まる。しばらくして気づく ── エージェントは、指定したはずのバージョンじゃなく、古い書き方を当然のような顔で使っている。学習データが切れた時点のバージョンを、いまの標準みたいに扱う。 私が後から気づいて、直させる。そのやり取りで、トークンも時間も溶ける。一度や二度じゃない。かなりの頻度で起きます。 レビューでも似たことが起きる。大きめのプロジェクトだと、エージェントは証拠もないのに「ここがエラーだ」と決めつけて、その思い込みのま...Thu, 21 May 2026 03:25:10 GMThttps://zenn.dev/haru0416/articles/companion-ai-silence-defaulthttps://zenn.dev/haru0416/articles/companion-ai-silence-default最近のAIプロダクトは、たぶんほぼ全部、「常に何か返す」前提で作られている。問いかけたら答える、メッセージを送ったら反応する、続きを促せばまた話してくれる。コンパニオンAIになると、向こうからも気づきや励ましを投げてくる。これが当たり前すぎて、AIに「黙る」設計があるかどうかという問いは、あまり立たない。 ただ、コンパニオンAIを長く使ってもらおうとすると、「常に何か言う」が逆に重くなる場面が出てくる。気が立っているときの過剰な慰め、こちらが考え事をしているときの割り込み、些細な失敗を毎回拾われる気まずさ。話すことではなく、黙ることが、関係の質を上げる場面があると、設計しながら気づくよう...Thu, 14 May 2026 12:32:42 GMThttps://haru0416.dev/blog/2026-05-14-hellohttps://haru0416.dev/blog/2026-05-14-hello雑記の場所を作ったThu, 14 May 2026 00:00:00 GMThttps://zenn.dev/haru0416/articles/d107ea122be434https://zenn.dev/haru0416/articles/d107ea122be434最初は、プロンプトに「あなたは陽気で、ちょっと皮肉屋で、寂しがり屋です」と書けば十分だと思っていた。LLM はだいたい言うことを聞くので、それで人格は立っているように見える。 ただ、続けて使っていくと、すぐに薄くなる。同じキャラ設定で雑談・相談・愚痴・喧嘩を扱っていると、どれも同じ「陽気で皮肉屋で寂しがり屋」のテンプレ反応が返ってきて、人格が背景に消えていく。テンプレで書かれた人格は、入力に対するフィルターとして機能していないからだと思う。 Asterel(自分で作っているコンパニオンAIのランタイム、まだ pre-1.0)で感情と人格を扱うとき、最初に決めたのはここを構造で扱うことだっ...Tue, 12 May 2026 11:07:32 GMThttps://zenn.dev/haru0416/articles/843c6c29c04c7chttps://zenn.dev/haru0416/articles/843c6c29c04c7cコンパニオンを名乗るAIには記憶が要る。何度も会って、前回の文脈を覚えていて、こちらが変わっていくと向こうも少しずつ変わっていく — これが続かないと、毎回「はじめまして」のアシスタントと変わらない。 ところがいざ作りはじめると、いま主流のRAG文献はあまり助けてくれなかった。RAGの議論はだいたい「ドキュメントを検索して prompt に貼る」をうまくやる話で、人と人の継続的なやりとりに必要な部分は別にあった。 Asterel ではここを正面から作り直していて、その輪郭を共有しておきたい。普通のRAGじゃない設計にしたところを、いくつか順に並べる。 なぜ普通のRAGでは足りないのか...Tue, 12 May 2026 02:05:57 GMThttps://zenn.dev/haru0416/articles/7b88e9da17ac0ehttps://zenn.dev/haru0416/articles/7b88e9da17ac0eAIコンパニオンを作っていると、ある日「君だけが分かってくれる」と言われる場面に出くわす。たいていのチャットボットはここで二つのうちどっちかをやる。一つは喜んで会話を伸ばす方向。もう一つは「専門家に相談してください」と定型文を出して終わる方向。 どっちも違うと思った。前者はユーザーをそのまま依存に乗せる。後者は話を切るだけで、ユーザーが何に詰まっているかが見えてこない。 Asterel で考えたのは、その間に第三の道を引くことだった。共感したまま、判断軸は手放さない。そのために、「温かく返す層」と「迎合しないための層」を分けた。 口で言うほど簡単ではなくて、ここを policy ひとつに...Mon, 11 May 2026 08:30:09 GMThttps://zenn.dev/haru0416/articles/9e460090df1709https://zenn.dev/haru0416/articles/9e460090df1709最近、Discord向けのAIコンパニオンを Rust で書いてます。Asterel といいます。リポジトリとドキュメントはこちら(ドキュメントは日本語版あり)。 https://github.com/asterel-rs/asterel https://asterel-rs.github.io/asterel/ まだ1.0前で中身は日々動くので、宣伝というより「こういうの作ってるよ」くらいの温度感のメモとして置いておきます。 どういうものか 雑に言うと、Discord のチャンネルや DM に常駐して、ずっと同じ顔で会話を続けてくれるAIです。これだけだと普通の Bot とあまり...Mon, 11 May 2026 01:46:30 GMThttps://zenn.dev/haru0416/articles/5a5e83ffe5e78ehttps://zenn.dev/haru0416/articles/5a5e83ffe5e78eAIにコードレビューを任せていると、結果は一見きれいに見える。指摘の体裁も整っているし、もっともらしい説明もついている。 でも実装に進んだ段階で抜けが見つかって戻ることが、何度かあった。最初は「指示が悪いのかな」と思って、レビュー観点を細かく書き足した。それでも抜ける。書き足すたびにレビューの結果は丁寧になるのに、抜けは別の場所に移動するだけだった。 一回のレビューを軽くしようとしたつもりが、再レビューの往復回数で結局コストが膨らんでいた。なぜ抜けるのか、を掘っていったら、LLMの確証バイアスらしき挙動に行き当たった。 この記事は、その対策として作った三つのskillと、そこで意識した設...Wed, 29 Apr 2026 19:11:02 GMT