Kiro CLI ヘッドレスモードを GitHub Actions で定期実行してBacklog業務を完全自動化した話

はじめに

Kiro CLI には --no-interactive フラグで動作するヘッドレスモードがあります。これは人間がインタラクティブに AI と会話する必要がなく、対話なしで任意の AI エージェントを稼働させることができる機能です。ターミナルで起動するときに求められるブラウザ認証は不要で、API キーをセットアップするだけで認証が通ります。

本記事では、Kiro CLI ヘッドレスモードを GitHub Actions 上で定期実行し、Backlog の課題振り分けを自動化した事例を紹介します。

全体像

[GitHub Actions (cron: 平日15分間隔)]
    │
    │  kiro-cli chat --no-interactive --trust-all-tools --agent ticket-dispatch
    │
    ▼
[Kiro CLI ヘッドレスモード]
    ├─ config/ai-dispatch-rule.md を読み取り（振り分けルール）
    ├─ output/result.json を読み取り（事前処理で生成された振り分け対象リスト）
    │
    ├─ MCP Server
    │     └─ backlog-mcp-server
    │           ├─ @backlog/count_issues  → 各メンバーの課題数取得
    │           ├─ @backlog/update_issue  → 担当者設定
    │           └─ @backlog/add_issue_comment → 署名コメント投稿
    │
    └─ 結果: 課題が適切な担当者に自動振り分けされる

背景: Kiro 導入前の運用課題

弊社の環境では、ユーザーから Backlog で課題を受け取り、サービスデスクのメンバーが手動でチケットを適切な担当者にディスパッチする運用を実施していました。

この運用には以下の課題がありました。

• 人的コスト ― 振り分け担当者が毎日数十件の課題を目視で確認し、担当者を判断・設定する必要がある
• 属人化 ― 振り分けルールが特定メンバーの頭の中にしかなく、不在時に滞留が発生する
• 対応遅延 ― 振り分けが行われるまで担当者が決まらず、着手が遅れる

これらを解消するため、Kiro CLI ヘッドレスモードを採用した自動振り分けの仕組みを導入しました。

Kiro CLI ヘッドレスモード

基本的な使い方

kiro-cli chat --no-interactive --trust-all-tools \
  --agent ticket-dispatch \
  "result.jsonを読み取り、needs_aiの課題についてAI振り分けを実行"

フラグ	役割
--no-interactive	対話プロンプトを表示せず、指示を実行して終了
--trust-all-tools	ツール実行時の確認プロンプトをスキップ（CI 向け）
--agent <name>	.kiro/agents/ に定義したカスタムエージェントを指定

通常の対話モードと同じ能力（ファイル読み書き、コマンド実行、MCP ツール呼び出し）をそのまま非対話で使えます。ローカルで動作確認したエージェントを、そのまま CI に持っていけるのが大きな利点です。

なぜ GitHub Actions と相性が良いのか

GitHub Actions は cron によるスケジュール実行が可能で、定期的な処理を自動起動するのに最適です。

仮に定期実行が必要なカスタムエージェントを作成したとして、ローカルで人間が毎回ターミナルを開いて実行するのでは結局運用コストがかかります。GitHub Actions でサーバーレスかつ自動定期実行できることで、この問題が解消されます。

また、GitHub Actions のランナーはある程度の使用量（プランによる）が無料で使え、任意の MCP Server をホストできるのも大きな利点です。

カスタムエージェントの設計

ツールの制限

エージェント定義の tools フィールドで、MCP Server が提供するツールのうち使用を許可するものだけを列挙しています。

"tools": [
    "read",
    "@backlog/count_issues",
    "@backlog/update_issue",
    "@backlog/add_issue_comment"
]

MCP Server 自体は課題の作成・削除なども提供しますが、エージェントに許可するのは振り分けに必要な操作のみ。これにより AI が意図しない破壊的操作を行うリスクを排除しています。

ディレクトリ構成

.kiro/
├── agents/ticket-dispatch.json   # エージェント定義
├── prompts/dispatch.md           # システムプロンプト
└── skills/ticket-dispatch/SKILL.md  # 実行手順・ルール

プロンプト / Skills 設計のポイント

ヘッドレスモードでは対話的な確認ができないため、プロンプトで「やっていいこと」と「やってはいけないこと」を厳密に定義する必要があります。

## ルール
- 対象プロジェクト: PROJECT_A のみ。他プロジェクトは操作禁止
- 許可される書き込み: update_issue（担当者のみ）と add_issue_comment（署名コメントのみ）
- 署名必須: コメントには必ず <!-- AUTO_DISPATCHED --> を含める

対話モードであれば「これでいいですか？」と確認できますが、ヘッドレスモードかつ --trust-all-tools で起動することで自律的に判断して実行します。そのため Skills 設計では以下の観点が重要となります。

• 操作対象の限定 ― プロジェクト・フィールドを明示的に制限
• 判断基準の明文化 ― 曖昧さを排除し、ルールファイルに従って決定論的に動作させる
• 完了条件の定義 ― 何をもって「処理完了」とするかを明確にする

振り分けロジックの例

エージェントは以下のロジックで担当者を決定します。

| 担当者 | 重み | 備考 |
|---|---|---|
| パートナー企業X | 3 | 内部3名のため重み3 |
| メンバーA | 1 | |
| メンバーB | 1 | |
| メンバーC | 1 | |

1. @backlog/count_issues で各メンバーの未完了課題数を取得
2. 課題数 ÷ 重み = 負荷スコア を算出
3. 負荷スコアが最も低いメンバーを選定
4. @backlog/update_issue で担当者を設定
5. @backlog/add_issue_comment で選定理由を署名コメントとして投稿

このロジック自体はコードではなく Markdown のルールファイルに記述されており、AI エージェントがそれを解釈して実行します。ルール変更はファイル編集だけで完結します。

GitHub Actions ワークフロー

name: Ticket Dispatch

on:
  schedule:
    - cron: '3/15 23 * * 0-4'    # JST 8:03-8:48（平日）
    - cron: '3/15 0-12 * * 1-5'  # JST 9:03-21:48（平日）
    - cron: '3 13 * * 1-5'       # JST 22:03（平日）
  workflow_dispatch:

jobs:
  dispatch:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Kiro CLI and MCP Server
        run: |
          curl -fsSL https://cli.kiro.dev/install | bash
          npm install -g backlog-mcp-server

      - name: Run AI dispatch
        run: |
          kiro-cli chat --no-interactive --trust-all-tools \
            --require-mcp-startup \
            --agent ticket-dispatch \
            "output/result.jsonを読み取り、needs_aiの課題についてAI振り分けを実行"
        env:
          KIRO_API_KEY: ${{ secrets.KIRO_API_KEY }}
          BACKLOG_DOMAIN: ${{ secrets.BACKLOG_DOMAIN }}
          BACKLOG_API_KEY: ${{ secrets.BACKLOG_API_KEY }}

ワークフロー設計のポイント

• cron オフセット ― 毎時 :03, :18, :33, :48 で実行し、GitHub Actions の混雑時間帯（毎時 :00）を回避
• --require-mcp-startup ― MCP Server の接続に失敗した場合に即座に失敗させる（CI 推奨フラグ）
• 必要な Secrets は 3 つだけ ― KIRO_API_KEY（app.kiro.dev で発行）、BACKLOG_DOMAIN、BACKLOG_API_KEY
• セットアップが軽量 ― Kiro CLI のインストールと MCP Server の npm install だけで準備完了

ヘッドレスモードの活用パターン

今回は課題振り分けに使いましたが、ヘッドレスモード × GitHub Actions の組み合わせは他にも応用できます。

ユースケース	エージェントの役割	MCP Server
課題振り分け（本記事）	ルールに基づき担当者を選定・設定	Backlog MCP Server
PR レビュー自動化	コード差分を読み、レビューコメントを投稿	GitHub MCP Server
定期レポート生成	データを集計し、Slack/メールで報告	各種 MCP Server

運用して分かったこと

良い点

• 開発→本番の移行が簡単 ― ローカルで kiro-cli chat --agent ticket-dispatch で対話テストし、動作確認できたらそのまま CI に載せるだけ
• ルール変更がコード変更不要 ― Markdown ファイルを編集してコミットするだけで次回実行から反映
• MCP Server のエコシステムが使える ― npm で公開されている MCP Server をそのまま利用可能
• 監査証跡 ― GitHub Actions のワークフローログから証跡やエラーハンドリングが容易

注意点

• プロンプトや Skills の精度が重要 ― ヘッドレスでは確認なしに実行されるため、ルール定義の曖昧さが直接ミスにつながる
• API キーの管理 ― Kiro API キーは app.kiro.dev で発行し、GitHub Secrets に格納
• GitHub Actions の cron の信頼性 ― GitHub 側の都合で定時に起動しないことがあるため、緊急性やリアルタイム性が求められる場合には向かない

まとめ

観点	本構成のアプローチ
AI 実行方式	Kiro CLI ヘッドレスモード (--no-interactive)
実行基盤	GitHub Actions (cron 定期実行)
外部サービス連携	MCP Server (Backlog MCP Server)
エージェント定義	.kiro/agents/ + プロンプト + スキルファイル
ルール管理	Markdown ファイルの編集のみで変更可能
テスト方法	ローカルで対話モード → CI で非対話モード

Kiro CLI のヘッドレスモードは「AI エージェントを CI/CD パイプラインに組み込む」ための実用的な手段です。GitHub Actions の cron と組み合わせれば、追加インフラなしに定期的な業務自動化が簡単に構築できます。

日常の運用業務において、定期的に実施していて AI 判断に代替できそうな業務があれば、今回の構成を参考にしていただければ幸いです。