Blog
友人と「今年は○○だったね」と話すことはよくあります。でも実際に調べてみると、意外と違うこともある。そんな身近な“思い込み”を公的なデータで確かめる連載「本当なの？」を始めます。
「今年は台風が多い」と感じた人は多いはず。気象庁の統計で、2026年の台風の発生・日本への接近・上陸の数を1951年からの記録と比べてみると、多いのは「発生」だけで、日本に来た数は平年並みでした。
dev-orchestra 1.2.1 で小さな機能追加を1件依頼し、かかった時間（承認待ちを除いて約6分）と、レビュアーを1人・2人・4人にしたときの指摘数と採用数を測りました。人数を増やすと採用できる指摘は増えましたが、増えたのはテストの指摘でした。
dev-orchestra 1.2.1 で入った instructions を試しました。implementer やレビュアーへの決まった指示をリポジトリに書いておくと、毎回のプロンプトに入ります。どう表示され、どこに入り、指示を変える変更がどう扱われるかを、実際の出力で確かめます。
dev-orchestra の v1.1.0 から v1.2.1 までの変更をまとめました。計画を作業単位に分けて並べて走らせる機能、役割ごとに決まった指示を渡す機能、設計の前の質問、進み具合の報告の設定が入りました。Windows で出力を取り込んでいる人は、文字コードの変更に注意してください。
dev-orchestra 1.2.0 で入った作業単位を試しました。計画に ## Units を書き、2 つの作業単位を別々の git worktree で並べて Claude に実装させ、作業ツリーへマージし、最後の統合の作業単位をその場で走らせるまでを、実際のコマンドと出力で追います。
dev-orchestra を 1.0.0 から 1.1.1 に、Claude Code・Codex・Antigravity のそれぞれで実際に更新してみました。Claude Code は claude plugin update だけでは更新されず、先にマーケットプレイスの更新が要りました。今の版の確かめ方、CLI ごとの手順、更新したあとに確かめることをまとめます。
dev-orchestra 1.0.0 で、自作のアダプタを一から書いてローカル LLM をレビュアーに加えてみました。プロンプトを受けて答えを返す小さな CLI と、50 行ほどのアダプタだけで繋がります。置き場所、doctor での確認、できる役とできない役、注意点までまとめます。
dev-orchestra の役（ロール）ごとのモデルの指定方法、レビュアーの観点の選び方、分野の専門役を提案させる config suggest-roles を紹介します。わざとバグを仕込んだ変更を 9 人のレビュアーに見せて、人数を増やすと何が変わるかも測ってみました。
dev-orchestra の初期設定で選ぶプリセット quality / standard / fast を、Claude Code だけ・Codex だけ・両方の 3 つの環境で実際に展開して比べました。役ごとのモデル、レビュアーの人数、コストを削る度合いがどう変わるか、どれを選べばいいかをまとめます。
Antigravity にも dev-orchestra を入れてみました。話しかける場所としては普通に使えますが、Antigravity CLI（agy）に設計やレビューを任せるのは限定的です。できること・できないことと、おすすめの使い方をまとめました。
Codex にも dev-orchestra を入れてみました。Codex だけの環境でも動きますが、Claude Code と両方入れると、別々の会社の AI がレビューする推奨構成に自動でなります。Codex の場合だけの機能と注意点も最後にまとめました。
Claude Code だけの環境に dev-orchestra を入れて、初期設定から1文の依頼までを試しました。インストールは2行、初回にプリセットを選ぶだけで、レビュアーも Claude だけで組まれます。Claude Code の場合だけの機能と注意点も最後にまとめました。
Claude Code / Codex / Antigravity で動くプラグイン dev-orchestra の紹介です。何ができるか、公式の codex-plugin-cc との違い、Claude Code だけでも使う意味、そしてデメリットまでまとめました。
AIに書かせたコードを別のAIにもレビューさせたい。でも手作業でやると、ターミナル間のコピペと待ち時間で疲れ果てる。それを仕組みにしたプラグイン dev-orchestra の 1.0.0 を出したので、作った経緯と使ってみての感想をまとめました。
社外に出せないコードを、クラウドのAIに送らずにレビューする方法をまとめました。ローカルLLMをdev-orchestraのレビュアーに登録し、機密のものはローカルだけで、公開してよいものはクラウドのAIと併用します。ローカルLLMのレビューの実力と、呼び出し方ひとつでコードが外に出てしまう落とし穴も書きます。
ローカルLLMの速度や品質を測るときに、結果を信用できるものにする手順をまとめました。同じ条件でも1割ぶれる、順番で結果が変わる、裏の処理で5倍ぶれる、採点器が壊れている。実際に踏んだ失敗から作った、測る前・測っている間・測ったあとのチェックリストです。
Ryzen AI ミニPCに96GBのメモリを積んでローカルLLMを動かし、実際に何GB使っているかを測りました。35BのMoEモデルで24GiB、コンテキストを上限の256Kまで伸ばしても28GiB程度です。32GB・64GB・96GBでそれぞれ何ができそうかを、実測と推定を分けて整理します。
Ryzen AI 9 HX 370（Radeon 890M）のミニPCで、ローカルLLMを毎秒20トークン前後で動かすまでの手順を1本にまとめました。llama.cppのVulkan版を入れ、MoEモデルを選び、効く設定だけを入れて、llmと打つだけで使える状態にします。つまずいた点も全部載せています。
Ryzen AI ミニPCでローカルLLMを動かすときに試した設定を、効果の大きさ順に1枚にまとめました。Vulkanは5.2倍、MoEは5.7倍。一方で、効かなかったもの、逆効果だったもの、そもそも無効だったものもあります。すべてこの機体での実測値です。
ローカルLLMのサーバが、テキストしか使わないのに画像用のmmprojを毎回読み込んでいました。外すと速くなるかを、前回まとめたチェックリストに沿って測りました。1回目は計測中のずれが大きく速度について何も言えず、裏で別のAIセッションが動いていたと分かったので、止めて測り直しました。メモリは1GiB減り、速度は3%未満の差で変わりませんでした。既定は外すことにしました。
ローカルLLM環境の構築と検証を13本の記事に書くあいだに、測定する側が間違っていた場面が19回ありました。比べ方、採点器のバグ、外からの割り込み、前提の取り違え、動いていなかった安全装置。気づいたきっかけを数えると、半分以上は「ありえない値」か「生データ」でした。測る前のチェックリストにまとめます。
ローカルLLMに128Kトークンの文書を読ませ、20か所に仕込んだ事実を拾えるか測りました。深さによる取りこぼしは無く、文書に無いことは「記載なし」と答えました。唯一の誤りは、先頭2文字が同じ別の番号との取り違えで、片方の名前を変えると消えました。
ローカルLLMに128Kトークンの文書を読ませると20分以上かかります。2回目以降を速くできるか、プロンプトキャッシュを6通りの使い方で測りました。質問を変えるだけなら数秒で済みますが、ディスクに保存して再起動すると全部読み直しになります。理由はモデルのハイブリッド構成にありました。以前の記事の誤りも見つかりました。
ローカルLLMのコンテキストを32Kから128Kまで伸ばして測りました。予想していたメモリ不足は起きず、理由はモデルの構造にありました。代わりに見えた壁はプロンプトの取り込み時間で、128Kを読ませるだけで21〜24分かかります。途中で自分の自動起動に計測を汚された話も含みます。
ローカルLLMのCLIでthinkingを既定で切っていました。速度だけ見て決めた判断の裏を取るため正答率を測ったら、同率でした。ただしそこに至るまでに、自分で書いた採点スクリプトのバグを2回踏んでいます。
8本の記事で16枚の図を作るうちに、配色の検証・文字サイズの下限・図を入れる判断が固まってきました。棒グラフの原点がずれていた話や、小さすぎて全図を作り直した話を含めて、いま使っているルールをまとめます。
50 TOPS の NPU を積んだ機体でローカルLLMを動かしてきましたが、一度も NPU を使っていません。使えるのか調べたら、動く保証がなく、動いても iGPU より遅く、最大の利点が自分の使い方では効かないと分かりました。インストーラを落としたところで止めた記録です。
過去に下した設定判断を検証しようとして、逆の結果が出ました。喜びかけたところで物理的におかしい点に気づき、測り直したら元の判断が正しかった。別々に起動したベンチを比較してはいけない、という話です。
Claude・Codex・ローカルQwenの3枚に、自分で書いて自分で動かしていたスクリプトをレビューさせました。3件は自力では気づけないもので、1件は「レビュー結果を集計するスクリプト自体」のバグでした。一方で、3枚とも見逃した欠陥もあります。
WSL上の開発でWindowsホストのローカルLLMをレビュアーとして使いたい。経路は2つあり、どちらも実現はできます。ただし片方は安全性を、もう片方は信頼性を差し出す必要があったので見送りました。その判断の記録です。
速くしただけでは使わない。PC起動後に`llm`と打つだけで答えが返る状態にするまでと、アイドル時に22.7GBを手放す仕組み、そして48GBを無駄に占有していたバグの話です。
自宅PCで動かしているQwenを、複数モデルで独立レビューするdev-orchestraの3枚目のレビュアーとして組み込みました。プロバイダがAPIではなくCLIをラップする設計だったので、薄いCLIを1枚挟んで繋いだ話です。その後の公式対応と、Store版Pythonのパス罠についても追記しました。
まっさらにしたRyzen AI 9 HX 370機に、llama.cppとVulkanでローカルLLM環境を作り直しました。CPU推論から約7倍。最新モデルを選んで失敗した話と、ファイルが大きいほうが速いという実測結果をまとめます。
AMD Ryzen AI 9 HX 370搭載機に積み上げたローカルLLM環境を、最新の方法で組み直すために一度全部消します。何が残っているかの棚卸しから、削除の手順、消してはいけないものまでをまとめました。
Claude Codeの/insightsコマンドで過去41セッションを分析してもらいました。うまくいっている使い方や詰まりポイント、自分の使い方の癖まで指摘されたレポートの中身を紹介します。
気象・地震・大気質・熱波のデータをリアルタイム統合し、47都道府県の危険度をランキング＋地図で表示するWebアプリを作りました。
winget で Microsoft の GNU Coreutils を Windows にインストールし、PowerShell から cat や rm などの Unix コマンドを使えるようにする手順を紹介します。
開発中に複数アカウントのCookieやlocalStorageを切り替えたくて、信頼できるOSSが見当たらなかったので自作しました。
日本語環境の Windows 11 ではスタート検索に「terminal」と入力しても Windows Terminal がヒットしない問題を、スタートメニューへのショートカット追加で解決する方法を紹介します。
Microsoft StoreでCopilot Keyboardをインストールし、初期設定を済ませるまでの手順をまとめます。
Model Context Protocol（MCP）のC# SDKを使って天気取得ツールを自作し、Claude Codeに接続するまでの手順をまとめます。思ったよりシンプルでした。
AIコーディングアシスタントopencodeをOllamaと組み合わせてローカルLLM（Qwen3.6）で動かすまでの手順と、実際に試してみた感想をまとめます。
tk3.biz のブログで書いていること（ローカルLLM、AIでの開発とコードレビュー、Windowsの環境づくり、自作アプリ）と、記事を書くときに守っていることをまとめました。
該当する記事がありません