👻
Kiro IDE v0.8 の新機能 Contextual Hooks を実際に使ってみた

2025/12/27に公開
 はじめに今回はKiro IDE v0.8で登場したContextual Hooksの中身を確認していきます。

前回の記事：Kiro IDE v0.8 の新機能 Web Tools / Subagents を試して分かったこと
詳細は公式Changelogを参照してください。

公式Changelog

 そもそもKiroのHooksとは？Hooksは、特定のイベントをトリガーにAIエージェントを自動実行する機能です。例えば、特定のソースコードを更新した際にREADME.mdも更新するといった処理を、自然言語ベースで実現できます。HooksはKiro IDEの初期リリースから存在する機能で、当初から主要な機能の1つとして注目されてきました。複雑なワークフローを簡素化する手段として提供されています。
Hooksの概要や活用例については、以下の記事が参考になります。

Amazon Web Serviceブログ「Kiro の AI エージェントフックで開発ワークフローを自動化する」

 v0.8でContextual Hooksが登場v0.7までは、以下の2種類・計4パターンのトリガーが提供されていました。
File Hooks：「ファイル操作をトリガーに実行」
File Created：ファイルの作成時
File Saved：ファイルの保存時
File Deleted：ファイルの削除時

Manual Hooks：「手動で実行」
Manual Trigger：手動実行

v0.8のアップデートで「Contextual Hooks」が新たに登場し、2つのトリガー（Prompt Submit、Agent Stop）が追加されました。
Contextual Hooks：「特定のコンテキスト状態に応じたトリガー」
Prompt Submit：プロンプト送信時に実行
Agent Stop：エージェント終了時に実行

つまり、ファイル操作だけでなく、プロンプト送信時やエージェント終了時にも任意の処理を追加できるようになりました。Kiro IDE v0.8では、以下のようにTriggerの選択肢として追加されています。

 セキュリティスキャナーの実行まずはセキュリティスキャナーの例です。これは公式ドキュメントでも紹介されている代表的なユースケースになります。エージェントの実行が完了したタイミングで、自動的にセキュリティスキャンを起動するよう設定します。TriggerにはAgent Stopを指定しており、エージェント処理が終了した直後にスキャンが実行される仕組みです。
公式ドキュメント: Security pre-commit scanner
{
  "enabled": true,
  "name": "Security Vulnerability Scanner",
  "description": "Reviews changed files for potential security issues including API keys, tokens, credentials, private keys, encryption keys, certificates, authentication tokens, session IDs, passwords, secrets in configuration files, IP addresses with sensitive data, hardcoded internal URLs, and database connection credentials. Provides specific risk analysis and secure alternatives.",
  "version": "1",
  "when": {
    "type": "agentStop"
  },
  "then": {
    "type": "askAgent",
    "prompt": "Review the changed files for potential security issues. Specifically look for: 1. API keys, tokens, or credentials in source code 2. Private keys or sensitive credentials 3. Encryption keys or certificates 4. Authentication tokens or session IDs 5. Passwords or secrets in configuration files 6. IP addresses containing sensitive data 7. Hardcoded internal URLs 8. Database connection credentials. For each issue found: 1. Highlight the specific security risk 2. Suggest a secure alternative approach 3. Recommend security best practices"
  }
}
プロンプトによるエージェント実行が完了すると、ワークスペース内のファイル（Hookの設定等で制限可能）を対象にセキュリティスキャンが自動的に実行されます。
これまでは、ファイルの保存や作成といったイベント発生時のみスキャンを実行する構成が中心でした。しかしContextual Hooksの登場により、外部リポジトリをCloneした直後や、エージェントによる大きな変更が加わった後なども含め、より実運用に近いタイミングでリアルタイムなチェックが可能になっています。
セキュリティレビューをエージェントの実行フローに自然に組み込める点は、v0.8における大きな進化と言えそうです。

 シェルコマンドアクションが可能Contextual Hooksについて調べていく中で、「プロンプト送信のたびに処理を実行すると、実行時間が長くなりCreditsの消費も増えてしまうのではないか。ユースケース次第では使いどころが限られるのでは？」という疑問がありました。
この疑問の一部を解消してくれる形で、v0.8で追加された2つのトリガー（Prompt Submit、Agent Stop）は、シェルコマンドアクションに対応しています。これらのトリガーでは、以下2種類のアクションを選択できます。
Agent Prompt：エージェントに自然言語で指示を出すアクション（Creditsを消費）
Shell Command：ローカル環境でコマンドを実行するアクション（Creditsを消費しない）
参考：Kiro公式ドキュメント：Shell Command action
公式ドキュメントでは、ユーザーのプロンプト操作ログをGrafana Lokiに送信する、というシェルコマンドアクションの例も紹介されています。
参考：Kiro公式ドキュメント：Centralized user prompt logging
シェルコマンドアクションはCreditsを消費せずに実行できるため、この例のように「操作ログの保存」や「外部システムへの通知」といった用途では、特に実用性が高そうです。

そこで次は、実際にGrafana Lokiを用意し、Kiro IDEからログを送信できるかを試してみたいと思います。

 （準備）Grafana Lokiをローカルで起動今回は検証用途として、できるだけシンプルな構成でGrafana Lokiをローカル起動します。

構成はGrafana + Lokiのみとし、Docker Composeで立ち上げます。

 作業用ディレクトリの作成作業ディレクトリは ./grafana_loki とします。
mkdir -p ./grafana_loki/config
cd ./grafana_loki/config

 Loki の設定ファイルまずはLokiの設定ファイルを作成します。ローカル検証向けのため、認証は無効化し、ファイルシステムストレージを利用します。
cat << EOF > loki-config.yaml
auth_enabled: false

server:
  http_listen_port: 3100

common:
  path_prefix: /loki
  storage:
    filesystem:
      chunks_directory: /loki/chunks
      rules_directory: /loki/rules
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory

schema_config:
  configs:
    - from: 2024-01-01
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h

limits_config:
  allow_structured_metadata: true
EOF

 Grafana / Loki の Docker Compose 設定続いて、GrafanaとLokiを起動するための docker-compose.yml を作成します。
cd ..

cat << EOF > docker-compose.yml
version: "3.9"

services:
  loki:
    image: grafana/loki:3.0.0
    container_name: loki
    ports:
      - "3100:3100"
    command: -config.file=/etc/loki/loki-config.yaml
    volumes:
      - ./config/loki-config.yaml:/etc/loki/loki-config.yaml:ro
      - loki-data:/loki
    restart: unless-stopped

  grafana:
    image: grafana/grafana:10.4.3
    container_name: grafana
    ports:
      - "3000:3000"
    environment:
      GF_SECURITY_ADMIN_PASSWORD: admin
    volumes:
      - grafana-data:/var/lib/grafana
    depends_on:
      - loki

volumes:
  loki-data:
  grafana-data:
EOF

 コンテナの起動以下のコマンドでコンテナを起動します。
docker compose up -d
curl http://localhost:3100/ready  # ready が返るまで待機
readyが返ってくれば、Lokiは正常に起動しています。

 Grafana の初期設定（ブラウザ）ブラウザで以下にアクセスします。
Grafana: http://localhost:3000
ユーザー名: admin
パスワード: admin

次に、データソースとしてLokiを追加します。
Data Source: Loki
URL: http://loki:3100

 テストログの送信Lokiが正しく動作しているか、簡単なテストログを送信します。
$ curl -X POST "http://localhost:3100/loki/api/v1/push" \
 -H "Content-Type: application/json" \
 --data-raw '{
   "streams": [
     {
       "stream": { "job": "test" },
       "values": [
         [ "'$(date +%s%N)'", "hello from loki" ]
       ]
     }
   ]
 }'

 ログの確認GrafanaのExplore画面で、{job="test"} を指定すると、先ほど送信したログが確認できます。
この状態で、次はKiro IDEのHooksを利用してLokiにログを送信していきます。

 チャット操作ログをGrafana Lokiに連携するここが今回の検証で最も苦戦したポイントでした。

結論から言うと、Prompt Submit（プロンプト送信）トリガーだけで、チャット入力された文字列をそのまま Grafana Lokiに送信することはできませんでした。

その背景には、以下のような仕様上の制約があると考えています。

 うまくいかなかった理由Kiro IDEで入力したチャット文字列は、環境変数などとして直接参照できません
公式ドキュメントでは ${USER_PROMPT} のような例が記載されていますが、実際にはこのような変数展開でチャット内容をそのまま扱うのは困難でした

LLM ログ（Kiro LLM - Prompt / Completion）を直接取得してLokiにPOSTするアプローチも試しました
しかし、ログがリアルタイムにファイルへ書き出される挙動には見えず、Hooksから安定して扱うことができませんでした（※ここは私のやり方が良くない可能性あり）


 方針転換：ローカルツールを介したチカラワザ構成そこで方針を切り替え、ローカルで完結する小さなツールを2つ作成するという、ややゴリ押しな方法を採用しました。

 作成するツールmain.go
引数で受け取った文字列をテキストファイル（.txt）に書き込む
ファイルは1日1回ローテーション

send-to-loki.go

main.goが出力した最新のテキストファイルを読み込む
ファイルの「最後の1行」をGrafana Lokiに送信


 Hooksの構成この2つのツールを以下のようにHooksから呼び出します。
Prompt Submitトリガー
アクション：Agent Prompt
内容：
「ユーザーがチャットしたテキストメッセージを引数として、ローカルのmain.goを実行する」ように指示


Agent Stopトリガー
アクション：Run Command
内容：

send-to-loki.goを実行



 ログ連携の全体フローこの構成により、チャット入力から Loki へのログ送信は次の流れになります。
ユーザーがKiro IDEのチャット欄にテキストメッセージを入力
Prompt Sumitトリガー
入力文字列を引数にしてmain.goを実行
ローカルのログファイルに追記

Kiroのエージェントが本来のタスクを実行
Agent Stopトリガー

send-to-loki.goを実行
ログファイルの最新行をGrafana Lokiに送信


 実行結果実際に動かしてみた結果が以下です。
Grafana Loki側では、チャットで入力した文字列がログとして正しく取り込まれていることを確認できました。
ログ連携の方法は決してスマートとは言えませんが、
Prompt Submit / Agent Stopという新しいトリガーを活用し
Shell Commandアクションを組み合わせることで
ユーザー操作ログを外部に集約する
という目的は達成できました。

一方で、Prompt SubmitトリガーではAgent Promptアクションを利用しているため、完全にCreditsを消費しない構成にはなっていません。HooksとShell Commandアクションの自由度の高さを感じる一方で、チャット入力そのものを安全かつ低コストで扱える、公式にサポートされた仕組みが今後提供されると嬉しいと感じた部分でもあります。

 おわりに今回の検証を通して、Kiro IDE v0.8は「試せる設計の幅が一段広がった」という印象を受けました。特にContextual Hooksは、使いどころを見極めることで、開発体験を静かに底上げしてくれる機能だと感じています。
まだ発展途上な部分も多いですが、今後のアップデート次第ではより自然に開発フローへ組み込める機能になっていくはずです。引き続き試行錯誤しながら、良さそうな使い方を探っていきたいと思います。
はじめに

そもそもKiroのHooksとは？

v0.8でContextual Hooksが登場

セキュリティスキャナーの実行

シェルコマンドアクションが可能

（準備）Grafana Lokiをローカルで起動

作業用ディレクトリの作成

Loki の設定ファイル

Grafana / Loki の Docker Compose 設定

コンテナの起動

Grafana の初期設定（ブラウザ）

テストログの送信

ログの確認

チャット操作ログをGrafana Lokiに連携する

うまくいかなかった理由

方針転換：ローカルツールを介したチカラワザ構成

作成するツール

Hooksの構成

ログ連携の全体フロー

実行結果

おわりに

Discussion
