プロローグ：War Roomの喧騒
深夜2時17分。Slackの通知音。次いで、電話が鳴る。
@channel 緊急
グローバル受注システムダウン
全拠点で影響発生中
War Room立ち上げ
5分後、Zoom会議室には数十人が集まっていた。
プライムベンダーのプロジェクトマネージャーが、緊迫した声で状況を確認している。各ベンダーの責任者が「調査中です」「確認します」「ログを取得しています」と報告する。
画面の向こうでは、誰かがキーボードを叩く音。誰かがため息をつく音。
私はミュートにしたまま、静かにターミナルを開く。
War Roomは情報共有の場だ。本当の戦いは、裏側で起きている。
干支が二周する重み
このシステムとの付き合いは、干支が二周するほど長い。
20xx年代初頭、前職の製造系企業でこの顧客のグローバル受注システム立ち上げプロジェクトに参加した。当時はまだ若手だった。先輩エンジニアたちと徹夜しながら、要件定義書を書き、コードを書き、テストを繰り返した。
それから十数年、同じシステムをサポートし続けた。機能追加、性能改善、データ移行、障害対応。システムの初期設計思想、過去の障害履歴、データ構造の癖、業務フローの複雑な分岐。すべて、頭の中に入っている。
転職した今も、縁あって同じシステムに関わっている。
でも、立場は変わった。
かつてはメーカーの正社員として、直接顧客と向き合っていた。今は、複数の下請け層を経た先にいる。契約形態は準委任契約。オンコール義務はない。責任範囲は限定的。
それでも、深夜2時に電話は鳴る。
顧客のシステム部門責任者は、私の携帯番号を知っている。War Roomで議論が紛糾すると、「あなたの意見を聞きたい」とチャットが来る。
契約上の立場と、実質的な信頼は、必ずしも一致しない。
多層ベンダー構造という迷宮
このプロジェクトの体制は、典型的な多層構造だ。
顧客（グローバル製造業系企業）
└ プライムベンダーA社（元請け）
└ 当社（二次請け）
└ 協力会社・個人事業主（三次請け）
└ プライムベンダーB社（元請け、別領域担当）
└ （以下、同様の階層構造）
オンコール体制があるのは、プライムベンダーまで。それ以降は、ベストエフォート。
障害が発生すると、情報は階層を下りてくる。でも、判断は階層を上っていかなければならない。
War Roomでの典型的な会話：
プライムA「データベースの負荷が上がっている。原因は？」
二次請け「ログを確認します。少々お待ちください」
三次請け「該当時刻のAPIリクエスト数を集計中です」
プライムB「当方の管轄では異常なし」
顧客「復旧見込みは？」
プライムA「調査中です。30分以内に再度報告します」
情報は流れている。でも、誰も答えを持っていない。
数十人が画面を見つめているのに、真実に辿り着くのは遅い。
組織が大きいほど、個人の判断が重要になる。
システムの「生き字引」という孤独
War Roomで、こんなやり取りがあった。
プライムA「20xx年に実装した〇〇機能、バッチ処理の順序を確認したい」
エンジニアB「設計書を探します」
エンジニアC「その時期の担当者、もう退職してます」
私（ミュート解除）「その機能、私が実装しました。バッチはX→Y→Zの順です。
理由は、在庫引当のロック競合を避けるため。設計書は△△にあります」
War Roomが、一瞬静まる。
「ありがとうございます」とプライムAの声。
ミュートに戻る。
システムの「生き字引」であることは、武器でもあり、呪いでもある。
武器：誰よりも速く、的確に答えられる。信頼が積み上がる。War Roomでの発言権を得られる。
呪い：深夜でも、休日でも、頼られる。「あなたにしかわからない」と言われる。責任範囲を超えて、巻き込まれる。
準委任契約だから、追加報酬はない。でも、断れない。
なぜなら、このシステムは、もう自分の一部だから。
干支が二周する間、共に生きてきた。成長も、失敗も、すべて知っている。
だから、止まらせたくない。
Kiro CLIという個人の武器
War Roomで議論が続く中、私は裏で別の作業をしている。
組織の公式ツールは、権限の壁がある。プライムベンダーの監視システムには、私はアクセスできない。顧客の内部ネットワークにも入れない。
でも、ログは共有される。CloudWatch Logs、アプリケーションログ、データベースのスロークエリログ。これらは、War Room用のS3バケットに集約される。
そして、担当領域のAWSアカウントには、アクセス権がある。
ここで、個人の武器が必要になる。
組織の制約を超えて、高速に分析し、的確に判断するためのツール。
それが、Kiro CLIだ。
実例1：War Roomの裏側での高速分析
[War Roomでの会話]
プライムA「受注APIのエラー率が急上昇している。原因を特定してください」
エンジニアD「CloudWatch Logsを確認します」
エンジニアE「該当時刻のメトリクスをダウンロード中」
私は、ミュートのまま動く。
kiro-cli chat --agent incident-response
> 共有されたCloudWatch Logsから、
> 過去3時間の受注APIエラーを分析。
> エラー率が急上昇したタイミングと、
> その直前のイベント（デプロイ、設定変更等）を関連付けて
Kiro CLIが、膨大なログを解析する。
[2分後、結果]
分析結果：
- エラー率急上昇: 22:47 (それまで0.1% → 12.3%へ)
- 該当エラー: "Database connection timeout" (特定リージョンのみ)
- 直前のイベント: 22:45 RDS接続プールの設定変更（max_connections: 100 → 50）
- 影響範囲: APAC地域の受注リクエスト
仮説:
接続プール設定の変更により、APAC地域のピークタイム（深夜日本時間 = 現地日中）に
接続数が不足。タイムアウトが多発。
3分経過。War Roomでは、まだログのダウンロードが続いている。
私は、ミュートを解除する。
私「22:47にエラー率が急上昇しています。直前の22:45、RDS接続プール設定が
変更されていませんか？max_connectionsが減っているなら、それが原因かと」
War Room、静まる。
プライムAが確認する。5秒の沈黙。
プライムA「…確認しました。該当の設定変更、ありました。即座に戻します」
10分後、エラー率が正常化。War Roomに安堵の空気が流れる。
Kiro CLIは、魔法のツールじゃない。
でも、膨大なログを人間が読める形に整理し、時系列を並べ、相関関係を見つけてくれる。
War Roomで数十人が議論している間、裏で一人、高速に分析できる。
これが、組織の隙間で生き残るための、個人の武器だ。
実例2：根本原因の仮説構築
別の障害。受注データが一部の拠点で正しく保存されない。
[War Roomでの会話]
顧客「欧州拠点からの受注データ、DBに入っていない」
プライムB「アプリケーションログでは、正常に処理されている」
エンジニアF「データベースのトランザクションログを確認中」
私は、過去の記憶を辿る。「似たような障害、以前もあった気がする」
kiro-cli chat --agent incident-response
> プロジェクトの過去の障害履歴（.kiro/runbooks/内）を検索。
> 「受注データが保存されない」「特定拠点のみ」というキーワードで。
> 類似の過去事例があれば、その原因と対処法を教えて
Kiro CLIが、過去のRunbookを検索する。
[結果]
類似事例: 20xx年x月、南米拠点で同様の事象
原因: タイムゾーン変換処理のバグ（サマータイム切り替え時期）
対処: アプリケーション層のタイムゾーン処理を修正
現在の状況との類似点:
- 欧州拠点（サマータイム実施地域）
- 発生時刻: 現地時間でサマータイム切り替え直後
私は、仮説を立てる。
私「過去に似た事例があります。サマータイム切り替えのタイミングで、
タイムゾーン変換処理が誤作動している可能性。欧州の該当日時を確認すべきです」
プライムBが確認。
プライムB「…確かに、今日がサマータイム切り替え日です。該当処理を確認します」
30分後、原因特定。修正パッチ適用。
干支が二周する記憶は、私の頭の中にある。
でも、すべてを完璧に覚えているわけじゃない。
Kiro CLIは、その記憶を補完してくれる。過去のRunbook、設計書、障害報告書。これらを瞬時に検索し、関連する情報を提示してくれる。
個人の経験 × AI の検索力 = War Roomでの発言力
準委任契約という現実
War Roomが解散する。朝6時。約4時間の戦いだった。
プライムA「お疲れ様でした。復旧しました」
顧客「ありがとうございました。報告書は後ほど」
Zoomが終わる。静寂が戻る。
私は、タイムシートを開く。
「障害対応: 4時間」
準委任契約だから、作業時間分の報酬は出る。でも、深夜割増はない。オンコール手当もない。
それでも、やる。
なぜなら、このシステムは止められないから。
グローバルで、24時間365日、どこかの国で取引が動いている。製造業のサプライチェーンを支えている。このシステムが止まれば、工場のラインが止まる。物流が混乱する。
日商数億円規模。1分のダウンタイムが、数十万円の損失。
その重みを、誰よりも理解している。
干支が二周する間、ずっとこのシステムと共にいたから。
これが、多層ベンダー構造で生き残る、ベテランエンジニアの現実だ。
契約上の責任範囲は限定的。でも、実質的な期待は大きい。
組織の武器（公式ツール、権限、サポート体制）は限られている。
だから、個人が武装する。
Kiro CLIは、その武器の一つだ。
事前準備：障害対応専用カスタムエージェント
ここまで読んで、疑問を持った人もいるだろう。
「War Roomの真っ最中に、Kiro CLIを使いこなせるのか？」
答えは、平時の準備にある。
カスタムエージェントの設定
Kiro CLIの強力な機能の一つが、「カスタムエージェント」だ。
障害対応に特化したエージェント設定例：
{
"name": "incident-response",
"description": "グローバル製造業系受注システムの障害対応専用エージェント",
"prompt": "あなたは、干支二周にわたりこのシステムを見てきたベテランSREです。War Room参加中のエンジニアをサポートします。冷静に、段階的に、リスクを明示しながら分析してください。過去の類似事例を参照し、根本原因の仮説を複数提示してください。",
"tools": [
"execute_bash",
"fs_read"
],
"toolsSettings": {
"execute_bash": {
"allowCommands": [
"aws logs filter-log-events*",
"aws logs describe-*",
"aws rds describe-*",
"aws lambda list-*",
"aws cloudwatch get-metric-statistics*"
]
},
"fs_read": {
"allowedPaths": [
"services/**",
"infrastructure/**",
".kiro/runbooks/**",
".kiro/past-incidents/**"
]
}
},
"resources": [
"file://.kiro/steering/incident-response-principles.md",
"file://.kiro/runbooks/db-connection-issues.md",
"file://.kiro/runbooks/api-timeout-investigation.md",
"file://.kiro/past-incidents/20xx-timezone-bug.md"
]
}
このエージェントは：
-
過去の障害履歴を学習している（
.kiro/past-incidents/） - 対処手順書（Runbook） を自動参照する
- システム構成（services, infrastructure）を理解している
- ベテランSREのトーンで、リスクを明示しながら提案する
Runbookの整備
干支が二周する間の障害対応経験を、すべてMarkdown化している。
.kiro/
├── runbooks/
│ ├── db-connection-issues.md
│ ├── api-timeout-investigation.md
│ ├── data-replication-failure.md
│ └── timezone-conversion-bugs.md
└── past-incidents/
├── 20xx-01-サマータイム障害.md
├── 20xx-05-RDS接続プール枯渇.md
└── 20xx-12-グローバルDNS障害.md
これらは、私の「外部記憶」だ。
Kiro CLIは、これを瞬時に検索し、関連する過去事例を提示してくれる。
平時の訓練
開発環境で、定期的にKiro CLIを使っている。
- ログ解析の練習
- 根本原因分析のシミュレーション
- 質問の仕方による結果の違いを学習
War Roomで初めて使うツールは、凶器になる。
平時の訓練が、緊急時の冷静さを生む。
Kiro CLIの真価：組織の制約を超える
War Roomには、数十人が参加する。
でも、全員が同じ武器を持っているわけじゃない。
- プライムベンダー：顧客環境への直接アクセス、高度な監視ツール、豊富な人員
- 二次請け（当社）：限定的なアクセス権、小規模チーム
- 三次請け：さらに限定的、個人事業主も含む
組織の武器は、権限に縛られる。
でも、個人の武器は、持ち主の能力に依存する。
Kiro CLIは：
- ログさえあれば、分析できる
- コードさえあれば、根本原因を探れる
- 過去の記録さえあれば、類似事例を見つけられる
組織の階層構造を超えて、個人が戦える。
準委任契約のベテランエンジニアが、War Roomで発言力を持つ理由。
それは、経験 × 準備 × 個人の武器だ。
音楽との向き合い方
War Roomの4時間、音楽は流さなかった。
Zoomの画面を見つめ、ターミナルと向き合い、ミュートとミュート解除を繰り返す。
集中するために、外部の音は遮断する。
でも、戦いが終わった後は違う。
朝6時、War Roomが解散した。
部屋に一人残る。窓の外が、少しずつ明るくなっている。
その時、ふとKiroroの「長い間」を流した。
♪ 長い間 待ってた
長い間 信じてた
あなたに会える日を
干支が二周する間、このシステムと共にいた。
長い戦いだった。まだ、終わらない。
でも、今夜も乗り越えた。
音楽は、戦闘中のBGMじゃない。戦後の、静かな癒しだ。
そして、「Kiro CLI」という名前が、「Kiroro」に似ているだけで、どこか親しみを感じる。
AIツールなのに、温かい。
独りじゃない。
そんな気持ちにさせてくれる、言葉遊び以上の何かがある。
エピローグ：次の障害へ
グローバル製造業系のシステムは、止まらない。
24時間365日、どこかの国で受注が動いている。
次の障害は、必ず来る。それがいつかはわからない。
その時、War Roomに数十人が集まる。
プライムベンダーが指揮を取り、各社が「調査中です」と報告し、顧客が「復旧見込みは？」と問う。
その裏側で、私は静かにターミナルを開く。
Kiro CLIと共に、ログを解析し、仮説を立て、的確なタイミングで発言する。
干支が二周した。でも、まだ終わらない。
このシステムが動き続ける限り、私も戦い続ける。
準委任契約のベテランエンジニアとして。
組織の隙間で、個人の武器を持って。
Kiroro × Kiro CLI
言葉遊び以上の、温かい何かを胸に。
参考情報・実践ガイド
Kiro CLIのセットアップ
詳細な手順は省略するが、重要なポイントだけ記載する。
インストール
curl -fsSL https://cli.kiro.dev/install | bash
macOSとLinuxで利用可能。Windows（WSL経由）でも動作する。
認証方式の選択
企業利用なら、AWS IAM Identity Centerを推奨。
- 管理者がアクセス権を一元管理
- サブスクリプション層の割り当て
- 利用状況と支出の追跡
個人利用なら、GitHubやGoogle認証で十分。
カスタムエージェントの作成
.kiro/agents/incident-response.jsonを作成し、あなたの環境に合わせて調整する。
重要なのは：
- 過去の障害履歴をRunbook化する
- システムの設計思想をドキュメント化する
- 平時に繰り返し訓練する
Kiro IDEとの統合
すでにKiro IDEを使っているなら、設定は共有される。
- MCP サーバー設定（
.kiro/settings/mcp.json） - ステアリングルール（
.kiro/steering/*.md） - カスタムエージェント（
.kiro/agents/*.json）
IDE で構築した環境が、そのままCLIでも使える。
コスト管理
Kiro CLIは、使用量に応じてクレジットを消費する。
War Room中は、コストより復旧速度を優先すべきだが、平時の訓練では使用量を意識したい。
Autoエージェントを活用すれば、タスクに応じて最適なモデルを自動選択し、効率的にクレジットを使用できる。
守秘義務への配慮
この記事で紹介した事例は、すべて抽象化・匿名化している。
実際にRunbookを作成する際も：
- 顧客名、プロジェクト名は伏せる
- 具体的なデータ、金額、件数は概数化する
- 設計思想や対処パターンのみを記録する
Kiro CLIはローカルで動作するため、機密情報が外部に送信される心配は少ないが、念のため社内規定を確認すること。
コミュニティ
Kiro Discord コミュニティでは、他のエンジニアとの情報交換、エージェント設定の共有、フィードバックの提供ができる。
最後に：準委任契約のエンジニアへ
この記事を読んでいるあなたは、もしかしたら似た境遇かもしれない。
多層ベンダー構造の中で、準委任契約で働いている。
オンコール義務はない。でも、電話は鳴る。
責任範囲は限定的。でも、期待される。
組織の武器は限られている。でも、戦わなければならない。
ならば、個人が武装しよう。
経験を積み、知識を深め、ツールを使いこなす。
Kiro CLIは、その選択肢の一つだ。
魔法のツールじゃない。でも、War Roomの裏側で、静かに戦うための、確かな武器になる。
そして、戦いが終わったら。
朝日が昇る頃、Kiroroの曲を流そう。
「未来へ」 でもいい。 「長い間」 でもいい。
干支が二周しても、まだ終わらない戦いを、静かに噛みしめるために。
あなたは、独りじゃない。
この記事は、実際の障害対応経験をもとにしていますが、守秘義務に配慮し、企業名・プロジェクト名・具体的な数値等は抽象化・匿名化しています。