# MaguyvaのTypeScript対応: モノレポのためのより良いコンテキスト

Canonical source: https://maguyva.ai/ja/languages/typescript

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

MaguyvaはAST解析とシンボル抽出によりTypeScriptに対応しており、AIエージェントはモノレポ全体で、インターフェース、実装、共有パッケージ、JSXを多用したアプリケーションコードをたどることができます。

## 対応状況スナップショット

- 対応レベル: AST・シンボル対応
- プログラミング
- 拡張子: .cts, .d.ts, .mts, .spec.ts, .stories.ts, .test.ts, ほか1件
- 構文を考慮した検索と構造コンテキストのための実際のAST解析。
- 名前付きシンボルはセマンティック検索と相互参照に利用されます。関係抽出が有効な場合は、グラフナビゲーションも利用できます。
- この言語は、グラフを考慮した検索にシンボルと関係情報を提供します。対応するエッジの種類は、その言語固有の構文要素によって異なります。
- AST解析とシンボル抽出の両方に対応しています。

## 最適な用途

- 1つのTypeScriptリポジトリの中でNext.js、Nodeサービス、共有パッケージ、ツール群を運用する、プロダクト/プラットフォームチーム。
- インターフェース、DTO、スキーマ、Reactコンポーネントが連動して動くものの、異なるディレクトリに置かれているリポジトリ。
- 共有の型やパッケージ境界に手を加える前に、AIエージェントに安全なコンテキストを与えようとするチーム。

## エージェントワークフロー

- 型、インターフェース、コンポーネントを、その定義から実際に使用しているコードパスまで追う。
- 共有ヘルパーやAPIコントラクトを変更する前に、パッケージ横断で実装を比較する。
- 共有の型、ユーティリティ、サービスモジュールを編集した場合に想定される影響範囲をマッピングする。

## TypeScriptのページが重要な理由

TypeScriptは、多くのチームがAI支援によるリファクタリングにようやく安心感を抱けると期待する言語です。型システムは助けにはなりますが、本当の問題を取り除いてはくれません。共有パッケージ、DTO、生成されたクライアント、Reactコンポーネント、テスト、アプリコードのすべてが、大規模なリポジトリの中で同じ名前を引き合いに出しているという問題です。

TypeScriptにとって、基準は「構文を理解している」よりも高いところにあります。エージェントは、共有の型、フック、クライアントを編集する前に、定義から実装、影響範囲へとコントラクトをたどる必要があります。

## MaguyvaがTypeScriptで実際に抽出するもの

Maguyvaは、`.ts`、`.mts`、`.cts`、そしてテストやストーリー周りの一般的なTypeScriptファイルのバリエーションにわたって、クラス、メソッド、インターフェース、型エイリアスを抽出します。メンバー接頭辞は正規化される一方、クラス修飾された識別子は保持されます。これは、リポジトリに素のヘルパー名と、同じ末尾セグメントを持つクラススコープのメソッドの両方がある場合に役立ちます。

JSXは単なるマークアップではなく、意味のある構造的な手がかりとして扱われます。インデックス済みのTypeScriptファイルでは、テスト、ストーリー、設定もアプリケーションコードとともに利用できるため、エージェントは共有コンポーネントやサービスを変更する前に、使用例や設定を確認できます。

## TypeScriptのリポジトリに役立つMCPワークフロー

通常、次の3つの出発点のパターンで十分です。

- `find_symbol`を使う — インターフェース、型エイリアス、フック、サービスの名前がすでに分かっているとき。
- `dependency_search`を使う — パッケージ横断で波及する可能性のある共有の型やクライアントを変更する前に。
- `structural_search`を使う — キーワード一致ではなくコードの形が必要なとき、例えば繰り返されるコンポーネントやメソッドのパターンなど。

「チェックアウトの送信パスを追う」のような概念的な疑問には、生の検索よりも`get_task_context`の方がしばしば良い最初の一手になります。

## このページが特に関連する場面

このページは、TypeScriptが複数のパッケージの調整レイヤーとなっているWeb/プラットフォームのモノレポにおいて、最も力を発揮します。リポジトリに今も古いJSが多く含まれる場合は、[JavaScriptガイド](/ja/languages/javascript)を読んでください。あなたの疑問が本当に「エージェントはアプリコードとインフラのコンテキストを一緒に保持できるか」というものであれば、これを[Terraform](/ja/languages/terraform)と組み合わせて読んでください。

## エンジンの詳細

- TypeScriptでは、すべてを汎用的なシンボルにまとめてしまうのではなく、クラス・メソッド・インターフェース・型エイリアスを個別に抽出します。
- メンバーのプレフィックスは除去されますが、クラス修飾された識別子は保持されるため、`CheckoutService.create` を単なる `create` と区別できます。
- JSX要素はインスタンス化として扱われます。インデックス済みのTypeScriptファイルでは、テスト、ストーリー、設定もアプリケーションコードとともにコンテキストとして利用できます。

## 役立つMCPエントリーポイント

- `find_symbol`: 調べたい共有インターフェース、型エイリアス、フック、サービスが分かっている場合はここから始めてください。
- `dependency_search`: 共有のDTOやクライアントを変更する前に使用し、パッケージ横断での現実的な影響範囲を把握してください。
- `structural_search`: 文字列一致ではなくパターンで検索したいとき、例えば繰り返し現れるコンポーネントやメソッドの形状を探すときは、ASTレベルの検索を使用してください。