Blog
dev-orchestra 1.2.1 で入った instructions を試しました。implementer やレビュアーへの決まった指示をリポジトリに書いておくと、毎回のプロンプトに入ります。どう表示され、どこに入り、指示を変える変更がどう扱われるかを、実際の出力で確かめます。 I tried instructions, added in dev-orchestra 1.2.1. Standing instructions for the implementer or reviewers written in the repository go into every prompt. I check, with real output, how they are shown, where they go, and how a change to the instructions is treated.
dev-orchestra の v1.1.0 から v1.2.1 までの変更をまとめました。計画を作業単位に分けて並べて走らせる機能、役割ごとに決まった指示を渡す機能、設計の前の質問、進み具合の報告の設定が入りました。Windows で出力を取り込んでいる人は、文字コードの変更に注意してください。 A roundup of dev-orchestra's changes from v1.1.0 to v1.2.1: running a plan as work units side by side, standing instructions per role, questions before the design, and settings for progress reports. If you capture its output on Windows, note the encoding change.
dev-orchestra 1.2.0 で入った作業単位を試しました。計画に ## Units を書き、2 つの作業単位を別々の git worktree で並べて Claude に実装させ、作業ツリーへマージし、最後の統合の作業単位をその場で走らせるまでを、実際のコマンドと出力で追います。 I tried the work units added in dev-orchestra 1.2.0. I wrote a ## Units section in a plan, had Claude implement two units side by side in separate git worktrees, merged them into the working tree, and ran the final integration unit in place, with the actual commands and output.
dev-orchestra を 1.0.0 から 1.1.1 に、Claude Code・Codex・Antigravity のそれぞれで実際に更新してみました。Claude Code は claude plugin update だけでは更新されず、先にマーケットプレイスの更新が要りました。今の版の確かめ方、CLI ごとの手順、更新したあとに確かめることをまとめます。 I actually updated dev-orchestra from 1.0.0 to 1.1.1 in each of Claude Code, Codex, and Antigravity. In Claude Code, claude plugin update alone did nothing; the marketplace had to be refreshed first. I cover how to check your version, the steps for each CLI, and what to check after updating.
dev-orchestra 1.0.0 で、自作のアダプタを一から書いてローカル LLM をレビュアーに加えてみました。プロンプトを受けて答えを返す小さな CLI と、50 行ほどのアダプタだけで繋がります。置き場所、doctor での確認、できる役とできない役、注意点までまとめます。 With dev-orchestra 1.0.0, I wrote my own adapter from scratch and added a local LLM as a reviewer. All it takes is a small CLI that takes a prompt and returns an answer, plus an adapter of about 50 lines. I cover where to put it, checking it with doctor, which roles it can and can't take, and the cautions.
dev-orchestra の役（ロール）ごとのモデルの指定方法、レビュアーの観点の選び方、分野の専門役を提案させる config suggest-roles を紹介します。わざとバグを仕込んだ変更を 9 人のレビュアーに見せて、人数を増やすと何が変わるかも測ってみました。 How to set the model for each role in dev-orchestra, how to choose reviewer focuses, and config suggest-roles, which proposes domain specialists. I also showed a change with deliberately planted bugs to 9 reviewers to see what changes as you add more of them.
dev-orchestra の初期設定で選ぶプリセット quality / standard / fast を、Claude Code だけ・Codex だけ・両方の 3 つの環境で実際に展開して比べました。役ごとのモデル、レビュアーの人数、コストを削る度合いがどう変わるか、どれを選べばいいかをまとめます。 I expanded dev-orchestra's setup presets quality / standard / fast in three environments (Claude Code only, Codex only, and both) and compared them. Here is how the per-role models, the number of reviewers, and how much cost is cut change, and which one to pick.
Antigravity にも dev-orchestra を入れてみました。話しかける場所としては普通に使えますが、Antigravity CLI（agy）に設計やレビューを任せるのは限定的です。できること・できないことと、おすすめの使い方をまとめました。 I installed dev-orchestra in Antigravity too. It works fine as the place you talk to, but handing design and review to the Antigravity CLI (agy) is limited. Here is what works, what doesn't, and how I recommend using it.
Codex にも dev-orchestra を入れてみました。Codex だけの環境でも動きますが、Claude Code と両方入れると、別々の会社の AI がレビューする推奨構成に自動でなります。Codex の場合だけの機能と注意点も最後にまとめました。 I installed dev-orchestra in Codex too. It works with Codex alone, but with both Claude Code and Codex installed, it automatically switches to the recommended setup where AIs from different companies review your code. I also summarized the Codex-specific features and caveats at the end.
Claude Code だけの環境に dev-orchestra を入れて、初期設定から1文の依頼までを試しました。インストールは2行、初回にプリセットを選ぶだけで、レビュアーも Claude だけで組まれます。Claude Code の場合だけの機能と注意点も最後にまとめました。 I installed dev-orchestra in a Claude Code-only environment and tried everything from the initial setup to a one-sentence request. Installation is two lines, and on first use you just pick a preset; the reviewers are made up of Claude alone. At the end, I also summarize the features and caveats specific to Claude Code.
Claude Code / Codex / Antigravity で動くプラグイン dev-orchestra の紹介です。何ができるか、公式の codex-plugin-cc との違い、Claude Code だけでも使う意味、そしてデメリットまでまとめました。 An introduction to dev-orchestra, a plugin that runs on Claude Code / Codex / Antigravity. I cover what it does, how it differs from the official codex-plugin-cc, why it's worth using even with Claude Code alone, and its downsides.
AIに書かせたコードを別のAIにもレビューさせたい。でも手作業でやると、ターミナル間のコピペと待ち時間で疲れ果てる。それを仕組みにしたプラグイン dev-orchestra の 1.0.0 を出したので、作った経緯と使ってみての感想をまとめました。 I wanted code written by one AI to be reviewed by other AIs too. Doing it by hand, copy-pasting between terminals and waiting wore me out. I released version 1.0.0 of dev-orchestra, a plugin that turns that into a system, and this post covers why I built it and how it has felt to use.
社外に出せないコードを、クラウドのAIに送らずにレビューする方法をまとめました。ローカルLLMをdev-orchestraのレビュアーに登録し、機密のものはローカルだけで、公開してよいものはクラウドのAIと併用します。ローカルLLMのレビューの実力と、呼び出し方ひとつでコードが外に出てしまう落とし穴も書きます。 How I review code that can't leave the company without sending it to a cloud AI. I register a local LLM as a dev-orchestra reviewer, use only the local model for confidential code, and combine it with cloud AI for code that can be shared. I also cover how good the local LLM's reviews really are, and the pitfall where a single choice of how you invoke it sends your code out anyway.
ローカルLLMの速度や品質を測るときに、結果を信用できるものにする手順をまとめました。同じ条件でも1割ぶれる、順番で結果が変わる、裏の処理で5倍ぶれる、採点器が壊れている。実際に踏んだ失敗から作った、測る前・測っている間・測ったあとのチェックリストです。 I put together the steps that make the results trustworthy when measuring the speed or quality of a local LLM. The same conditions vary by 10%, the order changes the result, background work causes 5x swings, and the grader is broken. This is a before, during and after checklist built from mistakes I actually made.
Ryzen AI ミニPCに96GBのメモリを積んでローカルLLMを動かし、実際に何GB使っているかを測りました。35BのMoEモデルで24GiB、コンテキストを上限の256Kまで伸ばしても28GiB程度です。32GB・64GB・96GBでそれぞれ何ができそうかを、実測と推定を分けて整理します。 I ran a local LLM on a Ryzen AI mini PC with 96GB of memory and measured how many GB it actually uses. A 35B MoE model takes 24GiB, and even with the context stretched to its 256K limit, it stays around 28GiB. I sort out what 32GB, 64GB and 96GB are each likely to handle, keeping measurements and estimates apart.
Ryzen AI 9 HX 370（Radeon 890M）のミニPCで、ローカルLLMを毎秒20トークン前後で動かすまでの手順を1本にまとめました。llama.cppのVulkan版を入れ、MoEモデルを選び、効く設定だけを入れて、llmと打つだけで使える状態にします。つまずいた点も全部載せています。 All the steps to run a local LLM at around 20 tokens per second on a Ryzen AI 9 HX 370 (Radeon 890M) mini PC, in one post. Install the Vulkan build of llama.cpp, pick an MoE model, add only the settings that help, and end up able to just type llm. Every stumbling point I hit is included.
Ryzen AI ミニPCでローカルLLMを動かすときに試した設定を、効果の大きさ順に1枚にまとめました。Vulkanは5.2倍、MoEは5.7倍。一方で、効かなかったもの、逆効果だったもの、そもそも無効だったものもあります。すべてこの機体での実測値です。 I put the settings I tried for running a local LLM on a Ryzen AI mini PC on one page, ordered by how much they help. Vulkan gave 5.2x, MoE 5.7x. Some settings did nothing, some backfired, and some were never enabled in the first place. Every number was measured on this machine.
ローカルLLMのサーバが、テキストしか使わないのに画像用のmmprojを毎回読み込んでいました。外すと速くなるかを、前回まとめたチェックリストに沿って測りました。1回目は計測中のずれが大きく速度について何も言えず、裏で別のAIセッションが動いていたと分かったので、止めて測り直しました。メモリは1GiB減り、速度は3%未満の差で変わりませんでした。既定は外すことにしました。 My local LLM server was loading the image mmproj on every start, even though I only use text. I measured whether dropping it makes things faster, following the checklist from my previous post. In the first run the drift during measurement was too large to say anything about speed, and it turned out another AI session was running in the background, so I stopped it and measured again. Memory went down by 1 GiB, and speed stayed the same, within 3%. I made dropping it the default.
ローカルLLM環境の構築と検証を13本の記事に書くあいだに、測定する側が間違っていた場面が19回ありました。比べ方、採点器のバグ、外からの割り込み、前提の取り違え、動いていなかった安全装置。気づいたきっかけを数えると、半分以上は「ありえない値」か「生データ」でした。測る前のチェックリストにまとめます。 While writing 13 posts about building and testing my local LLM setup, the measuring side was wrong 19 times: how I compared, bugs in the grader, interruptions from outside, wrong assumptions, and safety mechanisms that weren't working. Counting how I noticed, more than half came from "impossible values" or "raw data". I turn them into a checklist for before measuring.
ローカルLLMに128Kトークンの文書を読ませ、20か所に仕込んだ事実を拾えるか測りました。深さによる取りこぼしは無く、文書に無いことは「記載なし」と答えました。唯一の誤りは、先頭2文字が同じ別の番号との取り違えで、片方の名前を変えると消えました。 I had a local LLM read a 128K-token document and measured whether it could pick up facts planted in 20 places. Nothing was missed because of depth, and for things not in the document it answered "not stated". The only mistake was mixing up a different ID that shared its first two characters, and it went away when I renamed one of them.
ローカルLLMに128Kトークンの文書を読ませると20分以上かかります。2回目以降を速くできるか、プロンプトキャッシュを6通りの使い方で測りました。質問を変えるだけなら数秒で済みますが、ディスクに保存して再起動すると全部読み直しになります。理由はモデルのハイブリッド構成にありました。以前の記事の誤りも見つかりました。 Having a local LLM read a 128K-token document takes over 20 minutes. To see whether later requests can be faster, I measured the prompt cache in 6 scenarios. Changing just the question takes seconds, but saving to disk and restarting means re-reading everything. The reason lies in the model's hybrid architecture. I also found a mistake in an earlier post.
ローカルLLMのコンテキストを32Kから128Kまで伸ばして測りました。予想していたメモリ不足は起きず、理由はモデルの構造にありました。代わりに見えた壁はプロンプトの取り込み時間で、128Kを読ませるだけで21〜24分かかります。途中で自分の自動起動に計測を汚された話も含みます。 I stretched my local LLM's context from 32K to 128K and measured it. The memory shortage I expected never happened, and the reason lay in the model's architecture. The wall I hit instead was prompt ingestion time: just reading 128K takes 21–24 minutes. It also covers how my own auto-start polluted the measurements along the way.
ローカルLLMのCLIでthinkingを既定で切っていました。速度だけ見て決めた判断の裏を取るため正答率を測ったら、同率でした。ただしそこに至るまでに、自分で書いた採点スクリプトのバグを2回踏んでいます。 I had turned thinking off by default in my local LLM CLI. To back up a decision I'd made by looking only at speed, I measured accuracy, and it was the same. But on the way there, I hit bugs in the grading script I wrote myself twice.
8本の記事で16枚の図を作るうちに、配色の検証・文字サイズの下限・図を入れる判断が固まってきました。棒グラフの原点がずれていた話や、小さすぎて全図を作り直した話を含めて、いま使っているルールをまとめます。 While making 16 figures across 8 posts, I settled on how to verify colors, a minimum text size, and when to include a figure at all. Here are the rules I use now, including a bar chart whose origin was off and figures so small I remade them all.
50 TOPS の NPU を積んだ機体でローカルLLMを動かしてきましたが、一度も NPU を使っていません。使えるのか調べたら、動く保証がなく、動いても iGPU より遅く、最大の利点が自分の使い方では効かないと分かりました。インストーラを落としたところで止めた記録です。 I've been running local LLMs on a machine with a 50 TOPS NPU, but I've never used the NPU. When I looked into whether I could, I found there's no guarantee it runs, it's slower than the iGPU even if it does, and its biggest advantage doesn't apply to how I use it. A record of stopping right after downloading the installer.
過去に下した設定判断を検証しようとして、逆の結果が出ました。喜びかけたところで物理的におかしい点に気づき、測り直したら元の判断が正しかった。別々に起動したベンチを比較してはいけない、という話です。 When I tried to verify a settings decision I'd made earlier, I got the opposite result. Just as I was about to celebrate, I noticed something physically odd, measured again, and the original decision was right. This is about why you shouldn't compare benchmarks from separate launches.
Claude・Codex・ローカルQwenの3枚に、自分で書いて自分で動かしていたスクリプトをレビューさせました。3件は自力では気づけないもので、1件は「レビュー結果を集計するスクリプト自体」のバグでした。一方で、3枚とも見逃した欠陥もあります。 I had three reviewers, Claude, Codex and a local Qwen, review scripts I had written and been running myself. Three were bugs I couldn't have found on my own, and one was in the very script that tallies the review results. There was also a defect all three missed.
WSL上の開発でWindowsホストのローカルLLMをレビュアーとして使いたい。経路は2つあり、どちらも実現はできます。ただし片方は安全性を、もう片方は信頼性を差し出す必要があったので見送りました。その判断の記録です。 I wanted to use the local LLM on my Windows host as a reviewer for development in WSL. There are two routes, and either one can be made to work. But one meant giving up safety and the other meant giving up reliability, so I passed. This is a record of that decision.
速くしただけでは使わない。PC起動後に`llm`と打つだけで答えが返る状態にするまでと、アイドル時に22.7GBを手放す仕組み、そして48GBを無駄に占有していたバグの話です。 Making it fast wasn't enough to get me to use it. How I got to the point where typing `llm` after booting the PC returns an answer, a way to give back 22.7GB when idle, and a bug that was needlessly taking up 48GB.
自宅PCで動かしているQwenを、複数モデルで独立レビューするdev-orchestraの3枚目のレビュアーとして組み込みました。プロバイダがAPIではなくCLIをラップする設計だったので、薄いCLIを1枚挟んで繋いだ話です。その後の公式対応と、Store版Pythonのパス罠についても追記しました。 I added the Qwen model running on my home PC as a third reviewer in dev-orchestra, which has multiple models review code independently. Providers wrap CLIs rather than APIs, so I connected it through a thin CLI. I also added a postscript on the official support that came later and a path trap in the Store version of Python.
まっさらにしたRyzen AI 9 HX 370機に、llama.cppとVulkanでローカルLLM環境を作り直しました。CPU推論から約7倍。最新モデルを選んで失敗した話と、ファイルが大きいほうが速いという実測結果をまとめます。 I rebuilt the local LLM setup on my freshly wiped Ryzen AI 9 HX 370 machine with llama.cpp and Vulkan: about 7 times faster than CPU inference. Here's how picking the newest model backfired, and measurements showing the bigger file was faster.
AMD Ryzen AI 9 HX 370搭載機に積み上げたローカルLLM環境を、最新の方法で組み直すために一度全部消します。何が残っているかの棚卸しから、削除の手順、消してはいけないものまでをまとめました。 To rebuild the local LLM setup I had piled up on my AMD Ryzen AI 9 HX 370 machine with the latest approach, I'm deleting it all first. I cover taking inventory of what's left, the removal steps, and what you shouldn't delete.
Claude Codeの/insightsコマンドで過去41セッションを分析してもらいました。うまくいっている使い方や詰まりポイント、自分の使い方の癖まで指摘されたレポートの中身を紹介します。 I used Claude Code's /insights command to analyze my past 41 sessions. Here's what was in the report, which pointed out what's working, where I get stuck, and even my own habits.
気象・地震・大気質・熱波のデータをリアルタイム統合し、47都道府県の危険度をランキング＋地図で表示するWebアプリを作りました。 I built a web app that combines weather, earthquake, air quality and heat wave data in real time and shows the risk level of all 47 prefectures as a ranking and a map.
winget で Microsoft の GNU Coreutils を Windows にインストールし、PowerShell から cat や rm などの Unix コマンドを使えるようにする手順を紹介します。 How to install Microsoft's GNU Coreutils on Windows with winget so you can use Unix commands such as cat and rm from PowerShell.
開発中に複数アカウントのCookieやlocalStorageを切り替えたくて、信頼できるOSSが見当たらなかったので自作しました。 I wanted to switch cookies and localStorage between multiple accounts during development, and couldn't find open-source software I could trust, so I built my own.
日本語環境の Windows 11 ではスタート検索に「terminal」と入力しても Windows Terminal がヒットしない問題を、スタートメニューへのショートカット追加で解決する方法を紹介します。 On Windows 11 in Japanese, typing "terminal" into Start search doesn't find Windows Terminal. Here's how to fix that by adding a shortcut to the Start menu.
Microsoft StoreでCopilot Keyboardをインストールし、初期設定を済ませるまでの手順をまとめます。 The steps from installing Copilot Keyboard from the Microsoft Store to finishing its initial setup.
Model Context Protocol（MCP）のC# SDKを使って天気取得ツールを自作し、Claude Codeに接続するまでの手順をまとめます。思ったよりシンプルでした。 Using the C# SDK for the Model Context Protocol (MCP), I built a weather tool and connected it to Claude Code. Here are the steps. It was simpler than I expected.
AIコーディングアシスタントopencodeをOllamaと組み合わせてローカルLLM（Qwen3.6）で動かすまでの手順と、実際に試してみた感想をまとめます。 The steps to run the AI coding assistant opencode with Ollama on a local LLM (Qwen3.6), and my impressions after actually trying it.
新しくブログを開設しました。技術的な話題を中心に発信していきます。 I've opened a new blog, where I'll mainly write about technical topics.
該当する記事がありません No matching posts.