🔥
Kiroがまだ使えない😭ので自作した！ #1
はじめに
話題のkiro使いたかったのですが、残念ながらwaiting list待ち。。いつになったら使えるのやら。ということで、待つのもダルいし作ろうというわけです。むしろゼロから作ることで新しいカスタマイズ性や新たな発見があるかもしれません。まずは使ってみないことには課題もわかりません。
今回の開発ターゲット
kiro自体は、
①requirements:要求仕様書(Eras)
②design:設計書
③tasks:設計書に基づくタスク
④code:タスクで定義されたコード
…
など複数の成果物をステップバイステップで作成します。
普段の自分の業務にもせっかくならすぐに使えるようにしたいので、まずはrequirements、degin、tasksをターゲットにします。私の普段の業務的には、要件定義のスタートとしてはユーザーヒアリングから始まります。なので、最初のインプットはユーザーヒアリングでメモした議事録としたいと思います。
今回の開発環境
・AzureOpenAI環境でo3のAPIを使用
・python 3.11
今回参考にした記事
勝手ながら記載しましたが、非常に参考になりました。
エージェントアーキテクチャ
超シンプルですが、ワークフロー型のエージェント構造で、ヒューマンフィードバックで人間の承認がない限り次に進まない仕様にしました。
エージェント定義（コード抜粋）
from __future__ import annotations
import argparse
import json
from typing import Dict, List, TypedDict
from pathlib import Path
from langgraph.graph import END, START, StateGraph
from setting import reasoning_llm, tech_const_path # LLMのインスタンスを定義した設定読み込み
from prompts import INSTRUCTION_FOR_ANALYST_AGENT, INSTRUCTION_FOR_REQUIREMENTS_AGENT, INSTRUCTION_FOR_DESIGN_AGENT, INSTRUCTION_FOR_TASK_AGENT # プロンプトの読み込み
llm = reasoning_llm # お好きなLLMのインスタンスに変更してください
###########################################################################
# ヘルパー関数
###########################################################################
# メッセージを文字列化
def msg_text(msg): # ChatMessage でも str でも文字列化
return msg.content if hasattr(msg, "content") else msg
# 技術的制約を読み込む
def load_tech_constraints(filepath: str) -> str:
with open(filepath, encoding="utf-8") as f:
return f.read().strip()
# markdown形式でステップごとに成果物を保存
def save_step_markdown(kind: str, content: str, outdir: Path = Path("output")):
"""成果物をステップごとにMarkdown保存（追記形式も可）"""
outdir.mkdir(exist_ok=True)
# ファイル名にkind名とタイムスタンプ付与（上書き防止したい場合）
#timestamp = datetime.now().strftime('%Y%m%d_%H%M%S')
fname = f"{kind}.md"
# fname = f"{kind}_{timestamp}.md"
(outdir / fname).write_text(content, encoding="utf-8")
# 承認ダイアログのヘルパー関数
def _approve_dialog(title: str, payload: str):
print(f"\n=== {title} ===\n{payload}\n")
resp = input("[a] 承認 / [e] 変更指示 > ").strip().lower()
if resp.startswith("e"):
instr = input("📝 変更指示を入力してください\n> ")
return "edit", instr
return ("approve", None)
# ステート定義
class DevState(TypedDict, total=False):
prompt: str # ヒアリング入力（生テキスト）
project_desc: str # 生成された詳細プロジェクト説明
spec: str # EARS 仕様
design: str # 設計ドキュメント
tasks: List[Dict] # タスク一覧
code_diff: str # 生成されたコード差分
test_report: str # テスト結果
event: str # 'save' / 'commit' 用フック
#######################################################################
# ドキュメント生成
#######################################################################
# ヒアリング内容からプロジェクト詳細化するエージェント
def describe_project(state: DevState) -> DevState:
"""ヒアリング内容を詳細なプロジェクト説明に展開"""
prompt = INSTRUCTION_FOR_ANALYST_AGENT.format(prompt=state['prompt'])
resp = llm.invoke(prompt)
state["project_desc"] = msg_text(resp)
save_step_markdown("project_description", f"# Project Description\n\n{state['project_desc']}")
return state
# プロジェクト内容から要求仕様を作るエージェント
def expand_spec(state: DevState) -> DevState:
"""プロジェクト説明 → EARS 要件仕様"""
prompt = INSTRUCTION_FOR_REQUIREMENTS_AGENT.format(prompt=state['prompt'], tech_constraints=state.get('tech_constraints', ''))
resp = llm.invoke(prompt)
state["spec"] = msg_text(resp)
save_step_markdown("requirements", f"# Requirements\n\n{state['spec']}")
return state
# 設計ドキュメントを生成するエージェント
def generate_design(state: DevState) -> DevState:
"""EARS 仕様 → 設計ドキュメント"""
prompt = INSTRUCTION_FOR_DESIGN_AGENT.format(spec=state['spec'], tech_constraints=state.get('tech_constraints', ''))
resp = llm.invoke(prompt)
state["design"] = msg_text(resp)
save_step_markdown("design", f"# Design\n\n{state['design']}")
return state
# タスクを計画するエージェント
def plan_tasks(state: DevState) -> DevState:
"""設計ドキュメント → タスク一覧"""
prompt = INSTRUCTION_FOR_TASK_AGENT.format(design=state['design'])
resp = llm.invoke(prompt)
state["tasks"] = [{"title": l.strip(), "done": False}
for l in msg_text(resp).splitlines() if l.strip()]
save_step_markdown("tasks", f"# Design Document\n\n{state['tasks']}")
return state
# コードを実装するエージェント
def implement(state: DevState) -> DevState:
task = next(t for t in state["tasks"] if not t["done"])
resp = llm.invoke(
f"You are the CODE agent. Implement the following task and output the result in unified diff format.\n\n{task['title']}"
)
state["code_diff"] = msg_text(resp)
task["done"] = True
return state
# テストを実行して結果を報告するエージェント
def test_and_verify(state: DevState):
resp = llm.invoke(
f"You are the TEST agent. Generate tests for the following diff and report the results as PASS/FAIL.\n\n{state['code_diff']}"
)
state["test_report"] = msg_text(resp)
return "fix" if "FAIL" in state["test_report"].upper() else state
# フックを実行するエージェント
def hook_runner(state: DevState):
if state.get("event") in {"save", "commit"}:
return test_and_verify(state)
return state
#######################################################################
# ヒューマンフィードバック
#######################################################################
def proj_desc_review(state: DevState):
# 1回分のレビューだけ行う
action, instr = _approve_dialog("PROJECT DESCRIPTION REVIEW", state["project_desc"])
if action == "approve":
save_step_markdown("project_description", f"# Project Description\n\n{state['project_desc']}")
state.pop("redo", None)
return state
# 編集指示がある場合、リライトして再レビュー用のフラグを立てて返す
state["project_desc"] = msg_text(llm.invoke(
f"""
Rewrite the following project description per instruction.
# Specifications
{state['project_desc']}
# Instruction
{instr}
# Guidelines
- Provide only the revised project description.
- Do not include any unnecessary information.
"""
))
save_step_markdown("project_description", f"# Project Description\n\n{state['project_desc']}")
state["redo"] = True
return state
def spec_review(state: DevState):
# 要件定義レビュー（編集/承認の都度呼び出しされる想定）
action, instr = _approve_dialog("SPEC REVIEW", state["spec"])
if action == "approve":
save_step_markdown("requirements", f"# Requirements\n\n{state['spec']}")
state.pop("redo", None) # フラグ除去で「次へ」
return state
# 編集指示ありの場合
state["spec"] = msg_text(llm.invoke(
f"""
Rewrite the following specification per instruction.
# specifications
{state['spec']}
# Instruction
{instr}
# Guidelines
- Provide only the revised specifications.
- Do not include any unnecessary information.
"""
))
save_step_markdown("requirements", f"# Requirements\n\n{state['spec']}")
state["redo"] = True # ループ用フラグON
return state
def design_review(state: DevState):
# 設計ドキュメントレビュー（編集/承認の都度呼び出しされる想定）
action, instr = _approve_dialog("DESIGN REVIEW", state["design"])
if action == "approve":
save_step_markdown("design", f"# Design\n\n{state['design']}")
state.pop("redo", None)
return state
state["design"] = msg_text(llm.invoke(
f"""
Rewrite the following design per instruction.
# design
{state['design']}
# Instruction
{instr}
# Guidelines
- Provide only the revised design document.
- Do not include any unnecessary information.
"""
))
save_step_markdown("design", f"# Design\n\n{state['design']}")
state["redo"] = True
return state
def task_review(state: DevState):
# タスク一覧レビュー（編集/承認の都度呼び出しされる想定）
view = "\n".join(f"- {t['title']}" for t in state["tasks"])
action, instr = _approve_dialog("TASK LIST REVIEW", view)
if action == "approve":
save_step_markdown("tasks", f"# Tasks\n\n{view}")
state.pop("redo", None)
return state
rewritten = llm.invoke(
f"Rewrite the task list per instruction (one task per line).\n\n{view}\n\nInstruction: {instr}"
)
state["tasks"] = [{"title": l.strip(), "done": False}
for l in msg_text(rewritten).splitlines() if l.strip()]
save_step_markdown("tasks", "# Tasks\n\n" + "\n".join(f"- {t['title']}" for t in state["tasks"]))
state["redo"] = True
return state
#######################################################
# グラフの定義
#######################################################
def build_graph() -> StateGraph:
kiro = StateGraph(DevState)
# 各ノードを追加
kiro.add_node("proj_desc", describe_project) # プロジェクト説明自動生成
kiro.add_node("proj_desc_rev", proj_desc_review) # プロジェクト説明レビュー
kiro.add_node("spec", expand_spec) # 要件定義自動生成
kiro.add_node("spec_rev", spec_review) # 要件定義レビュー
kiro.add_node("design", generate_design) # 設計自動生成
kiro.add_node("design_rev", design_review) # 設計レビュー
kiro.add_node("tasks", plan_tasks) # タスク自動生成
kiro.add_node("task_rev", task_review) # タスクリストレビュー
# ノード遷移を設定
kiro.add_edge(START, "proj_desc") # 開始→プロジェクト説明
kiro.add_edge("proj_desc", "proj_desc_rev") # 説明→レビュー
# 条件分岐（state["redo"]がTrueなら再レビュー、なければ次へ）
kiro.add_conditional_edges(
"proj_desc_rev",
lambda state: "redo" if state.get("redo") else "next",
{
"redo": "proj_desc_rev", # 再レビュー
"next": "spec", # 承認時のみ次へ
}
)
kiro.add_edge("spec", "spec_rev")
kiro.add_conditional_edges(
"spec_rev",
lambda state: "redo" if state.get("redo") else "next",
{
"redo": "spec_rev",
"next": "design",
}
)
kiro.add_edge("design", "design_rev")
kiro.add_conditional_edges(
"design_rev",
lambda state: "redo" if state.get("redo") else "next",
{
"redo": "design_rev",
"next": "tasks",
}
)
kiro.add_edge("tasks", "task_rev")
kiro.add_conditional_edges(
"task_rev",
lambda state: "redo" if state.get("redo") else "next",
{
"redo": "task_rev",
"next": END,
}
)
app = kiro.compile()
return app
※プロンプトについては現場のナレッジも一部含むため、変数として今回は隠してあります。悪しからず！
kiroと比べてユニークな仕様
プロジェクト具体化エージェント
ユーザーヒアリングの結果をそのまま入力したいところですが、プロジェクトの詳細がわかってない状態では、良い要件定義書は作れません。そのため、今回は本家kiroには存在しないプロジェクトの概要を詳細に説明するエージェントを最初に追加しました。こちらも人間のフィードバックによりリファインやリライトが可能な仕組みです。今回ユニークな仕様として、予想通りではありましたが一番効果がありました。
技術制約プロンプト
特に現場で使われる際に重視したのですが、開発エンジニアのバックボーンから得意な技術を事前にプロンプトに仕込んでおき、基本的にはそれに沿って設計してもらえれば比較的人間側もすんなり受け入れられると思ったので、要求仕様作成エージェントと設計書作成エージェントに技術制約プロンプトを仕込んでおきました。時々この制約から外れることもありますが、応答は正しいのでご愛嬌、笑
※後々kiroを見直したところ似たような設定がありました苦笑
入力と実際の成果物
入力:議事録
議事録
**日付**：2025年7月29日
**会議名**：発注業務デジタル化プロジェクト 要件定義会議
**出席者**：
- 佐藤（調達部）
- 木村（現場担当）
- 山本（システム部）
---
## 議題
現状の発注業務の困りごと整理とPowerApps活用による改善方針
---
### 発言・困りごと
- **佐藤**：「発注依頼がメールや紙の申請書で届くので、抜けや漏れが発生しやすいです。」
- **木村**：「現場で急な部品追加や変更が発生しても、発注内容の修正や承認が遅れがちです。」
- **佐藤**：「申請内容を一覧で確認したいが、毎回Excelに転記して管理しています。」
- **山本**：「今後はモバイルからも発注できる仕組みを作りたいので、PowerAppsを活用するのが良いと思います。」
- **木村**：「承認フローが分かりにくく、誰が止めているのか現場では分かりません。」
- **佐藤**：「申請データの履歴を後から検索したいが、今は過去メールを探している状態です。」
- **山本**：「紙の申請書だと申請漏れや誤記も多く、業務効率が上がりません。」
---
### 現状の課題まとめ
1. **発注依頼が紙・メールでバラバラに管理されている**
2. **申請内容の修正や追加時に、情報がリアルタイムで共有されない**
3. **承認プロセスが見えづらく、進捗が分からない**
4. **データの転記や集計に手間がかかる**
5. **履歴検索・追跡ができず、情報の抜け漏れが発生**
6. **モバイル対応が未実現で現場からの申請が不便**
7. **申請ミス・漏れ・誤記が多発している**
---
### 次回アクション
- エージェントが困りごとから要件案を整理
- PowerApps活用案の初期ドラフト作成（システム部）
- 次回ミーティングで要件レビュー
---
入力：技術制約プロンプト
We must use only the following technology:
- Frontend: PowerApps
- Backend: Power Automate
- Data Store: SharePoint
- Authentication: Azure AD
- External APIs: 承認システム
- BI: Power BI
- DevOps:Any technology can be used
- Security:Any technology can be used
- Monitoring:Any technology can be used
成果物：project description
こういったまとめは結局のところ要約なのですが、人間も改めて見直すことで、振り返りになり考えが整理されやすいのがメリットです。
## 1. 目的
- 発注依頼から承認・履歴管理までを PowerApps および Power Automate でデジタル化し、抜け漏れのない迅速な発注業務を実現する
- 現場（モバイル）とオフィス（PC）の両方で同一の業務フローを運用し、情報共有と進捗可視化を徹底する
- 転記作業の廃止とデータ活用基盤（検索・集計）の整備により、調達部・現場双方の生産性を向上させる
## 2. 背景
- 現在、発注依頼は紙・メール・Excel など複数チャネルで行われており、情報の散逸・誤記・申請漏れが頻発している
- 承認プロセスは口頭・メールでの確認に頼っており、停滞箇所や責任者が把握しにくい
- 過去データはメールボックスを検索するしか手段がなく、履歴追跡や集計に時間がかかる
- モバイル環境での入力手段がなく、現場からのタイムリーな申請・修正が困難
## 3. ステークホルダー
- 佐藤（調達部）
- 発注依頼受付・発注書発行・納期管理
- 木村（現場担当）
- 部品追加・変更の申請、進捗確認
- 山本（システム部）
- Power Platform 導入、システム運用保守
- 承認者（部門長、購買課長 など）
- 発注金額・内容の承認
- 経営層
- 購買コストおよび業務効率のモニタリング
## 4. 業務フロー概要
1. 現場・オフィスいずれかから PowerApps で発注依頼を登録
- 必須項目チェック、添付ファイル（図面・見積）アップロード
2. 自動で承認ルートを生成し Power Automate へ連携
- 金額や部品カテゴリによる動的ルーティング
3. 承認者が PowerApps または Teams 通知からワンクリック承認／差戻し
- 差戻し理由は必須入力
4. 調達部が承認済み依頼を基に発注書を発行（PDF 出力／社内システム連携）
5. 納期確定後、納期情報を PowerApps で更新
- 関係者に自動通知
6. 全データは Dataverse（または SharePoint リスト）へ蓄積
- 検索・フィルタ・グラフ表示機能を提供
7. 履歴・KPI レポートを Power BI で可視化し、改善サイクルを回す
## 5. システム範囲
- 対象業務
- 発注依頼入力、修正、承認、発注書発行、履歴検索、レポート
- 対象ユーザー
- 約120 名（現場 70 名、調達部 20 名、承認者 30 名）
- 使用プラットフォーム
- Microsoft PowerApps（Canvas App）
- Microsoft Power Automate（承認フロー）
- Dataverse または SharePoint リスト（マスタ・取引データ管理）
- Power BI（分析・可視化）
- 連携対象
- Office 365 Outlook（通知メール）
- Teams（承認通知カード）
- 既存基幹システム（発注書番号・仕入先マスタの参照） ※API 連携を検討
- 非対象範囲
- 実際の購買契約・支払処理（財務システム側で継続）
- 部品在庫管理（別システムで管理）
## 6. 成功指標 (KPI)
- 発注依頼の入力不備率：現状 15% → 3% 以下
- 承認リードタイム：平均 2.5 日 → 0.5 日
- 手作業転記時間：月 30 時間 → 0 時間
- 発注進捗可視化率：100%（全案件がステータス表示可能）
- モバイル利用率：現場ユーザーの 90% が月 1 回以上ログイン
- ユーザー満足度アンケート：平均 3.5 → 4.5（5 段階評価）
## 7. 想定制約・前提
- PowerApps／Power Automate／Power BI のライセンスは全ユーザー分を会社負担で確保済み
- 2025 年 12 月末までに本番稼働し、旧プロセスを完全停止する
- 既存基幹システムは REST API を提供しており、購買マスタ連携が可能である
- セキュリティ要件として社外ネットワークからのアクセスは MFA（多要素認証）必須
- モバイル端末は iOS 14 以降／Android 11 以降をサポート対象とする
- ワークフロー分岐規則（承認階層）は調達部が維持管理し、システム部は設定のみを行う
- 導入後 3 か月間はシステム部が操作サポート窓口を設置し、その後は通常運用へ移行する
成果物：requiremnts
本家kiroと遜色ないのでは！ERAS形式で整理してくれます。
Requirements Specification
1. Overview
本システムは、PowerApps＋SharePoint Online＋Power Automate を基盤とした発注申請デジタル化アプリケーションである。紙・メールで分散している発注依頼を一元管理し、 モバイル環境からの申請、リアルタイムな承認状況可視化、履歴検索の容易化により業務効率と統制を向上させる。主な利用者は調達部（申請／承認）、現場担当（申請／修正）、システム部（運用管理）であり、認証は Azure AD を利用することを前提とする。
2. Requirement 1: ロールベース認証とアクセス制御
User Story: As a システム管理者, I want to assign permissions by role so that each user can only see and operate functions appropriate to their responsibilities.
Acceptance Criteria
・WHEN ユーザがサインインする THEN Azure AD によるシングルサインオンが行われ、ユーザのロールが自動取得される
・WHEN 調達部ロールのユーザが申請一覧を開く THEN すべての申請データを閲覧・承認できる
・WHEN 現場担当ロールのユーザが申請一覧を開く THEN 自身が起案した申請のみ閲覧・編集できる
・WHEN システム管理者ロールのユーザが管理メニューにアクセスする THEN マスタ管理・監査ログを操作できる
Success Criteria
不正アクセス件数 0 件／年
Requirement 2: 発注申請入力フォーム
User Story: As a 現場担当, I want to enter order details via a guided form so that omission and typo are minimized.
Acceptance Criteria
・WHEN フォームを開く THEN 必須項目が★印で表示される
・WHEN 必須項目が未入力のまま送信を押下する THEN エラーメッセージが表示され送信できない
・WHEN 部品マスタから品番を検索選択する THEN 品名と単価が自動入力される
・WHEN フォーム送信完了後 THEN 申請番号が自動採番されユーザに通知される
Requirement 3: モバイル対応UI
User Story: As a 現場担当, I want to submit and approve orders from my smartphone so that I can act even when away from my desk.
Acceptance Criteria
・WHEN スマートフォンでアプリを起動する THEN レスポンシブレイアウトでフォームが表示される
・WHEN スマートフォンで部品検索を行う THEN 3 秒以内に検索結果が表示される
・WHEN 電波圏外で入力中に通信が切れた THEN 下書きがローカルに自動保存され通信復帰後に同期される
Requirement 4: 添付ファイル・写真アップロード
User Story: As a 現場担当, I want to attach specification sheets or site photos so that approvers can understand the context.
Acceptance Criteria
・WHEN 添付ボタンを押下する THEN カメラ起動またはファイル選択ダイアログが表示される
・WHEN 10MB を超えるファイルをアップロードする THEN サイズ超過のエラーメッセージが出る
・WHEN 添付完了後 THEN サムネイルがフォーム内に表示される
Requirement 5: 発注申請一時保存・下書き機能
User Story: As a 現場担当, I want to save drafts so that I can complete the form later without losing input.
Acceptance Criteria
・WHEN 「下書き保存」を押下する THEN 入力内容が下書きテーブルに保存される
・WHEN 再度アプリを開く THEN 未送信の下書きが一覧に表示され編集できる
・WHEN 下書きを送信した場合 THEN 下書きレコードは自動で削除される
Requirement 6: 申請内容リアルタイム同期
User Story: As an 承認者, I want to view the latest application data instantly so that I base my decision on current information.
Acceptance Criteria
・WHEN 起案者が申請を送信する THEN 5 秒以内に承認者の一覧画面に新規レコードが反映される
・WHEN 申請が修正された THEN 承認者の画面がリアルタイムにリフレッシュされる
Success Criteria
同期遅延 5 秒以内 95％ 以上
Requirement 7: 承認ワークフロー（段階承認）
User Story: As a 調達部承認者, I want a multi-stage approval flow so that corporate policy is met.
Acceptance Criteria
・WHEN 申請が送信される THEN Power Automate が第一承認者へ承認依頼を通知する
・WHEN 第一承認者が承認すると THEN システムが第二承認者へ自動で回付する
・WHEN いずれかの承認者が却下すると THEN フローが停止し起案者へ却下通知が送信される
Requirement 8: 承認ステータス可視化ダッシュボード
User Story: As a 起案者, I want to know who is currently holding my request so that I can follow up quickly.
Acceptance Criteria
・WHEN 起案者がダッシュボードを開く THEN 各申請の現在ステータスと担当者名が一覧表示される
・WHEN 承認者がステータスを更新すると THEN ダッシュボードが自動更新される
・WHEN フィルタで「保留中」を選択すると THEN 保留中レコードのみ表示される
Requirement 9: 進捗通知とリマインド
User Story: As a 承認者, I want automatic reminders so that I do not overlook pending tasks.
Acceptance Criteria
・WHEN 承認依頼が届いてから24時間経過しても操作が無い THEN Power Automate がリマインドメールを送信する
・WHEN 申請が最終承認された THEN 起案者と調達部に完了通知が届く
・WHEN 申請が却下された THEN 起案者へ却下理由付きメールが送信される
Requirement 10: 申請履歴検索・フィルタ
User Story: As a 調達部員, I want to search historical data by keyword and date so that I can quickly reference past orders.
Acceptance Criteria
・WHEN キーワードと期間を入力して検索ボタンを押す THEN 3 秒以内に結果が表示される
・WHEN 「Excel 出力」ボタンを押下する THEN 検索結果がフィルタ条件付きで.xlsx ファイルとしてダウンロードされる
Requirement 11: データエクスポート（Excel）
User Story: As a 調達部員, I want to download data into Excel so that I can perform additional analysis.
Acceptance Criteria
・WHEN エクスポート対象を選択し「エクスポート」ボタンを押下する THEN .xlsx ファイルが作成される
・WHEN ダウンロードしたファイルを開く THEN 文字化けや列欠落がない
Requirement 12: 変更申請・差戻し機能
User Story: As a 起案者, I want to modify a submitted request when site conditions change so that order accuracy is maintained.
Acceptance Criteria
・WHEN 承認フローが進行中に起案者が「変更依頼」ボタンを押下する THEN 承認フローが一時停止する
・WHEN 変更内容を再送信する THEN 承認フローが最初から再開される
・WHEN 承認者が「差戻し」を選択する THEN 起案者のステータスが「差戻し中」に更新され編集可能になる
Requirement 13: システム管理者用マスタメンテナンス
User Story: As a システム管理者, I want to maintain master data such as 部品 and 取引先 so that users always reference the latest information.
Acceptance Criteria
・WHEN 管理者がマスタ管理画面を開く THEN CRUD 操作用の一覧が表示される
・WHEN 新規マスタを追加して保存する THEN 重複キーがある場合はエラーメッセージが表示される
・WHEN マスタを更新すると THEN フロントエンドの検索結果に即時反映される
Requirement 14: 監査ログ
User Story: As an 内部監査担当, I want to trace who changed what and when so that compliance requirements are met.
Acceptance Criteria
・WHEN ユーザが申請を作成・更新・承認・却下・削除する THEN 操作日時・ユーザID・操作種別がログに記録される
・WHEN 監査ログ閲覧画面を開く THEN ロールが「システム管理者」の場合のみ閲覧できる
Success Criteria
ログ欠損率 0％
Requirement 15: パフォーマンス・可用性要件
User Story: As a 全ユーザ, I want stable performance so that daily operations are not interrupted.
Acceptance Criteria
・WHEN 平日日中（9-18 時）に画面遷移する THEN 応答時間が 3 秒以内である
・WHEN PowerApps または SharePoint Online が障害で 1 時間以上停止した THEN システム管理者へ自動通知が送信される
Success Criteria
月間稼働率 99.5％ 以上
Requirement 16: 多拠点対応タイムゾーン設定（Assumption: SharePoint Online がタイムゾーン自動変換 API を提供）
User Story: As a 海外拠点ユーザ, I want timestamps to display in my local time so that I clearly understand deadlines.
Acceptance Criteria
・WHEN ログイン時にブラウザのロケールが取得される THEN 申請画面の日時フィールドがローカルタイムで表示される
・WHEN 申請を保存する THEN サーバー側には UTC で格納される
Requirement 17: SLA アラートしきい値管理
User Story: As a システム管理者, I want to configure SLA thresholds so that reminder intervals can be changed without code modification.
Acceptance Criteria
・WHEN 管理画面で「リマインド間隔」を変更し保存する THEN 直ちに新しい値で Power Automate が実行される
・WHEN 不正値（例：負数）を入力して保存する THEN バリデーションエラーが表示される
Requirement 18: アクセシビリティ対応
User Story: As a 色覚多様性ユーザ, I want clear color contrast so that information is readable.
Acceptance Criteria
・WHEN WCAG 2.1 AA チェッカーツールを実行する THEN コントラスト比エラーが 0 である
・WHEN キーボードのみで操作する THEN すべてのインタラクティブ要素にフォーカスアウトラインが表示される
Requirement 19: バックアップ／リストア運用手順
User Story: As a システム管理者, I want standard backup procedures so that data can be restored after incidents.
Acceptance Criteria
・WHEN SharePoint Online のサイトコレクションが毎晩バックアップされる THEN 保持期間は 30 日となる
・WHEN リストア依頼が発生する THEN 4 時間以内に最新バックアップから復旧できる
Requirement 20: ヘルプ＆FAQコンテンツ
User Story: As a 新規利用者, I want in-app help so that I can resolve minor questions myself.
Acceptance Criteria
・WHEN 画面右上の「？」アイコンをクリックする THEN 操作マニュアル PDF へのリンクが表示される
・WHEN キーワード検索で「承認フロー」と入力する THEN 関連 FAQ が10件以内に表示される
成果物：design
こちらは非常に長いので抜粋としています。
=== DESIGN REVIEW ===
# 発注申請デジタル化アプリケーション
技術設計書（Ver.1.0）
作成日: 2024-xx-xx
---
## 1. システム概要 / Purpose
本システムは PowerApps・SharePoint Online・Power Automate を基盤とし、紙・メールで分散していた発注申請プロセスをワンストップで電子化する。
• 発注申請入力、承認ワークフロー、進捗可視化をモバイル／PC 双方で提供
• Azure AD によるロールベース認証と監査ログで内部統制を強化
• リアルタイム同期・自動リマインダーによりリードタイムを短縮し SLA を順守
主要利用者
1. 現場担当（起案・修正）
2. 調達部（承認・検索・輸出）
3. システム管理者（マスタ保守・監査・運用）
4. 内部監査担当（監査ログ閲覧）
5. 海外拠点ユーザ（多タイムゾーン対応）
---
## 2. 全体アーキテクチャ
設計書の中には下記のようなアプリとステークホルダーのやり取りが分かりやすく作成もされています。自分で作ると無駄に時間かかるのでうれしいかも。。（笑）
成果物：tasks
- # Implementation Plan
- ※English is used as the main language; Japanese words appear where they are proper nouns or requirement IDs (全角).
- ---
- ## Phase 0: Project Initiation & Governance
- *Target: kick-off, roles, baseline schedule, Dev/Test/Prod tenants ready*
- - [ ] 0.1 Kick-off workshop with all stakeholders
- - Align scope, priority, success criteria (Req.1-20).
- - [ ] 0.2 Confirm licensing & budgets (Power Apps, Power Automate, Azure Functions Premium).
- - [ ] 0.3 Define RACI & communication plan (Teams チャネル, weekly sync).
- - [ ] 0.4 Create central repo & branching policy in GitHub (`main / develop / release/*`).
- ---
- ## Phase 1: Environment / Platform Setup
- ### 1-A Microsoft 365 & SharePoint
- - [ ] 1.1 Provision SharePoint Site Collection `OrderReq` (★ foundation for all lists).
- - [ ] 1.2 Create Azure AD Security Groups
- (`OrderReq-FieldUser`, `OrderReq-Procurement`, `OrderReq-SysAdmin`, `OrderReq-Auditor`).
- - [ ] 1.3 Configure site permissions—do NOT break inheritance; validate Read / Contribute / Owner.
- - [ ] 1.4 Enable site-level webhooks (App-only registration) for future Flows.
- ### 1-B Azure Resources (Bicep IaC)
- - [ ] 1.5 Deploy Azure Function App (Node .js 20, Premium P1V3, VNET integration).
- - [ ] 1.6 Deploy Application Insights, Key Vault, Log Analytics workspace.
- - [ ] 1.7 Configure Managed Identity & Key Vault secrets (SPO ClientId/Secret, instrumentation key).
- - [ ] 1.8 Set up Azure Front Door (optional, DDoS/Geo-routing).
- ### 1-C CI/CD Pipeline
- - [ ] 1.9 Create GitHub Actions workflow
- - build & deploy Functions with OIDC
- - export/import Power Platform Solutions
- - run Jest & Pester tests.
- ---
- ## Phase 2: SharePoint Data Layer
- - [ ] 2.1 Create Lists
- • `Orders` • `OrderDrafts` • `PartsMaster` • `Vendors` • `Config` • `AuditLogs`.
- - [ ] 2.2 Define columns, content types, validation formulas exactly per Section 3.
- - [ ] 2.3 Create Document Library `OrderAttachments` with automatic folder creation by OrderID.
- - [ ] 2.4 Apply default JSON column formatting (status badges, amount color).
- - [ ] 2.5 Seed `Config` list default values (`ReminderHours`=24, `SyncIntervalSec`=5).
- - [ ] 2.6 Upload PowerShell backup script to Azure Automation (Req.19).
- ---
- ## Phase 3: Azure Functions API
- - [ ] 3.1 Scaffolding of Function project (`/orders/search`, `/orders/export`, `/audit/write`).
- - [ ] 3.2 Implement token validation (MSAL, `api://{func-app-id}/user_impersonation`).
- - [ ] 3.3 Implement `/orders/search` with SPO Search API + composite index (≤3 sec SLA).
- - [ ] 3.4 Implement `/orders/export` (generate XLSX, split >1000 rows, ZIP).
- - [ ] 3.5 Implement `/audit/write` (dual-write to `AuditLogs` list & App Insights).
- - [ ] 3.6 Unit tests with Jest; code coverage ≥80 %.
- - [ ] 3.7 Configure Application Insights telemetry & structured logging.
- ---
- ## Phase 4: Power Apps Canvas App
- ### 4-A Core Framework
- - [ ] 4.1 Create unmanaged solution `OrderReqApp` in Dev environment.
- - [ ] 4.2 Implement authentication & role detection (`User().Email` + Graph groups).
- - [ ] 4.3 Build global components (header, toast, offline banner).
- - [ ] 4.4 Implement offline caching (`SaveData/LoadData` for drafts).
- ### 4-B Screens
- - [ ] 4.5 SCR01 ログイン/ホーム – card menu by role.
- - [ ] 4.6 SCR02 申請一覧 – Gallery with delegable filter.
- - [ ] 4.7 SCR03 申請入力 – Form, details repeater (max 20), auto-sum, mandatory ★.
- - [ ] 4.8 SCR04 承認タスク – Adaptive Card launcher + Approve/Reject.
- - [ ] 4.9 SCR05 ダッシュボード – KPI tiles, progress bar.
- - [ ] 4.10 SCR06 マスタ管理 – DataTable w/ duplicate check.
- - [ ] 4.11 SCR07 監査ログ – Log viewer, export button.
- ### 4-C Logic & Validation
- - [ ] 4.12 Power FX validation formulas (Req.2, size check 10 MB, time-zone handling).
- - [ ] 4.13 Implement auto-number display `"PO-"&Text(ThisItem.ID,"00000")`.
- - [ ] 4.14 Error handling with `IfError()` + `/audit/write` fallback.
- ---
- ## Phase 5: Power Automate Flows
- - [ ] 5.1 Flow `OrderApproval`
- - Trigger on `Orders.Status="Pending"`
- - Stage1 / Stage2 approval, branching, update SPO.
- - [ ] 5.2 Flow `Reminder24h` (Delay Until, read `Config.ReminderHours`).
- - [ ] 5.3 Flow `RealTimeSync` – SPO webhook to push update to App (Req.6).
- - [ ] 5.4 Flow `OpsAlert` – on any flow failure send Teams notification.
- - [ ] 5.5 Flow `ExportLargeRuns` – orchestrate `/orders/export` & e-mail ZIP.
- ---
- ## Phase 6: Monitoring & Observability
- - [ ] 6.1 Configure App Insights dashboards (Function p95 latency, failure %).
- - [ ] 6.2 Create SPO Health Monitor Logic App and Pingdom synthetic test.
- - [ ] 6.3 Build Teams Ops channel webhook, connect to Alerts (≥1 h outage).
- ---
- ## Phase 7: Testing
- - [ ] 7.1 Unit tests (Functions Jest, Power FX formulas).
- - [ ] 7.2 Integration tests (Flow Test API, SPO to Function round-trip).
- - [ ] 7.3 Mobile offline/online scenario tests.
- - [ ] 7.4 Security test—role-based access, blocked extensions.
- - [ ] 7.5 Performance test—50 RPS, p95 < 2 s (Req.15).
- - [ ] 7.6 UAT with representative Field / Procurement / Auditor users.
- - [ ] 7.7 Sign-off & defect triage.
- ---
- ## Phase 8: Deployment & Release
- - [ ] 8.1 Package unmanaged solution → managed; export.
- - [ ] 8.2 Promote to Test tenant via GitHub Actions environment gate.
- - [ ] 8.3 Smoke test & regression in Test.
- - [ ] 8.4 Promote to Prod; run post-deployment checklist (webhooks, secrets).
- - [ ] 8.5 Tag release in Git (`v1.0.0`).
- ---
- ## Phase 9: Documentation & Training
- - [ ] 9.1 End-user manuals (PDF) linked from Power Apps `?` button.
- - [ ] 9.2 Admin runbook (backup, restore, config changes).
- - [ ] 9.3 FAQ SharePoint page + search web-part (Req.20).
- - [ ] 9.4 Live training sessions & recorded video.
- ---
- ## Phase 10: Hyper-care & Handover
- - [ ] 10.1 2-week hyper-care defect support window.
- - [ ] 10.2 Transition to Ops team; review monitoring dashboards.
- - [ ] 10.3 Close-out report & lessons learned.
- ---
- ## Progress Tracking
- - Created on: 2024-xx-xx
- - Overall Status: ☐ Not Started / ☐ In Progress / ☐ Blocked / ☐ Completed
- - Total Tasks: **65** (estimate)
- - Completed: 0
- - Remaining: 65
- ---
- ## Technical Requirements (snapshot)
- • Frontend: Power Apps Canvas / Power FX
- • Workflow: Power Automate Cloud Flows
- • Backend: Azure Functions (Node .js 20)
- • Data: SharePoint Online Lists & Document Library
- • AuthZ: Azure AD (group-based), MSAL
- • Logs/Monitoring: Application Insights, SPO Audit
- • CI/CD: GitHub Actions, Bicep, PnP Provisioning
- ---
- ## Next Steps
- 1. Approve this WBS in steering committee.
- 2. Lock environment naming & resource group strategy by Phase 1 start.
- 3. Begin Phase 1 tasks in parallel once licensing is confirmed.
- 4. Prepare UAT user list and data seeds by Phase 7.
- ---
現時点の自作kiroエージェントの使い道
cursorやその他vibe codingの最初の入力でやはり具体性があるほどにうまく行くのが経験的にわかっているので、この自作kiroエージェントで作成したタスク等を入力とし、良いコードを作成していきたいと思います。最終的にはgithubですべてレビューも完結できるように自動プッシュとコミットも実装していきたいですね。
また、社内RAGもFastAPIやMCP化を事前にしてあるので、今後必要に応じて専門知識を検索しに行く仕組みも追加し、高度な要求仕様作成にも耐えられる仕組みにしたいと考えています。
もしご興味あれば！
今は完全に趣味で開発してますが、ossとして汎用性を持たせて公開することも検討しています。もしご興味ある方いましたら一緒に開発してブラッシュアップしましょう！🔥
SNGの連絡先
※完全に趣味であり営利目的ではありません
続編
Discussion
野暮なコメントですが、kiroのプレビュー版は以下からダウンロードして使えますよ。 私も、公式サイトのwaiting list推しによって分かりづらくて探すのに苦労しました。
ありがとうございます！お恥ずかしながら。。知りませんでした涙
早速試してみます、自己のチームのワークフローに寄り添う形で再設計してみたいと考えています