説明スキルの比較：ELI5、Archify、Explainer
Anthropicのコミュニティプラグイン用リポジトリに、ELI5というスキルが公開されています。これは大きな絵と少ない言葉を使ったHTMLで、対象を視覚的に説明するスキルです。
ELI5はClaudeの目玉機能であるArtifactsのデモとして公開されたと解釈できそうですが、私たちがAIに仕事をどんどん任せている一方で、コーディングではソースコード本体を読む機会が減り、ドキュメントとして生成される文章も冗長で、専門的な語彙や会話のコンテキスト汚染がある、前提知識に頼ったものになりがちです。それを人間が読解するコストもばかにならないという課題があり、こうした説明系のスキルはその負担を減らすためにも受け入れられているものだと考えています。
筆者も最近はこのような説明系のスキルを積極的に試しています。本記事ではその中から特徴の異なる3つのスキルを紹介し、実際にAgent Skillsの仕組みの説明を生成して比べてみます。
絵本のように説明するELI5
ELI5のスキルは短く、題材について何も知らない人を想定しています。
System One Adapterを使ったJevとローカルモデルの分類タスク比較
前回の記事では、文章を渡すと型付きの判定と確率を返すJevというモデルを紹介しました。その後、TypeSafeに新しく登録しようとしたら、画面には「Sorry, new signups are paused」と表示されており、新規登録が止まっていました（9月25日時点）。Vercelによると、JevはAI Gatewayに登場してから24時間で、過去のどのモデルよりも多くの有料チームに使われたそうです。すごい。現在は新規登録できないため、本記事のサンプルを実行できるのは、TypeSafeの既存アカウントを持つ人だけです。
このビッグウェーブに乗って私も自分でJev互換のモデルを作ってみたいと思ったので、まずはJevのAPIと手元のモデルを同じ題材で比べる環境を作ることにしました。
そして、すでに独自のJevライクモデルを公開している人たちもいます。KevはQwenの公開重みを追加学習したモデルで、LayaはModernBERT系。Tev1もQwenを使った学習方法を公開しています。私もKevを日本語データセットで追加学習して精度の変化を見たり、麻雀の「何切る」問題で検証したりしまし
#21 Jev
TypeSafe AIが新たなモデル「Jev」を公開しました。
Introduction - TypeSafe AIJev is TypeSafe’s flagship model and the first System One model. Send state and typed questions; get structured answers your code can use directly.TypeSafe AI
2026年8月のニュースレター運用ふりかえり
先月から、本ニュースレターの運用と配信内容を月に一度振り返ることにしました。
今回はその8月分です。
投稿が少し遅れてしまったことをお詫びします。
7月に掲げた、情報量や発信量を減らして自分の判断を書くという目標に向けて、8月は調査と執筆の工程に結構集中していました。
調査と執筆に使う時間は増えた一方、有料ニュースレターとしての発信本数はかなり減ってしまったと思います。
工程の改善に加えて、今後はどのような内容をどのくらいの頻度で発信するか、考え直したいと思っています。
前回の報告以降に投稿した記事は以下のとおりです。
* 8月7日：#17: Muse Code
* 8月14日：#18 DeepSeek Harness Architecture
* 8月22日：Claude Codeのダイナミックワークフローを手書きする
* 8月24日：#19 Codex アプリ風の Obsidian テーマ Verso
* 8月29日：
AIエージェントに仕様書と決定記録を必要なときだけ読ませる試み
私は最近、ストリーミング音声認識APIを使ったMac向け文字入力アプリ「Whistt」を開発しています。このアプリのリポジトリでは、今までの経験を踏まえて、作業に必要な開発ドキュメントをAIエージェントに自動で読み込ませる手法を検証しています。
この取り組みの狙いは、少ない人数で、より大きな範囲のソフトウェアを作ることです。そのためには、仕様の決定や技術的判断の経緯を、必要なときにAIに読み込ませる必要があります。
仕様書と意思決定記録の役割を分ける
Whisttは、まずバイブコーディングでプロトタイプを実装し、その後で仕様書を整えました。立ち上げ時には、仕様書を先に作り、それをもとに実装を生成する仕様駆動開発（SDD）の進め方は採っていません。
仕様書は当初、Macアプリの一連の操作のうち、自動テスト化できていない部分を手で一つひとつ確認するためのチェックリストとして使っていました。QAフェーズで使うこうした項目は、今まではMarkdownの箇条書きやExcelシートにして、目視で確認していました。これをAIから使いやすいように、振る舞いや条件を一定の書式で書くGherki