Kiro CLI で「日誌ひとつ」のタスク管理環境を構築した話 ── AWS builders.flash の記事を実践してみた

はじめに

AWS builders.flash に掲載された「AWS 社員が試した Kiro を用いたタスク管理法」（菅原太樹氏、津郷光明氏、岡本晋太朗氏著）は、AI コーディングアシスタント Kiro のステアリング機能と MCP 連携を活用し、メモの取得から整理、タスク管理、進捗共有までを一気通貫で効率化する手法を紹介しています。

本記事では、この記事に触発されて実際に自分の業務メモリポジトリを再構築した過程を記録します。元記事の三者三様のアプローチのうち、主に菅原氏の「1 日の仕事をすべて 1 つのデイリーファイルに集約する」アプローチをベースに、自分の環境に合わせてカスタマイズしました。

元記事のエッセンス

元記事で特に印象的だったのは、以下の 3 つの考え方です。

人間の認知負荷を下げ、シングルスレッド化することで、情報と意識の散在を防ぎます。

── 菅原太樹氏, 「AWS 社員が試した Kiro を用いたタスク管理法」

1 日の情報を 1 つのファイルに集約するという発想は、一見シンプルですが、「どのファイルに書けばいいか」という判断コストをゼロにする効果があります。

私にとってタスク管理ツールは「AI が使うデータベース」です。

── 菅原太樹氏, 同上

タスク管理ツールの UI を人間が操作するのではなく、AI に「今日やるべきことは？」と聞くだけでよいという発想の転換です。

必要な時に、必要な情報だけを、過不足なく得ることができます。

── 津郷光明氏, 同上

津郷氏のクエリベースの情報取得は、「メモは読むものではなく検索されるもの」という考え方を体現しています。

構築前の状態

私の業務メモリポジトリ my-memorandum は、カテゴリごとにフォルダを分けた構成でした。

my-memorandum/
├── 日誌/                   # 日々の作業メモ
├── プロジェクトA/           # 顧客案件
├── 環境整備/               # インフラ関連
├── 会社経営/               # 経営関連
├── 技術資料/               # 技術調査
├── 雑誌記事/               # 読書メモ
└── 管理/                   # 案件管理

問題は明確でした。

ファイルの置き場所に迷う ── 技術調査の結果はどこに置く？プロジェクトに関連する技術資料は？
日誌とプロジェクトメモが分断 ── 日誌に書いた内容をプロジェクトフォルダに転記する手間
タスクの抜け漏れ ── 日誌に「〜すること」と書いても、翌日には忘れている
Redmine との二重管理 ── git hook でチケットを自動登録していたが、対象が特定プロジェクト配下のみで形骸化

構築前と構築後の情報の流れを比較すると、変化が明確です。

段階的な構築

元記事の推奨に従い、「まずは 2 つのステアリングファイルから」始めて、段階的に環境を整えました。

Phase 1: ステアリングの導入

.kiro/steering/
├── about_me.md      # Always: 所属・担当領域
└── overall.md       # Always: ワークスペースの概要

about_me.md に自分の担当領域を、overall.md にディレクトリ構成とエージェントの役割を定義しました。これだけで Kiro の応答がワークスペースの文脈を理解したものに変わります。

元記事でも、全プロジェクトに適用する Global ステアリングと、ディレクトリごとの Project ステアリングの使い分けが紹介されています。私の場合、日本語応答やコーディング規約は既にグローバルステアリング（~/.kiro/steering/）に定義済みだったため、プロジェクトレベルでは about_me.md と overall.md の 2 つから始めました。

Phase 2: /start-day と /end-day

元記事の菅原氏のワークフローを参考に、Manual インクルージョンモードのステアリングを作成しました。

.kiro/steering/
├── start-day.md     # Manual: 朝の日誌自動生成
└── end-day.md       # Manual: 夕方の振り分け・タスク抽出

/start-day は前日の日誌から「明日の予定」と未完了タスクを引き継ぎ、Redmine の未完了チケットと Things の Today リストを取得して、当日の日誌ファイルを自動生成します。元記事では daily/YYYY-MM-DD.md 形式でしたが、既存の命名規則（YYYYMMDD_日誌.md）をそのまま活かしました。

生成される日誌のテンプレートは以下の通りです。

# 日誌 — YYYY年M月D日（曜日）

---

## 本日の予定
（前日の「明日の予定」と未完了タスクから転記）

### Redmine 未完了チケット
（未完了チケットを #ID: 件名 形式で列挙）

### Things Today
（Things の Today リストから取得したタスクを列挙）

## 作業内容

## メモ・気づき

## 明日の予定

/end-day は日誌の作業内容をプロジェクトフォルダに振り分け、タスクを抽出して Redmine・Things に連携します。日曜日には自動的に /weekly-report も実行し、1 週間分の日誌を集約した週次レポートを生成します。

Phase 3〜4: ディレクトリ構成の再編

元記事の推奨構成に倣い、プロジェクト別フォルダを project/ 配下に集約し、report/weekly/ を新設しました。

my-memorandum/
├── 日誌/                   # 全ファイルの入口
├── project/                # プロジェクト別（end-day で自動振り分け）
│   ├── プロジェクトA/
│   ├── プロジェクトB/
│   └── ...
├── 技術資料/               # 技術調査（end-day で自動振り分け）
├── 雑誌記事/               # 読書メモ（end-day で自動振り分け）
├── report/weekly/          # 週次レポート（weekly-report で自動生成）
├── 管理/                   # 案件管理・作業フロー
└── .kiro/
    ├── steering/           # ステアリング設定
    └── settings/           # MCP 設定

Phase 5: Redmine MCP 連携 + Things MCP 連携

ここが元記事の「タスク管理ツールは AI が使うデータベース」という考え方を実践した部分です。

Redmine 連携

従来は git の post-commit hook で Redmine にチケットを自動登録していましたが、以下の問題がありました。

対象が特定のプロジェクトフォルダのみ
箇条書きを無差別にチケット化（ノイズが多い）
一方向（登録のみ、状態確認・更新ができない）

mcp-redmine を導入し、双方向の連携に切り替えました。

/start-day → Redmine から未完了チケットを取得し、日誌の「本日の予定」に反映
/end-day → 日誌からタスクを抽出し、チケットの作成・更新を提案（承認制）

「提案→承認」のフローにしたのは、旧 hook の「無条件に登録」で痛い目を見た教訓です。

Things 連携

Things は macOS/iOS 向けの個人タスク管理アプリで、エリアやプロジェクトによる階層的な整理と、Today リストによる日次フォーカスが特徴です。

Redmine はプロジェクト単位の開発タスク管理に適していますが、日常の細かいタスク（買い物、事務手続き、連絡事項等）まで Redmine に入れるのは過剰です。そこで Things MCP に独自の修正を加えたものを使用して、個人タスク管理との連携も実現しました。

/start-day → Things の Today リストからタスクを取得し、日誌に反映
/end-day → 抽出タスクを Things のエリア/プロジェクトに登録（承認制）

Redmine と Things の使い分けは、日誌の見出しから自動判定されます。プロジェクト案件は Redmine、それ以外は Things という棲み分けです。

Phase 6: 日誌フォルダを全ファイルの入口にする

最終的に、元記事の菅原氏が示した「情報の流れは daily/ → project/ → report/」という設計をさらに推し進め、日中に作成するファイルはすべて 日誌/ に置くというルールにしました。

技術資料も、雑誌メモも、PDF も、すべて 日誌/YYYYMMDD_タイトル.拡張子 で格納します。/end-day 実行時にファイル名と内容から目的別フォルダに自動移動し、日誌本体にリンクを記録します。

これにより、人間が覚えるルールは「日誌/ に置く」の 1 つだけになりました。

冪等性の確保

ステアリングを設計する上で重要だったのが冪等性です。/start-day や /end-day を誤って 2 回実行しても、同じ結果になる必要があります。

操作	冪等性の仕組み
`/start-day` のファイル作成	既存ファイルがあれば Redmine セクションのみ更新
`/end-day` のファイル移動	移動済みファイルは `日誌/` に存在しないため自然にスキップ
`/end-day` の作業内容振り分け	`<!-- end-day: dispatched YYYY-MM-DD -->` マーカーで制御
`/end-day` の Redmine 連携	タスク行末の `(Redmine #ID)` で処理済みを判定
`/end-day` の Things 連携	タスク行末の `(Things)` で処理済みを判定

1 日の作業フロー

最終的な運用は以下の通りです。

時間帯	実行者	やること
朝	Kiro	`/start-day` で日誌を自動生成（前日の引き継ぎ + Redmine チケット + Things Today）
日中	人間	`日誌/` にメモと関連ファイルをすべて格納
夕方	Kiro	`/end-day` でファイル移動・作業内容振り分け・タスク抽出・Redmine/Things 連携
夕方	人間	Redmine・Things の操作を承認、「明日の予定」を記入
日曜	Kiro	`/end-day` 終了後に自動で `/weekly-report` を実行し週次レポート生成

まとめ

元記事のまとめで述べられている通り、「ステアリングファイルを数枚書くだけで、日々の面倒な作業が大幅に減」りました。

私の環境で特に効果が大きかったのは以下の 3 点です。

「日誌に置くだけ」ルール ── ファイルの分類を考える認知コストがゼロになった
Redmine MCP による双方向連携 ── タスク管理ツールの UI を開く頻度が激減した
冪等性のある /end-day ── 安心して何度でも実行できる

元記事のまとめで言うように、「どれが正解ということはなく、自分が一番楽に続けられる方法を選ぶ」ことが大切です。本記事が、Kiro を使ったタスク管理環境の構築を検討している方の参考になれば幸いです。

参考

菅原太樹, 津郷光明, 岡本晋太朗, 「AWS 社員が試した Kiro を用いたタスク管理法」, AWS builders.flash, 2026年4月
Kiro 公式ドキュメント — ステアリング
Kiro 公式ドキュメント — MCP 設定
mcp-redmine — Redmine MCP サーバー
Things MCP — Things MCP サーバー