エージェント ツール コンパイラー: 自然言語インテントからコンパイル パイプライン経由で実行可能なツール コードまで

1. コンパイラーとしてのエージェント: 類似性とその意味

コンパイラは、字句解析、解析、意味解析、中間表現、最適化、コード生成という明確に定義された一連の段階を通じて、高級言語で書かれたソース コードを実行可能なマシン コードに変換します。各段階には正式な保証があります。パーサーは構文の妥当性を保証します。型チェッカーはセマンティックな一貫性を保証します。オプティマイザーは、パフォーマンスを向上させながらプログラムのセマンティクスを保持します。コード ジェネレーターは、出力がターゲット アーキテクチャに対して有効であることを確認します。

ツール生成エージェントは、これらの段階をすべてスキップします。これらは、自然言語 (可能な限り最高レベルの「言語」) を取得し、単一のステップで実行可能コード (最低レベル) を生成します。これは、中間表現、型チェック、最適化、形式保証を行わずに、ソース テキストからマシン コードに直接変換するコンパイラーと同等です。結果は予測可能です。生成されたツールにはデッド コードが含まれ、エラー ケースが欠落し、型安全性が欠如し、セキュリティ脆弱性が含まれ、最適化対象の構造化表現がないために最適化できません。

Agent Tool Compiler は、コンパイラ エンジニアリングの原則をツール合成に適用します。 |コンパイラステージ |従来のコンパイラ |エージェント ツール コンパイラ | |---|---|---| |ソース言語 |プログラミング言語（C、Rustなど） |自然言語（英語、日本語など） | |字句解析 |トークン化 |インテント抽出 | |解析 |構文ツリーの構築 |インテントAST構築 | |意味解析 |型チェック、スコープ解決 |契約推論、副作用分析 | | IR生成 | LLVM IR、SSA フォーム |ツール IR (汎用ツールの説明) | |最適化 |デッドコードの除去、ループの展開 |セキュリティ強化、キャッシュ、並列化 | |コード生成 | x86、ARM マシンコード | TypeScript、Python、WASM | |リンク |ライブラリリンク、シンボル解決 |ランタイム統合、依存関係注入 |

このたとえは、単に教育的なものではありません。これは、各段階の境界でテスト可能な保証を備えた特定のエンジニアリング アーキテクチャを意味します。

2. フロントエンド: 自然言語からインテントへの AST

フロントエンド ステージでは、非構造化自然言語のインテントを構造化された インテント AST に変換します。これは、ツールがどのように行うべきかを指定せずに何を行うかをキャプチャする抽象構文ツリーです。インテント AST は、ユーザーのリクエストのコンパイラーの内部表現であり、従来のコンパイラーがソース コードから構築する構文ツリーに似ています。

// Intent AST node types
interface IntentAST {
  root: IntentNode
  metadata: {
    sourceUtterance: string    // Original NL input
    confidence: number         // Parser confidence score
    ambiguities: Ambiguity[]   // Unresolved ambiguities for human review
  }
}

type IntentNode =
  | ActionNode          // "fetch", "transform", "validate", "store"
  | DataFlowNode        // Input → Processing → Output
  | ConstraintNode      // "must complete in < 5s", "must not expose PII"
  | ErrorModeNode       // "if API returns 429, retry with backoff"
  | SideEffectNode      // "writes to database", "sends notification"
  | CompositionNode     // Sequential, parallel, or conditional composition

interface ActionNode {
  type: "action"
  verb: string                 // Normalized action verb
  object: string               // What the action operates on
  parameters: ParameterSpec[]  // Inferred parameters with types
  returnType: TypeSpec          // Inferred return type
}

interface ConstraintNode {
  type: "constraint"
  category: "performance" | "security" | "compliance" | "resource"
  predicate: string            // Formal constraint expression
  priority: "must" | "should" | "may"
}

フロントエンドは 2 フェーズの解析戦略を使用します。 フェーズ 1 (意図の抽出) では、LLM を使用して自然言語記述から構造化された意図を抽出し、ドラフトの意図 AST を生成します。このフェーズは本質的にあいまいです。自然言語は曖昧であり、LLM の解釈が間違っている可能性があります。 フェーズ 2 (意図の検証) では、パラメータの型推論、副作用分析、制約の一貫性チェック、および曖昧さの検出といった決定論的なルールを AST ドラフトに適用します。フェーズ 2 で解決できない曖昧さが見つかった場合、コンパイルを続行する前に人間によるレビューのためにフラグが立てられます。

重要な洞察は、フロントエンドが理解 (フェーズ 1、LLM を利用した、ファジー) と検証 (フェーズ 2、ルールベース、決定論的) を分離していることです。これはまさに従来のコンパイラの動作方法です。パーサーは構文的には有効でも意味的に意味のないプログラムを受け入れ、セマンティック アナライザーがエラーをキャッチします。問題を分割することにより、理解段階が本質的に確率的であっても、形式的手法を検証段階に適用できます。

\text{Parse}: \Sigma^* \rightarrow \text{IntentAST} \cup \{\perp\}

ここで、$\Sigma^*$ はすべての自然言語文字列のセットで、$\perp$ は解析の失敗を示します (意図が曖昧または矛盾しすぎてコンパイルできない)。解析関数は完全なものではありません。一部の自然言語入力はツールにコンパイルできないため、コンパイラーは不正な出力を生成するのではなく、それらを拒否する必要があります。

3. ミドルエンド: インテント AST から API 仕様へ

ミドルエンドは、Intent AST を具体的な API 仕様、つまりツールのインターフェイス コントラクトに落とし込みます。このステージでは、型の推論、パラメーターの設計、エラー コントラクトの定義、およびリソースの推定を実行します。 「このツールが何をすべきかを考えると、その API はどのようなものであるべきですか?」という質問に答えます。

interface ToolAPISpec {
  name: string                      // Generated from action verb + object
  description: string               // Human-readable description
  version: string                   // Semantic version

  input: {
    parameters: TypedParameter[]    // Name, type, required, default, validation
    constraints: InputConstraint[]  // Pre-conditions
  }

  output: {
    successType: TypeSpec           // Return type on success
    errorTypes: ErrorSpec[]         // Possible error types with codes
    sideEffects: SideEffect[]       // Declared side effects
  }

  contract: {
    idempotent: boolean             // Safe to retry?
    timeout: number                 // Maximum execution time (ms)
    retryPolicy: RetryPolicy        // How to handle transient failures
    resourceBudget: ResourceBudget  // CPU, memory, network limits
  }

  security: {
    requiredPermissions: string[]   // What the tool needs access to
    dataClassification: string      // PII, confidential, public
    auditLevel: "full" | "summary" | "none"
  }
}

ソース型は正式な型システムではなく自然言語から取得されるため、ミドルエンドでの型推論は特に困難です。コンパイラーは、ヒューリスティック型推論 (パラメーター名とコンテキストから型を推論します。たとえば、「email」は電子メール パターンに一致する文字列である可能性が高く、「count」は負ではない整数である可能性が高くなります) と制約伝播 (パラメーターがダウンストリームの算術演算で使用される場合は、数値である必要があります) の組み合わせを使用します。

ミドルエンドでは インターフェイス設計の最適化も実行されます。推論されたパラメータが与えられると、関連するパラメータをオブジェクトにグループ化し、デフォルトを持つ必要があるオプションのパラメータを特定し、境界で検証する必要があるパラメータか実装内部で検証する必要があるパラメータを決定し、パラメータの数とタイプに基づいて位置パラメータ スタイルと名前付きパラメータ スタイルのどちらかを選択します。この最適化により、パラメーターの設計が後回しになるアドホック生成よりも、よりクリーンで人間工学に基づいた API が生成されます。

4. バックエンド: API 仕様からコード生成まで

バックエンド ステージは、ツール API 仕様から実行可能コードを生成します。フロントエンド (理解に LLM を使用) やミドルエンド (ルールベースの推論を使用) とは異なり、バックエンドは ハイブリッド生成戦略 を使用します。つまり、ボイラープレート (パラメーター検証、エラー処理、ログ) にはテンプレート ベースの生成、実装ロジック (ツールが実行する実際の計算) には LLM ベースの生成です。

バックエンドは、共有コード生成フレームワークを通じて複数の言語を対象としています。

// Multi-target code generation
interface CodeGenerator {
  target: "typescript" | "python" | "wasm"

  // Boilerplate generation (template-based, deterministic)
  emitParameterValidation(params: TypedParameter[]): string
  emitErrorHandling(errors: ErrorSpec[]): string
  emitLogging(auditLevel: string): string
  emitRetryWrapper(policy: RetryPolicy): string
  emitResourceGuard(budget: ResourceBudget): string

  // Implementation generation (LLM-based, validated)
  emitImplementation(
    spec: ToolAPISpec,
    intentAST: IntentAST
  ): Promise<string>

  // Assembly
  assemble(parts: CodeParts): CompiledTool
}

interface CompiledTool {
  source: string               // Generated source code
  sourceMap: SourceMap          // Maps generated code to Intent AST nodes
  typeDeclarations: string     // Type definitions for the tool's API
  testSuite: TestCase[]        // Auto-generated tests from the API spec
  documentation: string        // Auto-generated API documentation
}

定型文を実装から分離することが重要です。ボイラープレート コード (検証、エラー処理、ログ、再試行ロジック) は予測可能なパターンに従い、テンプレートから決定論的に生成できます。実装コード (実際のロジック) にはドメインの理解が必要で、LLM によって生成されます。コンパイラは定型的なボイラープレートを生成することにより、LLM で生成された実装の品質に関係なく、すべてのツールで一貫したエラー処理、検証、ログ記録を行うことができます。

ソース マップは重要なアーティファクトです。ソース マップは、生成されたコードのすべての行を、その動機となった Intent AST ノードにマッピングします。これにより、デバッグ (「ユーザーが『API からデータを取得する』と言ったため、この行が生成されました」)、監査 (「ツールが PII データを処理するため、このセキュリティ チェックが追加されました」)、および変更 (「この動作を変更するには、対応する Intent AST ノードを変更して再コンパイルします」) が可能になります。

5. 最適化パス: 正しいものから効率的かつ安全なものへ

最初のコード生成後、コンパイラーは一連の最適化パスを適用します。各パスは、意味上の等価性を維持しながら、生成されたコードを変換します (各パスの後にテスト スイートを再実行することで検証されます)。

パス 1: デッド コードの除去。 LLM で生成されたコードには、到達不能な分岐、未使用の変数、冗長な計算が含まれることがよくあります。コンパイラは、制御フロー グラフとデータ フロー分析を使用して標準的なデッド コード分析を実行し、出力に影響を及ぼさないコードを削除します。一般的な削減: 生成された行の 15 ～ 25%。

パス 2: セキュリティ強化 コンパイラは、ツールのデータ分類と必要な権限に基づいてセキュリティ チェックを挿入します。 PII を処理するツールについては、入力のサニタイズ、出力の編集、監査ログが追加されます。外部 API 呼び出しを行うツールの場合、リクエストの署名、TLS 検証、および応答の検証が追加されます。データベースに書き込むツールの場合、パラメーター化されたクエリ構築 (SQL インジェクションの防止) とトランザクション境界が追加されます。

パス 3: 型の絞り込み。 LLM は正確な型について不確実であるため、LLM で生成されたコードは広範な型 (「any」、「object」、「unknown」) を使用する傾向があります。コンパイラは型の絞り込み分析を実行します。実装で値が実際にどのように使用されているかを調べ、すべての使用法と一貫性のある最も具体的な型に型を絞り込みます。これにより、実行時に表面化する可能性のある型エラーがコンパイル時に捕捉されます。

パス 4: 並列化。 コンパイラは、同時に実行できる独立した操作を識別します。さまざまなエンドポイントへの連続的な API 呼び出し、独立したデータ変換、および非依存の検証チェックは、Promise.all (TypeScript) または asyncio.gather (Python) を使用して自動的に並列化されます。一般的な高速化: 複数の外部呼び出しを行うツールの場合は 30 ～ 50%。

パス 5: キャッシュ挿入。 同じパラメーターで繰り返し呼び出しを行うツール (データ エンリッチメント ツールで一般的) の場合、コンパイラーは構成可能な TTL を持つメモ化レイヤーを挿入します。キャッシュの決定は、API 仕様でのツールのべき等性宣言に基づいて行われます。つまり、べき等な操作のみがキャッシュされます。

パス 6: エラー回復挿入。 コンパイラーはツールのエラー モードを分析し、回復ロジックを挿入します。一時的なエラーの場合は指数関数的バックオフによる再試行、永続的な障害の場合はサーキット ブレーカー、オプションの依存関係の場合はグレースフル デグラデーション パス、回復不可能な障害の場合は構造化エラー レポートを実行します。

\text{Optimize}: \text{Code} \xrightarrow{P_1} \text{Code} \xrightarrow{P_2} \cdots \xrightarrow{P_n} \text{Code}'

ここで、各パス $P_i$ はセマンティクスを保持します: $\forall x。 \; \text{eval}(P_i(\text{コード}), x) = \text{eval}(\text{コード}, x)$。パスの構成もセマンティクスを保持し、最適化されたコードがすべての有効な入力に対して最適化されていないコードと同一の出力を生成するようにします。

6. エージェントツールのタイプシステム

ATC には、エージェント ツール用に特別に設計された型システムが含まれています。この型システムは、エージェント固有の懸念事項を捕捉する構造を備えた標準プログラミング言語の型システムを拡張します。

// Agent Tool Type System
type ToolType =
  | PrimitiveType          // string, number, boolean, null
  | StructType             // { field: Type, ... }
  | ArrayType              // Type[]
  | UnionType              // Type | Type
  | ConstrainedType        // Type & constraint (e.g., string & email)
  | ResourceType           // External resource reference (URL, DB connection)
  | SensitiveType          // Wraps any type to mark it as PII/confidential
  | TemporalType           // Time-bounded values (expires after TTL)
  | FallibleType           // Result<T, E> — explicit success/error

// Constrained types enforce domain rules at the type level
type EmailAddress = ConstrainedType<string, "matches(/^[^@]+@[^@]+$/)">;
type PositiveInt = ConstrainedType<number, "x > 0 && Number.isInteger(x)">;
type Percentage = ConstrainedType<number, "x >= 0 && x <= 100">;

// Sensitive types trigger automatic security measures
type SSN = SensitiveType<string, "PII">;
// Compiler auto-injects: input validation, output redaction, audit logging

// Temporal types prevent stale data usage
type CachedPrice = TemporalType<number, { ttl: 300_000 }>; // 5 min TTL
// Compiler auto-injects: expiry check before use, refresh on expiry

型システムでは、次の 3 つの主要なプロパティが強制されます。 1. ツール境界を越えた型安全性 ツール A の出力がツール B の入力にフィードされるとき、コンパイラーはコードが生成される前に、IR レベルで型の互換性を検証します。これにより、コンパイル時に統合エラーが検出されます。 2. 構築によるセキュリティ 機密タイプはデータ フローを通じて伝播します。ツールが「SensitiveType」入力を受信すると、そこから派生した出力も機密としてマークされます。これにより、偶発的なデータ漏洩が防止されます。コンパイラーは、機密データを明示的に機密解除せずにログに記録、キャッシュ、または返すコードの生成を拒否します。 3. 時間的な正確さ 時間型は、型システムの鮮度要件をエンコードすることで、古いデータのバグを防ぎます。キャッシュされたデータを使用するツールは、キャッシュの有効期限が切れた場合に対処する必要があり、コンパイラは更新ロジックを自動的に生成します。

7. ツール IR: 汎用ツール記述形式

ツール IR は ATC の中心的なデータ構造であり、ソース言語またはターゲット言語に関係なく、すべてのツールが通過する中間表現です。 IR は、言語に依存せず、最適化可能でシリアル化可能であるように設計されています。

interface ToolIR {
  // Identity
  id: string
  name: string
  version: string

  // Data flow graph
  entryBlock: IRBlock
  blocks: IRBlock[]
  edges: IREdge[]

  // Type environment
  typeEnv: Map<string, ToolType>

  // Resource declarations
  resources: ResourceDeclaration[]

  // Constraint set
  constraints: IRConstraint[]
}

interface IRBlock {
  id: string
  kind: "entry" | "compute" | "branch" | "call" | "error" | "exit"
  instructions: IRInstruction[]
  successors: string[]          // Block IDs
}

type IRInstruction =
  | { op: "load"; target: string; source: string }
  | { op: "validate"; target: string; constraint: string }
  | { op: "transform"; target: string; fn: string; args: string[] }
  | { op: "call"; target: string; service: string; method: string; args: string[] }
  | { op: "branch"; condition: string; trueBlock: string; falseBlock: string }
  | { op: "return"; value: string }
  | { op: "error"; code: string; message: string }

IR は、従来のコンパイラ設計から借用した 基本ブロック 構造を使用します。各ブロックには、単一のエントリ ポイントと 1 つ以上の出口エッジを持つ一連の命令が含まれています。この構造により、標準的なコンパイラの最適化が可能になります。共通の部分式の削除 (2 つのブロックが同じ値を計算する場合)、ループ不変のコード モーション (値がループ反復全体で一定の場合)、分岐予測 (条件が静的に決定可能な場合) です。

IR は、ツールがツール レジストリに保存される形式でもあります。ツールを別のターゲット言語用に再コンパイルする必要がある場合、または最適化パスが改善された場合、元の自然言語の意図を再解析することなく、ツールを IR から再コンパイルできます。これにより、ツールのセマンティクスがツールの実装から切り離されます。IR はツールの動作をキャプチャし、バックエンドがその方法を決定します。

8. ランタイム統合: コンパイル済みツールのホットロード

コンパイルされたツールは、再起動を必要とせずにエージェント ランタイムに統合する必要があります。 ATC は、ホットロード、つまり実行中のエージェントに対してツールを追加、置換、または削除する機能を実装します。

ホットロード プロトコルは次の 3 つの手順に従います。 1. 分離。 コンパイルされたツールは、分離された実行コンテキスト (TypeScript の場合は V8 分離、Python の場合はサブプロセス、WASM の場合は WASM サンドボックス) にロードされます。隔離により、不正なツールがエージェント ランタイムをクラッシュしたり、他のツールの状態にアクセスしたりすることがなくなります。 2. 登録。 ツールの API 仕様はエージェントのツール レジストリに登録され、ツール選択システムで検出できるようになります。登録はアトミックです。ツールは完全に (すべてのメタデータ、タイプ、エントリ ポイントを) 登録するか、まったく登録しません。 3. ウォームアップ ランタイムは、ツールの自動生成されたテスト スイートを分離されたコンテキストで実行し、コンパイルされたコードが (コンパイル サンドボックスだけでなく) 運用環境で実際に動作することを検証します。ウォームアップが失敗した場合、登録はロールバックされます。

Hot-loading enables a powerful development loop: an agent identifies a need for a new tool, compiles it through the ATC pipeline, hot-loads it into its own runtime, and begins using it — all without human intervention or system restart. The entire cycle from intent to executable tool takes less than 2 seconds in benchmarks.

9. コンパイルエラー処理: ツールのコンパイルが失敗した場合

すべての自然言語インテントをツールにコンパイルできるわけではありません。 ATC はコンパイル エラーの分類を定義しており、それぞれに特定の回復戦略が含まれています。

コンパイル エラーは従来の意味での失敗ではなく、情報です。あいまいな意図エラーは、コンパイラーがユーザーからのより多くの情報を必要とすることを意味します。矛盾した制約エラーは、ユーザーの要件が物理的に不可能であることを意味します。セキュリティ違反エラーは、ツールが持っていないアクセス許可を必要とすることを意味します。いずれの場合も、コンパイラは問題を説明し、解決策を提案する構造化されたエラー レポートを生成します。

Compilation errors are a feature, not a bug. A compiler that never rejects input is not performing validation. The ATC's ability to reject malformed intents — and explain why — is one of its primary advantages over ad-hoc generation, where the LLM will always produce some code regardless of whether the intent is compilable.

10. ベンチマーク: コンパイル時間と生成されたコードの品質

コンパイル時間、コード品質、実行時の信頼性という 3 つの側面にわたって、アドホック LLM ベースのツール生成に対して ATC をベンチマークします。

ATC は複数段階の分析と最適化を実行するため、コンパイルに時間がかかります (1.8 秒対 1.2 秒)。ただし、コンパイルされたツールは、あらゆる品質指標において大幅に優れています。コード サイズの 40% の削減は、主にデッド コードの削除 (パス 1) と、LLM で生成された同等のものよりもコンパクトなテンプレート ベースのボイラープレートによってもたらされます。実行時エラーの 60% の削減は、型の絞り込み (パス 3)、セキュリティの強化 (パス 2)、およびエラー回復挿入 (パス 6) によるものです。 25% のレイテンシーの改善は、並列化 (パス 4) とキャッシュ (パス 5) によるものです。

コンパイル時間のオーバーヘッド (0.6 秒) は、ツールの存続期間にわたって償却されます。つまり、一度コンパイルされたツールは数千回または数百万回実行されます。品質の向上はさらに複雑になります。実行時エラーが減れば、再試行も減り、デバッグも減り、エージェントの信頼性が高まります。

11. 数学的基礎: ツール生成に適用される形式言語理論

私たちは、ツールのコンパイルに関与する言語の階層を定義することによって、ATC を形式言語理論に基づいています。

レベル 0: 自然言語 ($\mathcal{L}_0$)。 入力言語 - 制限のない自然言語。これはチョムスキー階層のタイプ 0 言語 (再帰的に列挙可能) であり、どの有限オートマトンでも完全には解析できないことを意味します。フロントエンドの LLM は、このレベルの近似パーサーとして機能します。

レベル 1: インテント言語 ($\mathcal{L}_1$)。 インテント AST 言語 - ツールのインテントを捕捉する文脈自由文法。これはチョムスキー階層の Type-2 言語であり、プッシュダウン オートマトンによって解析可能です。文法は IntentAST スキーマによって定義されます。

\mathcal{L}_1 = \{ w \in \text{IntentAST}^* : \text{valid}(w) \}

レベル 2: ツール IR 言語 ($\mathcal{L}_2$)。 IR 言語 - 基本ブロックのデータ フロー グラフを記述する通常の言語 (チョムスキー階層のタイプ 3)。 IR には再帰がない (ツールは単一レベルの関数であり、再帰的プログラムではない) ため、有限オートマトンとして表すことができます。

\mathcal{L}_2 = \{ w \in \text{ToolIR}^* : \text{wellTyped}(w) \land \text{acyclic}(w) \}

レベル 3: 実行可能コード ($\mathcal{L}_3$)。 出力言語 - コード ジェネレーターが生成できるパターンに制限されたターゲット プログラミング言語のサブセット。

コンパイル パイプラインは一連の言語変換です。

\text{ATC}: \mathcal{L}_0 \xrightarrow{\text{Frontend}} \mathcal{L}_1 \xrightarrow{\text{Middle-end}} \mathcal{L}_2 \xrightarrow{\text{Backend}} \mathcal{L}_3

各変換により、言語の複雑さが軽減されます。タイプ 0 (無制限) からタイプ 2 (コンテキストフリー)、タイプ 3 (通常)、そしてタイプ 2 言語の制限されたサブセットまでです。この複雑さの軽減により、最適化が可能になります。タイプ 0 言語は最適化できません (決定不可能です) が、タイプ 3 言語は最適化できます (完全に分析可能です)。

正式な基礎により、コンパイラの正確さの基準も得られます。

\forall i \in \mathcal{L}_0. \; \text{ATC}(i) \neq \perp \implies \text{semantics}(\text{ATC}(i)) \subseteq \text{intent}(i)

つまり、コンパイラーが出力を正常に生成した場合、生成されたコードのセマンティクスは、自然言語入力で表現された意図のサブセットである (つまり、一貫している) 必要があります。 (等価ではなく) サブセット関係は、自然言語の意図が過小指定されている可能性があることを認識しています。コンパイルされたツールは、意図の 1 つの有効な解釈を実装しますが、必ずしも唯一の有効な解釈ではありません。

12. 結論

Agent Tool Compiler は、ツール生成をコンパイルの問題として再構成し、現在アドホック LLM 生成が主流となっている領域に、数十年にわたるコンパイラ エンジニアリングの厳密さをもたらします。アーキテクチャ上の重要な洞察は、コード生成による最適化から理解までを切り離す、中間表現 (Intent AST と Tool IR) の導入です。各ステージには明確な入力、出力、および正確さの基準があります。最適化パスにより、アドホックなツールよりも小型、高速、安全、信頼性の高いツールが生成されます。型システムは、実行時エラーとして表面化するであろうエラーをコンパイル時に捕捉します。そして、形式言語理論の基礎は、コンパイラーの正確性を推論するためのフレームワークを提供します。 MARIA OS では、ATC は自己拡張エージェントが無秩序ではなく体系的に能力を拡張できるようにするインフラストラクチャです。新しいツールはすべて、パイプラインを通じてコン​​パイル、最適化、型チェック、統合され、あらゆる段階で品質を保証します。