このハンズオンは調査タスクを実行する過程でKiroを使い、調査タスクのシナリオにそって設定しながらKiroの機能を学ぶことができるハンズオンです。
Kiroについては下記を参照してください。
前提条件
- Kiro IDEがインストール済み(ダウンロード)
- インターネット接続
- MCPを使う場合はnodeの実行環境が必要
完成済みのリポジトリはこちら
シナリオ
「動画配信サービス、結局どれがいいんだろう?」——Netflix、Amazon Prime Video、Disney+……選択肢が多すぎて比較が面倒。各社の公式サイトを巡回し、料金プランを確認し、コンテンツの特徴を整理し、出典をチェックし、本文を修正し……。気づけば数時間が過ぎている。
この記事では、AWS発のAI開発環境「Kiro IDE」を使って、こうした「調べもの → 整理 → ファクトチェック → 本文修正 → 比較レポート作成」の一連の作業を完全に自動化するハンズオンを紹介します。Kiroの5つの主要機能を段階的に学び、最終的に「4つのHookを順番に押すだけで、本文修正まで含めた比較レポートが完成する」仕組みを構築します。
調査対象:
- Netflix
- Amazon Prime Video
- Disney+
- U-NEXT
- Apple TV+
全体構成
| 章 | テーマ | やること |
|---|---|---|
| 第1章 | Steering | プロジェクトのルールと判断基準をKiroに教える |
| 第2章 | Skills | 調査・分析・指摘・再調査・修正・監査・統合の「手順」を実行するスキルを作る |
| 第3章 | サブエージェント | 5サービスを5体のAIに同時に調べさせる |
| 第4章 | Hooks | Skillsとサブエージェントを呼び出すタイミングを設定して自動化する |
| 第5章 | MCP | Tavily MCPを繋いでWeb検索を強化する(オプション) |
| 第6章 | 統合演習 | 全部組み合わせて4つのボタンで完全自動化されたレポートを生成 |
作成する全体像
このハンズオンで作るもの: Hooks 4個、サブエージェント 1個、Skill 7個(必須6 + オプション1)、Steering 5ファイル。全部で17個のコンポーネントとなります。
フォルダ構成
kiro-research-journey/
├── data/ ← 参照用の元データ(調査対象リストなど)
├── reports/ ← 調査の成果物(各社の調査メモ、分析結果)
│ └── _review/ ← レビュー・判断ログ専用フォルダ
└── output/ ← 最終レポート
設計の柱
本ハンズオンを貫く3つの原則:
- ルールは Steering に集約 — フォーマット・出典規約・判断基準をSteeringで管理し、Skillは「手順」だけに専念
-
本文修正権限は単一のSkillだけ —
apply-decisionsSkill のみが本文を書き換える。これにより「誰が・いつ・なぜ修正したか」が一意に追跡可能 - 判断ログ駆動モデル — 各指摘について「修正/保持/保留」の判断と根拠を判断ログに記録し、本文修正は判断ログを実行に移すだけ
これにより、本文修正の自動化とハルシネーション混入対策を両立させます。
注意
ハルシネーションがまったくないと保証するものではありません。あくまでも実行は自己責任で
第1章: Steering — プロジェクトのルールと判断基準をKiroに教える
Steeringとは?
Steeringは、Kiroにプロジェクトの知識を永続的に与えるMarkdownファイルです(公式ドキュメント)。毎回チャットで同じ指示を繰り返す代わりに、ルールをファイルに書いておけば、Kiroが一貫してそのパターンに従います。
Steeringなし: 毎回プロンプトでルールを指定 → 出力がバラバラ
Steeringあり: ルールが自動適用 → 常に同じ品質のアウトプット
4つの読み込みモード
Steeringには場面に応じた読み込みモードがあります:
| モード | いつ読み込まれるか | 使いどころ |
|---|---|---|
always |
常に | 基本ルール(言語、フォーマット) |
fileMatch |
特定のファイルにマッチした時 | ファイル種別ごとのルール |
manual |
チャットで #ファイル名 と入力したとき |
たまにしか使わないガイド |
auto |
リクエスト内容に応じて自動判定 | 条件付きで追加適用するルール |
演習 1-1: 調査レポートのルールを定義する
.kiro/steering/report-rules.md を作成し、下記をコピペします。
---
inclusion: always
---
# 調査レポートのルール
## 基本ルール
- 出力はすべて日本語で行う
- 情報には必ず出典(URLまたは情報源の名称)を記載する
- 数値データには取得時期を明記する(例: 2025年Q1時点)
- 推測や意見は「※推測」と明示し、事実と区別する
## レポートのフォーマット
- 見出しは「##」で統一する
- 要点は箇条書きで簡潔にまとめる
- 各セクションの冒頭に3行以内のサマリーを入れる
## ファイル保存のルール
- 調査の成果物は `reports/` フォルダに保存する
- ファイル名は `{カテゴリ}-{対象名}.md` 形式にする
- 参照用の元データは `data/` フォルダに保存する
- 統合レポートは `output/` フォルダに保存する
## `reports/_review/` フォルダの扱い
`reports/_review/` は**レビュー・判断ログ専用フォルダ**として扱う。
### 配置されるファイル
- `checklist-{YYYY-MM-DD}.md` — source-check Skill が生成する指摘リスト
- `decision-log-{YYYY-MM-DD}.md` — re-investigate-and-judge Skill が生成する判断ログ
### 命名規則
- 必ず `{種類}-{YYYY-MM-DD}.md` 形式
- 1日に複数回実行する場合は `{種類}-{YYYY-MM-DD}-{HHMM}.md` 形式
### 重要な扱い
- **調査レポートの読み込み対象外**: 「reports/ のレポートを読み込む」「reports/ を統合する」「reports/ をレビューする」といった指示において、`_review/` 配下のファイルは**必ず除外**する
- **統合レポートに含めない**: 統合レポート生成時、`_review/` 配下のファイル内容は最終成果物に反映しない
- **本文修正の対象外**: 本文修正の対象は `reports/*.md` であり、`reports/_review/*.md` ではない
- **判断ログは累積管理**: 過去の判断ログは削除せず、日付ごとに残す。Gitでの履歴追跡を前提とする
作成したら左のサイドバーのKiroのアイコンをクリックしてください。
AGENT STEERING & SKILLS のウインドウに追加されていることを確認します。
これにて設定は完了です。それでは動作確認してみましょう。
確認方法: チャットで「NetflixとDisney+の違いを簡単にまとめて」と入力。出典つき・日本語・箇条書きで回答が返ればOK。
NetflixとDisney+の違いを簡単にまとめて
右上のNew Sessionをクリックすると新しいチャットウインドウが表示されます。
report-rules.mdが読み込まれ、標準のWeb Toolを使用してWEB検索が実行されます。
出典・取得時期つきでまとめてくれました。
演習 1-2: auto Steeringでレビューガイドラインを作る
レビューやフィードバックを依頼されたときに追加適用されるルールを作ります。
.kiro/steering/review-guidelines.md を作成し、下記をコピペします。
---
inclusion: auto
name: review-guidelines
description: レビューやフィードバックのガイドライン。レビュー、評価、フィードバック、チェックを行うときに使用。
---
# レビュー・フィードバックのガイドライン
## レビュー時のルール
- 良い点を先に述べてから改善点を指摘する(サンドイッチ法)
- 改善点には具体的な代替案を提示する
- 主観的な意見は「※個人的見解」と明示する
- 重要度を3段階で示す: 🔴 必須 / 🟡 推奨 / 🟢 任意
確認方法: チャットで「レビューや評価をするときのガイドラインを教えて」と入力。auto inclusion で本Steeringが読み込まれ、「サンドイッチ法」「重要度3段階(🔴🟡🟢)」などの内容を含む説明が返ればOK。実際のレビュー動作の検証は、第2章で reports/ 配下にレポートが揃ってから行います。
レビューや評価をするときのガイドラインを教えて
review-guidelinesの読み込みが確認できます。
演習 1-3: ファイル参照で既存資料を読ませる
調査対象が変わるたびにチャットで5社を指定するのは面倒です。リストをファイル化して、Steeringから常に参照させます。
data/research-targets.md を作成して、下記の内容をコピペしてください。
# 調査対象サービス一覧
| サービス名 | 運営会社 |
| ------------------ | ----------------------- |
| Netflix | Netflix, Inc. |
| Amazon Prime Video | Amazon |
| Disney+ | The Walt Disney Company |
| U-NEXT | U-NEXT株式会社 |
| Apple TV+ | Apple Inc. |
次にステアリングファイルを作成します。
.kiro/steering/services.md を作成し、下記をコピペしてください。
---
inclusion: always
---
# 調査の基本情報
以下の調査対象リストを常に参照してください:
#[[file:data/research-targets.md]]
Steeringファイルから #[[file:data/research-targets.md]] と書くことで、調査対象リストを常にKiroに意識させることができます。
調査対象が変わった場合は、Steeringを修正せず data/research-targets.md を修正するだけで大丈夫です。
確認方法: チャットで「調査対象のサービスを一覧で教えて」と入力。data/research-targets.md に記載した5社が返ってくれば、ファイル参照が正しく機能している証拠です。実際の調査の実行は第2章の Skill 作成後に試します。
調査対象のサービスを一覧で教えて
services.mdが読み込まれresearch-targets.mdに指定したサービスを認識してくれます。
演習 1-4: 判断基準 Steering を作成する
本ハンズオンのファクトチェック自動化を支える重要な Steering です。「どんな指摘をどう扱うか」の判断基準をここに集約し、Skill側に判断ロジックを書かないことで、基準を変えたいときは Steering 1ファイルの修正で済むようになります。
.kiro/steering/judgment-criteria.md を作成:
---
inclusion: auto
name: judgment-criteria
description: 出典チェックと修正判断の基準。修正、保持、保留、再調査、ファクトチェック、ハルシネーション監査の判断を行うときに使用。
---
# 判断基準
## 項目のカテゴリ分類
source-checkが指摘した各項目は、以下の3カテゴリに分類して扱う。
### A. 機械的修正項目
出典URL補完、取得日追記、「※推測」マークの追加、表記統一など、判断を要しない形式的な修正。
→ ✅ そのまま修正してよい(再調査不要)
### B. 事実検証項目
数値、日付、固有名詞、シェア率、ランキングなど、検証可能な事実主張。
→ 公的ソースで検証してから判断する
### C. 主観・予測・業界慣行
評価表現、将来予測、業界常識的記述。
→ 再調査不要。「※推測」追記または保持判断
## カテゴリ別の処理ルール
### A の処理
- 提案通りに修正
- 状態: ✅
- 根拠記録: 「形式的修正につき再調査なし」と明記
### B の処理
公的ソースで検証した結果に応じて分岐:
| 検証結果 | 状態 | アクション |
| -------------- | ---- | ----------------------------------- |
| 一致 | ✅ | 出典URLと取得日を追記 |
| 異なる | ✅ | 公的ソースの値に書き換え(根拠必須) |
| 出典見つからず | ⚠️ | 判断保留として人間判断に渡す |
### C の処理
- 出典なしを承知の上で保持する価値があるか判断
- 業界共通認識・文脈上必要 → 🟦 保持(理由必須)
- 推測・予測の性質が強い → 「※推測」「※業界観測」を追記して ✅
- どちらとも言えない → ⚠️ 保留
## 公的ソースの優先順位
事実検証(カテゴリB)における出典の優先順位:
1. 当該企業の公式発表(公式サイト、決算資料、プレスリリース、IR資料)
2. 公的機関・業界団体の統計(総務省、経産省、業界団体公表値)
3. 大手調査会社のレポート(要出典明記、機関名と発行年を必ず記録)
4. 大手メディアの報道(要出典明記、可能なら一次ソースまで遡る)
**採用しない**: 個人ブログ、まとめサイト、Wikipedia、SNS投稿、出典不明の二次情報
## 保留にすべきケース
以下の場合は無理に修正せず ⚠️ 保留とすること:
- 公的ソースで複数の異なる値が出てくる
- 「直近」「最新」と書かれているが、複数時期の数値が混在している
- そもそも該当する事実が確認できない(過去のものになっている可能性)
- 一次ソースが英語等の外国語のみで、翻訳に解釈の余地がある
- 検索結果が古く(1年以上前)、現在も有効か不明
## 修正時の必須記録項目
カテゴリB・Aで本文を修正する場合、本文中の該当箇所に以下を必ず含める:
- 出典URL(短縮URLではなく完全な形)
- 取得日(YYYY-MM-DD形式)
- 引用形式: `出典: https://... ({YYYY-MM-DD}取得)`
判断ログ側にも同じ情報を記録する(重複でよい)。
---
## 許容される無害な変更パターン
`decision-log-audit` Skill がハルシネーション検出を行う際の**例外リスト**。判断ログに明示されていない変更でも、ここに登録されたパターンに該当する場合は ✅ 監査OK として扱う。
**運用方針**: 最初は厳しめ(このリストは空に近い状態)で始め、運用しながら明らかに無害な変更を発見したら追記していく。Skill 側に例外ロジックを書かず、本リストで一元管理する。
### 登録フォーマット
```
### #NNN: パターン名
- 説明: どのような変更を許容するか
- 適用条件: 該当判定の基準
- 例:
- 修正前: ...
- 修正後: ...
```
### 登録済みパターン
<!-- 初期状態: 空。運用しながら追加していく -->
(現在登録されているパターンなし)
### 追加候補(運用開始後に検討)
以下は実際に運用してノイズになった時に登録する候補:
- 日付・期間表記の正規化(「2025年Q1」⇔「2025年第1四半期」など)
- 半角・全角の統一
- 句読点の修正
- URLのトラッキングパラメータ除去
ただし**実際に発生してから登録**する方針。先回りで全部登録しないこと。
確認方法: チャットで「事実検証項目とは何で、どう扱うべき?」と質問。本Steeringの内容(カテゴリB、公的ソースの優先順位など)に沿った回答が返れば、auto inclusion で正しく読み込まれています。
事実検証項目とは何で、どう扱うべき?
judgment-criteria.mdの読み込まれています。
演習 1-5: ワークフロー遵守ポリシーを定義する
ユーザーの指示が抽象的・短文になりがちな場面(「修正して」「比較して」「まとめて」など)で、エージェントが Skill を経由せず直接ファイルを編集・生成してしまう事故を防ぐための always Steering です。
判断ログ駆動モデルとSkillの責務分離は本ハンズオンの根幹なので、設計原則を Steering で明文化して強制します。
.kiro/steering/workflow-policy.md を作成:
---
inclusion: always
---
# ワークフロー遵守ポリシー
このプロジェクトは判断ログ駆動モデルに基づく特定のワークフローで構築されている。
ユーザーの指示が抽象的・短文であっても、以下のルールを必ず守ること。
**効率を理由にスキップしない。**
## 1. 本文修正権限は apply-decisions Skill のみ
`reports/*.md` の本文を直接編集できるのは **`apply-decisions` Skill だけ**である。
ユーザーから以下のような指示があっても、エージェントが本文を直接書き換えてはならない:
- 「修正して」「直して」「更新して」「書き換えて」
- 「ここを変えて」「これも追加して」
- 「出典を足して」「日付を追記して」
必ず以下の経路を通る:
\`\`\`
source-check Skill (指摘)
→ re-investigate-and-judge Skill (判断ログ生成)
→ apply-decisions Skill (本文修正)
→ decision-log-audit Skill (監査)
\`\`\`
**例外**: 新規ファイルの作成 (`service-research` Skill による初回調査) は本ルールの対象外。
既存ファイルへの編集に限定して適用される。
## 2. 統合レポート生成は integrated-report Skill のみ
`output/final-report-*.md` を生成できるのは **`integrated-report` Skill だけ**である。
ユーザーから以下のような指示があっても、エージェントが直接 output/ にファイルを書き出してはならない:
- 「比較して」「比較表を作って」
- 「まとめて」「サマリを作って」
- 「統合レポートを作って」「最終レポートを作って」
- 「全部見せて」「一覧化して」
必ず `integrated-report` Skill を呼び出し、その内部の監査ゲートを通過させること。
**チャット内で簡易的に比較を表示するのは可**。ただしファイルとして書き出す場合は必ず Skill を経由する。
## 3. 判断ログの不変性
`reports/_review/decision-log-*.md` に「適用結果」セクションが既に存在する場合、そのログは**確定済み**として扱う。
- 上書き編集や再実行をしない
- 修正が必要な場合は `re-investigate-and-judge` Skill を再実行し、**新しい日付の判断ログを作り直す**
- 過去の判断ログは履歴として残す (Git管理を前提)
## 4. ファイル種別の境界
| 場所 | 編集権限 |
| -------------------------- | ------------------------------------------------- |
| `reports/*.md` | `apply-decisions` Skill のみ (新規作成は除く) |
| `reports/_review/*.md` | 各 Skill が自分の担当セクションを追記するのみ |
| `output/*.md` | `integrated-report` Skill のみ |
| `data/*.md` | ユーザーが手動で編集 (エージェントは原則触らない) |
「reports/ を読む」「reports/ を統合する」といった指示で `_review/` 配下を含めない。
## 5. ショートカット禁止
ユーザーの抽象的な指示にも対応するが、設計原則をスキップしない。状態に応じて適切な Skill から開始する:
- **reports/ に対象レポートがない状態で「比較して」** → `service-research` Skill から開始
- **checklist がない状態で「修正して」** → `source-check` Skill から開始
- **判断ログが未生成で「直して」** → `re-investigate-and-judge` から開始
- **監査未通過で「統合レポートを作って」** → 監査ゲート確認のために中止
## 6. 不確実時はユーザーに確認
どの Skill を使うべきか判断できない場合、勝手にショートカットせず、ユーザーに次のいずれかを確認する:
- 現在の状態(どこまで進んでいるか)
- 期待される出力(チャット表示で十分か、ファイルとして残すか)
- スキップしてよい工程の有無
確認方法: チャットで「reports/ の本文を直接修正していい?」と質問してください。エージェントが「本プロジェクトでは apply-decisions Skill のみが本文を修正できる」「source-check → re-investigate-and-judge → apply-decisions → decision-log-audit の経路を通る必要がある」とワークフロー全体を説明できればOK。実際の修正動作の検証は第2章以降の Skill 構築後、および第6章の統合演習で行います。
reports/ の本文を直接修正していい?
workflow-policy.mdが読み込まれていることが確認できます。
第2章: Skills — 調査・分析・指摘・再調査・修正・監査・統合の「手順」を実行するスキルを作る
Skillsとは?
Skillsは、オープンなAgent Skills標準に準拠した再利用可能な手順パッケージです(公式ドキュメント)。手順・スクリプト・テンプレートをまとめておき、タスクに関連するときだけKiroが読み込んで実行します。
この章では、本ハンズオンの作業を担う7つのSkillを作ります。
| Skill | 役割 | 位置づけ | 本文修正権限 |
|---|---|---|---|
service-research |
サービスを調査してレポートを書く | 必須 (後の Hook 1 で起動) | ❌(新規作成のみ) |
swot-analysis |
レポートからSWOT分析を作る | オプション (任意で実行) | ❌ |
source-check |
レポートの出典をチェックしチェックリスト化 | 必須 (後の Hook 2 で起動) | ❌ |
re-investigate-and-judge |
チェックリストの項目を再調査し判断ログ生成 | 必須 (後の Hook 3 で起動) | ❌ |
apply-decisions |
判断ログを本文に反映 | 必須 (後の Hook 3 で起動) | ✅ 唯一の権限保持 |
decision-log-audit |
ハルシネーションと反映漏れの監査 | 必須 (後の Hook 3 で起動) | ❌ |
integrated-report |
個別レポートを統合して比較レポートを生成 | 必須 (後の Hook 4 で起動) | ❌ |
💡 設計の核: 本文修正権限を持つSkillは
apply-decisionsだけです。これにより「誰が本文を変えたか」が一意に追跡可能になり、監査の対象も明確になります。
💡 SWOT分析だけがオプション扱い: メインの自動化フロー(Hook 1〜4)には組み込まれていません。Skillsの概念学習として作成し、必要なときにチャットから明示的に呼び出して使います。
SteeringとSkillsの責務分離
| Steering | Skills | |
|---|---|---|
| 例えるなら | スタイルガイド・社内規定 | 手順書・マニュアル |
| 読み込み | 常時 or 条件付き | 必要なときだけ |
| 内容 | ルール・規約・判断基準 | 具体的な作業手順+テンプレート |
| 構造 | 単一のMarkdownファイル | フォルダ(references/ scripts/ assets/) |
| 共有性 | プロジェクト固有 | ポータブル(インポート/エクスポート可能) |
💡 判断基準: 「全ての作業に常に適用されるべきか?」→ Steering。「特定の作業を依頼されたときだけ必要か?」→ Skills。
Skillsのフォルダ構造(公式仕様)
my-skill/
├── SKILL.md # 必須: 手順の本体
├── scripts/ # 任意: 実行可能なスクリプト
├── references/ # 任意: 参照ドキュメント(詳細解説、仕様書など)
└── assets/ # 任意: テンプレート、設定ファイルなど
references/ や assets/ に分離することで、SKILL.md本体を軽く保ちつつ、必要なときだけ詳細情報を読み込めます。
演習 2-1: サービス調査Skillを作成する
調査の手順とアウトプット形式を1つのSkillにまとめます。
.kiro/skills/service-research/SKILL.md を作成:
---
name: service-research
description: サブスクリプションサービスの調査・比較を行う。サービス比較、料金調査、機能比較を行うときに使用。
---
## サービス調査の手順
### Step 1: 基本情報の収集
- サービス概要(開始年、運営会社、対象地域)
- 会員数・シェア
- 直近のニュース・アップデート
### Step 2: 料金プラン分析
- プラン一覧と価格
- 無料トライアルの有無
- 家族プラン・学割の有無
### Step 3: コンテンツ・機能分析
- コンテンツ数・ジャンル構成
- オリジナル作品の強み
- 画質・同時視聴数・ダウンロード対応
### Step 4: 比較表の作成
`assets/comparison-table.md` のテンプレートを使用する。
### Step 5: 保存
- `reports/{サービス名}.md` として保存する(ファイル名は英小文字とハイフン)
### Step 6: 総合評価と示唆
続いて.kiro/skills/service-research/assets/comparison-table.mdを作成し、比較表を作成するためのテンプレートを追加します。
# サービス比較表
## 基本情報
| 項目 | サービスA | サービスB | サービスC |
| -------------------- | --------- | --------- | --------- |
| サービス開始年 | | | |
| 運営会社 | | | |
| 対象地域 | | | |
| 会員数 | | | |
| 市場シェア | | | |
| 直近のアップデート | | | |
## 料金プラン
| 項目 | サービスA | サービスB | サービスC |
| --------------------- | --------- | --------- | --------- |
| エントリープラン | | | |
| スタンダードプラン | | | |
| プレミアムプラン | | | |
| 無料トライアル | | | |
| 家族プラン | | | |
| 学割 | | | |
| 年額プランの有無/割引 | | | |
## コンテンツ・機能
| 項目 | サービスA | サービスB | サービスC |
| -------------------- | --------- | --------- | --------- |
| 総コンテンツ数 | | | |
| 主要ジャンル | | | |
| オリジナル作品の強み | | | |
| 最高画質 | | | |
| 同時視聴数 | | | |
| ダウンロード対応 | | | |
| 対応デバイス | | | |
## 出典一覧
各サービスの主要な情報源を記録します。`source-check` Skill のチェック対象になります。
| サービス | 出典URL | 取得日 |
| --------- | ------- | ------ |
| サービスA | | |
| サービスB | | |
| サービスC | | |
## 推測・観測情報の取り扱い
事実として確認できない情報(将来の値上げ予測、シェア順位の解釈など)は本表には含めず、本文側に「※推測」「※業界観測」を明示して記載してください。
呼び出し方: チャットで「Netflixを調査して」と入力するか、/service-research スラッシュコマンドで明示的に呼び出し。
Netflixを調査して
service-researchが利用されていることが確認できます。
レポートが作成されました。
演習 2-2: SWOT分析Skillを作成する(オプション)
💡 本Skillはオプション扱い: メインの自動化フロー(Hook 1〜4)には組み込まれていません。Skillsの
references/活用例として作成し、必要に応じて「NetflixのSWOT分析をして」のように呼び出して使います。本ハンズオンを最短で動かしたい場合はスキップしても問題ありません。
SWOT分析は「分析手順+テンプレート」なので、Skills に置きます。さらに references/ にフレームワーク詳細を分離します。
.kiro/skills/swot-analysis/SKILL.md を作成:
---
name: swot-analysis
description: SWOT分析を行う。強み弱み分析、戦略分析、競合のSWOT、事業分析を行うときに使用。
---
## SWOT分析の手順
### Step 1: 対象の基本情報を整理する
### Step 2: 4象限を埋める(`references/framework.md` のテンプレートを使用)
### Step 3: クロスSWOT戦略を導出する
### Step 4: アクションアイテムの提案
### Step 5: 保存
- `reports/{サービス名}-swot.md` として保存する(ファイル名は英小文字とハイフン)
- `integrated-report` Skill はこのファイルが存在する場合のみ統合レポートに取り込む
.kiro/skills/swot-analysis/references/framework.md にSWOTマトリクスやクロスSWOT戦略の詳細テンプレートを配置:
# SWOT分析フレームワーク詳細
## SWOTマトリクス テンプレート
| | プラス要因 | マイナス要因 |
| -------- | ------------ | ------------ |
| 内部環境 | **強み (S)** | **弱み (W)** |
| 外部環境 | **機会 (O)** | **脅威 (T)** |
## 各象限の分析観点
### 強み (Strengths) — 内部 × プラス
- 独自の技術・特許
- ブランド力・認知度
- 人材・組織力
- 財務基盤
- 顧客基盤・ネットワーク
### 弱み (Weaknesses) — 内部 × マイナス
- リソース不足
- 技術的負債
- 市場カバレッジの限界
- 組織の硬直性
- コスト構造の問題
### 機会 (Opportunities) — 外部 × プラス
- 市場の成長
- 規制緩和
- 技術革新
- 競合の撤退・弱体化
- 新しい顧客セグメント
### 脅威 (Threats) — 外部 × マイナス
- 新規参入者
- 代替技術の台頭
- 規制強化
- 景気後退
- 顧客ニーズの変化
## クロスSWOT戦略テンプレート
| 戦略 | 組み合わせ | 方向性 |
| ------ | ----------- | ------------------------------ |
| SO戦略 | 強み × 機会 | 強みを活かして機会を最大化する |
| WO戦略 | 弱み × 機会 | 弱みを克服して機会を活用する |
| ST戦略 | 強み × 脅威 | 強みを活かして脅威に対抗する |
| WT戦略 | 弱み × 脅威 | 弱みと脅威の影響を最小化する |
呼び出し方: チャットで「NetflixのSWOT分析をして」と入力するか、/swot-analysis スラッシュコマンドで明示的に呼び出し。
NetflixのSWOT分析をして
swot-analysisが適用されSWOT分析レポートの作成を実施してくれています。
演習 2-3: 出典チェックSkill(source-check)を作成する
ここからがファクトチェック自動化の入口です。レポートの品質を担保する指摘Skillを作ります。
このSkillはファイル本体を直接修正しません。問題点と修正提案をチェックリスト形式で別ファイルに出力するだけです。本文の修正は後段の apply-decisions Skill が担当します。
.kiro/skills/source-check/SKILL.md を作成:
---
name: source-check
description: レポートの出典・取得時期・推測/事実の区別をチェックし、修正提案つきチェックリストを生成する。出典チェック、ファクトチェック、レビュー、品質チェックを行うときに使用。
---
## 手順
### Step 1: 対象ファイルを読む
- 指示がなければ `reports/` 配下のすべての `.md` を対象にする
- 単一ファイル指定時はそれだけを対象にする
- ※ `reports/_review/` 配下は対象外
### Step 2: 4観点で問題を抽出する
1. 出典が不足している記述(URLまたは情報源名がない)
2. 取得時期が不明な数値(例: 「会員数1.5億人」など)
3. サービス間で矛盾している記述(料金・プラン名など)
4. 推測と事実が区別されていない箇所
### Step 3: チェックリストを出力する
`assets/checklist-template.md` のフォーマットに沿って、
`reports/_review/checklist-{YYYY-MM-DD}.md` に出力する。
各項目は必ず以下3点を含めること:
- **場所**: ファイル名・該当箇所の引用
- **問題の指摘**: 何が不足・矛盾しているか
- **具体的な修正提案**: どう直すべきか(これがないと項目として不完全)
### Step 4: ファイル本体は修正しない
本Skillは**指摘の生成のみ**を担当する。
本文の修正は `apply-decisions` Skill の責務であり、その前段で `re-investigate-and-judge` Skill が判断ログを生成する。
本Skillは判断ログにも触らない。
.kiro/skills/source-check/assets/checklist-template.md を作成:
# レビューチェックリスト ({YYYY-MM-DD})
> このチェックリストはsource-check Skillが自動生成しました。
> 後段の re-investigate-and-judge Skill が各項目を再調査して判断ログを生成し、
> apply-decisions Skill が本文に反映します。
## 🔴 必須修正
- **[ファイル名]** 「該当箇所の引用」
- 問題: (何が不足・矛盾しているか)
- 修正提案: (どう直すべきか)
## 🟡 推奨修正
- **[ファイル名]** 「該当箇所の引用」
- 問題: ...
- 修正提案: ...
## 🟢 任意
- **[ファイル名]** 「該当箇所の引用」
- 問題: ...
- 修正提案: ...
確認方法: チャットで「reports/ の出典をチェックして」と入力。reports/_review/checklist-YYYY-MM-DD.md が生成され、🔴🟡🟢の3段階で問題点と修正提案がリストアップされればOK。
⚠️ 動作確認の前提: 本 Skill のチェック対象は
reports/配下のレポートです。第2章時点ではまだレポートが揃っていない場合があるので、空のreports/sample.mdなどダミーを用意するか、第6章の統合演習でまとめて確認する形でも構いません。
reports/ の出典をチェックして
source-checkスキルが呼び出されています。
レポートの出力も確認できました。
レポートの内容をみると評価をしてくれていることがわかります。
演習 2-4: 再調査・判断Skill(re-investigate-and-judge)を作成する
source-check が出した指摘について、Webで再調査し、修正/保持/保留の判断を確定するSkillです。判断結果は判断ログ(decision-log)に書き出します。本文は触りません。
.kiro/skills/re-investigate-and-judge/SKILL.md を作成:
---
name: re-investigate-and-judge
description: source-checkが指摘した項目を再調査し、修正/保持/保留の判断を判断ログに記録する。本文は修正しない。再調査、ファクトチェック、判断ログ生成を行うときに使用。
---
## 概要
`source-check` が生成したチェックリストの各項目について:
1. 必要に応じてWeb検索で再調査し
2. **修正 / 意図的に保持 / 判断保留** のいずれかを判断し
3. 全件の判断と根拠を判断ログに記録する
**本文は修正しない。** 本文への反映は `apply-decisions` Skill の責務である。
判断基準は `.kiro/steering/judgment-criteria.md` を信頼し、Skill側で独自判断は行わない。
## 入力
- `reports/_review/checklist-*.md` の最新ファイル
- `reports/*.md` の本文(該当箇所の確認のため読み取りのみ)
## 出力
- `reports/_review/decision-log-{YYYY-MM-DD}.md` (新規生成)
## 手順
### Step 1: 最新のチェックリストを読む
`reports/_review/` 配下の最新 `checklist-*.md` を読み込む。各項目について以下を抽出:
- 場所(ファイル名・該当箇所の引用)
- 問題の指摘
- 修正提案
- 重要度(🔴 / 🟡 / 🟢)
### Step 2: 項目ごとにカテゴリ分類する
`.kiro/steering/judgment-criteria.md` の分類基準に従って、各項目を以下のいずれかに分類:
- **A. 機械的修正項目** — 出典URL補完、取得日追記、表記統一など
- **B. 事実検証項目** — 数値・日付・固有名詞・シェア率など、検証可能な事実
- **C. 主観・予測・業界慣行** — 評価表現、将来予測、業界常識的記述
### Step 3: 項目ごとに再調査と判断を行う
カテゴリに応じて以下を実行する。
**A の場合**: 再調査不要。提案内容を判断ログに ✅ で記録する。
**B の場合**:
1. Web検索(または Tavily MCP)で公的ソースを確認する
2. 公的ソースの優先順位は `judgment-criteria.md` に従う
3. 結果に応じて記録する:
- 一致 → ✅(出典URLと取得日を記録)
- 異なる → ✅(公的ソースの値と根拠URLを記録)
- 出典見つからず → ⚠️ 保留
**C の場合**: 再調査不要。
- 「※推測」「※業界観測」追記で対応するなら → ✅
- 出典なしで保持が妥当なら → 🟦(理由必須)
- 判断つかない → ⚠️ 保留
### Step 4: 判断ログを生成する
`reports/_review/decision-log-{YYYY-MM-DD}.md` を新規作成し、`assets/decision-log-template.md` のフォーマットに従って全件を記録する。
各項目には以下を必ず含める:
- 場所(ファイル名・該当箇所の引用)
- カテゴリ(A / B / C)
- 状態(✅ / 🟦 / ⚠️)
- **修正アクション内容**(✅の場合: 何をどう書き換えるかを具体的に明記)
- 判断理由(🟦・⚠️の場合)
- 根拠URL(B型 ✅ の場合は必須)
- 取得日
> 💡 「修正アクション内容」は次工程の `apply-decisions` が実行する指示書になる。曖昧な記述は避け、「該当箇所をXXXに置き換える」「末尾に出典として `https://... ({YYYY-MM-DD}取得)` を追記する」のように、機械的に実行可能なレベルで書くこと。
### Step 5: 残課題サマリを末尾に追加する
判断ログの末尾に以下を出力する:
```
## 残課題サマリ
- ✅ 修正アクション確定: N件
- 🟦 意図的に保持: N件
- ⚠️ 判断保留: N件
## 次工程ゲート
- [ ] ⚠️ 保留項目がすべて解消された
- [ ] apply-decisions の実行に進んでよい
```
## 重要事項
- **本文を絶対に編集しない。** 修正は `apply-decisions` Skill の責務
- **判断基準は Steering を信頼すること。** Skill側で「これは直すべき」「これは残すべき」と独自判断を加えない
- **修正アクション内容は実行可能な粒度で書く。** apply-decisions が機械的に解釈できるよう明確に
- **「あえて残す」判断には必ず理由を書く。** 後から第三者が監査できるように
- **一度の実行で全件を処理する。** 部分実行で中断するとログの整合性が壊れる
判断ログのテンプレートも作成します。
.kiro/skills/re-investigate-and-judge/assets/decision-log-template.md を作成:
# 判断ログ ({YYYY-MM-DD})
> このログは re-investigate-and-judge Skill が自動生成しました。
> 各項目の判断と根拠が記録されており、後から監査可能です。
> ✅ 項目の本文反映は apply-decisions Skill が、整合性監査は decision-log-audit Skill が担当します。
---
## ✅ 修正アクション確定
### [reports/netflix.md] 「会員数2.7億人」
- **カテゴリ**: B (事実検証)
- **状態**: ✅
- **修正アクション内容**: 該当箇所を「会員数約3.0億人 (2025年Q4時点)」に書き換え、末尾に「出典: https://about.netflix.com/... (2026-05-12取得)」を追記
- **根拠URL**: https://about.netflix.com/...
- **取得日**: 2026-05-12
### [reports/disney-plus.md] 「2019年開始」
- **カテゴリ**: A (機械的修正)
- **状態**: ✅
- **修正アクション内容**: 該当行の末尾に「(出典: https://thewaltdisneycompany.com/..., 2026-05-12取得)」を追記。本文の事実関係は変更しない
- **根拠**: 形式的修正につき再調査なし
- **取得日**: 2026-05-12
---
## 🟦 意図的に保持
### [reports/u-next.md] 「日本市場では国産系の代表格」
- **カテゴリ**: C (業界慣行)
- **状態**: 🟦
- **判断理由**: 業界共通認識として記載。定量的な順位ソースを当てるよりも文脈表現として有効と判断
- **備考**: 次回 source-check で同様の指摘が出た場合、本判断を参照すること
---
## ⚠️ 判断保留
### [reports/apple-tv-plus.md] 「料金は今後値上げ予定」
- **カテゴリ**: B (事実検証)
- **状態**: ⚠️
- **再調査結果**: 公式発表なし。観測記事は存在するが一次ソース未確認
- **推奨アクション**:
- 「※業界観測」を追記して掲載するか
- 該当記述を削除するか
- 人間判断を仰ぐ
---
## 残課題サマリ
- ✅ 修正アクション確定: N件
- 🟦 意図的に保持: N件
- ⚠️ 判断保留: N件
## 次工程ゲート
- [ ] ⚠️ 保留項目がすべて解消された
- [ ] apply-decisions の実行に進んでよい
<!--
以下、apply-decisions 実行後に追記されるセクション
## 適用結果 (YYYY-MM-DD HH:MM)
...
以下、decision-log-audit 実行後に追記されるセクション
## 監査結果 (YYYY-MM-DD HH:MM)
...
-->
確認方法: 演習2-3で生成したチェックリストがある状態で、チャットで「re-investigate-and-judge を実行して」と入力。reports/_review/decision-log-YYYY-MM-DD.md が生成され、各項目に ✅ / 🟦 / ⚠️ の判断と修正アクション内容が記録されていればOK。本文ファイルは未変更であることも合わせて確認してください。
re-investigate-and-judge を実行して
re-investigate-and-judgeスキルの実行が確認できます。
ログが出力されました。
Webで再調査し、修正/保持/保留の判断して結果がまとめられていることが確認できます。
演習 2-5: 修正適用Skill(apply-decisions)を作成する
判断ログを読み込んで本文に反映するSkill。本ハンズオンにおいて、本文修正権限を持つ唯一のSkillです。
.kiro/skills/apply-decisions/SKILL.md を作成:
---
name: apply-decisions
description: 判断ログに記録された修正アクションをレポート本文に反映する。判断ログの実行、本文修正の適用を行うときに使用。
---
## 概要
`re-investigate-and-judge` が生成した判断ログを読み込み、✅ 状態の項目を `reports/*.md` 本文に反映する。
**このSkillは本ハンズオンにおいて、レポート本文を直接書き換える権限を持つ唯一のSkillである。** 他のSkillから本文修正を行ってはならない。
## 入力
- `reports/_review/decision-log-*.md` の最新ファイル
## 出力
- `reports/*.md` (該当箇所を直接修正)
- 判断ログに「適用結果」セクションを追記
## 手順
### Step 1: 最新の判断ログを読む
`reports/_review/` 配下の最新 `decision-log-*.md` を読み込む。
### Step 2: 適用前ガード
以下を確認し、満たさない場合は実行を中止する:
- ⚠️ 保留項目が0件であること
- 各 ✅ 項目に「修正アクション内容」が記載されていること
- 判断ログがすでに「適用結果」セクションを持っていないこと(**二重適用防止**)
中止する場合は、ユーザーに理由を明示する。
### Step 3: ✅ 項目を1件ずつ本文に反映
各 ✅ 項目について以下を実行:
1. 対象ファイル (`reports/*.md`) と該当箇所を特定する
2. 「修正アクション内容」に書かれた指示通りに本文を編集する
3. 編集ルール:
- **最小差分の原則** — 該当箇所のみ書き換える。周辺の文脈や見出し構造を壊さない
- **出典の追記形式** — `出典: https://... ({YYYY-MM-DD}取得)` で統一
- **判断ログにない情報を本文に追加しない** — ハルシネーション防止のため、ログに書かれた以上のことはしない
4. 1件編集するごとに、編集前後の差分を確認してから次へ進む
🟦 (保持) と ⚠️ (保留) の項目は本文修正不要。スキップする。
### Step 4: 適用結果を判断ログに追記
判断ログの末尾に「## 適用結果 (YYYY-MM-DD HH:MM)」セクションを追記する:
```
## 適用結果 (YYYY-MM-DD HH:MM)
### 適用済み
- [reports/netflix.md] 「会員数2.7億人」 → 「会員数約3.0億人 (2025年Q4時点)」
- [reports/disney-plus.md] 「2019年開始」 → 「2019年11月開始」
### スキップ (🟦 / ⚠️)
- [reports/u-next.md] 「日本市場では国産系の代表格」 (🟦 保持)
- [reports/apple-tv-plus.md] 「料金は今後値上げ予定」 (⚠️ 保留)
### 適用件数
- ✅ 適用済み: N件
- 🟦 スキップ (保持): N件
- ⚠️ スキップ (保留): N件
```
### Step 5: 次工程への引き継ぎ
ユーザーに以下を報告する:
- 適用件数のサマリ
- 次工程: `decision-log-audit` で監査を実施する旨
## 再適用が必要になった場合の運用
監査NGや人間判断によって判断ログを再構築する必要が生じた場合の方針:
### 原則: 同じ判断ログを上書き・再実行しない
「適用結果」セクションがある判断ログは**確定された監査対象**として扱い、後から修正・再適用してはならない。理由:
- 再実行すると本文に二重修正がかかる可能性がある
- 判断ログの「適用結果」が事実と乖離し、Git履歴と整合しなくなる
- 後続の `decision-log-audit` が何を監査すべきか不明瞭になる
### 推奨運用: 新しい日付で判断ログを作り直す
1. `re-investigate-and-judge` Skill を再実行し、新しい日付の判断ログを生成する
2. 古い判断ログはそのまま残す(履歴として保存)
3. `apply-decisions` は新しい判断ログを入力として実行する
4. 過去との差分を確認したい場合は Gitで両ファイルを比較する
## 重要事項
- **判断ログに書かれていることだけを実行する。** 自分で再調査や判断を追加しない
- **編集に迷ったら中止する。** 「修正アクション内容」が曖昧な場合は適用せず、該当項目を「適用保留」として報告する
- **同じ判断ログを2回実行しない。** 「適用結果」セクションがある判断ログは適用済みとみなしスキップする
- **再適用が必要なら新しい日付で判断ログを作り直す。** 上書きや部分修正後の再実行は行わない
- **エラー時は途中で止める。** 一括適用の途中でエラーが起きたら、その時点の状態を報告して停止する
確認方法: 演習2-4で生成した判断ログがある状態で、チャットで「apply-decisions を実行して」と入力。reports/*.md の該当箇所が修正され、判断ログ末尾に「## 適用結果」セクションが追記されていればOK。
apply-decisions を実行して
apply-decisionsスキルの読み込みが確認できます。
修正が実行されていきます。
ログにも適用結果が反映さていることが確認できました。
演習 2-6: 監査Skill(decision-log-audit)を作成する
最後の砦。本文修正がハルシネーションを含んでいないか、保持項目が誤って削除されていないかを監査します。
.kiro/skills/decision-log-audit/SKILL.md を作成:
---
name: decision-log-audit
description: 判断ログとレポート本文の整合性を監査し、ハルシネーションや反映漏れを検出する。判断ログ監査、修正反映確認、ハルシネーションチェックを行うときに使用。
---
## 概要
`apply-decisions` の実行後、判断ログと `reports/*.md` の整合性を監査する。
監査の観点は3つ:
1. **反映漏れ** — ✅ 項目が本文に反映されているか
2. **ハルシネーション** — 判断ログにない情報が本文に追加されていないか
3. **保持項目の残存** — 🟦 項目が誤って削除されていないか
## 入力
- `reports/_review/decision-log-*.md` の最新ファイル(「適用結果」セクション付きであること)
- `reports/*.md` の本文
- `.kiro/steering/judgment-criteria.md` の「許容される無害な変更パターン」セクション
## 出力
- 判断ログに「監査結果」セクションを追記
## 手順
### Step 1: 最新の判断ログを読む
`reports/_review/` 配下の最新 `decision-log-*.md` を読み込む。
「適用結果」セクションが存在しない場合は、「apply-decisions が未実行です」とユーザーに通知して中止する。
### Step 2: ✅ 項目の反映確認
各 ✅ 項目について以下を検証:
1. 「修正アクション内容」に書かれた変更が、対応する `reports/*.md` の該当箇所に反映されているか
2. 出典URLが追記されているか(B型項目の場合)
3. 取得日が記録されているか
判定:
- ✅ 監査OK — 提案通り反映されている
- ⚠️ 監査NG (反映漏れ) — チェックボックスは ✅ だが本文が直っていない、または不完全
### Step 3: ハルシネーション検出
`apply-decisions` の「修正アクション内容」と実際の本文修正を比較し、以下を検出する:
- 判断ログに書かれていない**新規記述**が本文に追加されていないか
- 修正と関係ない箇所が変更されていないか
- 出典URLが判断ログのものと異なっていないか
**ただし、`judgment-criteria.md` の「許容される無害な変更パターン」に該当する変更は ❌ にしない。** 該当する場合は ✅ 監査OK とし、監査結果に「許容パターン適用」と備考を残す。
判定:
- ✅ 監査OK — ログ通りの修正のみが反映されている / または許容パターンに該当
- ❌ 監査NG (ハルシネーション疑い) — ログにない情報が追加されている / 別の修正が混入している
### Step 4: 🟦 保持項目の残存確認
各 🟦 項目について、該当箇所が本文に**そのまま残っているか**確認する。意図的に保持と判断されたものが削除・改変されていれば監査NG。
### Step 5: 監査結果を判断ログに追記
判断ログの末尾に「## 監査結果 (YYYY-MM-DD HH:MM)」セクションを追記:
```
## 監査結果 (YYYY-MM-DD HH:MM)
### ✅ 監査OK
- [reports/netflix.md] 「会員数」項目: 反映済み、出典・取得日OK、ハルシネーションなし
- ...
### ⚠️ 監査NG: 反映漏れ
- (該当なし)
### ❌ 監査NG: ハルシネーション疑い
- (該当なし)
### サマリ
- 監査対象: N件
- ✅ OK: N件 (うち許容パターン適用: N件)
- ⚠️ 反映漏れ: N件
- ❌ ハルシネーション疑い: N件
- 🟦 保持項目の残存OK: N件
### 統合レポート生成ゲート
- [ ] すべての監査項目が ✅ OK である
- [ ] ⚠️ 保留項目が判断ログにゼロ件である
- [ ] 統合レポート生成に進んでよい
```
### Step 6: ユーザーへの報告
監査結果のサマリと、次工程に進めるかどうかをユーザーに報告する。
- 全項目 ✅ かつ ⚠️ 保留ゼロ → 「統合レポート生成に進めます」
- それ以外 → 残課題を一覧で提示
**ノイズフィードバックの提案**: 監査NGの中に「明らかに無害だが許容パターンに未登録のもの」を発見した場合、`.kiro/steering/judgment-criteria.md` の「許容される無害な変更パターン」への追加をユーザーに提案する。運用しながら許容パターンを育てていく。
## 重要事項
- **判断ログを信じすぎない。** 「適用結果」に「適用済み」と書かれていても、本文を実際に確認する
- **本文は絶対に編集しない。** 監査結果の追記のみが本Skillの書き込み権限
- **ハルシネーションの判定は最初は厳しめでよい。** 運用初期はノイズ多めでも誤検出ゼロを優先。許容パターンが整ってきたら自然に静かになる
- **保持項目の残存チェックを忘れない。** 「直すべきもの」だけでなく「直してはいけないもの」も監査対象
- **許容パターンは Steering に集約する。** Skill側で例外判断を抱え込まない
確認方法: apply-decisions 実行後の状態で、チャットで「decision-log-audit を実行して」と入力。判断ログ末尾に「## 監査結果」セクションが追記され、各項目の判定 (✅ / ⚠️ / ❌) とサマリが記録されていればOK。
decision-log-audit を実行して
decision-log-auditスキルの読み込みが確認できます。
監査の実行を確認できます。
ログで監査の結果の記録が確認できます。
演習 2-7: 統合レポートSkill(integrated-report)を作成する
ファクトチェック済みの個別レポートを横断的に統合して、最終的な比較レポートを生成するSkillです。実行前に判断ログの監査結果ゲートを確認するため、未完了の項目があれば自動的に中止します。
.kiro/skills/integrated-report/SKILL.md を作成:
---
name: integrated-report
description: 個別の調査レポートを統合して比較レポートを生成する。統合レポート、比較レポート、最終レポート、final reportを作成するときに使用。
---
## 概要
`reports/*.md` の個別レポートを横断的に統合し、`output/final-report-{YYYY-MM-DD}.md` として比較レポートを生成する。
実行前に判断ログの監査結果ゲートを確認し、問題があれば実行を中止する。
## 入力
- `reports/*.md` (※ `_review/` 配下は除外)
- `reports/_review/decision-log-*.md` の最新ファイル(監査結果セクション付き)
- `assets/report-template.md`
## 出力
- `output/final-report-{YYYY-MM-DD}.md`
## 手順
### Step 1: 監査結果ゲートの確認
最新の `decision-log-*.md` を読み、以下を確認する:
- 「監査結果」セクションが存在する
- すべての監査項目が ✅ OK
- ⚠️ 保留項目がゼロ
- 「統合レポート生成ゲート」がすべて満たされている
満たさない場合は実行を中止し、未完了項目を一覧で提示してユーザーの判断を求める。
### Step 2: 個別レポートの読み込み
- `reports/` 配下のすべての `.md` を対象にする
- ※ `reports/_review/` 配下は対象外
- SWOT分析ファイル (`reports/*-swot.md`) は存在する場合のみ取り込む
### Step 3: 統合レポートの構造を組み立てる
`assets/report-template.md` のフォーマットに従って以下のセクションを生成する:
1. エグゼクティブサマリ(3〜5行)
2. 各サービスの概要
3. 比較表(基本情報・料金・コンテンツ)
4. (オプション) SWOT分析の総括 — `reports/*-swot.md` が存在する場合のみ
5. ユースケース別の推奨と示唆
### Step 4: 出典の継承
各個別レポートに記載されている出典URL・取得日を、統合レポートにもそのまま引き継ぐ。
**本工程で新しい事実主張を追加してはならない。** 統合は既存レポートの再構成までであり、再調査や新情報の付加は `re-investigate-and-judge` の責務である。
### Step 5: 保存
`output/final-report-{YYYY-MM-DD}.md` として保存する。
## 重要事項
- **本Skillは reports/*.md を一切修正しない。** 読み取り専用で利用する
- **本工程で新しい事実を加えない。** 出典のないまま新主張が混入するのを防ぐため
- **監査ゲートを必ず通過してから実行する。** ハルシネーション疑いがある状態の本文を統合してはならない
- **個別レポートの構造を尊重する。** 元レポートのセクション順序を大きく組み替えず、横断比較のセクションを追加する形で構成する
- **SWOT分析の取り扱い**: SWOT分析はオプションSkillで、`reports/*-swot.md` が存在しない場合は SWOT セクション自体を省略する。存在する場合は「SWOT分析の総括」セクションとして取り込む
統合レポートのテンプレートも作成します。
.kiro/skills/integrated-report/assets/report-template.md を作成:
# サブスクリプションサービス比較レポート ({YYYY-MM-DD})
## エグゼクティブサマリ
(3〜5行で本レポートの結論と要点を記載)
## 各サービスの概要
### サービスA
(各個別レポートから概要部分を要約)
### サービスB
### サービスC
## 比較表
### 基本情報
| 項目 | サービスA | サービスB | サービスC |
| ------------ | --------- | --------- | --------- |
| 開始年 | | | |
| 運営会社 | | | |
| 会員数 | | | |
| 市場シェア | | | |
### 料金プラン
| 項目 | サービスA | サービスB | サービスC |
| ---------------- | --------- | --------- | --------- |
| エントリープラン | | | |
| プレミアムプラン | | | |
| 無料トライアル | | | |
### コンテンツ・機能
| 項目 | サービスA | サービスB | サービスC |
| ---------------- | --------- | --------- | --------- |
| 総コンテンツ数 | | | |
| オリジナル作品 | | | |
| 最高画質 | | | |
| 同時視聴数 | | | |
<!-- SWOT分析ファイル (reports/*-swot.md) が存在する場合のみ以下を出力 -->
## SWOT分析の総括 (該当する場合)
(各SWOTファイルの要点を横断的にまとめる)
## ユースケース別の推奨と示唆
- **コスト重視のユーザー向け**: ...
- **オリジナル作品重視のユーザー向け**: ...
- **家族での視聴向け**: ...
- **その他のユースケース**: ...
## 出典一覧
| サービス | 主な出典URL | 取得日 |
| --------- | ----------- | ------ |
| サービスA | | |
| サービスB | | |
| サービスC | | |
---
> 本レポートは判断ログ駆動モデルに基づき自動生成されました。
> ファクトチェックの過程は `reports/_review/decision-log-{YYYY-MM-DD}.md` に記録されています。
確認方法: 判断ログに「監査結果」セクションがあり、すべて ✅ の状態で「integrated-report を実行して」と入力。output/final-report-YYYY-MM-DD.md が生成されればOK。逆に監査未完了の状態で実行すると、Step 1 のゲートで中止されることも確認してください。
integrated-report を実行して
本ハンズオンでは確認を割愛し、最後に実行を確認します。
プログレッシブ・ディスクロージャー
Skillsは賢い読み込み方式を採用しています:
- 普段 → スキルの「名前」と「説明」だけ記憶(軽い)
- 必要時 → 説明がリクエストに一致したら全手順を読み込む
- 実行時 →
references/やassets/のファイルも読み込む
大量のSkillを登録してもKiroの動作が重くなりません。
Skillsの責務分離 (本章のまとめ)
| Skill | 何をする | 何をしない | 位置づけ |
|---|---|---|---|
service-research |
調査して新規レポート作成 | 既存レポートの修正 | 必須 (Hook 1) |
swot-analysis |
SWOTマトリクスを作成 | 本文への直接書き込み | オプション |
source-check |
問題指摘とチェックリスト | 判断・修正 | 必須 (Hook 2) |
re-investigate-and-judge |
再調査と判断ログ生成 | 本文の修正 | 必須 (Hook 3) |
apply-decisions |
判断ログを本文に反映 | 自分で判断や調査を追加 | 必須 (Hook 3) |
decision-log-audit |
ハルシネーションと反映の監査 | 本文の修正 | 必須 (Hook 3) |
integrated-report |
個別レポートを統合 | 本文の修正・新規事実の付加 | 必須 (Hook 4) |
本文修正権限を持つのは apply-decisions だけ——これが本ハンズオンの不変条件です。
第3章: サブエージェント — 5サービスを5体のAIに同時に調べさせる
サブエージェントとは?
サブエージェントは、Kiroが複数のタスクを並列で実行したり、特定のタスクを専門のエージェントに委任する仕組みです(公式ドキュメント)。各サブエージェントは独立したコンテキストを持ち、メインエージェントのコンテキストを汚さずに作業を完了して結果を返します。
あなたの指示
│
メインエージェント(Kiro)
├──→ サブエージェントA(Netflix調査) ──→ 結果A ─┐
├──→ サブエージェントB(Disney+調査) ──→ 結果B ─┼──→ 統合結果
└──→ サブエージェントC(U-NEXT調査) ──→ 結果C ─┘
演習 3-1: カスタムサブエージェントを作成する
.kiro/agents/service-analyst.md を作成:
---
name: service-analyst
description: 調査・分析を行う専門エージェント。
tools: ["read", "write", "web"]
---
あなたは調査・分析アナリストです。
## あなたの役割
- 指定されたサービスの情報を網羅的に収集する
- 事実と推測を明確に区別する
- 必ず出典を記載する
## 調査の進め方
- Steeringのルール(フォーマット・保存先・出典)に従う
- service-researchスキルを使って調査を実施する
💡 サブエージェントはSteeringのルールを自動的に継承します(公式ドキュメントに「Steering files and MCP servers work in subagents exactly as they do in the main agent」と明記)。そのため、フォーマットや出典ルールをサブエージェント側に重複して書く必要はありません。
演習 3-2: 並列調査の動作確認
チャットから直接サブエージェントを並列起動して動作確認します。
チャットで以下を入力:
サブエージェントを使って、以下の3サービスを並列で調査してください。
1. Netflix
2. Disney+
3. U-NEXT
並列で調査を実施してることが確認できます。
第4章: Hooks — Skillsとサブエージェントを呼び出すタイミングを設定する
Hooksとは?
Hooksは、IDE上で特定のイベントが発生したときに、あらかじめ定義したエージェントアクションを自動実行する仕組みです(公式ドキュメント)。
第2章で「何をするか(手順)」をSkillsとして部品化し、第3章で「誰がやるか(並列実行の担い手)」をサブエージェントとして定義しました。この章ではHooksに「いつ実行するか(タイミング)」を任せます。Hooksの本体は「対応するSkillやサブエージェントを呼び出すだけ」の薄いラッパーになります。
主なトリガー
| トリガー | いつ発火するか | このハンズオンでの使い方 |
|---|---|---|
| 手動トリガー | ボタンを押したとき | ✅ メインで使う。4つのHookすべてこれ |
| ファイル保存 | ファイルを保存したとき | (本ハンズオンでは未使用、概念のみ紹介) |
| ファイル作成 | 新しいファイルを作ったとき | (本ハンズオンでは未使用) |
| エージェント完了 | Kiroが回答し終わったとき | (本ハンズオンでは未使用) |
設計するワークフロー
4つのHookを上から順番に押していくだけで、調査から統合レポート生成まで完結します。
[1] 調査開始 → サブエージェント x5 で並列調査 (service-research)
→ reports/{service}.md (5本)
[2] 出典チェック → source-check Skill
→ reports/_review/checklist-YYYY-MM-DD.md
[3] 再調査パイプライン → 3 Skill を順次起動
├─ re-investigate-and-judge (再調査+判断ログ生成)
├─ apply-decisions (本文修正)
└─ decision-log-audit (監査)
[4] 統合レポート生成 → integrated-report Skill (内部で監査ゲート確認)
→ output/final-report-YYYY-MM-DD.md
💡 ファイル名の順序制御: Kiroの AGENT HOOKS ビューはファイル名のアルファベット順で表示されます。
01-〜04-のプレフィックスを付けて、上から正しい順番に並ぶようにします。
演習 4-1: Hook 1 — 調査開始
第3章で定義した service-analyst サブエージェントを並列起動して、調査対象すべてを一気に調べさせるHookです。
.kiro/hooks/01-run-initial-research.kiro.hook を作成:
{
"name": "01_調査開始",
"version": "1.0.0",
"when": {
"type": "userTriggered"
},
"then": {
"type": "askAgent",
"prompt": "data/research-targets.md に記載されている調査対象すべてについて、service-analyst サブエージェントを並列起動して調査を実行してください。すべての調査が完了したら、生成されたファイル一覧と簡単なサマリを報告してください。"
}
}
本ハンズオンでは確認を割愛し、最後に実行を確認します。
演習 4-2: Hook 2 — 出典チェック実行
.kiro/hooks/02-run-source-check.kiro.hook を作成:
{
"name": "02_出典チェック実行",
"version": "1.0.0",
"when": { "type": "userTriggered" },
"then": {
"type": "askAgent",
"prompt": "source-check Skill を使って reports/ 配下のレポートをチェックし、reports/_review/ にチェックリストを生成してください。"
}
}
確認方法: KiroのAGENT HOOKSビューから「出典チェック実行」の再生ボタンを押します。
本ハンズオンでは確認を割愛し、最後に実行を確認します。
演習 4-3: Hook 3 — 再調査パイプライン実行
3つのSkillをボタン一つで順次起動し、再調査から本文修正、監査までを完全自動化します。
.kiro/hooks/03-run-investigate-pipeline.kiro.hook を作成:
{
"name": "03_再調査パイプライン実行",
"version": "1.0.0",
"when": { "type": "userTriggered" },
"then": {
"type": "askAgent",
"prompt": "以下を順次実行してください。各ステップが完了してから次に進むこと。\n\n1. re-investigate-and-judge Skill: reports/_review/ の最新チェックリストの各項目を再調査・判断し、decision-log を生成する (本文は修正しない)\n\n2. apply-decisions Skill: 生成された decision-log の ✅ 項目を reports/*.md 本文に反映する\n\n3. decision-log-audit Skill: decision-log と reports/*.md の整合性を監査し、結果を decision-log 末尾に追記する\n\n最後に、⚠️ 保留項目の有無と統合レポート生成可否をユーザーに報告してください。"
}
}
確認方法: AGENT HOOKSビューから「再調査パイプライン実行」の再生ボタンを押す。Chatに3 Skillの順次実行ログが流れ、最終的に判断ログに「適用結果」と「監査結果」の両方が追記されていればOK。reports/*.md の本文も自動修正されているはずです。
本ハンズオンでは確認を割愛し、最後に実行を確認します。
💡 このHookの強み: ボタン一つで「再調査 → 本文修正 → 監査」が完了します。通常は人間が判断ログを目視確認する必要はありません。ハルシネーションのチェックは
decision-log-auditが行います。ただし監査結果にNGや⚠️保留が残った場合は、人の判断が必要になります。
演習 4-4: Hook 4 — 統合レポート生成
integrated-report Skill を呼び出す薄いラッパーです。監査ゲートのチェックは Skill 側に委ねます。
.kiro/hooks/04-generate-integrated-report.kiro.hook を作成:
{
"name": "04_統合レポート生成",
"version": "1.0.0",
"when": { "type": "userTriggered" },
"then": {
"type": "askAgent",
"prompt": "integrated-report Skill を使って、reports/ 配下のレポートを統合し、output/final-report-{YYYY-MM-DD}.md を生成してください。実行前に判断ログの監査結果ゲートを確認すること。"
}
}
確認方法:
- 監査結果に問題がある状態で実行 → Skill 内部のゲート確認で中止され、残課題が提示される
- すべて ✅ + ⚠️ 保留ゼロの状態で実行 →
output/final-report-YYYY-MM-DD.mdが生成される
本ハンズオンでは確認を割愛し、最後に実行を確認します。
全ての設定が完了するとhooksのビューに下記の4つが追加されています。
Skills × Hooks の責務分離
| 観点 | Skills(第2章) | Hooks(第4章) |
|---|---|---|
| 担当 | 何をするか(手順・テンプレート) | いつするか(トリガー) |
| 再利用 | 他プロジェクトに持ち出し可能 | プロジェクト固有のオーケストレーション |
| 例 | apply-decisions / integrated-report | 04-generate-integrated-report |
| 変更頻度 | 手順を改善するときだけ | ワークフローを変えるときだけ |
Skill側がしっかり作られていれば、Hooksは「Skill呼び出し」の薄い1行プロンプトで済みます——この構造が後続の MCP 連携や統合演習でも効いてきます。
第5章: MCP — Tavily MCPを繋いでWeb検索を強化する(オプション)
MCPとは?
MCP(Model Context Protocol)は、Kiroに外部ツールを接続するためのプロトコルです(公式ドキュメント)。ビルトインWeb検索に加えて、専門的なデータソースやAPIをKiroから直接利用できるようになります。
Kiroの情報取得手段
| 手段 | 設定 | 用途 |
|---|---|---|
| ビルトインWeb検索 | 不要 | 一般的な情報収集(デフォルトで使える) |
| Tavily MCP |
.kiro/settings/mcp.json に追記 |
より高精度な検索・SPA(動的サイト)の取得 |
💡 MCPの設定がうまくいかない場合: この章はスキップしてもOKです。ビルトインWeb検索だけで第6章の統合演習は問題なく進められます。MCPは「あるとより便利」なオプションです。
演習 5-1: ビルトインWeb検索を体験する
追加設定なしで使えます。チャットで以下を入力するだけ:
Netflixの最新の料金プランを調べて
→ KiroがビルトインWeb検索を使って最新情報を取得し、回答してくれます。
演習 5-2: Tavily MCPを設定する
Tavilyは高精度なWeb検索APIで、通常のビルトインWeb検索では取得しにくいSPA(JavaScriptで動的に生成されるサイト)のコンテンツも取得できます。
ユーザー登録は別途必要です。
https://www.tavily.com/
💡 無料枠について: Tavilyには無料プランがあり、月あたりのリクエスト数に上限が設けられています。最新の無料枠の範囲や料金体系は公式サイト(https://www.tavily.com/)でご確認ください。本ハンズオンの動作確認程度であれば、無料枠の範囲内で十分試せます。
-
.kiro/settings/mcp.jsonを開く - 以下の内容に編集:
{
"mcpServers": {
"tavily-mcp": {
"command": "npx",
"args": [
"mcp-remote",
"https://mcp.tavily.com/mcp"
],
"autoApprove": [
"tavily_search"
]
}
}
}
- 保存してMCPサーバーが接続されることを確認
確認してみよう
Tavilyを使って、Disney+の料金プランと対応デバイスを調べて
Tavilyを使っていることが確認できます。
Tavilyが効くところ
第2章で作った re-investigate-and-judge Skill** です。このSkillはチェックリストの「事実検証項目(カテゴリB)」をWeb検索で再調査しますが、配信サービス各社の最新料金ページはSPAであることが多く、ビルトインWeb検索では取れないケースがあります。Tavilyを繋いでおくと、判断ログの「⚠️ 保留」が減り、自動修正の精度が上がります。
ビルトインWeb検索 vs Tavily MCP
| ビルトインWeb検索 | Tavily MCP | |
|---|---|---|
| 設定 | 不要 |
.kiro/settings/mcp.json に追記 |
| 通常のWebサイト | ✅ 取得可能 | ✅ 取得可能 |
| SPA(動的サイト) | ❌ 中身が取れないことがある | ✅ 取得可能 |
| 検索精度 | 標準 | より高精度(advanced検索対応) |
使い分けの指針
- 普段の調査 → ビルトインWeb検索で十分(設定不要)
- SPAサイトの情報が必要 / より精度の高い検索がしたい → Tavily MCP
カスタムサブエージェントでMCPを利用する
.kiro/agents/service-analyst.md を編集する
---
name: service-analyst
description: 調査・分析を行う専門エージェント。
tools: ["read", "write", "web","@tavily-mcp"]
---
あなたは調査・分析アナリストです。
## あなたの役割
- 指定されたサービスの情報を網羅的に収集する
- 事実と推測を明確に区別する
- 必ず出典を記載する
## 調査の進め方
- Steeringのルール(フォーマット・保存先・出典)に従う
- service-researchスキルを使って調査を実施する
toolsに@tavily-mcpを追加することサブエージェントからも利用できます。
第6章: 統合演習 — 4つのボタンで自動化された調査レポート生成を体験する
第1〜5章で個別に作成した設定を使ってみます。下の図は最終成果物の全体像です。
4つの Hook を順番に押すだけで自動化が完結します。Hook 3 だけが内部で3つの Skill を連鎖して呼びますが、ユーザーから見れば「ボタン1個」です。
全体のデータの流れ
実行ステップ
-
調査対象リスト確認 — Steering が
data/research-targets.mdを常に参照 - 5サービスを並列調査 — Hook 1(調査開始)の ▶ ボタン → サブエージェント x5 起動
-
(オプション)SWOT分析 — 「各サービスのSWOT分析をして」と依頼 →
swot-analysisSkill が自動活性化し、reports/{service}-swot.mdを生成 -
出典チェック — Hook 2(出典チェック実行)の ▶ ボタン →
source-checkSkill がチェックリストを生成 - 再調査パイプライン — Hook 3(再調査パイプライン実行)の ▶ ボタン → 3 Skill が順次起動し、本文修正+監査まで完了
-
統合レポート生成 — Hook 4(統合レポート生成)の ▶ ボタン →
integrated-reportSkill が監査ゲートを確認後、output/に最終レポートを出力
** ⚠️保留が残った場合は、その時点で人の判断が必要になります(その場合は判断ログを確認し、新しい日付で re-investigate-and-judge を再実行する運用になります)
最後まで実行できるとサマリーがアウトプットされます。
下記のようなレポートが作成されました。
各機能の役割分担
| 機能 | 担当 | 配置 |
|---|---|---|
| Steering | 保存先・命名規則・フォーマット・判断基準・ワークフロー遵守ポリシー | .kiro/steering/ |
| Skills | 調査・分析・指摘・再調査・修正・監査・統合の「手順」 | .kiro/skills/ |
| サブエージェント | 「誰が」やるか(並列実行) | .kiro/agents/ |
| Hooks | 「いつ」Skillを呼ぶか | .kiro/hooks/ |
| Web検索 + MCP | 「どこから」情報を取るか | ビルトイン + .kiro/settings/mcp.json
|
まとめ
Kiroの機能を使い調査タスクの実行が自動化されました。
今回の調査対象はサブスクリプションサービスでしたが、サブエージェントのプロンプトや判断基準を調整することで、汎用的な調査も実行できるようにするなどカスタマイズも可能です。
本文修正権限を apply-decisions Skill に集約し、ログ駆動モデルで履歴を残す設計は、自動化と監査可能性を両立する一つのモデルケースとして、社内のリサーチ業務や競合分析、市場調査など幅広く応用できるのではないでしょうか?
Claud Codeが流行っていますが、Kiroもカスタマイズによっては汎用的なタスクを実行できる可能性があると私は考えています。
Kiroだけでナレッジ検索システムを構築するハンズオンも公開しています！
ぜひ、ためしてください。