import ChatMessage from "../../components/ChatMessage.astro";
import Conversation from "../../components/Conversation.astro";
import Collapsible from "../../components/Collapsible.astro";
書きたい主旨は「設計でコンテキストを短くして、LLMと人の生産を両立させる」。きっかけとして、M3 Tech BlogのPlaywright×Gaugeの記事とツイートを参照します。
了解です。冒頭で狙いを明示し、その後に“きっかけ”として記事とツイートを紹介。以降はテストに限らない一般の短コンテキスト設計として展開します。
狙いは“設計でコンテキストを短くする”こと。LLMの生産量によって基盤を改善し、人もLLMも長大な読解なく同じ地点から短く書けるようにする。本稿はプログラミング全般でのLLM導入を対象とし、例としてテストを取り上げるに留める。
## Tweet
2025-09-01に公開されたエムスリーテックブログ「非エンジニアもMarkdownでテストを書ける — PlaywrightとGaugeによる自動テスト」（ https://www.m3tech.blog/entry/2025/09/01/120000 ）が示唆に富んでいた。趣旨は、Playwrightでブラウザ操作とアサーションを担保し、Gaugeで仕様をMarkdownとして書けるようにして非エンジニアも巻き込む、というものだ。
---
## stakmeの見解
LLMの適所は、致命的ではない派生コードを大量に肩代わりさせ、クリティカルなコンテキストの範囲と量を極小化することにある。「非エンジニアに書けるものはAIにも書ける」という前提に立ち、まずはSQLやDSL、コード／APIジェネレーター、テンプレートで土台を整える。そこで“安心して短く書ける状態”を先につくり、その短い前提の中でLLMに実装させ、人間はそこだけをレビューし、リファクタとテストで締める——順番は常に「自動生成とスキャフォールドが先」。
同時に、いまの私は“LLMならではのアーキテクチャ”をまだ発明していないとも感じている。モデルは抽象度の高い戦略（例: 依存管理の設計）を短い指示だけで素早く把握できないことが多く、むしろ人間側のADRや語彙管理の不足がボトルネックになりがちだ。だからこそ非エンジニアを巻き込み、長い説明よりもテンプレ生成を優先する。スキャフォールドはまずCLIで十分で、既存CLIが噛み合わなければMCPで包めばいい。
> 興味深いなと思いました。現代LLMが最もハマる用法として「致命的でないが書ききれない派生的コードの量をLLMで増やし、致命的なコンテキストの場所と量を小さくする」があると思っており、これもそう捉えられそう（非エンジニアに書けるものはAIにも書ける理論）。
>
> つまり私の感覚としては、まずLLMの生産量を投じることで基盤を改善する。SQLとコードを生成するジェネレーターでもいいし、DSLでもいいし、なんらかそのシステムにとって必要なものを抽象化するAPIでもなんでもいいが、とにかくそういったものを片っ端から生成していく。で、これなら安心して短くプログラムを書けますね〜〜という状態に持っていってからLLMにプログラムを書かせ、そこだけを人間がレビューする。要するにリファクタとテストという当たり前の活動をするだけなんだが、LLMを現場投入していくにはこの当たり前プロセスをやっていくのが結局早い。自動生成とスキャフォルドはお勧め。
>
> 裏を返すと、まだ私は「LLMならではのアーキテクチャ」みたいなのは発明できておらず、人間の限界に沿ってLLMを使っているとも言える。かなしいね。まあそのうち誰かが何とかするやろ…。
>
> LLMの癖みたいなのはあると思います。たとえば「依存性のイカした管理」みたいな戦略的で抽象度が高いことを（限られた指示書から）シュッと理解するモデルはあんまりないとか。ただこれは「人間のADR管理がスカスカ」みたいな課題のほうが疑わしいけど…ともかく非エンジニア巻き込みは時代の要請っぽい。
>
> ちなみにスキャフォールドはCLIでもMCPでもいいんだけど、別にMCPにする必要もないのでCLIで十分。既存のCLIがうまくハマらないならMCPで包んであげるのもアリかもしれないが、とにかく言葉でグチグチ説明するよりテンプレ自動生成のほうが早く、そしてコンテキストも短い。
---
## 追加分析（人が触れていない論点）
ここでは“冗長な文脈を設計で削る”という方針を肯定しつつ、実運用でどこに歪みが出やすいかを批判的に検討する。結論から言えば、このアプローチは局所の思考負荷を大きく下げる一方で、システム全体の“文脈の総量”を別の場所へ移転させる。移転先の管理が甘いと、速度は一時的に出ても、数か月後に保守コストが跳ね上がる。
まず、スキャフォールドとテンプレートは“資産化と負債化”を同時に起こす。雛形が増えるほど着手は速くなるが、半減期の短いドメインでは陳腐化の速度も上がる。意図どおりの短文脈を保つには、テンプレートに寿命を設定し、CIで使用状況と最新APIの差分を常時計測して、使われない雛形は躊躇なく退役させる運用が要る。増やし続けること自体が目的化した瞬間、短文脈は“断片化した文脈”へと劣化する。
次に、辞書化された語彙やステップは“公開API”そのものであり、生成の自由度を下げる代わりに意味の一貫性を守る装置だ。だが語彙の拡張を無制限に許すと同義語や方言が噴出し、語彙そのものが新たな長文脈に化ける。語彙は“追加より統合”を原則とし、似た概念は統合提案を自動で起票する。採番やバージョニングは“使い分けの理由”とセットで残し、惰性の `v3` を増やさない。
また、“派生コードを増やし、致命コンテキストを固定する”という設計は、テストでは特に効くが、アプリ本体に無制限に適用すると逆効果になり得る。派生の増殖は変更時の探索空間を広げ、静的解析やレビューのノイズを増やす。重要なのは生成量そのものではなく“生成の密度”だ。類似度の高い派生を束ねてひとつの抽象へ戻すリファクタリング・サイクルを、生成の後段に必ず置いておく必要がある。
LLM特性も見逃せない。短文脈に寄せるほど、モデルはテンプレートに強く“接地”するが、その接地はしばしばアンカー・バイアスを伴う。テンプレートに抜けている制約は、モデルが永遠に“見ない”。この盲点は、短文脈設計の成功が大きいほど、静かに広がる。定期的に“テンプレートに載らない事例だけ”でテストベンチを組み、雛形の更新を促す儀式が要る。
非エンジニア巻き込みにも落とし穴がある。仕様の可読性が上がると、品質の“見かけ”も上がるが、実際の網羅や重要経路の担保は別問題だ。レビューは“読める/読めない”ではなく“守られているべき前提が守られているか”に寄せ、仕様を数ではなく“体重”で測る。たとえば、仕様の合格率よりも、障害後に追加された“再発防止シナリオ”の生存率や、重要経路の“前提カタログ”に対するトレーサビリティの充足率を追うほうが健全だ。
コスト面でも、派生の量産はCIの待ち行列を肥大化させる。短文脈を守るための生成が、長時間のフィードバックで相殺されるのは本末転倒だ。ここは“生成予算”を明示して、PR単位のテスト増加を定量で制御する。たとえば、1PRで増やしてよいシナリオの上限、1日で回す総ステップ数の上限、失敗時に残すアーティファクトの総容量の上限をあらかじめ決め、閾値を越えた生成はドラフトに退避する。
では、どの条件ならこの方針は“速いだけでなく、長く強い”か。鍵は三つある。第一に、語彙とテンプレートを“編集可能な標準”として扱うこと。誰でも提案でき、しかし誰もが勝手に増やせはしない。第二に、生成の後にリファクタリングを必ず置くこと。短く書く権利は、短く保つ義務とセットだ。第三に、短文脈の外側に“長文脈の逃がし先”を用意すること。アーキ図、前提カタログ、設計ADRなど、抽象の宿る置き場を痩せさせない。
まとめると、このアプローチは“文脈の切断”ではなく“文脈の再配置”である。短く書ける現場を作る一方で、長く語るべき場所を枯らさない。速度と保守性のバランスは、その二つの器にどれだけ適切に水を分けられるかに尽きる。
短くするコツは「減らす」だけでなく「移す」。増やした派生は、期限・密度・出口（統合先）を最初から決めておくと、後で効きます。
## 参考リンク
参考: Playwright(https://playwright.dev/)、Model Context Protocol(https://modelcontextprotocol.io/)。
---
メンテの話は鋭いなと思いました（感想）
コードの自動生成はその点、生成物が同じならきっと壊れてないんだろうという安心感があり、導入も交換もしやすいんですよ。もちろんテストも書きますが。