> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2025/w50-what-should-the-team-do-next-year-in-ai-coding.md).

# W50-来年、チームは AI Coding で何をすべきか

今週、a16z と OpenRouter の[『State of AI』](https://openrouter.ai/state-of-ai)を読んだ。OpenRouter 上の100兆規模の実際の token を使った実証研究だ。冒頭を読んだだけで時間の感覚がおかしくなった。o1 の正式版は2024-12-05に公開され、まだちょうど1年しかたっていない。推論モデルが扱う token の割合は2025年を通じて伸び、最近では半分を超えた。

今後数年もモデルの能力が強まり、マルチモーダル、記憶、Agentic な能力が広がり続けると仮定しよう。その場合、AI Coding におけるチームの中心目標は、ツールをいくつか導入し、プロンプトを数組ためることにとどまるべきではない。AI-Ready な開発基盤を築くことだ。モデルが強くなるほど、私たちの提供能力を引き出せるようにする。

長期にわたって本筋の仕事を続けるために、次の五つには蓄積する価値がある。

**1）アーキテクチャ**

人が明確に説明できないプロジェクトでは、AI も力を発揮しにくい。大量の token を使ううえ、暗黙の依存を見落として回帰バグを起こしやすい。フロントエンドで主な問題になるのは、画面と業務ロジックの混在、ロジックと副作用の絡み合い、変わりやすいものと変わりにくいものを分けられないことだ。MVVM や MVC を採用すれば解決するわけではない。

プロジェクトは「中核コードは何か」に明確に答えられるべきだ。中核コードはすべての業務ロジックと状態変化を担う。理想的には純粋関数で、フレームワークに依存せず、環境依存がなく、単体テストができ、入出力が確定している。それ以外がネットワーク I/O、副作用、UI 描画を処理する。そうして初めて AI に安定した足場ができ、変更も制御しやすくなる。

**2）文脈の明示**

歴史的背景がなければ、AI はコード内の奇妙な hack の理由を理解できない。文書やコメントの重要性は、知識を残すことにとどまらず、コード生成の質へ直接影響する。

具体的には、業務ドメインの情報、アーキテクチャ上の制約、技術スタックの好み、チームの開発規範を明示すべきだ。ADR、制約リスト、README の「壊してはならないもの」など、AI が使いやすい形にし、適切なツールチェーンでモデルへ渡すのが望ましい。

**3）制約を前へ移す**

コンパイラや静的解析で問題を早期に検出する考え方には、強く賛同する。厳格なコンパイルを行う代表的な言語は Rust だが、フロントエンドの多くの場面では、事故防止に Rust が必須なわけではない。本当の問題は、TS の言語上の強みを十分に使えていないことだ。普及を速めるため、歴史的に緩い使い方を認めてきた結果、多くのプロジェクトで型やコンパイルの制約を有効にし切れていない。

TS の strict モードは交渉の余地のない基礎であり、any のような意味のない型は積極的に禁止すべきだ。共通の独自 Lint ルールも必要になる。ESLint ルールを書いてアーキテクチャの境界を強制し、言語の使い方を揃える。例えば Composition API を必須にし、層をまたぐ依存を禁じる。

**4）プログラムによる検証**

コード生成はますます安くなる。本当に高いのはコードが正しいかの検証であり、安く検証できる作業を先に行うべきだ。これは TDD の考え方に沿い、従来 TDD の実践コストが高かった問題も解く。

よいアーキテクチャがあれば中核コードを識別でき、そこを単体テストで覆うことの費用対効果が高まる。フロントエンドとバックエンドは契約に基づいて協働するため、Zod を加え、Schema を実行時に検証することも必要だ。フロントエンドと QA はテストケースを介して協働する。実装前に受け入れ条件や自然言語のテストケースを明記するのは退屈に見えるが、有効かもしれない。

**5）可観測性と原因調査**

顧客の苦情への対応や本番障害の調査は、組織が拡大し分業が細かくなるほど効率が落ちる。サービスごとにログが分散し、チャットで事実を集めるだけで数時間が消える。

ログと可観測性をつなぎ、AI が上流から下流まで完全なデータを見られるようにする。最低限、構造化ログ、共通の trace、重要経路の再現を実現したい。事実収集を先に自動化すれば、エンジニアはより素早く応答できる。AI による自動診断にも必要な前提だ。