どうも、マイクです。おはようございます。
二千二十六年八月十六日、日曜日の朝七時を回りました。
ここからの時間は「zenncast」、きょうもZennで話題になっているトレンド記事を、ラジオ感覚でゆるっと紹介していきます。
きょうは全部で五本、ご紹介していきます。
それぞれけっこう中身が濃いので、コーヒー片手に、ながら聞きでお付き合いください。
。。。。
まず一本目。
ソフトウェア開発の「概念設計」の大事さを、ECサイトの例で丁寧に説明してくれている記事です。
テーマは、「データ構造をどう持つかの前に、そもそも世界に何が存在して、何と何を別物として扱うのか、そこをちゃんと決めておくと、コードの品質が長い目で見て効いてくるよ」という話なんですね。
たとえば、ネットショップの注文データ。
ありがちなのが、「注文」と「配送結果」を一つのオブジェクト、オーダーの中に全部押し込んでしまうパターンです。
最初はシンプルで良さそうなんですけど、再配送が発生したり、分割発送したり、キャンセルしたり、現実世界のややこしいケースが増えてくると、一気に苦しくなります。
記事の中では、そういう世界だと「再配送のためだけのゼロ円注文」が出てきたり、「このフラグが立ってる時だけはこう解釈する」みたいな、帳尻合わせのフラグがどんどん増えていく、と。
すると、売上分析をしようとしたり、「このユーザーにこういう商品をおすすめしたい」と推薦ロジックを組もうとしたり、バグを避ける処理を書こうとするたびに、「あ、このゼロ円注文は特別扱いね」「このフラグがオンのときは除外ね」と、例外処理だらけになっていきます。
一方で、「注文（オーダー）」と「履行（フルフィルメント）」をきちんと分けて設計すると、世界の見え方がガラッと変わるんですね。
ユーザーが「なにを、いくつ買うのか」という注文は注文として置いておいて、配送や在庫引き当て、再配達、分割発送みたいな「実際にどう届けたか」は履行として独立した概念にする。
そうしておくと、「一つの注文に対して、履行が複数ぶら下がる」という形で、再配送も分割発送も、あとから出てくる自然な仕様を、無理な特別処理を増やさずに、そのまま表現できるようになります。
さらに、「購入数量」と「実際に配送された数量」が、それぞれ別のテーブルやエンティティで素直に表現されるので、売上集計や出荷数の集計クエリも、変な条件を足さずにスッと書ける。結果として、バグが入り込む余地そのものが減っていきます。
記事では、新しい機能を考えるときも、いきなり画面どうするかとか、APIの設計どうするかじゃなくて、「誰が、何に対して、なにをする機能なのか」を、いま既にある概念の言葉で言い換えてみよう、と提案しています。
それで自然に説明できるなら、既存の世界観にうまく収まっているし、どうしても説明できないなら、新しい概念が必要なのかもしれない、と。
さらに、現場ごとの呼び方の違いや、現実世界で使われている用語の違いにちゃんと目を向けて、「もうこれしかないよね」と思える名前を付けることが大事だ、という話で締めくくられています。
名前をきちんと付けることで、概念の境界がはっきりして、責務が混ざるのを防ぎやすくなる。
設計の話なんだけど、組織のコミュニケーションの話にもなっていて、開発やってる人はすごく刺さる内容だと思います。
。。。。
続いて二本目。
こちらは、同じ「Claude Sonnet ファイブ」というモデルを、二つの違うコマンドラインツールから使ったら挙動がどう変わるのか、という、かなりガチな比較実験の記事です。
比べているのは、「Claude Code」と「GitHub Copilot CLI」。
どちらも、ターミナルからAIにコードを書かせたり、修正してもらったりできるツールですね。
同じモデルを使っているはずなのに、「effort level」というパラメータの効き方が、ツールごとにまったく違ったよ、という結果が出ています。
実験環境はラズベリーパイ。
そこで、データベースまわりのパイソンタスクを三種類用意して、それぞれを何度も何度も実行します。
回数としては、最初に二百四十回、そのあと追加で百五十回。
かなりの数を回して、品質と、かかった時間と、コストを測っています。
品質をちゃんと見るために、各パターンでエヌイコール五十、つまり五十回まで試行回数を増やしていったところ、全タスクで安定して合格率百分の百を達成したのは、「Claude Code × Sonnet ファイブ × effort イフェクトのエックスハイ」だけだったんですね。
一方で Copilot CLI は、ハイでもエックスハイでも、隠しテストでどこかしら失敗が出てしまった。
コストについては、両者ほとんど同じくらいで、以前の実験で見えた「Copilotのほうが一・五倍から二倍くらい高い」という差は、今回の条件では消えていました。
なので、結果を分けたのは「価格」ではなく、「品質の安定度」だった、という結論になっています。
さらに面白いのが、OpenTelemetry のトレースを使って、「時間がどこに割かれているか」を分解して見ているところです。
Claude Code 側は、effort レベルを上げていくと、一回あたりの思考時間が長くなって、出力の量も最大で約四倍くらいまで増えていく。
つまり、「もっと頑張って考えてね」と頼むと、本当にじっくり考えて、長めの説明やコードを出すような挙動になっている。
一方で Copilot CLI は、effort を上げても、出力量も思考の回数もほとんど増えない。
結果として、「天井は低いけど、床は高い」ような、あまり振れ幅のない動きをしていることが分かります。
最低限はきちんと動くけど、ちゃんと気合い入れて考えてほしいときの伸び代が、あまり見られない、というイメージですね。
このトレースは、「どの成分の時間が伸びているのか」「本当に同じモデル・同じ設定で動いているのか」を検証するにはとても役に立つけれど、effort の内部実装がどうなっているかまでは教えてくれない。
なので、「なぜ Copilot 側では effort がうまく効いてこないのか」という根本原因は、今回の記事ではまだ宿題として残っています。
ツール選びで悩んでいる人には、かなり実践的な示唆が多い内容でした。
。。。。
三本目。
こちらは、モデルを「Opus ファイブ」に切り替えた人の、運用まわりの体験談です。
テーマは、「五か月かけて育ててきた CLAUDEドットエムディーや、たくさんのスキル・ルールを、思い切って棚卸ししてみたらどうなったか」という話です。
もともと筆者は、CLAUDEドットエムディーに細かい指示を書き込んだり、スキルやルールを大量に用意したりして、「こう動いてほしい」というレールをかなり作り込んでいたんですね。
ところが Opus ファイブに切り替えたところ、その全部を読み込まないほうが、むしろうまく動く場面が増えてきた。
そこで、「じゃあ、何を残して、何を捨てるべきなのか」を、Claude 本人に監査してもらおう、という発想になります。
具体的には、「スラッシュ claude ハイフン api スペース prompt ハイフン audit」というコマンドを使って、既存の設定をまるっと監査させたそうです。
すると、ちょっとプレッシャー強めの指示文とか、ほかのルールと重複しているものなんかを、Opus ファイブの挙動に合わせて、かなりいい感じに取捨選択してくれた。
この段階で、「文章として変だよね」「ルール同士で矛盾してない？」といったレベルの整理は、かなり自動でやってくれたわけです。
ただし限界もあって、「このスキルの中身は妥当かどうか」をチェックしてくれる一方で、「そもそも、このスキルという仕組み自体、まだ必要？」とか、「Claude Code の新しい機能、たとえばスラッシュ goal みたいなコマンドで、丸ごと置き換えられない？」といった、一段高い設計レベルの問いまでは、自動では踏み込んでくれなかった。
そこで筆者は、ツール呼び出しのログから、「どのスキルが、どのくらい実際に使われているのか」を集計させて、本当に使っている仕組みだけを残す、という整理に踏み込みます。
その結果、スキルの数は四十個から六個まで一気に削減。
常に読み込んでいるテキスト量も、およそ七十二パーセント削れたそうです。
それでも、期待どおりに動いてくれた、とのこと。
筆者としては、今後は「Opus ファイブ向けに書き換えてね」と頼むだけじゃなくて、「実際の利用状況も見たうえで、いらない仕組みは思い切って捨てられないか」というところまで含めて、Claude に監査をお願いするのがよさそうだ、とまとめています。
設定を足すばかりじゃなくて、減らすことも、一つのスキルになってきている感じがあって面白いですね。
。。。。
四本目。
ここからはちょっとライトに、Tips 系の記事です。
テーマは、「お金をあまりかけずに、AIコーディングをどう楽しむか」。
筆者がやっているのは、まず「無料枠が多めのAPI」を上手に組み合わせて使うこと。
たとえば Nvidia、Mistral、Cloudflare、Cerebras、そして Opencode Go のような、わりと緩い無料モデルたちですね。
こういうサービスを組み合わせて、「この作業はこっちのモデル」「この検証はあっちのモデル」と使い分けながら、できるだけ課金を抑えつつ開発していきます。
とはいえ、安いモデルや性能控えめなモデルだと、どうしてもコード品質が落ちがち。
そこで筆者は、「いきなりコードを書かせるんじゃなくて、まずは『なにを作るのか』を文章でしっかりまとめさせる」という工夫をしています。
ふるまい駆動開発、いわゆる BDD とか、仕様書ベースの設計、テスト駆動開発を組み合わせて、人間があとから修正する量を減らすようにしているんですね。
もう一つの悩みどころが、コンテキストとレート制限。
無料枠だと、すぐに会話の履歴が切れてしまったり、一定時間で呼び出し回数の制限に当たってしまったりします。
これに対しては、「作業を細かいフェーズに分ける」「どこまで終わったかを、ちゃんとドキュメントとして書かせる」ことで、途中でモデルを切り替えても、開発を継続しやすくしています。
具体的には、headroom や codegraph といったトークン節約ツールで、不要な情報を圧縮したり削ったりしながら、コンテキストをなるべく効率よく使う。
さらに、obra スラッシュ superpowers と自作のスキルを使って、SPECドットエムディー、plans ディレクトリ、tasks ディレクトリ、decisions ディレクトリ、みたいな感じで、仕様・フェーズ・タスク・意思決定を順番にファイルとして残していきます。
こうしておくと、たとえコンテキストが全部消えてしまっても、ファイルを読み直すだけで方針がぶれずに、エージェントに開発を続けさせることができる。
要するに、「記憶に頼らない開発プロセス」を、AI側にも強制しているわけですね。
記事では、実際に「ネットワークパケットを花火みたいに可視化するアプリ」を、ほぼ無料枠だけで開発したケースが紹介されています。
その中で、レート制限がかかったり、モデルを何度も切り替えたりしながらも、タスクの引き継ぎや改善を、そこそこうまく回せたそうです。
一方で、「スキルの制約が強すぎて、毎回承認待ちになる」といった、運用上のもどかしさも感じたようで、そのあたりは今後の調整ポイントですね、というコメントで締められていました。
お金をかけずに工夫している人には、かなり共感できる内容だと思います。
。。。。
そして最後、五本目。
こちらは「サービス紹介」ではなく、「AIエージェント向け拡張機能の入れ物をどう標準化するか」を解説・考察している、仕様寄りの記事です。
キーワードは、「Agent Plugins バージョンいちてんぜろてんぜろ」。
この Agent Plugins いちてんぜろてんぜろ は、「Agent Skills」と「MCP サーバーの設定」を、一つのプラグインとしてまとめて配るための、ほんとうに最小限の標準を決めています。
ポイントは、「中身をどう書くか」とか「マーケットプレイスをどう運営するか」「権限管理をどうするか」といったところは、あえて決めていない、という点です。
じゃあ何を決めているのかというと、「プラグインとして配布されるフォルダ構造」と、「そのフォルダを安全に扱うためのルール」。
具体的には、「skills ディレクトリと mcpドットjson を持つ、検査可能なフォルダであること」とか、「PLUGIN アンダースコア ROOT と PLUGIN アンダースコア DATA という二つの領域を分けて、状態をきれいに分離すること」。
それから、スキーマをきっちり閉じたものにしておくことや、プラグインの中にシークレット、つまり秘密情報を埋め込まないこと。
こういった、「配布単位として安全に扱うためのルール」だけを、ものすごく厳密に標準化しているんですね。
逆に言うと、hooks や subagents、マーケットプレイスの作り方、認可の仕組みなんかは、それぞれのクライアントやサービスが独自に工夫していい領域として残されています。
ここが各社の差別化ポイントになるだろう、という見立てです。
次に標準化の焦点になりそうなのは、新しいコンポーネントそのものではなくて、「信頼とガバナンス」の層じゃないか、と筆者は見ています。
たとえば、プラグインに署名を付けて、出所を検証できるようにするとか、シークレットをどう安全に渡すかとか、組織としてどう統制を効かせるか、といった部分ですね。
記事ではさらに、標準をめぐるプレイヤー同士の力関係にも触れています。
中身の標準である「Agent Skills」を握っているのは Anthropic。
一方で、「Agent Plugins」という箱の標準を主導しているのは、OpenAI、AWS、Microsoft といった面々。
この「中身」と「箱」で主導権を握る会社が違う、ちょっとねじれた構図を整理しながら、既存ツールの事例も紹介しています。
たとえば Kiro や Copilot といったツールは、標準化された「箱」だけを受け入れつつ、自分たち流のロード戦略や拡張機能の仕組みは維持している。
つまり、「プラグインとしての外側は標準に揃えるけれど、中でどう読んで、どう動かすかは、うちの流儀でやるよ」というスタンスですね。
そんなふうに、エコシステム全体の動き方を俯瞰しながら、「これからどこが標準化の戦場になっていきそうか」を考察している記事でした。
。。。。
というわけで、きょうの「zenncast」、お届けしてきた記事を、さっとおさらいしておきましょう。
まずは一本目。
ECサイトの例を通じて、「注文」と「履行」をちゃんと分けるなど、概念設計を丁寧にやっておくことが、長期的なコード品質を大きく左右するんだ、という話。
二本目は、Claude Code と Copilot CLI で、同じ Sonnet ファイブを使ったときの比較実験。
effort レベルの効き方や、品質の安定度に大きな差があって、トレースを取るとその違いがよく見えてきた、という内容でした。
三本目は、Opus ファイブに切り替えたタイミングで、CLAUDEドットエムディーやスキル群を Claude 自身に監査させて、四十個あったスキルを六個まで減らし、常時ロード文字数も七割以上削った、という棚卸し体験談。
四本目は、お金をかけずにAIコーディングを楽しむTips。
無料枠のAPIを組み合わせつつ、仕様書ベースやテスト駆動で品質をカバーし、SPECドットエムディーや tasks ディレクトリなどのファイルを軸に、コンテキストが消えても開発を続けられるようにしていた、というお話でした。
そして五本目は、Agent Plugins いちてんぜろてんぜろ の仕様解説と考察。
「skills ディレクトリと mcpドットjson を持つ安全なフォルダ」という箱の標準化を軸に、信頼とガバナンスのこれからや、各社ツールのスタンスを整理していました。
気になった記事があれば、詳しい内容はショーノートにリンクをまとめておきますので、あとでぜひチェックしてみてください。
番組の感想や、「こんなテーマを扱ってほしい」といったリクエストも、どしどしお待ちしています。
それでは、きょうはこのへんで。
お相手はマイクでした。
次回の「zenncast」で、またお会いしましょう。