【入門】Kiro CLI を使いこなすために押さえておくべきこと

はじめに

先月（2025 年 11 月） Amazon Q から Kiro CLI へと進化を遂げた AWS 製の生成 AI CLI ツールを効果的に活用するために、最低限押さえておくべき機能についてまとめてみました。
本記事では、それぞれの基本的な使い方を解説します。

Amazon Q からの相違点についてはこちらの記事をご覧ください。

1. Chat

従来のチャットツールとの違い

Kiro CLI は AWS の開発環境に特化し、プロジェクト固有の知識学習と細かい権限制御、AWS サービスとのシームレスな統合を組み合わせた AI アシスタントです。

# 基本的な起動
kiro-cli chat

# プロジェクト固有のエージェントで起動
kiro-cli chat --agent aws-specialist

# 過去のセッションを復元
kiro-cli chat --resume

会話の永続化と再利用

重要な設定手順やトラブルシューティングの過程を保存し、チーム全体で共有できます：

# 重要な会話を保存
/save docker-setup-guide

# 後日、同じコンテキストで再開
/load docker-setup-guide

実用例：

複雑なインフラ設定手順の記録
新メンバーへのオンボーディング資料
問題解決プロセスの共有

`/editor` コマンドで効率的に複数行のプロンプトを入力

長いコードや詳細な要件を効率的に入力：

# 方法1：/editor コマンド（デフォルト：vi）
/editor

# 方法2：キーボードショートカット
Ctrl + J  # 改行を挿入して複数行入力

`/reply` コマンドによる返信

直前の Kiro 出力メッセージを引用してプロンプトを作成します：

/reply  # 最新メッセージを引用してエディタが開く

`/prompts` コマンドによる再利用可能なプロンプト管理

よく使うプロンプトを保存・管理：

# プロンプト一覧を表示
/prompts list

# 新しいプロンプトを作成
/prompts create --name code-review --content "コードレビューを実施してください"

# プロンプトを編集
/prompts edit code-review

# プロンプトの詳細を確認
/prompts details code-review

# プロンプトを使用（@プレフィックス）
@code-review
@team-standup

プロンプトの保存場所と優先順位：

ローカル：.kiro/prompts/（プロジェクト固有、最優先）
グローバル：~/.kiro/prompts/（全プロジェクト共通）
MCP プロンプト：MCP サーバー提供（引数対応）

3 つのコンテキスト管理方法：

Agent Resources：永続的（エージェント設定で定義）
Session Context：一時的（/context コマンド）
Knowledge Bases：大規模データ用（検索時のみアクティブ）

参考：Manage prompts

`/context` コマンドによる動的なコンテキスト管理

現在のセッションで一時的にファイルを追加・削除：

# ファイルをコンテキストに追加
/context add README.md
/context add docs/*.md

# コンテキスト使用状況を確認
/context show

# 不要なファイルを削除
/context remove temp-file.py

# 全セッションコンテキストをクリア
/context clear

参考：Context management

その他のコマンド確認

Ctrl + S  # コマンド一覧を表示

参考： Chat

2. Custom Agents

なぜカスタムエージェントが必要なのか？

プロジェクトごとに異なる技術スタック、規約、権限要件に対応するため、Kiro CLI では専門化されたエージェントを作成できます。

エージェント設定の基本構造

エージェント設定ファイルは JSON 形式で、以下の主要フィールドで構成されます：

{
  "name": "エージェント名",
  "description": "エージェントの説明",
  "prompt": "システムプロンプト",
  "model": "使用するモデル",
  "tools": ["利用可能なツール"],
  "allowedTools": ["自動許可するツール"],
  "toolsSettings": { "ツール固有の設定" },
  "resources": ["アクセス可能なリソース"],
  "hooks": { "ライフサイクルフック" }
}

実践的なエージェント設定例

AWS 専門のエージェント：

{
  "name": "aws-specialist",
  "description": "AWS専門エージェント",
  "prompt": "You are an expert AWS infrastructure specialist",
  "model": "claude-sonnet-4",
  "tools": ["read", "write", "aws", "@git"],
  "allowedTools": ["read", "aws:s3:*", "@git/git_status"],
  "toolsSettings": {
    "aws": {
      "allowedServices": ["s3", "lambda", "ec2"],
      "deniedServices": ["iam", "organizations"],
      "autoAllowReadonly": true
    },
    "write": {
      "allowedPaths": ["infrastructure/**", "*.yaml"],
      "deniedPaths": [".env", "*.key", "credentials/**"]
    }
  },
  "resources": [
    "file://README.md",
    "file://infrastructure/**/*.yaml",
    "file://docs/aws-setup.md"
  ]
}

Tools フィールドの詳細設定

利用可能なツール指定方法：

{
  "tools": [
    "read", // 組み込みツール
    "write", // 組み込みツール
    "@git", // Git MCP サーバーの全ツール
    "@rust-analyzer/check_code", // Rust Analyzer MCP サーバーの特定ツール
    "*" // 全ツール（開発時のみ推奨）
  ]
}

特殊な指定方法：

"*"：全ての利用可能なツール
"@builtin"：全ての組み込みツール
"@server_name"：特定の MCP サーバーが提供する全ツール

AllowedTools による権限制御

自動許可パターンの設定：

{
  "allowedTools": [
    // 完全一致
    "read",
    "@git/git_status",

    // ワイルドカード パターン
    "code_*", // code_review, code_analysis など
    "*_bash", // execute_bash, run_bash など
    "@server/read_*", // MCP サーバーの read_ 系ツール
    "@git-*/status", // git-* MCP サーバーの status ツール

    // サーバーレベル許可
    "@fetch", // fetch MCP サーバーの全ツール
    "@git-*" // git-* パターン MCP サーバーの全ツール
  ]
}

パターンマッチングルール：

*：任意の文字列（空文字含む）
?：1 文字
完全一致が優先
大文字小文字を区別

ToolsSettings による詳細制御

ツール固有の設定例：

{
  "toolsSettings": {
    "write": {
      "allowedPaths": ["src/**", "docs/**"],
      "deniedPaths": [".env", "*.key", "secrets/**"]
    },
    "shell": {
      "allowedCommands": ["git status", "npm test"],
      "deniedCommands": ["rm -rf", "sudo *"],
      "autoAllowReadonly": true
    },
    "aws": {
      "allowedServices": ["s3", "lambda"],
      "deniedServices": ["iam", "organizations"],
      "autoAllowReadonly": true
    }
  }
}

エージェントの配置と優先順位

ローカルエージェント（プロジェクト固有）：

.kiro/agents/
├── dev-agent.json
├── aws-specialist.json
└── code-reviewer.json

グローバルエージェント（ユーザー全体）：

~/.kiro/agents/
├── general-assistant.json
├── documentation-writer.json
└── security-auditor.json

優先順位：

ローカルエージェント（.kiro/agents/）
グローバルエージェント（~/.kiro/agents/）

ToolAliases

MCP ツール間の名前競合を解決：

{
  "toolAliases": {
    "@github-mcp/get_issues": "github_issues",
    "@gitlab-mcp/get_issues": "gitlab_issues"
  }
}

MCP ツールに別名で短いツール名を付与：

{
  "toolAliases": {
    "@aws-cloudformation/deploy_stack_with_parameters": "deploy_cf",
    "@kubernetes-tools/get_pod_logs_with_namespace": "pod_logs"
  }
}

プロンプトファイルの外部化

サイズが大きなプロンプトは、外部ファイルとして参照可能：

{
  "prompt": "file://./prompts/aws-expert.md"
}

エージェント実用例

セキュリティ重視の本番環境エージェント：

{
  "name": "production-safe",
  "description": "本番環境用の制限されたエージェント",
  "allowedTools": ["read", "@git/git_status", "@aws/describe_*"],
  "toolsSettings": {
    "write": {
      "allowedPaths": ["logs/**"],
      "deniedPaths": ["**"]
    },
    "aws": {
      "allowedServices": ["cloudwatch", "logs"],
      "autoAllowReadonly": true
    }
  }
}

開発環境用の柔軟なエージェント：

{
  "name": "dev-assistant",
  "description": "開発環境用の全機能エージェント",
  "tools": ["*"],
  "allowedTools": ["read", "write", "shell", "@git/*", "@docker/*"],
  "toolsSettings": {
    "shell": {
      "autoAllowReadonly": true
    }
  }
}

ベストプラクティス

セキュリティ：

最小権限の原則を適用
本番環境では厳格な制限
機密ファイルへのアクセスを明示的に拒否

組織化：

説明的な名前を使用
プロジェクトごとにローカルエージェント
チーム共通設定はバージョン管理

テスト：

安全な環境で権限をテスト
段階的に権限を拡張
ツール設定の動作確認

参考： Custom Agents, Agent Configuration Reference

3. MCP

MCP でできること：

専門的な知識ベースやドキュメントへのアクセス
外部サービスや API との統合
ドメイン固有のツールによる機能拡張
特定のワークフロー向けカスタムツールの作成

設定方法

MCP サーバーの設定には 3 つの方法があります：

1. コマンドライン設定：

kiro-cli mcp add \
  --name "awslabs.aws-documentation-mcp-server" \
  --scope global \
  --command "uvx" \
  --args "awslabs.aws-documentation-mcp-server@latest"

2. mcp.json ファイル設定：

{
  "mcpServers": {
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      }
    },
    "github": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

3. エージェントファイルに設定することも可能：

// .kiro/agents/my-agent.json
{
  "name": "my-agent",
  "mcpServers": {
    "fetch": {
      "command": "uvx",
      "args": ["mcp-server-fetch"]
    }
  },
  "includeMcpJson": true
}

includeMcpJson オプション：

true：エージェント専用サーバー＋共通の mcp.json ファイルのサーバー
false：エージェント専用サーバーのみ

設定ファイルの優先順位

MCP サーバーは以下の優先順位で読み込まれます：

エージェント設定：mcpServers フィールド
ワークスペース設定：.kiro/settings/mcp.json
グローバル設定：~/.kiro/settings/mcp.json

実用的な MCP サーバー例

AWS ドキュメント検索：

# 自然言語でAWSドキュメントを検索
> Lambda の環境変数設定方法を調べて

# 特定のドキュメントページを読み込み
> AWS ECS タスク定義のドキュメントを読んで

GitHub 統合：

# リポジトリ情報の取得
> tensorflow/tensorflow リポジトリの情報を表示

# イシューの作成
> 私のリポジトリにログインバグについてのイシューを作成

環境変数の活用

機密情報は環境変数で管理：

{
  "mcpServers": {
    "api-server": {
      "env": {
        "API_KEY": "${YOUR_API_KEY}",
        "DEBUG": "true"
      }
    }
  }
}

# 環境変数の設定
export YOUR_API_KEY="your-actual-key"
export GITHUB_TOKEN="ghp_xxxxxxxxxxxx"

セキュリティ設定

ツールの無効化：

{
  "mcpServers": {
    "server-name": {
      "disabledTools": ["delete_file", "execute_command"]
    }
  }
}

サーバーの無効化：

{
  "mcpServers": {
    "server-name": {
      "disabled": true
    }
  }
}

現在の MCP サーバー設定を確認

# アクティブなMCPサーバーを確認
/mcp

参考： MCP Integration

4. Steering

Steering とは

Steering は、.kiro/steering/ 内のマークダウンファイルを通じて、Kiro にプロジェクトの永続的な知識を提供する機能です。毎回の会話で規約を説明する代わりに、確立されたパターンやライブラリ、標準を一貫して適用できます。

主な利点

一貫したコード生成：すべてのコンポーネントや API が確立されたパターンに従う
繰り返しの削減：プロジェクト標準を毎回説明する必要がない
チーム連携：新規メンバーも経験豊富な開発者も同じ標準で作業
スケーラブルな知識管理：コードベースと共に成長するドキュメント

ファイルのスコープ

ワークスペース Steering（.kiro/steering/）：

特定のプロジェクトにのみ適用
プロジェクト固有のパターンや標準を定義

グローバル Steering（~/.kiro/steering/）：

全ワークスペースに適用
個人またはチーム全体の共通規約を定義

優先順位： ワークスペース > グローバル

基本的なステアリングファイル

1. ステアリングフォルダの作成：

# ワークスペース用
mkdir -p .kiro/steering

# グローバル用
mkdir -p ~/.kiro/steering

2. 基本ファイルの作成：

.kiro/steering/
├── product.md     # プロダクト概要、目的、ユーザー、機能
├── tech.md        # 技術スタック、フレームワーク、ツール
└── structure.md   # ファイル構成、命名規則、アーキテクチャ

カスタムステアリングファイルの作成

専門的なガイダンスの追加：

.kiro/steering/
├── api-standards.md      # API 設計規約
├── testing-standards.md  # テスト手法とパターン
├── code-conventions.md   # コーディング規約
├── security-policies.md  # セキュリティガイドライン
└── deployment-workflow.md # デプロイメント手順

実践例：API 規約ファイル

api-standards.md：

# API 設計規約

## エンドポイント命名

- RESTful な URL 設計
- 複数形のリソース名（/users, /orders）
- バージョニング：/api/v1/

## レスポンス形式

- 成功：200 系ステータス
- エラー：統一フォーマット

## 認証

- JWT トークン
- Bearer 形式

ファイル参照機能

他のファイルを参照して具体例を提供：

# コンポーネント規約

## ボタンコンポーネントの例

#file:components/ui/button.tsx

## API 仕様

#file:api/openapi.yaml

AGENTS.md 標準対応

Kiro は AGENTS.md 標準もサポート：

# 自動で読み込まれる場所
~/kiro/steering/AGENTS.md    # グローバル
./AGENTS.md                  # ワークスペースルート

ベストプラクティス

ファイル設計：

1 ファイル 1 ドメイン（API、テスト、デプロイなど）
明確なファイル名（api-rest-conventions.md）
決定の理由も記載（なぜその標準なのか）

セキュリティ：

API キーやパスワードは含めない
ステアリングファイルはコードベースの一部

メンテナンス：

スプリント計画時に見直し
アーキテクチャ変更時に更新
コード変更と同様にレビューを実施

参考： Steering

AI: プロジェクトの API 規約に従って、以下のエンドポイントを実装します：

GET /api/v1/users

レスポンス形式も規約に合わせて統一されたエラーハンドリングを含めます...

参考： [Steering](https://kiro.dev/docs/cli/steering/)

## 5. Hooks：自動化されたワークフロー

### エージェント起動時の自動実行

Hooks 機能により、エージェント起動時に特定のコマンドを自動実行できます。

```json
{
  "hooks": {
    "agentSpawn": [
      {
        "command": "aws sts get-caller-identity",
        "timeout_ms": 10000
      },
      {
        "command": "git status --porcelain",
        "timeout_ms": 5000
      }
    ]
  }
}

実用的な活用例

開発環境の状態確認：

AWS 認証情報の確認
Git リポジトリの状態チェック
依存関係の更新確認
環境変数の検証

プロジェクト固有の初期化：

データベース接続テスト
必要なサービスの起動確認
設定ファイルの妥当性チェック

エラーハンドリング

{
  "hooks": {
    "agentSpawn": [
      {
        "command": "docker ps",
        "timeout_ms": 5000,
        "continueOnError": true,
        "description": "Docker サービス確認（オプション）"
      }
    ]
  }
}

参考： Custom Agents

6. Code Intelligence：LSP 統合による高度なコード理解

Code Intelligence とは

Code Intelligence は Language Server Protocol (LSP) を Kiro CLI に統合し、IDE と同等のセマンティックなコード理解機能を提供します。7 つの言語（TypeScript、Rust、Python、Go、Java、Ruby、C/C++）に事前対応し、カスタム LSP 設定で他の言語にも拡張可能です。

動作原理

Kiro CLI はバックグラウンドで LSP サーバープロセスを起動し、JSON-RPC over stdio で通信します。プロジェクトマーカー（package.json、Cargo.toml など）とファイル拡張子から言語を検出し、適切な言語サーバーを開始。サーバーはコードを継続的に解析してシンボル、型、参照のインデックスを維持し、自然言語クエリを LSP プロトコルリクエストに変換して結果を返します。

言語サーバーのインストール

対応言語とインストールコマンド：

# TypeScript/JavaScript
npm install -g typescript-language-server typescript

# Rust
rustup component add rust-analyzer

# Python
pip install pyright

# Go
go install golang.org/x/tools/gopls@latest

# Java
brew install jdtls  # macOS

# Ruby
gem install solargraph

# C/C++
brew install llvm   # macOS
apt install clangd  # Linux

初期化

# プロジェクトルートで実行
/code init

初期化結果例：

✓ Workspace initialization started
Detected Languages: ["python", "rust", "typescript"]

Available LSPs:
✓ rust-analyzer (rust) - initialized (488ms)
✓ typescript-language-server (typescript) - initialized (214ms)
○ gopls (go) - not installed

ステータス表示：

✓：初期化完了
◐：初期化中
○ available：インストール済み（未使用）
○ not installed：未インストール

基本的な使用例

シンボル検索：

> UserRepository クラスを見つけて
# → src/repositories/user.repository.ts:15:1 で発見

参照検索：

> Person クラスの使用箇所をすべて表示
# → 3ファイルで5箇所の参照を発見

定義ジャンプ：

> UserService の定義場所を教えて
# → src/services/user.service.ts:42:1

ファイル内シンボル一覧：

> auth.service.ts にはどんなシンボルがある？
# → AuthService クラス、login/logout/validateToken 関数

安全なリネーム：

> FetchUser メソッドを fetchUserData にリネーム（ドライラン）
# → 5ファイルで12箇所の変更が必要

診断情報：

> main.ts の診断結果を表示
# → エラー1件、警告1件を検出

カスタム言語サーバー

プロジェクトルートの lsp.json でカスタム言語を追加：

{
  "languages": {
    "mylang": {
      "name": "my-language-server",
      "command": "my-lsp-binary",
      "args": ["--stdio"],
      "file_extensions": ["mylang", "ml"],
      "project_patterns": ["mylang.config"],
      "exclude_patterns": ["**/build/**"],
      "multi_workspace": false,
      "initialization_options": { "custom": "options" }
    }
  }
}

トラブルシューティング

よくある問題と解決策：

問題	原因	解決策
初期化中エラー	LSP サーバー起動失敗	`/code init -f` で再起動
シンボルが見つからない	インデックス作成中	待機後に再試行
定義が見つからない	位置がシンボルを指していない	行・列番号を確認

ベストプラクティス

プロジェクトごとに初期化：プロジェクトルートで /code init を実行
正確な位置指定：行・列番号はシンボル名を正確に指す
リネーム前の確認：dry_run で変更内容をプレビュー
診断の活用：構文エラーが解析を妨げる場合がある
具体的な検索：「UserService」>「user」のように具体的に

制限事項

LSP サーバーによって機能サポートが異なる
大規模コードベースでは初期インデックス作成に時間がかかる
自動初期化は lsp.json 存在時のみ

参考： Code Intelligence

7. プライバシーとセキュリティ

AWS セキュリティ基盤

Kiro は AWS アプリケーションとして、AWS のセキュリティインフラストラクチャ上に構築されています。AWS の共有責任モデルに基づき、AWS がクラウドのセキュリティを、お客様がクラウド内のセキュリティを担当します。

動作モードによるセキュリティ制御

Autopilot モード（自動実行）：

Kiro が複数ステップを自動実行
ファイル作成・変更・削除を自動で実行
いつでも手動制御に切り替え可能

Supervised モード（承認制）：

各アクションで事前承認が必要
ファイル変更前にユーザー確認
完全な制御を維持

信頼できるコマンド設定

デフォルトでは全コマンドに承認が必要ですが、信頼できるコマンドを事前設定可能：

# 完全一致
npm install

# ワイルドカード
npm *          # 全npm コマンドを信頼
git status     # 特定コマンドのみ

# 全コマンド信頼（注意して使用）
*

サービス改善とオプトアウト

データ使用：

Free/Individual：サービス改善に使用される場合あり
Enterprise：サービス改善には使用されない
Amazon Q Developer Pro：サービス改善には使用されない

※オプトアウトすることも可能：Opt out of data sharing

ベストプラクティス

ワークスペース分離：

機密プロジェクトは別ワークスペースで管理
.gitignore で機密ファイルを除外
専用ユーザーアカウントまたはコンテナ環境の使用

AWS 認証情報管理：

一時的な認証情報の使用
AWS 名前付きプロファイルでアクセス分離
機密作業時は認証情報を環境から削除

リポジトリアクセス制御：

GitHub 認証時のアクセス可能リポジトリを確認
リポジトリ固有のアクセストークンを使用
定期的な権限監査

リモート拡張機能のセキュリティ

警告： リモート拡張機能はローカルマシンとリモートマシン間の接続を開きます。信頼できる安全なリモートマシンにのみ接続してください。侵害されたリモートマシンは、接続を使用してローカルマシンでコードを実行する可能性があります。

収集されるテレメトリ

使用データ：

Kiro バージョン、OS、匿名マシン ID

パフォーマンス指標：

ログイン、タブ補完、コード生成、Steering、Hooks、MCP などの機能のリクエスト数、エラー、レイテンシ

その他、Kiro CLI は強力な AWS 統合により、セキュリティとプライバシーを最優先に設計されています。
詳細については公式ドキュメントを参照してください。

参考： Privacy and Security, Data Protection

まとめ：Kiro CLI が革新的な理由

従来の AI ツールとの根本的な違い

プロジェクト固有の学習能力： Steering により、プロジェクト固有の文脈を理解
深いツール統合： MCP により、開発環境のあらゆるツールと連携
継続的な開発セッション：単発の質問ではなく、長期的な開発パートナー
企業レベルのセキュリティ：細かい権限制御と監査機能
IDE レベルのコード理解： LSP 統合による高度なコード操作

開発者の生産性向上

Kiro CLI を導入することで：

設定時間の短縮：複雑な環境構築を自然言語で指示
知識の共有：チーム全体でベストプラクティスを標準化
エラー解決の高速化：コンテキストを理解した的確な提案
コードレビューの効率化：自動的な問題検出と改善提案

今すぐ始めるには

# Kiro CLI のインストール
npm install -g @aws/kiro-cli

# 初回セットアップ
kiro-cli auth login

# 最初のチャットセッション
kiro-cli chat

Kiro CLI は単なるツールではなく、開発チームの新しいメンバーです。
あなたのプロジェクトに特化した知識を持ち、セキュリティを保ちながら、開発効率を劇的に向上させる AI パートナーとして活用してください。

最新の情報については、公式ドキュメントをご確認ください。

はじめに

1. Chat

従来のチャットツールとの違い

会話の永続化と再利用

/editor コマンドで効率的に複数行のプロンプトを入力

/reply コマンドによる返信

/prompts コマンドによる再利用可能なプロンプト管理

/context コマンドによる動的なコンテキスト管理

その他のコマンド確認

2. Custom Agents

なぜカスタムエージェントが必要なのか？

エージェント設定の基本構造

実践的なエージェント設定例

Tools フィールドの詳細設定

AllowedTools による権限制御

ToolsSettings による詳細制御

エージェントの配置と優先順位

ToolAliases

プロンプトファイルの外部化

エージェント実用例

ベストプラクティス

3. MCP

設定方法

設定ファイルの優先順位

実用的な MCP サーバー例

環境変数の活用

セキュリティ設定

現在の MCP サーバー設定を確認

4. Steering

Steering とは

主な利点

ファイルのスコープ

基本的なステアリングファイル

カスタムステアリングファイルの作成

実践例：API 規約ファイル

ファイル参照機能

AGENTS.md 標準対応

ベストプラクティス

実用的な活用例

エラーハンドリング

6. Code Intelligence：LSP 統合による高度なコード理解

Code Intelligence とは

動作原理

言語サーバーのインストール

初期化

基本的な使用例

カスタム言語サーバー

トラブルシューティング

ベストプラクティス

制限事項

7. プライバシーとセキュリティ

AWS セキュリティ基盤

動作モードによるセキュリティ制御

信頼できるコマンド設定

サービス改善とオプトアウト

ベストプラクティス

リモート拡張機能のセキュリティ

収集されるテレメトリ

まとめ：Kiro CLI が革新的な理由

従来の AI ツールとの根本的な違い

開発者の生産性向上

今すぐ始めるには

`/editor` コマンドで効率的に複数行のプロンプトを入力

`/reply` コマンドによる返信

`/prompts` コマンドによる再利用可能なプロンプト管理

`/context` コマンドによる動的なコンテキスト管理