どうも、マイクです。
時刻は朝七時を少し回ったところ、二〇二六年八月十二日、水曜日。
ここはテック好きのみなさんと最新の記事をゆるっと追いかけていく「zenncast」。
今日も Zenn で話題になっているトレンド記事を、まとめてチェックしていきたいと思います。

今日はぜんぶで、五本の記事をご紹介します。
どれも「AI・LLMまわり」「開発の現場での工夫」がテーマになっていて、かなり実践的な話が多いので、エンジニアのみなさんはもちろん、AIを触り始めた方にも参考になると思います。

。。。。

まず一つ目。
「中古データセンター・マイニング用GPUを使って、自宅で LLM をどこまで安く、現実的に動かせるか？」という、かなり攻めた内容の試算記事です。

ポイントは、最新の新品 GPU じゃなくて、中古のデータセンター向け・マイニング向け GPU を賢く使おう、という発想なんですね。
記事で名前が挙がっているのは、Tesla P一〇〇、V一〇〇、CMP 一七〇HX、MI五〇、P四〇 といったあたり。
これらはスペックだけ見ると地味に見えるんですが、「メモリ一ギガバイトあたりの価格」が、いまどきの RTX 五〇九〇 とか RTX PRO 六〇〇〇、DGX Spark なんかと比べると、圧倒的に安いんです。

具体例がかなりリアルでして。
たとえば、オフィスワーク用途の二二ギガバイト級の GPU を一枚使う構成を考えるとします。
記事では「Tesla V一〇〇 一枚 ＋ 中古ワークステーション」のセットで、おおよそ十四万円くらいで組める、と試算しています。
同じくらいのメモリ容量を、最新の RTX 五〇九〇 で構成しようとすると、だいたい九十五万円くらいかかる。
にもかかわらず、速度面では RTX 五〇九〇 構成と比べて、一・八倍くらい遅いだけで済む、というんですね。
「値段は七分の一くらいなのに、スピードは二倍遅い程度で踏みとどまってる」というバランスで、これはかなりコスパがいいと言えそうです。

さらに、DeepSeek Vフォー・Flash のような、重さにして百四十ギガバイト超えの大型モデルを動かしたい場合。
こうなってくると、メモリをたくさん積んだ GPU を何枚も並べる必要が出てきますが、記事では CMP 一七〇HX を三〜四枚使う構成を例に出しています。
これを使うと、DGX Spark を二台並べるとか、RTX PRO 六〇〇〇 を二枚刺しにするような構成と比べても、総額はかなり安く抑えられる、という結果になっていました。

ただし、「安くなるから全部中古で！」と単純にはいかないよ、という話もちゃんと書かれています。
中古 GPU は消費電力が高めだったり、ファンの音がうるさかったり、発熱対策も必要になります。
それから、どのエンジンを使うか──たとえば llama.cpp で動かすのか、vLLM でサーバーを立てるのか──によっても、速度や使い勝手がけっこう変わってきます。

なので筆者は、「ハードウェアの値段だけ見て飛びつかないで、ソフトウェアと電気代まで含めたトータルコストをちゃんと見極めることが重要だ」と強調しています。
単に“最安”を狙うというより、「家庭で本当に回せるライン」を具体的な金額とスペックで示してくれているので、自宅 LLM サーバーに興味がある方にはかなり実用的な内容になっています。

。。。。

続いて二つ目。
こちらは、「AI」「LLM」「MCP」といった言葉が、人によってバラバラの意味で使われちゃっている現状を整理し直そう、という解説記事です。
用語のカオスをいったんリセットして、「なにがどの役割なのか」をきちんと分けて考えよう、というスタンスですね。

まず、ざっくり「AI」という言葉。
これはめちゃくちゃ広い概念で、その中の一部として「モデル」があります。
モデルというのは、学習を終えた巨大な数式のかたまりみたいなもので、その一種として「言語に特化しているのが LLM ですよ」と。
より正確に言えば、いまは文章だけじゃなくて画像も扱える「LMM」なんて呼ばれるタイプも出てきている、という話も出てきます。

で、「仕様書を書いてくれる」とか「ファイルをいじってくれる」とか、我々がつい LLM の“機能”だと思いがちな部分。
実はそこは LLM そのものの仕事じゃなくて、その上に乗っているアプリケーションやツール群が担っている、という説明が丁寧にされています。
LLM は基本的には「テキストを受け取って、テキストを返す」だけ。
ファイル操作やAPIコールなどの実際の処理は、LLM に指示をもらったアプリ側が実行しているわけですね。

トークンとコンテキストについても、よくある誤解をほどくように説明されています。
トークンは、文字列を細かく区切ったときの「量の単位」で、コンテキストは「一度に LLM が読める情報量の上限」のこと。
チャットしていると「会話が続いているように見える」んですが、LLM の API 自体は会話の状態を覚えていません。
毎回、過去の履歴も含めてぜんぶ送り直しているから、あたかも会話が続いているように見える、という仕組みですね。

そして最近よく聞く MCP。
これは、AI アプリと外部ツールやサービスをつなぐための「共通ルール・プロトコル」です。
LLM は、「どのツールを、どんな引数で呼びたいか」という、あくまで“文章によるリクエスト”を出すだけ。
それを受け取って、実際にツールを呼ぶかどうか判断したり、エラーが出たときにどうリトライするか、というロジックは、アプリケーション側が担当しています。

従来は、人間のエンジニアが API の仕様書を読み込んで、対応するコードを書いていましたよね。
MCP の世界では、サーバー側が「使える機能の一覧」や「パラメータの型情報」などを機械可読なかたちで返してくれる。
それを LLM が実行時に問い合わせて理解して、「この場面ではこのツールを、こういう引数で呼べばよさそうだ」と、その場で使い方を決めてくれる、という役割分担になっています。

このへんの「誰が仕様を理解して、誰が実行しているのか」という線引きを一度ちゃんと整理しておくと、AI アプリを設計するときにも混乱しにくくなるよ、というのが記事の狙いです。

。。。。

三つ目は、ちょっと実務寄りの Tips 記事。
テーマは「コーディングエージェントのトークン消費を、BM二五でどれくらい減らせるか？」です。

多くのコードエージェントって、リポジトリの中から「関連しそうなファイルを探す」ときに、ものすごくトークンを使っています。
記事では、この“ファイル検索部分”を賢く前処理することで、トークン消費をおよそ三割カットできた、という検証結果が紹介されています。

具体的には、ふつうのアプローチとしては、Glob や Grep でファイルをしらみつぶしに探して、そこからまとめて LLM に読ませる、みたいな流れが多いですよね。
この記事では、それと比較するかたちで、「BM二五」という情報検索アルゴリズムを使った方式を試しています。
まず BM二五でコードをスコアリングして、「関連度の高いコード断片候補」を順番に返す。
そのうえで、絞り込まれた断片だけを Codex に読ませる、という構成です。

自社リポジトリを使った実験で、通常の「Glob / Grep ＋ファイル読み取り探索」と、BM二五ベースの方式とを比較したところ。
どの質問に対しても、正答率はほぼ同じまま。
それでいて、トークンの合計は約二九パーセント減、動作時間の中央値も三四パーセント短くなった、という結果が出ています。

検索の工夫もかなり細かく書かれていて、BM二五用のインデックスは、コードを数十行単位のチャンクに分割して登録します。
識別子の分割──たとえば getUserProfile なら get / user / profile というふうに──を行ったり、日本語テキストは二文字ずつに分割したり。
さらに「ファイルパスが一致しているものは強く評価する」といったルールも入れて、コードと日本語の文章が、部分一致でもうまくヒットするように工夫しています。

トークンが減った理由としては、BM二五で最初から「関係のありそうなコード断片」だけを読むようにしたことで、無関係なファイルを読みまくる必要がなくなったこと。
それから、検索語をあれこれ試行錯誤する回数や、候補を比較するために行う推論の回数も、まとめて減らせたことが挙げられています。
「エージェントの性能は変えずに、インデックス設計で効率を上げる」というアプローチが面白い記事でした。

。。。。

四つ目は、少しオピニオン寄りの記事。
テーマは、「ドメインモデル図やオブジェクト図をどう管理するか？」です。

よくあるのが、draw.io や Mermaid でドメインモデル図やオブジェクト図を描いて、それをドキュメントとして置いておく、というスタイルですよね。
ところが筆者いわく、このやり方だと、実装の変更に図が追従されなくなって、「すぐに古くなって誰も見なくなる」という問題が起きがちだと。
さらに、オブジェクト図として残しておく具体例パターンも、どうしても数が少なくなりやすい。
そして、AI を使った開発フローにこの図を乗せづらい、という課題も挙げられています。

そこで筆者が試しているのが、「TypeScript の型定義を直接参照するコードで、ドメインモデルとオブジェクト図（具体例）を表現してしまう」というアプローチです。
図を書くための独立したツールを使うのではなく、あくまで「コードとしてモデリングする」という発想ですね。
それを Storybook のような Web UI で可視化する仕組みを試作していて、ブラウザ上で図っぽく見えるんだけれど、裏側は全部 TypeScript の型とコードでつながっている、という世界観になっています。

これをやると何がうれしいか。
まず、型定義が変わったときに、対応する“図用のコード”にコンパイルエラーが出るので、「構造的に古くなった図」が自然と残りにくくなります。
さらに、オブジェクト図に相当する具体例も、ふつうのコードとして書くので、AI に「この型のパターンをいくつか生成して」と頼んで、どんどん追加させることもできます。
結果として、モデリングの成果物を、実装コードと同じ「コードの世界」に置いておけるので、リファクタリングや機能追加と一緒に、継続的に育てていけるんじゃないか、という提案です。

「設計ドキュメントを別ツールに逃がさず、できるだけコードの近くに置く」っていう考え方自体は昔からあるんですが、そこに AI と TypeScript の型システム、Storybook 的な UI を組み合わせて、いまの時代の開発フローに合わせ直しているのが面白いところでした。

。。。。

最後、五つ目。
これはサービス紹介の記事です。
名前は「ever-better」。
既存の JavaScript / TypeScript プロジェクトに、lint や型チェックといった「品質の足回り」を自動で導入してくれるツールです。

特徴的なのは、「いまこの瞬間に存在している違反数を“天井”として固定し、それ以上は増やさない」というコンセプト。
どんなに大きなレガシープロジェクトでも、「まずはこれ以上悪くしない」というラインを引いて、そこから徐々に改善していけるようにする、という発想ですね。

具体的には、`diagnose` `bootstrap` `freeze` `check` `prune` といった、少数のコマンドを用意していて、これと Claude Code 用のプラグインを組み合わせて使います。
この流れに乗ると、コード整形、ESLint や TypeScript の導入、既存違反の「凍結」、そしてルールごとの自動修正プルリクエスト作成までを、かなり半自動で進められるようになっています。

実験としては、pm二 というプロセスマネージャーや、別の大規模な TypeScript プロジェクトなどで試した結果が紹介されています。
数千件レベルの警告や型エラーが出ているプロジェクトでも、とにかくまずは「止血」して、それを少しずつ削っていくことができた。
その過程で、十三年間誰も気づいていなかったバグが見つかったり、型だけでは検知しにくい危険なパターン──たとえば Object のプロトタイプ経由で起こるバグや、計算量が爆発する正規表現など──も、かなりの数があぶり出せたそうです。

設計思想としておもしろいのが、「機械的に決められる部分はぜんぶコマンドに押し込んで、AI には“読む・直す・テストを書く”といった柔軟な作業だけを任せる」という割り切り方です。
具体的には、「違反を数える」「記録する」「優先度順に並べる」「しきい値を超えていないかの合否を出す」みたいな、ルールで機械化しやすいところはツールが担当。
一方で、「このコードをどうリファクタリングするか」「どんなテストケースを書くか」といった創造的な判断は、Claude などの AI に投げる、という役割分担になっています。

その結果、一日五百コミット規模のような、かなり変更が激しいプロジェクトでも破綻しない品質管理ができて、かつ、誰でも同じプロセスを再現しやすくなる、というのがこのサービスの売りになっています。

。。。。

というわけで、きょうの zenncast は、
中古データセンター GPU で自宅 LLM 環境をどこまで現実的に安く組めるか、という話。
AI・LLM・MCP の役割を整理し直す基礎解説。
BM二五 を使ってコーディングエージェントのトークン消費を三割カットした Tips。
ドメインモデル図とオブジェクト図を TypeScript の型とコードの世界に持ち込む、というオピニオン。
そして、既存 JS / TS プロジェクトの品質を「これ以上悪くしない」ラインから整えていく ever-better の紹介。
この五本をお届けしました。

気になる記事があった方は、詳しい内容や元の記事へのリンクをショーノートにまとめておきますので、あとでぜひチェックしてみてください。
番組の感想や、「こんなテーマを取り上げてほしい」といったリクエストも大歓迎です。
あなたの開発現場での悩みや工夫の話も、どしどし送ってください。

それでは、そろそろお別れの時間です。
お相手はマイクでした。
また次回の zenncast でお会いしましょう。