Amazon Web Services ブログ

繰り返すのをやめよう：あなたが見逃していた AI コンテキストレイヤー、グローバルステアリングとは

本記事は米国時間 2025 年 11 月 4 日に公開された「 Stop Repeating Yourself: Why Global Steering is the AI Context Layer You’ve Been Missing」を翻訳したものです。

あなたは、関数型の React コンポーネントを使った欲しいことを AI アシスタントに 47 回も伝えました。セミコロン付きの Prettier を使っていることを 23 回。そして、テストファイルは__tests__ディレクトリに配置し、ソースコードと並べないことを少なくとも 15 回。
聞き覚えがありませんか？

ここで実際にかかっているコストについて考えてみましょう。これは単にイライラするだけではなく、生産性を下げています。新しいプロジェクトをセットアップするたびに、すでに何十回も説明してきたプロンプトを再び説明するのに 10 〜 15 分を費やしています。年間 20 のプロジェクトに取り組む開発者にとって、それは 5 時間以上の単純な繰り返しです。50 人のチーム全体では？ワークスペース間で同じ基準をコピー＆ペーストするのに年間 250 時間を費やしていることになります。

そして、さらに状況は悪化します。コンテキストが一貫性がないと、コードも一貫しません。あるプロジェクトではセキュリティ基準が適用されます。別のプロジェクトでは、そのファイルをペーストし忘れたためにセキュリティ基準が欠落しています。テストカバレッジは大きく変動します。コードスタイルもずれていきます。不整合は技術的負債として蓄積されます。

AI を使ってコーディングしているなら（正直、2025 年に誰もがしているでしょうが）、この壁にぶつかっているはずです。すべての新しいプロジェクトがゼロからスタートします。AI はあなたの好み、チームの規約、会社の基準を覚えていません。あらゆるワークスペースに同じ指示をコピー＆ペーストするか、さらに悪いことに、毎回手動で入力し直すしかありません。

これが Kiro グローバルステアリングが解決する問題です。

Kiro グローバルステアリングは、AI コンテキストのための個人用の.bashrcのようなもので、どこにいても付いてくる、必要なときに準備ができている設定だと考えてください。好みを一度書けば、それがあなたが触れるすべてのプロジェクトの基盤になります。コピーも、忘れることも、不整合もありません。

影響は？開発者は毎月数時間を節約できます。チームは自動的に一貫性を達成します。組織は規模に応じて基準を適用します。そして最も重要なことは、AI アシスタントが毎回、初日からあなたを理解するようになることです。

そもそもステアリングとは何か？

グローバルステアリングに入る前に、ステアリングが実際に何をするのかを明確にしましょう。

ステアリングは永続的な AI コンテキストです。これは、AI エージェントが作業を開始する前に、あなたの好み、基準、決定事項について伝える一連のMarkdown ファイルです。すべての会話で同じことを説明する代わりに、ステアリングファイルに一度書けば、AI は作業を開始するリクエストを受けたときに自動的にそれを読み込みます。

現状：ワークスペースステアリング

現在、Kiro はワークスペース固有のステアリングを使用しており、以下の場所に保存されています。

<project>/.kiro/steering/

このアプローチは、プロジェクトごとに設定を指定する必要がある場合にうまく機能します。

しかし、問題があります。AI に伝えることのほとんどは、プロジェクト固有ではありません。

あなたのコーディングスタイルの好みは、すべてのプロジェクトで同じです。テストの哲学はどこでも一貫しているべきです。普遍的なセキュリティ基準が必要です。なぜそれをすべてのワークスペースで繰り返す必要があるのでしょうか？

グローバルステアリングの登場：個人用 AI 設定レイヤー

グローバルステアリングはあなたのホームディレクトリに存在します。

~/.kiro/steering/

このステアリングファイルは永続的です。普遍的です。どこにでも付いてきます。

ここに置いた Markdown ファイルは、ワークスペースレベルで明示的に上書きされない限り、すべてのプロジェクトで Kiro が利用できるようになります。

グローバルステアリングに何を入れるべきか？

プロジェクトに関係なく、あなたの仕事全体で一貫しているものについて考えてください

個人的なコーディングスタイル ~/.kiro/style.md（グローバル）

# style.md

## コード整形

- 常にセミコロン付きの Prettier を使用
- JS/TSは2スペースインデント、Python は 4 スペース
- 複数行の配列/オブジェクトには末尾のカンマ

## React の好み

- 関数コンポーネントのみ（クラスコンポーネントは使わない）
- 再利用可能なロジックにはカスタムフック
- コンポーネント上部で props を分割代入

## 命名規則

- 関数と変数は camelCase
- コンポーネントとクラスは PascalCase
- 定数は SCREAMING_SNAKE_CASE
- 簡潔さよりも説明的な名前

テストのルール ~/.kiro/testing.md（グローバル）

# testing.md

## テスト基準

- ビジネスロジックには最低80%のカバレッジ
- テストファイルは`__tests__/`ディレクトリに配置
- Jest + React Testing Library を使用
- 外部依存関係はモック化
- クリティカルパスには統合テスト

## テスト構造

- Arrange-Act-Assert パターン
- 説明的なテスト名（it should...）
- 可能な限り 1 テストにつき 1 つのアサーション

セキュリティ要件 ~/.kiro/security.md（グローバル）

# security.md

## セキュリティの基本

- 秘密情報は絶対にコミットしない（環境変数を使用）
- すべてのユーザー入力を検証
- SQL/HTML レンダリング前にデータをサニタイズ
- パラメータ化されたクエリを使用、文字列連結は禁止
- API にレート制限を実装
- HTTPS のみ、混合コンテンツは禁止

ドキュメンテーション基準 ~/.kiro/docs.md（グローバル）

# docs.md

## コードドキュメンテーション

- すべての公開関数に JSDoc
- 複雑なロジックのみインラインコメント
- セットアップ手順を含む README をすべてのプロジェクトに
- OpenAPI/Swagger を使用した APIドキュメンテーション
- "Keep a Changelog" のサイトに従った変更履歴

アーキテクチャ原則 ~/.kiro/architecture.md（グローバル）

# architecture.md

## 設計原則

- 関心の分離
- DRYだが明確さを犠牲にしない
- 継承よりコンポジション
- 説明的なエラーで早期に失敗
- 単一責任の原則

## コード構成

- 機能ベースのフォルダ構造
- 関連ファイルの近接配置
- クリーンなインポートのためのバレルエクスポート

このパターンは、何を構築するかではなく、どのように作業するかを定義します。

実世界のシナリオ：個人開発者

実際にこれがどのように機能するか見てみましょう。

Jane Doe さんの場合

Jane は、React とNode を使った顧客プロジェクト、オープンソースへの貢献、個人的なサイドプロジェクトに取り組んでいるフリーランスのフルスタック開発者です。すべてのプロジェクトで異なるビジネスロジックがありますが、彼女の基準は同じままです。

Janeのグローバルステアリング設定

Jane の~/.kiro/steering/フォルダ

~/.kiro/steering/
├── style.md              # コーディングスタイルの好み
├── testing.md            # テストアプローチ
├── security.md           # セキュリティベースライン
├── docs.md               # ドキュメンテーション基準
├── git.md                # コミットメッセージ形式
└── accessibility.md      # アクセシビリティ要件

主要なファイル：

~/.kiro/git.md（グローバル）

# Git 規約

## コミットメッセージ

Conventional Commits に従う：

- feat: 新機能
- fix: バグ修正
- docs: ドキュメント変更
- refactor: コード再構築
- test: テストの追加/変更

形式：`type(scope): description`

例：`feat(auth): OAuth2サポートを追加`

## ブランチ戦略

- `main` - 本番環境対応
- `develop` - 統合ブランチ
- `feature/xxx` - 新機能
- `fix/xxx` - バグ修正

~/.kiro/accessibility.md（グローバル）

# アクセシビリティ基準

## 要件

- 最低限 WCAG 2.1 AA コンプライアンス
- セマンティックな HTML要素
- 適切な見出し階層（h1 → h2 → h3）
- すべての画像に alt 属性
- キーボードナビゲーションのサポート
- フォーカスインジケーターを可視化
- 最低 4.5:1 のカラーコントラスト比

## テスト

- キーボードのみでテスト
- スクリーンリーダーを使用（NVDA/JAWS）
- コミット前に axe DevTools を実行

ワークスペース固有のステアリング

さて、Jane は新しいクライアントプロジェクトであるEコマースプラットフォームを開発を開始します。彼女のプロジェクト固有のステアリングファイルは/.kiro/steering/に配置されます。

<project>/.kiro/steering/
├── product.md       # E コマースのビジネス要件
├── tech.md          # Next.js、Stripe、PostgreSQL の選択
└── structure.md     # このプロジェクトのフォルダレイアウト

<project>/.kiro/product.md（ワークスペース）

# Eコマースプラットフォーム

## コア機能

- 検索機能付き商品カタログ
- 永続化されたショッピングカート
- Stripe 決済統合
- 注文履歴と追跡
- メール通知

## ユーザーロール

- ゲスト：閲覧と購入
- 顧客：保存されたアドレス、注文履歴
- 管理者：商品管理、注文処理

<project>/.kiro/tech.md（ワークスペース）

# 技術スタック

## フロントエンド

- Next.js 14（App Router）
- TypeScript
- Tailwind CSS
- 状態管理にZustand

## バックエンド

- Next.js API ルート
- Prisma 経由の PostgreSQL
- 決済に Stripe
- メールに SendGrid

## インフラストラクチャ

- Vercel にデプロイ
- データベースに Supabase
- 画像に Amazon S3

どのように連携するか

Jane が「新しい ProductCard コンポーネントを作成して」と Kiro に依頼すると以下のものを読み込みます。

Kiro が読み込むもの：

  1. グローバルステアリング（~/.kiro/steering/）
    • style.md → 関数コンポーネント、Prettier 設定
    • accessibility.md → セマンティック HTML、alt 属性要件
    • testing.md → テストファイルの配置とカバレッジ
  2. ワークスペースステアリング（/.kiro/steering/）
    • tech.md → Next.js、TypeScript、Tailwind を使用
    • product.md → 商品データ構造と機能
    • structure.md → コンポーネントはsrc/components/に配置

結果として、Kiro は、TypeScript を使用した Tailwind CSS クラスの関数型 React コンポーネント、適切なセマンティック HTML とアクセシビリティ属性、対応するテストファイルと共に正しいディレクトリに配置、Jane のコーディングスタイルに一致、すべてを自動的に生成します。

Jane が好みを設定を繰り返し指示することなく、すべてが実行されます。

チームシナリオ：組織全体の基準

では、これをスケールアップしましょう。50 人の開発者がいるチームではどうなるでしょうか？

AnyCompany の場合

AnyCompany には、8 つの開発チームがあり、混合技術スタック（React、Vue、Python、Go）にわたる 30 以上のアクティブなリポジトリを管理し、厳格なセキュリティとコンプライアンス要件を持っています。

課題：すべての開発者が会社の基準に従う必要がありますが、異なる技術を使用した異なるプロジェクトに取り組んでいます。

AnyCompany のグローバルステアリング戦略

展開アプローチ

組織は、グローバルステアリングファイルをチームに配布する方法の柔軟性を持っています。重要な制約は、Kiro が ~/.kiro/steering/ ディレクトリからのみグローバルステアリングファイルを読み取ることですが、ファイル自体はコピーまたはシンボリックリンクを通じてどこからでも取得できます。

バージョン管理を使用するチームの場合、AnyCompany は、セキュリティポリシー、SOC2 および GDPR コンプライアンス要件、コードレビュー基準、オンコール手順、アクセシビリティ要件、UI/UX ブランドガイドラインを含む会社全体のステアリングファイルを含む共有リポジトリを維持しています。開発者はオンボーディング中にこのリポジトリをクローンし、ファイルを~/.kiro/steering/に直接コピーするか、中央リポジトリが変更されたときに自動的に反映されるシンボリックリンクを作成します。シンプルなセットアップスクリプトがこのプロセスを自動化し、手動コピーなしですべての開発者が同じベースラインを取得できるようにします。

setup-kiro.sh


#!/bin/bash
# setup-kiro.sh

echo "AnyCompany Kiro グローバルステアリングをセットアップしています..."

# 会社のステアリングをクローン
git clone <チームのグローバルステアリングファイルのURLをここに> ~/.kiro/company-steering

# グローバルステアリングへシンボリックリンク（更新が自動同期）
ln -s ~/.kiro/company-steering/* ~/.kiro/steering/

echo "グローバルステアリングが設定されました！"

Jamf や Intune などのモバイルデバイス管理ツールを使用する企業の場合、展開は完全に自動化できます。MDM スクリプトは、内部サーバーからファイルをダウンロードし、適切な権限を設定し、必要なファイルが存在し続けることを強制することで、~/.kiro/steering/ に直接入力できます。または、MDM は/opt/company/kiro-steering/のような中央の場所にファイルを展開し、~/.kiro/steering/ へのシンボリックリンクを作成できます。これにより、ファイルを管理された場所に保ちながら、集中更新が提供されます。このアプローチは、開発者の手動セットアップが不要になり、集中ポリシー管理、ポリシーが変更されたときの自動更新、コンプライアンスのための監査証跡を提供します。

#!/bin/bash
# MDM 経由で AnyCompany Kiro グローバルステアリングを展開

USER_HOME="/Users/$USER"
STEERING_DIR="$USER_HOME/.kiro/steering"
COMPANY_NAME="会社名をここに"

mkdir -p "$STEERING_DIR"

# 内部サーバーから会社のステアリングファイルをダウンロード
curl -o "$STEERING_DIR/security.md" "https://internal.$COMPANY_NAME.com/kiro/security.md"
curl -o "$STEERING_DIR/compliance.md" "https://internal.$COMPANY_NAME.com/kiro/compliance.md"
curl -o "$STEERING_DIR/code-review.md" "https://internal.$COMPANY_NAME.com/kiro/code-review.md"

chown -R $USER "$STEERING_DIR"
chmod 755 "$STEERING_DIR"

echo "AnyCompany Kiro グローバルステアリングが正常に展開されました"

実際のチーム例：フロントエンドチーム

AnyCompany のフロントエンドチームは独自のレイヤーを追加します。

チーム共有ステアリングリポジトリ（フロントエンド）

frontend-steering/
├── react-patterns.md    # チームの React 規約
├── component-api.md     # Props パターン
├── state-management.md  # Zustand と Context をいつ使うか
└── performance.md       # バンドルサイズ、遅延ロードルール

個人開発者：John Doe

John は AnyCompany のフロントエンド開発者です。

John の完全なステアリング設定：

# チーム固有および会社全体（グローバルステアリング内）
~/.kiro/steering/
├── security.md          # ✅ 会社のセキュリティ（中央の場所からシンボリックリンク）
├── compliance.md        # ✅ SOC2/GDPR（中央の場所からシンボリックリンク）
├── code-review.md       # ✅ PR の基準（中央の場所からシンボリックリンク）
├── react-patterns.md    # ✅ フロントエンドチームの React 規約
├── component-api.md     # ✅ チームの Props パターン
├── style.md             # ✅ John の個人的なスタイルの好み
└── shortcuts.md         # ✅ John のカスタムスニペット

# プロジェクト固有（現在のワークスペース）
<project>/.kiro/steering/
├── product.md           # ✅ この製品の要件
├── tech.md              # ✅ このプロジェクトのスタック
└── structure.md         # ✅ このコードベースのレイアウト

John が何かを構築するよう Kiro に依頼すると、Kiro はワークスペースステアリングがグローバルステアリングに優先して、ファイルを読み取ります。ワークスペースステアリングはプロジェクト固有で、競合が存在する場合に優先されます。グローバルステアリングには、John の個人的な好み、チーム規約、会社基準が含まれ、ワークスペースの上書きが存在しない場合に使用されます。結果として、John は会社のセキュリティコンプライアンスが自動的に適用され、プロジェクト全体で共有されるフロントエンドチームの基準、彼の個人的なワークフローの好み、現在のワークスペースからのプロジェクト固有のコンテキストを取得します。これらのレイヤーはすべてシームレスに連携します。

シナリオ：複数言語を利用する開発者

別のシナリオは、複数の技術スタックで作業する場合です。React とTypeScript を使用したフロントエンド開発、Python と FastAPI を使用したバックエンドサービス、React Native で構築されたモバイルアプリケーション、Terraform を通じて管理されるインフラストラクチャ。これらのエコシステム全体で共通の問題は、それぞれが異なる規約を持っているため、コードベース全体で一貫性のない実践に陥りやすいことです。

以下に示すソリューションは、言語に適した実装で、さまざまなコーディング言語にわたって基準を指定する方法を示しています。これで、テスト基準は一貫していますが、実装は言語に応じて適切に変化します。

グローバルステアリングのソリューション：

# テスト基準（すべての言語）

## カバレッジ

- ビジネスロジックには最低80%
- 決済/セキュリティコードには100%

## テスト構造

- Arrange-Act-Assertパターン
- 説明的な名前
- テストごとに1つのアサーション

## 言語固有

### TypeScript/JavaScript

- Jest + Testing Library
- `__tests__/`ディレクトリにテスト

### Python

- pytest
- `tests/`ディレクトリにテスト
- セットアップに fixture を使用

### Go

- 標準の`testing`パッケージ
- テーブル駆動テスト
- `_test.go`サフィックス

~/.kiro/naming.md（グローバル）

# 命名規則（すべての言語）

## 普遍的なルール

- 巧妙さよりも説明的
- 完全な単語、略語は使わない（標準的なものを除く）
- ブール変数：`is`、`has`、`should` 接頭辞
- 配列/リスト：複数形の名詞
- ブール名に否定形を避ける

## 言語固有

### TypeScript/JavaScript

- 変数/関数は camelCase
- クラス/コンポーネントは PascalCase
- 定数は SCREAMING_SNAKE

### Python

- 変数/関数は snake_case
- クラスは PascalCase
- 定数は SCREAMING_SNAKE

### Go

- エクスポートされる名前は PascalCase
- エクスポートされない名前は camelCase

一般的なステアリングのガイドライン

ステアリングに入れてはいけないもの

API キーや秘密情報、データベース認証情報、内部 URL やエンドポイント、顧客データや PII 、独自のアルゴリズム（ステアリングファイルを共有する予定がある場合）を含めてはいけません。これは、グローバルステアリングファイルは平文の Markdown であり、多くの場合共有または同期され、デフォルトでは暗号化されていないためです。

含めても安全なもの

一般的なセキュリティプラクティス、コードパターンと好み、テストアプローチ、ドキュメンテーション基準、公開 API 設計原則、フレームワークとライブラリの選択をステアリングファイルに含めることは安全です。

始めよう：最初のグローバルステアリングファイル

グローバルステアリングを試して実際に動作を見る準備はできましたか？以下は、実際に確認できる簡単な例です。

ステップ1：最初のファイルを作成する

最も頻繁に繰り返すことを選びます。ほとんどの開発者にとって、それはコーディングスタイルです：

nano ~/.kiro/steering/style.md

ステップ2：テストする

Kiro で新しいプロジェクトを開いて、「新しいコンポーネントを作成して」と依頼します。Kiro は、あなたが言及しなくても、~/.kiro/steering/style.mdからのスタイルの好みに従うはずです。

ステップ3：徐々に拡張する

繰り返しのパターンを発見したら、より多くのファイルを追加し、有機的に構築します。

# 来週、テスト基準を追加
nano ~/.kiro/steering/testing.md

# その次の週、セキュリティベースラインを追加
nano ~/.kiro/steering/security.md

まとめ

これで、Kiro があなたの全体的なスタイルと好みを理解するためにグローバルステアリングを使用して、より効率的に作業する方法ができました。唯一残された課題は、何時間もの時間と繰り返しの指示を節約するために、Kiro プロジェクトに適用し始めるグローバルステアリングファイルに何を書くかです。今日、最初のグローバルステアリングファイルを作成しましょう。二度と同じことを繰り返さない体験をしてみてください。

グローバルステアリングに何を入れますか？ハッシュタグ #codewithkiro でセットアップを共有するか、X、LinkedIn、または Instagramで @kirodotdev をタグ付けし、Blueskyで @kiro.dev をタグ付けしてください。